要約

  • 6manの草案は、4オクテットのNRP Selector IDをIPv6 Hop-by-Hop optionで運ぶ。対応ノードはローカル資源を選べるが、非対応ノードは無視して転送できる。
  • 第16版は、IDの観測がサービス種別を漏らし、改変が別キューへの誘導や隔離低下を招き得ると明記した。
  • 9月6日のshepherd write-upは文書を前進可能と評価する一方、記録された実装状況はないと述べる。

この設計の互換性は、同時に証拠の空白でもある。第16版のOption Typeは、未知のオプションを飛ばす00を使う。装置が理解しなくてもパケットは目的地へ進める。したがって到着は、資源指定が全ホップで実行された証明にならない。

入口はローカル分類に基づいてNRPを選び、外側IPv6ヘッダーにIDを置く。線速処理できる中継ノードでは、宛先が次ホップとインターフェースを、IDが帯域、バッファ、キューや仮想チャネルを選ぶ。共通なのは番号の形式であり、資源表と実装は各ノードに分散している。

Sビットも万能ではない。対応ノードでIDがローカル資源に一致しない場合、S=1なら破棄、S=0なら既定資源で転送する。オプション自体を読まないノードには届かない規則だ。厳格なOAMパケットの到着は限定した経路試験になり得るが、通常トラフィックのSLAを代弁しない。

第15版から現在の第16版XMLへの重要な追加は、IDから低遅延・高スループット要求を推測して狙い撃ちできること、途中改変で別キューへ送れることだ。草案は運用者管理の信頼ドメインとフィルタリングを推奨する。だがフィールド構造に送信者認証、暗号学的完全性、ホップ別処理証明はない。

9月6日、Datatrackerと履歴にshepherdとwrite-upが加わった。11人の支持、一人からの六つの論点、代替符号化案と、それを採らず進む議長判断が公開記録になった。導入を示唆する回答もある。それでもwrite-upは「記録された実装状況なし」と線を引く。

背景資料はRFC 8200、RFC 7045、RFC 9098、RFC 9099、RFC 9673であり、NRPはRFC 9543、RFC 9732、スケーラビリティ草案に接続する。IANA IPv6 Parametersへの割当はなお要求段階だ。

Heng Luの最小初期仕様なら、共通形式とローカル判断を混同しない。現実の層はIDとキュー動作を分け、稼働コード優先は公開実装と観測を求める。信頼は宣言できても、遵守は観測しなければならない。