RFC4039 日本語訳
4039 Rapid Commit Option for the Dynamic Host Configuration Protocolversion 4 (DHCPv4). S. Park, P. Kim, B. Volz. March 2005. (Format: TXT=22297 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Park
Request for Comments: 4039 P. Kim
Category: Standards Track SAMSUNG Electronics
B. Volz
Cisco Systems
March 2005
コメントを求めるワーキンググループS.公園要求をネットワークでつないでください: 4039年のP.キムカテゴリ: 2005年の標準化過程三星のエレクトロニクスB.フォルツシスコシステムズの行進
Rapid Commit Option for the
Dynamic Host Configuration Protocol version 4 (DHCPv4)
Dynamic Host Configuration Protocolバージョン4のための急速なCommit Option(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントは普通であるよりむしろ2交換処理の4交換処理を使用することでIPアドレスと設定情報を得るためにDHCPv6 Rapid Commitオプションが似せられた新しいDynamic Host Configuration Protocolバージョン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
1. 序論… 2 2. 要件… 2 3. クライアント/サーバ操作… 2 3.1. 詳細な流れ… 3 3.2. 管理問題… 6 4. 急速である、オプション形式を遂行してください… 7 5. IANA問題… 7 6. セキュリティ問題… 7 7. 参照… 7 7.1. 標準の参照… 7 7.2. 有益な参照… 8 8. 承認… 8人の作者のアドレス… 9 完全な著作権宣言文… 10
Park, et al. Standards Track [Page 1] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[1ページ]DHCPv4 March 2005のためにオプションを遂行してください。
1. Introduction
1. 序論
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サーバ)を考慮します、クライアントが臨時に割り当てられたアドレスの1つを選んで、要求するまでアドレスがクライアントに臨時に割り当てられるだけであるとき。 したがって、1つのサーバだけが存在しているか、またはアドレスが豊富であるときに使用されるかもしれなくて、複数のサーバがクライアントのためにアドレスを遂行する2交換処理は問題ではありません。
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.
このドキュメントはいくつかの環境における速めるためには2交換処理のクライアント構成を開始するのに使用できるDHCPv6 Rapid Commitオプション[RFC3315]が似せられたDHCPv4のために新しいRapid Commitオプションを定義します。 クライアントは、DHCPDISCOVERメッセージでそれを送ることによって、このオプションのサポートの広告を出します。 サーバは、ここに定義されるように次に、設定情報に基づく2交換処理を許容するかどうか決定して、[RFC2131]で定義されるようにDHCPDISCOVERを扱うか、クライアントの設定情報を遂行して、またはRapid Commitオプションと共にDHCPACKメッセージを送るのに進むことができます。
2. Requirements
2. 要件
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]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
3. Client/Server Operations
3. クライアント/サーバ操作
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.
Rapid Commitオプションをサポートするクライアントが突然の出来事を使用するつもりであるなら、能力を遂行してください、そして、それは発信するというDHCPDISCOVERメッセージにRapid Commitオプションを含んでいます。 クライアントはいかなる他のメッセージでもそれを入れてはいけません。 そうするために構成されると、クライアントとサーバはこのオプションを使用するだけです。
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メッセージを受け取ります、それ。しかしながら、SHOULDはすぐに(追加DHCPOFFERかDHCPACKメッセージを待たないで)、DHCPACKを処理して、アドレスとそこに含まれた設定情報を使用します。
Park, et al. Standards Track [Page 2] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[2ページ]DHCPv4 March 2005のためにオプションを遂行してください。
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オプションを含んでいるDHCPACKとのRapid Commitオプションを含んで、アドレスと設定情報を完全に遂行したDHCPDISCOVERメッセージに反応するかもしれません。 サーバはいかなる他のメッセージにもRapid Commitオプションを含んではいけません。
The Rapid Commit option MUST NOT appear in a Parameter Request List option [RFC2132].
Rapid CommitオプションはParameter Request Listオプション[RFC2132]に現れてはいけません。
All other DHCP operations are as documented in [RFC2131].
他のすべてのDHCP操作が[RFC2131]に記録されるようにあります。
3.1. Detailed Flow
3.1. 詳細な流れ
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メッセージを放送します。 クライアントがRapid Commitがオプションであるとサポートして、突然の出来事を使用するつもりであるなら、能力を遂行してください、そして、それはDHCPDISCOVERメッセージにRapid Commitオプションを含んでいます。 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. 各サーバはRapid CommitオプションがあるDHCPOFFERメッセージか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.
新しいアドレスを割り当てるとき、サーバSHOULDは、提供されたネットワーク・アドレスが既に使用中でないことをチェックします。 例えば、サーバはICMP Echo Requestと共に提供されたアドレスを調べるかもしれません。
Park, et al. Standards Track [Page 3] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[3ページ]DHCPv4 March 2005のためにオプションを遂行してください。
Servers SHOULD be implemented so that network administrators
MAY choose to disable probes of newly allocated addresses.
サーバSHOULD、ネットワーク管理者が、新たに割り当てられたアドレスの徹底的調査を無効にするのを選ぶことができるように、実装されてください。
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)
サーバClient Server(選択されません)(選択されます)
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
v vに対して| | | | 初期化を始めます。| | | | | _____________/|\____________ | |/DHCPDISCOVER| DHCPDISCOVER\| | 急速で、公約してください。| 急速で、公約してください。| | | | 決定します。| 構成を決定します。| 構成| | 構成を遂行します。| 回答を集めます。| |\ | ____________/| | \________ | /DHCPACK| | DHCPOFFER\|急速であるのがある/は公約します。| | (捨てられます) | | | 初期設定完全です。| | | | . . . . . . | | | | 優雅な閉鎖| | | | | |\_____________ | | | DHCPRELEASE\| | | | | | リースを捨てます。| | | v vに対して
Figure 1 Timeline diagram when Rapid Commit is used
Rapid Commitが使用されているときTimelineが図解する図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
3. クライアントは1つ以上のサーバから1DHCPOFFERかDHCPACK(DHCPDISCOVERでRapid Commitオプションを送るなら)メッセージを受け取ります。 DHCPACK(Rapid Commitオプションがある)が受け取られているなら、提供された設定パラメータが許容できるなら、クライアントはすぐに、下でのステップ5に達するかもしれません。 クライアントは、複数の応答を待つのを選ぶかもしれません。 クライアントが1つのサーバを選ぶ、どれを要求するか、または受け入れるか。
Park, et al. Standards Track [Page 4] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[4ページ]DHCPv4 March 2005のためにオプションを遂行してください。
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.
DHCPOFFERとDHCPACKメッセージで提供された設定パラメータに基づいた設定パラメータ。 クライアントがDHCPACKを選ぶなら、それはステップ5に達します。 さもなければ、クライアントはそれがどのサーバを選択したかを示すために'サーバ識別子'オプションを含まなければならないDHCPREQUESTメッセージを放送して、メッセージは必要な構成値を指定する別の選択肢を含むかもしれません。 '要求されたIPアドレス'オプションはサーバからのDHCPOFFERメッセージの'yiaddr'の値へのセットであるに違いありません。このDHCPREQUESTメッセージは、DHCP/BOOTP中継エージェントを通して放送されて、リレーされます。 どんなBOOTP中継エージェントもオリジナルのDHCPDISCOVERメッセージを受け取った同じセットのDHCPサーバにDHCPREQUESTメッセージを転送するのを確実にするのを助けるために、DHCPREQUESTメッセージをDHCPメッセージヘッダーの'secs'分野で同じ値を使用して、オリジナルのDHCPDISCOVERメッセージのように同じIP放送演説に送らなければなりません。 そして、クライアント回のアウト、クライアントが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メッセージSHOULD NOTのどんな設定パラメータもクライアントが応じている以前のDHCPOFFERメッセージのそれらと衝突します。 サーバSHOULD NOTはここに提供されたネットワーク・アドレスをチェックします。 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メッセージを満たすことができないなら(例えば要求されたネットワーク・アドレスを割り当てました)、サーバSHOULDは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メッセージを全く受け取らないなら、サーバSHOULDは利用可能であるとして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
5. クライアントは設定パラメータでDHCPACKメッセージを受け取ります。 クライアントSHOULDはパラメタ(例えば、割り当てられたネットワーク・アドレスのためのARP)に最終的なチェックを実行します、そして、それはリースの持続時間がDHCPACKで指定したことに注意します。
Park, et al. Standards Track [Page 5] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[5ページ]DHCPv4 March 2005のためにオプションを遂行してください。
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.
メッセージ。 ここに、クライアントは構成されます。 クライアントがそれを検出するなら、アドレスは既に使用中です、そして、(例えば、ARPの使用による)クライアントはDHCPDECLINEメッセージをサーバに送らなければなりません、そして、それはコンフィギュレーションプロセスを再開します。 コンフィギュレーションプロセスを再開する前に、クライアントSHOULDは、ループの場合に過度のネットワークトラフィックを避けるのを最低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で説明されるように再送するクライアントは4回DHCPREQUESTメッセージを再送するかもしれません、60秒の総遅れのために、初期化手順を再開する前に。 再送信アルゴリズムを使った後にクライアントがDHCPACKもDHCPNAKメッセージも受け取らないなら、クライアントは、INIT状態に先祖帰りをして、初期化プロセスを再開します。 クライアントSHOULDは初期化プロセスが失敗して、再開しているようにユーザに通知します。
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メッセージをサーバに送ることによってリースを放棄するのを選ぶかもしれません。クライアントは、その'クライアント識別子'か'chaddr'とネットワーク・アドレスがDHCPRELEASEメッセージにある状態でリリースされるためにリースを特定します。 リースを得たとき、クライアントが'クライアント識別子'を使用したなら、それはDHCPRELEASEメッセージの同じ'クライアント識別子'を使用しなければなりません。
3.2. Administrative Considerations
3.2. 管理問題
Network administrators MUST only enable the use of Rapid Commit on a DHCP server if one of the following conditions is met:
以下の条件の1つが会われるなら、ネットワーク管理者は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. 複数のサーバが存在しているとき、すべてのクライアントのためにそれぞれ結合を遂行するかもしれません、そして、したがって、各サーバには、利用可能な十分なアドレスがなければなりません。
Park, et al. Standards Track [Page 6] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[6ページ]DHCPv4 March 2005のためにオプションを遂行してください。
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がクライアントによって使用されなかったアドレスを取り戻すのにおいて速めるのにおいて使用されているとき割り当てられたアドレスのためのいろいろな(おそらくより短い)初期のリース時間構成を許すかもしれません。
4. Rapid Commit Option Format
4. 急速である、オプション形式を遂行してください。
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 |
+-----+-----+
コードレン+-----+-----+ | 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メッセージにこのオプションを含まなければなりません。
5. IANA Considerations
5. IANA問題
IANA has assigned value 80 for the Rapid Commit option code in accordance with [RFC2939].
[RFC2939]に従って、IANAはRapid Commitオプションコードのために値80を割り当てました。
6. Security Considerations
6. セキュリティ問題
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メッセージにRapid Commitオプションを注射するのがサーバがアドレスを割り当てることを引き起こすために十分であるときに)。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
Park, et al. Standards Track [Page 7] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[7ページ]DHCPv4 March 2005のためにオプションを遂行してください。
7.2. Informative References
7.2. 有益な参照
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2132] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、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ガイドラインとメッセージはタイプします」、BCP43、RFC2939、2000年9月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3118] DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、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.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
8. Acknowledgements
8. 承認
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.
テッドLemonとアンドレKosturのおかげで、彼らの多くの貴重なコメントにおいて、特別です。 おかげに、彼のレビューのためのラルフDromsはWGLCの間、コメントします。 おかげに、これにおける彼らのサポートのためのNoh-Byung ParkとYoungkeunキムは働いています。
Particularly, the authors would like to acknowledge the implementation contributions by Minho Lee of SAMSUNG Electronics.
特に、作者は三星Electronicsのミニョリーによる実装貢献を承諾したがっています。
Park, et al. Standards Track [Page 8] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[8ページ]DHCPv4 March 2005のためにオプションを遂行してください。
Authors' Addresses
作者のアドレス
Soohong Daniel Park Mobile Platform Laboratory SAMSUNG Electronics 416, Maetan-3dong, Yeongtong-Gu Suwon, Korea
モバイルプラットホーム研究所三星エレクトロニクス416、Maetan-3dong、Yeongtong-Gu水原、SoohongダニエルPark韓国
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キムモバイルのプラットホーム研究所三星エレクトロニクス416、Maetan-3dong、Yeongtong-Gu水原、韓国
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
バーニーフォルツシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA01719米国
Phone: +1-978-936-0382 EMail: volz@cisco.com
以下に電話をしてください。 +1-978-936-0382 メールしてください: volz@cisco.com
Park, et al. Standards Track [Page 9] RFC 4039 Rapid Commit Option for DHCPv4 March 2005
公園、他 規格が急速な状態でRFC4039を追跡する、[9ページ]DHCPv4 March 2005のためにオプションを遂行してください。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Park, et al. Standards Track [Page 10]
公園、他 標準化過程[10ページ]
一覧
スポンサーリンク
