Network Working Group R. Hinden
Request for Comments: 2450 Nokia
Category: Informational December 1998
Network Working Group R. Hinden
Request for Comments: 2450 Nokia
Category: Informational December 1998
Proposed TLA and NLA Assignment Rules
拟议的TLA和NLA分配规则
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's.
本文件提出了[AGGR]中定义的顶级聚合标识符（TLA ID）和下一级聚合标识符（NLA ID）的规则。这些拟议规则适用于分配TLA ID的登记处和接收TLA ID的组织。
This proposal is intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. Its content represents the result of extensive discussion between the IPng working group, IANA, and Registries.
本提案旨在作为IPng工作组向IANA和注册处提供的投入。它不适用于任何正式的IETF状态。其内容代表了IPng工作组、IANA和注册中心之间广泛讨论的结果。
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 proposed TLA and NLA assignment rules described in this document are intended for the first two years of IPv6 TLA address assignments. As routing technology evolves and we gain additional experience with allocating IPv6 addresses the procedures proposed in this document may change.
本文件中描述的拟议TLA和NLA分配规则适用于IPv6 TLA地址分配的前两年。随着路由技术的发展，以及我们在分配IPv6地址方面获得的更多经验，本文档中提出的过程可能会发生变化。
This document proposes assignment rules for the TLA ID and NLA ID fields in the IPv6 Aggregatable Global Unicast Address Format. This address format is designed to support both the current provider-based aggregation and a new type of exchange-based aggregation. The combination will allow efficient routing aggregation for sites that connect directly to providers and for sites that connect to exchanges. Sites will have the choice to connect to either type of aggregation entity.
本文档提出了IPv6可聚合全局单播地址格式中TLA ID和NLA ID字段的分配规则。此地址格式旨在支持当前基于提供程序的聚合和新类型的基于exchange的聚合。这种组合将允许直接连接到提供商的站点和连接到交换机的站点进行有效的路由聚合。站点可以选择连接到任一类型的聚合实体。
While this address format is designed to support exchange-based aggregation (in addition to current provider-based aggregation) it is not dependent on exchanges for its overall route aggregation properties. It will provide efficient route aggregation with only provider-based aggregation.
虽然此地址格式旨在支持基于exchange的聚合（除了当前基于提供程序的聚合之外），但其总体路由聚合属性并不依赖于exchange。它将仅通过基于提供商的聚合提供有效的路由聚合。
The aggregatable global unicast address format as defined in [AGGR] is as follows:
[AGGR]中定义的可聚合全局单播地址格式如下：
| 3| 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+
| 3| 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+
<--Public Topology---> Site
<-------->
Topology
<------Interface Identifier----->
<--Public Topology---> Site
<-------->
Topology
<------Interface Identifier----->
Where
哪里
FP Format Prefix (001) TLA ID Top-Level Aggregation Identifier RES Reserved for future use NLA ID Next-Level Aggregation Identifier SLA ID Site-Level Aggregation Identifier INTERFACE ID Interface Identifier
FP格式前缀（001）TLA ID顶级聚合标识符保留供将来使用NLA ID下一级聚合标识符SLA ID站点级聚合标识符接口ID接口标识符
The design choices for the size of the fields in the aggregatable address format were based on the need to meet a number of technical requirements that are described in [AGGR]. An extract of the technical requirements from [AGGR] is as follows:
可聚合地址格式中字段大小的设计选择基于满足[AGGR]中描述的许多技术要求的需要。[AGGR]的技术要求摘录如下：
The size of the Top-Level Aggregation Identifier is 13 bits. This allows for 8,192 TLA ID's. This size was chosen to insure that the default-free routing table in top level routers in the Internet is kept within the limits, with a reasonable margin, of the current routing technology. The margin is important because default-free routers will also carry a significant number of longer (i.e., more-specific) prefixes for optimizing paths internal to a TLA and between TLAs.
顶级聚合标识符的大小为13位。这允许8192个TLA ID。选择此大小是为了确保Internet顶级路由器中的默认空闲路由表保持在当前路由技术的限制范围内，并留有合理的余量。余量很重要，因为无默认路由器也将携带大量更长（即更具体）的前缀，用于优化TLA内部和TLA之间的路径。
The important issue is not only the size of the default-free routing table, but the complexity of the topology that determines the number of copies of the default-free routes that a router must examine while computing a forwarding table. In current practice with IPv4, it is common to see a prefix announced fifteen times via different paths. The complexity of Internet topology is very likely to increase in the future. It is important that IPv6 default-free routing support additional complexity as well as a considerably larger internet.
重要的问题不仅在于默认空闲路由表的大小，还在于拓扑的复杂性，它决定了路由器在计算转发表时必须检查的默认空闲路由副本的数量。在当前的IPv4实践中，通常会看到前缀通过不同的路径发布15次。互联网拓扑结构的复杂性在未来很可能会增加。重要的是，IPv6无默认路由支持额外的复杂性以及相当大的internet。
It should be noted for comparison that the current IPv4 default-free routing table is approximately 50,000 prefixes. While this shows that it is possible to support more routes than 8,192 it is matter of debate if the number of prefixes supported today in IPv4 is already too high for current routing technology. There are serious issues of route stability as well as cases of providers not supporting all top level prefixes. The technical requirement was to pick a TLA ID size that was below, with a reasonable margin, what was being done with IPv4.
需要注意的是，当前的IPv4默认免费路由表大约有50000个前缀。虽然这表明支持8192以上的路由是可能的，但如果目前IPv4中支持的前缀数量对于当前的路由技术来说已经太高，这是一个有争议的问题。存在严重的路由稳定性问题以及提供商不支持所有顶级前缀的情况。技术要求是选择一个TLA ID大小，该大小低于IPv4所做的操作，并具有合理的余量。
The choice of 13 bits for the TLA field was an engineering compromise. Fewer bits would have been too small by not supporting enough top level organizations. More bits would have exceeded what can be reasonably accommodated, with a reasonable margin, with current routing technology in order to deal with the issues described in the previous paragraphs.
TLA字段选择13位是一种工程折衷。如果不支持足够的顶级组织，那么更少的BIT就会太小。更多的比特数将超过当前路由技术合理容纳的比特数，并有合理的余量，以便处理前面段落中描述的问题。
If in the future, routing technology improves to support a larger number of top level routes in the default-free routing tables there are two choices on how to increase the number TLA identifiers. The first is to expand the TLA ID field into the reserved field. This would increase the number of TLA ID's to approximately 2 million. The second approach is to allocate another format prefix (FP) for use with this address format. Either or a combination of these approaches allows the number of TLA ID's to increase significantly.
如果在将来，路由技术得到改进，以支持默认自由路由表中更多的顶级路由，那么关于如何增加TLA标识符的数量，有两种选择。第一个是将TLA ID字段扩展到保留字段。这将使TLA ID的数量增加到大约200万。第二种方法是分配另一个格式前缀（FP）用于此地址格式。这些方法中的任何一种或组合都允许TLA ID的数量显著增加。
The size of the Reserved field is 8 bits. This size was chosen to allow significant growth of either the TLA ID and/or the NLA ID fields.
保留字段的大小为8位。选择此大小是为了允许TLA ID和/或NLA ID字段显著增长。
The size of the Next-Level Aggregation Identifier field is 24 bits. This allows for approximately sixteen million NLA ID's if used in a flat manner. Used hierarchically it allows for a complexity roughly equivalent to the IPv4 address space (assuming an average network size of 254 interfaces). If in the future additional room for complexity is needed in the NLA ID, this may be accommodated by extending the NLA ID into the Reserved field.
下一级聚合标识符字段的大小为24位。如果以平面方式使用，这允许大约1600万NLA ID。分层使用时，其复杂性大致相当于IPv4地址空间（假设平均网络大小为254个接口）。如果未来NLA ID中需要额外的复杂性空间，则可以通过将NLA ID扩展到保留字段中来适应这一点。
The size of the Site-Level Aggregation Identifier field is 16 bits. This supports 65,535 individual subnets per site. The design goal for the size of this field was to be sufficient for all but the largest of organizations. Organizations which need additional subnets can arrange with the organization they are obtaining Internet service from to obtain additional site identifiers and use this to create additional subnets.
站点级聚合标识符字段的大小为16位。每个站点支持65535个单独的子网。该领域规模的设计目标是，除最大的组织外，其他所有组织都能胜任。需要额外子网的组织可以与他们从中获取Internet服务的组织进行安排，以获取额外的站点标识符，并使用此标识符创建额外的子网。
The Site-Level Aggregation Identifier field was given a fixed size in order to force the length of all prefixes identifying a particular site to be the same length (i.e., 48 bits). This facilitates movement of sites in the topology (e.g., changing service providers and multi-homing to multiple service providers).
站点级聚合标识符字段的大小是固定的，以便强制标识特定站点的所有前缀的长度相同（即48位）。这有助于在拓扑中移动站点（例如，更改服务提供商和多个服务提供商的多归属）。
The Interface ID Interface Identifier field is 64 bits. This size was chosen to meet the requirement specified in [ARCH] to support EUI-64 based Interface Identifiers.
接口ID接口标识符字段为64位。选择该尺寸是为了满足[ARCH]中规定的要求，以支持基于EUI-64的接口标识符。
The proposed TLA/NLA assignment rules described in this document are consistent with these technical requirements.
本文件中描述的拟议TLA/NLA分配规则与这些技术要求一致。
The specific technical motivation for the proposed TLA/NLA assignment rules described in this document is as follows:
本文件中所述拟议TLA/NLA分配规则的具体技术动机如下：
- Limit the number of top level prefixes in the Internet to a manageable size. This is important to insure that the default-free routing table in the top level routers in the Internet is kept within the limits, with a reasonable margin, of current routing technology.
- 将Internet中顶级前缀的数量限制为可管理的大小。这对于确保Internet顶级路由器中的默认自由路由表保持在当前路由技术的限制范围内（具有合理的余量）非常重要。
- Only assign top level prefixes to transit providers, not to leaf sites even if they are multiply homed. The aggregation address format is designed to have a clear separation between transit providers and leaf sites. Sites which wish to be multihomed to multiple transit providers have in IPv6 a number of alternatives to having a top level prefix.
- 仅将顶级前缀分配给传输提供程序，而不分配给叶站点，即使它们是多址的。聚合地址格式的设计目的是在传输提供商和叶站点之间有一个清晰的分离。希望与多个传输提供商建立多址连接的站点在IPv6中有许多替代方案，而不是使用顶级前缀。
- Only assign top level prefixes to organizations who are capable and intend to provide operational IPv6 transit services within three months of assignment. The goal is to not assign top level prefixes to organizations who only want a prefix in case they might provide service sometime in the future. The assignment of prefixes is intended to closely match the operational IPv6 Internet and to be consistent with the current practice of registries making assignments when addresses are actually used.
- 仅将顶级前缀分配给有能力并打算在分配后三个月内提供运营IPv6传输服务的组织。这样做的目的是不将顶级前缀分配给只需要前缀的组织，以防它们将来可能提供服务。前缀的分配旨在与可运行的IPv6互联网紧密匹配，并与注册中心在实际使用地址时进行分配的现行做法保持一致。
- Organizations assigned TLA ID's are required to make all the assignments publically available. This is necessary in order for the registries to have accurate information on assignments and to enable trouble shooting Internet problems.
- 分配TLA ID的组织必须公开所有分配。这是必要的，以便登记处能够获得关于转让的准确信息，并能够解决互联网问题。
- Allocation of prefixes that are consistent with the address format in [AGGR]. Specifically the allocation prefixes that are not longer than 48 bits as to not infringe into the SLA and Interface Identifier fields. This is to facilitate movement of sites in the topology (e.g., changing service providers and multi-homing to multiple service providers).
- 分配与[AGGR]中地址格式一致的前缀。具体而言，不超过48位的分配前缀不侵犯SLA和接口标识符字段。这是为了促进拓扑中站点的移动（例如，更改服务提供商和多主到多个服务提供商）。
TLA ID's are assigned to organizations providing transit topology. They are specifically not assigned to organizations only providing leaf topology. TLA ID assignment does not imply ownership. It does imply stewardship over a valuable Internet resource.
TLA ID分配给提供公交拓扑的组织。它们并没有专门分配给仅提供叶拓扑的组织。TLA ID分配并不意味着所有权。它确实意味着对宝贵的互联网资源的管理。
The IAB and IESG have authorized the Internet Assigned Numbers Authority (IANA) as the appropriate entity to have the responsibility for the management of the IPv6 address space as defined in [ALLOC].
IAB和IESG已授权互联网分配号码管理局（IANA）作为适当实体，负责管理[ALLOC]中定义的IPv6地址空间。
The IANA will assign small blocks (e.g., few hundred) of TLA ID's to registries. The registries will assign the TLA ID's to organizations meeting the requirements for TLA ID assignment. When the registries have assigned all of their TLA ID's they can request that the IANA give them another block. The blocks do not have to be contiguous. The IANA may also assign TLA ID's to organizations directly. This includes the temporary TLA assignment for testing and experimental usage for activities such as the 6bone or new approaches like exchanges.
IANA将把TLA ID的小块（例如几百块）分配给注册中心。登记处将向满足TLA ID分配要求的组织分配TLA ID。当注册中心分配了所有TLA ID后，他们可以请求IANA再给他们一个区块。这些块不必是连续的。IANA还可以直接向组织分配TLA ID。这包括临时TLA分配，用于测试和实验活动，如6bone或新方法（如Exchange）。
TLA allocations will be done in two stages. The first stage is to allocate a Sub-TLA ID. When the recipient has demonstrated that they have assigned more than 90% of the NLA ID for their Sub-TLA ID, they will be allocated a TLA ID. The Sub-TLA ID does not have to be returned.
TLA分配将分两个阶段进行。第一阶段是分配一个子TLA ID。当接收人证明他们已经为其子TLA ID分配了超过90%的NLA ID时，他们将被分配一个TLA ID。子TLA ID不必返回。
Sub-TLA ID's are assigned out of TLA ID 0x0001 as follows. Note that use of the Reserved field to create the Sub-TLA field is specific to TLA ID 0x0001. It does not affect any other TLA.
子TLA ID从TLA ID 0x0001中分配，如下所示。请注意，使用保留字段创建子TLA字段特定于TLA ID 0x0001。它不影响任何其他TLA。
| 3 | 13 | 13 | 19 |
+----+----------+---------+---------------+
| FP | TLA | Sub-TLA | NLA |
| | ID | | ID |
+----+----------+---------+---------------+
| 3 | 13 | 13 | 19 |
+----+----------+---------+---------------+
| FP | TLA | Sub-TLA | NLA |
| | ID | | ID |
+----+----------+---------+---------------+
where:
哪里：
FP = 001 = Format Prefix
FP=001=格式前缀
This is the Format Prefix used to identify aggregatable global unicast addresses.
这是用于标识可聚合全局单播地址的格式前缀。
TLA ID = 0x0001 = Top-Level Aggregation Identifier
TLA ID=0x0001=顶级聚合标识符
This is the TLA ID assigned by the IANA for Sub-TLA allocation.
这是IANA为子TLA分配而分配的TLA ID。
Sub-TLA ID = Sub-TLA Aggregation Identifier
子TLA ID=子TLA聚合标识符
The Sub-TLA ID field is used by the registries for initial allocations to organizations meeting the requirements in Section 5.2 of this document. The IANA will assign small blocks (e.g., few hundred) of Sub-TLA ID's to registries. The registries will assign the Sub-TLA ID's to organizations meeting the requirements specified in Section 5.2. When the registries have assigned all of their Sub-TLA ID's they can request that the IANA give them another block. The blocks do not have to be contiguous. The
登记处使用Sub-TLA ID字段对满足本文件第5.2节要求的组织进行初始分配。IANA将向注册中心分配小的子TLA ID块（例如几百个）。登记处将向满足第5.2节规定要求的组织分配次级TLA ID。当注册中心分配了所有子TLA ID后，他们可以请求IANA给他们另一个块。这些块不必是连续的。这个
IANA may also assign Sub-TLA ID's to organizations directly. This includes the temporary TLA assignment for testing and experimental usage for activities such as the 6bone or new approaches like exchanges.
IANA也可以将子TLA ID直接分配给组织。这包括临时TLA分配，用于测试和实验活动，如6bone或新方法（如Exchange）。
NLA ID = Next-Level Aggregation Identifier
NLA ID=下一级聚合标识符
Next-Level Aggregation ID's are used by organizations assigned a TLA ID to create an addressing hierarchy and to identify sites. The organization can assign the top part of the NLA ID in a manner to create an addressing hierarchy appropriate to its network. See Section 6.0 for more detail.
分配了TLA ID的组织使用下一级聚合ID来创建寻址层次结构和标识站点。组织可以以创建适合其网络的寻址层次结构的方式分配NLA ID的顶部。详见第6.0节。
Sub-TLA allocations are interim until the organization receiving the Sub-TLA can show evidence of IPv6 Internet transit service. If transit service can not be demonstrated by three months from the date of allocation the Sub-TLA allocation will be revoked.
子TLA分配是临时的，直到接收子TLA的组织能够显示IPv6 Internet传输服务的证据为止。如果自分配之日起三个月内无法证明公交服务，则将撤销TLA子分配。
As part of assigning a TLA ID to an organization, the IANA or Registries may initially only assign a fraction of the NLA ID space for a particular TLA ID to the organization receiving the TLA ID assignment. When the organization has assigned more than 90% of the NLA ID space it may request additional NLA ID space in its TLA ID.
作为向组织分配TLA ID的一部分，IANA或注册中心最初可能仅向接收TLA ID分配的组织分配特定TLA ID的NLA ID空间的一小部分。当组织分配了超过90%的NLA ID空间时，可以在其TLA ID中请求额外的NLA ID空间。
The proposed assignment requirements are intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status.
拟议的转让要求旨在作为IPng工作组向IANA和登记处提供的信息。它不适用于任何正式的IETF状态。
Registries enforce the following requirements for organizations assigned Sub-TLA and TLA ID's:
注册中心对分配了子TLA和TLA ID的组织强制执行以下要求：
1) Must have a plan to offer native IPv6 service within 3 months from assignment. The plan must include NLA ID allocation and registration procedures. NLA ID allocation and registration may be subcontracted to other organizations such as a registry.
1) 必须有计划在派遣后3个月内提供本机IPv6服务。该计划必须包括NLA ID分配和注册程序。NLA ID分配和注册可以分包给其他组织，如注册中心。
Native IPv6 service is defined as providing IPv6 service as defined in the appropriate "IPv6 over <link>" specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc., for the link at the boundary of the organization. This should include running Neighbor Discovery (as appropriate) and exchanging IPv6 routing information. The method the organization uses to carry IPv6 traffic across its network is independent of this definition and is a local issue for the organization.
本机IPv6服务定义为为为组织边界的链路提供适当的“IPv6 over<link>”规范中定义的IPv6服务，如“IPv6 over Ethernet”[Ethernet]、“IPv6 over FDDI”[FDDI]等。这应该包括运行邻居发现（视情况而定）和交换IPv6路由信息。组织用于在其网络上承载IPv6流量的方法与此定义无关，是组织的本地问题。
2) Must have a verifiable track record of providing Internet transit to other organizations. Sub-TLA and/or TLA ID's must not be assigned to organizations that are only providing leaf service even if multihomed.
2) 必须有向其他组织提供互联网传输的可验证记录。子TLA和/或TLA ID不得分配给仅提供叶服务的组织，即使是多址的。
Verification of an organization's track record in providing Internet transit service must be verified by techniques such as traceroute, BGP advertisements, etc.
必须通过跟踪路由、BGP广告等技术验证组织在提供互联网交通服务方面的记录。
3) Payment of a registration fee to the Internet Assigned Numbers Authority (IANA). Registries may also charge some fee for services rendered, generally in relation to the cost of providing those services. All payment of registration and service fees must be made prior to the actual Sub-TLA ID and/or TLA ID assignment.
3) 向互联网分配号码管理局（IANA）支付注册费。登记处还可以对提供的服务收取一定的费用，通常与提供这些服务的成本有关。所有注册费和服务费必须在实际的子TLA ID和/或TLA ID分配之前支付。
4) Must provide registry services for the NLA ID address space it is responsible for under its Sub-TLA ID and/or TLA ID. This must include both sites and next level providers. The database of NLA assignments must be public and made available to the registries.
4) 必须为其子TLA ID和/或TLA ID下负责的NLA ID地址空间提供注册服务。这必须包括站点和下一级提供商。NLA分配数据库必须是公开的，并提供给登记处。
5) Periodically (interval set by registry) provide to registry utilization statistics of the Sub-TLA ID and/or TLA ID it has custody of. The organization must also show evidence of carrying TLA routing and transit traffic. This can be in the form of traffic statistics, traceroutes, routing table dumps, or similar means.
5) 定期（由注册表设置的间隔）向注册表提供其保管的子TLA ID和/或TLA ID的利用率统计信息。该组织还必须出示运输TLA路线和过境交通的证据。这可以是流量统计、跟踪路由、路由表转储或类似的方式。
6) Organizations requesting another Sub-TLA and/or TLA ID must show evidence to the registries that they have assigned more than 90% of the NLA ID space in their previous allocations.
6) 请求另一个子TLA和/或TLA ID的组织必须向注册中心提供证据，证明其在以前的分配中分配了超过90%的NLA ID空间。
Organizations which are given custody of a Sub-TLA ID and/or TLA ID, and fail to continue to meet all the above requirements may have the Sub-TLA ID and/or TLA ID custody revoked.
被授予子TLA ID和/或TLA ID保管权且未能继续满足上述所有要求的组织可能会撤销子TLA ID和/或TLA ID保管权。
Next-Level Aggregation ID's are used by organizations assigned a Sub-TLA ID and/or TLA ID to create an addressing hierarchy and to identify sites. The organization can assign the top part of the NLA ID in a manner to create an addressing hierarchy appropriate to its network.
分配了子TLA ID和/或TLA ID的组织使用下一级聚合ID创建寻址层次结构并标识站点。组织可以以创建适合其网络的寻址层次结构的方式分配NLA ID的顶部。
Registries may initially only assign a fraction of the NLA ID space for a particular Sub-TLA ID and/or TLA ID to the organization receiving the Sub-TLA ID and/or TLA ID assignment. When the organization has assigned more than 90% of the NLA ID space it may request additional NLA ID space in its Sub-TLA ID and/or TLA ID.
注册中心最初只能将特定子TLA ID和/或TLA ID的NLA ID空间的一小部分分配给接收子TLA ID和/或TLA ID分配的组织。当组织分配了超过90%的NLA ID空间时，它可以在其子TLA ID和/或TLA ID中请求额外的NLA ID空间。
Organizations assigned Sub-TLA ID and/or TLA ID's are required to assume (directly or indirectly) registry duties for the NLA ID's they assign. Each organization assigned a NLA ID is required to assume registry duties for the next level NLA ID's it assigns and follow
被分配次级TLA ID和/或TLA ID的组织必须（直接或间接）承担其分配的NLA ID的注册职责。每个分配了NLA ID的组织都必须承担其分配和遵循的下一级NLA ID的注册职责
Registry guidelines. This responsibility includes passing this information back to the registry that assigned the TLA and/or Sub-TLA. The TLA ID and/or Sub-TLA ID holder collects this information from the next level, the next level holder collects this information from the level below, etc.
登记册准则。此职责包括将此信息传递回分配TLA和/或子TLA的注册表。TLA ID和/或子TLA ID持有者从下一级收集此信息，下一级持有者从下一级收集此信息，等等。
The design of the bit layout of the NLA ID space for a specific Sub-TLA ID and/or TLA ID is left to the organization responsible for that Sub-TLA ID and/or TLA ID. Likewise the design of the bit layout of the next level NLA ID is the responsibility of the organization assigned the previous level NLA ID. It is recommended that organizations assigning NLA address space use "slow start" allocation procedures as is currently done with IPv4 CIDR blocks [CIDR].
特定子TLA ID和/或TLA ID的NLA ID空间的位布局设计由负责该子TLA ID和/或TLA ID的组织负责。同样，下一级NLA ID的位布局设计由分配前一级NLA ID的组织负责。建议各组织分配NLA地址空间使用“慢启动”分配过程，就像当前对IPv4 CIDR块[CIDR]所做的那样。
The design of an NLA ID allocation plan is a tradeoff between routing aggregation efficiency and flexibility. Creating hierarchies allows for greater amount of aggregation and results in smaller routing tables. Flat NLA ID assignment provides for easier allocation and attachment flexibility, but results in larger routing tables.
NLA ID分配计划的设计是路由聚合效率和灵活性之间的折衷。创建层次结构允许更大数量的聚合，并导致更小的路由表。平面NLA ID分配提供了更容易的分配和附件灵活性，但会导致更大的路由表。
The author would like to express his thanks to Thomas Narten, Steve Deering, Bob Fink, Matt Crawford, Rebecca Nitzan, Allison Mankin, Jim Bound, Christian Huitema, Scott Bradner, Brian Carpenter, John Stewart, Eric Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard, Mirjam Kuehne, Paula Caslav, David Conrad, and David Kessens for their review and constructive comments.
作者谨向托马斯·纳滕、史蒂夫·迪林、鲍勃·芬克、马特·克劳福德、丽贝卡·尼赞、艾莉森·曼金、吉姆·邦德、克里斯蒂安·惠特马、斯科特·布拉德纳、布赖恩·卡彭特、约翰·斯图尔特、埃里克·霍夫曼、乔恩·波斯特尔、丹尼尔·卡伦伯格、金·哈伯德、米贾姆·库恩、保拉·卡斯拉夫、大卫·康拉德、，感谢David Kessens的评论和建设性意见。
IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH]. Authentication of the ownership of prefixes to avoid "prefix stealing" is a related security issue but is beyond the scope of this document.
IPv6寻址文档对Internet基础设施安全没有任何直接影响。IPv6数据包的身份验证在[AUTH]中定义。验证前缀的所有权以避免“前缀窃取”是一个相关的安全问题，但超出了本文档的范围。
[AGGR] Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[AGGR]Hinden，R.，Deering，S.和M.O'Dell，“一种可聚合的全球单播地址格式”，RFC 2374，1998年7月。
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management", RFC 1881, December 1995.
[ALLOC]IAB和IESG，“IPv6地址分配管理”，RFC 18811995年12月。
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ARCH]Hinden，R.，“IP版本6寻址体系结构”，RFC 23731998年7月。
[AUTH] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 2402, November 1998.
[AUTH]Atkinson，R.和S.Kent，“IP认证头”，RFC 2402，1998年11月。
[CIDR] Fuller, V., Li, T., Varadhan, K. and J. Yu, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[CIDR]Fuller，V.，Li，T.，Varadhan，K.和J.Yu，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[Ethernet]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
[FDDI]Crawford，M.，“通过FDDI网络传输IPv6数据包”，RFC 2467，1998年12月。
[IPV6] Deering, S. and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]Deering，S.和R.Hinden，编辑，“互联网协议，第6版（IPV6）规范”，RFC 2460，1998年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Robert M. Hinden Nokia 232 Java Drive Sunnyvale, CA 94089 USA
Robert M.Hinden诺基亚232 Java Drive Sunnyvale，加利福尼亚州，美国94089
Phone: +1 408 990-2004
EMail: hinden@iprg.nokia.com
Phone: +1 408 990-2004
EMail: hinden@iprg.nokia.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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。