July 28, 2006

An IPv6 Refresher--Part II

Excerpted from Deploying IPv6 Networks, Chapter 2--An IPv6 Refresher, Part II concentrates on special use addresses, IPv6 Anycast Addresses, Multicast Addresses, IPv6 and Layer 2 Addressing and IPv6 Addressing Architecture at a Glance.

By Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete

Miss Part I? No need to search--it's right here.

Special-Use Addresses
At last, a small set of unicast addresses have been defined for special use. They do not carry a scope, so they are discussed independently of the other unicast addresses.

Two basic addresses carry IPv6 operational significance:

• The unspecified address is not assigned to any interfaces. However, it is used as an SA by devices that do not have an IPv6 address or their IPv6 address has not been yet proven to be unique within the local link. The unspecified IPv6 address has all 128 bits set to 0. It can be represented as 0:0:0:0:0:0:0:0, or as :: in compressed form.
• The loopback address is used by every node to refer to itself, and it is similar to the 127.0.0.1 address in IPv4. In IPv6, the loopback address has all the 127 leading bits set to 0, and the last bit is 1. It can be represented as 0:0:0:0:0:0:0:1, or as ::1 in compressed form.

The other two special address types relate to the coexistence of IPv4 and IPv6. Linking the two address spaces is important to support various aspects of this coexistence. Two mechanisms were developed to map IPv4 addresses into IPv6 addresses:

• The IPv4-compatible IPv6 address was defined to be used for dynamic tunneling and is built by adding the IPv4 address to 96 bits set to 0. This address type was deprecated and it is no longer used.
• The IPv4-mapped IPv6 address is used to represent the address of an IPv4 node in an IPv6 format. The IPv4-mapped IPv6 address is built by adding the IPv4 address to 80 bits set to 0 followed by 16 bits set to 1.

Example 4 shows the IPv4-compatible and the IPv4-mapped IPv6 addresses corresponding to the IPv4 address 192.100.10.1.

Example 4. Examples of IPv4-Compatible and IPv4-Mapped IPv6 Addresses

Table 2 summarizes the representation of these special addresses.

Table 2. Special-Use Addresses

IPv6 Anycast Addresses
When the same unicast address is assigned to multiple interfaces, typically belonging to different nodes, it becomes an anycast address as specified in RFC 3513. Because anycast addresses are structurally indistinguishable from unicast addresses, a node has to be configured to understand that an address assigned to its interface is an anycast address. A packet with an anycast DA is routed to the nearest interface configured with it. An anycast address cannot be used as the SA of a packet. Anycast is often used to virtually replicate important network resources, such as Domain Name System (DNS) root servers, web servers, and multicast rendezvous points (RPs), thus providing a level of redundancy and load sharing. IPv6 went beyond this concept that is currently used by IPv4 in that it defined a set of reserved addresses for each unicast prefix to facilitate the future use of anycast.

The subnet-router anycast address is defined by RFC 3513 for every prefix as the address with the interface ID set to 0. A router has to support the subnet-router anycast addresses for all the prefixes configured on its interfaces. A packet destined to such an address will be delivered to the nearest router that has an interface with that prefix.

RFC 2526 defines an additional set of anycast addresses reserved for a given prefix. Figure 8 shows the structure of these anycast addresses.

Figure 8. IPv6 Reserved Anycast Address Format

The address format makes clear the intent of reserving the high-order addresses of a subnet for anycast use. This approach was motivated by the need to avoid conflicts with other reserved addresses. Considering the group scope of the anycast address, it also makes sense that the high-order bit, which would represent the individual/group bit of a mapped MAC address, is set to 1 (group). In the case of unicast prefixes with EUI-64 interface IDs, the universal/local bit is set to 0 to indicate that the interface ID for the anycast address is not globally unique. The Anycast ID field shown in Figure 8 can take the following values: 0 through 125,127 (00-7D, 7F) are reserved; ID 126 (7E) is the only one currently in use for the Mobile IPv6 (MIPv6) home agent's anycast addresses.

Note: MIPv6 provides a host with a mechanism to discover the address of one of his home agents (HAs). The host can attempt to register to the home agent's anycast address (described in this section) hosting its home prefix. One of the HAs will receive the request, reject the registration, and instead reply to the host with a list of the actual addresses of the HAs it can use.

The anycast addresses are allocated from the unicast address space. There is little oper-ational experience with this address type, although a few usage examples are provided in RFC 3513.

A multicast address identifies a group of interfaces. A packet with a multicast destination address is delivered to all the group members. It is important to remember that multicast addresses should not be used as SAs. The IPv6 multicast addresses have their top 8 high-order bits set to 1 (FF00::/8) and the format shown in Figure 9.

Three of the four bits in the flag are currently in use:

• The low-order bit T defined in RFC 3513 is set to 0 for permanently assigned multicast addresses that are assigned by IANA. The T bit is set to 1 for nonpermanently assigned multicast addresses.
• The P bit is defined in RFC 3306, and it indicates whether the multicast address is built based on a unicast prefix (set to 1) or not (set to 0).
• The R bit defined in RFC 3956, if set to 1, indicates that the multicast group address contains the unicast address of the RP servicing that group.

The remaining fourth flag bit is reserved for future use and currently is set to 0. The P bit set to 1 indicates that the multicast address is built from a unicast address. Because the unicast address is considered to have a limited lifetime, the resulting multicast address cannot be permanently assigned. This means that a P bit set to 1 requires the T bit to be set to 1, too.

Scoping is a powerful feature built in the IPv6 multicast address architecture. It provides routers with the information needed to contain the multicast traffic within the appropriate domain. Table 3 lists the values that are currently defined for the 4-bit Scope field shown in Figure 9.

Similar to the unicast addresses, the multicast address space has its own elements of special interest, as described next.

Unicast-Prefix-Based Multicast Addresses
GLOP addresses were introduced in IPv4 to provide globally unique IPv4 multicast group addresses to organizations that own autonomous system numbers (ASNs). The addresses are built based on globally unique ASNs. RFC 3306 extends this concept and defines a mechanism that generates globally unique IPv6 multicast addresses based on a unicast prefix, as shown in Figure 10.

The reserved bits must be set to 0. The 64 bits provided for the Unicast Prefix field are sufficient based on the structure of the IPv6 unicast addresses (64 bits are used by the interface ID). The format presented in Figure 10 suggests that any given IPv6 unicast prefix comes with 2³² multicast addresses.

Example 5 shows the unicast-prefix-based multicast address generated from the unicast prefix 2001:100:abc:1::/64.

Note: The scope of the unicast-prefix-based multicast address should not exceed that of the embedded unicast prefix.

Note: The group addresses used in Source Specific Multicast (SSM) deployment models (see Chapter 6, "Providing IPv6 Multicast Services") were defined as a subset of the unicast-prefix-based multicast addresses, where the Prefix Length and the Network Prefix fields are set to 0 (See Figure 11).

Solicited-Node Multicast Addresses
The solicited-node multicast address provides a mechanism to contact a host on the local-link when knowing only its layer 3 unicast address. This address type is generated for each unicast and anycast prefix assigned to an interface. The address format is FF02::1:FF00:0000/104, where the low-order 24 bits are the same as the unicast or anycast address that generated it. It represents a deterministic way to identify a local-link multicast group to which a host with a given IPv6 unicast address is listening. If not all the information needed to establish unicast connectivity to the host (the MAC address) is available, the destination can still be reached via multicast sent to its solicited-node multicast address.

Fundamental IPv6 control-plane processes, such as layer 2-to-layer 3 address mapping and Duplicate Address Detection (DAD) use this type of addresses (see the "Neighbor Discovery" section later in this chapter). Example 6 builds a solicited-node multicast address based on the format shown in Figure 12.

The solicited-node multicast address has a link-local scope. It is used for control-plane functions only within the local link.

Note: Based on the structure of the solicited-node multicast address, it is clear that the same solicited-node multicast address represents multiple IPv6 unicast addresses. Considering the large addressing space and assuming that there is no address assignment policy that favors the 40 high-order bits of the interface ID, this oversubscription of the solicited-node multicast address should not be significant.

IPv6 Multicast Address Allocation
IPv6 multicast addresses are allocated by IANA based on the rules documented on its website:
IANA

IANA identifies two multicast address types in its allocation policy:

• Variable-scope multicast addresses--These addresses are similar across all scopes, but they represent distinct groups. They are reserved for certain types of services or applications. A good example is NTP (Network Time Protocol), which has a multicast address of FF0X:0:0:0:0:0:0:101, where X masks the address scope.
• Fixed-scope multicast addresses--These addresses have a certain meaning only within the scope they are defined in. This type of addresses is important in the basic operation of IPv6. For this reason, a few common ones are listed in Table 4.

One part of the multicast address was not talked about too much in this section, the group ID. In theory, the group ID can take any value as long as the rest of the address fits the structure described in the earlier sections. The larger multicast address space raises the concern of significant oversubscription of layer 2 addresses (which are much smaller in size) mapped to the IPv6 multicast groups. To minimize this over-subscription, group ID allocation guidelines were defined in RFC 3307, and they are shown in Table 5.

The low end of the group ID value is reserved for the permanent multicast addresses under IANA management. This is consistent with the examples shown earlier in Table 2-4. Permanent multicast group ID is used as a globally unique identifier of a service (such as NTP). The high-end range of group ID values is reserved for dynamically allocated addresses, regardless of mechanism. However, having distinct ranges for the server and host allocations does make it easier to identify the multicast addresses obtained through a managed service.

Some of these allocation rules might become irrelevant in the future if other mechanisms are implemented to mitigate this oversubscription.

IPv6 and Layer 2 Addressing
IPv6 addresses correlate with layer 2 addresses in two ways of interest to this discussion. The first way is IPv6 specific and provides the mechanism of building an interface ID from layer 2 addresses. The second way is common for both IPv4 and IPv6 and provides the mechanism for mapping an IP multicast address to a layer 2 multicast address.

EUI-64 Interface Identifiers
IEEE specifies the format of the EUI-64 identifiers. To make such an identifier an IPv6 interface ID, the only thing that has to be done is to flip the sixth bit in Internet standard order (universal/local bit).

The IEEE specification also provides a mechanism for generating a 64-bit EUI-64 identifier from a 48-bit layer 2 address. With such a mechanism in place, a correlation can be established between the MAC address of an interface and the interface ID portion of IPv6 addresses. This type of ID is used, for example, by default by the link-local addresses on Cisco routers.

Figure 13 shows the two-step process of generating an IPv6 interface ID from a MAC address. The first step is to create an EUI-64 identifier; the second step is to modify it to make it an IPv6 interface ID.

Layer 2 Multicast Addresses
Similar to IPv4, IPv6 is currently mapping layer 3 multicast addresses into layer 2 addresses. For multicast IPv6 traffic, the first 16 high-order bits of the MAC address identify the layer 2 multicast address: 3333.XXXX.XXXX. The low-order 32 bits of the IPv6 multicast address are copied into the remaining portion of the MAC address. Figure 14 shows an example of this mapping mechanism in the case of a solicited-node multicast IPv6 address.

• Loopback address
• Link-local address
• Unicast or anycast addresses if configured
• Subscribe to the all-nodes multicast address
• Multicast address of all the groups it subscribes to
• Subscribe to its own solicited-node multicast address

Depending on the node type, configuration, and supported protocols, other addresses might be present or multicast groups might be joined.

A router must support the addresses listed for hosts, as well as the following:

• Subnet-router anycast address
• All configured anycast addresses
• The all routers multicast address

These addresses are used for both control- and data-plane-relevant traffic.

Configuring IPv6 Addresses in Cisco IOS Routers
This section presents the Cisco IOS router-specific configuration steps that are needed to provision a Cisco router interface for IPv6. Example 7 presents the process of enabling IPv6 on a router interface and underlines some of the concepts reviewed in this section.

In Example 7, the router was already enabled to run IPv6 with the global command ipv6 unicast-routing. A router that is not configured for IPv6 routing will act as a host on each of its interfaces configured for IPv6. Despite not being shown in the example, for optimal forwarding of IPv6 traffic it is important to explicitly enable Cisco Express Forwarding (CEF) on Cisco routers with the global configuration command ipv6 cef.

Note: The link-local address was automatically generated from the 48-bit MAC address of the interface. This is the default behavior of a Cisco router. Cisco IOS commands also enable you to manually configure the link-local address.

Example 8 presents the process of configuring various types of addresses on the router interface. The results of these configuration steps are shown in the output of show ipv6 interface, which displays the IPv6 properties of the interface.

Any number of global IPv6 unicast addresses can be configured on an interface. Remember: Unlike IPv4, where the latest configured address overwrites the existing one, in IPv6 the new address is just added to the existing one. If the intent is to remove the current address, you must do so explicitly.

IPv6 Addressing Architecture at a Glance
The IPv6 addressing architecture is, for the most part, settled in its final structure. Some of its aspects are still being worked on (for example, the unique-local unicast address). Despite these ongoing tweaks, at its current level of development and standardization, IPv6 addressing is mature enough for the deployment of large IPv6 networks. Table 6 summarizes the information presented in this section for quick reference.

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.