idnits 2.17.1 draft-ietf-homenet-simple-naming-03.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 4 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 788: '... [RFC7788]. HNRs MUST NOT use pre-installed keys: each HNR MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2018) is 2005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7336' is defined on line 1034, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-dnsop-session-signal-16 == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-08 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-15 == Outdated reference: A later version (-11) exists of draft-ietf-intarea-provisioning-domains-03 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-02 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nibbhaya Consulting 4 Intended status: Informational D. Migault 5 Expires: April 26, 2019 Ericsson 6 S. Cheshire 7 Apple Inc. 8 October 23, 2018 10 Homenet Naming and Service Discovery Architecture 11 draft-ietf-homenet-simple-naming-03 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 April 26, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Managed LAN versus Homenet . . . . . . . . . . . . . . . 4 58 2.1.1. Multiple Provisioning Domains . . . . . . . . . . . . 5 59 2.2. Homenet-specific considerations . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. Reachability . . . . . . . . . . . . . . . . . . . . . . 8 64 5.2. Link Names . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.3. Authoritative name service for the homenet domain . . . . 9 66 5.4. Authoritative name service for per-link subdomains of the 67 homenet domain . . . . . . . . . . . . . . . . . . . . . 10 68 5.5. Authoritative name service for the ULA reverse mapping 69 domain . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.6. Authoritative name service for the RFC1918 reverse 71 mapping domains . . . . . . . . . . . . . . . . . . . . . 10 72 6. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Round Robining . . . . . . . . . . . . . . . . . . . . . 13 74 6.2. Retransmission . . . . . . . . . . . . . . . . . . . . . 13 75 6.3. DNS Stateful Operations and DNS Push . . . . . . . . . . 13 76 6.4. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 14 77 6.5. Host behavior . . . . . . . . . . . . . . . . . . . . . . 14 78 7. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. DNSSD Service Registration Protocol . . . . . . . . . . . 14 80 7.2. Homenet Reverse Mapping Update Protocol . . . . . . . . . 15 81 7.2.1. Adding ULA reverse mappings . . . . . . . . . . . . . 15 82 7.2.2. Adding RFC1918 reverse mappings . . . . . . . . . . . 16 83 8. Host Configuration . . . . . . . . . . . . . . . . . . . . . 16 84 9. Globally Unique Names . . . . . . . . . . . . . . . . . . . . 16 85 10. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . . . 17 86 10.1. How trust is established . . . . . . . . . . . . . . . . 17 87 11. Homenet Delegation Registration Protocol . . . . . . . . . . 18 88 12. Using the Local Namespace While Away From Home . . . . . . . 19 89 13. Expected Host Behavior . . . . . . . . . . . . . . . . . . . 19 90 14. Management Considerations . . . . . . . . . . . . . . . . . . 19 91 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 92 16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 93 17. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 94 17.1. Homenet Reverse Registration Protocol . . . . . . . . . 20 95 17.2. Homenet Delegation Registration Protocol . . . . . . . . 20 96 17.3. Unique Local Address Reserved Documentation Prefix . . . 21 98 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 18.1. Normative References . . . . . . . . . . . . . . . . . . 21 100 18.2. Informative References . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Introduction 105 This document is a homenet architecture document. The term 'homenet' 106 refers to a set of technologies that allow home network users to have 107 a local-area network (LAN) with more than one physical link and, 108 optionally, more than one internet service provider. Home network 109 users are assumed not to be knowledgeable in network operations, so 110 homenets automatically configure themselves, providing connectivity 111 and service discovery within the home with no operator intervention. 112 This document describes the aspect of homenet automatic configuration 113 that has to do with service discovery and name resolution. 115 This architecture provides a minimal set of features required to 116 enable seamless service discovery on a multi-link home network, but 117 does not attempt to provide feature parity with a managed LAN. 119 This document begins by presenting a motivational list of 120 requirements and considerations, which should give the reader a clear 121 idea of the scope of the problem being solved. It then explains how 122 each requirement is addressed, and provides references for relevant 123 standards documents describing the details of the implementation. 124 Not all requirements are addressed by this architecture document, but 125 the basic requirements are satisfied, and this document serves as a 126 foundation upon which solutions to the remaining problems can be 127 built. 129 2. Requirements 131 Name service on a local area network (LAN) requires the following: 133 o Name: a forward domain under which information about local 134 services will be published 136 o Authority: a name server that is authoritative for at least one 137 forward domain and one or two reverse domains that are applicable 138 to that network and is capable of signing and publishing the zones 139 using DNSSEC 141 o Resolution: a full-service caching DNS resolver that fully 142 supports EDNS(0) and queries with the DO bit set 144 o Publication: a mechanism that 145 * allows services on the LAN to publish information about the 146 services they provide 148 * allows services to publish information on how to reach them 150 * manages the lifetime of such information, so that it persists 151 long enough to prevent spoofing, but protects end users from 152 seeing stale information 154 o Host configuration: one or more automatic mechanisms (e.g. DHCP 155 or RA) that provide: 157 * caching resolver information to hosts on the LAN 159 * information about how services on the LAN can publish 160 information 162 o Trust: some basis for trusting the information that is provided by 163 the service discovery system 165 2.1. Managed LAN versus Homenet 167 A managed network is one that has a (human) manager, or operator. 168 The operator has authority over the network, and the authority to 169 publish names in a forward DNS tree, and reverse names in the reverse 170 tree. The operator has the authority to sign the respective trees 171 with DNSSEC, and acquire TLS certificates for hosts/servers within 172 the network. 174 On a managed LAN, many of these services can be provided by 175 operators. When a new printer is added to the network, it can be 176 added to the service discovery system (the authoritative server) 177 manually. When a printer is taken out of service, it can be removed. 178 In this scenario, the role of "publisher" is filled by the network 179 operator. 181 In many managed LANs, establishment of trust for service discovery is 182 simply on the basis of a belief that the local resolver will give a 183 correct answer. Once the service has been discovered and chosen, 184 there may be some security (e.g., TLS) that protects the connection 185 to the service, but the trust model is often just "you're connected 186 to a network you trust, so you can trust the printer that you 187 discovered on this network." 189 A homenet does not have an operator, so functions that would normally 190 be performed by the operator have to happen automatically. This has 191 implications for trust establishment--since there is no operator 192 controlling what services are published locally, some other mechanism 193 is required for basic trust establishment. 195 2.1.1. Multiple Provisioning Domains 197 Additionally, whereas in a managed LAN with multiple links to the 198 Internet, the network operator can configure the network so that 199 multihoming is handled seamlessly, in a homenet, multihoming must be 200 handled using multiple provisioning domains [RFC7556]. 202 When a host on a homenet connects to a host outside the homenet, and 203 the homenet is multihomed, the source address that the host uses for 204 connecting determines which upstream ISP connection is used. In 205 principle, this is not a problem, because the Internet is a fully 206 connected network, so any host that is on the Internet can be reached 207 by any host on the Internet, regardless of how that host connects to 208 the Internet. 210 Unfortunately in practice this is not always the case. Some ISPs 211 provide special services to their end users that are only accessible 212 when connected through the ISP. When such a service is discovered 213 using that ISP's name server, a response will be provided that will 214 only work if the host connects using a prefix provided by that ISP. 215 If another ISP's prefix is used, the connection will fail. 217 In the case of content delivery networks (CDNs), using the name 218 service of one ISP and then connecting through a second ISP may seem 219 to work, but may provide very poor service. 221 In order to address this problem, the homenet naming architecture 222 takes two approaches. First, for hosts that do not support 223 provisioning domain separation, we make sure that all ISP name 224 servers are consulted in such a way that Happy Eyeballs will tend to 225 work. Second, for hosts that do support provisioning domain 226 separation, we provide information to the hosts to identify 227 provisioning domains, and we provide a mechanism that hosts can use 228 to indicate which provisioning domain to use for a particular DNS 229 query. 231 2.2. Homenet-specific considerations 233 A naming architecture for homenets therefore adds the following 234 considerations: 236 o All of the operations mentioned here must reliably function 237 automatically, without any user intervention or debugging. 239 o Because user intervention cannot be required, naming conflicts 240 must be resolved automatically, and, to the extent possible, 241 transparently. 243 o Devices that provide services must be able to publish those 244 services on the homenet, and those services must be available from 245 any part of the homenet, not just the link to which the device is 246 attached. 248 o Homenets must address the problem of multiple provisioning 249 domains, in the sense that the DNS may give a different answer 250 depending on whether caching resolvers at one ISP or another are 251 queried. 253 An additional requirement from the Homenet Architecture [RFC7556] is 254 that hosts are not required to implement any homenet-specific 255 capabilities in order to discover and access services on the homenet. 256 This architecture may define optional homenet-specific features, but 257 hosts that do not implement these features must work on homenets. 259 3. Terminology 261 This document uses the following terms and abbreviations: 263 HNR Homenet Router 265 SHNR Homenet Router implementing simple homenet naming architecture 267 AHNR Homenet Router implementing advanced homenet naming 268 architecture 270 ISP Internet Service Provider 272 Forward Mapping A mapping between a host name or service name and 273 some information about that host or service. 275 Reverse Mapping A mapping between an IP address and the host that 276 has that IP address. 278 Homenet Domain A domain name that is used for publishing the names 279 of devices and services that are present on the homenet. By 280 default, 'home.arpa.' 282 4. Name 284 In order for names to be published on a homenet, it is necessary that 285 there be a set of domain names under which such names are published. 286 These domain names, together, are referred to as the "local domains." 287 By default, homenets publish names for forward lookups under the 288 reserved domain 'home.arpa.' [RFC8375] publishing names. 290 So a host called 'example' that published its name on the homenet 291 would publish its records on the domain name 'example.home.arpa.'. 292 Because 'home.arpa.' is used by all homenets, it has no global 293 meaning, and names published under the domain 'home.arpa' cannot be 294 used outside of the homenet on which they are published. 296 How to publish names outside of the homenet is out of scope for this 297 document. However, in order to address the problem of validating 298 names published on the homenet using DNSSEC, it is necessary that the 299 homenet have a globally valid delegation from the root. This allows 300 hosts on the homenet to validate names published on the homenet using 301 the DNS root trust anchor ([RFC4033] section 3.1). 303 It is not necessary that this delegation work for hosts off the 304 homenet. HNRs implementing this specification do not answer queries 305 from outside the homenet; however, when a validating resolver inside 306 the homenet attempts to validate the chain of trust up to the root 307 zone, the chain of trust will validate correctly, because the answer 308 given for internally-available zones will be signed by a DS record 309 that is present in the delegation externally. 311 If there is a valid delegation from the root, the homenet domain will 312 be the name of the delegated domain. By default, there will be no 313 delegation from the root; in this case, the homenet domainname will 314 be 'home.arpa.' 316 In addition to the homenet domain, names are needed for reverse 317 lookups. These names are dependent on the IP addressing used on the 318 homenet. If the homenet is addressed with IPv4, a reverse domain 319 corresponding to the IPv4 subnet [RFC1034] section 5.2.1 should be 320 constructed. For example, if the homenet is allocating local IP 321 addresses out of net 10 [RFC1918], a domain, '10.in-addr.arpa' would 322 be required. Like 'home.arpa.', '10.in-addr.arpa' is a locally- 323 served zone, and has no validity outside of the homenet. 325 If the homenet is addressed with IPv6, it is expected to have a 326 unique local address prefix. The reverse mapping domain for hosts on 327 any link in the subnet will be a subdomain of the reverse zone for 328 the subset of the ULA prefix that is being advertised on that link. 329 Every service on the homenet that supports IPv6 is expected to be 330 reachable at an address that is configured using the ULA prefix. 331 Therefore there is no need for any IPv6 reverse zone to be populated 332 other than the ULA zone. So for example if the homenet's ULA prefix 333 is fc00:2001:db8::/48, then the reverse domain name for the homenet 334 would end in '8.b.d.0.1.0.0.2.0.0.d.f.ip6.arpa'. 336 5. Authority 338 There are two types of authoritative name service on the homenet. 339 Every link on the homenet has a zone that is a subdomain of the 340 homenet's primary domain. Authority for these zones is local to the 341 HNR that is currently authoritative for that zone. The contents of 342 these zones are served using DNSSD Discovery Proxy 343 [I-D.ietf-dnssd-hybrid]. Consequently, there is no need for database 344 replication in the case that a new HNR is elected; that HNR simply 345 takes over the Discovery Relay function. 347 Name service for the homenet domain itself may be stateless or 348 stateful. HNRs are not required to implement stateful service. If 349 one or more HNRs on the homenet are capable of providing this 350 service, then one of those HNRs is elected to act as the primary 351 nameserver for the homenet domain; one or more HNRs may also act as 352 secondary servers. 354 Name service for reverse mapping subdomains is only provided if one 355 or more HNRs can provide stateful service. If no such server is 356 present, the reverse mapping subdomains are not served. If stateful 357 servers are present, the primary and secondary servers for these 358 subdomains will be the same as for the homenet domain. 360 5.1. Reachability 362 Whether the homenet domain is a global domain name or not, HNRs 363 answering queries for domains on the homenet do not respond to 364 queries from off the homenet unless configured to do so. Exposing 365 services on the homenet for browsing off the homenet creates many 366 opportunities for security issues; as such, even an HNR configured to 367 answer queries from prefixes off the homenet do not provide answers 368 for names of devices on the homenet unless configured to do so. How 369 reachability of names published on the homenet is managed is out of 370 scope for this document: an HNR implementing only this document 371 checks the source address of every query to see if it is within a 372 prefix belonging to the homenet; if not, the HNR does not answer the 373 query. 375 5.2. Link Names 377 Each link must have a name. These names are determined using HNCP. 378 Each router will have zero or more wired links, each of which must be 379 labeled. In addition, each router will have zero or more wireless 380 links. Each of these links will be named by the frequency band the 381 link supports, 2.4ghz or 5ghz. 383 The HNR is named using its manufacturer name. If, as is likely, two 384 or more HNRs from the same manufacturer are present on a homenet, 385 then the HNR name is made up of the manufacturer name plus as many 386 hexadecimal digits as are required from the HNRs link layer addresses 387 so as to disambiguate them. 389 When shipping multiple HNRs as a kit, manufacturers are advised to 390 arrange that each HNR has a different number in the lowest four bits 391 of the link-layer address. Manufacturers are also advised to print 392 that link layer address, in full, somewhere on the outside of the HNR 393 where it can be seen by the user. Since most HNRs will have more 394 than one interface, the manufacturer should be consistent in choosing 395 which link-layer address is printed on the outside and used to 396 identify the router. 398 The name given to a link is the name of the HNR, plus a hyphen ('-'), 399 plus name of the interface of that HNR that is attached to the link. 400 In the event that this name must be displayed to the user, this 401 should give the user enough information to figure out which link is 402 being referenced. In the event that the HNR that is providing 403 authoritative service for that link changes, the link name changes. 404 This should only happen if the network topology changes. 406 If the appearance of a new HNR requires that the name of an existing 407 HNR change, then the names of all the links managed by that existing 408 HNR change to reflect the new name. 410 5.3. Authoritative name service for the homenet domain 412 All HNRs must be capable of providing authoritative name service for 413 the homenet domain. HNRs that provide only stateless authoritative 414 service publish the information that is required for hosts to do DNS 415 Service Discovery over DNS, using the local resolver as a DNSSD 416 Discovery Broker. 418 Some contents are required for the homenet domain, whether it is 419 stateful or stateless. 421 o Every link on the homenet has a name that is a subdomain of the 422 homenet domain. The zone associated with the homenet domain 423 contains a delegation for each of these subdomains. 425 o In order for DNSSD service discovery to work, a default browsing 426 domain must be published. The default browsing domain is simply 427 the homenet domain. 429 o If DNSSD SRP is supported (that is, if stateful authoritative 430 service is present), then an SRV record must be published, along 431 with a list of available registration zones containing exactly one 432 entry, for the homenet domain ([I-D.sctl-service-registration] 433 section 2). 435 o Also if DNSSD SRP is supported, then one or more A and/or AAAA 436 records must be published under the name that the SRV record 437 points to, which should be a single label subdomain of the homenet 438 domain. 440 Both stateful and stateless authoritative servers provided by HNRs 441 must support DNS Stateful Operations [I-D.ietf-dnsop-session-signal] 442 and DNS Push [I-D.ietf-dnssd-push] for the names for which they are 443 authoritative. 445 5.4. Authoritative name service for per-link subdomains of the homenet 446 domain 448 Per-link subdomains of the homenet domain are served by DNSSD 449 Discovery Proxies. Although these proxies generally do caching, no 450 long-lived state is kept by them. DNSSD Discovery Proxies running on 451 HNRs must support DNS Stateful Operations and DNS Push. 453 5.5. Authoritative name service for the ULA reverse mapping domain 455 The ULA reverse mapping domain itself is only published if stateful 456 name service is available. It is represented as a single zone, which 457 contains no delegations: every reverse mapping for an address in the 458 ULA prefix is simply published in the ULA zone. 460 In order to permit registration of reverse mappings in this domain, 461 it must contain an SRV record for the label _homenet-rrp._tcp at the 462 top level, pointing to the primary server for the domain. 464 5.6. Authoritative name service for the RFC1918 reverse mapping domains 466 If IPv4 service is being provided on the homenet, and if stateful 467 name service is being provided on the homenet, then either one or 468 sixteen reverse mapping zones for the RFC1918 prefix in use must be 469 provided. If more than one RFC1918 prefix is in use, reverse mapping 470 zones for all such prefixes must be provided. 472 Like the ULA reverse mapping zone, the RFC1918 reverse mapping zones 473 must each contain an SRV record on the label _homenet-rrp._tcp at the 474 top level, pointing to the name of the primary server for the zone. 476 The RFC1918 reverse mapping zone contains the entire address space of 477 the RFC1918 prefix that is in use on the homenet. Section 3 of 478 RFC1918 defines three prefixes that may be used. The homenet will 479 use all of one of these three prefixes. Of these, the 172.16.0.0 480 prefix is subdivided on a 12-bit boundary, and therefore must be 481 represented as 16 separate zones. The 10.0.0.0/8 and 192.168.0.0/16 482 prefixes are each represented as a single zone. 484 The zone to be updated is therefore the 10.in-addr.arpa zone for all 485 addresses in 10.0.0.0/8, and the 168.192.in-addr.arpa zone for all 486 addresses in 192.168.0.0/16. For addresses in the 172.16.0.0/12 487 prefix, the zone to be updated is the subdomain of 172.in-addr.arpa 488 that corresponds to bits 8-11 of the prefix: a number between 16 and 489 31, inclusive. 491 Also like the ULA zone, the RFC1918 reverse mapping zones contain no 492 delegations: if there is a single zone, then every reverse mapping 493 published for an address in the RFC1918 prefix in use on the homenet 494 is published directly under this zone. If there are sixteen zones, 495 each address is published in its respective zone. Because the zone 496 172.in-addr.arpa is not available to be served locally, its locally 497 served subdomains are simply served individually with no delegation. 499 6. Resolution 501 Name resolution on the homenet must accomplish two tasks: resolving 502 names that are published on the homenet, and resolving names that are 503 published elsewhere. This is accomplished by providing several 504 functional layers. 506 1. The set of caching nameservers provided by the ISP or ISPs 507 through which the homenet gains access to the global internet, if 508 any (homenets can operate standalone as well). 510 2. The set of stateful name servers on the homenet that are 511 authoritative for the homenet domain as a whole, and for any 512 reverse mapping zones that are provided by the homenet. This 513 layer is optional, and may or may not be present. If present, it 514 is provided by one or more HNRs on the homenet that support 515 stateful service. 517 3. The set of stateless name servers on the homenet that are 518 authoritative for the homenet domain as a whole. These are not 519 used if one or more stateful servers are present. 521 4. The set of stateless DNSSD Discovery Proxies that are 522 authoritative for each of the links in the homenet. 524 5. A DNS routing proxy. Hereafter we refer to this as the DNS 525 proxy. 527 The reason that these are described as layers is that it's quite 528 possible that all of the DNS services on the homenet might be 529 provided by a single service listening on port 53; how the request is 530 routed then depends on the question being asked. So the services 531 described as running on HNRs are treated as functional blocks which 532 may be connected internally, if the question being asked can be 533 answered directly by the HNR that received it, or they may be 534 separate name servers running on different HNRs, if the question can 535 be answered within the homenet, or it may be that the HNR receiving 536 the query forwards it to an ISP caching name server. 538 The routing works as follows. When a request is received (opcode=0, 539 Q/R=0), the DNS proxy looks at the owner name in the question part of 540 the message. 542 o If the name is a subdomain of the homenet domain, the query is 543 local. 545 o If the name is a subdomain of a locally-valid ULA reverse mapping 546 domain, the query is local. 548 o If the name is a subdomain of a locally valid RFC1918 reverse 549 mapping zone, the query is local. 551 o If the name is a subdomain of any locally-served zone, as defined 552 in Locally Served DNS Zones [localzones], but is not otherwise 553 identified as local, the response is NXDOMAIN. 555 o Otherwise, the query is not local. 557 Local queries are further divided. If the query is for a link 558 subdomain, the DNS proxy consults the table that maps per-link 559 subdomains to the HNRs that serve them. Either the HNR that serves 560 this link subdomain is the HNR that received the question, or not. 561 If it is, then the DNS proxy passes the query directly to the local 562 DNSSD Discovery Proxy. Otherwise, it forwards the query to the DNSSD 563 Discovery Proxy on the HNR that is providing Discovery Proxy service 564 for that link. 566 If the query is for the homenet subdomain, and stateful authoritative 567 service for the homenet subdomain is present on the homenet, then 568 either the HNR receiving the query provides stateful authoritative 569 service, or not. If it does, then the query is passed directly to 570 the local authoritative server. If not, then the HNR looks in the 571 table of authoritative servers generated by HNCP and forwards the 572 request to one of these servers. Queries for the reverse mapping 573 zones are handled the same way. 575 Otherwise, the query is examined to see if it contains an EDNS(0) 576 Provisioning Domain option. If not, it round-robined across the 577 resolvers provided by each ISP in such a way that each ISP is tried 578 in succession, and the same ISP is not asked the same question 579 repeatedly. If the query does contain the EDNS(0) Provisioning 580 Domain option, then that option is used to select which ISP's 581 resolvers are used for the round robin. 583 6.1. Round Robining 585 There are several cases above where there may be a choice of servers 586 to which to forward queries. It's assumed that when the query can be 587 satisfied by the HNR that received it, round robining is not 588 required. If there is a specific HNR that is responsible for a 589 particular link, then round robining is likewise not required. 590 However, if the query is for a stateful authoritative server, and the 591 HNR that received it does not provide this service, and there is more 592 than one HNR on the homenet that does provide the service, the HNR 593 that received the query round robins it across the available set of 594 HNRs that could answer it. 596 Similarly, if the query is to be sent to an ISP's resolver, and the 597 ISP has provided more than one resolver, round robining is done 598 across the set of resolvers provided by that ISP. If the query is to 599 be attempted at every ISP, then that is accomplished by round- 600 robining in such a way that each ISP is tried in succession, rather 601 than all the resolvers at one ISP, and then all the resolvers at the 602 next ISP, and so on. 604 6.2. Retransmission 606 For queries that can't be resolved locally by the HNR that received 607 them, retransmission as described in [RFC1035] is performed. 609 6.3. DNS Stateful Operations and DNS Push 611 DNS proxies on HNRs are required to support DNS Stateful Operations 612 and DNS Push. When a DNS Push operation is requested on a name that 613 can be satisfied by the HNR that received it, it is handled locally. 614 When such an operation is requested on a name that is local to the 615 homenet, but can't be satisfied by the HNR that received it, a DNS 616 Stateful operation is started with the HNR that is responsible for 617 it. 619 6.4. Multicast DNS 621 In addition to consulting the local resolver, hosts on the homenet 622 may attempt to discover services directly using Multicast DNS. HNRs 623 may filter out incoming Multicast DNS queries, forcing the client to 624 do service discovery using the DNS protocol. If such filtering is 625 not done, the client will be able to discover services on the link to 626 which it is attached, but will not be able to discover services 627 elsewhere. 629 It is believed that all currently-available hosts support DNSSD using 630 the DNS protocol. Support for mDNS on the local link is therefore 631 not required. However, if an mDNS query returns the same answer as 632 the DNS protocol query, this is not expected to be a problem. 634 6.5. Host behavior 636 Hosts that support the RA Provisioning Domain option direct queries 637 to the name server(s) of the provisioning domain they will use for 638 communication using the EDNS(0) provisioning domain option. In 639 practice this means that a host that supports PvDs will keep a set of 640 provisioning information for each prefix that it received from the 641 router, and will either choose a prefix to use based on its own 642 criteria, or will attempt to connect using every PvD at once or in 643 sequence. Answers to queries sent for a particular provisioning 644 domain will only be used with source addresses for prefixes that are 645 in that provisioning domain. 647 7. Publication 649 Names are published either using Multicast DNS Service Discovery 650 [RFC6762] or DNSSD Service Registration Protocol 651 ([I-D.sctl-service-registration]). Reverse mappings are published 652 using Homenet Reverse Mapping Update Protocol Section 7.2. 654 7.1. DNSSD Service Registration Protocol 656 HNRs that provide stateful authoritative service also publish 657 information acquired using DNSSD Service Registration Protocol 658 [I-D.sctl-service-registration]. DNSSD SRP does not explicitly 659 support population of the reverse zone; hosts that wish to provide 660 reverse mapping information must first establish their hostname using 661 DNSSD SRP; once established, the key used to authenticate the DNSSD 662 SRP update is also used to update the reverse name. 664 Support for SRP provides several advantages over DNSSD Discovery 665 Proxy. First, DNSSD SRP provides a secure way of claiming service 666 names. Second, a claimed name is valid for the entire network 667 covered by the SRP service, not just an individual link, as is the 668 case with mDNS. Third, SRP does not use multicast, and is therefore 669 more reliable on links with constrained multicast support 670 [I-D.ietf-mboned-ieee802-mcast-problems]. 672 Support for the DNSSD SRP service is not sufficient to achieve full 673 deployment of DNSSD SRP: it is also necessary that services advertise 674 using DNSSD SRP. Requiring such support is out of scope for this 675 document; our goal is simply to specify a way in which DNSSD SRP can 676 be supported on homenets, so that that as adoption of SRP increases 677 on devices providing service, it can actually be used. 679 7.2. Homenet Reverse Mapping Update Protocol 681 This is an extension to the DNSSD Service Registration protocol. The 682 purpose is to allow for updates of reverse mappings. Hosts wishing 683 to publish reverse mappings first publish their hostname using DNSSD 684 SRP. When this process has successfully completed, the host can add 685 reverse mappings to the ULA reverse mapping domain and to the RFC1918 686 reverse mapping domain, if present. 688 7.2.1. Adding ULA reverse mappings 690 The host first determines the ULA prefix. If there is more than one 691 ULA prefix active, the ULA prefix with the longest preferred lifetime 692 is used. A ULA prefix can be identified because it matches the 693 prefix fc00::/7 ([RFC4193] section 3.1). The actual prefix is then 694 the first 48 bits of the advertised prefix or the IP address in that 695 prefix. 697 Because the ULA reverse mapping zone contains no delegations, all 698 updates go to that one zone. To determine where to send the updates, 699 the host first queries the SRV record under the label _homenet- 700 rrp._tcp at the top of the ULA reverse mapping zone. It then uses 701 the name contained in the SRV record to look up A and/or AAAA records 702 to which to send the update. 704 The update is then signed using SIG(0) with the key that was used for 705 the DNSSD SRP registration. The update is then sent using DNS Update 706 [RFC2136] to one of the IP addresses received during the A/AAAA 707 resolution step. The update is sent using TCP; if a TCP connection 708 to one of the addresses fails, each subsequent address is tried in 709 succession; if none of the addresses is reachable, the update fails, 710 and may be retried after a reasonable period (on the order of an 711 hour) has elapsed. 713 7.2.2. Adding RFC1918 reverse mappings 715 RFC1918 reverse mapping updates use the same mechanism as ULA reverse 716 mapping updates. The host must first determine which zone to update, 717 as described earlier in Section 5.6. Once the zone has been 718 determined, the reverse mapping is updated as described in 719 Section 7.2.1. 721 8. Host Configuration 723 Each HNR provides a Homenet DNS Proxy. When an HNR provides the DNS 724 resolver IP address to hosts on the link using RA, DHCPv4 or DHCPv6, 725 it provides its own address. The IPv4 address that it provides is a 726 valid IPv4 address on the link to which the host is attached. The 727 IPv6 address it provides is an address in the homenet's ULA prefix 728 that is valid on the link to which the host is attached. 730 When sending router advertisements, the homenet includes the PvD ID 731 RA option [I-D.ietf-intarea-provisioning-domains] in each RA. 732 Because the PvD ID RA option can only be sent once per RA message, if 733 the homenet is connected to more than one ISP, the prefixes for each 734 ISP must be advertised in different RA options. In this case, the 735 prefix for the ULA should also be sent in a separate RA. 737 If the configuration received from the ISP includes a Domain Name 738 (DHCPv4) or Domain Search List (DHCPv4 or DHCPv6) option, the domain 739 name provided is used to identify the PvD. In the case of Domain 740 Search List options, if there is more than one, the first one is 741 used. For the ULA prefix, the homenet domain is used to identify the 742 PvD. 744 In order to facilitate DNSSD bootstrapping, any DHCPv4, DHCPv6 or RA 745 Domain Search List options contain only a single domain name, the 746 homenet domain. This allows hosts to quickly bootstrap DNS Service 747 Discovery using the local domain name, as descried in [RFC6763] 748 section 11. 750 9. Globally Unique Names 752 Homenets are not required to have globally unique names. Homenets 753 operating according to this specification do not publish names in 754 such a way that they can be resolved by hosts that aren't on the 755 homenet. However, such names are useful for DNSSEC validation. 757 There are three ways that homenets can get global names: 759 1. They can be manually configured by the user. How this is done is 760 out of scope for this document. 762 2. They can publish a delegation with the ISP, using a Homenet 763 Delegation Registration Protocol Section 11. 765 3. They can publish a delegation with some other provider, using 766 Homenet Delegation Registration Protocol Section 11. How this is 767 configured is out of scope for this document. 769 Homenets are also not required to support global delegations for 770 reverse mapping of global IPv4 and IPv6 addresses. How this would be 771 done is out of scope for this document. 773 10. DNSSEC Validation 775 DNSSEC validation for 'home.arpa' requires installing a per-homenet 776 trust anchor on the host, and is therefore not practical. Validation 777 for locally-served reverse zones for the ULA and RFC1918 addresses 778 would likewise require a trust anchor to be installed on the host, 779 and likewise are not practical. 781 If DNSSEC validation is to be done for the homenet, the homenet must 782 acquire a global name, and must be provided with a secure delegation. 783 Secure delegations must also be provided from the homenet domain to 784 each of the per-link subdomains. 786 Each HNR on a homenet generates its own private/public key pair that 787 can serve as a trust anchor. These keys are shared using HNCP 788 [RFC7788]. HNRs MUST NOT use pre-installed keys: each HNR MUST 789 generate its own key. The HNR responsible for authoritative 790 Discovery Proxy service on a particular link signs the zone for that 791 link; delegations from the homenet domain zone to each per-link 792 subdomain zone include a DS record signed by the ZSK of the homenet 793 zone. 795 10.1. How trust is established 797 Every HNR has its own public/private key pair. A DS record for each 798 such public key is published in the delegation for the homenet 799 domain. If stateless authoritative service for the homenet zone is 800 being provided, then each HNR signs its own homenet zone. The signed 801 zone should be very stable, although the delegations may change when 802 the network topology changes. The HNR can therefore sign the zone 803 using its private key whenever it changes. Each HNR will have a copy 804 of the zone signed with a different key, but since all of the ZSKs 805 are present in the DS RRset at the delegation point, validation will 806 succeed. 808 If stateful authoritative service is being provided, the HNR that is 809 acting as primary signs the zone, and all the secondaries serve 810 copies acquired using zone transfers. If the HNR that is primary 811 goes away, then a secondary becomes primary and signs the zone before 812 beginning to provide service. Again, since all of the HNR's public 813 keys exist in the DS RRset at the delegation, the zone can be 814 validated. 816 11. Homenet Delegation Registration Protocol 818 Homenet Delegation Registration Protocol (HDeRP) operates similarly 819 to DNSSD Service Registration Protocol. When a homenet is not 820 connected to an ISP that supports HDeRP, and then an ISP connection 821 becomes available, the HNR that is connected to the ISP determines 822 whether HDeRP is available. This is done by first determining the 823 ISP domain. 825 If the connection to the ISP is IPv4-only, this will be either the 826 DHCPv4 Domain Name option or, if not present, the only domain name in 827 the DHCPv4 Domain Name Search List option. If the Domain Name Search 828 List option contains more than one name, HDeRP is not supported by 829 the ISP. 831 If the connection to the ISP is dual-stack or IPv6-only, then the 832 DHCPv6 Domain Search List option obtained through DHCPv6 Prefix 833 Delegation is used. If it is not present, or if it contains more 834 than one domain name, HDeRP is not supported by the ISP. 836 Once the ISP domain has been discovered, the HNR looks for an SRV 837 record owned by the name _homenet-derp._tcp under the ISP domain. If 838 this is not present, HDeRP is not supported. If the SRV record is 839 present, then the HNR looks for A and AAAA records on the hostname 840 provided in the HNR. If present, these are used when attempting the 841 update. 843 The HNR then constructs a DNS update. The DNS update creates a 844 delegation for the zone home.arpa, with a DS record for each HNR on 845 the homenet, containing that HNR's public key. The HNR doing the 846 update lists its key as the first key in the DS RRset. The update is 847 signed using SIG(0) with the private key of the HNR that is 848 constructing it. As with DNSSD SRP, the update includes an Update 849 Lease EDNS(0) option, specifying a key lifetime of a week. 851 The HNR then attempts to connect to the hostname provided in the SRV 852 record, in a round-robin fashion across the set of IP addresses 853 discovered during the A/AAAA lookup phase. When it has successfully 854 connected, it sends the DNS update. 856 The HDeRP server validates the update by checking the SIG(0) 857 signature of the update against the first key in the DS RRset. If 858 the update is successfully validated, then the server generates a 859 domain name and sends a reply back to the HNR on the same TCP 860 connection, including the NOERROR (0) RCODE, and including in the 861 query section the actual domain name that was generated. 863 This domain name then becomes the homenet name. Subsequent updates 864 use the homenet name rather than 'home.arpa'. It is not necessary 865 that the same HNR do the update; if a different HNR does the update, 866 it lists its public key first in the DS RRset, and signs the update 867 using its private key. 869 The HDeRP is responsible for removing the delegation if it is not 870 refreshed for the length of its lifetime. HNRs should attempt to 871 refresh the delegation when half the lifetime has experienced, then 872 again at 5/8ths, and again at 7/8ths of the lifetime. If the ISP 873 becomes unavailable, and a different ISP becomes available that 874 supports HDeRP, the homenet should migrate to the new ISP. 876 12. Using the Local Namespace While Away From Home 878 This document does not specify a way for service discovery to be 879 performed on the homenet by devices that are not directly connected 880 to a link that is part of the homenet. 882 13. Expected Host Behavior 884 It is expected that hosts will fall into one of two categories: hosts 885 that are able to discover DNS-SD browsing domains, and hosts that are 886 not. Hosts that can discover DNS-SD browsing domains can be expected 887 to successfully use service discovery across the entire homenet. 888 Hosts that do not will only be able to discover services on the 889 particular local subnet of the homenet to which they happen to be 890 attached at any given time. 892 This is not considered to be a problem, since it is understood by the 893 authors that the vast majority of hosts that are capable of doing 894 mDNS discovery are also capable of doing DNS-SD discovery as 895 described in [RFC6763]. 897 14. Management Considerations 899 This architecture is intended to be self-healing, and should not 900 require management. That said, a great deal of debugging and 901 management can be done simply using the DNS Service Discovery 902 protocol. 904 15. Privacy Considerations 906 Privacy is somewhat protected in the sense that names published on 907 the homenet are only visible to devices connected to the homenet. 908 This may be insufficient privacy in some cases. 910 The privacy of host information on the homenet is left to hosts. 911 Various mechanisms are available to hosts to ensure that tracking 912 does not occur if it is not desired. However, devices that need to 913 have special permission to manage the homenet will inevitably reveal 914 something about themselves when doing so. 916 16. Security Considerations 918 There are some clear issues with the security model described in this 919 document, which will be documented in a future version of this 920 section. A full analysis of the avenues of attack for the security 921 model presented here have not yet been done, and must be done before 922 the document is published. 924 17. IANA considerations 926 17.1. Homenet Reverse Registration Protocol 928 IANA is requested to add a new entry to the Service Names and Port 929 Numbers registry for homenet-rrp with a transport type of tcp. No 930 port number is to be assigned. The reference should be to this 931 document, and the Assignee and Contact information should reference 932 the authors of this document. The Description should be as follows: 934 Availability of Homenet Reverse Registration Protocol service for a 935 given domain is advertised using an SRV record with an owner name of 936 "_homenet-rrp._tcp.." in that domain, which gives the target 937 host and port where Homenet Reverse Registration service is provided 938 for the named domain. 940 17.2. Homenet Delegation Registration Protocol 942 IANA is requested to add a new entry to the Service Names and Port 943 Numbers registry for homenet-derp with a transport type of tcp. No 944 port number is to be assigned. The reference should be to this 945 document, and the Assignee and Contact information should reference 946 the authors of this document. The Description should be as follows: 948 Availability of Homenet Delegation Registration Protocol service for 949 a given domain is advertised using an SRV record with an owner name 950 of "_homenet-derp._tcp.." in that domain, which gives the 951 target host and port where Homenet Delegation Registration service is 952 provided for the named domain. 954 17.3. Unique Local Address Reserved Documentation Prefix 956 IANA is requested to add an entry to the IPv6 Special-Purpose Address 957 Registry for the prefix fc00:2001:db8::/48. The Name shall be 958 "Unique Local Address Documentation Prefix." The reference RFC will 959 be this document, once published. The date will be the date the 960 entry was added. All other fields will be the same as for the 961 Documentation prefix, 2001:db8::/32. 963 18. References 965 18.1. Normative References 967 [I-D.ietf-dnsop-session-signal] 968 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 969 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 970 draft-ietf-dnsop-session-signal-16 (work in progress), 971 September 2018. 973 [I-D.ietf-dnssd-hybrid] 974 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 975 Service Discovery", draft-ietf-dnssd-hybrid-08 (work in 976 progress), March 2018. 978 [I-D.ietf-dnssd-push] 979 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 980 draft-ietf-dnssd-push-15 (work in progress), September 981 2018. 983 [I-D.ietf-intarea-provisioning-domains] 984 Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. 985 Shao, "Discovering Provisioning Domain Names and Data", 986 draft-ietf-intarea-provisioning-domains-03 (work in 987 progress), October 2018. 989 [I-D.sctl-service-registration] 990 Cheshire, S. and T. Lemon, "Service Registration Protocol 991 for DNS-Based Service Discovery", draft-sctl-service- 992 registration-02 (work in progress), July 2018. 994 [localzones] 995 Internet Assigned Numbers Authority, "Locally-Served DNS 996 Zones", n.d., . 999 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1000 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1001 . 1003 [RFC1035] Mockapetris, P., "Domain names - implementation and 1004 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1005 November 1987, . 1007 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1008 and E. Lear, "Address Allocation for Private Internets", 1009 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1010 . 1012 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1013 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1014 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1015 . 1017 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1018 Rose, "DNS Security Introduction and Requirements", 1019 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1020 . 1022 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1023 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1024 . 1026 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1027 DOI 10.17487/RFC6762, February 2013, 1028 . 1030 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1031 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1032 . 1034 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1035 "Framework for Content Distribution Network 1036 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1037 August 2014, . 1039 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 1040 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 1041 . 1043 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1044 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1045 2016, . 1047 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1048 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1049 . 1051 18.2. Informative References 1053 [I-D.ietf-mboned-ieee802-mcast-problems] 1054 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 1055 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1056 Media", draft-ietf-mboned-ieee802-mcast-problems-02 (work 1057 in progress), August 2018. 1059 Authors' Addresses 1061 Ted Lemon 1062 Nibbhaya Consulting 1063 P.O. Box 958 1064 Brattleboro, Vermont 05301 1065 United States of America 1067 Email: mellon@fugue.com 1069 Daniel Migault 1070 Ericsson 1071 8400 boulevard Decarie 1072 Montreal, QC H4P 2N2 1073 Canada 1075 Email: daniel.migault@ericsson.com 1077 Stuart Cheshire 1078 Apple Inc. 1079 1 Infinite Loop 1080 Cupertino, California 95014 1081 USA 1083 Phone: +1 408 974 3207 1084 Email: cheshire@apple.com