draft-ietf-6man-why64-07.txt   draft-ietf-6man-why64-08.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: April 23, 2015 Univ. of Southampton Expires: May 4, 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
October 20, 2014 October 31, 2014
Analysis of the 64-bit Boundary in IPv6 Addressing Analysis of the 64-bit Boundary in IPv6 Addressing
draft-ietf-6man-why64-07 draft-ietf-6man-why64-08
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 April 23, 2015. This Internet-Draft will expire on May 4, 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 7 skipping to change at page 3, line 7
1. Introduction 1. Introduction
Rather than simply overcoming the IPv4 address shortage by doubling Rather than simply overcoming the IPv4 address shortage by doubling
the address size to 64 bits, IPv6 addresses were originally chosen to the address size to 64 bits, IPv6 addresses were originally chosen to
be 128 bits long to provide flexibility and new possibilities. In be 128 bits long to provide flexibility and new possibilities. In
particular, the notion of a well-defined interface identifier was particular, the notion of a well-defined interface identifier was
added to the IP addressing model. The IPv6 addressing architecture added to the IP addressing model. The IPv6 addressing architecture
[RFC4291] specifies that a unicast address is divided into n bits of [RFC4291] specifies that a unicast address is divided into n bits of
subnet prefix followed by (128-n) bits of interface identifier (IID). subnet prefix followed by (128-n) bits of interface identifier (IID).
The bits in the IID have no meaning and the entire identifier should The bits in the IID may have significance only in the process of
deriving the IID and once it is derived the entire identifier should
be treated as an opaque value [RFC7136]. Also, since IPv6 routing is be treated as an opaque value [RFC7136]. Also, since IPv6 routing is
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
skipping to change at page 9, line 48 skipping to change at page 9, line 48
be considered "magic" in some RFCs, e.g., 64k limits in DNS and be considered "magic" in some RFCs, e.g., 64k limits in DNS and
Base64 encodings in MIME. None of this has any influence on the Base64 encodings in MIME. None of this has any influence on the
length of the IID, but might confuse a careless reader. length of the IID, but might confuse a careless reader.
4.2. Possible failure modes 4.2. Possible failure modes
This section discusses several specific aspects of IPv6 where we can This section discusses several specific aspects of IPv6 where we can
expect operational failures with subnet prefixes other than /64. expect operational failures with subnet prefixes other than /64.
o Router implementations: Router implementors might interpret IETF o Router implementations: Router implementors might interpret IETF
standards such as [RFC6164] and [RFC7136] to indicate that specifications such as [RFC6164] and [RFC7136] to indicate that
prefixes between /65 and /126 inclusive for unicast packets on- prefixes between /65 and /126 inclusive for unicast packets on-
the-wire are invalid, and operational practices that utilize the-wire are invalid, and operational practices that utilize
prefix lengths in this range may fail on some devices, as prefix lengths in this range may fail on some devices, as
discussed in Section 4.3.2. discussed in Section 4.3.2.
o Multicast: [RFC3306] defines a method for generating IPv6 o Multicast: [RFC3306] defines a method for generating IPv6
multicast group addresses based on unicast prefixes. This method multicast group addresses based on unicast prefixes. This method
assumes a longest prefix of 64 bits. If a longer prefix is used, assumes a longest prefix of 64 bits. If a longer prefix is used,
there is no way to generate a specific multicast group address there is no way to generate a specific multicast group address
using this method. In such cases the administrator would need to using this method. In such cases the administrator would need to
skipping to change at page 17, line 46 skipping to change at page 17, line 46
Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter,
Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach, Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach,
Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas, Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas,
and numerous other participants in the 6MAN working group. An and numerous other participants in the 6MAN working group. An
extremely detailed review 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-08: IESG comments, 2014-10-31.
draft-ietf-6man-why64-07: correction to Linux NOT-SUP status, draft-ietf-6man-why64-07: correction to Linux NOT-SUP status,
2014-10-20. 2014-10-20.
draft-ietf-6man-why64-06: minor IETF Last Call comments, 2014-10-02. draft-ietf-6man-why64-06: minor IETF Last Call comments, 2014-10-02.
draft-ietf-6man-why64-05: Area Director review comments, 2014-09-16. 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.
skipping to change at page 22, line 39 skipping to change at page 22, line 39
"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-44 (work in progress), October draft-templin-aerolink-46 (work in progress), October
2014. 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
 End of changes. 8 change blocks. 
7 lines changed or deleted 10 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/