要約

  • draft-ietf-intarea-dhcp-rate-signaling-00は、加入者向けに設定されたレートをDHCPv4とDHCPv6で運ぶ提案であり、実効速度や物理容量を測定する仕組みではない。
  • 契約プラン、サーバー通知、L2/L3の計数基準、中継での変更、実際のシェーパー設定、物理上限、別途行った測定を「レート権限記録」で切り分けるべきだ。

試験をしていないのに数字が表示される

家庭用ルーターがDHCP応答を受け取った直後、管理画面に「1 Gbps」と表示したとする。ネットワークから来た精密な数字であり、ルーター自身がその値でシェーパーを設定していれば、利用者は回線能力が確認済みだと受け取りやすい。しかし、その時点でルーターはテスト用トラフィックを流す必要も、経路上の混雑を観測する必要もない。

提案中のDHCP Explicit Rate Signalingが扱うのは測定ではなく、アクセス網内の設定共有である。CPEと外付けモデムやONTを結ぶEthernetのリンク速度は、加入者が購入したレートより高いことがある。CPEが物理リンクしか見られなければ、実際の制約より奥に大きなキューを作ってしまう。上り・下りの設定レートが分かれば、CPE、relay、DHCP snoopingを行うL2装置は、適切な場所でshaping、policing、Active Queue Managementを行いやすくなる。

有用性は数値の出所を変えない。DHCPサーバーは、ローカル設定、RADIUS/AAA、外部ポリシーサーバーなどから値を取得できる。つまり通知は、商品プランや加入者ポリシーをネットワーク機器向けに投影したものだ。パケットを送り、利用可能容量を発見した結果ではない。

文書の段階も区別が要る。個人草案の改訂01に対するINTAREAの採用呼びかけは2026年7月31日に始まり、8月27日に議長が採用コンセンサスを記録した。同日、内容を維持した作業部会版00が提出された。これは審議の場が決まったことを示すが、RFCの成立を意味しない。Datatrackerには目標RFCステータスが記載されず、IANAに求めるコードもTBDのままである。

一つのbit/sに三つの読み方

草案のコンテナには、64ビットの上り値、下り値と、レート種別が入る。単位が同じでも、種別が違えば数値が支配する範囲は変わる。

種別0は情報提供用である。表示やテレメトリーに使えても、インターフェース、シェーパー、ポリサー、AQMを設定してはならない。種別2はレイヤー2のレートで、種別を省略した場合の既定値でもある。Ethernetフレームを数える一方、FCSとパケット間隔は含めない。種別3はIPヘッダーとペイロードを数えるレイヤー3のレートで、草案は商品上の帯域や速度測定でよく用いられる基準だと説明する。

この差は小さな注記ではない。VLANタグやトンネルのオーバーヘッドがあれば、L2で制御する装置とL3で測るアプリは異なる値を示し得る。どちらかが誤動作しているとは限らない。未知の基本種別を受信した装置は、推測して適用せず、オプション全体を破棄して既定値へ戻ることになっている。

ゼロも特殊な命令である。レート0は無制限を表し、以前の制限を外して機器の初期設定へ戻す用途を持つ。「明示的なゼロ」「オプションなし」「形式エラー」「応答未観測」を同じ0 Mbpsとして保存すれば、障害調査に必要な状態遷移が失われる。

権威はサーバーで終わらない

クライアントはオプション対応を要求リストで示し、最大レートや希望するL2/L3種別をヒントとして送れる。それでも最終的なDHCPACKまたはDHCPv6 REPLYではサーバーの値が優先される。ただし、ここでいう権威はDHCP取引内のものだ。元になった契約情報が正しいか、AAAプロファイルが最新かまでは保証しない。

さらに、配送経路には編集者がいる。DHCPv4 relay、特にBNGは、転送前にオプションを追加、変更、削除できる。DHCPを監視するL2スイッチは値を抜き出し、自分の加入者側インターフェースにキューやポリサーを作れる。DHCPv6では入れ子のrelay-replyヘッダーにより、クライアント用と中間relay用に異なるレートを届けられる。relayは自分宛ての階層を処理し、クライアント向けの内部ペイロードを覗かない設計だ。

同じアクセス経路に複数の有効値が存在し得る理由はここにある。CPEは上りの待ち行列、アクセスrelayは別区間、BNGは下りの制約を担当するかもしれない。異なる値は直ちに矛盾ではないが、CPE画面の一つの数字だけでは全体のポリシーを代表できない。

値には寿命もある。DHCPv6のReconfigureやリース更新はセッション中に設定を変えられる。DHCPv4ではDHCPOFFERのレートをサーバー選択の材料にできても、適用するのはDHCPACKに入った値だけである。メッセージ種別、取引識別、受信時刻、リース期限を捨てると、「現在値」の現在性を説明できない。

2 Gbpsの通知を1 Gbpsのポートが受けたら

草案は、通知値が物理インターフェース能力を上回る場合も扱う。2 Gbpsを受けたCPEのWANポートが1 Gbpsなら、実際に適用するshaping、policing、AQMは物理上限まで下げるべきだ。画面には元の通知値と上限適用後の値を両方示し、差をログに残すよう勧めている。

ここには少なくとも三つの事実がある。ネットワークが通知した値、機器が適用した値、ポートが物理的に扱える値だ。速度測定は四つ目であり、測定サーバー、アクセス網の外側の経路、混雑、トランスポート、Wi‑Fi、端末負荷に左右される。一つの列で代用できる関係ではない。

競合処理にも履歴が必要だ。DHCPv4とDHCPv6が違う値を出した場合、草案はDHCPv6を優先し、現在の設定がどちらに由来するか保持する。同じサブオプションが複数あれば、最後に処理したものが勝つ。PPPoEではPPP認証が独自のレートを渡していてもDHCPを優先し、ゼロ受信またはPPPセッション終了で既定値へ戻す。

最終的な「設定レート」だけを見ても、v6がv4に勝ったのか、relayが書き換えたのか、ポートで切り下げたのか、セッション終了で解除されたのか分からない。採用されなかった候補も判断の証拠である。

レート権限記録を一件ずつ作る

実装時には、作用したレートごとに小さな権限記録を残すべきだ。これは本稿のガバナンス提案であり、Internet-Draftの必須要件ではない。

冒頭には、加入者セッションまたはリース、機器、インターフェース、DHCP版、メッセージ種別、取引の手掛かり、受信時刻、期限を置く。共有可能なら契約プランとサーバーポリシーの出所も記し、サーバーが通知した上り・下り、情報用/L2/L3の種別を原値として保存する。

変更可能な各hopは別の行にする。relayやBNGが何を受け、追加・変更・削除のどれを行い、何を転送し、どのローカルキューに適用したかを残す。DHCPv6なら対象となるrelay-reply階層を示す。監視しただけのスイッチに、実行したという属性を付けてはいけない。

結果欄にはshaper、policer、AQMの有効値、物理上限、上限を使った理由、競合に勝ったプロトコル、解除・期限条件を分けて置く。性能測定は、方法、両端、時刻を備えた別系列として関連付ける。「通知」「適用」「物理対応」「契約」「測定」という動詞を画面にも残せば、一語の「速度」が作る越境を防げる。

もっともらしい値ほど来歴が必要になる

DHCPはメッセージ認証なしで使われる場合が多い。草案は、偽造応答で不当に低いレートを注入すればサービス妨害になり得るとし、運用者が妥当性のしきい値を設ける案を挙げる。これは草案の脅威評価であって、実事件の報告ではない。

しきい値は極端な数字を止められても、もっともらしい偽値の出所を証明しない。正当なダウングレードを拒む可能性もある。どのシステムがプランを選ぶ権限を持ち、どのrelayが上書きでき、誰が逸脱を調査するのかという管理上の権限も必要になる。

現在のIANA BOOTP/DHCP Parametersには、この提案のオプション名やサブオプション・レート種別レジストリはまだない。TBDを使う草案としての現在地を示すだけで、却下でも将来の割当保証でもない。試験導入は暫定コードと草案版を必ず結び付ける必要がある。

証拠が届く範囲

RFC 7567はボトルネック付近のAQMがなぜ重要かを示し、RFC 9330はL4Sにおける浅いキューと輻輳通知の関係を説明する。適切な設定レートがそれらを助け、結果として利用者の測定体験を改善することはあり得る。

それでもDHCP応答が証明するのは、特定の権限経路が特定の取引・リースで指示を渡したことまでだ。性能を論じるなら、ポリシーの出所、中継の操作、適用状態、物理限界、独立測定を接続しなければならない。bit/sの桁数は、主張の範囲を広げない。

出典