Network Working Group R. Hinden
Request for Comments: 2374 Nokia
Obsoletes: 2073 M. O'Dell
Category: Standards Track UUNET
S. Deering
Cisco
July 1998
Network Working Group R. Hinden
Request for Comments: 2374 Nokia
Obsoletes: 2073 M. O'Dell
Category: Standards Track UUNET
S. Deering
Cisco
July 1998
An IPv6 Aggregatable Global Unicast Address Format
IPv6可聚合全局单播地址格式
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing Architecture" [ARCH]. It is designed to facilitate scalable Internet routing.
本文档定义了用于Internet的IPv6可聚合全局单播地址格式。本文档中定义的地址格式与IPv6协议[IPv6]和“IPv6寻址体系结构”[ARCH]一致。它旨在促进可扩展的Internet路由。
This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast Address Format". RFC 2073 will become historic. The Aggregatable Global Unicast Address Format is an improvement over RFC 2073 in a number of areas. The major changes include removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology.
本文档取代了RFC 2073，“一种基于IPv6提供商的单播地址格式”。RFC2073将成为历史。可聚合全局单播地址格式在许多方面都比RFC2073有所改进。主要更改包括删除注册表位，因为路由聚合不需要它们，支持基于EUI-64的接口标识符，支持基于提供程序和交换的聚合，分离公共和站点拓扑，以及新的基于聚合的术语。
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]中所述进行解释。
IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses: Unicast, Anycast, and Multicast. This document defines a specific type of Unicast address.
IPv6地址是接口和接口集的128位标识符。有三种类型的地址：单播、选播和多播。本文档定义了特定类型的单播地址。
In this document, fields in addresses are given specific names, for example "subnet". When this name is used with the term "ID" (for "identifier") after the name (e.g., "subnet ID"), it refers to the contents of the named field. When it is used with the term "prefix" (e.g. "subnet prefix") it refers to all of the addressing bits to the left of and including this field.
在本文档中，地址中的字段具有特定的名称，例如“子网”。当此名称与名称（例如，“子网ID”）后的术语“ID”（表示“标识符”）一起使用时，它指的是命名字段的内容。当它与术语“前缀”（例如“子网前缀”）一起使用时，它指的是该字段左侧的所有寻址位，包括该字段。
IPv6 unicast addresses are designed assuming that the Internet routing system makes forwarding decisions based on a "longest prefix match" algorithm on arbitrary bit boundaries and does not have any knowledge of the internal structure of IPv6 addresses. The structure in IPv6 addresses is for assignment and allocation. The only exception to this is the distinction made between unicast and multicast addresses.
IPv6单播地址的设计假设Internet路由系统根据任意位边界上的“最长前缀匹配”算法做出转发决策，并且不了解IPv6地址的内部结构。IPv6地址中的结构用于分配和分配。唯一的例外是单播和多播地址之间的区别。
The specific type of an IPv6 address is indicated by the leading bits in the address. The variable-length field comprising these leading bits is called the Format Prefix (FP).
IPv6地址的特定类型由地址中的前导位指示。包含这些前导位的可变长度字段称为格式前缀（FP）。
This document defines an address format for the 001 (binary) Format Prefix for Aggregatable Global Unicast addresses. The same address format could be used for other Format Prefixes, as long as these Format Prefixes also identify IPv6 unicast addresses. Only the "001" Format Prefix is defined here.
本文档为可聚合全局单播地址的001（二进制）格式前缀定义了地址格式。相同的地址格式可用于其他格式前缀，只要这些格式前缀还标识IPv6单播地址。此处仅定义“001”格式前缀。
This document defines an address format for the IPv6 aggregatable global unicast address assignment. The authors believe that this address format will be widely used for IPv6 nodes connected to the Internet. 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可聚合全局单播地址分配的地址格式。作者认为，这种地址格式将广泛用于连接到Internet的IPv6节点。此地址格式旨在支持当前基于提供程序的聚合和新类型的基于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 it's overall route aggregation properties. It will provide efficient route aggregation with only provider-based aggregation.
虽然此地址格式旨在支持基于exchange的聚合（除了当前基于提供程序的聚合之外），但其总体路由聚合属性并不依赖于exchange。它将仅通过基于提供商的聚合提供有效的路由聚合。
Aggregatable addresses are organized into a three level hierarchy:
可聚合地址被组织为三级层次结构：
- Public Topology - Site Topology - Interface Identifier
- 公共拓扑-站点拓扑-接口标识符
Public topology is the collection of providers and exchanges who provide public Internet transit services. Site topology is local to a specific site or organization which does not provide public transit service to nodes outside of the site. Interface identifiers identify interfaces on links.
公共拓扑是提供公共互联网传输服务的提供商和交换机的集合。站点拓扑是特定站点或组织的本地拓扑，该站点或组织不向站点外部的节点提供公共交通服务。接口标识符标识链接上的接口。
______________ ______________
--+/ \+--------------+/ \+----------
( P1 ) +----+ ( P3 ) +----+
+\______________/ | |----+\______________/+--| |--
| +--| X1 | +| X2 |
| ______________ / | |-+ ______________ / | |--
+/ \+ +-+--+ \ / \+ +----+
( P2 ) / \ +( P4 )
--+\______________/ / \ \______________/
| / \ | |
| / | | |
| / | | |
_|_ _/_ _|_ _|_ _|_
/ \ / \ / \ / \ / \
( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )
\___/ \___/ \___/ \___/ \___/
| / \
_|_ _/_ \ ___
/ \ / \ +-/ \
( S.D ) ( S.E ) ( S.F )
\___/ \___/ \___/
______________ ______________
--+/ \+--------------+/ \+----------
( P1 ) +----+ ( P3 ) +----+
+\______________/ | |----+\______________/+--| |--
| +--| X1 | +| X2 |
| ______________ / | |-+ ______________ / | |--
+/ \+ +-+--+ \ / \+ +----+
( P2 ) / \ +( P4 )
--+\______________/ / \ \______________/
| / \ | |
| / | | |
| / | | |
_|_ _/_ _|_ _|_ _|_
/ \ / \ / \ / \ / \
( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )
\___/ \___/ \___/ \___/ \___/
| / \
_|_ _/_ \ ___
/ \ / \ +-/ \
( S.D ) ( S.E ) ( S.F )
\___/ \___/ \___/
As shown in the figure above, the aggregatable address format is designed to support long-haul providers (shown as P1, P2, P3, and P4), exchanges (shown as X1 and X2), multiple levels of providers (shown at P5 and P6), and subscribers (shown as S.x) Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses. Organizations who connect to these exchanges will also subscribe (directly, indirectly via the exchange, etc.) for long-haul service from one or more long-haul providers. Doing so, they will achieve
如上图所示，可聚合地址格式旨在支持长途提供商（如P1、P2、P3和P4所示）、交换机（如X1和X2所示）、多级提供商（如P5和P6所示）和订户（如S.x所示），交换机（与当前NAP、补丁等不同）将分配IPv6地址。连接到这些交易所的组织还将（直接、间接地通过交易所等）从一个或多个长途提供商处订阅长途服务。这样做，他们将取得成功
addressing independence from long-haul transit providers. They will be able to change long-haul providers without having to renumber their organization. They can also be multihomed via the exchange to more than one long-haul provider without having to have address prefixes from each long-haul provider. Note that the mechanisms used for this type of provider selection and portability are not discussed in the document.
解决独立于长途运输提供商的问题。他们将能够更换长途服务提供商，而无需对其组织重新编号。它们还可以通过exchange多址连接到多个长途服务提供商，而不必使用每个长途服务提供商的地址前缀。请注意，文档中没有讨论用于这种类型的提供者选择和可移植性的机制。
The aggregatable global unicast address format is as follows:
可聚合全局单播地址格式如下：
| 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 following sections specify each part of the IPv6 Aggregatable Global Unicast address format.
以下各节指定IPv6可聚合全局单播地址格式的每个部分。
Top-Level Aggregation Identifiers (TLA ID) are the top level in the routing hierarchy. Default-free routers must have a routing table entry for every active TLA ID and will probably have additional entries providing routing information for the TLA ID in which they are located. They may have additional entries in order to optimize routing for their specific topology, but the routing topology at all levels must be designed to minimize the number of additional entries fed into the default free routing tables.
顶级聚合标识符（TLA ID）是路由层次结构中的顶级。默认自由路由器必须为每个活动TLA ID都有一个路由表条目，并且可能会有其他条目为它们所在的TLA ID提供路由信息。为了优化特定拓扑的路由，它们可能有额外的条目，但所有级别的路由拓扑都必须设计为最小化馈入默认空闲路由表的额外条目的数量。
This addressing format supports 8,192 (2^13) TLA ID's. Additional TLA ID's may be added by either growing the TLA field to the right into the reserved field or by using this format for additional format prefixes.
此寻址格式支持8192（2^13）TLA ID。可以通过将TLA字段向右扩展到保留字段或使用此格式作为其他格式前缀来添加其他TLA ID。
The issues relating to TLA ID assignment are beyond the scope of this document. They will be described in a document under preparation.
与TLA ID分配相关的问题超出了本文件的范围。它们将在正在编写的文件中加以说明。
The Reserved field is reserved for future use and must be set to zero.
保留字段保留供将来使用，必须设置为零。
The Reserved field allows for future growth of the TLA and NLA fields as appropriate. See section 4.0 for a discussion.
保留字段允许TLA和NLA字段的未来增长（视情况而定）。有关讨论，请参见第4.0节。
Next-Level Aggregation Identifier'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. It can use the remainder of the bits in the field to identify sites it wishes to serve. This is shown as follows:
分配了TLA ID的组织使用下一级聚合标识符来创建寻址层次结构和标识站点。组织可以以创建适合其网络的寻址层次结构的方式分配NLA ID的顶部。它可以使用字段中的剩余位来识别它希望服务的站点。具体情况如下：
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
Each organization assigned a TLA ID receives 24 bits of NLA ID space. This NLA ID space allows each organization to provide service to approximately as many organizations as the current IPv4 Internet can support total networks.
每个分配了TLA ID的组织接收24位NLA ID空间。此NLA ID空间允许每个组织向当前IPv4 Internet支持的整个网络所能支持的组织提供服务。
Organizations assigned TLA ID's may also support NLA ID's in their own Site ID space. This allows the organization assigned a TLA ID to provide service to organizations providing public transit service and to organizations who do not provide public transit service. These organizations receiving an NLA ID may also choose to use their Site ID space to support other NLA ID's. This is shown as follows:
分配TLA ID的组织也可以在其自己的站点ID空间中支持NLA ID。这允许分配TLA ID的组织向提供公共交通服务的组织和不提供公共交通服务的组织提供服务。这些接收NLA ID的组织也可以选择使用其站点ID空间来支持其他NLA ID。具体情况如下：
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
| m | 24-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+
|NLA2 | Site ID | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+
| m | 24-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+
|NLA2 | Site ID | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+
| o |24-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+
|NLA3 | Site ID| SLA ID | Interface ID |
+-----+--------+--------+-----------------+
| o |24-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+
|NLA3 | Site ID| SLA ID | Interface ID |
+-----+--------+--------+-----------------+
The design of the bit layout of the NLA ID space for a specific TLA ID is left to the organization responsible for that TLA ID. Likewise the design of the bit layout of the next level NLA ID is the responsibility of the previous level NLA ID. It is recommended that organizations assigning NLA address space use "slow start" allocation procedures similar to [RFC2050].
特定TLA ID的NLA ID空间的位布局设计由负责该TLA ID的组织负责。同样，下一级NLA ID的位布局设计由上一级NLA ID负责。建议分配NLA地址空间的组织使用“慢启动”分配程序类似于[RFC2050]。
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 SLA ID field is used by an individual organization to create its own local addressing hierarchy and to identify subnets. This is analogous to subnets in IPv4 except that each organization has a much greater number of subnets. The 16 bit SLA ID field support 65,535 individual subnets.
SLA ID字段由单个组织用于创建自己的本地寻址层次结构和标识子网。这与IPv4中的子网类似，只是每个组织都有更多的子网。16位SLA ID字段支持65535个单独的子网。
Organizations may choose to either route their SLA ID "flat" (e.g., not create any logical relationship between the SLA identifiers that results in larger routing tables), or to create a two or more level hierarchy (that results in smaller routing tables) in the SLA ID field. The latter is shown as follows:
组织可以选择将其SLA ID路由为“平面”（例如，不在SLA标识符之间创建任何逻辑关系，从而产生较大的路由表），或者在SLA ID字段中创建两级或两级以上的层次结构（从而产生较小的路由表）。后者如下所示：
| n | 16-n | 64 bits |
+-----+------------+-------------------------------------+
|SLA1 | Subnet | Interface ID |
+-----+------------+-------------------------------------+
| n | 16-n | 64 bits |
+-----+------------+-------------------------------------+
|SLA1 | Subnet | Interface ID |
+-----+------------+-------------------------------------+
| m |16-n-m | 64 bits |
+----+-------+-------------------------------------+
|SLA2|Subnet | Interface ID |
+----+-------+-------------------------------------+
| m |16-n-m | 64 bits |
+----+-------+-------------------------------------+
|SLA2|Subnet | Interface ID |
+----+-------+-------------------------------------+
The approach chosen for structuring an SLA ID field is the responsibility of the individual organization.
为构建SLA ID字段而选择的方法由单个组织负责。
The number of subnets supported in this address format should 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.
除最大的组织外，此地址格式支持的子网数量应足以满足所有组织的需要。需要额外子网的组织可以与他们从中获取Internet服务的组织进行安排，以获取额外的站点标识符，并使用此标识符创建额外的子网。
Interface identifiers are used to identify interfaces on a link. They are required to be unique on that link. They may also be unique over a broader scope. In many cases an interfaces identifier will be the same or be based on the interface's link-layer address. Interface IDs used in the aggregatable global unicast address format are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI-64]. These identifiers may have global scope when a global token (e.g., IEEE 48bit MAC) is available or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE EUI-64 terminology) in the EUI-64 identifier must be set correctly, as defined in [ARCH], to indicate global or local scope.
接口标识符用于标识链接上的接口。它们在该链接上必须是唯一的。在更广泛的范围内，它们也可能是独一无二的。在许多情况下，接口标识符将相同或基于接口的链路层地址。可聚合全局单播地址格式中使用的接口ID要求为64位长，并以IEEE EUI-64格式[EUI-64]构造。当全局令牌（例如，IEEE 48位MAC）可用时，这些标识符可能具有全局作用域，或者当全局令牌不可用时，这些标识符可能具有局部作用域（例如，串行链路、隧道端点等）。EUI-64标识符中的“u”位（IEEE EUI-64术语中的通用/本地位）必须按照[ARCH]中的定义正确设置，以指示全局或局部范围。
The procedures for creating EUI-64 based Interface Identifiers is defined in [ARCH]. The details on forming interface identifiers is defined in the appropriate "IPv6 over <link>" specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
[ARCH]中定义了创建基于EUI-64的接口标识符的过程。有关形成接口标识符的详细信息在适当的“IPv6 over<link>”规范中定义，如“IPv6 over Ethernet”[Ethernet]、“IPv6 over FDDI”[FDDI]等。
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. These are described in the following paragraphs.
可聚合地址格式中字段大小的设计选择基于满足若干技术要求的需要。下文将对这些问题进行说明。
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
顶级聚合标识符的大小为13位。这允许8192个TLA ID。选择此大小是为了确保Internet中顶级路由器中的默认空闲路由表为
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.
保持在当前路由技术的限制范围内，并留有合理的余量。余量很重要，因为无默认路由器也将携带大量更长（即更具体）的前缀，用于优化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. Current practice with IPv4 it is common to see a prefix announced fifteen times via different paths.
重要的问题不仅在于默认空闲路由表的大小，还在于拓扑的复杂性，它决定了路由器在计算转发表时必须检查的默认空闲路由副本的数量。IPv4的当前实践通常会看到前缀通过不同的路径发布15次。
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.
互联网拓扑结构的复杂性在未来很可能会增加。重要的是，IPv6无默认路由支持额外的复杂性以及相当大的internet。
It should be noted for comparison that at the time of this writing (spring, 1998) the IPv4 default-free routing table contains 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.
值得注意的是，在撰写本文时（1998年春季），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.
下一级聚合标识符字段的大小为24位。
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.
如果以平面方式使用，这允许大约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 authors would like to express our thanks to Thomas Narten, Bob Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg for their review and constructive comments.
作者要感谢托马斯·纳顿、鲍勃·芬克、马特·克劳福德、埃里森·曼金、吉姆·邦德、克里斯蒂安·惠特马、斯科特·布拉德纳、布赖恩·卡彭特、约翰·斯图尔特和丹尼尔·卡伦伯格的评论和建设性意见。
[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., "IP Authentication Header", RFC 1826, August 1995.
[AUTH]Atkinson，R.，“IP认证头”，RFC 1826，1995年8月。
[AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996.
[AUTO]Thompson，S.和T.Narten.，“IPv6无状态地址自动配置”，RFC 1971，1996年8月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", Work in Progress.
[ETHER]Crawford，M.，“通过以太网传输IPv6数据包”，正在进行中。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997.
[EUI64]IEEE，“64位全局标识符（EUI-64）注册机构指南”，http://standards.ieee.org/db/oui/tutorials/EUI64.html，1997年3月。
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", Work in Progress.
[FDDI]Crawford，M.，“通过FDDI网络传输IPv6数据包”，正在进行中。
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[IPV6]Deering，S.和R.Hinden，“互联网协议，第6版（IPV6）规范”，RFC 1883，1995年12月。
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 1466, November 1996.
[RFC2050]哈伯德，K.，科斯特斯，M.，康拉德，D.，卡伦伯格，D.，和J.波斯特尔，“互联网注册IP分配指南”，BCP 12，RFC 1466，1996年11月。
[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月。
IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH].
IPv6寻址文档对Internet基础设施安全没有任何直接影响。IPv6数据包的身份验证在[AUTH]中定义。
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
电话：1408 990-2004电子邮件：hinden@iprg.nokia.com
Mike O'Dell UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22030 USA
美国弗吉尼亚州费尔法克斯威廉姆斯大道3060号迈克·奥戴尔UUNET技术有限公司，邮编：22030
Phone: 1 703 206-5890 EMail: mo@uunet.uu.net
电话：1703206-5890电子邮件：mo@uunet.uu.net
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Stephen E.Deering Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: 1 408 527-8213 EMail: deering@cisco.com
电话：1408 527-8213电子邮件：deering@cisco.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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。