Despite what one might read in certain techno-marketing publications, IPv4 is very much alive; it has not by any stretch yet been replaced by IPv6.
So it remains important that vendors of networking products do IPv4 and do it correctly.
But some vendors appear to be getting lazy.
In particular one of the largest vendors seems to be taking a shortcut that could leave users unable to communicate even though those users have otherwise perfectly usable packet service from their network providers.
The issue described here is relatively rare, but it does occur. And the software code to “do it right” is well known to be difficult – but certainly not impossible. In fact it may well be that this vendor retreated from a working code base that properly handled this matter.
So what is it that we are talking about?
The Windows 10 operating system from Microsoft does not properly adhere to RFC 1122 [https://tools.ietf.org/html/rfc1122] “Requirements for Internet Hosts — Communication Layers”.
RFC 1122 requires IPv4 to handle overlapping fragments. (See section 3.3.2 Reassembly). IPv4 is a core protocol for delivering packets over the Internet.
IP fragmentation is the process of splitting a single Internet Protocol (IP) datagram into multiple packets of smaller size. Packets have to be fragmented when they are too large for a network link. Every network link has its own maximum transmission unit (MTU). If a packet exceeds the size of the MTU, the MTU sender (whether that sender is the initial source or a router along the path) will fragment the packet in order to process it. Thus, the packet has to be split into smaller sections. Because switches and routers can send these packets along different paths to their ultimate destination, occasionally overlapping of the fragments may occur.
IPv4 requires that the receiver assemble these fragments back into the original whole. If the receiver does not receive all of the pieces within a time window all of the pieces are discarded. The pieces may arrive in any order, they may nicely abut one another, or there may be gaps that will be patched by later fragments, and in some cases the fragments may overlap.
Unfortunately Microsoft’s Windows 10 does not allow overlapping IPv4 fragments. In fact, Windows 10 discards the overlapping IPv4 fragments. The original packet could have been successfully delivered, just in overlapping fragments, not one datagram. But if the receiving node discards those fragments, without making an effort to reassemble them, then the fragments will not be processed.
The Microsoft website has no information on why Windows 10 did not follow the rules, or what the rationale or justification might be for this decision.
When fragments with overlapping content arrive at the destination device, that device must reassemble the fragments into a single cohesive packet (its original state). This IPv4 reassembly code is notoriously difficult to implement and test.
IPv6, unlike IPv4, requires that overlapping IPv6 fragments are discarded (see RFC 5722 [hyperlink https://tools.ietf.org/html/rfc5722]). Microsoft may have decided to simply reuse the newer IPv6 code in IPv4, thus avoiding implementation and testing of the more difficult IPv4 reassembly code.
Improve or Correct the RFC
In addition, since the newer IPv6 contains improvements, notably a larger address space, one might interpret the discarding of overlapping fragments as an error in IPv4, meriting correction. Microsoft may have decided that since IPv6 discards overlapping fragments, then IPv4 should probably have done that as well.
Finally, Microsoft may argue that IPv4 is less secure than IPv6, due to overlapping fragments. In the past, Denial of Service attack tools exploited poor implementations of the IPv4 re-assembly code, specifically the Teardrop and Land attacks (see https://www.cert.org/historical/advisories/ca-1997-28.cfm) However patches and corrections for these attacks have existed for 20 years, so that is not a credible reason for non-compliance with RFC 1122.
More recently, overlapping fragments exploited some firewalls by counting on the firewall to inspect only the first fragment of a packet, allowing the balance of the fragments to flow through, without inspection. However firewalls and Intrusion Detection Systems have found workarounds to prevent these types of attacks.
Nevertheless, Microsoft may have relied on these security vulnerabilities to decide to discard overlapping fragments in IPv4.
Since Windows 10 does not conform to RFC 1122 and discards overlapping fragments, a number of possible risks come to light. Windows 10 may break embedded systems and application software and present new interoperability problems.
Other operating systems, such as Linux and FreeBSD, continue to follow RFC 1122 and support overlapping IPv4 fragments.
A recent proposed standard RFC 6864, dated February 2013, noted no change in the need for hosts to support overlapping IPv4 fragments:
RFC 1122 also suggests that fragments can overlap. Such overlap can occur if successive retransmissions are fragmented in different ways but with the same reassembly IPv4 ID. This overlap is noted as the result of reusing IPv4 IDs when retransmitting datagrams, which this document deprecates. However, it is also the result of in-network datagram duplication, which can still occur. As a result, this document does not change the need for receivers to support overlapping fragments.
There is no RFC allowing overlapping IPv4 fragments to be discarded. Microsoft’s Windows 10 is not compliant with RFC 1122 that requires IPv4 to handle overlapping fragments. IWL’s tests will continue to follow RFC 1122. The specific tests for proper reassembly of overlapping fragments will continue to be graded for all stacks.
Is it okay to make IPv4 act like IPv6? Not at this time.