--- 1/draft-ietf-dnssd-hybrid-03.txt 2016-10-31 17:16:53.084577054 -0700 +++ 2/draft-ietf-dnssd-hybrid-04.txt 2016-10-31 17:16:53.136578344 -0700 @@ -1,18 +1,18 @@ Internet Engineering Task Force S. Cheshire Internet-Draft Apple Inc. -Intended status: Standards Track February 4, 2016 -Expires: August 7, 2016 +Intended status: Standards Track October 31, 2016 +Expires: May 4, 2017 Hybrid Unicast/Multicast DNS-Based Service Discovery - draft-ietf-dnssd-hybrid-03 + draft-ietf-dnssd-hybrid-04 Abstract Performing DNS-Based Service Discovery using purely link-local Multicast DNS enables discovery of services that are on the local link, but not (without some kind of proxy or similar special support) discovery of services that are outside the local link. Using a very large local link with thousands of hosts facilitates service discovery, but at the cost of large amounts of multicast traffic. @@ -41,73 +41,76 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 7, 2016. + This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology Used in this Document . . . . . . 5 - 3. Compatibility Considerations . . . . . . . . . . . . . . . . . 5 + 3. Compatibility Considerations . . . . . . . . . . . . . . . . . 6 4. Hybrid Proxy Operation . . . . . . . . . . . . . . . . . . . . 6 4.1. Delegated Subdomain for Service Discovery Records . . . . 7 4.2. Domain Enumeration . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Domain Enumeration via Unicast Queries . . . . . . . . 8 4.2.2. Domain Enumeration via Multicast Queries . . . . . . . 9 4.3. Delegated Subdomain for LDH Host Names . . . . . . . . . . 10 4.4. Delegated Subdomain for Reverse Mapping . . . . . . . . . 12 4.5. Data Translation . . . . . . . . . . . . . . . . . . . . . 13 4.5.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . . 13 4.5.2. Suppressing Unusable Records . . . . . . . . . . . . . 14 - 4.5.3. Application-Specific Data Translation . . . . . . . . 15 + 4.5.3. Text Encoding Translation . . . . . . . . . . . . . . 14 + 4.5.4. Application-Specific Data Translation . . . . . . . . 15 4.6. Answer Aggregation . . . . . . . . . . . . . . . . . . . . 16 - 4.6.1. Discovery of LLQ and/or PUSH Notification Service . . 19 - 5. DNS SOA (Start of Authority) Record . . . . . . . . . . . . . 20 - 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 - 6.1. Already Implemented and Deployed . . . . . . . . . . . . . 20 - 6.2. Already Implemented . . . . . . . . . . . . . . . . . . . 21 - 6.3. Partially Implemented . . . . . . . . . . . . . . . . . . 21 - 6.4. Not Yet Implemented . . . . . . . . . . . . . . . . . . . 21 - 7. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 8.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . . 22 - 8.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 23 - 9. Intelectual Property Rights . . . . . . . . . . . . . . . . . 23 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 5. DNS SOA (Start of Authority) Record . . . . . . . . . . . . . 19 + 6. DNSSEC Issues . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.1. On-line signing only . . . . . . . . . . . . . . . . . . . 20 + 6.2. NSEC and NSEC3 Records . . . . . . . . . . . . . . . . . . 20 + 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 + 7.1. Already Implemented and Deployed . . . . . . . . . . . . . 21 + 7.2. Already Implemented . . . . . . . . . . . . . . . . . . . 21 + 7.3. Partially Implemented . . . . . . . . . . . . . . . . . . 21 + 7.4. Not Yet Implemented . . . . . . . . . . . . . . . . . . . 22 + 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 9.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 23 + 10. Intelectual Property Rights . . . . . . . . . . . . . . . . . 24 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Multicast DNS [RFC6762] and its companion technology DNS-based Service Discovery [RFC6763] were created to provide IP networking with the ease-of-use and autoconfiguration for which AppleTalk was well known [RFC6760] [ZC]. For a small network consisting of just a single link (or several physical links bridged together to appear as a single logical link to @@ -135,20 +138,55 @@ discusses various possible ways that a service's PTR, SRV, TXT and address records can make their way into the Unicast DNS namespace, including manual zone file configuration [RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007] and proxies of various kinds. This document specifies a type of proxy called a Hybrid Proxy that uses Multicast DNS [RFC6762] to discover Multicast DNS records on its local link, and makes corresponding DNS records visible in the Unicast DNS namespace. + In simple terms, a descriptive DNS name is chosen for each physical + link in an organization. Using a DNS NS record, responsibility for + that DNS name is delegated to a Hybrid Proxy physically attached to + that link. Now, when a remote client issues a unicast query for a + name falling within the delegated subdomain, the normal DNS + delegation mechanism results in the unicast query arriving at the + Hybrid Proxy, since it has been declared authoritative for those + names. Now, instead of consulting a textual zone file on disk to + discover the answer to the query, as a traditional DNS server would, + a Hybrid Proxy consults its local link, using Multicast DNS, to find + the answer to the question. + + Note that the Hybrid Proxy uses a "pull" model. The local link is + not queried using Multicast DNS until a remote client has requested + that data. In the idle state, in the absence of client requests, the + Hybrid Proxy sends no packets and imposes no burden on the network. + It operates purely "on demand". + + An alternative proposal has been a proxy that performs DNS updates to + a remote DNS server on behalf of the Multicast DNS devices on the + local network. The difficulty of this is that the proxy would have + to be issuing all possible Multicast DNS queries all the time, to + discover all the answers it needed to push up to the remote DNS + server using DNS Update. It would thus generate very high load on + the network continuously, even when there were no clients with any + interest in that data. + + Hence, having a model where the query comes to the Hybrid Proxy is + much more efficient than a model where the Hybrid Proxy pushes the + answers out to some other remote DNS server. + + A client can send queries to the Hybrid Proxy in the form of + traditional DNS queries, or by making a DNS Push Notification + subscription [I-D.ietf-dnssd-push]. + 2. Conventions and Terminology Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The Hybrid Proxy builds on Multicast DNS, which works between hosts on the same link. A set of hosts is considered to be "on the same link" if: @@ -540,29 +578,45 @@ about Long-Lived Queries, and its newer replacement, DNS Push Notifications, see Section 4.6. 4.5.2. Suppressing Unusable Records A Hybrid Proxy SHOULD suppress Unicast DNS answers for records that are not useful outside the local link. For example, DNS A and AAAA records for IPv6 link-local addresses [RFC4862] and IPv4 link-local addresses [RFC3927] should be suppressed. Similarly, for sites that have multiple private address realms [RFC1918], private addresses - from one private address realm should not be communicated to clients + from one private address realm SHOULD NOT be communicated to clients in a different private address realm. By the same logic, DNS SRV records that reference target host names that have no addresses usable by the requester should be suppressed, and likewise, DNS PTR records that point to unusable SRV records should be similarly be suppressed. -4.5.3. Application-Specific Data Translation +4.5.3. Text Encoding Translation + + A Hybrid Proxy does no translation between text encodings. + Specifically, a Hybrid Proxy does no translation between Punycode and + UTF-8, either in the owner name of DNS records, or anywhere in the + RDATA of DNS records (such as the RDATA of PTR records, SRV records, + NS records, or other record types like TXT, where it is ambiguous + whether the RDATA may contain DNS names). All bytes are treated + as-is, with no attempt at text encoding translation. A client + implementing DNS-based Service Discovery [RFC6763] will use UTF-8 + encoding for its service discovery queries, which the Hybrid Proxy + passes through without any text encoding translation to the Multicast + DNS subsystem. Responses from the Multicast DNS subsystem are + similarly returned, without any text encoding translation, back to + the requesting client. + +4.5.4. Application-Specific Data Translation There may be cases where Application-Specific Data Translation is appropriate. For example, AirPrint printers tend to advertise fairly verbose information about their capabilities in their DNS-SD TXT record. TXT record sizes in the range 500-1000 bytes are not uncommon. This information is a legacy from LPR printing, because LPR does not have in-band capability negotiation, so all of this information is conveyed using the DNS-SD TXT record instead. IPP printing does have @@ -666,37 +720,36 @@ of the device responding to the Multicast DNS query. If the Multicast DNS device responds quickly, then the update message is delivered quickly. If the Multicast DNS device responds slowly, then the update message is delivered slowly. The benefit of using update messages is that the Hybrid Proxy can respond promptly because it doesn't have to delay its unicast response to allow for the expected worst-case delay for receiving all the Multicast DNS responses. Even if a proxy were to try to provide reliability by assuming an excessively pessimistic worst-case time (thereby giving a very poor user experience) there would still be the risk of a slow Multicast - DNS device taking even longer than that (e.g, a device that is not + DNS device taking even longer than that (e.g., a device that is not even powered on until ten seconds after the initial query is received) resulting in incomplete responses. Using update message solves this dilemma: even very late responses are not lost; they are delivered in subsequent update messages. There are two factors that determine specifically how responses are generated: The first factor is whether the query from the client included an LLQ or DNS Push Notification option (typical with long-lived service browsing PTR queries) or not (typical with one-shot operations like SRV or address record queries). Note that queries containing the LLQ - or PUSH option are received directly from the client (see - Section 4.6.1). Queries containing no LLQ or PUSH option are - generally received via the client's configured recursive (caching) - name server. + or PUSH option are received directly from the client. Queries + containing no LLQ or PUSH option are generally received via the + client's configured recursive (caching) name server. The second factor is whether the Hybrid Proxy already has at least one record in its cache that positively answers the question. o No LLQ or PUSH option; no answer in cache: Issue an mDNS query, exactly as a local client would issue an mDNS query on the local link for the desired record name, type and class, including retransmissions, as appropriate, according to the established mDNS retransmission schedule [RFC6762]. As soon as any Multicast DNS response packet is received that contains one or @@ -740,129 +794,110 @@ continues to remain accurate even as the network environment changes.) DNS TTLs in responses are returned unmodified. Note that the "negative responses" referred to above are "no error no answer" negative responses, not NXDOMAIN. This is because the Hybrid Proxy cannot know all the Multicast DNS domain names that may exist on a link at any given time, so any name with no answers may have child names that do exist, making it an "empty nonterminal" name. -4.6.1. Discovery of LLQ and/or PUSH Notification Service - - To issue LLQ or PUSH queries, clients need to communicate directly - with the authoritative Hybrid Proxy. The procedure by which the - client locates the authoritative Hybrid Proxy is described in the LLQ - specification [I-D.sekar-dns-llq] and the DNS Push Notifications - specification [I-D.ietf-dnssd-push]. - - Briefly, the procedure is as follows: - - To discover the LLQ service for a given domain name, a client first - performs DNS zone apex discovery, and then, having discovered , - the client then issues a DNS query for the SRV record with the name - _dns-llq._udp. to find the target host and port for the LLQ - service for that zone. By default LLQ service runs on UDP port 5352, - but since SRV records are used, the LLQ service can be offered on any - port. - - To discover the DNS Push Notification service for a given domain - name, a client first performs DNS zone apex discovery, and then, - having discovered , the client then issues a DNS query for the - SRV record with the name _dns-push-tls._tcp. to find the target - host and port for the DNS Push Notification service for that zone. - By default DNS Push Notification service runs on TCP port 5352, but - since SRV records are used, the DNS Push Notification service can be - offered on any port. - - A client performs DNS zone apex discovery using the procedure below: - - 1. The client issues a DNS query for the SOA record with the given - domain name. - - 2. A conformant recursive (caching) name server will either send a - positive response, or a negative response containing the SOA - record of the zone apex in the Authority Section. - - 3. If the name server sends a negative response that does not - contain the SOA record of the zone apex, the client trims the - first label off the given domain name and returns to step 1 to - try again. - - By this method, the client iterates until it learns the name of the - zone apex, or (in pathological failure cases) reaches the root and - gives up. - - Normal DNS caching is used to avoid repetitive queries on the wire. - 5. DNS SOA (Start of Authority) Record The MNAME field SHOULD contain the host name of the Hybrid Proxy device (i.e., the same domain name as the rdata of the NS record delegating the relevant zone(s) to this Hybrid Proxy device). The RNAME field SHOULD contain the mailbox of the person responsible for administering this Hybrid Proxy device. - The SERIAL field SHOULD contain a sequence number that increments - each time the Hybrid Proxy returns an SOA record to any client. - [Author's note: Or maybe it could just be zero?] + The SERIAL field MUST be zero. Since zone transfers are undefined for Hybrid Proxy zones, the REFRESH, RETRY and EXPIRE fields have no useful meaning for Hybrid Proxy zones. These fields SHOULD contain reasonable default values. The RECOMMENDED values are: REFRESH 7200, RETRY 3600, EXPIRE 86400. The MINIMUM field (used to control the lifetime of negative cache entries) SHOULD contain the value 10. The value of ten seconds is chosen based on user experience considerations (see Section 4.5.1). - [Author's note: Discussion of these recommendations is requested.] +6. DNSSEC Issues -6. Implementation Status +6.1. On-line signing only + + Auth server must possess key, to generate signed data from mDNS + responses. Therefore off-line signing not applicable to Hybrid + Proxy. + +6.2. NSEC and NSEC3 Records + + In DNSSEC, NSEC and NSEC3 records are used to assert the nonexistence + of certain names, also described as "authenticated denial of + existence". + + Since a Hybrid Proxy only knows what names exist on the local link by + issuing queries for them, and since it would be impractical to issue + queries for every possible name just to find out which names exist + and which do not, a Hybrid Proxy cannot programatically synthesize + the traditional NSEC and NSEC3 records which assert the nonexistence + of a large range names. Instead, when generating a negative + response, a Hybrid Proxy programatically synthesizes a single NSEC + record assert the nonexistence of just the specific name queried, and + no others. Since the Hybrid Proxy has the zone signing key, it can + do this on demand. Since the NSEC record asserts the nonexistence of + only a single name, zone walking is not a concern, so NSEC3 is not + necessary. Note that this applies only to traditional immediate DNS + queries, which may return immediate negative answers when no + immediate positive answer is available. When used with a DNS Push + Notification subscription [I-D.ietf-dnssd-push] there are no negative + answers, merely the absence of answers so far, which may change in + the future if answers become available. + +7. Implementation Status Some aspects of the mechanism specified in this document already exist in deployed software. Some aspects are new. This section outlines which aspects already exist and which are new. -6.1. Already Implemented and Deployed +7.1. Already Implemented and Deployed Domain enumeration by the client (the "b._dns-sd._udp" queries) is already implemented and deployed. Unicast queries to the indicated discovery domain is already implemented and deployed. These are implemented and deployed in Mac OS X 10.4 and later (including all versions of Apple iOS, on all iPhone and iPads), in Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) and later. Domain enumeration and unicast querying have been used for several years at IETF meetings to make Terminal Room printers discoverable from outside the Terminal room. When you Press Cmd-P on your Mac, or select AirPrint on your iPad or iPhone, and the Terminal room printers appear, that is because your client is sending unicast DNS queries to the IETF DNS servers. -6.2. Already Implemented +7.2. Already Implemented A minimal portable Hybrid Proxy implementation has been produced by Markus Stenberg and Steven Barth, which runs on OS X and several Linux variants including OpenWrt [ohp]. It was demonstrated at the Berlin IETF in July 2013. Tom Pusateri also has an implementation that runs on any Unix/Linux. It has a RESTful interface for management and an experimental demo CLI and web interface. -6.3. Partially Implemented +7.3. Partially Implemented The current APIs make multiple domains visible to client software, but most client UI today lumps all discovered services into a single flat list. This is largely a chicken-and-egg problem. Application writers were naturally reluctant to spend time writing domain-aware UI code when few customers today would benefit from it. If Hybrid Proxy deployment becomes common, then application writers will have a reason to provide better UI. Existing applications will work with the Hybrid Proxy, but will show all services in a single flat list. Applications with improved UI will group services by domain. @@ -874,111 +909,117 @@ [I-D.ietf-dnssd-push]. The pragmatic short-term deployment approach is for vendors to produce Hybrid Proxies that implement both the deployed Long-Lived Query mechanism [I-D.sekar-dns-llq] (for today's clients) and the new DNS Push Notifications mechanism [I-D.ietf-dnssd-push] as the preferred long-term direction. The translating/filtering Hybrid Proxy specified in this document. Implementations are under development, and operational experience with these implementations has guided updates to this document. -6.4. Not Yet Implemented +7.4. Not Yet Implemented Client implementations of the new DNS Push Notifications mechanism [I-D.ietf-dnssd-push] are currently underway. A mechanism to 'stitch' together multiple ".local." zones so that - they appear as one. Such a mechanism will be specified in a future - companion document. + they appear as one. Such a stitching mechanism will be specified in + a future companion document. This stitching mechanism addresses the + issue that if a printer is physically moved from one link to another, + then conceptually the old service has disappeared from the DNS + namespace, and a new service with a similar name has appeared. This + stitching mechanism will allow a service to change its point of + attachment without changing the name by which it can be found. -7. IPv6 Considerations +8. IPv6 Considerations An IPv6-only host and an IPv4-only host behave as "ships that pass in the night". Even if they are on the same Ethernet, neither is aware of the other's traffic. For this reason, each physical link may have *two* unrelated ".local." zones, one for IPv6 and one for IPv4. Since for practical purposes, a group of IPv6-only hosts and a group of IPv4-only hosts on the same Ethernet act as if they were on two entirely separate Ethernet segments, it is unsurprising that their use of the ".local." zone should occur exactly as it would if they really were on two entirely separate Ethernet segments. It will be desirable to have a mechanism to 'stitch' together these two unrelated ".local." zones so that they appear as one. Such mechanism will need to be able to differentiate between a dual-stack (v4/v6) host participating in both ".local." zones, and two different hosts, one IPv6-only and the other IPv4-only, which are both trying to use the same name(s). Such a mechanism will be specified in a future companion document. -8. Security Considerations +9. Security Considerations -8.1. Authenticity +9.1. Authenticity A service proves its presence on a link by its ability to answer link-local multicast queries on that link. If greater security is desired, then the Hybrid Proxy mechanism should not be used, and something with stronger security should be used instead, such as authenticated secure DNS Update [RFC2136] [RFC3007]. -8.2. Privacy +9.2. Privacy The Domain Name System is, generally speaking, a global public database. Records that exist in the Domain Name System name hierarchy can be queried by name from, in principle, anywhere in the world. If services on a mobile device (like a laptop computer) are made visible via the Hybrid Proxy mechanism, then when those services - become visibile in a domain such as "My House.example.com" that might + become visible in a domain such as "My House.example.com" that might indicate to (potentially hostile) observers that the mobile device is in my house. When those services disappear from "My House.example.com" that change could be used by observers to infer when the mobile device (and possibly its owner) may have left the house. The privacy of this information may be protected using techniques like firewalls and split-view DNS, as are customarily used today to protect the privacy of corporate DNS information. -8.3. Denial of Service +9.3. Denial of Service A remote attacker could use a rapid series of unique Unicast DNS queries to induce a Hybrid Proxy to generate a rapid series of corresponding Multicast DNS queries on one or more of its local links. Multicast traffic is expensive -- especially on Wi-Fi links -- which makes this attack particularly serious. To limit the damage that can be caused by such attacks, a Hybrid Proxy (or the underlying Multicast DNS subsystem which it utilizes) MUST implement Multicast DNS query rate limiting appropriate to the link technology in question. For Wi-Fi links the Multicast DNS subsystem SHOULD NOT issue more than 20 Multicast DNS query packets per second. On other link technologies like Gigabit Ethernet higher limits may be appropriate. -9. Intelectual Property Rights +10. Intelectual Property Rights Apple has submitted an IPR disclosure concerning the technique proposed in this document. Details are available on the IETF IPR disclosure page [IPR2119]. -10. IANA Considerations +11. IANA Considerations This document has no IANA Considerations. -11. Acknowledgments +12. Acknowledgments Thanks to Markus Stenberg for helping develop the policy regarding the four styles of unicast response according to what data is - immediately available in the cache. Thanks to Anders Brandt and - Andrew Yourtchenko for their comments. [Partial list; more names to - be added.] + immediately available in the cache. Thanks to Anders Brandt, Tim + Chown, Ralph Droms, Ray Hunter, Ted Lemon, Tom Pusateri, Markus + Stenberg, Dave Thaler, and Andrew Yourtchenko for their comments. + [Partial list; more names to be added.] -12. References +13. References -12.1. Normative References +13.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, @@ -1013,21 +1054,21 @@ December 2012. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, December 2012. [I-D.ietf-dnssd-push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", draft-ietf-dnssd-push-03 (work in progress), November 2015. -12.2. Informative References +13.2. Informative References [HOME] Cheshire, S., "Special Use Top Level Domain 'home'", draft-cheshire-homenet-dot-home (work in progress), November 2015. [IPR2119] "Apple Inc.'s Statement about IPR related to Hybrid Unicast/Multicast DNS-Based Service Discovery", . [ohp] "Hybrid Proxy implementation for OpenWrt",