要約

  • RFC 3074は、事前設定された256バケットの割当とクライアント識別子を使い、複数のDHCPサーバーが要求ごとの交渉なしに同じ応答判断を行えるようにした。
  • ハッシュが分けたのは応答資格であり、実測された仕事量ではない。未割当バケットは応答の空白になり得るし、遅延応答もリース提供の証明にはならない。

負荷計ではなく、応答先を分ける仕組み

DHCPのブロードキャストは複数のサーバーへ同時に届くことがある。2001年のRFC 3074は、クライアントを変更せずに重複応答を減らす方法を提案した。各サーバーが取引識別子に同じハッシュを適用し、結果が自分のHash Bucket Assignment（HBA）に含まれるときだけ応答する。

入力には、存在すればDHCP Client Identifierを使う。なければハードウェア長とクライアントのハードウェアアドレスを用い、先頭16バイトまでを処理する。Pearsonハッシュは値を256区画のいずれかに写す。32オクテットのビットマップがサーバーの担当区画を示し、BOOTPリレーは区画をServer IDに対応付けて転送先を選べる。

つまり、毎回の交渉を初期設定へ移した設計だった。出発点は当時作業中だったDHCP Failover案の最適化で、後に協調サーバーやBOOTPリレーへ用途が広がった。サーバー間の要求単位の交換を省き、既存クライアントを変えないことが狙いだった。

ただし設定画面の比率は、CPU使用率、応答時間、アドレスプールの圧迫、割当成功件数ではない。RFCは短期間なら実際の割合が目標からずれ、要求数が増えるほど設定比率へ近づくと説明する。これはクライアント取引の長期的な分布であり、各取引の費用や各サーバーの仕事量が等しいという意味ではない。

所有者のいない区画は、意図された沈黙にもなる

重要なのはハッシュ式そのものより、HBAの空欄だ。結果がどのサーバーにも割り当てられていない場合、その取引は完全に無視され得る。RFCは、状況によってはそれが望ましいとも記す。無応答はパケット損失だけでなく、構成された方針からも生じる。

任意のDelayed Service設定を使えば、通常は担当しないサーバーも、クライアントが一定時間待った後に応答できる。これは時間経過後の別ルートであり、稼働中の合意形成でも、指定サーバーの故障判定でもない。選ばれたサーバーが利用できない場合や適切なアドレスを持たない場合も、実装側の対応に委ねられる。

リレーを介する経路では段階がさらに見えやすい。リレーはバケットを一台へ送ることも、別のフェイルオーバー構成を持つプライマリー／バックアップ組へ送ることもできる。選択、転送、リース状態の共有、クライアントによるアドレス利用は別の事実だ。RFC 3074は選択方法を定めるが、共有リース状態や一連の成功を証明する仕組みではない。

IETF Datatrackerは現在もRFC 3074をProposed Standardと記載する。これは文書の標準化上の位置であり、今日の導入実績ではない。2017年のRFC 8156はDHCPv6フェイルオーバーと障害・ネットワーク分断時のリース引継ぎを定義するが、RFC 3074の更新や配備を示すものではない。

Heng Luの後年の「Reality Layers」はDHCPの証拠ではなく、規則、運用者の設定、サーバーの実行、クライアントの結果を混同しないための編集上の視点としてのみ参照する。RFC 3074の歴史的な仕事は応答資格を計算可能にしたことだ。サービスの成否まで自己証明できるようにしたわけではない。

出典