draft-ietf-dnsext-mdns-14.txt   draft-ietf-dnsext-mdns-15.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-14.txt> Microsoft <draft-ietf-dnsext-mdns-15.txt> Microsoft
22 March 2003 2 April 2003
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 13 skipping to change at page 2, line 13
DNS, and with a distinct resolver cache. DNS, and with a distinct resolver cache.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 4 1.1 Requirements .................................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Name resolution using LLMNR ........................... 4 2. Name resolution using LLMNR ........................... 4
2.1 Sender behavior ................................. 5 2.1 Sender behavior ................................. 5
2.2 Responder behavior .............................. 5 2.2 Responder behavior .............................. 5
2.3 Unicast queries ................................. 7 2.3 Unicast queries ................................. 6
2.4 Addressing ...................................... 7 2.4 Addressing ...................................... 7
2.5 TTL ............................................. 7 2.5 Off-link detection .............................. 7
2.6 Retransmissions ................................. 8 2.6 Retransmissions ................................. 8
2.7 DNS TTL ......................................... 8 2.7 DNS TTL ......................................... 8
3. Usage model ........................................... 8 3. Usage model ........................................... 8
3.1 Unqualified names ............................... 9 3.1 Unqualified names ............................... 9
3.2 LLMNR configuration ............................. 9 3.2 LLMNR configuration ............................. 10
4. Conflict resolution ................................... 11 4. Conflict resolution ................................... 11
4.1 Considerations for multiple interfaces .......... 13 4.1 Considerations for multiple interfaces .......... 13
4.2 API issues ...................................... 14 4.2 API issues ...................................... 14
5. Security considerations ............................... 14 5. Security considerations ............................... 15
5.1 Scope restriction ............................... 15 5.1 Scope restriction ............................... 15
5.2 Usage restriction ............................... 15 5.2 Usage restriction ............................... 16
5.3 Cache and port separation ....................... 16 5.3 Cache and port separation ....................... 16
5.4 Authentication .................................. 16 5.4 Authentication .................................. 17
6. IANA considerations ................................... 17 6. IANA considerations ................................... 17
7. Normative References .................................. 17 7. Normative References .................................. 17
8. Informative References ................................ 17 8. Informative References ................................ 18
Acknowledgments .............................................. 18 Acknowledgments .............................................. 19
Authors' Addresses ........................................... 19 Authors' Addresses ........................................... 19
Intellectual Property Statement .............................. 19 Intellectual Property Statement .............................. 19
Full Copyright Statement ..................................... 20 Full Copyright Statement ..................................... 20
1. Introduction 1. Introduction
This document discusses Link-Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which operates on a separate port from DNS, with a distinct resolver which operates on a separate port from DNS, with a distinct resolver
cache, but does not change the format of DNS packets. LLMNR supports all cache, but does not change the format of DNS packets. LLMNR supports all
current and future DNS formats, types and classes. However, since LLMNR current and future DNS formats, types and classes. However, since LLMNR
only operates on the local link, it cannot be considered a substitute only operates on the local link, it cannot be considered a substitute
for DNS. for DNS.
The goal of LLMNR is to enable name resolution in scenarios in which The goal of LLMNR is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible. These include conventional DNS name resolution is not possible. These include
scenarios in which hosts are not configured with the address of a DNS scenarios in which hosts are not configured with the address of a DNS
server, where configured DNS servers do not reply to a query, or where server, where configured DNS servers do not reply to a query, or where
they respond with errors, as described in Section 3. they respond with errors, as described in Section 3.
LLMNR queries are sent to and received on port TBD using a LINKLOCAL LLMNR queries are sent to and received on port TBD using a link-scope
address as specified in "Administratively Scoped IP Multicast" [RFC2365] multicast address as specified in "Administratively Scoped IP Multicast"
for IPv4. The LLMNR LINKLOCAL address to be used for IPv4 is [RFC2365] for IPv4. The LLMNR link-scope multicast address to be used
224.0.0.251. For IPv6, the "solicited name" LINKLOCAL multicast for IPv4 is 224.0.0.251. For IPv6, the "solicited name" link-scope
addresses are used for A/AAAA queries, and a separate multicast address multicast addresses are used for A/AAAA queries, and a separate link-
TBD for all other queries. LINKLOCAL multicast addresses are used to scope multicast address TBD for all other queries. Link-scope multicast
prevent propagation of LLMNR traffic across routers, potentially addresses are used to prevent propagation of LLMNR traffic across
flooding the network; for details, see Section 2.4. In circumstances routers, potentially flooding the network; for details, see Section 2.4.
described in Section 2.3, LLMNR queries can also be sent to a unicast In circumstances described in Section 2.3, LLMNR queries can also be
address. sent to a unicast address.
Propagation of LLMNR packets on the local link is considered sufficient Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks. The assumption is that if a to enable name resolution in small networks. The assumption is that if a
network has a home gateway, then the network either has a DNS server or network has a home gateway, then the network either has a DNS server or
the home gateway can function as a DNS proxy. By implementing DHCPv4 as the home gateway can function as a DNS proxy. By implementing DHCPv4 as
well as a DNS proxy and dynamic DNS, home gateways can provide name well as a DNS proxy and dynamic DNS, home gateways can provide name
resolution for the names of hosts over IPv4 on the local network. resolution for the names of hosts over IPv4 on the local network.
For small IPv6 networks, equivalent functionality can be provided by a For small IPv6 networks, equivalent functionality can be provided by a
home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name
resolution for the names of hosts over IPv6 on the local network. resolution for the names of hosts over IPv6 on the local network.
This should be adequate as long as home gateways implementing DNS This should be adequate as long as home gateways implementing DNS
configuration also support dynamic DNS in some form. configuration also support dynamic DNS in some form.
In the future, LLMNR may be defined to support greater than LINKLOCAL In the future, LLMNR may be defined to support greater than link-scope
multicast scope. This would occur if LLMNR deployment is successful, multicast. This would occur if LLMNR deployment is successful, the
the assumption that LLMNR is not needed on multiple links proves assumption that LLMNR is not needed on multiple links proves incorrect,
incorrect, and multicast routing becomes ubiquitous. For example, it is and multicast routing becomes ubiquitous. For example, it is not clear
not clear that this assumption will be valid in large adhoc networking that this assumption will be valid in large adhoc networking scenarios.
scenarios.
Once we have experience in LLMNR deployment in terms of administrative Once we have experience in LLMNR deployment in terms of administrative
issues, usability and impact on the network it will be possible issues, usability and impact on the network it will be possible
reevaluate which multicast scopes are appropriate for use with multicast reevaluate which multicast scopes are appropriate for use with multicast
name resolution mechanisms. name resolution mechanisms.
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 name LLMNR in particular is outside of the scope of this document, as is name
resolution over non-multicast capable media. resolution over non-multicast capable media.
skipping to change at page 4, line 42 skipping to change at page 4, line 42
Routable address Routable address
An address other than a linklocal address. This includes An address other than a linklocal address. This includes
site local and globally routable addresses, as well as site local and globally routable addresses, as well as
private addresses. private addresses.
2. Name resolution using LLMNR 2. Name resolution using LLMNR
The sequence of events for LLMNR usage is as follows: The sequence of events for LLMNR usage is as follows:
[1] If a sender needs to resolve a query for a name "host.example.com", [1] If a sender needs to resolve a query for a name "host.example.com",
then it sends a LLMNR query to the LINKLOCAL multicast address. then it sends an LLMNR query to the link-scope multicast address.
[2] A responder responds to this query only if it is authoritative [2] A responder responds to this query only if it is authoritative
for the domain name "host.example.com". The responder sends for the domain name "host.example.com". The responder sends
a response to the sender via unicast over UDP. a response to the sender via unicast over UDP.
[3] Upon the reception of the response, the sender verifies that the Hop [3] Upon the reception of the response, the sender verifies that the
Limit field in IPv6 header or TTL field in IPv4 header (depending on packet originated on-link (see Section 2.5 for details). If these
the protocol used) of the response is set to 255. The sender then
verifies compliance with the addressing requirements for IPv4,
described in [IPV4Link], and IPv6, described in [RFC2373]. If these
conditions are met, then the sender uses and caches the returned conditions are met, then the sender uses and caches the returned
response. If not, then the sender ignores the response and continues response. If not, then the sender ignores the response and continues
waiting for the response. waiting for the response.
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. Sender behavior
A sender sends an LLMNR query for any legal Type of resource record A sender sends an LLMNR query for any legal Type of resource record
(e.g. A, PTR, etc.) to the LINKLOCAL multicast address. An LLMNR sender (e.g. A, PTR, etc.) to the link-scope multicast address. An LLMNR
MAY send requests for any name. sender MAY send requests for any name.
Under conditions described in Section 2.3, a sender may also send a Under conditions described in Section 2.3, a sender may also send a
unicast query. The RD (Recursion Desired) bit MUST NOT be set. If a unicast query. The RD (Recursion Desired) bit MUST NOT be set. If a
responder receives a query with the header containing RD set bit, the responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit. responder MUST ignore the RD bit.
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 linklocal in the event that no responders are available within the linklocal
multicast scope, or in the event that no positive non-null responses multicast scope, or in the event that no positive non-null responses
exist for the transmitted query. If no positive response is received, a exist for the transmitted query. If no positive response is received, a
resolver treats it as a response that no records of the specified type resolver treats it as a response that no records of the specified type
and class for the specified name exist (that is, it is treated the same and class for the specified name exist (that is, it is treated the same
as a response with RCODE=0 and an empty answer section). as a response with RCODE=0 and an empty answer section).
2.2. Responder behavior 2.2. Responder behavior
A responder listens on port TBD on the LINKLOCAL multicast address(es) A responder listens on port TBD on the link-scope multicast address(es)
and on the unicast address(es) that could be set as the source and on the unicast address(es) that could be set as the source
address(es) when the responder responds to the LLMNR query. The host address(es) when the responder responds to the LLMNR query. The host
configured as a responder MUST act as a sender to verify the uniqueness configured as a responder MUST act as a sender to verify the uniqueness
of names as described in Section 4. of names as described in Section 4.
Responders MUST NOT respond to LLMNR queries for names they are not Responders MUST NOT respond to LLMNR queries for names they are not
authoritative for. Responders SHOULD respond to LLMNR queries for names authoritative for. Responders SHOULD respond to LLMNR queries for names
and addresses they are authoritative for. This applies to both forward and addresses they are authoritative for. This applies to both forward
and reverse lookups. and reverse lookups.
skipping to change at page 7, line 25 skipping to change at page 7, line 17
If a TC (truncation) bit is set in the response, then the sender MAY use If a TC (truncation) bit is set in the response, then the sender MAY use
the response if it contains all necessary information, or the sender MAY the response if it contains all necessary information, or the sender MAY
discard the response and resend the query over TCP or using EDNS0 with discard the response and resend the query over TCP or using EDNS0 with
larger window using the unicast address of the responder. The RA larger window using the unicast address of the responder. The RA
(Recursion Available) bit in the header of the response MUST NOT be set. (Recursion Available) bit in the header of the response MUST NOT be set.
If the RA bit is set in the response header, the sender MUST ignore it. If the RA bit is set in the response header, the sender MUST ignore it.
2.4. Addressing 2.4. Addressing
The IPv4 LINKLOCAL multicast address a given responder listens to, and The IPv4 link-scope multicast address a given responder listens to, and
to which a sender sends all queries, is 224.0.0.251. The IPv6 LINKLOCAL to which a sender sends all queries, is 224.0.0.251. The IPv6 link-
multicast address a given responder listens to, and to which a sender scope multicast address a given responder listens to, and to which a
sends A/AAAA queries, is formed as follows: The name of the resource sender sends A/AAAA queries, is formed as follows: The name of the
record in question is expressed in its canonical form (see [RFC2535], resource record in question is expressed in its canonical form (see
section 8.1), which is uncompressed with all alphabetic characters in [RFC2535], section 8.1), which is uncompressed with all alphabetic
lower case. characters in lower case.
The first label of the FQDN in the query is then hashed using the MD5 The first label of the FQDN in the query is then hashed using the MD5
algorithm, described in [RFC1321]. The first 32 bits of the resultant algorithm, described in [RFC1321]. The first 32 bits of the resultant
128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield 128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield
the 128-bit "solicited name multicast address". (Note: this procedure the 128-bit "solicited name multicast address". (Note: this procedure
is intended to be the same as that specified in section 3 of "IPv6 Node is intended to be the same as that specified in section 3 of "IPv6 Node
Information Queries" [NodeInfo]). A responder that listens for queries Information Queries" [NodeInfo]). A responder that listens for queries
for multiple names with different first labels will necessarily listen for multiple names with different first labels will necessarily listen
to multiple of these solicited name multicast addresses. to multiple of these solicited name multicast addresses.
For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of 2.5. Off-link detection
IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to
source address selection, TTL settings, and acceptable
source/destination address combinations. IPv6 is described in [RFC2460];
IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries and
responses MUST obey the rules laid out in these documents.
2.5. TTL The source address of LLMNR queries and responses MUST be "on link". The
destination address of an LLMNR query MUST be a link-scope multicast
address or an "on link" unicast address; the destination address of an
LLMNR response MUST be an "on link" unicast address. For IPv4, an "on
link" address is defined as a link-local address or an address whose
prefix belongs to a subnet on the local link; for IPv6 [RFC2460] an "on
link" address is either a link-local address, defined in [RFC2373], or
an address whose prefix belongs to a subnet on the local link. A sender
SHOULD prefer RRs including reachable addresses where RRs involving both
reachable and unreachable addresses are returned in response to a query.
In composing an LLMNR response, the responder MUST set the Hop Limit In composing an LLMNR response, the responder MUST set the Hop Limit
field in the IPv6 header and the TTL field in IPv4 header of the LLMNR field in the IPv6 header and the TTL field in IPv4 header of the LLMNR
response to 255. The sender MUST verify that the Hop Limit field in IPv6 response to 255. The sender MUST verify that the Hop Limit field in IPv6
header and TTL field in IPv4 header of each response to the LLMNR query header and TTL field in IPv4 header of each response to the LLMNR query
is set to 255. If it is not, then sender MUST ignore the response. is set to 255. If it is not, then sender MUST ignore the response.
Since routers decrement the Hop Limit on all packets they forward,
received packets containing a Hop Limit of 255 must have originated from
a neighbor.
Implementation note: Implementation note:
In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
options are used to set the TTL of outgoing unicast and multicast options are used to set the TTL of outgoing unicast and multicast
packets. The IP_RECVTTL socket option is available on some platforms packets. The IP_RECVTTL socket option is available on some platforms
to retrieve the IPv4 TTL of received packets with recvmsg(). to retrieve the IPv4 TTL of received packets with recvmsg().
[RFC2292] specifies similar options for setting and retrieving the [RFC2292] specifies similar options for setting and retrieving the
IPv6 Hop Limit. IPv6 Hop Limit.
2.6. Retransmissions 2.6. Retransmissions
skipping to change at page 8, line 34 skipping to change at page 8, line 34
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in
order to assure themselves that the query has been received by a host order to assure themselves that the query has been received by a host
capable of responding to the query. Since a sender cannot know capable of responding to the query. Since a sender cannot know
beforehand whether it will receive no response, one response, or more beforehand whether it will receive no response, one response, or more
than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order
to collect all possible responses, rather than considering the query to collect all possible responses, rather than considering the query
answered after the first response is received. answered after the first response is received.
LLMNR implementations SHOULD dynamically estimate the timeout value LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described (LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described
in [RFC2988], with a minimum timeout value of 300 ms. in [RFC2988], with a minimum timeout value of 300 ms. Repetition SHOULD
NOT be attempted more than 3 times.
Repetition SHOULD NOT be attempted more than 3 times and SHOULD NOT be
repeated more often than once per second to reduce unnecessary network
traffic.
2.7. DNS TTL 2.7. DNS TTL
The responder should use a pre-configured TTL value in the records The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. Due to the TTL minimalization returned in the LLMNR query response. Due to the TTL minimalization
necessary when caching an RRset, all TTLs in an RRset MUST be set to the necessary when caching an RRset, all TTLs in an RRset MUST be set to the
same value. In the additional and authority section of the response the same value. In the additional and authority section of the response the
responder includes the same records as a DNS server would insert in the responder includes the same records as a DNS server would insert in the
response to the unicast DNS query. response to the unicast DNS query.
skipping to change at page 9, line 18 skipping to change at page 9, line 14
As noted in [DNSPerf], even when DNS servers are configured, a As noted in [DNSPerf], even when DNS servers are configured, a
significant fraction of DNS queries do not receive a response, or result significant fraction of DNS queries do not receive a response, or result
in a negative responses due to missing inverse mappings or NS records in a negative responses due to missing inverse mappings or NS records
that point to nonexistent or inappropriate hosts. Given this, support that point to nonexistent or inappropriate hosts. Given this, support
for LLMNR as a secondary name resolution mechanism has the potential to for LLMNR as a secondary name resolution mechanism has the potential to
result in a large number of inappropriate queries without the following result in a large number of inappropriate queries without the following
additional restrictions: additional restrictions:
[1] If a DNS query does not receive a response, prior to falling [1] If a DNS query does not receive a response, prior to falling
back to LLMNR, a DNS query SHOULD be retransmitted at least back to LLMNR, the query SHOULD be retransmitted at least
once. once.
[2] A sender SHOULD send LLMNR queries only for names that are [2] A sender SHOULD send LLMNR queries only for names that are
either unqualified or exist within the default domain. either unqualified or exist within the default domain.
[3] A responder with both linklocal and routable addresses [3] A responder with both link-local and routable addresses
MUST respond to LLMNR queries for A/AAAA RRs only with MUST respond to LLMNR queries for A/AAAA RRs only with
routable address(es). This encourages use of routable routable address(es). This encourages use of routable
address(es) for establishment of new connections. address(es) for establishment of new connections.
RRs returned in LLMNR responses MUST only include values that are valid
on the local interface, such as IPv4 or IPv6 addresses valid on the
local link or names defended using the mechanism described in Section 4.
In particular:
[1] If a link-scope IPv6 address is returned in a AAAA RR, that
address MUST be valid on the local link over which LLMNR is
used.
[2] If an IPv4 address is returned, it must be reachable through
the link over which LLMNR is used.
[3] If a name is returned (for example in a CNAME, MX
or SRV RR), the name MUST be valid on the local interface.
3.1. Unqualified names 3.1. Unqualified names
The same host MAY use LLMNR queries for the resolution of unqualified The same host MAY use LLMNR queries for the resolution of unqualified
host names, and conventional DNS queries for resolution of other DNS host names, and conventional DNS queries for resolution of other DNS
names. names.
If a name is not qualified and does not end in a trailing dot, for the If a name is not qualified and does not end in a trailing dot, for the
purposes of LLMNR, the implicit search order is as follows: purposes of LLMNR, the implicit search order is as follows:
[1] Request the name with the current domain appended. [1] Request the name with the current domain appended.
skipping to change at page 10, line 4 skipping to change at page 10, line 16
3.2. LLMNR configuration 3.2. 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 all interface basis. By default, LLMNR responders SHOULD be enabled on all
interfaces, at all times. interfaces, at all times.
Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
possible for a dual stack host to be configured with the address of a 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 DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use over IPv6. In these situations, a dual stack host will suitable for use over IPv6. In these situations, a dual stack host will
send AAAA queries to the configured DNS server over IPv4. send AAAA queries to the configured DNS server over IPv4.
However, an IPv6-only host unconfigured with a DNS server suitable for However, an IPv6-only host unconfigured with a DNS server suitable for
use over IPv6 will be unable to resolve names using DNS. Since use over IPv6 will be unable to resolve names using DNS. Since
automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] and automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and
[DNSDisc] are not yet widely deployed, and not all DNS servers support [DNSDisc]) are not yet widely deployed, and not all DNS servers support
IPv6, lack of IPv6 DNS configuration may be a common problem in the IPv6, lack of IPv6 DNS configuration may be a common problem in the
short term, and LLMNR may prove useful in enabling linklocal name short term, and LLMNR may prove useful in enabling linklocal name
resolution over IPv6. resolution over IPv6.
For example, a home gateway may implement a DNS proxy and DHCPv4, but For example, a home gateway may implement a DNS proxy and DHCPv4, but
not DHCPv6 for DNS configuration [DHCPv6DNS] or [DNSDisc]. In such a not DHCPv6 for DNS configuration [DHCPv6DNS]. In such a circumstance,
circumstance, IPv6-only hosts will not be configured with a DNS server. IPv6-only hosts will not be configured with a DNS server. Where the DNS
Where the DNS proxy does not support dynamic client update over IPv6 or proxy does not support dynamic client update over IPv6 or DHCPv6-based
DHCPv6-based dynamic update of the DNS proxy, the home gateway will not dynamic update of the DNS proxy, the home gateway will not be able to
be able to dynamically register the names of IPv6 hosts. As a result, dynamically register the names of IPv6 hosts. As a result, the DNS
the DNS proxy will respond to AAAA RR queries sent over IPv4 or IPv6 proxy will respond to AAAA RR queries sent over IPv4 or IPv6 with an
with an authoritative name error (RCODE=3). This prevents hosts from authoritative name error (RCODE=3). This prevents hosts from resolving
resolving the names of IPv6-only hosts on the local link. In this the names of IPv6-only hosts on the local link. In this situation,
situation, LLMNR over IPv6 can be used for resolution of dynamic names. LLMNR over IPv6 can be used for resolution of dynamic names.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure LLMNR on an interface. The LLMNR Enable Option, described in configure LLMNR on an interface. The LLMNR Enable Option, described in
[LLMNREnable], can be used to explicitly enable or disable use of LLMNR [LLMNREnable], can be used to explicitly enable or disable use of LLMNR
on an interface. The LLMNR Enable Option does not determine whether or 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 in which order DNS itself is used for name resolution. The order in
which various name resolution mechanisms should be used can be specified which various name resolution mechanisms should be used can be specified
using the Name Service Search Option for DHCP [RFC2937]. using the Name Service Search Option for DHCP [RFC2937].
3.2.1. Configuration consistency 3.2.1. Configuration consistency
skipping to change at page 13, line 23 skipping to change at page 13, line 35
Implementers who are not planning to support LLMNR on multiple Implementers who are not planning to support LLMNR on multiple
interfaces simultaneously may skip this section. interfaces simultaneously may skip this section.
A multi-homed host checks the uniqueness of UNIQUE records as described A multi-homed host checks the uniqueness of UNIQUE records as described
in Section 4. The situation is illustrated in figure 1. in Section 4. The situation is illustrated in figure 1.
---------- ---------- ---------- ----------
| | | | | | | |
[A] [myhost] [myhost] [A] [myhost] [myhost]
Figure 1. LINKLOCAL 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 able to 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 right (see respond with a host RR for "myhost" on the interface on the right (see
Figure 1). The multi-homed host may, however, be configured to use the Figure 1). The multi-homed host may, however, be configured to use the
"myhost" name on the interface on the left. "myhost" name on the interface on the left.
Since names are only unique per-link, hosts on different links could be Since names are only unique per-link, hosts on different links could be
using the same name. If an LLMNR client sends requests over multiple using the same name. If an LLMNR client sends requests over multiple
skipping to change at page 15, line 27 skipping to change at page 15, line 43
5.1. Scope restriction 5.1. Scope restriction
With LLMNR it is possible that hosts will allocate conflicting names for With LLMNR it is possible that hosts will allocate conflicting names for
a period of time, or that attackers will attempt to deny service to a period of time, or that attackers will attempt to deny service to
other hosts by allocating the same name. Such attacks also allow hosts other hosts by allocating the same name. Such attacks also allow hosts
to receive packets destined for other hosts. to receive packets destined for other hosts.
In the absence of authentication, LLMNR reduces the exposure to such In the absence of authentication, LLMNR reduces the exposure to such
threats by ignoring LLMNR query response packets received from off-link threats by ignoring LLMNR query response packets received from off-link
senders. In all received responses, the Hop Limit field in IPv6 and the senders. While restricting ignoring packets received from off-link
TTL field in IPv4 are verified to contain 255, the maximum legal value. senders reduces the level of vulnerability, it does not eliminate it.
Since routers decrement the Hop Limit on all packets they forward, There are scenarios such as public "hotspots" where attackers can be
received packets containing a Hop Limit of 255 must have originated from present on the same link. These threats are most serious in wireless
a neighbor. networks such as 802.11, since attackers on a wired network will require
physical access to the home network, while wireless attackers may reside
While restricting ignoring packets received from off-link senders outside the home. Link-layer security can be of assistance against
reduces the level of vulnerability, it does not eliminate it. There are these threats if it is available.
scenarios such as public "hotspots" where attackers can be present on
the same link. These threats are most serious in wireless networks such
as 802.11, since attackers on a wired network will require physical
access to the home network, while wireless attackers may reside outside
the home. Link-layer security can be of assistance against these
threats if it is available.
5.2. Usage restriction 5.2. Usage restriction
As noted in Section 3, LLMNR is intended for usage in a limited set of As noted in Section 3, LLMNR is intended for usage in a limited set of
scenarios. scenarios.
If an interface has been configured via any automatic configuration If an interface has been configured via any automatic configuration
mechanism which is able to supply DNS configuration information, then mechanism which is able to supply DNS configuration information, then
LLMNR SHOULD NOT be used as the primary name resolution mechanism on LLMNR SHOULD NOT be used as the primary name resolution mechanism on
that interface, although it MAY be used as a secondary mechanism. that interface, although it MAY be used as a secondary mechanism.
skipping to change at page 16, line 43 skipping to change at page 17, line 8
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
the this minimizes the opportunities for poisoning the LLMNR cache, and the 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 does not require use of DNSSEC, and as a result, responses to
LLMNR queries MAY NOT be authenticated. If authentication is desired, LLMNR queries may be unauthenticated. If authentication is desired, and
and a pre-arranged security configuration is possible, then IPsec ESP a pre-arranged security configuration is possible, then IPsec ESP with a
with a null-transform MAY be used to authenticate LLMNR responses. In a null-transform MAY be used to authenticate LLMNR responses. In a small
small network without a certificate authority, this can be most easily 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 for both TCP and administration. LLMNR requires allocation of a port for both TCP and
UDP. LLMNR utilizes a link scope multicast IPv4 address (224.0.0.251) UDP. LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251)
that has been previously allocated to LLMNR by IANA. It also requires that has been previously allocated to LLMNR by IANA. It also requires
allocation of a link scope multicast IPv6 address, for use with queries allocation of a link scope multicast IPv6 address, for use with queries
of types other than A/AAAA. of types other than A/AAAA.
7. Normative References 7. Normative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
skipping to change at page 17, line 44 skipping to change at page 18, line 5
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[IPV4Link] Cheshire, S., Aboba, B.,Guttman, E., "Dynamic
Configuration of IPv4 Link-Local Addresses", Internet
draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-07.txt, August 2002.
8. Informative References 8. Informative References
[RFC1536] Kumar, A., et. al. "DNS Implementation Errors and [RFC1536] Kumar, A., et. al. "DNS Implementation Errors and
Suggested Fixes", RFC 1536, October 1993. Suggested Fixes", RFC 1536, October 1993.
[RFC2292] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", [RFC2292] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6",
RFC 2292, February 1998. RFC 2292, February 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
skipping to change at page 18, line 32 skipping to change at page 18, line 37
[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness
of Caching", IEEE/ACM Transactions on Networking, Volume of Caching", IEEE/ACM Transactions on Networking, Volume
10, Number 5, pp. 589, October 2002. 10, Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I., Thaler, D., "Well known site [DNSDisc] Durand, A., Hagino, I., Thaler, D., "Well known site
local unicast addresses to communicate with recursive DNS local unicast addresses to communicate with recursive DNS
servers", Internet draft (work in progress), draft-ietf- servers", Internet draft (work in progress), draft-ietf-
ipv6-dns-discovery-07.txt, October 2002. ipv6-dns-discovery-07.txt, October 2002.
[IPV4Link] Cheshire, S., Aboba, B.,Guttman, E., "Dynamic
Configuration of IPv4 Link-Local Addresses", Internet
draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-07.txt, August 2002.
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft [LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
(work in progress), draft-guttman-mdns-enable-02.txt, (work in progress), draft-guttman-mdns-enable-02.txt,
April 2002. April 2002.
[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet [NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
draft (work in progress), draft-ietf-ipn-gwg-icmp-name- draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-09.txt, May 2002. lookups-09.txt, May 2002.
Acknowledgments Acknowledgments
skipping to change at page 20, line 30 skipping to change at page 20, line 40
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."
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-14.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-15.txt>, and expires
October 22, 2003. November 22, 2003.
 End of changes. 

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