idnits 2.17.1 draft-madanapalli-ipv6-periodic-rtr-advts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 260. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 4, 2006) is 6476 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-07 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Madanapalli 3 Internet-Draft LogicaCMG 4 Intended status: Standards Track B. Patil 5 Expires: February 5, 2007 Nokia 6 August 4, 2006 8 Recommendation to make periodic Router Advertisements in IPv6 optional 9 draft-madanapalli-ipv6-periodic-rtr-advts-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 5, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Periodic IPv6 router advertisements are a concern in mobile and 43 cellular networks in which the hosts are attached to the network and 44 access router but switch state to dormant mode in order to conserve 45 battery power. In addition the air interface is a resource that 46 should be used optimally and hence periodic router advertisements 47 that an access router would send should be limited. Transmission of 48 Periodic router advertisements to hosts on a link by a router should 49 be optional. At the very least the interval between such router 50 advertisements should be configurable to a value that is 51 significantly higher than currently specified. This document 52 provides a recommendation for the periodic router advertisement 53 interval (MaxRtrAdvInterval) and router lifetime. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Adverse effects of frequent Periodic RAs . . . . . . . . . . . 3 59 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 65 Intellectual Property and Copyright Statements . . . . . . . . . . 7 67 1. Introduction 69 [1] defines neighbor discovery procedures for IPv6 for router 70 discovery, prefix discovery, address resolution, neighbor 71 Unreachability detection and parameter discovery. [1] defines Router 72 Advertisements, which are sent either periodically or in response to 73 Router solicitations from a host. [1] recommends the interval between 74 periodic Router advertisements to be small enough such that the hosts 75 will be able to discover all routers on a link within the span of a 76 few minutes. 78 [1] also defines parameter values for various parameters. Two 79 specific parameters are considered within the scope of this document: 81 1. Router Lifetime during which a router acts as the default router 82 for a host. The current maximum recommended value for this 83 parameter is 150 minutes (9000 seconds). 85 2. MaxRtrAdvInterval: The maximum possible delay between two 86 consecutive periodic router advertisements. The current 87 recommended value is 30 minutes (1800 seconds). 89 Routers that implement the current recommendations would send the 90 periodic multicast router advertisements every 30 minutes, which can 91 be a significant problem in mobile/cellular network environments. 92 This document looks at the adverse effects of the current [1] 93 specification on mobile and cellular networks, resulting from 94 periodic multicast router advertisements and recommends that the 95 sending of such router advertisements be optional, i.e. it should be 96 possible to configure a router in specific environments or deployment 97 scenarios with periodic router advertisements switched off. 99 2. Adverse effects of frequent Periodic RAs 101 Mobile/cellular Networks like GPRS, 3G and WiMAX typically assign 102 long lived prefixes, and the default access routers (GGSN, PDSN, ASN 103 GW etc) for the hosts would typically be available for a long time on 104 a given link (possibly infinite). Generally there exists only one 105 default router at any given time on a given link for a host. The 106 host devices in these networks, i.e. the mobile nodes, have 107 constraints on battery power. To conserve battery life, mobile nodes 108 frequently enter idle or dormant mode. Typically a mobile node will 109 be in idle/dormant mode most of the time. 111 IPv6 capable mobile nodes that are attached to an access router and 112 are in idle/dormant mode will have to be awakened to deliver the 113 router advertisement. This incurs significant costs and has a 114 negative impact on the battery lifetime of such devices. The mobile 115 node has to be paged and switched to a state, which allows it to 116 receive the router advertisement. Additionally bandwidth over the 117 air interface is used for transmission of such packets. From an 118 operational perspective, the periodic router advertisement in mobile 119 networks is detrimental to optimal use of the radio resources as well 120 as impacting battery power in mobile devices. The transmission and 121 delivery of periodic router advertisements to a mobile node which is 122 in dormant/idle mode at the expense of paging, allocating radio 123 resources and establishing a connection to the host is unnecessary. 124 Router advertisement is useful at the MN if it relied on it as the 125 means to detect movement. However in many of the cellular networks, 126 movement detection is not done at the IP layer. If an MN needs a 127 router advertisement for any reason, it can always solicit for it. 128 And if the network needs to deliver a router advertisement to a host 129 to convey changes, it can do so as well without having to depend on 130 periodic RAs. 132 3. Recommendations 134 In order to optimize IPv6 behavior for deployment in mobile/cellular 135 environments this document recommends the following changes to the ND 136 [1] specification: 138 o The transmission of periodic router advertisements should be 139 optional. Access routers in mobile/cellular environments should 140 have the option of switching off the sending of periodic RAs to 141 hosts that are currently attached to the AR. The host served by 142 such an AR should not expect to receive unsolicited RAs. 144 o The maximum router lifetime be increased beyond the current max 145 value of 9000 seconds. 147 o The maximum value of the parameter MaxRtrAdvInterval be greater 148 than 1800 seconds. 150 The changes recommended to be made for ND are as follows: 152 1. Router Life Time: Allow the setting of this parameter in the 153 router advertisement to 65535. This would imply that the router 154 is available as the default router for infinity. This value can 155 be updated by the subsequent router advertisements with a 156 specific value. 158 2. MaxRtrAdvInterval: Allow the parameter to be configurable with a 159 value set to 0 (zero). This indicates that the periodic 160 multicast router advertisements are switched off on this 161 interface. In case no value is specified for this parameter, 162 then the MaxRtrAdvInterval should be computed as indicated below: 164 MaxRtrAdvInterval = 0.33 * min of {Router Lifetime, Prefix 165 lifetime} 166 This allows a host to receive three router advertisements 167 before either Router Lifetime, or Prefix lifetime expires so 168 that if there is any pocket loss in transmission it can be 169 alleviated. 171 3. Recommend that mobile nodes proactively solicit router 172 advertisements in any of the following cases: 174 The threshold of the router lifetime is 0.75 * 175 AdvDefaultLifetime and is triggered. 177 The threshold of the prefix lifetime is 0.75 * 178 AdvValidLifetime and is triggered. 180 4. Security Considerations 182 This document specifies a few amendments to the [1] and does not 183 introduce any new security threats. To reduce the threats associated 184 with ND it is recommended that deployments use SeND [2] to secure 185 neighbor discovery messages. 187 5. IANA Considerations 189 This document has no actions for IANA. 191 6. Acknowledgements 193 TBD 195 7. References 197 [1] "Neighbor Discovery for IP version 6 (IPv6), 198 draft-ietf-ipv6-2461bis-07.txt(work in progress)", May 2006. 200 [2] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 201 Neighbor Discovery (SEND)", RFC 3971, March 2005. 203 Authors' Addresses 205 Syam Madanapalli 206 LogicaCMG 207 125 Yemlur Main Road 208 Off Airport Road 209 Bangalore 560037 210 India 212 Email: smadanapalli at gmail dot com 214 Basavaraj Patil 215 Nokia 216 6000 Connection Drive 217 Irving, TX 75039 218 USA 220 Email: basavaraj.patil@nokia.com 222 Full Copyright Statement 224 Copyright (C) The Internet Society (2006). 226 This document is subject to the rights, licenses and restrictions 227 contained in BCP 78, and except as set forth therein, the authors 228 retain all their rights. 230 This document and the information contained herein are provided on an 231 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 232 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 233 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 234 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 235 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 236 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 238 Intellectual Property 240 The IETF takes no position regarding the validity or scope of any 241 Intellectual Property Rights or other rights that might be claimed to 242 pertain to the implementation or use of the technology described in 243 this document or the extent to which any license under such rights 244 might or might not be available; nor does it represent that it has 245 made any independent effort to identify any such rights. Information 246 on the procedures with respect to rights in RFC documents can be 247 found in BCP 78 and BCP 79. 249 Copies of IPR disclosures made to the IETF Secretariat and any 250 assurances of licenses to be made available, or the result of an 251 attempt made to obtain a general license or permission for the use of 252 such proprietary rights by implementers or users of this 253 specification can be obtained from the IETF on-line IPR repository at 254 http://www.ietf.org/ipr. 256 The IETF invites any interested party to bring to its attention any 257 copyrights, patents or patent applications, or other proprietary 258 rights that may cover technology that may be required to implement 259 this standard. Please address the information to the IETF at 260 ietf-ipr@ietf.org. 262 Acknowledgment 264 Funding for the RFC Editor function is provided by the IETF 265 Administrative Support Activity (IASA).