idnits 2.17.1 draft-yc-v6ops-solicited-ra-unicast-01.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 (July 22, 2015) is 3200 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 175 -- Looks like a reference, but probably isn't: '2' on line 177 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: January 23, 2016 Google 6 July 22, 2015 8 Reducing battery impact of Router Advertisements 9 draft-yc-v6ops-solicited-ra-unicast-01 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 January 23, 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. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 Routing information is communicated to IPv6 hosts by Router 68 Advertisement messages. If these messages are too frequent, they can 69 severely impact power consumption on battery-powered hosts. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Problem scenarios 77 2.1. Solicited multicast RAs on large networks 79 On links with a large number of battery-powered devices, sending 80 solicited Router Advertisements multicast can severely impact host 81 power consumption. This is because every time a device joins the 82 network, all devices on the network receive a multicast Router 83 Advertisement. In the worst case, if devices are continually joining 84 and leaving the network, and the network is large enough, then all 85 devices on the network will receive solicited Router Advertisements 86 at the maximum rate specified by section 6.2.6 of [RFC4861], which is 87 one every 3 seconds. 89 2.2. Frequent periodic Router Advertisements 91 Some networks send periodic multicast Router Advertisements (e.g., 92 once every few seconds). This may be due to a desire to ensure that 93 hosts always have access to up-to-date router information. 95 3. Consequences 97 Observed reactions to frequent Router Advertisement messages by 98 battery-powered devices include: 100 o Some hosts simply experience bad battery life on these networks 101 and otherwise operate normally. This is frustrating for users of 102 these networks. 104 o Some hosts react by dropping all Router Advertisement messages 105 when in power saving mode on any network, e.g., [1]. This causes 106 devices to lose connectivity when in power-saving mode, 107 potentially disrupting background network communications, because 108 the device is no longer able to send packets or acknowledge 109 received traffic. 111 o Some hosts react by dropping *all* IPv6 packets when in power 112 saving mode, [2]. This disrupts network communications. 114 Compounding the problem, when dealing with devices that drop Router 115 Advertisements when in power saving mode, some network administrators 116 work around the problem by sending RAs even more frequently. This 117 causes devices to engage in even more aggressive filtering. 119 4. Recommendations 121 1. Router manufacturers SHOULD allow network administrators to 122 configure the routers to respond to with unicast Router 123 Advertisements to Router Solicitations if: 125 * The Router Solicitation's source address is not the 126 unspecified address, and: 128 * The solicitation contains a valid Source Link-Layer Address 129 option. 131 2. Networks that serve large numbers (tens or hundreds) of battery- 132 powered devices SHOULD enable this behaviour. 134 3. Networks that serve battery-powered devices SHOULD NOT send 135 multicast RAs too frequently (e.g., more than one every 5-10 136 minutes for current battery-powered devices) unless the 137 information in the RA packet has substantially changed. If there 138 is a desire to ensure that hosts pick up configuration changes 139 quickly, those networks MAY send frequent Router Advertisements 140 for a limited period of time (e.g., not more than one minute) 141 immediately after a configuration change. 143 No protocol changes are required. Responding to Router Solicitations 144 with unicast Router Advertisements is already allowed by section 145 6.2.6 of [RFC4861], and Router Advertisement intervals are already 146 configurable by the administrator to a wide range of values. 148 5. Acknowledgements 150 The authors wish to thank Steven Barth, Erik Kline, Erik Nordmark, 151 Alexandru Petrescu, and Mark Smith for feedback and helpful 152 suggestions. 154 6. IANA Considerations 156 None. 158 7. Security Considerations 160 None. 162 8. References 164 8.1. Normative References 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, March 1997. 169 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 170 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 171 September 2007. 173 8.2. URIs 175 [1] https://code.google.com/p/android/issues/detail?id=32662 177 [2] http://www.gossamer-threads.com/lists/nsp/ipv6/54641 179 Authors' Addresses 181 Andrew Yourtchenko 182 cisco 183 7a de Kleetlaan 184 Diegem, 1831 185 Belgium 187 Phone: +32 2 704 5494 188 Email: ayourtch@cisco.com 189 Lorenzo Colitti 190 Google 191 Roppongi 6-10-1 192 Minato, Tokyo 106-6126 193 JP 195 Email: lorenzo@google.com