draft-ietf-6man-why64-04.txt   draft-ietf-6man-why64-05.txt 
6MAN B. Carpenter, Ed. 6MAN B. Carpenter, Ed.
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational T. Chown Intended status: Informational T. Chown
Expires: March 14, 2015 Univ. of Southampton Expires: March 20, 2015 Univ. of Southampton
F. Gont F. Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
A. Petrescu A. Petrescu
CEA, LIST CEA, LIST
A. Yourtchenko A. Yourtchenko
cisco cisco
September 10, 2014 September 16, 2014
Analysis of the 64-bit Boundary in IPv6 Addressing Analysis of the 64-bit Boundary in IPv6 Addressing
draft-ietf-6man-why64-04 draft-ietf-6man-why64-05
Abstract Abstract
The IPv6 unicast addressing format includes a separation between the The IPv6 unicast addressing format includes a separation between the
prefix used to route packets to a subnet and the interface identifier prefix used to route packets to a subnet and the interface identifier
used to specify a given interface connected to that subnet. used to specify a given interface connected to that subnet.
Currently the interface identifier is defined as 64 bits long for Currently the interface identifier is defined as 64 bits long for
almost every case, leaving 64 bits for the subnet prefix. This almost every case, leaving 64 bits for the subnet prefix. This
document describes the advantages of this fixed boundary and analyses document describes the advantages of this fixed boundary and analyses
the issues that would be involved in treating it as a variable the issues that would be involved in treating it as a variable
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 14, 2015. This Internet-Draft will expire on March 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 19
entirely based on variable length prefixes (also known as variable entirely based on variable length prefixes (also known as variable
length subnet masks), there is no basic architectural assumption that length subnet masks), there is no basic architectural assumption that
n has any particular fixed value. All IPv6 routing protocols support n has any particular fixed value. All IPv6 routing protocols support
prefixes of any length up to /128. prefixes of any length up to /128.
The IID is of basic importance in the IPv6 stateless address The IID is of basic importance in the IPv6 stateless address
autoconfiguration (SLAAC) process [RFC4862]. However, it is autoconfiguration (SLAAC) process [RFC4862]. However, it is
important to understand that its length is a parameter in the SLAAC important to understand that its length is a parameter in the SLAAC
process, and it is determined in a separate link-type specific process, and it is determined in a separate link-type specific
document (see Section 2 of RFC 4862). The SLAAC protocol does not document (see Section 2 of RFC 4862). The SLAAC protocol does not
define its length or assume any particular length. define its length or assume any particular length. Similarly, DHCPv6
[RFC3315] does not include a prefix length in its address assignment.
The notion of a /64 boundary in the address was introduced after the The notion of a /64 boundary in the address was introduced after the
initial design of IPv6, following a period when it was expected to be initial design of IPv6, following a period when it was expected to be
at /80. There were two motivations for setting it at /64. One was at /80. There were two motivations for setting it at /64. One was
the original "8+8" proposal [DRAFT-odell] that eventually led to ILNP the original "8+8" proposal [DRAFT-odell] that eventually led to ILNP
[RFC6741], which required a fixed point for the split between local [RFC6741], which required a fixed point for the split between local
and wide-area parts of the address. The other was the expectation and wide-area parts of the address. The other was the expectation
that EUI-64 MAC addresses would become widespread in place of 48-bit that EUI-64 MAC addresses would become widespread in place of 48-bit
addresses, coupled with the plan at that time that auto-configured addresses, coupled with the plan at that time that auto-configured
addresses would normally be based on interface identifiers derived addresses would normally be based on interface identifiers derived
skipping to change at page 5, line 40 skipping to change at page 5, line 40
A site may not be delegated a sufficiently generous prefix from which A site may not be delegated a sufficiently generous prefix from which
to allocate a /64 prefix to all of its internal subnets. In this to allocate a /64 prefix to all of its internal subnets. In this
case the site may either determine that it does not have enough case the site may either determine that it does not have enough
address space to number all its network elements and thus, at the address space to number all its network elements and thus, at the
very best, be only partially operational, or it may choose to use very best, be only partially operational, or it may choose to use
internal prefixes longer than /64 to allow multiple subnets and the internal prefixes longer than /64 to allow multiple subnets and the
hosts within them to be configured with addresses. hosts within them to be configured with addresses.
In this case, the site might choose, for example, to use a /80 per In this case, the site might choose, for example, to use a /80 per
subnet, in combination with hosts using either manually configured subnet, in combination with hosts using either manually configured
addressing or DHCPv6. addressing or DHCPv6 [RFC3315].
Scenarios that have been suggested where an insufficient prefix might Scenarios that have been suggested where an insufficient prefix might
be delegated include home or small office networks, vehicles, be delegated include home or small office networks, vehicles,
building services and transportation services (road signs, etc.). It building services and transportation services (road signs, etc.). It
should be noted that the homenet architecture text should be noted that the homenet architecture text
[I-D.ietf-homenet-arch] states that a CPE should consider the lack of [I-D.ietf-homenet-arch] states that a CPE should consider the lack of
sufficient address space to be an error condition, rather than using sufficient address space to be an error condition, rather than using
prefixes longer than /64 internally. prefixes longer than /64 internally.
Another scenario occasionally suggested is one where the Internet Another scenario occasionally suggested is one where the Internet
skipping to change at page 6, line 15 skipping to change at page 6, line 15
in accordance with [RFC6177]. It is sometimes suggested that in accordance with [RFC6177]. It is sometimes suggested that
assigning a prefix such as /48 or /56 to every user site (including assigning a prefix such as /48 or /56 to every user site (including
the smallest) as recommended by [RFC6177] is wasteful. In fact, the the smallest) as recommended by [RFC6177] is wasteful. In fact, the
currently released unicast address space, 2000::/3, contains 35 currently released unicast address space, 2000::/3, contains 35
trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a
small fraction have been allocated. Allowing for a conservative small fraction have been allocated. Allowing for a conservative
estimate of allocation efficiency, i.e., an HD-ratio of 0.94 estimate of allocation efficiency, i.e., an HD-ratio of 0.94
[RFC4692], approximately 5 trillion /48 prefixes can be allocated. [RFC4692], approximately 5 trillion /48 prefixes can be allocated.
Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 Even with a relaxed HD-ratio of 0.89, approximately one trillion /48
prefixes can be allocated. Furthermore, with only 2000::/3 currently prefixes can be allocated. Furthermore, with only 2000::/3 currently
committed for unicast addressing, we still have almost 7/8ths of the committed for unicast addressing, we still have approximately 85% of
address space in reserve. Thus there is no objective risk of prefix the address space in reserve. Thus there is no objective risk of
depletion by assigning /48 or /56 prefixes even to the smallest prefix depletion by assigning /48 or /56 prefixes even to the
sites. smallest sites.
3.2. Hierarchical addressing 3.2. Hierarchical addressing
Some operators have argued that more prefix bits are needed to allow Some operators have argued that more prefix bits are needed to allow
an aggregated hierarchical addressing scheme within a campus or an aggregated hierarchical addressing scheme within a campus or
corporate network. However, if a campus or enterprise gets a /48 corporate network. However, if a campus or enterprise gets a /48
prefix (or shorter), then that already provides 16 bits for prefix (or shorter), then that already provides 16 bits for
hierarchical allocation. In any case, flat IGP routing is widely and hierarchical allocation. In any case, flat IGP routing is widely and
successfully used within rather large networks, with hundreds of successfully used within rather large networks, with hundreds of
routers and thousands of end systems. Therefore there is no routers and thousands of end systems. Therefore there is no
skipping to change at page 17, line 14 skipping to change at page 17, line 14
6. IANA Considerations 6. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
7. Acknowledgements 7. Acknowledgements
This document was inspired by a vigorous discussion on the V6OPS This document was inspired by a vigorous discussion on the V6OPS
working group mailing list with at least 20 participants. Later, working group mailing list with at least 20 participants. Later,
valuable comments were received from Ran Atkinson, Fred Baker, Steven valuable comments were received from Ran Atkinson, Fred Baker, Steven
Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Jen Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter,
Linkova, Philip Matthews, Matthew Petach, Scott Schmit, Tatuya Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach,
Jinmei, Fred Templin, Ole Troan, Stig Venaas, and numerous other Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas,
participants in the 6MAN working group. An extremely detailed review and numerous other participants in the 6MAN working group. An
by Mark Smith was especially helpful. extremely detailed review by Mark Smith was especially helpful.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
8. Change log [RFC Editor: Please remove] 8. Change log [RFC Editor: Please remove]
draft-ietf-6man-why64-05: Area Director review comments, 2014-09-16.
draft-ietf-6man-why64-04: fixed reference error, 2014-09-10. draft-ietf-6man-why64-04: fixed reference error, 2014-09-10.
draft-ietf-6man-why64-03: fixed nits, 2014-08-27. draft-ietf-6man-why64-03: fixed nits, 2014-08-27.
draft-ietf-6man-why64-02: responded to WGLC reviews and comments, draft-ietf-6man-why64-02: responded to WGLC reviews and comments,
2014-08-16. 2014-08-16.
draft-ietf-6man-why64-01: language improvements, added TCAM draft-ietf-6man-why64-01: language improvements, added TCAM
reference, 2014-05-07. reference, 2014-05-07.
skipping to change at page 18, line 38 skipping to change at page 18, line 41
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", RFC 3146, October 2001. over IEEE 1394 Networks", RFC 3146, October 2001.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast [RFC3590] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September Listener Discovery (MLD) Protocol", RFC 3590, September
2003. 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 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", RFC Point (RP) Address in an IPv6 Multicast Address", RFC
3956, November 2004. 3956, November 2004.
skipping to change at page 22, line 7 skipping to change at page 22, line 12
"IPv6 Home Networking Architecture Principles", draft- "IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-17 (work in progress), July 2014. ietf-homenet-arch-17 (work in progress), July 2014.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in
progress), June 2014. progress), June 2014.
[I-D.templin-aerolink] [I-D.templin-aerolink]
Templin, F., "Transmission of IP Packets over AERO Links", Templin, F., "Transmission of IP Packets over AERO Links",
draft-templin-aerolink-32 (work in progress), August 2014. draft-templin-aerolink-35 (work in progress), September
2014.
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802-2001 Networks: Overview and Architecture", IEEE Std 802-2001
(R2007), 2007. (R2007), 2007.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May Discovery (ND) Trust Models and Threats", RFC 3756, May
 End of changes. 11 change blocks. 
16 lines changed or deleted 24 lines changed or added

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