Address Types
| Getting beyond the dramatic change in the size of the IPv6 address space, you can't help but be struck by the equally dramatic change in how address space is used. Rather than arbitrary allocations between block sizes, the IETF sought to carve the new address space into functional categories, each of which would enable more-efficient routing through a more-sophisticated hierarchy. These functional categories are known as anycast, unicast, and multicast. Noticeably absent was the broadcast address type. IPv6 doesn't use broadcast addresses, but it satisfies that function through the multicast address type. Throughout this book, we've looked at how IPv4's addressing system works. Implicit was that there were two types of addresses: those that get assigned to individual hosts to uniquely identify them and those that are used to forward data to multiple hosts (multicast). Well, IPv6 gives a name to the first type of address: unicast. IPv6 also preserves the concept of multicasting, albeit in a slightly different way. These two concepts (unicast and multicast) should be familiar enough by this point in the book that we don't need to rehash them here. Anycasting, however, is a completely new concept that is unique to IPv6. The need for anycast addresses became apparent after the successful commercialization of the Internet. Often-visited Web sites needed to be geographically dispersed to better service their user community without causing congestion in any one part of the Internet. That gave rise to the problem of how to address geographically dispersed but functionally equivalent hosts. The answer, anycasting, doesn't impose some of the delays of a DNS-based solution. It simply routes packets to the "nearest" host that has that address, as determined by whichever metrics the routing protocol uses to calculate routes to destination networks. AnycastAn anycast address is created simply: You assign the same unicast address to two or more IPv6 hosts. In theory, such hosts are functionally equivalent, and you would want to route packets to the "nearest" host. This works well in applications such as distributed Web sites. There is a tremendous variety of unicast address types. Anycast addresses can be created from any of them. Consequently, anycast addresses are numerically indistinguishable from unicast addresses. This necessitates a safeguard. Otherwise, anycast groups could be created by accident and could wreak havoc in the form of intermittent failures of specific hosts (those with the same address) within your network. The safeguard is that anycasting must be explicitly enabled on your router's interface(s). I would gladly provide you with the syntax required to accomplish this, but as of Cisco IOS Release 12.2(2)T, support for this feature has yet to be developed by Cisco Systems. Support has been promised for an as-yet unspecified future release. I have included coverage of anycasting in this chapter because it is a powerful and intriguing innovation. The fact that support for it has yet to appear in the IOS should tell you just how raw IPv6 is as a product, despite years of hype and development. MulticastSupport for multicasting, however, is better defined and implemented. Much like its IPv4-based counterpart, the IPv6 multicast address is an identifier that correlates to a list of unicast addresses that are logically linked for the purposes of receiving streams of multicasted information. All IPv6 multicast addresses begin with the binary prefix 11111111, or FF in hex. This prefix flags the entire address as being a multicast address. The complete structure of the IPv6 multicast address is as follows:
NOTE The Cisco Systems documentation on IPv6 multicasting uses the terminology "lifetime" for the 4-bit field that immediately follows the 8-bit multicast flag. If you check RFC 2373, you will see that this field is identified somewhat generically as "flags." Both are used for the same purpose, and Cisco adheres to the published format and use of this field. Just the terminology differs. This benign example demonstrates the potential for differences of interpretation that can exist between published specifications and product documentation. The notion of scope is interesting in that not all multicast codes are automatically assumed to be global. Rather, they can be limited in scope much the same way that unicast addresses are limited. That's something we'll look at in the next section. The scopes of multicast codes are listed in Table 15-2. Mathematically valid values not listed in the table are unassigned.
These scopes let you multicast to a predefined group of hosts on the same node, the same local-area network, within the same site, within the same private network, or anywhere in the Internet. You might question the logic behind having such limits for multicasting purposes, and you'd probably be right! However, these scopes make much more sense when you realize that broadcasting has been eliminated in IPv6. Instead of a discrete broadcasting mechanism, IPv6 uses reserved multicast addresses to broadcast to all hosts within specific scopes. The reserved all-nodes multicast addresses are listed in Table 15-3.
Unicast Address ArchitecturesThe unicast address type is remarkably specialized and warrants closer scrutiny. IPv4 featured an address architecture that differed only in the sizes of the routable portion of the address. In other words, the various classes and later classless blocks of network addresses all enjoyed the same functionality. This is no longer true in IPv6. IPv6 was designed with an eye toward functionality. Thus, no fewer than five distinct types of unicast address architectures were developed:
The following sections further describe these architectures in terms of their functionality and specific structure. Each one introduces several more hierarchical layers than can be found in IPv4. The purpose and benefits of these layers will be explained as we come to them. NOTE You might encounter references to other types of IPv6 unicast addresses that aren't listed here. Those addresses either are completely tangential to the content of this book (such as NSAP-compatible IPv6 unicast addresses) or are still being evaluated for possible development (such as IPX-compatible IPv6 unicast addresses). Others might have slipped into obsolescence and are no longer part of the protocol. One particular type to note is the former ISP unicast address. This type has been obsoleted. Its functionality has been both supplanted and augmented by the aggregatable global unicast address. Aggregatable Global UnicastCreated in RFC 2374, published in July 1998, the aggregatable global unicast address type was specifically designed to enable very efficient routing through the Internet. Of particular concern to the architects of this new protocol was the potential effect on routers and the Internet's routing efficiency. Let's face it: When you increase the length of an address by 400%, you probably also increase the memory consumption of routers that have to keep track of those addresses by the same percentagethat is, of course, unless you fundamentally change the nature of the address. This new type of address is far more hierarchical than the IPv4 address space. Its hierarchy contains several new fields that enable a tremendous improvement in routing efficiency. After we look at the structure of this new address type, it should be a bit clearer why routing efficiency improves despite the four-fold increase in the size of the addresses. The aggregatable global address contains the following data structures:
Looking over the structure of this unicast address type, you can see the logic behind the hierarchy. It is not unlike a postal address, except that in this address the specificity increases, whereas a postal address decreases in specificity as you advance through the hierarchy of the fields. In simpler terms, a postal address first identifies the specific recipient, then that recipient's street address, then the town in which that street is located, and then the state in which that town is located. The aggregatable global unicast address follows the same logic but inverts the pattern. It offers two fields (a total of 40 bits) for differing levels of hierarchy that directly facilitate the aggregation of routes into larger-sized address blocks. This tends to reduce the size of routing tables by eliminating specificity until it is needed. To make this seem a bit more real, imagine the TLA (Top-Level Aggregator) being used to identify a large corporation, such as the Acme Manufacturing Company. Acme is spread over several states and enjoys an extensive internal wide-area network (WAN). But it connects to the Internet at only one location. Acme has extended its network to an Internet exchange (MAE-West, for example). The world's Internet users can route to Acme using just its TLA field. That gets you inside its WAN, where the NLA (Next-Level Aggregator) is used to route traffic. The NLA could be used in a virtually unlimited number of ways, but for the sake of simplicity, let's assume that Acme uses the NLA to identify states within the U.S. Its WAN can then route traffic based on just the TLA and NLA. Once inside each state, traffic is routed to the specific destination site using the Site-Level Aggregation (SLA) identifier. The most specific portion of the address, the interface identifier, isn't used until after the traffic reaches the correct site. Aggregatable global addresses also offer benefits to those who choose to connect to the Internet via an ISP. Ostensibly, such customers use addresses that bear the ISP's identifier in the TLA rather than their own. The world's Internet users could have their traffic routed to any of that ISP's customers by using just that ISP's TLA. Today, individual address blocks must be tracked, which can get quite onerous. Thus, there is the potential for a tremendous reduction in the size of the Internet's routing tables. Link-Local-Use UnicastA concept first proposed way back in RFC 1597, and later updated in RFC 1918, was the notion of private IP addresses. We looked at these RFCs in Chapter 5. You saw that three distinct blocks of addresses were reserved for use in private networks. Ostensibly, this arrangement conserved address spaces by creating addresses that didn't have to be globally unique! You didn't need permission to use them; you just couldn't route them over the Internet. TCP/IP, as a protocol suite, was maturing, and it rapidly became a global de facto standard for network-based communications. But not everyone who needed TCP/IP to support an application also required access to the Internet. For those people and organizations, private addressing was perfect. It was a graceful way of making an existing protocol and address space go a little further with an absolute minimum of effort. IPv6 embraced the motivation behind these RFCs but solved the problem in a different way. The solution was termed the link-local-use anycast address. This ungainly name belies a simple concept: Use an endpoint's physical address (a Media Access Control [MAC] address) as the basis for a unique IP address that is valid only for local communications. MAC addresses are each globally unique, but they aren't a good basis for a routable internetwork address because of their relatively flat hierarchy. A MAC address contains only two componentsa hexadecimal serial number and a manufacturer identifierneither of which lends itself to routability in a network. The IPv6 link-local-use address contains three components:
The Interface Identifier can be based on an endpoint's MAC address (MAC addresses aren't 118 bits in length), but it doesn't have to be. The only requirement stipulated in RFC 2373 is that the Identifier must be unique on that link. Routers are not allowed to forward packets bearing this type of address in either their source or destination address fields. This limits the use of this address type to just a single LAN environment. Consequently, there is no requirement for global uniqueness with this address architecture, but addresses must be unique per link. This approach theoretically allows a conservation of address space by reserving a range of addresses (all starting with the binary string 1111111010) that can be used only for communications on a LAN. Please note that this string is just the prefix to the first 16-bit group of the IPv6 address (remember, IPv6 addresses are broken into eight 16-bit groups separated by a colon). Because this string is just 10 bits in length, the last 5 bits of the first 16-bit address group determine the Base16 symbol used to represent the total value of those bits. A potentially contravening argument can be made against the intent behind the purported benefit of this address type. The address space represented with this binary prefix is huge! RFC 2373 tries to mitigate the perception of overkill by stating that only 1/1024 of the IPv6 address space is allocated to link-local-use addresses, but a small percentage of a gigantic number is still a huge number. There is no escaping the basic fact that you don't need 118 bits to create a unique address within a LAN. You could probably accomplish that universally with less than 20 bits. Remember, the entire Internet is currently being serviced with just 32 bits of addressing. So 118 address bits for LAN addresses is ludicrously excessive! I'm reminded of the mind-set that existed when the IPv4 address space was first being allocated. The prevailing philosophy was that the address space was so huge relative to demand that it would never be depleted. With this simple philosophy, many an inefficient solution was rationalized and accepted. Only time will tell if history will repeat itself in this arena. Site-Local-Use UnicastAn alternative to the ISP unicast address type is the site-local-use unicast address. This type of address is specifically designed for organizations and/or enterprises that require IP and IP addresses for internal communications but that do not need to access the Internet. Ostensibly, a private but routable address type would keep routing very efficient across the Internet by reducing the number of addresses (routes) that routers in the Internet would have to track and maintain. Implicit in this description is the fact that the site-local-use unicast address is valid for use within only a single site. The question is, what constitutes a site? The site-local-use unicast address contains the following structure:
The functionality of this address type differs slightly from the link-local-use unicast in that routers may forward packets that bear either a source or destination address of this type. The caveat is that they cannot forward them out of the site! Figure 15-1 demonstrates the routability of this type of address. Figure 15-1. Routability of the Site-Local-Use IPv6 Unicast Addresses
You probably want to know what would happen if someone using this local-use address type later needed to connect to the Internet. Would he have to completely renumber? Would he have to set up an address translator? Well, I'm happy to tell you the IPng team has already thought through this dilemma. Site-local-use unicasts can be "upgraded" to a routable address by replacing the 10-bit local-use prefix with a routable ISP prefix. In theory, this makes for a very graceful migration path. I say "in theory" because I have yet to find anyone who has actually performed this upgrade. Still, it's reassuring to know that a complete renumbering isn't in store when you want to migrate from a site-local-use unicast to a globally routable address type. IPv4-Compatible IPv6 UnicastOne of the mechanisms established specifically to facilitate migration from IPv4 to IPv6 is the IPv4-compatible IPv6 unicast address. This type of address permits backward compatibility with any IPv4 addresses that might linger during or after a migration to IPv6. The way this address type works is quite simple, but it makes the most sense when you view its structure. This address type has three fields:
This address type is brilliant in its simplicity. The architects of IPv6 realized that one of the barriers to migration was the logistical nightmare of redesigning (and then implementing!) a new addressing scheme. This unicast address obviates the need to do that by allowing you to keep your existing IPv4 addressing scheme. Migration is made possible by prefacing an existing IPv4 address with 96 bits of 0s. In this manner, a barrier to migration is removed. It is important to notice that this type of IPv6 address doesn't spare you from the burden of renumbering. You still have to "renumber" each endpoint, but the logistics of renumbering become different. Typically, renumbering requires several steps:
Much of the work involved in implementing a new address space can be automated through a tool such as DHCP. Of course, some devices require static addresses or lack the intelligence to be able to use dynamic configuration tools. Thus, such tools are useful but not panaceas. Despite this caveat, it is easy to see that the vast majority of the effort in any renumbering process is expended up front in the planning stages. So, having a type of address that would greatly reduce the up-front planning requirements was seen as a real boon. IPv4-Mapped IPv6 UnicastAnother very interesting address type that was specifically designed to mitigate the pain of migration is the IPv4-mapped IPv6 unicast address. Despite a name similar to IPv4-compatible addresses (and an extremely similar data structure), this type of address is radically different. In fact, network administrators can't assign this type of address to endpoints! Instead, this address type provides backward compatibility with IPv4 addresses by enabling automatic tunneling of IPv4 packets through IPv6 network regions. This address type has the following structure:
If you missed it, the only structural difference between IPv4-mapped and IPv4-compatible unicast addresses are the values set to the 16-bit field. This unnamed field is set to high values (hexadecimal F) in the IPv4-mapped address and low values (hexadecimal 0) in the IPv4-compatible address. Otherwise, both address types feature a reserved and unused 80-bit field set to 0s, and both preserve the integrity of the original, premigration IPv4 address. The IPv4-mapped IPv6 unicast address differs functionally in that it is not assigned to endpoints in the network. Rather, it is constructed and used by routers that can communicate in both IPv4 and IPv6 as a means of transporting IPv4 packets (generated by IPv4-only endpoints) through an IPv6 network. How this works is illustrated in the next section. Comparing IPv4-Compatible and IPv4-Mapped AddressesIPv4-compatible and IPv4-mapped IPv6 addresses share a pair of commonalities:
Superficially, it might appear as if they are more similar than different. Their differences, however, are profound and lie in how they are used. IPv4-compatible addresses facilitate a migration by letting you "retain" your existing IPv4 addresses and addressing scheme by embedding them within an IPv6 superstructure. These are assigned to specific IPv6 hosts, which are then connected to an IPv6-capable network. Figure 15-2 demonstrates how this looks in a typical, but tiny, network. Figure 15-2. Using IPv4-Compatible IPv6 Addresses
Contrarily, IPv4-mapped unicast addresses can't be assigned to hosts, yet they play a vital role during the transition from IPv4 to IPv6. Given the nature of this type of migration, as well as the stubbornness of some types of addresses, it is highly probable that a migration will be quite lengthy and protracted. For example, you might never be able to "upgrade" the IP address on the management port of an older local-area network hub or switch. You are almost forced into accepting a dual-address environment for a long time. Thus, it was imperative for IPv6 to contain mechanisms to minimize the trauma of an extended migration. The IPv4-compatible IPv6 address is one such device. IPv4-mapped unicast addresses are constructed, as needed, by IPv4/IPv6 routers. In essence, the dual-protocol routers function as gateways between IPv4 and IPv6 network regions. They wrap an IPv4 address with an IPv6 packet and an address for transport through IPv6 networks en route to its IPv4 destination. Upon arrival at the far edge of the IPv6 network region, ostensibly at another router that is both IPv4- and IPv6-capable, the v6 portion of the address is stripped, and the original IPv4 addressing and packet structure are launched on the way to the address's final destination. A topological example of how this could work is illustrated in Figure 15-3. Figure 15-3. Using IPv4-Mapped IPv6 Addresses
This buys you the opportunity to upgrade your network in stages. First you could upgrade the backbone to IPv6, configure your routers to support the creation of IPv4-mapped unicast addresses, and then take the time to carefully plan the migration of the rest of your network. Such a migration might or might not feature the use of IPv4-compatible IPv6 addresses for the hosts at the edges of the network. |
EAN: 2147483647
Pages: 118