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