idnits 2.17.00 (12 Aug 2021) /tmp/idnits40196/draft-sctl-dnssd-unicast-autoconfig-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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 8, 2018) is 1283 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-dnssd-hybrid has been published as RFC 8766 == Outdated reference: draft-ietf-mboned-ieee802-mcast-problems has been published as RFC 9119 == Outdated reference: draft-ietf-dnssd-push has been published as RFC 8765 == Outdated reference: A later version (-02) exists of draft-sctl-service-registration-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Informational T. Lemon 5 Expires: May 12, 2019 Nibbhaya Consulting 6 November 8, 2018 8 Unicast Service Discovery Autoconfiguration 9 draft-sctl-dnssd-unicast-autoconfig-00 11 Abstract 13 This document considers the requirements for adding a Thread mesh to 14 an existing home network, where the infrastructure of that existing 15 home network was designed with no prior knowledge of Thread, and 16 provides no special or unusual facilities designed to support this. 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 May 12, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 1. Introduction 52 [Authors' note: As an initial draft, in places this document presents 53 several alternatives that are being considered. We invite feedback 54 and comments to help evolve this document.] 56 Because multicast can be inefficient and unreliable [Mcast], work is 57 taking place to enable DNS-Based Service Discovery [RFC6763] to 58 operate with less reliance on multicast [Roadmap]. One current 59 target use case for this work is Thread [Thread] wireless mesh 60 networking. 62 Thread wireless mesh networking uses IEEE 802.15.4 radios, which use 63 little power, and are suitable for battery-powered devices. The 64 Thread protocol organizes the network nodes into a mesh, typically 65 with a Thread border router that connects the mesh to the home 66 network. For the purposes of this document we will refer to the home 67 network, be it Ethernet, or Wi-Fi, or both, or other similar 68 technologies, simply as the home network. The home network forms a 69 backbone to which one or more Thread mesh networks connect via Thread 70 border routers. 72 Existing work describes how DNS-Based Service Discovery can be 73 performed using unicast on such a network. Devices on the Thread 74 mesh offering services use Service Registration Protocol [RegProt] to 75 register their services at a Service Registration Server. Devices 76 seeking to discover these services send unicast queries to the 77 Service Registration Server using unicast DNS [RFC1034] [RFC1035] for 78 single individual queries, and using DNS Push Notifications [Push] 79 where ongoing change notification is required. 81 Certain configuration information is required for this to work. 82 Devices on the Thread mesh offering services need to know what names 83 to use when registering those services, and to what address they 84 should send their service registrations. Devices seeking to discover 85 these services need to know what names to use when constructing their 86 queries, and to what address they should send those queries. In 87 addition, IPv6 address prefixes need to be chosen and configured for 88 both the home network and the Thread mesh network(s), and 89 communicated, in order to facilitate unicast communication between 90 clients and the services they have discovered. 92 For proof-of-concept experiments, the necessary information can be 93 configured manually, and this has been done successfully. For 94 deployment, we need to determine how the necessary information will 95 be learned and configured automatically in real-world scenarios. 97 The Thread wireless mesh protocol includes mechanisms to perform 98 configuration tasks on the mesh, like electing a lead router, and 99 communicating this information to devices on the Thread mesh. This 100 existing mechanism can be extended fairly simply to facilitate the 101 necessary Service Registration Protocol configuration tasks. The 102 Service Registration Protocol [RegProt] specification document 103 advocates that if a device offering a service has no information 104 regarding the domain in which to register that service, it should use 105 the special use domain name [RFC6761] "services.arpa" to indicate 106 that the Service Registration Server should substitute a domain of 107 its choice, and that same mechanism is recommended in this case. 109 On the home network side of the Thread border router, there are 110 several possibilities. The necessary configuration tasks could be 111 handled by the home network's main gateway, by a collection of 112 Homenet routers using HNCP, or independently by the Thread border 113 router. 115 1.1. Configuration by Main Gateway 117 The home network's main gateway could handle the necessary 118 configuration tasks. 120 The main gateway could be responsible for selecting IPv6 address 121 prefixes for each of the links in the network, and communicating that 122 information to the relevant routers, perhaps using DHCPv6 prefix 123 delegation. 125 The information about what domain name to use for service discovery 126 can be communicated to client devices on the home network using DHCP 127 or IPv6 router advertisement options. Currently this is done using 128 the respective "DNS search list" options, though new options for this 129 specific purpose could be defined in the future. If the user has a 130 registered globally unique domain name for this purpose and the main 131 gateway is configured with this information, then that domain name 132 can be communicated to client devices. In the absence of a 133 registered globally unique domain name the special-use domain name 134 [RFC6761] "home.arpa" [RFC8375] should be used as a reasonable out- 135 of-the-box default. 137 Similarly, the information about what DNS recursive resolver to use 138 can be communicated to client devices on the home network using DHCP 139 or IPv6 router advertisement options. If the main gateway configures 140 its own address as the DNS recursive resolver for clients to use, it 141 can ensure that operations using "home.arpa" are handled 142 appropriately. Sending queries for names within "home.arpa" to 143 public recursive resolvers on the Internet will not yield useful 144 results, because names within "home.arpa" are not globally unique. 146 They are unique only within the local network, and hence queries for 147 those names need to be handled within the local network. 149 1.2. Configuration using HNCP 151 A complex home network with multiple links and multiple routers could 152 be managed using HNCP. However, at this time, this remains a future 153 possibility, since it is likely to be some time before HNCP is widely 154 used. 156 1.3. Self-Configuration by Thread Border Routers 158 The previous two scenarios assume that the home network's main 159 gateway, or its HNCP mesh, has specific capabilities to configure and 160 support the use of unicast DNS service discovery. 162 An alternative scenario is to consider the case where a Thread border 163 router is added to an existing home network, which has no special 164 mechanisms in place to support this operation. 166 The remainder of this document explores this scenario. 168 One possibility to keep in mind is that in this scenario, adding one 169 or more Thread border routers to an existing home network that 170 doesn't itself use HNCP, the Thread border router(s) themselves could 171 use HNCP as the protocol to communicate between each other to 172 coordinate their operation on the network. 174 2. Adding Thread Mesh to Existing Home Network 176 This section explores the requirements for connecting a Thread mesh, 177 via a Thread border router, to a typical home network. For the 178 purposes of this document, it is assumed that the existing network 179 infrastructure is fixed and cannot be changed. Changes or new 180 functionality may be implemented as required in the Thread devices on 181 the Thread mesh, in the Thread border router, or in the devices on 182 the home network that will be communicating with the Thread devices. 183 Since this document assumes no changes to the existing network 184 infrastructure, it is necessary to state the assumptions about that 185 existing network infrastructure. 187 We consider a typical home network to be a single multicast/broadcast 188 domain. If there are multiple Ethernet switches or Wi-Fi access 189 points, they are configured so that together they provide a single 190 logical link. If there is a NAT gateway, it is at the network egress 191 point. (A NAT gateway on the path between two devices on a home 192 network makes communication between those two devices considerably 193 more complicated, and this document does not address that case.) 195 In order to add a Thread mesh usefully to an existing home network, 196 several things need to be accomplished. The goal is to accomplish 197 these objectives without requiring changes to the existing 198 infrastructure on that home network. 200 1. Delivery of unicast traffic in both directions, from home network 201 to Thread mesh, and from Thread mesh to home network. 203 2. Enabling services offered by devices on the Thread mesh to be 204 discovered by clients seeking those services. 206 3. Enabling services offered by devices on the home network to be 207 discovered by clients on the Thread mesh seeking those services. 209 2.1. Unicast Delivery 211 If HNCP were in use on the network, then Thread border routers could 212 participate and use HNCP to manage their configuration. 214 In the absence of HNCP, Thread border routers need a way to self- 215 configure, without assistance from the home network's existing 216 infrastructure. 218 What is proposed is that Thread border routers select a 32-bit random 219 number, and use that to construct an IPv6 ULA prefix for their 220 connected mesh, which is very likely to be unique in that home. The 221 Thread border router then advertises reachability to that IPv6 ULA 222 prefix onto the home network using IPv6 Router Advertisements. In 223 principle, this can be done independently of whatever other IPv6 224 prefixes, if any, are being advertised on the home network by the 225 home network's existing main gateway. [It has been reported, 226 however, that there are at least some client devices that do not 227 properly handle receiving multiple independent IPv6 Router 228 Advertisements like this, so some investigation and bug fixing may be 229 required to make this work.] 231 In the case where there are multiple independent Thread border 232 routers connected to the home network, serving separate Thread 233 meshes, we want to avoid the situation where two different Thread 234 border routers choose the same randomly-selected IPv6 ULA prefix. 235 This can be achieved by having the Thread border routers listen for 236 IPv6 Router Advertisements before selecting their IPv6 ULA prefix. 237 If a Thread border router receives IPv6 Router Advertisements 238 offering reachability to its IPv6 ULA prefix via a different path, 239 then this indicates that an inadvertent duplication may have 240 occurred, and the Thread border router should select a different IPv6 241 ULA prefix for its mesh. 243 2.2. Discovery of Services on the Thread Mesh 245 To facilitate unicast discovery of services on the Thread mesh, four 246 things need to be determined: 248 1. How a device on the Thread mesh, offering services, knows what 249 parent domain name to use when registering services. 251 2. How that device knows to what address its service registrations 252 should be sent (if the name does not fall under a registered 253 globally unique domain name). 255 3. How a client device, on the Thread mesh or the home network, 256 seeking services, knows what parent domain name to use querying 257 to discover services. 259 4. How that device knows to what address its unicast service 260 discovery queries should be sent (if the name does not fall under 261 a registered globally unique domain name). 263 Devices on the Thread mesh should register services using the parent 264 domain "services.arpa". This indicates that the Service Registration 265 Server should automatically substitute an appropriate domain. 267 The Thread mesh management protocol can be used to configure devices 268 on the Thread mesh with the address to which they should send their 269 service registrations. 271 The Thread border router needs to communicate, to devices on the home 272 network, how they can discover services on the Thread mesh. 274 This involves communicating the service discovery domain. In 275 principle, this could be a registered globally unique domain name, it 276 which case the normal DNS delegation mechanism using NS records 277 allows the client to discover what server is authoritative for those 278 names. In many cases though, the Thread border router will not have 279 a registered globally unique domain name allocated. To provide out- 280 of-the-box automatic operation, the Thread border router needs to be 281 able to generate its own locally unique name to use. The special use 282 domain name "local" is not suitable, because of its implied sematics 283 that these names are resolved using link-local multicast DNS 284 [RFC6762]. The special use domain name "home.arpa" is not suitable, 285 because of its implied coordination via HNCP, and the home network's 286 main gateway may not support HNCP [RFC8375]. To provide out-of-the- 287 box automatic operation, this document proposes a new special use 288 domain name "adhoc.arpa" for this purpose. By default a Thread 289 border router will use the name "thread.adhoc.arpa". If this name is 290 already in use on the home network, then a new unique name will be 291 selected, such as "thread-2.adhoc.arpa". 293 The Thread border router needs to communicate the service discovery 294 domain to peers on the home network. In the case that the service 295 discovery domain falls under the "adhoc.arpa" name, the Thread border 296 router also needs to communicate that queries for these names need to 297 be sent to the Thread border router directly, not to the client's 298 default DNS recursive resolver. 300 Three alternatives are being considered 302 1. Use link-local Multicast DNS queries and records to convey the 303 service discovery domain, and optionally the address to which 304 queries should be sent. 306 2. Define a new IPv6 router advertisement option to communicate the 307 service discovery domain, and optionally the address to which 308 queries should be sent. 310 3. Add this information to the Multiple Provisioning Domain Router 311 Advertisement option [RFC7556] [MPvD]. 313 One question to answer is whether the Multicast DNS records or IPv6 314 router advertisement options would directly convey the domain name to 315 use for service discovery, or a base name used to derive domain 316 enumeration queries of the form lb._dns-sd._udp. [RFC6763]. 318 Another question is whether to use a single Multicast DNS record or 319 IPv6 router advertisement option that communicates both the domain 320 name and the address to use for queries, or a pair of records/ 321 options, one carrying the name to use for service discovery, and a 322 second, if necessary, associating an "adhoc.arpa" name with the 323 address to use for those queries. 325 With the appropriate configuration methods defined, and implemented 326 on client devices, client devices on the home network would discover 327 additional domains to use for service discovery, and send appropriate 328 service discovery queries to Thread border routers on the home 329 network. 331 The same discovery domain, and optionally the address to which 332 queries should be sent, is communicated to client devices on the 333 Thread mesh using the Thread mesh management protocol. 335 2.3. Discovery of Services on the Home Network 337 To facilitate devices on the Thread mesh discovering services offered 338 on the home network, advertised using Multicast DNS, a Discovery 339 Proxy [DisProx] is implemented in the Thread border router. 341 As above in Section 2.2 the Thread mesh management protocol is used 342 to communicate a discovery domain, and the address to which queries 343 should be sent for that discovery domain, to client devices on the 344 Thread mesh. 346 The address in this case is the address of the Thread border router. 347 The discovery domain could be some generated unique name under 348 "adhoc.arpa", or it could be some fixed special use domain name. The 349 fixed name could be a simple fixed string like "lan.arpa", or it 350 could be a special reserved name under "adhoc.arpa" such as 351 "services.adhoc.arpa". The latter is probably preferred because it 352 avoids having to request multiple special use domain names [RFC6761]. 353 Alternatively, we could organize all the required special names such 354 that they fall under a single reserved special use domain name 355 "services.arpa." 357 When the Thread border router receives a query for a name under this 358 discovery domain, it uses the Discovery Proxy mechanism [DisProx] to 359 perform Multicast DNS queries on behalf of the client, returning the 360 results to the client. 362 3. Security Considerations 364 As an informational document, this document introduces no new 365 Security Considerations of its own. The various referenced documents 366 each describe their own relevant Security Considerations as 367 appropriate. 369 4. Domain Name Reservation Considerations 371 As currently envisaged, this document may end up requesting a special 372 use domain name [RFC6761]. If so, once the special properties are 373 fully determined, this section will be populated with the appropriate 374 text. 376 5. Informative References 378 [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 379 Service Discovery", draft-ietf-dnssd-hybrid-08 (work in 380 progress), March 2018. 382 [Mcast] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 383 Zuniga, "Multicast Considerations over IEEE 802 Wireless 384 Media", draft-ietf-mboned-ieee802-mcast-problems-03 (work 385 in progress), October 2018. 387 [MPvD] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 388 for multiple provisioning domains in IPv6 Neighbor 389 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 390 (work in progress), February 2016. 392 [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 393 draft-ietf-dnssd-push-14 (work in progress), March 2018. 395 [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol 396 for DNS-Based Service Discovery", draft-sctl-service- 397 registration-00 (work in progress), July 2017. 399 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 400 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 401 . 403 [RFC1035] Mockapetris, P., "Domain names - implementation and 404 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 405 November 1987, . 407 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 408 RFC 6761, DOI 10.17487/RFC6761, February 2013, 409 . 411 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 412 DOI 10.17487/RFC6762, February 2013, 413 . 415 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 416 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 417 . 419 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 420 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 421 . 423 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 424 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 425 . 427 [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- 428 cheshire-dnssd-roadmap-03 (work in progress), October 429 2018. 431 [Thread] "Thread Wireless Mesh Networking", 432 . 434 Authors' Addresses 436 Stuart Cheshire 437 Apple Inc. 438 One Apple Park Way 439 Cupertino, California 95014 440 USA 442 Phone: +1 (408) 996-1010 443 Email: cheshire@apple.com 445 Ted Lemon 446 Nibbhaya Consulting 447 P.O. Box 958 448 Brattleboro, Vermont 05301 449 United States of America 451 Email: mellon@fugue.com