draft-ietf-dnsext-mdns-41.txt   draft-ietf-dnsext-mdns-42.txt 
DNSEXT Working Group Bernard Aboba DNSEXT Working Group Bernard Aboba
INTERNET-DRAFT Dave Thaler INTERNET-DRAFT Dave Thaler
Category: Standards Track Levon Esibov Category: Standards Track Levon Esibov
<draft-ietf-dnsext-mdns-41.txt> Microsoft <draft-ietf-dnsext-mdns-42.txt> Microsoft Corporation
15 July 2005 4 August 2005
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 22, 2006. This Internet-Draft will expire on February 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. Copyright (C) The Internet Society 2005.
Abstract Abstract
The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
name resolution in scenarios in which conventional DNS name name resolution in scenarios in which conventional DNS name
resolution is not possible. LLMNR supports all current and future resolution is not possible. LLMNR supports all current and future
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 4 1.1 Requirements .................................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Name Resolution Using LLMNR ........................... 4 2. Name Resolution Using LLMNR ........................... 4
2.1 LLMNR Packet Format ............................. 6 2.1 LLMNR Packet Format ............................. 6
2.2 Sender Behavior ................................. 9 2.2 Sender Behavior ................................. 9
2.3 Responder Behavior .............................. 9 2.3 Responder Behavior .............................. 9
2.4 Unicast Queries ................................. 11 2.4 Unicast Queries and Responses ................... 11
2.5 Off-link Detection .............................. 12 2.5 Off-link Detection .............................. 12
2.6 Responder Responsibilities ...................... 13 2.6 Responder Responsibilities ...................... 13
2.7 Retransmission and Jitter ....................... 13 2.7 Retransmission and Jitter ....................... 13
2.8 DNS TTL ......................................... 15 2.8 DNS TTL ......................................... 15
2.9 Use of the Authority and Additional Sections .... 15 2.9 Use of the Authority and Additional Sections .... 15
3. Usage model ........................................... 15 3. Usage model ........................................... 15
3.1 LLMNR Configuration ............................. 16 3.1 LLMNR Configuration ............................. 16
4. Conflict Resolution ................................... 18 4. Conflict Resolution ................................... 18
4.1 Uniqueness Verification ......................... 18 4.1 Uniqueness Verification ......................... 18
4.2 Conflict Detection and Defense .................. 19 4.2 Conflict Detection and Defense .................. 19
4.3 Considerations for Multiple Interfaces .......... 20 4.3 Considerations for Multiple Interfaces .......... 20
4.4 API issues ...................................... 21 4.4 API issues ...................................... 21
5. Security Considerations ............................... 22 5. Security Considerations ............................... 22
5.1 Scope Restriction ............................... 22 5.1 Denial of Service ............................... 22
5.2 Usage Restriction ............................... 23 5.2 Spoofing ...............,........................ 22
5.3 Cache and Port Separation ....................... 24 5.3 Authentication .................................. 23
5.4 Authentication .................................. 24 5.4 Cache and Port Separation ....................... 24
6. IANA considerations ................................... 24 6. IANA considerations ................................... 24
7. Constants ............................................. 24 7. Constants ............................................. 25
8. References ............................................ 25 8. References ............................................ 25
8.1 Normative References ............................ 25 8.1 Normative References ............................ 25
8.2 Informative References .......................... 25 8.2 Informative References .......................... 26
Acknowledgments .............................................. 27 Acknowledgments .............................................. 27
Authors' Addresses ........................................... 27 Authors' Addresses ........................................... 27
Intellectual Property Statement .............................. 27 Intellectual Property Statement .............................. 28
Disclaimer of Validity ....................................... 28 Disclaimer of Validity ....................................... 28
Copyright Statement .......................................... 28 Copyright Statement .......................................... 29
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which is based on the DNS packet format and supports all current and which is based on the DNS packet format and supports all current and
future DNS formats, types and classes. LLMNR operates on a separate future DNS formats, types and classes. LLMNR operates on a separate
port from the Domain Name System (DNS), with a distinct resolver port from the Domain Name System (DNS), with a distinct resolver
cache. cache.
The goal of LLMNR is to enable name resolution in scenarios in which The goal of LLMNR is to enable name resolution in scenarios in which
skipping to change at page 5, line 51 skipping to change at page 5, line 51
stack host SHOULD attempt to reach DNS servers over all stack host SHOULD attempt to reach DNS servers over all
protocols on which DNS server address(es) are configured, protocols on which DNS server address(es) are configured,
prior to use of LLMNR. prior to use of LLMNR.
A typical sequence of events for LLMNR usage is as follows: A typical sequence of events for LLMNR usage is as follows:
[a] DNS servers are not configured or attempts to resolve the [a] DNS servers are not configured or attempts to resolve the
name via DNS have failed, after exhausting the searchlist. name via DNS have failed, after exhausting the searchlist.
[b] An LLMNR sender sends an LLMNR query to the link-scope [b] An LLMNR sender sends an LLMNR query to the link-scope
multicast address(es) defined in Section 2, unless a multicast address(es) defined above, unless a unicast
unicast query is indicated. A sender SHOULD send LLMNR query is indicated. A sender SHOULD send LLMNR queries
queries for PTR RRs via unicast, as specified in Section 2.4. for PTR RRs via unicast, as specified in Section 2.4.
[c] A responder responds to this query only if it is authoritative [c] A responder responds to this query only if it is authoritative
for the domain name in the query. A responder responds to a for the domain name in the query. A responder responds to a
multicast query by sending a unicast UDP response to the sender. multicast query by sending a unicast UDP response to the sender.
Unicast queries are responded to as indicated in Section 2.4. Unicast queries are responded to as indicated in Section 2.4.
[d] Upon reception of the response, the sender processes it. [d] Upon reception of the response, the sender processes it.
Further details of sender and responder behavior are provided in the Further details of sender and responder behavior are provided in the
sections that follow. sections that follow.
skipping to change at page 7, line 45 skipping to change at page 7, line 45
length greater than that permitted on the transmission channel. length greater than that permitted on the transmission channel.
The TC bit MUST NOT be set in an LLMNR query and if set is ignored The TC bit MUST NOT be set in an LLMNR query and if set is ignored
by an LLMNR responder. If the TC bit is set in an LLMNR response, by an LLMNR responder. If the TC bit is set in an LLMNR response,
then the sender SHOULD discard the response and resend the LLMNR then the sender SHOULD discard the response and resend the LLMNR
query over TCP using the unicast address of the responder as the query over TCP using the unicast address of the responder as the
destination address. See [RFC2181] and Section 2.4 of this destination address. See [RFC2181] and Section 2.4 of this
specification for further discussion of the TC bit. specification for further discussion of the TC bit.
T Tentative. The 'T'entative bit is set in a response if the T Tentative. The 'T'entative bit is set in a response if the
responder is authoritative for the name, but has not yet verified responder is authoritative for the name, but has not yet verified
the uniqueness of one or more of the resource record(s) in the the uniqueness of the name. A responder MUST ignore the 'T' bit in
answer section. A responder MUST ignore the 'T' bit in a query, if a query, if set. A response with the 'T' bit set is silently
set. If a uniqueness query elicits a response with the 'T' bit discarded by the sender, except if it is a uniqueness query, in
set, a conflict has been detected and a responder MUST resolve the which case a conflict has been detected and a responder MUST
conflict as described in Section 4.1. Otherwise, a response with resolve the conflict as described in Section 4.1.
the 'T' bit set is silently discarded by the sender.
Z Reserved for future use. Implementations of this specification Z Reserved for future use. Implementations of this specification
MUST set these bits to zero in both queries and responses. If MUST set these bits to zero in both queries and responses. If
these bits are set in a LLMNR query or response, implementations of these bits are set in a LLMNR query or response, implementations of
this specification MUST ignore them. Since reserved bits could this specification MUST ignore them. Since reserved bits could
conceivably be used for different purposes than in DNS, conceivably be used for different purposes than in DNS,
implementors are advised not to enable processing of these bits in implementors are advised not to enable processing of these bits in
an LLMNR implementation starting from a DNS code base. an LLMNR implementation starting from a DNS code base.
RCODE RCODE
skipping to change at page 22, line 8 skipping to change at page 22, line 8
multiple addrinfo structures, each with an associated sockaddr_in6 multiple addrinfo structures, each with an associated sockaddr_in6
structure. This list will thus contain the IPv4 and IPv6 addresses structure. This list will thus contain the IPv4 and IPv6 addresses
of both hosts responding to the name 'A'. Link-local addresses will of both hosts responding to the name 'A'. Link-local addresses will
have a sin6_scope_id value that disambiguates which interface is used have a sin6_scope_id value that disambiguates which interface is used
to reach the address. Of course, to the application, Figures 2 and 3 to reach the address. Of course, to the application, Figures 2 and 3
are still indistinguishable, but this API allows the application to are still indistinguishable, but this API allows the application to
communicate successfully with any address in the list. communicate successfully with any address in the list.
5. Security Considerations 5. Security Considerations
LLMNR is by nature a peer-to-peer name resolution protocol. It is LLMNR is a peer-to-peer name resolution protocol designed for use on
therefore inherently more vulnerable than DNS, since existing DNS the local link. While LLMNR limits the vulnerability of responders
security mechanisms are difficult to apply to LLMNR. While tools to off-link senders, it is possible for an off-link responder to
exist to allow an attacker to spoof a response to a DNS query, reach a sender.
spoofing a response to an LLMNR query is easier since the query is
sent to a link-scope multicast address, where every host on the
logical link will be made aware of it.
In order to address the security vulnerabilities, the following
mechanisms are contemplated:
[1] Scope restrictions. In scenarios such as public "hotspots" attackers can be present on
[2] Usage restrictions. the same link. These threats are most serious in wireless networks
[3] Cache and port separation. such as 802.11, since attackers on a wired network will require
[4] Authentication. physical access to the network, while wireless attackers may mount
attacks from a distance. Link-layer security such as [IEEE-802.11i]
can be of assistance against these threats if it is available.
These techniques are described in the following sections. This section details security measures available to mitigate threats
from on and off-link attackers.
5.1. Scope Restriction 5.1. Denial of Service
With LLMNR it is possible that hosts will allocate conflicting names Attackers may take advantage of LLMNR conflict detection by
for a period of time, or that attackers will attempt to deny service allocating the same name, denying service to other LLMNR responders
to other hosts by allocating the same name. Such attacks also allow and possibly allowing an attacker to receive packets destined for
hosts to receive packets destined for other hosts. other hosts. By logging conflicts, LLMNR responders can provide
forensic evidence of these attacks.
Since LLMNR is typically deployed in situations where no trust model An attacker may spoof LLMNR queries from a victim's address in order
can be assumed, it is likely that LLMNR queries and responses will be to mount a denial of service attack. Responders setting the IPv6 Hop
unauthenticated. In the absence of authentication, LLMNR reduces the Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
exposure to such threats by utilizing UDP queries sent to a link- response may be able to reach the victim across the Internet.
scope multicast address, as well as setting the TTL (IPv4) or Hop
Limit (IPv6) fields to one (1) on unicast queries and responses.
Using a TTL of one (1) in order to send a unicast LLMNR query reduces While LLMNR responders only respond to queries for which they are
the likelihood of both denial of service attacks and spoofed authoritative and LLMNR does not provide wildcard query support, an
responses. Checking that an LLMNR query is sent to a link-scope LLMNR response may be larger than the query, and an attacker can
multicast address should prevent spoofing of multicast queries by generate multiple responses to a query for a name used by multiple
off-link attackers. responders. A sender may protect itself against unsolicited
responses by silently discarding them as rapidly as possible.
While this limits the ability of off-link attackers to spoof LLMNR 5.2. Spoofing
queries and responses, it does not eliminate it. For example, it is
possible for an attacker to spoof a response to a query (such as an A
or AAAA query for a popular Internet host), and by using a TTL or Hop
Limit field larger than one (1), for the forged response to reach the
LLMNR sender.
When LLMNR queries are sent to a link-scope multicast address, it is LLMNR is designed to prevent reception of queries sent by an off-link
attacker. LLMNR requires that responders receiving UDP queries check
that they are sent to a link-scope multicast address. However, it is
possible that some routers may not properly implement link-scope possible that some routers may not properly implement link-scope
multicast, or that link-scope multicast addresses may leak into the multicast, or that link-scope multicast addresses may leak into the
multicast routing system. multicast routing system. To prevent successful setup of TCP
connections by an off-link sender, responders receiving a TCP SYN
Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than reply with a TCP SYN-ACK with TTL set to one (1).
one in an LLMNR UDP response may enable denial of service attacks
across the Internet. However, since LLMNR responders only respond to
queries for which they are authoritative, and LLMNR does not provide
wildcard query support, it is believed that this threat is minimal.
There also are scenarios such as public "hotspots" where attackers
can be present on the same link. These threats are most serious in
wireless networks such as 802.11, since attackers on a wired network
will require physical access to the home network, while wireless
attackers may reside outside the home. Link-layer security can be of
assistance against these threats if it is available.
5.2. Usage Restriction
As noted in Sections 2 and 3, LLMNR is intended for usage in a While it is difficult for an off-link attacker to send an LLMNR query
limited set of scenarios. to a responder, it is possible for an off-link attacker to spoof a
response to a query (such as an A or AAAA query for a popular
Internet host), and by using a TTL or Hop Limit field larger than one
(1), for the forged response to reach the LLMNR sender. Since the
forged response will only be accepted if it contains a matching ID
field, choosing a pseudo-random ID field within queries provides some
protection against off-link responders.
Since an LLMNR query can be sent when DNS server(s) do not respond, Since LLMNR queries can be sent when DNS server(s) do not respond, an
an attacker can execute a denial of service attack on the DNS attacker can execute a denial of service attack on the DNS server(s)
server(s) and then poison the LLMNR cache by responding to an LLMNR and then poison the LLMNR cache by responding to an LLMNR query with
query with incorrect information. To some extent, these incorrect information. To some extent, these vulnerabilities exist
vulnerabilities exist today, since DNS response spoofing tools are today, since DNS response spoofing tools are available that can allow
available that can allow an attacker to respond to a query more an attacker to respond to a query more quickly than a distant DNS
quickly than a distant DNS server. server. However, switched networks or link layer security may make
it difficult for an on-link attacker to snoop unicast DNS queries,
whereas multicast LLMNR queries are propagated to all hosts on the
link, making it easier for an on-link attacker to spoof LLMNR
responses.
Since LLMNR queries are sent and responded to on the local-link, an Since LLMNR queries are sent and responded to on the local-link, an
attacker will need to respond more quickly to provide its own attacker will need to respond more quickly to provide its own
response prior to arrival of the response from a legitimate response prior to arrival of the response from a legitimate
responder. If an LLMNR query is sent for an off-link host, spoofing responder. If an LLMNR query is sent for an off-link host, spoofing
a response in a timely way is not difficult, since a legitimate a response in a timely way is not difficult, since a legitimate
response will never be received. response will never be received.
The vulnerability is more serious if LLMNR is given higher priority Limiting the situations in which LLMNR queries are sent, as described
than DNS among the enabled name resolution mechanisms. In such a in Section 2, is the best protection against these attacks. If LLMNR
configuration, a denial of service attack on the DNS server would not is given higher priority than DNS among the enabled name resolution
be necessary in order to poison the LLMNR cache, since LLMNR queries mechanisms, a denial of service attack on the DNS server would not be
necessary in order to poison the LLMNR cache, since LLMNR queries
would be sent even when the DNS server is available. In addition, would be sent even when the DNS server is available. In addition,
the LLMNR cache, once poisoned, would take precedence over the DNS the LLMNR cache, once poisoned, would take precedence over the DNS
cache, eliminating the benefits of cache separation. As a result, cache, eliminating the benefits of cache separation. As a result,
LLMNR is only used as a name resolution mechanism of last resort. LLMNR is only used as a name resolution mechanism of last resort.
5.3. Cache and Port Separation 5.3. Authentication
LLMNR is a peer-to-peer name resolution protocol, and as a result,
it is often deployed in situations where no trust model can be
assumed. This makes it difficult to apply existing DNS security
mechanisms to LLMNR.
LLMNR does not support "delegated trust" (CD or AD bits). As a
result, unless LLMNR senders are DNSSEC aware, it is not feasible to
use DNSSEC with LLMNR.
If authentication is desired, and a pre-arranged security
configuration is possible, then the following security mechanisms may
be used:
[a] LLMNR implementations MAY support TSIG and/or SIG(0) security
mechanisms. "DNS Name Service based on Secure Multicast DNS for
IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes the use of TSIG
to secure LLMNR responses, based on group keys.
[b] IPsec ESP with a null-transform MAY be used to authenticate unicast
LLMNR queries and responses or LLMNR responses to multicast
queries. In a small network without a certificate authority, this
can be most easily accomplished through configuration of a group
pre-shared key for trusted hosts.
Where these mechanisms cannot be supported, responses to LLMNR
queries may be unauthenticated.
5.4. Cache and Port Separation
In order to prevent responses to LLMNR queries from polluting the DNS In order to prevent responses to LLMNR queries from polluting the DNS
cache, LLMNR implementations MUST use a distinct, isolated cache for cache, LLMNR implementations MUST use a distinct, isolated cache for
LLMNR on each interface. The use of separate caches is most LLMNR on each interface. The use of separate caches is most
effective when LLMNR is used as a name resolution mechanism of last effective when LLMNR is used as a name resolution mechanism of last
resort, since this minimizes the opportunities for poisoning the resort, since this minimizes the opportunities for poisoning the
LLMNR cache, and decreases reliance on it. LLMNR cache, and decreases reliance on it.
LLMNR operates on a separate port from DNS, reducing the likelihood LLMNR operates on a separate port from DNS, reducing the likelihood
that a DNS server will unintentionally respond to an LLMNR query. that a DNS server will unintentionally respond to an LLMNR query.
5.4. Authentication
Since LLMNR does not support "delegated trust" (CD or AD bits), and
LLMNR senders are unlikely to be DNSSEC-aware, in practice LLMNR is
not compatible with DNSSEC.
LLMNR implementations MAY support TSIG and/or SIG(0) security
mechanisms; where this is not supported, responses to LLMNR queries
may be unauthenticated. If authentication is desired, and a pre-
arranged security configuration is possible, then IPsec ESP with a
null-transform MAY be used to authenticate unicast LLMNR queries and
responses or LLMNR responses to multicast queries. In a small
network without a certificate authority, this can be most easily
accomplished through configuration of a group pre-shared key for
trusted hosts.
6. IANA Considerations 6. IANA Considerations
This specification creates one new name space: the reserved bits in This specification creates one new name space: the reserved bits in
the LLMNR header. These are allocated by IETF Consensus, in the LLMNR header. These are allocated by IETF Consensus, in
accordance with BCP 26 [RFC2434]. accordance with BCP 26 [RFC2434].
LLMNR requires allocation of port 5355 for both TCP and UDP. LLMNR requires allocation of port 5355 for both TCP and UDP.
LLMNR requires allocation of link-scope multicast IPv4 address LLMNR requires allocation of link-scope multicast IPv4 address
224.0.0.252, as well as link-scope multicast IPv6 address 224.0.0.252, as well as link-scope multicast IPv6 address
skipping to change at page 25, line 47 skipping to change at page 26, line 7
2535, March 1999. 2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
8.2. Informative References 8.2. Informative References
[IEEE-802.11i]
Institute of Electrical and Electronics Engineers, "Supplement
to Standard for Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security",
IEEE 802.11i, July 2004.
[LLMNRSec]
Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
2004, Phoenix Park, Korea, February 9-11, 2004.
[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
Fixes", RFC 1536, October 1993. Fixes", RFC 1536, October 1993.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
skipping to change at page 26, line 28 skipping to change at page 26, line 49
[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
2937, September 2000. 2937, September 2000.
[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of Link-Local IPv4 Addresses", RFC 3927, October 2004. of Link-Local IPv4 Addresses", RFC 3927, October 2004.
[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft [Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
(work in progress), draft-cheshire-dnsext-multicastdns-04.txt, (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
February 2004. June 2005.
[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
Caching", IEEE/ACM Transactions on Networking, Volume 10, Caching", IEEE/ACM Transactions on Networking, Volume 10,
Number 5, pp. 589, October 2002. Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers", unicast addresses to communicate with recursive DNS servers",
Internet draft (work in progress), draft-ietf-ipv6-dns- Internet draft (work in progress), draft-ietf-ipv6-dns-
discovery-07.txt, October 2002. discovery-07.txt, October 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/