Internet Engineering Task Force S. Cheshire Internet-Draft Apple Inc. Intended status: Informational T. Lemon Expires: May 12, 2019 Nibbhaya Consulting November 8, 2018 Unicast Service Discovery Autoconfiguration draft-sctl-dnssd-unicast-autoconfig-00 Abstract This document considers the requirements for adding a Thread mesh to an existing home network, where the infrastructure of that existing home network was designed with no prior knowledge of Thread, and provides no special or unusual facilities designed to support this. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 12, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Cheshire & Lemon Expires May 12, 2019 [Page 1] Internet-Draft Unicast Service Discovery Autoconfig November 2018 1. Introduction [Authors' note: As an initial draft, in places this document presents several alternatives that are being considered. We invite feedback and comments to help evolve this document.] Because multicast can be inefficient and unreliable [Mcast], work is taking place to enable DNS-Based Service Discovery [RFC6763] to operate with less reliance on multicast [Roadmap]. One current target use case for this work is Thread [Thread] wireless mesh networking. Thread wireless mesh networking uses IEEE 802.15.4 radios, which use little power, and are suitable for battery-powered devices. The Thread protocol organizes the network nodes into a mesh, typically with a Thread border router that connects the mesh to the home network. For the purposes of this document we will refer to the home network, be it Ethernet, or Wi-Fi, or both, or other similar technologies, simply as the home network. The home network forms a backbone to which one or more Thread mesh networks connect via Thread border routers. Existing work describes how DNS-Based Service Discovery can be performed using unicast on such a network. Devices on the Thread mesh offering services use Service Registration Protocol [RegProt] to register their services at a Service Registration Server. Devices seeking to discover these services send unicast queries to the Service Registration Server using unicast DNS [RFC1034] [RFC1035] for single individual queries, and using DNS Push Notifications [Push] where ongoing change notification is required. Certain configuration information is required for this to work. Devices on the Thread mesh offering services need to know what names to use when registering those services, and to what address they should send their service registrations. Devices seeking to discover these services need to know what names to use when constructing their queries, and to what address they should send those queries. In addition, IPv6 address prefixes need to be chosen and configured for both the home network and the Thread mesh network(s), and communicated, in order to facilitate unicast communication between clients and the services they have discovered. For proof-of-concept experiments, the necessary information can be configured manually, and this has been done successfully. For deployment, we need to determine how the necessary information will be learned and configured automatically in real-world scenarios. Cheshire & Lemon Expires May 12, 2019 [Page 2] Internet-Draft Unicast Service Discovery Autoconfig November 2018 The Thread wireless mesh protocol includes mechanisms to perform configuration tasks on the mesh, like electing a lead router, and communicating this information to devices on the Thread mesh. This existing mechanism can be extended fairly simply to facilitate the necessary Service Registration Protocol configuration tasks. The Service Registration Protocol [RegProt] specification document advocates that if a device offering a service has no information regarding the domain in which to register that service, it should use the special use domain name [RFC6761] "services.arpa" to indicate that the Service Registration Server should substitute a domain of its choice, and that same mechanism is recommended in this case. On the home network side of the Thread border router, there are several possibilities. The necessary configuration tasks could be handled by the home network's main gateway, by a collection of Homenet routers using HNCP, or independently by the Thread border router. 1.1. Configuration by Main Gateway The home network's main gateway could handle the necessary configuration tasks. The main gateway could be responsible for selecting IPv6 address prefixes for each of the links in the network, and communicating that information to the relevant routers, perhaps using DHCPv6 prefix delegation. The information about what domain name to use for service discovery can be communicated to client devices on the home network using DHCP or IPv6 router advertisement options. Currently this is done using the respective "DNS search list" options, though new options for this specific purpose could be defined in the future. If the user has a registered globally unique domain name for this purpose and the main gateway is configured with this information, then that domain name can be communicated to client devices. In the absence of a registered globally unique domain name the special-use domain name [RFC6761] "home.arpa" [RFC8375] should be used as a reasonable out- of-the-box default. Similarly, the information about what DNS recursive resolver to use can be communicated to client devices on the home network using DHCP or IPv6 router advertisement options. If the main gateway configures its own address as the DNS recursive resolver for clients to use, it can ensure that operations using "home.arpa" are handled appropriately. Sending queries for names within "home.arpa" to public recursive resolvers on the Internet will not yield useful results, because names within "home.arpa" are not globally unique. Cheshire & Lemon Expires May 12, 2019 [Page 3] Internet-Draft Unicast Service Discovery Autoconfig November 2018 They are unique only within the local network, and hence queries for those names need to be handled within the local network. 1.2. Configuration using HNCP A complex home network with multiple links and multiple routers could be managed using HNCP. However, at this time, this remains a future possibility, since it is likely to be some time before HNCP is widely used. 1.3. Self-Configuration by Thread Border Routers The previous two scenarios assume that the home network's main gateway, or its HNCP mesh, has specific capabilities to configure and support the use of unicast DNS service discovery. An alternative scenario is to consider the case where a Thread border router is added to an existing home network, which has no special mechanisms in place to support this operation. The remainder of this document explores this scenario. One possibility to keep in mind is that in this scenario, adding one or more Thread border routers to an existing home network that doesn't itself use HNCP, the Thread border router(s) themselves could use HNCP as the protocol to communicate between each other to coordinate their operation on the network. Cheshire & Lemon Expires May 12, 2019 [Page 4] Internet-Draft Unicast Service Discovery Autoconfig November 2018 2. Adding Thread Mesh to Existing Home Network This section explores the requirements for connecting a Thread mesh, via a Thread border router, to a typical home network. For the purposes of this document, it is assumed that the existing network infrastructure is fixed and cannot be changed. Changes or new functionality may be implemented as required in the Thread devices on the Thread mesh, in the Thread border router, or in the devices on the home network that will be communicating with the Thread devices. Since this document assumes no changes to the existing network infrastructure, it is necessary to state the assumptions about that existing network infrastructure. We consider a typical home network to be a single multicast/broadcast domain. If there are multiple Ethernet switches or Wi-Fi access points, they are configured so that together they provide a single logical link. If there is a NAT gateway, it is at the network egress point. (A NAT gateway on the path between two devices on a home network makes communication between those two devices considerably more complicated, and this document does not address that case.) In order to add a Thread mesh usefully to an existing home network, several things need to be accomplished. The goal is to accomplish these objectives without requiring changes to the existing infrastructure on that home network. 1. Delivery of unicast traffic in both directions, from home network to Thread mesh, and from Thread mesh to home network. 2. Enabling services offered by devices on the Thread mesh to be discovered by clients seeking those services. 3. Enabling services offered by devices on the home network to be discovered by clients on the Thread mesh seeking those services. Cheshire & Lemon Expires May 12, 2019 [Page 5] Internet-Draft Unicast Service Discovery Autoconfig November 2018 2.1. Unicast Delivery If HNCP were in use on the network, then Thread border routers could participate and use HNCP to manage their configuration. In the absence of HNCP, Thread border routers need a way to self- configure, without assistance from the home network's existing infrastructure. What is proposed is that Thread border routers select a 32-bit random number, and use that to construct an IPv6 ULA prefix for their connected mesh, which is very likely to be unique in that home. The Thread border router then advertises reachability to that IPv6 ULA prefix onto the home network using IPv6 Router Advertisements. In principle, this can be done independently of whatever other IPv6 prefixes, if any, are being advertised on the home network by the home network's existing main gateway. [It has been reported, however, that there are at least some client devices that do not properly handle receiving multiple independent IPv6 Router Advertisements like this, so some investigation and bug fixing may be required to make this work.] In the case where there are multiple independent Thread border routers connected to the home network, serving separate Thread meshes, we want to avoid the situation where two different Thread border routers choose the same randomly-selected IPv6 ULA prefix. This can be achieved by having the Thread border routers listen for IPv6 Router Advertisements before selecting their IPv6 ULA prefix. If a Thread border router receives IPv6 Router Advertisements offering reachability to its IPv6 ULA prefix via a different path, then this indicates that an inadvertent duplication may have occurred, and the Thread border router should select a different IPv6 ULA prefix for its mesh. Cheshire & Lemon Expires May 12, 2019 [Page 6] Internet-Draft Unicast Service Discovery Autoconfig November 2018 2.2. Discovery of Services on the Thread Mesh To facilitate unicast discovery of services on the Thread mesh, four things need to be determined: 1. How a device on the Thread mesh, offering services, knows what parent domain name to use when registering services. 2. How that device knows to what address its service registrations should be sent (if the name does not fall under a registered globally unique domain name). 3. How a client device, on the Thread mesh or the home network, seeking services, knows what parent domain name to use querying to discover services. 4. How that device knows to what address its unicast service discovery queries should be sent (if the name does not fall under a registered globally unique domain name). Devices on the Thread mesh should register services using the parent domain "services.arpa". This indicates that the Service Registration Server should automatically substitute an appropriate domain. The Thread mesh management protocol can be used to configure devices on the Thread mesh with the address to which they should send their service registrations. The Thread border router needs to communicate, to devices on the home network, how they can discover services on the Thread mesh. This involves communicating the service discovery domain. In principle, this could be a registered globally unique domain name, it which case the normal DNS delegation mechanism using NS records allows the client to discover what server is authoritative for those names. In many cases though, the Thread border router will not have a registered globally unique domain name allocated. To provide out- of-the-box automatic operation, the Thread border router needs to be able to generate its own locally unique name to use. The special use domain name "local" is not suitable, because of its implied sematics that these names are resolved using link-local multicast DNS [RFC6762]. The special use domain name "home.arpa" is not suitable, because of its implied coordination via HNCP, and the home network's main gateway may not support HNCP [RFC8375]. To provide out-of-the- box automatic operation, this document proposes a new special use domain name "adhoc.arpa" for this purpose. By default a Thread border router will use the name "thread.adhoc.arpa". If this name is Cheshire & Lemon Expires May 12, 2019 [Page 7] Internet-Draft Unicast Service Discovery Autoconfig November 2018 already in use on the home network, then a new unique name will be selected, such as "thread-2.adhoc.arpa". The Thread border router needs to communicate the service discovery domain to peers on the home network. In the case that the service discovery domain falls under the "adhoc.arpa" name, the Thread border router also needs to communicate that queries for these names need to be sent to the Thread border router directly, not to the client's default DNS recursive resolver. Three alternatives are being considered 1. Use link-local Multicast DNS queries and records to convey the service discovery domain, and optionally the address to which queries should be sent. 2. Define a new IPv6 router advertisement option to communicate the service discovery domain, and optionally the address to which queries should be sent. 3. Add this information to the Multiple Provisioning Domain Router Advertisement option [RFC7556] [MPvD]. One question to answer is whether the Multicast DNS records or IPv6 router advertisement options would directly convey the domain name to use for service discovery, or a base name used to derive domain enumeration queries of the form lb._dns-sd._udp. [RFC6763]. Another question is whether to use a single Multicast DNS record or IPv6 router advertisement option that communicates both the domain name and the address to use for queries, or a pair of records/ options, one carrying the name to use for service discovery, and a second, if necessary, associating an "adhoc.arpa" name with the address to use for those queries. With the appropriate configuration methods defined, and implemented on client devices, client devices on the home network would discover additional domains to use for service discovery, and send appropriate service discovery queries to Thread border routers on the home network. The same discovery domain, and optionally the address to which queries should be sent, is communicated to client devices on the Thread mesh using the Thread mesh management protocol. Cheshire & Lemon Expires May 12, 2019 [Page 8] Internet-Draft Unicast Service Discovery Autoconfig November 2018 2.3. Discovery of Services on the Home Network To facilitate devices on the Thread mesh discovering services offered on the home network, advertised using Multicast DNS, a Discovery Proxy [DisProx] is implemented in the Thread border router. As above in Section 2.2 the Thread mesh management protocol is used to communicate a discovery domain, and the address to which queries should be sent for that discovery domain, to client devices on the Thread mesh. The address in this case is the address of the Thread border router. The discovery domain could be some generated unique name under "adhoc.arpa", or it could be some fixed special use domain name. The fixed name could be a simple fixed string like "lan.arpa", or it could be a special reserved name under "adhoc.arpa" such as "services.adhoc.arpa". The latter is probably preferred because it avoids having to request multiple special use domain names [RFC6761]. Alternatively, we could organize all the required special names such that they fall under a single reserved special use domain name "services.arpa." When the Thread border router receives a query for a name under this discovery domain, it uses the Discovery Proxy mechanism [DisProx] to perform Multicast DNS queries on behalf of the client, returning the results to the client. Cheshire & Lemon Expires May 12, 2019 [Page 9] Internet-Draft Unicast Service Discovery Autoconfig November 2018 3. Security Considerations As an informational document, this document introduces no new Security Considerations of its own. The various referenced documents each describe their own relevant Security Considerations as appropriate. 4. Domain Name Reservation Considerations As currently envisaged, this document may end up requesting a special use domain name [RFC6761]. If so, once the special properties are fully determined, this section will be populated with the appropriate text. 5. Informative References [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", draft-ietf-dnssd-hybrid-08 (work in progress), March 2018. [Mcast] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", draft-ietf-mboned-ieee802-mcast-problems-03 (work in progress), October 2018. [MPvD] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 (work in progress), February 2016. [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", draft-ietf-dnssd-push-14 (work in progress), March 2018. [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol for DNS-Based Service Discovery", draft-sctl-service- registration-00 (work in progress), July 2017. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . Cheshire & Lemon Expires May 12, 2019 [Page 10] Internet-Draft Unicast Service Discovery Autoconfig November 2018 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, . [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, . [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- cheshire-dnssd-roadmap-03 (work in progress), October 2018. [Thread] "Thread Wireless Mesh Networking", . Authors' Addresses Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, California 95014 USA Phone: +1 (408) 996-1010 Email: cheshire@apple.com Ted Lemon Nibbhaya Consulting P.O. Box 958 Brattleboro, Vermont 05301 United States of America Email: mellon@fugue.com Cheshire & Lemon Expires May 12, 2019 [Page 11]