idnits 2.17.1 draft-gont-v6ops-cpe-slaac-renum-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 95: '... o CPE routers MUST signal stale con...' RFC 2119 keyword, line 98: '... o CPE routers MUST implement the DH...' RFC 2119 keyword, line 101: '... o CPE routers SHOULD NOT automatica...' RFC 2119 keyword, line 107: '...arned via DHCPv6-PD MUST NOT span past...' RFC 2119 keyword, line 109: '...Lifetime" and "Valid Lifetime" MUST be...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2019) is 1637 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-gont-6man-slaac-renum-01 == Outdated reference: A later version (-02) exists of draft-gont-v6ops-slaac-renum-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group (v6ops) F. Gont 3 Internet-Draft SI6 Networks 4 Intended status: Informational J. Zorz 5 Expires: May 4, 2020 6 R. Patterson 7 Sky UK 8 November 1, 2019 10 Improving the Reaction of Customer Edge Routers to Renumbering Events 11 draft-gont-v6ops-cpe-slaac-renum-00 13 Abstract 15 In scenarios where network configuration information related to IPv6 16 prefixes becomes invalid without any explicit signaling of that 17 condition (such as when a CPE crashes and reboots without knowledge 18 of the previously-employed prefixes), hosts on the local network will 19 continue using stale prefixes for an unacceptably long period of 20 time, thus resulting in connectivity problems. This document 21 specifies improvements to Customer Edge Routers that help mitigate 22 the aforementioned problem for typical residential and small office 23 scenarios. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 4, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Improved CPE behavior . . . . . . . . . . . . . . . . . . . . 2 61 2.1. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 3 62 2.2. Signaling Stale Configuration Information . . . . . . . . 3 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 6.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 In scenarios where network configuration information related to IPv6 74 prefixes becomes invalid without any explicit signaling of that 75 condition, nodes on the local network will continue using stale 76 prefixes for an unacceptably long period of time, thus resulting in 77 connectivity problems. This problem is documented in detail in 78 [I-D.gont-v6ops-slaac-renum]. 80 This document specifies improvements to Customer Edge Routers that 81 help mitigate the aforementioned problem for residential or small 82 office scenarios. 84 2. Improved CPE behavior 86 This section specifies and clarifies requirements for CPE routers 87 (particularly when they advertise with SLAAC [RFC4862] prefixes 88 learned via DHCPv6-PD [RFC8415]) that can help mitigate the problem 89 discussed in Section 1. This would obviously make robustness 90 dependent on the CPE (on which the user or ISP may have no control), 91 as opposed to the host itself. 93 The updated behaviour is as follows: 95 o CPE routers MUST signal stale configuration information as 96 specified in Section 2.2 98 o CPE routers MUST implement the DHCPv6-PD/SLAAC interface specified 99 in Section 2.1. 101 o CPE routers SHOULD NOT automatically send DHCPv6-PD RELEASE 102 messages upon reboot events. 104 2.1. Interaction Between DHCPv6-PD and SLAAC 106 The "Preferred Lifetime" and "Valid Lifetime" of PIOs [RFC4861] 107 corresponding to prefixes learned via DHCPv6-PD MUST NOT span past 108 the lease time of the DHCPv6-PD prefixes. This means that the 109 advertised "Preferred Lifetime" and "Valid Lifetime" MUST be 110 dynamically adjusted such that the advertised lifetimes never span 111 past the lease time of the prefixes delegated via DHCPv6-PD. 113 This is in line with these existing requirements from other 114 specifications, which we reference here for clarity: 116 o [RFC8415] specifies, in Section 6.3, that "if the delegated prefix 117 or a prefix derived from it is advertised for stateless address 118 autoconfiguration [RFC4862], the advertised preferred and valid 119 lifetimes MUST NOT exceed the corresponding remaining lifetimes of 120 the delegated prefix." 122 RATIONALE: 124 * The lifetime values employed for the "Preferred Lifetime" 125 (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) 126 should never be larger than the remaining lease time for the 127 corresponding prefix (as learned via DHCPv6-PD). 129 * The lifetime values advertised for prefixes corresponding to a 130 prefix leased via DHCPv6-PD should be dynamically updated 131 (rather than static values), since otherwise the advertised 132 lifetimes would eventually span past the DHCPv6-PD lease time. 134 2.2. Signaling Stale Configuration Information 136 In order to phase-out stale configuration information: 138 o A CPE router sending RAs that advertise dynamically-learned 139 prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on 140 stable storage, the list of prefixes being advertised on each 141 network segment. 143 o Upon changes to the advertised prefixes, and after bootstrapping, 144 the CPE router advertising prefix information via SLAAC should 145 proceed as follows: 147 * Any prefixes that were previously advertised via SLAAC, but 148 that are not currently intended for address configuration, MUST 149 be advertised with a PIO option with the "A" bit set to 1 and 150 the "Valid Lifetime" and a "Preferred Lifetime" set to 0. 152 * Any prefixes that were previously advertised via SLAAC as "on- 153 link", but that are not currently not considered "on-link", 154 MUST be advertised with a PIO option with the "L" bit set to 1 155 and the "Valid Lifetime" and a "Preferred Lifetime" set to 0. 157 * If both of the previous conditions are met (a prefix was 158 previously advertised with both the "A" and "L" bits set, but 159 is currently *not* intended for address configuration and is 160 *not* considered on-link), the prefix MUST be advertised with a 161 PIO option with both the "A" and "L" bits set to 1 and the 162 "Valid Lifetime" and a "Preferred Lifetime" set to 0. That is. 163 the advertisements of the previous two steps can be coalesced 164 into a single one with both the "A" and "L" bits set. 166 * The aforementioned advertisement SHOULD be performed for at 167 least the "Valid Lifetime" previously employed for such prefix. 169 The aforementioned improved behaviour assumes compliance with the 170 following existing requirements from other specifications, which we 171 reference here for clarity: 173 o [RFC7084] specifies (requirement LE-13, in Section 4.3) that when 174 the delegated prefix changes (i.e., the current prefix is replaced 175 with a new prefix without any overlapping time period), "the IPv6 176 CE router MUST immediately advertise the old prefix with a 177 Preferred Lifetime of zero and a Valid Lifetime of either a) zero 178 or b) the lower of the current Valid Lifetime and two hours (which 179 must be decremented in real time) in a Router Advertisement 180 message as described in Section 5.5.3, (e) of [RFC4862]" 182 3. IANA Considerations 184 This document has no actions for IANA. 186 4. Security Considerations 188 This document discusses a problem that may arise in scenarios where 189 dynamic IPv6 prefixes are employed, and proposes improvements to 190 Customer Edge Routers [RFC7084] to mitigate the problem for 191 residential or small office scenarios. It does not introduce new 192 security issues. 194 5. Acknowledgments 196 The authors would lie to thank (in alphabetical order) Mikael 197 Abrahamsson, Luis Balbinot, Brian Carpenter, Owen DeLong, Gert 198 Doering, Steinar Haug, Nick Hilliard, Philip Homburg, Lee Howard, 199 Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet Martinez, 200 Richard Patterson, Michael Richardson, Mark Smith, Tarko Tikan, and 201 Ole Troan, for providing valuable comments on 202 [I-D.gont-6man-slaac-renum], on which this document is based.earlier 203 versions of this document. 205 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 206 for a discussion of these issues. Fernando would also like to thank 207 Brian Carpenter who, over the years, has answered many questions and 208 provided valuable comments that has benefited his protocol-related 209 work. 211 6. References 213 6.1. Normative References 215 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 216 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 217 DOI 10.17487/RFC4861, September 2007, 218 . 220 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 221 Address Autoconfiguration", RFC 4862, 222 DOI 10.17487/RFC4862, September 2007, 223 . 225 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 226 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 227 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 228 RFC 8415, DOI 10.17487/RFC8415, November 2018, 229 . 231 6.2. Informative References 233 [I-D.gont-6man-slaac-renum] 234 Gont, F. and J. Zorz, "Reaction of Stateless Address 235 Autoconfiguration (SLAAC) to Renumbering Events", draft- 236 gont-6man-slaac-renum-01 (work in progress), February 237 2019. 239 [I-D.gont-v6ops-slaac-renum] 240 Gont, F., Zorz, J., and R. Patterson, "Reaction of 241 Stateless Address Autoconfiguration (SLAAC) to Renumbering 242 Events", draft-gont-v6ops-slaac-renum-00 (work in 243 progress), July 2019. 245 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 246 Requirements for IPv6 Customer Edge Routers", RFC 7084, 247 DOI 10.17487/RFC7084, November 2013, 248 . 250 Authors' Addresses 252 Fernando Gont 253 SI6 Networks 254 Segurola y Habana 4310, 7mo Piso 255 Villa Devoto, Ciudad Autonoma de Buenos Aires 256 Argentina 258 Phone: +54 11 4650 8472 259 Email: fgont@si6networks.com 260 URI: https://www.si6networks.com 262 Jan Zorz 263 Frankovo n. 165 264 Skofja Loka 265 Slovenia 267 Email: jan@go6.si 269 Richard Patterson 270 Sky UK 272 Email: richard.patterson@sky.uk