Network Systems DesignLine | An IPv6 Refresher--Part I

July 24, 2006

An IPv6 Refresher--Part I

Excerpted from Deploying IPv6 Networks, Chapter 2--An IPv6 Refresher, this comprehensive multi-part series covers the concepts fundamental to undertsanding IPv6, including: the new addressing architecture, new header format and structure, enhanced functions of ICMP, and Layer 2 address-resolution mechanisms. Here is Part I.

By Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete

IPv6 represents an evolutionary step for IP. Despite building upon IPv4 and the experience gained operating IPv4 networks, IPv6 has its own idiosyncrasies and unique functionality implementations. For this reason, you should familiarize yourself with the fundamentals of the protocol prior to looking into deploying it. This chapter ushers you into the scope of this book by providing a brief refresher of key IPv6 concepts.

Many aspects of IPv6 set it apart from its predecessor. Some of these aspects are discussed in subsequent chapters from a deployment perspective. This chapter, however, focuses on a subset of IPv6 protocol characteristics that represent the foundation of its operation, as follows:

IPv6 addressing
IPv6 packet format
ICMPv6
Neighbor Discovery

This chapter particularly emphasizes addressing for a simple reason: It represents one of the most important benefits of IPv6 today. Neighbor Discovery is also discussed at length to clarify the link operation of IPv6.

Rather than repeating the information readily available in many books dedicated to describing the IPv6 protocols, this book focuses on reviewing the deltas from IPv4 and their impact on deployment. The following books are recommended for technology overviews: Cisco Self-Study: Implementing Cisco IPv6 Networks (IPv6) by R. Desmeules, and IPv6: The New Internet Protocol by C. Huitema.

IPv6 Addressing
Addressing is a fundamental aspect of the communication process between two or more entities. It provides the means to identify information sources and destinations while enabling dedicated resources to appropriately link the two groups together. This holds true whether we talk about the United States Postal Service or an IP network. The previous chapter briefly overviewed the IPv4 addressing structure and the challenges generated by a limited address space and its unwise use. The previous chapter also showed that the most compelling reason to adopt IPv6 is its addressing capabilities. It is natural, therefore, to make this topic a centerpiece of this IPv6 refresher.

IPv6 Address Representation
If we set aside the troubles that result from unplanned address assignments, we still face the inevitable exhaustion of the IPv4 addressing space. The 32- bit long IPv4 address offers roughly 2 billion practically usable IDs. This set will not be able to withstand much longer the growing needs of a rapidly increasing number of users who require unique, globally reachable IP addresses. The natural solution is to increase the address space. The 128-bit long addresses were selected despite more aggressive proposals put forward during the development of IPv6. One might find 2¹²⁸ or 340,282,366,920,938,463,463,374,607,431,770,000,000 addresses to be excessive. However, there was a time, not many years ago, when the same was thought of the IPv4 address space. On the other hand, one could argue that "the bigger the better." However, that line of reasoning should take into consideration the impact longer addresses have on system performance. A system using a 64-bit CPU, bus, or memory structure can process both the source address (SA) and destination address (DA) IPv4 addresses in one pass; whereas for IPv6 addresses, the same requires four passes.

The IPv6 address can be represented as a string of 0s and 1s. This representation is a rather long string, but it is the way favored by computers. A hexadecimal representation shortens the 128-bit string to 32 characters, and it appeals to programmers. This representation is still long enough to make it hard to remember, so the string of 32 hexadecimal characters was given some structure and segmented into 8 groups of 4 characters (or 16 bits) separated by a colon (:). The decimal representation, like the one used by IPv4 that everyone is familiar with, was not adopted by IPv6.

Two additional rules were introduced to further optimize the IPv6 address representation:

The elimination of leading 0s--Within each group of 16 bits between two colons, the leading 0s can be eliminated. This means that you can write :00A1: as :A1: (See Figure 1)

The elimination of consecutive 0s--You can collapse consecutive all-0 groups of 16 bits between consecutive colons. In this case, :0000:0000:0000: becomes :: (see Figure 1)

These rules must lead to a unique compressed representation of an address. For this reason, the consecutive-0s rule can be applied only once. It is incorrect to compress the address in the Figure 2-1 example to 2001::A1::1E2A. Someone looking at this address would not know whether the first :: stands for 2 or 3 groups of 16 zero bits.

It is important to mention that : is a meaningful character in the Uniform Resource Locator (URL), where it separates the port number from the address. To avoid confusion, RFC 2732 suggests to enclose the IPv6 address in a URL in brackets, as shown in Example 1.

Figure 1. IPv6 Address Representation

Example 1. Using an IPv6 Address Within a URL

IPv6 Address Architecture
Understanding the IPv6 address representation enables us to discuss the IPv6 addressing architecture defined in RFC 3513. Three types of IPv6 addresses have been defined:

Unicast--Identifies a single node, and traffic destined to a unicast address is forwarded to a single node.
Multicast--Identifies a group of nodes, and traffic destined to a multicast address is forwarded to all the nodes in the group.
Anycast--Identifies a group of nodes, and traffic destined to an anycast address is forwarded to the nearest node in the group.

All of these address types were present in IPv4, along with broadcast addresses. Broadcast traffic was shown to be too resource intensive (during regular operation as well as during broadcast storms), so IPv6 ignores it and uses multicast addresses instead.

A flat, structureless address space would require routers to keep track of every single host's location, leading to scalability issues. This problem can be resolved through address aggregation, grouping multiple addresses under a common representation. To facilitate this process, IP addresses are segmented in a network portion that identifies a logical group of hosts and a host portion that identifies the host within the group. Hosts are aggregated under the same network or prefix. IPv4 demonstrated the constraints of a class-based addressing architecture, so IPv6 allows variable lengths for the network portion of its addresses. This approach requires the length of the prefix to be identified by adding /(number of bits) to the address.

To maintain some parallelism between the addressing structure of the two IP versions, we used the IPv4 terminology host portion up to this point in the context of IPv6 addresses. IPv6, however, prefers to identify the interface of a host within a prefix rather than the host itself, which could have multiple interfaces. For this reason, the IPv6 addresses are segmented into a prefix or network portion and the interface identifier.

RFC 3513 leaves no room for doubt about what the interface ID should be: "For all unicast addresses, except those that start with binary value 000, interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." The rule reveals the intent to maintain a globally unique character for the interface ID whenever possible. You can generate an interface ID in many different ways:

The network portion of the address is further refined in the case of IPv6 to integrate the concept of scope.

The scope identifies a network domain, be it physical or logical. Being able to easily recognize the scope of an IP stream enables a network to better manage its resources by containing the traffic within the relevant domain and by applying policies relevant to that scope. The IP address is an essential element in making layer 3 forwarding decisions, so it should reflect the scope. Hosts would use he appropriate IP SA and DA for the scope of their communication.

In IPv6, the unicast address format reflects three predefined scopes, as follows:

These scopes are hierarchical, as shown in Figure 2. The global scope is larger than the local (site) scope, which in turn includes the link scope.

The link and global scopes represent the two extreme cases, the smallest and the largest scopes. This distinction makes it easier to define them. RFC 3513 identifies a site-local scope that fits logically between the link and global scopes, although its definition is open for interpretation. A site can mean different things to different people. It can be a corporate network, a geographically constrained portion of a corporate network, or simply an administered domain within a corporate network. Because IPv6 addresses are structured based on scope, the ambiguity in site definition increases the complexity of IPv6 features and implementations. The original definition of the site scope also left the door open for the use of nonunique site-local addresses with their drawbacks (discussed later in the section). For these reasons, on March 20, 2003, the IETF IPv6 working group deprecated the site-local scope and the corresponding IPv6 address type. Figure 2 emphasizes this point.

With habits being hard to break, especially when they prove to be operationally effective, the site-local scope and the site-local addresses did not go away quietly. Enterprises are accustomed to the safety and the advantages of a site-relevant, private addressing scheme--the good old 10.x.y.z network--so they pressed for the development of an alternate solution to the site-local address. To meet these demands, the IETF IPv6 working group defined a new scope and address type called unique-local, preserving the concept of a site scope by using local in its name while emphasizing the "nearly" uniqueness of the addressing used within the site.

Depending on an IPv6 node's complexity, it may or may not be aware of the scope information carried within the structure of a unicast address. Routers, however, must be aware of scoping to a certain degree because they have to keep traffic within the scope of its destination or source address. Because hosts typically communicate within more than one scope, interfaces have an address for each of the scopes used.

Embedding the scope information into the network portion of the IPv6 address adds to its complexity. The subsequent sections discuss the details of the actual implementation of scopes in unicast addresses.

Link-Local Addresses
When an IPv6-enabled node comes online, each interface is provided by default with a layer 3 address that can be used for communication exclusively with other hosts on the same link. The local link defines the scope of these addresses, so packets that have them as SA or DA should never be routed to other links. These addresses are called link-local. They are used for on-link communication as well as link operation processes such as finding neighbors or routers.

Figure 3 shows the structure of link-local addresses. A link-local address is made of a network portion of fixed format FE80::/10, where the high-level 10 bits are 1111 1110 10, and the subsequent 54 bits are 0.

As mentioned earlier, in IPv6 the interface identifier terminology is used instead of the host portion of the address, as shown in Figure 2-3. Example 2-3 shows the link-local address of an Ethernet interface with the interface ID generated based on the layer 2 MAC address.

Note: From a layer 3 standpoint, the link is the elemental domain, implying it does not have an internal hierarchy. This explains the flat structure of the link-local addresses.

It is important to note the fact that the link-local address, by its nature and format, is independent of the overall addressing scheme used in a network. This is consistent with its scope; the link-local address is not meaningful outside the link. For this reason, link local communication is not impacted during network renumbering. Its perennial property is leveraged by various protocols. Routers advertise their link-local address to all nodes on the link (see the "Neighbor Discovery" section later in this chapter), thus enabling them to communicate with a gateway regardless of the global unicast addressing scheme. This property of the link-local address is also actively leveraged in network design. Link-local addresses are used to identify a next hop whenever possible (a Border Gateway Protocol [BGP] neighbor, for example).

Unique Local Unicast Address
The concept of site scope can easily be mapped to that of a private administrative domain where addressing does not have to obey any global rules. The IPv6 addresses assigned to this scope as defined in RFC 3513 were called site-local, and they did not have to be unique. Their resemblance to the IPv4 private address space was a reminder of the drawbacks of such an approach (See RFC 3879). Some of he arguments against the use of site-local addresses are as follows:

Figure 4 shows the format of these addresses. The unique-local unicast addresses are fully standardized in RFC 4193.

The portion of the unicast address space reserved for unique-local addresses (ULAs) is FC00::/7. Figure 4 shows the structure of a ULA with the following elements:

ULAs have to be used within the confines of a predefined domain that represents the local scope of these particular addresses. Traffic using ULAs as either SA or DA should not be allowed to cross the boundaries of the domain. ULAs make it easy to interconnect distinct local domains because there are no address collisions.

Discontiguous site topologies are easier to manage. Routers connected to multiple sites can distinguish between them solely based on the address, thus avoiding the need for additional labels. These examples underline the benefits of the unique-local addressing versus the site-local addressing.

GGlobal Unicast Address
The global unicast addresses are defined for use across the IPv6 Internet. They are globally unique and globally routable. The IPv6 addresses reserved for global scoped communication are identified by their high- level 3 bits set to 001 (2000::/3), as described in RFC 3587.

IPv6's primary goal to provide plenty of globally accessible addresses is accomplished with the use of more address bits. The additional length could come at a cost by impacting routing processes through longer lookups, significantly larger routing tables, and larger routing updates (because many more networks are possible than with IPv4). Add to this the likely possibility that IPv6 networks are expected to have two or more coexistent addressing schemes and it becomes clear that IPv6 routers will need some help. One way to provide the needed relief is to implement and enforce strong rules on prefix aggregation. Such rules and policies would reduce the size of the routing table and the length of most of the prefixes populating them.

A lot of effort has been placed on developing a flexible structure for the GUAs that facilitates easy aggregation. Several attempts were made, starting with RFC 2373, to enforce a granular address structure reflecting various levels of aggregation. In the end, it was decided to enforce proper aggregation through rigorous allocation policies and settle for a simpler address structure, as specified in RFC 3587 and shown in Figure 5.

Global unicast addresses are likely to coexist with other types of unicast addresses on a given interface. For example, users within an enterprise need to exchange information within the private intranet and with resources on the Internet. This means that a host's interface within a private network could be assigned two addresses, one to be used to communicate with other hosts and resources within the private network (possibly a unique-local) and another to be used to communicate with hosts and resources outside the private network (global unicast). For operational and management purposes, a correlation between the elements of the various address types on an interface might make sense. In this example, the GUA and the ULA might use the same interface ID or even the same subnet ID.

Address allocation policies define the globally unique IPv6 address hierarchy. For this reason, it is important to briefly review them at this time. Pv6 Unicast Address Allocation
IANA is in charge of managing the IPv6 address space. Table 2-1 summarizes the assignments, at the time of this writing, from the global unicast address pool.

IANA is currently allocating unicast addresses from all the IPv6 Internet domains identified in Table 1.

After IPv4's transition from class-based to classless addresses, registries started to implement a hierarchical approach to address allocation. Larger address space is assigned to organizations (ISPs, governments, research networks, and so on), who in turn assign smaller pieces to their customers. This approach allowed for hierarchical routing, which is credited with a significant reduction in the size of the routing tables in core routers. A similar yet better-defined and stricter approach was adopted for IPv6. Earlier complex structuring of the IPv6 prefix in fields such as Top Level Aggregation and Next Level Aggregation has been replaced by the simpler format described in this section. IPv6 global unicast address hierarchy is enforced through IANA's allocation policy rather than fitting a predefined address format. Figure 2-6 exemplifies the address-allocation process for the 2001::/16 pool. IANA provides a prefix no longer than 32 bits to the Regional Internet Registries (RIRs).

The RIR allocates pieces of the prefix it received from IANA to National Internet Registries (NIRs; where present), to Local Internet Registries (LIRs), or Internet service providers (ISPs). These allocations are currently in the range of 32 to 35 bits in length.

As shown in Figure 2-6, each organization is assigned a prefix by the one above it and in turn is assigning prefixes to the one below it. Thus, each organization (IANA, RIR, NIR, LIR, and ISP) represents an aggregation boundary.

ISPs and LIRs keep track of the usage of their allocations with the help of the same metric used for IPv4, the host density (HD) ratio (defined in RFC 3194). ISPs/LIRs have to allocate prefixes in a way that prevents segmentation and allows for optimal use of aggregation. Such best practices enable them to make the most out of their address space. When justified, ISPs/LIRs can go back to the RIRs to request more allocations.

You can find a list of allocated prefixes from both the 2001:: and 3FFE:: space at CS-IPv6. Figure 7 presents a snapshot of this information for the sole purpose of exemplifying the allocation policies described in this section. NTT/VERIO is a service provider with global coverage, so it acquires prefixes from various RIRs. This example shows its 2001:218::/32 allocation received from APNIC. One of its customes is the Universisty of Leipzig, which was assigned the 2001:218:A20::/48 prefix. The university allocated a subnet, 2001:218:A20:FFFD::/64, t oone of its departments. It is interesting to note that a more practical allocation could be for NTT/VERIO to assign this European university a prefix from its RIPE NCC allocation 2001:728::/32.

IPv6's method of implementing address hierarchy through allocation policies leads to a subtle but important departure from the traditional IPv4 address-management concepts. At the time of this writing, in the case of IPv6, an enterprise no longer owns its global address space. The address space it is using is a subset of their ISP's allocation. This means that an enterprise will have to go through network renumbering every time it changes ISPs. Despite IPv6's features that make renumbering easier, this process would carry an operational impact.

Because IPv6 interfaces can support multiple unicast addresses, the migration from one ISP to another one can be done through a transient period where the prefixes from both old and new ISPs coexist on the customer network. Operational experience for this type of situation still needs to be developed to evaluate the impact on medium- and large-size enterprises when switching between IPv6 ISPs. Nevertheless, as enterprises become interested in IPv6, this aspect of address management is often listed as a major concern. For this reason, large, multinational enterprises started to get involved in policy meetings of the Internet registries, lobbying for changes to the allocation mechanisms.

About the Authors
Ciprian Popoviciu is a technicala leader at Cisco with more than eight years of experience designing, testing, and troubleshooting large IP networks. He currently focuses on the architecture, design, and test of large IPv6 network deployments in direct collaboration with service providrers worldwide. Ciprian holds a bachelor of science degree from Babes-Bolyai University, a master of science degree and a doctorate degree in physics from the University from the University of Miani.

Eric Levy-Abegnoli is a technical leader in the IP Technologies Engineering Group at Cisco Systems, where he is the technical lead for IPv6 development in IOS. Before joining Cisco, Eric worked for IBM, where he successfully led a development team in the Networking Hardware Division and a research team at the Thomas J. Watson Research Center, focusing on networking and content delivery platforms. Eric received the Diplome d'Ingenieur from the Ecole Centrale de Lyon, France.

Patrick Grossetete, manager of product management at Cisco Systems, is responsible for a suite of Cisco IOS software technologies including IPv6 and IP Mobility. He is a member of the IPv6 Forum Technical Directorate and manages Cisco's participation in the Forum. In June 2003 he received the "IPv6 Forum Internet Pioneer Award," at the San Diego Summit. He received a degree in computer technology from the Control Data Institute, Paris, France.

To contact the author, please email: reviews@ciscopress.com and use Deploying IPv6 Networks/post question as the subject line. Title: Deploying IPv6 Networks. ISBN: 1-58705-210-5 Authors: Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete. Chapter 2: An IPv6 Refresher. Published by Cisco Press

Reproduced from the book Deploying IPv6 Networks. Copyright [2006], Cisco Systems, Inc. Reproduced by permission of Pearson Education, Inc., 800 East 96th Street, Indianapolis, IN 46240. Written permission from Pearson Education, Inc. is required for all other uses.

*Visit Cisco Press for a detailed description and to learn how to purchase this title.