draft-ietf-dnssd-hybrid-02.txt   draft-ietf-dnssd-hybrid-03.txt 
Internet Engineering Task Force S. Cheshire Internet Engineering Task Force S. Cheshire
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track November 5, 2015 Intended status: Standards Track February 4, 2016
Expires: May 8, 2016 Expires: August 7, 2016
Hybrid Unicast/Multicast DNS-Based Service Discovery Hybrid Unicast/Multicast DNS-Based Service Discovery
draft-ietf-dnssd-hybrid-02 draft-ietf-dnssd-hybrid-03
Abstract Abstract
Performing DNS-Based Service Discovery using purely link-local Performing DNS-Based Service Discovery using purely link-local
Multicast DNS enables discovery of services that are on the local Multicast DNS enables discovery of services that are on the local
link, but not (without some kind of proxy or similar special support) link, but not (without some kind of proxy or similar special support)
discovery of services that are outside the local link. Using a very discovery of services that are outside the local link. Using a very
large local link with thousands of hosts facilitates service large local link with thousands of hosts facilitates service
discovery, but at the cost of large amounts of multicast traffic. discovery, but at the cost of large amounts of multicast traffic.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 8, 2016. This Internet-Draft will expire on August 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 15, line 29 skipping to change at page 15, line 29
information is inefficient, but not fatal. However, when a Hybrid information is inefficient, but not fatal. However, when a Hybrid
Proxy aggregates data from multiple printers on a link, and sends it Proxy aggregates data from multiple printers on a link, and sends it
via unicast (via UDP or TCP) this amount of unnecessary TXT record via unicast (via UDP or TCP) this amount of unnecessary TXT record
information can result in large responses. A DNS reply over TCP information can result in large responses. A DNS reply over TCP
carrying information about 70 printers with an average of 700 bytes carrying information about 70 printers with an average of 700 bytes
per printer adds up to about 50 kilobytes of data. Therefore, a per printer adds up to about 50 kilobytes of data. Therefore, a
Hybrid Proxy that is aware of the specifics of an application-layer Hybrid Proxy that is aware of the specifics of an application-layer
protocol such as AirPrint (which uses IPP) can elide unnecessary key/ protocol such as AirPrint (which uses IPP) can elide unnecessary key/
value pairs from the DNS-SD TXT record for better network efficiency. value pairs from the DNS-SD TXT record for better network efficiency.
Also, the DNS-SD TXT record for many printers contains an "adminurl"
key something like "adminurl=http://printername.local/status.html".
For this URL to be useful outside the local link, the embedded dot-
local hostname needs to be translated to an appropriate name with
larger scope. Dot-local names are easily translated when they appear
in well-defined places, either as a record's name, or in the rdata of
record types like PTR and SRV. In the printing case, some
application-specific knowledge about the semantics of the "adminurl"
key is needed for the Hybrid Proxy to know that it contains a name
that needs to be translated. This is somewhat analogous to the need
for NAT gateways to contain ALGs (Application-Specific Gateways) to
facilitate the correct translation of protocols that embed addresses
in unexpected places.
As is the case with NAT ALGs, protocol designers are advised to avoid
communicating names and addresses in nonstandard locations, because
those "hidden" names and addresses are at risk of not being
translated when necessary, resulting in operational failures. In the
printing case, the operational failure of failing to translate the
"adminurl" key correctly is that, when accessed from a different
link, printing will still work, but clicking the "Admin" UI button
will fail to open the printer's administration page. Rather than
duplicating the host name from the service's SRV record in its
"adminurl" key, thereby having the same host name appear in two
places, a better design might have been to omit the host name from
the "adminurl" key, and instead have the client implicitly substitute
the target host name from the service's SRV record in place of a
missing host name in the "adminurl" key. That way the desired host
name only appears once, and it is in a well-defined place where
software like the Hybrid Proxy is expecting to find it.
Note that this kind of Application-Specific Data Translation is Note that this kind of Application-Specific Data Translation is
expected to be very rare. It is the exception, rather than the rule. expected to be very rare. It is the exception, rather than the rule.
This is an example of a common theme in computing. It is frequently This is an example of a common theme in computing. It is frequently
the case that it is wise to start with a clean, layered design, with the case that it is wise to start with a clean, layered design, with
clear boundaries. Then, in certain special cases, those layer clear boundaries. Then, in certain special cases, those layer
boundaries may be violated, where the performance and efficiency boundaries may be violated, where the performance and efficiency
benefits outweigh the inelegance of the layer violation. benefits outweigh the inelegance of the layer violation.
As in other similar situations, these layer violations are optional. These layer violations are optional. They are done primarily for
They are done only for efficiency reasons, and are not required for efficiency reasons, and generally should not be required for correct
correct operation. A Hybrid Proxy can operate solely at the mDNS operation. A Hybrid Proxy MAY operate solely at the mDNS layer,
layer, without any knowledge of semantics at the DNS-SD layer or without any knowledge of semantics at the DNS-SD layer or above.
above.
4.6. Answer Aggregation 4.6. Answer Aggregation
In a simple analysis, simply gathering multicast answers and In a simple analysis, simply gathering multicast answers and
forwarding them in a unicast response seems adequate, but it raises forwarding them in a unicast response seems adequate, but it raises
the question of how long the Hybrid Proxy should wait to be sure that the question of how long the Hybrid Proxy should wait to be sure that
it has received all the Multicast DNS answers it needs to form a it has received all the Multicast DNS answers it needs to form a
complete Unicast DNS response. If it waits too little time, then it complete Unicast DNS response. If it waits too little time, then it
risks its Unicast DNS response being incomplete. If it waits too risks its Unicast DNS response being incomplete. If it waits too
long, then it creates a poor user experience at the client end. In long, then it creates a poor user experience at the client end. In
skipping to change at page 23, line 34 skipping to change at page 23, line 34
disclosure page [IPR2119]. disclosure page [IPR2119].
10. IANA Considerations 10. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
11. Acknowledgments 11. Acknowledgments
Thanks to Markus Stenberg for helping develop the policy regarding Thanks to Markus Stenberg for helping develop the policy regarding
the four styles of unicast response according to what data is the four styles of unicast response according to what data is
immediately available in the cache. Thanks to Andrew Yourtchenko for immediately available in the cache. Thanks to Anders Brandt and
comments about privacy issues. [Partial list; more names to be Andrew Yourtchenko for their comments. [Partial list; more names to
added.] be added.]
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
 End of changes. 7 change blocks. 
13 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/