Internet Infrastructure Review（IIR）Vol.45
2019年12月20日

1. 定期観測レポート

IIJインフラから見るインターネットの傾向～2019年

IIJではインターネットサービスを提供するために、国内でも有数規模のネットワーク・サーバインフラを運用しています。ここでは、IIJのインフラ運用を通じて得られた情報を元に、現在のインターネットがどのような傾向を持っているのかを検討し、報告します。

取り上げるテーマは、ネットワークの経路情報、DNS問い合わせ情報、IPv6利用状況の他、モバイル・フレッツ接続サービスにおける自然災害の影響についても述べます。また、IIJのトラフィックの大部分を支えるバックボーンネットワークの歴史についても併せて紹介します。

Theme 01 BGP・経路数

最初にIIJ網から他組織に広報している「IPv4 フルルート」の情報を確認します（表-1）。今回は「IPv4 フルルート」に含まれるunique IPv4アドレス数の情報も追加しました（表-2）。なおこの1年の間にAPNIC（及びJPNIC）ではIPv4アドレス割り振りサイズの上限が/23（512アドレス）に縮小されています。

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

拡大する

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

拡大する

経路総数は昨年と比べて若干少ない増加となりましたが76万を超えました。/22-/24の3プレフィクスが経路総数に占める割合は80.1%になっています。一方でunique IPv4アドレス数は総数の1%未満ではありますが過去9年間で初めての減少となりました。RPKIによる不正経路排除の効果など一時的なものなのか、はたまた『IPv4インターネットの収縮』の始まりなのか、今後はこちらも注視したいと思います。

次に「IPv6 フルルート」の情報を確認します（表-3）。経路総数は昨年よりも大きな伸びを示し7万を超えました。ただし分割広報された経路が全体の過半数を占める状況は変わっておらず、割り振り/割り当てサイズとしてはあまり見ることのないプレフィクス長"/30-/31"、"/41-/43"、"/45-/47"が昨年からの増加率トップ3となっています。

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

拡大する

最後に「IPv4/IPv6 フルルート」広報元AS（Origin AS）数を確認します（表-4）。16-bit AS番号Origin ASの減少数、32-bit onlyAS番号Origin ASの増加数、共に過去9年間で最大となりました。またIPv6経路を広報するAS（"IPv6-enabled"）が全体の1/4を初めて超えました。RIPE NCCのIPv4アドレス在庫が2020年を待たずに完全に枯渇するとの予測も出ており、次回どうなるのか楽しみです。

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

拡大する

Theme 02 DNSクエリ解析

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

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

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

IIJが提供するフルリゾルバの観測データを見てみると、利用者の利用傾向を示すように時間帯によって問い合わせ量が変動し、朝4時半頃に問い合わせ元のIPアドレス当たり最小の0.05query/sec、昼12時半頃にピークを迎えて0.23query/sec程度になっています。この値は昨年とほぼ同様ですが、ピーク値が+0.01ポイントと若干上昇しています。問い合わせ傾向を通信に使われたIPv4とIPv6のIPプロトコル別に見てみると、深夜帯は大きな違いはなくほぼ同じ傾向を示している一方、人の活動する日中や特に20時以降では顕著にIPv6でIPアドレス当たりの問い合わせが増える傾向が見えています。家庭でIPv6が利用できる環境が整備されてきていることを示唆していると考えています。また全体の問い合わせ数で見ると、IPv6による問い合わせが、問い合わせ元IP数、実際の問い合わせ数共にIPv4よりも多くなっています。IPv6による問い合わせ数は増加傾向にあり、昨年は全体の55%、今年は4ポイント以上増えて、全体の約60%がIPv6による問い合わせとなっています。

近年の特徴的な傾向として、朝方の毎正時など切りの良い時刻に一時的に問い合わせが増加しています。問い合わせ元数も同時に増えているため、利用者の端末でタスクをスケジュールしたり、目覚まし機能などで端末が起動することに伴う機械的なアクセスが増えたりといったことが原因だと推測できます。昨年は毎正時の14秒前に問い合わせが増加していましたが、今年はそれに加えて毎正時の10秒前にも問い合わせが増加しています。毎正時では増加後、緩やかに問い合わせ量が減っていくのに比べて、毎正時の14秒前と10秒前の増加ではすぐにそれまでの問い合わせ量程度に戻っています。つまり多くの端末が綺麗に同期して問い合わせを行っていることから、何かすぐに完了する軽量なタスクが実行されていると考えられます。

例えば接続確認や時刻同期など基本的なタスクを本格的なスリープ解除前に終わらせるような機構があり、これに利用されている問い合わせが影響していると予想しています。

Theme 03 IPv6

ここではIIJバックボーンのIPv6トラフィックの流量、流入元、主なプロトコルについて報告します。また、モバイルにおけるIPv6に関する新たな切り口として、端末OS（Apple iOS/Android）の違いによるIPv6接続状況についても解説します。

トラフィック

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

拡大する

図-3 IIJのコアPOP（東京・大阪・名古屋）のバックボーンルータで計測した、IPv4トラフィックとIPv6トラフィック

IPv4のトラフィックはこの1年で約8%増加、IPv6のトラフィックは1年で約85%増加しました。全トラフィックに占めるIPv6の割合（図-4）は、約10%となり、昨年の約6%から4ポイント増加しています。また、IPv6トラフィックの割合のピークは約12%を記録しており、IPv6トラフィックが占める割合は着実に増加しています。

拡大する

図-4 全トラフィックに占めるIPv6の割合

図-5は同じ期間をログスケールで描画したものです。IPv4トラフィックの伸びが鈍化している中、IPv6トラフィックは着実に伸びてきているのが分かります。

拡大する

図-5 IIJのコアPOP（東京・大阪・名古屋）のバックボーンルータで計測した、IPv4トラフィックとIPv6トラフィック（ログスケール）

送信元組織（BGP AS）

利用プロトコル

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

拡大する

図-8 IPv6トラフィックのProtocol番号（Next-Header）と送信元ポート番号で解析したグラフ

拡大する

図-9 IPv4トラフィックのProtocol番号と送信元ポート番号で解析したグラフ

IPv6において、前回3位だったTCP80（HTTP）が2位になり、UDP443（QUIC）が3位になりました。これは、IPv4と同じ並びになったということで、IPv6の使われ方がIPv4同様の傾向になってきた、あるいは一般的になったといっても良いでしょう。

なお、前回はランキング外だったUDP4500が5位に入っています。IPv6ではNATは基本的に使われないはずですが、NATトラバーサルIPSec用として一般的に使われているUDP4500が上位に入っていることは興味深いところです。

モバイル端末OSの違いによるIPv6接続状況について

前回、「Apple iOSのバージョン11から、IPv6接続がデフォルトで有効化されたので、モバイルのIPv6トラフィックが増加した」ということを報告しました。

今回はモバイル端末のIMEI （International Mobile Equipment Identity）を解析し、OS種別（iOSかAndroidか）とIPv6接続しているかどうか（IPv6アドレスが割当られているかどうか）を分析してみました。

解析対象は個人向けモバイルサービス（IIJmioモバイルサービス）の約107万回線（2019年6月末時点の契約回線数）で、2019年10月の平日のとある日に接続中だったものです（MVNEとしての回線や法人契約回線は含みません）。

まとめ

IPv6のトラフィック量、利用プロトコル、そしてモバイル端末OS別のIPv6接続数について見てきました。IPv4トラフィックの伸びが鈍化する中、IPv6トラフィックは前回同様の伸びを示しており、IPv6の利用が更に進んでいることが分かりました。最近発売される家庭用Wi-Fiルータの多くはIPv6 IPoE対応を謳っていますし、動画配信サービスにおいてもIPv6の有効化の動きがありますので、今後更にIPv6トラフィックは増えていくのではないかと思われます。

モバイルサービスにおいては、IPv6が有効となっている接続が半数近くあり、想像以上にIPv6が有効になっていました。トラフィックはまだまだ全体の2割程度ですので、今後サービス側のさらなるIPv6対応を期待したいと思います。

Theme 04 モバイル・フレッツと自然災害

本来であればフレッツ及びモバイルの定点観測として傾向の変化を報告するところですが、本レポートのVol.44（https://www.iij.ad.jp/dev/report/iir/044/01.html）の「1. 定期観測レポート」でほぼ同様の内容が報告されていますので、ここでは自然災害が及ぼす影響について考察します。

2019年は自然災害が多く発生した年でした。特に、先日の令和元年台風第19号（以下、台風19号）の際は各地で甚大な被害が発生しました。IIJのバックボーンでも東京-大阪間を接続する基幹回線が複数本、長期間に渡り切断されました。経由する長野県で道路が流され、埋設されていた光ファイバーが物理的に破損したことによるものです。破損した区間が長く、復旧には数週間を要しました。幸い、IIJのバックボーンではこのような災害などによる障害を想定してネットワークを設計しており、東京-大阪間においては太平洋側、日本海側、内陸にルート分散しているため、ユーザの通信に実影響が及ぶことはありませんでした。

一方、モバイル及びフレッツといったユーザの利用に直結するアクセスサービスでは台風19号の影響が如実に見られました。それについてデータを見ながら考察します。なお、ここでのフレッツはPPPoEのみを指すものとします。

図-13から図-24は、台風19号が本州を通過した2019年10月12日前後及び対比のため1週間前の2019年10月5日前後の接続数とトラフィック量（アップロードとダウンロードの合計）の推移を表したグラフです。いずれも、金曜日（2019年10月4日、2019年10月11日）00:00の値を1として正規化しています。

まずは接続数に着目してみます。現在、フレッツの利用者の多くはブロードバンドルータやホームゲートウェイを介した常時接続のため、通常は1日を通じて接続数の変化はほとんどありません。実際、台風19号の影響がほとんどなかったフレッツ大阪エリアでは、期間中の接続数の変化はごくわずかでした。

しかし、影響の大きかったフレッツ千葉、福島、宮城エリアでは2019年10月12日から2019年10月13日にかけて接続数の低下が見られます。特にフレッツ千葉エリアでは大幅に低下しています。これらの地域では停電が多く発生しており、各家庭にあるブロードバンドルータやホームゲートウェイが停電により停止したことによるものと考えられます。一方、モバイルについてはMVNO設備の特性上、端末がどこに在圏しているかを把握することができないため全国での集計となりますが、2019年10月12日から2019年10月13日にかけて接続数の低下が見られます。MNOの設備にも被害が及んだ影響、もしくは外出を控えてモバイルを利用しなかったことによる影響と考えられます。

次にトラフィック量について見てみます。トラフィック量は東京以北の各フレッツエリアで2019年10月12日の日中に増加し、逆にモバイルでは大きく低下しています。週末でしたが、荒天のため外出を避け、自宅でモバイルではなくフレッツを使いインターネットを利用するユーザが多かった影響と考えられます。

今やインターネットは電気、ガス、水道に次ぐ重要な社会インフラとなっており、自然災害時こそ真価を発揮します。今後もIIJでは自然災害による影響も十分考慮しながらバックボーンを設計し、いつでも安心して使えるインターネット基盤を提供していきます。

Theme 05 IIJバックボーンの歴史

2018年のこの記事で、IIJのバックボーンの総トラフィックが10年で10倍以上になっていることを紹介しました。今回はIIJのバックボーンの歴史、特に回線品目について振り返ってみたいと思います。

IIJは特別第二種電気通信事業者としてISP事業をスタートしました。そのためサービス開始当初から第一種電気通信事業者が設置した通信回線を借りて通信網を構築し、サービスを提供してきました。第一種/第二種という区分が廃止された現在でも、この点は基本的に変わっていません。

今、手元に1998年当時のバックボーンマップが残っています。当時利用していた回線は、45MbpsのDS-3が大部分で一部に155MbpsのSTM-1が利用されていました。1998年以降、刻々とバックボーンが増強されていく様子がバックボーンマップに残っています。しばらくはおおむね2年おきに4倍の帯域の回線/ルータのインタフェースがリリースされる状況が続きます。2000年に600Mbps（STM-4）、2002年に2.4Gbps（STM-16）、2004年に9.6Gbps（STM-64）と次々に拡張されていきます。今振り返ってみればトラフィックの増加に合わせて回線も太くなっていく幸せな時代でした。もっと大きな規模のISPは事情が異なったかも知れませんが、IIJの規模ではネットワークのトポロジーを大きく変えずに回線を入れ替えていけばトラフィックの増加におおむね追従できていました。

次のグラフはバックボーンマップから、日米区間のバックボーンの帯域と、バックボーンの中で利用できた最も太い回線品目をプロットしたものです。1998年から2004年のSTM-64を利用開始するまでは回線は帯域を順調に広げています。しかし2005年以降、2014年までおよそ9年もの間、STM-64以上の回線が普及しませんでした。STM-256が今一つ普及しなかったり、その上の100Gが技術的に困難で開発/規格化が大きく遅れたなど、いろいろと事情はありました。しかし、その間もトラフィックは増え続け、ついには200Gbpsの帯域、STM-64の回線を20本確保しなければならないところまで至ってしまいました。（先のグラフの縦軸は対数ですよ!!）

このため、この間のIIJでのバックボーン構成は非常に大きく変化しました。回線の利用効率を上げるため、ECMP（Equal Cost Multi Path）が効きやすいようにネットワークトポロジーを変更したり、MPLSで回線を仮想化するレイヤーを作りIPバックボーンの構成の自由度を上げたりといったようにです。

2014年に100G Ethernetが普及すると状況はいったん落ち着きました。IIJも昨年、主要なバックボーン区間の100G化が完了し、トラフィック増に応じてリーフの100G化を行っているところです。一方で、この12月には日米間に6本目の100G回線が上がる予定になっています。100Gも普及を始めてから5年が経ち、そろそろ一段太い回線が欲しくなってきました。400Gの足音が少しずつ大きくなってきているようです。

IIJでは引き続き、最新の技術動向を追いかけながら効率の良い快適なバックボーンを拡大していきます。

拡大する

図-25 回線品目と日米間帯域

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

• Theme 01 BGP・経路数
• Theme 02 DNSクエリ解析
• Theme 03 IPv6
• Theme 04 モバイル・フレッツと自然災害
• Theme 05 IIJバックボーンの歴史