Network Working Group C. Vogt Internet-Draft R. Bless Expires: December 26, 2005 M. Doll University of Karlsruhe June 24, 2005 Analysis of IPv6 Relocation Delays draft-vogt-dna-relocation-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 December 26, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Mobile nodes require fast IPv6 relocation. Yet, router discovery, address auto-configuration, and support for TSLLAOs depend on delayed MLD signaling, defeating existing optimizations in many situations. This document identifies problematic situations. It proposes delay relaxations for MLD Reports or use of optimistic addresses prior to the initial Neighbor Solicitation to improve them. Vogt, et al. Expires December 26, 2005 [Page 1] Internet-Draft IPv6 Relocation Delays June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Situation A . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Situation B . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Situation C . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Situation D . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Situation E . . . . . . . . . . . . . . . . . . . . . . . 6 4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Eliminating the Delay for MLD Reports . . . . . . . . . . 7 4.2 Using Optimistic Addresses Before the Initial NS . . . . . 7 4.3 Increasing Robustness . . . . . . . . . . . . . . . . . . 7 5. Brief Analysis . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Vogt, et al. Expires December 26, 2005 [Page 2] Internet-Draft IPv6 Relocation Delays June 2005 1. Introduction Mobile nodes require fast router discovery and auto-configuration of global IPv6 addresses. Upcoming standards [1], [3], and [4] attend to this. IPv6 Neighbor Discovery [1] accellerates router discovery in that it allows mobile nodes to forego the recommended backoff for the first Router Solicitation after interface (re-) initialization. Optimistic Duplicate Address Detection (ODAD) [3] allows early use of new IPv6 addresses once an initial NS has been sent. Nodes who support the Tentative Source Link-Layer Address Option (TSLLAO) [4] can save additional address-resolution round trips during router discovery and address auto-configuration. Still, mobile nodes must send a MLD Report [5] at some stage during router discovery or address auto-configuration. MLD Reports are subject to a random backoff between 0 and MAX_RTR_SOLICITATION_DELAY (1 second) time RFC 2462bis [2] (*). There is currently no accelleration for this, defeating the benefits of the afore-mentioned optimizations in many situations. This document identifies some of these situations and suggests two approaches to improve them: relaxing the delay for MLD Reports under certain conditions or permitting use of optimistic addresses prior to the initial NS. The document is considered a basis for further mailing list discussion. It is supposed to aid the revision process of existing DNA Working Group documents rather than to evolve itself towards a separate document. (*) Note: Delaying the initial message after interface (re-) initialization is a common rule across RFC 2461bis and RFC 2462bis. This is mentioned explicitly for MLD Reports sent during address auto-configuration RFC 2462bis. It is not explicitly mentioned for MLD Reports sent during router discovery (cf. section 3.3). It is assumed in this document that the delay is implied in the latter case. 2. History This problem was first raised and discussed on the IPv6 mailing list [6]. The outcome was to not incorporate a delay relaxation for the MLD Report into RFC 2461bis and RFC 2462bis, as it was unclear then whether this could negatively impact other on-link nodes (both mobile and stationary). Instead, the consensus was to discuss this in greater detail in the DNA Working Group. The problem appeared again in a similar context on the DNA mailing Vogt, et al. Expires December 26, 2005 [Page 3] Internet-Draft IPv6 Relocation Delays June 2005 list [7]. 3. Problem Statement This section identifies five situations in which IPv6 relocation is substantially delayed in spite of optimizations defined by RFC 2461bis, ODAD, and TSLLAO. Common to all situations is the assumption that the mobile node does not risk sending a RS with a topologically false IPv6 source address, neither does it risk Neighbor Cache pollution of on-link neighbors. This implies the following: Since the mobile node does not know before reception of a RA whether or not it has changed IPv6 attachment, it cannot use its configured global unicast addresses during router discovery. For the same reason, the mobile node must handle its configured link-local unicast addresses as if those where tentative. It is also assumed that the mobile node implements ODAD. Nonetheless, the identified issues are essentially the same when the mobile node uses non-optimized RFC 2462bis. 3.1 Situation A Description Routers on the new IP link support the TSLLAO for RSs. The mobile node solicits a unicast RA by sending a RS with a TSLLAO from the unspecified address. The TSLLAO allows the router to unicast the RA without performing address resolution. o MN sends a RS with a TSLLAO from the unspecified address. o MN receives an IPv6-multicast RA by link-layer unicast. o MN sends a MLD Report for an optimistic address. o MN send a NS for the optimistic address, initiating ODAD. The RS (step 1) may be sent immediately, even though this is the first message transmitted after (re-) enabling the interface RFC 2461bis. From a standard's perspective, it is debatable whether or not the MLD Report must be delayed. RFC 2462bis says in section 5.4.2: Even if the Neighbor Solicitation is not going to be the first message to be sent, the node SHOULD delay joining the solicited- node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY if the address being checked is Vogt, et al. Expires December 26, 2005 [Page 4] Internet-Draft IPv6 Relocation Delays June 2005 configured by a router advertisement message sent to a multicast address. The RA (step 2) is an IPv6 multicast, yet a link-layer unicast. Since there is only a single recipient, omitting the delay for the MLD Report would be feasible. However, this requires inspection of the link-layer destination address within the IPv6 stack, which may not be possible. 3.2 Situation B Description Routers on the new IP link support the TSLLAO for RSs. The mobile node solicits a unicast RA by sending a RS with a TSLLAO from an optimistic address. o MN sends a MLD Report for an optimistic address. o MN send a NS for the optimistic address, initiating ODAD. o MN sends a RS with a TSLLAO from the optimistic address. o MN receives a unicast RA. The MLD Report (step 1) is delayed for up to 1 second (MAX_RTR_SOLICITATION_DELAY) because it is the first message transmitted after (re-) enabling the interface RFC 2462bis. 3.3 Situation C Description Routers on the new IP link do not support the TSLLAO for RSs. The mobile node solicits a RA. Routers unicast solicited RAs. Soliciting a unicast RA requires the mobile node to send a RS from an optimistic address (without a SLLAO). o MN sends a MLD Report for an optimistic address. o MN sends a NS for the optimistic address, initiating ODAD. o MN sends a RS from the optimistic address. o MN receives a NS for the optimistic address from the router. o MN sends a NA for the optimistic address to the router. o MN receives a unicast RA. The MLD Report (step 1) is delayed for up to 1 second (MAX_RTR_SOLICITATION_DELAY) because it is the first message transmitted after (re-) enabling the interface RFC 2462bis. 3.4 Situation D Vogt, et al. Expires December 26, 2005 [Page 5] Internet-Draft IPv6 Relocation Delays June 2005 Description Routers on the new IP link do not support the TSLLAO for RSs, but do send unsolicited multicast RAs every 30ms to 70ms according to rules in [RFC3775]. o MN receives a multicast RA. o MN sends a MLD Report for an optimistic address. o MN sends an initial NS for the optimistic address (ODAD). The MLD Report (step 2) is delayed for two reasons. First, it is the first message transmitted after (re-) enabling the interface. This calls for a delay of up to 1 second (MAX_RTR_SOLICITATION_DELAY) RFC 2462bis. Second, the MLD Report is sent in response to a multicast RA. This also calls for a delay of up to 1 seconds (MAX_RTR_SOLICITATION_DELAY) RFC 2462bis. 3.5 Situation E Description Routers on the new IP link do not support the TSLLAO for RSs. The mobile node solicits a multicast RA. The mobile node can send the RS from the unspecified address, eliminating the requirement to initiate ODAD at this point. o MN sends an RS from the unspecified address. o MN receives a multicast RA. o MN sends a MLD Report for an optimistic address. o MN send a NS for the optimistic address, initiating ODAD. The RS (step 1) may be sent immediately, even though this is the first message transmitted after (re-) enabling the interface RFC 2461bis. The multicast RA (step 2) is delayed for up to 3 seconds (maximum of MAX_RA_DELAY_TIME and MIN_DELAY_BETWEEN_RAS) RFC 2461bis. In addition, the MLD Report (step 3) is delayed for up to 1 second (MAX_RTR_SOLICITATION_DELAY) because it is sent in response to a multicast RA RFC 2462bis. 4. Possible Solutions Both of the following two approaches can eliminate the high IPv6 relocation delays indentified in section 2. Vogt, et al. Expires December 26, 2005 [Page 6] Internet-Draft IPv6 Relocation Delays June 2005 4.1 Eliminating the Delay for MLD Reports The random backoff for MLD Reports is "RECOMMENDED" in RFC 2461bis and RFC 2462bis to resolve contention amongst multiple neighbors when booting up simultaneously. It has little benefit when applied by a mobile node after IPv6 relocation. It hence seems feasible to eliminate the backoff for MLD Reports when applied after IPv6 relocation. In particular, both of the following two conditions would have to be met: 1. The mobile node has received a trigger from its local link layer indicating that interface reattachment has taken place. 2. The MLD Report is either the first message transmitted on the new link or it is sent in response to a unicast RA indicating IPv6 relocation. 4.2 Using Optimistic Addresses Before the Initial NS ODAD allows (limited) use of optimistic addresses after an initial NS has been sent. This NS must be preceeded by a MLD Report for the corresponding solicited-nodes multicast address. The random backoff for the MLD Report foils the benefits of ODAD. Fortunately, it appears feasible to allow (limited) use of an optimistic address even before the initial NS is sent. The delay for the MLD Report can so be moved to a non-critical phase. 4.3 Increasing Robustness Mobile nodes SHOULD retransmit multiple NSs during ODAD. Each NS SHOULD be immediately preceded by a retransmitted MLD Report. Thus, robustness to loss of (undelayed) MLD Report can be increased. 5. Brief Analysis The conditions defined in section 4.1 should be conservative enough to limit the proposed optimization to non-critical situations. In particular, the random backoff for MLD Reports should be retained for responses to multicast RAs as well as when the node boots up. This assumes that a reliable trigger for these conditions can be implemented. Generally, collisions of MLD and IPv6 Neighbor Discovery messages are more likely to occur in a mobile environment than in a stationary because mobile nodes use these messages for movement detection and IPv6 relocation. Delaying the MLD Report does not mitigate this, however. Vogt, et al. Expires December 26, 2005 [Page 7] Internet-Draft IPv6 Relocation Delays June 2005 Retransmitted MLD Reports and RSs, as described in section 4.3, may repair router-discovery failure in situation C due to a collided (undelayed) MLD Report. Similarly, retransmitting MLD Reports and NSs is likely to resolve collisions and ensure correct operation of ODAD in situations A through E. ODAD may still fail when neighbors located at different sides of a snooping switch simultaneously attempt to auto-configure the same IPv6 address. If one of the nodes' MLD Report collides, but its NS does not, that node will not receive the competing node's NS. The result is that the former "wins" this race condition and the latter "loses" it. More serious is a situation in which both MLD Reports get lost. The MLD state will eventually be repaired by the retransmitted MLD Report of both the mobile node and the neighbor. But there will be two nodes on the link using the same address. The IPv6 protocol suite currently does not recover from configured duplicate addresses. 6. Security Considerations This optimization does not imply security concerns in addition to those which already exist in the standard IPv6 protocol suite. Vogt, et al. Expires December 26, 2005 [Page 8] Internet-Draft IPv6 Relocation Delays June 2005 7. References [1] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-03 (work in progress), May 2005. [2] Thomson, S., "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08 (work in progress), May 2005. [3] Moore, N., "Optimistic Duplicate Address Detection for IPv6", draft-ietf-ipv6-optimistic-dad-05 (work in progress), February 2005. [4] Daley, G., "Tentative Source Link-Layer Address Options for IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in progress), February 2005. [5] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [6] "Discussion on the IPv6 mailing list, starting May 27, 2005", May 2005, . [7] "Discussion on the DNA mailing list, starting June 13, 2005", June 2005, . Authors' Addresses Christian Vogt Institute of Telematics University of Karlsruhe P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de URI: http://www.tm.uka.de/~chvogt/ Vogt, et al. Expires December 26, 2005 [Page 9] Internet-Draft IPv6 Relocation Delays June 2005 Roland Bless Institute of Telematics University of Karlsruhe P.O. Box 6980 76128 Karlsruhe Germany Email: bless@tm.uka.de URI: http://www.tm.uka.de/~bless/ Mark Doll Institute of Telematics University of Karlsruhe P.O. Box 6980 76128 Karlsruhe Germany Email: doll@tm.uka.de URI: http://www.tm.uka.de/~doll/ Appendix A. Acknowledgements Credits go to Gregory Daley for a valuable discussion on interactions between MLD and router discovery plus address auto-configuration. Thanks also to folks contributing to the initial thread on the IPv6 mailing list [1]. Vogt, et al. Expires December 26, 2005 [Page 10] Internet-Draft IPv6 Relocation Delays June 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vogt, et al. Expires December 26, 2005 [Page 11]