diff --git a/doc/draft/draft-ietf-dnsext-mdns-30.txt b/doc/draft/draft-ietf-dnsext-mdns-30.txt deleted file mode 100644 index 1537573911..0000000000 --- a/doc/draft/draft-ietf-dnsext-mdns-30.txt +++ /dev/null @@ -1,1868 +0,0 @@ -DNSEXT Working Group Levon Esibov -INTERNET-DRAFT Bernard Aboba -Category: Standards Track Dave Thaler - Microsoft -17 March 2004 - - - - Linklocal Multicast Name Resolution (LLMNR) - - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC 2026. - - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. - - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material -or to cite them other than as "work in progress." - - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt - - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. - - -Copyright Notice - - -Copyright (C) The Internet Society (2004). All Rights Reserved. - - -Abstract - - -Today, with the rise of home networking, there are an increasing number -of ad-hoc networks operating without a Domain Name System (DNS) server. -In order to allow name resolution in such environments, Link-Local -Multicast Name 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. - - -The goal of LLMNR is to enable name resolution in scenarios in which -conventional DNS name resolution is not possible. Since LLMNR only -operates on the local link, it cannot be considered a substitute for -DNS. - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 1] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -Table of Contents - - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 3 - 1.2 Terminology ..................................... 4 -2. Name resolution using LLMNR ........................... 4 - 2.1 LLMNR packet format ............................. 5 - 2.2 Sender behavior ................................. 8 - 2.3 Responder behavior .............................. 8 - 2.4 Unicast queries ................................. 10 - 2.5 Off-link detection .............................. 11 - 2.6 Responder responsibilities ...................... 12 - 2.7 Retransmission and jitter ....................... 12 - 2.8 DNS TTL ......................................... 13 - 2.9 Use of the authority and additional sections .... 13 -3. Usage model ........................................... 14 - 3.1 LLMNR configuration ............................. 15 -4. Conflict resolution ................................... 16 - 4.1 Considerations for multiple interfaces .......... 18 - 4.2 API issues ...................................... 19 -5. Security considerations ............................... 19 - 5.1 Scope restriction ............................... 20 - 5.2 Usage restriction ............................... 21 - 5.3 Cache and port separation ....................... 21 - 5.4 Authentication .................................. 22 -6. IANA considerations ................................... 22 -7. References ............................................ 22 - 7.1 Normative References ............................ 22 - 7.2 Informative References .......................... 23 -Acknowledgments .............................................. 24 -Authors' Addresses ........................................... 25 -Intellectual Property Statement .............................. 25 -Full Copyright Statement ..................................... 26 - - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 2] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -1. Introduction - - -This document discusses Link Local Multicast Name Resolution (LLMNR), -which utilizes the DNS packet format and supports all current and future -DNS formats, types and classes. LLMNR operates on a separate port from -the Domain Name System (DNS), with a distinct resolver cache. - - -The goal of LLMNR is to enable name resolution in scenarios in which -conventional DNS name resolution is not possible. These include -scenarios in which hosts are not configured with the address of a DNS -server, where configured DNS servers do not reply to a query, or where -they respond with errors, as described in Section 2. Since LLMNR only -operates on the local link, it cannot be considered a substitute for -DNS. - - -Link-scope multicast addresses are used to prevent propagation of LLMNR -traffic across routers, potentially flooding the network. LLMNR queries -can also be sent to a unicast address, as described in Section 2.4. - - -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 gateway, then the network is able to provide DNS server -configuration. Configuration issues are discussed in Section 3.1. - - -In the future, it may be desirable to consider use of multicast name -resolution with multicast scopes beyond the link-scope. This could -occur if LLMNR deployment is successful, the need for multicast name -resolution beyond the link-scope, or multicast routing becomes -ubiquitous. For example, expanded support for multicast name resolution -might be required for mobile ad-hoc networking scenarios, or where no -DNS server is available that is authoritative for the names of local -hosts, and can support dynamic DNS, such as in wireless hotspots. - - -Once we have experience in LLMNR deployment in terms of administrative -issues, usability and impact on the network, it will be possible to -reevaluate which multicast scopes are appropriate for use with multicast -name resolution. - - -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 -NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be - - - - -Esibov, Aboba & Thaler Standards Track [Page 3] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -interpreted as described in [RFC2119]. - - -1.2. Terminology - - -This document assumes familiarity with DNS terminology defined in -[RFC1035]. Other terminology used in this document includes: - - -Positively Resolved - Responses with RCODE set to zero are referred to in this document - as "positively resolved". - - -Routable Address - An address other than a Link-Local address. This includes globally - routable addresses, as well as private addresses. - - -Reachable - An address is considered reachable over a link if either an ARP or - neighbor discovery cache entry exists for the address on the link. - - -Responder - A host that listens to LLMNR queries, and responds to those for - which it is authoritative. - - -Sender - A host that sends an LLMNR query. - - -2. Name resolution using LLMNR - - -LLMNR is a peer-to-peer name resolution protocol that is not intended as -a replacement for DNS. LLMNR queries are sent to and received on port -TBD. IPv4 administratively scoped multicast usage is specified in -"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope -multicast address a given responder listens to, and to which a sender -sends queries, is TBD. The IPv6 link-scope multicast address a given -responder listens to, and to which a sender sends all queries, is TBD. - - -Typically a host is configured as both an LLMNR sender and a responder. -A host MAY be configured as a sender, but not a responder. However, a -host configured as a responder MUST act as a sender to verify the -uniqueness of names as described in Section 4. This document does not -specify how names are chosen or configured. This may occur via any -mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. - - -LLMNR usage MAY be configured manually or automatically on a per -interface basis. By default, LLMNR responders SHOULD be enabled on all -interfaces, at all times. Enabling LLMNR for use in situations where a -DNS server has been configured will result in a change in default -behavior without a simultaneous update to configuration information. - - - - -Esibov, Aboba & Thaler Standards Track [Page 4] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -Where this is considered undesirable, LLMNR SHOULD NOT be enabled by -default, so that hosts will neither listen on the link-scope multicast -address, nor will they send queries to that address. - - -An LLMNR sender may send a request for any name. However, by default, -LLMNR requests SHOULD be sent only when one of the following conditions -are met: - - -[1] No manual or automatic DNS configuration has been performed. If an - interface has been configured with DNS server address(es), then - LLMNR SHOULD NOT be used as the primary name resolution mechanism - on that interface, although it MAY be used as a name resolution - mechanism of last resort. - - -[2] DNS servers do not respond. - - -[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name - Error) or RCODE=0, and an empty answer section. - - -A typical sequence of events for LLMNR usage is as follows: - - -[a] DNS servers are not configured or do not respond to a DNS query, or - respond with RCODE=3, or RCODE=0 and an empty answer section. - - -[b] An LLMNR sender sends an LLMNR query to the link-scope multicast - address(es) defined in Section 2, unless a unicast query is - indicated. A sender SHOULD send LLMNR queries for PTR RRs via - unicast, as specified in Section 2.4. - - -[c] A responder responds to this query only if it is authoritative for - the domain name in the query. A responder responds to a multicast - query by sending a unicast UDP response to the sender. Unicast - queries are responded to as indicated in Section 2.4. - - -[d] Upon reception of the response, the sender processes it. - - -Further details of sender and responder behavior are provided in the -sections that follow. - - -2.1. LLMNR packet format - - -LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for -both queries and responses. LLMNR implementations SHOULD send UDP -queries and responses only as large as are known to be permissible -without causing fragmentation. When in doubt a maximum packet size of -512 octets SHOULD be used. LLMNR implementations MUST accept UDP -queries and responses as large as permitted by the link MTU. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -2.1.1. LLMNR header format - - -LLMNR queries and responses utilize the DNS header format defined in -[RFC1035] with exceptions noted below: - - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| ID | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -|QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| QDCOUNT | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| ANCOUNT | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| NSCOUNT | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| ARCOUNT | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - -where: - - -ID A 16 bit identifier assigned by the program that generates any kind - of query. This identifier is copied from the query to the response - and can be used by the sender to match responses to outstanding - queries. The ID field in a query SHOULD be set to a pseudo-random - value. - - -QR A one bit field that specifies whether this message is an LLMNR - query (0), or an LLMNR response (1). - - -OPCODE - A four bit field that specifies the kind of query in this message. - This value is set by the originator of a query and copied into the - response. This specification defines the behavior of standard - queries and responses (opcode value of zero). Future - specifications may define the use of other opcodes with LLMNR. - LLMNR senders and responders MUST support standard queries (opcode - value of zero). LLMNR queries with unsupported OPCODE values MUST - be silently discarded by responders. - - -TC TrunCation - specifies that this message was truncated due to - length greater than that permitted on the transmission channel. - The TC bit MUST NOT be set in an LLMNR query and if set is ignored - by an LLMNR responder. If the TC bit is set an LLMNR response, - then the sender MAY use the response if it contains all necessary - information, or the sender MAY discard the response and resend the - - - - -Esibov, Aboba & Thaler Standards Track [Page 6] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - - LLMNR query over TCP using the unicast address of the responder as - the destination address. See [RFC2181] and Section 2.4 of this - specification for further discussion of the TC bit. - - -Z Reserved for future use. Implementations of this specification - MUST set these bits to zero in both queries and responses. If - these bits are set in a LLMNR query or response, implementations of - this specification MUST ignore them. Since reserved bits could - conceivably be used for different purposes than in DNS, - implementors are advised not to enable processing of these bits in - an LLMNR implementation starting from a DNS code base. - - -RCODE - Response code -- this 4 bit field is set as part of LLMNR - responses. In an LLMNR query, the RCODE MUST be zero, and is - ignored by the responder. The response to a multicast LLMNR query - MUST have RCODE set to zero. A sender MUST silently discard an - LLMNR response with a non-zero RCODE sent in response to a - multicast query. - - - If an LLMNR responder is authoritative for the name in a multicast - query, but an error is encountered, the responder SHOULD send an - LLMNR response with an RCODE of zero, no RRs in the answer section, - and the TC bit set. This will cause the query to be resent using - TCP, and allow the inclusion of a non-zero RCODE in the response to - the TCP query. Responding with the TC bit set is preferrable to - not sending a response, since it enables errors to be diagnosed. - - - Since LLMNR responders only respond to LLMNR queries for names for - which they are authoritative, LLMNR responders MUST NOT respond - with an RCODE of 3; instead, they should not respond at all. - - - LLMNR implementations MUST support EDNS0 [RFC2671] and extended - RCODE values. - - -QDCOUNT - An unsigned 16 bit integer specifying the number of entries in the - question section. A sender MUST place only one question into the - question section of an LLMNR query. LLMNR responders MUST silently - discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders - MUST silently discard LLMNR responses with QDCOUNT not equal to - one. - - -ANCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the answer section. LLMNR responders MUST silently - discard LLMNR queries with ANCOUNT not equal to zero. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -NSCOUNT - An unsigned 16 bit integer specifying the number of name server - resource records in the authority records section. Authority - record section processing is described in Section 2.9. - - -ARCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the additional records section. Additional record - section processing is described in Section 2.9. - - -2.2. Sender behavior - - -A sender may send an LLMNR query for any legal resource record type -(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. - - -As described in Section 2.4, a sender may also send a unicast query. -Sections 2 and 3 describe the circumstances in which LLMNR queries may -be sent. - - -The sender MUST anticipate receiving no replies to some LLMNR queries, -in the event that no responders are available within the link-scope or -in the event no positive non-null responses 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 exist for the -specified name (it is treated the same as a response with RCODE=0 and an -empty answer section). - - -Since the responder may order the RRs in the response so as to indicate -preference, the sender SHOULD preserve ordering in the response to the -querying application. - - -2.3. Responder behavior - - -An LLMNR response MUST be sent to the sender via unicast. - - -Upon configuring an IP address responders typically will synthesize -corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR -queries for these RRs. An SOA RR is synthesized only when a responder -has another RR as well; the SOA RR MUST NOT be the only RR that a -responder has. However, in general whether RRs are manually or -automatically created is an implementation decision. - - -For example, a host configured to have computer name "host1" and to be a -member of the "example.com" domain, and with IPv4 address 10.1.1.1 and -IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the -following records: - - -host1. IN A 10.1.1.1 - - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - -host1.example.com. IN A 10.1.1.1 -IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - -1.1.1.10.in-addr.arpa. IN PTR host1. -IN PTR host1.example.com. - - -6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa -IN PTR host1. -IN PTR host1.example.com - - -An LLMNR responder might be further manually configured with the name of -a local mail server with an MX RR included in the "host1." and -"host1.example.com." records. - - -In responding to queries: - - -[a] Responders MUST listen on UDP port TBD on the link-scope multicast - address(es) defined in Section 2, and on UDP and TCP port TBD on - the unicast address(es) that could be set as the source address(es) - when the responder responds to the LLMNR query. - - -[b] Responders MUST direct responses to the port from which the query - was sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - responder MUST take note of the source port and use that as the - destination port in the response. Responses SHOULD always be sent - from the port to which they were directed. - - -[c] Responders MUST respond to LLMNR queries for names and addresses - they are authoritative for. This applies to both forward and - reverse lookups. - - -[d] Responders MUST NOT respond to LLMNR queries for names they are not - authoritative for. - - -[e] Responders MUST NOT respond using cached data. - - -[f] If a DNS server is running on a host that supports LLMNR, the DNS - server MUST respond to LLMNR queries only for the RRSets relating - to the host on which the server is running, but MUST NOT respond - for other records for which the server is authoritative. DNS - servers also MUST NOT send LLMNR queries in order to resolve DNS - queries. - - -[g] If a responder is authoritative for a name, it MAY respond with - RCODE=0 and an empty answer section, if the type of query does not - - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - - match a RR that the responder has. - - -As an example, a host configured to respond to LLMNR queries for the -name "foo.example.com." is authoritative for the name -"foo.example.com.". On receiving an LLMNR query for an A RR with the -name "foo.example.com." the host authoritatively responds with A RR(s) -that contain IP address(es) in the RDATA of the resource record. If the -responder has a AAAA RR, but no A RR, and an A RR query is received, the -responder would respond with RCODE=0 and an empty answer section. - - -In conventional DNS terminology a DNS server authoritative for a zone is -authoritative for all the domain names under the zone apex except for -the branches delegated into separate zones. Contrary to conventional -DNS terminology, an LLMNR responder is authoritative only for the zone -apex. - - -For example the host "foo.example.com." is not authoritative for the -name "child.foo.example.com." unless the host is configured with -multiple names, including "foo.example.com." and -"child.foo.example.com.". As a result, "foo.example.com." cannot reply -to an LLMNR query for "child.foo.example.com." with RCODE=3 -(authoritative name error). 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, -"foo.example.com." and "child.foo.example.com.". - - -In this example (unless this limitation is introduced) an LLMNR query -for an A resource record for the name "child.foo.example.com." would -result in two authoritative responses: RCODE=3 (authoritative name -error) received from "foo.example.com.", and a requested A record - from -"child.foo.example.com.". To prevent this ambiguity, LLMNR enabled -hosts could perform a dynamic update of the parent (or grandparent) zone -with a delegation to a child zone. In this example a host -"child.foo.example.com." would send a dynamic update for the NS and glue -A record to "foo.example.com.", but this approach significantly -complicates implementation of LLMNR and would not be acceptable for -lightweight hosts. - - -2.4. Unicast queries and responses - - -Unicast queries SHOULD be sent when: - - -[a] A sender repeats a query after it received a response with the TC - bit set to the previous LLMNR multicast query, or - - -[b] The sender queries for a PTR RR of a fully formed IP address within - the "in-addr.arpa" or "ip6.arpa" zones. - - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -A responder receiving a unicast query MUST send the response with a -source address set to the destination address field of the IP header of -the query causing the response. - - -Unicast LLMNR queries MUST be sent using TCP. Senders MUST support -sending TCP queries, and responders MUST support listening for TCP -queries. - - -Responses to TCP unicast LLMNR queries MUST be sent using TCP, using -the same connection as the query. If the sender of a TCP query receives -a response to that query not using TCP, the response MUST be silently -discarded. - - -Unicast UDP queries MUST be silently discarded. - - -If TCP connection setup cannot be completed in order to 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). - - -2.5. "Off link" detection - - -For IPv4, an "on link" address is defined as a link-local address -[IPv4Link] or an 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 local link. - - -A sender MUST select a source address for LLMNR queries that is "on -link". The destination address of an LLMNR query MUST be a link-scope -multicast address or an "on link" unicast address. - - -A responder MUST select a source address for responses that is "on -link". The destination address of an LLMNR response MUST be an "on link" -unicast address. - - -On receiving an LLMNR query, the responder MUST check whether it was -sent to a LLMNR multicast addresses defined in Section 2. If it was -sent to another multicast address, then the query MUST be silently -discarded. - - -Section 2.4 discusses use of TCP for LLMNR queries and responses. In -composing an LLMNR query using TCP, the sender MUST set the Hop Limit -field in the IPv6 header and the TTL field in the IPv4 header of the -response to one (1). 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 connection from off-link since the sender will not receive a - - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -SYN-ACK from the responder. - - -For UDP queries and responses the Hop Limit field in the IPv6 header, -and the TTL field in the IPV4 header MAY be set to any value. However, -it is RECOMMENDED that the value 255 be used for compatibility with -Apple Rendezvous. - - -Implementation note: - - - In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL - socket options are used to set the TTL of outgoing unicast and - multicast packets. The IP_RECVTTL socket option is available on some - platforms to retrieve the IPv4 TTL of received packets with - recvmsg(). [RFC2292] specifies similar options for setting and - retrieving the IPv6 Hop Limit. - - -2.6. Responder responsibilities - - -It is the responsibility of the responder to ensure that 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. In -particular: - - -[a] If a link-scope IPv6 address is returned in a AAAA RR, that address - MUST be valid on the local link over which LLMNR is used. - - -[b] If an IPv4 address is returned, it MUST be reachable through the - link over which LLMNR is used. - - -[c] If a name is returned (for example in a CNAME, MX or SRV RR), the - name MUST be resolvable on the local link over which LLMNR is used. - - -Routable addresses MUST be included first in the response, if available. -This encourages use of routable address(es) for establishment of new -connections. - - -2.7. Retransmission and jitter - - -An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine -when to retransmit an LLMNR query and how long to collect responses to -an LLMNR query. - - -If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, -then a sender MAY repeat the transmission of the query in order to -assure that it was received by a host capable of responding to it. -Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. -Where LLMNR queries are sent using TCP, retransmission is handled by the - - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -transport layer. - - -Because an LLMNR sender cannot know in advance if a query sent using -multicast will receive no response, one response, or more than one -response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect -all possible responses, rather than considering the multicast query -answered after the first response is received. A unicast query sender -considers the query answered after the first response is received, so -that it only waits for LLMNR_TIMEOUT if no response has been received. - - -An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT -for each transmission. It is suggested that the computation of -LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries -sent on the same interface. - - -For example, the algorithms described in RFC 2988 [RFC2988] (including -exponential backoff) compute an RTO, which is used as the value of -LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO -(discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO -(discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum -RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). - - -Recommended values are an initial RTO of 1 second, a minimum RTO of -200ms, and a maximum RTO of 5 seconds. In order to avoid -synchronization, the transmission of each LLMNR query and response -SHOULD delayed by a time randomly selected from the interval 0 to 100 -ms. This delay MAY be avoided by responders responding with RRs which -they have previously determined to be UNIQUE (see Section 4 for -details). - - -2.8. DNS TTL - - -The responder should use a pre-configured TTL value in the records -returned an LLMNR response. A default value of 30 seconds is -RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc -networks), the TTL value may need to be reduced. - - -Due to the TTL minimalization necessary when caching an RRset, all TTLs -in an RRset MUST be set to the same value. - - -2.9. Use of the authority and additional sections - - -Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a -concept of delegation. In LLMNR, the NS resource record type may be -stored and queried for like any other type, but it has no special -delegation semantics as it does in the DNS. Responders MAY have NS -records associated with the names for which they are authoritative, but -they SHOULD NOT include these NS records in the authority sections of - - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -responses. - - -Responders SHOULD insert an SOA record into the authority section of a -negative response, to facilitate negative caching as specified in -[RFC2308]. The owner name of this SOA record MUST be equal to the query -name. - - -Responders SHOULD NOT perform DNS additional section processing, except -as required for EDNS0 and DNSSEC. - - -Senders MUST NOT cache RRs from the authority or additional section of a -response as answers, though they may be used for other purposes such as -negative caching. - - -3. Usage model - - -Since LLMNR is a secondary name resolution mechanism, its usage is in -part determined by the behavior of DNS implementations. This document -does not specify any changes to DNS resolver behavior, such as -searchlist processing or retransmission/failover policy. However, -robust DNS resolver implementations are more likely to avoid unnecessary -LLMNR queries. - - -As noted in [DNSPerf], even when DNS servers are configured, a -significant fraction of DNS queries do not receive a response, or result -in negative responses due to missing inverse mappings or NS records that -point to nonexistent or inappropriate hosts. This has the potential to -result in a large number of unnecessary LLMNR queries. - - -[RFC1536] describes common DNS implementation errors and fixes. If the -proposed fixes are implemented, unnecessary LLMNR queries will be -reduced substantially, and so implementation of [RFC1536] is -recommended. - - -For example, [RFC1536] Section 1 describes issues with retransmission -and recommends implementation of a retransmission policy based on round -trip estimates, with exponential backoff. [RFC1536] Section 4 describes -issues with failover, and recommends that resolvers try another server -when they don't receive a response to a query. These policies are -likely to avoid unnecessary LLMNR queries. - - -[RFC1536] Section 3 describes zero answer bugs, which if addressed will -also reduce unnecessary LLMNR queries. - - -[RFC1536] Section 6 describes name error bugs and recommended searchlist -processing that will reduce unnecessary RCODE=3 (authoritative name) -errors, thereby also reducing unnecessary LLMNR queries. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -3.1. LLMNR configuration - - -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 [RFC3315] 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. - - -Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], -IPv6-only hosts may not be configured with a DNS server. Where there is -no DNS server authoritative for the name of a host or the authoritative -DNS server does not support dynamic client update over IPv6 or -DHCPv6-based dynamic update, then an IPv6-only host will not be able to -do DNS dynamic update, and other hosts will not be able to resolve its -name. - - -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 DNS server(s) exist which are authoritative for the A -RRs of local hosts and support either dynamic client update over IPv4 or -DHCPv4-based dynamic update, then the names of local IPv4 hosts can be -resolved over IPv4 without LLMNR. However, if no DNS server is -authoritative for the names of local hosts, or the authoritative DNS -server(s) do not support dynamic update, then LLMNR enables linklocal -name resolution 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 -on an interface. The LLMNR Enable Option does not determine whether or -in which order DNS itself is used for name resolution. The order in -which various name resolution mechanisms should be used can be specified -using the Name Service Search Option (NSSO) for DHCP [RFC2937], using -the LLMNR Enable Option code carried in the NSSO data. - - -It is possible that DNS configuration mechanisms will go in and out of - - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -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 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. -For example, where DHCP is used for DNS configuration, [RFC2131] -recommends a maximum retry interval of 64 seconds. In the absence of -other guidance, a default retry interval of one (1) minute is -RECOMMENDED. - - -4. Conflict resolution - - -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 -may first be concatenated, and then treated in the same manner that -multiple RRs received from the same DNS server would; the sender -perceives no inherent conflict in the receipt of multiple responses. - - -There are some scenarios when multiple responders MAY respond to the -same query. There are other scenarios when only one responder MAY -respond to a query. Resource records for which the latter queries are -submitted are referred as UNIQUE throughout this document. The -uniqueness of a resource record depends on a nature of the name in the -query and type of the query. For example it is expected that: - - - - multiple hosts may respond to a query for an SRV type record - - multiple hosts may respond to a query for an A or AAAA type - record for a cluster name (assigned to multiple hosts in - the cluster) - - only a single host may respond to a query for an A or AAAA - type record for a name. - - -Every responder that responds to an LLMNR query AND includes a UNIQUE -record in the response: - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -[1] MUST verify that there is no other host within the scope of the - LLMNR query propagation that can return a resource record for the - same name, type and class. - - -[2] MUST NOT include a UNIQUE resource record in the response without - having verified its uniqueness. - - -Where a host is configured to issue LLMNR queries on more than one -interface, each interface should have its own independent LLMNR cache. -For each UNIQUE resource record in a given interface's configuration, -the host MUST verify resource record uniqueness on that interface. To -accomplish this, the host MUST send an LLMNR query for each UNIQUE -resource record. - - -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 rebooted - - wakes from sleep (if the network interface was inactive during sleep) - - is configured to respond to the LLMNR queries on an interface - enabled for transmission and reception of IP traffic - - is configured to respond to the LLMNR queries using additional - UNIQUE resource records - - detects that an interface is connected and is usable - (e.g. an IEEE 802 hardware link-state change indicating - that a cable was attached or completion of authentication - (and if needed, association) with a wireless base station - or adhoc network - - -When a host that has 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 an interface different from -the one on which the query was sent. If the response arrives on a -different interface, 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 order -to minimize the chance of conflicts in such a situation, it is -recommended that steps be taken to ensure name uniqueness. For example, -the name could be chosen randomly from a large pool of potential names, -or the name could be assigned via a process designed to guarantee -uniqueness. - - -When name conflicts are detected, they SHOULD be logged. To detect -duplicate use of a name, an administrator can use a name resolution -utility which employs LLMNR and lists both responses and responders. - - - - -Esibov, Aboba & Thaler Standards Track [Page 17] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -This would allow an administrator to diagnose behavior and potentially -to intervene and reconfigure LLMNR responders who should not be -configured to respond to the same name. - - -4.1. Considerations for Multiple Interfaces - - -A multi-homed host may elect to configure LLMNR on only one of its -active interfaces. In many situations this will be adequate. However, -should a host need 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 -interfaces simultaneously may skip this section. - - -A multi-homed host checks the uniqueness of UNIQUE records as described -in Section 4. The situation is illustrated in figure 1. - - - ---------- ---------- - | | | | - [A] [myhost] [myhost] - - - Figure 1. Link-scope name conflict - - -In this situation, the multi-homed myhost will probe for, and defend, -its host name on both interfaces. A conflict will be detected on one -interface, but not the other. The multi-homed myhost will not be able -to 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. - - -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. - - - ---------- ---------- - | | | | - [A] [myhost] [A] - - - - Figure 2. Off-segment name conflict - - -If host myhost is configured to use LLMNR on both interfaces, it will -send LLMNR queries on both interfaces. When host myhost sends a query -for the host RR for name "A" it will receive a response from hosts on -both interfaces. - - -Host myhost cannot distinguish between the situation shown in Figure 2, - - - - -Esibov, Aboba & Thaler Standards Track [Page 18] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -and that shown in Figure 3 where no conflict exists. - - - [A] - | | - ----- ----- - | | - [myhost] - - - Figure 3. Multiple paths to same host - - -This illustrates that the proposed name conflict resolution mechanism -does not support detection or resolution of conflicts between hosts on -different links. This problem can also occur with unicast DNS when a -multi-homed host is connected to two different networks with separated -name spaces. It is not the intent of this document to address the issue -of uniqueness of names within DNS. - - -4.2. API issues - - -[RFC2553] provides an API which can partially solve the name ambiguity -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 -addresses) and IPv6 addresses. - - -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 -interfaces and the resolver library will return a list containing -multiple addrinfo structures, each with an associated sockaddr_in6 -structure. This list will thus contain the IPv4 and IPv6 addresses of -both hosts responding to the name 'A'. Link-local addresses will have a -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 -successfully with any address in the list. - - -5. Security Considerations - - -LLMNR is by nature a peer-to-peer name resolution protocol. It is -therefore inherently more vulnerable than DNS, since existing DNS -security mechanisms are difficult to apply to LLMNR. While tools exist -to alllow an attacker to spoof a response to a DNS query, spoofing a -response to an LLMNR query is easier since the query is sent to a link- -scope multicast address, where every host on the logical link will be -made aware of it. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 19] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -In order to address the security vulnerabilities, the following -mechanisms are contemplated: - - -[1] Scope restrictions. - - -[2] Usage restrictions. - - -[3] Cache and port separation. - - -[4] Authentication. - - -These techniques are described in the following sections. - - -5.1. Scope restriction - - -With LLMNR it is possible that hosts will allocate conflicting names for -a period of time, or that attackers will attempt to deny service to -other hosts by allocating the same name. Such attacks also allow hosts -to receive packets destined for other hosts. - - -Since LLMNR is typically deployed in situations where no trust model can -be assumed, it is likely that LLMNR queries and responses will be -unauthenticated. In the absence of authentication, LLMNR reduces the -exposure to such threats by utilizing UDP queries sent to a link-scope -multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) -fields to one (1) on TCP queries and responses. - - -Using a TTL of one (1) to set up a TCP connection in order to send a -unicast LLMNR query reduces the likelihood of both denial of service -attacks and spoofed responses. Checking that an LLMNR query is sent to -a link-scope multicast address should prevent spoofing of multicast -queries by off-link attackers. - - -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 or AAAA query for a popular Internet host), and by using a TTL -or Hop Limit field larger than one (1), for the forged response to reach -the LLMNR sender. - - -When LLMNR queries are sent to a link-scope multicast address, it is -possible that some routers may not properly implement link-scope -multicast, or that link-scope multicast addresses may leak into the -multicast routing system. - - -Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one -in an LLMNR UDP response may enable denial of service attacks across the -Internet. However, since LLMNR responders only respond to queries for - - - - -Esibov, Aboba & Thaler Standards Track [Page 20] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -which they are authoritative, and LLMNR does not provide wildcard query -support, it is believed that this threat is minimal. - - -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. - - -5.2. Usage restriction - - -As noted in Sections 2 and 3, LLMNR is intended for usage in a limited -set of scenarios. - - -If an LLMNR query is sent whenever a DNS server does not respond in a -timely way, then an attacker can poison the LLMNR cache by responding to -the query with incorrect information. To some extent, these -vulnerabilities exist today, since DNS response spoofing tools are -available that can allow an attacker to respond to a query more quickly -than a distant DNS server. - - -Since LLMNR queries are sent and responded to on the local-link, an -attacker will need to respond more quickly to provide its own response -prior to arrival of the response from a legitimate responder. If an -LLMNR query is sent for an off-link host, spoofing a response in a -timely way is not difficult, since a legitimate response will never be -received. - - -The vulnerability is more serious if LLMNR is given higher priority than -DNS among the enabled name resolution mechanisms. In such a -configuration, a denial of service attack on the DNS server would not be -necessary in order to poison the LLMNR cache, since LLMNR queries would -be sent even when the DNS server is available. In addition, the LLMNR -cache, once poisoned, would take precedence over the DNS cache, -eliminating the benefits of cache separation. As a result, LLMNR is only -used as a name resolution mechanism of last resort. - - -5.3. Cache and port separation - - -In order to prevent responses to LLMNR queries from polluting the DNS -cache, LLMNR implementations MUST use a distinct, isolated cache for -LLMNR on each interface. The use of separate caches is most effective -when LLMNR is used as a name resolution mechanism of last resort, since -this minimizes the opportunities for poisoning the LLMNR cache, and -decreases reliance on it. - - -LLMNR operates on a separate port from DNS, reducing the likelihood that - - - - -Esibov, Aboba & Thaler Standards Track [Page 21] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -a DNS server will unintentionally respond to an LLMNR query. - - -5.4. Authentication - - -LLMNR implementations may not support DNSSEC or TSIG, and as a result, -responses to LLMNR queries may be unauthenticated. If authentication is -desired, and a pre-arranged security configuration is possible, then -IPsec ESP with a null-transform MAY be used to authenticate LLMNR -responses. In a small network without a certificate authority, this can -be most easily accomplished through configuration of a group pre-shared -key for trusted hosts. - - -6. IANA Considerations - - -This specification creates one new name space: the reserved bits in the -LLMNR header. These are allocated by IETF Consensus, in accordance with -BCP 26 [RFC2434]. - - -LLMNR requires allocation of a port TBD for both TCP and UDP. -Assignment of the same port for both transports is requested. - - -LLMNR requires allocation of a link-scope multicast IPv4 address TBD. -LLMNR also requires allocation of a link-scope multicast IPv6 address -TBD. - - -7. References - - -7.1. Normative References - - -[RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. - - -[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - -[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - -[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - -[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - - -[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 22] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - -[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 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. - - -[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - -[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission - Timer", RFC 2988, November 2000. - - -7.2. Informative References - - -[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested - Fixes", RFC 1536, October 1993. - - -[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - -[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - -[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - - -[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic - Socket Interface Extensions for IPv6", RFC 2553, March 1999. - - -[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC - 2937, September 2000. - - -[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - - -[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of - Caching", IEEE/ACM Transactions on Networking, Volume 10, - Number 5, pp. 589, October 2002. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 23] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local - unicast addresses to communicate with recursive DNS servers", - Internet draft (work in progress), draft-ietf-ipv6-dns- - discovery-07.txt, October 2002. - - -[IPV4Link] - Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of IPv4 Link-Local Addresses", Internet draft (work in - progress), draft-ietf-zeroconf-ipv4-linklocal-14.txt, April - 2004. - - -[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December - 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin - - -[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. - - -Acknowledgments - - -This work builds upon original work done on multicast DNS by Bill -Manning and Bill Woodcock. Bill Manning's work was funded under DARPA -grant #F30602-99-1-0523. The authors gratefully acknowledge their -contribution to the current specification. Constructive input has also -been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert -Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron -Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van- -Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku -Savela. - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 24] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -Authors' Addresses - - -Levon Esibov -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 - - -EMail: levone@microsoft.com - - -Bernard Aboba -Microsoft Corporation -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 - - -Intellectual Property Statement - - -The IETF takes no position regarding the validity or scope of any -intellectual property or other rights that might be claimed to pertain -to the implementation or use of the technology described in this -document or the extent to which any license under such rights might or -might not be available; neither does it represent that it has made any -effort to identify any such rights. Information on the IETF's -procedures with respect to rights in standards-track and standards- -related documentation can be found in BCP-11. Copies of claims of -rights made available for publication and any assurances of licenses to -be made available, or the result of an attempt made to obtain a general -license or permission for the use of such proprietary rights by -implementors or users of this specification can be obtained from the -IETF Secretariat. - - -The IETF invites any interested party to bring to its attention any -copyrights, patents or patent applications, or other proprietary rights -which may cover technology that may be required to practice this -standard. Please address the information to the IETF Executive -Director. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 25] - - - - - - -INTERNET-DRAFT LLMNR 17 March 2004 - - - -Full Copyright Statement - - -Copyright (C) The Internet Society (2004). All Rights Reserved. -This document and translations of it may be copied and furnished to -others, and derivative works that comment on or otherwise explain it or -assist in its implementation may be prepared, copied, published and -distributed, in whole or in part, without restriction of any kind, -provided that the above copyright notice and this paragraph are included -on all such copies and derivative works. However, this document itself -may not be modified in any way, such as by removing the copyright notice -or references to the Internet Society or other Internet organizations, -except as needed for the purpose of developing Internet standards in -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. - - -Open Issues - - -Open issues with this specification are tracked on the following web -site: - - -http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html - - -Expiration Date - - -This memo is filed as , and expires -October 4, 2004. - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 26] \ No newline at end of file