简化高级网络：DHCPv6前缀委派

IPv4使应用代码复杂化并影响电池续航

当今大部分互联网流量仍使用IPv4，这种协议无法为应用提供透明的端到端连接。IPv4仅提供2^32个地址——远少于当今互联网设备数量——因此不可能为每个Android设备分配公共IPv4地址，更不用说设备内的单个应用或功能。大多数互联网用户使用私有IPv4地址，并通过网络地址转换（NAT）与同一网络的其他用户共享公共IPv4地址。

NAT使得构建高级网络应用（如视频通话应用或VPN）变得困难，因为这类应用需要定期发送数据包以保持NAT会话活跃（这会损害电池续航），并需要实现STUN等复杂协议以允许设备通过NAT相互连接。

为何IPv6尚未解决此问题

新版互联网协议IPv6——目前约半数Google用户在使用——提供几乎无限的地址空间和设备使用多个地址的能力。当每个设备都能获得全局IPv6地址时，就不需要为地址共享使用NAT！但尽管地址空间本身不再受限，当前在Wi-Fi上使用的IPv6地址分配方法（如SLAAC和DHCPv6 IA_NA）仍存在限制。

一方面，SLAAC和DHCPv6 IA_NA都需要网络为每个单独地址维护状态，因此为每个Android设备分配超过几个IPv6地址可能导致网络扩展问题。这意味着通常无法为设备内的VM或容器分配IPv6地址，也无法为连接的可穿戴设备和其他绑定设备分配地址。例如，如果应用运行在连接到Android手机的可穿戴设备上，或运行在通过Android手机连接到Wi-Fi的绑定平板电脑上，它可能没有IPv6连接，需要处理NAT的复杂性和电池影响。

此外，我们收到一些用户和网络运营商的反馈，希望更严格控制Android设备使用的IPv6地址。到目前为止，Android仅支持SLAAC，这种协议不允许网络分配可预测的IPv6地址，且更难跟踪IPv6地址与使用设备之间的映射关系。这限制了某些网络上Android设备的IPv6可用性。

解决方案：通过DHCPv6 PD实现专用IPv6地址块

为克服这些缺点，我们增加了对RFC 8415和RFC 9762定义的DHCPv6前缀委派（PD）的支持。Android网络堆栈现在可以从网络请求专用前缀，如果获得前缀，将使用它获取IPv6连接。在未来的版本中，设备将能够与可穿戴设备、绑定设备、虚拟机和Thread等存根网络共享前缀，为所有这些设备提供全局IPv6连接。这真正实现了IPv6的潜力，允许端到端、可扩展地连接到无限数量的设备和功能，而无需NAT。由于前缀由网络分配，网络运营商可以使用现有DHCPv6日志记录基础设施跟踪哪个设备在使用哪个前缀（有关部署DHCPv6 PD的指南，请参阅RFC 9663）。

这使得网络能够完全实现IPv6的潜力：设备保持SLAAC的灵活性，例如使用几乎无限数量地址的能力，而网络保持传统DHCPv6设置的可管理性和可追溯性。我们希望这将使更多网络过渡到IPv6，为应用提供端到端IPv6连接，并减少对NAT穿越和保活的需求。

对应用开发者的意义

DHCPv6 PD支持预计将在年底前通过Google Play系统更新推送到大多数运行Android 11及更高版本的设备。无需任何操作即可利用此功能——它将在支持的网络透明提供IPv6连接。我们希望这一变化鼓励更多网络采用IPv6，从而在这些复杂网络场景中改善电池续航、可靠性和代码简洁性。如果您有复杂的网络应用，且应用或服务器不支持IPv6，现在可能是利用它来提高可靠性和电池续航的好时机。