I haven't read the NYT article (yeah, kill me), but I have more than a passing level of familiarity with the case. I used to work for Enron, and I have more than one former co-worker that I believe to be in discussions with federal prosecutors about testifying in this case.
I strongly suspect the functionality here was the Broadband Operating System, which was specifically the software support for trading operations. I wrote some of the software in the Pooling Point Control System part of the BOS, which was supposed to provide logistical support for the execution of bandwidth trades, i.e. our software expected to talk directly with the cross-connects and the switches in the pooling points. The case will probably turn on what the Enron executives told the analysts about what was the actual status of that development work at the time of the demonstrations.
I'm trying to be really careful, but let me say this: at Enron, it was a very macabre joke to repeat out loud the old chestnut about how Any Sufficiently Advanced Technology Is Indistinguishable From A Rigged Demo.
My advice to engineers who think they might be working for the next Enron: keep a diary, and keep it safe. When you are working for people who think they can deliver political solutions to engineering problems, you can expect that sooner or later your value to the team will be measured by how much leverage you have collected.
At Enron, almost all of the Lawful Good characters in the party were very low level players, and I saw a lot of my friends get screwed because they were sharp engineers but they weren't very good at power politics. Do I have strong opinions I am not voicing here? Yes. Do I wish I had kept a diary? Yes. Was I an accessory to a fraud? I sure hope not.
| 1> Union Carbide plant suffers catastrophic incident, resulting in | hundreds and thousands of injuries to employees and families. | | 2> Dow Chemical purchases Union Carbide plant. | | 3> Dow Chemical CEO should pe bunished for the accident. | | What are you smoking to get that conclusion from the first two events?
DOW Chemical didn't just purchase the plant. They purchased the entire company- including all its liabilities as well as its assets.
Is this whole "corporate enterprise" thing a new concept to you?
You raise some points that call for rebuttal. (If you see me ignoring them, it means I think they're not worth rebutting.)
> What's wrong with TFTP or NFS or any other network filesystem?
Ever tried to deploy a distributed NFS server? By that I mean: if the primary NFS server goes down, a secondary automatically and transparently serves as a replacement without the NFS client ever having to be redirected? Such things exist. None of them are cheap.
> Then what do you call it? Because using a database sounds like a very good > way to maintain cache coherency. You would rather state be strewn across the network?
You *already* have state strewn across the network, i.e. the availability states of the various processes that comprise the distributed system. Why try to maintain a cache of that state in a database when the processes can use the network to discover and locate one another directly?
Have you every tried to deploy a replicated database manager? Every transaction on the database must be ACID for this to work with high reliability. (ACID is an acronym, stands for Atomic Consistent Independent and Durable.) Easy to do with a monolithic database manager. Much harder to do with a replicated system. Again, such things exist. None of them are cheap.
My point: distributed systems with more single points of failure provide less reliability than systems with fewer. Rendezvous eliminates an important single point failure mode.
Actually, the only thing they have in common is that they both use the as-yet-unofficial IETF standard for IPv4 link-local address self-assignment. Everything else about the two initiatives are completely different.
Lots of processes running on an array of machines. Say for example you have a data center full of racks of 1U servers, and each one is cranking away on some part of the application code. You have redundant processes scattered around too, so if one machine takes a dive, you want the whole application to stay up and running anyway.
Imagine you're the administrator of this system. How do you tell each little process in the system what IP address and TCP port to use so that every other process in the system knows where to find it?
Without Rendezvous, you have several options-- all of them unappealing. You might start with some kind of application specific configuration file format and a cobbled-together system for distributing such data around to all the hosts in the system. You might instead store such network configuration in some directory server on the network, like DNS or LDAP or some kind of custom front end to some kind of evil database backend.
Either way, you quickly encounter what we veterans like to call "the cache coherency problem," i.e. the information in the directory must be consistent at all times with the actual state of the processes in the system. Whenever processes start, stop, migrate or change their profile, you have to update the directory. Solving this problem with existing technology can be expensive. If you don't solve it, then single-point failure modes proliferate and the system becomes exponentially more difficult to manage the larger it gets.
With Rendezvous, the network itself is the directory service. Since all the little processes in the system are responsible for their own advertisements, there is no cache coherency problem. You don't have to assign addresses and ports to all your processes because the application can simply assign itself a set of abstract service names and discover all the instances of those services on the network with Rendezvous service discovery. No configuration files to keep updated. No dynamic updates to LDAP or DNS servers that might get overloaded, or may not be running or in the right place when they need to be.
Of course, there are alternatives to consider. You might think to use SLP (RFC 2608-2610), which you can download now from www.openslp.org, but strangely... SLP hasn't managed to get much traction in industry. Some say that's because it's too unwieldy to use effectively.
You should compare Rendezvous with OpenSLP and see which one you think is better.
>>> it requires zero configuration once you're configured properly.
In other words, it requires zero configuration once you've decided that manually configuring all the hosts on your network with unique IPv4 addresses and a common subnet mask is prone to transcription errors, and you stop misconfiguring everything.
You might think that's a good idea... but then you'd want to look at the picture at the top of this page before you whip out the credit card and place a pre-order:
http://www.apple.com/xserve/specs.html
Size and weight: 26 lbm (31 lbm with 4 drives loaded), 1.73" x 19" x 28" Twenty-eight inches deep. And it has two big fans. It's 1U, but it's pretty deep.
If you ask me, they are not meant to run in close proximity to humans. It really wants to be a headless rack-mounted server locked in a data center somewhere.
--
Re:Rendezvous sounds interesting... open standard
on
Apple Drops Mac OS 9
·
· Score: 5, Informative
APIPA is yet another acronym for link-local IPv4 addressing.
What Apple is calling "Rendezvous" begins with link-local IPv4 addressing and adds "multicast DNS" (which Microsoft wants to call "link-local multicast name resolution," i.e. LLMNR... sigh).
Here's what Rendezvous *actually* is: it's the last little bit of what Appletalk had going for it, finally "ported over" to work on the Internet protocol. Not only is Mac OS 9 in the terminal patient's ward-- so is the Appletalk network protocol. Happy happy day.
> I have no idea what you are talking about regarding templates being created at compile-time > as being a bad thing. That's what generic programming is all about!!! Its the compiler > generating classes so that you don't have to. It has to be done at compile time. I'd love to > hear an example of a language that implements some kind of generic stuff at runtime.
Objective Caml is one language which does that. I know there are others, but I can't think of their names just now. Oberon, maybe? Ada? Bueller?
You don't need or want NAT for any of these purposes, because there are other *better* solutions available in each case.
+ If you want multiple services to appear to be provided by the same host, when in fact they are provided by different hosts behind a firewall, then you want your firewall to be an application-layer proxy. You don't need NAT for this. Just put the private server hosts on a site-local address, and let the proxy do as it will. A proxy will do a better job of this than a NAT.
+ If you want to load balance 1000 servers to one name, you want to use DNS SRV with named instances of abstract services, and let the clients do the load balancing. This way your NAT isn't a single-point failure opportunity, which is important if you have a data center with a 1000 servers in it. (Yes: you *can* have a CNAME point at 1000 SRV records. The DNS caches are your friends. Use them.)
+ If you want to hide your internal infrastructure and make everything appear at a border host, then again: you want an application-layer proxy not a NAT. An application-layer proxy will do a better job of hiding your internal infrastructure.
+ If you don't want to upgrade your IPv4 host to IPv6, and you still want to communicate with the IPv6 world, then well-- you haven't upgraded to IPv6 yet, have you? Once you upgrade your entire network to IPv6, you won't need the NAT anymore.
You are mistakenly confusing the function of a network address translator with the function of a firewall.
If we ever get around to deploying IPv6, we will still need firewalls for all the same reasons we need them with IPv4. We will not need network address translators, since they will not be providing any useful function whatsoever.
Set the outgoing mail host for your account to "localhost" after you run this, and your local SMTP port will be forwarded to the SMTP port on your mail host by SSH. There has to be an SSH daemon that will let you log in on the SMTP host for this to work.
The SMTP/TLS specification only just went to Proposed Standard Protocol with the publication of RFC 3207 earlier this month. The IMAP/TLS specification has been a proposed standard for like two years already.
How long will it be before we see one of these Internet service providers who use host MAC addresses for controlling network access filing suit against the vendors of so-ho NAT routers that permit users to assign an arbitrary MAC address to their WAN port?
Isn't that essentially a technology for circumventing network access controls?
All the candidate protocols for multimedia Internet instant messaging require some kind of proxy or ALG in every NAT device. Everyone hates NAT-- especially the IAB-- but a ridiculous number of people are relying on the facilities that NAT provides (home networks on residential IP service, and address realm independency). The current favorite, i.e. SIMPLE, seems much less NAT-friendly to me than the others.
Coincidence, or conspiracy? If you're one of those executives in "the already shaky ISP market," then you probably hate NAT for completely different reasons than the IAB. Any multimedia instant messaging protocol that drives up the cost of purchasing, provisioning and managing a subscriber's NAT device might just give you the sort of leverage over home networking that you've been pining away for since the breakup of the Monopoly.
Of course, I could just need to switch to decaf...
The larger one has a different battery, i.e. one with 8 cells instead of 6. So Apple is saying the 14" iBook can give you six hours of OS X on a single charge, instead of five... It's also 1 lb heavier.
And, dude-- it's not like the old iBook is no longer for sale, or anything stupid like that. What are you complaining about? Too many choices?
In a previous life, I worked for a major American space systems company. I worked on the ground station software for the command and telemetry systems in Intelsat VII and the NTT N-Star series. I had brief affairs with command and telemetry for a few other spacecraft. Those are my bona fides, and my resume is on my web page.
On the issues that concern you:
1. "Can someone effectively execute a denial of service attack by jamming the uplink signal at the analog level?" Yes, but you might be able to make it hard enough that it costs more money than it's worth. Remember that such an attack will have to be launched from near the terrestrial location of the ground control station. There's some steps you can take to use that to your advantage.
2. "Can you decipher the semantics of the command set?" We're assuming I can spoof the uplink and send random command strings and get them executed by the bird? Access to the telemetry would be crucial here. If I can't read the telemetry associated with valid commands, then the best I can hope to do is to upset the bird on my second or third valid command. Actually controlling the bird for a useful end is probably out of the question. (Though, it might be worth billions of dollars just to be able to kill the bird.) So: Encrypt the telemetry. Put the keys in God's Own Safe. But PLEASE don't let script kiddies execute valid, randomly generated command strings on birds they don't own! At least, force them to steal the symmetric keys for encrypting the command strings from the same safe you put the keys for encrypting the telemetry.
3. "Are the standards based approaches secure?" They're basically as secure as the setup you're probably using now. Maybe a little more secure, if the implementations you use are very mature and security experts have been grovelling over every line of their code since Turing was a teenager. You *ARE* planning to make all of the avionics code upgradeable on orbit, right? Security depends on the timely application of patches, you know.
I think the main reason functional programming never quite made it out of L'Academe is that imperative programming has its merits too, and what you want is a language that easily permits both approaches within the same program.
Purely functional languages like Haskell are probably not a good place to start if you've only ever been exposed to derivatives of C and Pascal. I'd also recommend choosing a language with strict evaluation rather than lazy evaluation, which is extra work to learn to use effectively. SML or an ML-derivative is what I would suggest.
I've had a good experience with Objective Caml. The compilers are stable, they can produce reasonably fast portable bytecode as well as satisyingly faster native object code on most platforms, the user community is still small enough that the developers at INRIA occasionally have time to help beginners with problems.
The new base station firmware also supports the RADIUS client for use with access control, but only on the new hardware. The firmware for the old hardware does not have the RADIUS client.
The firmware for the new Airport base has a RADIUS client. The firmware for the old Airport base does not have a RADIUS client. The Airport 2.0 software contains the firmware for both versions of base station, and will use the appropriate version when you upgrade your unit.
Since you don't have the new hardware, you don't get the features of the firmware for that hardware.
Actually, there is a theoretical limit: there is only finite number of available MAC addresses in the address space. Obviously, the 50-client limit pertains to some other practical consideration.
The 802.11 protocol may work with a virtually unlimited number of stations on the same wireless medium, but NAT engines usually have limits on the number of private IP addresses that can be shared with a single public IP address.
Slashdot Mirror
I haven't read the NYT article (yeah, kill me), but I have more than a passing level of familiarity with the case. I used to work for Enron, and I have more than one former co-worker that I believe to be in discussions with federal prosecutors about testifying in this case.
I strongly suspect the functionality here was the Broadband Operating System, which was specifically the software support for trading operations. I wrote some of the software in the Pooling Point Control System part of the BOS, which was supposed to provide logistical support for the execution of bandwidth trades, i.e. our software expected to talk directly with the cross-connects and the switches in the pooling points. The case will probably turn on what the Enron executives told the analysts about what was the actual status of that development work at the time of the demonstrations.
I'm trying to be really careful, but let me say this: at Enron, it was a very macabre joke to repeat out loud the old chestnut about how Any Sufficiently Advanced Technology Is Indistinguishable From A Rigged Demo.
My advice to engineers who think they might be working for the next Enron: keep a diary, and keep it safe. When you are working for people who think they can deliver political solutions to engineering problems, you can expect that sooner or later your value to the team will be measured by how much leverage you have collected.
At Enron, almost all of the Lawful Good characters in the party were very low level players, and I saw a lot of my friends get screwed because they were sharp engineers but they weren't very good at power politics. Do I have strong opinions I am not voicing here? Yes. Do I wish I had kept a diary? Yes. Was I an accessory to a fraud? I sure hope not.
| 1> Union Carbide plant suffers catastrophic incident, resulting in
| hundreds and thousands of injuries to employees and families.
|
| 2> Dow Chemical purchases Union Carbide plant.
|
| 3> Dow Chemical CEO should pe bunished for the accident.
|
| What are you smoking to get that conclusion from the first two events?
DOW Chemical didn't just purchase the plant. They purchased the entire company- including all its liabilities as well as its assets.
Is this whole "corporate enterprise" thing a new concept to you?
--
Mr. Shatner,
Loved your take on 'Lucy in the Sky with Diamonds'...
I must say I didn't fully appreciate it until I left the CD player on repeat for a full day.
Have you considered covering any other pop songs? (I can imagine you doing a very fine version of Don McLean's 'The Day The Music Died' for example.)
Read this and come back if you need help.
--
You raise some points that call for rebuttal. (If you see me ignoring them, it means I think they're not worth rebutting.)
> What's wrong with TFTP or NFS or any other network filesystem?
Ever tried to deploy a distributed NFS server? By that I mean: if the primary NFS server goes down, a secondary automatically and transparently serves as a replacement without the NFS client ever having to be redirected? Such things exist. None of them are cheap.
> Then what do you call it? Because using a database sounds like a very good
> way to maintain cache coherency. You would rather state be strewn across the network?
You *already* have state strewn across the network, i.e. the availability states of the various processes that comprise the distributed system. Why try to maintain a cache of that state in a database when the processes can use the network to discover and locate one another directly?
Have you every tried to deploy a replicated database manager? Every transaction on the database must be ACID for this to work with high reliability. (ACID is an acronym, stands for Atomic Consistent Independent and Durable.) Easy to do with a monolithic database manager. Much harder to do with a replicated system. Again, such things exist. None of them are cheap.
My point: distributed systems with more single points of failure provide less reliability than systems with fewer. Rendezvous eliminates an important single point failure mode.
--
Actually, the only thing they have in common is that they both use the as-yet-unofficial IETF standard for IPv4 link-local address self-assignment. Everything else about the two initiatives are completely different.
Check your facts.
--
Suppose you want to write a distributed system.
Lots of processes running on an array of machines. Say for example you have a data center full of racks of 1U servers, and each one is cranking away on some part of the application code. You have redundant processes scattered around too, so if one machine takes a dive, you want the whole application to stay up and running anyway.
Imagine you're the administrator of this system. How do you tell each little process in the system what IP address and TCP port to use so that every other process in the system knows where to find it?
Without Rendezvous, you have several options-- all of them unappealing. You might start with some kind of application specific configuration file format and a cobbled-together system for distributing such data around to all the hosts in the system. You might instead store such network configuration in some directory server on the network, like DNS or LDAP or some kind of custom front end to some kind of evil database backend.
Either way, you quickly encounter what we veterans like to call "the cache coherency problem," i.e. the information in the directory must be consistent at all times with the actual state of the processes in the system. Whenever processes start, stop, migrate or change their profile, you have to update the directory. Solving this problem with existing technology can be expensive. If you don't solve it, then single-point failure modes proliferate and the system becomes exponentially more difficult to manage the larger it gets.
With Rendezvous, the network itself is the directory service. Since all the little processes in the system are responsible for their own advertisements, there is no cache coherency problem. You don't have to assign addresses and ports to all your processes because the application can simply assign itself a set of abstract service names and discover all the instances of those services on the network with Rendezvous service discovery. No configuration files to keep updated. No dynamic updates to LDAP or DNS servers that might get overloaded, or may not be running or in the right place when they need to be.
Of course, there are alternatives to consider. You might think to use SLP (RFC 2608-2610), which you can download now from www.openslp.org, but strangely... SLP hasn't managed to get much traction in industry. Some say that's because it's too unwieldy to use effectively.
You should compare Rendezvous with OpenSLP and see which one you think is better.
--
Markets are only free to the people who own them.
--
>>> it requires zero configuration once you're configured properly.
In other words, it requires zero configuration once you've decided that manually configuring all the hosts on your network with unique IPv4 addresses and a common subnet mask is prone to transcription errors, and you stop misconfiguring everything.
You might think that's a good idea... but then you'd want to look at the picture at the top of this page before you whip out the credit card and place a pre-order:
http://www.apple.com/xserve/specs.html
Size and weight: 26 lbm (31 lbm with 4 drives loaded), 1.73" x 19" x 28"
Twenty-eight inches deep. And it has two big fans. It's 1U, but it's pretty deep.
If you ask me, they are not meant to run in close proximity to humans. It really wants to be a headless rack-mounted server locked in a data center somewhere.
--
APIPA is yet another acronym for link-local IPv4 addressing.
What Apple is calling "Rendezvous" begins with link-local IPv4 addressing and adds "multicast DNS" (which Microsoft wants to call "link-local multicast name resolution," i.e. LLMNR... sigh).
Here's what Rendezvous *actually* is: it's the last little bit of what Appletalk had going for it, finally "ported over" to work on the Internet protocol. Not only is Mac OS 9 in the terminal patient's ward-- so is the Appletalk network protocol. Happy happy day.
--
> I have no idea what you are talking about regarding templates being created at compile-time
> as being a bad thing. That's what generic programming is all about!!! Its the compiler
> generating classes so that you don't have to. It has to be done at compile time. I'd love to
> hear an example of a language that implements some kind of generic stuff at runtime.
Objective Caml is one language which does that. I know there are others, but I can't think of their names just now. Oberon, maybe? Ada? Bueller?
--
This is one of the reasons I hate using IE on OS X. It's a Carbon app.
RMS would be bald, he would have a pot belly and beady little eyes, and he would have an unhealthy fascination with prostitutes.
You don't need or want NAT for any of these purposes, because there are other *better* solutions available in each case.
+ If you want multiple services to appear to be provided by the same host, when in fact they are provided by different hosts behind a firewall, then you want your firewall to be an application-layer proxy. You don't need NAT for this. Just put the private server hosts on a site-local address, and let the proxy do as it will. A proxy will do a better job of this than a NAT.
+ If you want to load balance 1000 servers to one name, you want to use DNS SRV with named instances of abstract services, and let the clients do the load balancing. This way your NAT isn't a single-point failure opportunity, which is important if you have a data center with a 1000 servers in it. (Yes: you *can* have a CNAME point at 1000 SRV records. The DNS caches are your friends. Use them.)
+ If you want to hide your internal infrastructure and make everything appear at a border host, then again: you want an application-layer proxy not a NAT. An application-layer proxy will do a better job of hiding your internal infrastructure.
+ If you don't want to upgrade your IPv4 host to IPv6, and you still want to communicate with the IPv6 world, then well-- you haven't upgraded to IPv6 yet, have you? Once you upgrade your entire network to IPv6, you won't need the NAT anymore.
You are mistakenly confusing the function of a network address translator with the function of a firewall.
If we ever get around to deploying IPv6, we will still need firewalls for all the same reasons we need them with IPv4. We will not need network address translators, since they will not be providing any useful function whatsoever.
Here is a rude trick from the Terminal.app prompt that I use:
sudo ssh -N -L 25:mail.example.com:25 mail.example.com
Set the outgoing mail host for your account to "localhost" after you run this, and your local SMTP port will be forwarded to the SMTP port on your mail host by SSH. There has to be an SSH daemon that will let you log in on the SMTP host for this to work.
The SMTP/TLS specification only just went to Proposed Standard Protocol with the publication of RFC 3207 earlier this month. The IMAP/TLS specification has been a proposed standard for like two years already.
How long will it be before we see one of these Internet service providers who use host MAC addresses for controlling network access filing suit against the vendors of so-ho NAT routers that permit users to assign an arbitrary MAC address to their WAN port?
Isn't that essentially a technology for circumventing network access controls?
--
I'd say there's some room for controversy too.
All the candidate protocols for multimedia Internet instant messaging require some kind of proxy or ALG in every NAT device. Everyone hates NAT-- especially the IAB-- but a ridiculous number of people are relying on the facilities that NAT provides (home networks on residential IP service, and address realm independency). The current favorite, i.e. SIMPLE, seems much less NAT-friendly to me than the others.
Coincidence, or conspiracy? If you're one of those executives in "the already shaky ISP market," then you probably hate NAT for completely different reasons than the IAB. Any multimedia instant messaging protocol that drives up the cost of purchasing, provisioning and managing a subscriber's NAT device might just give you the sort of leverage over home networking that you've been pining away for since the breakup of the Monopoly.
Of course, I could just need to switch to decaf...
--
The larger one has a different battery, i.e. one with 8 cells instead of 6. So Apple is saying the 14" iBook can give you six hours of OS X on a single charge, instead of five... It's also 1 lb heavier.
And, dude-- it's not like the old iBook is no longer for sale, or anything stupid like that. What are you complaining about? Too many choices?
In a previous life, I worked for a major American space systems company. I worked on the ground station software for the command and telemetry systems in Intelsat VII and the NTT N-Star series. I had brief affairs with command and telemetry for a few other spacecraft. Those are my bona fides, and my resume is on my web page.
On the issues that concern you:
1. "Can someone effectively execute a denial of service attack by jamming the uplink signal at the analog level?" Yes, but you might be able to make it hard enough that it costs more money than it's worth. Remember that such an attack will have to be launched from near the terrestrial location of the ground control station. There's some steps you can take to use that to your advantage.
2. "Can you decipher the semantics of the command set?" We're assuming I can spoof the uplink and send random command strings and get them executed by the bird? Access to the telemetry would be crucial here. If I can't read the telemetry associated with valid commands, then the best I can hope to do is to upset the bird on my second or third valid command. Actually controlling the bird for a useful end is probably out of the question. (Though, it might be worth billions of dollars just to be able to kill the bird.) So: Encrypt the telemetry. Put the keys in God's Own Safe. But PLEASE don't let script kiddies execute valid, randomly generated command strings on birds they don't own! At least, force them to steal the symmetric keys for encrypting the command strings from the same safe you put the keys for encrypting the telemetry.
3. "Are the standards based approaches secure?" They're basically as secure as the setup you're probably using now. Maybe a little more secure, if the implementations you use are very mature and security experts have been grovelling over every line of their code since Turing was a teenager. You *ARE* planning to make all of the avionics code upgradeable on orbit, right? Security depends on the timely application of patches, you know.
--
I think the main reason functional programming never quite made it out of L'Academe is that imperative programming has its merits too, and what you want is a language that easily permits both approaches within the same program.
Purely functional languages like Haskell are probably not a good place to start if you've only ever been exposed to derivatives of C and Pascal. I'd also recommend choosing a language with strict evaluation rather than lazy evaluation, which is extra work to learn to use effectively. SML or an ML-derivative is what I would suggest.
I've had a good experience with Objective Caml. The compilers are stable, they can produce reasonably fast portable bytecode as well as satisyingly faster native object code on most platforms, the user community is still small enough that the developers at INRIA occasionally have time to help beginners with problems.
--
The new base station firmware also supports the RADIUS client for use with access control, but only on the new hardware. The firmware for the old hardware does not have the RADIUS client.
--
The firmware for the new Airport base has a RADIUS client. The firmware for the old Airport base does not have a RADIUS client. The Airport 2.0 software contains the firmware for both versions of base station, and will use the appropriate version when you upgrade your unit.
Since you don't have the new hardware, you don't get the features of the firmware for that hardware.
--
Actually, there is a theoretical limit: there is only finite number of available MAC addresses in the address space. Obviously, the 50-client limit pertains to some other practical consideration.
The 802.11 protocol may work with a virtually unlimited number of stations on the same wireless medium, but NAT engines usually have limits on the number of private IP addresses that can be shared with a single public IP address.
How many does your NAT engine support?