Digital Elephant
Private Networks
In the bad old days, when the Internet was young, we imagined that every computer everywhere in the world would have its very own unique address. This has been shown unworkable both because administration is a nightmare and because the number of computers in use has grown exponentially, and so today we find that IP addresses are a scarce commodity. This has led ISPs to ration addresses, to charge fairly high fees for the use of blocks of IP addresses, and to make things generally difficult for customers that wish to administer their own networks.
The original motivation for this unique-address approach, though, was that every machine should be able to talk to every other machine on the Internet. For several reasons, this has turned out not to be such a good idea either, and so a scheme has been worked out that solves two problems at once: it makes it easy for an unregistered person to set up a private networking space that will work well with the rest of the Internet, and it makes it hard for hackers to gain unauthorized access to those private machines.
This scheme is covered in great detail in RFC1597, Address Allocation for Private Internets; there are two essential parts: some address ranges have been set aside for use by any private network, and these addresses are to be excluded from the public Internet. These ranges are:
| 10.0.0.0 -- 10.255.255.255 | 1 | Class A range | 16,777,214 addresses |
| 172.16.0.0 -- 172.31.255.255 | 16 | Class B ranges | 65,534 addresses each |
| 192.168.0.0 -- 192.168.255.255 | 256 | Class C ranges | 254 addresses each |
This means that you are permitted (even encouraged) to choose a set of addresses in one of the ranges, and assign them to machines on your private network, without asking anyone's permission. The last range is best for most small operations. Each slice of this range covers 254 machines, and if you need more, you can just allocate yourself another chunk (eg, start with 192.168.1.x, and if you need more, use the range 192.168.2.x).
By itself, this is fine for security, but lousy for communication. Machines on the private network can talk to one another, but if one wants to reach a public Internet site, its packets will be refused by the first public router that sees them, because they contain one of the proscribed addresses. The missing piece is called network address translation (NAT) or masquerading. This process converts packets as they leave the private network so that they appear to originate on the boundary machine. At the same time, the boundary machine makes marginal notes, so that when a reply packet comes back from the public side, it can be converted back into a form that gives the original requestor the impression that it has direct communication with its target.
For systems on the private network, this is a perfectly fine scheme. It affords a workstation shared access to the Internet through a single boundary machine for (nearly) any transaction that is initiated by that machine. The only communication that is not supported is that which originates on the public side, and is aimed at a machine on the private network. This is exactly the domain of hackers, though, so most users will not see this as a drawback.