Network Working GroupDave ThalerAlain Durand INTERNET-DRAFTMicrosoft March 1,SUN Microsystems, inc. June 14, 2002 Jun-ichiro itojun Hagino ExpiresAugustDecember 2002 IIJ Research LaboratoryIPv6 StatelessDave Thaler Microsoft Well known site local unicast addresses for DNSDiscovery <draft-ietf-ipv6-dns-discovery-04.txt>resolver <draft-ietf-ipv6-dns-discovery-05.txt> Status of this Memo 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 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 a "work in progress". To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract Thisdocumentdocuments specifiesthe stepsahost takes in deciding howmethod for nodes toautoconfigure the addresses offind a DNSServers required for name resolutionresolver with minimum configuration inIP version 6. The autoconfiguration process includes determining whether such information should be obtained through the stateless mechanism, the stateful mechanism, or both. This document definestheprocess for acquiring a list of DNS server addresses. Approaches for acquiring a domain search path,network andthe domain name of the host viawithout running astateless mechanism are Draft Stateless DNS Discovery March 2002 included in an appendix for further study. The details of autoconfiguration using the statefuldiscovery protocolare specified elsewhere.on the nodes. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.Draft Stateless DNS Discovery March 20021. Introduction RFC 2462 [ADDRCONF]specifies "OtherConfigFlag" asprovides aper-interface variable, which is set from the value of the "O" ("Other stateful configuration") flag in Router Advertisements received. When OtherConfigFlag is set on an interface, information relatedway toname resolution is obtained using the stateful autoconfiguration mechanism.autoconfigure nodes with one or more IPv6 address and default routes. However,when OtherConfigFlag is not set, it does not describe howfor a node toobtainbe fully operational on a network, many other parameters are needed, suchinformation. This isas thepurposeaddress ofthis document. Forahost to effectively resolve names of other hosts, and potentially allow resolution of itsDNS resolver, mail relays, web proxies, etc. Except for nameto be performed,resolution, all thefollowing parametersother services aretypically required: o Oneusually described using names, not addresses, such as smtp.myisp.net ormore addresses of Domain Name Service (DNS) [RFC1034, RFC1035] servers. The function of name-to-address resolution (or vice versa) in IP is performed by DNS, which requires that at least one DNS Server be known and reachable bywebcache.myisp.net. For obvious bootstrapping reasons, adevice desiringnode needs toperform name resolution. o A per-interface domain name ofbe configured with thehost itself, and is equivalent toIP address (and not theDomain Name option in [DHCP]. This can be used when Multicastname) of a DNS resolver. As IPv6 addresses look much more complex than IPv4 ones, there isenabled, and the host respondssome incentive toqueries for its own name,make this configuration aswellautomatic and simple aswhen DNS Dynamic Update is enabled. Depending on the implementation, the per-interface domain name may or may notpossible. Although it would bethe same thing as the primary domain name of the host. o Search path. Itdesirable to have all configuration parameters configured/discovered automatically, it iscurrentlycommon practiceforin IPv4 today to ask thesearch pathuser tobe computeddo manual configuration for some of them by entering server names in adevice based on its domain name(s). However, a DHCP option [DOMSEARCH] has been proposed, and so search pathconfigurationis likely to beform. So, arequirement in general. o mDNS-enabled flag. This parameter controls whether Multicast DNS [MDNS] should be enabled on the host's interface. A design team recommendation [DDDT] contains an analysissolution that will allow for automatic configuration of therequirements and solution space, which was usedDNS resolver is seen as an important step forward in thebasisautoconfiguration story. The intended usage scenario for thisdocument. One result of this analysis was that thereproposal is aspectrum of configuration/discovery mechanisms. At one end, a single protocol is usedhome or enterprise network where IPv6 nodes are plugged/unplugged with minimum management and use local resources available on the network toconfigure/discovery all types of information.autoconfigure. Thisstyle works wellproposal is also usefull inan administered environmentcellular networks wherea network administrator wants to have a central pointall moble devices are included within the same site. 2. Pre-configuration vs discovery Some ofDraft Statelessthe discussions in the past around DNSDiscovery March 2002 control, and apply policies, etc. Atserver discovery have been trying to characterize theother end, each protocolsolution space into stateless versus stateful or server-oriented versus severless. It isself-configuring, rather than depending onnot absolutely clear how much state if anyother protocol or server. This style provides optimal fate sharing,needs to be kept to perform DNS server discovery, and, although the semantic differences between a router andworksa server are wellin zero-configuration environments such as adhoc networks and simple networks without network administrator staff. The former mechanism is used withunderstood from a conceptual perspective, the"Other stateful configuration" flag is used, and this draft providescurrent implementations tend to blur thebenefits (and limitations) ofpicture. In another attempt to characterize different approaches, one can look at how much intelligence a client needs to have in order to use thelatter approach when "Other stateful configuration"service. One avenue isnot set. Note: This document only includesto ask the IPv6 node to participate inits bodyasolution for obtainingdiscovery protocol, such as SLP or DHCP, learn the address ofDomain Name Service servers. Mechanisms for obtainingtheother parameters listed above are included in an Appendix A for further study. These may be movedserver and send packets to this server. Another one is to pre-configure (hard- code) aseparate document inlocal scope address on thefuture. 2. Overview A set of three well-known site-localIPv6addresses are reserved for autodiscovery of DNS servers. These addresses may be used as unicast addresses assignednode and let it send packets directly todifferent servers. The use of the addresses as anycast addressesthis address, withone of them being assigned to all DNS servers inthesite, or any combination of anycast and unicast addresses, is for further study. Host routes for these addresses are propagated inunderlying assumption that thesite'sroutingtables.system will forward them to the right place. This documentproposesexplores this later avenue of pre-configuration thatthese three addresses be: fec0:0:0:ffff::1 fec0:0:0:ffff::2 fec0:0:0:ffff::3 This listdoes not require participation ofthree addresses maythe end node in the DNS resolver discovery mechanism. The mechanism described here is to behardcoded intoused as ahost. Furthermore, we define two levels of functionality. Level 1 is defined below. Level 2last resort, when no other configuration information isdescribed in Appendix Aavailable. 3. Reserved Prefix and addresses The basic idea of this proposal isfor further study. Draft Stateless DNS Discovery March 2002 3. Level 1 Compliance Level 1 compliance entails using theto reserve a well known IPv6 site local prefix and three well known IPv6 addressesaboveforactual name resolution. It provides only rudimentary functionality. In particular, it does not provide the ability toDNS resolvers and then haveseparate configuration for hosts on different subnets, nor to provide hosts with a domain name other than one for whichthe routing system forward the DNSserver is authoritative. 3.1.request to those DNSServer Configuration Level 1 functionality requires noresolvers. IPv6 nodes will be pre-configured (hard coded) with those three IPv6 addresses as DNSserver configuration other than assigningresolver. Each local DNS resolvers should be configured with one ofthe well-knownthose three addresses to enable clients to switch from oneofto theserver's interfaces. A host route must thenother if one fails. Host routes for each of those resolvers should be injectedintoin the local routingdomain, e.g.,system. Example methods for injecting host routes and a brief discussion of their fate sharing properties is presented here: a) Manual injection of routes byconfiguringastatic host routerouter on theserver's router, and redistributing it intosame subnet. If theintra-domain routing protocol. A host route must then be injected intonode running thesite's routing infrastructure. Route injection can be done via any of several methods, including but not limited to: a) RunDNS resolver goes down, theserver on a router,router may or may not be notified andconfigure it to injectkeep announcing thehostroute. b)RunRunning a routing protocol on theserver, and configure it to inject the host route. Note that this requires that the server and its router(s) must run thesamerouting protocol, at least for communication betweennode running therouter(s) andDNS resolver. If theserver(s) onprocess running thelink. However, a server does not need to participate fully inDNS resolver dies, the routingprotocol, it only needs toprotocol may or may not beable to inject routes.notified and keep annoucing the route. c)Run multiple servers onRunning a routing protocol within the samelink(s), and configure their local router(s) to inject host routes forprocess running thewell-known address intoDNS resolver. If the DNS resolver and thesite'sroutinginfrastructure. Running multiple servers onprotocol run in separated threads, similar concerns as above are true. d) Having an "announcement" protocol that thesame link provides robustnessDNS resolver could use to advertize thefailure of a server, while routing provides robustnesshost route to thelossnearby router. Details ofrouters and other links. There may still be some failures, however,suchasaunidirectional failure of the router's interface, whichprotocols arenot handled byout of scope of thisoption. d) Modifydocument, but something similar to [MLD] is possible. IANA considerations for this prefix are covered in Section 6. 4. Site local versus global scope considerations The rationales for having a site local prefix are: -a) Using a site local prefix will ensure that therouters ontraffic to thelinkDNS resolver stays local toperiodically solicit (using Neighbor Discovery)thewell-known address, and injectsite. This will prevent theDraft StatelessDNSDiscovery March 2002 host route based on whetherrequests from accidentally leaking out of the site. However, the local resolver can implement areply is received. 3.2. Host Behavior The host sets itspolicy to forward DNSserver list equalresolution of non-local addresses tothe setan external DNS resolver. -b) Reverse DNS resolution ofthreesite local addresseslisted above. The search path is not discovered, butisgenerated fromonly meaningful within thehost's domain name(s) assite. Thus, making sure that such queries are first sent to a DNS resolver located within the site perimeter increase their likelyhood of success. Note: there is currentlycommon practice.some discussions about the usefulness of site local addresses in the IPv6 architecture. Depending on the outcome of this discussion, this section will need to be revisited. Ifdesired,aper-interface domain name canglobal prefix was chosen for this mechanism, concerns raised in a) could beobtained by sending a query (with the Recursion Desired (RD) bit set), doingaddressed using areverse lookup forsimple access list on thewell-known site-local IPv6 destination address,site exit routers andextracting the domain name from the NS recordconcerns raised in b) would disappear. 5. Examples of use This section presents example scenarios showing how thereply. 4. Security Considerations Ensuringmechanism described in this memo can co-exist with other techniques, namely manual configuration and DHCPv6 discovery. 5.1 Simple case, general purpose DNS resolver This example shows the case of an enterprise or a cellular network thatqueries reachmanages alegitimatefull flavor general purpose DNSserver relies onresolver and a large number of nodes running DNS stub resolvers. The DNS resolver is performing (and caching) all thesecurityrecursive queries on behalf of theIPv6 routing infrastructure. The issues herestub resolvers. Those stub resolvers are either manually configured with thesame as those for protecting basicIPv6connectivity. IPsec/IKE can be used whenaddress of thewell-known addresses are used as unicast addresses. The payload can be protected as follows. Ifresolver or with one (or several) of theclient can preconfigure awell knownprivate or public key then TSIG [TSIG] can be usedsite local unicast addresses defined in this memo. ------------------------------------------- | | | --------------------- | | |manually configured| | | |DNS stub resolver | | | --------------------- | | ---------- | | | |DNS |<----------- | | |resolver|<----------- | | ---------- | | | --------------------- | | |DNS stub resolver | | | |configured with | | | |well known address | | | --------------------- | | | ------------------------------------------- (The DNS resolver is configured to listen both on its IPv6 address and on thesame packets presentedwell known address) 5.2 DNS forwarder A drawback of the choice of site local scope for thequery. If thisreserved addresses for DNS resolver isnotthat, in thecase, then TSIG keys will havecase of a home/small office network connected to an ISP, DNS traffic cannot benegotiated using [TKEY]. Aftersent directly to theclient hasISP DNS resolver without having theproper key thenISP and all its customers share thequery can be performed. 5. IANA Considerations The IANA should assignsame definition of site. In this scenario, thefollowing site-local IPv6 addresseshome/small office network is connected to the ISP router (PE) via an edge router (CPE). Prefix delegation is performed out of band is is out of scope of this memo. ------------- / | -------- -------------- / | |ISP PE| |customer CPE| / Customer | | |===========| |====< site | | | | | \ | -------- -------------- \ | \ | ------------- The customer router CPE could beused as well-knownconfigured on its internal interface with one of the reserved site local addressesassigned toand listen for DNSservers: fec0:0:0:ffff::1 fec0:0:0:ffff::2 fec0:0:0:ffff::3. [Notequeries. It would be configured toreaders:use one (or several) of theabovewell known site local unicast addressesare tentative, butwithin theffff is intendedISP's site tobe consistent withsend its own queries to. It would act as asimultaneous proposalDNS forwarder, forwarding queries received on its internal interface toreservetheffff SLA for use with IANA-assigned addresses such as these.] Draft Stateless DNS Discovery March 2002 6. Acknowledgements The IPv6 DNS Discovery Design Team [DDDT] provided recommendations that formed the basis of this specification. Rob Austein and the IPv6 Working Group provided valuable feedback on the mechanism. Aaron Schrader provided helpful comments as well. Robert Hinden edited this version of the document. 7. References [ADDRCONF] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [ANYCAST] Hagino, Jun-ichiro itojun, and K. Ettikan, "An analysis of IPv6 anycast", draft-ietf-ipngwg-ipv6-anycast- analysis-00.txt, Work in progress, July 2001. [DDDT] Thaler, D., Editor, "Analysis of DNS Server Discovery Mechanisms for IPv6", draft-ietf-ipngwg-dns-discovery- analysis-00.txt [DIFFSEC] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. [DNSSEC] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [DOMSEARCH] B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc- domsearch-01.txt, December 2000. [MDNS] Esibov, L., Aboba, B., and D. Thaler, draft-ietf-dnsext- mdns-03.txt, July 2001. [TKEY] D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)" RFC 2930, September 2000. Draft StatelessISP's DNSDiscovery March 2002 [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. 8. Authors' Addresses Dave Thaler Microsoft One Microsoft Way Redmond, CA 98052, USA Email: dthaler@microsoft.com Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku, Tokyo 101-0054, JAPAN Email: itojun@iijlab.net Draft Stateless DNS Discovery March 2002 9. Appendix A - Level 2 Compliance Level 2 compliance allowsresolver. ------------- / | ---------- -------------- / | |ISP | |customer CPE| / Customer | |DNS |===========| DNS|====< siteadministrators to have site-wide defaults for all name resolution parameters, and optionally to have subnet-specific overrides. However, it defines a new DNS record type to hold name resolutioin configuration information.| |resolver| <------|---forwarder|-----\---- | ---------- -------------- \ | \ | ------------- In thisway, DNS becomes self-configuring. 9.1. DNS Server Configuration A new record type, CFG, is defined, with a syntax as follows: <owner> <class> <ttl> CFG "<attribute name>=<attribute value>" The set of attribute names is described below. This set may be extended by other RFCs, but any new attributes MUST be specific to name resolution. The DNS server list is expressed with a string ofconfiguration, theform "dnsservers=<address>[,<address>]*" where the attribute value is a comma-separated list of one or more addresses (either IPv4 or IPv6) in string literal format suitable for passing to getaddrinfo. The domain name to use is expressed with a string of the form "domainname=<domain>" where the attribute value is the domain name the client should use. The domain suffix search path is expressed with a string of the form "searchpath=<domain>[,<domain>]*" where the attribute valueCPE is acting as acomma-separated list of domain suffixes. The mDNS enabled flag is expressedmulti-sited router. 5.3 DNS forwarder witha string of the form "mdnsenabled=<value>" where the attribute value is either "true" or "false". Name resolution information canDHCPv6 interactions In this variant scenario, DHCPv6 could beexpressed as defaults for the entire site, as well as per-subnet overrides if desired. To express site defaults, the record ownerusedis a wildcard, namely *.local.arpa. The format of per-subnet overrides is described in the next section. [NOTE WELL:between theuse of "local.arpa"PE andthe CFG record syntax shown above are just placeholders until DNS experts figure out what the right thing is.] Draft Stateless DNS Discovery March 2002 Each of the attributes described herein are optional,CPE to do prefix delegation [DELEG] andany combination may be used, except that only one record per attributename should be present per owner (site or subnet) string. *.local.arpa IN CFG "dnsservers=fec0:0:1::1,fec0:0:2::2" *.local.arpa IN CFG "domainname=example.com" *.local.arpa IN CFG "searchpath=foo.example.com, bar.example.com,example.com" *.local.arpa IN CFG "mdnsenabled=true" Table 1: Example configuration TheDNSserver must also be assigned one of the well-known site- local addresses, and a host route must be injected into the site's routing infrastructure, e.g. using one of the methods described above in Section 3.1. 9.2. Host Behavior When an interface comes up,resolver discovery. ------------- / | -------- -------------- / | |ISP | |customer CPE| / Customer | |DHCPv6|===========| DHCPv6|====< site | |server| <------|------client| \ | -------- -------------- \ | \ | ------------- This example will show how DHCPv6 anda host determines that the OtherConfigFlag on the interface is off, then it takes the following actions. The host constructs a DNS query for CFG records for "<subnet>.local.arpa.", where <subnet> is constructed from an onlink prefix as follows: 1) Determine the onlink prefix to use. Any onlink site-local prefix is used, if present. Otherwise, any onlink global prefix is used. If no other onlink prefixes are present (e.g., if no routers are present), the link-local prefix iswell known site local unicast addresses can be usedas a last resort. 2) Convertat thesubnet prefix tosame time within astring by takingsite to discover thelower case string literal representation, with no zero compression, and replacing all colonsaddress of the DNS forwarder. The customer router CPE could be configured on its internal interface withunderscores. Table 2 below shows some examples. This notation is used so that it uses onlyonetoken, is unique per prefix,of the reserved site local addresses andis human readable. Draft Statelesslisten for DNSDiscovery March 2002 Prefix String ----------------- -------------------------------------- fec0:0:0:1::/64 fec0_0000_0000_0001.local.arpa 3ffe:ffff:0:1234::/64 3ffe_ffff_0000_1234.local.arpa fe80::/64 fe80_0000_0000_0000.local.arpa Table 2: Examplequeries. It would act as a DNS forwarder, forwarding those queriesOnce the query is formed,to thehost initially sendsDNS resolver pointed out by thequery using UDP to each discovery addressISP inturn until a reply is received, or until the end ofthelist is reached. To avoid implosion problems when an entireDHCPv6 exchange. ------------- / | ---------- -------------- / | |ISP | |customer CPE| / Customer | |DNS |===========| DNS|====< sitereboots such| |resolver| <------|---forwarder|-----\---- | ---------- -------------- \ | \ | ------------- The same CPE router could also act asafter a power outage, the first request should wait 3 seconds forareply, withlocal DHCPv6 server, advertising either itself as DNS forwarder. ------------- / | -------- -------------- / Customer | |ISP PE| |customer CPE| / site | | |===========|DHCPv6 |====< | | | |server------|-----\---> | -------- -------------- \ | \ | ------------- Within thewait period doubling for each subsequent request. Sincesite: a) DHCPv6 aware clients could use DHCPv6 to obtain thedestinationaddressmay be an anycast address,of thereply will necessarily come from a different address. The host must not discardDNS forwarder... ------------- / | ---------- -------------- / Customer | |ISP | |customer CPE| / site | |DNS |===========| DNS|====< | |resolver| <------|---forwarder|-----\----DHCPv6 | ---------- -------------- \ client | \ | ------------- (The address of thereplyDNS forwarder is aquired via DHCPv6.) b) other nodes may simplybecausesend their DNS request to thesource address is different.reserved site local addresses. ------------- / | ---------- -------------- / customer | |ISP | |customer CPE| / site | |DNS |===========| DNS|====< | |resolver| <------|---forwarder|-----\----non DHCPv6| ---------- -------------- \ node | \ | ------------- (Internal nodes use the reserved site local unicast address.) Amore detailed discussionvariant of thisissue can be found in [ANYCAST]. Upon receiving a response, the host parses the CFG records and acts on the information as follows. If a dnsservers attributescenario ispresent,thelistCPE can decide to pass the global address ofserver addresses is extracted fromthevalue. If no such attribute is present (or if no reply is received), an implementation-specific default list is used. For example: o an implementation MAY use an empty list (effectively disabling name resolution), o a host MAY use aISP DNSserver list containing only the anycast address, subject to the limitations discussedresolver in thenext section, o a host MAY use mDNS [MDNS] only, or o a host MAY use some combination of the above. In general,DHCPv6 exchange with thelist obtainedinternal nodes. 6. IANA considerations The site local prefix fec0:0000:0000:ffff::/64 isused into be reserved out of thesame way as ifsite local fec0::/10 prefix. The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 and fec0:000:0000:ffff::2 are to be reserved for DNS resolver configuration. All other addresses within thelist had been obtained (or failedfec0:0000:0000:ffff::/64 are reserved for future use and are expected to beobtained) via DHCP. Ifassigned only with IESG approval. 7. Security Considerations Ensuring that queries reach adomainname attribute is present, the domain name is extracted Draft Statelesslegitimate DNSDiscovery March 2002 fromserver relies on thevalue.security of the IPv6 routing infrastructure. Thedomain name (or lack thereof) is used inissues here are the samewayasifthose for protecting basic IPv6 connectivity. IPsec/IKE can be used as thelist had been obtained (or failed towell-known addresses are used as unicast addresses. The payload can beobtained) via DHCP.protected using standard DNS security techniques. If thesearchpath attribute is present,client can preconfigure a well known private or public key then TSIG [TSIG] can be used with thesearch path is extracted fromsame packets presented for thevalue.query. If this is notpresent,thehost usescase, then TSIG keys will have to be negotiated using [TKEY]. After thesearch path it would use if no path had been obtained if DHCP were in use. Ifclient has themdnsenabled attribute is present,proper key then thevalue is extracted. If not present, mDNS isquery can be performed. The use of site local addresses instead of global addresses will ensure the DNS queries issued by host using this mechanism will notenabled. Draftleak out of the site. 8. References [ADDRCONF] Thomson, S., and T. Narten, "IPv6 StatelessDNSAddress Autoconfiguration", RFC 2462, December 1998. [MLD] Deering, S., Fenner, W., Haberman, B., "Multicast Listener DiscoveryMarch 2002(MLD) for IPv6", RFC2710, October 1999. [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC2845, May 2000. [TKEY] D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)", RFC2930, September 2000. [DHCPv6] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), Februray 2002. [DELEG] Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6", draft-troan-dhcpv6-opt-prefix-delegation-00.txt (work in progress), February 2002. 9. Authors' Addresses Alain Durand SUN microsystems, inc. 901 San Antonio rd UMPK 17-202 Palo Alto, CA 94303, USA. Email: Alain.Durand@sun.com Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku, Tokyo 101-0054, JAPAN Email: itojun@iijlab.net Dave Thaler Microsoft One Microsoft Way Redmond, CA 98052, USA Email: dthaler@microsoft.com 10. Full Copyright Statement Copyright (C) The Internet Society(2001).(2002). 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 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.