要約

  • draft-ietf-bfd-rfc5883-bis 第 02 版は、マルチホップ BFD Echo の一律禁止を条件付き規則へ変更した。中間ノードが返送し得る環境では禁止し、それを確実に防げる場合にだけ利用を認める。
  • 文書はまだ作業部会の Internet-Draft であり、RFC 5883 の承認済み後継ではない。追加された HPE 実装表も未検証の寄稿情報で、新条件の導入や相互運用を証明しない。

Echo 応答が返ってきても、遠端まで到達したとは限らない。途中のルーターがパケットを送り返せば、送信元には正常に見える一方、確認したかった経路の残りは通っていない。

RFC 5883 が 2010 年にマルチホップでの BFD Echo 機能を全面禁止したのは、このためだ。後継候補の第 01 版も同じ規則を維持した。8 月 19 日公開の第 02 版は、禁止する条件をより細かく定義する。

新しい記述では、カプセル化や転送によって中間ノードが Echo パケットを送信元へ返す可能性がある場合、利用してはならない。反対に、中間ノードが返さないことを環境側で保証できる場合に限り、利用してよい。ソースルーティングとしてカプセル化する方法が例示されているが、あらゆるネットワークに通用する安全策として認定されたわけではない。

つまり、IETF がマルチホップ Echo を一般解禁したのではない。判断軸をホップ数だけから、完全な経路通過を証明できるかどうかへ移した。早期返送を排除する仕組みが崩れれば、応答は再び不完全な到達性を正常と見せる。

第 01 版と第 02 版の公式 XML を構造的に比較すると、この Echo 段落が本文唯一の規範的変更である。第 02 版には、既存の ZTE 記載に加えて HPE の実装状況も追加された。ただし、これらは作業部会が実装可能性を検討する材料であり、第三者試験ではない。

HPE は独自の Junos OS BFD Implementation を Mature とし、任意経路、カプセル化、認証を実装済みと報告している。一方、帯域外の Discriminator 通知と単方向リンクは MPLS LSP に限る部分実装で、実装経験は提示していない。

ドラフトの前書きは、この情報を IETF が検証しておらず、掲載は推奨を意味せず、一覧は製品カタログでもないと明記する。したがって Mature は寄稿者の自己評価であり、IETF 認証や普及率、異機種間相互運用の証拠にはならない。

旧版にはすでに ZTE の寄稿があり、Echo パケットを Segment Routing Header に収める unaffiliated BFD Echo 実装なら複数ホップで使えると説明していた。その時点では規範本文が一律禁止のままで、寄稿と規則の間に緊張があった。第 02 版は環境条件を導入したが、資料は ZTE の報告が変更原因だったとは述べていない。

汎用 BFD アプリケーションの関連ドラフトも同日、第 02 版へ進んだ。実質的な追加は別の HPE/Junos 実装表で、多くの項目を実装済みとする一方、OSPF Virtual Links は未実装で、実装経験も提示していない。汎用クライアントとマルチホップの申告内容を照合する助けにはなるが、独立製品間の動作確認ではない。

Datatracker 上のマルチホップ文書と汎用文書は、どちらも BFD 作業部会の活動中 Internet-Draft で、IESG 状態は I-D Exists である。承認・発行された場合にのみ RFC 5883 と RFC 5882 を置き換える。

運用上の制約も残る。BFD はルーター間や LSP 終端などのネットワーク運用・管理・保守のための仕組みで、インターネット越しの一般アプリケーション監視ではない。過剰な送信レートは輻輳と誤検知を招く。マルチホップは攻撃面を広げるため、強い暗号認証も重要になる。

今回の資料には、新しい条件が製品で有効化された証拠、異なる実装間の試験、実運用での可用性や収束の測定値がない。普遍的に安全なカプセル化も定義していない。次に必要なのは、応答が返ったという一点ではなく、経路変更や障害時にもパケットが必ず遠端を通過したと示す観測結果である。

情報源