draft-ietf-dnsext-mdns-35.txt   draft-ietf-dnsext-mdns-36.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-35.txt> Microsoft <draft-ietf-dnsext-mdns-36.txt> Microsoft
2 September 2004 8 September 2004
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 16, line 6 skipping to change at page 16, line 6
IPv6. IPv6.
Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
IPv6-only hosts may not be configured with a DNS server. Where there IPv6-only hosts may not be configured with a DNS server. Where there
is no DNS server authoritative for the name of a host or the is no DNS server authoritative for the name of a host or the
authoritative DNS server does not support dynamic client update over authoritative DNS server does not support dynamic client update over
IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
be able to do DNS dynamic update, and other hosts will not be able to be able to do DNS dynamic update, and other hosts will not be able to
resolve its name. resolve its name.
For example, if the configured DNS server responds to all AAAA RR For example, if the configured DNS server responds to a AAAA RR query
queries sent over IPv4 or IPv6 with an authoritative name error sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
(RCODE=3), then it will not be possible to resolve the names of RCODE=0 and an empty answer section, then a AAAA RR query sent using
IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for LLMNR over IPv6 may be successful in resolving the name of an
local name resolution. 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 linklocal name resolution over IPv4.
skipping to change at page 17, line 31 skipping to change at page 17, line 31
verify that there is no other host within the scope of LLMNR query verify that there is no other host within the scope of LLMNR query
propagation that can return a resource record for the same name, type propagation that can return a resource record for the same name, type
and class on that interface. Once a responder has verified the and class on that interface. Once a responder has verified the
uniqueness of a UNIQUE resource record, if it receives an LLMNR query uniqueness of a UNIQUE resource record, if it receives an LLMNR query
for that resource record, it MUST respond. for that resource record, it MUST respond.
To verify uniqueness, a responder MUST send an LLMNR query for each To verify uniqueness, a responder MUST send an LLMNR query for each
UNIQUE resource record. If no response is received after a suitable UNIQUE resource record. If no response is received after a suitable
number of attempts (see Section 2.7), the responder can use the number of attempts (see Section 2.7), the responder can use the
UNIQUE resource record in response to LLMNR queries. If a response UNIQUE resource record in response to LLMNR queries. If a response
is received, the responder MUST check whether the response arrived on is received, the responder MUST NOT use the UNIQUE resource record in
an interface different from the one on which the query was sent. If response to LLMNR queries.
the response arrives on a different interface, the responder can use
the UNIQUE resource record in response to LLMNR queries. If not,
then it MUST NOT use the UNIQUE resource record in response to LLMNR
queries.
Uniqueness verification is carried out when the host: Uniqueness verification is carried out when the host:
- starts up or is rebooted - starts up or is rebooted
- wakes from sleep (if the network interface was inactive - wakes from sleep (if the network interface was inactive
during sleep) during sleep)
- is configured to respond to LLMNR queries on an interface - is configured to respond to LLMNR queries on an interface
enabled for transmission and reception of IP traffic enabled for transmission and reception of IP traffic
- is configured to respond to LLMNR queries using additional - is configured to respond to LLMNR queries using additional
UNIQUE resource records UNIQUE resource records
- verifies the acquisition of a new IP address and configuration - verifies the acquisition of a new IP address and configuration
on an interface on an interface
The name conflict detection mechanism doesn't prevent name conflicts The name conflict detection mechanism doesn't prevent name conflicts
when previously partitioned segments are connected by a bridge. In when previously partitioned segments are connected by a bridge. It
order to minimize the chance of conflicts in such a situation, it is also does not prevent deadlocks where two hosts attempt to verify
recommended that steps be taken to ensure name uniqueness. For uniqueness of the same RR, yet neither can yet respond to queries
since uniqueness has not yet been verified.
In order to minimize the chance of conflicts in such situations, it
is recommended that steps be taken to ensure name uniqueness. For
example, the name could be chosen randomly from a large pool of example, the name could be chosen randomly from a large pool of
potential names, or the name could be assigned via a process designed potential names, or the name could be assigned via a process designed
to guarantee uniqueness. to guarantee uniqueness.
When name conflicts are detected, they SHOULD be logged. To detect When name conflicts are detected, they SHOULD be logged. To detect
duplicate use of a name, an administrator can use a name resolution duplicate use of a name, an administrator can use a name resolution
utility which employs LLMNR and lists both responses and responders. utility which employs LLMNR and lists both responses and responders.
This would allow an administrator to diagnose behavior and This would allow an administrator to diagnose behavior and
potentially to intervene and reconfigure LLMNR responders who should potentially to intervene and reconfigure LLMNR responders who should
not be configured to respond to the same name. not be configured to respond to the same name.
 End of changes. 

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