idnits 2.17.1 draft-ietf-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 97: '... o CE routers MUST signal stale con...' RFC 2119 keyword, line 100: '... o CE routers MUST implement the DH...' RFC 2119 keyword, line 103: '... o CE routers SHOULD NOT automatica...' RFC 2119 keyword, line 110: '... DHCPv6-PD MUST NOT span past the le...' RFC 2119 keyword, line 112: '..."Valid Lifetime" MUST be dynamically a...' (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 (February 19, 2020) is 1521 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-02 == Outdated reference: A later version (-02) exists of draft-gont-v6ops-slaac-renum-01 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: August 22, 2020 Go6 Institute 6 R. Patterson 7 Sky UK 8 February 19, 2020 10 Improving the Reaction of Customer Edge Routers to Renumbering Events 11 draft-ietf-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 Customer Edge Router crashes and reboots 18 without knowledge of the previously-employed prefixes), hosts on the 19 local network will continue using stale prefixes for an unacceptably 20 long period of time, thus resulting in connectivity problems. This 21 document specifies improvements to Customer Edge Routers that help 22 mitigate the aforementioned problem for typical residential and small 23 office 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 August 22, 2020. 42 Copyright Notice 44 Copyright (c) 2020 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 Customer Edge Router Behavior . . . . . . . . . . . 2 61 2.1. Interface Between DHCPv6-PD and SLAAC . . . . . . . . . . 3 62 2.2. Signaling Stale Configuration Information . . . . . . . . 3 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 6.2. Informative References . . . . . . . . . . . . . . . . . 6 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 (CE) Routers 81 that help mitigate the aforementioned problem for residential or 82 small office scenarios. 84 2. Improved Customer Edge Router Behavior 86 This section specifies and clarifies requirements for Customer Edge 87 Routers -- particularly when they advertise with Stateless Address 88 Autoconfiguration (SLAAC) [RFC4862] prefixes learned via 89 DHCPv6-Prefix Delegation (DHCPv6-PD) [RFC8415] or prefixes derived 90 from them -- that can help mitigate the problem discussed in 91 Section 1. This would obviously make robustness dependent on the 92 Customer Edge Router (on which the user or ISP may have no control), 93 as opposed to the host itself. 95 The updated behaviour is as follows: 97 o CE routers MUST signal stale configuration information as 98 specified in Section 2.2 100 o CE routers MUST implement the DHCPv6-PD/SLAAC interface specified 101 in Section 2.1. 103 o CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE 104 messages upon reboot events. 106 2.1. Interface Between DHCPv6-PD and SLAAC 108 The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information 109 Options (PIOs) [RFC4861] corresponding to prefixes learned via 110 DHCPv6-PD MUST NOT span past the lease time of the DHCPv6-PD 111 prefixes. This means that the advertised "Preferred Lifetime" and 112 "Valid Lifetime" MUST be dynamically adjusted such that the 113 advertised lifetimes never span past the lease time of the prefixes 114 delegated via DHCPv6-PD. 116 This is in line with these existing requirements from other 117 specifications, which we reference here for clarity: 119 o [RFC8415] specifies, in Section 6.3, that "if the delegated prefix 120 or a prefix derived from it is advertised for stateless address 121 autoconfiguration [RFC4862], the advertised preferred and valid 122 lifetimes MUST NOT exceed the corresponding remaining lifetimes of 123 the delegated prefix." 125 RATIONALE: 127 * The lifetime values employed for the "Preferred Lifetime" 128 (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) 129 should never be larger than the remaining lease time for the 130 corresponding prefix (as learned via DHCPv6-PD). 132 * The lifetime values advertised for prefixes corresponding to a 133 prefix leased via DHCPv6-PD should be dynamically updated 134 (rather than static values), since otherwise the advertised 135 lifetimes would eventually span past the DHCPv6-PD lease time. 137 2.2. Signaling Stale Configuration Information 139 In order to phase-out stale configuration information: 141 o A CE router sending RAs that advertise dynamically-learned 142 prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on 143 stable storage, the list of prefixes being advertised on each 144 network segment. 146 o Upon changes to the advertised prefixes, and after bootstrapping, 147 the CE router advertising prefix information via SLAAC should 148 proceed as follows: 150 * Any prefixes that were previously advertised via Router 151 Advertisement (RA) messages for address configuration, but that 152 are not currently intended for address configuration, MUST be 153 advertised with a PIO with the "A" bit set to 1 and the "Valid 154 Lifetime" and a "Preferred Lifetime" set to 0. 156 * Any prefixes that were previously advertised via RA messages as 157 "on-link", but that are not currently not considered "on-link", 158 MUST be advertised with a PIO with the "L" bit set to 1 and the 159 "Valid Lifetime" and a "Preferred Lifetime" set to 0. 161 * If both of the previous conditions are met (a prefix was 162 previously advertised with both the "A" and "L" bits set, but 163 is currently *not* intended for address configuration and is 164 *not* considered on-link), the prefix MUST be advertised with a 165 PIO option with both the "A" and "L" bits set to 1 and the 166 "Valid Lifetime" and a "Preferred Lifetime" set to 0. That is. 167 the advertisements of the previous two steps can be coalesced 168 into a single one with both the "A" and "L" bits set. 170 * The aforementioned advertisement SHOULD be performed for at 171 least the "Valid Lifetime" previously employed for such prefix. 173 The aforementioned improved behaviour assumes compliance with the 174 following existing requirements from other specifications, which we 175 reference here for clarity: 177 o [RFC7084] specifies (requirement LE-13, in Section 4.3) that when 178 the delegated prefix changes (i.e., the current prefix is replaced 179 with a new prefix without any overlapping time period), "the IPv6 180 CE router MUST immediately advertise the old prefix with a 181 Preferred Lifetime of zero and a Valid Lifetime of either a) zero 182 or b) the lower of the current Valid Lifetime and two hours (which 183 must be decremented in real time) in a Router Advertisement 184 message as described in Section 5.5.3, (e) of [RFC4862]" 186 3. IANA Considerations 188 This document has no actions for IANA. 190 4. Security Considerations 192 This document discusses a problem that may arise in scenarios where 193 dynamic IPv6 prefixes are employed, and proposes improvements to 194 Customer Edge Routers [RFC7084] to mitigate the problem for 195 residential or small office scenarios. It does not introduce new 196 security issues. 198 5. Acknowledgments 200 The authors would lie to thank (in alphabetical order) Mikael 201 Abrahamsson, Luis Balbinot, Tim Chown, Brian Carpenter, Owen DeLong, 202 Gert Doering, Steinar Haug, Nick Hilliard, Philip Homburg, Lee 203 Howard, Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet 204 Martinez, Richard Patterson, Michael Richardson, Mark Smith, Job 205 Snijders, Tarko Tikan, and Ole Troan, for providing valuable comments 206 on [I-D.gont-6man-slaac-renum], on which this document is 207 based.earlier versions of this document. 209 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 210 for a discussion of these issues. Fernando would also like to thank 211 Brian Carpenter who, over the years, has answered many questions and 212 provided valuable comments that has benefited his protocol-related 213 work. 215 6. References 217 6.1. Normative References 219 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 220 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 221 DOI 10.17487/RFC4861, September 2007, 222 . 224 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 225 Address Autoconfiguration", RFC 4862, 226 DOI 10.17487/RFC4862, September 2007, 227 . 229 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 230 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 231 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 232 RFC 8415, DOI 10.17487/RFC8415, November 2018, 233 . 235 6.2. Informative References 237 [I-D.gont-6man-slaac-renum] 238 Gont, F., Zorz, J., and R. Patterson, "Improving the 239 Robustness of Stateless Address Autoconfiguration (SLAAC) 240 to Flash Renumbering Events", draft-gont-6man-slaac- 241 renum-02 (work in progress), February 2020. 243 [I-D.gont-v6ops-slaac-renum] 244 Gont, F., Zorz, J., and R. Patterson, "Reaction of 245 Stateless Address Autoconfiguration (SLAAC) to Flash- 246 Renumbering Events", draft-gont-v6ops-slaac-renum-01 (work 247 in progress), November 2019. 249 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 250 Requirements for IPv6 Customer Edge Routers", RFC 7084, 251 DOI 10.17487/RFC7084, November 2013, 252 . 254 Authors' Addresses 256 Fernando Gont 257 SI6 Networks 258 Segurola y Habana 4310, 7mo Piso 259 Villa Devoto, Ciudad Autonoma de Buenos Aires 260 Argentina 262 Email: fgont@si6networks.com 263 URI: https://www.si6networks.com 265 Jan Zorz 266 Go6 Institute 267 Frankovo naselje 165 268 Skofja Loka 4220 269 Slovenia 271 Email: jan@go6.si 272 URI: https://www.go6.si 274 Richard Patterson 275 Sky UK 277 Email: richard.patterson@sky.uk