[要約] RFC 4039は、DHCPv4のための高速コミットオプションについての規格です。このRFCの目的は、DHCPv4のプロセスを迅速化し、ネットワークの接続を迅速かつ効率的に確立することです。
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)
動的ホスト構成プロトコルバージョン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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントでは、通常の4メッセージ交換ではなく2メッセージ取引所を使用してIPアドレスと構成情報を取得するために、DHCPV6 Rapid Commitオプションをモデルにした新しい動的ホスト構成プロトコルバージョン4（DHCPV4）オプションを定義します。
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メッセージ交換によって提供される保護が必要ない場合があるため、より迅速にクライアントを構成することができます。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オプションを定義します。クライアントは、このオプションをDHCPDISCOVERメッセージに送信することにより、このオプションのサポートを宣伝します。次に、サーバーは、構成情報に基づいて2メッセージ交換を許可するかどうかを決定し、[RFC2131]で定義されているDHCPDISCOVERを処理するか、クライアントの構成情報をコミットし、ここで定義されている迅速なコミットオプションで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]に記載されているように解釈される場合、このドキュメントに表示される場合、キーワードは必要、必要は、推奨される、推奨する、推奨することはできません。
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.
[RFC2131]で説明されているように、迅速なコミットオプションを使用してDHCPDISCOVERを送信したクライアント。ただし、クライアントが迅速なコミットオプションを使用して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.
迅速なコミットオプションをサポートするサーバーは、迅速なコミットオプションと完全にコミットされたアドレスおよび構成情報を含むDHCPackを使用した迅速なコミットオプションを含むDHCPDISCOVERメッセージに応答する場合があります。サーバーは、他のメッセージに迅速なコミットオプションを含めてはなりません。
The Rapid Commit option MUST NOT appear in a Parameter Request List option [RFC2132].
迅速なコミットオプションは、パラメーターリクエストリストオプション[RFC2132]に表示されてはなりません。
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から改訂されています。これには、迅速なコミットオプションの処理が含まれます。
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メッセージまたは迅速なコミットオプションを使用したdhcpackメッセージのいずれかで応答できます（dhcpdiscoverに迅速なコミットオプションが含まれ、サーバーの構成ポリシーが迅速なコミットの使用を可能にする場合にのみ後者のみです）。これらには、「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（dhcpdiscoverでrapidコミットオプションが送信される場合）を受信します。DHCPACK（迅速なコミットオプションを使用）を受信した場合、提供された構成パラメーターが許容される場合、クライアントはすぐに以下のステップ5に進むことができます。クライアントは、複数の応答を待つことを選択できます。クライアントは、DHCPOFFERおよびDHCPACKメッセージで提供される構成パラメーターに基づいて、構成パラメーターを要求または受け入れるための1つのサーバーを選択します。クライアントがDHCPACKを選択した場合、ステップ5に進みます。それ以外の場合、クライアントは、選択したサーバーを示すために「サーバー識別子」オプションを含める必要があるDHCPRequestメッセージをブロードキャストします。メッセージには、目的の構成値を指定する他のオプションが含まれる場合があります。「要求されたIPアドレス」オプションは、サーバーからのDHCPOFFERメッセージの「Yiaddr」の値に設定する必要があります。このDHCPRequestメッセージは、DHCP/BOOTPリレーエージェントを介して放送され、リレーされます。BOOTPリレーエージェントがDHCPRequestメッセージを元のDHCPDISCOVERメッセージを受信した同じDHCPサーバーのセットに転送するようにするために、DHCPRequestメッセージはDHCPメッセージヘッダーの「Secs」フィールドで同じ値を使用し、同じIP 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など）、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サーバーでの迅速なコミットの使用を有効にする必要があります。
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.
サーバーは、クライアントが使用していない再生アドレスを迅速に使用して使用される場合に割り当てられたアドレスの別の（おそらく短い）初期リース時間の構成を許可する場合があります。
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:
迅速なコミットオプションは、アドレス割り当てのための2メッセージ交換の使用を示すために使用されます。迅速なコミットオプションのコードは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]に従って、迅速なコミットオプションコードに値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]を参照）。ただし、このオプションを使用すると、いたずらなクライアントが利用可能なすべてのアドレスをより迅速に消費できるようにすることで、サービス拒否攻撃を促進するか、双方向通信を必要とせずに行うことができます（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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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
スーホンダニエルパークモバイルプラットフォーム研究所Samsung Electronics 416、Maetan-3dong、Yeongtong-Gu Suwon、韓国
Phone: +82-31-200-4508
EMail: soohong.park@samsung.com
Pyungsoo Kim Mobile Platform Laboratory SAMSUNG Electronics 416, Maetan-3dong, Yeongtong-Gu Suwon, Korea
Pyungsookim Mobile Platform Laboratory Samsung Electronics 416、Maetan-3dong、Yeongtong-gu Suwon、韓国
Phone: +82-31-200-4635
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。