draft-ietf-v6ops-addcon-08.txt   draft-ietf-v6ops-addcon-09.txt 
IPv6 Operations G. Van de Velde IPv6 Operations G. Van de Velde
Internet-Draft C. Popoviciu Internet-Draft C. Popoviciu
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: December 7, 2008 T. Chown Expires: February 9, 2009 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
June 5, 2008 August 8, 2008
IPv6 Unicast Address Assignment Considerations IPv6 Unicast Address Assignment Considerations
<draft-ietf-v6ops-addcon-08.txt> <draft-ietf-v6ops-addcon-09.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 December 7, 2008. This Internet-Draft will expire on February 9, 2009.
Abstract Abstract
One fundamental aspect of any IP communications infrastructure is its One fundamental aspect of any IP communications infrastructure is its
addressing plan. With its new address architecture and allocation addressing plan. With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network policies, the introduction of IPv6 into a network means that network
designers and operators need to reconsider their existing approaches designers and operators need to reconsider their existing approaches
to network addressing. Lack of guidelines on handling this aspect of to network addressing. Lack of guidelines on handling this aspect of
network design could slow down the deployment and integration of network design could slow down the deployment and integration of
IPv6. This document aims to provide the information and IPv6. This document aims to provide the information and
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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
2.4.2. Address Space Conservation . . . . . . . . . . . . . . 9 2.4.2. Address Space Conservation . . . . . . . . . . . . . . 9
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 9 3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 9
3.1. Considerations for Subnet Prefixes Shorter then /64 . . . 9 3.1. Considerations for Subnet Prefixes Shorter then /64 . . . 9
3.2. Considerations for /64 Prefixes . . . . . . . . . . . . . 10 3.2. Considerations for /64 Prefixes . . . . . . . . . . . . . 10
3.3. Considerations for Subnet Prefixes Longer then /64 . . . . 10 3.3. Considerations for Subnet Prefixes Longer then /64 . . . . 10
3.3.1. Anycast Addresses . . . . . . . . . . . . . . . . . . 11 3.3.1. Anycast Addresses . . . . . . . . . . . . . . . . . . 11
3.3.2. Addresses Used by Embedded-RP (RFC3956) . . . . . . . 12 3.3.2. Addresses Used by Embedded-RP (RFC3956) . . . . . . . 12
3.3.3. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 13 3.3.3. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 13
3.3.4. /126 Addresses . . . . . . . . . . . . . . . . . . . . 13 3.3.4. /126 Addresses . . . . . . . . . . . . . . . . . . . . 14
3.3.5. /127 Addresses . . . . . . . . . . . . . . . . . . . . 14 3.3.5. /127 Addresses . . . . . . . . . . . . . . . . . . . . 14
3.3.6. /128 Addresses . . . . . . . . . . . . . . . . . . . . 14 3.3.6. /128 Addresses . . . . . . . . . . . . . . . . . . . . 14
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 14 4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 14
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 14 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 14
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 14 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 15
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 15 4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 19
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 19 A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 19
A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 19 A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 19
A.1.2. Forming an Address (subnet) Allocation Plan . . . . . 20 A.1.2. Forming an Address (subnet) Allocation Plan . . . . . 20
A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 21 A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 21
A.1.4. Node Configuration Considerations . . . . . . . . . . 21 A.1.4. Node Configuration Considerations . . . . . . . . . . 21
A.2. Service Provider Considerations . . . . . . . . . . . . . 22 A.2. Service Provider Considerations . . . . . . . . . . . . . 22
A.2.1. Investigation of objective Requirements for an A.2.1. Investigation of objective Requirements for an
IPv6 addressing schema of a Service Provider . . . . 22 IPv6 addressing schema of a Service Provider . . . . 22
A.2.2. Exemplary IPv6 Address Allocation Plan for a A.2.2. Exemplary IPv6 Address Allocation Plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 25 Service Provider . . . . . . . . . . . . . . . . . . . 26
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 30 A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
The Internet Protocol Version 6 (IPv6) Addressing Architecture The Internet Protocol Version 6 (IPv6) Addressing Architecture
[RFC4291] defines three main types of addresses: unicast, anycast and [RFC4291] defines three main types of addresses: unicast, anycast 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: Globally Unique there are currently two principal allocated types: Globally Unique
Addresses [RFC3587] ('globals') and Unique Local IPv6 Addresses Addresses [RFC3587] ('globals') and Unique Local IPv6 Addresses
[RFC4193] (ULAs). In addition until recently there has been [RFC4193] (ULAs). In addition until recently there has been
'experimental' 6bone address space [RFC3701], though its use has been 'experimental' 6bone address space [RFC3701], though its use has been
skipping to change at page 6, line 23 skipping to change at page 6, line 23
addresses on their network without asking for a globally unique addresses on their network without asking for a globally unique
registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48, registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48,
the same as the currently recommended allocation for a site from the the same as the currently recommended allocation for a site from the
globally routable IPv6 address space [RFC3177]. globally routable IPv6 address space [RFC3177].
A site willing to use ULA address space can have either (a) multiple A site willing to use ULA address space can have either (a) multiple
/48 prefixes (e.g. a /44) and wishes to use ULAs, or (b) has one /48 /48 prefixes (e.g. a /44) and wishes to use ULAs, or (b) has one /48
and wishes to use ULAs or (c) a site has a less-than-/48 prefix (e.g. and wishes to use ULAs or (c) a site has a less-than-/48 prefix (e.g.
a /56 or /64) and wishes to use ULAs. In all above cases the ULA a /56 or /64) and wishes to use ULAs. In all above cases the ULA
addresses can be randomly chosen according the principles specified addresses can be randomly chosen according the principles specified
in [RFC4193]. Using random chosen ULA addresses will provide in case in [RFC4193]. However, in case (a) the use of randomly chosen ULA
(a) suboptimal aggregation capabilities, while in case (c) a /48 ULA addresses will provide suboptimal aggregation capabilities.
address is larger then the less-than-/48 prefix and will hence result
in address space overconsumption.
ULAs provide the means to deploy a fixed addressing scheme that is ULAs provide the means to deploy a fixed addressing scheme that is
not affected by a change in service provider and the corresponding PA not affected by a change in service provider and the corresponding PA
global addresses. Internal operation of the network is thus global addresses. Internal operation of the network is thus
unaffected during renumbering events. Nevertheless, this type of unaffected during renumbering events. Nevertheless, this type of
address must be used with caution. address must be used with caution.
A site using ULAs may or may not also deploy global addresses. In an A site using ULAs may or may not also deploy global addresses. In an
isolated network ULAs may be deployed on their own. In a connected isolated network ULAs may be deployed on their own. In a connected
network, that also deploys global addresses, both may be deployed, network, that also deploys global addresses, both may be deployed,
skipping to change at page 9, line 35 skipping to change at page 9, line 33
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 [RFC4291]. In this document we allocation are specified in RFC4291 [RFC4291]. In this document we
analyze their practical implications. Based on RFC4291 [RFC4291] it analyze their practical implications. Based on RFC4291 [RFC4291] it
is legal for any IPv6 unicast address starting with binary address is legal for any IPv6 unicast address starting with binary address
'000' to have a subnet prefix larger than, smaller than or equal to '000' to have a subnet prefix larger than, smaller than or equal to
64 bits. Each of these three options is discussed in this document. 64 bits. Each of these three options is discussed in this document.
This document mainly considers global addresses (assigned from RIR/ This document mainly considers global addresses (assigned from RIR/
LIR) and ULAs and while neither of these address types starts with LIR) and ULAs and while neither of these address types starts with
binary "000" only /64 prefixes are allowed on these types of binary "000" only /64 prefixes are allowed on these types of
addresses. addresses, however note that a future revision of the address
architecture [RFC4291] and a future link-type-specific document,
which will still be consistent with each other, could potentially
allow for an interface identifier of length other than the value
defined in the current documents.
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 considered bad practice. One exception to this statement is when is considered bad practice. One exception to this statement is when
using 6to4 technology where a /16 prefix is utilized for the pseudo- using 6to4 technology where a /16 prefix is utilized for the pseudo-
interface [RFC3056]. The shortest subnet prefix that could interface [RFC3056]. The shortest subnet prefix that could
theoretically be assigned to an interface or node is limited by the theoretically be assigned to an interface or node is limited by the
size of the network prefix allocated to the organization. size of the network prefix allocated to the organization.
skipping to change at page 10, line 22 skipping to change at page 10, line 24
Based on RFC3177 [RFC3177], 64 bits is the prescribed subnet prefix Based on RFC3177 [RFC3177], 64 bits is the prescribed subnet prefix
length to allocate to interfaces and nodes. length to allocate to interfaces and nodes.
When using a /64 subnet length, the address assignment for these When using a /64 subnet length, the address assignment for these
addresses can be made either by manual configuration, by a stateful addresses can be made either by manual configuration, by a stateful
Host Configuration Protocol [RFC3315] [RFC3736] or by stateless Host Configuration Protocol [RFC3315] [RFC3736] or by stateless
autoconfiguration [RFC4862]. autoconfiguration [RFC4862].
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. However, implementations could use proprietary for 64 bit subnets. While in theory it might be possible that some
mechanism for stateless autoconfiguration with other than 64 bit future autoconfiguration mechanisms would allow longer than 64 bit
prefix length. prefix lengths to be used, the use of such prefixes is not
recommended at this time.
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, however this kind of address prefix length longer than 64 bits, however this kind of address
conservation is of little benefit compared with the additional conservation is of little benefit compared with the additional
considerations one must make when creating and maintain an IPv6 considerations one must make when creating and maintain an IPv6
address plan. address plan.
Using a subnet prefix length of longer then a /64 will break amongst Using a subnet prefix length of longer then a /64 will break amongst
other technologies for example Neighborship Discovery (ND), Secure other technologies for example Neighbor Discovery (ND), Secure
Neighborship Discovery (SeND) and privacy extensions (RFC4193) Neighborship Discovery (SeND) and privacy extensions (RFC4193). As a
result, the use of prefix lengths beyond /64 is not recommended for
general use.
The address assignment can be made either by manual configuration or The address assignment can be made either by manual configuration or
by a stateful Host Configuration Protocol [RFC3315]. by a stateful Host Configuration Protocol [RFC3315].
When assigning a subnet prefix of more then 70 bits, according to When assigning a subnet prefix of more then 70 bits, according to
RFC4291 [RFC4291] 'u' and 'g' bits (respectively the 71st and 72nd RFC4291 [RFC4291] 'u' and 'g' bits (respectively the 71st and 72nd
bit) need to be taken into consideration and should be set correct. bit) need to be taken into consideration and should be set correct.
The 'u' (universal/local) bit is the 71st bit of IPv6 address and is The 'u' (universal/local) bit is the 71st bit of IPv6 address and is
used to determine whether the address is universally or locally used to determine whether the address is universally or locally
skipping to change at page 15, line 40 skipping to change at page 15, line 49
5. IANA Considerations 5. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
6. Security Considerations 6. Security Considerations
This document doesn't add any new security considerations that aren't This document doesn't add any new security considerations that aren't
already outlined in the security considerations of the references. already outlined in the security considerations of the references.
It must be noted that using subnet prefixes other than /64 breaks
security mechanisms such as Cryptographically Generated Addresses
(CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible
to use protocols that depend on them.
7. Acknowledgements 7. Acknowledgements
Constructive feedback and contributions have been received during Constructive feedback and contributions have been received during
IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola, IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola,
John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian
Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny
Listman, Salman Assadullah and Krishnan Thirukonda. Listman, Salman Assadullah and Krishnan Thirukonda.
8. References 8. References
 End of changes. 15 change blocks. 
21 lines changed or deleted 31 lines changed or added

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