idnits 2.17.1 draft-templin-v6ops-pdhost-06.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 (September 5, 2017) is 2418 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 357, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-04 Summary: 3 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 September 5, 2017 5 Expires: March 9, 2018 7 IPv6 Prefix Delegation for Hosts 8 draft-templin-v6ops-pdhost-06.txt 10 Abstract 12 IPv6 prefixes are typically delegated to requesting routers which 13 then use them to number their downstream-attached links and networks. 14 This document considers both this traditional case, and the case when 15 the "requesting router" is actually a simple host which receives a 16 delegated prefix that it can use for its own internal multi- 17 addressing purposes. This latter method can be employed in a wide 18 variety of use cases to allow ample address availability without 19 impacting link performance. 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 March 9, 2018. 38 Copyright Notice 40 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Multi-Addressing Considerations . . . . . . . . . . . . . . . 5 58 4. Multi-Addressing Alternatives for Delegated Prefixes . . . . 6 59 5. MLD/DAD Implications . . . . . . . . . . . . . . . . . . . . 6 60 6. IPv6 Neighbor Discovery Implications . . . . . . . . . . . . 7 61 7. ICMPv6 Implications . . . . . . . . . . . . . . . . . . . . . 7 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 11.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 IPv6 Prefix Delegation (PD) entails 1) the communication of a prefix 73 from a delegating authority to a requesting node, 2) a representation 74 of the prefix in the routing system, and 3) a control messaging 75 service to maintain delegated prefix lifetimes. Following 76 delegation, the prefix is available for the requesting node's 77 exclusive use and is not shared with any other nodes. An example 78 IPv6 PD service is DHCPv6 PD [RFC3315][RFC3633]. 80 Using any available prefix delegation service, a Delegating Router 81 'D' delegates a prefix 'P' to a Requesting Node 'R'' as shown in 82 Figure 1: 84 +---------------------+ 85 |Delegating Router 'D'| 86 | (Delegate 'P') | 87 +----------+----------+ 88 | 89 .-(::::::::) 90 .-(:::: IP ::::)-. 91 (:: Internetwork ::) 92 `-(::::::::::::)-' 93 `-(::::::)-' 94 | WAN Interface 95 +----------+----------+ 96 | (Receive 'P') | 97 | Requesting Node 'R'| 98 +----------+----------+ 99 | LAN Interface 100 X----+-------------+--------+----+---------------+---X 101 | | LAN | | 102 +---++-+--+ +---++-+--+ +---++-+--+ +---++-+--+ 103 | |A1| | | |A2| | | |A3| | | |An| | 104 | +--+ | | +--+ | | +--+ | | +--+ | 105 | Host H1 | | Host H2 | | Host H3 | ... | Host Hn | 106 +---------+ +---------+ +---------+ +---------+ 108 Figure 1: Prefix Delegation Model 110 In this figure, when Delegating Router 'D' delegates prefix 'P', the 111 prefix is injected into the IP Internetwork routing system in some 112 fashion to ensure that IPv6 packets with destination addresses 113 covered by 'P' are unconditionally forwarded to Requesting Node 'R'. 114 Meanwhile, 'R' receives 'P' via its "WAN" interface and sub-delegates 115 'P' to its downstream-attached links via one or more "LAN" 116 interfaces. Hosts 'H(i)' on a LAN subsequently receive addresses 117 'A(i)' taken from 'P' via an address autoconfiguration service such 118 as IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. 'R' 119 then acts as a router between hosts 'H(i)' and correspondents 120 reachable via the WAN interface. 122 This document also considers the case when 'R' is actually a simple 123 host, and receives a prefix delegation 'P' as if it were a router. 124 The host need not have any LAN interfaces, and can use the prefix 125 solely for its own internal addressing purposes. 'R' can act as a 126 host under the weak end system model [RFC1122] if it can assign 127 addresses taken from 'P' to its own internal virtual interfaces 128 (e.g., a loopback) as shown in Figure 2: 130 +---------------------+ 131 |Delegating Router 'D'| 132 | (Delegate 'P') | 133 +----------+----------+ 134 | 135 .-(::::::::) 136 .-(:::: IP ::::)-. 137 (:: Internetwork ::) 138 `-(::::::::::::)-' 139 `-(::::::)-' 140 | WAN Interface 141 +----------+----------+ 142 | (Receive 'P') | 143 | Requesting Node 'R' | 144 +---------------------+ 145 | Loopback Interface | 146 +--+-+--+-++-+-----+--+ 147 |A1| |A2| |A3| ... |An| 148 +--+-+--+-+--+-----+--+ 150 Figure 2: Weak End System Model 152 'R' could instead function as a host under the strong end system 153 model [RFC1122] by assigning IPv6 addresses taken from prefix 'P' to 154 the WAN interface as shown in Figure 3: 156 +---------------------+ 157 |Delegating Router 'D'| 158 | (Delegate 'P') | 159 +----------+----------+ 160 | 161 .-(::::::::) 162 .-(:::: IP ::::)-. 163 (:: Internetwork ::) 164 `-(::::::::::::)-' 165 `-(::::::)-' 166 | WAN Interface 167 +--+-+--+-++-+-----+--+ 168 |A1| |A2| |A3| ... |An| 169 +--+ +--+ +--+ +--+ 170 | (Receive 'P') | 171 | Requesting Node 'R' | 172 +---------------------+ 174 Figure 3: Strong End System Model 176 The major benefit for a host managing a delegated prefix in either 177 the weak or strong end system models is multi-addressing. With 178 multi-addressing, the host can configure an unlimited supply of 179 addresses to make them available for local applications without 180 requiring coordination with any other nodes. 182 The following sections present multi-addressing considerations for 183 hosts that employ prefix delegation mechanisms. 185 2. Terminology 187 The terminology of the normative references apply. The following 188 terms are defined for the purposes of this document: 190 shared prefix 191 an IPv6 prefix that may be advertised to more than one node on the 192 same link, e.g., in a Prefix Information Option (PIO) included in 193 a Router Advertisement (RA) message [RFC4861]. The shared prefix 194 property applies not only on multiple access links (e.g., 195 multicast-capable, NBMA, shared media, etc.), but also on point- 196 to-point links where the shared prefix is visible to both ends of 197 the link. 199 delegated prefix 200 a prefix that is delegated to a requesting node solely for its own 201 use, and is not delegated to any other nodes on the link. 203 3. Multi-Addressing Considerations 205 IPv6 allows nodes to assign multiple addresses to a single interface. 206 [RFC7934] discusses options for multi-addressing as well as use cases 207 where multi-addressing may be desirable. Address configuration 208 options for multi-addressing include SLAAC [RFC4862], stateful DHCPv6 209 address configuration [RFC3315] and any other address formation 210 methods (e.g., manual configuration). 212 Nodes that use SLAAC and/or DHCPv6 address configuration configure 213 addresses from a shared prefix and assign them to the interface over 214 which the prefix was received (e.g., in an RA). When this happens, 215 the node is obliged to use Multicast Listener Discovery (MLD) to join 216 the appropriate solicited-node multicast group(s) and to use the 217 Duplicate Address Detection (DAD) algorithm [RFC4862] to ensure that 218 no other node that receives the shared prefix configures a duplicate 219 address. 221 In contrast, a node that uses address configuration from a delegated 222 prefix can assign addresses without invoking MLD/DAD on the WAN 223 interface, since the prefix has been delegated to the node for its 224 own exclusive use and is not shared with any other nodes. 226 4. Multi-Addressing Alternatives for Delegated Prefixes 228 When a node receives a prefix delegation, it has many alternatives 229 for the way in which it can provision the prefix. [RFC7278] 230 discusses alternatives for provisioning a prefix obtained by a User 231 Equipment (UE) device under the 3rd Generation Partnership Program 232 (3GPP) service model. This document considers the more general case 233 when the node receives a prefix delegation in which the prefix is 234 delegated for its own exclusive use. 236 When the node receives the prefix, it can distribute the prefix to 237 downstream-attached networks via its LAN interfaces and configure one 238 or more addresses for itself on a LAN interface. The node then acts 239 as a router on behalf of its downstream-attached networks and 240 configures a default route that points to a router on the WAN link. 241 This approach is often known as the "tethered" configuration. 243 The node could instead use the delegated prefix for its own multi- 244 addressing purposes. In a first alternative, the node can receive 245 the prefix acting as a requesting node over the WAN interface but 246 then assign the prefix to an internal virtual interface (e.g., a 247 loopback interface) and assign one or more addresses taken from the 248 prefix to the virtual interface. In that case, applications on the 249 node can use the assigned addresses according to the weak end system 250 model. 252 In a second alternative, the node can receive the prefix as a 253 requesting node over the WAN interface but then assign one or more 254 addresses taken from the prefix to the WAN interface. In that case, 255 applications on the node can use the assigned addresses according to 256 the strong end system model. 258 In both of these latter two cases, the node acts as a host internally 259 even though it behaves as a router from the standpoint of prefix 260 delegation and neighbor discovery over the WAN interface. The host 261 can configure as many addresses for itself as it wants. 263 5. MLD/DAD Implications 265 When a node configures addresses for itself using either SLAAC or 266 DHCPv6 from a shared prefix, the node performs MLD/DAD by sending 267 multicast messages to test whether there is another node on the link 268 that configures a duplicate address from the shared prefix. When 269 there are many such addresses and/or many such nodes, this could 270 result in substantial multicast traffic that affects all nodes on the 271 link. 273 When a node configures addresses for itself using a delegated prefix, 274 the node can configure as many addresses as it wants but does not 275 perform MLD/DAD for any of the addresses over the WAN interface. 276 This means that arbitrarily many addresses can be assigned without 277 causing any multicast messaging over the WAN link that could disturb 278 other nodes. 280 6. IPv6 Neighbor Discovery Implications 282 The node acts as a simple host to send Router Solicitation (RS) 283 messages over the WAN interface the same as described in Section 4.2 284 of [RFC7084]. 286 In order to maintain the appearance of a router (i.e., even though it 287 is acting as a simple host), the node sets the "Router" flag to TRUE 288 in any Neighbor Advertisement messages it sends. This ensures that 289 the "isRouter" flag in the neighbor cache entries of any neighbors 290 remains TRUE. 292 The node initially has only a default route pointing to a router on 293 the WAN link. This means that packets sent over the node's WAN 294 interface will initially go through a default router even if there is 295 a better first-hop node on the link. In that case,a Redirect message 296 can update the node's neighbor cache, and future packets can take the 297 more direct route without disturbing the default router. The 298 Redirect can apply either to a singleton destination address, or to 299 an entire destination prefix as described in 300 [I-D.templin-6man-rio-redirect]. 302 7. ICMPv6 Implications 304 The Internet Control Message Protocol for IPv6 (ICMPv6) includes a 305 set of control message types [RFC4443] including Destination 306 Unreachable (DU). Routers return DU messages with code 0 ("No route 307 to destination") when a packet arrives for which there is no matching 308 entry in the routing table, and with code 3 ("Address unreachable") 309 when the IPv6 destination address cannot be resolved into a link- 310 layer address. Hosts return DU messages with code 3 to internal 311 applications when an address cannot be resolved, and with code 4 312 ("Port unreachable") to the sender if the transport protocol has no 313 listener. 315 A node that obtains a prefix delegation for "tethering" purposes acts 316 like a router in all respects and returns DU messages the same as for 317 any router. 319 A node that obtains a prefix delegation for its own multi-addressing 320 purposes (whether weak or strong end system) should act like a host 321 and refrain from sending DU messages with code 0 or 3 when it 322 receives a packet from a sender with an unknown IPv6 destination 323 address. That is to say that the node should silently drop any IPv6 324 packets with a destination address that matches the delegated prefix 325 but does not match any of its configured addresses. 327 8. IANA Considerations 329 This document introduces no IANA considerations. 331 9. Security Considerations 333 Security considerations are the same as specified for DHCPv6 Prefix 334 Delegation in [RFC3633] and for IPv6 Neighbor Discovery in[RFC4861]. 336 10. Acknowledgements 338 This work was motivated by recent discussions on the v6ops list. 339 Mark Smith pointed out the need to consider MLD as well as DAD for 340 the assignment of addresses to interfaces. Ricardo Pelaez-Negro, 341 Edwin Cordeiro, Fred Baker and Naveen Lakshman provided useful 342 comments that have greatly improved the draft. 344 11. References 346 11.1. Normative References 348 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 349 DOI 10.17487/RFC0791, September 1981, 350 . 352 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 353 Communication Layers", STD 3, RFC 1122, 354 DOI 10.17487/RFC1122, October 1989, 355 . 357 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 358 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 359 December 1998, . 361 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 362 C., and M. Carney, "Dynamic Host Configuration Protocol 363 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 364 2003, . 366 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 367 Host Configuration Protocol (DHCP) version 6", RFC 3633, 368 DOI 10.17487/RFC3633, December 2003, 369 . 371 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 372 Control Message Protocol (ICMPv6) for the Internet 373 Protocol Version 6 (IPv6) Specification", STD 89, 374 RFC 4443, DOI 10.17487/RFC4443, March 2006, 375 . 377 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 378 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 379 DOI 10.17487/RFC4861, September 2007, 380 . 382 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 383 Address Autoconfiguration", RFC 4862, 384 DOI 10.17487/RFC4862, September 2007, 385 . 387 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 388 Requirements for IPv6 Customer Edge Routers", RFC 7084, 389 DOI 10.17487/RFC7084, November 2013, 390 . 392 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 393 /64 Prefix from a Third Generation Partnership Project 394 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 395 DOI 10.17487/RFC7278, June 2014, 396 . 398 11.2. Informative References 400 [I-D.templin-6man-rio-redirect] 401 Templin, F. and j. woodyatt, "Route Information Options in 402 IPv6 Neighbor Discovery", draft-templin-6man-rio- 403 redirect-04 (work in progress), August 2017. 405 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 406 "Host Address Availability Recommendations", BCP 204, 407 RFC 7934, DOI 10.17487/RFC7934, July 2016, 408 . 410 Author's Address 412 Fred L. Templin (editor) 413 Boeing Research & Technology 414 P.O. Box 3707 415 Seattle, WA 98124 416 USA 418 Email: fltemplin@acm.org