HTTPS がほぼどこにでも普及していますが、IPv6 についてはどうでしょうか?

Let's Encrypt は、サイトがどこでも HTTPS を有効にすることをサポートし、奨励することを目的として、2016 年 4 月 12 日に開始されました (Web は TLS を優先プロトコルとして着実に移行していますが、どこでも SSL と呼ばれることもあります)。 2017 年 2 月末現在、 EFF (この取り組みを開始した組織) は、Web の半分が暗号化されていると推定しています。 もちろん、そのすべてが EFF と Let's Encrypt のせいというわけではありません。 結局のところ、その日付よりかなり前のデータがあり、それによると、F5 の顧客の大多数 (70% 程度) がクライアント向けサービスで HTTPS を有効にしていたことがわかります。 したがって、EFF が取り組みを開始する前から人々が HTTPS をサポートしていたことは明らかですが、発行された証明書* の数が非常に多いことを考えると、この取り組みが目に見える成功を収めていないわけではありません。

2006 年 9 月 11 日、ICANN は「インターネット割り当て番号機関 (IANA) による IPv6 アドレスの割り当てに関するグローバル ポリシーを承認」しました。 標準自体は何年も前（10年ほど前）に批准されていましたが、それらのアドレスの割り当てを管理するポリシーがなければ、それほど重要ではありませんでした。 しかし、2006 年の時点で、私たちは IPv6 への移行を真剣に考えていました。 結局のところ、Web は成長し、モバイルは爆発的に普及し、利用可能な IPv4 アドレスは減少し続けました。

IPv6が必要だったのは、セキュリティ強化のためではなく、数十億の接続デバイスやモノをサポートできる拡張アドレス空間のためでした。

しかし、採用率はひどい状態です。 「クラウド」は IPv6 が利用可能だった時代に誕生したと考えてください。 しかし、 Amazon AWSとMicrosoft Azure がコンピューティング インスタンス向けのクラウド サービスで IPv6 を有効にするまでには、2016 年後半までかかりました。  

このため、短期間でほぼすべての場所で HTTPS を利用できるのに、なぜ IPv6 をサポートするサイトの割合がまだこれほど少ないのかと嘆く人もいます。 Google は、ユーザーの 16.06% が IPv6 対応であると推定していますが(これは、World IPv6 Launch で追跡されているサービス プロバイダーのサポートと比較すると興味深い数字です)、Web サイトの 10% のみが IPv6 をサポートしています ( W3C Techs によると)。

公平に言えば、HTTPS は新しいものではありません。 EFF は、すでに手元にあるものを活用できるように、人々を奨励し、力を与えているだけなのです。 HTTPS は十分にサポートされ、十分に理解されており、徹底的に構築されています。 したがって、HTTP/2 のような以前の標準との非互換性など、同様の欠点を持つ新しい標準と比較する方が公平かもしれません。

2015 年 5 月に、堅固な Web 標準の新しいバージョンが承認されました。 HTTP/2 。 IPv6 と同様に、以前のバージョンとは互換性がありません。 「SSL Everywhere」とは異なり、IPv6 または HTTP/2 をサポートするには、単に証明書を取得して Web サーバーまたはインフラストラクチャで HTTPS を有効にするだけでは十分ではありません。 HTTP から HTTPS への移行は混乱を招き、ネットワーク インフラストラクチャに影響を及ぼす可能性がありますが、IPv6 や HTTP/2 によって発生する混乱と同じレベルの混乱ではありません。

新しい基本プロトコルに移行するには、移行アプローチが必要です。つまり、将来のある時点まで、古いプロトコルと新しいプロトコルの両方を同時にサポートする必要があります。 これは、トラフィックが流れる可能性があるすべてのデバイスに対して「デュアルスタック」を意味します。 これは、一部の組織にとっては大変な作業であり、他の組織にとってはアーキテクチャ上の悪夢です。 ソフトウェアが技術的負債を負うのと同様に、ネットワークはアーキテクチャ上の負債を負います。そして、そのアーキテクチャ上の負債に対する「利息の支払い」が、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 よりも小型で高速、かつ効率的です。 IPv4 と IPv6 の両方のサポートも同様です。 互換性がないため、ほとんどのデバイスはどちらか一方をサポートしています。 そして最終的に彼らはどれか一つを選び、皆がそれを支持しようと争うことになるだろう。

たとえそうでなかったとしても、現在利用可能な IPv4 アドレスは、2020 年までに使用されると予測されている 200 億台のデバイスのうち 20% 未満しか収容できません (Gartner)。 IPv6 は、シスコのより積極的な 500 億台のデバイス予測をはるかに上回る数をサポートします。 そして、それはまさに IoT です。

クラウドも、拡大する顧客基盤をサポートするために十分な IPv4 アドレスを購入できないという問題を抱えています。 IaaS が予測どおりに成長するには、クラウド プロバイダーは IPv6 に移行する必要があります。 アマゾンとマイクロソフトがそうした動きをしたのは、間違いなくこのことが一因である。

これらすべてが意味するのは、IPv6 サポートを必要とする強制機能が最終的に登場するということです。 それは IoT かもしれないし、クラウドそのものかもしれない。 これら 2 つの力が合わさると、あなたのビジネスに爆発的な混乱をもたらす可能性があります。 いずれにせよ、いつかは移行しなければなりませんが、急いで移行しないことが常に最善です。 IPv6 の問題点を解決するには長い時間がかかりましたが、移行を進めるためにデュアルスタック アプローチをサポートするソリューションが現在市場には十分以上あります。 したがって、まだ IPv6 を有効にしていない場合は、ビジネスの成長に必要な理由で強制される前に、IPv6 を有効にすることを真剣に検討する時期です。

* 確かに、一見すると偽造の証明書の数や、それをキャンディーのように盲目的に配布することはリスクを伴うという点について詳しく検討することもできますが、それはまた別の日に扱う問題です。