[要約] RFC 2450は、略語（TLA）と名前空間ラベル（NLA）の割り当てルールに関する提案です。このRFCの目的は、略語と名前空間ラベルの一貫性と効率性を向上させることです。
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.
Copyright（C）The Internet Society（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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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アドレス割り当ての最初の2年間を対象としています。ルーティングテクノロジーが進化し、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フィールドの割り当てルールを提案しています。このアドレス形式は、現在のプロバイダーベースの集約と新しいタイプの交換ベースの集約の両方をサポートするように設計されています。この組み合わせにより、プロバイダーに直接接続するサイトと取引所に接続するサイトの効率的なルーティング集約が可能になります。サイトは、どちらのタイプの集約エンティティに接続するかを選択できます。
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.
このアドレス形式は、（現在のプロバイダーベースの集約に加えて）交換ベースの集約をサポートするように設計されていますが、ルート集約プロパティ全体の交換に依存していません。プロバイダーベースの集約のみで効率的なルート集約を提供します。
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 | |
+--+-----+---+--------+--------+--------------------------------+
<--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 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ビットです。これにより、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. 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のデフォルトのないルーティングが、より複雑なインターネットとかなり大きなインターネットをサポートすることが重要です。
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デフォルトフリールーティングテーブルは約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. 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.
Next-Level Aggregation Identifierフィールドのサイズは24ビットです。これにより、フラットな方法で使用した場合、約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 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.
- インターネットの最上位プレフィックスの数を扱いやすいサイズに制限します。これは、インターネットの最上位ルーターにあるデフォルトのないルーティングテーブルが、現在のルーティングテクノロジの制限内に、妥当なマージンをもって保たれるようにするために重要です。
- 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.
- 最上位のプレフィックスは、割り当てから3か月以内に運用可能な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]のアドレス形式と一致するプレフィックスの割り当て。具体的には、SLAおよびInterface Identifierフィールドを侵害しないように、48ビット以下の割り当てプレフィックス。これは、トポロジ内のサイトの移動を容易にするためです（サービスプロバイダーの変更、複数のサービスプロバイダーへのマルチホーミングなど）。
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は、[ALLOC]で定義されているIPv6アドレス空間の管理を担当する適切なエンティティとして、Internet Assigned Numbers Authority（IANA）を承認しています。
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や交換などの新しいアプローチなどのアクティビティの実験的な使用が含まれます。
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の割り当ては2つの段階で行われます。最初の段階は、サブTLA IDを割り当てることです。受信者がNTL IDの90％以上をSub-TLA IDに割り当てたことを実証すると、TLA IDが割り当てられます。 Sub-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 |
+----+----------+---------+---------------+
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.
これは、サブTLA割り当てのためにIANAによって割り当てられた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
サブTLA IDフィールドは、このドキュメントのセクション5.2の要件を満たす組織への初期割り当てのためにレジストリによって使用されます。 IANAは、サブTLA IDの小さなブロック（数百など）をレジストリに割り当てます。レジストリは、サブTLA IDをセクション5.2で指定された要件を満たす組織に割り当てます。レジストリがすべてのサブ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や交換などの新しいアプローチなどのアクティビティの実験的な使用が含まれます。
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.
次レベルの集約IDは、TLA 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を受け取る組織がIPv6インターネットトランジットサービスの証拠を示すことができるまで、サブTLAの割り当ては暫定的です。トランジットサービスが割り当ての日から3か月までに提示できない場合、サブ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のNLA IDスペースの一部のみを、TLA ID割り当てを受信する組織に割り当てることができます。組織がNLA IDスペースの90％以上を割り当てている場合、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 Ethernet」[ETHER]、「IPv6 over FDDI」[FDDI]など、適切な「IPv6 over <link>」仕様で定義されているIPv6サービスを、組織の境界。これには、近隣探索（必要に応じて）の実行と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.
インターネットトランジットサービスの提供における組織の実績の検証は、traceroute、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）Internet Assigned Numbers Authority（IANA）への登録料の支払い。レジストリは、一般にそれらのサービスを提供するコストに関連して、提供されたサービスにいくらかの料金を請求する場合もあります。登録料およびサービス料のすべての支払いは、実際のSub-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）Sub-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ルーティングとトランジットトラフィックを運ぶ証拠を示す必要があります。これは、トラフィック統計、traceroute、ルーティングテーブルダンプ、または同様の手段の形を取ることができます。
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、あるいはその両方を要求する組織は、以前の割り当てでNLA IDスペースの90％以上を割り当てたという証拠をレジストリに示す必要があります。
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.
次のレベルの集約IDは、サブTLA IDまたはTLA 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の割り当てを受信する組織に割り当てることができます。組織がNLA IDスペースの90％以上を割り当てている場合、サブ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 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.
Sub-TLA IDやTLA IDを割り当てられた組織は、割り当てられたNLA IDに対して（直接的または間接的に）レジストリの義務を負う必要があります。 NLA IDを割り当てられた各組織は、それが割り当てる次のレベルのNLA IDのレジストリ義務を引き受け、レジストリガイドラインに従う必要があります。この責任には、TLAやSub-TLAを割り当てたレジストリにこの情報を戻すことが含まれます。 TLA IDまたはSub-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.
著者は、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、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アドレス指定ドキュメントは、インターネットインフラストラクチャのセキュリティに直接影響を与えません。 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 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. and S. Kent, "IP Authentication Header", RFC 2402, November 1998.
[AUTH] Atkinson、R。およびS. Kent、「IP Authentication Header」、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、「Classless Inter-Domain Routing（CIDR）：a Address Assignment and Aggregation Strategy」、RFC 1519、1993年9月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[ETHER] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、1998年12月。
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
[FDDI] Crawford、M。、「Transmission of IPv6 Packets over FDDI Networks」、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
ロバート・M Hindon Nokia 232 Java Drive Sunnyvale、CA 94089彼
Phone: +1 408 990-2004
EMail: hinden@iprg.nokia.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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。