Network Working Group A. Durand
Request for Comments: 2546 IMAG
Category: Informational B. Buclin
AT&T Labs Europe
March 1999
Network Working Group A. Durand
Request for Comments: 2546 IMAG
Category: Informational B. Buclin
AT&T Labs Europe
March 1999
6Bone Routing Practice
6Bone路由实践
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
The 6Bone is an environment supporting experimentation with the IPv6 protocols and products implementing it. As the network grows, the need for common operation rules emerged. In particular, operation of the 6Bone backbone is a challenge due to the frequent insertion of bogus routes by leaf or even backbone sites.
6Bone是一个支持IPv6协议和实现它的产品实验的环境。随着网络的发展，出现了对通用操作规则的需求。特别是，6Bone主干网的运行是一个挑战，因为leaf甚至主干网站点经常插入假路由。
This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols (such as RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC 2283]).
本备忘录确定了6Bone站点如何运行的指导原则，以便6Bone能够保持高质量的实验环境，避免过去遇到的病理情况。它为内部网关协议（如RIPng[RFC 2080]）和外部网关协议（如BGP4+[RFC 2283]）的配置定义了6Bone中可接受的“最佳当前实践”。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
The 6Bone is structured as a hierarchical network with pseudo Top Level Aggregator (pTLA) sites, pseudo Next Level Aggregator (pNLA) sites and leaf sites. This topology supports the IPv6 address aggregation architecture as described in [1]. The 6Bone backbone is made of a mesh interconnecting pTLAs only. pNLAs connect to one or more pTLAs and provide transit service for leaf sites.
6Bone的结构是一个具有伪顶级聚合器（pTLA）站点、伪下一级聚合器（pNLA）站点和叶站点的分层网络。此拓扑支持[1]中所述的IPv6地址聚合体系结构。6Bone主干网仅由连接PTLA的网状网构成。pNLAs连接到一个或多个PTLA，并为叶站点提供中转服务。
pTLA sites MUST use BGP4+ [RFC 2283] as the mandatory routing protocol for exchanging routing information among them.
pTLA站点必须使用BGP4+[RFC 2283]作为它们之间交换路由信息的强制路由协议。
Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY use a simple default route to their ISP.
多宿主站点或PNLA也应使用BGP4+。常规站点可以使用简单的默认路由到其ISP。
This section details common rules governing the routing on the 6Bone. They are derived from issues encountered on the 6Bone, with respect to the routes advertised, handling of special addresses, and aggregation:
本节详细介绍控制6Bone路由的常见规则。它们来源于6Bone上遇到的问题，涉及到广告的路由、特殊地址的处理和聚合：
1) link local prefixes
1) 链接本地前缀
2) site local prefixes
2) 站点本地前缀
3) loopback prefix & unspecified prefix
3) 环回前缀&未指定的前缀
4) multicast prefixes
4) 多播前缀
5) IPv4-compatible prefixes
5) IPv4兼容前缀
6) IPv4-mapped prefixes
6) IPv4映射前缀
7) default routes
7) 默认路由
8) Yet undefined unicast prefixes (from a different /3 prefix)
8) 但未定义的单播前缀（来自不同的/3前缀）
9) Inter site links issues
9) 站点间链接问题
10) aggregation & advertisement issues
10） 聚合和广告问题
The link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP.
链路本地前缀（FE80:：/10）不得通过IGP或EGP播发。
By definition, the link-local prefix has a scope limited to a specific link. Since the prefix is the same on all IPv6 links, advertising it in any routing protocol does not make sense and, worse, may introduce nasty error conditions.
根据定义，链接本地前缀的作用域仅限于特定链接。由于前缀在所有IPv6链路上都是相同的，因此在任何路由协议中公布它都没有意义，更糟糕的是，可能会导致严重的错误情况。
Well known cases where link local prefixes could be advertised by mistake include:
众所周知，链接本地前缀可能被错误广告的情况包括：
- a router advertising all directly connected network prefixes including the link-local one.
- 一种路由器，公布所有直接连接的网络前缀，包括链路本地前缀。
- Subnetting of the link-local prefix.
- 链接本地前缀的子网。
In such cases, vendors should be urged to correct their code.
在这种情况下，应敦促供应商更正其代码。
Site local prefixes (in the FEC0::/10 range) MAY be advertized by IGPs or EGPs within a site. The precise definition of a site is ongoing work discussed in the IPng working group.
站点本地前缀（在FEC0:：/10范围内）可由站点内的IGPs或EGPs发布广告。IPng工作组正在讨论场地的精确定义。
Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs.
不得向transit PNLA或PTLA发布站点本地前缀。
The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT be advertised by any routing protocol.
任何路由协议都不能公布环回前缀（：：1/128）和未指定的前缀（：：0/128）。
Multicast prefixes MUST NOT be advertised by any unicast routing protocol. Multicast routing protocols are designed to respect the semantics of multicast and MUST therefore be used to route packets with multicast destination addresses (in the range FF00::/8).
任何单播路由协议都不能播发多播前缀。多播路由协议旨在尊重多播的语义，因此必须用于路由具有多播目标地址的数据包（范围为FF00:：/8）。
Multicast address scopes MUST be respected on the 6Bone. Only global scope multicast addresses MAY be routed across transit pNLAs and pTLAs. There is no requirement on a pTLA to route multicast packets.
在6Bone上必须遵守多播地址作用域。只有全局范围多播地址可以跨传输PNLA和PTLA路由。pTLA不需要路由多播数据包。
Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) MAY be routed across a pNLA to its leaf sites.
组织本地多播（在FF08:：/16或FF18:：/16范围内）可以跨pNLA路由到其叶站点。
Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs.
站点本地多播不得路由至中转PNLA或PTLA。
Obviously, link-local multicasts and node-local multicasts MUST NOT be routed at all.
显然，链路本地多播和节点本地多播根本不能路由。
Sites may choose to use IPv4 compatible addresses (::a.b.c.d) internally. As there is no real rationale today for doing that, these addresses SHOULD
站点可以选择在内部使用IPv4兼容地址（：：a.b.c.d）。由于目前没有这样做的真正理由，这些地址应该
NOT be used in the 6Bone.
不要用在6Bone中。
The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
IGPs可以公布：：/96 IPv4兼容前缀。
IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or pTLAs.
EGPs不得向transit pNLAs或PTLA发布与IPv4兼容的前缀。
IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is an IPv4 address) MAY be advertised by IGPs within a site. It may be useful for some IPv6 only nodes within a site to have such a route pointing to a translation device.
IPv4映射的前缀（：：FFFF:a.b.c.d，其中a.b.c.d是IPv4地址）可以由站点内的IGPs播发。对于站点中的某些仅限IPv6的节点来说，将此类路由指向翻译设备可能很有用。
IPv4-mapped prefixes MUST NOT be advertised by EGPs.
EGPs不得播发IPv4映射前缀。
6Bone core pTLA routers MUST be default-free.
6核心pTLA路由器必须是默认免费的。
pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY do the same for their leaf sites.
PTLA可以向其PNLA公布默认路由。Transit PNLA也可以对其叶位进行同样的处理。
Yet undefined unicast prefixes from a format prefix other than 2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone. In particular, RFC 2471 test addresses MUST NOT be advertised on the 6Bone.
但是，格式前缀（2000:：/3除外）中未定义的单播前缀不得由6Bone中的任何路由协议播发。特别是，RFC 2471测试地址不得在6Bone上公布。
Routing of global unicast prefixes outside of the 6Bone range (3FFE::/16) is discussed in section 4, Routing policies, below.
下面第4节“路由策略”讨论了6Bone范围（3FFE:：/16）之外的全局单播前缀的路由。
Global IPv6 addresses MUST be used for the end points of the inter-site links. In particular, IPv4 compatible addresses MUST NOT be used for tunnels.
站点间链路的端点必须使用全局IPv6地址。特别是，与IPv4兼容的地址不得用于隧道。
Prefixes for those links MUST NOT be injected in the global routing tables.
不得在全局路由表中插入这些链接的前缀。
Route aggregation MUST be performed by any border router.
路由聚合必须由任何边界路由器执行。
Sites or pNLAs MUST only advertise to their upstream provider the prefixes assigned by that ISP unless otherwise agreed.
除非另有约定，否则站点或PNLA只能向其上游提供商公布该ISP分配的前缀。
Site border router MUST NOT advertise prefixes more specific than the /48 ones allocated by their ISP.
站点边界路由器不得公布比ISP分配的/48前缀更具体的前缀。
pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless special peering agreements are implemented. When such special peering agreements are in place between any two or more pTLAs, care MUST be taken not to leak the more specific prefixes to other pTLAs not participating in the peering agreement.
除非实施了特殊对等协议，否则pTLA不得向其他pTLA公布长度超过24的前缀。当任何两个或多个PTLA之间存在此类特殊对等协议时，必须注意不要将更具体的前缀泄漏给未参与对等协议的其他PTLA。
6Bone backbone sites maintain the mesh into the backbone and provide an as reliable as possible service, granted the 6Bone is an experimentation tool. To achieve their mission, 6Bone backbone sites MUST maintain peerings with at least 3 (three) other back bone sites.
6Bone主干站点将网格维护到主干中，并提供尽可能可靠的服务，前提是6Bone是一种实验工具。为了完成其任务，6Bone主干站点必须与至少3（三）个其他骨干站点保持对等。
The peering agreements across the 6Bone are by nature non-commercial, and therefore SHOULD allow transit traffic through.
跨6Bone的对等协议本质上是非商业性的，因此应该允许过境流量通过。
Eventually, the Internet registries will assign other TLAs than the 6Bone one (currently 3FFE::/16). The organizations bearing those TLAs will establish a new IPv6 network, parallel to the 6Bone. The 6Bone MIGHT interconnect with this new IPv6 Internet, b ut transit across the 6Bone will not be guaranteed. It will be left to each 6Bone backbone site to decide whether it will carry traffic to or from the IPv6 Internet.
最终，互联网注册中心将分配除6Bone之外的其他TLA（目前为3FFE:：/16）。拥有这些TLA的组织将建立一个新的IPv6网络，与6Bone并行。6Bone可能会与这个新的IPv6互联网互连，但不能保证通过6Bone进行传输。它将留给每个6Bone主干站点来决定是否将流量传输到IPv6互联网或从IPv6互联网传输流量。
The 6Bone registry is a RIPE-181 database with IPv6 extensions used to store information about the 6Bone. Each 6Bone site MUST maintain the relevant entries in the 6Bone registry (whois.6bone.net). In particular, the following objects MUST be present:
6Bone注册表是一个成熟的RIME-181数据库，具有IPv6扩展，用于存储有关6Bone的信息。每个6Bone站点必须在6Bone注册表（whois.6Bone.net）中维护相关条目。特别是，必须存在以下对象：
- IPv6-site: site description
- IPv6站点：站点描述
- Inet6num: prefix delegation
- Inet6num：前缀委派
- Mntner: coordinate of site maintenance staff
- Mntner：现场维护人员的协调人
Other objects MAY be maintained at the discretion of the sites, such as routing policy descriptors, person or role objects. The Mntner object MUST make reference to a role or person object, but those must not necessarily reside in the 6Bone registry, they can be stored within any of the Internet registry databases (RIPE, InterNIC, APNIC,
其他对象可由站点自行维护，如路由策略描述符、人员或角色对象。Mntner对象必须引用角色或个人对象，但这些对象不一定位于6Bone注册表中，它们可以存储在任何Internet注册表数据库（RIME、InterNIC、APNIC、，
New sites joining the 6Bone should seek to connect to a transit pNLA or a pTLA within their region, and preferably as close as possible to their existing IPv4 physical and routing path for Internet service. The 6Bone registry is available to find out candidate ISPs.
加入6Bone的新站点应寻求连接到其所在区域内的公交pNLA或pTLA，最好尽可能靠近其现有IPv4物理路径和互联网服务路由路径。6Bone注册表可用于查找候选ISP。
Any site connected to the 6Bone MUST maintain a DNS server for forward name looking and reverse address translation. The joining site MUST maintain the 6Bone registry objects relative to its site, and in particular the IPv6- site and the MNTNER objects.
连接到6Bone的任何站点都必须维护一个DNS服务器，以便进行正向名称查找和反向地址转换。加入站点必须维护相对于其站点的6Bone注册表对象，尤其是IPv6站点和MNTNER对象。
The upstream ISP MUST delegate the reverse address translation zone in DNS to the joining site. The ISP MUST also create 6Bone registry objects reflecting the delegated address space (inet6num:).
上游ISP必须将DNS中的反向地址转换区域委托给加入站点。ISP还必须创建反映委派地址空间的6Bone注册表对象（inet6num:）。
Up to date information about how to join the 6Bone is available on the 6Bone Web site at http://www.6bone.net.
有关如何加入6Bone的最新信息，请访问6Bone网站：http://www.6bone.net.
6Bone pTLA sites are altogether forming the backbone of the 6Bone. In order to ensure the highest level possible of availability and stability for the 6Bone environment, a few constraints are placed onto sites wishing to become or stay a 6Bone pTLA:
6Bone pTLA站点共同构成6Bone的主干。为了确保6Bone环境具有尽可能高的可用性和稳定性，对希望成为或保持6Bone pTLA的站点设置了一些限制：
1. The site MUST have experience with IPv6 on the 6Bone, at least as a leaf site and preferably as a transit pNLA under an existing pTLA.
1. 该站点必须具有在6Bone上使用IPv6的经验，至少作为叶站点，最好是作为现有pTLA下的传输pNLA。
2. The site MUST have the ability and intent to provide "production-like" 6Bone backbone service to provide a robust and operationally reliable 6Bone backbone.
2. 站点必须具备提供“生产型”6Bone主干网服务的能力和意图，以提供强健且操作可靠的6Bone主干网。
3. The site MUST have a potential "user community" that would be served by becoming a pTLA, e.g., the requester is a major player in a region, country or focus of interest.
3. 网站必须有一个潜在的“用户社区”，通过成为pTLA来服务，例如，请求者是某个地区、国家或利益中心的主要参与者。
4. Must commit to abide by the 6Bone backbone operational rules and policies as defined in the present document.
4. 必须承诺遵守本文件中定义的6Bone主干网运营规则和政策。
When a candidate site seeks to become a pTLA site, it will apply for it to the 6Bone Operations group (see below) by bringing evidences it meets the above criteria.
当候选站点寻求成为pTLA站点时，将通过提供符合上述标准的证据向6Bone Operations group（见下文）申请。
The 6Bone Operations group is the body in charge of monitoring the adherence to the present rules, and will take the appropriate actions to correct deviations. Membership in the 6Bone Operations group is mandatory for, and restricted to, any site connected to the 6Bone.
6Bone运营小组是负责监督本规则遵守情况的机构，将采取适当措施纠正偏差。6Bone操作组的成员资格对于连接到6Bone的任何站点都是强制性的，并且仅限于此。
The 6Bone Operations group is currently defined by those members of the existing 6Bone mailing list, i.e., 6bone@isi.edu, who represent sites participating on the 6Bone. Therefore it is incumbent on relevant site contacts to join the mailing list. Instructions on how to join the list are maintained on the 6Bone web site at http://www.6bone.net.
6Bone操作组目前由现有6Bone邮件列表的成员定义，即：。，6bone@isi.edu，他们代表参与6Bone的网站。因此，相关站点联系人有义务加入邮件列表。有关如何加入该列表的说明，请访问6Bone网站http://www.6bone.net.
Participation in the 6Bone is a voluntary and benevolent undertaking. However, participating sites are expected to adhere to the rules described in this document, in order to maintain the 6Bone as quality tool for experimenting with the IPv6 protocols and products implementing them.
参加6Bone是一项自愿和慈善的事业。但是，参与的站点应遵守本文档中描述的规则，以保持6Bone作为试验IPv6协议和实现这些协议的产品的质量工具。
The following processes are proposed to help enforcing the 6Bone rules:
建议采用以下流程来帮助实施6Bone规则：
- Each pTLA site has committed when requesting their pTLA to implement the rules, and to ensure they are respected by sites within their administrative control (i.e. those to who prefixes have been delegated).
- 每个pTLA站点在请求其pTLA实施规则时已作出承诺，并确保其管理控制范围内的站点（即前缀已被委派的站点）遵守这些规则。
- When a site detects an issue, it will first use the 6Bone registry to contact the site maintainer and work the issue.
- 当站点检测到问题时，它将首先使用6Bone注册表联系站点维护人员并解决问题。
- If nothing happens, or there is disagreement on what the right solution is, the issue can be brought to the 6Bone Operations group.
- 如果什么都没有发生，或者在正确的解决方案上存在分歧，可以将问题提交给6Bone运营团队。
- When the problem is related to a product issue, the site(s) involved is responsible for contact the product vendor and work toward its resolution.
- 当问题与产品问题相关时，相关站点负责联系产品供应商并努力解决问题。
- When an issue causes major operational problems, backbone sites may decide to temporarily set filters in order to restore service.
- 当问题导致重大操作问题时，主干站点可能会决定临时设置筛选器以恢复服务。
The result of bogus entries in routing tables is usually unreachable sites. Having guidelines to aggregate or reject routes will clean up the routing tables. It is expected that using these guidelines, routing on the 6Bone will be less sensitive to denial of service attacks due to misleading routes.
路由表中虚假条目的结果通常是无法访问的站点。制定聚合或拒绝路由的准则将清理路由表。预计使用这些准则，6Bone上的路由将因误导性路由而对拒绝服务攻击不那么敏感。
The 6Bone is a test network. Therefore, denial of service, packet disclosure, are to be expected.
6Bone是一个测试网络。因此，拒绝服务、数据包泄露是可以预料的。
This document is the result of shared experience on the 6Bone. Special thanks go to Bob Fink for the hard work make to date to direct the 6Bone effort, to David Kessens for the 6Bone registry, and to Guy Davies for his insightful contributions.
本文档是在6Bone上分享经验的结果。特别感谢Bob Fink迄今为止为指导6Bone努力所做的辛勤工作，感谢David Kessens为6Bone注册所做的努力，感谢Guy Davies为6Bone注册所做的富有洞察力的贡献。
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[1] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6 Testing Address Allocation", RFC 2471, December 1998.
[RFC 2471]Hinden，R.，Fink，R.和J.Postel（已故），“IPv6测试地址分配”，RFC 24711998年12月。
[RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC 2080]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC 2080，1997年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, March 1998.
[RFC 2283]Bates，T.，Chandra，R.，Katz，D.和Y.Rekhter，“BGP-4的多协议扩展”，RFC 2283，1998年3月。
[RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M. and J. Yu, Representation of IP Routing Policies in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[CRIPE-181]贝茨，T.，盖里奇，E.，琼切雷，L.，朱安尼格，J.，卡伦伯格，D.，特普斯特拉，M.和余志刚，路由注册表中IP路由策略的表示。技术报告CRIPE-181，CRIPE，CRIPE NCC，荷兰阿姆斯特丹，1994年10月。
Alain Durand Institut d'Informatique et de Mathematiques Appliquees de Grenoble IMAG BP 53 38041 Grenoble CEDEX 9 France
阿兰·杜兰德格勒诺布尔信息和数学研究所，英国石油公司53 38041法国格勒诺布尔CEDEX 9
Phone : +33 4 76 63 57 03
Fax : +33 4 76 51 49 64
EMail: Alain.Durand@imag.fr
Phone : +33 4 76 63 57 03
Fax : +33 4 76 51 49 64
EMail: Alain.Durand@imag.fr
Bertrand Buclin AT&T International S.A. Route de l'aeroport 31, CP 72 CH-1215 Geneve 15 (Switzerland)
伯特兰·布克林美国电话电报公司国际S.A.航空港31号航线，CP 72 CH-1215日内瓦15号（瑞士）
Phone : +41 22 929 37 40
Fax : +41 22 929 39 84
EMail: Bertrand.Buclin@ch.att.com
Phone : +41 22 929 37 40
Fax : +41 22 929 39 84
EMail: Bertrand.Buclin@ch.att.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。