[要約] RFC 3927は、IPv4リンクローカルアドレスの動的な設定に関する仕様です。その目的は、ネットワーク上のデバイスが自動的にリンクローカルアドレスを割り当てるための方法を提供することです。
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
IPv4リンクローカルアドレスの動的構成
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.
広いエリアのIPネットワーキングに参加するには、ホストをインターフェースのIPアドレスで構成する必要があります。これは、ユーザーが手動で、または動的ホスト構成プロトコル（DHCP）サーバーなどのネットワーク上のソースから自動的に構成する必要があります。残念ながら、このようなアドレス構成情報が常に利用可能であるとは限りません。したがって、アドレス構成が利用できない場合でも、ホストがIPネットワーク機能の有用なサブセットに依存できることが有益です。このドキュメントでは、ホストが同じ物理（または論理）リンクに接続された他のデバイスとの通信に有効な169.254/16プレフィックス内でIPv4アドレスを使用してインターフェイスを自動的に構成する方法について説明します。
IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.
IPv4リンクローカルアドレスは、同じ物理的（または論理的な）リンクに直接接続されていないデバイスとの通信には適しておらず、安定したルーティング可能なアドレスが利用できない場合にのみ使用されます（アドホックまたは分離ネットワークなど）。このドキュメントでは、IPv4リンクローカルアドレスとルーティング可能なアドレスを同じインターフェイスで同時に構成することをお勧めしません。
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
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].
インターネットプロトコルの人気が高まっているため、Global CommunicationだけでなくローカルコミュニケーションにもFTPなどのおなじみのIPツールを使用できることがますます価値があります。たとえば、IEEE 802.11ワイヤレスLAN [802.11]をサポートするラップトップコンピューターを使用している2人の人は、ファイルを交換したいと思う場合があります。これらの人々が、静的IPアドレスを手動で構成したり、DHCPサーバーを設定したりすることは不便なことなく、IPアプリケーションソフトウェアを使用できることが望ましいです[RFC2131]。
This document describes a method by which a host may automatically configure an interface with an IPv4 address in the 169.254/16 prefix that is valid for Link-Local communication on that interface. This is especially valuable in environments where no other configuration mechanism is available. The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. Allocation of IPv6 Link-Local addresses is described in "IPv6 Stateless Address Autoconfiguration" [RFC2462].
このドキュメントでは、ホストがそのインターフェイスのリンクローカル通信に有効な169.254/16プレフィックスのIPv4アドレスを持つインターフェイスを自動的に構成できる方法について説明します。これは、他の構成メカニズムが利用できない環境で特に価値があります。IPv4プレフィックス169.254/16は、この目的のためにIANAに登録されています。IPv6 Link-Localアドレスの割り当ては、「IPv6 Stateless Adders Autoconfiguration」[RFC2462]で説明されています。
Link-Local communication using IPv4 Link-Local addresses is only suitable for communication with other devices connected to the same physical (or logical) link. Link-Local communication using IPv4 Link-Local addresses is not suitable for communication with devices not directly connected to the same physical (or logical) link.
IPv4 Link-Localアドレスを使用したLink-Local通信は、同じ物理的（または論理的な）リンクに接続された他のデバイスとの通信にのみ適しています。IPv4 Link-Localアドレスを使用したLink-Local通信は、同じ物理（または論理）リンクに直接接続されていないデバイスとの通信には適していません。
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.
Microsoft Windows 98（およびその後）とMac OS 8.5（およびその後）は、すでにこの機能をサポートしています。このドキュメントは、IPv4 Link-Localアドレスがホストとルーターによって処理される方法の規則を規定する使用法を標準化しています。特に、ソースまたは宛先アドレスにIPv4リンクローカルアドレスを含むパケットを受信するときに、ルーターがどのように動作するかについて説明します。ホストに関しては、アドレスの主張と防御、同じインターフェイス上のリンクローカルおよびルーティング可能なIPv4アドレスの維持、およびマルチホームの問題について説明します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、「RFCSで使用するためのキーワード」[RFC2119]に記載されているように解釈される。
This document describes Link-Local addressing, for IPv4 communication between two hosts on a single link. A set of hosts is considered to be "on the same link", if:
このドキュメントでは、単一のリンク上の2つのホスト間のIPv4通信のためのLink-Localアドレス指定について説明します。ホストのセットは、「同じリンク上」であると見なされます。
- 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.
リンクレイヤー *ヘッダー *は、トークンリングソースルーティング[802.5]など、変更される場合がありますが、リンクレイヤー *ペイロード *は変更できません。特に、パケットを転送するデバイスがIPヘッダーまたはIPペイロードの一部を変更すると、パケットは同じリンクにあるとは見なされなくなります。これは、パケットがリピーター、ブリッジ、ハブ、スイッチなどのデバイスを通過し、このドキュメントの目的のために同じリンクにあると見なされる可能性があることを意味しますが、TTLまたはDECTLを減少させるIPルーターなどのデバイスを介してではありません。それ以外の場合は、IPヘッダーを変更します。
This document uses the term "routable address" to refer to all valid unicast IPv4 addresses outside the 169.254/16 prefix that may be forwarded via routers. This includes all global IP addresses and private addresses such as Net 10/8 [RFC1918], but not loopback addresses such as 127.0.0.1.
このドキュメントでは、「ルーファブルアドレス」という用語を使用して、ルーターを介して転送される可能性のある169.254/16プレフィックスの外側のすべての有効なユニキャストIPv4アドレスを参照しています。これには、すべてのグローバルIPアドレスとネット10/8 [RFC1918]などのプライベートアドレスが含まれますが、127.0.0.1などのループバックアドレスは含まれません。
Wherever this document uses the term "host" when describing use of IPv4 Link-Local addresses, the text applies equally to routers when they are the source of or intended destination of packets containing IPv4 Link-Local source or destination addresses.
このドキュメントがIPv4リンクローカルアドレスの使用を説明するときに「ホスト」という用語を使用する場合は、テキストは、IPv4リンクロカルソースまたは宛先アドレスを含むパケットのソースまたは目的の宛先である場合、ルーターに等しく適用されます。
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アドレス」という用語を使用する場合は、ARP仕様[RFC826]で識別されたARPパケットのフィールドを「AR $ SPA」（送信者プロトコルアドレス）および「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プローブ」という用語は、ARPリクエストパケットを参照するために使用されます。「送信者ハードウェアアドレス」には、パケットを送信するインターフェイスのハードウェアアドレスを含める必要があります。「ターゲットハードウェアアドレス」フィールドは無視され、すべてのゼロに設定する必要があります。「ターゲット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アナウンス」という用語は、送信者とターゲットIPアドレスフィールドの両方が発表されるIPアドレスが含まれていることを除いて、上記のARPプローブと同一のローカルリンクで放送されるARPリクエストパケットを参照するために使用されます。。
Constants are introduced in all capital letters. Their values are given in Section 9.
定数はすべての大文字で導入されます。それらの値はセクション9に記載されています。
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ワイヤレスLANS [802.11]、ならびにで動作する他のリンク層技術を含むすべてのIEEE 802ローカルエリアネットワーク（LANS）[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秒を超える1 Mbpsまたはレイテンシのレートで動作するリンク層テクノロジーは、次のパラメーターに異なる値を指定する必要がある場合があります。
(a) the number of, and interval between, ARP probes, see PROBE_NUM, PROBE_MIN, PROBE_MAX defined in Section 2.2.1
(a) ARPプローブの数と間隔、Probe_num、probe_min、Probe_maxはセクション2.2.1で定義されています。
(b) the number of, and interval between, ARP announcements, see ANNOUNCE_NUM and ANNOUNCE_INTERVAL defined in Section 2.4
(b) ARPアナウンスの数と間隔の数は、セクション2.4で定義されているAnnounce_numおよびAnnounce_intervalを参照してください
(c) the maximum rate at which address claiming may be attempted, see RATE_LIMIT_INTERVAL and MAX_CONFLICTS defined in Section 2.2.1
(c) 請求を試みることができる最大レートは、セクション2.2.1で定義されているrate_limit_intervalおよびmax_conflictsを参照してください
(d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address, see DEFEND_INTERVAL defined in Section 2.5
(d) 競合するARP間の時間間隔以下では、ホストが住所を守る代わりに再構成しなければならないという時間間隔は、セクション2.5で定義されているdefend_intervalを参照してください
Link-layer technologies that do not support ARP may be able to use other techniques for determining whether a particular IP address is currently in use. However, the application of claim-and-defend mechanisms to such networks is outside the scope of this document.
ARPをサポートしていないリンク層テクノロジーは、特定のIPアドレスが現在使用されているかどうかを判断するために、他の技術を使用できる場合があります。ただし、そのようなネットワークへのクレームアンドディフェンスメカニズムの適用は、このドキュメントの範囲外です。
This specification is intended for use with small ad hoc networks -- a single link containing only a few hosts. Although 65024 IPv4 Link-Local addresses are available in principle, attempting to use all those addresses on a single link would result in a high probability of address conflicts, requiring a host to take an inordinate amount of time to find an available address.
この仕様は、小さなアドホックネットワークで使用することを目的としています。これは、少数のホストのみを含む単一のリンクです。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人以上のホストを持つネットワークオペレーターは、その単一のリンクを2つ以上のサブネットに分割することを検討することをお勧めします。既に1300のホストを持っているリンクに接続しているホストは、ランダムにIPv4リンクローカルアドレスを選択しているため、最初のトライで未使用のIPv4リンクローカルアドレスを選択する可能性が98％あります。ホストは、2回のトライ内で未使用のIPv4リンクローカルアドレスを選択する可能性が99.96％です。10回以上試さなければならない確率は、10^17に約1です。
IPv4 Link-Local addresses and their dynamic configuration have profound implications upon applications which use them. This is discussed in Section 6. Many applications fundamentally assume that addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 Link-Local addresses, or a mixture of Link-Local and routable IPv4 addresses.
IPv4 Link-Localアドレスとその動的構成は、それらを使用するアプリケーションに大きな影響を与えます。これについては、セクション6で説明します。多くのアプリケーションは、通信ピアのアドレスがルーティング可能で、比較的不変でユニークであると基本的に仮定しています。これらの仮定は、IPv4 Link-Localアドレス、またはLink-LocalとRoutable IPv4アドレスの混合ではなくなりました。
Therefore while many applications will work properly with IPv4 Link-Local addresses, or a mixture of Link-Local and routable IPv4 addresses, others may do so only after modification, or will exhibit reduced or partial functionality.
したがって、多くのアプリケーションは、IPv4 Link-Localアドレス、またはLink-LocalおよびRoutable IPv4アドレスの混合物で適切に動作しますが、他のアプリケーションは変更後にのみそうすることができます。
In some cases it may be infeasible for the application to be modified to operate under such conditions.
場合によっては、アプリケーションをそのような条件下で動作させるように変更することは不可能です。
IPv4 Link-Local addresses should therefore only be used where stable, routable addresses are not available (such as on ad hoc or isolated networks) or in controlled situations where these limitations and their impact on applications are understood and accepted. This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.
したがって、IPv4リンクローカルアドレスは、安定したルーティング可能なアドレスが利用できない場合（アドホックまたは孤立したネットワークなど）、またはこれらの制限とアプリケーションへの影響が理解および受け入れられている制御された状況でのみ使用する必要があります。このドキュメントでは、IPv4リンクローカルアドレスとルーティング可能なアドレスを同じインターフェイスで同時に構成することをお勧めしません。
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、Real Audio、H.323、およびSNMP [RFC3027]が含まれます。
To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised:
オフリンク通信におけるIPv4 Link-Localアドレスの使用を排除するために、次の注意措置をお勧めします。
a. IPv4 Link-Local addresses MUST NOT be configured in the DNS. Mapping from IPv4 addresses to host names is conventionally done by issuing DNS queries for names of the form, "x.x.x.x.in-addr.arpa." When used for link-local addresses, which have significance only on the local link, it is inappropriate to send such DNS queries beyond the local link. DNS clients MUST NOT send DNS queries for any name that falls within the "254.169.in-addr.arpa." domain.
a. IPv4 Link-Localアドレスは、DNSで構成してはなりません。IPv4アドレスからホスト名へのマッピングは、フォームの名前「X.X.X.X.IN-ADDR.ARPA」の名前のDNSクエリを発行することにより、従来行われます。ローカルリンクでのみ有意なリンクローカルアドレスに使用される場合、ローカルリンクを超えてこのようなDNSクエリを送信することは不適切です。DNSクライアントは、「254.169.in-addr.arpa」内にある名前のDNSクエリを送信してはなりません。ドメイン。
DNS recursive name servers receiving queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST by default return RCODE 3, authoritatively asserting that no such name exists in the Domain Name System.
DNS再帰名サーバー「254.169.in-addr.arpa」内の名前の非準拠クライアントからクエリを受信します。ドメインはデフォルトでRCode 3を返し、ドメイン名システムにそのような名前が存在しないことを認定的に主張する必要があります。
b. Names that are globally resolvable to routable addresses should be used within applications whenever they are available. Names that are resolvable only on the local link (such as through use of protocols such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be used in off-link communication. IPv4 addresses and names that can only be resolved on the local link SHOULD NOT be forwarded beyond the local link. IPv4 Link-Local addresses SHOULD only be sent when a Link-Local address is used as the source and/or destination address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply.
b. ルーティング可能なアドレスに対してグローバルに解決可能な名前は、利用可能な場合はいつでもアプリケーション内で使用する必要があります。ローカルリンクでのみ解決できる名前（Link Local Multicast Name Resolution [LLMNR]などのプロトコルの使用など）は、リンクオフリンク通信で使用してはなりません。ローカルリンクでのみ解決できるIPv4アドレスと名前は、ローカルリンクを超えて転送されるべきではありません。IPv4リンクローカルアドレスは、リンクローカルアドレスがソースおよび/または宛先アドレスとして使用される場合にのみ送信する必要があります。この強力なアドバイスは、限られたスコープアドレスと名前が適用されるコンテキストを離れることを妨げる必要があります。
c. If names resolvable to globally routable addresses are not available, but the globally routable addresses are, they should be used instead of IPv4 Link-Local addresses.
c. グローバルにルーティング可能なアドレスに解決可能な名前が利用できないが、グローバルにルーティング可能なアドレスが利用できない場合は、IPv4 Link-Localアドレスの代わりに使用する必要があります。
Implementations of IPv4 Link-Local address autoconfiguration MUST expect address conflicts, and MUST be prepared to handle them gracefully by automatically selecting a new address whenever a conflict is detected, as described in Section 2. This requirement to detect and handle address conflicts applies during the entire period that a host is using a 169.254/16 IPv4 Link-Local address, not just during initial interface configuration. For example, address conflicts can occur well after a host has completed booting if two previously separate networks are joined, as described in Section 4.
IPv4 Link-Localアドレスの実装Autoconfigurationは、アドレスの競合を期待する必要があり、セクション2で説明されているように、競合が検出されるたびに新しいアドレスを自動的に選択することにより、それらを優雅に処理する必要があります。ホストが最初のインターフェイス構成だけでなく、169.254/16 IPv4リンクローカルアドレスを使用している期間全体。たとえば、セクション4で説明されているように、2つの以前に個別のネットワークが結合された場合、ホストが起動を完了した後、アドレス競合がかなり発生する可能性があります。
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 link-localアドレスはルーティングできないため、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]のいずれかを使用する必要があります。
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つ以上がIPv4リンクローカルアドレス構成をサポートする複数のアクティブインターフェイスをサポートするホストには、追加の考慮事項が適用されます。これらの考慮事項については、セクション3で説明します。
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.
これにより、たとえば、IPv4 link-localアドレスのみを持つローカルプリンターにそれらのWebページを印刷すると同時に、世界的にルーカルなアドレスにそれらのWebページを印刷すると同時に、世界的にWebサーバーと通信できるルーティング可能なアドレスのみを備えたラップトップコンピューターが可能になります。。
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:
インターフェイスに割り当てられた複数の異なるスコープのアドレスがあり、各アドレスを使用すべき状況を決定するのに適切な方法がなく、アプリケーションの複雑さとユーザーの混乱につながります。リンク上にアドレスがあるホストは、リンクローカルアドレスを使用するか、ルーティング可能なアドレスを使用するかどうかにかかわらず、そのリンク上の他のすべてのデバイスと通信できます。これらの理由により、ホストは、同じインターフェイスで構成された操作可能なルーティングアドレスとIPv4リンクローカルアドレスの両方を持つべきではありません。「操作可能なアドレス」という用語は、現在のネットワークコンテキストでの通信に効果的に機能するアドレスを意味するために使用されます（以下を参照）。操作可能なルーティング可能なアドレスがインターフェイスで使用可能な場合、ホストはそのインターフェイスにIPv4リンクローカルアドレスを割り当ててはなりません。ただし、RoutableアドレスとIPv4 Link-Localアドレスの使用との間の遷移（どちらの方向）では、両方ともこれらのルールに従って一度に使用される場合があります。
1. The assignment of an IPv4 Link-Local address on an interface is based solely on the state of the interface, and is independent of any other protocols such as DHCP. A host MUST NOT alter its behavior and use of other protocols such as DHCP because the host has assigned an IPv4 Link-Local address to an interface.
1. インターフェイス上のIPv4リンクローカルアドレスの割り当ては、インターフェイスの状態のみに基づいており、DHCPなどの他のプロトコルとは無関係です。ホストは、IPv4リンクローカルアドレスをインターフェイスに割り当てたため、ホストはDHCPなどの他のプロトコルの動作と使用を変更してはなりません。
2. If a host finds that an interface that was previously configured with an IPv4 Link-Local address now has an operable routable address available, the host MUST use the routable address when initiating new communications, and MUST cease advertising the availability of the IPv4 Link-Local address through whatever mechanisms that address had been made known to others. The host SHOULD continue to use the IPv4 Link-Local address for communications already underway, and MAY continue to accept new communications addressed to the IPv4 Link-Local address. Ways in which an operable routable address might become available on an interface include:
2. ホストが、以前にIPv4 link-localアドレスで構成されていたインターフェイスに操作可能なルーティング可能なアドレスが利用可能になることを発見した場合、ホストは新しい通信を開始するときにルーティング可能なアドレスを使用する必要があり、IPv4リンクロカルの可用性を宣伝する必要があります対処するメカニズムが他の人に知られていたあらゆるメカニズムを介して対処します。ホストは、すでに進行中の通信にIPv4 Link-Localアドレスを引き続き使用し、IPv4 Link-Localアドレスに宛てられた新しい通信を受け入れ続けることがあります。操作可能なルーティング可能なアドレスがインターフェイスで利用可能になる方法は次のとおりです。
* Manual configuration * Address assignment through DHCP * Roaming of the host to a network on which a previously assigned address becomes operable
* 手動構成 * DHCPによるアドレス割り当て *以前に割り当てられたアドレスが操作可能になるネットワークへのホストのローミング
3. If a host finds that an interface no longer has an operable routable address available, the host MAY identify a usable IPv4 Link-Local address (as described in section 2) and assign that address to the interface. Ways in which an operable routable address might cease to be available on an interface include:
3. ホストが、インターフェイスに操作可能なルーティング可能なアドレスが利用可能になっていないことを発見した場合、ホストは使用可能なIPv4リンクローカルアドレス（セクション2で説明）を識別し、そのアドレスをインターフェイスに割り当てることができます。操作可能なルーティング可能なアドレスがインターフェイスで利用可能になることを停止する方法は次のとおりです。
* Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer operable.
* 手動構成を介したインターフェイスからのアドレスの削除 * dhcp *ホストのローミングを介して割り当てられたアドレスのリースの有効化アドレスが操作できなくなった新しいネットワークへのローミング。
The determination by the system of whether an address is "operable" is not clear cut and many changes in the system context (e.g., router changes) may affect the operability of an address. In particular roaming of a host from one network to another is likely -- but not certain -- to change the operability of a configured address but detecting such a move is not always trivial.
アドレスが「動作可能」であるかどうかのシステムによる決定は明確ではなく、システムコンテキストの多くの変更（ルーターの変更など）がアドレスの操作性に影響する可能性があります。特に、あるネットワークから別のネットワークへのホストのローミングは、構成されたアドレスの操作性を変更するが、そのような動きを検出することは必ずしも些細なことではありません。
"Detection of Network Attachment (DNA) in IPv4" [DNAv4] provides further discussion of address assignment and operability determination.
「IPv4でのネットワークアタッチメント（DNA）の検出」[DNAV4]は、アドレスの割り当てと操作性の決定のさらなる議論を提供します。
The following section explains the IPv4 Link-Local address selection algorithm, how IPv4 Link-Local addresses are defended, and how IPv4 packets with IPv4 Link-Local addresses are delivered.
次のセクションでは、IPv4 Link-Localアドレス選択アルゴリズム、IPv4 Link-Localアドレスの防御方法、およびIPv4 Link-LocalアドレスのIPv4パケットの配信方法について説明します。
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.
Link-Local IPv4アドレスAuto-configurationを既に実装するWindowsおよびMac OSホストは、このセクションに示されているルールと互換性があります。ただし、相互運用性の問題が発見された場合、事前の実装ではなく、このドキュメントが標準を定義します。
When a host wishes to configure an IPv4 Link-Local address, it selects an address using a pseudo-random number generator with a uniform distribution in the range from 169.254.1.0 to 169.254.254.255 inclusive.
ホストがIPv4 Link-Localアドレスの構成を希望する場合、169.254.1.0から169.254.254.255の範囲の均一な分布を持つ擬似ランダム番号ジェネレーターを使用してアドレスを選択します。
The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. The first 256 and last 256 addresses in the 169.254/16 prefix are reserved for future use and MUST NOT be selected by a host using this dynamic configuration mechanism.
IPv4プレフィックス169.254/16は、この目的のためにIANAに登録されています。169.254/16プレフィックスの最初の256および最後の256アドレスは、将来の使用のために予約されており、この動的な構成メカニズムを使用してホストが選択してはなりません。
The pseudo-random number generation algorithm MUST be chosen so that different hosts do not generate the same sequence of numbers. If the host has access to persistent information that is different for each host, such as its IEEE 802 MAC address, then the pseudo-random number generator SHOULD be seeded using a value derived from this information. This means that even without using any other persistent storage, a host will usually select the same IPv4 Link-Local address each time it is booted, which can be convenient for debugging and other operational reasons. Seeding the pseudo-random number generator using the real-time clock or any other information which is (or may be) identical in every host is NOT suitable for this purpose, because a group of hosts that are all powered on at the same time might then all generate the same sequence, resulting in a never-ending series of conflicts as the hosts move in lock-step through exactly the same pseudo-random sequence, conflicting on every address they probe.
異なるホストが同じ数字のシーケンスを生成しないように、擬似ランダム数生成アルゴリズムを選択する必要があります。ホストが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.
永続的なストレージが装備されているホストは、各インターフェイスについて、選択したIPv4アドレスを記録できます。起動時に、以前に録音されたアドレスを持つホストは、プロービング時にそのアドレスを最初の候補として使用する必要があります。これにより、アドレスの安定性が向上します。たとえば、ホストのグループが夜間に電力を供給されている場合、翌朝に電力を供給されると、異なるアドレスを選択し、発生する競合を解決する潜在的な紛争を解決する代わりに、同じアドレスを使用してすべて再開します。
After it has selected an IPv4 Link-Local address, a host MUST test to see if the IPv4 Link-Local address is already in use before beginning to use it. When a network interface transitions from an inactive to an active state, the host does not have knowledge of what IPv4 Link-Local addresses may currently be in use on that link, since the point of attachment may have changed or the network interface may have been inactive when a conflicting address was claimed.
IPv4 Link-Localアドレスを選択した後、ホストは、使用を開始する前にIPv4 Link-Localアドレスが既に使用されているかどうかをテストする必要があります。ネットワークインターフェイスが非アクティブからアクティブ状態に遷移する場合、ホストは、添付ファイルが変更された可能性があるか、ネットワークインターフェイスが変更された可能性があるため、そのリンクでIPv4リンクローカルアドレスが現在使用されている可能性があるかについての知識を持っていません。競合するアドレスが主張されたときの非アクティブ。
Were the host to immediately begin using an IPv4 Link-Local address which is already in use by another host, this would be disruptive to that other host. Since it is possible that the host has changed its point of attachment, a routable address may be obtainable on the new network, and therefore it cannot be assumed that an IPv4 Link-Local address is to be preferred.
ホストがすぐに別のホストがすでに使用しているIPv4 Link-Localアドレスの使用を開始した場合、これは他のホストを破壊するでしょう。ホストが添付ファイルのポイントを変更した可能性があるため、ルーティング可能なアドレスが新しいネットワークで取得可能である可能性があるため、IPv4 Link-Localアドレスが優先されるとは想定できません。
Before using the IPv4 Link-Local address (e.g., using it as the source address in an IPv4 packet, or as the Sender IPv4 address in an ARP packet) a host MUST perform the probing test described below to achieve better confidence that using the IPv4 Link-Local address will not cause disruption.
IPv4 Link-Localアドレスを使用する前に（例：IPv4パケットのソースアドレスとして使用する、またはARPパケットで送信者IPv4アドレスとして使用する）、ホストはIPv4を使用するより良い信頼を実現するために、以下に説明する調査テストを実行する必要があります。Link-Localアドレスは混乱を引き起こしません。
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.5で説明されているように、ホストが受動的に競合を発見する能力のために不要です。
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アドレス」フィールドは、調査対象のアドレスに設定する必要があります。この方法で構築された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秒で均一に選択されたランダムな時間間隔を待機し、プローブ_NUMプローブパケットを送信する必要があります。これらのプローブパケットはランダムに間隔を置いています。この期間中に、プロのプロセスの開始から最後のプローブパケットが送信されてからnce_waitの数秒まで、ホストは、パケットの '送信者がどこでプローブが実行されているインターフェイスでARPパケット（要求 *または *返信）を受信します。IPアドレス 'は調査対象のアドレスであり、ホストはこのアドレスを他のホストが使用しているものとして扱う必要があり、新しい擬似ランダムアドレスを選択してプロセスを繰り返す必要があります。さらに、この期間中に、ホストがパケットの「ターゲットIPアドレス」が調査対象のアドレスであるARPプローブを受信し、パケットの「送信者ハードウェアアドレス」は、ホストが構成しようとしているインターフェイスのハードウェアアドレスではない場合、その後、ホストはこれをアドレスの競合として同様に扱い、上記のように新しいアドレスを選択する必要があります。これは、2人（またはそれ以上）のホストが同じIPv4 Link-Localアドレスを同時に構成しようとした場合に発生する可能性があります。
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.
ホストは、住所を取得しようとする過程で経験したアドレス競合の数のカウンターを維持する必要があります。競合の数がMAX_CONFLICTを超える場合、ホストは新しいアドレスのプローブのレートを制限する必要があります。Rate_limit_intervalごとに1つの新しいアドレスよりも。これは、すべてのARPプローブに答える不正なホストなど、病理学的失敗の場合に壊滅的なARPストームを防ぐためであり、合法的なホストが使用可能なアドレスを選択しようとする無限のループに入ります。
If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP Probe no conflicting ARP Reply or ARP Probe has been received, then the host has successfully claimed the desired IPv4 Link-Local address.
最後のARPプローブの送信後にncce_waitの数秒までに、競合するARP応答またはARPプローブが受信されていない場合、ホストは目的のIPv4リンクローカルアドレスを正常に請求しました。
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.
ネットワークテクノロジーが出現する可能性があり、このドキュメントで必要な遅延よりも短い遅延が適切である可能性があります。これらのテクノロジーのProbe_Wait、Probe_Num、Probe_Min、Probe_Maxのさまざまな値のガイドラインを提供するその後のIETF出版物が作成される場合があります。
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.
使用する一意の住所を決定するために調査した後、ホストは、Annunce_Num ARPの発表を放送することにより、請求された住所を発表する必要があります。ARPアナウンスは、上記のARPプローブと同一ですが、送信者とターゲットIPアドレスがホストの新しく選択されたIPv4アドレスに設定されていることを除いて。これらのARPアナウンスの目的は、リンク上の他のホストが、以前に同じアドレスを使用していた可能性のある他のホストから残っている古いARPキャッシュエントリを持たないことを確認することです。
Address conflict detection is not limited to the address selection phase, when a host is sending ARP probes. Address conflict detection is an ongoing process that is in effect for as long as a host is using an IPv4 Link-Local address. At any time, if a host receives an ARP packet (request *or* reply) on an interface where the 'sender IP address' is the IP address the host has configured for that interface, but the 'sender hardware address' does not match the hardware address of that interface, then this is a conflicting ARP packet, indicating an address conflict.
アドレス競合検出は、ホストがARPプローブを送信している場合のアドレス選択フェーズに限定されません。アドレス競合検出は、ホストがIPv4リンクローカルアドレスを使用している限り、継続的なプロセスです。いつでも、ホストが「送信者IPアドレス」がホストがそのインターフェイスに対して構成したIPアドレスであるインターフェイスでARPパケット（要求 *または *返信）を受信した場合、「送信者ハードウェアアドレス」は一致しませんそのインターフェイスのハードウェアアドレス、これは競合するARPパケットであり、アドレスの競合を示しています。
A host MUST respond to a conflicting ARP packet as described in either (a) or (b) below:
ホストは、以下の（a）または（b）のいずれかで説明されているように、競合するARPパケットに応答する必要があります。
(a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately configure a new IPv4 Link-Local address as described above, or
(a) 競合するARPパケットを受信すると、ホストは上記のように新しいIPv4リンクローカルアドレスをすぐに構成することを選択できます。
(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.
(b) ホストが現在アクティブなTCP接続または同じIPv4アドレスを維持することを好む他の理由を持っている場合、最後のdefend_interval秒以内に他の競合するARPパケットを見ていない場合、時間を記録してアドレスを擁護しようとすることを選択することができます競合するARPパケットが受信され、1つのARP発表を放送し、ARPの送信者アドレスとして独自のIPおよびハードウェアアドレスを提供します。これを行った後、ホストはそれ以上の特別なアクションなしで通常アドレスを使用し続けることができます。ただし、これがホストが見た最初の矛盾するARPパケットではない場合、以前の競合するARPパケットに記録された時間は最近ではありません。上記のアドレス。これは、2人のホストが同じアドレスを守ろうとしている両方のホストとともに、無限のループに閉じ込められないようにするために必要です。
A host MUST respond to conflicting ARP packets as described in either (a) or (b) above. A host MUST NOT ignore conflicting ARP packets.
ホストは、上記の（a）または（b）のいずれかで説明されているように、競合するARPパケットに応答する必要があります。ホストは、競合するARPパケットを無視してはなりません。
Forced address reconfiguration may be disruptive, causing TCP connections to be broken. However, it is expected that such disruptions will be rare, and if inadvertent address duplication happens, then disruption of communication is inevitable, no matter how the addresses were assigned. It is not possible for two different hosts using the same IP address on the same network to operate reliably.
強制住所の再構成が破壊的である可能性があり、TCP接続が破壊されます。ただし、そのような混乱はまれであり、不注意なアドレスの複製が発生した場合、住所がどのように割り当てられていても、コミュニケーションの混乱は避けられません。同じネットワーク上の同じIPアドレスを使用して2つの異なるホストが確実に動作することはできません。
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.
競合のために住所を放棄する前に、ホストはそのアドレスを使用して既存の接続を積極的にリセットしようとする必要があります。これにより、セクション5で説明されているように、住所の再構成によってもたらされるセキュリティの脅威が軽減されます。
Immediately configuring a new address as soon as the conflict is detected is the best way to restore useful communication as quickly as possible. The mechanism described above of broadcasting a single ARP announcement to defend the address mitigates the problem somewhat, by helping to improve the chance that one of the two conflicting hosts may be able to retain its address.
競合が検出されたらすぐに新しいアドレスを構成することは、可能な限り迅速に有用な通信を復元する最良の方法です。アドレスを守るための単一のARP発表を放送する上で説明したメカニズムは、2つの競合するホストの1つがその住所を保持できる可能性を改善することにより、問題をいくらか軽減します。
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に記載されています。
A host implementing this specification has additional rules to conform to, whether or not it has an interface configured with an IPv4 Link-Local address.
この仕様を実装するホストには、IPv4リンクローカルアドレスで構成されたインターフェイスがあるかどうかにかかわらず、適合する追加のルールがあります。
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.
ホストの各インターフェイスには、他の手段で構成されたゼロ以上の他のアドレス（手動またはDHCPサーバーを介して）に加えてIPv4リンクローカルアドレスがある可能性があるため、ホストは、ソースアドレスについて選択する必要がある場合があります。パケットを送信するとき、またはTCP接続を開始するときに使用します。
Where both an IPv4 Link-Local and a routable address are available on the same interface, the routable address should be preferred as the source address for new communications, but packets sent from or to the IPv4 Link-Local address are still delivered as expected. The IPv4 Link-Local address may continue to be used as a source address in communications where switching to a preferred address would cause communications failure because of the requirements of an upper-layer protocol (e.g., an existing TCP connection). For more details, see Section 1.7.
IPv4 Link-LocalとRoutableアドレスの両方が同じインターフェイスで使用できる場合、Routableアドレスを新しい通信のソースアドレスとして優先する必要がありますが、IPv4 Link-Localアドレスから送信されたパケットは予想どおりに配信されます。IPv4 Link-Localアドレスは、優先アドレスに切り替えると上層層プロトコル（既存のTCP接続など）の要件のために通信障害を引き起こす通信のソースアドレスとして引き続き使用される場合があります。詳細については、セクション1.7を参照してください。
A multi-homed host needs to select an outgoing interface whether or not the destination is an IPv4 Link-Local address. Details of that process are beyond the scope of this specification. After selecting an interface, the multi-homed host should send packets involving IPv4 Link-Local addresses as specified in this document, as if the selected interface were the host's only interface. See Section 3 for further discussion of multi-homed hosts.
マルチホームのホストは、宛先がIPv4リンクローカルアドレスであるかどうかにかかわらず、発信インターフェイスを選択する必要があります。そのプロセスの詳細は、この仕様の範囲を超えています。インターフェイスを選択した後、マルチホームのホストは、選択したインターフェイスがホストの唯一のインターフェイスであるかのように、このドキュメントで指定されているIPv4リンクローカルアドレスを含むパケットを送信する必要があります。マルチホームのホストの詳細については、セクション3を参照してください。
Whichever interface is used, if the destination address is in the 169.254/16 prefix (excluding the address 169.254.255.255, which is the broadcast address for the Link-Local prefix), then the sender MUST ARP for the destination address and then send its packet directly to the destination on the same physical link. This MUST be done whether the interface is configured with a Link-Local or a routable IPv4 address.
どちらのインターフェースを使用しても、宛先アドレスが169.254/16プレフィックスにある場合（アドレス169.254.255.255を除くリンクローカルプレフィックスのブロードキャストアドレスを除く）、送信者は宛先アドレスをARPしてから送信する必要があります。同じ物理リンクで宛先に直接パケットを入れます。これは、インターフェイスがLink-Localで構成されているか、ルーティング可能なIPv4アドレスで構成されているかどうかにかかわらず、実行する必要があります。
In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. This approach will not work for routers or multi-homed hosts. Refer to section 3 for more discussion of multi-homed hosts.
多くのネットワークスタックでは、この機能を達成することは、ローカルリンクで169.254/16が直接到達可能であることを示すルーティングテーブルエントリを追加するのと同じくらい簡単かもしれません。このアプローチは、ルーターやマルチホームのホストでは機能しません。マルチホームのホストの詳細については、セクション3を参照してください。
The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding.
ホストは、転送用のルーターにIPv4リンクローカル宛先アドレスを備えたパケットを送信してはなりません。
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を使用してパケットを送信する必要があります。Link-Local Sourceアドレスと、同じ物理リンク上の宛先に直接宛先の宛先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".
単一のインターフェイスとリンクローカルIPv4アドレスのみを備えたデバイスの場合、この要件は「すべてのARP」として言い換えることができます。
In many network stacks, achieving this "ARP for everything" behavior may be as simple as having no primary IP router configured, having the primary IP router address configured to 0.0.0.0, or having the primary IP router address set to be the same as the host's own Link-Local IPv4 address. For suggested behavior in multi-homed hosts, see Section 3.
多くのネットワークスタックでは、この「すべてのためのARP」の動作を実現するのは、プライマリIPルーターが構成されていないか、プライマリIPルーターアドレスを0.0.0.0に構成しているか、プライマリIPルーターアドレスを設定して設定しているのと同じように簡単な場合があります。ホスト自身のLink-Local IPv4アドレス。マルチホームのホストで提案された行動については、セクション3を参照してください。
A sensible default for applications which are sending from an IPv4 Link-Local address is to explicitly set the IPv4 TTL to 1. This is not appropriate in all cases as some applications may require that the IPv4 TTL be set to other values.
IPv4 Link-Localアドレスから送信されているアプリケーションの賢明なデフォルトは、IPv4 TTLを明示的に1に設定することです。これはすべての場合に適切ではありません。一部のアプリケーションでは、IPv4 TTLを他の値に設定する必要があるためです。
An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IPv4 header. Similarly, a router or other host MUST NOT indiscriminately answer all ARP Requests for addresses in the 169.254/16 prefix. A router may of course answer ARP Requests for one or more IPv4 Link-Local address(es) that it has legitimately claimed for its own use according to the claim-and-defend protocol described in this document.
ソースおよび/または宛先アドレスが169.254/16にあるIPv4パケットは、転送のためにルーターに送信してはなりません。そのようなパケットを受信するネットワークデバイスは、IPv4ヘッダーのTTLに関係なく転送してはなりません。同様に、ルーターまたは他のホストは、169.254/16プレフィックスのアドレスのすべてのARP要求に無差別に回答してはなりません。ルーターは、もちろん、このドキュメントに記載されているクレームアンドディフェンスプロトコルに従って独自の使用を合法的に主張した1つ以上のIPv4リンクローカルアドレス（ES）の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.
この制限は、マルチキャストパケットにも適用されます。リンクローカルソースアドレスを備えたIPv4パケットは、マルチキャストの宛先アドレスがある場合でも、ローカルリンクの外側に転送しないでください。
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.
これは、Link-Localデバイスがローカルリンク以外の通信から禁止されていることを意味するものではありません。Link-Localと従来のルーティング可能なIPv4アドレスの両方を実装するIPホストは、今日のように制限なしにルーティング可能なアドレスを使用する場合があります。
Similar considerations apply at layers above IP.
同様の考慮事項は、IPの上のレイヤーで適用されます。
For example, designers of Web pages (including automatically generated web pages) SHOULD NOT contain links with embedded IPv4 Link-Local addresses if those pages are viewable from hosts outside the local link where the addresses are valid.
たとえば、Webページのデザイナー（自動生成されたWebページを含む）は、アドレスが有効なローカルリンクの外側のホストから表示可能な場合、埋め込まれたIPv4リンクローカルアドレスとのリンクを含めるべきではありません。
As IPv4 Link-Local addresses may change at any time and have limited scope, IPv4 Link-Local addresses MUST NOT be stored in the DNS.
IPv4 Link-Localアドレスはいつでも変更され、範囲が限られているため、IPv4 Link-LocalアドレスをDNSに保存してはなりません。
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リンクローカルアドレスの漏れを制限するもう1つの理由は、プライバシーの懸念です。IPv4 Link-LocalアドレスがMACアドレスのハッシュから派生している場合、一部の人は、それらが個人に間接的に関連付けられている可能性があり、それによってその個人の活動を追跡するために使用されると主張する人もいます。ローカルリンク内では、パケット内のハードウェアアドレスはすべて直接観察可能です。そのため、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に文書化されているように、IPv4 Link-Localの早期実装により、DHCP状態マシンが変更されました。フィールドエクスペリエンスは、これらの変更がDHCPサービスの信頼性を低下させることを示しています。
A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way.
IPv4 Link-LocalとDHCPV4クライアントの両方を実装するデバイスは、IPv4 Link-Local構成に対応するためにDHCPV4クライアントの動作を変更してはなりません。特に、DHCPサーバーが現在応答しているかどうかにかかわらず、IPv4 Link-Localアドレスの構成は、DHCPクライアントが新しいIPアドレスを取得しようとするのを止めるために、有効なDHCPリースを構成する十分な理由ではありません。または、DHCP状態マシンの動作を他の方法で変更します。
Further discussion of this issue is provided in "Detection of Network Attachment (DNA) in IPv4" [DNAv4].
この問題のさらなる議論は、「IPv4のネットワークアタッチメント（DNA）の検出」[DNAV4]で提供されています。
The considerations outlined here also apply whenever a host has multiple IP addresses, whether or not it has multiple physical interfaces. Other examples of multiple interfaces include different logical endpoints (tunnels, virtual private networks etc.) and multiple logical networks on the same physical medium. This is often referred to as "multi-homing".
ここで概説されている考慮事項は、複数の物理インターフェイスを持っているかどうかにかかわらず、ホストが複数のIPアドレスを持っているときはいつでも適用されます。複数のインターフェイスの他の例には、異なる論理エンドポイント（トンネル、仮想プライベートネットワークなど）および同じ物理媒体の複数の論理ネットワークが含まれます。これはしばしば「マルチホミング」と呼ばれます。
Hosts which have more than one active interface and elect to implement dynamic configuration of IPv4 Link-Local addresses on one or more of those interfaces will face various problems. This section lists these problems but does no more than indicate how one might solve them. At the time of this writing, there is no silver bullet which solves these problems in all cases, in a general way. Implementors must think through these issues before implementing the protocol specified in this document on a system which may have more than one active interface as part of a TCP/IP stack capable of multi-homing.
複数のアクティブインターフェイスを持ち、これらのインターフェイスの1つ以上にIPv4リンクローカルアドレスの動的構成を実装することを選択するホストは、さまざまな問題に直面します。このセクションにはこれらの問題がリストされていますが、それらをどのように解決するかを示すだけではありません。この執筆時点では、一般的な方法でこれらの問題を解決する銀の弾丸はありません。実装者は、マルチホーミングが可能なTCP/IPスタックの一部として複数のアクティブインターフェイスを持つ可能性のあるシステムにこのドキュメントで指定されたプロトコルを実装する前に、これらの問題を介して考える必要があります。
A host may be attached to more than one network at the same time. It would be nice if there was a single address space used in every network, but this is not the case. Addresses used in one network, be it a network behind a NAT or a link on which IPv4 Link-Local addresses are used, cannot be used in another network and have the same effect.
ホストが同時に複数のネットワークに接続される場合があります。すべてのネットワークで1つのアドレススペースが使用されている場合はいいことですが、そうではありません。1つのネットワークで使用されるアドレスは、NATの背後にあるネットワークであろうと、IPv4リンクローカルアドレスが使用されるリンクであろうと、別のネットワークで使用できず、同じ効果があります。
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.
最初のスコープアドレスの問題は、ソースアドレスの選択です。マルチホームのホストには、複数のアドレスがあります。特定の宛先に送信する際に、どのアドレスをソースアドレスとして使用する必要がありますか？この質問は、通常、送信するインターフェイス（どのアドレス）と送信方法（ルーターに前進するか、直接送信するか）を表すルーティングテーブルを参照することで回答されます。目的地が曖昧になる可能性があるため、選択はスコープされたアドレスによって複雑になります。テーブルは良い答えを得ることができないかもしれません。この問題は、セクション3.2で説明されているNext-Hopの選択と結びついています。
The second scoped address problem arises from scoped parameters leaking outside their scope. This is discussed in Section 7.
2番目のスコープアドレスの問題は、スコープされたパラメーターが範囲外に漏れていることから生じます。これについては、セクション7で説明します。
It is possible to overcome these problems. One way is to expose scope information to applications such that they are always aware of what scope a peer is in. This way, the correct interface could be selected, and a safe procedure could be followed with respect to forwarding addresses and other scoped parameters. There are other possible approaches. None of these methods have been standardized for IPv4 nor are they specified in this document. A good API design could mitigate the problems, either by exposing address scopes to 'scoped-address aware' applications or by cleverly encapsulating the scoping information and logic so that applications do the right thing without being aware of address scoping.
これらの問題を克服することが可能です。1つの方法は、スコープ情報をアプリケーションに公開することで、ピアがどのスコープに入っているかを常に認識することです。この方法では、正しいインターフェイスを選択でき、転送アドレスやその他のスコープパラメーターに関して安全な手順に従うことができます。他の可能なアプローチがあります。これらのメソッドは、IPv4用に標準化されていません。また、このドキュメントでは指定されていません。優れたAPIデザインは、アドレススコープを「スコープアドレスアウェア」アプリケーションに公開するか、スコーピング情報とロジックを巧みにカプセル化して、アプリケーションがアドレススコープを知らずに正しいことをするようにすることにより、問題を軽減できます。
An implementer could undertake to solve these problems, but cannot simply ignore them. With sufficient experience, it is hoped that specifications will emerge explaining how to overcome scoped address multi-homing problems.
実装者はこれらの問題を解決するために引き受けることができますが、単にそれらを無視することはできません。十分な経験があれば、仕様がスコープされたアドレスマルチホームの問題を克服する方法を説明することが期待されることが期待されています。
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?
これは、IPv4リンクローカル宛先アドレスに関する中心的な問題であり、複数のインターフェイスで到達可能です。Hostは、Link-Local Destination LとLに送信する必要がある場合、複数のリンクでARPを使用して解決できますか？
Even if a Link-Local address can be resolved on only one link at a given moment, there is no guarantee that it will remain unambiguous in the future. Additional hosts on other interfaces may claim the address L as well.
特定の瞬間にリンクローカルアドレスを1つのリンクのみで解決できる場合でも、将来は明確なままであるという保証はありません。他のインターフェイスの追加ホストもアドレスLを請求する場合があります。
One possibility is to support this only in the case where the application specifically expresses which interface to send from.
1つの可能性は、アプリケーションが送信するインターフェースを具体的に表現する場合にのみこれをサポートすることです。
There is no standard or obvious solution to this problem. Existing application software written for the IPv4 protocol suite is largely incapable of dealing with address ambiguity. This does not preclude an implementer from finding a solution, writing applications which are able to use it, and providing a host which can support dynamic configuration of IPv4 Link-Local addresses on more than one interface. This solution will almost surely not be generally applicable to existing software and transparent to higher layers, however.
この問題に対する標準的または明らかな解決策はありません。IPv4プロトコルスイート用に記述された既存のアプリケーションソフトウェアは、アドレスのあいまいさをほとんど処理できません。これにより、実装者がソリューションを見つけたり、それを使用できるアプリケーションを作成したり、複数のインターフェイスでIPv4 Link-Localアドレスの動的構成をサポートできるホストを提供することを妨げるものではありません。ただし、このソリューションは、既存のソフトウェアに一般的に適用されず、高レイヤーに透過的ではありません。
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.
IPスタックには、リンクローカル宛先アドレスに送信する必要があるパケットに関連付けられたアウトバウンドインターフェイスが必要であるため、インターフェイスの選択が発生する必要があります。アウトバウンドインターフェイスは、ソースアドレスや宛先アドレスなどのパケットのヘッダーパラメーターから導出することはできません（たとえば、転送テーブルの検索を使用して）。したがって、アウトバウンドインターフェイスアソシエーションは、他の手段を通じて明示的に行う必要があります。仕様は、これらの手段を規定していません。
Attention is paid in this specification to transition from the use of IPv4 Link-Local addresses to routable addresses (see Section 1.5). The intention is to allow a host with a single interface to first support Link-Local configuration then gracefully transition to the use of a routable address. Since the host transitioning to the use of a routable address may temporarily have more than one address active, the scoped address issues described in Section 3.1 will apply. When a host acquires a routable address, it does not need to retain its Link-Local address for the purpose of communicating with other devices on the link that are themselves using only Link-Local addresses: any host conforming to this specification knows that regardless of source address an IPv4 Link-Local destination must be reached by forwarding directly to the destination, not via a router; it is not necessary for that host to have a Link-Local source address in order to send to a Link-Local destination address.
この仕様では、IPv4リンクローカルアドレスの使用からルーティング可能なアドレスへの移行に注意が払われます（セクション1.5を参照）。意図は、単一のインターフェイスを持つホストが最初のリンクローカル構成をサポートし、ルーティング可能なアドレスの使用に優雅に移行できるようにすることです。ルーティング可能なアドレスの使用に移行するホストは、一時的に複数のアドレスをアクティブにする可能性があるため、セクション3.1で説明されているスコープアドレスの問題が適用されます。ホストがルーティング可能なアドレスを取得する場合、リンクローカルアドレスのみを使用しているリンク上の他のデバイスと通信する目的で、リンクローカルアドレスを保持する必要はありません。ソースアドレスは、ルーターを介してではなく、宛先に直接転送することにより、IPv4リンクローカル宛先に到達する必要があります。リンクローカルの宛先アドレスに送信するために、そのホストがリンクローカルソースアドレスを持つ必要はありません。
A host with an IPv4 Link-Local address may send to a destination which does not have an IPv4 Link-Local address. If the host is not multi-homed, the procedure is simple and unambiguous: Using ARP and forwarding directly to on-link destinations is the default route. If the host is multi-homed, however, the routing policy is more complex, especially if one of the interfaces is configured with a routable address and the default route is (sensibly) directed at a router accessible through that interface. The following example illustrates this problem and provides a common solution to it.
IPv4 Link-Localアドレスを持つホストは、IPv4 Link-Localアドレスを持たない宛先に送信できます。ホストがマルチホームでない場合、手順は単純で明確です。ARPを使用してオンリンク宛先に直接転送することがデフォルトのルートです。ただし、ホストがマルチホームの場合、特にインターフェイスのいずれかがルーティング可能なアドレスで構成され、デフォルトルートがそのインターフェイスを通じてアクセス可能なルーターに向けられている場合、ルーティングポリシーがより複雑になります。次の例は、この問題を示しており、それに対する一般的な解決策を提供します。
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はlink1とlink2に接続されています。インターフェイスi1はルーティング可能なアドレスで構成され、i2はIPv4リンクローカルアドレスです。Host1には、I1を介してRouterのアドレスに設定されたデフォルトルートがあります。HOST1は、169.254/16からI2に目的地にルーティングし、宛先に直接送信します。
HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3.
Host2には、i3に割り当てられた構成（非リンクローカル）IPv4アドレスがあります。
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.
名前解像度またはサービスディスカバリープロトコルを使用すると、Host2のアドレスを発見できます。Host2のアドレスは169.254/16ではないため、Host1のルーティングポリシーはI1を介してRouterにデータグラムをHost2に送信します。RouterからHost2へのルートがない限り、Host1からHost2に送信されたデータグラムはそれに到達しません。
One solution to this problem is for a host to attempt to reach any host locally (using ARP) for which it receives an unreachable ICMP error message (ICMP message codes 0, 1, 6 or 7 [RFC792]). The host tries all its attached links in a round robin fashion. This has been implemented successfully for some IPv6 hosts, to circumvent exactly this problem. In terms of this example, HOST1 upon failing to reach HOST2 via the ROUTER, will attempt to forward to HOST2 via i2 and succeed.
この問題の解決策の1つは、ホストが到達不可能なICMPエラーメッセージ（ICMPメッセージコード0、1、6、または7 [RFC792]）を受信するホスト（ARPを使用）に到達しようとすることです。ホストは、すべての添付のリンクをラウンドロビンファッションで試します。これは、一部のIPv6ホストで正確にこの問題を回避するために正常に実装されています。この例に関しては、Routerを介してHost2に到達できなかった場合、Host1はI2を介してHost2に転送し、成功しようとします。
It may also be possible to overcome this problem using techniques described in section 3.2, or other means not discussed here. This specification does not provide a standard solution, nor does it preclude implementers from supporting multi-homed configurations, provided that they address the concerns in this section for the applications which will be supported on the host.
また、セクション3.2で説明した手法、またはここで説明しない他の手段を使用して、この問題を克服することも可能かもしれません。この仕様は、標準的なソリューションを提供するものではなく、ホストでサポートされるアプリケーションのこのセクションの懸念に対処していれば、実装者がマルチホーム構成をサポートすることを妨げるものでもありません。
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.
特に、特定のインターフェイスに割り当てられたアドレスを請求するように見えるARPパケットは、そのインターフェイスで受信され、ハードウェアアドレスが他のインターフェイスである場合にのみ競合を示します。
If a host has two interfaces on the same link, then claiming and defending on those interfaces must ensure that they end up with different addresses just as if they were on different hosts. Note that some of the ways a host may find itself with two interfaces on the same link may be unexpected and non-obvious, such as when a host has Ethernet and 802.11 wireless, but those two links are (possibly even without the knowledge of the host's user) bridged together.
ホストが同じリンクに2つのインターフェイスを持っている場合、それらのインターフェイスで請求して防御する必要があります。ホストが同じリンクに2つのインターフェイスを使用して自分自身を見つける方法の一部は、ホストがイーサネットと802.11ワイヤレスを持っている場合など、予期しない非自明性である可能性がありますが、これらの2つのリンクは（おそらく、ホストのユーザー）が一緒にブリッジされました。
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.
Disjoint Networkリンクのホストは、同じIPv4リンクローカルアドレスを構成する場合があります。これらの個別のネットワークリンクが後で結合またはブリッジされた場合、同じアドレスを使用しようとする2つのホストが現在同じリンクにあります。いずれかのホストがネットワーク上の他のホストと通信しようとすると、ある時点で、問題のホストがアドレス競合があることを検出できるようにするARPパケットを放送します。
When these address conflicts are detected, the subsequent forced reconfiguration may be disruptive, causing TCP connections to be broken. However, it is expected that such disruptions will be rare. It should be relatively uncommon for networks to be joined while hosts on those networks are active. Also, 65024 addresses are available for IPv4 Link-Local use, so even when two small networks are joined, the chance of conflict for any given host is fairly small.
これらのアドレス競合が検出されると、その後の強制再構成が破壊的である可能性があり、TCP接続が破壊されます。ただし、このような混乱はまれになると予想されます。ネットワークのホストがアクティブである間、ネットワークが参加することは比較的まれである必要があります。また、IPv4 Link-Localの使用には65024のアドレスが利用できます。そのため、2つの小さなネットワークが結合された場合でも、特定のホストの競合の可能性はかなり小さいです。
When joining two large networks (defined as networks with a substantial number of hosts per segment) there is a greater chance of conflict. In such networks, it is likely that the joining of previously separated segments will result in one or more hosts needing to change their IPv4 Link-Local address, with subsequent loss of TCP connections. In cases where separation and re-joining is frequent, as in remotely bridged networks, this could prove disruptive. However, unless the number of hosts on the joined segments is very large, the traffic resulting from the join and subsequent address conflict resolution will be small.
2つの大規模なネットワーク（かなりの数のホストセグメントを持つネットワークとして定義される）に参加すると、競合の可能性が高くなります。このようなネットワークでは、以前に分離されたセグメントの結合により、1つ以上のホストがIPv4リンクローカルアドレスを変更し、その後TCP接続の損失をもたらす必要がある可能性があります。リモートで架橋されたネットワークのように、分離と再加入が頻繁に発生する場合、これは破壊的であることが証明される可能性があります。ただし、結合されたセグメントのホストの数が非常に多い場合を除き、結合とその後のアドレス競合解決に起因するトラフィックは少なくなります。
Sending ARP replies that have IPv4 Link-Local sender addresses via broadcast instead of unicast ensures that these conflicts can be detected as soon as they become potential problems, but no sooner. For example, if two disjoint network links are joined, where hosts A and B have both configured the same Link-Local address, X, they can remain in this state until A, B or some other host attempts to initiate communication. If some other host C now sends an ARP request for address X, and hosts A and B were to both reply with conventional unicast ARP replies, then host C might be confused, but A and B still wouldn't know there is a problem because neither would have seen the other's packet. Sending these replies via broadcast allows A and B to see each other's conflicting ARP packets and respond accordingly.
Unicastの代わりにブロードキャストを介してIPv4リンクローカル送信者アドレスを持つARP返信を送信することにより、これらの競合が潜在的な問題になるとすぐに、しかしすぐにこれらの競合を検出できるようになります。たとえば、ホストAとBの両方が同じリンクローカルアドレスXを構成している2つの分離ネットワークリンクが結合されている場合、A、B、または他のホストが通信を開始しようとするまでこの状態にとどまることができます。他のホストCがアドレスXのARPリクエストを送信し、ホストAとBが従来のユニキャストARP返信で応答することを両方ともした場合、ホストCは混乱する可能性がありますが、AとBはまだ問題があることを知りません。どちらも相手のパケットを見なかったでしょう。これらの返信をブロードキャストで送信すると、AとBが互いの矛盾するARPパケットを確認し、それに応じて応答することができます。
Note that sending periodic gratuitous ARPs in an attempt to detect these conflicts sooner is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if the network links were joined only briefly, and were separated again before any new 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.
これらの競合をより早く検出するために定期的な無償のARPを送信することは必要ありません。ネットワーク帯域幅を無駄にし、実際に有害である可能性があることに注意してください。たとえば、ネットワークリンクが短時間のみ結合され、AまたはBが関与する新しい通信が開始される前に再び分離された場合、一時的な紛争は良性であり、強制的な再構成は必要ありませんでした。この場合、不必要な強制再構成をトリガーすることは、有用な目的に役立ちません。ホストは、周期的な無償のARPを送信しないでください。
The use of IPv4 Link-Local Addresses may open a network host to new attacks. In particular, a host that previously did not have an IP address, and no IP stack running, was not susceptible to IP-based attacks. By configuring a working address, the host may now be vulnerable to IP-based attacks.
IPv4 Link-Localアドレスの使用は、新しい攻撃のネットワークホストを開く場合があります。特に、以前はIPアドレスがなく、IPスタックが実行されていなかったホストは、IPベースの攻撃の影響を受けませんでした。作業アドレスを構成することにより、ホストはIPベースの攻撃に対して脆弱になるようになりました。
The ARP protocol [RFC826] is insecure. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP requests with replies giving its own hardware address, thereby claiming ownership of every address on the network.
ARPプロトコル[RFC826]は安全ではありません。悪意のあるホストは、ネットワーク上に不正なARPパケットを送信し、他のホストの正しい操作を妨害する場合があります。たとえば、ホストはすべてのARPリクエストに簡単に応答し、独自のハードウェアアドレスを提供し、ネットワーク上のすべてのアドレスの所有権を主張することができます。
NOTE: There are certain kinds of local links, such as wireless LANs, that provide no physical security. Because of the existence of these links it would be very unwise for an implementer to assume that when a device is communicating only on the local link it can dispense with normal security precautions. Failure to implement appropriate security measures could expose users to considerable risks.
注：物理的なセキュリティを提供しないワイヤレスLANSなど、特定の種類のローカルリンクがあります。これらのリンクが存在するため、実装者がデバイスがローカルリンクでのみ通信している場合、通常のセキュリティ予防策を分配できると仮定することは非常に賢明ではありません。適切なセキュリティ対策を実装しないと、ユーザーがかなりのリスクにさらされる可能性があります。
A host implementing IPv4 Link-Local configuration has an additional vulnerability to selective reconfiguration and disruption. It is possible for an on-link attacker to issue ARP packets which would cause a host to break all its connections by switching to a new address. The attacker could force the host implementing IPv4 Link-Local configuration to select certain addresses, or prevent it from ever completing address selection. This is a distinct threat from that posed by spoofed ARPs, described in the preceding paragraph.
IPv4 Link-Local構成を実装するホストは、選択的再構成と破壊に対して追加の脆弱性を持っています。リンク攻撃者がARPパケットを発行する可能性があります。これにより、ホストが新しいアドレスに切り替えることですべての接続を壊すことができます。攻撃者は、ホストを強制的に実装しているIPv4リンクローカル構成を特定のアドレスを選択したり、アドレスの選択を完了したりしないようにします。これは、前の段落に記載されているスプーフィングされたARPによってもたらされるものとは明確な脅威です。
Implementations and users should also note that a node that gives up an address and reconfigures, as required by section 2.5, allows the possibility that another node can easily and successfully hijack existing TCP connections.
実装とユーザーは、セクション2.5で要求されるように、アドレスと再構成を放棄するノードが、別のノードが既存のTCP接続を簡単かつ正常にハイジャックできる可能性を可能にすることに注意する必要があります。
Implementers are advised that the Internet Protocol architecture expects every networked device or host must implement security which is adequate to protect the resources to which the device or host has access, including the network itself, against known or credible threats. Even though use of IPv4 Link-Local addresses may reduce the 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 Link-Localアドレスを使用すると、デバイスが公開される脅威の数が減少する可能性がありますが、インターネットプロトコルをサポートするデバイスの実装者は、顧客のローカルネットワークにセキュリティリスクがないと仮定してはなりません。
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.
ネットワークが提供するセキュリティがデバイスがアクセスできるリソースを保護するのに適切である特定の種類のデバイスまたは特定の環境があるかもしれませんが、要件が要件があるという一般的な声明を発表することは誤解を招くでしょう。Accessの唯一の手段として、IPv4 Link-Localアドレスを使用してデバイスのセキュリティが削減されます。
In all cases, whether or not IPv4 Link-Local addresses are used, it is necessary for implementers of devices supporting the Internet Protocol to analyze the known and credible threats to which a specific host or device might be subjected, and to the extent that it is feasible, to provide security mechanisms which ameliorate or reduce the risks associated with such threats.
すべての場合において、IPv4 Link-Localアドレスが使用されているかどうかにかかわらず、インターネットプロトコルをサポートするデバイスの実装者が、特定のホストまたはデバイスが対象となる可能性のある既知で信頼できる脅威を分析する必要があります。そのような脅威に関連するリスクを改善または減少させるセキュリティメカニズムを提供するために、実行可能です。
Use of IPv4 Link-Local autoconfigured addresses presents additional challenges to writers of applications and may result in existing application software failing.
IPv4 Link-Local Autoconfiguredアドレスの使用は、アプリケーションの作家に追加の課題を提示し、既存のアプリケーションソフトウェアが失敗する可能性があります。
IPv4 Link-Local addresses used by an application may change over time. Some application software encountering an address change will fail. For example, existing client TCP connections will be aborted, servers whose addresses change will have to be rediscovered, blocked reads and writes will exit with an error condition, and so on.
アプリケーションで使用されるIPv4リンクローカルアドレスは、時間とともに変更される場合があります。アドレスの変更に遭遇するいくつかのアプリケーションソフトウェアは失敗します。たとえば、既存のクライアントTCP接続は中止され、アドレスの変更を再発見する必要があるサーバー、ブロックされた読み取りと書き込みはエラー条件で終了します。
Vendors producing application software which will be used on IP implementations supporting IPv4 Link-Local address configuration SHOULD detect and cope with address change events. Vendors producing IPv4 implementations supporting IPv4 Link-Local address configuration SHOULD expose address change events to applications.
IPv4リンクローカルアドレス構成をサポートするIP実装で使用されるアプリケーションソフトウェアを作成するベンダーは、アドレス変更イベントを検出して対処する必要があります。IPv4リンクローカルアドレス構成をサポートするIPv4実装を生成するベンダーは、アドレス変更イベントをアプリケーションに公開する必要があります。
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.
IPv4リンクローカルアドレスは、アプリケーションプロトコル（URLなど）を介して、同じリンクにない宛先に転送しないでください。これについては、セクション2.9および3でさらに説明します。
Existing distributed application software that forwards address information may fail. For example, FTP [RFC959] (when not using passive mode) transmits the IP address of the client. Suppose a client starts up and obtains its IPv4 configuration at a time when it 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アドレスを送信します。クライアントが起動し、Link-LocalアドレスのみがあるときにIPv4構成を取得するとします。その後、ホストはグローバルIPアドレスを取得し、クライアントはローカルリンクの外側のFTPサーバーに連絡します。FTPクライアントがFTP「ポート」コマンド内の新しいグローバルIPアドレスの代わりに古いリンクローカルアドレスを送信すると、FTPサーバーはクライアントに戻るデータ接続を開くことができず、FTP操作は失敗します。
Application software run on a multi-homed host that supports IPv4 Link-Local address configuration on more than one interface may fail.
アプリケーションソフトウェアは、複数のインターフェイスでIPv4リンクローカルアドレス構成をサポートするマルチホームホストで実行される可能性があります。
This is because application software assumes that an IPv4 address is unambiguous, that it can refer to only one host. IPv4 Link-Local addresses are unique only on a single link. A host attached to multiple links can easily encounter a situation where the same address is present on more than one interface, or first on one interface, later on another; in any case associated with more than one host. Most existing software is not prepared for this ambiguity. In the future, application programming interfaces could be developed to prevent this problem. This issue is discussed in Section 3.
これは、アプリケーションソフトウェアがIPv4アドレスが明確であり、1つのホストのみを参照できると想定しているためです。IPv4 Link-Localアドレスは、単一のリンクでのみ一意です。複数のリンクに接続されたホストは、複数のインターフェイス、または最初のインターフェイスで同じアドレスが後で別のインターフェースに存在する状況に簡単に遭遇する可能性があります。いずれにせよ、複数のホストに関連付けられています。ほとんどの既存のソフトウェアは、このあいまいさのために準備されていません。将来的には、この問題を防ぐためにアプリケーションプログラミングインターフェイスを開発することができます。この問題については、セクション3で説明します。
A router MUST NOT forward a packet with an IPv4 Link-Local source or destination address, irrespective of the router's default route configuration or routes obtained from dynamic routing protocols.
ルーターは、ルーターのデフォルトルート構成または動的ルーティングプロトコルから取得したルートに関係なく、IPv4リンクローカルソースまたは宛先アドレスでパケットを転送してはなりません。
A router which receives a packet with an IPv4 Link-Local source or destination address MUST NOT forward the packet. This prevents forwarding of packets back onto the network segment from which they originated, or to any other segment.
IPv4 Link-Localソースまたは宛先アドレスを含むパケットを受信するルーターは、パケットを転送してはなりません。これにより、パケットが発信されたネットワークセグメントへの転送、または他のセグメントへの転送を防ぎます。
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を割り当てました。この範囲の最初と最後の256のアドレス（169.254.0.xおよび169.254.255.x）は、「IANAを書くためのガイドライン」（BCP 26）[RFC2434]で定義されているように、標準訴訟によって割り当てられます。このドキュメントでは、他のIANAサービスは必要ありません。
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).
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[802]ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ、ANSI/IEEE STD 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 STD 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 STD 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] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027] Holdrege、M。およびP. Srisuresh、「IPネットワークアドレス翻訳者とのプロトコルの合併症」、RFC 3027、2001年1月。
[DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", Work in Progress, July 2004.
[DNAV4] Aboba、B。、「IPv4でのネットワークアタッチメント（DNA）の検出」、2004年7月、進行中の作業。
[LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", Work in Progress, June 2004.
[llmnr] Esibov、L.、Aboba、B。、およびD. Thaler、「Linklocal Multicast Name Resolution（LLMNR）」、2004年6月、Work in Progress。
Acknowledgments
謝辞
We would like to thank (in alphabetical order) Jim Busse, Pavani Diwanji, Donald Eastlake 3rd, Robert Elz, Peter Ford, Spencer Giacalone, Josh Graessley, Brad Hards, Myron Hattig, Hugh Holbrook, Christian Huitema, Richard Johnson, Kim Yong-Woon, Mika Liljeberg, Rod Lopez, Keith Moore, Satish Mundra, Thomas Narten, Erik Nordmark, Philip Nye, Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery Smyslov, and Ryan Troll for their contributions.
（アルファベット順）ジム・ブッセ、パヴァニ・ディワンジ、ドナルド・イーストレイク・3rd、ロバート・エルツ、ピーター・フォード、スペンサー・ジャカロン、ジョシュ・グレスリー、ブラッド・ハード、マイロン・ハティグ、ヒュー・ホルブルック、クリスチャン・フイテマ、リチャード・ジョンソン、キム・ヨンソンウーン、ミカ・リルジェバーグ、ロッド・ロペス、キース・ムーア、サティシュ・ムンドラ、トーマス・ナルテン、エリック・ノードマーク、フィリップ・ナイ、ハワード・リドノール、ダニエル・セニー、ディーター・シーグムンド、バレリー・スミースロフ、ライアン・トロールの貢献。
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は9つのDHCPDISCOVERパケットを送信し、パケット間に2秒の間隔があります。これらのリクエストのいずれか（18秒）から応答がない場合、それは自動化されます。
Upon finding that a selected address is in use, Mac OS will select a new random address and try again, at a rate limited to no more than one attempt every two seconds.
選択したアドレスが使用されていることがわかったとき、Mac OSは新しいランダムアドレスを選択し、2秒ごとに1回以下の試行に制限されたレートで再試行します。
Autoconfigured Mac OS systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Mac OS is not successful in obtaining a new lease, it keeps the existing autoconfigured IP address. If Mac OS is successful at obtaining a new lease, it drops all existing connections without warning. This may cause users to lose sessions in progress. Once a new lease is obtained, Mac OS will not allocate further connections using the autoconfigured IP address.
Autoconfigured Mac OSシステムは、5分ごとにDHCPサーバーの存在をチェックします。DHCPサーバーが見つかったが、Mac OSが新しいリースの取得に成功していない場合、既存のAutoConfigured IPアドレスを保持します。Mac OSが新しいリースの取得に成功した場合、警告なしに既存のすべての接続をドロップします。これにより、ユーザーは進行中のセッションを失う可能性があります。新しいリースが得られると、Mac OSはAutoConfigured 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システムは、存在する場合、リンクローカルアドレスにアドレス指定されたパケットをデフォルトゲートウェイに送信しません。これらのアドレスは、常にローカルセグメントで解決されます。
Mac OS systems by default send all outgoing unicast packets with a TTL of 255. All multicast and broadcast packets are also sent with a TTL of 255 if they have a source address in the 169.254/16 prefix.
Mac OSシステムは、デフォルトでは、すべての発信ユニキャストパケットを255のTTLで送信します。すべてのマルチキャストパケットとブロードキャストパケットは、169.254/16プレフィックスにソースアドレスがある場合、255のTTLで送信されます。
Mac OS implements media sense where the hardware (and driver software) supports this. As soon as network connectivity is detected, a DHCPDISCOVER will be sent on the interface. This means that systems will immediately transition out of autoconfigured mode as soon as connectivity is restored.
Mac OSは、ハードウェア（およびドライバーソフトウェア）がこれをサポートする場所でメディアセンスを実装しています。ネットワーク接続が検出されるとすぐに、DHCPDISCOVERがインターフェイスに送信されます。これは、システムが復元されるとすぐに、システムが自動コンフィギングモードからすぐに遷移することを意味します。
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アドレスを選択します。選択したアドレスはメモリに保存されているため、システムの1つのブーツ中にその後のオートコンフィグレーザーの試み中に再利用できます。
Autoconfiguration of a Link-Local address depends on the results of the DHCP process. DHCP sends two packets, with timeouts of one and two seconds. If no response is received (three seconds), it begins autoconfiguration. DHCP continues sending packets in parallel for a total time of 60 seconds.
Link-Localアドレスの自動構成は、DHCPプロセスの結果に依存します。DHCPは、タイムアウトが1秒と2秒の2つのパケットを送信します。応答がない場合（3秒）、Autoconfigurationが開始されます。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.
Autoconfigurationの開始時に、10個の一意のランダムIPアドレスを生成し、それぞれが2秒間順番にプローブを生成します。使用されていないアドレスを見つけた後、調査が停止するか、アドレスのリストが使い果たされます。
If DHCP is not successful, it waits five minutes before starting over again. Once DHCP is successful, the autoconfigured Link-Local address is given up. The Link-Local subnet, however, remains configured.
DHCPが成功していない場合、もう一度やり直す前に5分待ちます。DHCPが成功すると、Autoconfigured Link-Localアドレスがgiviveめられます。ただし、Link-Localサブネットは構成されたままです。
Autoconfiguration is only attempted on a single interface at any given moment in time.
Autoconfigurationは、特定の瞬間に単一のインターフェイスでのみ試行されます。
Mac OS X ensures that the connected interface with the highest priority is associated with the Link-Local subnet. Packets addressed to a Link-Local address are never sent to the default gateway, if one is present. Link-local addresses are always resolved on the local segment.
Mac OS Xは、最優先度の高い接続されたインターフェイスがLink-Localサブネットに関連付けられることを保証します。リンクローカルアドレスにアドレス指定されたパケットは、存在する場合、デフォルトゲートウェイに送信されることはありません。Link-Localアドレスは、常にローカルセグメントで解決されます。
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は、ハードウェアとドライバーがそれをサポートする場所でメディアセンスを実装します。ネットワークメディアが接続されていることを示すと、自動構成プロセスが再び始まり、以前に割り当てられたLink-Localアドレスを再利用しようとします。ネットワークメディアが切断されていることを示すと、システムは4秒待機してから、Link-Localアドレスとサブネットを構成します。その時より前に接続が復元された場合、自動構成プロセスが再び開始されます。それ以前に接続が復元されない場合、システムはAutoConfigureに別のインターフェイスを選択します。
Mac OS X by default sends all outgoing unicast packets with a TTL of 255. All multicast and broadcast packets are also sent with a TTL of 255 if they have a source address in the 169.254/16 prefix.
Mac OS Xは、デフォルトですべての発信ユニキャストパケットを255のTTLで送信します。すべてのマルチキャストおよびブロードキャストパケットは、169.254/16プレフィックスにソースアドレスがある場合、255のTTLで送信されます。
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リンクローカルアドレスを選択します。アドレス選択アルゴリズムは、インターフェイスのMACアドレスのハッシュを計算することに基づいているため、ホストの大規模なコレクションは、169.254/16アドレススペース内のアドレスを選択する際に均一な確率分布に従うようになります。インターフェイスの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システムのAutoconfigure再試行カウントは10です。10個のAutoConfigured IPv4アドレスを試した後、すべてを検索した後、ホストはIPv4アドレスなしで起動します。
Autoconfigured Windows 98/98SE systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Windows 98 is not successful in obtaining a new lease, it keeps the existing autoconfigured IPv4 Link-Local address. If Windows 98/98SE is successful at obtaining a new lease, it drops all existing connections without warning. This may cause users to lose sessions in progress. Once a new lease is obtained, Windows 98/98SE will not allocate further connections using the autoconfigured IPv4 Link-Local address.
Autoconfigured Windows 98/98SEシステムは、5分ごとにDHCPサーバーが存在することをチェックします。DHCPサーバーが見つかったが、Windows 98が新しいリースの取得に成功していない場合、既存のAutoconfigured IPv4 Link-Ling Addressを保持します。Windows 98/98SEが新しいリースの取得に成功した場合、警告なしに既存のすべての接続をドロップします。これにより、ユーザーは進行中のセッションを失う可能性があります。新しいリースが取得されると、Windows 98/98SEは、AutoConfigured IPv4 Link-Localアドレスを使用してさらなる接続を割り当てません。
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 Link-Localアドレスを備えたWindows 98/98SEシステムは、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：\ tcpip \ parameters \ parameters \ defaultttl of type reg_dwordの設定によって実行されます。ただし、このデフォルトのTTLはすべてのパケットに適用されます。この機能を使用してデフォルトのTTLを255に設定することができますが、IPv4 Link-LocalパケットのデフォルトのTTLを1つに設定するために使用することはできませんが、他のパケットを1より大きい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 Link-Localプレフィックスからパケットを書き換え、ローカルリンクを超えて転送します。Windows 98SE ICSは、IPv4 Link-Localプレフィックスに対して自動的にルーティングされないため、DHCPを介してアドレスを取得するホストは、AutoConfiguredのみのデバイスと通信できません。
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 Link-Localアドレスを使用できます。Windows 98/98SEは、ルーターの勧誘/広告をサポートしていません。Windows 98/98SEシステムは、AutoConfiguredモードの場合、デフォルトゲートウェイを自動的に発見しません。
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 Systemsの自動構成動作は、次の点を除き、Windows 98/98SEと同じです。
Media Sense Router Discovery Silent RIP
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リスナーもサポートしています。これは、Autoconfiguredモード中にデフォルトゲートウェイを不注意に発見する可能性があることを意味します。
ICS on Windows XP/2000/ME behaves identically to Windows 98SE with respect to address allocation and NATing of Link-Local prefixes.
Windows XP/2000/MEのICSは、リンクローカルプレフィックスのアドレス割り当てとネートに関して、Windows 98SEと同じように動作します。
Authors' Addresses
著者のアドレス
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014, USA
Stuart Cheshire Apple Computer、Inc。1 Infinite Loop Cupertino California 95014、米国
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 818 4011
EMail: bernarda@microsoft.com
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
Erik Guttman Sun Microsystems Eichhoelzelstr。7 74915 Waibstadtドイツ
Phone: +49 7263 911 701
EMail: erik@spybeam.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
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に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。