idnits 2.17.1 draft-ietf-6man-resilient-rs-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 9, 2015) is 3298 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7083 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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 Updates: 4861 (if approved) D. Anipko 5 Intended status: Standards Track Unaffiliated 6 Expires: October 11, 2015 D. Thaler 7 Microsoft 8 April 9, 2015 10 Packet loss resiliency for Router Solicitations 11 draft-ietf-6man-resilient-rs-06 13 Abstract 15 When an interface on a host is initialized, the host transmits Router 16 Solicitations in order to minimize the amount of time it needs to 17 wait until the next unsolicited multicast Router Advertisement is 18 received. In certain scenarios, these router solicitations 19 transmitted by the host might be lost. This document specifies a 20 mechanism for hosts to cope with the loss of the initial Router 21 Solicitations. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 11, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions used in this document . . . . . . . . . . . . 2 59 2. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Stopping the retransmissions . . . . . . . . . . . . . . 4 61 3. Configuring the use of retransmissions . . . . . . . . . . . 5 62 4. Known Limitations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 As specified in [RFC4861], when an interface on a host is 74 initialized, in order to obtain Router Advertisements quickly, a host 75 transmits up to MAX_RTR_SOLICITATIONS (3) Router Solicitation 76 messages, each separated by at least RTR_SOLICITATION_INTERVAL (4) 77 seconds. In certain scenarios, these router solicitations 78 transmitted by the host might be lost. e.g. The host is connected to 79 a bridged residential gateway over Ethernet or WiFi. LAN 80 connectivity is achieved at interface initialization, but the 81 upstream WAN connectivity is not active yet. In this case, the host 82 just gives up after the initial RS retransmits. 84 Once the initial RSs are lost, the host gives up and assumes that 85 there are no routers on the link as specified in Section 6.3.7 of 86 [RFC4861]. The host will not have any form of Internet connectivity 87 until the next unsolicited multicast Router Advertisement is 88 received. These Router Advertisements are transmitted at most 89 MaxRtrAdvInterval seconds apart (maximum value 1800 seconds). Thus 90 in the worst case scenario a host would be without any connectivity 91 for 30 minutes. This delay may be unacceptable in some scenarios. 93 1.1. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Proposed algorithm 100 To achieve resiliency to packet loss, the host needs to continue 101 retransmitting the Router Solicitations until it receives a Router 102 Advertisement, or until it is willing to accept that no router 103 exists. If the host continues retransmitting the RSs at 104 RTR_SOLICITATION_INTERVAL second intervals, it may cause excessive 105 network traffic if a large number of such hosts exists. To achieve 106 resiliency while keeping the aggregate network traffic low, the host 107 can use some form of exponential backoff algorithm to retransmit the 108 RSs. 110 Hosts complying to this specification MUST use the exponential 111 backoff algorithm for retransmits that is described in Section 14 of 112 [RFC3315] in order to continuously retransmit the Router 113 Solicitations until a Router Advertisement is received. The hosts 114 SHOULD use the following variables as input to the retransmission 115 algorithm: 117 IRT 4 seconds 119 MRT 3600 seconds 121 MRC 0 123 MRD 0 125 The initial value IRT was chosen to be in line with the current 126 retransmission interval (RTR_SOLICITATION_INTERVAL) that is specified 127 by [RFC4861] and the maximum retransmission time MRT was chosen to be 128 in line with the new value of SOL_MAX_RT as specified by [RFC7083]. 129 This is to ensure that the short term behavior of the RSs is similar 130 to what is experienced in current networks, and longer term 131 persistent retransmission behavior trends towards being similar to 132 that of DHCPv6 [RFC3315] [RFC7083]. 134 2.1. Stopping the retransmissions 136 On multicast-capable links, the hosts following this specification 137 SHOULD stop retransmitting the RSs when Router Discovery is 138 successful (i.e. an RA with a non-zero Router Lifetime that results 139 in a default route is received). If an RA is recieved from a router 140 and it does not result in a default route (i.e. Router Lifetime is 141 zero) the host MUST continue retransmitting the RSs. 143 On non-multicast links, the hosts following this specification MUST 144 continue retransmitting the RSs even after an RA that results in a 145 default route is received. This is required because, in such links, 146 sending an RA can only be triggered by an RS. Please note that such 147 links have special mechanisms for sending RSes as well. e.g. The 148 mechanism specified in Section 8.3.4. of ISATAP [RFC5214] unicasts 149 the RSes to specific routers. 151 3. Configuring the use of retransmissions 153 Implementations of this specification are encouraged to provide a 154 configuration option to enable or disable potentially infinite RS 155 retransmissions. If a configuration option is provided, it MUST 156 enable RS retransmissions by default. Providing an option to enable/ 157 disable retransmissions on a per-interface basis allows network 158 operators to configure RS behavior most applicable to each connected 159 link. 161 4. Known Limitations 163 When an IPv6-capable host attaches to a network that does not have 164 IPv6 enabled, it transmits 3 (MAX_RTR_SOLICITATIONS) Router 165 Solicitations as specified in [RFC4861]. If it receives no Router 166 Advertisements, it assumes that there are no routers present on the 167 link and it ceases to send further RSs. With the mechanism specified 168 in this document, the host will continue to retransmit RSs 169 indefinitely at the rate of approximately 1 RS per hour. It is 170 unclear how to differentiate between such a network with no IPv6 171 routers and a link where an IPv6 router is temporarily unreachable 172 but could become reachable in the future. 174 5. IANA Considerations 176 This document does not require any IANA actions. 178 6. Security Considerations 180 This document does not present any additional security issues beyond 181 those discussed in [RFC4861] and those RFCs that update [RFC4861]. 183 7. Acknowledgements 185 The authors would like to thank Steve Baillargeon, Erik Kline, Andrew 186 Yourtchenko, Ole Troan, Erik Nordmark, Lorenzo Colitti, Thomas 187 Narten, Ran Atkinson, Allison Mankin, Les Ginsberg, Brian Carpenter, 188 Barry Leiba, Brian Haberman, Spencer Dawkins, Alia Atlas, Stephen 189 Farrell and Mehmet Ersue for their reviews and suggestions that made 190 this document better. 192 8. References 193 8.1. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, March 1997. 198 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 199 and M. Carney, "Dynamic Host Configuration Protocol for 200 IPv6 (DHCPv6)", RFC 3315, July 2003. 202 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 203 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 204 September 2007. 206 [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT 207 and INF_MAX_RT", RFC 7083, November 2013. 209 8.2. Informative References 211 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 212 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 213 March 2008. 215 Authors' Addresses 217 Suresh Krishnan 218 Ericsson 219 8400 Decarie Blvd. 220 Town of Mount Royal, QC 221 Canada 223 Phone: +1 514 345 7900 x42871 224 Email: suresh.krishnan@ericsson.com 226 Dmitry Anipko 227 Unaffiliated 229 Phone: +1 425 442 6356 230 Email: dmitry.anipko@gmail.com 232 Dave Thaler 233 Microsoft 234 One Microsoft Way 235 Redmond, WA 236 USA 238 Email: dthaler@microsoft.com