Network Working Group R. Hinden
Request for Comments: 3587 Nokia
Obsoletes: 2374 S. Deering
Category: Informational Cisco
E. Nordmark
Sun
August 2003
Network Working Group R. Hinden
Request for Comments: 3587 Nokia
Obsoletes: 2374 S. Deering
Category: Informational Cisco
E. Nordmark
Sun
August 2003
IPv6 Global Unicast Address Format
IPv6全局单播地址格式
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic.
本文档淘汰了RFC 2374，“一种IPv6可聚合全局单播地址格式”。它定义了一个IPv6地址分配结构，其中包括顶级聚合器（TLA）和下一级聚合器（NLA）。本文件使RFC 2374和TLA/NLA结构具有历史意义。
RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format", defined an IPv6 address allocation structure that includes TLA and NLA. This document replaces RFC 2374, and makes RFC 2374 and the TLA/NLA structure historic.
RFC 2374，“一种IPv6可聚合全局单播地址格式”，定义了一种包含TLA和NLA的IPv6地址分配结构。本文件取代RFC 2374，使RFC 2374和TLA/NLA结构具有历史意义。
The TLA/NLA scheme has been replaced by a coordinated allocation policy defined by the Regional Internet Registries (RIRs) [IPV6RIR].
TLA/NLA计划已被区域互联网注册中心（RIR）[IPV6RIR]定义的协调分配政策所取代。
Part of the motivation for obsoleting the TLA/NLA structure is technical; for instance, there is concern that TLA/NLA is not the technically best approach at this stage of the deployment of IPv6. Moreover, the allocation of IPv6 addresses is related to policy and to the stewardship of the IP address space and routing table size, which the RIRs have been managing for IPv4. It is likely that the RIRs' policy will evolve as IPv6 deployment proceeds.
废除TLA/NLA结构的部分动机是技术性的；例如，有人担心TLA/NLA在IPv6部署的现阶段不是技术上最好的方法。此外，IPv6地址的分配与策略、IP地址空间和路由表大小的管理有关，RIR一直在为IPv4管理这些内容。RIRs的政策很可能会随着IPv6部署的进展而演变。
The IETF has provided technical input to the RIRs (for example, [RFC3177]), which the RIRs have taken into account when defining their address allocation policy.
IETF向RIR提供了技术输入（例如，[RFC3177]），RIR在定义其地址分配策略时考虑了这些输入。
RFC 2374 was the definition of addresses for Format Prefix 001 (2000::/3) which is formally made historic by this document. Even though currently only 2000::/3 is being delegated by the IANA, implementations should not make any assumptions about 2000::/3 being special. In the future, the IANA might be directed to delegate currently unassigned portions of the IPv6 address space for the purpose of Global Unicast as well.
RFC 2374是格式前缀001（2000:：/3）的地址定义，本文件正式将其历史化。尽管目前IANA仅授权2000:：/3，但实施不应假设2000:：/3是特殊的。将来，IANA可能会被指示将IPv6地址空间中当前未分配的部分委派给其他用户，以实现全局单播。
The Subnet Local Aggregator (SLA) field in RFC 2374 remains in function but with a different name in [ARCH]. Its new name is "subnet ID".
RFC 2374中的子网本地聚合器（SLA）字段仍然有效，但在[ARCH]中使用了不同的名称。它的新名称是“子网ID”。
The general format for IPv6 global unicast addresses as defined in "IP Version 6 Addressing Architecture" [ARCH] is as follows:
“IP版本6寻址体系结构”[ARCH]中定义的IPv6全局单播地址的一般格式如下：
| n bits | m bits | 128-n-m bits |
+-------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+-------------------------+-----------+----------------------------+
| n bits | m bits | 128-n-m bits |
+-------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+-------------------------+-----------+----------------------------+
where the global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnets/links), the subnet ID is an identifier of a subnet within the site, and the interface ID is as defined in section 2.5.1 of [ARCH]. The global routing prefix is designed to be structured hierarchically by the RIRs and ISPs. The subnet field is designed to be structured hierarchically by site administrators.
如果全局路由前缀是分配给站点（子网/链路集群）的值（通常为分层结构），则子网ID是站点内子网的标识符，接口ID如[ARCH]第2.5.1节所定义。全局路由前缀由RIR和ISP分层设计。子网字段按站点管理员的层次结构设计。
[ARCH] also requires that all unicast addresses, except those that start with binary value 000, have Interface IDs that are 64 bits long and to be constructed in Modified EUI-64 format. The format of global unicast address in this case is:
[ARCH]还要求所有单播地址（以二进制值000开头的地址除外）具有64位长的接口ID，并以修改后的EUI-64格式构造。在这种情况下，全局单播地址的格式为：
| n bits | 64-n bits | 64 bits |
+-------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+-------------------------+-----------+----------------------------+
| n bits | 64-n bits | 64 bits |
+-------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+-------------------------+-----------+----------------------------+
where the routing prefix is a value assigned to identify a site (a cluster of subnets/links), the subnet ID is an identifier of a subnet within the site, and the interface ID is a modified EUI-64 format as defined in [ARCH].
其中，路由前缀是为标识站点（子网/链路集群）而分配的值，子网ID是站点内子网的标识符，接口ID是[ARCH]中定义的修改过的EUI-64格式。
An example of the resulting format of global unicast address under the 2000::/3 prefix that is currently being delegated by the IANA and consistent with the recommendations in RFC 3177 is:
2000:：/3前缀下的全球单播地址的结果格式示例，目前由IANA授权，并符合RFC 3177中的建议：
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+----------------------------+
|001|global routing prefix| subnet ID | interface ID |
+---+---------------------+-----------+----------------------------+
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+----------------------------+
|001|global routing prefix| subnet ID | interface ID |
+---+---------------------+-----------+----------------------------+
The authors would like to express our thanks to Alain Durand, Brian Carpenter, Fred Templin, Julian Sellers, Jun-ichiro Itojun Hagino, Margaret Wasserman, Michel Py, Pekka Savola, Tatuya Jinmei, and Thomas Narten for their review and constructive comments.
作者要感谢Alain Durand、Brian Carpenter、Fred Templin、Julian Sellers、Jun ichiro Itojun Hagino、Margaret Wasserman、Michel Py、Pekka Savola、Tatuya Jinmei和Thomas Narten的评论和建设性意见。
[ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 3513, April 2003.
[ARCH]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 3513，2003年4月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]Deering，S.和R.Hinden，“互联网协议，第6版（IPV6）规范”，RFC 2460，1998年12月。
[IPV6RIR] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment Policy", Document ID: ripe-267, http://www.ripe.net/ripe/docs/ipv6policy.html, January 22, 2003.
[IPV6RIR]APNIC，ARIN，RIME NCC，“IPv6地址分配和分配策略”，文件ID:RIME-267，http://www.ripe.net/ripe/docs/ipv6policy.html，二○○三年一月二十二日。
[RFC3177] IAB/IESG, "Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177]IAB/IESG，“关于向站点分配IPv6地址的建议”，RFC3177，2001年9月。
IPv6 addressing documents do not have any direct impact on Internet infrastructure security.
IPv6寻址文档对Internet基础设施安全没有任何直接影响。
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA USA
Robert M.Hinden诺基亚313飞兆半导体山景大道，加利福尼亚州
EMail: bob.hinden@nokia.com
EMail: bob.hinden@nokia.com
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
Erik Nordmark Sun Microsystems Laboratories 180, avenue de l'Europe 38334 SAINT ISMIER Cedex France
Erik Nordmark Sun Microsystems Laboratories 180，欧洲大道38334号法国圣伊斯梅尔塞德克斯
EMail: erik.nordmark@sun.com
EMail: erik.nordmark@sun.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。