idnits 2.17.1 draft-templin-v6ops-pdhost-22.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 (December 17, 2018) is 1954 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 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-06 == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-06 Summary: 2 errors (**), 0 flaws (~~), 4 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 December 17, 2018 5 Expires: June 20, 2019 7 IPv6 Prefix Delegation and Multi-Addressing Models 8 draft-templin-v6ops-pdhost-22.txt 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 June 20, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . 8 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 Addresssing 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 Advertisment (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 [RFC3315], 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 does not assign the prefix itself (or subnets from 321 the prefix) to the upstream interface. By assigning only addresses, 322 the node observes the specification in [RFC3633], Section 12.1 which 323 forbids assignment of the prefix to the upstream interface. 325 In a third alternative, the node can assign addresses taken from the 326 delegated prefix to its local applications. The applications 327 themselves then serve as virtual interfaces. (Note that, in the 328 future, the practice of assigning unique non-link-local IPv6 329 addresses to applications could obviate the need for transport 330 protocol port numbers.) 331 In these multi-addressing cases, the node assigns the prefix itself 332 to a virtual interface such as a loopback so that unused portions of 333 the prefix are correctly identified as unreachable. The node then 334 acts as a host on behalf of its local applications even though 335 neighbors on the upstream link consider it as a router. 337 5. Address Autoconfiguration Considerations 339 Nodes autoconfigure addresses according to Section 6 of IPv6 Node 340 Requirements [I-D.ietf-6man-rfc6434-bis]. 342 Nodes that connect to a network that spans more than just a single 343 LAN configure at least one non-link-local adddress, i.e., for network 344 management and error reporting purposes. 346 Nodes recognize the Subnet Router Anycast address [RFC4291] for each 347 delegated prefix. Therefore, the node's use of the Subnet Router 348 Anycast address must be indistinguishable from the behavior of an 349 ordinary router when viewed from the outside world. 351 6. MLD/DAD Implications 353 When a node configures addresses for itself from a shared or 354 individual prefix (and when the interface variable 355 'DupAddrDetectTransmits' is non-zero [RFC4862]), the node performs 356 MLD/DAD by sending multicast messages over the upstream interface to 357 test whether there is another node on the link that configures a 358 duplicate address. When there are many such addresses and/or many 359 such nodes, this could result in substantial multicast traffic that 360 affects all nodes on the link. 362 When a node configures addresses for itself from a delegated prefix 363 and assigns them on downstream interfaces, it can configure as many 364 addresses as it wants without performing MLD/DAD for any of the 365 addresses over the upstream interface. 367 When a node configures addresses for itself from a delegated prefix 368 and assigns them on the upstream interface over which the prefix was 369 received, the node honors MLD/DAD procedures according the the 370 interface's 'DupAddrDetectTransmits' variable. 372 7. Dynamic Routing Protocol Implications 374 Nodes that receive delegated prefixes can be configured to either 375 participate or not participate in a dynamic routing protocol over the 376 upstream interface. When there are many nodes on the upstream link, 377 dynamic routing protocol participation might be impractical due to 378 scaling limitations, and may also be exacerbated by factors such as 379 node mobility. 381 Unless it participates in a dynamic routing protocol, the node 382 initially has only a default route pointing to a neighbor via an 383 upstream interface. This means that packets sent by the node over an 384 upstream interface will initially go through a default router even if 385 there is a better first-hop node on the link. The node may 386 subsequently receive Redirect messages from the default router that 387 identify a better first-hop. 389 8. IPv6 Neighbor Discovery Implications 391 According to [RFC4861], when a node receives a shared or individual 392 prefix with "L=1" and has a packet to send to an IPv6 destination 393 within the prefix, it is required to use the IPv6 ND address 394 resolution function to resolve the link-layer address of a neighbor 395 on the link that configures the address. 397 Also according to [RFC4861], when a node receives a shared or 398 individual prefix with "L=0" and has a packet to send to an IPv6 399 destination within the prefix, it sends the packet to a default 400 router since "L=0" makes no statement about on-link or off-link 401 properties of the prefix. 403 When a node requires a delegated prefix, it acts as a simple host by 404 sending RS messages over the upstream interface in the manner 405 described in Section 4.2 of [RFC7084] and invokes prefix delegation 406 services as discussed in Section 9. The node considers the upstream 407 interface as a non-advertising interface [RFC4861], i.e., it does not 408 send RA messages over the upstream interface. The node further does 409 not perform the IPv6 ND address resolution function over the upstream 410 interface, since the delegated prefix is by definition not associated 411 with the upstream interface. 413 9. Prefix Delegation Services 415 Selection of prefix delegation services must be considered according 416 to specific use cases. An example service is that offered by 417 standard DHCPv6 Prefix Delegation [RFC3633]. Alternative services 418 based on IPv6 ND messaging have also been proposed 419 [I-D.templin-6man-dhcpv6-ndopt][I-D.naveen-slaac-prefix-management]. 421 Other, non-router, mechanisms may exist, such as proprietary IPAMs, 422 [I-D.ietf-anima-prefix-management] and 423 [I-D.li-opsawg-address-pool-management-arch]. Requirements for 424 extending an IPv6 /64 Prefix from a Third Generation Partnership 425 Project (3GPP) Mobile Interface to a LAN Link are discussed in 426 [RFC7278]. 428 10. IANA Considerations 430 This document introduces no IANA considerations. 432 11. Security Considerations 434 Security considerations for IPv6 Neighbor Discovery [RFC4861] and any 435 applicable PD mechanisms apply to this document. Nodes that manage 436 their delegated prefixes such that MLD/DAD procedures are not needed 437 on the upstream interface can avoid introducing multicast messaging 438 congestion on the upstream link. Also, routers that delegate 439 prefixes keep only a single neighbor cache entry for each prefix 440 delegation recipient, meaning that the router's neighbor cache cannot 441 be subject to address resolution-based resource exhaustion attacks. 443 For shared and individual prefixes, if the advertising router 444 considers the prefix as on-link the IPv6 ND address resolution 445 function will prevent unwanted IPv6 packets from reaching the node. 446 For delegated prefixes and individual prefixes that are not 447 considered on-link, the router delivers all packets that match the 448 prefix to the node. In that case, the node may receive unwanted IPv6 449 packets via an upstream interface for which it has no matching 450 configured address. The node then drops the packets and observes the 451 ICMPv6 "Destination Unreachable - Address/Port unreachable" 452 procedures discussed in [RFC4443]. 454 The node may also receive IPv6 packets via an upstream interface that 455 do not match any of the node's delegated prefixes. In that case, the 456 node drops the packets and observes the ICMPv6 "Destination 457 Unreachable - No route to destination" procedures discussed in 458 [RFC4443]. Dropping the packets is necessary to avoid a reflection 459 attack that would cause the node to forward packets received from an 460 upstream interface via the same or a different upstream interface. 462 12. Acknowledgements 464 This work was motivated by discussions on the v6ops list. Mark 465 Smith, Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Ron Bonica, 466 Naveen Lakshman, Ole Troan, Bob Hinden, Brian Carpenter, Joel 467 Halpern, Albert Manfredi, Dusan Mudric, Paul Marks, Joe Touch, Alex 468 Petrescu, Lorenzo Colitti, Tatuya Jinmei and Naveen Kottapalli 469 provided useful 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 13. References 483 13.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 13.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-09 (work in 526 progress), July 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.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 547 Autoconfiguration Service for IPv6", draft-templin-6man- 548 dhcpv6-ndopt-06 (work in progress), September 2018. 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-06 (work in progress), May 2018. 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 Appendix A. Change Log 581 << RFC Editor - remove prior to publication >> 583 Changes from -21 to -22: 585 o Changes to address list comments contributed by Lorenzo Colitti, 586 Tatuya Jinmei, Brian Carpenter and Fred Baker. 588 o Deleted section on ICMPv6 - now defer to normative reference 589 [RFC4443]. 591 o Discuss 'DupAddrDetectTransmits' variable implications under MLD/ 592 DAD considerations. 594 Changes from -20 to -21: 596 o Re-worked classic routing model section 598 o Included multi-addressing case where addresses may be assigned to 599 applications 601 o Removed strong/weak end system discussions 603 Changes from -19 to -20: 605 o figure 1 updates to show Server as being somewhere in the network 607 o Introductory material to show relation to other RFCs on multi- 608 addressing 610 Changes from -18 to -19: 612 o added new section on Prefix Delegation Services 614 Changes from -17 to -18: 616 o re-worked discussion on the prefix delegation service in Section 1 617 o updated figures in Section 1 619 Changes from -16 to -17: 621 o added supporting text in the introduction to discuss the 622 Delegating Router's relationship with the Requesting Router and 623 with supporting intrastructure in the operator's network 625 o updated figures in introduction to include representation of 626 operator's network 628 o added new section on Address Autoconfiguration Considerations 630 Author's Address 632 Fred L. Templin (editor) 633 Boeing Research & Technology 634 P.O. Box 3707 635 Seattle, WA 98124 636 USA 638 Email: fltemplin@acm.org