draft-ietf-dnsext-mdns-27.txt   draft-ietf-dnsext-mdns-28.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-27.txt> Microsoft <draft-ietf-dnsext-mdns-28.txt> Microsoft
17 December 2003 1 January 2004
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 1, line 31 skipping to change at page 1, line 31
or to cite them other than as "work in progress." 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Today, with the rise of home networking, there are an increasing number Today, with the rise of home networking, there are an increasing number
of ad-hoc networks operating without a Domain Name System (DNS) server. of ad-hoc networks operating without a Domain Name System (DNS) server.
In order to allow name resolution in such environments, Link-Local In order to allow name resolution in such environments, Link-Local
Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all
current and future DNS formats, types and classes, while operating on a current and future DNS formats, types and classes, while operating on a
separate port from DNS, and with a distinct resolver cache. separate port from DNS, and with a distinct resolver cache.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
conventional DNS name resolution is not possible. Since LLMNR only conventional DNS name resolution is not possible. Since LLMNR only
operates on the local link, it cannot be considered a substitute for operates on the local link, it cannot be considered a substitute for
DNS. DNS.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
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 LLMNR packet format ............................. 5
2.2 Responder behavior .............................. 6 2.2 Sender behavior ................................. 8
2.3 Unicast queries ................................. 7 2.3 Responder behavior .............................. 9
2.4 Off-link detection .............................. 8 2.4 Unicast queries ................................. 10
2.5 Responder responsibility ........................ 9 2.5 Off-link detection .............................. 11
2.6 Retransmissions ................................. 10 2.6 Responder responsibilities ...................... 12
2.7 DNS TTL ......................................... 10 2.7 Retransmission and jitter ....................... 13
2.8 Use of the authority and additional sections .... 11 2.8 DNS TTL ......................................... 14
3. Usage model ........................................... 11 2.9 Use of the authority and additional sections .... 14
3.1 LLMNR configuration ............................. 12 3. Usage model ........................................... 14
4. Conflict resolution ................................... 13 3.1 LLMNR configuration ............................. 15
4.1 Considerations for multiple interfaces .......... 15 4. Conflict resolution ................................... 16
4.2 API issues ...................................... 16 4.1 Considerations for multiple interfaces .......... 18
5. Security considerations ............................... 16 4.2 API issues ...................................... 19
5.1 Scope restriction ............................... 17 5. Security considerations ............................... 20
5.2 Usage restriction ............................... 18 5.1 Scope restriction ............................... 20
5.3 Cache and port separation ....................... 18 5.2 Usage restriction ............................... 21
5.4 Authentication .................................. 19 5.3 Cache and port separation ....................... 22
6. IANA considerations ................................... 19 5.4 Authentication .................................. 22
7. References ............................................ 19 6. IANA considerations ................................... 22
7.1 Normative References ............................ 19 7. References ............................................ 22
7.2 Informative References .......................... 20 7.1 Normative References ............................ 22
Acknowledgments .............................................. 21 7.2 Informative References .......................... 23
Authors' Addresses ........................................... 21 Acknowledgments .............................................. 24
Intellectual Property Statement .............................. 22 Authors' Addresses ........................................... 25
Full Copyright Statement ..................................... 22 Intellectual Property Statement .............................. 25
Full Copyright Statement ..................................... 26
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which utilizes the DNS packet format for both requests and responses, which utilizes the DNS packet format and supports all current and future
and supports all current and future DNS formats, types and classes. DNS formats, types and classes. LLMNR operates on a separate port from
LLMNR operates on a separate port from the Domain Name System (DNS), the Domain Name System (DNS), with a distinct resolver cache.
with a distinct resolver 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
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 2. Since LLMNR only they respond with errors, as described in Section 2. Since LLMNR only
operates on the local link, it cannot be considered a substitute for operates on the local link, it cannot be considered a substitute for
DNS. DNS.
Link-scope multicast addresses are used to prevent propagation of LLMNR Link-scope multicast addresses are used to prevent propagation of LLMNR
traffic across routers, potentially flooding the network. LLMNR queries traffic across routers, potentially flooding the network. LLMNR queries
can also be sent to a unicast address, as described in Section 2.3. can also be sent to a unicast address, as described in Section 2.4.
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 gateway, then the network is able to provide DNS server a network has a gateway, then the network is able to provide DNS server
configuration. Configuration issues are discussed in Section 3.1. configuration. Configuration issues are discussed in Section 3.1.
In the future, it may be desirable to consider use of multicast name In the future, it may be desirable to consider use of multicast name
resolution with multicast scopes beyond the link-scope. This could resolution with multicast scopes beyond the link-scope. This could
occur if LLMNR deployment is successful, the need for multicast name occur if LLMNR deployment is successful, the need for multicast name
resolution beyond the link-scope, or multicast routing becomes resolution beyond the link-scope, or multicast routing becomes
skipping to change at page 4, line 4 skipping to change at page 3, line 52
Service discovery in general, as well as discovery of DNS servers using 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 LLMNR in particular, is outside of the scope of this document, as is
name resolution over non-multicast capable media. name resolution over non-multicast capable media.
1.1. Requirements 1.1. Requirements
In this document, several words are used to signify the requirements of In this document, several words are used to signify the requirements of
the specification. These words are often capitalized. The key words the specification. These words are often capitalized. The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
This document assumes familiarity with DNS terminology defined in This document assumes familiarity with DNS terminology defined in
[RFC1035]. Other terminology used in this document includes: [RFC1035]. Other terminology used in this document includes:
Routable address Positively Resolved
An address other than a Link-Local address. This includes Responses with RCODE set to zero are referred to in this document
globally routable addresses, as well as private addresses. as "positively resolved".
Responder A host that listens to LLMNR queries, and responds to those Routable Address
for which it is authoritative. An address other than a Link-Local address. This includes globally
routable addresses, as well as private addresses.
Sender A host that sends an LLMNR query. Responder
A host that listens to LLMNR queries, and responds to those for
which it is authoritative.
Sender
A host that sends an LLMNR query.
2. Name resolution using LLMNR 2. Name resolution using LLMNR
LLMNR is a peer-to-peer name resolution protocol that is not intended as LLMNR is a peer-to-peer name resolution protocol that is not intended as
a replacement for DNS. LLMNR queries are sent to and received on port a replacement for DNS. LLMNR queries are sent to and received on port
TBD. IPv4 administratively scoped multicast usage is specified in TBD. IPv4 administratively scoped multicast usage is specified in
"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope
multicast address a given responder listens to, and to which a sender multicast address a given responder listens to, and to which a sender
sends queries, is TBD. The IPv6 link-scope multicast address a given sends queries, is TBD. The IPv6 link-scope multicast address a given
responder listens to, and to which a sender sends all queries, is TBD. responder listens to, and to which a sender sends all queries, is TBD.
Typically a host is configured as both an LLMNR sender and a responder. Typically a host is configured as both an LLMNR sender and a responder.
A host MAY be configured as a sender, but not a responder. However, a A host MAY be configured as a sender, but not a responder. However, a
host configured as a responder MUST act as a sender to verify the host configured as a responder MUST act as a sender to verify the
uniqueness of names as described in Section 4. This document does not uniqueness of names as described in Section 4. This document does not
specify how names are chosen or configured. This may occur via any specify how names are chosen or configured. This may occur via any
mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].
LLMNR usage MAY be configured manually or automatically on a per 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. interfaces, at all times. Enabling LLMNR for use in situations where a
DNS server has been configured will result in upgraded hosts changing
their default behavior without a simultaneous update to configuration
information. Where this is considered undesirable, LLMNR SHOULD NOT be
enabled by default, so that hosts will neither listen on the link-scope
multicast address, nor will they send queries to that address.
An LLMNR sender may send a request for any name. However, by default, An LLMNR sender may send a request for any name. However, by default,
LLMNR requests SHOULD be sent only when one of the following conditions LLMNR requests SHOULD be sent only when one of the following conditions
are met: are met:
[1] No manual or automatic DNS configuration has been performed. If an [1] No manual or automatic DNS configuration has been performed. If an
interface has been configured with DNS server address(es), then interface has been configured with DNS server address(es), then
LLMNR SHOULD NOT be used as the primary name resolution mechanism LLMNR SHOULD NOT be used as the primary name resolution mechanism
on that interface, although it MAY be used as a name resolution on that interface, although it MAY be used as a name resolution
mechanism of last resort. mechanism of last resort.
skipping to change at page 5, line 18 skipping to change at page 5, line 28
Error) or RCODE=0, and an empty answer section. Error) or RCODE=0, and an empty answer section.
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 do not respond to a DNS query, or [a] DNS servers are not configured or do not respond to a DNS query, or
respond with RCODE=3, or RCODE=0 and an empty answer section. respond with RCODE=3, or RCODE=0 and an empty answer section.
[b] An LLMNR sender sends an LLMNR query to the link-scope multicast [b] An LLMNR sender sends an LLMNR query to the link-scope multicast
address(es) defined in Section 2, unless a unicast query is address(es) defined in Section 2, unless a unicast query is
indicated. A sender SHOULD send LLMNR queries for PTR RRs via indicated. A sender SHOULD send LLMNR queries for PTR RRs via
unicast, as specified in Section 2.3. unicast, as specified in Section 2.4.
[c] A responder responds to this query only if it is authoritative for [c] A responder responds to this query only if it is authoritative for
the domain name in the query. A responder responds to a multicast the domain name in the query. A responder responds to a multicast
query by sending a unicast UDP response to the sender. Unicast query by sending a unicast UDP response to the sender. Unicast
queries are responded to as indicated in Section 2.3. 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.
2.1. Sender behavior 2.1. LLMNR packet format
LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for
both queries and responses. Although [RFC1035] restricts DNS queries
and responses to 512 octets in length, since LLMNR operates only on the
local link, this restriction is not applicable. LLMNR implementations
MUST accept queries and responses as large as permitted by the link MTU.
2.1.1. LLMNR header format
LLMNR queries and responses utilize the DNS header format defined in
[RFC1035] and [RFC2535], as illustrated below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ID A 16 bit identifier assigned by the program that generates any kind
of query. This identifier is copied from the query to the response
and can be used by the sender to match responses to outstanding
queries.
QR A one bit field that specifies whether this message is an LLMNR
query (0), or an LLMNR response (1).
OPCODE
A four bit field that specifies kind of query in this message.
This value is set by the originator of a query and copied into the
response. LLMNR senders and responders MUST support standard
queries (opcode value of zero). LLMNR queries MUST NOT be sent
with other OPCODE values, and if sent, MUST be ignored by
responders.
AA Authoritative Answer. This bit is valid in LLMNR responses, and
specifies that the responder is an authority for the domain name in
the question section. Since responders only respond to LLMNR
queries for names and addresses they are authoritative for, the AA
bit MUST be set in LLMNR responses. If a sender receives a
response with the header containing the AA bit not set, the sender
MUST act as though the AA bit was set. The AA bit MUST NOT be set
in LLMNR queries, and MUST be ignored by LLMNR responders.
TC TrunCation - specifies that this message was truncated due to
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
by a responder. If the TC bit is set an LLMNR response, then the
sender MAY use the response if it contains all necessary
information, or the sender MAY discard the response and resend the
query over TCP using the unicast address of the responder as the
destination address. See [RFC2181] and Section 2.4 of this
specification for further discussion of the TC bit.
RD Recursion Desired. The RD bit MUST NOT be set in an LLMNR query or
response. If a responder receives an LLMNR query with the header
containing the RD bit set, the responder MUST act as though the RD
bit was not set. LLMNR senders MUST ignore the RD bit in LLMNR
responses.
RA Recursion Available. The RA bit MUST NOT be set in an LLMNR query
or response. If the RA bit is set in an LLMNR response, it MUST be
treated by the sender as though it was not set. LLMNR responders
MUST ignore the RA bit in LLMNR queries.
Z Reserved for future use. MUST be zero in all LLMNR queries and
responses. If these bits are set in an LLMNR query or response,
they MUST be ignored.
AD Authentic Data. The AD bit, defined in [RFC3655], MUST NOT be set
in an LLMNR query or response. If the AD bit is set in an LLMNR
query, it MUST be ignored by the responder. If the AD bit is set
in an LLMNR response, LLMNR senders MUST act as though the AD bit
were not set.
CD Checking Disabled. The CD bit, defined in [RFC2535], MUST NOT be
set in an LLMNR query or response. If the CD bit is set in an
LLMNR query, it MUST be ignored by the responder. LLMNR senders
MUST ignore the CD bit in LLMNR responses.
RCODE
Response code -- this 4 bit field is set as part of LLMNR
responses. In an LLMNR query, the RCODE MUST be zero, and is
ignored by the responder. The RCODE MUST be zero in an LLMNR
response. Instead of sending a response with a non-zero RCODE, a
LLMNR responder MUST NOT respond to a query. A sender receiving an
LLMNR response with a non-zero RCODE value MUST silently discard
the response.
QDCOUNT
An unsigned 16 bit integer specifying the number of entries in the
question section. A sender MUST place only one question into the
question section of an LLMNR query. LLMNR responders MUST ignore
questions after the first question.
ANCOUNT
An unsigned 16 bit integer specifying the number of resource
records in the answer section.
NSCOUNT
An unsigned 16 bit integer specifying the number of name server
resource records in the authority records section. Authority
record section processing is described in Section 2.9.
ARCOUNT
An unsigned 16 bit integer specifying the number of resource
records in the additional records section. Additional record
section processing is described in Section 2.9.
2.2. Sender behavior
An LLMNR query is composed in exactly the same manner and with the same An LLMNR query is composed in exactly the same manner and with the same
packet format as a DNS query as specified in [RFC1035]. The RD packet format as a DNS query. A sender may send an LLMNR query for any
(Recursion Desired) bit MUST NOT be set in a query. legal resource record type (e.g. A, AAAA, SRV, etc.) to the link-scope
multicast address.
A sender may send an LLMNR query for any legal resource record type As described in Section 2.4, a sender may also send a unicast query.
(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. As
described in Section 2.3, a sender may also send a unicast query.
Sections 2 and 3 describe the circumstances in which LLMNR queries may Sections 2 and 3 describe the circumstances in which LLMNR queries may
be sent. be sent.
The sender MUST anticipate receiving no replies to some LLMNR queries, 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 that no responders are available within the link-scope or
in the event no positive non-null responses exist for the transmitted in the event no positive non-null responses exist for the transmitted
query. If no positive response is received, a resolver treats it as a query. If no positive response is received, a resolver treats it as a
response that no records of the specified type and class exist for the 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 specified name (it is treated the same as a response with RCODE=0 and an
empty answer section). empty answer section).
Since the responder may order the RRs in the response so as to indicate Since the responder may order the RRs in the response so as to indicate
preference, the sender SHOULD preserve ordering in the response to the preference, the sender SHOULD preserve ordering in the response to the
querying application. querying application.
2.2. Responder behavior 2.3. Responder behavior
A response to an LLMNR query is composed in exactly the same manner and A response to an LLMNR query is composed in exactly the same manner and
with the same packet format as a response to a DNS query as specified in with the same packet format as a response to a DNS query. The response
[RFC1035]. The response MUST be sent to the sender via unicast. MUST be sent to the sender via unicast.
Upon configuring an IP address responders typically will synthesize Upon configuring an IP address responders typically will synthesize
corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR
queries for these RRs. An SOA RR is synthesized only when a responder queries for these RRs. An SOA RR is synthesized only when a responder
has another RR as well; the SOA RR MUST NOT be the only RR that a has another RR as well; the SOA RR MUST NOT be the only RR that a
responder has. However, in general whether RRs are manually or responder has. However, in general whether RRs are manually or
automatically created is an implementation decision. automatically created is an implementation decision.
In responding to queries: In responding to queries:
[a] Responders MUST NOT respond using cached data, and the AA [a] Responders MUST listen on UDP port TBD on the link-scope multicast
(Authoritative Answer) bit MUST be set.
[b] If a responder receives a query with the header containing the RD
bit set, the responder MUST ignore the RD bit.
[c] Responders MUST listen on UDP port TBD on the link-scope multicast
address(es) defined in Section 2, and on UDP and TCP port TBD on address(es) defined in Section 2, and on UDP and TCP port TBD on
the unicast address(es) that could be set as the source address(es) the unicast address(es) that could be set as the source address(es)
when the responder responds to the LLMNR query. when the responder responds to the LLMNR query.
[b] Responders MUST direct responses to the port from which the query
was sent. When queries are received via TCP this is an inherent
part of the transport protocol. For queries received by UDP the
responder MUST take note of the source port and use that as the
destination port in the response. Responses SHOULD always be sent
from the port to which they were directed.
[c] Responders MUST NOT respond using cached data. The AA bit MUST be
set in LLMNR responses.
[d] Responders MUST NOT respond to LLMNR queries for names they are not [d] Responders MUST NOT respond to LLMNR queries for names they are not
authoritative for. authoritative for.
[e] A response to an LLMNR query MUST have RCODE set to zero. [e] Responders MUST respond to LLMNR queries for names and addresses
Responses with RCODE set to zero are referred to in this document
as "positively resolved".
[f] Responders MUST respond to LLMNR queries for names and addresses
they are authoritative for. This applies to both forward and they are authoritative for. This applies to both forward and
reverse lookups. reverse lookups.
[g] If a DNS server is running on a host that supports LLMNR, the DNS [f] If a DNS server is running on a host that supports LLMNR, the DNS
server MUST respond to LLMNR queries only for the RRSets relating server MUST respond to LLMNR queries only for the RRSets relating
to the host on which the server is running, but MUST NOT respond to the host on which the server is running, but MUST NOT respond
for other records for which the server is authoritative. DNS for other records for which the server is authoritative. DNS
servers also MUST NOT send LLMNR queries in order to resolve DNS servers also MUST NOT send LLMNR queries in order to resolve DNS
queries. queries.
[h] If a responder is authoritative for a name, it MAY respond with [g] If a responder is authoritative for a name, it MAY respond with
RCODE=0 and an empty answer section, if the type of query does not RCODE=0 and an empty answer section, if the type of query does not
match a RR that the responder has. match a RR that the responder has.
As an example, a host configured to respond to LLMNR queries for the As an example, a host configured to respond to LLMNR queries for the
name "foo.example.com." is authoritative for the name name "foo.example.com." is authoritative for the name
"foo.example.com.". On receiving an LLMNR query for an A RR with the "foo.example.com.". On receiving an LLMNR query for an A RR with the
name "foo.example.com." the host authoritatively responds with A RR(s) name "foo.example.com." the host authoritatively responds with A RR(s)
that contain IP address(es) in the RDATA of the resource record. If the that contain IP address(es) in the RDATA of the resource record. If the
responder has a AAAA RR, but no A RR, and an A RR query is received, the responder has a AAAA RR, but no A RR, and an A RR query is received, the
responder would respond with RCODE=0 and an empty answer section. responder would respond with RCODE=0 and an empty answer section.
skipping to change at page 7, line 42 skipping to change at page 10, line 28
result in two authoritative responses: RCODE=3 (authoritative name result in two authoritative responses: RCODE=3 (authoritative name
error) received from "foo.example.com.", and a requested A record - from error) received from "foo.example.com.", and a requested A record - from
"child.foo.example.com.". To prevent this ambiguity, LLMNR enabled "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
hosts could perform a dynamic update of the parent (or grandparent) zone hosts could perform a dynamic update of the parent (or grandparent) zone
with a delegation to a child zone. In this example a host with a delegation to a child zone. In this example a host
"child.foo.example.com." would send a dynamic update for the NS and glue "child.foo.example.com." would send a dynamic update for the NS and glue
A record to "foo.example.com.", but this approach significantly A record to "foo.example.com.", but this approach significantly
complicates implementation of LLMNR and would not be acceptable for complicates implementation of LLMNR and would not be acceptable for
lightweight hosts. lightweight hosts.
2.3. Unicast queries and responses 2.4. Unicast queries and responses
Unicast queries SHOULD be sent when: Unicast queries SHOULD be sent when:
[a] A sender repeats a query after it received a response with the TC [a] A sender repeats a query after it received a response with the TC
bit set to the previous LLMNR multicast query, or bit set to the previous LLMNR multicast query, or
[b] The sender queries for a PTR RR of a fully formed IP address within [b] The sender queries for a PTR RR of a fully formed IP address within
the "in-addr.arpa" or "ip6.arpa" zones. the "in-addr.arpa" or "ip6.arpa" zones.
If a TC (truncation) bit is set in the response, then the sender MAY use A responder receiving a unicast query MUST send the response with a
the response if it contains all necessary information, or the sender MAY source address set to the destination address field of the IP header of
discard the response and resend the query over TCP using the unicast the query causing the response.
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.
Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support
unicast LLMNR queries MUST be sent using TCP, using the same connection sending TCP queries, and responders MUST support listening for TCP
as the query. If the sender of a TCP query receives a response to that queries.
query not using TCP, the response MUST be silently discarded.
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 to that query not using TCP, the response MUST be silently
discarded.
Unicast UDP queries MAY be responded to with a UDP response containing Unicast UDP queries MAY be responded to with a UDP response containing
an empty answer section and the TC bit set, so as to require the sender 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. to resend the query using TCP.
If an ICMP "Time Exceeded" message is received in response to a unicast If an ICMP "Time Exceeded" message is received in response to a unicast
UDP query, or if TCP connection setup cannot be completed in order to 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 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 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 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 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 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 cannot be made, then the sender relies on the retransmission and timeout
behavior described in Section 2.6. behavior described in Section 2.7.
2.4. "Off link" detection 2.5. "Off link" detection
For IPv4, an "on link" address is defined as a link-local address For IPv4, an "on link" address is defined as a link-local address
[IPv4Link] or an address whose prefix belongs to a subnet on the local [IPv4Link] 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 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 address, defined in [RFC2373], or an address whose prefix belongs to a
subnet on the local link. subnet on the local link.
A sender MUST select a source address for LLMNR queries that is "on A sender MUST select a source address for LLMNR queries that is "on
link". The destination address of an LLMNR query MUST be a link-scope link". The destination address of an LLMNR query MUST be a link-scope
multicast address or an "on link" unicast address. multicast address or an "on link" unicast address.
skipping to change at page 9, line 21 skipping to change at page 12, line 5
link-scope multicast, or that link-scope multicast addresses may leak link-scope multicast, or that link-scope multicast addresses may leak
into the multicast routing system. Therefore setting the IPv6 Hop Limit into the multicast routing system. Therefore setting the IPv6 Hop Limit
or IPv4 TTL field to one provides an additional precaution against or IPv4 TTL field to one provides an additional precaution against
leakage of LLMNR queries. leakage of LLMNR queries.
In composing a response to an LLMNR query, the responder MUST set the In composing a response to an LLMNR query, the responder MUST set the
Hop Limit field in the IPv6 header and the TTL field in IPv4 header of Hop Limit field in the IPv6 header and the TTL field in IPv4 header of
the response to one (1). This is done so as to prevent the use of LLMNR the response to one (1). This is done so as to prevent the use of LLMNR
for denial of service attacks across the Internet. for denial of service attacks across the Internet.
Section 2.3 discusses use of TCP for LLMNR queries and responses. The Section 2.4 discusses use of TCP for LLMNR queries and responses. The
responder SHOULD set the TTL or Hop Limit settings on the TCP listen 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 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 connection from 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. off-link since the sender will not receive a SYN-ACK from the responder.
Implementation note: Implementation note:
In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL
socket options are used to set the TTL of outgoing unicast and socket options are used to set the TTL of outgoing unicast and
multicast packets. The IP_RECVTTL socket option is available on some multicast packets. The IP_RECVTTL socket option is available on some
platforms to retrieve the IPv4 TTL of received packets with platforms to retrieve the IPv4 TTL of received packets with
recvmsg(). [RFC2292] specifies similar options for setting and recvmsg(). [RFC2292] specifies similar options for setting and
retrieving the IPv6 Hop Limit. retrieving the IPv6 Hop Limit.
2.5. Responder responsibilities 2.6. Responder responsibilities
It is the responsibility of the responder to ensure that RRs returned in It is the responsibility of the responder to ensure that RRs returned in
LLMNR responses MUST only include values that are valid on the local 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 interface, such as IPv4 or IPv6 addresses valid on the local link or
names defended using the mechanism described in Section 4. In names defended using the mechanism described in Section 4. In
particular: particular:
[a] If a link-scope IPv6 address is returned in a AAAA RR, that address [a] 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 used. MUST be valid on the local link over which LLMNR is used.
[b] If an IPv4 address is returned, it MUST be reachable through the [b] If an IPv4 address is returned, it MUST be reachable through the
link over which LLMNR is used. link over which LLMNR is used.
[c] If a name is returned (for example in a CNAME, MX or SRV RR), the [c] If a name is returned (for example in a CNAME, MX or SRV RR), the
name MUST be resolvable on the local link over which LLMNR is used. name MUST be resolvable on the local link over which LLMNR is used.
Routable addresses MUST be included first in the response, if available. Routable addresses MUST be included first in the response, if available.
This encourages use of routable address(es) for establishment of new This encourages use of routable address(es) for establishment of new
connections. connections.
2.6. Retransmissions 2.7. Retransmission and jitter
In order to avoid synchronization, LLMNR queries and responses are An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
delayed by a time randomly selected from the interval 0 to 200 ms. when to retransmit an LLMNR query and how long to collect responses to
an LLMNR query.
If an LLMNR query sent over UDP is not resolved within the timeout If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of then a sender MAY repeat the transmission of the query in order to
the query in order to assure that it was received by a host capable of assure that it was received by a host capable of responding to it.
responding to it. Retransmission of UDP queries SHOULD NOT be attempted Retransmission of UDP queries SHOULD NOT be attempted more than 3 times.
more than 3 times. Where LLMNR queries are sent using TCP, Where LLMNR queries are sent using TCP, retransmission is handled by the
retransmission is handled by the transport layer. transport layer.
Since a multicast query sender cannot know beforehand whether it will Because an LLMNR sender cannot know in advance if a query sent using
receive no response, one response, or more than one response, it SHOULD multicast will receive no response, one response, or more than one
wait for LLMNR_TIMEOUT in order to collect all possible responses, response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect
rather than considering the multicast query answered after the first all possible responses, rather than considering the multicast query
response is received. A unicast query sender considers the query answered after the first response is received. A unicast query sender
answered after the first response is received, so that it only waits for considers the query answered after the first response is received, so
LLMNR_TIMEOUT if no response has been received. that it only waits for LLMNR_TIMEOUT if no response has been received.
An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
for each transmission. It is suggested that the computation of
LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries
sent on the same interface.
For example, the algorithms described in RFC 2988 [RFC2988] (including
exponential backoff) to compute an RTO, which is used as the value of
LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed
in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in
Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed
in Section 2 of [RFC2988], paragraph 2.5).
LLMNR implementations SHOULD dynamically compute the timeout value
(LLMNR_TIMEOUT). It is suggested that this be based on the last
response received for a query, on a per-interface basis. For example,
the algorithms described in [RFC2988] (including exponential backoff)
may be used to estimate RTO, which when combined with jittering, is used
as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the
initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the
minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and
the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
Recommended values are an initial RTO of 1 second, a minimum RTO of Recommended values are an initial RTO of 1 second, a minimum RTO of
200ms, and a maximum RTO of 20 seconds. 500ms, and a maximum RTO of 5 seconds. In order to avoid
synchronization, the transmission of each LLMNR query and response
SHOULD delayed by a time randomly selected from the interval 0 to 100
ms. This delay MAY be avoided by responders responding with RRs which
they have previously determined to be UNIQUE (see Section 4 for
details).
2.7. DNS TTL 2.8. 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. A default value of 30 seconds is returned an LLMNR response. A default value of 30 seconds is
RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
networks), the TTL value may need to be reduced. networks), the TTL value may need to be reduced.
Due to the TTL minimalization necessary when caching an RRset, all TTLs Due to the TTL minimalization necessary when caching an RRset, all TTLs
in an RRset MUST be set to the same value. in an RRset MUST be set to the same value.
2.8. Use of the authority and additional sections 2.9. Use of the authority and additional sections
Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
concept of delegation. In LLMNR, the NS resource record type may be concept of delegation. In LLMNR, the NS resource record type may be
stored and queried for like any other type, but it has no special stored and queried for like any other type, but it has no special
delegation semantics as it does in the DNS. Responders MAY have NS delegation semantics as it does in the DNS. Responders MAY have NS
records associated with the names for which they are authoritative, but records associated with the names for which they are authoritative, but
they SHOULD NOT include these NS records in the authority sections of they SHOULD NOT include these NS records in the authority sections of
responses. responses.
Responders SHOULD insert an SOA record into the authority section of a Responders SHOULD insert an SOA record into the authority section of a
skipping to change at page 14, line 21 skipping to change at page 17, line 14
same name, type and class. same name, type and class.
[2] MUST NOT include a UNIQUE resource record in the response without [2] MUST NOT include a UNIQUE resource record in the response without
having verified its uniqueness. having verified its uniqueness.
Where a host is configured to issue LLMNR queries on more than one Where a host is configured to issue 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 configuration, For each UNIQUE resource record in a given interface's configuration,
the host MUST verify resource record uniqueness on that interface. To the host MUST verify resource record uniqueness on that interface. To
accomplish this, the host MUST send an LLMNR query for each UNIQUE accomplish this, the host MUST send an LLMNR query for each UNIQUE
resource record, as described in Section 2.6. resource record.
By default, a host SHOULD be configured to behave as though all RRs are By default, a host SHOULD be configured to behave as though all RRs are
UNIQUE. Uniqueness verification is carried out when the host: UNIQUE. Uniqueness verification is carried out when the host:
- starts up or is rebooted - starts up or is rebooted
- wakes from sleep (if the network interface was inactive during sleep) - wakes from sleep (if the network interface was inactive during sleep)
- is configured to respond to the LLMNR queries on an interface - is configured to respond to the LLMNR queries on an interface
enabled for transmission and reception of IP traffic enabled for transmission and reception of IP traffic
- 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
- detects that an interface is connected and is usable
(e.g. an IEEE 802 hardware link-state change indicating
that a cable was attached or that an association has occurred
with a wireless base station and that any required authentication
has completed)
When a host that has a UNIQUE record receives an LLMNR query for that When a host that has a UNIQUE record receives an LLMNR query for that
record, the host MUST respond. After the client receives a response, it record, the host MUST respond. After the client receives a response, it
MUST check whether the response arrived on an interface different from MUST check whether the response arrived on an interface different from
the one on which the query was sent. If the response arrives on a the one on which the query was sent. If the response arrives on a
different interface, the client can use the UNIQUE resource record in different interface, the client can use the UNIQUE resource record in
response to LLMNR queries. If not, then it MUST NOT use the UNIQUE response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
resource record in response to LLMNR queries. resource record in response to LLMNR queries.
The name conflict detection mechanism doesn't prevent name conflicts The name conflict detection mechanism doesn't prevent name conflicts
skipping to change at page 18, line 39 skipping to change at page 21, line 36
The vulnerability is more serious if LLMNR is given higher priority than The vulnerability is more serious if LLMNR is given higher priority than
DNS among the enabled name resolution mechanisms. In such a DNS among the enabled name resolution mechanisms. In such a
configuration, a denial of service attack on the DNS server would not be configuration, a denial of service attack on the DNS server would not be
necessary in order to poison the LLMNR cache, since LLMNR queries would necessary in order to poison the LLMNR cache, since LLMNR queries would
be sent even when the DNS server is available. In addition, the LLMNR be sent even when the DNS server is available. In addition, the LLMNR
cache, once poisoned, would take precedence over the DNS cache, cache, once poisoned, would take precedence over the DNS cache,
eliminating the benefits of cache separation. As a result, LLMNR is only eliminating the benefits of cache separation. As a result, LLMNR is only
used as a name resolution mechanism of last resort. used as a name resolution mechanism of last resort.
Note: enabling LLMNR for use in situations where a DNS server has been
configured will result in upgraded hosts changing their default behavior
without a simultaneous update to configuration information. Where this
is considered undesirable, LLMNR SHOULD NOT be enabled by default, so
that hosts will neither listen on the link-scope multicast address, nor
will they send queries to that address.
5.3. Cache and port separation 5.3. 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 effective LLMNR on each interface. The use of separate caches is most effective
when LLMNR is used as a name resolution mechanism of last resort, since when LLMNR is used as a name resolution mechanism of last resort, since
this minimizes the opportunities for poisoning the LLMNR cache, and this minimizes the opportunities for poisoning the LLMNR cache, and
decreases reliance on it. decreases reliance on it.
LLMNR operates on a separate port from DNS, reducing the likelihood that LLMNR operates on a separate port from DNS, reducing the likelihood that
a DNS server will unintentionally respond to an LLMNR query. a DNS server will unintentionally respond to an LLMNR query.
5.4. Authentication 5.4. Authentication
LLMNR does not require use of DNSSEC, and as a result, responses to LLMNR implementations may not support DNSSEC, and as a result, responses
LLMNR queries may be unauthenticated. If authentication is desired, and to LLMNR queries may be unauthenticated. If authentication is desired,
a pre-arranged security configuration is possible, then IPsec ESP with a and a pre-arranged security configuration is possible, then IPsec ESP
null-transform MAY be used to authenticate LLMNR responses. In a small
network without a certificate authority, this can be most easily with a null-transform MAY be used to authenticate LLMNR responses. In a
small network without a certificate authority, this can be most easily
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 requires allocation of a link-scope multicast IPv4 address TBD. LLMNR requires allocation of a link-scope multicast IPv4 address TBD.
skipping to change at page 19, line 43 skipping to change at page 22, line 33
[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.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998. RFC 2308, March 1998.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998. 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.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 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", RFC [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
[RFC2845] Vixie, P., et al., "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, September 2000.
[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.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001.
[RFC3655] Wellington, B. and G. Gudmundsson, "Redefinition of the DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
7.2. Informative References 7.2. Informative References
[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.
[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
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
skipping to change at page 22, line 36 skipping to change at page 25, line 43
IETF Secretariat. IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
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
Open issues with this specification are tracked on the following web Open issues with this specification are tracked on the following web
site: site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
skipping to change at page 23, line 18 skipping to change at page 26, line 25
Open Issues Open Issues
Open issues with this specification are tracked on the following web Open issues with this specification are tracked on the following web
site: site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-27.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-28.txt>, and expires
June 22, 2004. July 4, 2004.
 End of changes. 

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