Network Working Group                                        S. Cheshire
Request for Comments: 3927                                Apple Computer
Category: Standards Track                                       B. Aboba
                                                   Microsoft Corporation
                                                              E. Guttman
                                                        Sun Microsystems
                                                                May 2005
           Dynamic Configuration of IPv4 Link-Local Addresses

Status of This Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice


Copyright (C) The Internet Society (2005).




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ネットワークに参加するには、ホストは、DHCP(Dynamic Host Configuration Protocol)サーバとしてユーザーによってまたは自動的にネットワーク上のソースから手動で、そのインターフェイスのIPアドレスを設定する必要があります。残念ながら、このようなアドレス構成情報は常に利用できない場合があります。ホストは何のアドレスの設定が利用できない場合でも、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.


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. 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ツールを使用することができることが、ますます貴重になります。例えば、IEEE 802.11無線LANをサポートしているラップトップコンピュータとの二人[802.11]に合致するとファイルを交換することもできます。これらの人々は、手動で静的IPアドレスを設定するか、DHCPサーバ[RFC2131]を設定することの不便なしIPアプリケーションソフトウェアを使用できるようにすることが望ましいです。

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].

この文書では、ホストが自動的にそのインターフェイスのリンクローカル通信のために有効である169.254 / 16プレフィックスでIPv4アドレスを持つインターフェイスを設定するする方法を説明します。これは、他の設定メカニズムが利用できない環境では特に貴重です。 IPv4のプレフィックス169.254 / 16は、この目的のためにIANAに登録されています。 IPv6のリンクローカルアドレスの割り当ては、「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のリンクローカルアドレスを使用してリンクローカル通信は、同じ物理(または論理)リンクに接続された他の機器と通信するためにのみ適しています。 IPv4のリンクローカルアドレスを使用してリンクローカル通信は、直接同じ物理(または論理)リンクに接続されていないデバイスとの通信には適していません。

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(以降)およびMacはOS 8.5(以降)はすでにこの機能をサポートしています。この文書では、IPv4リンクローカルアドレスはホストとルータによって処理される方法のためのルールを定め、使用方法を標準化しています。特に、ルータが送信元または宛先アドレスにIPv4のリンクローカルアドレスを持つパケットを受信したときに動作するようにしている方法について説明します。ホストに関しては、リンクローカルおよびルーティング可能な同じインターフェイスに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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります「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:


- 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.


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

この文書では、用語「ルーティング可能なアドレスが」ルーターを介して転送することができる169.254 / 16プレフィックスの外、すべての有効なユニキャストIPv4アドレスを参照して使用しています。これは、すべてのグローバルIPアドレスと、このようなネット10/8 [RFC1918]などのプライベートアドレスを含むが、などのアドレスをループバックではありません。

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.


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.

このドキュメントは、ARPパケットの文脈における用語「送信元IPアドレス」または「ターゲットIPアドレス」を使用してどこに、それは([RFC826]「のar $スパ」としてARP仕様で特定されたARPパケットのフィールドを参照しています送信者のプロトコルアドレス)とそれぞれ「ARます$ TPA」(ターゲットプロトコルアドレス)。 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パケットを意味するために使用されます。 「送信者のハードウェアアドレス」パケットを送信するインターフェイスのハードウェアアドレスを含まなければなりません。 「ターゲットハードウェアアドレス」フィールドは、無視され、すべてゼロに設定する必要があります。 「ターゲット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 Requestパケットを参照するために使用され、ARPプローブと同一の両方の送信者とターゲットIPアドレスフィールドが発表されているIPアドレスが含まれていることを除いて、上記の。

Constants are introduced in all capital letters. Their values are given in Section 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.

この仕様は、で動作し、イーサネット[802.3]、トークンリング[802.5]とIEEE 802.11無線LAN [802.11]と同様に他のリンク層技術を含むすべてのIEEE 802ローカルエリアネットワーク(LAN)[802]、に適用されます少なくとも1 Mbpsのデータ転送速度は、最大1秒のラウンドトリップ遅延を持ち、ARP [RFC826]をサポートしています。この文書は、用語「IEEE 802」を使用してどこ、テキストは、これらのネットワーク技術のいずれにも同様に適用されます。

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をサポートしますが、1 Mbpsまたは1秒以上の待ち時間以下の速度で動作するリンク層技術は、次のパラメータに異なる値を指定する必要があります。

(a) the number of, and interval between, ARP probes, see PROBE_NUM, PROBE_MIN, PROBE_MAX defined in Section 2.2.1


(b) the number of, and interval between, ARP announcements, see ANNOUNCE_NUM and ANNOUNCE_INTERVAL defined in Section 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


(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


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.


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.

ほんの数のホストを含​​む単一のリンク - この仕様は、小さな広告アドホックネットワークで使用するためのものです。 65024のIPv4リンクローカルアドレスは、原則的に利用可能であるが、単一リンク上のすべてのこれらのアドレスを使用しようとすると、使用可能なアドレスを見つけるために途方もない時間を取るためにホストを必要とし、アドレス競合の確率が高くなります。

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% 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.

単一リンク上で1300台の以上のホストとネットワーク事業者は、二つ以上のサブネットにその単一のリンクを分割することを検討してください。すでに1300台のホストを持っているリンクに接続しているホストは、ランダムでのIPv4リンクローカルアドレスを選択し、最初の試み上の未使用のIPv4リンクローカルアドレスを選択する98%のチャンスがあります。ホストは、2回の試行の中の未使用のIPv4リンクローカルアドレスを選択するの99.96パーセントのチャンスがあります。それは10倍以上を試してみなければならない確率は約1〜10 ^ 17です。

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.


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.


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.


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リンクローカルアドレスを使用すると、アプリケーションの障害を引き起こす可能性があります。これは、IPv4リンクローカルアドレスが埋め込まれている場合、リンク上に存在しないホストと通信する際に、埋め込まれたアドレスを含む任意のアプリケーション内で発生する可能性があります。アドレスを埋め込むアプリケーションの例としては、IPsec、Kerberosの4/5、FTP、RSVP、SMTP、SIP、X-Windowsの/ xtermに/ Telnetを、リアルタイムオーディオ、H.323、およびSNMP [RFC3027]を含んでいます。

To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised:


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, "" 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 "" domain.

A。 IPv4のリンクローカルアドレスをDNSに設定しないでください。 IPv4からのマッピングは、通常、フォームの名前のDNSクエリを発行することによって行われているアドレスをホスト名に「を。」唯一のローカルリンク上の意味を持っているリンクローカルアドレスに使用する場合は、ローカルリンクを超えて、このようなDNSクエリを送信することは不適切です。 DNSクライアントは、範囲内にある任意の名前のためのDNSクエリを送ってはいけません「。」ドメイン。

DNS recursive name servers receiving queries from non-compliant clients for names within the "" domain MUST by default return RCODE 3, authoritatively asserting that no such name exists in the Domain Name System.

内の名前のために非対応のクライアントからの問い合わせを受けたDNS再帰ネームサーバ「。」デフォルトの戻りRCODE 3によってドメインMUSTは、正式にはそのような名前は、ドメインネームシステムに存在しないことを主張します。

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.


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.


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のリンクローカルアドレス自動設定は、アドレスの競合を期待しなければならない、と2章で述べたように、アドレスの競合を検出して処理するため、この要件は時に適用され、自動的に競合が検出されるたびに新しいアドレスを選択することで、優雅にそれらを処理するために準備しなければなりませんの実装ホストだけではなく、最初のインターフェイス設定時に、169.254 / 16のIPv4リンクローカルアドレスを使用していることを全期間。例えば、アドレスの競合は、二つの以前の別個のネットワークが結合されている場合、セクション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プレフィックスのアドレスは、手動またはDHCPサーバによって設定されるべきではないことに注意してください。手動またはDHCPの設定は、ホストがこのプレフィックスのアドレスに関連する重複検出と自動設定に関する特別なルールに従わずに169.254 / 16のプレフィックスでアドレスを使用することがあります。 DHCP仕様[RFC2131]はDHCPクライアントがARPと新たに受信したアドレスを調べる必要があることを示しているが、これは必須ではありません。同様にDHCP仕様は、DHCPサーバがそれを割り当てる前にICMPエコー要求を使用してアドレスを調べることを推奨しながら、これも必須ではありません、そしてサーバーがこれを行う場合でも、IPv4のリンクローカルアドレスはルーティングできませんので、DHCP直接リンクに接続されていないサーバは、そのリンク上のホストがすでに希望のIPv4リンクローカルアドレスを使用しているかどうかを検出することはできません。

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.


1.8. Communication with Routable Addresses
1.8. ルーティング可能なアドレスとのコミュニケーション

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.

構成されたリンクローカルアドレスを持つデバイスは、その逆も同じ物理リンク上に構成ルーティング可能なアドレスを持つデバイスと通信する必要がある、となります例があります。 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.


1.9. When to configure an IPv4 Link-Local address
1.9. IPv4のリンクローカルアドレスを設定した場合

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:


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.


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:


               * Manual configuration
               * Address assignment through DHCP
               * Roaming of the host to a network on which a previously
                 assigned address becomes operable

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:


               * Removal of the address from the interface through
                 manual configuration
               * Expiration of the lease on the address assigned through
               * Roaming of the host to a new network on which the
                 address is no longer operable.

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.

アドレスが「動作可能」であるか否かのシステムによる判定が明確と、システムコンテキストの多くの変更はない(例えば、ルータの変更)は、アドレスの操作性に影響を及ぼし得ます。特定のではない - - 別のネットワークからのホストの特定のローミングにそうであるように構成アドレスの操作性を変更することなく、そのような動きを検出することは必ずしも容易ではありません。

"Detection of Network Attachment (DNA) in IPv4" [DNAv4] provides further discussion of address assignment and operability determination.


2. Address Selection, Defense and Delivery

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.


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.

すでにリンクローカルIPv4アドレスの自動構成を実装し、Windowsと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 to inclusive.


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.

異なるホストが数字の同じシーケンスを生成しないように、擬似乱数生成アルゴリズムを選択しなければなりません。ホストは、そのIEEE 802 MACアドレスとホストごとに異なっている永続的な情報へのアクセスを有する場合、擬似乱数生成器は、この情報から導出された値を用いて播種されるべきです。これはさえ、他の永続ストレージを使用せずに、ホストは通常​​、同じIPv4のリンクローカルアドレスに、デバッグおよびその他の運用上の理由のために便利なことができ、それが起動するたびに、選択することを意味します。リアルタイムクロック、またはすべてのホストで同一である(またはであってもよい)は、任意の他の情報を使用して擬似乱数発生器をシードするため、すべて同じ時刻に電源が投入されているホストのグループかもしれないが、この目的に適していませんすべてのホストは、彼らが調べるすべてのアドレスに競合し、まったく同じ擬似ランダムシーケンスをロックステップで移動するよう紛争の終わることのないシリーズで、その結果、同じシーケンスを生成します。

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.


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.


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.


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.


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.

スリープ状態から再起動/起動ウェイク(ネットワークインタフェースは、睡眠中に不活性であった場合)以前に非アクティブなネットワークインターフェースIEEE 802のハードウェアリンク状態変化(適用メディアタイプとセキュリティメカニズムのための適切な)を育てるインタフェースがアクティブになったことを示しています。無線基地局またはアドホックネットワークとの関連付け。

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.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をサポートするようIEEE 802などのリンク層上で、衝突検出がARPプローブを用いて行われます。リンク層の上にARP他の技術をサポートしていない技術は、特定のIPv4アドレスが現在使用中であるかどうかを決定するために利用できます。しかしながら、そのようなネットワークへの請求アンド防御メカニズムのアプリケーションは、この文書の範囲外です。

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要求をブロードキャストすることによってすでに使用されているかどうかを確認するために、ホストのプローブ。クライアントは、それがパケットを送信するためのインターフェイスのハードウェアアドレスを持つARPリクエストの送信元のハードウェアアドレス]フィールドに入力する必要があります。 「送信元IPアドレス」フィールドは、アドレスが別のホストによってすでに使用中であることが判明した場合、同じリンク上の他のホストにARPキャッシュを汚染を避けるために、すべてゼロに設定しなければなりません。 「ターゲットハードウェアアドレス」フィールドは、無視され、すべてゼロに設定する必要があります。 「ターゲットIPアドレス」フィールドは、プローブさのアドレスに設定しなければなりません。オールゼロ「送信者のIPアドレス」でこのように構築されたARP要求は、「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秒まで、この期間中であれば、最後のプローブ・パケットが送信された後、ホストはプローブは、パケットの「送信元に行われているインターフェイス上のすべてのARPパケット(リクエスト*または* Reply)を受け取り、 IPアドレスの場合は、ホストが他のホストによって使用中であると、このアドレスを扱わなければならないためにプローブさアドレスで、新しい擬似ランダムアドレスを選択し、プロセスを繰り返す必要があります。この期間中にホストがARPプローブを受信した場合に加えて、パケットの「ターゲットIPアドレスは」のプローブさのアドレスであり、パケットの「送信元ハードウェアアドレスは」ホストが設定しようとしているインターフェイスのハードウェアアドレスでない場合、ホストは同様にアドレスの競合としてこれを扱わなければなりませんし、上記のように新しいアドレスを選択します。 2つ(またはそれ以上)のホストが同時に同じIPv4のリンクローカルアドレスを設定しようとした場合に発生する可能性があります。

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.


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.


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.


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プローブは今ことを除いて、上記の送信者とターゲット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.


A host MUST respond to a conflicting ARP packet as described in either (a) or (b) below:


(a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately configure a new IPv4 Link-Local address as described above, or


(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 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.


A host MUST respond to conflicting ARP packets as described in either (a) or (b) above. A host MUST NOT ignore conflicting ARP packets.


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.


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.


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.


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.

リンクローカル「送信元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.


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 choice about what source address to use when it sends a packet or initiates a TCP connection.


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のリンクローカルとルーティング可能なアドレスの両方が同じインターフェイスで利用可能である場合、ルーティング可能なアドレスは、新しい通信の送信元アドレスとして好まれるべきであるが、予想通りからまたはIPv4リンクローカルアドレスに送信されたパケットは、まだ配信されています。 IPv4のリンクローカルアドレスは、好ましいアドレスへの切り替えがあるため上位層プロトコル(例えば、既存の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.


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, 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.255.255を除く)169.254 / 16接頭辞である場合、送信者は、宛先アドレスのARPとそのを送らなければなりません直接同じ物理リンク上の宛先へパケットを。これは、インターフェイスがリンクローカルまたはルーティング可能な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.


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 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.

宛先アドレスが169.254 / 16プレフィックス外部ユニキャストアドレスである場合、それが可能な場合、ホストは、適切なルーティング可能なIPv4ソースアドレスを使用する必要があります。何らかの理由でホストがIPv4リンクローカル送信元アドレスを持つパケットを送信することを選択した場合(例えば、何のルーティング可能なアドレスを選択したインタフェースで提供されていない)、それは宛先アドレスに対してARPをしなければならないし、その後はIPv4と、そのパケットを送信しますリンクローカル送信元アドレスとルーティング可能な宛先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".


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, 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.


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.


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要求に応答してはなりません。ルータは、もちろん、それが合法的に、この文書で説明する請求-と-守るのプロトコルに従って、自身の使用のために主張したことが一つ以上のIPv4リンクローカルアドレス(複数可)のARP要求に答えることがあります。

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.


2.8. Link-Local Packets are Local
2.8. リンクローカルパケットはローカルです

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ベースアドレス競合検出を利用します。こうしたブロードキャストが転送されないので、競合が検出されないままでした対処その後、許可するサブネットました。

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.


2.9. Higher-Layer Protocol Considerations
2.9. 上位層プロトコルの考慮事項

Similar considerations apply at layers above 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.


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.


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リンクローカルアドレスの漏洩を制限するもう一つの理由は、プライバシーの問題です。 IPv4のリンクローカルアドレスは、MACアドレスのハッシュから派生している場合は、いくつかは、彼らが間接的に個々に関連付けられ、それによってその個人の活動を追跡するために使用することができることを主張しています。ローカルリンク内のパケット内のハードウェアアドレスは、ハードウェアアドレスを直接観察によって得られる可能性よりも、IPv4のリンクローカルアドレスは、侵入者に、彼らは何もより多くの情報を提供しないローカルリンクを残していないので、限り、すべての直接観測可能です。

2.11. Interaction between DHCPv4 client and IPv4 Link-Local State Machines

2.11. DHCPv4のクライアントとIPv4リンクローカルステートマシン間の相互作用

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.


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リンクローカルとのDHCPv4クライアントがIPv4リンクローカルコンフィギュレーションに対応するためのDHCPv4クライアントの動作を変更するべきではありません。 IPv4のリンクローカルアドレスの特定の構成では、DHCPサーバが現在応答しているかどうかにかかわらず、DHCPタイムアウトを変更するには、新しいIPアドレスを取得しようとするからDHCPクライアントを停止するには、有効なDHCPリースを構成解除するのに十分な理由ではありませんあるいは他の方法でDHCPステートマシンの動作を変更します。

Further discussion of this issue is provided in "Detection of Network Attachment (DNA) in IPv4" [DNAv4].


3. Considerations for Multiple Interfaces

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".


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.

複数のアクティブなインターフェイスを有しており、これらのインタフェースの一つ以上でIPv4リンクローカルアドレスの動的な構成を実装することを選択したホストは、様々な問題に直面するだろう。このセクションでは、これらの問題を示していますが、1つはそれらを解決する方法を示しているよりも多くしません。この記事の執筆時点では、一般的な方法で、すべての場合において、これらの問題を解決特効薬はありません。実装者は、マルチホーミングが可能TCP / IPスタックの一部として、複数のアクティブなインターフェイスを持っている可能性のあるシステム上で、この文書で指定されたプロトコルを実装する前に、これらの問題をよく考えなければなりません。

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.


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.


The second scoped address problem arises from scoped parameters leaking outside their scope. This is discussed in Section 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.


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.


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?


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.


One possibility is to support this only in the case where the application specifically expresses which interface to send from.


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プロトコル・スイートのために書かれた既存のアプリケーションソフトウェアは、アドレスあいまいさを扱うの大部分は不可能です。これは、解決策を見つけ、それを使用することができますアプリケーションを作成し、複数のインターフェイス上でのIPv4リンクローカルアドレスの動的な構成をサポートすることができますホストの提供から実装することを妨げるものではありません。このソリューションは、ほぼ確実しかし、一般的に、既存のソフトウェアに適用されると、上位層に対して透過的ではありません。

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 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. ルーティング可能なアドレスとホストとの対話

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.


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.


                         i1 +---------+ i2   i3 +-------+
               ROUTER-------=  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は、リンク1とリンク2に接続されています。 i2がIPv4のリンクローカルアドレスである一方、インターフェースI1は、ルーティング可能なアドレスを使用して設定されています。 HOST1は、I1を通じて、ルータのアドレスに設定されたデフォルトルートを持っています。 HOST1はI2に169.254 / 16で目的地へのルートは、宛先に直接送信し、意志。

HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3.


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のアドレスを発見することができます。 HOST2のアドレスは169.254 / 16ではないので、HOST1のルーティングポリシーは、ルータに、I1を経由してHOST2にデータグラムを送信します。 HOST2へのルータからのルートがある場合を除き、HOST2にHOST1から送信されたデータグラムはそれに達することはありません。

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つの解決策は、それが到達不能ICMPエラーメッセージ(ICMPメッセージコード0、1、6又は7 [RFC792])を受信するために(ARPを使用して)局所的に任意のホストに到達しようとするホストのためのものです。ホストは、ラウンドロビン方式ですべての接続されたリンクをしようとします。これは、まさにこの問題を回避するために、いくつかのIPv6ホストのために正常に実装されています。この例の観点では、ルータを経由して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.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.

マルチホームホストは、IPv4リンクローカル自動設定をサポートするすべてが同じリンク上の複数のインタフェースをサポートできる場合は注意が必要です。これらのインターフェイスは、同じアドレスを割り当てようとした場合、彼らはそれ自体に対してホストを守るだろう - と主張するアルゴリズムが失敗する原因。この問題の最も簡単な解決策は、IPv4リンクローカルアドレスで構成され、各インターフェイス上で独立したアルゴリズムを実行することです。

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.


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.


4. Healing of Network Partitions

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.


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.


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.


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リンクローカル送信元アドレスを持つARP応答を送信すると、これらの競合は、すぐに彼らは潜在的な問題が、ないより早くなっていないとして検出することができることを保証します。 2つの互いに素ネットワークリンクが接合されている場合、例えば、ホストAとBの両方が同じリンクローカルアドレス、Xを設定した場合、それらは通信を開始するためにA、B、またはいくつかの他のホストの試行までこの状態に留まることができます。いくつかの他のホストCは現在、アドレスXのARP要求を送信し、従来のユニキャストARP応答でAとBの両方が、返信にいたホスト、そして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 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.


5. Security Considerations

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.


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.


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.


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.


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.


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 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.

実装者は、インターネット・プロトコル・アーキテクチャは、すべてのネットワークデバイスまたはホストがデバイスまたはホストは、既知または信頼できる脅威に対してネットワーク自体、などのアクセスを、持っているにリソースを保護するのに適しており、セキュリティを実装する必要があります期待していることをお勧めします。 IPv4のリンクローカルアドレスの使用は、デバイスがさらされる脅威の数を減らすことができるにもかかわらず、インターネットプロトコルをサポートするデバイスの実装者は、顧客のローカルネットワークがセキュリティリスクから自由であると仮定してはいけません。

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.


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.


6. Application Programming Considerations

Use of IPv4 Link-Local autoconfigured addresses presents additional challenges to writers of applications and may result in existing application software failing.


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.


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リンクローカルアドレスの設定をサポートするIPの実装に使用されるアプリケーションソフトウェアを生成するベンダー。 IPv4のリンクローカルアドレスの設定をサポートしている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.


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 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.

アドレス情報は、失敗する可能性が転送既存の分散アプリケーションソフトウェア。例えば、FTPは、[RFC959](パッシブモードを使用しない場合)、クライアントのIPアドレスを送信します。クライアントが起動し、それが唯一のリンクローカルアドレスを持っている時にそのIPv4の設定を取得したとします。その後、ホストは、グローバルIPアドレスを取得し、クライアントはローカルリンク外のFTPサーバー。 FTPクライアントはその古いリンクローカルアドレスの代わりに、FTP「ポート」コマンドでその新たなグローバルIPアドレスを送信した場合、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.


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のリンクローカルアドレスは、単一のリンク上で一意です。簡単に同じアドレスが他に後、複数のインタフェース上に存在する、または1つのインターフェイス上で最初の状況に遭遇することができ、複数のリンクに接続されたホスト。どのような場合には、複数のホストに関連付けられています。ほとんどの既存のソフトウェアは、この曖昧さのために用意されていません。将来的には、アプリケーション・プログラミング・インターフェースは、この問題を回避するために開発することができます。この問題は、第3節で議論されます。

7. Router Considerations

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.


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.


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を割り当てました。 「IANAに書くためのガイドライン」(BCP 26)[RFC2434]で定義されるように、この範囲(169.254.0.xと169.254.255.x)の最初と最後の256個のアドレスは、標準アクションによって割り当てられます。他のIANAサービスは、この文書で必要ありません。

9. Constants

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_WAIT 1秒(初期ランダム遅延)PROBE_NUM 3(プローブパケットの数)PROBE_MIN 1秒(繰り返しプローブまでの最小遅延)PROBE_MAX 2秒(繰り返しプローブまでの最大遅延)ANNOUNCE_WAIT 2秒(発表前に遅延)ANNOUNCE_NUM 2(発表の数パケット)ANNOUNCE_INTERVAL 2秒(告知パケット間の時間))RATE_LIMIT_INTERVAL 60秒(連続する試行間の遅延)DEFEND_INTERVAL 10秒間防御のARPとの間の(最小間隔)を律速前に10(最大競合をMAX_CONFLICTS。

10. References
10.1. Normative References
10.1. 引用規格

[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.

[RFC792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、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ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[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問題部に書くためのガイドライン"、BCP 26、RFC 2434、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規格802、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 / IEC 8802-3情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - 第3部:キャリアセンス衝突検出(CSMA / CD)アクセス方法および物理層仕様、多重アクセス(また、ANSI / IEEE規格802.​​3- 1996)、1996。

[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 / IEC 8802から5情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - 第5部:トークンリングアクセス方式および物理層仕様、(また、ANSI / IEEE規格802.​​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]情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 固有の要件パート11:無線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.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、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.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。

[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.

[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。

[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.

[RFC3027]ホールドレッジ、M.とP. Srisuresh、RFC 3027、2001年1月 "IPネットワークアドレス変換とプロトコル合併症"。

[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] Esibov、L.、Aboba、B.とD.ターラー、 "リンクローカルマルチキャスト名前解決(LLMNR)"、進歩、2004年6月での作業。



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.

我々は(アルファベット順)ジム・ブッセ、Pavani Diwanji、ドナルドイーストレイク3日、ロバート・エルツ、ピーター・フォード、スペンサーGiacalone、ジョシュGraessley、ブラッド・ハーズ、マイロンHattig、ヒュー・ホルブルック、クリスチャンのHuitema、リチャード・ジョンソン、キムYong-に感謝したいと思いますウーン、ミカLiljeberg、ロッド・ロペス、キースムーア、サティシュムンドラ、トーマスNarten氏、エリックNordmarkと、フィリップ・ナイ、ハワードRidenour、ダニエルSenie、ディーター・ジークムント、ヴァレリーSmyslov、そして彼らの貢献のためのライアントロール。

Appendix A - Prior Implementations

付録A - 以前の実装

A.1. Apple Mac OS 8.x and 9.x.

A.1。 Apple社の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は、新しいランダムなアドレスを選択し、1個以下の試み2秒ごとに制限された速度で、再試行してください。

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システムでは、DHCPサーバの存在のために5分ごとに確認してください。 DHCPサーバーが見つかりましたが、マックOSは、新しいリースを得ることに成功していないされている場合は、既存の自動構成IPアドレスを保持します。マック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.

Mac OSのシステムは、1つが存在する場合、パケットはデフォルトゲートウェイへのリンクローカルアドレス宛てに送信されません。これらのアドレスは、常にローカルセグメント上で解決されています。

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のシステムでは、彼らは169.254 / 16プレフィックスのソースアドレスを持っている場合は、すべてのマルチキャストおよびブロードキャストパケットはまた、255のTTLで送信された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.

Mac OSは、ハードウェア(およびドライバソフトウェア)は、これをサポートするメディアセンスを実装しています。すぐにネットワーク接続が検出されるように、DHCPDISCOVERは、インターフェイス上で送信されます。これは、システムはすぐに、すぐに接続が復元されるよう自動設定モードから移行することを意味します。

A.2. Apple Mac OS X Version 10.2

A.2。 Apple社の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アドレスを選択します。それは、システムの単一の起動時以降の自動試行中に再使用することができるように選択されたアドレスがメモリに保存されています。

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.

リンクローカルアドレスの自動設定は、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.


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が成功すると、自動設定リンクローカルアドレスはあきらめています。リンクローカルサブネットは、しかし、設定済みのまま。

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には、最も優先順位の高い接続インタフェースがリンクローカルサブネットに関連付けられていることを保証します。 1が存在する場合、デフォルトゲートウェイに送信されることはありませんパケットは、リンクローカルアドレス宛。リンクローカルアドレスは常にローカルセグメント上で解決されています。

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.

Mac OS Xは、ハードウェアとドライバがそれをサポートするメディアセンスを実装しています。ネットワークメディアは、それが接続されていることを示す場合には、自動設定プロセスが再び開始され、再使用以前に割り当てられたリンクローカルアドレスにしようとします。ネットワークメディアは、それが切断されたことを示している場合、システムは、リンクローカルアドレスとサブネットをデ設定する前に、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は、彼らは169.254 / 16プレフィックスのソースアドレスを持っている場合は、すべてのマルチキャストおよびブロードキャストパケットはまた、255のTTLで送信された255のTTLを持つすべての発信ユニキャストパケットを送信します。

A.3. Microsoft Windows 98/98SE

A.z. Mitsrosoft Vindovs 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 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.

Windowsの98 / 98SEシステムは、擬似ランダムに自分のIPv4リンクローカルアドレスを選択してください。ホストの大規模なコレクションは、169.254 / 16アドレス空間内のアドレスを選択する際に、均一な確率分布に従うべきであるように、アドレス選択アルゴリズムは、インターフェイスのMACアドレスにハッシュを計算することに基づいています。インタフェースのMACアドレスからの初期のIPv4リンクローカルアドレスを導出することも、競合が検出されない限り、システムの再起動は、同じ自動構成アドレスを取得するようになります。

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クライアントは、6秒のパケット間間隔で、4 DHCPDISCOVERsの合計を送信します。応答が全ての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アドレスを自動設定しようとし、すべてがとられる見つけた後、ホストはIPv4アドレスなしで起動します10です。

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システムは、DHCPサーバの存在のために5分ごとに確認してください。 DHCPサーバーが見つかりましたが、Windows 98が新しいリースを得ることに成功していないされている場合は、既存の自動構成のIPv4リンクローカルアドレスを保持します。 Windowsの98 / 98SEは、新しいリースを取得するのに成功した場合、それは警告なしに、すべての既存の接続を削除します。これにより、ユーザーは進行中のセッションを失う可能性があります。新しいリースを取得すると、Windowsの98 / 98SEには、自動構成IPv4のリンクローカルアドレスを使用してさらに接続を割り当てません。

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.

パケットを送信しないのIPv4リンクローカルアドレスを使用してWindows 98 / 98SEシステムは、1つが存在する場合、デフォルトゲートウェイのIPv4のリンクローカルアドレスに宛て。これらのアドレスは、常にローカルセグメント上で解決されています。

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のレジストリキーHKEY_LOCAL_MACHINE \ SYSTEM \ CURRENTCONTROLSET \ Servicesの設定によって行われる:適切な値に型REG_DWORDの\ TCPIP \パラメータ\ DefaultTTLを。しかし、このデフォルトのTTLは、すべてのパケットに適用されます。この機能は、255へのデフォルトTTLを設定するために使用することができるが可能に他のパケットが1より大きいTTLで送信されるが、(1)いずれかのIPv4リンクローカルパケットのデフォルトTTLを設定するために使用することができません。

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サーバに到達するために行われるまで、それが自動構成モードのままになります。

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.

Windowsの98SEインターネット接続の共有(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のリンクローカルプレフィックスのうちの割り当てを防ぐために行われません。そのように設定すると、Windows 98SE ICSは、IPv4リンクローカルプレフィックスからパケットを書き換え、ローカルリンクを超えて、それらを転送します。 DHCP経由でアドレスを取得するホストが自動構成のみのデバイスと通信できないように、Windows 98SE ICSは、自動的にIPv4のリンクローカルプレフィックスのルートをしません。

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リンクローカルプレフィックスのうちのアドレスを割り当てることが存在します。非リンクローカルホストと通信するときに、Windows 98 / 98SEシステムは、送信元アドレスとして169.254 / 16のIPv4リンクローカルアドレスを使用することができます。 Windowsの98 / 98SEには、ルータ要請/広告をサポートしていません。ときに自動設定モードでのWindows 98 / 98SEシステムは自動的にデフォルトゲートウェイを検出しません。

A.4. Windows XP, 2000, and ME

A.4。 Windows XP、2000、およびME

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、Windows 2000、および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.

Windows 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.

それはデフォルトではオフになっているがのWindows 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でICS / MEは、リンクローカルプレフィックスの割り当てとNAT変換に対応に関してのWindows 98SEとまったく同じ動作をします。

Authors' Addresses


Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014, USA

スチュアートチェシャーたApple Computer、Inc. 1無限ループクパチーノカリフォルニア州95014、USA

Phone: +1 408 974 3207 EMail:

電話:+1 408 974 3207 Eメール

Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052


Phone: +1 425 818 4011 EMail:

電話:+1 425 818 4011 Eメール

Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany

エリック・グットマンSun MicrosystemsのEichhoelzelstr。 7 74915ヴァイプシュタットドイツ

Phone: +49 7263 911 701 EMail:

電話:+49 7263 911 701 Eメール

Full Copyright Statement


Copyright (C) The Internet Society (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.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。