Internet Engineering Task Force (IETF) A. Yourtchenko
Request for Comments: 7772 Cisco
BCP: 202 L. Colitti
Category: Best Current Practice Google
ISSN: 2070-1721 February 2016
Internet Engineering Task Force (IETF) A. Yourtchenko
Request for Comments: 7772 Cisco
BCP: 202 L. Colitti
Category: Best Current Practice Google
ISSN: 2070-1721 February 2016
Reducing Energy Consumption of Router Advertisements
降低路由器广告的能耗
Abstract
摘要
Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.
频繁的路由器广告消息会严重影响主机功耗。本文件建议了避免此类影响的操作实践。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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 BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc7772.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7772.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Solicited Multicast RAs on Large Networks . . . . . . . . 2
2.2. Frequent Periodic Router Advertisements . . . . . . . . . 3
3. Consequences . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Router Advertisement Frequency . . . . . . . . . . . . . . . 3
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Network-Side Recommendations . . . . . . . . . . . . . . 4
5.2. Device-Side Recommendations . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Solicited Multicast RAs on Large Networks . . . . . . . . 2
2.2. Frequent Periodic Router Advertisements . . . . . . . . . 3
3. Consequences . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Router Advertisement Frequency . . . . . . . . . . . . . . . 3
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Network-Side Recommendations . . . . . . . . . . . . . . 4
5.2. Device-Side Recommendations . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
Routing information is communicated to IPv6 hosts by Router Advertisement (RA) messages [RFC4861]. If these messages are sent too frequently, they can severely impact power consumption on battery-powered hosts.
路由信息通过路由器广告（RA）消息传送到IPv6主机[RFC4861]。如果这些消息发送过于频繁，可能会严重影响电池供电主机的功耗。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
On links with a large number of battery-powered devices, sending solicited multicast Router Advertisements can severely impact host power consumption. This is because every time a device joins the network, all devices on the network receive a multicast Router Advertisement. In the worst case, if devices are continually joining and leaving the network, and the network is large enough, then all devices on the network will receive solicited Router Advertisements at the maximum rate specified by Section 6.2.6 of [RFC4861], which is one every 3 seconds.
在具有大量电池供电设备的链路上，发送请求的多播路由器广告可能会严重影响主机功耗。这是因为每次设备加入网络时，网络上的所有设备都会收到多播路由器广告。在最坏的情况下，如果设备持续加入和离开网络，并且网络足够大，则网络上的所有设备将以[RFC4861]第6.2.6节规定的最大速率接收请求的路由器广告，即每3秒一次。
Some networks send periodic multicast Router Advertisements very frequently (e.g., once every few seconds). This may be due to a desire to minimize customer impact of network renumbering events, which in some large residential networks occur relatively frequently. In the presence of hosts that ignore RAs or even all IPv6 packets when in sleep mode, such networks may see a need to send RAs frequently in order to avoid leaving devices with non-functional IPv6 configurations for extended periods of time. Unfortunately, this has severe impact on battery life.
一些网络非常频繁地发送周期性多播路由器广告（例如，每隔几秒钟发送一次）。这可能是由于希望将网络重新编号事件对客户的影响降至最低，而在一些大型住宅网络中，重新编号事件相对频繁。当主机在睡眠模式下忽略RAs甚至所有IPv6数据包时，此类网络可能需要频繁发送RAs，以避免设备长时间处于非功能性IPv6配置。不幸的是，这严重影响了电池寿命。
Observed effects of frequently sending Router Advertisement messages to battery-powered devices include:
频繁向电池供电设备发送路由器广告消息的观察效果包括：
o Some hosts simply experience bad battery life on these networks and otherwise operate normally. This is frustrating for users of these networks.
o 有些主机在这些网络上的电池寿命很短，因此运行正常。这让这些网络的用户感到沮丧。
o Some hosts react by dropping all Router Advertisement messages when in power-saving mode on any network, e.g., <https://code.google.com/p/android/issues/detail?id=32662>. This causes devices to lose connectivity when in power-saving mode, potentially disrupting background network communications, because the device is no longer able to send packets or acknowledge received traffic.
o 某些主机在任何网络上处于节能模式时会丢弃所有路由器广告消息，例如<https://code.google.com/p/android/issues/detail?id=32662>. 这会导致设备在省电模式下失去连接，可能会中断后台网络通信，因为设备不再能够发送数据包或确认收到的流量。
o Some hosts react by dropping *all* IPv6 packets when in power-saving mode, <http://www.gossamer-threads.com/lists/nsp/ ipv6/54641>. This disrupts network communications.
o 某些主机在省电模式下会丢弃*所有*IPv6数据包<http://www.gossamer-threads.com/lists/nsp/ ipv6/54641>。这会中断网络通信。
Compounding the problem, when dealing with devices that drop Router Advertisements when in power saving mode, some network administrators work around the problem by sending RAs even more frequently. This causes devices to engage in even more aggressive filtering.
使问题更加复杂的是，当处理在省电模式下丢弃路由器广告的设备时，一些网络管理员通过更频繁地发送RAs来解决问题。这会导致设备进行更积极的过滤。
The appropriate frequency of periodic RAs depends on how constrained the network devices are.
周期性RAs的适当频率取决于网络设备的约束程度。
o Laptop-class devices will likely experience no noticeable battery-life impact, even if RAs are sent every few seconds.
o 笔记本类设备可能不会受到明显的电池寿命影响，即使RAs每隔几秒钟发送一次。
o Tablets, phones, and watches experience it more noticeably. At the time of writing, current-generation devices might consume on the order of 5 mA when the main processor is asleep. Upon receiving a packet, they might consume on the order of 200 mA for 250 ms, as the packet causes the main processor to wake up, process the RA, attend to other pending tasks, and then go back to sleep. Thus, on such devices, the cost of receiving one RA will be approximately 0.014 mAh.
o 平板电脑、手机和手表的体验更为显著。在写入时，当主处理器处于休眠状态时，电流生成设备可能消耗约5 mA的电流。在接收到数据包时，它们可能会消耗大约200 mA，持续250 ms，因为数据包会导致主处理器醒来，处理RA，处理其他挂起的任务，然后返回睡眠状态。因此，在此类设备上，接收一个RA的成本约为0.014 mAh。
In order to limit the amount of power used to receive Router Advertisements to, say, 2% of idle power (i.e., to impact idle battery life by no more than 2%), the average power budget for receiving RAs must be no more than 0.1 mA, or approximately 7 RAs per hour. Due to background multicast loss and the tendency of current devices to rate-limit multicast when asleep, many of these RAs might not reach the device. Thus, the minimum lifetimes for RA configuration parameters such as default router lifetime might reasonably be 5-10 times the RA period, or roughly 45-90 minutes.
为了将用于接收路由器广告的功率限制在空闲功率的2%（即，影响空闲电池寿命不超过2%），接收RAs的平均功率预算不得超过0.1 mA，或约为每小时7 RAs。由于背景多播丢失和当前设备在睡眠时限制多播速率的趋势，许多RAs可能无法到达设备。因此，RA配置参数（如默认路由器寿命）的最短寿命可能是RA周期的5-10倍，或者大约45-90分钟。
An impact of 2% relative to measured idle current is negligible, since on this sort of device average power consumption is typically much higher than idle power consumption.
相对于测量的空闲电流，2%的影响可以忽略不计，因为在这种设备上，平均功耗通常远高于空闲功耗。
o Specialized devices in non-general-purpose networks such as sensor networks might have tighter requirements. In these environments, even longer RA intervals might be appropriate.
o 非通用网络（如传感器网络）中的专用设备可能有更严格的要求。在这些环境中，甚至更长的RA间隔可能是合适的。
1. Router manufacturers SHOULD allow network administrators to configure the routers to respond to Router Solicitations with unicast Router Advertisements if:
1. 路由器制造商应允许网络管理员配置路由器，以便在以下情况下使用单播路由器广告响应路由器请求：
* The Router Solicitation's source address is not the unspecified address, and:
* 路由器请求的源地址不是未指定的地址，并且：
* The solicitation contains a valid Source Link-Layer Address option.
* 请求包含有效的源链接层地址选项。
2. Administrators of networks that serve large numbers (tens or hundreds) of battery-powered devices SHOULD enable this behavior.
2. 为大量（数十或数百）电池供电设备提供服务的网络管理员应启用此行为。
3. Networks that serve battery-powered devices SHOULD NOT send multicast RAs too frequently (see Section 4) unless the information in the RA packet has substantially changed. If there is a desire to ensure that hosts pick up configuration changes
3. 为电池供电设备提供服务的网络不应过于频繁地发送多播RAs（参见第4节），除非RA数据包中的信息发生了实质性变化。如果希望确保主机接受配置更改
quickly, those networks MAY send frequent Router Advertisements for a limited period of time (e.g., not more than one minute) immediately after a configuration change.
很快，这些网络可以在配置更改后立即在有限的时间段（例如，不超过一分钟）内频繁发送路由器广告。
No protocol changes are required. Responding to Router Solicitations with unicast Router Advertisements is already allowed by Section 6.2.6 of [RFC4861], and Router Advertisement intervals are already configurable by the administrator to a wide range of values.
不需要更改协议。[RFC4861]第6.2.6节已经允许使用单播路由器播发响应路由器请求，并且管理员已经可以将路由器播发间隔配置为一系列值。
1. Maintaining IPv6 connectivity requires that hosts be able to receive periodic multicast RAs [RFC4861]. Therefore, hosts that process unicast packets sent while they are asleep MUST also process multicast RAs sent while they are asleep. Battery-powered hosts MAY rate-limit identical RAs if they are sent too frequently.
1. 维护IPv6连接要求主机能够接收定期多播RAs[RFC4861]。因此，处理睡眠时发送的单播数据包的主机也必须处理睡眠时发送的多播RAs。如果发送频率过高，电池供电的主机可能会对相同的RAs进行速率限制。
2. Battery-powered devices that do not intend to maintain IPv6 connectivity while asleep SHOULD either disconnect from the network, abandoning all IPv6 configuration on that network, or perform Detecting Network Attachment in IPv6 (DNAv6) procedures [RFC6059] when waking up.
2. 如果电池供电的设备在睡眠时不打算保持IPv6连接，则应断开与网络的连接，放弃该网络上的所有IPv6配置，或者在醒来时执行IPv6（DNAv6）过程[RFC6059]中的网络连接检测。
Misconfigured or malicious hosts sending rogue Router Advertisements [RFC6104] can also severely impact power consumption on battery-powered hosts if they send a significant number of such messages. Any IPv6 network where there is potential for misconfigured or malicious hosts should take appropriate countermeasures to mitigate the problem.
发送恶意路由器广告[RFC6104]的配置错误或恶意主机如果发送大量此类消息，也会严重影响电池供电主机的功耗。任何可能存在错误配置或恶意主机的IPv6网络都应采取适当的对策来缓解问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://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, <http://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月<http://www.rfc-editor.org/info/rfc4861>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <http://www.rfc-editor.org/info/rfc6059>.
[RFC6059]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，RFC 6059，DOI 10.17487/RFC6059，2010年11月<http://www.rfc-editor.org/info/rfc6059>.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, DOI 10.17487/RFC6104, February 2011, <http://www.rfc-editor.org/info/rfc6104>.
[RFC6104]Chown，T.和S.Venaas，“流氓IPv6路由器广告问题声明”，RFC 6104，DOI 10.17487/RFC6104，2011年2月<http://www.rfc-editor.org/info/rfc6104>.
Acknowledgements
致谢
The authors wish to thank Steven Barth, Frank Bulk, David Farmer, Igor Gashinsky, Ray Hunter, Erik Kline, Erik Nordmark, Alexandru Petrescu, Libor Polcak, Mark Smith, Jinmei Tatuya, and James Woodyatt for feedback and helpful suggestions.
作者希望感谢史蒂文·巴特、弗兰克·伯克、大卫·法默、伊戈尔·加辛斯基、雷·亨特、埃里克·克莱恩、埃里克·诺德马克、亚历山德鲁·彼得雷斯库、利伯尔·波尔卡克、马克·史密斯、金美·塔图亚和詹姆斯·伍迪亚特的反馈和有益建议。
Authors' Addresses
作者地址
Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem, 1831 Belgium
Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem，1831比利时
Phone: +32 2 704 5494
Email: ayourtch@cisco.com
Phone: +32 2 704 5494
Email: ayourtch@cisco.com
Lorenzo Colitti Google Roppongi 6-10-1 Minato, Tokyo 106-6126 Japan
洛伦佐·科利蒂谷歌六本木6-10-1日本东京米纳托106-6126
Email: lorenzo@google.com
Email: lorenzo@google.com