RFC 9647：BabelのYANG状態は運用証明ではない

要約

RFC 9647は、Babelルーティングプロトコルを管理するための標準YANG 1.1モデル「ietf-babel」を定義し、NMDA（Network Management Datastore Architecture）に対応した管理面の共通言語を提供する。2024年10月にStandards Track RFCとして公開され、RFC 9046を基盤としてIPv6上のBabel管理を対象にしている。
このモデルは、Babelの有効化、定数、インターフェース、MAC鍵セット、DTLSオブジェクト、経路状態などを検査・設定可能にする。一方で、YANGモデル自体は必須のread-only情報モデル属性が実装上必ず存在することを強制できず、それらの値を実際に埋める責任は実装側に残る。
selectedなどの経路状態は管理モデルから見える実装状態の投影であり、単独ではパケット転送成功や独立観測された到達性を意味しない。運用者は、設定、認証、近隣関係、RIB/FIB投入、転送、復旧までを連続した証拠として確認する必要がある。
実務上の重要な検証単位は、モジュール版・データストア起源・時刻、read-only状態、インターフェース分類、実効デフォルト、MAC/DTLS適用、認証結果、経路履歴、転送投入、外部到達性という「十の受領証」の連鎖になる。

Babelの運用で最も危険な誤解の一つは、経路表の一行がネットワーク全体の真実を代表していると考えることである。管理システムが取得したBabel経路状態に、あるプレフィックスがselectedとして表示されている。これは重要な情報だが、その瞬間に確認できるのは、Babel実装が管理モデル上で選択状態として表現しているという事実である。

そこから先には複数の境界がある。

その経路が実際の転送テーブルへ導入されたのか。インターフェースに設定されたポリシーが意図どおり実効化されているのか。近隣ノードとの交換が認証済みなのか。障害発生後に代替経路へ移行できるのか。利用者視点でパケットが目的地まで到達しているのか。

RFC 9647は、この境界を消すための規格ではない。むしろ、Babel管理における観測可能な領域を整理し、どこまでがモデルで確認でき、どこからが追加検証になるのかを明確化する規格である。

RFC 9647が標準化した管理面

RFC 9647「A YANG Data Model for Babel」は、Babel用のYANG 1.1モジュールである ietf-babel を定義する。仕様はRFC 9046を基礎としており、NMDA対応の管理モデルとして設計されている。対象はIPv6上で動作するBabelの管理である。

参照：

モデルが扱う範囲は広い。管理者はBabel機能の有効化状態、プロトコル定数、インターフェース単位の設定、MAC鍵セット、DTLS関連オブジェクト、そして経路状態をYANGツリーとして扱える。

特に経路状態は、Babelの運用判断に必要な情報を管理面へ持ち上げる。対象にはプレフィックス、ルーターID、近隣ノード、受信・計算メトリック、シーケンス番号、ネクストホップ、feasible状態、selected状態などが含まれる。

しかし、ここで重要なのは「見えること」と「保証されること」が異なる点である。

RFC 9647は、YANGがデータモデルである以上、必須のread-only情報モデル属性の存在そのものを強制できないことを明示している。つまり、モデル上で観測用フィールドが定義されていても、その値を実装が正確かつ継続的に提供する責任は実装者側にある。

この制約は欠点というより、ネットワーク管理標準全体に共通する境界である。設定可能な構造と、現実世界で発生している状態の完全一致は別問題だからだ。

意図、実効状態、運用現実の分離

RFC 9647で特に重要なのは、NMDAの考え方に沿って設定意図と実際の状態を区別する点である。

Babelのenableリーフは、その違いを理解するための典型例になる。

runningやintended datastoreでは、enableは管理者が望む状態、つまり行政的な意図を表す。一方、operational datastoreでは、それが実際に動作状態として反映されているかを見る。

この差は、単純な設定確認では扱えない問題を示している。

「設定ファイルにはBabel有効と書いてある」という証拠と、「対象インターフェースでBabel交換が成立している」という証拠は異なる。さらに、「交換が成立している」と「その経路で利用者トラフィックが成功している」も異なる。

RFC 9647は、この段階差を管理モデルとして表現する道具を提供するが、段階間の因果関係を自動的に証明するものではない。

インターフェース分類とデフォルト値のリスク

Babelでは、リンク特性に応じたデフォルト動作が存在する。

有線インターフェースでは、デフォルトとしてtwo-out-of-three判定とsplit horizonが利用される。無線インターフェースでは、ETX（Expected Transmission Count）に基づく動作となり、split horizonは使用されない。

この差は、単なる設定値の違いではない。ネットワークの物理的・論理的性質をどのように判断するかに関係する。

例えば、無線バックホールが実際には有線ポートの背後に存在する場合、トンネル経由のBabelリンク、課金型バックアップ回線、低品質なフォールバック経路などでは、標準デフォルトが運用意図と一致しない可能性がある。

その場合、運用者は明示的な上書きとタイマー設定を検討する必要がある。

重要なのは、「RFCに従ったデフォルトだから正しい」という判断ではない。RFCが提供するのは一般的なモデルであり、個別ネットワークのリンク経済性、障害モード、遅延特性までは決定しない。

MACとDTLS――認証設定は存在だけでは完成しない

RFC 9647はBabelのセキュリティ関連オブジェクトも管理対象に含める。

MAC鍵セットやDTLSオブジェクトは、Babel交換の認証構成を管理面から扱うための要素である。また、MACやDTLSのデフォルト適用設定は、新規作成されたインターフェースへ参照を追加する仕組みを持つ。

しかし、ここにも検証すべき境界がある。

デフォルト設定が存在することは、すべての対象インターフェースで意図した鍵やDTLS設定が実効化されたことを意味しない。インターフェースごとの有効化状態、参照関係、適用結果を確認する必要がある。

さらに、MAC鍵やDTLS秘密鍵のような機密情報にはNACM（Network Configuration Access Control Model）による保護が関係する。

参照：

アクセス制御は、誰が設定を変更できるかという管理面の問題を扱う。一方、それだけで認証交換が成功したこと、あるいは通信相手が期待した相手であることを証明するわけではない。

RFC 9647自身のセキュリティ節も、対象をYANGモデルのセキュリティに限定している。Babelプロトコル、MAC認証、DTLSの詳細なセキュリティ考慮事項は、それぞれRFC 8966、RFC 8967、RFC 8968に委ねられている。

参照：

selected状態から転送保証までの十の受領証

RFC 9647を実運用で活用する場合、管理者が求めるべきなのは単一画面の状態表示ではなく、証拠チェーンである。

実務では、以下の十段階を一つの受領証列として扱うことができる。

モジュール版と機能確認 使用中のietf-babelモジュールのrevision、feature対応状況を確認する。
データストア、origin、時刻の記録 取得した状態がどのdatastore由来で、いつ観測されたものかを明確にする。
必要なread-only状態の存在確認 実装が提供すべき状態情報を実際に埋めているか確認する。
インターフェース分類の検証 有線、無線、トンネル、特殊リンクなどの分類が実態と一致するかを見る。
実効デフォルトと上書き確認 ETX、split horizon、タイマーなどが意図した値になっているか確認する。
MAC/DTLS識別情報と適用関係確認 鍵セット、証明書関連オブジェクト、インターフェース参照を確認する。
認証・ハンドシェイク結果確認 設定存在ではなく、実際の認証交換結果を見る。
近隣関係と経路履歴確認 neighbour状態、シーケンス番号、経路変化の時系列を確認する。
RIB/FIB投入確認 Babelが選択した経路が実際のルーティング・フォワーディング状態へ反映されたかを見る。
パケット転送、復旧、独立到達性確認 外部観測によって通信成功、障害復旧、サービス到達性を確認する。

この十段階はRFC 9647が直接定義する手順ではない。しかし、YANG管理情報を運用保証へ変換する際に必要となる証拠境界を整理する枠組みになる。

RFC 9647が可視化するBabel運用証拠チェーン――YANGモデルの外側に残る検証責任

なぜ重要か