|
|
Unicast ConnectivityThe delivery of IP services relies on an infrastructure that provides unicast connectivity between IP hosts. The foundation of such an infrastructure consists of three elements: addressing, routing, and forwarding. IP addresses represent a finite resource used in identifying hosts within private or global networks. The structure and allocation mechanisms of IP addresses are relevant in designing, deploying, and operating IP networks. A review of this topic is compelling; especially under the circumstances of a depleting IPv4 address space. After all, at the time of this writing, addressing is one of the main reasons for deploying IPv6. Routing and forwarding provide the mechanisms to move traffic between IP hosts. Whereas forwarding's dependency on IP version is relatively straightforward, routing has multiple dependencies on addressing. For this reason, it is important to see whether any of the IPv4 routing challenges were resolved in IPv6. AddressingIP addressing is a vast topic that influences most of the protocol layers and most of the services. It also represents a critical resource. This section briefly discusses address architecture and address allocation. For a complete and detailed presentation, the following books are helpful references:
IPv4 Address ArchitectureA little bit of history is necessary to understand the debate around the IPv4 address space depletion. An address is used to uniquely identify hosts within the network. Even in a flat nonhierarchical simple world, some minimum requirements on the address structure enable network elements to operate efficiently. In IPv4, the address has a fixed size of 32 bits. That would allow in theory up to 232 addresses or somewhere around four billion. It is important to note that at the time of its specification, these four billion possible addresses appeared to be more than adequate for years if not centuries to come. As soon as early 1990s, however, the Internet community had to introduce a number of changes in the address architecture and the address-allocation scheme to accommodate growing address needs. IPv6, which is based on 128-bit-long addresses, appears to be safe for centuries to come, but who says that history cannot repeat itself? A considerable waste of IPv4 addresses was generated by two factors:
The increasing number of hosts challenged the address space resources and led to the formalization of private addressing and Network Address Translation (NAT) as an address-conservation solution. The increase in the number of hosts is also matched by an increase in the number of networks and this leads to scalability problems for the routers. In 1994, the core routers had approximately 34,000 routes, doubling every year. By 2004, it was expected to reach millions routes. Variable-length subnet mask (VLSM), Classless Inter-Domain Routing (CIDR), and a new IP address-allocation strategy was the response to the routing table explosion. Although the core routing table size was predicted to grow from 34,000 to 80,000 between 1994 and 1995, in fact it reached 76,000 routes only in 2000 and about 160,000 in mid 2004. With IPv6 and its larger address space, one could fear that routing tables will further expand. Bigger addressing space might logically lead to more hosts followed by more networks. In reality, past experience has shown that the "number of hosts" and the "number of networks" are loosely related. With the proper aggregation mechanisms, partly driven by the right address-allocation strategy, the latter have been well under control. Assuming the same mechanisms are maintained and further enforced with IPv6, it is reasonable to believe that routing table size will remain within manageable limits. Note For more details on CIDR, and related topics, you can read the following RFCs: RFC 1517, RFC 1518, RFC 1519, and RFC 1520. Also, RFC 1887 provides some hints on the reasoning behind IPv6 address allocation, and architectural implications. The address-conservation mechanisms cannot stave off for long the need for global IP addresses. Past and current Internet growth rates (source BGP table statisticshttp://bgp.potaroo.net/) can be extrapolated to predict the time left before the complete exhaustion of all available IPv4 address space. Conservative studies estimate the IPv4 address-space exhaustion by February 2041, and the exhaustion of the IPv4 unallocated address pool by April 2020. More aggressive models predict even earlier dates such as 2009. These predictions are based on the underlying assumption that the current growth models will remain applicable for years to come, which is not necessarily accurate. IPv6 might change these assumptions. With the combination of the Internet as an attractive and accessible communications medium, and the emergence of communicating gadgets and devices of all kind (even the most unexpected ones such as phones, home appliances, cars, and so on) you must be ready to see them proliferate and stimulate a growth in Internet usage that cannot be extrapolated from past patterns. Private Versus Public AddressesPublic addresses are registered, globally unique, and can be used to provide reachability over the Internet. By contrast, private addresses are meaningful only within a closed, physical or virtual domain. In IPv4, private addresses have been always associated with unregistered addresses, which in return have been associated with nonunique addresses. There might be many reasons why an organization would want to use both public and private addresses. Public addresses are used to get connectivity across the Internet, to reach public resources. Private addresses are used to accomplish the following:
RFC 1918 identifies two categories of hosts that could deal with private addresses:
For these two categories, RFC 1918 further defines three blocks of private addresses that should not be routed over the Internet, and therefore free to replicate.
In an ideal world, privately addressed hosts would be confined to the private network, whereas only hosts with public addresses would be able to access the public domain. In reality, most hosts need to leave the private network boundaries at some point. Usually, there are not enough public addresses for all hosts in the private network, so further mechanisms are necessary to interface them with the public domain. The simplest one is NAT, discussed in the section "Network Address Translation." One of the benefits of the private address space is the large number of addresses available at the discretion of an enterprise. It was, however, only logical to expect that the private address space will face depletion similar to the overall IPv4 address space. In 2005, multiple-systems operators (MSOs; or cable operators) reported the fact that they are running out of private address space. This is due to the proliferation of cable modems, Voice over IP (VoIP) phones, and set-top boxes they have to manage over IP. This realization accelerated their plans to deploy IPv6 if not to provide services at least to manage their devices. Some of the reasons to use private addresses become obsolete with IPv6 (there are now plenty of public addresses for everyone) although others will remain. VPN solutions exist for IPv6, too, and that could be sufficient to safeguard the privacy of addressing used within a network. The plethora of IPv6 addresses had suggested some different paradigms for private addressing, in particular the concept of unique yet private address. These concepts are presented in Chapter 2, "An IPv6 Refresher." The concepts and issues that arose when crossing the boundary between private and public domains are presented in Chapter 7, "VPN IPv6 Architecture and Services." Static Versus Dynamic AddressesAddresses can be assigned to IP nodes either statically or dynamically. The static addresses are allocated "indefinitely" or until explicitly removed. Dynamic Host Configuration Protocol (DHCP) allows a computer to have a different IP address each time it connects to a network. This process enables multiple users to overload the use of a pool of dynamically assigned addresses. DHCP also enables mobile hosts to attach to visited subnets without requiring manual reconfiguration. In reality, dynamically allocated addresses might not change often either. In large networks, DHCP servers tend to allocate the same address to the same host over time, unless there is some shortage. For the home environment, there are two categories of users:
There are now advantages and disadvantages with the trend to use more stable source addresses than there were in the past. From a network operation perspective, one could find useful that the same user stays behind the same IP address; it is easier to manage, bill, filter, authenticate, and so on. However, this operational model eliminates address reuse, which conserves the IPv4 address space. For this reason, broadband services are a significant catalyst in the acceleration of IPv4 address consumption. When the address-shortage concerns are eliminated with the adoption of IPv6, there could be a tendency to allocate static addresses, or allocate dynamically the same address to the same user all the time. The advantages of having the IP address uniquely and permanently identify the device are counterbalanced by possible privacy issues. The same address used in multiple contexts (for instance, web surfing, gaming, and so on) can be used to correlate seemingly unrelated activities. Note that with IPv6, which offers the possibility of using addresses that embed topological information such as link identifier, the concern will grow. The mechanisms to allocate IPv6 addresses dynamically are reviewed in Chapter 3, "Delivering IPv6 Unicast Services." RenumberingWant to know a network administrator's worst nightmare? It is renumbering. Renumbering is the process of replacing existing network prefixes and host addresses considered as deprecated throughout the network with new ones. There can be a large variety of reasons for renumbering:
The complexity of the renumbering process comes from the fact that addresses are used in many different places within a network and for many different reasons. A single address or a set of addresses may have been configured statically or dynamically in various places such as the following:
Sometimes, simply changing the old address can make the new one operational; in many cases, however, the old address has been leaked in caches of all kinds (DNS caches, applications caches, routing caches, web caches, Address Resolution Protocol [ARP] caches). Many of these caches have expiration timers, which will make them invalidate the "old" addresses, but some do not. In most cases, changing the address and network prefix requires rebooting the host. When addresses are cached throughout the network, delays (mostly "uncontrolled") will occur before the new addresses are operational. Although some believe that renumbering issues have been entirely taken care of in IPv6, others believe that renumbering remains a problem without any good solution. The truth lies somewhere in between. The renumbering issue is multidimensional, and IPv6 brings some innovative solutions in some areas, although it does not solve the entire problem. Chapter 2 and Chapter 3 describe some built-in IPv6 mechanisms such as link-local addresses, autoconfiguration, and support for multiple addresses on the same interface that can ease aspects of network renumbering. Network Address TranslationNetwork Address Translation (NAT) has brought the best and the worst to IP deployments. Per NAT RFC authors, NAT was a short-term solution to enable address reuse and solve the address-depletion issue the IP Internet community was anticipating in 1993. That worked out well indeed, and what seemed to be a critical issue in 1993 is less critical more than 10 years later. NAT has enabled private addressing in all sorts of corporate networks, eliminating the need for publicly registered chunks of addresses. Nevertheless, NAT is a controversial subject in the networking community, and for that reason we dedicate this section to it. For technical background and more details on NAT principles and operations, refer to RFC 1631 and books such as the Cisco Press book Routing TCP/IP, Volume II (CCIE Professional Development) by Jeff Doyle. Over the years, NAT has been deployed widely throughout the Internet. During this time, its use was given justifications beyond address conservation: from security to privacy, from preventing renumbering to providing high-availability mechanisms, from deployment of virtual clusters to providing Internet access over VPNs. Each of these justifications was prompted by some deployment scenario and was meant to solve deployment issues. Although some of these reasons will become irrelevant after IPv6 is deployed, not all of them will. Although NAT has hurt the deployment of many applications, and many people would be happy to see this so-called "short-term" solution go away with IPv6, it will be interesting to understand and analyze NAT's place in today's networks and the problems it addresses. If we want to rid the world of the evil NAT, we must make sure IPv6 offers solutions for all problems NAT resolved. NAT comes with a number of issues, out of which the most significant is the connection model that it implies. NAT is asymmetrical. Because of the way NAT works, it is mainly usable for client/server sessions where clients within the private network initiate the session with servers sitting in the public network. The client will typically issue a Domain Name System (DNS) query for some public server name, and get the public server address. On the way back, the server will see only the public NAT address, expectantly a globally reachable one. Going the reverse direction is more troublesome. Anybody sitting outside the private network (either on the public network or on a different private network) would have difficulties reaching a host behind NAT. Some proxy servers can be used as "middlemen": They can handle all necessary application signaling and enable hosts to use each others NAT addresses as the reachable public address. Session Initiation Protocol (SIP) is a good example of such a solution. However, twisting every single peer-to-peer application to make it fit the client/server model appears to be a great limiting factor to the adoption and deployment of new applications. Another issue with NAT is that it does not look at any information above IP/TCP/UDP/ICMP layers. Some applications have endpoint source addresses buried within their messages, which do not get translated by NAT at the same time as the IP header addresses. This typically happens with applications such as H.323 that tend to establish multiple connections within a single session. To solve those issues, application layer gateways (ALGs) may need to perform complex application-level translations. When an application that required an ALG is deployed, NAT devices must support this particular ALG. NAT has some security issues, too. Any security mechanism based on signing or verifying part of the packet, whether header or payload including IP addresses, will have trouble when addresses are overwritten. For instance, with IPsec, both Authentication Header (AH) and Encapsulating Security Payload (ESP) have issues with NAT, although at a different order of magnitude. Can IPv6 Eliminate NAT?NAT is used in the networks of 70 percent of Fortune 1000 companies, for better and worse. So, either NAT is not necessary anymore after IPv6 is deployed, and the worst is gone. Or, IPv6 does not have a proper solution for all deployment scenarios where NAT is in use and these networks will not transition. Although the large IPv6 address space eliminates the need for NAT, it is important to explain how IPv6 also provides similar capabilities as the "perceived" benefits of NAT. This is the main purpose of Network Architecture Protection (NAP), an Internet Draft addressing each NAT benefit (real or perceived) and matching it with an IPv6 solution. Table 1-1 lists NAT features, and for each, it provides pointers to IPv6 documentation (RFC, Internet Drafts, and so on) and refers to chapters of this book where solutions are reviewed.
In addition to verifying that IPv6 deployments do not create issues in areas where NAT has a specific purpose, you will also have to examine coexistence issues. Because IPv4 and IPv6 are likely to cohabit for a significant period of time, you need to know whether there are any IPv6 deployment issues with regard to traversing IPv4 NATs. Indeed, many of the transitioning mechanisms that Chapter 3 describes involve tunneling IPv6 traffic over IPv4. These IPv4 networks are full of NAT, and being able to properly traverse them is critical to IPv6 deployment. RoutingThe engineering community has not really touched the routing foundations of unicast services in the context of IPv6. Of course, whenever an IPv4 routing protocol had some dependencies on IPv4 addresses, work was done to produce an IPv6 version of it. This is the case, for instance, with OSPFv3. Chapter 4 "IPv6 Routing Protocols," reviews these changes in the routing protocols. But besides "cosmetic differences," all IPv4 routing protocols are closely matched in IPv6, sharing the same design, often the same implementation, with the same area of applicability and the same issues. In IPv6, you will find the familiar Routing Information Protocol (RIP), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), and Border Gateway Protocol (BGP). Are you disappointed? You might have expected the IPv6 designers to take advantage of the new address structure to enhance the way routers handle network prefixes to achieve better aggregation. This would have indirectly led to new or significantly modified routing protocols. The opportunity was offered in the way the IPv6 address was structured. RFC 1887 describes some early attempts to form a hierarchical routing system, and RFC 3513 structures the IPv6 unicast address to enable efficient routing aggregation. So far, these attempts have not materialized into an innovative routing protocol. CIDR with BGP aggregation and allocation policies remain the solution for optimizing aggregation in IPv6, too.  |
|
|