idnits 2.17.1 draft-ietf-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]), 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. 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 (March 9, 2020) is 1502 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 484, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-nd-cache-init-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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) March 9, 2020 5 Intended status: Standards Track 6 Expires: September 10, 2020 8 Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First- 9 Hop Routers 10 draft-ietf-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 recommends hosts to send unsolicited Neighbor Advertisements upon 20 assigning a new IPv6 address. The proposed change will minimize the 21 delay and packet loss when a host initiate connections to off-link 22 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 September 10, 2020. 41 Copyright Notice 43 Copyright (c) 2020 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 . . . . . . . . . . . 4 62 2.1. Hosts Sending Gratuitous Neighbor Advertisements . . . . 4 63 2.2. Routers Creating Cache Entries Upon Receiving Unsolicited 64 Neighbor Advertisements . . . . . . . . . . . . . . . . . 5 65 3. Avoiding Disruption . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Neighbor Cache Entry Exists in Any State Other That 67 INCOMPLETE . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Neighbor Cache Entry Does Not Exist . . . . . . . . . . . 6 69 3.3. Neighbor Cache Entry is in INCOMPLETE state . . . . . . . 7 70 4. Modifications to RFC-Mandated Behavior . . . . . . . . . . . 7 71 4.1. Modification to RFC4861 Neighbor Discovery for IP version 72 6 (IPv6) . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1.1. Modification to the section 7.2.5 . . . . . . . . . . 7 74 4.1.2. Modification to the section 7.2.6 . . . . . . . . . . 8 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 8.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 The Neighbor Discovery state machine defined in [RFC4861] implies 86 that communications between IPv6 nodes are in most cases bi- 87 directional and if a host A is trying to communicate to its neighbor, 88 host B, the return traffic flows could be expected. So when the host 89 A starts the address resolution process, the target host would also 90 create an entry for the host A address in its neighbor cache. That 91 entry will be used for sending the return traffic to the host A. 93 However when a host sends traffic to off-link destinations a 94 different scenario is observed. After receiving a Router 95 Advertisement the host populates its neighbor cache with the default 96 router IPv6 and link-layer addresses and is able to send traffic to 97 off-link destinations. At the same time the router does not have any 98 cache entries for the host global addresses yet and only starts 99 address resolution upon receiving the first packet of the return 100 traffic flow. While waiting for the resolution to complete routers 101 only keep a very small number of packets in the queue (as recommended 102 in [RFC4861] Section 7.2.2. All subsequent packets arriving before 103 the resolution process finishes are likely to be dropped. It might 104 cause user-visible packet loss and performance degradation 106 The detailed problem statement and the various solution approaches 107 could be found in [I-D.ietf-v6ops-nd-cache-init]. This document 108 summarizes the proposed neighbor discovery updates to address the 109 issue. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 1.2. Terminology 121 ND: Neighbor Discovery, [RFC4861]. 123 SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862]. 125 NS: Neighbor Solicitation, [RFC4861]. 127 NA: Neighbor Advertisement, [RFC4861]. 129 RS: Router Solicitation, [RFC4861]. 131 RA: Router Advertisement, [RFC4861]. 133 LLA: Link-Layer Address. 135 SLLA: Source link-layer Address, an option in the ND packets 136 containing the link-layer address of the sender of the packet 137 [RFC4861]. 139 TLLA: Target link-layer Address, an option in the ND packets 140 containing the link-layer address of the target [RFC4861]. 142 GUA: Global Unicast Address [RFC4291]. 144 DAD: Duplicate Address Detection, [RFC4862]. 146 Optimistic DAD: a modification of DAD, [RFC4429]. 148 2. Proposed Changes to Neighbor Discovery 150 The following changes are proposed to minimize the delay in creating 151 new entries in a router neighbor cache 153 o A host SHOULD send unsolicited NAs upon assigning a new IPv6 154 address to its interface. 156 o A router SHOULD create a new cache entry upon receiving an 157 unsolicited NA from a host. 159 The following sections discuss these changes in more detail. 161 2.1. Hosts Sending Gratuitous Neighbor Advertisements 163 The section 7.2.6 of [RFC4861] discusses using unsolicited Neighbor 164 Advertisement to inform node neighbors of the new link-layer address 165 quickly. The same mechanism could be used to notify the host 166 neighbors about the new network-layer address as well: the host can 167 send gratuitous unsolicited Neighbor Advertisements upon assigning a 168 new global IPv6 address to its interface. 170 To minimize the potential disruption in case of duplicate addresses 171 the host SHOULD NOT set the Override flag for a preferred address and 172 MUST NOT set the Override flag if the address is in Optimistic 173 [RFC4429] state. 175 As the main purpose of sending unsolicited NAs upon configuring a new 176 address is to proactively create a Neighbor Cache entry on the first- 177 hop routers, the gratuitous NAs SHOULD be sent to all-routers 178 multicast address (ff02::2). Limiting the recipients to routers only 179 would help reduce the multicast noise level. If the link-layer 180 devices are performing MLD snooping [RFC4541] then those unsolicited 181 NAs will be only sent to onlink routers instead of being flooded to 182 all nodes. 184 It should be noted that the proposed mechanism does not cause any 185 significant increase in the multicast traffic. The additional 186 multicast unsolicited NA would proactively create a STALE cache entry 187 on routers as discussed below. When the router receives the return 188 traffic flows it does not need to send multicast NSes to the 189 solicited node multicast address but would be sending unicast NSes 190 instead. Therefore total amount of multicast traffic should not 191 increase. 193 Another option to reduce multicast noises would be sending the 194 gratuitous NAs as unicast to all router addresses. However such 195 approach has a serious disadvantage as it requires the host to have 196 the complete list of routers on link and their link-layaer addresses. 197 If not all routers are kept in the Default Router list ([RFC4861] 198 requires a node to keep at least two entries), the unsolicited NA 199 would reach only subset of routers, not nessesary the routers 200 receiving the return traffic flows. If the network provides a first- 201 hop router redundancy traffic flows can be asymmetrical: the host can 202 send traffic to one router while the return packets enters the 203 network via another one. So the router the host is using as its 204 default gateway (and would send a unicast gratuitous NA to) might not 205 be the router which needs the cache entry to be created. In 206 addition, a race condition may occur, if RAs from some routers are 207 delayed and arrive after the unsolicited NA has been sent. 209 As number of routers on a link is expected to be quite small, hosts 210 could send the the multicast gratuitous NAs as Ethernet unicasts, 211 mapping the IPv6 all-routers multicast address ff02::2 to routers 212 Ethernet unicast addresses as per [RFC6085]. This approach would 213 also mitigate the risk of informing an on-link attacker about IPv6 214 addresses assigned to the host. However it has the same 215 disadvantages as sending unicast NAs: the routers the NA is sent to 216 might not be ones routing the return traffic. 218 2.2. Routers Creating Cache Entries Upon Receiving Unsolicited Neighbor 219 Advertisements 221 The section 7.2.5 of [RFC4861] states: "When a valid Neighbor 222 Advertisement is received (either solicited or unsolicited), the 223 Neighbor Cache is searched for the target's entry. If no entry 224 exists, the advertisement SHOULD be silently discarded. There is no 225 need to create an entry if none exists, since the recipient has 226 apparently not initiated any communication with the target". 228 The reasoning behind dropping unsolicited Neighbor Advertisements 229 ("the recipient has apparently not initiated any communication with 230 the target") is valid for onlink host-to-host communication but, as 231 discussed in [I-D.ietf-v6ops-nd-cache-init] it does not really apply 232 for the scenario when the host is announcing its address to routers. 233 Therefore it would be beneficial to allow routers creating new 234 entries upon receiving an unsolicited Neighbor Advertisement. 236 This document suggests that routers SHOULD create a new Neighbor 237 Cache entry when receive an unsolicited Neighbor Advertisement. 239 3. Avoiding Disruption 241 If hosts following the recommendations in this document are using the 242 DAD mechanism defined in [RFC4862], they would send unsolicited NA as 243 soon as the address changes the state from tentative to preferred 244 (after its uniqueness has been verified). However hosts willing to 245 minimize network stack configuration delays might be using optimistic 246 addresses, which means there is a possibility of the address not 247 being unique on the link. The section 2.2 of [RFC4429] discusses 248 measures to ensure that ND packets from the optimistic address do not 249 override any existing neighbor cache entries as it would cause 250 traffic interruption of the rightful address owner in case of address 251 conflict. As hosts willing to speed up their network stack 252 configuration are most likely to be affected by the problem outlined 253 in this document it seems reasonable for such hosts to advertise 254 their optimistic GUAs by sending unsolicited NAs. The main question 255 to consider is the potential risk of overriding the cache entry for 256 the rightful address owner if the optimistic address happens to be 257 duplicated. 259 3.1. Neighbor Cache Entry Exists in Any State Other That INCOMPLETE 261 If the router Neighbor Cache entry for the target address already 262 exists in any state other than INCOMPLETE, then as per section 7.2.5 263 of [RFC4861] an unsolicited NA with the Override flag cleared would 264 change the entry state from REACHABLE to STALE but would not update 265 the entry in any other way. Therefore even if the host sends an 266 unsolicited NA from the its Optimistic address the router cache entry 267 would not be updated with the new Link-Layer address and no impact to 268 the traffic for the rightful address owner is expected. 270 3.2. Neighbor Cache Entry Does Not Exist 272 If there is no entry then it would be created/updated with the 273 supplied LLA and its state set to STALE. In that case as soon as the 274 entry is used for sending traffic to the host, the entry state will 275 be changed to DELAY, then PROBE and the unicast NS will be send. If 276 the DAD process has already failed, the host with the duplicated 277 address would not respond to the unicast NSes. The router will then 278 send multicast NSes which would reach the rightful owner of the 279 address and its LLA will be added to the routerND cache. So in the 280 scenario when the rightful owner does not use the address for 281 communication then it might be a short (a few seconds) period of time 282 when the data packets sent from the outside could reach the host with 283 the optimistic address. However it seems likely that hosts using 284 Optimistic DAD would start sending/receiving traffic right away, so 285 the first return packet would trigger the NUD process and rewrite the 286 cache. 288 3.3. Neighbor Cache Entry is in INCOMPLETE state 290 Another corner case is the INCOMPLETE cache entry for the address. 291 If the host sends an unsolicited NA from the Optimistic address it 292 would update the entry with the host LLA and set the entry to the 293 STALE state. As the INCOMPLETE entry means that the router has 294 started the ND process for the address and the multicast NS has been 295 sent, the rightful owner is expected to reply with solicited NA with 296 the Override flag set. Upon receiving a solicited NA with the 297 Override flag the cache entry will be updated with the TLLA supplied 298 and (as the NA has the Solicited flag set), the entry state will be 299 set to REACHABLE. It would recover the cache entry and set the LLA 300 to the one of the rightful owner. The only potential impact would be 301 for packets arriving to the router after the unsolicited NA from the 302 host but before the rightful owner responded with the solicited NA. 303 Those packets would be sent to the host with the optimistic address 304 instead of its rightful owner. However those packets would have been 305 dropped anyway as until the solicited NA is received the router can 306 not send the traffic. 308 4. Modifications to RFC-Mandated Behavior 310 All normative text in this memo is contained in this section. 312 4.1. Modification to RFC4861 Neighbor Discovery for IP version 6 (IPv6) 314 4.1.1. Modification to the section 7.2.5 316 This document proposes the following changes to the section 7.2.5 of 317 [RFC4861]: 319 ------------------------------------------------------------------ 321 OLD TEXT: 323 When a valid Neighbor Advertisement is received (either solicited or 324 unsolicited), the Neighbor Cache is searched for the target's entry. 325 If no entry exists, the advertisement SHOULD be silently discarded. 326 There is no need to create an entry if none exists, since the 327 recipient has apparently not initiated any communication with the 328 target. 330 NEW TEXT: 332 When a valid Neighbor Advertisement is received (either solicited or 333 unsolicited), the Neighbor Cache is searched for the target's entry. 334 If no entry exists, hosts SHOULD silently discard the advertisement. 335 There is no need to create an entry if none exists, since the 336 recipient has apparently not initiated any communication with the 337 target. Routers SHOULD create a new entry for the target address 338 with the link-layer address set to the Target link-layer address 339 option (if supplied). The entry its reachability state MUST also be 340 set to STALE. If the received Neighbor Advertisement does not 341 contain the Target link-layer address option the advertisement SHOULD 342 be silently discarded. 344 ------------------------------------------------------------------ 346 4.1.2. Modification to the section 7.2.6 348 This document proposes the following changes to the section 7.2.6 of 349 [RFC4861]: 351 OLD TEXT: 353 In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT 354 unsolicited Neighbor Advertisement messages to the all-nodes 355 multicast address. These advertisements MUST be separated by at 356 least RetransTimer seconds. 358 NEW TEXT: 360 In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT 361 unsolicited Neighbor Advertisement messages to the all-nodes 362 multicast address. These advertisements MUST be separated by at 363 least RetransTimer seconds. 365 A host may also wish to notify its first-hop routers when it 366 configures a new global IPv6 address so the routers can proactively 367 populate their neighbor caches with the corresponding entries. In 368 such cases a host SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT 369 Neighbor Advertisement messages. If the address is preferred then 370 the Override flag SHOULD NOT be set. If the address is in the 371 Optimistic state then the Override flag MUST NOT be set. The 372 destination address SHOULD be set to the all-routers multicast 373 address. These advertisements MUST be separated by at least 374 RetransTimer seconds. The first advertisement SHOULD be sent as soon 375 as one of the following events happens: 377 o if Optimistic DAD [RFC4429] is used: a new Optimistic GUA is 378 assigned to the host interface. 380 o if Optimistic DAD is not used: a GUA changes the state from 381 tentative to preferred. 383 ------------------------------------------------------------------ 385 5. IANA Considerations 387 This memo asks the IANA for no new parameters. 389 6. Security Considerations 391 One of the potential attack vectors to consider is a cache spoofing 392 when the attacker might try to install a cache entry for the victim's 393 IPv6 address and the attacker's Link-Layer address. However it 394 should be noted that this document does not propose any changes for 395 the scenario when the ND cache for the given IPv6 address already 396 exists. Therefore it is not possible for the attacker to override 397 any existing cache entry. 399 A malicious host could attempt to exhaust the neighbor cache on the 400 router by creating a large number of STALE entries. However this 401 attack vector is not new and this document does not increase the risk 402 of such an attack: the attacker could do it, for example, by sending 403 a NS or RS packet with SLLAO included. All recommendations from 404 [RFC6583] still apply. 406 Announcing a new address to all-routers multicast address may inform 407 an on-link attacker about IPv6 addresses assigned to the host. 408 However hiding information about the specific IPv6 address should not 409 be considered a security measure as such information is usually 410 disclosed via DAD to all nodes anyway. Network administrators can 411 also mitigate this issue by enabling MLD snooping on the link-layer 412 devices to prevent IPv6 link-local multicast packets being flooded to 413 all onlink nodes. If peer-to-peer onlink communications are not 414 desirable for the given network segment they should be prevented by 415 proper layer2 security mechanisms. Therefore the risk of allowing 416 hosts to send unsolicited Neighbor Advertisements to all-routers 417 multicast address is low. Should the issue needs to be mitigated on 418 the host level, the host can send unsolicited NAs to its routers 419 Ethernet unicast addresses as described in Section 2.1. 421 It should be noted that the proposed mechanism allows hosts to 422 proactively inform their routers about global IPv6 addresses existing 423 on-link. Routers could use that information to distinguish between 424 used and unused addresses to mitigate ND cache exhaustion DoS attacks 425 described in Section 4.3.2 [RFC3756] and [RFC6583]. 427 7. Acknowledgements 429 Thanks to the following people (in alphabetical order) for their 430 comments, review and feedback: Lorenzo Colitti, Fernando Gont, Tatuya 431 Jinmei, Erik Kline, Warren Kumari, Erik Nordmark, Michael Richardson, 432 Mark Smith, Dave Thaler, Pascal Thubert, Loganaden Velvindron, Eric 433 Vyncke. 435 8. References 437 8.1. Normative References 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 445 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 446 2006, . 448 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 449 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 450 . 452 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 453 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 454 DOI 10.17487/RFC4861, September 2007, 455 . 457 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 458 Address Autoconfiguration", RFC 4862, 459 DOI 10.17487/RFC4862, September 2007, 460 . 462 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 463 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 464 May 2017, . 466 8.2. Informative References 468 [I-D.ietf-v6ops-nd-cache-init] 469 Linkova, J., "Neighbor Cache Entries on First-Hop Routers: 470 Operational Considerations", draft-ietf-v6ops-nd-cache- 471 init-01 (work in progress), December 2019. 473 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 474 Neighbor Discovery (ND) Trust Models and Threats", 475 RFC 3756, DOI 10.17487/RFC3756, May 2004, 476 . 478 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 479 "Considerations for Internet Group Management Protocol 480 (IGMP) and Multicast Listener Discovery (MLD) Snooping 481 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 482 . 484 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 485 Extensions for Stateless Address Autoconfiguration in 486 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 487 . 489 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 490 "Address Mapping of IPv6 Multicast Packets on Ethernet", 491 RFC 6085, DOI 10.17487/RFC6085, January 2011, 492 . 494 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 495 Neighbor Discovery Problems", RFC 6583, 496 DOI 10.17487/RFC6583, March 2012, 497 . 499 Author's Address 501 Jen Linkova 502 Google 503 1 Darling Island Rd 504 Pyrmont, NSW 2009 505 AU 507 Email: furry@google.com