Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 8319 Kaloom
Updates: 4861 J. Korhonen
Category: Standards Track Nordic Semiconductor ASA
ISSN: 2070-1721 S. Chakrabarti
Verizon
E. Nordmark
Zededa
A. Yourtchenko
Cisco
February 2018
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 8319 Kaloom
Updates: 4861 J. Korhonen
Category: Standards Track Nordic Semiconductor ASA
ISSN: 2070-1721 S. Chakrabarti
Verizon
E. Nordmark
Zededa
A. Yourtchenko
Cisco
February 2018
Support for Adjustable Maximum Router Lifetimes per Link
支持每个链路可调整的最大路由器寿命
Abstract
摘要
The IPv6 Neighbor Discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements (RAs) from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by documents that are specific to the link layer. This document allows for overriding these values on a per-link basis.
IPv6邻居发现协议指定从路由器接口发送未经请求的多播路由器广告（RAs）之间允许的最长时间以及路由器的最长生存期。它还允许特定于链接层的文档覆盖这些限制。本文档允许在每个链接的基础上覆盖这些值。
This document specifies updates to the IPv6 Neighbor Discovery Protocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime.
本文档指定了对IPv6邻居发现协议（RFC 4861）的更新，以增加从路由器接口发送未经请求的多播RAs之间允许的最长时间，并增加路由器的最长生存期。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8319.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8319.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Relationship between AdvDefaultLifetime and MaxRtrAdvInterval 3
4. Updates to RFC 4861 . . . . . . . . . . . . . . . . . . . . . 4
5. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Relationship between AdvDefaultLifetime and MaxRtrAdvInterval 3
4. Updates to RFC 4861 . . . . . . . . . . . . . . . . . . . . . 4
5. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
IPv6 Neighbor Discovery relies on IP multicast based on the expectation that multicast makes efficient use of available bandwidth and avoids generating interrupts in the network nodes. On some data link layers, multicast may not be natively supported. On such links, any possible reduction of multicast traffic will be highly beneficial. Unfortunately, due to the fixed protocol constants specified in [RFC4861], it is difficult to relax the multicast timers for Neighbor Discovery. There are already clarifications specific to the link technology about how to tune the Neighbor Discovery Protocol (NDP) constants for certain systems in order to reduce excess NDP traffic. For example, [RFC6459] and [RFC7066] contain such clarifications for 3GPP cellular links.
IPv6邻居发现依赖于IP多播，因为多播可以有效利用可用带宽并避免在网络节点中产生中断。在某些数据链路层上，本机可能不支持多播。在这样的链路上，多播通信量的任何可能的减少都将是非常有益的。不幸的是，由于[RFC4861]中指定的固定协议常数，很难放松用于邻居发现的多播计时器。关于如何调整某些系统的邻居发现协议（NDP）常数以减少多余的NDP通信量，已经有针对链路技术的澄清。例如，[RFC6459]和[RFC7066]包含对3GPP蜂窝链路的此类澄清。
This document specifies updates to the IPv6 Neighbor Discovery Protocol [RFC4861] to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime.
本文档指定了对IPv6邻居发现协议[RFC4861]的更新，以增加从路由器接口发送未经请求的多播RAs之间允许的最长时间，并增加路由器的最长生存期。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
MaxRtrAdvInterval is an upper bound on the time between which two successive Router Advertisement messages are sent. Therefore, one might reason about the relationship between these two values in terms of a ratio K = AdvDefaultLifetime / MaxRtrAdvInterval, which expresses how many Router Advertisements are guaranteed to be sent before the router lifetime expires.
MaxRtrAdvInterval是发送两条连续路由器广告消息的时间上限。因此，我们可以用比率K=AdvDefaultLifetime/MaxRtrAdvInterval来解释这两个值之间的关系，该比率表示在路由器生存期到期之前保证发送多少路由器广告。
Assuming unicast Solicited Router Advertisements or a perfectly stable network, on a theoretically perfect link with no losses, it would be sufficient to have K just above 1, so that the sent Router Advertisement refreshes the router entry just before it expires. On the real links that allow for some loss, one would need to use K > 2 in order to minimize the chances of a single Router Advertisement loss causing a loss of the router entry.
假设单播请求的路由器广告或完全稳定的网络，在理论上完美的链路上没有损失，K刚好大于1就足够了，因此发送的路由器广告在其到期之前刷新路由器条目。在允许某些丢失的实际链路上，需要使用K>2，以最小化单个路由器广告丢失导致路由器入口丢失的可能性。
The exact calculation will depend on the packet loss probability. An example: if we take a ballpark value of 1% probability of a packet loss, then K = 2 will give 0.01% chance of an outage due to a packet loss, K = 3 will give 0.0001% chance of an outage, and so forth. To reverse the numbers, with these parameters, K ~= 1 gives 99% reliability, K ~= 2 gives 99.99% reliability, and K ~= 3 gives 99.9999% reliability -- which should be good enough for a lot of scenarios.
准确的计算将取决于分组丢失概率。例如：如果我们采用1%的数据包丢失概率的大致值，那么K=2将给出0.01%的数据包丢失导致中断的概率，K=3将给出0.0001%的中断概率，依此类推。为了逆转这些数字，使用这些参数，K~=1给出99%的可靠性，K~=2给出99.99%的可靠性，K~=3给出99.9999%的可靠性——这对于很多场景来说应该足够好了。
In a network with higher packet loss probabilities or if higher reliability is desired, the K might be chosen to be even higher. On the other hand, some of the data link layers provide reliable delivery at Layer 2, so there one might even consider using the "theoretical" value of K just above 1. Since the choice of these two parameters does not impact interoperability per se, this document does not impose any specific constraints on their values other than providing the guidelines in this section. Therefore, each individual link can optimize according to its use case.
在具有更高分组丢失概率的网络中，或者如果需要更高的可靠性，则K可以被选择为更高。另一方面，一些数据链路层在第2层提供可靠的传输，因此有人甚至可以考虑使用K的理论值大于1。由于这两个参数的选择本身并不影响互操作性，因此本文档除了提供本节中的指南外，不对其值施加任何特定约束。因此，每个单独的链接都可以根据其用例进行优化。
Also, AdvDefaultLifetime MUST be set to a value greater than or equal to the selected MaxRtrAdvInterval. Otherwise, a router lifetime is guaranteed to expire before the new Router Advertisement has a chance to be sent, thereby creating an outage.
此外，AdvDefaultLifetime必须设置为大于或等于所选MaxRtrAdvInterval的值。否则，路由器生存期保证在新路由器广告有机会发送之前过期，从而造成中断。
This document updates Sections 4.2 and 6.2.1 of [RFC4861] to change the following router configuration variables.
本文件更新了[RFC4861]第4.2节和第6.2.1节，以更改以下路由器配置变量。
In Section 4.2, inside the paragraph that defines Router Lifetime, change 9000 to 65535 seconds.
在第4.2节中，在定义路由器寿命的段落中，将9000秒更改为65535秒。
In Section 6.2.1, inside the paragraph that defines MaxRtrAdvInterval, change 1800 to 65535 seconds.
在第6.2.1节中，在定义MaxRtrAdvInterval的段落内，将1800秒更改为65535秒。
In Section 6.2.1, inside the paragraph that defines AdvDefaultLifetime, change 9000 to 65535 seconds.
在第6.2.1节中，在定义AdvDefaultLifetime的段落内，将9000秒更改为65535秒。
As explained in Section 3, the probability of packet loss must be considered when choosing the relationship between MaxRtrAdvInterval and AdvDefaultLifetime.
如第3节所述，在选择MaxRtrAdvInterval和AdvDefaultLifetime之间的关系时，必须考虑数据包丢失的概率。
Legacy hosts on a link with updated routers may have issues with a Router Lifetime of more than 9000 seconds. In the few implementations we have tested with general-purpose operating systems, there does not seem to be any issue with setting this field to more than 9000, but there might be implementations that incorrectly reject such RAs (since RFC 4861 requires receivers to handle any value).
具有更新路由器的链路上的旧主机可能存在路由器寿命超过9000秒的问题。在我们使用通用操作系统测试的少数实现中，将此字段设置为9000以上似乎没有任何问题，但可能存在错误地拒绝此类RAs的实现（因为RFC 4861要求接收器处理任何值）。
On a link where Router Advertisements are few and far between, the detrimental effects of a rogue router that sends an unsolicited RA are greatly increased. These rogue RAs can be prevented by using approaches like RA-Guard [RFC6105] and SEcure Neighbor Discovery (SEND) [RFC3971].
在路由器广告很少的链路上，发送未经请求的RA的恶意路由器的有害影响会大大增加。通过使用RA Guard[RFC6105]和安全邻居发现（SEND）[RFC3971]等方法可以防止这些恶意RAs。
This document has no IANA actions.
本文档没有IANA操作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<https://www.rfc-editor.org/info/rfc4861>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 3971，DOI 10.17487/RFC3971，2005年3月<https://www.rfc-editor.org/info/rfc3971>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, <https://www.rfc-editor.org/info/rfc6105>.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 6105DOI 10.17487/RFC6105，2011年2月<https://www.rfc-editor.org/info/rfc6105>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.
[RFC6459]Korhonen，J.，Ed.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，DOI 10.17487/RFC6459，2012年1月<https://www.rfc-editor.org/info/rfc6459>.
[RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. Krishnan, "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, November 2013, <https://www.rfc-editor.org/info/rfc7066>.
[RFC7066]Korhonen，J.，Ed.，Arkko，J.，Ed.，Savolainen，T.，和S.Krishnan，“第三代合作伙伴关系项目（3GPP）蜂窝主机的IPv6”，RFC 7066，DOI 10.17487/RFC7066，2013年11月<https://www.rfc-editor.org/info/rfc7066>.
Acknowledgements
致谢
The authors would like to thank the members of the 6MAN efficient ND design team for their comments that led to the creation of this document. The authors would also like to thank Lorenzo Colitti, Erik Kline, Jeena Rachel John, Brian Carpenter, Tim Chown, Fernando Gont, Warren Kumari, and Adam Roach for their comments and suggestions that improved this document.
作者要感谢6MAN高效ND设计团队的成员，感谢他们的意见，这些意见促成了本文件的创建。作者还要感谢Lorenzo Coletti、Erik Kline、Jeena Rachel John、Brian Carpenter、Tim Chown、Fernando Gont、Warren Kumari和Adam Roach为改进本文件提出的意见和建议。
Authors' Addresses
作者地址
Suresh Krishnan Kaloom 335 Rue Peel Montreal, QC Canada
Suresh Krishnan Kaloom加拿大QC蒙特利尔皮尔街335号
Email: suresh@kaloom.com
Email: suresh@kaloom.com
Jouni Korhonen Nordic Semiconductor ASA Metsanneidonkuja 10 02130 Espoo Finland
Jouni Korhonen Nordic Semiconductor ASA Metsanneidonkuja 10 02130芬兰埃斯波
Email: jouni.nospam@gmail.com
Email: jouni.nospam@gmail.com
Samita Chakrabarti Verizon United States of America
Samita Chakrabarti Verizon美利坚合众国
Email: samita.chakrabarti@verizon.com
Email: samita.chakrabarti@verizon.com
Erik Nordmark Zededa Santa Clara, CA United States of America
Erik Nordmark Zededa Santa Clara，加利福尼亚州，美利坚合众国
Email: nordmark@acm.org
Email: nordmark@acm.org
Andrew Yourtchenko Cisco 6b de Kleetlaan Diegem 1831 Belgium
Andrew Yourtchenko Cisco 6b de Kleetlaan Diegem 1831比利时
Email: ayourtch@cisco.com
Email: ayourtch@cisco.com