idnits 2.17.1 draft-templin-6man-rio-redirect-03.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2017) is 2539 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: 'RFC0791' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 502, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Updates: rfc4191, rfc4861 (if approved) J. Woodyatt 5 Intended status: Standards Track Google 6 Expires: November 13, 2017 May 12, 2017 8 Route Information Options in IPv6 Neighbor Discovery 9 draft-templin-6man-rio-redirect-03.txt 11 Abstract 13 The IPv6 Neighbor Discovery (ND) protocol provides a Router 14 Solicitation (RS) function allowing nodes to solicit a Router 15 Advertisement (RA) response from an on-link router, a Neighbor 16 Solicitation (NS) function allowing nodes to solicit a Neighbor 17 Advertisement (NA) response from an on-link neighbor, and a Redirect 18 function allowing routers to inform nodes of a better next hop 19 neighbor on the link toward the destination. This document specifies 20 backward-compatible extensions to IPv6 ND messages to support the 21 discovery of more-specific routes. 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 http://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 13, 2017. 40 Copyright Notice 42 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Route Information Options in IPv6 Neighbor Discovery Messages 4 61 4.1. Classical Redirection Scenario . . . . . . . . . . . . . 4 62 4.2. RIO Redirection Scenario . . . . . . . . . . . . . . . . 6 63 4.2.1. Router Specification . . . . . . . . . . . . . . . . 6 64 4.2.2. Source Specification . . . . . . . . . . . . . . . . 6 65 4.2.3. Target Specification . . . . . . . . . . . . . . . . 7 66 4.2.4. Operation Without Redirects . . . . . . . . . . . . . 8 67 4.2.5. Multiple RIOs . . . . . . . . . . . . . . . . . . . . 8 68 4.2.6. Why NS/NA? . . . . . . . . . . . . . . . . . . . . . 8 69 4.2.7. RIOs in RS Messages . . . . . . . . . . . . . . . . . 9 70 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Appendix A. Link-layer Address Changes . . . . . . . . . . . . . 12 78 Appendix B. Interfaces with Multiple Link-Layer Addresses . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] (IPv6 ND) 84 provides a Router Solicitation (RS) function allowing nodes to 85 solicit a Router Advertisement (RA) response from an on-link router, 86 a Neighbor Solicitation (NS) function allowing nodes to solicit a 87 Neighbor Advertisement (NA) response from an on-link neighbor, and a 88 Redirect function allowing routers to inform nodes of a better next 89 hop neighbor on the link toward the destination. Further guidance 90 for processing Redirect messages is given in "First-Hop Router 91 Selection by Hosts in a Multi-Prefix Network" [RFC8028]. 93 "Default Router Preferences and More-Specific Routes" [RFC4191] 94 specifies a Route Information Option (RIO) that routers can include 95 in RA messages to inform recipients of more-specific routes. This 96 document specifies a backward-compatible extension to allow nodes to 97 include RIOs in other IPv6 ND messages to support the dynamic 98 discovery of more-specific routes. 100 2. Terminology 102 The terminology in the normative references applies. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. Lower case 107 uses of these words are not to be interpreted as carrying RFC2119 108 significance. 110 3. Motivation 112 An example of a good application for RIO is the local-area subnets 113 served by the routers described in "Basic Requirements for IPv6 114 Customer Edge Routers" [RFC7084]. While many customer edge routers 115 are capable of operating in a mode with a dynamic routing protocol 116 operating in the local-area network, the default mode of operation is 117 typically designed for unmanaged operation without any dynamic 118 routing protocol. On these networks, the only means for any node to 119 learn about routers on the link is by using the Router Discovery 120 protocol described in [RFC4861]. 122 Nevertheless, hosts on unmanaged home subnets may use "IPv6 Prefix 123 Options for DHCPv6" [RFC3633] (DHCPv6 PD) to receive IPv6 routing 124 prefixes for additional subnets allocated from the space provided by 125 the service provider, and operate as routers for other links where 126 hosts in delegated subnets are attached. Hosts may even learn about 127 more specific routes than the default route by processing RIOs in RA 128 messages according to the rules for Type "C" hosts described in 129 [RFC4191]. 131 However, due to perceptions of the security considerations for hosts 132 in processing RIOs on unmanaged networks, the default configuration 133 for common host IPv6 implementations is not Type "C" behavior. 134 Accordingly, on typical home networks the forwarding path from hosts 135 on one subnet to destinations on every off-link local subnet always 136 passes through the customer edge router, even when a shorter path 137 would otherwise be available through an on-link router. This adds 138 costs for retransmission on shared LAN media, often adding latency 139 and jitter with queuing delay and delay variability. This is not 140 materially different under the scenarios described in "IPv6 Home 141 Networking Architecture Principles" [RFC7368] except that routers may 142 use an interior dynamic routing protocol to coordinate sending of 143 RIOs in RA messages, which as explained above, are not processed by 144 typical hosts. 146 In increasingly common practice, nodes that receive prefix 147 delegations may connect an entourage of "Internet of Things" back end 148 devices. The node may therefore appear as a router from the 149 perspective of the back end devices but behave as a host on the link 150 from the perspective of receiving Redirects and without participating 151 in a dynamic routing protocol. Instead, the node sends initial 152 packets with a source address taken from one of the node's delegated 153 prefixes via a default or more-specific route with a router on the 154 link as the next-hop. The router may return a Redirect message with 155 an RIO if there is a target node on the link that would be a better 156 next-hop for the destination. The target may itself be a holder of 157 prefix delegations that behaves in a similar fashion as the source 158 node. Examples of where such relationships apply include civil 159 aviation networks, unmanned aerial vehicle networks and enterprise 160 networks that host mobile end user devices (e.g., cell phones, 161 tablets, laptops, etc.). 163 By using RIOs in IPv6 ND messages, the forwarding path between 164 subnets can be shortened while accepting a much narrower opening of 165 attack surfaces on general purpose hosts related to the Router 166 Discovery protocol. The basic idea is simple: hosts normally send 167 packets for off-link destinations to their default router unless they 168 receive ND Redirect messages designating another on-link node as the 169 target. This document allows ND Redirects additionally to suggest 170 another on-link node as the target for one or more routing prefixes, 171 including one with the destination. Hosts that receive RIOs in ND 172 Redirect messages then unicast NS messages to the target containing 173 those RIOs, and process the unicast NA messages the target sends in 174 reply. If hosts only process RIOs in NA messages when they have 175 previously unicast them in NS messages to the targets of received ND 176 Redirect messages, then hosts only process RIO at the initiative of 177 routers they already accept as authoritative. 179 4. Route Information Options in IPv6 Neighbor Discovery Messages 181 The RIO is specified for inclusion in RA messages in Section 2.3 of 182 [RFC4191], while the neighbor discovery functions are specified in 183 [RFC4861]. This specification permits routers to include RIOs in 184 other IPv6 ND messages so that recipients can discover a better next 185 hop for a destination *prefix* instead of just a specific 186 destination. This specification therefore updates [RFC4191] and 187 [RFC4861], as discussed in the following sections. 189 4.1. Classical Redirection Scenario 191 In the classical redirection scenario there are three actors, namely 192 the Source, Router and Target as shown in Figure 1: 194 +-------------------+ 195 | | 196 | Router | 197 | | 198 +---------+---------+ 199 | 200 | 201 X---------+----------------+---------------+---------X 202 | Link | 203 | | 204 +---------+---------+ +----------+--------+ 205 | | | | 206 | Source | | Target | 207 | | | | 208 +-------------------+ +---------+---------+ 209 | 210 2001:db8::/N 211 | 212 X-+----+--+-------+-X 213 | | | 214 +--+ +--+ +--+ 215 |H1| |H2| .... |Hn| 216 +--+ +--+ +--+ 218 Figure 1: Classical Redirection Scenario 220 In addition, the Target may be a router that connects an arbitrarily- 221 complex set of IPv6 networks (e.g., as depicted by 2001:db8::/N in 222 the figure) with hosts H(i). 224 In this scenario, the Source initially has no route for 2001:db8::/N 225 and must send initial packets destined to correspondents H(i) via a 226 first-hop Router. Upon receiving the packets, the Router forwards 227 the packets to the Target and may also send a Redirect message back 228 to the Source with a destination address corresponding to the packet 229 that triggered the Redirect, the target link-local address and the 230 target link-layer address. After receiving the message, the Source 231 may begin sending packets destined to H(i) directly to the Target, 232 which will then forward them to its connected networks. 234 This specification augments the classical Redirection scenario by 235 allowing the Router to include an entire prefix (e.g., 2001:db8::/N) 236 in an RIO option in the Redirect message, and thereafter allowing the 237 Source to include an RIO in an NS message and the Target to include 238 an RIO in its NA response. The following sections present this 239 "augmented" RIO redirection scenario. 241 4.2. RIO Redirection Scenario 243 In the RIO redirection scenario, the Source sends initial packets via 244 the Router the same as in the classical scenario. When the Router 245 receives the packets, it searches its routing tables for a route that 246 is assigned to the Target and that covers the destination address of 247 the packet. The Router then includes this prefix in an RIO in a 248 Redirect message to send back to the Source. When the Source 249 receives the Redirect message, it includes the RIO in an NS message 250 to send to the Target. When the Target receives the NS message, it 251 first verifies that the prefix included in the RIO is indeed one of 252 its own prefixes. If so, the Target fills in the Prefix, Route 253 Lifetime and Prf values in the RIO option, and returns the option in 254 a unicast NA message reply to the Source. The Source can then 255 install the prefix in the RIO option in its routing table. The 256 following sections present more detailed specifications for the 257 Router, Source and Target. 259 4.2.1. Router Specification 261 When the Router receives a packet from the Source that is destined to 262 a host in an IPv6 network aggregated by the Target, the Router 263 searches its routing table for a prefix that covers the destination 264 address(e.g., 2001:db8::/N, as depicted in Figure 1). The Router 265 then prepares a Redirect message with the Destination field set to 266 the packet's IPv6 destination address, with the Target field set to 267 the link-local address of the Target, with a Target Link-Layer 268 Address option (TLLAO) set to the link-layer address of the Target, 269 and with an RIO that includes a Prefix for the destination with Route 270 Lifetime and Prf set to 0. The Router then sends the Redirect 271 message to the Source (subject to rate limiting). 273 4.2.2. Source Specification 275 According to [RFC4861], a Source that receives a valid Redirect 276 message updates its destination cache per the Destination Address and 277 its neighbor cache per the Target Address. According to [RFC4191], 278 Sources can be classified as Type "A", "B" or "C" based on how they 279 process RIOs, where a Type "C" Source updates its routing table per 280 any RIO elements included in an RA message. Finally, according to 281 [RFC8028], a Type "C" Source operating on a Multi-Prefix Network with 282 multiple default routes can make source address selection decisions 283 based on information in its routing table decorated with information 284 derived from the source of the RIO element. 286 In light of these considerations, this document introduces a new Type 287 "D" behavior for Sources with the same behavior as a Type "C" Source, 288 but which also process RIO elements in Redirect and NA messages, and 289 include RIO elements in NS messages. Type "D" Sources process 290 Redirect messages with RIO elements by first verifying that the 291 Prefix in the first RIO matches the Destination address. If the 292 Destination address does not match the Prefix, the Source discards 293 the Redirect message. Otherwise, the Source updates its neighbor 294 cache per the Target Address and its destination cache per the 295 Destination Address the same as for classical redirection. Next, the 296 Source MAY send an NS message containing an RIO option to the Target 297 to elicit an NA response. 299 When the Type 'D' Source receives the solicited NA message from the 300 Target, if the NA includes an RIO with a Prefix matching the one that 301 it received in the Redirect message the Source installs the Prefix in 302 its routing table including the Route Lifetime and Prf values, and 303 with the Target's address as the next hop. 305 After the Source installs the Prefix in its routing table, it MAY 306 then begin sending packets with destination addresses that match the 307 Prefix directly to the Target Instead of sending them to the Router. 308 The Source SHOULD decrement the Route Lifetime and MAY send new NS 309 messages to receive a fresh Route Lifetime (if the Route Lifetime 310 decrements to 0, the Source instead deletes the route from its 311 routing table). The Source MAY furthermore delete the route at any 312 time and again allow packets to flow through the Router which may 313 send a fresh Redirect. The Source should then again test the route 314 by performing a unicast NS/NA exchange with the Target the same as 315 described above. 317 After updating its routing table, the Source MAY receive an 318 unsolicited NA message from the Target with an RIO with new Route 319 Lifetime and/or Prf values. If the RIO Prefix is in its routing 320 table, and if the Route Lifetime value is 0, the Source deletes the 321 corresponding route. 323 After updating its routing table, the Source MAY also receive a 324 Destination Unreachable message from the Target with Code 0 ("no 325 route to destination"). If so, the Source again deletes the 326 corresponding route from its routing table. 328 4.2.3. Target Specification 330 When the Target receives an NS message from the Source containing an 331 RIO, it examines the Prefix to see if it matches one of the prefixes 332 in its prefix list. If so, the Target copies the RIO into a unicast 333 NA message to send back to the Source and fills in the Route Lifetime 334 and Prf fields with values that are consistent with its prefix list. 335 The Target then sends the NA message back to the Source. 337 At some later time, the Target may either alter or deprecate the 338 corresponding prefix in its prefix list. If the Target has sent 339 solicited NA messages with RIO options to one or more Sources, the 340 Target SHOULD send unsolicited NA messages with RIOs that include the 341 Prefix and with Route Lifetime set to 0. If the Target receives 342 packets with destination addresses that do not match a prefix in its 343 prefix list, the target sends a Destination Unreachable message to 344 the Source with Code 0 ("no route to destination"), subject to rate 345 limiting. 347 4.2.4. Operation Without Redirects 349 If the Source has some way to determine the Target's link-local 350 address without receiving a Redirect message from the Router, the 351 Source MAY send an NS message with an RIO directly to the Target with 352 the Prefix field set to the destination address of an IPv6 packet and 353 with Prefix Length set to 128. 355 When the Target receives the NS message, it prepares an NA response 356 with an RIO that includes a Prefix and Prefix length for one of its 357 prefixes that covers the destination address. The Target then sends 358 the NA message to the Source. 360 Before accepting the NA message, the Source must have assurance that 361 the Target is authoritative for its claimed Prefix and Prefix length 362 (e.g., through an authoritative intermediate node that examines the 363 message and drops it if the claims are invalid). 365 4.2.5. Multiple RIOs 367 If a Redirect includes multiple RIOs, the Source only checks the 368 destination address for a match against the Prefix in the first RIO. 370 If an NA message includes multiple RIOs, the Source only accepts 371 those Prefixes for which it has some way of knowing that the Target 372 is the correct next hop (e.g., via a Redirect). 374 If an NS message includes multiple RIOs, the Target only responds to 375 those Prefixes with matching entries in its prefix list. 377 4.2.6. Why NS/NA? 379 Since [RFC4191] already specifies the inclusion of RIOs in RA 380 messages, a natural question is why this document advocates the use 381 of NS/NA instead of RS/RA? 383 First, NS/NA exchanges used by the IPv6 Neighbor Unreachability 384 Detection (NUD) procedure are unicast-only whereas RA responses to RS 385 messages are typically sent as multicast. Since this mechanism must 386 operate only between the Source and Target without disturbing any 387 other nodes on the link, the use of unicast-only exchanges is 388 required. 390 Second, the IPv6 ND specification places restrictions on minimum 391 delays between RA messages. Since this mechanism expects an 392 immediate advertisement from the Target in response to the Source's 393 solicitation, only the NS/NA exchange can satisfy this property. 395 Third, the RA message is the "swiss army knife" of the IPv6 ND 396 protocol. RA messages carry numerous configuration parameters for 397 nodes on the link, including Cur Hop Limit, M/O flags, Router 398 Lifetime, Reachable Time, Retrans Time, Prefix Information Options, 399 MTU options, etc. The Target must not advertise any of this 400 information to the soliciting Source. 402 Finally, operators are deeply concerned about the security of RA 403 messages - so much so that they deploy link security mechanisms that 404 drop RA messages originating from nodes claiming to be an 405 authoritative router for the link. 407 4.2.7. RIOs in RS Messages 409 This document permits a source host to include RIOs in RS messages in 410 order to solicit RIOs in the corresponding RA messages from a trusted 411 router. The RS/RA RIO exchange is conducted in the same fashion as 412 for NS/NA exchanges, with the exception that RA messages may be 413 returned as multicast and/or may also include other configuration 414 information for the link. 416 5. Implementation Status 418 The IPv6 ND functions and RIOs are widely deployed in IPv6 419 implementations. 421 6. IANA Considerations 423 This document introduces no IANA considerations. 425 7. Security Considerations 427 The Redirect message validation rules in Section 8.1 of [RFC4861] 428 require recipients to verify that the IP source address of the 429 Redirect is the same as the current first-hop router for the 430 specified ICMP Destination Address. Recipients therefore naturally 431 reject any Redirect message with an incorrect source address. 433 Other security considerations for IPv6 ND messages that include RIOs 434 are the same as specified in Section 11 of [RFC4861]. Namely, the 435 protocol must take measures to secure IPv6 ND messages on links where 436 spoofing attacks are possible. 438 A spoofed ND message containing no RIOs could cause corruption in the 439 recipient's destination cache, while a spoofed ND message containing 440 RIOs could corrupt the host's routing tables. While the latter would 441 seem to be a more onerous result, the possibility for corruption is 442 unacceptable in either case. 444 "IPv6 ND Trust Models and Threats" [RFC3756] discusses spoofing 445 attacks, and states that: "This attack is not a concern if access to 446 the link is restricted to trusted nodes". "SEcure Neighbor Discovery 447 (SEND)" [RFC3971] provides one possible mitigation for other cases. 449 "IPv6 Router Advertisement Guard" [RFC6105] ("RA Guard") describes a 450 layer-2 filtering technique intended for network operators to use in 451 protecting hosts from receiving RA messages sent by nodes that are 452 not among the set of routers regarded as legitimate by the network 453 operator. 455 A soliciting node must have some form of trust basis for knowing that 456 the advertising node is authoritative for the prefixes it includes in 457 RIOs. For example, when an NS/NA exchange is triggered by the 458 receipt of a Redirect, the soliciting node can verify that the RIOs 459 in the NA message match the ones it received in the Redirect message. 461 8. Acknowledgements 463 Joe Touch suggested a standalone draft to document this approach in 464 discussions on the intarea list. The work was subsequently 465 transferred to the 6man list, where the following individuals 466 provided valuable feedback: Mikael Abrahamsson, Zied Bouziri, Brian 467 Carpenter, Steinar Haug, Christian Huitema, Tatuya Jinmei, Tomoyuki 468 Sahara. 470 Discussion with colleagues during the "bits-and-bites" session at 471 IETF98 helped shape this document. Those colleagues are gratefully 472 acknowledged for their contributions. 474 This work was sponsored through several ongoing initiatives, 475 including 1) the NASA Safe Autonomous Systems Operation (SASO) 476 program under NASA contract number NNA16BD84C, 2) the FAA SE2025 477 contract number DTFAWA-15-D-00030, 3) the Boeing Information 478 Technology (BIT) MobileNet program, and 4) the Boeing Research & 479 Technology (BR&T) enterprise autonomy program. 481 9. References 483 9.1. Normative References 485 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 486 DOI 10.17487/RFC0791, September 1981, 487 . 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, 491 DOI 10.17487/RFC2119, March 1997, 492 . 494 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 495 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 496 December 1998, . 498 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 499 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 500 November 2005, . 502 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 503 Control Message Protocol (ICMPv6) for the Internet 504 Protocol Version 6 (IPv6) Specification", RFC 4443, 505 DOI 10.17487/RFC4443, March 2006, 506 . 508 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 509 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 510 DOI 10.17487/RFC4861, September 2007, 511 . 513 9.2. Informative References 515 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 516 Host Configuration Protocol (DHCP) version 6", RFC 3633, 517 DOI 10.17487/RFC3633, December 2003, 518 . 520 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 521 Neighbor Discovery (ND) Trust Models and Threats", 522 RFC 3756, DOI 10.17487/RFC3756, May 2004, 523 . 525 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 526 "SEcure Neighbor Discovery (SEND)", RFC 3971, 527 DOI 10.17487/RFC3971, March 2005, 528 . 530 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 531 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 532 DOI 10.17487/RFC6105, February 2011, 533 . 535 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 536 Requirements for IPv6 Customer Edge Routers", RFC 7084, 537 DOI 10.17487/RFC7084, November 2013, 538 . 540 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 541 Weil, "IPv6 Home Networking Architecture Principles", 542 RFC 7368, DOI 10.17487/RFC7368, October 2014, 543 . 545 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 546 Hosts in a Multi-Prefix Network", RFC 8028, 547 DOI 10.17487/RFC8028, November 2016, 548 . 550 Appendix A. Link-layer Address Changes 552 Type "D" hosts send unsolicited NAs to announce link-layer address 553 changes per standard neighbor discovery [RFC4861]. Link-layer 554 address changes may be due to localized factors such as hot-swap of 555 an interface card, but could also occur during movement to a new 556 point of attachment on the same link. 558 Appendix B. Interfaces with Multiple Link-Layer Addresses 560 Type "D" host interfaces may have multiple connections to the link; 561 each with its own link-layer address. Type "D" nodes can therefore 562 include multiple link-layer address options in IPv6 ND messages. 563 Neighbors that receive these messages can cache and select link-layer 564 addresses in a manner outside the scope of this specification. 566 Authors' Addresses 568 Fred L. Templin (editor) 569 Boeing Research & Technology 570 P.O. Box 3707 571 Seattle, WA 98124 572 USA 574 Email: fltemplin@acm.org 575 James Woodyatt 576 Google 577 3400 Hillview Ave 578 Palo Alto, CA 94304 579 USA 581 Email: jhw@google.com