TSI GabeRouter of Packets Premium Member join:2007-01-03 Gatineau, QC |
to Mersault
Re: IPv6 betayou 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 Member
2012-Sep-6 9:18 am
I'm using 1500 MTU since forever now? |
|
TSI GabeRouter of Packets Premium Member join:2007-01-03 Gatineau, QC |
TSI Gabe
Premium Member
2012-Sep-6 3:20 pm
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. |
|
|
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 Member
2012-Sep-8 11:45 am
Using OpenWRT here works great. |
|
|
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 |
rpnc
Member
2012-Sep-15 2:09 pm
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 (banned) join:2007-09-06 Etobicoke, ON |
34764170 (banned)
Member
2012-Sep-15 2:43 pm
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. |
|
|
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 |
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 |
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 GabeRouter of Packets Premium Member join:2007-01-03 Gatineau, QC |
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 |
|
|
Any plans to give us rdns control on our block??
Ty! |
|
|