Zenn
🌊

RFC 4271: ボーダー・ゲートウェイ・プロトコル4 (BGP-4) part1

2024/08/27に公開
RFC
bgp
tech

本文書の位置付け

本文書は、インターネット・コミュニティのためのインターネット標準トラック・プロトコルを規定し、改善のための議論と提案を求める。このプロトコルの標準化状況と状態については、最新版の「インターネット公式プロトコル標準」(STD 1)を参照のこと。このメモの配布は制限を受けない。

著作権表示

著作権 (C) The Internet Society (2006)。

要旨

本文書では、自律システム間ルーティング・プロトコルであるボーダー・ゲートウェイ・プロトコル(BGP)について説明する。

BGPスピーキング・システムの主な機能は、ネットワーク到達可能性(reachability)情報を他のBGPシステムと交換することである。このネットワーク到達可能性情報には、到達可能性情報が通過する自律システム(AS)のリストに関する情報が含まれる。この情報は、この到達性のAS接続グラフを作成するのに十分であり、そこからルーティング・ループが除去され、ASレベルではいくつかのポリシー決定が実施可能になる。

BGP-4は、クラスレス・ドメイン間ルーティング(CIDR)をサポートする一連のメカニズムを提供する。これらのメカニズムは、一連の宛先をIPプレフィックスとして広告するためのサポートや、BGP内のネットワーク「クラス」の概念を排除することが含まれる。BGP-4はまた、ASパスの集約を含む経路の集約を可能にするメカニズムも導入している。

この文書により、RFC 1771を廃止する。

1. はじめに

ボーダー・ゲートウェイ・プロトコル(BGP)は、自律システム間ルーティング・プロトコルである。

BGPスピーキング・システムの主な機能は、ネットワーク到達可能性情報を他のBGPシステムと交換することである。このネットワーク到達可能性情報には、到達可能性情報が通過する自律システム(AS)のリストに関する情報が含まれる。この情報は、この到達性のためのAS接続のグラフを作成するのに十分であり、そこからルーティング・ループが除去され、ASレベルではいくつかのポリシー決定が実施可能になる。

BGP-4は、クラスレス・ドメイン間ルーティング(CIDR)[RFC1518, RFC1519]をサポートする一連のメカニズムを提供する。これらのメカニズムには、一連の宛先をIPプレフィックスとして広告し、BGP内のネットワーク「クラス」の概念を排除することが含まれる。BGP-4はまた、ASパスの集約を含む経路集約を可能にするメカニズムも導入している。

BGPを介して交換されるルーティング情報は、宛先ベースのフォワーディング・パラダイムのみをサポートする。このパラダイムは、ルータがパケットのIPヘッダに含まれる宛先アドレスのみに基づいてパケットを転送することを前提としている。これは、BGPを使用して適用できる(または適用できない)一連のポリシー決定を反映する。BGPは、宛先ベースのフォワーディング・パラダイムに適合するポリシーのみをサポートできる。

1.1. よく使われる用語の定義

このセクションでは、BGPプロトコルに特有の意味を持ち、本文全体で使われる用語の定義を示す。

Adj-RIB-In
Adj-RIBs-Inには、ピアからローカルBGPスピーカに広告された未処理のルーティング情報が含まれる。

Adj-RIB-Out
Adj-RIBs-Outには、ローカル・スピーカのUPDATEメッセージによってピアに広告する経路が含まれる。

自律システム (AS)
自律システムの従来の定義は、単一の技術管理下にあるルータの集合であり、内部ゲートウェイ・プロトコル(IGP)と共通のメトリックを使用して、AS内でパケットをルーティングする方法を決定し、AS間ルーティング・プロトコルを使用して他のASにパケットをルーティングする方法を決定する。この従来の定義が開発されて以来、単一のASが複数のIGPを使用することが一般的になり、場合によってはAS内で複数のメトリック・セットを使用することもある。自律システムという用語の使用は、複数のIGPとメトリックが使用されている場合でも、ASの管理は他のASから単一の一貫した内部ルーティング・プランを持っているように見え、それを介して到達可能な宛先の一貫したイメージを提示するという事実を強調している。

BGP識別子
BGPメッセージの送信者のBGP識別子を示す4オクテットの符号なし整数。BGPスピーカは、そのBGP識別子の値をそのBGPスピーカに割り当てられたIPアドレスに設定する。BGP識別子の値は起動時に決定され、すべてのローカル・インタフェースとBGPピアにとって同一である。

BGPスピーカ
BGPを実装するルータ。

EBGP
外部BGP(外部ピア間のBGP接続)。

外部ピア
ローカル・システムとは異なる自律システムにあるピア。

フィージブル経路 (Feasible route)
受信者が使用できる広告された経路。

⚠️ フィージブル経路について

フィージブル経路とは、BGPルータが受信した経路情報のうち、ループが発生しないことが保証され、かつネクストホップまで到達可能な経路を指す。フィージブル経路は、最終的に選ばれる経路とは限らないが、バックアップとして保持され、現在の最適経路が利用できなくなった場合の代替経路として使われる。

BGPでは経路を選定する際、複数の候補となる経路が存在することがある。最適経路を決定する前に、候補となる経路は「フィージブル条件 (feasible condition)」を満たしているかどうかが評価される。「フィージブル条件」は、受信した経路の経路集約情報であるASパスがループしていないことを確認するために用いられる。

簡単に言うと、フィージブル経路とはループがなく、有効な経路候補を言う。

IBGP
内部BGP(内部ピア間のBGP接続)。

内部ピア
ローカル・システムと同じ自律システム内にあるピア。

IGP
内部ゲートウェイ・プロトコル - 単一の自律システム内のルータ間でルーティング情報を交換するために使われるルーティング・プロトコル。

Loc-RIB
Loc-RIBには、ローカルBGPスピーカの決定プロセスによって選択された経路が含まれる。

NLRI (Network Layer Reachability Information)
ネットワーク層到達可能性情報。

経路(route)
宛先セットとその宛先へのパスの属性をペアにした情報単位。宛先セットとは、UPDATEメッセージのネットワーク層到達可能性情報(NLRI)フィールドで伝送される1つのIPアドレス・プレフィックスにIPアドレスが含まれる仕組みである。パスは、同じUPDATEメッセージのパス属性フィールドで報告される情報である。

RIB (Routing Information Base)
ルーティング情報ベース。

アンフィージブル経路 (Unfeasible route)
前に広告されたフィージブル経路で、現在は使用できない経路。

1.2. 要件の仕様

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119 [RFC2119]の記述にしたがって解釈される。

2. 謝辞

本文書は、カーク・ルーヒードとヤコフ・レクターの共同執筆により、1991年10月に[RFC1267]として最初に公開された。

この文書の旧バージョン(BGP-1)に貢献してくれたガイ・アルメス、レン・ボザック、ジェフリー・C・ホーニッヒに感謝する。

この文書の旧バージョンに多大な貢献をしてくれたデニス・ファーガソンに特に感謝する。

この文書の旧バージョン(BGP-2)をレビューし、建設的で貴重なコメントを寄せてくれたボブ・ブレーデンに特に感謝する。

また、インターネット・エンジニアリング・ステアリング・グループのルーティング担当ディレクターであるボブ・ヒンデンと、この文書の旧バージョン(BGP-2)をレビューするために彼が集めたレビュー担当者チームにも感謝したい。このチームは、デボラ・エストリン、ミロ・メディン、ジョン・モイ、ラディア・パールマン、マーサ・スティーンストラップ、マイク・セントジョンズ、ポール・ツチヤで構成され、強靭さ、プロ意識、礼儀正しさを兼ね備えた素晴らしいチームだった。

この文書にあるセクションは、BGPのOSI版であるIDRP[IS10747]から多くを借用している。この点については、ライマン・チャピンが議長を務めるANSI X3S3.3グループと、そのグループ内でIDRPの編集者を務めたチャールズ・クンツィンガーの功績を称えるべきである。

また、ベンジャミン・アバルバネル、エンケ・チェン、エドワード・クラブ、マイク・クレイレン、ヴァンサン・ジレ、エリック・グレイ、ジェフリー・ハース、ディミトリー・ハスキン、スティーブン・ケント、ジョン・クロウチク、デビッド・ルロイ、ダン・マッシー、ジョナサン・ナターレ、ダン・ペイ、マシュー・リチャードソン、ジョン・スカダー、ジョン・スチュワート3世、デーブ・ターラー、ポール・トレイナ、ラス・ホワイト、カーティス・ビラミザール、アレックス・ジニンのコメントにも感謝する。

この文書の最終版の作成に協力してくれたアンドリュー・ランゲに特に感謝する。

最後に、この文書にアイデアとサポートを提供してくれたIDRワーキング・グループのメンバー全員に感謝する。

3. オペレーションの概要

ボーダー・ゲートウェイ・プロトコル(BGP)は、自律システム間ルーティング・プロトコルである。これは、EGP([RFC904]で定義)とNSFNETバックボーンでのEGPの使用([RFC1092]と[RFC1093]で説明)で得られた経験を基に作られている。BGPに関する詳細については、[RFC1772]、[RFC1930]、[RFC1997]、[RFC2858]を参照のこと。

BGPスピーキング・システムの主な機能は、ネットワーク到達可能性情報を他のBGPシステムと交換することである。このネットワーク到達可能性情報には、到達可能性情報が通過する自律システム(AS)のリストに関する情報が含まれる。この情報は、ASの接続性グラフを作成するのに十分であり、そこからルーティング・ループが除去され、ASレベルではいくつかのポリシー決定が実施することができる。

この文書の文脈では、BGPスピーカーは自分自身が使用する経路だけをピアに広告することを前提とする(この文脈で、BGPスピーカーは、最も優先されるBGP経路で、転送に使用される場合、BGP経路を「使用する」と言う)。それ以外の場合は、この文書の範囲外である。

この文書の文脈では、「IPアドレス」という用語は、IPバージョン4アドレス[RFC791]を指す。

BGPを介して交換されるルーティング情報は、宛先ベースの転送パラダイムのみをサポートする。このパラダイムでは、ルータはパケットのIPヘッダに含まれる宛先アドレスのみに基づいてパケットを転送することを前提とする。これは、BGPを使用して適用できる(または適用できない)一連のポリシー決定を反映する。ポリシーによっては、宛先ベースの転送パラダイムではサポートできないものがあり、そのためソース・ルーティング(明示的ルーティングとも呼ばれる)のような手法を適用する必要があることに留意する。このようなポリシーは、BGPを使用しても適用できない。例えば、BGPは、あるASが隣接ASにトラフィックを送信し、その隣接するASの向こう側にある(ただし、到達は可能だが)宛先へ転送することはできない。その場合、トラフィックは隣接ASから発信されたトラフィック(同じ宛先)とは異なる経路を辿ることになる。一方、BGPは、宛先ベースの転送パラダイムに準拠するあらゆるポリシーをサポートできる。

BGP-4は、クラスレス・ドメイン間ルーティング(CIDR)[RFC1518、RFC1519]をサポートする新しいメカニズムを提供する。これらのメカニズムには、宛先セットをIPプレフィックスとして広告する土台や、BGPにおけるネットワークの「クラス」という概念を排除する点が含まれる。BGP-4はまた、ASパスの集約を含む経路集約を可能にするメカニズムも導入している。

本文書では、全体を通じて「自律システム」(AS)という用語を使用する。自律システムの従来の定義は、単一の技術管理下にあるルータの集合で、AS内でパケットをルーティングする方法を決定するために内部ゲートウェイ・プロトコル(IGP)と共通のメトリックを使用し、そして他のASにパケットをルーティングする方法を決定するために、AS間ルーティング・プロトコルを使用する。この従来の定義が開発されて以来、単一のASが複数のIGPを使用することが一般的となり、場合によってはAS内で複数のメトリック・セットを使用することもある。自律システムという用語の使用は、ASの管理は複数のIGPとメトリックが使用されている場合でも、他のASに対して単一の一貫した内部ルーティング・プランを持っているように見え、それを介して到達可能な宛先の一貫したイメージを提示するという事実を強調している。

BGPは、トランスポート・プロトコルとしてTCP[RFC793]を使用する。これにより、明示的なアップデートの断片化、再送、確認応答、および優先順位付けを実装する必要がなくなる。BGPはTCPポート179で待ち受ける。BGPで使用するエラー通知メカニズムは、TCPが「グレースフルな」クローズ(つまり、コネクションがクローズされる前に未処理のデータをすべて配信する)をサポートしていることを前提としている。

TCPコネクションは2つのシステム間で形成される。これらのシステムは、コネクション・パラメータを開いて確認するためにメッセージを交換する。

最初のデータフローは、Adj-Ribs-Out(3.2を参照)と呼ばれるエクスポート・ポリシーで許可されたBGPルーティング・テーブルの一部分である。ルーティング・テーブルがリフレッシュされると、増分アップデートが送信される。BGPは、ルーティング・テーブルの定期的な更新を必要としない。BGP接続をリセットせずにローカル・ポリシーの変更が正しい効果を持つようにするために、BGPスピーカーは(a) すべてのピアから広告された経路の現バージョンを接続の間保持するか、(b) ルートリフレッシュ拡張[RFC2918]を利用する必要がある(SHOULD)。

KEEPALIVEメッセージは、コネクションが生きていることを確認するために定期的に送信する。NOTIFICATIONメッセージは、エラーや特別な状況に応答して送信する。コネクションがエラー状態になると、NOTIFICATIONメッセージを送信し、コネクションを閉じる。

別のASのピアを外部ピア、同じASのピアを内部ピアと呼ぶ。内部BGPと外部BGPは、一般的にIBGPとEBGPと略される。

ASが複数のBGPスピーカーを持ち、他のASにトランジット・サービスを提供する場合、AS内のルーティングの一貫したビューを確保するために注意を払わなければならない。ASの内部経路の一貫したビューは、AS内で使用するIGPが担う。この文書では、AS内のすべてのBGPスピーカーが互いにIBGPを維持することによって、AS外の経路の一貫したビューを提供することを前提とする。

この文書では、BGPプロトコルの基本動作を規定する。この動作は、拡張仕様によって変更することができ、実際に変更されている。プロトコルが拡張された場合、新しい動作は拡張仕様で完全に文書化されている。

3.1. 経路: 広告とストレージ

このプロトコルの目的上、経路とは宛先セットと宛先へのパスの属性をペアにした情報単位として定義する。宛先セットとは、UPDATEメッセージのネットワーク層到達可能性情報(NLRI)フィールドで伝送される1つのIPアドレス・プレフィックスにIPアドレスが含まれるシステムであり、パスは同じUPDATEメッセージのパス属性フィールドで報告される情報である。

⚠️ パス、経路、プレフィックスの違い

BGPにおいて、パス(path)、経路(route)、プレフィックス(prefix)はそれぞれ異なる概念を指すが、ネットワークの経路制御において重要な役割を果たす。

  1. パス: BGPでは、自律システム(AS)間の経路情報を伝達する際に、通過するASのリストがASパスとして記録される。このASパスは、BGPで経路選択を行う際の重要な要素となる。ASパス長が短いほど優先される。
  2. 経路: BGPでは、「経路」とはあるネットワーク(IPプレフィックス)に到達するための情報全体を指す。経路には、プレフィックス、ネクストホップ、メトリック、ASパスなど、経路に関する全ての情報を含む。複数の経路がある場合、BGPはこれらを比較して最適経路を選ぶ。
  3. プレフィックス: プレフィックスとは、ネットワークを表すためのIPアドレスの範囲を指す。例えば、192.168.0.0/24は、192.168.0.0から192.168.0.255までのIPアドレスをカバーするプレフィックスである。BGPはプレフィックスごとに経路情報を管理し、IPプレフィックスに対してどの経路を使用するかを決定する。

まとめると:

  • プレフィックスは、ネットワーク範囲を指し、
  • 経路は、そのネットワーク範囲への経路情報全体を意味し、
  • パスは、ネットワークに到達するために通過するASリストを指す。

経路は、UPDATEメッセージによってBGPスピーカー間で広告される。UPDATEメッセージのNLRIフィールドに複数のプレフィックスを含めることで、同じパス属性を持つ複数の経路を1つのUPDATEメッセージで広告することができる。

経路は、セクション3.2で説明するように、ルーティング情報ベース(RIB)、つまり、Adj-RIBs-In、Loc-RIB、Adj-RIBs-Outに格納される。

BGPスピーカーは前に受信した経路を広告することを選択した場合、ピアに広告する前に、その経路のパス属性を追加または変更することもできる(MAY)。

BGPは、BGPスピーカーが前に広告した経路がもはや使用できなくなったことをピアに通知できるメカニズムを提供する。あるBGPスピーカーが、経路がサービスから撤回されたことを示す方法は3つある。

a) 前に広告した経路の宛先を示すIPプレフィックスをUPDATEメッセージの撤回経路(WITHDRAWN ROUTES)フィールドに広告して、関連付けられた経路が使用できなくなったことを示す、

b) 同じNLRIを持つ代替経路を広告する、または

c) BGPスピーカーのコネクションを閉じることで、スピーカーのペアが互いに広告していたすべての経路が暗黙的にサービスから削除される。

経路の属性を変更するには、差し替え経路を広告することで実現できる。差し替え経路は新しい(変更された)属性を持ち、元の経路と同じアドレス・プレフィックスを持つ。

3.2. ルーティング情報ベース

BGPスピーカー内のルーティング情報ベース(RIB)は、3つの異なる部分で構成される。

a) Adj-RIBs-In: Adj-RIBs-Inは、他のBGPスピーカーから受信した着信のUPDATEメッセージから学習したルーティング情報を格納する。その内容は、決定プロセスへの入力として利用できる経路を表す。

b) Loc-RIB: Loc-RIBには、BGPスピーカーがAdj-RIBs-Inに含まれるルーティング情報にローカル・ポリシーを適用し、選択したローカル・ルーティング情報が含まれる。これらは、ローカルBGPスピーカーが使用する経路である。各経路のネクスト・ホップは、ローカルBGPスピーカーのルーティング・テーブルを介して解決可能でなければならない(MUST)。

c) Adj-RIBs-Out: Adj-RIBs-Outは、ローカルBGPスピーカーがピアへの広告のために選択した情報を格納する。Adj-RIBs-Outに格納されたルーティング情報は、ローカルBGPスピーカーのUPDATEメッセージで運ばれ、ピアに広告される。

要約すると、Adj-RIBs-Inには、ピアからローカルBGPスピーカーに広告された未処理のルーティング情報が格納され、Loc-RIBにはローカルBGPスピーカーの決定プロセスによって選択された経路が格納され、Adj-RIBs-Outにはピアに広告するための経路が(ローカル・スピーカーのUPDATEメッセージを使用することで)まとめられる。

概念モデルでは、Adj-RIBs-In、Loc-RIB、Adj-RIBs-Outを区別しているが、これは実装が3つの別個のルーティング情報のコピーを保持しなければならないことを意味するものでも、要求するものでもない。実装の選択(例えば、情報の3つのコピーとポインタを含む1つのコピー)は、プロトコルによって制約されるものではない。

BGPスピーカーがパケット転送(またはパケット転送に使用される転送テーブルの構築)に使用するルーティング情報は、ルーティング・テーブルに保持される。ルーティング・テーブルには、直接接続されたネットワークへの経路、静的経路、IGPプロトコルから学習した経路、BGPから学習した経路が格納される。あるBGP経路をルーティング・テーブルにインストールすべきかどうか、また、BGP経路が他のソースによってインストールされた同じ宛先への経路を上書きすべきかどうかは、ローカル・ポリシーの決定事項であり、本文書では規定しない。実際のパケット転送に加えて、ルーティング・テーブルは、BGPアップデートで指定されたネクストホップ・アドレスの解決にも使用される(セクション5.1.3を参照)。

4. メッセージ・フォーマット

このセクションでは、BGPで使用するメッセージ・フォーマットについて説明する。

BGPメッセージはTCP接続を使って送信する。メッセージは、完全に受信した後にのみ処理を行う。メッセージの最大サイズは4096オクテットである。すべての実装は、この最大メッセージ・サイズをサポートする必要がある。送信する可能性のある最小メッセージは、データ部分のないBGPヘッダのみで構成する(19オクテット)。

すべてのマルチオクテット・フィールドは、ネットワーク・バイトオーダーである。

4.1. メッセージ・ヘッダの形式

各メッセージには固定サイズのヘッダがある。メッセージの種類によって、ヘッダの後にデータ部分がある場合とない場合がある。このフィールドのレイアウトは以下のとおりである。

bgp-header

マーカー:
この16 オクテットのフィールドは互換性のために含まれている。すべて1に設定しなければならない(MUST)。

Length:
この2オクテットの符号なし整数は、ヘッダを含むメッセージの合計長をオクテット単位で示す。したがって、TCPストリーム内の次のメッセージ(マーカー・フィールド)の位置を特定することができる。Lengthフィールドの値は、常に少なくとも19以上、4096以下でなければならない(MUST)。また、メッセージ・タイプによっては、さらに制限を受ける場合がある。メッセージの後に余分なデータを追加する「パディング」は許可されていない。したがって、Lengthフィールドは、メッセージの残り部分を考慮した上で。必要最小限の値でなければならない(MUST)。

タイプ:
この1オクテット符号なし整数は、メッセージのタイプコードを示す。この文書では、以下のタイプコードを定義する:

1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE

[RFC2918]に、もう1つのタイプコードを定義している。

⚠️ BGPのタイプコード

上記に0がないという点は、Errataで修正されている。

値 名称 参照
0 予約
1 OPEN [RFC4271]
2 UPDATE [RFC4271]
3 NOTIFICATION [RFC4271]
4 KEEPALIVE [RFC4271]
5 ROUTE-REFRESH [RFC2918]
6-255 未割当

<https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-1>

4.2. OPENメッセージ・フォーマット

TCP接続が確立された後、双方から最初に送信されるメッセージはOPENメッセージである。OPENメッセージが受理されると、OPENを確認するKEEPALIVEメッセージが返送される。

固定サイズのBGPヘッダに加えて、OPENメッセージには以下のフィールドが含まれる。

bgp-open

バージョン:
この1オクテットの符号なし整数は、メッセージのプロトコル・バージョン番号を示す。現在のBGPバージョン番号は4である。

自律システム番号:
この2オクテットの符号なし整数は、送信側の自律システム番号を示す。

ホールド時間:
この2オクテットの符号なし整数は、送信側がホールドタイマーの値として提案する秒数を示す。OPENメッセージを受信すると、BGPスピーカーは、設定されているホールド時間とOPENメッセージで受信したホールド時間のうち小さい方の値を使用して、ホールドタイマーの値を計算しなければならない(MUST)。ホールド時間は0秒か、少なくとも3秒でなければならない(MUST)。実装は、ホールド時間に基づいて接続を拒否することもできる(MAY)。計算された値は、送信側からの連続したKEEPALIVEやUPDATEメッセージを受信するまでの経過時間の最大秒数を示す。

BGP識別子:
この4オクテットの符号なし整数は、送信側のBGP識別子を示す。特定のBGPスピーカーは、そのBGPスピーカーに割り当てられたIPアドレスをBGP識別子の値に設定する。BGP識別子の値は起動時に決定され、すべてのローカル・インタフェースとBGPピアで同じ値となる。

オプション・パラメータ長:
この1オクテットの符号なし整数は、オプション・パラメータ・フィールドの合計長をオクテット単位で示す。このフィールドの値が0の場合、オプション・パラメータは存在しない。

オプション・パラメータ:
このフィールドには、オプション・パラメータのリストが含まれており、各パラメータは <パラメータ・タイプ、パラメータ長、パラメータ値>の3組として符号化される。

bgp-open-opt

パラメータ・タイプは、個々のパラメータを明確に識別する1オクテットのフィールドである。パラメータ長は、パラメータ値フィールドの長さをオクテット単位で示す1オクテットのフィールドである。パラメータ値は、パラメータ・タイプ・フィールドの値に従って解釈される可変長フィールドである。

[RFC3392]は、ケーパビリティ・オプション・パラメータを定義している。

OPENメッセージの最小長は29オクテットである(メッセージ・ヘッダを含む)。

4.3. UPDATEメッセージ・フォーマット

UPDATE メッセージは、BGPピア間でルーティング情報を伝達するために使用する。UPDATE メッセージの情報は、さまざまな自律システムの関係を記述するグラフを作成するために使用する。これから説明するルールを適用することで、ルーティング情報のループや他の異常を検出し、AS間ルーティングから取り除くことができる。

UPDATEメッセージは、共通のパス属性を共有するフィージブル経路をピアに広告したり、複数のアンフィージブル経路をサービスから撤回するために使われる(3.1を参照)。UPDATEメッセージは、フィージブル経路を広告すると同時に、複数のアンフィージブル経路のサービスから撤回することもできる(MAY)。UPDATEメッセージには、固定サイズのBGPヘッダを常に含み、以下に示すように他のフィールドも含む(示されたフィールドのいくつかは、すべてのUPDATEメッセージに存在するとは限らないことに留意する)。

bgp-update

⚠️ UPDATEメッセージのパケット

bgp-update-withdraw

撤回経路長:
この2オクテットの符号なし整数は、撤回経路フィールドの合計長をオクテット単位で示す。この値により、以下に規定されているように、ネットワーク層到達可能性情報フィールドの長さを決定することができる。

値が0の場合、サービスの撤回経路が存在せず、撤回経路フィールドがこのUPDATEメッセージに存在しないことを示す。

撤回経路:
これは、サービスの撤回経路のIPアドレス・プレフィックスのリストを含む可変長フィールドである。各IPアドレス・プレフィックスは、<長さ, プレフィックス>という形式の2タプルとして符号化され、そのフィールドを以下に説明する。

bgp-withdraw

これらのフィールドの使用法と意味は以下のとおりである。

a) Length:
長さフィールドは、IPアドレス・プレフィックスの長さをビット単位で示す。長さが0の場合は、プレフィックスはすべてのIPアドレスに一致する(0オクテットのプレフィックスを持つ)。

b) プレフィックス:
プレフィックス・フィールドには、IPアドレスのプレフィックスと、その後にフィールドの末尾がオクテット境界に収まるようにするために必要な最小数の末尾ビットが続く。末尾ビットの値は無関係であることに留意する。

⚠️ パケット上のプレフィックス

下記のBGPパケットから見たプレフィックス部分は、プレフィックス長のオクテット境界で区切られていることが分かる。

bgp-update-prefix

3.0.0.0/8 、2.1.0.0/18、1.0.0.0/21、5.1.100.128/25、4.1.2.0/26の順で広告されているが、下表のようになる。

プレフィックス BGPパケット上 オクテット境界
3.0.0.0/8 08 03 1
2.1.0.0/18 12 02 01 00 3
1.0.0.0/21 15 01 00 00 3
5.1.100.128/25 19 05 01 64 80 4
4.1.2.0/26 1a 04 01 02 00 4

総パス属性長:
この2オクテットの符号なし整数は、パス属性フィールドの合計長をオクテット単位で示す。この値により、以下で規定しているようにネットワーク層到達性フィールドの長さを決定することができる。

値が0の場合、このUPDATEメッセージにネットワーク層到達可能性情報フィールドもパス属性フィールドも存在しないことを示す。

パス属性:
撤回経路のみを運ぶUPDATEメッセージを除き、すべてのUPDATEメッセージには可変長のパス属性シーケンスが存在する。各パス属性は、可変長の3つの要素<属性タイプ, 属性長, 属性値>である。

属性タイプは、属性フラグ・オクテットと、それに続く属性タイプ・コード・オクテットで構成される2オクテット・フィールドである。

bgp-withdraw

属性フラグ・オクテットの上位ビット(ビット0)はオプション・ビットである。これは、属性がオプションか(1に設定されている場合)、周知か(0に設定されている場合)を定義する。

属性フラグ・オクテットの2番目の上位ビット(ビット1)は、推移ビットである。これは、オプション属性が推移的(1に設定されている場合)か、非推移的(0に設定されている場合)かを定義する。

周知属性については、推移ビットは1に設定しなければならない(推移的属性の説明については、セクション5を参照のこと)。

属性フラグ・オクテットの3番目の上位ビット(ビット2)は、部分ビットである。これは、オプションの推移的属性に含まれる情報が部分的なもの(1に設定されている場合)か、完全な情報(0に設定されている場合)かを定義する。周知属性とオプションの非推移的属性については、部分ビットは0に設定しなければならない。

属性フラグ・オクテットの4番目の上位ビット(ビット3)は、拡張Lengthビットである。属性長が1オクテット(0に設定されている場合)か、2オクテット(1に設定されている場合)かを定義する。

属性フラグ・オクテットの下位4ビットは使用されていない。送信時には0でなければならず、受信時には無視しなければならない。

属性タイプ・コード・オクテットには、属性タイプ・コードが含まれる。現在定義されている属性タイプ・コードについては、セクション5で説明している。

属性フラグ・オクテットの拡張Lengthビットが0に設定されている場合、パス属性の3番目のオクテットには、属性データのオクテット単位の長さが含まれる。

属性フラグ・オクテットの拡張Lengthビットが1に設定されている場合、パス属性の3番目と4番目のオクテットには、属性データのオクテット単位の長さが含まれる。

パス属性の残りのオクテットは属性値を表し、属性フラグと属性タイプ・コードに従って解釈される。サポートされている属性タイプ・コード、およびそれらの属性値と用途は以下のとおりである:

⚠️ 属性フィールドについて

まとめると次のようなフォーマットになる。属性データのオクテット長も可変である。

bgp-attribute

属性フラグは下記の通り。
　　ビット0: 周知(W)またはオプション(O)
　　ビット1: 推移的(T)または非推移的(N)
　　ビット2: 完全(C)または部分(P)
　　ビット3: 拡張Length(属性長が1オクテットあるいは2オクテット)
　　ビット4-7: 未使用で0に設定

a) ORIGIN (タイプ・コード1):

ORIGINは、パス情報の発信元を定義する、周知必須属性である。データ・オクテットは以下の値を取ることができる:

値 意味
0 IGP - ネットワーク層到達可能性情報は、発信元ASの内部にある
1 EGP - EGP プロトコル[RFC904]を介して学習されたネットワーク層到達可能性情報
2 INCOMPLETE - 他の手段で学習されたネットワーク層到達可能性情報

この属性の使用法は、5.1.1で定義する。

b) AS_PATH (タイプ・コード2):

AS_PATHは、ASパス・セグメントのシーケンスで構成される、周知必須属性である。各ASパス・セグメントは、3つの要素<パス・セグメント・タイプ, パス・セグメント長, パス・セグメント値>で表される。

パス・セグメント・タイプは、1オクテット長のフィールドで、以下の値が定義されている:

値 セグメント・タイプ
1 AS_SET: UPDATEメッセージで経路が通過したASの順序なし集合
2 AS_SEQUENCE: UPDATEメッセージで経路が通過したASの順序あり集合

パス・セグメント長は、1オクテット長フィールドで、パス・セグメント値フィールド内のASの数(オクテット数ではない)が含まれる。

パス・セグメント値フィールドには、 1つ以上のAS番号が含まれ、それぞれが2オクテット長のフィールドとして符号化される。

この属性の使用法は、5.1.2で定義する。

c) NEXT_HOP (タイプ・コード 3):

これは、UPDATEメッセージのネットワーク層到達可能性情報フィールドに列挙された宛先へのネクストホップとして使用するルータの(ユニキャスト)IPアドレスを定義する、周知必須属性である。

この属性の使用法は、5.1.3で定義する。

d) MULTI_EXIT_DISC (タイプ・コード4):

これは、4オクテットの符号なし整数で、オプションの非推移的属性である。この属性の値は、BGPスピーカーの決定プロセスで、近隣の自律システムへの複数のエントリ・ポイントを区別するために使用することもできる(MAY)。

この属性の使用法は、5.1.4で定義されている。

e) LOCAL_PREF (タイプ・コード5):

LOCAL_PREFは、4オクテットの符号なし整数で、周知必須属性である。BGPスピーカーは、この属性を使用して、広告する経路の優先度を他の内部ピアに通知する。

この属性の使用法は、5.1.5で定義する。

f) ATOMIC_AGGREGATE (タイプ・コード6)

ATOMIC_AGGREGATEは、長さ0の周知任意属性である。

この属性の使用法は、5.1.6で定義する。

g) AGGREGATOR (タイプ・コード7)

AGGREGATORは、6オクテットのオプションの推移的属性である。この属性には、集約経路を形成した最後のAS番号(2オクテットとして符号化)と、それに続く集約経路を形成したBGPスピーカーのIPアドレス(4オクテットとして符号化)が含まれる。これは、スピーカーのBGP識別子に使用されるアドレスと同じ必要がある(SHOULD)。

この属性の使用法は、5.1.7で定義する。

ネットワーク層到達可能性情報:
この可変長フィールドには、IPアドレス・プレフィックスのリストが含まれる。ネットワーク層到達可能性情報の長さ(オクテット単位)は明示的に符号化されていないが、以下で計算できる。

UPDATEメッセージの長さ - 23 - パス属性の合計長 - 撤回経路長

ここで、UPDATEメッセージの長さは固定サイズのBGPヘッダに符号化された値、パス属性の合計長と撤回経路長はUPDATEメッセージの可変部分に符号化された値、23は固定サイズの BGPヘッダ、パス属性の合計長フィールド、撤回経路長フィールドの合計長である。

到達可能性情報は、<長さ, プレフィックス>という形式の1つ以上の2タプルとして符号化される。各フィールドについては、以下で説明する。

bgp-nlri

これらのフィールドの用途と意味は以下のとおりである:

a) Length:
長さフィールドは、IPアドレス・プレフィックスのビット長を示す。長さが0の場合、すべての IPアドレスに一致するプレフィックス(プレフィックス自体が 0オクテット)を示す。

b) プレフィックス:
プレフィックス・フィールドには、IPアドレス・プレフィックスを含み、その後にフィールドの末尾がオクテット境界になるように十分なビットが続く。末尾のビットの値は無関係であることに留意。

UPDATEメッセージの最小長は23オクテットである -- 固定ヘッダ19オクテット + 撤回経路長の2オクテット + 合計パス属性長の2オクテット(撤回経路長の値は0、合計パス属性長の値は 0)。

UPDATEメッセージは、最大で1セットのパス属性を広告できるが、宛先がこれらの属性を共有している場合、複数の宛先を広告できる。あるUPDATEメッセージに含まれるすべてのパス属性は、UPDATEメッセージのNLRIフィールドで伝送されるすべての宛先に適用される。

UPDATEメッセージには、サービスから複数の撤回経路を列挙することができる。このような経路はそれぞれ、その宛先(IPプレフィックスとして表現される)によって識別され、その経路が事前広告されたBGPスピーカー接続の文脈において、その経路を明確に識別する。

UPDATEメッセージは、サービスの撤回経路のみを広告する場合があり、その場合、メッセージにはパス属性やネットワーク層到達可能性情報を含まない。逆に、フィージブル経路のみを広告する場合もあり、その場合は、撤回経路フィールドは不要である。

UPDATEメッセージには、撤回経路フィールドとネットワーク層到達可能性情報フィールドに同じアドレス・プレフィックスを含めるべきではない(SHOULD NOT)。しかし、BGPスピーカーはこの形式のUPDATEメッセージを処理できなければならない(MUST)。BGPスピーカーは、この形式のUPDATEメッセージを、撤回経路にアドレス・プレフィックスが含まれていないかのように処理する必要がある(SHOULD)。

⚠️ コメント

経路はなるべく削除しない。

4.4. KEEPALIVEメッセージ・フォーマット

BGPは、ピアが到達できるかどうかを判断するために、TCPベースのキープアライブ・メカニズムを使用しない。その代わり、KEEPALIVEメッセージを、ホールドタイマーが期限切れにならない程度の頻度でピア間で交換する。KEEPALIVEメッセージ間の適切な最大時間は、ホールド時間間隔の3分の1である。KEEPALIVEメッセージは、1秒に1回以上の頻度で送信してはならない(MUST NOT)。実装では、ホールド時間間隔に応じてKEEPALIVEメッセージを送信するレートを調整することもできる(MAY)。

ネゴシエートされたホールド時間間隔がゼロの場合、定期的なKEEPALIVEメッセージを送信してはならない(MUST NOT)。

KEEPALIVEメッセージはメッセージ・ヘッダのみで構成され、長さは19オクテットである。

4.5. NOTIFICATIONメッセージ・フォーマット

NOTIFICATIONメッセージは、エラー状態を検出したときに送信する。送信後すぐにBGP接続をクローズする。

固定サイズのBGPヘッダに加えて、NOTIFICATIONメッセージには以下のフィールドが含まれる:

bgp-notification

エラー・コード:

この1オクテットの符号なし整数は、NOTIFICATIONのタイプを示す。以下のエラー・コードが定義されている:

エラー・コード シンボル名 参照
1 メッセージ・ヘッダ・エラー セクション6.1
2 OPENメッセージ・エラー セクション6.2
3 UPDATEメッセージ・エラー セクション6.3
4 ホールド・タイマー期限切れ セクション6.5
5 有限状態マシン・エラー セクション6.6
6 停止(Cease) セクション6.7

エラー・サブコード:
この1オクテットの符号なし整数は、報告されたエラーの性質に関するより具体的な情報を提供する。各エラー・コードには、1つ以上のエラー・サブコードが関連付けられている場合がある。適切なエラー・サブコードが定義されていない場合、エラー・サブコード・フィールドにはゼロ(非特定)値を使用する。

メッセージ・ヘッダ・エラー・サブコード:

0 - 未指定
1 - 接続が同期していない。
2 - メッセージ長が不正。
3 - メッセージ・タイプが不正。

OPENメッセージ・エラー・サブコード:

0 - 未指定
1 - サポートしていないバージョン番号。
2 - ピアASが不正。
3 - BGP識別子が不正。
4 - サポートしていないオプション・パラメータ。
5 - [非推奨 - 付録Aを参照]。
6 - 許容できないホールド時間。

UPDATEメッセージ・エラー・サブコード:

0 - 未指定
1 - 属性リストが不正。
2 - 認識しない周知属性。
3 - 既知の属性がない。
4 - 属性フラグ・エラー。
5 - 属性長エラー。
6 - ORIGIN属性が無効。
7 - [非推奨 - 付録Aを参照]。
8 - 無効なNEXT_HOP属性。
9 - オプション属性エラー。
10 - 無効なネットワーク・フィールド。
11 - 不正なAS_PATH。

データ:
この可変長フィールドは、NOTIFICATIONの理由を診断するために使用する。データ・フィールドの内容は、エラー・コードとエラー・サブコードによって異なる。詳細については、セクション6を参照のこと。

データ・フィールドの長さは、メッセージ長フィールドから以下の式で求められることに留意する:

メッセージ長 = 21 + データ長

NOTIFICATIONメッセージの最小長は21オクテットである(メッセージ・ヘッダを含む)。

5. パス属性

このセクションでは、UPDATEメッセージのパス属性について説明する。

パス属性を、次の4つのカテゴリに分類する:

  1. 周知必須属性 (Well-known mandatory)
  2. 周知任意属性 (Well-known discretionary)
  3. オプション推移的属性 (Optional transitive)
  4. オプション非推移的属性 (Optional non-transitive)

BGPの実装は、すべての周知属性を認識しなければならない(MUST)。これらの属性の一部は必須であり、NLRIを含むすべてのUPDATEメッセージに含まなければならない(MUST)。他の属性は任意で、特定のUPDATEメッセージでは送信してもしなくてもよい(MAY or MAY NOT)。

BGPピアが周知属性を更新したら、送信するすべてのアップデートで、これらの属性をピアに渡らなければならない(MUST)。

周知属性に加えて、各パスは1つ以上のオプション属性を含むこともできる(MAY)。すべてのBGPの実装がすべてのオプション属性のサポートを要求または期待されているわけではない。認識できないオプション属性の処理は、属性フラグ・オクテットの推移的ビットの設定によって決定する。認識できない推移的オプション属性を持つパスは受け入れる必要がある(SHOULD)。認識されない推移的オプション属性を持つパスが受け入れられ、他のBGPピアに渡された場合、そのパスの認識されない推移的オプション属性は、パスと共に、属性フラグ・オクテットの部分ビットを1に設定して他のBGPピアに渡らなければならない(MUST)。認識される推移的オプション属性を持つパスが受け入れられ、他のBGPピアに渡り、属性フラグ・オクテットの部分ビットが前のASによって1に設定された場合、現在のASによって0に戻してはならない(MUST NOT)。認識されない非推移的オプション属性は、黙って無視し、他のBGPピアに渡らないようにしなければならない(MUST)。

新しい、推移的オプション属性は、オリジネータやパス内の他のBGPスピーカーがパスに付加することもできる(MAY)。オリジネータが付加しない場合、属性フラグ・オクテットの部分ビットは1に設定する。新しい非推移的オプション属性を付加するためのルールは、属性の性質によって異なる。各新規の非推移的オプション属性の文書には、そのようなルールを含むことが前提である(MULTI_EXIT_DISC属性の説明に例がある)。すべてのオプション属性(推移的および非推移的の両方)は、パス内のBGPスピーカーによって(適切であれば)更新することもできる(MAY)。

UPDATEメッセージの送信者は、UPDATEメッセージ内のパス属性を属性タイプの昇順に並べる必要がある(SHOULD)。UPDATEメッセージの受信者は、UPDATE メッセージ内のパス属性の順序が間違っていても処理できるように準備しなければならない(MUST)。

同じ属性(同じタイプの属性)は、UPDATEメッセージのパス属性フィールド内に複数回出現させることはできない。

必須カテゴリは、UPDATEメッセージにNLRIが含まれている場合、IBGP交換とEBGP交換の両方に存在しなければならない(MUST)属性を指す。プロトコル拡張メカニズムの目的上、オプションとして分類される属性は、純粋に任意(discretionary)、任意(discretionary)、必須(required)、または状況によっては許可されない場合がある。

属性 EBGP IBGP
ORIGIN 必須 必須
AS_PATH 必須 必須
NEXT_HOP 必須 必須
MULTI_EXIT_DISC 任意 任意
LOCAL_PREF セクション5.1.5を参照 必須
ATOMIC_AGGREGATE セクション5.1.6および9.1.4を参照 セクション5.1.6および9.1.4を参照
AGGREGATOR 任意 任意
⚠️ まとめ

属性は、以下のようにまとめることができる。

bgp-attr

タイプ
コード		 属性 タイプ プリファレンス
0 予約
1 ORIGIN 周知必須 IGP<EGP<incomplete
2 AS_PATH 周知必須 短いパス
3 NEXT_HOP 周知必須 パスが短いあるいはIGPメトリックが小さい
4 MULTI_EXIT_DISC オプション非推移的 小さい値
5 LOCAL_PREF 周知任意 大きい値
6 ATOMIC_AGGREGATE 周知任意 パス選択には使わない
7 AGGREGATOR オプション推移的 パス選択には使わない
8 COMMUNITY オプション推移的 パス選択には使わない
9 ORIGINATOR_ID オプション非推移的 パス選択には使わない
10 CLUSTER_LIST オプション非推移的 パス選択には使わない
14 MP_REACH_NLRI オプション非推移的
15 MP_UNREACH_NLRI オプション非推移的
16 EXTENDED COMMUNITY オプション推移的
17 AS4_PATH オプション推移的 短いパス
18 AS4_AGGREGATOR オプション推移的 パス選択には使わない

<https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2>

5.1. パス属性の使用法

各BGPパス属性の使用法については、以下のセクションで説明する。

5.1.1. ORIGIN

ORIGINは、周知必須属性である。ORIGIN属性は、関連するルーティング情報を発信するスピーカーが生成する。この値は、他のいかなるスピーカーも変更してはならない(SHOULD NOT)。

5.1.2. AS_PATH

AS_PATHは周知必須属性である。この属性は、UPDATEメッセージによって伝送されたルーティング情報が通過した自律システムを明確にする。このリストの構成要素は、AS_SETまたはAS_SEQUENCEである。

BGPスピーカーが他のBGPスピーカーのUPDATEメッセージから学習した経路を伝播する場合、経路の送信先となるBGPスピーカーの設置場所に基づいて、経路のAS_PATH属性を変更する。

a) BGPスピーカーが内部ピアに経路を広告する場合、広告するスピーカーは、経路に関連付けられたAS_PATH属性を変更してはならない(SHALL NOT)。

b) BGPスピーカーが経路を外部ピアに広告する場合、広告するスピーカーは、以下のようにAS_PATH属性を更新する。

  1. AS_PATHの最初のパス・セグメントがAS_SEQUENCEタイプの場合、ローカル・システムは自身のAS番号をシーケンスの最後の要素として先頭に追加する(プロトコル・メッセージのオクテットの位置に対して左端に置く)。先頭に追加することによって、AS_PATHセグメントがオーバーフローを引き起こす(つまり、255を超えるASが存在する)場合、AS_SEQUENCEタイプの新しいセグメントを先頭に追加し、この新しいセグメントに自身のAS番号を先頭に追加する必要がある(SHOULD)。

    ⚠️ ASパス・セグメントがオーバーフローを起こした場合

    上記説明が実装でどうなっているかを検証してみた。ExaBGPを使って、非常に長いASパス(255を超えるAS)を持つ経路を送ったところ、下記のようなBGPパケットとなった(Wireshark)。オーバーフローで、ASパス・セグメントが追加され、2つとなっていることが分かる。また、拡張Lengthビットが1にセットされ、2オクテットとなっていることも確認できる。

    bgp-aspath

  2. AS_PATHの最初のパス・セグメントがAS_SETタイプの場合、ローカル・システムはAS_SEQUENCEタイプの新しいパス・セグメントをAS_PATHの先頭に追加し、そのセグメントに自身のAS番号を含める。

  3. AS_PATHが空の場合、ローカル・システムはAS_SEQUENCEタイプのパス・セグメントを作成し、そのセグメントに自身のASを配置し、そのセグメントをAS_PATHに配置する。

BGPスピーカーが経路を発信するとき、以下のことを行う:

a) 発信元スピーカーは、外部ピアに送信するすべてのUPDATEメッセージのAS_PATH属性に、AS_SEQUENCEタイプのパス・セグメントに自身のAS番号を含める。この場合、発信元スピーカーの自律システムのAS番号がパス・セグメントの唯一のエントリとなり、このパス・セグメントがAS_PATH属性の唯一のセグメントとなる。

b) 発信元スピーカーは、内部ピアに送信するすべてのUPDATEメッセージに空のAS_PATH属性を含める。(空のAS_PATH属性とは、長さフィールドに値0が含む属性である)。

AS_PATH属性の変更がローカル・システムのAS番号を含めるか先頭に追加する必要がある場合は、ローカル・システムはAS_PATH属性に自身のAS番号のインスタンスを複数含めるか先頭に追加することもできる(MAY)。これはローカル設定で制御する。

5.1.3. NEXT_HOP

NEXT_HOPは、UPDATEメッセージに列挙されている宛先へのネクストホップとして使用する必要があるルータのIPアドレスを定義する周知必須属性である。NEXT_HOP属性は以下のように計算する:

  1. 内部ピアにメッセージを送信する場合、経路がローカル起点でない場合、BGPスピーカーは、自身のIPアドレスをNEXT_HOPとしてアナウンスするように明示的に設定されていない限り、NEXT_HOP属性を変更してはならない(SHOULD NOT)。ローカルで生成された経路を内部ピアにアナウンスする場合、BGPスピーカーは、アナウンスされたネットワークがスピーカにとって到達可能なルータのインタフェース・アドレスをNEXT_HOPとして使用する必要がある(SHOULD)。経路がスピーカーに直接接続されているか、スピーカーにとってアナウンスされたネットワークに到達可能なルータのインタフェース・アドレスが内部ピアのアドレスの場合、BGPスピーカーはNEXT_HOP属性に自身のIPアドレス(ピアに到達するために使用されるインタフェースのアドレス)を使用する必要がある(SHOULD)。

  2. 外部ピアXにメッセージを送信する場合、そのピアはスピーカーから1 IPホップ離れている場合:

    • アナウンスされる経路が内部ピアから学習されたか、ローカルで生成されたものの場合、BGPスピーカーは、ピアXがこのアドレスと共通のサブネットを共有していれば、NEXT_HOP属性に、アナウンスされたネットワークがスピーカーにとって到達可能な内部ピア・ルータ(または内部ルータ)のインタフェース・アドレスを使うことができる。これは、「サードパーティ」のNEXT_HOP属性の一形態である。

    • それ以外の場合、アナウンスされている経路が外部ピアから学習されたものである場合、ピアXがこのアドレスと共通のサブネットを共有していれば、スピーカーはNEXT_HOP 属性に、スピーカー自身がローカル経路の計算に使用している隣接ルータのIPアドレス(受信したNEXT_HOP属性から分かる)を使用できる。これは、「サードパーティ」NEXT_HOP属性の第二の形態である。

    • それ以外の場合、経路が広告先の外部ピアがアナウンスするBGPスピーカーのインタフェースの1つと共通のサブネットを共有している場合、スピーカーはNEXT_HOP属性にそのようなインタフェースに関連付けられたIPアドレスを使用することもできる(MAY)。これは、「ファーストパーティ」NEXT_HOP属性と呼ばれる。

    • デフォルトでは(上記の条件のいずれも当てはまらない場合)、BGPスピーカーは、ピアXとのBGP接続を確立するために使用するインタフェースのIPアドレスをNEXT_HOP属性に使用する必要がある(SHOULD)。

  3. 外部ピアXにメッセージを送信する場合、そのピアはスピーカーから複数のIPホップ離れている場合(別名「マルチホップEBGP」):

    • スピーカーはNEXT_HOP属性を伝播するように設定することもできる(MAY)。この場合、スピーカーがピアの学習した経路を広告するとき、広告された経路のNEXT_HOP属性は、学習した経路のNEXT_HOP属性とまったく同じである(スピーカーはNEXT_HOP属性を変更しない)。

    • デフォルトでは、BGPスピーカーは、ピアXとのBGP接続を確立するために、NEXT_HOP属性で使用するインタフェースのIPアドレスを使用する必要がある(SHOULD)。

通常、NEXT_HOP属性は、利用可能な最短パスが使用されるように選択される。BGPスピーカーは、不完全にブリッジされたメディアを処理するために、サードパーティのNEXT_HOP属性の広告を無効にする機能をサポートしなければならない(MUST)。

BGPスピーカーが生成した経路は、そのピアのアドレスをNEXT_HOPとして使用してピアに広告してはならない(SHALL NOT)。BGPスピーカーは、自身をネクストホップとする経路をインストールしてはならない(SHALL NOT)。

NEXT_HOP属性は、BGPスピーカーによって、関連する宛先にトランジット・パケットを転送するために使用する必要がある(SHOULD)実際のアウトバウンド・インタフェースと隣接(immediate)ネクストホップ・アドレスを決定するために使用される。

隣接ネクストホップ・アドレスは、NEXT_HOP属性のIPアドレスに対して、ルーティング・テーブルの内容を使用して、再帰経路の検索操作を実行し、等コストのエントリが複数存在する場合は1つのエントリを選択して決定する。NEXT_HOP属性のIPアドレスを解決するルーティング・テーブル・エントリは、常にアウトバウンド・インタフェースを指定する。エントリが接続されたサブネットを指定するが、ネクストホップ・アドレスを指定していない場合、NEXT_HOP属性のアドレスが隣接ネクストホップ・アドレスとして使用する必要がある(SHOULD)。エントリがネクストホップ・アドレスも指定している場合、このアドレスがパケット転送の隣接ネクストホップ・アドレスとして使用する必要がある(SHOULD)。

5.1.4. MULTI_EXIT_DISC

MULTI_EXIT_DISCは、外部(AS間)リンク、同じ隣接ASへの複数の出口または入口ポイントを区別するために使用されることを意図した、オプションの非推移的属性である。MULTI_EXIT_DISC属性の値は、メトリックと呼ばれる4オクテットの符号なし数値である。他のすべての要素が等しければ、メトリックの低い出口ポイントを優先する必要がある(SHOULD)。EBGP上で受信した場合、MULTI_EXIT_DISC属性は、同じAS内の他のBGPスピーカーにIBGP経由で伝播することもできる(MAY)(9.1.2.2も参照)。隣接ASから受信したMULTI_EXIT_DISC属性は、他の隣接ASに伝播してはならない(MUST NOT)。

BGPスピーカーは、経路からMULTI_EXIT_DISC属性を削除できる(ローカル設定に基づく)メカニズムを実装しなければならない(MUST)。BGPスピーカーが経路からMULTI_EXIT_DISC属性を削除するように設定されている場合、この削除は経路の優先度を決定する前と経路選択を実行する前に行わなければならない(MUST)(決定プロセス・フェーズ1と2)。

実装は、(ローカル設定に基づいて)EBGP経由で受信したMULTI_EXIT_DISC属性の値も変更することもできる(MAY)。BGPスピーカーがEBGP経由で受信したMULTI_EXIT_DISC属性の値を変更するように設定されている場合、値の変更は経路の優先度を決定する前と経路選択を実行する前(決定プロセス・フェーズ1と2)に行わなければならない(MUST)。これに関する必要な制限については、セクション9.1.2.2を参照のこと。

5.1.5. LOCAL_PREF

LOCAL_PREFは、あるBGPスピーカーが他の内部ピアに送信するすべてのUPDATEメッセージに含まなければならない(SHALL)周知属性である。BGPスピーカーは、ローカルに設定されたポリシーに基づいて、各外部経路の優先度を計算し、内部ピアに経路を広告するときに優先度を含めなければならない(SHALL)。優先度の高い方が優先されなければならない(MUST)。BGPスピーカーは、LOCAL_PREFを介して学習した優先度を決定プロセスで使用する(セクション9.1.1を参照)。

BGPスピーカーは、BGPコンフェデレーション[RFC3065]の場合を除き、外部ピアに送信するUPDATEメッセージにこの属性を含めてはならない(MUST NOT)。外部ピアから受信したUPDATEメッセージにこの属性が含まれている場合、BGPコンフェデレーション[RFC3065]の場合を除き、受信したスピーカーはこの属性を無視しなければならない(MUST)。

5.1.6. ATOMIC_AGGREGATE

ATOMIC_AGGREGATEは、周知任意属性である。

BGPスピーカーがピアに広告する目的で複数の経路を集約するとき、集約された経路のAS_PATHは通常、集約が形成されたASの集合から形成されたAS_SETを含む。多くの場合、ネットワーク管理者は、AS_SETなしで、経路ループを形成することなく、安全に集約を広告できるかどうかを判断できる。

AS_SETを削除した結果として、集約された経路のAS_PATHに存在するAS番号の少なくとも一部を集約が除外する場合、集約された経路はピアに広告されるときに、ATOMIC_AGGREGATE属性を含めるべきである(SHOULD)。

ATOMIC_AGGREGATE属性を持つ経路を受信したBGPスピーカーは、他のスピーカーに経路を伝播するときにその属性を削除すべきではない(SHOULD NOT)。

ATOMIC_AGGREGATE属性を持つ経路を受信したBGPスピーカーは、他のBGPスピーカーにこの経路を広告するときに、その経路のNLRIを(9.1.4で定義されているように)モアスペシフィックにしてはならない(MUST NOT)。

ATOMIC_AGGREGATE属性を持つ経路を受信したBGPスピーカーは、ループ・フリーの特性を持ちながらも、経路のNLRIで指定される宛先への実際のパスは、経路のAS_PATH属性で指定されるパスではない可能性があるという事実を認識する必要がある。

5.1.7. AGGREGATOR

AGGREGATORはオプションの推移的属性であり、集約によって形成されるアップデートに含めることもできる(MAY)(セクション9.2.2.2を参照)。経路集約を行うBGPスピーカーは、AGGREGATOR属性を追加することもできる(MAY)。AGGREGATOR属性は、それ自身のAS番号とIPアドレスを含むものとする(SHALL)。IPアドレスは、スピーカーのBGP識別子と同じ必要がある(SHOULD)。

6. BGPのエラー処理

このセクションでは、BGPメッセージの処理中にエラーが検出された場合の対処方法について説明する。

ここで説明する条件のいずれかが検出されると、指定されたエラー・コード、エラー・サブコード、およびデータ・フィールドを含むNOTIFICATIONメッセージが送信され、BGP接続がクローズされる(NOTIFICATIONメッセージを送信せず、BGP接続をクローズしないことが明示的に指定されている場合を除く)。エラー・サブコードが指定されていなければ、ゼロを使わなければならない(MUST)。

「the BGP connection is closed」(BGP接続がクローズされた)というフレーズは、TCP接続がクローズされ、関連つけられたAdj-RIB-Inがクリアされ、そのBGP接続のすべてのリソースが割り当て解除されたことを意味する。リモート・ピアに関連付けられたLoc-RIBのエントリは無効としてマークされる。ローカルシステムは、無効とマークされた経路の宛先に対する最適経路を再計算する。無効な経路がシステムから削除される前に、ピアに対して、無効とマークされた経路を撤回するか、無効な経路がシステムから削除される前に新しい最適経路を広告する。

明示的に指定されない限り、エラーを示すために送信されるNOTIFICATIONメッセージのデータ・フィールドは空である。

⚠️ エラーコード/サブエラーコードの一覧
エラー
コード		 エラー
サブコード		 説明
1 Msg Header Error
1 Connection Not Synchronized
2 Bad Msg Legth
3 Bad Msg Type
2 Open Msg error
1 Unsupported Version Number
2 Bad Peer AS
3 Bad BGP ID
4 Unsupported Optional Parameter
5 Authentication Failure
6 Unacceptable Holdtime
7 Unsupported Capability
11 Role Mismatch
3 Update Msg Error
1 Malformed Attribute List
2 Unrecognized Well-known Attribute
3 Missing Well-known Attribute
4 Attribute Flag Error
5 Attribute Length Error
6 Invalid ORIGIN Atrribute
8 Invalid NEXT_HOP Attribute
9 Optional Attribute Error
10 Invalid Network Field
11 Malformed AS_PATH
4 Holdtime Expired
5 Finite-Machine Error
1 Receive Unexpected Message in OpenSent State
2 Receive Unexpected Message in OpenConfirm State
3 Receive Unexpected Message in Established State
6 Ceased
1 Maximum Number of Prefixes Reached
2 Administrative Shutdown
3 Peer De-configured
4 Administrative Reset
5 Connection Rejected
6 Other Configuration Change
7 Connection Collision Resolution
8 Out of Resources
9 Hard Reset
10 BFD Down
7 ROUTE-REFRESH Message Error
1 Invalid Message Length

<https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-3>

6.1. メッセージ・ヘッダ・エラーの処理

メッセージ・ヘッダの処理中に検出されたすべてのエラーは、エラー・コード・メッセージ・ヘッダー・エラーでNOTIFICATIONメッセージを送信することで示さなければならない(MUST)。エラー・サブコードは、エラーの性質を詳しく説明する。

メッセージ・ヘッダのマーカー・フィールドの期待値はすべて1である。メッセージ・ヘッダのマーカー・フィールドが期待された値でない場合、同期エラーが発生し、エラー・サブコードは「Connection Not Synchronized」(接続が同期されていない)に設定しなければならない(MUST)。

少なくとも以下の1つが真である場合:

  • メッセージ・ヘッダのLengthフィールドが19より小さいか4096より大きい場合、

  • OPENメッセージのLengthフィールドがOPENメッセージの最小長より短い場合、

  • UPDATEメッセージのLengthフィールドがUPDATEメッセージの最小長より短い場合、

  • KEEPALIVEメッセージのLengthフィールドが19でない場合、

  • NOTIFICATIONメッセージのLengthフィールドがNOTIFICATIONメッセージの最小長より短い場合、

エラー・サブコードはBad Message Lengthに設定しなければならない(MUST)。データ・フィールドは、エラーのあるLengthフィールドが含まなければならない(MUST)。

メッセージ・ヘッダのタイプ・フィールドが認識できない場合、エラー・サブコードはBad Message Typeに設定しなければならない(MUST)。データ・フィールドには、エラーのあるタイプ・フィールドが含まなければならない(MUST)。

6.2. OPENメッセージのエラー処理

OPENメッセージの処理中に検出されたすべてのエラーは、エラー・コードOPENメッセージ・エラーでNOTIFICATIONメッセージを送信することで示さなければならない(MUST)。エラー・サブコードは、エラーの具体的な性質を詳しく説明する。

受信したOPENメッセージのバージョン・フィールドにあるバージョン番号がサポートされていない場合、エラー・サブコードは「Unsupported Version Number」(サポートされていないバージョン番号)に設定しなければならない。データ・フィールドは2オクテットの符号なし整数であり、リモートBGPピアが提示したバージョン(受信したOPENメッセージに示されている)よりも小さい、ローカルでサポートされている最大バージョン番号を示す。または、ローカルでサポートされている最小バージョン番号がリモートBGPピアが提示したバージョンよりも大きい場合は、ローカルでサポートされている最小バージョン番号を示す。

OPENメッセージの自律システム・フィールドが受け入れられない場合、エラー・サブコードは「Bad Peer AS」に設定しなければならない。受け入れ可能な自律システム番号の決定は、このプロトコルの範囲外である。

OPENメッセージのホールド時間フィールドが受け入れられない場合、エラー・サブコードは「Unacceptable Hold Time」(受け入れられないホールド時間)に設定しなければならない(MUST)。実装は、1秒または2秒のホールド時間値を拒否しなければならない(MUST)。実装は、提案されたホールド時間を拒否することもできる(MAY)。ホールド時間を受け入れる実装では、ホールド時間についてネゴシエートされた値を使用しなければならない(MUST)。

OPENメッセージのBGP識別子フィールドが構文的に正しくない場合、エラー・サブコードは「Bad BGP Identifier」(不正なBGP識別子)に設定しなければならない(MUST)。構文的に正しいとは、BGP識別子フィールドが有効なユニキャストIPホスト・アドレスを表していることを意味する。

OPENメッセージのオプション・パラメータの1つが認識されない場合、エラー・サブコードは「Unsupported Optional Parameters」(サポートされていないオプション・パラメータ)に設定しなければならない(MUST)。

OPENメッセージのオプション・パラメータの1つが認識されるが、不正な形式である場合、エラー・サブコードは0(未指定)に設定しなければならない(MUST)。

6.3. UPDATEメッセージのエラー処理

UPDATEメッセージの処理中に検出されたすべてのエラーは、エラー・コードUPDATEメッセージ・エラーを含むNOTIFICATIONメッセージを送信することで示さなければならない。エラー・サブコードは、エラーの具体的な種類(nature)を詳しく説明する。

UPDATEメッセージのエラー・チェックは、パス属性を検査から始まる。撤回経路長または属性合計長が超過する場合(つまり、撤回経路長 + 属性合計長 + 23がメッセージ長を超える場合)、エラー・サブコードは「Malformed Attribute List」(不正な属性リスト)に設定しなければならない(MUST)。

認識された属性に属性フラグがあり、属性タイプ・コードと矛盾する場合、エラー・サブコードは属性フラグ・エラーに設定しなければならない(MUST)。データ・フィールドには、エラーのある属性(タイプ、長さ、値)が含まれていなければならない(MUST)。

認識された属性に、属性タイプ・コードに基づく予想される長さと矛盾する属性長がある場合、エラー・サブコードは「Attribute Length Error」(属性長エラー)に設定しなければならない(MUST)。データ・フィールドには、エラーのある属性(タイプ、長さ、値)が含まれていなければならない(MUST)。

周知必須属性のいずれかが存在しない場合、エラー・サブコードを「Missing Well-known Attribute」(周知属性が存在しない)に設定しなければならない(MUST)。データ・フィールドには、存在しない周知属性の属性タイプ・コードが含まれていなければならない(MUST)。

周知必須属性のいずれかが認識されない場合は、エラー・サブコードを「Unrecognized Well-known Attribute」(認識されない周知属性)に設定しなければならない(MUST)。データ・フィールドには、認識されない属性(タイプ、長さ、および値)が含まれていなければならない(MUST)。

ORIGIN属性に未定義の値がある場合、エラー・サブコードを「Invalid Origin Attribute」(無効な Origin属性)に設定しなければならない(MUST)。データ・フィールドには、認識されない属性(タイプ、長さ、および値)が含まれていなければならない(MUST)。

NEXT_HOP属性フィールドが構文的に正しくない場合は、エラー・サブコードを「Invalid NEXT_HOP Attribute」(無効なNEXT_HOP属性)に設定しなければならない(MUST)。データ・フィールドには、認識されない属性(タイプ、長さ、および値)が含まれていなければならない(MUST)。構文的に正しいとは、NEXT_HOP属性が有効なIPホスト・アドレスを表していることを意味する。

NEXT_HOPのIPアドレスが意味的に正しいと見なされるには、以下の基準を満たさなければならない(MUST)。

a) 受信スピーカーのIPアドレスであってはならない(MUST NOT)。

b) 送信者と受信者が互いに1 IPホップ離れているEBGPの場合、NEXT_HOPのIPアドレスは、BGP接続を確立するために使われる送信者のIPアドレスか、NEXT_HOPのIPアドレスに関連付けられたインタフェースが受信BGPスピーカーと共通のサブネットを共有しなければならない(MUST)。

NEXT_HOP 属性が意味的に正しくない場合、エラーをログに記録し(SHOULD)、経路を無視する必要がある(SHOULD)。この場合、NOTIFICATIONメッセージは送信せず(SHOULD NOT)、接続を閉じるべきではない(SHOULD NOT)。

AS_PATH属性は、構文的に正しいかどうかをチェックする。パスが構文的に正しくない場合、エラー・サブコードを「Malformed AS_PATH」(不正なAS_PATH)に設定しなければならない(MUST)。

外部ピアからUPDATEメッセージを受信した場合、ローカル・システムは、プロトコル・メッセージ内のオクテットの位置に関して最も左側にあるAS_PATH属性のASが、メッセージを送信したピアの自律システム番号と等しいかどうかをチェックすることもできる(MAY)。チェックの結果、一致しないことが判明した場合、エラー・サブコードを「Malformed AS_PATH」(不正なAS_PATH)に設定しなければならない(MUST)。

オプション属性が認識された場合は、この属性の値がチェックしなければならない(MUST)。エラーが検出された場合、エラー・サブコードをOptional Attribute Errorに設定しなければならない(MUST)。データ・フィールドは属性(タイプ、長さ、値)が含まれていなければならない(MUST)。

UPDATEメッセージ内に属性が複数回現れた場合、エラー・サブコードは「Malformed Attribute List」(不正な属性リスト)に設定しなければならない(MUST)。

UPDATEメッセージのNLRIフィールドは、構文の有効性をチェックする。このフィールドが構文的に正しくない場合、エラー・サブコードは「Invalid Network Field」(無効なネットワーク・フィールド)に設定しなければならない(MUST)。

NLRIフィールドのプレフィックスが意味的に正しくない場合(例えば、予期しないマルチキャストIPアドレスなど)、エラーはローカルに記録され(SHOULD)、プレフィックスは無視する必要がある(SHOULD)。

正しいパス属性を含むが、NLRIを含まないUPDATEメッセージは、有効なUPDATEメッセージとして扱われるものとする。

6.4. NOTIFICATION メッセージのエラー処理

ピアがNOTIFICATIONメッセージを送信し、メッセージの受信者がそのメッセージにエラーを検出した場合、受信者はNOTIFICATIONメッセージを使用してそのエラーをピアに報告することはできない。このようなエラー(例えば、認識できないエラー・コードやエラー・サブコードなど)は、警告し、ローカルに記録し、ピアの管理者に通知する必要がある(SHOULD)。ただし、そのための手段は、この文書の範囲外である。

6.5. ホールド・タイマーの期限切れエラー処理

OPENメッセージのホールド時間フィールドで指定された期間内に、KEEPALIVE、UPDATE、および/またはNOTIFICATIONメッセージが連続してシステムが受信しない場合、エラー・コード「Hold Timer Expired」(ホールド・タイマーの期限切れ)を含むNOTIFICATIONメッセージを送信し、BGP接続をクローズする。

6.6. 有限状態マシン・エラー処理

BGP有限状態マシンによって検出されたエラー(予期しないイベントの受信など)は、エラー・コード「Finite State Machine Error」(有限状態マシン・エラー)を含むNOTIFICATIONメッセージを送信することで示す。

6.7. 停止(Cease)

このセクションで示されるような致命的なエラーがない場合、BGPピアは任意の時点で、エラー・コード「Cease」(停止)を含むNOTIFICATIONメッセージを送信してBGP接続をクローズすることを選択することもできる(MAY)。ただし、このセクションで示されるような致命的なエラーが存在する場合には、Case NOTIFICATIONメッセージを使用してはならない(MUST NOT)。

BGPスピーカーは、ネイバーから受け入れるアドレス・プレフィックスの数について、ローカルに設定された上限を課す機能をサポートすることもできる(MAY)。上限に達した場合、ローカル設定の制御下で、(a) ネイバーからの新しいアドレス・プレフィックスを破棄する(ただし、ネイバーとの BGP接続は維持したままとする)、または (b) ネイバーとのBGP接続を終了する、のいずれかを行う。BGPスピーカーが、ネイバーから受信したアドレス・プレフィックスの数が、ローカルに設定された上限を超えたことを理由に、ネイバーとのBGP接続を終了すると決定した場合、スピーカーはエラー・コード「Cease」(停止)を指定したNOTIFICATIONメッセージをネイバーに送信しなければならない(MUST)。スピーカーはこのことをローカルにログに記録することもできる(MAY)。

6.8. BGP接続衝突検出

BGPスピーカーのペアが同時に相互にBGP接続を確立しようとすると、2つの並列接続が形成される。これらの接続のうちの1つで使用されている送信元IPアドレスが、もう一方の接続で使用されている宛先IPアドレスと同じで、最初の接続で使用されている宛先IPアドレスが、もう一方の接続で使用される送信元IPアドレスと同じ場合、接続の衝突が発生する。接続の衝突が発生した場合、接続のうちの1つをクローズしなければならない(MUST)。

BGP識別子の値に基づいて、衝突が発生した場合にどのBGP接続を保持するかを検出するための規則が確立されている。この規則では、衝突に関与したピアのBGP識別子を比較し、より大きい値のBGP識別子を持つBGPスピーカーが開始した接続のみを保持する。

⚠️ より大きい値とは

後述の「BGP識別子の比較は、ホスト・バイト・オーダーに変換」の通り。

OPENメッセージを受信すると、ローカル・システムはOpenConfirm状態にあるすべての接続を検証しなければならない(MUST)。BGPスピーカーは、プロトコル以外の手段でピアのBGP識別子が分かっている場合、OpenSent状態にある接続を検査することもできる(MAY)。これらの接続の中に、BGP 識別子がOPENメッセージ内のものと同じBGP識別子を持つリモートBGPスピーカーへの接続があり、この接続がOPENメッセージを受信した接続と衝突する場合、ローカル・システムは以下の衝突解決手順を実行する。

  1. ローカル・システムのBGP識別子が、OPENメッセージで指定されているリモート・システムのBGP識別子と比較する。BGP識別子の比較は、ホスト・バイト・オーダーに変換し、4オクテットの符号なし整数として処理することで行う。

    ⚠️ サンプルコード(Python)
    $ python3
Python 3.9.6 (default, Mar 29 2024, 10:51:09) 
[Clang 15.0.0 (clang-1500.3.9.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> import socket
>>> socket.ntohl(struct.unpack('I', socket.inet_aton('192.168.1.1'))[0])
3232235777
>>>

  1. ローカルのBGP識別子の値がリモートのBGP識別子の値より小さい場合、ローカル・システムは既存のBGP接続(すでにOpenConfirm状態にある接続)を閉じ、リモート・システムが開始したBGP接続を受け入れる。

  2. それ以外の場合、ローカル・システムは新しく作成されたBGP接続(新たに受信したOPENメッセージに関連付けられている接続)を閉じ、既存の接続(すでにOpenConfirm状態にある接続) を引き続き使用する。

設定で許可されていない限り、Established状態にある既存のBGP接続と接続衝突が起きた場合、新たに作成された接続を閉じる。

Idle、Connect、Activeの状態にある接続では、接続衝突を検出できないことに留意すること。

BGP接続の切断(衝突解決手順の結果)は、エラー コード「Cease」を含むNOTIFICATIONメッセージを送信する。

7. BGPのバージョン・ネゴシエーション

BGPスピーカーは、各BGPスピーカーがサポートするバージョン番号のうち最も大きい番号から順に始めて、BGP接続の確率を複数回試みることで、プロトコルのバージョンをネゴシエートすることができる。OPEN試行がエラー・コード「OPEN Message Error」(OPENメッセージ・エラー)とエラー・サブコード「Unsupported Version Number」(サポートされないバージョン番号)で失敗した場合、BGPスピーカーは、試行したバージョン番号、ピアが試行したバージョン番号、NOTIFICATIONメッセージでピアから渡されたバージョン番号、およびサポートするバージョン番号を入手できる。2つのピアが1つ以上の共通バージョンをサポートしている場合、これにより、両者が最も大きい共通バージョンを迅速に決定できる。BGPバージョン・ネゴシエーションをサポートするために、BGPの将来バージョンでは、OPENメッセージとNOTIFICATIONメッセージのフォーマットを維持しなければならない(MUST)。

⚠️ バージョン・ネゴシエーションについて

今の実装は、バージョン・ネゴシエーションは行われていないと思われる。バージョン4でなければ、エラーとなるようにコーディングされている。

(パート1の終わり)

更新履歴

  • 2024.8.16
  • 2024.8.26
GitHubで編集を提案

Discussion