From: Mark Andrews Date: Tue, 8 Jan 2002 21:45:39 +0000 (+0000) Subject: new rev X-Git-Tag: v9.0.1^2~8651 X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=21143c2afa8a420ca32ec7c4136a1d54a59c1c4d;p=thirdparty%2Fbind9.git new rev --- diff --git a/doc/draft/draft-ietf-dnsext-mdns-07.txt b/doc/draft/draft-ietf-dnsext-mdns-07.txt deleted file mode 100644 index 1a7eb5c41a4..00000000000 --- a/doc/draft/draft-ietf-dnsext-mdns-07.txt +++ /dev/null @@ -1,1080 +0,0 @@ - - - - - - -DNSEXT Working Group Levon Esibov -INTERNET-DRAFT Bernard Aboba -Category: Standards Track Dave Thaler - Microsoft -15 November 2001 - - - Multicast DNS - -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 (2001). All Rights Reserved. - -Abstract - -Today, with the rise of home networking, there are an increasing number -of ad-hoc networks operating without a DNS server. In order to allow DNS -name resolution in such environments, the use of a multicast DNS is -proposed. - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 1] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -Table of Contents - -1. Introduction .......................................... 3 -2. Name resolution using multicast DNS ................... 3 - 2.1 Behavior of the sender and responder ............ 4 -3. Usage model ........................................... 7 - 3.1 mDNS configuration .............................. 8 -4. Sequence of events .................................... 9 -5. Conflict resolution ................................... 9 - 5.1 Considerations for multiple interfaces .......... 11 - 5.2 API issues ...................................... 12 -6. IANA considerations ................................... 13 -7. ARPA domain considerations ............................ 13 -8. References ............................................ 14 -9. Security considerations ............................... 15 -Acknowledgments .............................................. 16 -Authors' Addresses ........................................... 16 -Intellectual Property Statement .............................. 16 -Full Copyright Statement ..................................... 17 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 2] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -1. Introduction - -Multicast DNS enables DNS name resolution in the scenarios when -conventional DNS name resolution is not possible. Namely, when there are -no DNS servers available on the network or available DNS servers do not -provide name resolution for the names of the hosts on the local network. -The latter case, for example, corresponds to a scenario when a network -that doesn't have a DNS server is connected to the Internet through an -ISP and the network hosts are configured with the ISP's DNS server for -the name resolution. The ISP's DNS server provides the name resolution -for the names registered on the Internet, but doesn't provide name -resolution for the names of the hosts on the network. - -This document discusses multicast DNS, an extension to the DNS protocol -which consists of a single change to the method of use, and no change to -the format of DNS packets. - -Service discovery in general as well as discovery of DNS servers using -mDNS in particular is outside of the scope of this document, as is name -resolution over non-multicast capable media. - -In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", -"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as -described in RFC 2119 [1]. - -2. Name resolution using Multicast DNS - -This extension to the DNS protocol consists of a single change to the -method of use, and no change to the current format of DNS packets, It -allows multicast DNS queries to be sent to and received on port 53 using -a LINKLOCAL address as specified in "Administratively Scoped IP -Multicast" [2] for IPv4 and the "solicited name" LINKLOCAL multicast -addresses for IPv6. The mDNS LINKLOCAL address to be used for IPv4 is -. LINKLOCAL addresses are used to prevent propagation of multicast -DNS traffic across routers, potentially flooding the network. - -Propagation of multicast DNS packets on the local link is considered -sufficient to enable DNS name resolution in small adhoc networks. The -assumption is that if a network has a router, then the network either -has a DNS server or the router can function as a DNS proxy. - -By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers -can provide name resolution for the names of IPv4 hosts on the local -network. Where all IPv6 hosts also support IPv4, and the DNS proxy -supports AAAA RRs, resolution for the names of dual stack IPv6 hosts on -the local network can also be provided using this mechanism. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 3] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -Within small adhoc IPv6 networks, stateful autoconfiguration is the most -likely configuration mechanism. If DHCPv6 is not present, then in order -to support resolution of names of IPv6-only hosts on the local network, -the DNS proxy will need to support dynamic client update as well as DNS -over IPv6. - -Given the above mechanisms enabling DNS name resolution in small -networks with a router, it is assumed that multicast DNS need not be -enabled by default. - -In the future, mDNS may be defined to support greater than LINKLOCAL -multicast scope. This would occur if LINKLOCAL mDNS deployment is -successful, the assumption that mDNS is not needed on multiple links -proves incorrect, and multicast routing becomes ubiquitous. For -example, it is not clear that this assumption will be valid in large -adhoc networking scenarios. - -Once we have experience in mDNS deployment in terms of administrative -issues, usability and impact on the network it will be possible -reevaluate which multicast scopes are appropriate for use with mDNS. - -2.1. Behavior of the sender and responder - -For the purpose of this document a host that sends a multicast query is -called a "sender", while a host that listens to (but not necessarily -responds to) a multicast query is called "responder". A host configured -to be a "responder" may also be a "sender". A host configured to not be -a "responder" cannot be a "sender". - -2.1.1. Behavior of senders - -A sender sends multicast DNS query for any legal Type of resource record -(e.g. A, PTR, etc.) for a name within the ".local.arpa." domain to the -LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a -responder receives a query with the header containing RD set bit, the -responder MUST ignore the RD bit. - -The IPv6 LINKLOCAL address a given responder listens to, and to which a -sender sends, is a link-local multicast address formed as follows: The -name of the resource record in question is expressed in its canonical -form (see RFC 2535 [15], section 8.1), which is uncompressed with all -alphabetic characters in lower case. The first label of the resource -record name is then hashed using the MD5 algorithm (see RFC 1321 [16]). -The first 32 bits of the resultant 128-bit hash is then appended to the -prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name -multicast address". (Note: this procedure is intended to be the same as -that specified in section 3 of "IPv6 Node Information Queries" [14]). A -responder that listens for queries for multiple names will necessarily - - - -Esibov, Aboba & Thaler Standards Track [Page 4] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -listen to multiple of these solicited name multicast addresses. - -If the multicast query is not positively resolved ("positively resolved" -refers in this document to a response with the RCODE set to 0) during a -limited amount of time, then a sender MAY repeat the transmission of a -query in order to assure themselves that the query has been received by -a host capable of responding to the query. - -Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be -repeated more often than once per second to reduce unnecessary network -traffic. The delay between attempts should be randomized so as to avoid -synchronization effects. - -2.1.2. Behavior of responders - -A responder listens on port 53 on the LINKLOCAL address. Responders -MUST respond to multicast queries to those and only those names for -which they are authoritative. As an example, computer -"host.example.com.local.arpa." is authoritative for the domain -"host.example.com.local.arpa.". On receiving a multicast DNS A record -query for the name "host.example.com.local.arpa." such a host responds -with A record(s) that contain IP address(es) in the RDATA of the record. - -In conventional DNS terminology a DNS server authoritative for a zone is -authoritative for all the domain names under the zone root except for -the branches delegated into separate zones. Contrary to conventional DNS -terminology, a responder is authoritative only for the zone root. For -example the host "host.example.com.local.arpa." is not authoritative for -the name "child.host.example.com.local.arpa." unless the host is -configured with multiple names, including "host.example.com.local.arpa." -and "child.host.example.com.local.arpa.". The purpose of limiting the -name authority scope of a responder is to prevent complications that -could be caused by coexistence of two or more hosts with the names -representing child and parent (or grandparent) nodes in the DNS tree, -for example, "host.example.com.local.arpa." and -"child.host.example.com.local.arpa.". - -In this example (unless this limitation is introduced) a multicast query -for an A record for the name "child.host.example.com.local.arpa." would -result in two authoritative responses: name error received from -"host.example.com.local.arpa.", and a requested A record - from -"child.host.example.com.local.arpa.". To prevent this ambiguity, -multicast 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.host.example.com.local.arpa." would send a dynamic update -for the NS and glue A record to "host.example.com.local.arpa.", but this -approach significantly complicates implementation of multicast DNS and -would not be acceptable for lightweight hosts. - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -A response to a multicast query is composed in exactly the same manner -as a response to the unicast DNS query as specified in RFC 1035 [4]. -Responders MUST never respond using cached data, and the AA -(Authoritative Answer) bit MUST be set. The response is sent to the -sender via unicast. A response to an mDNS query MUST have RCODE set to -zero. mDNS responders may respond only to queries which they can resolve -positively. - -If a TC (truncation) bit is set in the response, then the sender MAY use -the response if it contains all necessary information, or the sender MAY -discard the response and resend the query over TCP or using EDNS0 with -larger window using the unicast address of the responder. The RA -(Recursion Available) bit in the header of the response MUST NOT be set. -Even if the RA bit is set in the response header, the sender MUST ignore -it. - -2.1.3. mDNS addressing - -For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of -IPv4 Link-Local Addresses" [18] lays out the rules with respect to -source address selection, TTL settings, and acceptable -source/destination address combinations. IPv6 LINKLOCAL addressing is -described in RFC 2373 [9]. mDNS queries and responses MUST obey the -rules laid out in these documents. - -In composing an mDNS response, the responder MUST set the Hop Limit -field in the IPv6 header and the TTL field in IPv4 header of the -multicast DNS response to 255. The sender MUST verify that the Hop Limit -field in IPv6 header and TTL field in IPv4 header of each response to -the multicast DNS query is set to 255. If it is not, then sender MUST -ignore the response. - - Implementation note: - - In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket - options are used to specify the TTL of outgoing unicast and multicast - packets. The IP_RECVTTL socket option is available on some platforms - to receive the IPv4 TTL of received packets with recvmsg(). RFC 2292 - [20] specifies similar options for specifying and receiving the IPv6 - Hop Limit. - -2.1.4. Use of DNS TTL - -The responder should use a pre-configured TTL value in the records -returned in the multicast DNS query response. Due to the TTL -minimalization necessary when caching an RRset, all TTLs in an RRset -MUST be set to the same value. In the additional and authority section -of the response the responder includes the same records as a DNS server - - - -Esibov, Aboba & Thaler Standards Track [Page 6] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -would insert in the response to the unicast DNS query. - -2.1.5. No/multiple responses - -The sender MUST anticipate receiving no replies to some multicast -queries, in the event that no responders are available within the -multicast scope, or in the event that 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 for the specified name -exist (NXRRSET). - -The sender MUST anticipate receiving multiple replies to the same -multicast query, in the event that several multicast DNS 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, -ordinarily. - -3. Usage model - -A host configured to be an mDNS "responder" MUST also be configured as a -"sender". A host not configured as a "responder" MUST NOT be a "sender". - -Multicast DNS usage is determined by special treatment of the -".local.arpa." namespace. The sender treats queries for ".local.arpa." -as a special case. A sender MUST NOT send a unicast query for names -ending with the ".local.arpa." suffix except when: - - a. A sender repeats a query after it received a response - to the previous multicast query with the TC bit set, or - - b. The sender's cache contains an NS resource record that enables - the sender to send a query directly to the hosts - authoritative for the name in the query. - -It is not expected that a host named "host.example.com." will be -manually configured to have the additional name -"host.example.com.local.arpa." when it is configured to use multicast -DNS. Instead, a responder with a name "host.example.com." configured -with ".local.arpa." suffix in its domain search configuration is -authoritative for the name "host.example.com.local.arpa.". For example, -when a responder with the name "host.example.com." receives an A type -query for the name "host.example.com.local.arpa." it authoritatively -responds to the query. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -The same host MAY use multicast DNS queries for the resolution of names -ending with ".local.arpa.", and unicast DNS queries for resolution of -all other names. When a user or application requests a DNS client to -resolve a dot-terminated name that contains a ".local.arpa" suffix, the -query for such a name MUST be multicast and the name SHOULD NOT be -concatenated with any suffix. - -If a DNS server is running on a host, then responder MUST NOT listen for -the multicast DNS queries on the same IP addresses on which the DNS -server listens, since otherwise they would intercept DNS queries -directed to a DNS server. The DNS server MUST respond to the multicast -DNS queries only for the RRSets owned by the host on which the server is -running, but MUST NOT respond for the records for which the server is -authoritative. - -3.1. mDNS configuration - -Multicast DNS usage can be configured manually or automatically. On -interfaces where no manual or automatic configuration has been performed -for a given protocol (IPv4 or IPv6), multicast DNS SHOULD be enabled by -default for that protocol. - -For IPv6, the stateless DNS discovery mechanisms described in "IPv6 -Stateless DNS Discovery" [19] can be used to discover whether multicast -DNS should be enabled or disabled on a per-interface basis. - -Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to -configure multicast DNS on an interface. The mDNS Enable Option, -described in [6], can be used to explicitly enable or disable use of -multicast DNS on an interface for a given protocol, as well as to -specify the order in which DNS and multicast DNS is used on that -interface. - -The mDNS Enable Option affects only DNS resolver behavior, that is, how -DNS resolution is performed, and whether multicast DNS is used. The -mDNS Enable Option does not determine whether or in which order DNS -itself is used for name resolution. This can be specified, for example, -using the Name Service Search Option for DHCP, RFC 2937 [3], which can -be used to globally determine where DNS is used within the name service -search order. - -If an interface has been configured for a given protocol via any -automatic configuration mechanism which is able to supply DNS -configuration information, then multicast DNS SHOULD NOT be used on that -interface for that protocol unless it has been explicitly enabled, -whether via that mechanism or any other. This ensures that upgraded -hosts do not change their default behavior, without requiring the source -of the configuration information to be simultaneously updated. This - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -implies that on the interface, the host will neither listen on the DNS -LINKLOCAL multicast address, nor will it send queries to that address. - -Note that it is possible for mDNS to be enabled for use with IPv6 at the -same time it is disabled for IPv4, and vice versa. For example, where a -home gateway implements a DNS proxy and DHCPv4, but not DHCPv6 or DNS -autoconfiguration, there may be no mechanism for allowing IPv6 hosts to -resolve the names of other IPv6 hosts on the home network. In this -situation, mDNS is useful for resolution of dynamic names, and it will -be enabled for use with IPv6, even though it is disabled for use with -IPv4. - -4. Sequence of events - -The sequence of events for multicast DNS usage is as follows: - -1. If a sender needs to resolve a query for a name - "host.example.com.local.arpa", then it sends a multicast query to the - LINKLOCAL multicast address. - -2. A responder responds to this query only if it is authoritative - for the domain name "host.example.com.local.arpa". The responder sends - a response to the sender via unicast over UDP. - -3. Upon the reception of the response, the sender verifies that the Hop - Limit field in IPv6 header or TTL field in IPv4 header (depending on - the protocol used) of the response is set to 255. The sender then - verifies compliance with the addressing requirements for IPv4, - described in [18], and IPv6, described in RFC 2373 [9]. If these - conditions are met, then the sender uses and caches the returned - response. If not, then the sender ignores the response and continues - waiting for the response. - -5. Conflict resolution - -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 a SRV type record - - multiple hosts may respond to a query for an A 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 type record for - a hostname. - - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -Every responder that responds to a multicast DNS query and/or dynamic -update request AND includes a UNIQUE record in the response: - - 1. MUST verify that there is no other host within the scope of the - multicast DNS query propagation that can return a DNS 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 respond to multicast DNS queries on more -than one interface, the host MUST verify resource record uniqueness on -each interface for each UNIQUE resource record that could be used on -that interface. To accomplish this, the host MUST multicast a dynamic -DNS update request as specified in RFC 2136 [11] for each new UNIQUE -resource record. Uniqueness verification is carried out when the host: - - - starts up or - - is configured to respond to the multicast DNS queries on - some interface or - - is configured to respond to the multicast DNS queries using - additional UNIQUE DNS records. - -Below we describe the data to be specified in the dynamic update -request: - -Header section - contains values according to RFC 2136 [11]. - -Zone section - The zone name in the zone section MUST be set to the name of the - UNIQUE record. The zone type in the zone section MUST be set to - SOA. The zone class in the zone section MUST be set to the class of - the UNIQUE record. - -Prerequisite section - This section MUST contain a record set whose semantics are - described in RFC 2136 [11], Section 2.4.3 "RRset Does Not Exist", - requesting that RRs with the NAME and TYPE of the UNIQUE record do - not exist. - -Update section - This section MUST be left empty. - -Additional section - This section is set according to RFC 2136. - -When a host that owns a UNIQUE record receives a dynamic update request -that requests that the UNIQUE resource record set does not exist, the - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -host MUST respond via unicast with the YXRRSET error, according to the -rules described in Section 3 of RFC 2136 [11]. - -After client receives an YXRRSET response to its dynamic update request -that a UNIQUE resource record does not exist, the host MUST check -whether the response arrived on another interface. If this is the case, -then the client can use the UNIQUE resource record in response to -multicast queries and dynamic update requests. If not, then it MUST NOT -use the UNIQUE resource record in response to multicast queries and -dynamic update requests. - -Note that this name conflict detection mechanism doesn't prevent name -conflicts when previously partitioned segments are connected by a -bridge. In such a situation, name conflicts are detected when a sender -receives more than one response to its multicast DNS query. In this -case, the sender sends the first response that it received to all -responders that responded to this query except the first one, using -unicast. A host that receives a query response containing a UNIQUE -resource record that it owns, even if it didn't send such a query, MUST -verify that no other host within the multicast DNS scope is -authoritative for the same name, using the dynamic DNS update request -mechanism described above. - -Based on the result, the host detects whether there is a name conflict -and acts as described above. - -5.1. Considerations for Multiple Interfaces - -A multi-homed host may elect to configure multicast DNS on only one of -its active interfaces. In many situations this will be adequate. -However, should a host wish to configure multicast DNS on more than one -of its active interfaces, there are some additional precautions it MUST -take. Implementers who are not planning to support multicast DNS on -multiple interfaces simultaneously may skip this section. - -A multi-homed host checks the uniqueness of UNIQUE records as described -in Section 5. The situation is illustrated in figure 1 below: - - ---------- ---------- - | | | | - [A] [myhost] [myhost] - - Figure 1. LINKLOCAL 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -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 mDNS 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 below. - - ---------- ---------- - | | | | - [A] [myhost] [A] - - - Figure 2. Off-segment name conflict - -If host myhost is configured to use mDNS on both interfaces, it will -send mDNS 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 will then forward a response from the -first responder to the second responder, who will attempt to verify the -uniqueness of host RR for its name, but will not discover a conflict, -since the conflicting host resides on a different link. Therefore it -will continue using its name. - -Indeed, 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. - -5.2. API issues - -RFC 2553 [13] provides an API which can partially solve the name -ambiguity problem for applications written to use this API, since the - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -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. mDNS 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. - -6. IANA Considerations - -This specification requires allocation of a link scope IPv4 multicast -addresses for use by multicast DNS. - -7. ARPA domain considerations - -This document specifies the use of a new sub-domain of the "ARPA" -domain. According to Section 2.1 of the ARPA Guidelines [12], this -specification requires description and justification. - -The 'local.arpa' domain is used to distinguish a local namespace. This -namespace differs from others in the following respects: - - - Name servers responding to requests for names in this - domain have different rules concerning authority. As - explained in Section 2.1, mDNS servers have limited - scope of authority, not extending to sub-domains of - domain they are authoritative for. - - - DNS servers SHOULD NOT forward or recursively resolve - queries for domain names in the local.arpa domain - if the - server cannot answer the query from its own database, - it MUST NOT reply. - - - Hosts may derive their own names in this namespace, - independent of centralized authorization and registration - (as defined in section 3 and section 5). - - - There is no delegation or administrative structure to - sub-domains of '.local.arpa'. - - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -How protocol objects are mapped into lookup keys: - - Names are associated with resources which can be requested - according to the DNS protocol. However, recursive lookup - is impossible. Further, mDNS specifies only the use of - multicast to transmit these requests. - -8. References - -[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - -[2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - -[3] Smith, C., "The Name Service Search Option for DHCP", RFC 2937, - September 2000. - -[4] Mockapetris, P., "Domain Names - Implementation and Specification", - RFC 1035, November 1987. - -[5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC - 1034, November, 1987. - -[6] Guttman, E., "DHCP mDNS Enable Option", Internet draft (work in - progress), draft-guttman-mdns-enable-01.txt, July 2001. - -[7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - -[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460, December 1998. - -[9] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", - RFC 2373, July 1998. - -[10] Information technology - Telecommunications and information - exchange between systems - Local and metropolitan area networks - - Specific Requirements Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) Specifications, IEEE Std. - 802.11-1997, 1997. - -[11] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in - the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. - -[12] Huston, G., "Management Guidelines & Operational Requirements for - the Internet Infrastructure Domain ("ARPA")", Internet draft (work - in progress), draft-iab-arpa-03.txt, July 2001. - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -[13] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic Socket - Interface Extensions for IPv6", RFC 2553, March 1999. - -[14] Crawford, Matt, "IPv6 Node Information Queries", Internet draft - (work in progress), draft-ietf-ipn-gwg-icmp-name-lookups-07.txt, - August 2000. - -[15] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, - March 1999. - -[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April - 1992. - -[17] Aboba, B., "DHCP Domain Search Option", Internet draft (work in - progress), draft-aboba-dhc-domsearch-08.txt, November 2001. - -[18] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local - Addresses", Internet draft (work in progress), draft-ietf-zeroconf- - ipv4-linklocal-05.txt, November 2001. - -[19] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", Internet - draft (work in progress), draft-ietf-ipngwg-dns-discovery-02.txt, - July 2001. - -[20] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", RFC 2292, - February 1998. - -9. Security Considerations - -This draft does not prescribe a means of securing the multicast DNS -mechanism. It is possible that hosts will allocate conflicting names for -a period of time, or that non-conforming hosts will attempt to deny -service to other hosts by allocating the same name. Such attacks also -allow nodes to receive packets destined for other nodes. The protocol -reduces the exposure to such threats in the absence of authentication by -ignoring multicast DNS query response packets received from off-link -senders. - -In all received responses, the Hop Limit field in IPv6 and the TTL field -in IPv4 are verified to contain 255, the maximum legal value. Since -routers decrement the Hop Limit on all packets they forward, received -packets containing a Hop Limit of 255 must have originated from a -neighbor. - -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 will serve to secure mDNS against the above threats - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -if it is available. For example, where 802.11 "Wired Equivalency -Privacy" (WEP) [10] is implemented, a casual attacker is likely to be -deterred from gaining access to the home network. - -The mechanism specified in this draft does not require use of DNSSEC. -As a result, responses to multicast DNS queries MAY NOT be -authenticated. If a network contains a "signed key distribution center" -for some of the DNS zones that the responders are authoritative for, and -senders on that network are configured with the key for the top zone -"local.arpa." (hosted by "signed keys distribution center"), then -senders MAY authenticate the responses using DNSSEC. - -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, Robert Elz, James -Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten, -Erik Nordmark, Sander Van-Valkenburg and Tomohide Nagashima. - -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 936 6605 -EMail: bernarda@microsoft.com - -Dave Thaler -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 - -Phone: +1 425 703 8835 -EMail: dthaler@microsoft.com - - - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -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. - -Full Copyright Statement - -Copyright (C) The Internet Society (2001). 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." - -Expiration Date - - - - - -Esibov, Aboba & Thaler Standards Track [Page 17] - - - - - -INTERNET-DRAFT Multicast DNS 15 November 2001 - - -This memo is filed as , and expires May -22, 2002. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 18] - - diff --git a/doc/draft/draft-ietf-dnsext-mdns-08.txt b/doc/draft/draft-ietf-dnsext-mdns-08.txt new file mode 100644 index 00000000000..5a40bcf3b5a --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-08.txt @@ -0,0 +1,1020 @@ + + + + + + +DNSEXT Working Group Levon Esibov +INTERNET-DRAFT Bernard Aboba +Category: Standards Track Dave Thaler + Microsoft +21 December 2001 + + + Linklocal Multicast DNS (LMDNS) + +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 (2001). All Rights Reserved. + +Abstract + +Today, with the rise of home networking, there are an increasing number +of ad-hoc networks operating without a DNS server. In order to allow +name resolution in such environments, Linklocal Multicast DNS (LMDNS) is +proposed. + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 1] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +Table of Contents + +1. Introduction .......................................... 3 +2. Name resolution using LMDNS ........................... 3 + 2.1 Behavior of the sender and responder ............ 4 +3. Usage model ........................................... 7 + 3.1 LMDNS configuration ............................. 8 +4. Sequence of events .................................... 9 +5. Conflict resolution ................................... 9 + 5.1 Considerations for multiple interfaces .......... 11 + 5.2 API issues ...................................... 12 +6. Security considerations ............................... 13 +7. IANA considerations ................................... 14 +8. Normative References .................................. 14 +9. Informative References ................................ 14 +Acknowledgments .............................................. 15 +Authors' Addresses ........................................... 15 +Intellectual Property Statement .............................. 16 +Full Copyright Statement ..................................... 16 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 2] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +1. Introduction + +Linklocal Multicast DNS (LMDNS) enables name resolution in the scenarios +when conventional DNS name resolution is not possible. Namely, when +there are no DNS servers available on the network or available DNS +servers do not provide name resolution for the names of the hosts on the +local network. The latter case, for example, corresponds to a scenario +when a network that doesn't have a DNS server is connected to the +Internet through an ISP and the network hosts are configured with the +ISP's DNS server for the name resolution. The ISP's DNS server provides +the name resolution for the names registered on the Internet, but +doesn't provide name resolution for the names of the hosts on the +network. + +This document discusses Linklocal Multicast DNS (LMDNS), which operates +on a separate port from DNS, with a distinct resolver cache, but does +not change the format of DNS packets. + +Service discovery in general, as well as discovery of DNS servers using +LMDNS in particular is outside of the scope of this document, as is name +resolution over non-multicast capable media. + +In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", +"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as +described in [RFC2119]. + +2. Name resolution using LMDNS + +While operating on a different port with a distinct resolver cache, +LMDNS makes no change to the current format of DNS packets. + +Linklocal multicast DNS queries are sent to and received on port 5353 +using a LINKLOCAL address as specified in "Administratively Scoped IP +Multicast" [RFC2365] for IPv4 and the "solicited name" LINKLOCAL +multicast addresses for IPv6. The LMDNS LINKLOCAL address to be used +for IPv4 is 224.0.0.251. LINKLOCAL addresses are used to prevent +propagation of LMDNS traffic across routers, potentially flooding the +network. + +Propagation of multicast DNS packets on the local link is considered +sufficient to enable name resolution in small adhoc networks. The +assumption is that if a network has a router, then the network either +has a DNS server or the router can function as a DNS proxy. + +By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers +can provide name resolution for the names of IPv4 hosts on the local +network. Where the DNS proxy supports AAAA RRs, resolution for the names +of dual stack IPv6 hosts on the local network can also be provided using + + + +Esibov, Aboba & Thaler Standards Track [Page 3] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +this mechanism. + +Within small adhoc IPv6 networks, stateful autoconfiguration is the most +likely configuration mechanism. If DHCPv6 is not present, then in order +to support resolution of names of IPv6-only hosts on the local network, +the DNS proxy will need to support dynamic client update as well as DNS +over IPv6. + +Given the above mechanisms enabling DNS name resolution in small +networks with a router, it is assumed that LMDNS need not be enabled by +default. + +In the future, multicast DNS may be defined to support greater than +LINKLOCAL multicast scope. This would occur if LMDNS deployment is +successful, the assumption that multicast DNS is not needed on multiple +links proves incorrect, and multicast routing becomes ubiquitous. For +example, it is not clear that this assumption will be valid in large +adhoc networking scenarios. + +Once we have experience in LMDNS deployment in terms of administrative +issues, usability and impact on the network it will be possible +reevaluate which multicast scopes are appropriate for use with multicast +DNS. + +2.1. Behavior of the sender and responder + +For the purpose of this document a host that sends a multicast query is +called a "sender", while a host that listens to (but not necessarily +responds to) a multicast query is called "responder". A host configured +to be a "responder" MAY also be a "sender". A host configured not to be +"responder" SHOULD NOT be a "sender". While hosts configured only as +senders can detect name conflicts, they cannot notify other senders of +potential conflicts for their name. Thus, implementation of both +responder and sender functionality is encouraged. + +2.1.1. Behavior of senders + +A sender sends an LMDNS query for any legal Type of resource record +(e.g. A, PTR, etc.) to the LINKLOCAL address. The RD (Recursion +Desired) bit MUST NOT be set. If a responder receives a query with the +header containing RD set bit, the responder MUST ignore the RD bit. + +The IPv6 LINKLOCAL address a given responder listens to, and to which a +sender sends, is a link-local multicast address formed as follows: The +name of the resource record in question is expressed in its canonical +form (see [RFC2535], section 8.1), which is uncompressed with all +alphabetic characters in lower case. The first label of the resource +record name is then hashed using the MD5 algorithm, described in + + + +Esibov, Aboba & Thaler Standards Track [Page 4] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +[RFC1321]. The first 32 bits of the resultant 128-bit hash is then +appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit +"solicited name multicast address". (Note: this procedure is intended +to be the same as that specified in section 3 of "IPv6 Node Information +Queries" [NodeInfo]). A responder that listens for queries for multiple +names will necessarily listen to multiple of these solicited name +multicast addresses. + +If the multicast query is not resolved during a limited amount of time +(LMDNS_TIMEOUT), then a sender MAY repeat the transmission of a query in +order to assure themselves that the query has been received by a host +capable of responding to the query. + +Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be +repeated more often than once per second to reduce unnecessary network +traffic. The delay between attempts should be randomized so as to avoid +synchronization effects. + +2.1.2. Behavior of responders + +An LMDNS responder listens on port 5353 on the LINKLOCAL address. +Responders MUST respond to multicast queries to those and only those +names for which they are authoritative. As an example, computer +"host.example.com." is authoritative for the domain "host.example.com.". +On receiving a linklocal multicast DNS A record query for the name +"host.example.com." such a host responds with A record(s) that contain +IP address(es) in the RDATA of the record. + +In conventional DNS terminology a DNS server authoritative for a zone is +authoritative for all the domain names under the zone root except for +the branches delegated into separate zones. Contrary to conventional DNS +terminology, a responder is authoritative only for the zone root. For +example the host "host.example.com." is not authoritative for the name +"child.host.example.com." unless the host is configured with multiple +names, including "host.example.com." and "child.host.example.com.". The +purpose of limiting the name authority scope of a responder is to +prevent complications that could be caused by coexistence of two or more +hosts with the names representing child and parent (or grandparent) +nodes in the DNS tree, for example, "host.example.com." and +"child.host.example.com.". + +In this example (unless this limitation is introduced) a multicast query +for an A record for the name "child.host.example.com." would result in +two authoritative responses: name error received from +"host.example.com.", and a requested A record - from +"child.host.example.com.". To prevent this ambiguity, multicast 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 5] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +"child.host.example.com." would send a dynamic update for the NS and +glue A record to "host.example.com.", but this approach significantly +complicates implementation of multicast DNS and would not be acceptable +for lightweight hosts. + +A response to a multicast query is composed in exactly the same manner +as a response to the unicast DNS query as specified in [RFC1035]. +Responders MUST never respond using cached data, and the AA +(Authoritative Answer) bit MUST be set. The response is sent to the +sender via unicast. A response to an LMDNS query MUST have RCODE set to +zero. Responses with RCODE set to zero are referred to in this document +as "positively resolved". LMDNS responders may respond only to queries +which they can resolve positively. + +If a TC (truncation) bit is set in the response, then the sender MAY use +the response if it contains all necessary information, or the sender MAY +discard the response and resend the query over TCP or using EDNS0 with +larger window using the unicast address of the responder. The RA +(Recursion Available) bit in the header of the response MUST NOT be set. +Even if the RA bit is set in the response header, the sender MUST ignore +it. + +2.1.3. LMDNS addressing + +For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of +IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to +source address selection, TTL settings, and acceptable +source/destination address combinations. IPv6 is described in [RFC2460]; +IPv6 LINKLOCAL addressing is described in [RFC2373]. LMDNS queries and +responses MUST obey the rules laid out in these documents. + +In composing an LMDNS response, the responder MUST set the Hop Limit +field in the IPv6 header and the TTL field in IPv4 header of the LMDNS +response to 255. The sender MUST verify that the Hop Limit field in IPv6 +header and TTL field in IPv4 header of each response to the LMDNS query +is set to 255. If it is not, then sender MUST ignore the response. + + Implementation note: + + In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket + options are used to specify the TTL of outgoing unicast and multicast + packets. The IP_RECVTTL socket option is available on some platforms + to receive the IPv4 TTL of received packets with recvmsg(). [RFC2292] + specifies similar options for specifying and receiving the IPv6 Hop + Limit. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 6] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +2.1.4. Use of DNS TTL + +The responder should use a pre-configured TTL value in the records +returned in the LMDNS query response. Due to the TTL minimalization +necessary when caching an RRset, all TTLs in an RRset MUST be set to the +same value. In the additional and authority section of the response the +responder includes the same records as a DNS server would insert in the +response to the unicast DNS query. + +2.1.5. No/multiple responses + +The sender MUST anticipate receiving no replies to some multicast +queries, in the event that no responders are available within the +linklocal multicast scope, or in the event that 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 for the specified name exist (NXRRSET). + +The sender MUST anticipate receiving multiple replies to the same +linklocal multicast query, in the event that several linklocal multicast +DNS 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, ordinarily. However, after receiving an initial response, +the sender is not required to wait for LMDNS_TIMEOUT for additional +responses. + +3. Usage model + +A host configured to be an LMDNS "responder" MUST also be configured as +a "sender". A host not configured as a "responder" MUST NOT be a +"sender". An LMDNS "sender" MAY multicast requests for any name. If +that name is not qualified and does not end in a trailing dot, for the +purposes of LMDNS, the implicit search order is as follows: + +[1] Request the name with the current domain appended. + +[2] Request just the name. + +This is the behavior suggested by [RFC1536]. LMDNS uses this technique +to resolve unqualified host names. + +If a DNS server is running on a host that supports LMDNS, the DNS server +MUST respond to LMDNS queries only for the RRSets owned by the host on +which the server is running, but MUST NOT respond for the records for +which the server is authoritative. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +3.1. LMDNS configuration + +LMDNS usage can be configured manually or automatically. On interfaces +where no manual or automatic configuration has been performed for a +given protocol (IPv4 or IPv6), LMDNS SHOULD be enabled by default for +that protocol. + +For IPv6, the stateless DNS discovery mechanisms described in "IPv6 +Stateless DNS Discovery" [DNSDisc] can be used to discover whether +linklocal multicast DNS should be enabled or disabled on a per-interface +basis. + +Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to +configure multicast DNS on an interface. The Multicast DNS Enable +Option, described in [mDNSEnable], can be used to explicitly enable or +disable use of linklocal multicast DNS on an interface for a given +protocol, as well as to specify the order in which DNS and LMDNS is used +on that interface. + +The Multicast DNS Enable Option affects only DNS resolver behavior, that +is, how DNS resolution is performed, and whether LMDNS is used. The +Multicast DNS Enable Option does not determine whether or in which order +DNS itself is used for name resolution. This can be specified, for +example, using the Name Service Search Option for DHCP, [RFC2937], which +can be used to globally determine where DNS is used within the name +service search order. + +If an interface has been configured for a given protocol via any +automatic configuration mechanism which is able to supply DNS +configuration information, then LMDNS SHOULD NOT be used on that +interface for that protocol unless it has been explicitly enabled, +whether via that mechanism or any other. This ensures that upgraded +hosts do not change their default behavior, without requiring the source +of the configuration information to be simultaneously updated. This +implies that on the interface, the host will neither listen on the DNS +LINKLOCAL multicast address, nor will it send queries to that address. + +Note that it is possible for LMDNS to be enabled for use with IPv6 at +the same time it is disabled for IPv4, and vice versa. For example, +where a home gateway implements a DNS proxy and DHCPv4, but not DHCPv6 +or DNS autoconfiguration, there may be no mechanism for allowing IPv6 +hosts to resolve the names of other IPv6 hosts on the home network. In +this situation, LMDNS is useful for resolution of dynamic names, and it +will be enabled for use with IPv6, even though it is disabled for use +with IPv4. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +4. Sequence of events + +The sequence of events for LMDNS usage is as follows: + +1. If a sender needs to resolve a query for a name + "host.example.com", then it sends a multicast query to the + LINKLOCAL multicast address. + +2. A responder responds to this query only if it is authoritative + for the domain name "host.example.com". The responder sends + a response to the sender via unicast over UDP. + +3. Upon the reception of the response, the sender verifies that the Hop + Limit field in IPv6 header or TTL field in IPv4 header (depending on + the protocol used) of the response is set to 255. The sender then + verifies compliance with the addressing requirements for IPv4, + described in [IPV4Link], and IPv6, described in [RFC2373]. If these + conditions are met, then the sender uses and caches the returned + response. If not, then the sender ignores the response and continues + waiting for the response. + +5. Conflict resolution + +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 a SRV type record + - multiple hosts may respond to a query for an A 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 type record for + a hostname. + +Every responder that responds to a linklocal multicast DNS query and/or +dynamic update request AND includes a UNIQUE record in the response: + + 1. MUST verify that there is no other host within the scope of the + LMDNS query propagation that can return a DNS 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 respond to linklocal multicast DNS queries +on more than one interface, the host MUST verify resource record +uniqueness on each interface for each UNIQUE resource record that could + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +be used on that interface. To accomplish this, the host MUST multicast a +dynamic DNS update request as specified in [RFC2136] for each new UNIQUE +resource record. Uniqueness verification is carried out when the host: + + - starts up or + - is configured to respond to the linklocal multicast DNS queries on + some interface or + - is configured to respond to the linklocal multicast DNS queries using + additional UNIQUE DNS records. + +Below we describe the data to be specified in the dynamic update +request: + +Header section + contains values according to [RFC2136]. + +Zone section + The zone name in the zone section MUST be set to the name of the + UNIQUE record. The zone type in the zone section MUST be set to + SOA. The zone class in the zone section MUST be set to the class of + the UNIQUE record. + +Prerequisite section + This section MUST contain a record set whose semantics are + described in [RFC2136], Section 2.4.3 "RRset Does Not Exist", + requesting that RRs with the NAME and TYPE of the UNIQUE record do + not exist. + +Update section + This section MUST be left empty. + +Additional section + This section is set according to [RFC2136]. + +When a host that owns a UNIQUE record receives a dynamic update request +that requests that the UNIQUE resource record set does not exist, the +host MUST respond via unicast with the YXRRSET error, according to the +rules described in Section 3 of [RFC2136]. + +After the client receives an YXRRSET response to its dynamic update +request stating that a UNIQUE resource record does not exist, the host +MUST check whether the response arrived on another interface. If this is +the case, then the client can use the UNIQUE resource record in response +to multicast queries and dynamic update requests. If not, then it MUST +NOT use the UNIQUE resource record in response to linklocal multicast +queries and dynamic update requests. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +Note that this name conflict detection mechanism doesn't prevent name +conflicts when previously partitioned segments are connected by a +bridge. In such a situation, name conflicts are detected when a sender +receives more than one response to its linklocal multicast DNS query. +In this case, the sender sends the first response that it received to +all responders that responded to this query except the first one, using +unicast. A host that receives a query response containing a UNIQUE +resource record that it owns, even if it didn't send such a query, MUST +verify that no other host within the linklocal multicast DNS scope is +authoritative for the same name, using the dynamic DNS update request +mechanism described above. + +Based on the result, the host detects whether there is a name conflict +and acts as described above. + +5.1. Considerations for Multiple Interfaces + +A multi-homed host may elect to configure LMDNS on only one of its +active interfaces. In many situations this will be adequate. However, +should a host wish to configure LMDNS on more than one of its active +interfaces, there are some additional precautions it MUST take. +Implementers who are not planning to support linklocal multicast DNS on +multiple interfaces simultaneously may skip this section. + +A multi-homed host checks the uniqueness of UNIQUE records as described +in Section 5. The situation is illustrated in figure 1 below: + + ---------- ---------- + | | | | + [A] [myhost] [myhost] + + Figure 1. LINKLOCAL 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. + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +Since names are only unique per-link, hosts on different links could be +using the same name. If an LMDNS 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 below. + + ---------- ---------- + | | | | + [A] [myhost] [A] + + + Figure 2. Off-segment name conflict + +If host myhost is configured to use LMDNS on both interfaces, it will +send LMDNS 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 will then forward a response from the first responder to the +second responder, who will attempt to verify the uniqueness of host RR +for its name, but will not discover a conflict, since the conflicting +host resides on a different link. Therefore it will continue using its +name. + +Indeed, 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. + +5.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 + + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +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. LMDNS 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. + +6. Security Considerations + +This draft does not prescribe a means of securing the LMDNS mechanism. +It is possible that hosts will allocate conflicting names for a period +of time, or that non-conforming hosts will attempt to deny service to +other hosts by allocating the same name. Such attacks also allow nodes +to receive packets destined for other nodes. The protocol reduces the +exposure to such threats in the absence of authentication by ignoring +LMDNS query response packets received from off-link senders. + +In order to prevent responses to LMDNS queries from polluting the DNS +cache, LMDNS implementations MUST use a distinct, isolated cache for +LMDNS. + +In all received responses, the Hop Limit field in IPv6 and the TTL field +in IPv4 are verified to contain 255, the maximum legal value. Since +routers decrement the Hop Limit on all packets they forward, received +packets containing a Hop Limit of 255 must have originated from a +neighbor. + +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 will serve to secure LMDNS against the above threats +if it is available. For example, where 802.11 "Wired Equivalency +Privacy" (WEP) [IEEE80211] is implemented, a casual attacker is likely +to be deterred from gaining access to the home network. + +The mechanism specified in this draft does not require use of DNSSEC. +As a result, responses to LMDNS queries MAY NOT be authenticated. If +authentication is desired, and a pre-arranged security configuration is +possible, then IPsec ESP with a null-transform MAY be used to +authenticate LMDNS responses. In a small network without a certificate +authority, this can be most easily accomplished through configuration of + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +a group pre-shared key for trusted hosts. + +7. IANA Considerations + +This specification does not create any new name spaces for IANA +administration. Since it uses a port (5353) and link scope multicast +IPv4 address (224.0.0.251) previously allocated for use with LMDNS, no +additional IANA allocations are required. + +8. Normative References + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC + 2136, April 1997. + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP + 23, RFC 2365, July 1998. + +[RFC2373] Hinden, R., Deering, S., "IP Version 6 Addressing + Architecture", RFC 2373, July 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. + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + +[IPV4Link] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 + Link-Local Addresses", Internet draft (work in progress), + draft-ietf-zeroconf-ipv4-linklocal-05.txt, November 2001. + +[mDNSEnable] Guttman, E., "DHCP Multicast DNS Enable Option", Internet + draft (work in progress), draft-guttman-mdns- + enable-01.txt, July 2001. + +9. Informative References + +[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +[RFC1536] Kumar, A., et. al. "DNS Implementation Errors and + Suggested Fixes", RFC 1536, October 1993. + +[RFC2292] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + +[RFC2553] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic + Socket Interface Extensions for IPv6", RFC 2553, March + 1999. + +[IEEE80211] Information technology - Telecommunications and + information exchange between systems - Local and + metropolitan area networks - Specific Requirements Part + 11: Wireless LAN Medium Access Control (MAC) and + Physical Layer (PHY) Specifications, IEEE Std. + 802.11-1997, 1997. + +[DNSDisc] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", + Internet draft (work in progress), draft-ietf-ipngwg-dns- + discovery-02.txt, July 2001. + +[NodeInfo] Crawford, Matt, "IPv6 Node Information Queries", Internet + draft (work in progress), draft-ietf-ipn-gwg-icmp-name- + lookups-07.txt, August 2000. + +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, Robert Elz, Rob +Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, +Thomas Narten, Erik Nordmark, Sander Van-Valkenburg and Tomohide +Nagashima. + +Authors' Addresses + +Levon Esibov +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + +EMail: levone@microsoft.com + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +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. + +Full Copyright Statement + +Copyright (C) The Internet Society (2001). 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001 + + +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." + +Expiration Date + +This memo is filed as , and expires +June 22, 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + +