idnits 2.17.00 (12 Aug 2021) /tmp/idnits13958/draft-krishnan-6man-rs-lost-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 26, 2010) is 4279 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track O. Bonness 5 Expires: February 27, 2011 Deutsche Telekom AG 6 August 26, 2010 8 IPv6 Stateless auto-configuration issues due to loss of IPv6 Router 9 Solicitation messages 10 draft-krishnan-6man-rs-lost-00 12 Abstract 14 The IPv6 stateless auto-configuration(SLAAC) mechanism allows a host 15 to generate its own addresses using a combination of locally 16 available information and information advertised by routers. This 17 document describes a failure scenario for SLAAC and discusses how 18 hosts can recover from this failure in a properly configured network. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 27, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions used in this document . . . . . . . . . . . . . . . 3 56 3. Issues due to lost RSs . . . . . . . . . . . . . . . . . . . . 3 57 4. Recovering from lost RSs . . . . . . . . . . . . . . . . . . . 3 58 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 When an interface on an IPv6 host is initialized, To obtain Router 68 Advertisements quickly, a host transmits Router Solitication messages 69 in order to elicit a Router advertisement from a router. This 70 document analyzes the case where all of these RSs are not received by 71 the router due to lack of connectivity at the time the RSs were 72 transmitted. 74 2. Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 3. Issues due to lost RSs 82 When an interface on an IPv6 host is initialized, in order to obtain 83 Router Advertisements quickly, a host SHOULD transmit up to 3 84 (MAX_RTR_SOLICITATIONS) Router Solicitation messages, each separated 85 by at least 4 (RTR_SOLICITATION_INTERVAL) seconds as specified in 86 Section 6.3.7. of [RFC4861]. 88 If there exists a switched network between the host and the router on 89 the network, it is possible that the host interface may become 90 enabled before link layer connectivity to the router is complete. In 91 this case the Router Solicitations sent by the host will never reach 92 the router and hence will not elicit a Router Advertisement from the 93 router. 95 After sending MAX_RTR_SOLICITATIONS solicitations, and receiving no 96 Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY 97 seconds after sending the last solicitation, the host will conclude 98 that there are no routers on the link for stateless auto- 99 configuration purposes. Hence the host will not be able to obtain a 100 global unicast address. 102 4. Recovering from lost RSs 104 After the RSs are lost, the host assumes that no routers are present 105 on the link, and will no longer actively try to acquire a Router. So 106 even if a router appears on the link due to link layer connectivity 107 being established, the host will be blissfully oblivious to the 108 presence of the router. 110 Even though the host is not actively soliciting routers at this 111 point, it will continue to receive and process Router Advertisements 112 messages as specified in Section 6.3.7. of [RFC4861]. 114 As long as the router on the link keeps sending periodic unsolicited 115 multicast RAs (as required by [RFC4861], one of these RAs will 116 eventually reach the host. If these unsolicited RAs contain at least 117 one prefix information option (PIO) with the autonomous address- 118 configuration flag set, the host can start using this prefix for 119 SLAAC [RFC4862] and it will successfully form an address. Hence the 120 issue is resolved. 122 If the RA does not contain any PIOs or it does not contain any PIOs 123 with the autonomous address-configuration flag set, it is unclear how 124 the host will react. This scenario, where the unsolicited RAs 125 contain less information that the solicited RAs, seems to be 126 anticipated and allowed by [RFC4861] where the following text is 127 present. 129 "Moreover, a host SHOULD send at least one solicitation in the case 130 where an advertisement is received prior to having sent a 131 solicitation. Responses to solicited advertisements may contain more 132 information than unsolicited advertisements." 134 Hosts following the SHOULD recommendation will send an RS in response 135 to the received unsolicited RA. This RS will cause the router to 136 send a solicited RA that will contain a PIO with the autonomous 137 address-configuration flag set. The host can start using this prefix 138 for SLAAC and it will successfully form an address. Hence the issue 139 is resolved. 141 5. Open Issues 143 If the router does not sent periodic multicast unsolicited RAs or if 144 the host does not implement the SHOULD recommendation for sending an 145 RS on receipt of an unsolicited RA, the host cannot configure an 146 address using SLAAC. In the absence of other address configuration 147 mechanisms (DHCPv6, Manual), the host will not be able to obtain a 148 global unicast address. 150 While such router behavior is clearly non-compliant and is unlikely 151 to be encountered, the expected behavior of hosts under this 152 situation is unclear. This document has been written in order to 153 foster discussion about both existing and expected host behaviors in 154 this case. 156 6. Acknowledgements 158 The authors would like to thank Alan Kavanagh, Balazs Varga, Sven 159 Ooghe, Thomas Haag, Thomas Narten, Ole Troan and Wojciech Dec for the 160 discussions that led to this document. 162 7. Security Considerations 164 This document describes a failure scenario for IPv6 Stateless address 165 auto-configuration. It does not bring up any new security issues. 167 8. IANA Considerations 169 This document does not require any IANA action. 171 9. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, March 1997. 176 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 177 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 178 September 2007. 180 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 181 Address Autoconfiguration", RFC 4862, September 2007. 183 Authors' Addresses 185 Suresh Krishnan 186 Ericsson 187 8400 Blvd Decarie 188 Town of Mount Royal, Quebec 189 Canada 191 Email: suresh.krishnan@ericsson.com 192 Olaf Bonness 193 Deutsche Telekom AG 194 T-Labs (Research & Development) 195 Goslarer Ufer 35 196 10589 Berlin 197 Germany 199 Email: olaf.bonness@telekom.de