Private Addressing and Subnetting Large Networks
You’ve heard it said: “We’re running out of IP addresses!” Really? In the IP (version 4) architecture, we use 32-bit address fields. With 32-bits in our addresses, there are 232 unique addresses available. That’s over four billion addresses! We know that the Internet has experienced exponential growth over the last few years, but even with continued growth, it’s unlikely that we’ll see anywhere near four billion machines on the Internet any time soon.
So where’s the problem? The problem exists in the granularity of address allocation. Prior to Classless Inter-Domain Routing (CIDR), addresses were allocated in classful blocks. That is, if you needed more addresses than a class C network provided, you got a class B network address; if you needed more than a class B provided, you got a class A network address. Those were the only three choices. (Not many organizations actually got class A addresses, of course.)
Although there are indeed over 4 billion unique IP addresses available with the current version of IP, the number of unique network numbers is much less. In fact, there are only 126 class A networks, about 16,000 class B networks, and about 2 million class C networks. This design has led to widespread waste of globally-unique IP addresses.
In the 1970s, the architects of the Internet envisioned an internetwork with dozens of networks and hundreds of nodes. They developed a design where any node on the internetwork was reachable by any other node. Back then, no one could have guessed the effect new applications like the World Wide Web and vastly increased bandwidth would have on the number of people interested in participating in “the Net.” On the Internet today, there are tens of thousands of networks and millions of nodes. Unfortunately, the original design has not scaled well. The increased number of networks joining the Internet has strained router technology, and the sheer number of participants has strained the limits of IP addressing as it was originally designed. Some compromises had to be made to allow the Internet to continue its growth.
Several strategies have been developed and implemented to help the Internet community cope with its growing pains. They help reduce the load on the Internet routers and help us use globally-unique IP addresses more efficiently. These strategies include:
Classless Inter-Domain Routing (CIDR), specified in RFCs 1517, 1518, and 1519, was introduced in September 1993 as a way to reduce router table growth. As a side effect, it has helped reduce the waste of IP addresses by reducing the granularity of allocation. Now, instead of full class A, B, or C networks, organizations can be allocated any number of addresses. (Normally, addresses are allocated in even powers of two to allow CIDR to realize its maximum benefit, but in reality, any number of addresses can be allocated.)
For example, if you needed 3,000 addresses for your network, a single class C network (256 addresses) would be insufficient. If, however, you were assigned a class B network (65,536 addresses), there would be over 62,000 addresses wasted! With CIDR, you can be allocated a block of 4,096 addresses—equivalent to 16 class C networks (a /20 in CIDR notation). This block of addresses will cover your addressing needs now, allow room for growth, and use global addresses efficiently. CIDR is covered in Chapter 6.
Variable-Length Subnet Mask (VLSM) is a technique used to conserve IP addresses by tailoring the mask to each subnet. Subnets that need many addresses will use a mask that provides many addresses. Those that need fewer addresses will use a different mask. The idea is to assign “just the right amount” of addresses to each subnet.
Many organizations have point-to-point WAN links. Normally, these links comprise a subnet with only two addresses required. Our subnetting tables given in Chapter 2 tell us that 255.255.255.252 is the appropriate mask to use for those subnets. But that mask would never do for a typical LAN where there are dozens (if not hundreds) of hosts in a subnet. By using a routing protocol that supports VLSM, we can use a block of addresses much more efficiently. VLSM is explained in more detail in Chapter 5.
By far, the most effective strategy for conserving globally-unique (public) IP addresses involves not using any at all! If your enterprise network will be using TCP/IP protocols, but will not be communicating with hosts on the global Internet, you don’t need to use public IP addresses. The Internet Protocol simply requires that all hosts in the interconnected network have unique addresses. If the internetwork is limited to your organization, then the IP addresses need only be unique within your organization.
Today, many (if not most) organizations want to have at least some ability to communicate over the Internet. Does that mean these organizations must use public addresses? Yes it does—but it does not mean that all of the devices in that network must have public addresses. Such networks can still use private addresses and a technique called Network Address Translation (NAT) to convert those private (inside) addresses to public (outside) addresses. NAT is discussed in Chapter 4.
IPv6 is fixing the problem of the limited address space of IPv4. Until IPv6 is fully deployed, we must make use of the IP addressing system we have. Sometimes, the networks we must support are not IP-address friendly. For example, consider the sample network in Figure 3.1.
In the network shown in Figure 3.1, we have multiple LANs at the headquarters location and several branch offices that each have one LAN. The headquarters router is acting as a “collapsed backbone,” connecting all the headquarters LANs and, via leased lines, the branch office routers. The organization has been assigned class B address 172.16.0.0, which provides 65,536 unique addresses.
As we mentioned in Chapter 2, the serial links connecting routers need their own IP addresses. In a point-to-point network such as the dedicated leased lines shown in Figure 3.1, each of the links is an individual subnet.
Table 3.1 lists the various subnets and the addressing requirements for each.
|Location||# Subnets||# Hosts|
In this example, the network is using RIP (version 1) as the routing protocol, so each subnet must use the same mask. Using guidelines discussed in Chapter 2, we identify the largest subnet in our network. One of the subnets at the Headquarters location needs 190 addresses. Consulting the tables in Chapter 2, we see that 255.255.255.0 is the most appropriate mask to use because it provides 254 unique addresses in each subnet. Table 3.2 shows just how inefficient it can be to use a single, fixed mask for all subnets.
The Headquarters subnets are sized appropriately, even allowing for some growth. The branch office subnets provide many more addresses than will actually be used. The biggest waste occurs in the WAN links. Since the sample network is using point-to-point links between headquarters and the branches, we will never need more than two addresses in each subnet. If you add up the numbers, there are a total of 2,570 addresses needed, but we are allocating 125 subnets with 254 addresses each for a total of 31,750 addresses. As you can see, we’re not using our class B network address very efficiently. The situation is even worse than it first appears. We see there are over 29,000 unused addresses in the subnets we are using; we’re only using 125 of the possible 256 subnets available. If you include the other 131 subnets with 254 possible addresses each, we have a grand total of 62,454 unused addresses. In other words, we’re using just under 4 percent of the total addresses provided by our class B network number. This inefficient use of addresses is one of the main causes of IP address exhaustion.
RFC 1917, published in February 1996, is titled “An Appeal to the Internet Community to Return Unused IP Networks to the IANA.” It cites the growing problem of IP address exhaustion and asks administrators to be good “netizens” and return blocks of IP addresses to the Internet Assigned Numbers Authority for reallocation. It suggests three alternatives:
3. If you have a large block of public addresses, but only need a small portion of them, return the large block to IANA and request a smaller block of addresses. This would be the appropriate action for our example network considered earlier.
The Internet Protocol requires that each interface on a network has a unique address. If the scope of your network is global, then the addresses must be globally-unique. Such is the case with the Internet. Since global uniqueness must be assured, a centralized authority must be responsible for making sure IP address assignments are made correctly and fairly.
For the last few years, this has been the function of the IANA. The Internet has been rapidly expanding in both number of connected networks and number of new applications. The 1990s have seen both the commercialization and the internationalization of the Internet. To meet the demands of a growing Internet community, the IANA is being replaced by the Internet Corporation for Assigned Names and Numbers (ICANN).
If an organization wants to use IP protocols and applications in its network, but has no intention of connecting its network to the global Internet, the IP addresses it uses need not be globally-unique. A network of this type is called a private network, and the addresses used are called private addresses.
If you are deploying IP on a private network, you can use any IP addresses you wish, as long as you adhere to the normal IP addressing rules. Before you go crazy and use an entire class A address for each subnet, consider the following possibilities:
As an example, suppose you needed a class C address for a small network that will not be connected to the Internet (see Figure 3.2). You chose to use 126.96.36.199 as your network address and configured all your devices accordingly. As soon as you finish getting everything set up, your boss decides to implement Internet e-mail. You consult your friendly neighborhood ISP who tells you not to worry. They can use a trick called Network Address Translation (see Chapter 4) that will allow you to keep using your addresses and give you access to the Internet. Great! Everything works just fine except for one thing—you can’t access www.microsoft.com.
The class C address 188.8.131.52 has been officially assigned to Microsoft, which uses it in its Web server farm. When you try to access the Microsoft Web site, the DNS (Domain Name System) resolves the name to IP address 184.108.40.206. When your browser sends an HTTP request to the target address, the IP software thinks (rightly so) that the address is inside your network and does not forward it to the router.
In the midst of the explosive Internet growth in the early 1990s, RFC 1597 suggested a way to help conserve globally-unique IP addresses. The idea was to set aside three blocks of addresses that would never be officially allocated to any organization. These blocks could then be used in any and every private network without fear of duplicating any officially assigned IP addresses in other organizations.
The first of these address blocks is equivalent to a traditional class A address. In CIDR notation, it would be 10.0.0.0/8. RFC 1918 calls it a 24-bit block of addresses because only 8 of the 32 bits is fixed; the other 24 bits are available for local administration. Either way, the range contains 16,777,216 unique addresses—enough to supply even the largest networks.
Table 3.3 summarizes the private address blocks defined by RFC 1918.
Anyone can use any of the address blocks in Table 3.3 in any network at any time. The main thing to remember is that devices using these addresses will not be able to communicate with other hosts on the Internet without some kind of address translation.
Number of addresses. One of the main benefits of using private addresses is that you have plenty to work with. Since you are not using globally-unique addresses (a scare resource), you don’t need to be conservative. In the example network shown in Figure 3.1, you could use an entire class B equivalent address block without feeling guilty. Even though you would be using only 4 percent of the available addresses, you are not hoarding a valuable commodity.
Security. Using private addresses can also enhance the security of your network. Even if part of your network is connected to the Internet, no one outside your network will be able to reach your devices. Likewise, no one from inside your network will be able to reach hosts on the Internet. RFC 1918 specifies that:
“… routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks.”
Limited scope. The reason you have all these addresses available is that your network will not be connected to the global Internet. If, later, you wish to communicate over the Internet, you must obtain official (globally-unique and routable) addresses and either renumber your devices or use NAT.
Renumbering. Anytime you switch to or from private addressing, you will need to renumber (change the IP address of) all your IP devices. Many organizations are setting up their user workstations to obtain IP addresses automatically when booting up rather than assigning a fixed IP address to the workstations. This facility requires that at least one Dynamic Host Configuration Protocol (DHCP) server be set up for the organization. DHCP is described in RFC 2131 and discussed in more detail in Chapter 7.
Joining Networks. If you join your network with another that has used private addressing, you may find that some devices have conflicting addresses. For example, let’s say you chose to use the 24-bit block of private addresses (network 10). You assigned the address 10.0.0.1 to the first router on the first subnet. Now you merge with another organization and must join your networks. Unfortunately, the administrator of the other network chose to assign address 10.0.0.1 to one of its routers. According to IP addressing rules, both devices cannot use the same address. Further, the two routers are probably on different subnets, so not only do you have to assign a different address to the router, you must assign different subnet addresses as well. Again, the solutions include renumbering and NAT.
“If a suitable subnetting scheme can be designed and is supported by the equipment concerned, it is advisable to use the 24-bit block (class A network) of private address space and make an addressing plan with a good growth path. If subnetting is a problem, the 16-bit block (class C networks), or the 20-bit block (class B networks) of private address space can be used.”
The concept of subnetting was introduced into the IP world in August 1985 (RFC 950). Since most IP software modules in use today were developed after that time, they do understand how to do subnetting. So go ahead and use the 10 network for private addressing unless you have good reasons to do otherwise. By using the 24-bit block, you have 24 bits to play with when designing a private addressing scheme.
Simplicity. We want the plan to be as simple as possible so that as many people as possible can understand it. When we look at the IP address of a particular device, we should be able to easily deduce what kind of device it is and where it is in our network without having to refer to volumes of documentation.
Router Efficiency. As nice as it is for the plan to be understandable by the humans that have to maintain it, the routers have to live with the plan every time a packet needs to be forwarded to another subnet. Therefore, the plan should not place a heavy burden on the resources of our routers. Ideally, the plan should build in addressing hierarchies that allow the routing tables to be kept at a relatively small size.
Following the guidelines of Chapter 2, we now present an example of a large organization that has decided to implement private IP addressing in its internetwork. The procedure is the same—choose a mask, allocate the subnet bits, and determine the range of addresses for each subnet.
The network that we’ll study here is relatively stable. There are about 3000 retail stores owned by the company and no store has more than 12 IP devices in it. Reports from management consultants indicate that this number should suffice for the medium term. Each store is connected to its regional distribution center via a leased point-to-point line.
There are currently 18 regional distribution centers, with each center supporting no more than 200 stores. Distribution centers have two physical networks for administration, and one supporting the warehouse. The largest of the admin LANs has 80 IP devices on it, and the warehouse LAN needs 120 addresses. Each distribution center is connected back to headquarters via two parallel T3 links.
|Location||# Subnets||Max Addresses|
|HQ - DC links||18 × 2 = 36||2|
|Dist. Ctr. LANs||18 × 3 = 54||120|
|DC - Store links||18 × 200 = 3,600||2|
|Store LANs||18 × 200 = 3,600||12|
|Total Subnets Needed:||7,305|
|Max Subnet Size:||230|
From the information in Table 3.4 we can obtain the number of subnets needed (7,305) and the number of addresses needed in the largest subnet (230).
There are many correct solutions to this addressing problem, and arguments can be made for all of them. Since our first goal is simplicity, we’ll try to keep the plan as simple as possible. Since all the Software we’re using understands subnetting, we’ll follow the advice given in RFC 1918 and use the 24-bit block—that is, network 10.
Can we somehow fit that hierarchy into our addressing scheme? Before we delve too deeply into this, we need to decide a couple of things. First, will we use fixed- or variable-length subnet masks? Using the “keep it simple” strategy, let’s try using the fixed mask approach, since it is easier to design and maintain.
Our next step is to decide on a mask to use. Looking at our class A subnetting tables in Chapter 2, we decide on 255.255.255.0. Could we have picked another? Sure, but most people would agree that 255.255.255.0 is the easiest mask to work with. The tables tell us we now have 65,535 subnets to work with, each supplying 254 addresses. This should work nicely. Now we have our IP address structure laid out before us:
Sixteen bits is represented in dotted decimal notation as two decimal numbers. Perhaps we can reduce the company network hierarchy to two levels: Region and Store. We can do this if we call the headquarters “Region 0.” Using this approach, we can try to make our IP addresses look something like this:
Let’s get down to business. In Table 3.3 we identified five different subnet groups. Looking at each group, we must decide on what the IP addresses should look like.
We stated that we should call the headquarters “Region 0.” There are 15 LANs in this group. Let’s use 10.0.L.0 for this group, where L is 0 for the backbone, and 1–14 for the administrative LANs. The LANs at the headquarters location are summarized in Table 3.5.
Again, there are a number of ways to assign this group of addresses. Let’s use 10.100+R.0.0 and 10.200+R.0.0 for the two WAN links to each regional distribution center. Here, R is the region number. Table 3.6 summarizes these assignments.
We don’t want to collide with the store LANs here, so we’ll start our allocation from the top of the list. The three DC LANs will be addressed using the forms 10.R.255.0, 10.R.254.0, and 10.R.253.0. Table 3.7 shows the plan.
|Region 1, Admin 1||10.1.255.1-10.1.255.254|
|Region 1, Admin 2||10.1.254.1-10.1.254.254|
|Region 1, Warehouse||10.1.253.1-10.1.253.254|
|Region 2, Admin 1||10.2.255.1-10.2.255.254|
|Region 2, Admin 2||10.2.254.1-10.2.254.254|
|Region 2, Warehouse||10.2.253.1-10.2.253.254|
|Region 18, Admin 1||10.18.255.1-10.18.255.254|
|Region 18, Admin 2||10.18.254.1 – 10.18.254.254|
|Region 18, Warehouse||10.18.253.1 – 10.18.253.254|
Following the lead of the HQ-DC links, the link from region R to store S will look like 10.100+R.S.0 (Table 3.8).
|Region 1 to Store 1||10.101.1.1 & 10.101.1.2|
|Region 1 to Store 2||10.101.2.1 & 10.101.2.2|
|Region 1 to Store 200||10.101.200.1 & 10.101.200.2|
|Region 2 to Store 1||10.102.1.1 & 10.102.1.2|
|Region 2 to Store 2||10.102.2.1 & 10.102.2.2|
|Region 2 to Store 200||10.102.200.1 & 10.102.200.2|
|Region 18 to Store 1||10.118.1.1 & 10.118.1.2|
|Region 18 to Store 2||10.118.2.1 & 10.118.2.2|
|Region 18 to Store 200||10.118.200.1 & 10.118.200.2|
Finally, we’re down to the largest group. Since this is the largest group, we’ll make these addresses as straightforward as possible. As we stated earlier, the LAN in store S in region R will have the address 10.R.S.0. Table 3.9 shows some samples of store LAN addresses.
Simplicity, ease of administration, and documentation. We’re using the same net mask (255.255.255.0) in every subnet. We have a single structure for each of the five types of subnets in our network. Because we are using private addressing, we have plenty of addressing space to work with. We have used this space to give our addresses some intelligence. Some noteworthy features of our plan are:
Router Efficiency. Will each router in the company’s internetwork need to list all 7305 subnets? We sure hope not! Our addressing scheme needs to allow for route summarization. To take full advantage of route summarization and keep our routing tables down to their absolute minimum size, the structure of our addresses needs to follow exactly the actual hierarchy of physical connections. Unfortunately, this is not the case with the addressing plan we have just developed. Let’s look again at the plan in Table 3.10.
In the ideal case, the corporate router would need to have only 19 entries: one for the corporate backbone, and one for each of the regions. To make that happen, all of the addresses associated with a region would have to share a common prefix. That is, they must all have the first several bits in common. This is not the case in our plan. For example, the distribution LAN in region 5 would have the address 10.5.255.0. The link from that distribution center to store 17 would be 10.105.17.0. The only prefix these two addresses have in common is the network ID (10) itself—not very helpful.
Does this mean we have to abandon our plan? No, it doesn’t. Although our plan is not ideal for route summarization, it well may be good enough. With some careful configuration of the regional routers, we can represent each region with three entries in the corporate router’s table. One entry would represent all of the DC and store LANs, and there would be one entry for each of the WAN links between the corporate router and the DC. The central router would then have less than a hundred entries in its routing table—a very reasonable number.
The routers at each distribution center would have an entry for each of the WAN links, store LANs, and DC LANs, totaling a bit over 400 entries. Current router technology is able to handle that number of entries very easily.
The designers of the Internet Protocol never dreamed that there would be millions of hosts on over 100,000 networks participating in the Internet. At the time, a fixed 32-bit address looked like it would be more than enough to serve the addressing needs of the Internet for years to come. And it has. However, as the Internet continues to grow, more and more pressure is being put on the user community to use globally-unique IP addresses efficiently. This pressure has lead to policy changes at the Internet Registries and to new techniques to conserve addresses.
A: Yes. Since the public and private addresses use different network prefixes, they will need to be on separate ports of a router. In other words, they would need to be separate subnets of your network. The devices with public addresses will be able to communicate on the Internet, those with private addresses will not.
A: Yes, you have two options. First, you can obtain public addresses and renumber your IP devices. Second, you (or your ISP) can implement Network Address Translation (NAT) to translate your private addresses to public addresses. NAT is covered in Chapter 4.
1. In our sample network, we were unable to maximize the benefits of route summarization because of the way we allocated the addresses. Without going to variable masks, design an addressing structure for our sample network that is completely hierarchical.
1. Use five or six of the 16 subnet bits to represent the regions. These bits will be the first bits in the subnet field. The remaining ten or eleven bits will represent the subnets in the region. For example, if we used five bits for the region ID and 11 bits for the subnet within the region, we can allocate 32 regions with 2048 subnets in each region. The addresses would line up like this:
2. Since private address blocks are not, by definition, globally-unique, there may be (and in fact are) many networks using the same addresses. If routing information about those networks or packets containing those addresses were allowed on the Internet, the Internet routers would become confused at best, misrouting packets. At worst, they would become hopelessly congested, causing massive communication failures.
3. By reducing the granularity of address allocation. Prior to CIDR, an organization was allocated 256 addresses (class C), 65,536 addresses (class B), or 16,777,216 addresses (class A). With CIDR, almost any number of addresses can be allocated, reducing the waste associated with the previous scheme.