Let’s Encryptは、あらゆるサイトでのHTTPSの有効化を支援・促進することを目的として、2016年4月12日に開始されました(Webでは推奨プロトコルとしてTLSへの移行が着実に進んでいますが、「SSL Everywhere」と呼ばれることもあります)。2017年2月末時点で、この取り組みを開始したEFFは、Webの半分が暗号化されたと推定しています。もちろん、そのすべてがEFFとLet’s Encryptの功績というわけではありません。実際、それよりかなり前のデータでも、F5のお客さまの大半(約70%)がクライアント向けサービスでHTTPSを有効にしていたことが示されています。つまり、EFFが取り組みを開始する以前からHTTPSは利用されていましたが、Let’s Encryptが発行した証明書*の数が非常に多いことを踏まえると、この取り組みが測定可能な成果を上げていることは確かです。
On 2006年9月11日、ICANNは「Internet Assigned Numbers Authority(IANA)によるIPv6アドレス割り当てのためのグローバルポリシーを承認」しました。標準自体はその何年も前(約10年前)に承認されていましたが、アドレス割り当てを管理するポリシーがなければ、実質的な意義はそれほど大きくありませんでした。しかし2006年には、IPv6への移行が本格化しました。Webが成長し、モバイルが爆発的に普及する一方で、利用可能なIPv4アドレスが枯渇しつつあったためです。
強化されたセキュリティのためでないとしても、数十億台のデバイスやモノの接続を支えられる広大なアドレス空間を確保するために、IPv6が必要でした。
それにもかかわらず、普及率は惨憺たるものです。「クラウド」が誕生した時代には、すでにIPv6が利用可能だったことを考えてみてください。それでも、2016年後半まで、Amazon AWSとMicrosoft Azureがコンピューティングインスタンス向けクラウドサービスでIPv6を有効にすることはありませんでした。
この状況を受け、HTTPSをこれほど短期間でほぼあらゆる場所に普及させられたのに、IPv6をサポートするサイトの割合がいまだに低いのはなぜか、と嘆く声もあります。Googleの推計によると、IPv6が有効になっているユーザーは16.06%です(World IPv6 Launchが追跡しているサービスプロバイダーの対応状況と比較すると興味深い数字です)。しかし、IPv6をサポートしているWebサイトはわずか10%です(W3C Techsによる)。

公平を期すなら、HTTPSは新しいものではありませんでした。EFFは、すでに利用可能だったHTTPSを有効にするよう人々に働きかけ、その実現を後押ししていただけです。HTTPSは広くサポートされ、十分に理解され、成熟しています。したがって、HTTP/2のように、以前の標準との互換性がないといった同様の欠点を持つ、より新しい標準と比較するほうが公平かもしれません。
2015年5月、長年にわたり利用されてきたWeb標準の新バージョンが正式に承認されました。それがHTTP/2です。IPv6と同様、以前のバージョンとの互換性はありません。「SSL Everywhere」とは異なり、IPv6やHTTP/2への対応は、証明書を取得してWebサーバーやインフラストラクチャでHTTPSを有効にするだけでは実現できません。HTTPからHTTPSへの移行が混乱を招き、ネットワークインフラストラクチャに影響を及ぼす可能性があるのは事実ですが、その影響はIPv6やHTTP/2への移行ほど大きくはありません。
新しい基盤プロトコルへの移行には、将来のある時点まで新旧両方を同時にサポートする移行アプローチが必要です。つまり、トラフィックが通過する可能性のあるすべてのデバイスで「デュアルスタック」が必要になります。これは、組織によっては途方もない作業となり、別の組織にとってはアーキテクチャ上の悪夢となります。ソフトウェアに技術的負債が生じるのと同様に、ネットワークにもアーキテクチャ上の負債が生じます。そして、その負債に対する「利払い」が、IPv6導入の妥当性を示すことを難しくしている可能性があります。結局のところ、IPv6への対応は必須というわけではありません。IPv6をサポートしなくても、事業は継続できます。
本当にそうでしょうか?
もともとHTTP/2ではTLS/SSLが必須になる予定だったことを思い出してください。これには多少の不満の声が上がり、最終的には任意となりました。しかし、ブラウザ開発各社はそれを意に介さず、TLS/SSL経由のHTTP/2のみをサポートしたため、事実上すべてのユーザーにこの要件を課すことになりました。2015年後半には、Googleが検索ランキングでHTTPS対応サイトを優先し始めました。さらに2016年には、Appleも同様の措置を講じ、すべてのネイティブアプリにApp Transport Securityの使用を義務付けたことで、HTTPSへの移行を再び事実上強制しました。
要するに、クライアント側の関係者によってHTTPSへの対応が事実上強制されてきたのです。
現時点では、IPv6に同様の要件はありません。IPv4アドレスが枯渇していくのを誰もが目の当たりにしましたが、その影響は比較的小さいか、ほとんどありませんでした。そのため、混乱を招き、多額の費用がかかる可能性のある移行に踏み切る切実な動機を、今のところ誰も感じていません。しかし、より多くのモノが登場するにつれ、いずれIPv6のみに対応した状態で出荷されるようになる可能性は十分にあります。モノは小型で、処理能力も限られています。モノのインターネットでは、機能を絞るほど効果的です。多くのIoTデバイスがHTTPではなくMQTTを採用する理由の1つもそこにあります。MQTTは、より重いWebプロトコルであるHTTPよりも軽量で高速かつ効率的です。IPv4とIPv6の両方に対応する場合も同様です。両者には互換性がないため、ほとんどのデバイスはいずれか一方に対応します。そして最終的には一方が選ばれ、誰もがその対応に追われることになるでしょう。

そうならないとしても、現在利用可能なIPv4アドレスで対応できるのは、2020年までに利用されると予測された200億台のデバイス(Gartner)の20%未満です。IPv6なら、はるかに強気なCiscoの予測である500億台をも大幅に上回る数のデバイスに対応できます。しかも、これはIoTだけの話です。
クラウドにも問題があります。拡大する顧客基盤を支えるのに十分なIPv4アドレスを確保できないためです。IaaSが予測どおりに成長するには、クラウドプロバイダーはIPv6へ移行しなければなりません。AmazonとMicrosoftがIPv6への移行を進めている背景にも、間違いなくこの事情があると考えられます。
これらすべてが意味するのは、IPv6対応を必要とする状況がいずれ必ず訪れるということです。その要因はIoTかもしれませんし、クラウドそのものかもしれません。あるいは、この2つが組み合わさり、ビジネスに爆発的な変革をもたらす力となる可能性もあります。いずれにせよ、いつかは移行しなければならず、切迫した状況で移行する事態は避けるに越したことはありません。IPv6の問題点を解消する時間は十分にあり、現在では、移行を開始するためのデュアルスタック方式をサポートするソリューションが市場に十分そろっています。まだ対応していない場合は、ビジネスの成長に欠かせない「モノ」によって対応を迫られる前に、IPv6の有効化を本格的に検討すべき時期です。
* 確かに、一見すると不正な証明書の数や、無差別にばらまくことに伴うリスクについて掘り下げることもできますが、それはまた別の機会に取り上げます。
著者について

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。