要約
- RFC 9650は
IS-IS Neighbor Link-Attribute Bit Valuesの登録手続きをStandards ActionからExpert Reviewへ変更し、実験段階でも未登録値を私用せずに割り当てを求められるようにした。 - 指定専門家の判断とIANA登録が証明するのは共有名前空間での割り当てであり、プロトコルの完成度、実装、安全性、導入、経路への効果ではない。
- 文書が進まない場合の失効・返却と、残存するバイナリや設定の撤去は別の仕事であり、要求からサービス観測まで段階別の証跡が必要になる。
失効した行と、消えない実装
実験用に割り当てられたビットを使うソフトウェアが複数の検証環境へ配布されたとする。その後、文書は進展せず、割り当ては期限を迎える。IANAの行を更新しても、装置上のバイナリや設定は更新されない。値が別用途へ再利用されれば、過去の実験が将来の衝突源になる。
RFC 7370が、文書がRFCへ進まない場合にRFC 7120の失効・返却手続きを求めるのはこのためだ。登録はライフサイクルを持つ。しかし運用資産の撤去は登録簿だけでは完了しない。
RFC 9650は、この登録簿への入口を変更した。RFC 5029が求めたStandards Actionは、実験的プロトコルにビットを割り当てるには厳しすぎ、未登録コードポイントの使用、いわゆるスクワッティングを誘発した。そこでExpert Reviewへ移行した。
割り当て対象を正確に見る
RFC 5029のLink-Attributes sub-TLVはsubtype 19で、値は16ビットのフラグである。0x1はLocal Protection Available、0x2はLink Excluded from Local Protectionを表す。sub-TLVは任意で、単一隣接先について一度だけ現れる。不対応ルーターは黙って無視する。
現在のIANA IS-IS TLV Codepoints登録簿はExpert Reviewと指定専門家を示し、RFC 5029、9667、9650を参照する。RFC 9667による0x4のLocal Edge Enabled for Floodingも登録されている。
この公開情報は「この値にはこの文書化された意味が割り当てられている」と言える。特定のLSPが正当な装置から出たこと、相手が意味を理解したこと、ポリシーが採用したことまでは言えない。不対応ルーターが静かに無視するという仕様上の挙動だけでも、広告と効果が同じ事実でないことが分かる。
軽い手続きは、無審査ではない
RFC 8126は、登録簿の目的に合う最も軽い手続きを選ぶよう求める。審査コストが過大なら、利用者は登録を諦め、実際の使用が表から消える。厳格さを増すほど調整が強くなるとは限らない。
Expert Reviewでは、十分な資料を指定専門家が公開指針に沿って審査する。RFC 7370によれば、通常はワーキンググループ文書かArea Directorの支援を予定する文書を対象とし、関係する合意や承認を確認した上で技術的妥当性を検討する。専門家はIETFの合意を上書きしない。承認後、IANAが値と文書参照を記録する。
つまり専門家が持つ権限は、登録基準に対する割り当て判断である。製品認証、セキュリティ監査、変更承認の権限はそこに含まれない。
「空いて見える値」が作る二つの負債
RFC 7120は、RFC成立前の実装経験が必要な場面を扱う。私的に空き値を選ぶと、後に正式な値が別になり、初期実装と最終実装が相互運用できなくなる。あるいは別の拡張へ同じ値が割り当てられ、現場で意味が衝突する。
早い段階の公開割り当ては、推測を共有事実へ変える。文書参照と状態を外部化し、他の実験が同じ位置を選ぶのを防ぐ。だが、その値で作られたコードの品質や配布先までは外部化しない。
証跡を段階ごとに閉じる
要求証跡には文書版、用途、申請者、日付を保存する。審査証跡には専門家、範囲、判断基準、質問と結論を残す。登録証跡には値、参照、観測時刻、失効状態を記録する。
実装側ではcommit、build provenance、送受信テスト、未知フラグと重複sub-TLVの扱いを残す。変更側では承認者、対象機器、設定、ロールバックを残す。運用側ではLSPの送信、受信、parse、semantic support、local policy、route calculation、forwarding、service observationを別の結果として結ぶ。
実行コードの優位に従えば、登録簿は意味を調べる一次資料であり、実際の挙動を調べる資料はロード済みコードと観測である。
セキュリティの責任は移動しない
RFC 9650はRFC 5029のセキュリティ課題を変更しない。後者はLSP内の追加情報が観測され得ること、改変が問題になり得ること、各仕様が開示と改変の影響を記述すべきことを述べる。
割り当て方法を変えても、LSPの送信元は認証されず、parserの安全性は保証されず、経路ポリシーも許可されない。名前衝突を減らす統制と、実装・運用リスクの統制を分けるからこそ、責任者を特定できる。
Minimum Initial Specificationの考え方では、共有層は一つの希少な記号に一つの意味を与えるところまででよい。採用と実行は、結果を負う現地の判断として見える形で残す。Reality Layersは、申請、審査、登録、実装、広告、経路を同じ「承認」に潰さない。
Sources
- Heng Lu — Minimum Initial Specification
- Heng Lu — Reality Layers and Symbolic Power
- Heng Lu — Running-Code Primacy
- IETF Datatracker — RFC 9650 history
- RFC Editor — RFC 9650 information
- RFC 9650 — HTML
- RFC 9650 — canonical text
- RFC 9650 — XML source
- RFC 9650 — errata search
- IANA — IS-IS TLV Codepoints
- RFC 5029 — IS-IS Link Attribute Sub-TLV
- RFC 7370 — IS-IS TLV Codepoints Expert Guidance
- RFC 8126 — IANA Registration Policy Guidance
- RFC 7120 — Early IANA Allocation
- RFC 9667 — IS-IS Flooding Reduction
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

