Netalyzer says I have a IPv6 fragmentation problem.

[kasperd]

I believe best current operational practice for DNS over IPv6 is to send only 1280 byte UDP frames.

Then again, I don't think it is completely agreed upon how to get past the 512 byte limit that DNS was designed with.

The DNS request is unlikely to go past 512 bytes in the first place (it is actually not that easy to construct a valid DNS request larger than 512 bytes). The reply can easily be larger than 512 bytes, and it used to be the case, that you were supposed to switch to TCP in that case.

The client can include an EDNS option specifying that it is capable of receiving larger packets, and then the server can send a reply larger than 512 bytes, and larger than 1280 bytes even. But some consider this a problem because it could be used in amplification attacks.

With all the things that need to go on to ensure that DNS packets larger than 512 bytes are permitted, you'd think that PMTU discovery could be completed by the time you are ready to send a large packet. Unfortunately PMTU discovery is a bit less efficient than I'd like it to be. Why do you have to waste bandwidth sending a maximum sized packet to find the MTU. Potentially you'll need to send multiple large packets before you find the actual MTU.

I think a better option would have been a hop by hop option that contain the MTU seen so far, and is then decremented by each router along the path if it cannot handle as large a packet as indicated by that option. Then you'd just need a small packet going back and forth to find the PMTU. Unfortunately introducing such an option now is of limited value, because it would have to be supported by most routers in order to really help.

[kcochran]

Ok, MTU adjustment is live.

Currently supporting three options: 1480, 1472 and 1280.

[Quill]

Ok, MTU adjustment is live.

Currently supporting three options: 1480, 1472 and 1280.

Excuse my ignorance but I'm not really sure what this does. I have an MTU of 1380, do these settings have any meaning for me?

[kasperd]

I have an MTU of 1380, do these settings have any meaning for me?

How did you manage to figure out your MTU without knowing what it means? If your actual MTU is 1380, then the best choice from the list of options is 1280. I assume 1480 is still the default. If you stick with the default, then a small number of packets will get dropped on the way from the Internet to your computer.

[Quill]

I have an MTU of 1380, do these settings have any meaning for me?

How did you manage to figure out your MTU without knowing what it means? If your actual MTU is 1380, then the best choice from the list of options is 1280. I assume 1480 is still the default. If you stick with the default, then a small number of packets will get dropped on the way from the Internet to your computer.

I understand what MTU is, and as far as determining mine, I used tracepath. What I don't understand, is what kcochran posted and how that information relates to my MTU setting.

[snarked]

1280:  Minimum IPv6 MTU per the RFCs.
1480:  Standard MTU for an IPv6 encapsulated packet over IPv4 ethernet.
1472:  Similar to 1480, except encapsulated as PPPoE under IPv4.

That's what they mean and how they're derived.

[Quill]

1280:  Minimum IPv6 MTU per the RFCs.
1480:  Standard MTU for an IPv6 encapsulated packet over IPv4 ethernet.
1472:  Similar to 1480, except encapsulated as PPPoE under IPv4.

That's what they mean and how they're derived.

Thanks for the reply, I am, however, familiar with the individual MTUs listed. What I'm trying to ascertain is, what they mean to me with an MTU of 1380. As far as I can see, there's no difference, if that's the case, what relevance do the new settings have? 

[kasperd]

What I'm trying to ascertain is, what they mean to me with an MTU of 1380.

If your exact value is not on the list, you want to use the largest one among those that are less than your actual MTU. So first you eliminate 1472 and 1480 because those are larger than 1380. Then you take the largest among those that remain.

[Quill]

What I'm trying to ascertain is, what they mean to me with an MTU of 1380.

If your exact value is not on the list, you want to use the largest one among those that are less than your actual MTU. So first you eliminate 1472 and 1480 because those are larger than 1380. Then you take the largest among those that remain.

Thanks for the reply. So, you basically suggesting I should manually lower mu MTU to 1280, even though there's no apparent change in the way my tunnel is behaving and no apparent fragmentation?

[broquea]

If you aren't finding that you experience MTU issues with how the MTU is configured on HE's side, then no, you don't need to touch a thing. If however you do feel you are experiencing MTU related issues, then yes you can try changing the MTU on HE's side to see if that resolves the issue.

[kasperd]

If you aren't finding that you experience MTU issues with how the MTU is configured on HE's side, then no, you don't need to touch a thing.

Correct. As I indicated earlier, HE had auto detection of the MTU already before the new option was introduced. The possible values were limited to the range 1280-1480 bytes. As long as PMTU was working on the IPv4 connection from the tunnel server to your router, you shouldn't experience a problem. The autodetection would cause a single packet drop once every few minutes.

I haven't tested what the new option does, but I assume it changes the upper value of the range. If PMTU is not working on the IPv4 path from the tunnel server to your router, then you can lower the setting. For example a setting of 1472 should then autodetect in the range from 1280-1472, and a setting of 1280 would make the range 1280-1280 effectively turning off the autodetection.

[broquea]

Correct. As I indicated earlier, HE had auto detection of the MTU already before the new option was introduced

There is no MTU auto-detection; never has been. The MTU configured on HE's tunnel interface has always been 1480, and nothing else aside from maybe 3-4 requested settings to 1472 done manually. I don't know where the system would have suggested otherwise.

[kasperd]

There is no MTU auto-detection; never has been.

There most certainly is. I don't know for how long it existed. I learned about the existence of that feature about three weeks ago.

See this example:

ping6 -n -s 1424 2001:470:28:940::1
PING 2001:470:28:940::1(2001:470:28:940::1) 1424 data bytes
From 2001:470:0:11e::2 icmp_seq=1 Packet too big: mtu=1464
From 2001:470:28:940:1c82:31b3:813c:2e14 icmp_seq=2 Destination unreachable: No route
From 2001:470:28:940:1c82:31b3:813c:2e14 icmp_seq=3 Destination unreachable: No route

I got the tunnel server to report an MTU of 1464 bytes. That is not one of the configurable choices, but I was able to get the tunnel server to use that MTU by making use of the auto detection.

[broquea]

After running this broker from 2007 until 2012, I can promise you that the tunnel interfaces weren't configured with anything other than 1480. They did not dynamically change to some other number on the interface.

[kasperd]

They did not dynamically change to some other number on the interface.

The tunnel server on 216.66.80.90 does change the MTU of my tunnel dynamically. I have looked at the traffic with tcpdump, and there is no doubt that tunnel server is dynamically changing the MTU.

I think you have been looking at a number, that does not mean, what you think it means.

Anybody who have two computers on different public IPv4 addresses can create two tunnels and verify the existence of that feature. Once an ICMP message indicating an IPv4 MTU of 1484 bytes has been send to 216.66.80.90, there will be ICMPv6 packets from 2001:470:0:11e::2 indicating an IPv6 MTU of 1464 bytes.