idnits 2.17.1 draft-templin-v6ops-pdhost-25.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 1, 2020) is 1577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.templin-6man-rio-redirect' is defined on line 575, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-08 Summary: 0 errors (**), 0 flaws (~~), 3 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 Intended status: Informational January 1, 2020 5 Expires: July 4, 2020 7 IPv6 Prefix Delegation and Multi-Addressing Models 8 draft-templin-v6ops-pdhost-25 10 Abstract 12 Requesting nodes typically acquire IPv6 prefixes from a prefix 13 delegation service for the network. The requesting node can 14 provision the prefix according to whether it acts as a router on 15 behalf of any downstream networks and/or as a host on behalf of its 16 local applications. In the latter case, the requesting node can use 17 portions of the delegated prefix for its own multi-addressing 18 purposes. This document therefore considers prefix delegation models 19 for both the classic routing and various multi-addressing use cases. 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 July 4, 2020. 38 Copyright Notice 40 Copyright (c) 2020 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 50 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Multi-Addressing Considerations . . . . . . . . . . . . . . . 6 61 4. Multi-Addressing Alternatives for Delegated Prefixes . . . . 7 62 5. Address Autoconfiguration Considerations . . . . . . . . . . 8 63 6. MLD/DAD Implications . . . . . . . . . . . . . . . . . . . . 8 64 7. Dynamic Routing Protocol Implications . . . . . . . . . . . . 9 65 8. IPv6 Neighbor Discovery Implications . . . . . . . . . . . . 9 66 9. Prefix Delegation Services . . . . . . . . . . . . . . . . . 9 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 13.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 IPv6 Neighbor Discovery (ND) is the process by which nodes on the 79 link discover each other's presence as well as advertise and receive 80 configuration information. IPv6 Prefix Delegation (PD) entails 1) 81 the communication of a prefix from a delegation service to a 82 requesting node, 2) a representation of the prefix in the network's 83 Routing Information Base (RIB) and the first-hop router's Forwarding 84 Information Base (FIB), and 3) a control messaging service to 85 maintain prefix lifetimes. Following delegation, the prefix is 86 available for the requesting node's exclusive use and is not shared 87 with any other nodes. This document considers prefix delegation 88 models and multiaddressing considerations for requesting nodes that 89 act as a router on behalf of any downstream networks and/or as a host 90 on behalf of their local applications. 92 For nodes that connect downstream-attached networks (e.g., a 93 cellphone that connects a "tethered" Internet of Things (IoT), a 94 laptop computer with a complex internal network of virtual machines, 95 etc.), the classic routing model applies as shown in Figure 1: 97 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 99 .---------. 100 ,-( )-. 101 ( +----------+ ) 102 ( |Server 'S'| ) 103 ( +----------+ ) 104 ( Network 'N' ) 105 `-(__________)-' 106 | 107 +----------+----------+ 108 | first-hop router 'F'| 109 +----------+----------+ 110 | 111 upstream link | 112 | 113 +----------+----------+ 114 | upstream interface | 115 +---------------------+ 116 | | 117 | requesting node 'R' | 118 | (Prefix 'P') | 119 | | 120 +--+-+--+-+--+-----+--+ 121 |A1| |A2| |A3| ... |Aj| 122 +--+-+--+-+--+-----+--+ 123 |downstream interfaces| 124 +----------+----------+ 125 | 126 internal and/or external | 127 downstream links | 128 X----+-------------+--------+----+---------------+---X 129 | | | | 130 +---++-+--+ +---++-+--+ +---++-+--+ +---++-+--+ 131 | |Ak| | | |Al| | | |Am| | | |A*| | 132 | +--+ | | +--+ | | +--+ | | +--+ | 133 | host H1 | | host H2 | | host H3 | ... | host Hn | 134 +---------+ +---------+ +---------+ +---------+ 136 <-------------- Downstream Network -------------> 138 Figure 1: Classic Routing Model 140 In the classic routing model, requesting node 'R' has one or more 141 upstream interfaces and connects zero or more internal and/or 142 external downstream networks. When 'R' requests a prefix delegation, 143 the following sequence of events transpires: 145 o Server 'S' located in network 'N' delegates prefix 'P' to 146 requesting node 'R'. 148 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 150 o 'P' is injected into the RIB for 'N', and first hop router 'F' 151 configures a FIB entry with 'R' as the next hop. 153 o R' receives 'P' and assigns zero or more addresses 'A(*)' taken 154 from 'P' to its downstream interfaces 156 o 'R' advertises zero or more sub-prefixes taken from 'P' to hosts 157 'H(i)' on downstream networks. 159 o 'R' delegates zero or more sub-prefixes taken from 'P' to 160 requesting nodes in downstream networks. 162 o 'R' acts as a router for hosts 'H(i)' on downstream networks and 163 as a host on behalf of its local applications. 165 This document also considers the case when 'R' uses portions of 'P' 166 for its own internal multi-addressing purposes. [RFC7934] provides 167 Best Current Practice (BCP) motivations for the benefits of multi- 168 addressing, while an operational means for providing nodes with 169 multiple addresses is given in [RFC8273]. The following multi- 170 addressing alternatives for delegated prefixes compliment this 171 framework. 173 In a first alternative, when requesting node 'R' receives prefix 'P', 174 it can assign addresses taken from 'P' to downstream virtual 175 interfaces (e.g., a loopback) as shown in Figure 2: 177 x 178 | 179 upstream link | 180 | 181 +----------+----------+ 182 | upstream interface | 183 +---------------------+ 184 | | 185 | requesting node 'R' | 186 | | 187 +--+-+--+-+--+-----+--+ 188 |A1| |A2| |A3| ... |An| 189 +--+-+--+-+--+-----+--+ 190 | virtual interfaces | 191 +---------------------+ 193 Figure 2: Address Assignment to Downstream Virtual Interfaces 195 In a second alternative, 'R' could assign IPv6 addresses taken from 196 'P' to the upstream interface over which the prefix was received as 197 shown in Figure 3: 199 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 201 x 202 | 203 upstream link | 204 | 205 +----------+----------+ 206 | upstream interface | 207 +--+-+--+-+--+-----+--+ 208 |A1| |A2| |A3| ... |An| 209 +--+-+--+-+--+-----+--+ 210 | | 211 | requesting node 'R' | 212 | | 213 +---------------------+ 215 Figure 3: Upstream Interface Address Assignment 217 In a third alternative, 'R' could assign IPv6 addresses taken from 218 'P' to its local applications which appear as "psuedo" virtual 219 interfaces as shown in Figure 4: 221 x 222 | 223 upstream link | 224 | 225 +----------+----------+ 226 | upstream interface | 227 +---------------------+ 228 | | 229 | requesting node 'R' | 230 | | 231 +--+-+--+-+--+-----+--+ 232 |A1| |A2| |A3| ... |An| 233 +--+-+--+-+--+-----+--+ 234 | Applications | 235 +---------------------+ 237 Figure 4: Application Addresssing Model 239 With these IPv6 PD-based multi-addressing considerations, the node 240 can configure an unlimited supply of addresses to make them available 241 for local applications without requiring coordination with other 242 nodes on upstream interfaces. The following sections present 243 considerations for nodes that employ IPv6 PD mechanisms. 245 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 247 2. Terminology 249 The terms "node", "host" and "router" are the same as defined in 250 [RFC8200]. The terms Router Solicitation (RS), Router Advertisement 251 (RA), Neighbor Solicitation (NS), Neighbor Advertisment (NA), 252 Redirect and Prefix Information Option (PIO) are the same as defined 253 in [RFC4861]. All other terminology in the normative references 254 applies, while the following terms are defined within the context of 255 this document: 257 shared prefix 258 an IPv6 prefix that may be advertised to more than one node on the 259 link. The router that advertises the prefix must consider the 260 prefix as on-link so that the IPv6 ND address resolution function 261 will identify the correct neighbor for each packet. 263 individual prefix 264 an IPv6 prefix that is advertised to exactly one node on the link, 265 where the node may be unaware that the prefix is individual and 266 may not participate in prefix maintenance procedures. The router 267 that advertises the prefix can consider the prefix as on-link or 268 not on-link. In the former case, the router performs address 269 resolution and only forwards those packets that match one of the 270 node's configured addresses so that the node will not receive 271 unwanted packets. In the latter case, the router can simply 272 forward all packets matching the prefix to the node which must 273 then drop any packets that do not match one of its configured 274 addresses. An example individual prefix service is documented in 275 [RFC8273]. 277 delegated prefix 278 an IPv6 prefix that is explicitly conveyed to a node for its own 279 exclusive use, where the node is an active participant in prefix 280 delegation and maintenance procedures. The first-hop router 281 simply forwards all packets matching the prefix to the requesting 282 node. The requesting node associates the prefix with downstream 283 and/or internal virtual interfaces (i.e., and not the upstream 284 interface). 286 3. Multi-Addressing Considerations 288 IPv6 allows nodes to assign multiple addresses to a single interface. 289 [RFC7934] discusses options for multi-addressing as well as use cases 290 where multi-addressing may be desirable. Address configuration 291 options for multi-addressing include StateLess Address 292 AutoConfiguration (SLAAC) [RFC4862], Dynamic Host Configuration 293 Protocol for IPv6 (DHCPv6) address configuration [RFC8415], manual 294 configuration, etc. 296 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 298 Nodes configure addresses from a shared or individual prefix and 299 assign them to the upstream interface over which the prefix was 300 received. When the node assigns the addresses, it is required to use 301 Multicast Listener Discovery (MLD) [RFC3810] to join the appropriate 302 solicited-node multicast group(s) and to use the Duplicate Address 303 Detection (DAD) algorithm [RFC4862] to ensure that no other node 304 configures a duplicate address. 306 In contrast, a node that configures addresses from a delegated prefix 307 can assign them without invoking MLD/DAD on an upstream interface, 308 since the prefix has been delegated to the node for its own exclusive 309 use and is not shared with any other nodes. 311 4. Multi-Addressing Alternatives for Delegated Prefixes 313 When a node receives a delegated prefix, it has many alternatives for 314 provisioning the prefix to its local interfaces and/or downstream 315 networks. [RFC7278] discusses alternatives for provisioning a prefix 316 obtained by a User Equipment (UE) device under the 3rd Generation 317 Partnership Program (3GPP) service model. This document considers 318 the more general case when the node receives a delegated prefix 319 explicitly provided for its own exclusive use. 321 When the node receives the prefix, it can distribute the prefix to 322 internal (virtual) or external (physical) downstream networks and 323 optionally configure addresses for itself on downstream interfaces. 324 The node then acts as a router on behalf of its downstream networks. 326 The node could instead (or in addition) use portions of the delegated 327 prefix for its own multi-addressing purposes. In a first 328 alternative, the node can assign as many addresses as it wants from 329 the prefix to downstream virtual interfaces. 331 In a second alternative, the node can assign as many addresses as it 332 wants from the prefix to the upstream interface over which the prefix 333 was received, but in normal practice does not assign the prefix 334 itself (or subnets from the prefix) to the upstream interface. If 335 the node assigned the prefix to the upstream interface, any neighbors 336 on the upstream link receiving an RA could configure addresses from 337 the prefix and a default route with the node as the next hop. This 338 could create a loop where upstream link neighbors send packets to the 339 node which in turn forwards them to another upstream link neighbor. 340 Still, there may be cases where the node provides services for 341 dependent neighbors on the upstream link that have no other means of 342 connecting to the network. ([RFC8415] chose to remain silent on this 343 subject since it is operational rather than functional in nature.) 345 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 347 In a third alternative, the node can assign addresses taken from the 348 delegated prefix to its local applications. The applications 349 themselves then serve as virtual interfaces. (Note that, in the 350 future, the practice of assigning unique non-link-local IPv6 351 addresses to applications could obviate the need for transport 352 protocol port numbers.) 354 In these multi-addressing cases, the node normally assigns the prefix 355 itself to a virtual interface such as a loopback so that unused 356 portions of the prefix are correctly identified as unreachable. The 357 node then acts as a host on behalf of its local applications even 358 though neighbors on the upstream link consider it as a router. 360 5. Address Autoconfiguration Considerations 362 Nodes autoconfigure addresses according to Section 6 of IPv6 Node 363 Requirements [RFC8504]. 365 Nodes that connect to a network that spans more than just a single 366 LAN configure at least one non-link-local adddress, i.e., for network 367 management and error reporting purposes. 369 Nodes recognize the Subnet Router Anycast address [RFC4291] for each 370 delegated prefix. Therefore, the node's use of the Subnet Router 371 Anycast address must be indistinguishable from the behavior of an 372 ordinary router when viewed from the outside world. 374 6. MLD/DAD Implications 376 When a node configures addresses for itself from a shared or 377 individual prefix (and when the interface variable 378 'DupAddrDetectTransmits' is non-zero [RFC4862]), the node performs 379 MLD/DAD by sending multicast messages over the upstream interface to 380 test whether there is another node on the link that configures a 381 duplicate address. When there are many such addresses and/or many 382 such nodes, this could result in substantial multicast traffic that 383 affects all nodes on the link. 385 When a node configures addresses for itself from a delegated prefix 386 and assigns them on downstream interfaces, it can configure as many 387 addresses as it wants without performing MLD/DAD for any of the 388 addresses over the upstream interface. 390 When a node configures addresses for itself from a delegated prefix 391 and assigns them on the upstream interface over which the prefix was 392 received, the node honors MLD/DAD procedures according the the 393 interface's 'DupAddrDetectTransmits' variable. 395 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 397 7. Dynamic Routing Protocol Implications 399 Nodes that receive delegated prefixes can be configured to either 400 participate or not participate in a dynamic routing protocol over the 401 upstream interface. When there are many nodes on the upstream link, 402 dynamic routing protocol participation might be impractical due to 403 scaling limitations, and may also be exacerbated by factors such as 404 node mobility. 406 Unless it participates in a dynamic routing protocol, the node 407 initially has only a default route pointing to a neighbor via an 408 upstream interface. This means that packets sent by the node over an 409 upstream interface will initially go through a default router even if 410 there is a better first-hop node on the link. The node may 411 subsequently receive Redirect messages from the default router that 412 identify a better first-hop. 414 8. IPv6 Neighbor Discovery Implications 416 According to [RFC4861], when a node receives a shared or individual 417 prefix with "L=1" and has a packet to send to an IPv6 destination 418 within the prefix, it is required to use the IPv6 ND address 419 resolution function to resolve the link-layer address of a neighbor 420 on the link that configures the address. 422 Also according to [RFC4861], when a node receives a shared or 423 individual prefix with "L=0" and has a packet to send to an IPv6 424 destination within the prefix, it sends the packet to a default 425 router since "L=0" makes no statement about on-link or off-link 426 properties of the prefix. 428 When a node requires a delegated prefix, it acts as a simple host by 429 sending RS messages over the upstream interface in the manner 430 described in Section 4.2 of [RFC7084] and invokes prefix delegation 431 services as discussed in Section 9. The node considers the upstream 432 interface as a non-advertising interface [RFC4861], i.e., it does not 433 send RA messages over the upstream interface. The node further does 434 not perform the IPv6 ND address resolution function over the upstream 435 interface, since the delegated prefix is by definition not associated 436 with the upstream interface. 438 9. Prefix Delegation Services 440 Selection of prefix delegation services must be considered according 441 to specific use cases. An example service is that offered by 442 standard DHCPv6 Prefix Delegation [RFC8415]. Alternative services 443 based on IPv6 ND messaging have also been proposed 444 [I-D.templin-6man-dhcpv6-ndopt][I-D.naveen-slaac-prefix-management]. 446 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 448 Other, non-router, mechanisms may exist, such as proprietary IPAMs, 449 [I-D.ietf-anima-prefix-management] and 450 [I-D.li-opsawg-address-pool-management-arch]. Requirements for 451 extending an IPv6 /64 Prefix from a Third Generation Partnership 452 Project (3GPP) Mobile Interface to a LAN Link are discussed in 453 [RFC7278]. 455 10. IANA Considerations 457 This document introduces no IANA considerations. 459 11. Security Considerations 461 Security considerations for IPv6 Neighbor Discovery [RFC4861] and any 462 applicable PD mechanisms apply to this document. Nodes that manage 463 their delegated prefixes such that MLD/DAD procedures are not needed 464 on the upstream interface can avoid introducing multicast messaging 465 congestion on the upstream link. Also, routers that delegate 466 prefixes keep only a single neighbor cache entry for each prefix 467 delegation recipient, meaning that the router's neighbor cache cannot 468 be subject to address resolution-based resource exhaustion attacks. 470 For shared and individual prefixes, if the advertising router 471 considers the prefix as on-link the IPv6 ND address resolution 472 function will prevent unwanted IPv6 packets from reaching the node. 473 For delegated prefixes and individual prefixes that are not 474 considered on-link, the router delivers all packets that match the 475 prefix to the node. In that case, the node may receive unwanted IPv6 476 packets via an upstream interface for which it has no matching 477 configured address. The node then drops the packets and observes the 478 ICMPv6 "Destination Unreachable - Address/Port unreachable" 479 procedures discussed in [RFC4443]. 481 The node may also receive IPv6 packets via an upstream interface that 482 do not match any of the node's delegated prefixes. In that case, the 483 node drops the packets and observes the ICMPv6 "Destination 484 Unreachable - No route to destination" procedures discussed in 485 [RFC4443]. Dropping the packets is necessary to avoid a reflection 486 attack that would cause the node to forward packets received from an 487 upstream interface via the same or a different upstream interface. 489 12. Acknowledgements 491 This work was motivated by discussions on the v6ops list. Mark 492 Smith, Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Ron Bonica, 493 Naveen Lakshman, Ole Troan, Bob Hinden, Brian Carpenter, Joel 494 Halpern, Albert Manfredi, Dusan Mudric, Paul Marks, Joe Touch, Alex 496 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 498 Petrescu, Lorenzo Colitti, Tatuya Jinmei and Naveen Kottapalli 499 provided useful comments that have greatly improved the document. 501 This work is aligned with the NASA Safe Autonomous Systems Operation 502 (SASO) program under NASA contract number NNA16BD84C. 504 This work is aligned with the FAA as per the SE2025 contract number 505 DTFAWA-15-D-00030. 507 This work is aligned with the Boeing Commercial Airplanes (BCA) 508 Internet of Things (IoT) and autonomy programs. 510 This work is aligned with the Boeing Information Technology (BIT) 511 MobileNet program. 513 13. References 515 13.1. Normative References 517 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 518 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 519 DOI 10.17487/RFC3810, June 2004, 520 . 522 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 523 Control Message Protocol (ICMPv6) for the Internet 524 Protocol Version 6 (IPv6) Specification", STD 89, 525 RFC 4443, DOI 10.17487/RFC4443, March 2006, 526 . 528 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 529 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 530 DOI 10.17487/RFC4861, September 2007, 531 . 533 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 534 Address Autoconfiguration", RFC 4862, 535 DOI 10.17487/RFC4862, September 2007, 536 . 538 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 539 (IPv6) Specification", STD 86, RFC 8200, 540 DOI 10.17487/RFC8200, July 2017, 541 . 543 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 545 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 546 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 547 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 548 RFC 8415, DOI 10.17487/RFC8415, November 2018, 549 . 551 13.2. Informative References 553 [I-D.ietf-anima-prefix-management] 554 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 555 IPv6 Edge Prefix Management in Large-scale Networks", 556 draft-ietf-anima-prefix-management-07 (work in progress), 557 December 2017. 559 [I-D.li-opsawg-address-pool-management-arch] 560 Li, C., Xie, C., Kumar, R., Fioccola, G., Xu, W., LIU, W., 561 Ma, D., and J. Bi, "Coordinated Address Space Management 562 architecture", draft-li-opsawg-address-pool-management- 563 arch-01 (work in progress), July 2018. 565 [I-D.naveen-slaac-prefix-management] 566 Kottapalli, N., "IPv6 Stateless Prefix Management", draft- 567 naveen-slaac-prefix-management-00 (work in progress), 568 November 2018. 570 [I-D.templin-6man-dhcpv6-ndopt] 571 Templin, F., "A Unified Stateful/Stateless Configuration 572 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-08 573 (work in progress), June 2019. 575 [I-D.templin-6man-rio-redirect] 576 Templin, F. and j. woodyatt, "Route Information Options in 577 IPv6 Neighbor Discovery", draft-templin-6man-rio- 578 redirect-08 (work in progress), June 2019. 580 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 581 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 582 2006, . 584 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 585 Requirements for IPv6 Customer Edge Routers", RFC 7084, 586 DOI 10.17487/RFC7084, November 2013, 587 . 589 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 591 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 592 /64 Prefix from a Third Generation Partnership Project 593 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 594 DOI 10.17487/RFC7278, June 2014, 595 . 597 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 598 "Host Address Availability Recommendations", BCP 204, 599 RFC 7934, DOI 10.17487/RFC7934, July 2016, 600 . 602 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 603 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 604 . 606 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 607 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 608 January 2019, . 610 Appendix A. Change Log 612 << RFC Editor - remove prior to publication >> 614 Changes from -24 to -25: 616 o Version and reference update 618 Changes from -23 to -24: 620 o Version and reference update 622 Changes from -22 to -23: 624 o Changed DHCPv6 references to RFC8415. Deprecate RFC3315 and 625 RFC3633. 627 o New text on assignment of addresses and prefixes on the upstream 628 interface. 630 Changes from -21 to -22: 632 o Changes to address list comments contributed by Lorenzo Colitti, 633 Tatuya Jinmei, Brian Carpenter and Fred Baker. 635 o Deleted section on ICMPv6 - now defer to normative reference 636 [RFC4443]. 638 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 640 o Discuss 'DupAddrDetectTransmits' variable implications under MLD/ 641 DAD considerations. 643 Changes from -20 to -21: 645 o Re-worked classic routing model section 647 o Included multi-addressing case where addresses may be assigned to 648 applications 650 o Removed strong/weak end system discussions 652 Changes from -19 to -20: 654 o figure 1 updates to show Server as being somewhere in the network 656 o Introductory material to show relation to other RFCs on multi- 657 addressing 659 Changes from -18 to -19: 661 o added new section on Prefix Delegation Services 663 Changes from -17 to -18: 665 o re-worked discussion on the prefix delegation service in Section 1 667 o updated figures in Section 1 669 Changes from -16 to -17: 671 o added supporting text in the introduction to discuss the 672 Delegating Router's relationship with the Requesting Router and 673 with supporting intrastructure in the operator's network 675 o updated figures in introduction to include representation of 676 operator's network 678 o added new section on Address Autoconfiguration Considerations 680 Author's Address 681 Internet-DrafIPv6 Prefix Delegation and Multi-Addressing Mo January 2020 683 Fred L. Templin (editor) 684 Boeing Research & Technology 685 P.O. Box 3707 686 Seattle, WA 98124 687 USA 689 Email: fltemplin@acm.org