要約

  • RFC 9900 は TCP/UDP の 831、832、833 を歴史的 NETCONF transport から de-assign する一方、service name を保持する。変わるのは協調レコードであり、全装置の状態ではない。
  • 退役には image、設定、listener、middlebox、traffic を範囲付きで調べる必要がある。port number だけでは protocol も不在も確定しない。

廃棄予定の予備機が、棚から一台だけ戻ってきた。起動すると古い service table を読み、かつての番号で管理プロセスを待ち受ける設定が現れた。中央の資産台帳にはなく、通常の scan 対象にも含まれていなかった。

その装置は実運用されたとは限らない。listener が本当に立ち上がったとも、NETCONF を話したともまだ言えない。それでも、登録変更から普遍的な不在を推論できない理由は十分に示している。

RFC 9900 は netconf-beep から 831、netconfsoaphttp から 832、netconfsoapbeep から 833 を TCP/UDP の双方で解放する。RFC 4744 と RFC 4743 は Historic で、既知の実装・配備はないとされる。

ただし service name は消えない。番号欄が空になり、過去の割当を示す note が残る。RFC 6335 では、名前は一意な象徴キー、port number は有限の共有資源である。IANA は de-assignment の前に未使用を合理的に確認し、番号を Reserved とし、歴史を記録する。

この構造は重要だ。サービスの歴史を忘れずに、希少な番号だけを協調対象から戻せる。現在の register は「この番号は旧サービスに割り当てられていない」と証言できる。端末内のファイル、firmware、template、firewall が更新済みかは証言できない。

RFC 9900 の “no known implementations and deployments” は、調査で得た強い情報である。しかし known の範囲は有限だ。閉じた管理網、停止中の lab、複製された image、独自設定まで世界的に観測する仕組みはない。だから本文は、旧関連を持つ設定があれば再評価し更新せよ、と明記する。

ローカル退役では、まず母集団を残す。対象 vendor、version、asset、repository、backup、golden image、service database、firewall/NAT、IDS、flow retention を列挙する。到達不能な装置も結果の一部である。検索式と実行時刻がなければ、negative evidence は再現できない。

次に、意味を段階化する。設定文字列は deploy 可能性、socket は待受け、transport handshake は接続、protocol parse は protocol identity、認証済み session は管理経路、application record は操作結果を示す。一段の証拠を後段の証明として扱わない。

RFC 7605 は、assigned port が exclusive use を保証しないと警告する。誤設定でも意図的利用でも、任意の service が任意の port に現れ得る。content validation が必要である。したがって 831 の listener を見て直ちに BEEP と名付ける scan も、何も見えず完全退役と結論する scan も粗すぎる。

時間軸も欠かせない。現在の IANA registry は現在の権威ある状態を示す。古い firewall rule の作成時点の意味は、historic note と当時の設定を組み合わせて復元する。incident record には registry epoch、local revision、process identity、traffic、application result が要る。

過剰な cleanup も危険である。RFC 6242 の NETCONF over SSH は 830、RFC 7589 の NETCONF over TLS は 6513、RFC 8071 の Call Home は 4334 を含む。RFC 9900 が扱うのは 831、832、833 であり、「NETCONF」と付く全経路ではない。

将来の reuse では、過去が新しい意味に混入する。RFC 6335 は reuse を de-assignment と新 assignment の連続として扱い、旧利用が広がった疑いがあれば慎重な review を求める。RFC 7605 は reclamation が手続上可能でも実務上ほぼ不可能だと述べる。

新しい assignee は正当な協調権限を得る。しかし受信した全 packet の identity は得ない。初期運用には quarantine、content-aware canary、source 分布、collision 指標、rate limit、曖昧な traffic の処理方針が必要だ。番号は rendezvous point であり、認証情報ではない。

rollback も registry と local で分ける。local rule や image は戻せる。RFC 9900 は戻せない。将来別サービスへ割り当てられた後に旧対応を復元すれば、復旧ではなく衝突になり得る。rollback unit には registry epoch と protocol probe を含めるべきだ。

Heng Lu の Running-Code Primacy は、register を否定せず、実行状態を装置自身の証拠で確認する。Minimum Initial Specification は薄い共通協調と、運用者が担う局所判断を両立させる。

Reality Layers が示す通り、正確な象徴レコードほど管轄外へ拡張されやすい。Data Sovereignty は形式的権限と実務的制御を分ける。RFC 9900 は割当終了を証明した。退役完了は、各 operator が別の ledger で証明する。

Sources