Skip to main content

3. Review of ND Mitigation Solutions (ND缓解解决方案回顾)

表1总结了第2.4节中描述的问题1-15可用的ND缓解解决方案。类似的解决方案被分组,从解决最多问题的解决方案开始。不相关的解决方案根据它们解决的问题(在第2.4节中列出)排序。表中的每个解决方案将在后面的子节中解释,其中表中的缩写将被描述。

在表1中,字母代码表示缓解解决方案的RFC类别(有关这些类别的解释,请参见BCP 9 [RFC2026]):

  • S: 标准跟踪 (Standards Track) (提议标准或互联网标准)
  • E: 实验性 (Experimental)
  • I: 信息性 (Informational)
  • B: 最佳当前实践 (Best Current Practice)
  • N/A: 不适用 (非RFC)

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

  • On-link sec.: 信任所有节点相关问题 (Trusting-all-nodes Related Issues)
  • NCE exh.: NCE耗尽 (NCE Exhaustion)
  • Fwd. delay: 路由器转发延迟 (Router Forwarding Delay)
  • No addr. acc.: 缺乏地址问责 (Lack of Address Accountability)
+==========+====+===========+=======+=========+====+=======+=======+
| ND       |RFC |Multicast  |Reliabi| On-link |NCE | Fwd.  | No    |
| solution |cat.|performance|lity   | sec.    |exh.| delay | addr. |
|          |    |           |       |         |    |       | acc.  |
|          |    +===+=+=+=+=+=====+=+=========+====+=======+=======+
|          |    | 1 |2|3|4|5|  6  |7|   8-12  | 13 |   14  |   15  |
+==========+====+===+=+=+=+=+=====+=+=========+====+=======+=======+
| MBBv6    | I  |           All identified issues solved           |
+----------+----+--------------------------------------------------+
| FBBv6    |N/A |           All identified issues solved           |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| UPPH     | I  |   |X| |X|X|     |X|         | 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| |     | |         |    |   X   |       |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| SAVI/    | I  |   | | | | |     | |    X    |    |       |       |
| RA-G     |    |   | | | | |     | |         |    |       |       |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| RFC 6583 | I  |   | | | | |     | |         | X  |       |       |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
| RFC 9686 | S  |   | | | | |     | |         |    |       |   X   |
+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+

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

3.1. Mobile Broadband IPv6 (MBBv6) (移动宽带IPv6)​

"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解决方案在本文档中称为移动宽带IPv6 (Mobile Broadband IPv6, MBBv6)。它们是信息性RFC。关键点是:

  • 将每个主机(例如,移动用户设备 (User Equipment, UE))与路由器(例如,移动网关)放在点对点 (Point-to-Point, P2P) 链路中具有以下结果:

    • 所有组播都有效地转换为单播。
    • P2P链路没有MAC地址。因此,不需要按需路由器NCE。
    • 信任所有节点仅与路由器相关。通过在路由器上应用过滤(例如,丢弃来自主机的RA),即使恶意主机也不能造成伤害。

  • 为每个主机分配唯一的/64前缀。与P2P链路一起,这将每个主机放在单独的链路和子网上。

  • 在路由器上维护(前缀,接口)绑定以用于转发目的。

由于解决了ND问题的所有三个原因,第2.4节讨论的所有问题都得到解决。

3.2. Fixed Broadband IPv6 (FBBv6) (固定宽带IPv6)​

"IPv6 in the context of TR-101" [TR177] 中定义的IPv6解决方案在本文档中称为固定宽带IPv6 (Fixed Broadband IPv6, FBBv6)。FBBv6有两种形式:

  • P2P: 每个主机(例如,住宅网关 (Residential Gateway, RG))与路由器(例如,宽带网络网关 (Broadband Network Gateway, BNG))处于P2P链路中。在这种情况下,解决方案在功能上类似于MBBv6。第2.4节讨论的所有ND问题都得到解决。

  • 点到多点 (Point to Multipoint, P2MP): 连接到接入设备(例如,光线路终端 (Optical Line Terminal, OLT))的所有主机(例如,RG)与路由器(例如,BNG)处于P2MP链路中。这是通过将所有主机放在路由器上的单个VLAN中并配置OLT阻止任何帧在其接入端口之间转发来实现的;来自每个主机的流量只能向上传输到路由器,而不能横向传输到另一个主机,从而防止直接的主机到主机通信。

以下列表总结了[TR177]中描述的FBBv6-P2MP架构的两个关键方面以及相关好处:

  • 实现DAD代理 (DAD Proxy) [RFC6957]:

    在上述P2MP架构中,正常的ND DAD过程将崩溃,因为主机无法彼此交换NS。为解决此问题,路由器作为DAD代理参与DAD过程以解决地址重复。

    好处是:

    • 从所有主机到路由器的组播流量有效地转换为单播,因为主机只能直接与路由器通信。
    • 信任所有节点模型仅限于路由器。通过应用简单的过滤(例如,丢弃来自主机的RA),路由器可以缓解安全风险,即使来自恶意主机。

  • 为每个主机分配唯一的/64前缀:

    为每个主机分配唯一的/64前缀会带来几个运营改进:

    • 路由器可以主动安装该前缀指向主机的转发条目,消除对按需路由器NCE的需求。
    • 由于每个主机位于不同的子网中,主机之间的流量通过路由器路由,消除了主机彼此执行地址解析的需求。
    • 没有地址解析,路由器到主机的组播仅限于非请求RA。由于每个主机位于其自己的子网中,这些RA作为单播数据包发送到各个主机。这遵循[RFC6085]中指定的方法,其中主机的MAC地址替换RA中的组播MAC地址。

由于解决了ND问题的所有三个原因,所有ND问题(第2.4节)也得到解决。

3.3. Unique Prefix per Host (UPPH) (每主机唯一前缀)​

每主机唯一前缀 (Unique Prefix per Host, UPPH) 解决方案在[RFC8273]和[RFC9663]中描述。两者都是信息性RFC。[RFC8273]依赖SLAAC进行唯一前缀分配,而[RFC9663]依赖DHCPv6前缀委派 (DHCPv6 Prefix Delegation, DHCPv6-PD)。分配机制的这种差异不会改变对ND问题的讨论,因为即使通过DHCPv6-PD接收其前缀,每个IPv6节点仍然需要运行SLAAC。因此,单独讨论[RFC8273]就足够了。

[RFC8273] "改进了共享网络段(如Wi-Fi或以太网)上的主机隔离和增强的订户管理"。关键点是:

  • 当前缀分配给主机时,路由器可以主动安装该前缀指向主机的转发条目。不再有按需路由器NCE。

  • 没有地址解析,路由器到主机的组播仅包含非请求RA。它们将以单播方式逐个发送给主机,因为每个主机的前缀不同。

  • 由于不同的主机位于不同的子网中,主机将通过路由器向其他主机发送流量。没有主机到主机的地址解析。

因此,由按需路由器NCE和路由器到主机组播引起的ND问题得到防止。

[RFC8273]指出,"实现每主机唯一IPv6前缀的网络可以简单地确保设备不能彼此发送数据包,除非通过第一跳路由器"。但是,当主机在以太网等共享介质上时,确保"设备不能彼此发送数据包,除非通过第一跳路由器"需要私有VLAN [RFC5517]等额外措施。没有这样的额外措施,在共享介质上,主机仍然可以在L2中彼此到达,因为它们属于同一请求节点组播组 (Solicited-Node Multicast Group)。因此,信任所有节点和主机到路由器的组播可能导致问题。在主机组播问题(即问题1、3、5、6和7)中,UPPH防止了问题5和7,因为不需要主机之间的地址解析(问题5),并且不可能出现GUA重复(问题7)。但是,问题1、3和6可能发生。

3.4. Wireless ND (WiND) (无线ND)​

本文档使用术语"无线ND (Wireless ND, WiND)"来描述[RFC6775]、[RFC8505]、[RFC8928]和RFC8929中为低功耗有损网络 (Low-Power and Lossy Networks, LLNs) [RFC7102] 定义的根本不同的ND解决方案。WiND更改主机和路由器行为,仅将组播用于路由器发现。关键点是:

  • 主机使用单播主动在路由器上注册其地址。路由器使用单播与主机通信,并成为地址所有权的抽象注册商和仲裁者。

  • 路由器还主动为主机安装NCE。这避免了对主机进行地址解析的需要。

  • 路由器将前缀信息选项 (Prefix Information Option, PIO) L位设置为0。每个主机仅与路由器通信([RFC4861]的第6.3.4节)。

  • 与LLN相关的其他功能。

WiND解决了LLN中的所有ND问题(第2.4节)。但是,WiND支持对于通用主机不是强制性的。因此,如果不对参与节点施加额外约束,它不能作为部署选项依赖。

3.5. Scalable Address Resolution Protocol (SARP) (可扩展地址解析协议)​

可扩展地址解析协议 (Scalable Address Resolution Protocol, SARP) [RFC7586] 是一个实验性解决方案。该实验于2017年结束,即RFC发布两年后。由于该想法已在针对更具体场景的缓解解决方案中使用(在第3.6节和第3.7节中描述),因此值得在此描述。使用场景是数据中心 (Data Centers, DCs),其中大型L2域跨越多个站点。在每个站点中,多个主机连接到交换机。主机可以是虚拟机 (Virtual Machines, VMs),因此数量可能很大。交换机通过纯L2网络或覆盖L2网络互连。

交换机将窥探并为本地主机安装(IP,MAC地址)代理表。交换机还将使用其自己的MAC地址响应来自其他站点对其主机的地址解析请求。这样,站点内的所有主机对其他站点来说将显示为具有单个MAC地址。因此,交换机只需要为本地主机和远程交换机构建MAC地址表,而不是为L2域中的所有主机构建。因此,交换机的MAC地址表大小显著减少。交换机还将从远程交换机添加(IP,MAC地址)响应到其代理ND表,以便它可以直接响应来自本地主机对此类IP的未来地址解析请求。这大大减少了网络中地址解析组播的数量。

与MBBv6、FBBv6和UPPH(试图解决第2.4节中讨论的所有ND问题)不同,SARP专注于减少地址解析组播以提高DC中大型L2域的性能和可扩展性。

3.6. ND Optimization for TRILL (TRILL的ND优化)​

大量链路透明互连 (Transparent Interconnection of Lots of Links, TRILL) 的ARP和ND优化RFC8302类似于SARP(第3.5节)。它可以被视为SARP在TRILL环境中的应用。

与SARP一样,TRILL的ND优化专注于减少组播地址解析。也就是说,它解决了问题5(第2.1节)。

3.7. Proxy ND in Ethernet Virtual Private Networks (ND EVPN) (以太网虚拟专用网中的代理ND)​

EVPN中的代理ARP/ND在RFC9161中指定。使用场景是DC,其中大型L2域跨越多个站点。在每个站点中,多个主机连接到提供商边缘 (Provider Edge, PE) 路由器。PE通过EVPN隧道互连。

每个站点的PE窥探本地地址解析NA以构建(IP,MAC地址)代理ND表条目。然后PE通过边界网关协议 (Border Gateway Protocol, BGP) 将此类代理ND条目传播到其他PE。每个PE还窥探本地主机对远程主机的地址解析NS。如果其代理ND表中存在远程主机的条目,PE将直接响应。因此,组播地址解析消息的数量显著减少。

与SARP一样,EVPN中的代理ARP/ND也专注于减少地址解析组播。

3.8. Reducing Router Advertisements per RFC 7772 (按照RFC 7772减少路由器通告)​

维护IPv6连接要求主机能够接收周期性组播RA [RFC4861]。在睡眠时处理单播数据包的主机也必须在睡眠时处理组播RA。过多的RA可能显著降低移动主机的电池寿命。RFC7772指定了减少RA的解决方案:

  • 如果主机的源IP地址已指定且主机的MAC地址有效,路由器应该 (SHOULD) 使用单播RA(而不是正常的组播RA)响应RS。这样,其他主机将不会接收此RA。

  • 路由器应该 (SHOULD) 降低组播RA频率。

[RFC7772]解决了问题2(第2.1节)。

3.9. Gratuitous Neighbor Discovery (GRAND) (无偿邻居发现)​

GRAND RFC9131以以下方式更改ND:

  • 节点在为其接口分配新IPv6地址时发送非请求NA。

  • 路由器为该节点创建新NCE并将其状态设置为STALE。

当稍后主机的数据包到达时,路由器可以使用现有的STALE NCE立即转发它([RFC4861],第7.2.2节)。然后它通过发送单播NS而不是组播NS来验证可达性以进行地址解析。这样,GRAND消除了路由器转发延迟,但它不解决其他按需路由器NCE问题。例如,NCE耗尽仍然可能发生。

3.10. Source Address Validation Improvement (SAVI) and Router Advertisement Guard (RA-Guard) (源地址验证改进和路由器通告防护)​

源地址验证改进 (Source Address Validation Improvement, SAVI) RFC7039将地址绑定到L2交换机上的端口,并拒绝来自其他端口对该地址的声明。因此,节点不能欺骗另一个节点的IP地址。

路由器通告防护 (Router Advertisement Guard, RA-Guard) [RFC6105] RFC7113仅允许来自路由器连接的端口的RA。因此,其他端口上的节点不能假装是路由器。

SAVI和RA-Guard解决链路内安全问题。

3.11. Dealing with NCE Exhaustion Attacks per RFC 6583 (按照RFC 6583处理NCE耗尽攻击)​

RFC6583处理NCE耗尽攻击问题(第2.3节)。它建议:

  • 运营商应该 (SHOULD):

    • 过滤未使用的地址空间,以便可以丢弃发往此类地址的消息,而不是触发NCE创建。
    • 实现ND消息处理的速率限制机制,以防止CPU和内存资源被压垮。

  • 供应商应该 (SHOULD):

    • 优先处理现有NCE的NDP处理而不是创建新NCE。

[RFC6583]承认"其中一些选项是'临时解决方案',并且在运营上可能难以管理"。[RFC6583]部分解决了路由器NCE耗尽问题。在实践中,路由器供应商对每个接口的NCE数量设置上限以防止缓存耗尽。如果链路上的地址多于该上限,路由器无法为每个地址保留条目,并且发往没有NCE的地址的数据包将被简单丢弃[RFC9663]。

3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6 per RFC 9686 (按照RFC 9686使用DHCPv6注册自生成IPv6地址)​

在IPv4中,网络管理员可以从DHCP服务器检索主机的IP地址并将其用于订户管理。在IPv6和SLAAC中,这是不可能的(第2.3节)。

RFC9686定义了一种通知DHCPv6服务器主机具有一个或多个自生成或静态配置地址的方法。这使网络管理员能够从DHCPv6服务器检索每个主机的IPv6地址。[RFC9686]为问题15(第2.3节)提供了解决方案。

3.13. Enhanced DAD (增强DAD)​

增强DAD RFC7527解决了特定情况下的DAD失败问题:环回接口 (Looped-back Interface)。DAD将在环回接口中失败,因为发送主机将接收回DAD消息,并将其解释为另一个主机正在尝试使用相同的地址。解决方案是在每个DAD消息中包含Nonce选项[RFC3971],以便发送主机可以检测到环回的DAD消息是由其自己发送的。

增强DAD不解决任何ND问题。它扩展了ND以在新场景中工作:环回接口。在此仅为完整性而进行审查。

3.14. ND Mediation for IP Interworking of Layer 2 VPNs (第2层VPN IP互通的ND中介)​

ND中介在RFC6575中指定。当两个连接电路 (Attachment Circuits, ACs) 通过虚拟专用线路服务 (Virtual Private Wired Service, VPWS) 互连,并且两个AC是不同介质(例如,一个是以太网而另一个是帧中继)时,两个PE必须进行互通以提供中介服务,以便客户边缘 (Customer Edge, CE) 可以解析远程端的MAC地址。[RFC6575]指定了这样的解决方案。

ND中介不解决任何ND问题。它扩展了ND以在新场景中工作:通过VPWS互连的两个不同介质的AC。在此仅为完整性而进行审查。

3.15. ND Solutions Defined Before the Latest Versions of ND (在最新版本ND之前定义的ND解决方案)​

ND和SLAAC的最新版本在[RFC4861]和[RFC4862]中指定。在[RFC4861]之前发布了几个ND缓解解决方案。在本节中仅为完整性审查它们。

3.15.1. Secure Neighbor Discovery (SEND) (安全邻居发现)​

SEND RFC3971的目的是确保主机和路由器是可信的。SEND定义了三个新的ND选项:加密生成地址 (Cryptographically Generated Addresses, CGA) RFC3972、RSA公钥密码系统和时间戳/Nonce。此外,SEND还定义了授权委派发现过程、地址所有权证明机制以及在ND协议中使用这些组件的要求。

3.15.2. Cryptographically Generated Addresses (CGA) (加密生成地址)​

CGA的目的是在SEND协议中将加密公钥与IPv6地址关联。关键点是通过计算公钥的加密哈希来生成IPv6地址的接口标识符 (Interface Identifier, IID)。生成的IPv6地址称为CGA。然后可以使用相应的私钥对从该地址发送的消息进行签名。

CGA假设合法主机不关心通过某些哈希过程创建的IID的位组合。攻击者需要确切的IID来冒充合法主机,但随后攻击者面临进行反向哈希计算的挑战,这是一个强大的数学挑战。

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

3.15.3. ND Proxy (ND代理)​

ND代理RFC4389旨在使由ND代理设备连接的多个链路作为单个链路工作。

  • 当ND代理从链路上的主机接收ND请求时,它将通过"最佳"(在下一段中定义)传出接口代理该消息。如果没有最佳接口,ND代理将向所有其他链路代理该消息。这里,代理意味着就像ND消息源自ND代理本身一样。也就是说,ND代理将ND消息的源IP和源MAC地址更改为ND代理的传出接口的IP和MAC地址,并相应地在传出接口创建NCE条目。

  • 当ND代理接收ND响应时,它将就像ND消息发往其自身一样,并更新接收接口的NCE条目状态。基于此类状态信息,ND代理可以确定未来ND请求的"最佳"传出接口。然后ND代理将ND消息代理回请求主机。

ND代理广泛用于SARP(第3.5节)、TRILL的ND优化(第3.6节)和EVPN中的代理ARP/ND(第3.7节)。

3.15.4. Optimistic DAD (乐观DAD)​

乐观DAD RFC4429寻求在成功情况下最小化地址配置延迟,并在失败情况下尽可能减少中断。也就是说,乐观DAD让主机在DAD完成之前立即使用新形成的地址进行通信,假设DAD无论如何都会成功。如果地址最终被证明是重复的,乐观DAD提供了一组机制来最小化影响。乐观DAD修改了原始ND [RFC2461]和原始SLAAC RFC2462,但该解决方案未纳入ND [RFC4861]和SLAAC [RFC4862]的最新规范。但是,乐观DAD的实现确实存在。

乐观DAD不解决任何ND问题(第2节)。在此仅为完整性而审查。

Last updated on