DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-19.txt> Microsoft
-12 May 2003
+<draft-ietf-dnsext-mdns-20.txt> Microsoft
+21 May 2003
Linklocal Multicast Name Resolution (LLMNR)
-INTERNET-DRAFT LLMNR 12 May 2003
+INTERNET-DRAFT LLMNR 21 May 2003
Table of Contents
1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
+ 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 4
2. Name resolution using LLMNR ........................... 4
- 2.1 Sender behavior ................................. 5
+ 2.1 Sender behavior ................................. 4
2.2 Responder behavior .............................. 5
2.3 Unicast queries ................................. 6
2.4 Addressing ...................................... 7
- 2.5 Off-link detection .............................. 8
+ 2.5 Off-link detection .............................. 7
2.6 Retransmissions ................................. 8
2.7 DNS TTL ......................................... 9
3. Usage model ........................................... 9
5. Security considerations ............................... 15
5.1 Scope restriction ............................... 15
5.2 Usage restriction ............................... 16
- 5.3 Cache and port separation ....................... 17
+ 5.3 Cache and port separation ....................... 16
5.4 Authentication .................................. 17
6. IANA considerations ................................... 17
7. Normative References .................................. 17
-INTERNET-DRAFT LLMNR 12 May 2003
+INTERNET-DRAFT LLMNR 21 May 2003
1. Introduction
Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks. The assumption is that if
-a network has a home gateway, then the network either has DNS and DHCPv4
-servers or the home gateway provides DHCPv4 and DNS server
-functionality. By providing Dynamic Host Configuration Service for
-IPv4 (DHCPv4), as well as a DNS server with support for dynamic DNS,
-which is also authoritative for the A RRs of local hosts, it is possible
-to support resolution of local host names over IPv4.
-
-For small IPv6 networks, equivalent functionality can be provided by
-implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for
-DNS configuration [DHCPv6DNS], as well providing a DNS server with
-support for dynamic DNS, which is also authoritative for the AAAA RRs of
-local hosts, it is possible to support the resolution of local host
-names over IPv6 as well as IPv4.
+a network has a home gateway, then the network is able to provide DNS
+server configuration and a DNS server is available that is authoritative
+for the names of local hosts and can support dynamic DNS. Configuration
+issues are discussed in Section 3.2.
In the future, LLMNR may be defined to support greater than link-scope
multicast. This would occur if LLMNR deployment is successful, the
reevaluate which multicast scopes are appropriate for use with multicast
name resolution mechanisms.
+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 resolution over non-multicast capable media.
+1.1. Requirements
+In this document, several words are used to signify the requirements of
+the specification. These words are often capitalized. The key words
+"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
-Esibov, Aboba & Thaler Standards Track [Page 3]
+Esibov, Aboba & Thaler Standards Track [Page 3]
-INTERNET-DRAFT LLMNR 12 May 2003
-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 resolution over non-multicast capable media.
+INTERNET-DRAFT LLMNR 21 May 2003
-1.1. Requirements
-In this document, several words are used to signify the requirements of
-the specification. These words are often capitalized. The key words
-"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].
Further details of sender and responder behavior are provided in the
sections that follow.
+2.1. Sender behavior
+A sender sends an LLMNR query for any legal resource record type (e.g.
+A/AAAA, SRV, PTR, etc.) to the link-scope multicast address. As
+described in Section 2.3, a sender may also send a unicast query. An
+LLMNR sender MAY send a request for any name.
+The RD (Recursion Desired) bit MUST NOT be set in a query. If a
+responder receives a query with the header containing RD set bit, the
+responder MUST ignore the RD bit.
-Esibov, Aboba & Thaler Standards Track [Page 4]
-
-
+Esibov, Aboba & Thaler Standards Track [Page 4]
-INTERNET-DRAFT LLMNR 12 May 2003
-2.1. Sender behavior
-A sender sends an LLMNR query for any legal resource record type (e.g.
-A/AAAA, SRV, PTR, etc.) to the link-scope multicast address. As
-described in Section 2.3, a sender may also send a unicast query. An
-LLMNR sender MAY send a request for any name.
+INTERNET-DRAFT LLMNR 21 May 2003
-The RD (Recursion Desired) bit MUST NOT be set in a query. If a
-responder receives a query with the header containing RD set bit, the
-responder MUST ignore the RD bit.
The sender MUST anticipate receiving no replies to some LLMNR queries,
in the event that no responders are available within the link-scope or
to verify the uniqueness of names as described in Section 4.
Responders MUST NOT respond to LLMNR queries for names they are not
-authoritative for, except in the event of a discovered conflict, as
-described in Section 4. Responders SHOULD respond to LLMNR queries for
-names and addresses they are authoritative for. This applies to both
-forward and reverse lookups.
+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, a computer "host.example.com." configured to respond to
LLMNR queries is authoritative for the name "host.example.com.". On
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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
which the server is running, but MUST NOT respond for other records for
which the server is authoritative.
For example the host "host.example.com." is not authoritative for the
name "child.host.example.com." unless the host is configured with
multiple names, including "host.example.com." and
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 5]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 21 May 2003
+
+
"child.host.example.com.". As a result, "host" cannot reply to a query
for "child" with NXDOMAIN. The purpose of limiting the name authority
scope of a responder is to prevent complications that could be caused by
with the TC bit set to the previous LLMNR multicast query, or
b. The sender's LLMNR cache contains an NS resource record that
+ enables the sender to send a query directly to the hosts
+ authoritative for the name in the query, or
+ c. The sender queries for a PTR RR.
+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
+discard the response and resend the query over TCP using the unicast
+address of the responder. The RA (Recursion Available) bit in the
+header of the response MUST NOT be set. If the RA bit is set in the
+response header, the sender MUST ignore the RA bit.
-Esibov, Aboba & Thaler Standards Track [Page 6]
+Esibov, Aboba & Thaler Standards Track [Page 6]
-INTERNET-DRAFT LLMNR 12 May 2003
- enables the sender to send a query directly to the hosts
- authoritative for the name in the query, or
- c. The sender queries for a PTR RR.
+INTERNET-DRAFT LLMNR 21 May 2003
-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
-discard the response and resend the query over TCP using the unicast
-address of the responder. The RA (Recursion Available) bit in the
-header of the response MUST NOT be set. If the RA bit is set in the
-response header, the sender MUST ignore the RA bit.
Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP
unicast LLMNR queries MUST be sent using TCP, using the same connection
MAY be responded to with an empty answer section and the TC bit set, so
as to require the sender to resend the query using TCP. Senders MUST
support sending TCP queries, and Responders MUST support listening for
-TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on
+TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on
the TCP listen socket to one (1) so that SYN-ACK packets will have TTL
-(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming
+(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming
connection from off-link since the Sender will not receive a SYN-ACK
from the Responder.
send a unicast TCP query, this is treated as a response that no records
of the specified type and class exist for the specified name (it is
treated the same as a response with RCODE=0 and an empty answer
-section). The UDP sender receiving an ICMP "Time Exceeded" message
+section). The UDP sender receiving an ICMP "Time Exceeded" message
SHOULD verify that the ICMP error payload contains a valid LLMNR query
packet, which matches a query that is currently in progress, so as to
-guard against a potential Denial of Service (DoS) attack. If a match
+guard against a potential Denial of Service (DoS) attack. If a match
cannot be made, then the sender relies on the retransmission and timeout
behavior described in Section 2.6.
given responder listens to, and to which a sender sends all queries, is
TBD.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
2.5. Off-link detection
The source address of LLMNR queries and responses MUST be "on link".
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
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 7]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 21 May 2003
+
+
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.
If an LLMNR query sent over UDP is not resolved within the timeout
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
the query in order to assure that it was received by a host capable of
responding to it. Since a multicast query sender cannot know beforehand
whether it will receive no response, one response, or more than one
LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received, on a per-interface
-basis, using the algorithms described in [RFC2988], with a minimum
-timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be
-attempted more than 3 times. Where LLMNR queries are sent using TCP,
-retransmission is handled by the transport layer.
+basis. The algorithms described in [RFC2988] are suggested, with a
+minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD
+NOT be attempted more than 3 times. Where LLMNR queries are sent using
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 8]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 21 May 2003
+
+
+TCP, retransmission is handled by the transport layer.
2.7. DNS TTL
[2] Where a DNS server is configured, by default a sender
SHOULD send LLMNR queries only for names that are either
unqualified or exist within the default domain. Where no
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
DNS server is configured, an LLMNR query MAY be sent for
any name.
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.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 9]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 21 May 2003
+
+
In particular:
[1] If a link-scope IPv6 address is returned in a AAAA RR, that
3.2. LLMNR configuration
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.
+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
+configured DNS server over IPv4. However, an IPv6-only host
+unconfigured with a DNS server suitable for use over IPv6 will be unable
+to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms
+(such as [DHCPv6DNS] and [DNSDisc]) are not yet widely deployed, and not
+all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration
+may be a common problem in the short term, and LLMNR may prove useful in
+enabling linklocal name resolution over IPv6.
+
-INTERNET-DRAFT LLMNR 12 May 2003
+INTERNET-DRAFT LLMNR 21 May 2003
-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 configured DNS server over IPv4.
-
-However, an IPv6-only host unconfigured with a DNS server suitable for
-use over IPv6 will be unable to resolve names using DNS. Since
-automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and
-[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
-short term, and LLMNR may prove useful in enabling linklocal name
-resolution over IPv6.
-
-For example, a home network may provide a DHCPv4 server but may not
-support DHCPv6 for DNS configuration [DHCPv6DNS]. In such a
-circumstance, IPv6-only hosts will not be configured with a DNS server.
-Where a DNS server is configured but does not support dynamic client
-update over IPv6 or DHCPv6-based dynamic update, hosts on the home
-network will not be able to dynamically register or resolve the names of
-local IPv6 hosts. If the configured DNS server responds to AAAA RR
+Where a DHCPv4 server is available but not a DHCPv6 server [DHCPv6DNS],
+IPv6-only hosts may not be configured with a DNS server. Where there is
+no DNS server authoritative for the names of hosts on the local network
+or the authoritative DNS server does not support dynamic client update
+over IPv6 or DHCPv6-based dynamic update, hosts on the home network will
+not be able to dynamically register or resolve the names of local IPv6
+hosts. For example, if the configured DNS server responds to AAAA RR
queries sent over IPv4 or IPv6 with an authoritative name error
(RCODE=3), then it will not be possible to resolve the names of
IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for
local name resolution.
+Similarly, if a DHCPv4 server is available providing DNS server
+configuration, and the DNS server authoritative for the A RRs of local
+hosts also supports either dynamic client update over IPv4 or
+DHCPv4-based dynamic update, then resolution of the names of local IPv4
+hosts can be provided over IPv4 without LLMNR. However, if there is no
+DNS server authoritative for the names of local hosts, or the
+authoritative DNS server does not support dynamic update, then LLMNR may
+prove useful in enabling linklocal name resoltion 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
which various name resolution mechanisms should be used can be specified
using the Name Service Search Option for DHCP [RFC2937].
-3.2.1. Configuration consistency
-
It is possible that DNS configuration mechanisms will go in and out of
service. In these circumstances, it is possible for hosts within an
administrative domain to be inconsistent in their DNS configuration.
For example, where DHCP is used for configuring DNS servers, one or more
-DHCP servers can go down. As a result, hosts configured prior to the
+DHCP servers can fail. As a result, hosts configured prior to the
outage will be configured with a DNS server, while hosts configured
after the outage will not. Alternatively, it is possible for the DNS
configuration mechanism to continue functioning while configured DNS
servers fail.
+Unless unconfigured hosts periodically retry configuration, an outage in
+the DNS configuration mechanism will result in hosts continuing to use
+LLMNR even once the outage is repaired. Since LLMNR only enables
+linklocal name resolution, this represents an unnecessary degradation in
+capabilities. As a result, it is recommended that hosts without a
+configured DNS server periodically attempt to obtain DNS configuration.
+A default retry interval of two (2) minutes is RECOMMENDED.
-INTERNET-DRAFT LLMNR 12 May 2003
-
+INTERNET-DRAFT LLMNR 21 May 2003
-Unless unconfigured hosts periodically retry configuration, an outage in
-the DNS configuration mechanism will result in hosts continuing to
-prefer LLMNR even once the outage is repaired. Since LLMNR only enables
-linklocal name resolution, this represents an unnecessary degradation in
-capabilities. As a result, it is recommended that hosts without a
-configured DNS server periodically attempt to obtain DNS configuration.
-A default retry interval of two (2) minutes is RECOMMENDED.
4. Conflict resolution
By default, a host SHOULD be configured to behave as though all RRs are
UNIQUE. Uniqueness verification is carried out when the host:
+ - starts up or
+ - is configured to respond to the LLMNR queries on an interface or
+ - is configured to respond to the LLMNR queries using additional
+ UNIQUE resource records.
+When a host that owns a UNIQUE record receives an LLMNR query for that
+record, the host MUST respond. After the client receives a response, it
-Esibov, Aboba & Thaler Standards Track [Page 12]
+Esibov, Aboba & Thaler Standards Track [Page 12]
-INTERNET-DRAFT LLMNR 12 May 2003
- - starts up or
- - is configured to respond to the LLMNR queries on an interface or
- - is configured to respond to the LLMNR queries using additional
- UNIQUE resource records.
+INTERNET-DRAFT LLMNR 21 May 2003
+
-When a host that owns a UNIQUE record receives an LLMNR query for that
-record, the host MUST respond. After the client receives a response, it
MUST check whether the response arrived on another interface. If this
is the case, then the client 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.
The name conflict detection mechanism doesn't prevent name conflicts
-when previously partitioned segments are connected by a bridge. In such
-a situation, name conflicts are detected when a sender receives more
-than one response to its LLMNR multicast query. In this case, the
-sender sends the first response that it received to all responders that
-responded to this query except the first one, using UDP unicast. A host
-that receives a query response containing a UNIQUE resource record that
-it owns, even if it didn't send such a query, MUST verify that no other
-host within the LLMNR scope is authoritative for the same name, using
-the mechanism described above. Based on the result, the host detects
-whether there is a name conflict and acts accordingly.
+when previously partitioned segments are connected by a bridge. In order
+to minimize the chance of conflicts in such a situation, it is
+recommended that steps be taken to ensure hostname uniqueness. For
+example, the hostname could be chosen randomly from a large pool of
+potential names, or the hostname could be assigned via a process
+designed to guarantee uniqueness.
4.1. Considerations for Multiple Interfaces
(see Figure 1). The multi-homed host may, however, be configured to use
the "myhost" name on the interface on the left.
+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
+interfaces, and receives replies from more than one, the result returned
+to the client is defined by the implementation. The situation is
+illustrated in figure 2.
-Esibov, Aboba & Thaler Standards Track [Page 13]
-INTERNET-DRAFT LLMNR 12 May 2003
+Esibov, Aboba & Thaler Standards Track [Page 13]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 21 May 2003
-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
-interfaces, and receives replies from more than one, the result returned
-to the client is defined by the implementation. The situation is
-illustrated in figure 2.
---------- ----------
| | | |
for the host RR for name "A" it will receive a response from hosts on
both interfaces.
-Host myhost will then send the first responder's response to the second
-responder, who will attempt to verify the uniqueness of host RR for its
-name, but will not discover a conflict, since the conflicting host
-resides on a different link. Therefore it will continue using its name.
-
Host myhost cannot distinguish between the situation shown in Figure 2,
and that shown in Figure 3 where no conflict exists.
this structure can be used for both IPv4 (using v4-mapped IPv6
addresses) and IPv6 addresses.
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
Following the example in Figure 2, an application on 'myhost' issues the
request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
sin6_scope_id value that disambiguates which interface is used to reach
the address. Of course, to the application, Figures 2 and 3 are still
indistinguishable, but this API allows the application to communicate
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 14]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 21 May 2003
+
+
successfully with any address in the list.
5. Security Considerations
multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
fields to one (1) on both queries and responses.
+While this limits the ability of off-link attackers to spoof LLMNR
+queries and responses, it does not eliminate it. For example, it is
+possible for an attacker to spoof a response to a frequent query (such
+as an A/AAAA query for a popular Internet host), and using a TTL or Hop
+Limit field larger than one (1), for the forged response to reach the
+LLMNR sender. There also are 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.
-INTERNET-DRAFT LLMNR 12 May 2003
+INTERNET-DRAFT LLMNR 21 May 2003
-While this limits the ability of off-link attackers to spoof LLMNR
-queries and responses, it does not eliminate it. For example, it is
-possible for an attacker to spoof a response to a frequent query (such
-as an A/AAAA query for a popular Internet host), and using a TTL or Hop
-Limit field larger than one (1), for the forged response to reach the
-LLMNR sender. There also are 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.
eliminating the benefits of cache separation. As a result, LLMNR is
best thought of as a name resolution mechanism of last resort.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
5.3. Cache and port separation
In order to prevent responses to LLMNR queries from polluting the DNS
LLMNR operates on a separate port from DNS, reducing the likelihood that
a DNS server will unintentionally respond to an LLMNR query.
+
+
+Esibov, Aboba & Thaler Standards Track [Page 16]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 21 May 2003
+
+
5.4. Authentication
LLMNR does not require use of DNSSEC, and as a result, responses to
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
+[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
-Esibov, Aboba & Thaler Standards Track [Page 17]
+[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
+ Timer", RFC 2988, November 2000.
+Esibov, Aboba & Thaler Standards Track [Page 17]
-INTERNET-DRAFT LLMNR 12 May 2003
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
+INTERNET-DRAFT LLMNR 21 May 2003
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
- Timer", RFC 2988, November 2000.
8. Informative References
draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-07.txt, August 2002.
+[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
+ (work in progress), draft-guttman-mdns-enable-02.txt,
+ April 2002.
+[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
+ draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
+ lookups-09.txt, May 2002.
-Esibov, Aboba & Thaler Standards Track [Page 18]
-INTERNET-DRAFT LLMNR 12 May 2003
+Esibov, Aboba & Thaler Standards Track [Page 18]
-[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
- (work in progress), draft-guttman-mdns-enable-02.txt,
- April 2002.
-[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
- draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
- lookups-09.txt, May 2002.
+
+
+
+INTERNET-DRAFT LLMNR 21 May 2003
+
Acknowledgments
+
+
+
+
+
+
+
+
Esibov, Aboba & Thaler Standards Track [Page 19]
-INTERNET-DRAFT LLMNR 12 May 2003
+INTERNET-DRAFT LLMNR 21 May 2003
Intellectual Property Statement
-INTERNET-DRAFT LLMNR 12 May 2003
+INTERNET-DRAFT LLMNR 21 May 2003
Open Issues
Expiration Date
-This memo is filed as <draft-ietf-dnsext-mdns-19.txt>, and expires
+This memo is filed as <draft-ietf-dnsext-mdns-20.txt>, and expires
November 22, 2003.
projects / thirdparty / bind9.git / commitdiff
