idnits 2.17.1 draft-templin-v6ops-pdhost-20.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 (May 29, 2018) is 2158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-6man-rfc6434-bis-08 == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-06 Summary: 2 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 May 29, 2018 5 Expires: November 30, 2018 7 IPv6 Prefix Delegation Models 8 draft-templin-v6ops-pdhost-20.txt 10 Abstract 12 IPv6 prefixes are typically delegated to requesting routers which 13 assign them to their downstream-attached links and networks. The 14 requesting node can provision the prefix according to whether it acts 15 as a router on behalf of any downstream networks and/or as a host on 16 behalf of its local applications. In the latter case, the requesting 17 node can use portions of the delegated prefix for its own multi- 18 addressing purposes. This document therefore considers prefix 19 delegation models for both the classic routing and multi-addressing 20 use cases. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 30, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Multi-Addressing Considerations . . . . . . . . . . . . . . . 6 59 4. Multi-Addressing Alternatives for Delegated Prefixes . . . . 6 60 5. Address Autoconfiguration Considerations . . . . . . . . . . 7 61 6. MLD/DAD Implications . . . . . . . . . . . . . . . . . . . . 7 62 7. Dynamic Routing Protocol Implications . . . . . . . . . . . . 8 63 8. IPv6 Neighbor Discovery Implications . . . . . . . . . . . . 8 64 9. ICMPv6 Implications . . . . . . . . . . . . . . . . . . . . . 9 65 10. Prefix Delegation Services . . . . . . . . . . . . . . . . . 9 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 14.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 IPv6 Prefix Delegation (PD) entails 1) the communication of a prefix 78 from a server to a requesting router, 2) a representation of the 79 prefix in the network's Routing Information Base (RIB) and the first- 80 hop router's forwarding information base (FIB), and 3) a control 81 messaging service to maintain prefix lifetimes. Following 82 delegation, the prefix is available for the requesting router's 83 exclusive use and is not shared with any other nodes. This document 84 considers prefix delegation models where the requesting node acts as 85 a router on behalf of any downstream networks and/or as a host on 86 behalf of its local applications. 88 For nodes that connect downstream-attached networks (e.g., a 89 cellphone that connects a "tethered" Internet of Things, a host with 90 a complex internal network of virtual machines, etc.), the classic 91 routing model applies as shown in Figure 1: 93 .---------. 94 ,-( )-. 95 ( +----------+ ) 96 ( |Server 'S'| ) 97 ( +----------+ ) 98 ( Network 'N' ) 99 `-(__________)-' 100 | 101 +----------+----------+ 102 | first-hop router 'F'| 103 +----------+----------+ 104 | 105 upstream link | 106 | 107 +----------+----------+ 108 | upstream interface | 109 +---------------------+ 110 | | 111 |requesting router 'R'| 112 | (Prefix 'P') | 113 | | 114 +--+-+--+-+--+-----+--+ 115 |A1| |A2| |A3| ... |Aj| 116 +--+-+--+-+--+-----+--+ 117 | downstream interface| 118 +----------+----------+ 119 | 120 downstream link | 121 | 122 X----+-------------+--------+----+---------------+---X 123 | | | | 124 +---++-+--+ +---++-+--+ +---++-+--+ +---++-+--+ 125 | |Ak| | | |Al| | | |Am| | | |A*| | 126 | +--+ | | +--+ | | +--+ | | +--+ | 127 | host H1 | | host H2 | | host H3 | ... | host Hn | 128 +---------+ +---------+ +---------+ +---------+ 130 <-------------- Downstream Network -------------> 132 Figure 1: Classic Routing Model 134 In this model, there is a server 'S' located somewhere in network 'N' 135 to which first-hop router 'F' is also connected. When server 'S' 136 delegates prefix 'P', first-hop router 'F' configures a FIB entry 137 with requesting router ''R' as the next hop, and the prefix is 138 injected into network 'N's RIB. Meanwhile, 'R' distributes 'P' to 139 its downstream external (physical) and/or internal (virtual) 140 networks. 'R' assigns addresses 'A(*)' taken from 'P' to downstream 141 interfaces, and hosts 'H(i)' on downstream networks assign addresses 142 'A(*)' taken from 'P' to their interface attachments to the 143 downstream link. 'R' then acts as a router for hosts 'H(i)' on 144 downstream networks and as a host on behalf of its local 145 applications, i.e., the same as for any router. (This model 146 additionaly supports recursive prefix sub-delegation to other 147 requesting routers more deeply embedded in the downstream network, 148 e.g., sub-delegation of a /48 into multiple /56 prefixes, sub- 149 delegation of a /56 into multiple /60 prefixes, etc.). 151 This document also considers the case when 'R' does not have any 152 downstream interfaces, and can use 'P' solely for its own internal 153 multi-addressing purposes. [RFC7934] provides Best Current Practice 154 (BCP) motivations for the benefits of multi-addressing, while an 155 operational means for providing nodes with multiple addresses is 156 given in [RFC8273]. The following prefix delegation models 157 compliment this multi-addressing framework while providing greater 158 efficiency since no duplicate address queries over the upstream link 159 are necessary (see:Section 3). 161 In the multi-addressing model, when requesting node 'R' receives 162 prefix 'P', it assigns the prefix to a virtual interface (e.g., a 163 loopback) instead of a physical or virtual downstream interface. 'R' 164 can then function under the weak end system (aka "weak host") model 165 [RFC1122][RFC8028] by assigning addresses taken from 'P' to virtual 166 interfaces as shown in Figure 2: 168 x 169 | 170 upstream link | 171 | 172 +----------+----------+ 173 | upstream Interface | 174 +---------------------+ 175 | | 176 | requesting node 'R' | 177 | | 178 +--+-+--+-+--+-----+--+ 179 |A1| |A2| |A3| ... |An| 180 +--+-+--+-+--+-----+--+ 181 | virtual Interface | 182 +---------------------+ 184 Figure 2: Weak End System Model 186 'R' could instead function under the strong end system (aka "strong 187 host") model [RFC1122][RFC8028] by assigning IPv6 addresses taken 188 from 'P' to the upstream interface as shown in Figure 3: 190 x 191 | 192 upstream link | 193 | 194 +----------+----------+ 195 | upstream interface | 196 +--+-+--+-+--+-----+--+ 197 |A1| |A2| |A3| ... |An| 198 +--+-+--+-+--+-----+--+ 199 | | 200 | requesting node 'R' | 201 | | 202 +---------------------+ 203 | virtual interface | 204 +---------------------+ 206 Figure 3: Strong End System Model 208 The major benefit for a node managing a delegated prefix in either 209 the weak or strong end system models is multi-addressing. With IPv6 210 PD-based multi-addressing, the node can configure an unlimited supply 211 of addresses to make them available for local applications without 212 requiring coordination with other nodes on upstream interfaces. 214 The following sections present considerations for nodes that employ 215 IPv6 PD mechanisms. 217 2. Terminology 219 The terminology of the normative references apply, and the terms 220 "node", "host" and "router" are the same as defined in [RFC8200]. 222 The following terms are defined for the purposes of this document: 224 shared prefix 225 an IPv6 prefix that may be advertised to more than one node on the 226 link, e.g., in a Router Advertisement (RA) message Prefix 227 Information Option (PIO) [RFC4861]. The router that advertises 228 the prefix must consider the prefix as on-link so that the IPv6 229 Neighbor Discovery (ND) address resolution function will identify 230 the correct neighbor for each packet. 232 individual prefix 233 an IPv6 prefix that is advertised to exactly one node on the link, 234 where the node may be unaware that the prefix is individual and 235 may not participate in prefix maintenance procedures. The router 236 that advertises the prefix can consider the prefix as on-link or 237 not on-link. In the former case, the router performs address 238 resolution and only forwards those packets that match one of the 239 node's configured addresses so that the node will not receive 240 unwanted packets. In the latter case, the router can simply 241 forward all packets matching the prefix to the node which must 242 then drop any packets that do not match one of its configured 243 addresses. An example individual prefix service is documented in 244 [RFC8273]. 246 delegated prefix 247 an IPv6 prefix that is explicitly conveyed to a node for its own 248 exclusive use, where the node is an active participant in prefix 249 delegation and maintenance procedures. The first-hop router 250 simply forwards all packets matching the prefix to the requesting 251 node. The requesting node associates the prefix with downstream 252 and/or internal virtual interfaces (i.e., and not the upstream 253 interface). 255 3. Multi-Addressing Considerations 257 IPv6 allows nodes to assign multiple addresses to a single interface. 258 [RFC7934] discusses options for multi-addressing as well as use cases 259 where multi-addressing may be desirable. Address configuration 260 options for multi-addressing include StateLess Address 261 AutoConfiguration (SLAAC) [RFC4862], Dynamic Host Configuration 262 Protocol for IPv6 (DHCPv6) address configuration [RFC3315], manual 263 configuration, etc. 265 Nodes configure addresses from a shared or individual prefix and 266 assign them to the upstream interface over which the prefix was 267 received. When the node assigns the addresses, it is required to use 268 Multicast Listener Discovery (MLD) [RFC3810] to join the appropriate 269 solicited-node multicast group(s) and to use the Duplicate Address 270 Detection (DAD) algorithm [RFC4862] to ensure that no other node 271 configures a duplicate address. 273 In contrast, a node that configures addresses from a delegated prefix 274 can assign them without invoking MLD/DAD on an upstream interface, 275 since the prefix has been delegated to the node for its own exclusive 276 use and is not shared with any other nodes. 278 4. Multi-Addressing Alternatives for Delegated Prefixes 280 When a node receives a delegated prefix, it has many alternatives for 281 provisioning the prefix to its local interfaces and/or downstream 282 networks. [RFC7278] discusses alternatives for provisioning a prefix 283 obtained by a User Equipment (UE) device under the 3rd Generation 284 Partnership Program (3GPP) service model. This document considers 285 the more general case when the node receives a delegated prefix 286 explicitly provided for its own exclusive use. 288 When the node receives the prefix, it can distribute the prefix to 289 downstream networks and configure zero or more addresses for itself 290 on downstream interfaces. The node then acts as a router on behalf 291 of its downstream networks and configures a default route via a 292 neighbor on an upstream interface. 294 The node could instead (or in addition) use portions of the delegated 295 prefix for its own multi-addressing purposes. In a first 296 alternative, the node can assign as many addresses as it wants from 297 the prefix to virtual interfaces. In that case, applications running 298 on the node can use the addresses according to the weak end system 299 model. 301 In a second alternative, the node can assign as many addresses as it 302 wants from the prefix to the upstream interface over which the prefix 303 was received. In that case, applications running on the node can use 304 the addresses according to the strong end system model. 306 In both of these latter two cases, the node assigns the prefix itself 307 to a virtual interface so that unused portions of the prefix are 308 correctly identified as unreachable. The node then acts as a host on 309 behalf of its local applications even though neighbors on the 310 upstream link consider it as a router. 312 5. Address Autoconfiguration Considerations 314 Nodes that act according to the weak/strong host models as discussed 315 in the previous section autoconfigure addresses from delegated 316 prefixes according to Section 6 of IPv6 Node Requirements 317 [I-D.ietf-6man-rfc6434-bis]. 319 As a recipient of a delegated prefix, the node is also required to 320 recognize the Subnet Router Anycast address [RFC4291]. Therefore, 321 the node's use of the Subnet Router Anycast address must be 322 indistinguishable from the behavior of an ordinary router when viewed 323 from the outside world. 325 6. MLD/DAD Implications 327 When a node configures addresses for itself from a shared or 328 individual prefix, it performs MLD/DAD by sending multicast messages 329 over upstream interfaces to test whether there is another node on the 330 link that configures a duplicate address. When there are many such 331 addresses and/or many such nodes, this could result in substantial 332 multicast traffic that affects all nodes on the link. 334 When a node configures addresses for itself from a delegated prefix, 335 it can configure as many addresses as it wants but does not perform 336 MLD/DAD for any of the addresses over upstream interfaces. This 337 means that the node can configure arbitrarily many addresses without 338 causing any multicast messaging over the upstream interface that 339 could disturb other nodes. 341 7. Dynamic Routing Protocol Implications 343 Nodes that receive delegated prefixes can be configured to either 344 participate or not participate in a dynamic routing protocol over the 345 upstream interface, according to the deployment model. When there 346 are many nodes on the upstream link, dynamic routing protocol 347 participation might be impractical due to scaling limitations, and 348 may also be exacerbated by factors such as node mobility. 350 Unless it participates in a dynamic routing protocol, the node 351 initially has only a default route pointing to a neighbor via an 352 upstream interface. This means that packets sent by the node over an 353 upstream interface will initially go through a default router even if 354 there is a better first-hop node on the link. 356 8. IPv6 Neighbor Discovery Implications 358 When a node receives a shared or individual prefix with "L=1" and has 359 a packet to send to an IPv6 destination within the prefix, it is 360 required to use the IPv6 ND address resolution function over the 361 upstream interface to resolve the link-layer address of a neighbor 362 that configures the address. When a node receives a shared or 363 individual prefix with "L=0" and has a packet to send to an IPv6 364 destination within the prefix, if the address is not one of the 365 node's own addresses it sends the packet to a default router since 366 "L=0" makes no statement about on-link or off-link properties of the 367 prefix [RFC4861]. 369 When a node receives a delegated prefix, it acts as a simple host to 370 send Router Solicitation (RS) messages over upstream interfaces 371 (i.e., the same as described in Section 4.2 of [RFC7084]) but also 372 sets the "Router" flag to TRUE in its Neighbor Advertisement 373 messages. The node considers the upstream interfaces as non- 374 advertising interfaces [RFC4861], i.e., it does not send RA messages 375 over the upstream interfaces. The node further does not perform the 376 IPv6 ND address resolution function over upstream interfaces, since 377 the delegated prefix is by definition not to be associated with an 378 upstream interface. 380 In all cases, the current first-hop router may send a Redirect 381 message that updates the node's neighbor cache so that future packets 382 can use a better first-hop node on the link. The Redirect can apply 383 either to a singleton destination address, or to an entire 384 destination prefix as described in [I-D.templin-6man-rio-redirect]. 386 9. ICMPv6 Implications 388 The Internet Control Message Protocol for IPv6 (ICMPv6) includes a 389 set of control message types [RFC4443] including Destination 390 Unreachable (DU). 392 According to [RFC4443], routers should return DU messages (subject to 393 rate limiting) with code 0 ("No route to destination") when a packet 394 arrives for which there is no matching entry in the routing table, 395 and with code 3 ("Address unreachable") when the IPv6 destination 396 address cannot be resolved. 398 According to [RFC4443], hosts should return DU messages (subject to 399 rate limiting) with code 3 to internal applications when the IPv6 400 destination address cannot be resolved, and with code 4 ("Port 401 unreachable") if the IPv6 destination address is one of its own 402 addresses but the transport protocol has no listener. 404 Nodes that obtain and manage delegated prefixes per this document 405 observe the same procedures as described for both routers and hosts 406 above. 408 10. Prefix Delegation Services 410 Selection of prefix delegation services must be considered according 411 to specific use cases. An example service is that offered by DHCPv6 412 [RFC3633]. An alternative service based on IPv6 ND messaging has 413 also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]. 415 Other, non-router, mechanisms may exist, such as proprietary IPAMs, 416 [I-D.ietf-anima-prefix-management] and 417 [I-D.sun-casm-address-pool-management-yang]. 419 11. IANA Considerations 421 This document introduces no IANA considerations. 423 12. Security Considerations 425 Security considerations for IPv6 Neighbor Discovery [RFC4861] and any 426 applicable PD mechanisms apply to this document. Nodes that receive 427 delegated prefixes do not perform MLD/DAD procedures on their 428 upstream interfaces, meaning that they cannot contribute to multicast 429 messaging congestion on the upstream link. Also, routers that 430 delegate prefixes keep only a single neighbor cache entry for each 431 prefix delegation recipient, meaning that the router's neighbor cache 432 cannot be subject to resource exhaustion attacks. 434 For shared and individual prefixes, if the router that advertises the 435 prefix considers the prefix as on-link the IPv6 ND address resolution 436 function will prevent unwanted IPv6 packets from reaching the node. 437 For delegated prefixes and individual prefixes that are not 438 considered on-link, the router delivers all packets that match the 439 prefix to the unicast link-layer address of the node (i.e., as 440 determined by resolution of the node's link-local address) even if 441 they do not match one of the node's configured addresses. In that 442 case, the node may receive unwanted IPv6 packets via an upstream 443 interface that do not match either a configured IPv6 address or a 444 transport listener. The node then drops the packets and observes the 445 "Destination Unreachable - Address/Port unreachable" procedures 446 discussed in Section 9. 448 The node may also receive IPv6 packets via an upstream interface that 449 do not match any of the node's delegated prefixes. In that case, the 450 node drops the packets and observes the "Destination Unreachable - No 451 route to destination" procedures discussed in Section 9. Dropping 452 the packets is necessary to avoid a reflection attack that would 453 cause the node to forward packets received from an upstream interface 454 via the same or a different upstream interface. 456 In all cases, the node must decide whether or not to send DUs 457 according to the specific operational scenario. In trusted networks, 458 the node should send DU messages to provide useful information to 459 potential correspondents. In untrusted networks, the node can 460 refrain from sending DU messages to avoid providing sensitive 461 information to potential attackers. 463 13. Acknowledgements 465 This work was motivated by discussions on the v6ops list. Mark 466 Smith, Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Ron Bonica, 467 Naveen Lakshman, Ole Troan, Bob Hinden, Brian Carpenter, Joel 468 Halpern, Albert Manfredi, Dusan Mudric and Paul Marks provided useful 469 comments that have greatly improved the document. 471 This work is aligned with the NASA Safe Autonomous Systems Operation 472 (SASO) program under NASA contract number NNA16BD84C. 474 This work is aligned with the FAA as per the SE2025 contract number 475 DTFAWA-15-D-00030. 477 This work is aligned with the Boeing Information Technology (BIT) 478 MobileNet program and the Boeing Research & Technology (BR&T) 479 enterprise autonomy program. 481 14. References 483 14.1. Normative References 485 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 486 C., and M. Carney, "Dynamic Host Configuration Protocol 487 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 488 2003, . 490 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 491 Host Configuration Protocol (DHCP) version 6", RFC 3633, 492 DOI 10.17487/RFC3633, December 2003, 493 . 495 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 496 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 497 DOI 10.17487/RFC3810, June 2004, 498 . 500 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 501 Control Message Protocol (ICMPv6) for the Internet 502 Protocol Version 6 (IPv6) Specification", STD 89, 503 RFC 4443, DOI 10.17487/RFC4443, March 2006, 504 . 506 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 507 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 508 DOI 10.17487/RFC4861, September 2007, 509 . 511 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 512 Address Autoconfiguration", RFC 4862, 513 DOI 10.17487/RFC4862, September 2007, 514 . 516 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 517 (IPv6) Specification", STD 86, RFC 8200, 518 DOI 10.17487/RFC8200, July 2017, 519 . 521 14.2. Informative References 523 [I-D.ietf-6man-rfc6434-bis] 524 Chown, T., Loughney, J., and T. Winters, "IPv6 Node 525 Requirements", draft-ietf-6man-rfc6434-bis-08 (work in 526 progress), March 2018. 528 [I-D.ietf-anima-prefix-management] 529 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 530 IPv6 Edge Prefix Management in Large-scale Networks", 531 draft-ietf-anima-prefix-management-07 (work in progress), 532 December 2017. 534 [I-D.pioxfolks-6man-pio-exclusive-bit] 535 Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement 536 Prefix Information Option eXclusive Flag", draft- 537 pioxfolks-6man-pio-exclusive-bit-02 (work in progress), 538 March 2017. 540 [I-D.sun-casm-address-pool-management-yang] 541 Sun, Q., Xie, C., Boucadair, M., Peng, T., and Y. Lee, "A 542 YANG Data Model for Address Pool Management", draft-sun- 543 casm-address-pool-management-yang-00 (work in progress), 544 March 2017. 546 [I-D.templin-6man-rio-redirect] 547 Templin, F. and j. woodyatt, "Route Information Options in 548 IPv6 Neighbor Discovery", draft-templin-6man-rio- 549 redirect-06 (work in progress), May 2018. 551 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 552 Communication Layers", STD 3, RFC 1122, 553 DOI 10.17487/RFC1122, October 1989, 554 . 556 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 557 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 558 2006, . 560 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 561 Requirements for IPv6 Customer Edge Routers", RFC 7084, 562 DOI 10.17487/RFC7084, November 2013, 563 . 565 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 566 /64 Prefix from a Third Generation Partnership Project 567 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 568 DOI 10.17487/RFC7278, June 2014, 569 . 571 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 572 "Host Address Availability Recommendations", BCP 204, 573 RFC 7934, DOI 10.17487/RFC7934, July 2016, 574 . 576 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 577 Hosts in a Multi-Prefix Network", RFC 8028, 578 DOI 10.17487/RFC8028, November 2016, 579 . 581 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 582 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 583 . 585 Appendix A. Change Log 587 << RFC Editor - remove prior to publication >> 589 Changes from -19 to -20: 591 o figure 1 updates to show Server as being somewhere in the network 593 o Introductory material to show relation to other RFCs on multi- 594 addressing 596 Changes from -18 to -19: 598 o added new section on Prefix Delegation Services 600 Changes from -17 to -18: 602 o re-worked discussion on the prefix delegation service in Section 1 604 o updated figures in Section 1 606 Changes from -16 to -17: 608 o added supporting text in the introduction to discuss the 609 Delegating Router's relationship with the Requesting Router and 610 with supporting intrastructure in the operator's network 612 o updated figures in introduction to include representation of 613 operator's network 615 o added new section on Address Autoconfiguration Considerations 617 Author's Address 619 Fred L. Templin (editor) 620 Boeing Research & Technology 621 P.O. Box 3707 622 Seattle, WA 98124 623 USA 625 Email: fltemplin@acm.org