idnits 2.17.1 draft-olopade-6man-slaac-signaling-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 draft header indicates that this document updates RFC4862, 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- 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 (October 19, 2020) is 1285 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) == Unused Reference: 'RFC4861' is defined on line 168, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 173, but no explicit reference was found in the text == Unused Reference: 'RFC8028' is defined on line 178, but no explicit reference was found in the text == Unused Reference: 'RFC8504' is defined on line 192, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-cpe-slaac-renum' is defined on line 198, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-slaac-renum' is defined on line 204, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-slaac-renum' is defined on line 210, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-cpe-slaac-renum-02 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-slaac-renum-04 == Outdated reference: A later version (-07) exists of draft-ietf-6man-slaac-renum-01 -- No information found for draft-linkova-6man-default-addr-selection - is the name correct? == Outdated reference: A later version (-07) exists of draft-ietf-6man-grand-03 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance (6man) Working Group Loba Olopade 3 Internet-Draft Virgin Media 4 Updates: 4862 (if approved) October 19, 2020 5 Intended status: Standards Track 6 Expires: April 22, 2021 8 Explicit signaling of Stateless Address Autoconfiguration (SLAAC) 9 to Renumbering Events 10 draft-olopade-6man-slaac-signaling-00 12 Abstract 14 After a renumbering event in an IPv6 network utilizing SLAAC, hosts 15 might continue to use stale addresses, as they are unaware of the 16 changes. Likewise, routers, who may deprecate the use of these 17 prefixes, are unaware of their use on the hosts. This scenario could 18 have an adverse effect on communication with the host. This document 19 proposes changes to the SLAAC algorithm that will explicitly allow 20 routers to learn of these stale prefixes that are still assigned on 21 the network. 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 https://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 November 19, 2020. 40 Copyright Notice 42 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. SLAAC reaction to new PIOs . . . . . . . . . . . . . . . . . . 3 60 3.1. Proposed Change . . . . . . . . . . . . . . . . . . . . . 4 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 67 Appendix A. Suggested Garbage collection of stale prefix 68 information . . . . . . . . . . . . . . . . . . . . . . . 6 69 A.1 Prefix Validation . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 After a renumbering event in an IPv6 network utilizing SLAAC, hosts 75 might continue to use stale addresses, as they are unaware of the 76 changes. Likewise, routers, who may deprecate the use of these 77 prefixes, are unaware of their use on the hosts. This scenario, with 78 its causes and impacts are well documented in [I-D.ietf-v6ops-slaac- 79 renum] and [I-D.linkova-6man-default-addr-selection-update]. A key 80 factor with this issue is the lack of explicit signaling. For various 81 reasons, routers might not explicitly signal the network that there 82 is a renumbering event. Once the renumbering event has occurred, 83 there are no means to learn of the stale prefixes that might still be 84 present on the network. Without a means to do a garbage collection, 85 the network is limited to the aging out process of stale 86 information. 88 Rather than aging out, it would be better for routers to learn of 89 this information, in a proactive manner. Using Neighbor Discovery 90 messages, the router could learn of the stale prefixes. 92 While it is not the objective of this document to propose how the 93 stale prefix information is validated and deprecated, an example of 94 how this might be done is given in Appendix A. 96 2. Terminology 98 The term "globally reachable" is used in this document as defined in 99 [RFC8190]. 101 The term "Global Unicast Address" (or its acronym "GUA") is used 102 throughout this document to refer to "globally reachable" [RFC8190] 103 addresses. That is, when used throughout this document, GUAs do NOT 104 include Unique Local Addresses (ULAs) [RFC4193]. Similarly, the term 105 "Global Unicast prefix" (or "GUA prefix") is employed throughout this 106 document to refer to network prefixes that specify GUAs, and does NOT 107 include the ULA prefix (FC00::/7) [RFC4193]. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 3. SLAAC reaction to new PIOs 117 In the absence of RA messages to deprecate stale prefixes, when RAs 118 are received with new PIO information, SLAAC hosts will form 119 additional IPv6 address on the interface. This could lead to a 120 situation where there are multiple addresses assigned to an 121 interface, while only a subset of them are valid. As previously 122 stated, with the current algorithm, there is no explicit way to 123 inform routers of the stale prefixes that are currently assigned to 124 the interfaces. 126 3.1. Proposed Change 128 When an address transitions from being tentative to preferred, for 129 each SLAAC assigned GUA address on the interface, the host should 130 send router solicitation messages, using the GUA as the source 131 address. Routers receiving the solicitation messages can deduce the 132 prefixes that are currently assigned to interfaces on the network. 133 They can then determine if these prefixes are still valid, and 134 proceed to deprecate them if they are not. 136 An alternate solution would use unsolicited Neighbor Advertisement, 137 similar to what is proposed in [I-D.ietf-6man-grand-03]. This would 138 still require NA messages for each SLAAC assigned GUA address on the 139 interface. 141 4. IANA Considerations 143 This document has no actions for IANA. 145 5. Security Considerations 147 It is not believed that this introduces any additional security risk. 149 6. Acknowledgments 151 The author would like to acknowledge Jen Linkova, Fernando Gont, Jan 152 Zorz and Richard Patterson for the work they have previously done on 153 this issue. 155 7. References 157 7.1. Normative References 159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 160 Requirement Levels", BCP 14, RFC 2119, 161 DOI 10.17487/RFC2119, March 1997, 162 . 164 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 165 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 166 . 168 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 169 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 170 DOI 10.17487/RFC4861, September 2007, 171 . 173 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 174 Address Autoconfiguration", RFC 4862, 175 DOI 10.17487/RFC4862, September 2007, 176 . 178 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 179 Hosts in a Multi-Prefix Network", RFC 8028, 180 DOI 10.17487/RFC8028, November 2016, 181 . 183 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 184 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 185 May 2017, . 187 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 188 "Updates to the Special-Purpose IP Address Registries", 189 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 190 . 192 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 193 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 194 January 2019, . 196 7.2. Informative References 198 [I-D.ietf-v6ops-cpe-slaac-renum] 199 Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving 200 the Reaction of Customer Edge Routers to Renumbering 201 Events", draft-ietf-v6ops-cpe-slaac-renum-02 (work in 202 progress), May 2020. 204 [I-D.ietf-v6ops-slaac-renum] 205 Gont, F., Zorz, J., and R. Patterson, "Reaction 206 of Stateless Address Autoconfiguration (SLAAC) to Flash- 207 Renumbering Events", draft-ietf-v6ops-slaac-renum-04 208 (work in progress), September 2020. 210 [I-D.ietf-6man-slaac-renum] 211 Gont, F., Zorz, J., and R. Patterson, "Improving the 212 Robustness of Stateless Address Autoconfiguration (SLAAC) 213 to Flash Renumbering Events", 214 draft-ietf-6man-slaac-renum-01 (work in progress), 215 September 2020. 217 [I-D.linkova-6man-default-addr-selection-update] 218 Linkova, J., "Default Address Selection and Subnet 219 Renumbering", 220 draft-linkova-6man-default-addr-selection-00 221 (work in progress), March 2017. 223 [I-D.ietf-6man-grand-03] 224 Linkova, J., "Gratuitous Neighbor Discovery: Creating 225 Neighbor Cache Entries on First-Hop Routers", 226 draft-ietf-6man-grand-03 (work in progress), March 2017. 228 Appendix A. Suggested Garbage collection of stale prefix information 230 Consider a scenario where a service provider is using non-persistent 231 prefixes. If the router were to reboot, for whatever reason, then the 232 a new PD is assigned to the router. The router will then start to 233 include the new PIOs in its RA messages. At this point, hosts on the 234 LAN will assign additional IPv6 addresses from the new prefix, on 235 their interface. Using the proposed algorithm, the router will 236 receive RS messages from hosts with source address from the stale 237 prefixes. 239 Upon receipt of the RS messages, the router can proceed to create a 240 neighbor cache for the address. Before creating the neighbor cache, 241 it should validate that the prefix is valid for the LAN interface. 243 Once validated, the neighbor cache entry can be created. A list of 244 unmanaged on-link prefixes should also be maintained. These prefixes 245 should not be included in its RA messages. 247 If the prefix validation is not successful, the router should 248 deprecate the prefix in its RA messages. 250 A.1 Prefix Validation 251 Routers should maintain a list for "unmanaged on-link prefixes". 252 These are prefixes that the router has determined are on-link, but 253 are not included in its RA messages. The list may be maintained by 254 static configuration, dynamic methods or both. 256 To validate a prefix, the router may do the following 258 o Check if the prefix is included in the list of unmanaged on-link 259 prefixes for the received interface. If not included, continue 260 with other validation steps. Otherwise, conclude the validation 261 with a success. 262 o Use a protocol (e.g. DHCPv6 leasequery) to check who the prefix is 263 assigned to. If assigned to itself, it should begin to include the 264 prefix in its RA messages and conclude the validation process with 265 a success. 266 o Send a RS message on the interface, and listen to see if the 267 prefix is included in received RA messages. RS messages must be 268 sent with unspecified source address, so that hosts will not 269 change the IsRouter flag for the router. If the prefix is 270 included, the unmanaged on-link list should be updated, and the 271 validation concluded as successful. 273 Authors' Addresses 275 Loba Olopade 276 Virgin Media 278 Email: loba.olopade@virginmedia.co.uk