第1回　移行ソリューション、その選択肢を知る


A10ネットワークス株式会社
山村剛久
2012/3/26

それでも残るIPv4サーバへのアクセスを確保、「NAT64」
図3　NAT64のアーキテクチャ（クリックすると拡大します）

■ネットワーク構成

IPv6（端末）←→IPv6（ISP／アクセス回線）←→IPv4（宛先）

■通信手法

NAT

■概要

　この手法は、クライアントがIPv6、アクセスラインがIPv6、宛先がIPv4（パブリック／プライベート）のケースに適用できます。

　いずれインターネットの世界がより進んでIPv6のネットワークが一般的になったとしても、ホストしているレガシーなアプリケーションの制約などから、依然としてIPv4のサーバは残るでしょう。この手法を使えば、DNSによる名前解決を行ったあとに、IPv6クライアントからIPv4サーバへ接続することが可能となります。

　IPv4アドレスはAレコードとしてDNSサーバに登録されていますが、IPv6クライアントはAレコードのアドレスは理解できません。そのため、NAT64／DNS64対応機器で、AレコードからIPv6端末が理解できるAAAAレコードへ変換するなどの調整を行います。

　こうしてIPv6のアドレス解決がされた後は、ユーザーからのパケットをIPv6からIPv4へNATして転送することで、通信可能となります。

ロードバランスとの一石二鳥、「SLB-PT」
図4　SLB-PTのアーキテクチャ

■ネットワーク構成

IPv6（端末）←→IPv6（ISP／アクセス回線）←→IPv4（宛先）
IPv4（端末）←→IPv4（ISP／アクセス回線）←→IPv6（宛先）

■通信手法

NAT

■概要

　この手法は、IPv4／IPv6いずれのクライアントからも、IPv4／IPv6のいずれのサーバに対しても、NATとロードバランスをさせて通信可能とするものです。NAT変換後の接続先は、NAT64／DNS64の場合にはネットワーク（イントラネットもしくはインターネット）ですが、SLB-PTの場合は直結されたサーバ（群）となります。

　この場合、DNS64のようなA/AAAAレコードの変換は不要です。SLB-PTを行うデバイスのバーチャルIP（VIP）のアドレスをA/AAAAレコードとして登録しておけば構いません。

　自組織内のIPv4サーバを手っ取り早くIPv6化するには便利な手法です。NATはもとより、ロードバランスも行うので、パフォーマンスや安定性の向上も同時に見込むことができます。

アクセスラインが取り残された場合には「6rd」
図5　6rdのアーキテクチャ

■ネットワーク構成

IPv6（端末）←→IPv4（ISP／アクセス回線）←→IPv6（宛先）

■通信手法

トンネル（IPv6 over IPv4）

■概要

　この手法はDS-Liteと真逆のネットワーク構成で、宅内がIPv6クライアント、アクセスラインがIPv4、宛先がIPv6のケースです。つまりアクセスラインだけIPv4が残ってしまった場合に有効な手法です。アクセスライン上はIPv6 over IPv4でトンネリングを行い、対向のIPv6ネットワークへ転送します。

　宅内にIPv4クライアントも混在している場合には、IPv4アクセスライン経由でそのままIPv4ネットワークとの通信も可能です。

移行ソリューション導入時の注意点

　5種類のソリューションについて説明しましたが、ここまで見てきたように、ネットワーク経路上のIPv6化されている場所によって、取り得るアプローチは異なってきます。

　また、これらのソリューションにより、IPv4←→IPv6のIPアドレスの相互接続性は担保されます。しかしながら、実際に通信を行ってみると問題が発生する場合があります。これは、IPv4／IPv6のプロトコル仕様やその実装、サーバでホストしているアプリケーションの実装などに依存する問題があるためです。

　以下のようなケースでは、通信経路上のデバイスでの対応が必要となる場合が考えられます。

  • パケットのペイロードの部分にオリジナルのIPアドレスが埋め込まれているようなアプリケーションの通信で発生する問題（IPv4／IPv6アドレスを変換したとしても、ペイロード内のアドレスがオリジナルのままであれば、通信エラーが発生するなど）

    →ALG（Application Layer Gateway）機能により、ペイロードの中のIPv4／IPv6アドレスも同じく変換することが必要です。変換できるアプリケーションの種類などは、ネットワークデバイスにより異なります。

  • IPv4／IPv6のパケットの変換やカプセル化（トンネリングなどの手法の場合）などに起因するMTUサイズの問題（途中経路の最大MTUを超えないように調整する手順）

    →IPv4／IPv6 Path MTU DiscoveryやMSS clampingなどの機能で、パケットサイズの調整を行います。

  • NAT変換（IPv4←→IPv6、IPv4←→IPv4、IPv6←→IPv4）による通信ログ保存の問題（犯罪捜査などへ協力のためのアドレストレーサビリティが必要です）

    →ハイパフォーマンスなログ収集ソリューション／デバイスが必要となります。

　こういった課題を考慮しながら移行ソリューションを実装していくことが重要です。

さて、どこから手を付けよう？

　ここまでご紹介した内容に基づいて、どの手法で、どこからIPv6に対応させようか？と思っていただければ幸いです。

　おそらく、この記事を読んでいる皆さんが一番先に検討したいことは、IPv6クライアントとIPv4サーバの相互接続ではないでしょうか。Windows 7やMac OS X LionなどのクライアントOSはネイティブでIPv6に対応しています。ユーザーの手元の端末はすでにIPv6 readyなのです。一方、すでに稼働中のWebサーバやアプリケーションサーバは、ほとんどがIPv4ベースのままなのですから。

　次回からは、先にご紹介したNAT64／DNS64やSLB-PTの実装方法を、実際のネットワークデザインや設定も交えてご紹介していきたいと思います。NAT64／DNS64やSLB-PTの手法を活用すれば、IPv6クライアントからIPv4サーバへのアクセスなどが可能となります。この記事が、小さな環境からIPv6化を徐々に進めて、運用ノウハウを蓄積しながら移行を進める助けになれば幸いです。
第1回　「移行ソリューション、その選択肢を知る」
  現実となったIPv6移行の日
さまざまなIPv4／IPv6移行ソリューション
IPv4延命策の「LSN（CGN）」
アクセスラインが先にIPv6化しているなら「DS-Lite」
それでも残るIPv4サーバへのアクセスを確保、「NAT64」
ロードバランスとの一石二鳥、「SLB-PT」
アクセスラインが取り残された場合には「6rd」
移行ソリューション導入時の注意点
さて、どこから手を付けよう？
「Master of IP Network総合インデックス」

　



Master of IP Network フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Master of IP Network 記事ランキング

本日 月間
＠IT