idnits 2.17.1 draft-ietf-homenet-simple-naming-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 : ---------------------------------------------------------------------------- == 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 393: '... and names advertised locally MUST use...' RFC 2119 keyword, line 398: '... MUST filter out global IP addresses...' RFC 2119 keyword, line 426: '...mal Homenet routers MUST implement the...' RFC 2119 keyword, line 436: '.... However, homenet servers MUST allow...' RFC 2119 keyword, line 439: '... homenet routers MUST NOT answer queri...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'CITE' on line 483 == Unused Reference: '13' is defined on line 583, 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-01 == 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-10 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Barefoot Consulting 4 Intended status: Informational D. Migault 5 Expires: May 3, 2018 Ericsson 6 S. Cheshire 7 Apple Inc. 8 October 30, 2017 10 Simple Homenet Naming and Service Discovery Architecture 11 draft-ietf-homenet-simple-naming-00 13 Abstract 15 This document describes a simple name resolution and service 16 discovery architecture for homenets, using the 'home.arpa' domain 17 name hierarchy. This architecture covers local publication of names, 18 as well as name resolution service for local and global names for 19 devices connected to the homenet. 21 This document does not cover discovery of homenet services by devices 22 not connected to the homenet, nor DNSSEC, nor acquisition and 23 configuration of a global name as an alternative to 'home.arpa'. 24 These topics will be addressed in a separate document. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 3, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Existing solutions . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Configuring Resolvers . . . . . . . . . . . . . . . . . . 5 65 3.2. DNS Service Discovery Registration Protocol . . . . . . . 6 66 3.3. Configuring Service Discovery . . . . . . . . . . . . . . 6 67 3.4. Resolution of local names . . . . . . . . . . . . . . . . 8 68 3.5. Globally Unique Name . . . . . . . . . . . . . . . . . . 10 69 3.6. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 10 70 3.7. Support for Multiple Provisioning Domains . . . . . . . . 10 71 3.8. Using the Local Namespace While Away From Home . . . . . 11 72 4. Management Considerations . . . . . . . . . . . . . . . . . . 11 73 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 76 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 This document describes a simple architecture for providing name 82 service and service discovery for homenets. This allows hosts 83 connected to the homenet to use the Domain Name System to discover 84 services and the hosts providing those services, whether they are on 85 the home network or the Internet. In addition, the architecture 86 provides a way for hosts connected to the homenet that provide 87 services to advertise those services for discovery by other homenet 88 hosts. 90 This simple architecture is intended to serve as a foundational 91 architecture for naming on home networks. It is expected that all 92 Homenet routers will implement this architecture. It satisfies a 93 subset of the requirements listed in IPv6 Home Networking 94 Architecture Principles [7], and provides a foundation for completely 95 addressing those requirements. 97 This simple architecture leaves the following requirements from 98 RFC7368 Section 3.7 unaddressed: 100 o Acquisition of a global name for the homenet, to be used in place 101 of 'home.arpa.' 103 o Delegation of public reverse trees for prefixes delegated to the 104 homenet: subdomains of 'ip6.arpa' and 'in-addr.arpa'. 106 o Publication of names on the homenet for general public use on the 107 internet. 109 o Publication of names on the homenet for use by authorized users of 110 the homenet when connected to other networks. 112 o Secure delegation, enabling DNSSEC validation of names published 113 on the homenet. 115 A later document will describe additional functionality that can be 116 implemented on more capable home network routers, so that a home 117 network that has at least one such router, and one or more routers 118 that only implement the architecture described in this document, can 119 work together to provide the full feature set described in RFC 7368. 121 In general, the set of capabilities required to discover services on 122 any network are: 124 o A domain name that represents the network, under which names can 125 be published and services advertised 127 o The ability to publish names that identify hosts and services. 129 o Advertising locally available services by publishing resource 130 records. 132 o A service that can be queried for names and resources records in 133 order to discover and use services. 135 o Advertisement of that service so that hosts can send queries to 136 it. 138 o Timely removal of published names and resource records when they 139 are no longer in use 141 A simple homenet naming architecture adds the following 142 considerations: 144 1. Users cannot be assumed to be skilled or knowledgeable in name 145 service operation, or even to have any sort of mental model of 146 how these functions work. All of the operations mentioned here 147 must reliably function automatically, without any user 148 intervention or debugging. 150 2. Because user intervention cannot be required, naming conflicts 151 must be resolved automatically, and, to the extent possible, 152 transparently. 154 3. Hosts are not required to implement any homenet-specific 155 capabilities in order to discover and access services on the 156 homenet. 158 4. Devices that provide services must be able to publish those 159 services on the homenet, and those services must be available 160 from any part of the homenet, not just the link to which the 161 device is attached. 163 5. Homenet explicitly supports multihoming: connecting to more than 164 one Internet Service Provider. It therefore must address the 165 problem of multiple provisioning domains [8], in the sense that 166 the DNS may give a different answer depending on whether caching 167 resolvers at one ISP or another are queried. 169 1.1. Existing solutions 171 Previous attempts to automate naming and service discovery in the 172 context of a home network are able to function with varying degrees 173 of success depending on the topology of the home network. 174 Unfortunately, these solutions do not fully address the requirements 175 of homenets. 177 For example, Multicast DNS [5] can provide naming and service 178 discovery [6], but only within a single multicast domain. 180 The Domain Name System provides a hierarchical namespace [1], a 181 mechanism for querying name servers to resolve names [2], a mechanism 182 for updating namespaces by adding and removing names [4], and a 183 mechanism for discovering services [6]. Unfortunately, DNS provides 184 no mechanism for automatically provisioning new namespaces, and 185 secure updates to namespaces require that the host submitting the 186 update have a public or symmetric key that is known to the network 187 and authorized for updates. In an unmanaged network, the publication 188 of and authorization of these keys is an unsolved problem. 190 Some managed networks get around this problem by having the DHCP 191 server do DNS updates. However, this doesn't really work, because 192 DHCP doesn't provide a mechanism for updating service discovery 193 records: it only supports publishing A and AAAA records. 195 This partially solves the trust problem: DHCP can validate that a 196 device is at least connected to a network link that is actually part 197 of the managed network. This prevents an off-network attacker from 198 registering a name, but provides no mechanism for actually validating 199 the identity of the host registering the name. For example, it would 200 be easy for an attacker on the network to steal a registered name. 202 Hybrid Multicast DNS [10] proposes a mechanism for extending 203 multicast DNS beyond a single multicast domain. However, in order to 204 use this as a solution, some shortcomings need to be considered. 205 Most obviously, it requires that every multicast domain have a 206 separate name. This then requires that the homenet generate names 207 for every multicast domain. These names would then be revealed to 208 the end user. But since they would be generated automatically and 209 arbitrarily, they would likely cause confusion rather than clarity, 210 and in degenerate cases requires that the end user have a mental 211 model of the topology of the network in order to guess on which link 212 a given service may appear. 214 At present, the approach we intend to take with respect to 215 disambiguation is that this will not be solved at a protocol level 216 for devices that do not implement the registration protocol. 218 2. Terminology 220 This document uses the following terms and abbreviations: 222 HNR Homenet Router 224 ISP Internet Service Provider 226 3. Name Resolution 228 3.1. Configuring Resolvers 230 Hosts on the homenet receive a set of resolver IP addresses using 231 either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of 232 resolvers, if available, over DHCP. IPv6-only hosts will receive 233 resolver IPv6 addresses using either stateful (if available) or 234 stateless DHCPv6, or through the Recursive DNS Server Option ([9], 235 Section 5.1) in router advertisements. 237 All Homenet routers provide resolver information using both stateless 238 DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is optional, 239 however if either service is offered, resolver addresses will be 240 provided using that mechanism as well. 242 3.2. DNS Service Discovery Registration Protocol 244 The DNSSD Service Registration protocol [12] requires that DNS 245 updates be validated on the basis that they are received on the local 246 link. To ensure that such registrations are actually received on 247 local links in the homenet, updates are sent to the local relay proxy 248 ([11]) (XXX how?). 250 The relay proxy encapsulates the update and sends it to whatever 251 Discovery Proxy is listening on the link; the Discovery proxy then 252 either consumes the update directly, or forwards it to the 253 authoritative resolver for the local service discovery zone. If the 254 registration protocol is not supported on the homenet, the Discovery 255 Proxy rejects the update with a ??? RCODE. 257 3.3. Configuring Service Discovery 259 Clients discovering services using DNS-SD [6] follow a two-step 260 process. The first step is for the client device to determine in 261 which domain(s) to attempt to discover services. The second step is 262 for the client device to then seek desired service(s) in those 263 domain(s). For an example of the second step, given the desired 264 service type "IPP Printing", and the domains "local" and 265 "meeting.ietf.org", the client device forms the queries 266 "_ipp._tcp.local. PTR ?" (resolved using Multicast DNS) and 267 "_ipp._tcp.meeting.ietf.org PTR. ?" (resolved using Unicast DNS) and 268 then presents the combined list of results to the user. 270 The first step, determining in which domain(s) to attempt to discover 271 services, is performed in a variety of ways, as described in 272 Section 11 of the DNS-Based Service Discovery specification [6]. 274 The domain "local" is generally always in the set of domains in which 275 the client devices attempt to discover services, and other domains 276 for service discovery may be configured manually by the user. 278 The device also learns additional domains automatically from its 279 network environment. For this automatic configuration discovery, 280 special DNS queries are formulated. To learn additional domain(s) in 281 which to attempt to discover services, the query string 282 "lb._dns_sd._udp" is prepended onto three different kinds of 283 "bootstrap domain" to form DNS queries that allow the device to learn 284 the configuration information. 286 One of these bootstrap domains is the fixed string "local". The 287 device issues the query "lb._dns_sd._udp.local. PTR ?" (resolved 288 using Multicast DNS), and if any answers are received, then they are 289 added to the set of domains in which the client devices attempt to 290 discover services. 292 Another kind of these bootstrap domains is name-based, derived from 293 the DHCPv4 "domain name" option (code 15) [3] (for IPv4) or the DNS 294 Search List (DNSSL) Router Advertisement option [9] (for IPv6). If a 295 domain in the DNSSL is "example.com", then the device issues the 296 query "lb._dns_sd._udp.example.com. PTR ?" (resolved using Unicast 297 DNS), and if any answers are received, then they are likewise added 298 to the set of domains in which the client devices attempt to discover 299 services. 301 Finally, the third kind of bootstrap domain is address-based, derived 302 from the device's IP address(es) themselves. If the device has IP 303 address 192.168.1.100/24, then the device issues the query 304 "lb._dns_sd._udp.0.1.168.192.in-addr.arpa. PTR ?" (resolved using 305 Unicast DNS), and if any answers are received, then they are also 306 added to the set of domains in which the client devices attempt to 307 discover services. 309 Since there is an HNR on every link of a homenet, automatic 310 configuration could be performed by having HNRs answer the 311 "lb._dns_sd._udp.local. PTR ?" (Multicast DNS) queries. However, 312 because multicast is slow and unreliable on many modern network 313 technologies like Wi-Fi, we prefer to avoid using it. Instead we 314 require that a homenet be configured to answer the name-based 315 bootstrap queries. By default the domain in the DNSSL communicated 316 to the client devices will be "home.arpa", and the homenet will be 317 configured to correctly answer queries such as 318 "lb._dns_sd._udp.example.com. PTR ?", though client devices must not 319 assume that the name will always be "home.arpa". A client could be 320 configured with any valid DNSSL, and should construct the appropriate 321 bootstrap queries derived from the name(s) in their configured DNS 322 Search List. 324 HNRs will answer domain enumeration queries against every IPv4 325 address prefix advertised on a homenet link, and every IPv6 address 326 prefix advertised on a homenet link, including prefixes derived from 327 the homenet's ULA(s). Whenever the "" sequence appears in 328 this section, it references each of the domains mentioned in this 329 paragraph. 331 Homenets advertise the availability of several browsing zones in the 332 "b._dns_sd._udp." subdomain. By default, the 'home.arpa' 333 domain is advertised. Similarly, 'home.arpa' is advertised as the 334 default browsing and service registration domain under 335 "db._dns_sd._udp.", "r._dns_sd._udp.", 336 "dr._dns_sd._udp." and "lb._dns_sd._udp.". 338 In order for this discovery process to work, the homenet must provide 339 authoritative answers for each of the domains that might be queried. 340 To do this, it provides authoritative name service for the 'ip6.arpa' 341 and 'in-addr.arpa' subdomains corresponding to each of the prefixes 342 advertised on the homenet. For example, consider a homenet with the 343 192.168.1.0/24, 2001:db8:1234:5600::/56 and fc01:2345:6789:1000::/56 344 prefixes. This homenet will have to provide a name server that 345 claims to be authoritative for 1.168.192.in-addr.arpa, 346 6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa and 347 0.0.9.8.7.6.5.4.3.2.1.0.c.f.ip6.arpa. 349 An IPv6-only homenet would not have an authoritative server for a 350 subdomain of in-addr.arpa. These public authoritative zones are 351 required for the public prefixes even if the prefixes are not 352 delegated. However, they need not be accessible outside of the 353 homenet. 355 It is out of the scope of this document to specify ISP behavior, but 356 we note that ISPs have the option of securely delegating the zone, or 357 providing an unsigned delegation, or providing no delegation. Any 358 delegation tree that does not include an unsigned delegation at or 359 above the zone cut for the ip6.arpa reverse zone for the assigned 360 prefix will fail to validate. 362 Ideally, an ISP should provide a secure delegation using a zone- 363 signing key provided by the homenet. However, that too is out of 364 scope for this document. Therefore, an ISP that wishes to support 365 users of the simple homenet naming architecture will have to provide 366 an unsigned delegation. We do not wish, however, to discourage 367 provisioning of signed delegations when that is possible. 369 3.4. Resolution of local names 371 By default, Local names appear as subdomains of 'home.arpa'. These 372 names can only be resolved within the homenet; not only is 373 'home.arpa' not a globally unique name, but queries from outside of 374 the homenet for any name, on or off the homenet, must be rejected 375 with a REFUSED response. The intended use case for local names is 376 that hosts will attempt to discover or contact other hosts on the 377 homenet that are offering services. 379 In addition, names of devices on the homenet can appear in the 380 resource records of names that are subdomains of the locally-served 381 'in-addr.arpa' or 'ip6.arpa zone that corresponding to the RFC1918 382 IPv4 prefix and the IPv6 ULA that is in use on the homenet. Names 383 ending in 'home.arpa' should never appear in RRDATA for names that 384 are subdomains of reverse mappings for global IP addresses. This 385 should not cause operational problems, since connections between 386 devices on the homenet can be expected to use addresses in the 387 homenet's ULA prefix. 389 ISP-provided addresses cannot be assumed to be stable. Not only is 390 it possible that the ISP policy is to change addresses over time, but 391 the connection to the ISP may not always be available. The homenet's 392 ULA prefix and RFC1918 prefix, however, can be assumed to be stable. 393 Therefore, IP addresses and names advertised locally MUST use 394 addresses in the homenet's ULA prefix and/or RFC1918 prefix. 396 It is possible that local services may offer services available on IP 397 addresses in public as well as ULA prefixes. Homenet hybrid proxies 398 MUST filter out global IP addresses, providing only ULA addresses, 399 similar to the process described in section 5.5.2 of [10]. 401 This filtering applies to queries within the homenet; it is 402 appropriate for non-ULA addresses to be used for offering services, 403 because in some cases end users may want such services to be 404 reachable outside of the homenet. Configuring this is however out of 405 scope for this document. 407 The Hybrid Proxy model relies on each link having its own name. 408 However, homenets do not actually have a way to name local links that 409 will make any sense to the end user. Consequently, this mechanism 410 will not work without some tweaks. In order to address this, 411 homenets will use Discovery Brokers [16]. The discovery broker will 412 be configured so that a single query for a particular service will be 413 successful in providing the information required to access that 414 service, regardless of the link it is on. 416 Artificial link names will be generated using HNCP. These should 417 only be visible to the user in graphical user interfaces in the event 418 that the same name is claimed by a service on two links. Services 419 that are expected to be accessed by users who type in names should 420 use [12] if it is available. 422 Homenets are not required to support Service Registration. Service 423 registration requires a stateful authoritative DNS server; this may 424 be beyond the capability of the minimal Homenet router. However, 425 more capable Homenet routers should provide this capability. In 426 order to make this work, minimal Homenet routers MUST implement the 427 split hybrid proxy [11]. This enables a Homenet with one or more 428 Homenet routers that provide a stateful registration cache to allow 429 those routers to take over service, using Discovery Relays to service 430 links that are connected using Homenet routers with more limited 431 functionality. 433 3.5. Globally Unique Name 435 Automatic configuration of a globally unique name for the homenet is 436 out of scope for this document. However, homenet servers MUST allow 437 the user to configure a globally unique name in place of the default 438 name, 'home.arpa.' By default, even if configured with a global 439 name, homenet routers MUST NOT answer queries from outside of the 440 homenet for subdomains of that name. 442 3.6. DNSSEC Validation 444 DNSSEC Validation for the 'home.arpa' zone and for the locally-served 445 'ip6.arpa and 'in-adr.arpa' domains is not possible without a trust 446 anchor. Establishment of a trust anchor for such validation is out 447 of scope for this document. 449 Homenets that have been configured with a globally unique domain MUST 450 support DNSSEC signing of local names, and must provide a way to 451 generate a KSK that can be used in the secure delegation of the 452 globally unique domain assigned to the homenet. 454 3.7. Support for Multiple Provisioning Domains 456 Homenets must support the Multiple Provisioning Domain Architecture 457 [8]. Hosts connected to the homenet may or may not support multiple 458 provisioning domains. For hosts that do not support multiple 459 provisioning domains, the homenet provides one or more resolvers that 460 will answer queries for any provisioning domain. Such hosts may 461 receive answers to queries that either do not work as well if the 462 host chooses a source address from a different provisioning domain, 463 or does not work at all. However, the default source address 464 selection policy, longest-match [CITE], will result in the correct 465 source address being chosen as long as the destination address has a 466 close match to the prefix assigned by the ISP. 468 Hosts that support multiple provisioning domains will be provisioned 469 with one or more resolvers per provisioning domain. Such hosts can 470 use the IP address of the resolver to determine which provisioning 471 domain is applicable for a particular answer. 473 Each ISP has its own provisioning domain. Because ISPs connections 474 cannot be assumed to be persistent, the homenet has its own separate 475 provisioning domain. 477 Configuration from the IPv4 DHCP server are treated as being part of 478 the homenet provisioning domain. The case where a homenet advertises 479 IPv4 addresses from one or more public prefixes is out of scope for 480 this document. Such a configuration is NOT RECOMMENDED for homenets. 482 Configuration for IPv6 provisioning domains is done using the 483 Multiple Provisioning Domain RA option [CITE]. 485 3.8. Using the Local Namespace While Away From Home 487 This architecture does not provide a way for service discovery to be 488 performed on the homenet by devices that are not directly connected 489 to a link that is part of the homenet. 491 4. Management Considerations 493 This architecture is intended to be self-healing, and should not 494 require management. That said, a great deal of debugging and 495 management can be done simply using the DNS Service Discovery 496 protocol. 498 5. Privacy Considerations 500 Privacy is somewhat protected in the sense that names published on 501 the homenet are only visible to devices connected to the homenet. 502 This may be insufficient privacy in some cases. 504 The privacy of host information on the homenet is left to hosts. 505 Various mechanisms are available to hosts to ensure that tracking 506 does not occur if it is not desired. However, devices that need to 507 have special permission to manage the homenet will inevitably reveal 508 something about themselves when doing so. It may be possible to use 509 something like HTTP token binding [14] to mitigate this risk. 511 6. Security Considerations 513 There are some clear issues with the security model described in this 514 document, which will be documented in a future version of this 515 section. A full analysis of the avenues of attack for the security 516 model presented here have not yet been done, and must be done before 517 the document is published. 519 7. IANA considerations 521 No new actions are required by IANA for this document. 523 Note however that this document is relying on the allocation of 524 'home.arpa' described in Special Use Top Level Domain '.home.arpa' 526 [15]. This document therefore can't proceed until that allocation is 527 done. [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH PRIOR TO 528 PUBLICATION]. 530 8. Normative References 532 [1] Mockapetris, P., "Domain names - concepts and facilities", 533 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 534 . 536 [2] Mockapetris, P., "Domain names - implementation and 537 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 538 November 1987, . 540 [3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 541 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 542 . 544 [4] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 545 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 546 RFC 2136, DOI 10.17487/RFC2136, April 1997, 547 . 549 [5] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 550 DOI 10.17487/RFC6762, February 2013, 551 . 553 [6] Cheshire, S. and M. Krochmal, "DNS-Based Service 554 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 555 . 557 [7] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 558 Weil, "IPv6 Home Networking Architecture Principles", 559 RFC 7368, DOI 10.17487/RFC7368, October 2014, 560 . 562 [8] Anipko, D., Ed., "Multiple Provisioning Domain 563 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 564 . 566 [9] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 567 "IPv6 Router Advertisement Options for DNS Configuration", 568 RFC 8106, DOI 10.17487/RFC8106, March 2017, 569 . 571 [10] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 572 Service Discovery", draft-ietf-dnssd-hybrid-07 (work in 573 progress), September 2017. 575 [11] Cheshire, S. and T. Lemon, "Multicast DNS Discovery 576 Relay", draft-sctl-dnssd-mdns-relay-01 (work in progress), 577 October 2017. 579 [12] Cheshire, S. and T. Lemon, "Service Registration Protocol 580 for DNS-Based Service Discovery", draft-sctl-service- 581 registration-00 (work in progress), July 2017. 583 [13] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 584 for multiple provisioning domains in IPv6 Neighbor 585 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 586 (work in progress), February 2016. 588 [14] Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 589 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 590 tokbind-https-10 (work in progress), July 2017. 592 [15] Pfister, P. and T. Lemon, "Special Use Domain 593 'home.arpa.'", draft-ietf-homenet-dot-14 (work in 594 progress), September 2017. 596 [16] Cheshire, S. and T. Lemon, "Service Discovery Broker", 597 draft-sctl-discovery-broker-00 (work in progress), July 598 2017. 600 Authors' Addresses 602 Ted Lemon 603 Barefoot Consulting 604 Brattleboro, Vermont 05301 605 United States of America 607 Email: mellon@fugue.com 609 Daniel Migault 610 Ericsson 611 8400 boulevard Decarie 612 Montreal, QC H4P 2N2 613 Canada 615 Email: daniel.migault@ericsson.com 616 Stuart Cheshire 617 Apple Inc. 618 1 Infinite Loop 619 Cupertino, California 95014 620 USA 622 Phone: +1 408 974 3207 623 Email: cheshire@apple.com