Internet Infrastructure Review（IIR）Vol.65
2024年12月

1. 定期観測レポート

IIJインフラから見たインターネットの傾向 〜2024年

インターネットサービスを提供するIIJは、国内でも有数規模のネットワーク・サーバインフラを運用しています。その運用によって得られた情報から1年間のインターネットの動向を分析し、本誌IIRで毎年報告しています。今回もBGP経路、DNSクエリ分析、IPv6、モバイルの各視点からここ1年の変化の傾向を分析しました。

Theme 01 BGP・経路数

拡大する

表-1「IPv4フルルート」に含まれるプレフィクス長ごとの経路数の推移

次に「IPv6フルルート」の情報（表-2）及び「IPv6フルルート」に含まれるunique IPv6/64ブロック数の情報（表-3）を確認します。

拡大する

表-2「IPv6フルルート」に含まれるプレフィクス長ごとの経路数の推移

総経路数は20万超に到達しました。増加数は昨年よりは減少しましたが一昨年と同程度を維持しています。"/41-/43"列の数回を除くと本定期観測を開始して以来増加する一方の各経路数ですが、今回は/29の増加数が初めて4桁になったことが目を引きます。unique/64ブロック数も30%弱の増加となっており、IPv6の導入、IPv6ネットワークの拡大が引き続き進んでいることが窺えます。なおBGPとは無関係の余談ですが、昨今想定される大規模ネットワークの例示に従来のもの（/32）では不足との理由から、より大きなドキュメント用IPv6アドレスブロック（/20）の追加が行われています（RFC9637）。

最後に「IPv4/IPv6 フルルート」広報元AS（Origin AS）数を確認します（表-4）。なおこの1年の間にARIN及びLACNICに対し各々1024の32-bit only AS番号が追加割り振りされています。

拡大する

表-4「IPv4/IPv6フルルート」の広報元AS数の推移

Theme 02 DNSクエリ解析

IIJでは利用者がDNSの名前解決を利用できるようフルサービスリゾルバを提供しています。この項目では名前解決の状況を解説し、IIJで2024年10月9日に行ったフルサービスリゾルバの1日分の観測データのうち、主にコンシューマサービス向けに提供しているサーバのデータに基づいて分析と考察を行います。

フルサービスリゾルバは利用者端末からのDNS問い合わせに応じて必要な名前解決機能を提供します。具体的には、名前を解決するためrootと呼ばれる最上位のゾーン情報を提供する権威サーバのIPアドレスを手がかりとして、問い合わせを行い、適宜権威サーバをたどって必要なレコードを探します。フルサービスリゾルバが毎回このように他のサーバに問い合わせをしていると負荷や遅延の影響が問題となるため、得られた情報はしばらくキャッシュしておいて再び同じ問い合わせを受けた場合にはそのキャッシュから応答しています。最近はこの他にも家庭用ルータやファイアウォールなど、通信経路上の機器にもDNS関連の機能が実装されており、DNS問い合わせの中継や制御ポリシーの適用に関わっている場合があります。また、Webブラウザなど一部のアプリケーションでは独自の名前解決機能を実装している場合があり、OSの設定とは異なるポリシーで名前解決を行っている場合もあります。

ISPは接続種別に応じたPPPやDHCP、RA、PCOなどの通知手段を利用してフルサービスリゾルバのIPアドレスを利用者に伝え、利用者端末が名前解決用のネームサーバを自動設定できるようにしています。ISPは複数のフルサービスリゾルバを利用者に伝えられるほか、利用者は自身でOSやWebブラウザなどの設定を変更して利用するネームサーバを指定することもできます。端末に複数の名前解決用ネームサーバが設定されている場合、どれを利用するかは端末の実装やアプリケーションに依存するため、フルサービスリゾルバ側では利用者が総量としてどの程度の問い合わせを行っているか分かりません。このため、利用者側の挙動や状態が変わると、突然あるフルサービスリゾルバ向けの問い合わせが増えることも考えられるため、フルサービスリゾルバでは問い合わせ動向を注視しながら、常に処理能力に余裕を持たせた運用を心がける必要があります。

IIJが提供するフルサービスリゾルバの観測データを見てみると、利用者の利用傾向を示すように時間帯によって問い合わせ量が変動し、朝4時25分頃に問い合わせ元のIPアドレス当たり最小の0.15query/sec、夜21時50分頃にピークを迎えて0.32query/sec程度になっています。昨年に比べると、全般に0.02ポイント程度減少しています。問い合わせ傾向を通信に使われたIPv4とIPv6のIPプロトコル別に見てみると、昨年からはIPv6が+1ポイント程度増えており、IPv4を通信に使った問い合わせが全体の約59%、IPv6が約41%となっています。

近年の特徴的な傾向として、朝方の正時などキリの良い時刻に一時的に問い合わせが増加することが挙げられます。今年もこれまでと同様、朝6時や朝7時にそうした増加が見られました。午前6時と午前7時の14秒前と9秒前の問い合わせも前年同様増加している事が観測できました。これは近年見られている傾向で、正時に増加する問い合わせ量では急な増加後、緩やかに問い合わせ量が減っていくのに比べて、正時前の増加では急な増加の直後にそれまでの問い合わせ量程度に戻っています。つまり多くの端末が綺麗に同期して問い合わせを行っていることから、何かすぐに完了する軽量なタスクが実行されているのではないかと推測しています。一方で、今年はこうしたキリの良い時刻の増加量が今までと比べて減少しているほか、朝8時から夜22時までの正時には逆に問い合わせが減少して、そこから徐々に増加する傾向が観測できました。名前解決を利用している端末の実装に何らかの変更があったと推測しています。

問い合わせプロトコルに注目すると、UDPが98.438%でほとんどがUDPでの問い合わせになっています。ただ、TCPでの問い合わせは2021年が0.189%、2022年が0.812%、2023年が1.419%、2024年が1.561%であり、ここ数年TCPでの問い合わせ割合が増加してきています。主な増加要因として、DNS over TLS（DoT）での問い合わせが増えてきていることが挙げられます。DoTでは基本的にTCPの853番ポートを使って問い合わせをするため、DoTの利用が増えるとTCPの問い合わせが増えることになります。

問い合わせレコードタイプに注目すると、ホスト名に対応するIPv4アドレスを問い合わせるAレコードとIPv6アドレスを問い合わせるAAAAレコード、そしてWebサービスの解決に用いられるHTTPSレコードが全体の98%を占めています。AとAAAAの問い合わせ傾向は通信に利用されるIPプロトコルで違いが見られ、IPv6での問い合わせではより多くのAAAAレコード問い合わせが見られます。IPv4での問い合わせでは、全体の62%程度がAレコード問い合わせ、17%程度がAAAAレコード問い合わせです（図-2）。一方IPv6での問い合わせでは、全体の40%程度がAレコード問い合わせ、35%程度がAAAAレコード問い合わせです（図-3）。昨年と比べるとIPv4では+5ポイント、IPv6でも+2ポイント程度Aレコードの問い合わせ割合が増加しています。これに代わって、2020年から観測され始めたHTTPSレコードのDNS問い合わせが今回初めて減少傾向を示しました。IPv4で17%、IPv6で24%程度となっており、昨年と比べるとIPv4で-3ポイント、IPv6では-2ポイントと減少していました。クライアントの実装に何らかの変更があったことが考えられます。2022年から観測され始めたSVCBレコードは、IPv4で0.30%、IPv6では0.57%と、まだ全体に対する比率は少ないながらも順調に推移しています。これは、Discovery of Designated Resolvers（DDR）という、クライアントが暗号化に対応したフルサービスリゾルバを検出するための新しいプロトコル提案の実装が利用されているためと推測しています。

Theme 03 IPv6＆モバイル

今回もIIJバックボーンのIPv6トラフィック量、送信元AS、主なプロトコルについて見ていきます。また、モバイルサービスの端末OS別のIPv6接続状況などについても調査したいと思います。

トラフィック

IIJのコアPOP（東京3ヵ所、大阪2ヵ所、名古屋2ヵ所）のバックボーンルータで計測したトラフィックを図-4に示します。集計期間は2024年2月1日から9月30日までの8ヵ月間です。2024年のインターネットトラフィック量の期中の推移としては、IPv6、IPv4共に緩やかに減少傾向となっていました。昨年同日（グラフの薄い色の線）と重ねて比較すると、IPv6、IPv4いずれも昨年よりは増加しており、それぞれの前年比はIPv6が14.309%増、IPv4が14.505%増であり、ほぼ同じ増加率となっていました。

拡大する

図-4 IIJコアPOPのバックボーンルータで計測したトラフィック

図-5に、2024年2月1日を100として指数化したグラフを示します。先ほどご紹介したとおり、年初からのトラフィック量の推移としては微減かつ、IPv6もIPv4もほぼ同様の動きとなっています。

拡大する

図-5 2024年2月1日を100としたときの変動状況

次に、トラフィック全体に占めるIPv6の比率を図-6に示します。最小18.6%から最大22.5%ほどで推移し、期中の平均は20.16%となっています。大きなトレンドは見て取れず、昨年同時期とほぼ同等の比率となっていて、IPv6の伸びは小休止といったところでしょうか。

拡大する

図-6 トラフィック全体に占めるIPv6の比率

以下に2017年からのIPv6比率の推移を表-5に示します。これまでコロナ禍を除いて順調に伸びてきましたが、今年は昨年と同等の比率となりました。

拡大する

表-5 IPv6比率の推移（2017年〜）

送信元組織（BGP AS）

2024年2月1日から2024年9月30日までの、IPv6とIPv4のトラフィック送信元組織（BGP Source AS番号）の上位を図-7と図-8に示します。

IPv6では、IIJ内の配信などが6割以上を占めますが、IIJ以外のASについて見ていきます。まず昨年2位だった米検索大手のA社がトラフィック比率6%で1位となりました。2位は昨年1位だった日本の大手コンテンツ事業者のB社で比率は5%でした。今回1位と2位が入れ替わりとなりましたが、トラフィック量は拮抗しているので今後も再逆転があるかもしれません。3位は米クラウド事業者のC社で昨年の8位から上ってきました。一昨年は16位だったので、ここ数年大きくIPv6トラフィックを伸ばしているといえます。ただし、トラフィック比率は約2%と上位2社からは少し開きがありますし、4位以下もかなり拮抗しているので、今後も毎年のように順位は変わっていくものと思われます。

利用プロトコル

IPv6トラフィックのProtocol番号（Next-Header）と送信元ポート番号で解析したグラフを図-9に、IPv4トラフィックのProtocol番号と送信元ポート番号のグラフを図-10に示します。期間は2024年9月30日（月）から10月6日（日）の1週間です。

拡大する

図-9 IPv6トラフィックの送信元ポート解析

拡大する

図-10 IPv4トラフィックの送信元ポート解析

IPv6は、昨年同様HTTPS、QUIC、NAT Traversal、ESPと続き、これら上位4つのプロトコルで利用率91%を占めます。なお、HTTPSは74%、QUICは9%で、HTTP系プロトコルで8割以上となり、NAT-TとESPのVPN系プロトコルは8.4%でした。

トラフィック傾向は昨年と大きく変わりませんが、全体的に昼間のトラフィックが増えているように見えます。特にIPv6は土曜日曜の昼のトラフィックが増加しており、個人ユーザのトラフィックが大きな比率を占めるのではないかと推察しています。また、IPv4においてはUDP443がTCP80を上回り、非暗号化HTTPが減少しています。しかしほぼグラフでは見えないくらいの量しかないIPv6のHTTPと比べ、IPv4ではやっとQUICに追い越されたところで、まだまだ古いサーバが多いのではないかと考えられます。

モバイルのIPv6接続状況

一昨年の本レポートのVol.57（https://www.iij.ad.jp/dev/report/iir/057.html）及び昨年の本レポートのVol.61（https://www.iij.ad.jp/dev/report/iir/061.html）に続いて、今回も個人向け「IIJmioモバイルサービス」の接続における、IPv6有効化率を調査します。また、端末OS種別による違いと端末メーカによる違いの有無も見てみることにします。

IIJmioモバイルサービスに接続している端末のIPv6有効化率は60.6%でした。昨年は58.73%、一昨年は56.3%で、毎年2ポイント程度の増加となっています。端末OS別に見ると、Apple iOSのIPv6有効化率は87.010%、AndroidのIPv6有効化率は30.235%でした。AndroidのIPv6有効化率は昨年比較で5ポイントと大きく上昇していて、全体のIPv6有効化率増に寄与しています。

次に、IIJmioモバイルサービスに接続している端末の上位20位までのメーカ別IPv6有効化率を見てみます。図-11に上位20社のグラフを示します。日本ではApple製品を利用しているユーザが多く、53%以上のシェアとなっています。そしてAppleのIPv6有効化率は約87％と高く、昨年より若干有効化率が上がっています。なお、IPv6有効化率が最も高かった端末メーカはモトローラモビリティで、有効化率91.7%となっています。続いてAppleの87%、3番目はGoogleの86%となります。

拡大する

図-11 UEメーカIPv6有効化状況（上位20社）

今回注目したのは、IIJmio接続端末数では14位のFCNTです。今年新製品としてarrows we2などが発売となりましたが、arrows we2単体で見ると、IPv6有効化率は97.6%となっており、デフォルト設定でAPNプロファイルがPDP-Type IPv4v6になっていて、IPv6接続が有効になっているものと考えられます。ただし、同じFCNT製でも、MNO向け端末であるF-51Bは7.4%のIPv6有効化率で、FCNT製端末全体では31.2%に留まってしまいます。

まとめ

今回もIIJインターネットバックボーンコアのトラフィック、送信元AS、プロトコルについて紹介しました。トラフィック量は期中微減、昨年比約14%強の増加でした。IPv6の利用率はほぼ横ばいの20.16%で、今年は足踏み状態となりました。送信元ASで見るIPv6トラフィック量は1位と2位が逆転しましたが拮抗、3位以下もそれぞれ1〜2%で拮抗状態です。

利用プロトコルについては、これまで同様、IPv6の方が比較的新しく構築されたサーバが多いとみられ、暗号化HTTP系プロトコルが8割以上を占め、非暗号化HTTPは微量となっていますが、IPv4だと非暗号化HTTPはまだそれなりにある状態です。

モバイルについては、Android系OSの端末でIPv6有効化率が5ポイント上昇、全体として2ポイント弱の上昇となりました。また、新たに発売となった端末でAPN設定のPDP-Type設定でIPv6が有効化されているように見受けられます。今後もデフォルトでIPv6有効化された端末が増えていくことが望まれます。

引き続き様々な角度からIPv6の状況を観察しつつ、何か新しい発見がありましたら紹介したいと思います。

Theme 04 インターネットバックボーンのトレンド

IIJのインターネットバックボーンインフラの相互接続と経路の観点から昨今のインターネットバックボーンに関するトレンドを紹介します。

相互接続インタフェースのトレンドと要件

インターネット上で相互接続を行うには、インタフェースを事業者間で統一させる必要があります。現在、IIJでは相互接続のインタフェースとして主に400G-FR4、100G-LR4及び10G-LRを利用しています。ここ数年のトレンドとして、10Gのインタフェースを使った事業者間の相互接続を見直す動きがあります。事業者が相互接続を行う目的として、「トラフィック交換にかかる費用の削減」及び「効率化による通信品質の向上」が挙げられます。費用削減の観点では、相互接続に10Gのインタフェースを利用することがコスト的に見合わない状況になりつつあると想像されます。その主な要因として、事業者間のAS境界で利用される相互接続ルータの100Gポートあたりのコスト改善と10Gインタフェースの扱いづらさが挙げられます。相互接続ルータはIIJにおいても広帯域かつ高密度のものを要望・選定します。そういったルータで10Gのインタフェースを利用するとポートの利用効率が下がってしまいます。理由としては、100Gと10Gがポート構成上、排他的に利用される場合が多いためです。限りある物理インタフェースポートを10Gで利用すると100Gに比べて帯域が小さくなりますし、その分運べるトラフィック量が少なくなり、結果としてポートあたりの利用効率が下がります。また、相互接続ルータとして10Gから400Gインタフェースまで対応できるものを選定しようとすると100G/400Gのみ対応可能なルータに比べて機能や価格で満足できる選択肢が狭まることが多いです。

そのため、IIJでは10Gインタフェースの利用が必須ではない接続やLing Aggregationにより10Gの回線を複数束ねている接続、今後帯域を10G以上へ増速する可能性がある接続では、相互接続する相手に対して10Gから100Gのインタフェースへの増強をお願いしています。同様にIIJの相互接続先事業者からも今後は10Gの個別接続から、IXP経由の接続に変更する、もしくは100Gインタフェースへポート増強のリクエストを受けるようになっています。

図-12と図-13を比較して、IIJのインターネットバックボーンの直近1年間における相互接続インタフェースの割合の変化を見てみます。ここ1年で全体割合に対して10Gの利用が減少し、100Gのインタフェースの利用率が上昇していることが分かります。

100G以上の相互接続のインタフェース要件として、400Gインタフェースの利用が検討されていますが、利用に関してはまだ限定的な印象です。IXP事業者での対応は比較的進んでいる認識ですが、事業者間での相互接続においては大規模なトラフィックを持つ事業者以外はまだまだこれからの対応と思われます。

その他、新たなトレンドとして、100Gのインタフェースにおいて100G-LRの利用を推進する動きが見受けられます。100G-LRは現在広く使われている100G-LR4と比較して、1波長あたりの伝送容量が25Gから100Gへ増えた仕様です。レーザーの数が1個体あたり4から1へ減ったため個体あたりのコスト低下及び部品点数が減ったことによる故障率の低下がメリットとして挙げられます。現在欧米のIXPを中心として相互接続インタフェースに100G-LRの利用が始まっていて、今後は事業者間の相互接続にも利用されていくと予想されています。

RPKI関連の状況

RPKI関連の状況について確認してみましょう。自組織が保有するIPアドレスの正当性を署名として登録されるROAの状況をみてみます。インターネット上に公開されているNIST RPKI MonitorによるROAの当登録状況（図-14、図-15）^（注1）としては、インターネット上の全IPv4経路におけるValid（ROAが登録され、経路検証済）の割合が53.38%、Not-Found（ROAの登録がまだ実施されていないもの）の割合が46.15%、Invalid（ROAの登録状況に差異があり、不正経路と扱われるもの）の割合が0.47%であるようです。IPv6においてはValidが55.30%、Not-Foundが40.24%、Invalidが4.46%でした。IPv4におけるROAの登録の割合が50％を超えてきており、半数以上の経路で正当性が担保されている点についてはだいぶ進捗したように見て取れます。一方でIPv6はInvalid経路が4%以上ある状況です。ROAの登録はシンプルで、経路を生成・広告するOriginAS、PrefixとSubnet情報、広告する最大経路長（Subnetのサイズ）を登録します。いずれかのパラメータがROAと矛盾となるとInvalidとなってしまうため、検証目的ではない場合は是正が必要と思われます。現在、RPKI-ROVをAS境界のBGPピアで有効にしており、IIJへピアから広告される経路についてはROAに基づいたOrigin Validationを実行しています。Invalid経路については経路ハイジャックであるかどうかの見分けがつかないため、基本的には受け取らないようなポリシーで運用しています。

また、IIJがお客様の経路をトランジットしている割合を含めると、全経路の52.8%はROVでValidとして判定されています。日本国内においてもROAの発行が進んでいる状況が見て取れます。

1. （注1）参照：NIST RPKI Monitor（https://rpki-monitor.antd.nist.gov/）。

1. IIJインフラから見たインターネットの傾向 〜2024年

• Theme 01 BGP・経路数
• Theme 02 DNSクエリ解析
• Theme 03 IPv6＆モバイル
• Theme 04 インターネットバックボーンのトレンド