draft-ietf-dnssd-hybrid-09.txt   draft-ietf-dnssd-hybrid-10.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 March 11, 2019 Intended status: Standards Track March 24, 2019
Expires: September 12, 2019 Expires: September 25, 2019
Discovery Proxy for Multicast DNS-Based Service Discovery Discovery Proxy for Multicast DNS-Based Service Discovery
draft-ietf-dnssd-hybrid-09 draft-ietf-dnssd-hybrid-10
Abstract Abstract
This document specifies a network proxy that uses Multicast DNS to This document specifies a network proxy that uses Multicast DNS to
automatically populate the wide-area unicast Domain Name System automatically populate the wide-area unicast Domain Name System
namespace with records describing devices and services found on the namespace with records describing devices and services found on the
local link. local link.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 September 12, 2019. This Internet-Draft will expire on September 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
5.2.2. Domain Enumeration via Multicast Queries . . . . . . 13 5.2.2. Domain Enumeration via Multicast Queries . . . . . . 13
5.3. Delegated Subdomain for LDH Host Names . . . . . . . . . 14 5.3. Delegated Subdomain for LDH Host Names . . . . . . . . . 14
5.4. Delegated Subdomain for Reverse Mapping . . . . . . . . . 16 5.4. Delegated Subdomain for Reverse Mapping . . . . . . . . . 16
5.5. Data Translation . . . . . . . . . . . . . . . . . . . . 18 5.5. Data Translation . . . . . . . . . . . . . . . . . . . . 18
5.5.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . 18 5.5.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . 18
5.5.2. Suppressing Unusable Records . . . . . . . . . . . . 19 5.5.2. Suppressing Unusable Records . . . . . . . . . . . . 19
5.5.3. NSEC and NSEC3 queries . . . . . . . . . . . . . . . 20 5.5.3. NSEC and NSEC3 queries . . . . . . . . . . . . . . . 20
5.5.4. No Text Encoding Translation . . . . . . . . . . . . 20 5.5.4. No Text Encoding Translation . . . . . . . . . . . . 20
5.5.5. Application-Specific Data Translation . . . . . . . . 21 5.5.5. Application-Specific Data Translation . . . . . . . . 21
5.6. Answer Aggregation . . . . . . . . . . . . . . . . . . . 23 5.6. Answer Aggregation . . . . . . . . . . . . . . . . . . . 23
6. Administrative DNS Records . . . . . . . . . . . . . . . . . 26 6. Administrative DNS Records . . . . . . . . . . . . . . . . . 27
6.1. DNS SOA (Start of Authority) Record . . . . . . . . . . . 26 6.1. DNS SOA (Start of Authority) Record . . . . . . . . . . . 27
6.2. DNS NS Records . . . . . . . . . . . . . . . . . . . . . 27 6.2. DNS NS Records . . . . . . . . . . . . . . . . . . . . . 28
6.3. DNS SRV Records . . . . . . . . . . . . . . . . . . . . . 27 6.3. DNS Delegation Records . . . . . . . . . . . . . . . . . 28
7. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 28 6.4. DNS SRV Records . . . . . . . . . . . . . . . . . . . . . 29
7.1. On-line signing only . . . . . . . . . . . . . . . . . . 28 7. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 30
7.2. NSEC and NSEC3 Records . . . . . . . . . . . . . . . . . 28 7.1. On-line signing only . . . . . . . . . . . . . . . . . . 30
8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 29 7.2. NSEC and NSEC3 Records . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 31
9.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . 32
9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Implementation Status . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . 35
A.1. Already Implemented and Deployed . . . . . . . . . . . . 36 Appendix A. Implementation Status . . . . . . . . . . . . . . . 38
A.2. Already Implemented . . . . . . . . . . . . . . . . . . . 36 A.1. Already Implemented and Deployed . . . . . . . . . . . . 38
A.3. Partially Implemented . . . . . . . . . . . . . . . . . . 36 A.2. Already Implemented . . . . . . . . . . . . . . . . . . . 38
A.4. Not Yet Implemented . . . . . . . . . . . . . . . . . . . 37 A.3. Partially Implemented . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Multicast DNS [RFC6762] and its companion technology DNS-based Multicast DNS [RFC6762] and its companion technology DNS-based
Service Discovery [RFC6763] were created to provide IP networking Service Discovery [RFC6763] were created to provide IP networking
with the ease-of-use and autoconfiguration for which AppleTalk was with the ease-of-use and autoconfiguration for which AppleTalk was
well known [RFC6760] [ZC] [Roadmap]. well known [RFC6760] [ZC] [Roadmap].
For a small home network consisting of just a single link (or a few For a small home network consisting of just a single link (or a few
physical links bridged together to appear as a single logical link physical links bridged together to appear as a single logical link
skipping to change at page 3, line 32 skipping to change at page 3, line 32
Multicast DNS packets, by design, are not propagated onto other Multicast DNS packets, by design, are not propagated onto other
links. links.
Using link-local multicast packets for Multicast DNS was a conscious Using link-local multicast packets for Multicast DNS was a conscious
design choice [RFC6762]. Even when limited to a single link, design choice [RFC6762]. Even when limited to a single link,
multicast traffic is still generally considered to be more expensive multicast traffic is still generally considered to be more expensive
than unicast, because multicast traffic impacts many devices, instead than unicast, because multicast traffic impacts many devices, instead
of just a single recipient. In addition, with some technologies like of just a single recipient. In addition, with some technologies like
Wi-Fi [IEEE-11], multicast traffic is inherently less efficient and Wi-Fi [IEEE-11], multicast traffic is inherently less efficient and
less reliable than unicast, because Wi-Fi multicast traffic is sent less reliable than unicast, because Wi-Fi multicast traffic is sent
at lower data rates, and is not acknowledged. Increasing the amount at lower data rates, and is not acknowledged [Mcast]. Increasing the
of expensive multicast traffic by flooding it across multiple links amount of expensive multicast traffic by flooding it across multiple
would make the traffic load even worse. links would make the traffic load even worse.
Partitioning the network into many small links curtails the spread of Partitioning the network into many small links curtails the spread of
expensive multicast traffic, but limits the discoverability of expensive multicast traffic, but limits the discoverability of
services. At the opposite end of the spectrum, using a very large services. At the opposite end of the spectrum, using a very large
local link with thousands of hosts enables better service discovery, local link with thousands of hosts enables better service discovery,
but at the cost of larger amounts of multicast traffic. but at the cost of larger amounts of multicast traffic.
Performing DNS-Based Service Discovery using purely Unicast DNS is Performing DNS-Based Service Discovery using purely Unicast DNS is
more efficient and doesn't require large multicast domains, but does more efficient and doesn't require large multicast domains, but does
require that the relevant data be available in the Unicast DNS require that the relevant data be available in the Unicast DNS
namespace. The Unicast DNS namespace in question could fall within a namespace. The Unicast DNS namespace in question could fall within a
traditionally assigned globally unique domain name, or could use a traditionally assigned globally unique domain name, or could use a
private local unicast domain name such as ".home.arpa" private local unicast domain name such as ".home.arpa" [RFC8375].
[I-D.ietf-homenet-dot].)
In the DNS-SD specification [RFC6763], Section 10 ("Populating the In the DNS-SD specification [RFC6763], Section 10 ("Populating the
DNS with Information") discusses various possible ways that a DNS with Information") discusses various possible ways that a
service's PTR, SRV, TXT and address records can make their way into service's PTR, SRV, TXT and address records can make their way into
the Unicast DNS namespace, including manual zone file configuration the Unicast DNS namespace, including manual zone file configuration
[RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007] and proxies of [RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007] and proxies of
various kinds. various kinds.
Making the relevant data available in the Unicast DNS namespace by Making the relevant data available in the Unicast DNS namespace by
manual DNS configuration is one option. This option has been used manual DNS configuration is one option. This option has been used
for many years at IETF meetings to advertise the IETF Terminal Room for many years at IETF meetings to advertise the IETF Terminal Room
printer. Details of this example are given in Appendix A of the printer. Details of this example are given in Appendix A of the
Roadmap document [Roadmap]. However, this manual DNS configuration Roadmap document [Roadmap]. However, this manual DNS configuration
is labor intensive, error prone, and requires a reasonable degree of is labor intensive, error prone, and requires a reasonable degree of
DNS expertise. DNS expertise.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
A similar analogy, instead of enlisting another human being to A similar analogy, instead of enlisting another human being to
initiate the service discovery operation on your behalf, is to log initiate the service discovery operation on your behalf, is to log
into your own desktop work computer using screen sharing, and then into your own desktop work computer using screen sharing, and then
run the printer browser yourself to see the list of printers. Or log run the printer browser yourself to see the list of printers. Or log
in using ssh and type "dns-sd -B _ipp._tcp" and observe the list of in using ssh and type "dns-sd -B _ipp._tcp" and observe the list of
discovered printer names. In neither case is there any risk of a discovered printer names. In neither case is there any risk of a
forwarding loop causing a traffic storm, because no multicast packets forwarding loop causing a traffic storm, because no multicast packets
are being sent over the screen sharing or ssh connection. are being sent over the screen sharing or ssh connection.
The Discovery Proxy provides another way of performing remote The Discovery Proxy provides another way of performing remote
queries, just using a different protocol instead of screen sharing or queries, except using a different protocol instead of screen sharing
ssh. or ssh.
When the Discovery Proxy software performs Multicast DNS operations, When the Discovery Proxy software performs Multicast DNS operations,
the exact same Multicast DNS caching mechanisms are applied as when the exact same Multicast DNS caching mechanisms are applied as when
any other client software on that Discovery Proxy device performs any other client software on that Discovery Proxy device performs
Multicast DNS operations, whether that be running a printer browser Multicast DNS operations, whether that be running a printer browser
client locally, or a remote user running the printer browser client client locally, or a remote user running the printer browser client
via a screen sharing connection, or a remote user logged in via ssh via a screen sharing connection, or a remote user logged in via ssh
running a command-line tool like "dns-sd". running a command-line tool like "dns-sd", or a remote user sending
DNS requests that cause a Discovery Proxy to perform discovery
operations on its behalf.
3. Conventions and Terminology Used in this Document 3. Conventions and Terminology Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described and "OPTIONAL" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels", in "Key words for use in RFCs to Indicate Requirement Levels",
when, and only when, they appear in all capitals, as shown here when, and only when, they appear in all capitals, as shown here
[RFC2119] [RFC8174]. [RFC2119] [RFC8174].
skipping to change at page 10, line 19 skipping to change at page 10, line 19
reaches the delegated authoritative name server for that subdomain, reaches the delegated authoritative name server for that subdomain,
namely the Discovery Proxy on the link in question. Like a namely the Discovery Proxy on the link in question. Like a
conventional Unicast DNS server, a Discovery Proxy implements the conventional Unicast DNS server, a Discovery Proxy implements the
usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP. usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP.
However, unlike a conventional Unicast DNS server that generates However, unlike a conventional Unicast DNS server that generates
answers from the data in its manually-configured zone file, a answers from the data in its manually-configured zone file, a
Discovery Proxy generates answers using Multicast DNS. A Discovery Discovery Proxy generates answers using Multicast DNS. A Discovery
Proxy does this by consulting its Multicast DNS cache and/or issuing Proxy does this by consulting its Multicast DNS cache and/or issuing
Multicast DNS queries, as appropriate, according to the usual Multicast DNS queries, as appropriate, according to the usual
protocol rules of Multicast DNS [RFC6762], for the corresponding protocol rules of Multicast DNS [RFC6762], for the corresponding
Multicast DNS name, type and class, (e.g., in this case, Multicast DNS name, type and class, with the delegated zone part of
the name replaced with ".local" (e.g., in this case,
"_printer._tcp.local. PTR ?"). Then, from the received Multicast DNS "_printer._tcp.local. PTR ?"). Then, from the received Multicast DNS
data, the Discovery Proxy synthesizes the appropriate Unicast DNS data, the Discovery Proxy synthesizes the appropriate Unicast DNS
response. How long the Discovery Proxy should wait to accumulate response, with the ".local" top-level label replaced with with the
Multicast DNS responses is described below in Section 5.6. name of the delegated zone. How long the Discovery Proxy should wait
to accumulate Multicast DNS responses before sending its unicast
reply is described below in Section 5.6.
The existing Multicast DNS caching mechanism is used to minimize The existing Multicast DNS caching mechanism is used to minimize
unnecessary Multicast DNS queries on the wire. The Discovery Proxy unnecessary Multicast DNS queries on the wire. The Discovery Proxy
is acting as a client of the underlying Multicast DNS subsystem, and is acting as a client of the underlying Multicast DNS subsystem, and
benefits from the same caching and efficiency measures as any other benefits from the same caching and efficiency measures as any other
client using that subsystem. client using that subsystem.
Note that the contents of the delegated zone, generated as it is by
performing ".local" Multicast DNS queries, mirrors the records
available on the local link via Multicast DNS very closely, but not
precisely. There is not a full bidirectional equivalence between the
two. Certain records that are available via Multicast DNS may not
have equivalents in the delegated zone, possibly because they are
invalid or not relevant in the delegated zone, or because they are
being supressed because they are unusable outside the local link (see
Section 5.5.2). Conversely, certain records that appear in the
delegated zone may not have corresponding records available on the
local link via Multicast DNS. In particular there are certain
administrative SRV records (see Section 6) that logically fall within
the delegated zone, but semantically represent metadata *about* the
zone rather than records *within* the zone, and consequently these
administrative records in the delegated zone do not have any
corresponding counterparts in the Multicast DNS namespace of the
local link.
5.2. Domain Enumeration 5.2. Domain Enumeration
A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR
queries, using both unicast and multicast. If it receives a Domain queries, using both unicast and multicast. If it receives a Domain
Name configuration via DHCP option 15 [RFC2132], then it issues Name configuration via DHCP option 15 [RFC2132], then it issues
unicast queries using this domain. It issues unicast queries using unicast queries using this domain. It issues unicast queries using
names derived from its IPv4 subnet address(es) and IPv6 prefix(es). names derived from its IPv4 subnet address(es) and IPv6 prefix(es).
These are described below in Section 5.2.1. It also issues multicast These are described below in Section 5.2.1. It also issues multicast
Domain Enumeration queries in the "local" domain [RFC6762]. These Domain Enumeration queries in the "local" domain [RFC6762]. These
are described below in Section 5.2.2. The results of all the Domain are described below in Section 5.2.2. The results of all the Domain
skipping to change at page 18, line 35 skipping to change at page 18, line 35
service shuts down gracefully, it sends goodbye packets to remove its service shuts down gracefully, it sends goodbye packets to remove its
PTR records immediately from neighboring caches. If a service shuts PTR records immediately from neighboring caches. If a service shuts
down abruptly without sending goodbye packets, the Passive down abruptly without sending goodbye packets, the Passive
Observation Of Failures (POOF) mechanism described in Section 10.5 of Observation Of Failures (POOF) mechanism described in Section 10.5 of
the Multicast DNS specification [RFC6762] comes into play to purge the Multicast DNS specification [RFC6762] comes into play to purge
the cache of stale data. the cache of stale data.
A traditional Unicast DNS client on a distant remote link does not A traditional Unicast DNS client on a distant remote link does not
get to participate in these Multicast DNS cache coherency mechanisms get to participate in these Multicast DNS cache coherency mechanisms
on the local link. For traditional Unicast DNS queries (those on the local link. For traditional Unicast DNS queries (those
received without using Long-Lived Query [DNS-LLQ] or DNS Push received without using Long-Lived Query [LLQ] or DNS Push
Notification subscriptions [Push]) the DNS TTLs reported in the Notification subscriptions [Push]) the DNS TTLs reported in the
resulting Unicast DNS response MUST be capped to be no more than ten resulting Unicast DNS response MUST be capped to be no more than ten
seconds. seconds.
Similarly, for negative responses, the negative caching TTL indicated Similarly, for negative responses, the negative caching TTL indicated
in the SOA record [RFC2308] should also be ten seconds (Section 6.1). in the SOA record [RFC2308] should also be ten seconds (Section 6.1).
This value of ten seconds is chosen based on user-experience This value of ten seconds is chosen based on user-experience
considerations. considerations.
skipping to change at page 19, line 23 skipping to change at page 19, line 23
or other renumbering events, we would like the updated information to or other renumbering events, we would like the updated information to
be available to remote clients in a relatively timely fashion. be available to remote clients in a relatively timely fashion.
However, network administrators should be aware that many recursive However, network administrators should be aware that many recursive
(caching) DNS servers by default are configured to impose a minimum (caching) DNS servers by default are configured to impose a minimum
TTL of 30 seconds. If stale data appears to be persisting in the TTL of 30 seconds. If stale data appears to be persisting in the
network to the extent that it adversely impacts user experience, network to the extent that it adversely impacts user experience,
network administrators are advised to check the configuration of network administrators are advised to check the configuration of
their recursive DNS servers. their recursive DNS servers.
For received Unicast DNS queries that use LLQ [DNS-LLQ] or DNS Push For received Unicast DNS queries that use LLQ [LLQ] or DNS Push
Notifications [Push], the Multicast DNS record's TTL SHOULD be Notifications [Push], the Multicast DNS record's TTL SHOULD be
returned unmodified, because the Push Notification channel exists to returned unmodified, because the Push Notification channel exists to
inform the remote client as records come and go. For further details inform the remote client as records come and go. For further details
about Long-Lived Queries, and its newer replacement, DNS Push about Long-Lived Queries, and its newer replacement, DNS Push
Notifications, see Section 5.6. Notifications, see Section 5.6.
5.5.2. Suppressing Unusable Records 5.5.2. Suppressing Unusable Records
A Discovery Proxy SHOULD suppress Unicast DNS answers for records A Discovery Proxy SHOULD offer a configurable option, enabled by
that are not useful outside the local link. For example, DNS A and default, to suppress Unicast DNS answers for records that are not
AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 link- useful outside the local link. When the option to suppress unusable
local addresses [RFC4862] SHOULD be suppressed. Similarly, for sites records is enabled:
that have multiple private address realms [RFC1918], in cases where
the Discovery Proxy can determine that the querying client is in a
different address realm, private addresses SHOULD NOT be communicated
to that client. IPv6 Unique Local Addresses [RFC4193] SHOULD be
suppressed in cases where the Discovery Proxy can determine that the
querying client is in a different IPv6 address realm.
By the same logic, DNS SRV records that reference target host names o DNS A and AAAA records for IPv4 link-local addresses [RFC3927] and
that have no addresses usable by the requester should be suppressed, IPv6 link-local addresses [RFC4862] SHOULD be suppressed.
and likewise, DNS PTR records that point to unusable SRV records
should be similarly be suppressed. o Similarly, for sites that have multiple private address realms
[RFC1918], in cases where the Discovery Proxy can determine that
the querying client is in a different address realm, private
addresses SHOULD NOT be communicated to that client.
o IPv6 Unique Local Addresses [RFC4193] SHOULD be suppressed in
cases where the Discovery Proxy can determine that the querying
client is in a different IPv6 address realm.
o 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.
5.5.3. NSEC and NSEC3 queries 5.5.3. NSEC and NSEC3 queries
Multicast DNS devices do not routinely announce their records on the Multicast DNS devices do not routinely announce their records on the
network. Generally they remain silent until queried. This means network. Generally they remain silent until queried. This means
that the complete set of Multicast DNS records in use on a link can that the complete set of Multicast DNS records in use on a link can
only be discovered by active querying, not by passive listening. only be discovered by active querying, not by passive listening.
Because of this, a Discovery Proxy can only know what names exist on Because of this, a Discovery Proxy can only know what names exist on
a link by issuing queries for them, and since it would be impractical a 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 to issue queries for every possible name just to find out which names
skipping to change at page 23, line 29 skipping to change at page 23, line 29
the subdomain in question -- needs to decide what DNS TTL to report the subdomain in question -- needs to decide what DNS TTL to report
for these records. If the TTL is too long then the recursive for these records. If the TTL is too long then the recursive
(caching) name servers issuing queries on behalf of their clients (caching) name servers issuing queries on behalf of their clients
risk caching stale data for too long. If the TTL is too short then risk caching stale data for too long. If the TTL is too short then
the amount of network traffic will be more than necessary. In fact, the amount of network traffic will be more than necessary. In fact,
there may be no TTL which is both short enough to avoid undesirable there may be no TTL which is both short enough to avoid undesirable
stale data and at the same time long enough to be efficient on the stale data and at the same time long enough to be efficient on the
network. network.
Both these dilemmas are solved by use of DNS Long-Lived Queries Both these dilemmas are solved by use of DNS Long-Lived Queries
(DNS LLQ) [DNS-LLQ] or its newer replacement, DNS Push Notifications (DNS LLQ) [LLQ] or its newer replacement, DNS Push Notifications
[Push]. [Push].
Clients supporting unicast DNS Service Discovery SHOULD implement DNS Clients supporting unicast DNS Service Discovery SHOULD implement DNS
Push Notifications [Push] for improved user experience. Push Notifications [Push] for improved user experience.
Clients and Discovery Proxies MAY support both DNS LLQ and DNS Push, Clients and Discovery Proxies MAY support both DNS LLQ and DNS Push,
and when talking to a Discovery Proxy that supports both, the client and when talking to a Discovery Proxy that supports both, the client
may use either protocol, as it chooses, though it is expected that may use either protocol, as it chooses, though it is expected that
only DNS Push will continue to be supported in the long run. only DNS Push will continue to be supported in the long run.
skipping to change at page 24, line 43 skipping to change at page 24, line 43
query on the local link for the desired record name, type and query on the local link for the desired record name, type and
class, including retransmissions, as appropriate, according to the class, including retransmissions, as appropriate, according to the
established mDNS retransmission schedule [RFC6762]. As soon as established mDNS retransmission schedule [RFC6762]. As soon as
any Multicast DNS response packet is received that contains one or any Multicast DNS response packet is received that contains one or
more positive answers to that question (with or without the Cache more positive answers to that question (with or without the Cache
Flush bit [RFC6762] set), or a negative answer (signified via a Flush bit [RFC6762] set), or a negative answer (signified via a
Multicast DNS NSEC record [RFC6762]), the Discovery Proxy Multicast DNS NSEC record [RFC6762]), the Discovery Proxy
generates a Unicast DNS response packet containing the generates a Unicast DNS response packet containing the
corresponding (filtered and translated) answers and sends it to corresponding (filtered and translated) answers and sends it to
the remote client. If after six seconds no Multicast DNS answers the remote client. If after six seconds no Multicast DNS answers
have been received, return a negative response to the remote have been received, cancel the mDNS query and return a negative
client. Six seconds is enough time to transmit three mDNS response to the remote client. Six seconds is enough time to
queries, and allow some time for responses to arrive. transmit three mDNS queries, and allow some time for responses to
arrive.
DNS TTLs in responses MUST be capped to at most ten seconds. DNS TTLs in responses MUST be capped to at most ten seconds.
(Reasoning: Queries not using LLQ or Push Notifications are (Reasoning: Queries not using LLQ or Push Notifications are
generally queries that that expect an answer from only one device, generally queries that that expect an answer from only one device,
so the first response is also the only response.) so the first response is also the only response.)
o Not using LLQ or Push Notifications; at least one answer in cache: o Not using LLQ or Push Notifications; at least one answer in cache:
Send response right away to minimise delay. Send response right away to minimise delay.
DNS TTLs in responses MUST be capped to at most ten seconds. DNS TTLs in responses MUST be capped to at most ten seconds.
No local mDNS queries are performed. No local mDNS queries are performed.
(Reasoning: Queries not using LLQ or Push Notifications are (Reasoning: Queries not using LLQ or Push Notifications are
skipping to change at page 25, line 42 skipping to change at page 25, line 42
The query remains active for as long as the client maintains the The query remains active for as long as the client maintains the
LLQ or Push Notification state, and results in transmission of LLQ or Push Notification state, and results in transmission of
mDNS queries, with appropriate Known Answer lists, to determine if mDNS queries, with appropriate Known Answer lists, to determine if
further answers are available. If additional mDNS answers are further answers are available. If additional mDNS answers are
received later, LLQ or Push Notification messages are sent. received later, LLQ or Push Notification messages are sent.
(Reasoning: We want UI that is displayed very rapidly, yet (Reasoning: We want UI that is displayed very rapidly, yet
continues to remain accurate even as the network environment continues to remain accurate even as the network environment
changes.) changes.)
DNS TTLs in responses are returned unmodified. DNS TTLs in responses are returned unmodified.
Note that the "negative responses" referred to above are "no error no The "negative responses" referred to above are "no error no answer"
answer" negative responses, not NXDOMAIN. This is because the negative responses, not NXDOMAIN. This is because the Discovery
Discovery Proxy cannot know all the Multicast DNS domain names that Proxy cannot know all the Multicast DNS domain names that may exist
may exist on a link at any given time, so any name with no answers on a link at any given time, so any name with no answers may have
may have child names that do exist, making it an "empty nonterminal" child names that do exist, making it an "empty nonterminal" name.
name.
Note that certain aspects of the behavior described here do not have
to be implemented overtly by the Discovery Proxy; they occur
naturally as a result of using existing Multicast DNS APIs.
For example, in the first case above (no LLQ or Push Notifications,
and no answers in the cache) if a new Multicast DNS query is
requested (either by a local client, or by the Discovery Proxy on
behalf of a remote client), and there is not already an identical
Multicast DNS query active, and there are no matching answers already
in the Multicast DNS cache on the Discovery Proxy device, then this
will cause a series of Multicast DNS query packets to be issued with
exponential backoff. The exponential backoff sequence in some
implementations starts at one second and then doubles for each
retransmission (0, 1, 3, 7 seconds, etc.) and in others starts at one
second and then triples for each retransmission (0, 1, 4, 13 seconds,
etc.). In either case, if no response has been received after six
seconds, that is long enough that the underlying Multicast DNS
implementation will have sent three query packets without receiving
any response. At that point the Discovery Proxy cancels its
Multicast DNS query (so no further Multicast DNS query packets will
be sent for this query) and returns a negative response to the remote
client via unicast.
The six-second delay is chosen to be long enough to give enough time
for devices to respond, yet short enough not to be too onerous for a
human user waiting for a response. For example, using the "dig" DNS
debugging tool, the current default settings result in it waiting a
total of 15 seconds for a reply (three transmissions of the query
packet, with a wait of 5 seconds after each packet) which is ample
time for it to have received a negative reply from a Discovery Proxy
after six seconds.
The statement that for a one-shot query (i.e., no LLQ or Push
Notifications requested), if at least one answer is already available
in the cache then a Discovery Proxy should not issue additional mDNS
query packets, also occurs naturally as a result of using existing
Multicast DNS APIs. If a new Multicast DNS query is requested
(either locally, or by the Discovery Proxy on behalf of a remote
client), for which there are relevant answers already in the
Multicast DNS cache on the Discovery Proxy device, and after the
answers are delivered the Multicast DNS query is then cancelled
immediately, then no Multicast DNS query packets will be generated
for this query.
6. Administrative DNS Records 6. Administrative DNS Records
6.1. DNS SOA (Start of Authority) Record 6.1. DNS SOA (Start of Authority) Record
The MNAME field SHOULD contain the host name of the Discovery Proxy The MNAME field SHOULD contain the host name of the Discovery Proxy
device (i.e., the same domain name as the rdata of the NS record device (i.e., the same domain name as the rdata of the NS record
delegating the relevant zone(s) to this Discovery Proxy device). delegating the relevant zone(s) to this Discovery Proxy device).
The RNAME field SHOULD contain the mailbox of the person responsible The RNAME field SHOULD contain the mailbox of the person responsible
skipping to change at page 27, line 9 skipping to change at page 28, line 9
link for fault tolerance reasons, this will result in clients link for fault tolerance reasons, this will result in clients
receiving inconsistent SOA records (different MNAME, and possibly receiving inconsistent SOA records (different MNAME, and possibly
RNAME) depending on which Discovery Proxy answers their SOA query. RNAME) depending on which Discovery Proxy answers their SOA query.
However, since clients generally have no reason to use the MNAME or However, since clients generally have no reason to use the MNAME or
RNAME data, this is unlikely to cause any problems. RNAME data, this is unlikely to cause any problems.
6.2. DNS NS Records 6.2. DNS NS Records
In the event that there are multiple Discovery Proxy devices on a In the event that there are multiple Discovery Proxy devices on a
link for fault tolerance reasons, the parent zone MUST be configured link for fault tolerance reasons, the parent zone MUST be configured
with glue records giving the names and addresses of all the Discovery with NS records giving the names of all the Discovery Proxy devices
Proxy devices on the link. on the link.
Each Discovery Proxy device MUST be configured with its own NS Each Discovery Proxy device MUST be configured to answer NS queries
record, and with the NS records of its fellow Discovery Proxy devices for the zone apex name by giving its own NS record, and the NS
on the same link, so that it can return the correct answers for NS records of its fellow Discovery Proxy devices on the same link, so
queries. that it can return the correct answers for NS queries.
6.3. DNS SRV Records The target host name in the RDATA of an NS record MUST NOT reference
a name that falls within any zone delegated to a Discovery Proxy.
Apart from the zone apex name, all other host names that fall within
a zone delegated to a Discovery Proxy correspond to local Multicast
DNS host names, which logically belong to the respective Multicast
DNS hosts defending those names, not the Discovery Proxy. Generally
speaking, the Discovery Proxy does not own or control the delegated
zone; it is merely a conduit to the corresponding ".local" namespace,
which is controlled by the Multicast DNS hosts on that link. If an
NS record were to reference a manually-determined host name that
falls within a delegated zone, that manually-determined host name may
inadvertently conflict with a corresponding ".local" host name that
is owned and controlled by some device on that link.
6.3. DNS Delegation Records
Since the Multicast DNS specification [RFC6762] states that there can
be no delegation (subdomains) within a ".local" namespace, this
implies that any name within a zone delegated to a Discovery Proxy
(except for the zone apex name itself) cannot have any answers for
any DNS queries for RRTYPEs SOA, NS, or DS. Consequently:
o for any query for the zone apex name of a zone delegated to a
Discovery Proxy, the Discovery Proxy MUST generate the appropriate
immediate answers as described above, and
o for any query for RRTYPEs SOA, NS, or DS, for any name within a
zone delegated to a Discovery Proxy, other than the zone apex
name, instead of translating the query to its corresponding
Multicast DNS ".local" equivalent, a Discovery Proxy MUST generate
an immediate negative answer.
6.4. DNS SRV Records
There are certain special DNS records that logically fall within the There are certain special DNS records that logically fall within the
delegated unicast DNS subdomain, but rather than mapping to their delegated unicast DNS subdomain, but rather than mapping to their
corresponding ".local" namesakes, they actually contain metadata corresponding ".local" namesakes, they actually contain metadata
pertaining to the operation of the delegated unicast DNS subdomain pertaining to the operation of the delegated unicast DNS subdomain
itself. They do not exist in the corresponding ".local" namespace of itself. They do not exist in the corresponding ".local" namespace of
the local link. For these queries a Discovery Proxy MUST generate the local link. For these queries a Discovery Proxy MUST generate
immediate answers, whether positive or negative, to avoid delays immediate answers, whether positive or negative, to avoid delays
while clients wait for their query to be answered. For example, if a while clients wait for their query to be answered. For example, if a
Discovery Proxy does not implement Long-Lived Queries [DNS-LLQ] then Discovery Proxy does not implement Long-Lived Queries [LLQ] then it
it MUST return an immediate negative answer to tell the client this MUST return an immediate negative answer to tell the client this
without delay, instead of passing the query through to the local without delay, instead of passing the query through to the local
network as a query for "_dns-llq._udp.local.", and then waiting network as a query for "_dns-llq._udp.local.", and then waiting
unsuccessfully for answers that will not be forthcoming. unsuccessfully for answers that will not be forthcoming.
If a Discovery Proxy implements Long-Lived Queries [DNS-LLQ] then it If a Discovery Proxy implements Long-Lived Queries [LLQ] then it MUST
MUST positively respond to "_dns-llq._udp.<zone> SRV" queries, positively respond to "_dns-llq._udp.<zone> SRV" queries,
"_dns-llq._tcp.<zone> SRV" queries, and "_dns-llq-tls._tcp.<zone> "_dns-llq._tcp.<zone> SRV" queries, and
SRV" queries as appropriate, else it MUST return an immediate "_dns-llq-tls._tcp.<zone> SRV" queries as appropriate, else it MUST
negative answer for those queries. return an immediate negative answer for those queries.
If a Discovery Proxy implements DNS Push Notifications [Push] then it If a Discovery Proxy implements DNS Push Notifications [Push] then it
MUST positively respond to "_dns-push-tls._tcp.<zone>" queries, else MUST positively respond to "_dns-push-tls._tcp.<zone>" queries, else
it MUST return an immediate negative answer for those queries. it MUST return an immediate negative answer for those queries.
A Discovery Proxy MUST return an immediate negative answer for A Discovery Proxy MUST return an immediate negative answer for
"_dns-update._udp.<zone> SRV" queries, "_dns-update._tcp.<zone> SRV" "_dns-update._udp.<zone> SRV" queries, "_dns-update._tcp.<zone> SRV"
queries, and "_dns-update-tls._tcp.<zone> SRV" queries, since using queries, and "_dns-update-tls._tcp.<zone> SRV" queries, since using
DNS Update [RFC2136] to change zones generated dynamically from local DNS Update [RFC2136] to change zones generated dynamically from local
Multicast DNS data is not possible. Multicast DNS data is not possible.
skipping to change at page 33, line 26 skipping to change at page 35, line 26
editor.org/info/rfc6762>. editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
draft-ietf-dnssd-push-14 (work in progress), March 2018.
[DSO] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
draft-ietf-dnsop-session-signal-07 (work in progress), RFC 8490, DOI 10.17487/RFC8490, March 2019,
March 2018. <https://www.rfc-editor.org/info/rfc8490>.
12.2. Informative References [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-19 (work in progress), March 2019.
[I-D.ietf-homenet-dot] 12.2. Informative References
Pfister, P. and T. Lemon, "Special Use Domain
'home.arpa.'", draft-ietf-homenet-dot-14 (work in
progress), September 2017.
[Roadmap] Cheshire, S., "Service Discovery Road Map", draft- [Roadmap] Cheshire, S., "Service Discovery Road Map", draft-
cheshire-dnssd-roadmap-03 (work in progress), October cheshire-dnssd-roadmap-03 (work in progress), October
2018. 2018.
[DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns-
ul-01 (work in progress), August 2006. ul-01 (work in progress), August 2006.
[DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- [LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries",
llq-01 (work in progress), August 2006. draft-sekar-dns-llq-03 (work in progress), March 2019.
[RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service- for DNS-Based Service Discovery", draft-sctl-service-
registration-00 (work in progress), July 2017. registration-00 (work in progress), July 2017.
[Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery [Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery
Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress), Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress),
March 2018. March 2018.
[Mcast] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work
in progress), November 2018.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>. <https://www.rfc-editor.org/info/rfc2132>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
skipping to change at page 35, line 5 skipping to change at page 37, line 5
editor.org/info/rfc7558>. editor.org/info/rfc7558>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, <https://www.rfc- DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
editor.org/info/rfc7626>. editor.org/info/rfc7626>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>. 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
<https://www.rfc-editor.org/info/rfc8375>.
[ohp] "Discovery Proxy (Hybrid Proxy) implementation for [ohp] "Discovery Proxy (Hybrid Proxy) implementation for
OpenWrt", <https://github.com/sbyx/ohybridproxy/>. OpenWrt", <https://github.com/sbyx/ohybridproxy/>.
[ZC] Cheshire, S. and D. Steinberg, "Zero Configuration [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration
Networking: The Definitive Guide", O'Reilly Media, Inc. , Networking: The Definitive Guide", O'Reilly Media, Inc. ,
ISBN 0-596-10100-7, December 2005. ISBN 0-596-10100-7, December 2005.
[IEEE-1Q] "IEEE Standard for Local and metropolitan area networks -- [IEEE-1Q] "IEEE Standard for Local and metropolitan area networks --
Bridges and Bridged Networks", IEEE Std 802.1Q-2014, Bridges and Bridged Networks", IEEE Std 802.1Q-2014,
November 2014, <http://standards.ieee.org/getieee802/ November 2014, <http://standards.ieee.org/getieee802/
skipping to change at page 36, line 40 skipping to change at page 38, line 40
details of this particular specific example is given in Appendix A of details of this particular specific example is given in Appendix A of
the Roadmap document [Roadmap]. the Roadmap document [Roadmap].
A.2. Already Implemented A.2. Already Implemented
A minimal portable Discovery Proxy implementation has been produced A minimal portable Discovery Proxy implementation has been produced
by Markus Stenberg and Steven Barth, which runs on OS X and several by Markus Stenberg and Steven Barth, which runs on OS X and several
Linux variants including OpenWrt [ohp]. It was demonstrated at the Linux variants including OpenWrt [ohp]. It was demonstrated at the
Berlin IETF in July 2013. Berlin IETF in July 2013.
Tom Pusateri also has an implementation that runs on any Unix/Linux. Tom Pusateri has an implementation that runs on any Unix/Linux. It
It has a RESTful interface for management and an experimental demo has a RESTful interface for management and an experimental demo CLI
CLI and web interface. and web interface.
Ted Lemon also has produced a portable implementation of Discovery
Proxy, which is available in the mDNSResponder open source code.
The Long-Lived Query mechanism [LLQ] referred to in this
specification exists and is deployed, but was not standardized by the
IETF. The IETF has developed a superior Long-Lived Query mechanism
called DNS Push Notifications [Push], which is built on DNS Stateful
Operations [RFC8490]. The pragmatic short-term deployment approach
is for vendors to produce Discovery Proxies that implement both the
deployed Long-Lived Query mechanism [LLQ] (for today's clients) and
the new DNS Push Notifications mechanism [Push] as the preferred
long-term direction.
A.3. Partially Implemented A.3. Partially Implemented
The current APIs make multiple domains visible to client software, The current APIs make multiple domains visible to client software,
but most client UI today lumps all discovered services into a single but most client UI today lumps all discovered services into a single
flat list. This is largely a chicken-and-egg problem. Application flat list. This is largely a chicken-and-egg problem. Application
writers were naturally reluctant to spend time writing domain-aware writers were naturally reluctant to spend time writing domain-aware
UI code when few customers today would benefit from it. If Discovery UI code when few customers today would benefit from it. If Discovery
Proxy deployment becomes common, then application writers will have a Proxy deployment becomes common, then application writers will have a
reason to provide better UI. Existing applications will work with reason to provide better UI. Existing applications will work with
the Discovery Proxy, but will show all services in a single flat the Discovery Proxy, but will show all services in a single flat
list. Applications with improved UI will group services by domain. list. Applications with improved UI will group services by domain.
The Long-Lived Query mechanism [DNS-LLQ] referred to in this
specification exists and is deployed, but has not been standardized
by the IETF. The IETF is developing a superior Long-Lived Query
mechanism called DNS Push Notifications [Push], which is based on DNS
Stateful Operations [DSO],. The pragmatic short-term deployment
approach is for vendors to produce Discovery Proxies that implement
both the deployed Long-Lived Query mechanism [DNS-LLQ] (for today's
clients) and the new DNS Push Notifications mechanism [Push] as the
preferred long-term direction.
Implementations of the translating/filtering Discovery Proxy
specified in this document are under development, and operational
experience with these implementations has guided updates to this
document.
A.4. Not Yet Implemented
Client implementations of the new DNS Push Notifications mechanism
[Push] are currently underway.
Author's Address Author's Address
Stuart Cheshire Stuart Cheshire
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014 Cupertino, California 95014
USA USA
Phone: +1 (408) 996-1010 Phone: +1 (408) 996-1010
Email: cheshire@apple.com Email: cheshire@apple.com
 End of changes. 33 change blocks. 
114 lines changed or deleted 216 lines changed or added

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