Network Working Group G. Van de Velde
Request for Comments: 5375 C. Popoviciu
Category: Informational Cisco Systems
T. Chown
University of Southampton
O. Bonness
C. Hahn
T-Systems Enterprise Services GmbH
December 2008
IPv6 Unicast Address Assignment Considerations
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
One fundamental aspect of any IP communications infrastructure is its
addressing plan. With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network
designers and operators need to reconsider their existing approaches
to network addressing. Lack of guidelines on handling this aspect of
network design could slow down the deployment and integration of
IPv6. This document aims to provide the information and
recommendations relevant to planning the addressing aspects of IPv6
deployments. The document also provides IPv6 addressing case studies
for both an enterprise and an ISP network.
Van de Velde, et al. Informational [Page 1]
RFC 5375 IPv6 Addressing Considerations December 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network-Level Addressing Design Considerations . . . . . . . . 4
2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 4
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5
2.3. 6bone Address Space . . . . . . . . . . . . . . . . . . . 6
2.4. Network-Level Design Considerations . . . . . . . . . . . 6
2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8
3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 10
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 10
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 16
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 16
A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16
A.1.2. Forming an Address (Subnet) Allocation Plan . . . . . 17
A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 18
A.1.4. Node Configuration Considerations . . . . . . . . . . 18
A.2. Service Provider Considerations . . . . . . . . . . . . . 19
A.2.1. Investigation of Objective Requirements for an
IPv6 Addressing Schema of a Service Provider . . . . . 19
A.2.2. Exemplary IPv6 Address Allocation Plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 23
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28
Appendix B. Considerations for Subnet Prefixes Different than
/64 . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Considerations for Subnet Prefixes Shorter than /64 . . . 30
B.2. Considerations for Subnet Prefixes Longer than /64 . . . . 31
B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.4. EUI-64 'u' and 'g' Bits . . . . . . . . . . . . . . . 31
B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 32
B.2.6. Addresses Used by Embedded-RP (RFC 3956) . . . . . . . 33
B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 34
Van de Velde, et al. Informational [Page 2]
RFC 5375 IPv6 Addressing Considerations December 2008
1. Introduction
The Internet Protocol Version 6 (IPv6) Addressing Architecture
[RFC4291] defines three main types of addresses: unicast, anycast,
and multicast. This document focuses on unicast addresses, for which
there are currently two principal allocated types: Globally Unique
Addresses ('globals') [RFC3587] and Unique Local IPv6 Addresses
(ULAs) [RFC4193]. In addition, until recently there has been the
'experimental' 6bone address space [RFC3701], though its use has been
deprecated since June 2006 [RFC3701].
The document covers aspects that should be considered during IPv6
deployment for the design and planning of an addressing scheme for an
IPv6 network. The network's IPv6 addressing plan may be for an IPv6-
only network, or for a dual-stack infrastructure where some or all
devices have addresses in both protocols. These considerations will
help an IPv6 network designer to efficiently and prudently assign the
IPv6 address space that has been allocated to their organization.
The address assignment considerations are analyzed separately for the
two major components of the IPv6 unicast addresses -- namely,
'Network-Level Addressing' (the allocation of subnets) and the
'interface-id' (the identification of the interface within a subnet).
Thus, the document includes a discussion of aspects of address
assignment to nodes and interfaces in an IPv6 network. Finally, the
document provides two examples of deployed addressing plans in a
service provider (ISP) and an enterprise network.
Parts of this document highlight the differences that an experienced
IPv4 network designer should consider when planning an IPv6
deployment, for example:
o IPv6 devices will more likely be multi-addressed in comparison
with their IPv4 counterparts.
o The practically unlimited size of an IPv6 subnet (2^64 bits)
reduces the requirement to size subnets to device counts for the
purposes of (IPv4) address conservation.
o The vastly increased subnet size has implications on the threat of
address-based host scanning and other scanning techniques, as
discussed in [RFC5157].
We do not discuss here how a site or ISP should proceed with
acquiring its globally routable IPv6 address prefix. In each case,
the prefix received is either provider assigned (PA) or provider
independent (PI).
Van de Velde, et al. Informational [Page 3]
RFC 5375 IPv6 Addressing Considerations December 2008
We do not discuss PI policy here. The observations and
recommendations of this text are largely independent of the PA or PI
nature of the address block being used. At this time, we assume that
when an IPv6 network changes provider, typically it will need to
undergo a renumbering process, as described in [RFC4192]. A separate
document [THINKABOUT] makes recommendations to ease the IPv6
renumbering process.
This document does not discuss implementation aspects related to the
transition from the now obsoleted site-local addresses to ULAs. Some
implementations know about site-local addresses even though they are
deprecated, and do not know about ULAs even though they represent
current specification. As a result, transitioning between these
types of addresses may cause difficulties.
2. Network-Level Addressing Design Considerations
This section discusses the kind of IPv6 addresses used at the network
level for the IPv6 infrastructure. The kind of addresses that can be
considered are Globally Unique Addresses and ULAs. We also comment
here on the deprecated 6bone address space.
2.1. Globally Unique Addresses
The most commonly used unicast addresses will be Globally Unique
Addresses ('globals'). No significant considerations are necessary
if the organization has an address space assignment and a single
prefix is deployed through a single upstream provider.
However, a multihomed site may deploy addresses from two or more
service-provider-assigned IPv6 address ranges. Here, the network
administrator must have awareness on where and how these ranges are
used on the multihomed infrastructure environment. The nature of the
usage of multiple prefixes may depend on the reason for multihoming
(e.g., resilience failover, load balancing, policy-based routing, or
multihoming during an IPv6 renumbering event). IPv6 introduces
improved support for multi-addressed hosts through the IPv6 default
address selection methods described in RFC 3484 [RFC3484]. A
multihomed host may thus have two or more addresses, one per prefix
(provider), and select source and destination addresses to use as
described in that RFC. However, multihoming also has some
operational and administrative burdens besides choosing multiple
addresses per interface [RFC4218] [RFC4219].
Van de Velde, et al. Informational [Page 4]
RFC 5375 IPv6 Addressing Considerations December 2008
2.2. Unique Local IPv6 Addresses
ULAs have replaced the originally conceived site-local addresses in
the IPv6 addressing architecture, for reasons described in [RFC3879].
ULAs improve on site-locals by offering a high probability of the
global uniqueness of the prefix used, which can be beneficial when
there is (deliberate or accidental) leakage or when networks are
merged. ULAs are akin to the private address space [RFC1918]
assigned for IPv4 networks, except that in IPv6 networks we may
expect to see ULAs used alongside global addresses, with ULAs used
internally and globals used externally. Thus, use of ULAs does not
imply use of NAT for IPv6.
The ULA address range allows network administrators to deploy IPv6
addresses on their network without asking for a globally unique
registered IPv6 address range. A ULA prefix is 48 bits, i.e., a /48,
the same as the currently recommended allocation for a site from the
globally routable IPv6 address space [RFC3177].
A site that wishes to use ULAs can have (a) multiple /48 prefixes
(e.g., a /44) (b) one /48, or (c) a less-than-/48 prefix (e.g., a /56
or /64). In all of the above cases, the ULAs can be randomly chosen
according to the principles specified in [RFC4193]. However, in case
(a) the use of randomly chosen ULAs will provide suboptimal
aggregation capabilities.
ULAs provide the means to deploy a fixed addressing scheme that is
not affected by a change in service provider and the corresponding PA
global addresses. Internal operation of the network is thus
unaffected during renumbering events. Nevertheless, this type of
address must be used with caution.
A site using ULAs may or may not also deploy global addresses. In an
isolated network, ULAs may be deployed on their own. In a connected
network that also deploys global addresses, both may be deployed,
such that hosts become multi-addressed (one global and one ULA), and
the IPv6 default address selection algorithm will pick the
appropriate source and destination addresses to use, e.g., ULAs will
be selected where both the source and destination hosts have ULAs.
Because a ULA and a global site prefix are both /48 length, an
administrator can choose to use the same subnetting (and host
addressing) plan for both prefixes.
As an example of the problems ULAs may cause, when using IPv6
multicast within the network, the IPv6 default address selection
algorithm prefers the ULA as the source address for the IPv6
multicast streams. This is NOT a valid option when sending an IPv6
multicast stream to the IPv6 Internet for two reasons. For one,
Van de Velde, et al. Informational [Page 5]
RFC 5375 IPv6 Addressing Considerations December 2008
these addresses are not globally routable, so Reverse Path Forwarding
checks for such traffic will fail outside the internal network. The
other reason is that the traffic will likely not cross the network
boundary due to multicast domain control and perimeter security
policies.
In principle, ULAs allow easier network mergers than RFC 1918
addresses do for IPv4 because ULA prefixes have a high probability of
uniqueness, if the prefix is chosen as described in the RFC.
2.3. 6bone Address Space
The 6bone address space was used before the Regional Internet
Registries (RIRs) started to distribute 'production' IPv6 prefixes.
The 6bone prefixes have a common first 16 bits in the IPv6 Prefix of
3FFE::/16. This address range has been deprecated as of 6 June 2006
[RFC3701] and must not be used on any new IPv6 network deployments.
Sites using 6bone address space should renumber to production address
space using procedures as defined in [RFC4192].
2.4. Network-Level Design Considerations
IPv6 provides network administrators with a significantly larger
address space, enabling them to be very creative in how they can
define logical and practical addressing plans. The subnetting of
assigned prefixes can be done based on various logical schemes that
involve factors such as:
o Using existing systems
* translate the existing subnet numbers into IPv6 subnet IDs
* translate the VLAN IDs into IPv6 subnet IDs
o Redesign
* allocate according to your need
o Aggregation
* Geographical Boundaries - by assigning a common prefix to all
subnets within a geographical area.
* Organizational Boundaries - by assigning a common prefix to an
entire organization or group within a corporate infrastructure.
Van de Velde, et al. Informational [Page 6]
RFC 5375 IPv6 Addressing Considerations December 2008
* Service Type - by reserving certain prefixes for predefined
services such as: VoIP, content distribution, wireless
services, Internet access, security areas, etc. This type of
addressing may create dependencies on IP addresses that can
make renumbering harder if the nodes or interfaces supporting
those services on the network are sparse within the topology.
Such logical addressing plans have the potential to simplify network
operations and service offerings, and to simplify network management
and troubleshooting. A very large network would not need to consider
using private address space for its infrastructure devices, thereby
simplifying network management.
The network designer must however keep in mind several factors when
developing these new addressing schemes for networks with and without
global connectivity:
o Prefix aggregation - The larger IPv6 addresses can lead to larger
routing tables unless network designers are actively pursuing
aggregation. While prefix aggregation will be enforced by the
service provider, it is beneficial for the individual
organizations to observe the same principles in their network
design process.
o Network growth - The allocation mechanism for flexible growth of a
network prefix, documented in RFC 3531 [RFC3531] can be used to
allow the network infrastructure to grow and be numbered in a way
that is likely to preserve aggregation (the plan leaves 'holes'
for growth).
o ULA usage in large networks - Networks that have a large number of
'sites' that each deploy a ULA prefix that will by default be a
'random' /48 under fc00::/7 will have no aggregation of those
prefixes. Thus, the end result may be cumbersome because the
network will have large amounts of non-aggregated ULA prefixes.
However, there is no rule to disallow large networks from using a
single ULA prefix for all 'sites', as a ULA still provides 16 bits
for subnetting to be used internally.
o Compact numbering of small sites - It is possible that as registry
policies evolve, a small site may experience an increase in prefix
length when renumbering, e.g., from /48 to /56. For this reason,
the best practice is to number subnets compactly rather than
sparsely, and to use low-order bits as much as possible when
numbering subnets. In other words, even if a /48 is allocated,
act as though only a /56 is available. Clearly, this advice does
not apply to large sites and enterprises that have an intrinsic
need for a /48 prefix.
Van de Velde, et al. Informational [Page 7]
RFC 5375 IPv6 Addressing Considerations December 2008
o Consider assigning more than one /64 to a site - A small site may
want to enable routing amongst interfaces connected to a gateway
device. For example, a residential gateway that receives a /48
and is situated in a home with multiple LANs of different media
types (sensor network, wired, Wi-Fi, etc.), or has a need for
traffic segmentation (home, work, kids, etc.), could benefit
greatly from multiple subnets and routing in IPv6. Ideally,
residential networks would be given an address range of a /48 or
/56 [RIPE_Nov07] such that multiple /64 subnets could be used
within the residence.
2.4.1. Sizing the Network Allocation
We do not discuss here how a network designer sizes their application
for address space. By default, a site will receive a /48 prefix
[RFC3177]; however, different RIR service regions policies may
suggest alternative default assignments or let the ISPs decide on
what they believe is more appropriate for their specific case (see
Section 6.5.4, "Assignments from LIRs/ISPs", of [ARIN]). The default
provider allocation via the RIRs is currently a /32 [RIPE_Nov07].
These allocations are indicators for a first allocation for a
network. Different sizes may be obtained based on the anticipated
address usage [RIPE_Nov07]. At the time of writing, there are
examples of allocations as large as /19 having been made from RIRs to
providers.
2.4.2. Address Space Conservation
Despite the large IPv6 address space, which enables easier
subnetting, it still is important to ensure an efficient use of this
resource. Some addressing schemes, while facilitating aggregation
and management, could lead to significant numbers of addresses being
unused. Address conservation requirements are less stringent in
IPv6, but they should still be observed.
The proposed Host-Density (HD) value [RFC3194] for IPv6 is 0.94
compared to the current value of 0.96 for IPv4. Note that with IPv6,
HD is calculated for sites (e.g., on a basis of /56), instead of for
addresses as with IPv4.
3. Subnet Prefix Considerations
An important part of an IPv4 addressing plan is deciding the length
of each subnet prefix. Unlike in IPv4, the IPv6 addressing
architecture [RFC4291] specifies that all subnets using Globally
Unique Addresses and ULAs always have the same prefix length of 64
bits. (This also applies to the deprecated 6bone and site-local
addresses.)
Van de Velde, et al. Informational [Page 8]
RFC 5375 IPv6 Addressing Considerations December 2008
The only exception to this rule are special addresses starting with
the binary value 000, such as IPv4-compatible IPv6 addresses. These
exceptions are largely beyond the scope of this document.
Using a subnet prefix length other than a /64 will break many
features of IPv6, including Neighbor Discovery (ND), Secure Neighbor
Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of
Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode
(PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6
Intermediation (SHIM6) [SHIM6], among others. A number of other
features currently in development, or being proposed, also rely on
/64 subnet prefixes.
Nevertheless, many IPv6 implementations do not prevent the
administrator from configuring a subnet prefix length shorter or
longer than 64 bits. Using subnet prefixes shorter than /64 would
rarely be useful; see Appendix B.1 for discussion.
However, some network administrators have used prefixes longer than
/64 for links connecting routers, usually just two routers on a
point-to-point link. On links where all the addresses are assigned
by manual configuration, and all nodes on the link are routers (not
end hosts) that are known by the network, administrators do not need
any of the IPv6 features that rely on /64 subnet prefixes, this can
work. Using subnet prefixes longer than /64 is not recommended for
general use, and using them for links containing end hosts would be
an especially bad idea, as it is difficult to predict what IPv6
features the hosts will use in the future.
Appendix B.2 describes some practical considerations that need to be
taken into account when using prefixes longer than /64 in limited
cases. In particular, a number of IPv6 features use interface
identifiers that have a special form (such as a certain fixed value
in some bit positions). When using prefixes longer than /64, it is
prudent to avoid certain subnet prefix values so that nodes who
assume that the prefix is /64 will not incorrectly identify the
addresses in that subnet as having a special form. Appendix B.2
describes the subnet prefix values that are currently believed to be
potentially problematic; however, the list is not exhaustive and can
be expected to grow in the future.
Using /64 subnets is strongly recommended, also for links connecting
only routers. A deployment compliant with the current IPv6
specifications cannot use other prefix lengths. However, the V6OPS
WG believes that despite the drawbacks (and a potentially expensive
network redesign, if IPv6 features relying on /64 subnets are needed
in the future), some networks administrators will use prefixes longer
than /64.
Van de Velde, et al. Informational [Page 9]
RFC 5375 IPv6 Addressing Considerations December 2008
3.1. Considerations for /64 Prefixes
Based on RFC 3177 [RFC3177], 64 bits is the prescribed subnet prefix
length to allocate to interfaces and nodes.
When using a /64 subnet length, the address assignment for these
addresses can be made either by manual configuration, by a Dynamic
Host Configuration Protocol [RFC3315], by stateless autoconfiguration
[