要約

  • RFC 9673 は RFC 8200 を更新し、aggregate forwarding rate を守りながら router が option ごとに処理を選べる手順を定めた。
  • router は最初の option だけを処理し、残りを skip することがあるため、packet 到達だけでは期待した option の実行を証明できない。
  • 証拠は platform、build、enabled-option table、packet 内の順序と長さ、経路と時刻、node ごとの観測、forwarding 影響、application 結果を分けて結ぶ必要がある。

検証 packet には二つの Hop-by-Hop option が入っていた。先頭は診断用、二番目は service が必要とする処理だった。宛先には届いた。ある中継 router の counter は一つ増えた。しかし、その router が扱えたのは先頭だけだった。packet の成功と service の期待は、option の並び順で分かれていた。

RFC 9673 は RFC 8200 を更新し、Hop-by-Hop Options を現代の router で実用にするための minimum procedure を示す。目的は uniform behavior の復活ではない。処理を local configuration と forwarding capacity の内側に置き、未処理でも packet が進める設計を作ることだ。

すべての hop に同じ約束を求めない

初期 IPv6 は、全 node が Hop-by-Hop header を調べることを要求した。高速 router では特殊処理が slow path や control plane に入り、通常転送や routing protocol の資源と競合し得る。RFC 7045 は extension header の現実を整理し、RFC 7872 は複数の extension-header traffic に大きな path loss があった時期の測定を残した。RFC 9098 と RFC 9288 は運用上の影響と filtering を扱う。これらは risk の根拠であって、今日の特定 path の測定値ではない。

RFC 9673 は、Hop-by-Hop header を処理しない router も、通常は後続 header に基づき packet を転送し、header があるという理由だけで drop してはならないとする。非準拠の downstream device を保護するための configured exception は残る。

したがって、到達には複数の説明がある。全 node が処理したかもしれない。一部だけかもしれない。誰も処理せず安全に skip したかもしれない。destination ACK は path transport の receipt であり、distributed execution log ではない。

full forwarding rate は装置ごとの境界である

RFC 9673 の Full Forwarding Rate は、aggregate forwarding rate を悪化させない処理を意味する。すべての router に共通する option 数や byte 数は定めない。parser の幅、hardware pipeline、software、option の意味、位置、packet rate、traffic mix が違うからだ。

最初の option を処理すると aggregate rate が下がるなら、そのように設定すべきではない。追加 option も同じ条件を満たす場合に処理する。実装例として、full rate で扱える Option Type の lookup table を operator が設定する方法が示される。

table は能力と policy の証拠になり得る。ただし model、hardware revision、build、interface、policy generation を伴わなければならない。中央 controller の “enabled” は、各 chassis が同じ pipeline を持つことも、対象 flow がその chassis を通ったことも証明しない。

「処理予算」という言葉を一つの quota にしてはいけない。必要なのは、何が、どの条件で、fast path、slow path、control plane のどこへ行き、どの rate limiter に守られたかである。

順序が option の優先権を決める

source は option を一つに制限できる。複数を入れるなら total size を抑え、重要度の高い順に置くことが動機付けられる。router が一つ、または限られた数しか処理しない可能性があるためだ。

これは packet format の細部ではない。診断を一番にするか、service-critical action を一番にするかは control decision である。IANA IPv6 parameter registry に両方の type が登録されていても、実装、enable、実行の順番までは保証しない。

RFC 9673 は router が処理できない option に対する drop や ICMP の振る舞いも、指定された場合に configuration-dependent にする。未知 type の action bits 自体は別の論点である。ここで重要なのは、既知 option でも local work が割り当てられず、packet は進み得ることだ。

ICMP が来ないことは肯定応答ではない

RFC 4443 は ICMPv6 を定める。Parameter Problem が source に届けば、少なくとも一 node が option を認識できなかったことを示せる。しかし message がないことは全 node の処理を示さない。生成されなかった、rate-limit された、return path で失われた、あるいは option が skip された可能性がある。

Router Alert は資源境界が必要な理由を鮮明にする。RFC 6398 は slow path の exposure を論じる。RFC 9673 は control-plane exception を残す一方、ACL、trusted source、rate limiting などの protection を要求する。packet 内の request は、router の可用性より上位の権限ではない。

強い receipt は node に結び付く。正確な type、interface、build、policy generation、timestamp と counter または trace が必要だ。その上で、action が service value を生んだかを別に見る。parse、execute、benefit は三つの状態である。

racing の結果には有効期限がある

RFC 9673 は option あり／なしの test、acknowledgement を待つ段階的利用、失敗時の fallback を示す。RFC 8799 の limited domain なら node を共同管理できるが、open Internet では path が変わる。

ECMP、reconvergence、maintenance、software update は、昨日の test が対象にした node を入れ替える。保存すべきものは exact bytes、type、order、total length、flow identity、route evidence、time、ack 条件、ICMP、per-hop telemetry、aggregate metric である。

RFC 9673 の設計思想は、部分導入を失敗扱いしないことにある。新 option は simple、short、full-rate 向け、skip 可能で、全 router が処理しなくても benefit を得られるべきだ。network が安全に断れるなら、service 側は断られた事実を安全に扱わなければならない。

出典