RFC2374 日本語訳
2374 An IPv6 Aggregatable Global Unicast Address Format. R. Hinden, M.O'Dell, S. Deering. July 1998. (Format: TXT=25068 bytes) (Obsoletes RFC2073) (Obsoleted by RFC3587) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Hinden
Request for Comments: 2374 Nokia
Obsoletes: 2073 M. O'Dell
Category: Standards Track UUNET
S. Deering
Cisco
July 1998
Hindenがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2374 ノキアは以下を時代遅れにします。 2073年のM.オデルカテゴリ: 標準化過程UUNET S.デアリングシスコ1998年7月
An IPv6 Aggregatable Global Unicast Address Format
IPv6 Aggregatableのグローバルなユニキャストアドレス形式
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
1.0 Introduction
1.0 序論
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 aggregatableのグローバルなユニキャストアドレス形式を定義します。 本書では定義されたアドレス形式は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.
RFC2073、「IPv6のプロバイダーベースのユニキャストアドレス形式」を記録されたこれは取り替えます。 RFC2073は歴史的になるでしょう。 Aggregatable Global Unicast Address Formatは多くの領域のRFC2073の上の改良です。 それらはルート集合に必要でないので、大きな変化は登録ビットの取り外しを含んでいます、そして、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Hinden, et. al. Standards Track [Page 1] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[1ページ]RFC2374IPv6
2.0 Overview of the IPv6 Address
2.0 IPv6アドレスの概要
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つのタイプのアドレスがあります: ユニキャスト、Anycast、およびマルチキャスト。 このドキュメントは特定のタイプのUnicastアドレスを定義します。
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アドレスの特定のタイプはアドレスで主なビットによって示されます。 これらの主なビットを包括する可変長の分野はFormat Prefix(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.
このドキュメントはAggregatable Global Unicastアドレスのための001の(2進)の形式Prefixのためにアドレス形式を定義します。 他のFormat Prefixesに同じアドレス形式を使用できました、また、これらのFormat PrefixesがIPv6ユニキャストアドレスを特定する限り。 「1インチの形式接頭語はここで定義されます」だけ
3.0 IPv6 Aggregatable Global Unicast Address Format
3.0 IPv6 Aggregatableのグローバルなユニキャストアドレス形式
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 aggregatableのグローバルなユニキャストアドレス課題のためにアドレス形式を定義します。 作者は、このアドレス形式がインターネットに接続されたIPv6ノードに広く使用されると信じています。 このアドレス形式は、両方が現在のプロバイダーベースの集合と新しいタイプの交換ベースの集合であるとサポートするように設計されています。 組み合わせは直接プロバイダーに接続するサイトと交換に接続するサイトのための効率的なルーティング集合を許容するでしょう。 サイトには、どちらかのタイプの集合実体に関連づける選択があるでしょう。
Hinden, et. al. Standards Track [Page 2] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[2ページ]RFC2374IPv6
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:
Aggregatableアドレスは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 )
\___/ \___/ \___/
______________ ______________ --+/ \+--------------+/ \+---------- (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
図に上に、「集合-可能」アドレス形式が長期プロバイダー(P1、P2、P3、およびP4として、目立つ)をサポートするように設計されているのが示されるように、交換(X1とX2として、目立つ)、複数のレベルのプロバイダー(P5とP6によって、目立つ)、および加入者(S.xとして、目立ちます)交換(現在のNAPs、FIXesなどと異なった)はアドレスをIPv6に割り当てるでしょう。 また、これらの交換に接続する組織は長期サービスのために1つ以上の長期プロバイダーから申し込まれるでしょう(直接と、間接的に交換などで)。 したがって、彼らが達成する
Hinden, et. al. Standards Track [Page 3] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[3ページ]RFC2374IPv6
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.
長期トランジットプロバイダーから独立を扱います。 彼らの組織に番号を付け替えさせる必要はなくて、彼らは長期プロバイダーを変えることができるでしょう。 また、それらは1つの長期プロバイダーよりそれぞれの長期プロバイダーからのアドレス接頭語を持つ必要はなくて以上への交換で「マルチ-家へ帰」ることができます。 ドキュメントでこのタイプのプロバイダー選択と移植性に使用されるメカニズムについて議論しないことに注意してください。
3.1 Aggregatable Global Unicast Address Structure
3.1 Aggregatableグローバルなユニキャストアドレス構造
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 | |
+--+-----+---+--------+--------+--------------------------------+
| 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を使用します。
The following sections specify each part of the IPv6 Aggregatable Global Unicast address format.
以下のセクションはIPv6 Aggregatable Global Unicastアドレス形式の各部分を指定します。
3.2 Top-Level Aggregation ID
3.2 トップレベルのAggregation ID
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.
トップレベルAggregation Identifiers(TLA ID)はルーティング階層構造のトップレベルです。 無デフォルトのルータは、あらゆるアクティブなTLA IDのために経路指定テーブルエントリーを持たなければならなくて、それらが位置しているTLA IDのためにたぶんルーティング情報を提供する追加エントリーを持つでしょう。 彼らには、追加エントリーがそれらの特定のトポロジーにルーティングを最適化するためにあるかもしれませんが、無料のルーティングが見送るデフォルトに食べさせられた追加エントリーの数を最小にするようにすべてのレベルにおけるルーティングトポロジーを設計しなければなりません。
Hinden, et. al. Standards Track [Page 4] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[4ページ]RFC2374IPv6
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課題に関連する問題はこのドキュメントの範囲を超えています。 それらはドキュメントで準備で説明されるでしょう。
3.3 Reserved
3.3 予約されました。
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を見てください。
3.4 Next-Level Aggregation Identifier
3.4 次のレベル集合識別子
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:
次のレベルAggregation IdentifierのものはTLA IDがアドレシング階層構造を作成して、サイトを特定するために割り当てられた組織によって使用されます。 組織は、ネットワークに適切な状態でアドレシング階層構造を作成するために方法でNLA IDの最高部分を割り当てることができます。 それは、それが役立ちたがっているサイトを特定するのにその分野のビットの残りを使用できます。 これは以下の通り示されます:
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
| n| 24-nビット| 16 | 64ビット| +-----+--------------------+--------+-----------------+ |NLA1| サイトID| SLA ID| インタフェース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のものが割り当てられた組織はそれら自身のSite IDスペースでNLA IDのものをサポートするかもしれません。 これで、TLA IDが割り当てられた組織は公共のトランジットサービスを提供する組織と、そして、公共のトランジットサービスを提供しない組織に対するサービスを提供できます。 また、NLA IDを受けるこれらの組織は、NLA IDの他のものをサポートするのにそれらのSite IDスペースを使用するのを選ぶかもしれません。 これは以下の通り示されます:
Hinden, et. al. Standards Track [Page 5] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[5ページ]RFC2374IPv6
| n | 24-n bits | 16 | 64 bits | +-----+--------------------+--------+-----------------+ |NLA1 | Site ID | SLA ID | Interface ID | +-----+--------------------+--------+-----------------+
| n| 24-nビット| 16 | 64ビット| +-----+--------------------+--------+-----------------+ |NLA1| サイトID| SLA ID| インタフェースID| +-----+--------------------+--------+-----------------+
| m | 24-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+
|NLA2 | Site ID | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+
| m| 24-n-m| 16 | 64ビット| +-----+--------------+--------+-----------------+ |NLA2| サイトID| SLA ID| インタフェースID| +-----+--------------+--------+-----------------+
| o |24-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+
|NLA3 | Site ID| SLA ID | Interface ID |
+-----+--------+--------+-----------------+
| o|24-n m o| 16 | 64ビット| +-----+--------+--------+-----------------+ |NLA3| サイトID| SLA ID| インタフェース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課題は、より簡単な配分と付属の柔軟性に備えますが、より大きい経路指定テーブルをもたらします。
3.5 Site-Level Aggregation Identifier
3.5 サイトレベル集合識別子
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識別子の間の、より大きい経路指定テーブルをもたらす少しの論理的関係性も作成しない)を発送するか、またはSLA ID分野で2以上の平らな階層構造(それは、より小さい経路指定テーブルをもたらす)を作成するのを選ぶかもしれません。 後者は以下の通り示されます:
Hinden, et. al. Standards Track [Page 6] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[6ページ]RFC2374IPv6
| n | 16-n | 64 bits | +-----+------------+-------------------------------------+ |SLA1 | Subnet | Interface ID | +-----+------------+-------------------------------------+
| n| 16-n| 64ビット| +-----+------------+-------------------------------------+ |SLA1| サブネット| インタフェースID| +-----+------------+-------------------------------------+
| m |16-n-m | 64 bits |
+----+-------+-------------------------------------+
|SLA2|Subnet | Interface ID |
+----+-------+-------------------------------------+
| m|16-n-m| 64ビット| +----+-------+-------------------------------------+ |SLA2|サブネット| インタフェース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.
このアドレス形式でサポートされたサブネットの数は最も大きい組織以外のすべてに十分であるべきです。 追加サブネットを必要とする組織はそれらが追加サイト識別子を得て、追加サブネットを作成するのにこれを使用するためにインターネットのサービスを得ている組織と共に手配されることができます。
3.6 Interface ID
3.6 インタフェースID
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]で組み立てられるのに必要です。 これらの識別子は、グローバルなトークン(例えば、IEEE48は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を作成するためのベースのInterface Identifiersが定義される手順[ARCH]。 適切で定義されて、「<の上のIPv6は>をリンクする」という「イーサネットの上のIPv6」などの仕様が[ETHER]、「FDDIの上のIPv6」[FDDI]であるというインタフェース識別子を形成することに関する詳細など
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. 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
Top平らなAggregation Identifierのサイズは13ビットです。 これは8,192TLA IDのものを考慮します。 インターネットのトップ平らなルータにおける無デフォルトの経路指定テーブルがそうであることを保障しますこのサイズが選ばれた。
Hinden, et. al. Standards Track [Page 7] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[7ページ]RFC2374IPv6
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.
現在のルーティング技術の手頃なマージンがある限界を制限しました。 また、無デフォルトのルータが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. 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.
それはこの時点のそれがおよそ5万の接頭語を含むとIPv4無デフォルトの経路指定テーブルに書く(春、1998)比較で有名であるべきです。 これは、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の数をかなり増加させます。
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.
Next-レベルAggregation Identifier分野のサイズは24ビットです。
Hinden, et. al. Standards Track [Page 8] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[8ページ]RFC2374IPv6
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.
平坦な方法で使用されるなら、これはおよそ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]で指定されて、このサイズは、条件を満たすために選ばれました。
5.0 Acknowledgments
5.0 承認
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.
作者は彼らのレビューと建設的なコメントのためにトーマスNarten、ボブFink、マット・クロフォード、アリソン・マンキン、ジムBound、クリスチャンのHuitema、スコット・ブラドナー、ブライアンCarpenter、ジョン・スチュワート、およびダニエルKarrenbergに感謝したがっています。
6.0 References
6.0の参照箇所
[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月。
[AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995.
[AUTH] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。
[AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address
Autoconfiguration", RFC 1971, August 1996.
[自動]のトンプソン、S.、およびT.Narten、「IPv6の状態がないアドレス自動構成」、RFC1971、8月1996日
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", Work in Progress.
[エーテル] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」が進行中で働いています。
Hinden, et. al. Standards Track [Page 9] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[9ページ]RFC2374IPv6
[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]のデアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC1883、12月1995日
[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.とKostersとM.とコンラッドとD.とKarrenberg、D.とJ.ポステル、「インターネット登録IP配分ガイドライン」、BCP12、RFC1466、1996年11月。
[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月。
7.0 Security Considerations
7.0 セキュリティ問題
IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH].
ドキュメントを扱うIPv6がインターネット基盤セキュリティに少しの直接的な衝撃も持っていません。 IPv6パケットの認証は[AUTH]で定義されます。
Hinden, et. al. Standards Track [Page 10] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[10ページ]RFC2374IPv6
8.0 Authors' Addresses
8.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
Mike O'Dell UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22030 USA
マイクオデルUUNET Technologies Inc.3060ウィリアムズ・Driveヴァージニア22030フェアファクス(米国)
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
西タスマン・DriveスティーブンE.デアリングシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Phone: 1 408 527-8213 EMail: deering@cisco.com
以下に電話をしてください。 1 408 527-8213 メールしてください: deering@cisco.com
Hinden, et. al. Standards Track [Page 11] RFC 2374 IPv6 Global Unicast Address Format July 1998
et Hinden、アル。 ユニキャストアドレス形式1998年7月にグローバルな標準化過程[11ページ]RFC2374IPv6
9.0 Full Copyright Statement
9.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, et. al. Standards Track [Page 12]
et Hinden、アル。 標準化過程[12ページ]
一覧
スポンサーリンク
