idnits 2.17.1 draft-linkova-6man-grand-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 abstract seems to contain references ([RFC4861], [RFC4862], [RFC4429]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC4862, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC4429, but the header doesn't have an 'Updates:' line to match this. 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 (October 27, 2019) is 1642 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: 'RFC4941' is defined on line 397, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance J. Linkova 3 Internet-Draft Google 4 Updates: 4861 (if approved) October 27, 2019 5 Intended status: Standards Track 6 Expires: April 29, 2020 8 Gratuitous Neighor Discovery: Creating Neighbor Cache Entries on First- 9 Hop Routers 10 draft-linkova-6man-grand-00 12 Abstract 14 Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the 15 link-layer addresses of neighboring nodes as well as to discover and 16 maintain reachability information. This document updates [RFC4861] 17 to allow routers to proactively create a Neighbor Cache entry when a 18 new IPv6 address is assigned to a host. It also updates [RFC4862] 19 and [RFC4429] recommending hosts to send unsolicited Neighbor 20 Advertisements upon assigning a new IPv6 address. The proposed 21 change will minimize the delay and packet loss when a host initiate 22 connections to off-link destination from a new IPv6 address. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 29, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Proposed Changes to Neighbor Discovery . . . . . . . . . . . 3 62 2.1. Hosts Sending Gratuitous Neighbor Advertisements . . . . 4 63 2.2. Routers Creating Cache Entries Upon Receiving Unsolicited 64 Neighbor Advertisements . . . . . . . . . . . . . . . . . 4 65 3. Avoiding Disruption . . . . . . . . . . . . . . . . . . . . . 5 66 4. Modifications to RFC-Mandated Behavior . . . . . . . . . . . 6 67 4.1. Modification to RFC4861 Neighbor Discovery for IP version 68 6 (IPv6) . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Modification to the section 7.2.5 . . . . . . . . . . 6 70 4.1.2. Modification to the section 7.2.6 . . . . . . . . . . 7 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 The Neighbor Discovery state machine defined in [RFC4861] implies 82 that communications between IPv6 nodes are in most cases bi- 83 directional and if a host A is trying to communicate to its neighbor, 84 host B, the return traffic flows could be expected. So when the host 85 A start the address resolution process, the target host would also 86 create an entry for the host A address in its neighbor cache. That 87 entry will be used for sending the return traffic to the host A. 89 However when a host sends traffic to off-link destinations the 90 different scenario might be observed. After receiving an RA the host 91 populates its neighbor cache with the default router address and is 92 able to send traffic to off-link destinations. At the same time the 93 router does not have any cache entries for the host global addresses 94 and therefore needs to start address resolution upon receiving the 95 first packet of the return traffic flow. While waiting for the 96 resolution to complete routers only keep a very small number of 97 packets in the queue (as recommended in [RFC4861] Section 7.2.2. It 98 might cause user-visible packet loss and performance degradation. 100 The detailed problem statement and various solution approaches could 101 be found in [I-D.linkova-v6ops-nd-cache-init]. This document 102 summarized the proposed neighbor discovery changes to address the 103 issue. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 1.2. Terminology 115 ND: Neighbor Discovery, [RFC4861]. 117 SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862]. 119 NS: Neighbor Solicitation, [RFC4861]. 121 NA: Neighbor Advertisement, [RFC4861]. 123 RS: Router Solicitation, [RFC4861]. 125 RA: Router Advertisement, [RFC4861]. 127 SLLA: Source link-layer Address, an option in the ND packets 128 containing the link-layer address of the sender of the packet 129 ([RFC4861]). 131 TLLA: Target link-layer Address, an option in the ND packets 132 containing the link-layer address of the target ([RFC4861]). 134 GUA: Global Unicast Address ([RFC4291]). 136 DAD: Duplicate Address Detection, [RFC4862]. 138 Optimistic DAD: a modification of DAD, [RFC4429]. 140 2. Proposed Changes to Neighbor Discovery 142 The following changes are proposed to minimize the delay in creating 143 new entries in a router neighbor cache 144 o A host SHOULD send unsolicited NA upon assigning a new IPv6 145 address to its interface. 147 o A router MAY create a new cache entry upon receiving an 148 unsolicited NA from a host. 150 The following sections discuss these changes in more detail. 152 2.1. Hosts Sending Gratuitous Neighbor Advertisements 154 The section 7.2.6 of [RFC4861] discusses using unsolicited Neighbor 155 Advertisement to inform node neighbors of the new link-layer address 156 quickly. The same mechanism could be used to notify the host 157 neighbors about the new network-layer address as well: the host can 158 send gratuitous unsolicited Neighbor Advertisements upon assigning a 159 new global IPv6 address to its interface. However there is no need 160 for every single device on-link to be aware of another IPv6 address 161 the gratuitous NAs should be sent to all-routers multicast address 162 (ff02::2). Limiting the recipients to routers only would help reduce 163 the multicast noise level. 165 2.2. Routers Creating Cache Entries Upon Receiving Unsolicited Neighbor 166 Advertisements 168 The section 7.2.5 of [RFC4861] states: "When a valid Neighbor 169 Advertisement is received (either solicited or unsolicited), the 170 Neighbor Cache is searched for the target's entry. If no entry 171 exists, the advertisement SHOULD be silently discarded. There is no 172 need to create an entry if none exists, since the recipient has 173 apparently not initiated any communication with the target". 175 The reasoning behind dropping unsolicited Neighbor Advertisements 176 ("the recipient has apparently not initiated any communication with 177 the target") is valid for onlink host-to-host communication but, as 178 discussed in [I-D.linkova-v6ops-nd-cache-init] does not really apply 179 for the scenario when the host is announcing its address to routers. 181 Therefore it would be beneficial to allow routers creating new 182 entries upon receiving an unsolicited Neighbor Advertisement. While 183 such behaviour would not formally violate [RFC4861] it's worth 184 clarifying the difference in the expected behaviour between hosts and 185 routers and provide explicit recommendations for routers. 187 This document suggests that routers MAY create a new Neighbor Cache 188 entry when receive an unsolicited Neighbor Advertisement. 190 3. Avoiding Disruption 192 If hosts following the recommendations in this document are using the 193 DAD mechanism defined in [RFC4862], they would send unsolicited NA as 194 soon as the address changes the state from tentative to preferred 195 (after its uniqueness has been verified). However hosts willing to 196 minimize network stack configuration delays might be using optimistic 197 addresses, which means there is a possibility of the address not 198 being unique on the link. The section 2.2 of [RFC4429] discusses 199 measures to ensure that ND packets from the optimistic address do not 200 override any existing neighbor cache entries as it would cause 201 traffic interruption of the rightful address owner in case of address 202 conflict. 204 As hosts willing to speed up their network stack configuration are 205 most likely to be affected by the problem outlined in this document 206 it seems reasonable for such hosts to advertise their optimistic GUAs 207 by sending unsolicited NAs. The main question to consider is the 208 potential risk of overriding the cache entry for the rightful address 209 owner if the optimistic address happens to be duplicated. 211 As per section 7.2.5 of [RFC4861] if the Neighbor Cache entry for the 212 target address already exists and is in in any state other than 213 INCOMPLETE then the only change the unsolicited NA could cause is to 214 change the entry from REACHABLE to STALE. It would not cause any 215 traffic interruption for the rightful address owner. 217 If there is no entry then it would be created/updated with the 218 supplied LLA and its state set to STALE. In that case as soon as the 219 entry is used for sending traffic to the host, the entry state will 220 be changed to DELAY and the Neighbor Unreachability Detection would 221 be started and the rightful owner LLA will be entered in the cache. 222 So in the scenario when the rightful owner does not use the address 223 for communication then it might be a short (a few seconds) period of 224 time when the data packets sent from the outside could reach the host 225 with the optimistic address. However it seems likely that hosts 226 using Optimistic DAD would start sending/receiving traffic right 227 away, so the first return packet would trigger the NUD process and 228 rewrite the cache. 230 Another corner case is the INCOMPLETE cache entry for the address. 231 If the host sends an unsolicited NA from the Optimistic address it 232 would update the entry with the host LLA and set the entry to the 233 STALE state. As the INCOMPLETE entry means that the router has 234 started the ND process for the address and the multicast NS has been 235 sent, the rightful owner is expected to reply with solicited NA which 236 would recover the cache entry and set the LLA to the rightful owner's 237 one. The risk here: 239 o The data packet arrives after the unsolicited NA from the host but 240 before the rightful owner responded with the solicited NA. Those 241 packets would be sent to the host with the optimistic address 242 instead of its rightful owner. However without the unsolicited NA 243 those packets would have been dropped anyway (as the entry was in 244 INCOMPLETE state). 246 4. Modifications to RFC-Mandated Behavior 248 All normative text in this memo is contained in this section. 250 4.1. Modification to RFC4861 Neighbor Discovery for IP version 6 (IPv6) 252 4.1.1. Modification to the section 7.2.5 254 This document proposes the following changes to the section 7.2.5 of 255 [RFC4861]: 257 ------------------------------------------------------------------ 259 OLD TEXT: 261 When a valid Neighbor Advertisement is received (either solicited or 262 unsolicited), the Neighbor Cache is searched for the target's entry. 263 If no entry exists, the advertisement SHOULD be silently discarded. 264 There is no need to create an entry if none exists, since the 265 recipient has apparently not initiated any communication with the 266 target. 268 NEW TEXT: 270 When a valid Neighbor Advertisement is received (either solicited or 271 unsolicited), the Neighbor Cache is searched for the target's entry. 272 If no entry exists, hosts SHOULD silently discard the advertisement. 273 There is no need to create an entry if none exists, since the 274 recipient has apparently not initiated any communication with the 275 target. Routers MAY create a new entry for the target address with 276 the link-layer address set to the Target link-layer address option 277 (if supplied). The entry its reachability state MUST also be set to 278 STALE. If the received Neighbor Advertisement does not contain the 279 Target link-layer address option the advertisement SHOULD be silently 280 discarded. Routers SHOULD have a configuration knob to enable 281 creating a new cache entry upon receiving an unsolicited Neighbor 282 Advertisement on a specific interface. 284 ------------------------------------------------------------------ 286 4.1.2. Modification to the section 7.2.6 288 This document proposes the following changes to the section 7.2.6 of 289 [RFC4861]: 291 OLD TEXT: 293 In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT 294 unsolicited Neighbor Advertisement messages to the all-nodes 295 multicast address. These advertisements MUST be separated by at 296 least RetransTimer seconds. 298 NEW TEXT: 300 In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT 301 unsolicited Neighbor Advertisement messages to the all-nodes 302 multicast address. These advertisements MUST be separated by at 303 least RetransTimer seconds. 305 A host may also wish to notify its first-hop routers when it 306 configures a new global IPv6 address so the routers can proactively 307 populate their neighbor caches with the corresponding entries. In 308 such cases a host SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT 309 unsolicited Neighbor Advertisement messages to the all-routers 310 multicast address. These advertisements MUST be separated by at 311 least RetransTimer seconds. The first advertisement SHOULD be sent 312 as soon as one of the following events happens: 314 o if Optimistic DAD [RFC4429] is used: a new Optimistic GUA is 315 assigned to the host interface. 317 o if Optimistic DAD is not used: a GUA changes the state from 318 tentative to preferred. 320 ------------------------------------------------------------------ 322 5. IANA Considerations 324 This memo asks the IANA for no new parameters. 326 6. Security Considerations 328 One of the potential attack vectors to consider is a cache spoofing 329 when the attacker might try to install a cache entry for the victim's 330 IPv6 address and the attacker's Link-Layer address. However it 331 should be noted that this document does not propose any changes for 332 the scenario when the ND cache for the given IPv6 address already 333 exists. Therefore it is not possible for the attacker to override 334 any existing cache entry. 336 A malicious host could attempt to exhaust the neighbor cache on the 337 router by creating a large number of STALE entries. However this 338 attack vector is not new and this document does not increase the risk 339 of such an attack: the attacker could do it, for example, by sending 340 a NS or RS packet with SLLAO included. All recommendations from 341 [RFC6583] still apply. 343 Announcing a new address to all-routers multicast address may inform 344 an on-link attacker about IPv6 addresses assigned to the host. 345 However hiding information about the specific IPv6 address should not 346 be considered a security measure as it falls into 'Security through 347 obscurity' category. If peer-to-peer onlink communications are not 348 desirable they should be prevented by proper layer2 security 349 mechanisms. Therefore the risk of allowing hosts to send unsolicited 350 Neighbor Advertisements to all-routers multicast address is low. 352 7. Acknowledgements 354 Thanks to the following people (in alphabetical order) for their 355 review and feedback: Lorenzo Colitti, Tatuya Jinmei, Erik Kline, 356 Warren Kumari, Michael Richardson, Pascal Thubert, Loganaden 357 Velvindron, Eric Vyncke. 359 8. References 361 8.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 369 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 370 2006, . 372 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 373 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 374 . 376 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 377 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 378 DOI 10.17487/RFC4861, September 2007, 379 . 381 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 382 Address Autoconfiguration", RFC 4862, 383 DOI 10.17487/RFC4862, September 2007, 384 . 386 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 387 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 388 May 2017, . 390 8.2. Informative References 392 [I-D.linkova-v6ops-nd-cache-init] 393 Linkova, J., "Neighbor Cache Entries on First-Hop Routers: 394 Operational Considerations", draft-linkova-v6ops-nd-cache- 395 init-01 (work in progress), July 2019. 397 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 398 Extensions for Stateless Address Autoconfiguration in 399 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 400 . 402 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 403 Neighbor Discovery Problems", RFC 6583, 404 DOI 10.17487/RFC6583, March 2012, 405 . 407 Author's Address 409 Jen Linkova 410 Google 411 1 Darling Island Rd 412 Pyrmont, NSW 2009 413 AU 415 Email: furry@google.com