Network Working Group S. Roy
Request for Comments: 4943 Sun Microsystems, Inc.
Category: Informational A. Durand
Comcast
J. Paugh
Nominum, Inc.
September 2007
Network Working Group S. Roy
Request for Comments: 4943 Sun Microsystems, Inc.
Category: Informational A. Durand
Comcast
J. Paugh
Nominum, Inc.
September 2007
IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
基于链路假设的IPv6邻居发现被认为是有害的
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm.
本文档描述了从IP版本6（IPv6）的邻居发现中定义的概念主机发送算法中删除“链路上假设”的历史和背景信息。根据最初描述的算法，当主机的默认路由器列表为空时，主机假定所有目的地都在链路上。对于不具备脱离链路IPv6连接（例如，没有默认路由器）的支持IPv6的节点来说，这尤其有问题。本文档描述了做出这种假设是如何导致问题的，以及这些问题是如何超过概念发送算法这一部分的好处的。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background on the On-link Assumption . . . . . . . . . . . . . 2
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. First Rule of Destination Address Selection . . . . . . . . 3
3.2. Delays Associated with Address Resolution . . . . . . . . . 3
3.3. Multi-interface Ambiguity . . . . . . . . . . . . . . . . . 4
3.4. Security-Related Issues . . . . . . . . . . . . . . . . . . 4
4. Changes to RFC 2461 . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background on the On-link Assumption . . . . . . . . . . . . . 2
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. First Rule of Destination Address Selection . . . . . . . . 3
3.2. Delays Associated with Address Resolution . . . . . . . . . 3
3.3. Multi-interface Ambiguity . . . . . . . . . . . . . . . . . 4
3.4. Security-Related Issues . . . . . . . . . . . . . . . . . . 4
4. Changes to RFC 2461 . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7
Neighbor Discovery for IPv6 [RFC4861] defines a conceptual sending algorithm for hosts. The version of the algorithm described in [RFC2461] states that if a host's default router list is empty, then the host assumes that all destinations are on-link. This memo documents the removal of this assumption in the updated Neighbor Discovery specification [RFC4861] and describes the reasons why this assumption was removed.
IPv6邻居发现[RFC4861]定义了主机的概念性发送算法。[RFC2461]中描述的算法版本说明，如果主机的默认路由器列表为空，则主机假定所有目的地都在链路上。本备忘录记录了更新的邻居发现规范[RFC4861]中删除此假设的情况，并说明了删除此假设的原因。
This assumption is problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity. This is typical when systems that have IPv6 enabled on their network interfaces (either on by default or administratively configured that way) are attached to networks that have no IPv6 services such as off-link routing. Such systems will resolve DNS names to AAAA and A records, and they may attempt to connect to unreachable IPv6 off-link nodes.
对于不具备脱离链路IPv6连接的支持IPv6的节点，此假设存在问题。当在其网络接口上启用了IPv6的系统（默认情况下启用或以这种方式管理配置）连接到没有IPv6服务（如断开链路路由）的网络时，这是典型的情况。此类系统将DNS名称解析为AAAA和A记录，并可能尝试连接到无法访问的IPv6断开链路节点。
The on-link assumption creates problems for destination address selection as defined in [RFC3484], and it adds connection delays associated with unnecessary address resolution and neighbor unreachability detection. The behavior associated with the assumption is undefined on multi-interface nodes and has some subtle security implications. All of these issues are discussed in this document.
链路上的假设为[RFC3484]中定义的目标地址选择带来了问题，并增加了与不必要的地址解析和邻居不可达性检测相关的连接延迟。与该假设相关联的行为在多接口节点上是未定义的，并且具有一些微妙的安全含义。本文件讨论了所有这些问题。
This part of Neighbor Discovery's [RFC2461] conceptual sending algorithm was created to facilitate communication on a single link between systems configured with different global prefixes in the absence of an IPv6 router. For example, consider the case where two systems on separate links are manually configured with global addresses and are then plugged in back-to-back. They can still communicate with each other via their global addresses because they'll correctly assume that each is on-link.
邻居发现[RFC2461]概念发送算法的这一部分是为了在没有IPv6路由器的情况下，促进配置了不同全局前缀的系统之间在单个链路上的通信。例如，考虑在单独链路上的两个系统手动配置全局地址，然后被背对背插入的情况。他们仍然可以通过他们的全局地址相互通信，因为他们会正确地假设每个人都在链路上。
Without the on-link assumption, the above scenario wouldn't work, and the systems would need to be configured to share a common prefix such as the link-local prefix. On the other hand, the on-link assumption introduces several problems to various parts of the networking stack described in Section 3. As such, this document points out that the problems introduced by the on-link assumption outweigh the benefit that the assumption lends to this scenario. It is more beneficial to the end user to remove the on-link assumption from Neighbor Discovery and declare this scenario illegitimate (or a misconfiguration).
如果没有on-link假设，上述场景将无法工作，系统需要配置为共享一个公共前缀，例如link-local前缀。另一方面，On-link假设给第3节中描述的网络堆栈的各个部分带来了几个问题。因此，本文件指出，链接假设带来的问题超过了该假设带来的好处。对于最终用户来说，从邻居发现中删除链路上的假设并宣布此场景为非法（或错误配置）更为有利。
The on-link assumption causes the following problems.
联机假设会导致以下问题。
Default Address Selection for IPv6 [RFC3484] defines a destination address selection algorithm that takes an unordered list of destination addresses as input and produces a sorted list of destination addresses as output. The algorithm consists of destination address sorting rules, the first of which is "Avoid unusable destinations". The idea behind this rule is to place unreachable destinations at the end of the sorted list so that applications will be least likely to try to communicate with those addresses first.
IPv6的默认地址选择[RFC3484]定义了一种目标地址选择算法，该算法将无序的目标地址列表作为输入，并生成有序的目标地址列表作为输出。该算法由目的地址排序规则组成，第一个规则是“避免不可用的目的地”。这条规则背后的思想是将无法到达的目的地放在排序列表的末尾，这样应用程序就不太可能首先尝试与这些地址通信。
The on-link assumption could potentially cause false positives when attempting unreachability determination for this rule. On a network where there is no IPv6 router (all off-link IPv6 destinations are unreachable), the on-link assumption states that destinations are assumed to be on-link. An implementation could interpret that as, if the default router list is empty, then all destinations are reachable on-link. This may cause the rule to prefer an unreachable IPv6 destination over a reachable IPv4 destination.
在尝试确定此规则的不可访问性时，链接上假设可能会导致误报。在没有IPv6路由器的网络上（所有断开链路的IPv6目的地都不可访问），链路上假设表示目的地假定为链路上。一个实现可以解释为，如果默认路由器列表为空，那么所有目的地都可以在链路上访问。这可能会导致规则倾向于选择不可访问的IPv6目标，而不是可访问的IPv4目标。
Users expect that applications quickly connect to a given destination regardless of the number of IP addresses assigned to that destination. If a destination name resolves to multiple addresses and the application attempts to communicate to each address until one succeeds, this process shouldn't take an unreasonable amount of time. It is therefore important that the system quickly determine if IPv6 destinations are unreachable so that the application can try other destinations when those IPv6 destinations are unreachable.
用户希望应用程序能够快速连接到给定的目的地，而不考虑分配给该目的地的IP地址数量。如果目标名称解析为多个地址，并且应用程序尝试与每个地址通信，直到其中一个地址成功为止，则此过程不应花费不合理的时间。因此，系统必须快速确定IPv6目的地是否无法访问，以便应用程序可以在无法访问其他目的地时尝试这些目的地。
For an IPv6-enabled host deployed on a network that has no IPv6 routers, the result of the on-link assumption is that link-layer address resolution must be performed on all IPv6 addresses to which the host sends packets. The application will not receive acknowledgment of the unreachability of destinations that are not on-link until at least address resolution has failed, which is no less than 3 seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). This is greatly amplified by transport protocol delays. For example, [RFC1122] Section 4.2.3.5 requires that TCP retransmit for at least 3 minutes before aborting the connection attempt.
对于部署在没有IPv6路由器的网络上的启用IPv6的主机，链路上假设的结果是必须对主机向其发送数据包的所有IPv6地址执行链路层地址解析。在至少地址解析失败之前，应用程序将不会收到不在链路上的目的地不可到达的确认，地址解析失败的时间不少于3秒（最大多播请求*重传计时器）。传输协议延迟大大放大了这一点。例如，[RFC1122]第4.2.3.5节要求TCP在中止连接尝试之前至少重新传输3分钟。
When the application has a large list of off-link unreachable IPv6 addresses followed by at least one reachable IPv4 address, the delay associated with Neighbor Unreachability Detection (NUD) of each IPv6 address before successful communication with the IPv4 address is unacceptable.
当应用程序具有大量链路外不可访问的IPv6地址列表，后跟至少一个可访问的IPv4地址时，在与IPv4地址成功通信之前，与每个IPv6地址的邻居不可访问性检测（NUD）相关的延迟是不可接受的。
There is no defined way to implement this aspect of the sending algorithm on a node that is attached to multiple links. Specifically, a problem arises when a node is faced with sending a packet to an IPv6 destination address to which it has no route, and the sending node is attached to multiple links. With the on-link assumption, this node assumes that the destination is on-link, but on which link? From an implementor's point of view, there are three ways to handle sending an IPv6 packet to a destination in the face of the on-link assumption on a multi-interface node:
在连接到多个链路的节点上，没有定义的方法来实现发送算法的这一方面。具体地说，当节点面临向其没有路由的IPv6目标地址发送数据包，并且发送节点连接到多个链路时，就会出现问题。在链路上假设的情况下，该节点假设目的地在链路上，但在哪个链路上？从实施者的角度来看，面对多接口节点上的链路上假设，有三种方法可以处理向目的地发送IPv6数据包：
1. Attempt to send the packet on a single link (either administratively pre-defined or using some algorithm).
1. 尝试在单个链路上发送数据包（管理预定义或使用某种算法）。
2. Attempt to send the packet on every link.
2. 尝试在每个链路上发送数据包。
3. Drop the packet.
3. 放下包。
If the destination is indeed on-link, the first option might not succeed since the wrong link could be picked. The second option might succeed in reaching the destination but is more complex to implement and isn't guaranteed to pick the correct destination. For example, there could be more than one node configured with the same address, each reachable through a different link. The address by itself does not disambiguate which destination the sender actually wanted to reach, so attempting to send the packet to every link is not guaranteed to reach the anticipated destination. The third option, dropping the packet, is equivalent to not making the on-link assumption at all. In other words, if there is no route to the destination, don't attempt to send the packet. An implementation that behaves this way would require an administrator to configure routes to the destination in order to have reachability to the destination, thus eliminating the ambiguity.
如果目标确实在链接上，第一个选项可能不会成功，因为可能会选择错误的链接。第二个选项可能成功到达目的地，但实现起来更复杂，而且不能保证选择正确的目的地。例如，可能有多个节点配置了相同的地址，每个节点都可以通过不同的链接访问。地址本身并不能消除发送方实际想要到达的目的地的歧义，因此尝试将数据包发送到每个链路并不保证能够到达预期的目的地。第三种选择，丢弃数据包，相当于根本不进行链路上的假设。换句话说，如果没有到目的地的路由，不要尝试发送数据包。以这种方式运行的实现需要管理员配置到目的地的路由，以便能够到达目的地，从而消除模糊性。
The on-link assumption discussed here introduces a security vulnerability to the Neighbor Discovery protocol described in Section 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756] titled "Default router is 'killed'". There is a threat that a host's router can be maliciously killed in order to cause the host to start
此处讨论的链路上假设为IPv6邻居发现信任模型和威胁[RFC3756]第4.2.2节中描述的邻居发现协议引入了一个安全漏洞，标题为“默认路由器被“杀死”。存在一种威胁，即主机的路由器可能被恶意杀死，从而导致主机启动
sending all packets on-link. The attacker can then spoof off-link nodes by sending packets on the same link as the host. The vulnerability is discussed in detail in [RFC3756].
在链路上发送所有数据包。然后，攻击者可以通过在与主机相同的链路上发送数据包来欺骗链路节点。[RFC3756]中详细讨论了该漏洞。
Another security-related side-effect of the on-link assumption has to do with virtual private networks (VPNs). It has been observed that some commercially available VPN software solutions that don't support IPv6 send IPv6 packets to the local media in the clear (their security policy doesn't simply drop IPv6 packets). Consider a scenario where a system has a single Ethernet interface with VPN software that encrypts and encapsulates certain packets. The system attempts to send a packet to an IPv6 destination that it obtained by doing a DNS lookup, and the packet ends up going in the clear to the local media. A malicious third party could then spoof the destination on-link.
链路上假设的另一个与安全相关的副作用与虚拟专用网络（VPN）有关。据观察，一些不支持IPv6的商用VPN软件解决方案会将IPv6数据包发送到本地媒体（其安全策略不会简单地丢弃IPv6数据包）。考虑一个场景，系统有一个单一的以太网接口，用VPN软件加密和封装某些数据包。系统尝试向通过DNS查找获得的IPv6目标发送数据包，数据包最终被清除到本地媒体。然后，恶意的第三方可以在链接上欺骗目标。
The following changes have been made to the Neighbor Discovery specification between [RFC2461] and [RFC4861]:
[RFC2461]和[RFC4861]之间的邻居发现规范进行了以下更改：
The last sentence of the second paragraph of Section 5.2 ("Conceptual Sending Algorithm") was removed. This sentence was, "If the Default Router List is empty, the sender assumes that the destination is on-link."
删除第5.2节第二段（“概念发送算法”）的最后一句。这句话是：“如果默认路由器列表为空，则发送方假定目的地在链路上。”
Bullet item 3) in Section 6.3.6 ("Default Router Selection") was removed. The item read, "If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2."
删除了第6.3.6节（“默认路由器选择”）中的项目3）。该项内容为：“如果默认路由器列表为空，则假设所有目的地都在第5.2节规定的链路上。”
APPENDIX A was modified to remove on-link assumption related text in bullet item 1) under the discussion on what happens when a multihomed host fails to receive Router Advertisements.
对附录A进行了修改，删除了项目符号1）中与链接假设相关的文本，讨论了当多宿主机无法接收路由器广告时会发生什么情况。
The result of these changes is that destinations are considered unreachable when there is no routing information for that destination (through a default router or otherwise). Instead of attempting link-layer address resolution when sending to such a destination, a node should send an ICMPv6 Destination Unreachable message (code 0 - no route to destination) message up the stack.
这些更改的结果是，如果没有目的地的路由信息（通过默认路由器或其他方式），则认为目的地不可访问。当发送到这样的目的地时，节点不应尝试链路层地址解析，而应向堆栈上发送ICMPv6目的地不可访问消息（代码0-无到目的地的路由）。
The removal of the on-link assumption from Neighbor Discovery addresses all of the security-related vulnerabilities of the protocol as described in Section 3.4.
如第3.4节所述，从邻居发现中删除链路上的假设解决了协议的所有安全相关漏洞。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[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月。
The authors gratefully acknowledge the contributions of Jim Bound, Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol.
作者衷心感谢吉姆·邦德、斯宾塞·道金斯、托尼·海恩、米卡·利耶贝格、埃里克·诺德马克、佩卡·萨沃拉和罗纳德·范德波尔的贡献。
Authors' Addresses
作者地址
Sebastien Roy Sun Microsystems, Inc. 1 Network Drive UBUR02-212 Burlington, MA 01803
Sebastien Roy Sun Microsystems，Inc.马萨诸塞州伯灵顿市网络大道1号UBUR02-212邮编01803
EMail: sebastien.roy@sun.com
EMail: sebastien.roy@sun.com
Alain Durand Comcast 1500 Market Street Philadelphia, PA 19102
宾夕法尼亚州费城市场街1500号Alain Durand Comcast，邮编：19102
EMail: alain_durand@cable.comcast.com
EMail: alain_durand@cable.comcast.com
James Paugh Nominum, Inc. 2385 Bay Road Redwood City, CA 94063
James Paugh Nominum，Inc.加利福尼亚州红木市海湾路2385号，邮编94063
EMail: jim.paugh@nominum.com
EMail: jim.paugh@nominum.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.