Network Working Group
Dave ThalerAlain Durand INTERNET-DRAFT Microsoft March 1,SUN Microsystems, inc. June 14, 2002 Jun-ichiro itojun Hagino Expires AugustDecember 2002 IIJ Research Laboratory IPv6 StatelessDave Thaler Microsoft Well known site local unicast addresses for DNS Discovery <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 This documentdocuments specifies the stepsa host takes in deciding howmethod for nodes to autoconfigure the addresses offind a DNS Servers required for name resolutionresolver with minimum configuration in IP version 6. The autoconfiguration process includes determining whether such information should be obtained through the stateless mechanism, the stateful mechanism, or both. This document definesthe process for acquiring a list of DNS server addresses. Approaches for acquiring a domain search path,network and the domain name of the host viawithout running a stateless mechanism are Draft Stateless DNS Discovery March 2002 included in an appendix for further study. The details of autoconfiguration using the statefuldiscovery protocol are 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 a per-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 to name 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 to obtainbe fully operational on a network, many other parameters are needed, such information. This isas the purposeaddress of this document. Fora host to effectively resolve names of other hosts, and potentially allow resolution of itsDNS resolver, mail relays, web proxies, etc. Except for name to be performed,resolution, all the following parametersother services are typically required: o Oneusually described using names, not addresses, such as smtp.myisp.net or more 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, a device desiringnode needs to perform name resolution. o A per-interface domain name ofbe configured with the host itself, and is equivalent toIP address (and not the Domain 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 is enabled, and the host respondssome incentive to queries for its own name,make this configuration as wellautomatic and simple as when DNS Dynamic Update is enabled. Depending on the implementation, the per-interface domain name may or may notpossible. Although it would be the same thing as the primary domain name of the host. o Search path. Itdesirable to have all configuration parameters configured/discovered automatically, it is currentlycommon practice forin IPv4 today to ask the search pathuser to be computeddo manual configuration for some of them by entering server names in a device based on its domain name(s). However, a DHCP option [DOMSEARCH] has been proposed, and so search pathconfiguration is likely to beform. So, a requirement 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 the requirements and solution space, which was usedDNS resolver is seen as an important step forward in the basisautoconfiguration story. The intended usage scenario for this document. One result of this analysis was that thereproposal is a spectrum 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 to configure/discovery all types of information.autoconfigure. This style works wellproposal is also usefull in an administered environmentcellular networks where a network administrator wants to have a central pointall moble devices are included within the same site. 2. Pre-configuration vs discovery Some of Draft Statelessthe discussions in the past around DNS Discovery March 2002 control, and apply policies, etc. Atserver discovery have been trying to characterize the other end, each protocolsolution space into stateless versus stateful or server-oriented versus severless. It is self-configuring, rather than depending onnot absolutely clear how much state if any other 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 and worksa server are well in 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 the benefits (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 the latter approach when "Other stateful configuration"service. One avenue is not set. Note: This document only includesto ask the IPv6 node to participate in its bodya solution for obtainingdiscovery protocol, such as SLP or DHCP, learn the address of Domain Name Service servers. Mechanisms for obtainingthe other 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) a separate document inlocal scope address on the future. 2. Overview A set of three well-known site-localIPv6 addresses are reserved for autodiscovery of DNS servers. These addresses may be used as unicast addresses assignednode and let it send packets directly to different servers. The use of the addresses as anycast addressesthis address, with one of them being assigned to all DNS servers inthe site, or any combination of anycast and unicast addresses, is for further study. Host routes for these addresses are propagated inunderlying assumption that the site'srouting tables.system will forward them to the right place. This document proposesexplores this later avenue of pre-configuration that these three addresses be: fec0:0:0:ffff::1 fec0:0:0:ffff::2 fec0:0:0:ffff::3 This listdoes not require participation of three addresses maythe end node in the DNS resolver discovery mechanism. The mechanism described here is to be hardcoded intoused as a host. Furthermore, we define two levels of functionality. Level 1 is defined below. Level 2last resort, when no other configuration information is described in Appendix Aavailable. 3. Reserved Prefix and addresses The basic idea of this proposal is for 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 addresses abovefor actual name resolution. It provides only rudimentary functionality. In particular, it does not provide the ability toDNS resolvers and then have separate configuration for hosts on different subnets, nor to provide hosts with a domain name other than one for whichthe routing system forward the DNS server is authoritative. 3.1.request to those DNS Server Configuration Level 1 functionality requires noresolvers. IPv6 nodes will be pre-configured (hard coded) with those three IPv6 addresses as DNS server configuration other than assigningresolver. Each local DNS resolvers should be configured with one of the well-knownthose three addresses to enable clients to switch from one ofto the server's interfaces. A host route must thenother if one fails. Host routes for each of those resolvers should be injected intoin the local routing domain, 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 by configuringa static host routerouter on the server's router, and redistributing it intosame subnet. If the intra-domain routing protocol. A host route must then be injected intonode running the site's routing infrastructure. Route injection can be done via any of several methods, including but not limited to: a) RunDNS resolver goes down, the server on a router,router may or may not be notified and configure it to injectkeep announcing the hostroute. b) RunRunning a routing protocol on the server, and configure it to inject the host route. Note that this requires that the server and its router(s) must run thesame routing protocol, at least for communication betweennode running the router(s) andDNS resolver. If the server(s) onprocess running the link. However, a server does not need to participate fully inDNS resolver dies, the routing protocol, it only needs toprotocol may or may not be able to inject routes.notified and keep annoucing the route. c) Run multiple servers onRunning a routing protocol within the same link(s), and configure their local router(s) to inject host routes forprocess running the well-known address intoDNS resolver. If the DNS resolver and the site'srouting infrastructure. Running multiple servers onprotocol run in separated threads, similar concerns as above are true. d) Having an "announcement" protocol that the same link provides robustnessDNS resolver could use to advertize the failure of a server, while routing provides robustnesshost route to the lossnearby router. Details of routers and other links. There may still be some failures, however,such asa unidirectional failure of the router's interface, whichprotocols are not handled byout of scope of this option. 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 the routers ontraffic to the linkDNS resolver stays local to periodically solicit (using Neighbor Discovery)the well-known address, and injectsite. This will prevent the Draft StatelessDNS Discovery March 2002 host route based on whetherrequests from accidentally leaking out of the site. However, the local resolver can implement a reply is received. 3.2. Host Behavior The host sets itspolicy to forward DNS server list equalresolution of non-local addresses to the setan external DNS resolver. -b) Reverse DNS resolution of threesite local addresses listed above. The search path is not discovered, butis generated fromonly meaningful within the host'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 currently common 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. If desired,a per-interface domain name canglobal prefix was chosen for this mechanism, concerns raised in a) could be obtained by sending a query (with the Recursion Desired (RD) bit set), doingaddressed using a reverse lookup forsimple access list on the well-known site-local IPv6 destination address,site exit routers and extracting the domain name from the NS recordconcerns raised in b) would disappear. 5. Examples of use This section presents example scenarios showing how the reply. 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 that queries reachmanages a legitimatefull flavor general purpose DNS server relies onresolver and a large number of nodes running DNS stub resolvers. The DNS resolver is performing (and caching) all the securityrecursive queries on behalf of the IPv6 routing infrastructure. The issues herestub resolvers. Those stub resolvers are either manually configured with the same as those for protecting basicIPv6 connectivity. IPsec/IKE can be used whenaddress of the well-known addresses are used as unicast addresses. The payload can be protected as follows. Ifresolver or with one (or several) of the client can preconfigure awell known private 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 the same packets presentedwell known address) 5.2 DNS forwarder A drawback of the choice of site local scope for the query. If thisreserved addresses for DNS resolver is notthat, in the case, then TSIG keys will havecase of a home/small office network connected to an ISP, DNS traffic cannot be negotiated using [TKEY]. Aftersent directly to the client hasISP DNS resolver without having the proper key thenISP and all its customers share the query can be performed. 5. IANA Considerations The IANA should assignsame definition of site. In this scenario, the following 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 be used as well-knownconfigured on its internal interface with one of the reserved site local addresses assigned toand listen for DNS servers: fec0:0:0:ffff::1 fec0:0:0:ffff::2 fec0:0:0:ffff::3. [Notequeries. It would be configured to readers:use one (or several) of the abovewell known site local unicast addresses are tentative, butwithin the ffff is intendedISP's site to be consistent withsend its own queries to. It would act as a simultaneous proposalDNS forwarder, forwarding queries received on its internal interface to reservethe ffff 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 DNS Discovery 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: email@example.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: firstname.lastname@example.org Draft Stateless DNS Discovery March 2002 9. Appendix A - Level 2 Compliance Level 2 compliance allowsresolver. ------------- / | ---------- -------------- / | |ISP | |customer CPE| / Customer | |DNS |===========| DNS|====< site administrators 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 this way, 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, the form "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 a comma-separated list of domain suffixes. The mDNS enabled flag is expressedmulti-sited router. 5.3 DNS forwarder with a 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 be expressed as defaults for the entire site, as well as per-subnet overrides if desired. To express site defaults, the record ownerused is a wildcard, namely *.local.arpa. The format of per-subnet overrides is described in the next section. [NOTE WELL:between the use of "local.arpa"PE and the 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] and any 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 TheDNS server 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 and a 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 used as a last resort. 2) Convertat the subnet prefix tosame time within a string by takingsite to discover the lower 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 with underscores. Table 2 below shows some examples. This notation is used so that it uses onlyone token, is unique per prefix,of the reserved site local addresses and is human readable. Draft Statelesslisten for DNS Discovery 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 queries Once the query is formed,to the host initially sendsDNS resolver pointed out by the query using UDP to each discovery addressISP in turn until a reply is received, or until the end ofthe list is reached. To avoid implosion problems when an entireDHCPv6 exchange. ------------- / | ---------- -------------- / | |ISP | |customer CPE| / Customer | |DNS |===========| DNS|====< site reboots such| |resolver| <------|---forwarder|-----\---- | ---------- -------------- \ | \ | ------------- The same CPE router could also act as after a power outage, the first request should wait 3 seconds fora reply, withlocal DHCPv6 server, advertising either itself as DNS forwarder. ------------- / | -------- -------------- / Customer | |ISP PE| |customer CPE| / site | | |===========|DHCPv6 |====< | | | |server------|-----\---> | -------- -------------- \ | \ | ------------- Within the wait period doubling for each subsequent request. Sincesite: a) DHCPv6 aware clients could use DHCPv6 to obtain the destinationaddress may be an anycast address,of the reply 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 the replyDNS forwarder is aquired via DHCPv6.) b) other nodes may simply becausesend their DNS request to the source 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.) A more detailed discussionvariant of this issue 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 is present,the listCPE can decide to pass the global address of server addresses is extracted fromthe value. 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 DNS server list containing only the anycast address, subject to the limitations discussedresolver in the next 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 the list obtainedinternal nodes. 6. IANA considerations The site local prefix fec0:0000:0000:ffff::/64 is used into be reserved out of the same 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 the list had been obtained (or failedfec0:0000:0000:ffff::/64 are reserved for future use and are expected to be obtained) via DHCP. Ifassigned only with IESG approval. 7. Security Considerations Ensuring that queries reach a domainname attribute is present, the domain name is extracted Draft Statelesslegitimate DNS Discovery March 2002 fromserver relies on the value.security of the IPv6 routing infrastructure. The domain name (or lack thereof) is used inissues here are the same wayas ifthose for protecting basic IPv6 connectivity. IPsec/IKE can be used as the list had been obtained (or failed towell-known addresses are used as unicast addresses. The payload can be obtained) via DHCP.protected using standard DNS security techniques. If the searchpath attribute is present,client can preconfigure a well known private or public key then TSIG [TSIG] can be used with the search path is extracted fromsame packets presented for the value.query. If this is not present,the host usescase, then TSIG keys will have to be negotiated using [TKEY]. After the search path it would use if no path had been obtained if DHCP were in use. Ifclient has the mdnsenabled attribute is present,proper key then the value 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 not enabled. Draftleak out of the site. 8. References [ADDRCONF] Thomson, S., and T. Narten, "IPv6 Stateless DNSAddress Autoconfiguration", RFC 2462, December 1998. [MLD] Deering, S., Fenner, W., Haberman, B., "Multicast Listener Discovery March 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: email@example.com Dave Thaler Microsoft One Microsoft Way Redmond, CA 98052, USA Email: firstname.lastname@example.org 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.