diff --git a/doc/draft/draft-aboba-dnsext-mdns-01.txt b/doc/draft/draft-aboba-dnsext-mdns-01.txt new file mode 100644 index 0000000000..439680df39 --- /dev/null +++ b/doc/draft/draft-aboba-dnsext-mdns-01.txt @@ -0,0 +1,480 @@ + + + + + + +DNSEXT Working Group Levon Esibov +INTERNET-DRAFT Bernard Aboba +Category: Standards Track Dave Thaler + Microsoft +14 July 2000 + + + Multicast DNS + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +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. + +1. Copyright Notice + +Copyright (C) The Internet Society (2000). All Rights Reserved. + +2. Abstract + +Today, with the rise of home networking, there are an increasing number +of small networks operating without a DNS server. In order to allow DNS +name resolution in such environments, the use of a multicast DNS is +proposed. + +3. 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 the name resolution for the names of the hosts on the local +network. The latter case, for example, corresponds to a scenario when a +home network that doesn't have a DNS server is connected to the Internet +through an ISP and the home network hosts are configured with the ISP's +DNS server for the name resolution. The ISP's DNS server provides the + + + +Esibov, Aboba & Thaler Standards Track [Page 1] + + + + + +INTERNET-DRAFT Multicast DNS 14 July 2000 + + +name resolution for the names registered on the Internet, but doesn't +provide name resolution for the names of the hosts on the home 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. + +4. Terminology + +In this document, the key words "MAY", "MUST, "MUST NOT", "optional", +"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as +described in [1]. + +5. Name resolution using Multicast DNS + +This extension to the DNS protocol consists of a single change to the +method of use, and no change whatsoever to the current format of DNS +packets. Namely, this extension allows multicast DNS queries to be sent +to and received on port 53 using the LINKLOCAL addresses for IPv4 and +IPv6, which are yet to be assigned by IANA. LINKLOCAL addresses are used +since the expectation is that if a network has a router, then this +router can function as a mini-DHCP server, as described in [3], and a +DNS proxy, possibly implementing dynamic DNS. Thus there is not expected +to be a need for use of multicast DNS in networks with multiple +segments. + +Hosts actively using mDNS behave as DNS servers, and inherit all the +obligations of DNS servers, as described in [8], including the need to +increment the serial number in SOA records. It is suggested that the +serial number be taken from a monotonically increasing clock which +implies that the serial number will be monotonic across reboots. +However, this is not crucial if the DNS TTL is set to a low value. + +In order to prevent a DNS server from recursive resolution of the +multicast DNS queries, the RD (Recursion Desired) bit in the Header +section of the query MUST be set to 0. If the RD bit is set to 1, then +it is ignored. + +DNS resolvers configured to use multicast DNS for name resolution listen +on port 53 on the LINKLOCAL mDNS address. Responses SHOULD contain a AA +(Authoritative Answer) bit set to 0. + +Issue: Handling of the AA bit was flagged as a subject for more +discussion. + +If a query sent to the LINKLOCAL mDNS addresses is not positively +resolved ("positively resolved" refers in this document to the response +with the RCODE set to 0) during a limited amount of time, then the + + + +Esibov, Aboba & Thaler Standards Track [Page 2] + + + + + +INTERNET-DRAFT Multicast DNS 14 July 2000 + + +resolver MAY repeat the transmission of a query in order to assure +themselves that the query has been received by any hosts capable of +answering the query. + +Resolvers MUST anticipate receiving no replies to some multicasted +queries, in the event that no multicast-enabled clients are available +within the multicast scope, or in the event that no positive non-null +responses exist to 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), which should be cached according to RFC 2308 [15]. + +6. Usage model + +Multicast DNS usage is determined by the domain search configuration as +well as by special treatment of the ".lcl.arpa" namespace. The resolver +treat queries for ".lcl.arpa" as a special case, thus avoiding the need +to formally allocate a new top level domain. The domain search list can +be configured manually or automatically via a DHCP option. There is +therefore no need for another mDNS configuration mechanism. + +The resolver will always do a multicast query for names in the +".lcl.arpa" namespace if there is no NS record corresponding to the +name. mDNS is only used to resolve unqualified names. This means, for +example, that queries for "www.microsoft.com" will never be resolved via +mDNS. + +If ".lcl.arpa" is not in the domain search list, then mDNS MUST NOT be +used by that host. An auto-configured host will typically have +".lcl.arpa" first in its search list so that it will be enabled to use +mDNS. Typically an enterprise host will not have ".lcl.arpa" in its +searchlist at all so that it will not use mDNS. + +6.1. Sequence of events + +The sequence of events for usage of multicast DNS is as follows: + +1. A host multicasts a query for ANY record for a name within + the ".lcl.arpa" domain. The query is sent to the LINKLOCAL + multicast address. The response is multicast to the LINKLOCAL + address, and uses DNS TTL=0, with the exception of NS, which + uses a default TTL, with a value TBD. + +2. Hosts only respond to queries if they are the name server for + the domain (e.g. they are foo.lcl.arpa). Hosts never + respond based on cached information. The responding host + responds with SOA and NS records. + + + +Esibov, Aboba & Thaler Standards Track [Page 3] + + + + + +INTERNET-DRAFT Multicast DNS 14 July 2000 + + +3. Now that the querying host has discovered the name server for the + domain, subsequent queries are sent unicast to the discovered + name server. + +Note that this implies that multicast DNS cannot be used for discovering +services (e.g. trying to query for all printers on the segument via a +"*._lpr._udp" SRV [4] query). While this is not an objective of the +current specification, this functionality may be added in a subsequent +extension. + +Since mDNS queries are sent on to a LINKLOCAL multicast address, mDNS +cannot even be used to discover the location of DNS servers off the +local segment. As a result, mDNS is not useful for IPv6 or IPv4 DNS +server discovery. + +7. Name conflicts + +It is required to verify the uniqueness of the host DNS name when a host +boots, when its name is changed, or when it is configured to use +multicast DNS (such as when the domain search option is changed to +include ".lcl.arpa"). + +A gratuitious name resolution query SHOULD be done to check for a name +conflict. This is done by having the resolver send a multicast ANY type +query for its own name. If the query is not positively resolved then +host starts using its name. If the query is positively resolved, then +the host should verify that the IP addresses specified in the response +are its own IP addresses, possibly from another adapter. If the host +verifies it, then it starts using its name. If the host cannot match the +returned A records to its IP addresses, then a conflict has been +detected. In order to resolve ownership conflicts, if the host has a +lower IP address it will keep the name, else if the device has a higher +IP address it will change names. + +A host that has detected a name conflict and has loses the name election +MUST NOT use the name. This means that the host MUST NOT respond to +multicast queries for that name and MUST NOT respond to other multicast +queries with the records that contain in RDATA name in conflict (for +example, PTR record). + +Note that this name conflict detection mechanism doesn't prevent name +conflicts when previously separate networks are connected by a bridge. +Name conflict in such situation is detected when a host receives an +multicast response to a query for its name or when a client receives +more than one response to a multicast query that it sent. A host that +receives a response for a query for it's own name, even if it didn't +send such query, behaves as if it sent this query. + + + + +Esibov, Aboba & Thaler Standards Track [Page 4] + + + + + +INTERNET-DRAFT Multicast DNS 14 July 2000 + + +In order to prevent denial of service attacks, it is recommended that +"lcl.arpa" be placed last in the domain searchlist. As long as this is +the case, there should be no way for a server with a FQDN to encounter +name conflict problems which would cause it to become unreachable. + +8. IANA Considerations + +Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses. + +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. + +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. In +order to provide for privacy equivalent to a wired network, the 802.11 +specification provides for RC4-based encryption. This is known as the +"Wired Equivalency Privacy" (WEP) specification. Where WEP is +implemented, an attacker will need to obtain the WEP key prior to +gaining access to the home network. + +10. Acknowledgements + +The authors would like to thank Stuart Cheshire, Michael Patton, Erik +Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, +Myrong Hattig and Bill Manning for comments on this draft, provided at +the mDNS lunch in Adelaide, Australia on 3/29/00. + +11. 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 5] + + + + + +INTERNET-DRAFT Multicast DNS 14 July 2000 + + +Dave Thaler +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + +Phone: +1 (425) 703-8835 +EMail: dthaler@microsoft.com + + +12. 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] Aboba, B., "The Mini-DHCP Server", Internet draft (work in + progress), draft-aboba-dhc-mini-01.txt, April 2000. + +[4] Gulbrandsen, A., Vixie, P., Esibov, L. "A DNS RR for specifying the + location of services (DNS SRV)", RFC 2782, February 2000. + +[5] Braden, R., "Requirements for Internet Hosts -- Application and + Support", RFC 1123, October 1989. + +[6] Hanna, S., Patel, B., and Shah, M., "Multicast Address Dynamic + Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. + +[7] Gulbrandsen, A., "A DNS RR for encoding DHCP information", Internet + draft (work in progress), draft-ietf-dnsind-dhcp-rr-00.txt, October + 1999. + +[8] Mockapetris, P., "Domain Names - Implementation and Specification", + RFC 1035, November 1987. + +[9] IANA, "Single-source IP Multicast Address Range", + http://www.isi.edu/in-notes/iana/assignments/single-source- + multicast, October 1998. + +[10] Handley, M., Thaler, D., and Kermode, R., "Multicast-Scope Zone + Announcement Protocol (MZAP)", Work in progress, draft-ietf-mboned- + mzap-06.txt, December, 1999. + +[11] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear, + E., "Address Allocation for Private Internets", RFC 1918, February, + 1996. + + + + +Esibov, Aboba & Thaler Standards Track [Page 6] + + + + + +INTERNET-DRAFT Multicast DNS 14 July 2000 + + +[12] Stapp, M., Rekhter, Y., "Interaction between DHCP and DNS", + Internet draft (work in progress), draft-ietf-dhc-dhcp-dns-11.txt, + October 1999. + +[13] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS + UPDATE)", RFC 2136, April, 1997. + +[14] Troll, R., "DHCP Option to Disable Stateless Auto- + Configuration in IPv4 Clients", RFC 2563, May 1999. + +[15] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + +[16] Auerbach, K., "PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP + TRANSPORT: CONCEPTS AND METHODS", RFC 1001, March, 1987. + +13. 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. + +14. Full Copyright Statement + +Copyright (C) The Internet Society (2000). 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 implmentation 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 7] + + + + + +INTERNET-DRAFT Multicast DNS 14 July 2000 + + +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." + +15. Expiration Date + +This memo is filed as , and expires +February 1, 20001. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-00.txt b/doc/draft/draft-ietf-dnsext-mdns-00.txt new file mode 100644 index 0000000000..1458fa6802 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-00.txt @@ -0,0 +1,521 @@ + + +DNSEXT Working Group Levon Esibov +INTERNET-DRAFT Bernard Aboba +Category: Standards Track Dave Thaler + Microsoft +November 16, 2000 + + + Multicast DNS + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +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 (2000). All Rights Reserved. + +Abstract + +Today, with the rise of home networking, there are an increasing number +of small networks operating without a DNS server. In order to allow DNS +name resolution in such environments, the use of a multicast DNS is +proposed. + +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 +home network that doesn't have a DNS server is connected to the Internet +through an ISP and the home 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 home network. + + + + +Esibov, Aboba & Thaler Standards Track [Page 1] + +INTERNET-DRAFT Multicast DNS 16 November 2000 + + +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. + +Discovery of the services in general as well as discovery of the DNS +servers in particular using multicast DNS is left outside of the scope +of this document. + +Name resolution over non-multicast capable media is left outside of the +scope of this document. + +In this document, the key words "MAY", "MUST, "MUST NOT", "optional", +"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as +described in [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 whatsoever to the current format of DNS +packets. Namely, this extension allows multicast DNS queries to be sent +to and received on port 53 using the LINKLOCAL addresses [2] for IPv4 +and IPv6 (below in this text referred as LINKLOCAL address), which are +yet to be assigned by IANA. LINKLOCAL addresses are used to prevent +propagation of the multicast DNS traffic across the routers that may +cause network flooding. Propagation of the multicast DNS packets within +the boundaries is considered sufficient to enable DNS name resolution, +since the expectation is that if a network has a router, then this +router can function as a mini-DHCP server, as described in [3], and a +DNS proxy, possibly implementing dynamic DNS. Thus there is not expected +to be a need for use of multicast DNS in networks with multiple +segments. + +2.1 Behavior of the sender and responder + +For the purpose of this document a device that sends a multicast query +is called a "sender", while a device that listens to (but not +necessarily responds to) a multicast query is called "responder". A +device configured to be a "responder" may also be a "sender". A device +configured to not be a "responder" cannot be a "sender". + +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. + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 2] + +INTERNET-DRAFT Multicast DNS 16 November 2000 + + +If the multicast query is not positively resolved ("positively resolved" +refers in this document to the 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 5 times, and the repetition SHOULD NOT be repeated +more often than once per 0.1 seconds to reduce the unnecessary network +traffic. Retry intervals SHOULD be exponentially increased. + +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.". When such host receives a multicast DNS +query for an A record for the name "host.example.com.local.arpa." it +responds with an A record(s) that contains its 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 such limitation +of the name authority scope of a responder is to prevent complication +that could be caused by coexistence of two or more devices with the +names representing child and parent (or grandparents) 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 introduced) the multicast query for an A record for the name +"child.host.example.com.local.arpa." would cause two authoritative +responses: name error received from "host.example.com.local.arpa.", and +requested A record - from "child.host.example.com.local.arpa.". To +prevent such ambiguity, we could propose to implement multicast enabled +devices to 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 the "host.example.com.local.arpa.", but this +approach significantly complicates implementation of the multicast DNS +and would not be acceptable for a lightweight devices. + +The response to the multicast query is composed in exactly the same +manner as in case of a response to the unicast DNS query as specified +in [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. 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 unicast address of the + + + +Esibov, Aboba & Thaler Standards Track [Page 3] + +INTERNET-DRAFT Multicast DNS 16 November 2000 + + +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. The responder MUST set the Hop Limit +field in IPv6 header and TTL field in IPv4 header of all responses to +the multicast DNS query 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 such response. + +The responder should use a pre-configured TTL [5] 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. + +The responder includes in the additional and authority section of the +response the same records, as a DNS server would insert in the response +to the unicast DNS query. + +Sender MUST anticipate receiving no replies to some multicasted queries, +in the event that no responders are available within the multicast +scope, or in the event that no positive non-null responses exist to 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), which SHOULD be cached for a period that SHOULD NOT +exceed 5 seconds. + +Sender MUST anticipate receiving multiple replies to the same +multicasted 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 device configured to be a "responder" may also be a "sender". A device +configured to not be a "responder" cannot be a "sender". + +Multicast DNS usage is determined by the domain search configuration as +well as by special treatment of the ".local.arpa." namespace. Any +device whose domain search configuration contains ".local.arpa." domain +is configured to behave as "responder". A device configured to be a +"responder" may also be a "sender". A device cannot be configured to +behave as one (i.e. sender or responder), but not another. The sender +treats queries for ".local.arpa." as a special case. The domain search +list can be configured manually or automatically via a DHCP option. + + + + +Esibov, Aboba & Thaler Standards Track [Page 4] + +INTERNET-DRAFT Multicast DNS 16 November 2000 + + +A sender MUST NOT send a unicast query for names ending with the +".local.arpa." suffix except in the case when a sender repeats a query +over TCP after it received a response to the previous multicast query +with TC bit set or unless sender's cache contains NS resource record +that enables sender to send a query directly to the devices +authoritative for the name in query. + +It is not expected that a device "host.example.com." will be manually +configured to have 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.". I.e. when 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. + +If ".local.arpa" is not in the domain search list, then multicast DNS +MUST NOT be used by a device. This implies that the device will neither +listen on the DNS LINKLOCAL multicast address, nor will it send queries +to that address. An auto-configured host will typically have +".local.arpa" first in its search list so that it will be enabled to +use mDNS. Typically an enterprise host will not have ".local.arpa" in +its search list at all so that it will not use mDNS. + +The same device may use multicast DNS queries for the name resolution of +the names ending with ".local.arpa.", and unicast DNS queries for name +resolution of all other names. When a DNS client is requested by a user +or application to perform a name resolution of a dot-terminated name +that contains a ".local.arpa" suffix, a query for such name MUST be +multicasted and such name should not be concatenated with any suffix. + +If a DNS server is running on a device, the device MUST NOT listen for +the multicast DNS queries, to prevent a device from listening on port 53 +and intercepting DNS queries directed to a DNS server. A DNS server may +listen and respond to the multicast queries. A DNS server by default +doesn't listen to the multicast DNS queries. Presence of the +".local.arpa." in the domain search list doesn't affect the +configuration on the DNS server. + + +4. Sequence of events + +The sequence of events for usage of multicast DNS 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. + + +Esibov, Aboba & Thaler Standards Track [Page 5] + +INTERNET-DRAFT Multicast DNS 16 November 2000 + + + 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 + used protocol) of the response is set to 255. If it is, then sender + uses and caches the returned response. If not, then the sender ignores + the response and continues waiting for the response. + + +5. Name conflicts + +It is required to verify the uniqueness of the host DNS name when a host +boots, when its name is changed, or when it is configured to use +multicast DNS (such as when the domain search option is changed to +include ".local.arpa."). + +A gratuitous name resolution query SHOULD be done to check for a name +conflict. This is done by having the resolver send a multicast query for +a SOA type query for its own name (i.e. for the name it is authoritative +for). If the query is not positively resolved then host assumes +authority for the name. If the query is positively resolved, then the +host should verify that the computer name specified in the RDATA of the +SOA record in the answer section of the response is its own computer +name. If the host verifies it, then it assumes authority for its name. +If the host cannot match the returned computer name to its computer +name, then a conflict has been detected. In order to resolve name +conflict, the host will change the name. + +A host that has detected a name conflict MUST NOT use the name. This +means that the host MUST NOT respond to multicast queries for that name +and MUST NOT respond to other multicast queries with the records that +contain in RDATA name in conflict (for example, PTR record). + +Note that this name conflict detection mechanism doesn't prevent name +conflicts when previously separate networks are connected by a bridge. +Name conflict in such situation is detected when a sender receives more +than one response to its multicasted DNS query. Such sender sends using +unicast the first response that it received to all responders, except +the first one, that responded to this query. A host that receives a +response for a query for it's own name, even if it didn't send such +query, sends a multicast query for the SOA record for the name that it +is authoritative for. Based on the response the host detects the name +conflict and acts according to the description above. + + +6. IANA Considerations + +Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses. + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 6] + +INTERNET-DRAFT Multicast DNS 16 November 2000 + + +7. 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. The Hop Limit field in IPv6 and TTL field in IPv4 of all +received packets is verified to contain 255, the maximum legal value. +Because 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. In +order to provide for privacy equivalent to a wired network, the 802.11 +specification provides for RC4-based encryption. This is known as the +"Wired Equivalency Privacy" (WEP) specification. Where WEP is +implemented, an attacker will need to obtain the WEP key prior to +gaining access to the home network. + +The mechanism specified in this draft does not require use of the +DNSSEC, which means that the responses to the multicast DNS queries may +not be authenticated. If a network contains a "signed key distribution +center" for all (or at least some) of the DNS zones that the responders +are authoritative for, then those devices on such a network are +configured with the key for the top zone, "local.arpa." (hosted by +"signed keys distribution center") may use DNSSEC for the authentication +of the responders using DNSSEC. + +8. Acknowledgements + +The authors would like to thank Stuart Cheshire, Michael Patton, Erik +Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, +Myrong Hattig, Bill Manning and James Gilroy for comments on this draft. + +9. Authors' Addresses + +Levon Esibov +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + +EMail: levone@microsoft.com + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + +INTERNET-DRAFT Multicast DNS 16 November 2000 + +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 + + +10. 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] Aboba, B., "The Mini-DHCP Server", Internet draft (work in + progress), draft-aboba-dhc-mini-01.txt, April 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. + +11. 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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + +INTERNET-DRAFT Multicast DNS 16 November 2000 + + +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. + +12. Full Copyright Statement + +Copyright (C) The Internet Society (2000). 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." + +13. Expiration Date + +This memo is filed as , and expires +May 16, 2001. + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 9] diff --git a/doc/draft/draft-manning-multicast-dns-02.txt b/doc/draft/draft-manning-multicast-dns-02.txt new file mode 100644 index 0000000000..d25613d01e --- /dev/null +++ b/doc/draft/draft-manning-multicast-dns-02.txt @@ -0,0 +1,419 @@ +Network Working Group B. Woodcock +Request for Comments: nnnn Zocalo +Category: Experimental B. Manning + ISI + August 2000 + + + Multicast Discovery of DNS Services + draft-manning-multicast-dns-02.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance + with all provisions of Section 10 of RFC2026 except that the right + to produce derivative works is not granted. 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." + + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +1. Introduction + + This document describes a minimal extension to the method of a DNS + query which allows unconfigured hosts to locate a local DNS server, + or in the absence of a DNS server to nonetheless identify some + local network services. + +2. Acknowledgments + + Vital contributions to this document were made by Paul Vixie, Dave + Meyer, Stuart Cheshire, Richard Ford, Tony McGregor, Erik Guttman, + Benard Aboba, and Peter Ford. Thanks also to Alex Hoppman for + discussion of text-encoding methods. + +3. Overview and rationale + + This experimental extension to DNS is intended to provide a bootstrap + mechanism whereby unconfigured devices may find a local DNS server + and begin using it to perform the usual name resolution and service + lookup functions. This need is particularly acute in the absence of + a DHCP server. + + Secondarily, it is anticipated that device vendors may implement the + server (query-receiving) portion of this extension, in order to + render unconfigured devices which may lack an out-of-band + configuration interface such as a screen or keyboard discoverable on + the local network. For example, if a newly-purchased laser printer + or router were connected to a network, this extension would allow a + system administrator to use the DNS to discover the IP address which + the device had selected or been DHCP-assigned, and begin + communicating with it through the network. + + A tertiary objective of this extension is to make possible the + deprecation of the AppleTalk protocol, which has been prolonged as a + means of providing support for "network browsing." + +4. Discussion + + This extension to the DNS protocol consists of a single change to the + method of use, and no change whatsoever to the current format of DNS + packets. Specifically, this extension allows UDP DNS queries, as + documented in RFC 1035, sections 4.1.1, 4.1.2 and 4.2.1, to be + addressed to port 53 of statically-assigned relative offset -2 within + the range of multicast addresses defined as "administratively scoped" + by RFC 2365, section 9. Within the full /8 of administratively + scoped addresses, this corresponds to the destination address + 239.255.255.253. Until MZAP or a similar protocol is implemented to + allow hosts to discover the extent of the local multicast scopes + which enclose them, it is anticipated that implementations will + simply utilize the destination address 239.255.255.253. + + In order to receive multicasted queries, DNS server implementations + MUST listen on the -2 offset to their local scope (as above, in the + absence of a method of determining the scope, this will be assumed to + be relative to the full /8 allocated for administratively-scoped + multicast use, or 239.255.255.253), and respond via ordinary unicast + UDP to ONLY those queries for which they have or can find a positive + non-null answer. Multicast-enabled DNS servers MUST answer + multicasted queries non-authoritatively. That is, when responding to + a query which was received via multicast, they MAY NOT include an NS + record which contains data which resolves back to their own IP + address. + + Resolvers SHOULD be liberal in their acceptance of wildcard queries. + That is, resolvers should anticipate receiving queries which will + contain the asterisk character in any position within the query's + data field. For example, a query for SRV RRs with data + "afp.tcp.*.domain.com." would match "afp.tcp.server.domain.com." but + not match "afp.tcp.". A query for "afp.tcp.*" would match both, + since the asterisk should be interpreted as matching zero or more + characters within the RR data. + + Resolvers MUST anticipate receiving no replies to some multicasted + queries, in the event that no multicast-enabled DNS server + implementations are active within the local scope, or in the event + that no positive non-null responses exist to the transmitted query. + That is, a query for the MX record for host.domain.com would go + unanswered if no local server was able to resolve that request, if no + MX record exists for host.domain.com, or if no local servers were + capable of receiving multicast queries. The resolver which initiated + the query MUST treat such non-response as a non-cacheable negative + response. Since this multicast transmission does not provide + reliable delivery, resolvers MAY repeat the transmission of a query + in order to assure themselves that is has been reveived by any hosts + capable of answering, however any resolvers which repeat a query MUST + increase the interval between such repetitions exponentially over + time. + + Resolvers MUST also anticipate receiving multiple replies to the same + multicasted query, in the event that several multicast-enabled DNS + servers 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 server + would, ordinarily. + + +5. Implementation Notes Appendix + + It is anticipated that a major use of this extension to DNS will be + for the replacement of the AppleTalk Name Binding Protocol (NBP) + "distributed database," and the implementation of a similar service + within other operating systems and on other platforms. Such use + implies the existence of "stub DNS servers" on each participating + host, each containing only local information in its served zones, but + not to the exclusion of data which other servers may assert within + the same zones. + + The following rather complex example shows the format by which an + implementor could assert the local information possessed by any + Macintosh in zones served by a stub DNS server on that host: + + $ORIGIN . + @ SOA . . 1998082701 0 0 0 0 + 0 IN NS dns.udp. + Jasons-Mac 0 IN A 169.254.101.218 + 0 IN HINFO Macintosh-G3-400 MacOS-8.6 + 0 IN LOC 37 52 N 122 20 W + 0 IN RP . owner-name.Jasons-Mac. + Jasons-Hard-Disk 0 IN A 169.254.101.218 + 0 IN TXT "UTF8-encoded service-name" + Print-Spooler 0 IN A 169.254.101.218 + 0 IN TXT "UTF8-encoded service-name" + dns.udp 0 IN SRV 0 0 53 Jasons-Mac. + afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk. + lpr.tcp 0 IN SRV 0 0 515 Print-Spooler. + http.tcp 0 IN SRV 0 0 80 www.jasonco.com. + https.tcp 0 IN SRV 0 0 443 secure.jasonco.com. + + $ORIGIN jasonco.com. + www 0 IN A 169.254.101.218 + 0 IN TXT "UTF8-encoded service-name" + secure 0 IN A 169.254.101.218 + 0 IN TXT "UTF8-encoded service-name" + + $ORIGIN Jasons-Mac. + dns.udp 0 IN SRV 0 0 53 Jasons-Mac. + owner-name 0 IN TXT "Jason A. Luser" + * 0 IN PTR afp.tcp.Jasons-Mac. + 0 IN PTR lpr.tcp.Jasons-Mac. + 0 IN PTR http.tcp.Jasons-Mac. + afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk. + lpr.tcp 0 IN SRV 0 0 515 Print-Spooler. + http.tcp 0 IN SRV 0 0 80 www.jasonco.com. + + $ORIGIN 101.254.169.in-addr.arpa. + 218 0 IN PTR Jasons-Mac. + + Windows and Unix hosts are possessed of many of the same, or + analogous, types of local information, and similar examples could be + constructed around hypothetical hosts of those types. A much + simpler example featuring a laser printer follows, in section 6 of + this document. + + Note that in translating service and device names from high-bit-depth + character sets such as Unicode to DNS-compliant hostnames, a + character-mapping must occur, whereby spaces are mapped to hyphens, + punctuation other than periods is removed, and plain characters are + substituted for their accented equivalents. Implementors MUST perform + a uniqueness check, in order to guarantee that no other device within + the local multicast scope has already asserted a claim to the DNS + name which their device wishes to employ. Uniqueness checks at + service-registration time must be somewhat more strict than their + historical AppleTalk equivalents, comparing names which have already + been converted to their DNS-compliant state (containing only a-z, + A-Z, 0-9, and the hyphen character, and starting with a letter rather + than a hyphen or number), and must treat upper and lower-case as + equivalent. Note that periods in device and service names shall be + preserved and used to establish subdomains within the stub DNS + server's dataset. The high-bit-depth names are made available to + queriants in the form of UTF8-encoded RDATA in TXT RRs included as + Additional Information (as described in RFC 1035, sections 4.1 + through 4.1.3) appended to any A RR response. + + Implementors of multicast-enabled resolvers may expect the following + results of the following query-types: + + Data Type Result + + *.in-addr.arpa PTR All hostnames in the local scope + *.host.domain.com SRV All services on host.domain.com + lpr.tcp. SRV All printers/spoolers in the local scope + + Duplicate identical records received in different responses to a + query may be treated as a single record in the concatenation of + responses. It is beyond the scope of this document to suggest + disposition of different responses which contain disagreeing pairs of + name NAME and RDATA. + + Implementors should note that "virtual hosts" (that is, the support + of multiple IP addresses on a single host, and the binding of + different services to different addresses) are easily supported in + responses to multicast queries, but should also note that one of the + benefits afforded by the use of SRV RR-types is a reduction in the + need for virtual hosts, since multiple named services may be bound to + different (non-well-known) ports of the same IP address, and still be + individually identified and differentiated. For example, a single + host might support one HTTP server on port 80, a second on port 8001, + and an HTTPS server on port 443, and each could be reached via + different name. + + Another major use of this extension to DNS is to allow bootstrapping + machines to find local DNS servers. It is anticipated that larger + enterprises may in the future possess one or more fully-featured DNS + servers which are also multicast-enabled. Once a bootstrapping host + has located such a server, that host need no longer use multicast at + all. That host may instead employ ordinary unicast DNS exactly as + any other host would, to query those DNS servers. The servers, in + turn, might well employ multicast queries to glean information about + the services contained within their local scope, which information + they might then use to respond to unicast queries (proxying, in + effect), and cache against future need. Note also that the ability + to answer multicast queries would prove particularly useful to a DNS + server which was resident on the same host as a NAT at the border of + an enterprise which employed 10.0.0.0/8 or 169.254.0.0/16 unicast + addresses internally. + + Implementors MAY choose to employ an optimization whereby the + deleterious impact of large numbers of unconfigured hosts + simultaneously attempting to locate DNS servers during the bootstrap + process might be mitigated, and the process be made more efficient. + Specifically, high- and low-water marks are defined for frequency of + multicasted lookups for SRV RRs of "dns.udp.". When a + multicast-enabled DNS server observes the frequency of such lookups + exceeding a high-water mark (five queries per minute, perhaps), the + server MAY begin interspersing responses transmitted via multicast, + rather than unicast, until such time as the frequency of such lookups + falls below a low-water mark (one query per five minutes, perhaps). + In order for this to work, multicast-enabled resolvers would also + need to listen on the multicast address for responses, and cache them + briefly. Both the server and resolver portions of this optimized + behavior are optional, and it should be stressed that this + optimization need not be considered by implementors of stub servers + in devices such as printers, which do not provide generalized DNS + services. If DNS server implementors choose to employ multicast + responses, they MUST interleave multicast responses with unicast + responses in such a way that the multicast responses decrease over + time, rather than flooding the network, in order that servers not be + used to propagate denial-of-service attacks. In other words, a + reasonable approach might be while above the high-water mark to make + the first, second, fourth, eighth, sixteenth et cetera responses for + each RR multicast, while all inbetween would be unicast. Note that + this not only protects against multicast "storms," it also protects + against the mis-match condition which occurs in the case that a + non-optimized resolver is the presence only of optimized servers, all + of which are temporarily in multicast-response mode. + + Implementors SHOULD also employ DNS Sec, or its equivalent, as soon + as such technology is standardized, in order to minimize the + possiblity of "spoofing" of information by nodes responding to + multicast queries. + + +6. Use & Administration Notes Appendix + + Administrators of networks employing this protocol are advised to + employ fully-qualified domain names (FQDNs) as their host names where + possible, such that the dots separating portions of the name shall be + interpreted by the stub-server implementations as subdomain + delimiters, and shall thus serve to remove the host from the local + view of the root domain to its correct and appropriate + globally-unique subdomain. + + Administrators of service-providing devices, such as already-deployed + printers, which are not capable of receiving multicast DNS queries, + may wish to inject DNS records into a local multicast-enabled DNS + server on behalf of those devices. For example, an administrator + might wish to create records of the following nature in order to make + a non-multicast-capable laser printer visible to both multicast and + unicast queriants: + + $ORIGIN . + lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com. + + $ORIGIN sales.domain.com. + laser2 0 IN A 169.254.5.28 + 0 IN TXT "Old Sales Dep't Laser Printer" + + $ORIGIN laser2.sales.domain.com. + * 0 IN PTR lpr.tcp.laser2.sales.domain.com. + lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com. + + $ORIGIN 5.254.169.in-addr.arpa. + 28 0 IN PTR laser2.sales.domain.com. + + Administrators of networks which contain either multicast-capable + resolvers or multicast-capable DNS servers MUST employ filters + defining a contiguous border around their enterprises and prohibiting + passage of data to and from the 239.0.0.0/8 address space, as well as + routing information relating to the 239.0.0.0/8 prefix or any subnet + of it. This is the mechanism by which RFC 2365 administrative + scoping is enacted. The sole exception to this rule would be any + explicitly-configured interconnections with other specific + enterprises between which all involved administrators wish to share a + single browsable network space. This is anticipated to be a very + infrequent occurrence within the current regime of network security + policies. + +References + + RFC 1035: Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November, 1987. + + RFC 2052: Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the + location of services (DNS SRV)", RFC 2052, October, 1996. + + RFC 2365: Meyer, D., "Administratively Scoped IP Multicast", + RFC 2365, July, 1998. + + Handley, M., Thaler, D., "Multicast-Scope Zone Announcement + Protocol (MZAP)", MBoneD Internet Draft, October, 1998. + + Sidhu, G.S., Andrews, R.F., and Oppenheimer, A., "Inside AppleTalk, + Second Edition", Addison-Wesley, 1990. + +Security Considerations + + While this extension to DNS introduces no new security problems to + DNS or Multicast, it should be emphasized that distributed + directories, common to other networking protocols, have not hitherto + been widely used in the IP networking community. Distributed + directories do require that users and system administrators assume + some conscious balance between the level of trust which they accord + to the responding entities on their network, and the degree of + credence which they pay to the responses they receive. The level of + trust traditionally assumed in distributed directory environments + does not necessarily mix well with clear-text password transmission + such as is still found on some IP networks, for example. + + +Authors' Addresses + + Bill Woodcock + Zocalo + 2355 Virginia Street + Berkeley, CA 94709-1315 + USA + + Phone: +1 510 540 8000 + EMail: woody@zocalo.net + + + Bill Manning + USC/ISI + 4676 Admiralty Way, #1001 + Marina del Rey, CA. 90292 + USA + + Phone: +1 310 822 1511 + EMail: bmanning@isi.edu + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). 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 + +...... + +--------------1F985EC911030AB70E0CD7B9-- + + + +-- +--bill