要約

  • draft-ietf-intarea-dhcp-rate-signaling-00 では、DHCPOFFERやADVERTISEの速度はサーバー選択に使えても、DHCPACKまたはREPLYを受けるまで適用してはならない。
  • 監査には数字だけでなく、メッセージ状態、発信者、対象、リレーによる変更、レート種別、リース期限、物理上限、適用後の状態が必要になる。

二つのDHCPサーバーが応答する。一方のDHCPOFFERは500 Mbit/s、もう一方は300 Mbit/sを示した。クライアントはその情報を選択理由の一つにできる。だが500という数字を見た瞬間にシェーパーを書き換えることはできない。選ばれたサーバーがDHCPACKで最終値を返して初めて、設定の根拠になる。

この時間差は細かな実装規則に見えるが、制御権限の境界そのものだ。「端末は500 Mbit/sを受信した」というログだけでは、候補の広告だったのか、最終確認だったのか分からない。数字は同じでも効力が違う。

INTAREA作業部会のDHCP Explicit Rate Signaling案は、上り・下り速度とレイヤー2または3のレート種別を運ぶ。物理ポートが契約アクセスより高速な場合、CPEが真のボトルネック付近にシェーパーやAQMを置けるようにするのが狙いだ。リレーやDHCP snoopingスイッチも利用できる。

ただし、2026年8月27日付のrevision 00はInformational Internet-Draftで、期限は2027年2月28日である。RFCでも、特定事業者の導入実績でもない。要求中のオプションコードやレジストリは確定済みとは限らない。

選択に影響する情報と、状態を変える権限

初期提示値には役割がある。クライアントは、望ましい速度を示すサーバーを選ぶかもしれない。ところが提示後に選ばれたサーバーが異なる値を返すことも、値を返さないこともある。リレーが途中で変更する可能性もある。

したがって、監査記録は「見た値」と「適用根拠になった値」を分けなければならない。トランザクションID、メッセージ種別、選択サーバー、ACK/REPLYでの再提示、リレー経路、適用時刻を結び付ける必要がある。

クライアント自身も、物理上限や望むレート種別を提案できる。サーバーはそれを受け入れ、拒否し、変換してよい。要求に書かれた数字は端末側の提案を示すだけで、購入契約やネットワークの最終方針を証明しない。

リレー後の数字を「サーバー値」と呼ばない

DHCPv4リレーはDHCPACKのオプションを読み、自身のポリサーを設定できる。RADIUSなどのAAA属性に基づき、オプションを追加、変更、削除することも想定されている。

これはアクセス網の実務には便利だが、証拠の扱いを難しくする。中央サーバーの出力とクライアントの入力は一致するとは限らない。変更が正規の処理であっても、変更前後を別の記録として残すべきだ。

必要なのは、リレーの識別、加入者セッション、AAAレコードの版、変更前後の値、方向、種別、対象、理由、有効期限である。RFC 3046やRFC 2865は周辺の仕組みを説明するが、個別変更の正当性を自動的には与えない。

DHCPv6では入れ子の位置が宛先を示す

サーバーはクライアント向けREPLYと、複数のRELAY-REPL層に別々の速度を置ける。CPEには480 Mbit/s、アクセスリレーにはバースト余地を含む520 Mbit/sという設計もあり得る。異なる対象への異なる命令であり、単純な矛盾ではない。

リレーは自分のヘッダーに置かれたオプションを処理し、内側のクライアント向けペイロードから都合のよい値を拾ってはならない。包んだパケット全体を保持していることと、内部の全命令を実行する権限は一致しない。

ログが加入者IDと速度だけを保存すると、この対象境界が消える。どのカプセル化層にあり、誰宛てだったかまでがデータの意味である。

タイプが不明なら数字も使えない

同じ500 Mbit/sでも、レイヤー2とレイヤー3では数える範囲が違う。誤った種別で設定すれば、意図した位置からボトルネックが移る可能性がある。

案は未知のサブオプションコードを無視して将来拡張を許す一方、既知フィールドの未知値が全体の意味を左右する場合、Rate Option全体を無効にする。魅力的な数字だけを救済して推測することは認めない。

重複フィールドは最後のものが処理される。収集基盤が順序を失った集合に正規化すれば、端末の判断を再現できない。リースの成功とレートポリシーの成功も分けるべきで、DHCP自体が完了しても速度オプションだけ棄却され得る。

期限切れは同じ数字の由来を変える

デュアルスタックで値が競合するとき、案はDHCPv6を優先し、適用値と元プロトコルを一緒に保持するよう求める。v4とv6がともに400 Mbit/sを示していても、v6リースが切れれば、画面上の数字を変えずに権威はv4へ移る。

見た目が連続していても証拠は連続していない。サーバー、リレー経路、期限が変わる。v4も無効なら既定設定へ戻る。PPPoEではDHCPの値がPPP認証応答の値に優先するが、セッション終了はその権限を失わせる。

ゼロは回線容量ゼロという観測ではない。制限なし、または既存リミッターを削除して既定へ戻す命令だ。制御値を性能計測として描けば、正常な解除を障害に変えてしまう。

snoopingスイッチも命令を実行すれば統治対象になる

DHCP snoopingスイッチがオプションを見てハードウェアキューやポリサーを設定した瞬間、単なる観測者ではなくアクチュエーターになる。パケットキャプチャは値が通過したことを示すが、その値がスイッチ宛てだったことや設定成功までは示さない。

入口ポートの信頼領域、セッションとの結合、メッセージ状態、カプセル化、対象、インターフェース能力、ローカル上限、設定トランザクション、ハードウェア読戻しを一本の受領連鎖にする必要がある。

ここではHeng Luのrunning code primacyが具体的な意味を持つ。組織図上の権威ではなく、最終的にトラフィックを変えた稼働状態を調べる。ただし稼働している事実だけでも正当性は生まれない。誰の命令でその状態になったかを同時に残す。

平文の正しい命令は攻撃にもなる

DHCPは多くの環境で平文かつ未認証である。偽サーバーや経路上の攻撃者が低い速度を注入すれば、アドレス取得を壊さずに局所的なサービス妨害ができる。最低しきい値は極端な値を拒み、物理上限は過大値を抑えるが、送信元認証にはならない。

RFC 3118はDHCP認証を定義する。しかし文書の存在は導入の証拠ではない。信頼ポート、サーバー許可リスト、リレー検証、snooping保護、認証の実運用、AAAの出典を確認しなければならない。

キュー設定はレイテンシ改善の証明ではない

正しいボトルネック速度はshapingやAQMに役立つ。RFC 7567は過大キューの問題を示し、RFC 9330はL4Sの浅いキューを説明する。それでも、オプション受信だけで結果は証明できない。

実効設定、キュー占有、マーク、ドロップ、遅延分布、スループット、エラー、ロールバックを後から観測する必要がある。信号は意図、設定コミットは行為、利用者体験は別の結果である。

共通仕様の価値は狭く保つほど強い。方向、レート種別、対象、実行可能になるメッセージ、期限、競合時の優先、フォールバックを相互運用可能にできる。加入者台帳の真偽やリレーの透明性、結果の良否まで保証するものではない。

不確実性

revision 00は今後変更、置換、失効する可能性がある。本稿では特定の事業者、CPE、リレー、スイッチ、ファームウェアの実装を確認していない。性能と運用上の利点は提案理由であり、各環境での検証が必要だ。

情報源