RFC2185 日本語訳
2185 Routing Aspects of IPv6 Transition. R. Callon, D. Haskin. September 1997. (Format: TXT=31281 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Callon
Request for Comments: 2185 Cascade Communications Co.
Category: Informational D. Haskin
Bay Networks Inc.
September 1997
Callonがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2185年のカスケードコミュニケーション社のカテゴリ: 情報のD.ハスキンベイネットワークス株式会社1997年9月
Routing Aspects Of IPv6 Transition
IPv6変遷のルート設定局面
Status of this memo
このメモの状態
This memo 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 gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document "Transition Mechanisms for IPv6 Hosts and Routers" [1]. Readers should be familiar with the transition mechanisms before reading this document.
このドキュメントはIPv6変遷のルーティング局面の概要を与えます。 それはプロトコルに基づいています。「IPv6ホストとルータのための変遷メカニズム」というドキュメントでは、[1]を定義しました。 読者はこのドキュメントを読む前の変遷メカニズムに詳しいはずです。
The proposals contained in this document are based on the work of the Ngtrans working group.
本書では含まれた提案はNgtransワーキンググループの仕事に基づいています。
1. TERMINOLOGY
1. 用語
This paper uses the following terminology:
この紙は以下の用語を使用します:
node - a protocol module that implements IPv4 or IPv6.
ノード--IPv4かIPv6を実装するプロトコルモジュール。
router - a node that forwards packets not explicitly
addressed to itself.
ルータ--明らかにそれ自体に扱われなかったパケットを進めるノード。
host - any node that is not a router.
ホスト--ルータでないどんなノード。
border router - a router that forwards packets across
routing domain boundaries.
ルータに接してください--ルーティングドメイン境界の向こう側にパケットを送るルータ。
link - a communication facility or medium over which
nodes can communicate at the link layer, i.e., the layer
immediately below internet layer.
リンクしてください--ノードがすなわち、リンクレイヤ、インターネット層のすぐ下の層で交信できる通信機器か媒体。
interface - a node's attachment to a link.
連結してください--リンクへのノードの付属。
address - an network layer identifier for an interface or
a group of interfaces.
アドレス--インタフェースのためのネットワーク層識別子かインタフェースのグループ。
Callon & Haskin Informational [Page 1] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[1ページ]のRFC2185ルート設定局面
neighbors - nodes attached to the same link.
隣人--ノードは同じリンクに付きました。
routing domain - a collection of routers which coordinate
routing knowledge using a single routing protocol.
経路ドメイン--ただ一つのルーティング・プロトコルを使用することでルーティング知識を調整するルータの収集。
routing region (or just "region") - a collection of routers
interconnected by a single internet protocol (e.g. IPv6)
and coordinating their routing knowledge using routing
protocols from a single internet protocol stack. A
routing region may be a superset of a routing domain.
ルーティング領域(または、まさしく「領域」)--ルータの収集は、ただ一つのインターネットプロトコル(例えば、IPv6)と単一のインターネットプロトコル・スタックからルーティング・プロトコルを使用することでそれらのルーティング知識を調整することによって、内部連絡されました。 ルーティング領域は経路ドメインのスーパーセットであるかもしれません。
tunneling - encapsulation of protocol A within protocol B,
such that A treats B as though it were a datalink layer.
トンネリング--プロトコルB(Aがまるでそれがデータリンク層であるかのようにBを扱うようなもの)の中のプロトコルAのカプセル化。
reachability information - information describing the set of
reachable destinations that can be used for packet
forwarding decisions.
可到達性情報--パケット推進決定に使用できる届いている目的地のセットについて説明する情報。
routing information - same as reachability information.
ルーティング情報--可到達性情報と同じです。
address prefix - the high-order bits in an address.
接頭語を扱ってください--アドレスの高位のビット。
routing prefix - address prefix that expresses destinations
which have addresses with the matching address prefixes.
It is used by routers to advertise what systems they are
capable of reaching.
ルーティング接頭語--合っているアドレス接頭語でアドレスを持っている目的地を言い表す接頭語を扱ってください。 それはルータによって使用されて、それらは達しながらできるどんなシステムの広告を出すか。
route leaking - advertisement of network layer reachability
information across routing region boundaries.
漏出を発送してください--ルーティング領域の限界の向こう側のネットワーク層可到達性情報の広告。
2. ISSUES AND OUTLINE
2. 問題とアウトライン
This document gives an overview of the routing aspects of IPv4 to IPv6 transition. The approach outlined here is designed to be compatible with the existing mechanisms for IPv6 transition [1].
このドキュメントはIPv4のルーティング局面の概要をIPv6変遷に与えます。 ここに概説されたアプローチは、IPv6変遷[1]において既存のメカニズムと互換性があるように設計されています。
During an extended IPv4-to-IPv6 transition period, IPv6-based systems must coexist with the installed base of IPv4 systems. In such a dual internetworking protocol environment, both IPv4 and IPv6 routing infrastructure will be present. Initially, deployed IPv6-capable domains might not be globally interconnected via IPv6-capable internet infrastructure and therefore may need to communicate across IPv4-only routing regions. In order to achieve dynamic routing in such a mixed environment, there need to be mechanisms to globally distribute IPv6 network layer reachability information between dispersed IPv6 routing regions. The same techniques can be used in later stages of IPv4-to-IPv6 transition to route IPv4 packets between isolated IPv4-only routing region over IPv6 infrastructure.
IPv4からIPv6への拡張過渡期の間、IPv6ベースのシステムはIPv4システムのインストールされたベースと共存しなければなりません。そのような二元的なインターネットワーキングプロトコル環境で、IPv4とIPv6ルーティングインフラストラクチャの両方が存在するでしょう。 初めは、配布しているIPv6できるドメインは、IPv6できるインターネットインフラストラクチャでグローバルにインタコネクトされないで、したがって、IPv4だけルーティング領域の向こう側に交信する必要があるかもしれません。 そのような複雑な環境におけるダイナミックルーティングを達成するために、分散IPv6ルーティング領域の間にIPv6ネットワーク層可到達性情報をグローバルに分配するメカニズムがあるのが必要です。 IPv4からIPv6への変遷の後期段階にIPv6インフラストラクチャの上で孤立しているIPv4だけルーティング領域の間にIPv4パケットを発送するのに同じテクニックを使用できます。
Callon & Haskin Informational [Page 2] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[2ページ]のRFC2185ルート設定局面
The IPng transition provides a dual-IP-layer transition, augmented by use of encapsulation where necessary and appropriate. Routing issues related to this transition include:
IPng変遷は必要であって、適切であるところでカプセル化の使用で増大する二元的なIP層の変遷を提供します。 この変遷に関連するルート設定問題は:
(1) Routing for IPv4 packets
(1) IPv4パケットのためのルート設定
(2) Routing for IPv6 packets
(2a) IPv6 packets with IPv6-native addresses
(2b) IPv6 packets with IPv4-compatible addresses
(2) IPv6パケットのためのルート設定、(ネイティブのIPv6がある2a) IPv6パケットはIPv4コンパチブルアドレスで(2b)IPv6パケットを扱います。
(3) Operation of manually configured static tunnels
(3) 手動で構成された静的なトンネルの操作
(4) Operation of automatic encapsulation
(4a) Locating encapsulators
(4b) Ensuring that routing is consist with
encapsulation
(4) 自動カプセル化の操作、(ルーティングがそうであることを確実にする4a) Locating encapsulators(4b)がカプセル化と一致しています。
Basic mechanisms required to accomplish these goals include: (i) Dual-IP-layer Route Computation; (ii) Manual configuration of point- to-point tunnels; and (iii) Route leaking to support automatic encapsulation.
これらの目標を達成しなければならなかった基本的機構は: (i) 二元的なIP層の経路計算。 (ii) ポイントへのポイントトンネルの手動の構成。 そして、自動カプセル化をサポートする(iii)ルート漏出。
The basic mechanism for routing of IPv4 and IPv6 involves dual-IP- layer routing. This implies that routes are separately calculated for IPv4 addresses and for IPv6 addressing. This is discussed in more detail in section 3.1.
IPv4とIPv6のルーティングのための基本的機構は二元的なIP-層のルーティングにかかわります。 これは、ルートがIPv4アドレスとIPv6アドレシングのために別々に計算されるのを含意します。 さらに詳細にセクション3.1でこれについて議論します。
Tunnels (either IPv4 over IPv6, or IPv6 over IPv4) may be manually configured. For example, in the early stages of transition this may be used to allow two IPv6 domains to interact over an IPv4 infrastructure. Manually configured static tunnels are treated as if they were a normal data link. This is discussed in more detail in section 3.2.
Tunnels(IPv6の上のIPv4かIPv4の上のIPv6のどちらか)は手動で構成されるかもしれません。 例えば、変遷の初期段階に、これは、2つのIPv6ドメインがIPv4インフラストラクチャの上に相互作用するのを許容するのに使用されるかもしれません。 手動で構成された静的なトンネルはまるでそれらが正常なデータ・リンクであるかのように扱われます。 さらに詳細にセクション3.2でこれについて議論します。
Use of automatic encapsulation, where the IPv4 tunnel endpoint address is determined from the IPv4 address embedded in the IPv4- compatible destination address of IPv6 packet, requires consistency of routes between IPv4 and IPv6 routing domains for destinations using IPv4-compatible addresses. For example, consider a packet which starts off as an IPv6 packet, but then is encapsulated in an IPv4 packet in the middle of its path from source to destination. This packet must locate an encapsulator at the correct part of its path. Also, this packet has to follow a consistent route for the entire path from source to destination. This is discussed in more detail in section 3.3.
自動カプセル化の使用は、IPv4トンネル終点アドレスがIPv6パケットのIPv4コンパチブル送付先アドレスに埋め込まれたIPv4アドレスから決定しているところでIPv4コンパチブルアドレスを使用することで目的地へのIPv4とIPv6経路ドメインの間のルートの一貫性を必要とします。 例えば、IPv6パケットとして始めますが、経路の中央のIPv4パケットでソースから目的地までカプセルに入れられるパケットを考えてください。 このパケットは経路の適度の地域でencapsulatorの場所を見つけなければなりません。 また、このパケットは全体のソースから目的地までの経路への一貫したルートに従わなければなりません。 さらに詳細にセクション3.3でこれについて議論します。
The mechanisms for tunneling IPv6 over IPv4 are defined in the transition mechanisms specification [1].
IPv4の上でIPv6にトンネルを堀るためのメカニズムは変遷メカニズム仕様[1]に基づき定義されます。
Callon & Haskin Informational [Page 3] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[3ページ]のRFC2185ルート設定局面
3. MORE DETAIL OF BASIC APPROACHES
3. 基本的なアプローチに関するその他の詳細
3.1 Basic Dual-IP-layer Operation
3.1 基本的な二元的なIP層の操作
In the basic dual-IP-layer transition scheme, routers may independently support IPv4 and IPv6 routing. Other parts of the transition, such as DNS support, and selection by the source host of which packet format to transmit (IPv4 or IPv6) are discussed in [1]. Forwarding of IPv4 packets is based on routes learned through running IPv4-specific routing protocols. Similarly, forwarding of IPv6 packets (including IPv6-packets with IPv4-compatible addresses) is based on routes learned through running IPv6-specific routing protocols. This implies that separate instances of routing protocols are used for IPv4 and for IPv6 (although note that this could consist of two instances of OSPF and/or two instances of RIP, since both OSPF and RIP are capable of supporting both IPv4 and IPv6 routing).
基本的な二元的なIP層の変遷体系では、ルータは、独自にIPv4とIPv6がルーティングであるとサポートするかもしれません。 [1]でどのパケット・フォーマットを伝えたらよいかに関する送信元ホスト(IPv4かIPv6)による変遷のDNSサポートや、選択などの他の部品について議論します。 IPv4パケットの推進は実行しているIPv4特有のルーティング・プロトコルを通して学習されたルートに基づいています。 同様に、IPv6パケット(IPv4コンパチブルアドレスがあるIPv6-パケットを含んでいる)の推進は実行しているIPv6特有のルーティング・プロトコルを通して学習されたルートに基づいています。 これは、ルーティング・プロトコルの別々のインスタンスがIPv4とIPv6に使用されるのを含意します(これがOSPFの2つのインスタンス、そして/または、RIPの2つのインスタンスから成ることができたというメモですが、両方以来、OSPFとRIPはIPv4とIPv6の両方にルーティングをサポートすることができます)。
A minor enhancement would be to use an single instance of an integrated routing protocol to support routing for both IPv4 and IPv6. At the time that this is written there is no protocol which has yet been enhanced to support this. This minor enhancement does not change the basic dual-IP-layer nature of the transition.
小さい方の増進はIPv4とIPv6の両方のためにルーティングをサポートするのに統合ルーティング・プロトコルのただ一つのインスタンスを使用するだろうことです。 これが書かれている時に、これをサポートするためにまだ高められているプロトコルが全くありません。 この小さい方の増進は変遷の基本的な二元的なIP層の本質を変えません。
For initial testing of IPv6 with IPv4-compatible addresses, it may be useful to allow forwarding of IPv6 packets without running any IPv6- compatible routing protocol. In this case, a dual (IPv4 and IPv6) router could run routing protocols for IPv4 only. It then forwards IPv4 packets based on routes learned from IPv4 routing protocols. Also, it forwards IPv6 packets with an IPv4-compatible destination address based on the route for the associated IPv4 address. There are a couple of drawbacks with this approach: (i) It does not specifically allow for routing of IPv6 packets via IPv6-capable routers while avoiding and routing around IPv4-only routers; (ii) It does not produce routes for "non-compatible" IPv6 addresses. With this method the routing protocol does not tell the router whether neighboring routers are IPv6-compatible. However, neighbor discovery may be used to determine this. Then if an IPv6 packet needs to be forwarded to an IPv4-only router it can be encapsulated to the destination host.
IPv4コンパチブルアドレスによるIPv6の初期のテストに、実行のないIPv6パケットの推進にどんなIPv6コンパチブルルーティング・プロトコルも許容するのは役に立つかもしれません。 この場合、二元的な(IPv4とIPv6)ルータはIPv4だけのためにルーティング・プロトコルを実行するかもしれません。 そして、それはIPv4ルーティング・プロトコルから学習されたルートに基づくパケットをIPv4に送ります。 また、それは関連IPv4アドレスのためにルートに基づくIPv4コンパチブル送付先アドレスがあるパケットをIPv6に送ります。 このアプローチがある2、3の欠点があります: (i) それはIPv6のルーティングのためにIPv4だけルータの周りで避けて、掘っている間、IPv6できるルータでパケットを明確に許容しません。 (ii) それは「非コンパチブル」IPv6アドレスのためのルートを作成しません。 このメソッドで、ルーティング・プロトコルは、隣接しているルータはIPv6互換性があるかどうかルータに言いません。 しかしながら、隣人発見は、これを決定するのに使用されるかもしれません。 そして、IPv6パケットが、IPv4だけルータに送られる必要があるなら、あて先ホストにそれをカプセル化することができます。
3.2 Manually Configured Static Tunnels
3.2 手動で構成された静的なTunnels
Tunneling techniques are already widely deployed for bridging non-IP network layer protocols (e.g. AppleTalk, CLNP, IPX) over IPv4 routed infrastructure. IPv4 tunneling is an encapsulation of arbitrary packets inside IPv4 datagrams that are forwarded over IPv4 infrastructure between tunnel endpoints. For a tunneled protocol, a tunnel appears as a single-hop link (i.e. routers that establish a
テクニックがIPv4の上で非IPネットワーク層プロトコルが(例えば、AppleTalk、CLNP、IPX)であるとブリッジするために既に広く配布されるトンネリングはインフラストラクチャを発送しました。 IPv4トンネリングはトンネル終点の間のIPv4インフラストラクチャの上に送られるIPv4データグラムの中の任意のパケットのカプセル化です。 トンネルを堀られたプロトコルに関しては、トンネルが単一のホップリンクとして現れる、(すなわち、aを設立するルータ
Callon & Haskin Informational [Page 4] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[4ページ]のRFC2185ルート設定局面
tunnel over a network layer infrastructure can inter-operate over the tunnel as if it were a one-hop, point-to-point link). Once a tunnel is established, routers at the tunnel endpoints can establish routing adjacencies and exchange routing information. Describing the protocols for performing encapsulation is outside the scope of this paper (see [1]). Static point-to-point tunnels may also be established between a host and a router, or between two hosts. Again, each manually configured point-to-point tunnel is treated as if it was a simple point-to-point link.
ネットワーク層インフラストラクチャがまるでそれがワンバウンドの、そして、二地点間のリンクであるかのようにトンネルの上に共同利用できるaの上のトンネル) トンネルがいったん確立されると、トンネル終点のルータはルーティング隣接番組と交換ルーティング情報を確立できます。 この紙の範囲の外に実行カプセル化のためにプロトコルについて説明するのがあります。([1])を見てください。 また、静的な二地点間トンネルはホストとルータの間、または、2人のホストの間で確立されるかもしれません。 一方、それぞれの手動で構成された二地点間トンネルはまるでそれが簡単なポイントツーポイント接続であるかのように扱われます。
3.3 Automatic Tunnels
3.3 自動Tunnels
Automatic tunneling may be used when both the sending and destination nodes are connected by IPv4 routing. In order for automatic tunneling to work, both nodes must be assigned IPv4-compatible IPv6 addresses. Automatic tunneling can be especially useful where either source or destination hosts (or both) do not have any adjacent IPv6- capable router. Note that by "adjacent router", this includes routers which are logically adjacent by virtue of a manually configured point-to-point tunnel (which is treated as if it is a simple point-to-point link).
発信と目的地ノードの両方がIPv4ルーティングで接続されるとき、自動トンネリングは使用されるかもしれません。 自動トンネリングが扱うように、IPv4コンパチブルIPv6アドレスを両方のノードに割り当てなければなりません。 自動トンネリングはソースかあて先ホストのどちらか(ともに)がどんな隣接しているIPv6できるルータも持っていないところで特に役に立つ場合があります。 「隣接しているルータ」でこれが手動で構成された二地点間トンネル(まるでそれが簡単なポイントツーポイント接続であるかのように扱われる)による論理的に隣接しているルータを含んでいることに注意してください。
With automatic tunneling, the resulting IPv4 packet is forwarded by IPv4 routers as a normal IPv4 packet, using IPv4 routes learned from routing protocols. There are therefore no special issues related to IPv4 routing in this case. There are however routing issues relating to how IPv6 routing works in a manner which is compatible with automatic tunneling, and how tunnel endpoint addresses are selected during the encapsulation process. Automatic tunneling is useful from a source host to the destination host, from a source host to a router, and from a router to the destination host. Mechanisms for automatic tunneling from a router to another router are not currently defined.
自動トンネリングと共に、正常なIPv4パケットとしてIPv4ルータで結果として起こるIPv4パケットを進めます、ルーティング・プロトコルから学習されたIPv4ルートを使用して。 したがって、この場合IPv4ルーティングに関連する増刊が全くありません。 しかしながら、トンネル終点アドレスがカプセル化プロセスの間、IPv6ルーティングが自動トンネリングと互換性がある方法でどう利くか、そして、どう選択されるかに関連するルーティング問題があります。 自動トンネリングは送信元ホストからあて先ホストの役に立ちます、送信元ホストからルータまでルータからあて先ホストまで。 自動ルータから別のルータまでのトンネリングのためのメカニズムは現在、定義されません。
3.3.1 Host to Host Automatic Tunneling
3.3.1 自動トンネリングをホストに接待してください。
If both source and destination hosts make use of IPv4-compatible IPv6 addresses, then it is possible for automatic tunneling to be used for the entire path from the source host to the destination host. In this case, the IPv6 packet is encapsulated in an IPv4 packet by the source host, and is forwarded by routers as an IPv4 packet all the way to the destination host. This allows initial deployment of IPv6-capable hosts to be done prior to the update of any routers.
ソースとあて先ホストの両方がIPv4コンパチブルIPv6アドレスを利用するなら、自動トンネリングが全体の経路に送信元ホストからあて先ホストまで使用されるのは、可能です。 この場合、IPv6パケットを送信元ホストがIPv4パケットでカプセルに入れって、ルータはIPv4パケットとしてあて先ホストまでのいっぱいに進めます。 これで、IPv6有能なホストの初期の展開はどんなルータのアップデートの前にもします。
Callon & Haskin Informational [Page 5] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[5ページ]のRFC2185ルート設定局面
A source host may make use of Host to Host automatic tunneling provided that the following are both true:
以下がともに本当であれば、送信元ホストはHostの自動トンネリングにHostを利用するかもしれません:
- the source address is an IPv4-compatible IPv6 address.
- the destination address is an IPv4-compatible IPv6 address.
- the source host does know of one or more neighboring IPv4-
capable routers, or the source and destination are on the
same subnet.
- ソースアドレスはIPv4コンパチブルIPv6アドレスです。 - 送付先アドレスはIPv4コンパチブルIPv6アドレスです。 - 送信元ホストが1つ以上の隣接しているIPv4できるルータを知っているか、またはソースと目的地が同じサブネットにあります。
If all of these requirements are true, then the source host may encapsulate the IPv6 packet in an IPv4 packet, using a source IPv4 address which is extracted from the associated source IPv6 address, and using a destination IPv4 address which is extracted from the associated destination IPv6 address.
これらの要件のすべてが本当であるなら、送信元ホストはIPv4パケットでIPv6パケットをカプセルに入れるかもしれません、関連ソースIPv6アドレスから抜粋されるソースIPv4アドレスを使用して、関連送付先IPv6アドレスから抜粋される送付先IPv4アドレスを使用して。
Where host to host automatic tunneling is used, the packet is forwarded as a normal IPv4 packet for its entire path, and is decapsulated (i.e., the IPv4 header is removed) only by the destination host.
自動トンネリングを接待するホストが使用されているところでは、パケットは、全体の経路への正常なIPv4パケットとして進められて、単にあて先ホストによってdecapsulatedされます(すなわち、IPv4ヘッダーを取り除きます)。
3.3.2 Host to Router Configured Default Tunneling
3.3.2 ルータの構成されたデフォルトにトンネリングを接待してください。
In some cases "configured default" tunneling may be used to encapsulate the IPv6 packet for transmission from the source host to an IPv6-backbone. However, this requires that the source host be configured with an IPv4 address to use for tunneling to the backbone.
いくつかの場合、「構成されたデフォルト」トンネリングは、送信元ホストからIPv6-バックボーンまでのトランスミッションのためにIPv6パケットをカプセルに入れるのに使用されるかもしれません。 しかしながら、これは、送信元ホストがバックボーンにトンネルを堀るのに使用するIPv4アドレスによって構成されるのを必要とします。
Configured default tunneling is particularly useful if the source host does not know of any local IPv6-capable router (implying that the packet cannot be forwarded as a normal IPv6 packet directly over the link layer), and when the destination host does not have an IPv4-compatible IPv6 address (implying that host to host tunneling cannot be used).
あて先ホストにIPv4コンパチブルIPv6アドレスがないとき(ホストトンネリングにそのホストを含意するのを使用できません)、送信元ホストがどんな地方のIPv6できるルータも知らないなら(正常なIPv6パケットとしてリンクレイヤの直接上にパケットを送ることができないのを含意して)、構成されたデフォルトトンネリングは特に役に立ちます。
Host to router configured default tunneling may optionally also be used even when the host does know of a local IPv6 router. In this case it is a policy decision whether the host prefers to send a native IPv6 packet to the IPv6-capable router or prefers to send an encapsulated packet to the configured tunnel endpoint.
また、ホストが地方のIPv6ルータを知るときさえ、ルータの構成されたデフォルトトンネリングへのホストは任意に使用されるかもしれません。 この場合、それはホストが、ネイティブのIPv6パケットをIPv6できるルータに送るのを好むか、または構成されたトンネル終点にカプセル化されたパケットを送るのを好むかという政策決定です。
Similarly host to router default configured tunneling may be used even when the destination address is an IPv4-compatible IPv6 address. In this case for example a policy decision may be made to prefer tunneling for part of the path and native IPv6 for part of the path, or alternatively to use tunneling for the entire path from source host to destination host.
同様に、ルータデフォルトへのホストは、送付先アドレスがIPv4コンパチブルIPv6アドレスでさえあるときに、トンネリングが使用されるかもしれないのを構成しました。 この場合、経路の一部のために経路とネイティブのIPv6の一部にトンネルを堀るのを好むか、または全体の経路に代わりに送信元ホストからあて先ホストまでトンネリングを使用するのを例えば政策決定をするかもしれません。
Callon & Haskin Informational [Page 6] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[6ページ]のRFC2185ルート設定局面
A source host may make use of host to router configured default tunneling provided that ALL of the following are true:
以下のすべてが本当であれば、送信元ホストはルータの構成されたデフォルトトンネリングにホストを利用するかもしれません:
- the source address is an IPv4-compatible IPv6 address.
- the source host does know of one or more neighboring IPv4-
capable routers
- the source host has been configured with an IPv4 address of
an dual router which can serve as the tunnel endpoint.
- ソースアドレスはIPv4コンパチブルIPv6アドレスです。 - 送信元ホストは1つ以上の隣接しているIPv4できるルータを知っています--送信元ホストはトンネル終点として機能できる二元的なルータのIPv4アドレスによって構成されました。
If all of these requirements are true, then the source host may encapsulate the IPv6 packet in an IPv4 packet, using a source IPv4 address which is extracted from the associated source IPv6 address, and using a destination IPv4 address which corresponds to the configured address of the dual router which is serving as the tunnel endpoint.
これらの要件のすべてが本当であるなら、送信元ホストはIPv4パケットでIPv6パケットをカプセルに入れるかもしれません、関連ソースIPv6アドレスから抜粋されるソースIPv4アドレスを使用して、トンネル終点として機能している二元的なルータの構成されたアドレスに一致している送付先IPv4アドレスを使用して。
When host to router configured default tunneling is used, the packet is forwarded as a normal IPv4 packet from the source host to the dual router serving as tunnel endpoint, is decapsulated by the dual router, and is then forwarded as a normal IPv6 packet by the tunnel endpoint.
ルータの構成されたデフォルトトンネリングへのホストが使用されているとき、パケットは、正常なIPv4パケットとして送信元ホストから二元的なトンネル終点として機能するルータまで進められて、二元的なルータによってdecapsulatedされて、トンネル終点のそばで正常なIPv6パケットとして進められたその時です。
3.3.2.1 Routing to the Endpoint for the Configured Default Tunnel
3.3.2.1 構成されたデフォルトトンネルへの終点へのルート設定
The dual router which is serving as the end point of the host to router configured default tunnel must advertise reachability into IPv4 routing sufficient to cause the encapsulated packet to be forwarded to it.
ホストのエンドポイントとしてルータの構成されたデフォルトトンネルに機能している二元的なルータはカプセル化されたパケットがそれに送られることを引き起こすことができるくらいのIPv4ルーティングに可到達性の広告を出さなければなりません。
The simplest approach is for a single IPv4 address to be assigned for use as a tunnel endpoint. One or more dual routers, which have connectivity to the IPv6 backbone and which are capable of serving as tunnel endpoint, advertise a host route to this address into IPv4 routing in the IPv4-only region. Each dual host in the associated IPv4-only region is configured with the address of this tunnel endpoint and selects a route to this address for forwarding encapsulated packet to a tunnel end point (for example, the nearest tunnel end point, based on whatever metric(s) the local routing protocol is using).
最も簡単なアプローチはただ一つのIPv4アドレスが使用のためにトンネル終点として割り当てられることです。 1つ以上の二元的なルータ(IPv6バックボーンに接続性を持って、トンネル終点として機能できる)がIPv4だけ領域でのIPv4ルーティングへのこのアドレスにホストルートの広告を出します。 関連IPv4だけ領域のそれぞれの二元的なホストは、トンネルエンドポイント(例えば、ローカルのルーティング・プロトコルが使用しているいかなるメートル法の(s)に基づいた最も近いトンネルエンドポイント)へのパケットであるとカプセル化された推進のために、このトンネル終点のアドレスによって構成されて、このアドレスにルートを選択します。
Finally, in some cases there may be some reason for specific hosts to prefer one of several tunnel endpoints, while allowing all potential tunnel endpoints to serve as backups in case the preferred endpoint is not reachable. In this case, each dual router with IPv6 backbone connectivity which is serving as potential tunnel endpoint is given a unique IPv4 address taken from a single IPv4 address block (where the IPv4 address block is assigned either to the organization administering the IPv4-only region, or to the organization
いくつかの場合、最終的に、都合のよい終点が届かないといけないのですべての潜在的トンネル終点がバックアップとして機能するのを許容している間、特定のホストがいくつかのトンネル終点の1つを好む何らかの理由があるかもしれません。 この場合、潜在的トンネル終点として機能しているIPv6バックボーンの接続性があるそれぞれの二元的なルータに1つのIPv4あて先ブロックから抜粋されるユニークなIPv4アドレスを与えます。(IPv4だけ領域を管理しながらIPv4がどこでブロックを扱うか組織に配属する、組織
Callon & Haskin Informational [Page 7] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[7ページ]のRFC2185ルート設定局面
administering the local part of the IPv6 backbone). In the likely case that there are much less than 250 such dual routers serving as tunnel endpoints, we suggest using multiple IPv4 addresses selected from a single 24-bit IPv4 address prefix for this purpose. Each dual router then advertises two routes into the IPv4 region: A host route corresponding to the tunnel endpoint address specifically assigned to it, and also a standard (prefix) route to the associated IPv4 address block. Each dual host in the IPv4-only region is configured with a tunnel endpoint address which corresponds to the preferred tunnel endpoint for it to use. If the associated dual router is operating, then the packet will be delivered to it based upon the host route that it is advertising into the IPv4-only region. However, if the associated dual router is down, but some other dual router serving as a potential tunnel endpoint is operating, then the packet will be delivered to the nearest operating tunnel endpoint.
IPv6バックボーンの地方の部分を管理します) トンネル終点として多くのそのような250未満の二元的なルータ給仕がいるありそうな場合では、私たちは、ただ一つの24ビットのIPv4アドレス接頭語からこのために選択された複数のIPv4アドレスを使用することを提案します。 次に、それぞれの二元的なルータはIPv4領域に2つのルートの広告を出します: それへの明確に割り当てられたトンネル終点アドレスに対応するホストルート、および関連IPv4あて先ブロックへの標準の(接頭語)ルートも。 IPv4だけ領域のそれぞれの二元的なホストはそれが使用する都合のよいトンネル終点に一致しているトンネル終点アドレスによって構成されます。 関連二元的なルータが作動していると、パケットはそれがIPv4だけ領域に広告を出しているホストルートでそれにベースで提供されるでしょう。 しかしながら、関連二元的なルータが下がっていますが、潜在的トンネル終点として機能するある他の二元的なルータが作動していると、パケットは最も近い操作トンネル終点に提供されるでしょう。
3.3.3 Router to Host Automatic Tunneling
3.3.3 ホストの自動トンネリングへのルータ
In some cases the source host may have direct connectivity to one or more IPv6-capable routers, but the destination host might not have direct connectivity to any IPv6-capable router. In this case, provided that the destination host has an IPv4-compatible IPv6 address, normal IPv6 forwarding may be used for part of the packet's path, and router to host tunneling may be used to get the packet from an encapsulating dual router to the destination host.
いくつかの場合、送信元ホストには、ダイレクト接続性が1つ以上のIPv6できるルータまであるかもしれませんが、あて先ホストはどんなIPv6できるルータにもダイレクト接続性を持っていないかもしれません。 この場合、あて先ホストにIPv4コンパチブルIPv6アドレスがあれば、通常のIPv6推進はパケットの経路の一部に使用されるかもしれません、そして、ホストトンネリングへのルータは、要約の二元的なルータからあて先ホストまでパケットを得るのに使用されるかもしれません。
In this case, the hard part is the IPv6 routing required to deliver the IPv6 packet from the source host to the encapsulating router. For this to happen, the encapsulating router has to advertise reachability for the appropriate IPv4-compatible IPv6 addresses into the IPv6 routing region. With this approach, all IPv6 packets (including those with IPv4-compatible addresses) are routed using routes calculated from native IPv6 routing. This implies that encapsulating routers need to advertise into IPv6 routing specific route entries corresponding to any IPv4-compatible IPv6 addresses that belong to dual hosts which can be reached in an neighboring IPv4-only region. This requires manual configuration of the encapsulating routers to control which routes are to be injected into IPv6 routing protocols. Nodes in the IPv6 routing region would use such a route to forward IPv6 packets along the routed path toward the router that injected (leaked) the route, at which point packets are encapsulated and forwarded to the destination host using normal IPv4 routing.
この場合、固い部分はルーティングが送信元ホストから要約ルータまでIPv6パケットを提供するのを必要としたIPv6です。 これが起こるように、要約ルータは適切なIPv4コンパチブルIPv6アドレスのためにIPv6ルーティング領域に可到達性の広告を出さなければなりません。 このアプローチで、すべてのIPv6パケット(IPv4コンパチブルアドレスがあるそれらを含んでいる)が、固有のIPv6ルーティングから計算されたルートを使用することで発送されます。 これは、ルータが二元的なそうすることができるホストのものであるどんなIPv4コンパチブルIPv6アドレスにも対応する特定のルートエントリーのIPv6ルーティングに広告を出すために必要とする要約に隣接しているIPv4だけ領域で達しているのを含意します。 これは、IPv6ルーティング・プロトコルに注がれるためにルートがどれであるかを制御するために要約ルータの手動の構成を必要とします。 IPv6ルーティング領域のノードは、ポイントパケットが正常なIPv4ルーティングを使用することであて先ホストにカプセルに入れられて、送られるルートを注入した(漏れます)ルータに向かった発送された経路に沿ってパケットをIPv6に送るのにそのようなルートを使用するでしょう。
Depending upon the extent of the IPv4-only and dual routing regions, the leaking of routes may be relatively simple or may be more complex. For example, consider a dual Internet backbone, connected via one or two dual routers to an IPv4-only stub routing domain. In
IPv4だけと二元的なルーティング領域の範囲によって、ルートの漏出は、比較的簡単であるかもしれないか、または、より複雑であるかもしれません。 例えば、IPv4だけスタッブ経路ドメインへの1か2つの二元的なルータで接続された二元的なインターネットの基幹を考えてください。 コネ
Callon & Haskin Informational [Page 8] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[8ページ]のRFC2185ルート設定局面
this case, it is likely that there is already one summary address prefix which is being advertised into the Internet backbone in order to summarize IPv4 reachability to the stub domain. In such a case, the border routers would be configured to announce the IPv4 address prefix into the IPv4 routing within the backbone, and also announce the corresponding IPv4-compatible IPv6 address prefix into IPv6 routing within the backbone.
本件、IPv4の可到達性をスタッブドメインへまとめるためにインターネットの基幹に広告に掲載されている1つの概要アドレス接頭語が既にありそうです。 このような場合には、境界ルータは、バックボーンの中でIPv4アドレス接頭語をIPv4ルーティングに発表して、また、バックボーンの中で対応するIPv4コンパチブルIPv6アドレス接頭語をIPv6ルーティングに発表するために構成されるでしょう。
A more difficult case involves the border between a major Internet backbone which is IPv4-only, and a major Internet backbone which supports both IPv4 and IPv6. In this case, it requires that either (i) the entire IPv4 routing table be fed into IPv6 routing in the dual routing domain (implying a doubling of the size of the routing tables in the dual domain); or (ii) Manual configuration is required to determine which of the addresses contained in the Internet routing table include one or more IPv6-capable systems, and only these addresses be advertised into IPv6 routing in the dual domain.
比較的困難なケースはIPv4専用である主要なインターネットの基幹と、IPv4とIPv6の両方をサポートする主要なインターネットの基幹との境界にかかわります。 この場合、(i) 全体のIPv4経路指定テーブルが二元的な経路ドメイン(二元的なドメインの経路指定テーブルのサイズの倍増を含意する)でのIPv6ルーティングに与えられているのが必要です。 または、(ii)手動の構成が、インターネット経路指定テーブルに含まれたアドレスのどれが1台以上のIPv6できるシステムを含むか、そして、これらのアドレスだけが二元的なドメインでのIPv6ルーティングに広告を出すことを決定するのに必要です。
3.3.4 Example of How Automatic Tunnels May be Combined
3.3.4 例、How Automatic Tunnels5月では、Combinedになってください。
Clearly tunneling is useful only if communication can be achieved in both directions. However, different forms of tunneling may be used in each direction, depending upon the local environment, the form of address of the two hosts which are exchanging IPv6 packets, and the policies in use.
明確に、両方の方向にコミュニケーションを達成できる場合にだけ、トンネリングは役に立ちます。 しかしながら、異なったフォームのトンネリングは各方向に使用されるかもしれません、どれがIPv6パケット、および使用中の方針を交換しているかに地方の環境、2人のホストの敬称によって。
Table 1 summarizes the form of tunneling that will result given each possible combination of host capabilities, and given one possible set of policy decisions. This table is derived directly from the requirements for automatic tunneling discussed above.
テーブル1は1つの可能な政策決定をホスト能力のそれぞれの可能な組み合わせを与えて、考えて、結果として生じるトンネリングの書式をまとめます。 このテーブルは直接上で議論した自動トンネリングのための要件から引き出されます。
The example in table 1 uses a specific set of policy decisions: It is assumed in table 1 that the source host will transmit a native IPv6 where possible in preference over encapsulation. It is also assumed that where tunneling is needed, host to host tunneling will be preferred over host to router tunneling. Other combinations are therefore possible if other policies are used.
テーブル1の例は特定の政策決定を使用します: テーブル1では、送信元ホストがカプセル化の上で好みで可能であるところにネイティブのIPv6を送ると思われます。 また、ホスト、トンネリングが必要であるそんなにところで思われますトンネリングを接待するのがルータトンネリングへのホストの上で都合のよいのを。 したがって、他の方針が使用されているなら、他の組み合わせは可能です。
Due to a specific policy choice, the default sending rules in [1] may not be followed.
特定保険証券選択のため、[1]で規則を送るデフォルトは従われないかもしれません。
Note that IPv6-capable hosts which do not have any local IPv6 router must be given an IPv4-compatible v6 address in order to make use of their IPv6 capabilities. Thus, there are no entries for IPv6-capable hosts which have an incompatible IPv6 address and which also do not have any connectivity to any local IPv6 router. In fact, such hosts could communicate with other IPv6 hosts on the same local network without the use of a router. However, since this document focuses on
彼らのIPv6能力を利用するためにどんな地方のIPv6ルータも持っていないIPv6有能なホストにIPv4コンパチブルv6アドレスを与えなければならないことに注意してください。 したがって、IPv6有能なホストのための両立しないIPv6アドレスを持っていて、またどんな地方のIPv6ルータにもどんな接続性も持っていないエントリーが全くありません。 事実上、そのようなホストは同じ企業内情報通信網でルータの使用なしで他のIPv6ホストとコミュニケートできました。 しかしながら、オンこのドキュメント焦点以来
Callon & Haskin Informational [Page 9] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[9ページ]のRFC2185ルート設定局面
routing and router implications of IPv6 transition, direct communication between two hosts on the same local network without any intervening router is outside the scope of this document.
IPv6変遷のルーティングとルータ含意、このドキュメントの範囲の外に少しも介入しているルータのない同じ企業内情報通信網の2人のホストのダイレクトコミュニケーションがあります。
Also, table 1 does not consider manually configured point-to-point tunnels. Such tunnels are treated as if they were normal point-to- point links. Thus any two IPv6-capable devices which have a manually configured tunnel between them may be considered to be directly connected.
また、テーブル1は手動で構成された二地点間トンネルを考えません。 そのようなトンネルはまるでそれらが正常なポイントからポイントへのリンクであるかのように扱われます。 したがって、それらの間の手動で構成されたトンネルを持っているどんな2台のIPv6できるデバイスによっても直接接続されると考えられるかもしれません。
-----------------+------------------+--------------------------
Host A | Host B | Result
-----------------+------------------+--------------------------
v4-compat. addr. | v4-compat. addr. | host to host tunneling
no local v6 rtr. | no local v6 rtr. | in both directions
-----------------+------------------+--------------------------
v4-compat. addr. | v4-compat. addr. | A->B: host to host tunnel
no local v6 rtr. | local v6 rtr. | B->A: v6 forwarding plus
| | rtr->host tunnel
-----------------+------------------+--------------------------
v4-compat. addr. | incompat. addr. | A->B: host to rtr tunnel
no local v6 rtr. | local v6 rtr. | plus v6 forwarding
| | B->A: v6 forwarding plus
| | rtr to host tunnel
-----------------+------------------+--------------------------
v4-compat. addr. | v4-compat. addr. | end to end native v6
local v6 rtr. | local v6 rtr. | in both directions
-----------------+------------------+--------------------------
v4-compat. addr. | incompat. addr. | end to end native v6
local v6 rtr. | local v6 rtr. | in both directions
-----------------+------------------+--------------------------
incompat. addr. | incompat. addr. | end to end native v6
local v6 rtr. | local v6 rtr. | in both directions
-----------------+------------------+--------------------------
-----------------+------------------+-------------------------- ホストA| ホストB| 結果-----------------+------------------+-------------------------- v4-compat. addr。 | v4-compat. addr。 | どんな地方のv6 rtrもホストトンネリングに接待しないでください。 | 地方のv6 rtrがありません。 | 両方の方向に-----------------+------------------+-------------------------- v4-compat. addr。 | v4-compat. addr。 | 1>のB: どんな地方のv6 rtrもホストトンネルに接待しないでください。 | 地方のv6 rtr。 | B>A: v6推進プラス| | rtr>のホストトンネル-----------------+------------------+-------------------------- v4-compat. addr。 | incompat. addr。 | 1>のB: どんな地方のv6 rtrもrtrトンネルに接待しないでください。 | 地方のv6 rtr。 | プラスv6推進| | B>A: v6推進プラス| | ホストトンネルへのrtr-----------------+------------------+-------------------------- v4-compat. addr。 | v4-compat. addr。 | 終わって、ネイティブのv6地方のv6 rtrを終わらせてください。 | 地方のv6 rtr。 | 両方の方向に-----------------+------------------+-------------------------- v4-compat. addr。 | incompat. addr。 | 終わって、ネイティブのv6地方のv6 rtrを終わらせてください。 | 地方のv6 rtr。 | 両方の方向に-----------------+------------------+-------------------------- incompat. addr。 | incompat. addr。 | 終わって、ネイティブのv6地方のv6 rtrを終わらせてください。 | 地方のv6 rtr。 | 両方の方向に-----------------+------------------+--------------------------
Table 1: Summary of Automatic Tunneling Combinations
テーブル1: 自動トンネリング組み合わせの概要
3.3.5 Example
3.3.5 例
Figure 2 illustrates an example network with two regions A and B. Region A is dual, meaning that the routers within region A are capable of forwarding both IPv4 and IPv6. Region B is IPv4-only, implying that the routers within region B are capable of routing only IPv4. The illustrated routers R1 through R4 are dual. The illustrated routers r5 through r9 are IPv4-only. Also assume that hosts H3 through H8 are dual. Thus H7 and H8 have been upgraded to be IPv6- capable, even though they exist in a region in which the routers are not IPv6-capable. However, host h1 and h2 are IPv4-only.
図2は2つの領域Aを例のネットワークに入れます、そして、B.Region Aによる二元的です、それを意味して、領域Aの中のルータがIPv4とIPv6の両方を進めることができるということです。 領域Bの中のルータはルーティングIPv4だけができるのを含意して、領域BはIPv4専用です。 イラスト入りのルータのR1からR4はそうです。二元的。 イラスト入りのルータのr5からr9はIPv4専用です。 また、ホストのH3からH8がそうであると仮定してください。二元的。 したがって、H7とH8はできるIPv6になるようにアップグレードしました、ルータがIPv6できない領域に存在していますが。 しかしながら、ホストh1とh2はIPv4専用です。
Callon & Haskin Informational [Page 10] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[10ページ]のRFC2185ルート設定局面
......................... .......................
. . . .
. h1 . . |-h2 .
. | . . | .
. H3---R1--------R2---------------r5----r9----+ .
. | | . . | |-H7 .
. | | . . | .
. | | . . | .
. H4---R3--------R4---------------r6----r8-----H8 .
. . . .
......................... .......................
Region A (Dual Routers) Region B (IPv4-only Rtrs)
......................... ....................... . . . . . h1。|-h2。| . . | . . H3---R1--------R2---------------r5----r9----+ . . | | . . | |-H7。| | . . | . . | | . . | . . H4---R3--------R4---------------r6----r8-----H8… ....................... 領域は(二元的なルータ)領域Bです。(IPv4だけRtrs)
Figure 2: Example of Automatic Tunneling
図2: 自動トンネリングに関する例
Consider a packet from h1 to H8. In this case, since h1 is IPv4-only, it will send an IPv4 packet. This packet will traverse regions A and B as a normal IPv4 packet for the entire path. Routing will take place using normal IPv4 routing methods, with no change from the operation of the current IPv4 Internet (modulo normal advances in the operation of IPv4, of course). Similarly, consider a return packet from H8 to h1. Here again H8 will transmit an IPv4 packet, which will be forwarded as a normal IPv4 packet for the entire path.
h1からH8とパケットを考えてください。 この場合、それは、h1がIPv4専用であるので、IPv4パケットを送るでしょう。 このパケットは全体の経路への正常なIPv4パケットとして領域AとBを横断するでしょう。 ルート設定は正常なIPv4ルーティング方式を使用することで行われるでしょう、現在のIPv4インターネット(もちろんIPv4の操作における法の通常の進歩)の操作からの変化なしで。 同様に、H8からh1とリターンパケットを考えてください。 一方、ここに、H8はIPv4パケットを伝えるでしょう(全体の経路への正常なIPv4パケットとして進められるでしょう)。
Consider a packet from H3 to H8. In this case, since H8 is in an IPv4-only routing domain, we can assume that H8 uses an IPv4- compatible IPv6 address. Since both source and destination are IPv6- capable, H3 may transmit an IPv6 packet destined to H8. The packet will be forwarded as far as R2 (or R4) as an IPv6 packet.
H3からH8とパケットを考えてください。 H8がIPv4だけ経路ドメインにあって、この場合、私たちは、H8がIPv4コンパチブルIPv6アドレスを使用すると思うことができます。 ソースと目的地の両方ができるIPv6であるので、H3はH8に運命づけられたIPv6パケットを伝えるかもしれません。 IPv6パケットとしてR2(または、R4)と同じくらい遠くにパケットを送るでしょう。
Router R2 (or R4) will then encapsulate the full IPv6 packet in an IPv4 header for delivery to H8. In this case it is necessary for routing of IPv6 within region A to be capable of delivering this packet correctly to R2 (or R4). As explained in section 3.3, routers R2 and R4 may inject routes to IPv4-compatible IPv6 addresses into the IPv6 routing used within region A corresponding to the routes which are available via IPv4 routing within region B.
そして、ルータR2(または、R4)は配送のためにIPv4ヘッダーで完全なIPv6パケットをH8にカプセルに入れるでしょう。 この場合、領域Aの中のIPv6のルーティングが正しくR2(または、R4)にこのパケットを提供できるのが必要です。 セクション3.3で説明されるように、ルータのR2とR4は領域Bの中のIPv4ルーティングで利用可能なルートに対応する領域Aの中で使用されたIPv6ルーティングへのIPv4コンパチブルIPv6アドレスにルートを注入するかもしれません。
Consider a return packet from H8 to H3. Again, since both source and destination are IPv6-capable, a IPv6 packet may be transmitted by H8. However, since H8 does not have any direct connectivity to an IPv6- capable router, H8 must make use of an automatic tunnel. Which form of automatic tunnel will be used depends upon the type of address assigned to H3.
H8からH3とリターンパケットを考えてください。 一方、ソースと目的地の両方がIPv6できるので、IPv6パケットはH8によって伝えられるかもしれません。 しかしながら、H8がIPv6のできるルータにどんなダイレクト接続性も持っていないので、H8は自動トンネルを利用しなければなりません。 どの形式の自動トンネルが使用されるかはH3に割り当てられたアドレスのタイプにかかっています。
Callon & Haskin Informational [Page 11] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[11ページ]のRFC2185ルート設定局面
If H3 is assigned an IPv4-compatible address, then the requirements specified in section 3.3.1 will all be satisfied. In this case host H8 may encapsulate the full IPv6 packet in an IPv4 header using a source IPv4 address extracted from the IPv6 address of H8, and using a destination IPv4 address extracted from the IPv6 address of H3.
IPv4コンパチブルアドレスがH3に割り当てられると、セクション3.3.1で指定された要件はすべて満たされるでしょう。 この場合、ホストH8は、IPv4ヘッダーでH8のIPv6アドレスから抜粋されて、H3のIPv6アドレスから抜粋された送付先IPv4アドレスを使用することでソースIPv4アドレスを使用することで完全なIPv6パケットをカプセルに入れるかもしれません。
If H3 has an IPv6-only address, then it is not possible for H8 to extract an IPv4 address to use as the destination tunnel address from the IPv6 address of H3. In this case H8 must use host to router tunneling, as specified in section 3.3.2. In this case one or both of R2 and R4 must have been configured with a tunnel endpoint IPv4 address (R2 and R4 may use either the same address or different addresses for this purpose). R2 and/or R4 therefore advertise reachability to the tunnel endpoint address to r5 and r6 (respectively), which advertise this reachability information into region B. Also, H8 must have been configured to know which tunnel endpoint address to use for host to router tunneling. This will result in the IPv6 packet, encapsulated in an IPv4 header, to be transmitted as far as the border router R2 or R4. The border router will then strip off the IPv4 header, and forward the remaining IPv6 packet as a normal IPv6 packet using the normal IPv6 routing used in region A.
H3にIPv6だけアドレスがあるなら、H8がH3のIPv6アドレスから送付先トンネルアドレスとして使用するIPv4アドレスを抜粋するのは、可能ではありません。 この場合、H8はセクション3.3.2で指定されるようにルータトンネリングにホストを使用しなければなりません。 この場合、R2とR4の1か両方がトンネル終点IPv4アドレスによって構成されたに違いありません(R2とR4はこのために同じアドレスか異なったアドレスのどちらかを使用するかもしれません)。 したがって、R2、そして/または、R4は領域B.Alsoにこの可到達性情報の広告を出すr5とr6(それぞれ)へのトンネル終点アドレスに可到達性の広告を出して、H8は、ホストにどのトンネル終点アドレスをルータトンネリングに使用したらよいかを知るために構成されたに違いありません。 これは、境界ルータのR2かR4と同じくらい遠くに伝えられるためにIPv4ヘッダーでカプセルに入れられたIPv6パケットに結果として生じるでしょう。 正常なIPv6ルーティングを使用する正常なIPv6パケットが領域でAを使用したので、境界ルータは、次に、IPv4ヘッダーを全部はぎ取って、残っているIPv6パケットを進めるでしょう。
4. SECURITY CONSIDERATIONS
4. セキュリティ問題
Use of tunneling may violate firewalls of underlying routing infrastructure.
トンネリングの使用は基本的なルーティングインフラストラクチャのファイアウォールに違反するかもしれません。
No other security issues are discussed in this paper.
この紙で他の安全保障問題について全く議論しません。
5. REFERENCES
5. 参照
[1] Gilligan, B. and E. Nordmark. Transition Mechanisms for IPv6
Hosts and Routers, Sun Microsystems, RFC 1933, April 1996.
[1] ギリガン、B.、およびE.Nordmark。 IPv6ホストとルータのための変遷メカニズム、サン・マイクロシステムズ、RFC1933、1996年4月。
6. AUTHORS' ADDRESSES
6. 作者のアドレス
Ross Callon Cascade Communications Co. 5 Carlisle Road Westford, MA 01886 email: rcallon@casc.com
ロスCallon Cascade Communications社5のカーライルRoadウェストフォード、MA 01886はメールされます: rcallon@casc.com
Callon & Haskin Informational [Page 12] RFC 2185 Routing Aspects Of IPv6 Transition September 1997
IPv6変遷1997年9月のCallonとハスキン情報[12ページ]のRFC2185ルート設定局面
Dimitry Haskin Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 email: dhaskin@baynetworks.com
ビルリカ、ドミトリーハスキンベイネットワークスInc.2の連邦政府の通りMA 01821はメールされます: dhaskin@baynetworks.com
Callon & Haskin Informational [Page 13]
CallonとハスキンInformationalです。[13ページ]
一覧
スポンサーリンク
