Cisco Network Registrar ユーザー ガイド 7.0
拡張ポイントの使用
拡張ポイントの使用
発行日;2012/01/16 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 9MB) | フィードバック

目次

拡張ポイントの使用

拡張機能の使用

拡張機能の作成、編集、および追加

タスクの決定

アプローチの決定

拡張言語の選択

言語独立の API

ルーチンのシグニチャ

ディクショナリ

ディクショナリ内のユーティリティ メソッド

設定エラー

外部サーバとの通信

拡張機能の認識

TCL 拡張機能

TCL アプリケーション プログラム インターフェイス

TCL エラーの処理

TCL でのブール変数の処理

TCL 拡張機能の設定

TCL の Init-Entry 拡張ポイント

C/C++ 拡張機能

C/C++ API

C/C++ でのタイプの使用

C/C++ 拡張機能の構築

C/C++ でのスレッドセーフな拡張機能の使用

C/C++ 拡張機能の設定

C/C++ 拡張機能のデバッグ

C/C++ での DHCP サーバ メモリへのポインタ

C/C++ の Init-Entry エントリ ポイント

拡張機能を使用した DHCP 要求処理

DHCPv6 拡張機能のイネーブル化

パケットの受信

パケットのデコード

クライアントクラスの判別

クライアントクラスの変更

クライアントクラスの処理

応答コンテナの構築

ネットワークとリンクの判別

リースの検索

リース要求のシリアル化

リースの受け入れ可能性の判別

DHCPv6 リース処理

DHCPv6 プレフィックスの使用可能性

DHCPv6 リースの使用可能性

DHCPv6 リースの割り振り

応答パケット データの収集

応答パケットのエンコード

安定した記憶域の更新

パケットの送信

DNS 要求の処理

リース状態の変化のトレース

拡張ディクショナリ

環境ディクショナリ

環境ディクショナリのデータ項目

初期環境ディクショナリ

要求ディクショナリと応答ディクショナリ

デコード済みの DHCP パケット データ項目

パラメータ リスト オプションの使用

拡張ポイントの説明

init-entry

pre-packet-decode

post-packet-decode

post-class-lookup

pre-client-lookup

pre-client-lookup の環境ディクショナリ

pre-client-lookup へのクライアントクラス データの入力

pre-client-lookup の要求ディクショナリ

post-client-lookup

post-client-lookup の環境ディクショナリ

post-client-lookup の要求ディクショナリ

generate-lease

check-lease-acceptable

lease-state-change

lease-state-change の応答ディクショナリ

lease-state-change の環境ディクショナリ

pre-packet-encode

pre-packet-encode の要求ディクショナリ

pre-packet-encode の応答ディクショナリ

post-packet-encode

pre-dns-add-forward

post-send-packet

environment-destructor

オブジェクトとオプションの処理

オブジェクトおよびオプションを処理するメソッドの使用

C/C++ でのオプションとサブオプション

拡張ポイントの使用

拡張機能を作成すると、Cisco Network Registrar が DHCP 要求を処理し、それに応答する方法を制御できます。また DHCP サーバの動作について、ユーザ インターフェイスから通常できないような変更を行えます。ここでは、DHCPv4 および DHCPv6 用の拡張機能を追加できる拡張ポイントについて説明します。


) 拡張機能は、式とは異なります(第25章「式の使用方法」を参照)。拡張機能は、要求パケットまたは応答パケットを変更するために使用します。式は、クライアント ID の作成またはクライアントのルックアップに使用します。


拡張機能の使用

Network Registrar DHCP サーバの操作を変更またはカスタマイズするには、TCL または C/C++ で拡張機能を作成して使用します。

DHCP サーバで使用する拡張機能を作成するには、次の手順を実行します。

1. 実行するタスク(どの DHCP パケット プロセスを変更するか)を決定する。

2. 使用するアプローチ(パケットプロセスをどのように変更するか)を決定する。

3. 拡張機能を追加する拡張ポイントを決定する。

4. 言語を選択する(TCL または C/C++)。

5. 拡張機能を記述する(またコンパイルしてリンクする)。

6. DHCP サーバの設定に拡張機能を追加する。

7. 拡張ポイントに拡張機能を追加する。

8. DHCP サーバをリロードして、拡張機能を認識できるようにする。

9. 結果をテストしデバッグする。

拡張機能の作成、編集、および追加

拡張機能は、作成、編集、および追加することができます。

Web UI

Advanced DHCP Extensions の順にクリックし、List DHCP Extensions ページを開きます。
Add DHCP Extension をクリックして、Add DHCP Extension ページを開きます(図29-1を参照)。

図29-1 Add DHCP Extention ページ(ローカル Advanced)

 

拡張機能を追加できる拡張ポイントを表示するには、List DHCP Extensions ページでページ上部にある Show Extension Points をクリックして、List DHCP Extension Points ページを開きます(図29-2を参照)。拡張機能を作成したら、このページで 1 つまたは複数の拡張ポイントにその拡張機能を追加し、次に Modify DHCP Extension をクリックします。

図29-2 List DHCP Extention Points ページ(ローカル Advanced)

 

CLI コマンド

extension コマンドを使用します。このコマンドでは、次のシンタックスを使用する必要があります。

nrcmd> extension name create language extension-file entry-point
 

entry-point は、 extension-file 内のエントリ ポイント名です。DHCP サーバがファイルを毎回ロードしたときの初期エントリ ポイントについて、オプションの init-entry アトリビュート値を設定することもできます(「init-entry」を参照)。この関数は、このモジュールにバインドされている拡張ポイントから呼び出せます。 extension list を使用して、拡張機能を一覧表示することもできます。

拡張機能を追加および削除するには、DHCP サーバに対する dhcp attachExtension および dhcp detachExtension を使用します。それに必要なシンタックスは次のとおりです(シーケンス番号はオプションです)。

nrcmd> dhcp attachExtension extension-point extension-name [sequence-number]
nrcmd> dhcp detachExtension extension-point [sequence-number]
 

タスクの決定

拡張機能を適用するタスクは、通常、それぞれの環境に合せて DHCP サーバの処理を一部変更します。拡張機能は、要求の受け取りからクライアントへの応答まで、次のようなあらゆる DHCP サーバの処理ポイントに適用できます。

1. パケットの受信とデコード。

2. あらゆるクライアントクラスのルックアップ、変更、および処理。

3. 応答タイプの構築。

4. サブネット(DHCPv6 の場合はリンク)の判別。

5. 既存のリースの検索。

6. リース要求のシリアル化。

7. クライアントのリース受け入れ可能性の判別。

8. 応答パケットの収集とエンコード。

9. パケットの安定記憶域のアップデート。

10. パケットの返信。

これらの手順(および各手順で使用する拡張ポイント)の一覧については、「拡張機能を使用した DHCP 要求処理」を参照してください。

たとえば、BOOTP コンフィギュレーションを使用する特殊なルーティング ハブがあるとします。このデバイスは、 chaddr フィールド内にイーサネット ハードウェア タイプ(1)と MAC アドレスを入れて、BOOTP 要求を発行します。その後、同じ MAC アドレスで、ただしハードウェア タイプをトークン リング(6)として、別の BOOTP 要求を送信します。2 つの異なるハードウェア タイプを指定すると、DHCP サーバがそのデバイスに 2 つの IP アドレスを割り振ります。DHCP サーバは、通常、ハードウェア タイプ 1 の MAC アドレスと、タイプ 6 の MAC アドレスを区別し、異なるデバイスであると見なします。この場合、DHCP サーバが同じデバイスに 2 つの異なるアドレスを渡すことを防ぐ拡張機能を記述できます。

アプローチの決定

多くの場合、1 つの問題を解決するにも多くの解決策があります。どういう種類の拡張機能を作成するかの選択にあたっては、まず入力 DHCP パケットのリライトを検討してください。この方法では、DHCP サーバの内部処理について知る必要がないので、好ましいアプローチといえます。

「タスクの決定」に説明されている問題については、次のいずれかの方法で拡張機能を作成して問題を解決できます。

トークン リング(6)ハードウェア タイプのパケットをドロップする。

パケットをイーサネット パケットに変更してから、終了時に再び元のパケットに戻す。

2 番目の方法の拡張機能は複雑ですが、DHCP クライアントは DHCP サーバからのどちらかの応答を使用できます。2 番目のアプローチではパケットをリライトしますが、ここでは
post-packet-encode
拡張ポイントを使用します(「post-packet-encode」を参照)。異なるアプローチを使用する場合は、違う拡張機能と拡張ポイントが必要です。

拡張言語の選択

拡張機能は、TCL または C/C++ で記述できます。DHCP が関係する限りにおいては、これらの言語の機能はよく似ていますが、言語設計のアプローチが大きく異なるので、これらをサポートするためのアプリケーション プログラミング インターフェイス(API)が若干異なります。

TCL :TCL のスクリプティングは C/C++ のスクリプティングよりいくらか簡単ですが、これはシングルスレッドのインタープリタ言語であり、より多くのリソースが必要です。しかし、C/C++ よりも重大なバグが生じる可能性が低いのでサーバ障害が発生する可能性も低くなります。Network Registrar は現在 TCL バージョン 8.4 をサポートしています。

C/C++ :この言語は、可能な限り高いパフォーマンスと柔軟性(外部プロセスとの通信など)を提供します。ただし、C/C++ API は TCL API より複雑です。また、C/C++ では、サーバ障害の原因となるバグが拡張機能内で発生する可能性がより高くなります。

言語独立の API

次の概念は、TCL と C/C++ のどちらで拡張機能を記述するかに依存しません。

ルーチンのシグニチャ

拡張機能はファイル内のルーチンとして定義する必要があります。また、同じファイル内に複数の拡張機能を格納できます。そこで 1 つ以上の DHCP サーバ拡張ポイントに拡張を追加することになります。DHCP サーバは、拡張ポイントに達すると、拡張機能によって定義されるルーチンを呼び出します。ルーチンは、正常終了または異常終了を返します。拡張機能が異常終了したときに、DHCP サーバがパケットをドロップするように設定できます。

1 つのファイル(TCL ソース ファイルまたは C/C++ .dll か .so ファイル)を DHCP サーバの複数の拡張機能として設定できます。これには、設定した拡張機能ごとに別のエントリ ポイントを指定します。

サーバは、すべてのルーチン エントリ ポイントを最低 3 つの引数、つまり、要求、応答、および環境の 3 つのディクショナリを使用して呼び出します。各ディクショナリには、それぞれがキーと値のペアで構成される、多数のデータ項目を格納できます。

拡張機能は、特定のデータ項目のディクショナリで get メソッドを実行して DHCP サーバからデータ項目を取得できます。

拡張機能は、多数の同じ名前のデータ項目で put または remove 操作を実行してデータ項目を変更できます。

どの拡張ポイントでもすべてのディクショナリが使用できるわけではありませんが、すべての拡張ポイントにおいて、どのルーチンの呼び出しシーケンスも同じです。拡張機能は、特定の拡張ポイントに存在しないディクショナリを参照しようとすると、エラーが発生します。「環境ディクショナリ」「要求ディクショナリと応答ディクショナリ」を参照してください。

ディクショナリ

要求、応答、およびサーバ内のデータには、ディクショナリ インターフェイスからアクセスします。拡張ポイントには、要求、応答、および環境という 3 つのタイプのディクショナリが用意されています。

要求ディクショナリ :DHCP 要求に関する情報と要求自体に含まれるすべての情報。データの値は、文字列、整数、IP アドレス、および blob です。

応答ディクショナリ :DHCP クライアントに返す DHCP 応答パケットの生成に関する情報。データの値は、文字列、整数、IP アドレス、および blob です。

環境ディクショナリ :DHCP サーバと拡張機能との間で受け渡される情報。

ディクショナリについては、「拡張ディクショナリ」を参照してください。

環境ディクショナリは、異なる拡張ポイントに付加された拡張機能間の通信にも使用できます。DHCP サーバは、拡張機能が設定された最初の拡張ポイントに達すると、環境ディクショナリを作成します。環境ディクショナリは、許容されるデータ項目の名前が DHCP サーバによって固定されない唯一のディクショナリです。環境ディクショナリを使用すると、任意の文字列値のデータ項目を挿入できます。

DHCP クライアントの要求と応答の間の制御フローにあるすべての拡張ポイント(変化の原因によって異なるが、 lease-state-change 以外のすべての拡張ポイント)は、同じ環境ディクショナリを使用します。その結果、拡張機能は何らかの条件が存在することを判別し、環境ディクショナリに番兵を置き、後続の拡張機能が同じ条件を判別しないようにします。

前の例では、 post-packet-decode 拡張ポイントにある拡張機能が、パケットを興味深いパケット(特定のメーカーのデバイス、BOOTP、およびトークン リングからのパケット)であったと判別し、ハードウェア タイプをトークン リングからイーサネットにリライトします。拡張機能はまた、環境ディクショナリに番兵を置いた後、 post-packet-encode 拡張ポイントの非常に単純な拡張機能で、ハードウェア タイプをトークン リングに戻します。

ディクショナリ内のユーティリティ メソッド

各ディクショナリは、拡張機能の追跡レベルをリセットし、値を出力ファイルにロギングできるユーティリティ メソッドがあります。

設定エラー

拡張機能が失敗する理由は数多くあります。次に例を示します。

サーバがファイルを見つけられない。

ファイル内にエントリ ポイントまたは init-entry ポイントが存在しない。

拡張機能自体が init-entry 呼び出しからエラーを返す。

拡張機能のエラーは、それ自体重大なエラーではなく、これによって DHCP サーバが始動しないということはありません。ただし、失敗したその拡張機能を拡張ポイントのいずれかで設定している場合、サーバは始動しません。したがって、設定プロセスをデバッグするために、 init-entry ポイント(「init-entry」を参照)で拡張機能を設定し、拡張ポイントに追加しないという方法が考えられます。そのプロセスを正常に終了した時点で、拡張機能を拡張ポイントに追加します。

外部サーバとの通信

外部サーバまたはデータベースと通信して、クライアントクラスに影響を与えたり、着信 DHCP クライアントの要求を検証したりする拡張機能を記述できます。このような拡張機能の記述は、非常に高いスキルとデバッギングの専門知識が要求される複雑な作業です。DHCP サーバのパフォーマンスを許容レベルに維持するには、このような拡張機能をマルチスレッド化する必要があり、非常に高速で外部サーバと通信する必要があります。

パフォーマンスの低下は、拡張機能により、要求を処理しているスレッドが停止することが原因で発生する場合があります。拡張機能が外部サーバと通信している間、スレッドは停止します。このやり取りに 50 ~ 100 ミリ秒以上かかる場合、サーバのパフォーマンスに深刻な影響を及ぼします。拡張機能を配置する特定の環境に影響があるかどうかは、環境によって異なります。

外部サーバと同期して通信(つまり、外部サーバと通信するために着信 DHCP クライアント要求の処理を停止)しないようにする 1 つの方法は、DHCP クライアント要求を処理している間にこの通信を行わないことです。これは明白なことですが、一見すると不可能にも思われます。ただし、DHCP クライアント サーバ プロトコルの性質を利用することで、DHCP クライアント要求処理から外部サーバへのアクセスを切り離すことができます。

このボトルネックを回避するには、拡張機能の一部としてキャッシュ メカニズムを使用します。サーバが拡張機能を使用して要求を処理する場合、キャッシュにクライアント データがないかを拡張機能でチェックします(マルチスレッド化の問題を避けるために適切なロックを使用)。これは、クライアントの状態によって次のように処理されます。

クライアントがキャッシュ内にある(かつ期限が切れていない)場合は、キャッシュ内のデータに応じて、拡張機能で要求を受け入れるか、拒否します。

クライアントがキャッシュ内にない場合は、拡張機能で外部サーバ(UDP を推奨)への要求をキューに入れてから、DHCP クライアント要求をドロップします。クライアントが要求を再送信するまで、データはキャッシュに入っています。

このキャッシュ メカニズムでは、拡張機能がレシーバ スレッド( init-entry 拡張ポイントで開始および停止)を持っている必要があります。このスレッドはソケットを読み取り、応答によりキャッシュをアップデートします。このスレッド(または個々のスレッド)もタイムアウトして、キャッシュから古い項目を削除する必要があります。ただし、シングル スレッドを使用すると、よりサイズが大きい受信ソケット バッファを設定しなければならない場合があります。

このような技術が必要とされるのは、DHCP サーバ上の負荷が高く、DHCP サーバの負荷に必要なパフォーマンスをサポートするのに外部サーバのスピードが十分でない場合だけです。ただし、現実の問題として、このような状況が頻繁に見られます。また、外部サーバが到達不能(接続タイムアウトが秒単位ではなく、分単位で発生する)になった際の対処法も考慮する必要があります。

拡張機能の認識

DHCP サーバが拡張機能を認識できるのは、それ自体が最初に設定されたとき、またはリロード時のみです。拡張機能や拡張機能の設定の変更は、一般に可能です。しかし、サーバをリロードまたは再始動するまで、変更は有効ではありません。拡張のデバッグ時に、DHCP サーバのリロードを忘れることがエラーの原因となる場合がよくあります。

Network Registrar がリロードを必要とする理由は、拡張機能を事前にロードし、サーバの設定時にそれらの準備を完了することにより、処理のインパクトを最小限に抑えるためです。このアプローチは実稼働モードでは有用ですが、拡張機能のデバッグ時には面倒に感じられることがあります。

TCL 拡張機能

拡張機能を TCL で記述する場合、TCL API、エラーとブール変数の処理、および TCL 拡張機能を初期化する方法について理解しておく必要があります。Network Registrar は、TCL バージョン 8.4 を使用します。

TCL アプリケーション プログラム インターフェイス

すべての TCL 拡張機能は、同じルーチン シグニチャを持ちます。

proc yourentry { request response environ } { # your-code }
 

任意のディクショナリでデータ項目を操作するには、次の引数をコマンドとして扱う必要があります。したがって、入力パケットの giaddr を取得するには、次のように記述します。

set my_giaddr [ $request get giaddr ]
 

この記述により、TCL 変数 my_giaddr が、パケット内の giaddr の文字列値に、たとえば 10.10.1.5 や 0.0.0.0 のように設定されます。

入力パケットの giaddr は、次の TCL 文を使用してリライトされます。

$request put giaddr "1.2.3.4"
 

1 つのルーチン エントリを複数の拡張ポイントに設定し、その動作を、呼び出し元としてサーバに使用される拡張ポイントに応じて変更する場合、拡張ポイントの ASCII 名が、DHCP サーバから環境ディクショナリのキー extension-point の下に渡されます。

TCL 拡張機能のサンプルについては、次のデフォルトの Network Registrar ディレクトリを参照してください。

Solaris および Linux の場合 :/opt/nwreg2/examples/dhcp/tcl

Windows の場合 :\Program Files\Network Registrar\examples\dhcp\tcl

TCL エラーの処理

TCL エラーは次の場合に生成されます。

利用できないディクショナリを参照した場合

利用できないディクショナリのデータ項目を参照した場合

無効なデータ項目(たとえば無効な IP アドレス)に対して、put 操作を要求した場合

これらの場合は、文を catch error 文で囲まない限り、拡張機能が即座に失敗します。

catch { $request put giaddr "1.2.3.a" } error
 

TCL でのブール変数の処理

環境ディクショナリでは、ブール変数は文字列値であり、 true または false の値を持ちます。DHCP サーバは、拡張機能によって値が true または false に設定されると想定します。一方、要求または応答ディクショナリでは、ブール値はシングルバイトの数値形式であり、 true 1 false 0 となります。このアプローチは C/C++ 拡張機能では効率的ですが、TCL API がやや複雑になります。

TCL 拡張機能の設定

TCL 拡張機能を設定するには、拡張機能を記述して拡張機能のディレクトリに保存します。UNIX および Linux では、/opt/nwreg2/extensions/dhcp/tcl ディレクトリになります。Windows では、\Program Files\Network Registrar\extensions\dhcp\tcl ディレクトリになります。

DHCP サーバは、始動時に拡張機能を設定するとき、TCL ソース ファイルをインタープリタに読み込みます。ソース ファイルにシンタックス エラーがあって、TCL インタープリタがファイルをロードできない場合も拡張機能が失敗します。通常、DHCP サーバによって TCL からログファイルにエラー トレースバックが生成され、ユーザがエラーを見つけるのに役立ちます。

TCL の Init-Entry 拡張ポイント

TCL 拡張機能は、 init-entry 拡張ポイント(「init-entry」を参照)をサポートし、コマンドラインの init-args パラメータに与えられた引数が、キー arguments に関連付けられた環境ディクショナリに表示されます。

パフォーマンス向上のため、DHCP サーバで複数の TCL インタープリタを、それぞれ独自の TCL コンテキストで実行できます。サーバは、それが実行するすべての TCL コンテキスト(インタープリタ)に対して、 init-entry ポイントで一度だけ TCL 拡張機能を呼び出します。複数の呼び出しが存在する場合は、TCL 拡張機能の init-entry が堅牢であることを確認する必要があります。

複数の TCL コンテキスト間で情報を交換することはできませんが、 init-entry が TCL インタープリタ内のグローバル TCL 変数を初期化でき、TCL 拡張機能がそのインタープリタに関係なくグローバル TCL 変数にアクセスできます。

TCL インタープリタは、すべての TCL 拡張機能で共有されることに注意してください。TCL 拡張機能がグローバル変数を初期化するか、手順を定義している場合、他の TCL 拡張機能のグローバル変数や手順名と競合していないことを確認します。

C/C++ 拡張機能

すべての DHCP C/C++ 拡張機能は、 dex 拡張機能です。これは、「DHCP Extension」の短縮形です。

C/C++ API

C/C++ API の entry init-entry ルーチンの両方に対するルーチン シグニチャは次のとおりです。

typedef int (DEXAPI * DexEntryPointFunction)(
int iExtensionPoint,
dex_AttributeDictionary_t* pRequest,
dex_AttributeDictionary_t* pResponse,
dex_EnvironmentDictionary_t* pEnviron );
 

拡張ポイントの整数値は、3 つの構造へのポインタとともに、各ルーチンのパラメータの 1 つです。

C/C++ API は、共有ライブラリを Network Registrar DHCP サーバ ファイルにリンクしなくてもいいように特に構成されています。ルーチンへのエントリは、拡張機能を設定するときに設定します。要求、応答、環境のそれぞれのディクショナリで実行する操作に必要なコールバック情報は、3 つのディクショナリ パラメータから構成される構造であり、拡張ルーチンに渡されます。

DHCP サーバはすべてのバイナリ情報をネットワーク順に返しますが、これは必ずしも実行中のアーキテクチャに適した順序とは限りません。

C/C++ でのタイプの使用

C/C++ ルーチンには、たとえば getByType() のようなタイプを使用できるルーチンが数多くあります。これらは、パフォーマンスが重視される環境で使用するためのルーチンです。これらのルーチンを使用すると、拡張機能がたとえば init-entry ポイントでタイプへのポインタを一度取得すれば、その後は、文字列値の名前の代わりにそのポインタを使用して、C/C++ API のルーチンを呼び出せます。このようにタイプを使用すると、拡張機能の実行処理フローからハッシュ テーブル ルックアップを 1 つ削除できるので、あらゆる拡張機能のパフォーマンスが(少なくとも若干は)向上します。

C/C++ 拡張機能の構築

ディレクトリ /opt/nwreg2/examples/dhcp/dex(UNIX および Linux)および \Program Files\Network Registrar\examples\dhcp\dex(Windows)には、サンプルの C/C++ 拡張コードとともに、サンプル拡張機能を構築するための簡単なメイクファイルが用意されています。独自の拡張機能を構築するには、このファイルを変更する必要があります。これには、Microsoft Visual C++ V5.0、GNU C++、および SunPro C++ 用のセクションがあります。単にコメント行を移動し、環境に合せてファイルを設定します。

拡張機能は、インクルード ファイル dex.h を参照する必要があります。このファイルには、作成したプログラムが C/C++ API を使用するために必要な情報が含まれています。Windows で C/C++ 拡張機能を構築する場合は、必ずエントリ ポイントを .def ファイルに追加します。

.dll(Windows)または .so(UNIX)ファイルは、構築した後(すべての dex 拡張機能が共有ライブラリとなります)、/opt/nwreg2/extensions/dhcp/dex ディレクトリ(UNIX)または \Program Files\Network Registrar\extensions\dhcp\dex ディレクトリ(Windows)に移動する必要があります。その後、それらのファイルを設定します。

C/C++ でのスレッドセーフな拡張機能の使用

DHCP サーバはマルチスレッドなので、DHCP サーバ用に記述された C/C++ 拡張機能は、スレッドセーフである必要があります。これらの拡張機能は、同じエントリ ポイントで複数のスレッドから、また複数のプロセッサから同時に呼び出せる必要があります。Network Registrar の C/C++ 拡張機能を設計するには、マルチスレッド環境用にコードを記述した豊富な経験が必要です。


注意 すべての C/C++ 拡張機能は、スレッドセーフになっている必要があります。そうでないと、DHCP サーバが正しく動作せずに、診断がきわめて困難な形で障害が発生します。これらの拡張機能が使用するライブラリおよびライブラリ ルーチンも、スレッドセーフである必要があります。

オペレーティング システムによっては、使用される実行時機能が本当にスレッドセーフであることを確認する必要があります。各機能のマニュアルを確認してください。オペレーティング システムによっては、スレッドセーフの特別なバージョンが提供されることがあります(多くの場合、 functionname _r)。Windows は、マルチスレッド アプリケーション用に、スレッドセーフなライブラリを数バージョン用意しているので、通常このような問題はありません。

スレッドのいずれかが非スレッドセーフな呼び出しを行うと、セーフ バージョンまたはロック バージョンの呼び出しを行っている他のスレッドすべてに影響します。これによってメモリの破壊やサーバ障害が発生する可能性があります。

このような障害は、その原因が明らかになることがほとんどないので、診断がきわめて困難です。サーバ障害を発生させるには、サーバに非常に高い負荷をかけるか、マルチプロセッサ マシンで多くの処理を行う必要があります。場合によっては、数日間、実行を続ける必要があります。拡張機能の実装に問題があっても、重い負荷が長期間続いた後でなければ問題が発現しません。

ランタイム ライブラリやサードパーティ ライブラリによっては、検出できない非スレッドセーフ呼び出しを行っていることがあるので、どの外部ファイルとリンクされているかを実行可能ファイルで確認します(UNIX 上の nm )。

次のリストのいずれかの機能のシングルスレッド バージョンがスレッドによって呼び出された場合(_r サフィックスのないバージョンが、Solaris 上のスレッドによって呼び出された場合)は、それらを使用しないでください。これらのライブラリ ルーチンのスレッドセーフ バージョンへのインターフェイスは、オペレーティング システムによって異なる場合があります。

機能のスレッドセーフ バージョンは次のとおりです。

 

asctime_r

gethostbyname_r

getservbyport_r

ctermid_r

gethostent_r

getservent_r

ctime_r

getnetbyaddr_r

getspent_r

fgetgrent_r

getnetbyname_r

getspnam_r

fgetpwent_r

getnetent_r

gmtime_r

fgetspent_r

getprotobyname_r

lgamma_r

gamma_r

getprotobynumber_r

localtime_r

getgrid_r

getprotoent_r

nis_sperror_r

getgrnam_r

getpwent_r

rand_r

getlogin_r

getrpcbyname_r

readdir_r

getpwnam_r

getrpcbynumber_r

strtok_r

getpwuid_r

getrpcent_r

tmpnam_r

getgrent_r

getservbyname_r

ttyname_r

gethostbyaddr_r

C/C++ 拡張機能の設定

.dll ファイルや .so ファイルは、サーバの動作中はアクティブなので上書きしないでください。サーバ停止後は、.dll ファイルおよび .so ファイルを新しいバージョンで上書きできます。

C/C++ 拡張機能のデバッグ

C/C++ 共有ライブラリは、DHCP サーバと同じアドレス空間で動作し、DHCP サーバ内の情報へのポインタを受け取るので、C/C++ 拡張機能にバグがあると、DHCP サーバのメモリが簡単に破壊され、サーバの障害につながります。このため、C/C++ 拡張機能を記述してテストするときには慎重に行う必要があります。まず TCL 拡張機能を使用して拡張機能を作成する方法を試し、さらにパフォーマンスを向上させるために C/C++ の拡張機能を使用します。

C/C++ での DHCP サーバ メモリへのポインタ

C/C++ 拡張機能のインターフェイス ルーチンは、次の 2 つの形式でポインタを DHCP サーバに返します。

一連のバイトへの char* ポインタ

(dex.h で定義された)指定された長さの一連のバイトへのポインタを持つ abytes_t という構造へのポインタ

いずれの場合も、拡張機能がその拡張ポイントで実行されている間、DHCP サーバ メモリへのポインタが有効です。それらのポインタは、この要求を処理するシリーズ内の残りの拡張ポイントに対しても有効です。したがって、 post-packet-decode 拡張ポイントに返された abytes_t ポインタは、 post-send-packet 拡張ポイントでも有効です。

ポインタは、環境ディクショナリに保存された情報が有効である限り有効です。しかしこれには 1 つ例外があります。 getType という C/C++ ルーチンは、タイプを参照する abytes_t というポインタを返します。これらのポインタは、拡張機能の寿命を通じて有効です。通常、サーバは、このルーチンを init-entry 拡張ポイントで呼び出し、タイプを定義する abytes_t 構造へのポインタを共有ライブラリのスタティック データに保存します。 getType によって返される abytes_t 構造へのポインタは、初期化のための init-entry 呼び出しから非初期化のための呼び出しまで有効です。

C/C++ の Init-Entry エントリ ポイント

DHCP サーバは、各拡張機能を設定するときと、それを設定解除するときに 1 回ずつ init-entry 拡張ポイント(「init-entry」を参照)を呼び出します。dex.h ファイルは、設定呼び出しと設定解除呼び出しの拡張ポイントとして渡される 2 つの拡張ポイントとして、設定のための DEX_INITIALIZE と設定解除のための DEX_UNINITIALIZE を定義します。拡張ポイント データ項目の環境ディクショナリの値は、それぞれの呼び出しで initialize または uninitialize です。

initialize init-entry 拡張ポイントを呼び出すときに、環境ディクショナリ データ項目 persistent に値 true が含まれている場合、 uninitialize 呼び出しから戻る前であれば、いつでも環境ディクショナリ ポインタを保存し、使用できます。このように、バックグラウンド スレッドは、環境ディクショナリ ポインタを使用してサーバのログ ファイルにメッセージをロギングできます。同時に複数のスレッドがディクショナリへの呼び出しを行わないように、ディクショナリへのすべてのアクセスをインターロックする必要があります。保存済みのディクショナリ ポインタは、拡張機能が uninitialize 呼び出しから戻る時点まで使用できます。このように、バックグラウンド スレッドが終了時のメッセージをロギングできます。

拡張機能を使用した DHCP 要求処理

Network Registrar DHCP サーバには、独自の拡張機能を追加できる拡張ポイントがあります。それらの拡張ポイントには、処理フローのどこでそれらを使用するかを示すわかりやすい名前が付いています。

拡張ポイントは、DHCP クライアントからの入力要求の処理に関連付けられているので、DHCP サーバが要求を処理する方法を理解するのに役立ちます。DHCP サーバでの要求処理の各ステージ(DHCPv4 と DHCPv6 では若干異なります)を、 表29-1 に示します。

 

表29-1 拡張機能を使用したクライアント要求処理の各段階

クライアント要求処理の段階
使用される拡張ポイント

1. DHCP クライアントからパケットを受信します。

pre-packet-decode

2. パケットをデコードします。

post-packet-decode

3. クライアントクラスを判別します。

4. クライアントクラスを修正します。

post-class-lookup

5. すべてのクライアントクラスを処理し、クライアントをルックアップします。

pre-client-lookup
post-client-lookup

6. 要求から応答コンテナを構築します。

7. 要求の送信元である DHCPv4 ネットワークまたは DHCPv6 リンクを判別します。

8. DHCPv4 では、このクライアントにすでに関連付けられているリースを検索し、見つからない場合はクライアントに対して新しいリースを手配します。

9. このクライアントに関連付けられているすべての要求をシリアル化します(要求がシリアル化キューの先頭に到達すると処理が続行されます)。

10. DHCPv6 では、クライアント要求を処理し、必要に応じてリースを生成します。サーバは、各バインディングで使用可能なプレフィックスごとに、少なくとも 1 つの優先リースをクライアントに提供しようとします。クライアント要求に対しては、リースを複数回生成し、リース状態も複数回変更できますが、予約されたリースはその対象となりません。

generate-lease および lease-state-change
(DHCPv6 ではどちらも複数回の呼び出しが可能)

11. リースがこのクライアントで(まだ)受け入れ可能かを判別します(DHCPv6 では複数回行われることがあります)。

check-lease-acceptable

12. 必要に応じて DNS アップデート操作を開始します(DHCPv6 では複数回行われることがあります)。

13. すべてのデータを収集して、応答パケットに保存します。

14. 応答パケットでエンコードの準備を行います。

pre-packet-encode

15. クライアントに伝送できるように、応答パケットをエンコードします。

post-packet-encode

16. 必要に応じて、安定した記憶域をアップデートします。

17. パケットをクライアントに送信します。

post-send-packet

18. クライアントと要求のコンテキストをすべて解放します。

environment-destructor

これらの手順および拡張機能を使用するその他の機会については、次の項で説明します。拡張ポイントは、 太字 で示します。


pre-packet-decodepost-packet-encodegenerate-lease(DHCPv6 のみ)、environment-destructor の各拡張ポイントは Network Registrar 7.0 で導入されました。


DHCPv6 拡張機能のイネーブル化

デフォルトでは、拡張機能が DHCPv4 のみをサポートすることが前提となっています。DHCPv6 拡張機能を記述するには、以下を行う init-entry 拡張ポイントを実装する必要があります。

1. dhcp-support 環境データ項目を v4 (DHCPv4 専用、プリセット値)、 v6 (DHCPv6 専用)、または v4,v6 (DHCPv4 および DHCPv6 用)に設定する。このデータ項目によって、拡張機能のサポート対象がサーバに通知されます。

2. extension-extension-api-version 環境データ項目を 2 に設定する( extension-extension-api-version 2 に設定されていないと、 dhcp-support データ項目は無視されます)。

DHCPv4 と DHCPv6 は、パケット形式、DHCP プロトコル、および内部サーバ データが異なるため、多くの場合、別々に拡張機能を記述する必要があります。ただし、どちらの拡張機能も基本的な部分はほとんど同じです。サーバが処理中に拡張ポイントを呼び出す場所も基本的に同じですが、DHCPv6 の一部の拡張ポイントは、クライアントごとのリース要求が複数回になる可能性があるために、サーバから複数回呼び出されることがあります。

パケットの受信

DHCP サーバは、DHCPv4 パケットをポート 67、DHCPv6 パケットをポート 547(DHCP 入力ポート)でそれぞれ受信し、処理のためにキューに追加します。またできるだけすばやく UDP 入力キューを空にするように努めます。受信したすべての要求は内部リストに保存され、それらを処理する空きスレッドができるとすぐに処理されます。これらのキューの長さは設定可能ですが、あらかじめ設定されている長さを超えることはできません。

パケットのデコード

空きスレッドができると、DHCP サーバはそれに入力要求の処理というタスクを割り振ります。DHCP サーバが取る最初のアクションは、入力パケットをデコードして、それが有効な DHCP クライアント パケットであるかを判別することです。このデコード プロセスの一部として、DHCP サーバはすべてのオプションをチェックして、それらが有効であるかどうか、つまり、これらのオプションの長さが要求パケットの全体の文脈から判断して意味があるかを確認します。また DHCP 要求パケットのすべてのデータをチェックしますが、この段階ではパケット内のデータに対しては何のアクションも行いません。

pre-packet-decode 拡張ポイントを使用して入力パケットをリライトします。DHCP サーバはこの拡張ポイントを渡した後、パケットのすべての情報を複数の内部データ構造に保存して、後続の処理を効率化します。

クライアントクラスの判別

client-class-lookup-id 内に式を設定した場合は、この段階で、DHCP サーバがその式を評価します(式の説明については、 第25章「式の使用方法」 を参照)。式の結果は、<null> となるか、それ以外の場合は文字列に変換されます。文字列の値は、クライアントクラス名か <none> です。<none> の場合、サーバは、 client-class-lookup-id が設定されていない場合と同じように、パケットの処理を続けます。<null> 応答または client-class-lookup-id を評価するエラーの場合、サーバはエラー メッセージをロギングし、パケットをドロップします( post-class-lookup 拡張ポイントに設定された拡張機能が、サーバがパケットをドロップしないように特に設定されている場合を除く)。クライアントクラスを設定するプロセスの一環として、DHCP サーバはそのクライアントクラスに対して設定されている limitation-id をすべて評価し、要求とともに格納します。

クライアントクラスの変更

DHCP サーバは、 client-class-lookup-id を評価し、クライアントクラスを設定した後に、
post-class-lookup 拡張ポイントに追加されている拡張機能を呼び出します。その拡張機能を使用すると、 limitation-id を含め、クライアントクラスによって要求に関連付けられたすべてのデータを変更できます。拡張機能は、 client-class-lookup-id の評価の結果、パケットがドロップされたかどうかについての情報も取得します。拡張機能は、パケットのドロップが必要かどうかを確認するだけでなく、必要に応じて、パケットをドロップしないようにサーバに指示します。

また、 post-class-lookup 拡張ポイントで実行される拡張機能は、要求に対して新しいクライアントクラスを設定でき、そのクライアントクラスのデータを、現在のクライアントクラスのデータの代わりに使用します。これは、クライアントクラスを設定することで実際にそのクライアントクラスが要求に使用される唯一の拡張ポイントです。

クライアントクラスの処理

クライアントクラスの処理をイネーブルにした場合、DHCP サーバがこの段階でそれを実行します。

pre-client-lookup 拡張ポイントは、ルックアップを阻止したり、既存のデータを上書きするデータを提供したりすることで、ルックアップ対象のクライアントに影響を与えるために使用します。DHCP サーバは、 pre-client-lookup 拡張ポイントを渡した後に、ローカル データベースまたは LDAP データベースが設定されている場合は、(拡張機能が特にそれを禁止していない限り)そのデータベースでクライアントをルックアップします。

サーバはクライアントをルックアップした後、クライアント エントリのデータを使用して追加の内部データ構造に入力します。DHCP サーバは、指定されたクライアントクラス エントリ内のデータを使用して、クライアント エントリで指定されていない情報を補完します。DHCP サーバは、内部データ構造内のさまざまな場所に格納されているデータを他の処理で使用できるようにすべて取得し、次の拡張ポイントを実行します。

post-client-lookup 拡張ポイントを使用して、クライアントクラス処理から入力された内部サーバ データ構造を調べるなど、クライアントクラスのルックアップ プロセスの処理を調べます。DHCP サーバが追加の処理を行う前にデータを変更する場合にも、この拡張ポイントを使用できます。

応答コンテナの構築

この段階では、DHCP サーバが要求タイプを判別し、適切な応答コンテナを構築します。たとえば、要求が DHCPDISCOVER の場合、サーバは処理を実行するために DHCPOFFER 応答を作成します。入力要求が BOOTP 要求の場合、サーバは応答処理を実行するために BOOTP 応答を作成します。

DHCPv6 の場合は、サーバが要求に応じて ADVERTISE パケットまたは REPLY パケットを作成します。

ネットワークとリンクの判別

DHCP サーバは、すべての要求について送信元のサブネットを判別し、それを IP アドレスを含んでいるアドレス プールのセット、スコープ、またはリンクにマップする必要があります。

DHCPv4 の場合、DHCP サーバ内部とはネットワークの概念であり、この文脈では LAN セグメントまたは物理ネットワークを指します。DHCP サーバでは、すべてのスコープが 1 つのネットワークに属します。ネットワーク番号が同一であるという理由で、同じネットワークにグループ化されるスコープもあります。また、プライマリスコープ ポインタによって関連しているという理由でグループ化されるスコープもあります。

Network Registrar DHCP サーバは、DHCP クライアントの処理に使用するネットワークを次の方法で判別します。

送信元アドレスによって判別します。 giaddr 、または giaddr が 0 の場合は、要求が到着したインターフェイスのアドレスを使用します。

このアドレスを使用して、スコープの中から、このアドレスと同じサブネット上のサーバ内に設定されているスコープを検索します。サーバがスコープを見つけなかった場合は、要求がドロップされます。

スコープを見つけた後、それ以降の処理にそのネットワークを使用します。

DHCPv6 の処理については、「リンクとプレフィックスの判定」を参照してください。

リースの検索

DHCPv4 の場合、DHCP サーバは、ネットワークを確立した時点で、ネットワーク レベルで保持されているハッシュ テーブルを検索して、 client-id がこのネットワークで既知であるかどうかを調べます。この文脈で「既知」とは、このクライアントが以前にこのネットワークで提供またはリースを受けており、かつそれ以降そのリースが別のクライアントに提供またはリースされていないことを意味します。したがって、現在のリースまたは期限が終了して使用可能となったリースが、ネットワーク レベルのハッシュ テーブルに表示されます。DHCP サーバはリースを見つけると、次の手順、つまり、同じ IP アドレスへのすべての要求のシリアル化に進みます。

DHCP サーバがリースを見つけられず、これが BOOTP 要求または DHCPDISCOVER 要求の場合、ネットワーク内のスコープで予約済みのリースを検索します。予約済みのリースが見つかると、サーバはそのスコープとリースがともに受け入れ可能かをチェックします。予約済みのリースとそれを含むスコープは、次の要件を満たす必要があります。

リースが利用可能であること(他の DHCP クライアントにリースされていないこと)

スコープが要求タイプ(BOOTP または DHCP)をサポートしていること

スコープが非アクティブ状態でないこと

リースが非アクティブ状態でないこと

scope-selection タグに、クライアントのすべての selection-criteria が含まれ、クライアントの selection-criteria-excluded が含まれていないこと

スコープが更新専用状態でないこと

予約済みリースが受け入れ可能であれば、DHCP サーバは次の手順、つまり、その IP アドレスへのすべての要求のシリアル化に進みます。このクライアントの既存のリースまたは予約済みリースが見つからなかった場合、サーバは次にこのクライアントで使用可能なすべての IP アドレスを検索します。

DHCP サーバが採用する一般的なプロセスとしては、このネットワークに関連付けられたすべてのスコープをラウンドロビン順にスキャンし、このクライアントで受け入れ可能であるとともに、使用可能なアドレスを持つスコープを探します。受け入れ可能なスコープには、次の特徴があります。

クライアントに selection-criteria が関連付けられている場合は、scope-selection タグにクライアントのすべての包含基準が含まれている。

クライアントに selection-criteria-excluded が関連付けられている場合は、scope-selection タグにクライアントの除外基準が含まれていない。

スコープがクライアントの要求タイプをサポートしている。クライアントの要求が DHCPREQUEST の場合は、DHCP に対してスコープをイネーブルにする必要があります。同様に、要求が BOOTP 要求の場合は、BOOTP とダイナミック BOOTP に対してスコープをイネーブルにする必要があります。

更新専用状態でない。

非アクティブ状態でない。

使用可能なアドレスがある。

受け入れ可能なスコープが見つからない場合、サーバはメッセージをロギングしてパケットをドロップします。

DHCPv6 の処理については、「リンクとプレフィックスの判定」を参照してください。

リース要求のシリアル化

1 つのクライアントとリースについて複数の DHCP 要求を同時に処理できるので、DHCPv4 要求をリースのレベルでシリアル化する必要があります。サーバは、それらの要求をリースに対するキューに追加し、追加した順に処理します。

DHCPv6 の場合、サーバはリース上ではなくクライアント上(リンク単位)でシリアル化を行います。

リースの受け入れ可能性の判別

DHCPv4 の場合、DHCP サーバはここで、リースが(まだ)そのクライアントで受け入れ可能かを判別します。初めてのクライアントが新しく取得したリースの場合は、受け入れ可能になります。しかし、サーバが既存のリースの更新を処理する場合は、サーバがリースを許可した後に受け入れ可能性の基準が変更されていることがあるので、その受入可能性を再度チェックする必要があります。

クライアントが現在のリースと異なる予約を持つ場合、サーバはまず予約済みのリースが受け入れ可能かを判別します。リースの受け入れ可能性についての基準は次のとおりです。

予約済みのリースが使用可能なこと

予約済みのリースが非アクティブ状態でないこと

スコープが非アクティブ状態でないこと

要求が BOOTP の場合は、スコープが BOOTP をサポートしていること

また、要求が DHCP の場合は、スコープが DHCP をサポートしていること

クライアントに selection-criteria がある場合は、scope-selection タグにクライアントのすべての包含基準が含まれていること

クライアントに selection-criteria-excluded がある場合は、scope-selection タグにクライアントのすべての除外基準が含まれていないこと

以前このリースに関連付けられていたクライアントが現在のクライアントと異なる場合は、スコープが更新専用状態であること

予約されたリースがこれらの基準すべてを満たす場合、DHCP サーバは現在のリースが受け入れ不能だと判断します。このクライアントについて予約されたリースが存在しない場合、または予約されたリースが受け入れ可能性の基準を満たさない場合、DHCP サーバは、現在のリースの受け入れ可能性を調べます。

受け入れ可能性の基準は次のとおりです。

リースが非アクティブ状態でないこと

スコープが非アクティブ状態でないこと

要求が BOOTP の場合は、スコープが BOOTP をサポートしていること。また、要求が DHCP の場合は、スコープが DHCP をサポートしていること

このリースについての予約がクライアントに存在せず、要求が BOOTP の場合は、スコープがダイナミック BOOTP をサポートしていること

このリースの予約がクライアントに存在しない場合、他のクライアントも予約できないこと

クライアントに selection-criteria がある場合は、scope-selection タグにクライアントのすべての包含基準が含まれていること

クライアントに selection-criteria-excluded がある場合は、scope-selection タグにクライアントのすべての除外基準が含まれていないこと

以前このリースに関連付けられていたクライアントが現在のクライアントと異なる場合は、スコープが更新専用状態であること


ヒント DHCP サーバ処理のこの時点で、check-lease-acceptable 拡張ポイントを使用できます。この拡張ポイントを使用すると、受け入れテストの結果を変更できます。これは、非常に注意して行ってください。


リースを受け入れ不能と判別した場合、DHCP サーバは、現在処理中の具体的な DHCP 要求に応じて異なるアクションを行います。

DHCPDISCOVER :DHCP サーバは、現在のリースを解放し、このクライアント用に別の受け入れ可能なリースの取得を試みます。

DHCPREQUEST SELECTING :リースが無効なので、DHCP サーバは DHCP クライアントに NACK を送信します。これを受けてクライアントは、すぐに DISCOVER 要求を発行して新しい DHCPOFFER を取得します。

DHCPRENEW DHCPREBIND :DHCP サーバは DHCP クライアントに NACK を送信して、DHCP クライアントを INIT フェーズにします(DHCP クライアントが DHCPDISCOVER 要求を発行するようにします)。このリースは、クライアントが実際に要求を発行するまで有効です。

BOOTP :DHCP サーバは、現在のリースを解放し、このクライアント用に別の受け入れ可能なリースの取得を試みます。


注意 check-lease-acceptable 拡張ポイントを使用する場合は、十分に注意して行ってください。拡張ポイントから返された回答が、DHCPDISCOVER 要求またはダイナミック BOOTP 要求で実行された使用可能なリースの検索での受け入れ可能性チェックの結果と一致しないと、(すぐに、または次の DHCPDISCOVER 要求または BOOTP 要求で)無限サーバ ループが発生する可能性があります。この場合、サーバは使用可能なリースを新しく取得し、それが受け入れ不能だと判別し、さらに使用可能なリースを新しく取得し、それが受け入れ不能だと判別するというループにずっと入ったままになります。

DHCPv6 リース処理

DHCP サーバは、クライアント要求の IA_NA、IA_TA、IA_PD の各オプションをスキャンすることで、IPv6 リース要求を処理します(「DHCPv6 のバインディング」を参照)。これらのオプションごとに、サーバはクライアントが明示的に要求しているリースを検討します。クライアントとバインディングにリースがすでに存在する場合(IA オプションおよび IAID)、サーバはそのリースがまだ受け入れ可能かどうかを判別します。クライアントの要求するリースがすでにクライアントに存在しない場合、サーバは次の場合にそのリースをクライアントに与えようとします。

別のクライアントまたはバインディングが、すでにそのリースを使用していない。

リースのプレフィックスの allocation-algorithms アトリビュートに client-request フラグが設定されている。

リースが使用可能であり、使用可能なプレフィックスにある(「DHCPv6 プレフィックスの使用可能性」を参照)。

次にサーバは、クライアントが予約を使用していること、およびリンク上の使用可能な各プレフィックスに対してゼロ以外の推奨期間を持つ、使用可能なリースをクライアントが持つことを、保証しようとします。したがってサーバは、これらのバインディングをそれぞれ次のように処理します。

1. プレフィックスの allocation-algorithms アトリビュートで予約フラグが設定されている場合に、クライアント予約(未使用)をバインディングに追加します。サーバは、予約に対して適切なタイプの最初のバインディングを使用します。つまり、IA_NA バインディングにはアドレス リースを使用し、IA_PD バインディングにはプレフィックス リースを使用します。

2. クライアントが使用できる各プレフィックスに対して、ゼロ以外の推奨期間を持つリースをクライアントが持っていない場合、サーバはクライアントにリースを割り振ります。サーバがどのようにリースを割り振るかは、プレフィックスの allocation-algorithms フラグによって制御されます。

DHCPv6 プレフィックスの使用可能性

使用可能なプレフィックスの条件は次のとおりです。

非アクティブでないこと。

期限が切れていないこと。

バインディング タイプのリースが可能であること。

クライアント選択基準(設定されている場合)に適合していること。

クライアント選択除外基準(設定されている場合)に適合していないこと。

DHCPv6 リースの使用可能性

使用可能なリースの条件は次のとおりです。

使用不可になっていないこと。

無効になっていないこと。

非アクティブでないこと。

別のクライアントに予約されていないこと。

inhibit-all-renews または inhibit-renews-at-reboot が適用されないこと。

更新中に更新可能であること(IA_TA リースは更新不可能)。

ゼロ以外の有効期間でリース可能であること。

DHCPv6 リースの割り振り

サーバは、プレフィックスで新しいリースを割り振る必要がある場合に、 allocation-algorithms アトリビュートでプレフィックス拡張フラグが設定されていると、 generate-lease 拡張ポイントで登録済みの拡張機能を呼び出します(「generate-lease」を参照)。拡張機能では、割り当てるアドレス(IA_NA または IA_TA バインディング)またはプレフィックス(IA_PD バインディング)を提供するか、通常の割り振りアルゴリズムを使用するようにサーバに要求するか( allocation-algorithms でイネーブルになっている場合)、またはこのプレフィックスでのリースの割り当てをスキップするようにサーバに要求することができます。提供されたアドレスまたはプレフィックスが、無効であるか、すでに使用されている場合は、サーバがその拡張機能を再度呼び出すことがあります。

拡張機能を使用できないか、拡張機能が登録されていないか、または拡張機能がサーバの通常の割り振りアルゴリズムを要求した場合、サーバはランダムに生成されたアドレスを割り振るか、または最初の最適なプレフィックスを検索して(プレフィックスの allocation-algorithms アトリビュートで制御)、リースを作成します。

サーバは、リースを取得してその受け入れ可能性チェックを実行すると(「DHCPv6 リースの使用可能性」を参照)、 check-lease-acceptable 拡張ポイントに登録されている拡張機能を呼び出して、拡張機能がリースの受け入れ可能性を変更できるようにします(「check-lease-acceptable」を参照)。この拡張ポイントは通常、受け入れ可能から受け入れ不可能へと結果を変更するためだけに使用しますが、サーバでは受け入れ不可能から受け入れ可能へと結果を変更できます。ただし、悪影響が生じる可能性があるため、この操作は行わないよう強く推奨します。リースが受け入れ可能でない場合、サーバは別のリースを割り振ろうとするため、無限ループにならないよう注意してください。場合によっては、クライアントが取得するリースを完全に制御するために check-lease-acceptable 拡張ポイントおよび generate-lease 拡張ポイントが必要となります。 generate-lease では、リースの割り振りをスキップするようにサーバに要求できます。

サーバは、各リースに対するクライアント要求ごとに、 check-lease-acceptable 拡張ポイントを呼び出します。

応答パケット データの収集

この段階の処理で、DHCP サーバは、DHCP 応答によって送信するすべてのデータを収集するとともに、応答の送信先アドレスとポートを判別します。 pre-packet-encode 拡張ポイントを使用して、応答として DHCP クライアントに送信されるデータを変更するか、または DHCP 応答の送信先となるアドレスを変更します(「pre-packet-encode」を参照)。


注意 pre-packet-encode 拡張ポイントでドロップしたパケットについては、DHCP パケットでも BOOTP パケットでも、リース時間が残っている限り、リースされるアドレスが Network Registrar リース状態データベースに表示されます。このため、もっと早い時点でパケットをドロップすることをお勧めします。

応答パケットのエンコード

この段階で、DHCP は応答データ構造内の情報をネットワーク パケットにエンコードします。この DHCP クライアントで DNS アクティビティが必要な場合、DHCP サーバが、DNS 作業要求を DHCP サーバにある DNS 処理サブシステムのキューに追加します。その要求は可能であればいつでも実行されますが、一般に、パケットをクライアントに送信するまで実行されません(「DNS 要求の処理」を参照)。

安定した記憶域の更新

この段階で、DHCP サーバは、処理を行う前に、IP アドレスに関してディスク上にある情報が最新であることを確認します。DHCPv6 では、この処理に複数のリースが関係する場合があります。

パケットの送信

post-send-packet 拡張ポイント(「post-send-packet」を参照)は、DHCP 要求応答サイクルの厳しい時間制約外で実行する処理のために使用します。サーバは、パケットをクライアントに送信した後に、この拡張ポイントを呼び出します。

DNS 要求の処理

ここでは、DNS に名前を追加するために DHCP サーバが行う処理を簡単に説明します。

1. A レコードに使用する名前を構築する :DHCP サーバは、転送(A レコード)DNS 要求で使用する名前を作成します。DHCPv6 では、これが AAAA レコードとなります。DNS 名は、DHCP 要求のオプション値から得られるか、またはサーバが合成します(合成がイネーブルになっている場合)。拡張機能を使用すると、要求パケット内のデータから名前を構築するために、オプション値を挿入または修正できます。

2. 名前がまだ存在しないことをアサートして名前の追加を試みる :この段階では、DNS 名アップデート要求の前提条件として、名前が存在しないことが必要です。これに成功すると、DHCP サーバは逆レコードのアップデートに進みます。

3. 名前が DHCP サーバによって供給されることをアサートして名前の追加を試みる :DHCP サーバは、ホストが存在し、すでに送信されたレコードと同じ TXT レコードを持っていることをアサートして、そのホスト名の追加を試みます。これに成功すると、サーバは次のタスクとして、逆レコードのアップデートに進みます。失敗した場合、サーバはその命名のリトライ回数を使い切ってしまったかをチェックします。リトライ回数に残りがない場合、終了してエラーがロギングされます。残りがある場合は、最初の手順である A レコードの名前の構築に戻ります。

DHCPv6 では、サーバが TXT レコードの代わりに DHCID レコードを使用します。また、DHCPv6 クライアントは複数のリースを持つことができ、順ゾーンは同じでも、異なっていてもかまいません。

4. 逆レコードをアップデートする :これで DHCP サーバは、どの名前に逆(PTR)レコードを関連付けるかがわかり、それがレコードの所有者だと想定できるので、前提条件なしに逆レコードをアップデートできます。アップデートができない場合は、DHCP サーバがエラーをロギングします。

リース状態の変化のトレース

サーバは、リースの状態が変化するたびに(およびこのタイミングでのみ) lease-state-change 拡張ポイントを呼び出します。既存の状態は、応答ディクショナリの lease-state データ項目にあります。新しい状態は、環境ディクショナリの new-state にあります。 new-state が既存の状態と同じになることはありません(同じ場合、サーバは拡張機能を呼び出しません)。この拡張機能は読み取り専用と見なす必要があります。また、ディクショナリ項目はサーバがさまざまな場所で呼び出すため、ディクショナリ項目には変更を加えないでください。この拡張ポイントは、リースの状態の変化をトレースするためだけに使用します。

拡張ディクショナリ

拡張機能はすべて、3 つの引数を持つルーチンです。これらの引数とは、要求ディクショナリ、応答ディクショナリ、環境ディクショナリです。すべての拡張機能ですべてのディクショナリが使用できるわけではありません。拡張ポイントとそれらで使用できるディクショナリを 表29-2 に示します。

 

表29-2 拡張ポイントと関連ディクショナリ

拡張ポイント
ディクショナリ

init-entry

環境

pre-packet-decode

要求、環境

post-packet-decode

要求、環境

pre-client-lookup

要求、環境

post-client-lookup

要求、環境

post-class-lookup

要求、環境

generate-lease

要求、応答、環境

lease-state-change

応答、環境

check-lease-acceptable

要求、応答、環境

pre-packet-encode

要求、応答、環境

post-packet-encode

要求、応答、環境

post-send-packet

要求、応答、環境

environment-destructor

環境


) サーバは、DHCPv6 Reconfigure メッセージを送信するときに、pre-packet-encode
post-packet-encode、および post-send-packet の各拡張ポイントを要求なしに呼び出すことができます。


要求ディクショナリと応答ディクショナリについては、 isValid メソッドを使用して、ディクショナリが拡張ポイントで使用可能かどうかをプローブできます。

これら 3 つのディクショナリは、名前と値のペアで構成されます。環境ディクショナリは、すべての拡張ポイントで使用できる最も単純なディクショナリです。要求ディクショナリと応答ディクショナリはそれよりも複雑で、データはタイプ分けされています。そのため、これらのディクショナリのいずれかに値を設定するときは、データ タイプを値に合せる必要があります。ディクショナリは、値の取得、追加、および削除に使用します。

環境ディクショナリ

環境ディクショナリは、すべての拡張ポイントで使用できます。これは、名前と値のペアのセットで厳格に構成され、名前と値はともに文字列です。

DHCP サーバは環境ディクショナリを使用して、異なる拡張ポイントで異なる方法を使用して拡張機能と通信できます。拡張ポイントによっては、サーバが情報を環境ディクショナリに保存し、拡張機能がそれを変更する場合があります。また、拡張機能が環境ディクショナリに値を保存し、拡張機能が処理を終了した後、フローやデータを制御する場合もあります。

環境ディクショナリは、拡張機能によって任意の名前と値のペアを追加できる点が特徴です。ドキュメント化されていない名前と値のペアを使用してもエラーは発生しませんが、サーバがそれらを認識できません。この名前と値のペアは、拡張ポイント間のデータ通信に役立ちます。

DHCP サーバは、DHCP 要求が到着したときに環境ディクショナリを作成し、ディクショナリは処理の間その要求とともに残ります。したがって、 post-packet-decode 拡張ポイントで実行される拡張機能がデータを環境ディクショナリに追加でき、 pre-packet-encode 拡張ポイントで実行される拡張機能がそのデータをこのディクショナリから読み取ることができます。


init-entry 拡張ポイントには、独自の環境ディクショナリがあります。


環境ディクショナリのデータ項目

表29-3 のデータ項目は、環境ディクショナリで有効です。

 

表29-3 環境ディクショナリのデータ項目

データ項目
説明

attempts
(読み取り専用)

generate-lease 拡張ポイント専用。サーバが 1 つのリースに対してこの拡張機能を呼び出す回数です。

default-prefix-length
(読み取り専用)

generate-lease 拡張ポイント専用。デフォルトのプレフィックス長(ポリシーから取得)に設定されます(Expert モードの longest-
prefix-length
データ項目と shortest-prefix-length データ項目が設定されていない場合のデフォルトは default-prefix-length です)。

dhcp-support
(読み取り/書き込み)

init-entry 拡張ポイント専用。この拡張機能のためにサーバが登録済み拡張ポイントを呼び出す必要のある、DHCP のバージョンです。 v4 v6 、または v4,v6 に設定できます。

drop
(読み取り/書き込み)

拡張機能の終了時に、 drop の値が文字列 true に等しい場合、DHCP サーバは入力パケットをドロップし、メッセージをログ ファイルにロギングします。ほとんどの拡張ポイントで使用できますが、使用できないものもあります(たとえば generate-lease )。

extension-extensionapi-version
(書き込み専用)

init-entry 拡張ポイント専用。拡張機能に必要な拡張 API の最小バージョンです。Network Registrar リリース 7.0 で導入された API 機能を拡張機能が使用する場合は 2 に設定し、それ以前のリリースの機能を使用する場合は 1 に設定します。

extension-name
(読み取り専用)

拡張機能の設定に使用した名前。コードの同じ部分を、複数の異なる拡張機能として、複数の異なる拡張ポイントに設定できます。この設定により、同じコードをその設定方法に応じて異なる目的に使用できます。コードはまた、この文字列を使用して extension-name-sequence 文字列の中でそれ自体の名前を検索できます。これにはそれ自体の名前を知る必要があります。

extension-name-sequence
(読み取り専用)

この拡張ポイントの設定を表すカンマで区切られた文字列を提供します。これにより、ある拡張機能の前後にどの拡張機能を実行可能かを判別できます(現在実行中の拡張機能は extension-name データ項目に示されます)。たとえば、 tclfirst を最初の拡張機能として設定し、 dexscript を 5 番目の拡張機能として設定すると、 extension-name-sequence の値は "tclfirst,,,,dexscript" となります。

extension-point
(読み取り専用)

拡張ポイントの名前。たとえば、 post-packet-decode などです。

extension-sequence
(読み取り専用)

この拡張ポイントでの、この拡張機能のシーケンス番号となる文字列。

generated-address
(書き込み専用)

generate-lease 拡張ポイント専用。拡張機能がサーバに対して、リースに使用するように求めるアドレスです。

generated-prefix
(書き込み専用)

generate-lease 拡張ポイント専用。拡張機能がサーバに対して、リースに使用するように求める DHCPv6 の委任プレフィックスです。

log-drop-message
(読み取り/書き込み)

拡張機能の終了時に、 drop の値が文字列 true に等しく、
llog-drop-message
の値が文字列 false に等しい場合、DHCP サーバは入力パケットをドロップしますが、メッセージをログ ファイルにロギングしません。要求ディクショナリを持つすべての拡張ポイントでは、 log verbose-logging で始まるデータ項目をいつでも設定できます。DHCP サーバは必要に応じてそれらを読み取ります。

prefix-length
(書き込み専用)

generate-lease 拡張ポイント専用。要求されたプレフィックス長、またはデフォルトのプレフィックス長に設定します。

server-dhcp-support
(読み取り専用)

init-entry 拡張ポイント専用。このデータ項目は、サーバで設定済みのサポート対象を示すために、サーバが設定します。DHCP サーバの dhcp-support アトリビュートの設定(expert アトリビュートが visibility=3 に設定されている必要があります)およびプレフィックスが設定されているかどうかに応じて、 v4 v6 、または v4,v6 に設定されます。

dhcp-support = both で、かつプレフィックスが設定されていない場合、 server-dhcp-support v4 に設定されます。

dhcp-support = both で、かつ 1 つ以上のプレフィックスが設定されている場合、 server-dhcp-support v4,v6 に設定されます。

dhcp-support = v4 の場合、 server-dhcp-support v4 に設定されます。

dhcp-support = v6 で、かつ 1 つ以上のプレフィックスが設定されている場合、 server-dhcp-support v6 に設定されます。

server-extensionapi-version
(読み取り専用)

init-entry 拡張ポイント専用。サーバの拡張 API のバージョンです。Network Registrar Release 7.0 以降の場合は 2 、それ以前のリリースの場合は 1 に設定されます。

skip-lease
(書き込み専用)

generate-lease 拡張ポイント専用。拡張機能がサーバによるリースの生成を必要としない場合は、TRUE に設定します。

trace-level
(書き込み専用)

これに数値を設定すると、この要求を処理するすべての拡張機能について、その数値が extension-trace-level サーバ アトリビュートの現在の設定になります。

user-defined-data
(読み取り/書き込み)

要求が処理される前にリースとともに格納されたリースの user-defined-data アトリビュートで設定されます。
pre-packet-encode の「前」にディスクに書き込むことができます。ヌルに設定された場合、サーバはリースからの user-defined-data を無視します。このデータ項目は、すべての要求について書き込むことができるわけではありません(特に pre-packet-encode 拡張ポイントと post-packet-encode 拡張ポイントの場合)。

初期環境ディクショナリ

init-args init-entry を使用して拡張機能を設定できます。その代わりに、拡張機能の設定情報を指定して、環境ディクショナリから読み取ることもできます。DHCP プロパティ initial-environment-
dictionary
は、一連のアトリビュートと値のペアを使用して設定でき、各ペアはすべての環境ディクショナリで使用できます。この機能を使用すると、さまざまな設定やカスタマイズした情報が指定できます。あらゆる拡張機能が環境ディクショナリから直接簡単に読み取れ、 init-args init-entry を使用したアプローチと違って、スタティック データ領域に保存する必要がありません。

initial-environment-dictionary のアプローチを使用して定義した値は、あらゆる環境ディクショナリから読み取れます。また、 initial-environment-dictionary に表示される任意のアトリビュートに対して、新しい値を定義することもできます。これらの新しい値は、環境ディクショナリの寿命を通じて(通常、要求パケットが処理されている寿命の間)使用可能です。ただし、これによって他の環境ディクショナリの内容が変更されるわけではありません。新しい環境ディクショナリ(異なる要求と関連付けられている)は、DHCP サーバの initial-environment-dictionary プロパティによって定義されるアトリビュートと値のペアを参照します。

加えて、 initial-environment-dictionary で定義されたこれらのアトリビュートと値のペアは、環境ディクショナリの値列挙に表示されません。これらのペアを使用できるのは、環境ディクショナリに現在定義されていないアトリビュート値を要求した場合のみです。アトリビュートと値のペアは、環境ディクショナリに実際に表示されません。したがって、アトリビュートのいずれかに対して新しい値を定義すると、新しい値が環境ディクショナリに表示されます。後にその値を削除し、そのアトリビュート値を要求すると、元の値が提供されます。

要求ディクショナリと応答ディクショナリ

要求ディクショナリと応答ディクショナリには、規定のセットのアクセス可能な名前があります。ただし、すべての名前にすべての拡張ポイントからアクセスできるわけではありません。これらのディクショナリによって、拡張機能が、内部サーバ データ構造に読み取りと書き込みアクセスまたは場合によっては読み取り専用アクセスできます。それぞれのデータ項目には特定のデータ タイプがあります。put 操作で正しいデータ タイプを省略した場合(C/C++ 拡張機能)、または DHCP サーバがそれを正しいデータ タイプに変換できない場合(TCL 拡張機能)は、拡張機能が失敗します。

要求ディクショナリは、要求を処理し始めるときに使用できます。サーバが応答を作成すると、要求ディクショナリと応答ディクショナリが使用可能になります。応答ディクショナリが使用可能になる前にアクセスするのは誤りです。

一般に、サーバのデータは拡張機能を使用して変更できません。場合によっては、設定済みのデータを拡張機能を使用して変更できますが、その変更はその 1 つの要求の処理の間だけ有効です。

デコード済みの DHCP パケット データ項目

DHCP プロトコルは、UDP ベースの要求と応答のプロトコルであり、DHCP サーバ操作を開始するのは、通常、クライアントからの DHCP 要求です。また結果は通常、そのクライアントに返信される DHCP 応答です。

DHCP 拡張機能によって、ほとんどの拡張ポイントにある拡張機能が、DHCP 要求に入力された情報を使用できるようになり、 pre-packet-encode 拡張ポイントで使用可能な DHCP 要求に対する応答としてその情報を送信できるようになります(「pre-packet-encode」を参照)。

この DHCP パケットベースの情報に加え、DHCP 要求の処理時に DHCP サーバが使用する追加データがあります。このデータは、サーバのアーキテクチャの一部として、DHCP 要求または DHCP 応答のいずれかに関連付けられます。このデータの多くは、拡張機能でも使用できるようになり、その多くが読み取りと書き込みの両方が可能です。これは多くの場合、DHCP サーバの処理アルゴリズムを変更します。

したがって、要求ディクショナリと応答ディクショナリは、それぞれのディクショナリに 2 クラスのデータを含みます。含まれるのは、デコード済みのパケット データとその他の要求または応答に関連するデータ項目です。デコード済みのパケット データ項目とは、DHCP 要求または DHCP 応答に直接含まれる、またはそれから派生したデータ項目です。デコード済みパケット データ項目にアクセスすることで、DHCP 要求および DHCP 応答パケットの読み取りと、場合によってはリライトが可能です。図29-3は、要求ディクショナリと応答ディクショナリの関係を示しています。

図29-3 拡張機能の要求ディクショナリと応答ディクショナリ

 

情報には、要求ディクショナリのデコード済みのパケット データ項目を使用して、 giaddr ciaddr などの DHCP 要求パケットから、およびすべての着信 DHCP オプションからアクセスできます。同様に、応答ディクショナリのデコード済みのパケット データ項目にアクセスすることによって、 giaddr ciaddr を設定したり、発信 DHCP 応答で DHCP オプションを追加、削除したりできます。

デコード済みのパケット データ項目によって提供されるパケット情報すべてにアクセスできるわけではないことに注意してください。各拡張ポイントの説明には、その拡張ポイントで使用可能なデータ項目が一覧表示されています。デコード済みのパケット データ項目は常にグループとしてアクセス可能なので、それらはグループとして一覧表示されます。表B-2を参照してください。

DHCP オプションには名前によってアクセスします。オプションが存在しない場合、そのオプションに対してサーバからデータが返されません。デコード済みの要求またはデコード済みの応答にオプションを配置すると、既存のデータを残したままデータを追加するように put 操作で特に指定しない限り、デコード済みの要求またはデコード済みの応答内にすでに存在する同じ名前のオプションが、配置したオプションによって置き換えられます。

DHCP オプションの中には、複数の値を持つオプションもあります。たとえば、ルータ オプションに、1 つ以上の IP アドレスが関連付けられている場合があります。この複数の値へのアクセスは、オプション名に対するインデックス付きの操作で行います。


ヒント 要求または応答ディクショナリに clear 操作を行うと、デコード済みのパケットにあるすべてのオプションが削除されます。


パラメータ リスト オプションの使用

DHCP サーバが特に 2 つの方法で処理する dhcp-parameter-request-list というオプションがあり、次のいずれかとして使用可能です。

dhcp-parameter-request-list という名前の複数値を持つバイト オプション

dhcp-parameter-request-list-blob という名前の blob(バイトのシーケンス)オプション

このオプションは、いずれかの名前を使用して get または put できます。DHCP サーバでは、 dhcp-parameter-request-list (およびその -blob バージョン)の応答ディクショナリでの扱いが、要求ディクショナリでの扱いと異なります。要求ディクショナリでアクセスしたときのこのオプションは、要求ディクショナリの DHCP オプションの 1 つにすぎません。しかし応答ディクショナリでは、特別な処理が行われます。

応答ディクショナリで dhcp-parameter-request-list オプションを使用して、DHCP または BOOTP クライアントに返されるオプションの順序を制御できます。応答ディクショナリでオプションを put すると、オプションのリストに一覧表示されている既存のオプションを先頭としてリストに表示される順番になるように、DHCP サーバが既存のオプションを並べ替えます。次に、リストにあった最後のオプションの後に、残りのオプションが現在の順序で表示されます。DHCP サーバは、新しいリストで置き換えるまでこのリストを維持し、後でオプションを応答に put する場合に、このリストを使用してそのオプションの順序を決定します。

拡張機能は応答ディクショナリで dhcp-parameter-request-list に対して get 操作を行うときに、デコード済みの応答パケットを調べてオプションを見つけることはしません。その代わりに、DHCP サーバが、デコード済みの応答パケットに現在存在するすべてのオプションのリストを含むものを合成します。

拡張ポイントの説明

ここでは、拡張ポイントとそれらのアクション、およびデータ項目について説明します。すべての拡張ポイントについて、 extension-point を表示し、環境ディクショナリに trace-level データ項目の値を設定できます。ほとんどの拡張ポイントで、サーバがパケットをドロップするように指示することもできます。

init-entry

init-entry 拡張ポイントは、DHCP サーバが拡張機能を設定または設定解除するときに呼び出す追加の拡張ポイントです。この処理は、サーバを起動、停止、またはリロードするときに発生します。このエントリ ポイントは、拡張機能に対して他のエントリ ポイントと同じシグニチャを持ちますが、ユーザが使用するのは環境ディクショナリのみです。 init-entry 拡張ポイントの設定は、CLI で dhcp attachExtension コマンドを使用して行うのではなく、すでに設定済みの拡張機能で init-entry を定義することで暗黙的に行います。


) DHCPv6 の拡張ポイントをイネーブルにするには(または DHCPv4 の拡張ポイントをディセーブルにするには)、init-entry 拡張ポイントを指定する必要があります。


init-entry の設定には、エントリ ポイントの名前を使用する方法のほかに、 init-entry ポイントの呼び出し前に、DHCP サーバが環境ディクショナリの文字列 arguments の下にロードする引数の文字列を設定する方法もあります。 arguments を使用すると、初期化引数の値を変えることでカスタマイズした拡張機能を作成できるので、コードを変更せずに動作を変更することができます。

引数を設定するには、既存の拡張ポイント上に init-args を設定します。これらの引数は、 init-entry 拡張ポイントの設定呼び出しと設定解除呼び出しの両方に対して存在します。設定呼び出しの拡張ポイント名は initialize であり、設定解除呼び出しの拡張ポイント名は uninitialize です。


) サーバが init-entry 拡張ポイントで拡張機能を呼び出す順序は、リロードごと、または解放ごとに異なることがあります。



注意 初期化解除のために呼び出された拡張機能は、自ら作成したすべてのスレッドを終了し、クリーンアップしてから復帰する必要があります。拡張機能が復帰すると、DHCP サーバはメモリから拡張機能をアンロードします。このときに、拡張機能が作成したスレッドが実行中のままであると、サーバ障害が発生する可能性があります。

pre-packet-decode

pre-packet-decode に使用可能なディクショナリは、要求ディクショナリと環境ディクショナリです。

この拡張ポイントは、要求が到着したときに DHCP サーバが最初に検出する拡張ポイントです。サーバは、パケットを受信してから( post-packet-decode 拡張ポイントで)デコードするまでの間に、この拡張ポイントを呼び出します。拡張機能は、この拡張ポイントを使用してパケットを検査し、サーバがデコードする前にパケットを変更するか、またはサーバにパケットをドロップさせます。

要求ディクショナリには 2 つの新しいデータ項目があり、この拡張ポイントで使用できます。

client-packet :読み取り専用項目。 getBytes だけに対して有効です。サーバからは、パケットのクライアント部分のアドレスと長さが返されます。DHCPv4 では、パケット全体です。DHCPv6 では、クライアント メッセージです。

packet :読み取り/書き込み項目。 getBytes および putBytes だけに対して有効です。 getBytes では、パケット全体のアドレスと長さを返します。 putBytes では、既存のパケットを新しいデコード済みのパケットで置き換えます。DHCPv4 では、 packet client-packet と同じです。DHCPv6 で、 packet はリレーされる場合はフル パケットとなり、リレーされない場合は client-packet と同じです。

拡張機能は、パケットに書き込むことでパケットのバイト数を直接変更できます。ただし、 putBytes を使用してパケットの長さを調整する必要があります(パケットが大きすぎると操作が失敗することがあります)。DHCPv6 で、リレーされるパケットのクライアント部分の長さを調整する場合は、パケットの Relay Message オプションで長さをアップデートする必要があります。

パケットを解析して必要な情報を探し、パケットを正しく変更することは、拡張機能が行います(それが必要な場合)。

サーバは受信済みパケットをまだデコードしていないため、要求ディクショナリのデータ項目はほとんど使用できません(通常は、サーバが受信済みパケットから入力するからです)。したがって、この拡張ポイントではパケットから直接データを抽出する必要があります。また、誤った形式のパケットを、拡張機能で正しく処理する必要があります。


注意 pre-packet-decode に使用される要求ディクショナリの client-packet および packet データ項目は、要求ディクショナリを持つすべての拡張ポイントで使用できます。ただし、pre-packet-decode 以外の拡張ポイントでパケットを直接変更または置換すると、予期しない副作用をもたらす可能性があるため、そのような操作は行わないでください。たとえば、パケットに対する変更をサーバが受け取らなかったり、処理中にオプションのデータが突然変更されたりする場合があります。

受信パケットのロギングをイネーブルにしている場合、サーバが、この拡張ポイントに登録済みの拡張機能を呼び出した後にパケットをロギングするので、注意してください。

post-packet-decode

post-packet-decode に使用可能なディクショナリは、要求ディクショナリと環境ディクショナリです。

この拡張ポイントの直後に入力パケットのデコードが行われ、続いてパケットのデータに対する処理が行われます。この時点における拡張機能の主なアクティビティは、入力パケットの情報を読み取ってそれに何らかの処理を行うことです。たとえば、この拡張ポイントを使用して入力パケットをリライトできます。

post-packet-decode 拡張ポイントは、最も簡単に使用できる拡張ポイントの 1 つです。サーバ動作の変更が、入力 DHCP または BOOTP パケットのリライトとして表現できる場合は、この拡張ポイントを使用する必要があります。パケットはすでにデコードされていますが、何も処理されていないので、副作用は非常に限られています。

post-packet-decode 拡張ポイントはデコード済みの入力パケットを変更できる唯一のポイントなので、サーバがすべての変更点を認識しているかを確認する必要があります。拡張機能は、パケットをドロップし、それ以降の処理を終了する場合に、環境ディクショナリの drop データ項目を使用します。

表29-4 に、 post-packet-decode 要求ディクショナリで使用できるデータ項目のリストを示します。

 

表29-4 post-packet-decode 要求ディクショナリのデータ項目

要求ディクショナリのデータ項目
操作

client-ipaddress

IP アドレス

読み取り/書き込み

client-port

整数

読み取り/書き込み

os-type

文字列

読み取り/書き込み

reply-to-client-address

整数

読み取り/書き込み

transaction-time

整数

読み取り専用

post-class-lookup

post-class-lookup に使用可能なディクショナリは、要求ディクショナリと環境ディクショナリです。

サーバがこの拡張ポイントを呼び出すのは、 client-class-lookup-id が存在する場合だけです。それ以外は、 post-packet-decode と同様です。サーバは、 client-class-lookup-id を評価してこのクライアントにクライアントクラス データを設定した後に、 post-class-lookup 拡張ポイントを呼び出します。この拡張ポイントには、 post-packet-decode 拡張ポイントと同じディクショナリがあります。

この拡張ポイントへの入力時に、環境ディクショナリは drop データ項目を true または false に設定します。この設定を拡張機能で変更することで、パケットをドロップする(またはドロップしない)ように設定でき、その変更がサーバから認識されます。またサーバは、 log-drop-message を調べて、ドロップをロギングするかどうかを決定します。

この拡張ポイントは、環境ディクショナリで client-class-name を設定することもできます。これにより、以前のクライアントクラスとは無関係に、指定したクライアントクラスがこのパケットに設定されます。この設定が有効となるのは、環境ディクショナリの drop データ項目の値が、既存の拡張ポイントに対して false に設定されている場合のみです。

pre-client-lookup

pre-client-lookup に使用可能なディクショナリは、要求ディクショナリと環境ディクショナリです。

この拡張ポイントを使用できるのは、DHCP サーバについて、クライアントクラス処理をイネーブルにした場合だけです。この拡張ポイントを使用すると、拡張機能が次のアクションのどれでも、またはすべてを実行できます。

クライアントクラス処理時にサーバがルックアップするクライアントを変更する。

現在のエントリやそれが指定するクライアントクラスから検出されたデータ項目を上書きするための個々のデータ項目を指定する。

サーバがクライアントのルックアップをすべて省略するように設定する。この場合、使用されるクライアント データは、拡張機能が環境ディクショナリに提供したデータのみです。

この拡張ポイントで実行される拡張機能の操作については、要求ディクショナリを使用して決定できますが、環境ディクショナリがすべての操作を制御します。

pre-client-lookup の環境ディクショナリ

表29-5 のデータ項目は、 pre-client-lookup でクライアントクラスの制御に使用できます。

 

表29-5 pre-client-lookup 環境ディクショナリのデータ項目

環境ディクショナリのデータ項目
説明
操作

client-specifier

クライアントクラスの処理コードが、MCD または LDAP においてルックアップするクライアントの名前。この名前をこの拡張ポイントで変更すると、DHCP サーバが指定されたクライアントをルックアップします。

読み取り/書き込み

default-client-class-name

次の場合に、 default-client-class-name オプションに関連付けられている値を class-name として使用するように、サーバに指示します。

client-specifier データ項目が pre-client-lookup スクリプトで指定されていない場合

サーバが特定のクライアント エントリを見つけられなかった場合

default-client-class-name データ項目は、デフォルト クライアントに関連付けられている クラス名 に優先すると想定されます。

読み取り/書き込み

release-by-ip

client-id (DHCPRELEASE 要求から生成)によってリースを取得できない場合に、IP アドレスによってリースを解放するようにサーバに指示します。

読み取り/書き込み

skip-client-lookup

この項目を true に設定すると、DHCP サーバは、この拡張機能の終了直後に実行する通常のクライアント ルックアップを省略します。この場合、このクライアントの記述に使用されるデータ項目は、環境ディクショナリに配置されたデータ項目のみです。

読み取り/書き込み

user-defined-data

要求が処理される前にリースとともに格納されたリースの user-defined-data アトリビュートで設定されます。ヌルに設定された場合、サーバは user-defined-data を無視します。

読み取り/書き込み

pre-client-lookup へのクライアントクラス データの入力

表29-6 に示す環境ディクショナリのデータ項目を設定すると、(内部データベース内または LDAP からの)クライアント ルックアップによって決定された値が、設定した値で上書きされます。ディクショナリに何も追加しない場合、サーバはクライアント値に入っている値、つまりキーを使用します。

 

表29-6 pre-client-lookup 環境ディクショナリのクライアントのデータ項目

クライアントクラスのデータ項目
説明
操作

action

この文字列を数値に変換し、その結果をアクションとして使用します。使用できる数値は、 0 (なし)および 1 (除外)です。

読み取り/書き込み

authenticate-until

1970 年 1 月 1 日からの経過時間を秒数で計測した絶対時刻。クライアント認証の期限が満了する時刻を示すために使用します。クライアント認証の期限が満了すると、DHCP サーバは、クライアントクラスではなく、クライアントの unauthenticated-client-class オプションに指定された値を使用して、クライアント エントリの欠けているデータ項目を補完します。

読み取り/書き込み

client-class-name

このデータ項目によって指定されるクライアントクラスは、クライアント エントリで欠けている情報を補うために使用します。指定した名前に対応するクライアントクラスが存在しない場合は、DHCP サーバが警告をロギングして処理を続行します。 none を指定すると、DHCP サーバは、このクライアント エントリにクライアントクラス名が指定されていない場合と同様に動作します。

読み取り/書き込み

domain-name

このドメイン名は、スコープで指定されたドメイン名よりも優先し、クライアントの DNS 操作に使用します。スコープ内でドメインのプライマリ サーバとして表示される DNS サーバは、指定したドメインのプライマリ サーバでもある必要があります。クライアントまたはクライアントクラス エントリでドメイン名の上書きがない場合、DHCP サーバはスコープのドメイン名を使用します。クライアント エントリまたは拡張機能に none という語が含まれている場合、DHCP サーバはスコープのドメイン名を使用します。

読み取り/書き込み

host-name

これは、入力パケットで指定された host-name オプション、またはクライアントやクライアントクラス エントリによるデータに優先して、クライアントに使用します。これを none に設定すると、DHCP サーバはクライアントやクライアントクラス エントリによる情報を使用せず、クライアントの要求による名前を使用します。

読み取り/書き込み

policy-name

このポリシーを、クライアント エントリに対して指定されたポリシーとして使用し、そのクライアント エントリによって指定されたすべてのポリシーを上書きします。

読み取り/書き込み

selection-criteria

カンマで区切られた文字列のリストで、各文字列はこのクライアントのスコープ選択基準を(この入力パケットについて)指定します。このクライアントが使用するスコープは、これらの scope-selection タグをすべて持っている必要があります。

このデータ項目は、クライアントまたはクライアントクラス エントリで指定された基準を上書きする場合に使用します。これを使用すると、クライアント エントリのスコープ選択基準がローカルまたは LDAP データベースのどちらに格納されているかとは無関係に、DHCP サーバはそのスコープ選択基準を使用しません。このデータ項目を none に設定すると、DHCP サーバはこのパケットにスコープ選択タグを使用しません。これをヌル文字列に設定すると、DHCP サーバはそれを設定されていない場合と同様に扱って、クライアントまたはクライアントクラス エントリのスコープ選択基準を使用します。

読み取り/書き込み

selection-criteria-excluded

カンマで区切られた文字列のリストで、各文字列はこのクライアントの除外基準を(この入力について)指定します。このクライアントが使用するスコープには、これらの選択タグが存在してはなりません。

このデータ項目は、指定されたクライアントまたはクライアントクラス エントリを上書きする場合に使用します。これを使用すると、クライアント エントリのスコープ除外基準がローカルまたは LDAP データベースのどちらに格納されているかとは無関係に、DHCP サーバはそのスコープ除外基準を使用しません。これを none に設定すると、DHCP サーバは、このパケットにスコープ除外タグを使用しません。このデータ項目をヌル文字列に設定すると、DHCP サーバはそれを設定されていない場合と同様に扱って、クライアントまたはクライアントクラス エントリのスコープ除外基準を使用します。

読み取り/書き込み

unauthenticated-client-
class-name

サーバがクライアントを認証しない場合に使用するクライアントクラスの名前。
unauthenticated-client-class-name を指定しないことを示すには、このデータ項目の値として無効なクライアントクラス名を使用します。値 none またはクライアントクラス名でない名前を使用できます。DHCP サーバは、クライアントクラスが存在しないというエラーをロギングします。

読み取り/書き込み

user-defined-data

要求が処理される前にリースとともに格納されたリースの user-defined-data アトリビュートで設定されます。ヌルに設定された場合、サーバは user-defined-data を無視します。

読み取り/書き込み

pre-client-lookup の要求ディクショナリ

表29-7 で説明するデコード済みのパケット データ項目は、すべてが使用可能です。 pre-client-lookup 拡張ポイントに対して使用できる要求情報のデータ項目は、 client-ipaddress client-port 、および transaction-time です(表29-4を参照)。 表29-7 ではこの拡張ポイントで使用可能なクライアント情報のデータ項目、 表29-8 ではクライアント理解データ項目について、それぞれ説明します。

 

表29-7 pre-client-lookup 要求ディクショナリのクライアントのデータ項目

クライアント情報のデータ項目
操作

client-id

blob

読み取り/書き込み

client-id-created-from-mac-address

整数

読み取り専用

client-mac-address

blob

読み取り/書き込み(DHCPv4 のみ)

client-os-type

文字列

読み取り/書き込み

 

表29-8 pre-client-lookup 要求ディクショナリのクライアント理解データ項目

クライアント理解データ項目
操作

client-wants-nulls-in-strings

整数

読み取り/書き込み

import-packet

整数

読み取り/書き込み

reply-to-client-address

整数

読み取り/書き込み

post-client-lookup

post-client-lookup に使用できるディクショナリは、要求ディクショナリと環境ディクショナリです。

この拡張ポイントを使用すると、クライアントクラス処理操作全体の結果を検査し、それらの結果に基づいて措置を講じることができます。たとえば、それを使用して結果の一部をリライトしたり、パケットをドロップしたりします。 post-client-lookup 拡張ポイントで実行されている拡張機能のクライアントクラス処理から返されたパケット内のホスト名を上書きするには、ホスト名を要求ディクショナリの client-requested-host-name データ項目に設定します。この操作により、Network Registrar は、データ項目で指定した文字列がパケットに指定されている場合と同様に、そのサーバを参照します。

また、この拡張ポイントを使用して、環境ディクショナリにデータ項目を設定し、 pre-packet-encode 拡張ポイント(「pre-packet-encode」を参照)で実行されている拡張機能の処理に対し、応答パケットに別のオプションをロードしたり、他の措置を講じたりといった影響を与えることもできます。

post-client-lookup の環境ディクショナリ

post-client-lookup では、 表29-9 に示す環境ディクショナリのデータ項目を使用できます。

 

表29-9 post-client-lookup 環境ディクショナリのデータ項目

環境ディクショナリのデータ項目
説明
操作

client-specifier

クライアントクラス処理でルックアップしたクライアントの名前。

読み取り専用

cnr-ldap-query-failed

DHCP サーバは、LDAP サーバの障害からの回復を容易にするためにこのアトリビュートを設定します。これにより、post-client-lookup スクリプトが LDAP サーバの障害に対応できるようになります。DHCP サーバは、クライアントのルックアップの後、LDAP サーバのエラーが原因で LDAP クエリーが失敗した場合に、このフラグを true に設定します。サーバが LDAP サーバから応答を受け取ると、次の 2 つの状況のいずれかが発生します。

フラグが false に設定される。

cnr-ldap-query-failed アトリビュートが環境ディクショナリに表示されない。

読み取り専用

user-defined-data

要求が処理される前にリースとともに格納された、リースの user-defined-data アトリビュートで設定されます。ヌルに設定された場合、サーバは user-defined-data を無視します。

読み取り/書き込み

post-client-lookup の要求ディクショナリ

表29-10 で説明するデコード済みのパケット データ項目は、すべてが使用可能です。
post-client-lookup 拡張ポイントで使用可能な要求情報のデータ項目は、 client-ipaddress client-port 、および transaction-time です(表29-4を参照)。クライアント情報データ項目は、 pre-client-lookup 拡張ポイントの場合と同じです(表29-7を参照)。

 

表29-10 post-client-lookup 要求ディクショナリのクライアント理解データ項目

クライアント理解データ項目
操作

client-class-name

文字列

読み取り専用

client-class policy

文字列

読み取り/書き込み

client-domain-name

文字列

読み取り/書き込み

client-host-name

文字列

読み取り/書き込み

client-policy

文字列

読み取り/書き込み

client-requested-host-name

文字列

読み取り/書き込み

client-wants-nulls-in-strings

整数

読み取り/書き込み

import-packet

整数

読み取り/書き込み

reply-to-client-address

整数

読み取り/書き込み

selection-criteria

文字列

読み取り/書き込み

selection-criteria-excluded

文字列

読み取り/書き込み

generate-lease

generate-lease に使用可能なディクショナリは、要求、応答、および環境の各ディクショナリです。この拡張ポイントは DHCPv6 だけに対して使用できます。

この拡張ポイントを使用すると、DHCPv6 アドレスまたはプレフィックスを生成し、拡張機能でそのアドレスまたはプレフィックスを制御できるようになります。サーバが generate-lease を呼び出すのは、アドレスの割り振りまたはプレフィックスの委任の際に拡張機能を呼び出せるようにプレフィックスが設定されている場合に限られます。つまり、プレフィックスの allocation-algorithms アトリビュートで拡張フラグが設定されている必要があります。サーバが generate-lease 拡張機能を呼び出すと、次のことが行われます。

サーバが、応答ディクショナリのプレフィックス コンテキストを、リースが作成されるプレフィックスに設定します(DEX_PREFIX および DEX_INITIAL を指定して setObject を呼び出すと、このコンテキストが返されます)。

サーバがまだリースを作成していないため、リース コンテキストは存在しません。ただし、
リースバインディング データ項目、特に lease-binding-type lease-binding-iaid は使用できます(DEX_LEASE および DEX_INITIAL を指定して setObject を呼び出すと、このコンテキストが返され、さらにプレフィックスが設定されます。これは、リース コンテキストによって、リース、バインディング、プレフィックスの 3 つのコンテキストが設定されるからです)。

サーバが、環境ディクショナリの skip-lease データ項目を false に設定します。

サーバが、環境ディクショナリの attempts データ項目(読み取り専用)を、このリースを作成するために拡張機能を呼び出した回数(1 から開始)に設定します。

プレフィックス委任の場合は、次の環境ディクショナリ データ項目を使用できます。

prefix-length :プレフィックス長(要求された、またはデフォルトのプレフィックス長)

default-prefix-length :デフォルトのプレフィックス長(ポリシーから取得)

longest-prefix-length :許容される最大プレフィックス長(ポリシーから取得)

shortest-prefix-length :許容される最小プレフィックス長(ポリシーから取得)

拡張機能が復帰すると、次の操作を実行できます。

環境ディクショナリの generated-address データ項目にアドレスを設定することで、明示的なアドレス(ステートフルなアドレス割り当て用)を要求する。このアドレスをクライアントで使用できない場合は、サーバが再びこの拡張機能を呼び出すことがあります。

環境ディクショナリの generated-prefix データ項目にプレフィックスを設定することで、明示的なプレフィックス(プレフィックス委任割り当て用)を要求する。このプレフィックスをクライアントで使用できない場合は、サーバが再びこの拡張機能を呼び出すことがあります。

環境ディクショナリの skip-lease データ項目を true に設定することで、サーバがリースを割り当てないようにする。

上記の設定を行わないことで、通常のアドレス割り当てまたはプレフィックス委任を可能にする。

サーバは、リースごとに拡張機能を最大 500 回呼び出します(この制限は、サーバがランダムにリースを生成するときに現在適用されている制限と同じです)。サーバが拡張機能を複数回呼び出すのは、拡張機能から使用不能なアドレスまたは委任プレフィックス(プレフィックスの範囲内にない、またはすでに存在するプレフィックス)が提供された場合だけです。


) この拡張ポイントでは、サーバにパケットのドロップを要求できません。


check-lease-acceptable

check-lease-acceptable に使用可能なディクショナリは、要求、応答、および環境の各ディクショナリです。

この拡張ポイントには、現在のリースをこのクライアントで受容できるかどうかをサーバが判別した直後に到達します。この拡張機能を使用すると、その操作の結果を検査し、ルーチンが別の結果を返すようにすることができます。「リースの受け入れ可能性の判別」を参照してください。

acceptable データ項目は、この拡張ポイントの環境ディクショナリで使用できます。これは読み取りと書き込みのデータ項目であり、リースがこのクライアントで受け入れ可能かどうかに応じて、DHCP サーバが初期化します。この結果は、拡張機能を使用して読み込みや変更ができます。受け入れ可能なデータ項目を true に設定すると、それが受け入れ可能であることが示され、false に設定すると、受け入れ不能であることが示されます。

pre-packet-encode で使用可能な要求ディクショナリのデータ項目は、いずれも check-lease-acceptable で使用可能です(「pre-packet-encode」を参照)。

pre-packet-encode に使用できるすべての応答ディクショナリ データ項目は、 check-lease-acceptable に使用でき、加えて client-os-type データ項目も使用できます。これは読み取り/書き込みデータ項目であり、拡張機能を使用して読み取りと変更ができます。ただし、 client-os-type データ項目の設定は、 post-packet-decode 要求ディクショナリで os-type データ項目を変更することによってのみ可能です。

lease-state-change

lease-state-change に使用可能なディクショナリは、応答ディクショナリと環境ディクショナリです。

サーバは、リースの状態が変化したときにこの拡張ポイントを呼び出します。既存の状態は、応答ディクショナリの lease-state というリース情報のデータ項目にあります(表29-12を参照)。新しい状態は、環境ディクショナリのデータ項目 new-state にあります。新しい状態が既存の状態と同一の場合、サーバはこの拡張ポイントを呼び出しません。

この拡張ポイントは主に読み取り専用で使用しますが、他の拡張ポイントが後から取得できるように、データを環境ディクショナリに書き込むこともできます。

lease-state-change には、たとえばリース期限用などに、別の環境ディクショナリを持つこともできます。

lease-state-change の応答ディクショナリ

lease-state-change 拡張ポイントには、 pre-packet-encode「pre-packet-encode」を参照)と同じ応答ディクショナリ データ項目がありますが、有用なのはクライアント情報とリース情報のデータ項目だけです( 表29-11 および 表29-12 を参照)。この拡張ポイントでは、応答パケットが伝送されないことが多いので、応答ディクショナリのオプションやエンコード済みのパケット データ項目(たとえば、 giaddr ciaddr )にアクセスしないでください。

 

表29-11 lease-state-change 応答ディクショナリのクライアントのデータ項目

クライアント情報のデータ項目
操作

client-domain-name

文字列

読み取り/書き込み

client-expiration-time

blob

読み取り専用

client-host-name

文字列

読み取り/書き込み

client-id

blob

読み取り/書き込み

client-id-created-from-mac-address

整数

読み取り専用

client-last-transaction-time

整数

読み取り専用

client-mac-address

blob

読み取り/書き込み(DHCPv4 のみ)

client-requested-host-name

文字列

読み取り/書き込み

domain-name-changed

整数

読み取り/書き込み

host-name-changed

整数

読み取り/書き込み

host-name-in-dns

整数

読み取り/書き込み

reverse-name-in-dns

整数

読み取り/書き込み

 

表29-12 lease-state-change 応答ディクショナリのリースのデータ項目

リース情報のデータ項目
操作

lease-deactivated

整数

読み取り専用

lease-ipaddress

IP アドレス

読み取り専用

lease-reserved

整数

読み取り専用

lease-state

文字列

読み取り専用

response-source

文字列

読み取り専用。返される値は、サーバが処理中のものです。

unknown :次のいずれでもない場合
client :クライアント パケット
failover :フェールオーバー パートナーからのバインディング アップデート
timeout :リースの期限または猶予期間の終了
operator :ユーザ インターフェイスからの要求
one-lease-per-client :クライアントごとに 1 つのリース(新しいリース用に、古いリースからクライアントを削除)

start-time-of-state

整数

読み取り専用

lease-state-change の環境ディクショナリ

現在の状態は、応答ディクショナリの lease-state リース情報のデータ項目にあり( 表29-12 を参照)、変更後の状態は、環境ディクショナリの new-state データ項目にあります。これはすべて読み取り専用です。

この拡張ポイントに追加されているスクリプトの初期化エントリ ポイントでは、終了時に環境ディクショナリにアトリビュート exiting-state があると、サーバがそのアトリビュートの値を保存し、リースがその状態から別の状態に移行するときにのみスクリプトを呼び出します。したがって、 exiting-state leased に設定すると、既存の状態が leased で、かつ新しい状態がそれ以外の場合にのみ、サーバが拡張ポイントを呼び出します。他の方法で他のリースが移行するのを検出したが(たとえば、 post-send-packet 拡張ポイント)、本当に意図する移行以外、この拡張ポイントを呼び出すオーバーヘッドをかけないようにする場合に、このように設定することができます。有効なリース状態は次のとおりです。

available

offered

leased

expired

unavailable

released

other-available

pending-available

これらの状態についての厳格な状態移行テーブルはありません。フェールオーバー環境では、通常、バインディング アップデート メッセージを受け取ったサーバが、特定の状態の移行を行うことなく、相手側サーバの指示に従って状態を設定します。

pre-packet-encode

pre-packet-encode に使用可能なディクショナリは、要求、応答、および環境の各ディクショナリです。


) DHCPv6 Reconfigure メッセージには、要求ディクショナリがありません(Reconfigure はサーバが発信するメッセージであるため)。したがって、イネーブルにした拡張機能で、応答の msg-type に ADVERTISE または REPLY がないか調べるか、要求に isValid を使用して Reconfigure メッセージが存在するか確認する必要があります。


pre-packet-encode の要求ディクショナリ

表29-13 で説明するデコード済みのパケット データ項目は、すべてが使用可能です。
pre-packet-encode
拡張ポイントで使用可能な要求情報のデータ項目は、 client-ipaddress client-port 、および transaction-time です(表29-4を参照)。 表29-13 に、クライアント情報のデータ項目を示します。クライアント理解データ項目は、 post-client-lookup 拡張ポイントの場合と同じです(表29-10を参照)。

 

表29-13 pre-packet-encode のクライアントのデータ項目

クライアント情報のデータ項目
操作

client-id

blob

読み取り/書き込み

client-id-created-from-mac-address

整数

読み取り専用

client-mac-address

blob

読み取り/書き込み(DHCPv4 のみ)

reply-to-client-address

整数

読み取り/書き込み

pre-packet-encode の応答ディクショナリ

pre-packet-encode 拡張ポイントには、次に示す応答ディクショナリのデータ項目があります。

一般 表29-14 を参照してください。

クライアント情報 表29-15 を参照してください。

リース情報 表29-16 を参照してください。

スコープ アドレス情報 表29-17 を参照してください。

スコープ受け入れ可能性情報 表29-18 を参照してください。

スコープ DNS 情報 表29-19 を参照してください。

 

表29-14 pre-packet-encode 応答ディクショナリの一般データ項目

応答ディクショナリのデータ項目
操作

reply-ipaddress

IP アドレス

読み取り/書き込み

reply-port

整数

読み取り/書き込み

scope-ping-clients

整数

読み取り専用

scope-renew-only

整数

読み取り専用

scope-renew-only-expire-time

整数

読み取り専用

scope-selection-tags

文字列

読み取り専用

scope-send-ack-first

整数

読み取り専用

transaction-time

整数

読み取り専用

 

表29-15 pre-packet-encode のクライアントのデータ項目

クライアント情報のデータ項目
操作

client-domain-name

文字列

読み取り専用

client-expiration-time

blob

読み取り専用

client-host-name

文字列

読み取り専用

client-id

blob

読み取り専用

client-id-created-from-mac-address

整数

読み取り専用

client-last-transaction-time

整数

読み取り専用

client-mac-address

blob

読み取り専用(DHCPv4 のみ)

client-requested-host-name

文字列

読み取り専用

domain-name-changed

整数

読み取り専用

host-name-changed

整数

読み取り専用

host-name-in-dns

整数

読み取り専用

reverse-name-in-dns

整数

読み取り専用

 

表29-16 pre-packet-encode のリースのデータ項目

リース情報のデータ項目
操作

lease-deactivated

整数

読み取り専用

lease-ipaddress

IP アドレス

読み取り専用

lease-reserved

整数

読み取り専用

lease-state

文字列

読み取り専用

lease-start-time-of-state

整数

読み取り専用

 

表29-17 pre-packet-encode のスコープ アドレスのデータ項目

スコープ アドレス情報のデータ項目
操作

scope-network-number

IP アドレス

読み取り専用

scope-primary-network-number

IP アドレス

読み取り専用

scope-primary-subnet-mask

IP アドレス

読み取り専用

scope-subnet-mask

IP アドレス

読み取り専用

 

表29-18 pre-packet-encode のスコープ受け入れ可能性のデータ項目

スコープ受け入れ可能性情報のデータ項目
操作

scope-allow-bootp

整数

読み取り専用

scope-allow-dhcp

整数

読み取り専用

scope-allow-dynamic-bootp

整数

読み取り専用

scope-available-leases

整数

読み取り専用

scope-deactivated

整数

読み取り専用

 

表29-19 pre-packet-encode のスコープ DNS アップデートのデータ項目

スコープ DNS 情報のデータ項目
操作

scope-dns-forward-server-address

IP アドレス

読み取り専用

scope-dns-forward-zone-name

文字列

読み取り専用

scope-dns-number-of-host-bytes

整数

読み取り専用

scope-dns-reverse-server-address

IP アドレス

読み取り専用

scope-dns-reverse-zone-name

文字列

読み取り専用

scope-update-dns-enabled

整数

読み取り専用

scope-update-dns-for-bootp

整数

読み取り専用

post-packet-encode

post-packet-encode に使用可能なディクショナリは、要求、応答、および環境の各ディクショナリです。


) DHCPv6 Reconfigure メッセージには、要求ディクショナリがありません(Reconfigure はサーバが発信するメッセージであるため)。したがって、イネーブルにした拡張機能で、応答の msg-type に ADVERTISE または REPLY がないか調べるか、要求に isValid を使用して Reconfigure メッセージが存在するか確認する必要があります。


サーバは、パケットをエンコードしてからクライアントに送信するまでの間に、この拡張機能を呼び出します。その結果、サーバはクライアントにパケットを送信する前に、そのパケットを検査および変更できます。また、拡張機能によってサーバでパケットをドロップすることもできます(ただし、サーバがその内部データとディスク上のデータに変更を加えていた場合は、パケットをドロップしても変更が元に戻りません)。

応答ディクショナリには client-packet および packet データ項目が追加されており、その動作は 「pre-packet-decode」に示した要求ディクショナリに対する動作と同様です。他の拡張ポイントにはパケットが存在しないため、応答の client-packet または packet データ項目を要求できるのは、この拡張ポイントだけであることに注意してください。また、サーバはパケットに加えられた変更を処理せず、変更後のパケットをクライアントに単純に送信します。

送信パケットのロギングをイネーブルにすると、サーバがこの拡張ポイントに登録済みの拡張機能を呼び出した後に、パケットをロギングします。トレースに X>=3 が設定されている場合は、この拡張ポイントに登録済みの拡張機能を呼び出す前にも、サーバがパケットをロギングします(ただし、拡張機能が少なくとも 1 つ登録されている場合に限られます)。

pre-dns-add-forward


pre-dns-add-forward 拡張ポイントは推奨されなくなったため、説明が削除されました。Network Registrar の今後のリリースでは、この拡張ポイントが完全に削除される可能性があります。client-fqdn などの必須オプションを設定するには、代わりに以前の要求拡張ポイント
post-client-lookup など)を使用してください。


post-send-packet

post-send-packet 拡張ポイントは、DHCP 要求応答サイクルの厳しい時間制約外で実行する処理のために使用します。サーバは、パケットをクライアントに送信した後に、この拡張ポイントを呼び出します。


) DHCPv6 Reconfigure メッセージには、要求ディクショナリがありません(Reconfigure はサーバが発信するメッセージであるため)。したがって、イネーブルにした拡張機能で、応答の msg-type に ADVERTISE または REPLY がないか調べるか、要求に isValid を使用して Reconfigure メッセージが存在するか確認する必要があります。


表29-13の説明のとおり、 pre-packet-encode 拡張ポイントで使用されるすべての要求ディクショナリ データ項目を使用できます。ただし、すべての操作は読み取り専用です。
pre-packet-encode
拡張ポイントで使用されるすべての応答ディクショナリ データ項目を使用できます。詳細については、「pre-packet-encode の応答ディクショナリ」を参照してください。

environment-destructor

environment-destructor 拡張ポイントは、拡張機能が保持しているコンテキストをクリーンアップできるようにします。この拡張ポイントに使用可能なディクショナリは、環境ディクショナリだけです。

環境ディクショナリは、1 つのクライアント要求に対して呼び出されるすべての拡張ポイントに使用できます。一部の拡張機能は、1 つのクライアント要求に対して呼び出された複数の拡張ポイント間でコンテキスト情報を維持する必要があり、しかもサーバが処理中に複数の場所で要求をドロップする可能性があるため、拡張機能はその要求に対して自身が作成したコンテキストを確実に解放できないことがあります。このような場合、サーバは環境ディクショナリを破壊しようとするたびに、 environment-destructor 拡張ポイントを呼び出します(そのサーバが最初の場所で環境ディクショナリを作成している場合)。


) サーバは、それぞれの拡張機能を他の追加ポイントで呼び出していない場合でも、environment-destructor 拡張ポイントに追加されているすべての拡張機能を呼び出します。


オブジェクトとオプションの処理

次の項では、拡張機能における DHCP オブジェクトおよびオプションの特殊な処理方法について説明します。

オブジェクトおよびオプションを処理するメソッドの使用

拡張機能では、DHCP オブジェクトの設定、および DHCP オプションの取得、移動、適用、および削除を行うメソッドを呼び出すことができます。実際のメソッドは、TCL および C/C++ の setObject getOption moveToOption putOption 、および removeOption です。

これらの新しいコールバック メソッドは、Network Registrar 7.0 で主に DHCPv6 をサポートするために導入されました。ただし、オプション関連の機能は DHCPv4 にも使用できます。これらのメソッドは、元のメソッドの get [ Bytes ]、 get [ Bytes ] ByType put [ Bytes ]、 put [ Bytes ] ByType 、および remove [ ByType ] よりもオプションへのアクセス機能が充実していることから、DHCPv4 に使用することが推奨されています。


ヒント C/C++ でのこれらのメソッドのさまざまな使用方法については、「DEX 要求ディクショナリ方式と応答ディクショナリ方式」を参照してください。


DHCPv6 では、 setObject getOption moveToOption putOption 、および removeOption の各メソッドを使用して、オプションにアクセスする必要があります。 setObject メソッドは DHCPv6 用に導入されました。これは、拡張機能が多数のリース、プレフィックス、およびメッセージ(クライアントまたは複数リレー)にアクセスする可能性があるからです。そのため、 setObject では、要求および応答ディクショナリのデータ項目とオプションを取得するように、後続の呼び出しのコンテキストを設定します。サーバが拡張機能を呼び出すと、コンテキストが現在のリース(該当する場合)、プレフィックス(該当する場合)、およびクライアント メッセージに設定されます。たとえば、サーバが pre-packet-encode 拡張ポイントを呼び出した場合、この拡張ポイントにはリースやプレフィックスが関連付けられていないため、要求および応答ディクショナリのメッセージ コンテキストだけが有効となり、そのコンテキストが対応するクライアント メッセージに設定されます。一方、サーバが lease-state-change 拡張ポイントを呼び出した場合は、応答ディクショナリのリース コンテキストが状態の変化したリースに設定され、応答ディクショナリのプレフィックス コンテキストがそのリースのプレフィックスに設定されて、さらに要求および応答ディクショナリのメッセージ コンテキストが、対応するクライアント メッセージに設定されます。

C/C++ でのオプションとサブオプション

一部の C/C++ 拡張機能には、DHCP オプションおよびサブオプションを処理するための特殊な引数タイプ値が用意されています。DEX_OPTION_ * 引数タイプは、オプション(またはサブオプション)での定義ではなく、標準の DHCPv4 または DHCPv6 オプション定義セットを使用するように指定します。そのため、DEX_OPTION_ * を使用すると、サーバは標準の DHCPv4 または DHCPv6 オプション定義セットでオプション名または番号をルックアップし、DEX_SUBOPTION_ * を使用すると、現在のオプション定義(存在する場合)のサブオプション名または番号をルックアップします。

したがって、DHCPv6 のオプションにアクセスするときに、オプションがカプセル化されている場合は、DEX_OPTION_ * に続けて DEX_OPTION_ * を使用することがよくあります。ベンダー オプションを調べるときは、DEX_SUBOPTION を使用します。DHCPv4 の場合は、クライアント パケット レベルで DEX_OPTION を使用してから、ネスト レベルに応じて DEX_SUBOPTION を 1 回以上使用します。一般的に、エンタープライズ番号やベンダー名を持つのはオプションだけですが、これが禁止されているわけではありません。何が有効になるかは、オプション定義セットによって決まります(定義を解消することも可能ですが、その時点ですべてがバイナリ バイトとして扱われるため、何を可能にするかが制限されます。また、オプションやサブオプションの名前は使用できませんが、番号を使用する必要があります)。

getOption moveToOption putOption removeOption の各メソッドでのオプションの順序指定ルールは、 request 式のシンタックスと同様です(表25-1を参照)。順序指定の一般的な構成は次のとおりです。

プリアンブル句([ parent | home ])

オプション句( option [ vendor | enterprise ] [ instance ])

サブオプション句( suboption [ vendor | enterprise ] [ instance ])

終了句([ instance-count | index-count | [ index ] [ more ] end

呼び出しを構成するには、1 つのプリアンブル句を使用し、その後に 0 個以上のオプション句、0 個以上のサブオプション句(これ自体にオプション句とサブオプション句が続く場合もあります)、1 つの終了句の順に使用します。 get メソッドでないと実行できないもの( instance-count index-count more など)もあります。また、 move-to はどこにあっても、コンテキストを現在のオプションまたはサブオプションに移動することができます。

オプション定義によってそのデータ形式が決まりますが、このデータ形式は、以前の関数が特定のオプションに返す形式と異なることがあります。処理するオプションによっては、次の点に注意してください。

ベンダー クラス オプション(DHCPv4 の場合は v-i-vendor-class [124]、DHCPv6 の場合は vendor-class [16])では、オプションの特定のインスタンスを要求する(エンタープライズ ID または名前を使用しない)場合、エンタープライズ ID を取得する唯一の方法は、未加工のデータを要求(DEX_INDEX で DEX_RAW を指定)することです。

DHCPv4 ベンダー オプション( v-i-vendor-class [124] および v-i-vendor-opts [125])では、未加工のデータ(DEX_INDEX で DEX_RAW を指定)に対する操作が、オプション全体ではなく、そのオプションのインスタンス(プリセット値は 0)だけに適用されます。このオプションのデータ全体を取得する方法はないため、 putOption をデータ全体に対して使用することはできません。DHCPv6 ベンダー オプションでは、それぞれが独立したオプションであるため、この点は問題になりません。

いずれかの DHCPv4 ベンダー オプション(124 または 125)が正しくフォーマットされていないと、データ全体が blob として返されます(インスタンス 0 を要求し、特定のエンタープライズ ID を指定しなかった場合)。ただし、拡張機能が putOption を使用した場合、操作によってはそのデータが既存のデータに追加されて、フォーマットが正しくなくなることもあります。

ベンダー オプションでは、オプションの指定がないと、エンタープライズ ID が得られないために putOption( pDict, "01:02", DEX_OPTION_NUMBER, 124, DEX_END ) が失敗します。ただし、00:00:00:09 がエンタープライズ ID であり、それに続く 04 で始まるバイトが、そのエンタープライズ ID のオプション データの長さであると見なされるため、 putOption( pDict, "00:00:00:09:04:03:65:66:67", DEX_OPTION_NUMBER, 124, DEX_END ) は正常に実行されます。この場合は、長さバイトが検証され、正しい長さでないと putOption が失敗します。このデータを追加する場合は、 putOption( pDict, "65:66:67", DEX_OPTION_NUMBER, 124, DEX_ENTERPRISE_ID, 9, DEX_END ) を使用した方法を推奨します。