draft-ietf-v6ops-addcon-02.txt   draft-ietf-v6ops-addcon-03.txt 
Network Working Group G. Van de Velde Network Working Group G. Van de Velde
Internet-Draft C. Popoviciu Internet-Draft C. Popoviciu
Expires: April 26, 2007 Cisco Systems Expires: September 4, 2007 Cisco Systems
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
October 23, 2006 March 3, 2007
IPv6 Unicast Address Assignment Considerations IPv6 Unicast Address Assignment Considerations
<draft-ietf-v6ops-addcon-02.txt> <draft-ietf-v6ops-addcon-03.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007. This Internet-Draft will expire on September 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 draft aims to provide the information and recommendations IPv6. This document aims to provide the information and
relevant to planning the addressing aspects of IPv6 deployments. The recommendations relevant to planning the addressing aspects of IPv6
draft also provides IPv6 addressing case studies for both an deployments. The document also provides IPv6 addressing case studies
enterprise and an ISP network. for both an enterprise and an ISP network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Network Level Addressing Design Considerations . . . . . . . . 5 2. Network Level Addressing Design Considerations . . . . . . . . 5
2.1. Global Unique Addresses . . . . . . . . . . . . . . . . . 5 2.1. Global Unique Addresses . . . . . . . . . . . . . . . . . 5
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 6 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 6
2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 7 2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 7
2.4. Network Level Design Considerations . . . . . . . . . . . 7 2.4. Network Level Design Considerations . . . . . . . . . . . 7
2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
skipping to change at page 3, line 28 skipping to change at page 3, line 28
3.3. Considerations for subnet prefixes longer then /64 . . . . 9 3.3. Considerations for subnet prefixes longer then /64 . . . . 9
3.3.1. Anycast addresses . . . . . . . . . . . . . . . . . . 10 3.3.1. Anycast addresses . . . . . . . . . . . . . . . . . . 10
3.3.2. Addresses used by Embedded-RP (RFC3956) . . . . . . . 11 3.3.2. Addresses used by Embedded-RP (RFC3956) . . . . . . . 11
3.3.3. ISATAP addresses . . . . . . . . . . . . . . . . . . . 12 3.3.3. ISATAP addresses . . . . . . . . . . . . . . . . . . . 12
3.3.4. /126 addresses . . . . . . . . . . . . . . . . . . . . 12 3.3.4. /126 addresses . . . . . . . . . . . . . . . . . . . . 12
3.3.5. /127 addresses . . . . . . . . . . . . . . . . . . . . 12 3.3.5. /127 addresses . . . . . . . . . . . . . . . . . . . . 12
3.3.6. /128 addresses . . . . . . . . . . . . . . . . . . . . 12 3.3.6. /128 addresses . . . . . . . . . . . . . . . . . . . . 12
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 13 4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 13
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 13 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 13
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 13 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 13
4.3. Cryptographically Generated IPv6 Addresses . . . . . . . . 13 4.3. Cryptographically Generated IPv6 Addresses . . . . . . . . 14
4.4. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14 4.4. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Enterprise Considerations . . . . . . . . . . . . . . . . 15 5.1. Enterprise Considerations . . . . . . . . . . . . . . . . 15
5.1.1. Obtaining general IPv6 network prefixes . . . . . . . 15 5.1.1. Obtaining general IPv6 network prefixes . . . . . . . 15
5.1.2. Forming an address (subnet) allocation plan . . . . . 16 5.1.2. Forming an address (subnet) allocation plan . . . . . 16
5.1.3. Other considerations . . . . . . . . . . . . . . . . . 16 5.1.3. Other considerations . . . . . . . . . . . . . . . . . 17
5.1.4. Node configuration considerations . . . . . . . . . . 17 5.1.4. Node configuration considerations . . . . . . . . . . 17
5.2. Service Provider Considerations . . . . . . . . . . . . . 18 5.2. Service Provider Considerations . . . . . . . . . . . . . 18
5.2.1. Investigation of objective Requirements for an 5.2.1. Investigation of objective Requirements for an
IPv6 addressing schema of a Service Provider . . . . 18 IPv6 addressing schema of a Service Provider . . . . 18
5.2.2. Exemplary IPv6 address allocation plan for a 5.2.2. Exemplary IPv6 address allocation plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 21 Service Provider . . . . . . . . . . . . . . . . . . . 21
5.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 25 5.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. Introduction 1. Introduction
The Internet Protocol Version 6 (IPv6) Addressing Architecture [25] The Internet Protocol Version 6 (IPv6) Addressing Architecture [26]
defines three main types of addresses: unicast, anycast and defines three main types of addresses: unicast, anycast and
multicast. This document focuses on unicast addresses, for which multicast. This document focuses on unicast addresses, for which
there are currently two principal allocated types: Global Unique there are currently two principal allocated types: Global Unique
Addresses [13] ('globals') and Unique Local IPv6 Addresses [23] Addresses [14] ('globals') and Unique Local IPv6 Addresses [24]
(ULAs). In addition until recently there has been 'experimental' (ULAs). In addition until recently there has been 'experimental'
6bone address space [3], though its use has been deprecated since 6bone address space [3], though its use has been deprecated since
June 2006 [16]. June 2006 [17].
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 'Network
Level Addressing' (the allocation of subnets) and the 'Subnet Prefix' Level Addressing' (the allocation of subnets) and the 'interface-id'.
(address usage within a subnet). Thus the document includes a Thus the document includes a discussion of aspects of address
discussion of aspects of address assignment to nodes and interfaces assignment to nodes and interfaces in an IPv6 network. Finally the
in an IPv6 network. Finally the document provides two examples of document provides two examples of deployed address plans in a service
successfully deployed address plans in a service provider (ISP) and provider (ISP) and an enterprise network.
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 Even though there is no broadcast for the IPv6 protocol, there is o Even though there is no broadcast for the IPv6 protocol, there is
still need to consider the number of devices in a given subnet due still need to consider the number of devices in a given subnet due
to traffic storm and level of traffic generated by hosts to traffic storm and level of traffic generated by hosts
o The implications of the vastly increased subnet size on the threat o The implications of the vastly increased subnet size on the threat
of address-based host scanning and other scanning techniques, as of address-based host scanning and other scanning techniques, as
discussed in [27]. discussed in [30].
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. However, one acquiring its globally routable IPv6 address prefix. However, one
should note that IPv6 networks currently receive their global unicast should note that IPv6 networks currently receive their global unicast
address allocation from their 'upstream' provider, which may be address allocation from their 'upstream' provider, which may be
another ISP, a Local Internet Registry (LIR) or a Regional Internet another ISP, a Local Internet Registry (LIR) or a Regional Internet
Registry (RIR). In each case the prefix received is provider Registry (RIR). In each case the prefix received is provider
assigned (PA). Until very recently there has been no provider assigned (PA). Until very recently there has been no provider
independent (PI) address space for IPv6 generally available. However independent (PI) address space for IPv6 generally available. However
ARIN is now piloting PI address space allocations, subject to ARIN is now providing PI address space allocations, subject to
customers meeting certain requirements. customers meeting certain requirements.
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 most commonly an IPv6 network which changes provider will need to
undergo a renumbering process, as described in [22]. A separate undergo a renumbering process, as described in [23]. A separate
document [29] makes recommendations to ease the IPv6 renumbering document [32] makes recommendations to ease the IPv6 renumbering
process. 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 between the ULA addresses and the now obsoleted site-local
addresses. Most implementations know about Site-local addresses even addresses. Most implementations know about Site-local addresses even
though they are deprecated, and do not know about ULAs - even though though they are deprecated, and do not know about ULAs - even though
they represent current specification. As result transitioning they represent current specification. As result transitioning
between these types of addresses may cause difficulties. between these types of addresses may cause difficulties.
2. Network Level Addressing Design Considerations 2. Network Level Addressing Design Considerations
skipping to change at page 5, line 48 skipping to change at page 5, line 47
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 [11]. A multihomed address selection methods described in RFC3484 [12]. A multihomed
host may thus have two addresses, one per prefix (provider), and host may thus have two addresses, one per prefix (provider), and
select source and destination addresses to use as described in that select source and destination addresses to use as described in that
RFC. RFC. However multihoming also has some operative and administrative
burdens besides chosing multiple addresses per interface [33]
[34][35].
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 [18]. the IPv6 addressing architecture, for reasons described in [19].
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 in the
case of (deliberate or accidental) leakage, or where networks are case of (deliberate or accidental) leakage, or where networks are
merged. ULAs are akin to the private address space [1] assigned for merged. ULAs are akin to the private address space [1] assigned for
IPv4 networks, except that in IPv6 networks we may expect to see ULAs IPv4 networks, except that in IPv6 networks we may expect to see ULAs
used alongside global addresses, with ULAs used internally and used alongside global addresses, with ULAs used internally and
globals used externally. Thus use of ULAs does not imply use of NAT globals used externally. Thus use of ULAs does not imply use of NAT
for IPv6. 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 [8]. globally routable IPv6 address space [9].
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 globals. In an isolated A site using ULAs may or may not also deploy globals. In an isolated
network ULAs may be deployed on their own. In a connected network, network ULAs may be deployed on their own. In a connected network,
that also deploys global addresses, both may be deployed, such that that also deploys global addresses, both may be deployed, such that
skipping to change at page 7, line 19 skipping to change at page 7, line 19
The usage of ULAs should be carefully considered even when not The usage of ULAs should be carefully considered even when not
attached to the IPv6 Internet due to the potential for added attached to the IPv6 Internet due to the potential for added
complexity when connecting to the Internet at some point in the complexity when connecting to the Internet at some point in the
future. future.
2.3. 6Bone Address Space 2.3. 6Bone Address Space
The 6Bone address space was used before the RIRs started to The 6Bone address space was used before the RIRs started to
distribute 'production' IPv6 prefixes. The 6Bone prefixes have a distribute 'production' IPv6 prefixes. The 6Bone prefixes have a
common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address
range is deprecated as of 6th June 2006 [16] and should be avoided on range is deprecated as of 6th June 2006 [17] and should be avoided on
any new IPv6 network deployments. Sites using 6bone address space any new IPv6 network deployments. Sites using 6bone address space
should renumber to production address space using procedures as should renumber to production address space using procedures as
defined in [22]. defined in [23].
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 address 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 Geographical Boundaries - by assigning a common prefix to all o Geographical Boundaries - by assigning a common prefix to all
subnets within a geographical area subnets within a geographical area
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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: developing these new addressing schemes:
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 [12] can be used to allow network prefix, documented in RFC3531 [13] can be used to allow
the network infrastructure to grow and be numbered in a way that the network infrastructure to grow and be numbered in a way that
is likely to preserve aggregation (the plan leaves 'holes' for is likely to preserve aggregation (the plan leaves 'holes' for
growth) growth)
o ULA usage in large networks - Networks which have a large number 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 of 'sites' that each deploy a ULA prefix which will by default be
a 'random' /48 under fc00::/7 will have no aggregation of those a 'random' /48 under fc00::/7 will have no aggregation of those
prefixes. Thus the end result may be cumbersome because the 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 to use a
single ULA for all 'sites', as a ULA still provides 16 bits for single ULA for all 'sites', as a ULA still provides 16 bits for
subnetting to be used internally subnetting to be used internally
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 [8]. for address space. By default a site will receive a /48 prefix [9] ,
The default provider allocation via the RIRs is currently a /32 [28]. however different RIR service regions policies may suggest
alternative default assignments or let the ISPs to decide on what
they believe is more appropriate for their specific case [28]. The
default provider allocation via the RIRs is currently a /32 [31].
These allocations are indicators for a first allocation for a These allocations are indicators for a first allocation for a
network. Different sizes may be obtained based on the anticipated network. Different sizes may be obtained based on the anticipated
address usage [28]. There are examples of allocations as large as address usage [31]. There are examples of allocations as large as
/19 having been made from RIRs to providers at the time of writing. /19 having been made from RIRs to providers at the time of writing.
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 subnetting,
it still is important to ensure an efficient use of this resource. it still is important to ensure an efficient use of this resource.
Some addressing schemes, while facilitating aggregation and Some addressing schemes, while facilitating aggregation and
management, could lead to significant numbers of addresses being 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 IPv6
but they should still be observed. but they should still be observed.
The proposed HD [9] value for IPv6 is 0.94 compared to the current The proposed HD [10] value for IPv6 is 0.94 compared to the current
value of 0.96 for IPv4. Note that for IPv6 HD is calculated for value of 0.96 for IPv4. Note that for IPv6 HD is calculated for
sites (i.e. on a basis of /48), instead of based on addresses like sites (i.e. on a basis of /48), instead of based on addresses like
with IPv4. with IPv4.
3. Subnet Prefix Considerations 3. Subnet Prefix Considerations
This section analyzes the considerations applied to define the subnet This section analyzes the considerations applied to define the subnet
prefix of the IPv6 addresses. The boundaries of the subnet prefix prefix of the IPv6 addresses. The boundaries of the subnet prefix
allocation are specified in RFC4291 [25]. In this document we allocation are specified in RFC4291 [26]. In this document we
analyze their practical implications. Based on RFC4291 [25] it is analyze their practical implications. Based on RFC4291 [26] it is
legal for any IPv6 unicast address starting with binary address '000' legal for any IPv6 unicast address starting with binary address '000'
to have a subnet prefix larger than, smaller than or of equal to 64 to have a subnet prefix larger than, smaller than or of equal to 64
bits. Each of these three options is discussed in this document. bits. Each of these three options is discussed in this document.
3.1. Considerations for subnet prefixes shorter then /64 3.1. Considerations for subnet prefixes shorter then /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 bad practice. The shortest subnet prefix that could theoretically is considered bad practice. The shortest subnet prefix that could
be assigned to an interface or node is limited by the size of the theoretically be assigned to an interface or node is limited by the
network prefix allocated to the organization. size of the network prefix allocated to the organization. One
exception to this recommendation is when using 6to4 technology where
a /16 prefix is utilised for the pseudo-interface [8].
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 then /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. This
however is unnecessary considering that 2^64 provides plenty of node however is unnecessary considering that 2^64 provides plenty of node
addresses for a well designed IPv6 network. Layer two technologies addresses for a well designed IPv6 network. Layer two technologies
are unlikely to support such large numbers of nodes within a single are unlikely to support such large numbers of nodes within a single
link (e.g. Ethernet limited to 48-bits of hosts) link (e.g. Ethernet limited to 48-bits of hosts)
The subnet prefix assignments can be made either by manual The subnet prefix assignments can be made either by manual
configuration, by a stateful Host Configuration Protocol [10] or by a configuration, by a stateful Host Configuration Protocol [11] or by a
stateful prefix delegation mechanism [15]. stateful prefix delegation mechanism [16].
3.2. Considerations for /64 prefixes 3.2. Considerations for /64 prefixes
Based on RFC3177 [8], 64 bits is the prescribed subnet prefix length Based on RFC3177 [9], 64 bits is the prescribed subnet prefix length
to allocate to interfaces and nodes. 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 stateful
Host Configuration Protocol [10] [17] or by stateless Host Configuration Protocol [11] [18] or by stateless
autoconfiguration [2]. autoconfiguration [2].
Note that RFC3177 strongly prescribes 64 bit subnets for general Note that RFC3177 strongly prescribes 64 bit subnets for general
usage, and that stateless autoconfiguration option is only defined usage, and that stateless autoconfiguration option is only defined
for 64 bit subnets. for 64 bit subnets.
3.3. Considerations for subnet prefixes longer then /64 3.3. Considerations for subnet prefixes longer then /64
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. prefix length longer than 64 bits.
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 [10]. by a stateful Host Configuration Protocol [11].
When assigning a subnet prefix of more then 80 bits, according to When assigning a subnet prefix of more then 80 bits, according to
RFC4291 [25] "u" and "g" bits (respectively the 81st and 82nd bit) RFC4291 [26] "u" and "g" bits (respectively the 81st and 82nd bit)
need to be taken into consideration and should be set correctly. In need to be taken into consideration and should be set correctly. In
currently implemented IPv6 protocol stacks, the relevance of the "u" currently implemented IPv6 protocol stacks, the relevance of the "u"
(universal/local) bit and "g" (the individual/group) bit are marginal (universal/local) bit and "g" (the individual/group) bit are marginal
and typically will not show an issue when configured wrongly, however and typically will not show an issue when configured wrongly, however
future implementations may turn out differently. future implementations may turn out differently.
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.
3.3.1. Anycast addresses 3.3.1. Anycast addresses
3.3.1.1. Subnet Router Anycast Address 3.3.1.1. Subnet Router Anycast Address
RFC4291 [25] provides a definition for the required Subnet Router RFC4291 [26] provides a definition for the required Subnet Router
Anycast Address as follows: 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 is not a router. No additional dependencies for the subnet which is not a router. No additional dependencies for the subnet
prefix while the EUI-64 and an IID dependencies will be discussed prefix while the EUI-64 and an IID dependencies will be discussed
skipping to change at page 11, line 25 skipping to change at page 11, line 32
| subnet prefix | 1111111...111111 | anycast ID | | subnet prefix | 1111111...111111 | anycast ID |
+------------------------------+------------------+------------+ +------------------------------+------------------+------------+
| interface identifier field | | interface identifier field |
In the case discussed above there is no additional dependency for the In the case discussed above there is no additional dependency for the
subnet prefix with the exception of the EUI-64 and an IID dependency. subnet prefix with the exception of the EUI-64 and an IID dependency.
These will be discussed later in this document. These will be discussed later in this document.
3.3.2. Addresses used by Embedded-RP (RFC3956) 3.3.2. Addresses used by Embedded-RP (RFC3956)
Embedded-RP [19] reflects the concept of integrating the Rendezvous Embedded-RP [20] reflects the concept of integrating the Rendezvous
Point (RP) IPv6 address into the IPv6 multicast group address. Due Point (RP) IPv6 address into the IPv6 multicast group address. Due
to this embedding and the fact that the length of the IPv6 address to this embedding and the fact that the length of the IPv6 address
AND the IPv6 multicast address are 128 bits, it is not possible to AND the IPv6 multicast address are 128 bits, it is not possible to
have the complete IPv6 address of the multicast RP embedded as such. have the complete IPv6 address of the multicast RP embedded as such.
This resulted in a restriction of 15 possible RP-addresses per prefix This resulted 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 is set to all '0'. the Interface ID is set to all '0'.
[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 bit.
This format implies that when selecting subnet prefixes longer then This format implies that when selecting subnet prefixes longer then
64, and the bits beyond the 64th one are none-zero, the subnet can 64, and the bits beyond the 64th one are non-zero, the subnet can not
not use embedded-RP. 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,
eventhough it would not generate major problems.
3.3.3. ISATAP addresses 3.3.3. ISATAP addresses
ISATAP [24] is an automatic tunneling protocol used to provide IPv6 ISATAP [25] is an automatic tunneling protocol used to provide IPv6
connectivity over an IPv4 campus or enterprise environment. In order connectivity over an IPv4 campus or enterprise environment. In order
to leverage the underlying IPv4 infrastructure, the IPv6 addresses to leverage the underlying IPv4 infrastructure, the IPv6 addresses
are constructed in a special format. are constructed in a special 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.
[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 recommended When using subnet prefix length longer then 64 bits it is recommended
that that the portion of the IPv6 prefix from bit 65 to the end of that that the portion of the IPv6 prefix from bit 65 to the end of
the subnet prefix does not match with the well-known ISATAP [0000: the subnet prefix does not match with the well-known ISATAP [0000:
5EFE] address portion. 5EFE] address portion.
In its actual definition there is no multicast support on ISATAP In its actual definition there is no multicast support on ISATAP
3.3.4. /126 addresses 3.3.4. /126 addresses
The 126 bit subnet prefixes are typically used for point-to-point The 126 bit subnet prefixes are typically used for point-to-point
links similar to the RFC3021 [5] recommendations for IPv4. The usage links similar to a the IPv4 address conservative /30 allocation for
of this subnet address length does not lead to any additional point-to-point links. The usage of this subnet address length does
considerations other than the ones discussed earlier in this section, not lead to any additional considerations other than the ones
particularly those related to the "u" and "g" bits. discussed earlier in this section, particularly those related to the
"u" and "g" bits.
3.3.5. /127 addresses 3.3.5. /127 addresses
The usage of the /127 addresses is not valid and should be strongly The usage of the /127 addresses is not valid and should be strongly
discouraged as documented in RFC3627 [14]. discouraged as documented in RFC3627 [15].
3.3.6. /128 addresses 3.3.6. /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 either the following well-known addresses:
skipping to change at page 13, line 47 skipping to change at page 14, line 8
future transport protocols future transport protocols
o These addresses may add complexity to the operational management o These addresses may add complexity to the operational management
and troubleshooting of the infrastructure (i.e. which address and troubleshooting of the infrastructure (i.e. which address
belongs to which real host) belongs to which real host)
o A reverse DNS lookup check may be broken when using privacy o A reverse DNS lookup check may be broken when using privacy
extensions extensions
4.3. Cryptographically Generated IPv6 Addresses 4.3. Cryptographically Generated IPv6 Addresses
Cryptographically Generated Addresses (CGAs) are based upon RFC3972 Cryptographically Generated Addresses (CGAs) are based upon RFC3972
[21] and provide a method for binding a public signature key to an [22] and provide a method for binding a public signature key to an
IPv6 address in the Secure Neighbor Discovery (SEND) protocol [20]. IPv6 address in the Secure Neighbor Discovery (SEND) protocol [21].
The basic idea is to generate the interface identifier (i.e. the The basic idea is to generate the interface identifier (i.e. the
rightmost 64 bits) of the IPv6 address by computing a cryptographic rightmost 64 bits) of the IPv6 address by computing a cryptographic
hash of the public key. The resulting IPv6 address is called a hash of the public key. The resulting IPv6 address is called a
cryptographically generated address (CGA). The corresponding private cryptographically generated address (CGA). The corresponding private
key can then be used to sign messages sent from that address. key can then be used to sign messages sent from that address.
Implications to be aware of when using CGA addresses are found in Implications to be aware of when using CGA addresses are found in
section 7 of RFC3972 [21]: section 7 of RFC3972 [22]:
o When using CGA addresses the values of the "u" and "g" bits are o When using CGA addresses the values of the "u" and "g" bits are
ignored however it does not add any security or implementation ignored however it does not add any security or implementation
implications implications
o There is no mechanism for proving that an address is not a CGA o There is no mechanism for proving that an address is not a CGA
o When it is discovered that a node has been compromised, a new o When it is discovered that a node has been compromised, a new
signature key and a new CGA should be generated signature key and a new CGA should be generated
Due to the fact that CGA generated addresses are almost Due to the fact that CGA generated addresses are almost
indistinguishable from a privacy address and has similar properties indistinguishable from a privacy address and has similar properties
for many purposes, the same considerations as with privacy addresses for many purposes, the same considerations as with privacy addresses
skipping to change at page 15, line 30 skipping to change at page 15, line 33
RIPE of 2001:630::/32. The current recommended practice is for sites RIPE of 2001:630::/32. The current recommended practice is for sites
to receive a /48 allocation, and on this basis Southampton has to receive a /48 allocation, and on this basis Southampton has
received such a prefix for its own use, specifically 2001:630: received such a prefix for its own use, specifically 2001:630:
d0::/48. The regional network also uses its own allocation from the d0::/48. The regional network also uses its own allocation from the
NREN provider. 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 [22] on renumbered following the aforementioned renumbering procedure [23] on
two occasions, and this has proven adequate (with provisos documented two occasions, and this has proven adequate (with provisos documented
in [29]. We also do not see any need to deploy ULAs for in or out of in [32]. We also do not see any need to deploy ULAs for in or out of
band network management; there are enough IPv6 prefixes available in band network management; there are enough IPv6 prefixes available in
the site allocation for the infrastructure. In some cases, use of the site allocation for the infrastructure. In some cases, use of
private IP address space in IPv4 creates problems, so we believe that private IP address space in IPv4 creates problems, so we believe that
the availability of ample global IPv6 address space for the availability of ample global IPv6 address space for
infrastructure may be a benefit for many sites. infrastructure may be a benefit for many sites.
No 6bone addressing is used on site any more. We note that since the No 6bone addressing is used on site any more. We note that since the
6bone phaseout of June 2006 [16] most transit ISPs have begun 6bone phaseout of June 2006 [17] 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 organization 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. We note that IPv6 here as they are not in scope for the document. We note that IPv6
has advantages for multicast group address allocation. In IPv4 a has advantages for multicast group address allocation. In IPv4 a
site needs to use techniques like GLOP to pick a globally unique site needs to use techniques like GLOP to pick a globally unique
multicast group to use. This is problematic if the site does not use multicast group to use. This is problematic if the site does not use
BGP and have an ASN. In IPv6 unicast-prefix-based IPv6 multicast BGP and have an ASN. In IPv6 unicast-prefix-based IPv6 multicast
addresses empower a site to pick a globally unique group address addresses empower a site to pick a globally unique group address
skipping to change at page 16, line 30 skipping to change at page 16, line 35
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 on 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, we chose to deploy our IP subnets In a dual-stack network, we choose to deploy our 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. We do not in the same administrative domains and the same geography. We do not
expect to have IPv6-only subnets in production use for a while yet, expect to have IPv6-only subnets in production use for a while yet,
outside our test beds and our early Mobile IPv6 trials. With outside our test beds and our early Mobile IPv6 trials. With
congruent addressing, our firewall policies are also aligned for IPv4 congruent addressing, our firewall policies are also aligned for IPv4
and IPv6 traffic at our site border. and IPv6 traffic at our 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
skipping to change at page 17, line 5 skipping to change at page 17, line 13
the network infrastructure and the server side systems. the network infrastructure and the server side systems.
5.1.3. Other considerations 5.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 [24] for example. There is no use of ISATAP [25] for example.
For the Mobile IPv6 early trails, we have allocated one prefix for For the Mobile IPv6 early trials, we have allocated one prefix for
Home Agent (HA) use. We have not yet considered in detail how Mobile Home Agent (HA) use. We have not yet considered in detail how Mobile
IPv6 usage may grow, and whether more or even every subnet will IPv6 usage may grow, and whether more or even every subnet will
require HA support. require HA support.
The university operates a tunnel broker [7] service on behalf of The university operates a tunnel broker [7] service on behalf of
UKERNA for JANET sites. This uses separate address space from JANET, UKERNA for JANET sites. This uses separate address space from JANET,
not our university site allocation. not our university site allocation.
5.1.4. Node configuration considerations 5.1.4. Node configuration considerations
We currently use stateless autoconfiguration on most subnets for IPv6 We currently use stateless autoconfiguration on most subnets for IPv6
hosts. There is no DHCPv6 service deployed yet, beyond tests of hosts. There is no DHCPv6 service deployed yet, beyond tests of
early code releases. We plan to deploy DHCPv6 for address assignment early code releases. We plan to deploy DHCPv6 for address assignment
when robust client and server code is available (at the time of when robust client and server code is available (at the time of
writing the potential for this looks good, e.g. via the ISC writing the potential for this looks good, e.g. via the ISC
implementation). We also are seeking a common integrated DHCP/DNS implementation). We also are seeking a common integrated DHCP/DNS
management platform, even if the servers themselves are not co- management platform, even if the servers themselves are not co-
located, including integrated DHCPv4 and DHCPv6 server configuration, located, including integrated DHCPv4 and DHCPv6 server configuration,
as discussed in [26]. Currently we add client statelessly as discussed in [27]. Currently we add client statelessly
autoconfigured addresses to the DNS manually, though dynamic DNS is autoconfigured addresses to the DNS manually, though dynamic DNS is
an option. Our administrators would prefer the use of DHCP because an option. Our administrators would prefer the use of DHCP because
they believe it gives them more management control. 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 [27], we note that all our hosts are dual-stack, and scanning attacks [30], we note that all our hosts are dual-stack, and
thus are potentially exposed over both protocols anyway. We publish thus are potentially exposed over both protocols anyway. We publish
all addresses in DNS, and do not operate a two faced DNS. all addresses in DNS, and do not operate a two faced DNS.
We have internal usage of RFC3041 privacy addresses [6] currently We have internal usage of RFC3041 privacy addresses [6] currently
(certain platforms currently ship with it on by default), but may (certain platforms currently ship with it on by default), but may
wish to administratively disable this (perhaps via DHCP) to ease wish to administratively disable this (perhaps via DHCP) to ease
management complexity. However, we need to determine the feasibility management complexity. However, we need to determine the feasibility
of this on all systems, e.g. for guests on wireless LAN or other of this on all systems, e.g. for guests on wireless LAN or other
user-maintained systems. Network management and monitoring should be user-maintained systems. Network management and monitoring should be
simpler without RFC3041 in operation, in terms of identifying which simpler without RFC3041 in operation, in terms of identifying which
skipping to change at page 18, line 11 skipping to change at page 18, line 18
a DNS server, or can pick 'random' addresses for obfuscation, though a DNS server, or can pick 'random' addresses for obfuscation, though
that's not an issue for publicly advertised addresses (dns, mx, web, that's not an issue for publicly advertised addresses (dns, mx, web,
etc). etc).
5.2. Service Provider Considerations 5.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 5.2.1 starts with some thoughts regarding objective Sub-section 5.2.1 starts with some thoughts regarding objective
requirements of such an addressing schema and deriving a few general requirements of such an addressing schema and derives a few general
thumb rules that have to be kept in mind when designing an ISP IPv6 thumb rules that have to be kept in mind when designing an ISP IPv6
addressing plan. addressing plan.
Sub-section 5.2.2 illustrates these findings of 5.2.1 with an Sub-section 5.2.2 illustrates these findings of 5.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 millions of Internet Services as well as Network Access services to several
customers. millions of customers.
5.2.1. Investigation of objective Requirements for an IPv6 addressing 5.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 5.2.2 is one possible example. sub-section 5.2.2 is one possible example.
For this document it is assumed that our exemplary ISP has to fulfil For this document it is assumed that our exemplary ISP has to fulfill
several roles for its customers as there are: several roles for its customers as there are:
o Local Internet Registry o Local Internet Registry
o Network Access Provider o Network Access Provider
o Internet Service Provider o Internet Service Provider
5.2.1.1. Requirements for an IPv6 addressing schema from the LIR 5.2.1.1. Requirements for an IPv6 addressing schema from the LIR
perspective of the Service Provider perspective of the Service Provider
In their role as LIR the Service Providers have to care about the In their role as LIR the Service Providers have to care about the
policy constraints of the RIRs and the standards of the IETF policy constraints of the RIRs and the standards of the IETF
regarding IPv6 addressing. In this context, the following basic regarding IPv6 addressing. In this context, the following basic
requirements and recommendations have to be taken into account and requirements and recommendations have to be considered and should be
should be satisfied by the IPv6 address allocation plan of a Service satisfied by the IPv6 address allocation plan of a Service Provider:
Provider: o As recommended in RFC 3177 [9] and in several RIR policies
o As recommended in RFC 3177 [7] 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.) o "Big customers" (like big enterprises, governmental agencies etc.)
may receive shorter prefixes according to their needs when this may receive shorter prefixes according to their needs when this
need could be documented and justified to the RIR. need could 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 of 0.94 as it is defined for IPv6. This requirement ratio that is proposed for IPv6. This requirement corresponds to
corresponds to the demand for an efficient usage of the IPv6 the demand for an efficient usage of the IPv6 address aggregate by
address aggregate by the Service Provider. (Note: A 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 of the Service 0.94 means an effective usage of about 31% of a /20 prefix of the
Provider on the basis of /48 assignments.) Service Provider on the basis of /48 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 o The LIR has to make available means for supporting the reverse DNS
mapping of the customer prefixes. mapping of the customer prefixes.
5.2.1.2. IPv6 addressing schema requirements from the ISP perspective 5.2.1.2. IPv6 addressing schema requirements from the ISP perspective
of the Service Provider of the Service Provider
From ISP perspective the following basic requirements could be From ISP perspective the following basic requirements could be
identified: identified:
skipping to change at page 19, line 44 skipping to change at page 20, line 4
routing table (DFZ). This strong aggregation keeps the routing routing table (DFZ). This strong aggregation keeps the routing
tables of the DFZ small and eases filtering and access control tables of the DFZ small and eases filtering and access control
very much. very much.
o The IPv6 addressing schema of the SP should contain maximal o The IPv6 addressing schema of the SP should contain maximal
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 the time with new customers, transport technologies and business
cases. The requirement of maximal flexibility is contrary to the cases. The requirement of maximal flexibility is contrary to the
requirements of strong IPv6 address aggregation and efficient requirements of strong IPv6 address aggregation and efficient
address usage, but at this point each SP has to decide which of address usage, but at this point each SP has to decide which of
these requirements to prioritize. these requirements to prioritize.
o Keeping the multilevel network hierarchy of an ISP in mind, due to o Keeping the multilevel network hierarchy of an ISP in mind, due to
addressing efficiency reasons not all hierarchy levels can and addressing efficiency reasons not all hierarchy levels can and
should be mapped into the IPv6 addressing schema of an ISP. should be mapped into the IPv6 addressing schema of an ISP.
Sometimes it is much better to implement "flat" addressing for the Sometimes it is much better to implement "flat" addressing for the
ISP network than to loose big chunks of the IPv6 address aggregate ISP network than to loose big chunks of the IPv6 address aggregate
in addressing each level of network hierarchy. Besides that a in addressing each level of network hierarchy. Besides that a
decoupling of provider network addressing and customer addressing decoupling of provider network addressing and customer addressing
is recommended. (Note: A strong aggregation e.g. on POP, is recommended. (Note: A strong aggregation e.g. on POP,
aggregation router or LER level limits the numbers of customer aggregation router or Label Edge Router (LER) level limits the
routes that are visible within the ISP network but brings also numbers of customer routes that are visible within the ISP network
down the efficiency of the IPv6 addressing schema. That's why but brings also down the efficiency of the IPv6 addressing schema.
each ISP has to decide how many internal aggregation levels he That's why each ISP has to decide how many internal aggregation
wants to deploy.) levels it wants to deploy.)
5.2.1.3. IPv6 addressing schema requirements from the Network Access 5.2.1.3. IPv6 addressing schema requirements 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 flexible enough to o The IPv6 addressing schema of the SP must be flexible enough to
adapt changes that are injected from the customer side. This adapt changes that are injected from the customer side. This
covers changes to addressing architecture or routing topology that covers changes to addressing architecture or routing topology that
are triggered from for instance the raising needs of the customers are triggered from for instance the growing needs of the customers
regarding IPv6 addresses as well as changes that come from regarding IPv6 addresses as well as changes that come from
topological modifications (e.g. when the customer moves from one topological modifications (e.g. when the customer moves from one
point of network attachment (POP) to another). point of network attachment (POP) to another).
o For each IPv6 address assignment to customers a "buffer zone" must o For each IPv6 address assignment to customers a "buffer zone" must
be reserved that allows the customer to grow in its addressing be reserved that allows the customer to grow in its addressing
range without renumbering or assignment of additional prefixes. range without renumbering or assignment of additional 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. multi-homed network access with the same SP).
These few requirements are only part of all the requirements a These few requirements are only part of all the requirements a
Service Provider has to investigate and keep in mind during the Service Provider has to investigate and keep in mind during the
definition phase of its addressing architecture. Each SP will most definition phase of its addressing architecture. Each SP will most
likely add more constraints to this list. likely add more constraints to this list.
5.2.1.4. A few thumb rules for designing an IPv6 ISP addressing 5.2.1.4. A few thumb rules for designing an IPv6 ISP addressing
architecture architecture
As outcome of the above investigation of requirements regarding an As outcome of the above enumeration of requirements regarding an ISP
ISP IPv6 addressing plane the following design "thumb rules" should IPv6 addressing plan the following design "thumb rules" have been
be derived: derived:
o No "One size fits all" Each ISP must develop its own IPv6 address o No "One size fits all" Each ISP must develop its own IPv6 address
allocation schema depending on its concrete business needs. It is allocation schema depending on its concrete business needs. It is
not practicable to design one addressing plan that fits all ISPs not practicable to design one addressing plan that fits for all
(Small / big, Routed / MPLS-based, access / transit, LIR / No-LIR, kinds of ISPs (Small / big, Routed / MPLS-based, 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 SPs own infrastructure
will be addressed in a fairly flat way whereas the part of the will be addressed in a fairly flat way whereas the part of the
customer addressing architecture should contain several levels of customer addressing architecture should contain several levels of
aggregation. 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 necessary. 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
skipping to change at page 21, line 25 skipping to change at page 21, line 33
well as to allow future growing rates (e.g. of customer well as to allow future growing 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 "thumb rule" -
flexibility. flexibility.
5.2.2. Exemplary IPv6 address allocation plan for a Service Provider 5.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 to provide IPv6 backbone transport based backbone and implements 6PE [29] to provide IPv6 backbone
between the different locations (POPs) of a fully dual-stacked transport between the different locations (POPs) of a fully dual-
network access and aggregation area. stacked network access and aggregation area.
Besides that 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-own infrastructure and to
delegate IPv6 prefixes to its customers following the above mentioned delegate IPv6 prefixes to its customers following the above mentioned
requirements and thumb rules as far as possible. requirements and thumb rules as far as possible.
The below figure summarizes the device types in an SP network and the The below figure summarizes the device types in an SP network and the
typical network design. The network hierarchy of the SP has to be typical network design of a MPLS-based service provider. The network
taken into account for the design of an IPv6 addressing schema and hierarchy of the SP has to be taken into account for the design of an
defines its basic shape and the levels of aggregation. IPv6 addressing schema and defines its basic shape 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 22, line 40 skipping to change at page 22, line 41
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
Basic design decisions for the exemplary Service Provider IPv6 Basic design decisions for the exemplary Service Provider IPv6
address plan regarding customer prefixes take into consideration: address plan regarding customer prefixes take into consideration:
o The prefixes assigned to all customers behind the same LER (e.g. o The prefixes assigned to all customers behind the same LER (e.g.
LER or LER-BB) are aggregated under one prefix. This ensures that LER or LER-BB) are aggregated under one LER prefix. This ensures
the number of labels that have to be used for 6PE is limited and that the number of labels that have to be used for 6PE is limited
hence provides a strong MPLS label conservation. 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 real * A pool (e.g. /24) for satisfying the addressing needs of really
"big" customers (as defined in 5.2.2.1 sub-section A.) that "big" customers (as defined in 5.2.2.1 sub-section A.) that
need IPv6 prefixes larger than /48 (e.g. /32). These customers need IPv6 prefixes larger than /48 (e.g. /32). These customers
are assumed to be connected to several POPs of the access are assumed to be connected to several POPs of the access
network, so that this customer prefix will be visible in each network, so that this customer prefix will be visible in each
of these POPs. of these POPs.
* A pool (e.g. /24) for the LERs with direct customer connections * A pool (e.g. /24) for the LERs with direct customer connections
(e.g. dedicated line access) and without an additional (e.g. dedicated line access) and without an additional
aggregation area between the customer and the LER. (These LERs aggregation area between the customer and the LER. (These LERs
are mostly connected to a limited number of customers because are mostly connected to a limited number of customers because
of the limited number of interfaces/ports.) of the limited number of interfaces/ports.)
* A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve * A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve
a high number of customers that are normally connected via some a high number of customers that are normally connected via some
kind of aggregation network (e.g. DSL customers behind a BB- kind of aggregation network (e.g. DSL customers behind a BB-
RAR or Dial-In customers behind a RAR). RAR or Dial-In customers behind a RAR).
* The IPv6 address delegation within each Pool (end customer * The IPv6 address delegation within each Pool (end customer
skipping to change at page 23, line 17 skipping to change at page 23, line 19
aggregation area between the customer and the LER. (These LERs aggregation area between the customer and the LER. (These LERs
are mostly connected to a limited number of customers because are mostly connected to a limited number of customers because
of the limited number of interfaces/ports.) of the limited number of interfaces/ports.)
* A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve * A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve
a high number of customers that are normally connected via some a high number of customers that are normally connected via some
kind of aggregation network (e.g. DSL customers behind a BB- kind of aggregation network (e.g. DSL customers behind a BB-
RAR or Dial-In customers behind a RAR). RAR or Dial-In customers behind a RAR).
* The IPv6 address delegation within each Pool (end customer * The IPv6 address delegation within each Pool (end customer
delegation or also the aggregates that are dedicated to the delegation or also the aggregates that are dedicated to the
LERs itself) should be chosen with an additional buffer zone of LERs itself) should be chosen with an additional buffer zone of
300% for future growth. 100% - 300% for future growth. I.e. 1 or 2 additional prefix
bits should be reserved according to the expected future growth
rate of the corresponding customer / the corresponding network
device aggregate.
5.2.2.1. Defining an IPv6 address allocation plan for customers of the 5.2.2.1. Defining an IPv6 address allocation plan for customers of the
Service Provider Service Provider
5.2.2.1.1. 'Big' customers 5.2.2.1.1. 'Big' customers
SP's "big" customers receive their prefix from the /24 IPv6 address SP's "big" customers receive their prefix from the /24 IPv6 address
aggregate that has been reserved for their "big" customers. A aggregate that has been reserved for their "big" customers. A
customer is considered as "big" customer if it has a very complex customer is considered as "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 300% future growing zone is range 32-48 and for each assignment a 100 or 300% future growing zone
marked as "reserved" for this customer. This means that for instance is marked as "reserved" for this customer. This means for instance
with a delegation of a /34 to a customer the /32 that contains this that with a delegation of a /34 to a customer the corresponding /32
/34 is reserved for the customer for future usage. prefix (which contains this /34) is reserved for the customers 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) [28]. Algorithm (SAA) [31].
5.2.2.1.2. 'Common' customers 5.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 300% future growing IPv6 address range is reserved for each Again a 100 - 300% future growing IPv6 address range is reserved for
customer, so that a "common" customer receives a /48 allocation but each customer, so that a "common" customer receives a /48 allocation
has a /46 reserved. but has a /47 or /46 reserved.
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 the
customer IPv6 address aggregate (e.g. /38) of the corresponding LER. 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 In all other cases (e.g. the customer is attached to a RAR that is
themselves aggregated to an AG or to a LER) at least 2 different themselves aggregated to an AG or to a LER) 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
skipping to change at page 24, line 29 skipping to change at page 24, line 35
should be reserved. (Note: This approach requires of course some should be reserved. (Note: This approach requires of course some
"fine tuning" of the addressing schema based on a very good knowledge "fine tuning" of the addressing schema based on a very good knowledge
of the Service Provider network topology including actual growing of the Service Provider network topology including actual growing
ranges and rates.) 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 of
the aggregation network - AG or RAR) is exhausted, the related LER the aggregation network - AG or RAR) is exhausted, the related LER
(or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to
/37 or /36) so that the originally reserved growing zone can be used /37 or /36) so that the originally reserved growing zone can be used
for further IPv6 address allocations to customers. In the case where for further IPv6 address allocations to customers. In the case where
the growing zone is exhausted as well a new prefix range from the this growing zone is exhausted as well a new prefix range from the
corresponding pool of the next higher hierarchy level can be corresponding pool of the next higher hierarchy level can be
requested. 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 IPv6
address pool of the LER where the customers are attached and address pool of the LER where the customers are attached and
aggregated and 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. This approach leads of course to a higher amount of
customer routes at LER and aggregation network level but takes a customer routes at LER and aggregation network level but takes a
great amount of complexity out of the addressing schema. great amount of complexity out of the addressing schema.
Nevertheless the aggregation of the customer prefixes to one prefix Nevertheless the aggregation of the customer prefixes to one prefix
at LER level is realized as required above. at LER level is realized as required above.
(Note: The handling of (e.g. technically triggered) changes within
the ISP access network is shortly discussed in section 5.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 than these growing areas can be freed and used
for assignments for prefix pools to other devices at the same level for assignments for prefix pools to other devices at the same level
of the network hierarchy. of the network hierarchy.
5.2.2.2. Defining an IPv6 address allocation plan for the Service 5.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 SPs own network infrastructure a /32 (or
/40) from the "big" customers address pool can be chosen. /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 chose 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 this 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 network
or operational information into the IID. or operational information into the IID.
It is assumed that a 300% growing zones for each level of network It is assumed that again 100 - 300% growing zones for each level of
hierarchy and additional prefixes may be assigned to POPs and/or network hierarchy and additional prefix bits may be assigned to POPs
routers if needed. 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 prefix that has been chosen for addressing SPs own (Note: The /32 prefix that has been chosen for addressing SPs own
IPv6 network infrastructure gives enough place to code additional IPv6 network infrastructure gives enough place to code additional
functionalities like security levels or private and test 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.)
skipping to change at page 26, line 10 skipping to change at page 26, line 21
In the case when ULAs are used it is possible to map the proposed In the case when ULAs are used it is possible to map the proposed
internal IPv6 addressing of SPs own network infrastructure as internal IPv6 addressing of SPs own network infrastructure as
described in 5.2.2.2 above directly to the ULA addressing schema by described in 5.2.2.2 above 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.
5.2.3.2. Multicast 5.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.
5.2.3.3. POP Multi-homing or Change of POP 5.2.3.3. POP Multi-homing
POP (or better LER) Multi-homing of customers with the same SP can be POP (or better LER) Multi-homing of customers with the same SP can be
realized within the proposed IPv6 addressing schema of the SP by realized within the proposed IPv6 addressing schema of the SP by
assigning multiple LER-dependent prefixes to this customer (i.e. assigning multiple LER-dependent prefixes to this customer (i.e.
considering each customer location as a single-standing customer) or considering each customer location as a single-standing customer) or
by choosing a customer prefix out of the pool of "big" customers. by choosing a customer prefix out of the pool of "big" customers.
The second solution has the disadvantage that in every LER where the 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 requiring an explicit MPLS label.
An equal effect happens when a customer changes its point of
attachment to another POP/LER since in this case the customer prefix
could not be aggregated into the LER prefix and needs to be
advertised more specific in the IGP.
(Note: The described negative POP/LER Multi-homing effects to the (Note: The described negative POP/LER Multi-homing effects to the
addressing architecture in the SP access network are not tackled by addressing architecture in the SP access network are not tackled by
implementing the Shim6 Site Multi-homing approach since this approach implementing the Shim6 Site Multi-homing approach since this approach
targets only on a mechanism for dealing with multiple prefixes in end targets only on a mechanism for dealing with multiple prefixes in end
systems -- the SP will nevertheless have unaggregated customer systems -- the SP will nevertheless have unaggregated customer
prefixes in its internal routing tables.) prefixes in its internal routing tables.)
5.2.3.4. Extensions needed for the later IPv6 migration phases 5.2.3.4. Changing Point of Network Attachement
In the possible case that a customer has to change its point of
network attachment to another POP/LER within the ISP access network
two different approaches can be applied assuming that the customer
uses PA addresses out of the SP aggregate:
1.) The customer has to renumber its network with an adequate
customer prefix out of the aggregate of the corresponding LER/RAR of
its new network attachement. To minimise the administrative burden
for the customer the prefix should be of the same size as the former.
This conserves the IPv6 address aggregation within the SP network
(and the MPLS label space) but adds additional burden to the
customer. Hence this approach will most likely only be chosen in the
case of 'small customers' with temporary addressing needs and/or
prefix delegation with address auto-configuration.
2.) The customer does not need to renumber its network and keeps its
address aggregate.
This apporach leads to additional more-specific routing entries
within the IGP routing table of the LER and will hence consume
additional MPLS labels - but it is totally transparent to the
customer. Because this results in additional administrative effort
and will stress the router resources (label space, memory) of the ISP
this solution will only be offered to the most valuable customers of
an ISP (like e.g. "big customers" or "enterprise customers").
Nevertheless the ISP has again to find a fair trade-off between
customer renumbering and sub-optimal address aggregation (i.e. the
generation of additional more-specific routing entries within the IGP
and the waste of MPLS Label space).
5.2.3.5. Restructuring of SP (access) network and Renumbering
A technically triggered restructuring of the SP (access) network (for
instance because of split of equipment or installation of new
equipment) should not lead to a customer network renumbering. This
challenge should be handled in advance by an intelligent network
design and IPv6 address planing.
In the worst case the customer network renumbering could be avoided
through the implementation of more specific customer routes. (Note:
Since this kind of network restructuring will mostly happen within
the access network (at the level) below the LER, the LER aggregation
level will not be harmed and the more-specific routes will not
consume additional MPLS label space.)
5.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 a 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 in the case when the whole MPLS backbone
infrastructure (LDP, IGP etc.) is realized over IPv6 transport an infrastructure (LDP, IGP etc.) is realized over IPv6 transport an
addressing of the LSRs is needed. Other changes may be necessary as addressing of the LSRs is needed. Other changes may be necessary as
well but should not be explained at this point. well but should not be explained at this point.
6. IANA Considerations 6. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
7. Security Considerations 7. Security Considerations
This IPv6 addressing document does not have any direct impact on This IPv6 addressing document does not have any direct impact on
Internet infrastructure security. Internet infrastructure security.
8. Acknowledgements 8. Acknowledgements
Constructive feedback and contributions have been received from Stig Constructive feedback and contributions have been received from Marla
Venaas, Pekka Savola, John Spence, Patrick Grossetete, Carlos Garcia Azinger, Stig Venaas, Pekka Savola, John Spence, Patrick Grossetete,
Braschi, Brain Carpenter and Mark Smith. Carlos Garcia Braschi, Brian Carpenter, Mark Smith and Ginny Listman.
9. References 9. References
9.1. Normative References 9.1. Normative References
9.2. Informative References 9.2. Informative References
[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996. RFC 1918, February 1996.
skipping to change at page 27, line 40 skipping to change at page 28, line 45
[5] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31- [5] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-
Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021,
December 2000. December 2000.
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[7] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [7] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address [8] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[9] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001. Allocations to Sites", RFC 3177, September 2001.
[9] Durand, A. and C. Huitema, "The H-Density Ratio for Address [10] Durand, A. and C. Huitema, "The H-Density Ratio for Address
Assignment Efficiency An Update on the H ratio", RFC 3194, Assignment Efficiency An Update on the H ratio", RFC 3194,
November 2001. November 2001.
[10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[11] Draves, R., "Default Address Selection for Internet Protocol [12] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[12] Blanchet, M., "A Flexible Method for Managing the Assignment of [13] Blanchet, M., "A Flexible Method for Managing the Assignment of
Bits of an IPv6 Address Block", RFC 3531, April 2003. Bits of an IPv6 Address Block", RFC 3531, April 2003.
[13] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast [14] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast
Address Format", RFC 3587, August 2003. Address Format", RFC 3587, August 2003.
[14] Savola, P., "Use of /127 Prefix Length Between Routers [15] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, September 2003. Considered Harmful", RFC 3627, September 2003.
[15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [16] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[16] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address [17] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
Allocation) Phaseout", RFC 3701, March 2004. Allocation) Phaseout", RFC 3701, March 2004.
[17] Droms, R., "Stateless Dynamic Host Configuration Protocol [18] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[18] Huitema, C. and B. Carpenter, "Deprecating Site Local [19] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[19] Savola, P. and B. Haberman, "Embedding the Rendezvous Point [20] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address", RFC 3956, (RP) Address in an IPv6 Multicast Address", RFC 3956,
November 2004. November 2004.
[20] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [21] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[21] Aura, T., "Cryptographically Generated Addresses (CGA)", [22] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[22] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering [23] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering
an IPv6 Network without a Flag Day", RFC 4192, September 2005. an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[23] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [24] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[24] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- [25] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-
Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214,
October 2005. October 2005.
[25] Hinden, R. and S. Deering, "IP Version 6 Addressing [26] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[26] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host [27] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
Issues", RFC 4477, May 2006. Issues", RFC 4477, May 2006.
[27] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning [28] ARIN, "http://www.arin.net/policy/nrpm.html#six54".
[29] De Clerq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider
Edge Routers (6PE) (draft-ooms-v6ops-bgp-tunnel-06.txt)",
June 2006.
[30] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning
(draft-ietf-v6ops-scanning-implications-00.txt)", June 2006. (draft-ietf-v6ops-scanning-implications-00.txt)", June 2006.
[28] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment [31] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment
Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003. Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003.
[29] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to [32] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to
think about when Renumbering an IPv6 network think about when Renumbering an IPv6 network
(draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007. (draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007.
[33] "List of Internet-Drafts relevant to the Multi6-WG
(http://ops.ietf.org/multi6/draft-list.html )".
[34] Lear, E., "Things MULTI6 Developers should think about
(draft-ietf-multi6-things-to-think-about-01)", January 2005.
[35] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming
solutions (draft-ietf-multi6-multihoming-threats-03)",
January 2005.
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
skipping to change at page 32, line 5 skipping to change at page 33, line 5
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
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 32, line 29 skipping to change at page 33, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 107 change blocks. 
178 lines changed or deleted 253 lines changed or added

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