文章总结： 本文档介绍了在大型广播网络中使用DHCPv6前缀代理为每个客户端分配唯一IPv6前缀的部署方案，该方案通过为每个设备提供独立前缀来提升网络可扩展性和端到端连接能力。文档详细说明了网络架构设计原则、路由部署要求、服务器配置注意事项以及适用场景分析，适用于企业网络和公共Wi-Fi等需要解决地址扩展性问题的环境。 综合评分： 85 文章分类： 技术标准,网络安全,解决方案,IPv6
使用DHCPv6前缀代理（DHCPv6-PD）为大型广播网络中的每个客户端分配唯一的IPv6前缀
衡水石头哥 衡水石头哥
铁军哥
2026年5月4日 07:41 北京
在小说阅读器读本章
去阅读
RFC9663：Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks，October 2024
梗概
本文档讨论了当连接到大型广播网络（例如企业网络或公共Wi-Fi网络）的各个节点通过DHCPv6前缀代理（DHCPv6 Prefix Delegation，DHCPv6-PD）分配唯一前缀（如RFC 8415中指定）时的IPv6部署场景。
本备忘录的状态
本文档不是互联网标准跟踪规范；其发布仅供参考。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。并非IESG批准的所有文件都是任何级别互联网标准的候选文件；请参阅RFC 7841第2节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc9663。
版权声明
版权所有（c）2024 IETF Trust和文档作者。版权所有。
本文件受本文件发布之日生效的BCP 78和IETF信托与IETF文件相关的法律规定（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括《信托法律条款》第4.e节中所述的修订版BSD许可证文本，并且不提供修订版BSD许可证中所述的保证。
1、简介
通常，企业或公共Wi-Fi部署等广播网络会将许多设备放置在具有单个链接前缀的共享链接上。本文档描述了另一种部署模型，其中各个设备从网络获取前缀。这提供了两个重要的优点。
首先，它提供了更好的可扩展性。与IPv4不同，IPv6允许主机拥有多个地址，大多数部署都是这种情况（有关更多详细信息，请参阅附录A）。然而，增加地址数量会带来网络基础设施的可扩展性问题。网络设备需要维护各种类型的表和哈希（首跳路由器上的邻居缓存、第二层设备上的邻居发现代理缓存等）。在虚拟可扩展局域网（Virtual eXtensible Local Area Network，VXLAN）网络[RFC7348]上，每个地址可能表示为一条路由。这意味着，例如，如果每个客户端有10个地址而不是1个，则网络必须支持10倍以上的路由等。如果基础设施设备的资源耗尽，该设备可能会从相应的表中删除一些IPv6地址，而地址所有者可能仍在使用该地址发送流量。这会导致流量被丢弃并降低客户体验。为每台主机提供一个前缀允许网络为每个设备仅维护一个条目，同时仍然为设备提供使用任意数量地址的能力。
其次，这种部署模型提供了扩展网络的能力。在IPv4中，连接到网络的设备可以使用NAT提供与对向设备的连接。通过DHCPv6前缀代理（DHCPv6 Prefix Delegation，DHCPv6-PD）[RFC8415]，此类设备可以类似地扩展网络，但与IPv4 NAT不同的是，它可以为其所连接的设备提供完整的端到端连接。
[RFC8273]中记录了另一种为每个设备部署唯一前缀的方法。同样，蜂窝IPv6网络中的标准部署模型[RFC6459]为每个设备提供了唯一的前缀。然而，在企业型网络中为每个设备提供唯一的前缀并不常见，其中节点通常连接到广播网段（例如VLAN），并且每个链路都分配有一个在链路上前缀。本文档采用与[RFC8273]类似的方法，但使用DHCPv6-PD分配前缀。
本文档重点介绍网络的行为。本文档中未定义主机行为。
2、需求语言
本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时，应按照BCP 14[RFC2119][RFC8174]中的描述进行解释。
3、术语
Node：节点，实现IPv6[RFC8200]的设备
Host：主机，不是路由器的任何节点[RFC8200]
Client：客户端，连接到网络并获取地址的节点。该节点可能希望获得地址供其自己使用，或者它可能是希望将网络扩展到其物理或虚拟子系统或两者的路由器。它可以是[RFC8200]定义的主机或路由器。
AP：Access Point，（无线）接入点
DHCPv6 IA_NA：Identity Association for Non-temporary Addresses，非临时地址的身份联盟（[RFC8415]第21.4节）
DHCPv6 IA_PD：Identity Association for Prefix Delegation，前缀代理的身份联盟（[RFC8415]的第21.21节）
DHCPv6-PD：DHCPv6 Prefix Delegation，DHCPv6前缀代理[RFC8415]；将IPv6前缀委托给客户端的机制。
ND：Neighbor Discovery，邻居发现[RFC4861]
NUD：Neighbor Unreachability Detection，邻居不可达检测[RFC4861]
PIO：Prefix Information Option，前缀信息选项[RFC4862]
SLAAC：Stateless Address Autoconfiguration ，IPv6无状态地址自动配置[RFC4862]
4、设计原则
此部署模型的运行方式如下：
* 设备充当DHCPv6-PD客户端，并通过发送IA_PD请求通过DHCPv6-PD请求前缀。
* 服务器向客户端委托一个前缀，并将委托的前缀安装到首跳路由器的路由表中，作为指向客户端链路本地地址的路由。首跳路由器可以充当DHCPv6中继并窥探来自离线DHCPv6服务器的DHCPv6回复消息，也可以充当DHCPv6服务器本身。在这两种情况下，它都可以在本地安装路由，如果网络运行动态路由协议，则将路由或整个前缀池分发到该协议中。
* 对于路由器和所有其他基础设施设备，委派前缀被视为离线，因此到该前缀的流量不会触发任何ND数据包，除了维持客户端链路本地地址的邻居不可达检测（Neighbor Unreachability Detection，NUD）所需的最小ND之外。
* 设备可以通过多种方式使用委托前缀。例如，它可以形成地址，如[RFC7084]的要求WAA-7中所述。它还可以扩展网络，如[RFC7084]或[RFC7278]中所述。
图1显示了一个示例场景。请注意，示例中使用的前缀长度是 /64，因为这是SLAAC当前支持的前缀长度，并且建议的部署模型不需要其他前缀长度。
图1：具有两个首跳路由器的拓扑示例
5、适用性和局限性
为每个客户端委派唯一的前缀可提供SLAAC和DHCPv6地址分配的所有优势，但代价是更大的地址空间使用率。这种设计将使某些网络受益匪浅（参见第12节），在这些网络中，附加服务（例如DHCPv6前缀代理）的额外成本和大量地址空间的分配很容易被证明是合理的。此类网络的示例包括但不限于：
* 大型网络，即使每个客户端有三到五个地址也可能会带来可扩展性问题。
* 具有大量虚拟主机的网络，因此物理设备需要多个地址。
* 可能需要大量故障排除、设备流量记录或取证的托管网络。
在较小的网络中，例如地址空间较小且客户端数量较少的家庭网络或小型企业，SLAAC是更简单且通常是首选的选择。
6、路由和寻址注意事项
6.1、前缀池分配
一种简单的部署模型是为每个链路分配专用的前缀池。每个链接池中的前缀仅发布给该链接上的请求客户端；如果客户端移动到另一个链接，他们将从与新链接关联的池中获取前缀（参见第9节）。
这与使用DHCP分配各个地址（例如DHCPv4或DHCPv6 IA_NA）时的地址池分配方式非常相似，其中每个链路都有一个专用的地址池，在链路上的客户端从该池中获取地址。在此模型中，网络可以将整个池路由到链路的首跳路由器，并且路由器不需要将各个委托前缀通告到网络的动态路由协议中。
其他部署模型（例如通过多个链路或路由器共享的前缀池）也是可能的，但本文档中未进行描述。
6.2、首跳路由器要求
在大型网络中，DHCPv6服务器通常是集中式的，并通过与首跳路由器位于同一位置的DHCPv6中继进行访问。为了将IPv6前缀委托给客户端，首跳路由器需要实现DHCPv6中继功能并满足[RFC8987]中定义的要求。特别是，根据[RFC8987]的第4.2节，首跳路由器必须维护一个本地路由表，其中包含委托给客户端的所有前缀。
由于首跳路由器执行DHCPv6中继功能，所提出的设计既不需要路径中的任何后续中继，也不会为此类后续中继（如果部署了这些后续中继）引入任何要求（例如，窥探）。
为了确保即使重新启动或更换中继，也能保留到委托前缀的路由，运营商必须确保网络基础设施中的所有中继都支持[RFC5460]中定义的DHCPv6批量租赁查询。虽然[RFC8987]的第4.3节列出了在持久存储中保留活动前缀代理作为DHCPv6批量租用查询的替代方案，但依赖持久存储具有以下缺点：
* 在具有多个中继的网络中，在中继重新启动时网络状态可能会发生显着变化（可能会委托新的前缀或某些前缀可能会过期等）。
* 如果物理更换路由器，则可能无法保留持久存储。
首跳路由器获取有关委托前缀信息的另一种机制是使用Active Leasequery[RFC7653]，尽管这尚未得到广泛支持。
6.3、具有多个首跳路由器的拓扑
在具有冗余首跳路由器的拓扑中，所有路由器都需要中继DHCPv6流量，将委派前缀安装到其路由表中，并在需要时将这些前缀通告到网络。
如果首跳路由器通过侦听服务器发送的DHCPv6 Reply消息来获取委托前缀信息，则所有首跳路由器都必须能够侦听这些消息。如果客户端组播它发送到服务器的DHCPv6消息，则这是可能的。服务器将通过每个首跳中继接收客户端消息的一个副本，并将通过从中接收消息的中继（或中继链）以单播方式回复每个客户端消息。因此，所有首跳中继将能够侦听答复。根据[RFC8415]第14节，客户端始终使用组播，除非服务器使用服务器单播选项明确允许单播通信（[RFC8415]，第21.12节）。因此，在具有多个首跳路由器的拓扑中，必须将DHCPv6服务器配置为不使用服务器单播选项。应该注意的是，[RFC8415bis]不赞成使用服务器单播选项，正是因为它与具有多个首跳中继的拓扑不兼容。
为了从崩溃或重新启动中恢复，中继可以使用Bulk Leasequery或Active Leasequery来发出带有其他中继ID的QUERY_BY_RELAY_ID（由操作员配置）。此外，一些供应商还提供特定于供应商的机制来同步DHCP中继之间的状态。
6.4、在线通讯
出于安全原因，某些网络会在二层阻止在链路上设备到设备的流量，以防止同一在链路上的客户端之间进行通信。在这种情况下，为每个客户端委派前缀不会影响流量，因为所有流量无论如何都会发送到首跳路由器。根据网络安全策略，路由器可能允许或丢弃流量。
如果网络允许点对点通信，则通常会在将L位设置为1的情况下通告在链路上前缀的PIO[RFC4861]。因此，来自该前缀的所有地址都被视为链接上的，并且直接发送到这些目的地的流量（不通过路由器）。如果这样的网络将前缀委托给客户端（如本文档中所述），则每个客户端都会将其他客户端的目标地址视为不在链路上，因为这些地址来自委托的前缀并且不再位于在线前缀内。当客户端向另一个客户端发送流量时，数据包最初将发送到默认路由器。路由器将使用ICMPv6重定向消息进行响应（[RFC4861]的第4.5节）。如果客户端接收并接受重定向，则流量可以直接在设备之间流动。因此，部署本文档中描述的解决方案的管理员应该确保首跳路由器可以发送ICMPv6重定向（路由器配置为这样做，并且安全策略允许这些消息）。
7、DHCPv6-PD服务器注意事项
本文档不会对DHCPv6协议本身进行任何更改。但是，为了使建议的解决方案正常工作，需要按如下方式配置DHCPv6-PD服务器：
* 服务器必须遵循[RFC8168]关于处理前缀长度提示的建议。
* 服务器必须提供一个足够短的前缀，以便客户端将网络扩展到至少一个接口，并允许该接口上的节点通过SLAAC获取地址。服务器可以通过委托多个此类前缀或委托较短长度的单个前缀来向请求的客户端提供更多地址空间。应该注意的是，[RFC8168]允许服务器提供比从客户端接收到的前缀长度提示值更短的前缀。
* 如果服务器通过多个中继多次从同一客户端接收到相同的请求消息，则它必须使用相同的前缀回复所有消息。这可确保所有中继正确配置到委托前缀的路由。
* 服务器不得向客户端发送服务器单播选项，除非网络拓扑保证没有客户端连接到具有多个中继的链路（参见第6.3节）。
* 为了确保首跳路由器崩溃或重新启动时连接不中断，服务器必须支持Bulk Leasequery或Active Leasequery。
由于大多数运营商对IPv4有一定的经验，因此他们可以使用类似的方法来选择池大小和计时器（例如T1和T2计时器）。尤其应考虑以下因素：
* 预计最大客户数量；
* 客户端连接的平均持续时间；
* 客户端的移动性如何（所有客户端都连接到单个有线VLAN的网络可能会选择比客户端可以在多个无线网络之间切换的网络更长的计时器）；
* 客户端预计重新连接到网络的频率（例如，企业经过身份验证的Wi-Fi网络可能使用比开放公共Wi-Fi更长的计时器）。
委托前缀的DHCPv6服务器可以与动态DNS基础设施连接，以使用通配符记录自动填充反向DNS，这与[RFC8501]的2.2节中描述的类似。也希望填充转发DNS的网络无法仅基于DHCPv6前缀委托事务自动执行此操作，但它们可以通过其他方式执行此操作，例如通过支持DHCPv6地址注册，如[ADDR-NOTIFICATION]中所述。
第15节和第13节讨论了出于安全和隐私考虑而提出的一些其他建议。
8、前缀长度注意事项
委托足够大小的前缀来使用SLAAC允许客户端扩展网络，为连接到它的IPv6节点（例如虚拟机或网络共享设备）提供无限的地址，因为所有IPv6主机都需要支持SLAAC[RFC8504]。此外，即使支持其他形式的地址分配的客户端也需要SLAAC来实现某些功能，例如形成专用地址以供464XLAT使用（请参阅[RFC6877]的第6.3节）。
截至撰写本文时，允许设备使用SLAAC的唯一前缀大小是64位。此外，如[RFC7421]中所述，使用短于64位的接口标识符（interface identifier，IID）和长于64位的子网前缀不符合当前IPv6规范。选择更长的前缀将要求客户端和任何连接的系统使用其他地址分配机制。这将限制所提出的解决方案的适用性，因为许多主机目前不支持其他机制。
出于同样的原因，需要 /64或更短的前缀长度来扩展网络，如[RFC7084]中所述（参见要求L-2），并且需要 /64的前缀长度来根据[SNAC-SIMPLE]为末节网络提供全局连接。
在大型网络上可以分配足够大小的前缀来支持SLAAC。一般来说，任何从长度为X（例如，X=/18、X=/24）的IPv4前缀对客户端进行编号的网络都需要长度为X+32（例如，X=/40、X=/56）的IPv6前缀，以便为每个设备提供 /64前缀。例如，[RFC7934]的第9.2节表明，即使是一个非常大的网络，分配10.0.0.0/8中1600万个IPv4地址中的每一个，也只需要一个IPv6 /40。 /40前缀是一小部分地址空间：当前IPv6单播范围2000::/3中的 /40数量比IPv4地址多32倍。当前使用 /48前缀的现有站点在不重新编号的情况下无法支持此模型中超过64k的客户端，尽管许多此类规模的网络具有本地互联网注册（Local Internet Registry，LIR）状态并且可以证明更大的地址块是合理的。
请注意，分配足够大小的前缀来支持SLAAC并不要求对向节点使用SLAAC；他们也可以使用其他地址分配机制。
9、客户端移动性
根据[RFC8415]第18.2.12节，当客户端移动到新链路时，它必须发起重新绑定/回复消息交换。因此，当客户端在网络连接点之间移动时，它将刷新其委托前缀，就像刷新从共享链路前缀分配的地址（通过SLAAC或DHCPv6 IA_NA）一样：
* 当客户端从同一在链路上的不同连接点之间移动时（例如，在连接到同一无线网络的同时在两个AP之间漫游，或在属于同一VLAN的两个交换机端口之间移动），委派前缀不会更改，并且首跳路由器具有前缀路由，下一跳设置为该在链路上的客户端链路本地地址。根据[RFC8987]第4.3节中的要求S-2，DHCPv6中继（首跳路由器）必须保留委托前缀的路由，直到该路由由于DHCP定时器到期而被释放或删除。因此，如果客户端重新连接到同一链接，前缀不会更改。
* 当客户端移动到不同的链路时，DHCPv6服务器会为客户端提供新的前缀，因此行为与SLAAC或DHCPv6分配的地址一致，但在新在链路上也有所不同。
理论上，即使客户端更改连接点，DHCPv6服务器也可以将相同的前缀委托给同一客户端。然而，虽然允许客户端在链路之间漫游时保持相同的前缀可能会给客户端带来一些好处，但如果不更改DHCPv6中继行为，这是不可行的：在客户端移动到新链路后，DHCPv6中继将在DHCPv6计时器的持续时间内保留指向旧在链路上客户端链路本地地址的路由（请参阅[RFC8987]的要求S-2，第4.3节）。因此，首跳路由器将具有指向不同链路的同一前缀的两条路由，从而导致客户端出现连接问题。
应该注意的是，从共享的在链路上前缀寻址客户端也不允许客户端在链路之间漫游时保留地址，因此所提出的解决方案在这方面没有什么不同。除此之外，不同的链路通常应用不同的安全策略（例如，公司内部网络与访客网络），因此不同在链路上的客户端需要使用不同的前缀。
10、防欺骗和SAVI交互
在面向客户端的首跳路由器接口上启用单播反向路径转发（unicast Reverse Path Forwarding，uRPF）[RFC3704]可提供针对欺骗的第一层防御。恶意客户端发送的欺骗数据包将被路由器丢弃，除非欺骗地址属于委托给同一接口上另一个客户端的前缀。因此，恶意客户端只能欺骗已委托给同一在链路上另一个客户端的地址或另一个客户端的链路本地地址。
源地址验证改进（Source Address Validation Improvement，SAVI）[RFC7039]提供更可靠的保护，防止地址欺骗。在支持SAVI的基础设施上部署建议的解决方案的管理员应确保SAVI外围设备支持DHCPv6-PD窥探，以便为委派前缀创建正确的绑定（请参阅[RFC7513]）。使用FCFS SAVI[RFC6620]保护链路本地地址并为DHCPv6-PD分配的前缀创建SAVI绑定可以防止欺骗。
一些基础设施设备没有实现[RFC7039]中定义的SAVI；相反，它们出于安全或性能改进的目的执行其他形式的地址跟踪和窥探（例如ND代理）。对于无线设备（例如接入点和控制器）来说，这是非常常见的行为。管理员应确保此类设备能够侦听DHCPv6-PD数据包，以便来自委托前缀的流量不会被丢弃。
应该注意的是，使用DHCPv6-PD使攻击者更难选择欺骗的源地址。当所有客户端都使用相同的共享链接来形成地址时，攻击者可能会通过侦听组播邻居请求和邻居通告来了解其他客户端使用的地址。然而，在DHCPv6-PD环境中，攻击者只能通过侦听组播DHCPv6消息来了解其他客户端的全局地址，这些消息传输频率不高，并且可能根本不会被客户端接收，因为它们被发送到特定于DHCPv6服务器和中继的组播组。
11、使用PIO前缀的迁移策略以及与SLAAC的共存
对于网络来说，明确指示其对连接的客户端的DHCPv6-PD支持将是有益的。
* 在小型网络（例如家庭网络）中，客户端数量不太多，可用前缀的数量成为限制因素。如果家庭网络中的每部电话或笔记本电脑都请求适合SLAAC的唯一前缀，并且ISP分配给客户驻地设备（Customer Premises Equipment，CPE）的前缀太长，则家庭网络可能会用完前缀。例如，如果ISP委派 /60，则CPE只能将15个 /64前缀代理给客户端。因此，虽然企业网络管理员可能希望网络中的所有电话都请求前缀，但非常不希望同一部电话在连接到家庭网络时请求前缀。
* 当网络同时支持每个客户端的唯一前缀和A=1的PIO作为地址分配方法时，客户端最好不要使用PIO前缀来形成全局地址，而只使用通过DHCPv6-PD委派的前缀。使用PIO前缀和DHCPv6-PD启动SLAAC，然后在收到委派前缀后弃用SLAAC地址将对应用程序产生很大的破坏。如果客户端继续使用由PIO前缀形成的地址，它不仅会破坏所提出的解决方案的好处（参见第12节），而且还会在源地址选择中引入复杂性和不可预测性。因此，如果网络提供设置了“A”标志的PIO，客户端需要知道使用什么地址分配方法以及是否使用PIO中的前缀。
本文档中描述的部署模型不需要网络发出对DHCPv6-PD支持的信号：例如，充当兼容路由器[RFC7084]的设备即使没有此类信号，也能够通过DHCPv6-PD接收前缀。此外，如果某些客户端检测到网络不通过SLAAC提供地址，它们可能会决定启动DHCPv6-PD并获取前缀。为了充分实现本节中描述的优点，[PIO-PFLAG]定义了一个新的PIO标志来表明DHCPv6-PD是获取前缀的首选方法。
12、好处
所提出的解决方案具有以下优点：
* 网络设备资源（例如内存）需要根据设备数量进行扩展，而不是根据IPv6地址数量进行扩展。每个设备的首跳路由器都有一条指向设备的链路本地地址的路由。这有可能节省硬件成本；例如，如果无线LAN控制器等硬件仅限于支持特定数量的客户端地址，或者在每个客户端地址消耗一个路由表条目的VXLAN部署中。
* 拥有多个地址的成本被转移给客户。主机可以根据需要自由创建和使用任意数量的地址，而不会给网络带来任何额外费用。
* 如果连接到给定链路的所有客户端都支持此操作模式，并且可以从委托前缀生成地址，则没有理由在设置了“A”标志的PIO中通告分配给该链路的公共前缀。因此，可以从该链路和路由器接口中完全删除全局共享前缀，因此该链路的在链路上没有全局地址。这将减少[RFC6583]中描述的邻居发现攻击的攻击面。
* 从首跳路由器获取的DHCPv6-PD日志和路由表提供有关IPv6到MAC映射的完整信息，可用于取证和故障排除。此类信息的动态性远不如ND缓存；因此，操作员可以更轻松地收集和处理它。
* 每个客户端的专用前缀允许网络管理员为每个设备创建安全策略（例如ACL），即使客户端使用临时地址也是如此。这可以缓解[IPv6-ADDRESS]中描述的问题之一。
* 命运共享：给定客户端使用的所有全局地址都作为单个前缀进行路由。它们要么全部起作用，要么全部不起作用，这使得故障更容易诊断和缓解。
* 较低级别的组播流量：较少的邻居发现[RFC4861]组播数据包，因为路由器只需要解析客户端的链路本地地址。此外，除了客户端的链路本地地址之外，不存在重复地址检测（Duplicate Address Detection，DAD）流量。
* 能够透明地扩展网络。如果网络向客户端委托足够大小的前缀来支持SLAAC，则客户端可以提供与其他主机的连接，就像使用NAT的IPv4中可能实现的那样（例如，通过充当IPv6客户边缘（Customer Edge，CE）路由器，如[RFC7084]中所述）。
13、隐私考虑
如果窃听者或信息收集者知道给定客户端正在使用所提出的机制，那么他们可能能够根据其前缀来跟踪客户端。这种情况的隐私影响相当于使用有状态DHCPv6地址分配的网络的隐私影响：在这两种情况下，IPv6地址都是由服务器确定的，要么是因为服务器在共享前缀中分配了完整的128位地址，要么是因为服务器确定将哪个前缀委托给客户端。部署所提议机制的管理员可以使用与目前使用状态DHCPv6地址分配的网络中使用的方法类似的方法来减轻影响。
除了主机不需要临时地址的网络（例如数据中心网络）[RFC8981]，网络应该：
* 确保当客户端请求前缀时，前缀是随机分配的，而不是确定性分配的。
* 使用较短的前缀生命周期（例如，几个小时）来确保当客户端断开连接并重新连接时，它会获得不同的前缀。
* 允许客户端同时拥有多个前缀。这允许客户端使用类似于临时地址的机制来轮换前缀，但它对前缀而不是单个地址进行操作。在这种情况下，前缀的生命周期必须足够短，以允许客户端使用合理的轮换间隔而不使用太多的地址空间。例如，如果客户端每24小时请求一个新前缀并停止更新旧前缀，并且委托前缀的有效生命周期为1小时，则客户端将在24小时中的1小时内消耗两个前缀，因此平均消耗略低于1.05个前缀。
14、IANA考虑因素
本文档没有IANA行动。
15、安全考虑
恶意（或行为不当）客户端可能会尝试通过发送大量具有不同DHCP唯一标识符（DHCP Unique Identifiers，DUID）的请求来耗尽DHCPv6-PD池。为了防止行为不当的客户端拒绝向其他客户端提供服务，DHCPv6服务器或中继必须支持限制在任何给定时间委托给给定客户端的前缀数量。
网络可以通过使用无法欺骗的令牌（例如802.1x身份验证）对设备进行身份验证并限制每个客户端允许使用的链路本地地址或MAC地址的数量来防止恶意客户端。请注意，这不是一个新问题，因为可以使用DHCPv4或DHCPv6 IA_NA请求来实施相同的攻击；特别是，虽然客户端不太可能耗尽IA_NA地址池，但使用IA_NA的客户端可能会耗尽其他资源（例如DHCPv6）和路由基础设施资源（例如服务器RAM、ND缓存条目、三态内容可寻址内存（Ternary Content-Addressable Memory，TCAM）条目、SAVI条目等）。
恶意客户端可能会请求一个前缀，然后很快释放它，从而导致中继上的路由收敛事件。如果网络对来自客户端的广播和组播消息量进行速率限制，则可以减少此攻击的影响。
为同一客户端委托相同的前缀会带来隐私问题。第13节讨论了拟议的缓解措施。
第10节讨论了欺骗场景和预防机制。
16、参考文献
16.1、规范性参考文献
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[RFC4193]Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.[RFC5460]Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, DOI 10.17487/RFC5460, February 2009, <https://www.rfc-editor.org/info/rfc5460>.[RFC6620]Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, <https://www.rfc-editor.org/info/rfc6620>.[RFC6877]Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>.[RFC7084]Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.[RFC8168]Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017, <https://www.rfc-editor.org/info/rfc8168>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.[RFC8273]Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, <https://www.rfc-editor.org/info/rfc8273>.[RFC8415]Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.[RFC8981]Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.[RFC8987]Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson, "DHCPv6 Prefix Delegating Relay Requirements", RFC 8987, DOI 10.17487/RFC8987, February 2021, <https://www.rfc-editor.org/info/rfc8987>.
16.2、参考资料
[ADDR-NOTIFICATION]Kumari, W., Krishnan, S., Asati, R., Colitti, L., Linkova, J., and S. Jiang, "Registering Self-generated IPv6 Addresses using DHCPv6", Work in Progress, Internet-Draft, draft-ietf-dhc-addr-notification-13, 16 May 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-dhcaddr-notification-13>.[IPv6-ADDRESS]Gont, F. and G. Gont, "Implications of IPv6 Addressing on Security Operations", Work in Progress, Internet-Draft, draft-ietf-opsec-ipv6-addressing-00, 2 June 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-opsecipv6-addressing-00>.[PIO-PFLAG]Colitti, L., Linkova, J., Ma, X., and D. Lamparter, "Signaling DHCPv6 Prefix per Client Availability to Hosts", Work in Progress, Internet-Draft, draft-ietf-6manpio-pflag-11, 4 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-6manpio-pflag-11>.[RFC3704]Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.[RFC4861]Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.[RFC4862]Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.[RFC6459]Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.[RFC6583]Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, <https://www.rfc-editor.org/info/rfc6583>.[RFC7039]Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <https://www.rfc-editor.org/info/rfc7039>.[RFC7278]Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, DOI 10.17487/RFC7278, June 2014, <https://www.rfc-editor.org/info/rfc7278>.[RFC7348]Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.[RFC7421]Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <https://www.rfc-editor.org/info/rfc7421>.[RFC7513]Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <https://www.rfc-editor.org/info/rfc7513>.[RFC7653]Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, October 2015, <https://www.rfc-editor.org/info/rfc7653>.[RFC7934]Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>.[RFC8200]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.[RFC8415bis]Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress, Internet-Draft, draft-ietfdhc-rfc8415bis-05, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-dhcrfc8415bis-05>.[RFC8501]Howard, L., "Reverse DNS in IPv6 for Internet Service Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, <https://www.rfc-editor.org/info/rfc8501>.[RFC8504]Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.[SNAC-SIMPLE]Lemon, T. and J. Hui, "Automatically Connecting Stub Networks to Unmanaged Infrastructure", Work in Progress, Internet-Draft, draft-ietf-snac-simple-05, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-snacsimple-05>.
附录A、多个地址注意事项
虽然典型的IPv4主机的每个接口通常只有一个IPv4地址，但IPv6设备几乎总是为其接口分配多个地址。至少，一台主机可以拥有一个链路本地地址、一个临时地址，并且在大多数情况下还有一个稳定的全局地址。在提供NAT64服务的网络上，运行464XLAT客户端转换器（CLAT）[RFC6877]的纯IPv6主机将使用通过SLAAC配置的专用464XLAT地址（请参阅[RFC6877]的第6.3节），这使得地址总数达到4。每个主机接口的地址数量可能显着增加的其他常见场景包括但不限于：
* 运行容器或命名空间的设备：每个容器或命名空间将具有多个地址，如上所述。因此，仅以桥接模式运行几个容器的设备可以轻松地在给定在链路上拥有20个或更多IPv6地址。
* 为给定链路分配多个前缀的网络：多归属网络、同时使用唯一本地IPv6单播地址（ULA、[RFC4193]）和非ULA前缀的网络，或者执行从一个前缀到另一个前缀的优雅重新编号的网络。
[RFC7934]讨论了这个方面并明确指出IPv6部署不应限制主机可以拥有的IPv6地址的数量。然而，据观察，网络通常会限制每个设备的链接地址数量，这可能是为了保护网络资源并防止DoS攻击。
最常见的网络限制场景是ND代理。许多企业级无线解决方案都实施ND代理，以减少广播和组播下游（AP到客户端）流量并提供SAVI功能。为了执行ND代理，设备通常维护一个包含所连接客户端的IPv6和MAC地址的表。至少某些实现对此类表中每个MAC可以包含的IPv6地址数量进行了硬编码限制。当超过限制时，行为取决于实现。有些供应商只是未能将N+1地址安装到表中。其他人删除该MAC的最旧条目并将其替换为新地址。在任何情况下，受影响的地址都会在没有收到任何隐式信号的情况下失去网络连接，流量会被静默丢弃。
致谢
感谢Harald Alvestrand、Nick Buraglio、Brian Carpenter、Tim Chown、Roman Danyliw、Gert Doering、David Farmer、Fernando Gont、Joel Halpern、Nick Hilliard、Bob Hinden、Martin Hunek、Erik Kline、Warren Kumari、David Lamparter、Andrew McGregor、Tomek Mrugalski、Alexandre Petrescu、Jurgen Schonwalder、Pascal Thubert、Ole Troan、Eric Vyncke、Eduard Vasilenko、Timothy Winters、Chongfeng Xie和Peter Yee，感谢他们的讨论、意见和所有贡献。
***推荐阅读***
我们的WireGuard管理系统支持手机电脑了！全平台终端配置，支持扫码连接，一键搞定
保姆级教程：一条命令部署OpenVPN管理系统V4版，支持Win/Mac/安卓/iOS全平台接入
成本省下99.7%！用40元的腾讯云服务器自建IPsecVPN，成功对接企业级飞塔防火墙
万物皆可EVE-NG！一招解决Ubuntu镜像MAC冲突
告别OSPF！EVE-NG专业版+BGP Unnumbered打通Underlay的完整实战
从180秒到0.01秒：智算中心Underlay路由优化的速度与激情
Type-2是管家，Type-5是外交官！Border Leaf让智算中心网络走出去
上医治未病！从PFC流控到ECN预警配置实战
路修好了，该跑车了！RoCE零成本部署，智算中心RDMA平替方案全公开
单边写入为何秒杀双边传输？从UDP 4791到BTH头，看懂RDMA的灵魂构造！
手机也能跑DeepSeek-R1/Qwen3了：零成本搭建AI推理平台
2048卡昇腾910C集群算力集群交付工程手册
2048卡H100算力中心100G无阻塞存储网建设方案
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：铁军哥 衡水石头哥 衡水石头哥《使用DHCPv6前缀代理（DHCPv6-PD）为大型广播网络中的每个客户端分配唯一的IPv6前缀》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论