2. Prefix-to-AS Mapping Database (プレフィックスから AS へのマッピングデータベース)
2. Prefix-to-AS Mapping Database (プレフィックスから AS へのマッピングデータベース)
BGP スピーカーは, キャッシュから検証済みオブジェクトをローカルストレージにロードします。ロードされるオブジェクトには, (IP アドレス, プレフィックス長, 最大長, 起点 AS 番号) という内容があります。このようなローカルに保存されたオブジェクトを "Validated ROA Payload" または "VRP" と呼びます。
"VRP" に加えて, いくつかの用語を定義します。これらの用語が使用される場合, 大文字で表記されます:
-
Prefix (プレフィックス): (IP アドレス, プレフィックス長), 慣習的に解釈されます ([RFC4632] を参照)。
-
Route (ルート): [RFC4271] のセクション 1.1 で定義されているように, 受信した BGP
UPDATEから導出されたデータ。ルートには1つのプレフィックスとAS_PATHが含まれます。プレフィックスを特徴付ける他の属性も含まれる場合があります。 -
VRP Prefix (VRP プレフィックス): VRP からのプレフィックス。
-
VRP ASN (VRP AS 番号): VRP からの起点 AS 番号。
-
Route Prefix (ルートプレフィックス): ルートから導出されたプレフィックス。
-
Route Origin ASN (ルート起点 AS 番号): 次のようにルートから導出された起点 AS 番号:
-
そのセグメントが
AS_SEQUENCEタイプである場合, ルート内のAS_PATH属性の最終セグメントの右端の AS, または -
そのセグメントが
AS_CONFED_SEQUENCEまたはAS_CONFED_SETタイプである場合, またはAS_PATHが空である場合は, BGP スピーカー自身の AS 番号, または -
AS_PATH属性の最終セグメントが他のタイプである場合は, 識別値 "NONE"。
-
-
Covered (カバーされる): VRP プレフィックス長がルートプレフィックス長以下であり, VRP プレフィックス長で指定されたすべてのビットについて VRP プレフィックスアドレスとルートプレフィックスアドレスが同一である場合, ルートプレフィックスは VRP によってカバーされると言います。(つまり, ルートプレフィックスは VRP プレフィックスと同一であるか, VRP プレフィックスよりも詳細です。)
-
Matched (マッチする): ルートプレフィックスがその VRP によってカバーされ, ルートプレフィックス長が VRP 最大長以下であり, ルート起点 ASN が VRP ASN と等しい場合, ルートプレフィックスは VRP によってマッチすると言います。
これらの定義を考えると, 任意の BGP ルートは次のいずれかの検証状態を持つことがわかります:
-
NotFound (見つからない): ルートプレフィックスをカバーする VRP がありません。
-
Valid (有効): 少なくとも1つの VRP がルートプレフィックスとマッチします。
-
Invalid (無効): 少なくとも1つの VRP がルートプレフィックスをカバーしますが, どの VRP もマッチしません。
VRP は VRP ASN として値 "NONE" を持つことができないことに注意してください。したがって, 起点 ASN が "NONE" であるルートは, どの VRP ともマッチしません。同様に, 有効なルートは起点 ASN としてゼロを持つことはできません [AS0]。したがって, ASN がゼロの VRP とマッチするルートはありません。
BGP スピーカーが隣接ノードから UPDATE を受信すると, UPDATE メッセージ内の各ルートに対して上記のようなルックアップを実行すべきです (SHOULD)。ルックアップは, 別のプロトコルやローカルに定義された静的ルートなど, 別のソースから BGP に再配布されたルートにも適用されるべきです (SHOULD)。実装は, ルックアップが適用されるルートを制御する設定オプションを提供してもかまいません (MAY)。ルートの検証状態は, ルックアップの結果を反映するように設定されなければなりません (MUST)。実装は, この文書で説明されている検証状態を, ルートのローカルプロパティまたは属性として扱うべきです (should)。ルートで検証が実行されない場合, 実装はそのようなルートの検証状態を "NotFound" に初期化すべきです (SHOULD)。
検証状態の使用については, セクション 3 と 5 で説明します。実装は, 明示的に設定されていない限り, 検証状態の副作用としてルートを Adj-RIB-In または決定プロセスの考慮から除外してはなりません (MUST NOT)。
ルートは複数の VRP によってマッチまたはカバーされる可能性があることに注意してください。この手順では, VRP を訪問する順序を義務付けていません。ただし, 検証状態の出力は完全に決定されます。