あるデバイスがインターネットプロトコル（IP）を使ってインターネット上の他のデバイスと通信するためには、まずそのデバイスに固有の数値アドレスを割り当てる必要があります。このアドレスがどのようなものかは、IPのバージョン（IPv4またはIPv6）によって異なります。
IPv4が最初に導入されたのは1983年でした。これは、現代のインターネットを生み出し、現在でも支配的なIPバージョンです。IPv6の歴史は1998年までさかのぼることができますが、この10年間で大きく普及し始め、誰が何をどのように測定しているかにもよりますが、1%未満から30～40%にまで上昇しました。
接続されたデバイスの数がIPv4アドレスの数をはるかに上回り、コストも上昇していますから、はるかに大きなアドレス空間を提供するIPv6は、そろそろ支配的なプロトコルになってくるはずです。しかし、これから説明するように、そうはなっていません。
Cloudflareは何年にもわたり IPv6の強力な支持者であり、Cloudflare Radarを通じて, 、インターネット全体におけるIPv6の普及状況を注視してきました。Radarは使用開始から3年の比較的新しいプラットフォームです。さらに過去については、5つの地域インターネットレジストリ（RIRs） の1つであるAPNIC1の友人に少し尋ねるとわかります。データを2012年までさかのぼって調べてみると、IPv6は2017年半ばまで指数関数的な成長を遂げ、その後は直線的な成長期に入り、現在も進行中であることがわかります。
IPv6の普及は、IPv4_と_IPv6の両方のアドレスをデバイスに割り当てる必要があるという両プロトコル間の互換性の欠如と、インターネット上の事実上すべてのデバイスが依然としてIPv4をサポートしているという状況のために遅れています。とはいえ、IPv6はインターネットの将来にとって極めて重要であり、その普及拡大には継続的な取り組みが必要です。
Cloudflare Radarは、APNICや他のほとんどの情報源と同様に、主にインターネットサービスプロバイダー（ISP）が_クライアント側_にIPv6を導入した度合いを反映した数字を公表しています。これは非常に重要なアングルであり、エンドユーザーに直接影響を与えるものですが、計算方法にはもう一方の側面、つまり_サーバー側_もあります。
このことを念頭に置いて、サーバー側のIPv6普及状況を調べ、クライアントがIPv6でサーバーと実際に（あるいはおそらく）どれ程度の頻度で通信できるかをテストする簡単な実験に、ぜひお付き合いください。この調査ではDNSを利用しますが、その結果には驚かされることでしょう。
クライアント側のIPv6普及状況（HTTPから）
2023年10月末までに、Cloudflareの観測では、インターネット全体のIPv6普及率は、時間帯や曜日によって若干の変動はあるものの、全トラフィックの約**36%**に達しています。ボットを除いた場合の推定値は46%強まで上昇し、人間を除いた場合は24%近くまで低下します。これらの数字は、すべてのIPv6対応コンテンツ（デフォルト設定）において、IPv6経由で提供されたHTTPリクエストの割合を示しています。
この演習で最も重要なのは、人間_と_ボットの両方の数です。両種のトラフィックの間には普及状況に差異があり、その理由としては、使用されるさまざまなクライアントソフトウェアのIPv6サポートレベルの違いや、トラフィックが発生する多くのネットワーク内でのIPv6導入レベルの違い、またそのようなネットワークの規模の違いなど、いろいろありますが、それはまた別の日に話しましょう。特定の国やネットワークの数字が気になる方は、Cloudflare Radarや、2023年の振り返りレポートでご覧いただけます。
踊るためには2つ必要
読者の皆さんは、クライアントサーバーの計算方法のクライアント側を測定しても、話の半分しかわからないと指摘するかもしれません。IPv6対応のクライアントがIPv6経由でサーバーとの接続を確立するには、サーバーもIPv6に対応していなければなりません。
ここで2つの疑問が生じます。
サーバー側のIPv6の普及状況は？
クライアント側でのIPv6の普及状況とサーバー側での普及状況の整合性は？
ユーザー、デバイス、通信バイト数など、考慮する対象によって、いくつかの答えが考えられます。ここでは_接続に_焦点を当て（その理由はすぐにわかります）ます。次のような複合的な質問について考えます。
IPv6対応クライアントがインターネット上のサーバーに接続する際、一般的な使用パターンではどれ程度の割合でIPv6を使用できますか。
典型的な利用パターンには、あるWebサイトを他のWebサイトよりも頻繁に訪れる人々や、APIを呼び出す自動化されたクライアントなどがあります。このような視点を得るためにDNSに注目します。
DNSの入力
クライアントが、従来のIPv4プロトコルまたはより新しいIPv6のいずれかを使用して、名前でサーバーとの接続を確立しようとする場合、まずインターネットの電話帳である、ドメインネームシステム（DNS）でサーバーのIPアドレスを検索する必要があります。
DNSでホスト名を検索するのは再帰的なプロセスです。サーバーのIPアドレスを見つけるには、ドメイン階層（サーバー名のドット区切りの構成要素）を複数のDNS権威サーバーにまたがって、そのうちの1つが希望する応答を返すまでたどる必要があります2。しかし、ほとんどのクライアントはこれを直接行わず、代わりに再帰リゾルバーと呼ばれる中間サーバーに依頼します。Cloudflareは、誰でも使用できるそのような再帰リゾルバー（1.1.1.1）を運営しています。
シンプルな例として、クライアントが1.1.1.1に「www.example.com 」が存在するIPアドレスを尋ねるとします。1.1.1.1はDNSルートサーバー3に「.com」について尋ねに行き、次に.com DNSサーバーに「example.com」について尋ね、最後にexample.com DNSサーバーに「www.example.com 」について尋ねます。example.com DNSサーバーは直接それを知っていて、IPアドレスを返します。次に同じような質問をするクライアントのために、1.1.1.1は最終的な答えとその間のステップの両方をキャッシュ（しばらく記憶）します。
つまり、1.1.1.1は、クライアントがIPv4アドレスを検索しようとする頻度（Aタイプクエリ）_および_IPv6アドレスを検索しようとする頻度（AAAAタイプクエリ）をカウントするのに非常に適した位置にあり、観測可能なインターネットのほとんどをカバーしています。
しかし、クライアントはサーバーのIPv4アドレスとIPv6アドレスのどちらを要求すべきかをどうやって判断するのでしょうか？
この答えは、IPv6が利用可能なクライアントは、接続を希望するすべてのサーバーに対して、AおよびAAAAの検索を別々に行い、単純に両方を要求するということです。これらのIPv6対応クライアントは、空でないAAAAの答えが返ってきた場合、空でないAの答えが返ってきたとしても（ほとんどの場合、答えが返ってくる）、IPv6での接続を優先します。興味のある方のための情報として、この新しい方を優先するアルゴリズムはHappy Eyeballsと呼ばれています。
実際のデータを見てみましょう。
クライアント側のIPv6普及状況（DNSより）
最初のステップは、ベースラインを確立することであり、クライアントIPv6の普及状況を1.1.1.1の視点で測定し、最初に行ったHTTPリクエストの数字と比較します。
IPv6を使用して1.1.1.1に接続するクライアントの頻度をカウントしたくなりますが、結果はいくつかの理由で誤解を招きます。1.1.1.1は、1.1.1.1サービスを通じてDNS検索を実行するためにクライアントが使用できるIPv4およびIPv6アドレスのセットの中で最も記憶に残るアドレスです。理想的には、1.1.1.1を再帰リゾルバーとして使用するIPv6対応クライアントは、最初の2つだけでなく、以下の4つすべてのIPアドレスを設定しておくべきです。
1.1.1.1 (IPv4)
1.0.0.1 (IPv4)
2606:4700:4700::1111 (IPv6)
2606:4700:4700::1001 (IPv6)
しかし、手動設定が必要な場合4、人間はIPv4アドレスよりもIPv6アドレスの方が記憶に残りにくく、IPv4アドレスで十分だと考えて設定を行う可能性が低くなります。
関連するものの、あまり明白ではない混乱要因は、多くのIPv6対応クライアントが、1.1.1.1のIPv6アドレスが設定されていても、IPv4でDNS検索を実行することです。これは、利用可能なアドレスに検索を分散させることが一般的なデフォルトオプションであるためです。
DNSクライアントの活動からIPv6の普及状況を評価するより賢明なアプローチは、前述のように、IPv6クライアントが常に両方を実行する5と仮定して、Aタイプのクエリの総量に対するAAAAタイプのクエリの割合を計算することです。
そして、1.1.1.1のの視点からは、クライアント側のIPv6普及率はクエリ量で**30.5％**と推定されます。これは、同じ期間にHTTPトラフィックから観測されたもの（35.9%）を少し下回りますが、2つの異なる視点でのこのような違いは想定外のものではありません。
TTLについて
DNS応答をキャッシュするのは再帰リゾルバーだけでなく、ほとんどのDNSクライアントも独自のローカルキャッシュを持っています。Webブラウザ、オペレーティングシステム、そして自宅のルーターでさえも、その後のクエリを高速化するために回答を残しています。
各回答がキャッシュに残る期間は、DNSレコードと一緒に送り返される有効期限（TTL）フィールドに依存します。DNSに詳しい方なら、AレコードとAAAAレコードが同じようなTTLを持っているか気になるかもしれません。もしそうでなければ、（クライアントレベルでより長くキャッシュされるため）この2つのタイプのうち1つに対するクエリが少なくなり、結果的に算出した数が偏ってくる可能性があります。
この円グラフは、1.1.1.1がAおよびAAAAクエリ6に応答して送り返す最小TTLを分類したものです。両方のタイプに多少の違いはありますが、その差は非常に小さいものです。
サーバー側でのIPv6の普及状況
次のグラフは、AおよびAAAAタイプのクエリが空でない応答を得る割合を示しており、サーバー側のIPv6普及状況に光を当て、求めている答えに近づいています。
サーバーのIPv6普及率は、クエリ量ベースで**43.3%**と推定され、クライアントの場合よりも明らかに高くなっています。
両方の側で使用されている割合
1.1.1.1が処理するIPアドレス検索の30.5%がIPv6アドレスを使用して意図した宛先に接続できたとしても、それらの検索のうち43.3%だけが空でない応答を得たとすると、クライアントとサーバー間でIPv6接続が行われる割合のかなり正確な値として約**13.2%**を得ることができます。
人気ドメインの潜在的影響
Radarのトップ100リストに含まれるドメインのクエリーボリュームで測定したIPv6サーバー側の普及率は60.8%です。これらのドメインを全体の計算から除外すると、以前の13.2%という数字は8%に下がります。これは大きな違いですが、トップ100ドメインが1.1.1.1へのAおよびAAAAクエリ全体の55%以上を占めているため、予想外ではありません。
このような人気の高いドメインのいくつかがすぐにでもIPv6を導入すれば、IPv6の普及が顕著になり、IPv6対応クライアントがIPv6を使用して接続を確立する機会も増えるでしょう。
まとめ
インターネット全体におけるIPv6の普及状況を観察することは、さまざまなことを意味します。
IPv6対応のインターネットに接続しているユーザー数をカウント
IPv6に対応したデバイスの数、またはそれらのデバイス上のソフトウェア（クライアントまたはサーバー、もしくはその両方）の数をカウント
IPv6接続を流れるトラフィック量をバイト単位で計算
IPv6経由の接続（または個々のリクエスト）の割合をカウント
この演習では、接続とリクエストに注目することにしました。いくつかの異なる視点を考慮することによってはじめて実態を正確に理解できることを念頭に置いて、3つの異なるIPv6普及率の数字を見ました。
CloudflareのCDNから配信されたHTTPリクエストをカウントした場合、35.9%（クライアント側）
1.1.1.1で処理されたAおよびAAAAタイプのDNSクエリをカウントした場合、30.5%（クライアント側）
1.1.1.1から行ったAAAAタイプのDNSクエリに対する有効なレスポンスは、43.3%（サーバー側）。
DNSの視点から、_クライアント側_と_サーバー側_の数値を組み合わせて、サードパーティサーバーへの接続がIPv4ではなくIPv6で確立される割合を見積もったところ、わずか**13.2%**でした。
これらの数字を改善するためには、インターネットサービスプロバイダー、クラウドおよびホスティングプロバイダー、そして企業も同様に、ネットワーク内のデバイスでIPv6を利用できるようにする割合を増やす必要があります。しかし、大規模なWebサイトやコンテンツソースもまた、IPv6対応クライアントがより多くIPv6を使用できるようにするために重要な役割を担っています。Radar Top 100のドメインに対するクエリの39.2%（1.1.1.1に対するすべてのAおよびAAAAクエリの半数以上に相当）は、依然としてIPv4のみの応答に制限されています。
IPv6完全普及への道のりにおいては、インターネットはまだまだそこには近づいていません。しかし、関係者全員が努力を続けることで、前進を続けることができ、おそらく前進を加速させることもできるでしょう。
サーバー側では、Cloudflareはすべてのドメインに無料のIPv6サポートを提供することで、長年にわたってこの世界的な取り組みを支援してきました。クライアント側では、1.1.1.1アプリはお使いのインターネットサービスプロバイダーがIPv6サポートを提供していない場合でも、デバイスを自動的にIPv6対応にします。また、IPv6のみのネットワークを管理している場合は、1.1.1.1のDNS64サポートでカバーできます。
***1CloudflareのパブリックDNSリゾルバー(1.1.1.1)はAPNICとのパートナーシップにより運営されています。詳しくは、発表元のブログ記事 および1.1.1.1のプライバシーポリシーをご覧ください。.2DNSの仕組みについては、Webサイトの「What is DNS?」セクションに詳細情報が掲載されています。実践的な学習者であれば、Julia Evansの「mess with dns」をご覧になることをお勧めします。3再帰リゾルバーは、13のルートサーバーのIPアドレスを事前に知っています。Cloudflareはまた、EおよびFルートインスタンスにAnycastサービスを提供することで、DNSの最上位レベルに参加しています。これは、1.1.1.1が最初の検索のステップで遠くまで行く必要がないことを意味します。41.1.1.1アプリを使用する場合は、4つのIPアドレスが自動的に設定されます。5簡略化のためですが、IPv6のみのクライアントはまだ無視できるほど少ないものと想定します。これは一般的に妥当な想定であり、利用可能な他のデータセットでも確認されています。61.1.1.1は、他の再帰リゾルバーと同様に、調整されたTTLを返します。レコードの最初の有効期限（TTL）からレコードが最後にキャッシュされてからの秒数を引いたものです。空のAおよびAAAAの回答は、RFC 2308で規定されているように、ドメインのStart of Authority(SOA)レコードで定義されている時間キャッシュされます。