dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
33
share rss forum feed


Mersault

join:2007-10-26
Toronto, ON
reply to TSI Gabe

Re: IPv6 beta

Gabe,

I'm still getting errors about MTU when I run the ICSI Netalyzer:


IPv6 Path MTU (?): Warning –
Your system can receive fragmented traffic, but can not send fragmented traffic over IPv6. The path between our system and your network has an MTU of 1486 bytes. The bottleneck is at IP address 2607:f2c0:1:2110::13. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.


Can you give us any info about this issue? Any reason I should ignore it even? I'm running MPD on FreeBSD9 with MLPPP enabled and two links. Here's what MPD has to say about the bundle:


Bundle level options:
ipcp enable
ipv6cp enable
compression disable
encryption disable
crypt-reqd disable
bw-manage disable
round-robin disable


Round-robin is disabled, which if I understand what I'm doing properly means I should be able to run full 1500 byte packets through my WAN because the packets are split in half and each half goes down one of the tunnels and the packet is reconstructed on the TekSavvy side, bypassing the MTU issues common to PPP connections.

Any comment from the TekSavvy network guys?


TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7

you absolutely need to configure your MTU to 1486 wether you are using MLPPP or not.

Well let me rephrase that...1492 without MLPPP. 1486 with MLPPP. You cannot use 1500.



rodjames
Premium
join:2010-06-19
Gloucester, ON

I'm using 1500 MTU since forever now?



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7

I'm using MPD + IPv6 + MLPPP as well at home and I most definitely have it configured to use 1486 and never had any issues. I don't recommend using 1500...it might work but it's not proper.


rhooper

join:2004-05-06
Ottawa, ON

Are you using MPD w/pfSense, roll-your-own, Tomato or other? I'm presently using pfSense with some hacks to make IPV6 work. In general pfSense seems good, but it has some quirks that annoy me. Looking for something better.



rodjames
Premium
join:2010-06-19
Gloucester, ON

Using OpenWRT here works great.



Mersault

join:2007-10-26
Toronto, ON
reply to TSI Gabe

said by TSI Gabe:

you absolutely need to configure your MTU to 1486 wether you are using MLPPP or not.

Well let me rephrase that...1492 without MLPPP. 1486 with MLPPP. You cannot use 1500.

Regardless of what MTU I use, the device at 2607:f2c0:1:2110::13 should be able to handle fragmented IPv6 packets, should it not? The F5 support site (support.f5.com) fragments packets (whether this this wise on their part or not is irrelevant, they fragment) and so it's impossible to view that site without explicitly setting your MTU to be be sub-1500. If 2607:f2c0:1:2110::13 would pass the fragments at least the site should load.

rpnc

join:2011-06-08
Markham, ON

said by Mersault:

said by TSI Gabe:

you absolutely need to configure your MTU to 1486 wether you are using MLPPP or not.

Well let me rephrase that...1492 without MLPPP. 1486 with MLPPP. You cannot use 1500.

Regardless of what MTU I use, the device at 2607:f2c0:1:2110::13 should be able to handle fragmented IPv6 packets, should it not? The F5 support site (support.f5.com) fragments packets (whether this this wise on their part or not is irrelevant, they fragment) and so it's impossible to view that site without explicitly setting your MTU to be be sub-1500. If 2607:f2c0:1:2110::13 would pass the fragments at least the site should load.

IPv6 routers do not fragment packets - unlike IPv4. So if one side chooses too big of IPv6 packet then it won't make it to the other side. IPv6 is supposed to choose the lowest MTU along a path but it's better to set the lower MTU yourself.

34764170

join:2007-09-06
Etobicoke, ON

said by rpnc:

IPv6 routers do not fragment packets - unlike IPv4. So if one side chooses too big of IPv6 packet then it won't make it to the other side. IPv6 is supposed to choose the lowest MTU along a path but it's better to set the lower MTU yourself.

I'm not saying this is an issue here but a general comment..

With IPv6 it is critical for path MTU discovery to work properly. Problem is too many break path MTU discovery within the IPv4 world with wrong firewall rules never mind with IPv6 where too many people use the same set of wrong firewall rules and the pain is much much greater. Too many people foolishly block all ICMP and that is wrong. But they seemingly like having a broken network I guess.


Mersault

join:2007-10-26
Toronto, ON
reply to rpnc

said by rpnc:

IPv6 routers do not fragment packets - unlike IPv4. So if one side chooses too big of IPv6 packet then it won't make it to the other side. IPv6 is supposed to choose the lowest MTU along a path but it's better to set the lower MTU yourself.

While in a perfect world this would be true, it's not what I have observed. IPv6 was designed with the idea that it would do MTU path discovery, and that upper layer protocols would sort out payload size. DNSSEC pretty much blew that idea out of the water. DNS can't do fragments, and DNSSEC responses regularly blow past 1500 bytes. But I'm not even talking about DNSSEC. I've seen websites that fragment over IPv6.

Now I'm not saying it's correct. I'm just saying it happens. And it's one of those instances where the adage that you should be liberal in what you accept and conservative in what you transmit holds true. While I certainly would be dismayed to learn a webhost I ran was fragmenting packets improperly, I'm equally dismayed to learn that my network can't handle them correctly.


Mersault

join:2007-10-26
Toronto, ON
reply to TSI Gabe

More from the ICSI Netalyzer: "The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1486 bytes. The bottleneck is at IP address 206.248.154.101."

Looks like an MTU of 1500 is possible with MLPPP. Which should be reasonable if we're splitting and reassembling the packets at the PPP layer. Now of course, this is only true if we're actually running two full PPP tunnels, and not the "single link MLPPP" thing that some people use to defeat the Bell DPI systems.


Majromax

join:2012-09-02
Dollard-Des-Ormeaux, QC

1 recommendation

reply to Mersault

said by Mersault:

said by rpnc:

IPv6 routers do not fragment packets - unlike IPv4.

While in a perfect world this would be true, it's not what I have observed. IPv6 was designed with the idea that it would do MTU path discovery, and that upper layer protocols would sort out payload size.

Rpnc is correct above. In the IPv6 specification, along-route routers must not independently fragment packets. The originating host, however, may. This is perfectly acceptable, and it is in fact required behaviour. The IPv6 specification requires hosts to allow fragment reassembly up to 1500 octets (bytes), and a host may silently drop larger reassembled packets. For best performance the upper-layer protocols shouldn't be sending packets larger than the MTU, but anything = 1500 octets is supposed to get there by specification, even if fragmentation is necessary by the IP layer.

The IPv6 behaviour here is analogous to the IPv4 behaviour when the 'Don't Fragment' bit is set. Otherwise, IPv4 routers are permitted to fragment packets en-route, and this becomes extremely complicated when routers can potentially re-fragment the fragments. Since they never manipulate fragments themselves, IPv6 routers can be dumber.


TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7
reply to Mersault

Ok so let me start this over

Single Non-MLPPP Line = MTU of 1492
Single MLPPP Line = MTU of 1486
Multiple MLPPP line (assuming you are splitting your packets properly both ways) = MTU of 1500
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )


ggqc007

join:2012-02-23
Canada

Any plans to give us rdns control on our block??

Ty!