PUBLIC 仮想 HUB に接続すると IPv6 通信が可能に

実は、上記を解禁した 2010 年 6 月 19 日 (土) から、PUBLIC 仮想 HUB に接続すると、IPv6 のグローバル IP アドレスが割り当てられ、IPv6 インターネットに直結 (Ethernet のレベルで接続) されるようになっている。設定は一切不要である。
試しに、TCP/IP および DNSIPv6 に対応した OS (Windows Vista / 7 / Linux 等) で PUBLIC 仮想 HUB に接続して、接続が完了したら、ping www.kame.net」とか「tracert www.kame.net」とか試してみてほしい。IPv6 インターネットに VPN 経由でネイティブアクセス (ここでいうネイティブとは、Ethernet インターフェイスとして、という意味) していることが分かるはずである。また、その状態で、有名な http://www.kame.net/ にアクセスすれば、カメさんのアニメーションが見れる。
この PUBLIC 仮想 HUB のセグメントは 64bit の Prefix を RA で流す IPv6 セグメントである。上位 64bit は「2001:200:1C8:FF01::」である。つまり、2001:200:1C8:FF01::/64 がネットワークアドレス (IPv6 ではプレフィックスと言うのだっけ) である。デフォルトゲートウェイ2001:200:1C8:FF01::1 である。
下位 64bit は、OS によって、仮想 LAN カードの MAC アドレスをもとに自動生成される。最近の OS では、他に匿名一時アドレスも自動生成されるが、MAC アドレスをもとに自動生成された IPv6 アドレスは、必ず利用可能である。ipconfig すれば表示される。この IPv6 アドレスは、MAC アドレスをもとに自動生成されるのだから、何日間接続していても、また、一度切断して再接続しても、IPv6 アドレスは変わらない。この実験サービスが将来停止するまで (または上位 64bit の Prefix が、何らかの原因で変わるまで) 絶対に変わらない。このような固定で IPv6 アドレスを割り当てるサービスを、無料で、日本国内で安定したバックホーンを用いて行っているのは、このサービスと、http://v6ip.tsukuba.wide.ad.jp/ くらいなのではないだろうか。なお、後者のサービスは、筑波大学システム情報工学研究科産学間連携推進室が運営している。両方とも、WIDE プロジェクトの IPv6 バックボーンでインターネットに接続されている。後者のサービスはユーザーごとに別々の IPv6 固定 Prefix を割り当てているのに対して、前者のサービスは、全ユーザーが同一の IPv6 固定 Prefix (2001:200:1C8:FF01::/64) である点が異なる。後者のサービスは、自宅や事務所に設置した VPN Bridge から仮想 HUB にカスケード接続し続けることで、既存の物理的な Ethernet セグメントに RA を流すことができるから、自宅にあるすべての IPv6 対応機器にグローバル固定 IPv6 アドレスを割り当てるというようなことができる。詳しくは こちらのニュースリリース を参照するとよい。


このサービスは簡単に言うと、IPv6 over IPv4 (TCPv4) であり、より正確には、IPv6 over Ethernet over TCP over IPv4 である。


両方のサービスとも、IPv6 のインターネットとの間の通信について、一切、パケットフィルタリングはかけていない。だから、自由に通信ができる。ただし、確か、例外として外向きの TCP 25 だけはフィルタさせていただいている。これは SMTPSPAM メールを送信されないようにするための措置である。


使い方としては、一番面白いのが、Windowsリモートデスクトップである。Windows Vista / 7 では、リモートデスクトップIPv6 上の TCP (これを TCPv6 と呼んで良いのだろうか?) を用いることができる。だから、自宅の PC に本サービス (前者と後者のどちらでも良い) に接続し続ける VPN Client をインストールし、IPv6 アドレスをもらっておけば、外出先から、その IPv6 アドレスを指定して、IPv6 インターネットを経由して直接、自分の PC のリモートデスクトップにアクセスできるのである。ただし、残念ながら、外出先で IPv6 のちゃんとしたインターネットが使えるところはほとんど無いだろうから、今のところは、どうせ、外出先の PC も VPN でこれらのサービスに VPN 接続し、そこで IPv6 アドレスをもらってから、IPv6 同士で通信するということになる。それなら、最初から、ASP 型 VPN 実験サービス を使って IPv4リモートデスクトップをすれば良いのだが。


実は、この IPv6 サービスは、まだほとんどトラフィックが流れていない。インターネット上にろくな IPv6 のサーバーがなく、また、IPv6 を活用したアプリもほとんどないので、仕方がないかも知れない。トラフィックグラフは以下のようである。

なお、IPv6 を使う場合も、IPv4 を使う場合も、PacketiX.NET の VPN 実験サーバーを経由すれば、リモートデスクトップを NAT の内側同士でも簡単に接続できてしまう。そうすれば、Desktop VPN オンラインサービス は不要なのではないか、なぜこの商用サービスに競合するような無料サービスを同一会社でやっているのか、と疑問に思われるかも知れない。その違いとしては、Desktop VPN の商用サービスのほうは、確かに VPNゲートウェイを経由するという点では似ているが、まず、リモートデスクトップ専用のアプリケーションレイヤの VPN ソフトウェアを用いて実装しているため、軽く、一般ユーザー権限でもインストール・実行が可能 (サーバー側も Administrators 権限が実は不要である。だから、社内 PC で、忙しいシステム管理者に代わって (代わりに自分でインストールしてと依頼されて)、一般社員が一般権限でインストールして利用することもできる) という特徴がある。もう 1 つの特徴は、Desktop VPNゲートウェイサーバーは、PacketiX.NET と違って、高品質な ISP のトランジット回線を高い値段 (月間平均で 1 Mbps あたり 1 万円もする!) で調達し、また、データセンターも、バッテリー設備、自家発電設備を備えた、安定性の高いセキュリティの整ったところに設置・稼働させているという点が異なる。PacketiX.NET は年に数回ダウンするが、Desktop VPN は、2007 年 10 月にサービスインしてから、一時的に利用できなくなったのは 2009 年 4 月 1 日 (日本 SGI のデータセンターから、新しいデータセンターへの引っ越し作業) の早朝の 1 回だけで、あとは無事故で動作し続けている。