dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
2953

mb6
join:2000-07-23
Washington, NJ
Netgear CM1150V
Netgear R7800

1 edit

mb6

Member

[IPv6] MTU

Got this advisory from Netalyzer: »netalyzr.icsi.berkeley.e ··· =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?

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

1 edit

2 recommendations

whfsdude

Premium Member

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

dslcreature

Premium Member

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
From My Cold Dead Hands
Premium Member
join:2004-06-24
The Boro
Netgear CM500
Pace 5268AC
TRENDnet TEW-829DRU

NetFixer to mb6

Premium Member

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


         


dslcreature
Premium Member
join:2010-07-10
Seattle, WA

dslcreature

Premium Member

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
From My Cold Dead Hands
Premium Member
join:2004-06-24
The Boro
Netgear CM500
Pace 5268AC
TRENDnet TEW-829DRU

NetFixer

Premium Member

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?
NetFixer

1 edit

NetFixer to mb6

Premium Member

to mb6
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
 

dslcreature
Premium Member
join:2010-07-10
Seattle, WA

dslcreature to NetFixer

Premium Member

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.

mb6
join:2000-07-23
Washington, NJ

mb6

Member

Still getting the same report. Everything else tests OK.

NetDog
Premium Member
join:2002-03-04
Hollywood, FL

1 recommendation

NetDog to mb6

Premium Member

to mb6
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/Pa ··· iscovery 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.'

mb6
join:2000-07-23
Washington, NJ
Netgear CM1150V
Netgear R7800

mb6

Member

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?

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

1 edit

whfsdude

Premium Member

said by mb6:

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
From My Cold Dead Hands
Premium Member
join:2004-06-24
The Boro
Netgear CM500
Pace 5268AC
TRENDnet TEW-829DRU

1 edit

NetFixer to mb6

Premium Member

to mb6
said by mb6:

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

mb6
join:2000-07-23
Washington, NJ
Netgear CM1150V
Netgear R7800

mb6

Member

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 Member
join:2002-03-04
Hollywood, FL

NetDog

Premium Member

said by mb6:

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

NetFixer
From My Cold Dead Hands
Premium Member
join:2004-06-24
The Boro
Netgear CM500
Pace 5268AC
TRENDnet TEW-829DRU

1 recommendation

NetFixer

Premium Member

said by NetDog:

said by mb6:

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

cp
Premium Member
join:2004-05-14
Wheaton, IL

cp to mb6

Premium Member

to mb6
said by mb6:

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
From My Cold Dead Hands
Premium Member
join:2004-06-24
The Boro
Netgear CM500
Pace 5268AC
TRENDnet TEW-829DRU

1 edit

NetFixer

Premium Member

said by cp:

said by mb6:

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.

camper
just visiting this planet
Premium Member
join:2010-03-21
Bethel, CT

camper to NetFixer

Premium Member

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
From My Cold Dead Hands
Premium Member
join:2004-06-24
The Boro
Netgear CM500
Pace 5268AC
TRENDnet TEW-829DRU

NetFixer

Premium Member

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