diff options
Diffstat (limited to 'doc/rfc/rfc7772.txt')
| -rw-r--r-- | doc/rfc/rfc7772.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc7772.txt b/doc/rfc/rfc7772.txt new file mode 100644 index 0000000..2625ec4 --- /dev/null +++ b/doc/rfc/rfc7772.txt @@ -0,0 +1,339 @@ + + + + + + +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. + + 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. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + + + + + + + +Yourtchenko & Colitti Best Current Practice [Page 1] + +RFC 7772 Reducing RA Energy Consumption February 2016 + + +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 + + 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. + + 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]. + +2. Problem Scenarios + +2.1. Solicited Multicast RAs on Large Networks + + 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. + + + + + + + + + +Yourtchenko & Colitti Best Current Practice [Page 2] + +RFC 7772 Reducing RA Energy Consumption February 2016 + + +2.2. Frequent Periodic Router Advertisements + + 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. + +3. Consequences + + 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 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 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. + + 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. + +4. Router Advertisement Frequency + + The appropriate frequency of periodic RAs depends on how constrained + the network devices are. + + o Laptop-class devices will likely experience no noticeable battery- + life impact, even if RAs are sent every few seconds. + + + + + + +Yourtchenko & Colitti Best Current Practice [Page 3] + +RFC 7772 Reducing RA Energy Consumption February 2016 + + + 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. + + 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. + + 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. + + 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. + +5. Recommendations + +5.1. Network-Side Recommendations + + 1. Router manufacturers SHOULD allow network administrators to + configure the routers to respond to Router Solicitations with + unicast Router Advertisements if: + + * 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. + + 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 + + + +Yourtchenko & Colitti Best Current Practice [Page 4] + +RFC 7772 Reducing RA Energy Consumption February 2016 + + + 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. + +5.2. Device-Side Recommendations + + 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. + + 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. + +6. Security Considerations + + 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. + +7. References + +7.1. Normative References + + [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>. + + [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>. + + + + + +Yourtchenko & Colitti Best Current Practice [Page 5] + +RFC 7772 Reducing RA Energy Consumption February 2016 + + + [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>. + +7.2. Informative References + + [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>. + +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 + + Phone: +32 2 704 5494 + Email: ayourtch@cisco.com + + + Lorenzo Colitti + Google + Roppongi 6-10-1 + Minato, Tokyo 106-6126 + Japan + + Email: lorenzo@google.com + + + + + + + + + + + + + + +Yourtchenko & Colitti Best Current Practice [Page 6] + |