HTTP2におけるProxyに関する議論

この記事はHTTP2 Advent Calendarの17日目の記事です。

はじめまして。nunnunと申します。HTTP2 newbieなので戦々恐々としておりますが、よろしくお願いします。

注意: HTTP/2.0はHTTP2もしくはh2と表記が変更になりました。

先日HTTP2のExplicit Proxyとそのプライバシー上の懸念について記事を書かせていただきましたが、その後のプロキシに関する議論を書きたいと思います。

IETF 91 HonoluluではProxyに関する議論がいくつか行われました。

  • draft-nottingham-web-proxy-desc-01
  • draft-loreto-wpd-usage-00
  • draft-chow-httpbis-proxy-discovery-00

背景

Explicit Proxyの議論が生まれた背景はGoogle ChromeのSPDY Mobile Proxyをキャリアが運用したいというモチベーションでした。SPDY Mobile Proxyをオペレータが運用することでTransparent Cacheなどのトラフィックエンジニアリングによるトラフィック削減が望めるため、HTTP2においてそうした仕組みを実現したいという目的で提案がなされた模様です。

draft-nottingham-web-proxy-desc-01

httpbisの議長であるMark NottinghamによるProxy Discoveryに関するドラフトです。従来HTTPにおけるProxyの設定はPAC(Proxy Auto Configuration)と言われるJavaScriptを用いてProxyを設定するという方式が用いられていました。JavaScriptを用いるため柔軟な設定が可能である反面、その設定URLを知らなければ設定できない問題が指摘されており、その問題点を解決するためWPAD (Web Proxy Auto Discovery)と呼ばれるDHCPもしくはDNSを用いてそのURLをnotifyする仕組みが提案され、Internet ExplorerやFirefoxなどで実装され、利用されてきました。

本提案ではまずHTTP/2 over TLSの利用を必須としています。従来のPACではクリアテキストでの設定も許容されていましたが、MiTM攻撃なども想定できることから証明書の検証が必須となっています。

またどのホストにどのプロキシを利用するといった設定がJSONによる形式に変更となりました。設定では、Proxyの名称、目的を記載するだけでなく、プロキシが企業などで利用されることが多いことから、プロキシを適用するネットワーク(IPアドレスがレンジにいる場合のみに適用するなど)を追加することができるようになりました。

更にはブラウザにおいてIncognitoモードに代表されるプライバシーモードが広く使われていることから、プライバシーモードの利用を強制するオプションの設定が可能となっています。

従来のWPADによるDiscoveryは禁止されたものの、well-known URIを用いたdiscoveryを行うことが規定されています。

draft-loreto-wpd-usage-00

MarkのWPDドラフトを拡張したドラフトがdraft-loreto-wpd-usage-00です。

特徴としては携帯電話ネットワークなどの高遅延、高ジッター環境で利用することを想定し、いくつかのトラフィックタイプ(Class of Serviceに近い)をlabelというタグを用いて分類し、それらトラフィックタイプ毎にプロキシを設定することを可能にしています。そのため、クライアントはコンテンツに応じてプロキシを使い分けることが可能となり、より最適化された通信が可能となるそうです。

draft-chow-httpbis-proxy-discovery-00

draft-chow-httpbis-proxy-discovery-00はWiFiのキャプティブポータルなどと組み合わせることで、明示的に同意を取ることでhttpsスキームな通信もProxyする(ただし”it MUST NOT alter the end-to-end encryption for “https” requests”と規定)ことも可能としています。
(きちんとドラフト読み込めていないので間違っていたらすみません)

ただしこれはMiTMであり、エンドツーエンドでのセキュアな通信を犯す可能性があるため、個人的にはhealthyではない提案であると感じています。

IETFでの議論

IETFではさまざまな議論が行われましたが、結局WGとしての結論は出ず何かをWG itemとして標準化するという結論には至りませんでした。

まとめ

WPADやPACといった仕組みはold-fashionな技術であるため、新しい仕組みが必要であると個人的に感じ、Internet Confidentialityに関するIABのステートメントや、現在W3C TAG(Technical Advisory Group)によるHTTPSへの移行に関する指摘事項ドラフトなどの流れを踏まえると安全にプロキシをDiscoverする仕組みの策定は重要であると感じています。

第4回IGCJ(日本インターネットガバナンス会議)に参加してきました

去年の6月から開催されているIGCJ(日本インターネットガバナンス会議)が4回目となり、インターネットウィーク期間中に開催されているので参加してきました。(参加自体は初回からしていますが)

IANA監督権限の移管に関するアップデートやITU全権委任会議での報告などがありましたが、スライドなどはアップロードされているので、個人的に気になったポイントをまとめたいと思います。

IANA監督権限まわり

粛々と進んでいるなという印象を受けました。基本的にIANA機能はICANNにお願いするという方針で、LACNICがMONC (Multistakeholder Oversight Number Council)というマルチステークホルダな組織がIANA機能の監視をするといった提案をしているのが変わってるなと感じました。

個人的にはNROが地域RIRの活動のコーディネーションとかもしており、これ以上マルチステークホルダにしなくても良いのではないかと感じましたがどうなるかはこれからです。IETF側もIANAPLAN BoFで粛々と進んでいるので、deadlineは近いですがこのまま行くのかなと思います。

ITU全権委任会議報告

4年に1度開催されるITU全権委任会議、ITUの最高意思決定機関。今回の焦点(インターネット的な文脈)はWCIT-12で問題となり改正ITR(アラブ諸国などの提案からセキュリティやスパムなどに国が積極的に関与すべき, インターネットに関するルール策定に国連がもっと介入すべきという方針になったが、日本を含む欧米各国は不署名)によって広がった対立をどう回避出来るかが焦点。
ITUではポリシーの策定は、各国が既存の決議に対して修正提案をする or 新規決議の提案をするという形で実施される。

基本的に日本を含む先進各国はインターネットに対する政府の権限を増やすという提案には反対をしたので、修正提案は取り下げという形となった。ITUの作業部会をもっとオープンにすべきという提案についてはインターネットに関する作業部会は事前にオープンなコンサルテーション会合を開くという方針に。これもマルチステークホルダモデルを踏まえた形なのかなと。

質疑で日本が決議に反対する理由としてITUのマンデート外なので反対という理由をしているが、現実的にはどういう観点で決議への賛否を決めているのかという質問があり、情報な自由の流通を確保することが大前提。それが阻害されるような項目については反対をするという方針という説明がされてた。

インターネットの透明性や非合法盗聴などについては、そもそも国連では人権を担当する委員会とかがあるのでそっちが担当して、ITUは技術について注力するという話があった。個人的にはここは重要なのかなと思っているので、そこら辺のアップデートが聞ける場があったらよいなと思いました。

IGCJを考える会レポート

いろいろな意見が出ていましたが、個人的に思ったのは「プロ」「コーカス」「オーディエンス」という分類で、インターネットガバナンスに関わる人は割と限定されてしまっているため、会社を代表していう意見とインターネットを利用する個人としての意見をうまく帽子を被り変えながら喋らないといけないというのが難しそうだなと言うのを感じました。個人の意見と会社の意見が一緒であればいいのですが、なかなか難しかったりしそうだなと・・・。

IGF2014報告

NETmundialとかはオープンといえども招待を受けないと参加できないのに対してIGFは誰でも参加できるというのが特徴。IGFについては僕の勉強が足りていないので情報収集をしないとなという印象を受けました。(ちゃんと議論を聞けなかったので、まとめきれてなくてすみません。そしてごめんなさい)

雑感

全体的に感じたのはインターネットガバナンスに関して日本ではJPNIC, JPRSさんに頼りすぎているなというのを感じました。もちろん彼らの業務範囲であるので情報集めて、僕らにわかりやすいようにまとめて、そして僕らが考えてそうなことを会議とかで発言していただいているのかなと思うのですが、インターネットはみんなのものだと思うのでもっとインターネットに関わるいろいろな人が意見を出したり、情報を発信していかないといけないなと思いました。JPNICさんとかは妖精さんではないですからね。。。

マルチステークホルダモデルについては勉強が足りてないのですが、究極のマルチステークホルダってマルチステークホルダモデルを作るにはどうしたら良いかの議論をマルチステークホルダでやろうみたいな話になって、以下無限ループみたいになってしまうのですが、ある程度の妥協とわかりやすい仕組み作りが大切かなというのは思いました。

エンジニアな観点だとポリシーの世界はいろいろややこしいと思いますが、エンジニアリングだけで解決できない問題はいっぱいあるのでそのためにももっとエンジニアがガバナンス・ポリシー策定に関わるとよいなと思いました。

インターネットガバナンスnewbieなので、いろいろ間違った認識、おまえ何言ってんだとかあると思いますので是非是非ココ間違ってるよとかご指摘いただけるとうれしいです。

カナダ国境でのlaptop searchについて

2013年11月にカナダ バンクーバーで行われたIETF 88に参加する時に起きた話なので少し古い情報です。

2013年11月3日にIETF 88に参加するためにカナダのバンクーバー空港で入国後、バゲージクレームエリアでカナダ国境サービス庁による手荷物捜索を受けました。通常手荷物捜索は税関などが非申告の禁輸品の所持を確認するためなどの行うのですが、すべての乗客の荷物を捜索することは難しいため、ランダム(もしくは彼らが疑うに足る事由がある場合)に選択して捜索を行うのですが、私が受けた手荷物捜索では児童ポルノの所持を確認するために所持していたデジタル端末すべてのパスワードを教えてなければならないというものでした。

詳細な経緯は以下の通りです。

手荷物を受け取った後、通関ゲートに向かっていたところ、カナダ国境サービス庁の職員にカナダを訪れた理由を聞かれ、IETFへの参加であることを告げたところ、手荷物の捜索を行うということで、ブースに案内されました。
そこで手荷物の捜索に協力していたところ、デジタル端末の捜索(laptop search)も行うのでこの場で(ちなみにオープンなカウンターで他にも”ランダム”に選ばれたアジア系の若い男性が同じようにデジタル端末の捜索を行われていました)パスワードを口頭で言えと告げられました。
そもそも児童ポルノは禁輸品であり、児童の人権は守られなければならないということは認識していましたが、オープンな場所であることや、通常この手の捜索は捜査令状などが必要なのではないかと思い、拒否することを告げたところ、職員より拒否する権限はないと言われました。
しかしながらオープンな場所で口頭でパスワードを告知することは避けたかったため、文字で書くので代替できないかと交渉したところ、それは認められ、職員が所持していたメモ帳(ちなみにそれには過去に同じように捜索を受けた人のパスワードがいっぱい書いてありました)に書くよう言われました。その後職員は私の所持していたデバイスをすべて持ち、バックオフィスに行きカウンターで待機するよう命じ約30分ほど待機しました。
もちろん私は法で禁じられた画像や動画などは所持していないため、30分ほどした後職員は戻り、私は空港の外に出ることが出来ました。

私はこの捜索にはいくつもの問題があると感じています。

  • 捜索の妥当性
    どのような理由で私が選ばれたのかわかりませんが、数百人の乗客から同じように捜索を受けていたのがアジア人の若い男性のみであったことはたとえランダムだとしてもとても恣意的に感じました。
  • 運用方法について
    BC Civil Liberties Associationによると、捜索では”Electronic Media Search Form”に記入をしなければならいと規定されていますが、実際には口頭申告されたパスワードをメモ帳に書き込むというずさんな方法で捜索が行われました。職員の対応にはプロフェッショナルさを感じることは出来ませんでした。
  • 何を優先すべきか
    児童の人権は優先すべきですが、一方個人のプライバシーも大切です。児童ポルノの捜索だけを行うのであれば、別室にラップトップを持っていくというオペレーションではなく、目の前で捜索することも可能だと思います。別室にラップトップを持っていったということは児童ポルノも関係なくデータはコピーされたと考えざるを得ず、またPRISM問題直後でしたのでバックドアを仕込まれた可能性も否定できませんでした。
    また例えば私が政府関連の仕事に従事していた場合、この捜索の結果機密が他国の政府にわたる可能性もあり、これには外交官特権のみでしか対抗することができません。
    更にはもし私が仮に児童ポルノを所持していたとしたらデータを物理デバイスに入れて国境を横断するなどというわかりやすい行為はしないでしょう。暗号化してどこかのサーバにアップロードするなどすると思います。つまりこのlaptop searchでどれくらい児童ポルノが国内に持ち込まれるのを防げたかについては疑問が残り、それにより侵害される個人のプライバシーの方が大きいのではないかと思います。

法治国家に生きる市民として法律に定められた正当な行為なので従いましたが、残念ながら心地よい対応ではなく、タイミングもあって強い憤りを感じました。

法律の専門家ではありませんので、細かいところは違うかもしれません。
その直後のFacebookポストも参考にリンクしておきます。

児童の人権と個人のプライバシーどちらもが尊重される社会が訪れるとよいなと切に願います。

適切な暗号スイートを選択する: BetterCrypto.org

SSLの暗号スイートはApacheなどのデフォルト設定を使えば安全と信じたいところなのだが、RC4の危殆化に伴って、RC4を無効にしないといけなかったりやPRISM問題が発生してPFSを有効にしたりと暗号スイートを自分で設定しないといけないパターンが増えてきたと思う。
(もちろんディストリビューションがデフォルトの暗号スイートを変更するのを待つという手もあるのだが、)

しかし自分で暗号スイートを選択して設定するのは困難だ。
僕は暗号の専門家ではないのでどの暗号が危殆化してないかとか、どの暗号を使うのが最適かとかを適切に選択できる自信はない。
かといって、適当にGoogleで出てきたApacheのSSLCipherSuite設定をコピペするのも不安だ。

そんな心配を解決してくれるのは、BetterCrypto.orgというサイトである。
オーストリア版CERTの中の人が、最新の安全な暗号スイートを簡単に設定出来るように常にアップデートしてくれている。

ApacheのSSLCipherSuite設定にサイトに記載されている暗号スイートをコピペすれば簡単にPFSなどを設定出来る。

オーストリアのCERNの推奨する暗号がセキュアかどうか信用できないから、自分でセキュアかどうか調べたいという人は、CRYPTREC電子政府暗号推奨リストを参照するとよい。
CRYPTRECとは総務省・経済産業省・NICT・IPAで構成された暗号の安全性・実装性について客観的に評価する組織で、様々な暗号を電子政府推奨暗号(今使える暗号)・推奨候補暗号(今後使う可能性が高い暗号)・運用監視暗号(危険なので使ってはいけない暗号)1 に分類してくれている。

セキュリティは沼なので逃げたくなるときもあるが、簡単に安全な設定をする方法(しかも安全性が検証された形で)が提示されはじめているので、そういう情報だけでもチェックしておくと良いのかもしれない。

  1. 括弧内の表現は目安として書いただけに過ぎないので、分類の詳細はきちんとCRYPTRECのサイトを参照してください []

HTTP/2における明示的プロキシ(Explicit Trusted Proxy)について

先日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)に対応した話などを目にしたことがあると思います。1

更には先週IABとW3CによるInternet Pervasive Monitoring(大規模モニタリング)に関する共同ワークショップ STRINT Workshopが開催され、Opportunistic keying2 について取り組もうという話が出るなどエンド間における暗号の重要性が高まっています。

話を戻して、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 / 合法的傍受)

などの理由3により、TLSによる暗号化をすべきでないという意見があります。

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

Explicit Trusted Proxyの提案

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

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

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

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

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

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

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

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

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

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

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

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

httpsを使う限り安全である8 通信が、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?

免責事項

  • この記事は私の視点であり、所属するいかなる組織の意思を示すものではありません
  • 私はネット中立性・インターネットの自由・通信の秘密・表現の自由を支持しています
  1. PFSについての解説と、なぜPFSが重要かは、Lavabit 事件とその余波、そして Forward Secrecyに書いてあるので見てみてください []
  2. 日和見暗号・Opportunistic Encryptionとも。httpsなどは暗号通信を行うことが明示的に同意されているが、httpなど明示的には暗号通信を行わない通信においてもエンド間が暗号を利用できる場合、暗号を利用することで安全に通信を行おうという考え []
  3. 詳しくはhttp2 Githubに記載されたProxy-use-caseを参照: Proxy User Stories · http2/http2-spec Wiki []
  4. Pervasive Monitoring is an Attack: https://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ []
  5. Man-in-the-middle: 中間者攻撃 []
  6. Application-Layer Protocol Negociation: 詳しくは@flano_yukiさんによるALPNについての解説を参照 []
  7. User-Agent: ブラウザのこと []
  8. PRISMの例や、httpsでも弱い暗号を使っていて第三者に解読される場合などはありますが []

JALの国内線で機内WiFiが使えるようになる話

2014年夏から国内線でも機内WiFiが使える様になるそうだ!1

JALの国際線では去年の夏から機内WiFiが使える様になってすごく便利なんだけど、機内WiFiは主に2つの方法で航空機と地上とを結んでいるので紹介。

  1. Kuバンド帯を使った衛星による通信
    Kuバンドという衛星通信でよく使われる周波数帯(12-18GHz)を用いて航空機と衛星、衛星と地球局(つまり地上)と結んでインターネット接続を可能にする方法。
    この方式だと衛星に接続出来る範囲(要リサーチ)がかなり広いので、ほとんどのエリアをカバーすることが出来る。2
    欠点としては衛星を経由するのでコストがかかる。(衛星の資源は限られてるからね)
    そして地球局はあまり分散されていないので、インターネットネットワーク的に不効率な場合が多い。
    例えばJALやトルコ航空などはT-mobile DEを地球局にしているので、日本の上空に居ても
    [航空機]-[衛星]-[地球局(ドイツ)]-[日本のWebサイト]
    みたいになって通信が非常に遅くなる。
  2. Air-To-Groundによる通信
    これは衛星を使わずに航空機と地上を結びインターネット接続を可能にする方法。
    簡単に言ってしまうと地上にアンテナを設置してそれと航空機が通信する感じ。
    今回JALが提携したgogoはATG-4というネットワークを米国国内に展開していて、160以上の基地局を設置している。
    航空機と基地局の間はEV-DO Rev.B(つまりCDMA-2000)で繋がっている。まさに携帯電話の電波を空に向けて出しているような方式。
    これだと衛星を使わずに済むので、安価にネットワークを作ることができる。
    しかし海上などでは基地局を設置できないのでネットワークを作ることが難しい。

今回JALがgogoと組んだので、てっきりATGでネットワーク組むのかと思ったのだが、中の人からリプライ貰ってどうもKuバンドで組むらしい。海や山が多い日本では基地局を設置するよりも衛星の方が良さそうですよね。3

どちらの方式にもメリット・デメリットがある。
アメリカのような国ではATGは良さそう。海が多い国では衛星。

飛行機に乗ってる間ぐらいしかオフラインになれないのにネット導入するとはむきー!!っていう話も非常に理解できるんですが、個人的にはネット有れば機内で暇にならないので早く導入してほしいなと思っています。

p.s.
ところで青い航空会社はいつになったら国際線に機内WiFi導入してくれるんだろう。。。
一応2013年の夏導入開始って話らしいんだけどね。。。げほげほ4
あ、なんか特定の便ではロールアウトしてるって話も聞くけど中の人こっそりおしえてください。

  1. 国内線においても「JALの新しい空 」が始まります – https://www.jal.co.jp/inflight/dom/new_seat/ []
  2. ただ成田-ニューヨークでも3,4個の衛星をハンドオーバーしてるらしい – https://www.ituaj.jp/wp-content/uploads/2013/04/2013_05-3_spsky.pdf []
  3. https://twitter.com/Gogo/status/394880907003580416 []
  4. ANA国際線機内で、Wi-Fiサービスがご利用できるようになります – http://www.ana.co.jp/pr/12_0406/12-ana-onair0625.html []

KDDI版iPhone 5/5s/5cでIPv6をつかう

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

20130927-161641.jpg

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

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

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

しかし現実にはこれだけでは動くわけではない。APN側でIPv6アドレスを払い出さない限り使用することができない。KDDIではLTE NET for DATA2という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で試してテザリング含めて動作することは確認しました。

  1. IPv6 at Verizon Wireless []
  2. http://www.au.kddi.com/mobile/charge/list/ltenet-for-data/ []