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