In Figure 14-5, what if
• B’s best path to F is through C?
• C’s best path to F is through E?
• E’s best path to F is through D?
• D’s best path to F is through B?
Figure 14-5 Control Plane Routing Loop
Why would router E point toward D to reach server F rather than to F itself? When a network is running two different routing protocols—each protocol serving a different purpose— this kind of control plane routing loop is possible because neither protocol might completely understand the topology.
Humans also make mistakes.
If host A sends a packet to server F, the packet will be forwarded to C by B, then to E by C, then to D by E, then back to B by D, then to C by B, etc. Any packets A sends to F will be passed along this forwarding loop seemingly forever.
The job of time to live (TTL ) is to prevent routers from eternally forwarding packets in a loop like this.
When host A sends a packet, it includes a TTL in the packet header. Each router forwarding the packet subtracts 1 from (or decrements) the TTL. If a router reduces the TTL to 0, it will discard the packet rather than forward it.
If, for instance, host A sends a packet with a TTL of 5 toward server F:
1. Router B would decrement the TTL by 1 while processing the packet and forward it to C.
2. Router C would decrement the TTL by 1 while processing the packet and forward it to E.
3. Assuming router E’s routing table is incorrectly using router D for the next hop toward F, router E will decrement the TTL by 1, so it is now 2, and forward the packet to D.
4. Assuming router D’s routing table uses E as its next hop toward server F, router D will decrement the TTL by 1, so it is now 1, and forward the packet to E.
5. Router E will receive the packet, decrement the TTL by 1 so it is now 0, and discard it.
Internet Protocol Version 6
The engineers and scientists working on RFC 971, the first standardized version of IPv4, concluded a 32-bit address space would be enough. At the time, there were 4.5 billion people worldwide, and a 32-bit address space can support up to 4.3 billion addresses. The folks working on specifying IPv4 could not anticipate several things, however, including
• The commoditization of computer hardware and the accompanying explosion of smaller computers individual businesses and users could afford.
• The introduction of portable devices, such as cellular telephones and tables, which connect to the Internet.
• The connection of millions of “things” to the Internet, such as appliances and control systems.
• The amount of IP address space wasted through aggregation.
The IETF made several attempts to use existing IPv4 address space more efficiently, such as Network Address Translation (NAT). In January 2011, IANA allocated the last two address blocks to registries.
The only real solution was to design a new protocol with a larger address space.
IPv6 Goals
Internet Protocol version 6 (IPv6) was designed with a variety of goals, including
• Increasing the address space from 32 bits to 128 bits.
• Building autoconfiguration of devices into the protocol.
• Allowing extensions to the IP header.
• Eliminating NAT.
• Eliminating packet fragmentation.
Two of these goals are worth examining in a little more detail.
Autoconfiguration
Chapter 2 described how IPv6’s Stateless Address Autoconfiguration (SLAAC) works, but not why IPv6’s designers included autoconfiguration in the base protocol.
Renumbering entire networks full of thousands of devices is challenging. Even when using DHCP to configure devices, it can take months of planning, testing, and work to move from one set of IP addresses to another. Because renumbering is hard, network operators prefer not to renumber.
The difficulty of renumbering, however, must be balanced against the efficient use of the IPv6 address space.
Smaller organizations need smaller blocks of address space, which
• Are harder to aggregate, increasing the total number of routes carried by routers in the Internet core.
• Are difficult to recover when a smaller organization fails or no longer needs the address space.
It is more efficient for registries to allocate IP addresses to network providers, and network providers to assign address space to their customers. However, if smaller organizations are assigned addresses by their provider, they must renumber their networks every time they change providers.
In other words, provider-assigned (PA) addresses are more efficient for the global Internet, while provider-independent (PI ) addresses are more efficient for organizations building and operating networks.
Operators can resolve this tension using NAT. If an operator translates private internal addresses to external public addresses, they can change providers by changing the configuration on a few edge devices.
One of IPv6’s original goals was to eliminate NAT, so IPv6’s designers included autoconfiguration in the base protocol specification.
Autoconfiguration has not proven ideal in every situation, however. For instance:
• Autoconfiguration is still difficult to deploy in very large networks.
• Some organizations must legally be able to tie a specific IP address to a specific user.
• NAT arguably has some utility in network security.
• Tying a host’s IPv6 address to its physical address can have bad security side effects. An IPv6 version of Dynamic Host Configuration Protocol (DHCPv6) was developed and deployed to resolve some of these problems for large organizations, and NAT is still in widespread use.