要約

  • RFC 9747 の宛先 IP、状態、識別子は送信側に属する。隣接機器は通常の IP 転送で折り返すだけで、BFD の状態を生成しない。
  • 戻りパケットの厳密なホップ条件とローカル設定は、小さな転送ループの証拠であり、対向 IP やアプリケーションの稼働証明ではない。
  • 検出が速くても、サービスを動かす権限や安全な切り戻し条件は別途必要になる。

「復旧」を誰が語っているのか

運用画面の Up を対向機器からの返答と受け取ると、この方式を読み違える。RFC 9747 では A が B に向けて送るパケットの宛先は、A 自身の IP アドレスだ。B はそれを通常の IP 転送で A に返す。A が得るのは、特定インターフェースを通る隣接機器との接続性についての観測である。B 上の特定 IP アドレスの可用性を確認するものではない。

この制限は RFC 9747 第1節 に明記されている。2025年3月に公表された IETF の標準化過程の文書で、RFC 5880 を更新し、IPv4 または IPv6 の単一 IP ホップを対象とする。公表は仕様の存在を示すが、普及率や実際の復旧時間の改善は示さない。

意義は、BFD を完全実装できない、あるいは制御セッションを設けたくない対向機器にも、局所的な検出を使えることだ。対向側に求めるのは折り返しに必要な IP 転送であり、プロトコルの会話ではない。その負担削減と引き換えに、観測の意味は狭くなる。

自分の状態を読み直す仕組み

パケットは BFD Control の形式を使うが、UDP 宛先ポートは Echo 用の 3785 である。B は BFD フィールドを解釈せず、状態を管理せず、新しい BFD 応答も生成しない。A は戻ってきたパケットに対し、所定の非同期処理、検証、認証を適用する。A から見ればセッションとして扱えるが、リンクの両端で BFD 状態を協調させてはいない。

状態機械が受け取るのは、A が生成し B を経由して戻った状態だ。Down、Init、Up の進行を、B が保守作業の意図を伝えたものとして扱うことはできない。AdminDown はこの方式では使わない。My Discriminator はローカル設定、Your Discriminator は最初がゼロで、その後は折り返された My Discriminator の値になる。初期の振り分けは送信元 IP または UDP 送信元ポートで行い、以後は Your Discriminator のみを使う。これはセッションを選ぶ規則であって、隣接機器の身元を証明する規則ではない。第2節 が手順を定める。

単一ホップの受け入れ条件も厳しい。送信時の TTL または Hop Limit は必ず 255、受信時は正確に 254 でなければ破棄する。認証を使ってもこの条件は免除されない。一方、254 という値だけでは B の独立した身元は分からない。通常の減算と転送条件に依存するからだ。トンネルなどの特殊動作があれば、その条件を別に確かめる必要がある。複数ホップの到達性も確認できない。最初のホップが返してしまい、その先の意図した経路を通らないためである。

準備の責任は消えない

B がホストなら、IP 転送が初期状態で有効とは限らない。RFC は B 上で折り返しを設定する方法を範囲外にしている。A 側でも、自分宛てのパケットをローカル配送で終わらせず、指定した B に実際に出す必要がある。多元接続リンクではデータリンク宛先も適切でなければならない。機器名を付けた設定だけでなく、対象インターフェースの実際の送信を確認する意味がここにある。

RFC 5881 の Echo 封装規則 は Redirect の回避も求める。送信インターフェースのサブネット内アドレスや IPv6 のリンクローカル送信元は、Redirect が起きないと分かっている場合を除いて適さない。さらに RFC 9747 は厳格なユニキャスト逆方向経路検査が折り返しを阻む可能性を指摘する。RFC 3704 にある検査との整合が必要だが、ネットワーク全体で送信元詐称防止を外す理由にはならない。

B の管理者が転送やフィルタを変えても、この仕組みから行政的な BFD 状態は届かない。届くのは、従来の条件を満たすパケットが戻らなくなったという結果だけかもしれない。「対向側に BFD が不要」と「対向側の準備が不要」は異なる。

パケット内の一秒は合意した検出時間ではない

Desired Min TX Interval と Required Min RX Interval には確定値を入れ、未初期化メモリの露出を防ぐ。推奨値は一秒、1,000,000 マイクロ秒だ。Required Min Echo RX Interval にはゼロを推奨する。しかし受信時は三つとも無視し、前二つは Detection Time の計算に使ってはならない。

Up 時の送信間隔と Detect Mult は A が設定する。開始時と Down 後の再開は毎秒一パケットを超えない低速送信とし、Up 後に設定間隔へ移る。Up の間に規定数の期待する Echo が届かなければ、A は Down となり LocalDiag を 2、Echo Function Failed にする。間隔と欠落数の積は名目的予算の説明には使えるが、実測の収束保証ではない。送受信の揺らぎ、ローカル処理、クライアントの判断、転送表更新、利用者の成功は別々に測る必要がある。

健全なループと失敗した取引

B が A 宛てパケットを返せても、B の管理 IP や先にあるアプリケーションは停止しているかもしれない。その場合 Echo Up は仕様上正しくても、サービス健全性の主張は正しくない。逆に、フィルタ変更や A の受信処理負荷で Down になっても、サービスの取引が成功する場合がある。サービスに対する誤検知と呼ぶなら、対象と観測期間を先に定義すべきだ。必ずしも BFD 状態機械の誤りではない。

RFC 9747 は詐称の可能性から BFD Authentication Section の利用を推奨する。だが認証内容を作るのも A である。戻った内容の検証は採用した認証方式の範囲で試験を保護し、B を独立した認証済み発言者にはしない。身元、管理意図、アプリケーション状態をそこから足すことはできない。小さなループがローカル予算内で条件を満たした、という証拠をそのまま使うことが、この方式の価値を保つ。

出典

仕様、継承規則、現在の状態: RFC Editor, RFC 9747, IETF Datatracker, RFC 5880, RFC 5881, RFC 5882, RFC 5082, RFC 3704, RFC 9747 — errata.

署名された分析の視点: Lu Heng — Note 65, Lu Heng — Note 64, Lu Heng — Note 36.