idnits 2.17.1 draft-ietf-homenet-simple-naming-01.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 276: '... MUST filter out global IP addresses...' RFC 2119 keyword, line 319: '...mal Homenet routers MUST implement the...' RFC 2119 keyword, line 455: '.... However, homenet servers MUST allow...' RFC 2119 keyword, line 458: '... homenet routers MUST NOT answer queri...' RFC 2119 keyword, line 468: '...red with a globally unique domain MUST...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC7556' on line 169 -- Looks like a reference, but probably isn't: 'CITE' on line 502 == Unused Reference: '8' is defined on line 580, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 606, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-07 == Outdated reference: A later version (-04) exists of draft-sctl-dnssd-mdns-relay-02 == Outdated reference: A later version (-02) exists of draft-sctl-service-registration-00 == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-12 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nibbhaya Consulting 4 Intended status: Informational D. Migault 5 Expires: September 6, 2018 Ericsson 6 S. Cheshire 7 Apple Inc. 8 March 5, 2018 10 Simple Homenet Naming and Service Discovery Architecture 11 draft-ietf-homenet-simple-naming-01 13 Abstract 15 This document describes how names are published and resolved on 16 homenets, and how hosts are configured to use these names to discover 17 services on homenets. It presents the complete architecture, and 18 describes a simple subset of that architecture that can be used in 19 low-cost homenet routers. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 6, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Managed LAN versus Homenet . . . . . . . . . . . . . . . 4 58 2.2. Homenet-specific considerations . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. DNS Service Discovery Registration Protocol . . . . . . . 7 65 7.2. Configuring Service Discovery . . . . . . . . . . . . . . 7 66 8. Host Configurtion . . . . . . . . . . . . . . . . . . . . . . 10 67 9. Globally Unique Name . . . . . . . . . . . . . . . . . . . . 10 68 10. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . . . 10 69 11. Support for Multiple Provisioning Domains . . . . . . . . . . 11 70 12. Using the Local Namespace While Away From Home . . . . . . . 11 71 13. Management Considerations . . . . . . . . . . . . . . . . . . 11 72 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 73 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 16. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 75 17. Normative References . . . . . . . . . . . . . . . . . . . . 12 76 Appendix A. Existing solutions . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 This document is a homenet architecture document. The term 'homenet' 82 refers to a set of technologies that allow home network users to have 83 a local-area network (LAN) with more than one physical link and, 84 optionally, more than one internet service provider. Home network 85 users are assumed not to be knowledgable in network operations, so 86 homenets automatically configure themselves, providing connectivity 87 and service discovery within the home with no operator intervention. 88 This document describes the aspect of homenet automatic configuration 89 that has to do with service discovery and name resolution. 91 The homenet naming architecture consists of two parts: the simple 92 naming architecture, and the advanced naming architecture. The 93 advanced architecture provides approximate parity of features with a 94 managed network, including the ability to publish services on the 95 internet. The simple architecture provides a minimal set of features 96 required to enable seamless service discovery on a multi-link home 97 network, but does not attempt to provide feature parity with a 98 managed LAN. 100 This document begins by presenting a motivational list of 101 requirements and considerations, which should give the reader a clear 102 idea of the scope of the problem being solved. It then explains how 103 each requirement is addressed, and provides references for relevant 104 standards documents describing the details of the implementation. 105 Some requirements are not satisfied by the simple architecture; these 106 are discussed in this document, but explained in more detail in the 107 Advanced Homenet Naming Architecture document, which is to follow. 109 2. Requirements 111 Name service on a local area network (LAN) requires the following: 113 o Name: a forward domain under which information about local 114 services will be published 116 o Authority: a name server that is authoritative for at least a 117 forward and one or two reverse domains that are applicable to that 118 network 120 o Resolution: a full-service caching DNS resolver 122 o Publication: a mechanism that 124 * allows services on the LAN to publish information about the 125 services they provide 127 * allows services to publish information on how to reach them 129 * manages the lifetime of such information, so that it persists 130 long enough to prevent spoofing, but protects end users from 131 seeing stale information 133 o Host configuration: one or more automatic mechanisms (e.g. DHCP 134 or RA) that provide: 136 * caching resolver information to hosts on the LAN 138 * information about how services on the LAN can publish 139 information 141 o Trust: some basis for trusting the information that is provided by 142 the service discovery system 144 2.1. Managed LAN versus Homenet 146 On a managed LAN, many of these services can be provided by 147 operators. When a new printer is added to the network, it can be 148 added to the service discovery system (the authoritative server) 149 manually. When a printer is taken out of service, it can be removed. 150 In this scenario, the role of "publisher" is filled by the network 151 operator. 153 In many managed LANs, establishment of trust for service discovery is 154 simply on the basis of a belief that the local resolver will give a 155 correct answer. Once the service has been discovered and chosen, 156 there may be some security (e.g., TLS) that protects the connection 157 to the service, but the trust model is often just "you're connected 158 to a network you trust, so you can trust the printer that you 159 discovered on this network." 161 A homenet does not have an operator, so functions that would normally 162 be performed by the operator have to happen automatically. This has 163 implications for trust establishment--since there is no operator 164 controlling what services are published locally, some other mechanism 165 is required for basic trust establishment. Additionally, whereas in 166 a managed LAN with multiple links to the Internet, the network 167 operator can configure the network so that multihoming is handled 168 seamlessly, in a homenet, multihoming must be handled using multiple 169 provisioning domains [RFC7556]. 171 2.2. Homenet-specific considerations 173 A naming architecture for homenets therefore adds the following 174 considerations: 176 o All of the operations mentioned here must reliably function 177 automatically, without any user intervention or debugging. 179 o Because user intervention cannot be required, naming conflicts 180 must be resolved automatically, and, to the extent possible, 181 transparently. 183 o Devices that provide services must be able to publish those 184 services on the homenet, and those services must be available from 185 any part of the homenet, not just the link to which the device is 186 attached. 188 o Homenets must address the problem of multiple provisioning 189 domains, in the sense that the DNS may give a different answer 190 depending on whether caching resolvers at one ISP or another are 191 queried. 193 An additional requirement from the Homenet Architecture [9] is that 194 hosts are not required to implement any homenet-specific capabilities 195 in order to discover and access services on the homenet. This 196 architecture may define optional homenet-specific features, but hosts 197 that do not implement these features must work on homenets. 199 3. Terminology 201 This document uses the following terms and abbreviations: 203 HNR Homenet Router 205 SHNR Homenet Router implementing simple homenet naming architecture 207 AHNR Homenet Router implementing advanced homenet naming 208 architecture 210 ISP Internet Service Provider 212 4. Name 214 In order for names to be published on a homenet, it is necessary that 215 there be a set of domain names under which such names are published. 216 These domain names, together, are referred to as the "local domains." 217 By default, homenets use the reserved domain 'home.arpa.' for 218 publishing names for forward lookups. So a host called 'example' 219 that published its name on the homenet would publish its records on 220 the domain name 'example.home.arpa.'. Because 'home.arpa.' is used 221 by all homenets, it has no global meaning, and names published under 222 the domain 'home.arpa' cannot be used outside of the homenet on which 223 they are published. 225 Homenet routers that implement advanced homenet naming may also be 226 configured with a global domain. How such a domain is configured is 227 out of scope for this document, and is described in the Advanced 228 Homenet Naming Architecture document [advanced]. 230 In addition to the name, which defaults to 'home.arpa.', names are 231 needed for reverse lookups. These names are dependent on the IP 232 addressing used on the homenet. If the homenet is addressed with 233 IPv4, a reverse domain corresponding to the IPv4 subnet [1] section 234 5.2.1 should be constructed. For example, if the homenet is 235 allocating local IP addresses out of net 10 [3], a domain, '10.in- 236 addr.arpa' would be required. Like 'home.arpa.', '10.in-addr.arpa' 237 is a locally-served zone, and has no validity outside of the homenet. 239 If the homenet is addressed with IPv6, it is expected to have a 240 unique local address prefix; subsets of this prefix will be 241 advertised on every link on the homenet. Every service on the 242 homenet that supports IPv6 is expected to be reachable at an address 243 that is configured using the ULA prefix. Therefore there is no need 244 for any IPv6 reverse zone to be populated other than the ULA zone. 245 So for example if the homenet's ULA prefix is fd00:2001:db8::/48, 246 then the reverse domain name for the homenet would end in 247 '8.b.d.0.1.0.0.2.0.0.d.f.ip6.arpa'. 249 5. Authority 251 The authority role is provided by a name server that is authoritative 252 for each of the local domains. SHNRs provide authoritative service 253 for the homenet using DNSSD Discovery Broker [17]. SHNRs also 254 provide Discovery Relay service [12]. On a homenet that has only 255 SHNRs, each SHNR individually provides authoritative service for the 256 whole homenet by using Discovery relays to discover services off the 257 local link. 259 The Discovery Proxy model relies on each link having its own name. 260 However, homenets do not actually have a way to name local links that 261 will make any sense to the end user. Consequently, this mechanism 262 will not work without some tweaks. In order to address this, 263 homenets will use Discovery Brokers [17]. The discovery broker will 264 be configured so that a single query for a particular service will be 265 successful in providing the information required to access that 266 service, regardless of the link it is on. 268 Artificial link names will be generated using HNCP. These should 269 only be visible to the user in graphical user interfaces in the event 270 that the same name is claimed by a service on two links. Services 271 that are expected to be accessed by users who type in names should 272 use [13] if it is available. 274 It is possible that local services may offer services available on IP 275 addresses in public as well as ULA prefixes. Homenet hybrid proxies 276 MUST filter out global IP addresses, providing only ULA addresses, 277 similar to the process described in section 5.5.2 of [11]. 279 This filtering applies to queries within the homenet; it is 280 appropriate for non-ULA addresses to be used for offering services, 281 because in some cases end users may want such services to be 282 reachable outside of the homenet. Configuring this is however out of 283 scope for this document. 285 6. Resolution 287 Name resolution is provided by a local DNS cache or proxy on the 288 homenet, henceforth the "local resolver." All host queries are sent 289 to this local resolver. The local resolver may either act as a full- 290 service caching resolver, or as a DNS proxy. Its responsibility with 291 respect to queries on the homenet is to notice queries for names for 292 which the local authoritative server is authoritative. Queries for 293 such names are handled through the local authoritative server. 294 Queries for all other names are resolved either by forwarding them to 295 an ISP-provided full service resolver, or by providing the full 296 service resolver function locally. 298 7. Publication 300 7.1. DNS Service Discovery Registration Protocol 302 The DNSSD Service Registration protocol [13] requires that DNS 303 updates be validated on the basis that they are received on the local 304 link. To ensure that such registrations are actually received on 305 local links in the homenet, updates are sent to the local relay proxy 306 ([12]) (XXX how?). 308 The relay proxy encapsulates the update and sends it to whatever 309 Discovery Proxy is listening on the link; the Discovery proxy then 310 either consumes the update directly, or forwards it to the 311 authoritative resolver for the local service discovery zone. If the 312 registration protocol is not supported on the homenet, the Discovery 313 Proxy rejects the update with a ??? RCODE. 315 Homenets are not required to support Service Registration. Service 316 registration requires a stateful authoritative DNS server; this may 317 be beyond the capability of the minimal Homenet router. However, 318 more capable Homenet routers should provide this capability. In 319 order to make this work, minimal Homenet routers MUST implement the 320 split hybrid proxy [12]. This enables a Homenet with one or more 321 Homenet routers that provide a stateful registration cache to allow 322 those routers to take over service, using Discovery Relays to service 323 links that are connected using Homenet routers with more limited 324 functionality. 326 7.2. Configuring Service Discovery 328 Clients discovering services using DNS-SD [7] follow a two-step 329 process. The first step is for the client device to determine in 330 which domain(s) to attempt to discover services. The second step is 331 for the client device to then seek desired service(s) in those 332 domain(s). For an example of the second step, given the desired 333 service type "IPP Printing", and the domains "local" and 334 "meeting.ietf.org", the client device forms the queries 335 "_ipp._tcp.local. PTR ?" (resolved using Multicast DNS) and 336 "_ipp._tcp.meeting.ietf.org PTR. ?" (resolved using Unicast DNS) and 337 then presents the combined list of results to the user. 339 The first step, determining in which domain(s) to attempt to discover 340 services, is performed in a variety of ways, as described in 341 Section 11 of the DNS-Based Service Discovery specification [7]. 343 The domain "local" is generally always in the set of domains in which 344 the client devices attempt to discover services, and other domains 345 for service discovery may be configured manually by the user. 347 The device also learns additional domains automatically from its 348 network environment. For this automatic configuration discovery, 349 special DNS queries are formulated. To learn additional domain(s) in 350 which to attempt to discover services, the query string 351 "lb._dns_sd._udp" is prepended onto three different kinds of 352 "bootstrap domain" to form DNS queries that allow the device to learn 353 the configuration information. 355 One of these bootstrap domains is the fixed string "local". The 356 device issues the query "lb._dns_sd._udp.local. PTR ?" (resolved 357 using Multicast DNS), and if any answers are received, then they are 358 added to the set of domains in which the client devices attempt to 359 discover services. 361 Another kind of these bootstrap domains is name-based, derived from 362 the DHCPv4 "domain name" option (code 15) [4] (for IPv4) or the DNS 363 Search List (DNSSL) Router Advertisement option [10] (for IPv6). If 364 a domain in the DNSSL is "example.com", then the device issues the 365 query "lb._dns_sd._udp.example.com. PTR ?" (resolved using Unicast 366 DNS), and if any answers are received, then they are likewise added 367 to the set of domains in which the client devices attempt to discover 368 services. 370 Finally, the third kind of bootstrap domain is address-based, derived 371 from the device's IP address(es) themselves. If the device has IP 372 address 192.168.1.100/24, then the device issues the query 373 "lb._dns_sd._udp.0.1.168.192.in-addr.arpa. PTR ?" (resolved using 374 Unicast DNS), and if any answers are received, then they are also 375 added to the set of domains in which the client devices attempt to 376 discover services. 378 Since there is an HNR on every link of a homenet, automatic 379 configuration could be performed by having HNRs answer the 380 "lb._dns_sd._udp.local. PTR ?" (Multicast DNS) queries. However, 381 because multicast is slow and unreliable on many modern network 382 technologies like Wi-Fi, we prefer to avoid using it. Instead we 383 require that a homenet be configured to answer the name-based 384 bootstrap queries. By default the domain in the DNSSL communicated 385 to the client devices will be "home.arpa", and the homenet will be 386 configured to correctly answer queries such as 387 "lb._dns_sd._udp.example.com. PTR ?", though client devices must not 388 assume that the name will always be "home.arpa". A client could be 389 configured with any valid DNSSL, and should construct the appropriate 390 bootstrap queries derived from the name(s) in their configured DNS 391 Search List. 393 HNRs will answer domain enumeration queries against every IPv4 394 address prefix advertised on a homenet link, and every IPv6 address 395 prefix advertised on a homenet link, including prefixes derived from 396 the homenet's ULA(s). Whenever the "" sequence appears in 397 this section, it references each of the domains mentioned in this 398 paragraph. 400 Homenets advertise the availability of several browsing zones in the 401 "b._dns_sd._udp." subdomain. By default, the 'home.arpa' 402 domain is advertised. Similarly, 'home.arpa' is advertised as the 403 default browsing and service registration domain under 404 "db._dns_sd._udp.", "r._dns_sd._udp.", 405 "dr._dns_sd._udp." and "lb._dns_sd._udp.". 407 In order for this discovery process to work, the homenet must provide 408 authoritative answers for each of the domains that might be queried. 409 To do this, it provides authoritative name service for the 'ip6.arpa' 410 and 'in-addr.arpa' subdomains corresponding to each of the prefixes 411 advertised on the homenet. For example, consider a homenet with the 412 192.168.1.0/24, 2001:db8:1234:5600::/56 and fc01:2345:6789:1000::/56 413 prefixes. This homenet will have to provide a name server that 414 claims to be authoritative for 1.168.192.in-addr.arpa, 415 6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa and 416 0.0.9.8.7.6.5.4.3.2.1.0.c.f.ip6.arpa. 418 An IPv6-only homenet would not have an authoritative server for a 419 subdomain of in-addr.arpa. These public authoritative zones are 420 required for the public prefixes even if the prefixes are not 421 delegated. However, they need not be accessible outside of the 422 homenet. 424 It is out of the scope of this document to specify ISP behavior, but 425 we note that ISPs have the option of securely delegating the zone, or 426 providing an unsigned delegation, or providing no delegation. Any 427 delegation tree that does not include an unsigned delegation at or 428 above the zone cut for the ip6.arpa reverse zone for the assigned 429 prefix will fail to validate. 431 Ideally, an ISP should provide a secure delegation using a zone- 432 signing key provided by the homenet. However, that too is out of 433 scope for this document. Therefore, an ISP that wishes to support 434 users of the simple homenet naming architecture will have to provide 435 an unsigned delegation. We do not wish, however, to discourage 436 provisioning of signed delegations when that is possible. 438 8. Host Configurtion 440 Hosts on the homenet receive a set of resolver IP addresses using 441 either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of 442 resolvers, if available, over DHCP. IPv6-only hosts will receive 443 resolver IPv6 addresses using either stateful (if available) or 444 stateless DHCPv6, or through the Recursive DNS Server Option ([10], 445 Section 5.1) in router advertisements. 447 All Homenet routers provide resolver information using both stateless 448 DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is optional, 449 however if either service is offered, resolver addresses will be 450 provided using that mechanism as well. 452 9. Globally Unique Name 454 Automatic configuration of a globally unique name for the homenet is 455 out of scope for this document. However, homenet servers MUST allow 456 the user to configure a globally unique name in place of the default 457 name, 'home.arpa.' By default, even if configured with a global 458 name, homenet routers MUST NOT answer queries from outside of the 459 homenet for subdomains of that name. 461 10. DNSSEC Validation 463 DNSSEC Validation for the 'home.arpa' zone and for the locally-served 464 'ip6.arpa and 'in-adr.arpa' domains is not possible without a trust 465 anchor. Establishment of a trust anchor for such validation is out 466 of scope for this document. 468 Homenets that have been configured with a globally unique domain MUST 469 support DNSSEC signing of local names, and must provide a way to 470 generate a KSK that can be used in the secure delegation of the 471 globally unique domain assigned to the homenet. 473 11. Support for Multiple Provisioning Domains 475 Homenets must support the Multiple Provisioning Domain Architecture 476 [9]. Hosts connected to the homenet may or may not support multiple 477 provisioning domains. For hosts that do not support multiple 478 provisioning domains, the homenet provides one or more resolvers that 479 will answer queries for any provisioning domain. Such hosts may 480 receive answers to queries that either do not work as well if the 481 host chooses a source address from a different provisioning domain, 482 or does not work at all. However, the default source address 483 selection policy, longest-match [CITE], will result in the correct 484 source address being chosen as long as the destination address has a 485 close match to the prefix assigned by the ISP. 487 Hosts that support multiple provisioning domains will be provisioned 488 with one or more resolvers per provisioning domain. Such hosts can 489 use the IP address of the resolver to determine which provisioning 490 domain is applicable for a particular answer. 492 Each ISP has its own provisioning domain. Because ISPs connections 493 cannot be assumed to be persistent, the homenet has its own separate 494 provisioning domain. 496 Configuration from the IPv4 DHCP server are treated as being part of 497 the homenet provisioning domain. The case where a homenet advertises 498 IPv4 addresses from one or more public prefixes is out of scope for 499 this document. Such a configuration is NOT RECOMMENDED for homenets. 501 Configuration for IPv6 provisioning domains is done using the 502 Multiple Provisioning Domain RA option [CITE]. 504 12. Using the Local Namespace While Away From Home 506 This architecture does not provide a way for service discovery to be 507 performed on the homenet by devices that are not directly connected 508 to a link that is part of the homenet. 510 13. Management Considerations 512 This architecture is intended to be self-healing, and should not 513 require management. That said, a great deal of debugging and 514 management can be done simply using the DNS Service Discovery 515 protocol. 517 14. Privacy Considerations 519 Privacy is somewhat protected in the sense that names published on 520 the homenet are only visible to devices connected to the homenet. 521 This may be insufficient privacy in some cases. 523 The privacy of host information on the homenet is left to hosts. 524 Various mechanisms are available to hosts to ensure that tracking 525 does not occur if it is not desired. However, devices that need to 526 have special permission to manage the homenet will inevitably reveal 527 something about themselves when doing so. It may be possible to use 528 something like HTTP token binding [15] to mitigate this risk. 530 15. Security Considerations 532 There are some clear issues with the security model described in this 533 document, which will be documented in a future version of this 534 section. A full analysis of the avenues of attack for the security 535 model presented here have not yet been done, and must be done before 536 the document is published. 538 16. IANA considerations 540 No new actions are required by IANA for this document. 542 Note however that this document is relying on the allocation of 543 'home.arpa' described in Special Use Top Level Domain '.home.arpa' 544 [16]. This document therefore can't proceed until that allocation is 545 done. [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH PRIOR TO 546 PUBLICATION]. 548 17. Normative References 550 [1] Mockapetris, P., "Domain names - concepts and facilities", 551 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 552 . 554 [2] Mockapetris, P., "Domain names - implementation and 555 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 556 November 1987, . 558 [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 559 and E. Lear, "Address Allocation for Private Internets", 560 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 561 . 563 [4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 564 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 565 . 567 [5] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 568 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 569 RFC 2136, DOI 10.17487/RFC2136, April 1997, 570 . 572 [6] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 573 DOI 10.17487/RFC6762, February 2013, 574 . 576 [7] Cheshire, S. and M. Krochmal, "DNS-Based Service 577 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 578 . 580 [8] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 581 Weil, "IPv6 Home Networking Architecture Principles", 582 RFC 7368, DOI 10.17487/RFC7368, October 2014, 583 . 585 [9] Anipko, D., Ed., "Multiple Provisioning Domain 586 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 587 . 589 [10] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 590 "IPv6 Router Advertisement Options for DNS Configuration", 591 RFC 8106, DOI 10.17487/RFC8106, March 2017, 592 . 594 [11] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 595 Service Discovery", draft-ietf-dnssd-hybrid-07 (work in 596 progress), September 2017. 598 [12] Cheshire, S. and T. Lemon, "Multicast DNS Discovery 599 Relay", draft-sctl-dnssd-mdns-relay-02 (work in progress), 600 November 2017. 602 [13] Cheshire, S. and T. Lemon, "Service Registration Protocol 603 for DNS-Based Service Discovery", draft-sctl-service- 604 registration-00 (work in progress), July 2017. 606 [14] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 607 for multiple provisioning domains in IPv6 Neighbor 608 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 609 (work in progress), February 2016. 611 [15] Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 612 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 613 tokbind-https-12 (work in progress), January 2018. 615 [16] Pfister, P. and T. Lemon, "Special Use Domain 616 'home.arpa.'", draft-ietf-homenet-dot-14 (work in 617 progress), September 2017. 619 [17] Cheshire, S. and T. Lemon, "Service Discovery Broker", 620 draft-sctl-discovery-broker-00 (work in progress), July 621 2017. 623 Appendix A. Existing solutions 625 Previous attempts to automate naming and service discovery in the 626 context of a home network are able to function with varying degrees 627 of success depending on the topology of the home network. 628 Unfortunately, these solutions do not fully address the requirements 629 of homenets. 631 For example, Multicast DNS [6] can provide naming and service 632 discovery [7], but only within a single multicast domain. 634 The Domain Name System provides a hierarchical namespace [1], a 635 mechanism for querying name servers to resolve names [2], a mechanism 636 for updating namespaces by adding and removing names [5], and a 637 mechanism for discovering services [7]. Unfortunately, DNS provides 638 no mechanism for automatically provisioning new namespaces, and 639 secure updates to namespaces require that the host submitting the 640 update have a public or symmetric key that is known to the network 641 and authorized for updates. In an unmanaged network, the publication 642 of and authorization of these keys is an unsolved problem. 644 Some managed networks get around this problem by having the DHCP 645 server do DNS updates. However, this doesn't really work, because 646 DHCP doesn't provide a mechanism for updating service discovery 647 records: it only supports publishing A and AAAA records. 649 This partially solves the trust problem: DHCP can validate that a 650 device is at least connected to a network link that is actually part 651 of the managed network. This prevents an off-network attacker from 652 registering a name, but provides no mechanism for actually validating 653 the identity of the host registering the name. For example, it would 654 be easy for an attacker on the network to steal a registered name. 656 Hybrid Multicast DNS [11] proposes a mechanism for extending 657 multicast DNS beyond a single multicast domain. However, in order to 658 use this as a solution, some shortcomings need to be considered. 660 Most obviously, it requires that every multicast domain have a 661 separate name. This then requires that the homenet generate names 662 for every multicast domain. These names would then be revealed to 663 the end user. But since they would be generated automatically and 664 arbitrarily, they would likely cause confusion rather than clarity, 665 and in degenerate cases requires that the end user have a mental 666 model of the topology of the network in order to guess on which link 667 a given service may appear. 669 At present, the approach we intend to take with respect to 670 disambiguation is that this will not be solved at a protocol level 671 for devices that do not implement the registration protocol. 673 Authors' Addresses 675 Ted Lemon 676 Nibbhaya Consulting 677 P.O. Box 958 678 Brattleboro, Vermont 05301 679 United States of America 681 Email: mellon@fugue.com 683 Daniel Migault 684 Ericsson 685 8400 boulevard Decarie 686 Montreal, QC H4P 2N2 687 Canada 689 Email: daniel.migault@ericsson.com 691 Stuart Cheshire 692 Apple Inc. 693 1 Infinite Loop 694 Cupertino, California 95014 695 USA 697 Phone: +1 408 974 3207 698 Email: cheshire@apple.com