IPv6グローバルユニキャストアドレス形式
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
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.
Copyright（C）The Internet Society（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 Aggregatable Global Unicast Address Format」を廃止します。 トップレベルアグリゲーター（TLA）および次レベルアグリゲーター（NLA）を含むIPv6アドレス割り当て構造を定義しました。 このドキュメントは、RFC 2374とTLA / NLA構造を歴史的なものにします。
1. Introduction
1.はじめに
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「An IPv6 Aggregatable Global Unicast Address Format」では、TLAとNLAを含むIPv6アドレス割り当て構造が定義されています。 このドキュメントはRFC 2374を置き換え、RFC 2374とTLA / NLA構造を歴史的なものにします。
2. TLA/NLA Made Historic
2. 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構造を廃止する動機の一部は技術的です。 たとえば、IPv6の展開のこの段階では、TLA / NLAが技術的に最良のアプローチではないという懸念があります。 さらに、IPv6アドレスの割り当ては、ポリシー、およびRIRがIPv4に対して管理してきたIPアドレス空間とルーティングテーブルサイズの管理に関連しています。 IPv6の展開が進むにつれて、RIRのポリシーが進化する可能性があります。
Hinden, et al. Informational [Page 1] RFC 3587 IPv6 Global Unicast Address Format August 2003 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はFormat Prefix 001（2000 :: / 3）のアドレスの定義であり、このドキュメントによって正式に歴史的にされています。 現在、2000 :: / 3だけがIANAによって委任されていますが、実装では、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」です。
3. Address Format
3.アドレス形式
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 |
+-------------------------+-----------+----------------------------+
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はセクション2.5で定義されています。 [ARCH]の.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があり、Modified EUI-64形式で構築する必要があります。 この場合のグローバルユニキャストアドレスの形式は次のとおりです。
| n bits | 64-n bits | 64 bits |
+-------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+-------------------------+-----------+----------------------------+
Hinden, et al. Informational [Page 2]
RFC 3587 IPv6 Global Unicast Address Format August 2003
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:
現在IANAによって委任されており、RFC 3177の推奨事項と一致する、2000 :: / 3プレフィックスでのグローバルユニキャストアドレスの結果の形式の例は次のとおりです。
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+----------------------------+
|001|global routing prefix| subnet ID | interface ID |
+---+---------------------+-----------+----------------------------+
4. Acknowledgments
4.謝辞
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、Itojun Jun Itojun Hagino、Margaret Wasserman、Michel Py、Pekka Savola、Tatuya Jinmei、およびThomas Nartenに感謝の意を表します。
5. References
5.リファレンス
5.1. Normative References
5.1。 規範的な参考文献
[ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003.
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
5.2. Informative References
5.2。 参考情報
[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.
[RFC3177] IAB/IESG, "Recommendations on IPv6 Address Allocations to
Sites", RFC 3177, September 2001.
6. Security Considerations
6.セキュリティに関する考慮事項
IPv6 addressing documents do not have any direct impact on Internet infrastructure security.
IPv6アドレス指定ドキュメントは、インターネットインフラストラクチャのセキュリティに直接影響を与えません。
Hinden, et al. Informational [Page 3] RFC 3587 IPv6 Global Unicast Address Format August 2003 7. Authors' Addresses
7.著者のアドレス
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA USA EMail: bob.hinden@nokia.com Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Erik Nordmark Sun Microsystems Laboratories 180, avenue de l'Europe 38334 SAINT ISMIER Cedex France EMail: erik.nordmark@sun.com Hinden, et al. Informational [Page 4] RFC 3587 IPv6 Global Unicast Address Format August 2003 8. Full Copyright Statement
8.完全な著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved. 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. Hinden, et al. Informational [Page 5]