Summary

  • RFC 9947は実験用のAlternate-Marking SRH TLVを単一の制御されたSRドメイン内に限定する一方、実網で得た結果をIndependent Submissions EditorまたはIETF SPRINGワーキンググループへInternet-Draftとして共有することを想定する。パケットの封じ込めと証拠の公開は別の権限判断である。
  • 公開結果には、公開承認者、仕様・実装・実験コードポイント、実装したフィールド、比較条件、機器群、標本と不確実性、否定的結果、集約・秘匿処理、成果物ハッシュ、訂正履歴を結ぶ「証拠持ち出し記録」が必要だ。生パケット、顧客識別子、攻撃に使えるトポロジーは出す必要がない。

実験の出口はRFCの外にある

2026年3月に公開されたRFC 9947は、Independent StreamのExperimental RFCである。IETFの合意文書でもInternet Standard候補でもなく、恒久的なIANA割り当てを作るものでもない。RFC 9343がIPv6のHop-by-HopまたはDestination OptionsにAlternate-Marking用フィールドを置くのに対し、RFC 9947はSRv6のSegment Routing Header内にTLVを置く代案を実験する。

目的は新方式の宣伝ではない。二つの方式を比べ、SRH TLVがネットワーク内でどれほど残るか、Destination Optionより処理を改善するか悪化させるか、機器アーキテクチャによって転送性能への影響が変わるか、通常のSRv6プログラミングやSID機能制御と共存できるか、拡張フィールドが他のオンパステレメトリーに比べて運用上どう見えるかを調べる。

その答えをRFC本文に書き込むことはできない。実験は公開後に行われるからだ。文書は、結果をIndependent Submissions EditorまたはSPRINGへInternet-Draftとして持ち込み、SRv6におけるAlternate Markingの今後を議論する材料にするよう求めている。初期結果は公開から二年以内に出ることが期待される。これはまだ経過していない期待であり、遅延を断定する根拠ではない。

注目すべきなのは、実験が単一サービスプロバイダーのネットワークに収まると想定される理由の一つとして、パケット経路で集めた性能監視データを共有する制約が挙げられていることだ。結果は外へ届けたい。しかし、その素材は簡単には外へ出せない。ここに統治上の接合部がある。

境界ルーターが判断できるのは形式まで

RFC 9947はデプロイの境界を明確にした。実験はSRドメインに相当する制御ドメイン内だけで行わなければならない。単一の運用者が利用と設定を決め、ノードをローカルに管理し、AltMark TLVを含むパケットの流入と流出を防ぐ。

TLV Typeには124から126の実験範囲を用いる。参加実装は値を調整し、同じネットワークで複数の実験が衝突しないよう、運用者が値を設定できることが望まれる。これはローカルな意味の衝突を避けるためであって、恒久番号や広域デプロイの承認ではない。RFC 9947にIANA actionはない。

境界ルーターは、該当値を持つパケットを落とせる。しかし、後から作られた統計の公開可否までは決められない。時刻別遅延が顧客の利用パターンを示すか、機種別の低下が非公開の弱点を示すか、小さな集計が特定経路を再識別できるかは、パケットフィルターの規則では扱えない。

反対に、秘匿を理由に結論しか出さなければ、外部の読者はプロトコル差と装置差を分けられない。「パケットは外へ出ていない」は必要な運用証明だが、「この公開結論は安全で、かつ十分に裏づけられている」という証明ではない。

何を実装したかで測定対象が変わる

基本TLVには20ビットのFlowMonID、損失フラグ、遅延フラグがある。Enhanced Alternate Markingでは、拡張FlowMonID、セグメント単位かエンドツーエンドかを示すモード、フラグメント状態、方向、タイムスタンプ、逆方向監視の制御情報、シーケンス番号を加えられる。逆方向制御には送信元・宛先プレフィックス長、プロトコル、ポート、DSCP、トンネル範囲、周期も関係する。

したがって、「RFC 9947を実装した」という表現だけでは足りない。どの拡張フィールドを有効にしたか、どのSID動作がTLV処理を選んだか、非対応の中継点を何台含んだかによって、収集できる値も処理負荷も変わる。非対応ノードがTLVを無視すること自体は、SRH処理規則と矛盾しない。

比較相手のRFC 9343側も同じ粒度で記述しなければならない。トラフィック、パケット長、負荷、監視点、測定周期が違うままでは、SRH TLVとDestination Optionの差を測ったことにならない。数字が精密でも、比較設計が揃っていなければ判断は曖昧である。

実験コードポイントも来歴の一部になる。実装Aが124、実装Bが126を期待していたなら、受信失敗は方式の欠陥ではなく設定不一致かもしれない。別実験との衝突があれば観測が混ざる。値を記録する目的は方式を承認するためではなく、同じ実験を語っているかを確認するためだ。

匿名化という一語では境界を越えられない

RFC 9343は、ユーザーデータを直接載せなくてもプライバシー上の問題が残ると説明する。FlowMonIDはフロー追跡に使われ得る。複数の観測点を組み合わせれば、性能や経路を推測できる。監視点から管理システムへ統計を返すチャネルは保護しなければならない。

RFC 9341は測定そのものへの攻撃も挙げる。マーキングや時刻同期が操作されれば、遅延や損失の結果が歪む。マークを低速の隠れチャネルとして使う理論的可能性もある。つまり、公開すべきなのは値だけでなく、値の完全性をどこまで確認したかという条件でもある。

RFC 8799が示すlimited domainの境界は、運用者が公開したくない運用パラメーターを守る。同時に、利用者個人のプライバシーは別の保護対象である。装置名を削っただけでは、正確な時刻、経路形状、狭いトラフィック区分、少数の観測値の組み合わせから再識別できる場合がある。

一方で、すべてを「機密」として平均値だけ残すと、選択バイアスが見えない。成功した期間だけを選んだのか、障害で中止した試行を除いたのか、あるベンダーの高速経路だけを採用したのかを判断できない。安全性と証拠能力は、一方を最大化すればよい関係ではない。

持ち出し記録はデータセットの代用品ではない

最小の公開記録は、まず権限を示す。運用者または研究スポンサー、公開を承認した役割、提出先と日時、判断に関係する資金・機器供給関係を明記する。ISEが受領した、あるいはSPRINGが議論したという事実は、支持やIETF合意を意味しない。

次に実験の同一性を固定する。RFCまたはInternet-Draftの版、実装ビルド、利用した実験TLV値、基本・拡張フィールドの範囲、SID動作、RFC 9343側の比較設定を結ぶ。公開できない成果物はハッシュで版を固定し、後の訂正が同じ素材を対象にしていると示せる。

三つ目は母集団である。装置アーキテクチャとソフトウェア群を、脆弱な在庫表にならない抽象度で示す。経路の形は説明しても所在地は伏せられる。観測期間、対象トラフィック、除外条件、標本処理、時計とカウンターの前提、損失・遅延・ジッター・生存性・処理コストの定義を揃える。不明値や欠測は平均の横に置く。

最後に変換と結果を記す。肯定、否定、判定不能、中止・ロールバックに至った結果を残す。フロー、経路、時刻、ベンダー属性のうち何を集約、削除、抑制したか、そのため外部再現性がどこまで失われたか、限定的な査読に供する保護資料があるか、訂正版が旧版をどう置き換えるかを示す。

これはDaniel Kadeによる編集上の提案であり、RFC 9947が定めた必須様式ではない。生データの公開を迫るものでもない。保護観測から公開主張へ移る際に、判断に必要な関係だけを落とさないための受領記録である。

Independent Streamという表示を消さない

RFC 7942のImplementation Statusは、running codeを議論に持ち込む際の参考になる。責任組織、実装名、成熟度、仕様のどこまでを実装したかを示し、実装の掲載がIETFの推奨ではないことを明記する。実装情報が時間依存である点も重要だ。

ただし、RFC 7942はIndependent Streamを対象外としている。RFC 9947にその手続きを強制することはできない。借りられるのは、実装証拠には範囲と時点があるという設計思想だけである。

RFC 7841のstream表示も維持されなければならない。優れた結果が出れば、新しいIETF作業の動機にはなり得る。だがIndependent Streamで公開された元文書が、結果によって過去にさかのぼってIETF合意へ変わるわけではない。証拠の強さと制度的な承認状態を別々に表示することが、公開議論への誠実な入口になる。

この時点で言えること

参照資料は、RFC 9947の地位、フィールド、制御ドメイン、比較課題、結果共有の想定を確認できる。関連RFCは、Alternate Marking、プライバシー、SRv6、limited domain、RFC streamの境界を説明する。しかし、特定運用者の実験結果、導入一覧、公開データセットはこの資料群にはない。

したがって、本稿はSRH TLV方式の優劣を判定しない。実験結果が遅れているとも言わない。生パケット、顧客情報、正確なトポロジー、ベンダー機密を公開すべきだとも言わない。

求めるのは、結果が現れた時に、その主張の届く範囲が読めることだ。パケットと保護された観測は域内に留められる。それでも、版、比較条件、欠測、秘匿変換、承認者、訂正履歴を持った証拠は外へ出せる。制御ドメインは、その二つを混同しない時に初めて公開標準作業へ貢献できる。

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC EditorのRFC 9947記録
  5. RFC 9947 — Alternate-Marking MethodのSRHへの適用
  6. RFC 9341 — Alternate-Marking Method
  7. RFC 9342 — Clustered Alternate-Marking Method
  8. RFC 9343 — Alternate-Marking MethodのIPv6適用
  9. RFC 8799 — Limited Domains and Internet Protocols
  10. RFC 8402 — Segment Routing Architecture
  11. RFC 8754 — IPv6 Segment Routing Header
  12. RFC 8986 — SRv6 Network Programming
  13. RFC 7841 — RFC Streams, Headers, and Boilerplates
  14. RFC 7942 — Improving Awareness of Running Code