DHCPv6 客户端 MAC 地址验证，防止会话劫持

从 Junos OS 18.2R1 版开始，DHCPv6 本地服务器和中继代理存在不可配置的机制，用于丢弃来自具有未知 MAC 地址的客户端的数据包，以防止恶意客户端劫持会话。当 DHCPv6 本地服务器或中继代理收到来自客户端的请求消息以建立会话时，它会从消息中提取客户端 MAC 地址（链路层地址），并将其添加到将 MAC 地址映射到客户端 IPv6 地址或前缀的本地表中。服务器或中继代理使用此表来比较从客户端的后续消息中收到的 MAC 地址，以验证客户端是否已知;否则，则将其视为恶意，并丢弃控制数据包。由于数据包未通过 MAC 验证，因此客户端 MAC 验证计数器将递增。

注意：

此处的假设是发送初始请求消息的客户端是良性的。在这种情况下，客户端 MAC 地址验证可防止恶意客户端试图劫持已建立或正在建立的客户端会话。客户端 MAC 地址验证无法防止发送初始请求消息的恶意客户端。

当不存在中继代理时;本地服务器与客户端共享链路或访问节点。在这种情况下，本地服务器直接从 DHCPv6 控制数据包的第 2 层标头中提取客户端 MAC 地址，并根据表验证地址。

当中继代理存在时，验证将由中继代理执行。 RFC 6939，DHCPv6 中的客户端链路层地址选项，使与 DHCPv6 客户端连接到同一链路的 DHCPv6 中继代理能够从收到的 DHCPv6 控制数据包中的以太网（第 2 层）报头中提取客户端 MAC 地址。数据包在其以太网报头中包含客户端链路层地址作为源 MAC 地址。中继代理根据存储在其本地表中的此客户端的值验证 MAC 地址。如果地址不匹配，则丢弃数据包。

如果地址已通过中继代理验证，且数据包未被丢弃，则中继代理还会在中继代理发送至本地服务器的 DHCPv6 中继转发消息的标头中包括该 MAC 地址。当 DHCPv6 本地服务器收到来自中继代理的中继转发消息时，服务器会自动检查该消息是否存在选项 79。当该选项存在时，本地服务器将提取 MAC 地址，并根据此客户端表中存储的值对其进行验证。如果选项 79 不存在，则本地服务器无法执行验证。

但是，由于中继代理已验证地址，因此本地服务器不应发现任何地址不匹配。

以下方案介绍了可能的中继代理配置及其对服务器验证的影响：

• 单个轻量级 DHCPv6 中继代理（LDRA;第 2 层）连接在客户端和服务器之间。如果 LDRA 未将选项 79 添加到报头，则本地服务器将直接从 DHCPv6 控制数据包的第 2 层报头中提取客户端 MAC 地址，并根据表验证地址。

• 客户端与服务器之间连接了一个或多个第 3 层 DHCPv6 中继代理。在这种情况下，服务器会检查中继代理发送的最内层中继转发消息的标头中的选项 79。将查看最内层的报头，因为它是由客户端到达的第一个中继代理修改的报头。其他报头由路径中的后续中继代理添加。这些代理不会添加选项 79，并且它们无法从第一个中继代理的第 2 层报头中提取 MAC 地址，因为该代理会将地址更改为自己的地址，每个后续中继代理也是如此。

• 客户端和服务器之间连接一个面向客户端的第 2 层 （LDRA） 中继代理后跟一个或多个第 3 层 DHCPv6 中继代理的组合。服务器检查中继代理发送的中继转发消息的最内层标头中的选项 79。如果 LDRA 没有将选项 79 添加到报头，则可能无法将报头中的 MAC 地址更改为自己的地址。因此，服务器接下来检查第二个最里面的报头是否有该选项，因为第一个第 3 层中继代理可能已经提取了 MAC 地址并添加了选项 79 来传达地址。

无需进行任何配置即可启用客户端 MAC 地址验证。您可以通过发出命令 show dhcpv6 server statistics 来查看由于验证失败而丢弃的控制数据包数。