我想知道 - 是否有人编写一个能够处理 IPv6 的简单数据包分析器来分析 Windows（Vista 或更高版本）和 RHEL5 之间收集的流量机器 - 在那里看到分段的 IPv6 数据包的机会有多大，即这些操作系统将执行 IPv6 数据包的分段？
我知道从技术上讲它可以存在并且在 RFC 中进行了描述，但考虑到 IPv4 时代已知的与碎片相关的安全风险 - 我想知道 - 为什么现代网络堆栈根本不放弃 IP6 碎片功能？为什么我们仍然需要它，隧道或其他什么？
更新：正如我上面提到的，IP 碎片会带来安全风险。以下是支持该声明的链接：
【问题讨论】：
标签： ipv6
改编自原文： 好的，所以 IPv6 路由器无法对数据包进行分段，它们被丢弃并返回 ICMPv6 数据包太大。这意味着端节点在链路 MTU 上执行协商。然而，这一切都描述了链路层，根据 OSI，高层不必关心低层的所有细节。
考虑到 IPv4 硬件可能支持高达 9,000 字节的 jumbograms，但数据报大小可以达到 64KB。使用 TCP，操作系统可以使用底层链路大小并优化分割数据流，一切都很好。然而，对于 UDP，在系统管理员注意到问题并重新配置软件之上处理此类协商的支持有限。
假设您有一些固定数据报大小为 8,000 字节的软件，要从 IPv4 迁移到 IPv6，如果端到端 MTU 仅为 1,500 字节，则可以选择分段，或者丢弃所有内容。在一个很好的清理中，您要求完全删除碎片，但这会破坏应用程序，需要重写的不仅仅是套接字初始化处理。
IPv6 仍然是 IP，我们的想法并不是要破坏一切，尽管提出的更改会删除所有影响性能的功能：建议至少 1,500（如 IPv4 中的 576，参见 68/1,280 abs. min），而不是分段途中。
详细说明 ASIC 硬件导致的各种 MTU 限制的 Cisco 页面：
示例
在带有IPv4 和IPv6 的Linux 2.6.38-10-generic 上。 IPv4在Wireshark中显示分片，IPv6只显示应用层分片。
tcpdump 显示：
11:13: IP aiko.hk.miru.hk.37505 > 239.192.0.1.7600: UDP, length 1972
11:13: IP aiko.hk.miru.hk.37505 > 239.192.0.1.7600: UDP, length 1117
11:15: IP6 fe80::230:1bff:feb7:a209.51993 > ff08::1.7600: UDP, length 1137
数据包是高于 IPv4 或 IPv6 的 UDP 之上的 PGM。 3,000 字节有效负载和 2,000 字节 MTU，因此应该有 IP 分片和 PGM 分片。
【讨论】：
在 Linux 中，如果上层提供的数据包大于发现的链路 MTU 的数据包，则会分段发送 IPv6 数据包，而 TCP 不会发生这种情况。
【讨论】：
如果任何应用程序曾经尝试通过标准以太网连接（禁用的巨型帧）使用 IPv6 生成 UDP 数据报，总有效负载（包括报头）大于 1500 字节，那么您将保证在 IPv6 上看到碎片层。
根据路径 MTU 分析的结果，堆栈可能会选择更早开始插入片段，从总有效负载（包括标头）少至 1280 字节开始。
【讨论】：
使用 IPv6 执行此操作会中断：
ICMP、UDP、TCP 转发器、TCP 实现由于接收到的数据包太大而以片段的形式重新传输先前发送的帧，以及任何其他 IP 层协议期望能够传输大小为 > MTU 的消息，但缺少协议特定的分段层。
UDP 尤其庞大。有些部署的系统依赖于这种工作，没有替代解决方案。您可能会破坏某些 SIP 或 SNMP，但在大多数情况下，它可以通过旋钮进行配置和工作。其他协议（例如 RADIUS）不提供此类选项，并且会直接中断而没有追索权。
【讨论】：