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

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

20130927-161641.jpg

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がサポートされた話

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 5Sのために徹夜した

au版ホワイト 64GBをゲットしたので満足している。
ただMNP予約番号を取り消さないと手続きできないという罠にハマって待機中。

ドコモ、ドコモってみんな話してたのに全く並んで無くてワロタ。

ゴールド個人的には微妙。。。グレーは在庫いっぱいだし質感良いしいいかも。

沖縄からこんにちは

5年以上ぶりに家族旅行で沖縄に来てもblogを更新を続けるアカウントがこちらになります。

海はきれいだし、美ら海水族館に行ってイルカショーみて満足だし、ダイビング潜って大満足なんですが、ばっきゃろーBuffaloさんのiPhone 5防水ケースに入れてたら浸水してiPhoneがお亡くなり疑惑に・・・。(幸い速攻気付いて乾かしたのでたぶん平気・・・だけど海水だし・・・
DSC00163DSC00295DSC00305

Nucleus CMSからWordPressへの移行

先に述べたように、Nucleus CMSとPHP 5.4の相性問題がひどくどうしようもなかったので、Wordpressに移行した。

その際の手順を今後のためにメモ

  • 記事の移行
    記事はNP_ImpExpというプラグインでMT形式に書き出してインポート
  • コメントスパム系
    これは事前にNucleus側のDBを弄って削除しておく。そうじゃないとWordpress側で死ぬほどコメント消さないといけなくなって面倒
  • メディア
    Nucleus CMSの/mediaフォルダをWordpress側にもコピーすれば終わり
  • URL周り
    未解決。Nucleus CMS側でCustom URLとかFancy URLとか使ってると手動で変換するしかないのが実情。
    404にならないように記事のPermalinkの最後部分だけ一緒にしておいて、検索して表示してあげるとかすると良いかも。

 

Reboot

いままでNucleus CMSっていうエンジンを使ってたんだけど、
PHP 5.4に対応するとかしないとかで死ぬほど面倒になったのでskyblue.me.ukの記事も合わせて全部移行した。

これでblogをreboot出来るとよいのだけど。。。

高校生時代の痛い記事とかPrivateにまだ出来てない・・・。

SIMフリーなiPhone 4S と iPad 3rd GenでAppleCare+を契約する

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ロックの状態とかいくらでもいじれるのに、今までやってた国際保証をしませんって話は意味不明なので、人柱になってみました。

トルコ航空のIn-Flight WiFiを使用してみた

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フリーなiPhone4Sで緊急地震速報を受信する

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

facebook cardを作った

moo.comとfacebookがコラボして、新しいTimelineへの移行を実施したユーザ向けにfacebook cardなるものをタダで作れるキャンペーンを行っていたので、作ってみた。


[Instagram]

Timelineをつくって、Facebook Cards from MOO にアクセスすると作ることができる。50枚までは送料含めてタダ。

発注したのが、1月19日で東京の自宅に届いたのが、1月30日なので大体1週間と少しぐらい。サイトには2週間待ってねって書いてあったので大体そんな感じ。


[Instagram

かなり前に、ブロガー界隈で流行ってたmini cardを作ったことがあったので、紙の質感とかわかってたんだけど、紙は結構いい紙を使ってて割と厚め。日本の標準的な名刺だったら3枚ぐらいの厚さかな。

タダなのは申し訳なかったので、一緒に有料のステッカーを作った。

[Instagram]
こいつは90枚で£4.29 + 送料£1.25 で大体670円ぐらい。 
ちなみにアイコンはかもめハウスっていう後輩とやってるシェアハウスのもので、大学の後輩の@chamooiさんに書いてもらいました!かわいくて気に入ってます。

なんか今ならキャンペーンやっててタダだし、なんかmooのメールとかいちいちかわいい[1]ので、よかったら作ってみるといいと思います。

[1] なんか自動送信のメールの最後に、

I’m Little MOO – the bit of software that will be managing your order with moo.com. It will shortly be sent to Big MOO, our print machine who will print it for you in the next few days. I’ll let you know when it’s done and on its way to you.

とか書いてあってかわいい