Network Working Group B. Aboba
Request for Comments: 4436 Microsoft Corporation
Category: Standards Track J. Carlson
Sun Microsystems
S. Cheshire
Apple Computer
March 2006
Detecting Network Attachment in IPv4 (DNAv4)
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment.
ネットワーク間の移動を検出し、取得するために（または使用を継続する）のに必要な時間は、IPv4設定が結合点間を移動中の全ハンドオーバ待ち時間の割合として重要であり得ます。この文書では、点間の移動におけるハンドオーバ遅延を減らすために、ARP、DHCP、およびIPv4のリンクローカルアドレス、IPv4の検出ネットワーク接続（DNAv4）として知られている手順のセットをサポートするホストの配備の経験から、合成します添付。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Applicability ..............................................2
1.2. Requirements ...............................................5
1.3. Terminology ................................................5
2. Overview ........................................................6
2.1. Reachability Test ..........................................8
2.1.1. Packet Format .......................................9
2.2. IPv4 Address Acquisition ..................................10
2.3. IPv4 Link-Local Addresses .................................11
2.4. Manually Assigned Addresses ...............................12
3. Security Considerations ........................................12
4. References .....................................................13
4.1. Normative References ......................................13
4.2. Informative References ....................................13
5. Acknowledgements ...............................................14
The time required to detect movement between networks and to obtain (or to continue to use) an operable IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment.
ネットワーク間の移動を検出し、取得するために（または使用を継続する）のに必要な時間に動作可能なIPv4の構成は、結合点間を移動中の全ハンドオーバ待ち時間の割合として重要であり得ます。
This document synthesizes, from experience in the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local addresses [RFC3927], a set of steps known as Detecting Network Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of re-attachment to a network that one has been connected to previously by attempting to re-use a previous (but still valid) configuration, reducing the re-attachment time on LANs to a few milliseconds. Since this procedure is dependent on the ARP protocol, it is not suitable for use on media that do not support ARP.
この文書では、ARP [RFC826]、DHCP [RFC2131]、およびIPv4のリンクローカルアドレス[RFC3927]、IPv4の（DNAv4）のためのネットワーク接続検出として知られている一連のステップをサポートしているホストの展開の経験から、合成します。 DNAv4は1つが、以前の（まだ有効な）構成を再使用しようと数ミリ秒までのLAN上の再付着の時間を短縮することにより、以前に接続されたネットワークへの再接続の（共通）の場合を最適化します。この手順は、ARPプロトコルに依存しているので、それはARPをサポートしていないメディア上での使用には適していません。
DHCP is an effective and widely adopted mechanism for a host to obtain an IP address for use on a particular network link, or to re-validate a previously obtained address via DHCP's INIT-REBOOT mechanism [RFC2131].
DHCPは、特定のネットワークリンク上で使用するためのIPアドレスを取得する、またはDHCPのINIT-REBOOT機構[RFC2131]を介して再検証以前に取得したアドレスにするホストのための効果的かつ広く採用されている機構です。
When obtaining a new address, DHCP specifies that the client SHOULD use ARP to verify that the offered address is not already in use. The process of address conflict detection [ACD] can take as much as seven seconds. In principle, this time interval could be shortened, with the obvious trade-off: the less time a host spends waiting to see if another host is already using its intended address, the greater the risk of inadvertent address conflicts.
新しいアドレスを取得する場合、DHCPは、クライアントが提供されたアドレスが使用されていないことを確認するためにARPを使用することを指定します。アドレス競合の検出[ACD]のプロセスは7秒ほどに取ることができます。原則的には、この時間間隔は、明らかなトレードオフで、短縮することができます。ホストが別のホストがすでに大きい、不注意によるアドレスの競合のリスクをその意図されたアドレスを使用しているかどうかを確認するために待機して過ごす時間が少ないです。
Where the client successfully re-validates a previously obtained address using the INIT-REBOOT mechanism, the DHCP specification does not require the client to perform address conflict detection, so this seven-second delay does not apply. However, the DHCP server may be slow to respond or may be down and not responding at all, so hosts could benefit from having an alternative way to quickly determine that a previously obtained address is valid for use on this particular link.
クライアントが正常にINIT-REBOOTメカニズムを使用して、以前に取得したアドレスを再検証する場合は、DHCP仕様は、アドレス競合検出を実行するためにクライアントを必要としないので、この7秒の遅延は適用されません。ただし、DHCPサーバーが応答が遅くなることがありますか、ホストがすぐに以前に取得したアドレスが、この特定のリンク上で使用するために有効であることを決定する別の方法を持っていることから利益を得ることができるので、全く応答がダウンしていないかもしれません。
When the client moves between networks, the address re-validation attempt may be unsuccessful; a DHCPNAK may be received in response to a DHCPREQUEST, causing the client to restart the configuration process by moving to the INIT state. If an address previously obtained on the new network is still operable, DNAv4 enables the host to confirm the new configuration quickly, bypassing restart of the configuration process and conflict detection.
クライアントがネットワーク間を移動すると、アドレスの再検証試行が失敗であってもよく、 DHCPNAKクライアントはINIT状態に移動させることにより、構成プロセスを再起動させる、DHCPREQUESTに応答して受信されてもよいです。以前に新しいネットワーク上で取得したアドレスがまだ動作可能である場合、DNAv4は、構成プロセスの再起動と競合検出をバイパスして、迅速に新しい設定を確認するホストを可能にします。
The alternative mechanism specified by this document applies when a host has a previously allocated DHCP address, which was not returned to the DHCP server via a DHCPRELEASE message, and which still has time remaining on its lease. In this case, the host may determine whether it has re-attached to the logical link where this address is valid for use, by sending a unicast ARP Request packet to a router previously known for that link (or, in the case of a link with more than one router, by sending one or more unicast ARP Request packets to one or more of those routers).
ホストはDHCPRELEASEメッセージを介してDHCPサーバに戻され、これはまだそのリースの残り時間を持っていなかった以前に割り当てられたDHCPアドレスを有する場合、この文書で指定された代替メカニズムが適用されます。この場合、ホストは、リンクの場合には、以前にそのリンクのために知られてルータにユニキャストARP要求パケットを送信（またはすることで、このアドレスが使用のために有効である論理リンクに再付着しているか否かを判断しますこれらのルータの1つまたは複数）への1つの以上のユニキャストARP要求パケットを送信することにより、複数のルータ、と。
The use of unicast ARP has a number of benefits. One benefit is that unicast packets impose less burden on the network than broadcast packets, particularly on 802.11 networks where broadcast packets may be sent at rates as low as 1 Mb/sec. Another benefit is that if the host is not on the link it hoped to find itself on, a broadcast ARP Request could pollute the ARP caches of peers on that link. When using private addresses [RFC1918], another device could be legitimately using the same address, and a broadcast ARP Request could disrupt its communications, causing TCP connections to be broken, and similar problems. Also, using a unicast ARP packet addressed to the MAC address of the router the host is expecting to find means that if the host is not on the expected link there will be no device with that MAC address, and the ARP packet will harmlessly disappear into the void without doing any damage.
ユニキャストARPの使用は多くの利点があります。 1つの利点は、ユニキャストパケットは、特に、ブロードキャストパケットが1メガビット/秒という低いレートで送信されてもよい802.11ネットワーク上で、ブロードキャストパケットより、ネットワーク上の少ない負担を課すことです。もう一つの利点は、ホストが、それは自分自身を上見つけることを望んだのリンク上にない場合は、ブロードキャストARP要求がそのリンク上のピアのARPキャッシュを汚染可能性があることです。プライベートアドレス[RFC1918]を使用する場合は、別のデバイスは、合法的に同じアドレスを使用して、ブロードキャストARP要求がその通信が中断される可能性があり、TCP接続が切断される原因、および同様の問題がある可能性があります。また、ユニキャストARPパケットを使用すると、ホストが見つけることを期待しているルータのMACアドレス宛のホストが期待されるリンク上にない場合、そのMACアドレスを持つ何のデバイスは存在しないだろうことを意味し、ARPパケットを無害に消えますすべてのダメージを与えることなしに、ボイド。
These issues that define the applicability of DNAv4 lead us to a number of conclusions:
DNAv4の適用性を定義するこれらの問題は、結論の数に私たちを導きます：
o DNAv4 is a performance optimization. Its purpose is to speed up a process that may require as much as a few hundred milliseconds (DHCP INIT-REBOOT), as well as to reduce multi-second conflict detection delays when a host changes networks.
O DNAv4は、パフォーマンスの最適化です。その目的は、のように数百ミリ秒（DHCP INIT-REBOOT）ほど、と同様に、ホストがネットワークを変更したときに、マルチ秒競合検出の遅延を減少させることが必要になることがあり、プロセスをスピードアップすることです。
o As a performance optimization, it must not sacrifice correctness. In other words, false positives are not acceptable. DNAv4 must not conclude that a host has returned to a previously visited link where it has an operable IP address if this is not in fact the case.
Oパフォーマンスを最適化するため、それは正確さを犠牲にしてはなりません。言い換えれば、偽陽性が認められません。 DNAv4が、これは事実ではない場合、ホストは、それが作動可能なIPアドレスを持っている、以前に訪れたリンクに戻ってきたと結論付けてはいけません。
o As a performance optimization, false negatives are acceptable. It is not an absolute requirement that this optimization correctly recognize a previously visited link in all possible cases. For example, if a router ignores unicast ARP Requests, then DNAv4 will not be able to detect that it has returned to the same link in the future. This is acceptable because the host still operates correctly as it did without DNAv4, just without the performance benefit. Users and network operators who desire the performance improvement offered by DNAv4 can upgrade their routers to support DNAv4.
パフォーマンスの最適化としてO、偽陰性が許容されています。それは、この最適化が正常に可能なすべてのケースで、以前に訪問したリンクを認識絶対条件ではありません。ルータは、ユニキャストARP要求を無視した場合、その後、DNAv4は、それが将来的に同じリンクに戻ったことを検出することができません。それはDNAv4せずに行ったように、ホストがまだちょうどパフォーマンス上の利点せず、正常に動作するので、これは許容可能です。 DNAv4が提供するパフォーマンスの向上を望むユーザーとネットワークオペレータはDNAv4をサポートするためにルータをアップグレードすることができます。
o As a performance optimization, where DNAv4 fails to provide a benefit, it should add little or no delay compared to today's DHCP processing. In practice, this implies that DHCP processing needs to proceed in parallel. Waiting for DNAv4 to fail before beginning DHCP processing can greatly increase total processing time, the opposite of the desired effect.
O DNAv4が利益を提供するために失敗したパフォーマンスの最適化、として、それが今日のDHCP処理に比べてほとんど、あるいはまったく遅れを追加する必要があります。実際には、これは、DHCP処理が並行して進める必要があることを意味します。 DNAv4が失敗するためにDHCP処理を開始する前に待って大幅に、所望の効果の反対を全体の処理時間を増やすことができます。
o Trials are inexpensive. DNAv4 performs its checks using small unicast packets. An IPv4 ARP packet on Ethernet is just 42 octets, including the Ethernet header. This means that the cost of an unsuccessful attempt is small, whereas the cost of a missed opportunity (having the right address available as a candidate and choosing not to try it for some reason) is large. As a result, the best strategy is often to try all available candidate configurations, rather than try to determine which candidates, if any, may be correct for this link, based on heuristics or hints. For a heuristic to offer the prospect of being a potentially useful way to eliminate inappropriate configurations from the candidate list, that heuristic has to (a) be fast and inexpensive to compute, as compared to sending a 42-octet unicast packet, and (b) have high probability of not falsely eliminating a candidate configuration that could be found to be the correct one.
Oトライアルは安価です。 DNAv4は、小さなユニキャストパケットを使用してチェックを行います。イーサネット上のIPv4のARPパケットは、イーサネットヘッダーを含むちょうど42オクテットです。これは、機会を逃し（候補として利用できる権利のアドレスを有し、かつ、何らかの理由でそれを試していない選択）のコストが大きいのに対し、失敗した試行のコストは、小さいことを意味します。その結果、最善の戦略は、利用可能なすべての候補の設定を試してみてください、というよりも、もしあれば、経験則やヒントをもとに、このリンクのために正しいとすることができる候補者決定しようとすることが多いです。候補リストから不適切な構成を排除するための潜在的に有用な方法であるという見通しを提供するためのヒューリスティックについては、そのヒューリスティックは、（a）は、42オクテットのユニキャストパケットを送信すること、および（bに比べて、計算するための高速かつ安価でなければなりません）誤って正しいものであることが判明することができる候補構成を排除しない可能性が高いです。
o Time is limited. If DNAv4 is to be effective in enabling low latency handoffs, it needs to complete in less than 10 ms. This implies that any heuristic used to eliminate candidate configurations needs to take at most a few milliseconds to compute. This does not leave much room for heuristics based on observation of link-layer or Internet-layer traffic.
O時間は限られています。 DNAv4は、低遅延ハンドオフを可能にするのに有効であることがあるならば、それは10ミリ秒未満で完了する必要があります。これは、候補者の構成を排除するために使用される任意のヒューリスティックを計算するために、最も数ミリ秒で行う必要があることを意味します。これは、リンク層またはインターネット層のトラフィックの観測に基づくヒューリスティックの余地を残していません。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります「要求レベルを示すためのRFCsにおける使用のためのキーワード」[RFC2119]に記載されているように解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています：
ar$sha ARP packet field: Sender Hardware Address [RFC826]. The hardware (MAC) address of the originator of an ARP packet.
ARの$舎ARPパケットフィールド：送信者のハードウェアアドレス[RFC826]。 ARPパケットの発信元のハードウェア（MAC）アドレス。
ar$spa ARP packet field: Sender Protocol Address [RFC826]. For IP Address Resolution, this is the IPv4 address of the sender of the ARP packet.
AR $スパARPパケットフィールド：送信者のプロトコルアドレス[RFC826]。 IPアドレス解決のために、これは、ARPパケットの送信元のIPv4アドレスです。
ar$tha ARP packet field: Target Hardware Address [RFC826]. The hardware (MAC) address of the target of an ARP packet.
AR $ thaのARPパケットフィールド：ターゲットハードウェアアドレス[RFC826]。 ARPパケットの対象のハードウェア（MAC）アドレス。
ar$tpa ARP packet field: Target Protocol Address [RFC826]. For IPv4 Address Resolution, the IPv4 address for which one desires to know the hardware address.
AR $ TPA ARPパケットフィールド：対象プロトコル[RFC826]アドレス。 IPv4アドレスの解決のために、IPv4アドレスが対象の一つは、ハードウェア・アドレスを知りたいです。
DHCP client A DHCP client or "client" is an Internet host using the Dynamic Host Configuration Protocol (DHCP) [RFC2131] to obtain configuration parameters, such as a network address.
DHCPクライアントA DHCPクライアントまたは「クライアント」は、ネットワークアドレスなどの設定パラメータを取得するために、動的ホスト構成プロトコル（DHCP）[RFC2131]を使用してインターネットホストです。
DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.
DHCPサーバDHCPサーバまたは「サーバ」DHCPクライアントに設定パラメータを返すインターネットホストです。
Link A communication facility or medium over which network nodes can communicate. Each link is associated with a minimum of two endpoints. Each link endpoint has a unique link-layer identifier.
ネットワークノードが通信を行う通信設備または媒体をリンクします。各リンクは、2つのエンドポイントの最小値と関連しています。各リンクのエンドポイントは、ユニークなリンク層識別子を持っています。
Link Down An event provided by the link layer that signifies a state change associated with the interface's no longer being capable of communicating data frames; transient periods of high frame loss are not sufficient. DNAv4 does not utilize "Link Down" indications.
インターフェイスのは、もはやデータフレームを通信することが可能であることに関連した状態の変化を意味するリンク層により提供されるイベントをリンクダウン。高フレーム損失の過渡期間は十分ではありません。 DNAv4は「リンクダウン」表示を利用していません。
Link Layer Conceptual layer of control or processing logic that is responsible for maintaining control of the data link. The data link layer functions provide an interface between the higher-layer logic and the data link. The link layer is the layer immediately below IP.
制御やデータリンクの制御を維持する責任がある処理ロジックのリンク層の概念層。データリンク層の機能は、上位レイヤロジックとデータ・リンクとの間のインタフェースを提供します。リンク層は、直ちにIP下の層です。
Link Up An event provided by the link layer that signifies a state change associated with the interface's becoming capable of communicating data frames.
インターフェースのは、データフレームを通信することが可能になってきてと関連する状態変化を意味し、リンク層が提供するイベントをアップリンクします。
Point of Attachment The link endpoint on the link to which the host is currently connected.
結合点ホストが現在接続しているリンク上のリンクのエンドポイント。
Routable address In this specification, the term "routable address" refers to any unicast IPv4 address other than an IPv4 Link-Local address. This includes private addresses as specified in "Address Allocation for Private Internets" [RFC1918].
本明細書でルーティング可能なアドレスは、用語「ルーティング可能なアドレスは、」IPv4のリンクローカルアドレス以外のユニキャストIPv4アドレスを指します。 「個人的なインターネットのための配分」[RFC1918]で指定されたように、これはプライベートアドレスを含んでいます。
Operable address In this specification, the term "operable address" refers either to a static IPv4 address, or an address assigned via DHCPv4 that has not been returned to the DHCP server via a DHCP RELEASE message, and whose lease has not yet expired.
本明細書において動作可能なアドレス、用語「作動可能なアドレスは」静的IPv4アドレス、またはDHCP RELEASEメッセージを介してDHCPサーバに返されていないのDHCPv4を介して割り当てられたアドレスのいずれかを参照し、そのリースまだ満了していません。
On connecting to a new point of attachment, the host responds to a "Link Up" indication from the link layer by carrying out the DNAv4 procedure.
新しい接続点に接続するには、ホストはDNAv4手続きを行うことにより、リンク層からの「リンクアップ」表示に応答します。
For each network that it connects to, it is assumed that the host saves the following parameters to stable storage:
それに接続する各ネットワークのために、ホストは、安定したストレージに以下のパラメータを保存しているものとします。
[1] The IPv4 and MAC address of one or more test nodes on the network.
[1]ネットワーク上の1つ以上のテストノードのIPv4アドレスとMACアドレスを。
[2] The IPv4 configuration parameters, including the DHCP client identifier, assigned address, and lease expiration time.
[2] DHCPクライアント識別子、割り当てられたアドレス、リース満了時間を含むIPv4の設定パラメータ、。
From the set of networks that have operable IPv4 addresses associated with them, the host selects a subset and attempts to confirm the configuration for each network, using the reachability test described in Section 2.1.
それらに関連するように動作可能なIPv4アドレスを有するネットワークのセットから、ホストは、サブセットを選択し、セクション2.1に記載の到達可能性テストを使用して、各ネットワークの設定を確認しようと試みます。
For a particular network, the host SHOULD use the addresses of local routers (preferably default gateways) as its test nodes. If more than one address is known, those addresses may be tested in parallel. In order to ensure configuration validity, the host SHOULD only configure routes for which the next hop address passes the reachability test. Other routes SHOULD be re-learned.
特定のネットワークのために、ホストは、そのテスト・ノードとしてローカルルータ（好ましくはデフォルトゲートウェイ）のアドレスを使用すべきです。複数のアドレスがわかっている場合は、これらのアドレスは、並行して試験することができます。コンフィギュレーション有効性を確保するために、ホストは、次ホップアドレスが到達可能性テストを通過するための経路を設定する必要があります。他の経路を再学習されるべきである（SHOULD）。
DNAv4 does not significantly increase the likelihood of an address conflict. The reachability test is only carried out for a network when the host has previously completed conflict detection as recommended in Section 2.2 of the DHCP specification [RFC2131] and obtained an operable IPv4 configuration on that network. Restrictions on sending ARP Requests and Responses are described in Section 2.1.1.
DNAv4が大幅アドレスの競合の可能性を増加させません。ホストが以前にDHCP仕様[RFC2131]のセクション2.2に推奨されるように、競合検出を完了し、そのネットワーク上で動作可能なIPv4の設定を取得したときに到達可能性テストは、唯一のネットワークのために行われます。 ARP要求および応答を送信の制限事項は、セクション2.1.1で説明されています。
One case where DNAv4 does increase the likelihood of an address conflict is when:
ときDNAv4がアドレス競合の可能性を高めるないものの場合は、次のとおりです。
o a DHCP server hands out an address lease,
、DHCPサーバーがアドレスのリースを配るO
o the host with that lease leaves the network,
そのリースを持つホストがネットワークを離れるO、
o the DHCP server is power-cycled or crashes and is rebooted,
O DHCPサーバーの電源を入れ直さまたはクラッシュし、再起動され、
o the DHCP server, having failed to save leases to stable storage, assigns that same address to another host, and
DHCPサーバO、安定したストレージにリースを保存するために失敗した、別のホストに同じアドレスを割り当て、
o the first host returns and, having a still-valid lease with time remaining, proceeds to use its assigned address, conflicting with the new host that is now using that same address.
残り時間にまだ有効なリースを有する第一のホスト戻ると、O、今では同じアドレスを使用している新しいホストと競合し、その割り当てられたアドレスを使用するように進みます。
While Section 4 of the DHCP specification [RFC2131] assumes that DHCP servers save their leases in persistent storage, almost no consumer-grade NAT gateway does so. Short DHCP lease lifetimes can mitigate this risk, though this also limits the operable candidate configurations available for DNAv4 to try.
DHCP仕様[RFC2131]のセクション4は、DHCPサーバは、永続的なストレージで自分のリースを保存することを前提としていますが、ほとんどの消費者グレードNATゲートウェイはそうしません。これはまた、DNAv4がしようとするのに利用できる操作可能な候補の設定を制限しても、短いDHCPリース寿命は、このリスクを軽減することができます。
The host skips the reachability test for a network if any of the following conditions are true:
ホストは、以下の条件のいずれかに該当する場合、ネットワークの到達可能性テストをスキップします：
[a] The host does not have an operable routable IPv4 address on that network. In this case, the reachability test cannot confirm that the host has an operable routable IPv4 address, so completing the reachability test would serve no purpose.
[A]ホストは、そのネットワーク上で動作可能なルーティング可能なIPv4アドレスを持っていません。この場合には、到達可能性テストは、ホストが動作可能なルーティング可能なIPv4アドレスを持っていることを確認することができないので、到達可能性テストを完了しても目的を果たしていないことになります。
[b] The host does not know the addresses of any test nodes on that network. In this case, insufficient information is available to carry out the reachability test.
[B]ホストは、ネットワーク上の任意のテストノードのアドレスを知りません。この場合には、十分な情報が到達可能性テストを実行するために利用可能です。
[c] If DHCP authentication [RFC3118] is configured. The reachability test utilizes ARP, which is insecure. Hosts that have been configured to attempt DHCP authentication SHOULD NOT utilize the reachability test. Security issues are discussed in Section 4.
[C] DHCP認証[RFC3118]が設定されている場合。到達可能性テストは安全ではないARPを利用します。 DHCP認証を試みるように設定されているホストは到達可能性テストを利用すべきではありません。セキュリティの問題は、第4節で議論されています。
[d] The contents of the DHCP Client Identifier option that the client used to obtain the candidate configuration is different from the DHCP Client Identifier option the client intends to present on the interface in question. In this case, it is anticipated that a DHCP server would NAK any request made by the client to acquire or extend the candidate configuration, since the two interfaces are presenting differing identities.
[D]の候補コンフィギュレーションを取得するために使用されるクライアントは、クライアントが当該界面に存在しようとDHCPクライアント識別子オプションは異なるDHCPクライアント識別子オプションの内容。この場合、二つのインターフェースは、異なるIDを提示しているので、DHCPサーバは、取得または候補構成を拡張するためにクライアントによって行われた要求をNAKことが予想されます。
If the reachability test is successful, the host SHOULD continue to use the operable routable IPv4 address associated with the confirmed network, without needing to re-acquire it. Once a valid reachability test response is received, validation is complete, and additional responses should be discarded.
到達可能性テストが成功した場合、ホストはそれを再取得することなく、確認ネットワークに関連付けられた動作可能なルーティング可能なIPv4アドレスを使用し続けるべきです。有効な到達可能性テスト応答が受信されると、検証が完了し、追加の応答が破棄されなければなりません。
If a DHCPv4 client is operational, it is RECOMMENDED that the host attempt to obtain IPv4 configuration via DHCPv4 in parallel with the reachability tests, with the host using the first answer returned. This ensures that the DNAv4 procedure will not result in additional delay in the case where reachability tests fail, or where sending a DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2 and 4.3.2 of the DHCP specification [RFC2131], completes more quickly than the reachability tests.
DHCPv4クライアントが動作している場合、最初の答えを使用してホストと到達可能性のテストと並行してのDHCPv4経由のIPv4設定を取得するためにホストの試みが、返さことが推奨されます。これはDNAv4手順は到達可能性テストが失敗した場合には、追加の遅延を生じないことを保証する、又はここでセクション3.2とDHCP仕様[RFC2131]の4.3.2に記載されているように、INIT-REBOOT状態からDHCPREQUESTを送信し、完了しますより迅速に到達可能性テストより。
In situations where both DNAv4 and DHCP are used on the same link, it is possible that the reachability test will complete successfully, and then DHCP will complete later with a different result. If this happens, the implementation SHOULD abandon the reachability test results and use the DHCP result instead, unless the address confirmed via the reachability test has been manually assigned (see Section 2.4).
DNAv4とDHCPの両方が同じリンク上で使用されている状況では、到達可能性テストが正常に完了し、その後DHCPが異なる結果と、後に完成する可能性があります。到達可能性テストを経て確認された住所が手動で割り当てられていない限り、この問題が発生した場合、実装は到達可能性テストの結果を放棄し、代わりにDHCP結果を使用すべきである、（2.4節を参照してください）。
Where the reachability test does not return an answer, this is typically because the host is not attached to the network whose configuration is being tested. In such circumstances, there is typically little value in aggressively retransmitting reachability tests that do not elicit a response.
到達可能性テストが答えを返さない場合は、ホストがその構成をテストされているネットワークに接続されていないので、これは一般的です。このような状況では、積極的な応答を誘発しない到達可能性テストを再送信中に典型的にはほとんど価値があります。
Where DNAv4 and DHCP are tried in parallel, one strategy is to forsake reachability test retransmissions and to allow only the DHCP client to retransmit. In order to reduce competition between DNAv4 and DHCP retransmissions, a DNAv4 implementation that retransmits may utilize the retransmission strategy described in Section 4.1 of the DHCP specification [RFC2131], scheduling DNAv4 retransmissions between DHCP retransmissions.
DNAv4とDHCPを並列に試されている場合、1つの戦略は、到達可能性テストの再送信を見捨てするだけDHCPクライアントが再送信できるようにすることです。 DNAv4とDHCP再送信との間の競合を低減するために、再送DNAv4実装は、DHCP再送信間DNAv4再送をスケジューリング、DHCP仕様[RFC2131]のセクション4.1に記載の再送戦略を利用することができます。
If a response is received to any reachability test or DHCP message, pending retransmissions are canceled. It is RECOMMENDED that a DNAv4 implementation retransmit no more than twice. To provide damping in the case of spurious "Link Up" indications, it is RECOMMENDED that the DNAv4 procedure be carried out no more than once a second.
応答は、任意の到達可能性テストやDHCPメッセージに受信された場合、保留中の再送信はキャンセルされます。これは、2倍を超えないDNAv4実装再送ことが推奨されます。スプリアス「リンクアップ」表示の場合には、減衰を提供するためには、DNAv4手順はありません複数回秒を行うことをお勧めします。
The reachability test is performed by sending a unicast ARP Request. The host MUST set the target protocol address (ar$tpa) to the IPv4 address of the node being tested, and the sender protocol address field (ar$spa) to its own candidate IPv4 address. The ARP Request MUST use the host MAC address as the source, and the test node MAC address as the destination. The host includes its MAC address in the sender hardware address field (ar$sha) and sets the target hardware address field (ar$tha) to 0.
到達可能性テストは、ユニキャストARP要求を送信することによって行われます。ホストは、独自候補のIPv4アドレスにテストされているノードのIPv4アドレスにターゲットプロトコルアドレス（ARます$ TPA）を設定し、送信者のプロトコルアドレスフィールド（ARの$スパ）しなければなりません。 ARP要求は、送信元であるホストのMACアドレス、及び宛先としてテストノードのMACアドレスを使用しなければなりません。ホストは、送信者のハードウェアアドレスフィールド（ARます$ SHA）でのMACアドレスが含まれており、0にターゲットハードウェアアドレスフィールド（ARます$ THA）を設定します。
If a valid ARP Reply is received, the MAC address in the sender hardware address field (ar$sha) in the ARP Reply is matched against the target hardware address field (ar$tpa) in the ARP Request, and the IPv4 address in the sender protocol address field (ar$spa) of the ARP Reply is matched against the target protocol address field (ar$tpa) in the ARP Request. If a match is found, then the host continues to use that IPv4 address, subject to the lease re-acquisition and expiration behavior described in Section 4.4.5 of the DHCP specification [RFC2131].
有効なARP応答が受信された場合、ARP応答で送信者のハードウェアアドレスフィールド（ARます$ SHA）でのMACアドレスがARP要求、およびにおけるIPv4アドレスにターゲットハードウェアアドレスフィールド（ARます$ TPA）と照合されますARP応答の送信元プロトコルアドレスフィールド（ARの$スパ）は、ARP要求におけるターゲットプロトコルアドレスフィールド（ARます$ TPA）と照合されます。一致が見つかった場合、ホストはDHCP仕様[RFC2131]のセクション4.4.5に記載のリースの再取得および呼気動作の対象とそのIPv4アドレスを使用し続けます。
The risk of an address conflict is greatest when the host moves between private networks, since in this case the completion of conflict detection on the former network does not provide assurance against an address conflict on the new network. Until a host has confirmed the operability of its IPv4 configuration by receipt of a response to the reachability test, it SHOULD NOT respond to ARP Requests and SHOULD NOT broadcast ARP Requests containing its address within the sender protocol address field (ar$spa).
プライベートネットワーク間の時にホストが移動する。この場合には、元ネットワーク上の競合検出の完了が新しいネットワーク上のアドレスの競合に対する保証を提供していないので、アドレスの競合のリスクは、最大です。ホストが到達可能性テストに対する応答の受信によってそのIPv4の設定の操作性を確認するまで、それはARP要求に応答すべきではなく、送信者のプロトコルアドレスフィールド（ARの$スパ）内のアドレスを含むARP要求をブロードキャストすべきではありません。
Sending an ICMP Echo Request [RFC792] would not be an acceptable way of testing a candidate configuration, since sending any IP packet generally requires an ARP Request/Reply exchange and, as explained above, ARP packets may not be broadcast safely until after the candidate configuration has been confirmed. Also, where a host moves from one private network to another, an ICMP Echo Request can result in an ICMP Echo Response even when the MAC address has changed, as long as the IPv4 address remains the same. This can occur, for example, where a host moves from one home network using prefix 192.168/16 to another one. In addition, if the ping is sent with TTL > 1, then an ICMP Echo Response can be received from an off-link router. As a result, if the MAC address of the test node is not checked, the host can mistakenly confirm attachment, potentially resulting in an address conflict. As a result, sending an ICMP Echo Request SHOULD NOT be used as a substitute for the reachability test.
上述したように、任意のIPパケットを送信することは、一般に、ARP要求/応答交換を必要とするので、[RFC792]、候補構成をテストするに許容される方法ではないICMPエコー要求を送信し、ARPパケットは、候補後まで安全にブロードキャストされなくてもよいです構成が確認されています。また、どこ別のプライベートネットワークからホストに移動すると、ICMPエコー要求は、MACアドレスは限りIPv4アドレスが同じままで、変更された場合でも、ICMPエコー応答をもたらすことができます。これは、ホストが別のものにプレフィックス192.168 / 16を使用して1つのホームネットワークから移動たとえば、のために、発生する可能性があります。ピングは、TTL> 1で送信された場合に加え、次いでICMPエコー応答は、オフリンクルータから受信することができます。テストノードのMACアドレスがチェックされていない場合、結果として、ホストが誤って潜在的にアドレス競合が生じる、添付ファイルを確認することができます。結果として、ICMPエコー要求を送信する到達可能性試験の代替として使用することはできません。
If the host has an operable routable IPv4 address on one or more networks, and if DHCPv4 is enabled on the interface, the host SHOULD attempt to acquire an IPv4 configuration using DHCPv4, in parallel with one or more reachability tests. This is accomplished by entering the INIT-REBOOT state and sending a DHCPREQUEST to the broadcast address, as specified in Section 4.4.2 of the DHCP specification [RFC2131].
ホストは、1つまたは複数のネットワーク上で動作可能なルーティング可能なIPv4アドレスを有し、DHCPv4のがインターフェイスで有効になっている場合、ホストは、一つ以上の到達可能性テストと並行して、DHCPv4のを使用してIPv4の設定を取得しようとするかどうか。これは、DHCP仕様[RFC2131]のセクション4.4.2で指定されるように、INIT-REBOOT状態に入ると、ブロードキャストアドレスにDHCPREQUESTを送信することによって達成されます。
If the host does not have an operable routable IPv4 address on any network, the host enters the INIT state and sends a DHCPDISCOVER packet to the broadcast address, as described in Section 4.4.1 of the DHCP specification [RFC2131]. If the host supports the Rapid Commit Option [RFC4039], it is possible that the exchange can be shortened from a 4-message exchange to a 2-message exchange.
ホストは、任意のネットワーク上で動作可能なルーティング可能なIPv4アドレスを持っていない場合、ホストはINIT状態に入り、DHCP仕様[RFC2131]のセクション4.4.1に記載したように、ブロードキャストアドレスにDHCPDISCOVERパケットを送信します。ホストは急速オプション[RFC4039]をコミットサポートしている場合、交換は2メッセージ交換に4メッセージ交換から短縮することが可能です。
If the host does not receive a response to a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in Section 4.1 of the DHCP specification [RFC2131].
ホストがDHCPREQUESTまたはDHCPDISCOVERに対する応答を受信しない場合、DHCPの仕様[RFC2131]のセクション4.1で指定されるように、それは再送信します。
As discussed in Section 4.4.4 of the DHCP specification [RFC2131], a host in INIT or REBOOTING state that knows the address of a DHCP server may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast address. In the INIT-REBOOT state, a DHCPREQUEST is sent to the broadcast address so that the host will receive a response regardless of whether the previously configured IPv4 address is correct for the network to which it has connected.
DHCP仕様[RFC2131]のセクション4.4.4で説明したように、DHCPサーバのアドレスを知っているINITまたはリブート状態のホストはDHCPDISCOVERまたはDHCPREQUESTなくIPv4のブロードキャストアドレスにそのアドレスを使用してもよいです。ホストは関係なく、以前に設定したIPv4アドレスは、それが接続されている先のネットワークの正しいかどうかの応答を受信するようにINIT-REBOOT状態では、DHCPREQUESTブロードキャストアドレスに送信されます。
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is not appropriate, since if the DHCP client has moved to another subnet, a DHCP server response cannot be routed back to the client since the DHCPREQUEST will bypass the DHCP relay and will contain an invalid source address.
DHCPクライアントが別のサブネットに移動した場合DHCPREQUESTをDHCPリレーをバイパスし、含まれていますから、DHCPサーバの応答をクライアントに戻すことができないので、INIT-REBOOT状態でのユニキャストアドレスにDHCPREQUESTを送信すると、適切ではありません無効な送信元アドレス。
DNAv4 applies only to previously configured addresses that had some lease lifetime associated with them, during which lifetime the address may be legitimately regarded as being reserved for exclusive use by the assigned host. DHCP-assigned addresses fit this description, but IPv4 Link-Local address [RFC3927] do not, since IPv4 Link-Local addresses are not handed out by an authoritative server and do not come with any guaranteed usable lifetime.
DNAv4のみアドレスが正当に割り当てられたホストによる排他的使用のために予約されているとみなすことができる生涯の間に、それらに関連するいくつかのリース寿命を持っていた以前に設定されたアドレスに適用されます。 DHCPによって割り当てられたアドレスは、この記述に合うが、IPv4のリンクローカルアドレス[RFC3927]はない、IPv4のリンクローカルアドレスは、権限のあるサーバーで配られていないので、あらゆる保証、使用可能な寿命が付属していません。
A host's claim on an IPv4 Link-Local address is valid only as long as that host remains connected to the link, actively defending against probes for its chosen address. As soon as a host shuts down, sleeps, or otherwise disconnects from a link, it immediately relinquishes any claim it may have had on any IPv4 Link-Local address on that link. A host wishing to reclaim a previously used IPv4 Link-Local address MUST perform the full probing and announcement process required by "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] and MUST NOT attempt to use DNAv4 as a shortcut to bypass that process.
そのホストが積極的に選択したアドレスのためのプローブ防御、リンクに接続されたままとIPv4のリンクローカルアドレス上のホストの主張は、唯一の限り有効です。すぐにホストは、シャットダウンする眠る、あるいはリンクから切断して、それはすぐにそれがそのリンク上の任意のIPv4リンクローカルアドレスを持っていたかもしれない任意の請求を放棄します。以前に使用したIPv4リンクローカルアドレスを再利用したいホストは、[RFC3927]「IPv4のリンクローカルアドレスの動的な設定」で必要とされる完全なプロービングと発表プロセスを実行しなければなりませんし、そのプロセスをバイパスするショートカットとしてDNAv4を使用するのを試みてはいけません。
Where the host does not have an operable routable IPv4 address on any network, the host MAY configure an IPv4 Link-Local address prior to entering the INIT state and sending a DHCPDISCOVER packet, as described in Section 2.3 of the DHCP specification [RFC2131]. Where a host can confirm that it remains connected to a network on which it possesses an operable routable IPv4 address, that address should be used, and the IPv4 Link-Local address is deprecated, as noted in Section 1.9 of the IPv4 Link-Local specification [RFC3927].
ホストは、任意のネットワーク上で動作可能なルーティング可能なIPv4アドレスを持っていない場合、DHCPの仕様[RFC2131]のセクション2.3で説明したように、ホストは、前INIT状態に入ると、DHCPDISCOVERパケットを送信したIPv4リンクローカルアドレスを構成することができます。ホストは、それが作動可能なルーティング可能なIPv4アドレスを所有するネットワークに接続されたままであることを確認できる場合、そのアドレスが使用されるべきである、とIPv4リンクローカル仕様のセクション1.9で述べたようにIPv4のリンクローカルアドレスは、廃止され[RFC3927]。
Where a host has an operable routable IPv4 address on one or more networks but the reachability test cannot confirm the configuration and the DHCPv4 client does not receive a response after employing the retransmission algorithm, Section 3.2 of the DHCP specification [RFC2131] states that the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease.
ホストが1つのまたは複数のネットワーク上で動作可能なルーティング可能なIPv4アドレスを有するが到達可能性テストは、設定を確認することができないとのDHCPv4クライアントが再送信アルゴリズムを使用した後に応答を受信しない場合、DHCPの仕様[RFC2131]のセクション3.2は、クライアントと述べています期限切れのリースの残りのために以前に割り当てられたネットワークアドレスおよびコンフィギュレーションパラメータを使用することもできます。
An implementation may use DNAv4 to confirm the configuration of manually assigned addresses. However, special consideration is required for this to produce reliable results, so it SHOULD NOT be enabled by default.
実装は、手動で割り当てられたアドレスの設定を確認するためにDNAv4を使用することができます。しかし、特別な配慮が、これは信頼性の高い結果を生成するために必要なので、デフォルトで有効にしないでください。
For the purposes of DNAv4, manually assigned addresses may be treated as equivalent to DHCP-assigned addresses with an infinite lifetime. This does not significantly increase the probability of an address conflict as long as the manually assigned address is reserved by the DHCP server or is outside the scope of addresses assigned by a DHCP server. However, where the manually assigned address is within an address scope utilized by a DHCP server, it is possible that the host will be unavailable when the DHCP server checks for a conflict prior to assigning the conflicting address. In this case, a host utilizing DNAv4 could confirm an address that had been assigned to another host.
DNAv4の目的のために、手動で割り当てられたアドレスは、無限の寿命を有するDHCP割り当てアドレスと同等に扱うことができます。これは大幅に手動で割り当てられたアドレスがDHCPサーバによって予約又はDHCPサーバによって割り当てられたアドレスの範囲外である限り、アドレス衝突の確率を増加させません。手動で割り当てられたアドレスがDHCPサーバによって利用されるアドレス範囲内にある場合しかし、ホストが使用不能になることが可能である場合、競合するアドレスを割り当てる前に、競合のためにDHCPサーバをチェックします。この場合、DNAv4を利用したホストが別のホストに割り当てられていたアドレスを確認することができました。
Typically, an address is manually assigned on a network because a dynamically assigned address was not suitable for some reason. Therefore, where DNAv4 and DHCP are run in parallel and DNAv4 confirms a manual configuration, it may be undesirable to allow this configuration to be overridden by DHCP, as described in Section 2.1. However, packet loss may cause the reachability test to fail while DHCP completes successfully, resulting in the host obtaining a dynamic address where a static address is desired. In order to provide for reliable reconfirmation of manually assigned addresses, reachability tests for manual configurations require a more aggressive retransmission strategy than that detailed in Section 4.1 of the DHCP specification [RFC2131]. For example, shorter retransmission intervals and more persistent retransmissions may be required.
動的に割り当てられたアドレスが何らかの理由のために適していなかったので、典型的には、アドレスを手動でネットワーク上で割り当てられています。 DNAv4とDHCPを並列に実行しDNAv4が手動設定を確認している場合、したがって、セクション2.1で説明したように、この構成は、DHCPによってオーバーライドされることを可能にするために望ましくない場合があります。しかし、パケット損失がDHCPは、静的アドレスが所望される動的アドレスを取得するホスト、その結果、正常に完了しながら到達可能性テストが失敗する可能性があり。手動で割り当てられたアドレスの信頼性の再確認を提供するために、手動構成の到達可能性テストは、DHCP仕様[RFC2131]のセクション4.1に詳述よりも積極的な再送信戦略を必要とします。例えば、短い再送間隔や、より持続的な再送信が必要になることがあります。
Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and DHCP and inherits the security vulnerabilities of these two protocols.
IPv4の（DNAv4）のためのネットワーク接続検出は、ARPおよびDHCPに基づいており、これら2つのプロトコルのセキュリティ上の脆弱性を継承しています。
ARP [RFC826] traffic is not secured, so an attacker gaining access to the network can spoof a response to the reachability test described in Section 2.1, leading the querier to conclude falsely that it is attached to a network that it is not connected to.
ARPは、[RFC826]トラフィックが確保されていないので、ネットワークにアクセスする攻撃者は、それが、それが接続されていないネットワークに接続されていることを誤って結論するクエリアをリードし、セクション2.1に記載の到達可能性テストに対する応答を偽装することができます。
Similarly, where DHCPv4 traffic is not secured, an attacker could masquerade as a DHCPv4 server, in order to convince the host that it was attached to a particular network. This and other threats relating to DHCPv4 are described in "Authentication for DHCP Messages" [RFC3118].
DHCPv4のトラフィックが確保されていない場合も同様に、攻撃者は、それが特定のネットワークに接続したことをホストに納得させるために、DHCPv4サーバになりすます可能性があります。これとのDHCPv4に関連する他の脅威は[RFC3118]「DHCPメッセージの認証」で説明されています。
The effect of these attacks will typically be limited to denial of service, unless the host utilizes its IP configuration for other purposes, such as security configuration or location determination. For example, a host that disables its personal firewall based on evidence that it had attached to a home network could be compromised by spoofing of the DNAv4 reachability test. In general, adjustment of the security configuration based on DNAv4 is NOT RECOMMENDED.
ホストは、セキュリティ設定または位置決意のような他の目的のためにそのIP設定を利用しない限り、これらの攻撃の影響は、典型的には、サービスの拒否に限定されるであろう。例えば、それがホームネットワークに接続していたという証拠に基づいて、そのパーソナルファイアウォールを無効にするホストがDNAv4の到達可能性テストのなりすましによって損なわれる可能性があります。一般的には、DNAv4に基づいてセキュリティ設定の調整が推奨されていません。
Hosts that depend on secure IP configuration SHOULD NOT use DNAv4 but SHOULD instead utilize DHCP authentication [RFC3118], possibly in combination with the Rapid Commit Option [RFC4039].
セキュアなIP構成に依存するホストはDNAv4を使うべきではなく、代わりに、おそらく高速との組み合わせで、DHCP認証[RFC3118]を利用するべきオプション[RFC4039]をコミットします。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上での送信のためにイーサネット（登録商標）アドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[ACD] Cheshire, S., "IPv4 Address Conflict Detection", Work in Progress, July 2005.
[ACD]チェシャー、S.、 "IPv4アドレス競合検出"、進歩、2005年7月での作業。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、RFC 3927、2005年5月。
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 4039, March 2005.
[RFC4039]パーク、S.、キム、P.、およびB.フォルツは、2005年3月、RFC 4039 "急速に動的ホスト構成プロトコルバージョン4（DHCPv4の）ためにコミットオプション"。
The authors would like to acknowledge Greg Daley of Monash University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ralph Droms of Cisco Systems, Ted Lemon of Nominum, John Loughney of Nokia, Thomas Narten of IBM and David Hankins of ISC for contributions to this document.
著者は、このへの貢献のためにモナッシュ大学のグレッグ・デイリー、エリック・グットマンとSun Microsystems社のエリックNordmarkと、シスコシステムズのラルフDroms、ノミナムのテッド・レモン、ノキアのジョンLoughney、IBMのトーマスNarten氏とISCのデビッド・ハンキンズを確認したいと思います資料。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425 818 4011 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
電話：+1 425 818 4011ファックス：+1 425 936 7329 Eメール：bernarda@microsoft.com
James Carlson Sun Microsystems, Inc 1 Network Drive Burlington, MA 01803-2757 USA
ジェームズ・カールソン米国Sun Microsystems、Inc. 1ネットワークドライブバーリントン、マサチューセッツ州01803から2757 USA
Phone: +1 781 442 2084 Fax: +1 781 442 1677 EMail: james.d.carlson@sun.com
電話：+1 781 442 2084ファックス：+1 781 442 1677 Eメール：james.d.carlson@sun.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino, California 95014, USA
スチュアートチェシャーたApple Computer、Inc. 1無限ループクパチーノ、カリフォルニア州95014、USA
Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org
電話：+1 408 974 3207 Eメール：rfc@stuartcheshire.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。