doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc6164.txt b/doc/rfc/rfc6164.txt
new file mode 100644
index 0000000..f60c6a6
--- /dev/null
+++ b/doc/rfc/rfc6164.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          M. Kohno
+Request for Comments: 6164             Juniper Networks, Keio University
+Category: Standards Track                                      B. Nitzan
+ISSN: 2070-1721                                         Juniper Networks
+                                                                 R. Bush
+                                                            Y. Matsuzaki
+                                               Internet Initiative Japan
+                                                              L. Colitti
+                                                                  Google
+                                                               T. Narten
+                                                         IBM Corporation
+                                                              April 2011
+
+
+           Using 127-Bit IPv6 Prefixes on Inter-Router Links
+
+Abstract
+
+   On inter-router point-to-point links, it is useful, for security and
+   other reasons, to use 127-bit IPv6 prefixes.  Such a practice
+   parallels the use of 31-bit prefixes in IPv4.  This document
+   specifies the motivation for, and usages of, 127-bit IPv6 prefix
+   lengths on inter-router point-to-point links.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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
+   Internet Standards 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/rfc6164.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kohno, et al.                Standards Track                    [Page 1]
+
+RFC 6164                   IPv6 prefixlen p2p                 April 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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
+   2. Scope of This Memo ..............................................3
+   3. Conventions Used in This Document ...............................3
+   4. Problems Identified with 127-Bit Prefix Lengths in the Past .....3
+   5. Reasons for Using Longer Prefixes ...............................4
+      5.1. Ping-Pong Issue ............................................4
+      5.2. Neighbor Cache Exhaustion Issue ............................4
+      5.3. Other Reasons ..............................................5
+   6. Recommendations .................................................5
+   7. Security Considerations .........................................6
+   8. Contributors ....................................................6
+   9. Acknowledgments .................................................6
+   10. References .....................................................6
+      10.1. Normative References ......................................6
+      10.2. Informative References ....................................7
+
+1.  Introduction
+
+   [RFC4291] specifies that interface IDs for all unicast addresses,
+   except those that start with the binary value 000, are required to be
+   64 bits long and to be constructed in Modified EUI-64 format.  In
+   addition, it defines the Subnet-Router anycast address, which is
+   intended to be used for applications where a node needs to
+   communicate with any one of the set of routers on a link.
+
+   Some operators have been using 127-bit prefixes, but this has been
+   discouraged due to conflicts with Subnet-Router anycast [RFC3627].
+   However, using 64-bit prefixes creates security issues that are
+   particularly problematic on inter-router links, and there are other
+   valid reasons to use prefixes longer than 64 bits, in particular /127
+   (see Section 5).
+
+
+
+Kohno, et al.                Standards Track                    [Page 2]
+
+RFC 6164                   IPv6 prefixlen p2p                 April 2011
+
+
+   This document provides a rationale for using 127-bit prefix lengths,
+   reevaluates the reasons why doing so was considered harmful, and
+   specifies how /127 prefixes can be used on inter-router links
+   configured for use as point-to-point links.
+
+2.  Scope of This Memo
+
+   This document is applicable to cases where operators assign specific
+   addresses on inter-router point-to-point links and do not rely on
+   link-local addresses.  Many operators assign specific addresses for
+   the purposes of network monitoring, reverse DNS resolution for
+   traceroute and other management tools, External Border Gateway
+   Protocol (EBGP) [RFC4271] peering sessions, and so on.
+
+   For the purposes of this document, an inter-router point-to-point
+   link is a link to which only two routers and no hosts are attached.
+   This may include Ethernet links that are configured to be point-to-
+   point.  Links between a router and a host, or links to which both
+   routers and hosts are attached, are out of scope of this document.
+
+   The recommendations in this document do not apply to the link-local
+   address scope.
+
+3.  Conventions Used in This Document
+
+   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].
+
+4.  Problems Identified with 127-Bit Prefix Lengths in the Past
+
+   [RFC3627] discourages the use of 127-bit prefix lengths due to
+   conflicts with the Subnet-Router anycast addresses, while stating
+   that the utility of Subnet-Router anycast for point-to-point links is
+   questionable.
+
+   [RFC5375] also says the usage of 127-bit prefix lengths is not valid
+   and should be strongly discouraged, but the stated reason for doing
+   this is to be in compliance with [RFC3627].
+
+   Though the analyses in the RFCs are correct, operational experience
+   with IPv6 has shown that /127 prefixes can be used successfully.
+
+
+
+
+
+
+
+
+
+Kohno, et al.                Standards Track                    [Page 3]
+
+RFC 6164                   IPv6 prefixlen p2p                 April 2011
+
+
+5.  Reasons for Using Longer Prefixes
+
+   There are reasons network operators use IPv6 prefix lengths greater
+   than 64, particularly 127, for inter-router point-to-point links.
+
+5.1.  Ping-Pong Issue
+
+   A forwarding loop may occur on a point-to-point link with a prefix
+   length shorter than 127.  This does not affect interfaces that
+   perform Neighbor Discovery, but some point-to-point links, which use
+   a medium such as the Synchronous Optical Network (SONET), do not use
+   Neighbor Discovery.  As a consequence, configuring any prefix length
+   shorter than 127 bits on these links can create an attack vector in
+   the network.
+
+   The ping-pong issue happens in the case of IPv4 as well.  But due to
+   the scarcity of IPv4 address space, the current practice is to assign
+   long prefix lengths such as /30 or /31 [RFC3021] on point-to-point
+   links; thus, the problem did not come to the fore.
+
+   The latest ICMPv6 specification [RFC4443] mitigates this problem by
+   specifying that a router receiving a packet on a point-to-point link,
+   where the packet is destined to an address within a subnet assigned
+   to that same link (other than one of the receiving router's own
+   addresses), MUST NOT forward the packet back on that link.  Instead,
+   it SHOULD generate an ICMPv6 Destination Unreachable message (code 3)
+   in response.  This check is on the forwarding processing path, so it
+   may have performance impact.
+
+5.2.  Neighbor Cache Exhaustion Issue
+
+   As described in Section 4.3.2 of [RFC3756], the use of a 64-bit
+   prefix length on an inter-router link that uses Neighbor Discovery
+   (e.g., Ethernet) potentially allows for denial-of-service attacks on
+   the routers on the link.
+
+   Consider an Ethernet link between two routers, A and B, to which a
+   /64 subnet has been assigned.  A packet sent to any address on the
+   /64 (except the addresses of A and B) will cause the router
+   attempting to forward it to create a new cache entry in INCOMPLETE
+   state, send a Neighbor Solicitation message on the link, start a
+   retransmit timer, and so on [RFC4861].
+
+   By sending a continuous stream of packets to a large number of the
+   2^64 - 3 unassigned addresses on the link (one for each router and
+   one for Subnet-Router anycast), an attacker can create a large number
+   of neighbor cache entries and cause one of the routers to send a
+   large number of Neighbor Solicitation packets that will never receive
+
+
+
+Kohno, et al.                Standards Track                    [Page 4]
+
+RFC 6164                   IPv6 prefixlen p2p                 April 2011
+
+
+   replies, thereby consuming large amounts of memory and processing
+   resources.  Sending the packets to one of the 2^24 addresses on the
+   link that has the same Solicited-Node multicast address as one of the
+   routers also causes the victim to spend large amounts of processing
+   time discarding useless Neighbor Solicitation messages.
+
+   Careful implementation and rate-limiting can limit the impact of such
+   an attack, but are unlikely to neutralize it completely.  Rate-
+   limiting Neighbor Solicitation messages will reduce CPU usage, and
+   following the garbage-collection recommendations in [RFC4861] will
+   maintain reachability, but if the link is down and neighbor cache
+   entries have expired while the attack is ongoing, legitimate traffic
+   (for example, BGP sessions) over the link might never be
+   re-established, because the routers cannot resolve each others' IPv6
+   addresses to link-layer addresses.
+
+   This attack is not specific to point-to-point links, but is
+   particularly harmful in the case of point-to-point backbone links,
+   which may carry large amounts of traffic to many destinations over
+   long distances.
+
+   While there are a number of ways to mitigate this kind of issue,
+   assigning /127 subnets eliminates it completely.
+
+5.3.  Other Reasons
+
+   Though address space conservation considerations are less important
+   for IPv6 than they are in IPv4, some operators prefer not to assign
+   /64s to individual point-to-point links.  Instead, they may be able
+   to number all of their point-to-point links out of a single /64 or a
+   small number of /64s.
+
+6.  Recommendations
+
+   Routers MUST support the assignment of /127 prefixes on point-to-
+   point inter-router links.  Routers MUST disable Subnet-Router anycast
+   for the prefix when /127 prefixes are used.
+
+   When assigning and using any /127 prefixes, the following
+   considerations apply.  Some addresses have special meanings, in
+   particular addresses corresponding to reserved anycast addresses.
+   When assigning prefixes (and addresses) to links, care should be
+   taken to ensure that addresses reserved for such purposes aren't
+   inadvertently assigned and used as unicast addresses.  Otherwise,
+   nodes may receive packets that they are not intended to receive.
+   Specifically, assuming that a number of point-to-point links will be
+   numbered out of a single /64 prefix:
+
+
+
+
+Kohno, et al.                Standards Track                    [Page 5]
+
+RFC 6164                   IPv6 prefixlen p2p                 April 2011
+
+
+   (a)  Addresses with all zeros in the rightmost 64 bits SHOULD NOT be
+        assigned as unicast addresses, to avoid colliding with the
+        Subnet-Router anycast address [RFC4291].
+
+   (b)  Addresses in which the rightmost 64 bits are assigned the
+        highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:
+        ffff) SHOULD NOT be used as unicast addresses, to avoid
+        colliding with reserved subnet anycast addresses [RFC2526].
+
+7.  Security Considerations
+
+   This document does not have inherent security considerations.  It
+   does discuss security-related issues and proposes a solution to them.
+
+8.  Contributors
+
+      Chris Morrow, morrowc@google.com
+
+      Pekka Savola, pekkas@netcore.fi
+
+      Remi Despres, remi.despres@free.fr
+
+      Seiichi Kawamura, kawamucho@mesh.ad.jp
+
+9.  Acknowledgments
+
+   The authors would like to thank Ron Bonica, Pramod Srinivasan,
+   Olivier Vautrin, Tomoya Yoshida, Warren Kumari, and Tatsuya Jinmei
+   for their helpful inputs.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+
+
+
+
+
+
+
+Kohno, et al.                Standards Track                    [Page 6]
+
+RFC 6164                   IPv6 prefixlen p2p                 April 2011
+
+
+10.2.  Informative References
+
+   [RFC2526]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
+              Addresses", RFC 2526, March 1999.
+
+   [RFC3021]  Retana, A., White, R., Fuller, V., and D. McPherson,
+              "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
+              RFC 3021, December 2000.
+
+   [RFC3627]  Savola, P., "Use of /127 Prefix Length Between Routers
+              Considered Harmful", RFC 3627, September 2003.
+
+   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
+              Neighbor Discovery (ND) Trust Models and Threats",
+              RFC 3756, May 2004.
+
+   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+              January 2006.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+              Control Message Protocol (ICMPv6) for the Internet
+              Protocol Version 6 (IPv6) Specification", RFC 4443,
+              March 2006.
+
+   [RFC5375]  Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
+              and C. Hahn, "IPv6 Unicast Address Assignment
+              Considerations", RFC 5375, December 2008.
+
+Authors' Addresses
+
+   Miya Kohno
+   Juniper Networks, Keio University
+   Shinjuku Park Tower, 3-7-1 Nishishinjuku
+   Shinjuku-ku, Tokyo  163-1035
+   Japan
+
+   EMail: mkohno@juniper.net
+
+
+   Becca Nitzan
+   Juniper Networks
+   1194 North Mathilda Avenue
+   Sunnyvale, CA  94089
+   USA
+
+   EMail: nitzan@juniper.net
+
+
+
+
+Kohno, et al.                Standards Track                    [Page 7]
+
+RFC 6164                   IPv6 prefixlen p2p                 April 2011
+
+
+   Randy Bush
+   Internet Initiative Japan
+   5147 Crystal Springs
+   Bainbridge Island, WA  98110
+   USA
+
+   EMail: randy@psg.com
+
+
+   Yoshinobu Matsuzaki
+   Internet Initiative Japan
+   Jinbocho Mitsui Building
+   1-105 Kanda Jinbo-cho, Tokyo  101-0051
+   Japan
+
+   EMail: maz@iij.ad.jp
+
+
+   Lorenzo Colitti
+   Google
+   1600 Amphitheatre Parkway
+   Mountain View, CA  94043
+   USA
+
+   EMail: lorenzo@google.com
+
+
+   Thomas Narten
+   IBM Corporation
+   3039 Cornwallis Ave.
+   PO Box 12195
+   Research Triangle Park, NC  27709-2195
+   USA
+
+   EMail: narten@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kohno, et al.                Standards Track                    [Page 8]
+