从 IPv6 中消除碎片有哪些好处？
我正在开发一个项目，其中包括使用 java 套接字开发应用程序。然而，在阅读一些基础知识和新推出的 IPv6 范例时，这促使我提出以下问题：
从 IPv6 中消除碎片有什么好处？
如果有人能让我理解为什么会很有帮助？
我在互联网上进行了研究，但没有找到任何有用的描述。
I was working on a project which includes developing an application using java sockets. However while reading some fundamentals and newly upcoming IPv6 paradigm which motivated me to ask below question,
What are the benefits of removing fragmentation from IPv6?
It would be helpful if someone can give me understanding about why?
I have researched on internet but haven't found any useful description.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
前言
一个常见的误解是 IPv6 不存在分段，因为 IPv6 标头没有 IPv4 所具有的分段偏移字段；然而，它并不完全准确。 IPv6 不允许路由器对数据包进行分段；然而，终端节点可以插入IPv6分段标头1。
IPv4 碎片和安全漏洞
正如 RFC 5722 所述2，碎片的问题之一是它往往会产生安全漏洞。 20 世纪 90 年代末，出现了几起针对 Windows 95 的著名攻击，这些攻击利用了重叠的 IPv4 片段3；此外，由于必须处理的问题很长，因此数据包的内联碎片有可能被互联网路由器芯片烧毁。最大的问题之一是，如果处理不当，路由器中缓冲的重叠片段（等待重组）可能会导致该设备上的安全漏洞。最终结果是大多数路由器实现将需要分段的数据包推送给软件；这不能以高速扩展。
IPv4 路由器缓冲分段
另一个问题是，如果 IPv4 路由器配置为重新组装分段，则必须将它们缓冲一段时间，直到收到其余分段。有人可能会利用这种动态并发送大量未完成的 IP 片段；迫使相关设备花费大量资源等待重新组装的机会。
总结
简而言之，有太多棘手的问题让路由器无法处理碎片。 IPv6 主机实现应使用 TCP 路径 MTU 发现，尽可能避免分段；然而，众所周知，UDP 对于 SNMP get-bulk 等应用程序来说是分段的。 PMTUD 还意味着需要端到端允许多个 ICMPv6 消息；有趣的是，许多 IPv4 防火墙管理员阻止 ICMP 以防止恶意网络映射（然后天真地阻止所有 ICMPv6），而没有意识到阻止所有 ICMP 会以微妙的方式破坏事情4。
END-NOTES
请参阅互联网协议第 6 版 (IPv6) 规范
第 4.5 节RFC 5722：处理重叠 IPv6 片段：
常用的防火墙使用指定的算法
在 RFC1858 中清除尝试的恶意数据包
覆盖部分传输层标头
为了绕过入站连接检查。 RFC1858
防止重叠片段攻击
通过推荐上层协议（在本例中为 TCP）
片段偏移量为 1 的数据包将被丢弃。
虽然这对于 IPv4 片段很有效，但它不会起作用
对于 IPv6 片段。这是因为可碎片部分
IPv6数据包之前可以包含扩展标头
TCP 标头，使得此检查效果较差。
请参阅Teardrop 攻击（维基百科）
请参阅RFC 4890：建议在防火墙中过滤 ICMPv6 消息
Preface
It is a common mis-understanding that there is no IPv6 fragmentation because the IPv6 header doesn't have the fragment-offset field that IPv4 does; however, it's not exactly accurate. IPv6 doesn't allow routers to fragment packets; however, end-nodes may insert an IPv6 fragmentation header1.
IPv4 Fragmentation and Security Vulnerabilities
As RFC 5722 states2, one of the problems with fragmentation is that it tends to create security holes. During the late 1990's there were several well-known attacks on Windows 95 that exploited overlapping IPv4 fragments3; furthermore, in-line fragmentation of packets is risky to burn into internet router silicon due to the long list of issues that must be handled. One of the biggest issues is that overlapping fragments buffered in a router (awaiting reassembly) could potentially cause a security vulnerability on that device if they are mis-handled. The end-result is that most router implementations push packets requiring fragmentation to software; this doesn't scale at large speeds.
IPv4 Router Buffering of Fragments
Another issue is that if IPv4 routers are configured to reassemble fragments, you must buffer them for a period of time until the rest are received. It is possible for someone to leverage this dynamic and send very large numbers of unfinished IP fragments; forcing the device in question to spend many resources waiting for an opportunity to reassemble.
Summary
In short, there are just too many hairy issues to allow a router to handle fragmentation. IPv6 hosts implementations should use TCP Path MTU discovery to avoid the need for fragmentation where possible; however, UDP is known to be fragmented for applications such as SNMP get-bulk. PMTUD also implies that several ICMPv6 messages need to be permitted end-to-end; interestingly many IPv4 firewall admins block ICMP to guard against hostile network mapping (and then naively block all ICMPv6), not realizing that blocking all ICMP breaks things in subtle ways4.
END-NOTES
See Section 4.5 of the Internet Protocol, Version 6 (IPv6) Specification
From RFC 5722: Handling of Overlapping IPv6 Fragments:
Commonly used firewalls use the algorithm specified
in RFC1858 to weed out malicious packets that try
to overwrite parts of the transport-layer header in
order to bypass inbound connection checks. RFC1858
prevents an overlapping fragment attack on an
upper-layer protocol (in this case, TCP) by recommending
that packets with a fragment offset of 1 be dropped.
While this works well for IPv4 fragments, it will not work
for IPv6 fragments. This is because the fragmentable part
of the IPv6 packet can contain extension headers before
the TCP header, making this check less effective.
See Teardrop attack (wikipedia)
See RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls
我没有给你“官方”答案，但仅根据阅读 IPv6 如何处理太大的数据报，我的猜测是减少路由器上的负载。分段和重组会在路由器上产生开销。 IPv6 将这一负担转移到终端节点，并要求它们执行 MTU 发现以确定它们可以发送的最大数据报大小。按理说，终端节点更适合这项任务，因为它们需要处理的数据较少。实际上，路由器的任务已经够多了。强制节点处理它并允许路由器简单地丢弃超过其 MTU 阈值的内容是有意义的。
理想情况下，最终结果是路由器在 IPv6 下（所有条件相同）可以处理比 IPv4 下更大的负载，因为它们不必担心分段/重组。该处理器能力可以专用于路由流量。
I don't have the "official" answer for you, but just based on reading how IPv6 handles datagrams that are too large, my guess would be to reduce the load on routers. Fragmentation and reassembly incurs overhead at the router. IPv6 moves this burden to the end nodes and requires that they perform MTU discovery to determine the maximum datagram size they can send. It stands to reason that the end nodes are better suited for the task because they have less data to process. Effectively, the routers have enough on their plates; it's makes sense to force the nodes to deal with it and allow the routers to simply drop something that exceeds their MTU threshold.
Ideally, the end result would be that routers can handle a larger load under IPv6 (all things being equal) than they did under IPv4 because there is no fragmentation/reassembly that they have to worry about. That processor power can be dedicated to routing traffic.
IPv4 保证的最小 MTU 为 576 字节，IPv6 为
1,5001,280 字节，推荐为 1,500 字节，区别主要是性能。由于大多数最终用户 LAN 段为 1,500 字节，因此由于需要较小尺寸的有效遗留网络产生额外碎片，因此可以减少用于存储状态的网络基础设施开销。对于 UDP，IPv4 标准中没有关于分段数据包重建的定义，这意味着每个平台可以以不同的方式处理它。 IPv6 断言分片和组装将始终发生在 IP 堆栈中，并且分片不会呈现给应用程序。
IPv4 has a guaranteed minimum MTU of 576 bytes, IPv6 is
1,5001,280 bytes, and recommendation is 1,500 bytes, the difference is basically performance. As most end-user LAN segments are 1,500 bytes it reduces network infrastructure overhead for storing state due to additional fragmentation from what are effectively legacy networks that require smaller sizes.For UDP there is no definition in IPv4 standards about reconstruction of fragmented packets which means every platform can handle it differently. IPv6 asserts that the fragmentation and assembly will always occur in the IP stack and fragments will not be presented to applications.