idnits 2.17.1 draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2, 2015) is 3129 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 238 -- Looks like a reference, but probably isn't: '2' on line 240 == Missing Reference: 'RFC6104' is mentioned on line 214, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations A. Yourtchenko 3 Internet-Draft Cisco 4 Intended status: Best Current Practice L. Colitti 5 Expires: April 4, 2016 Google 6 October 2, 2015 8 Reducing energy consumption of Router Advertisements 9 draft-ietf-v6ops-reducing-ra-energy-consumption-02 11 Abstract 13 Frequent Router Advertisement messages can severely impact host power 14 consumption. This document recommends operational practices to avoid 15 such impact. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 4, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Problem scenarios . . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Solicited multicast RAs on large networks . . . . . . . . 2 54 2.2. Frequent periodic Router Advertisements . . . . . . . . . 3 55 3. Consequences . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Router Advertisement frequency . . . . . . . . . . . . . . . 3 57 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Network-side recommendations . . . . . . . . . . . . . . 4 59 5.2. Device-side recommendations . . . . . . . . . . . . . . . 5 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 Routing information is communicated to IPv6 hosts by Router 71 Advertisement (RA) messages [RFC4861]. If these messages are too 72 frequent, they can severely impact power consumption on battery- 73 powered hosts. 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Problem scenarios 81 2.1. Solicited multicast RAs on large networks 83 On links with a large number of battery-powered devices, sending 84 solicited Router Advertisements multicast can severely impact host 85 power consumption. This is because every time a device joins the 86 network, all devices on the network receive a multicast Router 87 Advertisement. In the worst case, if devices are continually joining 88 and leaving the network, and the network is large enough, then all 89 devices on the network will receive solicited Router Advertisements 90 at the maximum rate specified by section 6.2.6 of [RFC4861], which is 91 one every 3 seconds. 93 2.2. Frequent periodic Router Advertisements 95 Some networks send periodic multicast Router Advertisements very 96 frequently (e.g., once every few seconds). This may be due to a 97 desire to ensure that hosts always have access to up-to-date router 98 information. This has severe impact on battery life. 100 3. Consequences 102 Observed reactions to frequent Router Advertisement messages by 103 battery-powered devices include: 105 o Some hosts simply experience bad battery life on these networks 106 and otherwise operate normally. This is frustrating for users of 107 these networks. 109 o Some hosts react by dropping all Router Advertisement messages 110 when in power saving mode on any network, e.g., [1]. This causes 111 devices to lose connectivity when in power-saving mode, 112 potentially disrupting background network communications, because 113 the device is no longer able to send packets or acknowledge 114 received traffic. 116 o Some hosts react by dropping *all* IPv6 packets when in power 117 saving mode, [2]. This disrupts network communications. 119 Compounding the problem, when dealing with devices that drop Router 120 Advertisements when in power saving mode, some network administrators 121 work around the problem by sending RAs even more frequently. This 122 causes devices to engage in even more aggressive filtering. 124 4. Router Advertisement frequency 126 The appropriate frequency of periodic RAs depends on how constrained 127 the network devices are. 129 o Laptop-class devices will likely experience no noticeable battery 130 life impact even if RAs are sent every few seconds. 132 o Tablets, phones, and watches experience it more noticeably. At 133 the time of writing, current-generation devices might consume on 134 the order of 5 mA when the main processor is asleep. Upon 135 receiving a packet, they might consume on the order of 200 mA for 136 250ms, as the packet causes the main processor to wake up, process 137 the RA, attend to other pending tasks, and then go back to sleep 138 again. Thus, on such devices the cost of receiving one RA will be 139 approximately 0.014mAh. 141 In order to limit the amount of power used to receive Router 142 Advertisements to, say, 2% of idle power (i.e., to impact idle 143 battery life by no more than 2%), the average power budget for 144 receiving RAs must be no more than 0.1mA, or approximately 7 RAs 145 per hour. Due to background multicast loss and the tendency of 146 current devices to rate-limit multicast when asleep, many of these 147 RAs might not reach the device. Thus the minimum lifetimes for RA 148 configuration parameters such as default router lifetime might 149 reasonably be 5-10 times the RA period, or roughly 45-90 minutes. 151 An idle time impact of 2% relative to measured idle current is 152 negligible, since on this sort of device average power consumption 153 is typically much higher than idle power consumption. 155 o Specialized devices in non-general-purpose networks such as sensor 156 networks might have tighter requirements. In these environments, 157 even longer RA intervals might be appropriate. 159 5. Recommendations 161 5.1. Network-side recommendations 163 1. Router manufacturers SHOULD allow network administrators to 164 configure the routers to respond to Router Solicitations with 165 unicast Router Advertisements if: 167 * The Router Solicitation's source address is not the 168 unspecified address, and: 170 * The solicitation contains a valid Source Link-Layer Address 171 option. 173 2. Administrators of networks that serve large numbers (tens or 174 hundreds) of battery-powered devices SHOULD enable this 175 behaviour. 177 3. Networks that serve battery-powered devices SHOULD NOT send 178 multicast RAs too frequently (see section Section 4) unless the 179 information in the RA packet has substantially changed. If there 180 is a desire to ensure that hosts pick up configuration changes 181 quickly, those networks MAY send frequent Router Advertisements 182 for a limited period of time (e.g., not more than one minute) 183 immediately after a configuration change. 185 No protocol changes are required. Responding to Router Solicitations 186 with unicast Router Advertisements is already allowed by section 187 6.2.6 of [RFC4861], and Router Advertisement intervals are already 188 configurable by the administrator to a wide range of values. 190 5.2. Device-side recommendations 192 1. Mobile devices that intend to maintain IPv6 connectivity while 193 asleep MUST NOT ignore RAs while asleep. 195 2. Mobile devices that do not intend to maintain IPv6 connectivity 196 while asleep SHOULD disconnect from the IPv6 network and SHOULD 197 reconnect to the network (including performing any DNAv6 198 procedures [RFC6059], sending Router Solicitations and performing 199 Duplicate Address Detection) when waking up. 201 6. Acknowledgements 203 The authors wish to thank Steven Barth, Frank Bulk, David Farmer, Ray 204 Hunter, Erik Kline, Erik Nordmark, Alexandru Petrescu, Libor Polcak, 205 Mark Smith, and Jinmei Tatuya for feedback and helpful suggestions. 207 7. IANA Considerations 209 None. 211 8. Security Considerations 213 Misconfigured or malicious hosts sending rogue Router Advertisements 214 [RFC6104] can also severely impact power consumption on battery- 215 powered hosts if they send a significant number of such messages. 216 Any IPv6 network where there is potential for misconfigured or 217 malicious hosts should take appropriate countermeasures to mitigate 218 the problem. 220 9. References 222 9.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 228 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 229 September 2007. 231 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 232 Detecting Network Attachment in IPv6", RFC 6059, DOI 10 233 .17487/RFC6059, November 2010, 234 . 236 9.2. URIs 238 [1] https://code.google.com/p/android/issues/detail?id=32662 240 [2] http://www.gossamer-threads.com/lists/nsp/ipv6/54641 242 Authors' Addresses 244 Andrew Yourtchenko 245 Cisco 246 7a de Kleetlaan 247 Diegem, 1831 248 Belgium 250 Phone: +32 2 704 5494 251 Email: ayourtch@cisco.com 253 Lorenzo Colitti 254 Google 255 Roppongi 6-10-1 256 Minato, Tokyo 106-6126 257 JP 259 Email: lorenzo@google.com