标准套接字接口隐藏了数据包处理细节，无法满足应用直接控制 IPv6 分片的需求。IPv4 原始套接字支持完整 IP 数据报收发，但 RFC3542 规定 IPv6 原始套接字无法发送或接收含扩展头的完整数据包，开发者需采用替代方案实现分片控制。
标准套接字与原始套接字的分工：
操作系统通过套接字 API 提供共享协议引擎，应用层无需自行实现 TCP/UDP 与 IP 头部封装。标准套接字模拟外设模型，read/write 操作即可完成网络通信，协议驱动在内核态完成报文组装与解析。实验中需要构建 IPv6 UDP 与 TCP 服务器并由应用直接决定分片策略，标准接口因屏蔽底层报文事务而无法使用。IPv4 提供 SOCK_RAW 选项，配合 IP_HDRINCL 套接字选项可让应用自行构造完整 IP 头部并绕过内核 IP 协议栈，代码片段演示了 AF_INET 与 IPPROTO_TCP 组合下的原始套接字创建流程。
IPv6 原始套接字的协议限制：
从 IPv4 迁移到 IPv6 通常只需将地址族改为 AF_INET6、地址结构扩展至 128 位，但原始套接字机制发生根本性变化。RFC3542 明确指出：IPv6 原始套接字 API 无法发送或接收包含扩展头的完整 IPv6 数据包。内核在写入原始套接字时会自动插入基础 IPv6 头部与必要扩展头，应用层仅能操作上层协议载荷。这种设计导致应用无法像 IPv4 那样通过 IP_HDRINCL 完全接管分片过程，原文未给出具体数据说明内核如何处理分片决策。
工程替代方向：
因 IPv6 原始套接字不暴露完整报文控制权，实现应用层分片控制需转向其他机制。可考虑在用户态构建完整 IPv6 协议栈，或利用数据平面开发套件（DPDK）等旁路内核方案直接操作网卡收发原始帧。另一思路是配合内核模块或 eBPF 程序在内核态拦截并修改分片逻辑。原文未给出具体实现代码或性能对比数据，工程师需根据延迟、吞吐与维护成本在用户态协议栈、内核旁路与内核插桩三条路径中权衡。
对运维与网络工程师而言，理解 IPv6 原始套接字的受限本质可避免在分片控制类需求上走弯路。当业务要求精确控制 IPv6 分片行为时，不应尝试移植 IPv4 原始套接字代码，而应评估用户态协议栈、内核旁路或内核插桩方案的适用性，并在测试环境验证分片策略对路径 MTU 发现与防火墙穿透的实际影响。
原文: APNIC Blog（2017-10-24）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog