idnits 2.17.00 (12 Aug 2021) /tmp/idnits26115/draft-lemon-stub-networks-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 163: '...se, the stub router SHOULD NOT provide...' RFC 2119 keyword, line 193: '...y, the stub router MUST monitor router...' RFC 2119 keyword, line 200: '... The stub router MUST listen for route...' RFC 2119 keyword, line 203: '...TIME seconds old MUST be assumed to no...' RFC 2119 keyword, line 208: '... The stub router MUST listen for route...' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 128 has weird spacing: '...network the n...' == Line 134 has weird spacing: '...re link any l...' == Line 147 has weird spacing: '... Prefix a pre...' -- The document date (25 April 2022) is 19 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6092 ** Downref: Normative reference to an Informational RFC: RFC 7084 == Outdated reference: A later version (-13) exists of draft-ietf-dnssd-srp-12 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Lemon 3 Internet-Draft Apple Inc. 4 Intended status: Best Current Practice 25 April 2022 5 Expires: 27 October 2022 7 Connecting Stub Networks to Existing Infrastructure 8 draft-lemon-stub-networks-03 10 Abstract 12 This document describes a set of practices for connecting stub 13 networks to adjacent infrastructure networks, as well as to larger 14 network fabrics. This is applicable in cases such as constrained 15 (Internet of Things) networks where there is a need to provide 16 functional parity of service discovery and reachability between 17 devices on the stub network and devices on an adjacent infrastructure 18 link (for example, a home network). 20 The stub networks use case is intended to fully address the need to 21 attach a single network link to an infrastructure network, where the 22 attached link provides no through routing and in cases where 23 integration to the infrastructure routing fabric (if any) is not 24 available. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 27 October 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Support for adjacent infrastructure links . . . . . . . . . . 4 62 3.1. Managing addressability on the adjacent infrastructure 63 link . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.1. IP addressability already present on adjacent 65 infrastructure link . . . . . . . . . . . . . . . . . 4 66 3.1.2. IP addressability not present on adjacent 67 infrastructure link . . . . . . . . . . . . . . . . . 6 68 3.1.3. Resolving contention over which prefix to 69 deprecate . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.4. Handling the presence of multiple stub routers . . . 7 71 3.2. Managing addressability on the stub network . . . . . . . 7 72 3.2.1. Maintenance across stub router restarts . . . . . . . 8 73 3.2.2. Generating a ULA prefix to provide addressability . . 9 74 3.3. Managing reachability on the adjacent infrastructure 75 link . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.4. Managing reachability on the stub network . . . . . . . . 9 77 3.5. Providing discoverability of stub network hosts on the 78 adjacent infrastructure link . . . . . . . . . . . . . . 10 79 3.6. Providing discoverability of adjacent infrastructure hosts 80 on the stub network . . . . . . . . . . . . . . . . . . . 12 81 4. Providing reachability to IPv4 services to the stub 82 network . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.1. NAT64 provided by infrastructure . . . . . . . . . . . . 12 84 4.2. NAT64 provided by stub router(s) . . . . . . . . . . . . 13 85 5. Handling partitioning events on a stub network . . . . . . . 14 86 6. Support for non-adjacent links . . . . . . . . . . . . . . . 14 87 6.1. Acquiring an off-stub-network-routable prefix for the stub 88 network . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.2. Arranging for routing to a stub network's off-stub-network 90 routable prefix . . . . . . . . . . . . . . . . . . . . . 16 91 6.3. Making service advertisements available on non-adjacent 92 infrastructure . . . . . . . . . . . . . . . . . . . . . 16 93 6.4. Making service advertisements available on the 94 internet . . . . . . . . . . . . . . . . . . . . . . . . 16 96 6.5. Distinction between non-adjacent infrastructure and global 97 internet connectivity . . . . . . . . . . . . . . . . . . 17 98 7. Normative References . . . . . . . . . . . . . . . . . . . . 17 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 This document describes a set of practices for connecting stub 104 networks to adjacent infrastructure networks, as well as to larger 105 network fabrics. This is applicable in cases such as constrained 106 (Internet of Things) networks where there is a need to provide 107 functional parity of service discovery and reachability between 108 devices on the stub network and devices on an adjacent infrastructure 109 link (for example, a home network). 111 The stub networks use case is intended to fully address the need to 112 attach a single network link to an infrastructure network, where the 113 attached link provides no through routing and in cases where 114 integration to the infrastructure routing fabric (if any) is not 115 available. 117 2. Glossary 119 Addressability The ability to associate each node on a link with its 120 own IPv6 address. 122 Reachability Given an IPv6 destination address that is not on-link 123 for any link to which a node is attached, the information required 124 that allows the node to send packets to a router that can forward 125 those packets towards a link where the destination address is on- 126 link. 128 Infrastructure network the network infrastructure to which a stub 129 router connects. This network can be a single link, or a network 130 of links. The network may also provide some services, such as a 131 DNS resolver, a DHCPv4 server, and a DHCPv6 prefix delegation 132 server, for example. 134 Infrastructure link any link in a network infrastructure that is 135 managed by a single entity. 137 Adjacent infrastructure link (AIL) an infrastructure link to which a 138 stub router is directly connected. 140 Non-adjacent infrastructure link (NAIL) an infrastructure link to 141 which a stub router is not directly connected. 143 Non-adjacent link (NAL) any link to which the stub router is not 144 directly connected, whether within an infrastructure or elsewhere 145 on the Internet. 147 Off-Stub-Network-Routable (OSNR) Prefix a prefix advertised on the 148 stub network that can be used for communication with hosts not on 149 the stub network. 151 3. Support for adjacent infrastructure links 153 We assume that adjacent infrastructure link supports Router and 154 Prefix Discovery using router advertisements. Adjacent 155 infrastructure links on networks where this is not supported are out 156 of scope for this document. 158 3.1. Managing addressability on the adjacent infrastructure link 160 In order to provide IPv6 routing to the stub network, IPv6 addressing 161 must be available on the adjacent infrastructure link. In the ideal 162 case, such addressing is already present on the link, and need not be 163 provided. In this case, the stub router SHOULD NOT provide 164 addressability on the adjacent infrastructure link. 166 3.1.1. IP addressability already present on adjacent infrastructure 167 link 169 IPv6 addressing is considered to be present on the link if a usable 170 on-link prefix is advertised on the adjacent infrastructure link. A 171 usable on-link prefix could be a prefix advertised on the link that 172 is on-link and allows autonomous configuration. A prefix is also a 173 usable on-link prefix if it is advertised on the link as on-link, and 174 if the 'm' bit is set in the Router Advertisement message header 175 ([RFC4861], Section 4.2) that contains the Prefix option. This 176 indicates that node addressibility is being managed using DHCPv6. 178 A prefix is advertised on the link if, when a Router Solicit message 179 ([RFC4861], Section 4.1) is sent, a Router Advertisement message is 180 received in response which contains a prefix information option 181 ([RFC4861], Section 4.6.2) for that prefix. 183 After such an RA message has been received, it can be assumed for 184 some period of time thereafter that the prefix is still valid on the 185 link. However, prefix lifetimes and router lifetimes are often quite 186 long. The mere fact that a prefix that has been advertised is still 187 within its valid lifetime does not mean that that prefix is still 188 being advertised on the link. 190 This is important because when a new host appears on the adjacent 191 infrastructure link and sends an initial router solicit, if it does 192 not receive a usable on-link prefix, it will not be able to 193 communicate. Consequently, the stub router MUST monitor router 194 solicits and advertisements on the link in order to determine whether 195 a prefix that has been advertised on the link is still being 196 advertised. 198 There are several methods that can be used to accomplish this: 200 The stub router MUST listen for router advertisements on the adjacent 201 infrastructure link, and record the time at which each router 202 advertisement was received. A router advertisement that is more than 203 STALE_RA_TIME seconds old MUST be assumed to no longer be advertised 204 on the link. When the last non-stale router advertisement containing 205 a usable prefixes on the link is marked stale, the stub router should 206 begin Router Discovery ([RFC4861], Section 6.3). 208 The stub router MUST listen for router solicits on the adjacent 209 infrastructure link. When a router solicit is received, the router 210 SHOULD set a timer for VICARIOUS_SOLICIT_TIME seconds. If, after 211 that amount of time, no router advertisements are received that 212 contain a usable on-link prefix, the stub router MUST begin router 213 discovery. This is necessary in case the response to the router 214 solicit was unicast, since in this case the stub router would not see 215 that response. When the stub router first connects to the adjacent 216 infrastructure link, it MUST begin router discovery. 218 When router discovery completes, the stub router evaluates whether or 219 not a usable on-link prefix has been seen in a non-stale router 220 advertisement during router discovery. If no usable on-link prefix 221 has been seen, then the stub router MUST begin to provide a usable 222 on-link prefix. 224 As an alternative to the vicarious router discovery process described 225 here, the stub router could monitor the presence of the router 226 advertising the on-link prefix in the neighbor cache. If the 227 neighbor cache entry becomes stale, this could be an indication that 228 the prefix is also stale. If the neighbor cache entry goes stale, 229 the router would need to try to refresh it, and if that fails, then 230 the stub router must begin advertising its own on-link prefix on the 231 stub network. 233 3.1.2. IP addressability not present on adjacent infrastructure link 235 When there is no usable on-link prefix on the adjacent infrastructure 236 network, the stub router provides its own on-link prefix. This 237 prefix has a valid and preferred lifetime of 238 STUB_PROVIDED_PREFIX_LIFETIME seconds. This prefix MUST allow for 239 autonomous configuration (SLAAC). 241 The stub router must advertise this prefix every BEACON_INTERVAL 242 seconds. When the stub router is advertising reachability to the 243 stub network, the on-link prefix advertisement and the route 244 information advertisement must be contained in the same router 245 advertisement. 247 When the stub router is advertising an on-link prefix on the AIL, it 248 may receive a router advertisement containing a usable on-link prefix 249 for the AIL with a non-zero preferred lifetime. In this case, the 250 stub router should begin to deprecate the on-link prefix it is 251 advertising on the AIL. The preferred lifetime for this prefix 252 should be set to zero in subsequent advertisements. 254 The valid lifetime (VALID) is computed based on three values: the 255 current time when a router advertisement is being generated (NOW), 256 the time at which the new usable on-link prefix advertisement was 257 received (DEPRECATE_TIME), and STUB_PROVIDED_PREFIX_LIFETIME. All of 258 these values are in seconds. VALID is computed as follows: 260 VALID = STUB_PROVIDED_PREFIX_LIFETIME - (NOW - DEPRECATE_TIME) 262 If VALID is less than BEACON_INTERVAL, the stub router does not 263 include the deprecated prefix in the router advertisement. Note that 264 VALID could be less than zero. Otherwise, the prefix is provided in 265 the advertisement, but with a valid lifetime of VALID. 267 3.1.3. Resolving contention over which prefix to deprecate 269 It is also possible that all routers on the link that are capable of 270 advertising prefixes might be following the same protocol of 271 deprecating their own prefix when a valid prefix shows up. To 272 prevent a situation where all routers deprecate their prefix and wait 273 until there are no valid prefixes being advertised before advertising 274 a prefix, each stub router must detect the situation where, having 275 deprecated its own prefix, all of the other prefixes being advertised 276 on the link have also been deprecated. 278 When this situation occurs, each router on the link MUST compare the 279 valid lifetimes of all the prefixes that have been seen. If the 280 router's own prefix expires last, then that router should immediately 281 resume publishing its prefix as a preferred prefix. 283 If a router observes this situation and its prefix is not the one 284 that expires last, it MUST set a timer for UNDEPRECATE_WAIT seconds, 285 while continuing to observe prefix advertisements on the link. If, 286 when the timer expires, the prefix that expires last has not been re- 287 published as a preferred prefix, then that prefix is marked as 288 'really deprecated', and no longer considered a candidate for de- 289 deprecation. 291 Using the remaining list of prefixes, the router should then apply 292 the same algorithm. It should continue to apply this algorithm until 293 either its prefix becomes the one to re-publish as preferred, or some 294 other router has re-published its prefix as preferred. 296 3.1.4. Handling the presence of multiple stub routers 298 When multiple stub routers are connected to the same AIL, and no 299 usable on-link prefix is being provided on that link by the 300 infrastructure, there will be a competition between routers to 301 provide a usable on-link prefix. In order to avoid duplication, stub 302 routers MUST include a random offset in the time interval across 303 which router discovery is performed. This ensures that after a power 304 failure, not all stub routers will exit router discovery at the exact 305 same time, and so one stub router should advertise a usable on-link 306 prefix before the others. This should prevent the other stub routers 307 from advertising additional on-link prefixes. 309 There is no particular harm caused by advertising multiple on-link 310 prefixes, but it is preferable to minimize this, because each on-link 311 prefix consumes space in every on-link host's routing table, and 312 consumes time when making source address selection and routing 313 decisions. 315 3.2. Managing addressability on the stub network 317 How addressability is managed on stub networks depends on the nature 318 of the stub network. For some stub networks, the stub router can be 319 sure that it is the only router. For example, a stub router that is 320 providing a Wi-Fi network for tethering will advertise its own SSID 321 and use its own joining credentials; in this case, it can assume that 322 it is the only router for that network, and advertise a default route 323 and on-link prefix just like any other router. 325 However, some stub networks are more cooperative in nature, for 326 example IP mesh networks. On such networks, multiple stub routers 327 may be present and be providing addressability and reachability. 329 In either case, some stub router connected to the stub network MUST 330 provide a usable on-link prefix (the OSNR prefix) for the stub 331 network. If the stub network is a multicast-capable medium where 332 Router Advertisements are used for router discovery, the same 333 mechanism described in section [Support for adjacent infrastructure 334 links] is used. 336 Stub networks that do not support the use of Router Advertisements 337 for router discovery must use some similar mechanism that is 338 compatible with that type of network. Describing the process of 339 establishing a common OSNR prefix on such networks is out of scope 340 for this document. 342 3.2.1. Maintenance across stub router restarts 344 Stub routers may restart from time to time; when a restart occurs, 345 the stub router may have been advertising state to the network which, 346 following the restart, is no longer required. 348 For example, suppose there are two stub routers connected to the same 349 infrastructure link. When the first stub router is restarted, the 350 second takes over providing an on-link prefix. Now the first router 351 rejoins the link. It sees that the second stub router's prefix is 352 advertised on the infrastructure link, and therefore does not 353 advertise its own. 355 This behavior can cause problems because the first stub router no 356 longer sees the on-link prefix it had been advertising on 357 infrastructure as on-link. Consequently, if it receives a packet to 358 forward to such an address, it will forward that packet directly to a 359 default router, if one is present; otherwise, it will have no route 360 to the destination, and will drop the packet. 362 To address this problem, stub routers SHOULD remember the last time a 363 prefix was advertised across restarts. On restart, the router can 364 immediately begin deprecating the prefix, and can stop after the 365 prefix valid lifetime goes to zero, based on the recorded time that 366 the last advertisement was sent. 368 When a stub router has only flash memory with limited write lifetime, 369 it may be inappropriate to do a write to flash every time a prefix 370 beacon happens. In this case, the router SHOULD record the set of 371 prefixes that have been advertised on infrastructure and the maximum 372 valid lifetime that was advertised. On restart, the router should 373 assume that hosts on the infrastructure link have received 374 advertisements for any such prefixes, and should immediately 375 deprecate them, and continue to do so until the maximum valid 376 lifetime has elapsed after restart. 378 3.2.2. Generating a ULA prefix to provide addressability 380 In order to be able to provide addressability either on the stub 381 network or on an adjacent infrastructure network, a stub router must 382 allocate its own ULA prefix. ULA prefixes, described in Unique Local 383 IPv6 Unicast Addresses ([RFC4193]) are randomly allocated prefixes. 384 A stub router MUST allocate a single ULA prefix for use in providing 385 on-link prefixes to the stub network and the infrastructure network, 386 as needed. 388 The ULA prefix allocated by a stub router SHOULD be maintained across 389 reboots, and SHOULD remain stable over time. For privacy reasons, a 390 stub router that roams from network to network may wish to allocate a 391 different ULA prefix each time it connects to a different 392 infrastructure network. 394 If IPv6 prefix delegation is available, which implies that IPv6 395 service is also available on the infrastructure link, then the stub 396 router MAY use IPv6 prefix delegation to acquire a prefix to 397 advertise on the stub network, rather than allocating one out of its 398 ULA prefix. 400 3.3. Managing reachability on the adjacent infrastructure link 402 Stub routers MUST advertise reachability to stub network OSNR 403 prefixes on any AIL to which they are connected. 405 Each stub network will have some set of prefixes that are advertised 406 as on-link for that network. A stub router connected to that network 407 SHOULD advertise reachability to all such prefixes on any AIL to 408 which it is attached using router advertisements 410 3.4. Managing reachability on the stub network 412 The stub router MAY advertise itself as a default router on the stub 413 network, if it itself has a default route on the AIL. In some cases 414 it may not be desirable to advertise reachability to the Internet as 415 a whole; in this case the stub router need not advertise itself as a 416 default router. 418 If the stub router is not advertising itself as a default on the stub 419 network, it MUST advertise reachability to any prefixes that are 420 being advertised as on-link on AILs to which it is attached. This is 421 true for prefixes it is advertising, and for other prefixes being 422 advertised on that link. 424 Note that in some stub network configurations, it is possible for 425 more than one stub router to be connected to the stub network, and 426 each stub router may be connected to a different AIL. In this case, 427 a stub router advertising a default route may receive a packet 428 destined for a link that is not an AIL for that router, but is an AIL 429 for a different router. In such a case, if the infrastructure is not 430 capable of routing between these two AILs, a packet which could have 431 been delivered by another stub router will be lost by the stub router 432 that received it. 434 Consequently, stub routers SHOULD be configurable to not advertise 435 themselves as default routers on the stub network. Stub routers 436 SHOULD be configurable to explicitly advertise AIL prefixes on the 437 stub network even if they are advertising as a default router. Stub 438 routers SHOULD be configurable to advertise NAIL prefixes on the stub 439 network; such configuration would include a list of NAIL prefixes to 440 advertise. This list may be configured in a management interface or 441 as a result of these routes being delivered in a routing protocol or 442 through router discovery. The mechanisms by which such configuration 443 can be accomplished are out of scope for this document. 445 3.5. Providing discoverability of stub network hosts on the adjacent 446 infrastructure link 448 In some cases it will be necessary for hosts on the adjacent 449 infrastructure link to be able to discover devices on the stub 450 network. In other cases, this will be unnecessary or even 451 undesirable. For example, it may be undesirable for devices on an 452 adjacent infrastructure link to be able to discover devices on a Wi- 453 Fi tether, for example provided by a mobile phone. 455 One example of a use case for stub networks where such discovery is 456 desirable is the constrained network use case. In this case a low- 457 power, low-cost stub network provides connectivity for devices that 458 provide services to the infrastructure. For such networks, it is 459 necessary that devices on the infrastructure be able to discover 460 devices on the stub network. 462 The most basic use case for this is to provide feature parity with 463 existing solutions like multicast DNS (mDNS). For example, a light 464 bulb with built-in Wi-Fi connectivity might be discoverable on the 465 infrastructure link to which it is connected, using mDNS, but likely 466 is not discoverable on other links. To provide equivalent 467 functionality for an equivalent device on a constrained network that 468 is a stub network, the stub network device must be discoverable on 469 the infrastructure link (which is an AIL from the perspective of the 470 stub network). 472 If services are to be advertised using DNS Service Discovery 473 [RFC6763], there are in principle two ways to accomplish this. One 474 is to present services on the stub network as a DNS zone which can 475 then be configured as a browsing domain in the DNS ([RFC6763], 476 Section 11). The second is to advertise stub network services on the 477 AIL using multicast DNS (mDNS) [RFC6762]. 479 Stub network routers cannot be assumed to be able to integrate into 480 the DNS naming hierarchy of the infrastructure network. Therefore, 481 stub networks must be able to rely on ad-hoc service advertisement 482 protocols. Since mDNS is in wide use, this is a suitable protocol 483 for this use case. This is not to say that mDNS is the only such 484 protocol that could be used, but it is the one that we suggest 485 implementing. 487 In order to provide mDNS discovery for devices on the stub network, 488 one of two solutions is likely to be applicable, depending on the 489 operational practicalities of the stub network. For a constrained 490 stub network, on which battery operated devices may be attached, mass 491 multicast traffic for service discovery is impractical, since every 492 device needs to wake up for every service discovery, even if they 493 don't offer that service, and since many such devices may be 494 operating on battery power. For such a network, multicast DNS is not 495 a good choice. 497 For such networks, a unicast service registration protocol such as 498 DNS-SD Service Registration Protocol (SRP) [I-D.ietf-dnssd-srp] is a 499 good solution. The stub router can act as an SRP server on the stub 500 network, accepting service advertisements from stub network devices. 501 On the adjacent infrastructure network, it can advertise those 502 services as multicast DNS Advertising Proxy 503 [I-D.sctl-advertising-proxy]. 505 For other stub networks, for example a Wi-Fi-based Personal Area 506 Network provided as part of a tethering function on a mobile device, 507 multicast DNS may be the only option. For Wi-Fi stub networks, there 508 is such a large installed base of devices supporting mDNS that 509 requiring some other service advertisement solution would be 510 problematic simply because it would require new software for that 511 entire installed base. For other networks, particularly constrained 512 networks, where devices do not currently support mDNS, no such 513 obstacle exists. 515 Because the primary use case for discovery of devices on a stub 516 network is the use case where the stub network is joining a 517 constrained network to an existing infrastructure link, we currently 518 only describe a solution (DNS-SD SRP) for that use case. A solution 519 for the use case where the stub router must provide discoverability 520 for a stub network where mDNS advertising is preferred is out of 521 scope for this document. 523 3.6. Providing discoverability of adjacent infrastructure hosts on the 524 stub network 526 Hosts on the stub network may need to discover hosts on the adjacent 527 infrastructure network. In the IoT network example we've been using, 528 there might be a light switch on the stub network which needs to be 529 able to actuate a light bulb connected to the adjacent infrastructure 530 network. In order to know where to send the actuation messages, the 531 light switch will need to be able to discover the light bulb's 532 address somehow. 534 In the case of a Wi-Fi stub network, devices on the stub network will 535 need to be able to access the Internet, and may also need to be able 536 to access local services on the adjacent infrastructure link. 538 In order to address these use cases, the stub network router SHOULD 539 provide a DNS-SD Discovery Proxy [RFC8766] and a DNS resolver. Since 540 these two functions are combined, if the stub router provides them, 541 it MUST offer both services on the standard DNS UDP and TCP ports. 543 4. Providing reachability to IPv4 services to the stub network 545 4.1. NAT64 provided by infrastructure 547 Stub networks are defined to be IPv6-only because it would be 548 difficult to implement a stub network using IPv4 technology. 549 However, stub network devices may need to be able to communicate with 550 IPv4-only services either on the adjacent infrastructure, or on the 551 global internet. Ideally, the infrastructure network fully supports 552 IPv6, and all services on the infrastructure network are 553 IPv6-capable. In this case, perhaps the infrastructure network 554 provides NAT64 service to IPv4-only hosts on the internet. In this 555 ideal setting, the stub router need do nothing-the infrastructure 556 network is doing it all. 558 In this situation, if there are multiple stub routers, each connected 559 to the same adjacent infrastructure link, there is no need for 560 special behavior-each stub router can advertise a default route, and 561 any stub router will do to route NAT64 traffic. If some stub routers 562 are connected to different adjacent infrastructure links than others, 563 some of which support NAT64 and some of which do not, then the 564 default route may not carry traffic to the correct link for NAT64 565 service. In this case, a more specific address to the infrastructure 566 NAT64 prefix(es) MUST be advertised by those stub routers that are 567 able to discover it. 569 4.2. NAT64 provided by stub router(s) 571 Most infrastructure networks at present do not provide NAT64 service. 572 It is therefore necessary for stub routers to be able to provide 573 NAT64 service if IPv4 hosts are to be reachable from the stub 574 network. 576 To provide NAT64 service, a stub router must allocate a NAT64 prefix. 577 For convenience, the stub network allocates a single prefix out of 578 the /48 ULA prefix that it maintains. Out of the 2^16 possible 579 subnets of the /48, the stub router SHOULD use the numerically 580 highest /64 prefix. 582 If there are multiple stub routers providing connectivity between the 583 stub network and infrastructure, each stub network uses its own NAT64 584 prefix-there is no common NAT64 prefix. The reason for this is that 585 NAT64 translation is not stateless, and is tied to the stub router's 586 IPv4 address. Therefore each NAT64 egress is not equivalent. 588 A stub network that services a Wi-Fi stub network SHOULD provide 589 DNS64 translation: hosts on the stub network cannot be assumed to be 590 able to do DNS64 synthesis in the stub resolver. In this case the 591 DNS resolver on the stub router MUST honor the CD and DO bits if 592 received in a request, since this indicates that the stub resolver on 593 the requestor intends to do DNSSEC validation. In this case, the 594 resolver on the stub router MUST NOT perform DNS64 synthesis. 596 On specific stub networks it may be desirable to require the stub 597 network device to perform DNS64 synthesis. Stub network routers for 598 such networks do not need to provide DNS64 synthesis. Instead, they 599 MUST provide an ipv4only.arpa answer that advertises the NAT64 prefix 600 for that stub router, and MUST provide an explicit route to that 601 NAT64 prefix on the stub network using RA or whatever technology is 602 specific to that stub network type. 604 In constrained networks it can be very useful if stub network 605 resolvers provide the information required to do DNS64 translation in 606 the answer to the AAAA query. If the answer to an AAAA query comes 607 back with "no data" (not NXDOMAIN), this suggests that there may be 608 an A record. In this case, the stub network's resolver SHOULD 609 attempt to look up an A record on the same name. If such a record 610 exists, the resolver SHOULD return no data in the Answer section of 611 the DNS response, and SHOULD provide any CNAME records that were 612 involved in returning the "no data" answer to the AAAA query, and 613 SHOULD provide any A records that were ultimately returned, in the 614 Additional section. The resolver should also include an 615 ipv4only.arpa record in the Additional section. 617 5. Handling partitioning events on a stub network 619 If a stub network is constructed using mesh technology, it may become 620 partitioned. In such a situation, it may be one stub router is 621 connected to one partition, and another stub router is connected to 622 the other partition. In this situation, in order for all nodes to be 623 reachable, it is necessary that each partition of the stub network 624 have its own prefix. When such a partition occurs, the stub routers 625 must detect that it has occurred. If a stub router is currently 626 providing a prefix on the stub network, it need take no action. If a 627 stub router had not been providing a prefix on the stub network, and 628 now discovers that there is no stub router providing a prefix on the 629 network, it MUST begin to provide its own prefix on the stub network. 630 It MUST also advertise reachability to that new prefix on its 631 adjacent infrastructure link(s). 633 When partitions of this type occur, they may also heal. When a 634 partition heals in a situation where two stub routers have both been 635 advertising a prefix, it will now appear that there are two prefixes 636 on the stub network. Since partition events may represent a 637 recurring situation, stub routers SHOULD wait for at least 638 PARTITION_HEAL_WAIT_TIME before deprecating one of these prefixes. 640 When the time comes to deprecate one or more prefixes as a result of 641 a network partition healing, only one prefix should remain. If there 642 are any GUA prefixes, and if there is no specific configuration 643 contradicting this, the GUA prefix that is numerically lowest should 644 be kept, and all others deprecated. If there are no GUA prefixes, 645 then the ULA prefix that is numerically lowest should be kept, and 646 the others deprecated. By using this approach, it is not necessary 647 for the routers to coordinate in advance. 649 6. Support for non-adjacent links 651 There are two ways that connectivity to non-adjacent links can be 652 established. The first is that if the infrastructure network as a 653 whole has a working IPv4 routing fabric, NAT64 can be used to enable 654 hosts on the stub network to establish communications with hosts on 655 non-adjacent links, including the Internet. In some cases, this is 656 all that is needed. 658 However, if it will be necessary for nodes on non-adjacent networks 659 to establish communications with nodes on the stub network, this will 660 require a working IPv6 routing fabric connecting the stub network to 661 any non-adjacent links from which communications will need to be 662 established. 664 In order for such routing to work, the stub network will also need to 665 acquire a prefix that the infrastructure network is aware of and can 666 route to. The ULA prefix that can work for communicating to adjacent 667 infrastructure links will not work for communicating to non-adjacent 668 links. 670 6.1. Acquiring an off-stub-network-routable prefix for the stub network 672 A prefix may be acquired by using DHCPv6 Prefix Delegation 673 ([RFC8415], Section 6.3). The stub router then advertises this 674 prefix as the on-link prefix for the stub network, as before. It 675 also advertises reachability to this prefix using router 676 advertisements, as before. 678 In the case where there is more than one stub router, it would be 679 best if only one stub router requested a delegated prefix. This can 680 be managed through the mechanism described earlier: the stub router 681 only acquires a prefix to advertise when it has decided that it needs 682 to advertise a prefix, and so in most cases only one stub router at a 683 time will request a delegated prefix. 685 In order to avoid excessive consumption of delegated prefixes, stub 686 routers connected to stub networks that support multiple stub routers 687 SHOULD request short lifetimes for delegated prefixes and renew 688 frequently. Stub routers SHOULD request a lifetime of 689 PREFIX_DELEGATION_INTERVAL. Stub routers SHOULD record the time that 690 a prefix was acquired in stable storage, and SHOULD release the 691 prefix using a "DHCP Release" transaction when shutting down, or when 692 it determines that a prefix is no longer needed (See "graceful 693 shutdown" in Figure 9 of [RFC8415] for details). Stub routers SHOULD 694 release any remembered still-valid prefix after reboot, if after 695 rebooting it is discovered that another prefix is being advertised on 696 the stub network. 698 6.2. Arranging for routing to a stub network's off-stub-network 699 routable prefix 701 We can assume that a side effect of the prefix delegation process 702 will be to establish routing to the stub router that requested the 703 prefix. This should mean that any node that wishes to establish 704 communication with a node on the stub network will be able to do so 705 through the delegating router that provides the prefix or, if it is 706 attached to an infrastructure link that is adjacent to the stub 707 router, through the stub router itself by means of the router 708 advertisement it is providing. 710 The case of multiple stub routers is more complicated however. Any 711 routing that comes as a side-effect of DHCPv6 Prefix Delegation will 712 only route through the stub router that acquired the prefix. Other 713 stub routers can provide reachability on their respective adjacent 714 infrastructure links, but reachability across the full routing fabric 715 of the infrastructure network will only be possible if there is some 716 routing protocol present on the infrastructure network. Addressing 717 this problem is out of scope for this document. 719 6.3. Making service advertisements available on non-adjacent 720 infrastructure 722 In order for service advertisements to be available on non-adjacent 723 infrastructure, the infrastructure must provide SRP service for 724 constrained stub networks, and must advertise the availability of 725 such service so that stub routers can forward SRP updates to that SRP 726 service, rather than providing SRP as a local service. This SRP 727 service can be discovered using DNS-SD, using the _dnssd-srp-tls 728 service type. If the stub network requires UDP-based SRP rather than 729 tls-based SRP, the stub router MUST act as a proxy to deliver SRP 730 updates over the tcp+tls transport. 732 For stub networks that use multicast DNS, stub routers must provide a 733 discovery proxy service, and most advertise that service to the 734 infrastructure. In turn, the infrastructure must configure that 735 service to be discoverable by devices on the infrastructure, as 736 described in [RFC8766], Section 6. 738 6.4. Making service advertisements available on the internet 740 The mechanism described previously for making service advertisements 741 available to non-adjacent infrastructure also scales to the internet, 742 since it uses DNS. Indeed, the question an operator should ask 743 before enabling such discovery is, do they want their stub network 744 devices to be discoverable on the internet. If it becomes possible 745 to configure service advertising automatically, behavior similar to 746 that specified in [RFC6092], Section 3.2 and 3.3, would be advised: 747 do not automatically advertise stub network devices on the Internet. 749 6.5. Distinction between non-adjacent infrastructure and global 750 internet connectivity 752 Stub routers may be mobile, or fixed. That is, they may move from 753 location to location along with some or all of their connected 754 devices, attaching to whatever infrastructure is available. Or they 755 may be fixed devices that are only ever expected to exist in one 756 particular location. 758 For devices that are intended to be in a fixed location, the 759 distinction between infrastructure links and the internet as a whole 760 is meaningful; for mobile nodes it most likely is not, unless such a 761 node is only going to ever attach to trusted infrastructure as it 762 moves from location to location-not a common scenario. 764 For fixed links, the infrastructure may be trusted, in which case the 765 distinction between infrastructure and internet can be expected to be 766 managed by the infrastructure, and therefore only visible to the stub 767 router in the sense that some non-adjacent destinations may be 768 reachable (infrastructure destinations, for example) while others are 769 not. 771 The reason for mentioning this here is to point out that the stub 772 router can't be expected to manage this interface: it is up to the 773 infrastructure network to do so, either implicitly or explicitly. 774 [RFC7084] provides a set of default behaviors for home routers that 775 may be adequate for automatically managing this interface, but 776 further work in this area may be warranted. 778 7. Normative References 780 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 781 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 782 DOI 10.17487/RFC4861, September 2007, 783 . 785 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 786 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 787 . 789 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 790 Capabilities in Customer Premises Equipment (CPE) for 791 Providing Residential IPv6 Internet Service", RFC 6092, 792 DOI 10.17487/RFC6092, January 2011, 793 . 795 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 796 DOI 10.17487/RFC6762, February 2013, 797 . 799 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 800 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 801 . 803 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 804 Requirements for IPv6 Customer Edge Routers", RFC 7084, 805 DOI 10.17487/RFC7084, November 2013, 806 . 808 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 809 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 810 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 811 RFC 8415, DOI 10.17487/RFC8415, November 2018, 812 . 814 [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 815 Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 816 2020, . 818 [I-D.ietf-dnssd-srp] 819 Lemon, T. and S. Cheshire, "Service Registration Protocol 820 for DNS-Based Service Discovery", Work in Progress, 821 Internet-Draft, draft-ietf-dnssd-srp-12, 24 October 2021, 822 . 825 [I-D.sctl-advertising-proxy] 826 Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD 827 Service Registration Protocol", Work in Progress, 828 Internet-Draft, draft-sctl-advertising-proxy-02, 12 July 829 2021, . 832 Author's Address 834 Ted Lemon 835 Apple Inc. 836 One Apple Park Way 837 Cupertino, California 95014 838 United States of America 839 Email: mellon@fugue.com