392 lines
14 KiB
Text
392 lines
14 KiB
Text
|
||
|
||
|
||
|
||
6man N. Bourbaki
|
||
Internet-Draft The Intertubes
|
||
Updates: 4291 (if approved) July 17, 2017
|
||
Intended status: Standards Track
|
||
Expires: January 18, 2018
|
||
|
||
|
||
IPv6 is Classless
|
||
draft-bourbaki-6man-classless-ipv6-01
|
||
|
||
Abstract
|
||
|
||
Over the history of IPv6, various classful address models have been
|
||
proposed, none of which has withstood the test of time. The last
|
||
remnant of IPv6 classful addressing is a rigid network interface
|
||
identifier boundary at /64. This document removes the fixed position
|
||
of that boundary for interface addressing.
|
||
|
||
Status of This Memo
|
||
|
||
This Internet-Draft is submitted in full conformance with the
|
||
provisions of BCP 78 and BCP 79.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF). Note that other groups may also distribute
|
||
working documents as Internet-Drafts. The list of current Internet-
|
||
Drafts is at http://datatracker.ietf.org/drafts/current/.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
This Internet-Draft will expire on January 18, 2018.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2017 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(http://trustee.ietf.org/license-info) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with respect
|
||
to this document. Code Components extracted from this document must
|
||
include Simplified BSD License text as described in Section 4.e of
|
||
|
||
|
||
|
||
|
||
Bourbaki Expires January 18, 2018 [Page 1]
|
||
|
||
Internet-Draft IPv6 is Classless July 2017
|
||
|
||
|
||
the Trust Legal Provisions and are provided without warranty as
|
||
described in the Simplified BSD License.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2
|
||
3. Problem reinforced by classful addressing . . . . . . . . . . 3
|
||
4. Identifier and Subnet Length Statements . . . . . . . . . . . 4
|
||
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
|
||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
|
||
8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
|
||
9.2. Informative References . . . . . . . . . . . . . . . . . 5
|
||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
|
||
1. Introduction
|
||
|
||
Over the history of the IPv6 protocol, several classful addressing
|
||
models have been proposed. The most notable example recommended Top-
|
||
Level Aggregation (TLA) and Next-Level Aggregation (NLA) Identifiers
|
||
[RFC2450], but was obsoleted by [RFC3587], leaving a single remnant
|
||
of classful addressing in IPv6: a rigid network interface identifier
|
||
boundary at /64. This document removes the fixed position of that
|
||
boundary for interface addressing.
|
||
|
||
Recent proposed changes to the IP Version 6 Addressing Architecture
|
||
specification [RFC4291] have caused controversy. While link prefixes
|
||
of varied lengths, e.g. /127, /126, /124, /120, ... /64 have been
|
||
successfully deployed for many years, glaring mismatches between a
|
||
formal specification and long-standing field deployment practices are
|
||
never wise, not least because of the strong risk of mis-
|
||
implementation, which can easily result in serious operational
|
||
problems.
|
||
|
||
This document also clarifies that IPv6 routing subnets may be of any
|
||
length up to 128.
|
||
|
||
2. Suggested Reading
|
||
|
||
It is assumed that the reader understands the history of classful
|
||
addressing in IPv4 and why it was abolished [RFC4632]. Of course,
|
||
the acute need to conserve address space that forced the adoption of
|
||
classless addressing for IPv4 does not apply to IPv6, but the
|
||
arguments for operational flexibility in address assignment remain
|
||
compelling.
|
||
|
||
|
||
|
||
Bourbaki Expires January 18, 2018 [Page 2]
|
||
|
||
Internet-Draft IPv6 is Classless July 2017
|
||
|
||
|
||
It is also assumed that the reader understands IPv6 [RFC2460], the IP
|
||
Version 6 Addressing Architecture [RFC4291], the proposed changes to
|
||
RFC4291 [I-D.ietf-6man-rfc4291bis] and RFC2464
|
||
[I-D.hinden-6man-rfc2464bis], [RFC7608] an IPv6 Prefix Length
|
||
Recommendation for Forwarding, and the IETF recommendation for the
|
||
generation of stable Interface Identifiers [RFC8064].
|
||
|
||
[I-D.jinmei-6man-prefix-clarify] is also worth reading to clarify
|
||
uses of varying prefix lengths on a single link.
|
||
|
||
For host computers on local area networks, generation of interface
|
||
identifiers is no longer necessarily bound to layer 2 addresses
|
||
(MACs) [RFC7217] [RFC8064]. Therefore their length, previously fixed
|
||
at 64 bits [RFC7136], is in fact a variably-sized parameter as
|
||
explicitly acknowledged in Section 5.5.3(d) of [RFC4862] which
|
||
states:
|
||
|
||
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. Thus, an implementation should not assume a
|
||
particular constant. Rather, it should expect any lengths of
|
||
interface identifiers.
|
||
|
||
3. Problem reinforced by classful addressing
|
||
|
||
As IPv6 usage has evolved and grown over in recent years, it has
|
||
become evident that it faces several scaling and coordination
|
||
problems. These problems are analogous to allocation and
|
||
coordination problems that motivated IPv4 CIDR allocation and later
|
||
abundant IPv4 PAT, they include:
|
||
|
||
Address allocation models for specific counts of fixed length
|
||
subnets to downstream networks or devices from /48 down to /64 are
|
||
based on our imagination of how subnets are or should be allocated
|
||
within ipv4 networks.
|
||
Hierarchical allocation of fixed-length subnets requires
|
||
coordination between lower / intermediate / upper network elements
|
||
and has implict assumption that policies and size allocation at
|
||
the top of the hierarchy will accomidate all use cases with fixed
|
||
lenth subnet allocation.
|
||
Coordination with upstream network elements for the allocation of
|
||
fixed length subnets reveals topology and intent that may be
|
||
private in scope and which amounts to permission to build a
|
||
particular topology.
|
||
|
||
|
||
|
||
|
||
|
||
Bourbaki Expires January 18, 2018 [Page 3]
|
||
|
||
Internet-Draft IPv6 is Classless July 2017
|
||
|
||
|
||
4. Identifier and Subnet Length Statements
|
||
|
||
IPv6 unicast interfaces may use any subnet length up to 128 except
|
||
for situations where an Internet Standard document may impose a
|
||
particular length, for example Stateless Address Autoconfiguration
|
||
(SLAAC) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router
|
||
Links [RFC6164].
|
||
|
||
Additionally, this document clarifies that a node or router MUST
|
||
support routing of any valid network prefix length, even if SLAAC or
|
||
other standards are in use, because routing could choose to
|
||
differentiate at a different granularity than is used by any such
|
||
automated link local address configuration tools.
|
||
|
||
5. Recommendations
|
||
|
||
For historical reasons, when a prefix is needed on a link, barring
|
||
other considerations, a /64 is recommended [RFC7136].
|
||
|
||
The length of the Interface Identifier in Stateless Address
|
||
Autoconfiguration [RFC4862] is a parameter; its length SHOULD be
|
||
sufficient for effective randomization for privacy reasons. For
|
||
example, a /48 might be sufficient. But operationally we recommend,
|
||
barring strong considerations to the contrary, using 64-bits for
|
||
SLAAC in order not to discover bugs where 64 was hard-coded, and to
|
||
favor portability of devices and operating systems.
|
||
|
||
Nonetheless, there is no reason in theory why an IPv6 node should not
|
||
operate with different interface identfier lengths on different
|
||
physical interfaces. Thus, a correct implementation of SLAAC must in
|
||
fact allow for any prefix length, with the value being a parameter
|
||
per interface. For instance, the Interface Identifier length in the
|
||
recommended (see [RFC8064]) algorithm for selecting stable interface
|
||
identifiers [RFC7217] is a parameter, rather than a hardcoded value.
|
||
|
||
6. Security Considerations
|
||
|
||
Assuming that nodes employ unpredictable interface identifiers
|
||
[RFC7721], the subnet size may have an impact on some security and
|
||
privacy properties of a network. Namely, the smaller the subnet
|
||
size, the more feasible it becomes to perform IPv6 address scans
|
||
[RFC7707] [RFC7721]. For some specific subnets, such as point to
|
||
point links, this may be less of an issue.
|
||
|
||
On the other hand, we assume that a number of IPv6 implementations
|
||
fail to enforce limits on the size of some of the data structures
|
||
they employ for communicating with neighboring nodes, such as the
|
||
Neighbor Cache. In such cases, the use of smaller subnets forces an
|
||
|
||
|
||
|
||
Bourbaki Expires January 18, 2018 [Page 4]
|
||
|
||
Internet-Draft IPv6 is Classless July 2017
|
||
|
||
|
||
operational limit on such data structures, thus helping mitigate some
|
||
pathological behaviors (such as Neighbor Cache Exhaustion attacks).
|
||
|
||
7. IANA Considerations
|
||
|
||
This document has no IANA Considerations.
|
||
|
||
8. Authors
|
||
|
||
The authors of this document are as follows:
|
||
|
||
Randy Bush, Internet Initiative Japan
|
||
Brian Carpenter, University of Auckland
|
||
Fernando Gont, SI6 Networks / UTN-FRH
|
||
Nick Hilliard, INEX
|
||
Geoff Huston, APNIC
|
||
Chris Morrow, Google, Inc.
|
||
Job Snijders, NTT Communications
|
||
|
||
9. References
|
||
|
||
9.1. Normative References
|
||
|
||
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
||
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
|
||
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
|
||
|
||
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
|
||
2006, <http://www.rfc-editor.org/info/rfc4291>.
|
||
|
||
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
|
||
Interface Identifiers with IPv6 Stateless Address
|
||
Autoconfiguration (SLAAC)", RFC 7217,
|
||
DOI 10.17487/RFC7217, April 2014,
|
||
<http://www.rfc-editor.org/info/rfc7217>.
|
||
|
||
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
|
||
"Recommendation on Stable IPv6 Interface Identifiers",
|
||
RFC 8064, DOI 10.17487/RFC8064, February 2017,
|
||
<http://www.rfc-editor.org/info/rfc8064>.
|
||
|
||
9.2. Informative References
|
||
|
||
[I-D.hinden-6man-rfc2464bis]
|
||
Crawford, M. and R. Hinden, "Transmission of IPv6 Packets
|
||
over Ethernet Networks", draft-hinden-6man-rfc2464bis-02
|
||
(work in progress), March 2017.
|
||
|
||
|
||
|
||
Bourbaki Expires January 18, 2018 [Page 5]
|
||
|
||
Internet-Draft IPv6 is Classless July 2017
|
||
|
||
|
||
[I-D.ietf-6man-rfc4291bis]
|
||
Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||
Architecture", draft-ietf-6man-rfc4291bis-09 (work in
|
||
progress), July 2017.
|
||
|
||
[I-D.jinmei-6man-prefix-clarify]
|
||
Jinmei, T., "Clarifications on On-link and Subnet IPv6
|
||
Prefixes", draft-jinmei-6man-prefix-clarify-00 (work in
|
||
progress), March 2017.
|
||
|
||
[RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule",
|
||
RFC 2450, DOI 10.17487/RFC2450, December 1998,
|
||
<http://www.rfc-editor.org/info/rfc2450>.
|
||
|
||
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
|
||
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
|
||
August 2003, <http://www.rfc-editor.org/info/rfc3587>.
|
||
|
||
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
|
||
(CIDR): The Internet Address Assignment and Aggregation
|
||
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
|
||
2006, <http://www.rfc-editor.org/info/rfc4632>.
|
||
|
||
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
|
||
Address Autoconfiguration", RFC 4862,
|
||
DOI 10.17487/RFC4862, September 2007,
|
||
<http://www.rfc-editor.org/info/rfc4862>.
|
||
|
||
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
|
||
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
|
||
Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
|
||
<http://www.rfc-editor.org/info/rfc6164>.
|
||
|
||
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
|
||
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
|
||
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
|
||
|
||
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
|
||
Length Recommendation for Forwarding", BCP 198, RFC 7608,
|
||
DOI 10.17487/RFC7608, July 2015,
|
||
<http://www.rfc-editor.org/info/rfc7608>.
|
||
|
||
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
|
||
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
|
||
<http://www.rfc-editor.org/info/rfc7707>.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Bourbaki Expires January 18, 2018 [Page 6]
|
||
|
||
Internet-Draft IPv6 is Classless July 2017
|
||
|
||
|
||
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
|
||
Considerations for IPv6 Address Generation Mechanisms",
|
||
RFC 7721, DOI 10.17487/RFC7721, March 2016,
|
||
<http://www.rfc-editor.org/info/rfc7721>.
|
||
|
||
Author's Address
|
||
|
||
Nicolas Bourbaki
|
||
The Intertubes
|
||
42 Rue du Jour
|
||
Sophia-Antipolis ::1
|
||
FR
|
||
|
||
Email: bourbaki@bogus.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Bourbaki Expires January 18, 2018 [Page 7]
|