Additional Practice with CIDR

Please turn to Appendix E for several practice exercises to reinforce your understanding of CIDR.

New Solutions for Scaling the Internet Address Space

As we approach the turn of the century, the problems of IPv4 address shortages and expanding Internet routing tables are still with us. The good news is that CIDR is working. The bad news is that recent growth trends indicate that the number of Internet routes is beginning to, once again, increase at an exponential rate. The Internet must find a way to keep the routing table growth linear. The IETF is continuing its efforts to develop solutions that will overcome these problems, enabling the continued growth and scalability of the Internet.

Appeal to Return Unused IP Network Prefixes
RFC 1917 requests that the Internet community return unused address blocks to the Internet Assigned Numbers Authority (IANA) for redistribution. This includes unused network numbers, addresses for networks that will never be connected to the global Internet for security reasons, and sites that are using a small percentage of their address space. RFC 1917 also petitions ISPs to return unused network-prefixes that are outside of their assigned address blocks. It will be interesting to see how the Internet community responds since many organizations with unused addresses don't want to return them because they are viewed as an asset.

Address Allocation for Private Internets
RFC 1918 requests that organizations make use of the private Internet address space for hosts that require IP connectivity within their enterprise network, but do not require external connections to the global Internet. For this purpose, the IANA has reserved the following three address blocks for private internets:

10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Any organization that elects to use addresses from these reserved blocks can do so without contacting the IANA or an Internet registry. Since these addresses are never injected into the global Internet routing system, the address space can simultaneously be used by many different organizations.

The disadvantage to this addressing scheme is that it requires an organization to use a Network Address Translator (NAT) for global Internet access. However, the use of the private address space and a NAT make it much easier for clients to change their ISP without the need to renumber or "punch holes" in a previously aggregated advertisement. The benefits of this addressing scheme to the Internet is that it reduces the demand for IP addresses so large organizations may require only a small block of the globally unique IPv4 address space.

Address Allocation from the Reserved Class A Address Space
An Internet draft, "Observations on the use of Components of the Class A Address Space within the Internet" <draft-ietf-cidrd-classa-01.txt>, explores the allocation of the upper-half of the currently reserved Class A address space through delegated registries. As the demand for IP addresses continues to grow, it appears that it may be necessary to eventually allocate the 64.0.0.0/2 address space. Note that the 64.0.0.0/2 address block is huge and represents 25% of the IPv4 unicast address space.

Implications of Address Allocation Policies
An Internet draft , "Implications of Various Address Allocation Policies for Internet Routing" <draft-ietf-cidrd-addr-ownership-07.txt>, discusses the fundamental issues that must be considered as the Internet develops a new unicast address allocation and management policies. The draft compares the benefits and limitations of an "address ownership" policy with an "address lending" policy.

"Address ownership" means that when an address block is assigned to an organization, it remains allocated to that organization for as long as the organization wants to keep it. This means that the address block is "portable" and that the organization would be able to use it to gain access to the Internet no matter where the organization connects to the Internet. On the other hand, "address lending" means that an organization obtains its address block on a "loan" basis. If the loan ends, the organization can no longer use the borrowed address block, must obtain new addresses, and renumber before using them.

As we have seen, hierarchical routing requires that addresses reflect the network topology in order to permit route aggregation. The draft argues that there are two fundamental problems that break the hierarchical addressing and routing model supported by CIDR:

The continued existence of pre-CIDR routes that cannot be aggregated.
Organizations that switch ISPs and continue to use addresses from their previous ISP's address block. The new ISP cannot aggregate the old address block as part of its aggregation, so it must inject an exception route into the Internet. If the number of exception routes continues to increases, they will erode the benefits of CIDR and prevent the scalability of the Internet's routing system.

The draft concludes with the recommendation that large providers, which can express their destinations with a single prefix, be assigned address blocks following the "address ownership" model. However, all allocations from these providers to a downstream clients should follow the "address lending" model. This means that if an organization changes its provider, the loan is canceled and the client will be required to renumber.

This draft has generated a tremendous amount of discussion within the Internet community about the concept of address ownership and what it means in the context of global routing. The authors present a strong argument that the Internet has to make a choice between either address ownership for all or a routable Internet - it can't have both! Smaller organizations that want to own their addresses have concerns about the difficulty of renumbering and their lack of self-determination if their provider or their provider's upstream provider changes its provider. Finally, ISPs have concerns because the term "large provider" has not been defined. At this time, the discussion continues since any criteria recommended by the IETF is bound to be perceived as unfair by some!