要約

  • RFC 3359は当時使用中、または提案中のIS-IS TLV番号を一覧にした。衝突を避けるための情報共有であり、自らが標準や割り当て機関だとは主張しなかった。
  • RFC 3563はこの一覧を初期状態として、IANAが暫定管理する登録簿と指定専門家による審査を設けた。登録された番号だけでは、実装や導入の事実は確認できない。

同じ八ビット値を、別々の拡張が異なる意味に使えば、パケットのバイト列は曖昧になる。双方の設計者が自分の文書だけを見て「空いている」と判断していても、受信ルーターは一つの番号から一つの解釈しか選べない。衝突は不正なパケットから始まるのではなく、互いの計画が見えていない状態から始まる。

2002年8月にInformationalとして公表されたRFC 3359は、その盲点を埋めるための作業用の地図だった。T. Przygiendaの文書は、IS-ISで使われている、または拡張で予定されていたトップレベルTLV値をまとめ、IIH、LSP、SNPのどのPDUに現れるかを示した。これは意味の定義を代替しない。後から番号を選ぶ人が、すでに誰かの仕事に使われた値を見つけるための手がかりである。

表の中身は、複数の制度的な歴史が一つのプロトコル空間で交差した結果だった。ISO 10589由来の値にRFC 1195のIP拡張が並び、IETFドラフト、DECnetの古い項目、LucentとNortelの独自値も記載された。掲載されているからといって、それらが同じ標準上の地位を持つわけではない。表が示したのは、異なる由来を持つ実装や作業が、同一の数値空間を使っていたという事実だ。

RFC 3359は、一覧の権限を明確に否定した。将来の番号衝突を避けることが目的だが、規格でもTLV番号の割り当て権限でもない。割り当てはISO、SIF、IETFの作業グループ間で共有される情報として扱われていた。ISOには番号管理機関がなく、当時のIANAの責務はIP関連の符号点に限られると説明された。文書は「妥当な中央権威が存在しない」と記した。

それでも一覧は役に立つ。値がすでに使われている、あるいは草案で検討されていると分かれば、別の番号を選べる。強制執行ではなく、可視性と相互運用への利害が行動を支える。異なるチームが同じ事実を見られれば、私的な割り当てが線上で衝突する可能性を下げられる。ただし、実際に何件の衝突を防いだかを測ったデータは、この資料にはない。

限界も具体的だった。RFC 3359は各値を定義した文書を一件ずつ特定せず、sub-TLVの番号体系も解決しなかった。将来は版を更新するか、正式な登録簿で置き換える可能性を示した。一行の記載は再利用を避ける警告にはなるが、完全な来歴、互換性条件、実装状況を示すものではない。

同じ2002年、RFC 3232は一般的なAssigned Numbersの一覧を定期的にRFCとして再刊する方法から、オンラインデータベースへ移ることを記録していた。変化する番号空間には、生きた台帳の方が適している。しかしIS-ISでは、さらに制度間の境界があった。中核プロトコルはISOが維持し、インターネット向け拡張はIETFの作業範囲に属する。異なる経路の実装もすでに存在する。表示を更新するだけでなく、誰が割り当てを承認し、誰が記録し、各組織がどう知らせ合うかを決める必要があった。

2003年のRFC 3563は、ISOC/IETFとISO/IEC JTC1/SC6の協力合意を記録した。中核メカニズムとインターネット固有の拡張を分け、JTC1が登録サービスを提供できるようになるまで、IANAがIS-IS TLV登録簿を暫定的に維持することを求めた。「暫定」は重要だ。JTC1から通知があれば割り当て管理を移管し、その後もIANAは情報提供用の写しを保つ可能性がある。登録簿を置く場所、番号を割り当てる権限、標準を維持する責任は同一ではなかった。

新しい登録簿の初期状態はRFC 3359と同期するよう求められた。非公式な一覧を捨てるのではなく、正式な手続きの出発点にしたのである。以後の割り当てにはIESGが指名する専門家の承認が必要とされ、IETFはJTC1/SC6に値を知らせる。JTC1/SC6側の割り当て要請もIANAの手続きに送られる。この仕組みは、すべての組織が同じ草案を自然に読むと期待せず、通知と照会を明示した。

登録簿は値を増やすだけでなく、PDUごとの適用状況を記録する列も変えていく。RFC 6233はPurge列を追加し、purgeされたLSPにどのTLVを含められるかを整理した。同じ値でも入るPDUによって妥当性が変わる。ただし列の表示は要約であり、完全な意味はそのTLVを定義した仕様に残る。

2014年の標準軌RFC 7370は、関連するsub-TLV登録簿を統合し、RFCになる前の割り当てを審査する指定専門家の指針を整えた。通常、申請はワーキンググループが採択した文書に基づく。適切なグループがない場合は区域ディレクターが後援する経路もある。専門家は合意や承認を確認し、技術的価値を審査するが、IETFの合意を覆す立場ではない。草案が進まなければ、早期割り当ての期限と回収規則を適用できる。

RFC 7120は早期割り当ての一般的な規律を示し、RFC 7370はExpert ReviewのIS-IS登録簿での運用を説明する。RFC 8126の政策名は、申請を認める条件の違いを整理する語彙だ。どの政策を通過しても、実装の品質やネットワークでの利用が証明されるわけではない。2024年のRFC 9650は、あるIS-ISリンク属性ビット登録簿をStandards ActionからExpert Reviewへ変更した。過度に厳しい要件が実験を妨げ、未登録の値が勝手に使われる危険を高める、という問題に対応するためだった。審査が軽すぎれば衝突し、重すぎれば共通の一覧から実験がこぼれる。

現在のIANAページは、この制度が更新されてきた結果を載せる生きた記録である。トップレベルと複数階層の登録簿、PDUの適用列、参考文書、登録政策が含まれる。ここで確認するページは2026年のスナップショットとして扱う。後年の列が2002年のRFC 3359にもあったかのようには書かない。

登録簿の一行から言えるのは、ある値、名称、参照先、適用方針が記録されていることまでだ。ルーターの解析器が対応すること、設定が有効であること、別ベンダーと相互運用できること、経路が導入されること、パケットが届くことは、別の証拠が必要になる。RFC 3359の歴史が示すのは、権威の完成ではなく、異なる制度が共有可能な記録を段階的に作った過程である。

参照資料