RFC2450 日本語訳
2450 Proposed TLA and NLA Assignment Rule. R. Hinden. December 1998. (Format: TXT=24486 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Hinden Request for Comments: 2450 Nokia Category: Informational December 1998
Hindenがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2450年のノキアカテゴリ: 情報の1998年12月
Proposed TLA and NLA Assignment Rules
提案されたTLAとNLA課題規則
Status of this Memo
この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)インターネット協会(1998)。 All rights reserved。
1.0 Introduction
1.0 序論
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.
このドキュメントはTop-レベルAggregation Identifiers(TLA ID)とNext-レベルAggregation Identifiers(NLA ID)のために[AGGR]で定義されるように規則を提案します。 これらの提案された規則は、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とRegistriesまで入力されるように意図します。 それはどんな公式のIETF状態にも意図しません。 内容はIPngワーキンググループと、IANAと、Registriesとの大規模な議論の結果を表します。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2.0 Scope
2.0 範囲
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課題規則は最初の2年間のIPv6 TLAアドレス課題のために意図します。 ルーティング技術が発展して、私たちが獲得するのに従って、IPv6アドレスに手順を割り当てる提案される追加経験は本書では変化するかもしれません。
Hinden Informational [Page 1] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[1ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
3.0 IPv6 Aggregatable Global Unicast Address Format
3.0 IPv6 Aggregatableのグローバルなユニキャストアドレス形式
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 Aggregatable Global Unicast Address Formatの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 | |
+--+-----+---+--------+--------+--------------------------------+
| 3| 13 | 8 | 24 | 16 | 64ビット| +--+-----+---+--------+--------+--------------------------------+ |fp| TLA|RES| NLA| SLA| インタフェース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 Format Prefix(001)TLA ID Top-レベルAggregation Identifier RES ReservedはNLA ID Next-レベルAggregation Identifier SLA ID Site-レベルAggregation Identifier INTERFACE ID Interface Identifierを使用します。
4.0 Technical Motivation
4.0 技術的な動機
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]からの技術的要求事項の抽出は以下の通りです:
Hinden Informational [Page 2] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[2ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
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.
Top平らなAggregation Identifierのサイズは13ビットです。 これは8,192TLA IDのものを考慮します。 このサイズはそれを保障するために選ばれて、インターネットのトップ平らなルータにおける無デフォルトの経路指定テーブルが限界の中に保たれます、現在のルーティング技術の手頃なマージンでことでした。 また、無デフォルトのルータがTLAとTLAsの間の内部の経路を最適化するために多くの、より長い(すなわち、より特定の)接頭語を運ぶので、マージンは重要です。
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デフォルトが解放する比較で経路指定テーブルがおよそ5万の接頭語であることが有名であるべきです。 これは、8,192より多くのルートを支えるのが可能であることを示しますが、現在のルーティング技術には、今日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ビットの選択は設計上の妥協でした。 より少ないビットが、十分な最高平らな組織を支持しないことによって、わずか過ぎたでしょう。 より多くのビットが前のパラグラフで説明された問題に対処するために手頃なマージンで現在のルーティング技術で合理的に設備することができることを超えていたでしょう。
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の数をかなり増加させます。
Hinden Informational [Page 3] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[3ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
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.
Reserved分野のサイズは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-レベルAggregation Identifier分野のサイズは24ビットです。 平坦な方法で使用されるなら、これはおよそ1600万NLA IDのものを考慮します。 階層的で使用されて、それはおよそIPv4アドレス空間に同等な複雑さを考慮します(254のインタフェースの平均したネットワークの規模を仮定して)。 コネであるなら、複雑さの将来の追加部屋がNLA IDで必要であり、これは、Reserved分野に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.
Site-レベルAggregation Identifier分野のサイズは16ビットです。 これは1サイトあたりの個々のサブネットに6万5535を支持します。 この分野のサイズのデザイン目標は最も大きい組織以外のすべてに十分であることでした。 追加サブネットを必要とする組織はそれらが追加サイト識別子を得て、追加サブネットを作成するのにこれを使用するためにインターネットのサービスを得ている組織と共に手配されることができます。
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ビット)であることを強制するためにSite-レベルAggregation Identifier分野に固定サイズを与えました。 これはトポロジー(例えば、サービスプロバイダーとマルチホーミングを複数のサービスプロバイダーに変える)でのサイトの動きを容易にします。
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のベースのInterface Identifiersを支持するために[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に最高平らな接頭語を持つのに多くの選択肢を持っています。
Hinden Informational [Page 4] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[4ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
- 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のものが割り当てられた組織はすべての課題をpublicallyに利用可能にしなければなりません。 登録が課題に関する的確な情報を持って、トラブルシューティングインターネット問題を可能にするのにこれが必要です。
- 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]のアドレス形式と一致した接頭語の配分。 明確に48ビットよりSLAとInterface Identifier分野に侵害しないくらいには長くない配分接頭語。 これは、トポロジー(例えば、サービスプロバイダーとマルチホーミングを複数のサービスプロバイダーに変える)でのサイトの動きを容易にするためのものです。
5.0 Proposed Rules for Assignment of Top-Level Aggregation ID's
5.0 トップレベルのIDの集合ものの課題のための提案された規則
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]で定義されるように適切な実体としてのインターネットAssigned民数記Authority(IANA)にはIPv6アドレス空間の管理への責任があるのを認可しました。
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がわずかなブロックを割り当てる、(例えば、数100) 登録へのTLA IDについて。 登録はTLA ID課題のために条件を満たす組織にTLA IDのものを配属するでしょう。 登録がそれらのTLA IDのもののすべてを割り当てたとき、それらは、IANAが別のブロックをそれらに与えるよう要求できます。 ブロックは隣接である必要はありません。 また、IANAは直接TLA IDのものを組織に配属するかもしれません。 これはテストするための一時的なTLA課題と6boneなどの活動のための実験用法か交換のような新しいアプローチを含んでいます。
Hinden Informational [Page 5] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[5ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
5.1 Proposed TLA Allocation Stages
5.1 提案されたTLA配分ステージ
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.
2つの段階でTLA配分をするでしょう。 第一段階はSub-TLA IDを割り当てることです。 受取人が、彼らがNLA 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 ID0x0001から割り当てられます。 Sub-TLA分野を作成するReserved分野の使用がTLA ID0x0001に特定であることに注意してください。 それはいかなる他のTLAにも影響しません。
| 3 | 13 | 13 | 19 |
+----+----------+---------+---------------+
| FP | TLA | Sub-TLA | NLA |
| | ID | | ID |
+----+----------+---------+---------------+
| 3 | 13 | 13 | 19 | +----+----------+---------+---------------+ | fp| TLA| サブTLA| NLA| | | ID| | ID| +----+----------+---------+---------------+
where:
どこ:
FP = 001 = Format Prefix
fpは001=形式接頭語と等しいです。
This is the Format Prefix used to identify aggregatable global
unicast addresses.
これは「集合-可能」グローバルなユニキャストアドレスを特定するのに使用されるFormat Prefixです。
TLA ID = 0x0001 = Top-Level Aggregation Identifier
TLA IDは0×0001=トップレベル集合識別子と等しいです。
This is the TLA ID assigned by the IANA for Sub-TLA allocation.
これはSub-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
Sub-TLA ID分野は初期の配分に登録によってこのドキュメントのセクション5.2で条件を満たす組織に使用されます。 IANAがわずかなブロックを割り当てる、(例えば、数100) Sub-TLAには、登録にはIDがあります。 登録はセクション5.2で指定された必要条件を満たす組織にSub-TLA IDのものを配属するでしょう。 登録がそれらのIDのSub-TLAもののすべてを割り当てたとき、それらは、IANAが別のブロックをそれらに与えるよう要求できます。 ブロックは隣接である必要はありません。 The
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は直接組織へのIDのものをSub-TLAに割り当てるかもしれません。 これはテストするための一時的なTLA課題と6boneなどの活動のための実験用法か交換のような新しいアプローチを含んでいます。
Hinden Informational [Page 6] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[6ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
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のAggregationものは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.
Sub-TLAを受ける組織がIPv6インターネットトランジットサービスの証拠を示すことができるまで、サブTLA配分は当座です。 配分の日付から3カ月でトランジットサービスを示すことができないと、Sub-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かRegistriesが初めは、特定のTLA IDのためにTLA ID課題を受け取る組織にNLA IDスペースの部分を配属するだけであるかもしれません。 組織がNLA IDスペースの90%以上を割り当てたとき、それはTLA IDの追加NLA IDスペースを要求するかもしれません。
5.2 Proposed Assignment Requirements
5.2 提案された課題要件
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とRegistriesまで入力されるように意図します。 それはどんな公式のIETF状態にも意図しません。
Registries enforce the following requirements for organizations assigned Sub-TLA and TLA ID's:
登録はSub-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」[ETHER]、「FDDIの上のIPv6」[FDDI]などの適切な「<リンク>の上のIPv6」仕様に基づき定義されるようにサービスをIPv6に供給すると定義されます、組織の境界のリンクに。 これは、Neighborディスカバリー(適宜)を走らせて、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のものを配属してはいけません。
Hinden Informational [Page 7] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[7ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
Verification of an organization's track record in providing
Internet transit service must be verified by techniques such as
traceroute, BGP advertisements, etc.
トレースルートなどのテクニック、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) インターネットAssigned民数記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) 定期的に、(登録によって設定された間隔)はそれが防護するSub-TLA ID、そして/または、TLA IDの登録利用統計に提供されます。 また、組織はTLAルーティングとトランジット交通を運ぶという証拠を示していなければなりません。 これは交通統計、トレースルート、経路指定テーブル憂鬱、または同様の手段の形にあることができます。
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) 別のSub-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.
Sub-TLA ID、そして/または、TLA IDの保護を与えて、Sub-TLA IDを持っていたかもしれなくて、TLA ID保護が取り消されたというすべての上記の必要条件を満たし続けていない組織。
6.0 Proposed Rules Assignment of Next-Level Aggregation ID's
6.0 次のレベルの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のAggregationものはSub-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.
登録は初めは、特定のSub-TLA ID、そして/または、TLA IDのためにSub-TLA ID、そして/または、TLA ID課題を受け取る組織にNLA IDスペースの部分を配属するだけであるかもしれません。 組織がNLA IDスペースの90%以上を割り当てたとき、それはSub-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
Sub-TLA ID、そして/または、TLA IDのものが割り当てられた組織はそれらが割り当てるNLA IDのもののために登録義務を引き受けなければなりません(直接か間接的に)。 NLA IDが割り当てられた各組織が、それが割り当てる平らなNLA IDの次のもののために登録義務を引き受けて、続くのに必要です。
Hinden Informational [Page 8] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[8ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
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.
登録ガイドライン。 この責任は、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].
特定のSub-TLA ID、そして/または、TLA IDのためのNLA IDスペースの噛み付いているレイアウトのデザインはそのSub-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課題は、より簡単な配分と付属の柔軟性に備えますが、より大きい経路指定テーブルをもたらします。
7.0 Acknowledgments
7.0 承認
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.
作者は彼らのレビューと建設的なコメントのためにトーマスNarten、スティーブ・デアリング、ボブFink、マット・クロフォード、レベッカNitzan、アリソン・マンキン、ジムBound、クリスチャンのHuitema、スコット・ブラドナー、ブライアンCarpenter、ジョン・スチュワート、エリック・ホフマン、ジョン・ポステル、ダニエルKarrenberg、キム・ハバード、ミリアムKuehne、ポーラCaslav、デヴィッド・コンラッド、およびデヴィッドKessensに感謝したがっています。
8.0 Security Considerations
8.0 セキュリティ問題
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]で定義されます。 「接頭語窃盗」を避ける接頭語の所有権の認証は、関連する安全保障問題ですが、このドキュメントの範囲を超えています。
9.0 References
9.0の参照箇所
[AGGR] Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable
Global Unicast Address Format", RFC 2374, July 1998.
[AGGR] HindenとR.とデアリングとS.とM.オデル、「Aggregatableのグローバルなユニキャストアドレス形式」、RFC2374、1998年7月。
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management", RFC
1881, December 1995.
[ALLOC] IABとIESG、「IPv6アドレス配分管理」、RFC1881、1995年12月。
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture", RFC
2373, July 1998.
[アーチ]Hinden、R.、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
Hinden Informational [Page 9] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[9ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
[AUTH] Atkinson, R. and S. Kent, "IP Authentication Header", RFC
2402, November 1998.
[AUTH] アトキンソンとR.とS.ケント、「IP認証ヘッダー」、RFC2402、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] フラーとV.と李とT.とVaradhanとK.とJ.ユー、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[エーテル] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC 2467, December 1998.
[FDDI] クロフォード、M.、「FDDIネットワークの上のIPv6パケットのトランスミッション」、RFC2467、1998年12月。
[IPV6] Deering, S. and R. Hinden, Editors, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6] デアリング、S.とR.Hinden、エディターズ、「インターネットプロトコル、バージョン6(IPv6)仕様」RFC2460、12月1998日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10.0 Author's Address
10.0 作者のアドレス
Robert M. Hinden Nokia 232 Java Drive Sunnyvale, CA 94089 USA
ロバートM.Hindenノキア232Java Driveカリフォルニア94089サニーベル(米国)
Phone: +1 408 990-2004 EMail: hinden@iprg.nokia.com
以下に電話をしてください。 +1 408 990-2004 メールしてください: hinden@iprg.nokia.com
Hinden Informational [Page 10] RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
Hinden情報[10ページ]のRFC2450は1998年12月にTLAとNLA課題規則を提案しました。
11.0 Full Copyright Statement
11.0 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Hinden Informational [Page 11]
Hinden情報です。[11ページ]
一覧
スポンサーリンク
