On 6to4 gateway and recommended MTU setting

[Ole Troan]

Brian,

>>>>> The better question is actually: why bother with 6to4?
>>>>> 
>>>>> Yes, it is a nice quick deployment strategy, but for anything long term,
>>>>> go native... (or at least native addresses using 6rd or something).
>>>> But with 6rd you will end up in the same discussion.
>>> 6to4 and 6rd are *both* transitional solutions that will die in due time.
>>> 
>>> Since we have plenty of running code experience that they work well with
>>> 1280 and sometimes hit PMTUD failures with 1480, any operator who wants to
>>> avoid unwanted phone calls will use 1280. Time enough to worry about an
>>> optimal value when you go native.
>>> 
>>> By the way, we didn't know enough when RFC3056 was written to suggest a
>>> default, and we were too optimistic about PMTUD, so it didn't seem to matter.
>> 
>> I see no reason to suggest a default of 1280 for 6rd though, as one can expect the MTU to be well managed within the ISP. unless you also wanted to suggest that the default IPv6 MTU for _every_ independent of linktype must be 1280? if we do that, will we ever get away from it again?
>> 
> 
> I guess. But as I've said over in the IETF discussion, experience with
> broken PMTUD in IPv4 was that setting a low value was the least painful
> choice, until things got better in the network as a whole.

aren't there two issues here. it is the issue of the tunnel MTU itself being smaller than the transport MTU to avoid fragmentation, and then there is the end to end IPv6 MTU.

we could say in the IETF IPv6  CPE router requirement draft that the default MTU should be advertised as 1280 for example. but that's a pretty big change.

Geoff Huston has an interesting blog post on the issue of MTU
http://www.potaroo.net/ispcol/2009-02/mtu.html

cheers,
Ole