draft-classless6/draft-nbourbaki-6man-classless-ipv6.txt
2017-05-09 19:29:41 +02:00

280 lines
11 KiB
Text
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Network Working Group N. Bourbaki
Internet-Draft The Intertubes
Intended status: Standards Track May 9, 2017
Expires: November 10, 2017
IPv6 is Classless
draft-bourbaki-6man-classless-ipv6-00
Abstract
Over the history of IPv6, various classful address models have been
proposed, with the most notable being Top-Level Aggregation (TLA) and
Next-Level Aggregation (NLA) Identifiers. They have all proved to be
mistakes. The last remnant of classful addressing is a rigid network
/ interface identifier boundary at /64. This document removes that
boundary as far as routing and addressing are concerned.
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 November 10, 2017.
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 November 10, 2017 [Page 1]
Internet-Draft IPv6 is Classless May 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. A simple Statement . . . . . . . . . . . . . . . . . . . . . 3
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
9.1. Normative References . . . . . . . . . . . . . . . . . . 4
9.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Over the history of IPv6, various classful address models have been
proposed, with the most notable being Top-Level Aggregation (TLA) and
Next-Level Aggregation (NLA) Identifiers; see, for example,
[RFC2450]. They have all proved to be mistakes. For example, TLA
and NLA were obsoleted by [RFC3587]. The last remnant of classful
addressing is a rigid network / interface identifier boundary at /64.
This document removes that boundary as far as routing and addressing
are concerned.
Some confusion has been caused by the IP Version 6 Addressing
Architecture, [RFC4291], and the proposed changes in
[I-D.hinden-6man-rfc4291bis] with respect to the minimum subnet size.
Meanwhile, link prefixes of varied lengths, /127, /126, /124, /120,
... /64 have been successfully deployed for many years. Having the
formal specification be unclear risks potential mis-implementation by
the naive, which could result in operational disasters.
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 allocation remain
compelling.
Bourbaki Expires November 10, 2017 [Page 2]
Internet-Draft IPv6 is Classless May 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.hinden-6man-rfc4291bis], and the recent recommendations
for the generation of stable Interface Identifiers [RFC8064].
An important recent IPv6 development was that, for host computers on
local area networks, the way in which interface identifiers were
formed was no longer 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 stated in
[RFC4862].
3. A simple Statement
To state it simply, IPv6 unicast subnetting is based on prefixes of
any valid length up to 128 except for links where an Internet
Standard such as, for example, Stateless Address AutoConfiguration
(SLAAC) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router
Links [RFC6164] is in use.
Nodes must always support routing on 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.
4. 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.
None the less, 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.
Bourbaki Expires November 10, 2017 [Page 3]
Internet-Draft IPv6 is Classless May 2017
5. Security Considerations
Assumming 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
operational limit on such data structures, thus helping mitigate some
pathological behaviors (such as Neighbor Cache Exhaustion attacks).
6. IANA Considerations
This document has no IANA Considerations.
7. Authors
The original draft was by Randy Bush, who was immediately aided and
abetted by Brian Carpenter, Chris Morrow, Fernando Gont, Geoff
Huston, Job Snijders, [ your name here ].
8. Acknowledgments
The authors wish to thank .
9. References
9.1. Normative References
[RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rules",
RFC 2450, December 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[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>.
Bourbaki Expires November 10, 2017 [Page 4]
Internet-Draft IPv6 is Classless May 2017
[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-rfc4291bis]
Hinden, B. and S. Deering, "IP Version 6 Addressing
Architecture", draft-hinden-6man-rfc4291bis-06 (work in
progress), October 2015.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[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, April 2011.
[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>.
[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>.
[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 November 10, 2017 [Page 5]