Network Working Group C. Vogt Internet-Draft R. Bless Expires: January 19, 2006 M. Doll Universitaet Karlsruhe (TH) G. Daley Monash University July 18, 2005 Analysis of IPv6 Relocation Delays draft-vogt-dna-relocation-01.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 January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract As mobile nodes move to new links, they need to resume their communications in a timely fashion. To communicate, IPv6 nodes need to complete router discovery, address auto-configuration, and other tasks. Unfortunately, this depends on prior completion of the Multicast Listener Discovery (MLD) protocol, introducing a mandatory Vogt, et al. Expires January 19, 2006 [Page 1] Internet-Draft IPv6 Relocation Delays July 2005 delay of up to one second. This document discusses where this can be problematic and proposes solutions that can alleviate the problem. Vogt, et al. Expires January 19, 2006 [Page 2] Internet-Draft IPv6 Relocation Delays July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Situation A . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Situation B . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Situation C . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Situation D . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Situation E . . . . . . . . . . . . . . . . . . . . . . . 7 4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Eliminating the Delay for MLD Reports . . . . . . . . . . 7 4.2 Using Optimistic Addresses Before the Initial NS . . . . . 8 4.3 Increasing Robustness . . . . . . . . . . . . . . . . . . 8 5. Brief Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Vogt, et al. Expires January 19, 2006 [Page 3] Internet-Draft IPv6 Relocation Delays July 2005 1. Introduction Mobile nodes require fast router discovery and auto-configuration of global IPv6 addresses. New mechanisms defined in [1], [3], and [4] attend to this. IPv6 Neighbor Discovery [1] accelerates router discovery in that it allows mobile nodes to forego the recommended backoff for the first Router Solicitation (RS) after interface (re-) initialization. Optimistic Duplicate Address Detection (ODAD) [3] allows early use of new IPv6 addresses once an initial Neighbor Solicitation (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][6] 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 acceleration for this, defeating the benefits of the afore-mentioned optimizations in many situations. This document identifies such 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. 2. History This problem was first raised and discussed on the IPv6 mailing list [9]. 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 list [10]. 3. Problem Statement This section identifies five situations, A through E, in which IPv6 relocation is substantially delayed in spite of optimizations defined by RFC 2461bis, ODAD, and TSLLAO. Vogt, et al. Expires January 19, 2006 [Page 4] Internet-Draft IPv6 Relocation Delays July 2005 In all situations, after changing links, the mobile node avoids using its configured global unicast addresses during router discovery, since it does not know before reception of a Router Advertisement (RA) whether or not it has changed IPv6 attachment. Also, in order to avoid Neighbor Cache pollution of on-link neighbors, 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 Routers on the new IP link support the TSLLAO for RSs. The mobile node solicits a unicast RA by sending an RS with an TSLLAO from the unspecified address. The TSLLAO allows the router to unicast the RA without performing address resolution. What follows is the message exchange from the mobile node's perspective: 1. MN sends an RS from the unspecified address with an TSLLAO. 2. MN receives an IPv6-multicast RA by link-layer unicast. 3. MN sends an MLD Report for an optimistic address. 4. MN sends an 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 [1]. 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 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 in this case, omitting the delay for the MLD Report would be feasible. But the mobile node must inspect the link-layer destination address in order to determine whether the RA was a multicast or a unicast. This may not always be possible. Vogt, et al. Expires January 19, 2006 [Page 5] Internet-Draft IPv6 Relocation Delays July 2005 3.2 Situation B Routers on the new IP link support the TSLLAO for RSs. The mobile node solicits a unicast RA by sending an RS with an TSLLAO from an optimistic address. Overall, it sends and receives the following messages in sequence: 1. MN sends an MLD Report for an optimistic address. 2. MN sends an NS for the optimistic address, initiating ODAD. 3. MN sends an RS with an TSLLAO from the optimistic address. 4. 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 [2]. 3.3 Situation C Routers on the new IP link do not support the TSLLAO for RSs. The mobile node solicits an RA. Routers unicast solicited RAs. Soliciting a unicast RA requires the mobile node to send an RS from an optimistic address (without a SLLAO). This is the complete message exchange: 1. MN sends an MLD Report for an optimistic address. 2. MN sends an NS for the optimistic address, initiating ODAD. 3. MN sends an RS from the optimistic address. 4. MN receives an NS for the optimistic address from the router. 5. MN sends a Neighbor Advertisement (NA) for the optimistic address to the router. 6. 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 [2]. 3.4 Situation D 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 [7]. The mobile node sends and receives the following messages in sequence: 1. MN receives a multicast RA. 2. MN sends an MLD Report for an optimistic address. Vogt, et al. Expires January 19, 2006 [Page 6] Internet-Draft IPv6 Relocation Delays July 2005 3. 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) [2]. 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) [2]. 3.5 Situation E 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. Overall, it sends an receives the following messages: 1. MN sends an RS from the unspecified address. 2. MN receives a multicast RA. 3. MN sends an MLD Report for an optimistic address. 4. MN sends an 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 [1]. The multicast RA (step 2) is delayed for up to 3 seconds (maximum of MAX_RA_DELAY_TIME and MIN_DELAY_BETWEEN_RAS) [1]. 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 [2]. 4. Possible Solutions The following approaches can be used to eliminate the high IPv6 relocation delays identified in Section 3. 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 after IPv6 relocation. In particular, both of the following two conditions would have to be met: Vogt, et al. Expires January 19, 2006 [Page 7] Internet-Draft IPv6 Relocation Delays July 2005 o The mobile node has received a trigger from its local link layer indicating that an interface, which was previously operational, has gone down and come up again. o 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. Note that mobile nodes would still have to send a MLD Report prior to sending a RS from an optimistic address in situation C: Since the RS does not include a SLLAO, the router will have to invoke address resolution for the optimistic address. Sending the MLD Report ensures that the mobile node can receive the NS in the presence of snooping switches. Note that RFC 2461bis currently does not require transmission of a MLD Report prior to the RS in case of interface (re-) initialization. 4.3 Increasing Robustness The optimum desynchonization delays for signaling messages such as the MLD Report are highly application- and environment-specific. RFC 2461bis and RFC 2462bis are tailored towards stationary nodes, so the delays of up to MAX_RTR_SOLICITATION_DELAY (1 second) are acceptable and make sense. However, for mobile nodes, such delays will badly impact real-time applications like VoIP. It may be possible in rare deployment scenarios to hard-code application- and environment- specific behavior into the nodes. But this approach is infeasible in general, simply because the applications and environments are unknown a priori. One solution to this problem is to differentiate between messages for which loss is recoverable and messages for which it is not. E.g., loss of an RS can be detected by the mobile node by lack of a corresponding RA. In this (unlikely) case, the mobile node loses some time, but will eventually retransmit the RS. On the other hand, loss of a MLD Report or NS sent during ODAD cannot be detected, because there is no expected response. This might lead to an address duplicate, which is currently not recoverable. Vogt, et al. Expires January 19, 2006 [Page 8] Internet-Draft IPv6 Relocation Delays July 2005 In this sense, a mobile node should retransmit an MLD Report and RS after an appropriate time period if it fails to receive a corresponding RA. For the purpose of ODAD, the mobile node should retransmit MLD Reports and NSs in background mode two, three, or more times. An optimistic address would then be considered unique only after none of these transmissions resulted in a response. The mobile node may use plenty of desynchronization delay without negatively affecting applications because all transmission occur in background mode. Specifically, mobile nodes SHOULD retransmit multiple NSs during ODAD. Each NS SHOULD be 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 indication 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. 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, during ODAD, 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. Vogt, et al. Expires January 19, 2006 [Page 9] Internet-Draft IPv6 Relocation Delays July 2005 Transmission of MLD Reports can lead to undesired signaling overhead. Furthermore, with respect to router discovery and address auto- configuration, MLD Reports have a benefit only in the presence of snooping switches [8]. The crux is that a mobile node usually does not know a new link's topology at attachment time, so it seems that omission of MLD Reports would become feasible only with appropriate support from the link layer. 6. Security Considerations The optimizations proposed in this document affect desynchronization delays and retransmission policies applied by mobile nodes. Malicious nodes can always choose their own delays and policies, of course. As a consequence, the optimizations proposed in this document do not imply security concerns in addition to those which already exist in the standard IPv6 protocol suite [1][2], in ODAD [3], or in TSLLAO [4]. Vogt, et al. Expires January 19, 2006 [Page 10] Internet-Draft IPv6 Relocation Delays July 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] Rolland, R., Luis, L., , S., Deering, S., Fenner, W., Kouvelas, I., and B. Haberman, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [8] Christensen, M., Kimball, K., and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 (work in progress), February 2005. [9] "Comment on RFCs 2461bis and 2462bis", Discussion on the IPv6 mailing list, May 27, 2005, . [10] "DAD and MLD Interaction", Discussion on the DNA mailing list, June 13, 2005, . Vogt, et al. Expires January 19, 2006 [Page 11] Internet-Draft IPv6 Relocation Delays July 2005 Authors' Addresses Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de URI: http://www.tm.uka.de/~chvogt/ Roland Bless Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: bless@tm.uka.de URI: http://www.tm.uka.de/~bless/ Mark Doll Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: doll@tm.uka.de URI: http://www.tm.uka.de/~doll/ Gregory Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Email: reg.daley@eng.monash.edu.au Vogt, et al. Expires January 19, 2006 [Page 12] Internet-Draft IPv6 Relocation Delays July 2005 Appendix A. Acknowledgments Credits go to Gregory Daley for a valuable discussion on interactions between MLD and router discovery plus address auto-configuration. Thanks also to Jari Arkko, who thoroughly reviewed version 00 of this draft. Last, but not least, the authors appreciate the contributions of folks to the initial thread on the IPv6 mailing list [9]. Vogt, et al. Expires January 19, 2006 [Page 13] Internet-Draft IPv6 Relocation Delays July 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 January 19, 2006 [Page 14]