IPv6のはなし
IPv6 (IP version 6) については以前にも何度か言及しました。IPv6 の RFC が公開されたのは 1995 年 12 月、今からちょうど 20 年前のことになります。前回は TCP/IP(v4) の華々しい成功の物語でしたが、今回は IPv6 の過去と現状についてのお話です。
IPv6 について
IPv6 はもともと 1990 年代、急速に消費が増大して IPv4 アドレス枯渇が目前に迫っていたインターネットの救済を主目的とした「IPng(IP Next Generation)」プロジェクトとして開発されたものです。作業は急ピッチで進められ、1995 年 12 月に RFC1883～RFC1887 の５本セットとして最初の IPv6 仕様が公開されました。
IPv6 は基本的に、IPv4 では 32bit 幅だったアドレスを 128bit(※註) に拡大した仕様として制定されました。上位層の TCP や UDP にはほとんど変更がなく、ルーティングや論理・物理アドレス連携(IPv4 における ARP)も実装が IPv6 対応になっただけで、基本動作の概念は IPv4 からそのまま受け継がれています。これついてはより先進的なモデルを取り入れるべきとする一派との間で激論があったそうですが、2000 年頃には枯渇すると予想されていた IPv4 アドレスに対する危機感から、あえて新規要素を排し「現状 IPv4 で問題のないところは弄らない」という方針で仕様制定された経緯があります。この方針について私は当時も今も高く評価しています。
※註：初期の IPng 案では 64bit でしたが、それでも枯渇するかも知れないとの懸念を受けて「これなら文句ないだろう」とばかりに 128bit に拡大された経緯があります。一方では可変長アドレスを支持する声も小さくはなく、特に OSI プロトコルの NSAP アドレス(最小 64bit～最大 160bit)支持派との間には激闘があったようです。
IPv6 と IPv4 の互換性
一方、IPv4 と IPv6 には直接互換性がありません。IPv4 と IPv6 が同じなのは「動作原理の概念」だけで、パケットヘッダの構造は全く異なりますし、イーサネット上で付加されるプロトコル番号も異なります。
IPv4 のヘッダ構造
最小構成で5x32bit=20バイト。
追加オプションはDestination Addressの後に付加され、それを含めたヘッダ全長がIHLフィールドに記される。
イーサネット上の識別コードは0x0800。
IPv6 のヘッダ構造
最小構成で10x32bit=40バイト。
追加オプションは独特な「数珠つなぎ」構造で結合され、ヘッダ長は固定。
イーサネット上の識別コードは0x86dd。
これにも激論があって、拡張アドレスを IPv4 の拡張ヘッダ部分に「隠す」ことで移行期間中は IPv4 との直接互換性を持たせる提案もあったようですが、この案は退けられました。移行期間が終わったあとも何十年、ひょっとすると何百年も使い続けることになるかも知れない「次世代 IP」に、IPv4 互換領域が盲腸のように延々と残り続けることが「美しくない」という判断だったようです。
IPv4/v6 ハイブリッドヘッダ案
IPv4のオプション領域に128bitアドレス２つ＋αを格納した例。
この例ではヘッダ長14x32bit=56バイト。
イーサネット上の識別コードはIPv4と同じ0x0800。
直接互換性をあえて排したのは、IPng 委員会の「どこかの時点で IPv4 はすっぱりと切り捨て、新アーキテクチャへ完全移行する」という意思表明のようなものでもありました。この「直接互換性の欠如」こそ IPv6 の普及が進まなかった根本原因として挙げる人もいますが、私には何とも言えません。仮に IPv4/v6 アドレスが相乗りするハイブリッドフォーマットを採用していても、結局 IPv6 フィールドは「将来拡張予定」として 0x00 のまま使われ続けてしまったかも知れません。
(わかりにくい)互換アドレス
IPv4/IPv6 の互換性および移行期間対策については、IPv4 の 32bit アドレスを IPv6 の 128bit 幅の中に取り込む「IPv4 互換アドレス」と「IPv4 射影アドレス」の２つが定義されました。しかしこの２つはいずれも名前から想像される「IPv4 機器と IPv6 機器の通信」を実現はしてくれません。「IPv4 互換アドレス」とは、IPv6 機器が IPv4 網を「トンネリング」して IPv6 同士で通信するとき、通過する IPv4 網のアドレスを便宜的に表記するためのもので、IPv4 機器と IPv6 機器が通信できるという意味ではありません。「射影アドレス」というのは IPv6 アドレスの文法で IPv4 アドレスを既述できる...「192.168.0.1」と書く代わりに「::ffff.192.168.0.1」と書けるという表記上の方便であって、実際にネットワークへ出て行くパケットは純粋な IPv4 フォーマットです。
もし IETF の目論見通りに IPv6 専用機器が普及してインターネットを置き換えていたならば、IPv4 専用機器はネットワークにつながらなくなっていたでしょう。幸か不幸かそれは 2015 年現在に至ってもいまだそうはなっていないわけですが、もし仮にそうなっていたとしても、「IPv4 互換アドレス」や「IPv4 射影アドレス」は古い IPv4 専用機器の救済策にはなってくれません。そのような機材はプロトコル変換器(トランスレータ)と呼ばれますが、IETF ではトランスレータの仕様は制定していません。
弊社ではひょっとしたらそんな需要が出るかもしれないと「SX-2600CV」という IPv4-IPv6 トランスレータを開発しましたが、そもそも「IPv6 専用ネットワークが台頭して IPv4 専用機器が困ってしまう」という事態が来ませんでした。
失われた１０年
ともあれ、IP アドレスの枯渇からネットを救う救世主として 1995 年 12 月に登場した IPv6 でしたが、その実装は遅れました。当初は BSD 系 Unix 上で稼動する KAME project が事実上のリファレンスとして先行し、当時台頭していた Linux 上の USAGI project は KAME よりやや遅れていて機能も貧弱でした。そして何より、当時圧倒的なシェアを誇っていた Microsoft Windows はやっと TCP/IP(v4) を標準実装した Windows95 がリリースされたばかり(※註)でした。Windows に IPv6 が機能制限付きのオプションとして曲りなりにも実装されるのは Windows XP (2001 年)、フルセットの IPv6 が標準実装されるのは Windows Vista (2006 年)と遅れます。
※註：Windows 3.1 までは NetBIOS しかサポートしておらず、TCP/IP 網＝インターネットに接続するためにはサードパーティー製の TCP/IP プロトコルスタックを購入してインストールする必要がありました。今ではもう信じられない話ですね。
IPv6 最初のつまづきは、この Microsoft Windows の対応遅れにあったと言っても良いと思います。95 年末に仕様がリリースされてから製品に標準実装するまで 10 年もかかったというのは、Microsoft には IPv6 を真面目に推進する気があったとは思えません。彼等には彼等なりの事情があったのでしょうが、Windows が対応しないものだからプロバイダーも周辺機器メーカーも右にならえの格好で IPv6 対応を見送り、IPv6 が話題として最も勢いのあった 10 年間をほとんど空費してしまいました。
この「失われた 10 年」は IPv6 にとって致命的でした。この 10 年の間に「ブロードバンド」が普及し、家庭内にルーターやイーサネットや WiFi が入ってきました。それらには全て IP アドレスが付いています。こうなる事はそもそも想定されていて、そうなったら IPv4 では足りないということで開発されたのが IPv6 だったのに、実際に「そうなった」ときに肝心の IPv6 普及は間に合っておらず、当座しのぎで入ってきた IPv4 の NAT/NAPT が定着してしまったのです。Windows Vista がやっと IPv6 対応した 2006 年、「じゃあ明日から IPv4 を使うのを止めよう」と思った人は何人いたでしょう？少なくとも私は「今更 IPv6 対応と言われてもなぁ...」と思いました。遅い、遅すぎる、あと 5 年は早く対応すべきだった、と。
IETF の対応とその余波
IETF はこの遅延を指を咥えて眺めていたわけではありません。しかしこの遅延は脅威ではなく、むしろ拙速ぎみに制定された RFC1883～RFC1887 を見直す好機と捉えられたようです。1997 年から 2000 年頃にかけて、RFC2000～3000 番台の IPv6 RFC が矢継ぎ早に...「朝令暮改」という言葉を思わせるペースで発表されました。Priority フィールドが Traffic Class フィールドに変わり、リンクローカルアドレスの分割規則が変わり、サイトローカル・アドレスはその解釈について二転三転したあと廃止されました。その一方ではモバイル・アドレスやテンポラリ・アドレスなど新しい種類のアドレスが幾つも提案され、それをまとめて管理すべく RFC 屈指の怪文書 RFC3484 Default Address Selection が制定されました。かつて「デフォルトルータに投げさえすれば自動解決する」と簡素さが誇られていたルーティングにも、RFC4191 で Preference 値が追加設定されました。
メジャーな OS(Windows) への実装が遅れ普及が遅々として進まないなか、「もし○○のような事態が起こったら」という机上の可能性についての議論とその対策が次々に RFC 化されてゆき、かつて RFC1883 時代には「シンプルで合理的」を誇られた IPv6 の仕様は、オプションと MUST と SHOULD と SHOULD NOT と MUST NOT の規制事項でがんじがらめに縛られた複雑怪奇なものに肥大化していました。そして、この相次ぐ仕様改定の時期を代表するような機能が IPsec と DHCPv6 でした。
「IPv6 ではセキュリティ機能が標準で付いてくる」という話を聞いたことはないでしょうか。これも IPng プロジェクトで激論となったところ...「次世代インターネットの基盤仕様にセキュリティが標準搭載でなくてどうする！」「いやそれは時期尚早だ！」という激論の果てに、「最低限のセキュリティ機能を標準実装とする」という合意で認証ヘッダ AH と暗号化ヘッダ ESP を「IPv6 全機能」のうちに含めることになったものです。しかし結局、これは事実上の空手形となりました。これにも様々な事情...当初選定した DES 暗号に対する米政府の規制、規制解除後 DES 暗号の急速な陳腐化、IPsec 特に ESP 仕様の矢継ぎ早の改訂、鍵交換プロトコル標準化の混迷など...があり、何が悪かったと「戦犯」を指せるほど単純ではありません。しかし、仕様公表される→実装が遅れる→その間に IPsec 仕様が改訂されたり新暗号アルゴリズムが発表される→どうせ実装は遅れているのだから、と改訂した仕様が公表される→ますます実装が遅延するという、IPv6 の遅延スパイラルに嵌ってしまったと思います。
もう一つは DHCPv6、当初は「Stateful Autoconfiguration」と呼ばれていた機能でした。IPv6 ではプラグ＆プレイ性...ケーブルを挿すだけでネットワークに必要な設定情報はなるべく自動的に取得できることが考慮されており、IPv6 アドレスとルーティング情報については Neighbor Discovery / Router Discovery という自動設定手順が IPv6 の基幹仕様レベルで規定され実装必須になっています。これらをまとめて Stateless Autoconfiguraiton と呼ぶのですが、より柔軟できめ細かな設定のできる設定プロトコルも必要であろうとされ、UDP ベースで稼動する DHCP の IPv6 版「DHCPv6」が Stateful Autoconfiguration として定義され、これも実装必須と位置付けられたのです。
しかし DHCPv6 の制定は延々と遅れました。DHCPv6 最初の仕様、RFC3315 が公表されたのは 2003 年 7 月...IPv6 の公表から実に 8 年近い歳月が経っていました。IPv4 で出来ていることを IPv6 に持って行くだけの作業に何故そんなにかかったのでしょう？それは RFC3315 がテキストフォーマットで 200KByte を超え、行数では 4000 行を超えるという事実から察して頂けるかと思います。DHCPv6 は「がんばりすぎた」プロトコルでした。あらゆる事態状況に対応できる多種多様のオプションを備え、それを誤解を許さぬ厳密な既述で仕様表記しようとした代物でした。私は DHCPv6 の真髄は、18.1.3 にあるこの一文に象徴されると思っています。
The client includes IA Address options in the IA option for the addresses associated with the IA.
...何なんでしょう、これ。よほど当たり前のことを物凄く難しく書いてあるのか、それとも物凄く重要なことを意味不明直前になるまで削ぎ落してあるのか。とにかく RFC3315 は全文通してこの調子で、「期限付きのアドレス(複数)を付与する」というだけの、IPv4 の DHCP では数十年の実績をもって稼動している機能をこれだけ難しく考え直せるということに私は驚き、呆れ、そして絶望しました。要するに「ダメだこりゃ」と。1995 年に「インターネットの未来」を真剣に案じ、意地や体面を捨てて現実的な仕様を制定しようとした IPv6 の開拓精神はもはや失われていると。開発現場から離れた象牙の塔で「完璧な仕様書」を書くことが目的になってしまっていると。
TACA project の顛末
2000 年前後、いよいよ IPv6 が本格的に普及すると考えられていた頃、日本の製造業とくに家電メーカーは IPv6 による「インターネット家電」の未来を夢見ていました。しかしまだ ARM Cortex-M のような超廉価 32bit MCU が実用化されていなかった当時、8bit や 16bit の MCU には IPv6 を実装すること自体がかなり大変で、しかも「本家」の IPv6 関連 RFC は前述のように肥大化・複雑化への坂道を転がり続けており、8bit や 16bit で IETF の並べた MUST, MUST NOT, SHOULD, SHOULD NOT の羅列を全て満たすことは非常に困難でした。
そこで、2001 年に日本の家電メーカーが中心になって発足した「軽量 IPv6 仕様」の提案が TACA project です。TACA とは Tiny software and system Architecture for non-Computer Appliances の略ですが、当時 KAME, USAGI, TAHI など動物名を付けていた日本の IPv6 関連プロジェクトの慣例にならった語呂合わせです。LCNA (Low Cost Network Appliance) とも呼ばれ、むしろ海外には LCNA の名のほうが知られていたようです。
私もそのころ自前の IPv6 スタックを実装しており、RFC が更新されるたび思いついたように増える SHOULD や SHOULD NOT、その一言一句を守るためだけに増える構造体フラグや if に辟易していましたから、「日本初」の「実用的」な実装仕様提案である TACA project には期待していました。IPv6 のリファレンス実装系 KAME や IPv6 仕様適合検査システム TAHI の成功は輝かしく、日本がいよいよネットワーク仕様標準の発信者になってゆくと思ったものです。
しかし、TACA が直面した現実は厳しいものでした。議事録から伝わってきたのは IETF の強烈な拒絶。RFC で見慣れた錚々たる面々からの批判と質問の嵐。「俺達がこんなに一生懸命になって完全完璧な次世代ネットワーク仕様を築きつつあるのに、何故お前らはこんな不完全な代物を押しつけようとするんだ？」という声なき声を感じました。いや、その「一生懸命になって完全完璧な仕様」を作ろうとする努力こそ、現場のエンジニアにとっては有難迷惑・余計なお世話、IPv6 が本当に実装されて本当に稼動する製品が世に出る障害になっているんですけど！？TACA project はそのジレンマに直面した現場からの提案なんですけど？かつて RFC ナンバーが三桁だったとき、貴方がたは「現場でコードを書いているエンジニアが意見を交換する」場として RFC を使ってきたのではないのですか？トップダウン方式の OSI 仕様制定の経緯をあれだけ批判していたじゃないですか？IETF や RFC は、あれだけ批判していた OSI の同じ轍を爆走しているんじゃないんですか！？
私はネットを通して傍観していた立場で TACA の会合に直接参加したこともなく、TACA の推進メンバーが同じように思ったかどうかはわかりません。しかし現実として、TACA project は急速に勢いを失ってしまいます。結局 TACA が提案したドラフトはどれ一つとして Standard Track に乗ることはなく、TACA/LCNA プロジェクトはわずか２年弱で活動を終了しました。
その後の IPv6
IPv6 は死に絶えてはいません。いまや大抵の OS には標準実装されていますし、プロバイダの多くはいつでも IPv6 が供給できる体制を持っている、とも言われます。「次世代インターネット標準」の掛け声ばかり高くて実装がぜんぜん追いついていなかった 2000 年頃に比べれば、はるかに充実し普及しているとも言えます。にも関わらず、IPv6 が「使われている」という実感はありません。「IP アドレス」と言えばいまだに１０進４桁の IPv4 アドレスを指しますし、コンシューマー向けの低価格ルーターの多くは今でも IPv4 専用です。納品物件でも IPv6 対応は「将来の対応を考慮する」という仕様書上の一文で済まされ、実際には実装されずに終わることが多いです。一体どうしてこうなった？...というのを、私が IPv6 に未来を見ていた 90 年代末～2000 年代初めを思い出して書いたのが今回のコラムです。
IPv6 が死に絶えていないのと同様、IPv4 のアドレス枯渇問題も解決はしていません。末端は NAT で誤魔化しても大域網の接続点にはグローバルアドレスが必要で、それは確実に枯渇へと向かっています。2011 年の春にはアジア太平洋地域のアドレス在庫が無くなり、新規のアドレス付与ができなくなりました。大量に在庫を持っていた米国も IPv4 アドレス枯渇は遠くないと言われています。割り当てられているけど使われていない「休眠アドレス」の発掘と再利用、アドレス空間の再分割と再配布など涙ぐましい努力が進められていますが、空になったオイル缶をひっくり返して滴を集めるようなもので、回収可能なアドレスは多寡が知れています。それも尽きたならばあとは IPv6 に切り替えるか、それとも IETF のセンセイがたが真っ赤になって激怒しそうな方法...NAT ルーターを基幹網に取り込むしかありません。
IPv6 への移行は機材の互換性やノウハウの欠如でコストが見積もりにくく、重い腰が上がらないとも言われています。ふーん...「ノウハウの欠如」ですか。IPv6 RFC が公表された 95 年の暮れから 20 年間、我々は一体何をやってきたんでしょうね。まだ先だ、今は忙しいと言って問題を先延ばしにしつつ、1999 年の半ばを過ぎてから「どうしよう、どうしよう」と右往左往しはじめた Y2K 騒動を思い出さずにはいられません。人間は意外と、同じ過ちを何度も繰り返す生き物のようです。
昨今は「IoT(Internet of Things)」だの「IoE(Internet of Everything)」という話題が騒がしく、体重計やらエアコンやら炊飯器などの「モノ」がインターネットにつながるのだと言われ、億の桁に達する新ノードがインターネットに接続されると言われています。IoT 接続プロトコルには 20 を超えるものが各社から提案されていますが、その多くは爆発的なアドレスの増加を見据えて IPv6 をベースにしています(※註)。IoT/IoE は IPv6 とともに「新しい時代のネットワーク」を築くのでしょうか。それとも IoT/IoE という言葉じたい、世間を騒がせたバズワードとして終わってしまうのでしょうか。あれだけ期待され、あれだけ成功確実と思われていた IPv6 の経緯を見てきた身には、未来を予測することの不確実さがつくづく身に沁みます。
※註：ただし提案されている殆どの IoT/IoE 仕様では、セキュリティを TLS/SSL で実装するとしています。これが前述した「IPv6 で IPsec セキュリティが標準実装されるという話は事実上の空手形」です。