IPv6无状态地址自动配置

关于本备忘录

本文档为互联网社区指定了一个互联网标准跟踪协议，并要求讨论和提出改进建议。请参阅当前版本的“互联网官方协议标准”（STD 1），了解该协议的标准化状态和状态。这份备忘录的分发是无限的。
摘要

本文档详细说明了主机在决定如何在IPV6中自动配置其接口时所采取的步骤。自动配置过程包括生成链路本地地址、通过无状态地址自动配置生成全局地址，以及验证链路上地址唯一性的重复地址检测过程。
1、导言

本文档详细说明了主机在决定如何在IPV6（IP version 6）中自动配置其接口时所采取的步骤。自动配置过程包括生成链路本地地址、通过无状态地址自动配置生成全局地址，以及验证链路上地址唯一性的重复地址检测过程。
IPv6无状态自动配置机制不需要手动配置主机，只需要对路由器进行最小（如果有的话）配置，也不需要额外的服务器。无状态机制允许主机使用本地可用信息和路由器通告的信息的组合来生成自己的地址。路由器通告标识与链路关联的子网的前缀，而主机生成唯一标识子网上接口的“接口标识符”。地址是通过将两者结合而形成的。在没有路由器的情况下，主机只能生成链路本地地址。然而，链路本地地址足以允许连接到同一链路的节点之间进行通信。

当一个站点不特别关心主机使用的确切地址时，使用无状态方法，只要它们是唯一的并且可以正确路由。另一方面，当站点需要对精确的地址分配进行更严格的控制时，使用IPv6动态主机配置协议（Dynamic Host Configuration Protocol for IPv6，DHCPv6）[RFC3315]。无状态地址自动配置和DHCPv6可以同时使用。
IPv6地址在固定（可能是无限）的时间内租给接口。每个地址都有一个关联的生存期，指示地址绑定到接口的时间。当生命周期到期时，绑定（和地址）将无效，地址可能会被重新分配给互联网其他地方的另一个接口。为了优雅地处理地址绑定的过期，地址在分配给接口时会经历两个不同的阶段。最初，地址是“首选”的，这意味着它在任意通信中的使用不受限制。稍后，一个地址会被“弃用”，因为预计其当前的接口绑定将无效。当地址处于弃用状态时，不鼓励使用，但并非严格禁止。新的通信（例如，打开新的TCP连接）应尽可能使用首选地址。已弃用的地址只能由一直在使用它的应用程序使用，并且在不中断服务的情况下很难切换到另一个地址。
为了确保所有配置的地址在给定的链路上都是唯一的，节点在将地址分配给接口之前，会对地址运行“重复地址检测”算法。对所有地址执行重复地址检测算法，无论它们是通过无状态自动配置还是DHCPv6获得的。本文档定义了重复地址检测算法。
本文档中指定的自动配置过程仅适用于主机，不适用于路由器。由于主机自动配置使用路由器通告的信息，因此需要通过其他方式配置路由器。然而，预计路由器将使用本文档中描述的机制生成链路本地地址。此外，路由器在将所有地址分配给接口之前，应成功通过本文档中描述的重复地址检测过程。
第2节提供了本文档中使用的术语的定义。第3节描述了导致当前自动配置过程的设计目标。第4节概述了该协议，而第5节详细描述了该协议。
2、术语

IP：Internet Protocol Version 6，本文中指IPv6。术语IPv4和IPv6仅在必要时使用，以避免歧义。
node：节点，实现IP的设备。
router：路由器，转发未明确寻址到自身的IP数据包的节点。
host：主机，任何不是路由器的节点。
upper layer：上层，紧邻IP之上的协议层。示例包括TCP和UDP等传输协议、ICMP等控制协议、OSPF等路由协议，以及通过IPX、AppleTalk或IP本身等IP“隧道化”（即封装在其中）的互联网或较低层协议。
link：链路，一种通信设施或介质，节点可以在链路层（即IP下一层）进行通信。例如以太网（简单或桥接）；PPP链路；X.25、帧中继或ATM网络；以及互联网（或更高层）“隧道”，如IPv4或IPv6本身上的隧道。除非在描述如何根据[RFC4861]在链路上操作IP的链路类型特定文档中另有规定，否则本文档中描述的协议将用于所有类型的链路。
interface：接口，节点与链路的连接。
packet：数据包，IP报文头加上有效载荷。
address：地址，一个或一组接口的IP层标识符。
unicast address：单播地址，单个接口的标识符。发送到单播地址的数据包被传递到由该地址标识的接口。
multicast address：组播地址，一组接口的标识符（通常属于不同的节点）。发送到组播地址的数据包被传递到该地址标识的所有接口。
anycast address：任播地址，一组接口的标识符（通常属于不同的节点）。发送到任播地址的数据包被传递到该地址标识的接口之一（根据路由协议的距离度量，“最近”的接口）。参见[RFC4291]。
solicited-node multicast address：请求节点组播地址，邻居请求消息发送到的组播地址。[RFC4291]中给出了计算地址的算法。
link-layer address：链路层地址，接口的链路层标识符。示例包括以太网链路的IEEE 802地址和综合业务数字网（Integrated Services Digital Network，ISDN）链路的E.164地址。
link-local address：链路本地地址，具有仅链路范围的地址，可用于到达连接到同一链路的相邻节点。所有接口都有一个链路本地单播地址。
global address：全局地址，具有无限制范围的地址。
communication：通信，节点之间的任何数据包交换，要求交换中使用的每个节点的地址在数据包交换期间保持不变。例如TCP连接或UDP请求响应。
tentative address：临时地址，在将其分配给接口之前，正在验证其在链路上的唯一性的地址。在通常意义上，临时地址不被视为分配给接口。接口丢弃接收到的发往临时地址的数据包，但接受与临时地址的重复地址检测相关的邻居发现数据包。
preferred address：首选地址，分配给上层协议使用不受限制的接口的地址。首选地址可以用作从接口发送（或发送到接口）的数据包的源（或目的地）地址。
deprecated address：弃用地址，分配给不鼓励但不禁止使用的接口的地址。弃用地址不应再用作新通信中的源地址，但从弃用地址发送或发送到弃用地址的数据包会按预期传递。在通信中，当切换到首选地址会给特定的上层活动（例如现有的TCP连接）带来困难时，弃用的地址可能会继续用作源地址。
valid address：有效地址，首选或弃用的地址。有效地址可能显示为数据包的源地址或目的地址，并且互联网路由系统预计会将发送到有效地址的数据包传递给其预期的收件人。
invalid address：无效地址，未分配给任何接口的地址。当有效地址的有效生存期到期时，该地址将失效。无效地址不应显示为数据包的目标地址或源地址。在前一种情况下，互联网路由系统将无法传递数据包；在后一种情况下，数据包的接收者将无法对其做出响应。
preferred lifetime：首选生存期，首选有效地址的时间长度（即弃用前的时间）。当首选生存期到期时，该地址将被弃用。
valid lifetime：有效生存期，地址保持有效状态的时间长度（即无效前的时间）。有效生存期必须大于或等于首选生存期。当有效生存期到期时，地址将无效。
interface identifier：接口标识符，接口的链路相关标识符，每个链路（至少）是唯一的[RFC4291]。无状态地址自动配置将接口标识符与前缀组合在一起形成地址。从地址自动配置的角度来看，接口标识符是一个已知长度的位串。接口标识符的确切长度及其创建方式在单独的链路类型特定文档中定义，该文档涵盖了与特定链路类型上的IP传输相关的问题（例如[RFC2464]）。请注意，地址架构[RFC4291]还定义了某组地址的接口标识符的长度，但这两组定义必须一致。在许多情况下，标识符将从接口的链路层地址中导出。
2.1、要求

本文档中出现的关键字“必须”、“禁止”、“需要”、“应”、“不应”、“宜”、“不宜”、“推荐”、“可以”和“可选”应按照[RFC2119]中的描述进行解释。
请注意，本文档有意将关键字的使用限制在协议规范中（第5节）。
3、设计目标

无状态自动配置的设计考虑了以下目标：
*不需要在将单个机器连接到网络之前对其进行手动配置。因此，需要一种机制，允许主机为其每个接口获取或创建唯一的地址。地址自动配置假定每个接口都可以为该接口提供一个唯一的标识符（即“接口标识符”）。在最简单的情况下，接口标识符由接口的链路层地址组成。接口标识符可以与前缀组合形成地址。
*由一组连接到单个链路的机器组成的小型站点不应要求存在DHCPv6服务器或路由器作为通信的先决条件。即插即用通信是通过使用链路本地地址实现的。链路本地地址有一个众所周知的前缀，用于标识一组节点所连接的（单个）共享链路。主机通过将接口标识符附加到链路本地前缀来形成链路本地地址。
*具有多个网络和路由器的大型站点不应要求存在DHCPv6服务器进行地址配置。为了生成全局地址，主机必须确定标识其连接的子网的前缀。路由器生成周期性的路由器通告，其中包括列出链路上活动前缀集的选项。
*地址配置应便于站点计算机的优雅重新编号。例如，当站点切换到新的网络服务提供商时，它可能希望对其所有节点进行重新编号。重新编号是通过将地址租给接口并将多个地址分配给同一接口来实现的。租期提供了一种机制，通过该机制，站点可以逐步淘汰旧前缀。向一个接口分配多个地址提供了一个过渡期，在此期间，新地址和正在逐步淘汰的地址同时工作。
4、协议概述

本节概述了接口自动配置时发生的典型步骤。自动配置仅在支持组播的链路上执行，并在启用支持组播接口时开始，例如在系统启动期间。节点（主机和路由器）通过为接口生成链路本地地址来开始自动配置过程。通过将接口的标识符附加到公知的链路本地前缀[RFC4291]来形成链路本地地址。
然而，在将链路本地地址分配给接口并使用之前，节点必须尝试验证该“临时”地址尚未被链路上的另一个节点使用。具体来说，它发送一个邻居请求消息，其中包含作为目标的临时地址。如果另一个节点已经在使用该地址，它将返回一个邻居通告。如果另一节点也试图使用相同的地址，它也将为目标发送一个邻居请求。邻居请求被（重新）传输的确切次数以及连续请求之间的延迟时间是特定于链路的，可以由系统管理设置。
如果节点确定其临时链路本地地址不是唯一的，则自动配置停止，需要手动配置接口。为了简化这种情况下的恢复，管理员应该可以提供一个替代接口标识符，以覆盖默认标识符，这样就可以使用新的（可能是唯一的）接口标识符应用自动配置机制。或者，需要手动配置链路本地和其他地址。
一旦节点确定其临时链路本地地址是唯一的，它就会将该地址分配给接口。此时，节点与相邻节点具有IP级连接。其余的自动配置步骤仅由主机执行；路由器的（自动）配置超出了本文的范围。
自动配置的下一阶段涉及获取路由器通告或确定不存在路由器。如果存在路由器，它们将发送路由器通告，指定主机可以执行的自动配置类型。请注意，即使没有路由器，用于地址配置的DHCPv6服务可能仍然可用。
路由器定期发送路由器通告，但连续通告之间的延迟通常会比执行自动配置的主机想要等待的时间长[RFC4861]。为了快速获得通告，主机向所有路由器组播组发送一个或多个路由器请求。
路由器通告还包含零个或多个前缀信息选项，这些选项包含无状态地址自动配置用于生成全局地址的信息。应当注意，主机可以同时使用无状态地址自动配置和DHCPv6。一个前缀信息选项字段，即“自主地址配置标志”，指示该选项是否适用于无状态自动配置。如果是这样，其他选项字段将包含子网前缀以及生存期值，指示从前缀创建的地址保持首选和有效的时间。
因为路由器会定期生成路由器通告，所以主机会不断收到新的通告。主机如上所述处理每个通告中包含的信息，添加和刷新在先前通告中接收到的信息。
默认情况下，所有地址在分配给接口之前都应该进行唯一性测试，以确保安全。应单独对手动、通过无状态地址自动配置或通过DHCPv6获得的所有地址进行测试。为了适应那些认为执行重复地址检测的开销超过其好处的站点，可以通过每个接口配置标志的管理设置来禁用重复地址检测。
为了加快自动配置过程，主机可以在等待路由器通告的同时生成其链路本地地址（并验证其唯一性）。因为路由器可能会延迟几秒钟对路由器请求的响应，所以如果这两个步骤是连续完成的，完成自动配置所需的总时间可能会长得多。
4.1、站点重新编号

地址租赁通过提供一种机制来超时分配给主机中接口的地址，从而促进站点重新编号。目前，TCP等上层协议不支持在连接打开时更改端点地址。如果端点地址无效，现有连接将中断，与无效地址的所有通信都将失败。即使应用程序使用UDP作为传输协议，地址在数据包交换期间也必须保持不变。
将有效地址分为首选和弃用类别，可以向上层指示有效地址可能很快就会失效，如果地址的有效期在通信结束前到期，则使用该地址的未来通信将失败。为了避免这种情况，更高层应该使用首选地址（假设存在足够范围的地址），以增加地址在通信期间保持有效的可能性。系统管理员有责任设置适当的前缀生存期，以尽量减少重新编号时通信失败的影响。弃用期应足够长，以便在地址无效时，大多数（如果不是全部）通信都在使用新地址。
IP层预计将为上层（包括应用程序）提供一种方法，在给定特定目的地和可能的其他约束的情况下，选择最合适的源地址。应用程序可以在开始新的通信之前选择源地址本身，也可以不指定地址，在这种情况下，上层网络层将使用IP层提供的机制代表应用程序选择合适的地址。
详细的地址选择规则超出了本文档的范围，在[RFC3484]中进行了描述。
5、协议规范

自动配置是在支持组播的接口上按每个接口执行的。对于多宿主主机，自动配置是在每个接口上独立执行的。自动配置主要适用于主机，但有两个例外。路由器应使用以下程序生成链路本地地址。此外，路由器在将所有地址分配给接口之前，会对其执行重复地址检测。
5.1、节点配置变量

节点必须允许系统管理为每个支持组播的接口配置以下与自动配置相关的变量：
DupAddrDetectTransmits：在对临时地址执行重复地址检测时发送的连续邻居请求消息的数量。值为零表示不对临时地址执行重复地址检测。值1表示没有后续重传的单次传输。
默认值：1，但可以被文档中特定于链路类型的值覆盖，该值涵盖了与特定链路类型上的IP传输相关的问题（例如[RFC2464]）。
自动配置还假设存在[RFC4861]中定义的变量RetransTimer。出于自动配置的目的，RetransTimer指定在重复地址检测期间执行的连续邻居请求传输之间的延迟（如果DupAddrDetectTransmits大于1），以及节点在发送最后一个邻居请求后在结束重复地址检测过程之前等待的时间。
5.2、自动配置相关结构

除了形成链路本地地址和使用重复地址检测之外，路由器如何（自动）配置其接口也超出了本文的范围。
主机维护一个地址列表及其相应的生存期。地址列表包含自动配置的地址和手动配置的地址。
5.3、创建链路本地地址

每当接口启用时，节点就会形成一个链路本地地址。在发生以下任何事件后，接口可能会启用：
*接口在系统启动时初始化。
*接口在临时接口故障后或被系统管理临时禁用后重新初始化。
*该接口首次连接到链路。这包括由于无线网络的接入点的改变而动态改变所连接的链路的情况。

*在管理上禁用该接口后，系统管理将启用该接口。

通过将众所周知的链路本地前缀FE80::0[RFC4291]（适当长度）与接口标识符组合，形成链路本地地址，如下所示：
1.地址最左侧的“前缀长度”位是链路本地前缀的位。
2.链路本地前缀右侧地址中的位设置为全零。
3.如果接口标识符的长度为N位，则地址的最右侧N位被接口标识符替换。
如果链路本地前缀长度和N的总和大于128，则自动配置失败，需要手动配置。接口标识符的长度在单独的特定于链路类型的文档中定义，该文档也应与地址架构[RFC4291]一致（见第2节）。这些文档将仔细定义长度，以便在链路上自动配置链路本地地址。
链路本地地址具有无限的首选和有效生存期；它永远不会超时。
5.4、重复地址检测

在将所有单播地址分配给接口之前，必须对其执行重复地址检测，无论它们是通过无状态自动配置、DHCPv6还是手动配置获得的，但以下情况除外：
*DupAddrDetectTransmits变量设置为零的接口不执行重复地址检测。
*不得对任播地址执行重复地址检测（请注意，任播地址在语法上无法与单播地址区分）。
*应测试每个单独的单播地址的唯一性。请注意，部署的实现仅对链路本地地址执行重复地址检测，并跳过对使用与链路本地地址相同的接口标识符的全局地址的测试。尽管本文档不会使这些实现无效，但不建议进行这种“优化”，新的实现也不得进行这种优化。这种优化来自于一个假设，即所有接口的地址都是从同一个标识符生成的。然而，这一假设实际上并不成立；引入了新类型的地址，其中对于单个接口上的所有单播地址，接口标识符不一定相同[RFC4941][RFC3972]。要求对所有单播地址执行重复地址检测将使算法对当前和未来的特殊接口标识符具有鲁棒性。

检测重复地址的过程使用如下所述的Neighbor Solicitation邻居请求和Advertisement通告消息。如果在过程中发现重复地址，则无法将该地址分配给接口。如果地址来自接口标识符，则需要为接口分配新的标识符，或者需要手动配置接口的所有IP地址。请注意，检测重复的方法并不完全可靠，重复地址可能仍然存在（例如，如果在执行重复地址检测时对链路进行了分区）。
在程序成功完成之前，应用重复地址检测程序的地址被称为暂定地址。暂定地址不被认为是传统意义上的“分配给接口”。也就是说，接口必须接受在目标地址字段中包含临时地址的邻居请求和通告消息，但处理此类数据包的方式与目标地址与分配给接口的地址匹配的数据包不同。发往临时地址的其他数据包应被默默丢弃。请注意，“其他数据包”包括邻居请求和通告消息，这些消息将临时（即单播）地址作为IP目的地址，并在目标地址字段中包含临时地址。不过，在正常操作中不应该发生这种情况，因为这些消息是在重复地址检测过程中组播的。
还应注意，在为接口分配地址之前，必须执行重复地址检测，以防止多个节点同时使用同一地址。如果一个节点开始与重复地址检测并行使用地址，而另一个节点已经在使用该地址，则执行重复地址检测的节点将错误地处理发往其他节点的流量，从而导致重置打开的TCP连接等可能的负面后果。
以下小节描述了节点为验证地址的唯一性而执行的具体测试。如果在发送DupAddrDetectTransmits次Neighbor Solicitations后的RetransTimer毫秒内，没有任何测试表明存在重复地址，则认为该地址是唯一的。一旦确定地址是唯一的，就可以将其分配给接口。
5.4.1、消息验证

节点必须默默地丢弃任何未通过[RFC4861]中指定的有效性检查的邻居请求或通告消息。通过这些有效性检查的邻居请求或通告消息分别称为有效请求或有效通告。
5.4.2、发送邻居请求消息

在发送邻居请求之前，接口必须加入所有节点的组播地址和临时地址的请求节点组播地址。前者确保节点从已经使用该地址的其他节点接收邻居通告；后者确保试图同时使用相同地址的两个节点应检测到彼此的存在。
为了检查地址，节点发送DupAddrDetectTransmits次Neighbor Solicitations，每个请求以RetransTimer毫秒分隔。将请求的目标地址设置为正在检查的地址，将IP源设置为未指定的地址，并将IP目的地设置为目标地址的请求节点组播地址。
如果邻居请求将是接口（重新）初始化后从接口发送的第一条消息，则节点应按照[RFC4861]中的规定，以0到MAX_RTR_SOLICITATION_DELAY之间的随机延迟延迟加入请求的节点组播地址。当许多节点同时在链路上启动时，例如在停电后，这有助于缓解拥塞，并且当多个节点试图同时请求同一地址时，这可能有助于避免竞争情况。
即使邻居请求不是发送的第一条消息，如果被检查的地址是由发送到组播地址的路由器通告消息配置的，则节点应延迟加入被请求的节点组播地址，延迟时间为0到MAX_RTR_SOLICIATION_delay之间的随机延迟。当多个节点要通过接收相同的单个组播路由器通告来配置地址时，延迟将避免类似的拥塞。
请注意，当节点加入组播地址时，它通常会为该组播地址发送组播侦听器发现（Multicast Listener Discovery，MLD）报告消息[RFC2710][RFC3810]。在重复地址检测的情况下，需要MLD报告消息来通知MLD侦听交换机而不是路由器转发组播数据包。在上述描述中，加入组播地址的延迟意味着延迟相应MLD报告消息的传输。由于MLD规范不要求随机延迟来避免竞争条件，因此仅仅延迟邻居请求就会导致MLD报告消息的拥塞。然后，拥塞将阻止MLD监听交换机正常工作，从而阻止重复地址检测工作。在这种情况下，包含MLD报告延迟的要求避免了这种情况。[RFC3590]还谈到了重复地址检测和MLD之间的一些交互问题，并指定了在这种情况中MLD报告应使用哪个源地址。
为了提高重复地址检测算法的鲁棒性，接口必须在延迟期间接收和处理发送到临时地址的所有节点组播地址或请求节点组播地址的数据报。这不一定与延迟加入组播组的要求相冲突。事实上，在某些情况下，节点可能会在MLD报告传输之前的延迟期内开始监听该组。然而，应该注意的是，在某些链路层环境中，特别是在MLD监听交换机的情况下，在发送MLD报告之前，没有组播接收可用。
5.4.3、接收邻居请求消息

在接口上收到有效的邻居请求消息后，节点行为取决于目标地址是否是暂定的。如果目标地址不是暂定的（即，它被分配给接收接口），则按照[RFC4861]中的描述处理请求。如果目标地址是暂定的，源地址是单播地址，则请求的发送方正在对目标执行地址解析；应该默默地忽略这一请求。否则，处理过程如下所述。在所有情况下，节点都不得对临时地址的邻居请求做出响应。
如果邻居请求的源地址是未指定的地址，则请求来自执行重复地址检测的节点。如果请求来自另一个节点，则暂定地址是重复的，不应（由任何节点）使用。如果请求来自节点本身（因为节点循环返回组播数据包），则请求并不表示存在重复地址。
实现者注意：许多接口为上层提供了一种有选择地启用和禁用组播数据包循环返回的方法。如何实施此类设施的细节可能会阻止重复地址检测正常工作。更多讨论见附录A。
以下测试确定了临时地址不唯一的条件：
*如果在发送临时地址之前收到邻居请求，则临时地址是重复的。当两个节点同时运行重复地址检测，但在不同时间发送初始请求时（例如，在加入请求的节点组播地址并发送初始请求之前选择不同的随机延迟值），就会发生这种情况。
*如果收到的邻居请求的实际数量超过了基于环路语义的预期数量（例如，接口没有环路数据包，但收到了一个或多个请求），则临时地址是重复的。当两个节点同时运行重复地址检测并大致同时传输请求时，就会发生这种情况。
5.4.4、接收邻居通告消息

在接口上收到有效的邻居通告消息后，节点行为取决于目标地址是暂定的还是与分配给接口的单播或任播地址匹配：
1.如果目标地址是暂定的，则暂定地址不是唯一的。
2.如果目标地址与分配给接收接口的单播地址匹配，则可能表明该地址是重复的，但未被重复地址检测过程检测到（回想一下，重复地址检测并不完全可靠）。如何处理这样的案件超出了本文的范围。
3.否则，如[RFC4861]中所述处理通告。
5.4.5、当重复地址检测失败时

如上所述，被确定为重复的临时地址不得分配给接口，节点应记录系统管理错误。
如果该地址是由基于硬件地址的接口标识符形成的链路本地地址，并且应该是唯一分配的（例如，以太网接口的EUI-64），则应禁用接口上的IP操作。通过禁用IP操作，节点将：
*不从接口发送任何IP分组，
*静默丢弃接口上接收到的任何IP数据包，以及
*不向接口转发任何IP数据包（当充当路由器或处理具有路由报文头的数据包时）。
在这种情况下，IP地址重复可能意味着正在使用重复的硬件地址，试图通过配置另一个IP地址从中恢复不会导致可用的网络。事实上，它可能会造成比仅禁用接口上的网络操作更难诊断的问题，从而使情况变得更糟；用户将看到一个部分工作的网络，其中一些设备工作，而其他设备不工作。
另一方面，如果重复链路本地地址不是由基于硬件地址的接口标识符形成的，则可以继续在接口上进行IP操作，该硬件地址应该是唯一分配的。
注：如第2节所述，上述描述中的“IP”是指“IPv6”。虽然硬件地址的背景原理与特定的网络协议无关，但它对其他协议的影响超出了本文的范围。
5.5、创建全局地址

全局地址是通过在适当长度的前缀后附加接口标识符而形成的。前缀是从路由器通告中包含的前缀信息选项中获得的。本节所述的全局地址的创建应该是本地可配置的。但是，默认情况下必须启用下面描述的处理。

5.5.1、请求路由器通告

路由器通告定期发送到所有节点的组播地址。为了快速获得通告，主机发出[RFC4861]中所述的路由器请求。
5.5.2、没有路由器通告

即使链路没有路由器，用于获取地址的DHCPv6服务可能仍然可用，主机可能希望使用该服务。从自动配置的角度来看，如果在发送了少量路由器请求后没有收到路由器通告，则链路没有路由器，如[RFC4861]所述。
请注意，从这个意义上讲，链路上可能没有路由器，但有一个节点有能力转发数据包。在这种情况下，必须在主机中手动配置转发节点的地址，以便能够在链路外发送数据包，因为自动配置默认路由器地址的唯一机制是使用路由器通告的机制。
5.5.3、路由器通告处理

对于路由器通告中的每个前缀信息选项：
a） 如果未设置自治标志，则忽略前缀信息选项。
b） 如果前缀是链路本地前缀，则忽略“前缀信息”选项。
c） 如果首选生存期大于有效生存期，则忽略前缀信息选项。在这种情况下，节点可能希望记录系统管理错误。
d） 如果通告的前缀不等于与接口关联的地址列表中已有的由无状态自动配置配置的地址的前缀（其中“相等”表示两个前缀长度相同，前缀的第一个前缀长度位相同），并且如果有效生存期不为0，则通过将通告的前缀与链路的接口标识符组合来形成地址（并将其添加到列表中），如下所示：

如果前缀长度和接口标识符长度之和不等于128位，则必须忽略前缀信息选项。在这种情况下，实现可能希望记录系统管理错误。接口标识符的长度在单独的特定于链路类型的文档中定义，该文档也应与地址架构[RFC4291]一致（见第2节）。
系统管理员有责任确保路由器通告中包含的前缀长度与该链路类型的接口标识符长度一致。然而，应该指出的是，这并不意味着所宣传的前缀长度没有意义。事实上，在[RFC4861]中，所通告的长度对于链路上的确定具有重要意义，其中前缀长度和接口标识符长度之和可能不等于128。因此，在这里验证通告的前缀长度应该是安全的，以便在地址自动配置的上下文中检测和避免指定无效前缀长度的配置错误。
请注意，地址架构[RFC4291]的未来修订版和未来的链路类型特定文档（仍将保持一致）可能允许长度不同于当前文档中定义的值的接口标识符。因此，一个实现不应该假设一个特定的常数。相反，它应该期望任何长度的接口标识符。
如果地址已成功形成，但该地址尚未出现在列表中，则主机会将其添加到分配给接口的地址列表中，并从前缀信息选项初始化其首选和有效的生存期值。请注意，在此步骤开始时执行的前缀检查并不总是能检测到列表中的地址冲突。列表中已有的地址，无论是手动配置还是通过DHCPv6配置，都可能与新创建的地址相同，而这种情况应该是非典型的。
e） 如果所通告的前缀等于列表中由无状态自动配置方式配置的地址的前缀，则该地址的优选生存期将重置为接收到的通告中的首选生存期。为地址的有效生存期执行的具体操作取决于接收到的通告中的有效生存时间以及之前自动配置的地址的有效生命期到期的剩余时间。在以下讨论中，我们将剩余时间称为“RemainingLifetime”：
1.如果收到的有效生存期大于2小时或大于RemainingLifetime，请将相应地址的有效生存时间设置为通告的有效生存期限。
2.如果RemainingLifetime小于或等于2小时，则忽略与有效生存期相关的前缀信息选项，除非获得此选项的路由器通告已通过身份验证（例如，通过安全邻居发现[RFC3971]）。如果路由器通告经过身份验证，则应在接收选项中将相应地址的有效生存期设置为有效生存期。
3.否则，将相应地址的有效生存期重置为2小时。
上述规则针对一种特定的拒绝服务攻击，其中虚假通告可能包含具有非常小的有效生命周期的前缀。如果没有上述规则，一个包含虚假前缀信息选项且有效生存期较短的未经身份验证的通告可能会导致节点的所有地址提前过期。上述规则确保合法通告（定期发送）在实际生效之前“取消”短暂的有效生命周期。
请注意，在接收到的前缀信息选项中，相应地址的首选生存期始终重置为首选生存期，而不管有效生存期是否也重置或忽略。区别在于，在首选生命周期内可能发生的攻击相对较小。此外，当有效管理员希望通过发送较短的首选生存期来弃用特定地址时，甚至不希望忽略首选生存期（而有效生存期被意外忽略）。
5.5.4、地址生命周期到期

当首选地址的首选生存期到期时，首选地址将被弃用。弃用地址应继续用作现有通信中的源地址，但如果可以很容易地使用足够范围的替代（非弃用）地址，则不应将其用于发起新的通信。

请注意，使用非弃用地址发起新通信的可行性可能是特定于应用程序的决定，因为只有应用程序可能知道（现在）弃用的地址是否正在（或仍然）被应用程序使用。例如，如果应用程序明确指定协议栈使用弃用的地址作为源地址，则协议栈必须接受这一点；应用程序可能会请求它，因为该IP地址用于更高级别的通信，并且可能要求这种分组中的多个连接使用同一对IP地址。
IP和更高层（如TCP、UDP）必须继续正常接受和处理发往弃用地址的数据报，因为弃用地址仍然是接口的有效地址。在TCP的情况下，这意味着发送到弃用地址的TCP SYN段将使用该弃用地址作为相应SYN-ACK中的源地址进行响应（如果不允许连接）。

实现可能会阻止任何新的通信使用已弃用的地址，但系统管理必须能够禁用此类设施，并且默认情况下必须禁用该设施。
关于源地址选择，还应注意其他微妙的情况。例如，上述描述没有澄清在弃用的较小范围地址和非弃用的足够范围地址之间应该使用哪个地址。[RFC3484]中描述了包括这种情况在内的地址选择的细节，这些细节超出了本文档的范围。
地址（及其与接口的关联）在其有效生存期到期时无效。无效地址不得用作传出通信中的源地址，也不得在接收接口上被识别为目的地。
5.6、配置一致性

主机可以使用无状态自动配置和DHCPv6来获取地址信息，因为两者可以同时启用。也可能从路由器通告和DHCPv6中学习其他配置参数的值，如MTU大小和跳数限制。如果多个来源提供了相同的配置信息，则此信息的值应保持一致。然而，如果从多个来源收到的信息不一致，则不认为是致命错误。主机接受通过邻居发现和DHCPv6接收到的所有信息的联合。
如果从不同来源学习到不一致的信息，则实现可能希望让安全学习的信息优先于没有保护的学习信息。例如，[RFC3971]的第8节讨论了如何处理通过安全邻居发现学习到的信息与通过普通邻居发现学习的信息冲突。同样的讨论也适用于通过普通邻居发现学习的信息和通过安全DHCPv6学习的信息之间的偏好，等等。
在任何情况下，如果没有安全差异，最近获得的值应该优先于之前学习到的信息。
5.7、保留已配置的地址以确保稳定性

具有稳定存储的实现可能希望在使用无状态地址自动配置获取地址时将地址保留在存储中。假设使用的生存期是合理的，这种技术意味着即使节点重新启动，路由器的临时中断（小于有效生存期）也永远不会导致节点的全局地址丢失。使用此技术时，还应注意必须保留首选和有效生命周期的到期时间，以防止在地址被弃用或无效后使用。
关于这种扩展的更多细节超出了本文的范围。
6、安全注意事项

无状态地址自动配置允许主机连接到网络，配置地址，并开始与其他节点通信，而无需在本地站点进行注册或身份验证。虽然这允许未经授权的用户连接和使用网络，但这种威胁在互联网架构中是固有的。任何与网络有物理连接的节点都可以生成提供连接的地址（使用各种自组织技术）。
使用无状态地址自动配置和重复地址检测可能会引发多次拒绝服务攻击。例如，任何节点都可以响应邻居请求以获取临时地址，导致另一个节点将该地址作为重复地址拒绝。另一份文件[RFC3756]讨论了这些攻击的详细信息，这些攻击可以通过安全邻居发现协议[RFC3971]来解决。还应注意的是，[RFC3756]指出，根据网络环境的不同，使用IP安全并不总是可行的。
7、致谢

Thomas Narten和Susan Thompson是1971年和2462年RFC的作者。对于RFC的这次修订，Tatuya Jinmei是唯一的编辑。
RFC 2461的作者要感谢IPNG（现在是IPV6）和ADDRCONF工作组的成员提供的意见。特别要感谢Jim Bound、Steve Deering、Richard Draves和Erik Nordmark。还要感谢John Gilmore提醒WG注意“0生存期前缀通告”拒绝服务攻击漏洞；本文档包含了解决此漏洞的更改。
许多人为识别RFC 2461的问题做出了贡献，并为本版本文档中反映的问题提出了解决方案。除上述人员外，撰稿人还包括Jari Arkko、James Carlson、Brian E.Carpenter、Gregory Daley、Elwyn Davies、Ralph Droms、Junichiro Itojun Hagino、Christian Huitema、Suresh Krishnan、Soohong Daniel Park、Markku Savela、Pekka Savola、Hemant Singh、Bernie Volz、Margaret Wasserman和Vlad Yasevich。
8、参考文献

8.1、规范性引用文件

[RFC2464] Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464, December 1998.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, RFC 4861, September 2007.
8.2、资料性引用

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 3315, July 2003.
[RFC3484] Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6)”, RFC 3484, February 2003.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, RFC 4941, September 2007.
[RFC3972] Aura, T., “Cryptographically Generated Addresses (CGA)”, RFC 3972, March 2005.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, “Multicast Listener Discovery (MLD) for IPv6”, RFC 2710, October 1999.
[RFC3810] Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6”, RFC 3810, June 2004.
[RFC3590] Haberman, B., “Source Address Selection for the Multicast Listener Discovery (MLD) Protocol”, RFC 3590, September 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND)”, RFC 3971, March 2005.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, “IPv6 Neighbor Discovery (ND) Trust Models and Threats”, RFC 3756, May 2004.
[RFC1112] Deering, S., “Host extensions for IP multicasting”, STD 5, RFC 1112, August 1989.
[IEEE802.11] IEEE, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”, ANSI/IEEE STd 802.11, August 1999.
附录A：环路抑制和重复地址检测

确定接收到的组播请求是环路发送方还是实际上来自另一个节点取决于实现。当连接到同一链路的两个接口恰好具有相同的标识符和链路层地址，并且它们几乎同时发送内容相同的数据包时，就会出现问题（例如，作为重复地址检测消息的一部分，邻居请求临时地址）。虽然接收器将接收这两个数据包，但它无法仅通过比较数据包内容（即内容相同）来确定哪个数据包被环路，哪个数据包来自其他节点。在这种特殊情况下，不需要精确地知道哪个数据包被环路，哪个数据包是由另一个节点发送的；如果收到的邀请多于发送的邀请，则暂定地址是重复的。然而，情况可能并不总是如此简单。
IPv4组播规范[RFC1112]建议服务接口为上层协议提供一种方法，以禁止向发送主机所属的组播组发送数据包的本地传递。一些应用程序知道同一主机上没有其他组成员，抑制环路可以防止它们不得不接收（和丢弃）自己发送的数据包。实现此功能的一种简单方法是在硬件级别禁用环路（如果硬件支持），并通过软件环路数据包（如果请求）。在硬件本身抑制环路的接口上，运行重复地址检测的节点只需对临时地址收到的邻居请求数量进行计数，并将其与预期数量进行比较。如果不匹配，则暂定地址是重复的。
然而，在硬件无法抑制环路的情况下，过滤掉不需要的环路的一种可能的软件启发式方法是丢弃任何链路层源地址与接收接口相同的接收到的数据包。甚至有一个链路层规范要求丢弃任何此类数据包[IEEE802.11]。不幸的是，使用该标准也会导致丢弃使用相同链路层地址的另一个节点发送的所有数据包。重复地址检测将在以这种方式过滤接收到的数据包的接口上失败：
*如果执行重复地址检测的节点丢弃了与接收接口具有相同源链路层地址的接收数据包，它还将丢弃来自也使用相同链路层地址其他节点的数据包，包括所需的邻居通告和邻居请求消息
重复地址检测工作正常。如果可以禁用抑制，则可以通过在节点执行重复地址检测时临时禁用软件对环路的抑制来避免这个特殊问题。
*如果已经使用特定IP地址的节点丢弃了与接口具有相同链路层源地址的接收到的数据包，它还将丢弃由也使用相同链路层地址的另一个节点发送的与重复地址检测相关的邻居请求消息。因此，重复地址检测将失败，另一个节点将配置一个非唯一地址。由于通常不可能知道另一个节点何时正在执行重复地址检测，因此只有在永久禁用环路软件抑制的情况下才能避免这种情况。
因此，为了在两个接口使用相同链路层地址的情况下正确执行重复地址检测，实现必须很好地理解接口的组播环路语义，并且接口不能仅仅因为源链路层地址与接口的地址相同就丢弃接收到的数据包。还应该注意的是，链路层规范可能与使重复地址检测工作所需的条件相冲突。
附录B：对比RFC 1971的变化

*将文档更改为使用术语“接口标识符”而不是“接口令牌”，以与其他IPv6文档保持一致。
*澄清了弃用地址的定义，以明确可以继续向或从弃用地址发送。
*在第5.5.3节“路由器通告处理”中添加了规则，以解决在以非常短的生命周期通告前缀时可能发生的拒绝服务攻击。
*澄清第5.5.4节中的措辞，明确所有上层协议必须处理（即发送和接收）发送到弃用地址的数据包。
附录C：对比RFC 2462的变化

可能影响现有实现的主要更改：
*指定执行重复地址检测的节点延迟加入被请求节点组播组，而不仅仅是延迟发送邻居请求，并解释了详细原因。
*如果正在检查的地址是由组播路由器通告配置的，则在发送邻居请求进行重复地址检测之前增加了随机延迟的要求。
*澄清了在重复地址检测失败时，应禁用IP网络操作，并且当硬件地址应该是唯一的时，应应用该规则。
主要澄清：
*阐明了如何确定接口标识符的长度，描述了与路由器通告中通告的前缀长度的关系，并避免在本文档中使用特定的硬编码长度。
*阐明了在执行重复地址检测时对接收到的邻居通告的处理。
*考虑到实现的成熟度和操作经验，删除了关于M和O标志的文本。Managed Flag和OtherConfig Flag已相应删除。（请注意，此更改并不意味着不推荐使用这些标志。）
*避免了“有状态配置”的措辞，众所周知，这非常令人困惑，在适当的情况下只使用了“DHCPv6”。
*建议对所有单播地址执行更强烈的重复地址检测，考虑各种不同的接口标识符，同时注意现有的实现。
*澄清第5.5.4节中的措辞，以明确应用程序指定的弃用地址可用于任何通信。
*使用更合适的术语澄清了第5.5.3节中描述的前缀检查，并且检查是针对无状态自动配置配置的地址前缀进行的。
*将对IP安全身份验证报文头的引用更改为对RFC 3971（安全邻居发现）的引用。还参考RFC 3756修订了安全考虑部分。
*当实现使用稳定存储来自动配置地址时，添加了一条注释。
*增加了对不一致信息集之间偏好的考虑，一个来自安全来源，另一个是在没有保护的情况下学习的。
其他杂项澄清：
*删除了对站点本地的引用，并修改了关键字周围的措辞。
*删除了第5.5.3节中拒绝服务保护中的冗余代码。
*澄清在执行重复地址检测时，应丢弃已通信的邻居请求或通告。
*第5.3节指出，当无线接入点发生变化时，接口可以被视为已启用。
完整版权声明

版权所有（C）IETF信托（2007）。
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文件和其中包含的信息是按“原样”提供的，贡献者、他/她代表或赞助的组织（如有）、互联网协会、IETF信托和互联网工程任务组否认所有明示或暗示的保证，包括但不限于使用本文件中的信息不会侵犯任何权利或对适销性或特定用途适用性的任何暗示保证。
知识产权

IETF对可能声称与本文档所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不持任何立场；它也不代表它已经做出了任何独立的努力来确定任何此类权利。有关RFC文档中权限程序的信息，请参阅BCP 78和BCP 79。
向IETF秘书处披露的知识产权副本以及提供许可证的任何保证，或本规范的实施者或用户试图获得使用此类专有权利的一般许可或许可的结果，可以从IETF在线知识产权存储库获得，网址为http://www.ietf.org/ipr.
IETF邀请任何利益相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准所需技术的其他专有权利。请将信息发送至IETFietf-ipr@ietf.org。