draft-ietf-6man-why64-05.txt   draft-ietf-6man-why64-06.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 20, 2015 Univ. of Southampton Expires: April 5, 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 16, 2014 October 2, 2014
Analysis of the 64-bit Boundary in IPv6 Addressing Analysis of the 64-bit Boundary in IPv6 Addressing
draft-ietf-6man-why64-05 draft-ietf-6man-why64-06
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 20, 2015. This Internet-Draft will expire on April 5, 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 2, line 43 skipping to change at page 2, line 43
4.3.1. Survey of the processing of Neighbor Discovery 4.3.1. Survey of the processing of Neighbor Discovery
options with prefixes other than /64 . . . . . . . . 11 options with prefixes other than /64 . . . . . . . . 11
4.3.2. Other Observations . . . . . . . . . . . . . . . . . 13 4.3.2. Other Observations . . . . . . . . . . . . . . . . . 13
4.4. Implementation and deployment issues . . . . . . . . . . 14 4.4. Implementation and deployment issues . . . . . . . . . . 14
4.5. Privacy issues . . . . . . . . . . . . . . . . . . . . . 15 4.5. Privacy issues . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 17 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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
skipping to change at page 7, line 25 skipping to change at page 7, line 25
One potential way to mitigate this attack would be to consider using One potential way to mitigate this attack would be to consider using
a /120 prefix, thus limiting the number of addresses in the subnet to a /120 prefix, thus limiting the number of addresses in the subnet to
be similar to an IPv4 /24 prefix, which should not cause any concerns be similar to an IPv4 /24 prefix, which should not cause any concerns
for ND cache exhaustion. Note that the prefix does need to be quite for ND cache exhaustion. Note that the prefix does need to be quite
long for this scenario to be valid. The number of theoretically long for this scenario to be valid. The number of theoretically
possible ND cache slots on the segment needs to be of the same order possible ND cache slots on the segment needs to be of the same order
of magnitude as the actual number of hosts. Thus small increases of magnitude as the actual number of hosts. Thus small increases
from the /64 prefix length do not have a noticeable impact: even 2^32 from the /64 prefix length do not have a noticeable impact: even 2^32
potential entries, a factor of two billion decrease compared to 2^64, potential entries, a factor of two billion decrease compared to 2^64,
is still more than enough to exhaust the memory on current routers. is still more than enough to exhaust the memory on current routers.
Given that SLAAC assumes a 64 bit network boundary, in such an Given that most link layer mappings cause SLAAC to assume a 64 bit
approach hosts would likely need to use DHCPv6, or be manually network boundary, in such an approach hosts would likely need to use
configured with addresses. DHCPv6, or be manually configured with addresses.
It should be noted that several other mitigations of the ND cache It should be noted that several other mitigations of the ND cache
attack are described in [RFC6583], and that limiting the size of the attack are described in [RFC6583], and that limiting the size of the
cache and the number of incomplete entries allowed would also defeat cache and the number of incomplete entries allowed would also defeat
the attack. For the specific case of a point-to-point link between the attack. For the specific case of a point-to-point link between
routers, this attack is indeed mitigated by a /127 prefix [RFC6164]. routers, this attack is indeed mitigated by a /127 prefix [RFC6164].
4. Effects of varying the interface identifier length 4. Effects of varying the interface identifier length
This section of the document analyses the impact and effects of This section of the document analyses the impact and effects of
skipping to change at page 8, line 26 skipping to change at page 8, line 26
the Stateless Autoconfiguration. These documents include [RFC2464] the Stateless Autoconfiguration. These documents include [RFC2464]
(Ethernet), [RFC2467] (FDDI), [RFC2470] (Token Ring), [RFC2492] (Ethernet), [RFC2467] (FDDI), [RFC2470] (Token Ring), [RFC2492]
(ATM), [RFC2497] (ARCnet), [RFC2590] (Frame Relay), [RFC3146] (IEEE (ATM), [RFC2497] (ARCnet), [RFC2590] (Frame Relay), [RFC3146] (IEEE
1394), [RFC4338] (Fibre Channel), [RFC4944] (IEEE 802.15.4), 1394), [RFC4338] (Fibre Channel), [RFC4944] (IEEE 802.15.4),
[RFC5072] (PPP), [RFC5121] [RFC5692] (IEEE 802.16), [RFC2529] [RFC5072] (PPP), [RFC5121] [RFC5692] (IEEE 802.16), [RFC2529]
(6over4), [RFC5214] (ISATAP), [I-D.templin-aerolink] (AERO), (6over4), [RFC5214] (ISATAP), [I-D.templin-aerolink] (AERO),
[I-D.ietf-6lowpan-btle], [I-D.ietf-6man-6lobac], [I-D.ietf-6lowpan-btle], [I-D.ietf-6man-6lobac],
[I-D.brandt-6man-lowpanz]. [I-D.brandt-6man-lowpanz].
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, RFC 4862
the link-local addresses, DHCPv6 for the potentially assigned EUI- for the link-local addresses, DHCPv6 for the potentially assigned
64-based IP addresses, Optimistic Duplicate Address Detection EUI-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 time of publication of local address is tentative [RFC3590]. At the time of publication 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
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, 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-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.
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
skipping to change at page 22, line 12 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-35 (work in progress), September draft-templin-aerolink-40 (work in progress), September
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. 9 change blocks. 
12 lines changed or deleted 14 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/