MacOS X で DHCPv6 を使用する

現在のIPv6ネットワークでは、ネットワークプレフィックスやルータ情報はRAで伝搬し、ネームサーバアドレスを含むその他ネットワーク設定はDHCPv6で伝搬する、といった運用が一般的に行われています。

残念ながらMacOS Xは、DHCPv6 クライアントが付属していない為、このようなネットワークでは、例えば「IPv6アドレスは取得できたもの、名前解決ができず、実質ネットワークが利用できない」といった状況へ陥ってしまいます。

幸いISCのDHCPクライアントがMacOS Xへ対応しているため、これを利用することで問題を解決できます。

MacOS XでISC DHCPをコンパイル、ならびに利用する方法は、「mtaneda's diary」さんが詳しく解説してくださっています。有難うございます。

ネットワーク設定の取得だけが必要な場合には-Sフラグを付けて起動すると良いでしょう。また、付属の client/scripts/macos スクリプトを利用することで、システムのネームサーバも再設定してくれます。例えば、このスクリプトを~root/bin/dhclient-macos としてインストールしている場合には、以下の通り実行すればネットワーク情報をDHCPv6経由で取得することが出来ます。

dhclient -v -6 -S -sf ~root/bin/dhclient-macos en0

なおIPv4のDHCP運用時同様、System Preferencesの Network で静的にDNSの設定を行なっている場合にはその値が優先されますので注意しましょう。

World IPv6 Day開催とフレッツIPv6アドレスに基づく接続トラブル

2011年06月08日、日本時間の午前9時よりWorld IPv6 Dayが開催されています。

World IPv6 Dayとは、世界的にIPv6接続実験を行う日です。社団法人日本インターネットプロバイダー協会の案内では、その目的に付いて以下の通り説明されています。

IPv4 アドレス枯渇期を迎えたことを受け、IPv6 によるサービス提供に問題がないことを確かめ、問題があった場合にはそれを共有し、今後の課題解決に役立てることが目的です。

幾つか懸念がありますが、最も問題の発生しそうな環境は、NTTのフレッツ光サービスからIPv6アドレスを受け取っているサイトです。フレッツ光サービスでは、独自サービスにIPv6を利用していますが、フレッツ網自体はIPv6インターネットへの接続性を提供していないため、IPv6インターネット上のサイトと接続することは出来ません。

例えばマイクロソフトは、この件に関する包括的な解説を公開しています。

我が家では、フレッツ光の一種であるB-Flet'sをアクセスラインに使用していますが、IPv6アドレスは受け取らないように設定しているため、今回のフレッツ網に纏わるは影響を受けません。また、あるプロバイダ様のご好意により、IPv6 over IPv4の静的なトンネルを試験利用させていただいているため、安定したIPv6での接続が確立できており、こちらも問題は受けません。

その上で、今回World IPv6 Dayの開始に伴い、実験として、フレッツ網からIPv6アドレスを受け取り、それを宅内ネットワークへ配布するようにしてみました。

普段利用しているIPv6のアドレスプレフィックスは2001:240:XXXX::/48です。今回フレッツから取得したアドレスは2001:c90:XXXX:XXXX::/64でした。これをIPv6対応ルータで受信させ、共に/64とした上で宅内ネットワークへ再伝搬(RA)させます。これにより宅内ネットワークには、条件が同等な二つのprefixが流れることになります。但しデフォルト経路は、IPv6インターネットへ接続している2001:240:XXXX::/48側です。

宅内ネットワークには、IPv6対応クライアントとしてMacOS X 10.6.7、Windows7 SP1、FreeBSD 8.2p2、iOS 4.3.3、Android 2.3.2を用意しました。

この環境で、今回実験に参加しているwww.google.comへの接続を試みました。IPv6アドレスは2404:6800:8002::68です。問題なく繋がりました。

次に国内から実験に参加しているwww.yahoo.co.jpへ接続しました。IPv6アドレスは2404:a600:1:1607:1181:5100:25:4055です。こちらも問題なく繋がります。

最後に、もう一箇所、同じく国内で実験に参加しているwww.sony.co.jpへ接続しました。IPv6アドレスは2001:cf8:0:51::18です。しかしこちらは繋がりません。

この理由は今回フレッツから割り当てられたアドレスと、接続先アドレスとの関係にあります。

単一インターフェイスへ複数のIPv6アドレスが割り当てられている場合、どのアドレスをソースアドレスとして利用するかはRFC3484である「Default Address Selection for Internet Protocol version 6 (IPv6)」で定義されています。

これに従えば「5. Source Address Selection」の「Rule 8:  Use longest matching prefix.」に基づき、「2001::cf8」で始まるwww.sony.co.jpの場合にのみ、確実に「2001:c90:XXXX:XXXX::/64」側のアドレスがソースアドレスとして利用されてしまいます。

勿論このアドレスは、フレッツの中でだけ使えるアドレスなので、www.sony.co.jpはこのアドレスに対して戻りパケットを伝達させることが出来ません。この為、結局接続出来なくなってしまいます。同様の理由で接続できないサイトにはwww.nta.go.jp(2001:c80:a001:1::cad9:2cd0)などがあります。

一方、他サイトでの接続に問題が生じなかったのは、ある意味偶然です。ソースアドレス選択アルゴリズムの結果、優先度が一致した場合には、どのアドレスを利用しても自由であり、今回はたまたま先にRAが発行されていた「2001:240:XXXX::/48」側のアドレスが利用されたに過ぎません。実際にRAの順番を変更したところ、接続できなくなりました。

この問題を解決するために、RFC3484ではポリシーテーブルという仕組みが提唱されており、この仕組を用いることでアドレス選択の優先度を変更できるようになっています。この仕組みを用いることで、IPv6インターネットへの接続時にはフレッツ網から割り当てられたIPv6アドレスを利用しないように設定することが可能です。今回使用したクライアントの中ではWindowsやFreeBSDがサポートしています。

Windows系での設定に関しては、IIJの松崎さんが、「NTT東西のIPv6閉域網向けポリシーテーブル設定」として公開してくださっています(有難うございます)。

FreeBSDでポリシーテーブルを変更するにはip6addrctlコマンドを利用します。松崎さんの設定情報をip6addrctl用の設定ファイル形式へ変更したものを以下に置いておきます。例えば/etc内へip6addrctl.confというファイル名で保存した後、root権限で/etc/rc.d/ip6addrctlなどを実行すれば簡単に設定可能です。

::1/128               50     0
::/0                  40     1
2001:c90::/32         40     6
2001:d70::/30         40     6
2001:a000::/21        40     6
2404:1a8::/32         40     6
2408::/22             40     6
2002::/16             30     2
::/96                 20     3
::ffff:0:0/96         10     4

Windows、FreeBSDとも、この設定を行うことで、www.sony.co.jpを含むIPv6サイトへ接続できるようになりました。

残る問題はMacOS X、iOS、Andoridです。これらにはポリシーテーブルを変更する手段がありません。

MacOS Xの場合、Web閲覧だけの解法であれば、ブラウザにGoogle Chromeを利用する、という方法があります。最新のGoogle Chromeには、IPv4、IPv6で同時にサイトへの接続を試み、先に応答が返ってきた接続を利用する、という仕組みが実装されています(簡易的なHappy Eyeballs)。この為、IPv4とIPv6の両アドレスが割り当てられているサイトであれば、例えIPv6のソースアドレス選択が誤っている場合でも、IPv4で接続できます。

残念ながらiOSとAndoroidには、このような仕組みは実装されていません。また、IPv6を使わないように設定する方法もありません。これらのOSを利用している場合には、フレッツから割り当てられたIPv6アドレスをRAで配布しないように設定する以外、解決策はなさそうです。

幸い、NTT東日本、NTT西日本とも、以前から告知されていた「フレッツ光ネクスト経由によるIPv6インターネットへ接続」が正式サービスとして開始されました。今後は多くのプロバイダがIPv6接続サービスを展開してくることでしょう。

次回World IPv6 Dayが開催される際には、フレッツによるIPv6アドレス割り当て問題が解決され、ISPによるAAAAフィルタリングなどを行うことなく、より多くの人々が問題なく接続できる環境になれば、と願っております。

iOS4はIPv6対応!

お気に入りサイトの一つであるyebo blogを読んでいたところ、「iOS 4」は無線LANでIPv6に対応との記事を目にしました。

以前の記事で「iOS4 GMを確認すると、IPv6の設定項目は無くなってしまったようだ。」との記述を見つけ、また、同様の投稿を他のサイトでも目にしていたので、残念だな、と思っていたのですが、ユーザへの設定項目がなくなっただけのようです!

私も早速いくつかのIPv6専用サイトへ接続してみましたが、ヤマハ RT57iからのRAを受け入れてくれたようで、問題なく表示されました。

iPod Touchが初号機が発表された際、itojunさんがIPv6対応かどうかを気にされていたことを思い出し、時代変化の速さと、少しの寂しさを感じました。

Internet Week 2008

Internet Week 2008 が東京秋葉原で開催され、私も幾つかのプログラムへ参加してきました。

やはり今年最大の話題はIPv4アドレスの枯渇にどう対処して行くか、という点。枯渇日予測データを公開されているAPNIC の Geoff Huston さんも参加して、議論が行われました。

とは言え、この話題になると根っこの議論は10年前から変わらず、ビジネス側は「移行しなければならないのは分かってはいるけど、インセンティブがない(returnが期待できない)ので移行の予算を確保しにくい」という論で、一方技術者側は「今対策しておかなければ、大きなリスクを抱えることになるぞ」という提言。

どちらも言っていることは分かるのですが、なかなか折り合いが付かず、という所でしょうか。

IPv4アドレスは順調に(?)枯渇するモノの、恐らくCGN(NTTの宮川さん曰く、Large Scale NATへ名前が変わるそうです)などにより、IPv4アドレスの活用は長期に及び、その間、大層緩やかにIPv6が浸透して行くことになるのかな、と思います。その間にサービス側はIPv6への移行を、更にゆっくりと進めて行く感じになるのでしょうか。現在のWebサービスが、対応可能なブラウザへ制限を持たせているよう、
IPv6で接続すると「IPv6はサポートしていません、IPv4で繋いでください」と出るとか...。

ただ、Windows VistaはIPv6 Readyで、結構簡単にIPv6接続をしてしまうので、ISPのサービス提供手法によっては、エンドユーザが意識せずにIPv6で接続してしまう可能性もあります。こうなると、サー
ビス側のユーザサポートは大変ですよねぇ...。結局、各ISPはぎりぎりになるまで、IPv6での接続を先送りしそうな気もしました。

こうした議論を見ていると、どこかしら、NAT登場時のInternetの衝撃を見ているようなデジャブを感じてしまったりもしています (^^;

個人的には、HTTP関連セッションで登場した、若手開発者のパワーが大変頼もしく、1990年代初頭のPC UnixやInternetビジネス黎明期を懐かしく思い出しました。がんばれー。

IPv6でgoogle.co.jp

米国Googleの検索サイトは、以前からIPv6対応していましたが、日本のGoogleサイトでも、IPv6対応を開始とのこと。素晴らしい! というわけで、早速アクセス。

あ、あれ!? ロゴが踊らない!? うーん、残念。

日本でもGoogleロゴが踊るようになるといいなー。

IPv4アドレス枯渇対応テクニカルセミナーに参加してきました

10/6、「第1回IPv4アドレス枯渇対応テクニカルセミナー」へ参加してきました。

少し遅れて会場入りしたのですが、溢れんばかりに非常に多くの人でびっくり。技術系の方々と非技術系の方々が半分位、という比率に見えました。とは言え、後半の技術系話では、流石に人数も減り、技術系の方々が多いように見えました。

前半の内容は、アドレス枯渇に関する概論でいつもの内容のおさらいです。ただ、総務省の方々がいらっしゃる場で、「IPv4アドレス枯渇が2010年に早まった」、という表現を使われていたのが新鮮でした。というのも総務省の「インターネットの円滑なIPv6移行に関する調査研究会」で公開された「IPv4アドレス枯渇時期予測について」では、IPv4アドレス枯渇時期を2011年初頭から、と表現していて、その関係から、「総務省レポートでは枯渇時期を2011年と予想」などと言われることが多かったので。

さて、今回のセミナーで私が聞きたかったのは、データセンターの方々や、サービスを展開されている方々の感じ方です。

総じて言えば「現状それほどの緊急性を感じていない」とでも言えば良いのでしょうか「ビジネスにならない為、まだ取り組んではいない」という言い方が正しいのかも知れません。

個人的には、自身のIPv6運用ノウハウ獲得までの学習曲線を思い返すと、サービスそのもの移行処理は勿論、サービスを支えるバックヤード系システムなどで安定性を獲得するまでに時間がかかると予想される、そろそろ腰をあげるべきなのでは、と感じています。

どんな形であれ、CGN的なアプローチはISPから提供されることになると思っていますので、エンドユーザ側は当面IPv4ネットワークを利用し続ける事ができるのだろうと思います。

問題はサービス提供側のグローバルIPv4アドレスが本当にピンチになってきたとき。絶対、水面下ではIPv4アドレスの争奪戦争が生じると思うのですが、どうなんでしょう?この点からAPNICで議論が繰り返されている「アドレスの移管を認め、DBの健全性だけは、何としても維持統べし」という意見は、大変現実的だと思うのですが...。

さて、日本のインターネットは常時接続が当たり前になりつつありますが、この成功故に、

1. 常用するIPv4アドレス量が高止まりになる


2. クライアントにCGN配下のIPv4アドレスとIPv6アドレスが割り振られる


3. 結果的にIPv4アドレスが延命され、サービス提供者はIPv6でのサービスをせず、アドレスは普及すれども、IPv6ネットワークが実質的に立ち上がらない


4. 一方で、多段NATによりVoIPなどの透過性が落ち、IPv4インターネットの魅力が徐々に落ち始める


5. 「ガラパゴス」ケータイサービスの囲い込みネットワーク戦略の接続性/サービス可搬性の魅力が相対的に高まる


6. ケータイインターネットが更に普及し、PCベースのインターネットは副次的になる


7. 日本のインターネット界が、世界から取り残される

なんて、悲しい流れにならないといいなぁ、と思いました。

家電機器など、開発/利用期間の長い装置はそろそろマイグレーションプロセスを考えて置かないと、期限切れギリギリになってしまうのでは、と思われるものも少なくありません。

この業界、これから数年はいろいろありそうだな、と感じています。

IPv4アドレス枯渇問題

7月中はIPv4アドレス枯渇に関する議論へ幾つか参加してきました。ひとつは、jus総会併設の勉強会で、もうひとつはJPNICのJPOPM14thです。また、私は参加できませんでしたが、JANOGでも、IPv4枯渇に関する話が出ていました。

2010年末頃にはRIRから割り当てるIPv4アドレスブロックがなくなる、というのはさまざまな箇所で言われている通りですが、さすがにそろそろ悠長に構えているには、期限も厳しく、そういう流れから、表で行われる議論の機会が増えているのかもしれません。

結局アドレス枯渇を根本的に解決するには空間を拡大するしかなく、現状使える技術はIPv6しかないわけですが、どうしても移行期間が発生しますので、そこをどうするかがひとつのポイントです。

とはいえ、ここもご想像通り、おおむねISPという大きな単位でNATを使う、ということになります。この為にCarrier Grade NATと称される技術が提唱され、既にInternet-Draftなども積極的に公開されています。

IPv6に関しては、もうずいぶんと前からDeployが進められていましたが、残念ながら、実運用という面では、それほど普及は進んでいません。それまでのつなぎに、End2End通信を破壊する、としてある意味、必要悪的な役目に甘んじていたNAT(NAPT)がその任を負う、というのは、なかなか面白いな、と感じています。

しかしNAT越えのinboundは、各種実装の相違から単一ルータでも難しい技術ですが、それがISPなどの大きな規模で導入され、運用されることになると、大変な御苦労があるかと思います。このあたり、宮川さんを中心とされる識者の方々が積極的に推進されているようですので、技術的には楽観的に安心してはいますが、IPv4ネットワークの維持とIPv6への緩やかな移行へ向けて、ぜひともがんばっていただきたいと感じました。