July 28, 2006
An IPv6 Refresher--Part II
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.
IPv6 Multicast Addresses
Miss Part I? No need to search--it's right here.
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
Example 4 shows the IPv4-compatible and the IPv4-mapped IPv6 addresses corresponding to the IPv4 address 220.127.116.11.
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
RFC 2526 defines an additional set of anycast addresses
reserved for a given prefix. Figure 8 shows the structure of these
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.
Multicast received its well-deserved attention during the development
of IPv6. It replaced broadcast addresses in the control-plane messages,
thus becoming a critical part of IPv6 network operation. The larger
address space provides plenty of globally unique multicast group
addresses to facilitate the deployment of multicast services.
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.
Figure 9. IPv6 Multicast Address Format
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.
Table 3. Defined IPv6 Multicast Scopes
Similar to the unicast addresses, the multicast address space has its own elements of special interest, as described next.
Unicast-Prefix-Based Multicast Addresses
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.
Figure 10. Unicast-Prefix-Based Multicast Address Format
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 232 multicast addresses.
Example 5 shows the unicast-prefix-based multicast address generated from the unicast prefix 2001:100:abc:1::/64.
Example 5. Unicast-Prefix-Based Multicast Address Generated from an IPv6 Unicast Prefix
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).
Figure 11. PIM-SSM Multicast Group Addresses
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.
Figure 12. Solicited-Node Multicast Address Format
Example 6. Generating a Solicited-Node Multicast Address
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
IPv6 Multicast Address Allocation
IPv6 multicast addresses are allocated by IANA based on the rules documented on its website:
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.
Table 3. Example of Fixed-Scope IPv6 Multicast Addresses
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.
Table 5. Group ID Allocation Rules
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
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.
Figure 13. Generating an Interface ID from a MAC Address in the Modified EUI-64 Format
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
Figure 14. Mapping an IPv6 Multicast Address into a MAC Address
These two address correlation mechanisms are often used in operational
networks and are often mentioned throughout this book.
IPv6 Addresses Required for an Interface
To ensure proper operation of the IPv6 protocol, each IPv6-enabled host must support the following set of addresses:
- 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
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.
Example 7. Enabling IPv6 on a Router Interface (Continued)
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.
Example 8. Configuring IPv6 on a Router Interface (Continued)
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
Table 6. IPv6 Addressing Summary and Significant Address Allocations (Continued)
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: firstname.lastname@example.org 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 ,
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.