BGP とインターネットのルーティング入門 - AS・経路選択から経路ハイジャックと RPKI まで

BGP とインターネットのルーティング入門 - AS・経路選択から経路ハイジャックと RPKI まで

作成日:
読了:約48分
更新日:
ネットワークTCP/IPインフラセキュリティBGP
この記事を読む人におすすめPR / Amazonアソシエイト
書籍PR
マスタリングTCP/IP ルーティング編

RIP・OSPF・BGP を体系的に学べる定番

Amazonで見る
書籍PR
マスタリングTCP/IP 入門編 第6版

IP と経路制御の基礎を固める一冊

Amazonで見る
書籍PR
ネットワークはなぜつながるのか 第2版

パケットの旅を追って全体像をつかむ

Amazonで見る

当サイトは Amazon.co.jp を宣伝しリンクすることで紹介料を得る手段を提供する、Amazonアソシエイト・プログラムの参加者です。価格・在庫はリンク先の最新情報をご確認ください。

「大手 SNS が数時間まるごと見えなくなった」「ある国の通信事業者の設定ミスで動画サイトに世界中からつながらなくなった」。インターネットの大規模障害のニュースには、しばしば BGP という単語が登場します。ところが BGP は、アプリケーション開発者が普段の業務で直接設定することはほとんどありません。そのため「名前は聞くけれど、何をしているのかはよく分からない」という方も多いのではないでしょうか。

この記事では、ルーティングの基本（ルーティングテーブルと最長一致）から始めて、AS と AS 番号、BGP-4 の基本動作と経路選択、トランジット・ピアリング・IX、経路ハイジャックとルートリークの実例、RPKI・ROV・ASPA による対策、そして手元で確認できるコマンドと公開ツール、クラウドの専用線接続での BGPまでを、RFC や当事者の公式発表を軸に整理します。

IP アドレスやプレフィックス長（/24 など）の基礎は IPアドレスとサブネット・CIDR・NAT 入門 で扱っているので、あわせて読むと理解しやすいはずです。

ルーティングの基本: ルーティングテーブルと最長一致

IP パケットは、送信元から宛先まで一気に届くわけではありません。途中のルーター（やホスト自身）が、それぞれ「この宛先ならどの隣へ渡すか」を判断し、バケツリレーのように転送していきます。この判断に使う表がルーティングテーブルです。

手元のルーティングテーブルを見る

ルーティングテーブルはルーターだけのものではなく、手元の PC にもあります。macOS では netstat -rn で確認できます（以下は筆者の macOS で 2026-09-24 に実行した結果の冒頭部分です）。

macOS: netstat -rn -f inet（抜粋）
Routing tables
 
Internet:
Destination        Gateway            Flags               Netif Expire
default            192.168.0.1        UGScg                 en0
127                127.0.0.1          UCS                   lo0
127.0.0.1          127.0.0.1          UH                    lo0
169.254            link#16            UCS                   en0      !
192.168.0          link#16            UCS                   en0      !

default がデフォルトルート（0.0.0.0/0）で、「ほかのどの行にも当てはまらない宛先は 192.168.0.1（家庭のルーター）へ渡す」という意味です。家庭の PC のテーブルはこの程度の行数で済みますが、インターネットの中核にいるルーターは、世界中の宛先プレフィックスを網羅した巨大なテーブル（いわゆるフルルート）を持っています。

Linux では ip route で一覧を、ip route get 1.1.1.1 で「その宛先に実際にどの経路が使われるか」を確認できます（構文のみ。本記事では Linux での実行はしていません）。

最長一致（Longest Prefix Match）

ルーティングテーブルには、範囲が重なり合う経路が同時に載っていることがよくあります。たとえば 203.0.113.0/24 と 203.0.113.128/25 の両方があれば、203.0.113.150 はどちらにも含まれます。このときルーターは、一致する経路のうちプレフィックス長が最も長い（範囲が最も狭い）ものを選びます。これが最長一致です。

最長一致は、後で扱う経路ハイジャックを理解するうえでも重要です。より細かいプレフィックスを広告した者が勝つという性質が、攻撃にも防御にも使われるからです。

JavaScript で最長一致を実装する

仕組みを確かめるために、最長一致を JavaScript で書いてみます。アドレスを32ビットの整数に変換し、プレフィックス長から作ったマスクで AND を取って比較するだけです。

lpm.mjs
// IPv4 アドレスを 32 ビットの符号なし整数に変換する
const toInt = (ip) =>
  ip.split('.').reduce((acc, octet) => ((acc << 8) + Number(octet)) >>> 0, 0);
 
// プレフィックス長からネットマスクを作る（/0 は 0）
const maskOf = (len) => (len === 0 ? 0 : (0xffffffff << (32 - len)) >>> 0);
 
// ルーティングテーブル（宛先プレフィックスとネクストホップ）
const table = [
  { prefix: '0.0.0.0/0', nextHop: '192.0.2.1 (デフォルトルート)' },
  { prefix: '203.0.113.0/24', nextHop: '198.51.100.1 (ISP-A 経由)' },
  { prefix: '203.0.113.128/25', nextHop: '198.51.100.9 (ISP-B 経由)' },
  { prefix: '203.0.113.200/32', nextHop: '198.51.100.20 (ホストルート)' },
];
 
// 最長一致: 一致する経路のうちプレフィックス長が最大のものを選ぶ
function lookup(dst) {
  const addr = toInt(dst);
  let best = null;
  for (const route of table) {
    const [net, lenStr] = route.prefix.split('/');
    const len = Number(lenStr);
    const mask = maskOf(len);
    if (((addr & mask) >>> 0) === ((toInt(net) & mask) >>> 0)) {
      if (best === null || len > best.len) best = { ...route, len };
    }
  }
  return best;
}
 
for (const dst of ['203.0.113.10', '203.0.113.150', '203.0.113.200', '8.8.8.8']) {
  const r = lookup(dst);
  console.log(`${dst.padEnd(15)} -> ${r.prefix.padEnd(18)} ${r.nextHop}`);
}

node lpm.mjs の実行結果は次のとおりです。

実行結果
203.0.113.10    -> 203.0.113.0/24     198.51.100.1 (ISP-A 経由)
203.0.113.150   -> 203.0.113.128/25   198.51.100.9 (ISP-B 経由)
203.0.113.200   -> 203.0.113.200/32   198.51.100.20 (ホストルート)
8.8.8.8         -> 0.0.0.0/0          192.0.2.1 (デフォルトルート)

203.0.113.150 は /24 にも /25 にも一致しますが、より長い /25 が選ばれています。どれにも一致しない 8.8.8.8 はデフォルトルートへ流れます。実際のルーターは全件を線形に走査するのではなく、トライ木などの専用データ構造やハードウェア（TCAM など）で高速に検索しますが、選ばれる結果の考え方は同じです。

静的ルーティングと動的ルーティング

ルーティングテーブルの中身を作る方法は、大きく2つあります。

方式中身の作り方向いている場面
静的ルーティング管理者が経路を手で設定する小規模ネットワーク、出口が1つしかない拠点、デフォルトルート
動的ルーティングルーター同士がルーティングプロトコルで経路情報を交換し、自動で更新する経路が多い、冗長経路がある、障害時に自動で迂回したい

静的ルーティングは挙動が予測しやすい反面、回線が切れても自動では迂回しません。動的ルーティングは障害に追従できますが、プロトコルの設定を誤ると影響が一気に広がります。インターネット全体の経路交換は、この動的ルーティングの代表例である BGP によって成り立っています。

IGP と EGP: 組織の中と外で役割が違う

動的ルーティングプロトコルは、使われる範囲によって2種類に分けて説明されます。

分類役割代表例主な関心事
IGP（Interior Gateway Protocol）1つの組織（AS）の内部で経路を交換するOSPF（OSPFv2 は RFC 2328）、IS-IS最短・最速の経路を素早く計算し、障害時にすばやく収束する
EGP（Exterior Gateway Protocol）組織（AS）同士の間で経路を交換するBGP-4（RFC 4271）契約や方針（ポリシー）に沿って、どの経路を誰に見せるかを制御する

IGP は「自社ネットワーク内でリンクのコストを見て最短経路を選ぶ」ための仕組みで、全ルーターが同じ管理者のもとで協調する前提です。一方で組織の境界をまたぐ経路交換では、「最短かどうか」よりも「その経路を使ってよい契約か」「相手にどこまで見せるか」が重要になります。BGP は、このポリシーを表現しやすいように設計されたプロトコルです。現在のインターネットで組織間の経路交換に使われている EGP は、事実上 BGP-4 です。

AS（自律システム）と AS 番号

BGP の世界での「組織」の単位が AS（Autonomous System、自律システム）です。AS の登録ガイドラインである RFC 1930（1996年3月）は、AS を「1つ以上のネットワーク運用者が運用する、単一で明確に定義されたルーティングポリシーを持つ、接続された IP プレフィックスの集まり」と定義しています。ISP、クラウド事業者、CDN、大学、大企業などが、それぞれ AS として識別されます。

各 AS には AS 番号（ASN）が割り当てられます。例として、Google は AS15169、Cloudflare は AS13335、KDDI は AS2516 です（後述の whois で実際に確認します）。AS 番号は IP アドレスと同じく、IANA から RIR（アジア太平洋地域なら APNIC）、さらに日本では NIR である JPNIC を経て分配されます。

2バイト AS と4バイト AS（RFC 6793）

当初の BGP では AS 番号は2バイト（16ビット）で、0 から 65535 までしか表せませんでした。AS の数が増えて枯渇が見えてきたため、4バイト（32ビット）に拡張されました。現行の仕様は RFC 6793（BGP Support for Four-Octet Autonomous System (AS) Number Space、2012年12月、RFC 4893 を置き換え）です。

4バイト AS に対応していない古い BGP スピーカーとの互換性のため、RFC 6793 は AS_TRANS（AS23456）という予約番号を定めています。4バイト AS 番号を2バイトの欄に入れられないときに、代わりにこの番号を入れて、本来の番号は別の属性で運ぶ仕組みです。経路情報の中に AS23456 が見えたら、この互換処理の痕跡だと考えてよいでしょう。

プライベート AS 番号と特殊用途の AS 番号

IP アドレスにプライベートアドレスがあるように、AS 番号にも組織内で自由に使ってよいプライベート AS 番号があります。IANA の Special-Purpose AS Numbers レジストリの内容を整理すると次のとおりです。

AS 番号用途根拠
0予約RFC 7607
23456AS_TRANS（4バイト AS の互換用）RFC 6793
64496 から 64511ドキュメント・サンプルコード用RFC 5398
64512 から 65534プライベート用途（2バイト）RFC 6996
65535予約RFC 7300
65536 から 65551ドキュメント・サンプルコード用RFC 5398
4200000000 から 4294967294プライベート用途（4バイト）RFC 6996
4294967295予約RFC 7300

プライベート AS 番号は、社内ネットワークやクラウドとの専用線接続（後述の AWS Direct Connect など）でよく使われます。インターネットに経路を広告する際には、上流側でプライベート AS 番号が取り除かれたり、上流の AS 番号に置き換えられたりします。なお、この記事のサンプルコードでは、ドキュメント用の 64496 から 64511 の範囲を使っています。

BGP-4 の基本動作

現在使われている BGP のバージョン4（BGP-4）は、RFC 4271（A Border Gateway Protocol 4 (BGP-4)、2006年1月、RFC 1771 を置き換え）で定義されています。IPv6 などの IPv4 以外の経路は、マルチプロトコル拡張（RFC 4760）で同じ BGP セッションに載せて運べます。

TCP 179 番で張る BGP セッション

RFC 4271 には「BGP は TCP ポート179番で待ち受ける」と明記されています。BGP は独自の再送や順序制御を持たず、そうした信頼性を TCP に任せています。TCP の3ウェイハンドシェイクや再送の仕組みは TCP と UDP の基本 で解説しています。

BGP で経路を交換する相手をピア（またはネイバー）と呼びます。ピアは自動では見つからず、管理者が「このアドレスの、この AS 番号の相手とセッションを張る」と明示的に設定します。この点は、隣接ルーターを自動で発見する OSPF などの IGP と大きく異なります。

4種類のメッセージ

RFC 4271 が定義するメッセージは次の4種類です。

型番号メッセージ役割
1OPENセッション確立時に、自分の AS 番号・ホールドタイム・BGP Identifier・対応機能などを伝える
2UPDATE経路の広告（パス属性と到達可能なプレフィックス）と取り消し（Withdrawn Routes）を運ぶ
3NOTIFICATIONエラーを通知し、セッションを閉じる
4KEEPALIVE経路の変化がなくても定期的に送り、相手が生きていることを確認する

ホールドタイムの間に相手から KEEPALIVE や UPDATE が届かなければ、セッションは切断されます。RFC 4271 はホールドタイムの推奨既定値を90秒、KEEPALIVE の送信間隔の目安をホールドタイムの3分の1としています。

BGP の特徴は、最初に全経路を交換したあとは差分だけを送ることです。定期的に全経路を送り直す古い距離ベクトル型プロトコルと違い、変化があったときに UPDATE で追加・取り消しを伝えます。

eBGP と iBGP

BGP セッションには2種類あります。

  • eBGP（External BGP）: 異なる AS のルーター同士のセッション。ISP との接続や IX でのピアリングはこちらです。
  • iBGP（Internal BGP）: 同じ AS 内のルーター同士のセッション。複数の出口を持つ AS で、外から学んだ経路を AS 内の他のルーターに行き渡らせるために使います。

iBGP には「iBGP で学んだ経路を別の iBGP ピアへは再広告しない」という決まりがあるため、素朴に組むと AS 内の全ルーター同士でセッションを張るフルメッシュが必要になります。規模が大きい AS では、これを避けるためにルートリフレクター（RFC 4456）が使われます。

パス属性

UPDATE で運ばれる経路には、パス属性と呼ばれる付帯情報が付きます。代表的なものは次のとおりです。

属性意味経路選択での扱い
AS_PATHその経路が通ってきた AS 番号の列。AS を通過するたびに先頭へ自 AS 番号が追加される短いほうを優先。自 AS 番号が含まれていればループとみなして捨てる
NEXT_HOPその宛先へ向かうときの次の転送先アドレス到達できない NEXT_HOP の経路は選択対象外
LOCAL_PREFAS 内だけで使う優先度（iBGP で配られる）大きいほうを優先
MULTI_EXIT_DISC（MED）隣接 AS に「複数の接続点のうちどれを使ってほしいか」を伝える目安同じ隣接 AS から来た経路同士で、小さいほうを優先
ORIGIN経路の生成元（IGP、EGP、INCOMPLETE）IGP、EGP、INCOMPLETE の順に優先
COMMUNITIES（RFC 1997）経路に付けるタグ。NO_EXPORT などの既定値がある直接の優先度ではなく、ポリシーの条件として使う

AS_PATH は経路選択とループ防止の両方に使われる、BGP の中心となる属性です。自社の AS 番号を意図的に複数回付け足して経路を長く見せる AS パスプリペンドは、「こちらの回線はなるべく使わないでほしい」と外部に伝える手段として広く使われています。

ベストパス選択の流れ

同じ宛先への経路を複数のピアから受け取った場合、BGP スピーカーは1本だけを選んで自分のルーティングテーブルに入れます。RFC 4271 の Decision Process では、まず各経路の優先度（iBGP で学んだ経路なら LOCAL_PREF、eBGP ならローカルのポリシー）を計算し、最も優先度の高い経路を選びます。同点の場合は、次の順でタイブレークします（RFC 4271 9.1.2.2）。

  1. AS_PATH に含まれる AS の数が最も少ないもの
  2. ORIGIN の値が最も小さいもの
  3. 同じ隣接 AS から来た経路同士で MULTI_EXIT_DISC が最も小さいもの
  4. eBGP で学んだ経路があれば、iBGP で学んだ経路を除外する
  5. NEXT_HOP までの AS 内部のコスト（IGP のメトリック）が最も小さいもの
  6. BGP Identifier が最も小さいスピーカーから広告されたもの
  7. ピアのアドレスが最も小さいもの

実際のルーター製品は、これに独自の項目や細かな調整を加えていることが多いため、運用ではベンダーのドキュメントで順序を確認します。大事なのは、BGP の経路選択がポリシー（LOCAL_PREF）をまず優先し、次に AS の数で比べるという点です。遅延や帯域は、基本の選択基準には入っていません。

なお、この選択はあくまで「同じプレフィックス」の経路同士の比較です。プレフィックス長が異なる経路はルーティングテーブル上で別の行として並び、パケット転送時には前述の最長一致で選ばれます。

トランジット・ピアリング・IX

AS 同士がどのような契約でつながるかは、技術と同じくらい経路の流れ方に影響します。

  • トランジット: 顧客 AS が上流の AS（トランジットプロバイダー）に費用を払い、インターネット全体への到達性を買う関係です。上流は顧客の経路を世界中に広告し、世界中の経路を顧客に渡します。
  • ピアリング: 規模の近い AS 同士が、お互いの（および自分の顧客の）経路だけを交換する関係です。費用を払わない形態（セトルメントフリー）が多く、トランジット費用の削減や遅延短縮のために行われます。

ここから、よく知られた経路広告の原則が導かれます。

  • 顧客から学んだ経路は、ピアにも上流にも広告してよい（顧客のトラフィックを運ぶと収入になるため）
  • ピアや上流から学んだ経路は、顧客にだけ広告する（他のピアや上流へ流すと、無償で他者のトラフィックを中継することになるため）

この原則を破って、ピアや上流から学んだ経路を別のピアや上流へ流してしまうことをルートリークと呼びます（RFC 7908 が問題を定義しています）。後で見る実際の障害の多くは、このルートリークか、他人のプレフィックスを自分のものとして広告してしまう経路ハイジャックのどちらかです。

IX（インターネットエクスチェンジ）と JPIX

多数の AS が個別に専用線でピアリングするのは非効率なので、1か所に集まって共通のスイッチ（ピアリング LAN）に接続し、その上で相手ごとに BGP セッションを張る場所が作られました。これが IX（Internet Exchange）です。

日本の商用 IX の草分けは JPIX（日本インターネットエクスチェンジ、現在の株式会社JPIX）です。JPNIC ニュースレターの寄稿によると、JPIX は 1997年7月10日に KDD とインターネット総合研究所（IRI）が発起人となり、ISP 事業者を中心とした16社の出資を得て設立され、1997年11月末に商用 IX サービスを開始しました。

後述の traceroute では、筆者の環境から 1.1.1.1（Cloudflare）へ向かう経路の途中に、JPNIC の whois で「JPIX」と登録されたアドレス帯のホップが実際に現れます。

事例で見る経路ハイジャックとルートリーク

BGP は、基本仕様の段階では「ピアから受け取った経路が正しいか」を暗号的に検証する仕組みを持っていません。受け取った側がフィルタを適切に設定していなければ、誤った経路はそのまま伝わっていきます。ここでは、当事者や観測者が一次情報を公開している事例を4つ取り上げます。

2008年: Pakistan Telecom による YouTube のハイジャック

RIPE NCC のケーススタディによると、経緯は次のとおりです（時刻は UTC）。

  • 2008年2月24日 18:47: Pakistan Telecom（AS17557）が 208.65.153.0/24 の広告を開始
  • 上流の PCCW Global（AS3491）がこの広告をそのままインターネット全体へ転送し、YouTube 宛てのトラフィックが世界規模で吸い込まれた
  • 20:07: YouTube（AS36561）が同じ /24 の広告を開始
  • 20:18: YouTube がさらに細かい 208.65.153.0/25 と 208.65.153.128/25 を広告
  • 21:01: PCCW Global が Pakistan Telecom 発の経路を取り下げ、約2時間で収束

この事例は、最長一致の性質が攻防の両方に使われた典型例です。YouTube 本来の経路より細かい /24 が広告されたため世界中のルーターがそちらを選び、対抗策として YouTube はさらに細かい /25 を広告して取り戻しました。RIPE NCC の記事も「最長一致のルールにより、これらの広告を受け取ったルーターはトラフィックを YouTube へ送る」と説明しています。

2017年: Google の経路誤広告と国内の大規模障害

2017年8月25日の昼ごろ、日本国内で広範囲にインターネット接続障害が発生しました。総務省の電気通信事故検証会議がまとめた検証報告（2017年12月）によると、Google が 12時22分に、本来配信する予定ではなかった大量かつ詳細な経路情報を誤設定により海外のネットワークプロバイダーへ配信し、それを受信した海外プロバイダーを経由して KDDI などに伝わりました。KDDI に配信された経路情報は約10万件を超える量だったとされています。

Google は、この誤設定を8分以内に修正したとコメントしています（INTERNET Watch の報道による）。一方で報告書によると、受信した KDDI 側では 12時24分から16時47分まで一部のルータが不安定になっており、誤った経路が数分で取り消されても、影響を受けた側の復旧にはそれ以上の時間がかかりうることが分かります。報告書は、誤送信された経路情報の受信防止と不要な経路情報の送信防止を、再発防止策の柱として挙げています。

2019年: Verizon と BGP オプティマイザによるルートリーク

Cloudflare のブログ（2019年6月24日）によると、米国ペンシルベニア州の ISP である DQE Communications（AS33154）が「BGP オプティマイザ」を使っており、受け取ったプレフィックスを細かく分割した経路（more-specifics）を網内に持っていました。その経路が顧客の Allegheny Technologies（AS396531）へ渡り、そこから大手トランジット事業者 Verizon（AS701）を経由して広まった結果、多くのインターネット経路が小さな企業の網を優先経路として通るようになりました。

Cloudflare は「IRR フィルタリングが使われていれば、関係したどのネットワークも誤った more-specifics を受け入れなかったはずだ」と指摘しています。ルートリークに加えて、最長一致によって細かい経路が優先されたことが影響を大きくした例です。

2021年: Facebook（現 Meta）の障害

2021年10月4日、Facebook・Instagram・WhatsApp などが世界中から利用できなくなりました。これは他者からの攻撃やハイジャックではなく、自社内の作業に端を発する障害です。Facebook Engineering の公式説明によると、流れは次のとおりです。

  • バックボーンの保守作業で、グローバルなバックボーン容量の可用性を評価するためのコマンドが発行され、意図せずバックボーンの全接続を落とした
  • 本来それを止めるはずの監査ツールにバグがあり、コマンドを止められなかった
  • Facebook の DNS サーバーは、自身がデータセンターと通信できない場合に BGP 広告を取り下げる設計になっていた。バックボーン断によってこの条件が満たされ、DNS サーバー自体は動いていたのにインターネットから到達できなくなった
  • 通常のリモートアクセス手段や社内ツールも DNS 断の影響で使えず、物理的なセキュリティが厳重なデータセンターに技術者を派遣して復旧した

Cloudflare の観測では、Facebook（AS32934）の BGP 経路の取り下げは 15:40 UTC ごろに始まり、DNS サーバーのプレフィックス（185.89.218.0/23 と 129.134.30.0/23）も広告されなくなりました。経路が戻り、サービスが回復したのは 21:20 UTC ごろです。

DNS の名前解決がどう動くかは DNS の仕組み入門 で解説しています。「DNS が引けない」という症状の裏に、「そもそも DNS サーバーへの経路がない」という BGP 側の原因がありえることは、障害対応で覚えておいて損はありません。

対策: RPKI・ROV・ASPA

これらの事例を受けて、経路の正しさを検証する仕組みが整備されてきました。

RPKI と ROA（RFC 6480）

RPKI（Resource Public Key Infrastructure）は、IP アドレスや AS 番号の割り当て関係を電子証明書で表現する PKI です。アーキテクチャは RFC 6480（An Infrastructure to Support Secure Internet Routing、2012年2月）で定義されています。アドレスの分配と同じ階層（IANA、RIR、NIR、アドレス保有者）に沿って証明書が発行されます。

アドレスの保有者は、この証明書を使って ROA（Route Origin Authorization）を作成します。ROA は「このプレフィックス（最大長まで）を広告してよい起源 AS はこれである」という署名付きの宣言です。各ネットワークは RPKI リポジトリから ROA を集めて検証し、検証済みの中身（VRP: Validated ROA Payload）をルーターに渡します。

ROV（RFC 6811）: Valid・Invalid・NotFound

ルーターが受け取った経路を VRP と照合する仕組みが ROV（Route Origin Validation）で、RFC 6811（BGP Prefix Origin Validation、2013年1月）が手順を定めています。判定結果は3種類です。

判定条件
NotFoundその経路のプレフィックスを覆う VRP が1つもない（ROA が作られていない）
Valid覆う VRP のうち、起源 AS が一致し、プレフィックス長が最大長以内のものが少なくとも1つある
Invalid覆う VRP はあるが、起源 AS かプレフィックス長のどちらかが合わない

ROV を導入したネットワークは、一般に Invalid の経路を捨てる（ドロップする）ポリシーを設定します。2008年の YouTube の事例で言えば、YouTube が ROA を作り、PCCW などが ROV で Invalid をドロップしていれば、Pakistan Telecom の /24 は起源 AS 不一致で Invalid と判定され、伝播を止められたことになります。

JavaScript で ROV の判定を再現する

RFC 6811 の判定ロジックを簡略化して書くと次のようになります（IPv4 のみ、複数 VRP の扱いも最小限です）。

rov.mjs
// RFC 6811 の考え方を簡略化した経路起源検証（IPv4 のみ）
const toInt = (ip) =>
  ip.split('.').reduce((acc, o) => ((acc << 8) + Number(o)) >>> 0, 0);
const parse = (p) => {
  const [net, len] = p.split('/');
  return { net: toInt(net), len: Number(len) };
};
const covers = (vrp, route) => {
  if (route.len < vrp.len) return false; // VRP より短いプレフィックスは覆えない
  const mask = vrp.len === 0 ? 0 : (0xffffffff << (32 - vrp.len)) >>> 0;
  return ((route.net & mask) >>> 0) === ((vrp.net & mask) >>> 0);
};
 
// VRP（検証済み ROA の中身）: プレフィックス・最大長・正当な起源 AS
const vrps = [{ prefix: '203.0.113.0/24', maxLength: 24, asn: 64500 }];
 
function validate(prefix, originAs) {
  const route = parse(prefix);
  const covering = vrps.filter((v) => covers(parse(v.prefix), route));
  if (covering.length === 0) return 'NotFound';
  const matched = covering.some(
    (v) => v.asn === originAs && route.len <= v.maxLength,
  );
  return matched ? 'Valid' : 'Invalid';
}
 
const cases = [
  ['203.0.113.0/24', 64500], // 正規の広告
  ['203.0.113.0/24', 64511], // 別の AS が同じプレフィックスを広告（ハイジャック）
  ['203.0.113.0/25', 64511], // より細かいプレフィックスで横取り
  ['203.0.113.0/25', 64500], // 正規 AS でも maxLength 超過
  ['198.51.100.0/24', 64501], // ROA が存在しない
];
for (const [p, as] of cases) {
  console.log(`${p.padEnd(16)} AS${as}  ${validate(p, as)}`);
}

node rov.mjs の実行結果です。

実行結果
203.0.113.0/24   AS64500  Valid
203.0.113.0/24   AS64511  Invalid
203.0.113.0/25   AS64511  Invalid
203.0.113.0/25   AS64500  Invalid
198.51.100.0/24  AS64501  NotFound

4行目に注目してください。正規の AS が広告していても、ROA の最大長（/24）を超える /25 は Invalid になります。ROA の最大長を必要以上に長くしておくと、細かいプレフィックスによる横取りを許す余地が生まれるため、実際に広告する長さに合わせておくのが基本です。

普及状況と JPNIC の取り組み

日本では、JPNIC が RPKI のサービスを提供しており、JPNIC から分配を受けたアドレスについて、Web 上で ROA を作成・管理できます。JPNIC の説明によれば、作成した ROA は APNIC のトラストアンカー（TAL）から辿れるようになります。JPNIC ブログ（2022年7月）によると、国内では2015年に試験提供が始まりました。同記事は、JPNIC から分配された IP アドレスに対する ROA のカバー率を IPv4 が45.6%、IPv6 が57.1%とし、日本の IPv4 のカバー率が2018年末の3.5%から大きく伸びたと説明しています。JPNIC は2024年11月に「RPKI の ROA を使ったインターネットにおける不正経路への対策ガイドライン」も公開しています。

世界全体での ROA の作成状況は NIST RPKI Monitor で、利用している ISP が ROV で Invalid 経路を捨てているかどうかは Cloudflare の「Is BGP safe yet?」で確認できます。いずれも数値が日々変わるため、本記事では現在値の引用は控えます。

ルートリーク対策: RFC 9234 と ASPA

ROV が検証するのは「起源 AS が正しいか」だけです。2019年の Verizon の事例のように、起源は正しいまま、途中の AS が本来流すべきでない経路を流すルートリークは ROV では検出できません。

そのための仕組みとして、次の2つが整備されつつあります。

  • RFC 9234（Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages、2022年5月）: BGP セッションの OPEN で「相手は顧客か、上流か、ピアか」という役割（Role）を合意し、OTC（Only To Customer）属性で「この経路は顧客方向にしか流してはいけない」ことを伝播させます。
  • ASPA（Autonomous System Provider Authorization）: 各 AS が「自分の上流（プロバイダー）はこの AS たちである」という宣言を RPKI に登録し、受け取った経路の AS_PATH がその上下関係と矛盾していないかを検証します。

ASPA は 2026年9月時点でまだ RFC になっていません。IETF datatracker によると、検証手順を定める draft-ietf-sidrops-aspa-verification は最新版が -28（2026年8月24日）で、想定ステータスは Proposed Standard、WG での状態は「Waiting for Write-Up」、IESG の状態は「I-D Exists」です。ASPA オブジェクトの形式を定める draft-ietf-sidrops-aspa-profile も -29（2026年7月29日）の Internet-Draft の段階です。仕様の細部は今後も変わりうるため、導入を検討する場合は最新の版を確認してください。

BGPsec と基本のフィルタリング

AS_PATH 全体を各 AS が署名して改ざんを防ぐ BGPsec も RFC 8205（2017年9月）として標準化されていますが、経路上のすべての AS が対応しないと効果が出ない性質上、普及は限定的と言われています（本記事では普及率の定量的な裏取りはしていません）。

地味ですが効果が大きいのは、基本的なフィルタリングです。

  • RFC 8212（BGP Default Reject、2017年7月）: eBGP では、明示的なポリシーが設定されていない限り経路を受け入れも広告もしない、という既定動作を求める
  • RFC 7454（BGP Operations and Security、2015年2月）: プレフィックスフィルタや最大プレフィックス数の制限など、運用上のセキュリティ対策をまとめた BCP
  • MANRS（Mutually Agreed Norms for Routing Security）: フィルタリングや連絡先の整備など、ネットワーク運用者が守るべき行動規範をまとめた取り組み

2017年の国内障害の検証報告が「受信防止」と「送信防止」を柱に挙げているのも、この考え方と同じです。

開発者が手元で確認できること

BGP ルーターを持っていなくても、経路や AS の情報は手元から確認できます。以下は筆者の macOS で 2026-09-24 に実行した結果です。

traceroute で経路上の AS を見る

macOS の traceroute は -a オプションで各ホップの AS 番号を表示できます。

macOS: traceroute -a -n -q 1 -w 1 -m 15 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 15 hops max, 40 byte packets
 1  [AS0] 192.168.0.1  5.772 ms
 2  *
 3  [AS2516] 27.x.x.x  7.096 ms
 4  [AS2516] 27.x.x.x  8.380 ms
 5  [AS2516] 27.x.x.x  6.646 ms
 6  [AS0] 210.171.224.134  9.256 ms
 7  [AS0] 210.171.224.134  8.865 ms
 8  [AS13335] 1.1.1.1  6.877 ms

読み方は次のとおりです。

  • 1番目は家庭内ルーター（プライベートアドレスなので AS0）
  • 3から5番目は AS2516（KDDI）の網内（ISP 網内のアドレスは伏せています）
  • 6・7番目の 210.171.224.134 は、JPNIC の whois で Network Name が JPIX（Japan Internet Exchange Co., Ltd.）と登録されたアドレス帯です。RIPEstat で確認すると、このアドレスを含むプレフィックスは BGP で広告されておらず（announced: false）、そのため AS0 と表示されています。IX のピアリング LAN のアドレスはインターネットに広告しないのが一般的で、traceroute ではこうした見え方になります
  • 8番目で AS13335（Cloudflare）に到達

つまりこの経路は、KDDI と Cloudflare が JPIX 上で直接つながる（ピアリングしている）形で届いていると読めます。なお6・7番目で同じアドレスが続けて応答している理由は、この出力からは判断できません。

Linux では mtr を使うと、traceroute と ping を組み合わせてホップごとの損失率と遅延を継続的に表示できます。mtr -z 1.1.1.1 の -z で AS 番号も表示されます（筆者の環境には mtr が入っていないため、ここでは構文のみ紹介します）。

whois で IP アドレスの AS を調べる

Team Cymru が提供する IP-to-ASN の whois サービスを使うと、IP アドレスから「どの AS が、どのプレフィックスとして広告しているか」を引けます。

whois -h whois.cymru.com ' -v 8.8.8.8'
AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
15169   | 8.8.8.8          | 8.8.8.0/24          | US | arin     | 2023-12-28 | GOOGLE - Google LLC, US
whois -h whois.cymru.com ' -v 1.1.1.1'
AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
13335   | 1.1.1.1          | 1.1.1.0/24          | AU | apnic    | 2011-08-11 | CLOUDFLARENET - Cloudflare, Inc., US

アクセスログに残った不審な IP アドレスがどのクラウドやどの ISP のものかを調べるときにも便利です。日本のアドレスの登録情報を詳しく見たいときは、whois -h whois.nic.ad.jp 210.171.224.134/e のように JPNIC の whois を直接引きます（末尾の /e で英語表示）。

RIPEstat の API で RPKI の判定を確認する

RIPE NCC の RIPEstat は、経路や RPKI の状態を Web と JSON API の両方で提供しています。rpki-validation を使うと、「この AS がこのプレフィックスを広告した場合の ROV 判定」を確認できます。

Cloudflare の 1.1.1.0/24 を正規の AS13335 が広告した場合
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=1.1.1.0/24" | jq '.data'
実行結果
{
  "resource": "13335",
  "prefix": "1.1.1.0/24",
  "validating_roas": [
    {
      "origin": "13335",
      "prefix": "1.1.1.0/24",
      "validity": "valid",
      "max_length": 24
    }
  ],
  "status": "valid",
  "validator": "routinator"
}

起源 AS をドキュメント用の AS64496 に変えて問い合わせると、ROA と合わないため invalid_asn と判定されます。

同じプレフィックスを別の AS（AS64496）が広告した場合
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64496&prefix=1.1.1.0/24" | jq -c '.data | {resource, prefix, status}'
実行結果
{"resource":"64496","prefix":"1.1.1.0/24","status":"invalid_asn"}

自社サービスのプレフィックスに ROA が作られているかを確認したいときは、この API を CI や監視スクリプトから定期的に呼ぶ、という使い方もできます。

そのほかの公開ツール

  • bgp.tools: AS やプレフィックスごとに、上流・ピア・広告しているプレフィックスや RPKI の状態を一覧できる Web サービスです
  • RIPEstat の Web UI: プレフィックスの広告履歴や、RIS（Routing Information Service）が世界各地で観測した経路を可視化できます。2008年の YouTube の事例の分析にも RIS のデータが使われています
  • NIST RPKI Monitor: ROA による経路のカバー状況の推移を確認できます
  • Is BGP safe yet?（Cloudflare）: 利用中の ISP が ROV で Invalid な経路を捨てているかをブラウザから確認できます

クラウドと BGP: AWS Direct Connect の例

アプリケーション開発者が BGP を意識する場面として一番身近なのは、オンプレミスとクラウドを専用線でつなぐケースでしょう。AWS Direct Connect では、接続の上に作る仮想インターフェース（VIF）ごとに BGP セッションを張り、経路を交換します。AWS のドキュメント（Direct Connect routing policies and BGP communities）から、BGP に関わる要点を抜き出します。

  • パブリック VIF では、顧客側は自分が保有するパブリック AS 番号か、プライベート AS 番号（64512 から 65534、または 4200000000 から 4294967294）を使える。プライベート AS 番号を使った場合、AWS は顧客の経路を広告する際にそれを AWS の AS 番号（7224）に置き換えるため、AS パスプリペンドは AWS の外では効かない
  • パブリック VIF の BGP セッションでは、AWS 側の AS 番号として 7224 を使う
  • パブリック VIF で AWS が広告する経路には、すべて NO_EXPORT コミュニティが付く
  • プライベート VIF とトランジット VIF で AWS から顧客側への経路を選ぶ際は、まず最長一致、次にローカルプリファレンス、次に AS_PATH の長さ、最後に MED の順で評価される
  • ローカルプリファレンスは、顧客が広告する経路に 7224:7100（低）、7224:7200（中）、7224:7300（高）のコミュニティを付けて指定する。アクティブ/パッシブ構成では、主系に 7224:7300、待機系に 7224:7100 を付ける例が示されている

たとえば2本の Direct Connect 回線を主系・待機系で使い分けたい場合、「同じプレフィックスをコミュニティで優先度を変えて広告する」か「主系でより細かいプレフィックスを広告する（最長一致で勝たせる）」のどちらかで設計します。ここまで読んできた最長一致、LOCAL_PREF、AS_PATH、MED の知識が、そのままクラウドの設計に使えることが分かると思います。

複数の回線や拠点にトラフィックを振り分ける考え方は、ロードバランシングのアルゴリズム入門 で扱ったアプリケーション層の負荷分散と比べてみるのも面白いでしょう。BGP による振り分けは、経路（ネットワーク）単位で粒度が粗く、変更が反映されるまでに時間がかかる点が大きな違いです。

まとめ

  • ルーターはルーティングテーブルを最長一致で引いて転送先を決めます。より細かいプレフィックスが優先されるこの性質は、経路ハイジャックにも、その対抗策にも使われます
  • 組織内の経路は OSPF などの IGP が、組織（AS）間の経路は BGP-4（RFC 4271）が担います。AS 番号は RFC 6793 で4バイトに拡張され、64512 から 65534 と 4200000000 から 4294967294 がプライベート用途です
  • BGP は TCP 179番でピアとセッションを張り、OPEN・UPDATE・NOTIFICATION・KEEPALIVE の4種類のメッセージで経路を差分交換します。ベストパスは LOCAL_PREF などのポリシーを優先し、次に AS_PATH の長さで選ばれます
  • 経路の流れ方はトランジットとピアリングの契約で決まり、IX は多数の AS がピアリングする場です。日本では JPIX が1997年に設立されました
  • 2008年の YouTube、2017年の国内大規模障害、2019年の Verizon、2021年の Facebook の事例はいずれも、BGP が「受け取った経路をそのまま信じる」仕組みであることと関係しています
  • 対策の軸は RPKI（RFC 6480）と ROV（RFC 6811）で、ルートリーク対策として RFC 9234 と ASPA（2026年9月時点で Internet-Draft）が整備されつつあります
  • traceroute の -a、Team Cymru の whois、RIPEstat の API を使えば、開発者でも手元から経路・AS・RPKI の状態を確認できます

BGP は普段は意識しなくても動いている仕組みですが、大規模障害のニュースを読み解くときや、クラウドとの専用線接続を設計するときには、ここで扱った基礎がそのまま役に立ちます。トランスポート層以上の話に興味があれば、HTTP/3 と QUIC 入門 もあわせてどうぞ。

参考資料

関連記事

IPアドレスとサブネット・CIDR・NAT 入門 - /24 の計算からプライベートアドレス、NAT越え、VPC の CIDR 設計まで

IPアドレスとサブネット・CIDR・NAT 入門 - /24 の計算からプライベートアドレス、NAT越え、VPC の CIDR 設計まで

約39分

IPv4 アドレスの構造（32ビット・ネットワーク部とホスト部）、サブネットマスクとプレフィックス長、クラスフルから CIDR（RFC 4632）への歴史、AND 演算によるネットワークアドレス・ブロードキャスト・利用可能ホスト数の計算、プライベートアドレス（RFC 1918）・リンクローカル（RFC 3927）・CGNAT 用 100.64.0.0/10（RFC 6598）・ループバックなどの特殊用途アドレス、NAT/NAPT の仕組み（RFC 3022）と NAT 越え（STUN / TURN / ICE）、IPv6 の基本（RFC 4291、/64、ULA）、Docker・AWS VPC・Kubernetes での CIDR 設計の実務、macOS/Linux での確認コマンドと JavaScript による CIDR 計算まで、Web 開発者・インフラ担当者向けにまとめます。

ネットワークTCP/IPIPv4IPv6NATインフラ
SSH の仕組み - 鍵交換・ホスト鍵検証・公開鍵認証を一次ソースで理解する

SSH の仕組み - 鍵交換・ホスト鍵検証・公開鍵認証を一次ソースで理解する

約18分

リモートサーバー運用の土台である SSH プロトコルを、一次ソースの RFC 4251/4252/4253/4254（SSH-2 の Architecture / Authentication / Transport / Connection）を軸に整理します。TCP 接続からバージョン交換、KEXINIT による鍵交換と Diffie-Hellman、ホスト鍵の検証（known_hosts と TOFU の弱点）、公開鍵認証（authorized_keys と署名）、チャネルの多重化とポートフォワーディング（ssh -L / -R / -D）まで、その仕組みと OpenSSH での確認方法をインフラ担当者・開発者向けにまとめます。

SSHセキュリティネットワークLinuxインフラ
OpenSSH 10.4 の新機能とセキュリティ修正 - sftp/scp の脆弱性対応と量子耐性への流れ

OpenSSH 10.4 の新機能とセキュリティ修正 - sftp/scp の脆弱性対応と量子耐性への流れ

約11分

2026年7月6日にリリースされた OpenSSH 10.4 を一次情報で整理します。悪意あるサーバによる sftp ダウンロード先のすり替え、scp のリモート間コピーでの親ディレクトリ書き込み、鍵再交換時のクライアント側 use-after-free など複数のセキュリティ修正の中身に加え、ML-DSA 44 と Ed25519 を組み合わせた実験的なポスト量子署名の追加、そして mlkem768x25519 デフォルト化・DSA 削除といった量子耐性への流れまで、実務での確認ポイントとともにまとめます。

OpenSSHSSHセキュリティネットワークインフラ