サイト内関連リンク：RFC 2131 DHCP
この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況は "Internet Official ProtocolStandards"(STD 1)を参照してほしい。この文書の配布は無制限である。
Copyright (C) The Internet Society (2002). All Rights Reserved.
この文書は、動的ホスト構成プロトコル(DHCPv4)において同じメッセージ内に複数回現れるオプションを扱うための規則を規定している。同じオプションの複数のインスタンスは、オプションが 255 オクテット(単独オプションでの最大サイズ)を超える場合、または DHCP オプションのオーバーロードの利点を得るためにオプションを分割する必要がある場合に生成される。オプション(DHCP パケット中の file フィールド かつ/または snameフィールド)内に同じオプションの複数のインスタンスがある場合、それらのオプションがひとつのオプションを形成するように、処理に先立って連結される。
RFC 2131[3] のセクション 4.1 に記述されているオプションの連結規則を明らかにすることにより、この文書は RFC 2131 を更新する。読者は RFC 2131 の該当部分を熟知していることを期待される。RFC 2131 のセクション 4.1 に書かれている "オプションは、そのオプションに関する文書で別に指定されていない限り、一度だけ現れることが許される。(Options may appear only once, unless otherwise specified in the options document.)" は削除されたと見なされるべきである。
DHCP プロトコル[3]は DHCP プロトコルエージェント間で情報を受け渡すための、DHCPv4 パケット中に符号化される "オプション" と呼ばれるものを規定している。これらのオプションは、タイプコードを表す 1 バイト、長さを表す 1 バイト、そしてその長さのバイト数(0 から 255)から構成されるバッファとして符号化される。
しかしながら 255 バイトを超えるオプションを送ることが有用な場合もあるだろう。ある特定のタイプコードを伴う二つ以上のオプションが DHCP パケット中に現れた場合、RFC 2131[3] ではそれらのオプションは全て連結されるべきであると規定しているが、その連結が行われるべき順序に関しては規定していない。
私たちはここで、255 バイトを超えるオプションを送信する場合に DHCP プロトコルエージェントによって使用されなければならない(MUST)順序付けの規則を規定する。何らかの理由によりプロトコルエージェントが 255 バイトより短いオプションを分割する場合にも、この規則が使用されなければならない(MUST)。ある特定のオプションタイプが二つ以上現れる DHCP パケットを受け取った場合にはいつでも、DHCP プロトコルエージェントはこの規則を用いなければならない(MUST)。
この文書では、キーワード "MAY" "MUST" "MUST NOT" "OPTIONAL" "RECOMMENDED" "SHOULD" "SOULD NOT"は、BCP 14,RFC 2119[2] で説明されている通りに解釈される。
複数に分割しなければならないオプションを含むパケットを DHCP エージェントが符号化する場合にこの規約は適用される。この分割には二つの理由がある。第一に、送信しなければならないオプション値が 255 バイトを超える場合である。この場合符号化エージェントはここで規定するアルゴリズムに従わなければならない(MUST)。第二に、現在の出力バッファにはオプションを格納するための十分な空きが無いが、オプションの一部を格納する空きはあり、オプションの残りの部分を格納するために別の出力バッファにも空きがあるという場合がありうる。この場合、符号化エージェントはこのアルゴリズムに従うか、そのオプションを全く送信しないかの何れかでなければならない(MUST)。
また、ある特定のタイプのオプションの複数のインスタンスを含む DHCP パケットを DHCP エージェントが受け取った場合にもこの規約は適用される。この場合そのエージェントは、ここで規定されている方法に従って分割されたオプションを連結しなければならない(MUST)。
このオプションは Dynamic Host Configuration Protocol [3] と DHCP Options and BOOTP vendor extensions [4] とを更新する。しかしながら現状出回っている DHCP プロトコルエージェントの多くはオプションの連結機能を実装していないため、受信側がオプションを正しく再構築できるかどうかが問題にならないか、受信側が連結機能を実装していることが確実な場合を除き、DHCP プロトコルエージェントは分割されたオプションを送信しないように注意するべきである。
ここで全ての DHCP オプションを二つのカテゴリに分類する - この文書で定義されているメカニズムの実装を必要とするものと、それ以外とである。私たちは前者を要連結オプション、後者を非要連結オプションとして言及する。要連結オプションになり得るオプションを定義するプロトコル規約では、明確にこの文書への参照を付けることにより、この文書で説明されているオプションの分割と連結とを実装することを要求しなければならない。
他に選択肢がないか、分割したオプションを相手側が適切に処理できることが分かっている場合を除き、DHCP プロトコルエージェントはこの文書で説明されているようなオプションの分割を行うべきではない(SHOULD NOT)。少なくともひとつの要連結オプションを提供するか要求するかした場合に、その通信相手は分割されたオプションを適切に処理できるものと見なされる。あるいはオプションを生成するエージェントの管理者は、この文書で説明されているような分割されたオプションを受信者が正しく連結できるものと仮定するように、明示的にそのエージェントを構成してもよい。
一部の実装は、要分割オプションだけを分割し、非要分割オプションを決して分割しないのが最も簡単であると考えるかもしれない。それは許容される。しかしながら何らかの連結オプションをサポートする実装は、要連結オプションと非要連結オプションとの両方を処理する能力を持たなければならない(MUST)。
DHCP エージェントが DHCP メッセージを受信する際のオプションの連結に対する制限は無い。この文書で説明されているメカニズムを実装している DHCP プロトコルエージェントは、同じタイプの二つのオプションを受信した時、それらを連結するべきである。
DHCP オプションは DHCP パケット内の三つの部分に格納することが出来る。それらは RFC 2131[3] で説明されている任意のパラメータフィールド・sname フィールド・file フィールドである。分割されるオプションが置かれても良いフィールドが三つに分かれているため、オプション分割のメカニズムの説明は複雑になっている。
さらに問題を複雑にすることに、ひとつのフィールドに納まらないオプションは別のオプションへの境界をまたぐことが許されず、代わりに符号化エージェントはそのオプションを二つに分け、各バッファにひとつずつを格納しなければならない。
議論を簡単にするために、私たちは三つのバッファの集合である集合オプションバッファについて書くことにする。これは論理的な集合であり、そのバッファは RFC 2131[3] で説明されている DHCP パケット内の各位置に現れなければならない(MUST)。
集合オプションバッファは、任意のオプションパラメータフィールド、file フィールド、sname フィールドから構成され、並び順もこの通りである。
警告: これは DHCP パケット内における三つのフィールドの物理的な並びとは異なる。
集合オプションバッファ内の三つのフィールド間の何れかの境界をまたぐような方法でオプションが格納されてはならない(MUST NOT)。
符号化エージェントは sname フィールドと file フィールドの両方、またはどちらか一方を使用することを自由に選択できる。符号化エージェントがこれら二つのフィールドを使用しないことを選択をした場合、この二つのフィールドは集合オプションバッファの一部であるとみなされてはならない(MUST NOT)。
"適用" と題した先のセクションで説明した理由に基き、符号化エージェントはオプションを分割することを決定する。
オプションは任意のオクテット境界で分割されてよい。分割された各部分が 255 オクテットを超えることは出来ない。分割されたオプションの各部分は集合オプションバッファに順番に格納されなければならない(MUST) - 最初の部分が集合オプションバッファの最初に、次に二番目の部分というように格納されなければならない(MUST)。符号化エージェントはオプションの分割方法に意味情報を含めようとしてはならない(MUST NOT)。
集合オプションバッファは DHCP パケットの物理的な並びを表していない。そのため、例えば三つに分割されたオプションの各部分がオプションフィールドに格納されるとき、最初の部分は任意のパラメータフィールドに、二番目の部分は file フィールドに、三番目の部分は sname フィールドに格納されることに注意してほしい。これは RFC 2131[3] との一貫性を維持している。
分割されたオプションの各部分は、それが RFC 2132[4] で説明されている通常の長さのオプションであるかのように集合オプションバッファに格納されなければならない(MUST)。分割されたオプションの各部分のフィールド長の合計が、そのオプション全体の長さに等しくならなければならない(MUST)。また分割された各部分のオプションコードフィールドの値は同じでなければならない。(MUST)
DHCP パケットのオプションバッファを読み取った複合エージェントが、その中に同じオプションコードを持つ二つ以上のオプションを見つけた場合、復号エージェントはそれを分割されたオプションと見なさなければならない(MUST)。
分割されたオプションを見つけた復号エージェントは、それらのオプションの内容を単一のオプションとして扱われなければならず(MUST)、前述の符号化エージェントの振る舞いの項で説明した順序でその内容を再構築しなければならない(MUST)。
オプションの値を使用するとき、復号エージェントは自分が動作しているマシンのアーキテクチャ特有のアラインメントの問題に対して確実に責任を負えるべきである。符号化エージェントがオプションのアラインを要求されることはない。
オプションが分割される位置に特別な意味はなく、符号化エージェントはどこでも自由にオプションを分割してよい。復号エージェントは分割されたオプションを単一のオブジェクトに再構築しなければならず(MUST)、分割されている各部分を別々のオブジェクトとして扱ってはならない(MUST NOT)。
"/diskless/foo" という値を持つオプション Bootfile name(オプションコード 67)を考える。通常これは、以下のように単一のオプションとして符号化される。
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 67 | 13 | / | d | i | s | k | l | e | s | s | / | f | o | o |
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
オプションバッファに合わせるために符号化エージェントがこのオプションを分割する場合、以下のように二つのオプションとして符号化し、この順序で集合オプションバッファに格納することが出来る。
+----+---+---+---+---+---+---+---+---+
| 67 | 7 | / | d | i | s | k | l | e |
+----+---+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+
| 67 | 6 | s | s | / | f | o | o |
+----+---+---+---+---+---+---+---+
この文書は新たなセキュリティ問題を提起しない。DHCP プロトコルにおける攻撃の潜在的な脅威は、DHCP プロトコル仕様のセクション 7 と DHCP メッセージの認証(Authentication for DHCP Messages)[5] とで議論されている。
認証オプション自身も分割され得ることに注意してほしい。そのような場合実装は、(MAC の生成または照合に先立って)認証フィールドにゼロをセットするとき、それが複数のオプションにまたがって分割されても良いように注意しなければならない。
[1] Croft, W. and J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 951,
September 1985.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[4] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Ted Lemon
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94043
USA
EMail: mellon@nominum.com
Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC 編集者の働きへの資金拠出は、現在 Internet Society によって提供されている。