draft-ietf-6man-why64-02.txt   draft-ietf-6man-why64-03.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: February 17, 2015 Univ. of Southampton Expires: February 28, 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
August 16, 2014 August 27, 2014
Analysis of the 64-bit Boundary in IPv6 Addressing Analysis of the 64-bit Boundary in IPv6 Addressing
draft-ietf-6man-why64-02 draft-ietf-6man-why64-03
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 February 17, 2015. This Internet-Draft will expire on February 28, 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 5, line 10 skipping to change at page 5, line 10
o Everything is the same. Compared to IPv4, there is no more o Everything is the same. Compared to IPv4, there is no more
calculating leaf subnet sizes, no more juggling between subnets, calculating leaf subnet sizes, no more juggling between subnets,
and fewer consequent errors. Network design is therefore simpler and fewer consequent errors. Network design is therefore simpler
and much more straightforward. This is of importance for all and much more straightforward. This is of importance for all
types of networks - enterprise, campus, small office, or home types of networks - enterprise, campus, small office, or home
networks - and for all types of operator, from professional to networks - and for all types of operator, from professional to
consumer. consumer.
o Adding a subnet is easy - just take another /64 from the pool. No o Adding a subnet is easy - just take another /64 from the pool. No
estimates, calculations, consideration or judgment is needed. estimates, calculations, consideration or judgement is needed.
o Router configurations are homogeneous and easier to understand. o Router configurations are homogeneous and easier to understand.
o Documentation is easier to write and easier to read; training is o Documentation is easier to write and easier to read; training is
easier. easier.
The remainder of this document describes arguments that have been The remainder of this document describes arguments that have been
made against the current fixed IID length and analyses the effects of made against the current fixed IID length and analyses the effects of
a possible change. However, the consensus of the IETF is that the a possible change. However, the consensus of the IETF is that the
benefits of keeping the length fixed at 64 bits, and the practical benefits of keeping the length fixed at 64 bits, and the practical
skipping to change at page 8, line 34 skipping to change at page 8, line 34
To a lesser extent, the address configuration RFCs themselves may in To a lesser extent, the address configuration RFCs themselves may in
some ways assume the 64-bit length of an Interface ID (e.g, SLAAC for some ways assume the 64-bit length of an Interface ID (e.g, SLAAC for
the link-local addresses, DHCPv6 for the potentially assigned EUI- the link-local addresses, DHCPv6 for the potentially assigned EUI-
64-based IP addresses, Optimistic Duplicate Address Detection 64-based IP addresses, Optimistic Duplicate Address Detection
[RFC4429] which computes 64-bit-based collision probabilities). [RFC4429] which computes 64-bit-based collision probabilities).
The MLDv1 [RFC2710] and MLDv2 [RFC3810] protocols mandate that all The MLDv1 [RFC2710] and MLDv2 [RFC3810] protocols mandate that all
queries be sent with a link-local source address, with the exception queries be sent with a link-local source address, with the exception
of MLD messages sent using the unspecified address when the link- of MLD messages sent using the unspecified address when the link-
local address is tentative [RFC3590]. At the the time of publication local address is tentative [RFC3590]. At the time of publication of
of RFC 2710, the IPv6 addressing architecture specified link-local RFC 2710, the IPv6 addressing architecture specified link-local
addresses with 64-bit interface identifiers. MLDv2 explicitly addresses with 64-bit interface identifiers. MLDv2 explicitly
specifies the use of the fe80::/64 link-local prefix, and bases the specifies the use of the fe80::/64 link-local prefix, and bases the
querier election algorithm on the link-local subnet prefix of length querier election algorithm on the link-local subnet prefix of length
/64. /64.
The IPv6 Flow Label Specification [RFC6437] gives an example of a The IPv6 Flow Label Specification [RFC6437] gives an example of a
20-bit hash function generation which relies on splitting an IPv6 20-bit hash function generation which relies on splitting an IPv6
address in two equally-sized 64bit-length parts. address in two equally-sized 64bit-length parts.
The basic transition mechanisms [RFC4213] refer to IIDs of length 64 The basic transition mechanisms [RFC4213] refer to IIDs of length 64
skipping to change at page 13, line 34 skipping to change at page 13, line 34
The results obtained can be summarized as follows: The results obtained can be summarized as follows:
o the "A" bit in the Prefix Information Options is honored only if o the "A" bit in the Prefix Information Options is honored only if
the prefix length is 64. At least for the case where the IID the prefix length is 64. At least for the case where the IID
length is defined to be 64 bits in the corresponding link-type- length is defined to be 64 bits in the corresponding link-type-
specific document, which is the case for all currently published specific document, which is the case for all currently published
such documents, this is consistent with [RFC4862], which defines such documents, this is consistent with [RFC4862], which defines
the case where the sum of the advertised prefix length and the IID the case where the sum of the advertised prefix length and the IID
length does not equal 128 as an error condition. length does not equal 128 as an error condition.
o the "L bit in the Prefix Information Options is honored for any o the "L" bit in the Prefix Information Options is honored for any
arbitrary prefix length (whether shorter or longer than /64). arbitrary prefix length (whether shorter or longer than /64).
o nodes that support the Route Information Option, allow such routes o nodes that support the Route Information Option, allow such routes
to be specified with prefixes of any arbitrary length (whether to be specified with prefixes of any arbitrary length (whether
shorter or longer than /64) shorter or longer than /64)
4.3.2. Other Observations 4.3.2. Other Observations
Participants in the V6OPS working group have indicated that some Participants in the V6OPS working group have indicated that some
forwarding devices have been shown to work correctly with long forwarding devices have been shown to work correctly with long
skipping to change at page 17, line 24 skipping to change at page 17, line 24
Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Jen Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Jen
Linkova, Philip Matthews, Matthew Petach, Scott Schmit, Tatuya Linkova, Philip Matthews, Matthew Petach, Scott Schmit, Tatuya
Jinmei, Fred Templin, Ole Troan, Stig Venaas, and numerous other Jinmei, Fred Templin, Ole Troan, Stig Venaas, and numerous other
participants in the 6MAN working group. An extremely detailed review participants in the 6MAN working group. An extremely detailed review
by Mark Smith was especially helpful. 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-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.
draft-ietf-6man-why64-00: WG adoption, WG comments, including major draft-ietf-6man-why64-00: WG adoption, WG comments, including major
text reorganisation: 3 main sections describe advantages of fixed text reorganisation: 3 main sections describe advantages of fixed
length IID, arguments for shorter lengths, and expected effects of length IID, arguments for shorter lengths, and expected effects of
varying the length, 2014-04-11. varying the length, 2014-04-11.
skipping to change at page 21, line 51 skipping to change at page 21, line 51
draft-ietf-6man-ipv6-address-generation-privacy-01 (work draft-ietf-6man-ipv6-address-generation-privacy-01 (work
in progress), February 2014. in progress), February 2014.
[I-D.ietf-homenet-arch] [I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"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.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-30 (work in progress), July 2014. draft-templin-aerolink-31 (work in progress), August 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. 9 change blocks. 
9 lines changed or deleted 11 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/