From 23924b681e7ca8e2538529b5d55ddcce9b90f41b Mon Sep 17 00:00:00 2001 From: Brian Wellington Date: Mon, 10 Dec 2001 04:49:32 +0000 Subject: [PATCH] updates --- ...> draft-ietf-dnsext-rfc2539bis-dhk-01.txt} | 39 +- .../draft-ietf-ngtrans-dns-ops-req-03.txt | 480 ++++++++++++++++++ .../draft-lewis-dnsext-key-genprot-00.txt | 141 +++++ 3 files changed, 641 insertions(+), 19 deletions(-) rename doc/draft/{draft-ietf-dnsext-rfc2539bis-dhk-00.txt => draft-ietf-dnsext-rfc2539bis-dhk-01.txt} (92%) create mode 100644 doc/draft/draft-ietf-ngtrans-dns-ops-req-03.txt create mode 100644 doc/draft/draft-lewis-dnsext-key-genprot-00.txt diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-00.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-01.txt similarity index 92% rename from doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-00.txt rename to doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-01.txt index c503b2d8e5..14fdfed53e 100644 --- a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-00.txt +++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-01.txt @@ -1,14 +1,15 @@ + INTERNET-DRAFT Diffie-Hellman Keys in the DNS OBSOLETES: RFC 2539 Donald Eastlake 3rd Motorola -Expires: January 2002 July 2001 +Expires: May 2002 November 2001 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) ------- -- -------------- ---- -- --- ------ ---- ------ ----- - + Donald E. Eastlake 3rd @@ -53,7 +54,7 @@ Status of This Document -Donald Eastlake 3rd [Page 1] +D. Eastlake 3rd [Page 1] INTERNET-DRAFT Diffie-Hellman Keys in the DNS @@ -111,7 +112,7 @@ Acknowledgements -Donald Eastlake 3rd [Page 2] +D. Eastlake 3rd [Page 2] INTERNET-DRAFT Diffie-Hellman Keys in the DNS @@ -169,7 +170,7 @@ Table of Contents -Donald Eastlake 3rd [Page 3] +D. Eastlake 3rd [Page 3] INTERNET-DRAFT Diffie-Hellman Keys in the DNS @@ -177,11 +178,11 @@ INTERNET-DRAFT Diffie-Hellman Keys in the DNS 1. Introduction - The Domain Name System (DNS) is the current global hierarchical - replicated distributed database system for Internet addressing, mail - proxy, and similar information. The DNS has been extended to include - digital signatures and cryptographic keys as described in [RFC 2535]. - Thus the DNS can now be used for secure key distribution. + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + similar information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC 2535]. Thus + the DNS can now be secured and used for key distribution. @@ -189,7 +190,7 @@ INTERNET-DRAFT Diffie-Hellman Keys in the DNS This document describes how to store Diffie-Hellman keys in the DNS. Familiarity with the Diffie-Hellman key exchange algorithm is assumed - [Schneier]. + [Schneier, RFC 2631]. @@ -227,7 +228,7 @@ INTERNET-DRAFT Diffie-Hellman Keys in the DNS in deciding on a p and g, see [RFC 2631]. -Donald Eastlake 3rd [Page 4] +D. Eastlake 3rd [Page 4] INTERNET-DRAFT Diffie-Hellman Keys in the DNS @@ -285,7 +286,7 @@ INTERNET-DRAFT Diffie-Hellman Keys in the DNS -Donald Eastlake 3rd [Page 5] +D. Eastlake 3rd [Page 5] INTERNET-DRAFT Diffie-Hellman Keys in the DNS @@ -343,7 +344,7 @@ INTERNET-DRAFT Diffie-Hellman Keys in the DNS -Donald Eastlake 3rd [Page 6] +D. Eastlake 3rd [Page 6] INTERNET-DRAFT Diffie-Hellman Keys in the DNS @@ -394,14 +395,14 @@ Author's Address Expiration and File Name - This draft expires in January 2002. + This draft expires in May 2002. - Its file name is draft-ietf-dnsext-rfc2539bis-dhk-00.txt. + Its file name is draft-ietf-dnsext-rfc2539bis-dhk-01.txt. -Donald Eastlake 3rd [Page 7] +D. Eastlake 3rd [Page 7] INTERNET-DRAFT Diffie-Hellman Keys in the DNS @@ -459,7 +460,7 @@ A.2. Well-Known Group 2: A 1024 bit prime -Donald Eastlake 3rd [Page 8] +D. Eastlake 3rd [Page 8] INTERNET-DRAFT Diffie-Hellman Keys in the DNS @@ -517,5 +518,5 @@ A.3. Well-Known Group 3: A 1536 bit prime -Donald Eastlake 3rd [Page 9] +D. Eastlake 3rd [Page 9] diff --git a/doc/draft/draft-ietf-ngtrans-dns-ops-req-03.txt b/doc/draft/draft-ietf-ngtrans-dns-ops-req-03.txt new file mode 100644 index 0000000000..c1823209b4 --- /dev/null +++ b/doc/draft/draft-ietf-ngtrans-dns-ops-req-03.txt @@ -0,0 +1,480 @@ +Internet Engineering Task Force Alain Durand +INTERNET-DRAFT SUN Microsystems +November 20, 2001 Johan Ihren +Expires May 21, 2002 Autonomica AB + + + + NGtrans IPv6 DNS operational requirements and roadmap + + draft-ietf-ngtrans-dns-ops-req-03.txt + + + + Status of this memo + + + This memo provides information to the Internet community. It does + not specify an Internet standard of any kind. This memo is in full + conformance with all provisions of Section 10 of RFC2026 [RFC2026]. + + 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. + + + +Abstract + + + This document describes IPv6 DNS operational requirements and + deployment roadmap steps. It is the result of discussion from members + of the IPv6, NGtrans, DNSop and DNSext working groups. The DNS is + looked as a critical part of the Internet infrastructure and is used + for much more purposes than name to address resolution. Thus a + smooth operation of the DNS is critical in the IPv6 transition. + + Discussion of this memo should happen in the NGtrans mailing list. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + + + +1. DNS issues in a mixed IPv4/IPv6 environment + + + IPv4 and IPv6 are two versions of the same original concept, but they + are not "binary compatible". That is, a datagram send by one version + of IP cannot be received by the other. Several things can go wrong + when operating DNS in a mixed environment IPv4 and IPv6. + + +1.1 Following the referral chain + + The caching resolver that tries to lookup a name starts out at the + root, and follows referrals until it is referred to a nameserver that + is authoritative for the name. If somewhere down the chain of + referrals it is referred to a nameserver that is only accessible over + a type of transport that is unavailable, a traditional nameserver is + unable to finish the task. + + When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is + only a matter of time until this starts to happen and the complete + DNS hierarchy starts to fragment into a graph where authoritative + nameservers for certain nodes are only accessible over a certain + transport. What is feared is that a node using only a particular + version of IP, querying information about another node using the same + version of IP can not do it because, somewhere in the chain of + servers accessed during the resolution process, one or more of them + will only be accessible with the other version of IP. + + +1.2 Examples of problems for an IPv6 only resolver + + This problem shows for IPv6 only resolver trying to fetch data from a + zone that is served by IPv6 servers when somewhere in the referral + chain, the list of name servers pointed at does not contain any IPv6 + reachable server. + + Hints for the root: + + X.ROOT-SERVERS.NET IN A 100.100.100.101 + X.ROOT-SERVERS.NET IN AAAA 3ffe:ffff:100:100::1 + + In the root zone: + + org. IN NS dot-org.X.ROOT-SERVERS.NET + dot-org.X.ROOT-SERVERS.NET IN A 100.100.100.102 + + In the .org zone: + + foobar.org. IN NS ns.foobar.org + ns.foobar.org IN A 200.200.200.201 + ns.foobar.org IN AAAA 3ffe:ffff:200:200::201 + + In the foobar.org zone: + + www.foorbar.org IN AAAA 3ffe:ffff:200:200::202 + + Although the zone foobar.org and the root are served by an IPv6 + server, an IPv6 only resolver can not resolve www.foobar.org because + there is no IPv6 server for the parent zone .org. + + +1.3 Examples of problems for an IPv4 only resolver + + Another instance of the problem shows for an IPv4 only MTA trying to + send mail to someone in an IPv6 only domain which has made provision + to have an IPv4 reachable MX. + + In the .org zone: + + foobar.org. IN NS ns.foobar.org + ns.foobar.org IN AAAA 3ffe:ffff:200:200::201 + + 3rd_party_dualstack_mail.org. IN NS ns.3rd_party_dualstack.org. + ns.3rd_party_dualstack.org. IN A 100.100.100.103 + + in the foobar.org zone: + + foobar.org IN MX 10 mail6.foobar.org. + foobar.org IN MX 20 mail4.3rd_party_dualstack.org. + mail6.foobar.org. IN AAAA 3ffe:ffff:200:200::202 + + in the 3rd_party_dualstack_mail.org zone: + + mail4.3rd_party_dualstack.org. IN A 100.100.100.104 + + An IPv4 only host cannot get the information about the IPv4 MX relay + mail4.3rd_party_dualstack_mail.org because the foobar.org zone is not + served by an IPv4 DNS server. + + + +2. Fundamental requirements + + +2.1 Uniqueness of the DNS root + + [RFC2826] requires the existence of a globally unique public name + space derived from a unique root. This root is valid for both IPv4 + and IPv6. + + -------------------------------------------------------------------- + Requirement 1: + + The public DNS has a unique root valid for IPv4 & IPv6. + -------------------------------------------------------------------- + + +2.2 DNS should be an IP version agnostic application + + Although DNS is regarded as a key component of the Internet + infrastructure, it is an application at layer 7 of OSI model and + should be independent from particular protocol choice at the network + layer. Some record type, like CNAME or MX are clearly IP version + agnostic. Even data like A, AAAA or PTR records contained in the DNS + may be relevant to particular applications requesting then regardless + of the IP version used during the queries. Also, [RFC2826] states, "A + DNS name can be passed from one party to another without altering the + semantic intent of the name." So, this is not because a particular + host can only communicate with a certain version of IP that it should + be prevented to query information regarding the over version of IP. + Another way of saying this is to say that the DNS data are + independent of the particular version of IP used to carry them. + + -------------------------------------------------------------------- + Requirement 2: + + Any node SHOULD be able to query any data from the DNS regardless of + the IP versions used for the transport of the queries and responses + issued by the various parties in place. + -------------------------------------------------------------------- + + +2.3 Transition is a long journey + + It is usually believed that transition can happen simultaneously following + two main scenarios. + + - Incremental deployment on existing network. + + This needs to be done without disturbing IPv4 service. This + strategy relies heavily on dual-stack nodes and tunnels. It is + foreseen that this scenario is likely to happen in corporate + networks. + + - Large scale deployment of new infrastructure + + This scenario envision large to very large networks where public + IPv4 address space is not available and private address is not + practical. Nodes in this scenario will very likely be IPv6-only + or IPv6-mostly (getting an IPv4 address only on demand). Note + that those networks will still need to communicate with the rest + of the Internet. + + Given the two above scenarios, the requirements discussed in this + memo are not targeted at transitioning the DNS from IPv4 only to IPv6 + only, but more at the transition of IPv4 only to a mixed environment, + where some systems will be IPv4 only, some will be IPv6 only and + others will be dual-stacked. + + It is generally admitted that, the burden of transition should be + placed on the new IPv6 systems and their local IPv6 infrastructure. + Ad-hoc administrative practices such as a local dual stack resolver + or locally Local dual stack resolver or locally administered NAT-PT + translator [RFC2766] could enable networks where some dual stacks + node are available to query IPv4 only DNS servers. (Note that NAT-PT + would have to be modified for that purpose as it translate AAAA + queries into A queries.) Administrative practices requiring any zone + served by IPv6 only servers to be also served by IPv4 servers would + enable IPv4 only resolvers to perform DNS queries for those zones. + + However, the requirements described here are looking at solving the + long term problem. Although dual stack networks will be common in the + early days of transition, IPv6 only networks would eventually be a + reality and solutions describe above would not be practical. + + + -------------------------------------------------------------------- + Requirement 3: + + A global bridging system IS REQUIRED to enable networks operating + with only one version of IP to query zones of the public DNS that are + only served by systems operating only with the over version of IP. + -------------------------------------------------------------------- + + The choice and the details of this bridging system are beyond the + scope of this document and should be discussed in the DNSop and + DNSext working groups. It can be the case that a general purpose, + ubiquitous translator will be the right thing or that a DNS specific + solution must be developed. If new pieces of protocols are needed in + the resolvers, due to the extraordinary amount of time it takes to + define then, implement them, test them, ship them into existing + products and get them deployed, works should start as soon as + possible. + + + +3. Bridging system requirements + + + Even though bridging has to work both ways, it is not strictly + necessary to use the same technique in each direction. That is, it is + perfectly acceptable to build two different mechanisms, one to enable + IPv4 only hosts to query IPv6 only DNS servers and one for IPv6 only + hosts to query IPv4 only DNS servers. It is also possible that part + of the bridging system consists of a set of administrative procedures + required to operate DNS zones. + + +3.1 IPv4 contraints + + Due to the very large IPv4 deployment phase, any solution that will + require any change either on binaries or configurations on every IPv4 + resolvers is out of scope. + + +3.2 Scaling the bridging system + + The bridging system that enable a resolver to query data from a + server which use a different IP version will have to be in place for + a long time. It will be a key part of the general IPv6 transition and + will heavily be used. + + -------------------------------------------------------------------- + Requirement 4: + + The bridging system SHOULD have good scaling properties. + -------------------------------------------------------------------- + + +3.3 Scaling even more the bridging system + + Auto configuration is the tendency for end systems. Resolver SHOULD + have a way to discover the bridging system components. This + discovery mechanism SHOULD also have good scaling properties. + + -------------------------------------------------------------------- + Requirement 5: + + The discovery mechanism of the bridging system SHOULD have good + scaling properties. + -------------------------------------------------------------------- + + +3.3 Scope of the bridging system + + The bridging systems SHOULD be able to bridge any zones. In + particular, until there is an IPv6 root name server, the bridging + systems SHOULD be able to bridge the IPv4 root. + + -------------------------------------------------------------------- + Requirement 6: + All zones (even the root) SHOULD be reachable via the bridging + system. + -------------------------------------------------------------------- + + +3.4 Security matters + + Being a critical piece of the Internet infrastructure, the DNS is a + potential value target and thus should be protected. Great care + should be used not to introduce new security issues while designing + the bridging system. + + -------------------------------------------------------------------- + Requirement 7: + + The bridging system SHOULD NOT introduce new security hazards. + -------------------------------------------------------------------- + + +3.5 bridging from IPv4 + + Although the details of the bridging systems are beyond the scope of + this document, it may be the case that there is no general solution + to allow an unmodified IPv4 resolver to query an IPv6 only name + server. In that would be the case, the IPv4 to IPv6 bridging system + could consist of an operational procedure: + + -------------------------------------------------------------------- + Possible operational procedure to bridge from IPv4 to IPv6: + + Any zone SHOULD be served by at least one IPv4 DNS server. + -------------------------------------------------------------------- + + + +4. Roadmap for DNS service in a mixed environment IPv4/IPv6 + + +4.1 Bridging system + + A bridging system satisfying all the above requirements SHOULD be in + place as early as possible to allow large scale IPv6 only DNS + deployment. + + -------------------------------------------------------------------- + Roadmap step 1: + + A robust, scalable bridging system should be defined, agreed and put + in place as soon as possible. + -------------------------------------------------------------------- + + +4.2 Root name service accessible via IPv6 + + The first DNS query a caching resolver will send is directed to a + root name server. This, if the configuration of the bridging system + is derived automatically from the DNS itself, there is a strong + requirement to make root name service available over IPv6 transport. + If the configuration is derived any other way or is done manually, + there is a possibility to operate the system without an IPv6 + accessible root in certain cases. However, as this document does not + want to preclude any particular implementation of the bridging system + at this point, it is highly recommended that some IPv6 enable root + name server be in place as early as possible. It is an important + step to show that IPv6 DNS deployment is possible. + + -------------------------------------------------------------------- + Roadmap step 2: + + The root SHOULD have at least one IPv6 name server. + -------------------------------------------------------------------- + + +4.3 TLDs servers accessible via IPv6 + + Having the capability to query a root name server using IPv6 is just + the first step. The next one is to query a TLD for a NS record + pointing to a domain name. Again, although not strictly necessary + from a technical perspective, it is important to make sure that some + TLD servers are accessible from the beginning via IPv6 so at least + some label strings are resolvable with IPv6 transport without + resorting to the bridging system. + + Also note that great care should be taken when adding IPv6 glue in + the TLD delegation by the root. + + -------------------------------------------------------------------- + Roadmap step 3: + + Each TLD zone SHOULD have at least one IPv6 name server. + -------------------------------------------------------------------- + + +4.4 IPv6 glue at TLD registries. + + Whenever glue is needed, it is necessary for domains delegated under + a TLD to be able to specify an IPv6 name server address to the TLD + registry. This is not so much a protocol issue but a management and + procedural issue. + + -------------------------------------------------------------------- + Roadmap step 4: + + Domains registering under TLDs SHOULD be able to specify IPv6 glue + wherever they are specifying IPv4 glue today. + -------------------------------------------------------------------- + + +4.5 Reverse path DNS servers + + Reverse DNS queries should also be supported in IPv6, for the same + reasons as direct queries. Today's resolvers do reverse nibbles + queries under the ip6.int tree. [RFC3152] has deprecated ip6.int, + thus reverse DNS queries MUST be moved to ip6.arpa. So, although + again not strictly speaking a technical requirement, it is important + to have at least one server for ip6.arpa accessible via IPv6. + + -------------------------------------------------------------------- + Roadmap step 5: + + The ip6.arpa zone SHOULD have at least one IPv6 server. + -------------------------------------------------------------------- + + + +5. Security considerations + + + Any bridging system, acting as open relay, could be misused to create + denial of service attacks on external DNS servers. Some provision + SHOULD be made in the design of those relay to deal with this issue. + + + +6 Authors addresses + + + Alain Durand + SUN Microsystems, Inc + 901 San Antonio Road + MPK17-202 + Palo Alto, CA 94303-4900 + USA + Mail: Alain.Durand@sun.com + + Johan Ihren + Autonomica AB + Bellmansgatan 30 + SE-118 47 Stockholm, Sweden + johani@autonomica.se + + + +7. References + + + [RFC2026] Bradner, S., + "The Internet Standards Process -- Revision 3", + BCP 9, RFC 2026, October 1996 + + [RFC2119] Bradner, S., + "Key words for use in RFCs to Indicate Requirement Levels", + BCP 14, RFC 2119, March 199 + + [RFC3152] Bush, R., + "Delegation of IP6.ARPA", + RFC 3152, August 2001 + + [RFC2826] Internet Architecture Board, + "IAB Technical Comment on the Unique DNS Root", + RFC 2826, May 2000 + + [RFC2766] Tsirtsis, G., Srisuresh, P., + "Network Address Translation - Protocol Translation (NAT-PT)", + RFC 2766, February 2000 + + + + + + + + diff --git a/doc/draft/draft-lewis-dnsext-key-genprot-00.txt b/doc/draft/draft-lewis-dnsext-key-genprot-00.txt new file mode 100644 index 0000000000..a991dafad5 --- /dev/null +++ b/doc/draft/draft-lewis-dnsext-key-genprot-00.txt @@ -0,0 +1,141 @@ +Internet Engineering Task Force Ed Lewis +Internet-Draft NAI Labs +July 9, 2001 Expires: January 9, 2002 + + DNS KEY Resource Record Generic Protocol Value + + +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 draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +This draft expires on January 9, 2002. + +Copyright Notice + +Copyright (C) The Internet Society (2001). All rights reserved. + +Abstract + +A new protocol value is defined for the KEY Resource Record which +identifies the intended protocol as that identified in the SRV-like +encoding of the KEY RR's owner name. + +1.0 Introduction + +Starting with discussions concerning the mixing of zone keys and +application keys at a zone apex, with the implication that the signing +of the apex set makes the parent responsible for signing data +inherently specific to the child zone, various proposals have been +made to eliminate that issue. One such proposal is to separate keys +by using the owner name, a la the SRV record. E.g., for a host named +"host.myzone.test." a key used for SSH might be found at +"_ssh._tcp.host.myzone.test." [RFC 2782] + +Other motivations for this proposal and approach to naming key is to +address issues including: concerns over size of the apex key set and +the extensive use of sub-typing KEY records. Since it is desirable +to send the apex key set as additional data, it would be good to +limit its size (by not having to include non-zone keys). Subtyping +refers to making a resolver filter a returned RR set to extract +the subset of records that meets the query's intent. + +This draft is not intended to document the SRV naming proposal, nor +are any of the examples represented here suggestions for naming +conventions. The intent of the draft is to define a catch-all protocol +value which informs a resolver that the intended protocol for this key +is encoded in the ownership name. + +If this (or a) generic protocol proposal is not adopted, yet a naming +convention is used, the impact is that for each new protocol a new +IANA-defined value is needed for the protocol octet in addition to a +new specific naming convention. This proposal is just a means to ease +the burden on IANA. + +2.0 KEY RR Protocol Value + +The unsigned integer value of is reserved to mean that the +owner name indicates the intended protocol of the KEY RR. + +3.0 Acknowledgements + +This proposal has been made in conversation with Jakob Schylter and +Ilja Hallberg at a DNS meeting in Malmo Sweden. + +4.0 IANA Considerations + +A protocol number assignment for the DNS Key Resource Record is +requested. The specific value is not considered important. + +A suggestion to IANA is made regarding the KEY RR protocol values. +One suggested assignment algorithm (perhaps this needs a different +draft) is to assign the protocol number according to the reserved port +number. This may help in uniqueness. + +5.0 Security Considerations + +This draft introduces no new security issues. + +6.0 References + +The text of any RFC may be retrieved by a web browser by requesting +the URL: ftp://ftp.isi.edu/in-notes/rfc.txt, where "wxyz" is the +number of the RFC. + +[RFC 2026] "The Internet Standards Process -- Revision 3", Bradner +[RFC 2535] "Domain Name System Security Extensions", Eastlake +[RFC 2782] "A DNS RR for specifying the location of services (DNS SRV)", + Gulbrandsen, Vixie, Esibov + +7.0 Editor's Address + +Edward Lewis + +3060 Washington Rd (Rte 97) +Glenwood, MD 21738 ++1(443)259-2352 + +8.0 Full Copyright Statement + +Copyright (C) The Internet Society 2001. All Rights Reserved. + +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it +or assist in its implementation may be prepared, copied, published and +distributed, in whole or in part, without restriction of any kind, +provided that the above copyright notice and this paragraph are +included on all such copies and derivative works. However, this +document itself may not be modified in any way, such as by removing +the copyright notice or references to the Internet Society or other +Internet organizations, except as needed for the purpose of developing +Internet standards in which case the procedures for copyrights defined +in the Internet Standards process must be followed, or as required to +translate it into languages other than English. + +The limited permissions granted above are perpetual and will not be +revoked by the Internet Society or its successors or assigns. + +This document and the information contained herein is provided on an +"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT +NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN +WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +