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
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
在路由器间链路上使用127位IPv6前缀
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.
在路由器间的点到点链路上，出于安全和其他原因，使用127位IPv6前缀非常有用。这种做法类似于IPv4中使用31位前缀。本文档规定了路由器间点到点链路上127位IPv6前缀长度的动机和用法。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6164.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
[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.
[RFC4291]指定所有单播地址（以二进制值000开头的地址除外）的接口ID必须为64位长，并以修改的EUI-64格式构造。此外，它还定义了子网路由器选播地址，用于节点需要与链路上的路由器组中的任何一个进行通信的应用。
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).
一些运营商一直在使用127位前缀，但由于与子网路由器选播[RFC3627]冲突，因此不鼓励使用127位前缀。然而，使用64位前缀会产生安全问题，这些问题在路由器间链路上尤为严重，使用长度超过64位的前缀还有其他正当理由，特别是/127（见第5节）。
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.
本文档提供了使用127位前缀长度的基本原理，重新评估了这样做有害的原因，并指定了如何在配置为用作点到点链路的路由器间链路上使用/127前缀。
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.
本文件适用于运营商在路由器间点到点链路上分配特定地址且不依赖链路本地地址的情况。许多运营商分配特定地址用于网络监控、跟踪路由和其他管理工具的反向DNS解析、外部边界网关协议（EBGP）[RFC4271]对等会话等目的。
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.
本文档中的建议不适用于链接本地地址范围。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
[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.
[RFC3627]由于与子网路由器选播地址冲突，不鼓励使用127位前缀长度，同时指出子网路由器选播用于点到点链路的实用性值得怀疑。
[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].
[RFC5375]还表示，127位前缀长度的使用是无效的，应强烈反对，但这样做的理由是符合[RFC3627]。
Though the analyses in the RFCs are correct, operational experience with IPv6 has shown that /127 prefixes can be used successfully.
尽管RFCs中的分析是正确的，但IPv6的运行经验表明/127前缀可以成功使用。
There are reasons network operators use IPv6 prefix lengths greater than 64, particularly 127, for inter-router point-to-point links.
网络运营商使用IPv6前缀长度大于64（特别是127）作为路由器间点到点链路是有原因的。
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.
转发循环可能发生在前缀长度小于127的点到点链路上。这不会影响执行邻居发现的接口，但某些使用同步光网络（SONET）等介质的点到点链路不使用邻居发现。因此，配置这些链接上的短于127位的任何前缀长度可以在网络中创建攻击向量。
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.
乒乓问题也发生在IPv4的情况下。但由于IPv4地址空间不足，目前的做法是在点到点链路上分配长前缀长度，如/30或/31[RFC3021]；因此，这个问题并没有突出。
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.
最新的ICMPv6规范[RFC4443]通过指定在点到点链路上接收数据包的路由器不得将数据包转发回该链路上，而该数据包的目的地是分配给同一链路的子网内的地址（接收路由器自己的地址之一除外），从而缓解了这一问题。相反，它应该生成一条ICMPv6目的地不可访问消息（代码3）作为响应。此检查位于转发处理路径上，因此可能会影响性能。
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.
如[RFC3756]第4.3.2节所述，在使用邻居发现（如以太网）的路由器间链路上使用64位前缀长度可能会导致对链路上路由器的拒绝服务攻击。
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].
考虑两个路由器A、B之间的以太网链路，A/64子网已被分配给该路由器。发送到/64上任何地址（A和B地址除外）的数据包将导致试图转发它的路由器在不完整状态下创建新的缓存项，在链路上发送邻居请求消息，启动重传计时器，等等[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
通过向链路上大量的2^64-3个未分配地址（每个路由器一个，子网路由器选播一个）发送连续的数据包流，攻击者可以创建大量的邻居缓存条目，并导致其中一个路由器发送大量的邻居请求数据包，而这些数据包永远不会收到
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.
回复，从而消耗大量内存和处理资源。将数据包发送到与路由器之一具有相同请求节点多播地址的链路上的2^24个地址之一也会导致受害者花费大量处理时间丢弃无用的邻居请求消息。
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.
谨慎的实施和速率限制可以限制此类攻击的影响，但不太可能完全消除它。速率限制邻居请求消息将减少CPU使用，并且遵循[RFC4861]中的垃圾收集建议将保持可达性，但如果在攻击进行期间链路中断且邻居缓存项已过期，则链路上的合法流量（例如BGP会话）可能永远不会重新建立，因为路由器无法将彼此的IPv6地址解析为链路层地址。
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.
虽然有许多方法可以缓解此类问题，但分配/127子网可完全消除此问题。
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.
虽然与IPv4相比，IPv6中的地址空间保护考虑因素不太重要，但一些运营商不愿意将/64分配给单个点到点链路。相反，它们可以从单个/64或少量/64中对所有点对点链接进行编号。
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.
路由器必须支持在点对点路由器间链路上分配/127前缀。使用/127前缀时，路由器必须禁用前缀的子网路由器选播。
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:
分配和使用任何/127前缀时，应考虑以下事项。某些地址具有特殊含义，特别是对应于保留选播地址的地址。为链接分配前缀（和地址）时，应注意确保为此类目的保留的地址不会无意中被分配和用作单播地址。否则，节点可能会接收它们不打算接收的数据包。具体来说，假设多个点到点链路将从单个/64前缀中编号：
(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].
(a) 最右边64位中全零的地址不应指定为单播地址，以避免与子网路由器选播地址[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].
(b) 为避免与保留子网选播地址冲突，最右边的64位分配了最高128个值的地址（即ffff:ffff:ffff:ff7f到ffff:ffff:ffff:ffff）不应用作单播地址[RFC2526]。
This document does not have inherent security considerations. It does discuss security-related issues and proposes a solution to them.
本文件没有固有的安全考虑。它确实讨论了与安全相关的问题，并提出了解决方案。
Chris Morrow, morrowc@google.com
克里斯·莫罗，morrowc@google.com
Pekka Savola, pekkas@netcore.fi
佩卡·萨沃拉，pekkas@netcore.fi
Remi Despres, remi.despres@free.fr
雷米·德普雷斯，雷米。despres@free.fr
Seiichi Kawamura, kawamucho@mesh.ad.jp
川村诚一，kawamucho@mesh.ad.jp
The authors would like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin, Tomoya Yoshida, Warren Kumari, and Tatsuya Jinmei for their helpful inputs.
作者要感谢Ron Bonica、Pramod Srinivasan、Olivier Vautrin、Tomoya Yoshida、Warren Kumari和Tatsuya Jinmei提供的有用信息。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021]Retana，A.，White，R.，Fuller，V.，和D.McPherson，“在IPv4点到点链路上使用31位前缀”，RFC 30212000年12月。
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003.
[RFC3627]Savola，P.，“在路由器之间使用/127前缀长度被认为是有害的”，RFC 3627，2003年9月。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Ed.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 3756，2004年5月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[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.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 2008.
[RFC5375]Van de Velde，G.，Popoviciu，C.，Chown，T.，Bonness，O.，和C.Hahn，“IPv6单播地址分配注意事项”，RFC 5375，2008年12月。
Authors' Addresses
作者地址
Miya Kohno Juniper Networks, Keio University Shinjuku Park Tower, 3-7-1 Nishishinjuku Shinjuku-ku, Tokyo 163-1035 Japan
Miya Kohno Juniper Networks，庆应大学新宿公园塔，日本东京西新宿3-7-1号，日本东京163-1035
EMail: mkohno@juniper.net
EMail: mkohno@juniper.net
Becca Nitzan Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔市北马蒂尔达大道1194号贝卡·尼桑·杜松网络公司，邮编94089
EMail: nitzan@juniper.net
EMail: nitzan@juniper.net
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 USA
兰迪·布什互联网倡议日本5147水晶泉班布里奇岛，华盛顿98110美国
EMail: randy@psg.com
EMail: randy@psg.com
Yoshinobu Matsuzaki Internet Initiative Japan Jinbocho Mitsui Building 1-105 Kanda Jinbo-cho, Tokyo 101-0051 Japan
日本东京神田金宝町1-105号金宝町三井金宝町1-105号楼日本松崎吉诺布互联网倡议101-0051
EMail: maz@iij.ad.jp
EMail: maz@iij.ad.jp
Lorenzo Colitti Google 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
洛伦佐·科利蒂谷歌1600竞技场公园道山景，美国加利福尼亚州94043
EMail: lorenzo@google.com
EMail: lorenzo@google.com
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195 USA
Thomas Narten IBM Corporation美国北卡罗来纳州研究三角公园康沃利斯大道3039号邮政信箱12195号，邮编27709-2195
EMail: narten@us.ibm.com
EMail: narten@us.ibm.com