draft-ietf-v6ops-addcon-00.txt   draft-ietf-v6ops-addcon-01.txt 
Network Working Group G. Van de Velde Network Working Group G. Van de Velde
Internet-Draft C. Popoviciu Internet-Draft C. Popoviciu
Expires: December 3, 2006 Cisco Systems Expires: December 3, 2006 Cisco Systems
T. Chown T. Chown
University of Southampton University of Southampton
June 1, 2006 O. Bonness
C. Hahn
T-Systems Enterprise Services GmbH
IPv6 Unicast Address Assignment Considerations IPv6 Unicast Address Assignment Considerations
<draft-ietf-v6ops-addcon-00.txt> <draft-ietf-v6ops-addcon-01.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 48 skipping to change at page 2, line 5
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 guideliness on handling this aspect to network addressing. Lack of guidelines on handling this aspect of
of network design could slow down the integration of IPv6. This network design could slow down the integration of IPv6. This draft
draft aims to provide the information and recommendations relevant to aims to provide the information and recommendations relevant to
planning the addressing aspects of IPv6 deployments. The draft also planning the addressing aspects of IPv6 deployments. The draft also
provides IPv6 addressing case studies for both an enterprise and an provides IPv6 addressing case studies for both an enterprise and an
ISP network. In this first version of the draft we aim to provoke ISP network. In this first version of the draft we aim to provoke
discussion on this important topic; more detailed case study texts discussion on this important topic; more detailed case study texts
will follow. will follow.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Network Level Addressing Design Considerations . . . . . . . . 4 2. Network Level Addressing Design Considerations . . . . . . . . 5
2.1. Global Unique Addresses . . . . . . . . . . . . . . . . . 4 2.1. Global Unique Addresses . . . . . . . . . . . . . . . . . 5
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 4 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5
2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 5 2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 6
2.4. Network Level Design Considerations . . . . . . . . . . . 6 2.4. Network Level Design Considerations . . . . . . . . . . . 7
2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 7 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
2.4.2. Address Space Conservation . . . . . . . . . . . . . . 7 2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 7 3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8
3.1. Considerations for subnet prefixes shorter then /64 . . . 7 3.1. Considerations for subnet prefixes shorter then /64 . . . 8
3.2. Considerations for /64 prefixes . . . . . . . . . . . . . 8 3.2. Considerations for /64 prefixes . . . . . . . . . . . . . 9
3.3. Considerations for subnet prefixes longer then /64 . . . . 8 3.3. Considerations for subnet prefixes longer then /64 . . . . 9
3.3.1. Anycast addresses . . . . . . . . . . . . . . . . . . 8 3.3.1. Anycast addresses . . . . . . . . . . . . . . . . . . 9
3.3.2. Addresses used by Embedded-RP (RFC3956) . . . . . . . 10 3.3.2. Addresses used by Embedded-RP (RFC3956) . . . . . . . 11
3.3.3. ISATAP addresses . . . . . . . . . . . . . . . . . . . 10 3.3.3. ISATAP addresses . . . . . . . . . . . . . . . . . . . 11
3.3.4. /126 addresses . . . . . . . . . . . . . . . . . . . . 11 3.3.4. /126 addresses . . . . . . . . . . . . . . . . . . . . 12
3.3.5. /127 addresses . . . . . . . . . . . . . . . . . . . . 11 3.3.5. /127 addresses . . . . . . . . . . . . . . . . . . . . 12
3.3.6. /128 addresses . . . . . . . . . . . . . . . . . . . . 11 3.3.6. /128 addresses . . . . . . . . . . . . . . . . . . . . 12
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 11 4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 12
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 12 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 13
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 12 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 13
4.3. Cryptographically Generated IPv6 Addresses . . . . . . . . 12 4.3. Cryptographically Generated IPv6 Addresses . . . . . . . . 13
4.4. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 13 4.4. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Enterprise Considerations . . . . . . . . . . . . . . . . 13 5.1. Enterprise Considerations . . . . . . . . . . . . . . . . 14
5.1.1. Obtaining general IPv6 network prefixes . . . . . . . 13 5.1.1. Obtaining general IPv6 network prefixes . . . . . . . 14
5.1.2. Forming an address (subnet) allocation plan . . . . . 14 5.1.2. Forming an address (subnet) allocation plan . . . . . 15
5.1.3. Other considerations . . . . . . . . . . . . . . . . . 15 5.1.3. Other considerations . . . . . . . . . . . . . . . . . 16
5.1.4. Node configuration considerations . . . . . . . . . . 15 5.1.4. Node configuration considerations . . . . . . . . . . 16
5.1.5. Observations . . . . . . . . . . . . . . . . . . . . . 16 5.1.5. Observations . . . . . . . . . . . . . . . . . . . . . 17
5.2. Service Provider Considerations . . . . . . . . . . . . . 16 5.2. Service Provider Considerations . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5.2.1. Investigation of objective Requirements for an
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 IPv6 addressing schema of a Service Provider . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.2. IPv6 address allocation plan for a Service Provider . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 5.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Introduction 1. Introduction
The Internet Protocol Version 6 (IPv6) Addressing Architecture [23] The Internet Protocol Version 6 (IPv6) Addressing Architecture [23]
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 three principal allocated types: Global Unique there are currently three principal allocated types: Global Unique
Addresses [12] ('globals'), Unique Local IPv6 Addresses [22] (ULAs) Addresses [12] ('globals'), Unique Local IPv6 Addresses [22] (ULAs)
and 6bone address space [3]. and 6bone address space [3].
skipping to change at page 3, line 28 skipping to change at page 4, line 28
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 its organization. IPv6 address space that has been allocated to its 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 'Subnet Prefix'
(address usage within a subnet). Thus the document includes a (address usage within a subnet). Thus the document includes a
discussion of aspects of address assignment to nodes and interfaces discussion of aspects of address assignment to nodes and interfaces
in an IPv6 network. Finally the document will provide two examples in an IPv6 network. Finally the document will provide two examples
of a successfully deployed address plan in a service provider (ISP) of successfully deployed address plans in a service provider (ISP)
and an enterprise network. and an enterprise network.
Parts of this document highlight the differences that an experienced Parts of this document highlight the differences that an experienced
IPv4 network designer should consider when planning an IPv6 IPv4 network designer should consider when planning an IPv6
deployment, for example: deployment, for example:
o IPv6 devices will more likely be multi-addressed in comparison o IPv6 devices will more likely be multi-addressed in comparison
with their IPv4 counterparts. with their IPv4 counterparts.
o The practically unlimited size of an IPv6 subnet (2^64 bits) o The practically unlimited size of an IPv6 subnet (2^64 bits)
reduces the requirement to size subnets to device counts for the reduces the requirement to size subnets to device counts for the
skipping to change at page 4, line 9 skipping to change at page 5, line 9
should note that IPv6 networks receive their global unicast address should note that IPv6 networks receive their global unicast address
allocation from their 'upstream' provider, which may be another ISP, allocation from their 'upstream' provider, which may be another ISP,
a Local Internet Registry (LIR) or a Regional Internet Registry a Local Internet Registry (LIR) or a Regional Internet Registry
(RIR). In each case the prefix received is provider assigned (PA); (RIR). In each case the prefix received is provider assigned (PA);
there is currently no provider independent (PI) address space for there is currently no provider independent (PI) address space for
IPv6. Thus an IPv6 network which changes provider will need to IPv6. Thus an IPv6 network which changes provider will need to
undergo a renumbering process, as described in [21]. A separate undergo a renumbering process, as described in [21]. A separate
document [28] makes recommendations to ease the IPv6 renumbering document [28] makes recommendations to ease the IPv6 renumbering
process. process.
This document neither discusses implemention aspects between ULA This document neither discusses implementation aspects between ULA
addresses and Site-local addresses. Most implementations know about addresses and Site-local addresses. Most implementations know about
Site-local addresses even though they are deprecated, and do not know Site-local addresses even though they are deprecated, and do not know
about ULAs - even though they are according current specification. about ULAs - even though they are according current specification.
As result transitioning between these types of addresses may cause As result transitioning between these types of addresses may cause
difficulties. difficulties.
2. Network Level Addressing Design Considerations 2. Network Level Addressing Design Considerations
This section discusses the kind of IPv6 addresses used at the network This section discusses the kind of IPv6 addresses used at the network
level for the IPv6 infrastructure. The kind of addresses that can be level for the IPv6 infrastructure. The kind of addresses that can be
considered are Global Unique Addresses, ULAs and 6bone address space. considered are Global Unique Addresses, ULAs and 6bone address space.
2.1. Global Unique Addresses 2.1. Global Unique Addresses
The most commonly used unicast addresses will be Global Unique The most commonly used unicast addresses will be Global Unique
Addresses ('globals'). No significant considerations are neccesary Addresses ('globals'). No significant considerations are necessary
if the organization has an address space assignment and a single if the organization has an address space assignment and a single
prefix is deployed through a single upstream provider. prefix is deployed through a single upstream provider.
However, a multihomed site may deploy addresses from two or more However, a multihomed site may deploy addresses from two or more
Service Provider assigned IPv6 address ranges. Here, the network Service Provider assigned IPv6 address ranges. Here, the network
Administrator must have awareness on where and how these ranges are Administrator must have awareness on where and how these ranges are
used on the multihomed infrastructure environment. The nature of the used on the multihomed infrastructure environment. The nature of the
usage of multiple prefixes may depend on the reason for multihoming usage of multiple prefixes may depend on the reason for multihoming
(e.g. resilience failover, load balancing, policy-based routing, or (e.g. resilience failover, load balancing, policy-based routing, or
multihoming during an IPv6 renumbering event). IPv6 introduces multihoming during an IPv6 renumbering event). IPv6 introduces
skipping to change at page 6, line 12 skipping to change at page 7, line 12
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 [15] and should be avoided on range is deprecated as of 6th June 2006 [15] 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 [21]. defined in [21].
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 subneting 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.
o Organizational Boundaries - by assigning a common prefix to an o Organizational Boundaries - by assigning a common prefix to an
entire organization or group within a corporate infrastructure. entire organization or group within a corporate infrastructure.
o Service Type - by reserving certain prefixes for predefined o Service Type - by reserving certain prefixes for predefined
services such as: VoIP, Content Distribution, wireless services, services such as: VoIP, Content Distribution, wireless services,
Internet Access, etc. Internet Access, etc.
Such logical addressing plans have the potential to simplify network Such logical addressing plans have the potential to simplify network
skipping to change at page 7, line 17 skipping to change at page 8, line 17
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 [7]. for address space. By default a site will receive a /48 prefix [7].
The default provider allocation via the RIRs is currently a /32 [27]. The default provider allocation via the RIRs is currently a /32 [27].
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 [27]. There are examples of allocations as large as address usage [27]. 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 subneting, 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 [8] value for IPv6 is 0.94 compared to the current The proposed HD [8] 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, instead of based on addresses like with IPv4. sites (i.e. on a basis of /48), instead of based on addresses like
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 [23]. In this document we allocation are specified in RFC4291 [23]. In this document we
analyze their practical implications. Based on RFC4291 [23] it is analyze their practical implications. Based on RFC4291 [23] 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 are 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 bad practice. The shortest subnet prefix that could theoretically
be assigned to an interface or node is limited by the size of the be assigned to an interface or node is limited by the size of the
network prefix allocated to the organization. network prefix allocated to the organization.
A possible reason for choosing the subnet prefix for an interface A possible reason for choosing the subnet prefix for an interface
shorter then /64 is that it would allow more nodes to be attached to shorter then /64 is that it would allow more nodes to be attached to
skipping to change at page 8, line 42 skipping to change at page 9, line 44
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
considerated when selecting a subnet length longer then 64 bits considered when selecting a subnet length longer then 64 bits.
subnet prefix length.
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 [23] provides a definition for the required Subnet Router RFC4291 [23] 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 dependancy for the subnet prefix which is not a router. No additional dependencies for the subnet
with the exception of the EUI-64 and an IID dependency. These will prefix while the EUI-64 and an IID dependencies will be discussed
be discussed later in this document. later in this document.
3.3.1.2. Reserved IPv6 Subnet Anycast Addresses 3.3.1.2. Reserved IPv6 Subnet Anycast Addresses
RFC2526 [4] stated that within each subnet, the highest 128 interface RFC2526 [4] stated that within each subnet, the highest 128 interface
identifier values are reserved for assignment as subnet anycast identifier values are reserved for assignment as subnet anycast
addresses. addresses.
The construction of a reserved subnet anycast address depends on the The construction of a reserved subnet anycast address depends on the
type of IPv6 addresses used within the subnet, as indicated by the type of IPv6 addresses used within the subnet, as indicated by the
format prefix in the addresses. format prefix in the addresses.
The first type of Subnet Router Anycast addresses have been defined The first type of Subnet Router Anycast addresses have been defined
as follows for EUI-64 format: as follows for EUI-64 format:
| 64 bits | 57 bits | 7 bits | | 64 bits | 57 bits | 7 bits |
+---------------------------------+------------------+------------+ +------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID | | subnet prefix | 1111110111...111 | anycast ID |
+---------------------------------+------------------+------------+ +------------------------------+------------------+------------+
The anycast address structure implies that it is important to avoid The anycast address structure implies that it is important to avoid
creating a subnet prefix where the bits 65 to 121 are defined as creating a subnet prefix where the bits 65 to 121 are defined as
"1111110111...111" (57 bits in total) so that confusion can be "1111110111...111" (57 bits in total) so that confusion can be
avoided. avoided.
For other IPv6 address types (that is, with format prefixes other For other IPv6 address types (that is, with format prefixes other
than those listed above), the interface identifier is not in EUI-64 than those listed above), the interface identifier is not in EUI-64
format and may be other than 64 bits in length; these reserved subnet format and may be other than 64 bits in length; these reserved subnet
anycast addresses for such address types are constructed as follows: anycast addresses for such address types are constructed as follows:
| n bits | 121-n bits | 7 bits | | n bits | 121-n bits | 7 bits |
+---------------------------------+------------------+------------+ +------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID | | subnet prefix | 1111111...111111 | anycast ID |
+---------------------------------+------------------+------------+ +------------------------------+------------------+------------+
| interface identifier field | | interface identifier field |
In the case discussed above there is no additional dependancy 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 [18] reflects the concept of integrating the Rendezvous Embedded-RP [18] 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.
Consequently this leads to the awareness that when when selecting This format implies that when selecting subnet prefixes longer then
subnet prefixes longer then 64, where the bits beyond the 64th bit 64, and the bits beyond the 64th one are none-zero, the subnet can
are none-zero embedded-RP can not be used for that subnet. not 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.
3.3.3. ISATAP addresses 3.3.3. ISATAP addresses
ISATAP [25] 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 [25] address has the IPv4 address embedded, based on a An IPv6 ISATAP [25] address has the IPv4 address embedded, based on a
predefined structure policy that identifies them as an ISATAP [25] predefined structure policy that identifies them as an ISATAP [25]
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 welknown ISATAP [0000:5EFE] the subnet prefix does not match with the well-known ISATAP [0000:
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 the RFC3021 [5] recommendations for IPv4. The usage
of this subnet address length does not lead to any additional of this subnet address length does not lead to any additional
considerations other than the ones discussed earlier in this section, considerations other than the ones discussed earlier in this section,
particularly those related to the "u" and "g" bits. 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 [13]. discouraged as documented in RFC3627 [13].
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 offlink 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:
o Subnet Router Anycast Address o Subnet Router Anycast Address
o Reserved Subnet Anycast Address o Reserved Subnet Anycast Address
o Addresses used by Embedded-RP o Addresses used by Embedded-RP
o ISATAP Addresses o ISATAP Addresses
4. Allocation of the IID of an IPv6 Address 4. Allocation of the IID of an IPv6 Address
In order to have a complete IPv6 address, an interface must be In order to have a complete IPv6 address, an interface must be
associated a prefix and an Interface Identifier (IID). Section 3 of associated a prefix and an Interface Identifier (IID). Section 3 of
this document analyzed the prefix selection considerations. This this document analyzed the prefix selection considerations. This
skipping to change at page 12, line 16 skipping to change at page 13, line 16
When using this method the network administrator has to allocate a When using this method the network administrator has to allocate a
valid 64 bit subnet prefix. The EUI-64 [2] allocation procedure can valid 64 bit subnet prefix. The EUI-64 [2] allocation procedure can
from that moment onwards assign the remaining 64 IID bits in a from that moment onwards assign the remaining 64 IID bits in a
stateless manner. All the considerations for selecting a valid IID stateless manner. All the considerations for selecting a valid IID
have been incorporated in the EUI-64 methodology. have been incorporated in the EUI-64 methodology.
4.2. Using Privacy Extensions 4.2. Using Privacy Extensions
The main purpose of IIDs generated based on RFC3041 [6] is to provide The main purpose of IIDs generated based on RFC3041 [6] is to provide
privacy to the entity using this address. While there is no privacy to the entity using this address. While there are no
particular restraints in the usage of these addresses as defined in particular constraints in the usage of these addresses as defined in
[6] there are some implications to be aware of when using privacy [6] there are some implications to be aware of when using privacy
addresses as documented in section 4 of RFC3041 [6]: addresses as documented in section 4 of RFC3041 [6]:
o The privacy extension algoritm may complicate flexibility in o The privacy extension algorithm may complicate flexibility in
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
skipping to change at page 13, line 23 skipping to change at page 14, line 23
In this situation the actual allocation is done by human intervention In this situation the actual allocation is done by human intervention
and consideration needs to be given to the complete IPv6 address so and consideration needs to be given to the complete IPv6 address so
that it does not result in overlaps with any of the well known IPv6 that it does not result in overlaps with any of the well known IPv6
addresses: addresses:
o Subnet Router Anycast Address o Subnet Router Anycast Address
o Reserved Subnet Anycast Address o Reserved Subnet Anycast Address
o Addresses used by Embedded-RP o Addresses used by Embedded-RP
o ISATAP Addresses o ISATAP Addresses
When using an address assigned by human intervention it is When using an address assigned by human intervention it is
recommended to choose IPv6 addresses which are not abvious to guess recommended to choose IPv6 addresses which are not obvious to guess
and/or avoid any IPv6 addresses that embed IPv4 addresses used in the and/or avoid any IPv6 addresses that embed IPv4 addresses used in the
current infrastructure. Following these two recommendations will current infrastructure. Following these two recommendations will
make it more difficult for malicious third parties to guess targets make it more difficult for malicious third parties to guess targets
for attack, and thus reduce security threats to a certain extent. for attack, and thus reduce security threats to a certain extent.
5. Case Studies 5. Case Studies
tbc. tbc.
5.1. Enterprise Considerations 5.1. Enterprise Considerations
skipping to change at page 14, line 7 skipping to change at page 15, line 7
Southampton connects to JANET, the UK academic network. JANET Southampton connects to JANET, the UK academic network. JANET
currently has a /32 allocation from RIPE of 2001:630::/32. The currently has a /32 allocation from RIPE of 2001:630::/32. The
current recommended practice is for sites to receive a /48 current recommended practice is for sites to receive a /48
allocation, and on this basis Southampton has received such a prefix allocation, and on this basis Southampton has received such a prefix
for its own use, specifically 2001:630:d0::/48. for its own use, specifically 2001:630:d0::/48.
No ULA addressing is used on site. The campus does not expect to No ULA addressing is used on site. The campus does not expect to
change service provider, and thus does not plan to use ULAs for the change service provider, and thus does not plan to use ULAs for the
(perceived) benefit of easing network renumbering. Indeed, the (perceived) benefit of easing network renumbering. Indeed, the
campus has renumbered following the aforementioned renumbering campus has renumbered following the aforementioned renumbering
procedure [21] on two occassions, and this has proven adequate (with procedure [21] on two occasions, and this has proven adequate (with
provisos documented in [28]. We also do not see any need to deploy provisos documented in [28]. We also do not see any need to deploy
ULAs for in or out of band network management; there are enough IPv6 ULAs for in or out of band network management; there are enough IPv6
prefixes available in the site allocation for the infrastructure. prefixes available in the site allocation for the infrastructure.
No 6bone addressing is used on site. This was phased out some time No 6bone addressing is used on site. This was phased out some time
ago. We note that as of 6th June 2006 transit ISPs will likely ago. We note that as of 6th June 2006 transit ISPs will likely
filter any attempted use of such prefixes. filter any attempted use of such prefixes.
Southampton does participate in global and organisation 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. Embedded RP is in here as they are not in scope for the document. Embedded RP is in
use, and has been tested successfully across providers between sites. use, and has been tested successfully across providers between sites.
5.1.2. Forming an address (subnet) allocation plan 5.1.2. Forming an address (subnet) allocation plan
The campus has a /16 prefix for IPv4 use; in principle 256 subnets of The campus has a /16 prefix for IPv4 use; in principle 256 subnets of
256 addresses. In reality the subnetting is muddier, because of 256 addresses. In reality the subnetting is muddier, because of
concerns of IPv4 address conservation; subnets are sized to the hosts concerns of IPv4 address conservation; subnets are sized to the hosts
within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts
skipping to change at page 15, line 35 skipping to change at page 16, line 35
The university operates a tunnel broker service on behalf of UKERNA. The university operates a tunnel broker service on behalf of UKERNA.
This uses separate address space from JANET, not the main university This uses separate address space from JANET, not the main university
allocation. 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 do seek a common integrated DHCP/DNS early code releases. We do seek a common integrated DHCP/DNS
management platform, even if the servers themselves are not management platform, even if the servers themselves are not co-
colocated. Currently we add client statelessly autoconfigured located. Currently we add client statelessly autoconfigured
addresses to the DNS manually. Our administrators would prefer the addresses to the DNS manually. Our administrators would prefer the
use of DHCP because they believe it gives them some management use of DHCP because they believe it gives them some management
control. control.
Regarding the [26] implications, we note that all our hosts are dual- Regarding the [26] implications, we note that all our hosts are dual-
stack, and thus are potentially exposed over both protocols anyway. stack, and thus are potentially exposed over both protocols anyway.
We publish all addresses in DNS, and do not operate a two faced DNS. We publish all addresses in DNS, and do not operate a two faced DNS.
We have internal usage of RFC3041 privacy addresses currently, but We have internal usage of RFC3041 privacy addresses currently, but
may wish to administratibely disable this (perhaps via DHCP), but we may wish to administratively disable this (perhaps via DHCP), but we
need to determine the feasibility of this on all systems, e.g. for need to determine the feasibility of this on all systems, e.g. for
WLAN guests or other user-maintained systems. Network management WLAN guests or other user-maintained systems. Network management
should be simpler without RFC3041 in opeation. Note RFC3041 is only should be simpler without RFC3041 in operation. Note RFC3041 is only
an issue for outbound connections. an issue for outbound connections.
We manually configure server addresses to avoid address changes on a We manually configure server addresses to avoid address changes on a
change of network adaptor. With IPv6 you can choose to pick ::53 for change of network adaptor. With IPv6 you can choose to pick ::53 for
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.1.5. Observations 5.1.5. Observations
The site is not (yet) using prefix delegation tools for IPv6. The site is not (yet) using prefix delegation tools for IPv6.
5.2. Service Provider Considerations 5.2. Service Provider Considerations
case studies are requested and in development. they should be added In this section an IPv6 addressing schema is sketched that could
for the -01 draft. serve as an example by a Service Provider offering Internet Services
as well as Network Access services to millions of customers. In this
example, the Service Provider is assumed to operate an MPLS based
backbone and implements 6PE to provide IPv6 backbone transport
between the different locations (POPs) of a fully dual-stacked
network access and aggregation area.
6. Security Considerations Besides that it is assumed that the Service Provider
o has received a /20 from its RIR
o operates its own LIR
o has to address its own IPv6 infrastructure
o delegates prefixes from this aggregate to its customers.
Hence this addressing schema covers the numbering of the Service
Provider IPv6 network devices as well the customer aggregates chosen
out of the /20 prefix of the SP.
5.2.1. Investigation of objective Requirements for an IPv6 addressing
schema of a Service Provider
The first step of the IPv6 addressing plan design for a Service
provider should be the identification of all technical, operational,
political and business requirements that have to be satisfied by the
services supported by this addressing schema.
According to the different technical constraints and business models
as well as the different weights of these requirements (from the
point of view of the corresponding Service Provider) it is very
likely that different addressing schemas will be developed and
deployed by different ISPs. Nevertheless the addressing schema of
this section is one possible example.
5.2.1.1. Requirements for an IPv6 addressing schema from the LIR
perspective of the Service Provider
In their role as LIR the Service Providers have to care about the
policy constraints of the RIRs and the standards of the IETF
regarding IPv6 addressing. In this context, the following basic
requirements and recommendations have to be taken into account and
should be satisfied by the IPv6 address allocation plan of a Service
Provider:
o As recommended in RFC 3177 [7] and in several RIR policies
"Common" customers sites (normally private customers) should
receive a /48 prefix from the aggregate of the Service Provider.
(Note: The addressing plan must be flexible enough and take into
account the possible change of the minimum allocation size for end
users currently under definition by the RIRs.)
o "Big customers" (like big enterprises, governmental agencies etc.)
may receive shorter prefixes according to their needs when this
need could be documented and justified to the RIR.
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
corresponds to the demand for an efficient usage of the IPv6
address aggregate by the Service Provider. (Note: A HD-ratio of
0.94 means an effective usage of about 31% of the /20 of the
Service Provider on the basis of /48 assignments.)
o All assignments to customers have to be documented and stored into
a database that can also be queried by the RIR.
o The LIR has to make available means for supporting the reverse DNS
mapping of the customer prefixes.
5.2.1.2. IPv6 addressing schema requirements from the ISP perspective
of the Service Provider
From ISP perspective the following basic requirements could be
identified:
o The IPv6 address allocation schema must be able to realize a
maximal aggregation of all IPv6 address delegations to customers
into the /20 of the Service Provider. Only this /20 will be
routed and injected from the Service Provider into the global
routing table (DFZ). This strong aggregation keeps the routing
tables of the DFZ small and eases filtering and access control
very much. (Note: A strong aggregation e.g. on POP or LER basis
limits as well the numbers of customer routes that are visible
within the ISP network.)
o The IPv6 addressing schema of the SP should contain maximal
flexibility since the infrastructure of the SP will change over
the time with new customers, transport technologies and business
cases. The requirement of maximal flexibility is contrary to the
requirements of strong IPv6 address aggregation and efficient
address usage, but at this point each SP has to decide which of
these requirements to prioritize.
o Keeping the multilevel network hierarchy of an ISP in mind, due to
addressing efficiency reasons not all hierarchy levels can and
should be mapped into the IPv6 addressing schema of an ISP.
Sometimes it is much better to implement "flat" addressing for the
ISP network than to loose big chunks of the IPv6 address aggregate
in addressing each level of network hierarchy. Besides that a
decoupling of provider network addressing and customer addressing
is recommended.
5.2.1.3. IPv6 addressing schema requirements from the Network Access
provider perspective of the Service Provider
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
Provider role. Some of the basic requirements are:
o The IPv6 addressing schema of the SP must be flexible enough to
adapt changes that are injected from the customer side. This
covers changes that are based on the raising IPv6 address needs of
the customer as well as changes that come from topological
modifications (e.g. when the customer moves from one point of
network attachment (POP) to another).
o For each IPv6 address assignment to customers a "buffer zone" must
be reserved that allows the customer to grow in its addressing
range without renumbering or assignment of additional prefixes.
o The IPv6 addressing schema of the SP must deal with multiple-
attachments of a single customer to the SP network infrastructure
(i.e. multi-homed network access with the same SP).
These few requirements are only part of all the requirements a
Service Provider has to investigate and keep in mind during the
definition phase of its addressing architecture. Each SP will most
likely add more constraints to this list.
5.2.2. IPv6 address allocation plan for a Service Provider
This section illustrates how the /20 IPv6 prefix of the SP can be
used to address the SP-own infrastructure and to delegate IPv6
prefixes to its customers following the above mentioned requirements
as far as possible.
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
taken into account for the design of an IPv6 addressing schema and
defines its basic shape.
+------------------------------------------------------------------+
| LSRs of the MPLS Backbone of the SP |
+------------------------------------------------------------------+
| | | | |
| | | | |
+-----+ +-----+ +--------+ +--------+ +--------+
| LER | | LER | | LER-BB | | LER-BB | | LER-BB |
+-----+ +-----+ +--------+ +--------+ +--------+
| | | | | | / | | |
| | | | | | / | | |
| | | | +------+ +------+ +------+ | |
| | | | |BB-RAR| |BB-RAR| | AG | | |
| | | | +------+ +------+ +------+ | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | RAR | | RAR | | RAR | | RAR |
| | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
+-------------------------------------------------------------------+
| Customer networks |
+-------------------------------------------------------------------+
Figure: Exemplary Service Provider Network
LSR ... Label Switch Router
LER ... Label Edge Router
LER-BB ... Broadband Label Edge Router
RAR ... Remote Access Router
BB-RAR ... Broadband Remote Access Router
AG ... Aggregation Router
Basic design decisions for the SP IPv6 address plan regarding
customer prefixes take into consideration:
o The prefixes assigned to all customers behind the same LER (e.g.
LER or LER-BB) are aggregated under one prefix. This ensures that
the number of labels that have to be used for 6PE is limited and
hence provides a strong MPLS label conservation.
o The /20 prefix of the SP is separated into 3 different pools that
are used to allocate IPv6 prefixes to the customers of the SP:
* A pool (e.g. /24) for satisfying the addressing needs of real
"big" customers (as defined in 5.2.2.1 sub-section A.) that
need IPv6 prefixes larger than /48 (e.g. /32). These customers
are assumed to be connected to several POPs of the access
network, so that this customer prefix will be visible in each
of these POPs.
* A pool (e.g. /24) for the LERs with direct customer connections
(e.g. dedicated line access) and without an additional
aggregation area between the customer and the LER. (These LERs
are mostly connected to a limited number of customers because
of the limited number of interfaces/ports.)
* 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
kind of aggregation network (e.g. DSL customers behind a BB-
RAR or Dial-In customers behind a RAR).
* The IPv6 address delegation within each Pool (end customer
delegation or also the aggregates that are dedicated to the
LERs itself) should be chosen with an additional buffer zone of
300% for future growth.
5.2.2.1. Defining an IPv6 address allocation plan for customers of the
Service Provider
5.2.2.1.1. 'Big' customers
SP's "big" customers receive their prefix from the /24 IPv6 address
aggregate that has been reserved for their "big" customers. A
customer is considered as "big" customer if it has a very complex
network infrastructure and/or huge IPv6 address needs (e.g. because
of very large customer numbers) and/or several uplinks to different
POPs of the SP network.
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
marked as "reserved" for this customer. This means that for instance
with a delegation of a /34 to a customer the /32 that contains this
/34 is reserved for the customer for future usage.
The prefixes for the "big" customers can be chosen from the
corresponding LER customer pool by either using an equidistant
algorithm or using mechanisms simililar to the Sparse Alocation
Algorithm (SAA) [27].
5.2.2.1.2. 'Common' customers
All customers that are not "big" customers are considered as "common"
customers. They represent the majority of customers hence they
receive a /48 out of the IPv6 customer address pool of the LER where
they are directly connected or aggregated.
Again a 300% future growing IPv6 address range is reserved for each
customer, so that a "common" customer receives a /48 allocation but
has a /46 reserved.
In the network access scenarios where the customer is directly
connected to the LER the customer prefix is directly taken out of the
customer IPv6 address aggregate (e.g. /38) of the corresponding LER.
In all other cases (e.g. the customer is attached to a RAR that is
themselves aggregated to an AG or to a LER) at least 2 different
approaches are possible.
1.) Mapping of Aggregation Network Hierarchy into Customer IPv6
Addressing Schema. The aggregation network hierarchy could be mapped
into the design of the customer prefix pools of each network level in
order to achieve a maximal aggregation at the LER level as well as at
the intermediate levels. (Example: Customer - /48, RAR - /38, AG -
/32, LER-BB - /30). At each network level an adequate growing zone
should be reserved. (Note: This approach requires of course some
"fine tuning" of the addressing schema based on a very good knowledge
of the Service Provider network topology including actual growing
ranges and rates.)
When the IPv6 customer address pool of a LER (or another device of
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
/37 or /36) so that the originally reserved growing zone can be used
for further IPv6 address allocations to customers. In the case where
the growing zone is exhausted as well a new prefix range from the
corresponding pool of the next higher hierarchy level can be
requested.
2.) "Flat" Customer IPv6 Addressing Schema. The other option is to
allocate all the customer prefixes directly out of the customer IPv6
address pool of the LER where the customers are attached and
aggregated and ignore the intermediate aggregation network
infrastructure. This approach leads of course to a higher amount of
customer routes at LER and aggregation network level but takes a
great amount of complexity out of the addressing schema.
Nevertheless the aggregation of the customer prefixes to one prefix
at LER level is realized as required above.
If the actual observed growing rates show that the reserved growing
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
of the network hierarchy.
5.2.2.2. Defining an IPv6 address allocation plan for the Service
Provider Network Infrastructure
For the IPv6 addressing of SPs own network infrastructure a /32 (or
/40) from the "big" customers address pool can be chosen.
This SP infrastructure prefix is used to code the network
infrastructure of the SP by assigning a /48 to every POP/location and
using for instance a /56 for coding the corresponding router within
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
/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
links within this POP.)
The IIDs of the router interfaces may be generated by using EUI-64 or
through plain manual configuration e.g. for coding additional network
or operational information into the IID.
It is assumed that a 300% growing zones for each level of network
hierarchy and additional prefixes may be assigned to POPs and/or
routers if needed.
Loopback interfaces of routers may be chosen from the first /64 of
the /56 router prefix (in the example above).
(Note: The /32 prefix that has been chosen for addressing SPs own
IPv6 network infrastructure gives enough place to code additional
functionalities like security levels or private and test
infrastructure although such approaches haven't been considered in
more detail for the above described SP until now.)
Point-to-point links to customers (e.g. PPP links, dedicated line
etc.) may be addressed using /126 prefixes out of the first /64 of
the access routers that could be reserved for this reason.
5.2.3. Additional Remarks
5.2.3.1. ULA
From the actual view point of SP there is no compelling reason why
ULAs should be used from a SP. Look at section 2.2.
ULAs could be used inside the SP network in order to have an
additional "site-local scoped" IPv6 address for SPs own
infrastructure for instance for network management reasons and maybe
also in order to have an addressing schema that couldn't be reached
from outside the SP network.
In the case when ULAs are used it is possible to map the proposed
internal IPv6 addressing of SPs own network infrastructure as
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.
5.2.3.2. Multicast
IPv6 Multicast-related addressing issues are out of the scope of this
document.
5.2.3.3. POP Multi-homing or Change of POP
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
assigning multiple LER-dependent prefixes to this customer (i.e.
considering each customer location as a single-standing customer) or
by choosing a customer prefix out of the pool of "big" customers.
The second solution has the disadvantage that in every LER where the
customer is attached this prefix will appear inside the IGP routing
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
addressing architecture in the SP access network are not tackled by
implementing the Shim6 Site Multi-homing approach since this approach
targets only on a mechanism for dealing with multiple prefixes in end
systems -- the SP will nevertheless have unaggregated customer
prefixes in its internal routing tables.)
5.2.3.4. Extensions needed for the later IPv6 migration phases
The proposed IPv6 addressing schema for a SP needs some slight
enhancements / modifications for the later phases of IPv6
integration, for instance in the case when the whole MPLS backbone
infrastructure (LDP, IGP etc.) is realized over IPv6 transport an
addressing of the LSRs is needed. Other changes may be necessary as
well but should not be explained at this point.
6. IANA Considerations
There are no extra IANA consideration for this document.
7. Security Considerations
This IPv6 addressing documents does not have any direct impact on This IPv6 addressing documents does not have any direct impact on
Internet infrastructure security. Internet infrastructure security.
7. Acknowledgements 8. Acknowledgements
Constructive feedback and contributions have been received from Stig Constructive feedback and contributions have been received from Stig
Venaas, Pekka Savola, John Spencer, Patrick Grossetete and Carlos Venaas, Pekka Savola, John Spencer, Patrick Grossetete and Carlos
Garcia Braschi. Garcia Braschi.
8. References 9. References
8.1. Normative References 9.1. Normative References
8.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.
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address [2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[3] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address [3] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address
Allocation", RFC 2471, December 1998. Allocation", RFC 2471, December 1998.
skipping to change at page 19, line 5 skipping to change at page 27, line 15
[26] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown- [26] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown-
v6ops- port-scanning-implications-02.txt)", October 2005. v6ops- port-scanning-implications-02.txt)", October 2005.
[27] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment [27] 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.
[28] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to [28] 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-03.txt)", July 2005. (draft-chown-v6ops-renumber-thinkabout-03.txt)", July 2005.
[29] Paul Wilson, Raymond Plzak, Axel Pawlik, "IPv6 Address Space
Management (www.ripe.net/ripe/docs/ipv6-sparse.html)",
February 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 20, line 5 skipping to change at page 28, line 34
Tim Chown Tim Chown
University of Southampton University of Southampton
Highfield Highfield
Southampton, SO17 1BJ Southampton, SO17 1BJ
United Kingdom United Kingdom
Phone: +44 23 8059 3257 Phone: +44 23 8059 3257
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
Olaf Bonness
T-Systems Enterprise Services GmbH
Goslarer Ufer 35
Berlin, 10589
Germany
Phone: +49 30 3497 3124
Email: Olaf.Bonness@t-systems.com
Christian Hahn
T-Systems Enterprise Services GmbH
Goslarer Ufer 35
Berlin, 10589
Germany
Phone: +49 30 3497 3164
Email: HahnC@t-systems.com
Intellectual Property Statement Intellectual Property Statement
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.
 End of changes. 41 change blocks. 
88 lines changed or deleted 474 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/