Network Working Group S. Madanapalli Internet-Draft LogicaCMG Intended status: Standards Track B. Patil Expires: February 5, 2007 Nokia August 4, 2006 Recommendation to make periodic Router Advertisements in IPv6 optional draft-madanapalli-ipv6-periodic-rtr-advts-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 5, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Periodic IPv6 router advertisements are a concern in mobile and cellular networks in which the hosts are attached to the network and access router but switch state to dormant mode in order to conserve battery power. In addition the air interface is a resource that should be used optimally and hence periodic router advertisements that an access router would send should be limited. Transmission of Periodic router advertisements to hosts on a link by a router should Madanapalli & Patil Expires February 5, 2007 [Page 1] Internet-Draft IPv6 Periodic Rtr Advts optional August 2006 be optional. At the very least the interval between such router advertisements should be configurable to a value that is significantly higher than currently specified. This document provides a recommendation for the periodic router advertisement interval (MaxRtrAdvInterval) and router lifetime. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Adverse effects of frequent Periodic RAs . . . . . . . . . . . 3 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Madanapalli & Patil Expires February 5, 2007 [Page 2] Internet-Draft IPv6 Periodic Rtr Advts optional August 2006 1. Introduction [1] defines neighbor discovery procedures for IPv6 for router discovery, prefix discovery, address resolution, neighbor Unreachability detection and parameter discovery. [1] defines Router Advertisements, which are sent either periodically or in response to Router solicitations from a host. [1] recommends the interval between periodic Router advertisements to be small enough such that the hosts will be able to discover all routers on a link within the span of a few minutes. [1] also defines parameter values for various parameters. Two specific parameters are considered within the scope of this document: 1. Router Lifetime during which a router acts as the default router for a host. The current maximum recommended value for this parameter is 150 minutes (9000 seconds). 2. MaxRtrAdvInterval: The maximum possible delay between two consecutive periodic router advertisements. The current recommended value is 30 minutes (1800 seconds). Routers that implement the current recommendations would send the periodic multicast router advertisements every 30 minutes, which can be a significant problem in mobile/cellular network environments. This document looks at the adverse effects of the current [1] specification on mobile and cellular networks, resulting from periodic multicast router advertisements and recommends that the sending of such router advertisements be optional, i.e. it should be possible to configure a router in specific environments or deployment scenarios with periodic router advertisements switched off. 2. Adverse effects of frequent Periodic RAs Mobile/cellular Networks like GPRS, 3G and WiMAX typically assign long lived prefixes, and the default access routers (GGSN, PDSN, ASN GW etc) for the hosts would typically be available for a long time on a given link (possibly infinite). Generally there exists only one default router at any given time on a given link for a host. The host devices in these networks, i.e. the mobile nodes, have constraints on battery power. To conserve battery life, mobile nodes frequently enter idle or dormant mode. Typically a mobile node will be in idle/dormant mode most of the time. IPv6 capable mobile nodes that are attached to an access router and are in idle/dormant mode will have to be awakened to deliver the router advertisement. This incurs significant costs and has a Madanapalli & Patil Expires February 5, 2007 [Page 3] Internet-Draft IPv6 Periodic Rtr Advts optional August 2006 negative impact on the battery lifetime of such devices. The mobile node has to be paged and switched to a state, which allows it to receive the router advertisement. Additionally bandwidth over the air interface is used for transmission of such packets. From an operational perspective, the periodic router advertisement in mobile networks is detrimental to optimal use of the radio resources as well as impacting battery power in mobile devices. The transmission and delivery of periodic router advertisements to a mobile node which is in dormant/idle mode at the expense of paging, allocating radio resources and establishing a connection to the host is unnecessary. Router advertisement is useful at the MN if it relied on it as the means to detect movement. However in many of the cellular networks, movement detection is not done at the IP layer. If an MN needs a router advertisement for any reason, it can always solicit for it. And if the network needs to deliver a router advertisement to a host to convey changes, it can do so as well without having to depend on periodic RAs. 3. Recommendations In order to optimize IPv6 behavior for deployment in mobile/cellular environments this document recommends the following changes to the ND [1] specification: o The transmission of periodic router advertisements should be optional. Access routers in mobile/cellular environments should have the option of switching off the sending of periodic RAs to hosts that are currently attached to the AR. The host served by such an AR should not expect to receive unsolicited RAs. o The maximum router lifetime be increased beyond the current max value of 9000 seconds. o The maximum value of the parameter MaxRtrAdvInterval be greater than 1800 seconds. The changes recommended to be made for ND are as follows: 1. Router Life Time: Allow the setting of this parameter in the router advertisement to 65535. This would imply that the router is available as the default router for infinity. This value can be updated by the subsequent router advertisements with a specific value. 2. MaxRtrAdvInterval: Allow the parameter to be configurable with a value set to 0 (zero). This indicates that the periodic multicast router advertisements are switched off on this Madanapalli & Patil Expires February 5, 2007 [Page 4] Internet-Draft IPv6 Periodic Rtr Advts optional August 2006 interface. In case no value is specified for this parameter, then the MaxRtrAdvInterval should be computed as indicated below: MaxRtrAdvInterval = 0.33 * min of {Router Lifetime, Prefix lifetime} This allows a host to receive three router advertisements before either Router Lifetime, or Prefix lifetime expires so that if there is any pocket loss in transmission it can be alleviated. 3. Recommend that mobile nodes proactively solicit router advertisements in any of the following cases: The threshold of the router lifetime is 0.75 * AdvDefaultLifetime and is triggered. The threshold of the prefix lifetime is 0.75 * AdvValidLifetime and is triggered. 4. Security Considerations This document specifies a few amendments to the [1] and does not introduce any new security threats. To reduce the threats associated with ND it is recommended that deployments use SeND [2] to secure neighbor discovery messages. 5. IANA Considerations This document has no actions for IANA. 6. Acknowledgements TBD 7. References [1] "Neighbor Discovery for IP version 6 (IPv6), draft-ietf-ipv6-2461bis-07.txt(work in progress)", May 2006. [2] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Madanapalli & Patil Expires February 5, 2007 [Page 5] Internet-Draft IPv6 Periodic Rtr Advts optional August 2006 Authors' Addresses Syam Madanapalli LogicaCMG 125 Yemlur Main Road Off Airport Road Bangalore 560037 India Email: smadanapalli at gmail dot com Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Madanapalli & Patil Expires February 5, 2007 [Page 6] Internet-Draft IPv6 Periodic Rtr Advts optional August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Madanapalli & Patil Expires February 5, 2007 [Page 7]