idnits 2.17.00 (12 Aug 2021) /tmp/idnits25689/draft-lemon-stub-networks-ps-02.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 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 261: '...ever approach is taken MAY use HNCP if...' RFC 2119 keyword, line 262: '... available, but MUST work without HNC...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Self-configuring Stub Networks: Problem Statement 8 draft-lemon-stub-networks-ps-02 10 Abstract 12 IETF currently provides protocols for automatically connecting single 13 hosts to existing network infrastructure. This document describes a 14 related problem: the problem of connecting a stub network (a 15 collection of hosts behind a router) automatically to existing 16 network infrastructure in the same manner. 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 27 October 2022. 35 Copyright Notice 37 Copyright (c) 2022 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 (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Interoperability Goals . . . . . . . . . . . . . . . . . 4 53 1.2. Usability Goals . . . . . . . . . . . . . . . . . . . . . 5 54 1.3. State of the Art . . . . . . . . . . . . . . . . . . . . 5 55 2. Possible Approaches . . . . . . . . . . . . . . . . . . . . . 6 56 2.1. Proxy ND . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.1.1. Reachability . . . . . . . . . . . . . . . . . . . . 7 58 2.1.2. Addressability . . . . . . . . . . . . . . . . . . . 7 59 2.1.3. Discoverability . . . . . . . . . . . . . . . . . . . 7 60 2.1.4. Requirements . . . . . . . . . . . . . . . . . . . . 7 61 2.1.5. Observations . . . . . . . . . . . . . . . . . . . . 8 62 2.2. Stub reachability using RA . . . . . . . . . . . . . . . 8 63 2.2.1. Reachability . . . . . . . . . . . . . . . . . . . . 8 64 2.2.2. Addressability . . . . . . . . . . . . . . . . . . . 8 65 2.2.3. Discoverability . . . . . . . . . . . . . . . . . . . 8 66 2.2.4. Requirements . . . . . . . . . . . . . . . . . . . . 8 67 2.2.5. Observations . . . . . . . . . . . . . . . . . . . . 9 68 2.3. Global reachability . . . . . . . . . . . . . . . . . . . 9 69 2.3.1. Reachability . . . . . . . . . . . . . . . . . . . . 10 70 2.3.2. Addressability . . . . . . . . . . . . . . . . . . . 10 71 2.3.3. Discoverability . . . . . . . . . . . . . . . . . . . 10 72 2.3.4. Requirements . . . . . . . . . . . . . . . . . . . . 10 73 2.3.5. Observations . . . . . . . . . . . . . . . . . . . . 10 74 2.4. Support for IPv4 . . . . . . . . . . . . . . . . . . . . 11 75 2.4.1. Reachability . . . . . . . . . . . . . . . . . . . . 11 76 2.4.2. Addressability . . . . . . . . . . . . . . . . . . . 12 77 2.4.3. Discoverability . . . . . . . . . . . . . . . . . . . 12 78 2.4.4. Requirements . . . . . . . . . . . . . . . . . . . . 12 79 2.4.5. Observations . . . . . . . . . . . . . . . . . . . . 12 80 3. Discoverability Options . . . . . . . . . . . . . . . . . . . 12 81 4. Multiple Egress, Multiple Link . . . . . . . . . . . . . . . 13 82 5. Management Considerations . . . . . . . . . . . . . . . . . . 14 83 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 86 9. Informative References . . . . . . . . . . . . . . . . . . . 14 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 This document describes the problem of linking stub networks to 92 existing networks automatically, in the same way that hosts, when 93 connected to an existing network, are able to discover network 94 addressing parameters, information about routing, and services that 95 are advertised on the network. 97 There are several use cases for stub networks. Motivating factors 98 include: 100 * Transitory connectivity: a mobile device acting as a router for a 101 set of co-located devices could connect to a network and gain 102 access to services for itself and for the co-located devices. 103 Such a stub network is unlikely to have more than one stub router. 105 * Incompatible media: for example, a constrained 802.15.4 network 106 connected as a stub network to a WiFi or ethernet infrastructure 107 network. In the case of an 802.15.4 network, it is quite possible 108 that the devices used to link the infrastructure network to the 109 stub network will not be conceived of by the end user as routers. 110 Consequently, we cannot assume that these devices will be on all 111 the time. A solution for this use case will require some sort of 112 commissioning process for stub routers, and can't assume that any 113 particular stub router will always be available; rather, any stub 114 router that is available must be able to adapt to current 115 conditions to provide reachability. 117 * Convenience: end users often connect devices to each other in 118 order to extend networks 120 What makes stub networks a distinct type of network is simply that a 121 stub network never provides transit between networks to which it is 122 connected. The term "stub" refers to the way the network is seen by 123 the link to which it is connected: there is reachability through a 124 stub network router to the stub network from that link, but there is 125 no reachability to any link beyond that one. 127 Stub networks may be globally reachable, or may be only locally 128 reachable. A host on a globally reachable stub network can 129 interoperate with other hosts anywhere on the Internet. A host on a 130 locally reachable stub network can only interoperate with hosts on 131 the network link(s) to which it is connected. 133 The goal of this document is to describe the minimal set of changes 134 or behaviors required to use existing IETF specifications to support 135 the stub network use case. The result should be a small set of 136 protocol enhancements (ideally no changes at all to protocols) and 137 should be deployable on existing networks without requiring changes 138 to those networks. Both the locally-reachable and globally-reachable 139 use case should be able to be made to work, and ideally the globally- 140 reachable use case should build on what is used to make the locally- 141 reachable use case work, rather than requiring two separate 142 solutions. 144 1.1. Interoperability Goals 146 What we mean by "interoperate" is that a host on a stub network: 148 * is discoverable by applicable hosts that are not on the stub 149 network 151 * is able to acquire an IP address that can be used to communicate 152 with applicable hosts not on the stub network 154 * has reachability to the network(s) to which applicable hosts are 155 attached 157 * is reachable from the network(s) to which applicable hosts are 158 attached 160 Discoverability here means "discoverable using DNS, or DNS Service 161 Discovery". As an example, when one host connected to a specific 162 WiFi network wishes to discover services on hosts connected to that 163 same WiFi network, it can do so using multicast DNS (RFC6762), which 164 is an example of DNS Service Discovery. Similarly, when a host on 165 some other network wishes to discover the same service, it must use 166 DNS-based DNS Service Discovery [RFC6763]. In both cases, 167 "discoverable using DNS" means that the host has an entry in the DNS. 169 NOTE: it may be tempting to ask, why do we lump discoverability in 170 with reachability and addressability, both of which are essentially 171 Layer 3 issues? The answer is that it does us no good to 172 automatically set up connectivity between stub network hosts and 173 infrastructure hosts if the infrastructure hosts have no mechanism 174 for learning about the availability of services provided by stub 175 network hosts. For stub networks that only consume cloud services 176 this will not be an issue, but for stub networks that provide 177 services, e.g. the incompatible media use case mentioned earlier, 178 discoverability is necessary in order for stub network connectivity 179 to be useful. 181 Ability to acquire an IP address that can be used to communicate 182 means that the IP address a host on the stub network acquires can be 183 used to communicate with it by hosts on neighbor networks, for 184 locally reachable stub networks, or by hosts on any network, for 185 globally reachable networks. Various means of providing such 186 addresses are discussed later. 188 Reachability to networks on which applicable hosts are attached means 189 that when a host on the stub network has the IP address of an 190 applicable host with which it intends to communicate, that host knows 191 of a next-hop router to which it can send datagrams, so that they 192 will ultimately reach the host with that IP address. 194 Reachability from networks on which applicable hosts are attached 195 means that when such a host has a datagram destined for an IP address 196 on the stub network, a next-hop router is known by that host which, 197 when the datagram is sent to that router, will ultimately result in 198 the datagram reaching the intended stub network host. 200 1.2. Usability Goals 202 In addition to the interoperability goals we've described above, the 203 additional goal for stub networks is that they be able to be 204 connected automatically, with no user intervention. The experience 205 of connecting a stub network to an infrastructure should be as 206 straightforward as connecting a new host to the same infrastructure 207 network. 209 1.3. State of the Art 211 Currently there is one known way to accomplish what we are describing 212 here [[Michael, does ANIMA have a second way?]]. The Homenet working 213 group produced a protocol, HomeNet Configuration Protocol (HNCP), the 214 purpose of which is to allow a collection of routers to self- 215 configure. HNCP is not technically constrained to home environments; 216 in principle, it can work in any environment. 218 The problem with HNCP is twofold. First, it only works if it is 219 deployed on all routers within the network infrastructure for a site. 220 Secondly, it attempts to do too much, and invents too much that is 221 new. Let's look at these in order. 223 First, HNCP only works when deployed on all routers within the 224 network infrastructure. To be clear, this does not mean that it is 225 impossible to use HNCP on a network where, for instance, the edge 226 router(s) do not support HNCP. What it does mean is that if this 227 configuration works, the reason it works is that the network supports 228 prefix delegation to routers inside the network. So a router doing 229 HNCP can get a prefix using prefix delegation from, for example, an 230 edge router, and this will work. 232 Unfortunately, the way that such an HNCP server should behave is not 233 documented, and it's not actually clear how it should behave. What 234 if the DHCP server allocates it a /64? HNCP is designed to get a 235 larger prefix and subdivide it-there is no provision for requesting 236 multiple delegations. So if we wanted to use HNCP to solve this 237 problem, we would need to do additional work. 239 Secondly, HNCP tries to do too much, and invents too much that is 240 new. HNCP is a complicated protocol for propagating network 241 configuration information in a mesh. It does not assume that any 242 network is a stub network, and because of that, using it to support 243 stub networks is needlessly complicated. 245 Despite having been an IETF proposed standard since 2016, and having 246 been worked on for quite some time before that, it is not possible to 247 purchase a router that implements HNCP. There exists a prototype 248 implementation in OpenWRT, but getting it to actually work is 249 problematic, and many problems have been left unsolved, and would be 250 quite difficult to solve with additional standards work. 252 We know this because several participants in the Homenet Working 253 Group have tried to implement make it work, and yet as yet we have 254 made no documentable progress, and indeed the Homenet Working Group 255 appears to be on the verge of closing. 257 Because of the first point-the utter lack of commercial 258 implementations of HNCP-any stub network solution that is intended to 259 be deployed to arbitrary networks can't rely on the availability of 260 HNCP. This may come in the future, but is not available now, and may 261 never be. Therefore, whatever approach is taken MAY use HNCP if 262 available, but MUST work without HNCP. Therefore, using HNCP 263 represents additional implementation complexity; whether this is 264 worth doing is something that should be considered, but because using 265 HNCP is necessarily optional, it probably makes the most sense to 266 assume that any functionality provided by HNCP will be external to 267 the stub network router, and that the stub network router itself need 268 not participate in the HNCP mesh. 270 2. Possible Approaches 272 2.1. Proxy ND 273 2.1.1. Reachability 275 Proxy Neighbor Discovery provides reachability to hosts on the stub 276 network by simply pretending that they are on the infrastructure 277 network. This reachability can be local or global depending on what 278 IPv6 service (if any) is available on the infrastructure link. The 279 use of Proxy ND for providing connectivity to stub networks is 280 described in [I-D.ietf-6lo-backbone-router]. 282 2.1.2. Addressability 284 If IPv6 service is available on the infrastructure link, this service 285 can be used to provide addressability on the stub network, and also 286 provides addressability on the infrastructure link. 288 If IPv6 service is not available on the infrastructure link, 289 addressability for proxy ND can be provided by advertising an on-link 290 autoconfigurable prefix in a Router Advertisement offered by the stub 291 router. 293 2.1.3. Discoverability 295 Discoverability for stub network hosts can be provided using DNS-SD 296 service registration protocol on the stub network, in combination 297 with an Advertising Proxy on the stub router which would advertise 298 registered services to the infrastructure link. 300 Discoverability of infrastructure link hosts by stub network hosts 301 can be provided using a DNS-SD discovery proxy and/or regular DNS. 302 As long as the stub network requires that each stub router provide a 303 DNS-SD Discovery Proxy and also provide name resolution, this will 304 work even in the multiple stub router case. 306 2.1.4. Requirements 308 * The infrastructure must either provide IPv6 service, or not block 309 the provision of IPv6 service by the stub router. 311 * Hosts on the infrastructure link must support IPv6 and must 312 support IPv6 neighbor discovery. 314 * Every stub host must register with at least one stub router that 315 will do proxy ND for it. 317 * Routers must share proxy ND information, or else each router is a 318 single point of failure for the set of hosts that have registered 319 with it. 321 * Sharing proxy ND information requires new protocol work 323 2.1.5. Observations 325 Can definitely work in specific circumstances, but probably doesn't 326 lend itself to full automation. 328 2.2. Stub reachability using RA 330 2.2.1. Reachability 332 Reachability to the stub network is provided using the Route 333 Information Option [RFC4191] in a router advertisement [RFC4861] 334 issued by the stub router. Since the stub router does not provide 335 IPv6 connectivity, it must not advertise itself as a default router. 336 Each stub router can provide a default route to the stub network. 338 2.2.2. Addressability 340 Addressability on the stub network is provided using a ULA prefix 341 generated by the stub router. Addressibility on the infrastructure 342 link is either provided by the infrastructure, or else must be 343 provided by the stub router. 345 2.2.3. Discoverability 347 Discoverability for this approach is the same as for the Proxy ND 348 approach. 350 2.2.4. Requirements 352 * Infrastructure network must not block router advertisements. 354 * Hosts on the infrastructure network must support IPv6, must 355 support the use of non-default routes as described in [RFC4191], 356 and must support routing through non-default routers (routers with 357 a router lifetime of 0). 359 * Stub routers must cooperate with other stub routers in announcing 360 an on-link prefix to the stub network. 362 * Stub routers must cooperate with infrastructure routers in 363 announcing an on-link prefix for the infrastructure network. Stub 364 routers must not advertise an on-link prefix when an on-link 365 prefix is already present. 367 2.2.5. Observations 369 This option has the advantage of relying primarily on ordinary IPv6 370 routing, as opposed to workarounds like proxy neighbor discovery or 371 NAT64. The cooperation that is required between stub routers is 372 minimal: they need simply minimize the advertising of redundant 373 information. When redundant information is advertised, this is an 374 aesthetic issue rather than an operational issue, and can be allowed 375 to heal gradually. 377 Additionally, this option does not require any new behavior on the 378 part of existing hosts or routers. It does assume that 379 infrastructure hosts actually implement [RFC4191], but it is not 380 unreasonable to expect that this either is already the case, or can 381 easily be accomplished. It also assumes that the infrastructure does 382 not enforce RA Guard [RFC6105]. This is compatible with the 383 recommendations in RFC6105, which indicates that RA guard needs to be 384 configured before it is enabled. 386 The approach described in this section only makes it possible for 387 stub network hosts to interoperate with hosts on the link to which 388 the stub router is directly attached. The "Global Reachability" 389 approach talks about how to establish interoperability between stub 390 network hosts and hosts on links to which the stub network is not 391 directly attached. 393 2.3. Global reachability 395 Global reachability for stub networks requires either the use of 396 NAT64, or else the presence of global IPv6 service on the link. As 397 such it is more of an add-on approach than a different approach. 398 This section talks about a specific example of global reachability: 399 how to make global reachability work for the "Stub Reachability using 400 RA" approach mentioned earlier. 402 The "global reachability" approach has applicability both in the 403 literal sense, and also in the sense of "reachability beyond the link 404 to which the stub router is directly attached." The behavior of the 405 stub router is the same in both cases: it is up to the network 406 infrastructure what prefix is delegated to the stub router, and what 407 reachability is provided. 409 2.3.1. Reachability 411 Reachability in this case requires integration into the routing 412 infrastructure. This is most easily accomplished by having the 413 DHCPv6 prefix delegation server add an entry in the routing table 414 pointing to the stub router to which the prefix has been delegated. 415 Stub routers can also advertise reachability to the stub network 416 using router advertisements, but these will only work on the local 417 link. 419 2.3.2. Addressability 421 Addressability in this case for hosts on the infrastructure link is 422 assumed to be provided by the infrastructure, since we are relying on 423 the infrastructure to provide DHCPv6 prefix delegation. 424 Addressibility on the stub network is provided using the prefix 425 acquired with prefix delegation. 427 2.3.3. Discoverability 429 Discoverability for devices on the link to which the stub network is 430 attached can be done as described earlier under the "Proxy ND" 431 approach. 433 2.3.4. Requirements 435 * Infrastructure network must support prefix allocation using DHCPv6 436 prefix delegation. 438 * Infrastructure network must install routes to prefixes provided 439 using DHCPv6 prefix delegation. 441 * In the case of multiple stub routers, stub routers must cooperate 442 both in acquiring and renewing prefixes acquired using prefix 443 delegation. Stub routers must communicate complete routing 444 information to the DHCPv6 prefix delegation server so that it can 445 install routes. 447 2.3.5. Observations 449 This approach should be a proper superset of the "Stub Reachability 450 using RA" approach. The primary technical challenge here is 451 specifying how multiple stub routers cooperate in doing prefix 452 delegation. 454 2.4. Support for IPv4 456 This document generally assumes that stub networks only support IPv6. 457 Bidirectional reachability for IPv4 can be provided using a 458 combination of NAT44 and Port Control Protocol [RFC6887]. The use of 459 NAT44 and PCP in this way has already been solved and need not be 460 discussed here. 462 2.4.1. Reachability 464 Reachability is complicated for NAT64. Typical NAT64 deployments 465 provide reachability from the stub network to the rest of the 466 Internet, but do not provide reachability from the rest of the 467 internet to the stub network. As with NAT44 and PCP, this type of 468 reachability is a solved problem and need not be discussed here. To 469 provide complete reachability to the IPv4 internet, a stub router 470 must not only provide reachability to the cloud, but also 471 reachability from the cloud. That additional work is discussed here. 473 To provide reachability from the cloud to devices on the network, 474 devices on the network will need to obtain static mappings from the 475 external IPv4 address and a port to the internal IPv6 address and a 476 port. There are three ways to do this: 478 * The stub host can use Port Control Protocol to register a port, 479 and then advertise that using SRP. 481 * The stub host can simply register using SRP, and then SRP can 482 establish a port mapping. 484 The first option has the advantage that the stub host is in complete 485 control over what is advertised. However, it places an additional 486 burden on the stub host which may not be desirable: the host has to 487 implement PCP and link the PCP port allocation to the SRP 488 registration. 490 For a constrained network device, it is most likely preferable to 491 combine the two transactions: the SRP server can receive the 492 registration from the stub host and acquire a PCP mapping for it, and 493 then register an AAAA and A record for the host along with an SRV 494 record for the IPv4 and IPv6 mappings. The hostname mapping would 495 need to be different for the A record and the AAAA record in order to 496 avoid spurious connections to the IPv4 port on the IPv6 address and 497 vice versa. 499 2.4.2. Addressability 501 Addressability on the stub network can be provided using a ULA prefix 502 specific to the stub network or, if NAT64 is being used in addition 503 to one of the other solutions discussed here, the prefix allocated on 504 the stub network for that purpose can also be used for NAT64. 506 IPv4 addressability on the infrastructure network is provided by the 507 infrastructure network. It is also possible that the infrastructure 508 network is an IPv6 network. In that case, the NAT64 edge router may 509 be provided by the infrastructure as well. 511 2.4.3. Discoverability 513 The discoverability described for the "ND Proxy" approach should work 514 here as well, except for the caveat mentioned above under 515 "reachability". 517 2.4.4. Requirements 519 * TBD 521 2.4.5. Observations 523 Support for NAT64 may be required for some deployments. NAT64 524 support requires either close cooperation between stub routers, or 525 else requires that the NAT64 translation be done externally. The 526 latter choice is likely quite a bit easier; solutions that provide 527 load balancing and high availability are already available on the 528 market, and hence do not require that the stub routers perform this 529 function. This is expected to be the best approach to serve the 530 needs of consumers of this capability. 532 3. Discoverability Options 534 We can divide the set of hosts needing to be discovered and the set 535 of hosts needing to discover them into four categories: 537 * Stub network hosts (stub hosts) 539 * Hosts that are on the link to which the stub network is directly 540 connected (direct hosts) 542 * Hosts that are on other links within the same infrastructure 543 (infrastructure hosts) 545 * Hosts that are on other links not within the same infrastructure 546 (cloud hosts) 548 To enable stub hosts to discover direct hosts, a Discovery Proxy 549 [RFC8766] can be used. This must be resident on any stub network 550 router that is seen by the stub host as a resolver. 552 To enable stub hosts to discover infrastructure hosts using DNS-SD 553 [RFC6763], the infrastructure must provide support for RFC6763 554 service discover using DNS. 556 To enable stub hosts to discover infrastructure hosts and cloud hosts 557 using DNS, DNS resolution must be provided by the stub router, and 558 the infrastructure must additionally provide the stub router with the 559 ability to resolve names. 561 To enable direct hosts to discover stub hosts, stub routers must 562 implement a DNS-SD Advertising Proxy. Stub hosts must register with 563 the advertising proxy using SRP. 565 To enable infrastructure hosts to discover stub hosts, stub routers 566 must provide authoritative DNS service for the stub network link so 567 that it can be integrated into the infrastructure DNS-SD service. To 568 do this automatically will require additional protocol work. 570 To enable cloud hosts to discover stub hosts, stub hosts would need 571 to register with the DNS, and the infrastructure would need to make 572 those registrations available globally, perhaps with whitelisting. 573 This is probably not a very widely applicable use case, and we do not 574 consider specifying how this works to be part of the work of this 575 document. 577 4. Multiple Egress, Multiple Link 579 In the case of a stub network that has multiple stub routers, it is 580 possible that, either when the stub network is initially set up, or 581 subsequently, one or more stub routers might be connected to a 582 different infrastructure link than one or more other stub routers. 583 There are two viable approaches to this problem: 585 * declare it out of scope and have the stub routers prevent such 586 configurations 588 * make sure that stub routers attached to each infrastructure link 589 provide complete service on that link 591 Explain further. 593 5. Management Considerations 595 TBD 597 6. Privacy Considerations 599 In the locally reachable case, privacy is protected in the sense that 600 names published locally are only visible to devices connected 601 locally. This may be insufficient privacy in some cases. 603 In the globally reachable case, discoverability has privacy 604 implications. Unfiltered automatic discoverability is probably not a 605 good idea in the globally reachable case. If automatic 606 discoverability is provided, some filtering mechanism would need to 607 be specified. 609 7. Security Considerations 611 TBD 613 8. IANA considerations 615 No new actions are required by IANA for this document. 617 9. Informative References 619 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 620 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 621 November 2005, . 623 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 624 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 625 DOI 10.17487/RFC4861, September 2007, 626 . 628 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 629 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 630 DOI 10.17487/RFC6105, February 2011, 631 . 633 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 634 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 635 . 637 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 638 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 639 DOI 10.17487/RFC6887, April 2013, 640 . 642 [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 643 Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 644 2020, . 646 [I-D.ietf-6lo-backbone-router] 647 Thubert, P., Perkins, C. E., and E. Levy-Abegnoli, "IPv6 648 Backbone Router", Work in Progress, Internet-Draft, draft- 649 ietf-6lo-backbone-router-20, 23 March 2020, 650 . 653 Author's Address 655 Ted Lemon 656 Apple, Inc. 657 One Apple Park Way 658 Cupertino, California 95014 659 United States of America 660 Email: mellon@fugue.com