小林 伸治 (koba@flab.fujitsu.co.jp)
株式会社 富士通研究所[1]
技術的には、移行の問題はTransition MechanismsとしてIPv6検討の中で議 論されてきた。その具体的な成果がSIT（Simple Internet Transition [2]）であ る。SITはネットワーク層のTransition Mechanismとして基本的なものではあ るが、アプリケーションの対応、プロトコル選択といったユーザレベルの運用 まで考慮すると十分ではない。そこで我々はアプリケーション層まで含めた総 合的なTransition Mechanismの可能性を検討し、有望な方式として application-level gateway技術を用いたIPv4-IPv6 Gatewayプロトタイプの開 発、評価を進めている。
本論文はapplication-level gateway技術によるIPv4-IPv6 Gatewayの一方 式としてSOCKS5プロトコルを応用した相互接続方式（SOCKS64）を提案するも のである。まずIPv4-IPv6相互接続技術と現在提案されている方式について考 察する。次にSOCKS64方式およびSOCKS5の実装をベースとした試験実装の結果 と問題点を説明する。最後にSOCKS64の実装方式を述べる。
この問題をユーザが意識しないようにするためには、IPv6/IPv4 nodeにお いて全てのInternetアプリケーションが、例えばDNSを引いた結果に応じてIP スタックを選択するように変更する必要がある。全てのInternetアプリケーショ ンがこのような機構を組み込むまでは、多かれ少なかれユーザはプロトコルを 意識しなければならない。
translationの問題はIPv4で提案されたNAT[8] の例を考えれば容易に理解され る。NATはIPv4 routerでアドレスの変換を行う機能で、例えばプライベートア ドレスとグローバルアドレスの変換に用いる。NAT routerはあらかじめ変換す べきアドレスの組をテーブルとして持ち、パケットを中継する時に変換テーブ ルを調べて該当すれば書き換える。これだけでもアドレス管理の上で問題が生 じる危険を感じるが、Internet ProtocolではIPパケットのみならず上位プロ トコル部分まで調べてアドレスを変換しなければならない場合がある。
例えばFTPではユーザが入力したコマンドをTCPセッションで接続相手に伝 える。NATがIPパケットのアドレスだけを変換すると、IPパケットは正常に届 くがTCP上にうめこまれたIPアドレスが変換されていないためにデータ転送で きない。そこでNATはIPヘッダだけでなく、TCPヘッダ（CHECKSUM、データ長）、 TCPデータの中の関連部分を変換しなければならない。 このような操作はネッ トワーク層の処理を完全に逸脱するものである。
アドレス対応の問題についてはIPv4-compatible addressを利用できる。し かしIPv6の本来の目的であるIPアドレス空間の拡大を考えると、 IPv4-compatible addressは限定的にしか用いられない。そこでtranslationにお いては相互接続点においてIPv4-IPv6をどう実現するかが課題となる。
アドレス対応関係の管理のために、TOWNSではDNSを用いる。IPv4 nodeは通 信に先立って通信相手のIPアドレスをDNSサーバに問い合わせるが、この時DNS サーバは相手がIPv6 nodeである場合は適当な疑似IPv6アドレスをIPv4アドレ スに割り当て、このアドレスをIPv4 nodeに返す。IPv4 nodeは相手がIPv4 nodeと考えて通信を行うが、この時ネットワークを流れるIPv4パケットを TOWNSが拾い、対応するIPv6パケットに変換する。
このようにDNSによってアドレス対応関係を管理するとユーザは相手のプロ トコルを意識することなく通信可能となるが、反面DNSにおけるアドレス対応 関係の管理が問題となる。例えば一度関連づけたアドレスをいつまで保持して おかなければならないか、DNSやネットワーク層では必ずしも判定できないた め、疑似IPv6アドレスとして用いるIPv4アドレスの使い回しに配慮が必要とな る。
もう一つ重要な点は移植性である。kernelレベルのgatewayはシステムアー キテクチャに強く依存するため、異なるシステムへの移植が困難になりがちで ある。それに比べapplication-level gatewayは格段に移植しやすい [10]。
application-level gatewayによるIPv4-IPv6 gatewayのイメージを説明す る。まずIPv4 nodeはIPv6/IPv4 nodeであるgatewayに対してIPv4通信を行う。 gatewayはこの通信をアプリケーションレベルで一度終結させ、新たな代理通 信として本来の宛先であるIPv6 nodeにIPv6通信を行う。すなわち間にgateway がはいりこんでいるが見かけ上はエンド・エンドが直接通信しているように見 える。
application-level gateway技術はFirewallで活用されていることからもわ かるように、エンドユーザからみると全く意識しなくてよいだけでなく、アプ リケーションの種類、セッションに応じたきめこまかな通信制御が可能である。 同様にユーザがIPのバージョンを意識しないで相互通信可能なIPv4-IPv6 gatewayを実現できることも期待される。
奈良先端科学技術大学院大学で検討されているFAITH[11] はこのような方式の 一つである。FAITHではTOWNSと同様にDNSを用いてIPv4-IPv6アドレスの対応関 係を管理する。gatewayはネットワーク層でパケット全て上位層にあげ application-level gatewayに引き渡す。FAITHはapplication-level gateway の特長によりtranslation方式の問題をなくすことができる。またDNSにおける アドレス対応関係を管理する問題も、application-level gatewayがDNSにセッ ション管理情報を通知すれば順当に解決できるものと考えられる。
SOCKSは通常のsocketインタフェースをSOCKS用のライブラリで置き換える。 このためクライアント側はSOCKS対応のアプリケーションを準備する必要があ るが、UNIXであればアプリケーションをライブラリを入れ替えて再コンパイル する程度の手間ですむ。PCなどクライアントマシンではSOCKS機能をもつアプ リケーションを導入しなければならないが、最近市販されているネットワーク アプリケーションではSOCKSなどProxy機能をサポートする例が多くなっている。 またNECはWindowsの通常アプリケーションをSOCKS対応化するソフトウェアと してSocksCapを開発し、無償公開している[15]。
SOCKSライブラリはまずクライアントとSOCKSサーバをTCP/IPで接続し、か つSOCKSサーバから本来接続すべきリモートサーバへTCPあるいはUDPで接続す る。これが成功すれば、そのあとはクライアントとリモートサーバがSOCKSサー バを介して透過的に接続される。
SOCKS4まではsocket APIをそのままSOCKSサーバで実現するような単純な仕 様となっていたが、SOCKS5では以下のような仕様が追加された。
アドレス表現形式としてIPv6アドレスが追加された アドレス表現形式としてFQDNが追加された特にFQDNの追加によりクライアント側でDNSを引く必要がなくなり、サー バ側で一括してFQDNの解決をすることができるようになった点は大きい。クラ イアント側はFQDNで表されるnodeがIPv4 nodeであるかIPv6 nodeであるかを意 識する必要がなくなるからである。
まずクライアントはSOCKSサーバに対してSOCKSコネクションを要求する。 このとき最終的な宛先nodeアドレスをFQDNで指定する。これを受けたSOCKSサー バは与えられたFQDNを解決し、得たアドレスがIPv6アドレスであればIPv6を、 IPv4アドレスであればIPv4を使ってremote nodeに対するコネクションを確立 する。そのあとクライアントに応答を返す。
次にクライアントが通信を行うと、SOCKS64はクライアントが使用している アプリケーションに対応したapplication-level gatewayを介して宛先nodeに 中継する。この時、中継前と後で通信は完全に独立であり、アプリケーション に応じた処理を行うことができる。
以上のようにSOCKSプロトコルを用いることにより、通常のDNSに手を加え ることなく、ユーザにとっては（SOCKS的な意味で）透過的なIPv4-IPv6 Gatewayを構築できる。
表１. SOCKS64実装システムの構成
試験実装は基本的にFQDNをDNSに問い合わせ た結果に従ってIPv4/IPv6に対応する処理を行う機能を追加しただけであり、 本来SOCKS5パッケージがもっている機能は一切損なっていない。Solarisと BSD/OSの二種類のOSをプラットフォームとし、IPv6 Stackも異なる実装を用い たが、共に大きな問題もなく拡張できた。
SOCKS64の接続確認はtelnet、ftp、httpを用いて行い、米国NECが公開して いるSOCKS5クライアント（socks5-v1.0r2、SocksCap32）を用いてIPv4 nodeと IPv6 nodeが通信可能であることを確認した。SocksCap32はSocksCapの Windows95対応版である。
但しftpについては、IPv4 nodeからIPv6 nodeに接続した場合に、接続はで きるがディレクトリ表示やデータ転送といった操作ができないという問題があっ た。これはftpのPORTコマンドを適切に変換していないためデータコネクショ ンが確立できないためである。このような問題を解決するためにはコネクショ ンの種類やコネクション間の関係を認識し、必要に応じてコネクションを流れ るデータを変更する必要があるが、今回の実装では対応していない。あとに述 べるが、米国NECの実装ではapplication-level gatewayとしての機能を追加す ることが困難なためである。
この結果から、まず比較的低速な回線によってFirewall外部と接続するよ うなSOCKSゲートウェイの利用形態においてはapplication-level gatewayのオー バヘッドは問題にならないことがわかる。また10Mbps以上の速度であっても同 時接続数が増加するとオーバヘッドの影響は小さくなる。従って実際の運用上 SOCKS64のオーバヘッドはほとんど問題にならないと考えられる。
SOCKS64方式を完全に実現するためには一度SOCKSコネクションを受け付け た後にユーザアプリケーションに応じた専用のapplication-level gatewayプ ロセスを起動するようなinetd的な実装が適している。
このようなシステムでは、例えばftpゲートウェイでは制御コネクションを 流れるデータをチェックし、PORTコマンドの自動修正を行うだけでなく、 SOCKS64サーバのコネクションテーブルを他のゲートウェイと共有することに よって対応するデータコネクションを認識し、適切な処理を行うことが可能と なる。
表２. IPv4-IPv6相互接続方式の比較
| TOWNS | Translation | |||
| FAITH | Application-level Gateway | |||
| SOCKS64 | Application-level Gateway |
TOWNS、FAITHはIPv4アドレスとIPv6アドレ スの対応管理をDNSの変更とサーバで実現している点でSOCKS64と異なる。 SOCKS64ではクライアントのプロセス内だけで管理すればよいのでDNSの変更は 不要で、アドレス対応管理も簡単である。
translation方式とapplication-level gateway方式との最大の違いはゲー トウェイでコネクションが終端されるかどうかである。コネクションを終端す ることで、アプリケーション毎のプロトコルの差異に細かく対応したり、柔軟 な接続制御を行ったりすることができる。translation方式は基本的にネット ワーク層の処理なので専用ルータなど単機能装置で実現可能である点が有利で あるが、既に述べたように上位層を意識した変換が必要となる場合にはかえっ て問題である。
SOCKS64の欠点はクライアント側での対応が必要となることである。 Firewallを持たないシステムではIPv6-IPv4相互接続を必要とする全てのユー ザにSOCKSをインストールさせなければならない。しかしながら、企業内ネッ トワークではインターネットへの接続にFirewallを用いるのが普通であり、実 際にSOCKSも広く用いられており、そのようなシステムではすでにユーザが SOCKSクライアントを利用している。このような場合、SOCKS64方式は最小のコ ストで利用可能である。
[1] 〒211-88 川崎市中原区上小田中4-1-1
[2] RFC1933、Transition Mechanisms for IPv6 Hosts and Routers、April 1996
[3]
nodeとは通信を行う主体であるhostとネットワークを構成するrouterの両方を
意味する用語である。
これに関連してSITでは以下の用語を定義している。
IPv? node とにかくIPv?をしゃべることのできるnode IPv?-only node IPv?しかしゃべることのできないnode IPv6/IPv4 node IPv4とIPv6の両方をしゃべることのできるnode[4] IPv6 addressのうち上位96bitが0であるものをIPv4-compatible addressと定義している。
[5]
Fully Qualified Domain Name、RFC1591、Domain Name System Structure
and Delegation、March 1994
STD13、Domain Names、November 1987
[6]
DNSにIPv6アドレスレコードAAAAが追加されている。
RFC1886、DNS Extensions to support IP version 6、December 1995
[7]
山本、角川、島、「IPv4とIPv6のトランスレータに関する考察」
、電子情報通信学会技術報告、CPSY97-34、1997-06、Jun. 1997
[8] RFC1631、The IP Network Address Translator、May 1994
[9]
Firewalls and Internet Security,Addison-Wesley,ISBN 0-201-63357-4,April 1995
Building Internet Firewalls, O'Reilly & Associates, Inc.,ISBN 1-56592-124-0,September 1995
[10]
よい例がWIDE Project（Sony、NTT）のIPv6 daemon（http://onoe2.sm.sony.co.jp/ipv6/）である。
これはIPv6プロトコルスタックをkernelでなくアプリケーションレベルのdaemonとして実装する。
性能的な問題はあるが、アプリケーションだけに移植性がよいのが最大の長所である。
[11]
角川「ネームサーバとヘッダ変換ゲートウェイを用いたIPv4とIPv6の相互通信」、
奈良先端科学技術大学院大学、情報科学研究科修士論文、NAIST-IS-MT9551055、Feb. 1997
[12] RFC1919、Classical versus Transparent IP Proxies、March 1996
[13] RFC1928、SOCKS Protocol Version 5、March 1996
[14] http://www.socks.nec.com/
[15] http://www.socks.nec.com/sockscap.html
[16] http://playground.sun.com/pub/solaris2-ipv6/html/solaris2-ipv6.html
[18] http://www.wide.ad.jp/wg/ipv6/
[19] 川崎市から藤沢市のWIDE Fujisawa NOCにある6boneに接続している。 http://www.v6.sfc.wide.ad.jp/6Bone/topology.html