upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-06-11 08:20:01 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

new draft

Browse source
This commit is contained in:
Mark Andrews 2003-05-21 23:23:30 +00:00
parent 7767c2a7aa
commit a3c5866412
1 changed files with 246 additions and 246 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

492
doc/draft/draft-ietf-dnsext-mdns-19.txt → doc/draft/draft-ietf-dnsext-mdns-20.txt
View file

@ -7,8 +7,8 @@
DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-19.txt> Microsoft
12 May 2003
<draft-ietf-dnsext-mdns-20.txt> Microsoft
21 May 2003
Linklocal Multicast Name Resolution (LLMNR)
@ -61,20 +61,20 @@ Esibov, Aboba & Thaler Standards Track [Page 1]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
Table of Contents
1. Introduction .......................................... 3
1.1 Requirements .................................... 4
1.1 Requirements .................................... 3
1.2 Terminology ..................................... 4
2. Name resolution using LLMNR ........................... 4
2.1 Sender behavior ................................. 5
2.1 Sender behavior ................................. 4
2.2 Responder behavior .............................. 5
2.3 Unicast queries ................................. 6
2.4 Addressing ...................................... 7
2.5 Off-link detection .............................. 8
2.5 Off-link detection .............................. 7
2.6 Retransmissions ................................. 8
2.7 DNS TTL ......................................... 9
3. Usage model ........................................... 9
@ -86,7 +86,7 @@ Table of Contents
5. Security considerations ............................... 15
5.1 Scope restriction ............................... 15
5.2 Usage restriction ............................... 16
5.3 Cache and port separation ....................... 17
5.3 Cache and port separation ....................... 16
5.4 Authentication .................................. 17
6. IANA considerations ................................... 17
7. Normative References .................................. 17
@ -121,7 +121,7 @@ Esibov, Aboba & Thaler Standards Track [Page 2]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
1. Introduction
@ -147,19 +147,10 @@ described in Section 2.3.
Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks. The assumption is that if
a network has a home gateway, then the network either has DNS and DHCPv4
servers or the home gateway provides DHCPv4 and DNS server
functionality. By providing Dynamic Host Configuration Service for
IPv4 (DHCPv4), as well as a DNS server with support for dynamic DNS,
which is also authoritative for the A RRs of local hosts, it is possible
to support resolution of local host names over IPv4.
For small IPv6 networks, equivalent functionality can be provided by
implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for
DNS configuration [DHCPv6DNS], as well providing a DNS server with
support for dynamic DNS, which is also authoritative for the AAAA RRs of
local hosts, it is possible to support the resolution of local host
names over IPv6 as well as IPv4.
a network has a home gateway, then the network is able to provide DNS
server configuration and a DNS server is available that is authoritative
for the names of local hosts and can support dynamic DNS. Configuration
issues are discussed in Section 3.2.
In the future, LLMNR may be defined to support greater than link-scope
multicast. This would occur if LLMNR deployment is successful, the
@ -172,18 +163,6 @@ issues, usability and impact on the network it will be possible to
reevaluate which multicast scopes are appropriate for use with multicast
name resolution mechanisms.
Esibov, Aboba & Thaler Standards Track [Page 3]
INTERNET-DRAFT LLMNR 12 May 2003
Service discovery in general, as well as discovery of DNS servers using
LLMNR in particular, is outside of the scope of this document, as is
name resolution over non-multicast capable media.
@ -193,6 +172,18 @@ name resolution over non-multicast capable media.
In this document, several words are used to signify the requirements of
the specification. These words are often capitalized. The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
Esibov, Aboba & Thaler Standards Track [Page 3]
INTERNET-DRAFT LLMNR 21 May 2003
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].
@ -230,20 +221,6 @@ A typical sequence of events for LLMNR usage is as follows:
Further details of sender and responder behavior are provided in the
sections that follow.
Esibov, Aboba & Thaler Standards Track [Page 4]
INTERNET-DRAFT LLMNR 12 May 2003
2.1. Sender behavior
A sender sends an LLMNR query for any legal resource record type (e.g.
@ -255,6 +232,18 @@ The RD (Recursion Desired) bit MUST NOT be set in a query. If a
responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit.
Esibov, Aboba & Thaler Standards Track [Page 4]
INTERNET-DRAFT LLMNR 21 May 2003
The sender MUST anticipate receiving no replies to some LLMNR queries,
in the event that no responders are available within the link-scope or
in the event no positive non-null responses exist for the transmitted
@ -272,10 +261,9 @@ the LLMNR query. A host configured as a responder MUST act as a sender
to verify the uniqueness of names as described in Section 4.
Responders MUST NOT respond to LLMNR queries for names they are not
authoritative for, except in the event of a discovered conflict, as
described in Section 4. Responders SHOULD respond to LLMNR queries for
names and addresses they are authoritative for. This applies to both
forward and reverse lookups.
authoritative for. Responders SHOULD respond to LLMNR queries for names
and addresses they are authoritative for. This applies to both forward
and reverse lookups.
As an example, a computer "host.example.com." configured to respond to
LLMNR queries is authoritative for the name "host.example.com.". On
@ -292,18 +280,6 @@ and an empty answer section.
If a DNS server is running on a host that supports LLMNR, the DNS server
MUST respond to LLMNR queries only for the RRSets owned by the host on
Esibov, Aboba & Thaler Standards Track [Page 5]
INTERNET-DRAFT LLMNR 12 May 2003
which the server is running, but MUST NOT respond for other records for
which the server is authoritative.
@ -316,6 +292,18 @@ root.
For example the host "host.example.com." is not authoritative for the
name "child.host.example.com." unless the host is configured with
multiple names, including "host.example.com." and
Esibov, Aboba & Thaler Standards Track [Page 5]
INTERNET-DRAFT LLMNR 21 May 2003
"child.host.example.com.". As a result, "host" cannot reply to a query
for "child" with NXDOMAIN. The purpose of limiting the name authority
scope of a responder is to prevent complications that could be caused by
@ -352,18 +340,6 @@ Unicast queries SHOULD be sent when:
with the TC bit set to the previous LLMNR multicast query, or
b. The sender's LLMNR cache contains an NS resource record that
Esibov, Aboba & Thaler Standards Track [Page 6]
INTERNET-DRAFT LLMNR 12 May 2003
enables the sender to send a query directly to the hosts
authoritative for the name in the query, or
@ -376,6 +352,18 @@ address of the responder. The RA (Recursion Available) bit in the
header of the response MUST NOT be set. If the RA bit is set in the
response header, the sender MUST ignore the RA bit.
Esibov, Aboba & Thaler Standards Track [Page 6]
INTERNET-DRAFT LLMNR 21 May 2003
Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP
unicast LLMNR queries MUST be sent using TCP, using the same connection
as the query. If the sender of a TCP query receives a response not
@ -383,9 +371,9 @@ using TCP, the response MUST be silently discarded. Unicast UDP queries
MAY be responded to with an empty answer section and the TC bit set, so
as to require the sender to resend the query using TCP. Senders MUST
support sending TCP queries, and Responders MUST support listening for
TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on
TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on
the TCP listen socket to one (1) so that SYN-ACK packets will have TTL
(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming
(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming
connection from off-link since the Sender will not receive a SYN-ACK
from the Responder.
@ -394,10 +382,10 @@ UDP query, or if TCP connection setup cannot be completed in order to
send a unicast TCP query, this is treated as a response that no records
of the specified type and class exist for the specified name (it is
treated the same as a response with RCODE=0 and an empty answer
section). The UDP sender receiving an ICMP "Time Exceeded" message
section). The UDP sender receiving an ICMP "Time Exceeded" message
SHOULD verify that the ICMP error payload contains a valid LLMNR query
packet, which matches a query that is currently in progress, so as to
guard against a potential Denial of Service (DoS) attack. If a match
guard against a potential Denial of Service (DoS) attack. If a match
cannot be made, then the sender relies on the retransmission and timeout
behavior described in Section 2.6.
@ -410,20 +398,6 @@ sends queries, is 224.0.0.251. The IPv6 link-scope multicast address a
given responder listens to, and to which a sender sends all queries, is
TBD.
Esibov, Aboba & Thaler Standards Track [Page 7]
INTERNET-DRAFT LLMNR 12 May 2003
2.5. Off-link detection
The source address of LLMNR queries and responses MUST be "on link".
@ -438,6 +412,18 @@ For IPv4, an "on link" address is defined as a link-local address or an
address whose prefix belongs to a subnet on the local link; for IPv6
[RFC2460] an "on link" address is either a link-local address, defined
in [RFC2373], or an address whose prefix belongs to a subnet on the
Esibov, Aboba & Thaler Standards Track [Page 7]
INTERNET-DRAFT LLMNR 21 May 2003
local link. A sender SHOULD prefer RRs including reachable addresses
where RRs involving both reachable and unreachable addresses are
returned in response to a query.
@ -472,18 +458,6 @@ delayed by a time uniformly distributed between 0 and 200 ms.
If an LLMNR query sent over UDP is not resolved within the timeout
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
Esibov, Aboba & Thaler Standards Track [Page 8]
INTERNET-DRAFT LLMNR 12 May 2003
the query in order to assure that it was received by a host capable of
responding to it. Since a multicast query sender cannot know beforehand
whether it will receive no response, one response, or more than one
@ -495,10 +469,22 @@ waits for LLMNR_TIMEOUT if no response has been received.
LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received, on a per-interface
basis, using the algorithms described in [RFC2988], with a minimum
timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be
attempted more than 3 times. Where LLMNR queries are sent using TCP,
retransmission is handled by the transport layer.
basis. The algorithms described in [RFC2988] are suggested, with a
minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD
NOT be attempted more than 3 times. Where LLMNR queries are sent using
Esibov, Aboba & Thaler Standards Track [Page 8]
INTERNET-DRAFT LLMNR 21 May 2003
TCP, retransmission is handled by the transport layer.
2.7. DNS TTL
@ -532,18 +518,6 @@ additional restrictions:
[2] Where a DNS server is configured, by default a sender
SHOULD send LLMNR queries only for names that are either
unqualified or exist within the default domain. Where no
Esibov, Aboba & Thaler Standards Track [Page 9]
INTERNET-DRAFT LLMNR 12 May 2003
DNS server is configured, an LLMNR query MAY be sent for
any name.
@ -558,6 +532,18 @@ INTERNET-DRAFT LLMNR 12 May 2003
RRs returned in LLMNR responses MUST only include values that are valid
on the local interface, such as IPv4 or IPv6 addresses valid on the
local link or names defended using the mechanism described in Section 4.
Esibov, Aboba & Thaler Standards Track [Page 9]
INTERNET-DRAFT LLMNR 21 May 2003
In particular:
[1] If a link-scope IPv6 address is returned in a AAAA RR, that
@ -588,9 +574,23 @@ to resolve unqualified host names.
3.2. LLMNR configuration
LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on all
interface basis. By default, LLMNR Responders SHOULD be enabled on all
interfaces, at all times.
Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
possible for a dual stack host to be configured with the address of a
DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use over IPv6.
In these situations, a dual stack host will send AAAA queries to the
configured DNS server over IPv4. However, an IPv6-only host
unconfigured with a DNS server suitable for use over IPv6 will be unable
to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms
(such as [DHCPv6DNS] and [DNSDisc]) are not yet widely deployed, and not
all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration
may be a common problem in the short term, and LLMNR may prove useful in
enabling linklocal name resolution over IPv6.
@ -601,35 +601,30 @@ Esibov, Aboba & Thaler Standards Track [Page 10]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
possible for a dual stack host to be configured with the address of a
DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use over IPv6. In these situations, a dual stack host will
send AAAA queries to the configured DNS server over IPv4.
However, an IPv6-only host unconfigured with a DNS server suitable for
use over IPv6 will be unable to resolve names using DNS. Since
automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and
[DNSDisc]) are not yet widely deployed, and not all DNS servers support
IPv6, lack of IPv6 DNS configuration may be a common problem in the
short term, and LLMNR may prove useful in enabling linklocal name
resolution over IPv6.
For example, a home network may provide a DHCPv4 server but may not
support DHCPv6 for DNS configuration [DHCPv6DNS]. In such a
circumstance, IPv6-only hosts will not be configured with a DNS server.
Where a DNS server is configured but does not support dynamic client
update over IPv6 or DHCPv6-based dynamic update, hosts on the home
network will not be able to dynamically register or resolve the names of
local IPv6 hosts. If the configured DNS server responds to AAAA RR
Where a DHCPv4 server is available but not a DHCPv6 server [DHCPv6DNS],
IPv6-only hosts may not be configured with a DNS server. Where there is
no DNS server authoritative for the names of hosts on the local network
or the authoritative DNS server does not support dynamic client update
over IPv6 or DHCPv6-based dynamic update, hosts on the home network will
not be able to dynamically register or resolve the names of local IPv6
hosts. For example, if the configured DNS server responds to AAAA RR
queries sent over IPv4 or IPv6 with an authoritative name error
(RCODE=3), then it will not be possible to resolve the names of
IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for
local name resolution.
Similarly, if a DHCPv4 server is available providing DNS server
configuration, and the DNS server authoritative for the A RRs of local
hosts also supports either dynamic client update over IPv4 or
DHCPv4-based dynamic update, then resolution of the names of local IPv4
hosts can be provided over IPv4 without LLMNR. However, if there is no
DNS server authoritative for the names of local hosts, or the
authoritative DNS server does not support dynamic update, then LLMNR may
prove useful in enabling linklocal name resoltion over IPv4.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure LLMNR on an interface. The LLMNR Enable Option, described in
[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
@ -638,19 +633,24 @@ in which order DNS itself is used for name resolution. The order in
which various name resolution mechanisms should be used can be specified
using the Name Service Search Option for DHCP [RFC2937].
3.2.1. Configuration consistency
It is possible that DNS configuration mechanisms will go in and out of
service. In these circumstances, it is possible for hosts within an
administrative domain to be inconsistent in their DNS configuration.
For example, where DHCP is used for configuring DNS servers, one or more
DHCP servers can go down. As a result, hosts configured prior to the
DHCP servers can fail. As a result, hosts configured prior to the
outage will be configured with a DNS server, while hosts configured
after the outage will not. Alternatively, it is possible for the DNS
configuration mechanism to continue functioning while configured DNS
servers fail.
Unless unconfigured hosts periodically retry configuration, an outage in
the DNS configuration mechanism will result in hosts continuing to use
LLMNR even once the outage is repaired. Since LLMNR only enables
linklocal name resolution, this represents an unnecessary degradation in
capabilities. As a result, it is recommended that hosts without a
configured DNS server periodically attempt to obtain DNS configuration.
A default retry interval of two (2) minutes is RECOMMENDED.
@ -661,17 +661,9 @@ Esibov, Aboba & Thaler Standards Track [Page 11]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
Unless unconfigured hosts periodically retry configuration, an outage in
the DNS configuration mechanism will result in hosts continuing to
prefer LLMNR even once the outage is repaired. Since LLMNR only enables
linklocal name resolution, this represents an unnecessary degradation in
capabilities. As a result, it is recommended that hosts without a
configured DNS server periodically attempt to obtain DNS configuration.
A default retry interval of two (2) minutes is RECOMMENDED.
4. Conflict resolution
The sender MUST anticipate receiving multiple replies to the same LLMNR
@ -713,6 +705,14 @@ resource record.
By default, a host SHOULD be configured to behave as though all RRs are
UNIQUE. Uniqueness verification is carried out when the host:
- starts up or
- is configured to respond to the LLMNR queries on an interface or
- is configured to respond to the LLMNR queries using additional
UNIQUE resource records.
When a host that owns a UNIQUE record receives an LLMNR query for that
record, the host MUST respond. After the client receives a response, it
Esibov, Aboba & Thaler Standards Track [Page 12]
@ -721,32 +721,21 @@ Esibov, Aboba & Thaler Standards Track [Page 12]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
- starts up or
- is configured to respond to the LLMNR queries on an interface or
- is configured to respond to the LLMNR queries using additional
UNIQUE resource records.
When a host that owns a UNIQUE record receives an LLMNR query for that
record, the host MUST respond. After the client receives a response, it
MUST check whether the response arrived on another interface. If this
is the case, then the client can use the UNIQUE resource record in
response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
resource record in response to LLMNR queries.
The name conflict detection mechanism doesn't prevent name conflicts
when previously partitioned segments are connected by a bridge. In such
a situation, name conflicts are detected when a sender receives more
than one response to its LLMNR multicast query. In this case, the
sender sends the first response that it received to all responders that
responded to this query except the first one, using UDP unicast. A host
that receives a query response containing a UNIQUE resource record that
it owns, even if it didn't send such a query, MUST verify that no other
host within the LLMNR scope is authoritative for the same name, using
the mechanism described above. Based on the result, the host detects
whether there is a name conflict and acts accordingly.
when previously partitioned segments are connected by a bridge. In order
to minimize the chance of conflicts in such a situation, it is
recommended that steps be taken to ensure hostname uniqueness. For
example, the hostname could be chosen randomly from a large pool of
potential names, or the hostname could be assigned via a process
designed to guarantee uniqueness.
4.1. Considerations for Multiple Interfaces
@ -773,6 +762,17 @@ to respond with a host RR for "myhost" on the interface on the right
(see Figure 1). The multi-homed host may, however, be configured to use
the "myhost" name on the interface on the left.
Since names are only unique per-link, hosts on different links could be
using the same name. If an LLMNR client sends requests over multiple
interfaces, and receives replies from more than one, the result returned
to the client is defined by the implementation. The situation is
illustrated in figure 2.
Esibov, Aboba & Thaler Standards Track [Page 13]
@ -781,15 +781,9 @@ Esibov, Aboba & Thaler Standards Track [Page 13]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
Since names are only unique per-link, hosts on different links could be
using the same name. If an LLMNR client sends requests over multiple
interfaces, and receives replies from more than one, the result returned
to the client is defined by the implementation. The situation is
illustrated in figure 2.
---------- ----------
| | | |
[A] [myhost] [A]
@ -802,11 +796,6 @@ send LLMNR queries on both interfaces. When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on
both interfaces.
Host myhost will then send the first responder's response to the second
responder, who will attempt to verify the uniqueness of host RR for its
name, but will not discover a conflict, since the conflicting host
resides on a different link. Therefore it will continue using its name.
Host myhost cannot distinguish between the situation shown in Figure 2,
and that shown in Figure 3 where no conflict exists.
@ -833,17 +822,6 @@ structure exposes the scope within which each scoped address exists, and
this structure can be used for both IPv4 (using v4-mapped IPv6
addresses) and IPv6 addresses.
Esibov, Aboba & Thaler Standards Track [Page 14]
INTERNET-DRAFT LLMNR 12 May 2003
Following the example in Figure 2, an application on 'myhost' issues the
request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
@ -854,6 +832,18 @@ both hosts responding to the name 'A'. Link-local addresses will 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 are still
indistinguishable, but this API allows the application to communicate
Esibov, Aboba & Thaler Standards Track [Page 14]
INTERNET-DRAFT LLMNR 21 May 2003
successfully with any address in the list.
5. Security Considerations
@ -891,19 +881,6 @@ exposure to such threats by utilizing queries sent to a link-scope
multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
fields to one (1) on both queries and responses.
Esibov, Aboba & Thaler Standards Track [Page 15]
INTERNET-DRAFT LLMNR 12 May 2003
While this limits the ability of off-link attackers to spoof LLMNR
queries and responses, it does not eliminate it. For example, it is
possible for an attacker to spoof a response to a frequent query (such
@ -915,6 +892,18 @@ 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.
Esibov, Aboba & Thaler Standards Track [Page 15]
INTERNET-DRAFT LLMNR 21 May 2003
Link-layer security can be of assistance against these threats if it is
available.
@ -952,18 +941,6 @@ cache, once poisoned, would take precedence over the DNS cache,
eliminating the benefits of cache separation. As a result, LLMNR is
best thought of as a name resolution mechanism of last resort.
Esibov, Aboba & Thaler Standards Track [Page 16]
INTERNET-DRAFT LLMNR 12 May 2003
5.3. Cache and port separation
In order to prevent responses to LLMNR queries from polluting the DNS
@ -976,6 +953,17 @@ decreases reliance on it.
LLMNR operates on a separate port from DNS, reducing the likelihood that
a DNS server will unintentionally respond to an LLMNR query.
Esibov, Aboba & Thaler Standards Track [Page 16]
INTERNET-DRAFT LLMNR 21 May 2003
5.4. Authentication
LLMNR does not require use of DNSSEC, and as a result, responses to
@ -1012,18 +1000,6 @@ allocation of a link-scope multicast IPv6 address.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
Esibov, Aboba & Thaler Standards Track [Page 17]
INTERNET-DRAFT LLMNR 12 May 2003
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
@ -1036,6 +1012,18 @@ INTERNET-DRAFT LLMNR 12 May 2003
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
Esibov, Aboba & Thaler Standards Track [Page 17]
INTERNET-DRAFT LLMNR 21 May 2003
8. Informative References
[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and
@ -1073,6 +1061,18 @@ INTERNET-DRAFT LLMNR 12 May 2003
draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-07.txt, August 2002.
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
(work in progress), draft-guttman-mdns-enable-02.txt,
April 2002.
[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-09.txt, May 2002.
Esibov, Aboba & Thaler Standards Track [Page 18]
@ -1081,17 +1081,9 @@ Esibov, Aboba & Thaler Standards Track [Page 18]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
(work in progress), draft-guttman-mdns-enable-02.txt,
April 2002.
[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-09.txt, May 2002.
Acknowledgments
This work builds upon original work done on multicast DNS by Bill
@ -1135,13 +1127,21 @@ EMail: dthaler@microsoft.com
Esibov, Aboba & Thaler Standards Track [Page 19]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
Intellectual Property Statement
@ -1201,7 +1201,7 @@ Esibov, Aboba & Thaler Standards Track [Page 20]
INTERNET-DRAFT LLMNR 12 May 2003
INTERNET-DRAFT LLMNR 21 May 2003
Open Issues
@ -1213,7 +1213,7 @@ http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-19.txt>, and expires
This memo is filed as <draft-ietf-dnsext-mdns-20.txt>, and expires
November 22, 2003.