Is it Okay to Make IPv4 Act Like IPv6?

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  []  “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.

What does this mean?

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.

Why did Microsoft do this?

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.

Reuse Code

IPv6,  unlike IPv4, requires that overlapping IPv6 fragments are discarded (see RFC 5722 [hyperlink]).  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  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.

Performance Testing of an IOT Application Controlling the ESP8266 Microcomputer Mounted on a Drone

Have you thought about how you will test the performance of IoT apps and drones? Our new video demonstrates performance testing of an IOT application controlling the ESP8266 Microcomputer mounted on a drone! As you might expect, as the drone flies further away from the wireless base station, performance degrades. So how can you emulate that in your test lab?

Watch the video to learn more:

Why did Waze and Google Maps fail?

Waze, the “…world’s largest community-based traffic and navigation app” failed its users in the Santa Cruz, California area during the month of February 2017.  These users who depend on Waze to find out traffic conditions and alternate routes were not able to do so.  The same was true for Google Maps.  For example, when traffic stalled for up to three hours, Waze and Google Maps happily reported that conditions were just fine.

What happened?

Many Santa Cruz, CA residents commute from the beach community, and ever farther, to the Silicon Valley. They commute over highway 17, a four-lane twisty thoroughfare (two lanes in each direction), built over a mountain range.   Normal drive times span between 30 and 45 minutes each way.  Once your vehicle enters this highway, you are committed; you cannot turn around until you reach the other side of the mountain.

Continue reading Why did Waze and Google Maps fail?

Confide, a Favorite App of the White House, May Not Be Secure

A New York City based start-up company, Confide, offers a text messaging system “with encrypted messages that self-destruct.”  You can download the app at

Confide lets its users “discuss sensitive topics, brainstorm ideas or give unfiltered opinions without fear of the Internet’s permanent, digital record and with no copies left behind.”  “Messages disappear forever after they are read once, making them as private and secure as the spoken word.”

Continue reading Confide, a Favorite App of the White House, May Not Be Secure

Checking for New SNMP Vulnerabilities

Cisco Systems recently announced a patch for a vulnerability in Simple Network Management Protocol (SNMP) functions of some Cisco routers.  “This vulnerability could allow an authenticated, remote attacker to cause high CPU usage on an affected device, resulting in a denial of service (DoS) condition. The vulnerability is due to an incorrect initialized variable. An attacker could exploit this vulnerability by performing SNMP polling on MIBs and using only Interface Index (ifIndex) values. A successful exploit could allow the attacker to increase CPU usage to 99% on an affected device and cause a DoS condition.” 1

Continue reading Checking for New SNMP Vulnerabilities

More on SDN Complexity and Reality

SDN:  Software Defined Networks

SDN Complexity and Reality” by Russ White and Shawn Zandi, was published on page 31 of The Internet Protocol Journal, November 2016 (Volume 19, Number 3).  You can download ipj19-3.pdf at

In the article, White and Zandi, examine the original three crucial elements to the SDN story:

First, SDNs were supposed to remove the intelligence from the distributed control planes and consolidate that intelligence in a centralized controller.

Continue reading More on SDN Complexity and Reality

Why You Should Care About Impairment Testing of Internet Protocols


The Internet Is An Imperfect and Hostile Place

The world is an imperfect place.  The internet is no exception.  The internet has its good days and it has its bad days.  Or to be more precise, the internet has its good seconds and its bad seconds.

Blemishes in internet performance arise from many sources. Continue reading Why You Should Care About Impairment Testing of Internet Protocols

Waveforms in KMAX

Real network conditions are rarely static.  Real life networks suffer transient conditions – congestion builds up and dissipates, tree branches wave in the wind across radio links, long distance routing paths change, VoIP call trunks are filled with more calls during working hours than during the evening.  Even something as small as a person standing near a wi-fi access point can change the carrying capacity of a network.

KMAX (and our Maxwell Pro) can emulate these kinds of changes.

Continue reading Waveforms in KMAX