[IPv6] MTU

Your system can not send or receive fragmented traffic over IPv6.The path between your network and our system supports an MTU of at least 1496 bytes. The path between our system and your network has an MTU of 1500 bytes. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.

Can someone translate?

--"When will they ever learn? When will they ever learn?" Pete Seeger 1961

There is some confusion on this point. To summarize IPv6 works the same as IPv4 only with the don't frag bit permanently set.

This means IPv6 does not allow intermediate routers to fragment packets which would otherwise exceed MTU toward the downstream path.

With IPv6 the only option for fragmentation is the peer. The peer must guess correctly the path MTU and not send a packet exceeding it. Like IPv4 it is still possible to send fragmented packets for example UDP message exceeding path MTU but each fragment must be less than path MTU or it is dropped.

You SHOULD be able to receive fragmented IPv6 packets. If not something is wrong with either path discovery (filtering "too big" indications) or an intermediate router is configured to drop fragments.

If you want to run a test for large IPv6 packets and proper PMTUD implementation, try running the test at »test-ipv6.com/

Not capable of checking the point raised by netalyzer.

Since you seem to have inside information (other than the information that is published on the test sites), how about enlightening the rest of us?--A well-regulated militia, being necessary to the security of a free State, the right of the people to keep and bear arms shall not be infringed.

When governments fear people, there is liberty. When the people fear the government, there is tyranny.

It explicitly tests IPv6 MTU starting at 1200 and incrementing to 1500.

Here is the result I see from that test:

Testing packet size: 1500Result: no PMTUD problems detected

EDIT: Mea Culpa!Oops, Never Mind! I looked at the JavaScript for the above test, and it did not really seem to be testing anything. I then lowered the MTU in the router that this PC was using to 1470, and the test results (as I expected) did not change.

However the old fashioned ping test for MTU did detect the difference:

Since you seem to have inside information (other than the information that is published on the test sites), how about enlightening the rest of us?

Its based on knowledge of browser security model. Standard browser programming environment does not have needed access to the operating system to cause a fragment to be transmitted nor does it have the ability to detect receipt of one (although this can be inferred the ipv6 test does not do it). Netalyzr does.

The PMTUD scheme used is also problematic. It works by sending spurts of data over TCP at a time followed by a delay to the users browser. When it DOES NOT work it can be an informative indication of a problem and is therefore useful.

However when it DOES work this does not necessarily mean PMTUD actually worked. It is very common these days for operating systems to be able to detect and work around systems foolishly electing to drop all ICMP using a variety of methods.

None of this works for UDP applications. If you have a UDP application such as a realtime video stream and there is no PMTUD you'll never know it unless the application has machinery to explicitly probe the end to end path.

Likewise if PMTUD does work but non-initial fragments are being dropped and you transmit a datagram > MTU it will cause breakage.

I have looked at this same issues on the Comcast Forums. Some routers\firewalls block ICMPv6, by design this a a bad thing for IPv6. The protocol uses ICMP very heavily and if a firewall\router admin dosen't understand IPv6 they tend to block it.

I like this line 'Many network security devices block all ICMP messages for perceived security benefits, including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection.'

which blocks ping requests from the Internet to the router. Now Netalyzer reports a clean bill of health (except for the known blocked ports).

The question for the experts is: Should I filter anonymous internet requests or should I not and be able to send/receive fragmented traffic over IPv6?--"When will they ever learn? When will they ever learn?" Pete Seeger 1961

which blocks ping requests from the Internet to the router. Now Netalyzer reports a clean bill of health (except for the known blocked ports).

The question for the experts is: Should I filter anonymous internet requests or should I not and be able to send/receive fragmented traffic over IPv6?

This is an interesting post; it caused me to recheck everything on my network for ICMP blocking. I had always explicitly allowed bidirectional ICMP in the internal firewalls of PC type devices, and had always allowed WAN ping responses in routers. None of the routers I currently use have a "FILTER ANONYMOUS INTERNET REQUESTS" setting...but perhaps the Enable/Disable SPI setting on my routers does the same thing (and I always have SPI enabled).

My D-Link DIR655 (which is my IPv6 gateway router) has the ability to create IPv6 firewall rules. I had already created an IPv6 outbound "allow all" LAN to * rule for all traffic, and an IPv6 inbound "allow all" WAN to LAN rule for all ICMP traffic. I changed the ICMP6 rule to become "allow all" WAN to *, and I no longer got the MTU warning message on the Netalyzr test. It appeared that the D-Link router might have been intercepting the ICMP6 traffic and not forwarding it to the LAN where the PC running the test could respond to it.

Next, I connected a notebook to my guest connection Netgear WNR1000v2-VC router. But I did not really expect to be able to do anything about that connection because I had already enabled the WAN ping response setting, and its IPv6 firewall only has a "Secured" and "Open" setting that applies to all connected IPv6 clients (my setting is set to "Secured"). To my surprise, the Netalyzr test did not complain about IPv6 MTU problems (and I had done this exact same thing only a couple of days ago).

I then went back to the PC I had used to run the Netalyzr test previously, and changed the DIR655 ICMP6 firewall rule back to its original settings. Now the Netalyzr test still runs with no IPv6 MTU complaints on that PC (or on another PC that had previously also gotten the IPv6 MTU warning). Since my PC, network, and router settings are now the same as they were previously (settings that previously got the Netalyzr IPv6 MTU warning), I can only assume that something has changed in the Internet path to/from my connection (and this would imply changes on two different IPv4 and IPv6 subnets with different Comcast gateways), or that the folks at ICSI changed something in their test.

Got to love IT work, it is seldom boring (although frequently frustrating).--A well-regulated militia, being necessary to the security of a free State, the right of the people to keep and bear arms shall not be infringed.

When governments fear people, there is liberty. When the people fear the government, there is tyranny.

Well, after reading NetFixer's experience I reran Netalyzer with the FILTER ANONYMOUS INTERNET REQUESTS security setting reverted back to enabled, and now I too again am getting a clean bill of health. So I am withdrawing the Eureaka and chocking it up to be a miraculous self fix....

Well, after reading NetFixer's experience I reran Netalyzer with the FILTER ANONYMOUS INTERNET REQUESTS security setting reverted back to enabled, and now I too again am getting a clean bill of health. So I am withdrawing the Eureaka and chocking it up to be a miraculous self fix....

I really hate it when things "work them self out" I am a big fan of cause.. effect.. then fix--Comcaster.. Network Engineer with NETO

Well, after reading NetFixer's experience I reran Netalyzer with the FILTER ANONYMOUS INTERNET REQUESTS security setting reverted back to enabled, and now I too again am getting a clean bill of health. So I am withdrawing the Eureaka and chocking it up to be a miraculous self fix....

I really hate it when things "work them self out" I am a big fan of cause.. effect.. then fix

Unfortunately for those of us who like "cause.. effect.. then fix", when you are working with the Internet and its multiple sources/destinations/paths that is often not the case; especially so when you are not an insider at the location where the fix is done (issuing a public mea culpa doesn't mesh with the culture in most corporations). I can't count the number of times that a chronic intermittent circuit problem (especially when multiple vendors and service providers were involved) would suddenly and mysteriously just go away (and none of the involved parties would take the "credit" for the fix, because that would also imply taking the blame for the problem).--A well-regulated militia, being necessary to the security of a free State, the right of the people to keep and bear arms shall not be infringed.

When governments fear people, there is liberty. When the people fear the government, there is tyranny.

Well, after reading NetFixer's experience I reran Netalyzer with the FILTER ANONYMOUS INTERNET REQUESTS security setting reverted back to enabled, and now I too again am getting a clean bill of health. So I am withdrawing the Eureaka and chocking it up to be a miraculous self fix....

I would be very suspect of this. What may be happening is that the icmp rules were re-enabled, but the traffic is still being allowed through due to statefulness. This happens a lot with iptables.

Well, after reading NetFixer's experience I reran Netalyzer with the FILTER ANONYMOUS INTERNET REQUESTS security setting reverted back to enabled, and now I too again am getting a clean bill of health. So I am withdrawing the Eureaka and chocking it up to be a miraculous self fix....

I would be very suspect of this. What may be happening is that the icmp rules were re-enabled, but the traffic is still being allowed through due to statefulness. This happens a lot with iptables.

I would reboot your equipment and run tests again...

I did. Using three different PCs and two different routers.--A well-regulated militia, being necessary to the security of a free State, the right of the people to keep and bear arms shall not be infringed.

When governments fear people, there is liberty. When the people fear the government, there is tyranny.

Unfortunately for those of us who like "cause.. effect.. then fix", when you are working with the Internet and its multiple sources/destinations/paths that is often not the case; especially so when you are not an insider at the location where the fix is done (issuing a public mea culpa doesn't mesh with the culture in most corporations). I can't count the number of times that a chronic intermittent circuit problem (especially when multiple vendors and service providers were involved) would suddenly and mysteriously just go away (and none of the involved parties would take the "credit" for the fix, because that would also imply taking the blame for the problem).

You've run into the classic dichotomy of the technical people who would not have any issues with saying "mea culpa" vs. the management people who fear their annual bonus would be reduced if a mea culpa were to be uttered.

You've run into the classic dichotomy of the technical people who would not have any issues with saying "mea culpa" vs. the management people who fear their annual bonus would be reduced if a mea culpa were to be uttered.

Yep, I have on numerous occasions gotten "I didn't tell you this, but..." hints from telco engineers/techs that I could not put into a final incident report (which just had to read as "problem disappeared".--A well-regulated militia, being necessary to the security of a free State, the right of the people to keep and bear arms shall not be infringed.

When governments fear people, there is liberty. When the people fear the government, there is tyranny.