Network Working Group S. Park
Request for Comments: 4039 P. Kim
Category: Standards Track SAMSUNG Electronics
B. Volz
Cisco Systems
March 2005
Rapid Commit Option for the
Dynamic Host Configuration Protocol version 4 (DHCPv4)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration.
このドキュメントでは、DHCPv6 Rapid Commitオプションをモデルにした新しいDynamic Host Configuration Protocolバージョン4（DHCPv4）オプションを定義し、通常の4メッセージ交換ではなく、2メッセージ交換を使用してIPアドレスと構成情報を取得し、クライアント構成を促進します。
Table of Contents
目次
1. Introduction................................................... 2
2. Requirements................................................... 2
3. Client/Server Operations....................................... 2
3.1. Detailed Flow............................................ 3
3.2. Administrative Considerations............................ 6
4. Rapid Commit Option Format..................................... 7
5. IANA Considerations............................................ 7
6. Security Considerations........................................ 7
7. References..................................................... 7
7.1. Normative References..................................... 7
7.2. Informative References................................... 8
8. Acknowledgements............................................... 8
Authors' Addresses................................................ 9
Full Copyright Statement.......................................... 10
In some environments, such as those in which high mobility occurs and the network attachment point changes frequently, it is beneficial to rapidly configure clients. And, in these environments it is possible to more quickly configure clients because the protections offered by the normal (and longer) 4-message exchange may not be needed. The 4-message exchange allows for redundancy (multiple DHCP servers) without wasting addresses, as addresses are only provisionally assigned to a client until the client chooses and requests one of the provisionally assigned addresses. The 2-message exchange may therefore be used when only one server is present or when addresses are plentiful and having multiple servers commit addresses for a client is not a problem.
高モビリティが発生し、ネットワーク接続ポイントが頻繁に変更される環境など、一部の環境では、クライアントを迅速に構成することが有益です。 また、これらの環境では、通常の（より長い）4メッセージ交換によって提供される保護が必要ない場合があるため、クライアントをより迅速に構成できます。 クライアントが暫定的に割り当てられたアドレスの1つを選択して要求するまで、アドレスは暫定的にクライアントに割り当てられるため、4メッセージ交換により、アドレスを無駄にすることなく冗長性（複数のDHCPサーバー）が可能になります。 したがって、2つのメッセージ交換は、サーバーが1つだけ存在する場合、またはアドレスが十分にあり、複数のサーバーがクライアントのアドレスをコミットすることが問題でない場合に使用できます。
This document defines a new Rapid Commit option for DHCPv4, modeled on the DHCPv6 Rapid Commit option [RFC3315], which can be used to initiate a 2-message exchange to expedite client configuration in some environments. A client advertises its support of this option by sending it in DHCPDISCOVER messages. A server then determines whether to allow the 2-message exchange based on its configuration information and can either handle the DHCPDISCOVER as defined in [RFC2131] or commit the client's configuration information and advance to sending a DHCPACK message with the Rapid Commit option as defined herein.
このドキュメントは、DHCPv6 Rapid Commitオプション[RFC3315]をモデルとするDHCPv4の新しいRapid Commitオプションを定義します。これは、2メッセージ交換を開始して、いくつかの環境でクライアント構成を促進するために使用できます。 クライアントは、DHCPDISCOVERメッセージで送信することにより、このオプションのサポートをアドバタイズします。 サーバーは、構成情報に基づいて2メッセージ交換を許可するかどうかを決定し、[RFC2131]で定義されたDHCPDISCOVERを処理するか、クライアントの構成情報をコミットして、ここで定義されたRapid CommitオプションでDHCPACKメッセージの送信に進むことができます 。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
これらのキーワードは、このドキュメントに記載されている場合、[RFC2119]で説明されているように解釈される必要があります。MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONAL。
If a client that supports the Rapid Commit option intends to use the rapid commit capability, it includes a Rapid Commit option in DHCPDISCOVER messages that it sends. The client MUST NOT include it in any other messages. A client and server only use this option when configured to do so.
ラピッドコミットオプションをサポートするクライアントがラピッドコミット機能を使用する場合、送信するDHCPDISCOVERメッセージにラピッドコミットオプションが含まれます。 クライアントはそれを他のメッセージに含めてはいけません。 クライアントとサーバーは、そのように構成されている場合にのみこのオプションを使用します。
A client that sent a DHCPDISCOVER with Rapid Commit option processes responses as described in [RFC2131]. However, if the client receives a DHCPACK message with a Rapid Commit option, it SHOULD process the DHCPACK immediately (without waiting for additional DHCPOFFER or DHCPACK messages) and use the address and configuration information contained therein.
Rapid CommitオプションでDHCPDISCOVERを送信したクライアントは、[RFC2131]で説明されているように応答を処理します。 ただし、クライアントがRapid Commitオプション付きのDHCPACKメッセージを受信した場合、DHCPACKをすぐに処理し（追加のDHCPOFFERまたはDHCPACKメッセージを待たずに）、そこに含まれるアドレスと構成情報を使用する必要があります。
A server that supports the Rapid Commit option MAY respond to a DHCPDISCOVER message that included the Rapid Commit option with a DHCPACK that includes the Rapid Commit option and fully committed address and configuration information. A server MUST NOT include the Rapid Commit option in any other messages.
Rapid Commitオプションをサポートするサーバーは、Rapid Commitオプションを含むDHCPDISCOVERメッセージに、Rapid Commitオプションと完全にコミットされたアドレスおよび構成情報を含むDHCPACKで応答する場合があります。 サーバーは、他のメッセージにRapid Commitオプションを含めてはなりません。
The Rapid Commit option MUST NOT appear in a Parameter Request List option [RFC2132].
Rapid Commitオプションは、Parameter Request Listオプション[RFC2132]に表示してはなりません（MUST NOT）。
All other DHCP operations are as documented in [RFC2131].
他のすべてのDHCP操作は[RFC2131]で文書化されています。
The following is revised from Section 3.1 of [RFC2131], which includes handling of the Rapid Commit option.
以下は、[RFC2131]のセクション3.1から改訂されており、Rapid Commitオプションの処理が含まれています。
1. The client broadcasts a DHCPDISCOVER message on its local physical subnet. If the client supports the Rapid Commit option and intends to use the rapid commit capability, it includes a Rapid Commit option in the DHCPDISCOVER message. The DHCPDISCOVER message MAY include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet.
1.クライアントは、ローカルの物理サブネットでDHCPDISCOVERメッセージをブロードキャストします。 クライアントがラピッドコミットオプションをサポートしており、ラピッドコミット機能を使用する場合、DHCPDISCOVERメッセージにラピッドコミットオプションが含まれます。 DHCPDISCOVERメッセージには、ネットワークアドレスとリース期間の値を提案するオプションが含まれる場合があります。 BOOTPリレーエージェントは、同じ物理サブネット上にないDHCPサーバーにメッセージを渡す場合があります。
2. Each server may respond with either a DHCPOFFER message or a DHCPACK message with the Rapid Commit option (the latter only if the DHCPDISCOVER contained a Rapid Commit option and the server's configuration policies allow use of Rapid Commit). These would include an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). Servers sending a DHCPOFFER need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client. Servers sending the DHCPACK message commit the binding for the client to persistent storage before sending the DHCPACK. The combination of 'client identifier' or 'chaddr' and assigned network address constitute a unique identifier for the client's lease and are used by both the client and server to identify a lease referred to in any DHCP messages. The server transmits the DHCPOFFER or DHCPACK message to the client, if necessary by using the BOOTP relay agent.
2.各サーバーは、DHCPOFFERメッセージまたはRapid Commitオプション付きのDHCPACKメッセージで応答できます（後者は、DHCPDISCOVERにRapid Commitオプションが含まれており、サーバーの構成ポリシーでRapid Commitの使用が許可されている場合のみ）。これらには、「yiaddr」フィールドに使用可能なネットワークアドレスが含まれます（およびDHCPオプションの他の構成パラメーター）。 DHCPOFFERを送信するサーバーは、提供されたネットワークアドレスを予約する必要はありませんが、サーバーが提供されたネットワークアドレスを別のクライアントに割り当てることを避ければ、プロトコルはより効率的に機能します。 DHCPACKメッセージを送信するサーバーは、DHCPACKを送信する前に、クライアントの永続ストレージへのバインディングをコミットします。 「クライアント識別子」または「chaddr」と割り当てられたネットワークアドレスの組み合わせは、クライアントのリースの一意の識別子を構成し、DHCPメッセージで参照されるリースを識別するためにクライアントとサーバーの両方で使用されます。サーバーは、必要に応じてBOOTPリレーエージェントを使用して、DHCPOFFERまたはDHCPACKメッセージをクライアントに送信します。
When allocating a new address, servers SHOULD check that the offered network address is not already in use; e.g., the server may probe the offered address with an ICMP Echo Request.
新しいアドレスを割り当てる場合、サーバーは、提供されたネットワークアドレスがまだ使用されていないことを確認する必要があります。 たとえば、サーバーは提供されたアドレスをICMPエコー要求でプローブできます。
Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses.
ネットワーク管理者が新しく割り当てられたアドレスのプローブを無効にすることを選択できるように、サーバーを実装する必要があります。
Figure 3 in [RFC2131] shows the flow for the normal 4-message exchange. Figure 1 below shows the 2-message exchange.
[RFC2131]の図3は、通常の4メッセージ交換のフローを示しています。 下の図1は、2メッセージ交換を示しています。
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| w/Rapid Commit| w/Rapid Commit|
| | |
Determines | Determines
configuration | configuration
| | Commits configuration
| Collects replies |
|\ | ____________/|
| \________ | / DHCPACK |
| DHCPOFFER\ |/w/Rapid Commit|
| (discarded) | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\_____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figure 1 Timeline diagram when Rapid Commit is used
図1ラピッドコミットを使用した場合のタイムライン図
3. The client receives one or more DHCPOFFER or DHCPACK (if the Rapid Commit option is sent in DHCPDISCOVER) messages from one or more servers. If a DHCPACK (with the Rapid Commit option) is received, the client may immediately advance to step 5 below if the offered configuration parameters are acceptable. The client may choose to wait for multiple responses. The client chooses one server from which to request or accept configuration parameters, based on the configuration parameters offered in the DHCPOFFER and DHCPACK messages. If the client chooses a DHCPACK, it advances to step 5. Otherwise, the client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, the message MAY include other options specifying desired configuration values. The 'requested IP address' option MUST be set to the value of 'yiaddr' in the DHCPOFFER message from the server. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents. To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as was the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if the client receives no DHCPOFFER messages.
3.クライアントは、1つ以上のサーバーから1つ以上のDHCPOFFERまたはDHCPACK（Rapid CommitオプションがDHCPDISCOVERで送信される場合）メッセージを受信します。 DHCPACK（Rapid Commitオプション付き）を受信した場合、提供された構成パラメーターが受け入れ可能であれば、クライアントはすぐに以下の手順5に進むことがあります。クライアントは、複数の応答を待つことを選択できます。クライアントは、DHCPOFFERおよびDHCPACKメッセージで提供される構成パラメーターに基づいて、構成パラメーターを要求または受け入れるサーバーを1つ選択します。クライアントがDHCPACKを選択した場合、ステップ5に進みます。それ以外の場合、クライアントは、選択したサーバーを示す「サーバー識別子」オプションを含める必要があるDHCPREQUESTメッセージをブロードキャストします。メッセージには、必要な構成値を指定する他のオプションを含めることができます。 「リクエストされたIPアドレス」オプションは、サーバーからのDHCPOFFERメッセージで「yiaddr」の値に設定する必要があります。このDHCPREQUESTメッセージはブロードキャストされ、DHCP / BOOTPリレーエージェントを介してリレーされます。 BOOTPリレーエージェントが元のDHCPDISCOVERメッセージを受信したDHCPサーバーの同じセットにDHCPREQUESTメッセージを確実に転送するために、DHCPREQUESTメッセージはDHCPメッセージヘッダーの「秒」フィールドで同じ値を使用して同じIPに送信する必要があります元のDHCPDISCOVERメッセージであったブロードキャストアドレス。クライアントがDHCPOFFERメッセージを受信しない場合、クライアントはタイムアウトし、DHCPDISCOVERメッセージを再送信します。
4. The servers receive the DHCPREQUEST broadcast from the client. Servers not selected by the DHCPREQUEST message use the message as notification that the client has declined those servers' offers. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. The combination of 'client identifier' or 'chaddr' and assigned network address constitute a unique identifier for the client's lease and are used by both the client and server to identify a lease referred to in any DHCP messages. Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding. The server SHOULD NOT check the offered network address at this point. The 'yiaddr' field in the DHCPACK messages is filled in with the selected network address.
4.サーバーは、クライアントからDHCPREQUESTブロードキャストを受信します。 DHCPREQUESTメッセージで選択されていないサーバーは、クライアントがそれらのサーバーのオファーを拒否したという通知としてメッセージを使用します。 DHCPREQUESTメッセージで選択されたサーバーは、クライアントのバインディングを永続ストレージにコミットし、要求元クライアントの構成パラメーターを含むDHCPACKメッセージで応答します。 「クライアント識別子」または「chaddr」と割り当てられたネットワークアドレスの組み合わせは、クライアントのリースの一意の識別子を構成し、DHCPメッセージで参照されるリースを識別するためにクライアントとサーバーの両方で使用されます。 DHCPACKメッセージ内の構成パラメーターは、クライアントが応答している以前のDHCPOFFERメッセージ内の構成パラメーターと競合しないようにする必要があります。 サーバーは、この時点で提供されたネットワークアドレスをチェックすべきではありません。 DHCPACKメッセージの「yiaddr」フィールドには、選択したネットワークアドレスが入力されます。
If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message.
選択したサーバーがDHCPREQUESTメッセージを満たすことができない場合（たとえば、要求されたネットワークアドレスが割り当てられている場合）、サーバーはDHCPNAKメッセージで応答する必要があります。
A server MAY choose to mark addresses offered to clients in DHCPOFFER messages as unavailable. The server SHOULD mark an address offered to a client in a DHCPOFFER message as available if the server receives no DHCPREQUEST message from that client.
サーバーは、DHCPOFFERメッセージでクライアントに提供されるアドレスを使用不可としてマークすることを選択できます。 サーバーは、クライアントがDHCPREQUESTメッセージをクライアントから受信しない場合、DHCPOFFERメッセージでクライアントに提供されたアドレスを使用可能としてマークする必要があります。
5. The client receives the DHCPACK message with configuration parameters. The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and it notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server, and it restarts the configuration process. The client SHOULD wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping.
5.クライアントは、構成パラメーターを含むDHCPACKメッセージを受信します。 クライアントは、パラメータ（たとえば、割り当てられたネットワークアドレスのARP）の最終チェックを実行する必要があり（SHOULD）、DHCPACKメッセージで指定されたリース期間を記録します。 この時点で、クライアントが構成されます。 アドレスがすでに使用されていることをクライアントが検出した場合（たとえば、ARPを使用して）、クライアントはDHCPDECLINEメッセージをサーバーに送信する必要があり、構成プロセスを再開します。 クライアントは、ループの場合に過剰なネットワークトラフィックを避けるために、構成プロセスを再起動する前に最低10秒待機する必要があります。
If the client receives a DHCPNAK message, the client restarts the configuration process.
クライアントがDHCPNAKメッセージを受信すると、クライアントは構成プロセスを再開します。
The client times out and retransmits the DHCPREQUEST message if the client receives neither a DHCPACK nor a DHCPNAK message. The client retransmits the DHCPREQUEST according to the retransmission algorithm in section 4.1 of [RFC2131]. The client should choose to retransmit the DHCPREQUEST enough times to give an adequate probability of contacting the server without causing the client (and the user of that client) to wait too long before giving up; e.g., a client retransmitting as described in section 4.1 of [RFC2131] might retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK nor a DHCPNAK message after employing the retransmission algorithm, the client reverts to INIT state and restarts the initialization process. The client SHOULD notify the user that the initialization process has failed and is restarting.
クライアントがDHCPACKもDHCPNAKメッセージも受信しない場合、クライアントはタイムアウトし、DHCPREQUESTメッセージを再送信します。 クライアントは、[RFC2131]のセクション4.1の再送信アルゴリズムに従ってDHCPREQUESTを再送信します。 クライアントは、クライアント（およびそのクライアントのユーザー）があまりにも長い時間待機せずにサーバーに接続する十分な確率を与えるのに十分な回数DHCPREQUESTを再送信することを選択する必要があります。 たとえば、[RFC2131]のセクション4.1で説明されているように再送信するクライアントは、初期化手順を再開する前に、DHCPREQUESTメッセージを4回、合計60秒の遅延で再送信する場合があります。 クライアントが再送信アルゴリズムを使用した後にDHCPACKもDHCPNAKメッセージも受信しない場合、クライアントはINIT状態に戻り、初期化プロセスを再開します。 クライアントは、初期化プロセスが失敗し、再起動していることをユーザーに通知する必要があります。
6. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released with its 'client identifier' or 'chaddr' and network address in the DHCPRELEASE message. If the client used a 'client identifier' when it obtained the lease, it MUST use the same 'client identifier' in the DHCPRELEASE message.
6.クライアントは、DHCPRELEASEメッセージをサーバーに送信することにより、ネットワークアドレスのリースを放棄することを選択できます。 クライアントは、DHCPRELEASEメッセージの「クライアント識別子」または「chaddr」とネットワークアドレスで、リリースするリースを識別します。 クライアントがリースを取得したときに「クライアント識別子」を使用した場合、DHCPRELEASEメッセージで同じ「クライアント識別子」を使用する必要があります。
Network administrators MUST only enable the use of Rapid Commit on a DHCP server if one of the following conditions is met:
ネットワーク管理者は、次の条件のいずれかが満たされている場合にのみ、DHCPサーバーでRapid Commitの使用を有効にする必要があります。
1. The server is the only server for the subnet.
1.サーバーは、サブネットの唯一のサーバーです。
2. When multiple servers are present, they may each commit a binding for all clients, and therefore each server must have sufficient addresses available.
2.複数のサーバーが存在する場合、それぞれがすべてのクライアントのバインディングをコミットする可能性があるため、各サーバーには十分なアドレスが必要です。
A server MAY allow configuration for a different (likely shorter) initial lease time for addresses assigned when Rapid Commit is used to expedite reclaiming addresses not used by clients.
サーバーは、Rapid Commitを使用してクライアントが使用していないアドレスの再利用を促進するときに割り当てられたアドレスの異なる（おそらく短い）初期リース時間の構成を許可する場合があります。
The Rapid Commit option is used to indicate the use of the two-message exchange for address assignment. The code for the Rapid Commit option is 80. The format of the option is:
Rapid Commitオプションは、アドレス割り当てに2メッセージ交換を使用することを示すために使用されます。 Rapid Commitオプションのコードは80です。オプションの形式は次のとおりです。
Code Len
+-----+-----+
| 80 | 0 |
+-----+-----+
A client MUST include this option in a DHCPDISCOVER message if the client is prepared to perform the DHCPDISCOVER-DHCPACK message exchange described earlier.
クライアントは、前述のDHCPDISCOVER-DHCPACKメッセージ交換を実行する準備ができている場合、DHCPDISCOVERメッセージにこのオプションを含める必要があります。
A server MUST include this option in a DHCPACK message sent in a response to a DHCPDISCOVER message when completing the DHCPDISCOVER-DHCPACK message exchange.
サーバーは、DHCPDISCOVER-DHCPACKメッセージ交換を完了するときに、DHCPDISCOVERメッセージへの応答で送信されるDHCPACKメッセージにこのオプションを含める必要があります。
IANA has assigned value 80 for the Rapid Commit option code in accordance with [RFC2939].
IANAは、[RFC2939]に従ってRapid Commitオプションコードに値80を割り当てています。
The concepts in this document do not significantly alter the security considerations for DHCP (see [RFC2131] and [RFC3118]). However, use of this option could expedite denial of service attacks by allowing a mischievous client to consume all available addresses more rapidly or to do so without requiring two-way communication (as injecting DHCPDISCOVER messages with the Rapid Commit option is sufficient to cause a server to allocate an address).
このドキュメントの概念は、DHCPのセキュリティに関する考慮事項を大幅に変更するものではありません（[RFC2131]および[RFC3118]を参照）。 ただし、このオプションを使用すると、悪意のあるクライアントがすべての使用可能なアドレスをより迅速に消費したり、双方向通信を必要とせずに消費したりすることにより、サービス拒否攻撃を促進できます（Rapid CommitオプションでDHCPDISCOVERメッセージを挿入するだけで、サーバーを引き起こすことができます） アドレスを割り当てる）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月。
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[RFC2939] Droms、R。、「新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン」、BCP 43、RFC 2939、2000年9月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R。、およびW. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、RFC 3315、2003年7月 。
Special thanks to Ted Lemon and Andre Kostur for their many valuable comments. Thanks to Ralph Droms for his review comments during WGLC. Thanks to Noh-Byung Park and Youngkeun Kim for their supports on this work.
貴重なコメントを寄せてくれたTed LemonとAndre Kosturに感謝します。 WGLCでのレビューコメントに対するRalph Dromsに感謝します。 この作業を支援してくださったノビョン・パークとキム・ヨングンに感謝します。
Particularly, the authors would like to acknowledge the implementation contributions by Minho Lee of SAMSUNG Electronics.
特に、作者は、SAMSUNG ElectronicsのMinho Leeによる実装の貢献に感謝します。
Authors' Addresses
著者のアドレス
Soohong Daniel Park Mobile Platform Laboratory SAMSUNG Electronics 416, Maetan-3dong, Yeongtong-Gu Suwon, Korea
Soohong Daniel ParkモバイルプラットフォームラボラトリSAMSUNG Electronics 416、Maetan-3dong、Maetan-3dong、Yeongtong-Gu Suwon、Korea
Phone: +82-31-200-4508 EMail: soohong.park@samsung.com
電話：+ 82-31-200-4508電子メール：soohong.park@samsung.com
Pyungsoo Kim Mobile Platform Laboratory SAMSUNG Electronics 416, Maetan-3dong, Yeongtong-Gu Suwon, Korea
Pyungsoo Kim Mobile Platform Laboratory SAMSUNG Electronics 416、Maetan-3dong、Maetan-3dong、Yeongtong-Gu Suwon、Korea
Phone: +82-31-200-4635 EMail: kimps@samsung.com
電話：+ 82-31-200-4635電子メール：kimps@samsung.com
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Bernie Volz Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、MA 01719 USA
Phone: +1-978-936-0382 EMail: volz@cisco.com
電話：+ 1-978-936-0382電子メール：volz@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。