Network Working Group                                          T. Narten
Request for Comments: 4861                                           IBM
Obsoletes: 2461                                              E. Nordmark
Category: Standards Track                               Sun Microsystems
                                                              W. Simpson
                                                              Daydreamer
                                                              H. Soliman
                                                    Elevate Technologies
                                                          September 2007
        
Network Working Group                                          T. Narten
Request for Comments: 4861                                           IBM
Obsoletes: 2461                                              E. Nordmark
Category: Standards Track                               Sun Microsystems
                                                              W. Simpson
                                                              Daydreamer
                                                              H. Soliman
                                                    Elevate Technologies
                                                          September 2007
        

Neighbor Discovery for IP version 6 (IPv6)

IP版本6(IPv6)的邻居发现

Status of This Memo

关于下段备忘

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

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Abstract

摘要

This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.

本文档指定了IP版本6的邻居发现协议。同一链路上的IPv6节点使用邻居发现来发现彼此的存在,确定彼此的链路层地址,查找路由器,并维护有关到活动邻居的路径的可达性信息。

Table of Contents

目录

   1. Introduction ....................................................4
   2. Terminology .....................................................4
      2.1. General ....................................................4
      2.2. Link Types .................................................8
      2.3. Addresses ..................................................9
      2.4. Requirements ..............................................10
   3. Protocol Overview ..............................................10
      3.1. Comparison with IPv4 ......................................14
      3.2. Supported Link Types ......................................16
      3.3. Securing Neighbor Discovery Messages ......................18
   4. Message Formats ................................................18
      4.1. Router Solicitation Message Format ........................18
      4.2. Router Advertisement Message Format .......................19
      4.3. Neighbor Solicitation Message Format ......................22
      4.4. Neighbor Advertisement Message Format .....................23
      4.5. Redirect Message Format ...................................26
      4.6. Option Formats ............................................28
           4.6.1. Source/Target Link-layer Address ...................28
           4.6.2. Prefix Information .................................29
           4.6.3. Redirected Header ..................................31
           4.6.4. MTU ................................................32
   5. Conceptual Model of a Host .....................................33
      5.1. Conceptual Data Structures ................................33
      5.2. Conceptual Sending Algorithm ..............................36
      5.3. Garbage Collection and Timeout Requirements ...............37
   6. Router and Prefix Discovery ....................................38
      6.1. Message Validation ........................................39
           6.1.1. Validation of Router Solicitation Messages .........39
           6.1.2. Validation of Router Advertisement Messages ........39
      6.2. Router Specification ......................................40
           6.2.1. Router Configuration Variables .....................40
           6.2.2. Becoming an Advertising Interface ..................45
           6.2.3. Router Advertisement Message Content ...............45
           6.2.4. Sending Unsolicited Router Advertisements ..........47
           6.2.5. Ceasing To Be an Advertising Interface .............47
           6.2.6. Processing Router Solicitations ....................48
           6.2.7. Router Advertisement Consistency ...................50
           6.2.8. Link-local Address Change ..........................50
      6.3. Host Specification ........................................51
           6.3.1. Host Configuration Variables .......................51
           6.3.2. Host Variables .....................................51
           6.3.3. Interface Initialization ...........................52
           6.3.4. Processing Received Router Advertisements ..........53
           6.3.5. Timing out Prefixes and Default Routers ............56
           6.3.6. Default Router Selection ...........................56
           6.3.7. Sending Router Solicitations .......................57
        
   1. Introduction ....................................................4
   2. Terminology .....................................................4
      2.1. General ....................................................4
      2.2. Link Types .................................................8
      2.3. Addresses ..................................................9
      2.4. Requirements ..............................................10
   3. Protocol Overview ..............................................10
      3.1. Comparison with IPv4 ......................................14
      3.2. Supported Link Types ......................................16
      3.3. Securing Neighbor Discovery Messages ......................18
   4. Message Formats ................................................18
      4.1. Router Solicitation Message Format ........................18
      4.2. Router Advertisement Message Format .......................19
      4.3. Neighbor Solicitation Message Format ......................22
      4.4. Neighbor Advertisement Message Format .....................23
      4.5. Redirect Message Format ...................................26
      4.6. Option Formats ............................................28
           4.6.1. Source/Target Link-layer Address ...................28
           4.6.2. Prefix Information .................................29
           4.6.3. Redirected Header ..................................31
           4.6.4. MTU ................................................32
   5. Conceptual Model of a Host .....................................33
      5.1. Conceptual Data Structures ................................33
      5.2. Conceptual Sending Algorithm ..............................36
      5.3. Garbage Collection and Timeout Requirements ...............37
   6. Router and Prefix Discovery ....................................38
      6.1. Message Validation ........................................39
           6.1.1. Validation of Router Solicitation Messages .........39
           6.1.2. Validation of Router Advertisement Messages ........39
      6.2. Router Specification ......................................40
           6.2.1. Router Configuration Variables .....................40
           6.2.2. Becoming an Advertising Interface ..................45
           6.2.3. Router Advertisement Message Content ...............45
           6.2.4. Sending Unsolicited Router Advertisements ..........47
           6.2.5. Ceasing To Be an Advertising Interface .............47
           6.2.6. Processing Router Solicitations ....................48
           6.2.7. Router Advertisement Consistency ...................50
           6.2.8. Link-local Address Change ..........................50
      6.3. Host Specification ........................................51
           6.3.1. Host Configuration Variables .......................51
           6.3.2. Host Variables .....................................51
           6.3.3. Interface Initialization ...........................52
           6.3.4. Processing Received Router Advertisements ..........53
           6.3.5. Timing out Prefixes and Default Routers ............56
           6.3.6. Default Router Selection ...........................56
           6.3.7. Sending Router Solicitations .......................57
        
   7. Address Resolution and Neighbor Unreachability Detection .......59
      7.1. Message Validation ........................................59
           7.1.1. Validation of Neighbor Solicitations ...............59
           7.1.2. Validation of Neighbor Advertisements ..............60
      7.2. Address Resolution ........................................60
           7.2.1. Interface Initialization ...........................61
           7.2.2. Sending Neighbor Solicitations .....................61
           7.2.3. Receipt of Neighbor Solicitations ..................62
           7.2.4. Sending Solicited Neighbor Advertisements ..........63
           7.2.5. Receipt of Neighbor Advertisements .................64
           7.2.6. Sending Unsolicited Neighbor Advertisements ........66
           7.2.7. Anycast Neighbor Advertisements ....................67
           7.2.8. Proxy Neighbor Advertisements ......................68
      7.3. Neighbor Unreachability Detection .........................68
           7.3.1. Reachability Confirmation ..........................69
           7.3.2. Neighbor Cache Entry States ........................70
           7.3.3. Node Behavior ......................................71
   8. Redirect Function ..............................................73
      8.1. Validation of Redirect Messages ...........................74
      8.2. Router Specification ......................................75
      8.3. Host Specification ........................................76
   9. Extensibility - Option Processing ..............................76
   10. Protocol Constants ............................................78
   11. Security Considerations .......................................79
      11.1. Threat Analysis ..........................................79
      11.2. Securing Neighbor Discovery Messages .....................81
   12. Renumbering Considerations ....................................81
   13. IANA Considerations ...........................................83
   14. References ....................................................84
      14.1. Normative References .....................................84
      14.2. Informative References ...................................84
   Appendix A: Multihomed Hosts ......................................87
   Appendix B: Future Extensions .....................................88
   Appendix C: State Machine for the Reachability State ..............89
   Appendix D: Summary of IsRouter Rules .............................91
   Appendix E: Implementation Issues .................................92
   Appendix F: Changes from RFC 2461 .................................94
   Acknowledgments ...................................................95
        
   7. Address Resolution and Neighbor Unreachability Detection .......59
      7.1. Message Validation ........................................59
           7.1.1. Validation of Neighbor Solicitations ...............59
           7.1.2. Validation of Neighbor Advertisements ..............60
      7.2. Address Resolution ........................................60
           7.2.1. Interface Initialization ...........................61
           7.2.2. Sending Neighbor Solicitations .....................61
           7.2.3. Receipt of Neighbor Solicitations ..................62
           7.2.4. Sending Solicited Neighbor Advertisements ..........63
           7.2.5. Receipt of Neighbor Advertisements .................64
           7.2.6. Sending Unsolicited Neighbor Advertisements ........66
           7.2.7. Anycast Neighbor Advertisements ....................67
           7.2.8. Proxy Neighbor Advertisements ......................68
      7.3. Neighbor Unreachability Detection .........................68
           7.3.1. Reachability Confirmation ..........................69
           7.3.2. Neighbor Cache Entry States ........................70
           7.3.3. Node Behavior ......................................71
   8. Redirect Function ..............................................73
      8.1. Validation of Redirect Messages ...........................74
      8.2. Router Specification ......................................75
      8.3. Host Specification ........................................76
   9. Extensibility - Option Processing ..............................76
   10. Protocol Constants ............................................78
   11. Security Considerations .......................................79
      11.1. Threat Analysis ..........................................79
      11.2. Securing Neighbor Discovery Messages .....................81
   12. Renumbering Considerations ....................................81
   13. IANA Considerations ...........................................83
   14. References ....................................................84
      14.1. Normative References .....................................84
      14.2. Informative References ...................................84
   Appendix A: Multihomed Hosts ......................................87
   Appendix B: Future Extensions .....................................88
   Appendix C: State Machine for the Reachability State ..............89
   Appendix D: Summary of IsRouter Rules .............................91
   Appendix E: Implementation Issues .................................92
   Appendix F: Changes from RFC 2461 .................................94
   Acknowledgments ...................................................95
        
1. Introduction
1. 介绍

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.

本规范定义了Internet协议版本6(IPv6)的邻居发现(ND)协议。节点(主机和路由器)使用邻居发现来确定已知驻留在连接链路上的邻居的链路层地址,并快速清除无效的缓存值。主机还使用邻居发现来查找愿意代表其转发数据包的邻居路由器。最后,节点使用该协议主动跟踪哪些邻居是可访问的,哪些是不可访问的,并检测更改的链路层地址。当路由器或到路由器的路径出现故障时,主机会主动搜索运行中的备用路由器。

Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). The services described in this document that are not directly dependent on multicast, such as Redirects, Next-hop determination, Neighbor Unreachability Detection, etc., are expected to be provided as specified in this document. The details of how one uses ND on NBMA links are addressed in [IPv6-NBMA]. In addition, [IPv6-3GPP] and[IPv6-CELL] discuss the use of this protocol over some cellular links, which are examples of NBMA links.

除非另有规定(在涉及特定链路类型上的操作IP的文件中),否则本文件适用于所有链路类型。然而,由于ND对其某些服务使用链路层多播,因此在某些链路类型(例如,非广播多址(NBMA)链路)上,可能会指定实现这些服务的替代协议或机制(在涵盖特定链路类型上的IP操作的适当文档中)。本文档中描述的不直接依赖于多播的服务,例如重定向、下一跳确定、邻居不可达性检测等,预期将按照本文档中的规定提供。关于如何在NBMA链路上使用ND的详细信息,请参见[IPv6 NBMA]。此外,[IPv6-3GPP]和[IPv6 CELL]讨论了该协议在一些蜂窝链路上的使用,这些都是NBMA链路的示例。

2. Terminology
2. 术语
2.1. General
2.1. 全体的

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 Control Message Protocol for the Internet Protocol Version 6. The terms ICMPv4 and ICMPv6 are used only in contexts where necessary to avoid ambiguity.

ICMP-Internet协议版本6的Internet控制消息协议。术语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-layer (or lower-layer) protocols being "tunneled" over (i.e., encapsulated in) IP such as Internetwork Packet Exchange (IPX), AppleTalk, or IP itself.

上层-IP之上的协议层。例如,传输协议(如TCP和UDP)、控制协议(如ICMP)、路由协议(如OSPF)以及通过(即封装在)IP(如网络间数据包交换(IPX)、AppleTalk或IP本身)“隧道”的互联网层(或较低层)协议。

link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as Internet-layer (or higher-layer) "tunnels", such as tunnels over IPv4 or IPv6 itself.

链路-一种通信设施或介质,节点可通过该通信设施或介质在链路层(即IP下的一层)进行通信。例如以太网络(简单或桥接)、PPP链路、X.25、帧中继或ATM网络以及互联网层(或更高层)“隧道”,例如IPv4或IPv6本身上的隧道。

interface - a node's attachment to a link.

接口-节点与链接的附件。

neighbors - nodes attached to the same link.

邻居-连接到同一链接的节点。

address - an IP-layer identifier for an interface or a set of interfaces.

地址-一个接口或一组接口的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].

选播地址-一组接口(通常属于不同节点)的标识符。发送到选播地址的数据包被发送到该地址标识的接口之一(根据路由协议的距离度量,“最近的”接口)。见[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.

链路层地址-接口的链路层标识符。示例包括以太网链路的IEEE 802地址。

on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on-link if:

在链接上-分配给指定链接上接口的地址。在以下情况下,节点将地址视为在链路上:

- it is covered by one of the link's prefixes (e.g., as indicated by the on-link flag in the Prefix Information option), or

- 它由链接的一个前缀覆盖(例如,由前缀信息选项中的on link标志指示),或

- a neighboring router specifies the address as the target of a Redirect message, or

- 相邻路由器将地址指定为重定向消息的目标,或

- a Neighbor Advertisement message is received for the (target) address, or

- 接收到(目标)地址的邻居播发消息,或

- any Neighbor Discovery message is received from the address.

- 从该地址接收任何邻居发现消息。

off-link - the opposite of "on-link"; an address that is not assigned to any interfaces on the specified link.

断开连接-与“接通”相反;未分配给指定链接上任何接口的地址。

longest prefix match - the process of determining which prefix (if any) in a set of prefixes covers a target address. A target address is covered by a prefix if all of the bits in the prefix match the left-most bits of the target address. When multiple prefixes cover an address, the longest prefix is the one that matches.

最长前缀匹配-确定一组前缀中覆盖目标地址的前缀(如果有)的过程。如果前缀中的所有位都与目标地址的最左侧位匹配,则目标地址由前缀覆盖。当多个前缀覆盖一个地址时,最长的前缀就是匹配的前缀。

reachability - whether or not the one-way "forward" path to a neighbor is functioning properly. In particular, whether packets sent to a neighbor are reaching the IP layer on the neighboring machine and are being processed properly by the receiving IP layer. For neighboring routers, reachability means that packets sent by a node's IP layer are delivered to the router's IP layer, and the router is indeed forwarding packets (i.e., it is configured as a router, not a host). For hosts, reachability means that packets sent by a node's IP layer are delivered to the neighbor host's IP layer.

可达性-到邻居的单向“前向”路径是否正常工作。特别是,发送到邻居的数据包是否到达了邻居机器上的IP层,并且是否正被接收IP层正确处理。对于相邻路由器,可达性意味着由节点的IP层发送的数据包被传送到路由器的IP层,并且路由器确实在转发数据包(即,它被配置为路由器,而不是主机)。对于主机,可达性意味着由节点的IP层发送的数据包被传递到邻居主机的IP层。

packet - an IP header plus payload.

数据包-IP报头加上有效负载。

link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one transmission unit over a link.

链路MTU-最大传输单元,即八位字节中的最大数据包大小,可通过链路在一个传输单元中传输。

target - an address about which address resolution information is sought, or an address that is the new first hop when being redirected.

目标-查找地址解析信息的地址,或重定向时新的第一个跃点的地址。

proxy - a node that responds to Neighbor Discovery query messages on behalf of another node. A router acting on behalf of a mobile node that has moved off-link could potentially act as a proxy for the mobile node.

代理-代表另一个节点响应邻居发现查询消息的节点。代表已脱离链路的移动节点的路由器可能充当移动节点的代理。

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返回到原始目的地的指示[PV6]中列出的ICMP错误指示。如果错误发生在发起数据包的节点以外的节点上,则会生成ICMP错误消息。如果错误发生在发起节点上,则不需要实现实际创建ICMP错误数据包并将其发送到源,只要上层发送方通过适当的机制得到通知(例如,过程调用的返回值)。但是,请注意,在某些情况下,实现可能会发现将错误返回给发送方很方便,方法是获取有问题的数据包,生成ICMP错误消息,然后通过通用错误处理例程(本地)传递它。

random delay - when sending out messages, it is sometimes necessary to delay a transmission for a random amount of time in order to prevent multiple nodes from transmitting at exactly the same time, or to prevent long-range periodic transmissions from synchronizing with each other [SYNC]. When a random component is required, a node calculates the actual delay in such a way that the computed delay forms a uniformly distributed random value that falls between the specified minimum and maximum delay times. The implementor must take care to ensure that the granularity of the calculated random component and the resolution of the timer used are both high enough to ensure that the probability of multiple nodes delaying the same amount of time is small.

随机延迟-发送消息时,有时需要将传输延迟一段随机时间,以防止多个节点在同一时间进行传输,或防止长距离定期传输相互同步[SYNC]。当需要随机分量时,节点计算实际延迟的方式是,计算的延迟形成均匀分布的随机值,介于指定的最小和最大延迟时间之间。实现者必须注意确保计算出的随机组件的粒度和使用的计时器的分辨率都足够高,以确保多个节点延迟相同时间量的概率很小。

random delay seed - if a pseudo-random number generator is used in calculating a random delay component, the generator should be initialized with a unique seed prior to being used. Note that it is not sufficient to use the interface identifier alone as the seed, since interface

随机延迟种子-如果在计算随机延迟组件时使用伪随机数生成器,则在使用该生成器之前,应使用唯一种子对其进行初始化。请注意,仅使用接口标识符作为种子是不够的,因为接口

identifiers will not always be unique. To reduce the probability that duplicate interface identifiers cause the same seed to be used, the seed should be calculated from a variety of input sources (e.g., machine components) that are likely to be different even on identical "boxes". For example, the seed could be formed by combining the CPU's serial number with an interface identifier. Additional information on randomness and random number generation can be found in [RAND].

标识符并不总是唯一的。为了减少重复接口标识符导致使用相同种子的可能性,应根据各种输入源(例如机器部件)计算种子,即使在相同的“框”上,这些输入源也可能不同。例如,可以通过将CPU的序列号与接口标识符相结合来形成种子。有关随机性和随机数生成的其他信息,请参见[RAND]。

2.2. Link Types
2.2. 链接类型

Different link layers have different properties. The ones of concern to Neighbor Discovery are:

不同的链接层具有不同的属性。邻居发现关注的问题有:

multicast capable - a link that supports a native mechanism at the link layer for sending packets to all (i.e., broadcast) or a subset of all neighbors.

支持多播-在链路层支持本机机制的链路,用于向所有邻居(即广播)或所有邻居的子集发送数据包。

point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast capability and a link-local address.

点对点-正好连接两个接口的链接。假设点到点链路具有多播能力和链路本地地址。

non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, but that does not support a native form of multicast or broadcast (e.g., X.25, ATM, frame relay, etc.). Note that all link types (including NBMA) are expected to provide multicast service for applications that need it (e.g., using multicast servers). However, it is an issue for further study whether ND should use such facilities or an alternate mechanism that provides the equivalent multicast capability for ND.

非广播多址(NBMA)-可以连接两个以上接口的链路,但不支持本地形式的多播或广播(如X.25、ATM、帧中继等)。请注意,所有链路类型(包括NBMA)都应为需要的应用程序(例如,使用多播服务器)提供多播服务。然而,ND是否应该使用这样的设施或为ND提供等效多播能力的替代机制是一个有待进一步研究的问题。

shared media - a link that allows direct communication among a number of nodes, but attached nodes are configured in such a way that they do not have complete prefix information for all on-link destinations. That is, at the IP level, nodes on the same link may not know that they are neighbors; by default, they communicate through a router. Examples are large (switched) public data networks such as Switched Multimegabit Data Service (SMDS) and Broadband Integrated Services Digital Network (B-ISDN). Also known as "large clouds". See [SH-MEDIA].

共享媒体-允许多个节点之间直接通信的链路,但连接的节点的配置方式使其不具有所有链路上目的地的完整前缀信息。也就是说,在IP级别,同一链路上的节点可能不知道它们是邻居;默认情况下,它们通过路由器进行通信。例如,大型(交换式)公共数据网络,如交换式兆比特数据业务(SMDS)和宽带综合业务数字网(B-ISDN)。也被称为“大云”。请参阅[SH-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)。许多无线链路都具有这些特性。

2.3. Addresses
2.3. 地址

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.

所有节点多播地址-到达所有节点的链接本地作用域地址,FF02::1。

all-routers multicast address - the link-local scope address to reach all routers, FF02::2.

所有路由器多播地址-到达所有路由器的链路本地作用域地址,FF02::2。

solicited-node multicast address - a link-local scope multicast address that is computed as a function of the solicited target's address. The function is described in [ADDR-ARCH]. The function is chosen so that IP addresses that differ only in the most significant bits, e.g., due to multiple prefixes associated with different providers, will map to the same solicited-node address thereby reducing the number of multicast addresses a node must join at the link layer.

请求节点多播地址-作为请求目标地址的函数计算的链路本地作用域多播地址。[ADDR-ARCH]中描述了该功能。选择该功能使得仅在最高有效位上不同的IP地址(例如,由于与不同提供者相关联的多个前缀)将映射到相同请求的节点地址,从而减少节点必须在链路层加入的多播地址的数量。

link-local address - a unicast address having link-only scope that can be used to reach neighbors. All interfaces on routers MUST have a link-local address. Also, [ADDRCONF] requires that interfaces on hosts have a link-local address.

链路本地地址-一个单播地址,具有可用于到达邻居的仅链路作用域。路由器上的所有接口必须具有链路本地地址。此外,[ADDRCONF]要求主机上的接口具有链接本地地址。

unspecified address - a reserved address value that indicates the lack of an address (e.g., the address is unknown). It is never used as a destination address, but may be used as a source address if the sender does not (yet) know its own address (e.g., while verifying an address is unused during stateless address autoconfiguration [ADDRCONF]). The unspecified address has a value of 0:0:0:0:0:0:0:0.

未指定地址-表示缺少地址的保留地址值(例如,地址未知)。它从未用作目标地址,但如果发送方(尚未)知道自己的地址(例如,在无状态地址自动配置[ADDRCONF]期间验证地址未使用时),则可以用作源地址。未指定的地址的值为0:0:0:0:0:0:0:0。

Note that this specification does not strictly comply with the consistency requirements in [ADDR-SEL] for the scopes of source and destination addresses. It is possible in some cases for hosts to use a source address of a larger scope than the destination address in the IPv6 header.

请注意,本规范未严格遵守[ADDR-SEL]中源地址和目标地址范围的一致性要求。在某些情况下,主机可能会在IPv6标头中使用范围大于目标地址的源地址。

2.4. Requirements
2.4. 要求

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS].

本文件中出现的关键词必须、不得、要求、应、不应、应、不应、建议、可能和可选时,应按照[关键词]中的说明进行解释。

This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document.

本文档还使用内部概念变量来描述协议行为和实现必须允许系统管理员更改的外部变量。提供特定变量名称、其值如何更改以及其设置如何影响协议行为,以演示协议行为。只要实现的外部行为与本文档中描述的一致,则不要求实现的外部行为与本文中描述的完全相同。

3. Protocol Overview
3. 协议概述

This protocol solves a set of problems related to the interaction between nodes attached to the same link. It defines mechanisms for solving each of the following problems:

该协议解决了与连接到同一链路的节点之间的交互相关的一组问题。它定义了解决以下每个问题的机制:

Router Discovery: How hosts locate routers that reside on an attached link.

路由器发现:主机如何定位驻留在连接链路上的路由器。

Prefix Discovery: How hosts discover the set of address prefixes that define which destinations are on-link for an attached link. (Nodes use prefixes to distinguish destinations that reside on-link from those only reachable through a router.)

前缀发现:主机如何发现一组地址前缀,这些地址前缀定义了连接的链接上的目的地。(节点使用前缀区分驻留在链路上的目的地和只能通过路由器到达的目的地。)

Parameter Discovery: How a node learns link parameters (such as the link MTU) or Internet parameters (such as the hop limit value) to place in outgoing packets.

参数发现:节点如何学习链路参数(如链路MTU)或Internet参数(如跳数限制值)以放入传出数据包中。

Address Autoconfiguration: Introduces the mechanisms needed in order to allow nodes to configure an address for an interface in a stateless manner. Stateless address autoconfiguration is specified in [ADDRCONF].

地址自动配置:介绍允许节点以无状态方式为接口配置地址所需的机制。[ADDRCONF]中指定了无状态地址自动配置。

Address resolution: How nodes determine the link-layer address of an on-link destination (e.g., a neighbor) given only the destination's IP address.

地址解析:仅给定目的地的IP地址,节点如何确定链路上目的地(如邻居)的链路层地址。

Next-hop determination: The algorithm for mapping an IP destination address into the IP address of the neighbor to which traffic for the destination should be sent. The next-hop can be a router or the destination itself.

下一跳确定:将IP目标地址映射到邻居的IP地址的算法,该邻居应将目标的通信发送到该地址。下一跳可以是路由器或目的地本身。

Neighbor Unreachability Detection: How nodes determine that a neighbor is no longer reachable. For neighbors used as routers, alternate default routers can be tried. For both routers and hosts, address resolution can be performed again.

邻居不可达性检测:节点如何确定邻居不再可达。对于用作路由器的邻居,可以尝试备用默认路由器。对于路由器和主机,都可以再次执行地址解析。

Duplicate Address Detection: How a node determines whether or not an address it wishes to use is already in use by another node.

重复地址检测:一个节点如何确定它希望使用的地址是否已经被另一个节点使用。

Redirect: How a router informs a host of a better first-hop node to reach a particular destination.

重定向:路由器如何通知主机更好的第一跳节点以到达特定目的地。

Neighbor Discovery defines five different ICMP packet types: A pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and Neighbor Advertisements messages, and a Redirect message. The messages serve the following purpose:

邻居发现定义了五种不同的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 determining whether another address shares the same link (on-link determination) and/or address configuration, a suggested hop limit value, etc.

路由器广告:路由器定期或响应路由器请求消息,通过各种链路和互联网参数来宣传其存在。路由器广告包含用于确定另一地址是否共享同一链路(链路上确定)和/或地址配置、建议的跃点限制值等的前缀。

Neighbor Solicitation: Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. Neighbor Solicitations are also used for Duplicate Address Detection.

邻居请求:由节点发送,以确定邻居的链路层地址,或验证是否仍然可以通过缓存的链路层地址访问邻居。邻居请求也用于重复地址检测。

Neighbor Advertisement: A response to a Neighbor Solicitation message. A node may also send unsolicited Neighbor Advertisements to announce a link-layer address change.

邻居广告:对邻居请求消息的响应。节点还可以发送未经请求的邻居公告,以宣布链路层地址更改。

Redirect: Used by routers to inform hosts of a better first hop for a destination.

重定向:路由器用来通知主机一个目的地的更好的第一跳。

On multicast-capable links, each router periodically multicasts a Router Advertisement packet announcing its availability. A host receives Router Advertisements from all routers, building a list of default routers. Routers generate Router Advertisements frequently enough that hosts will learn of their presence within a few minutes, but not frequently enough to rely on an absence of advertisements to detect router failure; a separate Neighbor Unreachability Detection algorithm provides failure detection.

在支持多播的链路上,每个路由器定期多播一个路由器广告包,宣布其可用性。主机从所有路由器接收路由器广告,建立默认路由器列表。路由器生成路由器广告的频率足以使主机在几分钟内了解到它们的存在,但不足以依靠没有广告来检测路由器故障;单独的邻居不可达性检测算法提供故障检测。

Router Advertisements contain a list of prefixes used for on-link determination and/or autonomous address configuration; flags associated with the prefixes specify the intended uses of a particular prefix. Hosts use the advertised on-link prefixes to build and maintain a list that is used in deciding when a packet's destination is on-link or beyond a router. Note that a destination can be on-link even though it is not covered by any advertised on-link prefix. In such cases, a router can send a Redirect informing the sender that the destination is a neighbor.

路由器广告包含用于链路上确定和/或自主地址配置的前缀列表;与前缀关联的标志指定特定前缀的预期用途。主机使用公布的链路前缀来构建和维护一个列表,该列表用于确定数据包的目的地是在链路上还是在路由器之外。请注意,目的地可以在链接上,即使它不包含在任何公布的链接前缀中。在这种情况下,路由器可以发送重定向,通知发送方目的地是邻居。

Router Advertisements (and per-prefix flags) allow routers to inform hosts how to perform Address Autoconfiguration. For example, routers can specify whether hosts should use DHCPv6 and/or autonomous (stateless) address configuration.

路由器广告(和每个前缀标志)允许路由器通知主机如何执行地址自动配置。例如,路由器可以指定主机是否应使用DHCPv6和/或自主(无状态)地址配置。

Router Advertisement messages also contain Internet parameters such as the hop limit that hosts should use in outgoing packets and, optionally, link parameters such as the link MTU. This facilitates centralized administration of critical parameters that can be set on routers and automatically propagated to all attached hosts.

路由器广告消息还包含Internet参数,如主机在传出数据包中应使用的跃点限制,以及可选的链路参数,如链路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层正确处理。邻居不可达性检测使用来自两个来源的确认。在可能的情况下,上层协议提供连接正在“向前进行”的肯定确认,也就是说,已知先前发送的数据已正确传递(例如,最近收到了新的确认)。当通过这样的“提示”未得到肯定确认时,节点发送单播邻居请求消息,该消息从下一跳请求邻居广告作为可达性确认。为了减少不必要的网络流量,探测消息只发送给节点正在主动向其发送数据包的邻居。

In addition to addressing the above general problems, Neighbor Discovery also handles the following situations:

除了解决上述一般问题外,邻居发现还处理以下情况:

Link-layer address change - A node that knows its link-layer address has changed can multicast a few (unsolicited) Neighbor Advertisement packets to all nodes to quickly update cached link-layer addresses that have become invalid. Note that the sending of unsolicited advertisements is a performance enhancement only (e.g., unreliable). The Neighbor Unreachability Detection algorithm ensures that all nodes will reliably discover the new address, though the delay may be somewhat longer.

链路层地址更改-知道其链路层地址已更改的节点可以将几个(未经请求的)邻居播发数据包多播到所有节点,以快速更新已失效的缓存链路层地址。请注意,发送未经请求的广告只是一种性能增强(例如,不可靠)。邻居不可达性检测算法确保所有节点都能可靠地发现新地址,尽管延迟可能会稍长一些。

Inbound load balancing - Nodes with replicated interfaces may want to load balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses.

入站负载平衡-具有复制接口的节点可能希望在同一链路上的多个网络接口上对传入数据包的接收进行负载平衡。此类节点具有分配给同一接口的多个链路层地址。例如,单个网络驱动程序可以将多个网络接口卡表示为具有多个链路层地址的单个逻辑接口。

Neighbor Discovery allows a router to perform load balancing for traffic addressed to itself by allowing routers to omit the source link-layer address from Router Advertisement packets, thereby forcing neighbors to use Neighbor Solicitation messages to learn link-layer addresses of routers. Returned Neighbor Advertisement messages can then contain link-layer addresses that differ depending on, e.g., who issued the solicitation. This specification does not define a mechanism that allows hosts to Load-balance incoming packets. See [LD-SHRE].

邻居发现允许路由器通过允许路由器从路由器广告包中省略源链路层地址,从而迫使邻居使用邻居请求消息来学习路由器的链路层地址,从而允许路由器对寻址到自身的流量执行负载平衡。然后,返回的邻居广告消息可以包含根据(例如)发出请求的人而不同的链路层地址。此规范未定义允许主机对传入数据包进行负载平衡的机制。见[LD-SHRE]。

Anycast addresses - Anycast addresses identify one of a set of nodes providing an equivalent service, and multiple nodes on the same link may be configured to recognize the same anycast address. Neighbor Discovery handles anycasts by having nodes expect to receive multiple Neighbor Advertisements for the same target. All advertisements for anycast addresses are tagged as being non-Override advertisements. A non-Override advertisement is one that does not update or replace the information sent by another advertisement. These advertisements are discussed later in the context of Neighbor advertisement messages. This invokes specific rules to determine which of potentially multiple advertisements should be used.

选播地址-选播地址标识提供等效服务的一组节点中的一个,同一链路上的多个节点可以配置为识别相同的选播地址。邻居发现通过让节点期望接收同一目标的多个邻居播发来处理选播。选播地址的所有播发都标记为非覆盖播发。非替代播发是指不更新或替换另一播发发送的信息的播发。这些广告稍后将在邻居广告消息的上下文中讨论。这将调用特定规则来确定应该使用可能的多个广告中的哪一个。

Proxy advertisements - A node willing to accept packets on behalf of a target address that is unable to respond to Neighbor Solicitations can issue non-Override Neighbor Advertisements. Proxy advertisements are used by Mobile IPv6 Home Agents to defend mobile nodes' addresses when they move off-link. However, it is not intended as a general mechanism to handle nodes that, e.g., do not implement this protocol.

代理播发-如果节点愿意代表无法响应邻居请求的目标地址接受数据包,则可以发出非覆盖邻居播发。移动IPv6主代理使用代理播发在移动节点脱离链路时保护移动节点的地址。然而,它不是用来处理例如不实现该协议的节点的一般机制。

3.1. Comparison with IPv4
3.1. 与IPv4的比较

The IPv6 Neighbor Discovery protocol corresponds to a combination of the IPv4 protocols Address Resolution Protocol [ARP], ICMP Router Discovery [RDISC], and ICMP Redirect [ICMPv4]. In IPv4 there is no generally agreed upon protocol or mechanism for Neighbor Unreachability Detection, although the Hosts Requirements document [HR-CL] does specify some possible algorithms for Dead Gateway Detection (a subset of the problems Neighbor Unreachability Detection tackles).

IPv6邻居发现协议对应于IPv4协议地址解析协议[ARP]、ICMP路由器发现[RDISC]和ICMP重定向[ICMPv4]的组合。在IPv4中,虽然主机需求文档[HR-CL]确实指定了一些可能的死网关检测算法(邻居不可访问性检测问题的一个子集),但对于邻居不可访问性检测,并没有公认的协议或机制。

The Neighbor Discovery protocol provides a multitude of improvements over the IPv4 set of protocols:

邻居发现协议比IPv4协议集提供了许多改进:

Router Discovery is part of the base protocol set; there is no need for hosts to "snoop" the routing protocols.

路由器发现是基本协议集的一部分;主机不需要“窥探”路由协议。

Router Advertisements carry link-layer addresses; no additional packet exchange is needed to resolve the router's link-layer address.

路由器广告携带链路层地址;解析路由器的链路层地址不需要额外的数据包交换。

Router Advertisements carry prefixes for a link; there is no need to have a separate mechanism to configure the "netmask".

路由器广告带有链接的前缀;不需要有单独的机制来配置“网络掩码”。

Router Advertisements enable Address Autoconfiguration.

路由器广告启用地址自动配置。

Routers can advertise an MTU for hosts to use on the link, ensuring that all nodes use the same MTU value on links lacking a well-defined MTU.

路由器可以公布一个MTU供主机在链路上使用,确保所有节点在缺少定义良好的MTU的链路上使用相同的MTU值。

Address resolution multicasts are "spread" over 16 million (2^24) multicast addresses, greatly reducing address-resolution-related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all.

地址解析多播“分布”在1600万(2^24)个多播地址上,大大减少了目标节点以外节点上与地址解析相关的中断。此外,非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, which significantly improves the robustness of packet delivery in the presence of failing routers, partially failing or partitioned links, or nodes that change their link-layer addresses. For

邻居不可达性检测是基础的一部分,它显著提高了在路由器故障、部分故障或分区链路或更改其链路层地址的节点出现时数据包交付的鲁棒性。对于

instance, mobile nodes can move off-link without losing any connectivity due to stale ARP caches.

例如,移动节点可以脱离链接,而不会因为过时的ARP缓存而失去任何连接。

Unlike ARP, Neighbor Discovery detects half-link failures (using Neighbor Unreachability Detection) and avoids sending traffic to neighbors with which two-way connectivity is absent.

与ARP不同,邻居发现检测半链路故障(使用邻居不可达性检测),并避免向缺少双向连接的邻居发送流量。

Unlike in IPv4 Router Discovery, the Router Advertisement messages do not contain a preference field. The preference field is not needed to handle routers of different "stability"; the Neighbor Unreachability Detection will detect dead routers and switch to a working one.

与IPv4路由器发现不同,路由器公告消息不包含首选项字段。偏好字段不需要处理不同“稳定性”的路由器;邻居不可达性检测将检测失效路由器并切换到工作路由器。

The use of link-local addresses to uniquely identify routers (for Router Advertisement and Redirect messages) makes it possible for hosts to maintain the router associations in the event of the site renumbering to use new global prefixes.

使用链路本地地址来唯一标识路由器(用于路由器广告和重定向消息),使得主机能够在站点重新编号以使用新的全局前缀时维护路由器关联。

By setting the Hop Limit to 255, Neighbor Discovery is immune to off-link senders that accidentally or intentionally send ND messages. In IPv4, off-link senders can send both ICMP Redirects and Router Advertisement messages.

通过将跃点限制设置为255,邻居发现不受意外或有意发送ND消息的断开链接发送者的影响。在IPv4中,断开链路的发送方可以发送ICMP重定向和路由器广告消息。

Placing address resolution at the ICMP layer makes the protocol more media-independent than ARP and makes it possible to use generic IP-layer authentication and security mechanisms as appropriate.

将地址解析放在ICMP层使协议比ARP更独立于媒体,并使其能够酌情使用通用IP层身份验证和安全机制。

3.2. Supported Link Types
3.2. 支持的链接类型

Neighbor Discovery supports links with different properties. In the presence of certain properties, only a subset of the ND protocol mechanisms are fully specified in this document:

邻居发现支持具有不同属性的链接。在存在某些属性的情况下,本文档中仅完全指定了ND协议机制的一个子集:

point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point-to-point links, and interfaces can be assigned link-local addresses.)

点对点-邻居发现处理此类链接就像处理多播链接一样。(可以在点到点链路上提供多播,并且可以为接口分配链路本地地址。)

multicast - Neighbor Discovery operates over multicast capable links as described in this document.

多播-如本文档所述,邻居发现在支持多播的链路上运行。

non-broadcast multiple access (NBMA) - Redirect, Neighbor Unreachability Detection and next-hop determination should be implemented as described in this document. Address resolution, and the mechanism for delivering Router Solicitations and Advertisements on NBMA links are

非广播多址(NBMA)-重定向、邻居不可达性检测和下一跳确定应按照本文档所述实施。地址解析,以及在NBMA链路上发送路由器请求和广告的机制

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.

本文件中未指定。请注意,如果主机支持手动配置默认路由器列表,则主机可以从重定向消息中动态获取其邻居的链路层地址。

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 an MTU for the link, which all nodes then use. All nodes on a link must use the same MTU (or Maximum Receive Unit) in order for multicast to work properly. Otherwise, when multicasting, a sender, which can not know which nodes will receive the packet, could not determine a minimum packet size that all receivers can process (or Maximum Receive Unit).

变量MTU-邻居发现允许路由器为链路指定MTU,然后所有节点都使用该MTU。链路上的所有节点必须使用相同的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.

该协议可以在未来进行扩展,以便在缺乏自反性和传递性连接的环境中找到可行的路径。

3.3. Securing Neighbor Discovery Messages
3.3. 保护邻居发现消息

Neighbor Discovery messages are needed for various functions. Several functions are designed to allow hosts to ascertain the ownership of an address or the mapping between link-layer and IP-layer addresses. Vulnerabilities related to Neighbor Discovery are discussed in Section 11.1. A general solution for securing Neighbor Discovery is outside the scope of this specification and is discussed in [SEND]. However, Section 11.2 explains how and under which constraints IPsec Authentication Header (AH) or Encapsulating Security Payload (ESP) can be used to secure Neighbor Discovery.

各种功能都需要邻居发现消息。设计了几个功能,以允许主机确定地址的所有权或链路层和IP层地址之间的映射。第11.1节讨论了与邻居发现相关的漏洞。保护邻居发现的通用解决方案不在本规范的范围内,并在[SEND]中讨论。但是,第11.2节解释了如何以及在何种约束下使用IPsec身份验证头(AH)或封装安全负载(ESP)来保护邻居发现。

4. Message Formats
4. 消息格式

This section introduces message formats for all messages used in this specification.

本节介绍本规范中使用的所有消息的消息格式。

4.1. Router Solicitation Message Format
4.1. 路由器请求消息格式

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 ...
     +-+-+-+-+-+-+-+-+-+-+-+-
        
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-
        

IP Fields:

IP字段:

Source Address An IP address assigned to the sending interface, or the unspecified address if no address is assigned to the sending interface.

源地址分配给发送接口的IP地址,如果未分配地址给发送接口,则为未指定的地址。

Destination Address Typically the all-routers multicast address.

目标地址通常是所有路由器的多播地址。

Hop Limit 255

跃点限制255

ICMP Fields:

ICMP字段:

Type 133

133型

Code 0

代码0

Checksum The ICMP checksum. See [ICMPv6].

校验和ICMP校验和。见[ICMPv6]。

Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Options:

保留此字段未使用。发送方必须将其初始化为零,接收方必须忽略它。有效选项:

Source link-layer address The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise, it SHOULD be included on link layers that have addresses.

源链接层地址发送方的链接层地址(如果已知)。如果源地址是未指定的地址,则不能包含。否则,它应该包含在具有地址的链接层上。

Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.

此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们不识别的任何选项,并继续处理消息。

4.2. Router Advertisement Message Format
4.2. 路由器广告消息格式

Routers send out Router Advertisement messages periodically, or in response to Router Solicitations.

路由器定期发送路由器广告消息,或响应路由器请求。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-
        
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-
        

IP Fields:

IP字段:

Source Address MUST be the link-local address assigned to the interface from which this message is sent.

源地址必须是分配给发送此消息的接口的链路本地地址。

Destination Address Typically the Source Address of an invoking Router Solicitation or the all-nodes multicast address.

目标地址通常是调用路由器请求的源地址或所有节点多播地址。

Hop Limit 255

跃点限制255

ICMP Fields:

ICMP字段:

Type 134

134型

Code 0

代码0

Checksum The ICMP checksum. See [ICMPv6].

校验和ICMP校验和。见[ICMPv6]。

Cur Hop Limit 8-bit unsigned integer. The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of zero means unspecified (by this router).

Cur-Hop Limit 8位无符号整数。对于传出的IP数据包,应在IP标头的跃点计数字段中放置的默认值。值为零表示未指定(此路由器)。

M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6].

M 1位“托管地址配置”标志。设置后,表示地址可通过动态主机配置协议[DHCPv6]使用。

If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.

如果设置了M标志,则O标志是冗余的,可以忽略,因为DHCPv6将返回所有可用的配置信息。

O 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network.

O 1位“其他配置”标志。设置时,表示通过DHCPv6可以获得其他配置信息。此类信息的示例为DNS相关信息或网络内其他服务器上的信息。

Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6.

注意:如果既没有设置M也没有设置O标志,则表示没有通过DHCPv6提供的信息。

Reserved A 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.

保留一个6位未使用字段。发送方必须将其初始化为零,接收方必须忽略它。

Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default

路由器生存期16位无符号整数。与默认路由器关联的生存期(以秒为单位)。该字段最多可包含65535个值,接收方应处理任何值,而第6节中的发送规则将生存时间限制为9000秒。生存期为0表示路由器不是默认路由器,不应出现在默认路由器上

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.

路由器列表。路由器寿命仅适用于路由器作为默认路由器的可用性;它不适用于包含在其他消息字段或选项中的信息。需要对其信息进行时间限制的选项包括其自己的生存期字段。

Reachable Time 32-bit unsigned integer. The time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm (see Section 7.3). A value of zero means unspecified (by this router).

可达时间32位无符号整数。节点在收到可访问性确认后假定邻居可访问的时间(以毫秒为单位)。由邻居不可达性检测算法使用(见第7.3节)。值为零表示未指定(此路由器)。

Retrans Timer 32-bit unsigned integer. The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm (see Sections 7.2 and 7.3). A value of zero means unspecified (by this router).

重新传输计时器32位无符号整数。重新传输的邻居请求消息之间的时间(以毫秒为单位)。用于地址解析和邻居不可达性检测算法(见第7.2和7.3节)。值为零表示未指定(此路由器)。

Possible options:

可能的选择:

Source link-layer address The link-layer address of the interface from which the Router Advertisement is sent. Only used on link layers that have addresses. A router MAY omit this option in order to enable inbound load sharing across multiple link-layer addresses.

源链路层地址发送路由器公告的接口的链路层地址。仅在具有地址的链接层上使用。路由器可以省略此选项,以便跨多个链路层地址实现入站负载共享。

MTU SHOULD be sent on links that have a variable MTU (as specified in the document that describes how to run IP over the particular link type). MAY be sent on other links.

MTU应该在具有变量MTU的链接上发送(如描述如何在特定链接类型上运行IP的文档中所指定)。可以通过其他链接发送。

Prefix Information These options specify the prefixes that are on-link and/or are used for stateless address autoconfiguration. A router SHOULD include all its on-link prefixes (except the link-local prefix) so that multihomed hosts have complete prefix information about on-link destinations for the links to which they attach. If complete information is lacking, a host with multiple interfaces may not be able to choose the correct outgoing interface when sending traffic to its neighbors.

前缀信息这些选项指定链接上的前缀和/或用于无状态地址自动配置的前缀。路由器应包括其所有的链路上前缀(链路本地前缀除外),以便多宿主机具有有关其所连接链路的链路上目的地的完整前缀信息。如果缺少完整信息,则具有多个接口的主机在向其邻居发送流量时可能无法选择正确的传出接口。

Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.

此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们不识别的任何选项,并继续处理消息。

4.3. Neighbor Solicitation Message Format
4.3. 邻居请求消息格式

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 ...
     +-+-+-+-+-+-+-+-+-+-+-+-
        
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Target Address                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-
        

IP Fields:

IP字段:

Source Address Either an address assigned to the interface from which this message is sent or (if Duplicate Address Detection is in progress [ADDRCONF]) the unspecified address. Destination Address Either the solicited-node multicast address corresponding to the target address, or the target address. Hop Limit 255

源地址分配给发送此消息的接口的地址或(如果正在进行重复地址检测[ADDRCONF])未指定的地址。目标地址与目标地址或目标地址对应的请求节点多播地址。跃点限制255

ICMP Fields:

ICMP字段:

Type 135

135型

Code 0

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

Source链路层地址发送方的链路层地址。当源IP地址为未指定的地址时,不得包含。否则,在具有地址的链路层上,此选项必须包含在多播请求中,并且应包含在单播请求中。

Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.

此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们不识别的任何选项,并继续处理消息。

4.4. Neighbor Advertisement Message Format
4.4. 邻居广告消息格式

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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|S|O|                     Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Target Address                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-
        

IP Fields:

IP字段:

Source Address An address assigned to the interface from which the advertisement is sent. Destination Address For solicited advertisements, the Source Address of an invoking Neighbor Solicitation or, if the solicitation's Source Address is the unspecified address, the all-nodes multicast address.

源地址分配给发送播发的接口的地址。请求播发的目标地址,调用邻居请求的源地址,或者,如果请求的源地址是未指定的地址,则为所有节点多播地址。

For unsolicited advertisements typically the all-nodes multicast address.

对于未经请求的播发,通常为所有节点的多播地址。

Hop Limit 255

跃点限制255

ICMP Fields:

ICMP字段:

Type 136

136型

Code 0

代码0

Checksum The ICMP checksum. See [ICMPv6].

校验和ICMP校验和。见[ICMPv6]。

R Router flag. When set, the R-bit indicates that the sender is a router. The R-bit is used by Neighbor Unreachability Detection to detect a router that changes to a host.

R路由器标志。设置后,R位表示发送方是路由器。邻居不可达性检测使用R位来检测更改为主机的路由器。

S Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. It MUST NOT be set in multicast advertisements or in unsolicited unicast advertisements.

美国国旗。当设置时,S位指示广告是响应来自目标地址的邻居请求而发送的。S位用作邻居不可达性检测的可达性确认。不得在多播播发或未经请求的单播播发中设置。

O Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached link-layer address. When it is not set the advertisement will not update a cached link-layer address though it will update an existing Neighbor Cache entry for which no link-layer address is known. It SHOULD NOT be set in solicited advertisements for anycast addresses and in solicited proxy advertisements. It SHOULD be set in other solicited advertisements and in unsolicited advertisements.

O覆盖标志。设置时,O位指示播发应覆盖现有缓存项并更新缓存的链接层地址。未设置时,播发将不会更新缓存的链接层地址,尽管它将更新不知道链接层地址的现有邻居缓存项。不得在任意广播地址的征集广告和征集代理广告中设置。应在其他征集广告和主动征集广告中设置。

Reserved 29-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.

保留29位未使用字段。发送方必须将其初始化为零,接收方必须忽略它。

Target Address For solicited advertisements, the Target Address field in the Neighbor Solicitation message that prompted this advertisement. For an unsolicited advertisement, the address whose link-layer address has changed. The Target Address MUST NOT be a multicast address.

请求播发的目标地址,邻居请求消息中提示此播发的目标地址字段。对于未经请求的播发,其链接层地址已更改的地址。目标地址不能是多播地址。

Possible options:

可能的选择:

Target link-layer address The link-layer address for the target, i.e., the sender of the advertisement. This option MUST be included on link layers that have addresses when responding to multicast solicitations. When responding to a unicast Neighbor Solicitation this option SHOULD be included.

目标链路层地址目标的链路层地址,即广告的发送者。在响应多播请求时,此选项必须包含在具有地址的链路层上。当响应单播邻居请求时,应包括此选项。

The option MUST be included for multicast solicitations in order to avoid infinite Neighbor Solicitation "recursion" when the peer node does not have a cache entry to return a Neighbor Advertisements message. When responding to unicast solicitations, the option can be omitted since the sender of the solicitation has the correct link-layer address; otherwise, it would not be able to send the unicast solicitation in the first place. However, including the link-layer address in this case adds little overhead and eliminates a potential race condition where the sender deletes the cached link-layer address prior to receiving a response to a previous solicitation.

该选项必须包含在多播请求中,以避免对等节点没有用于返回邻居消息的缓存项时出现无限邻居请求“递归”。当响应单播请求时,可以省略该选项,因为请求的发送方具有正确的链路层地址;否则,它首先将无法发送单播请求。然而,在这种情况下,包括链路层地址只会增加很少的开销,并且消除了发送方在接收到对先前请求的响应之前删除缓存的链路层地址的潜在竞争条件。

Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.

此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们不识别的任何选项,并继续处理消息。

4.5. Redirect Message Format
4.5. 重定向消息格式

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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Target Address                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Destination Address                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-
        

IP Fields:

IP字段:

Source Address MUST be the link-local address assigned to the interface from which this message is sent.

源地址必须是分配给发送此消息的接口的链路本地地址。

Destination Address The Source Address of the packet that triggered the redirect.

目标地址触发重定向的数据包的源地址。

Hop Limit 255

跃点限制255

ICMP Fields:

ICMP字段:

Type 137

137型

Code 0

代码0

Checksum The ICMP checksum. See [ICMPv6].

校验和ICMP校验和。见[ICMPv6]。

Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.

保留此字段未使用。发送方必须将其初始化为零,接收方必须忽略它。

Target Address An IP address that is a better first hop to use for the ICMP Destination Address. When the target is the actual endpoint of communication, i.e., the destination is a neighbor, the Target Address field MUST contain the same value as the ICMP Destination Address field. Otherwise, the target is a better first-hop router and the Target Address MUST be the router's link-local address so that hosts can uniquely identify routers.

目标地址一个IP地址,它是ICMP目标地址使用的更好的第一跳。当目标是通信的实际端点,即目标是邻居时,目标地址字段必须包含与ICMP目标地址字段相同的值。否则,目标是更好的第一跳路由器,并且目标地址必须是路由器的链路本地地址,以便主机能够唯一地识别路由器。

Destination Address The IP address of the destination that is redirected to the target.

目标地址重定向到目标的目标的IP地址。

Possible options:

可能的选择:

Target link-layer address The link-layer address for the target. It SHOULD be included (if known). Note that on NBMA links, hosts may rely on the presence of the Target Link-Layer Address option in Redirect messages as the means for determining the link-layer addresses of neighbors. In such cases, the option MUST be included in Redirect messages.

目标链路层地址目标的链路层地址。它应该包括在内(如果知道的话)。注意,在NBMA链路上,主机可能依赖重定向消息中存在的目标链路层地址选项作为确定邻居链路层地址的手段。在这种情况下,该选项必须包含在重定向消息中。

Redirected Header As much as possible of the IP packet that triggered the sending of the Redirect without making the redirect packet exceed the minimum MTU specified in [IPv6].

在不使重定向数据包超过[IPv6]中规定的最小MTU的情况下,尽可能多地使用触发重定向发送的IP数据包的重定向报头。

4.6. Option Formats
4.6. 选项格式

Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. Options should be padded when necessary to ensure that they end on their natural 64-bit boundaries. All options are of the form:

邻居发现消息包含零个或多个选项,其中一些选项可能在同一消息中多次出现。必要时应填充选项,以确保它们在其自然64位边界上结束。所有选项的形式如下:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |              ...              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                              ...                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
        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数据包。

4.6.1. Source/Target Link-layer Address
4.6.1. 源/目标链路层地址
      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 ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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]。

Link-Layer Address The variable length link-layer address.

链路层地址可变长度链路层地址。

The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER].

该字段的内容和格式(包括字节和位顺序)预计将在描述IPv6如何在不同链路层上运行的特定文档中指定。例如,[IPv6以太]。

Description The Source Link-Layer Address option contains the link-layer address of the sender of the packet. It is used in the Neighbor Solicitation, Router Solicitation, and Router Advertisement packets.

说明源链路层地址选项包含数据包发送方的链路层地址。它用于邻居请求、路由器请求和路由器广告数据包。

The Target Link-Layer Address option contains the link-layer address of the target. It is used in Neighbor Advertisement and Redirect packets.

目标链路层地址选项包含目标的链路层地址。它用于邻居播发和重定向数据包。

These options MUST be silently ignored for other Neighbor Discovery messages.

对于其他邻居发现消息,必须忽略这些选项。

4.6.2. Prefix Information
4.6.2. 前缀信息
       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                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |L|A| Reserved1 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Preferred Lifetime                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved2                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Prefix                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Fields:

领域:

Type 3

类型3

Length 4

长度4

Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The prefix length field provides necessary information for on-link determination (when combined with the L flag in the prefix information option). It also assists with address autoconfiguration as specified in [ADDRCONF], for which there may be more restrictions on the prefix length.

前缀长度为8位无符号整数。前缀中有效的前导位数。该值的范围为0到128。prefix length字段为链路上的确定提供必要的信息(与prefix information(前缀信息)选项中的L标志组合时)。它还有助于[ADDRCONF]中指定的地址自动配置,对于地址自动配置,前缀长度可能有更多限制。

L 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the L flag is not set a host MUST NOT conclude that an address derived from the prefix is off-link. That is, it MUST NOT update a previous indication that the address is on-link.

链接标志上的1位。设置时,表示此前缀可用于链路上的确定。未设置时,播发不会对前缀的链接上或链接下属性进行任何声明。换句话说,如果未设置L标志,则主机不得断定从前缀派生的地址是断开链接的。也就是说,它不能更新地址在链接上的先前指示。

A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for stateless address configuration as specified in [ADDRCONF].

1位自治地址配置标志。When set表示此前缀可用于[ADDRCONF]中指定的无状态地址配置。

Reserved1 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.

保留1个6位未使用字段。发送方必须将其初始化为零,接收方必须忽略它。

Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. The Valid Lifetime is also used by [ADDRCONF].

有效的生存期32位无符号整数。前缀在链路确定中有效的时间长度(相对于发送数据包的时间),以秒为单位。所有一位的值(0xFFFFFF)表示无穷大。[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]。所有一位的值(0xFFFFFF)表示无穷大。见[ADDRCONF]。

Note that the value of this field MUST NOT exceed the Valid Lifetime field to avoid preferring addresses that are no longer valid.

请注意,此字段的值不得超过有效生存期字段,以避免首选不再有效的地址。

Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.

保留2此字段未使用。发送方必须将其初始化为零,接收方必须忽略它。

Prefix An IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. A router SHOULD NOT send a prefix option for the link-local prefix and a host SHOULD ignore such a prefix option.

为IP地址或IP地址的前缀添加前缀。前缀长度字段包含前缀中的有效前导位数。前缀长度后的前缀中的位是保留的,发送方必须将其初始化为零,接收方则忽略。路由器不应为链路本地前缀发送前缀选项,主机应忽略此类前缀选项。

Description The Prefix Information option provide hosts with on-link prefixes and prefixes for Address Autoconfiguration. The Prefix Information option appears in Router Advertisement packets and MUST be silently ignored for other messages.

说明前缀信息选项为主机提供链接前缀和地址自动配置前缀。前缀信息选项出现在路由器广告数据包中,对于其他消息,必须忽略该选项。

4.6.3. Redirected Header
4.6.3. 重定向标头
       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                        ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       IP header + data                        ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Fields:

领域:

Type 4

类型4

Length The length of the option in units of 8 octets.

长度以8个八位字节为单位的选项长度。

Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.

保留这些字段未使用。发送方必须将它们初始化为零,接收方必须忽略它们。

IP header + data The original packet truncated to ensure that the size of the redirect message does not exceed the minimum MTU required to support IPv6 as specified in [IPv6].

IP标头+数据原始数据包被截断,以确保重定向消息的大小不超过[IPv6]中指定的支持IPv6所需的最小MTU。

Description The Redirected Header option is used in Redirect messages and contains all or part of the packet that is being redirected.

说明重定向头选项用于重定向消息,包含被重定向的全部或部分数据包。

This option MUST be silently ignored for other Neighbor Discovery messages.

对于其他邻居发现消息,必须忽略此选项。

4.6.4. MTU
4.6.4. MTU
       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                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              MTU                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Fields:

领域:

Type 5

类型5

Length 1

长度1

Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.

保留此字段未使用。发送方必须将其初始化为零,接收方必须忽略它。

MTU 32-bit unsigned integer. The recommended MTU for the link.

MTU 32位无符号整数。链接的推荐MTU。

Description The MTU option is used in Router Advertisement messages to ensure that all nodes on a link use the same MTU value in those cases where the link MTU is not well known.

说明MTU选项用于路由器公告消息,以确保链路上的所有节点在链路MTU未知的情况下使用相同的MTU值。

This option MUST be silently ignored for other Neighbor Discovery messages.

对于其他邻居发现消息,必须忽略此选项。

In configurations in which heterogeneous technologies are bridged together, the maximum supported MTU may differ from one segment to another. If the bridges do not generate ICMP Packet Too Big messages, communicating nodes will be unable to use Path MTU to dynamically determine the appropriate MTU on a per-neighbor basis. In such cases, routers can be configured to use the MTU option to specify the maximum MTU value that is supported by all segments.

在异构技术桥接在一起的配置中,不同网段支持的最大MTU可能不同。如果网桥没有生成过大的ICMP数据包消息,则通信节点将无法使用路径MTU来根据每个邻居动态确定适当的MTU。在这种情况下,路由器可以配置为使用MTU选项指定所有段支持的最大MTU值。

5. Conceptual Model of a Host
5. 主机的概念模型

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.

本节描述一个可能的数据结构组织的概念模型,主机(在某种程度上,路由器)将在与相邻节点交互时维护该组织。提供所描述的组织是为了便于解释邻居发现协议应该如何工作。本文档并不要求实现遵守此模型,只要其外部行为与本文档中描述的一致。

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.

该模型只关注与邻居发现直接相关的主机行为方面。特别是,它不涉及源地址选择或多主机上传出接口的选择等问题。

5.1. Conceptual Data Structures
5.1. 概念数据结构

Hosts will need to maintain the following pieces of information for each interface:

主机需要为每个接口维护以下信息:

Neighbor Cache - A set of entries about individual neighbors to which traffic has been sent recently. Entries are keyed on the neighbor's on-link unicast IP address and contain such information as its link-layer address, a flag indicating whether the neighbor is a router or a host (called IsRouter in this document), a pointer to any queued packets waiting for address resolution to complete, etc. A Neighbor Cache entry also contains information used by the Neighbor Unreachability Detection algorithm, including the reachability state, the number of unanswered probes, and the time the next Neighbor Unreachability Detection event is scheduled to take place.

邻居缓存-一组关于最近向其发送流量的单个邻居的条目。条目键入邻居的链路上单播IP地址,并包含以下信息:其链路层地址、指示邻居是路由器还是主机的标志(在本文档中称为IsRouter)、指向等待地址解析完成的任何排队数据包的指针、,等。邻居缓存条目还包含邻居不可访问性检测算法使用的信息,包括可访问性状态、未响应探测的数量以及计划发生下一个邻居不可访问性检测事件的时间。

Destination Cache - A set of entries about destinations to which traffic has been sent recently. The Destination Cache includes both on-link and off-link destinations and provides a level of indirection into the Neighbor Cache; the Destination Cache maps a destination IP address to the IP address of the next-hop neighbor. This cache is updated with information learned from Redirect messages. Implementations may find it convenient to store additional information not directly related to Neighbor Discovery in Destination Cache entries, such as the Path MTU (PMTU) and round-trip timers maintained by transport protocols.

目的地缓存-一组关于最近已向其发送流量的目的地的条目。目的地高速缓存包括链路上和链路外的目的地,并向邻居高速缓存提供一定程度的间接寻址;目标缓存将目标IP地址映射到下一跳邻居的IP地址。此缓存使用从重定向消息中获取的信息进行更新。实现可能会发现将与邻居发现不直接相关的附加信息存储在目标缓存条目中很方便,例如路径MTU(PMTU)和由传输协议维护的往返计时器。

Prefix List - A list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created from information received in Router Advertisements. Each entry has an associated invalidation timer value (extracted from the advertisement) used to expire prefixes when they become invalid. A special "infinity" timer value specifies that a prefix remains valid forever, unless a new (finite) value is received in a subsequent advertisement.

前缀列表-定义链接上一组地址的前缀列表。前缀列表条目是根据路由器广告中接收到的信息创建的。每个条目都有一个关联的失效计时器值(从公告中提取),用于在前缀失效时使其过期。特殊的“无限”计时器值指定前缀永远有效,除非在后续播发中接收到新的(有限)值。

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.

链路本地前缀被视为在前缀列表上,具有无限失效计时器,无论路由器是否为其播发前缀。收到的路由器播发不应修改链路本地前缀的无效计时器。

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.

请注意,可以使用多种技术实现上述概念数据结构。一种可能的实现是对上述所有数据结构使用单个最长匹配路由表。无论具体实现如何,路由器的邻居缓存项必须由使用该路由器的所有目标缓存项共享,以防止冗余的邻居不可达性检测探测。

Note also that other protocols (e.g., Mobile IPv6) might add additional conceptual data structures. An implementation is at liberty to implement such data structures in any way it pleases. For example, an implementation could merge all conceptual data structures into a single routing table.

还请注意,其他协议(如移动IPv6)可能会添加额外的概念数据结构。实现可以自由地以任何方式实现此类数据结构。例如,一个实现可以将所有概念数据结构合并到一个路由表中。

The Neighbor Cache contains information maintained by the Neighbor Unreachability Detection algorithm. A key piece of information is a neighbor's reachability state, which is one of five possible values. The following definitions are informal; precise definitions can be found in Section 7.3.2.

邻居缓存包含由邻居不可达性检测算法维护的信息。关键信息是邻居的可达性状态,这是五个可能值之一。以下定义是非正式的;精确定义见第7.3.2节。

INCOMPLETE Address resolution is in progress and the link-layer address of the neighbor has not yet been determined.

正在进行不完整的地址解析,尚未确定邻居的链路层地址。

REACHABLE Roughly speaking, the neighbor is known to have been reachable recently (within tens of seconds ago).

粗略地说,我们知道邻居最近(在几十秒内)是可以联系到的。

STALE The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability.

过时邻居不再被认为是可访问的,但在将流量发送给邻居之前,不应尝试验证其可访问性。

DELAY The neighbor is no longer known to be reachable, and traffic has recently been sent to the neighbor. Rather than probe the neighbor immediately, however, delay sending probes for a short while in order to give upper-layer protocols a chance to provide reachability confirmation.

延迟邻居不再知道是可到达的,并且最近已向邻居发送通信量。然而,与其立即探测邻居,不如将发送探测延迟一段时间,以便给上层协议提供提供可达性确认的机会。

PROBE The neighbor is no longer known to be reachable, and unicast Neighbor Solicitation probes are being sent to verify reachability.

探测邻居不再是可到达的,正在发送单播邻居请求探测以验证可到达性。

5.2. Conceptual Sending Algorithm
5.2. 概念发送算法

When sending a packet to a destination, a node uses a combination of the Destination Cache, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop, an operation known as "next-hop determination". Once the IP address of the next hop is known, the Neighbor Cache is consulted for link-layer information about that neighbor.

当向目的地发送数据包时,节点使用目的地缓存、前缀列表和默认路由器列表的组合来确定适当下一跳的IP地址,这一操作称为“下一跳确定”。一旦知道下一跳的IP地址,就会查询邻居缓存以获取有关该邻居的链路层信息。

Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6).

给定单播目的地的下一跳确定操作如下。发送方根据前缀列表执行最长前缀匹配,以确定数据包的目的地是开链还是断链。如果目的地在链路上,则下一跳地址与数据包的目的地地址相同。否则,发送方将从默认路由器列表中选择一个路由器(遵循第6.3.6节中描述的规则)。

For efficiency reasons, next-hop determination is not performed on every packet that is sent. Instead, the results of next-hop determination computations are saved in the Destination Cache (which also contains updates learned from Redirect messages). When the sending node has a packet to send, it first examines the Destination Cache. If no entry exists for the destination, next-hop determination is invoked to create a Destination Cache entry.

出于效率原因,不会对发送的每个数据包执行下一跳确定。相反,下一跳确定计算的结果保存在目标缓存中(该缓存还包含从重定向消息中学习到的更新)。当发送节点有数据包要发送时,它首先检查目标缓存。如果目标不存在条目,则调用下一跳确定以创建目标缓存条目。

Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. For multicast-capable interfaces Address Resolution consists of sending a Neighbor Solicitation message and waiting for a Neighbor Advertisement. When a Neighbor Advertisement response is received, the link-layer addresses is entered in the Neighbor Cache entry and the queued packet is transmitted. The address resolution mechanism is described in detail in Section 7.2.

一旦知道下一跳节点的IP地址,发送方将检查邻居缓存中有关该邻居的链路层信息。如果不存在条目,发送方将创建一个条目,将其状态设置为“未完成”,启动地址解析,然后将数据包排队等待地址解析完成。对于支持多播的接口,地址解析包括发送邻居请求消息和等待邻居公告。当接收到邻居播发响应时,在邻居缓存条目中输入链路层地址,并发送排队的数据包。第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以太])上操作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.

路由器和多宿主主机有多个接口。本文档的其余部分假设所有发送和接收的邻居发现消息都引用了相应上下文的接口。例如,当响应路由器请求时,相应的路由器广告被发送到接收请求的接口。

5.3. Garbage Collection and Timeout Requirements
5.3. 垃圾收集和超时要求

The conceptual data structures described above use different mechanisms for discarding potentially stale or unused information.

上述概念数据结构使用不同的机制来丢弃可能过时或未使用的信息。

From the perspective of correctness, there is no need to periodically purge Destination and Neighbor Cache entries. Although stale information can potentially remain in the cache indefinitely, the Neighbor Unreachability Detection algorithm ensures that stale information is purged quickly if it is actually being used.

从正确性的角度来看,不需要定期清除目标和邻居缓存项。尽管过时信息可能会无限期地保留在缓存中,但邻居不可访问性检测算法可确保过时信息在实际使用时被快速清除。

To limit the storage needed for the Destination and Neighbor Caches, a node may need to garbage-collect old entries. However, care must be taken to ensure that sufficient space is always present to hold the working set of active entries. A small cache may result in an excessive number of Neighbor Discovery messages if entries are discarded and rebuilt in quick succession. Any Least Recently Used (LRU)-based policy that only reclaims entries that have not been used

为了限制目标缓存和邻居缓存所需的存储,节点可能需要对旧条目进行垃圾收集。但是,必须注意确保始终存在足够的空间来容纳活动条目的工作集。如果条目被丢弃并快速连续重建,则小缓存可能会导致邻居发现消息数量过多。任何基于最近最少使用(LRU)的策略,仅回收未使用的条目

in some time (e.g., ten minutes or more) should be adequate for garbage-collecting unused entries.

在一段时间内(例如,十分钟或更长时间),垃圾收集未使用的条目应该足够了。

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.

节点应保留默认路由器列表和前缀列表中的条目,直到其生存期到期。但是,如果节点内存不足,它可能会过早地对条目进行垃圾收集。如果并非所有路由器都保留在默认路由器列表中,则节点应在默认路由器列表中保留至少两个条目(最好更多),以便为断开链路的目的地保持健壮的连接。

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.

从前缀列表中删除条目时,无需从目标缓存或邻居缓存中清除任何条目。邻居不可访问性检测将有效地清除这些缓存中已失效的任何条目。但是,当从默认路由器列表中删除条目时,目标缓存中通过该路由器的任何条目都必须再次执行下一跳确定以选择新的默认路由器。

6. Router and Prefix Discovery
6. 路由器和前缀发现

This section describes router and host behavior related to the Router Discovery portion of Neighbor Discovery. Router Discovery is used to locate neighboring routers as well as learn prefixes and configuration parameters related to stateless address autoconfiguration.

本节描述与邻居发现的路由器发现部分相关的路由器和主机行为。路由器发现用于定位相邻路由器,以及学习与无状态地址自动配置相关的前缀和配置参数。

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

6.1. Message Validation
6.1. 消息验证
6.1.1. Validation of Router Solicitation Messages
6.1.1. 路由器请求消息的验证

Hosts MUST silently discard any received Router Solicitation Messages.

主机必须以静默方式丢弃任何收到的路由器请求消息。

A router MUST silently discard any received Router Solicitation messages that do not satisfy all of the following validity checks:

路由器必须以静默方式丢弃未满足以下所有有效性检查的任何收到的路由器请求消息:

- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.

- IP跃点限制字段的值为255,即数据包不可能由路由器转发。

- ICMP Checksum is valid.

- ICMP校验和有效。

- ICMP Code is 0.

- ICMP代码为0。

- ICMP length (derived from the IP length) is 8 or more octets.

- ICMP长度(源自IP长度)为8个或更多个八位字节。

- All included options have a length that is greater than zero.

- 所有包含的选项的长度都大于零。

- If the IP source address is the unspecified address, there is no source link-layer address option in the message.

- 如果IP源地址是未指定的地址,则消息中没有源链接层地址选项。

The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.

必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项;向后不兼容的更改可能使用不同的代码值。

The contents of any defined options that are not specified to be used with Router Solicitation messages MUST be ignored and the packet processed as normal. The only defined option that may appear is the Source Link-Layer Address option.

必须忽略未指定用于路由器请求消息的任何已定义选项的内容,并按正常方式处理数据包。唯一可能出现的定义选项是源链接层地址选项。

A solicitation that passes the validity checks is called a "valid solicitation".

通过有效性检查的邀约称为“有效邀约”。

6.1.2. Validation of Router Advertisement Messages
6.1.2. 路由器广告消息的验证

A node MUST silently discard any received Router Advertisement messages that do not satisfy all of the following validity checks:

节点必须以静默方式丢弃任何接收到的不满足以下所有有效性检查的路由器播发消息:

- IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers.

- IP源地址是链接本地地址。路由器必须使用其链路本地地址作为路由器广告和重定向消息的源,以便主机能够唯一地标识路由器。

- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.

- IP跃点限制字段的值为255,即数据包不可能由路由器转发。

- ICMP Checksum is valid.

- ICMP校验和有效。

- ICMP Code is 0.

- ICMP代码为0。

- ICMP length (derived from the IP length) is 16 or more octets.

- ICMP长度(源自IP长度)为16个或更多八位字节。

- All included options have a length that is greater than zero.

- 所有包含的选项的长度都大于零。

The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.

必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项;向后不兼容的更改可能使用不同的代码值。

The contents of any defined options that are not specified to be used with Router Advertisement messages MUST be ignored and the packet processed as normal. The only defined options that may appear are the Source Link-Layer Address, Prefix Information and MTU options.

必须忽略未指定用于路由器广告消息的任何已定义选项的内容,并按正常方式处理数据包。可能出现的唯一定义选项是源链路层地址、前缀信息和MTU选项。

An advertisement that passes the validity checks is called a "valid advertisement".

通过有效性检查的广告称为“有效广告”。

6.2. Router Specification
6.2. 路由器规范
6.2.1. Router Configuration Variables
6.2.1. 路由器配置变量

A router MUST allow for the following conceptual variables to be configured by system management. The specific variable names are used for demonstration purposes only, and an implementation is not required to have them, so long as its external behavior is consistent with that described in this document. Default values are specified to simplify configuration in common cases.

路由器必须允许系统管理配置以下概念变量。特定的变量名仅用于演示目的,只要其外部行为与本文档中描述的一致,实现不需要它们。指定默认值以简化常见情况下的配置。

The default values for some of the variables listed below may be overridden by specific documents that describe how IPv6 operates over different link layers. This rule simplifies the configuration of Neighbor Discovery over link types with widely differing performance characteristics.

下面列出的某些变量的默认值可能会被描述IPv6如何在不同链路层上运行的特定文档覆盖。此规则简化了在性能特征差异很大的链路类型上进行邻居发现的配置。

For each interface:

对于每个接口:

IsRouter A flag indicating whether routing is enabled on this interface. Enabling routing on the interface would imply that a router can forward packets to or from the interface.

IsRouter一个标志,指示是否在此接口上启用路由。在接口上启用路由意味着路由器可以向接口转发数据包或从接口转发数据包。

Default: FALSE

默认值:FALSE

AdvSendAdvertisements A flag indicating whether or not the router sends periodic Router Advertisements and responds to Router Solicitations.

AdvSendAdvertisions一个标志,指示路由器是否定期发送路由器广告并响应路由器请求。

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.

请注意,默认情况下AdvSendAdvertisions必须为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 If MaxRtrAdvInterval >= 9 seconds; otherwise, the Default is MaxRtrAdvInterval.

默认值:如果MaxRtrAdvInterval>=9秒,则为0.33*MaxRtrAdvInterval;否则,默认值为MaxRtrAdvInterval。

AdvManagedFlag The TRUE/FALSE value to be placed in the "Managed address configuration" flag field in the Router Advertisement. See [ADDRCONF].

AdvManagedFlag路由器公告中“托管地址配置”标志字段中要放置的真/假值。见[ADDRCONF]。

Default: FALSE

默认值:FALSE

AdvOtherConfigFlag The TRUE/FALSE value to be placed in the "Other configuration" flag field in the Router Advertisement. See [ADDRCONF].

AdvOtherConfigFlag要放置在路由器公告的“其他配置”标志字段中的真/假值。见[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).

AdvReachable Time要放置在路由器发送的路由器广告消息中的Reachable Time字段中的值。值0表示未指定(此路由器)。必须不大于3600000毫秒(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).

advrestimer由路由器发送的路由器广告消息中要放置在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 the current diameter of the Internet. The value zero means unspecified (by this router).

AdvCurHopLimit路由器发送的路由器广告消息中放置在Cur-Hop Limit字段中的默认值。该值应设置为Internet的当前直径。值0表示未指定(此路由器)。

Default: The value specified in the "Assigned Numbers" [ASSIGNED] that was in effect at the time of implementation.

默认值:在实施时生效的“已分配编号”[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. These limits may be overridden by specific documents that describe how IPv6 operates over different link layers. For instance, in a point-to-point link the peers may have enough information about the number and status of devices at the other end so that advertisements are needed less frequently.

AdvDefaultLifetime从接口发送的路由器广告的路由器生存期字段中要放置的值,以秒为单位。必须为零或介于MaxRtrAdvInterval和9000秒之间。值为零表示路由器不用作默认路由器。这些限制可能会被描述IPv6如何在不同链路层上运行的特定文档所覆盖。例如,在点到点链路中,对等方可以具有关于另一端的设备的数量和状态的足够信息,从而减少广告的需要频率。

Default: 3 * MaxRtrAdvInterval

默认值:3*MaxRtrAdvInterval

AdvPrefixList A list of prefixes to be placed in Prefix Information options in Router Advertisement messages sent from the interface.

AdvPrefixList从接口发送的路由器广告消息中,要放置在前缀信息选项中的前缀列表。

Default: all prefixes that the router advertises via routing protocols as being on-link for the interface from which the advertisement is sent. The link-local prefix SHOULD NOT be included in the list of advertised prefixes.

默认值:路由器通过路由协议播发的所有前缀都位于发送播发的接口的链路上。链接本地前缀不应包含在播发前缀列表中。

Each prefix has an associated:

每个前缀都有一个关联的:

AdvValidLifetime The value to be placed in the Valid Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. Implementations MAY allow AdvValidLifetime to be specified in two ways:

AdvValidLifetime要放置在前缀信息选项的有效生存期中的值,以秒为单位。所有1的指定值(0xffffffff)表示无穷大。实现可能允许通过两种方式指定AdvValidLifetime:

- 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要放置在前缀信息选项中的on link flag(“L位”)字段中的值。

Default: TRUE

默认值:TRUE

Stateless address configuration [ADDRCONF] defines additional information associated with each of the prefixes:

无状态地址配置[ADDRCONF]定义了与每个前缀相关的附加信息:

AdvPreferredLifetime The value to be placed in the Preferred Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. See [ADDRCONF] for details on how this value is used. Implementations MAY allow AdvPreferredLifetime to be specified in two ways:

AdvPreferredLifetime要放入前缀信息选项中首选生存期的值,以秒为单位。所有1的指定值(0xffffffff)表示无穷大。有关如何使用此值的详细信息,请参见[ADDRCONF]。实现可能允许通过两种方式指定AdvPreferredLifetime:

- a time that decrements in real time, that is, one that will result in a Lifetime of zero at a specified time in the future, or

- 实时递减的时间,也就是说,在将来的某个特定时间,将导致寿命为零的时间,或

- a fixed time that stays the same in consecutive advertisements.

- 在连续广告中保持不变的固定时间。

Default: 604800 seconds (7 days), fixed (i.e., stays the same in consecutive advertisements). This value MUST NOT be larger than AdvValidLifetime.

默认值:604800秒(7天),固定(即在连续广告中保持不变)。此值不得大于AdvValidLifetime。

AdvAutonomousFlag The value to be placed in the Autonomous Flag field in the Prefix Information option. See [ADDRCONF].

要放置在“自主标志”选项中的“自主标志”值字段中。见[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

上述变量包含放置在传出路由器广告消息中的信息。主机使用收到的信息初始化一组控制其外部行为的类似变量(见第6.3.2节)。其中一些主机变量(例如CurHopLimit、renstimer和ReachableTime)适用于包括路由器在内的所有节点。实际上,这些变量可能并不存在于路由器上,因为它们的内容可以从

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节中所述的可达时间值的偶然随机化。

Protocol constants are defined in Section 10.

协议常数在第10节中定义。

6.2.2. Becoming an Advertising Interface
6.2.2. 成为广告界面

The term "advertising interface" refers to any functioning and enabled interface that has at least one unicast IP address assigned to it and whose corresponding AdvSendAdvertisements flag is TRUE. A router MUST NOT send Router Advertisements out any interface that is not an advertising interface.

术语“广告接口”是指任何功能正常且启用的接口,该接口至少有一个单播IP地址分配给它,且其相应的AdvSendAdvertisions标志为TRUE。路由器不得将路由器广告发送出任何非广告接口的接口。

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

- 将已启用接口上的AdvSendAdvertisions标志从FALSE更改为TRUE,或

- administratively enabling the interface, if it had been administratively disabled, and its AdvSendAdvertisements flag is TRUE, or

- 以管理方式启用接口(如果已以管理方式禁用),且其AdvSendAdvertisions标志为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.

- 当接口的AdvSendAdvertisions标志为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.

路由器必须加入广告接口上的所有路由器多播地址。路由器响应发送到所有路由器地址的路由器请求,并验证相邻路由器发送的路由器广告的一致性。

6.2.3. Router Advertisement Message Content
6.2.3. 路由器广告消息内容

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.

- 在M和O标志中:分别配置接口的AdvManagedFlag和AdvOtherConfigFlag。

- In the Cur Hop Limit field: the interface's configured CurHopLimit.

- 在Cur-Hop Limit字段中:接口配置的curhopflimit。

- In the Reachable Time field: the interface's configured AdvReachableTime.

- 在可达时间字段中:接口配置的AdvReachable时间。

- In the Retrans Timer field: the interface's configured AdvRetransTimer.

- 在Retrans Timer字段中:接口配置的AdvRetrantimer。

- In the options:

- 在选项中:

o Source Link-Layer Address option: link-layer address of the sending interface. This option MAY be omitted to facilitate in-bound load balancing over replicated interfaces.

o 源链路层地址选项:发送接口的链路层地址。可以省略此选项,以便在复制接口上实现绑定内负载平衡。

o MTU option: the interface's configured AdvLinkMTU value if the value is non-zero. If AdvLinkMTU is zero, the MTU option is not sent.

o MTU选项:如果值不为零,则接口配置的AdvLinkMTU值。如果LINKMTU为not sent,则LINKMTU选项为not sent。

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 “前缀为”选项中的“前缀为”列示了“前缀为”选项中的“前缀为”字段中的“前缀为”信息:

- In the "on-link" flag: the entry's AdvOnLinkFlag.

- 在“on link”标志中:条目的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.

- 在首选生存期字段中:条目的AdvPreferredLifetime。

A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise prefixes for stateless address autoconfiguration while not wishing to forward packets. Such a router sets the Router Lifetime field in outgoing advertisements to zero.

路由器可能希望发送路由器播发,而不将自身作为默认路由器播发。例如,路由器可能会为无状态地址自动配置播发前缀,而不希望转发数据包。这样的路由器将传出广告中的路由器生存期字段设置为零。

A router MAY choose not to include some or all options when sending unsolicited Router Advertisements. For example, if prefix lifetimes are much longer than AdvDefaultLifetime, including them every few advertisements may be sufficient. However, when responding to a Router Solicitation or while sending the first few initial

当发送未经请求的路由器广告时,路由器可以选择不包括部分或全部选项。例如,如果前缀生存时间远长于AdvDefaultLifetime,则每隔几次播发就包含它们就足够了。但是,在响应路由器请求或发送前几个初始

unsolicited advertisements, a router SHOULD include all options so that all information (e.g., prefixes) is propagated quickly during system initialization.

未经请求的广告,路由器应包括所有选项,以便在系统初始化期间快速传播所有信息(例如前缀)。

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,则可以发送多个播发,每个播发包含选项的子集。

6.2.4. Sending Unsolicited Router Advertisements
6.2.4. 发送未经请求的路由器广告

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]。每个广告界面都有自己的计时器。无论何时,只要将RADVINTERVAL配置为RADVINTERVAL和RTVAL之间的RADVINTERVAL接口的RADVINTERVAL被均匀地分配到RADVINTERVAL;计时器过期会导致发送下一个广告并选择一个新的随机值。

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_广告),如果随机选择的间隔大于MAX_INITIAL_RTR_Adverted_interval,则应将计时器设置为MAX_INITIAL_RTR_Adverted_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_播发未经请求的播发,使用与界面成为广告界面时相同的规则。

6.2.5. Ceasing To Be an Advertising Interface
6.2.5. 不再是广告界面

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

- 将已启用接口的AdvSendAdvertisions标志从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 ensure that subsequent Neighbor Advertisement messages sent from the interface have the Router flag set to zero.

在这种情况下,路由器应在路由器生存期字段为零的接口上传输一个或多个(但不超过MAX_FINAL_RTR_advisions)最终多播路由器广告。在路由器成为主机的情况下,系统还应在路由器支持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转发能力(即,将系统从路由器更改为主机),这一步骤并不一定意味着路由器的接口不再是广告接口。在这种情况下,后续路由器广告必须将路由器生存期字段设置为零。

6.2.6. Processing Router Solicitations
6.2.6. 处理路由器请求

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秒之间的随机时间。(如果发送单个播发以响应多个请求,则延迟相对于第一次请求。)此外,发送到所有节点多播地址的连续路由器播发的速率必须限制为在两秒之间每分钟延迟不超过一个播发。

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到最大延迟时间范围内的随机延迟。如果计算出的值对应于比计划发送下一个多播路由器广告的时间晚的时间,则忽略随机延迟并在已经计划的时间发送广告。

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

- 如果路由器在\u-RAS秒之间的最后一个MIN\u延迟\u内发送了多播路由器广告(请求的或未请求的),则将广告安排在与\u-RAS之间的MIN\u延迟\u加上前一个广告发送后的随机值相对应的时间发送。这确保了多播路由器广告的速率受限。

- Otherwise, schedule the sending of a Router Advertisement at the time given by the random value.

- 否则,在随机值给定的时间安排路由器广告的发送。

Note that a router is permitted to send multicast Router Advertisements more frequently than indicated by the MinRtrAdvInterval configuration variable so long as the more frequent advertisements are responses to Router Solicitations. In all cases, however, unsolicited multicast advertisements MUST NOT be sent more frequently than indicated by MinRtrAdvInterval.

请注意,允许路由器发送多播路由器播发的频率高于MinRtrAdvInterval配置变量所指示的频率,只要更频繁的播发是对路由器请求的响应。然而,在所有情况下,未经请求的多播广告发送的频率不得超过MinRtrAdvInterval的指示。

Router Solicitations in which the Source Address is the unspecified address MUST NOT update the router's Neighbor Cache; solicitations with a proper source address update the Neighbor Cache as follows. If the router already has a Neighbor Cache entry for the solicitation's sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, then the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE. If there is no existing Neighbor Cache entry for the solicitation's sender, the router creates one, installs the link- layer address and sets its reachability state to STALE as specified in Section 7.3.3. If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a multicast or a unicast router advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE.

源地址为未指定地址的路由器请求不得更新路由器的邻居缓存;具有正确源地址的请求会如下更新邻居缓存。如果路由器已经为请求的发送方提供了一个邻居缓存条目,请求包含一个源链路层地址选项,并且接收到的链路层地址与缓存中已有的地址不同,则应在相应的邻居缓存条目中更新链路层地址,并且它的可达性状态也必须设置为STALE。如果请求的发送方没有现有的邻居缓存条目,路由器将创建一个,安装链路层地址,并按照第7.3.3节的规定将其可达性状态设置为STALE。如果不存在现有的邻居缓存条目,并且请求中不存在源链路层地址选项,则路由器可以使用多播或单播路由器公告进行响应。无论是否提供源链路层地址选项,如果请求发送方的邻居缓存条目存在(或已创建),则该条目的IsRouter标志必须设置为FALSE。

6.2.7. Router Advertisement Consistency
6.2.7. 路由器广告一致性

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:

路由器应检查其他路由器发送的有效路由器广告,并验证路由器在链路上广告的信息是否一致。检测到的不一致表示一个或多个路由器可能配置错误,应记录到系统或网络管理。要检查的最小信息集包括:

- Cur Hop Limit values (except for the unspecified value of zero other inconsistencies SHOULD be logged to system network management).

- Cur-Hop限制值(除未指定的零值外,其他不一致应记录到系统网络管理)。

- Values of the M or O flags.

- M或O标志的值。

- Reachable Time values (except for the unspecified value of zero).

- 可到达的时间值(未指定的值零除外)。

- Retrans Timer values (except for the unspecified value of zero).

- 重新传输计时器值(未指定的零值除外)。

- Values in the MTU options.

- MTU选项中的值。

- Preferred and Valid Lifetimes for the same prefix. If AdvPreferredLifetime and/or AdvValidLifetime decrement in real time as specified in Section 6.2.1 then the comparison of the lifetimes cannot compare the content of the fields in the Router Advertisement, but must instead compare the time at which the prefix will become deprecated and invalidated, respectively. Due to link propagation delays and potentially poorly synchronized clocks between the routers such comparison SHOULD allow some time skew.

- 相同前缀的首选和有效生存期。如果第6.2.1节中规定的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.

请注意,不同的路由器播发不同的前缀集不是错误的。此外,一些路由器可能会将某些字段保留为未指定字段,即值为零,而其他路由器则指定值。错误的记录应限于冲突信息,这些信息会导致主机在每次接收到播发时从一个值切换到另一个值。

Any other action on reception of Router Advertisement messages by a router is beyond the scope of this document.

路由器接收路由器广告消息的任何其他行动超出本文件的范围。

6.2.8. Link-local Address Change
6.2.8. 链接本地地址更改

The link-local address on a router should rarely change, if ever. Nodes receiving Neighbor Discovery messages use the source address to identify the sender. If multiple packets from the same router contain different source addresses, nodes will assume they come from different routers, leading to undesirable behavior. For example, a

路由器上的链路本地地址应该很少改变(如果有的话)。接收邻居发现消息的节点使用源地址来标识发送方。如果来自同一路由器的多个数据包包含不同的源地址,节点将假定它们来自不同的路由器,从而导致不良行为。例如,一个

node will ignore Redirect messages that are believed to have been sent by a router other than the current first-hop router. Thus, the source address used in Router Advertisements sent by a particular router must be identical to the target address in a Redirect message when redirecting to that router.

节点将忽略被认为是由当前第一跳路由器以外的路由器发送的重定向消息。因此,由特定路由器发送的路由器广告中使用的源地址必须与重定向到该路由器时重定向消息中的目标地址相同。

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.

如果路由器更改其接口之一的链路本地地址,则应将此更改通知主机。路由器应该在路由器生存期字段设置为零的情况下,从旧的链路本地地址多播几个路由器广告,并且也从新的链路本地地址多播几个路由器广告。整体效果应与一个界面不再是广告界面,而另一个界面开始成为广告界面的效果相同。

6.3. Host Specification
6.3. 主机规格
6.3.1. Host Configuration Variables
6.3.1. 主机配置变量

None.

没有一个

6.3.2. Host Variables
6.3.2. 主变量

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

链接MTU链接的MTU。默认值:特定文档中定义的值,用于描述IPv6如何在特定链路层上运行(例如,[IPv6以太])。

CurHopLimit The default hop limit to be used when sending IP packets.

CurHopLimit发送IP数据包时使用的默认跃点限制。

Default: The value specified in the "Assigned Numbers" [ASSIGNED] that was in effect at the time of implementation.

默认值:在实施时生效的“已分配编号”[Assigned]中指定的值。

BaseReachableTime A base value used for computing the random ReachableTime value.

BaseReachableTime用于计算随机可达时间值的基值。

Default: REACHABLE_TIME milliseconds.

默认值:可达时间毫秒。

ReachableTime The time a neighbor is considered reachable after receiving a reachability confirmation.

可达时间邻居在收到可达性确认后被视为可达的时间。

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.

该值应为最小随机因子和最大随机因子乘以BaseAccessable Time毫秒之间的均匀分布随机值。当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.

Renstimer解析地址或探测邻居的可达性时,将邻居请求消息重新传输到邻居之间的时间。

Default: RETRANS_TIMER milliseconds

默认值:重新传输\u计时器毫秒

6.3.3. Interface Initialization
6.3.3. 接口初始化

The host joins the all-nodes multicast address on all multicast-capable interfaces.

主机在所有支持多播的接口上加入所有节点多播地址。

6.3.4. Processing Received Router Advertisements
6.3.4. 处理收到的路由器广告

When multiple routers are present, the information advertised collectively by all routers may be a superset of the information contained in a single Router Advertisement. Moreover, information may also be obtained through other dynamic means like DHCPv6. Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. However, when received information for a specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently received information is considered authoritative.

当存在多个路由器时,由所有路由器共同通告的信息可以是包含在单个路由器通告中的信息的超集。此外,还可以通过其他动态手段(如DHCPv6)获得信息。主机接受所有接收到的信息的联合;路由器公告的接收不得使先前公告或从其他来源接收的所有信息无效。然而,当接收到的特定参数(例如,链路MTU)或选项(例如,特定前缀上的生存期)的信息与先前接收到的信息不同,并且参数/选项只能有一个值时,最近接收到的信息被认为是权威的。

A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, and Retrans Timer) may contain a value denoting that it is unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using. In particular, a host MUST NOT interpret the unspecified value as meaning change back to the default value that was in use before the first Router Advertisement was received. This rule prevents hosts from continually changing an internal variable when one router advertises a specific value, but other routers advertise the unspecified value.

路由器广告字段(例如,Cur-Hop Limit、Reachable Time和Retrans Timer)可能包含一个表示未指定的值。在这种情况下,应忽略该参数,主机应继续使用其已使用的任何值。特别是,主机不得将未指定的值解释为意味着更改回在接收到第一个路由器公告之前正在使用的默认值。当一个路由器播发特定值,而其他路由器播发未指定值时,此规则防止主机不断更改内部变量。

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

列表上的路由器越多,就越有可能快速找到替代工作路由器(例如,无需等待下一个广告到达)。

If the received Cur Hop Limit value is non-zero, the host SHOULD set its CurHopLimit variable to the received value.

如果接收到的Cur-Hop Limit值非零,主机应将其curhopflimit变量设置为接收到的值。

If the received Reachable Time value is non-zero, the host SHOULD set its BaseReachableTime variable to the received value. If the new value differs from the previous value, the host SHOULD re-compute a new random ReachableTime value. ReachableTime is computed as a uniformly distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR times the BaseReachableTime. Using a random component eliminates the possibility that Neighbor Unreachability Detection messages will synchronize with each other.

如果接收到的可到达时间值非零,则主机应将其BaseReachableTime变量设置为接收到的值。如果新值与以前的值不同,主机应重新计算新的随机可达时间值。可达时间计算为最小随机因子和最大随机因子乘以基本可达时间之间的均匀分布随机值。使用随机组件消除了邻居不可达性检测消息相互同步的可能性。

In most cases, the advertised Reachable Time value will be the same in consecutive Router Advertisements, and a host's BaseReachableTime rarely changes. In such cases, an implementation SHOULD ensure that a new random value gets re-computed at least once every few hours.

在大多数情况下,在连续的路由器播发中,播发的可到达时间值将是相同的,并且主机的基本可到达时间很少改变。在这种情况下,实现应该确保至少每隔几个小时重新计算一次新的随机值。

The RetransTimer variable SHOULD be copied from the Retrans Timer field, if the received value is non-zero.

如果接收到的值非零,则应从Retrans Timer字段复制Retrans Timer变量。

After extracting information from the fixed part of the Router Advertisement message, the advertisement is scanned for valid options. If the advertisement contains a Source Link-Layer Address option, the link-layer address SHOULD be recorded in the Neighbor Cache entry for the router (creating an entry if necessary) and the IsRouter flag in the Neighbor Cache entry MUST be set to TRUE. If no Source Link-Layer Address is included, but a corresponding Neighbor Cache entry exists, its IsRouter flag MUST be set to TRUE. The IsRouter flag is used by Neighbor Unreachability Detection to determine when a router changes to being a host (i.e., no longer capable of forwarding packets). If a Neighbor Cache entry is created for the router, its reachability state MUST be set to STALE as specified in Section 7.3.3. If a cache entry already exists and is updated with a different link-layer address, the reachability state MUST also be set to STALE.

从路由器广告消息的固定部分提取信息后,将扫描广告以查找有效选项。如果播发包含源链路层地址选项,则链路层地址应记录在路由器的邻居缓存条目中(必要时创建条目),并且邻居缓存条目中的IsRouter标志必须设置为TRUE。如果不包括源链路层地址,但存在相应的邻居缓存项,则其ISRUTER标志必须设置为TRUE。邻居不可达性检测使用ISRUTER标志来确定路由器何时变为主机(即不再能够转发数据包)。如果为路由器创建了邻居缓存条目,则其可达性状态必须设置为STALE,如第7.3.3节所述。如果缓存项已存在,并使用不同的链路层地址更新,则还必须将可达性状态设置为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 maximum LinkMTU value specified in the link-type-specific document (e.g., [IPv6-ETHER]).

如果存在MTU选项,主机应将该选项的值复制到LinkMTU中,只要该值大于或等于最小链路MTU[IPv6],且不超过链路类型特定文档(例如[IPv6])中指定的最大链路MTU值。

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

设置了“on link”(L)标志的前缀信息选项表示一个前缀,该前缀标识应在链接上考虑的地址范围。但是,请注意,前缀信息选项

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

当on-link标志设置为零时,不会传递关于on-link确定的任何信息,并且不得被解释为表示前缀所涵盖的地址是断开链接的。取消以前的链路上指示的唯一方法是使用L位集和生存期设置为零来公布该前缀。将数据包发送至地址的默认行为(见第5.2节)是将数据包转发至默认路由器,该地址的链路状态信息未知;接收“on link”(L)标志设置为零的前缀信息选项不会改变此行为。第2.1节“链接上”的定义中规定了将地址视为链接上的原因。将on-link标志设置为零的前缀通常会设置自治标志,并由[ADDRCONF]使用。

For each Prefix Information option with the on-link flag set, a host does the following:

对于设置了on link标志的每个前缀信息选项,主机执行以下操作:

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

- 如果“前缀信息”选项的“有效生存期”字段为零,并且主机的前缀列表中不存在该前缀,请以静默方式忽略该选项。

Stateless address autoconfiguration [ADDRCONF] may in some circumstances use a larger Valid Lifetime of a prefix or ignore it completely in order to prevent a particular denial-of-service attack. However, since the effect of the same denial of service targeted at the on-link prefix list is not catastrophic (hosts would send packets to a default router and receive a redirect rather than sending packets directly to a neighbor), the Neighbor Discovery protocol does not impose such a check on the prefix lifetime values. Similarly, [ADDRCONF] may impose certain restrictions on the prefix length for address configuration purposes. Therefore, the prefix might be rejected by [ADDRCONF] implementation in the host. However, the

无状态地址自动配置[ADDRCONF]在某些情况下可能会使用前缀的更大有效生存期或完全忽略它,以防止特定的拒绝服务攻击。然而,由于针对链路上前缀列表的相同拒绝服务的影响不是灾难性的(主机将向默认路由器发送数据包并接收重定向,而不是直接向邻居发送数据包),因此邻居发现协议不对前缀生存期值施加这样的检查。类似地,[ADDRCONF]可能出于地址配置目的对前缀长度施加某些限制。因此,主机中的[ADDRCONF]实现可能会拒绝前缀。但是,

prefix length is still valid for on-link determination when combined with other flags in the prefix option.

当与prefix选项中的其他标志结合使用时,prefix length对于链路上的确定仍然有效。

Note: Implementations can choose to process the on-link aspects of the prefixes separately from the stateless address autoconfiguration aspects of the prefixes by, e.g., passing a copy of each valid Router Advertisement message to both an "on-link" and an "addrconf" function. Each function can then operate independently on the prefixes that have the appropriate flag set.

注意:实现可以选择分别处理前缀的链路上方面和前缀的无状态地址自动配置方面,例如,将每个有效路由器广告消息的副本传递给“链路上”和“addrconf”函数。然后,每个函数都可以在设置了相应标志的前缀上独立运行。

6.3.5. Timing out Prefixes and Default Routers
6.3.5. 超时前缀和默认路由器

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.

每当默认路由器列表中某个条目的生存期到期时,该条目将被丢弃。从默认路由器列表中删除路由器时,节点必须更新目标缓存,以使所有使用路由器的条目再次执行下一跳确定,而不是继续向(已删除的)路由器发送流量。

6.3.6. Default Router Selection
6.3.6. 默认路由器选择

The algorithm for selecting a router depends in part on whether or not a router is known to be reachable. The exact details of how a node keeps track of a neighbor's reachability state are covered in Section 7.3. The algorithm for selecting a default router is invoked during next-hop determination when no Destination Cache entry exists for an off-link destination or when communication through an existing router appears to be failing. Under normal conditions, a router would be selected the first time traffic is sent to a destination, with subsequent traffic for that destination using the same router as indicated in the Destination Cache modulo any changes to the Destination Cache caused by Redirect messages.

选择路由器的算法部分取决于路由器是否已知可到达。第7.3节详细介绍了节点如何跟踪邻居的可达性状态。当断开链路的目的地不存在目的地缓存条目或通过现有路由器的通信出现故障时,在下一跳确定期间调用用于选择默认路由器的算法。在正常情况下,第一次将流量发送到目的地时将选择一个路由器,该目的地的后续流量将使用目的地缓存中指示的相同路由器,将重定向消息引起的对目的地缓存的任何更改模数化。

The policy for selecting routers from the Default Router List is as follows:

从默认路由器列表中选择路由器的策略如下:

1) Routers that are reachable or probably reachable (i.e., in any state other than INCOMPLETE) SHOULD be preferred over routers whose reachability is unknown or suspect (i.e., in the INCOMPLETE state, or for which no Neighbor Cache entry exists). Further implementation hints on default router selection when multiple equivalent routers are available are discussed in [LD-SHRE].

1) 与可达性未知或可疑(即,处于不完整状态或不存在邻居缓存项)的路由器相比,应优先选择可访问或可能可访问(即,处于非完整状态)的路由器。[LD-SHRE]中讨论了多个等效路由器可用时默认路由器选择的进一步实现提示。

2) When no routers on the list are known to be reachable or probably reachable, routers SHOULD be selected in a round-robin fashion, so that subsequent requests for a default router do not return the same router until all other routers have been selected.

2) 当列表中没有已知可访问或可能可访问的路由器时,应以循环方式选择路由器,以便在选择所有其他路由器之前,对默认路由器的后续请求不会返回同一路由器。

Cycling through the router list in this case ensures that all available routers are actively probed by the Neighbor Unreachability Detection algorithm. A request for a default router is made in conjunction with the sending of a packet to a router, and the selected router will be probed for reachability as a side effect.

在这种情况下,在路由器列表中循环可确保邻居不可达性检测算法主动探测所有可用路由器。在向路由器发送数据包的同时发出对默认路由器的请求,作为副作用,将探测所选路由器的可达性。

6.3.7. Sending Router Solicitations
6.3.7. 发送路由器请求

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_请求路由器请求消息,每个消息之间至少间隔RTR_请求秒。路由器请求可在以下任何事件后发送:

- The interface is initialized at system startup time.

- 接口在系统启动时初始化。

- The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management.

- 在临时接口出现故障或被系统管理暂时禁用后,将重新初始化接口。

- The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management.

- 通过系统管理关闭其IP转发功能,系统从路由器变为主机。

- The host attaches to a link for the first time.

- 主机第一次连接到链接。

- The host re-attaches to a link after being detached for some time.

- 主机在分离一段时间后重新连接到链接。

A host sends Router Solicitations to the all-routers multicast address. The IP source address is set to either one of the interface's unicast addresses or the unspecified address. The Source Link-Layer Address option SHOULD be set to the host's link-layer address, if the IP source address is not the unspecified address.

主机向所有路由器多播地址发送路由器请求。IP源地址设置为接口的单播地址之一或未指定的地址。如果IP源地址不是未指定的地址,则源链路层地址选项应设置为主机的链路层地址。

Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen

在主机发送初始请求之前,它应该将传输延迟0到MAX_RTR_requisition_delay之间的随机时间量。当多台主机同时在一条链路上启动时(如可能发生的情况),这有助于缓解拥塞

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.

从电源故障中恢复后。如果自接口(重新)启用(例如,作为重复地址检测[ADDRCONF]的一部分)以来,主机已经执行了随机延迟,则在发送第一条路由器请求消息之前无需再次延迟。

In some cases, the random delay MAY be omitted if necessary. For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine movement to new links. Hence, if a mobile node received link-layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation depending on the level of certainty of the link-layer hints, and it is outside the scope of this specification. Note that using this mechanism inappropriately (e.g., based on weak or transient indications) may result in Router Solicitation storms. Furthermore, simultaneous mobility of a large number of mobile nodes that use this mechanism can result in a large number of solicitations sent simultaneously.

在某些情况下,如有必要,可省略随机延迟。例如,使用[MIPv6]移动到新链路的移动节点需要尽快发现这种移动,以最大限度地减少由于拓扑移动的变化而导致的数据包丢失量。路由器请求为移动IPv6中的移动检测提供了一个有用的工具,因为它们允许移动节点确定到新链路的移动。因此,如果移动节点接收到指示可能已经发生移动的链路层信息,则它可以立即发送路由器请求,而不存在随机延迟。此类指示的强度应由移动节点的实现根据链路层提示的确定程度进行评估,并且不在本规范的范围内。请注意,不适当地使用此机制(例如,基于微弱或瞬态指示)可能会导致路由器请求风暴。此外,使用该机制的大量移动节点的同时移动性可导致同时发送大量请求。

Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs. Moreover, a host SHOULD send at least one solicitation in the case where an advertisement is received prior to having sent a solicitation. Responses to solicited advertisements may contain more information than unsolicited advertisements.

一旦主机发送路由器请求,并收到具有非零路由器生存期的有效路由器公告,主机必须停止在该接口上发送额外请求,直到下次发生上述事件之一。此外,如果在发送邀请函之前收到广告,主持人应至少发送一份邀请函。对征求广告的回复可能包含比未经请求的广告更多的信息。

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_请求请求,并且在发送最后一次请求后等待MAX_RTR_请求延迟秒后未收到任何路由器播发,则主机会得出结论认为链路上没有用于[ADDRCONF]的路由器。但是,如果路由器出现在链路上,主机将继续接收和处理路由器广告消息。

7. Address Resolution and Neighbor Unreachability Detection
7. 地址解析和邻居不可达性检测

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]指定的重复地址检测。特别是,重复地址检测发送邻居请求消息,其中未指定源地址以其自己的“暂定”地址为目标。此类消息触发已经使用该地址的节点以指示该地址正在使用的多播邻居播发进行响应。

7.1. Message Validation
7.1. 消息验证
7.1.1. Validation of Neighbor Solicitations
7.1.1. 邻居请求的验证

A node MUST silently discard any received Neighbor Solicitation messages that do not satisfy all of the following validity checks:

节点必须以静默方式丢弃未满足以下所有有效性检查的任何接收到的邻居请求消息:

- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.

- IP跃点限制字段的值为255,即数据包不可能由路由器转发。

- ICMP Checksum is valid.

- ICMP校验和有效。

- ICMP Code is 0.

- ICMP代码为0。

- ICMP length (derived from the IP length) is 24 or more octets.

- ICMP长度(源自IP长度)为24个或更多八位字节。

- Target Address is not a multicast address.

- 目标地址不是多播地址。

- All included options have a length that is greater than zero.

- 所有包含的选项的长度都大于零。

- If the IP source address is the unspecified address, the IP destination address is a solicited-node multicast address.

- 如果IP源地址是未指定的地址,则IP目标地址是请求的节点多播地址。

- If the IP source address is the unspecified address, there is no source link-layer address option in the message.

- 如果IP源地址是未指定的地址,则消息中没有源链接层地址选项。

The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.

必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项;向后不兼容的更改可能使用不同的代码值。

The contents of any defined options that are not specified to be used with Neighbor Solicitation messages MUST be ignored and the packet processed as normal. The only defined option that may appear is the Source Link-Layer Address option.

必须忽略未指定用于邻居请求消息的任何已定义选项的内容,并按正常方式处理数据包。唯一可能出现的定义选项是源链接层地址选项。

A Neighbor Solicitation that passes the validity checks is called a "valid solicitation".

通过有效性检查的邻居请求称为“有效请求”。

7.1.2. Validation of Neighbor Advertisements
7.1.2. 邻居广告的验证

A node MUST silently discard any received Neighbor Advertisement messages that do not satisfy all of the following validity checks:

节点必须以静默方式丢弃未满足以下所有有效性检查的任何接收到的邻居播发消息:

- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.

- IP跃点限制字段的值为255,即数据包不可能由路由器转发。

- ICMP Checksum is valid.

- ICMP校验和有效。

- ICMP Code is 0.

- ICMP代码为0。

- ICMP length (derived from the IP length) is 24 or more octets.

- ICMP长度(源自IP长度)为24个或更多八位字节。

- Target Address is not a multicast address.

- 目标地址不是多播地址。

- If the IP Destination Address is a multicast address the Solicited flag is zero.

- 如果IP目标地址是多播地址,则请求标志为零。

- All included options have a length that is greater than zero.

- 所有包含的选项的长度都大于零。

The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.

必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项;向后不兼容的更改可能使用不同的代码值。

The contents of any defined options that are not specified to be used with Neighbor Advertisement messages MUST be ignored and the packet processed as normal. The only defined option that may appear is the Target Link-Layer Address option.

必须忽略未指定用于相邻播发消息的任何已定义选项的内容,并按正常方式处理数据包。唯一可能出现的定义选项是目标链路层地址选项。

A Neighbor Advertisements that passes the validity checks is called a "valid advertisement".

通过有效性检查的邻居广告称为“有效广告”。

7.2. Address Resolution
7.2. 地址解析

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

地址解析是一个过程,通过该过程,节点仅在给定其IP地址的情况下确定邻居的链路层地址。地址解析仅在确定为在链路上且发送方不知道其对应地址的地址上执行

link-layer address (see Section 5.2). Address resolution is never performed on multicast addresses.

链路层地址(见第5.2节)。永远不会对多播地址执行地址解析。

It is possible that a host may receive a solicitation, a router advertisement, or a Redirect message without a link-layer address option included. These messages MUST NOT create or update neighbor cache entries, except with respect to the IsRouter flag as specified in Sections 6.3.4 and 7.2.5. If a Neighbor Cache entry does not exist for the source of such a message, Address Resolution will be required before unicast communications with that address can begin. This is particularly relevant for unicast responses to solicitations where an additional packet exchange is required for advertisement delivery.

主机可能在不包括链路层地址选项的情况下接收请求、路由器公告或重定向消息。除第6.3.4节和第7.2.5节规定的IsRouter标志外,这些消息不得创建或更新邻居缓存项。如果此类消息的源不存在邻居缓存项,则在开始使用该地址进行单播通信之前,需要进行地址解析。这对于请求的单播响应尤其相关,其中广告交付需要额外的分组交换。

7.2.1. Interface Initialization
7.2.1. 接口初始化

When a multicast-capable interface becomes enabled, the node MUST join the all-nodes multicast address on that interface, as well as the solicited-node multicast address corresponding to each of the IP addresses assigned to the interface.

启用支持多播的接口时,节点必须加入该接口上的所有节点多播地址,以及与分配给该接口的每个IP地址对应的请求节点多播地址。

The set of addresses assigned to an interface may change over time. New addresses might be added and old addresses might be removed [ADDRCONF]. In such cases the node MUST join and leave the solicited-node multicast address corresponding to the new and old addresses, respectively. Joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols. Note that multiple unicast addresses may map into the same solicited-node multicast address; a node MUST NOT leave the solicited-node multicast group until all assigned addresses corresponding to that multicast address have been removed.

分配给接口的地址集可能会随时间而变化。可以添加新地址,也可以删除旧地址[ADDRCONF]。在这种情况下,节点必须加入和离开分别对应于新地址和旧地址的请求节点多播地址。加入请求的节点多播地址是使用多播侦听器发现(如[MLD]或[MLDv2]协议)完成的。注意,多个单播地址可以映射到同一请求节点多播地址;在删除与该多播地址对应的所有分配地址之前,节点不得离开请求的节点多播组。

7.2.2. Sending Neighbor Solicitations
7.2.2. 发送邻居请求

When a node has a unicast packet to send to a neighbor, but does not know the neighbor's link-layer address, it performs address resolution. For multicast-capable interfaces, this entails creating a Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Solicitation message targeted at the neighbor. The solicitation is sent to the solicited-node multicast address corresponding to the target address.

当节点有要发送给邻居的单播数据包,但不知道邻居的链路层地址时,它会执行地址解析。对于支持多播的接口,这需要在不完整状态下创建邻居缓存条目,并发送针对该邻居的邻居请求消息。请求被发送到与目标地址对应的请求节点多播地址。

If the source address of the packet prompting the solicitation is the same as one of the addresses assigned to the outgoing interface, that address SHOULD be placed in the IP Source Address of the outgoing solicitation. Otherwise, any one of the addresses assigned to the interface should be used. Using the prompting packet's source address when possible ensures that the recipient of the Neighbor

如果提示请求的数据包的源地址与分配给传出接口的地址之一相同,则该地址应放在传出请求的IP源地址中。否则,应使用分配给接口的任何一个地址。尽可能使用提示包的源地址可确保邻居的收件人

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

请求在其邻居缓存中安装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.

如果请求被发送到请求节点多播地址,则发送方必须将其链路层地址(如果有)作为源链路层地址选项。否则,发送方应将其链接层地址(如果有)作为源链接层地址选项。需要将源链路层地址包括在多播请求中,以向目标提供其可以向其发送邻居广告的地址。在单播请求上,实现可以省略源链路层地址选项。这里的假设是,如果发送方的缓存中有对等方的链路层地址,则对等方也很可能在其缓存中有发送方的条目。因此,它不需要发送。

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.

在等待地址解析完成时,发送方必须为每个邻居保留一小队等待地址解析完成的数据包。队列必须至少包含一个数据包,并且可能包含更多数据包。但是,每个邻居排队的数据包数应限制在某个较小的值内。当队列溢出时,新到达的条目应替换最旧的条目。一旦地址解析完成,节点将传输任何排队的数据包。

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.

在等待响应时,发送方应该大约每重传一毫秒重传一次邻居请求消息,即使在没有向邻居发送额外通信量的情况下也是如此。重新传输的速率必须限制为每个邻居每重新传输毫秒最多一次请求。

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_Request请求之后未收到邻居播发,则地址解析失败。对于排队等待地址解析的每个数据包,发送方必须返回代码为3(地址不可达)的ICMP目的地不可达指示。

7.2.3. Receipt of Neighbor Solicitations
7.2.3. 收到邻居的邀约

A valid Neighbor Solicitation that does not meet any of the following requirements MUST be silently discarded:

不满足以下任何要求的有效邻居请求必须被自动放弃:

- The Target Address is a "valid" unicast or anycast address assigned to the receiving interface [ADDRCONF],

- 目标地址是分配给接收接口[ADDRCONF]的“有效”单播或选播地址,

- The Target Address is a unicast or anycast address for which the node is offering proxy service, or

- 目标地址是节点提供代理服务的单播或选播地址,或

- The Target Address is a "tentative" address on which Duplicate Address Detection is being performed [ADDRCONF].

- 目标地址是正在执行重复地址检测的“暂定”地址[ADDRCONF]。

If the Target Address is tentative, the Neighbor Solicitation should be processed as described in [ADDRCONF]. Otherwise, the following description applies. If the Source Address is not the unspecified address and, on link layers that have addresses, the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation. If an entry does not already exist, the node SHOULD create a new one and set its reachability state to STALE as specified in Section 7.3.3. If an entry already exists, and the cached link-layer address differs from the one in the received Source Link-Layer option, the cached address should be replaced by the received address, and the entry's reachability state MUST be set to STALE.

如果目标地址是暂定的,则应按照[ADDRCONF]中所述处理邻居请求。否则,以下描述适用。如果源地址不是未指定的地址,并且在具有地址的链路层上,请求包括源链路层地址选项,则收件人应为请求的IP源地址创建或更新邻居缓存条目。如果条目不存在,节点应创建一个新条目,并按照第7.3.3节的规定将其可达性状态设置为STALE。如果条目已存在,并且缓存的链接层地址与接收的源链接层选项中的地址不同,则缓存的地址应替换为接收的地址,并且条目的可访问性状态必须设置为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。即使邻居请求由路由器发送,情况也是如此,因为邻居请求消息不包含发送方是否为路由器的指示。如果发送方是路由器,后续的邻居播发或路由器播发消息将设置正确的IsRouter值。如果邻居缓存项已存在,则不得修改其IsRouter标志。

If the Source Address is the unspecified address, the node MUST NOT create or update the Neighbor Cache entry.

如果源地址是未指定的地址,则节点不得创建或更新邻居缓存项。

After any updates to the Neighbor Cache, the node sends a Neighbor Advertisement response as described in the next section.

在对邻居缓存进行任何更新之后,节点发送邻居播发响应,如下一节所述。

7.2.4. Sending Solicited Neighbor Advertisements
7.2.4. 发送请求邻居的广告

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.

节点发送邻居公告以响应针对节点的一个分配地址的有效邻居请求。广告的目标地址是从招标的目标地址复制而来的。如果请求的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".

如果目标地址是节点为其提供代理服务的选播地址或单播地址,或者不包括目标链路层地址选项,则覆盖标志应设置为零。否则,覆盖标志应设置为1。覆盖标志的正确设置可确保节点优先考虑非代理播发,即使在代理播发之后接收,并且还可确保选播地址的第一个播发“获胜”。

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秒之间的随机时间。

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

因为单播邻居请求不需要包括源链路层地址,所以发送请求的邻居播发的节点可能在其邻居缓存中没有其邻居的对应链路层地址。在这种情况下,节点首先必须使用邻居发现来确定其邻居的链路层地址(即,发送多播邻居请求)。

7.2.5. Receipt of Neighbor Advertisements
7.2.5. 收到邻居的广告

When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target.

当接收到有效的邻居播发(请求或未请求)时,将在邻居缓存中搜索目标的条目。如果不存在条目,则应悄悄地丢弃广告。如果不存在条目,则无需创建条目,因为收件人显然没有启动与目标的任何通信。

Once the appropriate Neighbor Cache entry has been located, the specific actions taken depend on the state of the Neighbor Cache entry, the flags in the advertisement, and the actual link-layer address supplied.

找到适当的邻居缓存项后,所采取的具体操作取决于邻居缓存项的状态、播发中的标志以及提供的实际链路层地址。

If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the link layer has addresses and no Target Link-Layer Address option is included, the receiving node SHOULD silently discard the received advertisement. Otherwise, the receiving node performs the following steps:

如果接收到播发时目标的邻居缓存项处于未完成状态,则会发生以下两种情况之一。如果链路层有地址,并且不包括目标链路层地址选项,则接收节点应静默地丢弃接收到的播发。否则,接收节点执行以下步骤:

- It records the link-layer address in the Neighbor Cache entry.

- 它的入口链接层记录它的邻居地址。

- If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE; otherwise, it is set to STALE.

- 如果设置了广告的请求标志,则条目的状态设置为可达;否则,它将设置为过时。

- It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement.

- 它根据接收到的播发中的路由器标志在缓存项中设置ISRUTER标志。

- It sends any packets queued for the neighbor awaiting address resolution.

- 它发送排队等待地址解析的邻居的任何数据包。

Note that the Override flag is ignored if the entry is in the INCOMPLETE state.

请注意,如果条目处于未完成状态,则忽略覆盖标志。

If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the following actions take place:

如果目标的邻居缓存项在接收播发时处于除“未完成”以外的任何状态,则会发生以下操作:

I. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: a. If the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way. b. Otherwise, the received advertisement should be ignored and MUST NOT update the cache.

I.如果覆盖标志清除,且提供的链路层地址与缓存中的地址不同,则会发生两个操作之一:a。如果条目的状态是可访问的,请将其设置为STALE,但不要以任何其他方式更新条目。B否则,应忽略接收到的播发,并且不得更新缓存。

II. If the Override flag is set, or the supplied link-layer address is the same as that in the cache, or no Target Link-Layer Address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows:

二、如果设置了覆盖标志,或提供的链路层地址与缓存中的地址相同,或未提供目标链路层地址选项,则接收到的播发必须按如下方式更新邻居缓存条目:

- The link-layer address in the Target Link-Layer Address option MUST be inserted in the cache (if one is supplied and differs from the already recorded address).

- “目标链路层地址”选项中的链路层地址必须插入缓存中(如果提供了一个且与已记录的地址不同)。

- If the Solicited flag is set, the state of the entry MUST be set to REACHABLE. If the Solicited flag is zero and the link-layer address was updated with a different address, the state MUST be set to STALE. Otherwise, the entry's state remains unchanged.

- 如果设置了请求标志,则条目的状态必须设置为可访问。如果请求标志为零,并且链接层地址已用其他地址更新,则状态必须设置为过时。否则,条目的状态保持不变。

An advertisement's Solicited flag should only be set if the advertisement is a response to a Neighbor Solicitation. Because Neighbor Unreachability Detection Solicitations are sent to the cached link-layer address, receipt of a solicited advertisement indicates that the forward path is working. Receipt of an unsolicited advertisement, however, may indicate that a neighbor has urgent information to announce (e.g., a

仅当广告是对邻居请求的响应时,才应设置广告的请求标志。因为邻居不可达性检测请求被发送到缓存的链路层地址,所以接收到请求的播发指示转发路径正在工作。然而,收到未经请求的广告可能表明邻居有紧急信息要宣布(例如

changed link-layer address). If the urgent information indicates a change from what a node is currently using, the node should verify the reachability of the (new) path when it sends the next packet. There is no need to update the state for unsolicited advertisements that do not change the contents of the cache.

更改了链路层地址)。如果紧急信息指示与节点当前使用的内容不同,则节点应在发送下一个数据包时验证(新)路径的可达性。不需要更新未经请求但不会更改缓存内容的播发的状态。

- The IsRouter flag in the cache entry MUST be set based on the Router flag in the received advertisement. In those cases where the IsRouter flag changes from TRUE to FALSE as a result of this update, the node MUST remove that router from the Default Router List and update the Destination Cache entries for all destinations using that neighbor as a router as specified in Section 7.3.3. This is needed to detect when a node that is used as a router stops forwarding packets due to being configured as a host.

- 缓存项中的ISRUTER标志必须根据接收到的播发中的路由器标志进行设置。在这些情况下,如果ISRUTER标志因此更新而从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.

上述规则确保在相邻播发优先(即设置了覆盖标志)或相邻播发引用当前记录在缓存中的相同链路层地址时更新缓存。如果上述任何一项都不适用,则播发通过更改缓存项中的状态来提示未来的邻居不可访问性检测(如果尚未进行)。

7.2.6. Sending Unsolicited Neighbor Advertisements
7.2.6. 发送未经请求的邻居广告

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_邻居_广告未经请求的邻居广告消息。这些播发必须至少间隔重新计时秒。

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;否则,它必须将其设置为零。覆盖标志可以设置为零或一。在任何一种情况下,相邻节点都会立即将其目标地址的邻居缓存项的状态更改为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地址的节点可以为每个地址多播单独的邻居播发。在这种情况下,节点应在每个广告的发送之间引入小的延迟,以减少广告由于拥塞而丢失的概率。

A proxy MAY multicast Neighbor Advertisements when its link-layer address changes or when it is configured (by system management or other mechanisms) to proxy for an address. If there are multiple nodes that are providing proxy services for the same set of addresses, the proxies should provide a mechanism that prevents multiple proxies from multicasting advertisements for any one address, in order to reduce the risk of excessive multicast traffic. This is a requirement on other protocols that need to use proxies for Neighbor Advertisements. An example of a node that performs proxy advertisements is the Home Agent specified in [MIPv6].

当代理的链路层地址发生变化或(通过系统管理或其他机制)配置为代理某个地址时,代理可以多播邻居播发。如果有多个节点为同一组地址提供代理服务,则代理应提供一种机制,防止多个代理对任何一个地址的播发进行多播,以降低过度多播流量的风险。这是需要为邻居播发使用代理的其他协议的要求。执行代理播发的节点示例是[MIPv6]中指定的归属代理。

Also, a node belonging to an anycast address MAY multicast unsolicited Neighbor Advertisements for the anycast address when the node's link-layer address changes.

此外,当节点的链路层地址改变时,属于选播地址的节点可以为该选播地址多播未经请求的邻居播发。

Note that because unsolicited Neighbor Advertisements do not reliably update caches in all nodes (the advertisements might not be received by all nodes), they should only be viewed as a performance optimization to quickly update the caches in most neighbors. The Neighbor Unreachability Detection algorithm ensures that all nodes obtain a reachable link-layer address, though the delay may be slightly longer.

请注意,由于未经请求的邻居播发不会可靠地更新所有节点中的缓存(可能并非所有节点都会接收到播发),因此它们只应被视为性能优化,以快速更新大多数邻居中的缓存。邻居不可达性检测算法确保所有节点获得可到达的链路层地址,尽管延迟可能稍长。

7.2.7. Anycast Neighbor Advertisements
7.2.7. 选播邻居广告

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.

将选播地址分配给接口的节点将其视为完全相同的单播地址,但有两个例外。首先,响应邻居请求而发送的邻居广告应延迟0到MAX_ANYCAST_DELAY_time之间的随机时间,以降低网络拥塞的概率。其次,邻居播发中的覆盖标志应设置为0,以便在接收到多个播发时,使用第一个接收到的播发,而不是最近接收到的播发。

As with unicast addresses, Neighbor Unreachability Detection ensures that a node quickly detects when the current binding for an anycast address becomes invalid.

与单播地址一样,邻居不可达性检测可确保节点在选播地址的当前绑定失效时快速检测。

7.2.8. Proxy Neighbor Advertisements
7.2.8. 代理邻居广告

Under limited circumstances, a router MAY proxy for one or more other nodes, that is, through Neighbor Advertisements indicate that it is willing to accept packets not explicitly addressed to itself. For example, a router might accept packets on behalf of a mobile node that has moved off-link. The mechanisms used by proxy are essentially the same as the mechanisms used with anycast addresses.

在有限的情况下,路由器可以代理一个或多个其他节点,也就是说,通过邻居广告表明它愿意接受未显式寻址到自身的分组。例如,路由器可能代表已脱离链路的移动节点接受数据包。代理使用的机制基本上与选播地址使用的机制相同。

A proxy MUST join the solicited-node multicast address(es) that correspond to the IP address(es) assigned to the node for which it is proxying. This SHOULD be done using a multicast listener discovery protocol such as [MLD] or [MLDv2].

代理必须加入请求的节点多播地址,该地址对应于为其代理的节点分配的IP地址。这应该使用多播侦听器发现协议(如[MLD]或[MLDv2])来完成。

All solicited proxy Neighbor Advertisement messages MUST have the Override flag set to zero. This ensures that if the node itself is present on the link, its Neighbor Advertisement (with the Override flag set to one) will take precedence of any advertisement received from a proxy. A proxy MAY send unsolicited advertisements with the Override flag set to one as specified in Section 7.2.6, but doing so may cause the proxy advertisement to override a valid entry created by the node itself.

所有请求的代理邻居播发消息的覆盖标志必须设置为零。这确保了如果节点本身存在于链路上,则其邻居播发(覆盖标志设置为1)将优先于从代理接收的任何播发。代理可以发送未经请求的广告,覆盖标志设置为第7.2.6节规定的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 to avoid collisions due to multiple responses sent by several proxies. However, in some cases (e.g., Mobile IPv6) where only one proxy is present, such delay is not necessary.

最后,当发送代理广告以响应邻居请求时,发送方应将其响应延迟0到MAX_ANYCAST_delay_time秒之间的随机时间,以避免由于多个代理发送的多个响应而导致的冲突。然而,在某些情况下(例如,移动IPv6),只有一个代理存在,这种延迟是不必要的。

7.3. Neighbor Unreachability Detection
7.3. 邻居不可达性检测

Communication to or through a neighbor may fail for numerous reasons at any time, including hardware failure, hot-swap of an interface card, etc. If the destination has failed, no recovery is possible and communication fails. On the other hand, if it is the path that has failed, recovery may be possible. Thus, a node actively tracks the reachability "state" for the neighbors to which it is sending packets.

与邻居或通过邻居进行的通信在任何时候都可能因多种原因而失败,包括硬件故障、接口卡热插拔等。如果目标发生故障,则无法恢复,通信也会失败。另一方面,如果是路径失败,则恢复是可能的。因此,节点主动跟踪其向其发送数据包的邻居的可达性“状态”。

Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent

邻居不可达性检测用于主机和相邻节点之间的所有路径,包括主机到主机、主机到路由器和路由器到主机的通信。路由器之间也可以使用邻居不可达性检测,但如果是等效的,则不需要

mechanism is available, for example, as part of the routing protocols.

该机制是可用的,例如,作为路由协议的一部分。

When a path to a neighbor appears to be failing, the specific recovery procedure depends on how the neighbor is being used. If the neighbor is the ultimate destination, for example, address resolution should be performed again. If the neighbor is a router, however, attempting to switch to another router would be appropriate. The specific recovery that takes place is covered under next-hop determination; Neighbor Unreachability Detection signals the need for next-hop determination by deleting a Neighbor Cache entry.

当指向邻居的路径出现故障时,具体的恢复过程取决于邻居的使用方式。例如,如果邻居是最终目的地,则应再次执行地址解析。但是,如果邻居是路由器,则尝试切换到另一个路由器是合适的。发生的特定恢复包含在下一跳确定中;邻居不可达性检测通过删除邻居缓存项来表示需要确定下一跳。

Neighbor Unreachability Detection is performed only for neighbors to which unicast packets are sent; it is not used when sending to multicast addresses.

仅对发送单播分组的邻居执行邻居不可达性检测;发送到多播地址时不使用它。

7.3.1. Reachability Confirmation
7.3.1. 可达性确认

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层接收到最近发送给邻居的数据包,则认为邻居是可到达的。可以通过两种方式收集肯定的确认信息:来自上层协议的提示,指示连接正在“向前进行”,或者接收作为对邻居请求消息的响应的邻居公告消息。

A connection makes "forward progress" if the packets received from a remote peer can only be arriving if recent packets sent to that peer are actually reaching it. In TCP, for example, receipt of a (new) acknowledgment indicates that previously sent data reached the peer. Likewise, the arrival of new (non-duplicate) data indicates that earlier acknowledgments are being delivered to the remote peer. If packets are reaching the peer, they must also be reaching the sender's next-hop neighbor; thus, "forward progress" is a confirmation that the next-hop neighbor is reachable. For off-link destinations, forward progress implies that the first-hop router is reachable. When available, this upper-layer information SHOULD be used.

如果从远程对等方接收到的数据包只有在发送到该对等方的最近数据包实际到达时才能到达,则连接才会“向前进行”。例如,在TCP中,收到(新)确认表示先前发送的数据到达对等方。类似地,新(非重复)数据的到达表示正在向远程对等方传递早期确认。如果数据包到达对等方,它们也必须到达发送方的下一跳邻居;因此,“向前进展”是确认下一跳邻居是可到达的。对于断开链路的目的地,转发进程意味着第一跳路由器是可到达的。如果可用,应使用此上层信息。

In some cases (e.g., UDP-based protocols and routers forwarding packets to hosts), such reachability information may not be readily available from upper-layer protocols. When no hints are available and a node is sending packets to a neighbor, the node actively probes the neighbor using unicast Neighbor Solicitation messages to verify that the forward path is still working.

在某些情况下(例如,基于UDP的协议和向主机转发数据包的路由器),这种可达性信息可能不容易从上层协议获得。当没有可用提示且节点正在向邻居发送数据包时,该节点使用单播邻居请求消息主动探测邻居,以验证转发路径是否仍在工作。

The receipt of a solicited Neighbor Advertisement serves as reachability confirmation, since advertisements with the Solicited flag set to one are sent only in response to a Neighbor Solicitation.

接收请求的邻居播发用作可达性确认,因为请求标志设置为1的播发仅在响应邻居请求时发送。

Receipt of other Neighbor Discovery messages, such as Router Advertisements and Neighbor Advertisement with the Solicited flag set to zero, MUST NOT be treated as a reachability confirmation. Receipt of unsolicited messages only confirms the one-way path from the sender to the recipient node. In contrast, Neighbor Unreachability Detection requires that a node keep track of the reachability of the forward path to a neighbor from its perspective, not the neighbor's perspective. Note that receipt of a solicited advertisement indicates that a path is working in both directions. The solicitation must have reached the neighbor, prompting it to generate an advertisement. Likewise, receipt of an advertisement indicates that the path from the sender to the recipient is working. However, the latter fact is known only to the recipient; the advertisement's sender has no direct way of knowing that the advertisement it sent actually reached a neighbor. From the perspective of Neighbor Unreachability Detection, only the reachability of the forward path is of interest.

其他邻居发现消息的接收,例如路由器播发和请求标志设置为零的邻居播发,不得视为可达性确认。收到未经请求的邮件仅确认从发件人到收件人节点的单向路径。相反,邻居不可达性检测要求节点从自己的角度而不是邻居的角度跟踪到邻居的前向路径的可达性。请注意,收到请求的广告表示路径在两个方向上工作。请求必须已到达邻居,促使其生成广告。同样,收到广告表明从发送者到接收者的路径正在工作。然而,后一事实仅为接收者所知;广告的发送者无法直接知道它发送的广告是否确实到达了邻居。从邻居不可达性检测的角度来看,只关注前向路径的可达性。

7.3.2. Neighbor Cache Entry States
7.3.2. 邻居缓存条目状态

A Neighbor Cache entry can be in one of five states:

邻居缓存项可以处于以下五种状态之一:

INCOMPLETE Address resolution is being performed on the entry. Specifically, a Neighbor Solicitation has been sent to the solicited-node multicast address of the target, but the corresponding Neighbor Advertisement has not yet been received.

正在对条目执行不完整的地址解析。具体地说,邻居请求已经发送到目标的请求节点多播地址,但是还没有接收到相应的邻居播发。

REACHABLE Positive confirmation was received within the last ReachableTime milliseconds that the forward path to the neighbor was functioning properly. While REACHABLE, no special action takes place as packets are sent.

在最近的可到达时间毫秒内收到可到达的肯定确认,确认到邻居的转发路径正常工作。虽然可以访问,但在发送数据包时不会发生特殊操作。

STALE More than ReachableTime milliseconds have elapsed since the last positive confirmation was received that the forward path was functioning properly. While stale, no action takes place until a packet is sent.

自收到前向路径正常运行的最后肯定确认以来,STALE已超过可到达时间毫秒。过时时,在发送数据包之前不会执行任何操作。

The STALE state is entered upon receiving an unsolicited Neighbor Discovery message that updates the cached link-layer address. Receipt of such a message does not confirm reachability, and entering the STALE state ensures reachability is verified quickly if the entry is actually being used. However, reachability is not actually verified until the entry is actually used.

当收到更新缓存链路层地址的未经请求的邻居发现消息时,将进入过时状态。收到这样的消息并不能确认可访问性,而进入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.

延迟自接收到前向路径正常运行的最后一次肯定确认,并且在最后一次延迟\u第一次\u探测\u时间秒内发送了一个数据包以来,已超过可到达时间毫秒。如果在进入延迟状态的DELAY_FIRST_PROBE_时间秒内未收到可达性确认,则发送邻居请求并将状态更改为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.

延迟状态是一种优化,它为上层协议提供额外的时间,以便在自上次确认以来由于缺少最近的通信量而经过可到达时间毫秒的情况下提供可到达性确认。如果没有这种优化,在流量暂停后打开TCP连接将启动探测,即使随后的三方握手将几乎立即提供可达性确认。

PROBE A reachability confirmation is actively sought by retransmitting Neighbor Solicitations every RetransTimer milliseconds until a reachability confirmation is received.

探测在接收到可达性确认之前,通过每隔重新传输毫秒重新传输邻居请求来主动寻找可达性确认。

7.3.3. Node Behavior
7.3.3. 节点行为

Neighbor Unreachability Detection operates in parallel with the sending of packets to a neighbor. While reasserting a neighbor's reachability, a node continues sending packets to that neighbor using the cached link-layer address. If no traffic is sent to a neighbor, no probes are sent.

邻居不可达性检测与向邻居发送数据包并行运行。在重新确定邻居的可达性时,节点继续使用缓存的链路层地址向该邻居发送数据包。如果没有向邻居发送流量,则不会发送探测。

When a node needs to perform address resolution on a neighboring address, it creates an entry in the INCOMPLETE state and initiates address resolution as specified in Section 7.2. If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that neighbor invokes the next-hop determination procedure again. Invoking next-hop determination at this point ensures that alternate default routers are tried.

当节点需要对相邻地址执行地址解析时,它会创建一个处于不完整状态的条目,并按照第7.2节的规定启动地址解析。如果地址解析失败,则应删除该条目,以便到该邻居的后续通信再次调用下一跳确定过程。在这一点上调用下一跳确定可确保尝试备用默认路由器。

When a reachability confirmation is received (either through upper-layer advice or a solicited Neighbor Advertisement), an entry's state changes to REACHABLE. The one exception is that upper-layer advice has no effect on entries in the INCOMPLETE state (e.g., for which no link-layer address is cached).

当接收到可达性确认(通过上层建议或请求的邻居公告)时,条目的状态变为可达。一个例外是,上层通知对处于不完整状态(例如,没有缓存链接层地址)的条目没有影响。

When ReachableTime milliseconds have passed since receipt of the last reachability confirmation for a neighbor, the Neighbor Cache entry's state changes from REACHABLE to STALE.

当自接收到邻居的上一次可达性确认后已过可达时间毫秒时,邻居缓存项的状态将从可达变为陈旧。

Note: An implementation may actually defer changing the state from REACHABLE to STALE until a packet is sent to the neighbor, i.e., there need not be an explicit timeout event associated with the expiration of ReachableTime.

注意:一个实现实际上可能延迟将状态从可到达更改为过时,直到一个数据包被发送到邻居,也就是说,不需要有与可到达时间到期相关的显式超时事件。

The first time a node sends a packet to a neighbor whose entry is STALE, the sender changes the state to DELAY and sets a timer to expire in DELAY_FIRST_PROBE_TIME seconds. If the entry is still in the DELAY state when the timer expires, the entry's state changes to PROBE. If reachability confirmation is received, the entry's state changes to REACHABLE.

当节点第一次向其条目过时的邻居发送数据包时,发送方将状态更改为DELAY,并将计时器设置为在DELAY_first_PROBE_时间秒内过期。如果计时器过期时条目仍处于延迟状态,则条目的状态更改为PROBE。如果收到可达性确认,条目的状态将更改为可达。

Upon entering the PROBE state, a node sends a unicast Neighbor Solicitation message to the neighbor using the cached link-layer address. While in the PROBE state, a node retransmits Neighbor Solicitation messages every RetransTimer milliseconds until reachability confirmation is obtained. Probes are retransmitted even if no additional packets are sent to the neighbor. If no response is received after waiting RetransTimer milliseconds after sending the MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry SHOULD be deleted. Subsequent traffic to that neighbor will recreate the entry and perform address resolution again.

进入探测状态后,节点使用缓存的链路层地址向邻居发送单播邻居请求消息。处于探测状态时,节点每隔一个重定时毫秒重新传输邻居请求消息,直到获得可达性确认。即使没有向邻居发送额外的数据包,也会重新传输探测。如果在发送MAX_UNICAST_请求请求后等待重新启动毫秒后未收到响应,则重新传输将停止,并应删除该条目。到该邻居的后续通信将重新创建条目并再次执行地址解析。

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.

请注意,所有邻居请求都是基于每个邻居的速率限制。节点向同一邻居发送邻居请求的频率不得超过每重新计时毫秒一次。

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,以提供指向新链路层地址的路径正在工作的提示验证。

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转发功能),节点必须将所有接收到的邻居播发消息中的路由器标志字段与邻居缓存条目中记录的ISRUTER标志相比较。当节点检测到邻居已从路由器变为主机时,节点必须从默认路由器列表中删除该路由器,并按照第6.3.5节所述更新目标缓存。请注意,即使目标缓存条目正在使用某个路由器(例如,主机被重定向到该路由器),该路由器也可能未列在默认路由器列表中。在这种情况下,引用(前)路由器的所有目标缓存项必须在使用该项之前再次执行下一跳确定。

In some cases, link-specific information may indicate that a path to a neighbor has failed (e.g., the resetting of a virtual circuit). In such cases, link-specific information may be used to purge Neighbor Cache entries before the Neighbor Unreachability Detection would do so. However, link-specific information MUST NOT be used to confirm the reachability of a neighbor; such information does not provide end-to-end confirmation between neighboring IP layers.

在某些情况下,链路特定信息可能指示到邻居的路径已失败(例如,虚拟电路的重置)。在这种情况下,链路特定信息可用于在邻居不可访问性检测之前清除邻居缓存条目。但是,链路特定信息不得用于确认邻居的可达性;此类信息不提供相邻IP层之间的端到端确认。

8. Redirect Function
8. 重定向功能

This section describes the functions related to the sending and processing of Redirect messages.

本节介绍与发送和处理重定向消息相关的功能。

Redirect messages are sent by routers to redirect a host to a better first-hop router for a specific destination or to inform hosts that a destination is in fact a neighbor (i.e., on-link). The latter is accomplished by having the ICMP Target Address be equal to the ICMP Destination Address.

重定向消息由路由器发送,用于将主机重定向到特定目的地的更好的第一跳路由器,或通知主机目的地实际上是邻居(即,在链路上)。后者通过使ICMP目标地址等于ICMP目标地址来实现。

A router MUST be able to determine the link-local address for each of its neighboring routers in order to ensure that the target address in a Redirect message identifies the neighbor router by its link-local address. For static routing, this requirement implies that the next-hop router's address should be specified using the link-local address of the router. For dynamic routing, this requirement implies that all IPv6 routing protocols must somehow exchange the link-local addresses of neighboring routers.

路由器必须能够确定其每个相邻路由器的链路本地地址,以确保重定向消息中的目标地址通过其链路本地地址标识相邻路由器。对于静态路由,此要求意味着下一跳路由器的地址应使用路由器的链路本地地址指定。对于动态路由,此要求意味着所有IPv6路由协议必须以某种方式交换相邻路由器的链路本地地址。

8.1. Validation of Redirect Messages
8.1. 验证重定向消息

A host MUST silently discard any received Redirect message that does not satisfy all of the following validity checks:

主机必须以静默方式放弃任何未满足以下所有有效性检查的接收重定向消息:

- IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers.

- IP源地址是链接本地地址。路由器必须使用其链路本地地址作为路由器广告和重定向消息的源,以便主机能够唯一地标识路由器。

- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.

- IP跃点限制字段的值为255,即数据包不可能由路由器转发。

- ICMP Checksum is valid.

- ICMP校验和有效。

- ICMP Code is 0.

- ICMP代码为0。

- ICMP length (derived from the IP length) is 40 or more octets.

- ICMP长度(源自IP长度)为40或更多个八位字节。

- The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address.

- 重定向的IP源地址与指定ICMP目标地址的当前第一跳路由器相同。

- The ICMP Destination Address field in the redirect message does not contain a multicast address.

- 重定向消息中的ICMP目标地址字段不包含多播地址。

- The ICMP Target Address is either a link-local address (when redirected to a router) or the same as the ICMP Destination Address (when redirected to the on-link destination).

- ICMP目标地址是链路本地地址(重定向到路由器时)或与ICMP目标地址相同(重定向到链路上目标时)。

- All included options have a length that is greater than zero.

- 所有包含的选项的长度都大于零。

The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.

必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项;向后不兼容的更改可能使用不同的代码值。

The contents of any defined options that are not specified to be used with Redirect messages MUST be ignored and the packet processed as normal. The only defined options that may appear are the Target Link-Layer Address option and the Redirected Header option.

必须忽略未指定用于重定向消息的任何已定义选项的内容,并按正常方式处理数据包。可能出现的唯一定义选项是目标链路层地址选项和重定向标头选项。

A host MUST NOT consider a redirect invalid just because the Target Address of the redirect is not covered under one of the link's prefixes. Part of the semantics of the Redirect message is that the Target Address is on-link.

主机不能考虑重定向无效,只是因为重定向的目标地址不在链接的前缀之一覆盖。重定向消息的部分语义是目标地址位于链接上。

A redirect that passes the validity checks is called a "valid redirect".

通过有效性检查的重定向称为“有效重定向”。

8.2. Router Specification
8.2. 路由器规范

A router SHOULD send a redirect message, subject to rate limiting, whenever it forwards a packet that is not explicitly addressed to itself (i.e., a packet that is not source routed through the router) in which:

路由器在转发未明确寻址到自身的数据包(即,未通过路由器进行源路由的数据包)时,应发送受速率限制的重定向消息,其中:

- the Source Address field of the packet identifies a neighbor, and

- 数据包的源地址字段标识邻居,以及

- the router determines (by means outside the scope of this specification) that a better first-hop node resides on the same link as the sending node for the Destination Address of the packet being forwarded, and

- 路由器确定(通过在本规范范围之外的方式)更好的第一跳节点驻留在与发送节点相同的链路上,用于转发的分组的目的地地址,以及

- the Destination Address of the packet is not a multicast address.

- 数据包的目标地址不是多播地址。

The transmitted redirect packet contains, consistent with the message format given in Section 4.5:

传输的重定向数据包包含以下内容,与第4.5节给出的消息格式一致:

- In the Target Address field: the address to which subsequent packets for the destination should be sent. If the target is a router, that router's link-local address MUST be used. If the target is a host, the target address field MUST be set to the same value as the Destination Address field.

- 在目标地址字段中:目标的后续数据包应发送到的地址。如果目标是路由器,则必须使用该路由器的链路本地地址。如果目标是主机,则目标地址字段必须设置为与目标地址字段相同的值。

- In the Destination Address field: the destination address of the invoking IP packet.

- 在Destination Address字段中:调用IP数据包的目标地址。

- In the options:

- 在选项中:

o Target Link-Layer Address option: link-layer address of the target, if known.

o 目标链接层地址选项:目标的链接层地址(如果已知)。

o Redirected Header: as much of the forwarded packet as can fit without the redirect packet exceeding the minimum MTU required to support IPv6 as specified in [IPv6].

o 重定向头:在重定向数据包不超过[IPv6]中规定的支持IPv6所需的最小MTU的情况下,尽可能多的转发数据包。

A router MUST limit the rate at which Redirect messages are sent, in order to limit the bandwidth and processing costs incurred by the Redirect messages when the source does not correctly respond to the Redirects, or the source chooses to ignore unauthenticated Redirect messages. More details on the rate-limiting of ICMP error messages can be found in [ICMPv6].

路由器必须限制重定向消息的发送速率,以便在源未正确响应重定向或源选择忽略未经验证的重定向消息时,限制重定向消息产生的带宽和处理成本。有关ICMP错误消息速率限制的更多详细信息,请参见[ICMPv6]。

A router MUST NOT update its routing tables upon receipt of a Redirect.

路由器在收到重定向后不得更新其路由表。

8.3. Host Specification
8.3. 主机规格

A host receiving a valid redirect SHOULD update its Destination Cache accordingly so that subsequent traffic goes to the specified target. If no Destination Cache entry exists for the destination, an implementation SHOULD create such an entry.

接收到有效重定向的主机应相应地更新其目标缓存,以便后续通信流向指定的目标。如果目标不存在目标缓存项,则实现应创建此类项。

If the redirect contains a Target Link-Layer Address option, the host either creates or updates the Neighbor Cache entry for the target. In both cases, the cached link-layer address is copied from the Target Link-Layer Address option. If a Neighbor Cache entry is created for the target, its reachability state MUST be set to STALE as specified in Section 7.3.3. If a cache entry already existed and it is updated with a different link-layer address, its reachability state MUST also be set to STALE. If the link-layer address is the same as that already in the cache, the cache entry's state remains unchanged.

如果重定向包含目标链路层地址选项,则主机将为目标创建或更新邻居缓存项。在这两种情况下,缓存的链路层地址都是从目标链路层地址选项复制的。如果为目标创建了邻居缓存项,则其可达性状态必须设置为STALE,如第7.3.3节所述。如果缓存项已经存在,并且已使用不同的链路层地址进行更新,则其可达性状态也必须设置为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。但是,如果目标地址和目标地址相同,则无法可靠地确定目标地址是否为路由器。因此,新创建的邻居缓存项应将ISRUTER标志设置为FALSE,而现有缓存项应保持该标志不变。如果目标是路由器,则后续的邻居播发或路由器播发消息将相应地更新IsRouter。

Redirect messages apply to all flows that are being sent to a given destination. That is, upon receipt of a Redirect for a Destination Address, all Destination Cache entries to that address should be updated to use the specified next-hop, regardless of the contents of the Flow Label field that appears in the Redirected Header option.

重定向消息适用于发送到给定目标的所有流。也就是说,在接收到目标地址的重定向后,应该更新该地址的所有目标缓存项以使用指定的下一跳,而不管重定向标头选项中显示的流标签字段的内容如何。

A host MUST NOT send Redirect messages.

主机不得发送重定向消息。

9. Extensibility - Option Processing
9. 可扩展性-选项处理

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

为了确保将来的扩展与当前实现正确共存,所有节点都必须默默地忽略它们在接收到的ND数据包中无法识别的任何选项,并继续处理该数据包。本文档中指定的所有选项都必须

recognized. A node MUST NOT ignore valid options just because the ND message contains unrecognized ones.

辨识。节点不能仅仅因为ND消息包含无法识别的选项而忽略有效选项。

The current set of options is defined in such a way that receivers can process multiple options in the same packet independently of each other. In order to maintain these properties, future options SHOULD follow the simple rule:

当前选项集以这样的方式定义,即接收机可以彼此独立地处理同一分组中的多个选项。为了维护这些属性,未来的选项应遵循以下简单规则:

The option MUST NOT depend on the presence or absence of any other options. The semantics of an option should depend only on the information in the fixed part of the ND packet and on the information contained in the option itself.

该选项不得取决于是否存在任何其他选项。选项的语义应仅取决于ND数据包固定部分中的信息以及包含在选项本身中的信息。

Adhering to the above rule has the following benefits:

遵守上述规则有以下好处:

1) Receivers can process options independently of one another. For example, an implementation can choose to process the Prefix Information option contained in a Router Advertisement message in a user-space process while the link-layer address option in the same message is processed by routines in the kernel.

1) 接收器可以独立于彼此处理选项。例如,实现可以选择在用户空间处理中处理路由器广告消息中包含的前缀信息选项,而同一消息中的链路层地址选项由内核中的例程处理。

2) Should the number of options cause a packet to exceed a link's MTU, multiple packets can carry subsets of the options without any change in semantics.

2) 如果选项的数量导致数据包超过链路的MTU,则多个数据包可以携带选项的子集,而不会改变语义。

3) Senders MAY send a subset of options in different packets. For instance, if a prefix's Valid and Preferred Lifetime are high enough, it might not be necessary to include the Prefix Information option in every Router Advertisement. In addition, different routers might send different sets of options. Thus, a receiver MUST NOT associate any action with the absence of an option in a particular packet. This protocol specifies that receivers should only act on the expiration of timers and on the information that is received in the packets.

3) 发送方可以在不同的数据包中发送选项子集。例如,如果前缀的有效和首选生存期足够高,则可能没有必要在每个路由器公告中包含前缀信息选项。此外,不同的路由器可能发送不同的选项集。因此,接收器不得将任何动作与特定分组中缺少选项相关联。该协议规定,接收方只应在计时器过期时以及在数据包中接收到的信息时才采取行动。

Options in Neighbor Discovery packets can appear in any order; receivers MUST be prepared to process them independently of their order. There can also be multiple instances of the same option in a message (e.g., Prefix Information options).

邻居发现包中的选项可以以任意顺序出现;接收者必须准备好独立于订单处理这些信息。消息中也可以有同一选项的多个实例(例如,前缀信息选项)。

If the number of included options in a Router Advertisement causes the advertisement's size to exceed the link MTU, the router can send multiple separate advertisements, each containing a subset of the options.

如果路由器广告中包含的选项的数量导致广告的大小超过链路MTU,则路由器可以发送多个单独的广告,每个广告包含选项的子集。

The amount of data to include in the Redirected Header option MUST be limited so that the entire redirect packet does not exceed the minimum MTU required to support IPv6 as specified in [IPv6].

必须限制要包含在重定向标头选项中的数据量,以便整个重定向数据包不超过[IPv6]中规定的支持IPv6所需的最小MTU。

All options are a multiple of 8 octets of length, ensuring appropriate alignment without any "pad" options. The fields in the options (as well as the fields in ND packets) are defined to align on their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit boundary) with the exception of the 128-bit IP addresses/prefixes, which are aligned on a 64-bit boundary. The link-layer address field contains an uninterpreted octet string; it is aligned on an 8-bit boundary.

所有选项都是8个八位字节长度的倍数,确保在没有任何“pad”选项的情况下进行适当对齐。选项中的字段(以及ND数据包中的字段)定义为在其自然边界上对齐(例如,16位字段在16位边界上对齐),但128位IP地址/前缀除外,它们在64位边界上对齐。链路层地址字段包含一个未解释的八位字节字符串;它在8位边界上对齐。

The size of an ND packet including the IP header is limited to the link MTU. When adding options to an ND packet, a node MUST NOT exceed the link MTU.

包括IP报头的ND分组的大小限于链路MTU。向ND数据包添加选项时,节点不得超过链路MTU。

Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.

此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们不识别的任何选项,并继续处理消息。

10. Protocol Constants
10. 协议常数

Router constants:

路由器常数:

MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds

最大初始广告间隔16秒

MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions

最大初始RTR广告3次传输

MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions

最多3次传输

MIN_DELAY_BETWEEN_RAS 3 seconds

3秒之间的最小延迟

MAX_RA_DELAY_TIME .5 seconds

最大延迟时间。5秒

Host constants:

主机常数:

MAX_RTR_SOLICITATION_DELAY 1 second

最大请求延迟1秒

RTR_SOLICITATION_INTERVAL 4 seconds

RTR_请求_间隔4秒

MAX_RTR_SOLICITATIONS 3 transmissions

最大请求3次传输

Node constants:

节点常数:

MAX_MULTICAST_SOLICIT 3 transmissions

最大多播请求3次传输

MAX_UNICAST_SOLICIT 3 transmissions

最大单播请求3次传输

MAX_ANYCAST_DELAY_TIME 1 second

最大选播延迟时间1秒

MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions

MAX_NEIGHBOR_广告3传输

REACHABLE_TIME 30,000 milliseconds

可达时间30000毫秒

RETRANS_TIMER 1,000 milliseconds

重新启动计时器1000毫秒

DELAY_FIRST_PROBE_TIME 5 seconds

延迟第一次探测时间5秒

MIN_RANDOM_FACTOR .5

最小随机系数

MAX_RANDOM_FACTOR 1.5

最大随机系数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如何在不同链路层上运行的特定文档覆盖。此规则允许邻居发现在性能特征差异很大的链路上运行。

11. Security Considerations
11. 安全考虑

Neighbor Discovery is subject to attacks that cause IP packets to flow to unexpected places. Such attacks can be used to cause denial of service but also allow nodes to intercept and optionally modify packets destined for other nodes. This section deals with the main threats related to Neighbor Discovery messages and possible security mechanisms that can mitigate these threats.

邻居发现会受到导致IP数据包流向意外位置的攻击。此类攻击可用于造成拒绝服务,但也允许节点截获和选择性修改发送给其他节点的数据包。本节讨论与邻居发现消息相关的主要威胁,以及可能缓解这些威胁的安全机制。

11.1. Threat Analysis
11.1. 威胁分析

This section discusses the main threats associated with Neighbor Discovery. A more detailed analysis can be found in [PSREQ]. The main vulnerabilities of the protocol fall under three categories:

本节讨论与邻居发现相关的主要威胁。更详细的分析可在[PSREQ]中找到。该协议的主要漏洞分为三类:

- Denial-of-Service (DoS) attacks. - Address spoofing attacks. - Router spoofing attacks.

- 拒绝服务(DoS)攻击。-地址欺骗攻击。-路由器欺骗攻击。

An example of denial of service attacks is that a node on the link that can send packets with an arbitrary IP source address can both advertise itself as a default router and also send "forged" Router Advertisement messages that immediately time out all other default routers as well as all on-link prefixes. An intruder can achieve this by sending out multiple Router Advertisements, one for each legitimate router, with the source address set to the address of another router, the Router Lifetime field set to zero, and the

拒绝服务攻击的一个例子是,链路上可以发送具有任意IP源地址的数据包的节点既可以将自身作为默认路由器进行公告,也可以发送“伪造”路由器公告消息,该消息会立即使所有其他默认路由器以及所有链路前缀超时。入侵者可以通过发送多个路由器广告来实现这一点,每个合法路由器一个,源地址设置为另一个路由器的地址,路由器生存期字段设置为零,以及

Preferred and Valid lifetimes set to zero for all the prefixes. Such an attack would cause all packets, for both on-link and off-link destinations, to go to the rogue router. That router can then selectively examine, modify, or drop all packets sent on the link. The Neighbor Unreachability Detection (NUD) will not detect such a black hole as long as the rogue router politely answers the NUD probes with a Neighbor Advertisement with the R-bit set.

所有前缀的首选有效生存期均设置为零。这样的攻击将导致链路上和链路外目的地的所有数据包都进入恶意路由器。然后,路由器可以有选择地检查、修改或丢弃链路上发送的所有数据包。邻居不可达性检测(NUD)不会检测到这样一个黑洞,只要恶意路由器礼貌地用R位设置的邻居广告回答NUD探测。

It is also possible for any host to launch a DoS attack on another host by preventing it from configuring an address using [ADDRCONF]. The protocol does not allow hosts to verify whether the sender of a Neighbor Advertisement is the true owner of the IP address included in the message.

任何主机也可能通过阻止它使用[ADDRCONF]配置地址,在另一台主机上发起DoS攻击。该协议不允许主机验证邻居播发的发送方是否是消息中包含的IP地址的真正所有者。

Redirect attacks can also be achieved by any host in order to flood a victim or steal its traffic. A host can send a Neighbor Advertisement (in response to a solicitation) that contains its IP address and a victim's link-layer address in order to flood the victim with unwanted traffic. Alternatively, the host can send a Neighbor Advertisement that includes a victim's IP address and its own link-layer address to overwrite an existing entry in the sender's destination cache, thereby forcing the sender to forward all of the victim's traffic to itself.

重定向攻击也可以由任何主机实现,以便淹没受害者或窃取其流量。主机可以发送包含其IP地址和受害者的链路层地址的邻居公告(响应请求),以便向受害者发送不需要的流量。或者,主机可以发送包括受害者的IP地址及其自己的链路层地址的邻居公告,以覆盖发送方的目的地缓存中的现有条目,从而迫使发送方将受害者的所有流量转发给自己。

The trust model for redirects is the same as in IPv4. A redirect is accepted only if received from the same router that is currently being used for that destination. If a host has been redirected to another node (i.e., the destination is on-link), there is no way to prevent the target from issuing another redirect to some other destination. However, this exposure is no worse than it was before being redirected; the target host, once subverted, could always act as a hidden router to forward traffic elsewhere.

重定向的信任模型与IPv4中的信任模型相同。仅当从当前用于该目的地的同一路由器接收到重定向时,才会接受重定向。如果主机已重定向到另一个节点(即,目的地在链路上),则无法阻止目标向其他目的地发出另一个重定向。然而,这种暴露并不比被重定向之前更糟糕;目标主机一旦被颠覆,就可以始终充当隐藏的路由器,将流量转发到其他地方。

The protocol contains no mechanism to determine which neighbors are authorized to send a particular type of message (e.g., Router Advertisements); any neighbor, presumably even in the presence of authentication, can send Router Advertisement messages thereby being able to cause denial of service. Furthermore, any neighbor can send proxy Neighbor Advertisements as well as unsolicited Neighbor Advertisements as a potential denial-of-service attack.

该协议不包含确定哪些邻居被授权发送特定类型的消息(例如,路由器广告)的机制;任何邻居,可能即使在存在身份验证的情况下,也可以发送路由器广告消息,从而能够导致拒绝服务。此外,任何邻居都可以发送代理邻居播发以及未经请求的邻居播发,作为潜在的拒绝服务攻击。

Many link layers are also subject to different denial-of-service attacks such as continuously occupying the link in CSMA/CD (Carrier Sense Multiple Access with Collision Detection) networks (e.g., by sending packets closely back-to-back or asserting the collision signal on the link), or originating packets with somebody else's source MAC address to confuse, e.g., Ethernet switches. On the other hand, many of the threats discussed in this section are less

许多链路层还受到不同的拒绝服务攻击,例如在CSMA/CD(具有冲突检测的载波侦听多址)网络中持续占用链路(例如,通过紧密背靠背发送数据包或在链路上断言冲突信号),或使用其他人的源MAC地址发起数据包以混淆,例如以太网交换机。另一方面,本节讨论的许多威胁较少

effective, or non-existent, on point-to-point links, or cellular links where a host shares a link with only one neighbor, i.e., the default router.

在点到点链路或蜂窝链路上有效或不存在,其中主机仅与一个邻居(即默认路由器)共享链路。

11.2. Securing Neighbor Discovery Messages
11.2. 保护邻居发现消息

The protocol reduces the exposure to the above threats in the absence of authentication by ignoring ND packets received from off-link senders. The Hop Limit field of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor.

该协议通过忽略从非链路发送方接收的ND数据包,减少了在没有身份验证的情况下受到上述威胁的风险。验证所有接收数据包的跃点限制字段是否包含最大合法值255。因为路由器减少了它们转发的所有数据包的跳数限制,所以接收到的包含255跳数限制的数据包必须来自邻居。

Cryptographic security mechanisms for Neighbor Discovery are outside the scope of this document and are defined in [SEND]. Alternatively, IPsec can be used for IP layer authentication [IPv6-SA]. The use of the Internet Key Exchange (IKE) is not suited for creating dynamic security associations that can be used to secure address resolution or neighbor solicitation messages as documented in [ICMPIKE].

邻居发现的加密安全机制不在本文档的范围内,并在[SEND]中定义。或者,IPsec可用于IP层身份验证[IPv6 SA]。互联网密钥交换(IKE)的使用不适合创建动态安全关联,该关联可用于安全地址解析或邻居请求消息,如[ICMPIKE]中所述。

In some cases, it may be acceptable to use statically configured security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure Neighbor Discovery messages. However, it is important to note that statically configured security associations are not scalable (especially when considering multicast links) and are therefore limited to small networks with known hosts. In any case, if either [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for the purpose of authentication. Packets that fail authentication checks MUST be silently discarded.

在某些情况下,可以使用静态配置的与[IPv6 AUTH]或[IPv6 ESP]的安全关联来保护邻居发现消息。但是,需要注意的是,静态配置的安全关联是不可伸缩的(特别是在考虑多播链路时),因此仅限于具有已知主机的小型网络。在任何情况下,如果使用[IPv6 AUTH]或[IPv6 ESP],则必须验证ND数据包以进行身份验证。身份验证检查失败的数据包必须以静默方式丢弃。

12. Renumbering Considerations
12. 重新编号考虑事项

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

考虑下面的示例,其中前缀最初被广告为2个月的生命周期,但是在8月1日,确定前缀需要被删除并由于

renumbering by September 1st. This can be done by reducing the advertised lifetime to 1 week starting on August 1st, and as the cutoff gets closer, the lifetimes can be made shorter until by September 1st the prefix is advertised with a lifetime of 0. The point is that, if one or more nodes were unplugged from the link prior to September 1st, they might still think that the prefix is valid since the last lifetime they received was 2 months. Thus, if a node was unplugged on July 31st, it thinks the prefix is valid until September 30th. If that node is plugged back in prior to September 30th, it may continue to use the old prefix. The only way to force a node to stop using a prefix that was previously advertised with a long lifetime is to have that node receive an advertisement for that prefix that changes the lifetime downward. The solution in this example is simple: continue advertising the prefix with a lifetime of 0 from September 1st until October 1st.

9月1日前重新编号。这可以通过将播发的生存期从8月1日开始减少到1周来实现,并且随着截止日期的临近,生存期可以缩短,直到9月1日,前缀的生存期为0。关键是,如果一个或多个节点在9月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 that a particular prefix can be viewed as valid by any node on the link. The prefix must then be advertised with a 0 lifetime until that point in the future. This "furthest into the future" time is simply the maximum, over all Router Advertisements, of the time the advertisement was sent, plus the prefix's lifetime contained in the advertisement.

一般来说,为了对可能从链路上断开连接的节点具有鲁棒性,重要的是跟踪未来最远的距离,即特定前缀可以被链路上的任何节点视为有效。然后,前缀必须以0生存期播发,直到将来的该点。这个“最远的未来”时间只是所有路由器广告中广告发送时间的最大值,加上广告中包含的前缀的生存期。

The above has an important implication on using infinite lifetimes. If a prefix is advertised with an infinite lifetime, and that prefix later needs to be renumbered, it is undesirable to continue advertising that prefix with a zero lifetime forever. Thus, either infinite lifetimes should be avoided or there must be a limit on how long of a time a node can be unplugged from the link before it is plugged back in again. However, it is unclear how the network administrator can enforce a limit on how long time hosts such as laptops can be unplugged from the link.

上述内容对于使用无限寿命具有重要意义。如果某个前缀以无限生存期播发,并且该前缀以后需要重新编号,则不希望以零生存期继续播发该前缀。因此,要么应该避免无限的生存期,要么必须限制节点在重新插入之前从链路上拔出的时间。然而,目前尚不清楚网络管理员如何限制笔记本电脑等主机从链路上拔出的时间。

Network administrators should give serious consideration to using relatively short lifetimes (i.e., no more than a few weeks). While it might appear that using long lifetimes would help ensure robustness, in reality, a host will be unable to communicate in the absence of properly functioning routers. Such routers will be sending Router Advertisements that contain appropriate (and current) prefixes. A host connected to a network that has no functioning routers is likely to have more serious problems than just a lack of a valid prefix and address.

网络管理员应认真考虑使用相对较短的生命周期(即不超过几周)。虽然使用长寿命似乎有助于确保健壮性,但实际上,如果没有正常运行的路由器,主机将无法通信。此类路由器将发送包含适当(和当前)前缀的路由器广告。连接到没有正常运行的路由器的网络的主机可能存在比缺少有效前缀和地址更严重的问题。

The above discussion does not distinguish between the preferred and valid lifetimes. For all practical purposes, it is probably sufficient to track the valid lifetime since the preferred lifetime will not exceed the valid lifetime.

上述讨论并未区分首选寿命和有效寿命。出于所有实际目的,跟踪有效生存期可能就足够了,因为首选生存期不会超过有效生存期。

13. IANA Considerations
13. IANA考虑

This document does not require any new ICMPv6 types or codes to be allocated. However, existing ICMPv6 types have been updated to point to this document instead of RFC 2461. The procedure for the assignment of ICMPv6 types/codes is described in Section 6 of [ICMPv6].

本文件不要求分配任何新的ICMPv6类型或代码。但是,现有的ICMPv6类型已更新为指向此文档,而不是RFC 2461。[ICMPv6]第6节描述了分配ICMPv6类型/代码的程序。

This document continues to use the following ICMPv6 message types introduced in RFC 2461 and already assigned by IANA:

本文档继续使用RFC 2461中引入并已由IANA分配的以下ICMPv6消息类型:

Message name ICMPv6 Type

消息名称ICMPv6类型

Router Solicitation 133 Router Advertisement 134 Neighbor Solicitation 135 Neighbor Advertisement 136 Redirect 137

路由器请求133路由器公告134邻居请求135邻居公告136重定向137

This document continues to use the following Neighbor Discovery option types introduced in RFC 2461 and already assigned by IANA:

本文档继续使用RFC 2461中引入并已由IANA分配的以下邻居发现选项类型:

Option Name Type

选项名称类型

Source Link-Layer Address 1 Target Link-Layer Address 2 Prefix Information 3 Redirected Header 4 MTU 5

源链路层地址1目标链路层地址2前缀信息3重定向头4 MTU 5

Neighbor Discovery option types are allocated using the following procedure:

使用以下过程分配邻居发现选项类型:

1. The IANA should allocate and permanently register new option types from IETF RFC publication. This is for all RFC types including standards track, informational, and experimental status that originate from the IETF and have been approved by the IESG for publication.

1. IANA应从IETF RFC出版物中分配并永久注册新的选项类型。这适用于所有RFC类型,包括源于IETF并经IESG批准发布的标准跟踪、信息和实验状态。

2. IETF working groups with working group consensus and area director approval can request reclaimable Neighbor Discovery option type assignments from the IANA. The IANA will tag the values as "reclaimable in future".

2. 具有工作组共识和区域主管批准的IETF工作组可以从IANA请求可回收邻居发现选项类型分配。IANA将这些值标记为“将来可回收”。

The "reclaimable in the future" tag will be removed when an RFC is published documenting the protocol as defined in 1). This will make the assignment permanent and update the reference on the IANA Web pages.

当发布RFC时,“将来可回收”标签将被删除,该RFC记录了1)中定义的协议。这将使分配永久化,并更新IANA网页上的参考。

At the point where the option type values are 85% assigned, the IETF will review the assignments tagged "reclaimable in the future" and inform the IANA which ones should be reclaimed and reassigned.

当选项类型值分配85%时,IETF将审查标记为“未来可回收”的分配,并通知IANA哪些分配应回收和重新分配。

3. Requests for new option type value assignments from outside the IETF are only made through the publication of an IETF document, per 1) above. Note also that documents published as "RFC Editor contributions" [RFC3667] are not considered to be IETF documents.

3. 根据上文第1)条,只有通过发布IETF文件,才能从IETF外部请求新的选项类型值分配。另请注意,作为“RFC编辑器贡献”[RFC3667]发布的文件不被视为IETF文件。

14. References
14. 工具书类
14.1. Normative References
14.1. 规范性引用文件

[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[ADDR-ARCH]Hinden,R.和S.Deering,“IP版本6寻址体系结构”,RFC 42912006年2月。

[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.

[ICMPv6]Conta,A.,Deering,S.,和M.Gupta,Ed.,“互联网协议版本6(IPv6)规范的互联网控制消息协议(ICMPv6)”,RFC 4443,2006年3月。

[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月。

[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月。

14.2. Informative References
14.2. 资料性引用

[ADDRCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[ADDRCONF]Thomson,S.,Narten,T.,和T.Jinmei,“IPv6无状态地址自动配置”,RFC 48622007年9月。

[ADDR-SEL] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.

[ADDR-SEL]Draves,R.,“互联网协议版本6(IPv6)的默认地址选择”,RFC 3484,2003年2月。

[ARP] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.

[ARP]Plummer,D.,“以太网地址解析协议:或将网络协议地址转换为48位以太网地址,以便在以太网硬件上传输”,STD 37,RFC 826,1982年11月。

[ASSIGNED] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.

[指定]Reynolds,J.,Ed.,“指定号码:RFC 1700被在线数据库取代”,RFC 3232,2002年1月。

[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[DHCPv6]Droms,R.,Ed.,Bound,J.,Volz,B.,Lemon,T.,Perkins,C.,和M.Carney,“IPv6的动态主机配置协议(DHCPv6)”,RFC 33151003年7月。

[HR-CL] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[HR-CL]Braden,R.,Ed.“互联网主机的要求-通信层”,STD 3,RFC 1122,1989年10月。

[ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, March 2003.

[ICMPIKE]Arkko,J.,“ICMPv6对IKE的影响”,进展中的工作,2003年3月。

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

[ICMPv4]Postel,J.,“互联网控制消息协议”,STD 5,RFC 792,1981年9月。

[IPv6-3GPP] Wasserman, M., Ed., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.

[IPv6-3GPP]Wasserman,M.,Ed.,“第三代合作伙伴关系项目(3GPP)标准中IPv6的建议”,RFC 3314,2002年9月。

[IPv6-CELL] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003.

[IPv6蜂窝]Arkko,J.,Kuijpers,G.,Soliman,H.,Loughney,J.,和J.Wiljakka,“一些第二代和第三代蜂窝主机的互联网协议版本6(IPv6)”,RFC 3316,2003年4月。

[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.

[IPv6以太]Crawford,M.,“通过以太网传输IPv6数据包”,RFC 2464,1998年12月。

[IPv6-SA] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[IPv6 SA]Kent,S.和K.Seo,“互联网协议的安全架构”,RFC 43012005年12月。

[IPv6-AUTH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[IPv6认证]Kent,S.,“IP认证头”,RFC 4302,2005年12月。

[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[IPv6 ESP]Kent,S.,“IP封装安全有效负载(ESP)”,RFC 4303,2005年12月。

[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.

[IPv6 NBMA]Armitage,G.,Schulter,P.,Jork,M.,和G.Harter,“非广播多址(NBMA)网络上的IPv6”,RFC 2491,1999年1月。

[LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.

[LD-SHRE]Hinden,R.和D.Thaler,“IPv6主机到路由器负载共享”,RFC 4311,2005年11月。

[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[MIPv6]Johnson,D.,Perkins,C.,和J.Arkko,“IPv6中的移动支持”,RFC 37752004年6月。

[MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.

[MLD]Deering,S.,Fenner,W.和B.Haberman,“IPv6的多播侦听器发现(MLD)”,RFC 2710,1999年10月。

[MLDv2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[MLDv2]Vida,R.,Ed.,和L.Costa,Ed.,“IPv6的多播侦听器发现版本2(MLDv2)”,RFC 3810,2004年6月。

[PSREQ] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

[PSREQ]Nikander,P.,Ed.,Kempf,J.和E.Nordmark,“IPv6邻居发现(ND)信任模型和威胁”,RFC 37562004年5月。

[RAND] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

[RAND]Eastlake,D.,3rd,Schiller,J.,和S.Crocker,“安全的随机性要求”,BCP 106,RFC 40862005年6月。

[RDISC] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.

[RDISC]Deering,S.,编辑,“ICMP路由器发现消息”,RFC 12561991年9月。

[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004.

[RFC3667]Bradner,S.,“IETF在贡献中的权利”,RFC 3667,2004年2月。

[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.

[RTSEL]Draves,R.和D.Thaler,“默认路由器首选项和更具体的路由”,RFC 41912005年11月。

[SH-MEDIA] Braden, B., Postel, J., and Y. Rekhter, "Internet Architecture Extensions for Shared Media", RFC 1620, May 1994.

[SH-MEDIA]Braden,B.,Postel,J.,和Y.Rekhter,“共享媒体的互联网架构扩展”,RFC 1620,1994年5月。

[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[发送]Arkko,J.,Ed.,Kempf,J.,Zill,B.,和P.Nikander,“安全邻居发现(发送)”,RFC 39712005年3月。

   [SYNC]       S. Floyd, V. Jacobson, "The Synchronization of Periodic
                Routing Messages", IEEE/ACM Transactions on Networking,
                April 1994.  ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z
        
   [SYNC]       S. Floyd, V. Jacobson, "The Synchronization of Periodic
                Routing Messages", IEEE/ACM Transactions on Networking,
                April 1994.  ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z
        

Appendix A: Multihomed Hosts

附录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. Further work related to this problem can be found in [RTSEL].

当具有多个接口的主机使用邻居发现时,会出现许多复杂的问题。本节不尝试定义多宿主机在邻居发现方面的正确操作。相反,它确定了需要进一步研究的问题。鼓励实施者试验各种方法,使邻居发现在多主机上工作,并报告他们的经验。与此问题相关的进一步工作可在[RTSEL]中找到。

If a multihomed host receives Router Advertisements on all of its interfaces, it will (probably) have learned on-link prefixes for the addresses residing on each link. When a packet must be sent through a router, however, selecting the "wrong" router can result in a suboptimal or non-functioning path. There are number of issues to consider:

如果多宿主机在其所有接口上接收到路由器播发,则它(可能)已经了解了驻留在每个链路上的地址的链路前缀。但是,当数据包必须通过路由器发送时,选择“错误”的路由器可能会导致路径不理想或无法正常工作。有许多问题需要考虑:

1) In order for a router to send a redirect, it must determine that the packet it is forwarding originates from a neighbor. The standard test for this case is to compare the source address of the packet to the list of on-link prefixes associated with the interface on which the packet was received. If the originating host is multihomed, however, the source address it uses may belong to an interface other than the interface from which it was sent. In such cases, a router will not send redirects, and suboptimal routing is likely. In order to be redirected, the sending host must always send packets out the interface corresponding to the outgoing packet's source address. Note that this issue never arises with non-multihomed hosts; they only have one interface. Additional discussion on this topic can be found in RFC 1122 under Section 3.3.4.2.

1) 为了让路由器发送重定向,它必须确定它转发的数据包来自邻居。这种情况下的标准测试是将数据包的源地址与接收数据包的接口相关联的链路前缀列表进行比较。但是,如果发起主机是多址的,则它使用的源地址可能属于发送它的接口以外的接口。在这种情况下,路由器将不会发送重定向,并且可能出现次优路由。为了重定向,发送主机必须始终将数据包发送到对应于传出数据包源地址的接口。请注意,非多址主机不会出现此问题;它们只有一个接口。有关此主题的更多讨论,请参见RFC 1122第3.3.4.2节。

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 the following problem: If Router Advertisements are received on some, but not all, interfaces, a multihomed host could choose to only send packets out on the interfaces on which it has received Router Advertisements. A key assumption made here, however, is that routers on those other interfaces will be able to route packets to the ultimate destination, even when those destinations reside on the subnet to which the sender connects, but has no on-link prefix information. Should the assumption be FALSE, communication would fail. Even if the assumption holds, packets will traverse a suboptimal path.

受影响的接口。这会导致以下问题:如果在某些(而不是所有)接口上接收到路由器播发,则多宿主机可以选择仅在其接收到路由器播发的接口上发送数据包。然而,这里的一个关键假设是,这些其他接口上的路由器将能够将数据包路由到最终目的地,即使这些目的地位于发送方连接的子网上,但没有链路前缀信息。如果假设是错误的,沟通就会失败。即使这个假设成立,数据包也会穿越次优路径。

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 Retransmit timeout, Retransmit NS INCOMPLETE less than N Start retransmit retransmissions. timer

不完全重传超时,重传NS不完全小于N开始重传。计时器

INCOMPLETE Retransmit timeout, Discard entry - N or more Send ICMP error retransmissions.

不完整的重新传输超时,放弃条目-N个或多个发送ICMP错误重新传输。

INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=any address. Send queued packets.

不完整的NA,请求的=0,记录链接层过时覆盖=任何地址。发送排队的数据包。

INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets.

不完整的NA,请求=1,记录链接层可达覆盖=任何地址。发送排队的数据包。

INCOMPLETE NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag Link-layer address

不完整的NA,请求的=任何,未更改覆盖的更新内容=任何,没有IsRouter标志链接层地址

- NS, RS, Redirect - - No link-layer address

- NS、RS、重定向--无链路层地址

!INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached.

!不完整的NA,请求=1,-可访问覆盖=0与缓存的链接层地址相同。

!INCOMPLETE NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag. link-layer address

!不完整NA,请求=any,更新未更改覆盖的内容=any,无IsRouter标志。链路层地址

REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer address than cached.

可访问NA,请求=1,-过时覆盖=0与缓存的链接层地址不同。

STALE, PROBE NA, Solicited=1, - unchanged Or DELAY Override=0 Different link-layer address than cached.

过时、探测NA、请求=1,-未更改或延迟覆盖=0与缓存的链路层地址不同。

!INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=1 address (if different).

!不完整的NA,请求=1,记录链接层可达覆盖=1地址(如果不同)。

   !INCOMPLETE     NA, Solicited=0,        -                  unchanged
                   Override=0
        
   !INCOMPLETE     NA, Solicited=0,        -                  unchanged
                   Override=0
        

!INCOMPLETE NA, Solicited=0, - unchanged Override=1 Same link-layer address as cached.

!不完整的NA,请求的=0,-未更改的覆盖=1与缓存的链接层地址相同。

!INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=1 address. Different link-layer address than cached.

!不完整的NA,请求=0,记录链接层过时覆盖=1地址。与缓存的链接层地址不同。

!INCOMPLETE upper-layer reachability - REACHABLE confirmation

!不完全上层可达性-可达性确认

REACHABLE timeout, more than - STALE N seconds since reachability confirm.

可达性超时,自可达性确认后已超过-N秒。

STALE Sending packet Start delay timer DELAY

过时发送数据包开始延迟计时器延迟

DELAY Delay timeout Send unicast NS probe PROBE Start retransmit timer

延迟超时发送单播NS探测探测开始重传计时器

PROBE Retransmit timeout, Retransmit NS PROBE less than N retransmissions.

探测重传超时,重传NS探测小于N次重传。

PROBE Retransmit timeout, Discard entry - N or more retransmissions.

探测重传超时,放弃条目-N次或更多重传。

The state transitions for receiving unsolicited information other than Neighbor Advertisement messages apply to either the source of the packet (for Neighbor Solicitation, Router Solicitation, and Router Advertisement messages) or the target address (for Redirect messages) as follows:

用于接收除邻居广告消息以外的非请求信息的状态转换适用于分组的源(用于邻居请求、路由器请求和路由器广告消息)或目标地址(用于重定向消息),如下所示:

State Event Action New state

状态事件操作新状态

- NS, RS, RA, Redirect Create entry. STALE

- NS、RS、RA、重定向创建条目。不新鲜的

INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE address. Send queued packets.

NS、RS、RA、重定向记录链路层陈旧地址不完整。发送排队的数据包。

!INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE Different link-layer address address than cached.

!不完整的NS、RS、RA、重定向更新链接层与缓存的链接层地址不同。

INCOMPLETE NS, RS No link-layer - unchanged address

不完整的NS、RS无链路层-地址未更改

!INCOMPLETE NS, RS, RA, Redirect - unchanged Same link-layer address as cached.

!不完整的NS、RS、RA、重定向-与缓存的链接层地址相同。

Appendix D: Summary of IsRouter Rules

附录D:ISRUTER规则摘要

This appendix presents a summary of the rules for maintaining the IsRouter flag as specified in this document.

本附录概述了本文件规定的IsRouter标志维护规则。

The background for these rules is that the ND messages contain, either implicitly or explicitly, information that indicates whether or not the sender (or Target Address) is a host or a router. The following assumptions are used:

这些规则的背景是,ND消息隐式或显式地包含指示发送方(或目标地址)是主机还是路由器的信息。使用以下假设:

- The sender of a Router Advertisement is implicitly assumed to be a router.

- 路由器广告的发送者被隐式地假定为路由器。

- Neighbor Solicitation messages do not contain either an implicit or explicit indication about the sender. Both hosts and routers send such messages.

- 邻居请求消息不包含关于发件人的隐式或显式指示。主机和路由器都发送这样的消息。

- 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:实施问题

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:

邻居不可达性检测需要明确确认前向路径是否正常工作。为了避免需要邻居请求探测消息,上层协议应该在这样做的成本很小时提供这样的指示。可靠的面向连接的协议(如TCP)通常在转发路径工作时能够感知。例如,当TCP发送(或接收)数据时,它会更新其窗口序列号、设置和取消重传计时器等。通常指示正常工作的转发路径的特定场景包括:

- Receipt of an acknowledgment that covers a sequence number (e.g., data) not previously acknowledged indicates that the forward path was working at the time the data was sent.

- 接收到包含先前未确认的序列号(例如,数据)的确认表示发送数据时转发路径正在工作。

- Completion of the initial three-way handshake is a special case of the previous rule; although no data is sent during the handshake, the SYN flags are counted as data from the sequence number perspective. This applies to both the SYN+ACK for the active open and the ACK of that packet on the passively opening peer.

- 完成初始三方握手是前一规则的特例;尽管在握手过程中没有发送数据,但从序列号的角度来看,SYN标志被视为数据。这既适用于主动开放的SYN+ACK,也适用于被动开放对等方上该数据包的ACK。

- Receipt of new data (i.e., data not previously received) indicates that the forward-path was working at the time an acknowledgment was sent that advanced the peer's send window that allowed the new data to be sent.

- 接收到新数据(即,以前未接收到的数据)表明,在发送确认时,转发路径正在工作,该确认使对等方的发送窗口提前,从而允许发送新数据。

To minimize the cost of communicating reachability information between the TCP and IP layers, an implementation may wish to rate-limit the reachability confirmations its sends IP. One possibility is to process reachability only every few packets. For example, one might update reachability information once per round-trip time, if an implementation only has one round-trip timer per connection. For those implementations that cache Destination Cache entries within control blocks, it may be possible to update the Neighbor Cache entry directly (i.e., without an expensive lookup) once the TCP packet has been demultiplexed to its corresponding control block. For other implementations, it may be possible to piggyback the reachability confirmation on the next packet submitted to IP assuming that the implementation guards against the piggybacked confirmation becoming stale when no packets are sent to IP for an extended period of time.

为了最小化TCP层和IP层之间通信可达性信息的成本,实现可能希望对其IP发送的可达性确认进行速率限制。一种可能性是仅每隔几个包处理可达性。例如,如果一个实现每个连接只有一个往返计时器,那么每个往返时间可以更新一次可达性信息。对于在控制块内缓存目标缓存项的那些实现,一旦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; it merely indicates that 30 minutes ago the window update reached the peer, i.e., the path was working at that point in time. An implementation must also take into account TCP zero-window probes that are sent even if the path is broken and the window update did not reach the peer.

TCP还必须防止认为“过时”信息表示当前可达性。例如,在窗口打开30分钟后收到的新数据不构成路径当前工作的确认;它仅表示30分钟前窗口更新到达对等方,即路径在该时间点工作。实现还必须考虑发送的TCP零窗口探测,即使路径断开且窗口更新未到达对等方。

For UDP-based applications (Remote Procedure Call (RPC), DNS), it is relatively simple to make the client send reachability confirmations when the response packet is received. It is more difficult and in some cases impossible for the server to generate such confirmations since there is no flow control, i.e., the server cannot determine whether a received request indicates that a previous response reached the client.

对于基于UDP的应用程序(远程过程调用(RPC)、DNS),当接收到响应数据包时,让客户端发送可达性确认相对简单。由于不存在流控制,服务器更难生成此类确认,并且在某些情况下不可能生成此类确认,即,服务器无法确定接收到的请求是否指示先前的响应已到达客户端。

Note that an implementation cannot use negative upper-layer advice as a replacement for the Neighbor Unreachability Detection algorithm. Negative advice (e.g., from TCP when there are excessive retransmissions) could serve as a hint that the forward path from the sender of the data might not be working. But it would fail to detect when the path from the receiver of the data is not functioning, causing none of the acknowledgment packets to reach the sender.

请注意,实现不能使用否定的上层建议来替代邻居不可达性检测算法。负面建议(例如,当存在过多的重传时来自TCP)可能会提示来自数据发送方的转发路径可能不起作用。但它将无法检测来自数据接收方的路径何时不起作用,从而导致任何确认数据包都无法到达发送方。

Appendix F: Changes from RFC 2461

附录F:RFC 2461的变更

o Removed references to IPsec AH and ESP for securing messages or as part of validating the received message.

o 删除了对IPsec AH和ESP的引用,用于保护消息或验证接收到的消息。

o Added Section 3.3.

o 增加了第3.3节。

o Updated Section 11 to include more detailed discussion on threats, IPsec limitations, and use of SEND.

o 更新了第11节,包括关于威胁、IPsec限制和SEND使用的更详细讨论。

o Removed the on-link assumption in Section 5.2 based on RFC 4942, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful".

o 删除了第5.2节中基于RFC 4942“基于链路的IPv6邻居发现假设有害”的链路上假设。

o Clarified the definition of the Router Lifetime field in Section 4.2.

o 澄清了第4.2节中路由器寿命字段的定义。

o Updated the text in Sections 4.6.2 and 6.2.1 to indicate that the preferred lifetime must not be larger than valid lifetime.

o 更新了第4.6.2节和第6.2.1节中的文本,以表明首选寿命不得大于有效寿命。

o Removed the reference to stateful configuration and added reference for DHCPv6 instead.

o 删除了对有状态配置的引用,而是添加了对DHCPv6的引用。

o Added the IsRouter flag definition to Section 6.2.1 to allow for mixed host/router behavior.

o 在第6.2.1节中添加了ISRUTER标志定义,以允许混合主机/路由器行为。

o Allowed mobile nodes to be exempt from adding random delays before sending an RS during a handover.

o 允许移动节点在切换期间发送RS之前免于添加随机延迟。

o Updated the definition of the prefix length in the prefix option.

o 更新了前缀选项中前缀长度的定义。

o Updated the applicability to NBMA links in the introduction and added references to 3GPP RFCs.

o 在介绍中更新了NBMA链接的适用性,并添加了对3GPP RFC的参考。

o Clarified that support for load balancing is limited to routers.

o 阐明了对负载平衡的支持仅限于路由器。

o Clarified router behavior when receiving a Router Solicitation without Source Link-Layer Address Option (SLLAO).

o 澄清了在没有源链路层地址选项(SLLAO)的情况下接收路由器请求时的路由器行为。

o Clarified that inconsistency checks for CurHopLimit are done for non-zero values only.

o 澄清了CurHopLimit的不一致性检查仅针对非零值进行。

o Rearranged Section 7.2.5 for clarity, and described the processing when receiving the NA in INCOMPLETE state.

o 为了清晰起见,重新安排了第7.2.5节,并描述了在不完整状态下接收NA时的处理。

o Added clarifications in Section 7.2 on how a node should react upon receiving a message without SLLAO.

o 在第7.2节中增加了关于节点在收到没有SLLAO的消息时应如何反应的澄清。

o Added new IANA section.

o 增加了新的IANA部分。

o Miscellaneous editorials.

o 杂项社论。

Acknowledgments

致谢

The authors of RFC 2461 would like to acknowledge the contributions of the IPV6 working group and, in particular, (in alphabetical order) Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, Matt Thomas, and Susan Thomson.

RFC 2461的作者要感谢IPV6工作组的贡献,特别是(按字母顺序)Atkinson、Jim Bound、Scott Bradner、Alex Conta、Stephen Deering、Richard Draves、Francis Dupont、Robert Elz、Robert Gilligan、Robert Hinden、Tatuya Jinmei、Allison Mankin、Dan McDonald、Charles Perkins、,马特·托马斯和苏珊·汤姆森。

The editor of this document (Hesham Soliman) would like to thank the IPV6 working group for the numerous contributions to this revision -- in particular (in alphabetical order), Greg Daley, Elwyn Davies, Ralph Droms, Brian Haberman, Bob Hinden, Tatuya Jinmei, Pekka Savola, Fred Templin, and Christian Vogt.

本文档的编辑(Hesham Soliman)感谢IPV6工作组为本次修订做出的众多贡献,特别是(按字母顺序)Greg Daley、Elwyn Davies、Ralph Droms、Brian Haberman、Bob Hinden、Tatuya Jinmei、Pekka Savola、Fred Templin和Christian Vogt。

Authors' Addresses

作者地址

Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA

美国北卡罗来纳州三角研究园12195号邮政信箱托马斯·纳顿IBM公司,邮编:27709-2195

   Phone: +1 919 254 7798
   EMail: narten@us.ibm.com
        
   Phone: +1 919 254 7798
   EMail: narten@us.ibm.com
        

Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA

Erik Nordmark Sun Microsystems,Inc.美国加利福尼亚州门罗公园17号网络圈,邮编94025

   Phone: +1 650 786 2921
   Fax:   +1 650 786 5896
   EMail: erik.nordmark@sun.com
        
   Phone: +1 650 786 2921
   Fax:   +1 650 786 5896
   EMail: erik.nordmark@sun.com
        

William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 USA

美国密歇根州芳丹麦迪逊高地1384号威廉·艾伦·辛普森白日梦计算机系统咨询服务公司,邮编:48071

   EMail: william.allen.simpson@gmail.com
        
   EMail: william.allen.simpson@gmail.com
        

Hesham Soliman Elevate Technologies

Hesham Soliman提升技术公司

   EMail: hesham@elevatemobile.com
        
   EMail: hesham@elevatemobile.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

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

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

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

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.