要約

  • RFC 9899 の比較は、原点を選び、そこから length バイトを飛ばし、演算子とバイナリパターンを適用する。スキーマ上正しい設定だけでは、装置が実際に見たバイト列は分からない。
  • カウンター差分は、既知のスコープと epoch における ACE の局所的な帰属を示す。パケットの同一性、アクション実行、アプリケーション結果を単独では証明しない。

変更試験に四つの緑色の結果が並んだとする。YANG Library に機能があり、コミットが成功し、ACE を読み戻せて、試験中にカウンターも増えた。ここから「ペイロードルールは機能した」と書くのは簡単だ。だが四つの観測が正しくても、その文全体はまだ立証されていない。

RFC 9899 は 2025 年12月に Proposed Standard として公開され、RFC 8519 の ACL モデルを拡張した。Datatracker は前身を draft-ietf-netmod-acl-extensions と記録している。後日の「更新日」はレコードのメタデータであり、新しい仕様ではない。文書状態を証拠化するときは、RFC 情報ページ、Datatracker、その時点の正誤表検索を一緒に保存する必要がある。

比較窓を決める四つの要素

match-on-payload は、実装がパターン照合能力を広告する feature である。YANG 1.1 のスキーマ能力であって、転送面の報告ではない。payload-match では offset が意味上の原点を選び、length がそこから無視するバイト数を指定し、operator は既定で match、pattern はバイナリ値を保持する。比較開始点は offset + length である。

ここで length はパターン長ではない。あくまでスキップ距離であり、比較する値は pattern が決める。「offset 42、length 4」だけを残し、offset identity、operator、pattern を保存しなければ、規則は再現できない。

原点にも固有の意味がある。layer2 はデータリンクヘッダー、layer3 は IP ヘッダー、layer4 は IP オプション、IPv6 拡張ヘッダー、AH を含む IP 層ヘッダーの直後から始まる。payload はトランスポートヘッダーの直後であり、TCP オプションも越える。IANA YANG Parameters はモジュールの改訂と RFC 9899 が設けた型モジュールを確認する資料になるが、データプレーン動作の証拠ではない。

同じ数字でも原点は動く

アプリケーションデータが同じ二つの TCP パケットでも、オプションの有無でヘッダー長は変わる。RFC 9293 の Data Offset は TCP データの開始位置を示す。payload を正しく実装する装置は可変長を考慮するはずだが、試験が固定絶対オフセットで代用すれば、一方だけが偶然一致し得る。

IPv6 では観測位置がさらに重要になる。RFC 8200 の拡張ヘッダーは IPv6 ヘッダーと上位層の間に入り、フラグメントは宛先で再構成される前は別々のパケットである。RFC 9899 は layer4 の原点を定義する一方、各装置が再構成、デカプセル化、正規化の前後どこで照合するかまでは決めない。そこは実装と配置の事実であり、試験対象である。

暗号化はもっと明確な限界を作る。RFC 9000 は QUIC のパケットペイロードを保護し、パケット番号などにもヘッダー保護を施す。見えるヘッダー材料が残っても、アプリケーション平文が見えることにはならない。RFC 9899 は、非暗号化データでは決定的に照合でき、暗号化パケットでは不変パターンの有無が有効性を左右すると述べるだけで、復号機能を与えない。RFC 8329 はセキュリティ機能における内容照合の背景資料だが、特定装置の実装証明ではない。

九つの現実を一つに畳まない

検証記録は次の層を分けるべきである。正しいモジュール改訂、feature、deviation がノードを公開するスキーマ能力。誰がどの datastore に書き、認可されたかという認証・認可とトランザクション。設定が intended と operational のどこに存在するかという状態。RFC 8342 はこの差を形式化している。さらに、ACE が期待するインターフェース、方向、段階、ソフトウェアまたはハードウェア経路に置かれたというプログラム済み状態が必要だ。

その先に、独立キャプチャで固定した正確なバイト、暗号化・カプセル化・分割・再構成・正規化を含む可視性、既知のスコープと epoch におけるACE ヒット、別テレメトリで示すアクション実行、そして独立したサービス結果がある。

RFC 8341 が示す通り、スキーマ適合性とアクセス認可は別問題である。RFC 8519 の matched-packets と matched-octets は現行 ACL entry の読み取り専用カウンターであり、実装によってインターフェース別または集約値になり得る。スコープ、リセット履歴、制御刺激、独立観測がなければ、増分は原因パケットさえ特定しない。RFC 9899 の補完ログや名前付きカウンターアクションも、設定されたことと実行されたことは同義ではない。

パケット窓の受領書

再現可能な最小成果物は「パケット窓の受領書」である。モジュールと改訂、feature、deviation、装置ソフトウェアと転送部品、認証主体と認可結果、transaction ID、datastore、ACE ID と順序、アタッチ先、インターフェース、方向、デカプセル化・正規化・再構成との前後関係を記録する。加えて offset identity、スキップ長、operator、binary pattern、計算したバイト範囲、fixture と独立キャプチャのハッシュ、IP/TCP ヘッダー長、暗号化境界、見えると主張する不変値、カウンター名・幅・スコープ・集約規則・リセット時刻・前後値・刺激区間を結ぶ。アクションとサービス結果は別の証拠として添える。

正の一致だけでは足りない。アプリケーションデータを保ったまま TCP オプションを変える。IPv6 拡張ヘッダーを挿入する。文書化された環境で先頭・非先頭フラグメントを試す。pattern の一バイトだけを変える。暗号化と非暗号化、ingress と egress を比較する。最も単純なパケットだけで成功するなら、それは fixture の成功であって、ポリシー全体の保証ではない。

文書の権威と実装の力

ここでは外部の分析レンズを明示的に使う。Lu Heng の reality layers 論を Daniel Kade が本件へ適用すると、YANG は仕様・記号の層であり、プログラム済みデータプレーン、観測パケット、実行アクション、サービス結果は順に実行可能性の高い層となる。これは RFC の主張でも、著者意図の説明でもない。

Minimum Initial Specification と Localized Future Decisionからは、共同証拠を小さく決定的に保つ設計が導ける。スキーマ identity、比較窓、刺激、counter epoch、独立観測を共通核にし、hook、正規化、再構成というベンダー選択は局所的実装判断として可視化する。権威と信念に関する論考が強調する区別も同じだ。公開文書は調整に影響を与えるが、稼働中の転送路を制御する実装と運用者が実行力を持つ。これらは本稿の分析であり、IETF への帰属ではない。

RFC 9899 は比較を移植可能に記述する力を与えた。だが移植性は全知ではない。正確な主張は、「このスキーマと認可、プログラム済み hook の下で、この原点・スキップ・演算子・pattern により、この可視バイトを比較した。ACE カウンターはこの epoch で変化し、別証拠がアクションとサービス結果を示す」となる。それ以上には、別の受領書が要る。

情報源