draft-ietf-v6ops-addcon-10.txt   rfc5375.txt 
IPv6 Operations G. Van de Velde Network Working Group G. Van de Velde
Internet-Draft C. Popoviciu Request for Comments: 5375 C. Popoviciu
Intended status: Informational Cisco Systems Category: Informational Cisco Systems
Expires: March 26, 2009 T. Chown T. Chown
University of Southampton University of Southampton
O. Bonness O. Bonness
C. Hahn C. Hahn
T-Systems Enterprise Services GmbH T-Systems Enterprise Services GmbH
September 22, 2008 December 2008
IPv6 Unicast Address Assignment Considerations IPv6 Unicast Address Assignment Considerations
<draft-ietf-v6ops-addcon-10.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2008 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html. document authors. All rights reserved.
This Internet-Draft will expire on March 26, 2009. 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 Abstract
One fundamental aspect of any IP communications infrastructure is its One fundamental aspect of any IP communications infrastructure is its
addressing plan. With its new address architecture and allocation addressing plan. With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network policies, the introduction of IPv6 into a network means that network
designers and operators need to reconsider their existing approaches designers and operators need to reconsider their existing approaches
to network addressing. Lack of guidelines on handling this aspect of to network addressing. Lack of guidelines on handling this aspect of
network design could slow down the deployment and integration of network design could slow down the deployment and integration of
IPv6. This document aims to provide the information and IPv6. This document aims to provide the information and
recommendations relevant to planning the addressing aspects of IPv6 recommendations relevant to planning the addressing aspects of IPv6
deployments. The document also provides IPv6 addressing case studies deployments. The document also provides IPv6 addressing case studies
for both an enterprise and an ISP network. for both an enterprise and an ISP network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network Level Addressing Design Considerations . . . . . . . . 5 2. Network-Level Addressing Design Considerations . . . . . . . . 4
2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 5 2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 4
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5
2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 7 2.3. 6bone Address Space . . . . . . . . . . . . . . . . . . . 6
2.4. Network Level Design Considerations . . . . . . . . . . . 7 2.4. Network-Level Design Considerations . . . . . . . . . . . 6
2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
2.4.2. Address Space Conservation . . . . . . . . . . . . . . 9 2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 9 3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8
3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10 3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10
3.2. Allocation of the IID of an IPv6 Address . . . . . . . . . 10 4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10
3.2.1. Automatic EUI-64 Format Option . . . . . . . . . . . . 11 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 10
3.2.2. Using Privacy Extensions . . . . . . . . . . . . . . . 11 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 10
3.2.3. Manual/Dynamic Assignment Option . . . . . . . . . . . 11 4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 11
3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
3.4. Security Considerations . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12 7. Informative References . . . . . . . . . . . . . . . . . . . . 12
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 16
4.1. Normative References . . . . . . . . . . . . . . . . . . . 12 A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 16
4.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 15
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 15
A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16 A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16
A.1.2. Forming an Address (subnet) Allocation Plan . . . . . 16 A.1.2. Forming an Address (Subnet) Allocation Plan . . . . . 17
A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 17 A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 18
A.1.4. Node Configuration Considerations . . . . . . . . . . 18 A.1.4. Node Configuration Considerations . . . . . . . . . . 18
A.2. Service Provider Considerations . . . . . . . . . . . . . 18 A.2. Service Provider Considerations . . . . . . . . . . . . . 19
A.2.1. Investigation of objective Requirements for an A.2.1. Investigation of Objective Requirements for an
IPv6 addressing schema of a Service Provider . . . . 19 IPv6 Addressing Schema of a Service Provider . . . . . 19
A.2.2. Exemplary IPv6 Address Allocation Plan for a A.2.2. Exemplary IPv6 Address Allocation Plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 22 Service Provider . . . . . . . . . . . . . . . . . . . 23
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 26 A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28
Appendix B. Considerations for Subnet Prefixes Different then Appendix B. Considerations for Subnet Prefixes Different than
/64 . . . . . . . . . . . . . . . . . . . . . . . . . 29 /64 . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Considerations for Subnet Prefixes Shorter then /64 . . . 29 B.1. Considerations for Subnet Prefixes Shorter than /64 . . . 30
B.2. Considerations for Subnet Prefixes Longer then /64 . . . . 29 B.2. Considerations for Subnet Prefixes Longer than /64 . . . . 31
B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 29 B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 29 B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 29 B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.4. EUI-64 'u' and 'g' bits . . . . . . . . . . . . . . . 30 B.2.4. EUI-64 'u' and 'g' Bits . . . . . . . . . . . . . . . 31
B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 31 B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 32
B.2.6. Addresses Used by Embedded-RP (RFC3956) . . . . . . . 32 B.2.6. Addresses Used by Embedded-RP (RFC 3956) . . . . . . . 33
B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 33 B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
The Internet Protocol Version 6 (IPv6) Addressing Architecture The Internet Protocol Version 6 (IPv6) Addressing Architecture
[RFC4291] defines three main types of addresses: unicast, anycast and [RFC4291] defines three main types of addresses: unicast, anycast,
multicast. This document focuses on unicast addresses, for which and multicast. This document focuses on unicast addresses, for which
there are currently two principal allocated types: Globally Unique there are currently two principal allocated types: Globally Unique
Addresses [RFC3587] ('globals') and Unique Local IPv6 Addresses Addresses ('globals') [RFC3587] and Unique Local IPv6 Addresses
[RFC4193] (ULAs). In addition until recently there has been (ULAs) [RFC4193]. In addition, until recently there has been the
'experimental' 6bone address space [RFC3701], though its use has been 'experimental' 6bone address space [RFC3701], though its use has been
deprecated since June 2006 [RFC3701]. deprecated since June 2006 [RFC3701].
The document covers aspects that should be considered during IPv6 The document covers aspects that should be considered during IPv6
deployment for the design and planning of an addressing scheme for an 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- 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 only network, or for a dual-stack infrastructure where some or all
devices have addresses in both protocols. These considerations will devices have addresses in both protocols. These considerations will
help an IPv6 network designer to efficiently and prudently assign the help an IPv6 network designer to efficiently and prudently assign the
IPv6 address space that has been allocated to their organization. IPv6 address space that has been allocated to their organization.
The address assignment considerations are analyzed separately for the The address assignment considerations are analyzed separately for the
two major components of the IPv6 unicast addresses, namely 'Network two major components of the IPv6 unicast addresses -- namely,
Level Addressing' (the allocation of subnets) and the 'interface-id' 'Network-Level Addressing' (the allocation of subnets) and the
(the identification of the interface within a subnet). Thus the 'interface-id' (the identification of the interface within a subnet).
document includes a discussion of aspects of address assignment to Thus, the document includes a discussion of aspects of address
nodes and interfaces in an IPv6 network. Finally the document assignment to nodes and interfaces in an IPv6 network. Finally, the
provides two examples of deployed address plans in a service provider document provides two examples of deployed addressing plans in a
(ISP) and an enterprise network. service provider (ISP) and an enterprise network.
Parts of this document highlight the differences that an experienced Parts of this document highlight the differences that an experienced
IPv4 network designer should consider when planning an IPv6 IPv4 network designer should consider when planning an IPv6
deployment, for example: deployment, for example:
o IPv6 devices will more likely be multi-addressed in comparison o IPv6 devices will more likely be multi-addressed in comparison
with their IPv4 counterparts with their IPv4 counterparts.
o The practically unlimited size of an IPv6 subnet (2^64 bits) o The practically unlimited size of an IPv6 subnet (2^64 bits)
reduces the requirement to size subnets to device counts for the reduces the requirement to size subnets to device counts for the
purposes of (IPv4) address conservation purposes of (IPv4) address conservation.
o The implications of the vastly increased subnet size on the threat
of address-based host scanning and other scanning techniques, as o The vastly increased subnet size has implications on the threat of
address-based host scanning and other scanning techniques, as
discussed in [RFC5157]. discussed in [RFC5157].
We do not discuss here how a site or ISP should proceed with We do not discuss here how a site or ISP should proceed with
acquiring its globally routable IPv6 address prefix. In each case acquiring its globally routable IPv6 address prefix. In each case,
the prefix received is either provider assigned (PA) or provider the prefix received is either provider assigned (PA) or provider
independent (PI). independent (PI).
We do not discuss PI policy here. The observations and We do not discuss PI policy here. The observations and
recommendations of this text are largely independent of the PA or PI 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 nature of the address block being used. At this time, we assume that
most commonly an IPv6 network which changes provider will need to when an IPv6 network changes provider, typically it will need to
undergo a renumbering process, as described in [RFC4192]. A separate undergo a renumbering process, as described in [RFC4192]. A separate
document [THINKABOUT] makes recommendations to ease the IPv6 document [THINKABOUT] makes recommendations to ease the IPv6
renumbering process. renumbering process.
This document does not discuss implementation aspects related to the This document does not discuss implementation aspects related to the
transition between the ULA addresses and the now obsoleted site-local transition from the now obsoleted site-local addresses to ULAs. Some
addresses. Some implementations know about Site-local addresses even implementations know about site-local addresses even though they are
though they are deprecated, and do not know about ULAs - even though deprecated, and do not know about ULAs even though they represent
they represent current specification. As result transitioning current specification. As a result, transitioning between these
between these types of addresses may cause difficulties. types of addresses may cause difficulties.
2. Network Level Addressing Design Considerations 2. Network-Level Addressing Design Considerations
This section discusses the kind of IPv6 addresses used at the network This section discusses the kind of IPv6 addresses used at the network
level for the IPv6 infrastructure. The kind of addresses that can be level for the IPv6 infrastructure. The kind of addresses that can be
considered are Globally Unique Addresses and ULAs. We also comment considered are Globally Unique Addresses and ULAs. We also comment
here on the deprecated 6bone address space. here on the deprecated 6bone address space.
2.1. Globally Unique Addresses 2.1. Globally Unique Addresses
The most commonly used unicast addresses will be Globally Unique The most commonly used unicast addresses will be Globally Unique
Addresses ('globals'). No significant considerations are necessary Addresses ('globals'). No significant considerations are necessary
if the organization has an address space assignment and a single if the organization has an address space assignment and a single
prefix is deployed through a single upstream provider. prefix is deployed through a single upstream provider.
However, a multihomed site may deploy addresses from two or more However, a multihomed site may deploy addresses from two or more
Service Provider assigned IPv6 address ranges. Here, the network service-provider-assigned IPv6 address ranges. Here, the network
Administrator must have awareness on where and how these ranges are administrator must have awareness on where and how these ranges are
used on the multihomed infrastructure environment. The nature of the used on the multihomed infrastructure environment. The nature of the
usage of multiple prefixes may depend on the reason for multihoming usage of multiple prefixes may depend on the reason for multihoming
(e.g. resilience failover, load balancing, policy-based routing, or (e.g., resilience failover, load balancing, policy-based routing, or
multihoming during an IPv6 renumbering event). IPv6 introduces multihoming during an IPv6 renumbering event). IPv6 introduces
improved support for multi-addressed hosts through the IPv6 default improved support for multi-addressed hosts through the IPv6 default
address selection methods described in RFC3484 [RFC3484]. A address selection methods described in RFC3484 [RFC3484]. A
multihomed host may thus have two or more addresses, one per prefix multihomed host may thus have two or more addresses, one per prefix
(provider), and select source and destination addresses to use as (provider), and select source and destination addresses to use as
described in that RFC. However multihoming also has some operational described in that RFC. However, multihoming also has some
and administrative burdens besides chosing multiple addresses per operational and administrative burdens besides choosing multiple
interface [RFC4219][RFC4218]. addresses per interface [RFC4218] [RFC4219].
2.2. Unique Local IPv6 Addresses 2.2. Unique Local IPv6 Addresses
ULAs have replaced the originally conceived Site Local addresses in ULAs have replaced the originally conceived site-local addresses in
the IPv6 addressing architecture, for reasons described in [RFC3879]. the IPv6 addressing architecture, for reasons described in [RFC3879].
ULAs improve on site locals by offering a high probability of the ULAs improve on site-locals by offering a high probability of the
global uniqueness of the prefix used, which can be beneficial in the global uniqueness of the prefix used, which can be beneficial when
case of (deliberate or accidental) leakage, or where networks are there is (deliberate or accidental) leakage or when networks are
merged. ULAs are akin to the private address space [RFC1918] merged. ULAs are akin to the private address space [RFC1918]
assigned for IPv4 networks, except that in IPv6 networks we may assigned for IPv4 networks, except that in IPv6 networks we may
expect to see ULAs used alongside global addresses, with ULAs used expect to see ULAs used alongside global addresses, with ULAs used
internally and globals used externally. Thus use of ULAs does not internally and globals used externally. Thus, use of ULAs does not
imply use of NAT for IPv6. imply use of NAT for IPv6.
The ULA address range allows network administrators to deploy IPv6 The ULA address range allows network administrators to deploy IPv6
addresses on their network without asking for a globally unique addresses on their network without asking for a globally unique
registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48, 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 the same as the currently recommended allocation for a site from the
globally routable IPv6 address space [RFC3177]. globally routable IPv6 address space [RFC3177].
A site willing to use ULA address space can have either (a) multiple A site that wishes to use ULAs can have (a) multiple /48 prefixes
/48 prefixes (e.g. a /44) and wishes to use ULAs, or (b) has one /48 (e.g., a /44) (b) one /48, or (c) a less-than-/48 prefix (e.g., a /56
and wishes to use ULAs or (c) a site has a less-than-/48 prefix (e.g. or /64). In all of the above cases, the ULAs can be randomly chosen
a /56 or /64) and wishes to use ULAs. In all above cases the ULA according to the principles specified in [RFC4193]. However, in case
addresses can be randomly chosen according the principles specified (a) the use of randomly chosen ULAs will provide suboptimal
in [RFC4193]. However, in case (a) the use of randomly chosen ULA aggregation capabilities.
addresses will provide suboptimal aggregation capabilities.
ULAs provide the means to deploy a fixed addressing scheme that is ULAs provide the means to deploy a fixed addressing scheme that is
not affected by a change in service provider and the corresponding PA not affected by a change in service provider and the corresponding PA
global addresses. Internal operation of the network is thus global addresses. Internal operation of the network is thus
unaffected during renumbering events. Nevertheless, this type of unaffected during renumbering events. Nevertheless, this type of
address must be used with caution. address must be used with caution.
A site using ULAs may or may not also deploy global addresses. In an 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 isolated network, ULAs may be deployed on their own. In a connected
network, that also deploys global addresses, both may be deployed, network that also deploys global addresses, both may be deployed,
such that hosts become multiaddressed (one global and one ULA such that hosts become multi-addressed (one global and one ULA), and
address) and the IPv6 default address selection algorithm will pick the IPv6 default address selection algorithm will pick the
the appropriate source and destination addresses to use, e.g. ULAs appropriate source and destination addresses to use, e.g., ULAs will
will be selected where both the source and destination hosts have ULA be selected where both the source and destination hosts have ULAs.
addresses. Because a ULA and a global site prefix are both /48 Because a ULA and a global site prefix are both /48 length, an
length, an administrator can choose to use the same subnetting (and administrator can choose to use the same subnetting (and host
host addressing) plan for both prefixes. addressing) plan for both prefixes.
As an example of the problems ULAs may cause, when using IPv6 As an example of the problems ULAs may cause, when using IPv6
multicast within the network, the IPv6 default address selection multicast within the network, the IPv6 default address selection
algorithm prefers the ULA address as the source address for the IPv6 algorithm prefers the ULA as the source address for the IPv6
multicast streams. This is NOT a valid option when sending an IPv6 multicast streams. This is NOT a valid option when sending an IPv6
multicast stream to the IPv6 Internet for two reasons. For one, multicast stream to the IPv6 Internet for two reasons. For one,
these addresses are not globally routable so Reverse Path Forwarding these addresses are not globally routable, so Reverse Path Forwarding
checks for such traffic will fail outside the internal network. The checks for such traffic will fail outside the internal network. The
other reason is that the traffic will likely not cross the network other reason is that the traffic will likely not cross the network
boundary due to multicast domain control and perimeter security boundary due to multicast domain control and perimeter security
policies. policies.
In principle ULAs allow easier network mergers than RFC1918 addresses In principle, ULAs allow easier network mergers than RFC 1918
do for IPv4 because ULA prefixes have a high probability of addresses do for IPv4 because ULA prefixes have a high probability of
uniqueness, if the prefix is chosen as described in the RFC. uniqueness, if the prefix is chosen as described in the RFC.
2.3. 6Bone Address Space 2.3. 6bone Address Space
The 6Bone address space was used before the Regional Internet The 6bone address space was used before the Regional Internet
Registries (RIRs) started to distribute 'production' IPv6 prefixes. Registries (RIRs) started to distribute 'production' IPv6 prefixes.
The 6Bone prefixes have a common first 16 bits in the IPv6 Prefix of The 6bone prefixes have a common first 16 bits in the IPv6 Prefix of
[RFC3701] and must not be used on any new IPv6 network deployments. [RFC3701] and must not be used on any new IPv6 network deployments.
Sites using 6bone address space should renumber to production address Sites using 6bone address space should renumber to production address
space using procedures as defined in [RFC4192]. space using procedures as defined in [RFC4192].
2.4. Network Level Design Considerations 2.4. Network-Level Design Considerations
IPv6 provides network administrators with a significantly larger IPv6 provides network administrators with a significantly larger
address space, enabling them to be very creative in how they can address space, enabling them to be very creative in how they can
define logical and practical address plans. The subnetting of define logical and practical addressing plans. The subnetting of
assigned prefixes can be done based on various logical schemes that assigned prefixes can be done based on various logical schemes that
involve factors such as: involve factors such as:
o Using existing systems o Using existing systems
* translate the existing subnet number into IPv6 subnet id
* translate the VLAN id into IPv6 subnet id * translate the existing subnet numbers into IPv6 subnet IDs
* translate the VLAN IDs into IPv6 subnet IDs
o Redesign o Redesign
* allocate according to your need * allocate according to your need
o Aggregation o Aggregation
* Geographical Boundaries - by assigning a common prefix to all * Geographical Boundaries - by assigning a common prefix to all
subnets within a geographical area subnets within a geographical area.
* Organizational Boundaries - by assigning a common prefix to an * Organizational Boundaries - by assigning a common prefix to an
entire organization or group within a corporate infrastructure entire organization or group within a corporate infrastructure.
* Service Type - by reserving certain prefixes for predefined * Service Type - by reserving certain prefixes for predefined
services such as: VoIP, Content Distribution, wireless services such as: VoIP, content distribution, wireless
services, Internet Access, Security areas etc. This type of services, Internet access, security areas, etc. This type of
addressing may create dependencies on IP addresses that can addressing may create dependencies on IP addresses that can
make renumbering harder if the nodes or interfaces supporting make renumbering harder if the nodes or interfaces supporting
those services on the network are sparse within the topology. those services on the network are sparse within the topology.
Such logical addressing plans have the potential to simplify network Such logical addressing plans have the potential to simplify network
operations and service offerings, and to simplify network management operations and service offerings, and to simplify network management
and troubleshooting. A very large network would also have no need to and troubleshooting. A very large network would not need to consider
consider using private address space for its infrastructure devices, using private address space for its infrastructure devices, thereby
simplifying network management. simplifying network management.
The network designer must however keep in mind several factors when The network designer must however keep in mind several factors when
developing these new addressing schemes for networks with and without developing these new addressing schemes for networks with and without
global connectivity: global connectivity:
o Prefix Aggregation - The larger IPv6 addresses can lead to larger o Prefix aggregation - The larger IPv6 addresses can lead to larger
routing tables unless network designers are actively pursuing routing tables unless network designers are actively pursuing
aggregation. While prefix aggregation will be enforced by the aggregation. While prefix aggregation will be enforced by the
service provider, it is beneficial for the individual service provider, it is beneficial for the individual
organizations to observe the same principles in their network organizations to observe the same principles in their network
design process design process.
o Network growth - The allocation mechanism for flexible growth of a o Network growth - The allocation mechanism for flexible growth of a
network prefix, documented in RFC3531 [RFC3531] can be used to network prefix, documented in RFC3531 [RFC3531] can be used to
allow the network infrastructure to grow and be numbered in a way allow the network infrastructure to grow and be numbered in a way
that is likely to preserve aggregation (the plan leaves 'holes' that is likely to preserve aggregation (the plan leaves 'holes'
for growth) for growth).
o ULA usage in large networks - Networks which have a large number
of 'sites' that each deploy a ULA prefix which will by default be o ULA usage in large networks - Networks that have a large number of
a 'random' /48 under fc00::/7 will have no aggregation of those 'sites' that each deploy a ULA prefix that will by default be a
prefixes. Thus the end result may be cumbersome because the '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. network will have large amounts of non-aggregated ULA prefixes.
However, there is no rule to disallow large networks to use a 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 single ULA prefix for all 'sites', as a ULA still provides 16 bits
for subnetting to be used internally for subnetting to be used internally.
o It is possible that as registry policies evolve, a small site may
experience an increase in prefix length when renumbering, e.g. o Compact numbering of small sites - It is possible that as registry
from /48 to /56. For this reason, the best practice is number policies evolve, a small site may experience an increase in prefix
subnets compactly rather than sparsely, and to use low-order bits length when renumbering, e.g., from /48 to /56. For this reason,
as much as possible when numbering subnets. In other words, even the best practice is to number subnets compactly rather than
if a /48 is allocated, act as though only a /56 is available. sparsely, and to use low-order bits as much as possible when
Clearly, this advice does not apply to large sites and enterprises numbering subnets. In other words, even if a /48 is allocated,
that have an intrinsic need for a /48 prefix. act as though only a /56 is available. Clearly, this advice does
o A small site may want to enable routing amongst interfaces not apply to large sites and enterprises that have an intrinsic
connected to a gateway device. For example, a residential gateway need for a /48 prefix.
which receives a /48, is situated in a home with multiple LANs of
different media types (sensor network, wired, wifi, etc.), or has o Consider assigning more than one /64 to a site - A small site may
a need for traffic segmentation (home, work, kids, etc.) and could want to enable routing amongst interfaces connected to a gateway
benefit greatly from multiple subnets and routing in IPv6. device. For example, a residential gateway that receives a /48
Ideally, residential networks would be given an address range of a and is situated in a home with multiple LANs of different media
/48 or /56 [reference2] such that multiple /64 subnets could be types (sensor network, wired, Wi-Fi, etc.), or has a need for
used within the residence. 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 2.4.1. Sizing the Network Allocation
We do not discuss here how a network designer sizes their application We do not discuss here how a network designer sizes their application
for address space. By default a site will receive a /48 prefix for address space. By default, a site will receive a /48 prefix
[RFC3177] , however different RIR service regions policies may [RFC3177]; however, different RIR service regions policies may
suggest alternative default assignments or let the ISPs to decide on suggest alternative default assignments or let the ISPs decide on
what they believe is more appropriate for their specific case [ARIN]. what they believe is more appropriate for their specific case (see
The default provider allocation via the RIRs is currently a /32 Section 6.5.4, "Assignments from LIRs/ISPs", of [ARIN]). The default
[reference2]. These allocations are indicators for a first provider allocation via the RIRs is currently a /32 [RIPE_Nov07].
allocation for a network. Different sizes may be obtained based on These allocations are indicators for a first allocation for a
the anticipated address usage [reference2]. There are examples of network. Different sizes may be obtained based on the anticipated
allocations as large as /19 having been made from RIRs to providers address usage [RIPE_Nov07]. At the time of writing, there are
at the time of writing. examples of allocations as large as /19 having been made from RIRs to
providers.
2.4.2. Address Space Conservation 2.4.2. Address Space Conservation
Despite the large IPv6 address space which enables easier subnetting, Despite the large IPv6 address space, which enables easier
it still is important to ensure an efficient use of this resource. subnetting, it still is important to ensure an efficient use of this
Some addressing schemes, while facilitating aggregation and resource. Some addressing schemes, while facilitating aggregation
management, could lead to significant numbers of addresses being and management, could lead to significant numbers of addresses being
unused. Address conservation requirements are less stringent in IPv6 unused. Address conservation requirements are less stringent in
but they should still be observed. IPv6, but they should still be observed.
The proposed Host-Density (HD) [RFC3194] value for IPv6 is 0.94 The proposed Host-Density (HD) value [RFC3194] for IPv6 is 0.94
compared to the current value of 0.96 for IPv4. Note that for IPv6 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 /48), instead of based HD is calculated for sites (e.g., on a basis of /56), instead of for
on addresses like with IPv4. addresses as with IPv4.
3. Subnet Prefix Considerations 3. Subnet Prefix Considerations
An important part of an IPv4 addressing plan is deciding the length An important part of an IPv4 addressing plan is deciding the length
of each subnet prefix. Unlike in IPv4, the IPv6 addressing of each subnet prefix. Unlike in IPv4, the IPv6 addressing
architecture [RFC4291] specifies that all subnets using Globally architecture [RFC4291] specifies that all subnets using Globally
Unique Addresses and ULAs always have the same prefix length of 64 Unique Addresses and ULAs always have the same prefix length of 64
bits. (This applies also to the deprecated 6Bone and Site Local bits. (This also applies to the deprecated 6bone and site-local
addresses.) addresses.)
The only exception to this rule are special addresses starting with The only exception to this rule are special addresses starting with
the binary value 000, such as IPv4-Compatible IPv6 Addresses. These the binary value 000, such as IPv4-compatible IPv6 addresses. These
exceptions are largely beyond the scope of this document. exceptions are largely beyond the scope of this document.
Using a subnet prefix length other than a /64 will break many Using a subnet prefix length other than a /64 will break many
features of IPv6, amongst other things Neighbor Discovery (ND), features of IPv6, including Neighbor Discovery (ND), Secure Neighbor
Secure Neighborship Discovery (SEND) [RFC3971], privacy extensions Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of
[RFC4941], parts of Mobile IPv6 [RFC4866], PIM-SM with Embedded-RP Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode
[RFC3956], and SHIM6 [SHIM6]. A number of other features currently (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6
in development, or being proposed, also rely on /64 subnet prefixes. 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 Nevertheless, many IPv6 implementations do not prevent the
administrator from configuring a subnet prefix length shorter or administrator from configuring a subnet prefix length shorter or
longer than 64 bits. Using subnet prefixes shorter than /64 would longer than 64 bits. Using subnet prefixes shorter than /64 would
rarely be useful; see Appendix B.1 for discussion. rarely be useful; see Appendix B.1 for discussion.
However, some network administrators have used prefixes longer than However, some network administrators have used prefixes longer than
/64 for links connecting routers, usually just two routers on a /64 for links connecting routers, usually just two routers on a
point-to-point link. On links where all the addresses are assigned point-to-point link. On links where all the addresses are assigned
by manual configuration, and all nodes on the link are routers (not by manual configuration, and all nodes on the link are routers (not
end hosts) that are known by the network administrators do not need 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 any of the IPv6 features that rely on /64 subnet prefixes, this can
work. Using subnet prefixes longer than /64 are not recommended for work. Using subnet prefixes longer than /64 is not recommended for
general use, and using them for links containing end hosts would be general use, and using them for links containing end hosts would be
an especially bad idea, as it is difficult to predict what IPv6 an especially bad idea, as it is difficult to predict what IPv6
features the hosts will use in the future. features the hosts will use in the future.
Appendix B.2 describes some practical considerations that need to be Appendix B.2 describes some practical considerations that need to be
taken into account when using prefixes longer than /64 in limited taken into account when using prefixes longer than /64 in limited
cases. In particular, a number of IPv6 features use interface cases. In particular, a number of IPv6 features use interface
identifiers that have a special form (such as a certain fixed value identifiers that have a special form (such as a certain fixed value
in some bit positions). When using prefixes longer than /64, it is in some bit positions). When using prefixes longer than /64, it is
prudent to avoid certain subnet prefix values so that nodes who prudent to avoid certain subnet prefix values so that nodes who
skipping to change at page 10, line 27 skipping to change at page 9, line 50
addresses in that subnet as having a special form. Appendix B.2 addresses in that subnet as having a special form. Appendix B.2
describes the subnet prefix values that are currently believed to be describes the subnet prefix values that are currently believed to be
potentially problematic; however, the list is not exhaustive and can potentially problematic; however, the list is not exhaustive and can
be expected to grow in the future. be expected to grow in the future.
Using /64 subnets is strongly recommended, also for links connecting Using /64 subnets is strongly recommended, also for links connecting
only routers. A deployment compliant with the current IPv6 only routers. A deployment compliant with the current IPv6
specifications cannot use other prefix lengths. However, the V6OPS specifications cannot use other prefix lengths. However, the V6OPS
WG believes that despite the drawbacks (and a potentially expensive WG believes that despite the drawbacks (and a potentially expensive
network redesign, if IPv6 features relying on /64 subnets are needed network redesign, if IPv6 features relying on /64 subnets are needed
in the future), that some networks administrators will use prefixes in the future), some networks administrators will use prefixes longer
longer than /64. than /64.
3.1. Considerations for /64 Prefixes 3.1. Considerations for /64 Prefixes
Based on RFC3177 [RFC3177], 64 bits is the prescribed subnet prefix Based on RFC3177 [RFC3177], 64 bits is the prescribed subnet prefix
length to allocate to interfaces and nodes. length to allocate to interfaces and nodes.
When using a /64 subnet length, the address assignment for these When using a /64 subnet length, the address assignment for these
addresses can be made either by manual configuration, by a stateful addresses can be made either by manual configuration, by a Dynamic
Host Configuration Protocol [RFC3315] [RFC3736] or by stateless Host Configuration Protocol [RFC3315], by stateless autoconfiguration
autoconfiguration [RFC4862]. [RFC4862], or by a combination thereof [RFC3736].
Note that RFC3177 strongly prescribes 64 bit subnets for general Note that RFC 3177 strongly prescribes 64-bit subnets for general
usage, and that stateless autoconfiguration option is only defined usage, and that stateless autoconfiguration on most link layers
for 64 bit subnets. While in theory it might be possible that some (including Ethernet) is only defined for 64-bit subnets. While in
future autoconfiguration mechanisms would allow longer than 64 bit theory it might be possible that some future autoconfiguration
prefix lengths to be used, the use of such prefixes is not mechanisms would allow longer than 64-bit prefix lengths to be used,
recommended at this time. the use of such prefixes is not recommended at this time.
3.2. Allocation of the IID of an IPv6 Address 4. Allocation of the IID of an IPv6 Address
In order to have a complete IPv6 address, an interface must be In order to have a complete IPv6 address, an interface must be
associated a prefix and an Interface Identifier (IID). Section 3 of associated with a prefix and an Interface Identifier (IID). Section
this document analyzed the prefix selection considerations. This 3 of this document analyzed the prefix selection considerations.
section discusses the elements that should be considered when This section discusses the elements that should be considered when
assigning the IID portion of the IPv6 address. assigning the IID portion of the IPv6 address.
There are various ways to allocate an IPv6 address to a device or There are various ways to allocate an IPv6 address to a device or
interface. The option with the least amount of caveats for the interface. The option with the least amount of caveats for the
network administrator is that of EUI-64 [RFC4862] based addresses. network administrator is that of EUI-64 [RFC4862] based addresses.
For the manual or dynamic options, the overlap with well known IPv6 For the manual or dynamic options, the overlap with well-known IPv6
addresses should be avoided. addresses should be avoided.
3.2.1. Automatic EUI-64 Format Option 4.1. Automatic EUI-64 Format Option
When using this method the network administrator has to allocate a When using this method, the network administrator has to allocate a
valid 64 bit subnet prefix. The EUI-64 [RFC4862] allocation valid 64-bit subnet prefix. Once that allocation has been made, the
procedure can from that moment onward assign the remaining 64 IID EUI-64 [RFC4862] allocation procedure can assign the remaining 64 IID
bits in a stateless manner. All the considerations for selecting a bits in a stateless manner. All the considerations for selecting a
valid IID have been incorporated in the EUI-64 methodology. valid IID have been incorporated into the EUI-64 methodology.
3.2.2. Using Privacy Extensions 4.2. Using Privacy Extensions
The main purpose of IIDs generated based on RFC4941 [RFC4941] is to The main purpose of IIDs generated based on RFC4941 [RFC4941] is to
provide privacy to the entity using this address. While there are no provide privacy to the entity using an IPv6 address. While there are
particular constraints in the usage of these addresses as defined in no particular constraints in the usage of IPv6 addresses with IIDs as
[RFC4941] there are some implications to be aware of when using defined in [RFC4941], there are some implications to be aware of when
privacy addresses as documented in section 4 of RFC4941 [RFC4941] using privacy addresses as documented in Section 4 of RFC 4941
[RFC4941]
3.2.3. Manual/Dynamic Assignment Option 4.3. Manual/Dynamic Assignment Option
This section discusses those IID allocations that are not implemented This section discusses those IID allocations that are not implemented
through stateless address configuration (Section 4.1). They are through stateless address configuration (Section 4.1). They are
applicable regardless of the prefix length used on the link. It is applicable regardless of the prefix length used on the link. It is
out of scope for this section to discuss the various assignment out of scope for this section to discuss the various assignment
methods (e.g. manual configuration, DHCPv6, etc). methods (e.g., manual configuration, DHCPv6, etc).
In this situation the actual allocation is done by human intervention In this situation, the actual allocation is done by human
and consideration needs to be given to the complete IPv6 address so intervention, and consideration needs to be given to the complete
that it does not result in overlaps with any of the well known IPv6 IPv6 address so that it does not result in overlaps with any of the
addresses: well-known IPv6 addresses:
o Subnet Router Anycast Address (Appendix B.2.5.1.)
o Reserved Subnet Anycast Address (Appendix B.2.5.2.)
o Addresses used by Embedded-RP (Appendix B.2.6.)
o ISATAP Addresses (Appendix B.2.7.)
When using an address assigned by human intervention it is o Subnet Router Anycast Address (Appendix B.2.5.1)
recommended to choose IPv6 addresses which are not obvious to guess
and/or avoid any IPv6 addresses that embed IPv4 addresses used in the
current infrastructure. Following these two recommendations will
make it more difficult for malicious third parties to guess targets
for attack, and thus reduce security threats to a certain extent.
3.3. IANA Considerations o Reserved Subnet Anycast Address (Appendix B.2.5.2)
There are no extra IANA consideration for this document. o Addresses used by Embedded-RP (Appendix B.2.6)
3.4. Security Considerations o Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Addresses
(Appendix B.2.7)
When using an address assigned by human intervention, it is
recommended to choose IPv6 addresses that are not obvious to guess
and/or to avoid any IPv6 addresses that embed IPv4 addresses used in
the current infrastructure. Following these two recommendations will
make it more difficult for malicious third parties to guess targets
for attack, and thus reduce security threats to a certain extent.
5. Security Considerations
This document doesn't add any new security considerations that aren't This document doesn't add any new security considerations that aren't
already outlined in the security considerations of the references. already outlined in the security considerations of the references.
It must be noted that using subnet prefixes other than /64 breaks It must be noted that using subnet prefixes other than /64 breaks
security mechanisms such as Cryptographically Generated Addresses security mechanisms such as Cryptographically Generated Addresses
(CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible (CGAs) and Hash-Based Addresses (HBAs), and thus makes it impossible
to use protocols that depend on them. to use protocols that depend on them.
3.5. Acknowledgements 6. Acknowledgements
Constructive feedback and contributions have been received during Constructive feedback and contributions have been received during
IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola, IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola,
John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian
Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny
Listman, Salman Assadullah, Krishnan Thirukonda and the IESG. Listman, Salman Assadullah, Krishnan Thirukonda, and the IESG.
4. References
4.1. Normative References
4.2. Informative References 7. Informative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
E. Lear, "Address Allocation for Private Internets", G., and E. Lear, "Address Allocation for Private
BCP 5, RFC 1918, February 1996. Internets", BCP 5, RFC 1918, February 1996.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet
Addresses", RFC 2526, March 1999. Anycast Addresses", RFC 2526, March 1999.
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links", "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
RFC 3021, December 2000. RFC 3021, December 2000.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento,
Tunnel Broker", RFC 3053, January 2001. "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
via IPv4 Clouds", RFC 3056, February 2001. Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6
Allocations to Sites", RFC 3177, September 2001. Address Allocations to Sites", RFC 3177,
September 2001.
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in
BCP 53, RFC 3180, September 2001. 233/8", BCP 53, RFC 3180, September 2001.
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for [RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for
Address Assignment Efficiency An Update on the H ratio", Address Assignment Efficiency An Update on the H
RFC 3194, November 2001. ratio", RFC 3194, November 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration
IPv6 (DHCPv6)", RFC 3315, July 2003. Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3531] Blanchet, M., "A Flexible Method for Managing the [RFC3531] Blanchet, M., "A Flexible Method for Managing the
Assignment of Bits of an IPv6 Address Block", RFC 3531, Assignment of Bits of an IPv6 Address Block",
April 2003. RFC 3531, April 2003.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6
Unicast Address Format", RFC 3587, August 2003. Global Unicast Address Format", RFC 3587,
August 2003.
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers [RFC3627] Savola, P., "Use of /127 Prefix Length Between
Considered Harmful", RFC 3627, September 2003. Routers Considered Harmful", RFC 3627,
September 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for
Host Configuration Protocol (DHCP) version 6", RFC 3633, Dynamic Host Configuration Protocol (DHCP) version
December 2003. 6", RFC 3633, December 2003.
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
Allocation) Phaseout", RFC 3701, March 2004. Allocation) Phaseout", RFC 3701, March 2004.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration
(DHCP) Service for IPv6", RFC 3736, April 2004. Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
Neighbor Discovery (SEND)", RFC 3971, March 2005. "SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day",
September 2005. RFC 4192, September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6
Addresses", RFC 4193, October 2005. Unicast Addresses", RFC 4193, October 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005. Multihoming Solutions", RFC 4218, October 2005.
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6)
Should Think About", RFC 4219, October 2005. Developers Should Think About", RFC 4219,
October 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Configuration Protocol (DHCP): IPv4 and IPv6 Dual-
Issues", RFC 4477, May 2006. Stack Issues", RFC 4477, May 2006.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Faucheur, "Connecting IPv6 Islands over IPv4 MPLS
Provider Edge Routers (6PE)", RFC 4798, February 2007. Using IPv6 Provider Edge Routers (6PE)", RFC 4798,
February 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Address Autoconfiguration", RFC 4862, September 2007. Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007. Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)",
March 2008. RFC 5214, March 2008.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008. RFC 5157, March 2008.
[SHIM6] IETF, [SHIM6] IETF, "Site Multihoming by IPv6 Intermediation
"http://www.ietf.org/html.charters/shim6-charter.html". (shim6) Charter", <http://www.ietf.org/html.charters/
shim6-charter.html>.
[ARIN] ARIN, "http://www.arin.net/policy/nrpm.html#six54".
[reference2] [ARIN] ARIN, "ARIN Number Resource Policy Manual",
APNIC, ARIN, RIPE NCC, "www.ripe.net/ripe/docs/ Version 2008.4, September 2008,
ipv6policy.html", July 2007. <http://www.arin.net/policy/nrpm.html>.
[reference3] [RIPE_Nov07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and
APNIC, ARIN, RIPE NCC, Assignment Policy", ripe-421, November 2007,
"http://www.ripe.net/ripe/docs/ripe-412.html", July 2007. <http://www.ripe.net/ripe/docs/ipv6policy.html>.
[reference4] [RIPE_Jul07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and
ARIN, "http://www.arin.net/policy/nrpm.html#ipv6", Assignment Policy", ripe-412, July 2007,
March 2008. <http://www.ripe.net/ripe/docs/ripe-412.html>.
[reference5] [APNIC_IPv6] APNIC, "IPv6 Address Allocation and Assignment
APNIC, Policy", APNIC-089, August 2008, <http://
"http://www.apnic.net/policy/ipv6-address-policy.html", www.apnic.net/policy/ipv6-address-policy.html>.
March 2007.
[reference6] [LACNIC_IPv6] LACNIC, "Internet Resource Management Policies in
LACNIC, "http://lacnic.net/en/politicas/ipv6.html". Latin America and the Caribbean: IPv6 Address
Allocation and Assignment Policy",
<http://lacnic.net/en/politicas/ipv6.html>.
[reference7] [AFRINIC_IPv6] AfriNIC, "AfriNIC IPv6 Address Allocation and
AFRINIC, "http://www.afrinic.net/docs/policies/ Assignment Policy", March 2004,
afpol-v6200407-000.htm", March 2004. <http://www.afrinic.net/docs/policies/
afpol-v6200407-000.htm>.
[THINKABOUT] [THINKABOUT] Chown, T., Thompson, M., Ford, A., and S. Venaas,
Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things "Things to think about when Renumbering an IPv6
to think about when Renumbering an IPv6 network network", Work in Progress, March 2007.
(draft-chown-v6ops-renumber-thinkabout-05.txt)",
March 2007.
Appendix A. Case Studies Appendix A. Case Studies
This appendix contains two case studies for IPv6 addressing schemas This appendix contains two case studies for IPv6 addressing schemas
that have been based on the statements and considerations of this that have been based on the statements and considerations of this
draft. These case studies illustrate how this draft has been used in document. These case studies illustrate how this document has been
two specific network scenarios. The case studies may serve as basic used in two specific network scenarios. The case studies may serve
considerations for an administrator who designs the IPv6 addressing as basic considerations for an administrator who designs the IPv6
schema for an enterprise or ISP network, but are not intended to addressing schema for an enterprise or ISP network, but are not
serve as general design proposal for every kind of IPv6 network. All intended to serve as a general design proposal for every kind of IPv6
subnet sizes used in this appendix are for practical visualization network. All subnet sizes used in this appendix are for practical
and do not dictate RIR policy. visualization and do not dictate RIR policy.
A.1. Enterprise Considerations A.1. Enterprise Considerations
In this section one considers a case study of a campus network that In this section, one considers a case study of a campus network that
is deploying IPv6 in parallel with existing IPv4 protocols in a dual- is deploying IPv6 in parallel with existing IPv4 protocols in a dual-
stack environment. The specific example is the University of stack environment. The specific example is the University of
Southampton (UK), focusing on a large department within that network. Southampton (UK), focusing on a large department within that network.
The deployment currently spans around 1,000 hosts and over 1,500 The deployment currently spans around 1,000 hosts and over 1,500
users. users.
A.1.1. Obtaining General IPv6 Network Prefixes A.1.1. Obtaining General IPv6 Network Prefixes
In the case of a campus network, the site will typically take its In the case of a campus network, the site will typically take its
connectivity from its National Research and Education Network (NREN). connectivity from its National Research and Education Network (NREN).
Southampton connects to JANET, the UK academic network, via its local Southampton connects to JANET, the UK academic network, via its local
regional network LeNSE. JANET currently has a /32 allocation from regional network LeNSE (Learning Network South East). JANET
RIPE NCC. The current recommended practice is for sites to receive a currently has a /32 allocation from RIPE NCC. The current
/48 allocation, and on this basis Southampton has received such a recommended practice is for sites to receive a /48 allocation; on
prefix for its own use. The regional network also uses its own this basis, Southampton has received such a prefix for its own use.
allocation from the NREN provider. The regional network also uses its own allocation from the NREN
provider.
No ULA addressing is used on site. The campus is not multihomed No ULA addressing is used on site. The campus is not multihomed
(JANET is the sole provider), nor does it expect to change service (JANET is the sole provider), nor does it expect to change service
provider, and thus does not plan to use ULAs for the (perceived) provider, and thus does not plan to use ULAs for the (perceived)
benefit of easing network renumbering. Indeed, the campus has benefit of easing network renumbering. Indeed, the campus has
renumbered following the aforementioned renumbering procedure renumbered following the aforementioned renumbering procedure
[RFC4192] on two occasions, and this has proven adequate (with [RFC4192] on two occasions, and this has proven adequate (with
provisos documented in [THINKABOUT]. The campus do not see any need provisos documented in [THINKABOUT]). The campus does not see any
to deploy ULAs for in or out of band network management; there are need to deploy ULAs for in-band or out-of-band network management;
enough IPv6 prefixes available in the site allocation for the there are enough IPv6 prefixes available in the site allocation for
infrastructure. In some cases, use of private IP address space in the infrastructure. In some cases, use of private IP address space
IPv4 creates problems, so University of Southampton believe that the in IPv4 creates problems, so University of Southampton believes that
availability of ample global IPv6 address space for infrastructure the availability of ample global IPv6 address space for
may be a benefit for many sites. infrastructure may be a benefit for many sites.
No 6bone addressing is used on site any more. Since the 6bone No 6bone addressing is used on site any more. Since the 6bone
phaseout of June 2006 [RFC3701] most transit ISPs have begun phaseout of June 2006 [RFC3701], most transit ISPs have begun
filtering attempted use of such prefixes. filtering attempted use of such prefixes.
Southampton does participate in global and organization scope IPv6 Southampton does participate in global and organizational scope IPv6
multicast networks. Multicast address allocations are not discussed multicast networks. Multicast address allocations are not discussed
here as they are not in scope for the document. It is noted that here as they are not in scope for the document. It is noted that
IPv6 has advantages for multicast group address allocation. In IPv4 IPv6 has advantages for multicast group address allocation. In IPv4,
a site needs to use techniques like GLOP [RFC3180] to pick a globally a site needs to use techniques like GLOP [RFC3180] to pick a globally
unique multicast group to use. This is problematic if the site does unique multicast group to use. This is problematic if the site does
not use Border Gateway Protocol (BGP) [RFC4271] and have an not use the Border Gateway Protocol (BGP) [RFC4271] and does not have
Autonomous System Number (ASN). In IPv6 unicast-prefix-based IPv6 an Autonomous System Number (ASN). In IPv6,0 unicast-prefix-based
multicast addresses empower a site to pick a globally unique group IPv6 multicast addresses empower a site to pick a globally unique
address based on its unicast own site or link prefix. Embedded RP is group address based on its own unicast site or link prefix.
also in use, is seen as a potential advantage for IPv6 and multicast, Embedded-RP is also in use, is seen as a potential advantage for IPv6
and has been tested successfully across providers between sites and multicast, and has been tested successfully across providers
(including paths to/from the US and UK). between sites (including paths to/from the US and UK).
A.1.2. Forming an Address (subnet) Allocation Plan A.1.2. Forming an Address (Subnet) Allocation Plan
The campus has a /16 prefix for IPv4 use; in principle 256 subnets of The campus has a /16 prefix for IPv4 use; in principle, 256 subnets
256 addresses. In reality the subnetting is muddier, because of of 256 addresses. In reality, the subnetting is muddier, because of
concerns of IPv4 address conservation; subnets are sized to the hosts concerns of IPv4 address conservation; subnets are sized to the hosts
within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts within them, e.g., a /26 IPv4 prefix is used if a subnet has 35 hosts
in it. While this is efficient, it increases management burden when in it. While this is efficient, it increases management burden when
physical deployments change, and IPv4 subnets require resizing (up or physical deployments change, and IPv4 subnets require resizing (up or
down), even with DHCP in use. down), even when DHCP is in use.
The /48 IPv6 prefix is considerably larger than the IPv4 allocation The /48 IPv6 prefix is considerably larger than the IPv4 allocation
already in place at the site. It is loosely equivalent to a 'Class already in place at the site. It is loosely equivalent to a 'Class
A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an
effectively unlimited subnet address size (2^64) compared to 256 in effectively unlimited subnet address size (2^64) compared to 256 in
the IPv4 equivalent. The increased subnet size means that /64 IPv6 the IPv4 equivalent. The increased subnet size means that /64 IPv6
prefixes can be used on all subnets, without any requirement to prefixes can be used on all subnets, without any requirement to
resize them at a later date. The increased subnet volume allows resize them at a later date. The increased subnet volume allows
subnets to be allocated more generously to schools and departments in subnets to be allocated more generously to schools and departments in
the campus. While address conservation is still important, it is no the campus. While address conservation is still important, it is no
longer an impediment on network management. Rather, address (subnet) longer an impediment to network management. Rather, address (subnet)
allocation is more about embracing the available address space and allocation is more about embracing the available address space and
planning for future expansion. planning for future expansion.
In a dual-stack network, it was chosen to deploy our IP subnets In a dual-stack network, it was chosen to deploy the IP subnets
congruently for IPv4 and IPv6. This is because the systems are still congruently for IPv4 and IPv6. This is because the systems are still
in the same administrative domains and the same geography. It is not in the same administrative domains and the same geography. It is not
expected to have IPv6-only subnets in production use for a while yet, expected to have IPv6-only subnets in production use for a while yet,
outside the test beds and some early Mobile IPv6 trials. With outside the test beds and some early Mobile IPv6 trials. With
congruent addressing, our firewall policies are also aligned for IPv4 congruent addressing, the firewall policies are also aligned for IPv4
and IPv6 traffic at the site border. and IPv6 traffic at the site border.
The subnet allocation plan required a division of the address space The subnet allocation plan required a division of the address space
per school or department. Here a /56 was allocated to the school per school or department. Here, a /56 was allocated to the school
level of the university; there are around 30 schools currently. A level of the university; there are around 30 schools currently. A
/56 of IPv6 address space equates to 256 /64 size subnet allocations. /56 of IPv6 address space equates to 256 /64 subnet allocations.
Further /56 allocations were made for central IT infrastructure, for Further /56 allocations were made for central IT infrastructure, the
the network infrastructure and the server side systems. network infrastructure, and the server side systems.
A.1.3. Other Considerations A.1.3. Other Considerations
The network uses a Demilitarized Zone (DMZ) topology for some level The network uses a Demilitarized Zone (DMZ) topology for some level
of protection of 'public' systems. Again, this topology is congruent of protection of 'public' systems. Again, this topology is congruent
with the IPv4 network. with the IPv4 network.
There are no specific transition methods deployed internally to the There are no specific transition methods deployed internally to the
campus; everything is using the conventional dual-stack approach. campus; everything is using the conventional dual-stack approach.
There is no use of ISATAP [RFC5214] for example. There is no use of ISATAP [RFC5214] for example.
For the Mobile IPv6 early trials there is one allocated prefix for For the Mobile IPv6 early trials, there is one allocated prefix for
Home Agent (HA) use. However there has been no detailed Home Agent (HA) use. However, there has been no detailed
consideration yet how Mobile IPv6 usage may grow, and whether more or consideration yet regarding how Mobile IPv6 usage may grow, and
even every subnet will require HA support. whether more subnets (or even every subnet) will require HA support.
The university operates a tunnel broker [RFC3053] service on behalf The university operates a tunnel broker [RFC3053] service on behalf
of UKERNA for JANET sites. This uses separate address space from of the United Kingdom Education and Research Network Association
JANET, not our university site allocation. (UKERNA) for JANET sites. This uses separate address space from
JANET, not the university site allocation.
A.1.4. Node Configuration Considerations A.1.4. Node Configuration Considerations
Currently stateless autoconfiguration is used on most subnets for Currently, stateless autoconfiguration is used on most subnets for
IPv6 hosts. There is no DHCPv6 service deployed yet, beyond tests of IPv6 hosts. There is no DHCPv6 service deployed yet, beyond tests of
early code releases. It is planned to deploy DHCPv6 for address early code releases. It is planned to deploy DHCPv6 for address
assignment when robust client and server code is available (at the assignment when robust client and server code is available (at the
time of writing the potential for this looks good, e.g. via the ISC time of writing, the potential for this looks good, e.g., via the
implementation). University of Southampton is also investigating a Internet Systems Consortium (ISC) implementation). University of
common integrated DHCP/DNS management platform, even if the servers Southampton is also investigating a common integrated DHCP/DNS
themselves are not co-located, including integrated DHCPv4 and DHCPv6 management platform, even if the servers themselves are not co-
server configuration, as discussed in [RFC4477]. Currently clients located, including integrated DHCPv4 and DHCPv6 server configuration,
with statelessly autoconfigured addresses are added to the DNS as discussed in [RFC4477]. Currently, clients with statelessly
manually, though dynamic DNS is an option. The network autoconfigured addresses are added to the DNS manually, though
administrators would prefer the use of DHCP because they believe it dynamic DNS is an option. The network administrators would prefer
gives them more management control. the use of DHCP because they believe it gives them more management
control.
Regarding the implications of the larger IPv6 subnet address space on Regarding the implications of the larger IPv6 subnet address space on
scanning attacks [RFC5157], it is noted that all the hosts are dual- scanning attacks [RFC5157], it is noted that all the hosts are dual-
stack, and thus are potentially exposed over both protocols anyway. stack, and thus are potentially exposed over both protocols anyway.
All addresses or published in DNS, and hence do not operate a two All addresses are published in DNS, and the site does not operate a
faced DNS. two-faced DNS.
There is internal usage of RFC4941 privacy addresses [RFC4941] Currently, there is internal usage of RFC 4941 privacy addresses
currently (certain platforms currently ship with it on by default), [RFC4941] (certain platforms ship with it on by default), but network
but may desire to administratively disable this (perhaps via DHCP) to administrators may desire to disable this (perhaps via DHCP) to ease
ease management complexity. However, it is desired to determine the management complexity. However, it is desired to determine the
feasibility of this on all systems, e.g. for guests on wireless LAN feasibility of this on all systems, e.g., for guests on wireless LAN
or other user-maintained systems. Network management and monitoring or other user-maintained systems. Network management and monitoring
should be simpler without RFC4941 in operation, in terms of should be simpler without RFC4941 in operation, in terms of
identifying which physical hosts are using which addresses. Note identifying which physical hosts are using which addresses. Note
that RFC4941 is only an issue for outbound connections, and that that RFC4941 is only an issue for outbound connections, and that
there is potential to assign privacy addresses via DHCPv6. there is potential to assign privacy addresses via DHCPv6.
Manually configured server addresses are used to avoid address Manually configured server addresses are used to avoid address
changes based upon change of network adaptor. With IPv6 you can changes based upon change of network adaptor. With IPv6 you can pick
choose to pick ::53 for a DNS server, or can pick 'random' addresses ::53 for a DNS server, or you can pick 'random' addresses for
for obfuscation, though that's not an issue for publicly advertised obfuscation, though that's not an issue for publicly advertised
addresses (dns, mx, web, etc). addresses (dns, mx, web, etc.).
A.2. Service Provider Considerations A.2. Service Provider Considerations
In this section an IPv6 addressing schema is sketched that could In this section an IPv6 addressing schema is sketched that could
serve as an example for an Internet Service Provider. serve as an example for an Internet Service Provider.
Sub-section A.2.1 starts with some thoughts regarding objective Appendix A.2.1 starts with some thoughts regarding objective
requirements of such an addressing schema and derives a few general requirements of such an addressing schema and derives a few general
rules of thumb that have to be kept in mind when designing an ISP rules of thumb that have to be kept in mind when designing an ISP
IPv6 addressing plan. IPv6 addressing plan.
Sub-section A.2.2 illustrates these findings of A.2.1 with an Appendix A.2.2 illustrates the findings of Appendix A.2.1 with an
exemplary IPv6 addressing schema for an MPLS-based ISP offering exemplary IPv6 addressing schema for an MPLS-based ISP offering
Internet Services as well as Network Access services to several Internet services as well as network access services to several
millions of customers. millions of customers.
A.2.1. Investigation of objective Requirements for an IPv6 addressing A.2.1. Investigation of Objective Requirements for an IPv6 Addressing
schema of a Service Provider Schema of a Service Provider
The first step of the IPv6 addressing plan design for a Service The first step of the IPv6 addressing plan design for a service
provider should identify all technical, operational, political and provider should identify all technical, operational, political, and
business requirements that have to be satisfied by the services business requirements that have to be satisfied by the services
supported by this addressing schema. supported by this addressing schema.
According to the different technical constraints and business models According to the different technical constraints and business models
as well as the different weights of these requirements (from the as well as the different weights of these requirements (from the
point of view of the corresponding Service Provider) it is very point of view of the corresponding service provider), it is very
likely that different addressing schemas will be developed and likely that different addressing schemas will be developed and
deployed by different ISPs. Nevertheless the addressing schema of deployed by different ISPs. Nevertheless, the addressing schema of
sub-section A.2.2 is one possible example. Appendix A.2.2 is one possible example.
For this document it is assumed that our exemplary ISP has to fulfill For this document, it is assumed that our exemplary ISP has to
several roles for its customers as there are: fulfill several roles for its customers such as:
o Local Internet Registry o Local Internet Registry
o Network Access Provider o Network Access Provider
o Internet Service Provider o Internet Service Provider
A.2.1.1. Recommendations for an IPv6 Addressing Schema from the LIR A.2.1.1. Recommendations for an IPv6 Addressing Schema from the LIR
Perspective of the Service Provider Perspective of the Service Provider
In their role as Local Internet Registry (LIR) the Service Providers In its role as Local Internet Registry (LIR), the service provider
have to care about the policy constraints of the RIRs and the has to care about the policy constraints of the RIRs and the
standards of the IETF regarding IPv6 addressing. In this context, standards of the IETF regarding IPv6 addressing. In this context,
the following basic recommendations have to be considered and should the following basic recommendations have to be considered and should
be satisfied by the IPv6 address allocation plan of a Service be satisfied by the IPv6 address allocation plan of a service
Provider: provider:
o As recommended in RFC 3177 [RFC3177] and in several RIR policies
o As recommended in RFC 3177 [RFC3177] and in several RIR policies,
"Common" customers sites (normally private customers) should "Common" customers sites (normally private customers) should
receive a /48 prefix from the aggregate of the Service Provider. receive a /48 prefix from the aggregate of the service provider.
(Note: The addressing plan must be flexible enough and take into (Note: The addressing plan must be flexible enough and take into
account the possible change of the minimum allocation size for end account the possible change of the minimum allocation size for end
users currently under definition by the RIRs.) users currently under definition by the RIRs.)
o "Big customers" (like big enterprises, governmental agencies etc.)
may receive shorter prefixes according to their needs when this o "Big customers" (like big enterprises, governmental agencies,
need could be documented and justified to the RIR. etc.) may receive shorter prefixes according to their needs, when
their needs can be documented and justified to the RIR.
o The IPv6 address allocation schema has to be able to meet the HD- o The IPv6 address allocation schema has to be able to meet the HD-
ratio that is proposed for IPv6. This requirement corresponds to ratio that is proposed for IPv6. This requirement corresponds to
the demand for an efficient usage of the IPv6 address aggregate by the demand for an efficient usage of the IPv6 address aggregate by
the Service Provider. (Note: The currently valid IPv6 HD-ratio of the service provider. (Note: The currently valid IPv6 HD-ratio of
0.94 means an effective usage of about 31% of a /20 prefix of the 0.94 means an effective usage rate of about 22% of a /20 prefix of
Service Provider on the basis of /48 assignments.) the service provider, on the basis of /56 assignments.)
o All assignments to customers have to be documented and stored into o All assignments to customers have to be documented and stored into
a database that can also be queried by the RIR. a database that can also be queried by the RIR.
o The LIR has to make available means for supporting the reverse DNS
mapping of the customer prefixes. o The LIR has to make available the means for supporting the reverse
DNS mapping of the customer prefixes.
o IPv6 Address Allocation and Assignment Policies can be found at o IPv6 Address Allocation and Assignment Policies can be found at
RIRs and are similar in many aspects: RIRs and are similar in many aspects. See [RIPE_Nov07],
[reference2][reference3][reference4] [reference5][reference6] [RIPE_Jul07], [APNIC_IPv6], [LACNIC_IPv6], [AFRINIC_IPv6], and
Section 6 of [ARIN].
A.2.1.2. IPv6 Addressing Schema Recommendations from the ISP A.2.1.2. IPv6 Addressing Schema Recommendations from the ISP
Perspective of the Service Provider Perspective of the Service Provider
From ISP perspective the following basic requirements could be From the ISP perspective, the following basic requirements can be
identified: identified:
o The IPv6 address allocation schema must be able to realize a o The IPv6 address allocation schema must be able to realize a
maximal aggregation of all IPv6 address delegations to customers maximal aggregation of all IPv6 address delegations to customers
into the address aggregate of the Service Provider. Only this into the address aggregate of the service provider. Only this
provider aggregate will be routed and injected into the global provider aggregate will be routed and injected into the global
routing table (DFZ). This strong aggregation keeps the routing routing table (DFZ, "Default-Free Zone"). This strong aggregation
tables of the DFZ small and eases filtering and access control keeps the routing tables of the DFZ small and eases filtering and
very much. access control very much.
o The IPv6 addressing schema of the SP should contain optimal o The IPv6 addressing schema of the SP should contain optimal
flexibility since the infrastructure of the SP will change over flexibility since the infrastructure of the SP will change over
the time with new customers, transport technologies and business time with new customers, transport technologies, and business
cases. The requirement of optimal flexibility is contrary to the cases. The requirement of optimal flexibility is contrary to the
recommendation of strong IPv6 address aggregation and efficient recommendation of strong IPv6 address aggregation and efficient
address usage, but at this point each SP has to decide which of address usage, but each SP has to decide which of these
these requirements to prioritize. requirements to prioritize.
o Keeping the multilevel network hierarchy of an ISP in mind, due to
addressing efficiency reasons not all hierarchy levels can and o While keeping the multilevel network hierarchy of an ISP in mind,
should be mapped into the IPv6 addressing schema of an ISP. note that due to addressing efficiency reasons, not all hierarchy
Sometimes it is much better to implement a more "flat" addressing levels can and should be mapped into the IPv6 addressing schema of
for the ISP network than to loose big chunks of the IPv6 address an ISP. Sometimes it is much better to implement a more "flat"
aggregate in addressing each level of network hierarchy. (Note: addressing for the ISP network than to lose big chunks of the IPv6
In special cases it is even recommendable for really "small" ISPs address aggregate in addressing each level of network hierarchy.
to design and implement a totally flat IPv6 addressing schema (Note: In special cases, it is even recommended for really "small"
ISPs to design and implement a totally flat IPv6 addressing schema
without any level of hierarchy.) without any level of hierarchy.)
o Besides that a decoupling of provider network addressing and
customer addressing is recommended. (Note: A strong aggregation o A decoupling of provider network addressing and customer
e.g. on POP, aggregation router or Label Edge Router (LER) level addressing is recommended. (Note: A strong aggregation (e.g., on
POP, Aggregation Router (AG), or Label Edge Router (LER) level)
limits the numbers of customer routes that are visible within the limits the numbers of customer routes that are visible within the
ISP network but brings also down the efficiency of the IPv6 ISP network, but also brings down the efficiency of the IPv6
addressing schema. That's why each ISP has to decide how many addressing schema. That's why each ISP has to decide how many
internal aggregation levels it wants to deploy.) internal aggregation levels it wants to deploy.)
A.2.1.3. IPv6 Addressing Schema Recommendations from the Network Access A.2.1.3. IPv6 Addressing Schema Recommendations from the Network Access
provider Perspective of the Service Provider Provider Perspective of the Service Provider
As already done for the LIR and the ISP roles of the SP it is also As already done for the LIR and the ISP roles of the SP it is also
necessary to identify requirements that come from its Network Access necessary to identify requirements that come from its Network Access
Provider role. Some of the basic requirements are: Provider role. Some of the basic requirements are:
o The IPv6 addressing schema of the SP must be chosen in a way that
it can handle new requirements that are triggered from customer o The IPv6 addressing schema of the SP, it must be chosen in a way
side. This can be for instance the growing needs of the customers that it can handle new requirements that are triggered from
regarding IPv6 addresses as well as customer driven modifications customer side. For instance, this can be the customer's growing
within the access network topology (e.g. when the customer moves needs for IPv6 addresses as well as customer-driven modifications
within the access network topology (e.g., when the customer moves
from one point of network attachment (POP) to another). (See from one point of network attachment (POP) to another). (See
section A.2.3.4 "Changing Point of Network Attachment".) Appendix A.2.3.4, "Changing the Point of Network Attachment".)
o For each IPv6 address assignment to customers a "buffer zone"
o For each IPv6 address assignment to customers, a "buffer zone"
should be reserved that allows the customer to grow in its should be reserved that allows the customer to grow in its
addressing range without renumbering or assignment of additional addressing range without renumbering or assignment of additional
prefixes. prefixes.
o The IPv6 addressing schema of the SP must deal with multiple-
o The IPv6 addressing schema of the SP must deal with multiple
attachments of a single customer to the SP network infrastructure attachments of a single customer to the SP network infrastructure
(i.e. multi-homed network access with the same SP). (i.e., multihomed network access with the same SP).
These few requirements are only part of all the requirements a These few requirements are only part of the requirements a service
Service Provider has to investigate and keep in mind during the provider has to investigate and keep in mind during the definition
definition phase of its addressing architecture. Each SP will most phase of its addressing architecture. Each SP will most likely add
likely add more constraints to this list. more constraints to this list.
A.2.1.4. A Few Rules of Thumb for Designing an IPv6 ISP Addressing A.2.1.4. A Few Rules of Thumb for Designing an ISP IPv6 Addressing
Architecture Architecture
As outcome of the above enumeration of requirements regarding an ISP As a result of the above enumeration of requirements regarding an ISP
IPv6 addressing plan the following design "rules of thumb" have been IPv6 addressing plan, the following design "rules of thumb" have been
derived: derived:
o No "One size fits all". Each ISP must develop its own IPv6 o No "One size fits all". Each ISP must develop its own IPv6
address allocation schema depending on its concrete business address allocation schema depending on its concrete business
needs. It is not practicable to design one addressing plan that needs. It is not practical to design one addressing plan that
fits for all kinds of ISPs (Small / big, Routed / MPLS-based, fits for all kinds of ISPs (small / big, routed / MPLS-based,
access / transit, LIR / No-LIR, etc.). access / transit, LIR / No LIR, etc.).
o The levels of IPv6 address aggregation within the ISP addressing o The levels of IPv6 address aggregation within the ISP addressing
schema should strongly correspond to the implemented network schema should strongly correspond to the implemented network
structure and their number should be minimized because of structure, and their number should be minimized because of
efficiency reasons. It is assumed that the SPs own infrastructure efficiency reasons. It is assumed that the SP's own
will be addressed in a fairly flat way whereas the part of the infrastructure will be addressed in a fairly flat way, whereas
customer addressing architecture should contain several levels of part of the customer addressing architecture should contain
aggregation. several levels of aggregation.
o Keep the number of IPv6 customer routes inside your network as o Keep the number of IPv6 customer routes inside your network as
small as necessary. A totally flat customer IPv6 addressing small as possible. A totally flat customer IPv6 addressing
architecture without any intermediate aggregation level will lead architecture without any intermediate aggregation level will lead
to lots of customer routes inside the SP network. A fair trade- to lots of customer routes inside the SP network. A fair trade-
off between address aggregation levels (and hence the size of the off between address aggregation levels (and hence the size of the
internal routing table of the SP) and address conservation of the internal routing table of the SP) and address conservation of the
addressing architecture has to be found. addressing architecture has to be found.
o The ISP IPv6 addressing schema should provide maximal flexibility. o The ISP IPv6 addressing schema should provide maximal flexibility.
This has to be realized for supporting different sizes of customer This has to be realized for supporting different sizes of customer
IPv6 address aggregates ("big" customers vs. "small" customers) as IPv6 address aggregates ("big" customers vs. "small" customers) as
well as to allow future growing rates (e.g. of customer well as to allow future growth rates (e.g., of customer
aggregates) and possible topological or infrastructural changes. aggregates) and possible topological or infrastructural changes.
o A limited number of aggregation levels and sizes of customer o A limited number of aggregation levels and sizes of customer
aggregates will ease the management of the addressing schema. aggregates will ease the management of the addressing schema.
This has to be weighed against the previous "thumb rule" - This has to be weighed against the previous "rule of thumb" --
flexibility. flexibility.
A.2.2. Exemplary IPv6 Address Allocation Plan for a Service Provider A.2.2. Exemplary IPv6 Address Allocation Plan for a Service Provider
In this example, the Service Provider is assumed to operate an MPLS In this example, the service provider is assumed to operate an MPLS-
based backbone and implements 6PE [RFC4798] to provide IPv6 backbone based backbone and to implement IPv6 Provider Edge Routers (6PE)
transport between the different locations (POPs) of a fully dual- [RFC4798] to provide IPv6 backbone transport between the different
stacked network access and aggregation area. locations (POPs) of a fully dual-stacked network access and
aggregation area.
In addition, it is assumed that the service provider:
Besides that it is assumed that the Service Provider:
o has received a /20 from its RIR o has received a /20 from its RIR
o operates its own LIR o operates its own LIR
o has to address its own IPv6 infrastructure o has to address its own IPv6 infrastructure
o delegates prefixes from this aggregate to its customers o delegates prefixes from this aggregate to its customers
This addressing schema should illustrate how the /20 IPv6 prefix of This addressing schema should illustrate how the /20 IPv6 prefix of
the SP can be used to address the SP-own infrastructure and to the SP can be used to address the SP's own infrastructure and to
delegate IPv6 prefixes to its customers following the above mentioned delegate IPv6 prefixes to its customers, following the above-
requirements and rules of thumb as far as possible. mentioned requirements and rules of thumb as far as possible.
The below figure summarizes the device types in a SP network and the The figure below summarizes the device types in an SP network and the
typical network design of a MPLS-based service provider. The network typical network design of a MPLS-based service provider. The network
hierarchy of the SP has to be taken into account for the design of an hierarchy of the SP has to be taken into account for the design of an
IPv6 addressing schema and defines its basic shape and the various IPv6 addressing schema; it defines the basic shape of the addressing
levels of aggregation. schema and the various levels of aggregation.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| LSRs of the MPLS Backbone of the SP | | LSRs of the MPLS Backbone of the SP |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | | | | | | | | |
| | | | | | | | | |
+-----+ +-----+ +--------+ +--------+ +--------+ +-----+ +-----+ +--------+ +--------+ +--------+
| LER | | LER | | LER-BB | | LER-BB | | LER-BB | | LER | | LER | | LER-BB | | LER-BB | | LER-BB |
+-----+ +-----+ +--------+ +--------+ +--------+ +-----+ +-----+ +--------+ +--------+ +--------+
| | | | | | / | | | | | | | | | / | | |
skipping to change at page 23, line 28 skipping to change at page 24, line 34
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | RAR | | RAR | | RAR | | RAR | | | | | | | | | | RAR | | RAR | | RAR | | RAR |
| | | | | | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Customer networks | | Customer networks |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure: Exemplary Service Provider Network
LSR ... Label Switch Router LSR Label Switch Router
LER ... Label Edge Router LER Label Edge Router
LER-BB ... Broadband Label Edge Router LER-BB Broadband Label Edge Router
RAR ... Remote Access Router RAR Remote Access Router
BB-RAR ... Broadband Remote Access Router BB-RAR Broadband Remote Access Router
AG ... Aggregation Router AG Aggregation Router
Exemplary Service Provider Network
The following should be taken into consideration when making the
basic design decisions for the exemplary service provider IPv6
addressing plan regarding customer prefixes.
o The prefixes assigned to all customers behind the same LER (or
LER-BB) are aggregated under one LER prefix. This ensures that
the number of labels that have to be used for 6PE is limited and
hence provides strong MPLS label conservation.
Basic design decisions for the exemplary Service Provider IPv6
address plan regarding customer prefixes take into consideration:
o The prefixes assigned to all customers behind the same LER (e.g.
LER or LER-BB) are aggregated under one LER prefix. This ensures
that the number of labels that have to be used for 6PE is limited
and hence provides a strong MPLS label conservation.
o The /20 prefix of the SP is separated into 3 different pools that o The /20 prefix of the SP is separated into 3 different pools that
are used to allocate IPv6 prefixes to the customers of the SP: are used to allocate IPv6 prefixes to the customers of the SP:
* A pool (e.g. /24) for satisfying the addressing needs of really
"big" customers (as defined in A.2.2.1 sub-section A.) that
need IPv6 prefixes larger than /48 (e.g. /32). These customers
are assumed to be connected to several POPs of the access
network, so that this customer prefix will be visible in each
of these POPs.
* A pool (e.g. /24) for the LERs with direct customer connections 1. A pool (e.g., /24) for satisfying the addressing needs of
(e.g. dedicated line access) and without an additional really "big" customers (as defined in Appendix A.2.2.1.1) that
aggregation area between the customer and the LER. (These LERs need IPv6 prefixes larger than /48 (e.g., /32). These
are mostly connected to a limited number of customers because customers are assumed to be connected to several POPs of the
of the limited number of interfaces/ports.) access network, so that this customer prefix will be visible
* A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve in each of these POPs.
a high number of customers that are normally connected via some
kind of aggregation network (e.g. DSL customers behind a BB- 2. A pool (e.g., /24) for the LERs with direct customer
RAR or Dial-In customers behind a RAR). connections (e.g., dedicated line access) and without an
* The IPv6 address delegation within each Pool (end customer additional aggregation area between the customer and the LER.
delegation or also the aggregates that are dedicated to the (These LERs are mostly connected to a limited number of
LERs itself) should be chosen with an additional buffer zone of customers because of the limited number of interfaces/ports.)
100% - 300% for future growth. I.e. 1 or 2 additional prefix
bits should be reserved according to the expected future growth 3. A larger pool (e.g., 14*/24) for LERs (or LER-BBs) that serve
rate of the corresponding customer / the corresponding network a high number of customers that are normally connected via
device aggregate. some kind of aggregation network (e.g., DSL customers behind a
BB-RAR or dial-in customers behind a RAR).
o The IPv6 address delegation within each pool (the end customer
delegation or the aggregates that are dedicated to the LER itself)
should be chosen with an additional buffer zone of 100-300% for
future growth. That is, 1 or 2 additional prefix bits should be
reserved according to the expected future growth rate of the
corresponding customer or the corresponding network device
aggregate.
A.2.2.1. Defining an IPv6 Address Allocation Plan for Customers of the A.2.2.1. Defining an IPv6 Address Allocation Plan for Customers of the
Service Provider Service Provider
A.2.2.1.1. 'Big' Customers A.2.2.1.1. "Big" Customers
SP's "big" customers receive their prefix from the /24 IPv6 address The SP's "big" customers receive their prefix from the /24 IPv6
aggregate that has been reserved for their "big" customers. A address aggregate that has been reserved for their "big" customers.
customer is considered as "big" customer if it has a very complex A customer is considered a "big" customer if it has a very complex
network infrastructure and/or huge IPv6 address needs (e.g. because network infrastructure and/or huge IPv6 address needs (e.g., because
of very large customer numbers) and/or several uplinks to different of very large customer numbers) and/or several uplinks to different
POPs of the SP network. POPs of the SP network.
The assigned IPv6 address prefixes can have a prefix length in the The assigned IPv6 address prefixes can have a prefix length in the
range 32-48 and for each assignment a 100 or 300% future growing zone range 32-48 and for each assignment a 100 or 300% future growing zone
is marked as "reserved" for this customer. This means for instance is marked as "reserved" for this customer. For instance, this means
that with a delegation of a /34 to a customer the corresponding /32 that with a delegation of a /34 to a customer the corresponding /32
prefix (which contains this /34) is reserved for the customers future prefix (which contains this /34) is reserved for the customer's
usage. future usage.
The prefixes for the "big" customers can be chosen from the The prefixes for the "big" customers can be chosen from the
corresponding "big customer" pool by either using an equidistant corresponding "big customer" pool by either using an equidistant
algorithm or using mechanisms similar to the Sparse Allocation algorithm or using mechanisms similar to the Sparse Allocation
Algorithm (SAA) [reference2]. Algorithm (SAA) [RIPE_Nov07].
A.2.2.1.2. 'Common' Customers A.2.2.1.2. "Common" Customers
All customers that are not "big" customers are considered as "common" All customers that are not "big" customers are considered as "common"
customers. They represent the majority of customers hence they customers. They represent the majority of customers, hence they
receive a /48 out of the IPv6 customer address pool of the LER where receive a /48 out of the IPv6 customer address pool of the LER where
they are directly connected or aggregated. they are directly connected or aggregated.
Again a 100 - 300% future growing IPv6 address range is reserved for Again a 100 - 300% future growing IPv6 address range is reserved for
each customer, so that a "common" customer receives a /48 allocation each customer, so that a "common" customer receives a /48 allocation
but has a /47 or /46 reserved. but has a /47 or /46 reserved.
(Note: If it is obvious that the likelyhood of needing a /47 or /46 (Note: If it is obvious that the likelihood of needing a /47 or /46
in the future is very small for a "common" customer, than no growing in the future is very small for a "common" customer, then no growing
buffer should be reserved for it and only a /48 will be assigned buffer should be reserved for it, and only a /48 will be assigned
without any growing buffer.) without any growing buffer.)
In the network access scenarios where the customer is directly In the network access scenarios where the customer is directly
connected to the LER the customer prefix is directly taken out of the connected to the LER, the customer prefix is directly taken out of
customer IPv6 address aggregate (e.g. /38) of the corresponding LER. the customer IPv6 address aggregate (e.g., /38) of the corresponding
LER.
In all other cases (e.g. the customer is attached to a RAR that is For other cases (e.g., the customer is attached to a RAR that is
themselves aggregated to an AG or to a LER-BB) at least 2 different itself aggregated to an AG or to a LER-BB), at least 2 different
approaches are possible. approaches are possible.
1) Mapping of Aggregation Network Hierarchy into Customer IPv6 1) Mapping of Aggregation Network Hierarchy into Customer IPv6
Addressing Schema. The aggregation network hierarchy could be mapped Addressing Schema. The aggregation network hierarchy could be
into the design of the customer prefix pools of each network level in mapped into the design of the customer prefix pools of each
order to achieve a maximal aggregation at the LER level as well as at network level in order to achieve a maximal aggregation at the
the intermediate levels. (Example: Customer - /48, RAR - /38, AG - LER level as well as at the intermediate levels. (Example:
/32, LER-BB - /30). At each network level an adequate growing zone Customer - /48, RAR - /38, AG - /32, LER-BB - /30). At each
should be reserved. (Note: This approach requires of course some network level, an adequate growing zone should be reserved.
"fine tuning" of the addressing schema based on a very good knowledge (Note: Of course, this approach requires some "fine tuning" of
of the Service Provider network topology including actual growing the addressing schema based on a very good knowledge of the
ranges and rates.) Service Provider network topology including actual growing ranges
and rates.)
When the IPv6 customer address pool of a LER (or another device of When the IPv6 customer address pool of a LER (or another device
the aggregation network - AG or RAR) is exhausted, the related LER of the aggregation network -- AG or RAR) is exhausted, the
(or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to related LER (or AG or RAR) prefix is shortened by 1 or 2 bits
/37 or /36) so that the originally reserved growing zone can be used (e.g., from /38 to /37 or /36) so that the originally reserved
for further IPv6 address allocations to customers. In the case where growing zone can be used for further IPv6 address allocations to
this growing zone is exhausted as well a new prefix range from the customers. In the case where this growing zone is exhausted as
corresponding pool of the next higher hierarchy level can be well, a new prefix range from the corresponding pool of the next-
requested. higher hierarchy level can be requested.
2) "Flat" Customer IPv6 Addressing Schema. The other option is to 2) "Flat" Customer IPv6 Addressing Schema. The other option is to
allocate all the customer prefixes directly out of the customer IPv6 allocate all the customer prefixes directly out of the customer
address pool of the LER where the customers are attached and IPv6 address pool of the LER where the customers are attached and
aggregated and to ignore the intermediate aggregation network aggregated and to ignore the intermediate aggregation network
infrastructure. This approach leads of course to a higher amount of infrastructure. Of course, this approach leads to a higher
customer routes at LER and aggregation network level but takes a amount of customer routes at the LER and aggregation network
great amount of complexity out of the addressing schema. level, but it takes a great amount of complexity out of the
Nevertheless the aggregation of the customer prefixes to one prefix addressing schema. Nevertheless, the aggregation of the customer
at LER level is realized as required above. prefixes to one prefix at the LER level is realized as required
above.
(Note: The handling of (e.g. technically triggered) changes within Note: The handling of changes (e.g., technically triggered changes)
the ISP access network is shortly discussed in section A.2.3.5.) within the ISP access network is discussed briefly in
Appendix A.2.3.5.
If the actual observed growing rates show that the reserved growing If the actual observed growing rates show that the reserved growing
zones are not needed than these growing areas can be freed and used zones are not needed, then they can be freed and used for assignments
for assignments for prefix pools to other devices at the same level for prefix pools to other devices at the same level of the network
of the network hierarchy. hierarchy.
A.2.2.2. Defining an IPv6 Address Allocation Plan for the Service A.2.2.2. Defining an IPv6 Address Allocation Plan for the Service
Provider Network Infrastructure Provider Network Infrastructure
For the IPv6 addressing of SPs own network infrastructure a /32 (or For the IPv6 addressing of the SP's own network infrastructure, a /32
/40) from the "big" customers address pool can be chosen. (or /40) from the "big" customers address pool can be chosen.
This SP infrastructure prefix is used to code the network This SP infrastructure prefix is used to code the network
infrastructure of the SP by assigning a /48 to every POP/location and infrastructure of the SP by assigning a /48 to every POP/location and
using for instance a /56 for coding the corresponding router within using (for instance) a /56 for coding the corresponding router within
this POP. Each SP internal link behind a router interface could be this POP. Each SP internal link behind a router interface could be
coded using a /64 prefix. (Note: While it is suggested to choose a coded using a /64 prefix. (Note: While it is suggested to choose a
/48 for addressing the POP/location of the SP network it is left to /48 for addressing the POP/location of the SP network, it is left to
each SP to decide what prefix length to assign to the routers and each SP to decide what prefix length to assign to the routers and
links within this POP.) links within the POP.)
The IIDs of the router interfaces may be generated by using EUI-64 or The IIDs of the router interfaces may be generated by using EUI-64 or
through plain manual configuration e.g. for coding additional network through plain manual configuration, e.g., for coding additional
or operational information into the IID. network or operational information into the IID.
It is assumed that again 100 - 300% growing zones for each level of Again, it is assumed that 100-300% growing zones are needed for each
network hierarchy and additional prefix bits may be assigned to POPs level of network hierarchy, and additional prefix bits may be
and/or routers if needed. assigned to POPs and/or routers if needed.
Loopback interfaces of routers may be chosen from the first /64 of Loopback interfaces of routers may be chosen from the first /64 of
the /56 router prefix (in the example above). the /56 router prefix (in the example above).
(Note: The /32 (or /40) prefix that has been chosen for addressing (Note: The /32 (or /40) prefix that has been chosen for addressing
SPs own IPv6 network infrastructure gives enough place to code the SP's own IPv6 network infrastructure leaves enough space to code
additional functionalities like security levels or private and test additional functionalities like security levels or private and test
infrastructure although such approaches haven't been considered in infrastructure, although such approaches haven't been considered in
more detail for the above described SP until now.) more detail for the above-described SP until now.)
Point-to-point links to customers (e.g. PPP links, dedicated line Point-to-point links to customers (e.g., PPP links, dedicated lines,
etc.) may be addressed using /126 prefixes out of the first /64 of etc.) may be addressed using /126 prefixes out of the first /64 of
the access routers that could be reserved for this reason. the access routers that could be reserved for this reason.
A.2.3. Additional Remarks A.2.3. Additional Remarks
A.2.3.1. ULA A.2.3.1. ULA
From the actual view point of SP there is no compelling reason why There are no compelling reasons for service providers to use ULAs.
ULAs should be used from a SP. Look at section 2.2. See Section 2.2.
ULAs could be used inside the SP network in order to have an ULAs could be used inside the SP network in order to have an
additional "site-local scoped" IPv6 address for SPs own additional "site-local scoped" IPv6 address for the SP's own
infrastructure for instance for network management reasons and maybe infrastructure, for instance, for network management reasons and in
also in order to have an addressing schema that couldn't be reached order to have an addressing schema that can't be reached from outside
from outside the SP network. the SP network.
In the case when ULAs are used it is possible to map the proposed When ULAs are used, it is possible to map the proposed internal IPv6
internal IPv6 addressing of SPs own network infrastructure as addressing of the SP's own network infrastructure (as described in
described in A.2.2.2 above directly to the ULA addressing schema by Appendix A.2.2.2) directly to the ULA addressing schema by
substituting the /48 POP prefix with a /48 ULA site prefix. substituting the /48 POP prefix with a /48 ULA site prefix.
A.2.3.2. Multicast A.2.3.2. Multicast
IPv6 Multicast-related addressing issues are out of the scope of this IPv6 multicast-related addressing issues are out of the scope of this
document. document.
A.2.3.3. POP Multi-homing A.2.3.3. POP Multihoming
POP (or better LER) Multi-homing of customers with the same SP can be POP multihoming (or better, LER multihoming) of customers with the
realized within the proposed IPv6 addressing schema of the SP by same SP can be realized within the proposed IPv6 addressing schema of
assigning multiple LER-dependent prefixes to this customer (i.e. the SP by assigning multiple LER-dependent prefixes to this customer
considering each customer location as a single-standing customer) or (i.e., considering each customer location as a single customer) or by
by choosing a customer prefix out of the pool of "big" customers. choosing a customer prefix out of the pool of "big" customers. The
The second solution has the disadvantage that in every LER where the second solution has the disadvantage that in every LER where the
customer is attached this prefix will appear inside the IGP routing customer is attached, this prefix will appear inside the IGP routing
table requiring an explicit MPLS label. table, thus requiring an explicit MPLS label.
(Note: The described negative POP/LER Multi-homing effects to the Note: The negative effects (described above) of POP/LER multihoming
addressing architecture in the SP access network are not tackled by on the addressing architecture in the SP access network are not
implementing the Shim6 Site Multi-homing approach since this approach resolved by implementing the Site Multihoming by IPv6 Intermediation
targets only on a mechanism for dealing with multiple prefixes in end (SHIM6) approach. SHIM6 only targets a mechanism for dealing with
systems -- the SP will nevertheless have unaggregated customer multiple prefixes in end systems. The SP is expected to have
prefixes in its internal routing tables.) unaggregated customer prefixes in its internal routing tables.
A.2.3.4. Changing Point of Network Attachement A.2.3.4. Changing the Point of Network Attachment
In the possible case that a customer has to change its point of In the possible case that a customer has to change its point of
network attachment to another POP/LER within the ISP access network network attachment to another POP/LER within the ISP access network,
two different approaches can be applied assuming that the customer two different approaches can be applied, assuming that the customer
uses PA addresses out of the SP aggregate: uses PA addresses out of the SP aggregate:
1.) The customer has to renumber its network with an adequate 1) The customer has to renumber its network with an adequate
customer prefix out of the aggregate of the corresponding LER/RAR of customer prefix out of the aggregate of the corresponding LER/RAR
its new network attachement. To minimise the administrative burden of its new network attachment. To minimize the administrative
for the customer the prefix should be of the same size as the former. burden for the customer, the prefix should be of the same size as
This conserves the IPv6 address aggregation within the SP network the former. This conserves the IPv6 address aggregation within
(and the MPLS label space) but adds additional burden to the the SP network (and the MPLS label space) but adds additional
customer. Hence this approach will most likely only be chosen in the burden to the customer. Hence, this approach will most likely
case of "small customers" with temporary addressing needs and/or only be chosen in the case of "small customers" with temporary
prefix delegation with address auto-configuration. addressing needs and/or prefix delegation with address
autoconfiguration.
2.) The customer does not need to renumber its network and keeps its 2) The customer does not need to renumber its network and keeps its
address aggregate. address aggregate.
This apporach leads to additional more-specific routing entries This approach leads to additional more-specific routing entries
within the IGP routing table of the LER and will hence consume within the IGP routing table of the LER and will hence consume
additional MPLS labels - but it is totally transparent to the additional MPLS labels, but it is totally transparent to the
customer. Because this results in additional administrative effort customer. Because this results in additional administrative
and will stress the router resources (label space, memory) of the ISP effort and will stress the router resources (label space, memory)
this solution will only be offered to the most valuable customers of of the ISP, this solution will only be offered to the most
an ISP (like e.g. "big customers" or "enterprise customers"). valuable customers of an ISP (e.g., "big customers" or
"enterprise customers").
Nevertheless the ISP has again to find a fair trade-off between Nevertheless, the ISP again has to find a fair trade-off between
customer renumbering and sub-optimal address aggregation (i.e. the customer renumbering and sub-optimal address aggregation (i.e.,
generation of additional more-specific routing entries within the IGP the generation of additional more-specific routing entries within
and the waste of MPLS Label space). the IGP and the waste of MPLS label space).
A.2.3.5. Restructuring of SP (access) Network and Renumbering A.2.3.5. Restructuring of SP (Access) Network and Renumbering
A technically triggered restructuring of the SP (access) network (for A technically triggered restructuring of the SP (access) network (for
instance because of split of equipment or installation of new instance, because of split of equipment or installation of new
equipment) should not lead to a customer network renumbering. This equipment) should not lead to a customer network renumbering. This
challenge should be handled in advance by an intelligent network challenge should be handled in advance by an intelligent network
design and IPv6 address planing. design and IPv6 address planning.
In the worst case the customer network renumbering could be avoided In the worst case, the customer network renumbering could be avoided
through the implementation of more specific customer routes. (Note: through the implementation of more-specific customer routes. (Note:
Since this kind of network restructuring will mostly happen within Since this kind of network restructuring will mostly happen within
the access network (at the level) below the LER, the LER aggregation the access network (at the level) below the LER, the LER aggregation
level will not be harmed and the more-specific routes will not level will not be harmed and the more-specific routes will not
consume additional MPLS label space.) consume additional MPLS label space.)
A.2.3.6. Extensions Needed for the Later IPv6 Migration Phases A.2.3.6. Extensions Needed for the Later IPv6 Migration Phases
The proposed IPv6 addressing schema for a SP needs some slight The proposed IPv6 addressing schema for an SP needs some slight
enhancements / modifications for the later phases of IPv6 enhancements / modifications for the later phases of IPv6
integration, for instance in the case when the whole MPLS backbone integration, for instance, when the whole MPLS backbone
infrastructure (LDP, IGP etc.) is realized over IPv6 transport and an infrastructure (LDP, IGP, etc.) is realized over IPv6 transport, and
IPv6 addressing of the LSRs is needed. Other changes may be an IPv6 addressing of the LSRs is needed. Other changes may be
necessary as well but should not be explained at this point. necessary as well but should not be explained at this point.
Appendix B. Considerations for Subnet Prefixes Different then /64 Appendix B. Considerations for Subnet Prefixes Different than /64
B.1. Considerations for Subnet Prefixes Shorter then /64 B.1. Considerations for Subnet Prefixes Shorter than /64
An allocation of a prefix shorter then 64 bits to a node or interface An allocation of a prefix shorter then 64 bits to a node or interface
is considered bad practice. One exception to this statement is when is considered bad practice. One exception to this statement is when
using 6to4 technology where a /16 prefix is utilized for the pseudo- using 6to4 technology where a /16 prefix is utilized for the pseudo-
interface [RFC3056]. The shortest subnet prefix that could interface [RFC3056]. The shortest subnet prefix that could
theoretically be assigned to an interface or node is limited by the theoretically be assigned to an interface or node is limited by the
size of the network prefix allocated to the organization. size of the network prefix allocated to the organization.
A possible reason for choosing the subnet prefix for an interface A possible reason for choosing the subnet prefix for an interface
shorter then /64 is that it would allow more nodes to be attached to shorter than /64 is that it would allow more nodes to be attached to
that interface compared to a prescribed length of 64 bits. This that interface compared to a prescribed length of 64 bits. The
however is unnecessary for most networks considering that 2^64 prescribed /64 does include 2 functional bits, the 'g' bit and the
provides plenty of node addresses. inverted 'u' (universal/local) bit and these can not be chosen at
will. However, a larger address space then a /64 is unnecessary for
most networks, considering that 2^62 provides plenty of node
addresses.
The subnet prefix assignments can be made either by manual The subnet prefix assignments can be made by manual configuration, by
configuration, by a stateful Host Configuration Protocol [RFC3315], a stateful Host Configuration Protocol [RFC3315], by a stateful
by a stateful prefix delegation mechanism [RFC3633] or implied by prefix delegation mechanism [RFC3633], or implied by stateless
stateless autoconfiguration from prefix RAs. autoconfiguration from prefix Router Advertisements (RAs).
B.2. Considerations for Subnet Prefixes Longer then /64 B.2. Considerations for Subnet Prefixes Longer than /64
The following subsections describe subnet prefix values that should The following subsections describe subnet prefix values that should
be avoided in deployments, because nodes who assume that the subnet be avoided in deployments because nodes who assume that the subnet
prefix is /64 could treat them incorrectly. prefix is /64 could treat them incorrectly.
B.2.1. /126 Addresses B.2.1. /126 Addresses
126 bit subnet prefixes are typically used for point-to-point links 126-bit subnet prefixes are typically used for point-to-point links
similar to a the IPv4 address conservative /30 allocation for point- similar to a the IPv4 address-conservative /30 allocation for point-
to-point links. The usage of this subnet address length does not to-point links. The usage of this subnet address length does not
lead to any additional considerations other than the ones discussed lead to any considerations beyond those discussed earlier in this
earlier in this section, particularly those related to the "u" and section, particularly those related to the 'u' and 'g' bits (see
"g" bits. B.2.4.
B.2.2. /127 Addresses B.2.2. /127 Addresses
The usage of the /127 addresses, the equivalent of IPv4's RFC3021 The usage of the /127 addresses, the equivalent of IPv4's RFC3021
[RFC3021] is not valid and should be strongly discouraged as [RFC3021], is not valid and should be strongly discouraged as
documented in RFC3627 [RFC3627]. documented in RFC3627 [RFC3627].
B.2.3. /128 Addresses B.2.3. /128 Addresses
The 128 bit address prefix may be used in those situations where we The 128-bit address prefix may be used in those situations where we
know that one, and only one address is sufficient. Example usage know that one, and only one, address is sufficient. Example usage
would be the off-link loopback address of a network device. would be the off-link loopback address of a network device.
When choosing a 128 bit prefix, it is recommended to take the "u" and When choosing a 128 bit prefix, it is recommended to take the 'u' and
"g" bits into consideration and to make sure that there is no overlap 'g' bits into consideration and to make sure that there is no overlap
with either the following well-known addresses: with any of the following well-known addresses:
o Subnet Router Anycast Address o Subnet Router Anycast Address
o Reserved Subnet Anycast Address o Reserved Subnet Anycast Address
o Addresses used by Embedded-RP o Addresses used by Embedded-RP
o ISATAP Addresses o ISATAP Addresses
B.2.4. EUI-64 'u' and 'g' bits B.2.4. EUI-64 'u' and 'g' Bits
When using subnet prefix lengths other than /64, the interface When using subnet prefix lengths other than /64, the interface
identifier cannot be in Modified EUI-64 format as required by identifier cannot be in Modified EUI-64 format as required by
[RFC4291]. However, nodes not aware that a prefix length other than [RFC4291]. However, nodes not aware that a prefix length other than
/64 is used might still think it's an EUI-64; therefore, it's prudent /64 is used might still think it's an EUI-64; therefore, it's prudent
to take the next considerations to set the bits into account. to take into account the following points when setting the bits.
Address space conservation is the main motivation for using a subnet Address space conservation is the main motivation for using a subnet
prefix length longer than 64 bits, however this kind of address prefix length longer than 64 bits; however, this kind of address
conservation is of little benefit compared with the additional conservation is of little benefit compared with the additional
considerations one must make when creating and maintain an IPv6 considerations one must make when creating and maintaining an IPv6
address plan. addressing plan.
The address assignment can be made either by manual configuration or The address assignment can be made either by manual configuration or
by a stateful Host Configuration Protocol [RFC3315]. by a stateful Host Configuration Protocol [RFC3315].
When assigning a subnet prefix of more then 70 bits, according to When assigning a subnet prefix of more then 70 bits, according to RFC
RFC4291 [RFC4291] 'u' and 'g' bits (respectively the 71st and 72nd 4291 [RFC4291], 'u' and 'g' bits (the 71st and 72nd bit,
bit) need to be taken into consideration and should be set correct. respectively) need to be taken into consideration and should be set
correctly.
The 'u' (universal/local) bit is the 71st bit of IPv6 address and is The 71st bit of a IPv6 address is the inverted 'u' (universal/local)
used to determine whether the address is universally or locally bit and is used to determine whether the address is universally or
administered. If 0, the IEEE, through the designation of a unique locally administered. If 1, the IEEE, through the designation of a
company ID, has administered the address. If 1, the address is unique company ID, has administered the address. If 0, the address
locally administered. The network administrator has overridden the is locally administered. The network administrator has overridden
manufactured address and specified a different address. the manufactured address and specified a different address.
The 'g' (the individual/group) bit is the 72st bit and is used to The 'g' (the individual/group) bit is the 72nd bit and is used to
determine whether the address is an individual address (unicast) or a determine whether the address is an individual address (unicast) or a
group address (multicast). If '0', the address is a unicast address. group address (multicast). If '0', the address is a unicast address.
If '1', the address is a multicast address. If '1', the address is a multicast address.
In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bit In current IPv6 protocol stacks, the relevance of the 'u' and 'g'
is marginal and typically will not show an issue when configured bits is marginal and typically will not give an error when configured
wrongly, however future implementations may turn out differently if wrongly; however, future implementations may turn out differently if
they would be processing the 'u' and 'g' bit in IEEE like behavior. they process the 'u' and 'g' bits in IEEE-like behavior.
When using subnet lengths longer then 64 bits, it is important to When using subnet lengths longer then 64 bits, it is important to
avoid selecting addresses that may have a predefined use and could avoid selecting addresses that may have a predefined use and could
confuse IPv6 protocol stacks. The alternate usage may not be a confuse IPv6 protocol stacks. The alternate usage may not be a
simple unicast address in all cases. The following points should be simple unicast address in all cases. The following points should be
considered when selecting a subnet length longer then 64 bits. considered when selecting a subnet length longer then 64 bits.
B.2.5. Anycast Addresses B.2.5. Anycast Addresses
B.2.5.1. Subnet Router Anycast Address B.2.5.1. Subnet Router Anycast Address
skipping to change at page 31, line 19 skipping to change at page 33, line 4
B.2.5.1. Subnet Router Anycast Address B.2.5.1. Subnet Router Anycast Address
RFC4291 [RFC4291] provides a definition for the required Subnet RFC4291 [RFC4291] provides a definition for the required Subnet
Router Anycast Address as follows: Router Anycast Address as follows:
| n bits | 128-n bits | | n bits | 128-n bits |
+--------------------------------------------+----------------+ +--------------------------------------------+----------------+
| subnet prefix | 00000000000000 | | subnet prefix | 00000000000000 |
+--------------------------------------------+----------------+ +--------------------------------------------+----------------+
It is recommended to avoid allocating this IPv6 address to a device It is recommended to avoid allocating this IPv6 address to a device
which expects to have a normal unicast address. There is no that expects to have a normal unicast address.
additional dependency for the subnet prefix with the exception of the
64-bit extended unique identifier (EUI-64) and an Interface
Identifier (IID) dependency. These will be discussed later in this
document.
B.2.5.2. Reserved IPv6 Subnet Anycast Addresses B.2.5.2. Reserved IPv6 Subnet Anycast Addresses
RFC2526 [RFC2526] stated that within each subnet, the highest 128 RFC2526 [RFC2526] stated that within each subnet, the highest 128
interface identifier values are reserved for assignment as subnet interface identifier values are reserved for assignment as subnet
anycast addresses. anycast addresses.
The construction of a reserved subnet anycast address depends on the The construction of a reserved subnet anycast address depends on the
type of IPv6 addresses used within the subnet, as indicated by the type of IPv6 addresses used within the subnet, as indicated by the
format prefix in the addresses. format prefix in the addresses.
The first type of Subnet Anycast addresses have been defined as The first type of Subnet Anycast addresses have been defined as
follows for EUI-64 format: follows for the Modified EUI-64 format:
| 64 bits | 57 bits | 7 bits | | 64 bits | 57 bits | 7 bits |
+------------------------------+------------------+------------+ +------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID | | subnet prefix | 1111110111...111 | anycast ID |
+------------------------------+------------------+------------+ +------------------------------+------------------+------------+
The anycast address structure implies that it is important to avoid The anycast address structure implies that it is important to avoid
creating a subnet prefix where the bits 65 to 121 are defined as creating a subnet prefix where the bits 65 to 121 are defined as
"1111110111...111" (57 bits in total) so that confusion can be "1111110111...111" (57 bits in total) in order to prevent confusion.
avoided.
For other IPv6 address types (that is, with format prefixes other For other IPv6 address types (that is, with format prefixes other
than those listed above), the interface identifier is not in 64-bit than those listed above), the interface identifier is not in 64-bit
extended unique identifier (EUI-64) format and may be other than 64 extended unique identifier (EUI-64) format and may not be 64 bits in
bits in length; these reserved subnet anycast addresses for such length. The reserved subnet anycast addresses for such address types
address types are constructed as follows: are constructed as follows:
| n bits | 121-n bits | 7 bits | | n bits | 121-n bits | 7 bits |
+------------------------------+------------------+------------+ +------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID | | subnet prefix | 1111111...111111 | anycast ID |
+------------------------------+------------------+------------+ +------------------------------+------------------+------------+
| interface identifier field | | interface identifier field |
It is recommended to avoid allocating this IPv6 address to a device It is recommended to avoid allocating this IPv6 address to a device
which expects to have a normal unicast address. There is no that expects to have a normal unicast address.
additional dependency for the subnet prefix with the exception of the
EUI-64 and an Interface Identifier (IID) dependency. These will be
discussed later in this document.
B.2.6. Addresses Used by Embedded-RP (RFC3956) B.2.6. Addresses Used by Embedded-RP (RFC3956)
Embedded-RP [RFC3956] reflects the concept of integrating the Embedded-RP [RFC3956] reflects the concept of integrating the
Rendezvous Point (RP) IPv6 address into the IPv6 multicast group Rendezvous Point (RP) IPv6 address into the IPv6 multicast group
address. Due to this embedding and the fact that the length of the address. Due to this embedding and the fact that the length of the
IPv6 address AND the IPv6 multicast address are 128 bits, it is not IPv6 address AND the IPv6 multicast address are 128 bits, it is not
possible to have the complete IPv6 address of the multicast RP possible to have the complete IPv6 address of the multicast RP
embedded as such. embedded as such.
This resulted in a restriction of 15 possible RP-addresses per prefix This results in a restriction of 15 possible RP-addresses per prefix
that can be used with embedded-RP. The space assigned for the that can be used with embedded-RP. The space assigned for the
embedded-RP is based on the 4 low order bits, while the remainder of embedded-RP is based on the 4 low-order bits, while the remainder of
the Interface ID (RIID) is set to all '0'. the Rendezvous Interface ID (RIID) is set to all '0'. The format of
the IPv6 multicast group address used by embedded-RP is as follows:
(IPv6-prefix (64 bits))(60 bits all '0')(RIID) (IPv6-prefix (64 bits))(60 bits all '0')(RIID)
Where: (RIID) = 4 bit. where: (RIID) = 4 bits.
This format implies that when selecting subnet prefixes longer then This format implies that when selecting subnet prefixes longer than
64, and the bits beyond the 64th one are non-zero, the subnet can not 64, and when the bits beyond the 64th bit are non-zero, the subnet
use embedded-RP. cannot use embedded-RP.
In addition it is discouraged to assign a matching embedded-RP IPv6 In addition, it is discouraged to assign a matching embedded-RP IPv6
address to a device that is not a real Multicast Rendezvous Point, address to a device that is not a real Multicast Rendezvous Point,
even though it would not generate major problems. even though it would not generate major problems.
B.2.7. ISATAP Addresses B.2.7. ISATAP Addresses
ISATAP [RFC5214] is an experimental automatic tunneling protocol used ISATAP [RFC5214] is an experimental automatic tunneling protocol used
to provide IPv6 connectivity over an IPv4 campus or enterprise to provide IPv6 connectivity over an IPv4 campus or enterprise
environment. In order to leverage the underlying IPv4 environment. In order to leverage the underlying IPv4
infrastructure, the IPv6 addresses are constructed in a special infrastructure, the IPv6 addresses are constructed in a special
format. format.
An IPv6 ISATAP address has the IPv4 address embedded, based on a An IPv6 ISATAP address has the IPv4 address embedded, based on a
predefined structure policy that identifies them as an ISATAP predefined structure policy that identifies them as an ISATAP
address. address. The format is as follows:
[IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address] [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]
When using subnet prefix length longer then 64 bits it is good When using a subnet prefix length longer then 64 bits, it is good
engineering practice that the portion of the IPv6 prefix from bit 65 engineering practice to ensure that the portion of the IPv6 prefix
to the end of the host-id does not match with the well-known ISATAP from bit 65 to the end of the host-ID does not match with the well-
[0000:5EFE] address when assigning an IPv6 address to a non-ISATAP known ISATAP [0000:5EFE] address when assigning an IPv6 address to a
interface. non-ISATAP interface.
Note that the definition of ISATAP does not support multicast. Note that the definition of ISATAP does not support multicast.
Authors' Addresses Authors' Addresses
Gunter Van de Velde Gunter Van de Velde
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
skipping to change at page 33, line 38 skipping to change at page 35, line 12
Note that the definition of ISATAP does not support multicast. Note that the definition of ISATAP does not support multicast.
Authors' Addresses Authors' Addresses
Gunter Van de Velde Gunter Van de Velde
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2704 5473 Phone: +32 2704 5473
Email: gunter@cisco.com EMail: gunter@cisco.com
Ciprian Popoviciu Ciprian Popoviciu
Cisco Systems Cisco Systems
7025-6 Kit Creek Road 7025-6 Kit Creek Road
Research Triangle Park, North Carolina PO Box 14987 Research Triangle Park, North Carolina
USA USA
EMail: cpopovic@cisco.com
Phone: +1 919 392-3723
Email: cpopovic@cisco.com
Tim Chown Tim Chown
University of Southampton University of Southampton
Highfield Highfield
Southampton, SO17 1BJ Southampton SO17 1BJ
United Kingdom United Kingdom
Phone: +44 23 8059 3257 Phone: +44 23 8059 3257
Email: tjc@ecs.soton.ac.uk EMail: tjc@ecs.soton.ac.uk
Olaf Bonness
T-Systems Enterprise Services GmbH T-Systems Enterprise Services GmbH
Goslarer Ufer 35 Goslarer Ufer 35
Berlin, 10589 Berlin 10589
Germany Germany
Phone: +49 30 3497 3124 Phone: +49 30 3497 3124
Email: Olaf.Bonness@t-systems.com EMail: Olaf.Bonness@t-systems.com
Christian Hahn Christian Hahn
T-Systems Enterprise Services GmbH T-Systems Enterprise Services GmbH
Goslarer Ufer 35 Goslarer Ufer 35
Berlin, 10589 Berlin 10589
Germany Germany
Phone: +49 30 3497 3164 Phone: +49 30 3497 3164
Email: HahnC@t-systems.com EMail: HahnC@t-systems.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 288 change blocks. 
712 lines changed or deleted 758 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/