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