[要約] RFC 4861はIPv6における隣接ディスカバリのプロトコルであり、ネットワーク上のノード同士の通信を効率的に行うための仕組みを提供します。このRFCの目的は、IPv6ネットワークでのノードの自己設定と隣接関係の確立を支援することです。
Network Working Group T. Narten
Request for Comments: 4861 IBM
Obsoletes: 2461 E. Nordmark
Category: Standards Track Sun Microsystems
W. Simpson
Daydreamer
H. Soliman
Elevate Technologies
September 2007
Neighbor Discovery for IP version 6 (IPv6)
IPバージョン6の隣接発見（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 Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.
このドキュメントはIPバージョン6のネイバー・ディスカバリー・プロトコルを指定します。同じリンク上のIPv6ノードは、互いのリンク層アドレスを特定し、ルーターを検索し、アクティブへのパスに関する到達可能性情報を維持するために、互いのリンク層アドレスを決定するためにネイバー・ディスカバリーを使用します。隣人。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
2.1. General ....................................................4
2.2. Link Types .................................................8
2.3. Addresses ..................................................9
2.4. Requirements ..............................................10
3. Protocol Overview ..............................................10
3.1. Comparison with IPv4 ......................................14
3.2. Supported Link Types ......................................16
3.3. Securing Neighbor Discovery Messages ......................18
4. Message Formats ................................................18
4.1. Router Solicitation Message Format ........................18
4.2. Router Advertisement Message Format .......................19
4.3. Neighbor Solicitation Message Format ......................22
4.4. Neighbor Advertisement Message Format .....................23
4.5. Redirect Message Format ...................................26
4.6. Option Formats ............................................28
4.6.1. Source/Target Link-layer Address ...................28
4.6.2. Prefix Information .................................29
4.6.3. Redirected Header ..................................31
4.6.4. MTU ................................................32
5. Conceptual Model of a Host .....................................33
5.1. Conceptual Data Structures ................................33
5.2. Conceptual Sending Algorithm ..............................36
5.3. Garbage Collection and Timeout Requirements ...............37
6. Router and Prefix Discovery ....................................38
6.1. Message Validation ........................................39
6.1.1. Validation of Router Solicitation Messages .........39
6.1.2. Validation of Router Advertisement Messages ........39
6.2. Router Specification ......................................40
6.2.1. Router Configuration Variables .....................40
6.2.2. Becoming an Advertising Interface ..................45
6.2.3. Router Advertisement Message Content ...............45
6.2.4. Sending Unsolicited Router Advertisements ..........47
6.2.5. Ceasing To Be an Advertising Interface .............47
6.2.6. Processing Router Solicitations ....................48
6.2.7. Router Advertisement Consistency ...................50
6.2.8. Link-local Address Change ..........................50
6.3. Host Specification ........................................51
6.3.1. Host Configuration Variables .......................51
6.3.2. Host Variables .....................................51
6.3.3. Interface Initialization ...........................52
6.3.4. Processing Received Router Advertisements ..........53
6.3.5. Timing out Prefixes and Default Routers ............56
6.3.6. Default Router Selection ...........................56
6.3.7. Sending Router Solicitations .......................57
7. Address Resolution and Neighbor Unreachability Detection .......59
7.1. Message Validation ........................................59
7.1.1. Validation of Neighbor Solicitations ...............59
7.1.2. Validation of Neighbor Advertisements ..............60
7.2. Address Resolution ........................................60
7.2.1. Interface Initialization ...........................61
7.2.2. Sending Neighbor Solicitations .....................61
7.2.3. Receipt of Neighbor Solicitations ..................62
7.2.4. Sending Solicited Neighbor Advertisements ..........63
7.2.5. Receipt of Neighbor Advertisements .................64
7.2.6. Sending Unsolicited Neighbor Advertisements ........66
7.2.7. Anycast Neighbor Advertisements ....................67
7.2.8. Proxy Neighbor Advertisements ......................68
7.3. Neighbor Unreachability Detection .........................68
7.3.1. Reachability Confirmation ..........................69
7.3.2. Neighbor Cache Entry States ........................70
7.3.3. Node Behavior ......................................71
8. Redirect Function ..............................................73
8.1. Validation of Redirect Messages ...........................74
8.2. Router Specification ......................................75
8.3. Host Specification ........................................76
9. Extensibility - Option Processing ..............................76
10. Protocol Constants ............................................78
11. Security Considerations .......................................79
11.1. Threat Analysis ..........................................79
11.2. Securing Neighbor Discovery Messages .....................81
12. Renumbering Considerations ....................................81
13. IANA Considerations ...........................................83
14. References ....................................................84
14.1. Normative References .....................................84
14.2. Informative References ...................................84
Appendix A: Multihomed Hosts ......................................87
Appendix B: Future Extensions .....................................88
Appendix C: State Machine for the Reachability State ..............89
Appendix D: Summary of IsRouter Rules .............................91
Appendix E: Implementation Issues .................................92
Appendix F: Changes from RFC 2461 .................................94
Acknowledgments ...................................................95
This specification defines the Neighbor Discovery (ND) protocol for Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use Neighbor Discovery to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf. Finally, nodes use the protocol to actively keep track of which neighbors are reachable and which are not, and to detect changed link-layer addresses. When a router or the path to a router fails, a host actively searches for functioning alternates.
この仕様は、インターネットプロトコルバージョン6（IPv6）の近隣探索（ND）プロトコルを定義しています。ノード（ホストとルータ）ネイバーディスカバリを使用して、接続されているリンクに存在することが知られているネイバーのリンクレイヤアドレスを決定し、無効になるキャッシュ値をすばやくパージします。ホストはまたネイバーディスカバリを使用して、パケットを代表して転送しても構わないと思っている隣接ルータを見つけます。最後に、ノードはプロトコルを使用して、どのネイバーが到達可能かつ到達可能であり、変更されたリンク層アドレスを検出するために積極的に追跡します。ルータまたはルータへのパスが失敗した場合、ホストは機能的に機能を検索します。
Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). The services described in this document that are not directly dependent on multicast, such as Redirects, Next-hop determination, Neighbor Unreachability Detection, etc., are expected to be provided as specified in this document. The details of how one uses ND on NBMA links are addressed in [IPv6-NBMA]. In addition, [IPv6-3GPP] and[IPv6-CELL] discuss the use of this protocol over some cellular links, which are examples of NBMA links.
それ以外の場合を指定しない限り（特定のリンクタイプを介して動作IPをカバーする文書内で）このドキュメントはすべてのリンクタイプに適用されます。ただし、NDはそのサービスの一部にリンクレイヤマルチキャストを使用するため、一部のリンクタイプ（非ブロードキャストマルチアクセス（NBMA）リンクなど）、それらのサービスを実装するための代替プロトコルまたはメカニズムが指定されます（特定のリンクタイプ上のIPの動作をカバーする適切な文書で。この文書に直接依存していないサービスは、リダイレクト、ネクストホップの決定、近隣の到達不能検出などのようなマルチキャストに直接依存しているサービスが、この文書で指定されているように提供される予定です。NBMAリンクでNDを使用する方法の詳細は[IPv6-NBMA]でアドレス指定されます。さらに、[IPv6-3GPP]および[IPv6-Cell]は、NBMAリンクの例であるいくつかの細胞間リンクを介したこのプロトコルの使用について説明します。
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という用語は、あいまいさを避けるために必要なコンテキストでのみ使用されます。
ICMP - Internet Control Message Protocol for the Internet Protocol Version 6. The terms ICMPv4 and ICMPv6 are used only in contexts where necessary to avoid ambiguity.
ICMP - インターネットプロトコルバージョン6のインターネット制御メッセージプロトコルは、あいまいさを避けるために必要なコンテキストでのみ使用されます。
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-layer (or lower-layer) protocols being "tunneled" over (i.e., encapsulated in) IP such as Internetwork Packet Exchange (IPX), AppleTalk, or IP itself.
上位層 - IPのすぐ上のプロトコルレイヤー。例としては、TCPやUDPなどのトランスポートプロトコル、ICMPなどの制御プロトコル、Internelied Packet Exchangeなどの「トンネリングされたインターネット」IP（In In In In）IPなどのインターネット層（または下位）（IPX）、AppleTalk、または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 as well as Internet-layer (or higher-layer) "tunnels", such as tunnels over IPv4 or IPv6 itself.
リンク - ノードをリンク層、すなわちIPの直下のレイヤで通信できる通信機能または媒体。例は、イーサネット（シンプルまたはブリッジ付き）、PPPリンク、X.25、フレームリレー、またはATMネットワーク、およびIPv4またはIPv6自体の上のトンネルなどのインターネット層（または上位層）の「トンネル」です。
interface - a node's attachment to a link.
インターフェース - リンクへのノードの添付ファイル。
neighbors - nodes attached to the same link.
隣接者 - 同じリンクに接続されているノード。
address - an IP-layer identifier for an interface or a set of interfaces.
address - インタフェースまたは一連のインターフェイスのIP層識別子。
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 [ADDR-ARCH].
Anycast Address - 一連のインターフェイス（通常は異なるノードに属する）の識別子。Anycastアドレスに送信されたパケットは、そのアドレスによって識別されるインターフェイスの1つ（ルーティングプロトコルの距離の尺度に従って）によって識別されます。[ADDR-ARCH]を参照してください。
Note that an anycast address is syntactically indistinguishable from a unicast address. Thus, nodes sending packets to anycast addresses don't generally know that an anycast address is being used. Throughout the rest of this document, references to unicast addresses also apply to anycast addresses in those cases where the node is unaware that a unicast address is actually an anycast address.
エニーキャストアドレスは、ユニキャストアドレスと構文的に区別がつかないことに注意してください。したがって、パケットをエニーキャストアドレスに送信するノードは、一般に、エニーキャストアドレスが使用されていることを知らない。このドキュメントの残りの部分を通して、ユニキャストアドレスへの参照は、ノードが非公開アドレスが実際にはAnycastアドレスであることを認識していない場合のエニーキャストアドレスにも適用されます。
prefix - a bit string that consists of some number of initial bits of an address.
prefix - アドレスのいくつかの初期ビットからなるビット文字列。
link-layer address - a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links.
リンク層アドレス - インタフェースのリンクレイヤ識別子。例としては、イーサネットリンク用のIEEE 802アドレスがあります。
on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on-link if:
on-link - 指定されたリンク上のインターフェイスに割り当てられているアドレス。次の場合、ノードはアドレスをオンリンクにすると考えています。
- it is covered by one of the link's prefixes (e.g., as indicated by the on-link flag in the Prefix Information option), or
- それはリンクのプレフィックスの1つ（例えば、接頭辞情報オプションのオンリンクフラグによって示されるように）の1つによってカバーされます。
- a neighboring router specifies the address as the target of a Redirect message, or
- 隣接ルータは、リダイレクトメッセージのターゲットとしてアドレスを指定します。
- a Neighbor Advertisement message is received for the (target) address, or
- （ターゲット）アドレスに対して、ネイバーアドバタイズメントメッセージが受信されます。
- any Neighbor Discovery message is received from the address.
- アドレスから隣接検出メッセージが受信されます。
off-link - the opposite of "on-link"; an address that is not assigned to any interfaces on the specified link.
オフリンク - 「オンリンク」の反対。指定されたリンクの任意のインタフェースに割り当てられていないアドレス。
longest prefix match - the process of determining which prefix (if any) in a set of prefixes covers a target address. A target address is covered by a prefix if all of the bits in the prefix match the left-most bits of the target address. When multiple prefixes cover an address, the longest prefix is the one that matches.
最長プレフィックスの一致 - プレフィックスのセット内のプレフィックス（もしあれば）がターゲットアドレスをカバーするプロセス。接頭辞内のすべてのビットがターゲットアドレスの左端のビットと一致する場合、ターゲットアドレスはプレフィックスでカバーされます。複数のプレフィックスがアドレスをカバーすると、最長の接頭辞は一致するものです。
reachability - whether or not the one-way "forward" path to a neighbor is functioning properly. In particular, whether packets sent to a neighbor are reaching the IP layer on the neighboring machine and are being processed properly by the receiving IP layer. For neighboring routers, reachability means that packets sent by a node's IP layer are delivered to the router's IP layer, and the router is indeed forwarding packets (i.e., it is configured as a router, not a host). For hosts, reachability means that packets sent by a node's IP layer are delivered to the neighbor host's IP layer.
到達可能性 - 隣接への一方向の「転送」パスが正しく機能しているかどうか。特に、隣接に送信されたパケットが隣接機のIP層に到達し、受信側IP層によって適切に処理されているか。隣接ルータの場合、到達可能性は、ノードのIPレイヤによって送信されたパケットがルータのIPレイヤに配信され、ルータは実際にパケットの転送パケットを転送していることを意味します（すなわち、ホストではなくルータとして構成されています）。ホストの場合、到達可能性は、ノードのIPレイヤによって送信されたパケットがネイバーホストのIPレイヤに配信されることを意味します。
packet - an IP header plus payload.
パケット - IPヘッダーとペイロード。
link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one transmission unit over a link.
リンクMTU - 最大伝送ユニット、すなわち、1つの送信ユニット内でリンクを介して伝送することができる最大送信ユニット、すなわち最大パケットサイズ。
target - an address about which address resolution information is sought, or an address that is the new first hop when being redirected.
ターゲット - アドレス解決情報が求められているアドレス、またはリダイレクトされたときの新しいファーストホップであるアドレス。
proxy - a node that responds to Neighbor Discovery query messages on behalf of another node. A router acting on behalf of a mobile node that has moved off-link could potentially act as a proxy for the mobile node.
proxy - 別のノードに代わってネイバーディスカバリークエリメッセージに応答するノード。オフリンクを移動したモバイルノードを代表して行動するルータは、モバイルノードのプロキシとして機能する可能性があります。
ICMP destination unreachable indication - an error indication returned to the original sender of a packet that cannot be delivered for the reasons outlined in [ICMPv6]. If the error occurs on a node other than the node originating the packet, an ICMP error message is generated. If the error occurs on the originating node, an implementation is not required to actually create and send an ICMP error packet to the source, as long as the upper-layer sender is notified through an appropriate mechanism (e.g., return value from a procedure call). Note, however, that an implementation may find it convenient in some cases to return errors to the sender by taking the offending packet, generating an ICMP error message, and then delivering it (locally) through the generic error-handling routines.
ICMP宛先到達不能表示 - [ICMPv6]で概説されている理由で配信できないパケットの元の送信者に返されたエラー指示。パケットを発信するノード以外のノードでエラーが発生した場合は、ICMPエラーメッセージが生成されます。エラーが発生したノードでエラーが発生した場合、上層の送信者が適切なメカニズムを介して通知されている限り、実際にICMPエラーパケットをソースに作成して送信するために実装が必要ではありません（例：プロシージャコールからの戻り値）。）。ただし、実装には、問題が発生し、ICMPエラーメッセージを生成し、その後一般的なエラー処理ルーチンを介して（ローカルに）配信することによって、送信者にエラーを返す場合があります。
random delay - when sending out messages, it is sometimes necessary to delay a transmission for a random amount of time in order to prevent multiple nodes from transmitting at exactly the same time, or to prevent long-range periodic transmissions from synchronizing with each other [SYNC]. When a random component is required, a node calculates the actual delay in such a way that the computed delay forms a uniformly distributed random value that falls between the specified minimum and maximum delay times. The implementor must take care to ensure that the granularity of the calculated random component and the resolution of the timer used are both high enough to ensure that the probability of multiple nodes delaying the same amount of time is small.
ランダムな遅延 - メッセージを送信するときには、複数のノードが正確に同時に送信されるのを防ぐため、または長距離周期的な送信を互いに同期させるのを防ぐために、ランダムな時間の送信を遅延させる必要がある場合があります。同期します。ランダムなコンポーネントが必要な場合、ノードは、計算された遅延が指定された最小値と最大遅延時間の間にある均一に分布したランダム値を形成するように実際の遅延を計算します。計算されたランダム成分の粒度と使用されるタイマーの解像度が同じ時間を遅らせる確率が小さいことを確実にするのに十分に高いことを確実にするために、実装者は注意しなければならない。
random delay seed - if a pseudo-random number generator is used in calculating a random delay component, the generator should be initialized with a unique seed prior to being used. Note that it is not sufficient to use the interface identifier alone as the seed, since interface identifiers will not always be unique. To reduce the probability that duplicate interface identifiers cause the same seed to be used, the seed should be calculated from a variety of input sources (e.g., machine components) that are likely to be different even on identical "boxes". For example, the seed could be formed by combining the CPU's serial number with an interface identifier. Additional information on randomness and random number generation can be found in [RAND].
ランダム遅延シード - 擬似乱数発生器がランダムな遅延成分の計算に使用される場合、ジェネレータは使用される前に固有のシードで初期化されるべきです。インターフェイス識別子は常に一意ではないため、シードとしてインターフェイス識別子のみを使用するのに十分ではありません。重複したインターフェース識別子が同じシードを使用する確率を減らすために、シードは、同じ「ボックス」でさえも異なる可能性があるさまざまな入力ソース（例えば、機械部品）から計算する必要があります。例えば、シードは、CPUのシリアル番号をインターフェース識別子と組み合わせることによって形成することができる。ランダム性と乱数生成に関する追加情報は[Rand]にあります。
Different link layers have different properties. The ones of concern to Neighbor Discovery are:
異なるリンク層は異なる特性を有する。近隣探索への関心事は次のとおりです。
multicast capable - a link that supports a native mechanism at the link layer for sending packets to all (i.e., broadcast) or a subset of all neighbors.
マルチキャスト対応 - リンク層でのネイティブメカニズムをサポートするリンクAすべて（すなわち、ブロードキャスト）またはすべての隣接者のサブセットを送信する。
point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast capability and a link-local address.
point-to-point - 正確に2つのインタフェースを接続するリンク。ポイントツーポイントリンクは、マルチキャスト機能とリンクローカルアドレスを持つと仮定されます。
non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, but that does not support a native form of multicast or broadcast (e.g., X.25, ATM, frame relay, etc.). Note that all link types (including NBMA) are expected to provide multicast service for applications that need it (e.g., using multicast servers). However, it is an issue for further study whether ND should use such facilities or an alternate mechanism that provides the equivalent multicast capability for ND.
非ブロードキャストマルチアクセス（NBMA） - 2つより多いインターフェイスが接続できるリンクは、ネイティブ形式のマルチキャストまたはブロードキャスト（例えば、X.25、ATM、フレームリレーなど）をサポートしていません。すべてのリンクタイプ（NBMAを含む）は、それを必要とするアプリケーションのマルチキャストサービス（例えば、マルチキャストサーバを使用して）提供されることに注意してください。しかしながら、NDがそのような施設を使用すべきか、またはNDのための同等のマルチキャスト機能を提供する代替メカニズムであるかどうかをさらに検討することは問題である。
shared media - a link that allows direct communication among a number of nodes, but attached nodes are configured in such a way that they do not have complete prefix information for all on-link destinations. That is, at the IP level, nodes on the same link may not know that they are neighbors; by default, they communicate through a router. Examples are large (switched) public data networks such as Switched Multimegabit Data Service (SMDS) and Broadband Integrated Services Digital Network (B-ISDN). Also known as "large clouds". See [SH-MEDIA].
共有メディア - いくつかのノード間の直接通信を可能にするリンクであるが、接続されているノードは、すべてのオンリンク先に対して完全な接頭辞情報を持っていないように構成されています。つまり、IPレベルでは、同じリンク上のノードは、それらが隣接することを知らないかもしれません。デフォルトでは、それらはルータを介して通信します。例としては、スイッチドマルチメガビットデータサービス（SMDS）やブロードバンド統合サービスデジタルネットワーク（B-ISDN）などの大型（切り替え）パブリックデータネットワークがあります。「大雲」とも呼ばれます。[SHメディア]を参照してください。
variable MTU - a link that does not have a well-defined MTU (e.g., IEEE 802.5 token rings). Many links (e.g., Ethernet) have a standard MTU defined by the link-layer protocol or by the specific document describing how to run IP over the link layer.
変数MTU - 明確に定義されたMTU（例えば、IEEE 802.5トークンリング）を持たないリンク。多くのリンク（例えば、イーサネット）は、リンク層プロトコルによって定義された標準のMTU、またはリンク層を介してIPを実行する方法を記述する特定の文書によって定義される標準のMTUを有する。
asymmetric reachability - a link where non-reflexive and/or non-transitive reachability is part of normal operation. (Non-reflexive reachability means packets from A reach B, but packets from B don't reach A. Non-transitive reachability means packets from A reach B, and packets from B reach C, but packets from A don't reach C.) Many radio links exhibit these properties.
非対称到達可能性 - 非反射性および/または非推移的な到達可能性が通常の動作の一部であるリンク。（反射不全到達可能性は、到達Bからのパケットを意味しますが、BからのパケットはAに達しません。）多くの無線リンクはこれらの特性を示します。
Neighbor Discovery makes use of a number of different addresses defined in [ADDR-ARCH], including:
近隣探索は、以下を含む[ADDR-ARCH]で定義されているさまざまなアドレスを使用します。
all-nodes multicast address - the link-local scope address to reach all nodes, FF02::1.
All Nodesマルチキャストアドレス - すべてのノード、FF02 :: 1に到達するためのリンクローカルスコープアドレス。
all-routers multicast address - the link-local scope address to reach all routers, FF02::2.
All-Routersマルチキャストアドレス - すべてのルータ、FF02 :: 2すべてのルータに到達するためのリンクローカルスコープアドレス。
solicited-node multicast address - a link-local scope multicast address that is computed as a function of the solicited target's address. The function is described in [ADDR-ARCH]. The function is chosen so that IP addresses that differ only in the most significant bits, e.g., due to multiple prefixes associated with different providers, will map to the same solicited-node address thereby reducing the number of multicast addresses a node must join at the link layer.
勧誘ノードマルチキャストアドレス - 要請されたターゲットのアドレスの関数として計算されるリンクローカルスコープマルチキャストアドレス。機能は[ADDR-ARCH]に記載されています。関数は、例えば異なるプロバイダに関連付けられている複数のプレフィックスのために最も重要なビット内でのみ異なるIPアドレスが、同じ勧誘ノードアドレスにマッピングされるように選択され、それによってノードが結合しなければならないマルチキャストアドレスの数を減らすように選択される。リンク層
link-local address - a unicast address having link-only scope that can be used to reach neighbors. All interfaces on routers MUST have a link-local address. Also, [ADDRCONF] requires that interfaces on hosts have a link-local address.
link-local address - リンク専用スコープを持つユニキャストアドレスは、隣接者に到達するために使用できます。ルータのすべてのインターフェイスにはリンクローカルアドレスが必要です。また、[addrconf]ホスト上のインタフェースにリンクローカルアドレスが必要です。
unspecified address - a reserved address value that indicates the lack of an address (e.g., the address is unknown). It is never used as a destination address, but may be used as a source address if the sender does not (yet) know its own address (e.g., while verifying an address is unused during stateless address autoconfiguration [ADDRCONF]). The unspecified address has a value of 0:0:0:0:0:0:0:0.
指定されていないアドレス - アドレスの欠如を示す予約アドレス値（例えば、アドレスは不明です）。それは宛先アドレスとして使用されることはありませんが、送信者が（まだ）独自のアドレスを知らない場合（例えば、ステートレスアドレス自動設定のaddrconf]の間には未使用の）。未指定アドレスには、0：0：0：0：0：0：0の値があります。
Note that this specification does not strictly comply with the consistency requirements in [ADDR-SEL] for the scopes of source and destination addresses. It is possible in some cases for hosts to use a source address of a larger scope than the destination address in the IPv6 header.
この仕様は、ソースアドレスと宛先アドレスのスコープの[ADDR-SEL]の整合性要件に厳密に準拠していません。場合によっては、IPv6ヘッダーの宛先アドレスよりも大きなスコープの送信元アドレスを使用することが考えられます。
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 [KEYWORDS].
この文書に記載されている場合は、この文書に記載されている場合は、必要ではなく、必ずしも、推奨されてはいけません。
This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document.
この文書はまた、実装がシステム管理者が変更できるようにする必要があるプロトコル動作と外部変数を記述するために内部概念変数を使用します。特定の変数名、それらの値の変更、およびプロトコルの動作を説明するためにプロトコル動作の影響をどのように変更する方法。その外部的な動作がこの文書で説明されているものと一致する限り、実装はここで説明されている正確な形式でそれらを持つ必要はありません。
This protocol solves a set of problems related to the interaction between nodes attached to the same link. It defines mechanisms for solving each of the following problems:
このプロトコルは、同じリンクに添付されているノード間の相互作用に関連する一連の一連の問題を解決します。次の各問題を解決するためのメカニズムを定義します。
Router Discovery: How hosts locate routers that reside on an attached link.
ルーター検出：ホストは添付リンクに存在するルータを見つけます。
Prefix Discovery: How hosts discover the set of address prefixes that define which destinations are on-link for an attached link. (Nodes use prefixes to distinguish destinations that reside on-link from those only reachable through a router.)
接頭辞検出：どの宛先が接続されているリンクのオンリンクであるかを定義するアドレスプレフィックスのセットをホストに検出する方法。（ノードは、ルータを介して到達可能なものからオンリンクに存在する宛先を区別するためのプレフィックスを使用します。）
Parameter Discovery: How a node learns link parameters (such as the link MTU) or Internet parameters (such as the hop limit value) to place in outgoing packets.
パラメータ検出：ノードが、リンクパラメータ（リンクMTUなど）またはインターネットパラメータ（ホップ制限値など）を発信パケットに配置する方法。
Address Autoconfiguration: Introduces the mechanisms needed in order to allow nodes to configure an address for an interface in a stateless manner. Stateless address autoconfiguration is specified in [ADDRCONF].
アドレス自動設定：ノードがステートレス方式でインターフェイスのアドレスを設定できるようにするために必要なメカニズムを導入します。ステートレスアドレスの自動設定は[ADDRCONF]で指定されています。
Address resolution: How nodes determine the link-layer address of an on-link destination (e.g., a neighbor) given only the destination's IP address.
アドレス解決：ノードは、宛先のIPアドレスのみを考慮して、ノードはオンリンク先のリンク先のアドレス（例えば、隣接）をどのように決定するか。
Next-hop determination: The algorithm for mapping an IP destination address into the IP address of the neighbor to which traffic for the destination should be sent. The next-hop can be a router or the destination itself.
ネクストホップ決定：IP宛先アドレスを宛先のトラフィックのIPアドレスにマッピングするためのアルゴリズム。ネクストホップはルータまたは宛先自体にすることができます。
Neighbor Unreachability Detection: How nodes determine that a neighbor is no longer reachable. For neighbors used as routers, alternate default routers can be tried. For both routers and hosts, address resolution can be performed again.
近隣の到達不可能な検出：ノードがネイバーがもう到達できないと判断する方法。ルータとして使用される隣接者の場合、代替のデフォルトルータを試すことができます。ルータとホストの両方で、アドレス解決を再度実行できます。
Duplicate Address Detection: How a node determines whether or not an address it wishes to use is already in use by another node.
重複アドレス検出：ノードが使用したいアドレスがすでに別のノードによって使用されているかどうかを判断する方法。
Redirect: How a router informs a host of a better first-hop node to reach a particular destination.
リダイレクト：特定の宛先に到達するために、ルータがホストのより良いファーストホップノードをどのように通知するか。
Neighbor Discovery defines five different ICMP packet types: A pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and Neighbor Advertisements messages, and a Redirect message. The messages serve the following purpose:
近隣探索は、5つの異なるICMPパケットタイプを定義します.Luterの勧誘とルータの広告メッセージ、一対の隣接勧誘とネイバー広告メッセージ、およびリダイレクトメッセージ。メッセージは次の目的を果たします。
Router Solicitation: When an interface becomes enabled, hosts may send out Router Solicitations that request routers to generate Router Advertisements immediately rather than at their next scheduled time.
ルータの勧誘：インターフェイスが有効になると、ホストはルータを要求するルーター契約を送信して、次のスケジュールされた時間ではなくルータ広告を直ちに生成することができます。
Router Advertisement: Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisements contain prefixes that are used for determining whether another address shares the same link (on-link determination) and/or address configuration, a suggested hop limit value, etc.
ルータ広告：ルータは、定期的に、またはルータの勧誘メッセージに応答して、さまざまなリンクとインターネットパラメータと一緒にプレゼンスを宣伝します。ルータ広告には、別のアドレスが同じリンク（オンリンク判定）および/またはアドレス設定、推奨ホップ制限値などを共有するかどうかを判断するために使用されるプレフィックスが含まれています。
Neighbor Solicitation: Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. Neighbor Solicitations are also used for Duplicate Address Detection.
Neighbor ResiCation：ノードによって送信されて、ネイバーのリンク層アドレスを決定するか、またはネイバーがキャッシュされたリンク層アドレスを介してまだ到達可能であることを確認します。隣接命令は、重複アドレス検出にも使用されます。
Neighbor Advertisement: A response to a Neighbor Solicitation message. A node may also send unsolicited Neighbor Advertisements to announce a link-layer address change.
ネイバー広告：隣接勧誘メッセージへの応答ノードはまた、リンク層アドレスの変更をアナウンスするために迷惑なネイバーアドバタイズメントを送信することができる。
Redirect: Used by routers to inform hosts of a better first hop for a destination.
リダイレクト：宛先の最初のホップのホストに通知するためにルーターによって使用されます。
On multicast-capable links, each router periodically multicasts a Router Advertisement packet announcing its availability. A host receives Router Advertisements from all routers, building a list of default routers. Routers generate Router Advertisements frequently enough that hosts will learn of their presence within a few minutes, but not frequently enough to rely on an absence of advertisements to detect router failure; a separate Neighbor Unreachability Detection algorithm provides failure detection.
マルチキャスト対応リンクでは、各ルータはその可用性を発表するルータ広告パケットを定期的にマルチキャストします。ホストはすべてのルーターからルーターアドバタイズメントを受信し、デフォルトルータのリストを構築します。ルータはルータアドバタイズメントを数分以内にその存在感を学習するのに十分な頻度で、ルータの広告を学習しますが、ルータの障害を検出する広告がないことに依存するのに十分ではありません。別の近隣到達不能検出アルゴリズムは故障検出を提供します。
Router Advertisements contain a list of prefixes used for on-link determination and/or autonomous address configuration; flags associated with the prefixes specify the intended uses of a particular prefix. Hosts use the advertised on-link prefixes to build and maintain a list that is used in deciding when a packet's destination is on-link or beyond a router. Note that a destination can be on-link even though it is not covered by any advertised on-link prefix. In such cases, a router can send a Redirect informing the sender that the destination is a neighbor.
ルータ広告には、オンリンクの決定および/または自律アドレス設定に使用されるプレフィックスのリストが含まれています。接頭辞に関連付けられているフラグは、特定のプレフィックスの意図された用途を指定します。ホストアドバタイズされたオンリンクプレフィックスを使用して、パケットの宛先がオンリンクまたはルータを超えているときに使用されるリストを構築して管理します。アドバタイズされたオンリンクプレフィックスではカバーされていなくても、宛先はオンリンクになることができます。そのような場合、ルータは送信先がネイバーであることを送信者に通知するリダイレクトを送信できます。
Router Advertisements (and per-prefix flags) allow routers to inform hosts how to perform Address Autoconfiguration. For example, routers can specify whether hosts should use DHCPv6 and/or autonomous (stateless) address configuration.
ルータの広告（およびプレフィックスごとのフラグ）では、ルーターにアドレスの自動設定を実行する方法をホストに通知できます。たとえば、ルーターは、ホストがDHCPv6および/または自律型（ステートレス）アドレス設定を使用するかどうかを指定できます。
Router Advertisement messages also contain Internet parameters such as the hop limit that hosts should use in outgoing packets and, optionally, link parameters such as the link MTU. This facilitates centralized administration of critical parameters that can be set on routers and automatically propagated to all attached hosts.
Router Advertisementメッセージには、ホストが発信パケットやリンクMTUなどのリンクパラメータなどのホップ制限などのインターネットパラメータも含まれています。これにより、ルータに設定できる重要なパラメータの集中管理を容易にし、接続されているすべてのホストに自動的に伝達されます。
Nodes accomplish address resolution by multicasting a Neighbor Solicitation that asks the target node to return its link-layer address. Neighbor Solicitation messages are multicast to the solicited-node multicast address of the target address. The target returns its link-layer address in a unicast Neighbor Advertisement message. A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other's link-layer addresses; the initiator includes its link-layer address in the Neighbor Solicitation.
ノードは、ターゲットノードにリンク層アドレスを返すように要求する隣接勧誘をマルチキャストすることによってアドレス解決を実行します。隣接勧誘メッセージは、ターゲットアドレスの要求ノードマルチキャストアドレスにマルチキャストされています。ターゲットは、ユニキャストネイバーアドバタイズメントメッセージでリンクレイヤアドレスを返します。単一の要求応答のパケットのペアは、イニシエータとターゲットの両方が互いのリンク層アドレスを解決するのに十分です。イニシエータは、隣接勧誘におけるリンク層アドレスを含む。
Neighbor Solicitation messages can also be used to determine if more than one node has been assigned the same unicast address. The use of Neighbor Solicitation messages for Duplicate Address Detection is specified in [ADDRCONF].
Neighbor Resicationメッセージを使用して、複数のノードに同じユニキャストアドレスが割り当てられているかどうかを判断できます。重複アドレス検出のための隣接勧誘メッセージの使用は[ADDRCONF]に指定されています。
Neighbor Unreachability Detection detects the failure of a neighbor or the failure of the forward path to the neighbor. Doing so requires positive confirmation that packets sent to a neighbor are actually reaching that neighbor and being processed properly by its IP layer. Neighbor Unreachability Detection uses confirmation from two sources. When possible, upper-layer protocols provide a positive confirmation that a connection is making "forward progress", that is, previously sent data is known to have been delivered correctly (e.g., new acknowledgments were received recently). When positive confirmation is not forthcoming through such "hints", a node sends unicast Neighbor Solicitation messages that solicit Neighbor Advertisements as reachability confirmation from the next hop. To reduce unnecessary network traffic, probe messages are only sent to neighbors to which the node is actively sending packets.
近隣の到達不能検出は、ネイバーの障害または隣接パスの障害の障害を検出します。そうすることは、隣接に送信されたパケットが実際にその隣接に達してそのIP層によって正しく処理されていることを正の確認に必要です。近隣の到達不能検出は、2つのソースからの確認を使用します。可能であれば、上位層のプロトコルは、接続が「進行状況」、すなわち予め送信されたデータが正しく配信されたことが知られている（例えば、新たな確認応答が最近受信された）という肯定的な確認を提供する。そのような「ヒント」を介して肯定的な確認が終了していない場合、ノードはネイバーアドバタイズメントを求めるユニキャストネイバー勧誘メッセージを次のホップからの到達可能性確認として送信します。不要なネットワークトラフィックを削減するために、プローブメッセージは、ノードが積極的にパケットを送信しているネイバーにのみ送信されます。
In addition to addressing the above general problems, Neighbor Discovery also handles the following situations:
上記の一般的な問題に対処することに加えて、ネイバーディスカバリーは以下の状況を処理します。
Link-layer address change - A node that knows its link-layer address has changed can multicast a few (unsolicited) Neighbor Advertisement packets to all nodes to quickly update cached link-layer addresses that have become invalid. Note that the sending of unsolicited advertisements is a performance enhancement only (e.g., unreliable). The Neighbor Unreachability Detection algorithm ensures that all nodes will reliably discover the new address, though the delay may be somewhat longer.
リンク層アドレス変更 - リンク層アドレスが変更されたノードは、すべてのノードに数回（迷惑な）ネイバーアドバタイズメントパケットをマルチキャストして、無効になったキャッシュされたリンク層アドレスを迅速に更新できます。迷惑な広告の送信は、パフォーマンス向上だけである（例えば、信頼できない）。近隣の到達不能検出アルゴリズムは、遅延が多少長くなる可能性があるが、すべてのノードが新しいアドレスを確実に発見するようにします。
Inbound load balancing - Nodes with replicated interfaces may want to load balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses.
インバウンドロードバランシング - レプリケートインタフェースを持つノードは、同じリンク上の複数のネットワークインターフェイスにわたる着信パケットの受信をロードすることをお勧めします。そのようなノードは、同じインターフェイスに割り当てられた複数のリンク層アドレスを有する。例えば、単一のネットワークドライバは、複数のリンク層アドレスを有する単一の論理インタフェースとして複数のネットワークインタフェースカードを表すことができる。
Neighbor Discovery allows a router to perform load balancing for traffic addressed to itself by allowing routers to omit the source link-layer address from Router Advertisement packets, thereby forcing neighbors to use Neighbor Solicitation messages to learn link-layer addresses of routers. Returned Neighbor Advertisement messages can then contain link-layer addresses that differ depending on, e.g., who issued the solicitation. This specification does not define a mechanism that allows hosts to Load-balance incoming packets. See [LD-SHRE].
Neigvision Discoveryルータがルータ広告パケットからソースリンク層アドレスを省略することを許可することで、ルータが自分自身にアドレス指定されたトラフィックの負荷分散を実行し、ネイバーの勧誘メッセージを使用してルータのリンク層アドレスを学習することができます。返されたネイバーアドバタイズメントメッセージには、例えば勧誘を発行した人が異なるリンクレイヤアドレスを含めることができます。この仕様は、ホストが着信パケットをロードすることを可能にするメカニズムを定義しません。[LD-Shre]を参照してください。
Anycast addresses - Anycast addresses identify one of a set of nodes providing an equivalent service, and multiple nodes on the same link may be configured to recognize the same anycast address. Neighbor Discovery handles anycasts by having nodes expect to receive multiple Neighbor Advertisements for the same target. All advertisements for anycast addresses are tagged as being non-Override advertisements. A non-Override advertisement is one that does not update or replace the information sent by another advertisement. These advertisements are discussed later in the context of Neighbor advertisement messages. This invokes specific rules to determine which of potentially multiple advertisements should be used.
Anycastアドレス - Anycastアドレスは、同等のサービスを提供する一連のノードの1つを識別し、同じリンク上の複数のノードを同じエニーキャストアドレスを認識するように設定できます。ネイバーディスカバリは、ノードが同じターゲットに対して複数のネイバーアドバタイズメントを受信することを期待していることで、エニーキャストを処理します。Anycastアドレスのすべての広告は、オーバーライドの広告であるとタグ付けされています。オーバーライド以外の広告は、他の広告によって送信された情報を更新または置き換えないものです。これらの広告は、近隣の広告メッセージのコンテキストで後で説明されています。これにより、複数の広告を使用する必要があるのかを判断するための特定の規則が確認されます。
Proxy advertisements - A node willing to accept packets on behalf of a target address that is unable to respond to Neighbor Solicitations can issue non-Override Neighbor Advertisements. Proxy advertisements are used by Mobile IPv6 Home Agents to defend mobile nodes' addresses when they move off-link. However, it is not intended as a general mechanism to handle nodes that, e.g., do not implement this protocol.
プロキシ広告 - 隣接勧誘に応答できないターゲットアドレスの代わりにパケットを受け入れることが望まれていないノードは、オーバーライドされていないネイバーアドバタイズメントを発行することができます。プロキシ広告は、モバイルIPv6ホームエージェントがオフリンクを移動するときにモバイルノードのアドレスを守るために使用されます。しかしながら、例えばこのプロトコルを実装しないノードを扱う一般的なメカニズムとして意図されていない。
The IPv6 Neighbor Discovery protocol corresponds to a combination of the IPv4 protocols Address Resolution Protocol [ARP], ICMP Router Discovery [RDISC], and ICMP Redirect [ICMPv4]. In IPv4 there is no generally agreed upon protocol or mechanism for Neighbor Unreachability Detection, although the Hosts Requirements document [HR-CL] does specify some possible algorithms for Dead Gateway Detection (a subset of the problems Neighbor Unreachability Detection tackles).
IPv6ネイバーディスカバリプロトコルは、IPv4プロトコルアドレス解決プロトコル[ARP]、ICMPルータディスカバリ[RDISC]、およびICMPリダイレクト[ICMPv4]の組み合わせに対応しています。IPv4では、ホストの要件文書[HR-CL]は、デッドゲートウェイ検出のためのいくつかの可能なアルゴリズムを指定していますが、デッドゲートウェイの検出（隣接検出不能検出タックルのサブセット）を指定します。
The Neighbor Discovery protocol provides a multitude of improvements over the IPv4 set of protocols:
近隣探索プロトコルは、IPv4のプロトコルセットに対して多数の改善を提供します。
Router Discovery is part of the base protocol set; there is no need for hosts to "snoop" the routing protocols.
ルータの検出はベースプロトコルセットの一部です。ホストはルーティングプロトコルを「スヌープ」する必要はありません。
Router Advertisements carry link-layer addresses; no additional packet exchange is needed to resolve the router's link-layer address.
ルータ広告はリンク層アドレスを運ぶ。ルータのリンクレイヤアドレスを解決するには、追加のパケット交換は必要ありません。
Router Advertisements carry prefixes for a link; there is no need to have a separate mechanism to configure the "netmask".
ルータアドバタイズメントリンクのプレフィックスをキャリアします。"netmask"を設定するための別のメカニズムを持つ必要はありません。
Router Advertisements enable Address Autoconfiguration.
ルータアドバタイズメントはアドレスの自動設定を有効にします。
Routers can advertise an MTU for hosts to use on the link, ensuring that all nodes use the same MTU value on links lacking a well-defined MTU.
ルータは、ホストがリンクで使用するためにMTUをアドバタイズでき、すべてのノードが明確に定義されたMTUを欠いているリンクで同じMTU値を使用することを保証します。
Address resolution multicasts are "spread" over 16 million (2^24) multicast addresses, greatly reducing address-resolution-related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all.
アドレス解決マルチキャストは、1600万を超えるマルチキャストアドレスを超える「スプレッド」で、ターゲット以外のノードのアドレス解決関連の割り込みを大幅に削減します。さらに、非IPv6マシンはまったく中断されないでください。
Redirects contain the link-layer address of the new first hop; separate address resolution is not needed upon receiving a redirect.
リダイレクトには、新しいファーストホップのリンクレイヤアドレスが含まれています。リダイレクトを受信すると、別々のアドレス解決は必要ありません。
Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from Router Advertisements. However, routers may be configured to omit some or all prefixes from Router Advertisements. In such cases hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate.
複数のプレフィックスを同じリンクに関連付けることができます。デフォルトでは、ホストはルータ広告からすべてのオンリンクプレフィックスを学習します。ただし、ルータ広告からの一部またはすべてのプレフィックスを省略するようにルータを構成できます。そのような場合、ホストは、宛先がオフリンクで、トラフィックをルータに送信すると仮定します。ルータは必要に応じてリダイレクトを発行できます。
Unlike IPv4, the recipient of an IPv6 redirect assumes that the new next-hop is on-link. In IPv4, a host ignores redirects specifying a next-hop that is not on-link according to the link's network mask. The IPv6 redirect mechanism is analogous to the XRedirect facility specified in [SH-MEDIA]. It is expected to be useful on non-broadcast and shared media links in which it is undesirable or not possible for nodes to know all prefixes for on-link destinations.
IPv4とは異なり、IPv6リダイレクトの受信者は、新しいネクストホップがオンリンクであると仮定します。IPv4では、リンクのネットワークマスクに従ってオンリンクではないネクストホップを指定するリダイレクトを無視します。IPv6リダイレクトメカニズムは、[SHメディア]で指定されたXredirect機能に似ています。ノードがオンリンク先のプレフィックスを知ることができない、またはノードが望ましくないか不可能な非放送および共有メディアリンクには役立ちます。
Neighbor Unreachability Detection is part of the base, which significantly improves the robustness of packet delivery in the presence of failing routers, partially failing or partitioned links, or nodes that change their link-layer addresses. For instance, mobile nodes can move off-link without losing any connectivity due to stale ARP caches.
近隣の到達不可能な検出は基本の一部であり、故障したルータの存在下でのパケット配信の堅牢性を大幅に向上させ、部分的に障害のあるリンク、またはリンク層アドレスを変更するノード。たとえば、モバイルノードは、古いARPキャッシュによる接続性を失うことなく、オフリンクを移動できます。
Unlike ARP, Neighbor Discovery detects half-link failures (using Neighbor Unreachability Detection) and avoids sending traffic to neighbors with which two-way connectivity is absent.
ARPとは異なり、近隣探索は、（近隣の到達不能検出を使用して）ハーフリンク障害を検出し、双方向接続が存在しないネイバーへのトラフィックの送信を回避します。
Unlike in IPv4 Router Discovery, the Router Advertisement messages do not contain a preference field. The preference field is not needed to handle routers of different "stability"; the Neighbor Unreachability Detection will detect dead routers and switch to a working one.
IPv4 Router Discoveryとは異なり、ルータ広告メッセージには設定フィールドが含まれていません。「安定性」のルータを処理するには、環境設定フィールドは必要ありません。近隣の到達不能検知はデッドルータを検出し、動作する動作を切り替えます。
The use of link-local addresses to uniquely identify routers (for Router Advertisement and Redirect messages) makes it possible for hosts to maintain the router associations in the event of the site renumbering to use new global prefixes.
ルータを一意に識別するためのリンクローカルアドレスの使用（ルータアドバタイズメントおよびリダイレクトメッセージの場合）は、ホストが新しいグローバルプレフィックスを使用するサイトの番号変更のイベントで、ルータの関連付けを維持できるようになります。
By setting the Hop Limit to 255, Neighbor Discovery is immune to off-link senders that accidentally or intentionally send ND messages. In IPv4, off-link senders can send both ICMP Redirects and Router Advertisement messages.
ホップ制限を255に設定することで、ネイバーディスカバリは誤ってまたは意図的にNDメッセージを送信するオフリンク送信者の影響を受けています。IPv4では、オフリンク送信者はICMPリダイレクトとルータ広告メッセージの両方を送信できます。
Placing address resolution at the ICMP layer makes the protocol more media-independent than ARP and makes it possible to use generic IP-layer authentication and security mechanisms as appropriate.
ICMPレイヤでアドレス解決を配置すると、プロトコルがARPよりもメディアに依存しないため、一般的なIP層認証とセキュリティメカニズムを適切に使用することができます。
Neighbor Discovery supports links with different properties. In the presence of certain properties, only a subset of the ND protocol mechanisms are fully specified in this document:
近隣探索は、さまざまなプロパティのリンクをサポートしています。特定のプロパティが存在する場合は、このドキュメントではNDプロトコルメカニズムのサブセットのみが完全に指定されています。
point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point-to-point links, and interfaces can be assigned link-local addresses.)
ポイントツーポイント - ネイバーディスカバリは、マルチキャストリンクと同じようなリンクを処理します。（マルチキャストはポイントツーポイントリンクで簡単に提供され、インターフェイスはリンクローカルアドレスを割り当てることができます。）
multicast - Neighbor Discovery operates over multicast capable links as described in this document.
マルチキャスト - ネイバーディスカバリは、このドキュメントで説明されているようにマルチキャスト対応リンクを介して動作します。
non-broadcast multiple access (NBMA) - Redirect, Neighbor Unreachability Detection and next-hop determination should be implemented as described in this document. Address resolution, and the mechanism for delivering Router Solicitations and Advertisements on NBMA links are not specified in this document. Note that if hosts support manual configuration of a list of default routers, hosts can dynamically acquire the link-layer addresses for their neighbors from Redirect messages.
非ブロードキャスト多元接続（NBMA） - リダイレクト、ネイバーの到達不可能検出およびネクストホップの決定は、このドキュメントで説明されているように実装されるべきです。アドレス解決、およびNBMAリンクでルータの勧誘と広告を配信するためのメカニズムは、このドキュメントでは指定されていません。ホストがデフォルトルータのリストの手動設定をサポートする場合、ホストはリダイレクトメッセージからそれらのネイバーのリンクレイヤアドレスを動的に取得できます。
shared media - The Redirect message is modeled after the XRedirect message in [SH-MEDIA] in order to simplify use of the protocol on shared media links.
共有メディア - 共有メディアリンク上のプロトコルの使用を簡単にするために、リダイレクトメッセージは[SHメディア]のXredirectメッセージの後にモデル化されます。
This specification does not address shared media issues that only relate to routers, such as:
この仕様は、次のようなルータにのみ関係する共有メディアの問題に対処しません。
- How routers exchange reachability information on a shared media link.
- ルータは共有メディアリンクに関する到達可能性情報を交換する方法。
- How a router determines the link-layer address of a host, which it needs to send redirect messages to the host.
- ルータがホストのリンクレイヤアドレスをどのように決定するか。それはホストにリダイレクトメッセージを送信する必要がある。
- How a router determines that it is the first-hop router for a received packet.
- ルータが受信したパケットの最初のホップルータであると判断する方法。
The protocol is extensible (through the definition of new options) so that other solutions might be possible in the future.
プロトコルは将来その他の解決策が可能になる可能性があるため、（新しいオプションの定義を通じて）拡張可能です。
variable MTU - Neighbor Discovery allows routers to specify an MTU for the link, which all nodes then use. All nodes on a link must use the same MTU (or Maximum Receive Unit) in order for multicast to work properly. Otherwise, when multicasting, a sender, which can not know which nodes will receive the packet, could not determine a minimum packet size that all receivers can process (or Maximum Receive Unit).
変数MTU - ネイバーディスカバリにより、ルータはリンクのMTUを指定できます。これはすべてのノードを使用します。リンク上のすべてのノードは、マルチキャストが正しく機能するために同じMTU（または最大受信ユニット）を使用する必要があります。そうではなく、マルチキャストすると、どのノードがパケットを受信するかを知ることができない送信者は、すべての受信機が処理できる最小パケットサイズ（または最大受信ユニット）を決定することができませんでした。
asymmetric reachability - Neighbor Discovery detects the absence of symmetric reachability; a node avoids paths to a neighbor with which it does not have symmetric connectivity.
非対称到達可能性 - 近隣探索は対称的な到達可能性がないことを検出します。ノードは、対称接続を持たないネイバーへのパスを回避します。
The Neighbor Unreachability Detection will typically identify such half-links and the node will refrain from using them.
近隣の到達不可能な検出は通常、そのような半リンクを識別し、ノードはそれらの使用を控えます。
The protocol can presumably be extended in the future to find viable paths in environments that lack reflexive and transitive connectivity.
再帰的および推移的な接続性を欠いている環境で実行可能なパスを見つけるために、プロトコルは将来延長されることがおそらく拡張することができます。
Neighbor Discovery messages are needed for various functions. Several functions are designed to allow hosts to ascertain the ownership of an address or the mapping between link-layer and IP-layer addresses. Vulnerabilities related to Neighbor Discovery are discussed in Section 11.1. A general solution for securing Neighbor Discovery is outside the scope of this specification and is discussed in [SEND]. However, Section 11.2 explains how and under which constraints IPsec Authentication Header (AH) or Encapsulating Security Payload (ESP) can be used to secure Neighbor Discovery.
各種機能には、近隣探索メッセージが必要です。いくつかの関数は、ホストがアドレスの所有権またはリンク層とIP層のアドレス間のマッピングを確認できるように設計されています。ネイバーディスカバリーに関連する脆弱性については、セクション11.1で説明します。隣接発見を確保するための一般的な解決策は、この仕様の範囲外であり、[送信]で説明されています。ただし、セクション11.2はどのように制約IPsec認証ヘッダ（AH）またはカプセル化セキュリティペイロード（ESP）を使用してネイザディスカバリを保護するかを説明します。
This section introduces message formats for all messages used in this specification.
このセクションでは、この仕様で使用されているすべてのメッセージのメッセージフォーマットについて説明します。
Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly.
ホストはルータアドバタイズメントを迅速に生成するようにルータを促すためにルータの勧誘を送信します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IPフィールド：
Source Address An IP address assigned to the sending interface, or the unspecified address if no address is assigned to the sending interface.
送信元アドレス送信インターフェイスにアドレスが割り当てられていない場合は、送信インターフェイスに割り当てられているIPアドレス、または指定されていないアドレス。
Destination Address Typically the all-routers multicast address.
宛先アドレスは通常、オールルータマルチキャストアドレスです。
Hop Limit 255
ホップ限界255
ICMP Fields:
ICMPフィールド：
Type 133
タイプ133
Code 0
コード0
Checksum The ICMP checksum. See [ICMPv6].
ICMPチェックサムをチェックします。[ICMPv6]を参照してください。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Options:
予約済みこのフィールドは未使用です。送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。有効なオプション：
Source link-layer address The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise, it SHOULD be included on link layers that have addresses.
ソースリンクレイヤーアドレス既知の場合、送信者のリンク層アドレス。送信元アドレスが指定されていないアドレスの場合は含まれてはいけません。それ以外の場合は、アドレスを持つリンクレイヤに含める必要があります。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは、新しいオプション型を定義することができます。受信者は、認識していないオプションを黙って無視し、メッセージの処理を続行する必要があります。
Routers send out Router Advertisement messages periodically, or in response to Router Solicitations.
ルータは定期的に、またはルータの勧誘に応答してルーター広告メッセージを送信します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IPフィールド：
Source Address MUST be the link-local address assigned to the interface from which this message is sent.
ソースアドレスは、このメッセージが送信されるインターフェイスに割り当てられているリンクローカルアドレスでなければなりません。
Destination Address Typically the Source Address of an invoking Router Solicitation or the all-nodes multicast address.
宛先アドレスは通常、呼び出しのルータの勧誘または全ノードマルチキャストアドレスの送信元アドレスです。
Hop Limit 255
ホップ限界255
ICMP Fields:
ICMPフィールド：
Type 134
タイプ134
Code 0
コード0
Checksum The ICMP checksum. See [ICMPv6].
ICMPチェックサムをチェックします。[ICMPv6]を参照してください。
Cur Hop Limit 8-bit unsigned integer. The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of zero means unspecified (by this router).
Cur Hop Limit 8ビットの符号なし整数。発信IPパケットのIPヘッダーの[Hop Count]フィールドに配置されるデフォルト値。ゼロの値は、（このルータによって）指定されていないことを意味します。
M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6].
M 1ビット「管理対象アドレス設定」フラグ。設定すると、アドレスが動的ホスト構成プロトコル[DHCPv6]を介して使用可能であることを示します。
If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.
Mフラグが設定されている場合、oフラグは冗長であり、DHCPv6はすべての利用可能な構成情報を返すため無視することができます。
O 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network.
O 1ビット「その他の設定」フラグ。設定すると、他の構成情報がDHCPv6を介して利用可能であることを示します。そのような情報の例は、ネットワーク内の他のサーバに関するDNS関連の情報または情報である。
Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6.
注：MもOフラグもセットされていない場合、これはDHCPv6を介して情報が利用可能であることを示しています。
Reserved A 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
6ビット未使用フィールドを予約しました。送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields.
ルータの有効期間16ビットの符号なし整数。デフォルトルータに関連付けられているライフタイムは秒単位です。フィールドには最大65535の値を含めることができ、受信者は任意の値を処理する必要がありますが、セクション6の送信規則は寿命を9000秒に制限します。寿命0は、ルータがデフォルトのルータではなく、デフォルトのルータリストに表示されないことを示します。ルータの有効期間は、デフォルトルータとしてのルータの有用性にのみ適用されます。他のメッセージフィールドまたはオプションに含まれる情報には適用されません。情報の時間制限が必要なオプションには、独自のライフタイムフィールドが含まれています。
Reachable Time 32-bit unsigned integer. The time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm (see Section 7.3). A value of zero means unspecified (by this router).
到達可能時間32ビット符号なし整数。到達可能性確認を受けた後、ノードが隣人を想定していることをミリ秒単位で）。近隣の到達不能検出アルゴリズムによって使用されます（7.3項を参照）。ゼロの値は、（このルータによって）指定されていないことを意味します。
Retrans Timer 32-bit unsigned integer. The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm (see Sections 7.2 and 7.3). A value of zero means unspecified (by this router).
レグランタイマ32ビット符号なし整数。再送信された隣接勧誘メッセージ間で、ミリ秒単位で。アドレス解決と近隣の到達不能検出アルゴリズムによって使用されます（セクション7.2と7.3を参照）。ゼロの値は、（このルータによって）指定されていないことを意味します。
Possible options:
可能なオプション：
Source link-layer address The link-layer address of the interface from which the Router Advertisement is sent. Only used on link layers that have addresses. A router MAY omit this option in order to enable inbound load sharing across multiple link-layer addresses.
ソースリンク層アドレスルータの広告が送信されるインタフェースのリンクレイヤアドレス。アドレスを持つリンクレイヤでのみ使用されます。ルータは、複数のリンク層アドレスにわたるインバウンドロード共有を有効にするために、このオプションを省略することがあります。
MTU SHOULD be sent on links that have a variable MTU (as specified in the document that describes how to run IP over the particular link type). MAY be sent on other links.
MTUは、変数MTUを持つリンクで（特定のリンクタイプの上にIPを実行する方法を説明する文書で指定されている）を送信する必要があります。他のリンクで送信される可能性があります。
Prefix Information These options specify the prefixes that are on-link and/or are used for stateless address autoconfiguration. A router SHOULD include all its on-link prefixes (except the link-local prefix) so that multihomed hosts have complete prefix information about on-link destinations for the links to which they attach. If complete information is lacking, a host with multiple interfaces may not be able to choose the correct outgoing interface when sending traffic to its neighbors.
プレフィックス情報これらのオプションは、オンリンクのプレフィックスを指定し、および/またはステートレスアドレスの自動設定に使用されます。ルータは、マルチホームホストに接続先のリンク先のリンク先のオンリンク先に関する完全な接頭辞があるように、そのすべてのオンリンクプレフィックス（リンクローカルプレフィックスを除く）を含める必要があります。完全な情報が不足している場合、その隣接者にトラフィックを送信するときに複数のインターフェイスを持つホストが正しい発信インターフェイスを選択できない可能性があります。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは、新しいオプション型を定義することができます。受信者は、認識していないオプションを黙って無視し、メッセージの処理を続行する必要があります。
Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor.
ノードは、ターゲットノードのリンク層アドレスを要求するためにネイバーソリティを送信し、ターゲットに独自のリンクレイヤアドレスを提供します。ノードがネイバーの到達可能性を検証しようとしているときに、ノードがアドレスとユニキャストを解決する必要がある場合、隣接勧誘はマルチキャストです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IPフィールド：
Source Address Either an address assigned to the interface from which this message is sent or (if Duplicate Address Detection is in progress [ADDRCONF]) the unspecified address. Destination Address Either the solicited-node multicast address corresponding to the target address, or the target address. Hop Limit 255
ソースアドレスこのメッセージが送信されるインターフェイスに割り当てられているアドレスまたは（重複アドレス検出が進行中の[addrconf]）未指定アドレス。宛先アドレスは、ターゲットアドレスに対応する要求ノードマルチキャストアドレス、またはターゲットアドレスのいずれかです。ホップ限界255
ICMP Fields:
ICMPフィールド：
Type 135
タイプ135
Code 0 Checksum The ICMP checksum. See [ICMPv6].
コード0 ICMPチェックサムチェックサム。[ICMPv6]を参照してください。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済みこのフィールドは未使用です。送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
Target Address The IP address of the target of the solicitation. It MUST NOT be a multicast address.
ターゲットアドレス勧誘対象のIPアドレス。マルチキャストアドレスではありません。
Possible options:
可能なオプション：
Source link-layer address The link-layer address for the sender. MUST NOT be included when the source IP address is the unspecified address. Otherwise, on link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations.
ソースリンク層送信元のリンク層アドレス。送信元IPアドレスが指定されていないアドレスの場合に含まれてはいけません。そうでなければ、アドレスを持つリンクレイヤでは、マルチキャスト契約に含まれている必要があり、ユニキャスト契約に含める必要があります。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは、新しいオプション型を定義することができます。受信者は、認識していないオプションを黙って無視し、メッセージの処理を続行する必要があります。
A node sends Neighbor Advertisements in response to Neighbor Solicitations and sends unsolicited Neighbor Advertisements in order to (unreliably) propagate new information quickly.
ノードは、隣接勧誘に応答してネイバーアドバタイズメントを送信し、新しい情報を迅速に伝播するために迷惑な隣接アドバタイズメントを送信する。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IPフィールド：
Source Address An address assigned to the interface from which the advertisement is sent. Destination Address For solicited advertisements, the Source Address of an invoking Neighbor Solicitation or, if the solicitation's Source Address is the unspecified address, the all-nodes multicast address.
送信元アドレス広告が送信されるインターフェイスに割り当てられているアドレス。勧誘された広告の宛先アドレス、呼び出し側の勧誘の送信元アドレス、または勧誘の送信元アドレスが不特定アドレスである場合、全ノードマルチキャストアドレス。
For unsolicited advertisements typically the all-nodes multicast address.
迷惑なアドバタイズメントの場合、通常、全ノードマルチキャストアドレス。
Hop Limit 255
ホップ限界255
ICMP Fields:
ICMPフィールド：
Type 136
タイプ136
Code 0
コード0
Checksum The ICMP checksum. See [ICMPv6].
ICMPチェックサムをチェックします。[ICMPv6]を参照してください。
R Router flag. When set, the R-bit indicates that the sender is a router. The R-bit is used by Neighbor Unreachability Detection to detect a router that changes to a host.
Rルータフラグ設定すると、Rビットは送信者がルータであることを示します。Rビットは、ホストに変化するルータを検出するために、ネイバーの到達不能検出によって使用されます。
S Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. It MUST NOT be set in multicast advertisements or in unsolicited unicast advertisements.
■募集フラグ。設定すると、Sビットは、宛先アドレスからの隣接勧誘に応答して広告が送信されたことを示します。Sビットは、近隣の到達不能検出の到達可能性確認として使用されます。マルチキャスト広告または迷惑なユニキャストアドバタイズメントに設定してはいけません。
O Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached link-layer address. When it is not set the advertisement will not update a cached link-layer address though it will update an existing Neighbor Cache entry for which no link-layer address is known. It SHOULD NOT be set in solicited advertisements for anycast addresses and in solicited proxy advertisements. It SHOULD be set in other solicited advertisements and in unsolicited advertisements.
oフラグを上書きします。設定すると、Oビットは、広告が既存のキャッシュエントリを上書きし、キャッシュされたリンク層アドレスを更新する必要があることを示します。設定されていない場合、広告はキャッシュされたリンク層アドレスを更新しませんが、リンク層アドレスがわかっていない既存のネイバーキャッシュエントリを更新します。エニーキャストアドレスと勧誘のプロキシ広告の募集広告に設定する必要はありません。それは他の勧誘広告および迷惑な広告に設定されるべきです。
Reserved 29-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約29ビット未使用フィールド。送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
Target Address For solicited advertisements, the Target Address field in the Neighbor Solicitation message that prompted this advertisement. For an unsolicited advertisement, the address whose link-layer address has changed. The Target Address MUST NOT be a multicast address.
勧誘広告のターゲットアドレス、この広告を促した隣接勧誘メッセージのターゲットアドレスフィールド。迷惑な広告の場合、リンクレイヤアドレスが変更されたアドレス。ターゲットアドレスはマルチキャストアドレスであってはなりません。
Possible options:
可能なオプション：
Target link-layer address The link-layer address for the target, i.e., the sender of the advertisement. This option MUST be included on link layers that have addresses when responding to multicast solicitations. When responding to a unicast Neighbor Solicitation this option SHOULD be included.
ターゲットリンク層アドレスターゲットのリンク層アドレス、すなわち広告の送信者。このオプションは、マルチキャスト契約に応答するときにアドレスを持つリンクレイヤに含める必要があります。ユニキャストネイバーの勧誘に対応するとき、このオプションは含まれるべきです。
The option MUST be included for multicast solicitations in order to avoid infinite Neighbor Solicitation "recursion" when the peer node does not have a cache entry to return a Neighbor Advertisements message. When responding to unicast solicitations, the option can be omitted since the sender of the solicitation has the correct link-layer address; otherwise, it would not be able to send the unicast solicitation in the first place. However, including the link-layer address in this case adds little overhead and eliminates a potential race condition where the sender deletes the cached link-layer address prior to receiving a response to a previous solicitation.
ピアノードがネイバーアドバタイズメントメッセージを返すためのキャッシュエントリを持たないときに、無限のネイバー勧誘「再帰」を回避するために、マルチキャスト契約のためにオプションを含める必要があります。ユニキャスト勧誘に応答すると、勧誘の送信者に正しいリンク層アドレスがあるため、オプションを省略できます。それ以外の場合は、最初の場所でユニキャスト勧誘を送信することはできません。ただし、この場合はリンク層アドレスを含めて、誤った軌跡を除去し、潜在的なレース状態を排除し、そこで送信側は回答を受信する前にキャッシュされたリンク層アドレスを削除します。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは、新しいオプション型を定義することができます。受信者は、認識していないオプションを黙って無視し、メッセージの処理を続行する必要があります。
Routers send Redirect packets to inform a host of a better first-hop node on the path to a destination. Hosts can be redirected to a better first-hop router but can also be informed by a redirect that the destination is in fact a neighbor. The latter is accomplished by setting the ICMP Target Address equal to the ICMP Destination Address.
ルータはリダイレクトパケットを送信して、宛先へのパス上のより良いファーストホップノードをホストに通知します。ホストはより良いファーストホップルータにリダイレクトできますが、宛先が実際にはネイバーであるというリダイレクトによっても知らされます。後者は、ICMPターゲットアドレスをICMP宛先アドレスに等しく設定することによって実現されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IPフィールド：
Source Address MUST be the link-local address assigned to the interface from which this message is sent.
ソースアドレスは、このメッセージが送信されるインターフェイスに割り当てられているリンクローカルアドレスでなければなりません。
Destination Address The Source Address of the packet that triggered the redirect.
宛先アドレスリダイレクトをトリガーしたパケットの送信元アドレス。
Hop Limit 255
ホップ限界255
ICMP Fields:
ICMPフィールド：
Type 137
タイプ137
Code 0
コード0
Checksum The ICMP checksum. See [ICMPv6].
ICMPチェックサムをチェックします。[ICMPv6]を参照してください。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済みこのフィールドは未使用です。送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
Target Address An IP address that is a better first hop to use for the ICMP Destination Address. When the target is the actual endpoint of communication, i.e., the destination is a neighbor, the Target Address field MUST contain the same value as the ICMP Destination Address field. Otherwise, the target is a better first-hop router and the Target Address MUST be the router's link-local address so that hosts can uniquely identify routers.
ターゲットアドレスICMP宛先アドレスに使用する最初のホップであるIPアドレス。ターゲットが通信の実際の終点、すなわち宛先はネイバーである場合、ターゲットアドレスフィールドはICMP宛先アドレスフィールドと同じ値を含める必要があります。それ以外の場合、ターゲットはより良いファーストホップルータであり、ターゲットアドレスはルータのリンクローカルアドレスでなければなりませんので、ホストはルータを一意に識別できます。
Destination Address The IP address of the destination that is redirected to the target.
宛先アドレスターゲットにリダイレクトされた宛先のIPアドレス。
Possible options:
可能なオプション：
Target link-layer address The link-layer address for the target. It SHOULD be included (if known). Note that on NBMA links, hosts may rely on the presence of the Target Link-Layer Address option in Redirect messages as the means for determining the link-layer addresses of neighbors. In such cases, the option MUST be included in Redirect messages.
ターゲットリンク層ターゲットのリンクレイヤアドレスをアドレスします。それは含まれるべきです（既知の場合）。NBMAリンクでは、ホストは、隣接するリンク層アドレスを決定するための手段として、リダイレクトメッセージ内のターゲットリンク層アドレスオプションの存在に依存している可能性がある。そのような場合は、リダイレクトメッセージにオプションを含める必要があります。
Redirected Header As much as possible of the IP packet that triggered the sending of the Redirect without making the redirect packet exceed the minimum MTU specified in [IPv6].
リダイレクトパケットを[IPv6]で指定された最小MTUを超えずにリダイレクトの送信をトリガーしたIPパケットのできるだけリダイレクトされたヘッダーをリダイレクトしました。
Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. Options should be padded when necessary to ensure that they end on their natural 64-bit boundaries. All options are of the form:
近隣探索メッセージには、0個以上のオプションが含まれています。そのうちのいくつかは同じメッセージに複数回表示される可能性があります。必要に応じてオプションは、それらがそれらの天然の64ビット境界で終わることを確実にするために埋められるべきです。すべてのオプションは次の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type 8-bit identifier of the type of option. The options defined in this document are:
オプションの種類の8ビット識別子を入力します。この文書で定義されているオプションは次のとおりです。
Option Name Type
オプション名タイプ
Source Link-Layer Address 1 Target Link-Layer Address 2 Prefix Information 3 Redirected Header 4 MTU 5
ソースリンク層アドレス1ターゲットリンクレイヤアドレス2プレフィックス情報3リダイレクトヘッダ4 MTU 5
Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero.
長さ8ビット符号なし整数。8オクテット単位でオプションの長さ（タイプフィールドと長さフィールドを含む）。値0は無効です。ノードは、長さゼロのオプションを含むNDパケットを静的に破棄する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type 1 for Source Link-layer Address 2 for Target Link-layer Address
ターゲットリンク層アドレスのソースリンク層アドレス2のタイプ1
Length The length of the option (including the type and length fields) in units of 8 octets. For example, the length for IEEE 802 addresses is 1 [IPv6-ETHER].
長さ8オクテット単位でオプションの長さ（タイプフィールドと長さフィールドを含む）。たとえば、IEEE 802アドレスの長さは1 [IPv6-Ether]です。
Link-Layer Address The variable length link-layer address.
リンク層アドレス可変長リンク層アドレス。
The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER].
このフィールドのコンテンツとフォーマット（バイト順序とビット順序を含む）は、IPv6が異なるリンクレイヤを介して動作する方法を説明する特定の文書で指定される予定です。例えば、[IPv6-エーテル]。
Description The Source Link-Layer Address option contains the link-layer address of the sender of the packet. It is used in the Neighbor Solicitation, Router Solicitation, and Router Advertisement packets.
説明ソースリンク層アドレスオプションには、パケットの送信者のリンクレイヤアドレスが含まれています。それは隣接勧誘、ルータ勧誘、そしてルーター広告パケットで使用されています。
The Target Link-Layer Address option contains the link-layer address of the target. It is used in Neighbor Advertisement and Redirect packets.
ターゲットリンク層アドレスオプションには、ターゲットのリンクレイヤアドレスが含まれています。それは近隣の広告とリダイレクトパケットで使用されます。
These options MUST be silently ignored for other Neighbor Discovery messages.
これらのオプションは他のネイバーディスカバリメッセージでは黙って無視されなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type 3
タイプ3
Length 4
長さ4
Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The prefix length field provides necessary information for on-link determination (when combined with the L flag in the prefix information option). It also assists with address autoconfiguration as specified in [ADDRCONF], for which there may be more restrictions on the prefix length.
プレフィックス長8ビット符号なし整数。有効なプレフィックス内の先行ビットの数。値は0から128の範囲です。プレフィックス長フィールドは、オンリンクの決定に必要な情報を提供します（プレフィックス情報オプションのLフラグと組み合わせると）。また、[ADDRCONF]で指定されているアドレスの自動設定を支援します。これにより、プレフィックス長がより多くの制限がある可能性があります。
L 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the L flag is not set a host MUST NOT conclude that an address derived from the prefix is off-link. That is, it MUST NOT update a previous indication that the address is on-link.
L 1ビットオンリンクフラグ。設定すると、この接頭辞をオンリンクの決定に使用できることを示します。指定されていない場合、広告はプレフィックスのオンリンクまたはオフリンクプロパティに関するステートメントを作成します。つまり、Lフラグが設定されていない場合、ホストは、プレフィックスから派生したアドレスがオフリンクであると判断してはいけません。つまり、アドレスがオンリンクであることを前の表示を更新してはいけません。
A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for stateless address configuration as specified in [ADDRCONF].
1ビットの自律アドレス設定フラグ。setが、この接頭辞が[addrconf]で指定されている状態のステートレスアドレス設定に使用できることを示します。
Reserved1 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済み1 6ビット未使用フィールド送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. The Valid Lifetime is also used by [ADDRCONF].
有効な有効期間32ビット符号なし整数。接頭辞がオンリンク決定の目的で有効であることを秒単位の時間（パケットが送信される時間）の長さの長さ。すべての1ビット（0xFFFFFFFF）の値は無限大を表します。有効な有効期間は[ADDRCONF]によっても使用されます。
Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred [ADDRCONF]. A value of all one bits (0xffffffff) represents infinity. See [ADDRCONF].
優先寿命32ビット符号なし整数。ステートレスアドレスの自動設定を介してプレフィックスから生成されたアドレスが優先[ADDRCONF]のままである時間（パケットが送信される時間を基準にして）秒単位の時間（パケットが送信されます）。すべての1ビット（0xFFFFFFFF）の値は無限大を表します。[addrconf]を参照してください。
Note that the value of this field MUST NOT exceed the Valid Lifetime field to avoid preferring addresses that are no longer valid.
このフィールドの値は、有効な有効なアドレスを避けないように有効なLifeTimeフィールドを超えてはいけません。
Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Reserved2このフィールドは未使用です。送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
Prefix An IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. A router SHOULD NOT send a prefix option for the link-local prefix and a host SHOULD ignore such a prefix option.
IPアドレスまたはIPアドレスのプレフィックスを接頭辞。プレフィックスの長さフィールドには、プレフィックス内の有効な先行ビット数が含まれています。プレフィックス長の後のプレフィックス内のビットは予約されており、送信者によってゼロに初期化され、受信側によって無視されなければなりません。ルータはリンクローカルプレフィックスのプレフィックスオプションを送信しないでください。ホストはそのような接頭辞オプションを無視します。
Description The Prefix Information option provide hosts with on-link prefixes and prefixes for Address Autoconfiguration. The Prefix Information option appears in Router Advertisement packets and MUST be silently ignored for other messages.
説明プレフィックス情報オプションは、アドレスの自動設定のためのオンリンクプレフィックスとプレフィックスを持つホストを提供します。プレフィックス情報オプションがルータアドバタイズメントパケットに表示され、他のメッセージでは黙って無視されなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IP header + data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type 4
タイプ4
Length The length of the option in units of 8 octets.
長さ8オクテット単位のオプションの長さ。
Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済みこれらのフィールドは未使用です。それらは送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
IP header + data The original packet truncated to ensure that the size of the redirect message does not exceed the minimum MTU required to support IPv6 as specified in [IPv6].
IPヘッダーデータリダイレクトメッセージのサイズが[IPv6]で指定されているように、リダイレクトメッセージのサイズがIPv6をサポートするのに必要な最小MTUを超えないように、元のパケットが切り捨てられました。
Description The Redirected Header option is used in Redirect messages and contains all or part of the packet that is being redirected.
説明リダイレクトされたヘッダーオプションはリダイレクトメッセージで使用され、リダイレクトされているパケットのすべてまたは一部が含まれています。
This option MUST be silently ignored for other Neighbor Discovery messages.
このオプションは、他のネイバーディスカバリメッセージでは黙って無視されなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type 5
タイプ5
Length 1
長さ1
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済みこのフィールドは未使用です。送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
MTU 32-bit unsigned integer. The recommended MTU for the link.
MTU 32ビット符号なし整数。リンクの推奨MTU。
Description The MTU option is used in Router Advertisement messages to ensure that all nodes on a link use the same MTU value in those cases where the link MTU is not well known.
説明リンクMTUがよく知られていない場合に、リンク上のすべてのノードが同じMTU値を使用するように、MTUオプションがルータアドバタイズメントメッセージで使用されます。
This option MUST be silently ignored for other Neighbor Discovery messages.
このオプションは、他のネイバーディスカバリメッセージでは黙って無視されなければなりません。
In configurations in which heterogeneous technologies are bridged together, the maximum supported MTU may differ from one segment to another. If the bridges do not generate ICMP Packet Too Big messages, communicating nodes will be unable to use Path MTU to dynamically determine the appropriate MTU on a per-neighbor basis. In such cases, routers can be configured to use the MTU option to specify the maximum MTU value that is supported by all segments.
異種技術が併合されている構成では、サポートされている最大MTUは1つのセグメントごとに異なる場合があります。ブリッジがICMPパケットが大きすぎない場合、通信ノードはパスMTUを使用して、隣接する適切なMTUを動的に決定することはできません。そのような場合、ルーターはMTUオプションを使用してすべてのセグメントでサポートされている最大MTU値を指定するように設定できます。
This section describes a conceptual model of one possible data structure organization that hosts (and, to some extent, routers) will maintain in interacting with neighboring nodes. The described organization is provided to facilitate the explanation of how the Neighbor Discovery protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
このセクションでは、ホスト（そしてある程度、ルータ）が隣接ノードと対話する際に維持する1つの可能なデータ構造編成の概念モデルについて説明します。記載された組織は、近隣探索プロトコルがどのように振る舞うべきかの説明を容易にするために提供される。この文書は、その外部の動作がこの文書で説明されているものと一致している限り、実装がこのモデルに付着していることを義務付けません。
This model is only concerned with the aspects of host behavior directly related to Neighbor Discovery. In particular, it does not concern itself with such issues as source address selection or the selecting of an outgoing interface on a multihomed host.
このモデルは、隣接発見に直接関連するホストの動作の側面にのみ関係しています。特に、ソースアドレスの選択やマルチホームホスト上の発信インターフェイスの選択などの問題に関係ありません。
Hosts will need to maintain the following pieces of information for each interface:
ホストは、各インターフェイスごとに次の情報を維持する必要があります。
Neighbor Cache - A set of entries about individual neighbors to which traffic has been sent recently. Entries are keyed on the neighbor's on-link unicast IP address and contain such information as its link-layer address, a flag indicating whether the neighbor is a router or a host (called IsRouter in this document), a pointer to any queued packets waiting for address resolution to complete, etc. A Neighbor Cache entry also contains information used by the Neighbor Unreachability Detection algorithm, including the reachability state, the number of unanswered probes, and the time the next Neighbor Unreachability Detection event is scheduled to take place.
隣接キャッシュ - トラフィックが最近送信された個々のネイバーに関するエントリのセット。エントリは、ネイバーのオンリンクユニキャストIPアドレスにキーを付して、そのリンクレイヤアドレスとしてそのような情報を含み、ネイバーがルータまたはホストかを示すフラグ（このドキュメントのISRouterと呼ばれます）、待機中のすべてのキューパケットへのポインタです。完了するアドレス解決のために、隣接キャッシュエントリには、到達可能性状態、未回答プローブの数、および次のネイバーの到達不能検出イベントが行われる予定の隣接到達不能検出アルゴリズムによって使用される情報も含まれています。
Destination Cache - A set of entries about destinations to which traffic has been sent recently. The Destination Cache includes both on-link and off-link destinations and provides a level of indirection into the Neighbor Cache; the Destination Cache maps a destination IP address to the IP address of the next-hop neighbor. This cache is updated with information learned from Redirect messages. Implementations may find it convenient to store additional information not directly related to Neighbor Discovery in Destination Cache entries, such as the Path MTU (PMTU) and round-trip timers maintained by transport protocols.
宛先キャッシュ - トラフィックが最近送信された宛先に関する一連のエントリ。宛先キャッシュは、オンリンク先とオフリンク先の両方を含み、隣接キャッシュに間接的なレベルを提供します。宛先キャッシュは、宛先IPアドレスをネクストホップネイバーのIPアドレスにマッピングします。このキャッシュはリダイレクトメッセージから学習された情報で更新されます。実装は、パスMTU（PMTU）やトランスポートプロトコルによって維持された往復タイマなどの隣接ディスカバリに直接関連していない追加情報を保存するのが便利です。
Prefix List - A list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created from information received in Router Advertisements. Each entry has an associated invalidation timer value (extracted from the advertisement) used to expire prefixes when they become invalid. A special "infinity" timer value specifies that a prefix remains valid forever, unless a new (finite) value is received in a subsequent advertisement.
prefix list - オンリンクされているアドレスのセットを定義するプレフィックスのリスト。プレフィックスリストエントリは、ルータ広告で受信された情報から作成されます。各エントリには、無効になったときにプレフィックスを期限切れにするために使用される関連する無効化タイマ値（広告から抽出）があります。特別な「Infinity」タイマー値は、新しい（有限）値が後続の広告で受信されない限り、プレフィックスが永久に有効なままであることを指定します。
The link-local prefix is considered to be on the prefix list with an infinite invalidation timer regardless of whether routers are advertising a prefix for it. Received Router Advertisements SHOULD NOT modify the invalidation timer for the link-local prefix.
リンクローカルプレフィックスは、ルータがプレフィックスをアドバタイズしているかどうかにかかわらず、無限の無効化タイマーを持つプレフィックスリストにあると見なされます。受信したルータ広告は、Link-Localプレフィックスの無効化タイマーを変更しないでください。
Default Router List - A list of routers to which packets may be sent. Router list entries point to entries in the Neighbor Cache; the algorithm for selecting a default router favors routers known to be reachable over those whose reachability is suspect. Each entry also has an associated invalidation timer value (extracted from Router Advertisements) used to delete entries that are no longer advertised.
デフォルトルータリスト - パケットを送信できるルータのリスト。ルータリストエントリ隣接キャッシュ内のエントリを指す。到達可能性が疑われるものよりも到達可能であることが知られているデフォルトのルータを選択するためのアルゴリズム。各エントリには、アドバタイズされていないエントリを削除するために使用される関連する無効化タイマ値（ルータアドバタイズメントから抽出されます）もあります。
Note that the above conceptual data structures can be implemented using a variety of techniques. One possible implementation is to use a single longest-match routing table for all of the above data structures. Regardless of the specific implementation, it is critical that the Neighbor Cache entry for a router is shared by all Destination Cache entries using that router in order to prevent redundant Neighbor Unreachability Detection probes.
上記の概念的なデータ構造は、さまざまな技術を使用して実施することができることに留意されたい。1つの可能な実装は、上記のすべてのデータ構造に対して単一の最長一致ルーティングテーブルを使用することです。特定の実装に関係なく、冗長なネイバーの到達不能検出プローブを防ぐために、ルータのネイバーキャッシュエントリがすべての宛先キャッシュエントリによって共有されることが重要です。
Note also that other protocols (e.g., Mobile IPv6) might add additional conceptual data structures. An implementation is at liberty to implement such data structures in any way it pleases. For example, an implementation could merge all conceptual data structures into a single routing table.
他のプロトコル（例えば、モバイルIPv6）は、追加の概念データ構造を追加することもできます。実装は、そのようなデータ構造を喜ばせるような方法で実装するための自由にあります。たとえば、実装はすべての概念データ構造を単一のルーティングテーブルにマージすることができます。
The Neighbor Cache contains information maintained by the Neighbor Unreachability Detection algorithm. A key piece of information is a neighbor's reachability state, which is one of five possible values. The following definitions are informal; precise definitions can be found in Section 7.3.2.
隣接キャッシュには、ネイバーの到達不能検出アルゴリズムによって維持されている情報が含まれています。重要な情報は隣人の到達可能性状態であり、これは5つの可能な値のうちの1つです。以下の定義は非公式です。正確な定義はセクション7.3.2で見つけることができます。
INCOMPLETE Address resolution is in progress and the link-layer address of the neighbor has not yet been determined.
不完全なアドレス解決が進行中であり、ネイバーのリンク層アドレスはまだ決定されていません。
REACHABLE Roughly speaking, the neighbor is known to have been reachable recently (within tens of seconds ago).
到達可能な大まかに言って、隣人は最近到達可能であることが知られています（数秒前）。
STALE The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability.
古くなっている隣人は、到達可能であることがわかりませんが、トラフィックが隣人に送信されるまで、その到達可能性を確認するための試みはできません。
DELAY The neighbor is no longer known to be reachable, and traffic has recently been sent to the neighbor. Rather than probe the neighbor immediately, however, delay sending probes for a short while in order to give upper-layer protocols a chance to provide reachability confirmation.
遅延隣接は到達可能ではなく、トラフィックが近隣に送信されました。しかしながら、隣接を直ちにプローブするのではなく、上層プロトコルを到達可能性の確認を提供する機会を与えるために、短いプローブを短く遅らせる。
PROBE The neighbor is no longer known to be reachable, and unicast Neighbor Solicitation probes are being sent to verify reachability.
プローブ隣接は到達可能ではなく、ユニキャスト隣接勧誘プローブが到達可能性を検証するために送信されています。
When sending a packet to a destination, a node uses a combination of the Destination Cache, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop, an operation known as "next-hop determination". Once the IP address of the next hop is known, the Neighbor Cache is consulted for link-layer information about that neighbor.
パケットを宛先に送信すると、ノードは、宛先キャッシュ、プレフィックスリスト、およびデフォルトルータリストの組み合わせを使用して、適切なネクストホップのIPアドレス、「ネクストホップ決定」と呼ばれる操作を決定する。ネクストホップのIPアドレスがわかったら、ネイバーキャッシュはそのネイバーに関するリンクレイヤ情報について相談されます。
Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6).
特定のユニキャスト宛先のネクストホップ決定は次のように動作します。送信者は、プレフィックスリストと一致する最長の接頭辞一致を実行して、パケットの宛先がオンリンクまたはオフリンクかを判断します。宛先がオンリンクの場合、ネクストホップアドレスはパケットの宛先アドレスと同じです。それ以外の場合、送信者はデフォルトのルータリストからルータを選択します（6.3.6項で説明した規則に従って）。
For efficiency reasons, next-hop determination is not performed on every packet that is sent. Instead, the results of next-hop determination computations are saved in the Destination Cache (which also contains updates learned from Redirect messages). When the sending node has a packet to send, it first examines the Destination Cache. If no entry exists for the destination, next-hop determination is invoked to create a Destination Cache entry.
効率的な理由から、送信されたすべてのパケットに対してネクストホップの決定は実行されません。代わりに、ネクストホップ決定計算の結果は宛先キャッシュに保存されます（リダイレクトメッセージから学習された更新も含まれています）。送信側ノードに送信するパケットがある場合、最初に宛先キャッシュを調べます。宛先にエントリが存在しない場合、ネクストホップの決定が呼び出されて宛先キャッシュエントリが作成されます。
Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. For multicast-capable interfaces Address Resolution consists of sending a Neighbor Solicitation message and waiting for a Neighbor Advertisement. When a Neighbor Advertisement response is received, the link-layer addresses is entered in the Neighbor Cache entry and the queued packet is transmitted. The address resolution mechanism is described in detail in Section 7.2.
次のホップノードのIPアドレスが既知されると、送信者はそのネイザに関するリンクレイヤ情報のためのネイバーキャッシュを調べます。エントリが存在しない場合、送信者は1つを作成し、その状態を不完全に設定し、アドレス解決を開始してから、アドレス解決の保留中のデータパケットをキューに入れます。マルチキャスト対応のインタフェースの場合、アドレス解決は、隣接勧誘メッセージを送信し、近隣の広告を待つことから成ります。近隣アドバタイズメント応答を受信すると、リンク層アドレスがネイバーキャッシュエントリに入力され、キューイングされたパケットが送信される。アドレス解決機構については、セクション7.2で詳細に説明されている。
For multicast packets, the next-hop is always the (multicast) destination address and is considered to be on-link. The procedure for determining the link-layer address corresponding to a given IP multicast address can be found in a separate document that covers operating IP over a particular link type (e.g., [IPv6-ETHER]).
マルチキャストパケットの場合、ネクストホップは常に（マルチキャスト）宛先アドレスであり、オンリンクであると見なされます。所与のIPマルチキャストアドレスに対応するリンク層アドレスを決定するための手順は、特定のリンクタイプ（例えば、[IPv6 - Ether]）を介して動作IPをカバーする別の文書に見出すことができる。
Each time a Neighbor Cache entry is accessed while transmitting a unicast packet, the sender checks Neighbor Unreachability Detection related information according to the Neighbor Unreachability Detection algorithm (Section 7.3). This unreachability check might result in the sender transmitting a unicast Neighbor Solicitation to verify that the neighbor is still reachable.
ユニキャストパケットの送信中にネイバーキャッシュエントリがアクセスされるたびに、送信側は近隣の到達不能検出アルゴリズムに従って隣接到達不能検出関連情報をチェックする（セクション7.3）。この到達不能チェックは、送信者がユニキャストネイバーの勧誘を送信して、隣接がまだ到達可能であることを確認する可能性があります。
Next-hop determination is done the first time traffic is sent to a destination. As long as subsequent communication to that destination proceeds successfully, the Destination Cache entry continues to be used. If at some point communication ceases to proceed, as determined by the Neighbor Unreachability Detection algorithm, next-hop determination may need to be performed again. For example, traffic through a failed router should be switched to a working router. Likewise, it may be possible to reroute traffic destined for a mobile node to a "mobility agent".
ネクストホップの決定は、トラフィックが宛先に最初に送信されたときに行われます。その後のその宛先への通信が正常に進行する限り、宛先キャッシュエントリは継続され続けます。近接到達不能検出アルゴリズムによって決定されるように、ある時点での通信が進むが進むならば、ネクストホップ決定を再度実行する必要があるかもしれない。たとえば、失敗したルータを介したトラフィックを作業ルータに切り替える必要があります。同様に、モバイルノード宛てのトラフィックを「モビリティエージェント」に再ルーティングすることが可能であり得る。
Note that when a node redoes next-hop determination there is no need to discard the complete Destination Cache entry. In fact, it is generally beneficial to retain such cached information as the PMTU and round-trip timer values that may also be kept in the Destination Cache entry.
ノードがネクストホップの決定を下すとき、完全な宛先キャッシュエントリを破棄する必要はありません。実際、そのようなキャッシュされた情報をPMTUおよび往復タイマ値として保持することは一般に有益であり、それも宛先キャッシュエントリに保持され得る。
Routers and multihomed hosts have multiple interfaces. The remainder of this document assumes that all sent and received Neighbor Discovery messages refer to the interface of appropriate context. For example, when responding to a Router Solicitation, the corresponding Router Advertisement is sent out the interface on which the solicitation was received.
ルータとマルチホームホストには複数のインタフェースがあります。この文書の残りの部分は、送信されたすべてのネイバー検出メッセージが適切なコンテキストのインタフェースを参照していると想定しています。たとえば、ルータの勧誘に応答すると、対応するルータの広告が受信したインターフェイスを送信されます。
The conceptual data structures described above use different mechanisms for discarding potentially stale or unused information.
上述の概念的なデータ構造は、潜在的に古い情報または未使用の情報を破棄するための異なるメカニズムを使用する。
From the perspective of correctness, there is no need to periodically purge Destination and Neighbor Cache entries. Although stale information can potentially remain in the cache indefinitely, the Neighbor Unreachability Detection algorithm ensures that stale information is purged quickly if it is actually being used.
正確さの観点からは、宛先キャッシュエントリとネイバーキャッシュエントリを定期的にパージする必要はありません。古い情報は無期限にキャッシュ内に潜在的に残る可能性がありますが、近隣の到達不能検出アルゴリズムは、実際に使用されている場合に古い情報がすぐにパージされます。
To limit the storage needed for the Destination and Neighbor Caches, a node may need to garbage-collect old entries. However, care must be taken to ensure that sufficient space is always present to hold the working set of active entries. A small cache may result in an excessive number of Neighbor Discovery messages if entries are discarded and rebuilt in quick succession. Any Least Recently Used (LRU)-based policy that only reclaims entries that have not been used in some time (e.g., ten minutes or more) should be adequate for garbage-collecting unused entries.
宛先キャッシュおよびネイバーキャッシュに必要なストレージを制限するために、ノードは古いエントリを調整する必要があります。ただし、アクティブエントリのワーキングセットを保持するのに十分なスペースが常に存在するように注意してください。小さなキャッシュは、エントリが廃棄され、迅速に連続して再構築されている場合、過剰な数の近隣検出メッセージが発生する可能性があります。しばらくの間に使用されていないエントリを再利用する（例えば、10分以上）、使用されていないエントリの使用に適している必要があります。
A node should retain entries in the Default Router List and the Prefix List until their lifetimes expire. However, a node may garbage-collect entries prematurely if it is low on memory. If not all routers are kept on the Default Router list, a node should retain at least two entries in the Default Router List (and preferably more) in order to maintain robust connectivity for off-link destinations.
ノードは、寿命が期限切れになるまで、デフォルトのルータリストとプレフィックスリストにエントリを保持する必要があります。ただし、ノードは、メモリ上で低い場合に早期にエントリをごみ収集する可能性があります。すべてのルータがデフォルトのルータリストに保持されていない場合、ノードは、オフリンク先へのロバストな接続を維持するために、ノードがデフォルトのルータリストに少なくとも2つのエントリを保持する必要があります。
When removing an entry from the Prefix List, there is no need to purge any entries from the Destination or Neighbor Caches. Neighbor Unreachability Detection will efficiently purge any entries in these caches that have become invalid. When removing an entry from the Default Router List, however, any entries in the Destination Cache that go through that router must perform next-hop determination again to select a new default router.
プレフィックスリストからエントリを削除するときは、宛先キャッシュまたはネイバーキャッシュからエントリをパージする必要はありません。近隣の到達不能検出は、無効になっているこれらのキャッシュ内のエントリを効率的にパージします。ただし、デフォルトのルータリストからエントリを削除するときは、そのルータを通過する宛先キャッシュ内のエントリは、新しいデフォルトルーターを選択するために再度ネクストホップの決定を実行する必要があります。
This section describes router and host behavior related to the Router Discovery portion of Neighbor Discovery. Router Discovery is used to locate neighboring routers as well as learn prefixes and configuration parameters related to stateless address autoconfiguration.
このセクションでは、ネイバー・ディスカバリーのルーター検出部分に関連するルーターとホストの動作について説明します。Router Discoveryは、隣接ルータを見つけるために、ステートレスアドレスの自動設定に関連する習得プレフィックスと設定パラメータを参照します。
Prefix Discovery is the process through which hosts learn the ranges of IP addresses that reside on-link and can be reached directly without going through a router. Routers send Router Advertisements that indicate whether the sender is willing to be a default router. Router Advertisements also contain Prefix Information options that list the set of prefixes that identify on-link IP addresses.
Prefix Discoveryは、ホストがリンクに存在するIPアドレスの範囲を学習し、ルータを通過せずに直接アクセスできるプロセスです。ルータは、送信者がデフォルトのルータになることを希望するかどうかを示すルータアドバタイズメントを送信します。ルータ広告には、リンクIPアドレスを識別するプレフィックスのセットを一覧表示するプレフィックス情報オプションも含まれています。
Stateless Address Autoconfiguration must also obtain subnet prefixes as part of configuring addresses. Although the prefixes used for address autoconfiguration are logically distinct from those used for on-link determination, autoconfiguration information is piggybacked on Router Discovery messages to reduce network traffic. Indeed, the same prefixes can be advertised for on-link determination and address autoconfiguration by specifying the appropriate flags in the Prefix Information options. See [ADDRCONF] for details on how autoconfiguration information is processed.
ステートレスアドレスの自動設定は、アドレスの設定の一部としてサブネットのプレフィックスも取得する必要があります。アドレスの自動設定に使用されるプレフィックスは、オンリンクの決定に使用されるものと論理的に異なるが、自動設定情報はルータの検出メッセージでPIGGYBBACKに配置されてネットワークトラフィックを削減します。確かに、プレフィックス情報オプションで適切なフラグを指定することで、同じプレフィックスをオンリンクの決定とアドレス自動設定のためにアドバタイズできます。自動設定情報の処理方法については、[ADDRCONF]を参照してください。
Hosts MUST silently discard any received Router Solicitation Messages.
ホストは、受信したルータの勧誘メッセージを黙って破棄しなければなりません。
A router MUST silently discard any received Router Solicitation messages that do not satisfy all of the following validity checks:
ルータは、以下のすべての有効性チェックを満たさない受信したルータの勧誘メッセージを静かに破棄しなければなりません。
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IPホップ制限フィールドは、値255、すなわちパケットがルータによって転送された可能性がある。
- ICMP Checksum is valid.
- ICMPチェックサムが有効です。
- ICMP Code is 0.
- ICMPコードは0です。
- ICMP length (derived from the IP length) is 8 or more octets.
- ICMP長（IP長から導出）は8個以上のオクテットです。
- All included options have a length that is greater than zero.
- 含まれるすべてのオプションは、ゼロより大きい長さを持ちます。
- If the IP source address is the unspecified address, there is no source link-layer address option in the message.
- IP送信元アドレスが不特定アドレスの場合、メッセージにソースリンクレイヤアドレスオプションはありません。
The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
予約フィールドの内容、および認識されていないオプションは無視する必要があります。将来、プロトコルへの下位互換性のある変更は、予約フィールドの内容を指定したり、新しいオプションを追加することができます。後方互換性のない変更は、異なるコード値を使用できます。
The contents of any defined options that are not specified to be used with Router Solicitation messages MUST be ignored and the packet processed as normal. The only defined option that may appear is the Source Link-Layer Address option.
ルータの勧誘メッセージで使用されるように指定されていない定義されていないオプションの内容は無視され、パケットは通常どおりに処理されます。表示される可能性がある唯一の定義済みオプションは、ソースリンク層アドレスオプションです。
A solicitation that passes the validity checks is called a "valid solicitation".
有効性チェックを渡す勧誘は「有効な勧誘」と呼ばれます。
A node MUST silently discard any received Router Advertisement messages that do not satisfy all of the following validity checks:
ノードは、以下のすべての有効性チェックを満たさない受信したルータアドバタイズメッセージメッセージを静かに破棄しなければなりません。
- IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers.
- IP送信元アドレスはリンクローカルアドレスです。ルータは、リンクローカルアドレスをルータアドバタイズメントのソースとして使用し、メッセージをリダイレクトしてホストがルータを一意に識別できなければなりません。
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IPホップ制限フィールドは、値255、すなわちパケットがルータによって転送された可能性がある。
- ICMP Checksum is valid.
- ICMPチェックサムが有効です。
- ICMP Code is 0.
- ICMPコードは0です。
- ICMP length (derived from the IP length) is 16 or more octets.
- ICMP長（IP長から導出）は16個以上のオクテットです。
- All included options have a length that is greater than zero.
- 含まれるすべてのオプションは、ゼロより大きい長さを持ちます。
The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
予約フィールドの内容、および認識されていないオプションは無視する必要があります。将来、プロトコルへの下位互換性のある変更は、予約フィールドの内容を指定したり、新しいオプションを追加することができます。後方互換性のない変更は、異なるコード値を使用できます。
The contents of any defined options that are not specified to be used with Router Advertisement messages MUST be ignored and the packet processed as normal. The only defined options that may appear are the Source Link-Layer Address, Prefix Information and MTU options.
ルータ広告メッセージで使用されるように指定されていない定義されていないオプションの内容は無視され、パケットは通常どおりに処理されなければなりません。表示される可能性がある唯一の定義済みオプションは、ソースリンク層アドレス、プレフィックス情報、およびMTUオプションです。
An advertisement that passes the validity checks is called a "valid advertisement".
有効性チェックを渡す広告は「有効な広告」と呼ばれます。
A router MUST allow for the following conceptual variables to be configured by system management. The specific variable names are used for demonstration purposes only, and an implementation is not required to have them, so long as its external behavior is consistent with that described in this document. Default values are specified to simplify configuration in common cases.
ルータは、システム管理によって次の概念変数を設定することを許可する必要があります。特定の変数名はデモ用に使用され、その外部の動作がこのドキュメントで説明されているものと一致している限り、実装はそれらを持つ必要はありません。一般的な場合は、設定を簡素化するためにデフォルト値が指定されています。
The default values for some of the variables listed below may be overridden by specific documents that describe how IPv6 operates over different link layers. This rule simplifies the configuration of Neighbor Discovery over link types with widely differing performance characteristics.
以下にリストされているいくつかの変数のデフォルト値は、IPv6が異なるリンクレイヤーを介して動作する方法を説明する特定の文書によってオーバーライドされる可能性があります。この規則は、広く異なる性能特性を持つリンクタイプを介したネイバーディスカバリの構成を簡素化します。
For each interface:
インターフェイスごとに：
IsRouter A flag indicating whether routing is enabled on this interface. Enabling routing on the interface would imply that a router can forward packets to or from the interface.
このインターフェイスでルーティングが有効かどうかを示すフラグ。インターフェイス上でのルーティングを有効にすると、ルータがインターフェイスのまたはインターフェイスからパケットを転送できることを意味します。
Default: FALSE
デフォルト：false
AdvSendAdvertisements A flag indicating whether or not the router sends periodic Router Advertisements and responds to Router Solicitations.
AdvsEnd vertisementsルータが定期的なルーターアドバタイズメントを送信し、ルータの勧誘に応答するかどうかを示すフラグ。
Default: FALSE
デフォルト：false
Note that AdvSendAdvertisements MUST be FALSE by default so that a node will not accidentally start acting as a router unless it is explicitly configured by system management to send Router Advertisements.
Router Advertisementsを送信するためにシステム管理によって明示的に構成されていない限り、ノードがルータとして機能しないように、デフォルトではAdvsEndEdverlisementsはfalseでなければならないことに注意してください。
MaxRtrAdvInterval The maximum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 4 seconds and no greater than 1800 seconds.
MaxRtrAdvIntervalインターフェイスからの迷惑なマルチキャストルータアドバタイズメントを送信するのを秒単位で送信する最大時間。4秒以上1800秒以内でなければなりません。
Default: 600 seconds
デフォルト：600秒
MinRtrAdvInterval The minimum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 3 seconds and no greater than .75 * MaxRtrAdvInterval.
MinRrtradvIntervalインターフェイスから迷惑メールを送信することを許可された最小時間。3秒以上、.75 * MaxRtradvIntervalを超えてはいけません。
Default: 0.33 * MaxRtrAdvInterval If MaxRtrAdvInterval >= 9 seconds; otherwise, the Default is MaxRtrAdvInterval.
デフォルト：0.33 * MaxRtradvInterval maxrtradvinterval> = 9秒の場合それ以外の場合は、デフォルトはMaxRtradvIntervalです。
AdvManagedFlag The TRUE/FALSE value to be placed in the "Managed address configuration" flag field in the Router Advertisement. See [ADDRCONF].
AdvanManagedFlag Router Advertisementの「管理対象アドレス設定」フラグフィールドに配置されるtrue / false値。[addrconf]を参照してください。
Default: FALSE
デフォルト：false
AdvOtherConfigFlag The TRUE/FALSE value to be placed in the "Other configuration" flag field in the Router Advertisement. See [ADDRCONF].
AdvotherConfigFlagルータ広告の「その他の設定」フラグフィールドに配置されるTrue / False値。[addrconf]を参照してください。
Default: FALSE
デフォルト：false
AdvLinkMTU The value to be placed in MTU options sent by the router. A value of zero indicates that no MTU options are sent.
advlinkMtuルータによって送信されたMTUオプションに配置される値。ゼロの値は、MTUオプションが送信されていないことを示します。
Default: 0
デフォルト：0
AdvReachableTime The value to be placed in the Reachable Time field in the Router Advertisement messages sent by the router. The value zero means unspecified (by this router). MUST be no greater than 3,600,000 milliseconds (1 hour).
AdvReachableTimeルータから送信されたルータアドバタイズメッセージの到達可能時間フィールドに配置される値。値ゼロは（このルータによって）指定されていないことを意味します。3,600,000ミリ秒（1時間）以下でなければなりません。
Default: 0
デフォルト：0
AdvRetransTimer The value to be placed in the Retrans Timer field in the Router Advertisement messages sent by the router. The value zero means unspecified (by this router).
AdvEtranStimerルータによって送信されたルータ広告メッセージの「Retrans Timer」フィールドに配置される値。値ゼロは（このルータによって）指定されていないことを意味します。
Default: 0
デフォルト：0
AdvCurHopLimit The default value to be placed in the Cur Hop Limit field in the Router Advertisement messages sent by the router. The value should be set to the current diameter of the Internet. The value zero means unspecified (by this router).
advCurhoplimitルータから送信されたルータ広告メッセージの[標準ホップ制限]フィールドに配置されるデフォルト値。値をインターネットの現在の直径に設定する必要があります。値ゼロは（このルータによって）指定されていないことを意味します。
Default: The value specified in the "Assigned Numbers" [ASSIGNED] that was in effect at the time of implementation.
デフォルト：実装時に有効な「割り当てられた番号」[割り当てられた番号 "で指定された値。
AdvDefaultLifetime The value to be placed in the Router Lifetime field of Router Advertisements sent from the interface, in seconds. MUST be either zero or between MaxRtrAdvInterval and 9000 seconds. A value of zero indicates that the router is not to be used as a default router. These limits may be overridden by specific documents that describe how IPv6 operates over different link layers. For instance, in a point-to-point link the peers may have enough information about the number and status of devices at the other end so that advertisements are needed less frequently.
advdefaultLifeTimeインターフェイスから送信されたルータのLifetimeフィールドに配置される値は、秒単位で送信されます。ゼロまたはMaxRtradvIntervalと9000秒の間でなければなりません。ゼロの値は、ルータをデフォルトルータとして使用されないことを示します。これらの制限は、IPv6が異なるリンクレイヤーをどのように動作するかを説明する特定の文書によって上書きされる可能性があります。たとえば、ポイントツーポイントリンクでは、ピアは他端のデバイスの数とステータスに関する十分な情報を持つことができ、そのため、広告はそれほど頻繁に必要です。
Default: 3 * MaxRtrAdvInterval
デフォルト：3 * MaxRtradvInterval
AdvPrefixList A list of prefixes to be placed in Prefix Information options in Router Advertisement messages sent from the interface.
AdvPrefixListインターフェイスから送信されたルーター広告メッセージのプレフィックス情報オプションに配置されるプレフィックスのリスト。
Default: all prefixes that the router advertises via routing protocols as being on-link for the interface from which the advertisement is sent. The link-local prefix SHOULD NOT be included in the list of advertised prefixes.
デフォルト：すべてのプレフィックスは、ルーティングプロトコルを介して広告が送信されているインターフェイスのオンリンクを介してアドバタイズします。Link-Localプレフィックスは、アドバタイズされたプレフィックスのリストに含まれてはいけません。
Each prefix has an associated:
各プレフィックスには関連付けられています。
AdvValidLifetime The value to be placed in the Valid Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. Implementations MAY allow AdvValidLifetime to be specified in two ways:
advvalidLifeTime「プレフィックス情報」オプションの有効な有効期間に配置される値。1のすべての1の（0xFFFFFFFF）の指定値は無限大を表します。実装は、2つの方法でadvvalifeLifeTimeを指定できるようにします。
- a time that decrements in real time, that is, one that will result in a Lifetime of zero at the specified time in the future, or
- リアルタイムでデクリメントする時間、つまり、将来指定された時刻にゼロの一生をもたらす時間、または
- a fixed time that stays the same in consecutive advertisements.
- 連続した広告で同じ時間を維持する固定時間。
Default: 2592000 seconds (30 days), fixed (i.e., stays the same in consecutive advertisements).
デフォルト：2592000秒（30日）、固定（すなわち、連続した広告で同じまま）。
AdvOnLinkFlag The value to be placed in the on-link flag ("L-bit") field in the Prefix Information option.
AdvonLinkFlagプレフィックス情報オプションの[オンリンクフラグ]フィールド（「L-Bit」）フィールドに配置する値。
Default: TRUE
デフォルト：true.
Stateless address configuration [ADDRCONF] defines additional information associated with each of the prefixes:
ステートレスアドレス設定[ADDRCONF]は、各プレフィックスに関連付けられている追加情報を定義します。
AdvPreferredLifetime The value to be placed in the Preferred Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. See [ADDRCONF] for details on how this value is used. Implementations MAY allow AdvPreferredLifetime to be specified in two ways:
AdvPreferredLifeTime [プレフィックス情報]オプションの優先寿命に配置される値を秒単位で。1のすべての1の（0xFFFFFFFF）の指定値は無限大を表します。この値の使用方法については、[ADDRCONF]を参照してください。実装は、AdvPreferRedLifeTimeを2つの方法で指定できるようにします。
- a time that decrements in real time, that is, one that will result in a Lifetime of zero at a specified time in the future, or
- リアルタイムでデクリメントする時間、つまり、将来指定された時間にゼロの寿命を延ばす
- a fixed time that stays the same in consecutive advertisements.
- 連続した広告で同じ時間を維持する固定時間。
Default: 604800 seconds (7 days), fixed (i.e., stays the same in consecutive advertisements). This value MUST NOT be larger than AdvValidLifetime.
デフォルト：604800秒（7日）、固定（すなわち、連続した広告で同じまま）。この値はadvvalidlifetimeより大きくてはいけません。
AdvAutonomousFlag The value to be placed in the Autonomous Flag field in the Prefix Information option. See [ADDRCONF].
AdvautonomousFlagプレフィックス情報オプションの[自律フラグ]フィールドに配置される値。[addrconf]を参照してください。
Default: TRUE
デフォルト：true.
The above variables contain information that is placed in outgoing Router Advertisement messages. Hosts use the received information to initialize a set of analogous variables that control their external behavior (see Section 6.3.2). Some of these host variables (e.g., CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes including routers. In practice, these variables may not actually be present on routers, since their contents can be derived from the variables described above. However, external router behavior MUST be the same as host behavior with respect to these variables. In particular, this includes the occasional randomization of the ReachableTime value as described in Section 6.3.2.
上記の変数には、発信ルータ広告メッセージに配置されている情報が含まれています。ホストは、受信した情報を使用して、外部動作を制御する類似の変数のセットを初期化します（6.3.2項を参照）。これらのホスト変数（例えば、CurHopLimit、RetranStimer、およびRECIVECTIME）のいくつかは、ルータを含むすべてのノードに適用されます。実際には、これらの変数は、それらの内容が上記の変数から導出される可能性があるため、実際にはルータに存在しない可能性があります。ただし、外部ルータの動作は、これらの変数に関してホストの動作と同じでなければなりません。特に、これには、6.3.2項に記載されているように、到達可能な値の時折のランダム化が含まれます。
Protocol constants are defined in Section 10.
プロトコル定数はセクション10で定義されています。
The term "advertising interface" refers to any functioning and enabled interface that has at least one unicast IP address assigned to it and whose corresponding AdvSendAdvertisements flag is TRUE. A router MUST NOT send Router Advertisements out any interface that is not an advertising interface.
「広告インタフェース」という用語は、それに割り当てられている少なくとも1つのユニキャストIPアドレスを有する任意の機能および有効なインターフェースを指し、それに対応するADVENDEDENDERSEMISEMSフラグが真である。広告インタフェースではないインターフェイスを任意のインターフェイスに送信してはいけません。
An interface may become an advertising interface at times other than system startup. For example:
インターフェースは、システム起動以外の時点で広告インタフェースになる可能性があります。例えば：
- changing the AdvSendAdvertisements flag on an enabled interface from FALSE to TRUE, or
- 有効なインターフェイスのADVENDENDENVERTISEMSEMENTSフラグをFALSEからTRUE、または
- administratively enabling the interface, if it had been administratively disabled, and its AdvSendAdvertisements flag is TRUE, or
- 管理上無効化されていた場合は、インタフェースを管理すること、およびそのADVENDENDENDERSEMSEMENSEMSフラグが真の場合、または
- enabling IP forwarding capability (i.e., changing the system from being a host to being a router), when the interface's AdvSendAdvertisements flag is TRUE.
- IP転送機能を有効にする（すなわち、システムのルータがルータであることからシステムを変更すること）。
A router MUST join the all-routers multicast address on an advertising interface. Routers respond to Router Solicitations sent to the all-routers address and verify the consistency of Router Advertisements sent by neighboring routers.
ルータは広告インターフェイス上のオールルータマルチキャストアドレスに参加する必要があります。ルータは、全ルータアドレスに送信されたルータの勧誘に応答し、隣接ルータによって送信されたルータアドバタイズメントの一貫性を検証します。
A router sends periodic as well as solicited Router Advertisements out its advertising interfaces. Outgoing Router Advertisements are filled with the following values consistent with the message format given in Section 4.2:
ルータは、その広告インタフェースを求めたルータ広告と同様に定期的なルータ広告を送信します。発信ルータの広告は、セクション4.2に記載されているメッセージフォーマットと一致する以下の値で埋められます。
- In the Router Lifetime field: the interface's configured AdvDefaultLifetime.
- Router Lifetimeフィールドに、インターフェイスの設定済みのAdvDefaultLifetime。
- In the M and O flags: the interface's configured AdvManagedFlag and AdvOtherConfigFlag, respectively.
- MおよびOフラグで：インターフェイスが設定されているAdvManagedFlagとAdvotherConfigFlag。
- In the Cur Hop Limit field: the interface's configured CurHopLimit.
- Cur Hop Limitフィールドに、インターフェイスの設定されているCurHopLimit。
- In the Reachable Time field: the interface's configured AdvReachableTime.
- 到達可能な時間フィールドに：インターフェイスの設定されたAdvReachableTime。
- In the Retrans Timer field: the interface's configured AdvRetransTimer.
- RESTRANS TIMERフィールドに：インターフェイスの設定済みのAdveRanStimer。
- In the options:
- オプションで：
o Source Link-Layer Address option: link-layer address of the sending interface. This option MAY be omitted to facilitate in-bound load balancing over replicated interfaces.
o ソースリンク層アドレスオプション：送信インターフェイスのリンクレイヤアドレス。このオプションは、複製インターフェイス上の境界内の負荷分散を容易にするために省略されてもよい。
o MTU option: the interface's configured AdvLinkMTU value if the value is non-zero. If AdvLinkMTU is zero, the MTU option is not sent.
o MTUオプション：値がゼロ以外の場合は、インターフェイスの設定済みのADVLinkMTU値です。AdvLinkMtuがゼロの場合、MTUオプションは送信されません。
o Prefix Information options: one Prefix Information option for each prefix listed in AdvPrefixList with the option fields set from the information in the AdvPrefixList entry as follows:
o プレフィックス情報オプション：次のようにAdvPrefixListエントリの情報から設定されたオプションフィールドを持つAdvPrefixListにリストされている各プレフィックスの1つのプレフィックス情報オプション。
- In the "on-link" flag: the entry's AdvOnLinkFlag.
- 「オンリンク」フラグで：エントリのAdvonLinkFlag。
- In the Valid Lifetime field: the entry's AdvValidLifetime.
- 有効なライフタイムフィールドに：エントリのAdvValidLifetime。
- In the "Autonomous address configuration" flag: the entry's AdvAutonomousFlag.
- 「自律アドレス構成」フラグ：エントリのADVAUTOMONOMONMOUSFLAG。
- In the Preferred Lifetime field: the entry's AdvPreferredLifetime.
- 優先寿命フィールドに：エントリのAdvPreferredLifetime。
A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise prefixes for stateless address autoconfiguration while not wishing to forward packets. Such a router sets the Router Lifetime field in outgoing advertisements to zero.
ルータは、デフォルトルータとして広告自体を広告することなくルータの広告を送信したい場合があります。たとえば、ルータは、パケットの転送を希望しないが、ステートレスアドレスの自動設定のプレフィックスをアドバタイズすることがあります。そのようなルータは、発信広告内のルータライフタイムフィールドをゼロに設定します。
A router MAY choose not to include some or all options when sending unsolicited Router Advertisements. For example, if prefix lifetimes are much longer than AdvDefaultLifetime, including them every few advertisements may be sufficient. However, when responding to a Router Solicitation or while sending the first few initial unsolicited advertisements, a router SHOULD include all options so that all information (e.g., prefixes) is propagated quickly during system initialization.
迷惑なルータ広告を送信するときに、ルータは一部またはすべてのオプションを含めないことを選択できます。例えば、プレフィックス寿命がAdvDefaultLifetimeよりはるかに長い場合は、それらを含めてもっと多くの広告が十分であり得る。ただし、ルータの勧誘に対応する場合、または最初のいくつかの最初の未読アドバタイズメントを送信している間に、ルータはすべてのオプションを含める必要があります。
If including all options causes the size of an advertisement to exceed the link MTU, multiple advertisements can be sent, each containing a subset of the options.
すべてのオプションを含めると、広告のサイズがリンクMTUを超えると、それぞれオプションのサブセットを含む複数の広告を送信できます。
A host MUST NOT send Router Advertisement messages at any time.
ホストはいつでもルータ広告メッセージを送信してはいけません。
Unsolicited Router Advertisements are not strictly periodic: the interval between subsequent transmissions is randomized to reduce the probability of synchronization with the advertisements from other routers on the same link [SYNC]. Each advertising interface has its own timer. Whenever a multicast advertisement is sent from an interface, the timer is reset to a uniformly distributed random value between the interface's configured MinRtrAdvInterval and MaxRtrAdvInterval; expiration of the timer causes the next advertisement to be sent and a new random value to be chosen.
迷惑なルータの広告は厳密に定期的ではありません。その後の送信間の間隔は、同じリンク上の他のルータからの広告との同期の可能性を低減するためにランダム化されています。各広告インターフェースには独自のタイマーがあります。マルチキャスト広告がインターフェイスから送信されるたびに、タイマーはインターフェイスの設定されたMinRtradvIntervalとMaxRtradvInterval間の一様に分散ランダム値にリセットされます。タイマーの有効期限は、次の広告を送信し、新しいランダム値を選択する。
For the first few advertisements (up to MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it becomes an advertising interface, if the randomly chosen interval is greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval for the initial advertisements increases the likelihood of a router being discovered quickly when it first becomes available, in the presence of possible packet loss.
インターフェイスから送信された最初のいくつかの広告（最大MAX_INITIAL_RTR_RTR_VERSEMSEMESTEMSEMENTS）は、広告インターフェイスになると、ランダムに選択された間隔がMAX_INITIAL_RTR_ADVERT_INTERVALを超えると、代わりにタイマーをMAX_INITIAL_RTR_ADVERT_INTERVALに設定する必要があります。初期広告のために小さい間隔を使用すると、可能なパケット損失の存在下で、最初に利用可能になると、ルータがすぐに発見される可能性が高まります。
The information contained in Router Advertisements may change through actions of system management. For instance, the lifetime of advertised prefixes may change, new prefixes could be added, a router could cease to be a router (i.e., switch from being a router to being a host), etc. In such cases, the router MAY transmit up to MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the same rules as when an interface becomes an advertising interface.
ルータの広告に含まれる情報は、システム管理の動作によって変わる可能性があります。たとえば、アドバタイズされたプレフィックスの有効期間が変更される可能性がある、新しいプレフィックスを追加することができ、ルータはルータであることができなくなる可能性があります（つまり、ルータからホストになるようにスイッチ）など、ルータは送信できます。インタフェースが広告インターフェイスになると同じ規則を使用して、MAX_INITIAL_RTR_RTR_ADVERTISEMSEMSEMSEMSEMSERSEMISEMS
An interface may cease to be an advertising interface, through actions of system management such as:
次のようなシステム管理の行動を通じて、インターフェースが広告インターフェースであることをやめることがあります。
- changing the AdvSendAdvertisements flag of an enabled interface from TRUE to FALSE, or
- 有効なインターフェイスのADVSENDENDENTISEMSEMENTSのフラグを真からfalseに変更する
- administratively disabling the interface, or
- インタフェースの管理上の無効化、または
- shutting down the system.
- システムをシャットダウンします。
In such cases, the router SHOULD transmit one or more (but not more than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router Advertisements on the interface with a Router Lifetime field of zero. In the case of a router becoming a host, the system SHOULD also depart from the all-routers IP multicast group on all interfaces on which the router supports IP multicast (whether or not they had been advertising interfaces). In addition, the host MUST ensure that subsequent Neighbor Advertisement messages sent from the interface have the Router flag set to zero.
そのような場合、ルータは、ルータの有効期間ゼロフィールドを持つインターフェイス上で1つ以上（MAX_FINAL_RTR_DRTR_VERTISEMSEMSEMSEMSEMENT）を送信する必要があります。ルータがホストになる場合、システムはルータがIPマルチキャストをサポートするすべてのインターフェイス上のAll-Routers IPマルチキャストグループからも存在するはずです（それらがインターフェイスが広告されているかどうか）。さらに、ホストは、インターフェイスから送信された後続の隣接アドバタイズメッセージにルータフラグがゼロに設定されていることを確認する必要があります。
Note that system management may disable a router's IP forwarding capability (i.e., changing the system from being a router to being a host), a step that does not necessarily imply that the router's interfaces stop being advertising interfaces. In such cases, subsequent Router Advertisements MUST set the Router Lifetime field to zero.
システム管理は、ルータのIP転送機能を無効にする（すなわち、システムがホストになるためにルータの変更を変更する）ことができることに注意してください。そのような場合、後続のルータアドバタイズメントは、ルータの有効期間フィールドをゼロに設定する必要があります。
A host MUST silently discard any received Router Solicitation messages.
ホストは、受信したルータの勧誘メッセージを黙って破棄しなければなりません。
In addition to sending periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on an advertising interface. A router MAY choose to unicast the response directly to the soliciting host's address (if the solicitation's source address is not the unspecified address), but the usual case is to multicast the response to the all-nodes group. In the latter case, the interface's interval timer is reset to a new random value, as if an unsolicited advertisement had just been sent (see Section 6.2.4).
周期的で迷惑なアドバタイズメントを送信することに加えて、ルータは広告インターフェース上で受信された有効な勧誘に応答して広告を送信する。ルータは、勧誘ホストのアドレスに直接応答を直接ユニキャストすることを選択できます（勧誘の送信元アドレスが指定されていないアドレスではない場合）、通常の場合は、すべてのノードグループへの応答をマルチキャストすることです。後者の場合、インターフェイスの間隔タイマは、迷惑な広告が送信されたばかりのように、新しいランダムな値にリセットされます（6.2.4項を参照）。
In all cases, Router Advertisements sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in response to multiple solicitations, the delay is relative to the first solicitation.) In addition, consecutive Router Advertisements sent to the all-nodes multicast address MUST be rate limited to no more than one advertisement every MIN_DELAY_BETWEEN_RAS seconds.
すべての場合において、ルータの勧誘に応答して送信されたルーター広告は、0からMAX_RA_DELAY_TIME秒の間のランダムな時間によって遅延されなければなりません。（複数の勧誘に応答して単一の広告が送信された場合、遅延は最初の勧誘に相対的です。）さらに、全ノードマルチキャストアドレスに送信された連続ルータ広告は、MIN_DELAY_BETWEENE_RAS秒数を1つ以下の広告に限定する必要があります。。
A router might process Router Solicitations as follows:
ルータは次のようにルータの勧誘を処理することがあります。
- Upon receipt of a Router Solicitation, compute a random delay within the range 0 through MAX_RA_DELAY_TIME. If the computed value corresponds to a time later than the time the next multicast Router Advertisement is scheduled to be sent, ignore the random delay and send the advertisement at the already-scheduled time.
- ルータの勧誘を受け取り、MAX_RA_DELAY_TIMEを介して0の範囲内のランダムな遅延を計算します。計算値が次のマルチキャストルータ広告が送信される予定の時間より遅い場合、ランダムな遅延を無視し、すでにスケジュールされた時間に広告を送信します。
- If the router sent a multicast Router Advertisement (solicited or unsolicited) within the last MIN_DELAY_BETWEEN_RAS seconds, schedule the advertisement to be sent at a time corresponding to MIN_DELAY_BETWEEN_RAS plus the random value after the previous advertisement was sent. This ensures that the multicast Router Advertisements are rate limited.
- ルータが最後のMIN_DELAY_BETWEN_RAS秒内にマルチキャストルータアドバタイズメントを送信した場合は、MIN_DELAY_BETWENE_RASに対応する時間に送信される広告をスケジュールして、前回の広告が送信された後にランダム値をプラスします。これにより、マルチキャストルータ広告がレート制限されていることが保証されます。
- Otherwise, schedule the sending of a Router Advertisement at the time given by the random value.
- それ以外の場合は、ランダム値によって指定された時点でのルータアドバタイズメントの送信をスケジュールします。
Note that a router is permitted to send multicast Router Advertisements more frequently than indicated by the MinRtrAdvInterval configuration variable so long as the more frequent advertisements are responses to Router Solicitations. In all cases, however, unsolicited multicast advertisements MUST NOT be sent more frequently than indicated by MinRtrAdvInterval.
ルータは、頻繁な広告がルータの契約に対する回答である限り、MinRtradvInterval構成変数によって示されるよりも頻繁にマルチキャストルータアドバタイズメントを送信することが許可されています。ただし、すべての場合において、迷惑なマルチキャスト広告は、MinRtradvIntervalによって示されるよりも頻繁に送信されてはならない。
Router Solicitations in which the Source Address is the unspecified address MUST NOT update the router's Neighbor Cache; solicitations with a proper source address update the Neighbor Cache as follows. If the router already has a Neighbor Cache entry for the solicitation's sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, then the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation's sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a multicast or a unicast router advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE.
ソースアドレスが指定されていないアドレスであるルータ勧ティは、ルータのネイバーキャッシュを更新してはいけません。適切な送信元アドレスでの勧誘次のように、ネイバーキャッシュを更新します。 Routerが既に勧誘者の送信者のネイバーキャッシュエントリを既に持っている場合、勧誘はソースリンク層アドレスオプションを含み、受信したリンクレイヤアドレスはすでにキャッシュ内に異なり、リンクレイヤアドレスは内部に更新する必要があります。適切な隣接キャッシュエントリ、およびその到達可能性状態も古く設定されている必要があります。勧誘の送信者のための既存のネイバーキャッシュエントリがない場合、ルータは1つを作成し、リンクレイヤアドレスをインストールし、その到達可能性状態をSECTION 7.3.3で指定したときに古く設定します。勧誘中に既存のネイバーキャッシュエントリがなく、ソースリンクレイヤアドレスオプションがない場合、ルータはマルチキャストまたはユニキャストルータアドバタイズメントで応答することがあります。ソースリンク層アドレスオプションが指定されているかどうか、勧誘者の送信者のネイバーキャッシュエントリが存在する（または作成されている）場合は、エントリのISROUTERフラグをFALSEに設定する必要があります。
Routers SHOULD inspect valid Router Advertisements sent by other routers and verify that the routers are advertising consistent information on a link. Detected inconsistencies indicate that one or more routers might be misconfigured and SHOULD be logged to system or network management. The minimum set of information to check includes:
ルータは他のルータによって送信された有効なルータアドバタイズメントを検査し、ルータがリンク上の一貫した情報をアドバタイズしていることを確認する必要があります。検出された矛盾は、1つ以上のルーターが誤って設定されている可能性があり、システムまたはネットワーク管理に記録されるべきであることを示します。チェックするための最小の情報のセットに含まれています。
- Cur Hop Limit values (except for the unspecified value of zero other inconsistencies SHOULD be logged to system network management).
- 縦率の値（他の矛盾がゼロの不特定の値を除く）は、システムネットワーク管理に記録されるはずです。
- Values of the M or O flags.
- MまたはOフラグの値。
- Reachable Time values (except for the unspecified value of zero).
- 到達可能な時間値（不特定のゼロを除く）。
- Retrans Timer values (except for the unspecified value of zero).
- レグランタイマ値（不特定のゼロを除く）。
- Values in the MTU options.
- MTUオプションの値。
- Preferred and Valid Lifetimes for the same prefix. If AdvPreferredLifetime and/or AdvValidLifetime decrement in real time as specified in Section 6.2.1 then the comparison of the lifetimes cannot compare the content of the fields in the Router Advertisement, but must instead compare the time at which the prefix will become deprecated and invalidated, respectively. Due to link propagation delays and potentially poorly synchronized clocks between the routers such comparison SHOULD allow some time skew.
- 同じ接頭辞のための好ましい有効な寿命。セクション6.2.1で指定されているようにadvpleferredLifetimeおよび/またはAdvValidLifeTimeがリアルタイムで減少した場合、ライフタイムの比較はルータアドバタイズメントのフィールドの内容を比較することはできませんが、代わりにプレフィックスが推奨されて無効化される時間を比較する必要があります。それぞれ。リンク伝播遅延が遅延遅延や潜在的に不十分な同期クロックの間のクロックは、そのような比較を許容する必要があります。
Note that it is not an error for different routers to advertise different sets of prefixes. Also, some routers might leave some fields as unspecified, i.e., with the value zero, while other routers specify values. The logging of errors SHOULD be restricted to conflicting information that causes hosts to switch from one value to another with each received advertisement.
さまざまなルーターの異なるプレフィックスセットをアドバタイズするエラーではないことに注意してください。また、いくつかのルータはいくつかのフィールドを指定されていない、すなわち値ゼロで、他のルータは値を指定することがあります。エラーのログ記録は、受信した各アドバタイズメントでホストがある値から別の値に切り替える原因となる競合する情報に制限されるべきです。
Any other action on reception of Router Advertisement messages by a router is beyond the scope of this document.
ルータによるルータ広告メッセージを受信するというその他の行動は、この文書の範囲を超えています。
The link-local address on a router should rarely change, if ever. Nodes receiving Neighbor Discovery messages use the source address to identify the sender. If multiple packets from the same router contain different source addresses, nodes will assume they come from different routers, leading to undesirable behavior. For example, a node will ignore Redirect messages that are believed to have been sent by a router other than the current first-hop router. Thus, the source address used in Router Advertisements sent by a particular router must be identical to the target address in a Redirect message when redirecting to that router.
ルータ上のリンクローカルアドレスはめったに変わらないはずです。Noiby Discoveryメッセージを受信するノード送信元アドレスを使用して送信者を識別します。同じルータからの複数のパケットが異なる送信元アドレスを含む場合、ノードは異なるルータからのものであり、望ましくない動作につながります。たとえば、ノードは、現在のファーストホップルータ以外のルータによって送信されたと考えられるリダイレクトメッセージを無視します。したがって、特定のルータによって送信されたルータアドバタイズメントで使用される送信元アドレスは、そのルータにリダイレクトされたときにリダイレクトメッセージ内のターゲットアドレスと同じでなければなりません。
Using the link-local address to uniquely identify routers on the link has the benefit that the address a router is known by should not change when a site renumbers.
リンク - ローカルアドレスを使用して、リンク上のルータを一意に識別するために、サイトの参照が変更されたときにルータが変更されないアドレスが変更されないという利点があります。
If a router changes the link-local address for one of its interfaces, it SHOULD inform hosts of this change. The router SHOULD multicast a few Router Advertisements from the old link-local address with the Router Lifetime field set to zero and also multicast a few Router Advertisements from the new link-local address. The overall effect should be the same as if one interface ceases being an advertising interface, and a different one starts being an advertising interface.
ルータがそのインタフェースの1つのリンクローカルアドレスを変更すると、この変更のホストに通知する必要があります。ルータは、Router Lifetimeフィールドをゼロに設定された古いリンクローカルアドレスからいくつかのルータアドバタイズメントをマルチキャストし、新しいリンクローカルアドレスからいくつかのルータアドバタイズメントをマルチキャストします。全体的な効果は、1つのインターフェースが広告インターフェースであることを抑える場合と同じであるべきです、そして異なるものは広告インターフェースであることです。
None.
無し。
A host maintains certain Neighbor-Discovery-related variables in addition to the data structures defined in Section 5.1. The specific variable names are used for demonstration purposes only, and an implementation is not required to have them, so long as its external behavior is consistent with that described in this document.
ホストは、セクション5.1で定義されているデータ構造に加えて、特定のネイバーディスカバリ関連の変数を維持します。特定の変数名はデモ用に使用され、その外部の動作がこのドキュメントで説明されているものと一致している限り、実装はそれらを持つ必要はありません。
These variables have default values that are overridden by information received in Router Advertisement messages. The default values are used when there is no router on the link or when all received Router Advertisements have left a particular value unspecified.
これらの変数は、ルータ広告メッセージで受信された情報によって上書きされるデフォルト値を持ちます。デフォルト値は、リンク上にルータがない場合、またはすべての受信されたルータ広告が特定の値を指定されていない場合に使用されます。
The default values in this specification may be overridden by specific documents that describe how IP operates over different link layers. This rule allows Neighbor Discovery to operate over links with widely varying performance characteristics.
この仕様のデフォルト値は、IPが異なるリンクレイヤを介して動作する方法を説明する特定の文書によって上書きされることがあります。この規則により、近隣探索は広く変化する性能特性を持つリンクを介して動作することを可能にします。
For each interface:
インターフェイスごとに：
LinkMTU The MTU of the link. Default: The valued defined in the specific document that describes how IPv6 operates over the particular link layer (e.g., [IPv6-ETHER]).
LinkmtuリンクのMTU。デフォルト：IPv6が特定のリンクレイヤー（例えば、[IPv6-Ether]）をどのように操作する方法を説明する特定の文書で定義されている値。
CurHopLimit The default hop limit to be used when sending IP packets.
curhoplimit IPパケットを送信するときに使用されるデフォルトホップ制限。
Default: The value specified in the "Assigned Numbers" [ASSIGNED] that was in effect at the time of implementation.
デフォルト：実装時に有効な「割り当てられた番号」[割り当てられた番号 "で指定された値。
BaseReachableTime A base value used for computing the random ReachableTime value.
BasereachableTimeランダムなreachabletime値を計算するために使用される基本値。
Default: REACHABLE_TIME milliseconds.
デフォルト：reachable_timeミリ秒。
ReachableTime The time a neighbor is considered reachable after receiving a reachability confirmation.
RECIVEBLETIME到達可能性確認を受けた後に隣接が到達可能であると見なされます。
This value should be a uniformly distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR times BaseReachableTime milliseconds. A new random value should be calculated when BaseReachableTime changes (due to Router Advertisements) or at least every few hours even if no Router Advertisements are received.
この値は、MIN_RANDOM_FACTORとMAX_RANDOM_FACTOR TIMESS BASEREACHABLETIMEミリ秒の間の一様に分散したランダム値である必要があります。ルータ広告が受信されていなくても、LASEREACHABLETIMEの変更（ルータ広告のため）または少なくとも数時間ごとに、新しいランダム値を計算する必要があります。
RetransTimer The time between retransmissions of Neighbor Solicitation messages to a neighbor when resolving the address or when probing the reachability of a neighbor.
RetranStimerアドレスを解決するとき、またはネイバーの到達可能性を調べるときの隣接勧誘メッセージの再送信間の時間。
Default: RETRANS_TIMER milliseconds
デフォルト：RETRANS_TIMERミリ秒
The host joins the all-nodes multicast address on all multicast-capable interfaces.
ホストは、すべてのマルチキャスト対応インターフェイスのすべてのノードマルチキャストアドレスに参加します。
When multiple routers are present, the information advertised collectively by all routers may be a superset of the information contained in a single Router Advertisement. Moreover, information may also be obtained through other dynamic means like DHCPv6. Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. However, when received information for a specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently received information is considered authoritative.
複数のルータが存在する場合、全てのルータによってまとめてアドバタイズされた情報は、単一のルータ広告に含まれる情報のスーパーセットであり得る。さらに、DHCPv6のような他の動的手段を介して情報も得ることができる。ホストはすべての受信した情報の和集合を受け入れます。ルータ広告の受信は、以前の広告または他のソースから受信したすべての情報を無効にしてはいけません。ただし、特定のパラメータ（Link MTU）またはオプション（たとえば、特定のプレフィックス上の寿命）の受信情報は、以前に受信された情報とは異なる場合、パラメータ/オプションは1つの値を持つことができます。最後に受信した情報は考慮されます。権威ある。
A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, and Retrans Timer) may contain a value denoting that it is unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using. In particular, a host MUST NOT interpret the unspecified value as meaning change back to the default value that was in use before the first Router Advertisement was received. This rule prevents hosts from continually changing an internal variable when one router advertises a specific value, but other routers advertise the unspecified value.
ルータ広告フィールド（例えば、縦方向、到達可能時間、およびレトランスタイマ）は、指定されていないことを示す値を含み得る。そのような場合は、パラメータは無視され、ホストはすでに使用されている値を使用していかないはずです。特に、ホストは、最初のルータの広告が受信される前に使用されていたデフォルト値に変更された変更として、指定されていない値を解釈してはいけません。この規則は、1つのルータが特定の値をアドバタイズすると、ホストが内部変数を継続的に変更するのを防ぎますが、他のルータは不特定の値をアドバタイズします。
On receipt of a valid Router Advertisement, a host extracts the source address of the packet and does the following:
有効なルータアドバタイズメントを受信すると、ホストはパケットの送信元アドレスを抽出し、次のことを行います。
- If the address is not already present in the host's Default Router List, and the advertisement's Router Lifetime is non-zero, create a new entry in the list, and initialize its invalidation timer value from the advertisement's Router Lifetime field.
- アドレスがホストのデフォルトルータリストにまだ存在していない場合、広告のルータの有効期間がゼロ以外の場合は、リストに新しいエントリを作成し、その無効化タイマ値を広告のRourter Lifetimeフィールドから初期化します。
- If the address is already present in the host's Default Router List as a result of a previously received advertisement, reset its invalidation timer to the Router Lifetime value in the newly received advertisement.
- 以前に受信した広告の結果としてホストのデフォルトルータリストにアドレスがすでに存在している場合は、その無効化タイマーを新しく受信した広告のルータの有効期間の値にリセットしてください。
- If the address is already present in the host's Default Router List and the received Router Lifetime value is zero, immediately time-out the entry as specified in Section 6.3.5.
- アドレスが既にホストのデフォルトルータリストに存在し、受信したルータの有効期間値がゼロである場合は、直ちにセクション6.3.5で指定されているエントリをタイムアウトします。
To limit the storage needed for the Default Router List, a host MAY choose not to store all of the router addresses discovered via advertisements. However, a host MUST retain at least two router addresses and SHOULD retain more. Default router selections are made whenever communication to a destination appears to be failing. Thus, the more routers on the list, the more likely an alternative working router can be found quickly (e.g., without having to wait for the next advertisement to arrive).
デフォルトのルータリストに必要なストレージを制限するために、ホストは広告経由で検出されたすべてのルータアドレスを保存しないことを選択できます。ただし、ホストは少なくとも2つのルータアドレスを保持し、さらに維持する必要があります。デフォルトのルータ選択は、宛先への通信が失敗しているように見えるたびに行われます。したがって、リスト上のより多くのルータは、代替のワーキングルータが迅速に見つかる可能性が高い（例えば、次の広告が到着するのを待つ必要なしに）迅速に見つかる可能性がある。
If the received Cur Hop Limit value is non-zero, the host SHOULD set its CurHopLimit variable to the received value.
受信した縦のホップ制限値がゼロ以外の場合、ホストはそのCURHOPLIMIT変数を受信値に設定する必要があります。
If the received Reachable Time value is non-zero, the host SHOULD set its BaseReachableTime variable to the received value. If the new value differs from the previous value, the host SHOULD re-compute a new random ReachableTime value. ReachableTime is computed as a uniformly distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR times the BaseReachableTime. Using a random component eliminates the possibility that Neighbor Unreachability Detection messages will synchronize with each other.
受信した到達可能時間値がゼロ以外の場合、ホストはそのBasereachableTime変数を受信値に設定する必要があります。新しい値が前の値と異なる場合、ホストは新しいランダムなRECHINGETIME値を再計算する必要があります。RecureBletimeは、BasereachableTimeのMIN_RANDOM_FACTORとMAX_RANDOM_FACTOR倍の間の一様に分布したランダム値として計算されます。ランダムなコンポーネントを使用すると、近隣の到達不能検出メッセージが互いに同期する可能性がなくなります。
In most cases, the advertised Reachable Time value will be the same in consecutive Router Advertisements, and a host's BaseReachableTime rarely changes. In such cases, an implementation SHOULD ensure that a new random value gets re-computed at least once every few hours.
ほとんどの場合、アドバタイズされた到達可能時間値は連続したルータ広告で同じになり、ホストのBasereachableTimeはめったに変更されません。そのような場合、実装は、新しいランダム値が少なくとも数時間に1回再計算されるようにする必要があります。
The RetransTimer variable SHOULD be copied from the Retrans Timer field, if the received value is non-zero.
受信した値がゼロ以外の場合、RetranStimer変数をRetrans Timerフィールドからコピーする必要があります。
After extracting information from the fixed part of the Router Advertisement message, the advertisement is scanned for valid options. If the advertisement contains a Source Link-Layer Address option, the link-layer address SHOULD be recorded in the Neighbor Cache entry for the router (creating an entry if necessary) and the IsRouter flag in the Neighbor Cache entry MUST be set to TRUE. If no Source Link-Layer Address is included, but a corresponding Neighbor Cache entry exists, its IsRouter flag MUST be set to TRUE. The IsRouter flag is used by Neighbor Unreachability Detection to determine when a router changes to being a host (i.e., no longer capable of forwarding packets). If a Neighbor Cache entry is created for the router, its reachability state MUST be set to STALE as specified in Section 7.3.3. If a cache entry already exists and is updated with a different link-layer address, the reachability state MUST also be set to STALE.
ルータ広告メッセージの固定部分から情報を抽出した後、広告は有効なオプションのためにスキャンされます。広告に送信元リンク層アドレスオプションが含まれている場合、リンク層アドレスはルータのネイバーキャッシュエントリ（必要に応じてエントリを作成する）に記録され、ネイバーキャッシュエントリ内のISROUTERフラグはtrueに設定する必要があります。ソースリンクレイヤアドレスが含まれていないが、対応するネイバーキャッシュエントリが存在する場合、そのISROUTERフラグはtrueに設定する必要があります。ISROUTERフラグは、ルータがホストであるとき（すなわち、パケットを転送することができない）を判断するために、ネイバー到達不可能検出によって使用される。ルータに対してネイバーキャッシュエントリが作成されている場合、その到達可能性状態はセクション7.3.3で指定されているように古く設定する必要があります。キャッシュエントリがすでに存在していて別のリンクレイヤアドレスで更新されている場合は、到達可能性状態も古く設定されている必要があります。
If the MTU option is present, hosts SHOULD copy the option's value into LinkMTU so long as the value is greater than or equal to the minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value specified in the link-type-specific document (e.g., [IPv6-ETHER]).
MTUオプションが存在する場合、ホストは最小リンクMTU [IPv6]以上の値がLink-Type固有の文書で指定されている最大LinkMTU値を超えない限り、オプションの値をLINKMTUにコピーする必要があります。（例えば、[IPv6-エーテル]）。
Prefix Information options that have the "on-link" (L) flag set indicate a prefix identifying a range of addresses that should be considered on-link. Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link. The only way to cancel a previous on-link indication is to advertise that prefix with the L-bit set and the Lifetime set to zero. The default behavior (see Section 5.2) when sending a packet to an address for which no information is known about the on-link status of the address is to forward the packet to a default router; the reception of a Prefix Information option with the "on-link" (L) flag set to zero does not change this behavior. The reasons for an address being treated as on-link is specified in the definition of "on-link" in Section 2.1. Prefixes with the on-link flag set to zero would normally have the autonomous flag set and be used by [ADDRCONF].
「オンリンク」（L）フラグセットを持つプレフィックス情報オプションは、リンク上で考慮されるべきアドレスの範囲を識別する接頭辞を示します。ただし、オンリンクフラグがゼロに設定されたプレフィックス情報オプションは、オンリンクの決定に関する情報を認識しないため、プレフィックスでカバーされているアドレスがオフリンクであることを意味するために解釈されないでください。前回のオンリンク表示をキャンセルする唯一の方法は、その接頭辞をLビットセットとともに宣伝することです。ライフタイムはゼロに設定されます。アドレスのオンリンクステータスについて情報がわからないアドレスにパケットを送信する場合のデフォルトの動作（セクション5.2）は、パケットをデフォルトルータに転送することです。 「オンリンク」（L）フラグがゼロに設定されているプレフィックス情報オプションの受信は、この動作を変更しません。 on-linkとして扱われるアドレスの理由は、2.1の「オンリンク」の定義に指定されています。ゼロに設定されたオンリンクフラグを持つプレフィックスは、通常、自律フラグを設定し、[ADDRCONF]によって使用されます。
For each Prefix Information option with the on-link flag set, a host does the following:
オンリンクフラグセットを使用したプレフィックス情報オプションごとに、ホストは次のようになります。
- If the prefix is the link-local prefix, silently ignore the Prefix Information option.
- 接頭辞がlink-local接頭辞の場合は、プレフィックス情報オプションを黙って無視します。
- If the prefix is not already present in the Prefix List, and the Prefix Information option's Valid Lifetime field is non-zero, create a new entry for the prefix and initialize its invalidation timer to the Valid Lifetime value in the Prefix Information option.
- プレフィックスリストにプレフィックスがまだ存在していない場合、プレフィックス情報オプションの有効なLifeTimeフィールドがゼロ以外の場合は、接頭辞の新しいエントリを作成し、その無効化タイマをプレフィックス情報オプションの有効なライフタイム値に初期化します。
- If the prefix is already present in the host's Prefix List as the result of a previously received advertisement, reset its invalidation timer to the Valid Lifetime value in the Prefix Information option. If the new Lifetime value is zero, time-out the prefix immediately (see Section 6.3.5).
- 先に受信したアドバタイズメントの結果としてホストの接頭辞リストにプレフィックスがすでに存在している場合は、[プレフィックス情報]オプションの有効なライフタイム値に無効化タイマーをリセットしてください。新しい有効期間の値がゼロの場合は、直ちにプレフィックスをタイムアウトします（6.3.5項を参照）。
- If the Prefix Information option's Valid Lifetime field is zero, and the prefix is not present in the host's Prefix List, silently ignore the option.
- プレフィックス情報オプションの有効なLifeTimeフィールドがゼロで、プレフィックスがホストの接頭辞リストに存在しない場合は、そのオプションを無視します。
Stateless address autoconfiguration [ADDRCONF] may in some circumstances use a larger Valid Lifetime of a prefix or ignore it completely in order to prevent a particular denial-of-service attack. However, since the effect of the same denial of service targeted at the on-link prefix list is not catastrophic (hosts would send packets to a default router and receive a redirect rather than sending packets directly to a neighbor), the Neighbor Discovery protocol does not impose such a check on the prefix lifetime values. Similarly, [ADDRCONF] may impose certain restrictions on the prefix length for address configuration purposes. Therefore, the prefix might be rejected by [ADDRCONF] implementation in the host. However, the
ステートレスアドレス自動設定[ADDRCONF]状況によっては、特定のサービス拒否攻撃を防ぐために、プレフィックスの有効な有効な有効期間を使用するか、またはそれを完全に無視することがあります。ただし、オンリンクプレフィックスリストでターゲットとした同じサービスの影響は壊滅的なものではない（ホストはデフォルトのルータにパケットを送信し、隣接する範囲に直接送信するのではなくリダイレクトを受け取ります）。このようなチェックをプレフィックスの有効期間の値に課すことはありません。同様に、[ADDRCONF]はアドレス構成の目的でプレフィックス長に特定の制限を課すことがあります。したがって、プレフィックスはホスト内の[AddRconf]実装によって拒否される可能性があります。しかし
prefix length is still valid for on-link determination when combined with other flags in the prefix option.
プレフィックス長は、プレフィックスオプションの他のフラグと組み合わせると、まだオンリンクの決定に有効です。
Note: Implementations can choose to process the on-link aspects of the prefixes separately from the stateless address autoconfiguration aspects of the prefixes by, e.g., passing a copy of each valid Router Advertisement message to both an "on-link" and an "addrconf" function. Each function can then operate independently on the prefixes that have the appropriate flag set.
注：実装は、プレフィックスのステートレスアドレスの自動設定の側面とは別に、プレフィックスのオンリンクの側面を別々に処理することを選択できます。" 関数。各機能は、適切なフラグセットを持つ接頭辞で独立して動作できます。
Whenever the invalidation timer expires for a Prefix List entry, that entry is discarded. No existing Destination Cache entries need be updated, however. Should a reachability problem arise with an existing Neighbor Cache entry, Neighbor Unreachability Detection will perform any needed recovery.
無効化タイマーがプレフィックスリストエントリの有効期限が切れるたびに、そのエントリは破棄されます。ただし、既存の宛先キャッシュエントリを更新する必要はありません。既存のネイバーキャッシュエントリで到達可能性の問題が発生した場合、近隣の到達不能検出は必要な回復を実行します。
Whenever the Lifetime of an entry in the Default Router List expires, that entry is discarded. When removing a router from the Default Router list, the node MUST update the Destination Cache in such a way that all entries using the router perform next-hop determination again rather than continue sending traffic to the (deleted) router.
デフォルトのルータリスト内のエントリの有効期間が期限切れになるたびに、そのエントリは破棄されます。デフォルトのルータリストからルータを削除するとき、ノードは、ルータを使用するすべてのエントリが（削除）ルータへのトラフィックの送信を続けるのではなく、ルータを使用するすべてのエントリが再びネクストホップの決定を実行するように宛先キャッシュを更新する必要があります。
The algorithm for selecting a router depends in part on whether or not a router is known to be reachable. The exact details of how a node keeps track of a neighbor's reachability state are covered in Section 7.3. The algorithm for selecting a default router is invoked during next-hop determination when no Destination Cache entry exists for an off-link destination or when communication through an existing router appears to be failing. Under normal conditions, a router would be selected the first time traffic is sent to a destination, with subsequent traffic for that destination using the same router as indicated in the Destination Cache modulo any changes to the Destination Cache caused by Redirect messages.
ルータを選択するためのアルゴリズムは、ルータが到達可能であることがわかっているかどうかにかかわらず、部分的に依存します。ノードが隣人の到達可能性状態を追跡する方法の正確な詳細はセクション7.3で説明されています。デフォルトのルータを選択するためのアルゴリズムは、オフリンク先の宛先の宛先キャッシュエントリが存在しない場合、または既存のルータを介した通信が失敗しているように見えるときに、ネクストホップの決定中に呼び出されます。通常の条件下では、ルータが選択されます。デスティネーション・キャッシュ・モジュロに示されているのと同じルータを使用して、その宛先のトラフィックが宛先に送信されたルータが選択されます。
The policy for selecting routers from the Default Router List is as follows:
デフォルトのルータリストからルータを選択するためのポリシーは次のとおりです。
1) Routers that are reachable or probably reachable (i.e., in any state other than INCOMPLETE) SHOULD be preferred over routers whose reachability is unknown or suspect (i.e., in the INCOMPLETE state, or for which no Neighbor Cache entry exists). Further implementation hints on default router selection when multiple equivalent routers are available are discussed in [LD-SHRE].
1）到達可能またはおそらく到達可能なルータ（すなわち、不完全以外の状態では、任意の状態では）が到達可能性が不明であるか疑わしい（すなわち、不完全状態で、または隣接キャッシュエントリが存在しない）ルータよりも好ましいはずである。複数の同等のルータが利用可能な場合のデフォルトルータ選択でのさらなる実装ヒントは[LD-Shre]で説明されています。
2) When no routers on the list are known to be reachable or probably reachable, routers SHOULD be selected in a round-robin fashion, so that subsequent requests for a default router do not return the same router until all other routers have been selected.
2）リスト上のルータが到達可能か到達可能であることが知られていない場合は、ラウンドロビン方式でルータを選択する必要があるため、他のすべてのルータが選択されるまでデフォルトルータに対するその後の要求は同じルータを返さないようにします。
Cycling through the router list in this case ensures that all available routers are actively probed by the Neighbor Unreachability Detection algorithm. A request for a default router is made in conjunction with the sending of a packet to a router, and the selected router will be probed for reachability as a side effect.
この場合のルータリストを巡回すると、すべての利用可能なルータが近接到達不能検出アルゴリズムによって積極的に検査されるようにします。デフォルトルータの要求は、ルータへのパケットの送信と連携して行われ、選択されたルータは副作用としての到達可能性についてプローブされます。
When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Router Advertisement to locate default routers or learn prefixes. To obtain Router Advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages, each separated by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent after any of the following events:
インターフェイスが有効になると、ホストは次の迷惑なルータアドバタイズメントがデフォルトのルータまたは学習プレフィックスを見つけるのを待っていない可能性があります。ルータアドバタイズメントをすばやく取得するには、ホストは最大MAX_RTR_SOLICTIONSルータの勧誘メッセージを送信する必要があります。これはそれぞれ少なくともRTR_Solicate_Interval秒で区切られています。ルータの勧誘は、次のいずれかのイベントの後に送信されることがあります。
- 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 system changes from being a router to being a host, by having its IP forwarding capability turned off by system management.
- システムは、システム管理によってIP転送機能がオフになっていることによって、システムがルータであることからホストになります。
- The host attaches to a link for the first time.
- ホストは初めてリンクに接続します。
- The host re-attaches to a link after being detached for some time.
- ホストはしばらくの間切り離された後にリンクに再接続します。
A host sends Router Solicitations to the all-routers multicast address. The IP source address is set to either one of the interface's unicast addresses or the unspecified address. The Source Link-Layer Address option SHOULD be set to the host's link-layer address, if the IP source address is not the unspecified address.
ホストはルータの勧誘を全ルータマルチキャストアドレスに送信します。IP送信元アドレスは、インターフェイスのユニキャストアドレスまたは不特定アドレスのいずれかに設定されています。IP送信元アドレスが指定されていないアドレスではない場合、ソースリンク層のアドレスオプションをホストのリンク層アドレスに設定する必要があります。
Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. If a host has already performed a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]), there is no need to delay again before sending the first Router Solicitation message.
ホストが初期の勧誘を送信する前に、0からMAX_RTR_SOLITITION_DELAYの間のランダムな時間の間の送信を遅らせる必要があります。これは、停電からの回復後に発生する可能性があるなど、多くのホストが同時にリンク上で起動したときに輻輳を軽減するのに役立ちます。インタフェースは（例えば、重複アドレス検出[ADDRCONF]の一部として）、ホストがランダムな遅延を実行している場合（例えば、重複アドレス検出[ADDRCONF]の一部として）、最初のルータ勧誘メッセージを送信する前に再び遅延する必要はない。
In some cases, the random delay MAY be omitted if necessary. For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine movement to new links. Hence, if a mobile node received link-layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation depending on the level of certainty of the link-layer hints, and it is outside the scope of this specification. Note that using this mechanism inappropriately (e.g., based on weak or transient indications) may result in Router Solicitation storms. Furthermore, simultaneous mobility of a large number of mobile nodes that use this mechanism can result in a large number of solicitations sent simultaneously.
場合によっては、必要に応じてランダム遅延を省略することができます。たとえば、[MIPv6]を使用して、新しいリンクに移動するモバイルノードは、そのトポロジーの動きの変化に起因するパケット損失の量を最小限に抑えるために、できるだけ早くそのような動きを発見する必要があります。ルータ勧誘は、モバイルノードが新しいリンクへの移動を決定することを可能にするように、モバイルIPv6の移動検出のための便利なツールを提供します。したがって、モバイルノードがその移動が起こったことを示すリンク層情報を受信した場合、ランダムな遅延なしに直ちにルータの勧誘を送信することができる。そのような指示の強さは、リンク層のヒントの確実度のレベルに応じてモバイルノードの実装によって評価されるべきであり、そしてそれはこの仕様の範囲外です。このメカニズムを不適切に（例えば、弱いまたは一時的な表示に基づいて）ルータの勧誘の嵐をもたらす可能性があることに注意してください。さらに、このメカニズムを使用する多数のモバイルノードの同時モビリティは、同時に送信された多数の勧誘をもたらす可能性があります。
Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs. Moreover, a host SHOULD send at least one solicitation in the case where an advertisement is received prior to having sent a solicitation. Responses to solicited advertisements may contain more information than unsolicited advertisements.
ホストがルータの勧誘を送信し、ゼロ以外のルータの有効期間を持つ有効なルータアドバタイズメントを受信すると、次に上記のイベントの1つが発生するまで、ホストはそのインターフェイス上で追加の契約を送信することを却下する必要があります。さらに、ホストは、勧誘を送信する前に広告が受信された場合に少なくとも1つの勧誘を送るべきである。勧誘広告に対する回答は、迷惑な広告よりも多くの情報を含めることができます。
If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY seconds after sending the last solicitation, the host concludes that there are no routers on the link for the purpose of [ADDRCONF]. However, the host continues to receive and process Router Advertisements messages in the event that routers appear on the link.
ホストがMAX_RTR_SOLITISTATION_DELAYを受信した場合、最後の勧誘を送信してからMAX_RTR_SOLITITION_DELAY秒を待ってからルータアドバタイズメントを受信しなかった場合、ホストは[ADDRCONF]の目的のためにリンク上にルータがないと結論付けられます。ただし、ルータがリンクに表示された場合に、ホストはルータアドバタイズメントメッセージを受信して処理し続けます。
This section describes the functions related to Neighbor Solicitation and Neighbor Advertisement messages and includes descriptions of address resolution and the Neighbor Unreachability Detection algorithm.
このセクションでは、ネイバー勧誘とネイバー広告メッセージに関連する機能について説明し、アドレス解決と近隣の到達不能検出アルゴリズムの説明が含まれています。
Neighbor Solicitation and Advertisement messages are also used for Duplicate Address Detection as specified by [ADDRCONF]. In particular, Duplicate Address Detection sends Neighbor Solicitation messages with an unspecified source address targeting its own "tentative" address. Such messages trigger nodes already using the address to respond with a multicast Neighbor Advertisement indicating that the address is in use.
隣接勧誘および広告メッセージは、[ADDRCONF]で指定された重複アドレス検出にも使用されます。特に、重複アドレス検出は、それ自身の「暫定的な」アドレスを対象とした不特定の送信元アドレスと隣接勧誘メッセージを送信します。そのようなメッセージは、アドレスが使用中であることを示すマルチキャストネイバーアドバタイズメントで応答するために既にアドレスを使用してノードをトリガします。
A node MUST silently discard any received Neighbor Solicitation messages that do not satisfy all of the following validity checks:
ノードは、以下のすべての有効性チェックを満たさない受信された隣接勧誘メッセージを静かに破棄しなければなりません。
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IPホップ制限フィールドは、値255、すなわちパケットがルータによって転送された可能性がある。
- ICMP Checksum is valid.
- ICMPチェックサムが有効です。
- ICMP Code is 0.
- ICMPコードは0です。
- ICMP length (derived from the IP length) is 24 or more octets.
- ICMP長（IP長から派生された）は24オクテットです。
- Target Address is not a multicast address.
- ターゲットアドレスはマルチキャストアドレスではありません。
- All included options have a length that is greater than zero.
- 含まれるすべてのオプションは、ゼロより大きい長さを持ちます。
- If the IP source address is the unspecified address, the IP destination address is a solicited-node multicast address.
- IP送信元アドレスが指定されていないアドレスである場合、IP宛先アドレスは勧誘ノードマルチキャストアドレスです。
- If the IP source address is the unspecified address, there is no source link-layer address option in the message.
- IP送信元アドレスが不特定アドレスの場合、メッセージにソースリンクレイヤアドレスオプションはありません。
The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
予約フィールドの内容、および認識されていないオプションは無視する必要があります。将来、プロトコルへの下位互換性のある変更は、予約フィールドの内容を指定したり、新しいオプションを追加することができます。後方互換性のない変更は、異なるコード値を使用できます。
The contents of any defined options that are not specified to be used with Neighbor Solicitation messages MUST be ignored and the packet processed as normal. The only defined option that may appear is the Source Link-Layer Address option.
隣接勧誘メッセージで使用されるように指定されていない定義されたオプションの内容は無視され、パケットは通常として処理されなければなりません。表示される可能性がある唯一の定義済みオプションは、ソースリンク層アドレスオプションです。
A Neighbor Solicitation that passes the validity checks is called a "valid solicitation".
有効性チェックを渡す隣接勧誘は「有効な勧誘」と呼ばれます。
A node MUST silently discard any received Neighbor Advertisement messages that do not satisfy all of the following validity checks:
ノードは、以下のすべての有効性チェックを満たさない、受信したネイバーアドバタイズメッセージを静かに破棄しなければなりません。
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IPホップ制限フィールドは、値255、すなわちパケットがルータによって転送された可能性がある。
- ICMP Checksum is valid.
- ICMPチェックサムが有効です。
- ICMP Code is 0.
- ICMPコードは0です。
- ICMP length (derived from the IP length) is 24 or more octets.
- ICMP長（IP長から派生された）は24オクテットです。
- Target Address is not a multicast address.
- ターゲットアドレスはマルチキャストアドレスではありません。
- If the IP Destination Address is a multicast address the Solicited flag is zero.
- IP宛先アドレスがマルチキャストアドレスである場合、勧誘フラグはゼロです。
- All included options have a length that is greater than zero.
- 含まれるすべてのオプションは、ゼロより大きい長さを持ちます。
The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
予約フィールドの内容、および認識されていないオプションは無視する必要があります。将来、プロトコルへの下位互換性のある変更は、予約フィールドの内容を指定したり、新しいオプションを追加することができます。後方互換性のない変更は、異なるコード値を使用できます。
The contents of any defined options that are not specified to be used with Neighbor Advertisement messages MUST be ignored and the packet processed as normal. The only defined option that may appear is the Target Link-Layer Address option.
ネイバーアドバタイズメントメッセージで使用されるように指定されていない定義されていないオプションの内容は無視され、パケットは通常どおりに処理されている必要があります。表示される可能性がある唯一の定義されたオプションは、ターゲットリンク層アドレスオプションです。
A Neighbor Advertisements that passes the validity checks is called a "valid advertisement".
有効性チェックを渡す近隣アドバタイズメントは、「有効な広告」と呼ばれます。
Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Address resolution is performed only on addresses that are determined to be on-link and for which the sender does not know the corresponding link-layer address (see Section 5.2). Address resolution is never performed on multicast addresses.
アドレス解決は、そのIPアドレスのみが与えられたネイバーのリンク層アドレスをノードが決定するプロセスです。アドレス解決は、オンリンクであると決定され、送信側が対応するリンク層アドレスを知らないアドレスでのみ実行されます（セクション5.2を参照）。アドレス解決はマルチキャストアドレスでは実行されません。
It is possible that a host may receive a solicitation, a router advertisement, or a Redirect message without a link-layer address option included. These messages MUST NOT create or update neighbor cache entries, except with respect to the IsRouter flag as specified in Sections 6.3.4 and 7.2.5. If a Neighbor Cache entry does not exist for the source of such a message, Address Resolution will be required before unicast communications with that address can begin. This is particularly relevant for unicast responses to solicitations where an additional packet exchange is required for advertisement delivery.
ホストは、リンク層アドレスオプションが含まれていないリダイレクトメッセージ、またはリダイレクトメッセージを受信することができる可能性がある。これらのメッセージは、セクション6.3.4および7.2.5で指定されているように、ISROUTERフラグを除いて、ネイバーキャッシュエントリを作成または更新してはいけません。そのようなメッセージのソースに対してネイバーキャッシュエントリが存在しない場合、そのアドレスとのユニキャスト通信が開始される前にアドレス解決が必要になります。これは、広告配信に追加のパケット交換が必要な勧誘対策に対するユニキャスト応答に特に関連しています。
When a multicast-capable interface becomes enabled, the node MUST join the all-nodes multicast address on that interface, as well as the solicited-node multicast address corresponding to each of the IP addresses assigned to the interface.
マルチキャスト対応インタフェースが有効になると、ノードはそのインターフェイス上のすべてのノードマルチキャストアドレス、およびインターフェイスに割り当てられている各IPアドレスに対応する要求ノードマルチキャストアドレスに参加する必要があります。
The set of addresses assigned to an interface may change over time. New addresses might be added and old addresses might be removed [ADDRCONF]. In such cases the node MUST join and leave the solicited-node multicast address corresponding to the new and old addresses, respectively. Joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols. Note that multiple unicast addresses may map into the same solicited-node multicast address; a node MUST NOT leave the solicited-node multicast group until all assigned addresses corresponding to that multicast address have been removed.
インターフェイスに割り当てられているアドレスのセットは時間とともに変化する可能性があります。新しいアドレスが追加され、古いアドレスが[ADDRCONF]削除される可能性があります。そのような場合、ノードはそれぞれ新しいアドレスと古いアドレスに対応する勧誘ノードマルチキャストアドレスをそれぞれ結合して残す必要があります。勧誘ノードマルチキャストアドレスの結合は、[MLD]または[MLDv2]プロトコルなどのマルチキャストリスナーディスカバリを使用して行われます。複数のユニキャストアドレスは、同じ勧誘ノードマルチキャストアドレスにマッピングされる可能性があることに注意してください。そのマルチキャストアドレスに対応するすべての割り当てられたアドレスが削除されるまで、ノードは義務付けノードマルチキャストグループを離れてはいけません。
When a node has a unicast packet to send to a neighbor, but does not know the neighbor's link-layer address, it performs address resolution. For multicast-capable interfaces, this entails creating a Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Solicitation message targeted at the neighbor. The solicitation is sent to the solicited-node multicast address corresponding to the target address.
ノードが隣接に送信するようにユニキャストパケットを持つが、ネイバーのリンクレイヤアドレスがわからない場合は、アドレス解決を実行します。マルチキャスト対応インタフェースの場合、これは不完全な状態でネイバーキャッシュエントリを作成し、ネイバーをターゲットにした隣接勧誘メッセージを送信することを伴います。勧誘は、ターゲットアドレスに対応する勧誘ノードマルチキャストアドレスに送信されます。
If the source address of the packet prompting the solicitation is the same as one of the addresses assigned to the outgoing interface, that address SHOULD be placed in the IP Source Address of the outgoing solicitation. Otherwise, any one of the addresses assigned to the interface should be used. Using the prompting packet's source address when possible ensures that the recipient of the Neighbor Solicitation installs in its Neighbor Cache the IP address that is highly likely to be used in subsequent return traffic belonging to the prompting packet's "connection".
勧誘を促すパケットの送信元アドレスが、発信インターフェイスに割り当てられているアドレスの1つと同じである場合、そのアドレスは発信要請のIP送信元アドレスに配置する必要があります。それ以外の場合は、インターフェイスに割り当てられているアドレスのいずれかを使用する必要があります。可能であればプロンプトのパケットの送信元アドレスを使用すると、ネイバー勧誘の受信者がそのネイバーキャッシュにインストールされていることを確認します。プロンプトパケットの「接続」に属する後続の戻りトラフィックで使用される可能性が高いIPアドレス。
If the solicitation is being sent to a solicited-node multicast address, the sender MUST include its link-layer address (if it has one) as a Source Link-Layer Address option. Otherwise, the sender SHOULD include its link-layer address (if it has one) as a Source Link-Layer Address option. Including the source link-layer address in a multicast solicitation is required to give the target an address to which it can send the Neighbor Advertisement. On unicast solicitations, an implementation MAY omit the Source Link-Layer Address option. The assumption here is that if the sender has a peer's link-layer address in its cache, there is a high probability that the peer will also have an entry in its cache for the sender. Consequently, it need not be sent.
勧誘が要請されたノードマルチキャストアドレスに送信されている場合、送信者はそのリンクレイヤアドレス（1つが1つ持っている場合）をソースリンク層アドレスオプションとして含める必要があります。それ以外の場合、送信側はそのリンク層アドレス（1がある場合）をソースリンク層アドレスオプションとして含める必要があります。マルチキャスト勧誘におけるソースリンク層アドレスを含めて、ターゲットに隣接アドバタイズメントを送信できるアドレスを与えるために必要です。ユニキャスト解消では、実装はソースリンク層アドレスオプションを省略することがあります。ここでの仮定は、送信者がそのキャッシュ内のピアのリンク層アドレスを持つ場合、ピアに送信者のキャッシュ内にエントリを持つ可能性が高いことです。その結果、送信する必要はありません。
While waiting for address resolution to complete, the sender MUST, for each neighbor, retain a small queue of packets waiting for address resolution to complete. The queue MUST hold at least one packet, and MAY contain more. However, the number of queued packets per neighbor SHOULD be limited to some small value. When a queue overflows, the new arrival SHOULD replace the oldest entry. Once address resolution completes, the node transmits any queued packets.
アドレス解決を完了するのを待っている間、送信者は各ネイバーに対して、アドレス解決を完了するのを待っているパケットの小さなキューを保持しなければなりません。キューは少なくとも1つのパケットを保持し、さらに含めることができます。ただし、隣接当たりのキューに入れられたパケットの数は、いくつかの小さい値に制限されるべきです。キューがオーバーフローすると、新しい到着は最も古いエントリを置き換える必要があります。アドレス解決完了が完了すると、ノードはキューに入れられたパケットを送信します。
While awaiting a response, the sender SHOULD retransmit Neighbor Solicitation messages approximately every RetransTimer milliseconds, even in the absence of additional traffic to the neighbor. Retransmissions MUST be rate-limited to at most one solicitation per neighbor every RetransTimer milliseconds.
応答を待っている間、送信者は、追加のトラフィックがない場合でも、隣接勧誘メッセージをほぼすべてのRetranStimerのミリ秒を再送信する必要があります。再送信は、隣接当たりの最大1つの勧誘に、RetranStimerミリ秒ごとにrateに制限されなければならない。
If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT solicitations, address resolution has failed. The sender MUST return ICMP destination unreachable indications with code 3 (Address Unreachable) for each packet queued awaiting address resolution.
MAX_MULTICAST_SOLICICICITの後にネイバーアドバタイズメントが受信されない場合は、アドレス解決に失敗しました。送信者は、アドレス解決待ちエイジアウェイエイジアドレス解決の各パケットごとに、ICMP宛先到達不能指示をコード3（アドレス到達不能）に返さなければなりません。
A valid Neighbor Solicitation that does not meet any of the following requirements MUST be silently discarded:
次の要件のいずれかを満たさない有効な隣接勧誘は、静かに破棄されなければなりません。
- The Target Address is a "valid" unicast or anycast address assigned to the receiving interface [ADDRCONF],
- ターゲットアドレスは、受信インタフェース[ADDRCONF]に割り当てられている「有効な」ユニキャストまたはエニーキャストアドレスです。
- The Target Address is a unicast or anycast address for which the node is offering proxy service, or
- ターゲットアドレスは、ノードがプロキシサービスを提供しているユニキャストアドレスまたはエニーキャストアドレスです。
- The Target Address is a "tentative" address on which Duplicate Address Detection is being performed [ADDRCONF].
- ターゲットアドレスは、重複アドレス検出が実行されている「ADDRCONF」が実行されている「暫定的な」アドレスです。
If the Target Address is tentative, the Neighbor Solicitation should be processed as described in [ADDRCONF]. Otherwise, the following description applies. If the Source Address is not the unspecified address and, on link layers that have addresses, the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation. If an entry does not already exist, the node SHOULD create a new one and set its reachability state to STALE as specified in Section 7.3.3. If an entry already exists, and the cached link-layer address differs from the one in the received Source Link-Layer option, the cached address should be replaced by the received address, and the entry's reachability state MUST be set to STALE.
ターゲットアドレスが暫定的な場合は、[ADDRCONF]に記載されているように隣接勧誘を処理する必要があります。そうでなければ、以下の説明は適用されます。送信元アドレスが未指定アドレスではなく、アドレスを持つリンクレイヤでは、勧誘はソースリンクレイヤアドレスオプションを含み、受信者は勧誘のIP送信元アドレスのネイバーキャッシュエントリを作成または更新する必要があります。エントリがまだ存在しない場合、ノードは新しいものを作成し、セクション7.3.3で指定されているように到達可能性状態を定義に設定する必要があります。エントリがすでに存在し、キャッシュされたリンクレイヤアドレスが受信したソースリンク層オプションの1つと異なる場合は、キャッシュされたアドレスを受信したアドレスに置き換え、エントリの到達可能性状態を古く設定する必要があります。
If a Neighbor Cache entry is created, the IsRouter flag SHOULD be set to FALSE. This will be the case even if the Neighbor Solicitation is sent by a router since the Neighbor Solicitation messages do not contain an indication of whether or not the sender is a router. In the event that the sender is a router, subsequent Neighbor Advertisement or Router Advertisement messages will set the correct IsRouter value. If a Neighbor Cache entry already exists, its IsRouter flag MUST NOT be modified.
ネイバーキャッシュエントリが作成された場合は、isrouterフラグをFalseに設定する必要があります。隣接勧誘メッセージには、送信者がルータがあるかどうかの表示が含まれていないため、隣接勧誘がルータによって送信された場合でもこれは事実です。送信者がルータである場合、その後の隣接アドバタイズメントまたはルータ広告メッセージが正しいISROUTER値を設定します。隣接キャッシュエントリがすでに存在する場合、そのISROUTERフラグは変更してはいけません。
If the Source Address is the unspecified address, the node MUST NOT create or update the Neighbor Cache entry.
送信元アドレスが未指定アドレスの場合、ノードはネイバーキャッシュエントリを作成または更新してはいけません。
After any updates to the Neighbor Cache, the node sends a Neighbor Advertisement response as described in the next section.
隣接キャッシュへの更新があれば、ノードは次のセクションで説明されているようにネイバーアドバタイズメント応答を送信します。
A node sends a Neighbor Advertisement in response to a valid Neighbor Solicitation targeting one of the node's assigned addresses. The Target Address of the advertisement is copied from the Target Address of the solicitation. If the solicitation's IP Destination Address is not a multicast address, the Target Link-Layer Address option MAY be omitted; the neighboring node's cached value must already be current in order for the solicitation to have been received. If the solicitation's IP Destination Address is a multicast address, the Target Link-Layer option MUST be included in the advertisement. Furthermore, if the node is a router, it MUST set the Router flag to one; otherwise, it MUST set the flag to zero.
ノードは、ノードの割り当てられたアドレスの1つをターゲットとする有効な隣接勧誘に応答してネイバーアドバタイズメントを送信します。広告のターゲットアドレスは勧誘のターゲットアドレスからコピーされます。勧誘のIP宛先アドレスがマルチキャストアドレスではない場合は、ターゲットリンク層アドレスオプションを省略することができます。勧誘が受信されたために、隣接ノードのキャッシュされた値はすでに最新のものでなければなりません。勧誘のIP宛先アドレスがマルチキャストアドレスである場合は、ターゲットリンクレイヤオプションを広告に含める必要があります。さらに、ノードがルータの場合は、ルータフラグを1に設定する必要があります。それ以外の場合は、フラグをゼロに設定する必要があります。
If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included, the Override flag SHOULD be set to zero. Otherwise, the Override flag SHOULD be set to one. Proper setting of the Override flag ensures that nodes give preference to non-proxy advertisements, even when received after proxy advertisements, and also ensures that the first advertisement for an anycast address "wins".
ターゲットアドレスが、ノードがプロキシサービスを提供しているエニーキャストアドレスまたはUnicastアドレスであるか、またはターゲットリンク層アドレスオプションが含まれていない場合は、オーバーライドフラグをゼロに設定する必要があります。それ以外の場合は、オーバーライドフラグを1に設定する必要があります。オーバーライドフラグの適切な設定は、プロキシ広告の後に受信された場合でも、ノードは非プロキシ広告を好み、また、エニーキャストアドレスの最初の広告が「WINS」であることを保証します。
If the source of the solicitation is the unspecified address, the node MUST set the Solicited flag to zero and multicast the advertisement to the all-nodes address. Otherwise, the node MUST set the Solicited flag to one and unicast the advertisement to the Source Address of the solicitation.
勧誘の原因が指定されていないアドレスである場合、ノードは求められたフラグをゼロに設定し、広告を全ノードアドレスにマルチキャストする必要があります。それ以外の場合、ノードは勧誘フラグを1つに設定し、広告を勧誘の送信元アドレスに設定する必要があります。
If the Target Address is an anycast address, the sender SHOULD delay sending a response for a random time between 0 and MAX_ANYCAST_DELAY_TIME seconds.
ターゲットアドレスがAnycastアドレスである場合、送信側は0からMAX_Anycast_deLay_time秒の間のランダムな時間の応答の送信を遅らせる必要があります。
Because unicast Neighbor Solicitations are not required to include a Source Link-Layer Address, it is possible that a node sending a solicited Neighbor Advertisement does not have a corresponding link-layer address for its neighbor in its Neighbor Cache. In such situations, a node will first have to use Neighbor Discovery to determine the link-layer address of its neighbor (i.e., send out a multicast Neighbor Solicitation).
ユニキャストネイバー勧誘はソースリンク層アドレスを含める必要がないため、勧誘さのネイバーアドバタイズメントを送信するノードに、そのネイバーキャッシュ内のネイバーの対応するリンクレイヤアドレスがありません。そのような状況では、ノードは最初に隣接発見を使用してその隣接のリンク層アドレスを決定しなければならない（すなわち、マルチキャスト隣接勧誘を送信する）。
When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target.
有効なネイバーアドバタイズメントを受信した場合（要請または迷惑メール）、隣接キャッシュがターゲットのエントリを検索します。エントリが存在しない場合、広告は黙って破棄されるべきです。受信者は明らかにターゲットとの通信を開始していないので、何も存在しない場合はエントリを作成する必要はありません。
Once the appropriate Neighbor Cache entry has been located, the specific actions taken depend on the state of the Neighbor Cache entry, the flags in the advertisement, and the actual link-layer address supplied.
適切な隣接キャッシュエントリが見つかったら、実行される特定のアクションは、隣接キャッシュエントリの状態、広告内のフラグ、および提供された実際のリンク層アドレスによって異なります。
If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the link layer has addresses and no Target Link-Layer Address option is included, the receiving node SHOULD silently discard the received advertisement. Otherwise, the receiving node performs the following steps:
広告が受信されたときにターゲットの近隣キャッシュエントリが不完全な状態にある場合、2つのことのうちの1つが起こります。リンクレイヤがアドレスを持ち、ターゲットリンク層アドレスオプションが含まれていない場合、受信ノードは受信した広告を静かに破棄する必要があります。それ以外の場合、受信側ノードは次のステップを実行します。
- It records the link-layer address in the Neighbor Cache entry.
- リンクレイヤアドレスをネイバーキャッシュエントリに記録します。
- If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE; otherwise, it is set to STALE.
- 広告の勧誘フラグが設定されている場合、エントリの状態は到達可能に設定されます。それ以外の場合は、古くなるように設定されています。
- It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement.
- 受信したアドバタイズメントのルータフラグに基づいて、ASROUTERフラグをキャッシュエントリに設定します。
- It sends any packets queued for the neighbor awaiting address resolution.
- 近隣の待機アドレス解決のためにキューに入れられたパケットを送信します。
Note that the Override flag is ignored if the entry is in the INCOMPLETE state.
エントリが不完全状態にある場合、オーバーライドフラグは無視されます。
If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the following actions take place:
ターゲットのネイバーキャッシュエントリが、広告が受信されたときに不完全以外の状態にある場合は、次の操作が行われます。
I. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: a. If the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way. b. Otherwise, the received advertisement should be ignored and MUST NOT update the cache.
I.上書きフラグがクリアで、提供されたリンク層アドレスがキャッシュ内のそれと異なる場合は、2つのアクションのうちの1つが行われます。エントリの状態が到達可能な場合は、古く設定しますが、その他の方法でエントリを更新しないでください。b。それ以外の場合は、受信した広告を無視しており、キャッシュを更新しないでください。
II. If the Override flag is set, or the supplied link-layer address is the same as that in the cache, or no Target Link-Layer Address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows:
ii。オーバーライドフラグが設定されているか、または提供されたリンク層アドレスがキャッシュ内のそれと同じ場合、またはターゲットリンクレイヤアドレスオプションが指定されていない場合、受信したアドバタイズメントは次のようにネイバーキャッシュエントリを更新する必要があります。
- The link-layer address in the Target Link-Layer Address option MUST be inserted in the cache (if one is supplied and differs from the already recorded address).
- ターゲットリンク層アドレスオプションのリンクレイヤアドレスをキャッシュに挿入する必要があります（指定されている場合は既存のアドレスとは異なります）。
- If the Solicited flag is set, the state of the entry MUST be set to REACHABLE. If the Solicited flag is zero and the link-layer address was updated with a different address, the state MUST be set to STALE. Otherwise, the entry's state remains unchanged.
- 勧誘フラグが設定されている場合は、エントリの状態を到達可能に設定する必要があります。勧誘フラグがゼロで、リンク層アドレスが異なるアドレスで更新された場合は、状態を古く設定する必要があります。それ以外の場合、エントリの状態は変わりません。
An advertisement's Solicited flag should only be set if the advertisement is a response to a Neighbor Solicitation. Because Neighbor Unreachability Detection Solicitations are sent to the cached link-layer address, receipt of a solicited advertisement indicates that the forward path is working. Receipt of an unsolicited advertisement, however, may indicate that a neighbor has urgent information to announce (e.g., a changed link-layer address). If the urgent information indicates a change from what a node is currently using, the node should verify the reachability of the (new) path when it sends the next packet. There is no need to update the state for unsolicited advertisements that do not change the contents of the cache.
広告の勧誘フラグは、広告が隣接勧誘に対する回答である場合にのみ設定されるべきです。ネイバーの到達不可能な検出勧誘はキャッシュされたリンク層アドレスに送信されるため、要請された広告の受信は、前方パスが機能していることを示します。しかしながら、迷惑な広告の受信は、隣接者がアナウンスする緊急情報（例えば、変更されたリンク層アドレス）を有することを示すことができる。緊急情報が現在ノードが使用しているものからの変更を示している場合、ノードは次のパケットを送信したときの（新規）パスの到達可能性を検証する必要があります。キャッシュの内容を変更しない迷惑なアドバタイズメントの状態を更新する必要はありません。
- The IsRouter flag in the cache entry MUST be set based on the Router flag in the received advertisement. In those cases where the IsRouter flag changes from TRUE to FALSE as a result of this update, the node MUST remove that router from the Default Router List and update the Destination Cache entries for all destinations using that neighbor as a router as specified in Section 7.3.3. This is needed to detect when a node that is used as a router stops forwarding packets due to being configured as a host.
- キャッシュエントリ内のISROUTERフラグは、受信したアドバタイズメントのルータフラグに基づいて設定する必要があります。このアップデートの結果としてISROUTERフラグがTRUEからFALSEに変わる場合、ノードはデフォルトのルータリストからそのルータを削除し、そのネイバーを使用してすべての宛先の宛先キャッシュエントリをセクション7.3で指定されているように更新する必要があります。.3。これは、ルータとして使用されるノードがホストとして構成されているため、パケットの転送を停止するときに検出する必要があります。
The above rules ensure that the cache is updated either when the Neighbor Advertisement takes precedence (i.e., the Override flag is set) or when the Neighbor Advertisement refers to the same link-layer address that is currently recorded in the cache. If none of the above apply, the advertisement prompts future Neighbor Unreachability Detection (if it is not already in progress) by changing the state in the cache entry.
上記の規則は、ネイバー広告が優先されたとき（すなわち、上書きフラグが設定されている場合）、またはネイバー広告が現在キャッシュ内に記録されている同じリンク層アドレスを参照している場合にもキャッシュが更新されていることを確認します。上記のいずれも適用されていない場合、広告はキャッシュエントリ内の状態を変更することによって将来の近隣の到達不能検出（まだ進行中の場合）を促します。
In some cases, a node may be able to determine that its link-layer address has changed (e.g., hot-swap of an interface card) and may wish to inform its neighbors of the new link-layer address quickly. In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited Neighbor Advertisement messages to the all-nodes multicast address. These advertisements MUST be separated by at least RetransTimer seconds.
場合によっては、ノードは、そのリンク層アドレスが変更された（例えば、インターフェースカードのホットスワップ）、その近隣に新しいリンク層アドレスを迅速に通知することを望むことができる。そのような場合、ノードは、迷惑なネイバーアドレスメッセージを全ノードマルチキャストアドレスに送信することができる。これらの広告は少なくともRetranStimer秒で区切る必要があります。
The Target Address field in the unsolicited advertisement is set to an IP address of the interface, and the Target Link-Layer Address option is filled with the new link-layer address. The Solicited flag MUST be set to zero, in order to avoid confusing the Neighbor Unreachability Detection algorithm. If the node is a router, it MUST set the Router flag to one; otherwise, it MUST set it to zero. The Override flag MAY be set to either zero or one. In either case, neighboring nodes will immediately change the state of their Neighbor Cache entries for the Target Address to STALE, prompting them to verify the path for reachability. If the Override flag is set to one, neighboring nodes will install the new link-layer address in their caches. Otherwise, they will ignore the new link-layer address, choosing instead to probe the cached address.
迷惑なアドバタイズメントのターゲットアドレスフィールドはインタフェースのIPアドレスに設定され、ターゲットリンク層アドレスオプションは新しいリンクレイヤアドレスで埋められます。近隣の到達不能検出アルゴリズムを混乱させるのを避けるために、勧誘フラグはゼロに設定されなければならない。ノードがルータの場合は、ルータフラグを1に設定する必要があります。それ以外の場合は、ゼロに設定する必要があります。オーバーライドフラグは、0または1に設定されてもよい。どちらの場合でも、隣接ノードはターゲットアドレスのネイバーキャッシュエントリの状態を古く、到達可能性のパスを確認するように促します。オーバーライドフラグが1に設定されている場合、隣接ノードは自分のキャッシュに新しいリンクレイヤアドレスをインストールします。それ以外の場合、それらは新しいリンク層アドレスを無視し、代わりにキャッシュされたアドレスを調べることを選択します。
A node that has multiple IP addresses assigned to an interface MAY multicast a separate Neighbor Advertisement for each address. In such a case, the node SHOULD introduce a small delay between the sending of each advertisement to reduce the probability of the advertisements being lost due to congestion.
インターフェースに割り当てられている複数のIPアドレスを有するノードは、各アドレスに対して別々のネイバーアドバタイズメントをマルチキャストすることができる。そのような場合、ノードは各広告の送信間に小さな遅延を導入して、輻輳により広告が失われる可能性を減らすべきである。
A proxy MAY multicast Neighbor Advertisements when its link-layer address changes or when it is configured (by system management or other mechanisms) to proxy for an address. If there are multiple nodes that are providing proxy services for the same set of addresses, the proxies should provide a mechanism that prevents multiple proxies from multicasting advertisements for any one address, in order to reduce the risk of excessive multicast traffic. This is a requirement on other protocols that need to use proxies for Neighbor Advertisements. An example of a node that performs proxy advertisements is the Home Agent specified in [MIPv6].
リンク層のアドレスが変更されたとき、またはそれが（システム管理または他のメカニズムによって）アドレスに対するプロキシに設定されたときに（システム管理または他のメカニズムによって）。同じアドレスセットに対してプロキシサービスを提供している複数のノードがある場合、プロキシは、過度のマルチキャストトラフィックのリスクを減らすために、1つのアドレスについて複数のプロキシを妨げるメカニズムを提供する必要があります。これは、ネイバーアドバタイズメントのプロキシを使用する必要がある他のプロトコルに対する要件です。プロキシ広告を実行するノードの例は、[MIPv6]で指定されたホームエージェントです。
Also, a node belonging to an anycast address MAY multicast unsolicited Neighbor Advertisements for the anycast address when the node's link-layer address changes.
また、ノードのリンク層アドレスが変更されたときに、エニーキャストアドレスに属するノードは、エニーキャストアドレスに対して迷惑メールアドレスのマルチキャストをマルチキャストすることができる。
Note that because unsolicited Neighbor Advertisements do not reliably update caches in all nodes (the advertisements might not be received by all nodes), they should only be viewed as a performance optimization to quickly update the caches in most neighbors. The Neighbor Unreachability Detection algorithm ensures that all nodes obtain a reachable link-layer address, though the delay may be slightly longer.
迷惑なネイバー広告がすべてのノードで信頼性が確実にアップデートされないため（広告はすべてのノードで受信されない可能性がある）、それらはほとんどの隣人でキャッシュを迅速に更新するためのパフォーマンス最適化としてのみ表示されるべきです。近隣の到達不能検出アルゴリズムにより、遅延はわずかに長くなる可能性があるが、すべてのノードが到達可能なリンク層アドレスを取得することを保証します。
From the perspective of Neighbor Discovery, anycast addresses are treated just like unicast addresses in most cases. Because an anycast address is syntactically the same as a unicast address, nodes performing address resolution or Neighbor Unreachability Detection on an anycast address treat it as if it were a unicast address. No special processing takes place.
近隣探索の観点からは、ほとんどの場合、アニキャストアドレスはユニキャストアドレスのように扱われます。エニーキャストアドレスは、ユニキャストアドレスと同じであるため、アドレス解像度またはネイバーの到達不能検出を実行するノードは、それをユニキャストアドレスであるかのように扱います。特別な処理は行われません。
Nodes that have an anycast address assigned to an interface treat them exactly the same as if they were unicast addresses with two exceptions. First, Neighbor Advertisements sent in response to a Neighbor Solicitation SHOULD be delayed by a random time between 0 and MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, so that when multiple advertisements are received, the first received advertisement is used rather than the most recently received advertisement.
インターフェースに割り当てられているエニーキャストアドレスを持つノードは、2つの例外を持つユニキャストアドレスである場合とまったく同じです。まず、隣接勧誘に応答して送信された近隣広告は、ネットワークの輻輳の可能性を減らすために、0からMAX_Anycast_Delay_timeの間のランダムな時間によって遅延されるべきです。第二に、近隣アドバタイズメントのオーバーライドフラグは0に設定されるべきであるため、複数の広告が受信されると、最初に受信された広告が最も最近受信された広告ではなく使用されます。
As with unicast addresses, Neighbor Unreachability Detection ensures that a node quickly detects when the current binding for an anycast address becomes invalid.
ユニキャストアドレスと同様に、近隣の到達不能検出は、エニーキャストアドレスの現在のバインディングが無効になったときにノードが迅速に検出されるようになります。
Under limited circumstances, a router MAY proxy for one or more other nodes, that is, through Neighbor Advertisements indicate that it is willing to accept packets not explicitly addressed to itself. For example, a router might accept packets on behalf of a mobile node that has moved off-link. The mechanisms used by proxy are essentially the same as the mechanisms used with anycast addresses.
限られた状況下では、ルータは1つ以上の他のノードに対してプロキシ、すなわち、近隣の広告を通じて、それが明示的にそれ自体に対処されていないパケットを受け入れることを望んでいることを示している。たとえば、ルータがオフリンクを移動したモバイルノードに代わってパケットを受け入れることがあります。プロキシによって使用されるメカニズムは、エニーキャストアドレスで使用されるメカニズムと基本的に同じです。
A proxy MUST join the solicited-node multicast address(es) that correspond to the IP address(es) assigned to the node for which it is proxying. This SHOULD be done using a multicast listener discovery protocol such as [MLD] or [MLDv2].
プロキシは、プロキシがプロキシしているノードに割り当てられているIPアドレス（ES）に対応する要請ノードマルチキャストアドレス（ES）に参加する必要があります。これは、[MLD]や[MLDv2]などのマルチキャストリスナーディスカバリプロトコルを使用して行う必要があります。
All solicited proxy Neighbor Advertisement messages MUST have the Override flag set to zero. This ensures that if the node itself is present on the link, its Neighbor Advertisement (with the Override flag set to one) will take precedence of any advertisement received from a proxy. A proxy MAY send unsolicited advertisements with the Override flag set to one as specified in Section 7.2.6, but doing so may cause the proxy advertisement to override a valid entry created by the node itself.
すべての要請されたプロキシのネイバーアドバタイズメントメッセージは、オーバーライドフラグがゼロに設定されている必要があります。これにより、ノード自体がリンク上に存在する場合、そのネイバー広告（オーバーライドフラグが1に設定されている）は、プロキシから受信した広告の優先順位が優先されます。プロキシは、セクション7.2.6で指定されたものに設定されているものに設定されている迷惑な広告を送信することができますが、プロキシ広告がノード自体によって作成された有効なエントリをオーバーライドさせる可能性があります。
Finally, when sending a proxy advertisement in response to a Neighbor Solicitation, the sender should delay its response by a random time between 0 and MAX_ANYCAST_DELAY_TIME seconds to avoid collisions due to multiple responses sent by several proxies. However, in some cases (e.g., Mobile IPv6) where only one proxy is present, such delay is not necessary.
最後に、近隣の勧誘に応答してプロキシ広告を送信するとき、送信者は、複数のプロキシによって送信された複数の応答による衝突を回避するために、0からMAX_Anycast_delay_time秒の間のランダムな時間によってその応答を遅らせるべきです。しかし、1つのプロキシが存在する場合には（例えば、モバイルIPv6）場合によっては、そのような遅延は必要ではない。
Communication to or through a neighbor may fail for numerous reasons at any time, including hardware failure, hot-swap of an interface card, etc. If the destination has failed, no recovery is possible and communication fails. On the other hand, if it is the path that has failed, recovery may be possible. Thus, a node actively tracks the reachability "state" for the neighbors to which it is sending packets.
隣接との間、または隣接を通しての通信は、ハードウェア障害、インターフェイスカードのホットスワップなどを含む、いつでも多数の理由で失敗する可能性があります。宛先が失敗した場合、回復は可能であり、通信は失敗しません。一方、失敗したパスであれば、回復が可能です。したがって、ノードは、パケットを送信している隣接者の到達可能性「状態」を積極的に追跡する。
Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent mechanism is available, for example, as part of the routing protocols.
近隣の到達不可検出は、ホスト間、ホストからルータ、およびルータ間通信を含む、ホストと隣接ノードの間のすべてのパスに使用されます。近隣の到達不可能な検出もルータ間で使用され得るが、例えばルーティングプロトコルの一部として同等のメカニズムが利用可能である場合には不要である。
When a path to a neighbor appears to be failing, the specific recovery procedure depends on how the neighbor is being used. If the neighbor is the ultimate destination, for example, address resolution should be performed again. If the neighbor is a router, however, attempting to switch to another router would be appropriate. The specific recovery that takes place is covered under next-hop determination; Neighbor Unreachability Detection signals the need for next-hop determination by deleting a Neighbor Cache entry.
ネイバーへのパスが失敗しているように見えると、特定の回復手順は、ネイバーの使用方法によって異なります。隣接が最終的な宛先である場合は、例えばアドレス解決を再度実行する必要があります。ただし、ネイバーがルータの場合は、別のルータに切り替えることを試みることが適切です。行われる特定の回復は、次のホップの決定の下でカバーされています。近隣の到達不可能な検出には、ネイバーキャッシュエントリを削除することによってネクストホップの決定の必要性が必要です。
Neighbor Unreachability Detection is performed only for neighbors to which unicast packets are sent; it is not used when sending to multicast addresses.
近隣の到達不能検出は、ユニキャストパケットが送信される隣接者に対してのみ実行されます。マルチキャストアドレスへの送信時には使用されません。
A neighbor is considered reachable if the node has recently received a confirmation that packets sent recently to the neighbor were received by its IP layer. Positive confirmation can be gathered in two ways: hints from upper-layer protocols that indicate a connection is making "forward progress", or receipt of a Neighbor Advertisement message that is a response to a Neighbor Solicitation message.
ノードが最近、近年送信されたパケットがそのIP層によって受信されたことを最近受信した場合、隣接が到達可能と見なされます。正の確認は2つの方法で収集できます。接続を示す上位プロトコルからのヒントは、「進行状況」、または隣接勧誘メッセージに対する応答であるネイバー広告メッセージの受信を行っています。
A connection makes "forward progress" if the packets received from a remote peer can only be arriving if recent packets sent to that peer are actually reaching it. In TCP, for example, receipt of a (new) acknowledgment indicates that previously sent data reached the peer. Likewise, the arrival of new (non-duplicate) data indicates that earlier acknowledgments are being delivered to the remote peer. If packets are reaching the peer, they must also be reaching the sender's next-hop neighbor; thus, "forward progress" is a confirmation that the next-hop neighbor is reachable. For off-link destinations, forward progress implies that the first-hop router is reachable. When available, this upper-layer information SHOULD be used.
リモートピアから受信したパケットが、そのピアに送信された最近のパケットが実際にそれに到達している場合にのみ到着できる場合は、接続が「進行状況」になります。たとえば、TCPでは、（新規）確認応答の受信は、以前に送信されたデータがピアに到達したことを示します。同様に、新しい（重複しない）データの到着は、以前の確認応答がリモートピアに配信されていることを示します。パケットがピアに到達している場合は、送信者のネクストホップ隣人にも到達している必要があります。したがって、「前方進行状況」は、ネクストホップ隣人が到達可能な確認です。オフリンク先の目的地では、前方への進行状況は、最初のホップルータが到達可能であることを意味します。利用可能な場合は、この上位層情報を使用する必要があります。
In some cases (e.g., UDP-based protocols and routers forwarding packets to hosts), such reachability information may not be readily available from upper-layer protocols. When no hints are available and a node is sending packets to a neighbor, the node actively probes the neighbor using unicast Neighbor Solicitation messages to verify that the forward path is still working.
場合によっては（例えば、UDPベースのプロトコルおよびルータがホストに転送する）、そのような到達可能性情報は、上位層プロトコルから容易に入手できない可能性がある。ヒントが利用可能で、ノードが隣接にパケットを送信していない場合、ノードはユニキャストネイバー勧誘メッセージを使用して隣接して隣接していることを確認して、転送パスがまだ動作していることを確認します。
The receipt of a solicited Neighbor Advertisement serves as reachability confirmation, since advertisements with the Solicited flag set to one are sent only in response to a Neighbor Solicitation.
要請された隣接広告の受領は到達可能性確認として機能し、勧誘フラグを持つ広告が隣接勧誘に応答してのみ送信されるので、
Receipt of other Neighbor Discovery messages, such as Router Advertisements and Neighbor Advertisement with the Solicited flag set to zero, MUST NOT be treated as a reachability confirmation. Receipt of unsolicited messages only confirms the one-way path from the sender to the recipient node. In contrast, Neighbor Unreachability Detection requires that a node keep track of the reachability of the forward path to a neighbor from its perspective, not the neighbor's perspective. Note that receipt of a solicited advertisement indicates that a path is working in both directions. The solicitation must have reached the neighbor, prompting it to generate an advertisement. Likewise, receipt of an advertisement indicates that the path from the sender to the recipient is working. However, the latter fact is known only to the recipient; the advertisement's sender has no direct way of knowing that the advertisement it sent actually reached a neighbor. From the perspective of Neighbor Unreachability Detection, only the reachability of the forward path is of interest.
求められたフラグがゼロに設定されたルータ広告やネイバー広告などの他のネイバーディスカバリメッセージの受信は、到達可能性確認として扱わないでください。迷惑メッセージの受信は、送信者から受信者ノードへの一方向パスのみを確認します。対照的に、近隣の到達不可能な検出は、隣接の視点ではなく、その観点から隣接経路の到達可能性を追跡することを必要とする必要があります。勧誘広告の受領は、経路が両方向に機能していることを示している。勧誘は隣に到達しており、広告を生成するように促す必要があります。同様に、広告の受信は、送信者から受信者へのパスが機能していることを示しています。しかしながら、後者の事実は受取人だけに知られている。広告の送信者は、それが送信した広告が実際に隣人に達したことを知る直接的な方法はありません。近隣の到達可能性検出の観点から、前方経路の到達可能性のみが興味深いものです。
A Neighbor Cache entry can be in one of five states:
ネイバーキャッシュエントリは5つの状態のいずれかになります。
INCOMPLETE Address resolution is being performed on the entry. Specifically, a Neighbor Solicitation has been sent to the solicited-node multicast address of the target, but the corresponding Neighbor Advertisement has not yet been received.
エントリに対して不完全なアドレス解決が実行されています。具体的には、隣接勧誘がターゲットの勧誘ノードマルチキャストアドレスに送信されてきたが、対応する隣接広告はまだ受信されていない。
REACHABLE Positive confirmation was received within the last ReachableTime milliseconds that the forward path to the neighbor was functioning properly. While REACHABLE, no special action takes place as packets are sent.
隣接する正確な確認は、最後の到達可能な確認を受信し、隣接する順序は正しく機能していた。到達可能ながら、パケットが送信されるにつれて特別なアクションは行われません。
STALE More than ReachableTime milliseconds have elapsed since the last positive confirmation was received that the forward path was functioning properly. While stale, no action takes place until a packet is sent.
前方の正の確認が正しく機能していたので、RECINGABLETIMEミリ秒よりも古いSTALEが経過しました。古くなっている間、パケットが送信されるまで行動は行われません。
The STALE state is entered upon receiving an unsolicited Neighbor Discovery message that updates the cached link-layer address. Receipt of such a message does not confirm reachability, and entering the STALE state ensures reachability is verified quickly if the entry is actually being used. However, reachability is not actually verified until the entry is actually used.
古い状態は、キャッシュされたリンク層アドレスを更新する迷惑なネイバーディスカバリメッセージを受信すると入力されます。そのようなメッセージの受信は到達可能性を確認しないため、エントリが実際に使用されている場合に到達可能性がすぐに検証されます。ただし、到達可能性は実際にエントリが実際に使用されるまで検証されません。
DELAY More than ReachableTime milliseconds have elapsed since the last positive confirmation was received that the forward path was functioning properly, and a packet was sent within the last DELAY_FIRST_PROBE_TIME seconds. If no reachability confirmation is received within DELAY_FIRST_PROBE_TIME seconds of entering the DELAY state, send a Neighbor Solicitation and change the state to PROBE.
順方向パスが正しく機能していた最後の肯定的な確認が受信され、最後の遅延_FIRST_PROBE_TIME秒内にパケットが送信されたため、RECINGABLETIMEミリ秒よりも多くの遅延が経過しました。Delay_First_Probe_time秒内で到達可能性の確認がない場合は、遅延状態を入力するには、隣接勧誘を送信して状態をプローブに変更します。
The DELAY state is an optimization that gives upper-layer protocols additional time to provide reachability confirmation in those cases where ReachableTime milliseconds have passed since the last confirmation due to lack of recent traffic. Without this optimization, the opening of a TCP connection after a traffic lull would initiate probes even though the subsequent three-way handshake would provide a reachability confirmation almost immediately.
遅延状態は、最後のトラフィックの欠如による最後の確認から到達可能なミリ秒が経過した場合の到達可能性確認を提供するために、上位レイヤプロトコルを追加の時間を与える最適化です。この最適化がなければ、その後の3方向ハンドシェイクがほぼすぐに到達可能性の確認を提供するであろうとしても、トラフィックのラル後のTCP接続の開度はプローブを開始するであろう。
PROBE A reachability confirmation is actively sought by retransmitting Neighbor Solicitations every RetransTimer milliseconds until a reachability confirmation is received.
プローブ到達可能性確認が受信されるまで、RetranStimerミリ秒ごとに隣接勧誘を再送することで到達可能性確認が積極的に求められています。
Neighbor Unreachability Detection operates in parallel with the sending of packets to a neighbor. While reasserting a neighbor's reachability, a node continues sending packets to that neighbor using the cached link-layer address. If no traffic is sent to a neighbor, no probes are sent.
近隣の到達不能検出は、隣接するパケットの送信と並行して動作します。隣接の到達可能性を解決する間、ノードはキャッシュされたリンク層アドレスを使用してそのネイバーへのパケットの送信を続けます。トラフィックが隣接に送信されない場合、プローブは送信されません。
When a node needs to perform address resolution on a neighboring address, it creates an entry in the INCOMPLETE state and initiates address resolution as specified in Section 7.2. If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that neighbor invokes the next-hop determination procedure again. Invoking next-hop determination at this point ensures that alternate default routers are tried.
ノードが隣接アドレスでアドレス解決を実行する必要がある場合は、不完全な状態にエントリを作成し、セクション7.2で指定されているようにアドレス解決を開始します。アドレス解決が失敗した場合、エントリは削除する必要があるため、そのネイバーへの後続のトラフィックは再びネクストホップ決定手順を呼び出します。この時点でのネクストホップの決定を呼び出すことで、代替のデフォルトルーターが試行されます。
When a reachability confirmation is received (either through upper-layer advice or a solicited Neighbor Advertisement), an entry's state changes to REACHABLE. The one exception is that upper-layer advice has no effect on entries in the INCOMPLETE state (e.g., for which no link-layer address is cached).
到達可能性確認が受信されると（上位層のアドバイスまたは義務的な隣接広告のいずれかを介して）、エントリの状態が到達可能に変化します。1つの例外は、上位層のアドバイスが不完全状態のエントリに影響を及ぼさない（例えば、リンク層アドレスがキャッシュされていない）。
When ReachableTime milliseconds have passed since receipt of the last reachability confirmation for a neighbor, the Neighbor Cache entry's state changes from REACHABLE to STALE.
隣接の最後の到達可能性確認を受信してから到達可能なミリ秒が経過したとき、ネイバーキャッシュエントリの状態は到達可能なものから古くまで変化します。
Note: An implementation may actually defer changing the state from REACHABLE to STALE until a packet is sent to the neighbor, i.e., there need not be an explicit timeout event associated with the expiration of ReachableTime.
注：実装は、パケットが隣接に送信されるまで、到達可能な状態から古い状態まで状態を変更することができます。
The first time a node sends a packet to a neighbor whose entry is STALE, the sender changes the state to DELAY and sets a timer to expire in DELAY_FIRST_PROBE_TIME seconds. If the entry is still in the DELAY state when the timer expires, the entry's state changes to PROBE. If reachability confirmation is received, the entry's state changes to REACHABLE.
ノードが最初にエントリが古い隣にパケットを送信したときに、送信者は状態を遅延させてDELAY_FIRST_PROBE_TIME秒で期限切れになるようにタイマーを設定します。タイマーが期限切れになるとエントリが遅延状態にある場合、エントリの状態はプローブに変わります。到達可能性確認が受信された場合、エントリの状態は到達可能に変わります。
Upon entering the PROBE state, a node sends a unicast Neighbor Solicitation message to the neighbor using the cached link-layer address. While in the PROBE state, a node retransmits Neighbor Solicitation messages every RetransTimer milliseconds until reachability confirmation is obtained. Probes are retransmitted even if no additional packets are sent to the neighbor. If no response is received after waiting RetransTimer milliseconds after sending the MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry SHOULD be deleted. Subsequent traffic to that neighbor will recreate the entry and perform address resolution again.
プローブ状態に入ると、ノードはキャッシュされたリンク層アドレスを使用してユニキャストネイバー勧誘メッセージをネイバーに送信します。プローブ状態では、ノードは到達可能性確認が得られるまで、RetranStimerをミリ秒ごとに隣接勧誘メッセージを再送信します。追加のパケットが隣接に送信されていなくてもプローブは再送信されます。MAX_UNICAST_SOLICICICIS契約を送信した後にRetranStimerミリ秒の後に応答が受信されない場合は、再送信が終了し、エントリを削除する必要があります。そのネイバーへの後続のトラフィックはエントリを再作成し、アドレス解決を再度実行します。
Note that all Neighbor Solicitations are rate-limited on a per-neighbor basis. A node MUST NOT send Neighbor Solicitations to the same neighbor more frequently than once every RetransTimer milliseconds.
すべての隣接勧誘は、近隣ごとにレート制限されていることに注意してください。RetranStimerミリ秒ごとに、ノードは隣接勧誘をより頻繁に同じネイバーに送信してはいけません。
A Neighbor Cache entry enters the STALE state when created as a result of receiving packets other than solicited Neighbor Advertisements (i.e., Router Solicitations, Router Advertisements, Redirects, and Neighbor Solicitations). These packets contain the link-layer address of either the sender or, in the case of Redirect, the redirection target. However, receipt of these link-layer addresses does not confirm reachability of the forward-direction path to that node. Placing a newly created Neighbor Cache entry for which the link-layer address is known in the STALE state provides assurance that path failures are detected quickly. In addition, should a cached link-layer address be modified due to receiving one of the above messages, the state SHOULD also be set to STALE to provide prompt verification that the path to the new link-layer address is working.
隣接キャッシュエントリは、要約されたネイバー広告（すなわち、ルータ勧誘、ルータ広告、リダイレクト、および隣接勧誘）以外のパケットを受信した結果として、古い状態に入る。これらのパケットには、送信者またはリダイレクトの場合はリダイレクトターゲットのリンクレイヤアドレスが含まれています。ただし、これらのリンク層アドレスを受信しても、そのノードへの順方向パスの到達可能性は確認されません。リンク層アドレスが古い状態で知られている新しく作成されたネイバーキャッシュエントリを配置すると、パス障害が迅速に検出されるという保証が提供されます。さらに、上記のメッセージのいずれかを受信してキャッシュされたリンク層アドレスを変更する必要があるため、新しいリンクレイヤアドレスへのパスが機能しているプロンプト検証を提供するために状態を古く設定する必要があります。
To properly detect the case where a router switches from being a router to being a host (e.g., if its IP forwarding capability is turned off by system management), a node MUST compare the Router flag field in all received Neighbor Advertisement messages with the IsRouter flag recorded in the Neighbor Cache entry. When a node detects that a neighbor has changed from being a router to being a host, the node MUST remove that router from the Default Router List and update the Destination Cache as described in Section 6.3.5. Note that a router may not be listed in the Default Router List, even though a Destination Cache entry is using it (e.g., a host was redirected to it). In such cases, all Destination Cache entries that reference the (former) router must perform next-hop determination again before using the entry.
ルータがルータがホストになるように切り替わるケースを正しく検出する（たとえば、IP転送機能がシステム管理によってオフになっている場合）、ノードは、受信したすべてのネイバーアドバタイズメントメッセージのRouter FlagフィールドをISROUTERと比較する必要があります。隣接キャッシュエントリに記録されているフラグ。ノードが、ネイバーがホストになるように接続されたことを検出すると、ノードはデフォルトのルータリストからそのルータを削除し、6.3.5項で説明されているように宛先キャッシュを更新する必要があります。宛先キャッシュエントリがそれを使用していても、ルータはデフォルトのルータリストにリストされていない場合があります（例えば、ホストがそれにリダイレクトされました）。そのような場合、（以前）ルータを参照するすべての宛先キャッシュエントリは、エントリを使用する前に再度ネクストホップの決定を実行する必要があります。
In some cases, link-specific information may indicate that a path to a neighbor has failed (e.g., the resetting of a virtual circuit). In such cases, link-specific information may be used to purge Neighbor Cache entries before the Neighbor Unreachability Detection would do so. However, link-specific information MUST NOT be used to confirm the reachability of a neighbor; such information does not provide end-to-end confirmation between neighboring IP layers.
場合によっては、リンク固有の情報は、隣接への経路が失敗したことを示してもよい（例えば、仮想回線のリセット）。そのような場合、リンク固有の情報を使用して、近隣の到達不能検出がそうする前にネイバーキャッシュエントリをパージすることができます。ただし、リンク固有の情報は、隣人の到達可能性を確認するために使用してはいけません。そのような情報は、隣接するIP層間のエンドツーエンドの確認を提供しません。
This section describes the functions related to the sending and processing of Redirect messages.
このセクションでは、リダイレクトメッセージの送信および処理に関連する機能について説明します。
Redirect messages are sent by routers to redirect a host to a better first-hop router for a specific destination or to inform hosts that a destination is in fact a neighbor (i.e., on-link). The latter is accomplished by having the ICMP Target Address be equal to the ICMP Destination Address.
リダイレクトメッセージは、ルータによって送信されて、ホストを特定の宛先に対してより良いファーストホップルータにリダイレクトするか、宛先が実際にはネイバー（すなわち、オンリンク）であるホストに通知する。後者は、ICMPターゲットアドレスをICMP宛先アドレスと等しくすることによって達成される。
A router MUST be able to determine the link-local address for each of its neighboring routers in order to ensure that the target address in a Redirect message identifies the neighbor router by its link-local address. For static routing, this requirement implies that the next-hop router's address should be specified using the link-local address of the router. For dynamic routing, this requirement implies that all IPv6 routing protocols must somehow exchange the link-local addresses of neighboring routers.
リダイレクトメッセージ内のターゲットアドレスがリンクローカルアドレスによってネイバールータを識別するために、ルータは各隣接ルータのリンクローカルアドレスを決定できなければなりません。静的ルーティングの場合、この要件はルータのリンクローカルアドレスを使用してネクストホップルータのアドレスを指定する必要があることを意味します。動的ルーティングのために、この要件は、すべてのIPv6ルーティングプロトコルがどういうわけか隣接ルータのリンクローカルアドレスを交換する必要があることを意味します。
A host MUST silently discard any received Redirect message that does not satisfy all of the following validity checks:
次の有効性チェックをすべて満たさない受信リダイレクトメッセージを静かに破棄しなければならない。
- IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers.
- IP送信元アドレスはリンクローカルアドレスです。ルータは、リンクローカルアドレスをルータアドバタイズメントのソースとして使用し、メッセージをリダイレクトしてホストがルータを一意に識別できなければなりません。
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IPホップ制限フィールドは、値255、すなわちパケットがルータによって転送された可能性がある。
- ICMP Checksum is valid.
- ICMPチェックサムが有効です。
- ICMP Code is 0.
- ICMPコードは0です。
- ICMP length (derived from the IP length) is 40 or more octets.
- ICMP長（IP長から導出された）は40オクテットです。
- The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address.
- リダイレクトのIP送信元アドレスは、指定されたICMP宛先アドレスの現在のファーストホップルータと同じです。
- The ICMP Destination Address field in the redirect message does not contain a multicast address.
- リダイレクトメッセージのICMP宛先アドレスフィールドにはマルチキャストアドレスが含まれていません。
- The ICMP Target Address is either a link-local address (when redirected to a router) or the same as the ICMP Destination Address (when redirected to the on-link destination).
- ICMPターゲットアドレスは、リンクローカルアドレス（ルータにリダイレクトしたとき）、またはICMP宛先アドレスと同じ（リンク先にリダイレクトしたとき）のいずれかです。
- All included options have a length that is greater than zero.
- 含まれるすべてのオプションは、ゼロより大きい長さを持ちます。
The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
予約フィールドの内容、および認識されていないオプションは無視する必要があります。将来、プロトコルへの下位互換性のある変更は、予約フィールドの内容を指定したり、新しいオプションを追加することができます。後方互換性のない変更は、異なるコード値を使用できます。
The contents of any defined options that are not specified to be used with Redirect messages MUST be ignored and the packet processed as normal. The only defined options that may appear are the Target Link-Layer Address option and the Redirected Header option.
リダイレクトメッセージで使用するように指定されていない定義されていないオプションの内容は無視され、パケットは通常どおりに処理されます。表示される可能性がある唯一の定義されたオプションは、ターゲットリンク層アドレスオプションとリダイレクトされたヘッダーオプションです。
A host MUST NOT consider a redirect invalid just because the Target Address of the redirect is not covered under one of the link's prefixes. Part of the semantics of the Redirect message is that the Target Address is on-link.
リダイレクトのターゲットアドレスがリンクのプレフィックスの1つの下でカバーされていないため、リダイレクトが無効になってはいけません。リダイレクトメッセージのセマンティクスの一部は、ターゲットアドレスがオンリンクであることです。
A redirect that passes the validity checks is called a "valid redirect".
有効性チェックを渡すリダイレクトは、「有効なリダイレクト」と呼ばれます。
A router SHOULD send a redirect message, subject to rate limiting, whenever it forwards a packet that is not explicitly addressed to itself (i.e., a packet that is not source routed through the router) in which:
ルータは、それ自体に明示的にアドレス指定されていないパケットを転送する（すなわち、ルータを介して送信元ではないパケット）、レート制限の対象となるリダイレクトメッセージを送信する必要があります。
- the Source Address field of the packet identifies a neighbor, and
- パケットの送信元アドレスフィールドはネイバーを識別します。
- the router determines (by means outside the scope of this specification) that a better first-hop node resides on the same link as the sending node for the Destination Address of the packet being forwarded, and
- ルータは、転送されているパケットの宛先アドレスの送信ノードと同じリンク上に優れたファーストホップノードが同じリンク上にあることをルータに決定します。
- the Destination Address of the packet is not a multicast address.
- パケットの宛先アドレスはマルチキャストアドレスではありません。
The transmitted redirect packet contains, consistent with the message format given in Section 4.5:
送信されたリダイレクトパケットには、セクション4.5に記載されているメッセージフォーマットと一致しています。
- In the Target Address field: the address to which subsequent packets for the destination should be sent. If the target is a router, that router's link-local address MUST be used. If the target is a host, the target address field MUST be set to the same value as the Destination Address field.
- ターゲットアドレスフィールドに：宛先の後続のパケットを送信するアドレス。ターゲットがルータの場合、そのルータのリンクローカルアドレスを使用する必要があります。ターゲットがホストの場合、ターゲットアドレスフィールドは[宛先アドレス]フィールドと同じ値に設定する必要があります。
- In the Destination Address field: the destination address of the invoking IP packet.
- [宛先アドレス]フィールドに：起動IPパケットの宛先アドレス。
- In the options:
- オプションで：
o Target Link-Layer Address option: link-layer address of the target, if known.
o ターゲットリンク層アドレスオプション：標的のリンクレイヤアドレスは、既知であれば。
o Redirected Header: as much of the forwarded packet as can fit without the redirect packet exceeding the minimum MTU required to support IPv6 as specified in [IPv6].
o リダイレクトされたヘッダー：[IPv6]で指定されたIPv6をサポートするために必要な最小MTUを超えるリダイレクトパケットがなくなります。
A router MUST limit the rate at which Redirect messages are sent, in order to limit the bandwidth and processing costs incurred by the Redirect messages when the source does not correctly respond to the Redirects, or the source chooses to ignore unauthenticated Redirect messages. More details on the rate-limiting of ICMP error messages can be found in [ICMPv6].
ソースがリダイレクトに正しく応答しないときにリダイレクトメッセージによって発生した帯域幅および処理コストを制限するために、リダイレクトメッセージ、またはソースが未認証されたリダイレクトメッセージを無視することを選択したときに、ルータが送信されるレートを制限する必要があります。ICMPエラーメッセージのレート制限に関する詳細は[ICMPv6]にあります。
A router MUST NOT update its routing tables upon receipt of a Redirect.
リダイレクトを受信してルーティングテーブルを更新しないでください。
A host receiving a valid redirect SHOULD update its Destination Cache accordingly so that subsequent traffic goes to the specified target. If no Destination Cache entry exists for the destination, an implementation SHOULD create such an entry.
有効なリダイレクトを受信したホストは、それに応じてその宛先キャッシュを更新し、後続のトラフィックが指定されたターゲットに進むようにします。宛先キャッシュエントリが存在しない場合、実装はそのようなエントリを作成する必要があります。
If the redirect contains a Target Link-Layer Address option, the host either creates or updates the Neighbor Cache entry for the target. In both cases, the cached link-layer address is copied from the Target Link-Layer Address option. If a Neighbor Cache entry is created for the target, its reachability state MUST be set to STALE as specified in Section 7.3.3. If a cache entry already existed and it is updated with a different link-layer address, its reachability state MUST also be set to STALE. If the link-layer address is the same as that already in the cache, the cache entry's state remains unchanged.
リダイレクトにターゲットリンクレイヤアドレスオプションが含まれている場合、ホストはターゲットのネイバーキャッシュエントリを作成または更新します。どちらの場合も、キャッシュされたリンク層アドレスがターゲットリンク層アドレスオプションからコピーされます。ターゲット用にネイバーキャッシュエントリが作成されている場合、その到達可能性状態はセクション7.3.3で指定されているように古く設定する必要があります。キャッシュエントリが既に存在していて、異なるリンクレイヤアドレスで更新されている場合、その到達可能性状態も古く設定されている必要があります。リンク層アドレスがすでにキャッシュ内のそれと同じである場合、キャッシュエントリの状態は変更されません。
If the Target and Destination Addresses are the same, the host MUST treat the Target as on-link. If the Target Address is not the same as the Destination Address, the host MUST set IsRouter to TRUE for the target. If the Target and Destination Addresses are the same, however, one cannot reliably determine whether the Target Address is a router. Consequently, newly created Neighbor Cache entries should set the IsRouter flag to FALSE, while existing cache entries should leave the flag unchanged. If the Target is a router, subsequent Neighbor Advertisement or Router Advertisement messages will update IsRouter accordingly.
ターゲットアドレスと宛先アドレスが同じ場合、ホストはターゲットをオンリンクとして扱う必要があります。ターゲットアドレスが宛先アドレスと同じでない場合、ホストはターゲットに対してisrouterをtrueに設定する必要があります。ただし、ターゲットアドレスと宛先アドレスが同じ場合は、ターゲットアドレスがルータであるかどうかを確実に判断できません。その結果、新しく作成されたネイバーキャッシュエントリは、isrouterフラグをfalseに設定する必要がありますが、既存のキャッシュエントリはフラグを変更しないようにします。ターゲットがルータの場合、それに応じて後続のネイバーアドバタイズメントまたはルーターアドバタイズメントメッセージがISROUTERを更新します。
Redirect messages apply to all flows that are being sent to a given destination. That is, upon receipt of a Redirect for a Destination Address, all Destination Cache entries to that address should be updated to use the specified next-hop, regardless of the contents of the Flow Label field that appears in the Redirected Header option.
リダイレクトメッセージは、特定の宛先に送信されているすべてのフローに適用されます。つまり、宛先アドレスのリダイレクトを受信すると、リダイレクトされたヘッダーオプションに表示されるフローラベルフィールドの内容に関係なく、指定されたネクストホップを使用するようにすべての宛先キャッシュエントリを更新する必要があります。
A host MUST NOT send Redirect messages.
ホストはリダイレクトメッセージを送信してはいけません。
Options provide a mechanism for encoding variable length fields, fields that may appear multiple times in the same packet, or information that may not appear in all packets. Options can also be used to add additional functionality to future versions of ND.
オプションは、可変長フィールドをエンコードするためのメカニズム、同じパケット内で複数回表示される可能性があるフィールド、またはすべてのパケットに表示されない情報を提供します。オプションを使用して、NDの将来のバージョンに追加機能を追加することもできます。
In order to ensure that future extensions properly coexist with current implementations, all nodes MUST silently ignore any options they do not recognize in received ND packets and continue processing the packet. All options specified in this document MUST be recognized. A node MUST NOT ignore valid options just because the ND message contains unrecognized ones.
将来の拡張機能が現在の実装と適切に共存することを確実にするために、すべてのノードは、受信したNDパケットで認識されないオプションを黙って無視し、パケットの処理を続行する必要があります。この文書で指定されているすべてのオプションを認識する必要があります。NDメッセージに認識されていないものが含まれているため、ノードは有効なオプションを無視してはいけません。
The current set of options is defined in such a way that receivers can process multiple options in the same packet independently of each other. In order to maintain these properties, future options SHOULD follow the simple rule:
現在のオプションのセットは、受信者が互いに独立して同じパケット内の複数のオプションを処理できるように定義されています。これらのプロパティを維持するために、将来のオプションは簡単な規則に従うべきです。
The option MUST NOT depend on the presence or absence of any other options. The semantics of an option should depend only on the information in the fixed part of the ND packet and on the information contained in the option itself.
このオプションは、他のオプションの有無または不在に依存してはいけません。オプションのセマンティクスは、NDパケットの固定部分の情報とオプション自体に含まれる情報にのみ依存する必要があります。
Adhering to the above rule has the following benefits:
上記の規則に付着すると、次のような利点があります。
1) Receivers can process options independently of one another. For example, an implementation can choose to process the Prefix Information option contained in a Router Advertisement message in a user-space process while the link-layer address option in the same message is processed by routines in the kernel.
1）受信機は互いに独立してオプションを処理することができます。たとえば、実装は、同じメッセージ内のリンク層アドレスオプションがカーネル内のルーチンによって処理されている間に、ユーザー空間プロセスでルータアドバタイズメッセージに含まれているプレフィックス情報オプションを処理することを選択できます。
2) Should the number of options cause a packet to exceed a link's MTU, multiple packets can carry subsets of the options without any change in semantics.
2）選択肢の数がリンクのMTUを超えると、複数のパケットがセマンティクスの変更なしにオプションのサブセットを運ぶことができます。
3) Senders MAY send a subset of options in different packets. For instance, if a prefix's Valid and Preferred Lifetime are high enough, it might not be necessary to include the Prefix Information option in every Router Advertisement. In addition, different routers might send different sets of options. Thus, a receiver MUST NOT associate any action with the absence of an option in a particular packet. This protocol specifies that receivers should only act on the expiration of timers and on the information that is received in the packets.
3）送信者はさまざまなパケットにオプションのサブセットを送信することがあります。たとえば、プレフィックスの有効かつ優先有効期間が十分に高い場合は、すべてのルーターアドバタイズメントにプレフィックス情報オプションを含める必要はない可能性があります。さらに、異なるルータは異なるオプションセットを送信することがあります。したがって、受信機は、特定のパケット内のオプションの欠如と任意のアクションを関連付けてはいけません。このプロトコルは、受信者がタイマーの有効期限とパケット内で受信された情報にのみ行われるべきであることを指定します。
Options in Neighbor Discovery packets can appear in any order; receivers MUST be prepared to process them independently of their order. There can also be multiple instances of the same option in a message (e.g., Prefix Information options).
隣接発見パケットのオプションは任意の順序で表示できます。受信者は、それらを順序から独立して処理する準備をしなければなりません。メッセージ内に同じオプションの複数のインスタンスがある（例えば、プレフィックス情報オプション）。
If the number of included options in a Router Advertisement causes the advertisement's size to exceed the link MTU, the router can send multiple separate advertisements, each containing a subset of the options.
ルータ広告内の含まれているオプションの数が広告のサイズをリンクMTUを超えると、ルータはオプションのサブセットを含む複数の別々の広告を送信できます。
The amount of data to include in the Redirected Header option MUST be limited so that the entire redirect packet does not exceed the minimum MTU required to support IPv6 as specified in [IPv6].
リダイレクトされたヘッダーに含めるデータの量は、[IPv6]で指定されているように、リダイレクトパケット全体がIPv6をサポートするのに必要な最小MTUを超えないようにする必要があります。
All options are a multiple of 8 octets of length, ensuring appropriate alignment without any "pad" options. The fields in the options (as well as the fields in ND packets) are defined to align on their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit boundary) with the exception of the 128-bit IP addresses/prefixes, which are aligned on a 64-bit boundary. The link-layer address field contains an uninterpreted octet string; it is aligned on an 8-bit boundary.
すべてのオプションは長さの8オクテットの倍数で、「パッド」オプションなしで適切な整列を確保します。オプション（およびNDパケット内のフィールド）のフィールドは、128ビットIPアドレスを除いて、それらの固有の境界（たとえば、16ビットの境界では16ビットの境界で整列されている）を揃えるように定義されています。64ビット境界に位置合わせされている/プレフィックス。リンク層アドレスフィールドには、解釈されていないオクテット文字列が含まれています。それは8ビット境界上に整列しています。
The size of an ND packet including the IP header is limited to the link MTU. When adding options to an ND packet, a node MUST NOT exceed the link MTU.
IPヘッダを含むNDパケットのサイズはリンクMTUに限定されている。NDパケットにオプションを追加する場合、ノードはリンクMTUを超えてはいけません。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは、新しいオプション型を定義することができます。受信者は、認識していないオプションを黙って無視し、メッセージの処理を続行する必要があります。
Router constants:
ルータ定数：
MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds
MAX_INITIAL_RTR_ADVERT_INTERVAL 16秒
MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions
MAX_INITIAL_RTR_ADIVERSEMESSIES 3送信
MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions
MAX_FINAL_RTR_ADVERTISEMESS 3送信
MIN_DELAY_BETWEEN_RAS 3 seconds
min_delay_between_ras 3秒
MAX_RA_DELAY_TIME .5 seconds
MAX_RA_DELAY_TIME .5秒
Host constants:
ホスト定数：
MAX_RTR_SOLICITATION_DELAY 1 second
MAX_RTR_SOLITITITIONITION_DELAY 1秒
RTR_SOLICITATION_INTERVAL 4 seconds
RTR_Solicate_Interval 4秒
MAX_RTR_SOLICITATIONS 3 transmissions
MAX_RTR_SOLINITATIONS 3送信
Node constants:
ノード定数：
MAX_MULTICAST_SOLICIT 3 transmissions
MAX_MULTICAST_SOLICT 3送信
MAX_UNICAST_SOLICIT 3 transmissions
MAX_UNICAST_SOLICT 3送信
MAX_ANYCAST_DELAY_TIME 1 second
max_anycast_delay_time 1秒
MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions REACHABLE_TIME 30,000 milliseconds
MAX_NEIGHBOR_ADVERTISEMENTISEMER 3送信可能な3万ミリ秒
RETRANS_TIMER 1,000 milliseconds
RETRANS_TIMER 1,000ミリ秒
DELAY_FIRST_PROBE_TIME 5 seconds
DELAY_FIRST_PROBE_TIME 5秒
MIN_RANDOM_FACTOR .5
min_random_factor .5
MAX_RANDOM_FACTOR 1.5
MAX_RANDOM_FACTOR 1.5
Additional protocol constants are defined with the message formats in Section 4.
追加のプロトコル定数は、セクション4のメッセージフォーマットで定義されています。
All protocol constants are subject to change in future revisions of the protocol.
すべてのプロトコル定数は、将来のプロトコルの改訂の変更を受けます。
The constants in this specification may be overridden by specific documents that describe how IPv6 operates over different link layers. This rule allows Neighbor Discovery to operate over links with widely varying performance characteristics.
この仕様の定数は、IPv6が異なるリンクレイヤーをどのように動作するかを説明する特定の文書によってオーバーライドされるかもしれません。この規則により、近隣探索は広く変化する性能特性を持つリンクを介して動作することを可能にします。
Neighbor Discovery is subject to attacks that cause IP packets to flow to unexpected places. Such attacks can be used to cause denial of service but also allow nodes to intercept and optionally modify packets destined for other nodes. This section deals with the main threats related to Neighbor Discovery messages and possible security mechanisms that can mitigate these threats.
Neighbor Discoveryは、IPパケットを予期せぬ場所に流れる原因となる攻撃の対象となります。そのような攻撃は、サービス拒否を引き起こすだけでなく、ノードが他のノード宛てのパケットを遮断してオプションで変更することもできます。このセクションでは、ネイバーディスカバリーメッセージとこれらの脅威を軽減できる可能性のあるセキュリティメカニズムに関連する主な脅威について説明します。
This section discusses the main threats associated with Neighbor Discovery. A more detailed analysis can be found in [PSREQ]. The main vulnerabilities of the protocol fall under three categories:
このセクションでは、ネイバーディスカバリに関連する主な脅威について説明します。[PSREQ]には、より詳細な分析があります。プロトコルの主な脆弱性は3つのカテゴリにあります。
- Denial-of-Service (DoS) attacks. - Address spoofing attacks. - Router spoofing attacks.
- サービス拒否（DOS）攻撃。 - スプーフィング攻撃に対処します。 - ルータースプーフィング攻撃。
An example of denial of service attacks is that a node on the link that can send packets with an arbitrary IP source address can both advertise itself as a default router and also send "forged" Router Advertisement messages that immediately time out all other default routers as well as all on-link prefixes. An intruder can achieve this by sending out multiple Router Advertisements, one for each legitimate router, with the source address set to the address of another router, the Router Lifetime field set to zero, and the Preferred and Valid lifetimes set to zero for all the prefixes. Such an attack would cause all packets, for both on-link and off-link destinations, to go to the rogue router. That router can then selectively examine, modify, or drop all packets sent on the link. The Neighbor Unreachability Detection (NUD) will not detect such a black hole as long as the rogue router politely answers the NUD probes with a Neighbor Advertisement with the R-bit set.
サービス拒否攻撃の例は、任意のIP送信元アドレスを持つパケットを送信できるリンク上のノードが、それ自体をデフォルトルーターとしてアドバタイズすることができ、そのまま他のすべてのデフォルトルーターをすぐにタイムアウトする「偽造」ルーターアドバタイズメントメッセージも送信できます。すべてのオンリンクプレフィックスとしてまあ。侵入者は、正当なルータごとに複数のルータ広告を1つずつ送信することで、ソースアドレスが別のルータのアドレスに設定され、ルータのLifetimeフィールドがゼロに設定され、すべてのリフタイムがすべての場合ゼロに設定されます。接頭辞そのような攻撃は、オンリンク先とオフリンク先の両方の宛先のために、すべてのパケットを引き起こします。そのルータは、リンク上で送信されたすべてのパケットを選択的に調べ、変更、または削除できます。近隣の到達不能検出（NUD）は、不正ルータが丁寧にNUDプローブにRIDプローブに答える限り、そのようなブラックホールを検出しません。
It is also possible for any host to launch a DoS attack on another host by preventing it from configuring an address using [ADDRCONF]. The protocol does not allow hosts to verify whether the sender of a Neighbor Advertisement is the true owner of the IP address included in the message.
ADDRCONFを使用してアドレスを設定できないようにすることで、任意のホストが別のホストでDOS攻撃を起動することもできます。プロトコルでは、ホストは、ネイバーアドバタイズメントの送信者がメッセージに含まれているIPアドレスのTrue Oherであるかどうかを確認できません。
Redirect attacks can also be achieved by any host in order to flood a victim or steal its traffic. A host can send a Neighbor Advertisement (in response to a solicitation) that contains its IP address and a victim's link-layer address in order to flood the victim with unwanted traffic. Alternatively, the host can send a Neighbor Advertisement that includes a victim's IP address and its own link-layer address to overwrite an existing entry in the sender's destination cache, thereby forcing the sender to forward all of the victim's traffic to itself.
犠牲者を洪水や盗むために、攻撃をリダイレクト攻撃を達成することもできます。ホストは、そのIPアドレスと被害者のリンクレイヤアドレスを含む近隣アドバタイズメントを（勧誘に応答して）送信することができます。あるいは、ホストは、送信者のIPアドレスとそれ自身のリンク層アドレスとを含む隣接アドバジェクトを送信して、送信者の宛先キャッシュ内の既存のエントリを上書きし、それによって送信者がそのすべての被害者のトラフィックを自分自身に転送するように強制することができる。
The trust model for redirects is the same as in IPv4. A redirect is accepted only if received from the same router that is currently being used for that destination. If a host has been redirected to another node (i.e., the destination is on-link), there is no way to prevent the target from issuing another redirect to some other destination. However, this exposure is no worse than it was before being redirected; the target host, once subverted, could always act as a hidden router to forward traffic elsewhere.
リダイレクトの信頼モデルはIPv4と同じです。リダイレクトは、現在その宛先に使用されているのと同じルータから受信した場合にのみ受け付けられます。ホストが別のノード（すなわち、宛先がオンリンクオンリンク）にリダイレクトされた場合、ターゲットが他の宛先に別のリダイレクトを発行することを防ぐ方法はない。しかしながら、この露出はリダイレクトされる前にあったよりも悪いことはありません。ターゲットホストは、一度減素された後、他の場所でトラフィックを転送するための隠しルーターとして機能する可能性があります。
The protocol contains no mechanism to determine which neighbors are authorized to send a particular type of message (e.g., Router Advertisements); any neighbor, presumably even in the presence of authentication, can send Router Advertisement messages thereby being able to cause denial of service. Furthermore, any neighbor can send proxy Neighbor Advertisements as well as unsolicited Neighbor Advertisements as a potential denial-of-service attack.
プロトコルには、特定の種類のメッセージ（例えば、ルータ広告）を送信する権限があるかを判断するためのメカニズムが含まれていません。おそらく認証の存在下でも、任意の隣接、それによってルータ広告メッセージを送信することができ、それによってサービス拒否を引き起こすことができる。さらに、任意の隣人は、潜在的なサービス拒否攻撃として、プロキシ近隣アドバタイズメントを送信することができます。
Many link layers are also subject to different denial-of-service attacks such as continuously occupying the link in CSMA/CD (Carrier Sense Multiple Access with Collision Detection) networks (e.g., by sending packets closely back-to-back or asserting the collision signal on the link), or originating packets with somebody else's source MAC address to confuse, e.g., Ethernet switches. On the other hand, many of the threats discussed in this section are less effective, or non-existent, on point-to-point links, or cellular links where a host shares a link with only one neighbor, i.e., the default router.
多くのリンク層は、CSMA / CD（衝突検出によるキャリアセンス多元接続）ネットワーク（例えば、バックアップまたは衝突を主張することによって）リンクを継続的に占有するなど、さまざまなサービス拒否攻撃を受ける。リンク上の信号、または他の誰かのソースMACアドレスを持つパケット、例えばイーサネットスイッチを混同する一方、このセクションで説明されている脅威の多くは、ポイントツーポイントリンク、またはホストが1つの隣接、すなわちデフォルトルータだけを共有するセルラーリンクではありません。
The protocol reduces the exposure to the above threats in the absence of authentication by ignoring ND packets received from off-link senders. The Hop Limit field of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor.
このプロトコルは、オフリンク送信者から受信したNDパケットを無視して認証がない場合の上記の脅威への暴露を削減します。受信したすべてのパケットのホップリミットフィールドには、255、最大限の値が含まれています。ルータは、それらが正のすべてのパケットでホップの制限を減少させるので、ホップリミット255を含む受信パケットはネイバーから発信されていなければなりません。
Cryptographic security mechanisms for Neighbor Discovery are outside the scope of this document and are defined in [SEND]. Alternatively, IPsec can be used for IP layer authentication [IPv6-SA]. The use of the Internet Key Exchange (IKE) is not suited for creating dynamic security associations that can be used to secure address resolution or neighbor solicitation messages as documented in [ICMPIKE].
近隣探索の暗号化セキュリティメカニズムは、この文書の範囲外であり、[送信]で定義されています。あるいは、IPSECをIP層認証[IPv6-SA]に使用できます。インターネット鍵交換（IKE）の使用は、[ICMPIKE]に記載されているアドレス解決または隣接勧誘メッセージを保護するために使用できる動的セキュリティアソシエーションを作成するのに適していません。
In some cases, it may be acceptable to use statically configured security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure Neighbor Discovery messages. However, it is important to note that statically configured security associations are not scalable (especially when considering multicast links) and are therefore limited to small networks with known hosts. In any case, if either [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for the purpose of authentication. Packets that fail authentication checks MUST be silently discarded.
場合によっては、[IPv6-auth]または[IPv6-ESP]のいずれかで静的に設定されたセキュリティアソシエーションを使用して、ネイバー検出メッセージを保護することができます。ただし、静的に設定されたセキュリティアソシエーションはスケーラブルではない（特にマルチキャストリンクを検索するとき）、したがって、既知のホストを持つ小規模ネットワークに限定されていることに注意することが重要です。いずれにせよ、[IPv6-auth]または[IPv6-ESP]が使用されている場合、認証の目的でNDパケットを検証する必要があります。認証チェックに失敗するパケットは、静かに破棄されなければなりません。
The Neighbor Discovery protocol together with IPv6 Address Autoconfiguration [ADDRCONF] provides mechanisms to aid in renumbering -- new prefixes and addresses can be introduced and old ones can be deprecated and removed.
IPv6アドレスの自動設定[ADDRCONF]と一緒にネイバーディスカバリプロトコルを提供します。
The robustness of these mechanisms is based on all the nodes on the link receiving the Router Advertisement messages in a timely manner. However, a host might be turned off or be unreachable for an extended period of time (i.e., a machine is powered down for months after a project terminates). It is possible to preserve robust renumbering in such cases, but it does place some constraints on how long prefixes must be advertised.
これらのメカニズムの堅牢性は、ルータ広告メッセージを適時に受信したリンク上のすべてのノードに基づいています。ただし、ホストはオフになっているか、または長期間にわたって到達不能になる可能性があります（すなわち、プロジェクトが終了してから数ヶ月間パワーダウンされる）。そのような場合には、堅牢な番号付けを保持することは可能ですが、プレフィックスを宣伝する必要があるのかについていくつかの制約があります。
Consider the following example in which a prefix is initially advertised with a lifetime of 2 months, but on August 1st it is determined that the prefix needs to be deprecated and removed due to renumbering by September 1st. This can be done by reducing the advertised lifetime to 1 week starting on August 1st, and as the cutoff gets closer, the lifetimes can be made shorter until by September 1st the prefix is advertised with a lifetime of 0. The point is that, if one or more nodes were unplugged from the link prior to September 1st, they might still think that the prefix is valid since the last lifetime they received was 2 months. Thus, if a node was unplugged on July 31st, it thinks the prefix is valid until September 30th. If that node is plugged back in prior to September 30th, it may continue to use the old prefix. The only way to force a node to stop using a prefix that was previously advertised with a long lifetime is to have that node receive an advertisement for that prefix that changes the lifetime downward. The solution in this example is simple: continue advertising the prefix with a lifetime of 0 from September 1st until October 1st.
プレフィックスが最初に2か月の寿命でアドバタイズされている次の例を考慮してください。これは、8月1日から1週間の宣伝された寿命を1週間に短縮することによって行うことができ、カットオフが近づくにつれて寿命は9月1日までにプレフィックスが1の寿命で広告されるまで短くすることができます。 1つ以上のノードが9月1日の間にリンクから抜かれていなかったため、最後の生涯が2か月であったので、プレフィックスが有効であると考えているかもしれません。したがって、7月31日にノードが抜かれていれば、Prefixは9月30日まで有効であると思います。 9月30日以前にそのノードがバックされている場合は、古いプレフィックスを使用し続けることがあります。ロングライフタイムで以前に存在していたプレフィックスを使用する停止を強制する唯一の方法は、そのノードがそのプレフィックスの広告を下方に変更するそのノードを提供することです。この例の解決策は簡単です：9月1日から10月1日までのプレフィックスを存続期間で広告する。
In general, in order to be robust against nodes that might be unplugged from the link, it is important to track the furthest into the future that a particular prefix can be viewed as valid by any node on the link. The prefix must then be advertised with a 0 lifetime until that point in the future. This "furthest into the future" time is simply the maximum, over all Router Advertisements, of the time the advertisement was sent, plus the prefix's lifetime contained in the advertisement.
一般に、リンクから抜かれている可能性があるノードに対して堅牢になるためには、特定の接頭辞がリンク上の任意のノードによって有効であると見なすことができることが最も遠いものに追跡することが重要です。その後、将来その時点まで、接頭辞を0寿命でアドバタイズする必要があります。これは「将来への最も遠い」時間は、広告が送信された時点のすべてのルータ広告、および広告に含まれているプレフィックスの生涯にわたって最大の最大です。
The above has an important implication on using infinite lifetimes. If a prefix is advertised with an infinite lifetime, and that prefix later needs to be renumbered, it is undesirable to continue advertising that prefix with a zero lifetime forever. Thus, either infinite lifetimes should be avoided or there must be a limit on how long of a time a node can be unplugged from the link before it is plugged back in again. However, it is unclear how the network administrator can enforce a limit on how long time hosts such as laptops can be unplugged from the link.
上記は無限の寿命を使用することに重要な意味を持ちます。プレフィックスが無限の有効期間でアドバタイズされ、後でその接頭辞を参照する必要がある場合は、プレフィックスが永遠にゼロのプレフィックスを継続することは望ましくありません。したがって、無限の寿命のいずれかを回避するか、またはその期間の期間が再び接続される前にリンクからどのくらいの時間を抜くかに制限がなければならない。ただし、ネットワーク管理者がラップトップなどのホストがどのくらいのホストをリンクから抜いているかについての制限をどのように強制できるかは不明です。
Network administrators should give serious consideration to using relatively short lifetimes (i.e., no more than a few weeks). While it might appear that using long lifetimes would help ensure robustness, in reality, a host will be unable to communicate in the absence of properly functioning routers. Such routers will be sending Router Advertisements that contain appropriate (and current) prefixes. A host connected to a network that has no functioning routers is likely to have more serious problems than just a lack of a valid prefix and address.
ネットワーク管理者は、比較的短い寿命を使用すること（すなわち、数週間以下）を使用することを考慮に入れるべきである。長い寿命を使用すると、堅牢性を実際に保証するのに役立つかもしれませんが、正しく機能しているルーターがない状態でホストが通信できません。そのようなルーターは、適切な（および現在の）プレフィックスを含むルーターアドバタイズメントを送信します。機能的なルータを持たないネットワークに接続されているホストは、有効なプレフィックスとアドレスの欠如よりも深刻な問題を抱えている可能性があります。
The above discussion does not distinguish between the preferred and valid lifetimes. For all practical purposes, it is probably sufficient to track the valid lifetime since the preferred lifetime will not exceed the valid lifetime.
上記の議論は、好ましい寿命と有効な寿命を区別していない。すべての実用的な目的のために、好ましい寿命が有効な寿命を超えないので、それはおそらく有効な寿命を追跡するのに十分です。
This document does not require any new ICMPv6 types or codes to be allocated. However, existing ICMPv6 types have been updated to point to this document instead of RFC 2461. The procedure for the assignment of ICMPv6 types/codes is described in Section 6 of [ICMPv6].
この文書では、新しいICMPv6型やコピーを割り当てる必要はありません。ただし、既存のICMPv6タイプはRFC 2461の代わりにこのドキュメントを指すように更新されました.ICMPv6型/コードの割り当ての手順は[ICMPv6]のセクション6で説明されています。
This document continues to use the following ICMPv6 message types introduced in RFC 2461 and already assigned by IANA:
このドキュメントは、RFC 2461で導入され、すでにIANAによって割り当てられている次のICMPv6メッセージタイプを使用し続けます。
Message name ICMPv6 Type
メッセージ名ICMPv6タイプ
Router Solicitation 133 Router Advertisement 134 Neighbor Solicitation 135 Neighbor Advertisement 136 Redirect 137
ルーター勧誘133ルーター広告134隣接勧誘135隣接広告136リダイレクト137
This document continues to use the following Neighbor Discovery option types introduced in RFC 2461 and already assigned by IANA:
このドキュメントはRFC 2461で導入され、すでにIANAによって割り当てられている次の隣接発見オプションタイプを使用し続けています。
Option Name Type
オプション名タイプ
Source Link-Layer Address 1 Target Link-Layer Address 2 Prefix Information 3 Redirected Header 4 MTU 5
ソースリンク層アドレス1ターゲットリンクレイヤアドレス2プレフィックス情報3リダイレクトヘッダ4 MTU 5
Neighbor Discovery option types are allocated using the following procedure:
近隣検出オプションタイプは、次の手順で割り当てられています。
1. The IANA should allocate and permanently register new option types from IETF RFC publication. This is for all RFC types including standards track, informational, and experimental status that originate from the IETF and have been approved by the IESG for publication.
1. IANAは、IETF RFCパブリケーションから新しいオプションタイプを割り当てて永久に登録する必要があります。これは、IETFから発生し、IESGによって出版のIESGによって承認されている標準トラック、情報、および実験的なステータスを含むすべてのRFCタイプです。
2. IETF working groups with working group consensus and area director approval can request reclaimable Neighbor Discovery option type assignments from the IANA. The IANA will tag the values as "reclaimable in future".
2. ワーキンググループコンセンサスとエリアディレクターの承認を備えたIETFワーキンググループは、IANAから再生可能なネイバーディスカバリーオプションタイプ割り当てを要求できます。IANAは値を「将来の再生可能」としてタグを付けます。
The "reclaimable in the future" tag will be removed when an RFC is published documenting the protocol as defined in 1). This will make the assignment permanent and update the reference on the IANA Web pages.
1）で定義されているようにプロトコルを文書化するRFCが公開されている場合、「将来の再生可能」タグは削除されます。これにより、割り当てが永続的になり、IANA Webページの参照を更新します。
At the point where the option type values are 85% assigned, the IETF will review the assignments tagged "reclaimable in the future" and inform the IANA which ones should be reclaimed and reassigned.
オプションの種類の値が85％割り当てられている時点で、IETFは「将来の再生可能」にタグ付けされた割り当てを確認し、どちらを再生し、再割り当てされるべきかをIANAに知らせます。
3. Requests for new option type value assignments from outside the IETF are only made through the publication of an IETF document, per 1) above. Note also that documents published as "RFC Editor contributions" [RFC3667] are not considered to be IETF documents.
3. 新しいオプション型の要求IETFの外部からの割り当ての要求は、上記1）1）のIETF文書の公開を通じてのみ行われます。「RFC Editorの投稿」[RFC3667]として公開されている文書は、IETF文書とは見なされません。
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[Addr-Arch] Hinden、R.およびS.Theering、2006年2月、RFC 4291、RFC 4291。
[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[ICMPv6] Conta、A.、Theering、S.、およびM.Gupta、「インターネットプロトコルバージョン6（IPv6）仕様」、RFC 4443、2006年3月のインターネット制御メッセージプロトコル（ICMPv6）。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]ショー、S。およびR.Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S.、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ADDRCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[AddRconf] Thomson、S.、Narten、T.、T.jinmei、「IPv6ステートレスアドレス自動設定」、RFC 4862、2007年9月。
[ADDR-SEL] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[ADDR-SEL] DRAVES、R.、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択（IPv6）」、RFC 3484、2003年2月。
[ARP] 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.
[ARP] Plummer、D.、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48.イーサネットハードウェアの送信用イーサネットアドレスの変換」、STD 37、RFC 826、1982年11月。
[ASSIGNED] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[割り当てられた] Reynolds、J.、ED。「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」RFC 3232、2002年1月。
[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[DHCPv6] DROM、R.、ED。、BAWE、VORZ、B、LEMON、T.、PERKINS、C、およびM.Carney、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、RFC 33152003年7月。
[HR-CL] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[HR-CL] Braden、R.、Ed。、「インターネットホストの要求 - 通信層の要件」、STD 3、RFC 1122、1989年10月。
[ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, March 2003.
[ICMPIKE] Arkko、J.、「ICMPv6のICMPv6の影響」、2003年3月、進行中の取り組み。
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMPv4] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[IPv6-3GPP] Wasserman, M., Ed., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[IPv6-3GPP] Wasserman、M.、ED。、「第3世代パートナーシッププロジェクト（3GPP）規格（3GPP）規格（3GPP）規格のIPv6の推奨事項」、2002年9月。
[IPv6-CELL] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003.
[IPv6-Cell] Arkko、J.、Kuijpers、G.、Soliman、H.、Loughney、J.、J.Wiljakka、「インターネットプロトコルバージョン6（IPv6）、RFC 33162003年4月。
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[IPv6-Ether] Crawford、M.、「イーサネットネットワークを介したIPv6パケットの送信」、RFC 2464、1998年12月。
[IPv6-SA] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPv6-SA]ケント、S.およびK.SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[IPv6-AUTH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[IPv6-auth]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[IPv6-ESP]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[IPv6-NBMA] Armitage、G.、Schulter、P.、Jork、M.、およびG. Harter、「非放送多元接続（NBMA）ネットワーク（NBMA）ネットワークのIPv6」、RFC 2491、1999年1月。
[LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.
[LD-SHRE]階層、R.およびD. Thaler、「IPv6ホストからルータ負荷分散」、2005年11月、RFC 4311。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIPv6]ジョンソン、D.、Perkins、C.、J.Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[MLD] Theuring、S.、Fenner、W.、B. Haberman、「IPv6のマルチキャストリスナー発見（MLD）」、RFC 2710、1999年10月。
[MLDv2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDv2] VIDA、R.、ED。、およびL.Costa、ED。、「IPv6のMLDV2）、RFC 3810、2004年6月。
[PSREQ] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[PSREQ] Nikander、P.、ED。、KEMPF、J.、およびE. Nordmark、「IPv6 Noiby Discovery（ND）信託モデルと脅威」、RFC 3756、2004年5月。
[RAND] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RAND]イーストレイク、D.、第3、Schiller、J.、およびS. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RDISC] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RDISC]、S。、「ICMPルータディスカバリーメッセージ」、RFC 1256、1991年9月。
[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004.
[RFC3667] Bradner、S.、2004年2月、RFC 3667。
[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RTSEL] Draves、R.およびD. Thaler、「デフォルトルータ設定とその他の特定のルート」、RFC 4191、2005年11月。
[SH-MEDIA] Braden, B., Postel, J., and Y. Rekhter, "Internet Architecture Extensions for Shared Media", RFC 1620, May 1994.
[SHメディア] Braden、B.、Postel、J.、Y.Rekhter、「共有メディア用インターネットアーキテクチャ拡張」、RFC 1620、1994年5月。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[送信] Arkko、J.、Ed。、Kempf、J.、Zill、B.、P. Nikander、「Secure Neight Discovery（Send）」、RFC 3971、2005年3月。
[SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic
Routing Messages", IEEE/ACM Transactions on Networking,
April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z
Appendix A: Multihomed Hosts
There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. Implementors are encouraged to experiment with various approaches to making Neighbor Discovery work on multihomed hosts and to report their experiences. Further work related to this problem can be found in [RTSEL].
複数のインタフェースを持つホストによってネイバーディスカバリが使用されている場合に発生する多数の複雑な問題があります。このセクションでは、ネイバーディスカバリーに関してマルチホームホストの適切な動作を定義しようとしていません。むしろ、それはさらなる研究を必要とする問題を識別します。実装者は、マルチホームホストでの近隣探索作業を行い、経験を報告するためのさまざまなアプローチを実験することをお勧めします。この問題に関連するさらなる仕事は[RTSEL]にあります。
If a multihomed host receives Router Advertisements on all of its interfaces, it will (probably) have learned on-link prefixes for the addresses residing on each link. When a packet must be sent through a router, however, selecting the "wrong" router can result in a suboptimal or non-functioning path. There are number of issues to consider:
マルチホームホストがそのすべてのインターフェイスでルータアドバタイズメントを受信した場合、（おそらく）各リンクに存在するアドレスのオンリンクプレフィックスを学習しました。ただし、パケットをルータを介して送信する必要がある場合は、[間違った]ルータを選択すると、最適なパスまたは非機能パスが発生する可能性があります。考慮すべき問題が数多くあります。
1) In order for a router to send a redirect, it must determine that the packet it is forwarding originates from a neighbor. The standard test for this case is to compare the source address of the packet to the list of on-link prefixes associated with the interface on which the packet was received. If the originating host is multihomed, however, the source address it uses may belong to an interface other than the interface from which it was sent. In such cases, a router will not send redirects, and suboptimal routing is likely. In order to be redirected, the sending host must always send packets out the interface corresponding to the outgoing packet's source address. Note that this issue never arises with non-multihomed hosts; they only have one interface. Additional discussion on this topic can be found in RFC 1122 under Section 3.3.4.2.
1）ルータがリダイレクトを送信するためには、それが転送しているパケットがネイバーから発信されると判断する必要があります。この場合の標準テストは、パケットが受信されたインターフェイスに関連付けられているインターフェイスに関連付けられているオンリンクプレフィックスのリストにパケットの送信元アドレスを比較することです。ただし、発信ホストがマルチホームの場合、使用する送信元アドレスは、送信元のインターフェイス以外のインターフェイスに属します。そのような場合、ルータはリダイレクトを送信しません。最適なルーティングは可能性があります。リダイレクトするために、送信側ホストは常に発信パケットの送信元アドレスに対応するインターフェイスを常に送信する必要があります。この問題は非マルチホームホストでは生まれません。それらは1つのインターフェースしかありません。このトピックに関する追加の説明は、3.3.4.2項の下でRFC 1122にあります。
2) If the selected first-hop router does not have a route at all for the destination, it will be unable to deliver the packet. However, the destination may be reachable through a router on one of the other interfaces. Neighbor Discovery does not address this scenario; it does not arise in the non-multihomed case.
2）選択したファーストホップルータに宛先のルートがまったくない場合は、パケットを配信できなくなります。ただし、宛先は、他のインターフェイスの1つのルータを介して到達可能になります。Neighbor Discoveryはこのシナリオに対処しません。非マルチホームケースでは発生しません。
3) Even if the first-hop router does have a route for a destination, there may be a better route via another interface. No mechanism exists for the multihomed host to detect this situation.
3）最初のホップルータが宛先のルートを持っていても、他のインターフェイスを介してより良いルートがある可能性があります。この状況を検出するためのマルチホームホストにはメカニズムが存在しません。
If a multihomed host fails to receive Router Advertisements on one or more of its interfaces, it will not know (in the absence of configured information) which destinations are on-link on the affected interface(s). This leads to the following problem: If Router Advertisements are received on some, but not all, interfaces, a multihomed host could choose to only send packets out on the interfaces on which it has received Router Advertisements. A key assumption made here, however, is that routers on those other interfaces will be able to route packets to the ultimate destination, even when those destinations reside on the subnet to which the sender connects, but has no on-link prefix information. Should the assumption be FALSE, communication would fail. Even if the assumption holds, packets will traverse a suboptimal path.
マルチホームホストが1つ以上のインタフェースでルータアドバタイズメントを受信できない場合は、影響を受けるインタフェースのオンリンクがオンリンクされている（設定されている情報がない場合）。これにより、次のような問題が発生します。ルーターの広告が一部で表示されますが、すべてのインターフェイスが受信された場合、マルチホームホストは、ルーターアドバタイズメントを受信したインターフェイスに対してのみパケットを送信することを選択できます。ただし、ここで行われた鍵の仮定は、それらの宛先が送信者が接続するサブネットに存在するが、リンク上のプレフィックス情報を持たない場合でも、それらの他のインターフェース上のルータが最終的な宛先に配線することができるということである。仮定が偽の場合、通信は失敗するでしょう。仮定が保持されていても、パケットは最適値のパスを通過します。
Appendix B: Future Extensions
付録B：将来の拡張子
Possible extensions for future study are:
将来の研究のための可能な拡張は次のとおりです。
o Using dynamic timers to be able to adapt to links with widely varying delay. Measuring round-trip times, however, requires acknowledgments and sequence numbers in order to match received Neighbor Advertisements with the actual Neighbor Solicitation that triggered the advertisement. Implementors wishing to experiment with such a facility could do so in a backwards-compatible way by defining a new option carrying the necessary information. Nodes not understanding the option would simply ignore it.
o 動的タイマーを使用して、広く変化する遅延を持つリンクに適応できるようにします。ただし、往復回数を測定するには、受信した隣接アドバタイズメントと広告を誘発した環境勧誘と一致させるために、確認応答とシーケンス番号が必要です。そのような施設を実験することを望む実装者は、必要な情報を運ぶ新しいオプションを定義することによって、後方互換性のある方法でそうすることができます。オプションを理解しないノードは単に無視します。
o Adding capabilities to facilitate the operation over links that currently require hosts to register with an address resolution server. This could, for instance, enable routers to ask hosts to send them periodic unsolicited advertisements. Once again, this can be added using a new option sent in the Router Advertisements.
o ホストがアドレス解決サーバに登録する必要があるリンクを介した操作を容易にする機能を追加する。これは、例えば、ルータがホストに定期的な迷惑なアドバタイズメントを送信するように依頼することができます。もう一度、これはルーター広告で送信された新しいオプションを使用して追加できます。
o Adding additional procedures for links where asymmetric and non-transitive reachability is part of normal operations. Such procedures might allow hosts and routers to find usable paths on, e.g., radio links.
o 非対称および非過渡的な到達可能性が通常の操作の一部であるリンクのための追加の手順を追加する。そのような手順により、ホストやルータは、例えばラジオリンクに対して使用可能なパスを見つけることができます。
Appendix C: State Machine for the Reachability State
付録C：到達可能性状態のためのステートマシン
This appendix contains a summary of the rules specified in Sections 7.2 and 7.3. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
この付録には、セクション7.2と7.3で指定された規則の概要が含まれています。この文書は、その外部の動作がこの文書で説明されているものと一致している限り、実装がこのモデルに付着していることを義務付けません。
When performing address resolution and Neighbor Unreachability Detection the following state transitions apply using the conceptual model:
アドレス解決と近隣の到達不可能検出を実行するときは、次の状態遷移が概念的なモデルを使用して適用されます。
State Event Action New state
州イベントアクション新しい状態
- Packet to send. Create entry. INCOMPLETE Send multicast NS. Start retransmit timer
- 送信するパケットエントリを作成します。不完全なマルチキャストNSを送信します。再送信タイマーを起動します
INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE less than N Start retransmit retransmissions. timer
不完全な再送信タイムアウト、RESTRANSMIT NSがN未満の再送信の再送信を再送信します。タイマー
INCOMPLETE Retransmit timeout, Discard entry - N or more Send ICMP error retransmissions.
不完全な再送信タイムアウト、Entry - N以上のICMPエラーの再送信を廃棄します。
INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=any address. Send queued packets.
不完全なNA、要請= 0、レコードリンクレイヤーStale Override =任意のアドレス。キューに入れられたパケットを送信します。
INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets.
不完全なNA、retocted = 1、レコードリンク層到達可能なオーバーライド=任意のアドレス。キューに入れられたパケットを送信します。
INCOMPLETE NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag Link-layer address
不完全なNA、retocted = any、変更されていないオーバーライド= any、iSrouterフラグリンク層アドレスなし
- NS, RS, Redirect - - No link-layer address
- NS、RS、リダイレクト - - リンクレイヤアドレスなし
!INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached.
！不完全なNA、retocted = 1、 - 到達可能なオーバーライド= 0キャッシュされた同じリンクレイヤアドレス。
!INCOMPLETE NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag. link-layer address
不完全なNA、retocted = any、変更されていないオーバーライド= any、iSrouterフラグなし。リンク層アドレス
REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer address than cached.
到達可能なNA、retocted = 1、 - Stale Override = 0個の異なるリンク層アドレスはキャッシュされています。
STALE, PROBE NA, Solicited=1, - unchanged Or DELAY Override=0 Different link-layer address than cached.
Stale、Probe NA、retocted = 1、非変更または遅延オーバーライド= 0の異なるリンクレイヤアドレスはキャッシュされています。
!INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=1 address (if different).
！不完全なNA、要請= 1、レコードリンク層到達可能なオーバーライド= 1アドレス（異なる場合）。
!INCOMPLETE NA, Solicited=0, - unchanged
Override=0
!INCOMPLETE NA, Solicited=0, - unchanged Override=1 Same link-layer address as cached.
！不完全なNA、要求= 0、 - 変更されていないオーバーライド= 1同じリンク層アドレスがキャッシュされています。
!INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=1 address. Different link-layer address than cached.
！不完全なNA、要請= 0、LINK層Stale Override = 1アドレスを記録します。キャッシュされたよりも異なるリンクレイヤアドレス。
!INCOMPLETE upper-layer reachability - REACHABLE confirmation
！不完全な上層到達可能性 - 到達可能な確認
REACHABLE timeout, more than - STALE N seconds since reachability confirm.
到達可能なタイムアウト、到達可能性が確定してから - Stale N秒以上。
STALE Sending packet Start delay timer DELAY
古い送信パケット開始遅延タイマー遅延を開始します
DELAY Delay timeout Send unicast NS probe PROBE Start retransmit timer
遅延遅延タイムアウト送信ユニキャストNSプローブプローブスタート再送信タイマを開始
PROBE Retransmit timeout, Retransmit NS PROBE less than N retransmissions.
プローブ再送信タイムアウト、NSプローブがN個の再送信よりも小さい。
PROBE Retransmit timeout, Discard entry - N or more retransmissions.
プローブの再送信タイムアウト、エントリを破棄する - N以上の再送信。
The state transitions for receiving unsolicited information other than Neighbor Advertisement messages apply to either the source of the packet (for Neighbor Solicitation, Router Solicitation, and Router Advertisement messages) or the target address (for Redirect messages) as follows:
隣接広告メッセージ以外の迷惑情報を受信するための状態遷移は、パケットの送信元（隣接勧誘、ルータ勧誘、ルータ広告メッセージ）、または次のようにターゲットアドレス（リダイレクトメッセージの場合）に適用される。
State Event Action New state
州イベントアクション新しい状態
- NS, RS, RA, Redirect Create entry. STALE
- NS、RS、RA、リダイレクトエントリをリダイレクトします。st
INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE address. Send queued packets.
不完全なNS、RS、RA、リダイレクトレコードリンクレイヤーストレールアドレス。キューに入れられたパケットを送信します。
!INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE Different link-layer address address than cached.
不完全なNS、RS、RA、リダイレクトアップデートリンク層は、キャッシュされたよりも異なるリンク層アドレスアドレスを古くなっています。
INCOMPLETE NS, RS No link-layer - unchanged address
不完全なNS、RS NOリンクレイヤー - 変更されていないアドレス
!INCOMPLETE NS, RS, RA, Redirect - unchanged Same link-layer address as cached.
不完全なNS、RS、RA、リダイレクト - キャッシュされた同じリンク層アドレスを変更しない。
Appendix D: Summary of IsRouter Rules
付録D：ISROUTER規則の概要
This appendix presents a summary of the rules for maintaining the IsRouter flag as specified in this document.
この付録では、このドキュメントで指定されているisrouterフラグを維持するためのルールの概要を示します。
The background for these rules is that the ND messages contain, either implicitly or explicitly, information that indicates whether or not the sender (or Target Address) is a host or a router. The following assumptions are used:
これらの規則の背景は、NDメッセージに、暗黙的または明示的に、送信者（またはターゲットアドレス）がホストかルータかを示す情報が含まれています。以下の仮定が使用されます。
- The sender of a Router Advertisement is implicitly assumed to be a router.
- ルータ広告の送信者は暗黙的にルータと見なされます。
- Neighbor Solicitation messages do not contain either an implicit or explicit indication about the sender. Both hosts and routers send such messages.
- Neibly ResiCationメッセージには、送信者に関する暗黙的または明示的な表示が含まれていません。ホストとルータの両方がそのようなメッセージを送信します。
- Neighbor Advertisement messages contain an explicit "IsRouter flag", the R-bit.
- ネイバーアドバタイズメントメッセージには、明示的 "isrouterフラグ"、Rビットが含まれています。
- The target of the redirect, when the target differs from the destination address in the packet being redirected, is implicitly assumed to be a router. This is a natural assumption since that node is expected to be able to forward the packets towards the destination.
- リダイレクトのターゲット、ターゲットがリダイレクトされているパケット内の宛先アドレスと異なる場合は、暗黙的にルータと見なされます。そのノードがパケットを目的地に向けることができると予想されるので、これは自然な仮定です。
- The target of the redirect, when the target is the same as the destination, does not carry any host vs. router information. All that is known is that the destination (i.e., target) is on-link but it could be either a host or a router.
- ターゲットが宛先と同じであるリダイレクトのターゲットは、ホストとルータ情報を持ちません。知られているのは、宛先（すなわちターゲット）がオンリンクであるが、それはホストまたはルータのいずれかであり得ることである。
The rules for setting the IsRouter flag are based on the information content above. If an ND message contains explicit or implicit information, the receipt of the message will cause the IsRouter flag to be updated. But when there is no host vs. router information in the ND message, the receipt of the message MUST NOT cause a change to the IsRouter state. When the receipt of such a message causes a Neighbor Cache entry to be created, this document specifies that the IsRouter flag be set to FALSE. There is greater potential for mischief when a node incorrectly thinks a host is a router, than the other way around. In these cases, a subsequent Neighbor Advertisement or Router Advertisement message will set the correct IsRouter value.
ISROUTERフラグを設定するための規則は、上記の情報コンテンツに基づいています。NDメッセージに明示的な情報や暗黙的な情報が含まれている場合、メッセージの受信によってISROUTERフラグが更新されます。しかし、NDメッセージにホストとルータ情報がない場合、メッセージの受信はISROUTER状態に変更を引き起こしてはなりません。そのようなメッセージの受信がネイバーキャッシュエントリを作成すると、このドキュメントはISROUTERフラグがFALSEに設定されることを指定します。ノードが誤ってホストが誤っていると考えると、他の方法よりもノードがルータであると考えられます。このような場合、後続の隣接アドバタイズメントまたはルータ広告メッセージが正しいISROUTER値を設定します。
Appendix E: Implementation Issues
付録E：実装の問題
Neighbor Unreachability Detection requires explicit confirmation that a forward-path is functioning properly. To avoid the need for Neighbor Solicitation probe messages, upper-layer protocols should provide such an indication when the cost of doing so is small. Reliable connection-oriented protocols such as TCP are generally aware when the forward-path is working. When TCP sends (or receives) data, for instance, it updates its window sequence numbers, sets and cancels retransmit timers, etc. Specific scenarios that usually indicate a properly functioning forward-path include:
近隣の到達不可能な検出には、順方向パスが正しく機能しているという明示的な確認が必要です。隣接勧誘プローブメッセージの必要性を回避するために、上層プロトコルは、そうするコストが小さいときにそのような指示を提供するべきである。TCPなどの信頼性の高い接続指向プロトコルは、順方向パスが機能しているときに一般的に認識されています。たとえば、TCPがデータを送信（または受信）すると、そのウィンドウシーケンス番号を更新し、再送信タイマーの設定とキャンセルなどを更新します。通常、正しく機能しているフォワードパスを示す特定のシナリオは次のとおりです。
- Receipt of an acknowledgment that covers a sequence number (e.g., data) not previously acknowledged indicates that the forward path was working at the time the data was sent.
- 以前に確認されていないシーケンス番号（例えば、データ）をカバーする確認応答を受信することは、データが送信された時点で前方パスが機能していたことを示します。
- Completion of the initial three-way handshake is a special case of the previous rule; although no data is sent during the handshake, the SYN flags are counted as data from the sequence number perspective. This applies to both the SYN+ACK for the active open and the ACK of that packet on the passively opening peer.
- 最初の三方ハンドシェイクの完了は、前の規則の特別な場合です。ハンドシェイク中にデータは送信されませんが、SYNフラグはシーケンス番号のパースペクティブからのデータとしてカウントされます。これは、アクティブオープンのSYN ACKと受動オープンピア上のそのパケットのACKの両方に適用されます。
- Receipt of new data (i.e., data not previously received) indicates that the forward-path was working at the time an acknowledgment was sent that advanced the peer's send window that allowed the new data to be sent.
- 新しいデータの受信（すなわち、以前に受信されていないデータ）は、肯定応答が送信された時点で機能していたことを示し、これは、新しいデータを送信することを可能にするピアの送信ウィンドウを高度に送信したことを示している。
To minimize the cost of communicating reachability information between the TCP and IP layers, an implementation may wish to rate-limit the reachability confirmations its sends IP. One possibility is to process reachability only every few packets. For example, one might update reachability information once per round-trip time, if an implementation only has one round-trip timer per connection. For those implementations that cache Destination Cache entries within control blocks, it may be possible to update the Neighbor Cache entry directly (i.e., without an expensive lookup) once the TCP packet has been demultiplexed to its corresponding control block. For other implementations, it may be possible to piggyback the reachability confirmation on the next packet submitted to IP assuming that the implementation guards against the piggybacked confirmation becoming stale when no packets are sent to IP for an extended period of time.
TCP層とIP層との間の到達可能性情報を伝達するコストを最小限に抑えるために、実装はIPを送信する到達可能性確認を率を制限したいと思うかもしれません。1つの可能性は、到達可能性をいくつかのパケットごとに処理することです。たとえば、実装に1回のラウンドトリップタイマーしか持たない場合、往復時間に1回到達可能性情報を更新することができます。コントロールブロック内の宛先キャッシュエントリをキャッシュする実装形態では、TCPパケットがその対応する制御ブロックに分離された後に（すなわち、高価なルックアップなしで）隣接キャッシュエントリを更新することが可能であり得る。他の実装形態では、パケットがIPに長期間にわたって送信されない場合に、PiggyBacked確認になると、IPに提出された次のパケットに関する到達可能性確認をPiggybackにすることが可能であり得る。
TCP must also guard against thinking "stale" information indicates current reachability. For example, new data received 30 minutes after a window has opened up does not constitute a confirmation that the path is currently working; it merely indicates that 30 minutes ago the window update reached the peer, i.e., the path was working at that point in time. An implementation must also take into account TCP zero-window probes that are sent even if the path is broken and the window update did not reach the peer.
TCPはまた、「古い」情報を考える必要があり、現在の到達可能性を示す。たとえば、ウィンドウが開いてから30分後に新しいデータが受信されてからパスが現在機能しているという確認はありません。それは単に30分前にウィンドウの更新がピアに到達したこと、すなわちその時点でその時点で動作していたことを示すだけです。実装は、パスが壊れていてもウィンドウの更新がピアに届かなかった場合でも送信されるTCPゼロウィンドウプローブを考慮に入れる必要があります。
For UDP-based applications (Remote Procedure Call (RPC), DNS), it is relatively simple to make the client send reachability confirmations when the response packet is received. It is more difficult and in some cases impossible for the server to generate such confirmations since there is no flow control, i.e., the server cannot determine whether a received request indicates that a previous response reached the client.
UDPベースのアプリケーション（リモートプロシージャコール（RPC）、DNS）の場合、応答パケットが受信されたときにクライアントが到達可能性確認を送信させるのは比較的簡単です。フロー制御がないので、サーバがそのような確認を生成することはより困難であり、そのような確認は不可能であり、すなわちサーバは、受信した要求が前の応答がクライアントに到達したことを示すかどうかを判断できない。
Note that an implementation cannot use negative upper-layer advice as a replacement for the Neighbor Unreachability Detection algorithm. Negative advice (e.g., from TCP when there are excessive retransmissions) could serve as a hint that the forward path from the sender of the data might not be working. But it would fail to detect when the path from the receiver of the data is not functioning, causing none of the acknowledgment packets to reach the sender.
インプリメンテーションは、ネイバーの到達不能検出アルゴリズムの代わりとして、負の上位層のアドバイスを使用することはできません。マイナスのアドバイス（例えば、過度の再送信がある場合のTCPから）は、データの送信者からの順方向パスが機能しない可能性があるヒントとして機能する可能性があります。しかし、データの受信側からのパスが機能していないときに検出できず、確認応答パケットのどれも送信者に到達させません。
Appendix F: Changes from RFC 2461
付録F：RFC 2461からの変更
o Removed references to IPsec AH and ESP for securing messages or as part of validating the received message.
o メッセージを保護するため、または受信したメッセージの検証の一部として、IPsec AHとESPへの参照を削除しました。
o Added Section 3.3.
o セクション3.3を追加しました。
o Updated Section 11 to include more detailed discussion on threats, IPsec limitations, and use of SEND.
o 更新されたセクション11は、脅威、IPSecの制限、および送信の使用に関するより詳細な議論を含むように更新されました。
o Removed the on-link assumption in Section 5.2 based on RFC 4942, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful".
o RFC 4942、「IPv6隣接発見オンリンク仮定」をベースにしたセクション5.2のオンリンクの仮定を削除しました。
o Clarified the definition of the Router Lifetime field in Section 4.2.
o セクション4.2のルータライフタイムフィールドの定義を明確にしました。
o Updated the text in Sections 4.6.2 and 6.2.1 to indicate that the preferred lifetime must not be larger than valid lifetime.
o 推奨されるライフタイムが有効な有効期間より大きくなければならないことを示すために、セクション4.6.2および6.2.1のテキストを更新しました。
o Removed the reference to stateful configuration and added reference for DHCPv6 instead.
o 代わりにステートフル構成への参照を削除し、DHCPv6の参照を追加しました。
o Added the IsRouter flag definition to Section 6.2.1 to allow for mixed host/router behavior.
o 混在ホスト/ルータの動作を可能にするために、ISROUTERフラグ定義をセクション6.2.1に追加しました。
o Allowed mobile nodes to be exempt from adding random delays before sending an RS during a handover.
o ハンドオーバ中にRSを送信する前に、許可されたモバイルノードにランダムな遅延を追加することが除外されます。
o Updated the definition of the prefix length in the prefix option.
o プレフィックスオプションのプレフィックス長の定義を更新しました。
o Updated the applicability to NBMA links in the introduction and added references to 3GPP RFCs.
o 紹介でNBMAリンクへの適用性を更新し、3GPP RFCへの参照を追加しました。
o Clarified that support for load balancing is limited to routers.
o 負荷分散のサポートはルータに限られていることを明確にしました。
o Clarified router behavior when receiving a Router Solicitation without Source Link-Layer Address Option (SLLAO).
o ソースリンク層アドレスオプション（SLLAO）なしでルータ勧誘を受信すると、明確化されたルータの動作。
o Clarified that inconsistency checks for CurHopLimit are done for non-zero values only.
o Curhoplimitの矛盾チェックは、ゼロ以外の値に対してのみ行われていることを明確にしました。
o Rearranged Section 7.2.5 for clarity, and described the processing when receiving the NA in INCOMPLETE state.
o 明確にするために、7.2.5を並べ替え、不完全状態でNAを受信するときに処理を説明しました。
o Added clarifications in Section 7.2 on how a node should react upon receiving a message without SLLAO.
o SLLAOなしのメッセージを受信したときにノードがどのように反応するかについてのセクション7.2の説明を追加しました。
o Added new IANA section.
o 新しいIANAセクションを追加しました。
o Miscellaneous editorials.
o その他の編集
Acknowledgments
謝辞
The authors of RFC 2461 would like to acknowledge the contributions of the IPV6 working group and, in particular, (in alphabetical order) Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, Matt Thomas, and Susan Thomson.
RFC 2461の著者は、IPv6ワーキンググループの貢献、特に（アルファベット順）RAN Atkinson、Jim Bound、Scott Bradner、Alex Conta、Stephen Theering、Richard Draves、Francis Dupont、Robert Elz、Robert Gilligan、Robert Hinden、Tatuya Jinmei、Allison Mankin、Dan McDonald、Charles Perkins、Matt Thomas、Susan Thomson。
The editor of this document (Hesham Soliman) would like to thank the IPV6 working group for the numerous contributions to this revision -- in particular (in alphabetical order), Greg Daley, Elwyn Davies, Ralph Droms, Brian Haberman, Bob Hinden, Tatuya Jinmei, Pekka Savola, Fred Templin, and Christian Vogt.
この文書の編集者（Hesham Soliman）は、特にこのリビジョンへの多数の貢献について感謝します - 特に（アルファベット順）、Greg Daley、Elwyn Davies、Ralph Droms、Brian Haberman、Bob Hinden、TatuyaJinmei、Pekka Savola、Fred Templin、そしてキリスト教のVogt。
Authors' Addresses
著者の住所
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
Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark Sun Microsystems、Inc。17 Network Circle Menlo Park、CA 94025 USA
Phone: +1 650 786 2921
Fax: +1 650 786 5896
EMail: erik.nordmark@sun.com
William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 USA
ウィリアムアレンシンプソンDayDreamerコンピュータシステムコンサルティングサービス1384 Fontaine Madison Heights、ミシガン州48071 USA
EMail: william.allen.simpson@gmail.com
Hesham Soliman Elevate Technologies
Hesham Solimanの昇格技術
EMail: hesham@elevatemobile.com
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に情報を宛先に宛ててください。