IPv6 over Bluetooth のはなし
前回に引き続き Bluetooth の話です。今回は IP over Bluetooth の過去と現在、そして実際に使ってみた結果について解説します。
もともと Bluetooth は携帯電話にアクセサリ(主にヘッドセット)を接続するための簡易無線プロトコルとして開発されました。開発当時には TCP/IP を流すことなど殆ど考えていなかったと思われますが、圧倒的ともいえるインターネットの普及により、Bluetooth でも IP を扱うことが求められてきました。その最新の試みが Bluetooth 4.1LE 以降の IP Support Profile ですが、Bluetooth Classic でも過去何度か試みられてきました。まずはこれら「過去の IP over Bluetooth」について軽く触れてみます。
LAN Access Profile (LAP)
最初の「IP over Bluetooth」の試みである LAN Access Profile (2001 年 2 月) は携帯電話を無線モデムとして扱い、PC と携帯電話間を接続する目的で制定されました。仮想シリアルポートである RFCOMM の上にダイヤルアップ接続プロトコルの PPP を乗せてあります。LAP は IP over Bluetooth とはいっても子機～親機間の 1:1 接続しかできず、ダイヤルアップ PPP ベースというのも既にブロードバンド時代に入りつつあった 2001 年には古臭く思えました。かくして LAP はあまり使われることのないまま、2003 年 6 月に早くも廃止宣言 (Deprecated) されました。
PAN Profile (PAN)
PAN Profile は LAP を置換すべく 2003 年 2 月に制定されたプロファイルです。2 点間の接続しか考えていなかった LAP と異なり多点接続が可能で、また Bluetooth Network Encapsulation Protocol (BNEP) というカプセルフォーマットを採用することにより IP 以外のフレームタイプも通せる仕様になっていました。これはおそらく、当時まだしぶとく生き残っていた「Windows ファイル共有」の NetBEUI を意識したものでしょう。
PAN Profile には Network Access Point (NAP) モード、Group adhoc Network (GN) モード、PANU-PANU モードという３つの接続形態がありました。NAP と AdHoc モードは中枢を持つスター型、PANU-PANU モードは２点間の直接リンクです。PANU というのは PAN User の略で末端ノードを指し、一方中枢ノードは NAP あるいは GN と呼ばれます。この時点で「何かイヤだな」と思いますね。
PAN profile NAPモード。
NAP役のノードが子機(PANU)間の通信およびアップリンクへの中継を受け持つ。
PAN profile GNモード。
NAPモードとそっくりだが、アップリンクを持たない閉じたネットワーク。
PAN profile PANU-PANUモード。
1:1のピア接続。同時接続が１本に限られる場合もある。
１台のノードが複数PANU接続を持てる場合も中継は行わない。
案の定というか、この３つのモードのうちどれを実装するのか、それぞれをどういう名称で呼ぶのかが OS によって異なる結果となりました。例えば Windows では GN と PANU を「Direct Connections」NAP を「Access Points」と呼ぶけれど、Mac OS X では NAP と GN が「Bluetooth PAN」として一緒にされ PANU は表示されません。一方 Linux の BlueZ では BlueZ 3.x 時代に pand というデーモンプログラム/コマンドインターフェースが実装されたもののの、BlueZ 4.x 以降では pand の一部の機能のみ(中途半端に)サポートされ、正式の PAN 機能は DBUS API となって shell からのコマンドライン操作では殆ど操作不能になりました。しかも例によって不親切無愛想な BlueZ にはその辺のドキュメントが一切なく、ネット上の解説も玉石混交でえらく苦労させられました。
当時は Microsoft 社が Windows ドライバを IP 上で動かす WSDAPI (Web Services on Devices API) 構想を進めていたこともあり「PAN Profile は Bluetooth 普及の起爆剤になる」などとも報道されましたが、WSDAPI が早々に放棄されたこともあって「来なかった未来」になりました。PAN Profile は LAP に代わって携帯電話のテザリング用に実装されもしましたが、スマートフォンが内蔵 WiFi チップをアクセスポイントとして動作させる SoftAP/Hotspot モードをサポートするようになると、速度でも利便性でも劣る Bluetooth PAN は殆ど顧みられなくなりました。まだ「廃れてはいない」(Deprecated 宣言はされていない)というものの、PAN Profile が 2003 年の初版 1.0 以来一度も更新されていない事実がその利用度合いを暗示しています。
IP Support Profile (IPSP)
さて今回の主役 IPSP です。LAP も PAN も Bluetooth Classic を対象としたプロファイルでしたが、IPSP は Bluetooth LE を対象とした IP プロファイルです。Bluetooth SIG からの IPSP 仕様リリースは 2014 年 12 月でしたがこれだけでは不完全で、詳細な実装仕様については IETF から RFC7688 IPv6 over Bluetooth (2015 年 10 月)がリリースされるのを待つ必要がありました。
トポロジが３種類もあった PAN に対し、IPSP/RFC7688 (以降単に IPSP) はスター型トポロジだけをサポートします。中枢ノードは Router Role (RFC7688 では Central)、末端ノードは Node Role (RFC7688 では Peripheral) と呼ばれ、PANU とか GN とかの電話屋めいた略語(※註)は無くなりました。現実的には PC やスマートフォンが Router Role となり、周辺デバイスを Node Role として接続する運用になるでしょう。
※註：電話系の標準規格は英単語を避けてやたらと大文字略語を多用する傾向がありましたが、これは現在の ITU-T、かつての CCITT (Comite Consultatif International Telegraphique et Telephonique) 本部がフランスにあったことと無関係ではないように思います。
IPSP は 6LoWPAN フレームワークを採用しています。イーサネットフレームなら一応何でも通せた PAN の BNEP と異なり、IPSP では IPv6 しか通りません。いまさら NetBEUI でもないという事でしょうが、IPv4 も通らないということは注意しておく必要があります。
IPSP では Bluetooth 4.1 で拡張された LE L2CAP チャネル(正式呼称は「LE Connection Oriented Channels / LE Credit Based Flow Control Mode」)を使用します。つまり 4.0LE 仕様の Bluetooth プロトコルスタックでは動作しません(※註)。L2CAP 上の識別コード PSM (Protocol/Service Multiplexer) は LE_PSM_IPSP (0x0023=35) として定義されています。
※註：ただしリンク層(Bluetooth チップ／ドングル)の変更はないため、プロトコルスタックさえ更新すればチップは 4.0LE 仕様でも動作します.
IPSP のノード接続は接続対象の検索(ディスカバリ)、リンク確立(ペアリング)、L2CAP チャネル開設という手順を踏みます。ディスカバリでは Bluetooth の GAP/GATT 手順が使われ、GATT のサービス属性に IP Support Service (IPSS) UUID16=0x1820 を含むことによって IPSP サポートの有無がわかります。IPSP を見ると基本的にノード側が IPSS のサポートをアドバータイズフレームの AD フィールド(Core Spec 4.2 Vol.3 Part.C Section.11)に含めて送信し、これを検出したルータ側は自動的にノードに接続に行くことが想定されているようです(IPSP Section 6.2)。
リンク確立後は L2CAP のチャネル開設手順が行われますが、これは必ずルータ側から発行することになっています。もしルータがノードロールも兼ねていた場合はピコネット層のリンクマスター側がチャネル開設を行うこととされ、リンクマスターは IPSP PSM への L2CAP チャネル開設要求を拒否することと定義されています(IPSP Section 6)。
さてペアリングが確立し L2CAP のチャネルが開設すれば 6LoWPAN のリンクは確立したわけで、あとはただ通信するだけのはずですが、ここにひとつ落とし穴があります。IPSP においてルータ・ノード間のリンクは一本のスイッチ・バスではなく独立したリンクの集合として定義されており、リンクローカル・アドレスを用いた通信は単リンク間(ルータ・ノード間)で行き止まりで、ルータを経由したノード間で通信することはできません(RFC7668 3.2.1)。たとえアップリンクを持たない孤立ネットワークであっても、ノード間で通信するためには大域 IPv6 アドレスの付与が必要になります(※註)。
※註：IPv6 仕様の制定時には「こんなこともあろうか」とサブネットを切れるサイトローカルアドレスが定義されていたのに、すったもんだの末に廃止された話は「6LoWPAN のはなし」の時にも紹介しました。
IPv6 の静的自動アドレス設定(Stateless Auto Configuration)では通常、アドレス上位はルータから与えられたプレフィクス、アドレス下位には自身の MAC アドレス(EUI-64)を付与します。しかし RFC7668 では MAC アドレスの埋め込みを禁止(SHOULD NOT)しており、RFC3972, RFC4941, RFC5535, RFC7217 などの疑似乱数アドレス、あるいは DHCPv6(RFC3315) などを使うべしと既定しています。アドレス追跡や DOS 攻撃に対するセキュリティ懸念だとは思いますが、異なる規格を５つも並べて「など」と書くあたり、IETF の悪い病気の気配を感じますね。
「Bluetooth のセキュリティのはなし」でも触れたように、Bluetooth LE の「MAC アドレス」には Public Address, Static Random Address, Non-Resolvable Private Address, Resolvable Private Address という(紛らわしい)４種類があり、そのどれが使用可能なのか、それを使用すべきなのかは実装と設定によって異なります。RFC7668 では「6LN and a 6LBR are RECOMMENDED to use private Bluetooth device addresses」としていますが(3.2.2)、要するに乱数生成された MAC アドレスから更に乱数化した IPv6 静的アドレスを作るということで、はっきり言って「何がしたいねん」と思います。WEP の脆弱性騒動以来、無線規格はセキュリティ仕様に対して過敏になっている気配がありますが、ただでさえ新しい規格仕様で相互接続性が怪しいところに「～などを使うべし」という選択肢を複数入れるあたり、これまた IETF の悪い持病のように思えます。
IPSP を動作させてみる
Linux ではカーネルオプション CONFIG_BT_6LOWPAN で IPSP の実装がサポートされます。カーネルバージョン 3.15 あたりから付いているようですがカーネル 4.4 でもまだ暫定実装で、debugfs を介しての操作しかできません。ペアリングや GATT アドバータイズとの連携も入っていないようです。
とりあえず古いデスクトップ PC ２台に Ubuntu 14.04LTS をインストールして IPv6 over Bluetooth を動作させてみました。Ubuntu 14 を使ったのは「たまたま DVD を焼いてあった」という程度の理由です。また Ubuntu 14.04 のデフォルトカーネル 4.2.0 では bluetooth_6lowpan は動作せず(※註)、試行錯誤のすえカーネル 4.4.0 にアップグレードして動作確認しました。
※註：L2CAP の接続までは行われるのですが、十数秒考え込んだ挙句に切断してしまいます。
接続要求発行(マスター)側
# modprobe bluetooth_6lowpan
# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable (※註)
# hciconfig hci0 leadv
接続要求受理(スレーブ)側
# modprobe bluetooth_6lowpan
# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable (※註)
# echo 'connect 00:02:72:DB:EE:E9 1' > /sys/kernel/debug/bluetooth/6lowpan_control
※註：3.19 などの古いカーネルでは 6lowpan_enable が無く 6lowpan_psm というエンドポイントになっており、echo 35 > /sys/kernel/debug/bluetooth/6lowpan_psm で 6LoWPAN 機能を ON にします。
bluetooth_6lowpan が接続完了すると bt0 というインターフェースが作成されます。ifconfig で確認できます。
# ifconfig (接続要求発行側、00:1B:DC:06:A8:8F)
bt0 Link encap:UNSPEC HWaddr 00-1B-DC-FF-FE-06-A8-8F-00-00-00-00-00-00-00-00
inet6 addr: fe80::21b:dcff:fe06:a88f/64 Scope:Link
UP POINTOPOINT RUNNING MULTICAST MTU:1280 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:265 (265.0 B) TX bytes:265 (265.0 B)
# ifconfig (接続要求受理側、00:02:72:DB:EE:E9)
bt0 Link encap:UNSPEC HWaddr 00-02-72-FF-FE-DB-EE-E9-00-00-00-00-00-00-00-00
inet6 addr: fe80::202:72ff:fedb:eee9/64 Scope:Link
UP POINTOPOINT RUNNING MULTICAST MTU:1280 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:293 (293.0 B) TX bytes:293 (293.0 B)
通信が通っているかどうかは ping6 で確認できます。
# ping6 fe80::202:72ff:fedb:eee9%bt0
PING fe80::202:72ff:fedb:eee9%bt0(fe80::202:72ff:fedb:eee9) 56 data bytes
64 bytes from fe80::202:72ff:fedb:eee9: icmp_seq=1 ttl=64 time=145 ms
64 bytes from fe80::202:72ff:fedb:eee9: icmp_seq=2 ttl=64 time=124 ms
64 bytes from fe80::202:72ff:fedb:eee9: icmp_seq=3 ttl=64 time=169 ms
64 bytes from fe80::202:72ff:fedb:eee9: icmp_seq=4 ttl=64 time=152 ms
試しに iperf を動かしてみると、まぁ当たり前ですが遅いです。TCP モードで 10Kbit/sec 弱しか出ません。もっとも素の LE L2CAP でベンチマークをかけても 1.2KByte/sec くらいしか出ないので「6LoWPAN だから遅い」わけでもなく、そもそも 4.2 拡張以前の 39 バイト LE パケットのスループットがこの程度なのでしょう。
hcidump で見るとデータ長 64 バイトの ping6 が 27+27+22 バイトの３パケットに分割されており合計 76 バイト、すなわち IPv6 ヘッダ長は 12 バイトまで圧縮されているようです。ヘッダの中身までは見ていないので、ヘッダ圧縮形式が HC1 なのか IPHC なのかは確認していません。IPHC でもコンテキスト共有と SCI/DCI の最適化ができないかぎり、ヘッダ圧縮効率は HC1 と大差ないでしょう。
# iperf -V -c fe80::202:72ff:fedb:eee9%bt0
------------------------------------------------------------
Client connecting to fe80::202:72ff:fedb:eee9%bt0, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local fe80::21b:dcff:fe06:a88f port 50836 connected with fe80::202:72ff:fedb:eee9 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-226.1 sec 256 KBytes 9.28 Kbits/sec
#
Linux 上の 6LoWPAN は比較的新しい実装でまだ問題を多く残しているらしく、ちょっと負荷をかけると突然音信不通になって ping も通らなくなったりします。そのへんはいずれ改善されるとしても、このスループットで使い物になるのかどうかかなり疑問に思います。
そもそも「木に竹を接ぐ」ような真似をしてまで Bluetooth LE 上に IPv6 を通すのは、「HTTP/TLS のような標準プロトコルを動かしてクラウド接続したいから」ではないのでしょうか？それが至近距離でもスループット 10Kbps 程度ということは、2KByte 程度の X.509 証明書を介する HTTP/TLS 接続ではトランザクションあたり数秒かかる計算になります。起床時間をミリ秒単位に切り詰めて消費電力を節約したいバッテリ駆動の IoT 機器として「それは無いんじゃない？」と思います。
ペイロード長の短い UDP パケットを片方向で送るような用途なら別でしょうが、いまどき広域 IP 網で通信するなら暗号化と認証は必須です。通信時間と演算量(≒消費電力)を要する暗号化や認証の機能を常時通電のアップリンク・ルータ側に実装することもできますが、ならばローカル網のプロトコルは GATT でも何でも良く、末端ノードまで IPv6 にする意味はあるのだろうかと思います。
Bluetooth SIG もそう思ったのか、Bluetooth 4.2 では LE パケット拡張でペイロードサイズが 39 バイトから 257 バイトに拡張され(SIG のプレゼンによればスループット 2.5 倍)、Bluetooth 5 では 2Mbp LE PHY で更にもうひと押しが入ります。とはいえこれらの機能はルーター・ノード両側のチップが新仕様 Bluetooth に対応していなければ使えませんし、たとえ Bluetooth 5 同士でもせいぜい 5 倍、10Kbps が 50Kbps になる程度です。「Bluetooth LE 上にも IPv6 が通るようになる」からといって、Ethernet や WiFi 上で動作している HTTP/TLS や SSH が Bluetooth LE 上でも同じようにスイスイ動くわけではない(「一応動く」「動かないわけじゃない」「だけど通信時間と消費電力は？」)と考えておいたほうがよさそうです。
まとめ
「6LoWPAN のはなし」の時には「異なる物理層が用途によって使い分けられながら、同じ IPv6 ベースのプロトコルで同じアプリケーションが同じように動くことで共存することになるかも知れません」と書きましたが、少なくとも 1Mbps 39 バイトフレームの LE 上で 6LoWPAN を使ってみたかぎり、現実はなかなか厳しそうです。250Kbps 127 バイトフレームの 802.15.4 でも実情は似たようなものではないでしょうか。
Bluetooth LE や 802.15.4 は低価格・低消費電力を主目的に開発された無線規格なので「スループットが出ない」のは当たり前です。しかしインターネットの IPv6 や HTTP や TLS は消費電力のことなど殆ど無頓着に開発されてきた経緯があり、その「理想と現実をすり合わせる」ミドルウェアが 6LoWPAN なのですが、実際に使ってみると「IPv6 が通ります」だけではギャップは埋められないと感じます。セキュリティ機能を何処に持たせるのか(リンク層のみ？IPsec?TLS？アプリケーションレベル?)、6LoWPAN IPHC の SCI/DCI 最適化は誰がどのように設計し設定するのかなど、システムレベルでの最適化(≒妥協)を行わなければ消費電力と実用性の両立はできないでしょう。「ping6 が通るんだから、IPv6 なら何だって同じように動くはずだろ！」という乱暴な原則論ではろくな結果にならないと思います。それは 6LoWPAN に限らず、どんなコンピュータシステムでも同じことですけどね。