要約

  • IETFはRFC 7506をHistoricに移し、RFC 9570はLSP PingのRouter Alertを「設定しなければならない」から「設定してはならない」へ変更した。IANAは値69と応答モード3を消去せず、非推奨として残している。
  • 文書の退役、レジストリ状態、送信設定、受信動作、パケット上の観測は同じ事実ではない。運用完了にはそれらを結ぶ撤去証跡が必要だ。

変更審査で三つの証拠が提示される。RFC EditorのHistoric表示、IANAのDEPRECATED表示、そしてRFC 9570のMUST NOT。担当者は「旧機能撤去済み」と判定する。

ところが、現用テンプレートも装置のビルドも見ていない。受信側が値69をどう扱うかも、どの区間で何時間観測したかも記録されていない。正しい標準情報から、まだ測っていないネットワーク状態を導いたことが問題なのである。

Historicが変更するのは文書の地位

RFC 7506は2015年4月にStandards Trackで発行され、MPLS OAM向けIPv6 Router Alert Option値69を割り当てた。LSP Pingで利用できる値としてRFC 4379を更新した文書でもある。

Datatrackerのstatus-change文書は、RFC 9570がIPv4/IPv6双方のMPLS OAMからRouter Alertを退役させ、RFC 8029を更新し、RFC 7506をHistoricとする理由を説明したと記録する。状態はApproved - announcement sentである。

IESGのHistoric指定に関する声明によれば、単なるObsoletesは同じ技術の新しい文書への置き換えであり得る。Historicは、記述された技術が現行でも推奨でもないという判断だ。IETF全体のLast CallとIESGの正式な行為を経て、その理由がstatus-change文書に残る。

つまり権威と来歴は確定する。しかし、特定装置への設定投入結果までは含まれない。

新しい送受信ルールは具体的だ

従来のRFC 8029は、MPLS Echo RequestにIPv4なら値0、IPv6なら値69のRouter Alertを必須としていた。RFC 9570は該当文をMUST NOT be setへ置き換え、Router Alert付きUDP応答を求めるモード3も削除した。到着したRequest/ReplyのRouter Alertは無視すべきだとも定める。

LSP Pingには、出口LSRを越えるのを防ぐための別の仕組みが同時に存在した。特殊な宛先とTTL/Hop Limit 1である。RFC 9570はIPv6宛先として::1/128を推奨し、ECMPの経路を試す場合には別のエントロピー源を使うよう求める。

MPLS WGには、越境防止をRouter Alertに依存する実装も、応答モード3の実装も報告されていなかった。これは標準変更の根拠である一方、全世界の実装がゼロだという証明ではない。非公開ツールや古い検証用イメージが報告対象に入ったとは限らない。

非推奨の番号を残すことに意味がある

IANAのIPv6 Router Alertレジストリでは、69がMPLS OAM (DEPRECATED)として残り、RFC 7506とRFC 9570が併記されている。LSP Pingパラメータでも応答モード3は非推奨のまま識別可能だ。

これは新規利用の余地ではない。RFC 9570はRFC 8126に沿って、新実装は非推奨値を使うべきでなく、既存導入は引き続き円滑に動作するという互換性の意味を説明する。RFC 9805によるレジストリ閉鎖も、69の再割り当てや履歴削除を意味しない。

値が残るからこそ、デコーダーは観測したパケットを説明できる。監査では割当文書と退役文書を連結できる。履歴を消せば、古い値はなくなるのではなく、説明できなくなる。

「対応」の一語では四つの状態を隠す

送信側は古い設定から69を生成するかもしれない。受信側は到着を受理して無視するかもしれない。例外パスで処理する可能性もある。さらに、古い機能が依然として値へ依存しているかもしれない。この四状態は、同じ「RFC 7506対応」欄に入れてはいけない。

RFC 6398はRouter Alertの処理負荷と安全上の懸念を扱い、管理されていない環境での利用を勧めていない。したがって露出は測定対象になる。ただし、値を認識するだけで製品や運用者の脆弱性を断定する材料にはならない。

不在の証明にも境界が要る。24時間のキャプチャに69がなければ、その時間と観測点では見えなかったと言える。障害時だけ起動するテンプレートまで永久に消えたとは言えない。

運用撤去レシートを作る

必要なのは運用撤去レシートである。status-change文書、RFC 9570、二つのIANAレジストリを観測日付きで固定し、実行側の状態を別欄に置く。

各送信元について実装名、ビルド、現用テンプレート、Router Alert生成可否を記録する。受信側については無視・処理・拒否のどれかを記す。置換した宛先、TTL/Hop Limit、越境防止策、ECMPエントロピー源を示し、設定結果と試験結果を結ぶ。キャプチャには期間と場所を付ける。

互換性例外には所有者、範囲、期限、終了条件が要る。旧送信者と動作できることはRFC 9570の設計意図だが、無期限の放置を正当化しない。受信側が69を無視できることも、送信側が移行済みだという証拠ではない。

最終判定は、文書上の退役、設定上の退役、観測上の退役、旧互換の終了に分ける。The Policy Mirrorは公的ルールと実装ルールの比較を求め、Running-Code Primacyは実行の証拠を求める。Reality, Not Advocacyに従えば結論は限定される。RFC 7506はHistoricである。特定の回線から69が消えたかは、別途測らなければならない。

出典