[要約] RFC 4862はIPv6の状態を持たないアドレス自動設定に関する仕様であり、IPv6ノードがネットワーク上で自動的にアドレスを割り当てるための手順を定義しています。目的は、IPv6ノードが手動でアドレスを設定する必要なく、ネットワーク上で自動的にアドレスを取得できるようにすることです。
Network Working Group S. Thomson
Request for Comments: 4862 Cisco
Obsoletes: 2462 T. Narten
Category: Standards Track IBM
T. Jinmei
Toshiba
September 2007
IPv6 Stateless Address Autoconfiguration
IPv6ステートレスアドレスの自動設定
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の現在の版を参照してください。このメモの分布は無制限です。
Abstract
概要
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link.
このドキュメントは、IPバージョン6でインターフェイスを自動化する方法を決定するステップを指定します。自動設定プロセスでは、リンクローカルアドレスの生成、ステートレスアドレスの自動設定を介してグローバルアドレスを生成すること、および一意性を検証するための重複アドレス検出手順が含まれます。リンク上のアドレス。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Site Renumbering . . . . . . . . . . . . . . . . . . . . . 9
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 10
5.1. Node Configuration Variables . . . . . . . . . . . . . . . 10
5.2. Autoconfiguration-Related Structures . . . . . . . . . . . 11
5.3. Creation of Link-Local Addresses . . . . . . . . . . . . . 11
5.4. Duplicate Address Detection . . . . . . . . . . . . . . . 12
5.4.1. Message Validation . . . . . . . . . . . . . . . . . . 14
5.4.2. Sending Neighbor Solicitation Messages . . . . . . . . 14
5.4.3. Receiving Neighbor Solicitation Messages . . . . . . . 15
5.4.4. Receiving Neighbor Advertisement Messages . . . . . . 16
5.4.5. When Duplicate Address Detection Fails . . . . . . . . 17
5.5. Creation of Global Addresses . . . . . . . . . . . . . . . 17
5.5.1. Soliciting Router Advertisements . . . . . . . . . . . 18
5.5.2. Absence of Router Advertisements . . . . . . . . . . . 18
5.5.3. Router Advertisement Processing . . . . . . . . . . . 18
5.5.4. Address Lifetime Expiry . . . . . . . . . . . . . . . 20
5.6. Configuration Consistency . . . . . . . . . . . . . . . . 21
5.7. Retaining Configured Addresses for Stability . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Loopback Suppression and Duplicate Address
Detection . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Changes since RFC 1971 . . . . . . . . . . . . . . . 26
Appendix C. Changes since RFC 2462 . . . . . . . . . . . . . . . 27
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6). The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link.
このドキュメントでは、IPバージョン6（IPv6）のインターフェイスを自動設定する方法を決定するステップを指定します。自動構成プロセスは、リンクローカルアドレスを生成し、ステートレスアドレス自動設定を介してグローバルアドレスを生成すること、およびリンク上のアドレスの一意性を検証するための重複アドレス検出手順を含む。
The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link.
IPv6ステートレス自動設定メカニズムでは、ホストの手動設定、最小限のルータの設定、および追加のサーバーがないことが必要です。ステートレスメカニズムにより、ローカルに利用可能な情報とルータによってアドバタイズされた情報の組み合わせを使用して、ホストが独自のアドレスを生成できます。ルータはリンクに関連付けられているサブネットを識別するプレフィックスをアドバタイズしますが、ホストはサブネット上のインターフェイスを一意に識別する「インタフェース識別子」を生成します。2つを組み合わせることによってアドレスが形成されます。ルータがない場合、ホストはリンクローカルアドレスのみを生成できます。しかしながら、リンクローカルアドレスは、同じリンクに接続されているノード間の通信を可能にするのに十分である。
The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. On the other hand, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used when a site requires tighter control over exact address assignments. Both stateless address autoconfiguration and DHCPv6 may be used simultaneously.
ステートレスアプローチは、ユニークで正しくルーティング可能である限り、サイトが正確なアドレスのホストの使用に特に関係していない場合に使用されます。一方、IPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]は、サイトに正確なアドレス割り当てを厳密に制御する必要がある場合に使用されます。ステートレスアドレス自動設定とDHCPv6の両方を同時に使用できます。
IPv6 addresses are leased to an interface for a fixed (possibly infinite) length of time. Each address has an associated lifetime that indicates how long the address is bound to an interface. When a lifetime expires, the binding (and address) become invalid and the address may be reassigned to another interface elsewhere in the Internet. To handle the expiration of address bindings gracefully, an address goes through two distinct phases while assigned to an interface. Initially, an address is "preferred", meaning that its use in arbitrary communication is unrestricted. Later, an address becomes "deprecated" in anticipation that its current interface binding will become invalid. While an address is in a deprecated state, its use is discouraged, but not strictly forbidden. New communication (e.g., the opening of a new TCP connection) should use a preferred address when possible. A deprecated address should be used only by applications that have been using it and would have difficulty switching to another address without a service disruption.
IPv6アドレスは、固定された（おそらく無限）長さのためのインターフェースにリースされています。各アドレスには、アドレスがインターフェイスにどのようにバインドされているかを示す関連するライフタイムがあります。有効期限が切れると、バインディング（およびアドレス）が無効になり、アドレスはインターネット内の他の場所にある別のインターフェイスに再割り当てされることがあります。アドレスバインディングの有効期限を適切に処理するには、アドレスはインターフェイスに割り当てられている間に2つの異なるフェーズを通過します。最初に、アドレスは「優先」であり、任意の通信におけるその使用は無制限であることを意味する。後で、現在のインターフェイスバインディングが無効になると予想してアドレスが「廃止予定」になります。アドレスが廃止予定の状態にある間、その使用は推奨されませんが、厳密には禁止されていません。新しい通信（例えば、新しいTCP接続の開放）は可能な限り好ましいアドレスを使用する必要があります。廃止予定のアドレスは、それを使用していたアプリケーションによってのみ使用されるべきであり、サービスの中断なしで別のアドレスに切り替えることが困難であろう。
To ensure that all configured addresses are likely to be unique on a given link, nodes run a "duplicate address detection" algorithm on addresses before assigning them to an interface. The Duplicate Address Detection algorithm is performed on all addresses, independently of whether they are obtained via stateless autoconfiguration or DHCPv6. This document defines the Duplicate Address Detection algorithm.
設定されたすべてのアドレスが特定のリンクで一意である可能性があるようにするために、ノードはそれらをインターフェイスに割り当てる前にアドレスに「重複アドレス検出」アルゴリズムを実行します。重複アドレス検出アルゴリズムは、それらがステートレス自動設定またはDHCPv6を介して取得されたかどうかとは無関係に、すべてのアドレスに対して実行されます。この文書は重複アドレス検出アルゴリズムを定義します。
The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface.
このドキュメントで指定されている自動設定プロセスは、ルータではなくホストにのみ適用されます。ホストの自動設定はルータによってアドバタイズされた情報を使用するので、ルータは他の手段によって設定される必要があります。ただし、この文書に記載されているメカニズムを使用してルーターがリンクローカルアドレスを生成することが予想されます。さらに、ルータは、この文書に記載されている重複アドレス検出手順をインターフェイスに割り当てる前にすべてのアドレスに正常に渡すことが期待されています。
Section 2 provides definitions for terminology used throughout this document. Section 3 describes the design goals that lead to the current autoconfiguration procedure. Section 4 provides an overview of the protocol, while Section 5 describes the protocol in detail.
セクション2は、この文書全体を通して使用される用語の定義を提供します。セクション3では、現在の自動設定手順につながる設計目標について説明します。セクション4はプロトコルの概要を提供し、セクション5はプロトコルを詳細に説明しています。
IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used only in contexts where necessary to avoid ambiguity.
IP - Internet Protocolバージョン6. IPv4とIPv6という用語は、あいまいさを避けるために必要なコンテキストでのみ使用されます。
node - a device that implements IP.
node - IPを実装するデバイス。
router - a node that forwards IP packets not explicitly addressed to itself.
Router - IPパケットを自分自身に明示的にアドレス指定されていないノード。
host - any node that is not a router.
host - ルータではないノード。
upper layer - a protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and Internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IP such as IPX, AppleTalk, or IP itself.
上位層 - IPのすぐ上のプロトコルレイヤー。例としては、TCPやUDPなどのトランスポートプロトコル、ICMPなどの制御プロトコル、OSPFなどのルーティングプロトコル、およびIPX、AppleTalk、またはIP自体などのIPが「トンネル化されています」。
link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. The protocol described in this document will be used on all types of links unless specified otherwise in the link-type-specific document describing how to operate IP on the link in line with [RFC4861].
リンク - ノードをリンク層、すなわちIPの直下のレイヤで通信できる通信機能または媒体。例はイーサネット（シンプルまたはブリッジ付き）です。PPPリンクX.25、フレームリレー、またはATMネットワーク。IPv4またはIPv6自体の上のトンネルなど、インターネット（またはそれ以上の）レイヤーの「トンネル」。このドキュメントに記載されているプロトコルは、[RFC4861]に並んでリンク上のIPの動作方法を説明するリンクタイプ固有のドキュメントで指定されていない限り、すべての種類のリンクで使用されます。
interface - a node's attachment to a link.
インターフェース - リンクへのノードの添付ファイル。
packet - an IP header plus payload.
パケット - IPヘッダーとペイロード。
address - an IP-layer identifier for an interface or a set of interfaces.
address - インタフェースまたは一連のインターフェイスのIP層識別子。
unicast address - an identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address.
ユニキャストアドレス - 単一インターフェイスの識別子。ユニキャストアドレスに送信されたパケットは、そのアドレスによって識別されたインターフェイスに配信されます。
multicast address - an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address.
マルチキャストアドレス - 一連のインタフェースの識別子（通常は異なるノードに属しています）。マルチキャストアドレスに送信されたパケットは、そのアドレスによって識別されるすべてのインターフェイスに配信されます。
anycast address - an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocol's measure of distance). See [RFC4291].
Anycast Address - 一連のインターフェイス（通常は異なるノードに属する）の識別子。Anycastアドレスに送信されたパケットは、そのアドレスによって識別されるインターフェイスの1つ（ルーティングプロトコルの距離の尺度に従って）によって識別されます。[RFC4291]を参照してください。
solicited-node multicast address - a multicast address to which Neighbor Solicitation messages are sent. The algorithm for computing the address is given in [RFC4291].
勧誘ノードマルチキャストアドレス - ネイバー勧誘メッセージが送信されるマルチキャストアドレス。アドレスを計算するためのアルゴリズムは[RFC4291]に与えられます。
link-layer address - a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links and E.164 addresses for Integrated Services Digital Network (ISDN) links.
リンク層アドレス - インタフェースのリンクレイヤ識別子。例としては、イーサネットリンク用のIEEE 802アドレス、統合サービスデジタルネットワーク（ISDN）リンク用のE.164アドレスがあります。
link-local address - an address having link-only scope that can be used to reach neighboring nodes attached to the same link. All interfaces have a link-local unicast address.
link-local address - 同じリンクに接続されている隣接ノードに到達するために使用できるリンク専用スコープを持つアドレス。すべてのインターフェイスにはリンクローカルユニキャストアドレスがあります。
global address - an address with unlimited scope.
グローバルアドレス - 無制限のスコープを持つアドレス。
communication - any packet exchange among nodes that requires that the address of each node used in the exchange remain the same for the duration of the packet exchange. Examples are a TCP connection or a UDP request-response.
通信 - 交換内で使用されている各ノードのアドレスが、パケット交換の期間中に同じままであるノード間の任意のパケット交換。例は、TCP接続またはUDP要求応答です。
tentative address - an address whose uniqueness on a link is being verified, prior to its assignment to an interface. A tentative address is not considered assigned to an interface in the usual sense. An interface discards received packets addressed to a tentative address, but accepts Neighbor Discovery packets related to Duplicate Address Detection for the tentative address.
暫定アドレス - インタフェースへの割り当て前に、リンク上の一意性が検証されているアドレス。暫定的なアドレスは、通常の意味でインターフェースに割り当てられているとは見なされません。インターフェースは、暫定アドレス宛ての受信パケットを破棄しますが、仮アドレスの重複アドレス検出に関連するネイバーディスカバリパケットを受け入れます。
preferred address - an address assigned to an interface whose use by upper-layer protocols is unrestricted. Preferred addresses may be used as the source (or destination) address of packets sent from (or to) the interface.
優先address - 上位プロトコルによる使用が無制限のインターフェイスに割り当てられているアドレス。好ましいアドレスは、インターフェースから送信された（または）から送信されたパケットの送信元（または宛先）アドレスとして使用され得る。
deprecated address - An address assigned to an interface whose use is discouraged, but not forbidden. A deprecated address should no longer be used as a source address in new communications, but packets sent from or to deprecated addresses are delivered as expected. A deprecated address may continue to be used as a source address in communications where switching to a preferred address causes hardship to a specific upper-layer activity (e.g., an existing TCP connection).
廃止予定のアドレス - 使用が推奨されているが禁止されていないインターフェイスに割り当てられているアドレス。廃止予定のアドレスは、新しい通信の送信元アドレスとして使用されなくなりますが、廃止予定のアドレスから送信されたパケットは予想どおりに配信されます。廃止予定のアドレスは、好ましいアドレスへの切り替えが特定の上位層の活動（例えば既存のTCP接続）に困難を引き起こす通信中の送信元アドレスとして使用され続けることができる。
valid address - a preferred or deprecated address. A valid address may appear as the source or destination address of a packet, and the Internet routing system is expected to deliver packets sent to a valid address to their intended recipients.
有効なアドレス - 優先または非推奨のアドレス。有効なアドレスがパケットの送信元または宛先アドレスとして表示されることがあり、インターネットルーティングシステムは有効なアドレスに送信されたパケットを意図した受信者に配信すると予想されます。
invalid address - an address that is not assigned to any interface. A valid address becomes invalid when its valid lifetime expires. Invalid addresses should not appear as the destination or source address of a packet. In the former case, the Internet routing system will be unable to deliver the packet; in the latter case, the recipient of the packet will be unable to respond to it.
無効なアドレス - 任意のインターフェイスに割り当てられていないアドレス。有効なライフタイムが期限切れになると、有効なアドレスが無効になります。無効なアドレスは、パケットの宛先または送信元アドレスとして表示されません。前者の場合、インターネットルーティングシステムはパケットを配信できなくなります。後者の場合、パケットの受信者はそれに応答することができません。
preferred lifetime - the length of time that a valid address is preferred (i.e., the time until deprecation). When the preferred lifetime expires, the address becomes deprecated.
好ましい存続期間 - 有効なアドレスが優先される時間の長さ（すなわち、償却までの時間）。優先寿命が期限切れになると、アドレスは推奨されなくなります。
valid lifetime - the length of time an address remains in the valid state (i.e., the time until invalidation). The valid lifetime must be greater than or equal to the preferred lifetime. When the valid lifetime expires, the address becomes invalid.
有効な有効期間 - アドレスが有効な状態のまま（すなわち、無効化までの時間）の長さ。有効な寿命は、優先寿命以上でなければなりません。有効な有効期限が切れると、アドレスが無効になります。
interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [RFC4291]. Stateless address autoconfiguration combines an interface identifier with a prefix to form an address. From address autoconfiguration's perspective, an interface identifier is a bit string of known length. The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [RFC2464]). Note that the address architecture [RFC4291] also defines the length of the interface identifiers for some set of addresses, but the two sets of definitions must be consistent. In many cases, the identifier will be derived from the interface's link-layer address.
インターフェイス識別子 - リンクごとに（少なくとも）一意のインターフェイスのリンク依存識別子[RFC4291]。ステートレスアドレス自動設定インターフェイスIDとプレフィックスを作成してアドレスを形成します。アドレス自動設定の観点からは、インターフェイス識別子は既知の長さのビット文字列です。インターフェイス識別子の正確な長さと作成される方法は、特定のリンクタイプ（例えば、[RFC2464]）を介したIPの送信に関連する問題をカバーする別のリンク型固有の文書で定義されています。アドレスアーキテクチャ[RFC4291]はまた、いくつかのアドレスのセットのインターフェイス識別子の長さを定義していますが、2セットの定義は一貫している必要があります。多くの場合、識別子はインターフェイスのリンク層アドレスから派生します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
この文書に記載されている場合は、この文書に記載されている場合は、必要ではなく、必ずしも、推奨されるべきではなく、必ずしてはいけません。
Note that this document intentionally limits the use of the keywords to the protocol specification (Section 5).
この文書は意図的にキーワードの使用をプロトコル仕様に制限する（セクション5）。
Stateless autoconfiguration is designed with the following goals in mind:
ステートレス自動設定は、次の目標を念頭に置いて設計されています。
o Manual configuration of individual machines before connecting them to the network should not be required. Consequently, a mechanism is needed that allows a host to obtain or create unique addresses for each of its interfaces. Address autoconfiguration assumes that each interface can provide a unique identifier for that interface (i.e., an "interface identifier"). In the simplest case, an interface identifier consists of the interface's link-layer address. An interface identifier can be combined with a prefix to form an address.
o ネットワークに接続する前の個々のマシンの手動構成は必要ありません。その結果、ホストがそのインタフェースごとに一意のアドレスを取得または作成できるようにするメカニズムが必要です。アドレス自動設定は、各インターフェイスがそのインタフェースの一意の識別子（すなわち、「インタフェース識別子」）を提供できることを前提としています。最も単純な場合では、インターフェイス識別子はインターフェイスのリンク層アドレスで構成されています。インターフェイス識別子をプレフィックスと組み合わせることで、アドレスを形成できます。
o Small sites consisting of a set of machines attached to a single link should not require the presence of a DHCPv6 server or router as a prerequisite for communicating. Plug-and-play communication is achieved through the use of link-local addresses. Link-local addresses have a well-known prefix that identifies the (single) shared link to which a set of nodes attach. A host forms a link-local address by appending an interface identifier to the link-local prefix.
o 単一のリンクに接続されている一連のマシンからなる小サイトは、通信のための前提条件としてDHCPv6サーバーまたはルーターの存在を必要としません。リンクローカルアドレスを使用してプラグアンドプレイ通信が実現されます。リンクローカルアドレスには、一連のノードが添付されている（単一の）共有リンクを識別する有名なプレフィックスがあります。ホストは、リンクローカルプレフィックスにインターフェイス識別子を追加することによってリンクローカルアドレスを形成します。
o A large site with multiple networks and routers should not require the presence of a DHCPv6 server for address configuration. In order to generate global addresses, hosts must determine the prefixes that identify the subnets to which they attach. Routers generate periodic Router Advertisements that include options listing the set of active prefixes on a link.
o 複数のネットワークとルーターを持つ大規模なサイトは、アドレス設定用のDHCPv6サーバーの存在を必要としないはずです。グローバルアドレスを生成するために、ホストはそれらが添付するサブネットを識別するプレフィックスを決定する必要があります。ルータは、リンク上のアクティブなプレフィックスのセットを一覧表示するオプションを含む定期的なルータアドバタイズメントを生成します。
o Address configuration should facilitate the graceful renumbering of a site's machines. For example, a site may wish to renumber all of its nodes when it switches to a new network service provider. Renumbering is achieved through the leasing of addresses to interfaces and the assignment of multiple addresses to the same interface. Lease lifetimes provide the mechanism through which a site phases out old prefixes. The assignment of multiple addresses to an interface provides for a transition period during which both a new address and the one being phased out work simultaneously.
oアドレス設定は、サイトのマシンの優雅な番号を変更するのを容易にするはずです。たとえば、サイトは、新しいネットワークサービスプロバイダに切り替わるときにそのノードのすべてのノードを参照したい場合があります。参照番号は、インターフェイスへのアドレスのリースと同じインターフェイスへの複数のアドレスの割り当てを通じて実現されます。リース寿命は、サイトが古いプレフィックスを段階的に段階的にするメカニズムを提供します。インターフェースへの複数のアドレスの割り当ては、新しいアドレスと1つが同時に段階的に動作している間の遷移期間を提供する。
This section provides an overview of the typical steps that take place when an interface autoconfigures itself. Autoconfiguration is performed only on multicast-capable links and begins when a multicast-capable interface is enabled, e.g., during system startup. Nodes (both hosts and routers) begin the autoconfiguration process by generating a link-local address for the interface. A link-local address is formed by appending an identifier of the interface to the well-known link-local prefix [RFC4291].
このセクションでは、インターフェイスが自動設定時に行われる典型的な手順の概要を説明します。自動設定はマルチキャスト対応リンクでのみ実行され、マルチキャスト対応インタフェースが有効になっているとき、例えばシステム起動中に開始されます。ノード（ホストとルータの両方）は、インターフェイスのリンクローカルアドレスを生成することによって自動構成プロセスを開始します。リンクローカルアドレスは、既知のリンク - ローカルプレフィックス[RFC4291]にインタフェースの識別子を追加することによって形成される。
Before the link-local address can be assigned to an interface and used, however, a node must attempt to verify that this "tentative" address is not already in use by another node on the link. Specifically, it sends a Neighbor Solicitation message containing the tentative address as the target. If another node is already using that address, it will return a Neighbor Advertisement saying so. If another node is also attempting to use the same address, it will send a Neighbor Solicitation for the target as well. The exact number of times the Neighbor Solicitation is (re)transmitted and the delay time between consecutive solicitations is link-specific and may be set by system management.
ただし、リンクローカルアドレスをインターフェイスに割り当てることができますが、この「暫定的な」アドレスがリンク上の別のノードによってまだ使用されていないことを確認しようとしている必要があります。具体的には、暫定アドレスを含む隣接勧誘メッセージをターゲットとして送信します。別のノードがすでにそのアドレスを使用している場合は、そのように隣接アドバタイズメントを返します。別のノードも同じアドレスを使用しようとしている場合は、ターゲットにも隣接勧誘を送信します。隣接勧誘が送信された正確な回数（RE）、連続した契約の間の遅延時間はリンク固有であり、システム管理によって設定されます。
If a node determines that its tentative link-local address is not unique, autoconfiguration stops and manual configuration of the interface is required. To simplify recovery in this case, it should be possible for an administrator to supply an alternate interface identifier that overrides the default identifier in such a way that the autoconfiguration mechanism can then be applied using the new (presumably unique) interface identifier. Alternatively, link-local and other addresses will need to be configured manually.
暫定リンクローカルアドレスが固有ではないとノードが決定された場合は、自動設定停止、およびインターフェイスの手動構成が必要です。この場合の回復を簡単にするために、管理者が自動設定メカニズムを新しい（おそらく固有の）インターフェイス識別子を使用して適用できるように、デフォルトの識別子をオーバーライドする代替インタフェース識別子を提供することが可能であるはずである。あるいは、リンクローカルアドレスおよび他のアドレスを手動で構成する必要があります。
Once a node ascertains that its tentative link-local address is unique, it assigns the address to the interface. At this point, the node has IP-level connectivity with neighboring nodes. The remaining autoconfiguration steps are performed only by hosts; the (auto)configuration of routers is beyond the scope of this document.
暫定的なリンクローカルアドレスが一意であるというノードが確実になると、インターフェイスにアドレスを割り当てます。この時点で、ノードは隣接ノードとのIPレベルの接続性を持ちます。残りの自動構成ステップは、ホストによってのみ実行されます。ルータの（自動）構成はこの文書の範囲を超えています。
The next phase of autoconfiguration involves obtaining a Router Advertisement or determining that no routers are present. If routers are present, they will send Router Advertisements that specify what sort of autoconfiguration a host can do. Note that the DHCPv6 service for address configuration may still be available even if no routers are present.
自動構成の次の段階では、ルータの広告を取得するか、ルータが存在しないと判断することが含まれます。ルータが存在する場合、それらはホストがどのような様式の自動設定を行うことができるルータアドバタイズメントを送信します。ルータが存在しなくても、アドレス設定のためのDHCPv6サービスは利用可能かもしれないことに注意してください。
Routers send Router Advertisements periodically, but the delay between successive advertisements will generally be longer than a host performing autoconfiguration will want to wait [RFC4861]. To obtain an advertisement quickly, a host sends one or more Router Solicitations to the all-routers multicast group.
ルータは定期的にルータアドバタイズメントを送信しますが、連続した広告間の遅延は通常、自動設定を実行したいホストが通常表示されます[RFC4861]。広告をすばやく取得するには、ホストはすべてのルータ勧誘を全ルータマルチキャストグループに送信します。
Router Advertisements also contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate global addresses. It should be noted that a host may use both stateless address autoconfiguration and DHCPv6 simultaneously. One Prefix Information option field, the "autonomous address-configuration flag", indicates whether or not the option even applies to stateless autoconfiguration. If it does, additional option fields contain a subnet prefix, together with lifetime values, indicating how long addresses created from the prefix remain preferred and valid.
ルータ広告には、グローバルアドレスを生成するためにステートレスアドレス自動設定で使用される情報を含む0個以上のプレフィックス情報オプションも含まれています。ホストは、ステートレスアドレス自動設定とDHCPv6の両方を同時に使用することができることに注意してください。1つのプレフィックス情報オプションフィールド、「自律アドレス - 設定フラグ」は、そのオプションがステートレスの自動設定に適用されているかどうかを示します。そうであれば、追加のオプションフィールドには、プレフィックスから作成された長いアドレスが優先され、有効なままであることを示す、Lifetime値とともにサブネットプレフィックスが含まれています。
Because routers generate Router Advertisements periodically, hosts will continually receive new advertisements. Hosts process the information contained in each advertisement as described above, adding to and refreshing information received in previous advertisements.
ルータは定期的にルータアドバタイズメントを生成するため、ホストは継続的に新しい広告を受信します。ホストは、前述のように各広告に含まれている情報を処理し、以前の広告に受信された情報を追加し、更新します。
By default, all addresses should be tested for uniqueness prior to their assignment to an interface for safety. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration, or via DHCPv6. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag.
デフォルトでは、すべてのアドレスを安全のためのインタフェースへの割り当て前に一意性のためにテストする必要があります。テストは、ステートレスアドレス自動設定、またはDHCPv6を介して手動で取得されたすべてのアドレスに対して個別に実行されるべきです。重複アドレス検出を実行するオーバーヘッドを信じるサイトに対応するために、インタフェースごとの設定フラグの管理設定によって、重複アドレス検出の使用を無効にすることができます。
To speed the autoconfiguration process, a host may generate its link-local address (and verify its uniqueness) in parallel with waiting for a Router Advertisement. Because a router may delay responding to a Router Solicitation for a few seconds, the total time needed to complete autoconfiguration can be significantly longer if the two steps are done serially.
自動構成プロセスをスピードアップするために、ホストは、ルータ広告の待機と並行してそのリンクローカルアドレスを生成する（そしてその一意性を検証する）ことができます。ルータは数秒間ルータの勧誘に応答することを遅らせる可能性があるため、2つのステップが直列に行われた場合、自動設定を完了するのに必要な合計時間はかなり長くなる可能性があります。
Address leasing facilitates site renumbering by providing a mechanism to time-out addresses assigned to interfaces in hosts. At present, upper-layer protocols such as TCP provide no support for changing end-point addresses while a connection is open. If an end-point address becomes invalid, existing connections break and all communication to the invalid address fails. Even when applications use UDP as a transport protocol, addresses must generally remain the same during a packet exchange.
アドレスリースは、ホスト内のインタフェースに割り当てられたタイムアウトアドレスにメカニズムを提供することによって、サイトの番号変更を容易にします。現在、TCPなどの上位層プロトコルは、接続が開いている間にエンドポイントアドレスを変更するためのサポートは提供されません。エンドポイントアドレスが無効になると、既存の接続が破損し、無効なアドレスへのすべての通信が失敗します。アプリケーションがトランスポートプロトコルとしてUDPを使用する場合でも、アドレスは一般にパケット交換中に同じままです。
Dividing valid addresses into preferred and deprecated categories provides a way of indicating to upper layers that a valid address may become invalid shortly and that future communication using the address will fail, should the address's valid lifetime expire before communication ends. To avoid this scenario, higher layers should use a preferred address (assuming one of sufficient scope exists) to increase the likelihood that an address will remain valid for the duration of the communication. It is up to system administrators to set appropriate prefix lifetimes in order to minimize the impact of failed communication when renumbering takes place. The deprecation period should be long enough that most, if not all, communications are using the new address at the time an address becomes invalid.
有効なアドレスを優先され廃止されたカテゴリに分割すると、有効なアドレスが短く無効になる可能性がある上位レイヤを示す方法が提供され、アドレスの有効なライフタイムが通信が終了する前に有効期限が切れるようになります。このシナリオを回避するために、アドレスが通信期間中に有効なままである可能性を高めるために、より高い層は優先アドレスを使用する必要があります（十分な範囲のうちの1つが存在すると仮定する）。番号管理者は、番号管理者が参照が行われたときに失敗した通信の影響を最小限に抑えるために適切なプレフィックスの寿命を設定することです。廃止予定期間は、すべてが全くわからない場合、アドレスが無効になる時に新しいアドレスを使用していることがわかります。
The IP layer is expected to provide a means for upper layers (including applications) to select the most appropriate source address given a particular destination and possibly other constraints. An application may choose to select the source address itself before starting a new communication or may leave the address unspecified, in which case, the upper networking layers will use the mechanism provided by the IP layer to choose a suitable address on the application's behalf.
IP層は、特定の宛先およびおそらく他の制約を考慮して、最も適切な送信元アドレスを選択するための上位層（アプリケーションを含む）のための手段を提供することが予想される。アプリケーションは、新しい通信を開始する前に送信元アドレス自体を選択するか、またはそのアドレスを指定しないようにすることができ、その場合、上位ネットワーク層はIPレイヤによって提供されたメカニズムを使用してアプリケーションの代わりに適切なアドレスを選択します。
Detailed address selection rules are beyond the scope of this document and are described in [RFC3484].
詳細な住所選択規則はこの文書の範囲を超えていて、[RFC3484]に記載されています。
Autoconfiguration is performed on a per-interface basis on multicast-capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface. Autoconfiguration applies primarily to hosts, with two exceptions. Routers are expected to generate a link-local address using the procedure outlined below. In addition, routers perform Duplicate Address Detection on all addresses prior to assigning them to an interface.
自動設定は、マルチキャスト対応インタフェースでインターフェイスごとに実行されます。マルチホームホストの場合、自動設定は各インターフェイスで独立して実行されます。Autoconfigurationは、主にホストに適用され、2つの例外を示します。ルータは、以下に概説されている手順を使用してリンクローカルアドレスを生成すると予想されます。さらに、ルータはそれらをインターフェイスに割り当てる前に、すべてのアドレスの重複アドレス検出を実行します。
A node MUST allow the following autoconfiguration-related variable to be configured by system management for each multicast-capable interface: DupAddrDetectTransmits The number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection on a tentative address. A value of zero indicates that Duplicate Address Detection is not performed on tentative addresses. A value of one indicates a single transmission with no follow-up retransmissions.
ノードでは、各マルチキャスト対応インタフェースごとにシステム管理によって次のAutoconfiguration関連の変数を設定できます.DupAddrDetectTransmits暫定アドレスでの重複アドレス検出を実行しながら送信された連続した隣接勧誘メッセージの数。ゼロの値は、暫定アドレスでの重複アドレス検出が行われていないことを示します。値は、追従再送を受けていない単一の伝送を示します。
Default: 1, but may be overridden by a link-type specific value in the document that covers issues related to the transmission of IP over a particular link type (e.g., [RFC2464]).
デフォルト：1は、特定のリンクタイプ（例えば、[RFC2464]）を介したIPの送信に関連する問題をカバーする、ドキュメント内のリンク型固有の値によって上書きされる可能性があります。
Autoconfiguration also assumes the presence of the variable RetransTimer as defined in [RFC4861]. For autoconfiguration purposes, RetransTimer specifies the delay between consecutive Neighbor Solicitation transmissions performed during Duplicate Address Detection (if DupAddrDetectTransmits is greater than 1), as well as the time a node waits after sending the last Neighbor Solicitation before ending the Duplicate Address Detection process.
自動設定は、[RFC4861]で定義されているような可変レターンススタイルの存在も引き受けます。自動設定の目的のために、RetranStimerは、重複アドレス検出中に実行された連続した隣接勧誘の間の遅延（DUPADDRDETECTTRANSMITSが1より大きい場合）、および重複アドレス検出プロセスを終了する前に最後の隣接勧誘を送信した後の時間を指定します。
Beyond the formation of a link-local address and use of Duplicate Address Detection, how routers (auto)configure their interfaces is beyond the scope of this document.
リンクローカルアドレスの形成と重複アドレス検出の使用を超えて、ルータ（AUTO）がそれらのインタフェースを設定する方法は、このドキュメントの範囲を超えています。
A host maintains a list of addresses together with their corresponding lifetimes. The address list contains both autoconfigured addresses and those configured manually.
ホストは、対応する寿命とともにアドレスのリストを維持します。アドレスリストには、自動構成済みアドレスと手動で構成されたものの両方が含まれています。
A node forms a link-local address whenever an interface becomes enabled. An interface may become enabled after any of the following events:
ノードは、インターフェイスが有効になったときにリンクローカルアドレスを作成します。次のいずれかのイベント後にインターフェイスが有効になる可能性があります。
- The interface is initialized at system startup time.
- インタフェースはシステムの起動時に初期化されます。
- The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management.
- インタフェースは、一時的なインタフェースの障害後、またはシステム管理によって一時的に無効になった後に再初期化されます。
- The interface attaches to a link for the first time. This includes the case where the attached link is dynamically changed due to a change of the access point of wireless networks.
- インターフェイスは初めてリンクに接続します。これには、無線ネットワークのアクセスポイントの変更により、添付リンクが動的に変化する場合が含まれる。
- The interface becomes enabled by system management after having been administratively disabled.
- インターフェースは、管理上無効になった後にシステム管理によってイネーブルになります。
A link-local address is formed by combining the well-known link-local prefix FE80::0 [RFC4291] (of appropriate length) with an interface identifier as follows:
リンクローカルアドレスは、（適切な長さの）既知のリンクローカルプレフィックスFE80 :: 0 [RFC4291]を次のようにインタフェース識別子と組み合わせることによって形成される。
1. The left-most 'prefix length' bits of the address are those of the link-local prefix.
1. アドレスの左端の「プレフィックス長」ビットは、リンクローカルプレフィックスのものです。
2. The bits in the address to the right of the link-local prefix are set to all zeroes.
2. リンクローカルプレフィックスの右側のアドレス内のビットはすべてのゼロに設定されています。
3. If the length of the interface identifier is N bits, the right-most N bits of the address are replaced by the interface identifier.
3. インターフェイス識別子の長さがNビットの場合、アドレスの右端のNビットはインターフェイス識別子に置き換えられます。
If the sum of the link-local prefix length and N is larger than 128, autoconfiguration fails and manual configuration is required. The length of the interface identifier is defined in a separate link-type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2). These documents will carefully define the length so that link-local addresses can be autoconfigured on the link.
link-localプレフィックス長とnの合計が128より大きい場合、自動設定に失敗し、手動構成が必要です。インターフェイス識別子の長さは別のリンク型固有の文書で定義されています。これは、アドレスアーキテクチャ[RFC4291]と一致するはずです（セクション2を参照）。これらの文書は、リンクローカルアドレスをリンク上で自動設定できるように長さを慎重に定義します。
A link-local address has an infinite preferred and valid lifetime; it is never timed out.
リンクローカルアドレスには、無限の優先有効な有効期間があります。タイムアウトされていません。
Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions:
無数のアドレス検出は、ステートレス自動設定、DHCPv6、または手動構成を介して、次の例外を除いて、それらをインターフェイスに割り当てる前に、すべてのユニキャストアドレスに対して実行する必要があります。
- An interface whose DupAddrDetectTransmits variable is set to zero does not perform Duplicate Address Detection.
- dupaddrdetectTransmits変数がゼロに設定されているインターフェースは、重複アドレス検出を実行しません。
- Duplicate Address Detection MUST NOT be performed on anycast addresses (note that anycast addresses cannot syntactically be distinguished from unicast addresses).
- 重複アドレス検出は、エニーキャストアドレスに対して実行してはいけません（エニキャストアドレスは構文的にはユニキャストアドレスとは区別できません）。
- Each individual unicast address SHOULD be tested for uniqueness. Note that there are implementations deployed that only perform Duplicate Address Detection for the link-local address and skip the test for the global address that uses the same interface identifier as that of the link-local address. Whereas this document does not invalidate such implementations, this kind of
- 個々のユニキャストアドレスは、一意性のためにテストされるべきです。リンクローカルアドレスの重複アドレス検出のみを実行し、リンクローカルアドレスと同じインターフェイス識別子を使用するグローバルアドレスのテストをスキップする実装が展開されています。この文書はそのような実装を無効にしていない、この種の
"optimization" is NOT RECOMMENDED, and new implementations MUST NOT do that optimization. This optimization came from the assumption that all of an interface's addresses are generated from the same identifier. However, the assumption does actually not stand; new types of addresses have been introduced where the interface identifiers are not necessarily the same for all unicast addresses on a single interface [RFC4941] [RFC3972]. Requiring that Duplicate Address Detection be performed for all unicast addresses will make the algorithm robust for the current and future special interface identifiers.
「最適化」はお勧めできません。新しい実装はその最適化を行ってはいけません。この最適化は、すべてのインターフェイスのアドレスが同じ識別子から生成されるという仮定から取得されました。ただし、仮定は実際にはスタンドではありません。インターフェイス識別子が単一インターフェイス[RFC4941] [RFC3972]では、インタフェース識別子が必ずしも同じではない場合には、新しいタイプのアドレスが導入されました。すべてのユニキャストアドレスに対して重複アドレス検出を実行することは、現在および将来の特別なインターフェイス識別子に対してアルゴリズムを堅牢にすることを要求する。
The procedure for detecting duplicate addresses uses Neighbor Solicitation and Advertisement messages as described below. If a duplicate address is discovered during the procedure, the address cannot be assigned to the interface. If the address is derived from an interface identifier, a new identifier will need to be assigned to the interface, or all IP addresses for the interface will need to be manually configured. Note that the method for detecting duplicates is not completely reliable, and it is possible that duplicate addresses will still exist (e.g., if the link was partitioned while Duplicate Address Detection was performed).
重複アドレスを検出するための手順は、後述するように隣接勧誘および広告メッセージを使用する。手順中に重複アドレスが検出された場合は、アドレスをインターフェイスに割り当てることはできません。アドレスがインターフェイス識別子から派生した場合、新しい識別子をインターフェイスに割り当てる必要があります。また、インターフェイスのすべてのIPアドレスを手動で設定する必要があります。重複を検出するための方法は完全に信頼性がなく、重複アドレスが存在する（例えば、重複アドレス検出が行われている間にリンクが分割された場合）。
An address on which the Duplicate Address Detection procedure is applied is said to be tentative until the procedure has completed successfully. A tentative address is not considered "assigned to an interface" in the traditional sense. That is, the interface must accept Neighbor Solicitation and Advertisement messages containing the tentative address in the Target Address field, but processes such packets differently from those whose Target Address matches an address assigned to the interface. Other packets addressed to the tentative address should be silently discarded. Note that the "other packets" include Neighbor Solicitation and Advertisement messages that have the tentative (i.e., unicast) address as the IP destination address and contain the tentative address in the Target Address field. Such a case should not happen in normal operation, though, since these messages are multicasted in the Duplicate Address Detection procedure.
重複アドレス検出手順が適用されるアドレスは、手順が正常に完了するまで暫定的であると言われている。伝統的な意味では、仮アドレスは「インタフェースに割り当てられている」とは見なされません。すなわち、インタフェースは、ターゲットアドレスフィールド内の仮アドレスを含む隣接勧誘メッセージおよび広告メッセージを受け入れなければならず、そのようなパケットとターゲットアドレスがインターフェースに割り当てられたアドレスとの間違いが異なる。暫定アドレス宛ての他のパケットは静かに廃棄されるべきです。なお、「他のパケット」には、IP宛先アドレスとして暫定的な（すなわちユニキャスト）アドレスを有する隣接勧誘および広告メッセージが含まれており、ターゲットアドレスフィールドに仮アドレスを含む。これらのメッセージは重複アドレス検出手順でマルチキャストされているので、そのような場合は通常の動作では起こるべきではありません。
It should also be noted that Duplicate Address Detection must be performed prior to assigning an address to an interface in order to prevent multiple nodes from using the same address simultaneously. If a node begins using an address in parallel with Duplicate Address Detection, and another node is already using the address, the node performing Duplicate Address Detection will erroneously process traffic intended for the other node, resulting in such possible negative consequences as the resetting of open TCP connections.
複数のノードが同時に同じアドレスを使用するのを防ぐために、アドレスをインターフェイスに割り当てる前に、重複アドレス検出を実行する必要があることにも留意されたい。ノードが重複アドレス検出と並行してアドレスを使用している場合、別のノードが既にアドレスを使用している場合、重複アドレス検出を実行するノードは他のノードを対象としたトラフィックを誤って処理し、その結果、オープンのリセットとしての悪影響が可能になります。TCP接続
The following subsections describe specific tests a node performs to verify an address's uniqueness. An address is considered unique if none of the tests indicate the presence of a duplicate address within RetransTimer milliseconds after having sent DupAddrDetectTransmits Neighbor Solicitations. Once an address is determined to be unique, it may be assigned to an interface.
以下のサブセクションでは、アドレスの一意性を検証するためにノードが実行する具体的なテストについて説明します。DupAddrDetectTransmits隣接勧誘を送信した後、Retectimerミリ秒内の重複アドレスの存在を示すテストではない場合は、アドレスが一意であると見なされます。アドレスが一意であると決定されると、インターフェイスに割り当てることができます。
A node MUST silently discard any Neighbor Solicitation or Advertisement message that does not pass the validity checks specified in [RFC4861]. A Neighbor Solicitation or Advertisement message that passes these validity checks is called a valid solicitation or valid advertisement, respectively.
ノードは、[RFC4861]で指定された有効性チェックを渡していない隣接勧誘または広告メッセージを静かに破棄しなければなりません。これらの有効性チェックを渡す隣接勧誘または広告メッセージは、それぞれ有効な勧誘または有効な広告と呼ばれます。
Before sending a Neighbor Solicitation, an interface MUST join the all-nodes multicast address and the solicited-node multicast address of the tentative address. The former ensures that the node receives Neighbor Advertisements from other nodes already using the address; the latter ensures that two nodes attempting to use the same address simultaneously should detect each other's presence.
隣接勧誘を送信する前に、インターフェイスは、暫定アドレスの全ノードマルチキャストアドレスと勧誘ノードマルチキャストアドレスを結合する必要があります。前者は、既にアドレスを使用している他のノードからノードが隣接アドバタイズメントを受信することを保証します。後者は、同じアドレスを同時に使用しようとしている2つのノードが互いの存在を検出する必要があります。
To check an address, a node sends DupAddrDetectTransmits Neighbor Solicitations, each separated by RetransTimer milliseconds. The solicitation's Target Address is set to the address being checked, the IP source is set to the unspecified address, and the IP destination is set to the solicited-node multicast address of the target address.
アドレスを確認するために、ノードはDupAddrDetectTransmitsネイバー契約を送信し、それぞれRetranStimerミリ秒で区切られます。勧誘対象アドレスは、チェックされているアドレスに設定され、IPソースは不特定アドレスに設定され、IP宛先はターゲットアドレスの勧誘ノードマルチキャストアドレスに設定されます。
If the Neighbor Solicitation is going to be the first message sent from an interface after interface (re)initialization, the node SHOULD delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in [RFC4861]. This serves to alleviate congestion when many nodes start up on the link at the same time, such as after a power failure, and may help to avoid race conditions when more than one node is trying to solicit for the same address at the same time.
インターフェイス（RE）の初期化後に隣接勧誘がインターフェイスから送信された最初のメッセージになると、ノードは[RFC4861]で指定されているように、0からMAX_RTR_SOLITITION_DELAYの間のランダムな遅延によって依頼されたノードマルチキャストアドレスの結合を遅らせる必要があります。これは、多くのノードが停電後などのリンク上でリンク上で起動すると、輻輳を軽減するのに役立ち、複数のノードが同時に同じアドレスを求めようとしているときに競合状態を回避するのに役立ちます。
Even if the Neighbor Solicitation is not going to be the first message sent, the node SHOULD delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY if the address being checked is configured by a router advertisement message sent to a multicast address. The delay will avoid similar congestion when multiple nodes are going to configure addresses by receiving the same single multicast router advertisement.
隣接勧誘が送信された最初のメッセージであっても、ノードは、チェックされているアドレスがマルチキャストに送信されたルータ広告メッセージによって構成されている場合、0からMAX_RTR_Solity_Delayの間のランダムな遅延によって依頼されたノードマルチキャストアドレスを結合する必要があります。住所。複数のノードが同じ単一のマルチキャストルータアドバタイズメントを受信してアドレスを設定しようとしている場合、遅延は同様の輻輳を回避します。
Note that when a node joins a multicast address, it typically sends a Multicast Listener Discovery (MLD) report message [RFC2710] [RFC3810] for the multicast address. In the case of Duplicate Address Detection, the MLD report message is required in order to inform MLD-snooping switches, rather than routers, to forward multicast packets. In the above description, the delay for joining the multicast address thus means delaying transmission of the corresponding MLD report message. Since the MLD specifications do not request a random delay to avoid race conditions, just delaying Neighbor Solicitation would cause congestion by the MLD report messages. The congestion would then prevent the MLD-snooping switches from working correctly and, as a result, prevent Duplicate Address Detection from working. The requirement to include the delay for the MLD report in this case avoids this scenario. [RFC3590] also talks about some interaction issues between Duplicate Address Detection and MLD, and specifies which source address should be used for the MLD report in this case.
ノードがマルチキャストアドレスを結合すると、通常、マルチキャストアドレスのマルチキャストリスナディスカバリ（MLD）レポートメッセージ[RFC2710] [RFC2710]を送信します。アドレス検出が重複している場合、MLDレポートメッセージは、ルータではなくMLDスヌーピングスイッチにマルチキャストパケットを転送するために必要です。以上の説明では、マルチキャストアドレスを結合するための遅延は、対応するMLDレポートメッセージの送信を遅らせることを意味する。 MLD仕様は競合条件を回避するためにランダムな遅延を要求しないので、隣接勧誘を遅らせるだけで、MLDレポートメッセージによる輻輳が発生します。その後、輻輳はMLDスヌーピングスイッチが正しく機能しないようにすると、その結果、重複したアドレス検出が機能するのを防ぐことができます。この場合、MLDレポートの遅延を含める要件はこのシナリオを回避します。 [RFC3590]重複アドレス検出とMLDの間のいくつかの対話の問題について話し、この場合はMLDレポートにどの送信元アドレスを使用するかを指定します。
In order to improve the robustness of the Duplicate Address Detection algorithm, an interface MUST receive and process datagrams sent to the all-nodes multicast address or solicited-node multicast address of the tentative address during the delay period. This does not necessarily conflict with the requirement that joining the multicast group be delayed. In fact, in some cases it is possible for a node to start listening to the group during the delay period before MLD report transmission. It should be noted, however, that in some link-layer environments, particularly with MLD-snooping switches, no multicast reception will be available until the MLD report is sent.
重複アドレス検出アルゴリズムの頑健性を向上させるために、インタフェースは、遅延期間中に暫定アドレスの全ノードマルチキャストアドレスまたは依然としてノードマルチキャストアドレスに送信されたデータグラムを受信して処理する必要がある。これは必ずしもマルチキャストグループを結合する要件と矛盾する必要はありません。実際、場合によっては、MLDレポート送信前の遅延期間中にノードがグループの聴取を開始することが可能である。ただし、いくつかのリンクレイヤ環境では、特にMLDスヌーピングスイッチでは、MLDレポートが送信されるまでマルチキャスト受信はできません。
On receipt of a valid Neighbor Solicitation message on an interface, node behavior depends on whether or not the target address is tentative. If the target address is not tentative (i.e., it is assigned to the receiving interface), the solicitation is processed as described in [RFC4861]. If the target address is tentative, and the source address is a unicast address, the solicitation's sender is performing address resolution on the target; the solicitation should be silently ignored. Otherwise, processing takes place as described below. In all cases, a node MUST NOT respond to a Neighbor Solicitation for a tentative address.
インターフェイス上で有効な隣接勧誘メッセージを受信すると、ノードの動作はターゲットアドレスが暫定的であるかどうかによって異なります。ターゲットアドレスが暫定的ではない場合（すなわち、受信インタフェースに割り当てられている）、勧誘は[RFC4861]に記載されているように処理される。ターゲットアドレスが暫定的なもので、送信元アドレスがユニキャストアドレスである場合、勧誘者の送信者はターゲット上のアドレス解決を実行しています。勧誘は無視されるべきです。そうでなければ、処理は以下のように行われる。すべての場合において、ノードは暫定アドレスの隣接勧誘に応答してはいけません。
If the source address of the Neighbor Solicitation is the unspecified address, the solicitation is from a node performing Duplicate Address Detection. If the solicitation is from another node, the tentative address is a duplicate and should not be used (by either node). If the solicitation is from the node itself (because the node loops back multicast packets), the solicitation does not indicate the presence of a duplicate address.
隣接勧誘の送信元アドレスが不特定アドレスである場合、勧誘は重複アドレス検出を実行するノードからのものである。勧誘が別のノードからのものである場合、仮アドレスは重複しており、（どちらのノードによって）使用しないでください。勧誘がノード自体からのものである場合（ノードがマルチキャストパケットをループバックするため）、勧誘は重複アドレスの存在を示していません。
Implementer's Note: many interfaces provide a way for upper layers to selectively enable and disable the looping back of multicast packets. The details of how such a facility is implemented may prevent Duplicate Address Detection from working correctly. See Appendix A for further discussion.
実装者の注：多くのインタフェースは、上位層がマルチキャストパケットのループバックを選択的に有効にして無効にする方法を提供します。そのような施設がどのように実施されるかの詳細は、重複アドレス検出が正しく機能するのを妨げる可能性がある。詳細については付録Aを参照してください。
The following tests identify conditions under which a tentative address is not unique:
次のテストは、仮アドレスが一意ではない条件を識別します。
- If a Neighbor Solicitation for a tentative address is received before one is sent, the tentative address is a duplicate. This condition occurs when two nodes run Duplicate Address Detection simultaneously, but transmit initial solicitations at different times (e.g., by selecting different random delay values before joining the solicited-node multicast address and transmitting an initial solicitation).
- 暫定アドレスに対する隣接勧誘が送信される前に受信された場合、仮アドレスは重複しています。この状態は、2つのノードが同時に重複アドレス検出を実行するが、異なる時間で初期省エリティを送信するときに発生します（例えば、勧誘ノードマルチキャストアドレスを結合する前に異なるランダム遅延値を選択し、初期の勧誘を送信する前に）。
- If the actual number of Neighbor Solicitations received exceeds the number expected based on the loopback semantics (e.g., the interface does not loop back the packet, yet one or more solicitations was received), the tentative address is a duplicate. This condition occurs when two nodes run Duplicate Address Detection simultaneously and transmit solicitations at roughly the same time.
- 受信された隣接勧誘の数がループバックセマンティクスに基づいて予想される数を超えている場合（例えば、インターフェースはパケットをループバックしない、まだ1つ以上の救済は受信された）、仮アドレスは重複しています。この状態は、2つのノードが同時に重複アドレス検出を実行し、おおよそ同じ時間で契約を送信するときに発生します。
On receipt of a valid Neighbor Advertisement message on an interface, node behavior depends on whether the target address is tentative or matches a unicast or anycast address assigned to the interface:
インターフェイス上で有効なネイバーアドバタイズメントメッセージを受信すると、ノード動作は、ターゲットアドレスが暫定的なものか、インターフェイスに割り当てられているユニキャストアドレスまたはアニキャストアドレスと一致するかどうかによって異なります。
1. If the target address is tentative, the tentative address is not unique.
1. ターゲットアドレスが暫定的な場合、仮アドレスは固有ではありません。
2. If the target address matches a unicast address assigned to the receiving interface, it would possibly indicate that the address is a duplicate but it has not been detected by the Duplicate Address Detection procedure (recall that Duplicate Address Detection is not completely reliable). How to handle such a case is beyond the scope of this document.
2. ターゲットアドレスが受信側インタフェースに割り当てられているユニキャストアドレスと一致する場合、アドレスが重複しているが、重複アドレス検出手順によって検出されていないことを示すことが可能になる（重複アドレス検出は完全に信頼できるものではないことを思い出させる）。このような場合を扱う方法は、この文書の範囲を超えています。
3. Otherwise, the advertisement is processed as described in [RFC4861].
3. それ以外の場合、広告は[RFC4861]に記載されているように処理されます。
A tentative address that is determined to be a duplicate as described above MUST NOT be assigned to an interface, and the node SHOULD log a system management error.
上記のように重複して決定された仮アドレスはインターフェイスに割り当ててはならず、ノードはシステム管理エラーを記録する必要があります。
If the address is a link-local address formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP operation on the interface SHOULD be disabled. By disabling IP operation, the node will then:
アドレスが、一意に割り当てられている（例えば、イーサネットインターフェース用のEUI - 64）ハードウェアアドレスに基づいてインタフェース識別子から形成されたリンクローカルアドレスである場合、インタフェース上のIP操作は無効にされるべきである。IP操作を無効にすると、ノードは次のようになります。
- not send any IP packets from the interface,
- インターフェイスからIPパケットを送信しないでください。
- silently drop any IP packets received on the interface, and
- インターフェイスで受信したIPパケットを静的にドロップします。
- not forward any IP packets to the interface (when acting as a router or processing a packet with a Routing header).
- IPパケットをインターフェイスに転送しない（ルータとして機能する場合、またはルーティングヘッダーを使用してパケットを処理する）。
In this case, the IP address duplication probably means duplicate hardware addresses are in use, and trying to recover from it by configuring another IP address will not result in a usable network. In fact, it probably makes things worse by creating problems that are harder to diagnose than just disabling network operation on the interface; the user will see a partially working network where some things work, and other things do not.
この場合、IPアドレスの複製は、重複するハードウェアアドレスが使用されていることを意味し、別のIPアドレスを構成することによってそれから回復しようとすることは使用可能なネットワークをもたらすことによってそれから回復しようとします。実際には、インタフェースでネットワーク操作を無効にするだけでなく、診断が困難な問題を作成することで、それはおそらく悪化します。ユーザーは、いくつかのことが機能する部分的に働くネットワークを見て、他のものはそうではありません。
On the other hand, if the duplicate link-local address is not formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned, IP operation on the interface MAY be continued.
一方、一意に割り当てられていると思われるハードウェアアドレスに基づいて、重複リンクローカルアドレスがインタフェース識別子から形成されていない場合、インタフェース上のIP動作を継続することができる。
Note: as specified in Section 2, "IP" means "IPv6" in the above description. While the background rationale about hardware address is independent of particular network protocols, its effect on other protocols is beyond the scope of this document.
注：セクション2では、「IP」は上記の説明では「IPv6」を意味します。ハードウェアアドレスに関する背景根拠は特定のネットワークプロトコルとは無関係であるが、他のプロトコルへの影響はこの文書の範囲を超えています。
Global addresses are formed by appending an interface identifier to a prefix of appropriate length. Prefixes are obtained from Prefix Information options contained in Router Advertisements. Creation of global addresses as described in this section SHOULD be locally configurable. However, the processing described below MUST be enabled by default.
グローバルアドレスは、適切な長さのプレフィックスにインターフェイス識別子を追加することによって形成されます。プレフィックスは、ルータ広告に含まれているプレフィックス情報オプションから取得されます。このセクションで説明されているグローバルアドレスの作成はローカルに設定できます。ただし、以下の処理はデフォルトで有効にする必要があります。
Router Advertisements are sent periodically to the all-nodes multicast address. To obtain an advertisement quickly, a host sends out Router Solicitations as described in [RFC4861].
ルータ広告は、全ノードマルチキャストアドレスに定期的に送信されます。広告をすばやく取得するには、[RFC4861]に記載されているようにホストがルータの勧誘を送信します。
Even if a link has no routers, the DHCPv6 service to obtain addresses may still be available, and hosts may want to use the service. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in [RFC4861].
リンクにルータがない場合でも、アドレスを取得するDHCPv6サービスは依然として利用可能であり、ホストはサービスを使用したい場合があります。自動設定の観点からは、[RFC4861]で説明されているように少数のルータ勧誘を送信した後にルータの広告が受信されない場合、リンクはルータを持たない。
Note that it is possible that there is no router on the link in this sense, but there is a node that has the ability to forward packets. In this case, the forwarding node's address must be manually configured in hosts to be able to send packets off-link, since the only mechanism to configure the default router's address automatically is the one using Router Advertisements.
この意味でリンク上にルータがない可能性があることに注意してくださいが、パケットを転送する機能を持つノードがあります。この場合、デフォルトのルータのアドレスを自動的に設定するための唯一のメカニズムは、ルータ広告を使用しているものであるため、転送ノードのアドレスをホストでオフリンクを送信できるように手動で設定する必要があります。
For each Prefix-Information option in the Router Advertisement:
ルータ広告のプレフィックス情報オプションごとに、次の手順を実行します。
a) If the Autonomous flag is not set, silently ignore the Prefix Information option.
a) 自律フラグが設定されていない場合は、プレフィックス情報オプションを静かに無視します。
b) If the prefix is the link-local prefix, silently ignore the Prefix Information option.
b) 接頭辞がlink-local接頭辞の場合は、プレフィックス情報オプションを黙って無視します。
c) If the preferred lifetime is greater than the valid lifetime, silently ignore the Prefix Information option. A node MAY wish to log a system management error in this case.
c) 優先有効期間が有効な有効期間よりも大きい場合は、プレフィックス情報オプションを静的に無視します。この場合、ノードはシステム管理エラーを記録することをお勧めします。
d) If the prefix advertised is not equal to the prefix of an address configured by stateless autoconfiguration already in the list of addresses associated with the interface (where "equal" means the two prefix lengths are the same and the first prefix-length bits of the prefixes are identical), and if the Valid Lifetime is not 0, form an address (and add it to the list) by combining the advertised prefix with an interface identifier of the link as follows:
d) アドバタイズされたプレフィックスが、インターフェイスに関連付けられているアドレスのリスト内にすでにステートレス自動設定によって設定されているアドレスの接頭辞の接頭辞に等しくない場合（「等しい」とは、2つの接頭辞長が同じで、接頭辞の最初のプレフィックス長ビットが同じです。同一の）、有効な有効期間が0ではない場合は、アドバタイズされたプレフィックスを次のようにリンクのインターフェイス識別子と組み合わせることでアドレスを作成し（リストに追加）。
| 128 - N bits | N bits |
+---------------------------------------+------------------------+
| link prefix | interface identifier |
+----------------------------------------------------------------+
If the sum of the prefix length and interface identifier length
does not equal 128 bits, the Prefix Information option MUST be
ignored. An implementation MAY wish to log a system management
error in this case. The length of the interface identifier is
defined in a separate link-type specific document, which should
also be consistent with the address architecture [RFC4291] (see
Section 2).
It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. It should be noted, however, that this does not mean the advertised prefix length is meaningless. In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128. Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration.
ルータ広告に含まれるプレフィックスの長さがそのリンクタイプのインターフェイス識別子の長さと一致するようにすることは、システム管理者の責任です。ただし、これは広告プレフィックス長が無意味であるという意味ではないことに注意してください。実際、広告長は[RFC4861]でのオンリンク決定には、プレフィックス長とインタフェース識別子の長さの合計が128に等しくない場合があります。したがって、アドバタイズされたプレフィックスを検証するのは安全であるべきです。ここで、アドレスの自動設定のコンテキストで無効なプレフィックス長を指定する構成エラーを検出し、回避するために、長さ。
Note that a future revision of the address architecture [RFC4291] and a future link-type-specific document, which will still be consistent with each other, could potentially allow for an interface identifier of length other than the value defined in the current documents. Thus, an implementation should not assume a particular constant. Rather, it should expect any lengths of interface identifiers.
将来のアドレスアーキテクチャ[RFC4291]の将来の改訂と将来のリンク型固有の文書は、依然として互いに一貫している可能性があることに注意して、現在の文書で定義された値以外の長さのインタフェース識別子を可能にする可能性があることに注意してください。したがって、実装は特定の定数を仮定しないでください。むしろ、それはどの長さのインターフェース識別子を期待するべきです。
If an address is formed successfully and the address is not yet in the list, the host adds it to the list of addresses assigned to the interface, initializing its preferred and valid lifetime values from the Prefix Information option. Note that the check against the prefix performed at the beginning of this step cannot always detect the address conflict in the list. It could be possible that an address already in the list, configured either manually or by DHCPv6, happens to be identical to the newly created address, whereas such a case should be atypical.
アドレスが正常に形成され、アドレスがまだリストに含まれていない場合、ホストはインターフェイスに割り当てられているアドレスのリストに追加され、プレフィックス情報オプションからの優先寿命値を初期化します。この手順の先頭にあるプレフィックスに対するチェックは、リスト内のアドレスの競合を常に検出できません。手動でまたはDHCPv6によって設定されたリスト内のアドレスが、新しく作成されたアドレスと同じであることが可能になる可能性がありますが、そのような場合はそのような場合が異なるはずです。
e) If the advertised prefix is equal to the prefix of an address configured by stateless autoconfiguration in the list, the preferred lifetime of the address is reset to the Preferred Lifetime in the received advertisement. The specific action to perform for the valid lifetime of the address depends on the Valid Lifetime in the received advertisement and the remaining time to the valid lifetime expiration of the previously autoconfigured address. We call the remaining time "RemainingLifetime" in the following discussion: 1. If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime.
e）アドバタイズされたプレフィックスがリスト内のステートレス自動設定によって設定されたアドレスの接頭辞に等しい場合、アドレスの優先寿命は受信した広告内の優先寿命にリセットされます。アドレスの有効な有効期間を実行するための特定のアクションは、受信したアドバタイズメントの有効な有効期間と残りの時間が、以前に自動設定されたアドレスの有効な寿命の有効期限までです。次の説明では、残りの時間 "helicleLifeTime"を呼び出します.1。受信した有効な有効期間が残りのLifeTimeよりも大きい場合は、対応するアドレスの有効な有効期間をアドバタイズされた有効な有効期間に設定します。
2. If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated (e.g., via Secure Neighbor Discovery [RFC3971]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option.
2. RESSTIONLIFETIMEが2時間以下の場合、このオプションが取得したルータアドバタイズが認証されていない限り（例えば、Secure Noiby Discovery [RFC3971]を介して）、有効な有効期間に関してプレフィックス情報オプションを無視します。ルータの広告が認証された場合、対応するアドレスの有効な有効期間は、受信したオプションの有効な有効期間に設定する必要があります。
3. Otherwise, reset the valid lifetime of the corresponding address to 2 hours.
3. それ以外の場合は、対応するアドレスの有効な有効期間を2時間にリセットします。
The above rules address a specific denial-of-service attack in which a bogus advertisement could contain prefixes with very small Valid Lifetimes. Without the above rules, a single unauthenticated advertisement containing bogus Prefix Information options with short Valid Lifetimes could cause all of a node's addresses to expire prematurely. The above rules ensure that legitimate advertisements (which are sent periodically) will "cancel" the short Valid Lifetimes before they actually take effect.
上記の規則は、ボーガス広告が非常に小さい有効な寿命を持つプレフィックスを含めることができる特定のサービス拒否攻撃に対処します。上記の規則がなければ、短い有効な寿命を持つBogusプレフィックス情報オプションを含む単一の未認証広告は、すべてのノードのアドレスを早期に期限切れにする可能性があります。上記の規則は、正当な広告（定期的に送信される）が実際に有効になる前に短い有効な寿命を「キャンセル」することを保証します。
Note that the preferred lifetime of the corresponding address is always reset to the Preferred Lifetime in the received Prefix Information option, regardless of whether the valid lifetime is also reset or ignored. The difference comes from the fact that the possible attack for the preferred lifetime is relatively minor. Additionally, it is even undesirable to ignore the preferred lifetime when a valid administrator wants to deprecate a particular address by sending a short preferred lifetime (and the valid lifetime is ignored by accident).
有効なライフタイムもリセットされているか無視されたかどうかにかかわらず、対応するアドレスの優先寿命は、受信したプレフィックス情報オプションの優先寿命に常にリセットされることに注意してください。その差は、好ましい寿命の可能な攻撃が比較的小さいという事実から来ています。さらに、有効な管理者が短い優先寿命を送信することによって特定のアドレスを廃止することを望んでいるときに好ましい寿命を無視することが望ましくない（そして有効な寿命は偶発的に無視される）。
A preferred address becomes deprecated when its preferred lifetime expires. A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used to initiate new communications if an alternate (non-deprecated) address of sufficient scope can easily be used instead.
好ましい寿命が期限切れになると、好ましいアドレスが推奨されるようになる。廃止予定のアドレスは、既存の通信の送信元アドレスとして使用され続けるべきですが、十分な範囲の代替（非推奨）アドレスが代わりに簡単に使用できる場合は、新しい通信を開始するために使用されるべきではありません。
Note that the feasibility of initiating new communication using a non-deprecated address may be an application-specific decision, as only the application may have knowledge about whether the (now) deprecated address was (or still is) in use by the application. For example, if an application explicitly specifies that the protocol stack use a deprecated address as a source address, the protocol stack must accept that; the application might request it because that IP address is used in higher-level communication and there might be a requirement that the multiple connections in such a grouping use the same pair of IP addresses.
非廃止されていないアドレスを使用して新しい通信を開始することの実現可能性は、アプリケーションによって（現在）廃止予定されたアドレスがアプリケーションによって使用されているかどうかについての知識を有することができるので、アプリケーション固有の決定であり得ることに留意されたい。たとえば、アプリケーションがプロトコルスタックがソースアドレスとして廃止予定アドレスを使用することを明示的に指定している場合、プロトコルスタックはそれを受け入れる必要があります。IPアドレスが上位レベルの通信で使用され、そのようなグループ内の複数の接続が同じIPアドレスを使用するという要件があるため、アプリケーションは要求することがあります。
IP and higher layers (e.g., TCP, UDP) MUST continue to accept and process datagrams destined to a deprecated address as normal since a deprecated address is still a valid address for the interface. In the case of TCP, this means TCP SYN segments sent to a deprecated address are responded to using the deprecated address as a source address in the corresponding SYN-ACK (if the connection would otherwise be allowed).
IPおよび上位層（例えば、TCP、UDP）は、廃止予定のアドレスが依然としてインターフェースの有効なアドレスであるため、通常のように廃止予定アドレス宛てのデータグラムを受け入れて処理し続ける必要があります。TCPの場合、これは廃止予定アドレスに送信されたTCP SYNセグメントを対応するSYN-ACK（接続が許可されている場合）のソースアドレスとして廃止予定アドレスを使用するように応答することを意味します。
An implementation MAY prevent any new communication from using a deprecated address, but system management MUST have the ability to disable such a facility, and the facility MUST be disabled by default.
実装では、新しい通信が廃止予定のアドレスを使用するのを防ぐことができますが、システム管理はそのような機能を無効にする必要があり、施設はデフォルトで無効にする必要があります。
Other subtle cases should also be noted about source address selection. For example, the above description does not clarify which address should be used between a deprecated, smaller-scope address and a non-deprecated, sufficient scope address. The details of the address selection including this case are described in [RFC3484] and are beyond the scope of this document.
ソースアドレスの選択については、他の微妙な場合も注意する必要があります。例えば、上記の説明は、廃止予定の小さいスコープアドレスと非廃止されていない十分なスコープアドレスとの間でどのアドレスを使用すべきかを明確にしない。この場合を含むアドレス選択の詳細は[RFC3484]に記載されており、この文書の範囲を超えています。
An address (and its association with an interface) becomes invalid when its valid lifetime expires. An invalid address MUST NOT be used as a source address in outgoing communications and MUST NOT be recognized as a destination on a receiving interface.
有効な有効期限が切れると、アドレス（およびインターフェイスとの関連付け）が無効になります。無効なアドレスは、発信通信中の送信元アドレスとして使用しないでください。受信インターフェイス上の宛先として認識されてはいけません。
It is possible for hosts to obtain address information using both stateless autoconfiguration and DHCPv6 since both may be enabled at the same time. It is also possible that the values of other configuration parameters, such as MTU size and hop limit, will be learned from both Router Advertisements and DHCPv6. If the same configuration information is provided by multiple sources, the value of this information should be consistent. However, it is not considered a fatal error if information received from multiple sources is inconsistent. Hosts accept the union of all information received via Neighbor Discovery and DHCPv6.
両方が同時に有効にされる可能性があるため、ホストはステートレス自動設定とDHCPv6の両方を使用してアドレス情報を取得することが可能です。MTUサイズやホップの制限などの他の構成パラメータの値が、ルータアドバタイズメントとDHCPv6の両方から学習される可能性もあります。同じ設定情報が複数のソースによって提供されている場合、この情報の値は一貫しているはずです。ただし、複数のソースから受信した情報が矛盾している場合、致命的なエラーとは見なされません。ホストは、ネイバーディスカバリとDHCPv6を介して受信したすべての情報の組合を受け入れます。
If inconsistent information is learned from different sources, an implementation may want to give information learned securely precedence over information learned without protection. For instance, Section 8 of [RFC3971] discusses how to deal with information learned through Secure Neighbor Discovery conflicting with information learned through plain Neighbor Discovery. The same discussion can apply to the preference between information learned through plain Neighbor Discovery and information learned via secured DHCPv6, and so on.
矛盾した情報がさまざまな情報源から学習された場合、実装は保護なしで学習された情報を確実に優先した情報を学習したいと思うかもしれません。たとえば、[RFC3971]のセクション8は、プレーンネイバーディスカバリーを通じて学んだ情報と競合する安全な近隣の発見を通じて学んだ情報に対処する方法について説明します。同じ議論は、平野近隣の発見を通して学んだ情報と担保付きのDHCPv6を介して学んだ情報との間の好みに適用することができる。
In any case, if there is no security difference, the most recently obtained values SHOULD have precedence over information learned earlier.
いずれにせよ、セキュリティ差がない場合、最後に取得された値は、早期に学習された情報よりも優先されるべきです。
An implementation that has stable storage may want to retain addresses in the storage when the addresses were acquired using stateless address autoconfiguration. Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the valid lifetime) of a router will never result in losing a global address of the node even if the node were to reboot. When this technique is used, it should also be noted that the expiration times of the preferred and valid lifetimes must be retained, in order to prevent the use of an address after it has become deprecated or invalid.
安定したストレージを持つ実装は、ステートレスアドレスの自動設定を使用してアドレスが取得されたときにストレージ内のアドレスを保持することをお勧めします。ライフタイムが使用されていると仮定すると、この技術は、ルータの一時的な停止（有効な有効期間よりも小さい）が、ノードが再起動することになっていてもノードのグローバルアドレスを失うことになることを意味します。この技術が使用されるとき、それが非推奨または無効になった後のアドレスの使用を防ぐために、好ましい寿命および有効な寿命の有効期限を保持する必要があることにも留意されたい。
Further details on this kind of extension are beyond the scope of this document.
この種の拡張に関するさらなる詳細はこの文書の範囲を超えています。
Stateless address autoconfiguration allows a host to connect to a network, configure an address, and start communicating with other nodes without ever registering or authenticating itself with the local site. Although this allows unauthorized users to connect to and use a network, the threat is inherently present in the Internet architecture. Any node with a physical attachment to a network can generate an address (using a variety of ad hoc techniques) that provides connectivity.
ステートレスアドレスの自動設定は、ホストがネットワークに接続し、アドレスを設定し、ローカルサイトと自分自身を登録または認証することなく他のノードと通信を開始します。これにより、許可されていないユーザーがネットワークへの接続と使用を可能にするが、脅威は本質的にインターネットアーキテクチャに存在します。ネットワークへの物理的な添付ファイルを持つノードは、接続を提供するアドレス（さまざまなアドホック・テクニックを使用して）を生成できます。
The use of stateless address autoconfiguration and Duplicate Address Detection opens up the possibility of several denial-of-service attacks. For example, any node can respond to Neighbor Solicitations for a tentative address, causing the other node to reject the address as a duplicate. A separate document [RFC3756] discusses details about these attacks, which can be addressed with the Secure Neighbor Discovery protocol [RFC3971]. It should also be noted that [RFC3756] points out that the use of IP security is not always feasible depending on network environments.
ステートレスアドレスの自動設定と重複アドレス検出の使用は、いくつかのサービス拒否攻撃の可能性を開きます。たとえば、任意のノードは暫定アドレスの隣接勧誘に応答でき、他のノードがアドレスを複製として拒否します。別の文書[RFC3756]は、これらの攻撃に関する詳細について説明しています。[RFC3756]は、ネットワーク環境によっては、IPセキュリティの使用が必ずしも実現可能ではないことを指摘する必要があります。
Thomas Narten and Susan Thompson were the authors of RFCs 1971 and 2462. For this revision of the RFC, Tatuya Jinmei was the sole editor.
Thomas NartenとSusan ThompsonはRFCS 1971と2462の著者でした。このRFCの改訂では、Tatuya Jinmeiが唯一の編集者でした。
The authors of RFC 2461 would like to thank the members of both the IPNG (which is now IPV6) and ADDRCONF working groups for their input. In particular, thanks to Jim Bound, Steve Deering, Richard Draves, and Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG of the "0 Lifetime Prefix Advertisement" denial-of-service attack vulnerability; this document incorporates changes that address this vulnerability.
RFC 2461の著者は、IPNG（これは現在IPv6）とAddRConfワーキンググループの両方に入力のために感謝します。特に、Jim Bound、Steve Theering、Richard Draves、およびErik Nordmarkのおかげで。また、「0ライフタイムプレフィックス広告」のWGに警告するためにJohn Gilmoreにもアクセスしています。この文書には、この脆弱性に対応する変更が組み込まれています。
A number of people have contributed to identifying issues with RFC 2461 and to proposing resolutions to the issues as reflected in this version of the document. In addition to those listed above, the contributors include Jari Arkko, James Carlson, Brian E. Carpenter, Gregory Daley, Elwyn Davies, Ralph Droms, Jun-ichiro Itojun Hagino, Christian Huitema, Suresh Krishnan, Soohong Daniel Park, Markku Savela, Pekka Savola, Hemant Singh, Bernie Volz, Margaret Wasserman, and Vlad Yasevich.
多くの人がRFC 2461の問題の特定を識別し、このバージョンの文書に反映されている問題に対する解決策を提案することに貢献しています。上記のものに加えて、貢献者には、Jari Arkko、James Carlson、Brian E. Carpenter、Gregory Daley、Elwyn Davies、Ralph Droms、Ralph Droms、itojun萩野淳一、クリシュナン、Swichong Daniel Park、Markku Savea、PekkaSavola、Hemant Singh、Bernie Volz、Margaret Wasserman、Vlad Yasevich。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「イーサネットネットワークを介したIPv6パケットの送信」、RFC 2464、1998年12月。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
【RFC4291】2006年2月、RFC4291。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6の隣接発見（IPv6）」、RFC 4861、2007年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROM、R.、BAND、J.、VOLZ、B、レモン、T.、Perkins、C、およびM. Carney、「IPv6の動的ホスト構成プロトコル（DHCPV6）」、RFC 3315、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R.およびS.Krishnan、「IPv6のステートレスアドレス自動設定のためのプライバシー拡張」、2007年9月、RFC 4941。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972] Aura、T.、「暗号的に生成されたアドレス（CGA）」、RFC 3972、2005年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Theering、S.、Fenner、W.、B. Haberman、「IPv6のマルチキャストリスナー発見（MLD）」、RFC 2710、1999年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] VIDA、R.およびL. Costa、「IPv6のMulticast Listener Discovery Version 2（MLDv2）」、RFC 3810、2004年6月。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3590] Haberman、B、「マルチキャストリスナー発見（MLD）プロトコル（MLD）プロトコルの送信元アドレス選択」、2003年9月、RFC 3590。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B.、およびP.Nikander、「Secure Neight Discovery（Send）」、RFC 3971、2005年3月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J.、E. Nordmark、「IPv6 Noiby Discovery（ND）信託モデルと脅威」、RFC 3756、2004年5月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]ショー、S。、「IPマルチキャストのためのホスト拡張」、STD 5、RFC 1112、1989年8月。
[IEEE802.11] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE STd 802.11, August 1999.
[IEEE802.11] IEEE、「無線LANメディアアクセス制御（MAC）および物理層（PHY）仕様」、ANSI / IEEE STD 802.11、1999年8月。
Determining whether a received multicast solicitation was looped back to the sender or actually came from another node is implementation-dependent. A problematic case occurs when two interfaces attached to the same link happen to have the same identifier and link-layer address, and they both send out packets with identical contents at roughly the same time (e.g., Neighbor Solicitations for a tentative address as part of Duplicate Address Detection messages). Although a receiver will receive both packets, it cannot determine which packet was looped back and which packet came from the other node simply by comparing packet contents (i.e., the contents are identical). In this particular case, it is not necessary to know precisely which packet was looped back and which was sent by another node; if one receives more solicitations than were sent, the tentative address is a duplicate. However, the situation may not always be this straightforward.
受信されたマルチキャスト勧誘が送信者にループバックされたか、実際に別のノードから来たかどうかを判断することは実装に依存します。同じリンクに接続されている2つのインターフェースが同じ識別子とリンク層アドレスを持つことがあり、それらは両方とも同時に同一の内容を持つパケットを送信する（たとえば、暫定アドレスの一部として隣接アドレスの義務的な勧誘など）を送信する場合に発生します。アドレス検出メッセージを複製）。受信機は両方のパケットを受信するが、どのパケットがループバックされたかを判断でき、パケットの内容を比較するだけで他のノードから来たのかを判断することはできない（すなわち、内容は同一）。この特定のケースでは、どのパケットがループバックされていて別のノードによって送信されたかを正確に知る必要はありません。送信されたよりも多くの勧誘を受け取った場合、仮アドレスは重複しています。しかし、状況は常にこれを簡単にするとは限りません。
The IPv4 multicast specification [RFC1112] recommends that the service interface provide a way for an upper-layer protocol to inhibit local delivery of packets sent to a multicast group that the sending host is a member of. Some applications know that there will be no other group members on the same host, and suppressing loopback prevents them from having to receive (and discard) the packets they themselves send out. A straightforward way to implement this facility is to disable loopback at the hardware level (if supported by the hardware), with packets looped back (if requested) by software. On interfaces in which the hardware itself suppresses loopbacks, a node running Duplicate Address Detection simply counts the number of Neighbor Solicitations received for a tentative address and compares them with the number expected. If there is a mismatch, the tentative address is a duplicate.
IPv4マルチキャスト仕様[RFC1112]は、サービスインタフェースが、送信ホストがメンバーであるマルチキャストグループに送信されたパケットのローカル配信を禁止する方法を提供することをお勧めします。同じホスト上に他のグループメンバーがないことを知っており、ループバックを抑制することを抑制して、それらが自分自身が送信しているパケットを受信（廃棄）することを防ぎます。この機能を実装する簡単な方法は、パケットがソフトウェアでループバック（要求された場合）でループバックを無効にすることです。ハードウェア自体がループバックを抑制するインターフェイスでは、重複アドレス検出を実行しているノードは、暫定アドレスに対して受信された隣接解消の数をカウントし、それらを予想される数と比較します。不一致がある場合、暫定アドレスは重複しています。
In those cases where the hardware cannot suppress loopbacks, however, one possible software heuristic to filter out unwanted loopbacks is to discard any received packet whose link-layer source address is the same as the receiving interface's. There is even a link-layer specification that requires that any such packets be discarded [IEEE802.11]. Unfortunately, use of that criteria also results in the discarding of all packets sent by another node using the same link-layer address. Duplicate Address Detection will fail on interfaces that filter received packets in this manner:
しかしながら、ハードウェアがループバックを抑制できない場合では、不要なループバックを除去するための1つの可能なソフトウェアヒューリスティックは、リンク層の送信元アドレスが受信インターフェースと同じである受信パケットを破棄することである。そのようなパケットが破棄されることを要求するリンク層仕様もあります[IEEE802.11]。残念ながら、その基準を使用すると、同じリンク層アドレスを使用して別のノードによって送信されたすべてのパケットを破棄します。この方法で受信したパケットをフィルタリングするインターフェイスでは、重複アドレス検出が失敗します。
o If a node performing Duplicate Address Detection discards received packets that have the same source link-layer address as the receiving interface, it will also discard packets from other nodes that also use the same link-layer address, including Neighbor Advertisement and Neighbor Solicitation messages required to make Duplicate Address Detection work correctly. This particular problem can be avoided by temporarily disabling the software suppression of loopbacks while a node performs Duplicate Address Detection, if it is possible to disable the suppression.
o重複アドレス検出を実行するノードが受信側インタフェースと同じソースリンク層アドレスを持つ受信パケットを廃棄する場合は、近隣アドバタイズメントとネイバー勧誘メッセージも含む、同じリンクレイヤアドレスも使用する他のノードからパケットを破棄します。無数のアドレス検出を正しく作成するために必要です。この特定の問題は、抑制を無効にすることが可能であれば、ノードが重複アドレス検出を実行しながら、ループバックのソフトウェア抑制を一時的に無効にすることによって回避することができる。
o If a node that is already using a particular IP address discards received packets that have the same link-layer source address as the interface, it will also discard Duplicate Address Detection-related Neighbor Solicitation messages sent by another node that also use the same link-layer address. Consequently, Duplicate Address Detection will fail, and the other node will configure a non-unique address. Since it is generally impossible to know when another node is performing Duplicate Address Detection, this scenario can be avoided only if software suppression of loopback is permanently disabled.
o 特定のIPアドレスを使用しているノードがインターフェイスと同じリンクレイヤーの送信元アドレスを持つ受信パケットを破棄する場合は、同じリンクを使用する別のノードによって送信された重複アドレス検出関連の環境勧誘メッセージも廃棄されます。レイヤアドレス。その結果、重複アドレス検出が失敗し、他のノードは固有の非一意のアドレスを構成します。他のノードが重複アドレス検出を実行しているときに知ることは一般的には不可能であるので、このシナリオは、ループバックのソフトウェアの抑制が永久に無効になっている場合にのみ回避できます。
Thus, to perform Duplicate Address Detection correctly in the case where two interfaces are using the same link-layer address, an implementation must have a good understanding of the interface's multicast loopback semantics, and the interface cannot discard received packets simply because the source link-layer address is the same as the interface's. It should also be noted that a link-layer specification can conflict with the condition necessary to make Duplicate Address Detection work.
したがって、2つのインタフェースが同じリンク層アドレスを使用している場合に重複アドレス検出を正しく実行するには、実装はインタフェースのマルチキャストループバックセマンティクスをよく理解しておく必要があり、ソースリンクが単に受信パケットを破棄することはできません。レイヤアドレスはインターフェイスと同じです。リンク層仕様は、重複アドレス検出作業を行うのに必要な条件と矛盾することができることにも留意されたい。
o Changed document to use term "interface identifier" rather than "interface token" for consistency with other IPv6 documents.
o 他のIPv6文書との一貫性のために、「インターフェイストークン」ではなく「インターフェイス識別子」を使用する文書を変更しました。
o Clarified definition of deprecated address to make clear it is OK to continue sending to or from deprecated addresses.
o 明確にするための廃止予定アドレスの定義を明確にしたことは、廃止予定のアドレスへのまたは廃止予定のアドレスへの送信を続けることができます。
o Added rules to Section 5.5.3 Router Advertisement processing to address potential denial-of-service attack when prefixes are advertised with very short Lifetimes.
o プレフィックスが非常に短い寿命で宣伝されている場合の潜在的なサービス拒否攻撃をアドレス指定するためのセクション5.5.3ルータ広告処理の規則を追加しました。
o Clarified wording in Section 5.5.4 to make clear that all upper layer protocols must process (i.e., send and receive) packets sent to deprecated addresses.
o 5.5.4セクション5.5.4の文言は、すべての上層プロトコルが廃止予定のアドレスに送信されたパケットを処理する（すなわち送受信）する必要があることを明確にした。
Major changes that can affect existing implementations:
既存の実装に影響を与える可能性のある主な変更点：
o Specified that a node performing Duplicate Address Detection delay joining the solicited-node multicast group, not just delay sending Neighbor Solicitations, explaining the detailed reason.
o 要請ノードのマルチキャストグループに結合したノードが、隣接勧誘を遅らせるだけでなく、詳細な理由を説明するだけではなく、依頼されたノード検出遅延を遅らせることを指定した。
o Added a requirement for a random delay before sending Neighbor Solicitations for Duplicate Address Detection if the address being checked is configured by a multicasted Router Advertisements.
o チェックされているアドレスがマルチキャストされたルータ広告によって構成されている場合、重複アドレス検出のために隣接勧誘を送信する前に、ランダムな遅延の要件を追加しました。
o Clarified that on failure of Duplicate Address Detection, IP network operation should be disabled and that the rule should apply when the hardware address is supposed to be unique.
o 重複アドレス検出の失敗時に、IPネットワーク操作を無効にする必要があり、ハードウェアアドレスが一意であると思われる場合にそのルールが適用されるべきであることを明らかにしました。
Major clarifications:
主な説明：
o Clarified how the length of interface identifiers should be determined, described the relationship with the prefix length advertised in Router Advertisements, and avoided using a particular length hard-coded in this document.
o インタフェース識別子の長さを決定する方法を明確にし、ルータ広告で広告されているプレフィックス長との関係を説明し、この文書でハードコードされた特定の長さを使用して回避されました。
o Clarified the processing of received neighbor advertisements while performing Duplicate Address Detection.
o 重複アドレス検出を実行しながら、受信したネイバーアドバタイズメントの処理を明らかにしました。
o Removed the text regarding the M and O flags, considering the maturity of implementations and operational experiences. ManagedFlag and OtherConfigFlag were removed accordingly. (Note that this change does not mean the use of these flags is deprecated.)
o 実装の成熟度と運用経験を考慮して、MとOフラグに関するテキストを削除しました。ManagedFlagとOtherConfigFlagがそれに応じて削除されました。（この変更はこれらのフラグの使用を意味するわけではないことに注意してください。）
o Avoided the wording of "stateful configuration", which is known to be quite confusing, and simply used "DHCPv6" wherever appropriate.
o 非常に混乱していることが知られている「ステートフル構成」の表現を避け、適切な場所に「DHCPV6」を使用して使用しました。
o Recommended to perform Duplicate Address Detection for all unicast addresses more strongly, considering a variety of different interface identifiers, while keeping care of existing implementations.
o 既存の実装の世話をしながら、さまざまな異なるインターフェイス識別子を考慮して、すべてのユニキャストアドレスの重複アドレス検出をより強く実行することをお勧めします。
o Clarified wording in Section 5.5.4 to make clear that a deprecated address specified by an application can be used for any communication.
o アプリケーションで指定された廃止予定アドレスをコミュニケーションに使用できることを明確にするために、セクション5.5.4の文言を明確にしました。
o Clarified the prefix check described in Section 5.5.3 using more appropriate terms and that the check is done against the prefixes of addresses configured by stateless autoconfiguration.
o 5.5.3項で説明されているプレフィックスチェックをより適切な用語を使用して、ステートレス自動設定によって設定されたアドレスの接頭辞に対してチェックが行われました。
o Changed the references to the IP security Authentication Header to references to RFC 3971 (Secure Neighbor Discovery). Also revised the Security Considerations section with a reference to RFC 3756.
o IPセキュリティ認証ヘッダーへの参照をRFC 3971（Secure Neigvision Discovery）への参照に変更しました。また、RFC 3756への参照でセキュリティ上の考慮事項セクションを修正しました。
o Added a note when an implementation uses stable storage for autoconfigured addresses.
o 実装が自動設定アドレスに安定したストレージを使用するときにメモを追加しました。
o Added consideration about preference between inconsistent information sets, one from a secured source and the other learned without protection.
o 矛盾した情報セットの間の好みに関する考慮事項は、保護されたソースから1つとされ、もう1つは保護なしで学習されました。
Other miscellaneous clarifications:
その他の雑多な説明：
o Removed references to site-local and revised wording around the keyword.
o キーワードの周囲のサイトローカルおよび改訂された文言への参照を削除しました。
o Removed redundant code in denial-of-service protection in Section 5.5.3.
o セクション5.5.3のサービス拒否保護で冗長コードを削除しました。
o Clarified that a unicasted Neighbor Solicitation or Advertisement should be discarded while performing Duplicate Address Detection.
o 重複アドレス検出を実行しながら、ユニキャストネイバー勧誘または広告を破棄する必要があることを明確にした。
o Noted in Section 5.3 that an interface can be considered as becoming enabled when a wireless access point changes.
o 無線アクセスポイントが変わったときにインターフェイスを有効にすると考えることができると考えることができるのは、セクション5.3に記載されています。
Authors' Addresses
著者の住所
Susan Thomson Cisco Systems
スーザントムソンシスコシステムズ
EMail: sethomso@cisco.com
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA
Thomas Narten IBM Corporation P.O.Box 12195 Research Triangle Park、NC 27709-2195 USA
Phone: +1 919-254-7798
EMail: narten@us.ibm.com
Tatuya Jinmei Corporate Research & Development Center, Toshiba Corporation 1 Komukai Toshiba-cho, Saiwai-ku Kawasaki-shi, Kanagawa 212-8582 Japan
東芝株式会社タトゥヤジンメイコーポレートリサーチ＆開発センター1小山仁東芝町矢井区川崎市神奈川県212-8582日本
Phone: +81 44-549-2230
EMail: jinmei@isl.rdc.toshiba.co.jp
Full Copyright Statement
完全著作権宣言
Copyright (C) The IETF Trust (2007).
著作権（c）IETF Trust（2007）。
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, THE IETF TRUST 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.
この文書および本明細書に含まれる情報は、「現状の」基準であり、寄与者、統治、または後援されている、または（いずれも）、インターネット社会、IETF信託およびインターネットエンジニアリングのタスク力を否定する。本明細書における情報の使用が特定の目的のための権利または黙示的な保証を侵害しないことを保証するが、定義または暗示されていない保証、または暗示されていない。
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は、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事務局へのIETF事務局と利用可能なライセンスの保証のコピー、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。IETFオンラインIPRリポジトリからhttp://www.ietf.org/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に情報を宛先に宛ててください。