dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1431
share rss forum feed


mb

join:2000-07-23
Washington, NJ
Reviews:
·Comcast
·Verizon Online DSL

1 edit

[IPv6] MTU

Got this advisory from Netalyzer: »netalyzr.icsi.berkeley.edu/m=comcast

IPv6 Path MTU (?): Warning –

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



whfsdude
Premium
join:2003-04-05
Washington, DC

1 edit

2 recommendations

That is fine.

Packet fragmentation isn't supposed to occur in IPv6 as there is end-to-end path MTU discovery (PMTUD).

On a side note, this is why it's so important not to broadly filter ICMPv6.


dslcreature
Premium
join:2010-07-10
Seattle, WA
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.


NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
The Boro
Reviews:
·Cingular Wireless
·Comcast Business..
·Vonage
reply to mb
         
If you want to run a test for large IPv6 packets and proper PMTUD implementation, try running the test at »test-ipv6.com/
         


         


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


dslcreature
Premium
join:2010-07-10
Seattle, WA
said by NetFixer:

         
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.


NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
The Boro
Reviews:
·Cingular Wireless
·Comcast Business..
·Vonage
said by dslcreature:

said by NetFixer:

         
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.


NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
The Boro
Reviews:
·Cingular Wireless
·Comcast Business..
·Vonage

1 edit
reply to mb
Here is an interesting subtest on the ipv6-test.com site that you can run: »ipv6-test.com/pmtud/

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

Here is the result I see from that test:

Testing packet size: 1500
Result: 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:

C:\>ping -6 ipv6.dcsenterprises.net -l 1472
 
Pinging ipv6-dcs-srv.dyndns-ip.com [2601:5:c80:62:e291:f5ff:fe95:beac] with 1472 bytes of data:
 
Packet needs to be fragmented but DF set.
Reply from 2601:5:c80:62:e291:f5ff:fe95:beac: time=44ms
Reply from 2601:5:c80:62:e291:f5ff:fe95:beac: time=32ms
Reply from 2601:5:c80:62:e291:f5ff:fe95:beac: time=34ms
 
Ping statistics for 2601:5:c80:62:e291:f5ff:fe95:beac:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 32ms, Maximum = 44ms, Average = 36ms
 
C:\>ping -6 ipv6.dcsenterprises.net -l 1442
 
Pinging ipv6-dcs-srv.dyndns-ip.com [2601:5:c80:62:e291:f5ff:fe95:beac] with 1442 bytes of data:
 
Reply from 2601:5:c80:62:e291:f5ff:fe95:beac: time=28ms
Reply from 2601:5:c80:62:e291:f5ff:fe95:beac: time=28ms
Reply from 2601:5:c80:62:e291:f5ff:fe95:beac: time=28ms
Reply from 2601:5:c80:62:e291:f5ff:fe95:beac: time=28ms
 
Ping statistics for 2601:5:c80:62:e291:f5ff:fe95:beac:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 28ms, Maximum = 28ms, Average = 28ms
 

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


dslcreature
Premium
join:2010-07-10
Seattle, WA
reply to NetFixer
said by NetFixer:

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.

The IPv6 test site is simply not intended for this.


mb

join:2000-07-23
Washington, NJ
reply to mb
Still getting the same report. Everything else tests OK.


NetDog
Premium,VIP
join:2002-03-04
Parker, CO
kudos:80

1 recommendation

reply to mb
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 am not a big wiki person but take a look at this: »en.wikipedia.org/wiki/Path_MTU_Discovery look at this section "Problems with PMTUD"

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


mb

join:2000-07-23
Washington, NJ
Reviews:
·Comcast
·Verizon Online DSL
Eureaka,

I checked the security settings on my (Comcast IPv6 approved) Cisco e4200v2 and disabled:

FILTER ANONYMOUS INTERNET REQUESTS

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



whfsdude
Premium
join:2003-04-05
Washington, DC
Reviews:
·Comcast

1 edit
said by mb:

FILTER ANONYMOUS INTERNET REQUESTS

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?

My guess is this is just blocking Echo Request rather than the entire ICMPv6 protocol. If it's just blocking echo requests, you're fine.

With that said, I find obscurity gets me nothing, and I leave ping available for troubleshooting.


NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
The Boro
Reviews:
·Cingular Wireless
·Comcast Business..
·Vonage

1 edit
reply to mb
said by mb:

Eureaka,

I checked the security settings on my (Comcast IPv6 approved) Cisco e4200v2 and disabled:

FILTER ANONYMOUS INTERNET REQUESTS

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.


mb

join:2000-07-23
Washington, NJ
Reviews:
·Comcast
·Verizon Online DSL
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....


NetDog
Premium,VIP
join:2002-03-04
Parker, CO
kudos:80
said by mb:

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


NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
The Boro
Reviews:
·Cingular Wireless
·Comcast Business..
·Vonage

1 recommendation

said by NetDog:

said by mb:

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.


Clever_Proxy
Premium
join:2004-05-14
Villa Park, IL
reply to mb
said by mb:

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


NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
The Boro
Reviews:
·Cingular Wireless
·Comcast Business..
·Vonage

1 edit
said by Clever_Proxy:

said by mb:

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.


camper
Premium
join:2010-03-21
Bethel, CT
kudos:1
Reviews:
·Comcast
reply to NetFixer
said by NetFixer:

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.


NetFixer
Freedom is NOT Free
Premium
join:2004-06-24
The Boro
Reviews:
·Cingular Wireless
·Comcast Business..
·Vonage
said by camper:

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.