3. ND 缓解方案综述 (Review of ND Mitigation Solutions)

表 1 汇总了可用于第 2.4 节中 Issues 1-15 的 Neighbor Discovery (ND) 缓解方案. 相似方案被归为一组, 首先列出能解决最多问题的方案. 彼此无关的方案则按其解决的问题顺序排列. 表中的每个方案会在后续小节中说明, 表中缩写也会在那里解释.

在表 1 中, 字母代码表示缓解方案的 RFC 类别, 这些类别见 BCP 9 [RFC2026]:

• S: Standards Track, 即 Proposed Standard 或 Internet Standard.
• E: Experimental.
• I: Informational.
• B: Best Current Practice.
• N/A: Not Applicable, 即不是 RFC.

表 1 中的缩写与第 2.4 节对应如下:

• On-link sec.: 与 Trusting-all-nodes 相关的问题.
• NCE exh.: NCE exhaustion.
• Fwd. delay: Router forwarding delay.
• No addr. acc.: Lack of address accountability.

表 1: 已识别问题的解决方案

ND solution	RFC cat.	Multicast performance	Reliability	On-link sec.	NCE exh.	Fwd. delay	No addr. acc.
		1	2	3	4	5	6
MBBv6	I	All identified issues solved
FBBv6	N/A	All identified issues solved
UPPH	I		X		X	X
WiND	S	All issues solved for Low-Power and Lossy Networks (LLNs)
SARP	E					X
ND TRILL	S					X
ND EVPN	S					X
RFC 7772	B		X
GRAND	S				X
SAVI/RA-G	I
RFC 6583	I
RFC 9686	S

3.1. Mobile Broadband IPv6 (MBBv6)

本文档把 "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)" [RFC6459]、"IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" [RFC7066] 和 "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link" [RFC7278] 中定义的 IPv6 方案称为 Mobile Broadband IPv6 (MBBv6). 这些都是 Informational RFC. 要点如下:

• 把每个 host, 如移动 User Equipment (UE), 放入与 router, 如移动 gateway, 相连的 Point-to-Point (P2P) link, 会产生以下结果:
  • 所有 multicast 实际上都转换为 unicast.
  • P2P link 没有 MAC address. 因此不需要 Router-NCE-on-Demand.
  • Trusting-all-nodes 只与 router 相关. 通过在 router 上应用过滤, 例如丢弃来自 host 的 RA, 即使恶意 host 也无法造成危害.
• 为每个 host 分配唯一 /64 prefix. 这与 P2P link 结合后, 会把每个 host 放在独立 link 和 subnet 中.
• Router 为转发目的维护 (prefix, interface) 绑定.

由于 ND 问题的三个成因都被处理, 第 2.4 节讨论的所有问题也都得到处理.

3.2. Fixed Broadband IPv6 (FBBv6)

本文档把 "IPv6 in the context of TR-101" [TR177] 中定义的 IPv6 方案称为 Fixed Broadband IPv6 (FBBv6). FBBv6 有两种形态:

• P2P: 每个 host, 如 Residential Gateway (RG), 位于与 router, 如 Broadband Network Gateway (BNG), 相连的 P2P link 中. 在这种情况下, 该方案在功能上类似 MBBv6. 第 2.4 节讨论的所有 ND 问题都得到解决.
• Point to Multipoint (P2MP): 连接到接入设备, 如 Optical Line Terminal (OLT), 的所有 host, 如 RG, 位于与 router, 如 BNG, 相连的 P2MP link 中. 做法是在 router 上把所有 host 放入单个 VLAN, 并配置 OLT 阻止任何 frame 在其接入端口之间转发. 每个 host 的流量只能向上到 router, 不能横向到另一个 host, 从而防止直接 host-to-host 通信.

以下列表总结 [TR177] 描述的 FBBv6-P2MP 架构的两个关键方面及其收益:

• 实现 DAD proxy [RFC6957]:

  在上述 P2MP 架构中, 正常 ND Duplicate Address Detection (DAD) 过程会失效, 因为 host 之间不能彼此交换 Neighbor Solicitation (NS). 为解决该问题, router 作为 DAD Proxy 参与 DAD 过程, 用于解决地址重复.

  收益如下:

  • 从所有 host 到 router 的 multicast traffic 实际上转换为 unicast, 因为 host 只能直接与 router 通信.
  • Trusting-all-nodes 模型被限制在 router 上. 通过简单过滤, 例如丢弃来自 host 的 RA, router 能缓解安全风险, 即使面对恶意 host 也是如此.

• 为每个 host 分配唯一 /64 prefix:

  为每个 host 分配唯一 /64 prefix 会带来若干操作改进:

  • Router 可以主动安装通往该 host 的 prefix 转发表项, 消除对 Router-NCE-on-Demand 的需要.
  • 由于每个 host 位于不同 subnet, host 之间的流量会经过 router, 消除了 host 彼此执行地址解析的需要.
  • 没有地址解析时, router 到 host 的 multicast 仅限 unsolicited RA. 由于每个 host 位于自身 subnet 中, 这些 RA 会作为 unicast packet 发送给单个 host. 这遵循 [RFC6085] 指定的方法, 即在 RA 中用 host 的 MAC address 替代 multicast MAC address.

由于 ND 问题的三个成因都被处理, 所有 ND 问题, 即第 2.4 节, 也得到处理.

3.3. Unique Prefix per Host (UPPH)

Unique Prefix per Host (UPPH) 方案见 [RFC8273] 和 [RFC9663]. 两者都是 Informational RFC. [RFC8273] 依赖 SLAAC 进行唯一 prefix 分配, 而 [RFC9663] 依赖 DHCPv6 Prefix Delegation (DHCPv6-PD). 分配机制差异不会改变对 ND 问题的讨论, 因为每个 IPv6 node 即使通过 DHCPv6-PD 接收 prefix, 仍然需要运行 SLAAC. 因此, 只讨论 [RFC8273] 就足够.

[RFC8273] 在 Wi-Fi 或 Ethernet 等共享网段上 "improves host isolation and enhanced subscriber management". 要点如下:

• 当 prefix 分配给 host 时, router 可以主动安装通往该 host 的 prefix 转发表项. 这样不再需要 Router-NCE-on-Demand.
• 没有地址解析时, router 到 host 的 multicast 仅包含 unsolicited RA. 因为每个 host 的 prefix 都不同, 这些 RA 会逐个以 unicast 发送给 host.
• 由于不同 host 位于不同 subnet, host 会经由 router 向其他 host 发送流量. 因此没有 host-to-host 地址解析.

因此, 由 Router-NCE-on-Demand 和 router multicast to hosts 导致的 ND 问题会被避免.

[RFC8273] 指出, "network implementing a unique IPv6 prefix per host can simply ensure that devices cannot send packets to each other except through the first-hop router". 不过, 当 host 位于 Ethernet 等共享介质上时, 要确保 "devices cannot send packets to each other except through the first-hop router" 需要 Private VLAN [RFC5517] 等额外措施. 没有这类额外措施时, 在共享介质上, host 仍可在 L2 彼此到达, 因为它们属于同一个 Solicited-Node Multicast Group. 因此, Trusting-all-nodes 和 host multicast to routers 仍可能造成问题. 在 host multicast 问题中, 即 Issues 1、3、5、6 和 7, UPPH 能防止 Issues 5 和 7, 因为 host 之间不需要地址解析, 即 Issue 5, 且不存在 GUA 重复的可能性, 即 Issue 7. 不过, Issues 1、3 和 6 仍可能发生.

3.4. Wireless ND (WiND)

本文档使用 "Wireless ND (WiND)" 描述 Low-Power and Lossy Networks (LLNs) [RFC7102] 的一种根本不同的 ND 方案. 该方案由 [RFC6775]、[RFC8505]、[RFC8928] 和 [RFC8929] 定义, 属于 Standards Track. WiND 改变 host 和 router 行为, 使 multicast 仅用于 router discovery. 要点如下:

• Host 使用 unicast 主动向 router 注册自己的地址. Router 使用 unicast 与 host 通信, 并成为地址所有权的抽象 registrar 和 arbitrator.
• Router 也会主动为 host 安装 NCE. 这样避免了为 host 进行地址解析的需要.
• Router 把 Prefix Information Option (PIO) 的 L-bit 设置为 0. 每个 host 只与 router 通信, 见 [RFC4861] 第 6.3.4 节.
• 还有一些只与 LLN 相关的功能.

WiND 在 LLN 中解决所有 ND 问题, 即第 2.4 节. 不过, 通用 host 并不强制支持 WiND. 因此, 如果不对参与节点施加额外约束, 就不能依赖它作为部署选项.

3.5. Scalable Address Resolution Protocol (SARP)

Scalable Address Resolution Protocol (SARP) [RFC7586] 曾是 Experimental 方案. 该实验在 RFC 发布两年后的 2017 年结束. 由于该思想已用于更具体场景中的缓解方案, 见第 3.6 节和第 3.7 节, 因此值得在此说明. 使用场景是 Data Center (DC), 其中大型 L2 domain 跨多个站点. 每个站点中, 多个 host 连接到 switch. Host 可以是 Virtual Machine (VM), 因而数量可能很大. Switch 通过纯 L2 网络或 overlay L2 网络互联.

Switch 会 snoop 并为本地 host 安装 (IP, MAC address) proxy table. Switch 还会用自己的 MAC address 响应其他站点对本地 host 的地址解析请求. 这样, 一个站点内所有 host 对其他站点而言表现为拥有同一个 MAC address. 因此, switch 只需要为本地 host 和远端 switch 建立 MAC address table, 而不需要为 L2 domain 中所有 host 建表. 结果是 switch 的 MAC address table 大小显著降低. Switch 还会把来自远端 switch 的 (IP, MAC address) reply 加入自己的 proxy ND table, 以便后续可直接响应本地 host 对这些 IP 的地址解析请求. 这大幅减少网络中的地址解析 multicast.

MBBv6、FBBv6 和 UPPH 试图处理第 2.4 节讨论的所有 ND 问题, 而 SARP 不同, 它侧重减少地址解析 multicast, 以提升 DC 中大型 L2 domain 的性能和可扩展性.

3.6. TRILL 的 ND 优化

Transparent Interconnection of Lots of Links (TRILL) [RFC8302] 的 ARP 和 ND 优化属于 Standards Track, 与 SARP 类似, 见第 3.5 节. 它可视为 SARP 在 TRILL 环境中的应用.

与 SARP 一样, TRILL 的 ND 优化侧重减少 multicast address resolution. 也就是说, 它处理 Issue 5, 见第 2.1 节.

3.7. Ethernet Virtual Private Networks 中的 Proxy ND (ND EVPN)

EVPN 中的 Proxy ARP/ND 由 [RFC9161] 指定, 属于 Standards Track. 使用场景是 DC, 其中大型 L2 domain 跨多个站点. 每个站点中, 多个 host 连接到 Provider Edge (PE) router. PE 通过 EVPN tunnel 互联.

每个站点的 PE 会 snoop 本地地址解析 Neighbor Advertisement (NA), 以构建 (IP, MAC address) Proxy ND table entry. 随后 PE 通过 Border Gateway Protocol (BGP) 把这些 Proxy ND entry 传播给其他 PE. 每个 PE 还会 snoop 本地 host 对远端 host 的地址解析 Neighbor Solicitation (NS). 如果其 Proxy ND table 中存在远端 host 的条目, PE 会直接回复. 因此, multicast address resolution 消息数量显著减少.

与 SARP 一样, EVPN 中的 Proxy ARP/ND 也侧重减少地址解析 multicast.

3.8. 根据 RFC 7772 减少 Router Advertisement

维持 IPv6 连通性要求 host 能接收周期性 multicast RA [RFC4861]. 在睡眠时仍处理 unicast packet 的 host, 也必须在睡眠时处理 multicast RA. 过多 RA 会显著缩短移动 host 的电池寿命. [RFC7772] (Best Current Practice) 指定了减少 RA 的方案:

• 如果指定了 host 的源 IP address 且 host 的 MAC address 有效, router 应以 unicast RA 响应 RS, 而不是普通 multicast RA. 这样其他 host 不会收到该 RA.
• Router 应降低 multicast RA 频率.

[RFC7772] 处理 Issue 2, 见第 2.1 节.

3.9. Gratuitous Neighbor Discovery (GRAND)

GRAND [RFC9131] 属于 Standards Track, 它按以下方式改变 ND:

• Node 在为接口分配新的 IPv6 address 时发送 unsolicited NA.
• Router 为该 node 创建新的 NCE, 并把状态设置为 STALE.

当之后出现发往该 host 的 packet 时, router 可以使用已有 STALE NCE 立即转发, 见 [RFC4861] 第 7.2.2 节. 随后它会通过发送 unicast NS 而不是 multicast NS 来验证可达性. 这样, GRAND 消除了 router forwarding delay, 但不解决其他 Router-NCE-on-Demand 问题. 例如, NCE exhaustion 仍可能发生.

3.10. Source Address Validation Improvement (SAVI) 和 Router Advertisement Guard (RA-Guard)

Source Address Validation Improvement (SAVI) [RFC7039] 属于 Informational, 它把一个地址绑定到 L2 switch 的某个 port, 并拒绝其他 port 对该地址的声明. 因此, node 不能 spoof 另一个 node 的 IP address.

Router Advertisement Guard (RA-Guard) [RFC6105] [RFC7113] 属于 Informational, 它只允许从连接 router 的 port 收到 RA. 因此, 其他 port 上的 node 不能冒充 router.

SAVI 和 RA-Guard 处理 on-link security 问题.

3.11. 根据 RFC 6583 处理 NCE Exhaustion 攻击

[RFC6583] 属于 Informational, 用于处理 NCE exhaustion attack 问题, 见第 2.3 节. 它建议:

• 运营者应当:
  • 过滤未使用地址空间, 使发往这些地址的消息被丢弃, 而不是触发 NCE 创建.
  • 实现 ND 消息处理的 rate-limiting 机制, 防止 CPU 和内存资源被耗尽.
• 厂商应当:
  • 优先处理已有 NCE 的 NDP, 而不是创建新 NCE.

[RFC6583] 承认 "some of these options are 'kludges', and can be operationally difficult to manage". [RFC6583] 部分处理 Router NCE exhaustion 问题. 实际中, router 厂商会限制每个接口的 NCE 数量, 以防缓存耗尽. 如果链路上的地址多于该上限, router 无法为每个地址保留条目, 发往没有 NCE 的地址的 packet 会被直接丢弃 [RFC9663].

3.12. 使用 DHCPv6 注册自生成 IPv6 地址, 按 RFC 9686

在 IPv4 中, 网络管理员可以从 DHCP server 获取 host 的 IP address, 并将其用于 subscriber management. 在 IPv6 和 SLAAC 中, 这不可行, 见第 2.3 节.

[RFC9686] 属于 Standards Track, 它定义一种方法, 用于通知 DHCPv6 server 某个 host 拥有一个或多个自生成或静态配置的地址. 这使网络管理员能够从 DHCPv6 server 获取每个 host 的 IPv6 address. [RFC9686] 为 Issue 15 提供解决方案, 见第 2.3 节.

3.13. Enhanced DAD

Enhanced DAD [RFC7527] 属于 Standards Track, 它解决一种特定情况下的 DAD failure: looped-back interface. 在 looped-back interface 中, DAD 会失败, 因为发送 host 会收到自己发出的 DAD message, 并将其解释为另一个 host 试图使用同一地址. 解决方案是在每个 DAD message 中包含 Nonce option [RFC3971], 使发送 host 能检测 looped-back DAD message 是自己发送的.

Enhanced DAD 不解决任何 ND 问题. 它扩展 ND, 使其能用于一个新场景: looped-back interface. 这里只为完整性而回顾它.

3.14. Layer 2 VPN IP Interworking 的 ND Mediation

ND mediation 由 [RFC6575] 指定, 属于 Standards Track. 当两个 Attachment Circuit (AC) 通过 Virtual Private Wired Service (VPWS) 互联, 且两个 AC 使用不同介质, 例如一个是 Ethernet 而另一个是 Frame Relay, 两个 PE 必须进行 interwork, 提供 mediation service, 使 Customer Edge (CE) 能解析远端的 MAC address. [RFC6575] 指定了这种方案.

ND mediation 不处理任何 ND 问题. 它扩展 ND, 使其能用于一个新场景: 两个不同介质的 AC 通过 VPWS 互联. 这里只为完整性而回顾它.

3.15. 最新 ND 版本之前定义的 ND 方案

ND 和 SLAAC 的最新版本由 [RFC4861] 和 [RFC4862] 指定. 若干 ND 缓解方案在 [RFC4861] 之前发布. 本节只为完整性而回顾它们.

3.15.1. Secure Neighbor Discovery (SEND)

SEND [RFC3971] 属于 Standards Track, 目的在于确保 host 和 router 是可信的. SEND 定义了 3 个新的 ND option: Cryptographically Generated Addresses (CGA) [RFC3972]、RSA public-key cryptosystem 以及 Timestamp/Nonce, 均属于 Standards Track. 此外, SEND 还定义授权委托发现过程、地址所有权证明机制, 以及在 ND protocol 中使用这些组件的要求.

3.15.2. Cryptographically Generated Addresses (CGA)

CGA 的目的是在 SEND protocol 中把 cryptographic public key 与 IPv6 address 关联. 关键点是通过计算 public key 的 cryptographic hash 生成 IPv6 address 的 Interface Identifier (IID). 生成的 IPv6 address 称为 CGA. 对应 private key 随后可用于签署从该地址发送的消息.

CGA 假设合法 host 并不关心某种 hash 过程会创建怎样的 IID bit 组合. 攻击者需要精确 IID 才能冒充合法 host, 但这要求攻击者执行反向 hash 计算, 这是很强的数学挑战.

CGA 是 SEND 的一部分. 没有已报告的部署.

3.15.3. ND Proxy

ND Proxy [RFC4389] 属于 Experimental, 目标是让由 ND Proxy 设备连接的多条链路表现为单条链路.

• 当 ND Proxy 从某条链路上的 host 收到 ND request 时, 它会把消息 proxy 到 "best" outgoing interface, 该接口在下一段中定义. 如果没有 best interface, ND Proxy 会把消息 proxy 到所有其他链路. 这里的 proxy 表示像 ND message 来自 ND Proxy 自身一样行动. 也就是说, ND Proxy 会把 ND message 的 source IP 和 source MAC address 改为 ND Proxy outgoing interface 的 IP 和 MAC address, 并在 outgoing interface 上相应创建 NCE entry.
• 当 ND Proxy 收到 ND reply 时, 它会像 ND message 发往自身一样处理, 并更新接收接口上的 NCE entry 状态. 基于这些状态信息, ND Proxy 可以为后续 ND request 判断 "best" outgoing interface. 随后 ND Proxy 把 ND message proxy 回请求 host.

ND Proxy 广泛用于 SARP, 见第 3.5 节, TRILL 的 ND optimization, 见第 3.6 节, 以及 EVPN 中的 Proxy ARP/ND, 见第 3.7 节.

3.15.4. Optimistic DAD

Optimistic DAD [RFC4429] 属于 Standards Track, 目标是在成功情况下最小化地址配置延迟, 并在失败情况下尽可能减少中断. 也就是说, Optimistic DAD 假定 DAD 会成功, 允许 host 在 DAD 完成前立即使用新形成的地址通信. 如果该地址后来发现重复, Optimistic DAD 提供一组机制以最小化影响. Optimistic DAD 修改了原始 ND [RFC2461] 和原始 SLAAC [RFC2462], 二者均已废弃, 但该方案未纳入最新 ND [RFC4861] 和 SLAAC [RFC4862] 规范. 不过, 已存在 Optimistic DAD 实现.

Optimistic DAD 不解决任何 ND 问题, 见第 2 节. 这里只为完整性而回顾它.

---