Network Working Group H. Eidnes
Request for Comments: 2317 SINTEF RUNIT
BCP: 20 G. de Groot
Category: Best Current Practice Berkeley Software Design, Inc.
P. Vixie
Internet Software Consortium
March 1998
Network Working Group H. Eidnes
Request for Comments: 2317 SINTEF RUNIT
BCP: 20 G. de Groot
Category: Best Current Practice Berkeley Software Design, Inc.
P. Vixie
Internet Software Consortium
March 1998
Classless IN-ADDR.ARPA delegation
无类IN-ADDR.ARPA委托
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. The proposed method should thus remove one of the objections to subnet on non-octet boundaries but perhaps more significantly, make it possible to assign IP address space in smaller chunks than 24-bit prefixes, without losing the ability to delegate authority for the corresponding IN-ADDR.ARPA mappings. The proposed method is fully compatible with the original DNS lookup mechanisms specified in [1], i.e. there is no need to modify the lookup algorithm used, and there should be no need to modify any software which does DNS lookups.
本文档描述了一种在非八位字节边界上对覆盖少于256个地址的地址空间执行IN-ADDR.ARPA委托的方法。因此，建议的方法应消除对非八位组边界上的子网的异议之一，但可能更重要的是，它可以将IP地址空间分配为比24位前缀更小的块，而不会失去为相应的in-ADDR.ARPA映射委派权限的能力。建议的方法与[1]中规定的原始DNS查找机制完全兼容，即不需要修改所使用的查找算法，也不需要修改进行DNS查找的任何软件。
The document also discusses some operational considerations to provide some guidance in implementing this method.
本文件还讨论了一些操作注意事项，为实施该方法提供了一些指导。
With the proliferation of classless routing technology, it has become feasible to assign address space on non-octet boundaries. In case of a very small organization with only a few hosts, assigning a full 24-bit prefix (what was traditionally referred to as a "class C network number") often leads to inefficient address space utilization.
随着无类路由技术的发展，在非八位组边界上分配地址空间已成为可能。对于只有少数主机的非常小的组织，分配完整的24位前缀（传统上称为“C类网络号”）通常会导致地址空间利用率低下。
One of the problems encountered when assigning a longer prefix (less address space) is that it seems impossible for such an organization to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously. By use of the reverse delegation method described below, the most important objection to assignment of longer prefixes to unrelated organizations can be removed.
分配更长的前缀（更少的地址空间）时遇到的问题之一是，这样的组织似乎不可能自动维护自己的反向（“IN-ADDR.ARPA”）区域。通过使用下面描述的反向委托方法，可以消除将较长前缀分配给不相关组织的最重要的反对意见。
Let us assume we have assigned the address spaces to three different parties as follows:
假设我们已将地址空间分配给三个不同的方，如下所示：
192.0.2.0/25 to organization A 192.0.2.128/26 to organization B 192.0.2.192/26 to organization C
192.0.2.0/25到组织A 192.0.2.128/26到组织B 192.0.2.192/26到组织C
In the classical approach, this would lead to a single zone like this:
在经典方法中，这将导致一个单一区域，如下所示：
$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
The administration of this zone is problematic. Authority for this zone can only be delegated once, and this usually translates into "this zone can only be administered by one organization." The other organizations with address space that corresponds to entries in this zone would thus have to depend on another organization for their address to name translation. With the proposed method, this potential problem can be avoided.
该区域的管理存在问题。此区域的权限只能授予一次，这通常会转化为“此区域只能由一个组织管理”。因此，具有与此区域中的条目相对应的地址空间的其他组织将不得不依赖另一个组织进行地址到名称的转换。使用所提出的方法，可以避免这个潜在的问题。
Since a single zone can only be delegated once, we need more points to do delegation on to solve the problem above. These extra points of delegation can be introduced by extending the IN-ADDR.ARPA tree downwards, e.g. by using the first address or the first address and the network mask length (as shown below) in the corresponding address
由于单个区域只能委派一次，因此我们需要更多的点进行委派以解决上述问题。这些额外的委托点可以通过向下扩展IN-ADDR.ARPA树来引入，例如，在相应的地址中使用第一个地址或第一个地址以及网络掩码长度（如下所示）
space to form the the first component in the name for the zones. The following four zone files show how the problem in the motivation section could be solved using this method.
形成分区名称中第一个组件的空间。以下四个区域文件显示了如何使用此方法解决激励部分中的问题。
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
;...
; <<0-127>> /25
0/25 NS ns.A.domain.
0/25 NS some.other.name.server.
;
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
2 CNAME 2.0/25.2.0.192.in-addr.arpa.
3 CNAME 3.0/25.2.0.192.in-addr.arpa.
;
; <<128-191>> /26
128/26 NS ns.B.domain.
128/26 NS some.other.name.server.too.
;
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
130 CNAME 130.128/26.2.0.192.in-addr.arpa.
131 CNAME 131.128/26.2.0.192.in-addr.arpa.
;
; <<192-255>> /26
192/26 NS ns.C.domain.
192/26 NS some.other.third.name.server.
;
193 CNAME 193.192/26.2.0.192.in-addr.arpa.
194 CNAME 194.192/26.2.0.192.in-addr.arpa.
195 CNAME 195.192/26.2.0.192.in-addr.arpa.
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
;...
; <<0-127>> /25
0/25 NS ns.A.domain.
0/25 NS some.other.name.server.
;
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
2 CNAME 2.0/25.2.0.192.in-addr.arpa.
3 CNAME 3.0/25.2.0.192.in-addr.arpa.
;
; <<128-191>> /26
128/26 NS ns.B.domain.
128/26 NS some.other.name.server.too.
;
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
130 CNAME 130.128/26.2.0.192.in-addr.arpa.
131 CNAME 131.128/26.2.0.192.in-addr.arpa.
;
; <<192-255>> /26
192/26 NS ns.C.domain.
192/26 NS some.other.third.name.server.
;
193 CNAME 193.192/26.2.0.192.in-addr.arpa.
194 CNAME 194.192/26.2.0.192.in-addr.arpa.
195 CNAME 195.192/26.2.0.192.in-addr.arpa.
$ORIGIN 0/25.2.0.192.in-addr.arpa. @ IN SOA ns.A.domain. hostmaster.A.domain. (...) @ NS ns.A.domain. @ NS some.other.name.server. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain.
$ORIGIN 0/25.2.0.192.in-addr.arpa.@在SOA ns.A.域中。hostmaster.A.domain。（…）@NS NS.A.domain.@NS some.other.name.server；1个PTR主机1.A.domain。2 PTR主机2.A.domain。3 PTR主机3.A.域。
$ORIGIN 128/26.2.0.192.in-addr.arpa. @ IN SOA ns.B.domain. hostmaster.B.domain. (...) @ NS ns.B.domain. @ NS some.other.name.server.too. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain.
$ORIGIN 128/26.2.0.192.in-addr.arpa.@在SOA ns.B.domain中。hostmaster.B.domain。（…）@NS NS.B.domain.@NS some.other.name.server.too；129 PTR主机1.B.域。130 PTR主机2.B.域。131 PTR主机3.B.域。
$ORIGIN 192/26.2.0.192.in-addr.arpa. @ IN SOA ns.C.domain. hostmaster.C.domain. (...) @ NS ns.C.domain. @ NS some.other.third.name.server. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain.
$ORIGIN 192/26.2.0.192.in-addr.arpa.@在soans.C.domain中。hostmaster.C.domain。（…）@NS NS.C.domain.@NS some.other.third.name.server；193 PTR主机1.C.域。194 PTR主机2.C.域。195 PTR主机3.C.域。
For each size-256 chunk split up using this method, there is a need to install close to 256 CNAME records in the parent zone. Some people might view this as ugly; we will not argue that particular point. It is however quite easy to automatically generate the CNAME resource records in the parent zone once and for all, if the way the address space is partitioned is known.
对于使用此方法拆分的每个大小为256的区块，需要在父区域中安装近256条CNAME记录。有些人可能会认为这很丑陋；我们不会争论这一点。但是，如果地址空间的分区方式已知，则可以很容易地一次性在父区域中自动生成CNAME资源记录。
The advantage of this approach over the other proposed approaches for dealing with this problem is that there should be no need to modify any already-deployed software. In particular, the lookup mechanism in the DNS does not have to be modified to accommodate this splitting of the responsibility for the IPv4 address to name translation on "non-dot" boundaries. Furthermore, this technique has been in use for several years in many installations, apparently with no ill effects.
与处理此问题的其他建议方法相比，此方法的优点是不需要修改任何已部署的软件。特别是，DNS中的查找机制不必修改，以适应“非点”边界上IPv4地址到名称转换的责任划分。此外，这项技术已在许多装置中使用多年，显然没有不良影响。
As usual, a resource record like
像往常一样，像这样的资源记录
$ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26.2.0.192.in-addr.arpa.
$ORIGIN 2.0.192.in-addr.arpa。129 CNAME 129.128/26.2.0.192.in-addr.arpa。
can be convienently abbreviated to
可以方便地缩写为
$ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26
$ORIGIN 2.0.192.in-addr.arpa。129 CNAME 129.128/26
Some DNS implementations are not kind to special characters in domain names, e.g. the "/" used in the above examples. As [3] makes clear, these are legal, though some might feel unsightly. Because these are not host names the restriction of [2] does not apply. Modern clients and servers have an option to act in the liberal and correct fashion.
一些DNS实现对域名中的特殊字符不友好，例如上面示例中使用的“/”。正如[3]明确指出的，这些都是合法的，尽管有些人可能会觉得难看。由于这些不是主机名，[2]的限制不适用。现代客户机和服务器可以选择自由和正确的方式。
The examples here use "/" because it was felt to be more visible and pedantic reviewers felt that the 'these are not hostnames' argument needed to be repeated. We advise you not to be so pedantic, and to not precisely copy the above examples, e.g. substitute a more conservative character, such as hyphen, for "/".
这里的例子使用“/”是因为人们觉得它更明显，而迂腐的评论者认为“这些不是主机名”的论点需要重复。我们建议您不要如此迂腐，也不要完全照搬上述示例，例如，用更保守的字符（如连字符）替换“/”。
This technique is intended to be used for delegating address spaces covering fewer than 256 addresses. For delegations covering larger blocks of addresses the traditional methods (multiple delegations) can be used instead.
此技术旨在用于委派覆盖少于256个地址的地址空间。对于覆盖较大地址块的委托，可以使用传统方法（多个委托）。
Some older versions of name server software will make no effort to find and return the pointed-to name in CNAME records if the pointed-to name is not already known locally as cached or as authoritative data. This can cause some confusion in resolvers, as only the CNAME record will be returned in the response. To avoid this problem it is recommended that the authoritative name servers for the delegating zone (the zone containing all the CNAME records) all run as slave (secondary) name servers for the "child" zones delegated and pointed into via the CNAME records.
如果指向的名称在本地尚未被称为缓存或权威数据，则某些旧版本的名称服务器软件将不努力在CNAME记录中查找并返回指向的名称。这可能会在解析程序中造成一些混乱，因为响应中将只返回CNAME记录。为避免此问题，建议委派区域（包含所有CNAME记录的区域）的权威名称服务器都作为通过CNAME记录委派和指向的“子”区域的从属（辅助）名称服务器运行。
As a result of this method, the location of the zone containing the actual PTR records is no longer predefined. This gives flexibility and some examples will be presented here.
这种方法的结果是，不再预定义包含实际PTR记录的区域的位置。这提供了灵活性，这里将给出一些示例。
An alternative to using the first address, or the first address and the network mask length in the corresponding address space, to name the new zones is to use some other (non-numeric) name. Thus it is also possible to point to an entirely different part of the DNS tree (i.e. outside of the IN-ADDR.ARPA tree). It would be necessary to use one of these alternate methods if two organizations somehow shared the same physical subnet (and corresponding IP address space) with no "neat" alignment of the addresses, but still wanted to administrate their own IN-ADDR.ARPA mappings.
使用第一个地址或相应地址空间中的第一个地址和网络掩码长度来命名新区域的另一种方法是使用其他（非数字）名称。因此，也可以指向DNS树的完全不同部分（即IN-ADDR.ARPA树的外部）。如果两个组织以某种方式共享相同的物理子网（和相应的IP地址空间），而没有地址的“整齐”对齐，但仍希望管理自己的IN-ADDR.ARPA映射，则有必要使用这些替代方法之一。
The following short example shows how you can point out of the IN-ADDR.ARPA tree:
以下简短示例显示了如何指出IN-ADDR.ARPA树：
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
; ...
1 CNAME 1.A.domain.
2 CNAME 2.A.domain.
; ...
129 CNAME 129.B.domain.
130 CNAME 130.B.domain.
;
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
; ...
1 CNAME 1.A.domain.
2 CNAME 2.A.domain.
; ...
129 CNAME 129.B.domain.
130 CNAME 130.B.domain.
;
$ORIGIN A.domain.
@ IN SOA my-ns.A.domain. hostmaster.A.domain. (...)
; ...
;
host1 A 192.0.2.1
1 PTR host1
;
host2 A 192.0.2.2
2 PTR host2
;
$ORIGIN A.domain.
@ IN SOA my-ns.A.domain. hostmaster.A.domain. (...)
; ...
;
host1 A 192.0.2.1
1 PTR host1
;
host2 A 192.0.2.2
2 PTR host2
;
etc.
等
This way you can actually end up with the name->address and the (pointed-to) address->name mapping data in the same zone file - some may view this as an added bonus as no separate set of secondaries for the reverse zone is required. Do however note that the traversal via the IN-ADDR.ARPA tree will still be done, so the CNAME records inserted there need to point in the right direction for this to work.
通过这种方式，您实际上可以在同一区域文件中使用名称->地址和（指向的）地址->名称映射数据-有些人可能会认为这是一种额外的好处，因为反向区域不需要单独的辅助集。但是请注意，通过IN-ADDR.ARPA树进行的遍历仍将完成，因此插入其中的CNAME记录需要指向正确的方向，才能正常工作。
Sketched below is an alternative approach using the same solution:
以下是使用相同解决方案的替代方法：
$ORIGIN 2.0.192.in-addr.arpa. @ SOA my-ns.my.domain. hostmaster.my.domain. (...) ; ... 1 CNAME 1.2.0.192.in-addr.A.domain. 2 CNAME 2.2.0.192.in-addr.A.domain.
$ORIGIN 2.0.192.in-addr.arpa.@SOA my-ns.my.domain。hostmaster.my.domain。(...) ; ... 1 CNAME 1.2.0.192.in-addr.A.domain。2 CNAME 2.2.0.192.in-addr.A.domain。
$ORIGIN A.domain. @ SOA my-ns.A.domain. hostmaster.A.domain. (...) ; ... ; host1 A 192.0.2.1 1.2.0.192.in-addr PTR host1
$ORIGIN A.domain.@SOA my-ns.A.domain。hostmaster.A.domain。(...) ; ... ; 主机1 A 192.0.2.1 1.2.0.192.in-addr PTR主机1
host2 A 192.0.2.2 2.2.0.192.in-addr PTR host2
主机2 A 192.0.2.2 2.2.0.192.in-addr PTR主机2
It is clear that many possibilities exist which can be adapted to the specific requirements of the situation at hand.
显然，存在着许多可以根据当前局势的具体要求加以调整的可能性。
Note that one cannot provide CNAME referrals twice for the same address space, i.e. you cannot allocate a /25 prefix to one organisation, and run IN-ADDR.ARPA this way, and then have the organisation subnet the /25 into longer prefixes, and attempt to employ the same technique to give each subnet control of its own number space. This would result in a CNAME record pointing to a CNAME record, which may be less robust overall.
请注意，不能为同一地址空间提供两次CNAME引用，也就是说，不能将/25前缀分配给一个组织，并以这种方式运行IN-ADDR.ARPA，然后将该组织的子网/25划分为更长的前缀，并尝试采用相同的技术使每个子网控制自己的数字空间。这将导致CNAME记录指向CNAME记录，这可能总体上不太可靠。
Unfortunately, some old beta releases of the popular DNS name server implementation BIND 4.9.3 had a bug which caused problems if a CNAME record was encountered when a reverse lookup was made. The beta releases involved have since been obsoleted, and this issue is resolved in the released code. Some software manufacturers have included the defective beta code in their product. In the few cases we know of, patches from the manufacturers are available or planned to replace the obsolete beta code involved.
不幸的是，流行的DNS名称服务器实现BIND 4.9.3的一些旧的beta版有一个bug，如果在进行反向查找时遇到CNAME记录，就会导致问题。相关的beta版本已经过时，这个问题在发布的代码中得到了解决。一些软件制造商已经在他们的产品中加入了有缺陷的beta代码。在我们所知的少数情况下，制造商提供的补丁可用于或计划用于替换相关的过时beta代码。
With this scheme, the "leaf sites" will need to rely on one more site running their DNS name service correctly than they would be if they had a /24 allocation of their own, and this may add an extra component which will need to work for reliable name resolution.
使用此方案，“叶站点”将需要多依赖一个站点来正确运行其DNS名称服务，而不是如果它们有自己的a/24分配，这可能会添加一个额外的组件，该组件将需要用于可靠的名称解析。
Other than that, the authors are not aware of any additional security issues introduced by this mechanism.
除此之外，作者不知道该机制引入的任何其他安全问题。
The suggested scheme gives more flexibility in delegating authority in the IN-ADDR.ARPA domain, thus making it possible to assign address space more efficiently without losing the ability to delegate the DNS authority over the corresponding address to name mappings.
建议的方案在in-ADDR.ARPA域中授予权限方面提供了更大的灵活性，从而可以更有效地分配地址空间，而不会失去在相应的地址到名称映射上授予DNS权限的能力。
Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-ip.domains some time ago. Alan Barrett and Sam Wilson provided valuable comments on the newsgroup.
Glen A.Herrmannsfeldt不久前在comp.protocols.tcp-ip.domains上描述了这个技巧。艾伦·巴雷特和山姆·威尔逊对新闻组发表了宝贵的评论。
We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer, and Peter Koch for their review and constructive comments.
我们要感谢罗布·奥斯汀、兰迪·布什、马特·克劳福德、罗伯特·埃尔兹、格伦·A·赫尔曼斯菲尔德、丹尼尔·卡伦伯格、大卫·凯森斯、托尼·李、保罗·莫卡佩特里斯、埃里克·瓦森纳、迈克尔·巴顿、汉斯·莫雷尔和彼得·科赫的评论和建设性意见。
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host Table Specification", RFC 952, October 1985.
[2] Harrenstien，K.，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC 952，1985年10月。
[3] Elz, R., and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[3] Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
Havard Eidnes SINTEF RUNIT N-7034 Trondheim Norway
挪威特隆赫姆哈瓦德·艾德内斯辛特夫·鲁尼特N-7034
Phone: +47 73 59 44 68
Fax: +47 73 59 17 00
EMail: Havard.Eidnes@runit.sintef.no
Phone: +47 73 59 44 68
Fax: +47 73 59 17 00
EMail: Havard.Eidnes@runit.sintef.no
Geert Jan de Groot Berkeley Software Design, Inc. (BSDI) Hendrik Staetslaan 69 5622 HM Eindhoven The Netherlands
Geert Jan de Groot Berkeley软件设计有限公司（BSDI）Hendrik Staetslaan 69 5622 HM荷兰埃因霍温
Phone: +31 40 2960509
Fax: +31 40 2960309
EMail: GeertJan.deGroot@bsdi.com
Phone: +31 40 2960509
Fax: +31 40 2960309
EMail: GeertJan.deGroot@bsdi.com
Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 USA
Paul Vixie互联网软件联盟星路箱159A美国加利福尼亚州伍德赛德94062
Phone: +1 415 747 0204
EMail: paul@vix.com
Phone: +1 415 747 0204
EMail: paul@vix.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。