02-05 IPv4との共存

IPv4とIPv6をどのように共存するのが良いのかが読者の一番知りたいところだろう。
結論から先に言ってしまうと、IPv4/IPv6のデュアルスタックにするのが一番現実的な解になる。
デュアルスタックの場合は、IPv6に移行するのではなく、既存のIPv4ネットワークにIPv6を追加するイメージだ。

デュアルスタック以外の方法も含めてIPv4とIPv6の共存方法と、そのメリットデメリットを考えてみよう。

デュアルスタック

IPv6対応の一般的なOSでは、IPv4/IPv6のデュアルスタックが標準で実装されてるので、PCでのIPv4/IPv6共存はデュアルスタックが一番簡単な共存方法だ。
デュアルスタックの一番のメリットは、ターゲットノードがIPv4しか対応できていない場合や、IPv6にしか対応していない場合であっても、自動的にIPv4/IPv6が切り替わって接続するので、IPv4しか対応できないNASや複合機、あるいは業務システムを含めたサーバをそのまま利用し続ける事が出来る点だ。
インターネット上でサービスを提供しているサーバーも、今後徐々にIPv6アドレスしか持たないサーバーが出てくることになるのだが、クライアントPCがデュアルスタックになっていれば、これらに対して新たな対応は必要ない。

[ デュアルスタック ]

また、家庭やモバイルでインターネット接続している一般ユーザーも、徐々にIPv4アドレスの割り当てが厳しくなり、LSNなどの対策が講じられることになるし、LSN自体が破綻した時にはIPv6アドレスしか割り当てられないユーザーも出てくることになる。

このような事態になった時に、インターネット公開サーバーがIPv4アドレスしか持ってない場合は、利用者に対してサービスが提供できない事態になってしまうのだ。

良い事づくめのデュアルスタックであるが、悩ましいのが管理面だ。
IPv4とIPv6は別物なので、IPアドレスやルーティング管理もIPv4/IPv6を別物として考えなくてはならないので、完全に二重管理になってしまう。
トラブルシューティングもIPv4の問題なのか、IPv6の問題なのかの切り分けポイントが増えることになるので、ネットワーク管理者への負担が大きくなるのが最大の欠点と言えるだろう。

機器によってはIPv6対応がオプション扱いになっており、別途オプションやライセンスを購入しなくてはならないもの悩みの種だ。
これはIPv6普及とともに標準装備になっていくと予想されるので、執筆をしている今だけの問題かもしれない。

内部ネットワークをIPv4のままにする

NAT-PTやNAPT-PT(*1)や、インターネット側がデュアルスタックになっているproxyをインターネット境界に配置し、サイトの内側はIPv4だけで運用をし続けるという手法だ。

機器として執筆段階ではあまり数は出回っていないが、このような機能を持った機器も存在はする。

ただし、NAT-PT、NAPT-PTの仕様であるRFC2766は、問題点がRFC4966で指摘されており、Historic扱いとなったので、今後製品仕様として採用される可能性は低いと予想される。

LAN側はIPv4だけになるので、管理者の負担はIPv4/IPv6変換装置の管理が増えるだけで済むので、比較的現実的な解に思えるが、これらの機器は執筆段階で高価な機器しか存在しておらず、気楽に導入できる代物ではない。
また、未知のIPv6サービスが登場した時にこれらの機器が対応できるかが不安材料として残るのもデメリットだ。

[ IPv4で運用する ]

インターネット公開サーバーの場合、ミドルボックスでIPv6アドレスとIPv4アドレスをスタティックにマッピングする必要が出てくるし、ミドルボックスがSPOF(*2)になってしまうので、ミドルボックスを冗長化する必要も出てくるだろう。

ハイトラフィックサイトで、ロードバランサーを導入している場合は、ミドルボックスとの組み合わせで、更に構成が複雑になる事もありうる。

IPv6だけで運用する

サイトの内側をIPv6だけで運用し、インターネット境界でProxy又はNAT64でIPv4に逆変換するパターンがこの方法だ。

[ IPv6で運用する ]

ルーティング管理はIPv6だけになるので、IPv4との二重管理は不要だし、NAT64やproxy管理が増えるだけなので、一見現実味がありそうな方法ではあるが、周りを見渡すとIPv4しか対応していない機器もかなりの数稼働しているはずだ。これらの機器をすべてリプレースするコストは決してバカにならない。
更に、業務システムで使用しているサーバーをIPv6対応にする場合、動作プラットフォームがIPv4だけしかサポートしていないサーバーで稼働している場合は、フルスクラッチ開発(現在稼働しているシステムを捨てて、ゼロから再開発)しなくてはならないケースも想定されるし、IPv6対応プラットフォームで稼働しているシステムであっても、IPv6での動作確認と、必要に応じた改修が必要になる事も想定されるので、コストがどのくらいかかるのか読み切れない所も出てくる。

一番悩ましいのが、IPv4からIPv6への移行だ。小規模ネットワークであれば土日祝祭日で一気にネットワーク切替をすることも不可能ではないが、ある程度の規模があるネットワークでは段階的にIPv6への移行をせざるを得ない。その際に、IPv4とIPv6を如何に共存させるのかを考えなくてはならない事になり、結局移行中はデュアルスタックなどの方式を取らざるを得ないので、IPv6だけに移行するのは、かなりハードルが高い選択だ。

結局どうするが一番良いのか

いずれの方法も一長一短があるが、筆者が一番現実的だと考えるのがIPv4/IPv6デュアルスタックだ。
最新のOSはすべてデュアルスタックに対応しているので、OSをリプレース下高買いでデュアルスタックレディ状態になる。
デュアルスタックが現状で一番現実的なIPv4とIPv6の共存方法であるが、L3中継装置のIPv6対応など、大なり小なりのコスト(費用だけではなく、技術力であったり時間)が必要IPv6導入の悩みだ。

ISPによっては、一般家庭に対してIPv6を無料で提供しているところもあるが、IPv6が有料オプション扱いになってるISPも執筆段階ではそれなりの数が存在している、一般家庭で以前から使用されているブロードバンドルーターは、IPv6に対応していないものが多いので、この交換費用も必要だ。
IPv4アドレス枯渇と言うやむにやまれぬマイナスイメージのだけではなく、IPv6ならではのビジネスがインターネットに展開されないと、本当の意味でのIPv6普及は進まないのかもしれない。

-------------------------------------

(*1)
NAT-PT(network address translation - protocol translation)
NAPT-PT(network address port translation - protocol translation)
IPv4のNATやNAPTに加え、IPv4とIPv6のプロトコル変換もする

(*2)SPOF(Single Point of Failure)
単一障害点

>> 02-06 IPv6では重要な役割を担うICMPv6とリンクローカルアドレス