Network Working Group R. Rockell
Request for Comments: 2772 Sprint
Obsoletes: 2546 R. Fink
Category: Informational ESnet
February 2000
Network Working Group R. Rockell
Request for Comments: 2772 Sprint
Obsoletes: 2546 R. Fink
Category: Informational ESnet
February 2000
6Bone Backbone Routing Guidelines
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.
6Bone是一个Ipv6测试平台，用于帮助Ipv6的发展和部署。因此，重要的是IPv6网络的核心主干保持稳定，并且所有运营商都有一套共同的规则和指导方针来部署IPv6路由设备。
This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist.
本文件为所有6bone路由设备运营商提供了一套指导原则，可作为高效、稳定部署6bone路由系统的参考。随着6Bone的复杂性不断增加，遵守一组通用规则变得越来越重要，这样才能存在一个高效、可扩展的主干网。
Table of Contents
目录
1. Introduction.................................................. 2
2. Scope of this document........................................ 3
3. Common Rules for the 6bone.................................... 3
3.1 Link-local prefixes...................................... 3
3.2 Site-local prefixes...................................... 4
3.3 Loopback and unspecified prefixes........................ 5
3.4 Multicast prefixes....................................... 5
3.5 IPv4 compatible prefixes................................. 5
3.6 IPv4-mapped prefixes..................................... 6
3.7 Default routes........................................... 6
3.8 Yet undefined unicast prefixes........................... 6
3.9 Inter-site links......................................... 6
3.10 6to4 Prefixes........................................... 7
3.11 Aggregation & advertisement issues...................... 7
4. Routing Policies for the 6bone................................ 7
5. The 6Bone Registry............................................ 8
6. Guidelines for new sites joining the 6Bone.................... 9
7. Guidelines for 6Bone pTLA sites............................... 9
8. 6Bone Operations group........................................ 11
9. Common rules enforcement for the 6bone........................ 11
10. Security Considerations...................................... 12
11. References................................................... 12
12. Authors' Addresses........................................... 13
13. Full Copyright Statement..................................... 14
1. Introduction.................................................. 2
2. Scope of this document........................................ 3
3. Common Rules for the 6bone.................................... 3
3.1 Link-local prefixes...................................... 3
3.2 Site-local prefixes...................................... 4
3.3 Loopback and unspecified prefixes........................ 5
3.4 Multicast prefixes....................................... 5
3.5 IPv4 compatible prefixes................................. 5
3.6 IPv4-mapped prefixes..................................... 6
3.7 Default routes........................................... 6
3.8 Yet undefined unicast prefixes........................... 6
3.9 Inter-site links......................................... 6
3.10 6to4 Prefixes........................................... 7
3.11 Aggregation & advertisement issues...................... 7
4. Routing Policies for the 6bone................................ 7
5. The 6Bone Registry............................................ 8
6. Guidelines for new sites joining the 6Bone.................... 9
7. Guidelines for 6Bone pTLA sites............................... 9
8. 6Bone Operations group........................................ 11
9. Common rules enforcement for the 6bone........................ 11
10. Security Considerations...................................... 12
11. References................................................... 12
12. Authors' Addresses........................................... 13
13. Full Copyright Statement..................................... 14
The 6Bone is an IPv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.
6Bone是一个IPv6测试平台，用于帮助IPv6的发展和部署。因此，重要的是IPv6网络的核心主干保持稳定，并且所有运营商都有一套共同的规则和指导方针来部署IPv6路由设备。
This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist.
本文件为所有6bone路由设备运营商提供了一套指导原则，可作为高效、稳定部署6bone路由系统的参考。随着6Bone的复杂性不断增加，遵守一组通用规则变得越来越重要，这样才能存在一个高效、可扩展的主干网。
This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as defined [RFC 2283], commonly referred to as BGP4+, as the currently accepted EGP.
本文件使用BGP-4，并对BGP-4进行多协议扩展，定义为[RFC 2283]，通常称为BGP4+，作为当前接受的EGP。
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]中所述进行解释。
This document is a best-practices Informational document aimed at IPv6 entities which operate under the 6Bone IPv6 testbed TLA allocation.
本文档是针对在6Bone IPv6测试台TLA分配下运行的IPv6实体的最佳实践信息文档。
This section details common rules governing the routing of the 6Bone. They are derived from the 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 and unspecified prefixes
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) 6to4 prefixes
10） 6to4前缀
11) aggregation & advertisement issues
11） 聚合和广告问题
This link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP. Under no circumstance should this prefix be seen in the 6Bone backbone routing table.
不得通过IGP或EGP播发此链路本地前缀（FE80:：/10）。在任何情况下，都不应在6Bone主干路由表中看到此前缀。
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, but are not limited to:
众所周知，链接本地前缀可能被错误广告的情况包括但不限于：
- 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. While vendors should be encouraged to fix the problem, the ultimate responsibility lies on the operator of that IPv6 site to correct the problem through whatever means necessary.
在这种情况下，应敦促供应商更正其代码。虽然应该鼓励供应商解决问题，但最终责任在于该IPv6站点的运营商通过任何必要的手段纠正问题。
Should a pTLA discover link-local prefixes coming from another pTLA, it is the responsibility of the pTLA leaking the routes to filter these, and correct the problem in a timely fashion. Should a pTLA discover that a downstream of that pTLA is leaking link-local prefixes, it is the pTLA's responsibility to ensure that these prefixes are not leaked to other pTLA's, or to other downstreams of that pTLA.
如果pTLA发现来自另一pTLA的链路本地前缀，则pTLA有责任泄漏路由以过滤这些前缀，并及时纠正问题。如果pTLA发现该pTLA的下游泄漏链路本地前缀，则pTLA有责任确保这些前缀不会泄漏到其他pTLA或该pTLA的其他下游。
Failure to filter such routes in a timely fashion may result in the manual shutting down of BGP4+ sessions to that pTLA, from other pTLA's.
未能及时过滤此类路由可能导致从其他pTLA手动关闭到该pTLA的BGP4+会话。
(Also, it is each pTLA, pNLA, and end-site's responsibility to not only filter their own BGP4+ sessions appropriately to peers, but to filter routes coming from peers as well, and to only allow those routes that fit the aggregation model, and do not cause operational problems).
（此外，每个pTLA、pNLA和终端站点都有责任不仅将其自身的BGP4+会话适当地过滤到对等方，还应过滤来自对等方的路由，并且只允许符合聚合模型且不会导致操作问题的路由）。
Site local prefixes (in the FEC0::/10 range) MAY be advertised by IGP's or EGP's within a site. The precise definition of a site is ongoing work of the IPng working group, but should generally include a group of nodes that are operating under one administrator or group of administrators, or a group of nodes which are used for a common purpose.
站点本地前缀（在FEC0:：/10范围内）可由站点内的IGP或EGP发布。站点的精确定义是IPng工作组正在进行的工作，但通常应包括在一个或多个管理员管理下运行的一组节点，或用于公共目的的一组节点。
Site-local prefixes MUST NOT be advertised across transit pNLAs, pTLAs, or leaf-sites.
站点本地前缀不得在transit PNLA、PTLA或叶站点之间进行广告。
Again, should site-local prefixes be leaked outside of a given site, it is the responsibility of the site to fix the problem in a timely manner, either through filters, or via other means which remove the operational impact that those prefixes had on the peering sites involved. However, every site SHOULD filter not only outbound on their EGP, but also inbound, in order to ensure proper routing announcements are not only sent, but also received.
同样，如果站点本地前缀泄漏到给定站点之外，则站点有责任通过过滤器或其他方式及时解决问题，以消除这些前缀对相关对等站点的操作影响。然而，每个站点不仅应该在其EGP上过滤出站，还应该过滤入站，以确保不仅发送而且接收正确的路由通知。
The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT be advertised by any routing protocol.
任何路由协议都不能公布环回前缀（：：1/128）和未指定的前缀（：：0/128）。
The same responsibility lies with the party guilty of advertising the loopback or unspecified prefix as in Section 3.1 and 3.2.
如第3.1节和第3.2节所述，宣传环回或未指定前缀的一方也应承担同样的责任。
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 of 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 at the time of the writing of this memo.
在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。
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 where a.b.c.d represents the octets of an IPv4 address) internally. As there is no real rationale today for doing so, these address SHOULD NOT be used or routed in the 6Bone.
站点可以选择在内部使用IPv4兼容地址（：：a.b.c.d，其中a.b.c.d表示IPv4地址的八位字节）。由于目前没有这样做的真正理由，这些地址不应该在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兼容的前缀。
Should ::/96 IPv4-compatible prefixes be leaked into an EGP, it is the responsibility of the party who is advertising the route to fix the problem, either through proper filters, or through other means, while it remains in the best interest of all particiapants of the 6Bone to filter both outbound and inbound at their IGP borders.
如果：：/96 IPv4兼容的前缀泄漏到EGP中，则发布路线广告的一方有责任通过适当的过滤器或其他方式解决问题，同时在其IGP边界对出站和入站进行过滤符合6Bone所有参与者的最佳利益。
IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d represents the octets of 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, to aid in deployment of IPv6.
IPv4映射的前缀（：：FFFF:a.b.c.d，其中a.b.c.d表示IPv4地址的八位字节）可以由站点内的IGP进行广告。对于站点中的某些仅限IPv6的节点来说，将此类路由指向翻译设备可能很有用，以帮助部署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 any downstream peer (non-pTLA site). Transit pNLAs MAY advertise a default route to any of their downstreams (other transit pNLA or leaf site).
pTLA可以向任何下游对等方（非pTLA站点）公布默认路由。Transit pNLA可向其任何下游（其他Transit pNLA或leaf站点）公布默认路线。
Should a default route be redistributed into an EGP and found on any pTLA EGP sessions, it is the responsibility of the pTLA to fix this problem immediately upon realization of the route's existence, and the responsibility of the guilty pTLA to push the entity from which the default route was originated, should the default route have originated from downstream of a pTLA.
如果将默认路由重新分配到EGP中，并在任何pTLA EGP会话中发现，则pTLA有责任在意识到路由存在后立即解决此问题，而有罪的pTLA有责任推动产生默认路由的实体，如果默认路由来自pTLA的下游。
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 the 6Bone range (3ffe::/16), and routing of global unicast prefixes yet undelegated in the range (3ffe::/16) are discussed in section 4, Routing policies, below.
下面的第4节“路由策略”中讨论了6Bone范围（3ffe:：/16）之外的全局单播前缀的路由，以及在该范围（3ffe:：/16）内尚未删除的全局单播前缀的路由。
Global IPv6 addresses must be used for the end points of inter-site links. In particular, IPv4 compatible addresses MUST NOT be used for tunnels.
站点间链路的端点必须使用全局IPv6地址。特别是，与IPv4兼容的地址不得用于隧道。
Sites MAY use Other addressing schemes for Inter-site links, but these addresses MUST NOT be advertised into the IPv6 global routing table.
站点可以为站点间链路使用其他寻址方案，但不得将这些地址播发到IPv6全局路由表中。
Prefixes for inter-site links MUST NOT be injected in the global routing tables.
不得在全局路由表中插入站点间链接的前缀。
The 6to4 prefix, or some portion thereof, MAY be announced by any pTLA which has a current implementation of 6to4 in their IPv6 network. However, as 6to4 implementors gain more operational experience, it MAY be necessary to change this in some way. At the time of the writing of this docuement, any pTLA MAY announce the 6to4 prefix into global EBGP. However, in order to announce this block, the pTLA MUST have a 6to4 router active, sourcing this prefix announcement.
6to4前缀或其部分可由在其IPv6网络中当前实现6to4的任何pTLA宣布。然而，随着6to4实现者获得更多的操作经验，可能有必要以某种方式对此进行更改。在编写本文件时，任何pTLA均可将6to4前缀公布到全局EBGP中。但是，为了宣布此块，pTLA必须有一个6to4路由器处于活动状态，以获取此前缀声明。
This section subject to change, and MAY vary, depending on 6to4 progress within the NGTRANS working group.
根据NGTRANS工作组的进展情况，本节可能会有所更改，也可能会有所不同。
Route aggregation MUST be performed by any border router talking EGP with any other IPv6 sites. More-specifics MUST NOT be leaked into or across the IPv6 6Bone backbone.
路由聚合必须由与任何其他IPv6站点进行EGP对话的任何边界路由器执行。更多细节不得泄漏到IPv6 6Bone主干网或通过IPv6 6Bone主干网泄漏。
Leaf sites or pNLAs MUST only advertise to an upstream provider the prefixes assigned by that provider. Advertising a prefix assigned by another provider to a provider is not acceptable, and breaks the aggregation model. A site MUST NOT advertise a prefix from another provider to a provider as a way around the multi-homing problem. However, in the interest of testing new solutions, one may break this policy, so long as ALL affected parties are aware of this test, and all agree to support this testing. These policy breaks MUST NOT affect the 6bone routing table globally.
叶站点或PNLA必须仅向上游提供程序播发该提供程序分配的前缀。发布由另一个提供者分配给提供者的前缀是不可接受的，这会破坏聚合模型。站点不得将前缀从另一个提供者播发到提供者，以此作为解决多宿主问题的方法。但是，为了测试新的解决方案，只要所有受影响方都知道此测试，并且都同意支持此测试，就可以违反此政策。这些策略中断不能全局影响6bone路由表。
To clarify, if one has two upstream pNLA or pTLA providers, (A and B for this example), one MUST only announce the prefix delegated to one by provider A to provider A, and one MUST only announce the prefeix delegated by one from provider B upstream to provider B. There exists no circumstance where this should be violated, as it breaks the aggregation model, and could globally affect routing decisions if downstreams are able to leak other providers' more specific delegations up to a pTLA. As the IPNG working group works through the multi-homing problem, there may be a need to alter this rule slightly, to test new strategies for deployment. However, in the case of current specifications at the time of this writing, there is no reason to advertise more specifics, and pTLA's MUST adhere to the current aggregation model.
为了澄清，如果一个供应商有两个上游pNLA或pTLA供应商（本例中为A和B），则必须只宣布供应商A向供应商A委托给一个供应商的前缀，并且必须只宣布供应商B向供应商B上游委托给一个供应商的前缀。不存在违反此规定的情况，因为它打破了聚合模型，并且如果下游能够泄露其他提供商更具体的授权给pTLA，则可能会在全球范围内影响路由决策。由于IPNG工作组正在解决多主问题，因此可能需要稍微修改此规则，以测试新的部署策略。然而，就撰写本文时的当前规范而言，没有理由宣传更多细节，pTLA必须遵守当前的聚合模型。
Site border routers for pNLA or leaf sites MUST NOT advertise prefixes more specific (longer) than the prefix that was allocated by their upstream provider.
pNLA或叶站点的站点边界路由器不得公布比其上游提供商分配的前缀更具体（更长）的前缀。
All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other 6bone pTLAs unless special peering arrangements are implemented. When such special peering aggreements are in place between any two or more 6bone pTLAs, care MUST be taken not to leak the more specifics to other 6bone pTLAs not participating in the peering aggreement. 6bone pTLAs which have such agreements in place MUST NOT advertise other 6bone pTLA more specifics to downstream 6bone pNLAs or leaf sites, as this will break the best-path routing decision.
除非实施了特殊的对等安排，否则所有6bone pTLA不得向其他6bone pTLA播发长于给定pTLA委托（当前为/24或/28）的前缀。当任何两个或多个6bone PTLA之间存在此类特殊对等聚合时，必须注意不要将更多细节泄露给未参与对等聚合的其他6bone PTLA。6bone pTLA（已签订此类协议）不得向下游6bone PNLA或leaf站点宣传其他6bone pTLA更多细节，因为这将破坏最佳路径路由决策。
The peering agreements across the 6Bone may be by nature non-commercial, and therefore MAY allow transit traffic, if peering agreements of this nature are made. However, no pTLA is REQUIRED to give or receive transit service from another pTLA.
跨6Bone的对等协议本质上可能是非商业性的，因此，如果达成这种性质的对等协议，则可能允许过境流量。但是，不要求pTLA提供或接收来自另一pTLA的运输服务。
Eventually, the Internet registries will assign prefixes under other than the 6Bone TLA (3FFE::/16). As of the time this document was written in 1999, the Internet registries were starting to assign /35 sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly be used in the future.
最终，Internet注册中心将在6Bone TLA（3FFE:：/16）之外的其他名称下分配前缀。自1999年编写本文件时起，互联网注册处开始从2001:：/16 TLA分配/35子TLA（sTLA）块。其他的肯定会在将来使用。
The organizations receiving prefixes under these newer TLAs would be expected to want to establish peering and connectivity relationships with other IPv6 networks, both in the newer TLA space and in the 6bone pTLA space. Peering between new TLA's and the current 6Bone pTLA's MAY occur, and details such as transit, and what routes are received by each, are outside of general peering rules as stated in this memo, and are left up to the members of those TLA's and pTLA's that are establishing said peerings. However, it is expected that most of the rules discussed here are equally applicable to new TLAs.
在这些较新的TLA下接收前缀的组织希望在较新的TLA空间和6bone pTLA空间中与其他IPv6网络建立对等和连接关系。新TLA和当前6Bone pTLA之间可能会发生对等，而诸如中转和每个pTLA收到的路线等细节超出了本备忘录中规定的一般对等规则，并由建立上述对等的TLA和pTLA的成员决定。然而，预计这里讨论的大多数规则同样适用于新的TLA。
The 6Bone registry is a RIPE-181 database with IPv6 extensions used to store information about the 6Bone, and its sites. The 6bone is accessible at:
6Bone注册表是一个成熟的RIME-181数据库，具有IPv6扩展，用于存储有关6Bone及其站点的信息。可通过以下网址访问6bone：
<http://www.6bone.net/whois.html>)
<http://www.6bone.net/whois.html>)
Each 6Bone site MUST maintain the relevant entries in the 6Bone registry. In particular, the following object MUST be present for all 6Bone leaf sites, pNLAs and pTLAs:
每个6Bone站点必须在6Bone注册表中维护相关条目。特别是，所有6Bone叶位、PNLA和PTLA必须具有以下对象：
- IPv6-site: site description
- IPv6站点：站点描述
- Inet6num: prefix delegation (one record MUST exist for each delegation)
- Inet6num:前缀委派（每个委派必须存在一条记录）
- Mntner: contact info for site maintance/administration staff.
- Mntner：现场维护/管理人员的联系信息。
Other object 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 MAY NOT necessarily reside in the 6Bone registry. They can be stored within any of the Internet registry databases (ARIN, APNIC, RIPE-NCC, etc.)
其他对象可由站点自行维护，如路由策略描述符、人员或角色对象。Mntner对象必须引用role或person对象，但这些对象不一定位于6Bone注册表中。它们可以存储在任何Internet注册表数据库（ARIN、APNIC、RIME-NCC等）中
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 web site at <http://www.6bone.net> has various information and tools to help find candidate 6bone networks.
加入6Bone的新站点应寻求连接到其所在区域内的公交pNLA或pTLA，最好尽可能靠近其现有IPv4物理路径和互联网服务路由路径。6Bone网站位于<http://www.6bone.net>有各种信息和工具来帮助寻找候选人6bone网络。
Any site connected to the 6Bone MUST maintain a DNS server for forward name lookups and reverse address lookups. The joining site MUST maintain the 6Bone objects relative to its site, as describe in section 5.
连接到6Bone的任何站点都必须维护一个DNS服务器，以便进行正向名称查找和反向地址查找。如第5节所述，连接站点必须保持6Bone对象相对于其站点。
The upstream provider MUST delegate the reverse address translation zone in DNS to the joining site, or have an agreement in place to perform primary DNS for that downstream. The provider MUST also create the 6Bone registry inet6num object reflecting the delegated address space.
上游提供商必须将DNS中的反向地址转换区域委托给加入站点，或者签订协议，为该下游执行主DNS。提供程序还必须创建反映委派地址空间的6Bone注册表inet6num对象。
Up to date informatino about how to join the 6Bone is available on the 6Bone Web site at <http://www.6bone.net>.
有关如何加入6Bone的最新信息，请访问6Bone网站：<http://www.6bone.net>.
The following rules apply to qualify for a 6Bone pTLA allocation. It should be recognized that holders of 6Bone pTLA allocations are expected to provide production quality backbone network services for the 6Bone.
以下规则适用于6Bone pTLA分配的资格。应认识到，6Bone pTLA分配的持有人有望为6Bone提供生产质量骨干网络服务。
1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period the Applicant must be operationally providing the following:
1. pTLA申请人必须具有至少三（3）个月的6Bone终端站点或pNLA运输的合格经验。在整个资格认证期间，申请人必须在操作上提供以下内容：
a. Fully maintained, up to date, 6Bone Registry entries for their ipv6-site inet6num, mntner, and person objects, including each tunnel that the Applicant has.
a. 为其ipv6站点inet6num、mntner和person对象（包括申请人拥有的每个隧道）全面维护最新的6Bone注册表项。
b. Fully maintained, and reliable, BGP4+ peering and connectivity between the Applicant's boundary router and the appropriate connection point into the 6Bone. This router must be IPv6 pingable. This criteria is judged by members of the 6Bone Operations Group at the time of the Applicant's pTLA request.
b. 申请人边界路由器与6Bone的适当连接点之间的BGP4+对等和连接得到充分维护且可靠。此路由器必须是IPv6可ping的。在申请人提出pTLA请求时，该标准由6Bone Operations Group的成员进行判断。
c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system.
c. 申请人路由器和至少一个主机系统的完全维护DNS转发（AAAA）和反向（ip6.int）条目。
d. A fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing the Applicant's IPv6 services. This server must be IPv6 pingable.
d. 一个完全维护且可靠的IPv6可访问系统，至少提供一个或多个网页，描述申请人的IPv6服务。此服务器必须是IPv6可ping的。
2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following:
2. pTLA申请人必须具备提供“生产质量”6Bone骨干服务的能力和意图。申请人必须提供一份声明和信息以支持该索赔。这必须包括以下内容：
a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA applicant.
a. 支持人员至少两人，最好是三人，并在pTLA申请人的ipv6站点对象中为每个人注册人员属性。
b. A common mailbox for support contact purposes that all support staff have acess to, pointed to with a notify attribute in the ipv6-site object for the pTLA Applicant.
b. 所有支持人员都有权访问的用于支持联系目的的公用邮箱，在pTLA申请人的ipv6站点对象中使用notify属性指向该邮箱。
3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest. Applicant must provide a statement and information in support this claim.
3. pTLA申请人必须有一个潜在的“用户社区”，该社区将通过成为pTLA而得到服务，例如，申请人是某个地区、国家或利益中心的主要互联网服务提供商。申请人必须提供一份声明和信息以支持该索赔。
4. The pTLA Applicant MUST commit to abide by the current 6Bone operational rules and policies as they exist at time of its application, and agree to abide by future 6Bone backbone operational rules and policies as they evolve by consensus of the 6Bone backbone and user community.
4. pTLA申请人必须承诺遵守申请时存在的当前6Bone操作规则和政策，并同意在6Bone主干网和用户社区协商一致的情况下遵守未来的6Bone主干网操作规则和政策。
When an Applicant seeks to receive a pTLA allocation, it will apply to the 6Bone Operations Group (see section 8 below) by providing to the Group information in support of its claims that it meets the criteria above.
当申请人寻求获得pTLA分配时，将向6Bone Operations Group（见下文第8节）申请，向该集团提供支持其符合上述标准的声明的信息。
The 6Bone Operations Group is the group in charge of monitoring and policing adherence to the current rules. Membership in the 6Bone Operations Group is mandatory for, and restricted to, sites connected to the 6Bone.
6Bone运营小组负责监督和监管当前规则的遵守情况。对于连接到6Bone的站点，6Bone操作组的成员资格是强制性的，并且仅限于此。
The 6Bone Operations Group is currently defined by those members of the existing 6Bone mailing list who represent sites participating in the 6Bone. Therefore it is incumbent on relevant site contacts to join the 6Bone mailing list. Instructions on how to join the list are maintained on the 6Bone web site at < http://www.6bone.net>.
6Bone操作组目前由现有6Bone邮件列表中代表参与6Bone的站点的成员定义。因此，相关站点联系人有义务加入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 and policies described in this document in order to maintain the 6Bone as a quality tool for the deployment of, and transition to, IPv6 protocols and the products implementing them.
参加6Bone是一项自愿和慈善的事业。但是，参与的站点应遵守本文档中描述的规则和政策，以保持6Bone作为部署和转换IPv6协议及其实施产品的优质工具。
The following is in support of policing adherence to 6Bone rules and policies:
以下内容支持遵守6Bone规则和政策：
1. Each pTLA site has committed to implement the 6Bone's rules and policies, and SHOULD try to ensure they are adhered to by sites within their administrative control, i.e. those to who prefixes under their respective pTLA prefix have been delegated.
1. 各pTLA营业点已承诺实施6Bone的规则和政策，并应努力确保其行政控制范围内的营业点遵守这些规则和政策，即已将其各自pTLA前缀下的前缀委托给谁。
2. When a site detects an issue, it SHOULD first use the 6Bone registry to contact the site maintainer and work the issue.
2. 当站点检测到问题时，应首先使用6Bone注册表联系站点维护人员并解决问题。
3. If nothing happens, or there is disagreement on what the right solution is, the issue SHOULD be brought to the 6Bone Operations Group.
3. 如果什么都没有发生，或者对正确的解决方案存在分歧，则应将问题提交给6Bone运营小组。
4. When the problem is related to a product issue, the site(s) involved SHOULD be responsible for contacting the product vendor and work toward its resolution.
4. 当问题与产品问题相关时，相关站点应负责联系产品供应商并努力解决问题。
5. When an issue causes major operational problems, backbone sites SHOULD decide to temporarily set filters in order to restore service.
5. 当问题导致重大操作问题时，主干站点应决定临时设置筛选器以恢复服务。
The result of incorrect 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 rules and policies, routing on the 6Bone will be less sensitive to denial of service attacks due to misleading routes.
路由表中不正确条目的结果通常是无法访问的站点。制定聚合或拒绝路由的准则将清理路由表。预计使用这些规则和策略，6Bone上的路由对拒绝服务攻击的敏感度将降低，因为存在误导性路由。
The 6Bone is an IPv6 testbed to assist in the evolution and deployment of IPv6. Therefore, denial of service or packet disclosure are to be expected. However, it is the pTLA from where the attack originated who has ultimate responsibility for isolating and fixing problems of this nature. It is also every 6Bone site's responsibility to safely introduce new test systems into the 6Bone, by placing them at a strategically safe places which will have minimal impact on other 6Bone sites, should bugs or misconfigurations occur.
6Bone是一个IPv6测试平台，用于帮助IPv6的发展和部署。因此，拒绝服务或数据包泄露是可以预料的。然而，正是pTLA发起了攻击，他们对隔离和解决此类问题负有最终责任。每个6Bone站点都有责任安全地将新的测试系统引入6Bone，方法是将它们放置在战略安全的位置，如果出现错误或错误配置，对其他6Bone站点的影响最小。
[RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC 2373]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 2373，1998年7月。
[RFC 2471] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998.
[RFC 2471]Hinden，R.，Fink，R.和J.Postel，“IPv6测试地址分配”，RFC 2471，1998年12月。
[RFC 2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC 2546, March 1999
[RFC 2546]Durand，A.和B.Buclin，“6骨路由实践”，RFC 2546，1999年3月
[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月。
Rob Rockell EMail: rrockell@sprint.net
Rob Rockell电子邮件：rrockell@sprint.net
Bob Fink EMail: fink@es.net
Bob Fink电子邮件：fink@es.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。