_ フレッツ光ユーザーは6月8日の「IPv6 Day」に注意、Webが見られぬ恐れとかいう記事が出てますが。
_ いま現在 デイリーポータルZが問題なく見られれば、W6D 当日も大丈夫でしょう、たぶん。dpz って実は先月のうちにデュアルスタック化が完了していて、ひと足はやく World IPv6 Day な状態になってるので、問題が起きるような環境ならすでに dpz で起きてる可能性が高い。その他、 こののリストにあるサイトも同様。dpz では問題ないけどほかで問題がある、という可能性も十分あるけどね(dpz は AAAA が1個だけで、1回のフォールバックで A にいくのでわりと単純)。ちゃんとテストするなら こういうところで。なんかおかしい場合は、 このへんの対策を取ればいいんじゃないかな。
_ いま問題が起きていてうまくつながらない環境でも、W6D 当日になるととつぜん問題が解消しちゃう環境があるかもしれない。ISP によっては、v6 対応しているサイトでも v4 だけに見せかけるよう DNS に小細工する(aaaa filter)ところがあるので、そういう ISP でそうなる。複数の大手 ISP がその小細工をするようだし、そこから OEM 提供を受けてる中小 ISP も DNS は共用だろうから、けっこうな割合で問題は回避される。v6 化することによってどんな影響があるかを調べようというのが World IPv6 Day なのに、v6 を強制的に見せないようにして v4 だけにしてしまうってどうよ、という気はしなくもないけど、未知の問題を洗いだすだけでなく既知の問題への対策が重要なのもまた事実なので、どちらに重きをおくかについて ISP ごとにいろいろ判断があるんでしょう。
_ W6D にあわせて v6 化するけど、W6D 当日だけでなくその後も恒久的にデュアルスタックのままにしておくサイトというのも少なからずあると思われる。一方、aaaa filter は恒久的なものではなくあくまで一時的なものなので(そんなことしたら v6 使えないもん)、W6D からしばらく後で aaaa filter がはずされることになる。結果として、W6D 当日は問題ないけどそれからしばらくたって問題が発生するサイトというのが出てくる可能性がある。
_ ところで 6/1 からフレッツでトンネル方式の v6 接続サービスがいくつかの ISP ではじまってるけど、aaaa filter な DNS を使ってるとせっかく W6D までに v6 化が間に合ったとしても v4 でしかつながらん(正確には、v6 でつなげるための経路は存在するけど、どこにつなげればいいかという情報が得られない)ので注意。まあ、まっとうな ISP なら v6 接続してるユーザ用の DNS で aaaa filter はやらんと思うけど。
_ あとは、フレッツ閉域網のようななんちゃって v6 ではなく、ちゃんとした v6 の接続性があるところで起きる問題かなぁ。近所にあるはずのサーバにアクセスしてるのにパケットは太平洋を往復してる、みたいなの。まだまだ使ってる人が少なくてノウハウの蓄積が少ないのでこちらもけっこう起きるだろう。既知だけど運用者がたまたま知らなかっただけというのが大半だと思うけど(そう願うけど)、まったくの未知のトラブルが出てこないともかぎらない。とはいえ、最終的には小さなトラブルはあったけど大きな問題になるようなことはなくてよかったね、という結果になると思う。大障害には発展しないという見込みがあるからこその W6D 実施なわけだし。
_ 今ではそれが常識で、むしろそれをやってないところの方が珍しい電子メールのウィルスチェック。このサービスが今は亡き弱小 ISP で日本で最初に始まったのは、10年前の今日。なんでこんな細かい日付を知ってるのかというと、作った当事者だから。
_ サービス開始にあたって苦労したのは技術的なところではなく、政治的なところ。企業内のメールシステムでのウィルスチェックは導入がいくつか始まっていたものの、ISP でやる例はそれまで国内ではなかった(海外では数例)。通信事業者である ISP とそうではない一般企業との間には通信の秘密の取り扱いについての決定的な差があり、ウィルス感染しないようにという目的であっても ISP がやれば立派な侵害。これを、ユーザの明示的な同意があれば問題なし、と総務省に認めさせたりとかそういう根回しをさんざんやった上での開始だった。まあ、いくら弱小とはいえそのへんのことに技術屋のわしが動くことはなく、話を聞くだけだったけど。
_ ありがたいことにたくさんのユーザに使ってもらい、よその ISP も続々と参入し、いまや具備しない方が珍しいサービスになってる。でも、最初にこれをやった身から後発を見るに、これが通信の秘密を侵すものであるという認識に欠けてる ISP/ホスティング屋が多いように見える。デフォではウィルスチェックせず有料オプションになってるところはまだいいんだけど、標準でついてきてイヤだからといってもはずすことができない、というところは、契約時にちゃんとユーザにそのことを説明しなきゃいけないはずなんだけど、そうしてないところ多いよね。gmail でもウィルスチェックしてるけど規約に書いてないよ。日本語でサービスしてて日本法人もあるけど米国企業だから日本の法律は関係ないという理屈なのかしら。
_ ユーザの通信を覗き見ていじる、という行為は ISP にとってはタブーのはずなんだけど、ウィルス/迷惑メールフィルタが一般的になって以降はだいぶその考えが薄れてきてしまったように感じる。しかも、P2P 規制、OP25B、児童ポルノブロックと、新しいフィルタリングを始めるたびに、なんとかうまい理屈を捏ねて緊急避難だから違法性阻却、とユーザの同意なしでやる方向に持っていこうとしている。あのサービスを始めたときは10年後にこんなことになってると夢にも思わなかったけど、結果的にはあれがフィルタリング万歳な方向に誘導してしまったんだろうなぁ、と今は思う。別のもう一社(この ISP も今はもうない)もわずか数日の差で同じサービスを始めたし、別にわしらがやらなかったとしてもこの現状に変わりはなかっただろうけど、先頭を走っていたものとしてはとんでもないことをやってしまったんだなと思うばかり。
_ ISP によるフィルタリングは、わずか10年でこんなにも当たり前になってしまった。当初は情報セキュリティ方面での安全確保が主な目的だったけど、4月から始まった児童ポルノ規制で警察の使い走りもするようになった。行動ターゲティング広告のような商業目的での利用のために通信の覗き見をしたがってる人もたくさんいて、これもどうやら認められる方向で検討が進んでるらしい(?)。分野によっては自分は関係ないや、とか思うかもしれないけど、この調子で進めばあらゆる方面で通信の秘密はないがしろにされるだろう。加速することはあれ、この方向性が変わることがあるとはとても思えない。ユーザがはっきり望んだのあればまだいいんだけど、同意なしで無差別にフィルタリングするようなことは、たとえそれがユーザの益になることであってもこれ以上増えてほしくはないんだけれど。
_ W6D を巡る記事ではフレッツ閉域網やフォールバックしないアプリなど、クライアントに近い側で起きることが予想される問題ばかり取り上げられてる。ので、サーバに近い側で起きそうなトラブルをいくつか。
_ IPv4 では ICMP をすべてブロックしてるサイトというのをときどき見かける。大昔、ping of death という一部 OS が即死してしまうような攻撃がはやったり、また、ICMP flood のような DoS 攻撃もあるせいじゃないかと思うんだけど、そのまま同じように ICMPv6 もブロックしちゃうとたいへんマズい。v4 と違って、v6 では途中経路上のルータなどでのパケット分割が禁止されている。パケットがデカすぎるのであれば経路上で分割するのではなく、分割しなくてもいいようはじめから小さいサイズでパケットを送出する、というのが v6 のルール。で、どこまで小さくすればパケットが通るようになるのかを調べる(path MTU discovery)のに ICMPv6 が使われる。pmtu discovery 自体は v4 にもある仕組みだけど、パケット分割が廃止された v6 では v4 以上に重要で、これが効かなくなるとある程度以上のサイズのパケットがまったく通らなくなってしまうという致命的な障害につながる。ふだんは目立たないけど、ICMP だってちゃんと理由があって存在してるプロトコルなわけで、考えなしに止めちゃうのはよろしくない。
_ ……ええ、うちのサービスで先日やらかしました:-)。お、おれはわるくないよ？
_ それ以外、てきとーに思いつくままに。
_ 逆引きに失敗してアクセス拒否しちゃいけない人を蹴る。だから v6 で逆引きに頼るな、と。その他、クライアントの IP アドレスによって挙動を変えるようなことをやってる場合は v6 化してもちゃんと動くかどうか要チェック。
_ web のアクセスログの解析ツールって、まだ v6 対応してないものが実は多かったりするんだよね。ネットワークの接続性だけでなく、運用ツールの v6 対応も考えましょう。
_ 先日とある有名なサイトが、AAAA レコードに IP アドレスではなく /64 なプレフィックスを載せたとか ::ffff:x.x.x.x という v4 mapped address を載せたとかいう出来事があったけど、そういうアホなことをやらかすのはそうそうないと思う。…ないよね？
_ 以上、v6 をやってれば W6D とは無関係に起きうることなので念のため。W6D 特有のトラブルとして考えられるのは、W6D 終了時刻が過ぎたあと AAAA のキャッシュが生きてるうちに v4 only に戻してしまって接続に失敗する、とかその程度だろう。
_ そんなわけで World IPv6 Day 前日なわけですが。
_ ここのところ立て続けに関連ネタを書いてるけど、ぶっちゃけそれほど大騒ぎするイベントではないと思ってたり。すでに 参加表明サイトのうちの半分くらいが 0:00 UTC を待たずに dual stack になってるようだけど、みんな問題起きてないよね。一部環境で不都合が起きる可能性がないではないけど、大多数へ深刻な影響はないとわかってるからやるわけだし。日本は世界全体より影響を受ける人の割合が高そうではあるけど、それでも 1% もいない。困る人が大量発生することが見込まれるならはじめからそんなのやらないよ。一部の関係者だけ盛り上がってればいいことであって、 一般紙の記事にまでするようなことじゃない。
_ v6 対応済みリストから見つけてきた 厳しそうなサイト。韓国のニュースサイトみたい。現時点で AAAA が6個もあるので、v6 -> v4 のフォールバックに時間がかかるブラウザだと AAAA をぜんぶ試してる間にタイムアウトしそう。フレッツのなんちゃって v6 環境でここにちゃんとアクセスできれば、ほかもたいてい問題ないと思う。
_ フォールバックに問題がある場合の prefix policy 変更ツールの配布サイト。その1、 kokatsu.jp。v6/v4 デュアルスタックなので、問題に直面してこのツールを必要としているまさに当人こそ、ここへのアクセスに支障があってダウンロードできない可能性あり。その2、 attn.jp。同じくデュアルスタックだったので同じ問題が発生する可能性があったけど、今朝ほど中の人にその旨連絡したら v4 only になっちゃいました:-)。いつ dual stack に戻すのかは知らない。その3、 microsoft。www.microsoft.com は v6 化するけど、IE9 とかのダウンロード用のサイトは v4 のままらしいので、たぶん大丈夫。MS 製のは変更した prefix policy を W6D 終了後に自動で戻してくれるというありがたい機能がついてるけど、逆に言えばほんとに当日だけの一時しのぎでしかないのでそのへん要注意。
_ もちろん、prefix policy を変更するよりも、変更しなくても問題が起きないようにすることができるのであればそれがいちばんいいのは言うまでもない。
_ というわけで今朝から明日朝まで W6D です。
_ やっぱり path MTU discovery がうまく動作してないことに気がついてないところがいくつかあるなあ。ルーティングがおかしいところもちらほら。開始からいくら待っても AAAA レコードがつかないところもある。いったん v6 化したもののトラブったのか切り戻したところもいくつかある模様。
_ ちゃんと動いてるところはちゃんとしてるけど、ダメなところはほんとグダグダだな。v4 だと正常なのに v6 でアクセスすると 404 な応答を返しちゃってるんですけどー、とか、そんなおかしな AAAA レコード登録すんなよ、とか事前にテストしなかったの？てなレベルのも見かける。環境によって見えたり見えなかったりするならまだしも、こういう誰がどう見てもおかしいところって、おかしいことに気づいてないのか、おかしいことをわかってて放置してるのか、どっちなんだろ。どっちにしても理解に苦しむけど。
_ 今回はダメなところを探すのが目的のイベントなので、そういうところはどうしても目立っちゃうけど、まあ全体からすればやっぱりそういうのは少数かな。個人的な事前の予想よりは多めだけど。
_ facebook は http://[ipv6-address]/ でアクセスすると 500 を返すな。v4 なら www.facebook.com にリダイレクトされるので意図した挙動ではなさげ。ふつーそんなアクセスはしないからテストが漏れてたんだろう。まあ、これで困る人はいないと思うけど。
_ bit.ly は AAAA が4つ。 この前書いたv4 mapped address を DNS に載せたところって実は bit.ly のことだったんだけど(あれ、j.mp の方だったかも。どっちも同じところだが)、今回はだいじょぶそげ。
_ twitter は W6D に参加表明していなかったものの、blog.twitter.com と blog.jp.twitter.com は google blogger を利用していたために意図せず(?)巻き込まれた模様。で、巻き込んだ google さんはあちこち見てもどこも問題なさげ。まあ、ここは以前から v6 化してたしね。
_ web サーバに AAAA がついたところは多いけど、NS や MX が v6 化したところはほとんどないなぁ。まあわかってたことだけど。
_ 国内 ISP 各社の AAAA filter 状況。どこもたいてい open resolver なので契約ユーザじゃなくても調べられちゃうけど、ほんとはあまりよくないんだよね。
直接確認できなかったので不明にしたもののうち、伝聞によると ocn はフィルタなし、biglobe はありらしい。そんなわけで、かなりのところが v6 なんて知らないことにするという後ろ向きな対応をした模様。で、現時点までの情報では、フレッツなんちゃって v6 問題に起因する接続障害はゼロではないにしてもほとんどないようなので、無理にやらなくてよかったかもね、という結論になりそうな感じ。
- AAAA filter あり: nifty, plala, so-net, infosphere, asahi-net
- AAAA filter なし: au-one, odn, eo, iij
- 不明(acl かかってるとかアドレス不明とか): yahoo bb, ocn, biglobe, gyao(usen), jcom, dti
_ 自社のユーザに対するサポートをおこなうサイトが以前から v6 化されていたのに、今回の W6D に合わせて aaaa filter を入れた ISP がなぜそのような判断をしたのか知りたい。aaaa filter がないとアクセスできなくなってマズいということであれば、W6D 前まではそういうユーザが自社サイトにアクセスできないのを放置してた、ってことだよね。実際はそういうのはいたとしてもひじょーに少なかったわけだけど。
_ このまえのぷららの件、いまさら 報道されてた。遅いよ。まあ、総務省がアクションを起こしてるらしいことがわかっただけでもよかったとしよう。
_ そんなわけで、とくに大きな混乱はなく W6D は終了。
_ 日本ではフレッツの閉域 v6 網の問題がクローズアップされて、いくつもの大手 ISP が aaaa filter をかけたけれど、そんなことをしなくても平穏そのものだった。実は影響あったのに気がついてないユーザというのも多そうだけどね。
_ 事前に予想されていたとおり、W6D 当日かぎりではなく終わったあとも AAAA をつけたままにしているサイトが多数残っている。が、 AAAA filter を実施していた国内 ISP 各社も、plala と asahi-net は 早々と解除されたのを確認。伝聞によると biglobe も解除らしい。フレッツで問題が出るのであれば一度投入した AAAA filter を解除する時期は慎重に判断する必要があるけど、実際には拍子ぬけするぐらい何もなかったので、慎重に判断した上で「さっさとはずせ」の結論になるんでしょうな。
_ IE がダメとか言われてたけど、フォールバック全般に問題があったわけではなく、「特定の条件でのみ」失敗する、というバグのせい。正確な条件は忘れたけど、HTML から呼ばれる画像とか CSS とかの部品が HTML とは別ドメインのサイトにあるとコケることがある、てな感じだったかな。条件を満たしていても必ず失敗するわけではなくそれなりに成功することがあるし、コケたとしてもリロードしてやればおっけー、というひじょーに気づきにくいものなので、この影響でフォールバックに失敗してもふだんからよく起きてる画像欠けと同じ程度には閲覧できちゃうんだな。コンテンツ事業者にしてみれば広告画像が欠けると大問題なので看過できないだろうけど、一般ユーザの大半はこんなの発生していても気づかないというか気にしないだろう。
_ また、IE7 などで bit.ly や j.mp な短縮 URL へのアクセスが最低4秒かかるようになった、という現象もフレッツで発生しているはず。でも、ちょっと遅いなー、ぐらいしか思わない人が大半なんじゃないかな。v6 なホストにアクセスできないと判明した後、即座に次を試すんじゃなくてなぜか1秒待つんだよね。bit.ly、j.mp は AAAA が4個あるので4秒待ちに。今もまだ AAAA がついたままなので、現在進行形で起きてる現象。このまま恒久化かな？
_ 参加サイト側。今回は web アクセスの v6 化がメインだったのでメール、DNS の v6 対応がダメなのはやる前からわかっていて、なのでそれを問題にするつもりはないけど、web でもかなり高い割合で問題が あったみたい。もっとマシかと思ってた。DNS に AAAA を載せる前にテストとかしないのかな。トラフィックが少ないにしてもだいぶ前から v6 網は存在していたのでネットワーク側はわりと大丈夫だったけど、サーバ側はまだまだみんな初心者ということかなぁ。
_ ということで、(もしあるとしたら)次回の課題にすべきことも見えてきた。つまり、web を確実に v6 でつながるようにしよう、web 以外の部分も v6 化してみよう、v6 -> v4 のフォールバック検証だけでなくネイティブ v6 接続の検証をもっと大々的に。こんなところか。