

私自身,IPv6とのかかわりはそれほど古い方ではない。というのも,IPv4の既存ネットワークで提供するアプリケーションの設計や実装に多くかかわってきて,現状のネットワークに対して不満も疑問も持っていなかったということがある。48ビットのプレフィクスをもらっていったい何に使おうか,それを現実に考え始めた時,どうすればIPv6の環境を提供できるかということに興味が沸いたというのが,IPv6に取り組み始めたきっかけである。
フリービットでは,IPv4の既存ネットワーク環境でIPv6化できるFeel6 Technologyを開発し,その接続性などを確認するための実証実験「Feel6 Farm」を展開している。この実験は,IPv6の普及に向けて,誰もが簡単にIPv6を導入できるようにするための環境整備を目的としている。こうした実験を通して,実際にIPv6化した未来にどのようなことが起こるのか,また,接続性を提供するプロバイダ側では,どのような体制を取り,どんなサービスができるのかを模索していくことが,これから実際にIPv6を使っていく上で必要になってくると思う。
Feel6 Farmの構築においては,IPv6の接続性を提供するためにさまざまなサーバーやアプリを作成する必要があった。今回の実験では,IPv6ネットワークへの接続にトンネル技術を用いることが決まっていたので,トンネルを動的に管理する比較的大規模なシステムを構築しなければならなかった。トンネルを終端するルーターは,終端できるトンネルの数に限界があるので,これを効率良く運用する必要があったのだ。
こういった背景から,動的にトンネルを制御するためのプロトコルを選定することになった。プロトコル選定では,いくつかの有力候補を選び出し,それぞれの特徴をフリービットの技術者が中心となってレビューして決めるというプロセスを採用した。候補としては,TSP(tunnel setup protocol)とDTCP(dynamic tunnel configuration protocol)がすぐに挙がった。前者はfreenet6がこれを用いてトンネル接続を提供しているという実績があった。後者はオーストラリアのTrumpet Software International社が提唱しているプロトコルであるが,すでにこれを用いて実験的な接続環境を提供しているサービスが生まれていた。
プロトコルの最終的な選定ポイントは,主にセッション管理機能をどのように実装するかということに集約されていった。なぜなら,ユーザーがいつトンネルを使い始めて,いつやめるのかを常に把握できる構造を持たせた方が,トンネルというリソースを適正に配分しやすいと考えられるからだ。この視点で見てみると,TSPはステートレスなため,ユーザーのネットワーク接続状態をリアルタイムに管理することが難しかった。これに対してDTCPは必ずクライアントの存在確認(keep-alive)を実施する仕様となっているため,これをセッション管理のキーとすることができる。さらに,実装のしやすさや,既存のDTCPクライアントの存在も考慮にいれ,最終的にDTCPを採用することにした。
こうしてDTCPの実装を始めたが,すぐにプロトコル仕様的に避けられない問題に直面した。DTCPはIPv4のTCPセッションをkeep-aliveとして用いるため,クライアントの数が増えてくると,このIPv4のセッションを制御するサーバーのリソースが足りなくなってくることだ。この問題に関しては,DTCPサーバーを複数台で構成できるようなサーバー管理構造を実装したり,すべてのサーバーを64ビット・マシンにするなどして対処した。
一般に,こういった類いの問題は,想定するサービスの規模や,サーバー構成などに大きく影響されるので,実装方法や実現方法は一通りでない。そのため,比較的小規模の実験環境においては見過ごされてきた事柄を,今回,突き詰めてシステム化する必要があった。
サーバーやその周辺システムの仕様はほぼ固まったが,実際に接続するにはクライアントが必要である。そこでフリービットでは,専用のDTCPクライアントを用意することにした。このクライアントは単にDTCP接続機能を提供するだけでなく,ユーザーの環境を調べ,必要であればIPv6のプロトコル・スタックをインストールするといった面倒まで見てくれるものとした。さらにIPv6に対応したメールソフトやWebブラウザも統合した。こうすれば,IPv6環境でできそうなことをこのクライアント・ソフトだけで体験できるはずだ。もちろんサーバーは,既存のDTCPクライアントも接続できるようにしてある。
このように,ユーザーに接続環境を提供できるようなシステムを設計,実装していく中で考えたことは,このIPv6という環境をユーザーはどう感じてくれるのかということである。多くのユーザーにとって難解であろうIPv6を,“簡単さ”,“分かりやすさ”というキーワードで表現するのはとても難しい。今時点で,それが十分に達成できているとも思えない。しかし他方では,IPv6のネットワークがもたらす可能性を信じて,IPv6に魅力を感じてくれるユーザーがいることも確かだと思う。
さてIPv6の接続性を,簡単かつ分かりやすく提供できるようになったとして,その環境で利用可能なアプリケーションはなんだろうか。短期的に考えると,IPv6アドレスからのみアクセスを許すようなWebサーバーを構築するといったところで,IPv4のみのユーザーと“区別”してサービスを提供することが考えられるだろう。
しかし,長期的な観点からすると,こういった区別とは別にIPv6の特質を生かしたサービスがアプリケーションとともに立ち上がってくることと思う。その点で一番期待をしているのが,情報家電の分野である。今後発売されるであろう「IPv6プロトコル・スタックを搭載したビデオレコーダー」などが一般的になったとき,ユーザーはネットワークにどのような機能を求めるのだろうか。それはインターネット・サイドからのコネクティビティであり,リモート録画などのアプリケーションへのアクセスかもしれない。今はまだ何も具体的ではないが,そういった状況は,すでにそこまで来ていると思えるのだ。
こうした可能性を,今回のFeel6 Technologyで一つの方向性として示すことができたと思っている。将来的にネイティブなIPv6環境に移行していく間の橋渡しとして,IPv6環境が何をもたらすかについてまじめに考えることができる一つの場所を提供できたと思う。これからこの実証実験「Feel6 Farm」を続けていくに当たって,さまざまな問題がユーザー・サイドおよびオペレーション・サイドから上がってくることだろう。それらの事柄から学ぶことは非常に多いと思う。
最後に,個人的には「IPv4のNAT」+「IPv6のトンネル環境」という状態でしばらく生活していこうと思っている。幸い,ヤマハにFeel6 TechnologyのDTCPに対応したファームウエア*1を作っていただけた。トンネルがルーターで終端できるから,LANは自然とIPv6化できる。これさえあれば,IPv4もIPv6も両立させていけるはずである。まずは始めてみること,そのために必要なことは,現実に揃いつつあるのだ。
*1Feel6のサイトからダウンロード可能(RTA55i専用)
大泉洋
某大手自動車会社,某インターネット・プロバイダでのシステム開発などに従事。その後,フリービットの立ち上げに参加し,主に認証,課金にかかわるサーバー・サイドの開発を担当する。現在は主に研究開発を主眼として,IPv6接続の実証実験である「Feel6 Farm」におけるサービス開発や保守を行っている。