added the txt file to make it easy for non git users
This commit is contained in:
parent
0579dd3b0b
commit
8419897c5a
1 changed files with 280 additions and 0 deletions
280
draft-nbourbaki-6man-classless-ipv6.txt
Normal file
280
draft-nbourbaki-6man-classless-ipv6.txt
Normal file
|
|
@ -0,0 +1,280 @@
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Network Working Group N. Bourbaki
|
||||||
|
Internet-Draft The Intertubes
|
||||||
|
Intended status: Standards Track April 17, 2017
|
||||||
|
Expires: October 19, 2017
|
||||||
|
|
||||||
|
|
||||||
|
IPv6 is Classless
|
||||||
|
draft-bourbaki-6man-classless-ipv6-00
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
Over the history of IPv6, various classful address models have been
|
||||||
|
proposed, particularly Top-Level Aggregation (TLA) and Next-Level
|
||||||
|
Aggregation(NLA) Identifiers. They have all proved to be mistakes.
|
||||||
|
The last remnant is a rigid boundary at /64. This document removes
|
||||||
|
that rigidity as far as routing is 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 October 19, 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
|
||||||
|
the Trust Legal Provisions and are provided without warranty as
|
||||||
|
described in the Simplified BSD License.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Bourbaki Expires October 19, 2017 [Page 1]
|
||||||
|
|
||||||
|
Internet-Draft IPv6 is Classless April 2017
|
||||||
|
|
||||||
|
|
||||||
|
Table of Contents
|
||||||
|
|
||||||
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||||||
|
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2
|
||||||
|
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||||
|
4. A simple Statement . . . . . . . . . . . . . . . . . . . . . 3
|
||||||
|
5. Notes and Recommendations . . . . . . . . . . . . . . . . . . 3
|
||||||
|
6. Security Considerations . . . . . . . . . . . . . . . . . . . 3
|
||||||
|
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
|
||||||
|
8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||||
|
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||||
|
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||||
|
10.1. Normative References . . . . . . . . . . . . . . . . . . 4
|
||||||
|
10.2. Informative References . . . . . . . . . . . . . . . . . 4
|
||||||
|
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||||
|
|
||||||
|
1. Introduction
|
||||||
|
|
||||||
|
Over the history of IPv6, various classful address models have been
|
||||||
|
proposed, particularly Top-Level Aggregation (TLA) and Next-Level
|
||||||
|
Aggregation(NLA) Identifiers. They have all proved to be mistakes.
|
||||||
|
For example, TLA and NLA were obsoleted by [RFC3587]. The last
|
||||||
|
remnant is a rigid boundary at /64. This document removes that
|
||||||
|
rigidity as far as routing is concerned.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
It is also assumed that the reader understands IPv6, [RFC2460], IP
|
||||||
|
Version 6 Addressing Architecture, see [RFC4291], and the proposed
|
||||||
|
changes to [RFC4291], see [I-D.hinden-6man-rfc2464bis].
|
||||||
|
|
||||||
|
NOTE: do we mean 4291bis (currently moribund) or 2464bis?
|
||||||
|
|
||||||
|
An important recent development in IPv6 is that for host computers on
|
||||||
|
local area networks, the way in which interface identifiers are
|
||||||
|
formed is no longer bound to layer 2 addresses (MAC addresses)
|
||||||
|
[RFC7217]. We can therefore appreciate that their length, previously
|
||||||
|
fixed at 64 bits [RFC7136], is in fact a free parameter as stated in
|
||||||
|
[RFC4862].
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Bourbaki Expires October 19, 2017 [Page 2]
|
||||||
|
|
||||||
|
Internet-Draft IPv6 is Classless April 2017
|
||||||
|
|
||||||
|
|
||||||
|
3. Background
|
||||||
|
|
||||||
|
Some confusion has been caused by the IP Version 6 Addressing
|
||||||
|
Architecture, [RFC4291], and the proposed changes in
|
||||||
|
[I-D.hinden-6man-rfc2464bis] with respect to allowed maximum prefix
|
||||||
|
lengths and the minimum host part (sometimes known as interface
|
||||||
|
identifier) on a link.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
4. A simple Statement
|
||||||
|
|
||||||
|
To state it simply, IPv6 unicast routing 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 [RFC4862],
|
||||||
|
or Using 127-Bit IPv6 Prefixes on Inter-Router Links [RFC6164] is in
|
||||||
|
use.
|
||||||
|
|
||||||
|
5. Notes and Recommendations
|
||||||
|
|
||||||
|
For historical reasons, when a prefix is needed on a link, barring
|
||||||
|
other considerations, a /64 is traditional [RFC7136].
|
||||||
|
|
||||||
|
The length of the prefix identifier in Stateless Address
|
||||||
|
AutoConfiguration, [RFC4862] is a parameter; its length needs to 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-bits 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 length of prefix, with the value being
|
||||||
|
parameterised per interface.
|
||||||
|
|
||||||
|
NOTE: should we comment on the fact that at least Linux and Windows
|
||||||
|
seem to assume that the default prefix is /64 in the management CLI?
|
||||||
|
|
||||||
|
6. Security Considerations
|
||||||
|
|
||||||
|
This document has no known security impact, assuming that user
|
||||||
|
devices use an unpredictable interface identifier [RFC7721] for
|
||||||
|
privacy.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Bourbaki Expires October 19, 2017 [Page 3]
|
||||||
|
|
||||||
|
Internet-Draft IPv6 is Classless April 2017
|
||||||
|
|
||||||
|
|
||||||
|
7. IANA Considerations
|
||||||
|
|
||||||
|
This document has no IANA Considerations.
|
||||||
|
|
||||||
|
8. Authors
|
||||||
|
|
||||||
|
The original draft was by Randy Bush, who was immediately aided and
|
||||||
|
abetted by Brian Carpenter, Job Snijders, [ your name here ].
|
||||||
|
|
||||||
|
9. Acknowledgments
|
||||||
|
|
||||||
|
The authors wish to thank .
|
||||||
|
|
||||||
|
10. References
|
||||||
|
|
||||||
|
10.1. Normative References
|
||||||
|
|
||||||
|
[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.
|
||||||
|
|
||||||
|
10.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.
|
||||||
|
|
||||||
|
[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>.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Bourbaki Expires October 19, 2017 [Page 4]
|
||||||
|
|
||||||
|
Internet-Draft IPv6 is Classless April 2017
|
||||||
|
|
||||||
|
|
||||||
|
[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>.
|
||||||
|
|
||||||
|
[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 October 19, 2017 [Page 5]
|
||||||
Loading…
Add table
Add a link
Reference in a new issue