Networking Tips


[an error occurred while processing this directive]

No Title

[an error occurred while processing this directive]

Reference: Cisco: Internetworking Basics



Under the current IP addressing scheme (often known as IP4, 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 [] and its designated registars, such as Network Solutions, Inc. They handle domain name registration, not address registration.)

The three Regional Internet Registries are:

You must request address space, and they will either grant or deny address 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 recieve 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 not 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:

Private Subnets
IP address range Network/Mask Number of Address - 16,777,216 (224) - 1,048,576 (220) - 65,536 (216)

The network is a single class A network. is a set of sixteen class B networks. represents 255 contiguous class C networks. For organizations with private networks which are connected to the Internet, this means:

  1. 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 ogranizationally).

  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 administrator should have a copy of the latest RFC describing the private address space (for IPv4). An official source for this document is

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 a 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:

Europe North America Pacific Rim

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:

Region Range of Addresses Subnet # of Subnets
Europe - 64
Pacific Rim - 8
North America - 32

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

When you are 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 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.

About the Author

Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX / Linux server environment. Jeff's other interests include mathematical encryption theory, tutoring advanced mathematics, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 20 years and maintains his own website site at: Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science and Mathematics.

Copyright (c) 1998-2018 Jeffrey M. Hunter. All rights reserved.

All articles, scripts and material located at the Internet address of is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at

I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.

Last modified on
Wednesday, 28-Dec-2011 14:13:27 EST
Page Count: 28670