10

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.

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
TeaCupApp
  • 11,316
  • 18
  • 70
  • 150

3 Answers3

15

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.

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.

The other issue is that if you 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. Intelligent implementations limit the number of outstanding fragments to prevent a denial of service from this; however, limiting outstanding fragments could legitimately affect the number of valid fragments that can be reassembled.

In short, there are just too many hairy issues to allow a router to handle fragmentation. If IPv6 packets require fragmentation, hosts implementations should be smart enough to use TCP Path MTU discovery. That 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 ICMPv6 breaks things in subtle ways4.


**END-NOTES:**
  1. See Section 4.5 of the Internet Protocol, Version 6 (IPv6) Specification

  2. 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.

  3. See Teardrop attack (wikipedia)

  4. See RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls

Community
  • 1
  • 1
Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
  • 1
    +1, it's amazing how much faster routers can be when they can do everything in hardware – mpontillo Jun 06 '11 at 17:33
  • 4
    Blocking all v4 ICMP is just as harmful - the Fragmentation Needed responses are just as important to PMTUD in IPv4. – caf Jun 08 '11 at 13:07
5

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.

Chris Thompson
  • 35,167
  • 12
  • 80
  • 109
0

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.

Steve-o
  • 12,678
  • 2
  • 41
  • 60
  • 4
    I'm sorry, it's not correct that IPv6 requires 1500 bytes. [RFC 2460](http://www.faqs.org/rfcs/rfc2460.html) allows layer2 MTUs as low as 1280 bytes, see Section 5. – Mike Pennington Jun 06 '11 at 17:26
  • 3
    Why does it matter whether the fragment is TCP or UDP? IPv4 fragmentation is handled at the IP layer. – Mike Pennington Jun 06 '11 at 17:29
  • @Mike datagram assembly isn't guaranteed. Many messaging middleware stacks include code specifically for reconstruction when the underlying IP stack does not guarantee it. – Steve-o Jun 06 '11 at 17:33
  • 2
    my suspicion is that you're mixing up TCP sequencing and re-assembly for a byte *stream*; as opposed to UDP (a datagram service) which means payloads are atomic, by definition. As a result, there may be platform code to construct a UDP message stream, but this is independent of IPv4 fragmentation. – Mike Pennington Jun 06 '11 at 17:36
  • @Mike actually I might be mixing raw IP datagrams with UDP datagrams, UDP datagrams may be guaranteed but IP datagrams are not. i.e. when implementing a custom protocol above IP. – Steve-o Jun 06 '11 at 17:38