Movatterモバイル変換

Internet Engineering Task Force (IETF)                          M. KohnoRequest for Comments: 6164             Juniper Networks, Keio UniversityCategory: Standards Track                                      B. NitzanISSN: 2070-1721                                         Juniper Networks                                                                 R. Bush                                                            Y. Matsuzaki                                               Internet Initiative Japan                                                              L. Colitti                                                                  Google                                                               T. Narten                                                         IBM Corporation                                                              April 2011Using 127-Bit IPv6 Prefixes on Inter-Router LinksAbstract   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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6164.Kohno, et al.                Standards Track                    [Page 1]

RFC 6164                   IPv6 prefixlen p2p                 April 2011Copyright Notice   Copyright (c) 2011 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1. Introduction ....................................................22. Scope of This Memo ..............................................33. Conventions Used in This Document ...............................34. Problems Identified with 127-Bit Prefix Lengths in the Past .....35. Reasons for Using Longer Prefixes ...............................45.1. Ping-Pong Issue ............................................45.2. Neighbor Cache Exhaustion Issue ............................45.3. Other Reasons ..............................................56. Recommendations .................................................57. Security Considerations .........................................68. Contributors ....................................................69. Acknowledgments .................................................610. References .....................................................610.1. Normative References ......................................610.2. Informative References ....................................71.  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   (seeSection 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 inRFC 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 20115.  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 inSection 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 receiveKohno, 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.jp9.  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.  References10.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 201110.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.netKohno, 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.comKohno, et al.                Standards Track                    [Page 8]