idnits 2.17.00 (12 Aug 2021) /tmp/idnits50930/draft-ietf-v6ops-reducing-ra-energy-consumption-03.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 (November 5, 2015) is 2382 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) == Missing Reference: 'RFC6104' is mentioned on line 224, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: May 8, 2016 Google 6 November 5, 2015 8 Reducing energy consumption of Router Advertisements 9 draft-ietf-v6ops-reducing-ra-energy-consumption-03 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 May 8, 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 . . . . . . . . . 2 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. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Routing information is communicated to IPv6 hosts by Router 69 Advertisement (RA) messages [RFC4861]. If these messages are too 70 frequent, they can severely impact power consumption on battery- 71 powered hosts. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Problem scenarios 79 2.1. Solicited multicast RAs on large networks 81 On links with a large number of battery-powered devices, sending 82 solicited Router Advertisements multicast can severely impact host 83 power consumption. This is because every time a device joins the 84 network, all devices on the network receive a multicast Router 85 Advertisement. In the worst case, if devices are continually joining 86 and leaving the network, and the network is large enough, then all 87 devices on the network will receive solicited Router Advertisements 88 at the maximum rate specified by section 6.2.6 of [RFC4861], which is 89 one every 3 seconds. 91 2.2. Frequent periodic Router Advertisements 93 Some networks send periodic multicast Router Advertisements very 94 frequently (e.g., once every few seconds). This may be due to a 95 desire to minimize customer impact of network renumbering events, 96 which in some large residential networks occur relatively frequently. 98 In the presence of hosts that ignore RAs or even all IPv6 packets 99 when in sleep mode, such networks may see a need to send RAs 100 frequently in order to avoid leaving devices with non-functional IPv6 101 configurations for extended periods of time. Unfortunately, this has 102 severe impact on battery life. 104 3. Consequences 106 Observed reactions to frequent Router Advertisement messages by 107 battery-powered devices include: 109 o Some hosts simply experience bad battery life on these networks 110 and otherwise operate normally. This is frustrating for users of 111 these networks. 113 o Some hosts react by dropping all Router Advertisement messages 114 when in power saving mode on any network, e.g., 115 . This 116 causes devices to lose connectivity when in power-saving mode, 117 potentially disrupting background network communications, because 118 the device is no longer able to send packets or acknowledge 119 received traffic. 121 o Some hosts react by dropping *all* IPv6 packets when in power 122 saving mode, . This disrupts network communications. 125 Compounding the problem, when dealing with devices that drop Router 126 Advertisements when in power saving mode, some network administrators 127 work around the problem by sending RAs even more frequently. This 128 causes devices to engage in even more aggressive filtering. 130 4. Router Advertisement frequency 132 The appropriate frequency of periodic RAs depends on how constrained 133 the network devices are. 135 o Laptop-class devices will likely experience no noticeable battery 136 life impact even if RAs are sent every few seconds. 138 o Tablets, phones, and watches experience it more noticeably. At 139 the time of writing, current-generation devices might consume on 140 the order of 5 mA when the main processor is asleep. Upon 141 receiving a packet, they might consume on the order of 200 mA for 142 250ms, as the packet causes the main processor to wake up, process 143 the RA, attend to other pending tasks, and then go back to sleep 144 again. Thus, on such devices the cost of receiving one RA will be 145 approximately 0.014mAh. 147 In order to limit the amount of power used to receive Router 148 Advertisements to, say, 2% of idle power (i.e., to impact idle 149 battery life by no more than 2%), the average power budget for 150 receiving RAs must be no more than 0.1mA, or approximately 7 RAs 151 per hour. Due to background multicast loss and the tendency of 152 current devices to rate-limit multicast when asleep, many of these 153 RAs might not reach the device. Thus the minimum lifetimes for RA 154 configuration parameters such as default router lifetime might 155 reasonably be 5-10 times the RA period, or roughly 45-90 minutes. 157 An idle time impact of 2% relative to measured idle current is 158 negligible, since on this sort of device average power consumption 159 is typically much higher than idle power consumption. 161 o Specialized devices in non-general-purpose networks such as sensor 162 networks might have tighter requirements. In these environments, 163 even longer RA intervals might be appropriate. 165 5. Recommendations 167 5.1. Network-side recommendations 169 1. Router manufacturers SHOULD allow network administrators to 170 configure the routers to respond to Router Solicitations with 171 unicast Router Advertisements if: 173 * The Router Solicitation's source address is not the 174 unspecified address, and: 176 * The solicitation contains a valid Source Link-Layer Address 177 option. 179 2. Administrators of networks that serve large numbers (tens or 180 hundreds) of battery-powered devices SHOULD enable this 181 behaviour. 183 3. Networks that serve battery-powered devices SHOULD NOT send 184 multicast RAs too frequently (see section Section 4) unless the 185 information in the RA packet has substantially changed. If there 186 is a desire to ensure that hosts pick up configuration changes 187 quickly, those networks MAY send frequent Router Advertisements 188 for a limited period of time (e.g., not more than one minute) 189 immediately after a configuration change. 191 No protocol changes are required. Responding to Router Solicitations 192 with unicast Router Advertisements is already allowed by section 193 6.2.6 of [RFC4861], and Router Advertisement intervals are already 194 configurable by the administrator to a wide range of values. 196 5.2. Device-side recommendations 198 1. Maintaining IPv6 connectivity requires that hosts be able to 199 receive periodic multicast RAs [RFC4861] Therefore, hosts that 200 process unicast packets sent while they are asleep MUST also 201 process multicast RAs sent while they are asleep. Battery- 202 powered hosts MAY rate-limit identical RAs if they are sent too 203 frequently. 205 2. Battery-powered devices that do not intend to maintain IPv6 206 connectivity while asleep SHOULD either disconnect from the 207 network, abandoning all IPv6 configuration on that network, or 208 perform DNAv6 procedures [RFC6059] when waking up. 210 6. Acknowledgements 212 The authors wish to thank Steven Barth, Frank Bulk, David Farmer, 213 Igor Gashinsky, Ray Hunter, Erik Kline, Erik Nordmark, Alexandru 214 Petrescu, Libor Polcak, Mark Smith, Jinmei Tatuya and James Woodyatt 215 for feedback and helpful suggestions. 217 7. IANA Considerations 219 None. 221 8. Security Considerations 223 Misconfigured or malicious hosts sending rogue Router Advertisements 224 [RFC6104] can also severely impact power consumption on battery- 225 powered hosts if they send a significant number of such messages. 226 Any IPv6 network where there is potential for misconfigured or 227 malicious hosts should take appropriate countermeasures to mitigate 228 the problem. 230 9. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 234 RFC2119, March 1997, 235 . 237 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 238 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 239 DOI 10.17487/RFC4861, September 2007, 240 . 242 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 243 Detecting Network Attachment in IPv6", RFC 6059, DOI 244 10.17487/RFC6059, November 2010, 245 . 247 Authors' Addresses 249 Andrew Yourtchenko 250 Cisco 251 7a de Kleetlaan 252 Diegem, 1831 253 Belgium 255 Phone: +32 2 704 5494 256 Email: ayourtch@cisco.com 258 Lorenzo Colitti 259 Google 260 Roppongi 6-10-1 261 Minato, Tokyo 106-6126 262 JP 264 Email: lorenzo@google.com