[CE] 看起来还是有些人没见过世面，今天就来带大家见识一下什么叫做不合理的 DHCPv6。
你说它下发 IPv6 了吗？如发。
首先带大家复习一下 《关于推进IPv6技术演进和应用创新发展的实施意见》（工信部联通信〔2023〕45号）
…
（三）加快IPv6基础设施演进发展
5.加快网络基础设施升级演进。基础电信企业面向行业数字化转型需求，加快骨干网、城域网、5G网络升级改造，基于分段路由、网络切片、随流检测、应用感知网络、服务功能链（SFC）等技术， 提升企业专线、家庭宽带、移动终端等业务服务能力。开展“网络去NAT”专项行动，向互联网用户分配的IPv4私网地址加快退出。鼓励物联网平台、网关、模组等采用IPv6单栈部署，加强基于“IPv6+”的5G承载网研究和试点。强化IPv6在园区网络中的应用部署，在Wi-Fi 6/7网络中全面使用IPv6技术。
…
但就这，他妈的中国电信居然还在用错误的 IPv6 配置，一用他妈就是长达一个练习时长…
我就可好奇，他妈用了两年半的 IPv6 错误配置他们是一下都不带发现的吗？
中途他妈甚至换了一次光协议，结果 v6 支持他妈还是一样的恶心，
你们就那么缺那点地址？发个 /64？
他妈的你看看正常运营商谁他妈下发 /64 的不都得至少 /60 来分
你倒好，不想用 IPv6 就他妈直接说，别他妈整这点有的没的，一看就是为了完成 IPv6 部署而整点 IPv6。
我日你妈的中国电信，给我赶紧毁灭得了，
罗浮粗口，罗德岛粗口，VI粗口，地球粗口。
璃月粗口，蒙德粗口，〇〇粗口，混混粗口。
Section 2.5.1 of IP Version 6 Addressing Architecture, RFC4291
1 | Full Copyright Statement |
Section 6.3, 18.2.10.1 of Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC8415
1 | Copyright Notice |
在处理完这些烦人的法律问题之后，让我们回来继续讨论刚刚我们提到的问题。
Figure 1 illustrates a network architecture in which prefix
delegation could be used.______________________ \ / \ \ | ISP core network | \ \__________ ___________/ | | | +-------+-------+ | | Aggregation | | ISP | device | | network | (delegating | | | router) | | +-------+-------+ | | / |Network link to / |subscriber premises / | +------+------+ \ | CPE | \ | (requesting | \ | router) | | +----+---+----+ | | | | Subscriber ---+-------------+-----+ +-----+------ | network | | | | +----+-----+ +-----+----+ +----+-----+ | |Subscriber| |Subscriber| |Subscriber| / | PC | | PC | | PC | / +----------+ +----------+ +----------+ / Figure 1: Prefix Delegation NetworkIn this example, the server (delegating router) is configured with a
set of prefixes to be used for assignment to customers at the time of
each customer’s first connection to the ISP service. The prefix
delegation process begins when the client (requesting router)
requests configuration information through DHCP. The DHCP messages
from the client are received by the server in the aggregation device.
When the server receives the request, it selects an available prefix
or prefixes for delegation to the client. The server then returns
the prefix or prefixes to the client.
The client subnets the delegated prefix and assigns the longer
prefixes to links in the subscriber’s network. In a typical scenario
based on the network shown in Figure 1, the client subnets a single
delegated /48 prefix into /64 prefixes and assigns one /64 prefix to
each of the links in the subscriber network.
简单来说，就是用户端设备（请求路由器）发出一个 DHCPv6 请求到运营商设备（委派路由器），委派路由器会选择一个或者几个前缀发到请求设备上，然后由请求路由器来从这个前缀当中生成更长的前缀来下发到每个连接上。
When a client subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes.
这是 RFC 对 DHCPv6 客户端的要求。
All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1. Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.
The type of an IPv6 address is identified by the high-order bits of the address, as follows:
Address type Binary prefix IPv6 notation Section ------------ ------------- ------------- ------- Unspecified 00...0 (128 bits) ::/128 2.5.2 Loopback 00...1 (128 bits) ::1/128 2.5.3 Multicast 11111111 FF00::/8 2.7 Link-Local unicast 1111111010 FE80::/10 2.5.6 Global Unicast (everything else)
简单来说，就是除了 Unspecified，Loopback（回环）和 IPv4兼容的 IPv6 地址，所有的全球单播地址（最终分配到设备上的）全部要求是 64 位子前缀+64 位端口识别码
但是由于中国电信傻逼般的操作，路由器拿到的都是一个 /64 的前缀
受到 RFC8415-18.2.10.1 限制，它必须尝试拿出一个比 /64 还要小的前缀来分 （比如说 /68）
但是又受到 RFC4291-2.4 & 2.5.4 限制，它不能那么做
然后你就拿不到 IPv6 了。
结论：操你妈中国电信。