6man Working Group S. Krishnan Internet-Draft Ericsson Intended status: Standards Track O. Bonness Expires: February 27, 2011 Deutsche Telekom AG August 26, 2010 IPv6 Stateless auto-configuration issues due to loss of IPv6 Router Solicitation messages draft-krishnan-6man-rs-lost-00 Abstract The IPv6 stateless auto-configuration(SLAAC) mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. This document describes a failure scenario for SLAAC and discusses how hosts can recover from this failure in a properly configured network. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 27, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Krishnan & Bonness Expires February 27, 2011 [Page 1] Internet-Draft SLAAC Clarifications August 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Issues due to lost RSs . . . . . . . . . . . . . . . . . . . . 3 4. Recovering from lost RSs . . . . . . . . . . . . . . . . . . . 3 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Krishnan & Bonness Expires February 27, 2011 [Page 2] Internet-Draft SLAAC Clarifications August 2010 1. Introduction When an interface on an IPv6 host is initialized, To obtain Router Advertisements quickly, a host transmits Router Solitication messages in order to elicit a Router advertisement from a router. This document analyzes the case where all of these RSs are not received by the router due to lack of connectivity at the time the RSs were transmitted. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Issues due to lost RSs When an interface on an IPv6 host is initialized, in order to obtain Router Advertisements quickly, a host SHOULD transmit up to 3 (MAX_RTR_SOLICITATIONS) Router Solicitation messages, each separated by at least 4 (RTR_SOLICITATION_INTERVAL) seconds as specified in Section 6.3.7. of [RFC4861]. If there exists a switched network between the host and the router on the network, it is possible that the host interface may become enabled before link layer connectivity to the router is complete. In this case the Router Solicitations sent by the host will never reach the router and hence will not elicit a Router Advertisement from the router. After sending MAX_RTR_SOLICITATIONS solicitations, and receiving no Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY seconds after sending the last solicitation, the host will conclude that there are no routers on the link for stateless auto- configuration purposes. Hence the host will not be able to obtain a global unicast address. 4. Recovering from lost RSs After the RSs are lost, the host assumes that no routers are present on the link, and will no longer actively try to acquire a Router. So even if a router appears on the link due to link layer connectivity being established, the host will be blissfully oblivious to the presence of the router. Krishnan & Bonness Expires February 27, 2011 [Page 3] Internet-Draft SLAAC Clarifications August 2010 Even though the host is not actively soliciting routers at this point, it will continue to receive and process Router Advertisements messages as specified in Section 6.3.7. of [RFC4861]. As long as the router on the link keeps sending periodic unsolicited multicast RAs (as required by [RFC4861], one of these RAs will eventually reach the host. If these unsolicited RAs contain at least one prefix information option (PIO) with the autonomous address- configuration flag set, the host can start using this prefix for SLAAC [RFC4862] and it will successfully form an address. Hence the issue is resolved. If the RA does not contain any PIOs or it does not contain any PIOs with the autonomous address-configuration flag set, it is unclear how the host will react. This scenario, where the unsolicited RAs contain less information that the solicited RAs, seems to be anticipated and allowed by [RFC4861] where the following text is present. "Moreover, a host SHOULD send at least one solicitation in the case where an advertisement is received prior to having sent a solicitation. Responses to solicited advertisements may contain more information than unsolicited advertisements." Hosts following the SHOULD recommendation will send an RS in response to the received unsolicited RA. This RS will cause the router to send a solicited RA that will contain a PIO with the autonomous address-configuration flag set. The host can start using this prefix for SLAAC and it will successfully form an address. Hence the issue is resolved. 5. Open Issues If the router does not sent periodic multicast unsolicited RAs or if the host does not implement the SHOULD recommendation for sending an RS on receipt of an unsolicited RA, the host cannot configure an address using SLAAC. In the absence of other address configuration mechanisms (DHCPv6, Manual), the host will not be able to obtain a global unicast address. While such router behavior is clearly non-compliant and is unlikely to be encountered, the expected behavior of hosts under this situation is unclear. This document has been written in order to foster discussion about both existing and expected host behaviors in this case. Krishnan & Bonness Expires February 27, 2011 [Page 4] Internet-Draft SLAAC Clarifications August 2010 6. Acknowledgements The authors would like to thank Alan Kavanagh, Balazs Varga, Sven Ooghe, Thomas Haag, Thomas Narten, Ole Troan and Wojciech Dec for the discussions that led to this document. 7. Security Considerations This document describes a failure scenario for IPv6 Stateless address auto-configuration. It does not bring up any new security issues. 8. IANA Considerations This document does not require any IANA action. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Authors' Addresses Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: suresh.krishnan@ericsson.com Krishnan & Bonness Expires February 27, 2011 [Page 5] Internet-Draft SLAAC Clarifications August 2010 Olaf Bonness Deutsche Telekom AG T-Labs (Research & Development) Goslarer Ufer 35 10589 Berlin Germany Email: olaf.bonness@telekom.de Krishnan & Bonness Expires February 27, 2011 [Page 6]