要約

  • draft-ietf-intarea-dhcp-rate-signaling-00 は、上り・下りの64ビット値と、情報表示、レイヤー2、レイヤー3を区別する Rate Type を提案する。数値は瞬間的な容量の測定ではなく、サービス方針の表現である。
  • クライアントの値は提案にすぎず、サーバー応答が採用値になる。さらにリレーが値を変更でき、DHCPv6では複数のリレー階層へ別々の値を送れる。「DHCPで届いた」だけでは、決定者も実行者も一意に決まらない。
  • 運用上の事実にするには、元メッセージと有効期間、実際の設定値、アクティブなキュー、パケットカウンター、遅延・損失・スループットを段階ごとに確認しなければならない。

加入者宅のルーターがDHCPv6を更新し、REPLYから下り1,000,000,000 bit/sを受け取ったとする。画面は「利用可能 1 Gbit/s」と表示し、設定処理も成功を返した。ところが大容量転送が始まると、対話型通信の遅延は急に増えた。

矛盾とは限らない。1 Gbit/sは加入者プロファイルかもしれず、経路の実測値ではない。通知がレイヤー2、速度試験がレイヤー3なら、同じ数字を直接比較できない。AQMが待機中の論理インターフェースへ付いた可能性もある。BNGやアクセス区間に、さらに低いpolicerが存在するかもしれない。

これは障害報告ではなく、証拠の境界を明らかにするための想定である。ワーキンググループ版00が届けるのは「どの値を使ってほしいか」という信号であり、「その値がどこで何を実現したか」という受領証ではない。

「速度」を三つの台帳に分ける

ブロードバンド運用では、別物が一つの速度欄へ押し込まれやすい。第一は商品・AAAが決めた加入者レート。第二はshaper、policer、AQMに実際に書かれた有効値。第三は、ある時刻のあるフローが得た配送結果である。

台帳 必要な記録 それだけでは分からないこと
通知 生のオプション、方向、Rate Type、メッセージ種別、トランザクション、リース、サーバー／リレー 設定が実行されたか
制御 装置、インターフェース、キュー、アルゴリズム、オーバーヘッドモデル、書込みと読戻し そこが真のボトルネックか、利用者結果が改善したか
結果 ECN、drop、キュー滞留、遅延、損失、定義済み負荷での配送量 商品契約やポリシー決定者

提案オプションは第一の台帳を配り、第二を作る助けになる。第三は実トラフィックしか書けない。単一の bandwidth 欄で三者を代用すると、障害時に原因を復元できない。

計数する層を失えば、数字の意味も失う

上りと下りは、それぞれbit/s単位の64ビット符号なし整数である。Rate Typeが計数範囲を定める。

タイプ2はレイヤー2で、推奨計算ではEthernetヘッダーとペイロードを含み、FCSとフレーム間ギャップを除く。タイプ3はIPヘッダーとペイロードを対象にし、VLANタグやトンネルの数による差を避ける。Rate Typeが無い場合はレイヤー2として扱う。タイプ0は情報表示用であり、物理インターフェース、shaper、policer、AQMへ適用してはならない。

同じ1 Gbit/sでも、L2制御とL3制御でアプリケーションに残る量は異なる。速度試験がL3の値なら、L2通知との差は直ちに品質不足を意味しない。運用画面がレートだけを表示してタイプを捨てると、正しい信号を誤った約束へ変えてしまう。

予約済みまたは未知のRate TypeはOPTION_RATE全体を無効にする。基本的な解釈が不明なまま制御を適用しないためである。一方、未知のサブオプションコードは無視し、残りを処理する。同一コードが複数ある場合は最後を使う。正規化値だけでなく、どの分岐で得られたかも監査記録に残す必要がある。

ゼロも文脈で異なる。方向レートのゼロは無制限／デフォルトへの復帰、つまり以前の制限の削除を示す。容量ゼロの測定ではない。Rate Typeのゼロは「表示のみ」である。二つを混同すれば、古い制限を残すか、表示情報を実行命令にしてしまう。

サーバー権威はプロトコル動作の内側に限られる

DHCPv4クライアントはPRLでオプションを要求し、DHCPREQUESTで最大値や希望タイプを提示できる。しかし提案上、それはヒントである。サーバーがどう扱うかは実装依存で、クライアントはDHCPACKに含まれる答えを採用する。DHCPOFFERの値はサーバー選択に使えても、インターフェース設定には使えない。

DHCPv6でも、OROは要求、Requestの値はヒント、適用可能な答えはREPLYである。ADVERTISEだけで設定してはならない。サーバーはRECONFIGUREを使い、T1より前にRenewやInformation-requestを起こすこともできる。

サーバーの値はローカルプロファイル、RADIUSなどのAAA、外部ポリシーから導かれる。DHCPv4リレーはOPTION_RATEを追加・変更・削除できる。したがって、サーバー応答がクライアント動作上「権威的」であっても、元プロファイルが新しいこと、転送中に変更されていないこと、データプレーンに合うことまでは証明しない。

RFC 2131とRFC 8415はDHCPv4/v6の状態遷移を、RFC 3046はリレー情報の背景を、RFC 2865はRADIUSを示す。いずれも設定結果を観測するプロトコルではない。

DHCPv6では一つの交換に複数の宛先がいる

ネストしたRELAY-REPLを使い、サーバーはクライアント向けREPLYと各リレー階層へ別のOPTION_RATEを置ける。CPEの上りshaperより、リレー側の上りpolicerを少し高くする例も示される。各リレーは自分宛ての層を消費し、内側のクライアント向け値を受動的に読み取ってはならない。

ゆえに「DHCPレート」という単数形は危険である。方向、カプセル化階層、宛先、ポリシー主体、計数層、リース、有効期間を組にして保存すべきだ。RFC 6221は参照されるLightweight DHCPv6 Relay Agentを説明するが、新オプションを実際に消費した証拠にはならない。

デュアルスタックでは値より履歴が重要になる

DHCPv4とv6の値が衝突した場合、草案はv6を優先し、適用値の出所プロトコルを保持するよう求める。v6リースが切れても有効なv4リースが残れば、保持値は以後v4由来として扱われる。v4も無ければデフォルトへ戻る。

永続的な一つの速度欄では、この判断を再現できない。取得時刻、満了時刻、リースID、優先分岐、上書き、リセット理由が必要である。

PPPoEではDHCP OPTION_RATEがPPP認証応答内のレートに優先する。ただしPPPセッションが論理リンクの土台であり、明示的なゼロまたはセッション終了で適用値は撤回される。RFC 2516はPPPoEセッションを定義する。セッション消滅後にも制御を残せば、優先順位ではなく古い権威の残骸になる。

物理リンク上限は経路探索ではない

1 Gbit/sのWANポートへ2 Gbit/sが通知された場合、草案は適用値を物理容量へ制限するよう勧める。管理機能は元の値と制限後の値を両方表示し、差をログに残すべきだとする。

これは「この装置が知るローカル上限を超えて設定しなかった」という証拠である。1 Gbit/sが実際に使えることも、そのポートが最狭点であることも示さない。PON、アクセス集約、BNG、トランジット、相手サーバーのどこかが遅い可能性は残る。名前は「有効ローカルレート」であり、「利用可能容量」ではない。

AQMが必要とするのは正しい整数より正しいキュー

動機は明快だ。CPEポートが契約レートより速いと、上流の制御しにくい装置にキューが形成され、深いバッファや粗いpolicingが遅延を生む。CPEが上流制限より少し低い値でshapeすれば、管理可能なキューを手元へ移し、AQMで待ち時間を抑えられる可能性がある。

RFC 7567はAQMの推奨事項を示す。RFC 9330、RFC 9331、RFC 9332はL4Sアーキテクチャ、ECNプロトコル、Coupled DualQ AQMを扱う。実際の効果には、正しいキュー配置、分類、ECN処理、アルゴリズム、反応する輻輳制御が必要だ。

草案自身もレート通知を「enabler」と位置づけ、AQMと輻輳制御の詳細設計を範囲外に置く。値を受け取っただけでは、qdiscの選択、アクティブegressへの接続、上流policerを避ける余裕、低遅延と利用率の両立は分からない。

認証は発言者から先へ進めない

草案はDHCPが一般に平文かつ未認証であると指摘する。偽サーバーや経路上の攻撃者が低い値を注入すれば、局所的なDoSになり得る。最低値の健全性検査や物理上限によるcapは被害を抑えるが、出所を確立しない。

仮に認証があっても、それは既知主体が命令を出したことを示すだけである。プロファイルの新鮮さ、リレーの忠実性、受信装置の実行、利用者結果は別だ。

Running-Code Primacyが重視するのは、制度やラベルより実際に動く系である。Minimum Initial Specificationは、相互運用に必要な細い核だけを共通化し、その後の選択をローカルかつ置換可能に保つ。Reality Layersは、記号、設定、物理機構、観測結果を同じ現実として扱わないための枠組みになる。

公開された草案は導入実績ではない

Datatrackerは00版をInternet AreaワーキンググループのアクティブなInternet-Draftとして示し、想定ステータスはInformational、公開日は2026年8月27日、失効日は2027年2月28日である。履歴には個人草案からの置換が記録される。WG版XML、前身の記録、個人版01で系譜を検証できる。

まだRFCではなく、オプション番号もTBDである。これらの資料は製品実装、導入率、相互運用、性能改善、実障害を証明しない。

情報源