RFC4861 中文版下

10. 协议常量

路由器常量:

        MAX_INITIAL_RTR_ADVERT_INTERVAL  16 秒MAX_INITIAL_RTR_ADVERTISEMENTS    3 次发送MAX_FINAL_RTR_ADVERTISEMENTS      3 次发送MIN_DELAY_BETWEEN_RAS             3 秒MAX_RA_DELAY_TIME                 .5 秒

主机常量:

        MAX_RTR_SOLICITATION_DELAY        1 秒RTR_SOLICITATION_INTERVAL         4 秒MAX_RTR_SOLICITATIONS             3 次发送

节点常量:

        MAX_MULTICAST_SOLICIT             3 次发送MAX_UNICAST_SOLICIT               3 次发送MAX_ANYCAST_DELAY_TIME            1 秒MAX_NEIGHBOR_ADVERTISEMENT        3 次发送REACHABLE_TIME               30,000 毫秒RETRANS_TIMER                 1,000 毫秒DELAY_FIRST_PROBE_TIME            5 秒MIN_RANDOM_FACTOR                 .5MAX_RANDOM_FACTOR                 1.5

在第 4 节的消息格式中定义了其他协议常量。

所有协议常量可能会在未来版本中进行更改。

本规范中的常量可以被描述 IPv6 在不同链路层上运行的特定文档所覆盖。
此规则允许邻居发现在性能特性差异很大的各种链路上运行。

11. 安全考虑

邻居发现受到会导致 IP 数据包流向意外位置的攻击影响。这类攻击可能导致拒绝服务，也可能使节点拦截并可选择修改发送给其他节点的数据包。本节讨论了与邻居发现消息相关的主要威胁以及可能减轻这些威胁的安全机制。

11.1. 威胁分析

本节讨论了与邻居发现相关的主要威胁。[PSREQ] 中有更详细的分析。该协议的主要漏洞分为三类：

• 拒绝服务 (DoS) 攻击。
• 地址欺骗攻击。
• 路由器欺骗攻击。

拒绝服务攻击的一个示例是，可以发送具有任意 IP 源地址的数据包的链接上的节点，可以同时将自己广告为默认路由器，并发送“伪造”的路由器广告消息，立即使所有其他默认路由器以及所有本地前缀超时。攻击者可以通过发送多个路由器广告（每个广告对应一个合法的路由器），其中源地址设置为另一个路由器的地址，路由器生存期字段设置为零，并为所有前缀设置零的首选和有效生存期来实现此目的。此类攻击将导致所有传输到本地和跨本地目的地的数据包都发送到恶意路由器。然后，该路由器可以有选择地检查、修改或丢弃链路上发送的所有数据包。只要恶意路由器礼
貌地用带有设置 R 位的 Neighbor Advertisement 作出邻居不可达检测（NUD）的回应，NUD 就无法检测到这种黑洞。

任何主机也可以通过阻止另一台主机使用 [ADDRCONF] 配置地址来对另一台主机发起 DoS 攻击。该协议不允许主机验证发送 Neighbor Advertisement 的发送者是否是该消息中所包含的 IP 地址的真实所有者。

重定向攻击也可以由任何主机发起，以淹没受害者或窃取其流量。主机可以发送一个包含其 IP 地址和受害者链路层地址的 Neighbor Advertisement（作为响应）以向受害者发送不必要的流量。另外，主机可以发送一个包含受害者 IP 地址和自身链路层地址的 Neighbor Advertisement，以覆盖发送方目标缓存中的现有条目，从而强制发送方将所有受害者的流量转发到自身。

重定向的信任模型与 IPv4 相同。仅当来自当前用于该目的地的相同路由器接收到重定向时才会被接受。如果主机已被重定向到另一个节点（即，目的地在链路上），则无法防止目标发出另一个重定向到其他目的地。但是，在被重定向之前，目标主机暴露的风险并不比以前更糟；一旦被破坏，目标主机始终可以充当隐藏的路由器，将流量转发到其他地方。

该协议没有机制来确定哪些邻居被授权发送特定类型的消息（例如路由器通告）；任何邻居，甚至在进行身份验证的情况下，都可以发送路由器通告消息，从而能够导致拒绝服务。此外，任何邻居也可以发送代理 Neighbor Advertisement 以及未经请求的 Neighbor Advertisement，这可能导致拒绝服务攻击。

许多链路层也容易受到不同的拒绝服务攻击，例如在 CSMA/CD（载波侦听多路访问与碰撞检测）网络中持续占用链路（例如，通过紧密地发送数据包或在链路上断言冲突信号），或使用别人的源 MAC 地址生成数据包以混淆例如以太网交换机。另一方面，该部分讨论的许多威胁在点对点链接或移动网络中效果较低或不存在，因为主机只与一个邻居（即默认路由器）共享链接。

11.2. 邻居发现消息的安全保护

在没有身份验证的情况下，该协议通过忽略来自非本地发送者的 ND 数据包来减少上述威胁的暴露。验证所有接收到的数据包的跳数限制字段是否包含 255，即最大的合法值。因为路由器会减少它们转发的所有数据包的跳数限制，所以具有 255 跳数限制的接收数据包必须来自邻居。

邻居发现的加密安全机制超出了本文档的范围，并在 [SEND] 中定义。另外，IPsec 可用于 IP 层身份验证 [IPv6-SA]。然而，使用 Internet 密钥交换（IKE）不适用于创建可以用于保护地址解析或邻居请求消息的动态安全关联，如 [ICMPIKE] 中所述。

在某些情况下，可能可以接受使用静态配置的安全关联，使用 [IPv6-AUTH] 或 [IPv6-ESP] 来保护邻居发现消息。但是，重要的是要注意静态配置的安全关联并不具有可扩展性（特别是在考虑多播链路时），因此仅限于已知主机的小型网络。在任何情况下，如果使用了 [IPv6-AUTH] 或 [IPv6-ESP]，那么必须验证 ND 数据包以进行身份验证。未通过身份验证检查的数据包必须被静默丢弃。

12. 重新编号考虑因素

邻居发现协议与 IPv6 地址自动配置 [ADDRCONF] 一起提供了有助于重新编号的机制 – 新前缀和地址可以被引入，旧的前缀可以被废弃并删除。

这些机制的健壮性基于链路上所有节点及时接收到路由器通告消息。然而，主机可能关闭或长时间不可达（即，在项目终止后的几个月内关闭计算机）。在这种情况下也可能保留健壮的重新编号，但这对于要广播的前缀的生存期有一些限制。

考虑以下示例，其中一个前缀最初以 2 个月的生存期进行广告宣传，但到了 8 月 1 日确定需要由于重新编号而在 9 月 1 日之前废弃和删除该前缀。可以通过在 8 月 1 日开始将广告生存期减少到 1 周来实现此目的，随着截止日期的临近，生存期可以缩短，直到 9 月 1 日前，前缀的生存期为 0。关键是，如果一个或多个节点在 9 月 1 日之前被拔下，它们可能仍然认为前缀是有效的，因为它们收到的最后一个生存期为 2 个月。因此，如果一个节点在 7 月 31 日被拔下，它可能会认为前缀有效直到 9 月 30 日。如果该节点在 9 月 30 日之前重新连接，则可能继续使用旧的前缀。强制要求停止使用先前以较长生存期广告的前缀的唯一方法是使该节点接收到更改生存期的该前缀的广告。在此示例中的解决方案很简单：从 9 月 1 日到 10 月 1 日继续以生存期 0 广告该前缀。

总的来说，为了对可能从链路上拔出的节点保持健壮性，重要的是要跟踪某个特定前缀对于任何链路上的节点而言可以被视为有效的最长时间。然后，该前缀必须在未来的某个时间点之前以 0 生存期广告。这个“未来最长时间”就是所有路由器通告中的最大时间，加上广告中包含的前缀生存期。

以上对于使用无限生存期的重要含义。如果一个前缀以无限生存期进行广告，然后该前缀以后需要重新编号，则不希望永远以 0 生存期广告该前缀。因此，应该避免无限生存期，或者必须对主机在从链路上拔出后重新连接之前可以断开连接的时间进行限制。然而，网络管理员如何强制对主机（例如笔记本电脑）断开连接的时间进行限制尚不清楚。

网络管理员应认真考虑使用相对较短的生存期（即，不超过几周）。虽然使用长生存期似乎有助于确保健壮性，但实际上，在没有正常运行的路由器的情况下，主机将无法进行通信。此类路由器将发送包含适当（且当前）前缀的路由器通告。连接到没有正常运行路由器的网络的主机可能会遇到比缺乏有效前缀和地址更严重的问题。

13. IANA Considerations

本文档不需要分配任何新的 ICMPv6 类型或代码。但是，现有的 ICMPv6 类型已更新为指向本文档，而不是 RFC 2461。关于分配 ICMPv6 类型/代码的程序在 [ICMPv6] 的第 6 节中描述。

本文档继续使用 RFC 2461 中引入并已由 IANA 分配的以下 ICMPv6 消息类型：

  消息名称                            ICMPv6 类型路由器请求（Router Solicitation）         133路由器通告（Router Advertisement）        134邻居请求（Neighbor Solicitation）         135邻居通告（Neighbor Advertisement）        136重定向（Redirect）                       137

本文档继续使用 RFC 2461 中引入并已由 IANA 分配的以下邻居发现选项类型：

  选项名称                            类型源链路层地址（Source Link-Layer Address）       1目标链路层地址（Target Link-Layer Address）     2前缀信息（Prefix Information）                  3重定向的报头（Redirected Header）               4MTU                                           5

邻居发现选项类型的分配使用以下程序：

1. IANA 应从 IETF RFC 出版物中分配并永久注册新的选项类型。这适用于所有来自 IETF 并已获得 IESG 批准出版的标准跟踪、信息和实验状态的 RFC 类型。

2. 具有工作组共识和区域主任批准的 IETF 工作组可以向 IANA 请求可重新分配的邻居发现选项类型分配。IANA 将将这些值标记为“将来可重新分配”。

“将来可重新分配”标记将在发布记录协议的 RFC（如 1 所定义）时被移除。这将使分配变为永久，并更新 IANA 网页上的参考。

当选项类型值被分配 85% 时，IETF 将审查标记为“将来可重新分配”的分配，并通知 IANA 应该收回和重新分配哪些选项。

3. 来自 IETF 以外的新选项类型值分配请求仅通过发布 IETF 文档进行，根据 1) 上述。同时请注意，“RFC 编辑贡献” [RFC3667] 不被视为 IETF 文档。

14. References

14.1. Normative References

[ADDR-ARCH] Hinden, R. 和 S. Deering, “IP Version 6 Addressing
Architecture”, RFC 4291, 2006年2月.

[ICMPv6] Conta, A.，Deering, S. 和 M. Gupta, 编辑，“Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification”, RFC 4443,
2006年3月.

[IPv6] Deering, S. 和 R. Hinden，“Internet Protocol, Version 6
(IPv6) Specification”, RFC 2460, 1998年12月.

[KEYWORDS] Bradner, S.，“Key words for use in RFCs to Indicate
Requirement Levels”, BCP 14, RFC 2119, 1997年3月.

14.2. Informative References

[ADDRCONF] Thomson, S.，Narten, T. 和 T. Jinmei，“IPv6 Stateless
Address Autoconfiguration”, RFC 4862, 2007年9月.

[ADDR-SEL] Draves, R.，“Default Address Selection for Internet
Protocol version 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, 1982年11月.

[ASSIGNED] Reynolds, J.，编辑，“Assigned Numbers: RFC 1700 is
Replaced by an On-line Database”, RFC 3232, 2002年1月.

[DHCPv6] Droms, R.，编辑，Bound, J.，Volz, B.，Lemon, T.，Perkins,
C. 和 M. Carney，“Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)”, RFC 3315, 2003年7月.

[HR-CL] Braden, R.，编辑，“Requirements for Internet Hosts -
Communication Layers”, STD 3, RFC 1122, 1989年10月.

[ICMPIKE] Arkko, J.，“Effects of ICMPv6 on IKE”, Work in Progress,
2003年3月.

[ICMPv4] Postel, J.，“Internet Control Message Protocol”, STD 5,
RFC 792, 1981年9月.

[IPv6-3GPP] Wasserman, M.，编辑，“Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards”, RFC
3314, 2002年9月.

[IPv6-CELL] Arkko, J.，Kuijpers, G.，Soliman, H.，Loughney, J. 和
J. Wiljakka，“Internet Protocol Version 6 (IPv6) for
Some Second and Third Generation Cellular Hosts”, RFC
3316, 2003年4月.

[IPv6-ETHER] Crawford, M.，“Transmission of IPv6 Packets over
Ethernet Networks”, RFC 2464, 1998年12月.

[IPv6-SA] Kent, S. 和 K. Seo，“Security Architecture for the
Internet Protocol”, RFC 4301, 2005年12月.

[IPv6-AUTH] Kent, S.，“IP Authentication Header”, RFC 4302, 2005年12月.

[IPv6-ESP] Kent, S.，“IP Encapsulating Security Payload (ESP)”, RFC
4303, 2005年12月.

[IPv6-NBMA] Armitage, G.，Schulter, P.，Jork, M. 和 G. Harter，
“IPv6 over Non-Broadcast Multiple Access (NBMA)
networks”, RFC 2491, 1999年1月.

[LD-SHRE] Hinden, R. 和 D. Thaler，“IPv6 Host-to-Router Load
Sharing”, RFC 4311, 2005年11月.

[MIPv6] Johnson, D.，Perkins, C. 和 J. Arkko，“Mobility
Support in IPv6”, RFC 3775, 2004年6月.

[MLD] Deering, S.，Fenner, W. 和 B. Haberman，“Multicast
Listener Discovery (MLD) for IPv6”, RFC 2710, 1999年10月.

[MLDv2] Vida, R.，编辑，和 L. Costa，编辑，“Multicast Listener
Discovery Version 2 (MLDv2) for IPv6”, RFC 3810, 2004年6月.

[PSREQ] Nikander, P.，编辑，Kempf, J. 和 E. Nordmark，“IPv6
Neighbor Discovery (ND) Trust Models and Threats”, RFC
3756, 2004年5月.

[RAND] Eastlake, D.，第三版，Schiller, J. 和 S. Crocker，
“Randomness Requirements for Security”, BCP 106, RFC
4086, 2005年6月.

[RDISC] Deering, S.，编辑，“ICMP Router Discovery Messages”, RFC
1256, 1991年9月.

[RFC3667] Bradner, S.，“IETF Rights in Contributions”, RFC 3667,
2004年2月.

[RTSEL] Draves, R. 和 D. Thaler，“Default Router Preferences
and More-Specific Routes”, RFC 4191, 2005年11月.

[SH-MEDIA] Braden, B.，Postel, J. 和 Y. Rekhter，“Internet
Architecture Extensions for Shared Media”, RFC 1620, 1994年5月.

[SEND] Arkko, J.，编辑，Kempf, J.，Zill, B. 和 P. Nikander，
“SEcure Neighbor Discovery (SEND)”, RFC 3971, 2005年3月.

[SYNC] S. Floyd, V. Jacobson，“The Synchronization of Periodic
Routing Messages”, IEEE/ACM Transactions on Networking,
1994年4月. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z

附录 A：多宿主机

当使用邻居发现的主机具有多个接口时，会出现许多复杂的问题。本节不尝试定义关于邻居发现的多宿主机的正确操作。相反，它确定了需要进一步研究的问题。鼓励实施者尝试各种方法使邻居发现在多宿主机上工作，并报告他们的经验。与此问题相关的进一步工作可在 [RTSEL] 中找到。

如果多宿主机在所有接口上都接收到路由器通告，则（可能）已经学习到了每个链路上驻留地址的本地前缀。然而，当数据包必须通过路由器发送时，选择“错误”的路由器可能导致子优化或不正常工作的路径。需要考虑的问题有：

 1) 为了路由器能够发送重定向，它必须确定它正在转发的数据包源自邻居。这种情况的标准测试是将数据包的源地址与接收到数据包的接口关联的本地前缀列表进行比较。然而，如果发起主机是多宿主机，则它使用的源地址可能属于不同于发送接口的其他接口。在这种情况下，路由器不会发送重定向，并且可能出现子优化路由。为了被重定向，发送主机必须始终通过与出站数据包的源地址对应的接口发送数据包。请注意，这个问题在非多宿主机上永远不会出现；它们只有一个接口。关于这个主题的更多讨论可以在RFC 1122的第3.3.4.2节中找到。2) 如果选择的第一跳路由器对目标没有任何路由，它将无法传递数据包。然而，目标可能通过其他接口的路由器可达。邻居发现不涉及此场景；在非多宿主机情况下不会出现此情况。3) 即使第一跳路由器对目的地有路由，可能会有通过其他接口更好的路由。多宿主机没有机制来检测这种情况。

如果多宿主机在其一个或多个接口上未收到路由器通告，则（在没有配置信息的情况下）不会知道哪些目的地在受影响接口的链路上。这导致了以下问题：如果在一些接口上收到了路由器通告，但不是全部接口，则多宿主机可以选择仅在收到路由器通告的接口上发送数据包。然而，这里做出的一个关键假设是，那些其他接口上的路由器将能够将数据包路由到最终目的地，即使那些目的地驻留在发送者连接的子网上，但没有本地前缀信息。如果假设是错误的，通信将失败。即使假设成立，数据包也将经过非最佳路径。

附录 B：未来扩展

未来研究的可能扩展包括：

o 使用动态定时器以适应延迟差异很大的链路。然而，测量往返时间需要确认和序列号，以便将接收到的邻居通告与实际触发通告的邻居请求匹配。希望使用这种功能的实施者可以通过定义携带所需信息的新选项以向后兼容的方式进行尝试。不理解该选项的节点将简单地忽略它。o 添加能力以促进在当前需要主机向地址解析服务器注册的链路上的操作。例如，这可以使路由器要求主机定期发送未经请求的通告给它们。再次强调，这可以通过在路由器通告中发送新选项来添加。o 为对称和非传递可达性是正常操作的链路添加额外的程序。这种程序可能允许主机和路由器在例如无线链路上找到可用路径。

附录 C：可达性状态的状态机

本附录包含了在第7.2节和7.3节中指定的规则的摘要。本文档并不要求实现遵循该模型，只要其外部行为与本文档中描述的行为一致即可。

在执行地址解析和邻居不可达检测时，使用概念模型的以下状态转换适用：

状态 事件 动作 新状态

•           要发送数据包。          创建条目。             不完整发送组播 NS。启动重传计时器
  

不完整 重传超时，小于 N 重传 NS 不完整
重传次数。 启动重传计时器

不完整 重传超时，N 或更多 丢弃条目 -
重传次数。

不完整 NA，Solicited=0， 记录链路层地址。 陈旧
Override=any 发送排队的数据包。

不完整 NA，Solicited=1， 记录链路层地址。 可达
Override=any 发送排队的数据包。

不完整 NA，Solicited=any， 更新 IsRouter 标志 未改变
Override=any，没有 的内容
链路层地址

-              NS，RS，Redirect            -                    -没有链路层地址

!不完整 NA，Solicited=1， - 可达
Override=0
与缓存的相同
链路层地址。

!不完整 NA，Solicited=any， 更新 IsRouter 标志 未改变
Override=any，没有 的内容。
链路层地址
可达 NA，Solicited=1， - 陈旧
Override=0
与缓存的不同
链路层地址。

陈旧，探测 发送数据包 启动延迟计时器 延迟

延迟 延迟超时 发送单播 NS 探测 探测
启动重传计时器

探测 重传超时，小于 N 重传 NS 探测
重传次数。

探测 重传超时，N 或更多 丢弃条目 -
重传次数。
除邻居通告消息外，接收到的其他未经请求的信息的状态转换适用于数据包的源地址（对于邻居请求、路由器请求和路由器通告消息）或目标地址（对于重定向消息）如下：

状态 事件 动作 新状态

•           NS，RS，RA，Redirect    创建条目。            陈旧
  

不完整 NS，RS，RA，Redirect 记录链路层地址。 陈旧
发送排队的数据包。

!不完整 NS，RS，RA，Redirect 更新链路层地址 陈旧
不同的链路层地址
与缓存的。

不完整 NS，RS 没有链路层地址 - 未改变

!不完整 NS，RS，RA，Redirect - 未改变
与缓存的相同
链路层地址。

附录 D：IsRouter 规则摘要

本附录提供了在本文档中指定的维护 IsRouter 标志的规则摘要。

这些规则的背景是 ND 消息隐式或显式地包含指示发送者（或目标地址）是主机还是路由器的信息。使用以下假设：

- 路由器通告的发送者被隐式地假定为路由器。- 邻居请求消息不包含有关发送者的隐式或显式指示。主机和路由器都发送这样的消息。- 邻居通告消息包含一个明确的“IsRouter 标志”，即 R 位。- 当重定向的目标地址与被重定向的数据包的目的地址不同时，重定向的目标被隐式地假定为路由器。这是一个自然的假设，因为预期该节点能够将数据包转发到目的地。- 当重定向的目标地址与目的地相同时，不携带任何主机与路由器信息。所知道的是目的地（即目标）在链路上，但它可以是主机或路由器。

设置 IsRouter 标志的规则基于上述信息内容。如果 ND 消息包含显式或隐式信息，则收到消息将导致更新 IsRouter 标志。但是，当 ND 消息中没有主机与路由器信息时，接收到消息不得导致对 IsRouter 状态的更改。当接收此类消息导致创建邻居缓存条目时，本文档规定将 IsRouter 标志设置为 FALSE。当一个节点错误地认为主机是路由器时，可能会造成更多的麻烦，而不是反之。在这些情况下，随后的邻居通告或路由器通告消息将设置正确的 IsRouter 值。

附录 E：实现问题

附录 E.1：可达性确认

邻居不可达检测需要明确确认前向路径是否正常运行。为避免需要邻居请求探测消息，上层协议应在成本较低的情况下提供这样的指示。可靠的连接导向型协议（如 TCP）通常能意识到前向路径是否正常。例如，当 TCP 发送（或接收）数据时，它会更新其窗口序列号、设置和取消重传计时器等。通常指示前向路径正常运行的特定情况包括：

• 接收到覆盖先前未确认的序列号（例如，数据）的确认指示在数据发送时前向路径正常工作。

• 完成初始的三次握手是上述规则的特殊情况；尽管在握手期间没有发送数据，但 SYN 标志从序列号的角度来看被视为数据。这适用于主动打开时的 SYN+ACK 和被动打开对等方的该数据包的 ACK。

• 接收到新数据（即先前未接收的数据）指示前向路径在发送了提升对等方发送窗口的确认后允许发送新数据时正常工作。

为了最小化在 TCP 和 IP 层之间传递可达性信息的成本，实现可能希望对其发送的可达性确认进行速率限制。一种可能性是仅在每几个数据包时处理可达性信息。例如，如果一个实现每个连接只有一个往返时间计时器，那么可以每个往返时间更新一次可达性信息。对于在控制块内缓存目标缓存条目的实现，一旦 TCP 数据包已被多路复用到其相应的控制块，可能可以直接更新邻居缓存条目（即，无需昂贵的查找）。对于其他实现，可能可以在下一个提交给 IP 的数据包上附加可达性确认，假设实现在长时间没有发送到 IP 的情况下保护附加的确认不会过时。

TCP 还必须防止认为“过时”的信息表明当前的可达性。例如，窗口打开后 30 分钟接收到的新数据并不构成前向路径当前正常工作的确认；它只是指示了 30 分钟前窗口更新达到了对等方，即在那个时间点上路径是工作的。实现还必须考虑即使路径中断且窗口更新未达到对等方，TCP 也会发送零窗口探测。

对于基于 UDP 的应用（远程过程调用（RPC）、DNS），当接收到响应数据包时，使客户端发送可达性确认相对较简单。对于服务器生成这样的确认则更加困难，在某些情况下甚至是不可能的，因为没有流量控制，即服务器无法确定接收到的请求是否指示先前的响应已达到客户端。

注意，实现不能将负面的上层建议用作邻居不可达检测算法的替代品。负面建议（例如，当存在过多的重传时，来自 TCP 的建议可能表明数据发送方的前向路径可能不工作。但它无法检测到数据接收方的路径不工作，导致无法到达发送方的任何确认数据包。

附录 F：与 RFC 2461 的更改

• 删除了对于使用 IPsec AH 和 ESP 来保护消息或作为验证接收到的消息的一部分的引用。

• 添加了第 3.3 节。

• 更新了第 11 节，其中包含了对威胁、IPsec 限制和使用 SEND 的更详细讨论。

• 根据 RFC 4942，“IPv6 邻居发现假定链接本地性被认为是有害的”，删除了第 5.2 节中的对链接本地性的假设。

• 澄清了第 4.2 节中路由器生存时间字段的定义。

• 更新了第 4.6.2 节和第 6.2.1 节中的文本，以指示首选生存时间不能大于有效生存时间。

• 删除了对有状态配置的引用，并添加了对 DHCPv6 的引用。

• 在第 6.2.1 节中添加了 IsRouter 标志的定义，允许混合主机/路由器行为。

• 允许移动节点在手over期间发送 RS 之前免除添加随机延迟。

• 更新了前缀选项中前缀长度的定义。

• 更新了介绍中对于 NBMA 链路的适用性，并添加了对 3GPP RFCs 的引用。

• 澄清了仅限路由器支持负载平衡的情况。

• 澄清了在没有源链路层地址选项（SLLAO）的情况下接收路由器请求时路由器的行为。

• 澄清了仅对非零值进行 CurHopLimit 的一致性检查。

• 为了更清晰，重新排列了第 7.2.5 节，并描述了在 INCOMPLETE 状态下接收 NA 时的处理。

• 在第 7.2 节中增加了关于节点在接收到没有 SLLAO 的消息时应如何做出反应的澄清。

• 添加了新的 IANA 部分。

• 其他编辑方面的细微修改。

致谢

RFC 2461 的作者们要感谢 IPV6 工作组的贡献，特别是（按字母顺序）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 和 Susan Thomson。

本文档的编辑者（Hesham Soliman）要感谢 IPV6 工作组对本修订版的众多贡献，特别是（按字母顺序）Greg Daley、Elwyn Davies、Ralph Droms、Brian Haberman、Bob Hinden、Tatuya Jinmei、Pekka Savola、Fred Templin 和 Christian Vogt。