ページの先頭です


ページ内移動用のリンクです

  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review(IIR)
  5. Vol.49
  6. 1. 定期観測レポート IIJインフラから見たインターネットの傾向~2020年

Internet Infrastructure Review(IIR)Vol.49
2020年12月25日
RSS

目次

1. 定期観測レポート

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

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

Theme 01 BGP経路

最初に、IIJ網から他組織に広報している「IPv4フルルート」の情報(表-1)及び「IPv4フルルート」に含まれるunique IPv4アドレス数の情報(表-2)を確認します。なおこの1年の間にRIPE NCC及びLACNICのIPv4アドレス在庫が完全枯渇を迎えています。残るはAPNICとAfriNICですが、APNICは既に2021年初めの完全枯渇予測が出ており、またAfriNICでは2020年1月から割り振り/割り当てサイズに上限(/22)が設けられています。

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

表-2「IPv4フルルート」に含まれる unique IPv4アドレス総数の推移

経路の増加数には2018年をピークに減少傾向が見えますが、総数は80万を超えました。/22の経路数も10万超となりましたが/22-/24の3プレフィクスが経路総数に占める割合は80.9%と微増に留まっています。一方でunique IPv4アドレス数は、2011年以降で初の減少となった昨年(2019年)よりは増加したものの、まだ2018年及び2017年の値を下回っています。こちらも2018年がピークとなるのか、今後の推移に注目したいと思います。

次に「IPv6フルルート」の情報を確認します(表-3)。なお2019年11月にはARINに対して/12ブロックの最初の追加割り振りが行われています(同6月のRIPE NCCに続いて2番目)。

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

経路総数は昨年とほぼ同じ伸びを示し9万を超えました。来年10万超となっているのは間違いないと思えます。また総数の50.0%、増加数の58.1%は/48の経路であり、エンドサイトへのIPv6導入も順調に進んでいるものと推測されます。

最後に「IPv4/IPv6フルルート」広報元AS(Origin AS)数を確認します(表-4)。なおこの1年の間に、RIPE NCCに3072、LACNICに2048の32-bit only AS番号が追加割り振りされています。

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

16-bit AS番号Origin ASの減少及び32-bit only AS番号Origin ASの増加は共に昨年と同程度あり、Origin AS総数の4割を32-bit only ASが占めるに至っています。またIPv6経路を広報するAS("IPv6-enabled")は全体の28.1%と順調に増加しています。来年は3割を大きく超えてくるか否か、こちらも注目したいと思います。

Theme 02 DNSクエリ解析

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

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

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

IIJが提供するフルリゾルバの観測データを見てみると、利用者の利用傾向を示すように時間帯によって問い合わせ量が変動し、朝4時半頃に問い合わせ元のIPアドレス当たり最小の0.06query/sec、昼12時半頃にピークを迎えて0.24query/sec程度になっています。この値は昨年とほぼ同様ですが、早朝から日中体に掛けて+0.01ポイントと若干上昇しています。

問い合わせ傾向を通信に使われたIPv4とIPv6のIPプロトコル別に見てみると、昨年と比較してIPv4でのIPアドレス当たりの問い合わせが減っています。深夜帯に大きな変化はありませんが、日中帯や夕方夜間に渡って最大-0.03ポイント減少しています。一方でIPv6では、IPアドレス当たりの問い合わせは深夜帯も含めた全時間帯で+0.03ポイント前後増えています。これはIPv6対応した機器が家庭などに徐々に導入されたり、既存機器が置き換えられたりしていることを示唆していると考えています。また全体の問い合わせ数で見ると、IPv6による問い合わせが、問い合わせ元IP数、実際の問い合わせ数共にIPv4よりも多くなっています。IPv6による問い合わせ数は増加傾向にあり、昨年は全体の60%、今年は3ポイント増えて、全体の約63%がIPv6による問い合わせとなっています。

近年の特徴的な傾向として、朝方の毎正時などキリの良い時刻に一時的に問い合わせが増加しています。問い合わせ元数も同時に増えていますし、特に朝7時に顕著に傾向が見られるため、利用者の端末でタスクをスケジュールしたり、目覚まし機能などで端末が起動することに伴う機械的なアクセスが原因ではないかと推測しています。昨年は毎正時の14秒前と10秒前に問い合わせが増加していましたが、今年はそれに加えて毎正時の20秒前にも問い合わせが増加しています。毎正時では増加後、緩やかに問い合わせ量が減っていくのに比べて、毎正時前の増加では直ちにそれまでの問い合わせ量程度に戻っています。つまり多くの端末が綺麗に同期して問い合わせを行っていることから、何かすぐに完了する軽量なタスクが実行されているのではないかと推測しています。例えば接続確認や時刻同期など基本的なタスクを本格的なスリープ解除前に終わらせるような機構があり、これに利用されている問い合わせが影響していると考えられます。

問い合わせレコードタイプに注目すると、ホスト名に対応するIPv4アドレスを問い合わせるAレコードとIPv6アドレスを問い合わせるAAAAレコードがほとんどを占めています。AとAAAAの問い合わせ傾向は通信に利用されるIPプロトコルで違いが見られ、IPv6での問い合わせではより多くのAAAAレコード問い合わせが見られます。IPv4での問い合わせでは、全体の79%程度がAレコード問い合わせ、15%程度がAAAAレコード問い合わせです(図-1)。一方IPv6での問い合わせでは、全体の51%程度がAレコード問い合わせ、41%程度がAAAAレコード問い合わせとAAAAレコード問い合わせの比率が高まっています(図-2)。昨年と比べるとIPv4で5ポイント、IPv6で3ポイント程度Aレコードの問い合わせが減っています。今年は新しく実装されたばかりのHTTPSタイプのDNS問い合わせがIPv4で2%、IPv6で6%程度を占め、AとAAAAに次ぐ問い合わせ量になっています。この問い合わせは現状でApple社のiOS 14などがサポートしているようで、今後実装が広がるに連れて徐々に増加すると予想しています。

図-1 クライアントからのIPv4による問い合わせ

図-2 クライアントからのIPv6による問い合わせ

Theme 03 IPv6

ここではIIJバックボーンのIPv6トラフィックの流量、送信元AS、主なプロトコルについて見ていきます。

トラフィック

昨年同様、IIJのコアPOP(東京・大阪・名古屋)のバックボーンルータで計測した、IPv4トラフィックとIPv6トラフィックを図-3に示します。期間は2019年10月1日から2020年9月30日までの1年間です。

図-3 IPv4トラフィックとIPv6トラフィック(2019年10月〜2020年9月)

2020年は、年初からのCOVID-19(新型コロナウイルス)の影響もあり、昨年までとは異なったトラフィック傾向が観測されています。2020年2月くらいまでは大きな変化は見られなかったのですが、3月以降、COVID-19による休校や緊急事態宣言に伴う外出自粛が始まると、IPv4トラフィックが大きく伸びる結果となりました。本レポートのVol.48(https://www.iij.ad.jp/dev/report/iir/048.html)で触れられているように、モバイル系トラフィックは自粛期間中は減少し、固定系ブロードバンドサービスや法人VPNサービスが増加することとなり、それに伴いIPv4トラフィックが伸びたと考えられます。

今回は計測期間中の増減を相対的に把握するため、計測開始日(2019年10月1日)のIPv4、IPv6それぞれのトラフィックを1として正規化したグラフを作成(図-4)してみました。グラフ中程の4月から5月あたりが緊急事態宣言による外出自粛期間ですが、この期間はIPv4トラフィックが約8%増え、IPv6トラフィックは減少しているように見えます。緊急事態宣言終了後はIPv4トラフィックの増加は落ち着き、計測開始時と比べると微増、IPv6トラフィックも最終的には微増となっています。

図-4 期初を1とした場合のIPv4トラフィックとIPv6トラフィックの増減

IPv6が全体に占める比率は、図-5のとおり、緊急事態宣言中は低下しているが、最終的に期初と同じくらいの比率に戻る結果となりました。

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

送信元組織(BGP AS)

次に、2019年10月から2020年9月までの1年間の、IPv6とIPv4の平均トラフィック送信元組織(BGP AS番号)の上位を図-6と図-7に示します。

図-6 IPv6の平均トラフィック送信元組織(BGP AS番号)別占有率

図-7 IPv4の平均トラフィック送信元組織(BGP AS番号)別占有率

やはり最上位はA社ですが、占有率は前回比で5ポイント下がりました。大きく伸びているはIIJのAS番号を送信元に持つトラフィックで、計測点による特殊事情もあるかもしれませんが、昨年同様JOCDNプラットフォームの動画配信トラフィックでIPv6が伸びていることが主要因と考えられます。その他は特に大きな動きは観測されず、目立った傾向はありませんでした。

利用プロトコル

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

図-8 IPv6トラフィックのProtocol番号・送信元ポート番号別推移

図-9 IPv4トラフィックのProtocol番号・送信元ポート番号別推移

IPv6の1位はTCP443(HTTPS)、2位はUDP443(QUIC)となっており、HTTP系暗号化プロトコルで8割を超えるほどです。今回特徴的なのはTCP80(暗号化なしHTTP)が4位に落ち、ESP(IPSec暗号化)が3位に入ってきていることでしょうか。ESPは平日日中帯により多く観測されており、土日は少ないことから、企業ネットワークにおいて、IPv6 VPNの利用が増加しているものと思われます。平日昼の最も多い時間帯に全体の19%程を占めており、日中はQUICを逆転する程です。なお、グラフで見て取れるのは5位までであり、6位以下は量が少なく、グラフで確認することが困難なほどの量しかありません。

IPv4については利用プロトコルに大きな変動はないようですが、夜のピークトラフィックが若干減り、日中のトラフィックが全体的に増加しているように見えます。リモートワーク(在宅勤務)によって日中自宅で仕事をする人が増え、日中トラフィックが増えた、もしくは、転送量のピークが早い時間にシフトしているように思えます。また、平日のグラフの形(1〜5番目の山)と土日の形(6、7番目の山)が非常に似た形となっており、平日と休日のトラフィック傾向に差が少なくなってきているようです。

まとめ

IPv6のトラフィック量、送信元AS、利用プロトコルについて見てきました。今回はCOVID-19の影響もあり、これまでとは違った傾向が見られました。IPv6トラフィックの割合については、最終的には前回と大きく変わらない利用率でしたが、途中外出自粛の影響が見られました。IPv6の利用プロトコルやIPv4のトラフィックの山など、リモートワーク(在宅勤務)の影響と思える新たな動きも見られました。

COVID-19の流行については、まだまだ収束の気配を見せていません。ウィズコロナやアフターコロナと言われる世の中において、IPv6が、またインターネットの利用形態がどのように変化していくのか、引き続き見ていきたいと思います。

Theme 04 モバイル 3G、LTEの状況

今年はモバイルのトラフィック傾向に関しては、本レポートのVol.48(https://www.iij.ad.jp/dev/report/iir/048.html)で触れているとおり例年とは異なり、新型コロナウイルスの影響による外出自粛期間中に大きく落ち込みました。また、モバイルの世界では“5G”という言葉が世の中に広く知られる状況になり、MNO各社が5Gのサービスを開始し、IIJでも法人向けに提供しているIIJモバイルサービスにおいてau 5Gに対応したサービスを10月30日から提供開始しました。新しい規格の仕組みが世の中に浸透していく一方で、古い規格は終息に向かっていく現状もあります。2019年10月にNTTドコモが3G通信サービス「FOMA」を2026年3月末で終了すると発表しました。

今回はIIJで提供しているモバイルサービスにおける3Gトラフィックの傾向について解説します。対象期間は2019年10月1日から2020年9月30日です。

全体トラフィックにおける3Gの割合は図-10のとおりです。

図-10 全体トラフィックにおける3Gの状況

コンシューマ向けサービスでは0.5%以下の状況になっていますので3Gはほぼ利用されていないと言えます。それに対して、法人向けサービスでは平均で8%程度のトラフィックが3Gとなっており、法人ユーザ様では3Gが根強く利用されていることが分かります。

次に、2019年10月1日を基準日としたときのコンシューマ向けサービスのトラフィック量(図-11)とセッション数(図-12)に関する傾向をグラフに示します。コンシューマ向けサービスの3Gトラフィックに関してはトラフィック量、セッション数共に右肩下がりとなっており、ここ1年間でトラフィック、セッション数共に40%程度減っています。要因はいろいろと考えることができますが、コンシューマサービスの接続端末はほぼスマートフォンであることを考えると、世間でのLTEの接続環境が向上しており、3Gに落ちることが少なくなっていることが考えられます。今後どのような推移を見せていくかは確認していきます。

図-11 コンシューマ向けトラフィック量の傾向

図-12 コンシューマ向けセッション数の傾向

コンシューマ向けサービスのLTEのトラフィック量については、セッション数ではほぼ横ばい状態でしたが、トラフィック量に関しては2020年3月から5月にかけて一時的に3割減という状態になりました。こちらはコロナ禍での自粛期間中の落ち込みと考えられます。

次に、同じ2019年10月1日を基準日としたときの法人向けサービスのトラフィック量(図-13)とセッション数(図-14)に関する傾向を見てみます。

図-13 法人向けトラフィック量の傾向

図-14 法人向けセッション数の傾向

法人向けサービスの3Gトラフィックに関してですが、セッション数は断続的に減少傾向となっています。これは3Gサービス終了を見越して、3GからLTEへの移行などが進められていることが要因の1つと考えられます。また、2019年10月から“2020年4月まで”と“2020年5月以降”では減少の傾きが緩やかになっていますが、これはコロナ禍の影響によって移行などのスピードが緩やかになったことが1つの要因と考えられます。それに対して3Gのトラフィック量はコロナ禍の影響もなく緩やかな増加傾向が見られます。この点については法人ユーザ様の利用状況に依存することがあるため、今後の状況を注視していこうと思います。

また、LTEのトラフィック傾向ですが、セッション数では3Gと同様に自粛期間中の落ち込みはあるものの、断続的な増加傾向にあります。またトラフィック量に関しても自粛期間である2020年4月〜5月を底として、いまは徐々に戻ってきている状況にあります。

最後に、5Gの状況に関してです。最初に申し上げたとおりIIJでは10月30日からau 5Gを利用した法人サービスをリリースしました。そのため、トラフィック傾向などはまだ分析できる状況ではないのですが、IIJユーザ様がどの程度5Gに対応した端末を利用しているか調べてみました。

図-15のグラフは、「端末名に5Gと入っているAndroid端末」と「iPhone12シリーズ」という5G対応と思われる端末が2019年10月1日を基準日としたときの増加率を示したものです。iPhone12がリリースされる前までは1年間で40倍程度の増加でしたが、リリース後には1年前の約400倍(リリース直前に比べ約10倍)に増加しています。今後は5Gサービスに関するトラフィック傾向にも注視していきたいと思います。

図-15 5G対応端末の接続状況

Theme 05 IIJバックボーンにおけるBGP ROV導入

IIJでは2020年の11月以降、インターネットバックボーンにおけるRPKIを利用したBGP ROV(Route Origin Validation)を順次導入していきます。

RPKIなどの導入や仕組みについては、導入前にエンジニアブログでも紹介していますので、併せて参照ください。RPKIで利用するROAの発行数などの推移はRIPEやNISTなどで確認できます。RPKI自体は2008年頃からRIRで利用されており、JPNICでも2015年には登録が開始できるようになっています。ROA数はRIPEが随分と先行していますが、ここ数年は他のRIRのROAも非常に増加しており、活用が着々と進んでいる状況にあるようです。

今回は、IIJでBGP ROVを適用する前の2020年10月の特定の日における情報を抽出しています。表-5は、2020年10月のIIJのROAキャッシュサーバから特定の日のVRP(Validated ROA Payloads)をエクスポートしたデータから作成しています。ROAには、自組織が広告するprefixと、自組織を示すoriginとなるAS、そして該当のprefixを最大どこまでのprefix長で受け入れるのかを示すmax lengthがセットで登録されています。BGP経路に対するROA登録アドレス数の割合は、IIJの特定の日時のBGP経路数のUniqueアドレス数に対するROAの登録prefixの割合を示しています。

表-5 IIJ ROAキャッシュのVRPの情報

次に、ROAに登録されているprefix長とmax lengthの分布を図-16、図-17に示します。

図-16 登録されているprefix長とmax lengthの分布(IPv4)

図-17 登録されているprefix長とmax lengthの分布(IPv6)

横軸は、prefix長で、縦軸は登録数を示しています。棒グラフがROAに登録されているprefix長で、ポイントで表示してあるのが最大で受け入れるprefix長であるmax lengthとなります。登録prefix長とmax lengthの値が同じに設定してあるものは、IPv4で81.6%、IPv6で78.7%程度です。一方でmax prefixの方が長く設定してあるものは、IPv4は/24、IPv6は/48が多い傾向となっており、インターネットにおいて組織間でBGP経路を交換する際のトレンドと同じような状況であると推察します。

図-18、図-19は、上記で利用したVRPのデータを元にIIJの特定地域のBGP経路をValidationするとどの程度invalidな経路が存在するかを調査したものです。

図-18 特定ルータのBGP経路のValidation結果の推察(IPv4)

図-19 特定ルータのBGP経路のValidation結果の推察(IPv6)

Validとして判定されるのは、IPv4では24%、IPv6では29%程度であり、Invalidとして判定されるものは、IPv4では0.32%, IPv6では0.49%程度となりました。ROAに合致するprefixがないものはNotFoundとして示されており、全体の7割がそれにあたります。今後ROAの登録がすすむにつれて、NotFoundの割合は少なくなっていくと期待しています。また、Invalidな経路であっても、より大きい空間がValidやNotFoundとして判定されるケースがあるため、Invalidな経路として判定されたとしても、必ずしも到達性がなくなるわけではありませんが、そうでない経路も存在しており、IPv4の0.028%、IPv6の0.02%程度がそれにあたります。

インターネットは常に変化しているため、設定ミスや不具合による様々な経路の問題の脅威に常にさらされている状況です。こうした経路が正当であるかどうかも判断に困るものが多数であるため、未然に防ぐことは非常に難しい状況でしたが、それが今回の取り組みを行うと同時にRPKIが浸透していくことによって、未然に一部の脅威を防ぐ可能性が高くなっていくことにつながります。

IIJでは今後もより快適なインターネット社会を支えるため堅牢なインフラの提供に向けた取り組みを実施していきます。

執筆者プロフィール

1.BGP経路

倉橋 智彦(くらはし ともひこ)

IIJ 基盤エンジニアリング本部 運用技術部 技術開発課

2.DNSクエリ解析

松崎 吉伸(まつざき よしのぶ)

IIJ 基盤エンジニアリング本部 運用技術部 技術開発課

3.IPv6

佐々木 泰介(ささき たいすけ)

IIJ 基盤エンジニアリング本部 ネットワーク技術部 副部長

4.モバイル 3G、LTEの状況

齋藤 毅(さいとう つよし)

IIJ 基盤エンジニアリング本部 ネットワーク技術部 モバイル技術課長

5.IIJバックボーンにおけるBGP ROV導入

津辻 文亮(つつじ ふみあき)

IIJ 基盤エンジニアリング本部 ネットワーク技術部 ネットワーク企画課長

1. 定期観測レポート IIJインフラから見たインターネットの傾向〜2020年

ページの終わりです

ページの先頭へ戻る