draft-ietf-v6ops-addcon-09.txt   draft-ietf-v6ops-addcon-10.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: February 9, 2009 T. Chown Expires: March 26, 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
August 8, 2008 September 22, 2008
IPv6 Unicast Address Assignment Considerations IPv6 Unicast Address Assignment Considerations
<draft-ietf-v6ops-addcon-09.txt> <draft-ietf-v6ops-addcon-10.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 February 9, 2009. This Internet-Draft will expire on March 26, 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 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Network Level Addressing Design Considerations . . . . . . . . 5 2. Network Level Addressing Design Considerations . . . . . . . . 5
2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 5 2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 5
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5
2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 7 2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 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
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 /64 Prefixes . . . . . . . . . . . . . 10
3.2. Considerations for /64 Prefixes . . . . . . . . . . . . . 10 3.2. Allocation of the IID of an IPv6 Address . . . . . . . . . 10
3.3. Considerations for Subnet Prefixes Longer then /64 . . . . 10 3.2.1. Automatic EUI-64 Format Option . . . . . . . . . . . . 11
3.3.1. Anycast Addresses . . . . . . . . . . . . . . . . . . 11 3.2.2. Using Privacy Extensions . . . . . . . . . . . . . . . 11
3.3.2. Addresses Used by Embedded-RP (RFC3956) . . . . . . . 12 3.2.3. Manual/Dynamic Assignment Option . . . . . . . . . . . 11
3.3.3. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 13 3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 12
3.3.4. /126 Addresses . . . . . . . . . . . . . . . . . . . . 14 3.4. Security Considerations . . . . . . . . . . . . . . . . . 12
3.3.5. /127 Addresses . . . . . . . . . . . . . . . . . . . . 14 3.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12
3.3.6. /128 Addresses . . . . . . . . . . . . . . . . . . . . 14 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 14 4.1. Normative References . . . . . . . . . . . . . . . . . . . 12
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 14 4.2. Informative References . . . . . . . . . . . . . . . . . . 12
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 15 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 15
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 15 A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 A.1.2. Forming an Address (subnet) Allocation Plan . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.1.4. Node Configuration Considerations . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 A.2. Service Provider Considerations . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 19
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 19
A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 19
A.1.2. Forming an Address (subnet) Allocation Plan . . . . . 20
A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 21
A.1.4. Node Configuration Considerations . . . . . . . . . . 21
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 . . . . 19
A.2.2. Exemplary IPv6 Address Allocation Plan for a A.2.2. Exemplary IPv6 Address Allocation Plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 26 Service Provider . . . . . . . . . . . . . . . . . . . 22
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 30 A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 26
Appendix B. Considerations for Subnet Prefixes Different then
/64 . . . . . . . . . . . . . . . . . . . . . . . . . 29
B.1. Considerations for Subnet Prefixes Shorter then /64 . . . 29
B.2. Considerations for Subnet Prefixes Longer then /64 . . . . 29
B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 29
B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 29
B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 29
B.2.4. EUI-64 'u' and 'g' bits . . . . . . . . . . . . . . . 30
B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 31
B.2.6. Addresses Used by Embedded-RP (RFC3956) . . . . . . . 32
B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35 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
skipping to change at page 9, line 23 skipping to change at page 9, line 23
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 Host-Density (HD) [RFC3194] value for IPv6 is 0.94 The proposed Host-Density (HD) [RFC3194] value for IPv6 is 0.94
compared to the current value of 0.96 for IPv4. Note that for IPv6 compared to the current value of 0.96 for IPv4. Note that for IPv6
HD is calculated for sites (e.g. on a basis of /48), instead of based HD is calculated for sites (e.g. on a basis of /48), instead of based
on addresses like with IPv4. on addresses like with IPv4.
3. Subnet Prefix Considerations 3. Subnet Prefix Considerations
This section analyzes the considerations applied to define the subnet An important part of an IPv4 addressing plan is deciding the length
prefix of the IPv6 addresses. The boundaries of the subnet prefix of each subnet prefix. Unlike in IPv4, the IPv6 addressing
allocation are specified in RFC4291 [RFC4291]. In this document we architecture [RFC4291] specifies that all subnets using Globally
analyze their practical implications. Based on RFC4291 [RFC4291] it Unique Addresses and ULAs always have the same prefix length of 64
is legal for any IPv6 unicast address starting with binary address bits. (This applies also to the deprecated 6Bone and Site Local
'000' to have a subnet prefix larger than, smaller than or equal to addresses.)
64 bits. Each of these three options is discussed in this document.
This document mainly considers global addresses (assigned from RIR/
LIR) and ULAs and while neither of these address types starts with
binary "000" only /64 prefixes are allowed on these types of
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 The only exception to this rule are special addresses starting with
the binary value 000, such as IPv4-Compatible IPv6 Addresses. These
exceptions are largely beyond the scope of this document.
An allocation of a prefix shorter then 64 bits to a node or interface Using a subnet prefix length other than a /64 will break many
is considered bad practice. One exception to this statement is when features of IPv6, amongst other things Neighbor Discovery (ND),
using 6to4 technology where a /16 prefix is utilized for the pseudo- Secure Neighborship Discovery (SEND) [RFC3971], privacy extensions
interface [RFC3056]. The shortest subnet prefix that could [RFC4941], parts of Mobile IPv6 [RFC4866], PIM-SM with Embedded-RP
theoretically be assigned to an interface or node is limited by the [RFC3956], and SHIM6 [SHIM6]. A number of other features currently
size of the network prefix allocated to the organization. in development, or being proposed, also rely on /64 subnet prefixes.
A possible reason for choosing the subnet prefix for an interface Nevertheless, many IPv6 implementations do not prevent the
shorter then /64 is that it would allow more nodes to be attached to administrator from configuring a subnet prefix length shorter or
that interface compared to a prescribed length of 64 bits. This longer than 64 bits. Using subnet prefixes shorter than /64 would
however is unnecessary for most networks considering that 2^64 rarely be useful; see Appendix B.1 for discussion.
provides plenty of node addresses.
The subnet prefix assignments can be made either by manual However, some network administrators have used prefixes longer than
configuration, by a stateful Host Configuration Protocol [RFC3315], /64 for links connecting routers, usually just two routers on a
by a stateful prefix delegation mechanism [RFC3633] or implied by point-to-point link. On links where all the addresses are assigned
stateless autoconfiguration from prefix RAs. by manual configuration, and all nodes on the link are routers (not
end hosts) that are known by the network administrators do not need
any of the IPv6 features that rely on /64 subnet prefixes, this can
work. Using subnet prefixes longer than /64 are not recommended for
general use, and using them for links containing end hosts would be
an especially bad idea, as it is difficult to predict what IPv6
features the hosts will use in the future.
3.2. Considerations for /64 Prefixes Appendix B.2 describes some practical considerations that need to be
taken into account when using prefixes longer than /64 in limited
cases. In particular, a number of IPv6 features use interface
identifiers that have a special form (such as a certain fixed value
in some bit positions). When using prefixes longer than /64, it is
prudent to avoid certain subnet prefix values so that nodes who
assume that the prefix is /64 will not incorrectly identify the
addresses in that subnet as having a special form. Appendix B.2
describes the subnet prefix values that are currently believed to be
potentially problematic; however, the list is not exhaustive and can
be expected to grow in the future.
Using /64 subnets is strongly recommended, also for links connecting
only routers. A deployment compliant with the current IPv6
specifications cannot use other prefix lengths. However, the V6OPS
WG believes that despite the drawbacks (and a potentially expensive
network redesign, if IPv6 features relying on /64 subnets are needed
in the future), that some networks administrators will use prefixes
longer than /64.
3.1. Considerations for /64 Prefixes
Based on RFC3177 [RFC3177], 64 bits is the prescribed subnet prefix Based on RFC3177 [RFC3177], 64 bits is the prescribed subnet prefix
length to allocate to interfaces and nodes. length to allocate to interfaces and nodes.
When using a /64 subnet length, the address assignment for these When using a /64 subnet length, the address assignment for these
addresses can be made either by manual configuration, by a stateful addresses can be made either by manual configuration, by a 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. While in theory it might be possible that some for 64 bit subnets. While in theory it might be possible that some
future autoconfiguration mechanisms would allow longer than 64 bit future autoconfiguration mechanisms would allow longer than 64 bit
prefix lengths to be used, the use of such prefixes is not prefix lengths to be used, the use of such prefixes is not
recommended at this time. recommended at this time.
3.3. Considerations for Subnet Prefixes Longer then /64 3.2. Allocation of the IID of an IPv6 Address
Address space conservation is the main motivation for using a subnet
prefix length longer than 64 bits, however this kind of address
conservation is of little benefit compared with the additional
considerations one must make when creating and maintain an IPv6
address plan.
Using a subnet prefix length of longer then a /64 will break amongst
other technologies for example Neighbor Discovery (ND), Secure
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
by a stateful Host Configuration Protocol [RFC3315].
When assigning a subnet prefix of more then 70 bits, according to
RFC4291 [RFC4291] 'u' and 'g' bits (respectively the 71st and 72nd
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
used to determine whether the address is universally or locally
administered. If 0, the IEEE, through the designation of a unique
company ID, has administered the address. If 1, the address is
locally administered. The network administrator has overridden the
manufactured address and specified a different address.
The 'g' (the individual/group) bit is the 72st bit and is used to
determine whether the address is an individual address (unicast) or a
group address (multicast). If '0', the address is a unicast address.
If '1', the address is a multicast address.
In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bit
is marginal and typically will not show an issue when configured
wrongly, however future implementations may turn out differently if
they would be processing the 'u' and 'g' bit in IEEE like behavior.
When using subnet lengths longer then 64 bits, it is important to
avoid selecting addresses that may have a predefined use and could
confuse IPv6 protocol stacks. The alternate usage may not be a
simple unicast address in all cases. The following points should be
considered when selecting a subnet length longer then 64 bits.
3.3.1. Anycast Addresses
3.3.1.1. Subnet Router Anycast Address
RFC4291 [RFC4291] provides a definition for the required Subnet
Router Anycast Address as follows:
| n bits | 128-n bits |
+--------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+--------------------------------------------+----------------+
It is recommended to avoid allocating this IPv6 address to a device
which expects to have a normal unicast address. There is no
additional dependency for the subnet prefix with the exception of the
64-bit extended unique identifier (EUI-64) and an Interface
Identifier (IID) dependency. These will be discussed later in this
document.
3.3.1.2. Reserved IPv6 Subnet Anycast Addresses
RFC2526 [RFC2526] stated that within each subnet, the highest 128
interface identifier values are reserved for assignment as subnet
anycast addresses.
The construction of a reserved subnet anycast address depends on the
type of IPv6 addresses used within the subnet, as indicated by the
format prefix in the addresses.
The first type of Subnet Anycast addresses have been defined as
follows for EUI-64 format:
| 64 bits | 57 bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+------------------------------+------------------+------------+
The anycast address structure implies that it is important to avoid
creating a subnet prefix where the bits 65 to 121 are defined as
"1111110111...111" (57 bits in total) so that confusion can be
avoided.
For other IPv6 address types (that is, with format prefixes other
than those listed above), the interface identifier is not in 64-bit
extended unique identifier (EUI-64) format and may be other than 64
bits in length; these reserved subnet anycast addresses for such
address types are constructed as follows:
| n bits | 121-n bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+------------------------------+------------------+------------+
| interface identifier field |
It is recommended to avoid allocating this IPv6 address to a device
which expects to have a normal unicast address. There is no
additional dependency for the subnet prefix with the exception of the
EUI-64 and an Interface Identifier (IID) dependency. These will be
discussed later in this document.
3.3.2. Addresses Used by Embedded-RP (RFC3956)
Embedded-RP [RFC3956] reflects the concept of integrating the
Rendezvous Point (RP) IPv6 address into the IPv6 multicast group
address. Due to this embedding and the fact that the length of the
IPv6 address AND the IPv6 multicast address are 128 bits, it is not
possible to have the complete IPv6 address of the multicast RP
embedded as such.
This resulted in a restriction of 15 possible RP-addresses per prefix
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
the Interface ID (RIID) is set to all '0'.
(IPv6-prefix (64 bits))(60 bits all '0')(RIID)
Where: (RIID) = 4 bit.
This format implies that when selecting subnet prefixes longer then
64, and the bits beyond the 64th one are non-zero, the subnet can not
use embedded-RP.
In addition it is discouraged to assign a matching embedded-RP IPv6
address to a device that is not a real Multicast Rendezvous Point,
even though it would not generate major problems.
3.3.3. ISATAP Addresses
ISATAP [RFC5214] is an experimental automatic tunneling protocol used
to provide IPv6 connectivity over an IPv4 campus or enterprise
environment. In order to leverage the underlying IPv4
infrastructure, the IPv6 addresses are constructed in a special
format.
An IPv6 ISATAP address has the IPv4 address embedded, based on a
predefined structure policy that identifies them as an ISATAP
address.
[IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]
When using subnet prefix length longer then 64 bits it is good
engineering practice that the portion of the IPv6 prefix from bit 65
to the end of the host-id does not match with the well-known ISATAP
[0000:5EFE] address when assigning an IPv6 address to a non-ISATAP
interface.
Note that the definition of ISATAP does not support multicast.
3.3.4. /126 Addresses
126 bit subnet prefixes are typically used for point-to-point links
similar to a the IPv4 address conservative /30 allocation for point-
to-point links. The usage of this subnet address length does not
lead to any additional considerations other than the ones discussed
earlier in this section, particularly those related to the "u" and
"g" bits.
3.3.5. /127 Addresses
The usage of the /127 addresses, the equivalent of IPv4's RFC3021
[RFC3021] is not valid and should be strongly discouraged as
documented in RFC3627 [RFC3627].
3.3.6. /128 Addresses
The 128 bit address prefix may be used in those situations where we
know that one, and only one address is sufficient. Example usage
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
"g" bits into consideration and to make sure that there is no overlap
with either the following well-known addresses:
o Subnet Router Anycast Address
o Reserved Subnet Anycast Address
o Addresses used by Embedded-RP
o ISATAP Addresses
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
section discusses the elements that should be considered when section discusses the elements that should be considered when
assigning the IID portion of the IPv6 address. assigning the IID portion of the IPv6 address.
There are various ways to allocate an IPv6 address to a device or There are various ways to allocate an IPv6 address to a device or
interface. The option with the least amount of caveats for the interface. The option with the least amount of caveats for the
network administrator is that of EUI-64 [RFC4862] based addresses. network administrator is that of EUI-64 [RFC4862] based addresses.
For the manual or dynamic options, the overlap with well known IPv6 For the manual or dynamic options, the overlap with well known IPv6
addresses should be avoided. addresses should be avoided.
4.1. Automatic EUI-64 Format Option 3.2.1. Automatic EUI-64 Format Option
When using this method the network administrator has to allocate a When using this method the network administrator has to allocate a
valid 64 bit subnet prefix. The EUI-64 [RFC4862] allocation valid 64 bit subnet prefix. The EUI-64 [RFC4862] allocation
procedure can from that moment onward assign the remaining 64 IID procedure can from that moment onward assign the remaining 64 IID
bits in a stateless manner. All the considerations for selecting a bits in a stateless manner. All the considerations for selecting a
valid IID have been incorporated in the EUI-64 methodology. valid IID have been incorporated in the EUI-64 methodology.
4.2. Using Privacy Extensions 3.2.2. Using Privacy Extensions
The main purpose of IIDs generated based on RFC4941 [RFC4941] is to The main purpose of IIDs generated based on RFC4941 [RFC4941] is to
provide privacy to the entity using this address. While there are no provide privacy to the entity using this address. While there are no
particular constraints in the usage of these addresses as defined in particular constraints in the usage of these addresses as defined in
[RFC4941] there are some implications to be aware of when using [RFC4941] there are some implications to be aware of when using
privacy addresses as documented in section 4 of RFC4941 [RFC4941] privacy addresses as documented in section 4 of RFC4941 [RFC4941]
4.3. Manual/Dynamic Assignment Option 3.2.3. Manual/Dynamic Assignment Option
This section discusses those IID allocations that are not implemented This section discusses those IID allocations that are not implemented
through stateless address configuration (Section 4.1). They are through stateless address configuration (Section 4.1). They are
applicable regardless of the prefix length used on the link. It is applicable regardless of the prefix length used on the link. It is
out of scope for this section to discuss the various assignment out of scope for this section to discuss the various assignment
methods (e.g. manual configuration, DHCPv6, etc). methods (e.g. manual configuration, DHCPv6, etc).
In this situation the actual allocation is done by human intervention In this situation the actual allocation is done by human 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 (Appendix B.2.5.1.)
o Reserved Subnet Anycast Address o Reserved Subnet Anycast Address (Appendix B.2.5.2.)
o Addresses used by Embedded-RP o Addresses used by Embedded-RP (Appendix B.2.6.)
o ISATAP Addresses o ISATAP Addresses (Appendix B.2.7.)
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 obvious 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. IANA Considerations 3.3. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
6. Security Considerations 3.4. Security Considerations
This document doesn't add any new security considerations that aren't This document doesn't add any new security considerations that aren't
already outlined in the security considerations of the references. already outlined in the security considerations of the references.
It must be noted that using subnet prefixes other than /64 breaks It must be noted that using subnet prefixes other than /64 breaks
security mechanisms such as Cryptographically Generated Addresses security mechanisms such as Cryptographically Generated Addresses
(CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible
to use protocols that depend on them. to use protocols that depend on them.
7. Acknowledgements 3.5. 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, Krishnan Thirukonda and the IESG.
8. References 4. References
8.1. Normative References 4.1. Normative References
8.2. Informative References 4.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999. Addresses", RFC 2526, March 1999.
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links", "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
skipping to change at page 17, line 37 skipping to change at page 13, line 46
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005. Multihoming Solutions", RFC 4218, October 2005.
skipping to change at page 18, line 19 skipping to change at page 14, line 31
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.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798, February 2007. Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008. March 2008.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008. RFC 5157, March 2008.
[SHIM6] IETF,
"http://www.ietf.org/html.charters/shim6-charter.html".
[ARIN] ARIN, "http://www.arin.net/policy/nrpm.html#six54". [ARIN] ARIN, "http://www.arin.net/policy/nrpm.html#six54".
[reference2] [reference2]
APNIC, ARIN, RIPE NCC, "www.ripe.net/ripe/docs/ APNIC, ARIN, RIPE NCC, "www.ripe.net/ripe/docs/
ipv6policy.html", July 2007. ipv6policy.html", July 2007.
[reference3] [reference3]
APNIC, ARIN, RIPE NCC, APNIC, ARIN, RIPE NCC,
"http://www.ripe.net/ripe/docs/ripe-412.html", July 2007. "http://www.ripe.net/ripe/docs/ripe-412.html", July 2007.
skipping to change at page 33, line 5 skipping to change at page 29, line 5
A.2.3.6. Extensions Needed for the Later IPv6 Migration Phases A.2.3.6. Extensions Needed for the Later IPv6 Migration Phases
The proposed IPv6 addressing schema for a SP needs some slight The proposed IPv6 addressing schema for 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 and an infrastructure (LDP, IGP etc.) is realized over IPv6 transport and an
IPv6 addressing of the LSRs is needed. Other changes may be IPv6 addressing of the LSRs is needed. Other changes may be
necessary as well but should not be explained at this point. necessary as well but should not be explained at this point.
Appendix B. Considerations for Subnet Prefixes Different then /64
B.1. Considerations for Subnet Prefixes Shorter then /64
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
using 6to4 technology where a /16 prefix is utilized for the pseudo-
interface [RFC3056]. The shortest subnet prefix that could
theoretically be assigned to an interface or node is limited by the
size of the network prefix allocated to the organization.
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
that interface compared to a prescribed length of 64 bits. This
however is unnecessary for most networks considering that 2^64
provides plenty of node addresses.
The subnet prefix assignments can be made either by manual
configuration, by a stateful Host Configuration Protocol [RFC3315],
by a stateful prefix delegation mechanism [RFC3633] or implied by
stateless autoconfiguration from prefix RAs.
B.2. Considerations for Subnet Prefixes Longer then /64
The following subsections describe subnet prefix values that should
be avoided in deployments, because nodes who assume that the subnet
prefix is /64 could treat them incorrectly.
B.2.1. /126 Addresses
126 bit subnet prefixes are typically used for point-to-point links
similar to a the IPv4 address conservative /30 allocation for point-
to-point links. The usage of this subnet address length does not
lead to any additional considerations other than the ones discussed
earlier in this section, particularly those related to the "u" and
"g" bits.
B.2.2. /127 Addresses
The usage of the /127 addresses, the equivalent of IPv4's RFC3021
[RFC3021] is not valid and should be strongly discouraged as
documented in RFC3627 [RFC3627].
B.2.3. /128 Addresses
The 128 bit address prefix may be used in those situations where we
know that one, and only one address is sufficient. Example usage
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
"g" bits into consideration and to make sure that there is no overlap
with either the following well-known addresses:
o Subnet Router Anycast Address
o Reserved Subnet Anycast Address
o Addresses used by Embedded-RP
o ISATAP Addresses
B.2.4. EUI-64 'u' and 'g' bits
When using subnet prefix lengths other than /64, the interface
identifier cannot be in Modified EUI-64 format as required by
[RFC4291]. However, nodes not aware that a prefix length other than
/64 is used might still think it's an EUI-64; therefore, it's prudent
to take the next considerations to set the bits into account.
Address space conservation is the main motivation for using a subnet
prefix length longer than 64 bits, however this kind of address
conservation is of little benefit compared with the additional
considerations one must make when creating and maintain an IPv6
address plan.
The address assignment can be made either by manual configuration or
by a stateful Host Configuration Protocol [RFC3315].
When assigning a subnet prefix of more then 70 bits, according to
RFC4291 [RFC4291] 'u' and 'g' bits (respectively the 71st and 72nd
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
used to determine whether the address is universally or locally
administered. If 0, the IEEE, through the designation of a unique
company ID, has administered the address. If 1, the address is
locally administered. The network administrator has overridden the
manufactured address and specified a different address.
The 'g' (the individual/group) bit is the 72st bit and is used to
determine whether the address is an individual address (unicast) or a
group address (multicast). If '0', the address is a unicast address.
If '1', the address is a multicast address.
In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bit
is marginal and typically will not show an issue when configured
wrongly, however future implementations may turn out differently if
they would be processing the 'u' and 'g' bit in IEEE like behavior.
When using subnet lengths longer then 64 bits, it is important to
avoid selecting addresses that may have a predefined use and could
confuse IPv6 protocol stacks. The alternate usage may not be a
simple unicast address in all cases. The following points should be
considered when selecting a subnet length longer then 64 bits.
B.2.5. Anycast Addresses
B.2.5.1. Subnet Router Anycast Address
RFC4291 [RFC4291] provides a definition for the required Subnet
Router Anycast Address as follows:
| n bits | 128-n bits |
+--------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+--------------------------------------------+----------------+
It is recommended to avoid allocating this IPv6 address to a device
which expects to have a normal unicast address. There is no
additional dependency for the subnet prefix with the exception of the
64-bit extended unique identifier (EUI-64) and an Interface
Identifier (IID) dependency. These will be discussed later in this
document.
B.2.5.2. Reserved IPv6 Subnet Anycast Addresses
RFC2526 [RFC2526] stated that within each subnet, the highest 128
interface identifier values are reserved for assignment as subnet
anycast addresses.
The construction of a reserved subnet anycast address depends on the
type of IPv6 addresses used within the subnet, as indicated by the
format prefix in the addresses.
The first type of Subnet Anycast addresses have been defined as
follows for EUI-64 format:
| 64 bits | 57 bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+------------------------------+------------------+------------+
The anycast address structure implies that it is important to avoid
creating a subnet prefix where the bits 65 to 121 are defined as
"1111110111...111" (57 bits in total) so that confusion can be
avoided.
For other IPv6 address types (that is, with format prefixes other
than those listed above), the interface identifier is not in 64-bit
extended unique identifier (EUI-64) format and may be other than 64
bits in length; these reserved subnet anycast addresses for such
address types are constructed as follows:
| n bits | 121-n bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+------------------------------+------------------+------------+
| interface identifier field |
It is recommended to avoid allocating this IPv6 address to a device
which expects to have a normal unicast address. There is no
additional dependency for the subnet prefix with the exception of the
EUI-64 and an Interface Identifier (IID) dependency. These will be
discussed later in this document.
B.2.6. Addresses Used by Embedded-RP (RFC3956)
Embedded-RP [RFC3956] reflects the concept of integrating the
Rendezvous Point (RP) IPv6 address into the IPv6 multicast group
address. Due to this embedding and the fact that the length of the
IPv6 address AND the IPv6 multicast address are 128 bits, it is not
possible to have the complete IPv6 address of the multicast RP
embedded as such.
This resulted in a restriction of 15 possible RP-addresses per prefix
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
the Interface ID (RIID) is set to all '0'.
(IPv6-prefix (64 bits))(60 bits all '0')(RIID)
Where: (RIID) = 4 bit.
This format implies that when selecting subnet prefixes longer then
64, and the bits beyond the 64th one are non-zero, the subnet can not
use embedded-RP.
In addition it is discouraged to assign a matching embedded-RP IPv6
address to a device that is not a real Multicast Rendezvous Point,
even though it would not generate major problems.
B.2.7. ISATAP Addresses
ISATAP [RFC5214] is an experimental automatic tunneling protocol used
to provide IPv6 connectivity over an IPv4 campus or enterprise
environment. In order to leverage the underlying IPv4
infrastructure, the IPv6 addresses are constructed in a special
format.
An IPv6 ISATAP address has the IPv4 address embedded, based on a
predefined structure policy that identifies them as an ISATAP
address.
[IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]
When using subnet prefix length longer then 64 bits it is good
engineering practice that the portion of the IPv6 prefix from bit 65
to the end of the host-id does not match with the well-known ISATAP
[0000:5EFE] address when assigning an IPv6 address to a non-ISATAP
interface.
Note that the definition of ISATAP does not support multicast.
Authors' Addresses Authors' Addresses
Gunter Van de Velde Gunter Van de Velde
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2704 5473 Phone: +32 2704 5473
Email: gunter@cisco.com Email: gunter@cisco.com
 End of changes. 29 change blocks. 
261 lines changed or deleted 319 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/