IPv6ユニキャストアドレス割り当て体系(マルチホームルーティングドメイン)

広告

広告

原文

最終更新
2006-10-19T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/1887/rfc1887_44.html#source

IPv6ユニキャストアドレスの割り当て体系(和訳)

最終更新
2006-10-29T10:32:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/1887/rfc1887_44.html#translation

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
   are a number of possible ways to deal with these multi-homed routing
   domains.

ただし、複数のプロバイダから接続されるルーティングドメインには追加の考察を要する。そのようなマルチホームなルーティングドメインは、例えば、複数のバックボーン、同一の国で違う場所へ位置し違うプロバイダに接続された巨大な組織、様々な国のバックボーンに接続された複数の国際組織へ接続される単一サイトのキャンパスや会社から構成されるかもしれない。これらマルチホームルーティングドメインへの対処方法には多くの可能な方法がある。

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アドレスと無関係なために、この組織が接続されるTRDが他のプロバイダへこの組織のプレフィックスをアドバタイズする必要があるということだ。(世界的にみた)他のプロバイダは、ルーティングテーブル内にその組織への明示的なエントリを含む必要があるだろう。

   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.

例えば、非常に巨大な北アメリカの会社MBIIが完全に相互接続された内部ネットワークを持ち、北アメリカのプレフィックスの一部として単一のプレフィックスを割り当てられると仮定する。北アメリカの外部で、全ての北アメリカの宛先のルーティングテーブルが単一のプレフィックスとして保持される可能性がある。ただし北アメリカにおいては、全てのプロバイダがMBIIの個別のアドレスエントリを保持する必要がある。MBIIが実際の国際企業としてある場合、世界的な全てのプロバイダがMBIIの個別のエントリ(MBIIが接続されていないバックボーンを含む)を保持する必要があるかもしれない。そのようなマルチホームなルーティングドメインの数が明らかに少ないのであればこの方法も可能であるかもしれないが、組織がみなそのようなアドレスの割り当てを選択すればバックボーン内のルータに異常な負荷がかかるだろう。何百何千ものマルチホームな組織がある場合、この解決方法はインターネットに沿わないだろう。

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
   single address prefix based on the nearest connection.

2つ目の方法として、マルチホームな組織がTRDの各接続のために個別のIPv6アドレス空間を割り当てられ、最も近い相互接続ポイントに基づくそのドメインの部分集合に単一のプレフィックスを割り当てる方法だろう。例えば、MBIIがヨーロッパと1つは東端にある国際的なバックボーンへの3つの接続と同様にアメリカの2つのプロバイダの接続(東海岸と西海岸に)を持つ場合、MBIIは6つの異なるアドレスプレフィックスを用いてもよい。MBIIの各部分は、最も近い接続に基づく単一のアドレスプレフィックスを割り当てられるだろう。

   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内部宛先へのトラフィックの外部ルーティングのために、この方法はMBIIが6つの個別の組織であるかのように扱うこととなる。内部ルーティングのために、或いはMBII内部からMBII外部宛先へのルーティングトラフィックのために、この方法は解決策1と同様に機能する。

   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のそれらの部分だけに到達する他のTRDの能力を通知する必要がある。これは、解決策1と比較してTRDによって保持されるドメイン間ルーティングテーブルの読み込みが少ないため、追加のルーティング情報をTRD間で交換する必要がないことを暗示している。従って、この解決策は非常に多くのマルチホームな組織を含む巨大なインターネットによりみあったものである。

   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の問題点の1つは、マルチホーム組織へのバックアップルートが自動的に保持されないということである。解決策1にて、各TRDはMBIIに達する能力を通知する際にMBII内のホスト全てに到達可能であることを明示している。解決策2では、単にMBII内のホストの中のいくつかを含む自身のアドレスプレフィックスに基づいた全てのホストへの到達可能性を各TRDは通知する。MBIIとある特定の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).

更に、この方法及び前回の方法はパケットが異なる経路をとる傾向にあることに注意が必要である。1つ目の方法では、MBII内に割り当てられたMBII外部からのパケットは発信元に最も近いポイントを経由する傾向にあるだろう(従ってMBII内部ネットワーク上の負荷を最大にする傾向がある)。解決策2では、MBII内に割り当てられた外部からのパケットは、目的地に最も近いポイントを経由する傾向にあるだろう(MBIIネットワーク上の負荷を最小とし、TRD上の負荷を最大にする傾向がある)。

   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
   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.

これらの解決策は更に、ポリシーによって効果が異なる。例えば国Xでは、国X内の発信元から国X内の宛先へのトラフィックがいつでも完全にその国内に留まるとの法則を持つ場合。解決策1では、宛先が国内にあろうがなかろうが宛先アドレスからの決定は不可能である。解決策2では、個別のアドレスは国X内のホストに割り当てられることがあり、そのためルーティングポリシーに従うこととなる。同様にLSCが、パケットがMBII内の宛先へ送られる可能性のあるポリシーを持つとする。どちらの解決策でも、LSC内のルータはMBIIのアドレス空間内の宛先を持つ全てのトラフィックを破棄する設定がなされるかもしれない。しかし解決策1では1つのエントリが要求され、解決策2では多くのエントリが要求されるため、実際不可能であると思われる。

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への接続の1つに基づき各マルチホームな組織の単一のアドレスプレフィックスを割り当てることである。マルチホームな組織に接続した他のTRDは、その組織のためのルーティングテーブルエントリを保持するが、この経路をとる他のTRDからみると非常に選択的である。より直接的なルーティングを行う場合に限り、この方法によって全てのTRDがそこまでの経路を知っている(全てのTRDが各々の経路を保持すると仮定できるから)1つのデフォルトルーティングエントリを作り出すこととなる。

   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つある。組織の特別な利益団体が自身のプロバイダを展開したと仮定する。例えば、米国国立の小型装置メーカ及び研究者が米国全体に渡る、小型装置を製造する企業及び小型装置の研究成果によって知られるある大学によって用いられるプロバイダを設定したと仮定する。小型装置グループに属する様々な組織が、ルーティングドメインを区切ったり、(小型装置の製造及び研究に関する殆どの組織が他の活動に関係するので)それらの内の殆どが他のTRDに接続したりして内部ネットワークを運用すると想定することができる。従って、小型装置グループに属する組織の多くもしくは大部分が、小型装置に関する通信用の接続に1つと、他の種類の通信用の別の接続1つによる二重ホームであると想定することができる。更に、小型装置グループに関する組織の総数が、組織ごとに1つのエントリを含むルーティングテーブルを保持し、何百万(殆どが小型装置と関連しない)ものルーティングドメインを備えた巨大なインターネット全体に渡ってそれらを配送させるために無理のない十分小さな値であると仮定する。

   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番目の方法では、小型装置グループ内の各マルチホームな組織はTRDにその他の接続(その接続は小型装置グループと関係がない)を基にしたアドレス割り当てを用いるだろう。小型装置プロバイダは、様々な組織のメンバに関連したルーティングドメインへの経路を保持する必要がある。同様に、小型装置グループの全てのメンバは小型装置プロバイダ経由で他のメンバへの経路テーブルを保持する必要がある。しかし、小型装置プロバイダは到達可能なアドレス指定する他の一般的な世界規模のTRDの情報を知らせない(プロバイダは他の外部組織によって用いられることを想定していないから)ので、比較的大きなルーティングプレフィックスの集合は限られた場所でのみ保持される必要がある。小型装置グループ内の通信が好ましい経路を用いることを認める限り、小型装置グループのメンバである様々な組織に割り当てられたアドレスは、TRDへの他の接続の各メンバを経由するデフォルト経路を提供するだろう。

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番目のプレフィックスに基づいたアドレスを得るだろう。その後、これらのTRDのそれぞれは、他のTRDへの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は重要となる。特に将来のある時点では、事実上全てのルーティングドメインが公共のデータネットワークに接続されるだろう。この場合、政府が後援するネットワーク(いくつかの現在の地域業者のような)はほぼ全て、公共のネットワークで実質重複する顧客の集合を持つこともある。

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アドレスを割り当てる問題の解決策はいくつもある。これらの解決策は各々非常に異なる利点と欠点を持つ。各解決策は、マルチホームな組織と(マルチホームな組織が接続されていないものを含む)TRDに異なる実際の(つまり金融的な)コストを置く。

   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アドレスプレフィックスが任意の接続されたリーフルーティングドメインから受理はされるが、他のTRDにはアドバタイズされないかもしれない。更に稀な保守的なポリシーでは、TRDはそのようなローカルではないプレフィックスを受理し、他のTRDの定義された集合(この集合は、地理的な位置もしくは要求するリーフルーティングドメインに特有の協定結果のような何かを共通に持つTRDの優先グループである)でそれらを交換することに合意するかもしれない。様々なポリシーは、TRDへのポリシーに反映する実際のコストを含む。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年10月19日 最終更新:2006年10月29日