要約

  • RFC 3147 は、IPv4 または IPv6 を GRE に入れ、その GRE パケットを CLNP の利用者データとして運ぶことで、既設 CLNS 網の先にある IP 管理装置への逆向き経路を定義した。
  • 推奨された N-SEL 47 は CLNS 終端で GRE を選ぶだけであり、内側のプロトコルは GRE Protocol Type が示す。どちらも管理操作の成功を証明しない。
  • 古い網が新しい装置の到達経路になる以上、廃止には代替経路、パケット長、安全、アプリケーション応答、実機状態を別々に確認する必要があった。

新しい端末が古い経路の先に置かれた

SONET と SDH の管理は、2001 年に突然始まったわけではない。Bellcore GR-253-CORE と ITU-T G.784 が CLNS を要求したことで、運用者はすでに大規模な管理網を持っていた。新しいネットワーク要素が IP 管理へ移っても、管理局から装置までの中間網まで同時には置き換わらない。

移行期には二つの島ができる。古い CLNS 装置が新しい IP 網の奥に残る場合、CLNP PDU を GRE で IP 上に運べる。逆に、新しい IP 装置が古い CLNS 網の奥に置かれれば、必要なのは IP over CLNS である。片方向のトンネルを知っていても、反対方向の到達性は生まれない。

RFC 3147 は IPv4 または IPv6 パケットを GRE で包み、その全体を CLNP Data Type PDU のデータ部に配置した。CLNS が既設網内を転送し、出口のトンネル終端が CLNP と GRE を外して内側の IP パケットを送り出す。

この手順で CLNS ルータが IP ルータに変わるわけではない。管理対象装置がトンネルを理解する必要もない。二つの終端間に限定された通路を作ったのであり、管理網全体を更新したのではなかった。

一つのキャプチャに複数の現実があった

内側の IP ヘッダーは管理通信を表す。GRE ヘッダーは内側のネットワーク層プロトコルを識別する。外側の CLNP は、実際に横断する CLNS ドメインでのアドレスと転送を担う。各層は別の行為の記録である。

CLNP PDU が出口に届けば、キャリア層の配送は確認できる。GRE が正しく解釈できれば、内側の形式が分かる。IPv6 パケットを出力できれば、カプセル解除は成功した。それでも管理アプリケーションが要求を受理したか、正しい装置が実行したか、状態が変化したかは残る。

識別子も統合してはならない。NSAP は CLNS 終端を示し、IP アドレスは IP 層の宛先を示す。装置の運用上の同一性は資産台帳、設置場所、証明書などに依存し得る。一つの address に上書きすれば、移行前後を結ぶ証拠が消える。

したがって管理意図、内側 IP、GRE、CLNP、CLNS 転送、終端での解除、アプリケーション応答、実機状態を連鎖として保存する。前段の成功は後段の成功ではない。

47 は入口を選び、その先までは決めなかった

CLNS は NSAP の最後のオクテット、N-selector（N-SEL）で Network Service の利用者を分けた。CLNP のデータが GRE から始まることを両端で共有する必要があり、RFC 3147 は 10 進数の 47 を提案した。これは IP のプロトコル番号で GRE に割り当てられた値と同じだった。

しかし役割は別である。N-SEL 47 は CLNS 終端で GRE 処理を選択する。GRE Protocol Type が、その内側を IPv4、IPv6、または別のプロトコルとして識別する。47 を見ただけで「IPv4 管理」と記録すれば、IPv6 を誤分類する。

推奨値は相互運用の共通点であって、普及の証拠ではない。RFC に番号があることは意味を確定するが、全ベンダーの実装、オプションの一致、特定運用者の利用を証明しない。

監査可能な記録には送受信 NSAP、N-SEL、GRE の版とフラグ、Protocol Type、内側アドレス、ペイロード指紋、観測時刻が要る。「トンネル稼働中」だけでは何が通ったかを説明できない。

小さい疎通確認が大きな障害を隠す

カプセル化は長さを増やす。CLNS 内部のリンクには、IP 送信元から見えない PDU 上限がある。RFC 3147 は CLNP の Segmentation Permitted を設定するよう推奨した。分割が許されず PDU がリンク上限を超えると、CLNS は破棄でき、内側の送信元は理由を受け取れないことがある。

短い ping や照会だけが成功し、大きな設定転送が消える。このとき装置は「到達可能」と判定済みなので、障害はアプリケーションへ押し付けられやすい。実際の経路は特定の長さでしか使えない。

入口では IPv4 Path MTU Discovery も必要になる。大きな内側パケットで DF が解除されていれば、入口はカプセル化前に分割できる。DF が設定されていれば破棄し、fragmentation-needed の ICMP を返す。その ICMP にも戻り道が必要である。

元の長さ、DF、追加オーバーヘッド、CLNP 分割許可、制約リンク、断片、ICMP、観測点を保管して初めて説明できる。単純な成功率は、サイズ依存のブラックホールを装置の不安定さに見せてしまう。

トンネルは安全境界ではなかった

RFC 3147 は CLNS と GRE がこの用途に安全性を与えないと明記した。保護が必要なら、GRE over CLNS に入る前に別の方法をペイロードへ適用する。カプセル化は認証、暗号化、権限付与ではない。

三つのヘッダーがすべて正しくても、未承認の管理命令であり得る。終端が同じバイト列を出力しても、アプリケーションは拒否できる。応答があっても、独立した装置認証なしには発信主体を確定できない。

後年の GRE 拡張や現在の保護手段を導入することはできる。しかし 2001 年 7 月の仕様にさかのぼって属性を付けてはならない。観測された保護機構を、その時点のものとして記録する必要がある。

一時的な橋が旧網に新しい重要性を与えた

新しい IP 装置が GRE over CLNS に依存した瞬間、旧網は単なる撤去対象ではなくなった。新装置を管理する実行経路の一部になったからである。早く止めすぎれば、近代化の証拠とされた装置から先に孤立する。

これは CLNS を永久に残す主張ではない。廃止のための条件を明確にする。すべての依存装置に別経路があり、複数サイズが通り、安全制御が移り、ロールバックを試し、切替後の装置状態を確認する必要がある。トンネルカウンターだけでは足りない。

CLNS 運用者はルーティングと NSAP 計画を、IP 運用者は新経路を、ベンダーは管理アプリケーションを、サービス責任者は切替判断を支配する。IETF は境界の互換性を作れても、権限を一つに統合できない。

歴史的には、CLNP over IP と IP over CLNS が向かい合って存在したことが重要である。旧装置は新網を渡り、新装置は旧網を渡った。最小仕様は交差点だけを整え、将来判断を運用者に残した。

動くコードは計画への異議申立てである。装置状態が変わらなければ管理は失敗、小さいパケットしか通らなければ経路は未完成、CLNS だけが復旧路なら置換は終わっていない。トンネルは時間を買うが、完了証明書にはならない。

出典