KDDI研究所が、埼玉県上福岡市にある端末約200台規模の研究所をIPv6化するきっかけとなったのは、研究所長である浅見徹氏の一声だったという。上福岡の研究所内のネットワークは数年前からIPv4/IPv6のデュアルプロトコル環境だった。DNS、メール、Webの各サーバもIPv4とIPv6のデュアルプロトコル構成になっていたが、端末としてIPv6を使うのはIPv6関連の研究用のものだけに限られており、一般的な端末にはIPv4しか導入していない状況だった。
浅見氏の考えは、「IPv6で新しいサービスを開発していく立場にあるにもかかわらず、IPv6を使っていないのはおかしい」。そこで研究所の完全IPv6化プロジェクトがスタートした。
「IPv6しか使わない」を可能な限り推進
一般端末にIPv6プロトコルを追加してデュアルスタックにするだけでは、結局IPv4が使われることになってしまう。そこで、KDDI研究所では、一般端末をIPv6オンリーとすることにした。同研究所では、ユーザ端末のほとんどが、Windows 2000やWindows 98を含むWindowsファミリを利用していた。UNIXやLinuxを使う研究所員もいるが、こうした人でも業務書類等の関係からWindows端末は必ず利用しており、リモートでUNIXやLinuxのアプリケーションを動かしている。同研究所では、これらすべてのWindows端末をWindows XPに統一し、さらにIPv6だけを有効とした。これらの端末で所員は、Web、電子メール、FTPにより、日常業務を行う。
;) |
| IPｖ６専用網移行前の構成 |
;) |
| IPｖ６ 専用網移行後の構成 |
DMZに設置されているインターネットサービスサーバ群はすでにデュアルスタック化されているので、これについては従来通りのままとした。一般端末は、DNSや電子メールサーバにIPv6でアクセスし、サービスを受ける。一部のVLANセグメント内にもDNSや電子メールサーバがあったが、これらはIPv6オンリーにした。
ただし、管理部門の利用するシステムが、IPv6対応していないものを、無理やり対応させるのは困難だ。そこで業務上、どうしてもIPv4を使わなければならない端末については、IPv4オンリーのVLANセグメントに収容した。
インターネット上のWebサーバは、ほとんどIPv4なので、これらに対してIPv6端末からアクセスできるようにするため、インターネットとの接続点に、NATPT型のIPv4/IPv6トランスレータを新規設置した。また、KDDI研究所では、外部から所内ネットワークへのリモートアクセス用に、Cisco VPN（IPsec）を運用してきたが、所内ネットワークがIPv6化されるのに伴い、ISATAPルータを設置し、動的なIPv6 over IPv4トンネリングを実現した。
サーバに関連した問題の発生と対策
一般端末の業務アプリケーションをWeb、電子メール、FTPに限定したこともあり、現在では日常業務への支障はそれほどないが、当初は予想もしなかった多数の問題に悩まされたという。そのうち、サーバ関連は以下のようなものがあった。
- sendmailのスパムチェック処理での問題
KDDI研究所では、電子メールサーバにsendmailを利用し、スパムメール対策として、送信者をチェックするcheck_mailルーチンを動かしている。IPv6オンリーネットワークへの移行当初、「DNSにAAAAレコード（IPv6アドレス）は登録されていてもAレコード（IPv4アドレス）の登録がないメールサーバからのメールをスパムだと判断し、受信拒否してしまうという問題が起こった」（IPv6化を指揮する特命先端研究グループ プロジェクトリーダーの久保孝弘氏）。もちろん、一般的なメールサーバでIPv4アドレスの登録をしていないものはなく、これはIPv6オンリーのVLANセグメントに置いたメールサーバだった。これに対し、仮のIPv4アドレスでこのサーバのAレコードをDNSに追加して解決した。
- IPv4 WebアクセスにおけるDNSとトランスレータの問題
現在インターネット上で運用されているDNSサーバには、AAAAでの問い合わせに対し、AAAAレコードがないという答えを返さず、無応答のものがある。通常、Internet ExplorerなどのIPv6対応Webブラウザは、URLが入力されると、DNSにまずAAAAレコードを問い合わせ、IPv6でのアクセスを試みる。DNSから「AAAAレコードがない」という返事を受けると、今度はAレコードを問い合わせ、IPv4でのアクセスを試みるような実装になっている。ところがAAAAレコードの問い合わせに対し、DNSが返事を返さないと、自分でタイムアウトするまで待たされてしまうことになる。これは、最近知られるようになってきた問題で、WIDEプロジェクトもIPv6 FIXという活動の一環として、その解決に取り組んでいる（http://v6fix.net/）。
この問題は、DNSの無応答問題が改善されない限り、根本的には解決できない。しかし、「AAAAレコードでの応答待ちを短くし、Aレコードでの検索に切り替えるようトランスレータの設定を調整している」（IPv6インフラの管理を担当する特命先端研究グループ研究主査の阿部幹雄氏）という。
また、KDDI研究所では、ＩＰｖ4オンリーのWebサーバへのアクセスをNATPT型のIPv4/IPv6トランスレータ経由で行っている。トランスレータは、上記のようなDNSに遭遇したために、当初待たされたとしても、IPv6ユーザがアクセスするIPv4 WebサーバのIPｖ4アドレスをDNSから得た時点で、ＩPv6アドレスに変換してユーザに渡すとともに、アドレス変換テーブルを一定時間保持するため、この時間中は安定したアクセスが可能だ。しかし、これを超えるとエントリが消えるため、再び長い待ち時間が発生し、ブラウザが先にタイムアウトしてしまうという現象が発生した。具体的には、フォーム入力を終えて送信しようとすると失敗するといった苦情が報告された。
- WebコンテンツにIPv4アドレスが直書きされている
ごく一部のWebサーバで、リンクアドレスとしてIPv4アドレスが直書きされているケースがある。「hotmailのメール送信のボタンの画像のリンクアドレスにIPv4アドレスが書かれていて、このボタンが見えないという問題が発生した」（久保氏）という。これも根本的な解決策は、Webサーバ側にFQDNで記述してもらうしかないが、ユーザ側の対策としてはWebプロキシの利用で回避しているという。（現在hotmailはFQDNに修正されている）
- Path MTU Discoveryブラックホールの問題
KDDI研究所では、Cisco VPNを外から所内ネットワークへのリモートアクセスに使ってきたが、これにISATAPを組み合わせてIPv6アクセスを実現した。つまり、所内ネットワークのIPv6化に伴い、Cisco VPNでカプセル化されたIPv4パケットに、IPv6パケットをカプセル化して通すということになった。Cisco VPNルータのMTUのデフォルト値は1460になっている。そして、ISATAPサーバからのRAのMTUサイズも1460になっていたので、ISATAPによるカプセル化後はCisco VPNのMTU値よりも大きくなってしまう。そのため、Path MTU Discoveryブラックホールになり、Web等で通信が途中で停止してしまう。そこで、RAのMTUサイズが1280になるようにISATAPルータの設定を変更した。
- ISATAPのバッチファイルの問題
当初は、リモートアクセスでISATAPを利用するユーザのために、ISATAPサーバを指定し、MTUサイズを指定するためのバッチファイルをつくった。ユーザは、VPNでまずログインしてからバッチファイルを起動する。それでも1回でIPv6アドレスがもらえない場合がある。「当初はコマンドラインで確認してくれといっていたが、それでは煩雑でユーザには非常に不評だった。検索するプライマリドメイン名とISATAPという名前の組み合わせでDNSサーバにISATAPサーバを登録しておくと、自動的にIPv6アドレスが生成されるということが分かったので、これを利用している。これにより、ユーザはCisco VPNクライアントを起動して接続するだけでよくなった」（久保氏）という。
サーバにおいて当初発生したおもな問題は上の通りだが、端末側ではさらに多くの問題が発生した。後編では、これについて紹介する。
