draft-ietf-dnsext-mdns-16.txt   draft-ietf-dnsext-mdns-17.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-16.txt> Microsoft <draft-ietf-dnsext-mdns-17.txt> Microsoft
10 April 2003 16 April 2003
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Name resolution using LLMNR ........................... 4 2. Name resolution using LLMNR ........................... 4
2.1 Sender behavior ................................. 5 2.1 Sender behavior ................................. 5
2.2 Responder behavior .............................. 5 2.2 Responder behavior .............................. 5
2.3 Unicast queries ................................. 6 2.3 Unicast queries ................................. 6
2.4 Addressing ...................................... 7 2.4 Addressing ...................................... 7
2.5 Off-link detection .............................. 7 2.5 Off-link detection .............................. 7
2.6 Retransmissions ................................. 8 2.6 Retransmissions ................................. 8
2.7 DNS TTL ......................................... 8 2.7 DNS TTL ......................................... 8
3. Usage model ........................................... 8 3. Usage model ........................................... 8
3.1 Unqualified names ............................... 10 3.1 Unqualified names ............................... 9
3.2 LLMNR configuration ............................. 10 3.2 LLMNR configuration ............................. 10
4. Conflict resolution ................................... 11 4. Conflict resolution ................................... 11
4.1 Considerations for multiple interfaces .......... 13 4.1 Considerations for multiple interfaces .......... 12
4.2 API issues ...................................... 15 4.2 API issues ...................................... 14
5. Security considerations ............................... 15 5. Security considerations ............................... 14
5.1 Scope restriction ............................... 15 5.1 Scope restriction ............................... 14
5.2 Usage restriction ............................... 16 5.2 Usage restriction ............................... 15
5.3 Cache and port separation ....................... 16 5.3 Cache and port separation ....................... 16
5.4 Authentication .................................. 17 5.4 Authentication .................................. 16
6. IANA considerations ................................... 17 6. IANA considerations ................................... 16
7. Normative References .................................. 17 7. Normative References .................................. 16
8. Informative References ................................ 18 8. Informative References ................................ 17
Acknowledgments .............................................. 19 Acknowledgments .............................................. 18
Authors' Addresses ........................................... 19 Authors' Addresses ........................................... 18
Intellectual Property Statement .............................. 19 Intellectual Property Statement .............................. 19
Full Copyright Statement ..................................... 20 Full Copyright Statement ..................................... 19
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which operates on a separate port from DNS, with a distinct resolver which operates on a separate port from DNS, with a distinct resolver
cache, but does not change the format of DNS packets. LLMNR supports cache, but does not change the format of DNS packets. LLMNR supports
all current and future DNS formats, types and classes. However, since all current and future DNS formats, types and classes. However, since
LLMNR only operates on the local link, it cannot be considered a LLMNR only operates on the local link, it cannot be considered a
substitute for DNS. substitute for DNS.
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
conventional DNS name resolution is not possible. These include conventional DNS name resolution is not possible. These include
scenarios in which hosts are not configured with the address of a DNS scenarios in which hosts are not configured with the address of a DNS
server, where configured DNS servers do not reply to a query, or where server, where configured DNS servers do not reply to a query, or where
they respond with errors, as described in Section 3. they respond with errors, as described in Section 3.
LLMNR queries are sent to and received on port TBD using a link-scope LLMNR queries are sent to and received on port TBD using a link-scope
multicast address as specified in "Administratively Scoped IP Multicast" multicast address as specified in "Administratively Scoped IP Multicast"
[RFC2365] for IPv4. The LLMNR link-scope multicast address to be used [RFC2365] for IPv4. The LLMNR link-scope multicast address to be used
for IPv4 is 224.0.0.251. For IPv6, the "solicited name" link-scope for IPv4 is 224.0.0.251. For IPv6, the LLMNR link-scope multicast
multicast addresses are used for A/AAAA queries, and a separate link- address is TBD. Link-scope multicast addresses are used to prevent
scope multicast address TBD for all other queries. Link-scope multicast propagation of LLMNR traffic across routers, potentially flooding the
addresses are used to prevent propagation of LLMNR traffic across network; for details, see Section 2.4. In circumstances described in
routers, potentially flooding the network; for details, see Section 2.4. Section 2.3, LLMNR queries can also be sent to a unicast address.
In circumstances described in Section 2.3, LLMNR queries can also be
sent to a unicast address.
Propagation of LLMNR packets on the local link is considered sufficient Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks. The assumption is that if to enable name resolution in small networks. The assumption is that if
a network has a home gateway, then the network either has a DNS server a network has a home gateway, then the network either has a DNS server
or the home gateway can function as a DNS proxy. By implementing or the home gateway can function as a DNS proxy. By implementing
Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as a DNS Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as a DNS
proxy and dynamic DNS, home gateways can provide name resolution for the proxy and dynamic DNS, home gateways can provide name resolution for the
names of hosts over IPv4 on the local network. names of hosts over IPv4 on the local network.
For small IPv6 networks, equivalent functionality can be provided by a For small IPv6 networks, equivalent functionality can be provided by a
skipping to change at page 7, line 20 skipping to change at page 7, line 20
discard the response and resend the query over TCP or using EDNS0 with discard the response and resend the query over TCP or using EDNS0 with
larger window using the unicast address of the responder. The RA larger window using the unicast address of the responder. The RA
(Recursion Available) bit in the header of the response MUST NOT be set. (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 it. If the RA bit is set in the response header, the sender MUST ignore it.
2.4. Addressing 2.4. Addressing
The IPv4 link-scope multicast address a given responder listens to, and The IPv4 link-scope multicast address a given responder listens to, and
to which a sender sends all queries, is 224.0.0.251. The IPv6 link- to which a sender sends all queries, is 224.0.0.251. The IPv6 link-
scope multicast address a given responder listens to, and to which a scope multicast address a given responder listens to, and to which a
sender sends A/AAAA queries, is formed as follows: The name of the sender sends all queries, is TBD.
resource record in question is expressed in its canonical form (see
[RFC2535], section 8.1), which is uncompressed with all alphabetic
characters in lower case.
The first label of the FQDN in the query is then hashed using the MD5
algorithm, described in [RFC1321]. The first 32 bits of the resultant
128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield
the 128-bit "solicited name multicast address". (Note: this procedure
is intended to be the same as that specified in section 3 of "IPv6 Node
Information Queries" [NodeInfo]). A responder that listens for queries
for multiple names with different first labels will necessarily listen
to multiple of these solicited name multicast addresses.
2.5. Off-link detection 2.5. Off-link detection
The source address of LLMNR queries and responses MUST be "on link". The source address of LLMNR queries and responses MUST be "on link".
The destination address of an LLMNR query MUST be a link-scope multicast The destination address of an LLMNR query MUST be a link-scope multicast
address or an "on link" unicast address; the destination address of an address or an "on link" unicast address; the destination address of an
LLMNR response MUST be an "on link" unicast address. For IPv4, an "on LLMNR response MUST be an "on link" unicast address. For IPv4, an "on
link" address is defined as a link-local address or an address whose 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 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 link" address is either a link-local address, defined in [RFC2373], or
skipping to change at page 8, line 36 skipping to change at page 8, line 24
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in
order to assure themselves that the query has been received by a host order to assure themselves that the query has been received by a host
capable of responding to the query. Since a sender cannot know capable of responding to the query. Since a sender cannot know
beforehand whether it will receive no response, one response, or more beforehand whether it will receive no response, one response, or more
than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order
to collect all possible responses, rather than considering the query to collect all possible responses, rather than considering the query
answered after the first response is received. answered after the first response is received.
LLMNR implementations SHOULD dynamically estimate the timeout value LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described (LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described
in [RFC2988], with a minimum timeout value of 300 ms. Repetition SHOULD in [RFC2988], with a minimum timeout value of 300 ms. Retransmission
NOT be attempted more than 3 times. SHOULD NOT be attempted more than 3 times.
2.7. DNS TTL 2.7. DNS TTL
The responder should use a pre-configured TTL value in the records The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. Due to the TTL minimalization returned in the LLMNR query response. Due to the TTL minimalization
necessary when caching an RRset, all TTLs in an RRset MUST be set to the necessary when caching an RRset, all TTLs in an RRset MUST be set to the
same value. In the additional and authority section of the response the same value. In the additional and authority section of the response the
responder includes the same records as a DNS server would insert in the responder includes the same records as a DNS server would insert in the
response to the unicast DNS query. response to the unicast DNS query.
skipping to change at page 9, line 32 skipping to change at page 9, line 19
unqualified or exist within the default domain. Where no unqualified or exist within the default domain. Where no
DNS server is configured, an LLMNR query MAY be sent for DNS server is configured, an LLMNR query MAY be sent for
any name. any name.
[3] A responder with both link-local and routable addresses [3] A responder with both link-local and routable addresses
MUST respond to LLMNR queries for A/AAAA RRs only with MUST respond to LLMNR queries for A/AAAA RRs only with
routable address(es). This encourages use of routable routable address(es). This encourages use of routable
address(es) for establishment of new connections. address(es) for establishment of new connections.
[4] A sender SHOULD only send LLMNR queries for PTR RRs [4] A sender SHOULD only send LLMNR queries for PTR RRs
that represent addresses reachable through the link that represent addresses reachable on the link
over which LLMNR is used. over which LLMNR is used.
RRs returned in LLMNR responses MUST only include values that are valid 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 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. local link or names defended using the mechanism described in Section 4.
In particular: In particular:
[1] If a link-scope IPv6 address is returned in a AAAA RR, that [1] If a link-scope IPv6 address is returned in a AAAA RR, that
address MUST be valid on the local link over which LLMNR is address MUST be valid on the local link over which LLMNR is
used. used.
skipping to change at page 12, line 18 skipping to change at page 11, line 52
1. MUST verify that there is no other host within the scope of the 1. MUST verify that there is no other host within the scope of the
LLMNR query propagation that can return a resource record LLMNR query propagation that can return a resource record
for the same name, type and class. for the same name, type and class.
2. MUST NOT include a UNIQUE resource record in the 2. MUST NOT include a UNIQUE resource record in the
response without having verified its uniqueness. response without having verified its uniqueness.
Where a host is configured to respond to LLMNR queries on more than one Where a host is configured to respond to LLMNR queries on more than one
interface, each interface should have its own independent LLMNR cache. interface, each interface should have its own independent LLMNR cache.
For each UNIQUE resource record in a given interface's cache, the host For each UNIQUE resource record in a given interface's cache, the host
MUST verify resource record uniqueness on that interface. To accomplish MUST verify resource record uniqueness on that interface. To accomplish
this, the host MUST send a dynamic LLMNR update request for each new this, the host MUST send an LLMNR query for each UNIQUE resource record.
UNIQUE resource record. The format of the dynamic LLMNR update request
is identical that specified in [RFC2136]. By default, a host SHOULD be By default, a host SHOULD be configured to behave as though all RRs are
configured to behave as though all RRs are UNIQUE. Uniqueness UNIQUE. Uniqueness verification is carried out when the host:
verification is carried out when the host:
- starts up or - starts up or
- is configured to respond to the LLMNR queries on an interface or - is configured to respond to the LLMNR queries on an interface or
- is configured to respond to the LLMNR queries using additional - is configured to respond to the LLMNR queries using additional
UNIQUE resource records. UNIQUE resource records.
The data to be specified in the dynamic update request is as follows: 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
Header section
contains values according to [RFC2136].
Zone section
The zone name in the zone section MUST be set to the name of the
UNIQUE record. The zone type in the zone section MUST be set to
SOA. The zone class in the zone section MUST be set to the class
of the UNIQUE record.
Prerequisite section
This section MUST contain a record set whose semantics are
described in [RFC2136], Section 2.4.3 "RRset Does Not Exist"
(NXRRSET), requesting that RRs with the NAME and TYPE of the UNIQUE
record do not exist.
Update section
This section MUST be left empty.
Additional section
This section is set according to [RFC2136].
When a host that owns a UNIQUE record receives a dynamic update request
that requests that the UNIQUE resource record set does not exist, the
host MUST respond via unicast with the YXRRSET error, according to the
rules described in Section 3 of [RFC2136].
After the client receives an YXRRSET response to its dynamic update
request stating that a UNIQUE resource record does not exist, the host
MUST check whether the response arrived on another interface. If this MUST check whether the response arrived on another interface. If this
is the case, then the client can use the UNIQUE resource record in is the case, then the client can use the UNIQUE resource record in
response to LLMNR queries and dynamic update requests. If not, then it response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
MUST NOT use the UNIQUE resource record in response to LLMNR queries and resource record in response to LLMNR queries.
dynamic update requests.
Note that this name conflict detection mechanism doesn't prevent name Note that this name conflict detection mechanism doesn't prevent name
conflicts when previously partitioned segments are connected by a conflicts when previously partitioned segments are connected by a
bridge. In such a situation, name conflicts are detected when a sender bridge. In such a situation, name conflicts are detected when a sender
receives more than one response to its LLMNR query. receives more than one response to its LLMNR query.
In this case, the sender sends the first response that it received to 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 all responders that responded to this query except the first one, using
unicast. A host that receives a query response containing a UNIQUE 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 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 verify that no other host within the LLMNR scope is authoritative for
the same name, using the dynamic LLMNR update request mechanism the same name, using the mechanism described above. Based on the
described above. Based on the result, the host detects whether there is result, the host detects whether there is a name conflict and acts
a name conflict and acts as described above. accordingly.
4.1. Considerations for Multiple Interfaces 4.1. Considerations for Multiple Interfaces
A multi-homed host may elect to configure LLMNR on only one of its A multi-homed host may elect to configure LLMNR on only one of its
active interfaces. In many situations this will be adequate. However, active interfaces. In many situations this will be adequate. However,
should a host need to configure LLMNR on more than one of its active should a host need to configure LLMNR on more than one of its active
interfaces, there are some additional precautions it MUST take. interfaces, there are some additional precautions it MUST take.
Implementers who are not planning to support LLMNR on multiple Implementers who are not planning to support LLMNR on multiple
interfaces simultaneously may skip this section. interfaces simultaneously may skip this section.
skipping to change at page 16, line 31 skipping to change at page 15, line 31
If an interface has been configured via any automatic configuration If an interface has been configured via any automatic configuration
mechanism which is able to supply DNS configuration information, then mechanism which is able to supply DNS configuration information, then
LLMNR SHOULD NOT be used as the primary name resolution mechanism on LLMNR SHOULD NOT be used as the primary name resolution mechanism on
that interface, although it MAY be used as a name resolution mechanism that interface, although it MAY be used as a name resolution mechanism
of last resort. of last resort.
Note: enabling LLMNR for use in situations where a DNS server has been Note: enabling LLMNR for use in situations where a DNS server has been
configured will result in upgraded hosts changing their default behavior configured will result in upgraded hosts changing their default behavior
without a simultaneous update to configuration information. Where this without a simultaneous update to configuration information. Where this
is considered undesirable, LLMNR SHOULD NOT be enabled by default, so is considered undesirable, LLMNR SHOULD NOT be enabled by default, so
that hosts will neither listen on the LINKLOCAL multicast address, nor that hosts will neither listen on the link-scope multicast address, nor
will it send queries to that address. will it send queries to that address.
Use of LLMNR as a name resolution mechanism increases security Use of LLMNR as a name resolution mechanism increases security
vulnerabilities. For example, if an LLMNR query is sent whenever a DNS vulnerabilities. For example, if an LLMNR query is sent whenever a DNS
server does not respond in a timely way, then an attacker can execute a server does not respond in a timely way, then an attacker can execute a
denial of service attack on the DNS server(s) and then poison the LLMNR denial of service attack on the DNS server(s) and then poison the LLMNR
cache by responding to the resulting LLMNR queries with incorrect cache by responding to the resulting LLMNR queries with incorrect
information. information.
The vulnerability is more serious if LLMNR is given higher priority than The vulnerability is more serious if LLMNR is given higher priority than
skipping to change at page 17, line 34 skipping to change at page 16, line 34
accomplished through configuration of a group pre-shared key for trusted accomplished through configuration of a group pre-shared key for trusted
hosts. hosts.
6. IANA Considerations 6. IANA Considerations
This specification does not create any new name spaces for IANA This specification does not create any new name spaces for IANA
administration. LLMNR requires allocation of a port TBD for both TCP administration. LLMNR requires allocation of a port TBD for both TCP
and UDP. Assignment of the same port for both transports is requested. and UDP. Assignment of the same port for both transports is requested.
LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251) that LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251) that
has been previously allocated to LLMNR by IANA. It also requires has been previously allocated to LLMNR by IANA. It also requires
allocation of a link scope multicast IPv6 address, for use with queries allocation of a link-scope multicast IPv6 address.
of types other than A/AAAA.
7. Normative References 7. Normative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., et al., "Dynamic Updates in the Domain Name [RFC2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
System (DNS UPDATE)", RFC 2136, April 1997. System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998. 23, RFC 2365, July 1998.
[RFC2373] Hinden, R., and S. Deering, "IP Version 6 Addressing [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2988] Paxson, V., and M. Allman, "Computing TCP's [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Retransmission Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
8. Informative References 8. Informative References
[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and
Suggested Fixes", RFC 1536, October 1993. Suggested Fixes", RFC 1536, October 1993.
[RFC2292] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for
RFC 2292, February 1998. IPv6", RFC 2292, February 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2553, "Basic Socket Interface Extensions for IPv6", RFC 2553,
March 1999. March 1999.
[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.
[DHCPv6DNS] Droms, R., "A Guide to Implementing Stateless DHCPv6 [DHCPv6DNS] Droms, R., "A Guide to Implementing Stateless DHCPv6
Service", Internet draft (work in progress), draft-droms- Service", Internet draft (work in progress), draft-droms-
dhcpv6-stateless-guide-01.txt, October 2002. dhcpv6-stateless-guide-01.txt, October 2002.
[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness
of Caching", IEEE/ACM Transactions on Networking, Volume of Caching", IEEE/ACM Transactions on Networking, Volume
10, Number 5, pp. 589, October 2002. 10, Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I., and D. Thaler, "Well known site [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site
local unicast addresses to communicate with recursive DNS local unicast addresses to communicate with recursive DNS
servers", Internet draft (work in progress), draft-ietf- servers", Internet draft (work in progress), draft-ietf-
ipv6-dns-discovery-07.txt, October 2002. ipv6-dns-discovery-07.txt, October 2002.
[IPV4Link] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", Internet Configuration of IPv4 Link-Local Addresses", Internet
draft (work in progress), draft-ietf-zeroconf- draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-07.txt, August 2002. ipv4-linklocal-07.txt, August 2002.
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft [LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
(work in progress), draft-guttman-mdns-enable-02.txt, (work in progress), draft-guttman-mdns-enable-02.txt,
April 2002. April 2002.
[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet [NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
draft (work in progress), draft-ietf-ipn-gwg-icmp-name- draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-09.txt, May 2002. lookups-09.txt, May 2002.
Acknowledgments Acknowledgments
This work builds upon original work done on multicast DNS by Bill This work builds upon original work done on multicast DNS by Bill
Manning and Bill Woodcock. Bill Manning's work was funded under DARPA Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
grant #F30602-99-1-0523. The authors gratefully acknowledge their grant #F30602-99-1-0523. The authors gratefully acknowledge their
contribution to the current specification. Constructive input has also contribution to the current specification. Constructive input has also
been received from Mark Andrews, Stuart Cheshire, Robert Elz, Rob been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert
Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron
Thomas Narten, Erik Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-
Brian Zill, Keith Moore and Markku Savela. Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku
Savela.
Authors' Addresses Authors' Addresses
Levon Esibov Levon Esibov
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: levone@microsoft.com EMail: levone@microsoft.com
skipping to change at page 20, line 46 skipping to change at page 20, line 5
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Open Issues
Open issues with this specification are tracked on the following web
site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-16.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-17.txt>, and expires
November 22, 2003. November 22, 2003.
 End of changes. 

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