mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-29 13:38:26 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews 2002-07-25 14:45:16 +00:00
parent ec3984e9df
commit ea6695989c
1 changed files with 328 additions and 268 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

596
doc/draft/draft-ietf-dnsext-mdns-10.txt → doc/draft/draft-ietf-dnsext-mdns-11.txt
View File

@ -7,8 +7,8 @@
DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-10.txt> Microsoft
23 March 2002
<draft-ietf-dnsext-mdns-11.txt> Microsoft
20 July 2002
Linklocal Multicast Name Resolution (LLMNR)
@ -40,9 +40,9 @@ Abstract
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
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.
@ -61,28 +61,33 @@ Esibov, Aboba & Thaler Standards Track [Page 1]
INTERNET-DRAFT LLMNR 23 March 2002
INTERNET-DRAFT LLMNR 20 July 2002
Table of Contents
1. Introduction .......................................... 3
1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3
2. Name resolution using LLMNR ........................... 3
2.1 Behavior of the sender and responder ............ 4
3. Usage model ........................................... 7
2.1 Sender behavior ................................. 4
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
4. Sequence of events .................................... 9
5. Conflict resolution ................................... 9
5. Conflict resolution ................................... 10
5.1 Considerations for multiple interfaces .......... 11
5.2 API issues ...................................... 12
5.2 API issues ...................................... 13
6. Security considerations ............................... 13
6.1 Scope restriction ............................... 13
6.1 Scope restriction ............................... 14
6.2 Usage restriction ............................... 14
6.3 Cache and port separation ....................... 15
6.4 Authentication .................................. 15
7. IANA considerations ................................... 15
8. Normative References .................................. 15
8. Normative References .................................. 16
9. Informative References ................................ 16
Acknowledgments .............................................. 17
Authors' Addresses ........................................... 17
@ -104,11 +109,6 @@ Full Copyright Statement ..................................... 18
@ -121,14 +121,15 @@ Esibov, Aboba & Thaler Standards Track [Page 2]
INTERNET-DRAFT LLMNR 23 March 2002
INTERNET-DRAFT LLMNR 20 July 2002
1. Introduction
This document discusses Link-Local Multicast Name Resolution (LLMNR),
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
conventional DNS name resolution is not possible. These include
@ -149,10 +150,21 @@ 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, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
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
While operating on a different port with a distinct resolver cache,
@ -160,6 +172,18 @@ LLMNR makes no change to the current format of DNS packets.
LLMNR queries are sent to and received on port 5353 using a LINKLOCAL
address as specified in "Administratively Scoped IP Multicast" [RFC2365]
Esibov, Aboba & Thaler Standards Track [Page 3]
INTERNET-DRAFT LLMNR 20 July 2002
for IPv4 and the "solicited name" LINKLOCAL multicast addresses for
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
@ -173,17 +197,6 @@ 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
resolution for the names of IPv4 hosts on the local network.
Esibov, Aboba & Thaler Standards Track [Page 3]
INTERNET-DRAFT LLMNR 23 March 2002
For small IPv6 networks, equivalent functionality can be provided by a
home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name
@ -210,17 +223,7 @@ issues, usability and impact on the network it will be possible
reevaluate which multicast scopes are appropriate for use with multicast
name resolution mechanisms.
2.1. Behavior of the sender and responder
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
2.1. Sender behavior
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
@ -229,9 +232,6 @@ 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
MUST ignore the RD bit.
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
name of the resource record in question is expressed in its canonical
@ -241,19 +241,22 @@ Esibov, Aboba & Thaler Standards Track [Page 4]
INTERNET-DRAFT LLMNR 23 March 2002
INTERNET-DRAFT LLMNR 20 July 2002
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
name of the resource record in question is expressed in its canonical
form (see [RFC2535], section 8.1), which is uncompressed with all
alphabetic characters in lower case. The first label of the resource
record name is then hashed using the MD5 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 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 Information
Queries" [NodeInfo]). A responder that listens for queries for multiple
names will necessarily listen to multiple of these solicited name
multicast addresses.
alphabetic characters in lower case. 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 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 is intended to be the same as
that specified in section 3 of "IPv6 Node Information Queries"
[NodeInfo]). A responder that listens for queries for multiple names
will necessarily listen to multiple of these solicited name multicast
addresses.
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
@ -266,32 +269,29 @@ repeated more often than once per second to reduce unnecessary network
traffic. The delay between attempts should be randomized so as to avoid
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
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
queries to those and only those names for which they are authoritative.
As an example, computer "host.example.com." is authoritative for the
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
contain IP address(es) in the RDATA of the record.
responder responds to the LLMNR query. 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.
Responders MUST NOT respond to LLMNR queries for names they are not
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
authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional DNS
terminology, a responder is authoritative only for the zone root. 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 "child.host.example.com.". The
purpose of limiting the name authority scope of a responder is to
prevent complications that could be caused by 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
an A record for the name "child.host.example.com." would result in two
terminology, an LLMNR responder is authoritative only for the zone root.
@ -301,9 +301,21 @@ Esibov, Aboba & Thaler Standards Track [Page 5]
INTERNET-DRAFT LLMNR 23 March 2002
INTERNET-DRAFT LLMNR 20 July 2002
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
"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
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
an A record for the name "child.host.example.com." would result in two
authoritative responses: name error received from "host.example.com.",
and a requested A record - from "child.host.example.com.". To prevent
this ambiguity, LLMNR enabled hosts could perform a dynamic update of
@ -330,7 +342,7 @@ larger window using the unicast address of the responder. The RA
Even if the RA bit is set in the response header, the sender MUST ignore
it.
2.1.3. LLMNR addressing
2.3. Addressing
For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of
IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to
@ -339,6 +351,19 @@ 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.
Esibov, Aboba & Thaler Standards Track [Page 6]
INTERNET-DRAFT LLMNR 20 July 2002
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
response to 255. The sender MUST verify that the Hop Limit field in IPv6
@ -352,21 +377,9 @@ is set to 255. If it is not, then sender MUST ignore the response.
packets. The IP_RECVTTL socket option is available on some platforms
to receive the IPv4 TTL of received packets with recvmsg(). [RFC2292]
specifies similar options for specifying and receiving the IPv6 Hop
Esibov, Aboba & Thaler Standards Track [Page 6]
INTERNET-DRAFT LLMNR 23 March 2002
Limit.
2.1.4. Use of LLMNR TTL
2.4. TTL
The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. Due to the TTL minimalization
@ -375,7 +388,7 @@ 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
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,
in the event that no responders are available within the linklocal
@ -384,6 +397,12 @@ 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
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
query, in the event that several LLMNR enabled computers receive the
query and respond with valid answers. When this occurs, the responses
@ -392,26 +411,7 @@ multiple RRs received from the same DNS server would, ordinarily.
However, after receiving an initial response, the sender is not required
to wait for LLMNR_TIMEOUT for additional responses.
3. Usage model
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
configured as a "responder" MUST at least use "sender"'s capability to
send LLMNR dynamic update requests to verify the uniqueness of the names
as described in Section 5. An LLMNR "sender" MAY multicast requests for
any name. If that name is not qualified and does not end in a trailing
dot, for the purposes of LLMNR, the implicit search order is as follows:
[1] Request the name with the current domain appended.
[2] Request just the name.
This is the behavior suggested by [RFC1536]. LLMNR uses this technique
to resolve unqualified host names.
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
which the server is running, but MUST NOT respond for the records for
which the server is authoritative.
@ -421,9 +421,33 @@ Esibov, Aboba & Thaler Standards Track [Page 7]
INTERNET-DRAFT LLMNR 23 March 2002
INTERNET-DRAFT LLMNR 20 July 2002
3. Usage model
The same host may be configured as a "sender", but not a "responder" and
vice versa (as a "responder", but not "sender"). However, a host
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, as described in Section 5. An LLMNR "sender" MAY multicast
requests for any name. If that name is not qualified and does not end in
a trailing dot, for the purposes of LLMNR, the implicit search order is
as follows:
[1] Request the name with the current domain appended.
[2] Request just the name.
This is the behavior suggested by [RFC1536]. LLMNR uses this technique
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
MUST respond to LLMNR queries only for the RRSets owned by the host on
which the server is running, but MUST NOT respond for other records for
which the server is authoritative.
A sender MUST NOT send a unicast LLMNR query except when:
a. A sender repeats a query after it received a response
@ -439,9 +463,6 @@ example, when a responder with the name "host.example.com." receives an
A type LLMNR query for the name "host.example.com." it authoritatively
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
LLMNR usage can be configured manually or automatically. On interfaces
@ -451,6 +472,18 @@ protocol.
For IPv6, the stateless DNS discovery mechanisms described in "IPv6
Stateless DNS Discovery" [DNSDisc] or "Using DHCPv6 for DNS
Esibov, Aboba & Thaler Standards Track [Page 8]
INTERNET-DRAFT LLMNR 20 July 2002
Configuration in Hosts" [DHCPv6DNS] can be used to discover whether
LLMNR should be enabled or disabled on a per-interface basis.
@ -472,18 +505,6 @@ DNS proxy within the home gateway to dynamically register names learned
via DHCPv6. As a result, unless the DNS proxy supports client update, it
will not be able to respond to AAAA RR queries for local names sent over
IPv4 or IPv6, preventing IPv6 hosts from resolving the names of other
Esibov, Aboba & Thaler Standards Track [Page 8]
INTERNET-DRAFT LLMNR 23 March 2002
IPv6 hosts on the local link. In this situation, LLMNR enables
resolution of dynamic names, and it will be enabled for use with IPv6,
even though it is disabled for use with IPv4.
@ -508,6 +529,21 @@ The sequence of events for LLMNR usage is as follows:
response. If not, then the sender ignores the response and continues
waiting for the response.
Esibov, Aboba & Thaler Standards Track [Page 9]
INTERNET-DRAFT LLMNR 20 July 2002
5. Conflict resolution
There are some scenarios when multiple responders MAY respond to the
@ -532,18 +568,6 @@ request AND includes a UNIQUE record in the response:
2. MUST NOT include a UNIQUE resource record in the
response without having verified its uniqueness.
Esibov, Aboba & Thaler Standards Track [Page 9]
INTERNET-DRAFT LLMNR 23 March 2002
Where a host is configured to respond to LLMNR queries on more than one
interface, the host MUST verify resource record uniqueness on each
interface for each UNIQUE resource record that could be used on that
@ -568,6 +592,18 @@ Zone section
The zone name in the zone section MUST be set to the name of the
UNIQUE record. The zone type in the zone section MUST be set to
SOA. The zone class in the zone section MUST be set to the class of
Esibov, Aboba & Thaler Standards Track [Page 10]
INTERNET-DRAFT LLMNR 20 July 2002
the UNIQUE record.
Prerequisite section
@ -592,18 +628,6 @@ request stating that a UNIQUE resource record does not exist, the host
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 and dynamic update requests. If not, then it MUST NOT
Esibov, Aboba & Thaler Standards Track [Page 10]
INTERNET-DRAFT LLMNR 23 March 2002
use the UNIQUE resource record in response to LLMNR queries and dynamic
update requests.
@ -628,6 +652,18 @@ active interfaces. In many situations this will be adequate. However,
should a host wish to configure LLMNR on more than one of its active
interfaces, there are some additional precautions it MUST take.
Implementers who are not planning to support LLMNR on multiple
Esibov, Aboba & Thaler Standards Track [Page 11]
INTERNET-DRAFT LLMNR 20 July 2002
interfaces simultaneously may skip this section.
A multi-homed host checks the uniqueness of UNIQUE records as described
@ -646,24 +682,6 @@ 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
"myhost" name on the interface on the left.
Esibov, Aboba & Thaler Standards Track [Page 11]
INTERNET-DRAFT LLMNR 23 March 2002
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
@ -688,6 +706,24 @@ 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.
Esibov, Aboba & Thaler Standards Track [Page 12]
INTERNET-DRAFT LLMNR 20 July 2002
Indeed, host myhost cannot distinguish between the situation shown in
Figure 2, and that shown in Figure 3 where no conflict exists:
@ -712,18 +748,6 @@ of uniqueness of names within DNS.
problem for applications written to use this API, since the sockaddr_in6
structure exposes the scope within which each scoped address exists, and
this structure can be used for both IPv4 (using v4-mapped IPv6
Esibov, Aboba & Thaler Standards Track [Page 12]
INTERNET-DRAFT LLMNR 23 March 2002
addresses) and IPv6 addresses.
Following the example in Figure 2, an application on 'myhost' issues the
@ -749,6 +773,17 @@ be misconfigured to answer an LLMNR query with incorrect information.
In order to address the security vulnerabilities, the following
mechanisms are contemplated:
Esibov, Aboba & Thaler Standards Track [Page 13]
INTERNET-DRAFT LLMNR 20 July 2002
[1] Scope restrictions.
[2] Usage restrictions.
@ -772,18 +807,6 @@ senders. In all received responses, the Hop Limit field in IPv6 and the
TTL field in IPv4 are verified to contain 255, the maximum legal value.
Since routers decrement the Hop Limit on all packets they forward,
received packets containing a Hop Limit of 255 must have originated from
Esibov, Aboba & Thaler Standards Track [Page 13]
INTERNET-DRAFT LLMNR 23 March 2002
a neighbor.
While restricting ignoring packets received from off-link senders
@ -809,6 +832,18 @@ updated. This implies that on the interface, the host will neither
listen on the LINKLOCAL multicast address, nor will it send queries to
that address.
Esibov, Aboba & Thaler Standards Track [Page 14]
INTERNET-DRAFT LLMNR 20 July 2002
Violation of this guideline can significantly increases security
vulnerabilities. For example, if an LLMNR query were to be sent
whenever a DNS server did not respond in a timely way, then an attacker
@ -830,20 +865,6 @@ configured. Where resilience against DNS server failure is desired,
configuration of additional DNS servers or DNS server clustering is
recommended; LLMNR is not an appropriate "failsafe" mechanism.
Esibov, Aboba & Thaler Standards Track [Page 14]
INTERNET-DRAFT LLMNR 23 March 2002
6.3. Cache and port separation
In order to prevent responses to LLMNR queries from polluting the DNS
@ -871,6 +892,18 @@ hosts.
This specification does not create any new name spaces for IANA
administration. Since it uses a port (5353) and link scope multicast
Esibov, Aboba & Thaler Standards Track [Page 15]
INTERNET-DRAFT LLMNR 20 July 2002
IPv4 address (224.0.0.251) previously allocated for use with LLMNR, no
additional IANA allocations are required.
@ -892,18 +925,6 @@ additional IANA allocations are required.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
Esibov, Aboba & Thaler Standards Track [Page 15]
INTERNET-DRAFT LLMNR 23 March 2002
[RFC2373] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
@ -931,6 +952,18 @@ INTERNET-DRAFT LLMNR 23 March 2002
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
Esibov, Aboba & Thaler Standards Track [Page 16]
INTERNET-DRAFT LLMNR 20 July 2002
October 1998.
[RFC2553] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
@ -953,17 +986,6 @@ INTERNET-DRAFT LLMNR 23 March 2002
draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-08.txt, July 2001.
Esibov, Aboba & Thaler Standards Track [Page 16]
INTERNET-DRAFT LLMNR 23 March 2002
Acknowledgments
This work builds upon original work done on multicast DNS by Bill
@ -990,28 +1012,6 @@ One Microsoft Way
Redmond, WA 98052
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
@ -1021,9 +1021,19 @@ Esibov, Aboba & Thaler Standards Track [Page 17]
INTERNET-DRAFT LLMNR 23 March 2002
INTERNET-DRAFT LLMNR 20 July 2002
EMail: bernarda@microsoft.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
@ -1062,16 +1072,6 @@ which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
@ -1081,15 +1081,15 @@ Esibov, Aboba & Thaler Standards Track [Page 18]
INTERNET-DRAFT LLMNR 23 March 2002
Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-10.txt>, and expires
October 22, 2002.
INTERNET-DRAFT LLMNR 20 July 2002
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
@ -1138,3 +1138,63 @@ October 22, 2002.
Esibov, Aboba & Thaler Standards Track [Page 19]
INTERNET-DRAFT LLMNR 20 July 2002
Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-11.txt>, and expires
February 22, 2003.
Esibov, Aboba & Thaler Standards Track [Page 20]