IPv8 Internet-Draftが面白い理由 — 技術的には微妙なのに、なぜこんなに刺さるのか —

最近、IETFに投稿された「IPv8」というInternet-Draftが少し話題になっている。

これについていろいろな記事も出てきてるので、私も思ったことを吐き出しておく。

このドキュメントはどういうものか？

インターネットで使われるプロトコルは、IETFでRFCという形で標準化されるんだけど、そのRFCになる前の下書きのようなものが、Internet-Draft。
これは誰でも書けるし、査読もないし、更新しないと6ヶ月で消えるし、未完成でもOK。
Internet-Draftを元に議論を重ね、Working Group Draft を作成して、レビューを重ねた結果、RFCが発行される。
このドキュメントは Internet-Draft で、個人がアイディアとして投稿したものなので、このプロトコルが実際に使われるようになるかというと、正直微妙。
多分6ヶ月で消えちゃうんじゃないかなあ。

問題意識には共感できる

現状のインターネットの問題についていくつか指摘してて、これは事実だし、共感できるところも多い。

• IPv6の普及の遅れ

• デュアルスタック、NAT、セキュリティ等に起因する運用の複雑さ

そしてそれらを解決するための方向性もまあ理解できる。

• IPv4と完全互換

• シンプル化

• セキュリティ強化

• 運用統合

• スケーラビリティを考慮

ただ技術的には無理がある

これは面白いのでは？、と思って読んでみたんだけど、技術的には甘いところが多すぎるな。

• IPv4と完全互換、と言いつつ全然そんなことはない

• 機能を詰めこみすぎ

• 認証前提とか気持ちはわかるけどスジは悪い気がする

• ASNの解釈等、現実のインターネットとずれている

このドキュメントに対する個人的な結論

個人的には、このドキュメントはこういうものなのかな、と思っている。

正しい問題意識 × 無理な解決策

なぜこのドキュメントはバズったのか

バズった理由はこんなとこかしらねえ。

• 現状の問題が列挙されてて、インターネットのオペレーションをしたことがあれば、どれかは差さる

• 改善方針もそれっぽく書かれてて共感してしまう

• IPv6に対してモヤモヤした気持ちを持ってる人にとっては救世主のように思える？

• IPv8というバージョンナンバーの付け方がうまい

• 良く読むと突っ込み所が多い

きれいに設計された提案は、

• 現実との折り合い

• 既存との互換性

• 標準化プロセス

を考慮しすぎて「無難」になっちゃうんだけど、この提案では、

• 現実的かどうかは一旦置いておいて

• 不満をそのままぶつけている

なので「それはそうだよね」とと思わせる力があるのかなあ。
「良い技術」ではないが、「良い問い」ではあるんじゃないかと。
プロトコルとしては弱いし、標準化されることもないんだろうけどね。

このドキュメントの活用方法

このInternet-Draftは、大学のゼミとかでチームの勉強会とかでテーマにするとすごく面白いんじゃないかしらねえ。
上げられている現状の課題や、実装の是非等について検討すると、インターネットやプロトコルについての理解が深まると思うんだ。

深掘りすると面白そうなポイント

互換性維持に成功したプロトコルとの違い

互換性を維持しながら拡張に成功したプロトコルはいくつかある。

• 4byte AS

• タグVLAN(IEEE 802.1Q)

このへんがなぜ上手くいって、なぜIPv8は(今のフレーム構造だと)互換性がないと言えるのか、とかは面白いポイントだと思う

アドレス等の表記方法

IPv6の表記方法は、IPv4に比べてわかりにくい、ということも指摘されている。
ただ、表記をIPv4のように、10進数をドット区切りにすれば良いの？、というのも疑問なんだよね。

IPv4の表記方法については、実は標準化されたRFCがない。
ちょっとこのへんにも書いたけど。

アドレス長が単純に長くなった場合にどう省略するか、とかも考えると、なかなか面白いと思うよ。

IPv6の歴史と問題点

IPv6は、IPv4が抱える問題点を解消するだけじゃなく、こんな機能があれば良いな、というものを詰めこんじゃったプロトコルなんだと思う。
とてもエレガントなんだけど、実際に使われるようになると、いろいろな問題点があった。

• IPv4との非互換性

• マルチキャストの環境前提

• 多機能すぎるICMPv6

• IPsecをmustにしてた(2011年にRFC的にはshouldに変更)

• アドレス設計の自由度が高すぎる

• NDにスケーラビリティがない

• RAのセキュリティモデルが甘い

• 便利そうなのに実質使われることがない拡張ヘッダ

• フラグメントに弱い

• アドレスが長くなるのでDNSへの依存度が高くなるが、それによる問題も増える

• 複数のアドレス配布方式、デュアルスタック等によりトラブルシューティングが複雑になる

等々、ざっと思いつくまま書いてみても問題点はいろいろある。
そしてそれぞれを解決するために、補助的なプロトコルや独自実装が作られていて、今はなんとかちゃんと動いている、と思っている。

これだけ問題があったら捨てたくなる気持ちもわかるんだけど、それでもIPv6は魅力的なのよね。
エンジニア的にグっとくるのは、実は設計思想。

• アドレス幅の大幅拡張

• エンドツーエンド

• 自動設定

• ヘッダのシンプル化

• 拡張ヘッダによる機能分離

• ブロードキャスト廃止(必要なノードにだけ届ける)

• IPsecによるセキュリティ標準化(結果として不要だったけど)

• フラグメントをエンドで行なうことでのシンプル化

• アドレスの構造化

うまくいかなかったものもあるけど、方向性は理解できるのよね。
まあ、だからどんどん使われるようになってるし、今後のインターネットはIPv6ベースになっていくとは思うんだ。

レイヤー構造の意味

IPv8のInternet-Draftは、IPレイヤーだけじゃなくすべてのレイヤーを対象としている。
それによってシンプルになるはず、と思いたいのはわかる。
でも今の通信が、レイヤー構造になってるのには理由もあるんだよね。

• レイヤー構造を取ると、それぞれのレイヤーをシンプルにできる

• 各レイヤーを交換やバージョンアップしていくことで、ちょっとずつ進化していける

レイヤーとレイヤーをくっつけるプロトコルをうまく作らないといけないとか、面倒なこともあるんだけどね。

面白いのプロトコルとしては、IPv6の拡張ヘッダを利用して、全部のレイヤーのヘッダを全部付ける、というようなSRv6というものもある。
すごく面白いよ。

RFCがどのように作られるか

こういう面白いInternet-Draftは時々投下されるんだよね。
RFCとして標準化されるまでにどういうイベントがあるか、みたいなのも勉強会の面白いネタだと思う。

このInternet-Draftの反響調査

このInternet-Draftはとても話題になって、いろいろな解説記事が出ただんけど

• 本当じゃないよなあ、という記事もそこそこある

• 各記事が、いろいろな思いや立場で書かれている

と信憑性も熱量も全然違う記事た沢山あるように感じる。
誰によって、どういった記事が書かれているか、記事の評価、スタンス、等を誰かまとめてくれないなあ。
面白いと思うんだけなあ。
今的には、AIで書かれた記事っぽいかどうか、も知りたいかな。

そしてこのnoteも多分どこかに嘘を書いてるような気がする。
なんか見付けらた教えてくださいませ。

(余談)私とIPv6

IPv6に関係してなんか良く怒られるんだよね。

20年ぐらい前に、JANOGのスタッフ打ち上げで
「おれ達バックボーンはちゃんとIPv6対応を進めてるのに、お前らサーバ屋が全然対応しない、ちゃんとやれよ!!」
と絡まれたのは、今では良い思い出だ。

DMMの社内勉強会で、IPv6の話をしたスライドを馬渡さんに見付けられて、こんな発表をするハメになったりもした。
これも、なんかいろいろな方面から怒られたんだよね。

そして、半年ぐらい前にこの記事を書いたときにも、何人かに怒られた。
動かないのは、ちゃんとやらないからだ、もっと勉強しろ、仕様に文句を言うな、とかとか。

怒りと欲望は進歩の原動力なので、熱量があるのは良いことなんだけど、私に当たらないでよーー、と思うんだよね。
まあ言いやすいのはわかるんだけど。
怒るとお腹が空くので、良くないよー。

怒られないように言いわけをしておくと、いちおうIPv6方面のイベントにはこっそり参加もしてるんだよぉ。

• 2002年ぐらいの、IPv6インストール大会の雑用(遊びに行ったら許さんに捕まった)

• 2010年の World IPv6 Day 個人参加

• 2012年の World IPv6 Launch 個人参加

個人的には、IPv6はこれからはメインのプロトコルにはなるんだろうなあ、とは思っている。
データ構造自体はだいぶ長いこと使われるんじゃないかな。
ただ、コントロールプレーン自体は、ICMPv6じゃない何かが出てきて欲しいなあ、みたいなことは考えてて、こんなnoteは書いたことはある。
ネットワークは地味だけど面白いよー