RFC4436 日本語訳
4436 Detecting Network Attachment in IPv4 (DNAv4). B. Aboba, J.Carlson, S. Cheshire. March 2006. (Format: TXT=35991 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 4436 Microsoft Corporation
Category: Standards Track J. Carlson
Sun Microsystems
S. Cheshire
Apple Computer
March 2006
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 4436年のマイクロソフト社カテゴリ: 2006年の標準化過程J.カールソンサン・マイクロシステムズS.チェーシャー州アップル・コンピューターの行進
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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構成を得るのは(使用に続くように)総引き渡し潜在の部分として付属のポイントの間で移行するのにおいて重要であるかもしれません。 このドキュメントは統合されます、アルプ、DHCP、およびIPv4 Linkローカルのアドレスをサポートするホストの展開の経験から、IPv4(DNAv4)のためのDetecting Network Attachmentとして知られている、1セットのステップ、付属のポイントの間で移行しながら引き渡し潜在に縮小するために。
Aboba, et al. Standards Track [Page 1] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[1ページ]RFC4436DNAv4 March 2006
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
1. 序論…2 1.1. 適用性…2 1.2. 要件…5 1.3. 用語…5 2. 概要…6 2.1. 可到達性テスト…8 2.1.1. パケット形式…9 2.2. IPv4は獲得を扱います…10 2.3. IPv4のリンクローカルのアドレス…11 2.4. 手動で、アドレスを割り当てます…12 3. セキュリティ問題…12 4. 参照…13 4.1. 標準の参照…13 4.2. 有益な参照…13 5. 承認…14
1. Introduction
1. 序論
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.
このドキュメントは統合されます、アルプが[RFC826]と、DHCP[RFC2131]と、IPv4 Linkローカルのアドレス[RFC3927]であるとサポートするホストの展開の経験から、IPv4(DNAv4)のためのDetecting Network Attachmentとして知られている1セットのステップ。 DNAv4は前の、そして、(まだ有効)の構成を再使用するのを試みることによって1つが以前に関連づけられたネットワークへの再付属の(一般的)のケースを最適化します、LANの再付属時間を数ミリセカンドまで短縮して。 この手順がARPプロトコルに依存しているので、それはARPをサポートしないメディアにおける使用に適していません。
1.1. Applicability
1.1. 適用性
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,
新しいアドレスを得るとき、DHCPは、クライアントSHOULDが提供されたアドレスが既に使用中でないことを確かめるのにARPを使用すると指定します。 アドレス闘争検出[ACD]のプロセスは最大7秒取ることができます。 原則として、この時間間隔を短くすることができました。
Aboba, et al. Standards Track [Page 2] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[2ページ]RFC4436DNAv4 March 2006
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.
明白なトレードオフで: 別のホストが既に意図しているアドレスを使用しているかどうかを見るのを待ちながらホストが過ごす時間が少なければ少ないほど、不注意なアドレス闘争のリスクは、より高いです。
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.
クライアントがネットワークの間で移行するとき、アドレス再合法化試みは失敗しているかもしれません。 DHCPREQUESTに対応してDHCPNAKを受け取るかもしれません、クライアントが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サーバに返されないで、リースに残りながら、まだ時間がある)があるとき、このドキュメントによって指定された代替のメカニズムは適用されます。 この場合、ホストは、それが使用に、このアドレスが有効である論理的なリンクに再付いたかどうかと決心するかもしれません、以前にそのリンク(または1つ以上のユニキャストARP Requestパケットをそれらのルータの1つ以上に送るのによる1つ以上のルータとのリンクの場合で)に知られていたルータにユニキャストARP Requestパケットを送ることによって。
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つの利益はユニキャストパケットがパケットを放送するよりさらに少ない負担をネットワークに課すということです、特に放送パケットがレートで1Mb/秒と同じくらい低く送られるかもしれない802.11のネットワークで 別の利益はホストがリンクの上にいないなら気付くと、オンであることを望んでいて、放送ARP Requestがそのリンクで同輩のARPキャッシュを汚染できたということです。 プライベート・アドレス[RFC1918]を使用するとき、別のデバイスは合法的に同じアドレスを使用しているかもしれません、そして、放送ARP Requestは通信システムを遮断できました、TCP接続が壊れていて、同様の問題であることを引き起こして。また、ホストが見つけると予想しているルータのMACアドレスに扱われたユニキャストARPパケットを使用するのは、ホストがそこに予想されたリンクの上にいないならそれがそのMACアドレスをもってどんなデバイスにもならないことを意味します、そして、どんな損害も与えないで、ARPパケットは空間に無害に見えなくなるでしょう。
Aboba, et al. Standards Track [Page 3] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[3ページ]RFC4436DNAv4 March 2006
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)を数100ミリセカンドと同じくらい必要とするかもしれないプロセスを加速して、ホストがネットワークを変えるときのマルチ2番目の闘争検出遅れを減少させることです。
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 パフォーマンスの最適化として、有病誤診は許容できます。 それはこの最適化がすべての可能な場合で正しく以前に訪問されたリンクを認識するという絶対条件ではありません。 例えば将来それで同じリンクに返すDNAv4が検出できないその時ルータがユニキャストARP Requestsを無視するなら。 ホストが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の八重奏です。 これは、失敗の試みの費用がわずかであることを意味しますが、逃された機会(候補として利用可能な正しいアドレスを持って、ある理由でそれを試みないのを選ぶ)の費用は大きいです。 その結果、最も良い戦略はこのリンクに、もしあればどの候補が正しいかもしれないかを決定しようとするよりしばしばむしろすべての利用可能な候補構成を試みることです、発見的教授法かヒントに基づいて。 (b) 42八重奏のユニキャストパケットを送ると比べて、計算するためにヒューリスティックが(a)にそうしたという候補リストから不適当な構成を排除する潜在的に役に立つ方法であるという見通しを提供するヒューリスティックに、速くて、安価であってください、そして、間違ってわかることができた正しい方である候補構成を排除しないという高い確率を持ってください。
Aboba, et al. Standards Track [Page 4] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[4ページ]RFC4436DNAv4 March 2006
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が低遅延handoffsを有効にするのにおいて有効であるつもりであるなら、それは、10未満でThisが、計算するために候補構成を排除するのに使用されるどんなヒューリスティックも、高々数ミリセカンドと同じくらい取る必要であるのを含意する原稿を完成する必要があります。 これには、リンクレイヤの観測に基づく発見的教授法かインターネット層のトラフィックの余地があまりありません。
1.2. Requirements
1.2. 要件
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは「RFCsにおける使用が要件レベルを示すキーワード」[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.3. Terminology
1.3. 用語
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$鉱泉ARPパケット分野: 送付者プロトコルアドレス[RFC826。] IP Address Resolutionに関しては、これは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 Address Resolutionに関しては、IPv4は、どの1つの願望を知ったらよいかためにハードウェアがアドレスであると扱います。
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クライアントか「クライアント」が設定パラメータを得るのに、Dynamic Host Configuration Protocol(DHCP)[RFC2131]を使用しているインターネット・ホストです、ネットワーク・アドレスのように。
DHCP server
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
DHCPサーバA DHCPサーバか「サーバ」がDHCPクライアントに設定パラメータを返すインターネット・ホストです。
Aboba, et al. Standards Track [Page 5] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[5ページ]RFC4436DNAv4 March 2006
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.
A通信機器かネットワーク・ノードが交信できる媒体をリンクしてください。 それぞれのリンクは最低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.
もうデータフレームをコミュニケートできないインタフェースのものに関連している州の変化を意味するリンクレイヤで提供されたDown Anイベントをリンクしてください。 高いフレームの損失の一時的な一区切りは十分ではありません。 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.
データ・リンクのコントロールを維持するのに原因となるコントロールか処理論理のLayer Conceptual層をリンクしてください。 データ・リンク層機能は、より高い層の論理とデータ・リンクとのインタフェースを提供します。 リンクレイヤは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.
関連しているインタフェースのできるなって州の変化を意味するデータフレームを伝えるリンクレイヤで提供されたUp Anイベントをリンクしてください。
Point of Attachment
The link endpoint on the link to which the host is currently
connected.
Attachmentを指してください。ホストが現在接続されるリンクの上のリンク終点。
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].
Routableは、Inがこの仕様(「発送可能アドレス」がIPv4 Link-ローカルアドレス以外のどんなユニキャスト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を通して割り当てた操作できるアドレスInはまだ期限が切れていませんでした。
2. Overview
2. 概要
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:
それが接続する各ネットワークにおいて、ホストが以下のパラメタを安定貯蔵に保存すると思われます:
Aboba, et al. Standards Track [Page 6] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[6ページ]RFC4436DNAv4 March 2006
[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はテストノードとしてローカルルータ(望ましくはデフォルトゲートウェイ)のアドレスを使用します。 1つ以上のアドレスが知られているなら、それらのアドレスは平行でテストされるかもしれません。 構成の正当性を確実にするために、ホストSHOULDは次のホップアドレスが可到達性テストに合格するルートを構成するだけです。 もう一方は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 RequestsとResponsesを送るときの制限はセクション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 第1代ホストは、戻って、時間が残っているまだ有効なリースを持っていて、割り当てられたアドレスを使用しかけます、現在その同じアドレスを使用している新しいホストと衝突して。
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が試みるように利用可能な手術可能な候補構成を制限しますが。
Aboba, et al. Standards Track [Page 7] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[7ページ]RFC4436DNAv4 March 2006
2.1. Reachability Test
2.1. 可到達性テスト
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] ホストには、そのネットワークに関する手術可能なroutable IPv4アドレスがありません。 この場合可到達性テストが、ホストには手術可能なroutable 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を利用します。(ARPは不安定です)。 DHCP認証SHOULD NOTを試みるために構成されたホストは可到達性テストを利用します。 セクション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 Client Identifierオプションのコンテンツはクライアントが問題のインタフェースに提示するつもりであるDHCP Client Identifierオプションと異なっています。 この場合、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.
可到達性テストがうまくいくなら、ホストSHOULDは、確認されたネットワークに関連している手術可能なroutable 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構成を得るホスト試みが戻ったのは、RECOMMENDEDです。 これは、DNAv4手順が可到達性テストが失敗するか、または.2のセクション3.2と4.3DHCP仕様[RFC2131]で説明されるように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
DNAv4とDHCPの両方が同じリンクの上に使用される状況で、可到達性テストが首尾よく完成するのが、可能であり、次に、DHCPは後で異なった結果で完成するでしょう。 これが起こるなら、実装SHOULDは可到達性テストを捨てます。
Aboba, et al. Standards Track [Page 8] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[8ページ]RFC4436DNAv4 March 2006
results and use the DHCP result instead, unless the address confirmed via the reachability test has been manually assigned (see Section 2.4).
可到達性テストで確認されたアドレスが手動で割り当てられていない場合(セクション2.4を見てください)、なって、代わりにDHCP結果を使用します。
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 retransmissionsとの競争を抑えるために、再送されるDNAv4実装はDHCP仕様[RFC2131]のセクション4.1で説明された「再-トランスミッション」戦略を利用するかもしれません、DHCP retransmissionsの間のDNAv4 retransmissionsの計画をして。
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メッセージにも応答を受けるなら、未定の「再-トランスミッション」を取り消します。 DNAv4実装が二度未満再送されるのは、RECOMMENDEDです。 「結び付いてください」という偽りの指摘の場合における湿気を提供するには、DNAv4手順がそれ以上行われないのは、1秒あたりの一度よりRECOMMENDEDです。
2.1.1. Packet Format
2.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 Requestを送ることによって、実行されます。 ホストは検査されるノードのIPv4アドレスへの目標プロトコルアドレス(ar$tpa)、およびそれ自身の候補IPv4アドレスへの送付者プロトコルアドレス・フィールド(ar$鉱泉)を設定しなければなりません。 ARP Requestはソースとしてホスト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 Replyが受け取られているなら、ARP Replyの送付者ハードウェアアドレス・フィールド(ar$sha)のMACアドレスはARP Requestの目標ハードウェアアドレス・フィールド(ar$tpa)に取り組まされます、そして、ARP Replyの送付者プロトコルアドレス・フィールド(ar$鉱泉)のIPv4アドレスはARP Requestの目標プロトコルアドレス・フィールド(ar$tpa)に取り組まされます。 マッチが見つけられるなら、ホストは、.5のセクション4.4DHCP仕様[RFC2131]で説明されたリース再獲得と満了の振舞いを条件としてその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
ホストが私設のネットワークの間で移行するとき、アドレス闘争のリスクは最も高いです、前のネットワークにおける闘争検出の完成がこの場合保証を提供しないので
Aboba, et al. Standards Track [Page 9] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[9ページ]RFC4436DNAv4 March 2006
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構成の運転可能性を確認しました、それ。送付者プロトコルアドレス・フィールド(ar$鉱泉)の中にアドレスを保管していて、SHOULD NOTはARP RequestsとSHOULD NOT放送ARP Requestsに応じます。
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 Echo Request[RFC792]を送るのは、候補構成をテストする許容できる方法でないでしょう、一般に、どんなIPパケットも送るのがARP Request/回答交換を必要として、候補構成が確認された後までARPパケットが上で説明されるように安全に放送されないかもしれないので。 また、ホストが1つの私設のネットワークから別のネットワークまで移行するところでは、MACアドレスが変化さえしたとき、ICMP Echo RequestはICMP Echo Responseをもたらすことができます、IPv4アドレスが同じままで残っている限り。 例えば、これはホストが接頭語192.168/16を使用する1つのホームネットワークから別の1つまで移行するところに起こることができます。 さらに、TTL>1でピングを送るなら、オフリンクルータからICMP Echo Responseを受け取ることができます。 その結果、テストノードのMACアドレスがチェックされないなら、ホストは付属を誤って確認できます、潜在的にアドレス闘争をもたらして。 その結果、ICMP Echo Request SHOULDを送って、可到達性テストの代用品として使用されないでください。
2.2. IPv4 Address Acquisition
2.2. IPv4アドレス獲得
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つ以上のネットワークに手術可能なroutable IPv4アドレスを持って、DHCPv4がインタフェースで有効にされるなら、ホストSHOULDは、DHCPv4を使用することでIPv4構成を取得するのを試みます、1つ以上の可到達性テストと平行して。 これはINIT-REBOOT状態に入れて、DHCPREQUESTを放送演説に送ることによって、達成されます、.2のセクション4.4DHCP仕様[RFC2131]で指定されるように。
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.
ホストにどんなネットワークに関する手術可能なroutable IPv4アドレスもないなら、ホストは、INIT状態に入って、DHCPDISCOVERパケットを放送演説に送ります、.1のセクション4.4DHCP仕様[RFC2131]で説明されるように。 ホストがRapid Commit Option[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
.4のセクション4.4DHCP仕様[RFC2131]で議論するように、DHCPサーバのアドレスを知っているINITのホストかREBOOTING州がIPv4放送演説よりむしろDHCPDISCOVERかDHCPREQUESTのそのアドレスを使用するかもしれません。 INIT-REBOOT状態では、ホストが送るようにDHCPREQUESTを放送演説に送ります。
Aboba, et al. Standards Track [Page 10] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[10ページ]RFC4436DNAv4 March 2006
receive a response regardless of whether the previously configured IPv4 address is correct for the network to which it has connected.
それが接続したネットワークに、以前に構成された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.
INIT-REBOOT状態のユニキャストアドレスにDHCPREQUESTを送るのは適切ではありません、DHCPクライアントが別のサブネットに移行したなら、DHCPREQUESTがDHCPリレーを迂回させて、無効のソースアドレスを含むのでDHCPサーバ応答をクライアントに発送であって戻しできないので。
2.3. IPv4 Link-Local Addresses
2.3. IPv4のリンクローカルのアドレス
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 Link-ローカルアドレス[RFC3927]は合うというわけではありません、IPv4 Linkローカルのアドレスが正式のサーバによって与えられないで、またどんな保証された使用可能な生涯と共にも来ないので。
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 Link-ローカルアドレスのホストのクレームは有効です、選ばれたアドレスのために活発に徹底的調査に対して防御して。 ホストが停止するか、眠るか、またはそうでなければ、リンクから切断するとすぐに、それはすぐに、そのリンクの上にどんなIPv4 Link-ローカルアドレスにも持っていたどんなクレームも放棄します。 以前中古のIPv4 Link-ローカルアドレスを取り戻したがっているホストは、「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].
ホストにはどんなネットワークに関する手術可能なroutable IPv4アドレスもないところでは、INIT状態に入れて、DHCPDISCOVERパケットを送る前にホストはIPv4 Link-ローカルアドレスを構成するかもしれません、DHCP仕様[RFC2131]のセクション2.3で説明されるように。 ホストが、それがそれが手術可能なroutable IPv4アドレスを持っているネットワークに関連していたままで残っていると確認できるところでは、そのアドレスは使用されるべきです、そして、IPv4 Link-ローカルアドレスは推奨しないです、IPv4 Linkローカルの仕様[RFC3927]のセクション1.9に述べられるように。
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つ以上のネットワークに関する手術可能なroutable IPv4アドレスがありますが、可到達性テストが構成を確認できないで、再送信アルゴリズムを使った後にDHCPv4クライアントが応答を受けないところでは、DHCP仕様[RFC2131]のセクション3.2は、クライアントが、満期になっていないリースの残りに以前に割り当てられたネットワーク・アドレスと設定パラメータを使用するのを選ぶかもしれないと述べます。
Aboba, et al. Standards Track [Page 11] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[11ページ]RFC4436DNAv4 March 2006
2.4. Manually Assigned Addresses
2.4. 手動で割り当てられたアドレス
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を使用するかもしれません。 しかしながら、これが信頼できる結果を生むのに特別の配慮が必要であり、そうがそれである、SHOULD NOT、デフォルトで可能にされてください。
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サーバが闘争がないかどうかチェックするとき、ホストが入手できなくなるのは、可能です。 この場合、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は手動の構成を確認します、そして、この構成がDHCPによってくつがえされるのを許容するのは望ましくなくてもよいです、セクション2.1で説明されるように。 しかしながら、パケット損失はDHCPである間、可到達性テストに失敗されるかもしれません。首尾よく、静的なアドレスが望まれているダイナミックなアドレスを得ながらホストをもたらして、完了します。 手動で割り当てられたアドレスの信頼できる再確認に備えるために、手動の構成のための可到達性テストはDHCP仕様[RFC2131]のセクション4.1で詳しく述べられたそれより攻撃的な「再-トランスミッション」戦略を必要とします。 例えば、より短い再送信間隔と、より永続的な「再-トランスミッション」が必要であるかもしれません。
3. Security Considerations
3. セキュリティ問題
Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and DHCP and inherits the security vulnerabilities of these two protocols.
IPv4(DNAv4)のためにNetwork Attachmentを検出するのは、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で説明された可到達性テストへの応答を偽造することができます、querierが、それが関連づけられないネットワークに付けられていると間違って結論を下すように導いて。
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
同様に、DHCPv4トラフィックが保証されないところで攻撃者はDHCPv4サーバのふりをすることができました、それが特定のネットワークに付けられたとホストに納得させるために。 これと他の脅威
Aboba, et al. Standards Track [Page 12] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[12ページ]RFC4436DNAv4 March 2006
relating to DHCPv4 are described in "Authentication for DHCP Messages" [RFC3118].
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可到達性テストのスプーフィングでホームネットワークまで差し押さえを食ったという証拠に基づくパーソナルファイアウォールを無効にするホストに感染することができるでしょう。 一般に、DNAv4に基づくセキュリティ設定の調整はNOT RECOMMENDEDです。
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構成SHOULD NOTを当てにするホストがDNAv4を使用しますが、SHOULDは代わりに、DHCP認証[RFC3118]を利用します、ことによるとRapid Commit Option[RFC4039]と組み合わせて。
4. References
4. 参照
4.1. Normative References
4.1. 引用規格
[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.bitに扱う」STD37、RFC826、1982年11月。
[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月。
4.2. Informative References
4.2. 有益な参照
[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.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、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.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3118] DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、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.Guttman、「IPv4のリンクローカルのアドレスの動的設定」、RFC3927)は、2005がそうするかもしれません。
Aboba, et al. Standards Track [Page 13] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[13ページ]RFC4436DNAv4 March 2006
[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.フォルツ、「Dynamic Host Configuration Protocolバージョン4のための急速なCommit Option(DHCPv4)」、RFC4039(2005年3月)。
5. Acknowledgements
5. 承認
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.
作者はこのドキュメントへの貢献のためにモナッシュ大学のグレッグ・デイリー、サン・マイクロシステムズのエリックGuttmanとエリックNordmark、シスコシステムズのラルフDroms、NominumのテッドLemon、ノキアのジョン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、4011Fax: +1 7329年の425 936メール: bernarda@microsoft.com
James Carlson Sun Microsystems, Inc 1 Network Drive Burlington, MA 01803-2757 USA
ジェームス・カールソン・サン・マイクロシステムズ、Inc1ネットワークドライブバーリントン、MA01803-2757米国
Phone: +1 781 442 2084 Fax: +1 781 442 1677 EMail: james.d.carlson@sun.com
以下に電話をしてください。 +1 781 442、2084Fax: +1 1677年の781 442メール: james.d.carlson@sun.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino, California 95014, USA
カルパチーノ、スチュアートチェーシャー州アップル・コンピューターInc.1無限ループカリフォルニア 95014、米国
Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org
以下に電話をしてください。 +1 3207年の408 974メール: rfc@stuartcheshire.org
Aboba, et al. Standards Track [Page 14] RFC 4436 DNAv4 March 2006
Aboba、他 標準化過程[14ページ]RFC4436DNAv4 March 2006
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Aboba, et al. Standards Track [Page 15]
Aboba、他 標準化過程[15ページ]
一覧
スポンサーリンク
