RFC 1918 Private Address Space
Under the current IP addressing scheme (often known as IPv4, eventually to be replaced by IPv6), the address space is divided into two types: public address space and private address space. Understanding the difference is important and useful for a network administrator, especially if your organization is connected to the Internet.

All of the Public Address Space (IP addresses) routable via the Internet are managed by one of the three Regional Internet Registries (RIRs). Each of these is responsible for a geographic region. (Don't confuse these with the InterNIC [http://www.internic.net] and its designated registrars, such as Network Solutions, Inc. They handle domain name registration, not address registration.)

• North and South America, the Caribbean, and sub-Saharan Africa are managed by the American Registry for Internet Numbers, or simply: ARIN. http://www.arin.net
• Europe, the Middle East, and other parts of Africa are managed by RIPE (Réseaux IP Européens). http://www.ripe.net
• APNIC, the Asia Pacific Network Information Centre, handles the Asia Pacific region. http://www.apnic.net.

You must request address space, and they will either grant or deny your request. Alternately, you can request the address space from your ISP (who then, in turn, allocates you from its ARIN-allotted address space, or makes the request on your behalf).

This is done to preserve address space and provide a central authority to prevent address-space collisions. When you are using a public address, you can send to and receive from all (non-broken) parts of the Internet. This means that all routers in the Internet have an idea about how to route your IP address towards you. Because of this, not all address space is portable. If you own your address space, you can authorize an ISP to route it for you, but there is a chance when you change providers or locations that it will no longer be possible to route your IPs to that new location. (So you might want to check before you travel with your address space.)

In any event, the public address space has been divvied up and allocated to countries, companies, universities, ISPs, other organizations, and individuals. A small part of the overall address space has been classified as private address space. It is also known as RFC 1597 or RFC 1918 address space, after the RFCs that describe its proper use. Private address space is intended for use by anyone, but on private networks. The subnets themselves will be familiar to many of you, even if you were previously unaware that they corresponded to private address space. According to RFC 1918 (which obsoletes the well-known RFC 1597), the private subnets are:

1. The 10.0.0.0/8 network is a single class A network. 172.168.0.0/12 is a set of sixteen class B networks. 192.168.0.0/16 represents 255 contiguous class C networks. For organizations with private networks which are connected to the Internet, this means: They can run TCP/IP without any danger of address conflicts with the outside.
2. They can allocate address space from the private address space in a manner which makes sense for them (perhaps geographically, maybe organizationally).
3. Their internal networks are (somewhat) shielded from Internet-based attacks. An attacker has more difficulties launching an attack against IP addresses which cannot be routed.
4. Their machines with private addresses cannot directly communicate with the Internet. This necessitates the use of a proxy or masquerading mechanism, which can help perform logging and prevent unauthorized access.
5. They do not have to go through the hassle of changing IP addresses should they change ISPs, nor do they have to apply for address space when they need more.

Every network admin should have a copy of the latest RFC describing the private address space (for IPv4). An official source for this document is http://www.ietf.org/. Debian has provided a copy if you've loaded either the bind-doc or the doc-rfc package.

Allocating Private Address Space Internally
Keep private address space in mind when planning your network. If you work with other network admins at your organization, draw up an allocation scheme for your environment and have all involved agree to abide by it. The time-savings down the road could be substantial. Another benefit is that you can prevent clutter in your routing tables. If you use CIDR to divide the address space into large aggregates of subnets which are based on geographic boundaries, you can reduce the number of routing entries at each router.

For example, imagine a Frame Relay router located in Europe with PVCs to North America and the Pacific Rim. The site in Europe acts as the hub--i.e., the two leaf sites send data to each other via the site in Europe. Each site has four class C subnets, and all sites communicate with all other sites. If all three sites grew up at about the same time, and you allocated the subnets sequentially, you would have:

The router in Europe would then have four class C subnets to route per PVC. But the router in North America would have eight, as would the router on the Pacific Rim. At this scale, the issue is still a manageable one, but consider what happens when each site has 10–15 class C networks. If you plan ahead and assign each location a larger block of class C networks, you could have the following:

Now Europe has only two routing table entries: 192.168.64.0/18 (all 64 class C's towards the Pacific Rim), and 192.168.128.0/17 (the remaining 128 class C's towards North America). North America has only a single routing entry, 192.168.0.0/17, which points towards Europe. And the Pacific Rim also has two routing table entries: 192.168.0.0/18 and 192.168.128.0/19. A little time spent up front can alleviate the need for large static routing tables or dynamic routing daemons for your internal network.

When you're allocating network space, leave yourself room for growth. It is difficult to know in advance how much address space a site will need, so spread things out at first. (If you need to reclaim the unused address space later, it will still be there.) As a rule of thumb, allocate a class C for every existing 100 devices, and if the site expects growth, double the existing address space by taking another bit from the subnet mask.