[要約] RFC 4436は、IPv4ネットワークへの接続を検出するための手法であり、ネットワークアタッチメントの検出を目的としています。このRFCの目的は、IPv4ネットワークへの接続の状態を迅速かつ正確に判断することです。
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)
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).
Copyright（c）The Internet Society（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 Link-Localアドレスをサポートするホストの展開の経験から、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 Link-localアドレス[RFC3927]をサポートするホストの展開の経験から、IPV4（DNAV4）のネットワークアタッチメントを検出された一連のステップを統合します。DNAV4は、以前の（ただし有効な）構成を再利用しようとすることで以前に接続されていたネットワークへの（一般的な）再攻撃のケースを最適化し、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はDHCPRequestに応じて受信される場合があり、INIT状態に移動することによりクライアントが構成プロセスを再起動します。新しいネットワークで以前に取得したアドレスが引き続き操作可能である場合、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).
このドキュメントで指定された代替メカニズムは、ホストが以前に割り当てられたDHCPアドレスを持っている場合に適用されます。これは、DHCPreleaseメッセージを介してDHCPサーバーに返されず、まだリースに残る時間があります。この場合、ホストは、ユニキャストARPリクエストパケットをそのリンクで以前に知られているルーターに送信することにより、このアドレスが使用に有効な論理リンクに再び取り付けられたかどうかを判断できます。1つ以上のユニキャストARP要求パケットを1つ以上のルーターに送信することにより、複数のルーターを使用します。
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 MB/秒という低いレートで送信される802.11ネットワークでは。もう1つの利点は、ホストがリンクに載っていない場合、放送ARPリクエストがそのリンク上のピアのARPキャッシュを汚染する可能性があることです。プライベートアドレス[RFC1918]を使用する場合、別のデバイスが同じアドレスを合法的に使用している可能性があり、ブロードキャストARP要求が通信を破壊し、TCP接続が破損し、同様の問題が発生する可能性があります。また、ルーターのMACアドレスにアドレス指定されたユニキャストARPパケットを使用して、ホストはホストが予想されるリンクにない場合、その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は、実際にそうでない場合、ホストが以前に訪問可能なリンクに戻ったと結論付けてはなりません。
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処理が並行して進行する必要があることを意味します。DHCP処理を開始する前にDNAV4が失敗するのを待つと、総処理時間が大幅に増加する可能性があります。これは、目的の効果の反対です。
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オクテットユニキャストパケットを送信するのと比較して、速くて安価であることを計算する必要があります。）正しいものであることがわかっている候補構成を誤って排除しない可能性が高い。
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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、「要件レベルを示すためにRFCで使用するためのキーワード」[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 $ SHA 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 $ SPA 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クライアント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リリースメッセージを介して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.
セクション2.1で説明されているリーチ可能性テストを使用して、ホストはそれらに関連付けられている操作可能なIPv4アドレスを備えたネットワークのセットから、サブセットを選択し、各ネットワークの構成を確認しようとします。
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.
特定のネットワークの場合、ホストはテストノードとしてローカルルーター（できれば債務不履行ゲートウェイ）のアドレスを使用する必要があります。複数のアドレスがわかっている場合、これらのアドレスは並行してテストされる場合があります。構成の妥当性を確保するために、ホストは次のホップアドレスがReachabilityテストに合格するルートのみを構成する必要があります。他のルートを再学習する必要があります。
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がアドレスの競合の可能性を高める1つのケースは、次の場合です。
o a DHCP server hands out an address lease,
o DHCPサーバーがアドレスリースを配布します。
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
o リースを安定したストレージに保存できなかったDHCPサーバーは、その同じアドレスを別のホストに割り当て、
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ゲートウェイはほとんどありません。短いDHCPリース寿命はこのリスクを軽減できますが、これによりDNAV4が試すために利用可能な操作可能な候補構成も制限されます。
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アドレスを持っていません。この場合、Reachabilityテストでは、ホストが操作可能なルーティング可能なIPv4アドレスを持っていることを確認できないため、Reachabilityテストを完了しても目的はありません。
[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]が構成されている場合。ReachabilityテストはARPを利用します。これは不安定です。DHCP認証を試みるように構成されているホストは、Reachabilityテストを利用すべきではありません。セキュリティの問題については、セクション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クライアント識別子オプションとは異なります。この場合、DHCPサーバーは、2つのインターフェイスが異なるアイデンティティを提示しているため、候補構成を取得または拡張するようにクライアントが行った要求を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.
Reachabilityテストが成功した場合、ホストは、確認されたネットワークに関連付けられた操作可能なルーティング可能な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手順は、DHCP仕様[RFC2131]のセクション3.2および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の両方が同じリンクで使用される状況では、Reachabilityテストが正常に完了する可能性があり、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つの戦略は、Reachabilityテストの再送信を見捨て、DHCPクライアントのみが再送信できるようにすることです。DNAV4とDHCPの再送信間の競争を減らすために、再送信がDHCP仕様[RFC2131]のセクション4.1で説明されている再送信戦略を利用するDNAV4の実装、DNAV4の再送信のスケジューリングDHCP再送信のスケジューリング。
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.
RecionabilityテストまたはDHCPメッセージへの応答が受信された場合、保留中の再送信がキャンセルされます。DNAV4実装は2回以上再送信することをお勧めします。偽りの「リンクアップ」表示の場合に減衰を提供するには、DNAV4手順を1秒に1回しか実行しないことをお勧めします。
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リクエストを送信することにより実行されます。ホストは、ターゲットプロトコルアドレス（AR $ TPA）をテストするノードのIPv4アドレスに設定し、送信者プロトコルアドレスフィールド（AR $ SPA）を独自の候補IPv4アドレスに設定する必要があります。ARP要求は、ホストMACアドレスをソースとして、テストノードMACアドレスを宛先として使用する必要があります。ホストには、送信者ハードウェアアドレスフィールド（ar $ sha）にMacアドレスが含まれ、ターゲットハードウェアアドレスフィールド（ar $ tha）を0に設定します。
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リクエストのターゲットハードウェアアドレスフィールド（AR $ TPA）と、IPv4アドレスのIPv4アドレスと一致します。ARP応答の送信者プロトコルアドレスフィールド（AR $ SPA）は、ARPリクエストのターゲットプロトコルアドレスアドレスフィールド（AR $ TPA）と一致します。一致が見つかった場合、ホストはそのIPv4アドレスを引き続き使用します。これは、DHCP仕様[RFC2131]のセクション4.4.5で説明されているリースの再取得と有効期限の動作を条件とします。
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).
この場合、前者のネットワークでの競合検出の完了は、新しいネットワークのアドレス競合に対する保証を提供しないため、ホストがプライベートネットワーク間を移動する場合、住所競合のリスクは最大です。ホストがReachabilityテストへの応答を受け取ってIPv4構成の操作性を確認するまで、ARP要求に応答しないでください。また、送信者プロトコルアドレスフィールド（AR $ SPA）内にアドレスを含む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.
ICMPエコーリクエスト[RFC792]の送信は、IPパケットを送信するには一般にARPリクエスト/返信交換が必要であり、上記で説明したように、ARPパケットを候補者の後まで安全に放送することはできないため、候補構成をテストする許容可能な方法ではありません。構成が確認されています。また、ホストが1つのプライベートネットワークから別のネットワークに移動する場合、IPv4アドレスが同じままである限り、MACアドレスが変更された場合でも、ICMPエコーリクエストはICMPエコー応答をもたらす可能性があります。これは、たとえば、接頭辞192.168/16を使用して1つのホームネットワークから別のホームネットワークを使用して移動する場合に発生する可能性があります。さらに、Pingが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]をサポートしている場合、交換を4メッセージの交換から2メッセージ交換に短縮できる可能性があります。
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または再起動状態のホストは、IPv4ブロードキャストアドレスではなくDHCPDISCOVERまたはDHCPREQUESTでそのアドレスを使用する場合があります。init-reboot状態では、DHCPRequestがブロードキャストアドレスに送信されるため、以前に構成されたIPv4アドレスが接続されているネットワークに対して正しいかどうかに関係なく、ホストが応答を受信します。
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リレーをバイパスし、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リンクローカルアドレスは権威あるサーバーによって配布されず、保証された使用可能な生涯を伴わないため、IPv4リンクローカルアドレス[RFC3927]はそうではありません。
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リンクローカルアドレスを取り戻すことを希望するホストは、「IPv4リンクローカルアドレスの動的構成」[RFC3927]に必要な完全なプロービングおよびアナウンスプロセスを実行する必要があり、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アドレスを持っていますが、Reachabilityテストは構成を確認できず、DHCP4クライアントはDHCP仕様[RFC2131]の再送信アルゴリズムを使用した後、応答を受け取りません。以前に割り当てられたネットワークアドレスと構成パラメーターを使用することを選択できます。
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仕様のセクション4.1で詳述されているものよりも積極的な再送信戦略が必要です[RFC2131]。たとえば、より短い再送信間隔とより永続的な再送信が必要になる場合があります。
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に関連するこのおよびその他の脅威は、「DHCPメッセージの認証」[RFC3118]で説明されています。
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 Reachabilityテストのスプーフィングによって損なわれる可能性があります。一般に、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、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] 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月。
[ACD] Cheshire, S., "IPv4 Address Conflict Detection", Work in Progress, July 2005.
[ACD] Cheshire、S。、「IPv4アドレス競合検出」、2005年7月、進行中の作業。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、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] Park、S.、Kim、P。、およびB. Volz、「動的ホスト構成プロトコルバージョン4（DHCPV4）のラピッドコミットオプション」、RFC 4039、2005年3月。
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.
著者は、モナッシュ大学のグレッグ・デイリー、エリック・ガットマン、サン・マイクロシステムのエリック・ノードマーク、シスコ・システムのラルフ・ドロム、ノキナムのテッド・レモン、ノキアのジョン・ラウニー、IBMのトーマス・ナルテン、ISCのデイビッド・ハンキンズがこの貢献に貢献したことに感謝します。書類。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 818 4011
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
James Carlson Sun Microsystems, Inc 1 Network Drive Burlington, MA 01803-2757 USA
James Carlson Sun Systems、Inc 1ネットワークドライブバーリントン、マサチューセッツ州01803-2757 USA
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino, California 95014, USA
Stuart Cheshire Apple Computer、Inc。1 Infinite Loop Cupertino、California 95014、USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。