Eduroamは学術機関間におけるWiFiの相互ローミング運用プロジェクトで、全世界の大学や研究機関に所属する学生・教職員が利用できるシステムで、日本国内においては国立情報学研究所(NII)が推進をしています。

日本国内における認証連携には学術認証フェデレーションである”学認“を使用しており、学認に参加している機関であればeduroamが利用できるように見受けられますが、実際にはeduroamに別途参加しなければ利用できない仕組みになっています。

例えば慶應義塾大学のように学認に参加しているが、eduroamに参加していない機関に所属する学生・教職員はeduroamの恩恵に預かれず、国内外の学術機関に訪問した際にネットワークを利用できません。

Eduroamでは所属する機関の学生・教職員が持つクレデンシャルを利用して認証を行うため、個人や所属機関が特定されてしまうと言う問題 ((例えば[email protected]というアドレスで認証すればSFCに所属しているのがわかってしまいます)) がありました。その問題を解決するため学認では一時的に仮名のクレデンシャルを発行する仮名アカウント発行システムというシステムを運用しています。

本来仮名アカウント発行システムは利用者を保護するためのシステムですが、本システムを利用することでeduroamに参加していない機関に所属する人もeduroamを利用することができます。

方法

1. 仮名アカウント発行システムにログインする
   https://eduroamshib.nii.ac.jp/
2. ログインに成功したら、アカウントを発行する。
   利用期間は最大1年間まで選べます
3. 取得したクレデンシャルでeduroamを利用する

免責事項

本記事は私が所属している組織の意見を表明したものではありません。
また本記事の内容について保証するものではありません。

MacをYosemiteにしてからHWD14の有線Ethernetが使えなくなって、WiFi経由でしか使えなくなってしまい、非常に不便だったのだが使える方法があったのでメモ。

基本的にこの手のデバイスは最初接続するとUSB Composit Deviceとして認識されて、専用のユーティリティがATコマンドみたいなのを飛ばして有線Ethernetデバイスとして認識させるみたいな仕組みなので、初回接続時だけユーティリティのインストールが行われる仕組みになっている。

ただ、OSのアップグレードとかでそのユーティリティが動かなくなると有線Ethernetとしても使えなくなる仕組みなので、そのユーティリティさえアップグレード出来れば問題ないはずなのだけど、残念ながらHWD14はそのアップデートが提供されず購入して1年もたたないのに最新OSで使えないという残念な仕様となっていた。

勿論本国ではそのユーティリティは提供されているので、同じHuawei製のHWD14なら動くはずということで試してみたところ問題なく動きました。というオチ。

リンクはこちら。
http://consumer.huawei.com/en/support/downloads/detail/index.htm?id=31145

ところでHWD14小田急線で全くというほど使い物にならないのだけど(というか動いてると小田急線だけじゃなくダメ)、後継機に乗り換えたら使い物になるのかな？

先日Jxckさんがセッションオーナーを務めた次世代Webセッション@CROSS2014に参加してきました。

セッションではSPDYやHTTP/2(その当時はまだHTTP/2.0だったかな)について主にリソース転送をどうよくするかについて話がされ、QUICなど”Post-TCP”な話も出て非常に興味深く楽しみました。
そこで「僕が考える次世代Web」というお題でブログを書けとJxck先輩から宿題をいただいて、何の話を書こうかなとずーっと思っていたのですが、最近のIETFの議論で個人的にはとても大切だと考えるトピックがあったので紹介＋僕の思いを書きたいと思います。

[訂正]
私がドラフトを読み違えていたのが問題なのですが、このExplicit Proxyの仕組みはhttp schemeの場合だけ適用され、httpsでは適用されません。そのため、httpsについては引き続き安全だと言えます。
しかしこの通信が暗号化されるべきかべきでないかの情報も秘匿すべきという考えもあり、私個人の考えとしてはhttp/httpsいずれのschemeにおいてもALPN Protocol h2を用いた方がよいと考えます。

背景

NSAによるPRISMプログラムの発覚以降、インターネットを取り巻く状況は大きく変化しました。政府によりインターネットは監視され、end-to-endにおける暗号が再び注目されるようになり、Twitterがたとえ将来秘密鍵を政府に奪われたとしても過去の暗号通信を復号されないようにEphemeral Diffie-Hellman鍵交換を用いてPFS(Perfect Forward Secrecy)に対応した話などを目にしたことがあると思います。 ((PFSについての解説と、なぜPFSが重要かは、Lavabit 事件とその余波、そして Forward Secrecyに書いてあるので見てみてください))

更には先週IABとW3CによるInternet Pervasive Monitoring(大規模モニタリング)に関する共同ワークショップ STRINT Workshopが開催され、Opportunistic keying ((日和見暗号・Opportunistic Encryptionとも。httpsなどは暗号通信を行うことが明示的に同意されているが、httpなど明示的には暗号通信を行わない通信においてもエンド間が暗号を利用できる場合、暗号を利用することで安全に通信を行おうという考え)) について取り組もうという話が出るなどエンド間における暗号の重要性が高まっています。

話を戻して、HTTP/2の前身であるSPDYはTLSによる暗号化を必要としています。これは元々ファイアウォールやロードバランサーなどのmiddleboxがSPDYなどの未知のプロトコルをブロックするが、TLSはブロックされにくいことからTLSを用いたのが始まりでした。HTTP/2でもそれを受け継ぎ、TLSを利用してプロトコルのネゴシエーションを行っています。TLSを用いてmiddleboxによるブロックを防ぐということは、middleboxにより通信内容を解析されることが困難になることから、PRISM事件以降たびたびHTTP/2において暗号通信を必須とする提案(httpであったとしてもTLSを必須とする)がなされてきました。

TLS(暗号化)がなぜダメか

HTTP/2でTLSが必須となり、すべての通信が暗号化されることにより、弊害が生じるという意見があります。様々な理由により、http通信を”最適化”・”効率化”しなければならないという意見です。例えば、

• ペアレンタルコントロール
• ウィルススキャン
• ISPが転送量を減らすためにCDNを展開していないWebサイトの画像や動画などをキャッシュ(Transparent Proxy)
• モバイルネットワーク特に衛星網など遅延が著しい環境において、画像の圧縮などを行い高速化
• モバイルにおいて加入者情報をコンテンツプロバイダに提供
• 最適化広告
• エンタープライズにおいて、従業員が機密情報を社外に送信していないか監視
• ISPによる自主的・法的問わず、児童ポルノ・違法コンテンツの流通の監視
• 政府による合法的な市民の検閲・監視(Lawful interception / 合法的傍受)

などの理由 ((詳しくはhttp2 Githubに記載されたProxy-use-caseを参照: Proxy User Stories · http2/http2-spec Wiki ))により、TLSによる暗号化をすべきでないという意見があります。

このような意見からHTTP/2ではTLSを必須とはしない決定がなされました。つまり、httpにおいては今までと同様に平文で通信が行われることになります。(もちろんhttpsではTLSを用いて暗号化されます)

Explicit Trusted Proxyの提案

httpでは平文を使うため、先に挙げた理由などでHTTP通信を”最適化”・”効率化”することは可能です。しかし、前回バンクーバーで行われたIETFでも大規模モニタリングはプロトコルに対する攻撃であり、プロトコルは大規模モニタリングに対して策を講じなければならないと決まる ((Pervasive Monitoring is an Attack: https://datatracker.ietf.org/doc/draft-farrell-perpass-attack/)) など、可能な限り暗号化もしくは安全なプロトコルを利用しようという動きは加速しており、HTTP/2においてもTLSは必須ではないですが、おそらく多くのコンテンツプロバイダーはhttpsを用いることが予想されます。

ほとんどの通信がTLSを用いて暗号化されてしまうと、先に挙げたHTTP通信を”最適化”・”効率化”することが難しくなってしまいます。そこでEricssonやAT&Tにより、TLSを用いていたとしてもユーザの明示的な同意があればプロキシによるMITM ((Man-in-the-middle: 中間者攻撃)) を可能とする提案(draft-loreto-httpbis-trusted-proxy20)がなされました。

HTTP/2ではTLSのALPN ((Application-Layer Protocol Negociation: 詳しくは@flano_yukiさんによるALPNについての解説を参照)) というメカニズムを用いてTLS上でどのプロトコルを使用するかネゴシエーションを行います。HTTP/2の場合クライアントはh2というIDを通信可能なプロトコルとしてサーバに提示することでHTTP/2で通信が行われます。提案ではクライアントはh2clrというIDを提示している場合、中間に存在するプロキシがそこで通信を終端し、ユーザの明示的な同意(SHOULD)の後、”最適化”・”効率化”を行うことを可能としています。

提案では中間に存在するプロキシはその際拡張キー利用法にproxyAuthenticationが含まれたSSL証明書を用いなければならないとされており、より高いセキュリティが必要な場合はEV証明書を使うことを推奨しています。

ユーザが同意しない場合、プロキシはTLSのClientHelloメッセージをサーバに送信することでサーバとクライアント間でTLS接続を終端するとされています。

ユーザの明示的な同意とは

公衆無線LANなどにおけるCaptive Portalの場合など、提案ではさまざまなケースについてどういうフローを取るべきか書かれています。

また提案では、ユーザが同意した場合、ユーザエージェント ((User-Agent: ブラウザのこと)) は同意したという情報を保存し、次回以降同意無しにプロキシに接続しなければならない(SHOULD)とされています。一方提案ではその同意は特定の接続に限定されなければならなず(SHOULD)、一定の時間もしくは一回のみに限定することができる(MAY)とされていますが、特定の接続についての定義については述べていません。

しかしユーザの明示的な同意とは何をさすのでしょうか？

例えば「お客さまの通信速度の向上のため、通信の最適化を行います」と表示されたら大抵のユーザは同意ボタンを押すでしょう。しかし、本当に行っているのは安全なはずの暗号通信をman-in-the-middleする以外の何者でもない話であり、ユーザがhttpsで、アドレスバーが緑色だから安全と信じて入力したパスワードやパーソナルデータは実は”通信の最適化”のため中間者によって復号されているわけです。そして一度同意してしまったら明示的に設定をオフにしない限り、安全であるはずの通信が第三者によって見られ続けることになります。

また同意がプロキシ側で行われるのは更に問題です。この提案ではコンテンツプロバイダー側がプロキシを禁じることはできないため、プロキシが攻撃された場合ユーザ・コンテンツプロバイダー双方が気付かない間に情報が盗まれる可能性があります。

僕はこれは極めてunhealthyだと思います。

httpsを使う限り安全である ((PRISMの例や、httpsでも弱い暗号を使っていて第三者に解読される場合などはありますが)) 通信が、httpsを用いていても安全ではない、安全かどうか確認することが非常に煩雑になってしまいます。これではHTTP/2はHTTP/1.1に比べて後退してしまいます。

じゃぁどうすればいいの？

通信の秘密・言論の自由は憲法・電気通信事業法で保障された国民の権利です。一方子どもの権利は優先されるべき権利であり、それらを犯す児童ポルノなどを規制しなければならないことも理解できます。どちらも僕らの社会を支えるとても大切な権利だと信じています。

僕自身答えは持ち合わせていません。

いくつかのユースケースに対しては他のアプローチにより問題を解決することは出来ます。たとえば、キャッシュの問題ではキャリアがCDN-likeなサービスを安価で提供し、コンテンツプロバイダーが利用することで暗号化されるべき情報のみコンテンツプロバイダからサーブされ、画像などはCDNから配信するようなアプローチです。

しかしHTTP/2の持ち合わせるパフォーマンス改善など華やかな部分が取りただされている間にこの提案がなされ、静かにしかし確実に僕らのインターネットを変化させようとしていることを見逃してはいけないと思っています。

この問題はHTTP/2だけではありません。たくさん議論をしても皆が納得する結論を導くのは難しいと思っています。

コメント欄でもTwitter上でもかまいません。いろいろな意見をいただけるとうれしいです。

Natashaもこの問題を英語でも書いてくれています
Pervasive Monitoring, HTTP2, TLS: Why Can’t the User Decide?

免責事項

• この記事は私の視点であり、所属するいかなる組織の意思を示すものではありません
• 私はネット中立性・インターネットの自由・通信の秘密・表現の自由を支持しています

ついにiPhoneでIPv6が使えるようになった！

iPhoneにおけるiPv6はiOS 6時代からサポートされており、VerizonではiPhone 5からサポートされていた。これはVerizonはLTEにおいてIPv6をオプションではなく必須テクノロジーとしたためである。 ((IPv6 at Verizon Wireless))

そのため、iPhone 5以降iOSデバイスはIPv6をサポートしているのだが、Carrier Bundleの設定で有効にされているキャリアと有効にされていないキャリアが存在する。

CarrierBundle内のRequiresIPv4v6PDPTypesがTrueになっている場合に対応するのだが、KDDI Carrier Bundleでは15.1からサポートされ、Carrier Bundle的には対応した。

しかし現実にはこれだけでは動くわけではない。APN側でIPv6アドレスを払い出さない限り使用することができない。KDDIではLTE NET for DATA ((http://www.au.kddi.com/mobile/charge/list/ltenet-for-data/))というISPサービスでグローバルIPv4/IPv6アドレスの払い出しを行っている。
上記ページにはiPhone, iPadは対応していない旨が書かれているが、実際はAPNを書き換えることで動作する。

そこで、APNをLTE NET for DATAのau.au-net.ne.jpに書き換えることで、IPv6での通信が可能となる。

構成プロファイルを使うことで自分でも設定することが可能だが、実際に動作を確認したプロファイルを置いておくのでもし良かったら使ってください。
KDDI_iPv6_enabler : https://nunnun.jp/src/KDDI_iPv6_enabler.mobileconfig

追記: KDDIのホームページにやり方書いてあった。（いつの間に！）kazubu thanks!!
LTE NET for DATAの利用方法

手元の端末ではiPhone 5 / iPhone 5s / iPad miniで試してテザリング含めて動作することは確認しました。

iOS 7でMPTCP(Multipath TCP)がサポートされた。 ((Apple iOS 7 surprises as first with new multipath TCP connections))
唐突 ((しかし実はIETF87で、anonymous OSが実装しているという話もあり、iOS 7がそれだったのかと納得した訳だが))なのだが僕の博士課程における研究テーマであり、先のIETFで大人たちにメッタメタにされたのも悔しいのでMPTCPについて説明して、何が出来るようになるかを書きたいと思う。

MPTCPとは簡単にいうとTCPストリームを複数の経路で転送することにより、ストリームの多重化・耐障害性の向上を図るプロトコルである。

このタイミングでなぜこうしたプロトコルが必要か簡単に説明したい。
僕らが使うアプリケーションは大抵TCPを用いて通信をしている。それは長いインターネットの歴史でもあり、順序制御・再送制御・誤り制御をトランスポート層のプロトコルが行うことにより、僕らはそういったことを意識せず済むからである。
TCPはIPおよびポート番号を用いてストリームを識別する。例えばsrc: 192.168.0.1:3208 dest: 192.168.0.2: 63234といった形だ。そのためIPアドレスやポート番号が変更されると通信を継続するにはTCPストリームを再接続しなければならない。

話を変えて僕らが持つスマートフォンは大抵3GとWiFiという2つのIPインターフェイスを持っていることが多い。TCP・UDPでは1つのストリームにおいて複数のIPアドレスを用いることが出来ないため、通常どちらかのインターフェイスを優先的に使用するように制御されている。例えばWiFiが有効な環境においては新規のTCPストリームはWiFiのIPアドレスを用いて通信するなどだ。
この発想はインターフェイスが頻繁に変更されない場合有効である。しかし、インターフェイスが頻繁に接続・切断を繰り返しインターフェイスのスイッチが頻繁に発生するような場合（例えば公衆無線LANが入り乱れる都心の市街地を歩いているような場合）においてTCPセッションはインターフェイスが切り替わる度に再接続を行わなければならない。
TCPは僕らが生まれる前(1982年)に発明され、その当時の不安定な回線において信頼できる通信を行うために、3-way handshakeを必要とする。3GやWiFiなど遅延が大きなネットワークにおいてただただ通信を開始するためだけにパケットを往復させることは通信に大きな遅延を引き起こす。これが市街地において特に移動中公衆無線LANが全く使い物にならない原因の一つである。
（もちろんWiFiのイニシエーションにも時間がかかるので、それを早くしようという802.11aiなどもあるがこれは後日）

そこでTCPが持つ1つのIPアドレス・ポート番号でバインドされた経路しか使えない状況を改善し、複数の経路を用いてTCPのような通信を可能にしようという取り組みがなされてきた。
SCTPはPoint-to-point のプロトコルであるものの、エンドホストが複数のアドレスをサポートするため、エンドホストに到達するために複数のアドレスを使用することが可能であり、それにより下層レイヤー（つまりIPインターフェイス）の切替といった場合にもストリームが切断されることなく通信が可能なプロトコルである。
またMobile IPやMobile IPv6といったIPレベルでの取り組みもなされた。Mobile IP/IPv6はホームアドレスと呼ばれる移動をしても変化しないアドレスを用いることでインターフェイスが切り替わりネットワークをハンドオーバーしてもTCPやUDPなどIPアドレスをキーとして依存するプロトコルの切断を防ごうという取り組みである。
さらにはもっと低いレイヤーで3G/WiFiのハンドオーバーといった研究開発が行われてきた。

しかしながら、今日現在いずれのプロトコルもliftすることができていない。
なぜなら僕らはTCP・UDPをから逃れることができないからだ。
現在僕らがインターネットで使う殆どのプロトコルはトランスポートにTCP/UDPを使用して、インターネットもTCP/UDPを前提に設計・運用されている。例えばIPv4アドレスを共有する手法としてNATがあるが、NAT自体TCP/UDPに特化していて(もちろんGREとか対応しているのもあるけど) いくらTCPが先に述べたような問題があったとしても星の数ほどあるNAT-boxをSCTPに対応させるということは不可能である。
また3G/WiFiのハンドオーバーなども3G/WiFiいずれも同じネットワークオペレータが運用するといった場合には実現が可能でも、今日のインターネットような様々な組織が様々なネットワークを運用する形態においてはなかなかdeployすることが難しい。（技術的にもポリシー的にも難しい）

そんな中TCPを殆ど改変せず複数のストリームを扱えるようにしようという発想で提案されたのがMPTCPだった。
プロトコルの詳しい説明はきちんとまとめて記事にしたいので控えるが、MP_CAPABLEと呼ばれるTCPオプションを用いてエンドホストでnegotiationを行い、双方がそれをサポートする場合に限り2つ以上の経路を用いて通信を多重化し、下層レイヤーの障害の影響を受けずにTCPセッションを維持することが出来るTCPの拡張プロトコルである。
このMP_CAPABLEなどの処理はOSなどに実装されたTCP実装が透過的に行うため、アプリケーションからは普通のSocketと同じように利用することが可能である。つまり既存のアプリケーションを変更することなく、自動的に複数の経路を用いて障害に強く、多重化されたTCP通信を行うことが出来る。SCTPなどはアプリケーション自体の書き換えが必須であったことを考慮すると非常に有効であるといえる。

TCPオプションという話をすると必ず問題になるのがmiddleboxである。
理想的な環境ではインターネットを流れるパケットは改変されることなくエンドに転送される。しかし、現実のインターネットではNATやファイアウォール、更にはアプリケーションアクセラレータなどパケットを改変する中間者が大量に存在する。
MP_CAPABLEなどの未知のTCPオプションが存在する場合、そうしたmiddleboxはパケットを破棄したり、TCPオプションの破棄などを行うことが指摘されている。 ((Is it Still Possible to Extend TCP? Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam Greenhalgh, Mark Handley and Hideyuki Tokuda, ACM Internet Measurement Conference (IMC), November 2011, pp.181-192, Berlin, Germany))
そこでMPTCPではそうしたmiddleboxが存在している場合でも通信を行えるような仕組みや、最悪の手段としてTCPにフォールバックする仕組みが存在している。 ((How Hard Can It Be?! Designing and Implementing a Deployable Multipath TCP))

前振りが長いが、で、MPTCPがiOS 7でサポートされて何がインパクトが有るか。さーっと考えてみた限りこんなインパクトが考え得る。

• 3G/WiFiのハンドオーバーがスムーズになる
• 優先制御が可能であるため、回線の重み付けが可能にある
  ここでは説明していなかったが、MPTCPでは経路毎の優先制御が可能である。
  例えば3G:10%, WiFi:90%といった具合である。この場合もWiFiが切れても自動的に3Gで再送が行われるため、TCPセッションは切れることがない

現時点ではLinuxとfreebsd, iOS7でしか実装されていない。
GoogleはRTTの影響を受けにくいプロトコルとしてUDPをベースとしてQuicを提唱している。Quicももちろん有効に働くと思うが、Quicの場合アプリケーションの書き換えが必要になる。
MPTCPはカーネルにおいて処理されるため、アプリケーションの書き換えなしにストリームの多重化が可能になる。もちろんどちらのプロトコルが優位であるという議論をしたいわけではない。

iOS 7ではまずはSiriでMPTCPが有効にされているという話だ。
ユーザの音声データをなるべく早くサーバに送信したい（でも失敗したくない＝再送は時間がかかるのでUXに影響がでる）ので、WiFi/3Gの両方を使うことで確実に早く転送したいというケースで、MPTCPのユースケースとしては非常に優れていると思う。

記事でも指摘されていたがこれから他のアプリでも有効になるのではないかと思う。
MPTCPはサーバでも有効にされて初めて効果がでるプロトコルなのでこれからサーバ側の実装も必要になる。まだまだユースケースも少ないプロトコルなので、標準化や研究にうまく結びつけていきたいなと思う。

ここは間違ってるとか、補足すべきことがあるとかあったら指摘していただけるとうれしいです。

iPhone 4はInternational Warrantyがあるので、フランスで買ったiPhone 4をアメリカのApple Storeで交換して貰えたって話は以前書いた。

けれど、どうも2chスレとかでiPhone 4S以降はルールが変わって修理を受け付けて貰えないって話が出てきて、そんなはずはないと思ったので、AppleCare+の申し込みを試してみました。

結論から言うと、

• iPhone 4S (米国・unlocked・AppleStoreから購入)
  問題なく加入できた
• iPad 4G+WiFi 3rd Gen (米国・AT&T・AppleStoreから購入) 
  問題なく加入できた

ということで、問題なく加入できました。
加入するときに、故障しても修理受けられることを確認してもらってから加入しているので、間違いないと思います。 

ちなみにiPhone 4Sはどうも米国版なら加入できるものの、香港版とかだとむしろダメだという話をApple Store Ginzaの人は話してましたが、なぞ。

なんていうか、ハードウェアは同じ（日本版はシャッター音っていうのがあるのでアレですが）で、Activation ServerでSIMロックの状態とかいくらでもいじれるのに、今までやってた国際保証をしませんって話は意味不明なので、人柱になってみました。

IETF 83に参加してきました。
今回初めてIETFに参加して、httpbisやhybiを見てきました。
個人的にはISOCの人から、World IPv6 Launchのステッカーを貰えて幸せです。

いつもは直行便でパリに行ってるのだけど、直行便の空席がなく（そんなことあるのね）初めてイスタンブールトランジットでパリに行ってみました。

ずーっと昔Connexion by Boeingが機内インターネットを提供してたんだけど、あの当時高かった＋スマホとか無かったのであっという間につぶれて無くなってしまったのだけど、最近JALとかがPanasonic AvionicsのeXConnectっていうIn-flight WiFiの導入を発表してて、ようやく国際線で再びインターネットができるようになった。（JALは2012年夏ごろとのことだけど）

ちなみにPanasonic Avionicsの機内エンタテインメントシステムは最近のBoeing 777-300ER(77W)とか787だと大体どこの航空会社の機材にも付いているみたい。

まぁアメリカだとGoGoとかが、AirCellっていう技術（要は地上に基地局を置いて、航空機と地上の基地局をEV-DO Rev. A.でつないでるらしい）を使ってサービスしてるんだけど、EV-DOじゃTrans-oceanなフライトは厳しいよねということで、アメリカ国内でサービスインしてた感じ。

で、このeXConnectはKuバンド(12-18Ghz)の周波数帯を使って、通信衛星が地上局との通信を中継することで機内インターネットを提供しているみたいです。

で、トルコ航空は最近Boeingから納入された777-300ERでIn-flight WiFiが使えるみたいで、少なくとも1機はすでにサービスインしているというわけで、たまたま帰りのIST-NRT間のTK050がIn-flight WiFiが使える77Wだったので早速試してみました。

In-flight WiFiがつかえる機材は、センタースクリーンのところにLive TVとWiFiのステッカーが貼ってあります。

こんな感じ。

実際に使えるようになるのは、高度10,000mの巡航になってからで”Turkish Airlines”というSSIDに接続できるはず。

つなぐと、www.thy-planet.comっていうドメインのサイトにつながっていろいろ同意をすると、T-Mobileのページに飛びます。ちなみにthy-planet.comはGoDaddyでパークされてるドメインみたいだけど、これって大丈夫なのかな・・・？笑（一応所有者はTurkish Airlinesになってるけど・・・）

無事つながるとこんな感じ。

で、まぁネットワーク好きなので、pingとtracerouteしてみました。
pingした結果は消してしまったのだけど、飛行機から日本のホストまでだと大体1100msぐらい。
Tracerouteした結果はこんな感じです。

試しにUSENだかの速度測定サイトで図ってみたら0.09Mbpsとでました。まぁ遅延ひどいしね。。

ただ、体感的にはもうちょい出てた気がします。それなりに快適にインターネットできてた感触です。
何よりもこれがタダで使えるっていうのがすごい。

ただ、おそらく当局の許認可が降りてない関係か、中国上空では使えませんでした。客室乗務員の人がトラブルで使えないって行ってたので、もしかしたらシステムトラブルなだけかもしれませんが・・・。笑

いずれにしてもこれがJALはじめ各社に導入されるようになるわけなので、長距離国際線で暇をもてあますこともなくなりそうです。
（☆組としては早くANAさまに導入していただきたいところです・・・。このままだとJLに乗り換えますよ！！！）

ちゃんちゃん

SIMロック解除されたiPhone 4SでドコモのSIMを使って運用できることは既知で、SoftBankやKDDIと同様にCarrier BundleをインストールすればCMAS(緊急地震速報)を受信することは論理的に可能だったのだけど、実際に設定して動作を確認した訳じゃなかった。

ドコモやソフトバンクの緊急地震速報は3GPPのCBS(Cell Broadcast SMS)という仕組みを使っていて、その中のMessageIdと呼ばれる情報要素が緊急地震速報である場合にアラートを出すという仕組みでした。[1]

ただ、どのMessageIdが緊急地震速報（というかエリアメール）に相当するかの情報は開示されていなかったので、どのメッセージを表示したらいいかわかりませんでした。

ちょうどドコモのエリアメール対応Androidを弄っていたところ、エリアメールに相当するMessageIdがわかったので、設定してみた。

具体的にはMessageIdが40960から41983なメッセージをドコモはエリアメールと扱っているみたい。
そこでSoftbank_jp.bundleを参考に改変してみました。こんな感じ。

<dict>
<key>MessageIDParameters3GPP</key>
<dict>
<key>OptOut</key>
<array>
<dict>
<key>ToServiceID</key>
<integer>41983</integer>
<key>FromServiceID</key>
<integer>40690</integer>
<key>Selected</key>
<true/>
</dict>
<dict>
<key>ToServiceID</key>
<integer>43009</integer>
<key>FromServiceID</key>
<integer>43008</integer>
<key>Selected</key>
<true/>
</dict>
</array>
</dict>
</dict>

ちなみに43008-43009はSoftBankのCarrier Bundleにもともと入ってたもの。

で、今朝の東京都の帰宅困難者訓練でエリアメールの配信を行う[2]とのことだったので、待機してたところ無事受信できた。

1. 緊急情報の同報配信サービスの開発 – http://www.ntt.co.jp/journal/0806/files/jn200806036.pdf
2. 東京都防災ホームページ：東京都の対策 – 帰宅困難者対策訓練 – http://www.bousai.metro.tokyo.jp/japanese/tmg/0203kitaku.html