doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc7608.txt b/doc/rfc/rfc7608.txt
new file mode 100644
index 0000000..356fdaf
--- /dev/null
+++ b/doc/rfc/rfc7608.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Boucadair
+Request for Comments: 7608                                France Telecom
+BCP: 198                                                     A. Petrescu
+Category: Best Current Practice                                CEA, LIST
+ISSN: 2070-1721                                                 F. Baker
+                                                           Cisco Systems
+                                                               July 2015
+
+
+            IPv6 Prefix Length Recommendation for Forwarding
+
+Abstract
+
+   IPv6 prefix length, as in IPv4, is a parameter conveyed and used in
+   IPv6 routing and forwarding processes in accordance with the
+   Classless Inter-domain Routing (CIDR) architecture.  The length of an
+   IPv6 prefix may be any number from zero to 128, although subnets
+   using stateless address autoconfiguration (SLAAC) for address
+   allocation conventionally use a /64 prefix.  Hardware and software
+   implementations of routing and forwarding should therefore impose no
+   rules on prefix length, but implement longest-match-first on prefixes
+   of any valid length.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7608.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.         Best Current Practice                 [Page 1]
+
+RFC 7608                                                       July 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Recommendation  . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
+   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
+     4.2.  Informative References  . . . . . . . . . . . . . . . . .   4
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6
+
+1.  Introduction
+
+   Discussions on the 64-bit boundary in IPv6 addressing ([RFC7421])
+   revealed a need for a clear recommendation on which bits must be used
+   by forwarding decision-making processes.  However, such a
+   recommendation was out of scope for that document.
+
+   Although Section 2.5 of [RFC4291] states "IPv6 unicast addresses are
+   aggregatable with prefixes of arbitrary bit-length, similar to IPv4
+   addresses under Classless Inter-Domain Routing" (CIDR, [RFC4632]),
+   there is still a misinterpretation that IPv6 prefixes can be either
+   /127 ([RFC6164]) or any length up to /64.  This misinterpretation is
+   mainly induced by the 64-bit boundary in IPv6 addressing.
+
+   As discussed in [RFC7421], "the notion of a /64 boundary in the
+   address was introduced after the initial design of IPv6, following a
+   period when it was expected to be at /80".  This evolution of the
+   IPv6 addressing architecture, resulting in [RFC4291], and followed
+   with the addition of /127 prefixes for point-to-point links, clearly
+   demonstrates the intent for future IPv6 developments to have the
+   flexibility to change this part of the architecture when justified.
+
+
+
+Boucadair, et al.         Best Current Practice                 [Page 2]
+
+RFC 7608                                                       July 2015
+
+
+   It is fundamental not to link routing and forwarding to the IPv6
+   prefix/address semantics [RFC4291].  This document includes a
+   recommendation in order to support that goal.
+
+   Forwarding decisions rely on the longest-match-first algorithm, which
+   stipulates that, given a choice between two prefixes in the
+   Forwarding Information Base (FIB) of different length that match the
+   destination address in each bit up to their respective lengths, the
+   longer prefix is used.  This document's recommendation (Section 2) is
+   that IPv6 forwarding must follow the longest-match-first rule,
+   regardless of prefix length, unless some overriding policy is
+   configured.
+
+   This recommendation does not conflict with the 64-bit boundary for
+   some schemes that based on IPv6 stateless address autoconfiguration
+   (SLAAC) [RFC4862], such as [RFC2464].  Indeed, [RFC7421] clarifies
+   this is only a parameter in the SLAAC process, and other longer
+   prefix lengths are in operational use (e.g., either manually
+   configured or based upon DHCPv6 [RFC3315]).
+
+   A historical background of CIDR is documented in [RFC1380] and
+   Section 2 of [RFC4632].
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Recommendation
+
+   IPv6 implementations MUST conform to the rules specified in
+   Section 5.1 of [RFC4632].
+
+   Decision-making processes for forwarding MUST NOT restrict the length
+   of IPv6 prefixes by design.  In particular, forwarding processes MUST
+   be designed to process prefixes of any length up to /128, by
+   increments of 1.
+
+   Policies can be enforced to restrict the length of IP prefixes
+   advertised within a given domain or in a given interconnection link.
+   These policies are deployment specific and/or driven by
+   administrative (interconnection) considerations.
+
+
+
+
+
+
+
+
+Boucadair, et al.         Best Current Practice                 [Page 3]
+
+RFC 7608                                                       July 2015
+
+
+3.  Security Considerations
+
+   This document does not introduce security issues in addition to what
+   is discussed in [RFC4291].
+
+   IPv6 security issues, including operational ones, are discussed in
+   [RFC4942] and [OPSEC-v6].
+
+4.  References
+
+4.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [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>.
+
+   [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>.
+
+4.2.  Informative References
+
+   [OPSEC-v6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
+              Security Considerations for IPv6 Networks", Work in
+              Progress, draft-ietf-opsec-v6-06, March 2015.
+
+   [RFC1380]  Gross, P. and P. Almquist, "IESG Deliberations on Routing
+              and Addressing", RFC 1380, DOI 10.17487/RFC1380, November
+              1992, <http://www.rfc-editor.org/info/rfc1380>.
+
+   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
+              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
+              <http://www.rfc-editor.org/info/rfc2464>.
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
+              2003, <http://www.rfc-editor.org/info/rfc3315>.
+
+
+
+
+
+
+
+Boucadair, et al.         Best Current Practice                 [Page 4]
+
+RFC 7608                                                       July 2015
+
+
+   [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>.
+
+   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
+              Co-existence Security Considerations", RFC 4942,
+              DOI 10.17487/RFC4942, September 2007,
+              <http://www.rfc-editor.org/info/rfc4942>.
+
+   [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>.
+
+   [RFC7421]  Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
+              Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
+              Boundary in IPv6 Addressing", RFC 7421,
+              DOI 10.17487/RFC7421, January 2015,
+              <http://www.rfc-editor.org/info/rfc7421>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.         Best Current Practice                 [Page 5]
+
+RFC 7608                                                       July 2015
+
+
+Acknowledgements
+
+   Thanks to Eric Vyncke, Christian Jacquenet, Brian Carpenter, Fernando
+   Gont, Tatuya Jinmei, Lorenzo Colitti, Ross Chandler, David Farmer,
+   David Black, and Barry Leiba for their contributions and comments.
+
+   Special thanks to Randy Bush for his support.
+
+Authors' Addresses
+
+   Mohamed Boucadair
+   France Telecom
+   Rennes  35000
+   France
+
+   Email: mohamed.boucadair@orange.com
+
+
+   Alexandre Petrescu
+   CEA, LIST
+   CEA Saclay
+   Gif-sur-Yvette, Ile-de-France  91190
+   France
+
+   Phone: +33169089223
+   Email: alexandre.petrescu@cea.fr
+
+
+   Fred Baker
+   Cisco Systems
+   Santa Barbara, California  93117
+   United States
+
+   Email: fred@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.         Best Current Practice                 [Page 6]
+