new draft

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
-<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)
@@ -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
+   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
 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
+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
 (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
+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
 (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
+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
 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
+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
-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
 
 
 
@@ -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
+INTERNET-DRAFT                    LLMNR                     20 July 2002
-
-
-Expiration Date
-
-This memo is filed as <draft-ietf-dnsext-mdns-10.txt>,  and  expires
-October 22, 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]
+
+