RFC3927 日本語訳
3927 Dynamic Configuration of IPv4 Link-Local Addresses. S. Cheshire,B. Aboba, E. Guttman. May 2005. (Format: TXT=83102 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Cheshire
Request for Comments: 3927 Apple Computer
Category: Standards Track B. Aboba
Microsoft Corporation
E. Guttman
Sun Microsystems
May 2005
コメントを求めるワーキンググループS.チェーシャー州要求をネットワークでつないでください: 3927年のアップル・コンピューターカテゴリ: 標準化過程B.Abobaマイクロソフト社E.Guttmanサン・マイクロシステムズ2005年5月
Dynamic Configuration of IPv4 Link-Local Addresses
IPv4のリンクローカルのアドレスの動的設定
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.
広い領域IPネットワークに参加するのに、ホストは、インタフェースへのIPアドレスによってユーザかソースからの自動的にDynamic Host Configuration Protocol(DHCP)サーバなどのネットワークによって手動で構成される必要があります。残念ながら、そのようなアドレス設定情報はいつも利用可能であるかもしれないというわけではありません。 したがって、どんなアドレス構成も利用可能でないときにさえホストがIPネットワーク機能の役に立つ部分集合に依存できるのは、有益です。 このドキュメントはホストが同じ物理的で(論理的)のリンクに接続される対向機器とのコミュニケーションに、有効な169.254/16接頭語の中でどう自動的にIPv4アドレスとのインタフェースを構成するかもしれないかを説明します。
IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.
IPv4 Linkローカルのアドレスは、直接同じ物理的で(論理的)のリンクに接続されないデバイスとのコミュニケーションに適しないで、安定して、発送可能なアドレスが入手できない(臨時の、または、孤立しているネットワークなどの)ところで使用されるだけです。 このドキュメントは、IPv4 Linkローカルのアドレスと発送可能アドレスが同時に同じインタフェースで構成されることを勧めません。
Cheshire, et al. Standards Track [Page 1] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[1ページ]RFC3927IPv4
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 5
1.4. Application Layer Protocol Considerations . . . . . . . 6
1.5. Autoconfiguration Issues. . . . . . . . . . . . . . . . 7
1.6. Alternate Use Prohibition . . . . . . . . . . . . . . . 7
1.7. Multiple Interfaces . . . . . . . . . . . . . . . . . . 8
1.8. Communication with Routable Addresses . . . . . . . . . 8
1.9. When to configure an IPv4 Link-Local Address. . . . . . 8
2. Address Selection, Defense and Delivery . . . . . . . . . . . 9
2.1. Link-Local Address Selection. . . . . . . . . . . . . . 10
2.2. Claiming a Link-Local Address . . . . . . . . . . . . . 11
2.3. Shorter Timeouts. . . . . . . . . . . . . . . . . . . . 13
2.4. Announcing an Address . . . . . . . . . . . . . . . . . 13
2.5. Conflict Detection and Defense. . . . . . . . . . . . . 13
2.6. Address Usage and Forwarding Rules. . . . . . . . . . . 14
2.7. Link-Local Packets Are Not Forwarded. . . . . . . . . . 16
2.8. Link-Local Packets are Local. . . . . . . . . . . . . . 16
2.9. Higher-Layer Protocol Considerations. . . . . . . . . . 17
2.10. Privacy Concerns. . . . . . . . . . . . . . . . . . . . 17
2.11. Interaction between DHCPv4 and IPv4 Link-Local
State Machines. . . . . . . . . . . . . . . . . . . . . 17
3. Considerations for Multiple Interfaces. . . . . . . . . . . . 18
3.1. Scoped Addresses. . . . . . . . . . . . . . . . . . . . 18
3.2. Address Ambiguity . . . . . . . . . . . . . . . . . . . 19
3.3. Interaction with Hosts with Routable Addresses. . . . . 20
3.4. Unintentional Autoimmune Response . . . . . . . . . . . 21
4. Healing of Network Partitions . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Application Programming Considerations. . . . . . . . . . . . 24
6.1. Address Changes, Failure and Recovery . . . . . . . . . 24
6.2. Limited Forwarding of Locators. . . . . . . . . . . . . 24
6.3. Address Ambiguity . . . . . . . . . . . . . . . . . . . 25
7. Router Considerations . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References. . . . . . . . . . . . . . . . . . 26
10.2. Informative References. . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A - Prior Implementations. . . . . . . . . . . . . . . . 28
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 要件。 . . . . . . . . . . . . . . . . . . . . . 3 1.2. 用語. . . . . . . . . . . . . . . . . . . . . . 3 1.3。 適用性. . . . . . . . . . . . . . . . . . . . . 5 1.4。 応用層プロトコル問題. . . . . . . 6 1.5。 自動構成問題。 . . . . . . . . . . . . . . . 7 1.6. 補欠は禁止. . . . . . . . . . . . . . . 7 1.7を使用します。 倍数は.81.8を連結します。 Routableとのコミュニケーションは.81.9を扱います。 いつIPv4 Link地方のAddressを構成しますか? . . . . . 8 2. 選択、ディフェンス、および配送. . . . . . . . . . . 9 2.1を扱ってください。 リンクローカルアドレス選択。 . . . . . . . . . . . . . 10 2.2. リンクローカルアドレスが.112.3であると主張します。 より短いタイムアウト。 . . . . . . . . . . . . . . . . . . . 13 2.4. アドレス. . . . . . . . . . . . . . . . . 13 2.5を発表します。 闘争検出とディフェンス。 . . . . . . . . . . . . 13 2.6. 用法と推進が規則であると扱ってください。 . . . . . . . . . . 14 2.7. リンク地方のパケットは進められません。 . . . . . . . . . 16 2.8. リンク地方のPacketsはLocalです。 . . . . . . . . . . . . . 16 2.9. 上位層プロトコル問題。 . . . . . . . . . 17 2.10. プライバシーの問題。 . . . . . . . . . . . . . . . . . . . 17 2.11. DHCPv4とIPv4のリンク地方の州のマシンとの相互作用。 . . . . . . . . . . . . . . . . . . . . 17 3. 複数のインタフェースへの問題。 . . . . . . . . . . . 18 3.1. アドレスを見ました。 . . . . . . . . . . . . . . . . . . . 18 3.2. あいまいさ. . . . . . . . . . . . . . . . . . . 19 3.3を扱ってください。 Routableアドレスをもっているホストとの相互作用。 . . . . 20 3.4. 意図的でない自己免疫反応. . . . . . . . . . . 21 4。 ネットワークパーティション. . . . . . . . . . . . . . . . 22 5を回復させます。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 6。 アプリケーションプログラミング問題。 . . . . . . . . . . . 24 6.1. 変化、失敗、および回復. . . . . . . . . 24 6.2を扱ってください。 ロケータの株式会社推進。 . . . . . . . . . . . . 24 6.3. あいまいさ. . . . . . . . . . . . . . . . . . . 25 7を扱ってください。 ルータ問題. . . . . . . . . . . . . . . . . . . . 25 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 25 9。 定数. . . . . . . . . . . . . . . . . . . . . . . . . . 26 10。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. 引用規格。 . . . . . . . . . . . . . . . . . 26 10.2. 有益な参照。 . . . . . . . . . . . . . . . . 26の承認. . . . . . . . . . . . . . . . . . . . . . . . . 27の付録A--先の実装。 . . . . . . . . . . . . . . . 28
Cheshire, et al. Standards Track [Page 2] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[2ページ]RFC3927IPv4
1. Introduction
1. 序論
As the Internet Protocol continues to grow in popularity, it becomes increasingly valuable to be able to use familiar IP tools such as FTP not only for global communication, but for local communication as well. For example, two people with laptop computers supporting IEEE 802.11 Wireless LANs [802.11] may meet and wish to exchange files. It is desirable for these people to be able to use IP application software without the inconvenience of having to manually configure static IP addresses or set up a DHCP server [RFC2131].
インターネットプロトコルが、人気で成長し続けているのに従って、グローバルコミュニケーションだけではなく、また、ローカルのコミュニケーションのためにFTPなどのも身近なIPツールを使用できるのはますます貴重になります。 例えば、ラップトップコンピュータが、IEEE802.11がWireless LAN[802.11]であるとサポートしている2人の人が、会って、ファイルを交換したがっているかもしれません。 これらの人々が手動で静的IPアドレスを構成しなければならない不便なしでIPアプリケーション・ソフトを使用するか、またはDHCPサーバ[RFC2131]をセットアップできるのが、望ましいです。
This document describes a method by which a host may automatically configure an interface with an IPv4 address in the 169.254/16 prefix that is valid for Link-Local communication on that interface. This is especially valuable in environments where no other configuration mechanism is available. The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. Allocation of IPv6 Link-Local addresses is described in "IPv6 Stateless Address Autoconfiguration" [RFC2462].
このドキュメントはホストが自動的にそのインタフェースに関するLinkローカルのコミュニケーションに、有効な169.254/16接頭語のIPv4アドレスとのインタフェースを構成するかもしれないメソッドを説明します。 これは他の構成メカニズムがないのが入手できるところで環境で特に貴重です。 IPv4接頭語169.254/16はこのためにIANAに登録されます。 IPv6 Linkローカルのアドレスの配分は「IPv6の状態がないアドレス自動構成」[RFC2462]で説明されます。
Link-Local communication using IPv4 Link-Local addresses is only suitable for communication with other devices connected to the same physical (or logical) link. Link-Local communication using IPv4 Link-Local addresses is not suitable for communication with devices not directly connected to the same physical (or logical) link.
IPv4 Linkローカルのアドレスを使用するリンクローカルのコミュニケーションは単に同じ物理的で(論理的)のリンクに接続される対向機器とのコミュニケーションに適しています。 IPv4 Linkローカルのアドレスを使用するリンクローカルのコミュニケーションは直接同じ物理的で(論理的)のリンクに接続されないデバイスとのコミュニケーションに適していません。
Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already support this capability. This document standardizes usage, prescribing rules for how IPv4 Link-Local addresses are to be treated by hosts and routers. In particular, it describes how routers are to behave when receiving packets with IPv4 Link-Local addresses in the source or destination address. With respect to hosts, it discusses claiming and defending addresses, maintaining Link-Local and routable IPv4 addresses on the same interface, and multi-homing issues.
マイクロソフトWindows 98(後で)とMacOS8.5(後で)は既にこの能力をサポートします。 ホストとルータによってどう扱われるかためにIPv4 Linkローカルのアドレスがことである規則を定めて、このドキュメントは用法を標準化します。 特に、それはIPv4 Linkローカルのアドレスがソースか送付先アドレスにある状態でパケットを受けるとき、振る舞うルータがことである方法を説明します。 ホストに関して、アドレスを要求して、防御するのを議論します、同じインタフェース、およびマルチホーミング問題に関するLink地方とroutable IPv4アドレスを維持して。
1.1. Requirements
1.1. 要件
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" [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは「RFCsにおける使用のためのキーワード」[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Terminology
1.2. 用語
This document describes Link-Local addressing, for IPv4 communication between two hosts on a single link. A set of hosts is considered to be "on the same link", if:
このドキュメントは単一のリンクの上の2人のホストのIPv4コミュニケーションのためにLinkローカルのアドレシングを説明します。 1セットのホストが「同じリンク」にいると考えられる、:
Cheshire, et al. Standards Track [Page 3] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[3ページ]RFC3927IPv4
- when any host A from that set sends a packet to any other host B
in that set, using unicast, multicast, or broadcast, the entire
link-layer packet payload arrives unmodified, and
- そしてそのセットからのどんなホストAもユニキャスト、マルチキャスト、または放送を使用して、設定されるのでいかなる他のホストBにもパケットを送るとき、全体のリンクレイヤパケットペイロードが変更されていなく届く。
- a broadcast sent over that link by any host from that set of hosts
can be received by every other host in that set
- すべての他のホストが、設定されるので、それからのどんなホストによるリンクも設定した移動されたホストの放送を受けることができます。
The link-layer *header* may be modified, such as in Token Ring Source Routing [802.5], but not the link-layer *payload*. In particular, if any device forwarding a packet modifies any part of the IP header or IP payload then the packet is no longer considered to be on the same link. This means that the packet may pass through devices such as repeaters, bridges, hubs or switches and still be considered to be on the same link for the purpose of this document, but not through a device such as an IP router that decrements the TTL or otherwise modifies the IP header.
リンクレイヤ*ヘッダー*は変更されるかもしれません、リンクレイヤ*ペイロード*ではなく、Token Ring Sourceルート設定[802.5]などのように。パケットを進めるどれかデバイスが何かIPヘッダーかIPペイロードの一部分を変更するなら、特に、もう同じリンクの上にパケットがあると考えられません。 これは、パケットがリピータ、ブリッジ、ハブまたはスイッチなどのデバイスを通り抜けるかもしれなくて、このドキュメントの目的のための同じリンクの上にあるとまだ考えられていますが、TTLを減少させるか、またはそうでなければIPヘッダーを変更するIPルータなどのデバイスを通して考えられるというわけではないことを意味します。
This document uses the term "routable address" to refer to all valid unicast IPv4 addresses outside the 169.254/16 prefix that may be forwarded via routers. This includes all global IP addresses and private addresses such as Net 10/8 [RFC1918], but not loopback addresses such as 127.0.0.1.
このドキュメントは、ルータで進められるかもしれない169.254/16接頭語の外ですべての有効なユニキャストIPv4アドレスを参照するのに「発送可能アドレス」という用語を使用します。 これはすべてのグローバルIPアドレスを含んでいます、そして、兵卒はネット10/8などのように127.0などのループバックアドレスではなく、[RFC1918]が.0であると.1に扱います。
Wherever this document uses the term "host" when describing use of IPv4 Link-Local addresses, the text applies equally to routers when they are the source of or intended destination of packets containing IPv4 Link-Local source or destination addresses.
このドキュメントがIPv4 Link-地元筋か送付先アドレスを含むパケットについて「ホスト」というそれらがIPv4 Linkローカルのアドレスの使用について説明して、テキストが等しくルータに適用されるソースである用語を使用したか、または目的地を意図したどこ。
Wherever this document uses the term "sender IP address" or "target IP address" in the context of an ARP packet, it is referring to the fields of the ARP packet identified in the ARP specification [RFC826] as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target Protocol Address) respectively. For the usage of ARP described in this document, each of these fields always contains an IP address.
どこでも、このドキュメントが文脈で「送付者IPアドレス」か「目標IPアドレス」という用語を使用するところと、ARPパケットでは、それは「ar$鉱泉」(送付者プロトコルAddress)と「ar$tpa」(目標プロトコルAddress)としてARP仕様[RFC826]でそれぞれ特定されたARPパケットの野原を呼んでいます。 本書では説明されたARPの使用法のために、それぞれのこれらの分野はいつもIPアドレスを含んでいます。
In this document, the term "ARP Probe" is used to refer to an ARP Request packet, broadcast on the local link, with an all-zero 'sender IP address'. The 'sender hardware address' MUST contain the hardware address of the interface sending the packet. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP address' field MUST be set to the address being probed.
本書では、用語「ARPは調べること」が、オールゼロ'送付者IPアドレス'で地方のリンクの上に放送されたARP Requestパケットについて言及するのに使用されます。 '送付者ハードウェア・アドレス'はパケットを送るインタフェースのハードウェア・アドレスを含まなければなりません。 '目標ハードウェアアドレス'分野が無視される、SHOULD、すべてのゼロに設定されてください。 '目標IPアドレス'分野を調べられるアドレスに設定しなければなりません。
In this document, the term "ARP Announcement" is used to refer to an ARP Request packet, broadcast on the local link, identical to the ARP Probe described above, except that both the sender and target IP address fields contain the IP address being announced.
本書では、「ARP発表」という用語は地方のリンクの上に放送された上で説明されたARP Probeと同じARP Requestパケットについて言及するのに使用されます、送付者と目標IPアドレス・フィールドの両方が発表されるIPアドレスを含んでいるのを除いて。
Cheshire, et al. Standards Track [Page 4] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[4ページ]RFC3927IPv4
Constants are introduced in all capital letters. Their values are given in Section 9.
すべての大文字で定数を導入します。 セクション9でそれらの値を与えます。
1.3. Applicability
1.3. 適用性
This specification applies to all IEEE 802 Local Area Networks (LANs) [802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11 wireless LANs [802.11], as well as to other link-layer technologies that operate at data rates of at least 1 Mbps, have a round-trip latency of at most one second, and support ARP [RFC826]. Wherever this document uses the term "IEEE 802", the text applies equally to any of these network technologies.
この仕様はすべてのIEEE802ローカル・エリア・ネットワーク(LAN)[802]に適用されます、イーサネット[802.3]、Token-リング[802.5]、およびIEEE802.11無線LAN[802.11]を含んでいて、よく少なくとも1Mbpsのデータ信号速度で作動して、高々1秒の往復の潜在を持って、ARP[RFC826]をサポートする他のリンクレイヤ技術のように。 このドキュメントがどこで「IEEE802」という用語を使用しても、テキストは等しくこれらのネットワーク技術のいずれにも適用されます。
Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the following parameters:
ARPをサポートしますが、レートで1Mbpsを操作するリンクレイヤ技術か1秒より上における潜在が、以下のパラメタに異価を指定する必要があるかもしれません:
(a) the number of, and interval between, ARP probes, see PROBE_NUM,
PROBE_MIN, PROBE_MAX defined in Section 2.2.1
(a) 数、PROBE_ヌム、PROBE_MIN、MAXがセクション2.2.1で定義したPROBE_は、間の間隔にARPが調べるのを見ます。
(b) the number of, and interval between, ARP announcements, see
ANNOUNCE_NUM and ANNOUNCE_INTERVAL defined in Section 2.4
(b) 数、間の間隔(ARP発表)は、ANNOUNCE_NUMとANNOUNCE_INTERVALがセクション2.4で定義されるのを見ます。
(c) the maximum rate at which address claiming may be attempted, see
RATE_LIMIT_INTERVAL and MAX_CONFLICTS defined in Section 2.2.1
(c) RATE_LIMIT_INTERVALが、アドレス要求が試みられるかもしれないのを見る最高率とCONFLICTSがセクション2.2.1で定義したマックス_
(d) the time interval between conflicting ARPs below which a host
MUST reconfigure instead of attempting to defend its address, see
DEFEND_INTERVAL defined in Section 2.5
(d) セクション2.5で定義されたDEFEND_INTERVALが、ホストが防御するのを試みることの代わりにアドレスを再構成しなければならないのを見る闘争ARPsの間の時間間隔
Link-layer technologies that do not support ARP may be able to use other techniques for determining whether a particular IP address is currently in use. However, the application of claim-and-defend mechanisms to such networks is outside the scope of this document.
ARPをサポートしないリンクレイヤ技術は、特定のIPアドレスが現在使用中であるかどうか決定するのに他のテクニックを使用できるかもしれません。 そのようなネットワークにメカニズムを要求して、防御してください。しかしながら、アプリケーション、このドキュメントの範囲の外にあります。
This specification is intended for use with small ad hoc networks -- a single link containing only a few hosts. Although 65024 IPv4 Link-Local addresses are available in principle, attempting to use all those addresses on a single link would result in a high probability of address conflicts, requiring a host to take an inordinate amount of time to find an available address.
この仕様は分類広告hocネットワークによる使用のために意図します--ほんの数人のホストを含む単一のリンク。 65024のIPv4 Linkローカルのアドレスが原則として利用可能ですが、単一のリンクの上にそれらのすべてのアドレスを使用するのを試みるのがアドレス闘争の高い確率をもたらすでしょう、利用可能なアドレスを見つけるのにホストが途方もない時間を取るのが必要であることで。
Network operators with more than 1300 hosts on a single link may want to consider dividing that single link into two or more subnets. A host connecting to a link that already has 1300 hosts, selecting an IPv4 Link-Local address at random, has a 98% chance of selecting an unused IPv4 Link-Local address on the first try. A host has a 99.96%
1300人以上のホストが単一のリンクの上にいるネットワーク・オペレータは、そんなに単一の2へのリンクか以上サブネットを分割すると考えたがっているかもしれません。 無作為にIPv4 Link-ローカルアドレスを選択して、1300人のホストが既にいるリンクに接続するホストは一度で未使用のIPv4 Link-ローカルアドレスを選択するという98%の確率を持っています。 ホストには、99.96%があります。
Cheshire, et al. Standards Track [Page 5] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[5ページ]RFC3927IPv4
chance of selecting an unused IPv4 Link-Local address within two tries. The probability that it will have to try more than ten times is about 1 in 10^17.
2の中で未使用のIPv4 Link-ローカルアドレスを選択するという機会は試みます。 試みなければならないという10回以上の確率は10^17のうちのおよそ1です。
1.4. Application Layer Protocol Considerations
1.4. 応用層プロトコル問題
IPv4 Link-Local addresses and their dynamic configuration have profound implications upon applications which use them. This is discussed in Section 6. Many applications fundamentally assume that addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 Link-Local addresses, or a mixture of Link-Local and routable IPv4 addresses.
IPv4 Linkローカルのアドレスとそれらの動的設定はそれらを使用するアプリケーションに深遠な含意を持っています。 セクション6でこれについて議論します。 多くのアプリケーションが、交信している同輩のアドレスが発送可能で、比較的変らなくユニークであると基本的に仮定します。 これらの仮定はもうIPv4 Linkローカルの講演、またはLink地方とroutable IPv4アドレスの混合物に賛成しません。
Therefore while many applications will work properly with IPv4 Link- Local addresses, or a mixture of Link-Local and routable IPv4 addresses, others may do so only after modification, or will exhibit reduced or partial functionality.
したがって、多くのアプリケーションがIPv4 Linkのローカルのアドレスか、Link地方とroutable IPv4アドレスの混合物で適切に動作している間、他のものは単に変更の後にそうするかもしれないか、減少したか部分的な機能性を示すでしょう。
In some cases it may be infeasible for the application to be modified to operate under such conditions.
いくつかの場合、アプリケーションがそのような条件のもとで作動するように変更されるのは、実行不可能であるかもしれません。
IPv4 Link-Local addresses should therefore only be used where stable, routable addresses are not available (such as on ad hoc or isolated networks) or in controlled situations where these limitations and their impact on applications are understood and accepted. This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.
したがって、IPv4 Linkローカルのアドレスは安定して、発送可能なアドレスが入手できない(臨時の、または、孤立しているネットワークなどの)ところかこれらの制限とアプリケーションでのそれらの影響が理解されて、受け入れられる制御状況で使用されるだけであるべきです。 このドキュメントは、IPv4 Linkローカルのアドレスと発送可能アドレスが同時に同じインタフェースで構成されることを勧めません。
Use of IPv4 Link-Local addresses in off-link communication is likely to cause application failures. This can occur within any application that includes embedded addresses, if an IPv4 Link-Local address is embedded when communicating with a host that is not on the link. Examples of applications that embed addresses include IPsec, Kerberos 4/5, FTP, RSVP, SMTP, SIP, X-Windows/Xterm/Telnet, Real Audio, H.323, and SNMP [RFC3027].
オフリンクコミュニケーションにおけるIPv4 Linkローカルのアドレスの使用はアプリケーション失敗を引き起こしそうです。 これは埋め込まれたアドレスを含んでいるどんなアプリケーションの中にも起こることができます、リンクの上にいないホストとコミュニケートするとき、IPv4 Link-ローカルアドレスが埋め込まれるなら。 アドレスを埋め込むアプリケーションに関する例はレアルのIPsec、ケルベロス4/5、FTP、RSVP、SMTP、SIP、Xウィンドウ/Xterm/telnet、Audio、H.323、およびSNMP[RFC3027]を含んでいます。
To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised:
オフリンクコミュニケーションにおけるIPv4 Linkローカルのアドレスの使用を排除するために、以下の警告的な測定はアドバイスされます:
a. IPv4 Link-Local addresses MUST NOT be configured in the DNS.
Mapping from IPv4 addresses to host names is conventionally done
by issuing DNS queries for names of the form,
"x.x.x.x.in-addr.arpa." When used for link-local addresses, which
have significance only on the local link, it is inappropriate to
send such DNS queries beyond the local link. DNS clients MUST NOT
send DNS queries for any name that falls within the
"254.169.in-addr.arpa." domain.
a。 DNSでIPv4 Linkローカルのアドレスを構成してはいけません。 IPv4から、アドレスは、ホスト名にフォームの名前のための質問、「addr.arpaのx.x.x.x.」をDNSに発行することによって、慣習上写像されます。 リンクローカルのアドレス(地方のリンクだけの上に意味を持っている)に使用されると、地方のリンクを超えてそのようなDNS質問を送るのは不適当です。 DNSクライアントは"254.169.in-addr.arpa"の中に落ちるいずれのための質問が命名するDNSに. ドメインを送ってはいけません。
Cheshire, et al. Standards Track [Page 6] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[6ページ]RFC3927IPv4
DNS recursive name servers receiving queries from non-compliant
clients for names within the "254.169.in-addr.arpa." domain MUST
by default return RCODE 3, authoritatively asserting that no such
name exists in the Domain Name System.
. ドメインがデフォルトでそうしなければならない"254.169.in-addr.arpa"の中の名前のために不従順なクライアントから質問を受けるDNSの再帰的なネームサーバがRCODE3を返します、どんなそのような名前もドメインネームシステムで存在しないと厳然と断言して。
b. Names that are globally resolvable to routable addresses should be
used within applications whenever they are available. Names that
are resolvable only on the local link (such as through use of
protocols such as Link Local Multicast Name Resolution [LLMNR])
MUST NOT be used in off-link communication. IPv4 addresses and
names that can only be resolved on the local link SHOULD NOT be
forwarded beyond the local link. IPv4 Link-Local addresses SHOULD
only be sent when a Link-Local address is used as the source
and/or destination address. This strong advice should hinder
limited scope addresses and names from leaving the context in
which they apply.
b。 それらが利用可能であるときはいつも、アドレスを発送可能することにおいてグローバルに溶解性であることの名前はアプリケーションの中で使用されるべきです。 オフリンクコミュニケーションで地方のリンク(Link Local Multicast Name Resolution[LLMNR]などのプロトコルの使用などの)だけで溶解性であることの名前を使用してはいけません。 ローカルの上で決議できるだけであるIPv4アドレスと名前は進められた以遠が地方のリンクであったならSHOULD NOTをリンクします。 IPv4 Link-ローカルはSHOULDを扱います。ソース、そして/または、送付先アドレスとしてLink-ローカルアドレスを使用するときには単に送ってください。 この強いアドバイスは、限られた範囲アドレスと名前がそれらが適用する文脈を残すのを妨げるべきです。
c. If names resolvable to globally routable addresses are not
available, but the globally routable addresses are, they should be
used instead of IPv4 Link-Local addresses.
c。 アドレスをグローバルに発送可能することにおける溶解性の名前が利用可能ではありませんが、グローバルに発送可能なアドレスが利用可能であるなら、それらはIPv4 Linkローカルのアドレスの代わりに使用されるべきです。
1.5. Autoconfiguration Issues
1.5. 自動構成問題
Implementations of IPv4 Link-Local address autoconfiguration MUST expect address conflicts, and MUST be prepared to handle them gracefully by automatically selecting a new address whenever a conflict is detected, as described in Section 2. This requirement to detect and handle address conflicts applies during the entire period that a host is using a 169.254/16 IPv4 Link-Local address, not just during initial interface configuration. For example, address conflicts can occur well after a host has completed booting if two previously separate networks are joined, as described in Section 4.
IPv4 Link-ローカルアドレス自動構成の実装をアドレス闘争を予想しなければならなくて、闘争が検出されるときはいつも、自動的に新しいアドレスを選択することによって優雅にそれらを扱うように準備しなければなりません、セクション2で説明されるように。 アドレス闘争を検出して、扱うというこの要件は初期のインタフェース構成だけの間適用するのではなく、ホストが169.254/16IPv4 Link-ローカルアドレスを使用する全体の期間、適用されます。 例えば、2つの以前に別々のネットワークが加わられるならホストが、ブートするのを完了した後にアドレス闘争はよく起こることができます、セクション4で説明されるように。
1.6. Alternate Use Prohibition
1.6. 補欠は禁止を使用します。
Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually or by a DHCP server. Manual or DHCP configuration may cause a host to use an address in the 169.254/16 prefix without following the special rules regarding duplicate detection and automatic configuration that pertain to addresses in this prefix. While the DHCP specification [RFC2131] indicates that a DHCP client SHOULD probe a newly received address with ARP, this is not mandatory. Similarly, while the DHCP specification recommends that a DHCP server SHOULD probe an address using an ICMP Echo Request before allocating it, this is also not mandatory, and even if the server does this, IPv4 Link-Local addresses are not routable, so a DHCP server not directly connected to a link cannot detect whether a host on that link is already using the desired IPv4 Link-Local address.
169.254/16接頭語SHOULD NOTのアドレスが手動かDHCPサーバによって構成されることに注意してください。マニュアルかDHCP構成で、アドレスに関係する写し検出と自動構成に関する特別な規則に従わないで、ホストは169.254/16接頭語にアドレスをこの接頭語に使用してもよいです。 DHCP仕様[RFC2131]は、DHCPクライアントSHOULDがARPと共に新たに受け取られたアドレスを調べるのを示しますが、これは義務的ではありません。 DHCP仕様が、DHCPサーバSHOULDがそれを割り当てる前にICMP Echo Requestを使用することでアドレスを調べることを勧めますが、また、同様に、これも義務的でなく、またサーバがこれをしても、IPv4 Linkローカルのアドレスが発送可能でないので、直接リンクに接続されなかったDHCPサーバは、そのリンクの上のホストが既に必要なIPv4 Link-ローカルアドレスを使用しているかどうか検出できません。
Cheshire, et al. Standards Track [Page 7] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[7ページ]RFC3927IPv4
Administrators wishing to configure their own local addresses (using manual configuration, a DHCP server, or any other mechanism not described in this document) should use one of the existing private address prefixes [RFC1918], not the 169.254/16 prefix.
地元のアドレス(本書では説明されなかった手動の構成、DHCPサーバ、またはいかなる他のメカニズムも使用する)が個人的に存在のものを使用するべきであるのを構成したがっている管理者は、接頭語が169.254/16接頭語ではなく、[RFC1918]であると扱います。
1.7. Multiple Interfaces
1.7. 複数のインタフェース
Additional considerations apply to hosts that support more than one active interface where one or more of these interfaces support IPv4 Link-Local address configuration. These considerations are discussed in Section 3.
追加問題はこれらのインタフェースのものか以上がIPv4 Link-ローカルアドレスが構成であるとサポートする1つ以上のアクティブなインタフェースをサポートするホストに適用されます。 セクション3でこれらの問題について議論します。
1.8. Communication with Routable Addresses
1.8. Routableアドレスとのコミュニケーション
There will be cases when devices with a configured Link-Local address will need to communicate with a device with a routable address configured on the same physical link, and vice versa. The rules in Section 2.6 allow this communication.
構成されたLink-ローカルアドレスがあるデバイスが、発送可能アドレスが同じ物理的なリンクの上に構成にされているのでデバイスとコミュニケートする必要があるとき、ケースがあるでしょう、逆もまた同様に。 セクション2.6の規則はこのコミュニケーションを許容します。
This allows, for example, a laptop computer with only a routable address to communicate with web servers world-wide using its globally-routable address while at the same time printing those web pages on a local printer that has only an IPv4 Link-Local address.
これで、例えば、発送可能アドレスだけがあるラップトップコンピュータは、世界中で同時にIPv4 Link-ローカルアドレスだけを持っているローカルプリンタの上でそれらのウェブページを印刷する間、グローバルに発送可能なアドレスを使用することでウェブサーバーとコミュニケートできます。
1.9. When to configure an IPv4 Link-Local address
1.9. いつIPv4 Link-ローカルアドレスを構成しますか。
Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. The term "operable address" is used to mean an address which works effectively for communication in the current network context (see below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. However, during the transition (in either direction) between using routable and IPv4 Link-Local addresses both MAY be in use at once subject to these rules:
各アドレスがどんな事情で使用されるべきであるかを決定するために適切な道なしでインタフェースに割り当てられた複数の異なった範囲のアドレスを持っているのはアプリケーションのための複雑さとユーザのための混乱に通じます。 リンクに関するアドレスをもっているホストはそのリンクの上のすべての対向機器とコミュニケートできます、それらのデバイスがLinkローカルのアドレスを使用するか、またはアドレスを発送可能することにかかわらず。 これらの理由、ホストSHOULD NOTが同じインタフェースで手術可能な発送可能アドレスとIPv4 Link-ローカルアドレスの両方を構成させるので。 「手術可能なアドレス」という用語は、現在のネットワーク背景のコミュニケーションのために力を発揮するアドレスを意味するのに使用されます(以下を見てください)。 また、手術可能な発送可能アドレスがインタフェースで利用可能であるときに、ホストSHOULD NOTはIPv4 Link-ローカルアドレスをそのインタフェースに割り当てます。 しかしながら、発送可能であってIPv4 Linkローカルのアドレスを使用することの間の変遷(どちらかの方向への)の間、両方がすぐに、これらの規則を条件として使用中であるかもしれません:
1. The assignment of an IPv4 Link-Local address on an interface is
based solely on the state of the interface, and is independent
of any other protocols such as DHCP. A host MUST NOT alter its
behavior and use of other protocols such as DHCP because the
host has assigned an IPv4 Link-Local address to an interface.
1. インタフェースにおけるIPv4 Link-ローカルアドレスの課題は、唯一インタフェースの状態に基づいていて、DHCPなどのいかなる他のプロトコルからも独立しています。 ホストがIPv4 Link-ローカルアドレスをインタフェースに割り当てたので、ホストはDHCPなどの他のプロトコルのその振舞いと使用を変更してはいけません。
Cheshire, et al. Standards Track [Page 8] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[8ページ]RFC3927IPv4
2. If a host finds that an interface that was previously
configured with an IPv4 Link-Local address now has an operable
routable address available, the host MUST use the routable
address when initiating new communications, and MUST cease
advertising the availability of the IPv4 Link-Local address
through whatever mechanisms that address had been made known to
others. The host SHOULD continue to use the IPv4 Link-Local
address for communications already underway, and MAY continue
to accept new communications addressed to the IPv4 Link-Local
address. Ways in which an operable routable address might
become available on an interface include:
2. ホストが、今や以前にIPv4 Link-ローカルアドレスによって構成されたインタフェースが利用可能な手術可能な発送可能アドレスを持っているのがわかるなら、ホストは、新しいコミュニケーションを開始するとき、発送可能アドレスを使用しなければならなくて、そのアドレスにどういったメカニズムがあったかを通して他のものに明らかにされるIPv4 Link-ローカルアドレスの有用性の広告を出して、やまなければなりません。 ホストSHOULDは、コミュニケーションのための既に進行中のIPv4 Link-ローカルアドレスを使用し続けています、そして、IPv4 Link-ローカルアドレスに扱われた新しいコミュニケーションを受け入れ続けるかもしれません。 手術可能な発送可能アドレスがインタフェースで利用可能になるかもしれない方法は:
* Manual configuration
* Address assignment through DHCP
* Roaming of the host to a network on which a previously
assigned address becomes operable
* 以前に割り当てられたアドレスが手術可能になるネットワークへのホストのDHCP*ローミングを通した手動の構成*アドレス課題
3. If a host finds that an interface no longer has an operable
routable address available, the host MAY identify a usable IPv4
Link-Local address (as described in section 2) and assign that
address to the interface. Ways in which an operable routable
address might cease to be available on an interface include:
3. ホストが、インタフェースには利用可能な手術可能な発送可能アドレスがもうないのがわかるなら、ホストは、使用可能なIPv4 Link-ローカルアドレス(セクション2で説明されるように)を特定して、そのアドレスをインタフェースに割り当てるかもしれません。 手術可能な発送可能アドレスがインタフェースで利用可能であることをやめるかもしれない方法は:
* Removal of the address from the interface through
manual configuration
* Expiration of the lease on the address assigned through
DHCP
* Roaming of the host to a new network on which the
address is no longer operable.
* インタフェースから手動のアドレスにおける構成*借用期限の終了によるアドレスの取り外しはDHCP*を通してアドレスがもう手術可能でない新しいネットワークにホストのローミングを配属しました。
The determination by the system of whether an address is "operable" is not clear cut and many changes in the system context (e.g., router changes) may affect the operability of an address. In particular roaming of a host from one network to another is likely -- but not certain -- to change the operability of a configured address but detecting such a move is not always trivial.
アドレスが「手術可能であるかどうか」に関するシステムによる決断は切れてください。そうすれば、システムの背景(例えば、ルータ変化)における多くの変化がアドレスの運転可能性に影響してもよいのが明確ではありません。 1つのネットワークから別のネットワークまでのホストのローミングは、構成されたアドレスにもかかわらず、そのような移動を検出する運転可能性を変えるのがいつも些細であるというわけではないことを特に、ありそうですが、確信していません。
"Detection of Network Attachment (DNA) in IPv4" [DNAv4] provides further discussion of address assignment and operability determination.
「IPv4"[DNAv4]でのNetwork Attachment(DNA)の検出はアドレス課題と運転可能性決断のさらなる議論を提供します。」
2. Address Selection, Defense and Delivery
2. アドレス選択、ディフェンス、および配送
The following section explains the IPv4 Link-Local address selection algorithm, how IPv4 Link-Local addresses are defended, and how IPv4 packets with IPv4 Link-Local addresses are delivered.
以下のセクションはIPv4 Link-ローカルアドレス選択アルゴリズムと、IPv4 LinkローカルのアドレスがあるIPv4パケットがIPv4 Linkローカルのアドレスがどう防御されるか、そして、どう提供されるかを説明します。
Cheshire, et al. Standards Track [Page 9] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[9ページ]RFC3927IPv4
Windows and Mac OS hosts that already implement Link-Local IPv4 address auto-configuration are compatible with the rules presented in this section. However, should any interoperability problem be discovered, this document, not any prior implementation, defines the standard.
WindowsとLink地方のIPv4がアドレス自動構成であると既に実装するMac OSホストはこのセクションに提示される規則と互換性があります。 しかしながら、どんな先の実装ではなく、このドキュメントも何か相互運用性問題が発見されるなら規格を定義します。
2.1. Link-Local Address Selection
2.1. リンクローカルアドレス選択
When a host wishes to configure an IPv4 Link-Local address, it selects an address using a pseudo-random number generator with a uniform distribution in the range from 169.254.1.0 to 169.254.254.255 inclusive.
ホストがIPv4 Link-ローカルアドレスを構成したがっているとき、範囲の一様分布と共に169.254から疑似乱数生成器を使用することでアドレスを選択する、.1、.0、169.254 .254 .255 包括的です。
The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. The first 256 and last 256 addresses in the 169.254/16 prefix are reserved for future use and MUST NOT be selected by a host using this dynamic configuration mechanism.
IPv4接頭語169.254/16はこのためにIANAに登録されます。 この動的設定メカニズムを使用して、169.254/16接頭語における最初の256と最後の256のアドレスを、今後の使用のために予約して、ホストは選択してはいけません。
The pseudo-random number generation algorithm MUST be chosen so that different hosts do not generate the same sequence of numbers. If the host has access to persistent information that is different for each host, such as its IEEE 802 MAC address, then the pseudo-random number generator SHOULD be seeded using a value derived from this information. This means that even without using any other persistent storage, a host will usually select the same IPv4 Link-Local address each time it is booted, which can be convenient for debugging and other operational reasons. Seeding the pseudo-random number generator using the real-time clock or any other information which is (or may be) identical in every host is NOT suitable for this purpose, because a group of hosts that are all powered on at the same time might then all generate the same sequence, resulting in a never- ending series of conflicts as the hosts move in lock-step through exactly the same pseudo-random sequence, conflicting on every address they probe.
擬似乱数世代アルゴリズムを選ばなければならないので、異なったホストは同じ数列を生成しません。 ホストが異なった永続的な情報に近づく手段を持っているなら、IEEE802MACアドレス、次に、疑似乱数生成器SHOULDなどの各ホストに関して、この情報から得られた値を使用することで種を蒔かれてください。 いかなる他の永続的なストレージも使用さえしないで、これはそれを意味して、通常、ホストはそれが起動されている各回同じIPv4 Link-ローカルアドレスを選択するでしょう(デバッグと他の操作上の理由で便利である場合があります)。 すべてのホストで同じ状態でリアルタイム時計かそうするいかなる他の情報(または、あるかもしれない)も使用することで疑似乱数生成器に種を蒔くのはこのために適当ではありません、次に、同時に電源を入れられているホストの皆、グループが同じ系列をすべて生成するかもしれないので、ホストがまさに同じ擬似ランダム系列を通して型にはまったやり方に入って来るのに従って決して終わっていないシリーズの闘争をもたらして、彼らが調べるあらゆるアドレスで闘争して。
Hosts that are equipped with persistent storage MAY, for each interface, record the IPv4 address they have selected. On booting, hosts with a previously recorded address SHOULD use that address as their first candidate when probing. This increases the stability of addresses. For example, if a group of hosts are powered off at night, then when they are powered on the next morning they will all resume using the same addresses, instead of picking different addresses and potentially having to resolve conflicts that arise.
永続的なストレージを備えているホストは彼らが選択したIPv4アドレスを各インタフェースに記録するかもしれません。 調べるとき、穂ばらみでは、以前に記録されたアドレスSHOULDのホストは彼らの最初の候補としてそのアドレスを使用します。 これはアドレスの安定性を増強します。 ホストのグループが夜動力付きであり、次に、翌朝に動かされるとき彼らが皆、同じアドレスを使用するのを再開するということであるなら、例えば、異なったアドレスを選んで、潜在的に選ばなければならないことの代わりに起こる闘争を解決してください。
Cheshire, et al. Standards Track [Page 10] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[10ページ]RFC3927IPv4
2.2. Claiming a Link-Local Address
2.2. リンクローカルアドレスを要求します。
After it has selected an IPv4 Link-Local address, a host MUST test to see if the IPv4 Link-Local address is already in use before beginning to use it. When a network interface transitions from an inactive to an active state, the host does not have knowledge of what IPv4 Link- Local addresses may currently be in use on that link, since the point of attachment may have changed or the network interface may have been inactive when a conflicting address was claimed.
IPv4 Link-ローカルアドレスを選択した後に、ホストは、それを使用し始める前にIPv4 Link-ローカルアドレスが既に使用中であるかどうか確認するためにテストしなければなりません。 ネットワーク・インターフェースがいつから移行するか、活動的な状態に不活発です、ホストはどんなIPv4 Linkのローカルのアドレスが現在それで使用中であるかもしれないかに関する知識をリンクさせません、闘争アドレスが要求されたとき、接着点が変化したかもしれないか、またはネットワーク・インターフェースが不活発であったかもしれないので。
Were the host to immediately begin using an IPv4 Link-Local address which is already in use by another host, this would be disruptive to that other host. Since it is possible that the host has changed its point of attachment, a routable address may be obtainable on the new network, and therefore it cannot be assumed that an IPv4 Link-Local address is to be preferred.
ホストがすぐに別のホストで既に使用中のIPv4 Link-ローカルアドレスを使用し始めるなら、その他のホストにとって、これは破壊的でしょうに。 ホストが接着点を変えたのが、可能であるので、発送可能アドレスは新しいネットワークで入手可能であるかもしれません、そして、したがって、IPv4 Link-ローカルアドレスが好まれることであると思うことができません。
Before using the IPv4 Link-Local address (e.g., using it as the source address in an IPv4 packet, or as the Sender IPv4 address in an ARP packet) a host MUST perform the probing test described below to achieve better confidence that using the IPv4 Link-Local address will not cause disruption.
IPv4 Link-ローカルアドレス(例えば、IPv4パケットのソースアドレスとして、または、ARPパケットのSender IPv4アドレスとしてそれを使用する)を使用する前に、ホストはテストがIPv4 Link-ローカルアドレスを使用するのが分裂を引き起こさないというより良い信用を達成するために以下で説明した調べを実行しなければなりません。
Examples of events that involve an interface becoming active include:
アクティブになるインタフェースにかかわるイベントに関する例は:
Reboot/startup
Wake from sleep (if network interface was inactive during sleep)
Bringing up previously inactive network interface
IEEE 802 hardware link-state change (appropriate for the
media type and security mechanisms which apply) indicates
that an interface has become active.
Association with a wireless base station or ad hoc network.
以前に(適用されるメディアタイプとセキュリティー対策に適切)で不活発なネットワークインタフェースIEEE802ハードウェアリンク州の変化を持って来る睡眠(ネットワーク・インターフェースが睡眠の間、不活発であったなら)からのリブート/始動和氣は、インタフェースがアクティブになったのを示します。 ワイヤレスの基地局か臨時のネットワークとの協会。
A host MUST NOT perform this check periodically as a matter of course. This would be a waste of network bandwidth, and is unnecessary due to the ability of hosts to passively discover conflicts, as described in Section 2.5.
ホストは当然のこととしてこのチェックを定期的に実行してはいけません。 これは、ネットワーク回線容量の浪費であるだろう、ホストが闘争を受け身に発見する能力のために不要です、セクション2.5で説明されるように。
2.2.1. Probe details
2.2.1. 詳細を調べてください。
On a link-layer such as IEEE 802 that supports ARP, conflict detection is done using ARP probes. On link-layer technologies that do not support ARP other techniques may be available for determining whether a particular IPv4 address is currently in use. However, the application of claim-and-defend mechanisms to such networks is outside the scope of this document.
ARPをサポートするIEEE802などのリンクレイヤでは、闘争検出はARP探測装置を使用し終わっています。 ARPをサポートしないリンクレイヤ技術では、特定のIPv4アドレスが現在使用中であるかどうか決定するのに他のテクニックは利用可能であるかもしれません。 そのようなネットワークにメカニズムを要求して、防御してください。しかしながら、アプリケーション、このドキュメントの範囲の外にあります。
Cheshire, et al. Standards Track [Page 11] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[11ページ]RFC3927IPv4
A host probes to see if an address is already in use by broadcasting an ARP Request for the desired address. The client MUST fill in the 'sender hardware address' field of the ARP Request with the hardware address of the interface through which it is sending the packet. The 'sender IP address' field MUST be set to all zeroes, to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP address' field MUST be set to the address being probed. An ARP Request constructed this way with an all-zero 'sender IP address' is referred to as an "ARP Probe".
ホストは、アドレスが必要なアドレスのためにARP Requestを放送することによって既に使用中であるかどうか確認するために調べます。 クライアントはそれがパケットを送るインタフェースのハードウェア・アドレスでARP Requestの'送付者ハードウェア・アドレス'分野に記入しなければなりません。 '送付者IPアドレス'分野を同じリンクで他のホストでアドレスが既に別のホストによる使用であるように判明する場合でARPキャッシュを汚染するのを避けるようにすべてのゼロに設定しなければなりません。 '目標ハードウェアアドレス'分野が無視される、SHOULD、すべてのゼロに設定されてください。 '目標IPアドレス'分野を調べられるアドレスに設定しなければなりません。 オールゼロ'送付者IPアドレス'でこのように組み立てられたARP Requestは「ARP徹底的調査」と呼ばれます。
When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to PROBE_WAIT seconds, and should then send PROBE_NUM probe packets, each of these probe packets spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. If during this period, from the beginning of the probing process until ANNOUNCE_WAIT seconds after the last probe packet is sent, the host receives any ARP packet (Request *or* Reply) on the interface where the probe is being performed where the packet's 'sender IP address' is the address being probed for, then the host MUST treat this address as being in use by some other host, and MUST select a new pseudo-random address and repeat the process. In addition, if during this period the host receives any ARP Probe where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of the interface the host is attempting to configure, then the host MUST similarly treat this as an address conflict and select a new address as above. This can occur if two (or more) hosts attempt to configure the same IPv4 Link-Local address at the same time.
調べる準備ができ始めるなら、範囲ゼロでPROBE_WAIT秒まで一様に選択されて、ホストは無作為の時間間隔の間、待つべきです、そして、次に、PROBE_NUMに徹底的調査パケットを送るべきです、手当たりしだいに区切られた、それぞれのこれらの徹底的調査パケット、PROBE_MAX秒離れてへのPROBE_MIN。 調べプロセスの始まりから最後の徹底的調査パケットを送ったANNOUNCE_WAIT秒後までホストがこの期間、探測装置がパケットの'送付者IPアドレス'が調べられるアドレスであるところで実行されているインタフェースで何かARPパケット(**を要求するか、または返答する)を受けるなら、ホストは、ある他のホストで使用中であるとしてこのアドレスを扱わなければならなくて、新しい擬似ランダムアドレスを選択して、プロセスを繰り返さなければなりません。 さらに、ホストは、この期間、ホストがパケットの'目標IPアドレス'が調べられるアドレスであるどんなARP Probeも受け取って、パケットの'送付者ハードウェア・アドレス'がホストが構成するのを試みているインタフェースのハードウェア・アドレスでないなら同様にアドレス闘争としてこれを扱って、上の新しいアドレスを選択しなければなりません。 2人(さらに)のホストが、同時に同じIPv4 Link-ローカルアドレスを構成するのを試みるなら、これは起こることができます。
A host should maintain a counter of the number of address conflicts it has experienced in the process of trying to acquire an address, and if the number of conflicts exceeds MAX_CONFLICTS then the host MUST limit the rate at which it probes for new addresses to no more than one new address per RATE_LIMIT_INTERVAL. This is to prevent catastrophic ARP storms in pathological failure cases, such as a rogue host that answers all ARP probes, causing legitimate hosts to go into an infinite loop attempting to select a usable address.
ホストはアドレスを習得しようとすることの途中にそれが経験したアドレス闘争の数のカウンタを維持するべきです、そして、闘争の数がマックス_CONFLICTSを超えているなら、ホストはそれが新しいアドレスのためにRATE_LIMIT_INTERVALあたり1つ未満の新しいアドレスに調べられるレートを制限しなければなりません。 これは病理学的な失敗事件における壊滅的なARP嵐を防ぐためのものです、すべてのARP徹底的調査に答える凶暴なホストのように、使用可能なアドレスを選択するのを試みに正統のホストが無限ループに行くことを引き起こして。
If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP Probe no conflicting ARP Reply or ARP Probe has been received, then the host has successfully claimed the desired IPv4 Link-Local address.
次に、ホストが闘争の最後のARP ProbeノーARP ReplyかARP Probeのトランスミッションを受けた後にANNOUNCE_WAIT秒までに首尾よく必要なIPv4 Link-ローカルアドレスを要求したなら。
Cheshire, et al. Standards Track [Page 12] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[12ページ]RFC3927IPv4
2.3. Shorter Timeouts
2.3. より短いタイムアウト
Network technologies may emerge for which shorter delays are appropriate than those required by this document. A subsequent IETF publication may be produced providing guidelines for different values for PROBE_WAIT, PROBE_NUM, PROBE_MIN and PROBE_MAX on those technologies.
どちらのこのドキュメントによって必要とされたものより少しな遅れが適切であるかので、ネットワーク技術は現れるかもしれません。 その後のIETF出版物は、それらの技術でPROBE_WAIT、PROBE_ヌム、PROBE_MIN、およびPROBE_MAXに異価のためのガイドラインを供給しながら、製作されるかもしれません。
2.4. Announcing an Address
2.4. アドレスを発表します。
Having probed to determine a unique address to use, the host MUST then announce its claimed address by broadcasting ANNOUNCE_NUM ARP announcements, spaced ANNOUNCE_INTERVAL seconds apart. An ARP announcement is identical to the ARP Probe described above, except that now the sender and target IP addresses are both set to the host's newly selected IPv4 address. The purpose of these ARP announcements is to make sure that other hosts on the link do not have stale ARP cache entries left over from some other host that may previously have been using the same address.
使用へのユニークなアドレスを決定するために調べて、そして、ホストは、ANNOUNCE_NUM ARP発表(何秒も離れて区切られたANNOUNCE_INTERVAL)を放送することによって、要求されたアドレスを発表しなければなりません。 ARP発表は上で説明されたARP Probeと同じです、IPが演説する送付者と目標が現在ともにホストの新たに選択されたIPv4アドレスに用意ができているのを除いて。 これらのARP発表の目的はリンクの上の他のホストが以前に同じアドレスを使用したかもしれないある他のホストから聞き古したARPキャッシュエントリーを残させないのを確実にすることです。
2.5. Conflict Detection and Defense
2.5. 闘争検出とディフェンス
Address conflict detection is not limited to the address selection phase, when a host is sending ARP probes. Address conflict detection is an ongoing process that is in effect for as long as a host is using an IPv4 Link-Local address. At any time, if a host receives an ARP packet (request *or* reply) on an interface where the 'sender IP address' is the IP address the host has configured for that interface, but the 'sender hardware address' does not match the hardware address of that interface, then this is a conflicting ARP packet, indicating an address conflict.
ホストが探測装置をARPに送るとき、アドレス闘争検出はアドレス選択段階に制限されません。 アドレス闘争検出はホストがIPv4 Link-ローカルアドレスを使用している限り、有効な進行中の過程です。 いつでも、ホストが'送付者IPアドレス'がホストがそのインタフェースに構成したIPアドレスですが、'送付者ハードウェア・アドレス'がそのインタフェースのハードウェア・アドレスに合っていないインタフェースでARPパケット(**を要求するか、または返答する)を受けるなら、これは闘争しているARPパケットです、アドレス闘争を示して。
A host MUST respond to a conflicting ARP packet as described in either (a) or (b) below:
ホストは以下で(a)か(b)のどちらかで説明されるように闘争しているARPパケットに応じなければなりません:
(a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately configure a new IPv4 Link-Local address as described above, or
または(a) 闘争しているARPパケットを受けるときホストが、すぐに上で説明されるように新しいIPv4 Link-ローカルアドレスを構成するのを選ぶかもしれない。
(b) If a host currently has active TCP connections or other reasons to prefer to keep the same IPv4 address, and it has not seen any other conflicting ARP packets within the last DEFEND_INTERVAL seconds, then it MAY elect to attempt to defend its address by recording the time that the conflicting ARP packet was received, and then broadcasting one single ARP announcement, giving its own IP and hardware addresses as the sender addresses of the ARP. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first
(b) 現在、ホストには活発なTCP接続か同じIPv4がアドレスであることを保つのを好む他の理由があって、最後のDEFEND_INTERVAL秒以内に他の闘争しているARPパケットを見ていないなら、闘争しているARPパケットを受け取った時に記録して、次に、1つのただ一つのARP発表を放送することによってアドレスを防御するのを試みるのを選ぶかもしれません、ARPの送付者アドレスとしてそれ自身のIPとハードウェア・アドレスを与えて。 これをしたので、そして、ホストは、通常、さらなる少しも特別な動きなしでアドレスを使用し続けることができます。 しかしながら、これは1番目ではありません。
Cheshire, et al. Standards Track [Page 13] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[13ページ]RFC3927IPv4
conflicting ARP packet the host has seen, and the time recorded for the previous conflicting ARP packet is recent, within DEFEND_INTERVAL seconds, then the host MUST immediately cease using this address and configure a new IPv4 Link-Local address as described above. This is necessary to ensure that two hosts do not get stuck in an endless loop with both hosts trying to defend the same address.
ホストが見て、時間が前の闘争しているARPパケットのために記録した闘争しているARPパケットがDEFEND_INTERVAL秒以内に最近であり、次に、ホストは、上で説明されるようにすぐに、このアドレスを使用するのをやめて、新しいIPv4 Link-ローカルアドレスを構成しなければなりません。 これが、2人のホストが両方のホストが同じアドレスを防御していようとする永久ループで立ち往生しないのを保証するのに必要です。
A host MUST respond to conflicting ARP packets as described in either (a) or (b) above. A host MUST NOT ignore conflicting ARP packets.
ホストは上で(a)か(b)のどちらかで説明されるように闘争しているARPパケットに応じなければなりません。 ホストは闘争しているARPパケットを無視してはいけません。
Forced address reconfiguration may be disruptive, causing TCP connections to be broken. However, it is expected that such disruptions will be rare, and if inadvertent address duplication happens, then disruption of communication is inevitable, no matter how the addresses were assigned. It is not possible for two different hosts using the same IP address on the same network to operate reliably.
TCP接続が失意であることを引き起こして、無理矢理のアドレス再構成は破壊的であるかもしれません。 しかしながら、そのような分裂がまれになると予想されて、不注意なアドレス複製が起こるなら、コミュニケーションの分裂は必然です、アドレスがどのように割り当てられたとしても。 2人の異なったホストには、それは、確かに作動するのに同じネットワークに関する同じIPアドレスを使用することで可能ではありません。
Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address. This mitigates some security threats posed by address reconfiguration, as discussed in Section 5.
闘争、SHOULDが活発に試みるホストのためアドレスをやめる前に、そのアドレスを使用することであらゆる既存の接続をリセットしてください。 これはセクション5で議論するようにアドレス再構成によって引き起こされたいくつかの軍事的脅威を緩和します。
Immediately configuring a new address as soon as the conflict is detected is the best way to restore useful communication as quickly as possible. The mechanism described above of broadcasting a single ARP announcement to defend the address mitigates the problem somewhat, by helping to improve the chance that one of the two conflicting hosts may be able to retain its address.
闘争が検出されるとすぐに、すぐに新しいアドレスを構成するのは、できるだけはやく役に立つコミュニケーションを回復する最も良い方法です。 上でアドレスを防御するためにただ一つのARP発表を放送するのについて説明されたメカニズムは問題をいくらか緩和します、2人の闘争しているホストのひとりがアドレスを保有できるかもしれないという機会を改良するのを助けることによって。
All ARP packets (*replies* as well as requests) that contain a Link- Local 'sender IP address' MUST be sent using link-layer broadcast instead of link-layer unicast. This aids timely detection of duplicate addresses. An example illustrating how this helps is given in Section 4.
Linkの地方の'送付者IPアドレス'を含むすべてのARPパケット(*また、要求としての*回答)にリンクレイヤユニキャストの代わりにリンク層ブロードキャストを使用させなければなりません。 これは写しアドレスのタイムリーな検出を支援します。 これがどう助けるかを例証する例はセクション4で出されます。
2.6. Address Usage and Forwarding Rules
2.6. アドレス用法と推進規則
A host implementing this specification has additional rules to conform to, whether or not it has an interface configured with an IPv4 Link-Local address.
この仕様を履行するホストは従う付則を持っています、IPv4 Link-ローカルアドレスでインタフェースを構成するそれか否かに関係なく。
2.6.1. Source Address Usage
2.6.1. ソースアドレス用法
Since each interface on a host may have an IPv4 Link-Local address in addition to zero or more other addresses configured by other means (e.g., manually or via a DHCP server), a host may have to make a
ホストの上の各インタフェースにはゼロに加えたIPv4 Link-ローカルアドレスがあるかもしれないか、または他の、より多くのアドレスが他の手段(例えば、手動かDHCPサーバを通した)を構成したので、ホストはaを作らなければならないかもしれません。
Cheshire, et al. Standards Track [Page 14] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[14ページ]RFC3927IPv4
choice about what source address to use when it sends a packet or initiates a TCP connection.
それであるときに、どんなソースアドレスを使用したらよいかに関する選択は、パケットを送るか、またはTCP接続を開始します。
Where both an IPv4 Link-Local and a routable address are available on the same interface, the routable address should be preferred as the source address for new communications, but packets sent from or to the IPv4 Link-Local address are still delivered as expected. The IPv4 Link-Local address may continue to be used as a source address in communications where switching to a preferred address would cause communications failure because of the requirements of an upper-layer protocol (e.g., an existing TCP connection). For more details, see Section 1.7.
IPv4 Link-ローカルと発送可能アドレスの両方が同じインタフェースで利用可能であるところでは、発送可能アドレスは新しいコミュニケーションのためのソースアドレスとして好まれるべきですが、ローカルアドレスかIPv4 Link-ローカルアドレスに送られたパケットは予想されるようにまだ提供されています。 IPv4 Link-ローカルアドレスは、コミュニケーションのソースアドレスが上側の層のプロトコル(例えば、既存のTCP接続)の要件のために都合のよいアドレスに切り替わるところでコミュニケーション失敗を引き起こすでしょう、したがって、使用され続けるかもしれません。 その他の詳細に関しては、セクション1.7を見てください。
A multi-homed host needs to select an outgoing interface whether or not the destination is an IPv4 Link-Local address. Details of that process are beyond the scope of this specification. After selecting an interface, the multi-homed host should send packets involving IPv4 Link-Local addresses as specified in this document, as if the selected interface were the host's only interface. See Section 3 for further discussion of multi-homed hosts.
マルチ、家へ帰り、目的地がIPv4 Link-ローカルアドレスであるか否かに関係なく、外向的なインタフェースを選択する必要性を接待してください。 そのプロセスの細部はこの仕様の範囲を超えています。 インタフェースを選択した後にマルチ、家へ帰り、ホストはパケットを指定されるとしてIPv4 Linkローカルのアドレスに本書ではかかわらせるべきです、まるで選択されたインタフェースがホストの唯一のインタフェースであるかのように。 さらなる議論のためのセクション3を見る、マルチ、家へ帰り、ホスト。
2.6.2. Forwarding Rules
2.6.2. 推進規則
Whichever interface is used, if the destination address is in the 169.254/16 prefix (excluding the address 169.254.255.255, which is the broadcast address for the Link-Local prefix), then the sender MUST ARP for the destination address and then send its packet directly to the destination on the same physical link. This MUST be done whether the interface is configured with a Link-Local or a routable IPv4 address.
169.254/16接頭語に送付先アドレスがあるならどのインタフェースが使用されているか、(アドレスを除く、169.254、.255、.255、Linkローカルの接頭語のための放送のアドレスであるもの)、次に、目的地への送付者MUST ARPは直接同じ物理的なリンクの上の目的地にパケットを扱って、次に、送ります。 インタフェースがLink-ローカルかroutable IPv4アドレスによって構成されるか否かに関係なく、これをしなければなりません。
In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. This approach will not work for routers or multi-homed hosts. Refer to section 3 for more discussion of multi-homed hosts.
多くのネットワークスタックでは、この機能性を達成するのは、169.254/16が地方のリンクで直接届いているのを示す加えるのと同じくらい簡単な経路指定テーブルエントリーであるかもしれません。 または、このアプローチはルータに効き目がない、マルチ、家へ帰り、ホスト。 セクション3が、より多くの議論について参照される、マルチ、家へ帰り、ホスト。
The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding.
ホストは推進のためにIPv4 Linkローカルの送付先アドレスがあるパケットをどんなルータにも送ってはいけません。
If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable IPv4 source address, if it can. If for any reason the host chooses to send the packet with an IPv4 Link-Local source address (e.g., no routable address is available on the selected interface), then it MUST ARP for the destination address and then send its packet, with
送付先アドレスが169.254/16接頭語の外でユニキャストアドレスであるなら、ホストSHOULDは適切なroutable IPv4ソースアドレスを使用します、そうすることができるなら。 どんな理由でもホストは、IPv4 Link-地元筋アドレスがあるパケットを送るのを選んで(例えば、どんな発送可能アドレスも選択されたインタフェースで利用可能ではありません)、次に、それはアドレスとその時がパケットを送る目的地へのMUST ARPです。
Cheshire, et al. Standards Track [Page 15] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[15ページ]RFC3927IPv4
an IPv4 Link-Local source address and a routable destination IPv4 address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding.
IPv4 Link-地元筋アドレスと直接同じ物理的なリンクの上の目的地への発送可能送付先IPv4アドレス。 ホストは推進のためにどんなルータにもパケットを送ってはいけません。
In the case of a device with a single interface and only an Link- Local IPv4 address, this requirement can be paraphrased as "ARP for everything".
単一のインタフェースがあるデバイスに関するケースとLinkのローカルのIPv4アドレスだけでは、「すべてのためのARP」としてこの要件について言い換えることができます。
In many network stacks, achieving this "ARP for everything" behavior may be as simple as having no primary IP router configured, having the primary IP router address configured to 0.0.0.0, or having the primary IP router address set to be the same as the host's own Link- Local IPv4 address. For suggested behavior in multi-homed hosts, see Section 3.
多くのネットワークスタックでは、この「すべてのためのARP」の振舞いを達成するのがどんなプライマリIPルータも構成させないのと同じくらい簡単であるかもしれない、プライマリIPルータアドレスを持っているのはホストのものがLinkのローカルのIPv4アドレスを所有しているのでルータアドレスが同じになるようにセットしたのを0.0の.0の.0、または有のプライマリIPに構成しました。 中の提案された振舞い、マルチ、家へ帰り、ホストはセクション3を見てください。
2.7. Link-Local Packets Are Not Forwarded
2.7. リンク地方のパケットは進められません。
A sensible default for applications which are sending from an IPv4 Link-Local address is to explicitly set the IPv4 TTL to 1. This is not appropriate in all cases as some applications may require that the IPv4 TTL be set to other values.
IPv4 Link-ローカルアドレスから発信するアプリケーションのための実際的なデフォルト値は明らかに1にIPv4 TTLを設定することです。 いくつかのアプリケーションが、IPv4 TTLが他の値に用意ができているのを必要とするかもしれないので、これはすべての場合で適切ではありません。
An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IPv4 header. Similarly, a router or other host MUST NOT indiscriminately answer all ARP Requests for addresses in the 169.254/16 prefix. A router may of course answer ARP Requests for one or more IPv4 Link-Local address(es) that it has legitimately claimed for its own use according to the claim-and- defend protocol described in this document.
推進のために、169.254/16接頭語にはソース、そして/または、送付先アドレスがあるIPv4パケットをどんなルータにも送ってはいけません、そして、そのようなパケットを受けるどんなネットワークデバイスもそれを送ってはいけません、IPv4ヘッダーのTTLにかかわらず。 同様に、ルータか他のホストが無差別に169.254/16接頭語のアドレスにすべてのARP Requestsに答えなければならないというわけではありません。 そして、ルータがもちろん1つにARP Requestsに答えるかもしれないか、またはクレームに従ってそれが持っているより多くのIPv4 Link-ローカルアドレス(es)が合法的にそれ自身の使用の代金を請求した、-、-本書では説明されたプロトコルを防御してください。
This restriction also applies to multicast packets. IPv4 packets with a Link-Local source address MUST NOT be forwarded outside the local link even if they have a multicast destination address.
また、この制限はマルチキャストパケットに適用されます。 それらにマルチキャスト送付先アドレスがあっても、地方のリンクの外でLink-地元筋アドレスがあるIPv4パケットを進めてはいけません。
2.8. Link-Local Packets are Local
2.8. リンク地方のPacketsはLocalです。
The non-forwarding rule means that hosts may assume that all 169.254/16 destination addresses are "on-link" and directly reachable. The 169.254/16 address prefix MUST NOT be subnetted. This specification utilizes ARP-based address conflict detection, which functions by broadcasting on the local subnet. Since such broadcasts are not forwarded, were subnetting to be allowed then address conflicts could remain undetected.
非推進規則は、ホストが、すべての169.254/16の送付先アドレスに「リンク」に直接届いていると仮定するかもしれないことを意味します。 169.254/16アドレス接頭語を「副-網で覆」ってはいけません。 この仕様はARPベースのアドレス闘争検出を利用します。(それは、地方のサブネットで放送することによって、機能します)。 そのような放送が進められないので、サブネッティングがその時許容されることになっているなら、アドレス闘争は非検出されたままで残ることができるでしょうに。
Cheshire, et al. Standards Track [Page 16] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[16ページ]RFC3927IPv4
This does not mean that Link-Local devices are forbidden from any communication outside the local link. IP hosts that implement both Link-Local and conventional routable IPv4 addresses may still use their routable addresses without restriction as they do today.
これは、Link-ローカル装置が地方のリンクの外のどんなコミュニケーションからも禁じられることを意味しません。 両方がLink地方の、そして、従来のroutable IPv4アドレスであると実装するIPホストは今日するように制限なしでそれらの発送可能アドレスをまだ使用しているかもしれません。
2.9. Higher-Layer Protocol Considerations
2.9. 上位層プロトコル問題
Similar considerations apply at layers above IP.
同様の問題はIPの上の層で適用されます。
For example, designers of Web pages (including automatically generated web pages) SHOULD NOT contain links with embedded IPv4 Link-Local addresses if those pages are viewable from hosts outside the local link where the addresses are valid.
例えば、それらのページがアドレスが有効である地方のリンクの外のホストから見えているなら、ウェブページ(自動的に生成しているウェブページを含んでいる)SHOULD NOTのデザイナーは埋め込まれたIPv4 Linkローカルのアドレスとのリンクを含みます。
As IPv4 Link-Local addresses may change at any time and have limited scope, IPv4 Link-Local addresses MUST NOT be stored in the DNS.
IPv4 Linkローカルのアドレスがいつでも、変化するかもしれなくて、範囲を制限したとき、DNSにIPv4 Linkローカルのアドレスを保存してはいけません。
2.10. Privacy Concerns
2.10. プライバシーの問題
Another reason to restrict leakage of IPv4 Link-Local addresses outside the local link is privacy concerns. If IPv4 Link-Local addresses are derived from a hash of the MAC address, some argue that they could be indirectly associated with an individual, and thereby used to track that individual's activities. Within the local link the hardware addresses in the packets are all directly observable, so as long as IPv4 Link-Local addresses don't leave the local link they provide no more information to an intruder than could be gained by direct observation of hardware addresses.
地方のリンクの外でIPv4 Linkローカルのアドレスの漏出を制限する別の理由はプライバシーの問題です。 MACアドレスのハッシュからIPv4 Linkローカルのアドレスを得るなら、或るものはそれらを間接的に個人に関連づけて、その結果、その個人の活動を追跡するのに使用できたと主張します。 地方のリンクの中では、パケットのハードウェア・アドレスがすべて直接観察可能であるので、IPv4 Linkローカルのアドレスが地方のリンクを残さない限り、それらはハードウェア・アドレスの直接観察で獲得できるだろうというほど詳しい情報を全く侵入者に提供しません。
2.11. Interaction between DHCPv4 client and IPv4 Link-Local State
Machines
2.11. DHCPv4クライアントとIPv4 Link地方の州Machinesとの相互作用
As documented in Appendix A, early implementations of IPv4 Link-Local have modified the DHCP state machine. Field experience shows that these modifications reduce the reliability of the DHCP service.
Appendix Aに記録されるように、IPv4 Link地方の早めの実装はDHCP州のマシンを変更しました。 実地経験は、これらの変更がDHCPサービスの信頼性を減少させるのを示します。
A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way.
IPv4 Link地方で両方を実装するデバイスとDHCPv4クライアントは、IPv4 Link地方の構成を収容するためにDHCPv4クライアントの振舞いを変更するべきではありません。 IPv4 Link-ローカルアドレスの特定の構成では、DHCPサーバが現在反応しているか否かに関係なく、unconfigureへの十分な理由は、DHCPクライアントが、新しいIPアドレスを習得するか、DHCPタイムアウトを変えるか、または道における、いかなる他のもDHCP州のマシンの働きを変えるのを試みるのを止めるためには有効なDHCPリースではありませんか?
Further discussion of this issue is provided in "Detection of Network Attachment (DNA) in IPv4" [DNAv4].
「IPv4"[DNAv4]でのネットワーク付属(DNA)の検出」にこの問題のさらなる議論を提供します。
Cheshire, et al. Standards Track [Page 17] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[17ページ]RFC3927IPv4
3. Considerations for Multiple Interfaces
3. 複数のインタフェースへの問題
The considerations outlined here also apply whenever a host has multiple IP addresses, whether or not it has multiple physical interfaces. Other examples of multiple interfaces include different logical endpoints (tunnels, virtual private networks etc.) and multiple logical networks on the same physical medium. This is often referred to as "multi-homing".
また、ホストに複数のIPアドレスがあるときはいつも、ここに概説された問題は適用されます、それに複数の物理インターフェースがあるか否かに関係なく。 複数のインタフェースに関する他の例は同じ物理的な媒体の上の異なった論理的な終点(仮想私設網トンネルなど)と複数の論理的なネットワークを含んでいます。 これはしばしば「マルチホーミング」と呼ばれます。
Hosts which have more than one active interface and elect to implement dynamic configuration of IPv4 Link-Local addresses on one or more of those interfaces will face various problems. This section lists these problems but does no more than indicate how one might solve them. At the time of this writing, there is no silver bullet which solves these problems in all cases, in a general way. Implementors must think through these issues before implementing the protocol specified in this document on a system which may have more than one active interface as part of a TCP/IP stack capable of multi-homing.
1つ以上のアクティブなインタフェースを持って、それらのインタフェースの1つ以上に関するIPv4 Linkローカルのアドレスの動的設定を実装するのを選ぶホストが様々な問題に直面するでしょう。このセクションは、これらの問題を記載しますが、1つがどうそれらを解決するかもしれないかを示すだけです。 この書くこと時点で、すべての場合にはこれらの問題を解決する特効薬が全くありません、ザッと。 作成者は、本書ではシステムの上で指定されたプロトコルを実装する前のこれらの問題を通してどれにマルチホーミングができるTCP/IPスタックの一部として1つ以上のアクティブなインタフェースがあるかもしれないかを考えなければなりません。
3.1. Scoped Addresses
3.1. 見られたアドレス
A host may be attached to more than one network at the same time. It would be nice if there was a single address space used in every network, but this is not the case. Addresses used in one network, be it a network behind a NAT or a link on which IPv4 Link-Local addresses are used, cannot be used in another network and have the same effect.
ホストは同時に、1つ以上のネットワークに配属されるかもしれません。 あらゆるネットワークに使用されるただ一つのアドレス空間があれば、良いでしょうにが、これはそうではありません。 NATの後ろのネットワークかIPv4 Linkローカルのアドレスが使用されているリンクであることにかかわらず1つのネットワークに使用されるアドレスは、別のネットワークに使用されて、同じ効果を持つことができません。
It would also be nice if addresses were not exposed to applications, but they are. Most software using TCP/IP which await messages receives from any interface at a particular port number, for a particular transport protocol. Applications are generally only aware (and care) that they have received a message. The application knows the address of the sender to which the application will reply.
また、アドレスがアプリケーションに暴露されないなら、良いでしょうにが、それらは良いです。 メッセージを待つTCP/IPを使用するほとんどのソフトウェアが指定港番号でどんなインタフェースからも受信されます、特定のトランスポート・プロトコルのために。 一般に、アプリケーションは彼らがメッセージを受け取ったのを意識しているだけです(そして、注意)。 アプリケーションはアプリケーションが返答する送信者のアドレスを知っています。
The first scoped address problem is source address selection. A multi-homed host has more than one address. Which address should be used as the source address when sending to a particular destination? This question is usually answered by referring to a routing table, which expresses on which interface (with which address) to send, and how to send (should one forward to a router, or send directly). The choice is made complicated by scoped addresses because the address range in which the destination lies may be ambiguous. The table may not be able to yield a good answer. This problem is bound up with next-hop selection, which is discussed in Section 3.2.
最初の見られたアドレス問題はソースアドレス選択です。 マルチ、家へ帰り、ホストには、1つ以上のアドレスがあります。 特定の目的地に発信するとき、どのアドレスがソースアドレスとして使用されるべきですか? 経路指定テーブルと、どのインタフェース(どのアドレスがある)を送ったらよいかのどの急行と、どう発信するかに言及することによって、通常、この質問は答えられます(ルータをaに送るか、または直送するなら)。 目的地が位置するアドレスの範囲があいまいであるかもしれないので、選択を見られたアドレスで複雑にします。 テーブルは適切な答をもたらすことができないかもしれません。 この問題は次のホップ選択で縛られます。(セクション3.2でそれについて、議論します)。
Cheshire, et al. Standards Track [Page 18] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[18ページ]RFC3927IPv4
The second scoped address problem arises from scoped parameters leaking outside their scope. This is discussed in Section 7.
2番目の見られたアドレス問題はそれらの範囲の外で漏れる見られたパラメタから起こります。 セクション7でこれについて議論します。
It is possible to overcome these problems. One way is to expose scope information to applications such that they are always aware of what scope a peer is in. This way, the correct interface could be selected, and a safe procedure could be followed with respect to forwarding addresses and other scoped parameters. There are other possible approaches. None of these methods have been standardized for IPv4 nor are they specified in this document. A good API design could mitigate the problems, either by exposing address scopes to 'scoped-address aware' applications or by cleverly encapsulating the scoping information and logic so that applications do the right thing without being aware of address scoping.
これらの問題を克服するのは可能です。One道が範囲情報をアプリケーションに暴露することであるので、同輩がどんな範囲でいるかでそれらはいつも意識しています。 この道、正しいインタフェースを選択できました、そして、フォーワーディング・アドレスと他の見られたパラメタに関して安全な方法に従うことができました。 他の可能なアプローチがあります。 これらのメソッドのいずれもIPv4のために標準化されていません、そして、それらは本書では指定されません。 良いAPIデザインがアドレスが範囲であると'見られたアドレスの意識している'アプリケーションに暴露するか、または賢く情報と論理を見るのにカプセル化することによって問題を緩和するかもしれないので、アドレスの見ることを意識していなくて、アプリケーションは正しいことをします。
An implementer could undertake to solve these problems, but cannot simply ignore them. With sufficient experience, it is hoped that specifications will emerge explaining how to overcome scoped address multi-homing problems.
implementerはこれらの問題を解決するのを引き受けることができましたが、それらを絶対に無視できません。 十分な経験で、打ち勝つのがどのようにアドレスマルチホーミング問題を見たかを説明しながら仕様が現れることが望まれています。
3.2. Address Ambiguity
3.2. アドレスのあいまいさ
This is a core problem with respect to IPv4 Link-Local destination addresses being reachable on more than one interface. What should a host do when it needs to send to Link-Local destination L and L can be resolved using ARP on more than one link?
これは1つ以上のインタフェースで届いているIPv4 Linkローカルの送付先アドレスに関する核心問題です。 Link地方の目的地Lに発信するのが必要であり、1個以上のリンクの上のARPを使用することでLを決議できるとき、ホストは何をするべきですか?
Even if a Link-Local address can be resolved on only one link at a given moment, there is no guarantee that it will remain unambiguous in the future. Additional hosts on other interfaces may claim the address L as well.
与えられた瞬間に1個のリンクだけの上にLink-ローカルアドレスを決議できても、将来明白なままで残るという保証が全くありません。 他のインタフェースの追加ホストは、アドレスがまた、Lであると主張するかもしれません。
One possibility is to support this only in the case where the application specifically expresses which interface to send from.
1つの可能性はアプリケーションがどのインタフェースから発信するかを明確に言い表す場合だけでこれをサポートすることです。
There is no standard or obvious solution to this problem. Existing application software written for the IPv4 protocol suite is largely incapable of dealing with address ambiguity. This does not preclude an implementer from finding a solution, writing applications which are able to use it, and providing a host which can support dynamic configuration of IPv4 Link-Local addresses on more than one interface. This solution will almost surely not be generally applicable to existing software and transparent to higher layers, however.
この問題へのどんな標準の、または、明白な解決もありません。 IPv4プロトコル群に書かれた既存のアプリケーション・ソフトはアドレスのあいまいさに主に対処できません。 解答と、それを使用できる書くことのアプリケーションと、そうすることができるホストを提供すると1つ以上のインタフェースに関するIPv4 Linkローカルのアドレスの動的設定がサポートするのがわかるので、これはimplementerを排除しません。 しかしながら、この溶液は、ほぼ確実に一般に、既存のソフトウェアに適切であって、より高い層にわかりやすくならないでしょう。
Given that the IP stack must have the outbound interface associated with a packet that needs to be sent to a Link-Local destination address, interface selection must occur. The outbound interface
IPスタックにLinkローカルの送付先アドレスに送られる必要があるパケットに関連している外国行きのインタフェースがなければならないなら、インタフェース選択は起こらなければなりません。 外国行きのインタフェース
Cheshire, et al. Standards Track [Page 19] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[19ページ]RFC3927IPv4
cannot be derived from the packet's header parameters such as source or destination address (e.g., by using the forwarding table lookup). Therefore, outbound interface association must be done explicitly through other means. The specification does not stipulate those means.
ソースか送付先アドレス(例えば、推進テーブルルックアップを使用するのによる)などのパケットのヘッダーパラメタから派生できません。 したがって、他の手段で明らかに外国行きのインタフェース協会をしなければなりません。 仕様はそれらの手段を規定しません。
3.3. Interaction with Hosts with Routable Addresses
3.3. Routableアドレスをもっているホストとの相互作用
Attention is paid in this specification to transition from the use of IPv4 Link-Local addresses to routable addresses (see Section 1.5). The intention is to allow a host with a single interface to first support Link-Local configuration then gracefully transition to the use of a routable address. Since the host transitioning to the use of a routable address may temporarily have more than one address active, the scoped address issues described in Section 3.1 will apply. When a host acquires a routable address, it does not need to retain its Link-Local address for the purpose of communicating with other devices on the link that are themselves using only Link-Local addresses: any host conforming to this specification knows that regardless of source address an IPv4 Link-Local destination must be reached by forwarding directly to the destination, not via a router; it is not necessary for that host to have a Link-Local source address in order to send to a Link-Local destination address.
この仕様で注意をIPv4 Linkローカルのアドレスの使用から変遷にアドレスを発送可能するのに向けます(セクション1.5を見てください)。 意志は単一のインタフェースをもっているホストが最初に優雅にそしてLink地方の構成に発送可能アドレスの使用への変遷をサポートするのを許容することです。 発送可能アドレスの使用に移行するホストが一時1つ以上のアドレスをアクティブにするかもしれないので、セクション3.1で説明された見られたアドレス問題は適用されるでしょう。 ホストが発送可能アドレスを習得するとき、リンクの上のLinkローカルのアドレスだけを使用している対向機器とコミュニケートする目的のためのLink-ローカルアドレスを保有する必要はありません: この仕様に従うどんなホストも、ソースアドレスにかかわらずルータでないことで直接目的地に転送することによってIPv4 Link地方の目的地に達しなければならないのを知っています。 そのホストにはLink-地元筋アドレスがあるのは、Linkローカルの送付先アドレスに発信するのに必要ではありません。
A host with an IPv4 Link-Local address may send to a destination which does not have an IPv4 Link-Local address. If the host is not multi-homed, the procedure is simple and unambiguous: Using ARP and forwarding directly to on-link destinations is the default route. If the host is multi-homed, however, the routing policy is more complex, especially if one of the interfaces is configured with a routable address and the default route is (sensibly) directed at a router accessible through that interface. The following example illustrates this problem and provides a common solution to it.
IPv4 Link-ローカルアドレスをもっているホストはIPv4 Link-ローカルアドレスを持っていない目的地に発信するかもしれません。 ホストがそうでない、マルチ、家へ帰り、手順は、簡単であって、明白です: ARPを使用して、直接リンクの上の目的地に転送するのは、デフォルトルートです。 ホストがそうである、マルチ、家へ帰り、しかしながら、ルーティング方針は、より複雑です、特に、インタフェースの1つが発送可能アドレスによって構成されて、そのインタフェースを通してアクセスしやすいルータが(分別よく)デフォルトルートに向けられるなら。 以下の例は、この問題を例証して、一般的な解決法をそれに提供します。
i1 +---------+ i2 i3 +-------+
ROUTER-------= HOST1 =---------= HOST2 |
link1 +---------+ link2 +-------+
i1+---------+ i2 i3+-------+ ルータ-------= HOST1=---------= HOST2| link1+---------+ link2+-------+
In the figure above, HOST1 is connected to link1 and link2. Interface i1 is configured with a routable address, while i2 is an IPv4 Link-Local address. HOST1 has its default route set to ROUTER's address, through i1. HOST1 will route to destinations in 169.254/16 to i2, sending directly to the destination.
図では、上では、HOST1がlink1とlink2に接続されます。 インタフェースi1は発送可能アドレスによって構成されますが、i2はIPv4 Link-ローカルアドレスです。 HOST1はi1を通してデフォルトルートをROUTERのアドレスに設定させます。 目的地に直送して、HOST1はi2への169.254/16における目的地に発送するでしょう。
HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3.
HOST2は(非リンクのローカル)構成されたIPv4アドレスをi3に割り当てさせます。
Cheshire, et al. Standards Track [Page 20] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[20ページ]RFC3927IPv4
Using a name resolution or service discovery protocol HOST1 can discover HOST2's address. Since HOST2's address is not in 169.254/16, HOST1's routing policy will send datagrams to HOST2 via i1, to the ROUTER. Unless there is a route from ROUTER to HOST2, the datagrams sent from HOST1 to HOST2 will not reach it.
名前解決を使用するか、サービス発見プロトコルHOST1がHOST2のアドレスを発見できます。 169.254/16にはHOST2のアドレスがないので、HOST1のルーティング方針はi1を通したHOST2、ROUTERにデータグラムを送るでしょう。 ROUTERからHOST2までルートがないと、HOST1からHOST2に送られたデータグラムはそれに達しないでしょう。
One solution to this problem is for a host to attempt to reach any host locally (using ARP) for which it receives an unreachable ICMP error message (ICMP message codes 0, 1, 6 or 7 [RFC792]). The host tries all its attached links in a round robin fashion. This has been implemented successfully for some IPv6 hosts, to circumvent exactly this problem. In terms of this example, HOST1 upon failing to reach HOST2 via the ROUTER, will attempt to forward to HOST2 via i2 and succeed.
この問題への1つの解決が局所的(ARPを使用する)にどんなホストにも届くのを試みるそれが手の届かないICMPエラーメッセージ(ICMPメッセージコード0、1、6または7[RFC792])を受け取るホストのためのものです。 ホストは連続ファッションですべての付属リンクを試します。 これ、何人かのIPv6ホストのためにまさにこの問題を回避するために首尾よく実装されました。 この例に関して、ROUTERを通してHOST2に達しないときのHOST1、i2を通したHOST2へのフォワードに試みて、成功してください。
It may also be possible to overcome this problem using techniques described in section 3.2, or other means not discussed here. This specification does not provide a standard solution, nor does it preclude implementers from supporting multi-homed configurations, provided that they address the concerns in this section for the applications which will be supported on the host.
また、セクション3.2で説明されたテクニック、またはここで議論しなかった他の手段を使用することにおけるこの問題を克服するのも可能であるかもしれません。 この仕様が標準液を提供しないで、またサポートするのからimplementersを排除しない、マルチ、家へ帰り、構成ホストの上でサポートされるアプリケーションのためにこのセクションの関心を扱えば。
3.4. Unintentional Autoimmune Response
3.4. 意図的でない自己免疫反応
Care must be taken if a multi-homed host can support more than one interface on the same link, all of which support IPv4 Link-Local autoconfiguration. If these interfaces attempt to allocate the same address, they will defend the host against itself -- causing the claiming algorithm to fail. The simplest solution to this problem is to run the algorithm independently on each interface configured with IPv4 Link-Local addresses.
aであるなら注意しなければならない、マルチ、家へ帰り、ホストは同じリンクの上の1つ以上のインタフェースをサポートすることができます。それのすべてがリンクのためにIPv4 Link地方の自動構成をサポートします。 これらのインタフェースが、同じアドレスを割り当てるのを試みると、要求アルゴリズムが失敗することを引き起こして、それらはそれ自体に対してホストを防御するでしょう。 この問題への最も簡単な解決は独自にIPv4 Linkローカルのアドレスによって構成された各インタフェースにアルゴリズムを実行することです。
In particular, ARP packets which appear to claim an address which is assigned to a specific interface, indicate conflict only if they are received on that interface and their hardware address is of some other interface.
そのインタフェースにそれらを受け取る場合にだけ、特に特定のインタフェースに割り当てられるアドレスを要求するように見えるARPパケットは闘争を示します、そして、それらのハードウェア・アドレスはある他のインタフェースのものです。
If a host has two interfaces on the same link, then claiming and defending on those interfaces must ensure that they end up with different addresses just as if they were on different hosts. Note that some of the ways a host may find itself with two interfaces on the same link may be unexpected and non-obvious, such as when a host has Ethernet and 802.11 wireless, but those two links are (possibly even without the knowledge of the host's user) bridged together.
ホストが同じリンクの上に2つのインタフェースを持っているなら、それらのインタフェースで要求して、防御するのは、まるでまさしく異なったホストの上にあるかのように異なったアドレスで終わるのを確実にしなければなりません。 ホストにはイーサネットと802.11ワイヤレスがありますが、それらの2個のリンクが一緒にブリッジされる(ことによるとホストのユーザに関する知識がなくても)時のように気付くと、同じリンクの上に2つのインタフェースがある状態でホストがいるかもしれない方法のいくつかが予期していなくて、非明白であるかもしれないことに注意してください。
Cheshire, et al. Standards Track [Page 21] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[21ページ]RFC3927IPv4
4. Healing of Network Partitions
4. ネットワークパーティションの回復
Hosts on disjoint network links may configure the same IPv4 Link- Local address. If these separate network links are later joined or bridged together, then there may be two hosts which are now on the same link, trying to use the same address. When either host attempts to communicate with any other host on the network, it will at some point broadcast an ARP packet which will enable the hosts in question to detect that there is an address conflict.
ネットワークリンクはばらばらになります。ホスト、同じIPv4 Linkローカルアドレスを構成するかもしれません。 これらの別々のネットワークリンクが一緒に後で接合されるか、またはブリッジされるなら、現在、そうする2人のホストが同じリンクの上にいるかもしれません、同じアドレスを使用しようとして。 どちらのホストも、ネットワークでいかなる他のホストともコミュニケートするのを試みるとき、それは何らかのポイント放送のいる検出するために問題のホストを可能にするARPパケットにアドレス闘争を望んでいます。
When these address conflicts are detected, the subsequent forced reconfiguration may be disruptive, causing TCP connections to be broken. However, it is expected that such disruptions will be rare. It should be relatively uncommon for networks to be joined while hosts on those networks are active. Also, 65024 addresses are available for IPv4 Link-Local use, so even when two small networks are joined, the chance of conflict for any given host is fairly small.
これらのアドレス闘争が検出されるとき、TCP接続が失意であることを引き起こして、その後の無理矢理の再構成は破壊的であるかもしれません。 しかしながら、そのような分裂がまれになると予想されます。 それらのネットワークのホストが活発である間、ネットワークが加わられるのは、比較的珍しいはずです。 また、65024のアドレスもIPv4 Link地方の使用に利用可能であるので、2つの小さいネットワークが加わられるときさえ、どんな与えられたホストのための闘争の機会もかなり小さいです。
When joining two large networks (defined as networks with a substantial number of hosts per segment) there is a greater chance of conflict. In such networks, it is likely that the joining of previously separated segments will result in one or more hosts needing to change their IPv4 Link-Local address, with subsequent loss of TCP connections. In cases where separation and re-joining is frequent, as in remotely bridged networks, this could prove disruptive. However, unless the number of hosts on the joined segments is very large, the traffic resulting from the join and subsequent address conflict resolution will be small.
2つの大きいネットワーク(かなりの数の1セグメントあたりのホストと共にネットワークと定義される)に加わるとき、闘争のより大きなチャンスがあります。 そのようなネットワークでは、以前に切り離されたセグメントの接合は彼らのIPv4 Link-ローカルアドレスを変える必要がある1人以上のホストをもたらしそうでしょう、TCP接続のその後の損失で。 分離と再接合が離れてブリッジしているネットワークのように頻繁である場合では、これは破壊的であると判明できました。 しかしながら、トラフィックの結果にならない、接合セグメントのホストの数がそれほど大きくない場合接合してください。そうすれば、その後のアドレス紛争解決は小さくなるでしょう。
Sending ARP replies that have IPv4 Link-Local sender addresses via broadcast instead of unicast ensures that these conflicts can be detected as soon as they become potential problems, but no sooner. For example, if two disjoint network links are joined, where hosts A and B have both configured the same Link-Local address, X, they can remain in this state until A, B or some other host attempts to initiate communication. If some other host C now sends an ARP request for address X, and hosts A and B were to both reply with conventional unicast ARP replies, then host C might be confused, but A and B still wouldn't know there is a problem because neither would have seen the other's packet. Sending these replies via broadcast allows A and B to see each other's conflicting ARP packets and respond accordingly.
ユニキャストの代わりに放送を通したIPv4 Linkローカルの送付者アドレスを持っている回答をARPに送るのは、より早くいいえにしかし、潜在的な問題、なるとすぐに、これらの闘争を検出できるのを確実にします。 例えば、2がばらばらになるなら、ネットワークリンクは接合されて、X、ホストAとBがどこに両方を持っているかが同じLink-ローカルアドレスを構成して、A、Bまたはある他のホストが、コミュニケーションを開始するのを試みるまで、彼らはこの州に残ることができます。 ある他のホストCが現在、アドレスXを求めるARP要求を送って、ホストAとBが従来のユニキャストARP回答でともに返答するなら、ホストCは混乱するでしょうにが、AとBは、どちらももう片方のパケットを見ていないでしょう、したがって、問題があるのをまだ知っていないでしょう。 放送でこれらの回答を送るのに、AとBは、互いの闘争しているARPパケットを見て、それに従って、応じます。
Note that sending periodic gratuitous ARPs in an attempt to detect these conflicts sooner is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if the network links were joined only briefly, and were separated again before any new
これらの闘争で、より早く検出する試みで周期的な無料のARPsを送るのは必要でないというメモ、廃棄物が、帯域幅をネットワークでつないで、実際に有害であるかもしれません。 例えば、ネットワークであるなら、リンクは、簡潔にだけ接合されて、どんな前にも再び新しい状態で切り離されました。
Cheshire, et al. Standards Track [Page 22] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[22ページ]RFC3927IPv4
communication involving A or B were initiated, then the temporary conflict would have been benign and no forced reconfiguration would have been required. Triggering an unnecessary forced reconfiguration in this case would not serve any useful purpose. Hosts SHOULD NOT send periodic gratuitous ARPs.
AかBにかかわるコミュニケーションが開始されました、そして、次に、一時的な闘争は優しかったでしょう、そして、どんな無理矢理の再構成も必要でなかったでしょう。 この場合不要な無理矢理の再構成の引き金となる場合、少しの役に立つ目的も役立たないでしょう。 SHOULD NOTが周期的な無料のARPsを送るホスト。
5. Security Considerations
5. セキュリティ問題
The use of IPv4 Link-Local Addresses may open a network host to new attacks. In particular, a host that previously did not have an IP address, and no IP stack running, was not susceptible to IP-based attacks. By configuring a working address, the host may now be vulnerable to IP-based attacks.
IPv4 Link地方のAddressesの使用は新しい攻撃にネットワークホストを開くかもしれません。 以前にIPアドレスを持っていなかったホスト、およびIPスタック稼働はIPベースの攻撃に特に、影響されやすくはありませんでした。 働くアドレスを構成することによって、ホストは現在、IPベースの攻撃に被害を受け易いかもしれません。
The ARP protocol [RFC826] is insecure. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP requests with replies giving its own hardware address, thereby claiming ownership of every address on the network.
ARPプロトコル[RFC826]は不安定です。 他のホストの正しい操作を妨げて、悪意があるホストは詐欺的なARPパケットをネットワークに送るかもしれません。 例えば、ホストが回答がそれ自身のハードウェア・アドレスを与えているすべてのARP要求に答えるのは、簡単です、その結果、ネットワークに関するあらゆるアドレスの所有権を要求します。
NOTE: There are certain kinds of local links, such as wireless LANs, that provide no physical security. Because of the existence of these links it would be very unwise for an implementer to assume that when a device is communicating only on the local link it can dispense with normal security precautions. Failure to implement appropriate security measures could expose users to considerable risks.
以下に注意してください。 どんな物理的なセキュリティも提供しないある種類の無線LANなどの地方のリンクがあります。 これらのリンクの存在のために、デバイスがそれが通常の安全対策で分配できる地方のリンクだけについて話し合っているとき、implementerがそれを仮定するのは、非常に賢明でないでしょう。 適切なセキュリティが測定であると実装しない場合、かなりのリスクにユーザをさらすかもしれません。
A host implementing IPv4 Link-Local configuration has an additional vulnerability to selective reconfiguration and disruption. It is possible for an on-link attacker to issue ARP packets which would cause a host to break all its connections by switching to a new address. The attacker could force the host implementing IPv4 Link- Local configuration to select certain addresses, or prevent it from ever completing address selection. This is a distinct threat from that posed by spoofed ARPs, described in the preceding paragraph.
IPv4 Link地方の構成を実装するホストは選択している再構成と分裂に追加脆弱性を持っています。 リンクの上の攻撃者が新しい住所に切り替わることによってホストが中断しているARPパケットにすべての接続を発行するのは、可能です。 攻撃者は、IPv4 Linkが地方の構成であると実装するホストに、あるアドレスを選択させるか、またはそれがアドレス選択を終了するのを防ぐことができました。 これは先行のパラグラフで説明された偽造しているARPsによってポーズをとられたそれからの異なった脅威です。
Implementations and users should also note that a node that gives up an address and reconfigures, as required by section 2.5, allows the possibility that another node can easily and successfully hijack existing TCP connections.
実装とユーザは、また、セクション2.5のそばでそれがアドレスに与えて、必要に応じて再構成するそのaノードに注意して、別のノードが容易にそうすることができる可能性を許容して、首尾よく既存のTCP接続をハイジャックするべきです。
Implementers are advised that the Internet Protocol architecture expects every networked device or host must implement security which is adequate to protect the resources to which the device or host has access, including the network itself, against known or credible threats. Even though use of IPv4 Link-Local addresses may reduce the
Implementersはインターネットプロトコルアーキテクチャが、すべてのネットワークでつながれたデバイスかホストがデバイスかホストがアクセスを持っているリソースを保護するために適切なセキュリティを実装しなければならないと予想すると忠告されます、ネットワーク自体を含んでいて、知られているか確かな脅威に対して。 IPv4 Linkローカルのアドレスの使用は減少するかもしれません。
Cheshire, et al. Standards Track [Page 23] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[23ページ]RFC3927IPv4
number of threats to which a device is exposed, implementers of devices supporting the Internet Protocol must not assume that a customer's local network is free from security risks.
デバイスが暴露される脅威の数、インターネットがプロトコルであるとサポートするデバイスのimplementersは顧客の企業内情報通信網にはセキュリティリスクがないと仮定してはいけません。
While there may be particular kinds of devices, or particular environments, for which the security provided by the network is adequate to protect the resources that are accessible by the device, it would be misleading to make a general statement to the effect that the requirement to provide security is reduced for devices using IPv4 Link-Local addresses as a sole means of access.
特定の種類のデバイス、または特定の環境(ネットワークによって提供されたセキュリティはデバイスによってアクセス可能なリソースを保護するために適切である)があるかもしれない間、セキュリティを提供するという要件がデバイスのためにアクセサリーの唯一の手段としてIPv4 Linkローカルのアドレスを使用することで減らされるという効果への総論を作るのは紛らわしいでしょう。
In all cases, whether or not IPv4 Link-Local addresses are used, it is necessary for implementers of devices supporting the Internet Protocol to analyze the known and credible threats to which a specific host or device might be subjected, and to the extent that it is feasible, to provide security mechanisms which ameliorate or reduce the risks associated with such threats.
すべての場合では、IPv4 Linkローカルのアドレスが使用されているか否かに関係なく、それがそのような脅威に関連している危険を改善するか、または減少させるセキュリティー対策を提供するために可能であることが特定のホストかデバイスがかけられるかもしれない知られていて確かな脅威を分析するためにインターネットプロトコルをサポートするデバイスのimplementersと、範囲に必要です。
6. Application Programming Considerations
6. アプリケーションプログラミング問題
Use of IPv4 Link-Local autoconfigured addresses presents additional challenges to writers of applications and may result in existing application software failing.
IPv4 Linkローカルの自動構成されたアドレスの使用は、アプリケーションの作家への追加挑戦を提示して、既存のアプリケーション・ソフト失敗をもたらすかもしれません。
6.1. Address Changes, Failure and Recovery
6.1. アドレス変化、失敗、および回復
IPv4 Link-Local addresses used by an application may change over time. Some application software encountering an address change will fail. For example, existing client TCP connections will be aborted, servers whose addresses change will have to be rediscovered, blocked reads and writes will exit with an error condition, and so on.
アプリケーションで使用されるIPv4 Linkローカルのアドレスは時間がたつにつれて、変化するかもしれません。 アドレス変化に遭遇する何らかのアプリケーション・ソフトが失敗するでしょう。 例えば、既存のクライアントTCP接続は中止されて、アドレス変更が再発見されなければならなくて、読書を妨げて、書くサーバはエラー条件などと共に出るでしょう。
Vendors producing application software which will be used on IP implementations supporting IPv4 Link-Local address configuration SHOULD detect and cope with address change events. Vendors producing IPv4 implementations supporting IPv4 Link-Local address configuration SHOULD expose address change events to applications.
IPv4 Link-ローカルアドレス構成がSHOULDであるとサポートしながらIP実装で使用されるアプリケーション・ソフトを作り出すベンダーが、アドレス変化イベントを検出して、切り抜けます。 IPv4 Link-ローカルアドレスが構成SHOULD露出アドレスであるとサポートするIPv4実装を生産するベンダーがイベントをアプリケーションに変えます。
6.2. Limited Forwarding of Locators
6.2. ロケータの株式会社推進
IPv4 Link-Local addresses MUST NOT be forwarded via an application protocol (for example in a URL), to a destination that is not on the same link. This is discussed further in Sections 2.9 and 3.
アプリケーション・プロトコル(例えば、URLの)でIPv4 Linkローカルのアドレスを転送してはいけません、同じリンクの上にない目的地に。 セクション2.9と3で、より詳しくこれについて議論します。
Existing distributed application software that forwards address information may fail. For example, FTP [RFC959] (when not using passive mode) transmits the IP address of the client. Suppose a client starts up and obtains its IPv4 configuration at a time when it
アドレス情報を転送する既存の分配されたアプリケーション・ソフトは失敗するかもしれません。 例えば、FTP[RFC959](受け身の形態を使用しないとき)はクライアントのIPアドレスを伝えます。 一度にそれであるときに、クライアントがIPv4構成を立ち上げて、得ると仮定してください。
Cheshire, et al. Standards Track [Page 24] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[24ページ]RFC3927IPv4
has only a Link-Local address. Later, the host gets a global IP address, and the client contacts an FTP server outside the local link. If the FTP client transmits its old Link-Local address instead of its new global IP address in the FTP "port" command, then the FTP server will be unable to open a data connection back to the client, and the FTP operation will fail.
Link-ローカルアドレスしか持っていません。 その後、ホストはグローバルIPアドレスを得ます、そして、クライアントは地方のリンクの外でFTPサーバに連絡します。 FTPクライアントがFTP「移植」コマンドにおける新しいグローバルIPアドレスの代わりに古いLink-ローカルアドレスを伝えると、FTPサーバはデータ接続をクライアントに公開であって戻しできないでしょう、そして、FTP操作は失敗するでしょう。
6.3. Address Ambiguity
6.3. アドレスのあいまいさ
Application software run on a multi-homed host that supports IPv4 Link-Local address configuration on more than one interface may fail.
aにおけるアプリケーション・ソフト走行、マルチ、家へ帰り、1つ以上のインタフェースでIPv4 Link-ローカルアドレスが構成であるとサポートするホストは失敗するかもしれません。
This is because application software assumes that an IPv4 address is unambiguous, that it can refer to only one host. IPv4 Link-Local addresses are unique only on a single link. A host attached to multiple links can easily encounter a situation where the same address is present on more than one interface, or first on one interface, later on another; in any case associated with more than one host. Most existing software is not prepared for this ambiguity. In the future, application programming interfaces could be developed to prevent this problem. This issue is discussed in Section 3.
これはアプリケーション・ソフトがIPv4アドレスが明白であり、1人のホストだけについて言及できると仮定するからです。 IPv4 Linkローカルのアドレスは単一のリンクだけでユニークです。 複数のリンクに付けられたホストは容易に、同じアドレスが1つ以上のインタフェースに存在している状況に遭遇できますか、または最初に、1では、別のものは後で連結します。 どのような場合でも、1人以上のホストに関連しています。 ほとんどの既存のソフトウェアはこのあいまいさのために準備されません。 将来、この問題を防ぐためにアプリケーションプログラミングインターフェースを開発できました。 セクション3でこの問題について議論します。
7. Router Considerations
7. ルータ問題
A router MUST NOT forward a packet with an IPv4 Link-Local source or destination address, irrespective of the router's default route configuration or routes obtained from dynamic routing protocols.
ルータはIPv4 Link-地元筋か送付先アドレスがあるパケットを進めてはいけません、ダイナミックルーティングプロトコルから入手されたルータのデフォルトルート構成かルートの如何にかかわらず。
A router which receives a packet with an IPv4 Link-Local source or destination address MUST NOT forward the packet. This prevents forwarding of packets back onto the network segment from which they originated, or to any other segment.
IPv4 Link-地元筋か送付先アドレスでパケットを受けるルータはパケットを進めてはいけません。 これはそれらが起因したネットワークセグメントか、いかなる他のセグメントにもパケットの推進を防いで戻します。
8. IANA Considerations
8. IANA問題
The IANA has allocated the prefix 169.254/16 for the use described in this document. The first and last 256 addresses in this range (169.254.0.x and 169.254.255.x) are allocated by Standards Action, as defined in "Guidelines for Writing an IANA" (BCP 26) [RFC2434]. No other IANA services are required by this document.
IANAは本書では説明された使用のために接頭語169.254/16を割り当てました。 この範囲(169.254.0.xと169.254.255.x)の1番目と最後の256のアドレスがStandards Actionによって割り当てられます、「IANAに書くためのガイドライン」(BCP26)[RFC2434]で定義されるように。 他のIANAサービスは全くこのドキュメントによって必要とされません。
Cheshire, et al. Standards Track [Page 25] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[25ページ]RFC3927IPv4
9. Constants
9. 定数
The following timing constants are used in this protocol; they are not intended to be user configurable.
以下のタイミング定数はこのプロトコルに使用されます。 それらがユーザ構成可能であることを意図しません。
PROBE_WAIT 1 second (initial random delay)
PROBE_NUM 3 (number of probe packets)
PROBE_MIN 1 second (minimum delay till repeated probe)
PROBE_MAX 2 seconds (maximum delay till repeated probe)
ANNOUNCE_WAIT 2 seconds (delay before announcing)
ANNOUNCE_NUM 2 (number of announcement packets)
ANNOUNCE_INTERVAL 2 seconds (time between announcement packets)
MAX_CONFLICTS 10 (max conflicts before rate limiting)
RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts)
DEFEND_INTERVAL 10 seconds (minimum interval between defensive
ARPs).
PROBE_WAIT1 2番目の(初期の無作為の遅れ)のPROBE_NUM3(徹底的調査パケットの数)PROBE_MIN1第2(最小の繰り返された徹底的調査までの遅れ)PROBE_MAX2秒(最大の繰り返された徹底的調査までの遅れ)ANNOUNCE_WAIT2秒(発表する前の遅れ)ANNOUNCE_NUM2; (発表パケットの数) 60秒(連続した試みの間の遅れ)DEFEND_INTERVAL10秒(防衛的なARPsの最小間隔)のANNOUNCE_INTERVAL2秒(発表パケットの間の時間)マックス_CONFLICTS10(レート制限の前の最大闘争)RATE_LIMIT_INTERVAL。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.
[RFC792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
10.2. Informative References
10.2. 有益な参照
[802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[802] 地方とメトロポリタンエリアネットワークのIEEE規格: 概要とアーキテクチャ、ANSI/IEEE Std802、1990
[802.3] ISO/IEC 8802-3 Information technology - Telecommunications
and information exchange between systems - Local and
metropolitan area networks - Common specifications - Part
3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications,
(also ANSI/IEEE Std 802.3- 1996), 1996.
[802.3] ISO/IEC8802-3情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート3: 衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様、(ANSI/IEEE Std802.3- 1996も)、1996にアクセスします。
Cheshire, et al. Standards Track [Page 26] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[26ページ]RFC3927IPv4
[802.5] ISO/IEC 8802-5 Information technology - Telecommunications
and information exchange between systems - Local and
metropolitan area networks - Common specifications - Part
5: Token ring access method and physical layer
specifications, (also ANSI/IEEE Std 802.5-1998), 1998.
[802.5] ISO/IEC8802-5情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート5: トークンリングアクセス法と物理的な層の仕様、(ANSI/IEEE Std802.5-1998も)、1998
[802.11] Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, IEEE Std. 802.11-1999, 1999.
[802.11]情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--特定のRequirements Part11: ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様、IEEE Std。 802.11-1999, 1999.
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985.
[RFC959] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[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月)。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with
the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027] HoldregeとM.とP.Srisuresh、「IPネットワークアドレス変換機構とのプロトコル複雑さ」、RFC3027、2001年1月。
[DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
Work in Progress, July 2004.
[DNAv4] Aboba、B.、「IPv4"でのネットワーク付属(DNA)の検出、処理中の作業、2004年7月。」
[LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast
Name Resolution (LLMNR)", Work in Progress, June 2004.
[LLMNR] 「Linklocalマルチキャスト名前解決(LLMNR)」というEsibov、L.、Aboba、B.、およびD.ターレルは進歩、2004年6月に動作します。
Acknowledgments
承認
We would like to thank (in alphabetical order) Jim Busse, Pavani Diwanji, Donald Eastlake 3rd, Robert Elz, Peter Ford, Spencer Giacalone, Josh Graessley, Brad Hards, Myron Hattig, Hugh Holbrook, Christian Huitema, Richard Johnson, Kim Yong-Woon, Mika Liljeberg, Rod Lopez, Keith Moore, Satish Mundra, Thomas Narten, Erik Nordmark, Philip Nye, Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery Smyslov, and Ryan Troll for their contributions.
彼らの貢献についてジムBusse、Pavani Diwanji、ドナルドイーストレーク3番目、ロバートElz、ピーター・フォード、スペンサーGiacalone、ジョッシュGraessley、ブラッドHards、マイロンHattig、ヒューHolbrook、クリスチャンのHuitema、リチャード・ジョンソン、キムヤング-Woon、ミカLiljeberg、Rodロペス、キース・ムーア、サティシュMundra、トーマスNarten、エリックNordmark、フィリップ・ナイ、ハワードRidenour、ダニエルSenie、Dieterジークムント、ヴァレリ・スミスロフ、およびライアンTrollに感謝申し上げます(アルファベット順に)。
Cheshire, et al. Standards Track [Page 27] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[27ページ]RFC3927IPv4
Appendix A - Prior Implementations
付録A--先の実装
A.1. Apple Mac OS 8.x and 9.x.
A.1。 アップルMac OS 8.xと9.x。
Mac OS chooses the IP address on a pseudo-random basis. The selected address is saved in persistent storage for continued use after reboot, when possible.
Mac OSは擬似ランダムベースに関するIPアドレスを選びます。 可能であるときに、選択されたアドレスはリブートの後に継続的な使用のための永続的なストレージで保存されます。
Mac OS sends nine DHCPDISCOVER packets, with an interval of two seconds between packets. If no response is received from any of these requests (18 seconds), it will autoconfigure.
Mac OSはパケットの間の2秒の間隔と共に9つのDHCPDISCOVERパケットを送ります。 それは、応答がいいえならこれらの要求(18秒)のどれかから受けられるのを自動構成するでしょう。
Upon finding that a selected address is in use, Mac OS will select a new random address and try again, at a rate limited to no more than one attempt every two seconds.
選択されたアドレスが使用中であることがわかるとき、Mac OSは、新しい無作為のアドレスを選択して、再試行するでしょう、2秒毎の1つ未満の試みに制限されたレートで。
Autoconfigured Mac OS systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Mac OS is not successful in obtaining a new lease, it keeps the existing autoconfigured IP address. If Mac OS is successful at obtaining a new lease, it drops all existing connections without warning. This may cause users to lose sessions in progress. Once a new lease is obtained, Mac OS will not allocate further connections using the autoconfigured IP address.
自動構成されたMac OSシステムは5分毎にDHCPサーバの存在がないかどうかチェックします。 DHCPサーバが見つけられますが、Mac OSが新しいリースを得るのに成功していないなら、それは既存の自動構成されたIPアドレスを保管します。 Mac OSが新しいリースを得るところにうまくいくなら、それはいきなりすべての既存の接続を下げます。 これはユーザが進行中のセッションを失われるかもしれません。 いったん新しいリースを得ると、Mac OSは、自動構成されたIPアドレスを使用することでさらなる接続を割り当てないでしょう。
Mac OS systems do not send packets addressed to a Link-Local address to the default gateway if one is present; these addresses are always resolved on the local segment.
1つが存在しているなら、Mac OSシステムはLink-ローカルアドレスに扱われたパケットをデフォルトゲートウェイに送りません。 これらのアドレスは地方のセグメントでいつも決議されています。
Mac OS systems by default send all outgoing unicast packets with a TTL of 255. All multicast and broadcast packets are also sent with a TTL of 255 if they have a source address in the 169.254/16 prefix.
Mac OSシステムはデフォルトで255のTTLがあるすべての出発しているユニキャストパケットを送ります。 また、それらに169.254/16接頭語のソースアドレスがあるなら、255のTTLと共にすべてのマルチキャストと放送パケットを送ります。
Mac OS implements media sense where the hardware (and driver software) supports this. As soon as network connectivity is detected, a DHCPDISCOVER will be sent on the interface. This means that systems will immediately transition out of autoconfigured mode as soon as connectivity is restored.
OSがメディアを実装するMacは、ハードウェア(そして、ドライバソフトウェア)がどこでこれをサポートするかを感じます。 ネットワークの接続性が検出されるとすぐに、インタフェースでDHCPDISCOVERを送るでしょう。 これは、接続性が回復するとすぐに、システムがすぐに自動構成されたモードから移行することを意味します。
A.2. Apple Mac OS X Version 10.2
A.2。 アップルMac OS Xバージョン10.2
Mac OS X chooses the IP address on a pseudo-random basis. The selected address is saved in memory so that it can be re-used during subsequent autoconfiguration attempts during a single boot of the system.
Mac OS Xは擬似ランダムベースに関するIPアドレスを選びます。 選択されたアドレスは、システムの単一のブーツのときにその後の自動構成試みの間、それを再使用できるようにメモリに保存されます。
Cheshire, et al. Standards Track [Page 28] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[28ページ]RFC3927IPv4
Autoconfiguration of a Link-Local address depends on the results of the DHCP process. DHCP sends two packets, with timeouts of one and two seconds. If no response is received (three seconds), it begins autoconfiguration. DHCP continues sending packets in parallel for a total time of 60 seconds.
Link-ローカルアドレスの自動構成はDHCPプロセスの結果に依存します。 DHCPは1と2秒のタイムアウトと共に2つのパケットを送ります。 応答を全く(3秒)受けないなら、それは自動構成を始めます。 DHCPは、60秒の合計時の間、平行なパケットを送り続けています。
At the start of autoconfiguration, it generates 10 unique random IP addresses, and probes each one in turn for 2 seconds. It stops probing after finding an address that is not in use, or the list of addresses is exhausted.
自動構成の始めでは、それは、10のユニークな無作為のIPアドレスを作って、2秒間、順番にそれぞれを調べます。 それが、使用中でないアドレスを見つけた後に調べるのを止めるか、または住所録は空になっています。
If DHCP is not successful, it waits five minutes before starting over again. Once DHCP is successful, the autoconfigured Link-Local address is given up. The Link-Local subnet, however, remains configured.
DHCPがうまくいかないなら、それは最初からやり直す前に、5分間待ちます。 DHCPがいったんうまくいくようになると、自動構成されたLink-ローカルアドレスはあきらめられます。 しかしながら、Link地方のサブネットは構成されたままで残っています。
Autoconfiguration is only attempted on a single interface at any given moment in time.
自動構成はいつなんどきでも時間内に、単一のインタフェースで試みられるだけです。
Mac OS X ensures that the connected interface with the highest priority is associated with the Link-Local subnet. Packets addressed to a Link-Local address are never sent to the default gateway, if one is present. Link-local addresses are always resolved on the local segment.
Mac OS Xは、最優先との接続インタフェースがLink地方のサブネットに関連しているのを確実にします。 1つが存在しているなら、Link-ローカルアドレスに扱われたパケットをデフォルトゲートウェイに決して送りません。 リンクローカルのアドレスは地方のセグメントでいつも決議されています。
Mac OS X implements media sense where the hardware and driver support it. When the network media indicates that it has been connected, the autoconfiguration process begins again, and attempts to re-use the previously assigned Link-Local address. When the network media indicates that it has been disconnected, the system waits four seconds before de-configuring the Link-Local address and subnet. If the connection is restored before that time, the autoconfiguration process begins again. If the connection is not restored before that time, the system chooses another interface to autoconfigure.
OS Xがメディアを実装するMacは、ハードウェアとドライバーがどこでそれをサポートするかを感じます。 ネットワークメディアが、それを接続してあるのを示すとき、自動構成プロセスは、やり直して、以前に割り当てられたLink-ローカルアドレスを再使用するのを試みます。 ネットワークメディアが、それ切断されたのを示すとき、反-Link-ローカルアドレスとサブネットを構成する前に、システムは4秒待ちます。 接続がその時以前復元されるなら、自動構成プロセスはやり直します。 接続がその時以前復元されないなら、システムは自動構成する別のインタフェースを選びます。
Mac OS X by default sends all outgoing unicast packets with a TTL of 255. All multicast and broadcast packets are also sent with a TTL of 255 if they have a source address in the 169.254/16 prefix.
Mac OS Xはデフォルトで255のTTLがあるすべての出発しているユニキャストパケットを送ります。 また、それらに169.254/16接頭語のソースアドレスがあるなら、255のTTLと共にすべてのマルチキャストと放送パケットを送ります。
A.3. Microsoft Windows 98/98SE
A.3。 マイクロソフトWindows 98/98SE
Windows 98/98SE systems choose their IPv4 Link-Local address on a pseudo-random basis. The address selection algorithm is based on computing a hash on the interface's MAC address, so that a large collection of hosts should obey the uniform probability distribution in choosing addresses within the 169.254/16 address space. Deriving
Windows 98/98SEシステムは擬似ランダムベースに関するそれらのIPv4 Link-ローカルアドレスを選びます。 アドレス選択アルゴリズムはインタフェースのMACアドレスでハッシュを計算するのに基づいています、ホストの大きい収集が169.254/16アドレス空間の中でアドレスを選ぶ際に一定の確率分布に従うべきであるように。 派生
Cheshire, et al. Standards Track [Page 29] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[29ページ]RFC3927IPv4
the initial IPv4 Link-Local address from the interface's MAC address also ensures that systems rebooting will obtain the same autoconfigured address, unless a conflict is detected.
また、インタフェースのMACアドレスからの初期のIPv4 Link-ローカルアドレスは、リブートが同じように入手するシステムがアドレスを自動構成したのを確実にします、闘争が検出されない場合。
When in INIT state, the Windows 98/98SE DHCP Client sends out a total of 4 DHCPDISCOVERs, with an inter-packet interval of 6 seconds. When no response is received after all 4 packets (24 seconds), it will autoconfigure an address.
INIT状態にあるとき、Windows 98/98SE DHCP Clientは合計4DHCPDISCOVERsを出します、6秒の相互パケット間隔で。 すべての4つのパケット(24秒)の後に応答を全く受けないとき、それはアドレスを自動構成するでしょう。
The autoconfigure retry count for Windows 98/98SE systems is 10. After trying 10 autoconfigured IPv4 addresses, and finding all are taken, the host will boot without an IPv4 address.
Windows 98/98SEシステムのための再試行カウントが10であることを自動構成してください。 ホストは、IPv4アドレスなしで試みた後に、10が、IPv4が扱うのを自動構成して、見つけて、すべてが取られるのをブートするでしょう。
Autoconfigured Windows 98/98SE systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Windows 98 is not successful in obtaining a new lease, it keeps the existing autoconfigured IPv4 Link-Local address. If Windows 98/98SE is successful at obtaining a new lease, it drops all existing connections without warning. This may cause users to lose sessions in progress. Once a new lease is obtained, Windows 98/98SE will not allocate further connections using the autoconfigured IPv4 Link-Local address.
自動構成されたWindows 98/98SEシステムは5分毎にDHCPサーバの存在がないかどうかチェックします。 DHCPサーバが見つけられますが、Windows 98が新しいリースを得るのに成功していないなら、それは既存の自動構成されたIPv4 Link-ローカルアドレスを保ちます。 Windows 98/98SEが新しいリースを得るところにうまくいくなら、それはいきなりすべての既存の接続を下げます。 これはユーザが進行中のセッションを失われるかもしれません。 いったん新しいリースを得ると、Windows 98/98SEは、自動構成されたIPv4 Link-ローカルアドレスを使用することでさらなる接続を割り当てないでしょう。
Windows 98/98SE systems with an IPv4 Link-Local address do not send packets addressed to an IPv4 Link-Local address to the default gateway if one is present; these addresses are always resolved on the local segment.
1つが存在しているなら、IPv4 Link-ローカルアドレスがあるWindows 98/98SEシステムはIPv4 Link-ローカルアドレスに扱われたパケットをデフォルトゲートウェイに送りません。 これらのアドレスは地方のセグメントでいつも決議されています。
Windows 98/98SE systems by default send all outgoing unicast packets with a TTL of 128. TTL configuration is performed by setting the Windows Registry Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\ Parameters\DefaultTTL of type REG_DWORD to the appropriate value. However, this default TTL will apply to all packets. While this facility could be used to set the default TTL to 255, it cannot be used to set the default TTL of IPv4 Link-Local packets to one (1), while allowing other packets to be sent with a TTL larger than one.
Windows 98/98SEシステムはデフォルトで128のTTLがあるすべての出発しているユニキャストパケットを送ります。 TTL構成はWindows Registry Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesを設定することによって、実行されます: 適切な値へのタイプレッジ_DWORDの\Tcpip\Parameters\DefaultTTL。 しかしながら、このデフォルトTTLはすべてのパケットに適用するでしょう。 デフォルトTTLを255に設定するのにこの施設を使用できましたが、TTLが1より大きい状態で他のパケットが送られるのを許容している間IPv4 Link地方のパケットのデフォルトTTLを1つ(1)に設定するのにそれは使用できません。
Windows 98/98SE systems do not implement media sense. This means that network connectivity issues (such as a loose cable) may prevent a system from contacting the DHCP server, thereby causing it to auto-configure. When the connectivity problem is fixed (such as when the cable is re-connected) the situation will not immediately correct itself. Since the system will not sense the re-connection, it will remain in autoconfigured mode until an attempt is made to reach the DHCP server.
Windows 98/98SEシステムは、メディアが感覚であると実装しません。 これは問題(ゆるいケーブルなどの)が自動構成するためにシステムがDHCPサーバに連絡して、その結果、それを引き起こすのを防ぐかもしれないそのネットワークの接続性を意味します。 接続性問題がすぐに固定されているとき(ケーブルが再接続される時などの)、状況はそれ自体を修正しないでしょう。 システムが再接続を感じないので、DHCPサーバに達するのを試みをするまで、それは自動構成されたモードで残るでしょう。
Cheshire, et al. Standards Track [Page 30] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[30ページ]RFC3927IPv4
The DHCP server included with Windows 98SE Internet Connection Sharing (ICS) (a NAT implementation) allocates out of the 192.168/16 private address space by default.
Windows98SEインターネット接続共有(ICS)(NAT実装)と共にDHCPサーバを含んでいると、192.168/16プライベート・アドレスから、スペースはデフォルトで割り当てられます。
However, it is possible to change the allocation prefix via a registry key, and no checks are made to prevent allocation out of the IPv4 Link-Local prefix. When configured to do so, Windows 98SE ICS will rewrite packets from the IPv4 Link-Local prefix and forward them beyond the local link. Windows 98SE ICS does not automatically route for the IPv4 Link-Local prefix, so that hosts obtaining addresses via DHCP cannot communicate with autoconfigured-only devices.
しかしながら、登録キーを通して配分接頭語を変えるのが可能であり、IPv4 Linkローカルの接頭語から配分を防ぐのをチェックを全くしません。 そうするために構成されると、Windows98SE ICSはIPv4 Linkローカルの接頭語からパケットを書き直して、地方のリンクを超えてそれらを送るでしょう。 それがDHCPを通して入手アドレスをホスティングして、98SE ICSがIPv4 Linkローカルの接頭語のために自動的に発送しないウィンドウズは自動構成されて唯一のデバイスとコミュニケートできません。
Other home gateways exist that allocate addresses out of the IPv4 Link-Local prefix by default. Windows 98/98SE systems can use a 169.254/16 IPv4 Link-Local address as the source address when communicating with non-Link-Local hosts. Windows 98/98SE does not support router solicitation/advertisement. Windows 98/98SE systems will not automatically discover a default gateway when in autoconfigured mode.
デフォルトでIPv4 Linkローカルの接頭語からアドレスを割り当てる他のホームゲートウェイが存在しています。 非リンクのローカル・ホストとコミュニケートするとき、Windows 98/98SEシステムはソースアドレスとして169.254/16IPv4 Link-ローカルアドレスを使用できます。 Windows 98/98SEはルータ懇願/広告をサポートしません。 自動構成されたモードで発見するとき、Windows 98/98SEシステムは自動的にデフォルトゲートウェイを発見しないでしょう。
A.4. Windows XP, 2000, and ME
A.4。 Windows XP、2000、および私
The autoconfiguration behavior of Windows XP, Windows 2000, and Windows ME systems is identical to Windows 98/98SE except in the following respects:
以下の点を除いて、Windows XP、Windows2000、およびWindows MEシステムの自動構成働きはWindows 98/98SEと同じです:
Media Sense Router Discovery Silent RIP
メディアはルータの発見の静かな裂け目を感じます。
Windows XP, 2000, and ME implement media sense. As soon as network connectivity is detected, a DHCPREQUEST or DHCPDISCOVER will be sent on the interface. This means that systems will immediately transition out of autoconfigured mode as soon as connectivity is restored.
XP、2000、およびME道具メディアが気付くウィンドウズ。 ネットワークの接続性が検出されるとすぐに、インタフェースでDHCPREQUESTかDHCPDISCOVERを送るでしょう。 これは、接続性が回復するとすぐに、システムがすぐに自動構成されたモードから移行することを意味します。
Windows XP, 2000, and ME also support router discovery, although it is turned off by default. Windows XP and 2000 also support a RIP listener. This means that they may inadvertently discover a default gateway while in autoconfigured mode.
それがデフォルトでオフにされますが、またXP、2000、およびMEがルータ発見であるとサポートするウィンドウズ。 また、Windows XPと2000はRIPリスナーをサポートします。 これは、自動構成されたモードで意味する間、彼らがうっかりデフォルトゲートウェイを発見するかもしれないことを意味します。
ICS on Windows XP/2000/ME behaves identically to Windows 98SE with respect to address allocation and NATing of Link-Local prefixes.
Windows XP/2000/MEのICSは同様にLinkローカルの接頭語のアドレス配分とNATingに関してWindows98SEに振る舞います。
Cheshire, et al. Standards Track [Page 31] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[31ページ]RFC3927IPv4
Authors' Addresses
作者のアドレス
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014, USA
カリフォルニア 95014、スチュアートチェーシャー州アップル・コンピューターInc.1無限ループカルパチーノ米国
Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org
以下に電話をしてください。 +1 3207年の408 974メール: rfc@stuartcheshire.org
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 818 4011 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 4011年の425 818メール: bernarda@microsoft.com
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
エリックGuttmanサン・マイクロシステムズEichhoelzelstr。 7 74915Waibstadtドイツ
Phone: +49 7263 911 701 EMail: erik@spybeam.org
以下に電話をしてください。 +49 7263 911 701はメールされます: erik@spybeam.org
Cheshire, et al. Standards Track [Page 32] RFC 3927 IPv4 Link-Local May 2005
チェーシャー州、他 2005年5月のリンク地方の標準化過程[32ページ]RFC3927IPv4
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Cheshire, et al. Standards Track [Page 33]
チェーシャー州、他 標準化過程[33ページ]
一覧
スポンサーリンク
