idnits 2.17.1 draft-templin-6man-rio-redirect-08.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 (June 24, 2019) is 1767 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 696, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 705, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-27) exists of draft-templin-v6ops-pdhost-23 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 (if approved) J. Woodyatt 5 Intended status: Standards Track Google 6 Expires: December 26, 2019 June 24, 2019 8 Route Information Options in IPv6 Neighbor Discovery 9 draft-templin-6man-rio-redirect-08.txt 11 Abstract 13 The IPv6 Neighbor Discovery (ND) protocol allows nodes to discover 14 neighbors on the same link. Router Advertisement (RA) messages can 15 also convey routing information by including a non-zero (default) 16 Router Lifetime, and/or Route Information Options (RIOs). This 17 document specifies backward-compatible extensions that permit nodes 18 to include RIOs in other IPv6 ND messages to support the discovery of 19 more-specific routes among neighbors on the link. 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 https://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 December 26, 2019. 38 Copyright Notice 40 Copyright (c) 2019 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 (https://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 (RIOs) in IPv6 Neighbor Discovery 59 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. RIO Update . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. RIO Requirements . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Classic Redirection Scenario . . . . . . . . . . . . . . 7 63 4.4. RIO Redirection Scenario . . . . . . . . . . . . . . . . 9 64 4.4.1. Router Specification . . . . . . . . . . . . . . . . 9 65 4.4.2. Source Specification . . . . . . . . . . . . . . . . 10 66 4.4.3. Target Specification . . . . . . . . . . . . . . . . 11 67 4.5. Operation Without Redirects . . . . . . . . . . . . . . . 11 68 4.6. Multiple RIOs . . . . . . . . . . . . . . . . . . . . . . 12 69 4.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.8. Why NS/NA? . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 9.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Appendix A. Link-layer Address Changes . . . . . . . . . . . . . 17 79 Appendix B. Interfaces with Multiple Link-Layer Addresses . . . 17 80 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] (IPv6 ND) 86 provides a Router Solicitation (RS) function allowing nodes to 87 solicit a Router Advertisement (RA) response from an on-link router, 88 a Neighbor Solicitation (NS) function allowing nodes to solicit a 89 Neighbor Advertisement (NA) response from an on-link neighbor, and a 90 Redirect function allowing routers to inform nodes of a better next 91 hop neighbor on the link toward the destination. Further guidance 92 for processing Redirect messages is given in "First-Hop Router 93 Selection by Hosts in a Multi-Prefix Network" [RFC8028]. 95 "Default Router Preferences and More-Specific Routes" [RFC4191] 96 specifies a Route Information Option (RIO) that routers can include 97 in RA messages to inform recipients of more-specific routes (section 98 1 of that document provides rationale for the use of RA messages 99 instead of an adjunct routing protocol). This document specifies a 100 backward-compatible and incrementally-deployable extension to allow 101 nodes to include RIOs in other IPv6 ND messages to support the 102 dynamic discovery of more-specific routes. This allows nodes to 103 discover a better neighbor for more-specific routes to both increase 104 performance and reduce the workload on default routers. 106 This approach applies to any link type on which there may be many 107 nodes that provision delegated prefixes on their downstream 108 interfaces and do not provide transit services between upstream 109 networks. These nodes can either be routers that forward packets on 110 behalf of their downstream networks, or hosts that use a delegated 111 prefix for their own multi-addressing purposes 112 [I-D.templin-v6ops-pdhost][RFC7934]. 114 This work benefits from the experience of [RFC6706] - an experimental 115 protocol that uses UDP-based "pseudo-ND" messages instead of actual 116 ICMPv6 message codes. That experience has shown that using 117 synthesized UDP messages in addition to the IPv6 ND messaging already 118 present on the link is inefficient. Furthermore, the UDP approach is 119 neither backward-compatible nor incrementally-deployable, since 120 sending UDP messages blindly to a node that does not have the port 121 open could be misinterpreted as a port scan attack. This 122 specification avoids these issues by using the already-present and 123 natural IPv6 ND messaging available on the link, as specified in this 124 document. 126 2. Terminology 128 The terminology in the normative references applies. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. Lower case 133 uses of these words are not to be interpreted as carrying RFC2119 134 significance. 136 3. Motivation 138 An example of a good application for RIO is the local-area subnets 139 served by the routers described in "Basic Requirements for IPv6 140 Customer Edge Routers" [RFC7084]. While many customer edge routers 141 are capable of operating in a mode with a dynamic routing protocol 142 operating in the local-area network, the default mode of operation is 143 typically designed for unmanaged operation without any dynamic 144 routing protocol. On these networks, the only means for any node to 145 learn about routers on the link is by using the Router Discovery 146 protocol described in [RFC4861]. 148 Nevertheless, hosts on unmanaged home subnets may use prefix 149 delegation services such as DHCPv6 [RFC8415] to receive IPv6 routing 150 prefixes for additional subnets allocated from the space provided by 151 the service provider, and operate as routers for other links where 152 hosts in delegated subnets are attached. Hosts may even learn about 153 more specific routes than the default route by processing RIOs in RA 154 messages as described in [RFC4191]. 156 However, due to perceptions of the security considerations for hosts 157 in processing RIOs on unmanaged networks, the default configuration 158 for common host IPv6 implementations is to ignore RIOs. Accordingly, 159 on typical home networks the forwarding path from hosts on one subnet 160 to destinations on every off-link local subnet always passes through 161 the customer edge router, even when a shorter path would otherwise be 162 available through an on-link router. This adds costs for 163 retransmission on shared LAN media, often adding latency and jitter 164 with queuing delay and delay variability. This is not materially 165 different under the scenarios described in "IPv6 Home Networking 166 Architecture Principles" [RFC7368] except that routers may use an 167 interior dynamic routing protocol to coordinate sending of RIOs in RA 168 messages, which as explained above, are not processed by typical 169 hosts. 171 In increasingly common practice, a node that receives a prefix 172 delegation can use the prefix for its own multi-addressing purposes 173 or can connect an entourage of "Internet of Things (IoT)" back end 174 devices (an approach sometimes known as "tethering" [RFC7934]). On 175 many link types, the number of such nodes may be quite large which 176 would make running a dynamic routing protocol between the nodes 177 impractical. Example use cases include: 179 o IETF conference, airport, and hotel WiFi networks, where large 180 numbers of nodes on the link could receive IPv6 prefix 181 delegations. Using the extensions described in this document, the 182 nodes could dynamically discover more-specific routes to enable 183 direct neighbor-to-neighbor communications. 185 o Mobile enterprise devices that connect into a corporate network 186 via VPN links. Using the extensions described in this document, 187 mobile devices could dynamically establish pair-wise VPN links 188 between themselves without having to use the enterprise network as 189 transit. 191 o Civil aviation networks where an aircraft holds an IPv6 prefix 192 derived from the identification value assigned to it by the 193 International Civil Aviation Organization (ICAO). Using the 194 extensions described in this document, direct paths between the 195 aircraft and Air Traffic Control (ATC) can be established to 196 provide a more direct route for communications. 198 o Unmanned Air System (UAS) networks where each UAS receives an IPv6 199 prefix delegation for operation within the Unmanned Air Traffic 200 Management (UTM) service under development within NASA and the 201 FAA. Using the extensions described in this document, very large 202 numbers of UAS can be accommodated by the UTM service for both 203 vehicle-to-infrastructure and vehicle-to-vehicle communications. 205 By using RIOs in IPv6 ND messages, the forwarding path between 206 subnets can be shortened while accepting a much narrower opening of 207 attack surfaces on general purpose hosts related to the Router 208 Discovery protocol. The basic idea is simple: hosts normally send 209 packets for off-link destinations to their default router unless they 210 receive ND Redirect messages designating another on-link node as the 211 target. This document allows ND Redirects additionally to suggest 212 another on-link node as the target for one or more routing prefixes, 213 including one with the destination. Hosts that receive RIOs in ND 214 Redirect messages then send NS messages to the target containing 215 those RIOs, and process the NA messages the target sends in reply. 216 If hosts only process RIOs in NA messages when they have previously 217 sent them in NS messages to the targets of received ND Redirect 218 messages, then hosts only process the RIOs at the initiative of 219 routers they already accept as authoritative. 221 4. Route Information Options (RIOs) in IPv6 Neighbor Discovery Messages 223 The RIO is specified for inclusion in RA messages in Section 2.3 of 224 [RFC4191], while the neighbor discovery functions are specified in 225 [RFC4861]. This specification permits routers to include RIOs in 226 other IPv6 ND messages so that recipients can discover a better next 227 hop for a destination *prefix* instead of just a specific destination 228 address. This specification therefore updates [RFC4191] as discussed 229 in the following sections. 231 4.1. RIO Update 233 The RIO format given in Section 2.3 of [RFC4191] is updated by this 234 specification as shown in Figure 1: 236 0 1 2 3 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type | Length | Prefix Length |S|Res|Prf|Resvd| 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Route Lifetime | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Prefix (Variable Length) | 244 . . 245 . . 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Attributes ... 248 +-+-+-+-+-+-+-+-+-+-+-+- 250 Figure 1: Updated RIO Format 252 This format introduces a new S flag and variable-length Attributes. 253 The fields of the main body of the RIO are set as follows: 255 o Type, Prefix Length, Prf, Route Lifetime and Prefix are set 256 exactly as specified in Section 2.3 of [RFC4191]. 258 o For RA messages, Length is set exactly as specified in Section 2.3 259 of [RFC4191] and no Attributes are included. For all other IPv6 260 ND messages, Length MUST be initialized to exactly 1 when Prefix 261 Length is 0, to exactly 2 when Prefix Length is between 1 and 64, 262 and to exactly 3 when Prefix Length is greater than 64. Length is 263 then incremented by the length of all included Attributes in units 264 of 8-octets (see below). 266 o S is set to '1' to "Solicit" route information or to '0' (i.e., 267 the default value) to "Assert" route information. 269 o Res and Resvd are reserved and MUST be set to '0'. 271 Attributes MAY be included as ancillary route information. Each 272 Attribute is formatted in the same manner as specified for IPv6 ND 273 options in Section 4.6 of [RFC4861] and as shown in Figure 2: 275 0 1 2 3 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | ... | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 ~ ... ~ 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 2: RIO Attribute Format 285 This document defines the NULL Attribute with Type '0'. Other 286 Attribute Types are assigned through IANA action. 288 When Type is '0', Length MUST be set to the total number of 8-octet 289 blocks in the Attribute, and the Attribute body MUST include a 290 corresponding number of '0' octets. For example, for Lengths of 1, 291 2, 3, etc., the Attribute body includes 6, 14, 22, etc. '0' octets, 292 respectively. 294 Receivers ignore any NULL, unknown or malformed Attributes and 295 continue to process any other Attributes in the RIO that follow. 297 4.2. RIO Requirements 299 This specification updates [RFC4191] by allowing RIOs to appear in 300 any IPv6 ND messages with the following requirements: 302 o Redirect, NA and RA messages MUST NOT include RIOs with the S flag 303 set to '1'; any RIOs received in Redirect, NA and RA messages with 304 S set to '1' MUST be silently ignored. 306 o NS and RS messages MAY include some RIOs with S set to '1' and 307 others with S set to '0'. 309 o NA/RA responses to RIOs in NS/RS messages with S set to '1' MUST 310 include RIOs with the solicited route information and with S set 311 to '0'. (If the route information solicited by the NS/RS message 312 is incorrect or unrecognized, however, the RIO MUST be silently 313 ignored.) 315 o Asserted route information in any RIOs received with S set to '0' 316 SHOULD be considered as "unconfirmed" until the assertion can be 317 verified. Assertion verification can be through a trust anchor 318 such as a trusted on-link router, through a static routing table, 319 or through some other means outside the scope of this document. 320 Any route information that cannot be verified SHOULD be ignored. 322 The following sections present the classic redirection scenario 323 illustrating an exchange where a trusted on-link router is used to 324 verify RIO assertions. Other IPv6 ND messaging scenarios that can 325 employ some other means of verifying RIO assertions are also 326 acceptable. 328 4.3. Classic Redirection Scenario 330 In the classical redirection scenario there are three actors, namely 331 the Source, Router and Target as shown in Figure 3: 333 +-------------------+ 334 | | 335 | Router | 336 | | 337 +---------+---------+ 338 | 339 | 340 X---------+----------------+---------------+---------X 341 | Link | 342 | | 343 +---------+---------+ +----------+--------+ 344 | | | | 345 | Source | | Target | 346 | | | | 347 +-------------------+ +---------+---------+ 348 | 349 2001:db8::/N 350 | 351 X-+----+--+-------+-X 352 | | | 353 +--+ +--+ +--+ 354 |H1| |H2| .... |Hn| 355 +--+ +--+ +--+ 357 Figure 3: Classical Redirection Scenario 359 In addition, the Target may be a node that connects an arbitrarily- 360 complex set of IPv6 networks (e.g., as depicted by 2001:db8::/N in 361 the figure) with hosts H(i). 363 In this scenario, the Source initially has no route for 2001:db8::/N 364 and must send initial packets destined to correspondents H(i) via a 365 first-hop Router. Upon receiving the packets, the Router forwards 366 the packets to the Target and may also send a Redirect message back 367 to the Source with the Destination Address field set to the 368 destination of the packet that triggered the Redirect, the Target 369 Address field set to the target link-local address and with a Target 370 Link Layer Address Option (TLLAO) that includes the target link-layer 371 address. After receiving the message, the Source may begin sending 372 packets destined to H(i) directly to the Target, which will then 373 forward them to addresses within its internal and/or external IPv6 374 network prefixes. 376 This specification augments the classical Redirection scenario by 377 allowing the Router to include entire prefixes (e.g., 2001:db8::/N) 378 in RIOs in the Redirect message, and thereafter allowing the Source 379 to include RIOs in an NS message and the Target to include RIOs in 380 its NA response. The following sections present this "augmented" RIO 381 redirection scenario. 383 4.4. RIO Redirection Scenario 385 In the RIO redirection scenario, the Source sends initial packets via 386 the Router the same as in the classical scenario. When the Router 387 receives the packets, it searches its routing tables for a route that 388 is assigned to the Target and that covers the destination address of 389 the packet. The Router then includes the route in an RIO in a 390 Redirect message to send back to the Source. The Router sets the S 391 flag in the RIO to '0' to indicate that a prefix is being asserted. 393 When the Source receives the Redirect message, it prepares an NS 394 message that includes the route information received in the RIO from 395 the Redirect message and with S set to '1 to indicate that route 396 information is being solicited. At the same time, if the Source 397 needs to assert any route information to the Target, it includes the 398 information in RIOs with S set to '0'. The Source then sends the NS 399 message to the Target. 401 When the Target receives the NS message, it records any route 402 information in RIOs with S set to '0' as unconfirmed route 403 information for the Source pending verification. At the same time, 404 it determines whether the route information included in any RIOs with 405 S set to '1' matches one of its own routes. If so, the Target 406 includes the route information in an RIO with S set to '0' to return 407 in an NA message reply to the Source. 409 When the Source receives the NA message it can install any RIO 410 information that matches the Redirect RIOs in its routing table. The 411 following sections present more detailed specifications for the 412 Router, Source and Target. 414 4.4.1. Router Specification 416 When the Router receives a packet from the Source it searches its 417 routing table for a prefix that covers the destination address (e.g., 418 2001:db8::/N as depicted in Figure 1), where prefix could be 419 populated in the routing table during prefix delegation, via manual 420 configuration, etc. If the next hop for the prefix is on-link (i.e., 421 a "Target" in the terms of [RFC4861]), the Router then prepares a 422 Redirect message with the Destination Address field set to the 423 packet's IPv6 destination address, with the Target Address field set 424 to the link-local address of the Target, with a TLLAO set to the 425 link-layer address of the Target, and with an RIO that includes route 426 information for the prefix with Route Lifetime, Prf, and S set to 0. 428 The Router then sends the Redirect message to the Source (subject to 429 rate limiting). 431 4.4.2. Source Specification 433 According to [RFC4861], a Source that receives a valid Redirect 434 message updates its destination cache per the Destination Address and 435 its neighbor cache per the Target Address. According to [RFC4191], 436 Sources can be classified as Type "A", "B" or "C" based on how they 437 process RIOs, where a Type "C" Source updates its routing table per 438 any RIO elements included in an RA message. Finally, according to 439 [RFC8028], a Type "C" Source operating on a Multi-Prefix Network with 440 multiple default routes can make source address selection decisions 441 based on information in its routing table decorated with information 442 derived from the source of the RIO element. 444 In light of these considerations, this document introduces a new Type 445 "D" behavior for Sources with the same behavior as a Type "C" Source, 446 but which also process RIO elements in other IPv6 ND messages. Type 447 "D" Sources process Redirect messages with RIO elements by first 448 verifying that the Prefix in the first RIO matches the Destination 449 Address. If the Destination Address does not match the Prefix, the 450 Source discards the Redirect message. Otherwise, the Source updates 451 its neighbor cache per the Target Address and its destination cache 452 per the Destination Address the same as for classical redirection. 453 Next, the Source MAY send an NS message to the Target containing an 454 RIO with the Prefix and Prefix Length and with S set to '1' to elicit 455 an NA response (at the same time, the Source MAY include RIOs with S 456 set to '0' if it needs to assert any route information to the 457 Target). 459 When the Type 'D' Source receives the solicited NA message from the 460 Target, if the NA includes an RIO with S set to '0' and with a Prefix 461 corresponding to the one received in the Redirect message, the Source 462 installs the route information in its routing table with the Target's 463 address as the next hop. (Note that the Prefix Length received in 464 the NA message MAY be different than the Prefix Length received in 465 the Redirect message. If the Prefix Length in the NA is the same or 466 longer, the Source accepts the Prefix as verified by the Router; if 467 the Prefix Length is shorter, the Source considers the Prefix as 468 unconfirmed.) 470 After the Source installs the route information in its routing table, 471 it MAY begin sending packets with destination addresses that match 472 the Prefix directly to the Target Instead of sending them to the 473 Router. The Source SHOULD decrement the Route Lifetime and MAY send 474 new NS messages to receive a fresh Route Lifetime (if the Route 475 Lifetime decrements to 0, the Source instead deletes the route 476 information from its routing table). The Source MAY furthermore 477 delete the route information at any time and again allow subsequent 478 packets to flow through the Router which may send a fresh Redirect. 479 The Source SHOULD then again test the route by performing an NS/NA 480 exchange with the Target the same as described above. 482 After updating its routing table, the Source may receive an 483 unsolicited NA message from the Target with an RIO with new route 484 information. If the RIO Prefix is in its routing table, and if the 485 RIO Route Lifetime value is 0, the Source deletes the corresponding 486 route. 488 After updating its routing table, the Source may subsequently receive 489 a Destination Unreachable message from the Target with Code '0' ("No 490 route to destination"). If so, the Source SHOULD delete the 491 corresponding route information from its routing table and again 492 allow subsequent packets to flow through the Router. 494 4.4.3. Target Specification 496 When the Target receives an NS message from the Source containing an 497 RIO with S set to '1', it examines the Prefix and Prefix Length to 498 see if it matches one of the prefixes in its routing table. If so, 499 the Target prepares an NA message with an RIO including a Prefix and 500 Prefix Length, any necessary route information, and with S set to 501 '0'. The Target then sends the NA message back to the Source. 503 If the NS included any RIO options with S set to '0', the Target 504 SHOULD employ a suitable means to verify the asserted route 505 information, and SHOULD reject any route information that cannot be 506 verified. 508 At some later time, the Target may either alter or deprecate one of 509 its routes. If the Target has asserted route information in RIOs to 510 one or more Sources, the Target SHOULD send unsolicited NA messages 511 with RIOs that assert new route information to alter the route, where 512 a new Route Lifetime value of '0' deprecates the route. If the 513 Target receives a packet with a destination addresses for which there 514 is no matching route for one of its downstream networks, the Target 515 sends a Destination Unreachable message to the Source with Code '0' 516 ("No route to destination"), subject to rate limiting. 518 4.5. Operation Without Redirects 520 If the Source has some way to determine the Target's link-local 521 address without receiving a Redirect message from the Router, the 522 Source MAY send an NS message with an RIO directly to the Target with 523 S set to 1, Prefix set to the destination address of an IPv6 packet, 524 Prefix Length set to 128 and all other route information is set to 0. 526 When the Target receives the NS message, it prepares an NA response 527 with an RIO that includes route information for the shortest one of 528 its prefixes that covers the destination address. The Target then 529 sends the NA message to the Source. 531 When the Source receives the NA message, it SHOULD consider the route 532 information asserted in the RIO as unconfirmed until it can verify 533 the Target's claim (i.e., as described in Section 4.2). 535 Any node may also assert route information at any time by sending 536 IPv6 ND messages with RIOs with S set to 0. Recipients of such 537 messages SHOULD consider the route information as unconfirmed until 538 the information can be verified. 540 4.6. Multiple RIOs 542 If a Redirect includes multiple RIOs, the Source only checks the 543 destination address for a match against the Prefix in the first RIO. 545 If an NS/RS message includes multiple RIOs with S set to '1', the 546 neighbor responds to those RIOs which match entries in its routing 547 table. 549 If an NS/NA/RS/RA message includes multiple RIOs with S set to '0', 550 the neighbor considers all of the route information as unconfirmed 551 until the information can be verified. 553 4.7. Multicast 555 Nodes MAY send IPv6 ND messages with RIOs to link-scoped multicast 556 destination addresses including All Nodes, All Routers, and 557 Solicited-Node multicast (see: [RFC4291]. As an example, a node 558 could send unsolicited NA messages to the All Nodes multicast address 559 to alter or deprecate a route it had previously asserted to one or 560 more neighbors. 562 Nodes MUST be conservative in their use of multicast IPv6 ND 563 messaging to avoid unnecessarily disturbing other nodes on the link. 565 4.8. Why NS/NA? 567 Since [RFC4191] already specifies the inclusion of RIOs in RA 568 messages, a natural question is why use NS/NA instead of RS/RA? 569 First, RA messages are only sent over advertising interfaces 570 [RFC4861]. Source and Target nodes typically connect only downstream 571 networks; hence, they configure their upstream interfaces as non- 572 advertising interfaces. 574 Second, NS/NA exchanges used by the IPv6 Neighbor Unreachability 575 Detection (NUD) procedure are unicast-based whereas RA responses to 576 RS messages are typically sent as multicast. Since this mechanism 577 must support unicast operation, the use of unicast NS/NA exchanges is 578 preferred. 580 Third, the IPv6 ND specification places restrictions on minimum 581 delays between RA messages. Since this mechanism expects an 582 immediate advertisement from the Target in response to the Source's 583 solicitation, only the NS/NA exchange can satisfy this property. 585 Fourth, the RA message is the "swiss army knife" of the IPv6 ND 586 protocol. RA messages carry numerous configuration parameters for 587 the link, including Cur Hop Limit, M/O flags, Router Lifetime, 588 Reachable Time, Retrans Time, Prefix Information Options, MTU 589 options, etc. The Target must not advertise any of this information 590 to the soliciting Source. 592 Fifth, RIOs in legacy RA messages cannot encode attributes and 593 therefore may be limited in the route information they can carry. 595 Finally, operators are deeply concerned about the security of RA 596 messages - so much so that they deploy link-layer security mechanisms 597 that drop RA messages originating from nodes claiming to be an 598 authoritative router for the link [RFC6105]. 600 5. Implementation Status 602 The IPv6 ND functions and RIOs are widely deployed in IPv6 603 implementations, however these implementations do not currently 604 include RIOs in IPv6 ND messages other than RAs. 606 An experimental implementation of [RFC6706] exists, and demonstrates 607 how the Redirect function can be used to carry route information. 609 6. IANA Considerations 611 IANA is instructed to create a registry for "RIO Attributes" as 612 discussed in Section 4.1. The registry includes the following 613 initial entry: 615 0 - the NULL Attribute [draft-templin-6man-rio-redirect] 617 Other Attribute types are defined through standards action or expert 618 review. 620 7. Security Considerations 622 The Redirect message validation rules in Section 8.1 of [RFC4861] 623 require recipients to verify that the IP source address of the 624 Redirect is the same as the current first-hop router for the 625 specified ICMP Destination Address. Recipients therefore naturally 626 reject any Redirect message with an incorrect source address. 628 Other security considerations for IPv6 ND messages that include RIOs 629 are the same as specified in Section 11 of [RFC4861]. Namely, the 630 protocol must take measures to secure IPv6 ND messages on links where 631 spoofing attacks are possible. 633 A spoofed Redirect message containing no RIOs could cause corruption 634 in the recipient's destination cache, while a spoofed Redirect 635 message containing RIOs could corrupt the host's routing tables. 636 While the latter would seem to be a more onerous result, the 637 possibility for corruption is unacceptable in either case. 639 "IPv6 ND Trust Models and Threats" [RFC3756] discusses spoofing 640 attacks, and states that: "This attack is not a concern if access to 641 the link is restricted to trusted nodes". "SEcure Neighbor Discovery 642 (SEND)" [RFC3971] provides one possible mitigation for other cases. 643 In some scenarios, it may be sufficient to include only the Timestamp 644 and Nonce options defined for SEND without implementing other aspects 645 of the protocol. 647 "IPv6 Router Advertisement Guard" [RFC6105] ("RA Guard") describes a 648 layer-2 filtering technique intended for network operators to use in 649 protecting hosts from receiving RA messages sent by nodes that are 650 not among the set of routers regarded as legitimate by the network 651 operator. 653 Nodes must have some form of trust basis for knowing that the sender 654 of an ND message is authoritative for the prefixes it asserts in 655 RIOs. For example, when an NS/NA exchange is triggered by the 656 receipt of a Redirect, the soliciting node can verify that the RIOs 657 in the NA message match the ones it received in the Redirect message 658 (which originally came from a trusted router). 660 Nodes that do not wish to provide transit services for upstream 661 networks may also receive IPv6 packets via an upstream interface that 662 do not match any of their delegated prefixes. In that case, the node 663 drops the packets and observes the "Destination Unreachable - No 664 route to destination" procedures discussed in [RFC4443]. Dropping 665 the packets is necessary to avoid a reflection attack that would 666 cause the node to forward packets received from an upstream interface 667 via the same or a different upstream interface. 669 8. Acknowledgements 671 Joe Touch suggested a standalone draft to document this approach in 672 discussions on the intarea list. The work was subsequently 673 transferred to the 6man list, where the following individuals 674 provided valuable feedback: Mikael Abrahamsson, Zied Bouziri, Brian 675 Carpenter, Steinar Haug, Christian Huitema, Tatuya Jinmei, Tomoyuki 676 Sahara. 678 Discussion with colleagues during the "bits-and-bites" session at 679 IETF98 helped shape this document. Those colleagues are gratefully 680 acknowledged for their contributions. 682 This work is aligned with the NASA Safe Autonomous Systems Operation 683 (SASO) program under NASA contract number NNA16BD84C. 685 This work is aligned with the FAA as per the SE2025 contract number 686 DTFAWA-15-D-00030. 688 This work is aligned with the Boeing Information Technology (BIT) 689 MobileNet program and the Boeing Research & Technology (BR&T) 690 enterprise autonomy program. 692 9. References 694 9.1. Normative References 696 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 697 DOI 10.17487/RFC0791, September 1981, 698 . 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, 702 DOI 10.17487/RFC2119, March 1997, 703 . 705 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 706 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 707 December 1998, . 709 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 710 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 711 November 2005, . 713 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 714 Control Message Protocol (ICMPv6) for the Internet 715 Protocol Version 6 (IPv6) Specification", STD 89, 716 RFC 4443, DOI 10.17487/RFC4443, March 2006, 717 . 719 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 720 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 721 DOI 10.17487/RFC4861, September 2007, 722 . 724 9.2. Informative References 726 [I-D.templin-v6ops-pdhost] 727 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing 728 Models", draft-templin-v6ops-pdhost-23 (work in progress), 729 December 2018. 731 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 732 Neighbor Discovery (ND) Trust Models and Threats", 733 RFC 3756, DOI 10.17487/RFC3756, May 2004, 734 . 736 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 737 "SEcure Neighbor Discovery (SEND)", RFC 3971, 738 DOI 10.17487/RFC3971, March 2005, 739 . 741 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 742 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 743 2006, . 745 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 746 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 747 DOI 10.17487/RFC6105, February 2011, 748 . 750 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 751 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 752 . 754 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 755 Requirements for IPv6 Customer Edge Routers", RFC 7084, 756 DOI 10.17487/RFC7084, November 2013, 757 . 759 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 760 Weil, "IPv6 Home Networking Architecture Principles", 761 RFC 7368, DOI 10.17487/RFC7368, October 2014, 762 . 764 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 765 "Host Address Availability Recommendations", BCP 204, 766 RFC 7934, DOI 10.17487/RFC7934, July 2016, 767 . 769 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 770 Hosts in a Multi-Prefix Network", RFC 8028, 771 DOI 10.17487/RFC8028, November 2016, 772 . 774 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 775 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 776 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 777 RFC 8415, DOI 10.17487/RFC8415, November 2018, 778 . 780 Appendix A. Link-layer Address Changes 782 Type "D" hosts send unsolicited NAs to announce link-layer address 783 changes per standard neighbor discovery [RFC4861]. Link-layer 784 address changes may be due to localized factors such as hot-swap of 785 an interface card, but could also occur during movement to a new 786 point of attachment on the same link. 788 Appendix B. Interfaces with Multiple Link-Layer Addresses 790 Type "D" host interfaces may have multiple connections to the link; 791 each with its own link-layer address. Type "D" nodes can therefore 792 include multiple link-layer address options in IPv6 ND messages. 793 Neighbors that receive these messages can cache and select link-layer 794 addresses in a manner outside the scope of this specification. 796 Appendix C. Change Log 798 << RFC Editor - remove prior to publication >> 800 Changes from -07 to -08: 802 o Changed DHCPv6 Prefix Delegation reference to RFC8415. 804 Changes from -06 to -07: 806 o Fixed spelling and grammar. 808 Changes from -05 to -06: 810 o Minor adjustments to text and requirements. 812 Changes from -04 to -05: 814 o Removed "Ver" field and version numbers. 816 o Included reference to 'draft-templin-v6ops-pdhost' 818 o Changed "MAY" to "may" in two places 820 o Added text on advertising interfaces 822 o Added UAS use case 824 Authors' Addresses 826 Fred L. Templin (editor) 827 Boeing Research & Technology 828 P.O. Box 3707 829 Seattle, WA 98124 830 USA 832 Email: fltemplin@acm.org 834 James Woodyatt 835 Google 836 3400 Hillview Ave 837 Palo Alto, CA 94304 838 USA 840 Email: jhw@google.com