[要約] RFC 2374は、IPv6のアグリゲータブルなグローバルユニキャストアドレスのフォーマットに関する規格です。その目的は、IPv6アドレスの効率的な割り当てとルーティングを可能にするためのアドレスフォーマットを提供することです。
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.
Copyright（C）The Internet Society（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.
このドキュメントでは、インターネットで使用するIPv6集約可能グローバルユニキャストアドレス形式を定義しています。このドキュメントで定義されているアドレス形式は、IPv6プロトコル[IPV6]および「IPv6アドレス指定アーキテクチャ」[ARCH]に準拠しています。スケーラブルなインターネットルーティングを容易にするように設計されています。
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プロバイダーベースのユニキャストアドレス形式」に代わるものです。 RFC 2073は歴史的なものになるでしょう。集約可能グローバルユニキャストアドレス形式は、多くの分野でRFC 2073を改善したものです。主要な変更には、レジストリビットの削除が含まれているため、ルート集約、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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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ビットの識別子です。アドレスには、ユニキャスト、エニーキャスト、マルチキャストの3つのタイプがあります。このドキュメントでは、特定のタイプのユニキャストアドレスを定義します。
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ユニキャストアドレスは、インターネットルーティングシステムが任意のビット境界で「最長プレフィックス一致」アルゴリズムに基づいて転送を決定し、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集約可能グローバルユニキャストアドレス割り当てのアドレス形式を定義しています。著者は、このアドレス形式がインターネットに接続されたIPv6ノードに広く使用されると信じています。このアドレス形式は、現在のプロバイダーベースの集約と新しいタイプの交換ベースの集約の両方をサポートするように設計されています。この組み合わせにより、プロバイダーに直接接続するサイトと取引所に接続するサイトの効率的なルーティング集約が可能になります。サイトは、どちらのタイプの集約エンティティに接続するかを選択できます。
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.
このアドレス形式は、現在のプロバイダーベースの集約に加えて、交換ベースの集約をサポートするように設計されていますが、全体的なルート集約プロパティは交換に依存していません。プロバイダーベースの集約のみで効率的なルート集約を提供します。
Aggregatable addresses are organized into a three level hierarchy:
集約可能アドレスは、3つのレベルの階層に編成されています。
- 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 )
\___/ \___/ \___/
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 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.
上の図に示すように、集約可能なアドレス形式は、長距離プロバイダー（P1、P2、P3、およびP4として示される）、交換（X1およびX2として示される）、複数レベルのプロバイダー（P5およびP6）、およびサブスクライバー（Sxとして表示）の交換（現在のNAP、FIXなどとは異なります）は、IPv6アドレスを割り当てます。これらのエクスチェンジに接続する組織は、1つまたは複数の長距離プロバイダーからの長距離サービスに（直接、エクスチェンジを介して間接的に）サブスクライブします。そうすることで、長距離輸送プロバイダーからの独立への対応を実現します。彼らは、組織の番号を付け直すことなく、長距離プロバイダーを変更することができます。各長距離プロバイダーからのアドレスプレフィックスがなくても、エクスチェンジを介して複数の長距離プロバイダーへのマルチホーム化も可能です。このタイプのプロバイダーの選択と移植性に使用されるメカニズムについては、このドキュメントでは説明していません。
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 | |
+--+-----+---+--------+--------+--------------------------------+
<--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トップレベルの集約識別子RES将来の使用のために予約済みNLA ID次のレベルの集約識別子SLA IDサイトレベルの集約識別子INTERFACE 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.
このアドレス指定形式は、8,192（2 ^ 13）TLA IDをサポートします。追加のTLA IDは、TLAフィールドを右に予約フィールドに拡張するか、このフォーマットを追加のフォーマットプレフィックスに使用することによって追加できます。
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.
Reservedフィールドは将来の使用のために予約されており、ゼロに設定する必要があります。
The Reserved field allows for future growth of the TLA and NLA fields as appropriate. See section 4.0 for a discussion.
Reservedフィールドは、必要に応じて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:
Next-Level Aggregation Identifierは、TLA IDが割り当てられた組織がアドレス階層を作成し、サイトを識別するために使用されます。組織は、そのネットワークに適したアドレス階層を作成する方法で、NLA 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インターネットがネットワーク全体をサポートできるのとほぼ同じ数の組織にサービスを提供できます。
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 |
+-----+--------------------+--------+-----------------+
| 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 |
+-----+--------+--------+-----------------+
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フィールドは65,535の個別のサブネットをサポートします。
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識別子間に論理関係を作成しない）か、2つ以上のレベル階層を作成する（ルーティングテーブルを小さくする）かを選択できます。 SLA IDフィールド。後者は次のように表示されます。
| n | 16-n | 64 bits |
+-----+------------+-------------------------------------+
|SLA1 | 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.
このアドレス形式でサポートされるサブネットの数は、最大の組織を除くすべての組織に十分な数でなければなりません。追加のサブネットが必要な組織は、インターネットサービスを取得している組織と連携して、追加のサイト識別子を取得し、これを使用して追加のサブネットを作成できます。
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.
EUI-64ベースのインターフェイス識別子を作成する手順は、[ARCH]で定義されています。インターフェース識別子の形成の詳細は、「IPv6 over Ethernet」[ETHER]、「IPv6 over FDDI」[FDDI]などの適切な「IPv6 over <link>」仕様で定義されています。
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 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ビットです。これにより、8,192のTLA IDが可能になります。このサイズは、インターネットのトップレベルルーターのデフォルトのないルーティングテーブルが、現在のルーティングテクノロジーの制限内に、妥当なマージンで確実に維持されるように選択されました。デフォルトのないルーターは、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のデフォルトのないルーティングが、より複雑なインターネットとかなり大きなインターネットをサポートすることが重要です。
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のデフォルトのないルーティングテーブルには約50,000のプレフィックスが含まれていることに注意してください。これは、8,192を超えるルートをサポートできることを示していますが、IPv4で現在サポートされているプレフィックスの数が現在のルーティングテクノロジーに対してすでに多すぎる場合は、議論の余地があります。ルートの安定性の深刻な問題と、プロバイダーがすべての最上位プレフィックスをサポートしていない場合があります。技術的な要件は、IPv4で行われていたものよりも妥当なマージンで、以下のTLA IDサイズを選択することでした。
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ビットの選択は、エンジニアリング上の妥協でした。十分なトップレベルの組織をサポートしていなければ、ビットが少なすぎて小さすぎたでしょう。以前の段落で説明した問題に対処するために、現在のルーティングテクノロジーでは、より多くのビットが合理的に許容できる範囲を超えて、妥当なマージンをもっていたでしょう。
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識別子の数を増やす方法には2つの選択肢があります。 1つ目は、TLA IDフィールドを予約済みフィールドに拡張することです。これにより、TLA IDの数は約200万に増加します。 2番目の方法は、このアドレス形式で使用する別の形式プレフィックス（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.
Next-Level Aggregation Identifierフィールドのサイズは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.
これにより、フラットな方法で使用した場合、約1,600万の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ビットです。これは、サイトごとに65,535の個別のサブネットをサポートします。このフィールドのサイズの設計目標は、最大の組織を除くすべての組織にとって十分なものでした。追加のサブネットが必要な組織は、インターネットサービスを取得している組織と連携して、追加のサイト識別子を取得し、これを使用して追加のサブネットを作成できます。
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.
Interface ID Interface Identifierフィールドは64ビットです。このサイズは、EUI-64ベースのインターフェイス識別子をサポートするために[ARCH]で指定された要件を満たすために選択されました。
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.
著者は、レビューと建設的なコメントを提供してくれたThomas Narten、Bob Fink、Matt Crawford、Allison Mankin、Jim Bound、Christian Huitema、Scott Bradner、Brian Carpenter、John Stewart、Daniel Karrenbergに感謝の意を表します。
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management", RFC 1881, December 1995.
[ALLOC] IABおよびIESG、「IPv6アドレス割り当て管理」、RFC 1881、1995年12月。
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ARCH] Hinden、R。、「IP Version 6 Addressing Architecture」、RFC 2373、1998年7月。
[AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[AUTH] Atkinson、R。、「IP Authentication Header」、RFC 1826、1995年8月。
[AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996.
[AUTO] Thompson、S。、およびT. Narten。、「IPv6 Stateless Address Autoconfiguration」、RFC 1971、1996年8月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", Work in Progress.
[ETHER] Crawford、M。、「Ethernet network over IPv6 Packets over Ethernet Networks」、Work in Progress。
[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]クロフォード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アドレス指定ドキュメントは、インターネットインフラストラクチャのセキュリティに直接影響を与えません。 IPv6パケットの認証は[AUTH]で定義されています。
Robert M. Hinden Nokia 232 Java Drive Sunnyvale, CA 94089 USA
ロバート・M Hindon Nokia 232 Java Drive Sunnyvale、CA 94089彼
Phone: 1 408 990-2004 EMail: hinden@iprg.nokia.com
電話：1 408 990-2004メール：hinden@iprg.nokia.com
Mike O'Dell UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22030 USA
Mike O'Dell UUNET Technologies、Inc. 3060 Williams Drive Fairfax、VA 22030 USA
Phone: 1 703 206-5890 EMail: mo@uunet.uu.net
電話：1 703 206-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 West Tasman Drive San Jose、CA 95134-1706 USA
Phone: 1 408 527-8213 EMail: deering@cisco.com
電話：1 408 527-8213メール：deering@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。