idnits 2.17.1 draft-templin-v6ops-pdhost-12.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 29, 2017) is 2399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 404, 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 (-08) exists of draft-templin-6man-rio-redirect-04 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 September 29, 2017 5 Expires: April 2, 2018 7 IPv6 Prefix Delegation for Hosts 8 draft-templin-v6ops-pdhost-12.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 the case when the requesting router is a node 15 that acts as a host on behalf of its local applications and as a 16 router on behalf of any downstream networks. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 2, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Multi-Addressing Considerations . . . . . . . . . . . . . . . 6 55 4. Multi-Addressing Alternatives for Delegated Prefixes . . . . 6 56 5. MLD/DAD Implications . . . . . . . . . . . . . . . . . . . . 7 57 6. Dynamic Routing Protocol Implications . . . . . . . . . . . . 7 58 7. IPv6 Neighbor Discovery Implications . . . . . . . . . . . . 7 59 8. ICMPv6 Implications . . . . . . . . . . . . . . . . . . . . . 8 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 12.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 IPv6 Prefix Delegation (PD) entails 1) the communication of a prefix 71 from a delegating router to a requesting router, 2) a representation 72 of the prefix in the delegating router's routing table, and 3) a 73 control messaging service between the delegating and requesting 74 routers to maintain prefix lifetimes. Following delegation, the 75 prefix is available for the requesting router's exclusive use and is 76 not shared with any other nodes. An example IPv6 PD service is the 77 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 78 [RFC3315][RFC3633]. An alternative prefix management service based 79 solely on IPv6 Neighbor Discovery (ND) messaging has also been 80 proposed [I-D.pioxfolks-6man-pio-exclusive-bit]. 82 This document considers the case when the requesting router is a node 83 that acts as a host on behalf of its local applications and as a 84 router on behalf of any downstream networks. The following 85 paragraphs present possibilities for node behavior upon receipt of a 86 delegated prefix. 88 For nodes that connect downstream-attached (aka "tethered") networks, 89 a Delegating Router 'D' delegates a prefix 'P' to a Requesting node 90 'R' as shown in Figure 1: 92 +---------------------+ 93 |Delegating Router 'D'| 94 | (Delegate 'P') | 95 +----------+----------+ 96 | 97 | Upstream link 98 | 99 +----------+----------+ 100 | Upstream Interface | 101 +---------------------+ 102 | | 103 | Requesting node 'R' | 104 | (Receive 'P') | 105 | | 106 +--+-+--+-+--+-----+--+ 107 |A1| |A2| |A3| ... |An| 108 +--+-+--+-+--+-----+--+ 109 | Downstream Interface| 110 +----------+----------+ 111 | 112 | Downstream link 113 | 114 X----+-------------+--------+----+---------------+---X 115 | | | | 116 +---++-+--+ +---++-+--+ +---++-+--+ +---++-+--+ 117 | |X1| | | |X2| | | |X3| | | |Xn| | 118 | +--+ | | +--+ | | +--+ | | +--+ | 119 | Host H1 | | Host H2 | | Host H3 | ... | Host Hn | 120 +---------+ +---------+ +---------+ +---------+ 122 <-------------- Tethered Network -------------> 124 Figure 1: Classic Routing Model 126 In this figure, when Delegating Router 'D' delegates prefix 'P', it 127 inserts 'P' into its routing table with Requesting node 'R' as the 128 next hop. Meanwhile, 'R' receives 'P' via an upstream interface and 129 sub-delegates 'P' to its downstream external (physical) and/or 130 internal (virtual) networks. 'R' assigns addresses 'A(i)' taken from 131 'P' to downstream interfaces, and Hosts 'H(i)' on downstream networks 132 assign addresses 'X(i)' taken from 'P' to their interface attachments 133 to the downstream link. 'R' then acts as a router between hosts 134 'H(i)' on downstream networks and correspondents reachable via other 135 interfaces. 'R' can also act as a host on behalf of its local 136 applications. 138 This document also considers the case when 'R' does not have any 139 downstream interfaces, and can use 'P' solely for its own internal 140 addressing purposes. In that case, 'R' assigns 'P' to a virtual 141 interface (e.g., a loopback) that fills the role of a downstream 142 interface. 144 'R' can then function under the weak end system (aka "weak host") 145 model [RFC1122][RFC8028] by assigning addresses taken from 'P' to a 146 virtual interface as shown in Figure 2: 148 +---------------------+ 149 |Delegating Router 'D'| 150 | (Delegate 'P') | 151 +----------+----------+ 152 | 153 | Upstream link 154 | 155 +----------+----------+ 156 | Upstream Interface | 157 +---------------------+ 158 | | 159 | Requesting node 'R' | 160 | (Receive 'P') | 161 | | 162 +--+-+--+-+--+-----+--+ 163 |A1| |A2| |A3| ... |An| 164 +--+-+--+-+--+-----+--+ 165 | Virtual Interface | 166 +---------------------+ 168 Figure 2: Weak End System Model 170 'R' could instead function under the strong end system (aka "strong 171 host") model [RFC1122][RFC8028] by assigning IPv6 addresses taken 172 from 'P' to an upstream interface as shown in Figure 3: 174 +---------------------+ 175 |Delegating Router 'D'| 176 | (Delegate 'P') | 177 +----------+----------+ 178 | 179 | Upstream link 180 | 181 +----------+----------+ 182 | Upstream Interface | 183 +--+-+--+-+--+-----+--+ 184 |A1| |A2| |A3| ... |An| 185 +--+-+--+-+--+-----+--+ 186 | | 187 | Requesting node 'R' | 188 | (Receive 'P') | 189 | | 190 +---------------------+ 191 | Virtual Interface | 192 +---------------------+ 194 Figure 3: Strong End System Model 196 The major benefit for a node managing a delegated prefix in either 197 the weak or strong end system models is multi-addressing. With 198 multi-addressing, the node can configure an unlimited supply of 199 addresses to make them available for local applications without 200 requiring coordination with other nodes on upstream interfaces. 202 The following sections present considerations for nodes that employ 203 prefix delegation mechanisms. 205 2. Terminology 207 The terminology of the normative references apply, and the terms 208 "node", "host" and "router" are the same as defined in [RFC8200]. 210 The following terms are defined for the purposes of this document: 212 shared prefix 213 an IPv6 prefix that may be advertised to more than one node on the 214 link, e.g., in a Router Advertisement (RA) message Prefix 215 Information Option (PIO) [RFC4861]. 217 individual prefix 218 an IPv6 prefix that is advertised to exactly one node on the link, 219 where the node may be unaware that the prefix is individual and 220 may not participate in prefix maintenance procedures. 222 delegated prefix 223 an IPv6 prefix that is explicitly delegated to a node for its own 224 exclusive use, where the node is an active participant in prefix 225 delegation and maintenance procedures. 227 3. Multi-Addressing Considerations 229 IPv6 allows nodes to assign multiple addresses to a single interface. 230 [RFC7934] discusses options for multi-addressing as well as use cases 231 where multi-addressing may be desirable. Address configuration 232 options for multi-addressing include StateLess Address 233 AutoConfiguration (SLAAC) [RFC4862], DHCPv6 address configuration 234 [RFC3315], manual configuration, etc. 236 Nodes configure addresses from a shared or individual prefix and 237 assign them to the upstream interface over which the prefix was 238 received. When the node assigns the addresses, it is required to use 239 Multicast Listener Discovery (MLD) [RFC3810] to join the appropriate 240 solicited-node multicast group(s) and to use the Duplicate Address 241 Detection (DAD) algorithm [RFC4862] to ensure that no other node 242 configures a duplicate address. 244 In contrast, a node that configures addresses from a delegated prefix 245 can assign them without invoking MLD/DAD on an upstream interface, 246 since the prefix has been delegated to the node for its own exclusive 247 use and is not shared with any other nodes. 249 4. Multi-Addressing Alternatives for Delegated Prefixes 251 When a node receives a prefix delegation, it has many alternatives 252 for provisioning the prefix. [RFC7278] discusses alternatives for 253 provisioning a prefix obtained by a User Equipment (UE) device under 254 the 3rd Generation Partnership Program (3GPP) service model. This 255 document considers the more general case when the node receives a 256 delegated prefix explicitly provided for its own exclusive use. 258 When the node receives the prefix, it can distribute the prefix to 259 downstream networks and configure one or more addresses for itself on 260 downstream interfaces. The node then acts as a router on behalf of 261 its downstream networks and configures a default route via a neighbor 262 on an upstream interface. 264 The node could instead (or in addition) use portions of the delegated 265 prefix for its own multi-addressing purposes. In a first 266 alternative, the node can assign as many addresses as it wants from 267 the prefix to virtual interfaces. In that case, applications running 268 on the node can use the addresses according to the weak end system 269 model. 271 In a second alternative, the node can assign as many addresses as it 272 wants from the prefix to the upstream interface over which the prefix 273 was received. In that case, applications running on the node can use 274 the addresses according to the strong end system model. 276 In both of these latter two cases, the node assigns the prefix itself 277 to a virtual interface so that unused addresses from the prefix are 278 correctly identified as unreachable. The node then acts as a host on 279 behalf of its local applications even though neighbors on the 280 upstream link see it as a router. 282 5. MLD/DAD Implications 284 When a node configures addresses for itself from a shared or 285 individual prefix, it performs MLD/DAD by sending multicast messages 286 over upstream interfaces to test whether there is another node on the 287 link that configures a duplicate address. When there are many such 288 addresses and/or many such nodes, this could result in substantial 289 multicast traffic that affects all nodes on the link. 291 When a node configures addresses for itself from a delegated prefix, 292 it can configure as many addresses as it wants but does not perform 293 MLD/DAD for any of the addresses over upstream interfaces. This 294 means that the node can configure arbitrarily many addresses without 295 causing any multicast messaging over the upstream interface that 296 could disturb other nodes. 298 6. Dynamic Routing Protocol Implications 300 The node can be configured to either participate or not participate 301 in a dynamic routing protocol over the upstream interface, according 302 to the deployment model. When there are many nodes on the upstream 303 link, dynamic routing protocol participation might be impractical due 304 to scaling limitations, and may also be exacerbated by factors such 305 as node mobility. 307 Unless it participates in a dynamic routing protocol, the node 308 initially has only a default route pointing to a neighbor via an 309 upstream interface. This means that packets sent by the node over an 310 upstream interface will initially go through a default router even if 311 there is a better first-hop node on the link. 313 7. IPv6 Neighbor Discovery Implications 315 The node acts as a simple host to send Router Solicitation (RS) 316 messages over upstream interfaces (i.e., the same as described in 317 Section 4.2 of [RFC7084]) but also sets the "Router" flag to TRUE in 318 its Neighbor Advertisement messages. The node considers the upstream 319 interfaces as non-advertising interfaces [RFC4861], i.e., it does not 320 send RA messages over the upstream interfaces. 322 The current first-hop router may send a Redirect message that updates 323 the node's neighbor cache so that future packets can use a better 324 first-hop node on the link. The Redirect can apply either to a 325 singleton destination address, or to an entire destination prefix as 326 described in [I-D.templin-6man-rio-redirect]. 328 8. ICMPv6 Implications 330 The Internet Control Message Protocol for IPv6 (ICMPv6) includes a 331 set of control message types [RFC4443] including Destination 332 Unreachable (DU). 334 According to [RFC4443], routers should return DU messages (subject to 335 rate limiting) with code 0 ("No route to destination") when a packet 336 arrives for which there is no matching entry in the routing table, 337 and with code 3 ("Address unreachable") when the IPv6 destination 338 address cannot be resolved. 340 According to [RFC4443], hosts should return DU messages (subject to 341 rate limiting) with code 3 to internal applications when the IPv6 342 destination address cannot be resolved, and with code 4 ("Port 343 unreachable") if the IPv6 destination address is one of its own 344 addresses but the transport protocol has no listener. 346 Nodes that obtain and manage prefix delegations per this document 347 observe the same procedures as described for both routers and hosts 348 above. 350 9. IANA Considerations 352 This document introduces no IANA considerations. 354 10. Security Considerations 356 Security considerations for IPv6 Neighbor Discovery [RFC4861] and any 357 applicable prefix delegation mechanisms apply to this document. 359 Additionally, the node may receive unwanted IPv6 packets via an 360 upstream interface that match a delegated prefix but do not match 361 either a configured IPv6 address or a transport listener. In that 362 case, the node drops the packets and observes the "Destination 363 Unreachable - Address/Port unreachable" procedures discussed in 364 Section 8. 366 The node may also receive IPv6 packets via an upstream interface that 367 do not match any of the node's delegated prefixes. In that case, the 368 node drops the packets and observes the "Destination Unreachable - No 369 route to destination" procedures discussed in Section 8. Dropping 370 the packets is necessary to avoid a reflection attack that would 371 cause the node to forward packets received from an upstream interface 372 via the same or a different upstream interface. 374 In all cases, the node must decide whether or not to send DUs 375 according to the specific operational scenario. In trusted networks, 376 the node should send DU messages to provide useful information to 377 potential correspondents. In untrusted networks, the node may 378 refrain from sending DU messages to avoid providing sensitive 379 information to potential attackers. 381 11. Acknowledgements 383 This work was motivated by discussions on the v6ops list. Mark Smith 384 pointed out the need to consider MLD as well as DAD for the 385 assignment of addresses to interfaces. Ricardo Pelaez-Negro, Edwin 386 Cordeiro, Fred Baker, Naveen Lakshman, Ole Troan, Bob Hinden, Brian 387 Carpenter, Joel Halpern and Albert Manfredi provided useful comments 388 that have greatly improved the document. 390 This work is aligned with the NASA Safe Autonomous Systems Operation 391 (SASO) program under NASA contract number NNA16BD84C. 393 This work is aligned with the FAA as per the SE2025 contract number 394 DTFAWA-15-D-00030. 396 This work is aligned with the Boeing Information Technology (BIT) 397 MobileNet program and the Boeing Research & Technology (BR&T) 398 enterprise autonomy program. 400 12. References 402 12.1. Normative References 404 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 405 DOI 10.17487/RFC0791, September 1981, 406 . 408 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 409 C., and M. Carney, "Dynamic Host Configuration Protocol 410 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 411 2003, . 413 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 414 Host Configuration Protocol (DHCP) version 6", RFC 3633, 415 DOI 10.17487/RFC3633, December 2003, 416 . 418 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 419 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 420 DOI 10.17487/RFC3810, June 2004, 421 . 423 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 424 Control Message Protocol (ICMPv6) for the Internet 425 Protocol Version 6 (IPv6) Specification", STD 89, 426 RFC 4443, DOI 10.17487/RFC4443, March 2006, 427 . 429 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 430 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 431 DOI 10.17487/RFC4861, September 2007, 432 . 434 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 435 Address Autoconfiguration", RFC 4862, 436 DOI 10.17487/RFC4862, September 2007, 437 . 439 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 440 (IPv6) Specification", STD 86, RFC 8200, 441 DOI 10.17487/RFC8200, July 2017, 442 . 444 12.2. Informative References 446 [I-D.pioxfolks-6man-pio-exclusive-bit] 447 Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement 448 Prefix Information Option eXclusive Flag", draft- 449 pioxfolks-6man-pio-exclusive-bit-02 (work in progress), 450 March 2017. 452 [I-D.templin-6man-rio-redirect] 453 Templin, F. and j. woodyatt, "Route Information Options in 454 IPv6 Neighbor Discovery", draft-templin-6man-rio- 455 redirect-04 (work in progress), August 2017. 457 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 458 Communication Layers", STD 3, RFC 1122, 459 DOI 10.17487/RFC1122, October 1989, 460 . 462 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 463 Requirements for IPv6 Customer Edge Routers", RFC 7084, 464 DOI 10.17487/RFC7084, November 2013, 465 . 467 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 468 /64 Prefix from a Third Generation Partnership Project 469 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 470 DOI 10.17487/RFC7278, June 2014, 471 . 473 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 474 "Host Address Availability Recommendations", BCP 204, 475 RFC 7934, DOI 10.17487/RFC7934, July 2016, 476 . 478 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 479 Hosts in a Multi-Prefix Network", RFC 8028, 480 DOI 10.17487/RFC8028, November 2016, 481 . 483 Author's Address 485 Fred L. Templin (editor) 486 Boeing Research & Technology 487 P.O. Box 3707 488 Seattle, WA 98124 489 USA 491 Email: fltemplin@acm.org