Jan Zorz氏によるIPv6の神話解明、そしてその普及が遅れている理由

IPv6を語る―その必要性と導入の遅れ、誤解の解明

2023年5月12日
翻訳: 島田 麻里子

この記事は米Catchpoint Systems社のブログ記事Mythbusting IPv6 with Jan Zorzの翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

IPv6は、インターネットの成長とその既存のIPv4アドレスプロトコルに対する潜在的な影響、特にアドレスの枯渇の懸念に対処するために、1990年代後半にIPv4の後継として開発されました。
一定期間デュアルスタックソリューションとして運用された後、IPv4は完全に廃止されることになると考えられていました。
しかし、25年近く経った現在、IPv4アドレスの枯渇が現実的な問題となっており、その一因としてIPv6の導入が遅れていることが挙げられます。

実際、Geoff Huston氏によれば、現在の世界のIPv6展開率はわずか30％であり、Alexaトップ1000のWebサイトのうち、IPv6経由でアクセスできるのは30％に過ぎません。
IPv6への完全な移行がいつ完了するかは、現時点では不明です。

IPv6の導入ペースに関する問題は、IPv6プロトコルで運用されるネットワークが少なければ少ないほど、監視用のノードを追加する機会が減るため、私たちにとってより緊急性が高まっています。
これは古典的な鶏と卵の難問です。

そこで、世界的にIPv6導入の専門家として知られる6connect Labsの副社長であるJan Žorž氏を招き、この問題について話し合いました。

JanとTonyがIPv6の神話に挑む

Catchpointの運用担当VP、Tony Ferrelli氏が、Janと共に率直で面白く、洞察に満ちた会話を展開し、世界的な導入が遅れる原因、なぜグローバルなオペレーターがIPv6を必要とするのか、デュアルスタックから始めるデメリット、そしてIPv6にまつわる一般的な誤解を解明しました。

Janは過去12年間、IT分野のコンサルタントとして働いており、特にIPv6に特化しています。
彼はスロベニアでGo6研究所を共同設立し、IPv6に対する意識を高める活動を行いました。

その成功により、スロベニアは現在、IPv6に対して最も準備が整っているEUの国としてトップに立っています。
Jan氏は定期的に世界中で自身の研究成果を発表し、国内外でIPv6に対する意識を高め、その導入を促進しています。

一方のTonyは、Catchpointで運用を担当する前に、DoubleClick時代に共同創業者たちと初めて出会い、グローバルネットワークマネージャーを務めていました。
その後、10年以上にわたりGoogleのネットワークマネージャーを務めました。
GoogleのIPv6導入への熱意とコミットメントのおかげで、TonyはIPv6に多くの経験を積むことができました（ただし、彼は自分のネットワーク内のすべてのIPv4アドレスを覚えていた頃を懐かしく思っていると認めています）。

以下に、彼らの会話のハイライトを書き起こし形式で共有します。
また、逸話的な内容でありながら非常に洞察に満ちたやりとりを楽しんでいただくために、いくつか動画の切り抜きも含めています。

Q&A：書き起こし

遅々として進まないIPv6の普及

Tony:

そうですね、最初の質問はかなり重いな。
IPv6は正式には98年に登場しましたが、その前にもたくさんのことが起こっていました。
なぜ2022年から2023年にかけても、まだ導入が遅いように感じられるのでしょうか？

Jan:

まあ、人々はネットワークアドレス変換（NAT）を発明し、それによって一種の偽の安心感が生まれました。
「レガシープロトコルの悲惨な寿命を無限に延ばせる」といった感じです。
これは、ネットワークオペレーターや企業、そして他のすべての人がまだ考えていることですが、現実にはそうではありません...

IPv6の展開に忙しい人もいますが、IPv4の古い知識に固執している人もいます。
なぜでしょうね？ 私は運用環境から出てきた人間で、たくさんの人が「IPv4についてはすべて知っています。IPv4の問題を修正する方法も知っているし、IPv4のトラブルシューティングもわかる。どう対処すればいいかも。なのに、必要のない新しいプロトコルを導入する必要はあるんですか？」と言っているのを知っています。

基本的に、問題は技術者が自分たちのユーザに集中しすぎて、それ以上の広い世界を見ずにいることです。
IPv4アドレスを使ったプライベートNATを作れば、問題は解決します……今のところ。
私の経験では、彼らはGoogleやFacebookなどの大手コンテンツプロバイダがデータセンターからIPv4を削除し、エッジへのトランスレータに移行していることすら知らないことがよくあります。

最近、クロアチアが初めて開催したネットワークオペレータのグループで、IPv6について話をしようと誘われたんです。
おいおい、古い話だなぁと思いましたよ。
一体何なんだよ？って。

彼らは、いいえそんなことはない、私たちのオペレータに話してくれ、と言いました。
そのオペレータたちは、IPv4のスペースは十分にあるので、IPv6は必要ないと思っているようです。

そこで私は、「世界中のコンテンツプロバイダがやっていることはこういうことだ」と、非常にハイレベルなプレゼンテーションを作成しました。
彼らはIPv6をネットワーク内に導入しているのです。

IPv4で起こっていることと比較してみてください。
これはまだエッジにある小さなトランスレータです。
ISPとして、すべてのトラフィックをIPv4で送信し、キャリアグレードのNATで変換すると、基本的にはIPv4でネットワークの端にある小さな翻訳機に接続して、コンテンツに到達することになるのです。

これはあまりスマートではありません。

Tony:

そうですね。
すべてを1つのソースを通じて送り込んでいるわけですから……。
例えそれがまあまあ大きなデバイスでも、問題が生じますね。

Jan:

少なくとも二重の変換ですね。

Tony:

まさにそうです。

Jan:

次のスライドでは、「もしIPv6を導入したらどうなるか？」ということを尋ねてみました。
顧客からコンテンツまでまっすぐなグリーン・パスができ、その間にある翻訳などのコストがかからなくなるのです。

すると、彼らは「なんてこった、マジかよ」という感じでした。
わたしは「ええ、そうなんですよね」と答えました。

すると彼らは、「そうなんだ、知らなかった。IPv6は実験的なもので、大規模なものではないと思っていたが、これからは真剣に考える必要があるんだな」と言った感じで。
私は、「まあ、そろそろいい頃合いでしょうね」と話しました。

Tony:

ARINのスペースが不足し、RIPEもパブリックIPv4スペースの確保が難しくなっているので、今は彼らに何らかのプレッシャーがかかっているとは思いませんか？
Googleのようなところは、何年も前に※RFC1918のスペースを使い果たしていますね。

それで、その根拠は何だと思いますか？
何が人々の足を引っ張っているのでしょう？

※訳注…「RFC1918」 プライベートIPアドレスの範囲の割当に関するRFC文書

Jan:

さっきも言ったように、大手事業者や大手コンテンツプロバイダがようやく意見を変えてきたところで、幕の裏側では色々なことが行われているんです。
私は、世界中の多くの事業者のIPv6導入を支援してきましたが、これは一連のプロセスです。
小規模でそれほど複雑でないネットワークであれば、2～3カ月で導入できます、恐らく。

一方、もし巨大で複雑な通信ネットワークを持っているならば、おそらく1年か2年は必要でしょう……それも非常に速い場合です。

デュアルスタック化を目指す

訳注:「デュアルスタック」は、ネットワークのコンテキストで使われ、IPv4とIPv6の両方を同時にサポートするシステムを指します。
これは、IPv4からIPv6への移行期間中に特に重要です。
IPv6はIPv4に比べて多くの改善点を持っていますが、全てのデバイスやネットワークがまだIPv6をサポートしていないため、デュアルスタックシステムは重要な役割を果たしています。
デュアルスタックシステムでは、IPv4とIPv6の両方のアドレスを持つことができ、両方のプロトコルを通じて通信を行うことができます。

Tony:

通常、最初にデュアルスタックを推奨しているのですか？

Jan:

それは、状況によりますね。
固定ネットワークであればそうですが、国によっては、合法的傍受の必要性周りの法律が異なるため、それにもよります。

Tony:

政府が技術的な問題に関与してくれるのは素晴らしいことですね。

Jan:

そうですね、特定の法律に従わないと、オペレータのライセンスを失うことがあるという事実を皆さんご存じです。
もし、私がIPv6の実装を勧めて、彼らが必要な合法的傍受のインターフェースを提供できなかったためにライセンスを失ったとなれば、おそらく棒と火で私を追いかけてくるでしょう！

一方、モバイルネットワークでは、デュアルスタックを導入する理由はありません。
なぜなら、※464XLATは非常にうまく機能しているからです。

訳注…「464XLAT」IPv6とIPv4の共存技術のひとつ。
主にAndroidスマートフォンで実装されています。

Tony:

デュアルスタックから始めることのデメリットは何でしょうか？

Jan:

実際には、IPv4の空き容量が足りないという問題は変わらないので、主要な問題は解決しませんよね？

Tony:

そうですね。

Jan:

IPv6を導入することで、問題は少し軽減されます。
アドレスの問題はまだありますが、少なくとも、たとえば携帯電話や固定電話の事業者であれば、IPv6を導入するとすぐにトラフィックの50％がIPv6に切り替わるでしょう。
なぜなら、Google、Facebook、Yahoo、Microsoft、AppleなどがIPv6で運用しているからです。

Tony:

ええ、そうです。

Jan:

キャリアグレードNAT（CGN＝インターネットサービスプロバイダがインターネットと契約者回線の間で行うネットワークアドレス変換）がどんどん大きくなってしまうという問題がありますが、それは、CGNだけだと、CGNを大きくするためにネットワークを大きくする必要があり、それには多額の費用がかかるからです。
資金的にも無理がある。

IPv6をデュアルスタックで導入する場合も、CGNは必要ですが、少なくとも出口戦略はあります。
恐らく、より多くのコンテンツプロバイダがIPv6を導入すれば、CGNボックスを経由するトラフィックはますます少なくなっていくでしょうから。

ある時点で、CGNを非常に小さくできるか、あるいは、より多くのトラフィックがIPv6に移行するため、20年後くらいには消滅しているかもしれません。
それで、持続可能性とお金の問題は解決しました。
しかし、アドレスの問題は解決されません。

IPv6という神話

Tony:

IPv6に関する神話や誤った認識について、今すぐ打ち破りたいことはありますか？

Jan:

「インスタンスで64ビットを失うのだから、ネットワークとホスト部分の分割はもっとよく考えるべきだった」とは言われますね。
インターフェイスに番号をつけるだけで、アドレス空間の半分を失ってしまうのです。

でも、IPv6ができたのは25年、30年近く前のことです。
それでも、64ビットはある。
32ビットよりはマシでしょう。

また、このことから、IPv6はIPv4よりも安全性が低いか高いかのどちらかだと思われています。
しかし、基本的には同じです。

他にも、IPv6にはセキュリティがデフォルトで組み込まれていると言う人もいます。
そうではありません。
トランスポートモードでIPSECというオプションがありますが、それを有効にするほどの知識を持っている人はあまりいないと思います。

Tony:

そうですね。
現時点でそれを可能にした人を誰か思い浮かべることができますか？

Jan:

私が、ラボのテスト用にIPSECをトランスポートモードでやってみましたよ。

Tony:

しかし、ラボを越えて、現実の世界では？

Jan:

誰もやっていないと思うのですけどね。

Tony:

なぜですか？

Jan:

それを可能にする簡単なツール、特にキーを配布するためのツールが不足しているからです。
これが本当の問題なのです。

もし私があなたと一緒にトランスポートモードのIPSECを有効にしたい場合、私はキーを作成してあなたに送る必要があります。
そして、あなたが鍵を作り、それを私に送り、私がそれを入れる必要がある。
これは大変な作業です。

Tony:

仰る通り。
営利団体がこれを簡単にすると決めるまでは、おそらく採用されないでしょうね……。
あるいは、大手技術会社の1社が、時間とリソースを投資して実装を考えなければならないでしょう。

Jan:

その通りです。
そうだ、この人、あとこの人、そしてあの人と暗号化を始めたい、あとは自動的になるべきだ……という感じでやるのがいいのです。

IPv6によるマルチホーミング

訳注: 「マルチホーミング」はネットワーク接続に関する用語で、1つのネットワークエンドノードが複数のネットワーク（通常は2つ以上のインターネットサービスプロバイダ）に接続されている状態を指します。
これは冗長性を提供し、1つのリンクまたはプロバイダがダウンしても他の接続を通じてネットワーク接続を維持することが可能になります。
マルチホーミングは一般に、より高い信頼性と可用性が必要な企業やサービスプロバイダによって使用されます。
それはまた、ネットワークのパフォーマンスを最適化するためにも使用されることがあります。
たとえば、トラフィックを複数のリンクに分散することで、ネットワークの帯域幅を効果的に活用し、一部のリンクが飽和するのを防ぐことができます。

Tony:

マルチホーミングについてお話しください。
IPv4では、かなり簡単だったでしょう？
/24（サブネットマスク）を取得して、VerizonとAT&Tに行けば、2つの接続先を持って/24を通知することができる、簡単だ。

はっきり言って、今日マルチホーミングしないでサービス運営してたら、ちょっとバカにしてるんじゃないか？と思います。
それは危険です、だから……

Jan:

それはIPv4と全く同じです。

Tony:

完全に同じですか？

Jan:

ASとBGPが必要になりますから。

Tony:

そうですね。
あと、最小限の通知可能なネットブロックは何でしょうか？

Jan:

/48です。

Tony:

/48？
それが/64になることはないのでしょうか？
/64の方が実用的なのでは？

Jan:

とんでもない。
サイトの定義がどうであれ、/48がサイトのサイズであるという認識があります。

Tony:

例えばそのサイトに3台のサーバしかないような小さなスタートアップの場合はどうでしょうか？

Jan:

私が普段から言っていることをご存知でしょうか。
アドレスを数えるな、豆を数えるな、と。
IPv6では全く違います。

IPv6では、アドレスの後にあるネットワークサイズが、その目的を示しています。
ネットワークなら/64、サイトの場合や、気前がいいなら単一のホームユーザには/48……そうでない場合は、/56を割り当てますよね？
ただし、それ以下にはしないでください。

Tony:

では、グローバルに分散している企業のサービスを運営しているネットワークエンジニアにアドバイスすることはありますか？
おすすめは、各サイトに/48を用意することでしょうか？

Jan:

その地域で何が行われているかによります。
例えばRIPEリージョンであれば、LIRとして/29を取得することになります。
当初は/32でした。

Tony:

私たちの多くは、ISPに行き、ブロックを割り当てるよう頼んでいました。
すると、ISPは/64を割り当ててくれました。
しかし、そのブロックをマルチホームしたい場合、BGPを実行してマルチホームすると伝えると、ISPはその/64しか割り当てない。

Jan:

まさにこのことについて話すRIPE690のドキュメントを作成し始めました（「さらに詳しく」からリンクをご参照ください）。
エンドユーザに対するIPv6プレフィックスの割り当て、パーシステントとノンパーシステント、どのようなサイズを選択するかなど、オペレータのための現在の最善の運用方法について議論しています。
チュートリアルを行う際、私はいつも「1つの/64に何台のデバイスを入れることができますか？」と尋ねます。

Tony:

なぜ伝えないのですか？

Jan:

全てのデバイスですよ。
そして、これは皆さんの家の1つのレイヤー3インターフェースのアドレス指定に過ぎません。

IPv6普及のための動き

Tony:

では、最後になります。
ネットワーク事業者やビジネスリーダー、あるいは政府機関に向けて、IPv6導入を進める上で何か言いたいことはありますか？

Jan:

IPv6は成熟してきました。
とても古いんです。
もしIPv6が人間だったら、お酒を飲んでいることでしょう。

Tony:

では、IPv8があり、その後にIPv16があるのでしょうか？

Jan:

いやいや、違います。
25年以上にわたるIPv6の世界での経験とその展開を見ていると、たとえIPv10やIPv100ができたとしても、私たちが生きている間にそれ以外のものを展開できるようになるとは思えません。
だから、基本的には、私たちはそれに縛られている。

人々はそのことについて考え始め、動き出すべきでしょう！

Tony:

後押しするために、政府が関与する必要があると考えますか？

Jan:

まあ、そこは疑問ですね。
ある人は「市場に任せればいい」と言います。
また、「いや、政府が介入して要求すべきだ」と言う人もいます。

私はInternet Societyで7年間働いていたとき、世界中を回ってIPv6やDNS-SEC、RPKIなどに関する話をしました。
そして、国や法律が違えば、その中で仕事をしなければなりません。

ですから、特効薬はないのです。
世界のそれぞれの地域が、世界のそれぞれの地域によって対応することになるのです。

Tony:

素晴らしいですね、よくわかりました。
本当にありがとうございました。
楽しい話ができて嬉しかったです、感謝します。

Jan:

こちらこそ、楽しくお話させていただきました。
また質問があれば、パート2をやりましょう！

CatchpointのIPv6対応について

Catchpointでは、オブザーバビリティ・ネットワークを拡大する方法を常に模索しており、できるだけ深く広範な監視カバレッジを提供することを目指しています。
しばしば、お客様のニーズが次の観測ポイントの配置場所を決定する原動力となります。
昨年は、1日あたり30億人以上のグローバルユーザを抱える最大手のお客様が、IPv6ネットワークがインフラに不可欠であることから、IPv6ノードを当社のネットワークに追加することに強い意欲を示されました。

できる限り迅速に対応するために取り組んでいます。
現在、私たちは264のIPv6ノードを持っており、ニーズに応えるため、約2週間ごとに新たなノードを追加しています。

さらに詳しく

プレフィックスサイズに関するJanのRIPE690のドキュメントをご覧ください。
「Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose」

グローバルに分散された物理インフラをベースに、Catchpointがお客様の環境をテストし、ユーザが実際にいる場所でアプリケーションをテストする能力を提供する方法について、Equinix社のトニーへのインタビューはこちら。
「When something on the Internet breaks, how do you fix it?」

Catchpointの全世界のノード一覧をご覧ください。
これには、世界中で成長しているIPv6の存在も含まれています。