diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt | 1559 |
1 files changed, 0 insertions, 1559 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt deleted file mode 100644 index 8dcacc8..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt +++ /dev/null @@ -1,1559 +0,0 @@ - - - - - - -DNSEXT Working Group Levon Esibov -INTERNET-DRAFT Bernard Aboba -Category: Standards Track Dave Thaler -<draft-ietf-dnsext-mdns-33.txt> Microsoft -18 July 2004 - - - Linklocal Multicast Name Resolution (LLMNR) - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - 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. - - This Internet-Draft will expire on January 2, 2005. - -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. The goal of Link-Local Multicast Name Resolution - (LLMNR) is to enable name resolution in scenarios in which - conventional DNS name resolution is not possible. 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. 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 18 July 2004 - - -Table of Contents - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 - 1.2 Terminology ..................................... 4 -2. Name resolution using LLMNR ........................... 4 - 2.1 LLMNR packet format ............................. 6 - 2.2 Sender behavior ................................. 8 - 2.3 Responder behavior .............................. 8 - 2.4 Unicast queries ................................. 11 - 2.5 Off-link detection .............................. 11 - 2.6 Responder responsibilities ...................... 12 - 2.7 Retransmission and jitter ....................... 13 - 2.8 DNS TTL ......................................... 13 - 2.9 Use of the authority and additional sections .... 14 -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 ............................... 20 - 5.1 Scope restriction ............................... 20 - 5.2 Usage restriction ............................... 21 - 5.3 Cache and port separation ....................... 22 - 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 -Disclaimer of Validity ....................................... 26 -Full Copyright Statement ..................................... 26 - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 2] - - - - - -INTERNET-DRAFT LLMNR 18 July 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 arises 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. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -1.1. Requirements - - In this document, several words are used to signify the requirements - of the specification. The key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - -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 5355. 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 224.0.0.252. The IPv6 link-scope multicast - address a given responder listens to, and to which a sender sends all - queries, is FF02:0:0:0:0:0:1:3. - - 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. - - - -Esibov, Aboba & Thaler Standards Track [Page 4] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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. 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. - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -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. - -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. - - - -Esibov, Aboba & Thaler Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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 - 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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. - -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 - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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 - 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 5355 on the link-scope multicast - address(es) defined in Section 2, and on UDP and TCP port 5355 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. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[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 - 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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. - - Unicast LLMNR queries MUST be done using TCP and the responses MUST - be sent using the same TCP connection as the query. Senders MUST - support sending TCP queries, and responders MUST support listening - for TCP queries. 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. - - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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 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. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -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 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. - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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. - -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 - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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 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. - - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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: - - [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, - - - -Esibov, Aboba & Thaler Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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. - 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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, 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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. - - 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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 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, - - - -Esibov, Aboba & Thaler Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - 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 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 port 5355 for both TCP and UDP. - - LLMNR requires allocation of link-scope multicast IPv4 address - 224.0.0.252, as well as link-scope multicast IPv6 address - FF02:0:0:0:0:0:1:3. - -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. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[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. - -[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. - - - -Esibov, Aboba & Thaler Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[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. - -[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-15.txt, May - 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 18 July 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 18 July 2004 - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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. - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - -Open Issues - - Open issues with this specification are tracked on the following web - site: - - http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 26] - |
