From ea6695989cfe6d606225be32caf8b081ab8fd1eb Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 25 Jul 2002 14:45:16 +0000 Subject: [PATCH] new draft --- ...s-10.txt => draft-ietf-dnsext-mdns-11.txt} | 596 ++++++++++-------- 1 file changed, 328 insertions(+), 268 deletions(-) rename doc/draft/{draft-ietf-dnsext-mdns-10.txt => draft-ietf-dnsext-mdns-11.txt} (86%) diff --git a/doc/draft/draft-ietf-dnsext-mdns-10.txt b/doc/draft/draft-ietf-dnsext-mdns-11.txt similarity index 86% rename from doc/draft/draft-ietf-dnsext-mdns-10.txt rename to doc/draft/draft-ietf-dnsext-mdns-11.txt index dcf25c7ebb..207944aece 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-10.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-11.txt @@ -7,8 +7,8 @@ DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -23 March 2002 + 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 , 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 , and expires +February 22, 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 20] + +