RFC1887 日本語訳
1887 An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter,T. Li, Eds.. December 1995. (Format: TXT=66066 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Y. Rekhter
Request for Comments: 1887 cisco Systems
Category: Informational T. Li
cisco Systems
Editors
December 1995
Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1887年のコクチマスSystems Category: 情報のT.李コクチマスSystemsエディターズ1995年12月
An Architecture for IPv6 Unicast Address Allocation
IPv6ユニキャストアドレス配分のためのアーキテクチャ
Status of this Memo
このMemoの状態
This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. The overall IPv6 addressing architecture is defined in [2]. This document does not go into the details of an addressing plan.
このドキュメントはインターネットにユニキャストアドレスをIPv6[1]に割り当てるのにアーキテクチャを提供します。 総合的なIPv6アドレッシング体系は[2]で定義されます。 このドキュメントはアドレシングプランの詳細を調べません。
1. Scope
1. 範囲
The global internet can be modeled as a collection of hosts interconnected via transmission and switching facilities. Control over the collection of hosts and the transmission and switching facilities that compose the networking resources of the global internet is not homogeneous, but is distributed among multiple administrative authorities. Resources under control of a single administration within a contiguous segment of network topology form a domain. For the rest of this paper, `domain' and `routing domain' will be used interchangeably.
トランスミッションと施設を切り換えることを通してホストの収集がインタコネクトしたようにグローバルなインターネットをモデル化できます。 グローバルなインターネットに関するネットワークリソースを構成するホストの収集、トランスミッション、および切り換え施設のコントロールは、均質ではありませんが、複数の職務権限の中に広げられます。 ネットワーク形態の隣接のセグメントの中でただ一つの管理で制御されたリソースはドメインを形成します。 この紙の残りのために、'ドメイン'と'経路ドメイン'は互換性を持って使用されるでしょう。
Domains that share their resources with other domains are called network service providers (or just providers). Domains that utilize other domain's resources are called network service subscribers (or just subscribers). A given domain may act as a provider and a subscriber simultaneously.
他のドメインとそれらのリソースを共有するドメインはネットワークサービスプロバイダー(または、まさしくプロバイダー)と呼ばれます。 他のドメインのリソースを利用するドメインはネットワーク・サービス加入者(または、まさしく加入者)と呼ばれます。 与えられたドメインは同時に、プロバイダーと加入者として機能するかもしれません。
Rekhter & Li Informational [Page 1] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[1ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
There are two aspects of interest when discussing IPv6 unicast address allocation within the Internet. The first is the set of administrative requirements for obtaining and allocating IPv6 addresses; the second is the technical aspect of such assignments, having largely to do with routing, both within a routing domain (intra-domain routing) and between routing domains (inter-domain routing). This paper focuses on the technical issues.
インターネットの中でIPv6ユニキャストアドレス配分について議論するとき、興味がある2つの局面があります。 1番目は入手とアドレスをIPv6に割り当てるための管理要件のセットです。 2番目はそのような課題の技術的側面です、ルーティングと主に関係があるので、経路ドメイン(イントラドメインルーティング)と経路ドメイン(相互ドメインルーティング)の間の両方。 この紙は専門的な問題に焦点を合わせます。
In the current Internet many routing domains (such as corporate and campus networks) attach to transit networks (such as regionals) in only one or a small number of carefully controlled access points. The former act as subscribers, while the latter act as providers.
現在のインターネットでは、多くの経路ドメイン(法人とキャンパスネットワークなどの)が1だけの輸送網(地方版などの)か慎重に制御されたアクセスポイントの少ない数に付きます。 前者は加入者として機能しますが、後者はプロバイダーとして機能します。
Addressing solutions which require substantial changes or constraints on the current topology are not considered.
現在のトポロジーで大きな変化か規制を必要とするアドレシング解決が考えられません。
The architecture and recommendations in this paper are oriented primarily toward the large-scale division of IPv6 address allocation in the Internet. Topics covered include:
この紙におけるアーキテクチャと推薦はインターネットで主としてIPv6アドレス配分の大規模な分割に向かって向けられます。 カバーされた話題は:
- Benefits of encoding some topological information in IPv6
addresses to significantly reduce routing protocol overhead;
- ルーティングをかなり減少させるためにIPv6アドレスの何らかの位相的な情報をコード化する利益はオーバーヘッドについて議定書の中で述べます。
- The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth;
- インターネットアドレシングによる追加レベルの階層構造がネットワークの成長をサポートする予期された必要性。
- The recommended mapping between Internet topological entities
(i.e., service providers, and service subscribers) and IPv6
addressing and routing components;
- インターネットの位相的な実体(すなわち、サービスプロバイダー、およびサービス加入者)と、IPv6アドレシングとルーティングコンポーネントの間のお勧めのマッピング。
- The recommended division of IPv6 address assignment among
service providers (e.g., backbones, regionals), and service
subscribers (e.g., sites);
- IPv6のお勧めの分割はサービスプロバイダー(例えば、バックボーン、地方版)、およびサービス加入者(例えば、サイト)の中で課題を扱います。
- Allocation of the IPv6 addresses by the Internet Registry;
- IPv6の配分はインターネットのそばでRegistryを扱います。
- Choice of the high-order portion of the IPv6 addresses in leaf
routing domains that are connected to more than one service
provider (e.g., backbone or a regional network).
- IPv6の高位一部の選択は、葉でルーティングが1つ以上のサービスプロバイダー(例えば、バックボーンか地域ネットワーク)につなげられるドメインであると扱います。
It is noted that there are other aspects of IPv6 address allocation, both technical and administrative, that are not covered in this paper. Topics not covered or mentioned only superficially include:
この紙でカバーされていない技術的で管理の両方のIPv6アドレス配分の他の局面があることに注意されます。 表面的にカバーされなかったか、または言及されなかった話題は:だけ
- A specific plan for address assignment;
- アドレス課題のための特定のプラン。
- Embedding address spaces from other network layer protocols
(including IPv4) in the IPv6 address space and the addressing
- アドレス空間を他のネットワーク層プロトコル(IPv4を含んでいる)からIPv6アドレス空間に埋め込んで、アドレシング
Rekhter & Li Informational [Page 2] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[2ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
architecture for such embedded addresses;
そのようなもののためのアーキテクチャはアドレスを埋め込みました。
- Multicast addressing;
- マルチキャストアドレシング。
- Address allocation for mobile hosts;
- モバイルホストのための配分を扱ってください。
- Identification of specific administrative domains in the
Internet;
- インターネットでの特定の管理ドメインの識別。
- Policy or mechanisms for making registered information known to
third parties (such as the entity to which a specific IPv6
address or a potion of the IPv6 address space has been
allocated);
- 第三者(特定のIPv6アドレスかIPv6アドレス空間の一服が割り当てられた実体などの)に登録された情報を明らかにするための方針かメカニズム。
- How a routing domain (especially a site) should organize its
internal topology or allocate portions of its IPv6 address
space; the relationship between topology and addresses is
discussed, but the method of deciding on a particular topology
or internal addressing plan is not; and,
- 経路ドメイン(特にサイト)は、内部のトポロジーを組織化するべきであるか、またはどうIPv6アドレス空間の部分を割り当てるべきであるか。 トポロジーとアドレスとの関係について議論しますが、特定のトポロジーか内部のアドレシングプランを決めるメソッドは議論するというわけではありません。 そして
- Procedures for assigning host IPv6 addresses.
- ホストIPv6にアドレスを割り当てるための手順。
2. Background
2. バックグラウンド
Some background information is provided in this section that is helpful in understanding the issues involved in IPv6 address allocation. A brief discussion of IPv6 routing is provided.
このIPv6アドレス配分にかかわる問題を理解する際に役立っているセクションに何らかの基礎的な情報を提供します。 IPv6ルーティングの簡潔な議論を提供します。
IPv6 partitions the routing problem into three parts:
IPv6はルーティング問題を3つの部品に仕切ります:
- Routing exchanges between end systems and routers,
- エンドシステムとルータの間の交換を発送します。
- Routing exchanges between routers in the same routing domain,
and,
- そして、同じ経路ドメインのルータの間の交換を発送します。
- Routing among routing domains.
- 経路ドメインの中で掘ります。
3. IPv6 Addresses and Routing
3. IPv6アドレスとルート設定
For the purposes of this paper, an IPv6 address prefix is defined as an IPv6 address and some indication of the leftmost contiguous significant bits within this address portion. Throughout this paper IPv6 address prefixes will be represented as X/Y, where X is a prefix of an IPv6 address in length greater than or equal to that specified
この紙の目的のために、IPv6アドレス接頭語はこのアドレスの部分の中で一番左隣接の重要なビットのIPv6アドレスといくつかのしるしと定義されます。 この紙中では、接頭語がそうするIPv6アドレスがX/Yとして表されて、それはXが長さにおけるIPv6アドレスの接頭語以上であるところで指定しました。
Rekhter & Li Informational [Page 3] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[3ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
by Y and Y is the (decimal) number of the leftmost contiguous significant bits within this address. In the notation, X, the prefix of an IPv6 address [2] will have trailing insignificant digits removed. Thus, an IPv6 prefix might appear to be 43DC:0A21:76/40.
YとYで、このアドレスの中の一番左隣接の重要なビットの(10進)の数はそうですか? 記法、Xでは、IPv6アドレス[2]の接頭語で、引きずっているわずかなケタを取り除くでしょう。 したがって、IPv6接頭語は43DCであるように見えるかもしれません: 0A21: 76/40。
When determining an administrative policy for IPv6 address assignment, it is important to understand the technical consequences. The objective behind the use of hierarchical routing is to achieve some level of routing data abstraction, or summarization, to reduce the cpu, memory, and transmission bandwidth consumed in support of routing.
IPv6アドレス課題のための施政方針を決定するとき、技術的な結果を理解しているのは重要です。 階層型ルーティングの使用の後ろの目的は帯域幅がルーティングを支持して消費したcpu、メモリ、およびトランスミッションを減らすために何らかのレベルのルーティングデータ抽象化、または総括を達成することです。
While the notion of routing data abstraction may be applied to various types of routing information, this paper focuses on one particular type, namely reachability information. Reachability information describes the set of reachable destinations. Abstraction of reachability information dictates that IPv6 addresses be assigned according to topological routing structures. However in practice administrative assignment falls along organizational or political boundaries. These may not be congruent to topological boundaries and therefore the requirements of the two may collide. It is necessary to find a balance between these two needs.
ルーティングデータ抽象化の概念は様々なタイプのルーティング情報に適用されるかもしれませんが、この紙はすなわち、1つの特定のタイプ、可到達性情報に焦点を合わせます。 可到達性情報は届いている目的地のセットについて説明します。 可到達性情報の抽象化は、位相的なルーティング構造に従ってIPv6アドレスが割り当てられると決めます。 しかしながら、実際には、管理課題は組織的であるか政治上の境界に沿って下がります。 これらは位相的な境界に一致していないかもしれません、そして、したがって、2つのものの要件は衝突するかもしれません。 これらの2の間のバランスに必要性を見つけるのが必要です。
Reachability information abstraction occurs at the boundary between hierarchically arranged topological routing structures. An element lower in the hierarchy reports summary reachability information to its parent(s).
抽象化が階層的の間の境界に起こるという可到達性情報は位相的なルーティング構造をアレンジしました。 要素は階層構造レポート概要可到達性情報で親に下げられます。
At routing domain boundaries, IPv6 address information is exchanged (statically or dynamically) with other routing domains. If IPv6 addresses within a routing domain are all drawn from non-contiguous IPv6 address spaces (allowing no abstraction), then the address information exchanged at the boundary consists of an enumerated list of all the IPv6 addresses.
ルーティングドメイン境界では、他の経路ドメインでIPv6アドレス情報を交換します(静的かダイナミックに)。 非隣接のIPv6アドレス空間から経路ドメインの中のIPv6アドレスをすべて得るなら(抽象化を全く許さないで)、境界で交換されたアドレス情報はすべてのIPv6アドレスの列挙されたリストから成ります。
Alternatively, should the routing domain draw IPv6 addresses for all the hosts within the domain from a single IPv6 address prefix, boundary routing information can be summarized into the single IPv6 address prefix. This permits substantial data reduction and allows better scaling (as compared to the uncoordinated addressing discussed in the previous paragraph).
あるいはまた境界ルーティング情報を経路ドメインがすべてのホストのためにドメインの中でただ一つのIPv6アドレス接頭語からIPv6アドレスを作成するならただ一つのIPv6アドレス接頭語へまとめることができます。 これは、かなりのデータ整理を許可して、比例するほうがよいのを許容します(前のパラグラフで議論した非調整されたアドレシングと比べて)。
If routing domains are interconnected in a more-or-less random (i.e., non-hierarchical) scheme, it is quite likely that no further abstraction of routing data can occur. Since routing domains would have no defined hierarchical relationship, administrators would not be able to assign IPv6 addresses within the domains out of some common prefix for the purpose of data abstraction. The result would
すなわち、経路ドメインがaで多少無作為の状態でインタコネクトされる、(非、階層的である、)、体系、ルーティングデータのさらなる抽象化は全くかなり起こりそうであることができません。 経路ドメインには、定義された上下関係が全くないでしょう、したがって、管理者がデータ抽象化の目的のためにドメインの中でアドレスを何らかの一般的な接頭語からIPv6に割り当てることができないでしょう。 結果はそうするでしょう。
Rekhter & Li Informational [Page 4] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[4ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
be flat inter-domain routing; all routing domains would need explicit knowledge of all other routing domains that they route to. This can work well in small and medium sized internets. However, this does not scale to very large internets. For example, we expect IPv6 to grow to hundreds of thousands of routing domains in North America alone. This requires a greater degree of the reachability information abstraction beyond that which can be achieved at the `routing domain' level.
平坦な相互ドメインルーティングになってください。 ドメインがそれらが発送する他のすべての経路ドメインの形式知を必要とするすべてのルーティング。 これは小さくて中型の大きさで分けられたインターネットでうまくいくことができます。 しかしながら、これは非常に大きいインターネットに比例しません。 例えば、私たちは、IPv6が単独に北アメリカの何十万もの経路ドメインまでなると予想します。 これは'経路ドメイン'レベルで達成できるそれを超えて可到達性情報抽象化の、より大きい度合いを必要とします。
In the Internet, it should be possible to significantly constrain the volume and the complexity of routing information by taking advantage of the existing hierarchical interconnectivity. This is discussed further in Section 5. Thus, there is the opportunity for a group of routing domains each to be assigned an address prefix from a shorter prefix assigned to another routing domain whose function is to interconnect the group of routing domains. Each member of the group of routing domains now has its (somewhat longer) prefix, from which it assigns its addresses.
インターネットでは、既存の階層的な相互接続性を利用することによってルーティング情報のボリュームと複雑さをかなり抑制するのは可能であるべきです。 セクション5で、より詳しくこれについて議論します。 したがって、アドレス接頭語が経路ドメインのグループとインタコネクトする機能がことである別の経路ドメインに割り当てられたより短い接頭語から経路ドメインのグループにそれぞれ配属される機会があります。 経路ドメインのグループの各メンバーには、現在、(いくらか長い)の接頭語があります。(それはそれからアドレスを割り当てます)。
The most straightforward case of this occurs when there is a set of routing domains which are all attached to a single service provider domain (e.g., regional network), and which use that provider for all external (inter-domain) traffic. A short prefix may be given to the provider, which then gives slightly longer prefixes (based on the provider's prefix) to each of the routing domains that it interconnects. This allows the provider, when informing other routing domains of the addresses that it can reach, to abstract the reachability information for a large number of routing domains into a single prefix. This approach therefore can allow a great deal of reduction of routing information, and thereby can greatly improve the scalability of inter-domain routing.
ただ一つのサービスプロバイダードメイン(例えば、地域ネットワーク)にすべて付けられていて、すべての外部(相互ドメイン)のトラフィックにそのプロバイダーを使用する1セットの経路ドメインがあるとき、この最も簡単なケースは現れます。 短い接頭語をプロバイダーに与えるかもしれません。(次に、それは、わずかに長い接頭語(プロバイダーの接頭語に基づいている)をそれがインタコネクトするそれぞれの経路ドメインに与えます)。 ただ一つの接頭語への多くの経路ドメインのための可到達性情報に要約に達することができることをアドレスの他の経路ドメインに知らせるとき、これはプロバイダーを許容します。 このアプローチは、したがって、ルーティング情報の大きな減少を許すことができて、その結果、相互ドメインルーティングのスケーラビリティを大いに改良できます。
Clearly, this approach is recursive and can be carried through several iterations. Routing domains at any `level' in the hierarchy may use their prefix as the basis for subsequent suballocations, assuming that the IPv6 addresses remain within the overall length and structure constraints.
明確に、このアプローチは、再帰的であり、いくつかの繰り返しで運ぶことができます。 階層構造のどんな'レベル'でも経路ドメインはその後の細分割当ての基礎としてそれらの接頭語を使用するかもしれません、IPv6アドレスが全長と構造規制に残っていると仮定して。
At this point, we observe that the number of nodes at each lower level of a hierarchy tends to grow exponentially. Thus the greatest gains in the reachability information abstraction (for the benefit of all higher levels of the hierarchy) occur when the reachability information aggregation occurs near the leaves of the hierarchy; the gains drop significantly at each higher level. Therefore, the law of diminishing returns suggests that at some point data abstraction ceases to produce significant benefits. Determination of the point at which data abstraction ceases to be of benefit requires a careful consideration of the number of routing domains that are expected to
ここに、私たちは、階層構造の各下のレベルにおけるノードの数が、指数関数的に成長する傾向があるのを観測します。 したがって、可到達性情報集合が階層構造の葉の近くに起こると、可到達性情報抽象化(階層構造のすべての、より高いレベルの利益のための)における最大級の利得は起こります。 利得はそれぞれのより高いレベルで著しく低下します。 したがって、収穫逓減の法則は、何らかのポイントデータ抽象化におけるそれが、重要な利益を生産するのをやめるのを示します。 データ抽象化が有益であることをやめるポイントの決断は予想される経路ドメインの数の熟慮を必要とします。
Rekhter & Li Informational [Page 5] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[5ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
occur at each level of the hierarchy (over a given period of time), compared to the number of routing domains and address prefixes that can conveniently and efficiently be handled via dynamic inter-domain routing protocols.
階層構造(与えられた期間の間の)の各レベルで起こってください、ダイナミックな相互ドメインルーティング・プロトコルで便利に効率的に扱うことができる経路ドメインとアドレス接頭語の数と比べて。
3.1 Efficiency versus Decentralized Control.
3.1 効率対分散制御
If the Internet plans to support a decentralized address administration, then there is a balance that must be sought between the requirements on IPv6 addresses for efficient routing and the need for decentralized address administration. A coherent addressing plan at any level within the Internet must take the alternatives into careful consideration.
インターネットが、分散アドレスが管理であるとサポートするのを計画しているなら、効率的なルーティングのためのIPv6アドレスに関する要件と分散アドレス管理の必要性の間で求めなければならないバランスがあります。 インターネットの中のどんなレベルでも論理的なアドレシングプランは代替手段を熟慮に連れていかなければなりません。
As an example of administrative decentralization, suppose the IPv6 address prefix 43/8 identifies part of the IPv6 address space allocated for North America. All addresses within this prefix may be allocated along topological boundaries in support of increased data abstraction. Within this prefix, addresses may be allocated on a per-provider bases, based on geography or some other topologically significant criteria. For the purposes of this example, suppose that this prefix is allocated on a per-provider basis. Subscribers within North America use parts of the IPv6 address space that is underneath the IPv6 address space of their service providers. Within a routing domain addresses for subnetworks and hosts are allocated from the unique IPv6 prefix assigned to the domain according to the addressing plan for that domain.
行政の地方分権に関する例として、IPv6アドレス接頭語43/8が北アメリカに割り当てられたIPv6アドレス空間の一部を特定すると仮定してください。 位相的な境界に沿って増強されたデータ抽象化を支持してこの接頭語の中のすべてのアドレスを割り当てるかもしれません。 または、プロバイダーにこの接頭語の中では、アドレスを割り当てるかもしれない、地理学に基づいたベース、ある他の位相的である、重要な評価基準 この例の目的には、この接頭語が1プロバイダーあたり1個のベースに割り当てられると仮定してください。 北アメリカの中の加入者はそれらのサービスプロバイダーのIPv6アドレス空間の下にあるIPv6アドレス空間の部品を使用します。 経路ドメインの中では、そのドメインのためのアドレシング計画通りにそのドメインに割り当てられたユニークなIPv6接頭語からサブネットワークとホストのためのアドレスを割り当てます。
4. IPv6 Address Administration and Routing in the Internet
4. インターネットのIPv6アドレス管理とルート設定
Internet routing components -- service providers (e.g., backbones, regional networks), and service subscribers (e.g., sites or campuses) -- are arranged hierarchically for the most part. A natural mapping from these components to IPv6 routing components is for providers and subscribers to act as routing domains.
インターネット・ルーティングコンポーネント(サービスプロバイダー(例えば、バックボーン、地域ネットワーク)、およびサービス加入者(例えば、サイトかキャンパス))は階層的にだいたい配置されます。 自然なこれらのコンポーネントからIPv6ルーティングの部品までのマッピングはプロバイダーと加入者がドメインを発送するとして務めることです。
Alternatively, a subscriber (e.g., a site) may choose to operate as a part of a domain formed by a service provider. We assume that some, if not most, sites will prefer to operate as part of their provider's routing domain, exchanging routing information directly with the provider. The site is still allocated a prefix from the provider's address space, and the provider will advertise its own prefix into inter-domain routing.
あるいはまた、加入者(例えば、サイト)は、ドメインの一部がサービスプロバイダーによって形成されたので作動するのを選ぶかもしれません。 私たちが、それがいくつかであると思うか、またはサイトは、それらのプロバイダーの経路ドメインの一部として作動するのを最も好むでしょう、直接ルーティング情報をプロバイダーと交換して。 接頭語をプロバイダーのアドレス空間からサイトにまだ割り当てています、そして、プロバイダーは相互ドメインルーティングにそれ自身の接頭語の広告を出すでしょう。
Rekhter & Li Informational [Page 6] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[6ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
Given such a mapping, where should address administration and allocation be performed to satisfy both administrative decentralization and data abstraction? The following possibilities are considered:
そのようなマッピングを考えて、アドレス管理と配分は、行政の地方分権とデータ抽象化の両方を満たすためにどこで実行されるべきですか? 以下の可能性は考えられます:
1) At some part within a routing domain,
1) いくつかでは、経路ドメインの中で離れてください。
2) At the leaf routing domain,
2) 葉の経路ドメインで
3) At the transit routing domain (TRD), and
3) そしてトランジット経路ドメイン(TRD)で。
4) At some other, more general boundaries, such as at the
continental boundary.
4) ある他のより一般的な境界で、大陸の境界であれほどです。
A part within a routing domain corresponds to any arbitrary connected set of subnetworks. If a domain is composed of multiple subnetworks, they are interconnected via routers. Leaf routing domains correspond to sites, where the primary purpose is to provide intra-domain routing services. Transit routing domains are deployed to carry transit (i.e., inter-domain) traffic; backbones and providers are TRDs. More general boundaries can be seen as topologically significant collections of TRDs.
経路ドメインの中の部分はどんな任意の連結集合のサブネットワークにも対応しています。 ドメインが複数のサブネットワークで構成されるなら、それらはルータでインタコネクトされます。 葉の経路ドメインはサイトに対応しています。そこでは、プライマリ目的はイントラドメインルーティングサービスを提供することです。 トランジット経路ドメインはトランジット(すなわち、相互ドメイン)トラフィックを運ぶために配布されます。 バックボーンとプロバイダーはTRDsです。 より一般的な境界と位相的に考えることができます。TRDsの重要な収集。
The greatest burden in transmitting and operating on reachability information is at the top of the routing hierarchy, where reachability information tends to accumulate. In the Internet, for example, providers must manage reachability information for all subscribers directly connected to the provider. Traffic destined for other providers is generally routed to the backbones (which act as providers as well). The backbones, however, must be cognizant of the reachability information for all attached providers and their associated subscribers.
可到達性情報が伝わって、作動するのにおいて最も大きい負担がルーティング階層構造の最上部にあります。(そこでは、可到達性情報が蓄積する傾向があります)。 インターネットでは、例えば、プロバイダーは直接プロバイダーに接続されたすべての加入者のために可到達性情報を管理しなければなりません。 一般に、他のプロバイダーのために運命づけられたトラフィックはバックボーン(また、プロバイダーとしてのどの行為)に発送されるか。 しかしながら、バックボーンはすべての付属プロバイダーと彼らの関連加入者にとって可到達性情報を認識していなければなりません。
In general, the advantage of abstracting routing information at a given level of the routing hierarchy is greater at the higher levels of the hierarchy. There is relatively little direct benefit to the administration that performs the abstraction, since it must maintain routing information individually on each attached topological routing structure.
一般に、階層構造の、より高いレベルではルーティング階層構造の与えられたレベルでルーティング情報を抜き取る利点は、より大きいです。 抽象化を実行する管理への比較的少ない直接利益があります、それぞれの付属位相的なルーティング構造の上で個別にルーティング情報を保守しなければならないので。
For example, suppose that a given site is trying to decide whether to obtain an IPv6 address prefix directly from the IPv6 address space allocated for North America, or from the IPv6 address space allocated to its service provider. If considering only their own self-interest, the site itself and the attached provider have little reason to choose one approach or the other. The site must use one prefix or another; the source of the prefix has little effect on routing efficiency within the site. The provider must maintain information
例えば、与えられたサイトが、直接北アメリカに割り当てられたIPv6アドレス空間、または、サービスプロバイダーに割り当てられたIPv6アドレス空間からIPv6アドレス接頭語を得るかどうか決めようとしていると仮定してください。 それら自身の私利だけを考えるなら、サイト自体と付属プロバイダーには、1つのアプローチかもう片方を選ぶ理由がほとんどありません。 サイトは何らかの接頭語を使用しなければなりません。 接頭語の源はサイトの中でほとんどルーティング効率に影響を与えません。 プロバイダーは情報を保守しなければなりません。
Rekhter & Li Informational [Page 7] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[7ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
about each attached site in order to route, regardless of any commonality in the prefixes of the sites.
およそそれぞれ、いずれもにかかわらずサイトの接頭語の共通点を発送するためにサイトを添付しました。
However, there is a difference when the provider distributes routing information to other providers (e.g., backbones or TRDs). In the first case, the provider cannot aggregate the site's address into its own prefix; the address must be explicitly listed in routing exchanges, resulting in an additional burden to other providers which must exchange and maintain this information.
しかしながら、プロバイダーが他のプロバイダー(例えば、バックボーンかTRDs)にルーティング情報を分配するとき、違いがあります。 前者の場合、プロバイダーはそれ自身の接頭語へのサイトのアドレスに集められることができません。 ルーティング交換で明らかにアドレスを記載しなければなりません、この情報を交換して、保守しなければならない他のプロバイダーへの追加負担をもたらして。
In the second case, each other provider (e.g., backbone or TRD) sees a single address prefix for the provider, which encompasses the new site. This avoids the exchange of additional routing information to identify the new site's address prefix. Thus, the advantages primarily accrue to other providers which maintain routing information about this site and provider.
2番目の場合でプロバイダー(例えば、バックボーンかTRD)が、ただ一つのアドレスがプロバイダー(新しいサイトを包含するもの)のために前に置くのを見る互い これは、新しいサイトのアドレス接頭語を特定するために追加ルーティング情報の交換を避けます。 したがって、利点は主としてこのサイトとプロバイダーのルーティング情報を保守する他のプロバイダーに生じます。
One might apply a supplier/consumer model to this problem: the higher level (e.g., a backbone) is a supplier of routing services, while the lower level (e.g., a TRD) is the consumer of these services. The price charged for services is based upon the cost of providing them. The overhead of managing a large table of addresses for routing to an attached topological entity contributes to this cost.
1つは供給者/消費者モデルをこの問題に適用するかもしれません: より高いレベル(例えば、バックボーン)はルーティングサービスの供給者です、下のレベル(例えば、TRD)はこれらのサービスの消費者ですが。 サービスに課される価格はそれらを提供する費用に基づいています。 ルーティングのためのアドレスの大きいテーブルを付属位相的な実体に管理するオーバーヘッドはこの費用に貢献します。
At present the Internet, however, is not a market economy. Rather, efficient operation is based on cooperation. The recommendations discussed below describe simple and tractable ways of managing the IPv6 address space that benefit the entire community.
しかしながら、現在のところ、インターネットは市場経済ではありません。 むしろ、効率的な操作は協力に基づいています。 以下で議論した推薦は全体の共同体のためになるIPv6アドレス空間を管理する簡単で御しやすい方法を述べます。
4.1 Administration of IPv6 addresses within a domain.
4.1 ドメインの中のIPv6アドレスの政権。
If individual hosts take their IPv6 addresses from a myriad of unrelated IPv6 address spaces, there will be effectively no data abstraction beyond what is built into existing intra-domain routing protocols. For example, assume that within a routing domain uses three independent prefixes assigned from three different IPv6 address spaces associated with three different attached providers.
個々のホストが関係ないIPv6アドレス空間の無数から彼らのIPv6アドレスを取ると、データ抽象化は全く有効に既存のイントラドメインルーティング・プロトコルが組み込まれることを超えていないでしょう。 例えば、経路ドメインの中のそれが3つの異なった付属プロバイダーに関連している3つの異なったIPv6アドレス空間から割り当てられた3つの独立している接頭語を使用すると仮定してください。
This has a negative effect on inter-domain routing, particularly on those other domains which need to maintain routes to this domain. There is no common prefix that can be used to represent these IPv6 addresses and therefore no summarization can take place at the routing domain boundary. When addresses are advertised by this routing domain to other routing domains, an enumerated list of the three individual prefixes must be used.
これは相互ドメインルーティングでマイナスの影響があります、特にこのドメインにルートを維持する必要があるそれらの他のドメインで。 これらのIPv6アドレスを表すのに使用できるどんな一般的な接頭語もありません、そして、したがって、総括は全くルーティングドメイン境界で行われることができません。 アドレスがこの経路ドメインによって他の経路ドメインに広告に掲載されるとき、3つの個々の接頭語の列挙されたリストを使用しなければなりません。
Rekhter & Li Informational [Page 8] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[8ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
The number of IPv6 prefixes that leaf routing domains would advertise is on the order of the number of prefixes assigned to the domain; the number of prefixes a provider's routing domain would advertise is approximately the number of prefixes attached to the client leaf routing domains; and for a backbone this would be summed across all attached providers. This situation is just barely acceptable in the current Internet, and is intractable for the IPv6 Internet. A greater degree of hierarchical information reduction is necessary to allow continued growth in the Internet.
そのドメインに割り当てられた接頭語の数の注文には葉の経路ドメインが広告を出すIPv6接頭語の数があります。 プロバイダーの経路ドメインが広告を出す接頭語の数はクライアント葉の経路ドメインに付けられた接頭語のおよそ数です。 そして、バックボーンにおいて、これはすべての付属プロバイダーの向こう側にまとめられるでしょう。 この状況は、現在のインターネットでちょうどほとんど許容できないで、IPv6インターネットに、手に負えません。 より大きい度合いの階層的な情報減少が、インターネットの継続成長を許容するのに必要です。
4.2 Administration at the Leaf Routing Domain
4.2 葉の経路ドメインの政権
As mentioned previously, the greatest degree of data abstraction comes at the lowest levels of the hierarchy. Providing each leaf routing domain (that is, site) with a contiguous block of addresses from its provider's address block results in the biggest single increase in abstraction. From outside the leaf routing domain, the set of all addresses reachable in the domain can then be represented by a single prefix. Further, all destinations reachable within the provider's prefix can be represented by a single prefix.
既述のとおり、最も大きい度合いのデータ抽象化は階層構造の最も低いレベルで来ます。 それぞれの葉の経路ドメイン(すなわち、サイト)をプロバイダーのあて先ブロックからアドレスの隣接のブロックに供給すると、抽象化の最も大きいただ一つの増加はもたらされます。 そして、葉の経路ドメインの外から、ただ一つの接頭語はそのドメインで届いているすべてのアドレスのセットを表すことができます。 さらに、ただ一つの接頭語はプロバイダーの接頭語の中で届いているすべての目的地を表すことができます。
For example, consider a single campus which is a leaf routing domain which would currently require 4 different IPv6 prefixes. Instead, they may be given a single prefix which provides the same number of destination addresses. Further, since the prefix is a subset of the provider's prefix, they impose no additional burden on the higher levels of the routing hierarchy.
例えば、現在4つの異なったIPv6接頭語を必要とする葉の経路ドメインである単一のキャンパスを考えてください。 代わりに、同じ数の送付先アドレスを提供するただ一つの接頭語をそれらに与えるかもしれません。 さらに、彼らは、接頭語がプロバイダーの接頭語の部分集合であるので、ルーティング階層構造の、より高いレベルにどんな追加負担も課しません。
There is a close relationship between hosts and routing domains. The routing domain represents the only path between a host and the rest of the internetwork. It is reasonable that this relationship also extend to include a common IPv6 addressing space. Thus, the hosts within the leaf routing domain should take their IPv6 addresses from the prefix assigned to the leaf routing domain.
ホストと経路ドメインの間には、密接な関係があります。 経路ドメインはホストとインターネットワークの残りの間の唯一の経路を表します。 また、この関係がスペースを扱う一般的なIPv6を含むように広がるのは、妥当です。 したがって、葉の経路ドメインの中のホストは葉の経路ドメインに割り当てられた接頭語から彼らのIPv6アドレスを取るべきです。
4.3 Administration at the Transit Routing Domain
4.3 トランジット経路ドメインの政権
Two kinds of transit routing domains are considered, direct providers and indirect providers. Most of the subscribers of a direct provider are domains that act solely as service subscribers (they carry no transit traffic). Most of the subscribers of an indirect provider are domains that, themselves, act as service providers. In present terminology a backbone is an indirect provider, while an NSFnet regional is an example of a direct provider. Each case is discussed
2種類のトランジット経路ドメインは、考えられて、ダイレクトなプロバイダーと間接的なプロバイダーです。 ダイレクトプロバイダーの加入者の大部分は唯一サービス加入者として機能するドメイン(彼らはトランジットトラフィックを全く運ばない)です。 間接的なプロバイダーの加入者の大部分はそれ(自分たち)がサービスプロバイダーとして務めるドメインです。 現在の用語では、バックボーンは間接的なプロバイダーであり、NSFnetである間、地方であることは、ダイレクトプロバイダーに関する例です。 各ケースについて議論します。
Rekhter & Li Informational [Page 9] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[9ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
separately below.
別々に..以下に
4.3.1 Direct Service Providers
4.3.1 直航プロバイダー
In a provider-based addressing plan, direct service providers should use their IPv6 address space for assigning IPv6 addresses from a unique prefix to the leaf routing domains that they serve. The benefits derived from data abstraction are greater than in the case of leaf routing domains, and the additional degree of data abstraction provided by this may be necessary in the short term.
プロバイダーベースのアドレシングプランでは、直航プロバイダーは、ユニークな接頭語からそれらが役立つ葉の経路ドメインまでアドレスをIPv6に割り当てるのにそれらのIPv6アドレス空間を使用するべきです。 データ抽象化から得られた利益は葉の経路ドメインに関するケースよりすばらしいです、そして、これによって提供された追加度合いのデータ抽象化が短期で必要であるかもしれません。
As an illustration consider an example of a direct provider that serves 100 clients. If each client takes its addresses from 4 independent address spaces then the total number of entries that are needed to handle routing to these clients is 400 (100 clients times 4 providers). If each client takes its addresses from a single address space then the total number of entries would be only 100. Finally, if all the clients take their addresses from the same address space then the total number of entries would be only 1.
イラストと、100人のクライアントに役立つダイレクトプロバイダーに関する例を考えてください。 各クライアントが4つの独立しているアドレス空間からアドレスを取るなら、これらのクライアントにルーティングを扱うのに必要であるエントリーの総数は400(100のクライアント回の4プロバイダー)です。 各クライアントがただ一つのアドレス空間からアドレスを取るなら、エントリーの総数は100にすぎないでしょう。 最終的に、すべてのクライアントが同じアドレス空間から彼らのアドレスを取る場合にだけ、エントリーの総数は1でしょう。
We expect that in the near term the number of routing domains in the Internet will grow to the point that it will be infeasible to route on the basis of a flat field of routing domains. It will therefore be essential to provide a greater degree of information abstraction with IPv6.
私たちは、近いうちにインターネットの経路ドメインの数が経路ドメインの平らな野原に基づいて発送するのにおいて実行不可能になるというポイントに成長すると予想します。 したがって、より大きい度合いの情報抽象化にIPv6を提供するのは不可欠でしょう。
Direct providers may give part of their address space (prefixes) to leaf domains, based on an address prefix given to the provider. This results in direct providers advertising to other providers a small fraction of the number of address prefixes that would be necessary if they enumerated the individual prefixes of the leaf routing domains. This represents a significant savings given the expected scale of global internetworking.
ダイレクトプロバイダーはそれらのアドレス空間(接頭語)の一部を葉のドメインに与えるかもしれません、プロバイダーに与えられたアドレス接頭語に基づいて。 これはアドレスの数のわずかな部分が前に置く他の葉の経路ドメインの個々の接頭語を列挙するなら必要なプロバイダーへのダイレクトプロバイダー広告をもたらします。 グローバルなインターネットワーキングの予想されたスケールを考えて、これは重要な貯蓄を表します。
The efficiencies gained in inter-domain routing clearly warrant the adoption of IPv6 address prefixes derived from the IPv6 address space of the providers.
相互ドメインルーティングで明確に獲得された効率はプロバイダーのIPv6アドレス空間から得られたIPv6アドレス接頭語の採用を保証します。
The mechanics of this scenario are straightforward. Each direct provider is given a unique small set of IPv6 address prefixes, from which its attached leaf routing domains can allocate slightly longer IPv6 address prefixes. For example assume that NIST is a leaf routing domain whose inter-domain link is via SURANet. If SURANet is assigned an unique IPv6 address prefix 43DC:0A21/32, NIST could use a unique IPv6 prefix of 43DC:0A21:7652:34/56.
このシナリオの整備士は正直です。 ユニークな小さいセットのIPv6アドレス接頭語をそれぞれのダイレクトプロバイダーに与えます。(付属葉の経路ドメインは、アドレス接頭語を接頭語から、より長いIPv6にわずかに割り当てることができます)。 例えば、NISTがSURANetを通して相互ドメインリンクがある葉の経路ドメインであると仮定してください。 ユニークなIPv6アドレス接頭語43DC: 0A21/32がSURANetに割り当てられるなら、NISTは43DC: 0A21のユニークなIPv6接頭語を使用するかもしれません:、7652、: 34/56
Rekhter & Li Informational [Page 10] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[10ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
If a direct service provider is connected to another provider(s) (either direct or indirect) via multiple attachment points, then in certain cases it may be advantageous to the direct provider to exert a certain degree of control over the coupling between the attachment points and flow of the traffic destined to a particular subscriber. Such control can be facilitated by first partitioning all the subscribers into groups, such that traffic destined to all the subscribers within a group should flow through a particular attachment point. Once the partitioning is done, the address space of the provider is subdivided along the group boundaries. A leaf routing domain that is willing to accept prefixes derived from its direct provider gets a prefix from the provider's address space subdivision associated with the group the domain belongs to.
ある場合には、直航プロバイダーが複数の付着点を通した(直接か間接的)の別のプロバイダーに関連づけられるなら、付着点の間のカップリングのある度のコントロールと特定の加入者に運命づけられた交通の流れを及ぼすのはダイレクトプロバイダーに有利であるかもしれません。 グループへのすべての加入者、交通がグループの中のすべての加入者に運命づけられたようなものがそうするべきである最初の仕切りでそのようなコントロールを容易にすることができます。特定の付着点を通した流れ。 仕切りがいったん完了していると、プロバイダーのアドレス空間はグループ限界に沿って細分されます。 ダイレクトプロバイダーから得られた接頭語を受け入れても構わないと思っている葉の経路ドメインはプロバイダーのドメインが属すグループに関連しているアドレス空間下位区分から接頭語を得ます。
At the attachment point (between the direct and indirect providers) the direct provider advertises both an address prefix that corresponds to the address space of the provider, and one or more address prefixes that correspond to the address space associated with each subdivision. The latter prefixes match the former prefix, but are longer than the former prefix. Use of the "longest match" forwarding algorithm by the recipients of these prefixes (e.g., a router within the indirect provider) results in forcing the flow of the traffic to destinations depicted by the longer address prefixes through the attachment point where these prefixes are advertised to the indirect provider.
付着点(ダイレクトで間接的なプロバイダーの間の)では、ダイレクトプロバイダーはプロバイダーのアドレス空間に対応するアドレス接頭語と各下位区分に関連しているアドレス空間に対応する1つ以上のアドレス接頭語の両方の広告を出します。 後者の接頭語は、前の接頭語を合わせますが、前の接頭語より長いです。 これらの受取人による「最も長いマッチ」推進アルゴリズムの使用は付着点のを通ってこれらの接頭語が間接的なプロバイダーに広告に掲載されているより長いアドレス接頭語によって表現された目的地に交通の流れを強制する際に結果を前に置きます(例えば、間接的なプロバイダーの中のルータ)。
For example, assume that SURANet is connected to another regional provider, NEARNet, at two attachment points, A1 and A2. SURANet is assigned a unique IPv6 address prefix 43DC:0A21/32. To exert control over the traffic flow destined to a particular subscriber within SURANet, SURANet may subdivide the address space assigned to it into two groups, 43DC:0A21:8/34 and 43DC:0A21:C/34. The former group may be used for sites attached to SURANet that are closer (as determined by the topology within SURANet) to A1, while the latter group may be used for sites that are closer to A2. The SURANet router at A1 advertises both 43DC:0A21/32 and 43DC:0A21:8/34 address prefixes to the router in NEARNet. Likewise, the SURANet router at A2 advertises both 43DC:0A21/32 and 43DC:0A21:C/34 address prefixes to the router in NEARNet. Traffic that flows through NEARNet to destinations that match 43DC:0A21:8/34 address prefix would enter SURANet at A1, while traffic to destinations that match 43DC:0A21:C/34 address prefix would enter SURANet at A2.
例えば、SURANetが2つの付着点、A1、およびA2で別の地方のプロバイダー、NEARNetに接続されると仮定してください。 ユニークなIPv6アドレス接頭語43DCはSURANetに割り当てられます: 0A21/32。 SURANetの中の特定の加入者に運命づけられた交通の流れのコントロールを及ぼすために、SURANetはそれに割り当てられたアドレス空間を2つのグループ、43DC:0A21:8/34、および43DC:0A21:C/34に細分するかもしれません。 前のグループはA1の、より近く(SURANetの中でトポロジーで決定するように)にあるSURANetに添付されたサイトに使用されるかもしれません、後者のグループがA2の、より近くにあるサイトに使用されるかもしれませんが。 A1のSURANetルータは43DC: 0A21/32と43DC:0A21:8/34のアドレス接頭語の両方のNEARNetのルータに広告を出します。 同様に、A2のSURANetルータは43DC: 0A21/32と43DC:0A21:C/34のアドレス接頭語の両方のNEARNetのルータに広告を出します。 NEARNetを通して43DC:0A21:8/34アドレス接頭語に合っている目的地に流れる交通はA1にSURANetを入れるでしょう、43DC:0A21:C/34アドレス接頭語に合っている目的地への交通がA2にSURANetを入れるでしょうが。
Note that the advertisement by the direct provider of the routing information associated with each subdivision must be done with care to ensure that such an advertisement would not result in a global distribution of separate reachability information associated with each subdivision, unless such distribution is warranted for some
そのような広告が各下位区分に関連している別々の可到達性情報のグローバルな分配をもたらさないのを保証するために各下位区分に関連しているルーティング情報のダイレクトプロバイダーで慎重に広告しなければならないことに注意してください、そのような分配がいくつかのために保証されない場合
Rekhter & Li Informational [Page 11] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[11ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
other purposes (e.g., supporting certain aspects of policy-based routing).
他の目的(例えば、方針ベースのルーティングのある一定の局面を支持します)。
4.3.2 Indirect Providers (Backbones)
4.3.2 間接的なプロバイダー(背骨)
There does not at present appear to be a strong case for direct providers to take their address spaces from the the IPv6 space of an indirect provider (e.g., backbone). The benefit in routing data abstraction is relatively small. The number of direct providers today is in the tens and an order of magnitude increase would not cause an undue burden on the backbones. Also, it may be expected that as time goes by there will be increased direct interconnection of the direct providers, leaf routing domains directly attached to the backbones, and international links directly attached to the providers. Under these circumstances, the distinction between direct and indirect providers may become blurred.
ダイレクトプロバイダーが間接的なプロバイダー(例えば、背骨)のIPv6スペースからそれらのアドレス空間を取る強いケースは現在のところ、あるように見えません。 ルーティングデータ抽象化による利益は比較的わずかです。 今日、10にはダイレクトプロバイダーの数があります、そして、桁の増加は背骨の不当な負担を引き起こさないでしょう。 また、時間がそこに過ぎるとき、それはダイレクトプロバイダーの増加するダイレクトインタコネクトになるでしょう、直接背骨に付けられた葉の経路ドメインと予想されたかもしれなくて、国際的な関係は直接プロバイダーに付きました。 こういう事情ですから、ダイレクトで間接的なプロバイダーの区別はぼけるようになるかもしれません。
An additional factor that discourages allocation of IPv6 addresses from a backbone prefix is that the backbones and their attached providers are perceived as being independent. Providers may take their long-haul service from one or more backbones, or may switch backbones should a more cost-effective service be provided elsewhere. Having IPv6 addresses derived from a backbone is inconsistent with the nature of the relationship.
背骨接頭語からのIPv6アドレスの配分に水をさしている追加要素は背骨とそれらの付属プロバイダーが独立しているとして知覚されるということです。 プロバイダーは、1つ以上の背骨から彼らの長期サービスを取るか、または、より費用対効果に優れたサービスをほかの場所に提供するなら、背骨を切り換えるかもしれません。 背骨からIPv6アドレスを得させるのは関係の本質に矛盾しています。
4.4 Multi-homed Routing Domains
4.4、マルチ、家へ帰り、経路ドメイン
The discussions in Section 4.3 suggest methods for allocating IPv6 addresses based on direct or indirect provider connectivity. This allows a great deal of information reduction to be achieved for those routing domains which are attached to a single TRD. In particular, such routing domains may select their IPv6 addresses from a space delegated to them by the direct provider. This allows the provider, when announcing the addresses that it can reach to other providers, to use a single address prefix to describe a large number of IPv6 addresses corresponding to multiple routing domains.
セクション4.3における議論は直接の、または、間接的なプロバイダーの接続性に基づくアドレスをIPv6に割り当てるための方法を示します。 これは、大きな情報減少が独身のTRDに付けられているそれらの経路ドメインに達成されるのを許容します。 特に、そのような経路ドメインはダイレクトプロバイダーによってそれらへ代表として派遣されたスペースからのそれらのIPv6アドレスを選択するかもしれません。 複数の経路ドメインに対応する多くのIPv6アドレスについて説明するのにただ一つのアドレス接頭語を使用するために、それが他のプロバイダーに達することができるアドレスを発表するとき、これはプロバイダーを許容します。
However, there are additional considerations for routing domains which are attached to multiple providers. Such `multi-homed' routing domains may, for example, consist of single-site campuses and companies which are attached to multiple backbones, large organizations which are attached to different providers at different locations in the same country, or multi-national organizations which are attached to backbones in a variety of countries worldwide. There
しかしながら、複数のプロバイダーに付けられている経路ドメインへの追加問題があります。 そのようなもの、'、マルチ、家へ帰り、'例えば、経路ドメインはただ一つのサイトキャンパスと複数の背骨に付けられている会社か、同じ国で別の場所の異なったプロバイダーに付けられている大きな組織か、世界中のさまざまな国の背骨に付けられている多国籍の組織から成るかもしれません。 そこでは
Rekhter & Li Informational [Page 12] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[12ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
are a number of possible ways to deal with these multi-homed routing domains.
多くの可能な道がこれらに対処することになっている、マルチ、家へ帰り、経路ドメイン。
4.4.1 Solution 1
4.4.1 ソリューション1
One possible solution is for each multi-homed organization to obtain its IPv6 address space independently of the providers to which it is attached. This allows each multi-homed organization to base its IPv6 assignments on a single prefix, and to thereby summarize the set of all IPv6 addresses reachable within that organization via a single prefix. The disadvantage of this approach is that since the IPv6 address for that organization has no relationship to the addresses of any particular TRD, the TRDs to which this organization is attached will need to advertise the prefix for this organization to other providers. Other providers (potentially worldwide) will need to maintain an explicit entry for that organization in their routing tables.
1つの可能な解決策がそれぞれのためのものである、マルチ、家へ帰り、それが付けているプロバイダーの如何にかかわらずIPv6アドレス空間を得る組織。 これがそれぞれを許容する、マルチ、家へ帰り、IPv6課題をただ一つの接頭語に基礎づけて、その結果ただ一つの接頭語を通してその組織の中で届いているすべてのIPv6アドレスのセットをまとめる組織。 このアプローチの不都合はその組織のためのIPv6アドレスにはどんな特定のTRDのアドレスとの関係も全くないのでこの組織が付けているTRDsが、この組織のために他のプロバイダーに接頭語の広告を出す必要があるということです。 他のプロバイダー(潜在的に世界的な)は、その組織のためにそれらの経路指定テーブルで明白なエントリーを維持する必要があるでしょう。
For example, suppose that a very large North American company `Mega Big International Incorporated' (MBII) has a fully interconnected internal network and is assigned a single prefix as part of the North American prefix. It is likely that outside of North America, a single entry may be maintained in routing tables for all North American Destinations. However, within North America, every provider will need to maintain a separate address entry for MBII. If MBII is in fact an international corporation, then it may be necessary for every provider worldwide to maintain a separate entry for MBII (including backbones to which MBII is not attached). Clearly this may be acceptable if there are a small number of such multi-homed routing domains, but would place an unacceptable load on routers within backbones if all organizations were to choose such address assignments. This solution may not scale to internets where there are many hundreds of thousands of multi-homed organizations.
例えば、非常に大きい北米の会社の'メガのBigの国際Incorporated'(MBII)は完全にインタコネクトされた内部のネットワークを持って、北米の接頭語の一部としてただ一つの接頭語を割り当てられると仮定してください。 北アメリカの外では、単一のエントリーがすべての北米のDestinationsのために経路指定テーブルで維持されそうです。 しかしながら、北アメリカの中では、あらゆるプロバイダーが、MBIIのために別々のアドレスエントリーを維持する必要があるでしょう。 事実上、MBIIが国際会社であるなら、世界中のあらゆるプロバイダーがMBIIのために別々のエントリーを維持するのが必要であるかもしれません(どのMBIIに背骨を含めるかは付属していません)。 少ない数のそのようなものがあれば明確に、これが許容できるかもしれない、マルチ、家へ帰り、すべての組織がそのようなアドレス課題を選ぶなら背骨の中に容認できない負荷をルータに置くのを除いた経路ドメイン。 この解決策がインターネットに多くの何十万があるところに比例しないかもしれない、マルチ、家へ帰り、組織。
4.4.2 Solution 2
4.4.2 ソリューション2
A second possible approach would be for multi-homed organizations to be assigned a separate IPv6 address space for each connection to a TRD, and to assign a single prefix to some subset of its domain(s) based on the closest interconnection point. For example, if MBII had connections to two providers in the U.S. (one east coast, and one west coast), as well as three connections to national backbones in Europe, and one in the far east, then MBII may make use of six different address prefixes. Each part of MBII would be assigned a
2番目の可能なアプローチがあるだろう、マルチ、家へ帰り、別々のIPv6アドレス空間が各接続のためにTRDに割り当てられて、ドメインの何らかの部分集合にただ一つの接頭語を割り当てる組織は最も近いインタコネクトポイントを基礎づけました。 例えば、そして、MBIIに接続が米国(1つの東海岸、および1つの西海岸)に2つのプロバイダーまであったなら、ヨーロッパの国家の背骨、および遠い東の1つの3つの接続対接続と同様に、MBIIは6つの異なったアドレス接頭語を利用するかもしれません。 aはMBIIの各部分に割り当てられるでしょう。
Rekhter & Li Informational [Page 13] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[13ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
single address prefix based on the nearest connection.
ただ一つのアドレス接頭語は接続を最も近づくことに基礎づけました。
For purposes of external routing of traffic from outside MBII to a destination inside of MBII, this approach works similarly to treating MBII as six separate organizations. For purposes of internal routing, or for routing traffic from inside of MBII to a destination outside of MBII, this approach works the same as the first solution.
MBIIからMBIIの目的地内部までの交通の外部のルーティングの目的に、このアプローチは同様に6つの独立した組織団体としてMBIIを扱うのに効き目があります。 内部のルーティングの目的、またはMBIIの内部から目的地までMBIIの外に交通を発送するのに、このアプローチは最初の解決策として同じように効き目があります。
If we assume that incoming traffic (coming from outside of MBII, with a destination within MBII) is always to enter via the nearest point to the destination, then each TRD which has a connection to MBII needs to announce to other TRDs the ability to reach only those parts of MBII whose address is taken from its own address space. This implies that no additional routing information needs to be exchanged between TRDs, resulting in a smaller load on the inter-domain routing tables maintained by TRDs when compared to the first solution. This solution therefore scales better to extremely large internets containing very large numbers of multi-homed organizations.
私たちが、入って来る交通(MBIIの外部から、MBIIの中に目的地がある状態で、来る)が目的地への最も近いポイントでいつも入ることであると思うなら、MBIIには接続がある各TRDは、アドレスがそれ自身のアドレス空間から取られるMBIIのそれらの部分だけに達する能力を他のTRDsに発表する必要があります。 これは、どんな追加ルーティング情報も、TRDsの間で交換される必要でないのを含意します、最初の解決策と比べるとTRDsによって維持された相互ドメイン経路指定テーブルで、よりわずかな負荷をもたらして。 したがって、この解決策が非常に大きい数を含む非常に大きいインターネットによりよく比例する、マルチ、家へ帰り、組織。
One problem with the second solution is that backup routes to multi- homed organizations are not automatically maintained. With the first solution, each TRD, in announcing the ability to reach MBII, specifies that it is able to reach all of the hosts within MBII. With the second solution, each TRD announces that it can reach all of the hosts based on its own address prefix, which only includes some of the hosts within MBII. If the connection between MBII and one particular TRD were severed, then the hosts within MBII with addresses based on that TRD would become unreachable via inter-domain routing. The impact of this problem can be reduced somewhat by maintenance of additional information within routing tables, but this reduces the scaling advantage of the second approach.
2番目の解決策に関する、ある問題がそのバックアップルートである、マルチ、家へ帰り、組織は自動的に維持されません。 最初の解決策で、MBIIに達する能力を発表する際に、各TRDは、MBIIの中でホストに皆、達することができると指定します。 2番目の解決策で、各TRDは、MBIIの中に何人かのホストを含んでいるだけであるそれ自身のアドレス接頭語に基づくホストのすべてに達することができると発表します。 MBIIと1特定のTRDとの接続が断ち切られるなら、そのTRDに基づくアドレスがあるMBIIの中のホストは相互ドメインルーティングで手が届かなくなるでしょうに。 この問題の影響は経路指定テーブルの中でいくらか追加情報の維持で減少できますが、これは2番目のアプローチのスケーリング利点を減少させます。
The second solution also requires that when external connectivity changes, internal addresses also change.
また、2番目の解決策は、また、外部の接続性が変化するとき内部のアドレスが変化するのを必要とします。
Also note that this and the previous approach will tend to cause packets to take different routes. With the first approach, packets from outside of MBII destined for within MBII will tend to enter via the point which is closest to the source (which will therefore tend to maximize the load on the networks internal to MBII). With the second solution, packets from outside destined for within MBII will tend to enter via the point which is closest to the destination (which will tend to minimize the load on the networks within MBII, and maximize the load on the TRDs).
また、これと前のアプローチが、パケットが異なったルートを取ることを引き起こす傾向があることに注意してください。 最初のアプローチで、MBIIの中で運命づけられたMBIIの外部からのパケットは、ソース(したがって、MBIIへの内部のネットワークで負荷を最大にする傾向がある)の最も近くにあるポイントで入る傾向があるでしょう。 2番目の解決策で、MBIIの中で運命づけられた外部からのパケットは、目的地(MBIIの中のネットワークで負荷を最小にして、TRDsで負荷を最大にする傾向がある)の最も近くにあるポイントで入る傾向があるでしょう。
These solutions also have different effects on policies. For example, suppose that country `X' has a law that traffic from a source within country X to a destination within country X must at all times stay
また、これらの解決策は異なった影響を方針に与えます。 例えば、国'X'には国Xの中のソースから国Xの中の目的地までの交通がいつも残らなければならないという法があると仮定してください。
Rekhter & Li Informational [Page 14] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[14ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
entirely within the country. With the first solution, it is not possible to determine from the destination address whether or not the destination is within the country. With the second solution, a separate address may be assigned to those hosts which are within country X, thereby allowing routing policies to be followed. Similarly, suppose that `Little Small Company' (LSC) has a policy that its packets may never be sent to a destination that is within MBII. With either solution, the routers within LSC may be configured to discard any traffic that has a destination within MBII's address space. However, with the first solution this requires one entry; with the second it requires many entries and may be impossible as a practical matter.
完全に国内で。 最初の解決策では、送付先アドレスから国の中に目的地があるかどうか決定するのは可能ではありません。 2番目の解決策で、別々のアドレスはそれらのホストに割り当てられるかもしれません(国Xの中にあります)、その結果、ルーティング方針が従われるのを許容します。 同様に、その'小さいSmall社'(LSC)にパケットが決して送られないかもしれない方針があるなら、MBIIの中に目的地には、それがいます。 解決策で、LSCの中のルータは、MBIIのアドレス空間の中に目的地を持っているどんな交通も捨てるために構成されるかもしれません。 しかしながら、最初の解決策で、これは1つのエントリーを必要とします。 2番目では、それは、多くのエントリーを必要として、実際問題として不可能であるかもしれません。
4.4.3 Solution 3
4.4.3 ソリューション3
There are other possible solutions as well. A third approach is to assign each multi-homed organization a single address prefix, based on one of its connections to a TRD. Other TRDs to which the multi- homed organization are attached maintain a routing table entry for the organization, but are extremely selective in terms of which other TRDs are told of this route. This approach will produce a single `default' routing entry which all TRDs will know how to reach (since presumably all TRDs will maintain routes to each other), while providing more direct routing in some cases.
また、他の可能な解決策があります。 3番目のアプローチがそれぞれを割り当てることである、マルチ、家へ帰り、TRDとの接続のひとりに基づいた組織のaただ一つのアドレス接頭語。 他のTRDs、どれ、マルチ、家へ帰り、付けられた組織は、組織のためにa経路指定テーブルエントリーを維持しますが、どの他のTRDsがこのルートについて言われるかに非常に選択しているか。 このアプローチはいくつかの場合、よりダイレクトなルーティングを提供している間、すべてのTRDsが、どのようにが達するかを(おそらくすべてのTRDsが互いにルートを維持するので)知っている単一の'デフォルト'ルーティングエントリーを起こすでしょう。
There is at least one situation in which this third approach is particularly appropriate. Suppose that a special interest group of organizations have deployed their own provider. For example, lets suppose that the U.S. National Widget Manufacturers and Researchers have set up a U.S.-wide provider, which is used by corporations who manufacture widgets, and certain universities which are known for their widget research efforts. We can expect that the various organizations which are in the widget group will run their internal networks as separate routing domains, and most of them will also be attached to other TRDs (since most of the organizations involved in widget manufacture and research will also be involved in other activities). We can therefore expect that many or most of the organizations in the widget group are dual-homed, with one attachment for widget-associated communications and the other attachment for other types of communications. Let's also assume that the total number of organizations involved in the widget group is small enough that it is reasonable to maintain a routing table containing one entry per organization, but that they are distributed throughout a larger internet with many millions of (mostly not widget-associated) routing domains.
この3番目のアプローチが特に適切である少なくとも1つの状況があります。 組織の特殊利益集団がそれら自身のプロバイダーを配備したと仮定してください。 例えば、米国National Widget ManufacturersとResearchersが米国全体のプロバイダーと彼らのウィジェット研究の努力で知られているある大学を設立したと思わせます。プロバイダーはウィジェットを製造している会社によって使用されます。 経路ドメインを切り離してください。そうすれば、また、それらの大部分が他のTRDsに付けられるとき(また、ウィジェット製造と研究にかかわる組織の大部分が他の活動にかかわるので)、私たちは、ウィジェットグループにはある様々な組織がそれらの内部のネットワークを経営していると予想できます。 したがって、私たちが、多くかウィジェットグループにおける組織の大部分がそうであると予想できる、二元的である、-、家へ帰り、ウィジェットで関連しているコミュニケーションに関する1つの付属と他のタイプのコミュニケーションに関するもう片方の付属をもって。 また、ウィジェットグループにかかわる組織の総数が1組織あたり1つのエントリーを含む経路指定テーブルを維持するのが妥当である、しかし、それらが、より大きいインターネット中で何百万もの(ウィジェットでほとんど関連しない)の経路ドメインで分配されるほどわずかであると仮定しましょう。
Rekhter & Li Informational [Page 15] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[15ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
With the third approach, each multi-homed organization in the widget group would make use of an address assignment based on its other attachment(s) to TRDs (the attachments not associated with the widget group). The widget provider would need to maintain routes to the routing domains associated with the various member organizations. Similarly, all members of the widget group would need to maintain a table of routes to the other members via the widget provider. However, since the widget provider does not inform other general worldwide TRDs of what addresses it can reach (since the provider is not intended for use by other outside organizations), the relatively large set of routing prefixes needs to be maintained only in a limited number of places. The addresses assigned to the various organizations which are members of the widget group would provide a `default route' via each members other attachments to TRDs, while allowing communications within the widget group to use the preferred path.
3番目はアプローチします、それぞれ、マルチ、家へ帰り、ウィジェットグループにおける組織がTRDs(ウィジェットグループに関連づけられなかった付属)への他の付属に基づくアドレス課題を利用するでしょう。 ウィジェットプロバイダーは、様々な会員会社に関連している経路ドメインにルートを維持する必要があるでしょう。 同様に、ウィジェットグループのすべてのメンバーが、ウィジェットプロバイダーで他のメンバーにルートのテーブルを維持する必要があるでしょう。 しかしながら、ウィジェットプロバイダーが、それにどんなアドレスに達することができるかを(プロバイダーが使用のために他の外の組織によって意図されないので)他の一般的な世界的なTRDsに知らせないので、比較的大きいセットのルーティング接頭語は、限られた数の場所だけで維持される必要があります。 ウィジェットグループの中のコミュニケーションが都合のよい経路を使用するのを許容している間、ウィジェットグループのメンバーである様々な組織に配属されたアドレスはそれぞれを通した'デフォルトルート'メンバーにTRDsへの他の付属を提供するでしょう。
4.4.4 Solution 4
4.4.4 ソリューション4
A fourth solution involves assignment of a particular address prefix for routing domains which are attached to precisely two (or more) specific routing domains. For example, suppose that there are two providers `SouthNorthNet' and `NorthSouthNet' which have a very large number of customers in common (i.e., there are a large number of routing domains which are attached to both). Rather than getting two address prefixes these organizations could obtain three prefixes. Those routing domains which are attached to NorthSouthNet but not attached to SouthNorthNet obtain an address assignment based on one of the prefixes. Those routing domains which are attached to SouthNorthNet but not to NorthSouthNet would obtain an address based on the second prefix. Finally, those routing domains which are multi-homed to both of these networks would obtain an address based on the third prefix. Each of these two TRDs would then advertise two prefixes to other TRDs, one prefix for leaf routing domains attached to it only, and one prefix for leaf routing domains attached to both.
4番目の解決策は正確に2つ(さらに)の特定の経路ドメインに付けられている経路ドメインに特定のアドレス接頭語の課題にかかわります。 例えば、非常に多くの顧客が共通である2つのプロバイダー'SouthNorthNet'と'NorthSouthNet'があると仮定してください(すなわち、両方に付けられている多くの経路ドメインがあります)。 2つのアドレス接頭語を得るよりむしろ、これらの組織は3つの接頭語を得ることができました。 NorthSouthNetに付けられていますが、SouthNorthNetに付けられていないそれらの経路ドメインは接頭語の1つに基づくアドレス課題を得ます。 SouthNorthNetに付けられていますが、NorthSouthNetに付けられるというわけではないそれらの経路ドメインは2番目の接頭語に基づくアドレスを得るでしょう。 最終的にそうするそれらの経路ドメイン、マルチ、家へ帰り、3番目の接頭語に基づくアドレスをこれらのネットワークの両方に得るでしょう。 次に、それぞれのこれらの2TRDsが他のTRDsに2つの接頭語の広告を出すでしょう、そして、葉の経路ドメインへの1つの接頭語がそれだけに付きました、そして、葉の経路ドメインへの1つの接頭語が両方に付きました。
This fourth solution is likely to be important when use of public data networks becomes more common. In particular, it is likely that at some point in the future a substantial percentage of all routing domains will be attached to public data networks. In this case, nearly all government-sponsored networks (such as some current regionals) may have a set of customers which overlaps substantially with the public networks.
この4番目の解決策は公衆データネットワークの使用が、より一般的になるとき、重要である傾向があります。 未来の何らかのポイントでは、特に、すべての経路ドメインのかなりの割合が公衆データネットワークに付けられそうでしょう。 この場合、ほとんどすべての政府によって後援されたネットワーク(いくつかの現在の地方版などの)には、実質的に公衆通信回線に重なる顧客のセットがあるかもしれません。
Rekhter & Li Informational [Page 16] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[16ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
4.4.5 Summary
4.4.5 概要
There are therefore a number of possible solutions to the problem of assigning IPv6 addresses to multi-homed routing domains. Each of these solutions has very different advantages and disadvantages. Each solution places a different real (i.e., financial) cost on the multi-homed organizations, and on the TRDs (including those to which the multi-homed organizations are not attached).
したがって、アドレスをIPv6に割り当てるという問題の多くの可能な解決がある、マルチ、家へ帰り、経路ドメイン。 それぞれのこれらの解決策には、非常に異なった利点と損失があります。 各解決策が異なった本当(すなわち、財政的な)の費用を置く、マルチ、家へ帰り、組織、TRDs、(それらを含んでいる、どれ、マルチ、家へ帰り、付けられなかった組織)
In addition, most of the solutions described also highlight the need for each TRD to develop a policy on whether and under what conditions to accept addresses that are not based on its own address prefix, and how such non-local addresses will be treated. For example, a somewhat conservative policy might be that non-local IPv6 address prefixes will be accepted from any attached leaf routing domain, but not advertised to other TRDs. In a less conservative policy, a TRD might accept such non-local prefixes and agree to exchange them with a defined set of other TRDs (this set could be an a priori group of TRDs that have something in common such as geographical location, or the result of an agreement specific to the requesting leaf routing domain). Various policies involve real costs to TRDs, which may be reflected in those policies.
また、さらに、説明された解決策の大部分は扱われて自分自身のが基づいていないアドレスがオンであると受け入れるどんな条件のもとで接頭語を記述するか、そして、そのような非ローカルのアドレスがどのように扱われるかに各TRDが政策を立てる必要性を強調します。 例えば、いくらか保守的な方針は非ローカルのIPv6アドレス接頭語がどんな付属葉の経路ドメインからも受け入れますが、他のTRDsに広告を出さないということであるかもしれません。 それほど保守的でない方針で、TRDは、そのような非ローカルの接頭語を受け入れて、他のTRDsの定義されたセットとそれらを交換するのに同意するかもしれません(このセットは地理的な位置、またはドメインを発送する要求葉に特定の協定の結果などのように一脈相通じるものがあるTRDsの先験的なグループであるかもしれません)。 様々な方針は本当のコストをTRDsに伴います。(TRDsはそれらの方針に反映されるかもしれません)。
4.5 Private Links
4.5 個人的なリンク
The discussion up to this point concentrates on the relationship between IPv6 addresses and routing between various routing domains over transit routing domains, where each transit routing domain interconnects a large number of routing domains and offers a more- or-less public service.
議論がこの時点までにそれぞれのトランジット経路ドメインが多くの経路ドメインとインタコネクトして、aをさらに提供するトランジット経路ドメインの上の様々な経路ドメインの間のIPv6アドレスとルーティングとの関係に集中する、なし、社会奉仕。
However, there may also exist a number of links which interconnect two routing domains in such a way, that usage of these links may be limited to carrying traffic only between the two routing domains. We'll refer to such links as "private".
しかしながら、また、そのような方法で2つの経路ドメインとインタコネクトする多くのリンクが存在するかもしれなくて、これらのリンクのその使用法は2つの経路ドメインだけの間の交通を運ぶのに制限されるかもしれません。 私たちは「個人的」のようなリンクについて言及するつもりです。
For example, let's suppose that the XYZ corporation does a lot of business with MBII. In this case, XYZ and MBII may contract with a carrier to provide a private link between the two corporations, where this link may only be used for packets whose source is within one of the two corporations, and whose destination is within the other of the two corporations. Finally, suppose that the point-to-point link is connected between a single router (router X) within XYZ corporation and a single router (router M) within MBII. It is therefore necessary to configure router X to know which addresses can
例えば、XYZ会社がMBIIと多くビジネスをすると思いましょう。 この場合、XYZとMBIIは、キャリヤーで2つの会社の間の個人的なリンクを提供するのを契約するかもしれません。そこでは、このリンクが2つの会社の1つの中にソースがあって、2つの会社のもう片方の中に目的地があるパケットに使用されるだけであるかもしれません。 最終的に、ポイントツーポイント接続がXYZ会社の中のただ一つのルータ(ルータX)とMBIIの中のただ一つのルータ(ルータM)の間で接続されると仮定してください。 したがって、どのアドレスがそうすることができるかを知るためにルータXを構成するのが必要です。
Rekhter & Li Informational [Page 17] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[17ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
be reached over this link (specifically, all addresses reachable in MBII). Similarly, it is necessary to configure router M to know which addresses can be reached over this link (specifically, all addresses reachable in XYZ Corporation).
このリンク(明確にMBIIで届いているすべてのアドレス)の上に達してください。 同様に、どのアドレスにこのリンク(明確にXYZ社で届いているすべてのアドレス)の上に達することができるかを知るためにルータMを構成するのが必要です。
The important observation to be made here is that the additional connectivity due to such private links may be ignored for the purpose of IPv6 address allocation, and do not pose a problem for routing on a larger scale. This is because the routing information associated with such connectivity is not propagated throughout the internet, and therefore does not need to be collapsed into a TRD's prefix.
ここでされる重要な観測はそのような個人的なリンクによる追加接続性がIPv6アドレス配分の目的のために無視されて、ルーティングのために、より大きいスケールに問題を設定しないかもしれないということです。 これはそのような接続性に関連しているルーティング情報によってインターネット中で伝播されないで、したがって、TRDの接頭語まで潰される必要はないからです。
In our example, let's suppose that the XYZ corporation has a single connection to a regional, and has therefore uses the IPv6 address space from the space given to that regional. Similarly, let's suppose that MBII, as an international corporation with connections to six different providers, has chosen the second solution from Section 4.4, and therefore has obtained six different address allocations. In this case, all addresses reachable in the XYZ Corporation can be described by a single address prefix (implying that router M only needs to be configured with a single address prefix to represent the addresses reachable over this link). All addresses reachable in MBII can be described by six address prefixes (implying that router X needs to be configured with six address prefixes to represent the addresses reachable over the link).
私たちの例では、XYZ会社が地方版に単独結合を持っていて、したがって、持っていたと思いましょう。与えられたスペースからそれまで地方でIPv6アドレス空間を使用します。 同様に、MBIIが6つの異なったプロバイダーとの接続がある国際会社としてセクション4.4から2番目の解決策を選んで、したがって、6つの異なったアドレス配分を得たと思いましょう。 この場合、ただ一つのアドレス接頭語(ルータMがただ一つのアドレス接頭語によって構成されて、このリンクの上に届いているアドレスを表す必要であるだけであるのを含意する)でXYZ社で届いているすべてのアドレスについて説明できます。 6つのアドレス接頭語(ルータXが6つのアドレス接頭語によって構成されて、リンクの上に届いているアドレスを表す必要であるのを含意する)でMBIIで届いているすべてのアドレスについて説明できます。
In some cases, such private links may be permitted to forward traffic for a small number of other routing domains, such as closely affiliated organizations. This will increase the configuration requirements slightly. However, provided that the number of organizations using the link is relatively small, then this still does not represent a significant problem.
いくつかの場合、そのような個人的なリンクが他の少ない数の経路ドメインのための交通を進めることが許可されるかもしれません、密接に合併された組織などのように。 これは構成必要条件をわずかに増加させるでしょう。 しかしながら、リンクを使用する組織の数が比較的少なければ、これはまだ重大な問題を表していません。
Note that the relationship between routing and IPv6 addressing described in other sections of this paper is concerned with problems in scaling caused by large, essentially public transit routing domains which interconnect a large number of routing domains. However, for the purpose of IPv6 address allocation, private links which interconnect only a small number of private routing domains do not pose a problem, and may be ignored. For example, this implies that a single leaf routing domain which has a single connection to a `public' provider (e.g., the Alternet), plus a number of private links to other leaf routing domains, can be treated as if it were single-homed to the provider for the purpose of IPv6 address allocation. We expect that this is also another way of dealing with multi-homed domains.
この紙の他のセクションで説明されたルーティングとIPv6アドレシングとの関係は多くの経路ドメインとインタコネクトする大きくて、本質的には公共のトランジット経路ドメインによって引き起こされたスケーリングで問題に関係があることに注意してください。 しかしながら、少ない数の個人的な経路ドメインだけとインタコネクトする個人的なリンクは、IPv6アドレス配分の目的のために、問題を設定しないで、無視されるかもしれません。 例えば、これは、まるでそれがIPv6アドレス配分を目的のためのプロバイダーとシングル家へ帰らせるかのように'公共'のプロバイダー(例えば、Alternet)、および他の葉の経路ドメインへの多くの個人的なリンクに単独結合を持っている単葉経路ドメインは扱うことができるのを含意します。 私たちが、また、これが取扱いの別の方法であると予想する、マルチ、家へ帰り、ドメイン。
Rekhter & Li Informational [Page 18] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[18ページ]のRFC1887IPv6Unicastは構造1995年12月に配分を記述します。
4.6 Zero-Homed Routing Domains
4.6、無、家へ帰り、経路ドメイン
Currently, a very large number of organizations have internal communications networks which are not connected to any service providers. Such organizations may, however, have a number of private links that they use for communications with other organizations. Such organizations do not participate in global routing, but are satisfied with reachability to those organizations with which they have established private links. These are referred to as zero-homed routing domains.
現在、非常に多くの組織には、どんなサービスプロバイダーにも接続されない内部の通信網があります。 しかしながら、そのような組織は多くのそれらが他の組織とのコミュニケーションに使用する個人的なリンクを持っているかもしれません。 そのような組織は、グローバルなルーティングに参加しませんが、それらと個人的なリンクを設立したそれらの組織への可到達性に満たされています。 これらが呼ばれる、無、家へ帰り、経路ドメイン。
Zero-homed routing domains can be considered as the degenerate case of routing domains with private links, as discussed in the previous section, and do not pose a problem for inter-domain routing. As above, the routing information exchanged across the private links sees very limited distribution, usually only to the routing domain at the other end of the link. Thus, there are no address abstraction requirements beyond those inherent in the address prefixes exchanged across the private link.
無、家へ帰り、経路ドメインは、前項で議論するように個人的なリンクがある経路ドメインの堕落したケースであるとみなすことができて、相互ドメインルーティングのために問題を設定しません。 同じくらい上では、個人的なリンクの向こう側に交換されたルーティング情報が非常に限られた分配を見ます、通常リンクのもう一方の端の経路ドメインだけに。 したがって、アドレス抽象化要件は全く個人的なリンクの向こう側に交換されたアドレス接頭語に固有のそれらを超えていません。
However, it is important that zero-homed routing domains use valid globally unique IPv6 addresses. Suppose that the zero-homed routing domain is connected through a private link to a routing domain. Further, this routing domain participates in an internet that subscribes to the global IPv6 addressing plan. This domain must be able to distinguish between the zero-homed routing domain's IPv6 addresses and any other IPv6 addresses that it may need to route to. The only way this can be guaranteed is if the zero-homed routing domain uses globally unique IPv6 addresses.
しかしながら、それが重要である、それ、無、家へ帰り、経路ドメインは有効なグローバルにユニークなIPv6アドレスを使用します。 それを仮定してください、無、家へ帰り、経路ドメインは経路ドメインへの個人的なリンクを通してつなげられます。 さらに、この経路ドメインはグローバルなIPv6アドレシングプランに加入するインターネットに参加します。 このドメインが見分けることができなければならない、無、家へ帰り、ドメインのIPv6アドレスとそれが発送する必要があるかもしれないいかなる他のIPv6アドレスも発送します。 これを保証できる唯一の方法がそうである、無、家へ帰り、経路ドメインはグローバルにユニークなIPv6アドレスを使用します。
Whereas globally unique addresses are necessary to differentiate between destinations in the Internet, globally unique addresses may not be sufficient to guarantee global connectivity. If a zero-homed routing domain gets connected to the Internet, the block of addresses used within the domain may not be related to the block of addresses allocated to the domain's direct provider. In order to maintain the gains given by hierarchical routing and address assignment the zero- homed domain should under such circumstances change addresses assigned to the systems within the domain.
グローバルにユニークなアドレスがインターネットで目的地を区別するのに必要ですが、グローバルにユニークなアドレスは、グローバルな接続性を保証するために十分でないかもしれません。 aである、無、家へ帰り、経路ドメインはインターネットに関連づけられて、ドメインの中で使用されたアドレスのブロックはドメインのダイレクトプロバイダーに割り当てられたアドレスのブロックに関連しないかもしれません。 階層型ルーティングとアドレス課題で与えられた利得を維持する、無、家へ帰り、ドメインはこれではドメインの中のシステムに割り当てられたアドレスを変えるべきです。
4.7 Continental aggregation
4.7 大陸の集合
Another level of hierarchy may also be used in this addressing scheme to further reduce the amount of routing information necessary for
また、別のレベルの階層構造は、必要な状態でルーティング情報の量をさらに減少させるのにこのアドレシング体系に使用されるかもしれません。
Rekhter & Li Informational [Page 19] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[19ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
global routing. Continental aggregation is useful because continental boundaries provide natural barriers to topological connection and administrative boundaries. Thus, it presents a natural boundary for another level of aggregation of inter-domain routing information. To make use of this, it is necessary that each continent be assigned an appropriate contiguous block of addresses. Providers (both direct and indirect) within that continent would allocate their addresses from this space. Note that there are numerous exceptions to this, in which a service provider (either direct or indirect) spans a continental division. These exceptions can be handled similarly to multi-homed routing domains, as discussed above.
グローバルなルーティング。 大陸の境界が位相的な接続と管理境界に天然バリアを提供するので、大陸の集合は役に立ちます。 したがって、それは別のレベルの相互ドメインルーティング情報の集合のために固有の境界を提示します。 これを利用するために、アドレスの適切な隣接のブロックが各大陸に割り当てられるのが必要です。 その大陸の中のプロバイダー(ダイレクトものと同様に間接的な)はこのスペースからそれらのアドレスを割り当てるでしょう。 これへの多数の例外があることに注意してください。(そこでは、サービスプロバイダー(直接の、または、間接的な)は大陸の分割にかかります)。 同様にこれらの例外を扱うことができる、マルチ、家へ帰り、上で議論するようにドメインを発送します。
The benefit of continental aggregation is that it helps to absorb the entropy introduced within continental routing caused by the cases where an organization must use an address prefix which must be advertised beyond its direct provider. In such cases, if the address is taken from the continental prefix, the additional cost of the route is not propagated past the point where continental aggregation takes place.
大陸の集合の利益は組織がダイレクトプロバイダーの広告に掲載しなければならないアドレス接頭語を使用しなければならないケースによって引き起こされた大陸のルーティングの中で導入されたエントロピーを吸収するのを助けるということです。 そのような場合、大陸の接頭語からアドレスを取るなら、大陸の集合が行われるポイントの先でルートの別途費用を伝播しません。
Note that, in contrast to the case of providers, the aggregation of continental routing information may not be done on the continent to which the prefix is allocated. The cost of inter-continental links (and especially trans-oceanic links) is very high. If aggregation is performed on the `near' side of the link, then routing information about unreachable destinations within that continent can only reside on that continent. Alternatively, if continental aggregation is done on the `far' side of an inter-continental link, the `far' end can perform the aggregation and inject it into continental routing. This means that destinations which are part of the continental aggregation, but for which there is not a corresponding more specific prefix can be rejected before leaving the continent on which they originated.
プロバイダーに関するケースと対照して接頭語が割り当てられる大陸で大陸のルーティング情報の集合をしないかもしれないことに注意してください。 大陸間リンク(そして、特に移-海洋のリンク)の費用は非常に高いです。 集合がリンクの'近い'側面に実行されるなら、その大陸の中の手の届かない目的地のルーティング情報はその大陸にあることができるだけです。 あるいはまた、大陸間リンクの'遠い'側面で大陸の集合をするなら、'遠い'終わりは、集合を実行して、大陸のルーティングにそれを注ぐことができます。 これは、それらが起因した大陸を出る前に大陸の集合の一部ですが、どれが対応するより特定の接頭語がないか一部である目的地は拒絶できることを意味します。
For example, suppose that Europe is assigned a prefix of 46/8, such that European routing also contains the longer prefixes 46DC:0A01/32 and 46DC:0A02/32 . All of the longer European prefixes may be advertised across a trans-Atlantic link to North America. The router in North America would then aggregate these routes, and only advertise the prefix 46/8 into North American routing. Packets which are destined for 46DC:0A01:1234:5678:ABCD:8765:4321:AABB would traverse North American routing, but would encounter the North American router which performed the European aggregation. If the prefix 46DC:0A01/32 is unreachable, the router would drop the packet and send an unreachable message without using the trans-Atlantic link.
例えば、46/8の接頭語がヨーロッパに割り当てられると仮定してください、また、ヨーロッパのルーティングが、より長い接頭語の46DC: 0A01/32と46DC: 0A02/32を含むように。北アメリカへの大西洋横断のリンクの向こう側により長いヨーロッパの接頭語のすべての広告を出すかもしれません。 北アメリカのルータは、次に、これらのルートに集めて、北米のルーティングに接頭語46/8の広告を出すだけでしょう。 46DCのために運命づけられているパケット: 0A01: 1234:5678:ABCD: 8765:4321:AABBは北米のルーティングを横断するでしょうが、ヨーロッパの集合を実行した北米のルータに遭遇するでしょう。 46DC: 接頭語0A01/32が手が届かないなら、大西洋横断のリンクを使用しないで、ルータは、パケットを下げて、手の届かないメッセージを送るでしょう。
Rekhter & Li Informational [Page 20] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[20ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
4.8 Private (Local Use) Addresses
4.8 個人的な(地方の使用)アドレス
Many domains will have hosts which, for one reason or another, will not require globally unique IPv6 addresses. A domain which decides to use IPv6 addresses out of the private address space is able to do so without address allocation from any authority. Conversely, the private address prefix need not be advertised throughout the public portion of the Internet.
多くのドメインには、ホストがいるでしょう(何らかの理由のために、グローバルにユニークなIPv6アドレスを必要としないでしょう)。 プライベート・アドレススペースからIPv6アドレスを使用すると決めるドメインはどんな権威からもアドレス配分なしでそうすることができます。 逆に、インターネットの公共の部分中にプライベート・アドレス接頭語の広告を出す必要はありません。
In order to use private address space, a domain needs to determine which hosts do not need to have network layer connectivity outside the domain in the foreseeable future. Such hosts will be called private hosts, and may use the private addresses described above if it is topologically convenient. Private hosts can communicate with all other hosts inside the domain, both public and private. However, they cannot have IPv6 connectivity to any external host. While not having external network layer connectivity, a private host can still have access to external services via application layer relays. Public hosts do not have connectivity to private hosts outside of their own domain.
プライベート・アドレススペースを使用するために、ドメインは、どのホストがドメインの外ですぐにネットワーク層の接続性を必要としないかを決定する必要があります。 そのようなホストは、個人的なホストと呼ばれて、便利な状態でそれが位相的に説明されたなら上で説明されたプライベート・アドレスを使用するかもしれません。 個人的なホストは公共のものと同様に個人的なドメインの中の他のすべてのホストとコミュニケートできます。 しかしながら、彼らはどんな外部のホストにもIPv6の接続性を持つことができません。 外部のネットワーク層の接続性を持っていない間、応用層リレーで個人的なホストはまだ外部サービスに近づく手段を持つことができます。 公共のホストはそれら自身のドメインの外に個人的なホストに接続性を持っていません。
Because private addresses have no global meaning, reachability information associated with the private address space shall not be propagated on inter-domain links, and packets with private source or destination addresses should not be forwarded across such links. Routers in domains not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information that carries reachability information associated with private addresses. If such a router receives such information the rejection shall not be treated as a routing protocol error.
プライベート・アドレスにはどんなグローバルな意味もないので、相互ドメインリンクの上にプライベート・アドレススペースに関連している可到達性情報を伝播しないものとします、そして、そのようなリンクの向こう側に個人的なソースか送付先アドレスがあるパケットを進めるべきではありません。 プライベート・アドレスに関連している可到達性情報を運ぶルーティング情報を拒絶する(無視する)ためにプライベート・アドレススペースを使用しないドメインのルータ(特にインターネット接続サービス業者のもの)が構成されると予想されます。 そのようなルータがそのような情報を受け取るなら、ルーティング・プロトコル誤りとして拒絶を扱わないものとします。
In addition, indirect references to private addresses should be contained within the enterprise that uses these addresses. Prominent example of such references are DNS Resource Records. A possible approach to avoid leaking of DNS RRs is to run two nameservers, one external server authoritative for all globally unique IP addresses of the enterprise and one internal nameserver authoritative for all IP addresses of the enterprise, both public and private. In order to ensure consistency both these servers should be configured from the same data of which the external nameserver only receives a filtered version. The resolvers on all internal hosts, both public and private, query only the internal nameserver. The external server resolves queries from resolvers outside the enterprise and is linked into the global DNS. The internal server forwards all queries for information outside the enterprise to the external nameserver, so all internal hosts can access the global DNS. This ensures that
さらに、プライベート・アドレスの間接的な言及はこれらのアドレスを使用する企業の中に含まれるべきです。 そのような参照の際立った例はDNS Resource Recordsです。 DNS RRsを漏れさせるのを避ける可能なアプローチは企業のすべてのIPアドレスに正式で、かつ公共で、かつ個人的に2つのネームサーバ、企業のすべてのグローバルにユニークなIPアドレスに、正式の1つの外部のサーバ、および1つの内部のネームサーバを実行することです。 一貫性があることを保証するために、これらのサーバの両方が外部のネームサーバがフィルターにかけることのバージョンを受けるだけであるのと同じデータから構成されるべきです。 すべての内部のホストの上の公共の、そして、かつ個人的なレゾルバは、内部のネームサーバだけについて質問します。外部のサーバは、企業の外でレゾルバから質問を決議して、グローバルなDNSにリンクされます。 内部のサーバが外部のネームサーバへの企業の外に情報のためのすべての質問を送るので、すべての内部のホストがグローバルなDNSにアクセスできます。 これはそれを確実にします。
Rekhter & Li Informational [Page 21] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[21ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
information about private hosts does not reach resolvers and nameservers outside the enterprise.
個人的なホストの情報は企業の外でレゾルバとネームサーバに届きません。
4.9 Interaction with Policy Routing
4.9 方針ルート設定との相互作用
We assume that any inter-domain routing protocol will have difficulty trying to aggregate multiple destinations with dissimilar policies. At the same time, the ability to aggregate routing information while not violating routing policies is essential. Therefore, we suggest that address allocation authorities attempt to allocate addresses so that aggregates of destinations with similar policies can be easily formed.
私たちは、どんな相互ドメインルーティング・プロトコルも異なった方針で複数の目的地に集めようとするのに苦労すると思います。 同時に、ルーティング方針に違反していない間にルーティング情報に集める能力は不可欠です。 したがって、私たちは、アドレス配分当局が、容易に同様の方針がある目的地の集合を形成できるようにアドレスを割り当てるのを試みることを提案します。
5. Recommendations
5. 推薦
We anticipate that the current exponential growth of the Internet will continue or accelerate for the foreseeable future. In addition, we anticipate a rapid internationalization of the Internet. The ability of routing to scale is dependent upon the use of data abstraction based on hierarchical IPv6 addresses. It is therefore essential to choose a hierarchical structure for IPv6 addresses with great care.
私たちは、インターネットの現在の急激な増加が予見できる未来に続くか、または加速すると予期します。 さらに、私たちはインターネットの急速な国際化を予期します。 ルーティングが比例する能力は階層的なIPv6アドレスに基づくデータ抽象化の使用に依存しています。 したがって、IPv6アドレスのための階層構造を細心の注意を払って選ぶのは不可欠です。
Great attention must be paid to the definition of addressing structures to balance the conflicting goals of:
以下の闘争目標のバランスをとるのにアドレシング構造の定義にかなりの注意を向けなければなりません。
- Route optimality
- ルートの最適
- Routing algorithm efficiency
- ルーティング・アルゴリズム効率
- Ease and administrative efficiency of address registration
- アドレス登録の容易さと管理効率
- Considerations for what addresses are assigned by what addressing
authority
- どんなアドレスがどんなアドレシング権威によって割り当てられるか問題
It is in the best interests of the internetworking community that the cost of operations be kept to a minimum where possible. In the case of IPv6 address allocation, this again means that routing data abstraction must be encouraged.
インターネットワーキング共同体の利益のためでは、操作の費用が可能であるところで最小限に保たれるのは、そうです。 IPv6アドレス配分の場合では、これは、再びルーティングデータ抽象化を奨励しなければならないことを意味します。
In order for data abstraction to be possible, the assignment of IPv6 addresses must be accomplished in a manner which is consistent with the actual physical topology of the Internet. For example, in those cases where organizational and administrative boundaries are not
データ抽象化が可能であるように、インターネットの実際の物理的なトポロジーと一致した方法でIPv6アドレスの課題を実行しなければなりません。 例えば、それらの場合では、境界は組織的であって、管理であることのそうではありません。
Rekhter & Li Informational [Page 22] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[22ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
related to actual network topology, address assignment based on such organization boundaries is not recommended.
実際のネットワーク形態に関係づけられて、そのような組織境界に基づくアドレス課題は推薦されません。
The intra-domain routing protocols allow for information abstraction to be maintained within a domain. For zero-homed and single-homed routing domains (which are expected to remain zero-homed or single- homed), we recommend that the IPv6 addresses assigned within a single routing domain use a single address prefix assigned to that domain. Specifically, this allows the set of all IPv6 addresses reachable within a single domain to be fully described via a single prefix.
イントラドメインルーティング・プロトコルは、情報抽象化がドメインの中で維持されるのを許容します。 無、家へ帰り、ドメインを発送しながらシングル家へ帰る、(残っていると予想される、無、家へ帰り、シングルが家へ帰った、)、私たちは、IPv6アドレスがただ一つの経路ドメイン使用の中でそのドメインに割り当てられたただ一つのアドレス接頭語を割り当てたことを勧めます。 明確に、これは、単一領域の中で届いているすべてのIPv6アドレスのセットがただ一つの接頭語で完全に説明されるのを許容します。
We anticipate that the total number of routing domains existing on a worldwide Internet to be great enough that additional levels of hierarchical data abstraction beyond the routing domain level will be necessary.
私たちは、経路ドメインを超えた階層データ抽象化の追加レベルが平らにする十分すばらしくなるように世界的なインターネットに存在する経路ドメインの総数が必要になると予期します。
In most cases, network topology will have a close relationship with national boundaries. For example, the degree of network connectivity will often be greater within a single country than between countries. It is therefore appropriate to make specific recommendations based on national boundaries, with the understanding that there may be specific situations where these general recommendations need to be modified.
多くの場合、ネットワーク形態には、国境との密接な関係があるでしょう。 例えば、ネットワークの接続性の度合いは国より単一の国の中でしばしばさらに大きくなるでしょう。 したがって、国境に基づく特定の推薦状をするのは適切です、特定の状況がこれらの一般的な推薦が変更される必要があるところにあるかもしれないという条件で。
Further, from experience with IPv4, we feel that continental aggregation is beneficial and should be supported where possible as a means of limiting the unwarranted spread of routing exceptions.
さらに、私たちは、IPv4の経験から、大陸の集合が有益であると感じて、ルーティング例外の保証のない普及を制限する手段として可能であるところでサポートされるべきです。
5.1 Recommendations for an address allocation plan
アドレス配分のための5.1の推薦状が計画されています。
We anticipate that public interconnectivity between private routing domains will be provided by a diverse set of TRDs, including (but not necessarily limited to):
私たちは個人的な経路ドメインの間の公共の相互接続性にTRDsのさまざまのセットによって提供されて、含むのと(必ず有限であるというわけではない)であると予期します:
- Backbone networks;
- バックボーンネットワーク。
- A number of regional or national networks; and,
- 多くの地方の、または、国家のネットワーク。 そして
- A number of commercial Public Data Networks.
- 多くの商業Public Data Networks。
These networks will not be interconnected in a strictly hierarchical manner (for example, there is expected to be direct connectivity between regionals, and all of these types of networks may have direct international connections). These TRDs will be used to interconnect a wide variety of routing domains, each of which may comprise a single corporation, part of a corporation, a university campus, a
これらのネットワークは厳密に階層的な方法でインタコネクトされないでしょう(例えば、地方版の間でダイレクト接続性があると予想されます、そして、これらのタイプのネットワークのすべてには、ダイレクト国際的な接続があるかもしれません)。 これらのTRDsはそれのそれぞれが単一の会社を包括するかもしれないさまざまな経路ドメインとインタコネクトするのに使用されるでしょう、会社の一部、大学構内、a
Rekhter & Li Informational [Page 23] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[23ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
government agency, or other organizational unit.
政府機関、または他の組織的なユニット。
In addition, some private corporations may be expected to make use of dedicated private TRDs for communication within their own corporation.
さらに、いくつかの私法人がコミュニケーションにそれら自身の会社の中で専用個人的なTRDsを利用すると予想されるかもしれません。
We anticipate that the great majority of routing domains will be attached to only one of the TRDs. This will permit hierarchical address aggregation based on TRD. We therefore strongly recommend that addresses be assigned hierarchically, based on address prefixes assigned to individual TRDs.
私たちは、経路ドメインの大多数がTRDsの1つだけに付けられると予期します。 これはTRDに基づく階層的なアドレス集合を可能にするでしょう。 したがって、私たちは、アドレスが個々のTRDsに割り当てられたアドレス接頭語に基づいて階層的に割り当てられることを強く勧めます。
To support continental aggregation of routes, we recommend that all addresses for TRDs which are wholly within a continent be taken from the continental prefix.
ルートの大陸の集合をサポートするために、私たちは、完全に大陸の中にあるTRDsのためのすべてのアドレスが大陸の接頭語から取られることを勧めます。
For the proposed address allocation scheme, this implies that portions of IPv6 address space should be assigned to each TRD (explicitly including the backbones and regionals). For those leaf routing domains which are connected to a single TRD, they should be assigned a prefix value from the address space assigned to that TRD.
提案されたアドレス配分体系のために、これは、IPv6アドレス空間の部分が各TRDに割り当てられるべきであるのを含意します(明らかにバックボーンと地方版を含んでいて)。 独身のTRDにつなげられるそれらの葉の経路ドメインにおいて、接頭語値はそのTRDに割り当てられたアドレス空間からそれらに割り当てられるべきです。
For routing domains which are not attached to any publically available TRD, there is not the same urgent need for hierarchical address aggregation. We do not, therefore, make any additional recommendations for such `isolated' routing domains. Where such domains are connected to other domains by private point-to-point links, and where such links are used solely for routing between the two domains that they interconnect, again no additional technical problems relating to address abbreviation is caused by such a link, and no specific additional recommendations are necessary. We do recommend that since such domains may wish to use a private address space, that the addressing plan specify a specific prefix for private addressing.
どんなpublicallyに利用可能なTRDにも付けられていない経路ドメインには、階層的なアドレス集合の同じ緊急の必要がありません。 したがって、私たちはそのような'孤立している'経路ドメインのための少しの追加推薦状もしません。 そのようなドメインがどこで個人的なポイントツーポイント接続によって他のドメインにつなげられるか、そして、唯一再びそれらがインタコネクトする2つのドメインと、アドレス略語に関連するのがそのようなリンクによって引き起こされる追加技術的問題がなくて、特定の追加推薦の間のルーティングにおいて、そのようなリンクがどこで使用されているかが必要です。 私たちは、そのようなドメイン以来のそれがプライベート・アドレススペースを使用したがっているかもしれなくて、アドレシングプランが個人的なアドレシングに特定の接頭語を指定することを勧めます。
Further, in order to allow aggregation of IPv6 addresses at national and continental boundaries into as few prefixes as possible, we further recommend that IPv6 addresses allocated to routing domains should be assigned based on each routing domain's connectivity to national and continental Internet backbones.
さらに、国家の、そして、大陸の境界にできるだけわずかしかIPv6アドレスの集合を接頭語に許容しないように、私たちは、経路ドメインに割り当てられたIPv6アドレスが国家の、そして、大陸のインターネットの基幹への各経路ドメインの接続性に基づいて割り当てられるべきであることをさらに勧めます。
5.2 Recommendations for Multi-Homed Routing Domains
5.2の推薦、マルチ、家へ帰り、経路ドメイン
Some routing domains will be attached to multiple TRDs within the same country, or to TRDs within multiple different countries. We refer to these as `multi-homed' routing domains. Clearly the strict
いくつかの経路ドメインが同じ国の中の複数のTRDs、または、複数の異なった国の中のTRDsに付けられるでしょう。 私たちがこれらを参照する、'、マルチ、家へ帰り、'経路ドメイン。 明確に厳しい
Rekhter & Li Informational [Page 24] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[24ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
hierarchical model discussed above does not neatly handle such routing domains.
上で議論した階層的なモデルはそのような経路ドメインをきちんと扱いません。
There are several possible ways that these multi-homed routing domains may be handled, as described in Section 4.4. Each of these methods vary with respect to the amount of information that must be maintained for inter-domain routing and also with respect to the inter-domain routes. In addition, the organization that will bear the brunt of this cost varies with the possible solutions. For example, the solutions vary with respect to:
いくつかの可能な道がある、それ、これら、マルチ、家へ帰り、経路ドメインはセクション4.4で説明されるように扱われるかもしれません。 それぞれのこれらのメソッドは相互ドメインルーティングと相互ドメインルートに関しても維持しなければならない情報量に関して異なります。 さらに、この費用のほこさきに堪える組織は可能なソリューションで異なります。 例えば、ソリューションは以下に関して異なります。
- Resources used within routers within the TRDs;
- TRDsの中のルータの中の運用資金。
- Administrative cost on TRD personnel; and,
- TRD人員の管理費。 そして
- Difficulty of configuration of policy-based inter-domain routing
information within leaf routing domains.
- 葉の経路ドメインの中の方針ベースの相互ドメインルーティング情報の構成の困難。
Also, the solution used may affect the actual routes which packets follow, and may effect the availability of backup routes when the primary route fails.
また、使用されるソリューションは、パケットが従う実際のルートに影響して、幹線道路が失敗すると、バックアップルートの有用性に作用するかもしれません。
For these reasons it is not possible to mandate a single solution for all situations. Rather, economic considerations will require a variety of solutions for different routing domains, service providers, and backbones.
これらの理由で、すべての状況のためにただ一つのソリューションを強制するのは可能ではありません。 むしろ、経済上の考慮は異なった経路ドメイン、サービスプロバイダー、およびバックボーンのためにさまざまなソリューションを必要とするでしょう。
6. Security Considerations
6. セキュリティ問題
Security issues are not discussed in this document.
本書では安全保障問題について議論しません。
7. Acknowledgments
7. 承認
This document is largely based on RFC 1518. The section on Private Addresses borrowed heavily from RFC 1597.
このドキュメントはRFC1518に主に基づいています。 兵士のAddressesの上のセクションはRFC1597から大いに借りました。
We'd like to thank Havard Eidnes, Bill Manning, Roger Fajman for their review and constructive comments.
彼らのレビューと建設的なコメントについてHavard Eidnes、ビル・マニング、ロジャーFajmanに感謝申し上げます。
Rekhter & Li Informational [Page 25] RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Rekhterと李情報[25ページ]のRFC1887IPv6Unicastは、1995年12月に配分がアーキテクチャであると扱います。
REFERENCES
参照
[1] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version
6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks,
December 1995.
[1] デアリング、S.とR.Hinden、エディターズ、「インターネットプロトコル、バージョン6(IPv6)仕様」RFC1883、ゼロックスPARC、Ipsilonネットワーク、1995年12月
[2] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
1995.
[2] Hinden、R.とS.デアリング、エディターズ、「IPバージョン6アドレッシング体系」、RFC1884、Ipsilonネットワーク、ゼロックスPARC、1995年12月。
AUTHORS' ADDRESSES
作者のアドレス
Yakov Rekhter cisco Systems, Inc. 470 Tasman Dr. San Jose, CA 95134
サンノゼ、ヤコフRekhterコクチマスSystems Inc.470タスマン博士カリフォルニア 95134
Phone: (914) 528-0090 EMail: yakov@cisco.com
以下に電話をしてください。 (914) 528-0090 メールしてください: yakov@cisco.com
Tony Li cisco Systems, Inc. 470 Tasman Dr. San Jose, CA 95134
サンノゼ、トニー李コクチマスSystems Inc.470タスマン博士カリフォルニア 95134
Phone: (408) 526-8186 EMail: tli@cisco.com
以下に電話をしてください。 (408) 526-8186 メールしてください: tli@cisco.com
Rekhter & Li Informational [Page 26]
Rekhterと李Informationalです。[26ページ]
一覧
スポンサーリンク
