6LoWPAN のはなし
前回は IPv6 仕様制定 20 周年記念として、IPv6 が制定当時に描いた理想とかけ離れた現状、そして「IPv6 の組み込み向けサブセット仕様」を目指した TACA プロジェクトの敗退について(毒舌気味に)に語りました。しかし「IPv6 の小型軽量版」という話は思わぬところから盛り上がりつつあります。今回は IoT を支える(かもしれない？)キーワード、6LoWPAN のおはなしです。
6LoWPAN とは
「6LoWPAN」という妙な名前は IPv6 over Low-Power Wireless Personal Area Networks の略とされており、慣例的には「シックス・ローパン」と発音されます。2007 年に RFC4944 として標準化された仕様で、その目的は IPv6 プロトコルを IEEE802.15.4 無線 PAN 上で稼動させることでした。
IEEE802.15.4 は今まで何度かこのブログでも言及してきましたが、世間的には「Zigbee」として知られています。しかし「Zigbee」はアプリケーション・プロファイルまで含めた製品仕様体系の呼称であり、802.15.4 はその下回りに用いられる無線規格として独立しています。そして Zigbee は TCP/IP を使わない独自の通信体系(NWK/APS)を採用しており、従って「6LoWPAN」と「Zigbee」は同じものどころか、同じ 802.15.4 という土台の上で対立する規格とも言えます(※註)。
※註：ただし Zigbee Alliance も 6LoWPAN を含む IPv6 over 802.15.4 の仕様一式を「Zigbee IP(またの名を 920IP)」として定めており、必ずしも「Zigbee Alliance と 6LoWPAN が対立」している訳ではありません。ですが「いわゆる Zigbee(Zigbee Pro)＝非 IP ベースの古典的な Zigbee プロファイルを用いた機器」と「Zigbee IP」に互換性や相互接続性はなく、同一 PAN 中での共存もできません。
6LoWPAN が作られた理由
TCP/IP はもともと、特定のデータ通信手段(リンク層)に依存しない通信仕様でした。世間一般的にはイーサネットおよびその眷族(WiFi を含む)が多用されますが、必要とあらばシリアル回線を用いた SLIP リンクでも接続できますし、ジョーク RFC の傑作 RFC2549「IP over Avian Carriers」のように、IP データグラムを印刷し伝書鳩に括りつけて交換することでも「理論的には」コネクションは成立します。IPv6 の仕様制定時にも、最低限 MAC フレームの格納形式を定義するだけで多種多様なデータリンク層で稼動することが目標とされていました。それならば、なぜ IPv6 を 802.15.4 上で稼動させるにあたり「MAC 格納形式を定めるだけ」では済まなかったのでしょう？
最も大きな理由は、802.15.4 の MAC フレームが最大 127 バイトと短いことでした。IPv6 ではリンク層の最短データ長(minimum MTU)を 1280 バイトと定めており、802.15.4 原仕様のままでは IPv6 の仕様要件を満たせません。仮に特例を設けて IPv6 を 127 バイトフレームで稼動させても、今度は「通信効率が悪い」という問題が出ます。802.15.4 で暗号化を用いるとペイロード長は 81 バイトに過ぎず、そこに 40 バイトの IPv6 ヘッダと 8 バイトの UDP ヘッダが乗ればセグメント長 は 33 バイトしか残りません。フレーム長のうち実に 74% をヘッダで消費する(TCP では更に条件が悪くて 21 バイト 84%)ことになり、いくら何でも効率が悪すぎます。
実装の細部に踏み込むと更に色々な問題が出てきます。一般的な TCP/IP では MAC アドレスと IP(v6) アドレスの関係づけをブロードキャストによる一斉問い合わせ(ARP または Multicast Neighbor Solicitiation)で解決しますが、省電力化のため通信タイミングを時刻同期している 802.15.4 で非同期のブロードキャストを乱発すると省電力化が台無しになってしまいます。また 802.15.4 では数珠つなぎ状のメッシュトポロジーがサポートされていますが、これを IP 上でどう実装するかも問題となります。メッシュ結合点を IP サブネット境界とみなしてプレフィクスを分離するならば、全ノードが同じプレフィクスを共有するリンクローカルアドレス(FE80::/10)ではメッシュ間接続ができなくなります(※註)。メッシュを IP サブネットとして扱うならばグローバル IPv6 アドレスを取得し、それを多段のプレフィクスを含むマルチネットワークとして設定しなければならないことになります。
※註：IPv6 制定時点では「こんなこともあろうか」とローカルネットワーク内でサブネットを切れるサイトローカルアドレス(FEC0::/10)が定義されていましたが、その解釈と存在意義をめぐって IETF 内で議論が紛糾したあげく、RFC3879(2004) で遂に廃止宣言されました。
つまり IPv6 仕様をそのまま 802.15.4 MAC に実装しても「理屈としては動くはず」ですが、データ効率も電力効率も無茶苦茶悪く、メッシュ接続のためには IPv6 アドレスの取得管理が必須という代物になるわけで、実用品として使い物になるとは思えません。6LoWPAN はいわば「ミドルウェア」として 802.15.4 MAC 層と IPv6 層の間に介入し、理想と現実をすり合わせるための仕様です。
RFC4944
6LoWPAN の原仕様 RFC4944 は 1684 行 30 ページ 66K バイト、4000 番台の RFC としてはとても短い部類に入ります。ただし後から RFC6282(ヘッダ圧縮拡張) と RFC6775(近隣探索拡張) という２つの RFC が追加仕様として発表されており、これを全部合わせると 6116 行相当というそれなりの量になります。またメッシュ制御プロトコルとして RFC6550 RPL (Routing Protocol for Low-Power and Lossy Networks) というものが定義されており(※註)、これは単体で 8796 行 157 ページ 352KByte というてごわい分量があります。
※註：ただし RFC6550 RPL はあくまで「IPv6 のメッシュ経路制御プロトコル」という定義であって、6LoWPAN とは直接の依存関係は無い立前になっています。
前述した問題の解決のため、6LoWPAN では下記の機能が実現されています。
- パケットの分割と再結合
- ヘッダ圧縮
- 近隣探索の対応
- メッシュの対応
RFC4944/6LoWPAN のパケットでは、MAC ヘッダと IPv6 ヘッダの間に 6LoWPAN のヘッダが入ります。6LoWPAN ヘッダ先頭の 8bit は識別コードで、これを「ディスパッチ(Dispatch)」と呼んでいます。ディスパッチは最短 8bit ですが、先頭ビットのパターンによって識別コード「以外」の情報も含み、必要に応じて可変長の「ヘッダ」が続く場合もあります。
802.15.4 / 6LoWPAN フレームの構造
802.15.4のMACヘッダ構造は802.3や802.11と大きく異なることに注意。
MACアドレスは64bitのEUI-64形式と16bitの簡易形式の選択式で、
802.3の「TYPE」に相当するフィールドは無く、802.2LLC/SNAPも付かない。
IPv6 の特徴的な「数珠つなぎヘッダ(Next Header)」構造は 6LoWPAN には採用されていません。またペイロードを示す識別子もなく、IPv6, HC1 ないし IPHC ディスパッチの後ろには必ずペイロードが付くという「暗黙の規定」となっています。このへんにも理想を追求した(しすぎた？) IPv6 と、否応なく現実に合わせた 6LoWPAN の成立過程の違いが垣間見えるようです。
分割と再結合
6LoWPAN でのフレーム分割と再結合は First Fragment と Subsequent Fragments というディスパッチで実装されています。データグラムの最大長は 11bit=2K バイトで、16bit の識別子(tag)が付き、２番目以降の Subsequent Fragments のみ 8bit のオフセット(1 カウントあたり 8 バイト、255*8で最大値2040)が付きます。
RFC4944 First Fragment ディスパッチ
RFC4944 Subsequent Fragments ディスパッチ
RFC2460 IPv6 Fragment Header (比較参考)
IPv6 の断片ヘッダ(FH)が「8 バイト固定長、識別子は 32bit、常に 13bit のオフセットが付きセグメント最大長 = 8 バイト x 13bit = 64K バイト」というのに比べると「たった 3～4 バイトを節約するためだけに新しい仕様を作ったのかよ！」とも思えますが、IPv6 ベースのパケット分割だと２番目・３番目以降のフラグメントにも常に IPv6 ヘッダが付くことになります。これは非圧縮で 48 バイト(IPv6 + FH)、圧縮が効いても 10～20 バイト程度をパケット毎に消費するので馬鹿になりません。これに対して 6LoWPAN の分割再結合では最初のフラグメントだけが IPv6 ヘッダを伴えば良いので、分割再結合時の効率は「6LoWPAN Fragment と IPv6 FH のヘッダ長の違い」以上に改善されます。
6LoWPAN による IPv6 分割の例
ヘッダ圧縮
RFC4944 では HC1 というヘッダ圧縮ディスパッチが規定されていますが、後でより高機能な RFC6282 IPHC が発表されたため、HC1 の仕様は「推奨されない」となっています。
HC1 は状態非依存(Stateless)で、「重複する情報」や「大抵の場合決め打ち」の情報をディスパッチ内のフラグビットで示すことで省略していました。「重複する情報」というのは、IPv6 ヘッダで大きな容積を占める送受信アドレスの下位 64bit は MAC アドレスから導出可能な場合が多い(Link Local あるいは Stateless Autoconfiguration Address)からです。
RFC4944 HC1 IPv6 圧縮ヘッダ・ディスパッチ
HC1 では発信元・宛先の IPv6 アドレスを上下 64bit に２分割し、それぞれが省略可能か否かを 2bit (それぞれSRC/DST)で示します。例えばリンクローカルプレフィクス＋MAC アドレスの場合は上下ともに省略されます。Stateless アドレスの場合は上位 64bit のプレフィクスのみが付加され、下位 64bit は MAC アドレスから導出される、という格好になります。
しかし HC1 のアドレス表記方式では上位プレフィクスはリンクローカル以外省略できませんし、アドレス下位も常に MAC アドレスと整合するとは限りません。6LoWPAN 網の中はともかく、ルーター経由で外部のアドレスと通信する場合はほぼ 100% 整合しません。また HC1 はディスパッチ前半 8bit を固定パターンに使っているので効率が悪いという欠点なども指摘され、RFC6282 IPHC が追加制定されることになりました。IPHC はディスパッチ識別子を 3bit まで縮めて充填効率を上げ(※註)、また状態依存(Stateful)なアドレス圧縮にも対応しています。
※註：とは言っても、それで節約できたのは１バイト未満、たった 5bit に過ぎませんが！
RFC6282 IPHC IPv6 圧縮ヘッダ・ディスパッチ
SAC/DAC ビットがそれぞれ発信元・宛先のアドレス種別を示し、0 の場合は直接表記(Stateless)、1 の場合は間接表記(Stateful)となります。間接表記というのは「例のアレ」みたいな表記で、4bit のコンテキストインデックス値(SCI/DCI)で最大 16 種類の事前共有済みアドレス・プレフィクスを示します(※註)。ディスパッチ中の CID ビットが 1 にセットされた場合、4+4=8bit の SCI/DCI 値が DAM フィールドの直後に付加されますが、CID が 0 の場合は SCI=DCI=0 として解釈されます。IPv6 通信の殆どが「末端ノード(自分自身)」と「サーバ」の２点に集約される場合など、SC[0]=自分自身、DC[0]=サーバというコンテキスト前提を共有すれば、IPv6 ヘッダは最短の 16bit まで圧縮可能ということになります。
※註：RFC6282 ではコンテキストの内容や共有手段について「規定しない(How the contexts are shared and maintained is out of scope)」と明記されていますが、これは RFC6775 で別途定義されています。
SAC/DAC と SAM/DAM の組み合わせは下記のようになります。リンクローカルアドレスあるいは 128bit フルアドレス表記の場合に xAC=0、コンテキストベースでプレフィクスを共有する場合に xAC=1 を使うことになります。xAC=1, xAM=00 の場合の「ゼロアドレス」というのは例外的なマッピングですが、これは ICMPv6 近隣解決で多用されるゼロアドレスを圧縮するためのものでしょう。
xAC=0 後続情報
xAM=00 IPv6 アドレス 128bit
xAM=01 IPv6 アドレス下位 64bit (上位プレフィクス=リンクローカル)
xAM=10 IPv6 アドレス下位 16bit (上位プレフィクス=リンクローカル)
xAM=11 なし (上位=リンクローカル、下位=MAC アドレスから生成)
xAC=1 後続情報
xAM=00 なし (ゼロアドレス, ::)
xAM=01 IPv6 アドレス下位 64bit (上位プレフィクス=コンテキストより引用)
xAM=10 IPv6 アドレス下位 16bit (上位プレフィクス=コンテキストより引用)
xAM=11 なし(上位プレフィクス=コンテキストより引用、下位=MAC アドレスから生成)
この表だけからも伺えるように、RFC6282 はかなり複雑です。可変長ビットフォーマットでないだけマシとはいえ、真面目にコーディングすると if と switch-case が何重にも重なることになりますし、最大効率を発揮するためには用途に合わせたオプション組み合わせの最適化も必要となります。IPv6 の原型 RFC188x が、多少の充填効率よりも実装効率の向上を目指した(※註)のとはまるで対照的なのが面白いですね。
※註：例えば IPv6 の「数珠つなぎヘッダ」は 8 バイト単位長で、余る場合は切り詰めるのではなくゼロ埋めされます。更にヘッダの length フィールドは「0 のとき最短値 8 を指す」という変則的な表記となっており、最小値が 0 なのでヘッダ長のチェックは最大値の判断だけでよく「これで if が一個減らせる」ことが誇られていました。ただしこの変則仕様は ICMPv6 オプション部の長さフィールドには採用されていないばかりか、他のプロトコルにもあまり採用例はありません。どうやら「if が一個減らせる」ことよりも「直観的にわかりやすい」方が歓迎されたようです。これも K.I.S.S の一例でしょうね。
近隣探索(Neighbor Discovery)
通常の LAN や WiFi ではブロードキャストによる近隣探索が実装されますが、802.15.4 においてブロードキャストが忌避されることは前述したとおりです。
実は、IPv6 はもともとブロードキャストをサポートしないネットワーク(NBMA:Non-Broadcast Multiple Access)でも稼動するように設計されていました。NBMA ネットワークではデフォルトルータがノード一覧を把握している前提になっており、ノードはアドレスの近隣解決をデフォルトルーターへのユニキャスト問い合わせで行います(RFC1970 Section 3.2)。
6LoWPAN の近隣探索も基本的には NBMA として実装されます。すなわち 6LoWPAN ノード(6LN) は必ずデフォルトルータを持ち、近隣問い合わせは必ずデフォルトルータに対して行います。6LN がマルチキャストで一斉問い合わせをかけることは明確に禁止(MUST NOT)されています。
ただし RFC4944/RFC6775 とも、IPv6 デフォルトルータと 802.15.4 ネットワークトポロジーの関連については明言していません。単純なスター型接続ならば星の中枢にあたる PAN コーディネイターが IPv6 ルーターとしても働くだろうことはわかるのですが、直列多段の接続を伴うクラスター・ツリーにおいては中継ノード(802.15.4 ルーター)が近隣解決を請け負うのか、それともいちいち PAN コーディネイターまで遡るのかはよくわかりません。
スター型トポロジーの例
FFD(Full Function Device)がピコネット・コーディネイター(赤)となり、その周囲に RFD(Reduced Function Device)が接続される。
クラスター・ツリー・トポロジーの例
２つのピコネットがルーター役の FFD(橙) で接続されており、ピコネット A にはルーターを介した RFD の接続もある。ここで言う「ルーター」は 802.15.4/Zigbee の用語であり、必ずしも 6LoWPAN のルーター(6LR)と同じではないことに注意。
前述した「アドレス短縮コンテキストの共有方法」など 6LoWPAN の特殊な事情に対処するため、RFC6775 では ICMPv6 Neighbor Discovery に幾つかの追加オプションが拡張されています。RFC4944 は既存 IPv6 スタックを 802.15.4 ネットワーク上で動かすための純粋なミドルウェア仕様でしたが、RFC6775 ではこれらのオプションの追加制定によって「6LoWPAN 向けの IPv6 拡張仕様」を定めたともいえます。
Address Registration Option (ARO)
Type=33 の Neighbor Discovery オプション。6LN からの Neighbor Solicitation に付加され、6LR に対し 6LN の生存を知らせる。
6LoWPAN Context Option (6CO)
Type=34 の Neighbor Discovery オプション。6LR から 6LN に通知され、RFC6282 で規定されたコンテキストベースの短縮アドレス表記の共有情報を伝える。
Authoritative Border Router Option (ABRO)
Type=35 の Neighbor Discovery オプション。6LR から 6LN に通知され、上位網への接続を持つ境界ルーター(6LBR:6LoWPAN Border Router)の IP アドレスを知らせる。
メッシュ対応
RFC4944 では「6LoWPAN メッシュヘッダー」が定義されており、メッシュ内における最初の発信元と最終宛先の MAC アドレスをパケットに埋め込むことができます。しかし RFC4944 においては、発信元がどうやって最終宛先の MAC アドレスを知るのか、これを受け取った中間ノードがどうやって次の中継先を選択するのかについては「規定しない」と明記されています。「あくまで基本機構を提供するだけで、それをどう運用するかは実装依存(あるいは追加仕様において明記)とする」というのは RFC4944 の基本姿勢ですね。
RFC4944 メッシュヘッダー：V/F フラグは後続するoriginator(V), final(F) アドレスが 16bit(1) か 64bit(0) かを示す。
RFC6775 では、メッシュ構造をリンクレイヤーに隠して平板ネットワークとして扱う「Mesh-Under」と、メッシュを IPv6 網として扱う「Route-Over」の２モデルがサポートされています。Mesh-Under での経路指定には 6LoWPAN フレームに埋め込んだ RFC4944 メッシュヘッダーが使われ、Router-Over では IPv6 ベースのルーティング機構(例えば RFC6550 RPL)が使われるのだろうと思いますが、RFC6775 ではその辺への明確な言及が無くて歯切れが悪く感じます(RFC6775 には図版も少なく、全体的に不親切な印象を受けます)。
IPv4 と 6LoWPAN
「6LoWPAN の上で IPv4 プロトコルを流す」というのはいかにも本末転倒ですが、理屈としては IPv4 に対応したディスパッチ識別コードを決めれば IPv6/IPv4 を混在させることも可能(※註)です。検索してみると 2008 年に一度 draft-elpro-ipv4-lowpan-00 という提案がなされたようですが、ドラフト 0 版のまま更新もなく失効しており、おそらくは黙殺に近いかたちで葬り去られたようです。
※註：前述のとおり 802.15.4 の MAC には TYPE フィールドが無いので、ディスパッチコードが IPv4/IPv6 の識別子になります。draft-elpro-ipv4-lowpan では 01000100(0x44) を LOWPAN_HC4 ディスパッチとし、+8 ビットのフラグフィールドで後続する IPv4 ヘッダの圧縮規則を定義していました。
WiFi と 6LoWPAN
我々 WiFi 陣営にとって 802.15.4/6LoWPAN は「競合する敵あるいは共存すべき未来」です。6LoWPAN を WiFi 上に実装することも不可能ではありませんが、フレームサイズが大きくバースト転送(フレーム・アグリゲーション)による高速化を身上とする WiFi にとって、たかだか 40 バイト程度のヘッダ長削減やリンク層でのフレーム分割再結合にはほとんど恩恵がありません。その身上により「小細工なしで TCP/IP が稼動する」ことが WiFi の優位のひとつだったのですが、6LoWPAN の登場によって 802.15.4 や Bluetooth LE の上でも IPv6 が通るようになると、おちおち胡坐をかいてもいられなくなってきました。
それは良いことでもあります。かつては Zigbee のプロファイル、Bluetooth のプロファイルと WiFi の TCP/IP は全く相互接続性を持たない別世界だったのが、6LoWPAN によって相互接続可能となり協調動作することも可能になったのですから。工業用には 802.15.4、家庭内には Bluetooth、オフィスでは WiFi という風に、異なる物理層が用途によって使い分けられながら、同じ IPv6 ベースのプロトコルで同じアプリケーションが同じように動くことで共存することになるかも知れません。それはまさに IPv6 が 20 年前に夢見た「次世代インターネットのあるべき姿」なのですが...そう綺麗に住み分けられるものかどうか、(USB やイーサネットがそうだったように)１つの仕様規格が暴力的なまでの数と価格の優位で他を圧倒するのか、それは非常に予測の難しいところです。
まとめ
「21 世紀のインターネット標準」と言われながらも 20 年ものあいだ鳴かず飛ばずだった IPv6 ですが、数億・数十億に達するノードが接続される Internet of Things (IoT) の時代が来る(かもしれない)と言われるようになって、再び脚光を浴びてきた印象があります。しかし IoT の世界ではパケット長 127 バイトの IEEE802.15.4 や 39 バイトの Bluetooth LE に対応することが必要で、「より速く、より効率的に」という思想で設計された IPv6 とは微妙に噛み合わないことになってしまいました。
6LoWPAN はいわば IPv6 が掲げた理想と直面する現実を擦り合わせるものですが、「IP ヘッダの冗長情報を省略してサイズ縮小」なんてかつて低速のシリアル回線でやっていたようなこと(RFC1144 CSLIP, 1990 年)ですし、「フレーム長が短く」「ブロードキャストの無い」アーキテクチャ上に TCP/IP を載せるというのも 53 バイト固定セル長の ISDN ATM 上での仮想 LAN 実装(1992 年頃)を思い出し、「歴史は繰り返す」ものだなぁとしみじみ思います。
こんな泥臭い、いわば「汚い発明」のような 6LoWPAN ですが、IoT の世界では有力候補と見られています。既に述べたように Zigbee IP は 6LoWPAN を採用していますし、Google 社が主導する IoT 向けメッシュ規格の Thread も 6LoWPAN ベースです。またつい先日発表された IPv6 over Bluetooth LE (RFC7688) も 6LoWPAN を採用しており、802.3 非互換の省電力無線通信仕様上に IPv6 を実装する際のデファクト・スタンドードとして 6LoWPAN の地位は(良くも悪くも)確立されたように思えます。
さて、6LoWPAN は IoT 時代を支える屋台骨となるのでしょうか。6LoWPAN を屋台骨として、いよいよ IPv6 が 20 年越しの「次世代インターネット」を実現するのでしょうか？既に何度も述べてきたように、未来予想は甚だ難しいものです。そもそも「数億・数十億のノードが接続される IoT」という未来じたい、本当に来るのかどうかわかりません。それが実現したとしても果たして IPv6/6LoWPAN がその主流となるのか、相も変わらず 10 進 4 桁の IPv4 アドレスを NAPT で継ぎ足して使い続けるのかもわかりません。技術的な利害得失のマトリックスを書くことはできますが、市場は往々にして技術的利害得失以外の要因に強く影響されるものです(※註)。そもそも市場が「技術的利害得失」によって製品仕様を選択するならば、IPv4 なんて 10 年前にはもう絶滅していたはずなのですから(笑)。
※註：「iPhone が標準機能として搭載する」とか「SoftBank が対応機器を無料でばら撒く」とか...そういう意味で、iPhone が無線チップすら搭載していない 802.15.4 は「やや不利」ではありますね。Android や iOS がいつ 6LoWPAN に対応するのか、Apple がどれだけ 6LoWPAN 対応 APP を積極的にサポートするのか(彼等の独自 IoT 規格である HomeKit とはどう共存させるのか？など)もチェックポイントの一つになるでしょう。