Chapter 3: Private Addressing and Subnetting Large Networks – IP Addressing and Subnetting INC IPV6

Chapter 3

Private Addressing and Subnetting Large Networks

Solutions in this chapter:

 Discover the motivation for using private addresses

 Calculate address allocation efficiency

 Examine RFC 1918 private address ranges

 Develop strategies for subnetting private addresses

Introduction

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.

Strategies to Conserve 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:

 CIDR

 Variable-Length Subnet Masking (VLSM)

 Private Addressing

CIDR

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.

VLSM

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.

Private Addresses

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.

Addressing Economics

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.

Figure 3.1 A sample network.

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.

For IT Professionals

Using Frame Relay Networks as WAN Technology

When you use Frame Relay networks as your WAN technology, the entire Frame Relay “cloud” is one subnet, and each router interface will have an address appropriate for that subnet.

Table 3.1 lists the various subnets and the addressing requirements for each.

Table 3.1

Sample Network Addressing Needs

Location # Subnets # Hosts
Headquarters 1 50
  1 110
  1 190
  1 150
  1 150
Branches 60 30
WAN Links 60 2

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.

Table 3.2

Sample Network Address Analysis

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.

If we could use VLSM, the subnets would be sized more appropriately, but the larger problem remains. We would still be using only about 4 percent of our total class B space.

An Appeal

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:

1. If you aren’t going to connect to the public Internet, you don’t need globally-addresses. Use private addresses instead.

2. If you have a portable block of addresses, return the block to the IANA and use addresses supplied by your upstream Internet Service Provider.

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.

Public vs Private Address Spaces

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

NOTE

More information about the ICANN can be found at www.icann.com.

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.

Can I Pick My Own?

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:

1. Most organizations will eventually choose to implement some kind of connection to the Internet—if for no other reason than to exchange e-mail.

2. There may be a merger or acquisition in your future that might require joining your network to one or more other networks.

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 207.46.130.0 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.

Figure 3.2 The danger of picking your own addresses.

The class C address 207.46.130.0 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 207.46.130.14. 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.

The lesson here is that there is a risk in dreaming up your own IP addresses—even if you never intend to connect to the global Internet.

RFC 1918—Private Network Addresses

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.

NOTE

Not everyone agreed with this plan. The authors of RFC 1627 (June 1994) complained that an Internet policy decision was made without the normal peer review and public comment process. They also pointed out that the original ideal of the Internet architecture, worked out over decades, was to have every host uniquely addressable. They argued that RFC 1597 violates this ideal. Ultimately, of course, the proponents of private addressing prevailed.

In February 1996, RFC 1597 was updated and made obsolete by RFC 1918, and was assigned the “Best Current Practice” status.

The Three-Address Blocks

RFC 1918 designates three ranges of IP addresses as private:

 10.0.0.0–10.255.255.255

 172.16.0.0–172.31.255.255

 192.168.0.0–192.168.255.255

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.

The second block is called a 20-bit block and is equivalent to 16 traditional class B networks, or a /12 block in CIDR terminology. This block contains 1,048,576 addresses.

Finally, the third block is known as a 16-bit block and is equivalent to 256 class C networks. This 16-bit prefix supplies 65,536 different IP addresses.

Table 3.3 summarizes the private address blocks defined by RFC 1918.

Table 3.3

Private IP Address Blocks

Considerations

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.

Here are some things to think about when deciding to use private addressing in your network:

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.”

For Managers

Security Breaches from Within

Although the preceding information about security and privacy may be comforting, don’t let it lull you into complacency. Security experts estimate that anywhere from 50 to 70 percent of all attacks on computer systems come from inside the organization. Private network addressing cannot protect against insider attacks.

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.

Which to Use When

According to RFC 1918:

“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.

Strategy for Subnetting a Class A Private Network

When it comes to developing an addressing plan for a private network, the rules are exactly the same as for any other IP network. Our goals for the addressing plan are as follows:

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.

Ease of Administration. We want the plan to be easy to implement and maintain. The plan should allow room for anticipated growth and, if possible, make room for unanticipated growth or other changes.

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.

Documentation. We want to be able to describe the plan in a few short statements without a lot of explanations.

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

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.

The headquarters campus has 14 LANs connected by routers to the corporate backbone network. The largest of the headquarters LANs has 230 IP devices on it.

Figure 3.3 shows a high-level overview of the corporate network. We can summarize the addressing needs of the network in Table 3.4.

Table 3.4

Sample Network Addressing Analysis

Location # Subnets Max Addresses
Headquarters LANs 15 230
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

Figure 3.3 A large network.

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

The Strategy

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.

Now that we know we have 24 bits to work with, how shall we allocate them? We look for clues in the structure of the network we are studying. There seem to be three levels of hierarchy:

 Headquarters

 Distribution Centers

 Stores

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:

 Network ID: 8 bits

 Subnet ID: 16 bits

 Host ID: 8 bits

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:

10.R.S.Hwhere R is the region number, S is the store number, and H is the host ID. If we can make this work, the IP addresses will be almost self-documenting—a very desirable feature indeed.

Address Assignment

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.

The Headquarters LANs

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.

Table 3.5

Headquarters Subnets

Description Address Range
Backbone 10.0.0.1–10.0.0.254
LAN 1 10.0.1.1–10.0.1.254
LAN 2 10.0.2.1–10.0.2.254
LAN 14 10.0.14.1–10.0.14.254

The WAN Links from Headquarters to the Distribution Centers

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.

Table 3.6

Headquarters WAN Links

Description Addresses
HQ to Region 1 10.101.0.1 & 10.101.0.2 10.201.0.1 & 10.201.0.2
HQ to Region 2 10.102.0.1 & 10.102.0.2 10.202.0.1 & 10.202.0.2
HQ to Region 18 10.118.0.1 & 10.118.0.2 10.218.0.1 & 10.218.0.2

The Distribution Center LANs

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.

Table 3.7

Distribution Center Subnets

Description Address Range
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

The WAN Links from the DC to the Stores

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

Table 3.8

Distribution Center WAN Links

Description Addresses
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

The Store LANs

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.

Table 3.9

Store Subnets

Description Address Range
Region 1, Store 1 10.1.1.1-10.1.1.254
Region 1, Store 2 10.1.2.1-10.1.2.254
Region 1, Store 200 10.1.200.1-10.1.200.254
Region 6, Store 107 10.6.107.1-10.6.107.254
Region 18, Store 5 10.18.5.1-10.18.5.254

Results

The plan seems to work. Here again are the goals we established earlier, and some discussion of how well our plan meets the goals.

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:

1. Any address with a zero in the second byte refers to a device at the headquarters location.

2. Any address with a three-digit value in the second byte refers to a WAN link between a distribution center and either a store (third byte > 0) or the headquarters location (third byte = 0).

3. All other addresses refer to devices on LANs either in the DC or in a store.

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.

Table 3.10

Sample Network Address Structure

Subnet Group IP Address Structure
Headquarters LANs 10.0.1.0-10.0.15.0
HQ - DC links 10.100 + R.0.0
DC LANs 10.R.253.0-10.R.255.0
DC - Store links 10.100 + R.S.0
Store LANs 10.R.S.0

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.

Given that the routers will not be overwhelmed by the routing table sizes, and given that the addressing plan presented has some desirable features, we will go ahead and deploy the plan as presented.

Summary

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.

One of those techniques is to use private addresses, as specified in RFC 1918. There are both benefits and drawbacks to using private addresses.

FAQs

Q: How do I know which one of the private address blocks to use?

A: Unless there is a good reason—such as a specific learning objective, or to force your router into certain behaviors—use “network 10.”

Q: Can I use VLSM in private networks?

A: Absolutely! There’s no harm in using addresses wisely, even if you have a very large supply.

Q: Why is network 10 included in the private address ranges?

A: Class A network 10 was the address used by the old ARPANET, the precursor of today’s Internet. Network 10 was decommissioned in the 1980s and we use it today to honor its auspicious beginnings.

Q: Can I use private addresses and public addresses in my network?

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.

Q: I’ve got a network with private addresses. Now I want to connect to the Internet. Can I?

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.

Exercises

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.

2. Why should ISPs filter out any references to private address blocks?

3. How does CIDR contribute to address allocation efficiency?

Answers

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:

Headquarters: 10.0.0.0 through 10.7.255.255

Region 1:10.8.0.0 through 10.15.255.255

Region 2:10.16.0.0 through 10.23.255.255, etc.

This plan would be efficient (from the router’s point of view), but not very intuitive.

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.