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 地址。如果地址不匹配，它将丢弃数据包。

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

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

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

• 单个轻量级 DHCPv6 中继代理 （LDRA;第 2 层）连接在客户端和服务器之间。如果 LDRA 未将 option 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 命令来查看由于验证失败而丢弃的控制数据包数量。