[要約] RFC 2461はIPv6のためのNeighbor Discoveryプロトコルであり、ネットワーク上のノード間の通信を効率的に行うための手法を提供します。このRFCの目的は、IPv6ネットワークでのノードの自己設定と通信の最適化を実現することです。
Network Working Group T. Narten
Request for Comments: 2461 IBM
Obsoletes: 1970 E. Nordmark
Category: Standards Track Sun Microsystems
W. Simpson
Daydreamer
December 1998
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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............................................. 3
2. TERMINOLOGY.............................................. 4
2.1. General............................................. 4
2.2. Link Types.......................................... 7
2.3. Addresses........................................... 8
2.4. Requirements........................................ 9
3. PROTOCOL OVERVIEW........................................ 9
3.1. Comparison with IPv4................................ 13
3.2. Supported Link Types................................ 15
4. MESSAGE FORMATS.......................................... 17
4.1. Router Solicitation Message Format.................. 17
4.2. Router Advertisement Message Format................. 18
4.3. Neighbor Solicitation Message Format................ 21
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........................ 35
5.3. Garbage Collection and Timeout Requirements......... 37
6. ROUTER AND PREFIX DISCOVERY.............................. 37
6.1. Message Validation.................................. 38
6.1.1. Validation of Router Solicitation Messages..... 38
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.............. 44
6.2.3. Router Advertisement Message Content........... 44
6.2.4. Sending Unsolicited Router Advertisements...... 46
6.2.5. Ceasing To Be An Advertising Interface......... 46
6.2.6. Processing Router Solicitations................ 47
6.2.7. Router Advertisement Consistency............... 48
6.2.8. Link-local Address Change...................... 49
6.3. Host Specification.................................. 50
6.3.1. Host Configuration Variables................... 50
6.3.2. Host Variables................................. 50
6.3.3. Interface Initialization....................... 51
6.3.4. Processing Received Router Advertisements...... 51
6.3.5. Timing out Prefixes and Default Routers........ 54
6.3.6. Default Router Selection....................... 54
6.3.7. Sending Router Solicitations................... 55
7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION. 56
7.1. Message Validation.................................. 57
7.1.1. Validation of Neighbor Solicitations........... 57
7.1.2. Validation of Neighbor Advertisements.......... 58
7.2. Address Resolution.................................. 58
7.2.1. Interface Initialization....................... 59
7.2.2. Sending Neighbor Solicitations................. 59
7.2.3. Receipt of Neighbor Solicitations.............. 60
7.2.4. Sending Solicited Neighbor Advertisements...... 61
7.2.5. Receipt of Neighbor Advertisements............. 62
7.2.6. Sending Unsolicited Neighbor Advertisements.... 64
7.2.7. Anycast Neighbor Advertisements................ 65
7.2.8. Proxy Neighbor Advertisements.................. 65
7.3. Neighbor Unreachability Detection................... 66
7.3.1. Reachability Confirmation...................... 66
7.3.2. Neighbor Cache Entry States.................... 67
7.3.3. Node Behavior.................................. 68
8. REDIRECT FUNCTION........................................ 70
8.1. Validation of Redirect Messages..................... 71
8.2. Router Specification................................ 72
8.3. Host Specification.................................. 73
9. EXTENSIBILITY - OPTION PROCESSING........................ 74
10. PROTOCOL CONSTANTS...................................... 75
11. SECURITY CONSIDERATIONS................................. 76
12. RENUMBERING CONSIDERATIONS.............................. 78
References................................................... 80
Authors' Addresses........................................... 81
Appendix A: Multihomed Hosts................................. 82
Appendix B: Future Extensions................................ 84
Appendix C: State Machine for the Reachability State......... 85
Appendix D: Summary of ISROUTER Rules........................ 88
Appendix E: Implementation Issues............................ 89
Appendix E.1: Reachability confirmations................. 89
Appendix F: Changes since RFC 1970........................... 91
Full Copyright Statement..................................... 93
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., 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 is an area for further study.
特に明記されていない限り（特定のリンクタイプでの動作IPを扱っているドキュメントで）、このドキュメントはすべてのリンクタイプに適用されます。ただし、NDは一部のサービスにリンク層マルチキャストを使用するため、一部のリンクタイプ（NBMAリンクなど）では、それらのサービスを実装するための代替プロトコルまたはメカニズムが指定されている可能性があります（IPの操作をカバーする適切なドキュメントで特定のリンクタイプを介して）。このドキュメントで説明されているように、リダイレクト、ネクストホップの決定、近隣到達不能検出など、マルチキャストに直接依存しないサービスは、このドキュメントで指定されているとおりに提供されることが想定されています。 NBMAリンクでNDをどのように使用するかについての詳細は、さらに調査する必要があります。
The authors would like to acknowledge the contributions of the IPNGWG 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, Allison Mankin, Dan McDonald, Charles Perkins, Matt Thomas, and Susan Thomson.
著者は、IPNGWGワーキンググループの貢献、特に（アルファベット順で）ランアトキンソン、ジムバウンド、スコットブラドナー、アレックスコンタ、スティーブンディアリング、リチャードドレーブス、フランシスデュポン、ロバートエルツ、ロバートギリガン、ロバートヒンデン、アリソンマンキン、ダンマクドナルド、チャールズパーキンス、マットトーマス、スーザントムソン。
IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used only in contexts where necessary to avoid ambiguity.
IP-インターネットプロトコルバージョン6。IPv4およびIPv6という用語は、あいまいさを避けるために必要な場合にのみ使用されます。
ICMP - Internet Message Control Protocol for the Internet Protocol Version 6. The terms ICMPv4 and ICMPv6 are used only in contexts where necessary to avoid ambiguity.
ICMP-インターネットプロトコルバージョン6のインターネットメッセージ制御プロトコル。用語ICMPv4およびICMPv6は、あいまいさを避けるために必要なコンテキストでのみ使用されます。
node - a device that implements IP.
ノード-IPを実装するデバイス。
router - a node that forwards IP packets not explicitly addressed to itself.
ルーター-明示的にアドレス指定されていないIPパケットを転送するノード。
host - any node that is not a router.
ホスト-ルーターではないノード。
upper layer - a protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IP such as IPX, AppleTalk, or IP itself.
上位層-IPのすぐ上のプロトコル層。例としては、TCPやUDPなどのトランスポートプロトコル、ICMPなどの制御プロトコル、OSPFなどのルーティングプロトコル、IPX、AppleTalk、IP自体などのIPで「トンネリング」される（つまりカプセル化される）インターネットまたは下位層プロトコルがあります。 。
link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as internet (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].
エニーキャストアドレス-インターフェイスのセットの識別子（通常は異なるノードに属します）。エニーキャストアドレスに送信されたパケットは、そのアドレスで識別されるインターフェイスの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.
エニーキャストアドレスは、構文的にはユニキャストアドレスと区別できないことに注意してください。したがって、エニーキャストアドレスにパケットを送信するノードは、通常、エニーキャストアドレスが使用されていることを知りません。このドキュメントの残りの部分では、ユニキャストアドレスへの言及は、ノードがユニキャストアドレスが実際にはエニーキャストアドレスであることを認識していない場合のエニーキャストアドレスにも適用されます。
prefix - a bit string that consists of some number of initial bits of an address.
プレフィックス-アドレスのいくつかの初期ビットで構成されるビット文字列。
link-layer address - a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links and E.164 addresses for ISDN links.
リンク層アドレス-インターフェイスのリンク層識別子。例としては、イーサネットリンクのIEEE 802アドレスやISDNリンクのE.164アドレスなどがあります。
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, or
- リンクの接頭辞の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 piece over a link.
リンクMTU-リンク上で1つにまとめて送信できる最大伝送単位、つまりオクテット単位の最大パケットサイズ。
target - an address about which address resolution information is sought, or an address which is the new first-hop when being redirected.
target-アドレス解決情報が検索されるアドレス、またはリダイレクトされるときの新しい最初のホップであるアドレス。
proxy - a router 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.
プロキシ-別のノードに代わって近隣探索クエリメッセージに応答するルーター。オフリンクに移動したモバイルノードに代わって動作するルーターは、モバイルノードのプロキシとして機能する可能性があります。
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 insure that the granularity of the calculated random component and the resolution of the timer used are both high enough to insure 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 token alone as the seed, since interface tokens will not always be unique. To reduce the probability that duplicate interface tokens 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 token.
ランダム遅延シード-ランダム遅延コンポーネントの計算に疑似乱数ジェネレータを使用する場合、ジェネレータを使用する前に固有のシードで初期化する必要があります。インターフェイストークンは常に一意であるとは限らないため、シードとしてインターフェイストークンだけを使用するだけでは不十分です。重複するインターフェイストークンが同じシードを使用する可能性を減らすために、シードは、同じ「ボックス」上でも異なる可能性が高いさまざまな入力ソース（マシンコンポーネントなど）から計算する必要があります。たとえば、CPUのシリアル番号とインターフェイストークンを組み合わせてシードを形成できます。
Different link layers have different properties. The ones of concern to Neighbor Discovery are:
リンク層が異なれば、プロパティも異なります。ネイバーディスカバリーの懸念事項は次のとおりです。
multicast - 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.
マルチキャスト-パケットをすべて（つまり、ブロードキャスト）またはすべてのネイバーのサブセットに送信するために、リンク層でネイティブメカニズムをサポートするリンク。
point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast capability and have a link-local address.
ポイントツーポイント-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.).
非ブロードキャストマルチアクセス（NBMA）-3つ以上のインターフェースを接続できるリンクですが、ネイティブ形式のマルチキャストまたはブロードキャスト（X.25、ATM、フレームリレーなど）をサポートしていません。
Note that all link types (including NBMA) are expected to provide multicast service for IP (e.g., using multicast servers), but it is an issue for further study whether ND should use such facilities or an alternate mechanism that provides the equivalent ND services.
すべてのリンクタイプ（NBMAを含む）がIPにマルチキャストサービスを提供することが期待されていることに注意してください（たとえば、マルチキャストサーバーを使用して）。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 SMDS and B-ISDN. Also known as "large clouds". See [SH-MEDIA].
共有メディア-多数のノード間の直接通信を可能にするリンクですが、接続されたノードは、すべてのリンク上の宛先の完全なプレフィックス情報を持たないように構成されています。つまり、IPレベルでは、同じリンク上のノードは、それらが隣接していることを認識していない可能性があります。デフォルトでは、ルーターを介して通信します。例としては、SMDSやB-ISDNなどの大規模な（スイッチ）パブリックデータネットワークがあります。 「大きな雲」とも呼ばれます。 [SH-MEDIA]を参照してください。
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トークンリングなど）がないリンク。多くのリンク（イーサネットなど）には、リンク層プロトコルまたはリンク層で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.
非対称到達可能性-非再帰的および/または非推移的到達可能性が通常の操作の一部であるリンク。 （非再帰的到達可能性とは、AからのパケットがBに到達するが、BからのパケットはAに到達しないことを意味します。非推移的到達可能性は、AからのパケットがBに到達し、BからのパケットがCに到達しますが、AからのパケットはCに到達しません。）多くの無線リンクはこれらの特性を示します。
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 which differ only in the high-order bits, e.g., due to multiple high-order prefixes associated with different providers, will map to the same solicited-node address thereby reducing the number of multicast addresses a node must join.
要請ノードマルチキャストアドレス-要請ターゲットのアドレスの関数として計算されるリンクローカルスコープのマルチキャストアドレス。関数は[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.
リンクローカルアドレス-ネイバーに到達するために使用できるリンクのみのスコープを持つユニキャストアドレス。ルーター上のすべてのインターフェイスには、リンクローカルアドレスが必要です。また、[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 address autoconfiguration [ADDRCONF]). The unspecified address has a value of 0:0:0:0:0:0:0:0.
unspecified address-アドレスがないことを示す予約済みのアドレス値（例：アドレスが不明）。これは宛先アドレスとして使用されることはありませんが、送信者が自分のアドレスを（まだ）知らない場合（たとえば、アドレスの自動構成中にアドレスが使用されていないことの確認[ADDRCONF]）は、送信元アドレスとして使用できます。未指定アドレスの値は0：0：0：0：0：0：0：0です。
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].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、[キーワード]で説明されているように解釈されます。
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 such link parameters as the link MTU or such Internet parameters as the hop limit value to place in outgoing packets.
パラメータ検出：ノードがリンクMTUなどのリンクパラメータや、送信パケットに配置するホップ制限値などのインターネットパラメータを学習する方法。
Address Autoconfiguration: How nodes automatically configure an address for an interface.
アドレスの自動構成：ノードがインターフェースのアドレスを自動的に構成する方法。
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 that an address it wishes to use is not 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パケットタイプを定義します。ルーター要請メッセージとルーターアドバタイズメントメッセージのペア、近隣要請メッセージと近隣アドバタイズメントメッセージのペア、リダイレクトメッセージです。メッセージの目的は次のとおりです。
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 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 Advertisement: A response to a Neighbor Solicitation message. A node may also send unsolicited Neighbor Advertisements to announce a link-layer address change.
Neighbor Advertisement：近隣要請メッセージへの応答。ノードは、非送信請求ネイバーアドバタイズメントを送信して、リンク層アドレスの変更を通知することもできます。
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 stateful (DHCPv6) and/or autonomous (stateless) address configuration. The exact semantics and usage of the address configuration-related information is specified in [ADDRCONF].
ルーターアドバタイズメント（およびプレフィックスごとのフラグ）により、ルーターはホストにアドレスの自動構成を実行する方法を通知できます。たとえば、ルーターは、ホストがステートフル（DHCPv6）または自律（ステートレス）アドレス構成を使用するかどうかを指定できます。アドレス構成関連情報の正確なセマンティクスと使用法は、[ADDRCONF]で指定されています。
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.
ルーターアドバタイズメッセージには、ホストが発信パケットで使用するホップリミットなどのインターネットパラメーターと、オプションでリンク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].
近隣要請メッセージは、複数のノードに同じユニキャストアドレスが割り当てられているかどうかを判断するためにも使用できます。重複アドレス検出のための近隣要請メッセージの使用は、[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.
インバウンドロードバランシング-複製されたインターフェースを持つノードは、同じリンク上の複数のネットワークインターフェース間で着信パケットの受信をロードバランシングする必要がある場合があります。このようなノードには、同じインターフェースに割り当てられた複数のリンク層アドレスがあります。たとえば、単一のネットワークドライバーは、複数のネットワークインターフェイスカードを、複数のリンク層アドレスを持つ単一の論理インターフェイスとして表すことができます。
Load balancing is handled 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 who issued the solicitation.
負荷分散は、ルーターがルーターアドバタイズパケットからソースリンク層アドレスを省略できるようにすることで処理されます。これにより、ネイバーは近隣要請メッセージを使用してルーターのリンク層アドレスを学習するようになります。返されたネイバーアドバタイズメントメッセージには、要請を発行したユーザーに応じて異なるリンク層アドレスを含めることができます。
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. This invokes specific rules to determine which of potentially multiple advertisements should be used.
エニーキャストアドレス-エニーキャストアドレスは、同等のサービスを提供する一連のノードの1つを識別し、同じリンク上の複数のノードが同じエニーキャストアドレスを認識するように構成できます。ネイバー探索は、ノードに同じターゲットの複数のネイバーアドバタイズを受信することを期待させることで、エニーキャストを処理します。エニーキャストアドレスのすべてのアドバタイズは、非オーバーライドアドバタイズとしてタグ付けされます。これにより、特定のルールが呼び出され、複数の広告のどれを使用する必要があるかが決定されます。
Proxy advertisements - A router willing to accept packets on behalf of a target address that is unable to respond to Neighbor Solicitations can issue non-Override Neighbor Advertisements. There is currently no specified use of proxy, but proxy advertising could potentially be used to handle cases like mobile nodes that have moved off-link. However, it is not intended as a general mechanism to handle nodes that, e.g., do not implement this protocol.
プロキシアドバタイズメント-ネイバー要請に応答できないターゲットアドレスに代わってパケットを受け入れようとするルーターは、非オーバーライドネイバーアドバタイズメントを発行できます。現在、プロキシの使用は指定されていませんが、プロキシアドバタイジングは、オフリンクに移動したモバイルノードなどのケースを処理するために使用される可能性があります。ただし、このプロトコルを実装しないノードなどを処理するための一般的なメカニズムとしては意図されていません。
The IPv6 Neighbor Discovery protocol corresponds to a combination of the IPv4 protocols ARP [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 Hosts Requirements [HR-CL] does specify some possible algorithms for Dead Gateway Detection (a subset of the problems Neighbor Unreachability Detection tackles).
IPv6近隣探索プロトコルは、IPv4プロトコルのARP [ARP]、ICMPルーター探索[RDISC]、およびICMPリダイレクト[ICMPv4]の組み合わせに対応しています。ホスト要件[HR-CL]はデッドゲートウェイ検出の可能なアルゴリズムをいくつか指定していますが、IPv4では一般的に合意されたプロトコルまたはメカニズムが近隣到達不能検出に対応していません（近隣到達不能検出が取り組む問題のサブセット）。
The Neighbor Discovery protocol provides a multitude of improvements over the IPv4 set of protocols:
Neighbor Discoveryプロトコルは、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".
ルーターアドバタイズメントは、リンクのプレフィックスを伝達します。 「ネットマスク」を構成するための個別のメカニズムを用意する必要はありません。
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 4 billion (2^32) multicast addresses greatly reducing address resolution related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all.
アドレス解決マルチキャストは、40億（2 ^ 32）のマルチキャストアドレスに「広がる」ため、ターゲット以外のノードでのアドレス解決関連の割り込みが大幅に削減されます。さらに、非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-MEDIA]で指定されたXRedirect機能に類似しています。これは、ノードがリンク上の宛先のすべてのプレフィックスを知ることが望ましくない、または不可能である非ブロードキャストおよび共有メディアリンクで役立つと予想されます。
Neighbor Unreachability Detection is part of the base significantly improving the robustness of packet delivery in the presence of failing routers, partially failing or partitioned links and nodes that change their link-layer addresses. For instance, mobile nodes can move off-link without losing any connectivity due to stale ARP caches.
Neighbor Unreachability Detectionはベースの一部であり、障害のあるルーター、部分的に障害のあるリンク、またはリンク層アドレスを変更するノードおよびノードが存在する場合のパケット配信の堅牢性を大幅に向上させます。たとえば、モバイルノードは、古くなった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ルーター発見とは異なり、ルーターアドバタイズメッセージには優先フィールドが含まれていません。設定フィールドは、「安定性」の異なるルーターを処理する場合には必要ありません。 Neighbor Unreachability Detectionは、停止しているルーターを検出し、機能しているルーターに切り替えます。
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.
ルーターを一意に識別するためにリンクローカルアドレスを使用すると（ルーターアドバタイズおよびリダイレクトメッセージの場合）、サイトが番号を付け直したときに、ホストがルーターの関連付けを維持して、新しいグローバルプレフィックスを使用できるようになります。
Using the Hop Limit equal to 255 trick 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 standard IP authentication and security mechanisms as appropriate [IPv6-AUTH, IPv6-ESP].
ICMP層にアドレス解決を配置すると、プロトコルはARPよりもメディアに依存しなくなり、必要に応じて標準のIP認証およびセキュリティメカニズムを使用できるようになります[IPv6-AUTH、IPv6-ESP]。
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.) Neighbor Discovery should be implemented as described in this document.
ポイントツーポイント-近隣探索は、このようなリンクをマルチキャストリンクと同じように処理します。 （マルチキャストはポイントツーポイントリンクで簡単に提供でき、インターフェイスにはリンクローカルアドレスを割り当てることができます。）近隣探索は、このドキュメントで説明されているように実装する必要があります。
multicast - Neighbor Discovery should be implemented 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 is 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.
non-broadcast multiple access（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-MEDIA]の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 a 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 all receivers can process.
変数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.
このプロトコルは、将来的に拡張されて、再帰的および推移的な接続が欠落している環境で実行可能なパスを見つけることができます。
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
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
認証ヘッダーIP認証ヘッダーのセキュリティアソシエーションが送信者と宛先アドレスの間に存在する場合、送信者はこのヘッダーを含める必要があります（SHOULD）。
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 message periodically, or in response to a Router Solicitation.
ルーターは、定期的に、またはルーター要請に応答して、ルーター通知メッセージを送信します。
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
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
認証ヘッダーIP認証ヘッダーのセキュリティアソシエーションが送信者と宛先アドレスの間に存在する場合、送信者はこのヘッダーを含める必要があります（SHOULD）。
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ヘッダーのホップカウントフィールドに配置する必要があるデフォルト値。値0は、（このルーターによって）指定されていないことを意味します。
M 1-bit "Managed address configuration" flag. When set, hosts use the administered (stateful) protocol for address autoconfiguration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is described in [ADDRCONF].
M 1ビットの「管理アドレス構成」フラグ。設定すると、ホストは、ステートレスアドレス自動構成を使用して自動構成されたアドレスに加えて、アドレス自動構成に管理された（ステートフル）プロトコルを使用します。このフラグの使用については、[ADDRCONF]で説明されています。
O 1-bit "Other stateful configuration" flag. When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information. The use of this flag is described in [ADDRCONF].
O 1ビットの「その他のステートフル構成」フラグ。設定すると、ホストは管理された（ステートフル）プロトコルを使用して、他の（非アドレス）情報を自動構成します。このフラグの使用については、[ADDRCONF]で説明されています。
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 maximum value corresponds to 18.2 hours. 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ビット符号なし整数。秒単位のデフォルトルーターに関連付けられた寿命。最大値は18.2時間に相当します。ライフタイム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
到達可能時間32ビット符号なし整数。到達可能性の確認を受信した後、ノードがネイバーに到達可能であるとノードが想定する時間（ミリ秒単位）。近隣到達不能検出アルゴリズムで使用されます（7.3節を参照）。の値
zero means unspecified (by this router).
ゼロは、（このルーターによって）指定されていないことを意味します。
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).
Retrans Timer 32ビット符号なし整数。再送信された近傍要請メッセージ間の時間（ミリ秒単位）。アドレス解決および近隣到達不能検出アルゴリズムで使用されます（セクション7.2および7.3を参照）。値0は、（このルーターによって）指定されていないことを意味します。
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.
送信元リンク層アドレスルーターアドバタイズが送信されるインターフェイスのリンク層アドレス。アドレスを持つリンク層でのみ使用されます。ルーターは、複数のリンク層アドレス間でインバウンドの負荷分散を可能にするために、このオプションを省略してもよい（MAY）。
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を実行する方法を説明するドキュメントで指定されている）を持つリンクで送信する必要があります（SHOULD）。他のリンクで送信される場合があります。
Prefix Information These options specify the prefixes that are on-link and/or are used for 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 multihomed host 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.
送信元アドレスこのメッセージの送信元のインターフェースに割り当てられたアドレス、または（重複アドレス検出が進行中の場合[ADDRCONF]）未指定のアドレス。
Destination Address Either the solicited-node multicast address corresponding to the target address, or the target address.
宛先アドレスターゲットアドレスに対応する請求ノードマルチキャストアドレス、またはターゲットアドレス。
Hop Limit 255
ホップ制限255
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
認証ヘッダーIP認証ヘッダーのセキュリティアソシエーションが送信者と宛先アドレスの間に存在する場合、送信者はこのヘッダーを含める必要があります（SHOULD）。
ICMP Fields:
ICMPフィールド：
Type 135
タイプ135
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 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アドレスが指定されていないアドレスの場合は含めないでください。それ以外の場合、アドレスを持つリンク層では、このオプションはマルチキャスト要請に含まれている必要があり、ユニキャスト要請に含まれている必要があります（SHOULD）。
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
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
認証ヘッダーIP認証ヘッダーのセキュリティアソシエーションが送信者と宛先アドレスの間に存在する場合、送信者はこのヘッダーを含める必要があります（SHOULD）。
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ビットは、アドバタイズが宛先アドレスからの近隣要請に応答して送信されたことを示します。 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.
ターゲットリンク層アドレスターゲット、つまり広告の送信者のリンク層アドレス。このオプションは、マルチキャスト要請に応答するときにアドレスを持つリンク層に含める必要があります。ユニキャスト近隣要請に応答するときは、このオプションを含める必要があります（SHOULD）。
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 have 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 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
ホップ制限255認証ヘッダー送信者と宛先アドレスの間にIP認証ヘッダーのセキュリティアソシエーションが存在する場合、送信者はこのヘッダーを含める必要があります（SHOULD）。
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 which 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 1280 octets.
リダイレクトされたヘッダーリダイレクトパケットを作成せずにリダイレクトの送信をトリガーしたIPパケットは、可能な限り1280オクテットを超えます。
Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. All options are of the form:
近隣探索メッセージには0個以上のオプションが含まれ、その一部は同じメッセージで複数回表示される場合があります。すべてのオプションは次の形式です。
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
ソースリンク層アドレスのタイプ1、ターゲットリンク層アドレスの2
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-ETHER]です。
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.
説明Source Link-Layer Addressオプションには、パケットの送信者のリンク層アドレスが含まれています。これは、近傍要請、ルーター要請、およびルーター通知パケットで使用されます。
The Target Link-Layer Address option contains the link-layer address of the target. It is used in Neighbor Advertisement and Redirect packets.
Target Link-Layer Addressオプションには、ターゲットのリンク層アドレスが含まれています。ネイバーアドバタイズメントおよびリダイレクトパケットで使用されます。
These options MUST be silently ignored for other Neighbor Discovery messages.
これらのオプションは、他の近隣探索メッセージに対しては黙って無視されなければなりません（MUST）。
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.
プレフィックス長8ビットの符号なし整数。有効なプレフィックスの先行ビットの数。値の範囲は0〜128です。
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. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off-link.
L 1ビットのオンリンクフラグ。設定されている場合、この接頭辞をオンリンクの決定に使用できることを示します。設定されていない場合、アドバタイズメントはプレフィックスのオンリンクまたはオフリンクのプロパティについては何も述べません。たとえば、プレフィックスはアドレス構成に使用され、プレフィックスに属するアドレスの一部はオンリンクであり、その他はオフリンクです。
A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for autonomous address configuration as specified in [ADDRCONF].
1ビットの自律アドレス構成フラグ。設定されている場合、このプレフィックスを[ADDRCONF]で指定されている自律アドレス構成に使用できることを示します。
Reserved1 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Reserved1 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]を参照してください。
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アドレスのプレフィックス。 Prefix Lengthフィールドには、プレフィックスの有効な先行ビットの数が含まれています。プレフィックス長の後のプレフィックス内のビットは予約されており、送信者によってゼロに初期化され、受信者によって無視される必要があります。ルーターはリンクローカルプレフィックスのプレフィックスオプションを送信すべきではなく（SHOULD NOT）、ホストはそのようなプレフィックスオプションを無視すべきです（SHOULD）。
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 1280 octets.
IPヘッダー+データリダイレクトメッセージのサイズが1280オクテットを超えないように、元のパケットが切り捨てられました。
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 insure 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 use the MTU option to specify the maximum MTU value that is supported by all segments.
異種テクノロジーが一緒にブリッジされる構成では、サポートされる最大MTUがセグメントごとに異なる場合があります。ブリッジがICMP Packet Too Bigメッセージを生成しない場合、通信ノードはパス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.
ネイバーキャッシュ-トラフィックが最近送信された個々のネイバーに関するエントリのセット。エントリは、ネイバーのオンリンクユニキャストIPアドレスをキーとし、そのリンク層アドレス、ネイバーがルーターであるかホストであるかを示すフラグ（このドキュメントではIsRouterと呼ばれます）、待機中のキューに入れられたパケットへのポインターなどの情報を含みますアドレス解決を完了するためなど
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.
ネイバーキャッシュエントリには、到達可能性の状態、未応答のプローブの数、次のネイバー到達不能検出イベントの実行予定時刻など、ネイバー到達不能検出アルゴリズムで使用される情報も含まれています。
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.
プレフィックスリスト-リンク上にある一連のアドレスを定義するプレフィックスのリスト。プレフィックスリストのエントリは、ルーターアドバタイズメントで受信した情報から作成されます。各エントリには、プレフィックスが無効になったときにプレフィックスを期限切れにするために使用される（広告から抽出された）無効化タイマー値が関連付けられています。特別な「無限」タイマー値は、後続の通知で新しい（有限）値が受信されない限り、プレフィックスが永久に有効であることを指定します。
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.
リンクローカルプレフィックスは、ルーターがプレフィックスをアドバタイズしているかどうかに関係なく、無効化タイマーが無限のプレフィックスリストにあると見なされます。受信したルーターアドバタイズは、リンクローカルプレフィックスの無効化タイマーを変更してはなりません（SHOULD NOT）。
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., IPv6 Mobility) 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モビリティなど）により、概念的なデータ構造が追加される場合があります。実装は、このようなデータ構造を自由に実装する自由があります。たとえば、実装では、すべての概念的なデータ構造を1つのルーティングテーブルにマージできます。
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.
INCOMPLETEアドレス解決が進行中であり、ネイバーのリンク層アドレスがまだ決定されていません。
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.
STALEネイバーは到達可能であるとはもはや認識されていませんが、トラフィックがネイバーに送信されるまで、その到達可能性を確認する試みは行われません。
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.
DELAYネイバーは到達可能であるとはもはや認識されておらず、トラフィックは最近ネイバーに送信されました。ただし、ネイバーをすぐにプローブするのではなく、上位層プロトコルに到達可能性の確認を提供する機会を与えるために、プローブの送信を少しの間遅らせます。
PROBE The neighbor is no longer known to be reachable, and unicast Neighbor Solicitation probes are being sent to verify reachability.
PROBEネイバーは到達可能であることがもはや認識されておらず、到達可能性を確認するためにユニキャストのネイバー要請プローブが送信されています。
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). If the Default Router List is empty, the sender assumes that the destination is on-link.
特定のユニキャスト宛先のネクストホップの決定は、次のように動作します。送信者は、プレフィックスリストに対して最長のプレフィックスマッチを実行して、パケットの宛先がオンリンクかオフリンクかを判別します。宛先がリンク上にある場合、ネクストホップアドレスはパケットの宛先アドレスと同じです。それ以外の場合、送信者はデフォルトルーターリストからルーターを選択します（セクション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アドレスがわかると、送信者はネイバーキャッシュでそのネイバーに関するリンク層情報を調べます。エントリが存在しない場合、送信者はエントリを作成し、その状態をINCOMPLETEに設定し、アドレス解決を開始してから、アドレス解決の完了までデータパケットをキューに入れます。マルチキャスト対応インターフェースの場合、アドレス解決は、近隣要請メッセージの送信と近隣アドバタイズメントの待機で構成されます。 Neighbor Advertisement応答を受信すると、リンク層アドレスがNeighbor Cacheエントリに入力され、キューに入れられたパケットが送信されます。アドレス解決メカニズムについては、セクション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 insure 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 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分以上）のみを再利用するLRUベースのポリシーは、未使用のエントリのガベージコレクションに適しています。
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 address autoconfiguration.
このセクションでは、近隣探索のルーター探索部分に関連するルーターとホストの動作について説明します。ルーター検出は、隣接ルーターを見つけるだけでなく、アドレスの自動構成に関連するプレフィックスと構成パラメーターを学習するために使用されます。
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.
プレフィックス検出は、ホストがリンク上に存在し、ルーターを経由せずに直接到達できる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.
ステートレスアドレス自動構成では、アドレスの構成の一部としてサブネットプレフィックスも取得する必要があります。アドレスの自動構成に使用されるプレフィックスは、オンリンクの決定に使用されるプレフィックスとは論理的に異なりますが、ネットワークトラフィックを削減するために、自動構成情報はルーター検出メッセージに便乗されます。実際、プレフィックス情報オプションで適切なフラグを指定することにより、同じプレフィックスをオンリンクの決定とアドレスの自動構成にアドバタイズできます。自動構成情報の処理方法の詳細については、[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です。つまり、パケットがルーターによって転送されていない可能性があります。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- メッセージにIP認証ヘッダーが含まれている場合、メッセージは正しく認証されます。
- 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.
Reservedフィールドの内容、および認識されないオプションの内容は無視する必要があります。プロトコルに対する将来の下位互換性のある変更により、Reservedフィールドの内容が指定されるか、新しいオプションが追加される可能性があります。下位互換性のない変更では、異なるコード値を使用する場合があります。
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です。つまり、パケットがルーターによって転送されていない可能性があります。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- メッセージにIP認証ヘッダーが含まれている場合、メッセージは正しく認証されます。
- 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.
Reservedフィールドの内容、および認識されないオプションの内容は無視する必要があります。プロトコルに対する将来の下位互換性のある変更により、Reservedフィールドの内容が指定されるか、新しいオプションが追加される可能性があります。下位互換性のない変更では、異なるコード値を使用する場合があります。
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 multicast interface:
各マルチキャストインターフェイスについて：
AdvSendAdvertisements A flag indicating whether or not the router sends periodic Router Advertisements and responds to Router Solicitations.
AdvSendAdvertisementsルーターが定期的なルーターアドバタイズを送信し、ルーター要請に応答するかどうかを示すフラグ。
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.
システム管理によってルーターアドバタイズメントを送信するように明示的に構成されていない限り、ノードが誤ってルーターとして動作を開始しないように、AdvSendAdvertisementsはデフォルトで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.
MinRtrAdvIntervalインターフェイスから非送信請求マルチキャストルーターアドバタイズメントを送信する間に許可される最小時間（秒単位）。 3秒以上.75 * MaxRtrAdvInterval以下でなければなりません。
Default: 0.33 * MaxRtrAdvInterval
デフォルト：0.33 * MaxRtrAdvInterval
AdvManagedFlag The TRUE/FALSE value to be placed in the "Managed address configuration" flag field in the Router Advertisement. See [ADDRCONF].
AdvManagedFlagルーターアドバタイズメントの "Managed address configuration"フラグフィールドに配置されるTRUE / FALSE値。 [ADDRCONF]を参照してください。
Default: FALSE
デフォルト：FALSE
AdvOtherConfigFlag The TRUE/FALSE value to be placed in the "Other stateful 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ルーターから送信されたルーターアドバタイズメッセージの到達可能時間フィールドに配置される値。値0は、（このルーターによって）指定されていないことを意味します。 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).
AdvRetransTimerルーターによって送信されたルーターアドバタイズメッセージのRetrans Timerフィールドに配置される値。値0は、（このルーターによって）指定されていないことを意味します。
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 that current diameter of the Internet. The value zero means unspecified (by this router).
AdvCurHopLimitルーターから送信されるルーターアドバタイズメッセージのCur Hop Limitフィールドに配置されるデフォルト値。値は、インターネットの現在の直径に設定する必要があります。値0は、（このルーターによって）指定されていないことを意味します。
Default: The value specified in the "Assigned Numbers" RFC [ASSIGNED] that was in effect at the time of implementation.
デフォルト：実装時に有効だった「割り当て番号」RFC [ASSIGNED]で指定された値。
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.
AdvDefaultLifetimeインターフェイスから送信されたルーターアドバタイズメントのルーターライフタイムフィールドに配置される値（秒単位）。ゼロ、またはMaxRtrAdvIntervalと9000秒の間でなければなりません。ゼロの値は、ルーターがデフォルトのルーターとして使用されないことを示します。
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.
デフォルト：ルータがルーティングプロトコルを介して、アドバタイズメントの送信元のインターフェイスのオンリンクとしてアドバタイズするすべてのプレフィックス。リンクローカルプレフィックスは、アドバタイズされたプレフィックスのリストに含まれるべきではありません（SHOULD NOT）。
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 MUST allow AdvValidLifetime to be specified in two ways:
AdvValidLifetime Prefix InformationオプションのValid Lifetimeに配置される値（秒単位）。すべて1の指定値（0xffffffff）は無限大を表します。実装では、AdvValidLifetimeを次の2つの方法で指定できるようにする必要があります。
- 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 Prefix Informationオプションのオンリンクフラグ（「Lビット」）フィールドに配置される値。
Default: TRUE
デフォルト：TRUE
Automatic address configuration [ADDRCONF] defines additional information associated with each 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 MUST allow AdvPreferredLifetime to be specified in two ways:
AdvPreferredLifetime Prefix InformationオプションのPreferred Lifetimeに配置される値（秒単位）。すべて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).
デフォルト：604800秒（7日）、固定（つまり、連続する広告で同じままです）。
AdvAutonomousFlag The value to be placed in the Autonomous Flag field in the Prefix Information option. See [ADDRCONF].
AdvAutonomousFlag Prefix InformationオプションのAutonomous Flagフィールドに配置される値。 [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、ReachableTimeなど）は、ルーターを含むすべてのノードに適用されます。実際には、これらの変数は実際にはルーターに存在しない可能性があります。これは、これらの変数の内容が上記の変数から導出できるためです。ただし、外部ルーターの動作は、これらの変数に関してホストの動作と同じである必要があります。特に、これには、セクション6.3.2で説明されているReachableTime値のランダムなランダム化が含まれます。
Protocol constants are defined in Section 10.
プロトコル定数はセクション10で定義されています。
The term "advertising interface" refers to any functioning and enabled multicast 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アドレスが割り当てられ、対応するAdvSendAdvertisementsフラグがTRUEである、機能している有効なマルチキャストインターフェイスを指します。ルーターは、ルーターアドバタイズメントを、アドバタイズインターフェイスではないインターフェイスから送信してはなりません（MUST NOT）。
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
- 有効なインターフェイスのAdvSendAdvertisementsフラグをFALSEからTRUEに変更する、または
- administratively enabling the interface, if it had been administratively disabled, and its AdvSendAdvertisements flag is TRUE, or
- インターフェイスが管理上無効になっていて、そのAdvSendAdvertisementsフラグがTRUEの場合、管理上有効になっている、または
- 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.
- インターフェイスのAdvSendAdvertisementsフラグが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.
- [ルーターライフタイム]フィールド：インターフェースの構成済みAdvDefaultLifetime。
- In the M and O flags: the interface's configured AdvManagedFlag and AdvOtherConfigFlag, respectively. See [ADDRCONF].
- MフラグとOフラグ：インターフェースの構成済みAdvManagedFlagおよびAdvOtherConfigFlag。 [ADDRCONF]を参照してください。
- 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.
- Retrans Timerフィールド：インターフェースの構成済みAdvRetransTimer。
- 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 Source Link-Layer Addressオプション：送信インターフェイスのリンク層アドレス。このオプションは、複製されたインターフェースでのインバウンドのロードバランシングを容易にするために省略される場合があります。
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.
- 「自律アドレス構成」フラグ：エントリのAdvAutonomousFlag。
- In the Preferred Lifetime field: the entry's AdvPreferredLifetime.
- [Preferred Lifetime]フィールド：エントリのAdvPreferredLifetime。
A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise prefixes for 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よりもはるかに長い場合、それらを含めるだけで十分です。ただし、ルーター要請に応答するとき、または最初の非請求アドバタイズメントを送信するときに、ルーターはすべてのオプションを含める必要があるため（SHOULD）、すべての情報（プレフィックスなど）がシステムの初期化中に迅速に伝達されます。
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.
非送信請求ルーターアドバタイズは厳密に定期的ではありません。後続の送信の間隔はランダム化され、同じリンク上の他のルーターからのアドバタイズと同期する可能性が低くなります[SYNC]。各広告インターフェイスには独自のタイマーがあります。マルチキャストアドバタイズメントがインターフェイスから送信されると、タイマーは、インターフェイスに設定された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_ADVERTISEMENTS）について、ランダムに選択された間隔が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_ADVERTISEMENTS未承認のアドバタイズに、インターフェースがアドバタイズインターフェースになる場合と同じルールを使用します。
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
- 有効なインターフェイスのAdvSendAdvertisementsフラグをTRUEから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 insure that subsequent Neighbor Advertisement messages sent from the interface have the Router flag set to zero.
このような場合、ルーターは、ルーターのライフタイムフィールドが0のインターフェイスで、1つ以上（ただしMAX_FINAL_RTR_ADVERTISEMENTS以下）の最終マルチキャストルーターアドバタイズメントを送信する必要があります（SHOULD）。ルーターがホストになる場合、システムは、ルーターがIPマルチキャストをサポートするすべてのインターフェース上のすべてルーター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_BETWEEN_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.
- ルーター要請を受信したら、0からMAX_RA_DELAY_TIMEの範囲内でランダムな遅延を計算します。計算された値が、次のマルチキャストルーターアドバタイズメントの送信がスケジュールされている時間より後の時間に対応する場合、ランダムな遅延を無視して、すでにスケジュールされた時間にアドバタイズメントを送信します。
- 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_BETWEEN_RAS秒以内にマルチキャストルーターアドバタイズ（送信請求または非送信請求）を送信した場合は、MIN_DELAY_BETWEEN_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, 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. 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.
送信元アドレスが指定されていないアドレスであるルーター要請は、ルーターの近隣キャッシュを更新してはなりません（MUST NOT）。適切な送信元アドレスによる要請は、ネイバーキャッシュを次のように更新します。ルーターに要請の送信者の近隣キャッシュエントリが既にあり、要請に送信元リンク層アドレスオプションが含まれていて、受信したリンク層アドレスがすでにキャッシュにあるアドレスと異なる場合、リンク層アドレスを更新する必要があります（SHOULD）。適切なネイバーキャッシュエントリ、およびその到達可能性の状態もSTALEに設定する必要があります。要請の送信者に既存の近隣キャッシュエントリがない場合、ルーターはエントリを作成し、リンク層アドレスをインストールして、セクション7.3.3で指定されているように到達可能性の状態をSTALEに設定します。送信元リンク層アドレスオプションが提供されているかどうかにかかわらず、要請の送信者の近隣キャッシュエントリが存在する（または作成されている）場合、エントリの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:
ルーターは、他のルーターから送信された有効なルーターアドバタイズを検査して、ルーターがリンク上で一貫した情報をアドバタイズしていることを確認する必要があります（SHOULD）。検出された不整合は、1つ以上のルーターが正しく構成されていない可能性があり、システムまたはネットワーク管理にログ記録する必要があることを示しています。確認する最低限の情報には、次のものが含まれます。
- Cur Hop Limit values (except for the unspecified value of zero).
- Cur Hop Limit値（0の未指定の値を除く）。
- 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.7 then the comparison of the lifetimes can not 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.7で指定されているようにAdvPreferredLifetimeや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.
異なるルータが異なるプレフィックスのセットをアドバタイズすることはエラーではないことに注意してください。また、一部のルーターは一部のフィールドを未指定のままにする、つまり値をゼロにする場合がありますが、他のルーターは値を指定します。エラーのロギングは、ホストが受信したアドバタイズメントごとに1つの値から別の値に切り替える原因となる競合する情報に制限する必要があります（SHOULD）。
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 change rarely, 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.
ルーターのリンクローカルアドレスは、変更されることはほとんどありません。近隣探索メッセージを受信するノードは、送信元アドレスを使用して送信者を識別します。同じルーターからの複数のパケットに異なる送信元アドレスが含まれている場合、ノードは異なるルーターからのパケットであると想定し、望ましくない動作を引き起こします。たとえば、ノードは、現在の最初のホップのルーター以外のルーターによって送信されたと考えられるリダイレクトメッセージを無視します。したがって、特定のルーターによって送信されるルーターアドバタイズメントで使用されるソースアドレスは、そのルーターにリダイレクトするときのリダイレクトメッセージのターゲットアドレスと同一である必要があります。
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つのリンクローカルアドレスを変更する場合、この変更をホストに通知する必要があります（SHOULD）。ルーターは、ルーターライフタイムフィールドがゼロに設定された古いリンクローカルアドレスからいくつかのルーターアドバタイズをマルチキャストし、新しいリンクローカルアドレスからいくつかのルーターアドバタイズをマルチキャストする必要があります。全体的な効果は、あるインターフェースが広告インターフェースでなくなり、別のインターフェースが広告インターフェースである場合と同じです。
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 (unicast) IP packets.
CurHopLimit（ユニキャスト）IPパケットを送信するときに使用されるデフォルトのホップ制限。
Default: The value specified in the "Assigned Numbers" RFC [ASSIGNED] that was in effect at the time of implementation.
デフォルト：実装時に有効だった「割り当て番号」RFC [ASSIGNED]で指定された値。
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.
ReachableTime到達可能性の確認を受け取った後、ネイバーが到達可能と見なされる時間。
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にBaseReachableTimeミリ秒を掛けた値の間で均一に分散されたランダムな値である必要があります。新しいランダム値は、BaseReachableTimeが変更されたとき（ルーターアドバタイズにより）、またはルーターアドバタイズが受信されない場合でも少なくとも数時間ごとに計算する必要があります。
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, such as stateful autoconfiguration. 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.
複数のルーターが存在する場合、すべてのルーターによってまとめてアドバタイズされる情報は、単一のルーターアドバタイズメントに含まれる情報のスーパーセットになる場合があります。さらに、ステートフル自動構成などの他の動的な手段を通じて情報を取得することもできます。ホストは、受信したすべての情報の結合を受け入れます。ルーター通知の受信は、以前の通知で、または別のソースから受信したすべての情報を無効にしてはなりません。ただし、特定のパラメーター（リンクMTUなど）またはオプション（特定のプレフィックスの存続時間など）の受信情報が以前に受信した情報と異なり、パラメーター/オプションが持つことができる値は1つだけである場合、最新の受信情報は権威があると見なされます。
Some Router Advertisement fields (e.g., Cur Hop Limit, Reachable Time and Retrans Timer) may contain a value denoting 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.
一部のルーター通知フィールド（Cur Hop Limit、Reachable Time、Retrans Timerなど）には、未指定を示す値が含まれる場合があります。このような場合、パラメーターは無視する必要があり、ホストは既に使用している値を引き続き使用する必要があります。特に、ホストは、指定されていない値を、最初のルーターアドバタイズメントを受信する前に使用されていたデフォルト値に戻す変更として解釈してはなりません（MUST NOT）。このルールは、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.
- ホストのデフォルトルーターリストにアドレスがまだ存在せず、アドバタイズのルーターライフタイムがゼロ以外の場合は、リストに新しいエントリを作成し、アドバタイズのルーターライフタイムフィールドから無効化タイマー値を初期化します。
- 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).
デフォルトルーターリストに必要なストレージを制限するために、ホストは、アドバタイズで検出されたすべてのルーターアドレスを保存しないことを選択できます（MAY）。ただし、ホストは少なくとも2つのルーターアドレスを保持する必要があり、それ以上保持する必要があります（SHOULD）。宛先への通信が失敗しているように見える場合は常に、デフォルトのルーターが選択されます。したがって、リストに含まれるルーターが多いほど、（たとえば、次のアドバタイズメントが到着するのを待たずに）代替の動作中のルーターをすばやく見つけることができます。
If the received Cur Hop Limit value is non-zero the host SHOULD set its CurHopLimit variable to the received value.
受信したCur Hop Limit値がゼロ以外の場合、ホストはそのCurHopLimit変数を受信した値に設定する必要があります（SHOULD）。
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 recompute 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 Neighbor Unreachability Detection messages synchronize with each other.
受信した到達可能時間の値がゼロ以外の場合、ホストはそのBaseReachableTime変数を受信した値に設定する必要があります（SHOULD）。新しい値が以前の値と異なる場合、ホストは新しいランダムなReachableTime値を再計算する必要があります（SHOULD）。 ReachableTimeは、MIN_RANDOM_FACTORとMAX_RANDOM_FACTORとBaseReachableTimeの積の間で均一に分布するランダムな値として計算されます。ランダムなコンポーネントを使用すると、近隣到達不能検出メッセージが互いに同期する可能性がなくなります。
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 insure that a new random value gets recomputed 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フィールドからコピーする必要があります（SHOULD）。
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フラグは、Neighbor Unreachability Detectionによって使用され、ルーターがホストになる（つまり、パケットを転送できなくなる）ときを決定します。ルーターの近隣キャッシュエントリが作成された場合、到達可能性の状態は、セクション7.3.3で指定されているSTALEに設定する必要があります。キャッシュエントリがすでに存在し、別のリンク層アドレスで更新されている場合、到達可能性の状態もSTALEに設定する必要があります。
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 default LinkMTU value specified in the link type specific document (e.g., [IPv6-ETHER]).
MTUオプションが存在する場合、値が最小リンクMTU [IPv6]以上であり、リンクタイプ固有のドキュメントで指定されているデフォルトのLinkMTU値を超えない限り、ホストはオプションの値をLinkMTUにコピーする必要があります（例： 、[IPv6-ETHER]）。
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を参照）は、パケットをデフォルトのルーターに転送することです。 「on-link」（L）フラグがゼロに設定されたPrefix Informationオプションを受信しても、この動作は変わりません。アドレスがオンリンクとして扱われる理由は、セクション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.
- プレフィックスがリンクローカルプレフィックスである場合、サイレントに[プレフィックス情報]オプションを無視します。
- 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.
- プレフィックスがプレフィックスリストにまだ存在せず、プレフィックス情報オプションの[有効期間]フィールドがゼロ以外の場合は、プレフィックスの新しいエントリを作成し、その無効化タイマーを[プレフィックス情報]オプションの有効期間値に初期化します。
- 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.
- Prefix InformationオプションのValid Lifetimeフィールドがゼロであり、ホストのPrefix Listにプレフィックスが存在しない場合は、黙ってオプションを無視してください。
Stateless address autoconfiguration [ADDRCONF] may in some circumstances increase the 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.
ステートレスアドレス自動構成[ADDRCONF]は、特定のサービス拒否攻撃を防ぐために、状況によってはプレフィックスの有効期間を長くしたり、完全に無視したりする場合があります。ただし、オンリンクプレフィックスリストを対象とする同じサービス拒否の影響は壊滅的ではないため（ホストはパケットをネイバーに直接送信するのではなく、デフォルトルーターに送信してリダイレクトを受信します）、ネイバー探索プロトコルはプレフィックスのライフタイム値にそのようなチェックを課します。
Note: Implementations can choose to process the on-link aspects of the prefixes separately from the 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.
注：実装では、プレフィックスのアドレス自動構成の側面とは別に、プレフィックスのオンリンクの側面を処理することを選択できます。たとえば、有効な各ルーター通知メッセージのコピーを「オンリンク」と「addrconf」の両方に渡すことで関数。各関数は、適切なフラグが設定されているプレフィックスに対して独立して動作できます。
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). An implementation may choose to always return the same router or cycle through the router list in a round-robin fashion as long as it always returns a reachable or a probably reachable router when one is available.
1）到達可能またはおそらく到達可能な（つまり、INCOMPLETE以外の状態にある）ルーターは、到達可能性が不明または疑わしい（つまり、INCOMPLETE状態にある、または近隣キャッシュエントリが存在しない）ルーターよりも優先する必要があります。実装では、常に到達可能なルーターまたは到達可能な可能性のあるルーターが使用可能な場合に常に返される限り、常に同じルーターを返すか、ルーターリストをラウンドロビン方式で循環することを選択できます。
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.
この場合、ルーターリストを循環することで、利用可能なすべてのルーターが近隣到達不能検出アルゴリズムによってアクティブにプローブされることが保証されます。デフォルトルーターの要求は、ルーターへのパケットの送信と組み合わせて行われ、選択されたルーターは、副作用として到達可能性についてプローブされます。
3) If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2.
3）デフォルトルータリストが空の場合、セクション5.2で指定されているように、すべての宛先がリンク上にあると想定します。
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_SOLICITATIONS個のルーター要請メッセージをそれぞれRTR_SOLICITATION_INTERVAL秒以上離して送信する必要があります（SHOULD）。ルーター要請は、次のいずれかのイベントの後に送信されます。
- 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送信元アドレスが指定されていないアドレスでない場合は、送信元リンク層アドレスオプションをホストのリンク層アドレスに設定する必要があります（SHOULD）。
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_SOLICITATION_DELAYの間のランダムな時間だけ遅延させる必要があります（SHOULD）。これは、停電からの復旧後に発生する可能性があるなど、多くのホストがリンク上で同時に起動するときの輻輳を緩和するのに役立ちます。インターフェースが（再）有効になってから（例えば、重複アドレス検出[ADDRCONF]の一部として）ホストがすでにランダムな遅延を実行している場合、最初のルーター要請メッセージを送信する前に再度遅延する必要はありません。
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. Unsolicited Router Advertisements may be incomplete (see Section 6.2.3); solicited advertisements are expected to contain complete information.
ホストがルーター要請を送信し、ゼロ以外のルーターライフタイムを持つ有効なルーターアドバタイズメントを受信すると、ホストは、上記のイベントのいずれかが次に発生するまで、そのインターフェイスで追加の要請を送信しないようにする必要があります。さらに、ホストは、勧誘を送信する前に広告が受信された場合、少なくとも1つの要請を送信する必要があります（SHOULD）。非送信請求ルーター通知は不完全な場合があります（セクション6.2.3を参照）。要請された広告には、完全な情報が含まれている必要があります。
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_SOLICITATIONS要請を送信し、最後の要請を送信してからMAX_RTR_SOLICITATION_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です。つまり、パケットがルーターによって転送されていない可能性があります。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- メッセージにIP認証ヘッダーが含まれている場合、メッセージは正しく認証されます。
- 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.
Reservedフィールドの内容、および認識されないオプションの内容は無視する必要があります。プロトコルに対する将来の下位互換性のある変更により、Reservedフィールドの内容が指定されるか、新しいオプションが追加される可能性があります。下位互換性のない変更では、異なるコード値を使用する場合があります。
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です。つまり、パケットがルーターによって転送されていない可能性があります。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- メッセージにIP認証ヘッダーが含まれている場合、メッセージは正しく認証されます。
- 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.
Reservedフィールドの内容、および認識されないオプションの内容は無視する必要があります。プロトコルに対する将来の下位互換性のある変更により、Reservedフィールドの内容が指定されるか、新しいオプションが追加される可能性があります。下位互換性のない変更では、異なるコード値を使用する場合があります。
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.
ネイバーアドバタイズメントメッセージで使用するように指定されていない定義済みオプションの内容は無視する必要があり、パケットは通常どおりに処理されます。表示される可能性のある定義済みのオプションは、Target Link-Layer Addressオプションだけです。
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. Address resolution is never performed on multicast addresses.
アドレス解決は、ノードがIPアドレスのみを与えられたネイバーのリンク層アドレスを決定するプロセスです。アドレス解決は、リンク上であると判断され、送信者が対応するリンク層アドレスを知らないアドレスに対してのみ実行されます。マルチキャストアドレスに対してアドレス解決が実行されることはありません。
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. 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]。そのような場合、ノードは参加し、新しいアドレスと古いアドレスにそれぞれ対応する要請ノードマルチキャストアドレスを残さなければなりません。複数のユニキャストアドレスが同じ送信請求ノードマルチキャストアドレスにマップされる場合があることに注意してください。ノードは、そのマルチキャストアドレスに対応する割り当てられたアドレスがすべて削除されるまで、要請ノードマルチキャストグループを離れてはなりません（MUST NOT）。
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.
ノードがネイバーに送信するユニキャストパケットを持っているが、ネイバーのリンク層アドレスがわからない場合、ノードはアドレス解決を実行します。マルチキャスト対応のインターフェースの場合、これはINCOMPLETE状態でネイバーキャッシュエントリを作成し、ネイバーをターゲットとするネイバー要請メッセージを送信することを伴います。要請は、ターゲットアドレスに対応する要請ノードマルチキャストアドレスに送信されます。
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 insures 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送信元アドレスに配置する必要があります（SHOULD）。それ以外の場合は、インターフェイスに割り当てられたアドレスのいずれかを使用する必要があります。可能な場合にプロンプトパケットの送信元アドレスを使用すると、近隣要請の受信者が近隣キャッシュに、プロンプトパケットの「接続」に属する後続のリターントラフィックで使用される可能性が高い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.
要請が要請ノードマルチキャストアドレスに送信されている場合、送信者はそのリンク層アドレス（ある場合）をソースリンク層アドレスオプションとして含める必要があります。それ以外の場合、送信者は、リンク層アドレス（ある場合）をソースリンク層アドレスオプションとして含める必要があります（SHOULD）。送信元リンク層アドレスをマルチキャスト送信請求に含めることは、ターゲットに近隣アドバタイズメントを送信できるアドレスを与えるために必要です。ユニキャスト要請では、実装はソースリンク層アドレスオプションを省略してもよいです。ここでの前提は、送信者がピアのリンク層アドレスをキャッシュに持っている場合、ピアがキャッシュにも送信者のエントリを持っている可能性が高いということです。したがって、送信する必要はありません。
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つのパケットを保持する必要があり、さらにそれを含めることができます（MAY）。ただし、ネイバーごとのキューに入れられたパケットの数は、いくつかの小さな値に制限する必要があります。キューがオーバーフローすると、新しい到着が最も古いエントリを置き換える必要があります（SHOULD）。アドレス解決が完了すると、ノードはキューに入れられたパケットを送信します。
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ミリ秒ごとに近隣要請メッセージを再送信する必要があります（SHOULD）。再送信は、RetransTimerミリ秒ごとにネイバーごとに最大で1つの請求にレート制限する必要があります。
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_SOLICIT要請の後にネイバーアドバタイズが受信されない場合、アドレス解決は失敗しています。送信者は、アドレス解決を待っているキューに入れられた各パケットに対して、コード3（アドレス到達不能）でICMP宛先到達不能通知を返さなければなりません（MUST）。
A valid Neighbor Solicitation that does not meet any 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 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送信元アドレスの近隣キャッシュエントリを作成または更新する必要があります（SHOULD）。エントリがまだ存在しない場合、ノードは新しいエントリを作成して、セクション7.3.3で指定されているように到達可能性の状態をSTALEに設定する必要があります（SHOULD）。エントリがすでに存在し、キャッシュされたリンク層アドレスが受信したソースリンク層オプションのアドレスと異なる場合は、キャッシュされたアドレスを受信したアドレスで置き換え、エントリの到達可能性状態をSTALEに設定する必要があります。
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に設定する必要があります（SHOULD）。これは、近隣要請メッセージに送信者がルーターであるかどうかの指示が含まれていないため、近隣要請がルーターによって送信された場合でも当てはまります。送信者がルーターである場合、後続のネイバーアドバタイズメントメッセージまたはルーターアドバタイズメントメッセージは正しいIsRouter値を設定します。隣接キャッシュエントリがすでに存在する場合、そのIsRouterフラグを変更してはなりません。
If the Source Address is the unspecified address the node MUST NOT create or update the Neighbor Cache entry.
送信元アドレスが未指定のアドレスである場合、ノードは近隣キャッシュエントリを作成または更新してはなりません（MUST NOT）。
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".
ターゲットアドレスが、ノードがプロキシサービスを提供しているエニーキャストアドレスまたはユニキャストアドレスであるか、ターゲットリンク層アドレスオプションが含まれていない場合、オーバーライドフラグはゼロに設定する必要があります（SHOULD）。それ以外の場合は、オーバーライドフラグを1に設定する必要があります（SHOULD）。 Overrideフラグを適切に設定すると、プロキシアドバタイズメントの後で受信された場合でも、ノードが非プロキシアドバタイズメントを優先し、エニーキャストアドレスの最初のアドバタイズメントが「勝つ」ことを保証します。
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.
ターゲットアドレスがエニーキャストアドレスの場合、送信者は、0〜MAX_ANYCAST_DELAY_TIME秒のランダムな時間、応答の送信を遅延させる必要があります（SHOULD）。
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.
有効なネイバーアドバタイズが受信されると（要請または非要請）、ネイバーキャッシュでターゲットのエントリが検索されます。エントリが存在しない場合、通知は通知なく破棄されるべきです（SHOULD）。受信者は明らかにターゲットとの通信を開始していないため、存在しない場合はエントリを作成する必要はありません。
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:
アドバタイズを受信したときにターゲットのネイバーキャッシュエントリがINCOMPLETE状態にある場合、次の2つのいずれかが起こります。リンク層にアドレスがあり、ターゲットリンク層アドレスオプションが含まれていない場合、受信ノードは受信したアドバタイズメントをサイレントに破棄する必要があります（SHOULD）。それ以外の場合、受信ノードは次の手順を実行します。
- It records the link-layer address in the Neighbor Cache entry.
- リンク層アドレスをNeighbor Cacheエントリに記録します。
- If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE.
- 広告の要請フラグが設定されている場合、エントリの状態はREACHABLEに設定され、それ以外の場合はSTALEに設定されます。
- It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement.
- 受信したアドバタイズメントのルーターフラグに基づいて、キャッシュエントリにIsRouterフラグを設定します。
- 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.
エントリがINCOMPLETE状態の場合、Overrideフラグは無視されることに注意してください。
If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, processing becomes quite a bit more complex. 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: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; otherwise, the received advertisement should be ignored and MUST NOT update the cache. If the Override flag is set, both the Override flag is clear and 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:
アドバタイズを受信したときにターゲットのネイバーキャッシュエントリがINCOMPLETE以外の状態にある場合、処理はかなり複雑になります。オーバーライドフラグがクリアされ、指定されたリンク層アドレスがキャッシュ内のアドレスと異なる場合、2つのアクションのいずれかが行われます。エントリの状態がREACHABLEの場合、それをSTALEに設定しますが、どのエントリも更新しません。他の方法;それ以外の場合、受信したアドバタイズメントは無視する必要があり、キャッシュを更新してはなりません。オーバーライドフラグが設定されている場合、オーバーライドフラグがクリアされており、指定されたリンク層アドレスがキャッシュ内のアドレスと同じであるか、ターゲットリンク層アドレスオプションが指定されていない場合、受信したアドバタイズメントは近隣キャッシュエントリを次のように更新する必要があります。続く：
- The link-layer address in the Target Link-Layer Address option MUST be inserted in the cache (if one is supplied and is different than 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.
- Solicitedフラグが設定されている場合は、エントリの状態をREACHABLEに設定する必要があります。要請フラグがゼロで、リンク層アドレスが別のアドレスで更新された場合、状態をSTALEに設定する必要があります。それ以外の場合、エントリの状態は変更されません。
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, suggests 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.
場合によっては、ノードはリンク層アドレスが変更された（たとえば、インターフェースカードのホットスワップ）と判断でき、新しいリンク層アドレスを近隣にすぐに通知したい場合があります。このような場合、ノードは最大MAX_NEIGHBOR_ADVERTISEMENT非送信請求ネイバーアドバタイズメントメッセージをすべてのノードのマルチキャストアドレスに送信できます（MAY）。これらの広告は、少なくとも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に設定する必要があります。それ以外の場合は、ゼロに設定する必要があります。オーバーライドフラグは、ゼロまたは1に設定できます。どちらの場合でも、隣接ノードは、ターゲットアドレスの隣接キャッシュエントリの状態をすぐにSTALEに変更し、到達可能性のパスを確認するように要求します。オーバーライドフラグが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アドレスを持つノードは、アドレスごとに個別の近隣アドバタイズをマルチキャストしてもよい（MAY）。そのような場合、ノードは、各広告の送信の間に小さな遅延を導入して、輻輳が原因で広告が失われる可能性を減らす必要があります。
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.
プロキシは、リンク層アドレスが変更されたとき、またはアドレスをプロキシするように（システム管理またはその他のメカニズムによって）構成されたときに、近隣アドバタイズをマルチキャストする場合があります。同じアドレスセットにプロキシサービスを提供しているノードが複数ある場合、プロキシは、過剰なマルチキャストトラフィックのリスクを減らすために、複数のプロキシが1つのアドレスのアドバタイズをマルチキャストすることを防ぐメカニズムを提供する必要があります（SHOULD）。
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の間のランダムな時間だけ遅延する必要があります（SHOULD）。 2つ目は、近隣アドバタイズのオーバーライドフラグを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 identical to 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.
プロキシは、プロキシの対象であるノードに割り当てられたIPアドレスに対応する送信請求ノードマルチキャストアドレスに参加する必要があります。
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で指定されているように、Overrideフラグを1に設定して非送信請求アドバタイズメントを送信できますが、そうすると、ノード自体が作成した有効なエントリをプロキシアドバタイズメントが上書きする可能性があります。
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.
最後に、近隣要請への応答としてプロキシアドバタイズメントを送信する場合、送信者はその応答を0〜MAX_ANYCAST_DELAY_TIME秒のランダムな時間だけ遅延させる必要があります。
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は、Neighbor Cacheエントリを削除することにより、ネクストホップを決定する必要があることを知らせます。
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) acknowledgement indicates that previously sent data reached the peer. Likewise, the arrival of new (non-duplicate) data indicates that earlier acknowledgements 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 confirm 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 the 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.
要請されたネイバーアドバタイズメントの受信は、要請フラグが1に設定されたアドバタイズメントがネイバー要請に応答してのみ送信されるため、到達可能性の確認として機能します。ルーターアドバタイズメントや、要請されたフラグがゼロに設定されたネイバーアドバタイズメントなど、他の近隣探索メッセージの受信は、到達可能性の確認として扱われてはなりません。非送信請求メッセージの受信は、送信者から受信者ノードへの片方向パスのみを確認します。対照的に、ネイバー到達不能検出では、ノードが、ネイバーの視点からではなく、その視点からネイバーへの転送パスの到達可能性を追跡する必要があります。要請された広告の受信は、パスが両方向で機能していることを示していることに注意してください。要請はネイバーに到達し、アドバタイズメントを生成するよう促している必要があります。同様に、広告の受信は、送信者から受信者へのパスが機能していることを示します。ただし、後者の事実は受信者しか知りません。広告の送信者は、送信した広告が実際にネイバーに到達したことを直接知る方法がありません。ネイバー到達不能検出の観点からは、フォワードパスの到達可能性のみが重要です。
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.
INCOMPLETEアドレス解決がエントリで実行されています。具体的には、近隣要請がターゲットの送信請求ノードのマルチキャストアドレスに送信されましたが、対応する近隣アドバタイズはまだ受信されていません。
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.
REACHABLEネイバーへのフォワードパスが適切に機能していたことを、最後のReachableTimeミリ秒以内に確認しました。到達可能である間、パケットが送信されるときに特別なアクションは行われません。
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.
STALE転送パスが適切に機能していたという最後の肯定的な確認が受信されてからReachableTimeミリ秒以上経過しました。古くなっている間、パケットが送信されるまでアクションは発生しません。
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 insures reachability is verified quickly if the entry is actually being used. However, reachability is not actually verified until the entry is actually used.
キャッシュされたリンク層アドレスを更新する非送信請求ネイバー探索メッセージを受信すると、STALE状態になります。このようなメッセージを受信しても到達可能性は確認されず、STALE状態に入ると、エントリが実際に使用されている場合に到達可能性が迅速に検証されます。ただし、エントリが実際に使用されるまで、到達可能性は実際には検証されません。
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.
DELAY転送パスが適切に機能しているという最後の肯定的な確認が受信されてからReachableTimeミリ秒以上経過し、最後のDELAY_FIRST_PROBE_TIME秒以内にパケットが送信されました。 DELAY状態に入ってからDELAY_FIRST_PROBE_TIME秒以内に到達可能性の確認が受信されない場合は、近隣要請を送信し、状態をPROBEに変更します。
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.
DELAY状態は、最近のトラフィックの不足が原因で最後の確認からReachableTimeミリ秒が経過した場合に、上位層プロトコルに到達可能性の確認を提供する追加の時間を与える最適化です。この最適化を行わないと、後続の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 insures that alternate default routers are tried.
ノードが隣接アドレスでアドレス解決を実行する必要がある場合、ノードはINCOMPLETE状態のエントリを作成し、セクション7.2で指定されているようにアドレス解決を開始します。アドレス解決が失敗した場合は、エントリを削除する必要があります（SHOULD）。そのネイバーへの後続のトラフィックは、ネクストホップ決定手順を再度呼び出すためです。この時点でネクストホップ決定を呼び出すと、代替のデフォルトルーターが確実に試行されます。
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).
到達可能性の確認が受信されると（上位層のアドバイスまたは要請されたネイバーアドバタイズを通じて）、エントリの状態がREACHABLEに変わります。 1つの例外は、上位層のアドバイスがINCOMPLETE状態のエントリに影響しないことです（たとえば、リンク層アドレスがキャッシュされていない場合）。
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.
ネイバーの最後の到達可能性の確認を受信してからReachableTimeミリ秒が経過すると、ネイバーキャッシュエントリの状態がREACHABLEから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.
注：実装は実際に、パケットがネイバーに送信されるまで、状態の変更をREACHABLEからSTALEに延期する場合があります。
The first time a node sends a packet to a neighbor whose entry is STALE, the sender changes the state to DELAY and a 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.
エントリがSTALEであるネイバーにノードが初めてパケットを送信すると、送信者は状態をDELAYに変更し、タイマーがDELAY_FIRST_PROBE_TIME秒で期限切れになるように設定します。タイマーの期限が切れたときにエントリーがまだDELAY状態にある場合、エントリーの状態はPROBEに変わります。到達可能性の確認が受信されると、エントリの状態はREACHABLEに変わります。
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 performs address resolution again.
プローブ状態に入ると、ノードは、キャッシュされたリンク層アドレスを使用して、ユニキャスト近隣要請メッセージをネイバーに送信します。プローブ状態にある間、ノードは到達可能性の確認が取得されるまで、RetransTimerミリ秒ごとに近隣要請メッセージを再送信します。追加のパケットがネイバーに送信されない場合でも、プローブは再送信されます。 MAX_UNICAST_SOLICIT送信請求を送信してからRetransTimerミリ秒待機しても応答がない場合、再送信は中止され、エントリを削除する必要があります（SHOULD）。そのネイバーへの後続のトラフィックはエントリを再作成し、アドレス解決を再度実行します。
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ミリ秒ごとに1回よりも頻繁に同じ要請に近隣要請を送信してはなりません（MUST NOT）。
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.
近隣キャッシュエントリは、要請された近隣アドバタイズメント以外のパケット（つまり、ルーター要請、ルーターアドバタイズメント、リダイレクト、近隣要請）を受信した結果として作成されると、STALE状態になります。これらのパケットには、送信者、またはリダイレクトの場合はリダイレクトターゲットのリンク層アドレスが含まれています。ただし、これらのリンク層アドレスを受信しても、そのノードへの順方向パスの到達可能性は確認されません。リンク層アドレスが既知である新しく作成されたネイバーキャッシュエントリをSTALE状態に配置すると、パス障害が迅速に検出されます。さらに、上記のメッセージのいずれかを受信したためにキャッシュされたリンク層アドレスが変更された場合、状態もSTALEに設定して、新しいリンク層アドレスへのパスが機能していることを迅速に確認する必要があります。
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転送機能がオフになっている場合）、ノードは受信したすべての近隣アドバタイズメッセージのルーターフラグフィールドを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.
場合によっては、リンク固有の情報は、ネイバーへのパスが失敗したことを示す場合があります（たとえば、仮想回路のリセット）。このような場合、ネイバー到達不能検出が実行する前に、リンク固有の情報を使用してネイバーキャッシュエントリを削除できます。ただし、リンク固有の情報は、ネイバーの到達可能性を確認するために使用してはなりません（MUST NOT）。このような情報は、隣接する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.
ルーターは、リダイレクトメッセージ内のターゲットアドレスがリンクローカルアドレスによって隣接ルーターを確実に識別できるようにするために、隣接ルーターそれぞれのリンクローカルアドレスを特定できなければなりません（MUST）。静的ルーティングの場合、この要件は、ネクストホップルーターのアドレスをルーターのリンクローカルアドレスを使用して指定する必要があることを意味します。動的ルーティングの場合、この要件は、すべての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です。つまり、パケットがルーターによって転送されていない可能性があります。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- メッセージにIP認証ヘッダーが含まれている場合、メッセージは正しく認証されます。
- 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.
Reservedフィールドの内容、および認識されないオプションの内容は無視する必要があります。プロトコルに対する将来の下位互換性のある変更により、Reservedフィールドの内容が指定されるか、新しいオプションが追加される可能性があります。下位互換性のない変更では、異なるコード値を使用する場合があります。
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つでカバーされていないため、ホストはリダイレクトを無効と見なしてはなりません（MUST NOT）。リダイレクトメッセージのセマンティクスの一部は、ターゲットアドレスがオンリンクであることです。
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 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, and
- パケットの宛先アドレスがマルチキャストアドレスではない。
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 1280 octets in size.
o リダイレクトされたヘッダー：転送パケットのサイズが1280オクテットを超えるリダイレクトパケットなしで収まるだけの量。
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.
ルーターは、リダイレクトの受信時にルーティングテーブルを更新してはなりません（MUST NOT）。
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.
有効なリダイレクトを受信するホストは、後続のトラフィックが指定されたターゲットに送信されるように、それに応じて宛先キャッシュを更新する必要があります（SHOULD）。宛先に宛先キャッシュエントリが存在しない場合、実装はそのようなエントリを作成する必要があります（SHOULD）。
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で指定されているように、その到達可能性の状態をSTALEに設定する必要があります。キャッシュエントリが既に存在し、別のリンク層アドレスで更新されている場合、その到達可能性の状態もSTALEに設定する必要があります。リンク層アドレスがすでにキャッシュにあるアドレスと同じである場合、キャッシュエントリの状態は変更されません。
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 MAY have a configuration switch that can be set to make it ignore a Redirect message that does not have an IP Authentication header.
ホストは、IP認証ヘッダーを持たないリダイレクトメッセージを無視するように設定できる構成スイッチを持つ場合があります。
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メッセージに認識されないオプションが含まれているからといって、ノードは有効なオプションを無視してはなりません（MUST NOT）。
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.
オプションは、他のオプションの有無に依存してはなりません（MUST NOT）。オプションのセマンティクスは、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）送信者は、オプションのサブセットを異なるパケットで送信できます。たとえば、プレフィックスの有効期間と優先期間が十分に長い場合、すべてのルーターアドバタイズメントにプレフィックス情報オプションを含める必要がない場合があります。さらに、ルーターごとに異なるオプションのセットが送信される場合があります。したがって、受信者は、特定のパケットにオプションがないことをアクションに関連付けてはなりません（MUST NOT）。このプロトコルは、レシーバーがタイマーの期限切れとパケットで受信された情報にのみ作用するように指定しています。
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 1280 octets.
Redirected Headerオプションに含めるデータの量は、リダイレクトパケット全体が1280オクテットを超えないように制限する必要があります。
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ビットの境界に整列されます）。 / prefixes。これは、64ビット境界で整列されます。リンク層アドレスフィールドには、未解釈のオクテット文字列が含まれています。これは、8ビット境界に配置されます。
The size of an ND packet including the IP header is limited to the link MTU (which is at least 1280 octets). When adding options to an ND packet a node MUST NOT exceed the link MTU.
IPヘッダーを含むNDパケットのサイズは、リンクMTU（少なくとも1280オクテット）に制限されます。 NDパケットにオプションを追加する場合、ノードはリンクMTUを超えてはなりません（MUST NOT）。
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_ADVERTISEMENTS 3回の送信
MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions
MAX_FINAL_RTR_ADVERTISEMENTS 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_SOLICITATION_DELAY 1秒
RTR_SOLICITATION_INTERVAL 4 seconds
RTR_SOLICITATION_INTERVAL 4秒
MAX_RTR_SOLICITATIONS 3 transmissions
MAX_RTR_SOLICITATIONS 3回の送信
Node constants:
ノード定数：
MAX_MULTICAST_SOLICIT 3 transmissions
MAX_MULTICAST_SOLICIT 3送信
MAX_UNICAST_SOLICIT 3 transmissions
MAX_UNICAST_SOLICIT 3回の送信
MAX_ANYCAST_DELAY_TIME 1 second
MAX_ANYCAST_DELAY_TIME 1秒
MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions
MAX_NEIGHBOR_ADVERTISEMENT 3送信
REACHABLE_TIME 30,000 milliseconds
REACHABLE_TIME 30,000ミリ秒
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.
近隣探索は攻撃の対象となり、IPパケットが予期しない場所に流れます。このような攻撃は、サービス拒否を引き起こすために使用できますが、ノードが傍受し、オプションで他のノード宛のパケットを変更することもできます。
The protocol reduces the exposure to such 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のホップ制限を含む受信パケットはネイバーから発信されたものでなければなりません。
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 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つずつ複数のルーターアドバタイズメントを送信することでこれを実現できます。接頭辞。このような攻撃により、オンリンクとオフリンクの両方の宛先のすべてのパケットが不正なルーターに送信されます。そのルーターは、リンク上で送信されたすべてのパケットを選択的に検査、変更、またはドロップできます。不正ルーターがRビットが設定されたネイバーアドバタイズでNUDプローブに丁寧に応答する限り、ネイバー到達不能検出はこのようなブラックホールを検出しません。
Many link layers are also subject to different denial of service attacks such as continuously occupying the link in CSMA/CD 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.
多くのリンクレイヤーは、CSMA / CDネットワークでリンクを継続的に占有するなどのさまざまなサービス拒否攻撃にもさらされています（たとえば、パケットを密接に連続して送信するか、リンク上で衝突信号をアサートする）、または誰かとパケットを発信するイーサネットスイッチなど、混乱させる他の送信元MACアドレス。
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. It is natural to trust the routers on the link. 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; 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.
プロトコルには、特定のタイプのメッセージ（ルーターアドバタイズメントなど）を送信することを許可されているネイバーを決定するメカニズムは含まれていません。おそらく認証がある場合でも、ネイバーはルーターアドバタイズメッセージを送信できるため、サービス拒否を引き起こす可能性があります。さらに、すべてのネイバーは、潜在的なサービス拒否攻撃として、プロキシネイバーアドバタイズメントと非送信請求ネイバーアドバタイズメントを送信できます。
Neighbor Discovery protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an Authentication Header when sending Neighbor Discovery packets if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol.
近隣探索プロトコルのパケット交換は、IP認証ヘッダー[IPv6-AUTH]を使用して認証できます。宛先アドレスにIP認証ヘッダーで使用するセキュリティアソシエーションが存在する場合、ノードは近隣探索パケットを送信するときに認証ヘッダーを含める必要があります（SHOULD）。セキュリティアソシエーションは、手動構成またはいくつかのキー管理プロトコルの操作によって作成された可能性があります。
Received Authentication Headers in Neighbor Discovery packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored.
近隣探索パケットで受信した認証ヘッダーは、正しいことを確認する必要があり、不正な認証のパケットは無視する必要があります。
It SHOULD be possible for the system administrator to configure a node to ignore any Neighbor Discovery messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. The configuration technique for this MUST be documented. Such a switch SHOULD default to allowing unauthenticated messages.
システム管理者は、認証ヘッダーまたはカプセル化セキュリティペイロードのいずれかを使用して認証されていない近隣探索メッセージを無視するようにノードを構成できる必要があります（SHOULD）。これの構成テクニックは文書化されなければなりません。このようなスイッチは、デフォルトで非認証メッセージを許可する必要があります（SHOULD）。
Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6- ESP].
機密性の問題は、IPセキュリティアーキテクチャとIPカプセル化セキュリティペイロードのドキュメント[IPv6-SA、IPv6- ESP]で対処されています。
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 zero lifetime. 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日に9月1日までに番号が付け直されたため、プレフィックスを非推奨にして削除する必要があると判断された次の例を考えます。これは、アドバタイズされたライフタイムを8月1日から1週間に短縮することで実行できます。カットオフが近づくにつれて、9月1日までに、プレフィックスがゼロのライフタイムでアドバタイズされるまでライフタイムを短くできます。重要なのは、9月1日より前に1つ以上のノードがリンクから切り離された場合、最後に受け取ったライフタイムが2か月だったため、プレフィックスは有効であると考えるかもしれないということです。したがって、ノードが7月31日に抜かれた場合、プレフィックスは9月30日まで有効であると見なされます。そのノードが9月30日より前に再度接続された場合、古い接頭辞が引き続き使用される可能性があります。以前に長いライフタイムでアドバタイズされたプレフィックスの使用をノードに強制的に停止させる唯一の方法は、そのノードに、プレフィックスのアドバタイズを受信させ、ライフタイムを下方に変更することです。この例のソリューションは単純です。9月1日から10月1日まで、存続期間が0のプレフィックスを引き続きアドバタイズします。
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 a particular prefix can be viewed valid by any node on the link. The prefix must then be advertised with a 0 Lifetime until that point in 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 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 insure 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.
上記の説明では、推奨寿命と有効寿命を区別していません。推奨される有効期間は有効な有効期間を超えないため、実際的な目的では、有効な有効期間を追跡することでおそらく十分です。
REFERENCES
参考文献
[ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address Autoconfiguration", RFC 2462, December 1998.
[ADDRCONF] Thomson、S.およびT. Narten、「IPv6 Address Autoconfiguration」、RFC 2462、1998年12月。
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ADDR-ARCH] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 2373、1998年7月。
[ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[ANYCST] Partridge、C.、Mendez、T。およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月。
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982.
[ARP]プラムマー、D。、「イーサネットアドレス解決プロトコル」、STD 37、RFC 826、1982年11月。
[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[HR-CL] Braden、R。、編集者、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMPv4] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[ICMPv6] Conta、A。およびS. Deering、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 2463、1998年12月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[IPv6-ETHER] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、1998年12月。
[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPv6-SA]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[IPv6-AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[IPv6-AUTH] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[IPv6-ESP]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[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月。
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RDISC] Deering、S。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet Architecture Extensions for Shared Media", RFC 1620, May 1994.
[SH-MEDIA] Braden、R.、Postel、J。、およびY. Rekhter、「共有メディアのインターネットアーキテクチャ拡張」、RFC 1620、1994年5月。
[ASSIGNED] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[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
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@raleigh.ibm.com
Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA
Erik Nordmark Sun Microsystems、Inc. 901 San Antonio Road Palo Alto、CA 94303 USA
Phone: +1 650 786 5166
Fax: +1 650 786 5896
EMail: nordmark@sun.com
William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 USA
ウィリアムアレンシンプソンDaydreamerコンピューターシステムコンサルティングサービス1384 Fontaine Madison Heights、Michigan 48071 USA
EMail: Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
APPENDIX A: MULTIHOMED HOSTS
付録A：マルチホームホスト
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.
複数のインターフェースを持つホストが近隣探索を使用するときに発生する複雑な問題がいくつかあります。このセクションでは、近隣探索に関するマルチホームホストの適切な操作を定義することはしません。むしろ、さらなる調査が必要な問題を特定します。実装者は、ネイバーディスカバリをマルチホームホストで機能させるためのさまざまなアプローチを試し、その経験を報告することをお勧めします。
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.
1）ルーターがリダイレクトを送信するには、転送するパケットがネイバーから発信されたものであると判断する必要があります。この場合の標準的なテストは、パケットの送信元アドレスを、パケットが受信されたインターフェイスに関連付けられているオンリンクプレフィックスのリストと比較することです。ただし、発信元ホストがマルチホームの場合、使用するソースアドレスは、送信元のインターフェイス以外のインターフェイスに属している可能性があります。このような場合、ルーターはリダイレクトを送信せず、ルーティングが最適ではない可能性があります。リダイレクトするために、送信ホストは常に、送信パケットの送信元アドレスに対応するインターフェースからパケットを送信する必要があります。この問題は非マルチホームホストでは発生しないことに注意してください。インターフェースは1つだけです。
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）選択したファーストホップルーターに宛先へのルートがまったくない場合、ルーターはパケットを配信できません。ただし、宛先は、他のインターフェイスのいずれかのルーターを介して到達可能です。近隣探索はこのシナリオに対応していません。非マルチホームの場合には発生しません。
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 a number of problems:
マルチホームホストが1つまたは複数のインターフェイスでルーターアドバタイズを受信できなかった場合、影響を受けるインターフェイスでリンク上にある宛先が（構成された情報がない場合）認識されません。これは多くの問題を引き起こします：
1) If no Router Advertisement is received on any interfaces, a multihomed host will have no way of knowing which interface to send packets out on, even for on-link destinations. Under similar conditions in the non-multihomed host case, a node treats all destinations as residing on-link, and communication proceeds. In the multihomed case, however, additional information is needed to select the proper outgoing interface. Alternatively, a node could attempt to perform address resolution on all interfaces, a step involving significant complexity that is not present in the non-multihomed host case.
1）どのインターフェースでもルーター通知が受信されない場合、マルチホームホストは、リンク上の宛先であっても、どのインターフェースにパケットを送信するかを知る方法がありません。マルチホームでないホストの場合と同様の状況では、ノードはすべての宛先をリンク上にあるものとして扱い、通信が続行されます。ただし、マルチホームの場合、適切な発信インターフェイスを選択するには追加情報が必要です。あるいは、ノードがすべてのインターフェースでアドレス解決を実行しようとする可能性があります。これは、マルチホーム化されていないホストの場合にはない、かなり複雑な手順です。
2) 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 sub-optimal path.
2）すべてではなく一部のインターフェイスでルーターアドバタイズを受信した場合、マルチホームホストは、ルーターアドバタイズを受信したインターフェイスでのみパケットを送信することを選択できます。ただし、ここで重要な前提は、これらの他のインターフェイス上のルーターは、送信者が接続するサブネット上にそれらの宛先が存在するが、リンク上のプレフィックス情報がない場合でも、最終的な宛先にパケットをルーティングできることです。仮定がFALSEの場合、通信は失敗します。仮定が満たされていても、パケットは次善のパスを通過します。
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
- 送信するパケット。エントリを作成します。 INCOMPLETEマルチキャストNSを送信します。再送信タイマーを開始
INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE less than N Start retransmit timer retransmissions.
INCOMPLETE再送信タイムアウト、N未満の再送信NS INCOMPLETE再送信タイマーの再送信を開始します。
INCOMPLETE Retransmit timeout, Discard entry - N or more Send ICMP error retransmissions.
INCOMPLETE再送信タイムアウト、破棄エントリ-N以上ICMPエラーの再送信を送信します。
INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=any address. Send queued packets.
INCOMPLETE NA、Solicited = 0、Record link-layer STALE Override = any address。キューに入れられたパケットを送信します。
INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets.
INCOMPLETE NA、Solicited = 1、Record link-layer REACHABLE Override = any address。キューに入れられたパケットを送信します。
!INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached.
！INCOMPLETE NA、Solicited = 1、-REACHABLE Override = 0キャッシュと同じリンク層アドレス。
REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer address than cached.
REACHABLE NA、Solicited = 1、-STALE Override = 0キャッシュとは異なるリンク層アドレス。
STALE or PROBE NA, Solicited=1, - unchanged Override=0 Different link-layer address than cached.
STALEまたはPROBE NA、Solicited = 1、-変更なしOverride = 0キャッシュとは異なるリンク層アドレス。
!INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=1 address (if different).
！INCOMPLETE NA、Solicited = 1、レコードリンク層REACHABLE Override = 1アドレス（異なる場合）。
!INCOMPLETE NA, Solicited=0, - unchanged
Override=0
!INCOMPLETE NA, Solicited=0, - unchanged Override=1 Same link-layer address as cached.
！INCOMPLETE NA、Solicited = 0、-変更なしOverride = 1キャッシュされたのと同じリンク層アドレス。
!INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=1 address. Different link-layer address than cached.
！INCOMPLETE NA、Solicited = 0、Record link-layer 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
STALEパケット送信開始遅延タイマーDELAY
DELAY Delay timeout Send unicast NS probe PROBE Start retransmit timer
DELAY遅延タイムアウトユニキャスト送信NSプローブプローブ再送タイマーの開始
PROBE Retransmit timeout, Retransmit NS PROBE less than N retransmissions.
プローブ再送信タイムアウト、再送信NSプローブはN再送信未満です。
PROBE Retransmit timeout, Discard entry - N or more retransmissions.
PROBE再送信タイムアウト、エントリの破棄-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、リダイレクト作成エントリ。 STALE
INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE address. Send queued packets.
不完全なNS、RS、RA、リダイレクトレコードのリンク層STALEアドレス。キューに入れられたパケットを送信します。
!INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE Different link-layer address address than cached.
！INCOMPLETE NS、RS、RA、リダイレクト更新リンク層STALEキャッシュされたものとは異なるリンク層アドレスアドレス。
!INCOMPLETE NS, RS, RA, Redirect - unchanged Same link-layer address as cached.
！INCOMPLETE 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 Solicitation is implicitly assumed to be a host since there is no need for routers to send such messages.
- ルーター要請の送信者は、ルーターがそのようなメッセージを送信する必要がないため、暗黙的にホストであると見なされます。
- 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.
- 近隣要請メッセージには、送信者に関する暗黙的または明示的な指示は含まれません。ホストとルーターの両方がそのようなメッセージを送信します。
- 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：実装の問題
Appendix E.1: Reachability confirmations
付録E.1：到達可能性の確認
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:
ネイバー到達不能検出では、フォワードパスが正しく機能していることを明示的に確認する必要があります。 Neighbor Solicitationプローブメッセージの必要性を回避するために、上位層プロトコルは、そうすることのコストが小さいときにそのような指示を提供する必要があります。 TCPなどの信頼性の高い接続指向プロトコルは、通常、転送パスが機能していることを認識しています。たとえば、TCPがデータを送信（または受信）すると、ウィンドウシーケンス番号の更新、再送信タイマーの設定やキャンセルなどが行われます。通常、順方向パスが適切に機能していることを示す特定のシナリオには、次のものがあります。
- Receipt of an acknowledgement 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 the ACK of that packet on the passively opening peer.
- 最初の3ウェイハンドシェイクの完了は、前のルールの特別なケースです。ハンドシェイク中にデータは送信されませんが、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 acknowledgement 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 implementation 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に送信された次のパケットの到達可能性確認をピギーバックして、パケットが長時間IPに送信されないときにピギーバックされた確認が古くなるのを防ぐと想定できます。
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. In 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分後に受信した新しいデータは、パスが現在機能していることの確認にはなりません。 Inは、30分前にウィンドウの更新がピアに到達したこと、つまりパスがその時点で機能していたことを示しています。実装では、パスが壊れていてウィンドウの更新がピアに到達しなかった場合でも送信されるTCPゼロウィンドウプローブを考慮する必要があります。
For UDP based applications (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 can not determine whether a received request indicates that a previous response reached the client.
UDPベースのアプリケーション（RPC、DNS）の場合、応答パケットを受信したときにクライアントに到達可能性の確認を送信させるのは比較的簡単です。フロー制御がないため、サーバーがそのような確認を生成することはより困難であり、場合によっては不可能です。つまり、サーバーは、受信した要求が以前の応答がクライアントに到達したことを示すかどうかを判断できません。
Note that an implementation can not use negative upper-layer advise as a replacement for the Neighbor Unreachability Detection algorithm. Negative advise (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 acknowledgement packets to reach the sender.
実装では、近隣到達不能検出アルゴリズムの代わりに負の上位層アドバイスを使用できないことに注意してください。否定的なアドバイス（過剰な再送信がある場合のTCPからなど）は、データの送信者からの転送パスが機能していない可能性があることを示すヒントとして役立ちます。ただし、データの受信側からのパスが機能していない場合は検出できず、確認応答パケットが送信側に到達しません。
APPENDIX F: CHANGES SINCE RFC 1970
付録F：RFC 1970以降の変更
o Removed all references to the IPv6 priority field.
o IPv6優先度フィールドへの参照をすべて削除しました。
o Replaced definition of solicited node multicast address with a reference to the [ADDR-ARCH] specification. That specification says that "the solicited-node multicast address is formed by taking the low-order 24 bits of the address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104".
o 要請ノードマルチキャストアドレスの定義を[ADDR-ARCH]仕様への参照に置き換えました。その仕様では、「要請ノードマルチキャストアドレスは、アドレスの下位24ビット（ユニキャストまたはエニーキャスト）を取り、それらのビットをプレフィックスFF02：0：0：0：0：1：FF00に追加することによって形成されます。 ：/ 104 "。
o Updated the references section to list (new) RFC numbers.
o 参照セクションを更新して、（新しい）RFC番号をリストしました。
o Updated the text in section 7.2.5 and the tables in appendix C to have the receipt of an NS message update the state of an existing neighbor cache entry only if the link-layer address is different than the recorded link-layer address.
o リンク層アドレスが記録されたリンク層アドレスと異なる場合にのみ、NSメッセージの受信で既存のネイバーキャッシュエントリの状態を更新するように、セクション7.2.5のテキストと付録Cの表を更新しました。
o Added an explicit check in section 7.1.1 so that received NS messages from an unsolicited address must be sent the solicited-node multicast address; if sent to unicast destination, silently discard.
o セクション7.1.1に明示的なチェックを追加したため、非送信請求アドレスから受信したNSメッセージを送信請求ノードマルチキャストアドレスに送信する必要があります。ユニキャスト宛先に送信された場合、警告なしで破棄します。
o Added a requirement in section 6.2.1 that Lifetimes be configurable in either of two ways: as a fixed value that doesn't change over time, or one that decrements in real time.
o セクション6.2.1に、2つの方法のいずれかでライフタイムを構成できるという要件を追加しました。時間の経過とともに変化しない固定値として、またはリアルタイムで減少する値として。
o Added text in section 6.2.7 to relax the consistency checks on prefix lifetimes when the lifetimes are configured to decrement in real time. This is needed to avoid false alarms due to link propagation delay and lack of synchronized clocks.
o ライフタイムがリアルタイムで減少するように設定されている場合に、プレフィックスライフタイムの整合性チェックを緩和するために、セクション6.2.7にテキストを追加しました。これは、リンクの伝播遅延や同期クロックの欠如による誤ったアラームを回避するために必要です。
o Added text to section 6.3.4 to point out that [ADDRCONF] might ignore short lifetimes but that Neighbor Discovery does not ignore short prefix lifetimes.
o セクション6.3.4にテキストを追加して、[ADDRCONF]は短い有効期間を無視する可能性があるが、近隣探索は短いプレフィックスの有効期間を無視しないことを指摘しました。
o Clarified the rules for RS and NS packets with an unspecified source address. Such packets MUST NOT include source link-layer address option; verified by receivers.
o 送信元アドレスが指定されていないRSおよびNSパケットのルールを明確にしました。このようなパケットには、ソースリンク層アドレスオプションを含めてはなりません（MUST NOT）。受信者によって確認されました。
o Clarified in section 7.2.3 that addresses for which the node proxies are acceptable in NS messages. Previously the text only mentioned unicast and anycast addresses assigned to the interface (i.e., wasn't clear that proxy addresses were allowed).
o ノードプロキシがNSメッセージで受け入れられるアドレスであることをセクション7.2.3で明確にしました。以前は、インターフェイスに割り当てられたユニキャストアドレスとエニーキャストアドレスのみがテキストに記載されていました（つまり、プロキシアドレスが許可されていることが明確ではありませんでした）。
o Tightened up ambiguities an inconsistencies regarding when to set the IsRouter flag in Neighbor Cache entries. Added an appendix to summarize these rules.
o ネイバーキャッシュエントリでIsRouterフラグを設定するタイミングに関するあいまいさの不整合を強化しました。これらの規則を要約する付録を追加しました。
o Added a section on renumbering considerations to clarify how long prefixes have to be advertised when the lifetime(s) are reduced.
o ライフタイムが短縮されたときにプレフィックスをアドバタイズする必要がある期間を明確にするために、再番号付けの考慮事項に関するセクションを追加しました。
o Added additional text to the rules in section 7 for the NS/NA packets used for NUD probes so that the Link-Layer Address options can be omitted from these packets in certain cases without causing an infinite NS "recursion". Specifically, added text that permits the Link-Layer address to be omitted in unicast solicitations (i.e., MAY language).
o NUDプローブに使用されるNS / NAパケットのセクション7のルールに追加のテキストを追加し、無限のNS「再帰」を引き起こさずに、これらのパケットからリンク層アドレスオプションを省略できるようにしました。具体的には、リンク層アドレスをユニキャスト要請（つまりMAY言語）で省略できるようにするテキストを追加しました。
o Changed the default AdvValidLifetime from infinity to 30 days.
o デフォルトのAdvValidLifetimeを無限から30日に変更しました。
o Changed the constant "576" to "1280" in places where its context was that of the minimum sized IP packet that all links must be able to carry.
o すべてのリンクが伝送できる必要がある最小サイズのIPパケットのコンテキストであった場所で、定数「576」を「1280」に変更しました。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。