Network Working Group R. Hinden
Request for Comments: 4311 Nokia
Updates: 2461 D. Thaler
Category: Standards Track Microsoft
November 2005
Network Working Group R. Hinden
Request for Comments: 4311 Nokia
Updates: 2461 D. Thaler
Category: Standards Track Microsoft
November 2005
IPv6 Host-to-Router Load Sharing
IPv6主机到路由器负载共享
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion.
最初的IPv6概念发送算法没有在等效IPv6路由器之间进行负载共享，并且提出了在实践中可能存在问题的方案。本文档更新了RFC2461中的概念发送算法，以便以高效的方式在路由器之间分配到不同目的地的流量。
In the conceptual sending algorithm in [ND] and in the optional extension in [ROUTERSEL], a next hop is chosen when no destination cache entry exists for an off-link destination or when communication through an existing router is failing. Normally, a router is selected the first time traffic is sent to a specific destination IP address. Subsequent traffic to the same destination address continues to use the same router unless there is some reason to change to a different router (e.g., a redirect message is received, or the router is found to be unreachable).
在[ND]中的概念发送算法和[ROUTERSEL]中的可选扩展中，当断开链路的目的地不存在目的地缓存条目或通过现有路由器的通信失败时，选择下一跳。通常，第一次将流量发送到特定的目标IP地址时会选择路由器。到同一目的地地址的后续通信继续使用同一路由器，除非有理由更改到不同的路由器（例如，接收到重定向消息，或发现无法访问路由器）。
In addition, as described in [ADDRSEL], the choice of next hop may also affect the choice of source address, and hence indirectly (and to a lesser extent) may affect the router used for inbound traffic as well.
此外，如[ADDRSEL]中所述，下一跳的选择也可能影响源地址的选择，因此间接（在较小程度上）也可能影响用于入站流量的路由器。
In both the base sending algorithm and in the optional extension, sometimes a host has a choice of multiple equivalent routers for a destination. That is, all other factors are equal and a host must break a tie via some implementation-specific means.
在基本发送算法和可选扩展中，有时主机可以为目的地选择多个等效路由器。也就是说，所有其他因素都是平等的，主机必须通过特定于实现的方式打破僵局。
It is often desirable when there is more than one equivalent router that hosts distribute their outgoing traffic among these routers. This shares the load among multiple routers and provides better performance for the host's traffic.
当有一个以上的等效路由器，主机在这些路由器之间分配它们的传出流量时，这通常是可取的。这将在多个路由器之间共享负载，并为主机的流量提供更好的性能。
On the other hand, load sharing can be undesirable in situations where sufficient capacity is available through a single router and the traffic patterns could be more predictable by using a single router; in particular, this helps to diagnose connectivity problems beyond the first-hop routers.
另一方面，在通过单个路由器具有足够容量的情况下，负载共享可能是不可取的，并且通过使用单个路由器，流量模式可以更可预测；特别是，这有助于诊断第一跳路由器以外的连接问题。
[ND] does not require any particular behavior in this respect. It specifies that an implementation may always choose the same router (e.g., the first in the list) or may cycle through the routers in a round-robin manner. Both of these suggestions are problematic.
[ND]在这方面不需要任何特定的行为。它指定一个实现可以始终选择相同的路由器（例如，列表中的第一个），或者可以以循环方式在路由器之间循环。这两个建议都有问题。
Clearly, always choosing the same router does not provide load sharing. Some problems with load sharing using naive tie-breaking techniques such as round-robin and random are discussed in [MULTIPATH]. While the destination cache provides some stability since the determination is not per packet, cache evictions or timeouts can still result in unstable or unpredictable paths over time, lowering the performance and making it harder to diagnose problems. Round-robin selection may also result in synchronization issues among hosts, where in the worst case the load is concentrated on one router at a time.
显然，总是选择相同的路由器并不能提供负载共享。[MULTIPATH]中讨论了使用简单的连接中断技术（如循环和随机）进行负载共享的一些问题。虽然目标缓存提供了一定的稳定性，因为确定不是针对每个数据包的，但缓存收回或超时仍会随着时间的推移导致路径不稳定或不可预测，从而降低性能并使诊断问题变得更加困难。循环选择还可能导致主机之间的同步问题，在最坏的情况下，负载一次集中在一个路由器上。
In the remainder of this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
在本文件的其余部分中，关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
When a host chooses from multiple equivalent routers, it SHOULD support choosing using some method that distributes load for different destinations among the equivalent routers rather than always choosing the same router (e.g., the first in the list). This memo takes no stance on whether the support for load sharing should be turned on or off by default. Furthermore, a host that does attempt to distribute load among routers SHOULD use a hash-based scheme that takes (at least) the destination IP address into account, such as those described in [MULTIPATH], for choosing a router to use.
当主机从多个等效路由器中进行选择时，它应该支持使用某种方法在等效路由器之间为不同目的地分配负载，而不是总是选择同一个路由器（例如，列表中的第一个）。对于默认情况下是否应打开或关闭负载共享支持，此备忘录不采取任何立场。此外，尝试在路由器之间分配负载的主机应使用（至少）考虑目标IP地址的基于散列的方案，如[多路径]中所述，以选择要使用的路由器。
Note that traffic for a given destination address will use the same router as long as the Destination Cache Entry for the destination address is not deleted. With a hash-based scheme, traffic for a given destination address will use the same router over time even if the Destination Cache Entry is deleted, as long as the list of equivalent routers remains the same.
请注意，只要不删除目标地址的目标缓存条目，给定目标地址的通信量将使用相同的路由器。使用基于散列的方案，随着时间的推移，给定目标地址的流量将使用相同的路由器，即使目标缓存条目被删除，只要等效路由器的列表保持不变。
As mentioned in [MULTIPATH], when next-hop selection is predictable, an application can synthesize traffic that will all hash the same, making it possible to launch a denial-of-service attack against the load-sharing algorithm, and overload a particular router. This can even be done by a remote application that can cause a host to respond to a given destination address. A special case of this is when the same (single) next-hop is always selected, such as in the algorithm allowed by [ND]. Introducing hashing can make such an attack more difficult; the more unpredictable the hash is, the harder it becomes to conduct a denial-of-service attack against any single router.
如[MULTIPATH]中所述，当下一跳选择是可预测的时，应用程序可以合成所有哈希相同的流量，从而有可能对负载共享算法发起拒绝服务攻击，并使特定路由器过载。这甚至可以由远程应用程序完成，该应用程序可以使主机响应给定的目标地址。这种情况的一种特殊情况是，始终选择相同（单个）下一跳，如[ND]允许的算法。引入哈希会使这种攻击更加困难；哈希值越不可预测，就越难对任何单个路由器进行拒绝服务攻击。
However, a malicious local application can bypass the algorithm for its own traffic by using mechanisms such as raw sockets, and remote attackers can still overload the routers directly. Hence, the mechanisms discussed herein have no significant incremental impact on Internet infrastructure security.
然而，恶意的本地应用程序可以通过使用原始套接字等机制绕过算法来获取自己的流量，远程攻击者仍然可以直接使路由器过载。因此，本文讨论的机制对互联网基础设施安全没有显著的增量影响。
The authors of this document would like to thank Erik Nordmark, Brian Haberman, Steve Deering, Aron Silverton, Christian Huitema, and Pekka Savola.
本文作者要感谢Erik Nordmark、Brian Haberman、Steve Deering、Aron Silverton、Christian Huitema和Pekka Savola。
[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[ND]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[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月。
[ADDRSEL] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[ADDRSEL]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[ROUTERSEL] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[ROUTERSEL]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[MULTIPATH] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[多路径]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 2991，2000年11月。
Authors' Addresses
作者地址
Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043
Robert Hinden诺基亚313飞兆半导体山景大道，加利福尼亚州94043
Phone: +1 650 625-2004
EMail: bob.hinden@nokia.com
Phone: +1 650 625-2004
EMail: bob.hinden@nokia.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
Dave Thaler微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。