draft-ietf-dnsext-mdns-10.txt   draft-ietf-dnsext-mdns-11.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-10.txt> Microsoft <draft-ietf-dnsext-mdns-11.txt> Microsoft
23 March 2002 20 July 2002
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
Today, with the rise of home networking, there are an increasing number Today, with the rise of home networking, there are an increasing number
of ad-hoc networks operating without a DNS server. In order to allow of ad-hoc networks operating without a DNS server. In order to allow
name resolution in such environments, Link-Local Multicast Name name resolution in such environments, Link-Local Multicast Name
Resolution (LLMNR) is proposed. Resolution (LLMNR) is proposed. LLMNR supports all current and future
DNS formats, types and classes, while operating on a separate port from
DNS, and with a distinct resolver cache.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3
2. Name resolution using LLMNR ........................... 3 2. Name resolution using LLMNR ........................... 3
2.1 Behavior of the sender and responder ............ 4 2.1 Sender behavior ................................. 4
3. Usage model ........................................... 7 2.2 Responder behavior .............................. 5
2.3 Addressing ...................................... 6
2.4 TTL ............................................. 7
2.5 No/multiple responses ........................... 7
3. Usage model ........................................... 8
3.1 LLMNR configuration ............................. 8 3.1 LLMNR configuration ............................. 8
4. Sequence of events .................................... 9 4. Sequence of events .................................... 9
5. Conflict resolution ................................... 9 5. Conflict resolution ................................... 10
5.1 Considerations for multiple interfaces .......... 11 5.1 Considerations for multiple interfaces .......... 11
5.2 API issues ...................................... 12 5.2 API issues ...................................... 13
6. Security considerations ............................... 13 6. Security considerations ............................... 13
6.1 Scope restriction ............................... 13 6.1 Scope restriction ............................... 14
6.2 Usage restriction ............................... 14 6.2 Usage restriction ............................... 14
6.3 Cache and port separation ....................... 15 6.3 Cache and port separation ....................... 15
6.4 Authentication .................................. 15 6.4 Authentication .................................. 15
7. IANA considerations ................................... 15 7. IANA considerations ................................... 15
8. Normative References .................................. 15 8. Normative References .................................. 16
9. Informative References ................................ 16 9. Informative References ................................ 16
Acknowledgments .............................................. 17 Acknowledgments .............................................. 17
Authors' Addresses ........................................... 17 Authors' Addresses ........................................... 17
Intellectual Property Statement .............................. 18 Intellectual Property Statement .............................. 18
Full Copyright Statement ..................................... 18 Full Copyright Statement ..................................... 18
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. cache, but does not change the format of DNS packets. LLMNR supports all
current and future DNS formats, types and classes.
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. server.
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 for IPv4, while remaining unconfigured with a DNS server DNS server for IPv4, while remaining unconfigured with a DNS server
suitable for use with IPv6. Since automatic IPv6 DNS configuration suitable for use with IPv6. Since automatic IPv6 DNS configuration
mechanisms such as [DHCPv6DNS] and [DNSDisc] are not yet widely mechanisms such as [DHCPv6DNS] and [DNSDisc] are not yet widely
deployed, such "partially configuration" may be common in the short deployed, such "partially configuration" may be common in the short
term. However, in the long term, IPv6 DNS configuration will become more term. However, in the long term, IPv6 DNS configuration will become more
common so that LLMNR will typically be restricted to adhoc networks in common so that LLMNR will typically be restricted to adhoc networks in
which neither IPv4 nor IPv6 DNS servers are configured. which neither IPv4 nor IPv6 DNS servers are configured.
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.
1.1. Requirements
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119]. described in [RFC2119].
1.2. Terminology
Responder A host that listens to (but not necessarily responds to)
a LLMNR query is called "responder".
Sender A host that sends an LLMNR query. The same host may be
configured as a "sender", but not a "responder" and vice
versa, i.e. as a "responder", but not a "sender".
2. Name resolution using LLMNR 2. Name resolution using LLMNR
While operating on a different port with a distinct resolver cache, While operating on a different port with a distinct resolver cache,
LLMNR makes no change to the current format of DNS packets. LLMNR makes no change to the current format of DNS packets.
LLMNR queries are sent to and received on port 5353 using a LINKLOCAL LLMNR queries are sent to and received on port 5353 using a LINKLOCAL
address as specified in "Administratively Scoped IP Multicast" [RFC2365] address as specified in "Administratively Scoped IP Multicast" [RFC2365]
for IPv4 and the "solicited name" LINKLOCAL multicast addresses for for IPv4 and the "solicited name" LINKLOCAL multicast addresses for
IPv6, and using a unicast addresses in a few scenarios described below IPv6, and using a unicast addresses in a few scenarios described below
in Section 3. The LLMNR LINKLOCAL address to be used for IPv4 is in Section 3. The LLMNR LINKLOCAL address to be used for IPv4 is
224.0.0.251. LINKLOCAL addresses are used to prevent propagation of 224.0.0.251. LINKLOCAL addresses are used to prevent propagation of
LLMNR traffic across routers, potentially flooding the network. LLMNR traffic across routers, potentially flooding the network.
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
skipping to change at page 4, line 31 skipping to change at page 4, line 44
the assumption that LLMNR is not needed on multiple links proves the assumption that LLMNR is not needed on multiple links proves
incorrect, and multicast routing becomes ubiquitous. For example, it is incorrect, and multicast routing becomes ubiquitous. For example, it is
not clear that this assumption will be valid in large adhoc networking not clear 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.
2.1. Behavior of the sender and responder 2.1. Sender behavior
For the purpose of this document a host that sends a LLMNR query is
called a "sender", while a host that listens to (but not necessarily
responds to) a LLMNR query is called "responder". Although the same host
may be configured as a "sender", but not a "responder" and vice versa,
i.e. as a "responder", but not a "sender", the host configured as a
"responder" MUST act as a sender by using LLMNR dynamic update requests
to verify the uniqueness of names as described in Section 5.
2.1.1. Behavior of senders
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 address. Notice that in some (e.g. A, PTR, etc.) to the LINKLOCAL address. Notice that in some
scenarios described below in Section 3 a sender may also send a unicast scenarios described below in Section 3 a sender may also send a unicast
query. The RD (Recursion Desired) bit MUST NOT be set. If a responder 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. MUST ignore the RD bit.
The IPv6 LINKLOCAL address a given responder listens to, and to which a The IPv6 LINKLOCAL address a given responder listens to, and to which a
sender sends, is a link-local multicast address formed as follows: The sender sends, is a link-local multicast address formed as follows: The
skipping to change at page 5, line 4 skipping to change at page 5, line 8
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 address. Notice that in some (e.g. A, PTR, etc.) to the LINKLOCAL address. Notice that in some
scenarios described below in Section 3 a sender may also send a unicast scenarios described below in Section 3 a sender may also send a unicast
query. The RD (Recursion Desired) bit MUST NOT be set. If a responder 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. MUST ignore the RD bit.
The IPv6 LINKLOCAL address a given responder listens to, and to which a The IPv6 LINKLOCAL address a given responder listens to, and to which a
sender sends, is a link-local multicast address formed as follows: The sender sends, is a link-local multicast address formed as follows: The
name of the resource record in question is expressed in its canonical name of the resource record in question is expressed in its canonical
form (see [RFC2535], section 8.1), which is uncompressed with all form (see [RFC2535], section 8.1), which is uncompressed with all
alphabetic characters in lower case. The first label of the resource alphabetic characters in lower case. The first label of the FQDN in the
record name is then hashed using the MD5 algorithm, described in query is then hashed using the MD5 algorithm, described in [RFC1321].
[RFC1321]. The first 32 bits of the resultant 128-bit hash is then The first 32 bits of the resultant 128-bit hash is then appended to the
appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name
"solicited name multicast address". (Note: this procedure is intended multicast address". (Note: this procedure is intended to be the same as
to be the same as that specified in section 3 of "IPv6 Node Information that specified in section 3 of "IPv6 Node Information Queries"
Queries" [NodeInfo]). A responder that listens for queries for multiple [NodeInfo]). A responder that listens for queries for multiple names
names will necessarily listen to multiple of these solicited name will necessarily listen to multiple of these solicited name multicast
multicast addresses. addresses.
If the LLMNR query is not resolved during a limited amount of time If the LLMNR query is not resolved during a limited amount of time
(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. The default value for LLMNR_TIMEOUT capable of responding to the query. The default value for LLMNR_TIMEOUT
is 1 second. is 1 second.
Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be
repeated more often than once per second to reduce unnecessary network repeated more often than once per second to reduce unnecessary network
traffic. The delay between attempts should be randomized so as to avoid traffic. The delay between attempts should be randomized so as to avoid
synchronization effects. synchronization effects.
2.1.2. Behavior of responders 2.2. Responder behavior
A responder listens on port 5353 on the LINKLOCAL address and on the A responder listens on port 5353 on the LINKLOCAL address and on the
unicast address(es) that could be set as the source address(es) when the unicast address(es) that could be set as the source address(es) when the
responder responds to the LLMNR query. Responders MUST respond to LLMNR responder responds to the LLMNR query. The host configured as a
queries to those and only those names for which they are authoritative. "responder" MUST act as a sender by using LLMNR dynamic update requests
As an example, computer "host.example.com." is authoritative for the to verify the uniqueness of names as described in Section 5.
domain "host.example.com.". On receiving a LLMNR A record query for the
name "host.example.com." such a host responds with A record(s) that Responders MUST NOT respond to LLMNR queries for names they are not
contain IP address(es) in the RDATA of the record. authoritative for. Responders SHOULD respond to LLMNR queries for names
and addresses they are authoritative for. This applies to both forward
and reverse lookups.
As an example, assume that computer "host.example.com." is authoritative
for the domain "host.example.com.". On receiving a LLMNR A resource
record query for the name "host.example.com." the host responds with A
record(s) that contain IP address(es) in the RDATA of the resource
record.
In conventional DNS terminology a DNS server authoritative for a zone is In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone root except for authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional DNS the branches delegated into separate zones. Contrary to conventional DNS
terminology, a responder is authoritative only for the zone root. For terminology, an LLMNR responder is authoritative only for the zone root.
example the host "host.example.com." is not authoritative for the name
"child.host.example.com." unless the host is configured with multiple For example the host "host.example.com." is not authoritative for the
names, including "host.example.com." and "child.host.example.com.". The name "child.host.example.com." unless the host is configured with
purpose of limiting the name authority scope of a responder is to multiple names, including "host.example.com." and
prevent complications that could be caused by coexistence of two or more "child.host.example.com.". As a result, "host" cannot reply to a query
hosts with the names representing child and parent (or grandparent) for "child" with NXDOMAIN. The purpose of limiting the name authority
nodes in the DNS tree, for example, "host.example.com." and scope of a responder is to prevent complications that could be caused by
"child.host.example.com.". coexistence of two or more hosts with the names representing child and
parent (or grandparent) nodes in the DNS tree, for example,
"host.example.com." and "child.host.example.com.".
In this example (unless this limitation is introduced) a LLMNR query for In this example (unless this limitation is introduced) a LLMNR query for
an A record for the name "child.host.example.com." would result in two an A record for the name "child.host.example.com." would result in two
authoritative responses: name error received from "host.example.com.", authoritative responses: name error received from "host.example.com.",
and a requested A record - from "child.host.example.com.". To prevent and a requested A record - from "child.host.example.com.". To prevent
this ambiguity, LLMNR enabled hosts could perform a dynamic update of this ambiguity, LLMNR enabled hosts could perform a dynamic update of
the parent (or grandparent) zone with a delegation to a child zone. In the parent (or grandparent) zone with a delegation to a child zone. In
this example a host "child.host.example.com." would send a dynamic this example a host "child.host.example.com." would send a dynamic
update for the NS and glue A record to "host.example.com.", but this update for the NS and glue A record to "host.example.com.", but this
approach significantly complicates implementation of LLMNR and would not approach significantly complicates implementation of LLMNR and would not
be acceptable for lightweight hosts. be acceptable for lightweight hosts.
A response to a LLMNR query is composed in exactly the same manner as a A response to a LLMNR query is composed in exactly the same manner as a
skipping to change at page 6, line 31 skipping to change at page 6, line 43
resolve positively. resolve positively.
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.
Even if the RA bit is set in the response header, the sender MUST ignore Even if the RA bit is set in the response header, the sender MUST ignore
it. it.
2.1.3. LLMNR addressing 2.3. Addressing
For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of
IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to
source address selection, TTL settings, and acceptable source address selection, TTL settings, and acceptable
source/destination address combinations. IPv6 is described in [RFC2460]; source/destination address combinations. IPv6 is described in [RFC2460];
IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries and IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries and
responses MUST obey the rules laid out in these documents. responses MUST obey the rules laid out in these documents.
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
skipping to change at page 7, line 6 skipping to change at page 7, line 20
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 specify the TTL of outgoing unicast and multicast options are used to specify 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 receive the IPv4 TTL of received packets with recvmsg(). [RFC2292] to receive the IPv4 TTL of received packets with recvmsg(). [RFC2292]
specifies similar options for specifying and receiving the IPv6 Hop specifies similar options for specifying and receiving the IPv6 Hop
Limit. Limit.
2.1.4. Use of LLMNR TTL 2.4. 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.
2.1.5. No/multiple responses 2.5. No/multiple responses
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 (NXRRSET). and class for the specified name exist (NXRRSET).
Since the responder MUST NOT respond to queries for names it is not
authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR
query with an NXRRSET. However, for other queries, such a response is
possible; for example, if the host has a AAAA RR, but no MX RR, and an
MX RR query is received.
The sender MUST anticipate receiving multiple replies to the same LLMNR The sender MUST anticipate receiving multiple replies to the same LLMNR
query, in the event that several LLMNR enabled computers receive the query, in the event that several LLMNR enabled computers receive the
query and respond with valid answers. When this occurs, the responses query and respond with valid answers. When this occurs, the responses
MAY first be concatenated, and then treated in the same manner that MAY first be concatenated, and then treated in the same manner that
multiple RRs received from the same DNS server would, ordinarily. multiple RRs received from the same DNS server would, ordinarily.
However, after receiving an initial response, the sender is not required However, after receiving an initial response, the sender is not required
to wait for LLMNR_TIMEOUT for additional responses. to wait for LLMNR_TIMEOUT for additional responses.
3. Usage model 3. Usage model
The same host may be configured as a "sender", but not a "responder" and The same host may be configured as a "sender", but not a "responder" and
vice versa (as a "responder", but not "sender"). However, the host vice versa (as a "responder", but not "sender"). However, a host
configured as a "responder" MUST at least use "sender"'s capability to configured as a "responder" MUST at least use a "sender's" capability to
send LLMNR dynamic update requests to verify the uniqueness of the names send LLMNR dynamic update requests to verify the uniqueness of the
as described in Section 5. An LLMNR "sender" MAY multicast requests for names, as described in Section 5. An LLMNR "sender" MAY multicast
any name. If that name is not qualified and does not end in a trailing requests for any name. If that name is not qualified and does not end in
dot, for the purposes of LLMNR, the implicit search order is as follows: a trailing dot, for the 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.
[2] Request just the name. [2] Request just the name.
This is the behavior suggested by [RFC1536]. LLMNR uses this technique This is the behavior suggested by [RFC1536]. LLMNR uses this technique
to resolve unqualified host names. to resolve unqualified host names. The same host MAY use LLMNR queries
for the resolution of unqualified host names, and conventional DNS
queries for resolution of other DNS names.
If a DNS server is running on a host that supports LLMNR, the DNS server If a DNS server is running on a host that supports LLMNR, the DNS server
MUST respond to LLMNR queries only for the RRSets owned by the host on MUST respond to LLMNR queries only for the RRSets owned by the host on
which the server is running, but MUST NOT respond for the records for which the server is running, but MUST NOT respond for other records for
which the server is authoritative. which the server is authoritative.
A sender MUST NOT send a unicast LLMNR query except when: A sender MUST NOT send a unicast LLMNR query except when:
a. A sender repeats a query after it received a response a. A sender repeats a query after it received a response
to the previous LLMNR query with the TC bit set, or to the previous LLMNR query with the TC bit set, or
b. The sender's LLMNR cache contains an NS resource record that b. The sender's LLMNR cache contains an NS resource record that
enables the sender to send a query directly to the hosts enables the sender to send a query directly to the hosts
authoritative for the name in the query. authoritative for the name in the query.
A responder with a name "host.example.com." configured to respond to the A responder with a name "host.example.com." configured to respond to the
LLMNR queries is authoritative for the name "host.example.com.". For LLMNR queries is authoritative for the name "host.example.com.". For
example, when a responder with the name "host.example.com." receives an example, when a responder with the name "host.example.com." receives an
A type LLMNR query for the name "host.example.com." it authoritatively A type LLMNR query for the name "host.example.com." it authoritatively
responds to the query. responds to the query.
The same host MAY use LLMNR queries for the resolution of the local
names, and conventional DNS queries for resolution of other DNS names.
3.1. LLMNR configuration 3.1. LLMNR configuration
LLMNR usage can be configured manually or automatically. On interfaces LLMNR usage can be configured manually or automatically. On interfaces
where no manual or automatic DNS configuration has been performed for a where no manual or automatic DNS configuration has been performed for a
given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that
protocol. protocol.
For IPv6, the stateless DNS discovery mechanisms described in "IPv6 For IPv6, the stateless DNS discovery mechanisms described in "IPv6
Stateless DNS Discovery" [DNSDisc] or "Using DHCPv6 for DNS Stateless DNS Discovery" [DNSDisc] or "Using DHCPv6 for DNS
Configuration in Hosts" [DHCPv6DNS] can be used to discover whether Configuration in Hosts" [DHCPv6DNS] can be used to discover whether
LLMNR should be enabled or disabled on a per-interface basis. LLMNR should be enabled or disabled on a per-interface basis.
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].
skipping to change at page 18, line 43 skipping to change at page 19, line 4
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-10.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-11.txt>, and expires
October 22, 2002. February 22, 2003.
 End of changes. 

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