Internet Infrastructure Review（IIR）Vol.58
2023年3月22日

4. フォーカス・リサーチ（3）

IIJバックボーン30年間の変遷

4.1 はじめに

1993年、ルータ数台から始まったIIJバックボーンも今では数千台に及ぶネットワーク機器から成る大規模なネットワークへと進化してきました。その過程においては通信技術や経路制御技術、はたまたルータのハードウェア性能限界や電源事情等々、インターネットの急激な成長に追い付かず各種課題を抱えながらも、安定したインターネット環境を提供するため知恵と工夫により辛うじて乗り切ってきた日々であったように思います。

この章の前半では、IIJバックボーンがどのような経緯・理由でどのように変化してきたのか、またどのような工夫を加えたのか時代背景を交えつつ紹介していきたいと思います。また後半では、これまでにIIJが行ってきたネットワーク運用に係るセキュリティ対策を取り上げます。

4.2 IIJバックボーンの変遷

4.2.1 1993～2002年 黎明期（リソース不足との戦い）

インターネットが学術利用から商用利用へと移り変わろうとしている頃は、まだまだインターネットに対する認知度が低く接続するための環境（注1）も十分に整っていない中で利用料金も高額（注2）であったことから、トライアル的な利用が主流でした。

黎明期における物理構成の変遷

シングル構成のまま拡張を続けたIIJバックボーンですが、1999年頃からインターネット上での金融取引が始まるなど、企業でもネット活用が一般化するにつれインターネットに求められる品質がより厳しくなり始め、耐障害性向上への取り組みが本格的にスタートします。まずは主要なPOPから回線及び機器の冗長化を開始し、2002年頃には完全冗長化を終えました。

拡大する

図-2 バックボーンの拡張

【こぼれ話】

2002年冬、福岡POPにおいてバックボーン回線を2重化していたにも関わらず両回線が切断し孤立させてしまう障害を起こしてしまいます。原因は同一ファイバールートになっていた一部区間においてファイバーケーブルに侵入した水が凍り損傷させたというものでした。これを教訓にバックボーン回線の異ルート化を取り入れました。

黎明期における経路制御の変遷

【こぼれ話】

当時、経路数の増加量は深刻な問題でした。シャーシ型のルータではモジュール式のI/Fカードでもメモリが逼迫寸前だったこともあり数百枚分に及ぶカードへのメモリ増設を深夜作業で実施し機能不全に陥る状況を回避していました。

【こぼれ話】

ルータのCPUが非力なため、OSPFのバックボーンエリアに存在可能な台数は50台程度と業界ではささやかれていました。これを受けIIJバックボーンにもOSPFのエリア分けを導入しますが、運用の難易度が飛躍的に高くなってしまい、事故も幾度か発生しました。幸いハードウェアの進化もありエリア分けは撤廃していますが、シンプルな構成が一番であると思わせる最たる例だと感じています。

様々な組織が管理・運営するネットワークの集合体であるインターネットでは、ミスオペレーションによる意図しない経路ハイジャックも稀に起こります。場合によってはインターネット全体に影響を及ぼすような事態にもなりかねず、他ASとのルーティング情報の送受信には細心の注意が必要です。IIJでは、IIJ自身も含め、ユーザが加害者にならないよう早い時期から全エッジルータで経路フィルタを導入していました。

初期はアクセスコントロールリストとAS-PATHフィルタの組み合わせにより制御を行っていましたが、新たなCIDRブロックやプロバイダ非依存アドレスなどの追加のたびに全エッジルータの経路フィルタを更新する必要があり、非常に煩雑で手間がかかっていました。そこでBGP Communities Attribute （RFC1997）の導入に踏み切ります。活用方法は至って簡単で、経路流入元や経路生成元でBGP communityを付加しバックボーン内部に伝搬させエッジルータでBGP communityを元に広報経路の制御を行うというものですが、経路制御が格段に容易になり設定変更箇所が大幅に減ることで安定運用にもつながりました。

以上のように黎明期においては各種技術も発展途上にありインターネットの成長速度に追い付かない状況の中、リソース不足との戦いでもあり試行錯誤をしながら基礎を固めていった時期になります。

4.2.2 2003～2006年 普及期（品質向上とIPv6展開）

インターネットの利用が広がるにつれ、求められる品質も上がっていきました。2000年頃からバックボーンは順次冗長化されていき、長時間の断はほとんどなくなっていたものの、経路変化によるパケットロスが課題となりました。

インターネットにおける経路制御では、障害時に通信が自動的に迂回できるようにBGPやOSPFなどのダイナミックルーティング（動的経路制御）が利用されています。このダイナミックルーティングで、ネットワークの変化がルーティング情報としてネットワーク全体に伝搬され、それを受け取ったルータそれぞれが独自にルーティングテーブルを生成することで、ネットワーク全体が矛盾なく正常に通信できる状態を維持しています。この一連の動作による状態変化が収束（コンバージェンス）することをルーティングコンバージェンスと呼び、コンバージェンスに至るまでの時間（コンバージェンスタイム）がネットワークの品質性能を測る1つの要素となっています。

コンバージェンスに至るまでの状態変化は、大きく分けて以下のようなフェーズに分かれています。

• イベント検知（ルータの追加/削除、リンクのup/down、設定変更など）
• ルーティングプロトコルへの注入
• ルーティング情報の伝搬
• ルーティングの計算（ルーティングプロトコルごと）
• ルーティングテーブルへの反映

インターネット上では、メンテナンスや障害によって頻繁に状態変化が発生しています。状態変化が発生すると、コンバージェンスに至るまでの間、ルータ間でルーティングテーブルに矛盾が発生し、パケットロスが発生する可能性が出てきます。ネットワークが大規模になればなるほどコンバージェンスタイムが大きくなりやすく、コンバージェンス性能がネットワーク品質に与える影響は大きくなります。よって、より安定した高品質なネットワークを作る上で、ルーティングコンバージェンスを高速化させることが非常に重要になります。

当時（2003年頃）はルーティングコンバージェンスを高速化する技術が登場し始めた頃でした。まずはIIJのバックボーン性能を調べてみようということになり、廃止予定の設備を利用して計測しました。機器のデバッグログと結果を突き合わせて、時間を要しているポイントを分析し、対策を検討しました。結果、大きく分けて以下の3つを実施しました。

• ルータのアップグレード
• 各種パラメータのチューニング
• Down検知しやすいトポロジに変更

ルータを最新のOSにアップグレードしないと、そもそも各種パラメータのチューニングができませんでした。バックボーンルータだけでも1年弱、すべてのルータが完了するのに数年を要しました。また、このアップグレードと併せてIPv6対応も実施していきました。アップグレードが完了したルータから順次パラメータをチューニングしつつ、デュアルスタック化していきました。また、当時はまだBFD（Bidirectional Forwarding Detection）が登場していなかったため、L2 Segmentを可能な限りPoint-to-Point構成に変更し、できるだけKeep Aliveに頼らないトポロジにするなど地道な対応なども進めました。その成果として、コンバージェンスタイムを1秒未満に実現しています。

そのほか、ルーティングコンバージェンス高速化の取り組みと並行して、品質を上げるための様々なシステム開発にも取り組みました。

• ルータのログから状態変化を監視するシステム
• ルーティングのアップデート情報を記録するシステム
• 拠点間のパケットロス・遅延を計測・監視するシステム

今となっては当たり前のような品質ですが、こうした取り組みにより、いち早く実現させていきました。

4.2.3 2007～2010年 トラフィック格闘期（BF化）

増え続けるトラフィックに対して我々が利用しているルータの限界が見え、その当時の設計どおりにOC192（9.6G）の次の接続メディアとしてOC768（40G）の利用を検討しましたが、我々の要件に合うルータでOC768に対応しているのはCisco CRS-1しかありませんでした。しかし、床荷重が1tもあり設置できず早々に断念することになりました。そうなると、10GbEを複数本で増強するしかなく、ルータの10GbEポート数とキャパシティの問題からも設計を考え直さなければならない課題に直面しました。

そこで思いついたのが、CRS-1のバックプレーンの容量を増やすために使われていた3ステージスイッチファブリックのアーキテクチャを複数台のルータで実現し、巨大な仮想的な1台のルータ（以降ルータ群）にすることです（図-8-1）。

この構想ではスイッチファブリックに相当するバックボーンルータ（以降BFと略します）はエッジを担当するバックボーンルータ（以降BBと略します）すべてとつなぐ必要があります。しかし、逆から見るとBBルータ側はBFルータの台数分のポートが必要になりますが、エッジへの入出力を担当するためにすべてのポートをBFルータとの接続に使うわけにはいきません。このルータ群のキャパシティが4年間毎年2倍（現在のトラフィックの16倍）に増えても耐えられるだけのキャパシティを仮定として置き、BBルータの最大ポート数からBFルータへの接続用のポート数を算出して設計しました。

接続ポート数を解決した次には、複数台のルータで実現していることを逆手にとって、1ヵ所にしなくても複数拠点に分散して実現することで全体の台数を削減できることを思いつき、東京ではトラフィックが多かった拠点の3ヵ所をBFルータの設置場所に分散配置することを検討しました（図-8-2）。分散配置することで課題となるのが、拠点間の10Gの回線数が非常にたくさん必要になることです。当時の10GbEの回線単価を考えると非常に高価になることが想定され、分散配置しない方が安価になります。そこで、通信キャリアに想定している本数と共に1本あたりの回線単価がどれくらいになるのかを確認しつつ、自分たちで本格的に伝送装置を運用する場合の1本あたりの回線単価を比較して、一部の区間においては自分たちで伝送装置を持つことにしました。簡易的な伝送装置は利用していたものの、本格的な伝送装置を利用するには敷居も値段も高かったのですが、何度もメーカに押しかけて試験をさせてもらったり、何度も説明を受けたり、伺っているうちに、我々の本気度を感じ取ってくれたあるメーカさんが、我々の想定している金額感に合わせてくれたのが導入の決め手のひとつとなりました。

分散配置の回線の問題が解決した次に、このルータ群と各拠点との回線の設計に入りました。今までの回線設計である1+1冗長では非常に多くの回線が必要となるためN+1冗長にしてコスト削減を検討しますが、奇数本数になるときの分散させる方法が非常に難しく、良い方法が見つかりませんでした（図-8-3）。結局3ステージファブリック構想は一部諦めて、東阪など主要拠点間はBFルータ同士をつなぐことでN+1冗長とすることにしました。BFルータ間で接続したために、BBルータから入ってきたトラフィックがどの東阪の回線を使ってどれくらい流れているかなどを明確にしなければ、障害やメンテナンス時のトラフィックの迂回や増強計画が立てられないという非常に難しい問題を生むことになります。この問題を解決するにはnetflowによる解析しかなく、解析に時間がかかってしまうと万一突発的なトラフィックが発生したときに対応できません。丁度、このときに分散システムによって高速な解析ができるシステムを独自開発（注5）していたことによって、障害やメンテナンスによる輻輳を発生させることがありませんでした。結局、4年耐えられる設計としていましたが、倍の8年間設計を変えることなく増強し続けることができました。

拡大する

図-8 ファブリック構成のインターネットバックボーン 概要図

4.2.4 2011年～ネットワーククラウド（BBコアフルメッシュ化、閉域の拡充）

この頃になると既にAWSやGCP、Azureなど、そしてIIJでも「IIJ GIO」としてクラウドサービスを開始しており、クラウドサービスが本格化していきます。それに伴いインターネットトラフィックとは隔離された閉域の拠点間通信の需要が大きくなり、インターネットバックボーンとは別にプライベートバックボーンとしてMPLS/L3VPNを利用して拠点展開していくことになります。

インターネットバックボーンは前述のファブリック構成をとっており、ファブリックルータをスケールアウトさせることで全体のトラフィックを運ぶことができる構成でしたが、10Gメディアしかなかったため、トラフィックが増大してくるにつれて運用上の課題も多く抱えるようになってきます。POP内の接続についてはリンクを束ねるLAG（Link Aggregation）やIGP・BGP multipathなどのロードバランスを駆使することになるのですが、トラフィックフローのハッシュ値による分散では綺麗に分散するには限界があり、余計にポートを消費するようにもなってきます。また、どのリンクにIPパケットが流れているか分からないため正常性の確認が難しく、100Gで集約することを待ち望んでいました。

実際に100Gを実利用し始めたのは2012年頃で、JPNAPに100Gで接続を開始しています。既にインターネットバックボーンとしては東名阪で耐障害性を考えて異キャリア・異ルート・異拠点間の区間でOC192を20本程度利用していました。この構成から単純に100G化するにはコストもかかり過ぎてしまうため、100Gというキャパシティの利を活かして、ルート・拠点分散の冗長性を落とすことなく、以下のような点も一緒に実現することにしました。

拡大する

図-9 100G対応 フルメッシュ型インターネットバックボーン 概要図

• バックボーンネットワークの拠点回線の統合
• 東京・大阪依存構成の解消

IIJは自前でファイバーを持っていないため、長距離区間はキャリア回線を調達する必要があったため、複数のネットワーク面ごとにキャリア回線を個別に用意しなくてもよいようにMPLS/L2VPNでPW（Pseudo-Wire）を利用できるようにして、回線帯域を複数のネットワーク面でシェアできるようにしました。また、ルート・拠点分散の冗長性を各ネットワークで維持していくことは運用の手間が増える上にコストもかかるため、L2VPNがルート分散やトラフィックエンジニアリングの多くの部分を担い、MPLSの高速迂回によって回線障害などで発生するトポロジ変化を隠蔽することで、各ネットワークはより制御しやすい構成にすることにしました。トラフィックが多いインターネットバックボーンにおいては、コアPOP間をフルメッシュで結ぶことでコア拠点間のトランジットトラフィックをなくしてシンプルな構成にシフトしました。

東京・大阪依存構成の解消以前のバックボーンは東京や大阪近郊ではない拠点でも東京か大阪にぶら下がっている構成となっていました。トラフィックの効率性を考えるとその構成で十分でしたが、東京や大阪が被災した際にぶら下がっている拠点も通信ができない状況に陥ってしまうことになります。これを解消するべく札幌・仙台を関東非経由で名古屋へ岡山・広島・福岡・松江などを大阪非経由で名古屋に回線を延伸、日米間の国際線も東京・大阪・名古屋に分散配置して耐障害性を上げることを、数年かけて実施しています。

IIJのネットワークはもともとインターネットトラフィックの交換の中心であった米国にのみ拠点を持っていましたが、こうした取り組みと共に米国以外の地域にもネットワーク延伸しています。2013年にはヨーロッパ、2014年には香港とシンガポールにも延伸し、海外との接続性を米国のみに頼っていた構成からアジア・ヨーロッパ各地でダイレクトにトラフィック交換ができるようにもなり、インターネットの接続性の観点でも大幅な改善が実現しています。

こうした100Gの統合バックボーンを導入することでインターネットトラフィックと比べて小さかった閉域のプライベートバックボーンの拡充もスムーズに行うことができ、パブリッククラウドとの相互接続もクラウドエクスチェンジとして順次拡充しており、昨今の急速なワークスタイルの多様化するニーズにも対応できるようなネットワーククラウドとして拡張を実施してきました。

以上、黎明期から順に説明してきたとおり、IIJバックボーンもその時代の課題を解決してきたことで改善を繰り返し、変化してきました。社会インフラとして欠かせないインターネットは今後もより高い信頼性が求められるモノになっていくことでしょう。IIJはこれからもこうした社会のニーズに応えていくための信頼できる社会インフラとして拡張を実施していきます。

4.3 IIJ ネットワークのセキュリティ対策

IIJはネットワークが適切に利用可能であるようにセキュリティの向上にも取り組んできました。ここでは、ネットワーク運用に関わるセキュリティ対策のうち、IIJで実施した取り組みをいくつか紹介します。

4.3.1 Source Address Validation（送信元検証）

インターネットでは基本的にIPパケットヘッダの宛先IPアドレスを頼りに経路情報を探索し、IPパケットを宛先に届けています。IPパケットヘッダには送信元IPアドレスの情報もありますが、これが間違っていても宛先にはIPパケットが届きます。IPパケットを受け取った宛先はIPパケットヘッダの送信元IPアドレスを見て通信元を判別し、必要に応じて応答パケットを送出します。送信元IPアドレスが間違っていた場合、間違ったIPアドレスの情報を信じて、全く見当違いのホストに応答パケットが送出されることになります。この挙動は悪意ある攻撃者に悪用されるようになりました。例えば、攻撃元を識別しづらくしたり、他のホストに偽装して既存の通信を乗っ取ったり、特定ホストに応答パケットを送付させたりする攻撃手法が考案され、実際に攻撃で使用されました。

2005年頃からDNSを悪用したDNSリフレクター攻撃（DNS増幅攻撃）が観測されるようになりました。この攻撃は送信元IPアドレスを攻撃対象ホストのIPアドレスに偽装して、踏み台となるネームサーバにDNS問い合わせを送信します。名前解決でデータ量が増えた応答をネームサーバから攻撃対象ホストへ送付させることで、攻撃対象の帯域を効率的に埋め尽くし、サービス不能を狙う攻撃です。攻撃者は事前にインターネットに接続されたホストを乗っ取り、そうしたホストから送信元IPアドレスを偽装したパケットを送出することで攻撃を実施していました。IIJではこうした状況を鑑み、IIJの接続サービスが攻撃に悪用されないように、送信元IPアドレス偽装を防ぐ技術の導入を進めることとしました。

IPアドレスの偽装に関する問題は早くから認知されており、RFC 2827（BCP38）やRFC3704（BCP84）として問題と対策が文章にまとまっています。対策には、できるだけ接続サービスを終端している箇所の近くで、適切な送信元IPアドレスが用いられているかどうかを検証する必要があります。当時IIJで利用していた機器では送信元IPアドレスを検証するために、経路探索の仕組みを応用したunicast Reverse Path Forwarding（uRPF）と、パケットフィルタリングの機能を用いるAccess Control List（ACL）が利用可能でした。機種やソフトウェアのバーションによっては機能に制限があったので、機種に応じて適切な方法で実装することにしました。2006年3月には送信元検証をすべての接続サービスに導入する旨アナウンス（注6）し、順次適用を完了しました。これにより、IIJの接続サービスが攻撃に悪用されることを防ぎ、ネットワーク全体のセキュリティ向上と安定した運用を実現しました。

4.3.2 Internet Routing Registry（IRR）

インターネットに様々なネットワークが接続し、拡大する中で、ネットワーク間でBGP経路制御のポリシー調整をどう実現するかは大きな課題です。これに対し、IRRは各ネットワークが経路制御ポリシーをオブジェクトとして登録し、お互いにそれぞれのポリシーを参照できる機能を提供しています。IRRに登録されたオブジェクトは、経路フィルタの自動生成や障害発生時の確認用などに利用されています。IIJではroute、route6、as-setなどIRRの活用でよく参照されている主要なオブジェクトを登録し、情報が常に最新状態になるよう維持しています。更に、オブジェクトを登録するIRRサービスとして1990年台からMeritが運用するMerit RADbを利用してきました。2005年からはJPNICの運用するJPIRRも併用して、現在は主にこれら2つのIRRを利用しています。

IRRに登録されているオブジェクトが勝手に書き換えられてしまうと、それを参照した他のネットワークで間違った経路フィルタが生成されるなどして、IIJの到達性に問題が生じるかも知れません。Merit RADbもJPIRRも基本的には電子メールを管理システム宛てに送信することで、オブジェクトの更新を行います。その際に利用できる認証方式にはいくつか選択肢があり、IIJではその中で一番強固なPretty Good Privacy（PGP）を利用した認証を利用することにしました。これはPGPの電子署名とその検証を利用した認証で、事前にオブジェクト変更権限を持つPGP公開鍵をIRRに登録することで利用できます。IIJでは2003年にPGP認証へと移行完了しています。

4.3.3 Resource Public Key Infrastructure（RPKI）

RPKIはIPアドレスやAS番号など、番号資源の分配を証明するPKIで、これを活用することで経路制御の安全性向上を実現することもできます。IPアドレスの分配を受けた組織は、そのネットワークをどのASから広報するかを、Route Origination Authorization（ROA）としてRPKIシステムから発行できます。この情報を用いると、BGPで受信した経路情報が妥当な広報元ASで生成されたものかを確認できるようになります。現状ではIRRの方が広く利用されていますが、RPKIの方が自動化に優れ、より信頼度の高い情報を利用できるため、今後RPKIの利用も広がるものと考えています。

IIJでは2020年に基本的なROAの発行を完了しています。ROAには経路の分割広報をどこまで許容するかを示す最大経路長が含まれますが、IIJでは分割広報しないので、広報経路の経路長をそのまま設定しています。これはRFC 9319（BCP185）でも推奨されている設定です。また、同じく2020年からピアとアップストリームから受信するBGP経路広告をROAの情報を用いて検証し、ROAと矛盾する経路情報を破棄するポリシーを導入しています。これにより、ROAを発行しているネットワークが間違った広報元ASから経路広告されてもIIJネットワークでは該当経路を判別して破棄することが可能となっています。また、Merit RADbではROAと矛盾するオブジェクトを自動的に削除する機能が実装されているため、ROAを発行することでIRRに間違ったオブジェクトを登録されないようにする防御手段にもつながっています。

4.3.4 Mutually Agreed Norms for Routing Security（MANRS）

インターネット運用におけるネットワークのセキュリティ対策は、多くのネットワークが協調的に導入することでその有用性が高まります。対策の導入を推進するためのグローバルな自主的活動として、MANRSが挙げられます。これはInternet Society（ISOC）の協力のもと、推奨されるセキュリティ対策を分野別に設定し、インターネット運用に関わる各組織に取り組みの実践を求めるものです。活動に賛同する組織はMANRSに自身の実践している取り組みを示し、参加することができます。

IIJでは、利用可能なセキュリティ対策を適宜導入してきました。これらはMARNSの推奨する実践とも合致しており、IIJは日本初の参加組織として2015年にMANRSに参加しました（注7）。IIJでは、今後ともインターネットの安定運用のために運用を見直し、継続的な改善を続けてまいります。

1. （注1）WindowsやMac にTCP/IP のスタックが標準搭載されたのは1995年頃。
2. （注2）45Mbpsの専用線接続におけるインターネット利用料が2000万円/月。
3. （注3）BGP（Border Gateway Protocol）：初期はBGP3が主流でしたがCIDRの導入などによりBGP4(RFC1771)が誕生。βテストの頃よりBGP4を採用していました。
4. （注4）RFC1966 BGP Route Reflection An alternative to full mesh IBGP
5. （注5）IIR Vol.4、3章 クラウドコンピューティングテクノロジー「分散システムdddの実装と活用」（https://www.iij.ad.jp/dev/report/iir/004.html）を参照のこと。
6. （注6）IIJ、全接続サービスで「Source Address Validation(送信元検証)」を導入（https://www.iij.ad.jp/news/pressrelease/2006/pdf/0308.pdf）。
7. （注7）MANRS Turns 1 and First Japanese Operator, IIJ, Joins（https://www.manrs.org/2015/11/manrs-turns-1-and-first-japanese-operator-iij-joins/）。

4. フォーカス・リサーチ（3） IIJバックボーン30年間の変遷

• 4.1 はじめに
• 4.2 IIJバックボーンの変遷
• 4.3 IIJ ネットワークのセキュリティ対策