July 24, 2006
An IPv6 Refresher--Part I
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.
IPv6 Unicast Address
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
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
- 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
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.
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 2128
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.
The fundamental function of a network is to provide unicast
reachability for the hosts connected to it. All other services it
provides rely on this unicast infrastructure. For these reasons,
regardless of the IP version, unicast addresses play a critical role in
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
Example 2 shows the network and interface identifier of an IPv6 address.
Example 2. Identifying the Network and Interface ID of an IPv6 Address
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:
- Build one from the layer 2 address in the modified EUI-64
format. For the interface ID portion of the network, the seventh
high-order bit of the EUI-64 format defines a local scope when set to 0
and a global scope (globally unique) when set to 1. Different
mechanisms are defined for each media type to build the complete
interface ID in the modified EUI- 64 format (see the references in the
section "IPv6 and Data-Link Technologies" later in this chapter).
- Autogenerate a random address as defined in RFC 3041. This
assignment mechanism was developed mainly to limit the exposure of a
globally reachable address and to increase privacy (see Chapter 9,
"Securing IPv6 Networks").
- Acquire the interface ID via DHCPv6.
- Manual configuration.
- Cryptographically generated addresses (CGAs) based on RFC 3972
through a hash that includes a public key. This method of generating an
interface ID provides added security and enables address
authentication. The Neighbor Discovery process described later in this
chapter is secured with the help of CGAs.
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:
- The link-local scope--Identifies all hosts within a single layer
2 domain. The unicast addresses used within this scope are called link- local addresses.
- The unique-local scope--Identifies all devices reachable
within an administrative site or domain that typically contains
multiple distinct links. The unicast addresses used within this scope
are called unique- local addresses (ULAs).
- The global scope--Identifies all devices reachable across the Internet. The unicast addresses used within this scope are called global unicast addresses (GUAs).
These scopes are hierarchical, as shown in Figure 2. The global
scope is larger than the local (site) scope, which in turn includes the
Figure 2. Unicast Address Scoping
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.
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
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.
Figure 3. Local-Link Address Structure
Example 3. Link-Local Address of an Ethernet Interface
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,
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:
its drive to reestablish the original uniform and global structure of
the Internet, IPv6 could theoretically live without the concept of a
site. However, practical considerations dictate the need to identify
scopes smaller than the global one. Enterprises in particular have an
understandable fondness for identifying the boundaries of their
networks. For these reasons, the deprecated site-local scope and
addresses had to be replaced by a better-defined concept that could
handle the concerns mentioned. The new concept is that of a
unique-local scope and the corresponding unique-local addresses.
- Application issues--Applications have problems when the
site-local addresses are carried in payload outside the site. A good
example of this is the case of a client/server application that relies
on the addresses of each side, which are on different sites. The
address overlap between sites can confuse the server with respect to
the location of the client. Attempts to deal with address overlap by
adding a site identifier to the site-local addresses led to complex
implementations. It is difficult for network nodes to keep track of all
site identifiers, especially in the case of nodes multihomed over
Applications generally do not have a sense of scope, and they often
leak private addresses, such as site-local, outside the private
network. Leaks between sites with the same addressing can lead to
routing or DNS problems.
- Routing and Forwarding Issues--The nonunique
character of site-local addresses would force routers to have to track
the prefix of an interface and the site it belongs to.
Nonunique site-local addresses make it difficult to interconnect
discontiguous elements of a site over intermediate networks. Tunneling
becomes necessary in such circumstances.
Multi-sited routers have to base their forwarding decision not only
on the destination address but on the incoming interface as well to
contain the traffic within the proper site.
Figure 4 shows the format of these addresses. The unique-local unicast addresses are fully standardized in RFC 4193.
Figure 4. Unique-Local Unicast Address Format
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:
- L identifies the assignment policy. Only value 1 (FD00::/8) is currently in use designating a local assignment.
- Global ID is a 40-bit identifier that ensures the global
uniqueness of the address. It is generated pseudo-randomly and must not
be sequential. Because ULAs should not be globally routed, they do not
need to be aggregated, so sequential global IDs are not necessary.
- Subnet ID gives the administrator of the local domain a resource
that can be used to define a hierarchical addressing plan within the
- Interface ID has the same meaning for all unicast addresses, and it is 64 bits long in the modified EUI-64 format.
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
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.
Figure 5. Global Unicast Address Structure
The components of the global unicast address are as follows:
- Global routing prefix--A service provider is assigned a
portion of this prefix by the Internet Assigned Numbers Authority
(IANA), and it then allocates a subspace to its customers. Its length
is 48 bits or shorter based on the RFC 3177 recommendations.
- Subnet ID--An organization receives a prefix from its
service provider where the global routing prefix identifies the service
provider (SP) and the organization inside the SP, and the subnet ID
identifies the organizational structure of its network.
- Interface ID--The low-order 64 bits of the address are used to identify the interfaces of nodes on a link.
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
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.
Table 1. Assigned IPv6 Unicast Addresses
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 current RIRs are as follows:
- African Network Information Center (AfriNIC)
- Asia Pacific Network Information Center (APNIC)
- American Registry for Internet Numbers (ARIN)
- Regional Latin-American and Caribbean IP Address Registry (LACNIC)
- Rseaux IP Europens (RIPE NCC)
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.
ISPs allocate prefixes to their customers (enterprises or residential users).
Figure 6. IPv6 Prefix-Allocation Process
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
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
You can find a list of allocated prefixes from both the 2001:: and 3FFE:: space at
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.
Click here for Figure 7
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
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
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: email@example.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 ,
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.
Enjoy this article? Also read Transition IPv6 seamlessly in embedded systems