draft-ietf-dnsext-mdns-46.txt   draft-ietf-dnsext-mdns-47.txt 
DNSEXT Working Group Bernard Aboba DNSEXT Working Group Bernard Aboba
INTERNET-DRAFT Dave Thaler INTERNET-DRAFT Dave Thaler
Category: Standards Track Levon Esibov Category: Standards Track Levon Esibov
<draft-ietf-dnsext-mdns-46.txt> Microsoft Corporation <draft-ietf-dnsext-mdns-47.txt> Microsoft Corporation
Linklocal Multicast Name Resolution (LLMNR) 13 August 2006
Link-local Multicast Name Resolution (LLMNR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 32 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 15, 2006. This Internet-Draft will expire on January 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2006. Copyright (C) The Internet Society 2006.
Abstract Abstract
The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
name resolution in scenarios in which conventional DNS name name resolution in scenarios in which conventional DNS name
resolution is not possible. LLMNR supports all current and future resolution is not possible. LLMNR supports all current and future
DNS formats, types and classes, while operating on a separate port DNS formats, types and classes, while operating on a separate port
from DNS, and with a distinct resolver cache. Since LLMNR only from DNS, and with a distinct resolver cache. 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 .................................... 4 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 LLMNR Packet Format ............................. 5 2.1 LLMNR Packet Format ............................. 5
2.2 Sender Behavior ................................. 8 2.2 Sender Behavior ................................. 8
2.3 Responder Behavior .............................. 8 2.3 Responder Behavior .............................. 8
2.4 Unicast Queries and Responses ................... 11 2.4 Unicast Queries and Responses ................... 11
2.5 Off-link Detection .............................. 11 2.5 Off-link Detection .............................. 11
2.6 Responder Responsibilities ...................... 12 2.6 Responder Responsibilities ...................... 12
2.7 Retransmission and Jitter ....................... 13 2.7 Retransmission and Jitter ....................... 13
2.8 DNS TTL ......................................... 14 2.8 RR TTL .......................................... 14
2.9 Use of the Authority and Additional Sections .... 14 2.9 Use of the Authority and Additional Sections .... 14
3. Usage model ........................................... 15 3. Usage model ........................................... 15
3.1 LLMNR Configuration ............................. 16 3.1 LLMNR Configuration ............................. 16
4. Conflict Resolution ................................... 18 4. Conflict Resolution ................................... 18
4.1 Uniqueness Verification ......................... 18 4.1 Uniqueness Verification ......................... 18
4.2 Conflict Detection and Defense .................. 19 4.2 Conflict Detection and Defense .................. 19
4.3 Considerations for Multiple Interfaces .......... 20 4.3 Considerations for Multiple Interfaces .......... 20
4.4 API issues ...................................... 22 4.4 API issues ...................................... 22
5. Security Considerations ............................... 22 5. Security Considerations ............................... 22
5.1 Denial of Service ............................... 22 5.1 Denial of Service ............................... 22
5.2 Spoofing ...............,........................ 23 5.2 Spoofing ...............,........................ 23
5.3 Authentication .................................. 24 5.3 Authentication .................................. 24
5.4 Cache and Port Separation ....................... 24 5.4 Cache and Port Separation ....................... 24
6. IANA considerations ................................... 25 6. IANA considerations ................................... 25
7. Constants ............................................. 25 7. Constants ............................................. 25
8. References ............................................ 26 8. References ............................................ 25
8.1 Normative References ............................ 26 8.1 Normative References ............................ 25
8.2 Informative References .......................... 26 8.2 Informative References .......................... 26
Acknowledgments .............................................. 28 Acknowledgments .............................................. 28
Authors' Addresses ........................................... 28 Authors' Addresses ........................................... 28
Intellectual Property Statement .............................. 29 Intellectual Property Statement .............................. 29
Disclaimer of Validity ....................................... 29 Disclaimer of Validity ....................................... 29
Copyright Statement .......................................... 29 Copyright Statement .......................................... 29
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
skipping to change at page 6, line 26 skipping to change at page 6, line 26
OPCODE OPCODE
A four bit field that specifies the kind of query in this message. A four bit field that specifies the kind of query in this message.
This value is set by the originator of a query and copied into the This value is set by the originator of a query and copied into the
response. This specification defines the behavior of standard response. This specification defines the behavior of standard
queries and responses (opcode value of zero). Future queries and responses (opcode value of zero). Future
specifications may define the use of other opcodes with LLMNR. specifications may define the use of other opcodes with LLMNR.
LLMNR senders and responders MUST support standard queries (opcode LLMNR senders and responders MUST support standard queries (opcode
value of zero). LLMNR queries with unsupported OPCODE values MUST value of zero). LLMNR queries with unsupported OPCODE values MUST
be silently discarded by responders. be silently discarded by responders.
C Conflict. When set within a request, the 'C'onflict bit indicates C Conflict. When set within a query, the 'C'onflict bit indicates
that a sender has received multiple LLMNR responses to this query. that a sender has received multiple LLMNR responses to this query.
In an LLMNR response, if the name is considered UNIQUE, then the In an LLMNR response, if the name is considered UNIQUE, then the
'C' bit is clear, otherwise it is set. LLMNR senders do not 'C' bit is clear, otherwise it is set. LLMNR senders do not
retransmit queries with the 'C' bit set. Responders MUST NOT retransmit queries with the 'C' bit set. Responders MUST NOT
respond to LLMNR queries with the 'C' bit set, but may start the respond to LLMNR queries with the 'C' bit set, but may start the
uniqueness verification process, as described in Section 4.2. uniqueness verification process, as described in Section 4.2.
TC TrunCation - specifies that this message was truncated due to TC TrunCation - specifies that this message was truncated due to
length greater than that permitted on the transmission channel. length greater than that permitted on the transmission channel.
The TC bit MUST NOT be set in an LLMNR query and if set is ignored The TC bit MUST NOT be set in an LLMNR query and if set is ignored
skipping to change at page 8, line 24 skipping to change at page 8, line 24
An unsigned 16 bit integer specifying the number of resource An unsigned 16 bit integer specifying the number of resource
records in the additional records section. Additional record records in the additional records section. Additional record
section processing is described in Section 2.9. section processing is described in Section 2.9.
2.2. Sender Behavior 2.2. Sender Behavior
A sender MAY send an LLMNR query for any legal resource record type A sender MAY send an LLMNR query for any legal resource record type
(e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
As described in Section 2.4, a sender MAY also send a unicast query. As described in Section 2.4, a sender MAY also send a unicast query.
The sender MUST anticipate receiving no replies to some LLMNR The sender MUST anticipate receiving no responses to some LLMNR
queries, in the event that no responders are available within the queries, in the event that no responders are available within the
link-scope. If no response is received, a resolver treats it as a link-scope. If no response is received, a resolver treats it as a
response that the name does not exist (RCODE=3 is returned). A response that the name does not exist (RCODE=3 is returned). A
sender can handle duplicate responses by discarding responses with a sender can handle duplicate responses by discarding responses with a
source IP address and ID field that duplicate a response already source IP address and ID field that duplicate a response already
received. received.
When multiple valid LLMNR responses are received with the 'C' bit When multiple valid LLMNR responses are received with the 'C' bit
set, they SHOULD be concatenated and treated in the same manner that set, they SHOULD be concatenated and treated in the same manner that
multiple RRs received from the same DNS server would be. However, multiple RRs received from the same DNS server would be. However,
skipping to change at page 10, line 8 skipping to change at page 10, line 8
they are authoritative for. This applies to both forward and they are authoritative for. This applies to both forward and
reverse lookups, with the exception of queries with the 'C' bit reverse lookups, with the exception of queries with the 'C' bit
set, which do not elicit a response. set, which do not elicit a response.
[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] Responders MUST NOT respond using data from the LLMNR or DNS [e] Responders MUST NOT respond using data from the LLMNR or DNS
resolver cache. resolver cache.
[f] If a DNS server is running on a host that supports LLMNR, the DNS [f] If a responder is authoritative for a name, it MUST respond with
server MUST respond to LLMNR queries only for the RRSets relating
to the host on which the server is running, but MUST NOT respond
for other records for which the server is authoritative. DNS
servers also MUST NOT send LLMNR queries in order to resolve DNS
queries.
[g] If a responder is authoritative for a name, it MUST 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 name "foo.example.com." the host authoritatively responds with A
RR(s) that contain IP address(es) in the RDATA of the resource RR(s) 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 record. If 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 query is received, the responder would respond with RCODE=0 and an
skipping to change at page 10, line 38 skipping to change at page 10, line 31
In conventional DNS terminology a DNS server authoritative for a zone In conventional DNS terminology a DNS server authoritative for a zone
is authoritative for all the domain names under the zone apex except is authoritative for all the domain names under the zone apex except
for the branches delegated into separate zones. Contrary to for the branches delegated into separate zones. Contrary to
conventional DNS terminology, an LLMNR responder is authoritative conventional DNS terminology, an LLMNR responder is authoritative
only for the zone apex. only for the zone apex.
For example the host "foo.example.com." is not authoritative for the For example the host "foo.example.com." is not authoritative for the
name "child.foo.example.com." unless the host is configured with name "child.foo.example.com." unless the host is configured with
multiple names, including "foo.example.com." and multiple names, including "foo.example.com." and
"child.foo.example.com.". As a result, "foo.example.com." cannot "child.foo.example.com.". As a result, "foo.example.com." cannot
reply to an LLMNR query for "child.foo.example.com." with RCODE=3 respond to an LLMNR query for "child.foo.example.com." with RCODE=3
(authoritative name error). The purpose of limiting the name (authoritative name error). The purpose of limiting the name
authority scope of a responder is to prevent complications that could authority scope of a responder is to prevent complications that could
be caused by coexistence of two or more hosts with the names be caused by coexistence of two or more hosts with the names
representing child and parent (or grandparent) nodes in the DNS tree, representing child and parent (or grandparent) nodes in the DNS tree,
for example, "foo.example.com." and "child.foo.example.com.". for example, "foo.example.com." and "child.foo.example.com.".
Without the restriction on authority an LLMNR query for an A resource Without the restriction on authority an LLMNR query for an A resource
record for the name "child.foo.example.com." would result in two record for the name "child.foo.example.com." would result in two
authoritative responses: RCODE=3 (authoritative name error) received authoritative responses: RCODE=3 (authoritative name error) received
from "foo.example.com.", and a requested A record - from from "foo.example.com.", and a requested A record - from
skipping to change at page 14, line 7 skipping to change at page 14, line 5
followed by a response with the 'C' bit set, an LLMNR sender SHOULD followed by a response with the 'C' bit set, an LLMNR sender SHOULD
be prepared to process additional responses for the purposes of be prepared to process additional responses for the purposes of
conflict detection, even after it has considered a query answered. conflict detection, even after it has considered a query answered.
In order to avoid synchronization, the transmission of each LLMNR In order to avoid synchronization, the transmission of each LLMNR
query and response SHOULD delayed by a time randomly selected from query and response SHOULD delayed by a time randomly selected from
the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
responders responding with names which they have previously responders responding with names which they have previously
determined to be UNIQUE (see Section 4 for details). determined to be UNIQUE (see Section 4 for details).
2.8. DNS TTL 2.8. RR TTL
The responder should insert a pre-configured TTL value in the records The responder should insert a pre-configured TTL value in the records
returned in an LLMNR response. A default value of 30 seconds is returned in 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 Due to the TTL minimalization necessary when caching an RRset, all
TTLs in an RRset MUST be set to the same value. TTLs in an RRset MUST be set to the same value.
2.9. Use of the Authority and Additional Sections 2.9. Use of the Authority and Additional Sections
skipping to change at page 15, line 7 skipping to change at page 15, line 7
notifications are advisory, responders SHOULD log information from notifications are advisory, responders SHOULD log information from
the additional section, but otherwise MUST ignore the additional the additional section, but otherwise MUST ignore the additional
section. section.
Senders MUST NOT cache RRs from the authority or additional section Senders MUST NOT cache RRs from the authority or additional section
of a response as answers, though they may be used for other purposes of a response as answers, though they may be used for other purposes
such as negative caching. such as negative caching.
3. Usage Model 3. Usage Model
By default, an LLMNR sender SHOULD send LLMNR queries only for
single-label names. Stub resolvers supporting both DNS and LLMNR
SHOULD avoid sending DNS queries for single-label names, in order to
reduce unnecessary DNS queries. An LLMNR sender SHOULD NOT be
enabled to send a query for any name, except where security
mechanisms (described in Section 5.3) can be utilized. An LLMNR
query SHOULD only be sent for the originally requested name; a
searchlist is not used to form additional LLMNR queries.
LLMNR is a peer-to-peer name resolution protocol that is not intended LLMNR is a peer-to-peer name resolution protocol that is not intended
as a replacement for DNS; rather, it enables name resolution in as a replacement for DNS; rather, it enables name resolution in
scenarios in which conventional DNS name resolution is not possible. scenarios in which conventional DNS name resolution is not possible.
This includes situations in which hosts are not configured with the Where LLMNR security is not enabled as described in Section 5.3, if
address of a DNS server; where the DNS server is unavailable or LLMNR is given higher priority than DNS among the enabled name
unreachable; where there is no DNS server authoritative for the name resolution mechanisms, this would allow the LLMNR cache, once
of a host, or where the authoritative DNS server does not have the poisoned, to take precedence over the DNS cache. As a result, use of
desired RRs. LLMNR as a primary name resolution mechanism is NOT RECOMMENDED.
By default, an LLMNR sender SHOULD send LLMNR queries only for Instead, it is recommended that LLMNR be utilized as a secondary name
single-label names. In order to reduce unnecessary DNS queries, stub resolution mechanism, for use in situations where hosts are not
resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS configured with the address of a DNS server; where the DNS server is
queries for single-label names. An LLMNR sender SHOULD NOT be unavailable or unreachable; where there is no DNS server
enabled to send a query for any name, except where security authoritative for the name of a host, or where the authoritative DNS
mechanisms (described in Section 5.3) can be utilized. server does not have the desired RRs.
Regardless of whether security mechanisms can be utilized, LLMNR When LLMNR is configured as a secondary name resolution mechanism,
queries SHOULD NOT be sent unless one of the following conditions are LLMNR queries SHOULD only be sent when all of the following
met: conditions are met:
[1] No manual or automatic DNS configuration has been performed. [1] No manual or automatic DNS configuration has been performed.
If DNS server address(es) have been configured, a If DNS server address(es) have been configured, a
host SHOULD attempt to reach DNS servers over all protocols host SHOULD attempt to reach DNS servers over all protocols
on which DNS server address(es) are configured, prior to sending on which DNS server address(es) are configured, prior to sending
LLMNR queries. For dual stack hosts configured with DNS server LLMNR queries. For dual stack hosts configured with DNS server
address(es) for one protocol but not another, this implies that address(es) for one protocol but not another, this implies that
DNS queries SHOULD be sent over the protocol configured with DNS queries SHOULD be sent over the protocol configured with
a DNS server, prior to sending LLMNR queries. a DNS server, prior to sending LLMNR queries.
[2] All attempts to resolve the name via DNS on all interfaces [2] All attempts to resolve the name via DNS on all interfaces
have failed after exhausting the searchlist. This can occur have failed after exhausting the searchlist. This can occur
because DNS servers did not respond, or because they because DNS servers did not respond, or because they
responded to DNS queries with RCODE=3 (Authoritative Name responded to DNS queries with RCODE=3 (Authoritative Name
Error) or RCODE=0, and an empty answer section. Where a Error) or RCODE=0, and an empty answer section. Where a
single resolver call generates DNS queries for A and AAAA RRs, single resolver call generates DNS queries for A and AAAA RRs,
an implementation MAY choose not to send LLMNR queries if any an implementation MAY choose not to send LLMNR queries if any
of the DNS queries is successful. An LLMNR query SHOULD only of the DNS queries is successful.
be sent for the originally requested name; a searchlist
is not used to form additional LLMNR queries.
Since LLMNR is a secondary name resolution mechanism, its usage is in
part determined by the behavior of DNS implementations. In general,
robust DNS resolver implementations are more likely to avoid
unnecessary LLMNR queries.
As noted in [DNSPerf], even when DNS servers are configured, a Where LLMNR is used as a secondary name resolution mechanism, its
significant fraction of DNS queries do not receive a response, or usage is in part determined by the behavior of DNS resolver
result in negative responses due to missing inverse mappings or NS implementations; robust resolver implementations are more likely to
records that point to nonexistent or inappropriate hosts. This has avoid unnecessary LLMNR queries.
the potential to result in a large number of unnecessary LLMNR
queries.
[RFC1536] describes common DNS implementation errors and fixes. If [RFC1536] describes common DNS implementation errors and fixes. If
the proposed fixes are implemented, unnecessary LLMNR queries will be the proposed fixes are implemented, unnecessary LLMNR queries will be
reduced substantially, and so implementation of [RFC1536] is reduced substantially, and so implementation of [RFC1536] is
recommended. recommended.
For example, [RFC1536] Section 1 describes issues with retransmission For example, [RFC1536] Section 1 describes issues with retransmission
and recommends implementation of a retransmission policy based on and recommends implementation of a retransmission policy based on
round trip estimates, with exponential back-off. [RFC1536] Section 4 round trip estimates, with exponential back-off. [RFC1536] Section 4
describes issues with failover, and recommends that resolvers try describes issues with failover, and recommends that resolvers try
skipping to change at page 16, line 30 skipping to change at page 16, line 30
policies are likely to avoid unnecessary LLMNR queries. policies are likely to avoid unnecessary LLMNR queries.
[RFC1536] Section 3 describes zero answer bugs, which if addressed [RFC1536] Section 3 describes zero answer bugs, which if addressed
will also reduce unnecessary LLMNR queries. will also reduce unnecessary LLMNR queries.
[RFC1536] Section 6 describes name error bugs and recommended [RFC1536] Section 6 describes name error bugs and recommended
searchlist processing that will reduce unnecessary RCODE=3 searchlist processing that will reduce unnecessary RCODE=3
(authoritative name) errors, thereby also reducing unnecessary LLMNR (authoritative name) errors, thereby also reducing unnecessary LLMNR
queries. queries.
If error responses are received from both DNS and LLMNR, then the As noted in [DNSPerf] significant fraction of DNS queries do not
lowest RCODE value should be returned. For example, if either DNS or receive a response, or result in negative responses due to missing
LLMNR receives a response with RCODE=0, then this should returned to inverse mappings or NS records that point to nonexistent or
the caller. inappropriate hosts. Therefore a reduction in missing records can
prevent many unnecessary LLMNR queries.
3.1. LLMNR Configuration 3.1. LLMNR Configuration
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 interface basis. By default, LLMNR responders SHOULD be enabled on
all interfaces, at all times. Enabling LLMNR for use in situations all interfaces, at all times. Where this is considered undesirable,
where a DNS server has been configured will result in a change in LLMNR SHOULD be disabled, so that hosts will neither listen on the
default behavior without a simultaneous update to configuration link-scope multicast address, nor will they send queries to that
information. Where this is considered undesirable, LLMNR SHOULD NOT address.
be enabled by default, so that hosts will neither listen on the link-
scope multicast address, nor will they send queries to that address.
Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
possible for a dual stack host to be configured with the address of a configure LLMNR on an interface. The LLMNR Enable Option, described
DNS server over IPv4, while remaining unconfigured with a DNS server in [LLMNREnable], can be used to explicitly enable or disable use of
suitable for use over IPv6. LLMNR on an interface. The LLMNR Enable Option does not determine
whether or in which order DNS itself is used for name resolution.
The order in which various name resolution mechanisms should be used
can be specified using the Name Service Search Option (NSSO) for DHCP
[RFC2937], using the LLMNR Enable Option code carried in the NSSO
data.
In situations where LLMNR is configured as a secondary name
resolution protocol on a dual-stack host, behavior will be governed
by both IPv4 and IPv6 configuration mechanisms. Since IPv4 and IPv6
utilize distinct configuration mechanisms, it is possible for a dual
stack host to be configured with the address of a DNS server over
IPv4, while remaining unconfigured with a DNS server suitable for use
over IPv6.
In these situations, a dual stack host will send AAAA queries to the In these situations, a dual stack host will send AAAA queries to the
configured DNS server over IPv4. However, an IPv6-only host configured DNS server over IPv4. However, an IPv6-only host
unconfigured with a DNS server suitable for use over IPv6 will be unconfigured with a DNS server suitable for use over IPv6 will be
unable to resolve names using DNS. Automatic IPv6 DNS configuration unable to resolve names using DNS. Automatic IPv6 DNS configuration
mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
deployed, and not all DNS servers support IPv6. Therefore lack of deployed, and not all DNS servers support IPv6. Therefore lack of
IPv6 DNS configuration may be a common problem in the short term, and IPv6 DNS configuration may be a common problem in the short term, and
LLMNR may prove useful in enabling link-local name resolution over LLMNR may prove useful in enabling link-local name resolution over
IPv6. IPv6.
skipping to change at page 17, line 34 skipping to change at page 17, line 45
LLMNR over IPv6 may be successful in resolving the name of an LLMNR over IPv6 may be successful in resolving the name of an
IPv6-only host on the local link. IPv6-only host on the local link.
Similarly, if a DHCPv4 server is available providing DNS server Similarly, if a DHCPv4 server is available providing DNS server
configuration, and DNS server(s) exist which are authoritative for configuration, and DNS server(s) exist which are authoritative for
the A RRs of local hosts and support either dynamic client update the A RRs of local hosts and support either dynamic client update
over IPv4 or DHCPv4-based dynamic update, then the names of local over IPv4 or DHCPv4-based dynamic update, then the names of local
IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
DNS server is authoritative for the names of local hosts, or the DNS server is authoritative for the names of local hosts, or the
authoritative DNS server(s) do not support dynamic update, then LLMNR authoritative DNS server(s) do not support dynamic update, then LLMNR
enables linklocal name resolution over IPv4. enables link-local name resolution over IPv4.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure LLMNR on an interface. The LLMNR Enable Option, described
in [LLMNREnable], can be used to explicitly enable or disable use of
LLMNR on an interface. The LLMNR Enable Option does not determine
whether or in which order DNS itself is used for name resolution.
The order in which various name resolution mechanisms should be used
can be specified using the Name Service Search Option (NSSO) for DHCP
[RFC2937], using the LLMNR Enable Option code carried in the NSSO
data.
It is possible that DNS configuration mechanisms will go in and out It is possible that DNS configuration mechanisms will go in and out
of service. In these circumstances, it is possible for hosts within of service. In these circumstances, it is possible for hosts within
an administrative domain to be inconsistent in their DNS an administrative domain to be inconsistent in their DNS
configuration. configuration.
For example, where DHCP is used for configuring DNS servers, one or For example, where DHCP is used for configuring DNS servers, one or
more DHCP servers can fail. As a result, hosts configured prior to more DHCP servers can fail. As a result, hosts configured prior to
the outage will be configured with a DNS server, while hosts the outage will be configured with a DNS server, while hosts
configured after the outage will not. Alternatively, it is possible configured after the outage will not. Alternatively, it is possible
for the DNS configuration mechanism to continue functioning while for the DNS configuration mechanism to continue functioning while
configured DNS servers fail. configured DNS servers fail.
An outage in the DNS configuration mechanism may result in hosts An outage in the DNS configuration mechanism may result in hosts
continuing to use LLMNR even once the outage is repaired. Since continuing to use LLMNR even once the outage is repaired. Since
LLMNR only enables linklocal name resolution, this represents a LLMNR only enables link-local name resolution, this represents a
degradation in capabilities. As a result, hosts without a configured degradation in capabilities. As a result, hosts without a configured
DNS server may wish to periodically attempt to obtain DNS DNS server may wish to periodically attempt to obtain DNS
configuration if permitted by the configuration mechanism in use. In configuration if permitted by the configuration mechanism in use. In
the absence of other guidance, a default retry interval of one (1) the absence of other guidance, a default retry interval of one (1)
minute is RECOMMENDED. minute is RECOMMENDED.
4. Conflict Resolution 4. Conflict Resolution
By default, a responder SHOULD be configured to behave as though its By default, a responder SHOULD be configured to behave as though its
name is UNIQUE on each interface on which LLMNR is enabled. However, name is UNIQUE on each interface on which LLMNR is enabled. However,
skipping to change at page 19, line 27 skipping to change at page 19, line 28
check if the source address matches the address of any of its check if the source address matches the address of any of its
interfaces; if so, then the response is not considered a conflict, interfaces; if so, then the response is not considered a conflict,
since it originates from the sender. To avoid triggering conflict since it originates from the sender. To avoid triggering conflict
detection, a responder that detects that it is connected to the same detection, a responder that detects that it is connected to the same
link on multiple interfaces SHOULD set the 'C' bit in responses. link on multiple interfaces SHOULD set the 'C' bit in responses.
If a response is received with the 'T' bit clear, the responder MUST If a response is received with the 'T' bit clear, the responder MUST
NOT use the name in response to LLMNR queries received over any NOT use the name in response to LLMNR queries received over any
protocol (IPv4 or IPv6). If a response is received with the 'T' bit protocol (IPv4 or IPv6). If a response is received with the 'T' bit
set, the responder MUST check if the source IP address in the set, the responder MUST check if the source IP address in the
response, interpreted as an unsigned integer, is less than the source response is lexicographically smaller than the source IP address in
IP address in the query. If so, the responder MUST NOT use the name the query. If so, the responder MUST NOT use the name in response to
in response to LLMNR queries received over any protocol (IPv4 or LLMNR queries received over any protocol (IPv4 or IPv6). For the
IPv6). For the purpose of uniqueness verification, the contents of purpose of uniqueness verification, the contents of the answer
the answer section in a response is irrelevant. section in a response is irrelevant.
Periodically carrying out uniqueness verification in an attempt to Periodically carrying out uniqueness verification in an attempt to
detect name conflicts is not necessary, wastes network bandwidth, and detect name conflicts is not necessary, wastes network bandwidth, and
may actually be detrimental. For example, if network links are may actually be detrimental. For example, if network links are
joined only briefly, and are separated again before any new joined only briefly, and are separated again before any new
communication is initiated, temporary conflicts are benign and no communication is initiated, temporary conflicts are benign and no
forced reconfiguration is required. LLMNR responders SHOULD NOT forced reconfiguration is required. LLMNR responders SHOULD NOT
periodically attempt uniqueness verification. periodically attempt uniqueness verification.
4.2. Conflict Detection and Defense 4.2. Conflict Detection and Defense
skipping to change at page 20, line 24 skipping to change at page 20, line 25
address matches the address of any of its interfaces; if so, then the address matches the address of any of its interfaces; if so, then the
response is not considered a conflict, since it originates from the response is not considered a conflict, since it originates from the
sender. To avoid triggering conflict detection, a responder that sender. To avoid triggering conflict detection, a responder that
detects that it is connected to the same link on multiple interfaces detects that it is connected to the same link on multiple interfaces
SHOULD set the 'C' bit in responses. SHOULD set the 'C' bit in responses.
An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
log them. Upon detecting a conflict, an LLMNR responder MUST log them. Upon detecting a conflict, an LLMNR responder MUST
immediately stop using the conflicting name in response to LLMNR immediately stop using the conflicting name in response to LLMNR
queries received over any supported protocol, if the source IP queries received over any supported protocol, if the source IP
address in the response, interpreted as an unsigned integer, is less address in the response, is lexicographically smaller than than the
than the source IP address in the uniqueness verification query. source IP address in the uniqueness verification query.
After stopping the use of a name, the responder MAY elect to After stopping the use of a name, the responder MAY elect to
configure a new name. However, since name reconfiguration may be configure a new name. However, since name reconfiguration may be
disruptive, this is not required, and a responder may have been disruptive, this is not required, and a responder may have been
configured to respond to multiple names so that alternative names may configured to respond to multiple names so that alternative names may
already be available. A host that has stopped the use of a name may already be available. A host that has stopped the use of a name may
attempt uniqueness verification again after the expiration of the TTL attempt uniqueness verification again after the expiration of the TTL
of the conflicting response. of the conflicting response.
4.3. Considerations for Multiple Interfaces 4.3. Considerations for Multiple Interfaces
skipping to change at page 20, line 49 skipping to change at page 20, line 50
However, should a host need to configure LLMNR on more than one of However, should a host need to configure LLMNR on more than one of
its active interfaces, there are some additional precautions it MUST its active interfaces, there are some additional precautions it MUST
take. Implementers who are not planning to support LLMNR on multiple take. Implementers who are not planning to support LLMNR on multiple
interfaces simultaneously may skip this section. interfaces simultaneously may skip this section.
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 maintains its own independent LLMNR interface, each interface maintains its own independent LLMNR
resolver cache, containing the responses to LLMNR queries. resolver cache, containing the responses to LLMNR queries.
A multi-homed host checks the uniqueness of UNIQUE records as A multi-homed host checks the uniqueness of UNIQUE records as
described in Section 4. The situation is illustrated in figure 1. described in Section 4. The situation is illustrated in Figure 1.
---------- ---------- ---------- ----------
| | | | | | | |
[A] [myhost] [myhost] [A] [myhost] [myhost]
Figure 1. Link-scope name conflict Figure 1. Link-scope name conflict
In this situation, the multi-homed myhost will probe for, and defend, In this situation, the multi-homed myhost will probe for, and defend,
its host name on both interfaces. A conflict will be detected on one its host name on both interfaces. A conflict will be detected on one
interface, but not the other. The multi-homed myhost will not be interface, but not the other. The multi-homed myhost will not be
able to respond with a host RR for "myhost" on the interface on the able to respond with a host RR for "myhost" on the interface on the
right (see Figure 1). The multi-homed host may, however, be right (see Figure 1). The multi-homed host may, however, be
configured to use the "myhost" name on the interface on the left. configured to use the "myhost" name on the interface on the left.
Since names are only unique per-link, hosts on different links could Since names are only unique per-link, hosts on different links could
be using the same name. If an LLMNR client sends requests over be using the same name. If an LLMNR client sends queries over
multiple interfaces, and receives replies from more than one, the multiple interfaces, and receives responses from more than one, the
result returned to the client is defined by the implementation. The result returned to the client is defined by the implementation. The
situation is illustrated in figure 2. situation is illustrated in Figure 2.
---------- ---------- ---------- ----------
| | | | | | | |
[A] [myhost] [A] [A] [myhost] [A]
Figure 2. Off-segment name conflict Figure 2. Off-segment name conflict
If host myhost is configured to use LLMNR on both interfaces, it will If host myhost is configured to use LLMNR on both interfaces, it will
send LLMNR queries on both interfaces. When host myhost sends a send LLMNR queries on both interfaces. When host myhost sends a
query for the host RR for name "A" it will receive a response from query for the host RR for name "A" it will receive a response from
skipping to change at page 22, line 15 skipping to change at page 22, line 15
4.4. API Issues 4.4. API Issues
[RFC2553] provides an API which can partially solve the name [RFC2553] provides an API which can partially solve the name
ambiguity problem for applications written to use this API, since the ambiguity problem for applications written to use this API, since the
sockaddr_in6 structure exposes the scope within which each scoped sockaddr_in6 structure exposes the scope within which each scoped
address exists, and this structure can be used for both IPv4 (using address exists, and this structure can be used for both IPv4 (using
v4-mapped IPv6 addresses) and IPv6 addresses. v4-mapped IPv6 addresses) and IPv6 addresses.
Following the example in Figure 2, an application on 'myhost' issues Following the example in Figure 2, an application on 'myhost' issues
the request getaddrinfo("A", ...) with ai_family=AF_INET6 and the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both ai_flags=AI_ALL|AI_V4MAPPED. LLMNR queries will be sent from both
interfaces and the resolver library will return a list containing interfaces and the resolver library will return a list containing
multiple addrinfo structures, each with an associated sockaddr_in6 multiple addrinfo structures, each with an associated sockaddr_in6
structure. This list will thus contain the IPv4 and IPv6 addresses structure. This list will thus contain the IPv4 and IPv6 addresses
of both hosts responding to the name 'A'. Link-local addresses will of both hosts responding to the name 'A'. Link-local addresses will
have a sin6_scope_id value that disambiguates which interface is used have a sin6_scope_id value that disambiguates which interface is used
to reach the address. Of course, to the application, Figures 2 and 3 to reach the address. Of course, to the application, Figures 2 and 3
are still indistinguishable, but this API allows the application to are still indistinguishable, but this API allows the application to
communicate successfully with any address in the list. communicate successfully with any address in the list.
5. Security Considerations 5. Security Considerations
LLMNR is a peer-to-peer name resolution protocol designed for use on LLMNR is a peer-to-peer name resolution protocol designed for use on
the local link. While LLMNR limits the vulnerability of responders the local link. While LLMNR limits the vulnerability of responders
to off-link senders, it is possible for an off-link responder to to off-link senders, it is possible for an off-link responder to
reach a sender. reach a sender.
In scenarios such as public "hotspots" attackers can be present on In scenarios such as public "hotspots" attackers can be present on
the same link. These threats are most serious in wireless networks the same link. These threats are most serious in wireless networks
such as 802.11, since attackers on a wired network will require such as IEEE 802.11, since attackers on a wired network will require
physical access to the network, while wireless attackers may mount physical access to the network, while wireless attackers may mount
attacks from a distance. Link-layer security such as [IEEE-802.11i] attacks from a distance. Link-layer security such as [IEEE-802.11i]
can be of assistance against these threats if it is available. can be of assistance against these threats if it is available.
This section details security measures available to mitigate threats This section details security measures available to mitigate threats
from on and off-link attackers. from on and off-link attackers.
5.1. Denial of Service 5.1. Denial of Service
Attackers may take advantage of LLMNR conflict detection by Attackers may take advantage of LLMNR conflict detection by
skipping to change at page 23, line 11 skipping to change at page 23, line 11
An attacker may spoof LLMNR queries from a victim's address in order An attacker may spoof LLMNR queries from a victim's address in order
to mount a denial of service attack. Responders setting the IPv6 Hop to mount a denial of service attack. Responders setting the IPv6 Hop
Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
response may be able to reach the victim across the Internet. response may be able to reach the victim across the Internet.
While LLMNR responders only respond to queries for which they are While LLMNR responders only respond to queries for which they are
authoritative and LLMNR does not provide wildcard query support, an authoritative and LLMNR does not provide wildcard query support, an
LLMNR response may be larger than the query, and an attacker can LLMNR response may be larger than the query, and an attacker can
generate multiple responses to a query for a name used by multiple generate multiple responses to a query for a name used by multiple
responders. A sender may protect itself against unsolicited responders. A sender may protect itself against unsolicited
responses by silently discarding them as rapidly as possible. responses by silently discarding them.
5.2. Spoofing 5.2. Spoofing
LLMNR is designed to prevent reception of queries sent by an off-link LLMNR is designed to prevent reception of queries sent by an off-link
attacker. LLMNR requires that responders receiving UDP queries check attacker. LLMNR requires that responders receiving UDP queries check
that they are sent to a link-scope multicast address. However, it is that they are sent to a link-scope multicast address. However, it is
possible that some routers may not properly implement link-scope possible that some routers may not properly implement link-scope
multicast, or that link-scope multicast addresses may leak into the multicast, or that link-scope multicast addresses may leak into the
multicast routing system. To prevent successful setup of TCP multicast routing system. To prevent successful setup of TCP
connections by an off-link sender, responders receiving a TCP SYN connections by an off-link sender, responders receiving a TCP SYN
skipping to change at page 23, line 33 skipping to change at page 23, line 33
While it is difficult for an off-link attacker to send an LLMNR query While it is difficult for an off-link attacker to send an LLMNR query
to a responder, it is possible for an off-link attacker to spoof a to a responder, it is possible for an off-link attacker to spoof a
response to a query (such as an A or AAAA query for a popular response to a query (such as an A or AAAA query for a popular
Internet host), and by using a TTL or Hop Limit field larger than one Internet host), and by using a TTL or Hop Limit field larger than one
(1), for the forged response to reach the LLMNR sender. Since the (1), for the forged response to reach the LLMNR sender. Since the
forged response will only be accepted if it contains a matching ID forged response will only be accepted if it contains a matching ID
field, choosing a pseudo-random ID field within queries provides some field, choosing a pseudo-random ID field within queries provides some
protection against off-link responders. protection against off-link responders.
Since LLMNR queries can be sent when DNS server(s) do not respond, an When LLMNR is utilized as a secondary name resolution service,
attacker can execute a denial of service attack on the DNS server(s) queries can be sent when DNS server(s) do not respond. An attacker
and then poison the LLMNR cache by responding to an LLMNR query with can execute a denial of service attack on the DNS server(s) and then
incorrect information. As noted in "Threat Analysis of the Domain poison the LLMNR cache by responding to an LLMNR query with incorrect
Name System (DNS)" [RFC3833] these threats also exist with DNS, since information. As noted in "Threat Analysis of the Domain Name System
DNS response spoofing tools are available that can allow an attacker (DNS)" [RFC3833] these threats also exist with DNS, since DNS
to respond to a query more quickly than a distant DNS server. response spoofing tools are available that can allow an attacker to
However, while switched networks or link layer security may make it respond to a query more quickly than a distant DNS server. However,
difficult for an on-link attacker to snoop unicast DNS queries, while switched networks or link-layer security may make it difficult
multicast LLMNR queries are propagated to all hosts on the link, for an on-link attacker to snoop unicast DNS queries, multicast
making it possible for an on-link attacker to spoof LLMNR responses LLMNR queries are propagated to all hosts on the link, making it
without having to guess the value of the ID field in the query. possible for an on-link attacker to spoof LLMNR responses without
having to guess the value of the ID field in the query.
Since LLMNR queries are sent and responded to on the local-link, an Since LLMNR queries are sent and responded to on the local link, an
attacker will need to respond more quickly to provide its own attacker will need to respond more quickly to provide its own
response prior to arrival of the response from a legitimate response prior to arrival of the response from a legitimate
responder. If an LLMNR query is sent for an off-link host, spoofing responder. If an LLMNR query is sent for an off-link host, spoofing
a response in a timely way is not difficult, since a legitimate a response in a timely way is not difficult, since a legitimate
response will never be received. response will never be received.
This vulnerability can be reduced by limiting use of LLMNR to This vulnerability can be reduced by limiting use of LLMNR to
resolution of single-label names as described in Section 3, or by resolution of single-label names as described in Section 3, or by
implementation of authentication (see Section 5.3). implementation of authentication (see Section 5.3).
skipping to change at page 24, line 24 skipping to change at page 24, line 25
the following security mechanisms may be used: the following security mechanisms may be used:
[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) [a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
[RFC2931] security mechanisms. "DNS Name Service based on Secure [RFC2931] security mechanisms. "DNS Name Service based on Secure
Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
the use of TSIG to secure LLMNR, based on group keys. While group the use of TSIG to secure LLMNR, based on group keys. While group
keys can be used to demonstrate membership in a group, they do not keys can be used to demonstrate membership in a group, they do not
protect against forgery by an attacker that is a member of the protect against forgery by an attacker that is a member of the
group. group.
[b] IPsec ESP with a null-transform MAY be used to authenticate unicast [b] IPsec ESP with null encryption algorithm MAY be used to
LLMNR queries and responses or LLMNR responses to multicast authenticate unicast LLMNR queries and responses or LLMNR responses
queries. In a small network without a certificate authority, this to multicast queries. In a small network without a certificate
can be most easily accomplished through configuration of a group authority, this can be most easily accomplished through
pre-shared key for trusted hosts. As with TSIG, this does not configuration of a group pre-shared key for trusted hosts. As with
protect against forgery by an attacker with access to the group TSIG, this does not protect against forgery by an attacker with
pre-shared key. access to the group pre-shared key.
[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to [c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
support DNSSEC, LLMNR implementations MAY be configured with trust support DNSSEC, LLMNR implementations MAY be configured with trust
anchors, or they MAY make use of keys obtained from DNS queries. anchors, or they MAY make use of keys obtained from DNS queries.
Since LLMNR does not support "delegated trust" (CD or AD bits), Since LLMNR does not support "delegated trust" (CD or AD bits),
LLMNR implementations cannot make use of DNSSEC unless they are LLMNR implementations cannot make use of DNSSEC unless they are
DNSSEC-aware and support validation. Unlike approaches [a] or [b], DNSSEC-aware and support validation. Unlike approaches [a] or [b],
DNSSEC permits a responder to demonstrate ownership of a name, not DNSSEC permits a responder to demonstrate ownership of a name, not
just membership within a trusted group. As a result, it enables just membership within a trusted group. As a result, it enables
protection against forgery. protection against forgery.
5.4. Cache and Port Separation 5.4. Cache and Port Separation
In order to prevent responses to LLMNR queries from polluting the DNS In order to prevent responses to LLMNR queries from polluting the DNS
cache, LLMNR implementations MUST use a distinct, isolated cache for cache, LLMNR implementations MUST use a distinct, isolated cache for
LLMNR on each interface. The use of separate caches is most LLMNR on each interface. LLMNR operates on a separate port from DNS,
effective when LLMNR is used as a name resolution mechanism of last reducing the likelihood that a DNS server will unintentionally
resort, since this minimizes the opportunities for poisoning the respond to an LLMNR query.
LLMNR cache, and decreases reliance on it.
LLMNR operates on a separate port from DNS, reducing the likelihood
that a DNS server will unintentionally respond to an LLMNR query.
If LLMNR is given higher priority than DNS among the enabled name If a DNS server is running on a host that supports LLMNR, the LLMNR
resolution mechanisms, a denial of service attack on the DNS server responder on that host MUST respond to LLMNR queries only for the
would not be necessary in order to poison the LLMNR cache, since RRSets relating to the host on which the server is running, but MUST
LLMNR queries would be sent even when the DNS server is available. NOT respond for other records for which the DNS server is
In addition, the LLMNR cache, once poisoned, would take precedence authoritative. DNS servers MUST NOT send LLMNR queries in order to
over the DNS cache, eliminating the benefits of cache separation. As resolve DNS queries.
a result, LLMNR SHOULD NOT be used as a primary name resolution
mechanism.
6. IANA Considerations 6. IANA Considerations
LLMNR requires allocation of port 5355 for both TCP and UDP. This specification creates a new name space: the LLMNR namespace.
LLMNR requires allocation of link-scope multicast IPv4 address
224.0.0.252, as well as link-scope multicast IPv6 address
FF02:0:0:0:0:0:1:3.
This specification creates two new name spaces: the LLMNR namespace
and the reserved bits in the LLMNR header. The reserved bits in the
LLMNR header are allocated by IETF Consensus, in accordance with BCP
26 [RFC2434].
In order to to avoid creating any new administrative procedures, In order to to avoid creating any new administrative procedures,
administration of the LLMNR namespace will piggyback on the administration of the LLMNR namespace will piggyback on the
administration of the DNS namespace. administration of the DNS namespace.
The rights to use a fully qualified domain name (FQDN) within LLMNR The rights to use a fully qualified domain name (FQDN) within LLMNR
are obtained coincident with acquiring the rights to use that name are obtained by acquiring the rights to use that name within DNS.
within DNS. Those wishing to use a FQDN within LLMNR should first Those wishing to use a FQDN within LLMNR should first acquire the
acquire the rights to use the corresponding FQDN within DNS. Using a rights to use the corresponding FQDN within DNS. Using a FQDN within
FQDN within LLMNR without ownership of the corresponding name in DNS LLMNR without ownership of the corresponding name in DNS creates the
creates the possibility of conflict and therefore is discouraged. possibility of conflict and therefore is discouraged.
LLMNR responders may self-allocate a name within the single-label LLMNR responders may self-allocate a name within the single-label
name space, first defined in [RFC1001]. Since single-label names are name space, first defined in [RFC1001]. Since single-label names are
not unique, no registration process is required. not unique, no registration process is required.
7. Constants 7. Constants
The following timing constants are used in this protocol; they are The following timing constants are used in this protocol; they are
not intended to be user configurable. not intended to be user configurable.
skipping to change at page 28, line 23 skipping to change at page 28, line 16
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 Manning and Bill Woodcock. Bill Manning's work was funded under
DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
their contribution to the current specification. Constructive input their contribution to the current specification. Constructive input
has also been received from Mark Andrews, Rob Austein, Randy Bush, has also been received from Mark Andrews, Rob Austein, Randy Bush,
Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
St. Johns, Sander Van-Valkenburg, and Brian Zill. St. Johns, Sander van Valkenburg, and Brian Zill.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 706 6605 Phone: +1 425 706 6605
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
skipping to change at page 30, line 4 skipping to change at line 1357
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Open Issues
Open issues with this specification are tracked on the following web
site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
 End of changes. 38 change blocks. 
138 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/