Solaris オペレーティングシステムには、IPv4 アドレス指定から IPv6 アドレス指定へ移行するための暫定的な推奨方法として 6to4 が含まれています。独立した IPv6 サイトで 6to4 を利用すると、IPv6 をサポートしない IPv4 ネットワーク上で自動トンネルを介して通信できます。6to4 トンネルを使用するには、IPv6 ネットワーク上の境界ルーターを 6to4 自動トンネルの一方のエンドポイントとして設定する必要があります。そのあと、この 6to4 ルーターをほかの 6to4 サイトとの間のトンネルの構成要素として使用することも、あるいは必要に応じて 6to4 以外のネイティブ IPv6 サイトとの間のトンネルで使用することもできます。
6to4 トンネルのトポロジ
6to4 アドレス指定 (通知の書式など)
6to4 トンネルを介したパケットフローの説明
6to4 ルーターと 6to4 リレールーター間のトンネルのトポロジ
6to4 リレールーターサポートを設定する前の考慮事項
6to4 ルーティングについての詳細は、以下のページ / 文書を参照してください。
作業または技術情報 |
参照先 |
---|---|
6to4 ルーティングの概要 | |
6to4 サイトの設定作業 | |
6to4 関連の RFC、『Connection of IPv6 Domains via IPv4 Clouds』 | |
6to4 リレールーターとの間のトンネルのサポートを有効にする 6to4relay コマンドの詳細 |
6to4relay(1M) のマニュアルページ |
6to4 のセキュリティ問題についてのインターネット文書、『Security Considerations for 6to4』 |
次の図は、2 つの 6to4 サイト間の 6to4 トンネルを示しています。
この図は、独立した 2 つの 6to4 ネットワーク、サイト A とサイト B を示しています。各サイトは、IPv4 ネットワークに外部接続するようにルーターを設定してあります。この図では、IPv4 ネットワークを介した 6to4 トンネルによって 6to4 サイトが接続されています。
IPv6 サイトを 6to4 サイトにするには、6to4 をサポートできるように 1 つ以上のルーターインタフェースを設定する必要があります。このインタフェースは、IPv4 ネットワークに対する外部接続を提供する必要があります。qfe0 で設定するアドレスは、一意 (世界で唯一) のものでなければなりません。上記の図では、境界ルーター A のインタフェース qfe0 によってサイト A が IPv4 ネットワークに接続されています。qfe0 を 6to4 擬似インタフェースとして設定するには、IPv4 アドレスを使用してあらかじめインタフェース qfe0 を設定しておく必要があります。
上記の図では、6to4 サイト A はルーター A 上のインタフェース hme0 と hme1 に接続した 2 つのサブネットから構成されています。サイト A の両サブネットのすべての IPv6 ホストは、ルーター A からの通知を受け取ると 6to4 派生アドレスを使用して自動的に再設定を行います。
サイト B は、サイト A からのトンネルの反対側のエンドポイントにあたります。サイト A からトラフィックを正しく受け取るには、サイト B 側の境界ルーターを 6to4 をサポートするように設定する必要があります。この設定を行わないと、ルーターがサイト A から受け取るパケットが認識されずに削除されてしまいます。
ネイティブ IPv6 ルーターの場合と同様に、/etc/inet/ndpd.conf の中の 6to4 プレフィックスから派生したサブネットプレフィックスを通知する必要があります。次の図は、6to4 サイトのプレフィックスの構成を示しています。各部の説明は、6to4 プレフィックスの書式と6to4 通知の例を参照してください。
次の図は、ndpd.conf ファイルに指定する 6to4 サイトのサブネットプレフィックスの構成を示しています。
構成要素 |
長さ |
定義 |
---|---|---|
プレフィックス |
16 ビット |
6to4 プレフィックス 2002 (0x2002) |
IPv4 アドレス |
32 ビット |
6to4 インタフェースですでに設定されている一意の IPv4 アドレス。通知のために、ドット付きの 10 進表記ではなく 16 進表記の IPv4 アドレスを指定する |
Subnet ID |
16 ビット |
サブネット ID。これは、6to4 サイトにおけるリンクで一意となる値でなければならない |
通知の要素 |
対応する値 |
---|---|
6to4 プレフィックス |
2002 |
IPv4 アドレス |
8192:56bb。これは IPv4 アドレス 129.146.87.188 に対応するもの |
Subnet ID |
1 |
/64 |
プレフィックスの長さ |
ルーター通知によって 6to4 派生のプレフィックスを受信する際、IPv6 ホストはインタフェース上の 6to4 派生アドレスを自動的に設定し直します。このアドレスの書式は以下のとおりです。
prefix:IPv4 address:subnet ID:host ID/64 |
6to4 インタフェースを持つホストで ifconfig –a を実行すると、以下のような結果となります。
qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 7 inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 |
6to4 派生アドレスは、ifconfig の出力結果の中で inet6 のあとに続きます。
アドレスの構成要素 |
対応する値 |
---|---|
Prefix |
2002。これは 6to4 プレフィックス |
IPv4 value |
8192:56bb。これは、6to4 ルーターで設定されている 6to4 擬似インタフェースに対する 16 進表記による IPv4 アドレス |
subnet ID |
9258。これは、このホストの所属先であるサブネットのアドレス |
MAC address |
a00:20ff:fea9:4521。これは、現在 6to4 に設定されているホストインタフェースのリンク層アドレス |
この節では、1 つの 6to4 サイトにあるホストから遠隔の 6to4 サイト内のホストへのパケットの経路について説明します。次のシナリオは、例として 図 4–3 で示しているトポロジを使用しています。このシナリオは、6to4 ルーターと 6to4 ホストがすでに設定済みであることを想定しています。
6to4 サイト A のサブネット 1 に存在するホストが伝送を行い、6to4 サイト B 上のホストが宛先として機能します。フロー内の各パケットヘッダーには、送信元の 6to4 派生アドレスと宛先の 6to4 派生アドレスが含まれます。
6to4 ルーター A は、出力パケットを受け取り、IPv4 ネットワーク上で 6to4 サイト B との間のトンネルを構築します。
サイト A のルーターは、IPv4 ヘッダーを付けて各 6to4 パケットをカプセル化します。続いてサイト A のルーターは、標準の IPv4 ルーティング手続きを使用し IPv4 ネットワークを介してこのパケットを転送します。
パケットが遭遇する IPv4 ルーターが、パケットの宛先 IPv4 アドレスを使用して転送を行います。このアドレスはルーター B のインタフェースに使用される一意の (世界に 1 つしかない) IPv4 アドレスであり、6to4 擬似インタフェースとしても機能します。
サイト A から送付されたパケットがルーター B に到着します。ルーター B は、IPv4 ヘッダーを削除して IPv6 パケットのカプセル化を解除します。
続いてルーター B は、IPv6 パケット内の宛先アドレスを使用してサイト B の受信ホストにパケットを転送します。
6to4 リレールーターは、6to4 ではない ネイティブ IPv6 ネットワークと通信を行う必要がある 6to4 ルーターからのトンネルのエンドポイントとして機能します。本来、リレールーターは 6to4 サイトとネイティブ IPv6 サイトとの間のブリッジとして使用されます。この手法は安全ではないため、Solaris オペレーティングシステムのデフォルト設定では 6to4 リレールーターのサポートは無効になっています。しかし、サイトでこのようなトンネルが必要な場合には 6to4relay コマンドを使用して以下に示すようなトンネリングを有効にすることができます。
図 4–6 では、6to4 サイト A はネイティブ IPv6 サイト B に存在するノードと通信を行う必要があります。この図は、サイト A から IPv4 ネットワーク経由の 6to4 トンネルへと続くトラフィックの経路を示しています。このトンネルは、6to4 ルーター A と 6to4 リレールーターをエンドポイントとして使用しています。6to4 リレールーターより先は IPv6 ネットワークであり、IPv6 サイト B はこのネットワークに接続されています。
この節では、6to4 サイトからネイティブ IPv6 サイトに対するパケットフローについて説明します。ここでは、図 4–6 で示されているシナリオを例として使用しています。
6to4 サイト A 上のホストから、ネイティブ IPv6 サイト B 上のホストに向けて伝送を行います。フロー内の各パケットヘッダーには、その発信元アドレスとして 6to4 派生アドレスが指定されています。宛先アドレスは標準の IPv6 アドレスです。
6to4 ルーター A は、出力パケットを受け取り、IPv4 ネットワーク上で 6to4 リレールーターとの間のトンネルを構築します。
6to4 リレールーターエニーキャストグループの一部である 6to4 リレールーターには、192.88.99.1 というアドレスが割り当てられます。このエニーキャストアドレスは、6to4 リレールーターのデフォルトアドレスです。特定の 6to4 リレールーターを使用する必要がある場合は、デフォルトを上書きしてそのルーターの IPv4 アドレスを指定できます。
サイト A の 6to4 ルーターは、各パケットを宛先である 6to4 ルーターの IPv4 アドレスを持つ IPv4 ヘッダーとともにカプセル化します。この 6to4 ルーターは、標準の IPv4 ルーティング手続きを使用し IPv4 ネットワークを介してこのパケットを転送します。パケットが遭遇する IPv4 ルーターが、6to4 リレールーターにパケットを転送します。
サイト A に物理的にもっとも近いエニーキャスト 6to4 リレールーターが、192.88.99.1 エニーキャストグループ宛てのパケットを検出します。
このリレールーターは、IPv4 ヘッダーを取り除いて 6to4 パケットのカプセル化を解除し、ネイティブ IPv6 宛先アドレスを明らかにします。
続いてこのリレールーターは、IPv6 のみとなったパケットを IPv6 ネットワークに送信します。IPv6 ネットワークにおいて、パケットは最終的に Site B のルーターによって検出されます。続いてこのルーターが、宛先である IPv6 ノードにパケットを転送します。
本来、6to4 ルーターと 6to4 リレールーター間のトンネルは安全ではありません。これらのルーター間のトンネルには、以下のようなセキュリティ問題が内在しています。
6to4 リレールーターはパケットのカプセル化とカプセル化の解除を行いますが、パケット内に含まれるデータのチェックは行いません。
アドレスのスプーフィングは、6to4 リレールーターとの間で構築されるトンネルにおける際立った問題です。着信トラックについては、6to4 ルーターはリレールーターの IPv4 アドレスを送信元の IPv6 アドレスと対応させることができないという問題があります。このため、IPv6 ホストのアドレスは簡単にスプーフィングされかねません。6to4 リレールーターのアドレスもスプーフィングの可能性があります。
デフォルトの設定では、6to4 ルーターと 6to4 リレールーター間に信頼できるメカニズムは存在しません。したがって、6to4 ルーターは 6to4 リレールーターが信頼できるものであるかどうかを識別できず、正規の 6to4 リレールーターであるかすら確認できません。このようなことから、6to4 サイトと宛先の IPv6 サイト間に信頼関係が存在していることか、あるいは攻撃を受けるという可能性を両サイトとも受け入れることが求められます。
これらの問題を始めとする 6to4 リレールーターのセキュリティ問題については、インターネット文書『Security Considerations for 6to4』で説明されています。一般には、6to4 リレールーターのサポートは以下のような場合だけ検討してください。
信頼できるプライベートな IPv6 ネットワークとの間で 6to4 サイトが通信を行う場合。たとえば、独立した 6to4 サイトとネイティブ IPv6 サイトから構成されるキャンパスネットワーク上などでこのサポートを有効にすると便利かもしれません。
ビジネス上の理由で、6to4 サイトと特定のネイティブ IPv6 ホストとの通信を避けることができない場合。
インターネット文書『Security Considerations for 6to4』で提唱されている検査と信頼できるモデルを導入した場合。
4709338 – 静的な経路を認識する RIPng 実装が必要である
4152864 – 同じ tsrc と tdst のペアによる 2 つのトンネルの設定
6to4 境界ルーターが設置された 6to4 サイトでは、以下の問題が発生します。6to4 擬似インタフェースを設定する場合に 6to4 ルーターのルーティングテーブルに静的経路 2002::/16 が自動的に追加されます。バグ 4709338 は、この静的経路が 6to4 サイトに通知されることを防ぐ Solaris RIPng ルーティングプロトコルにおける制限について説明しています。
バグ 4709338 に対しては、以下に示す回避策のどちらかを適用できます。
6to4 サイト内のイントラサイトルーターすべてのルーティングテーブルに静的経路 2002::/16 を追加する
6to4 サイトの内部ルーターに RIPng 以外のルーティングプロトコルを使用する
バグ ID 4152864 は、同じトンネル発信元アドレスを使用して 2 つのトンネルが設定される場合に発生する問題について説明しています。これは、6to4 トンネルの重大な問題です。
同じトンネル発信元アドレスを使用して 6to4 トンネルと自動トンネルを設定することは避けてください。