Le 12 mars 2010 à 00:35, Mark Townsley a écrit : > On 3/10/10 10:24 PM, Brian E Carpenter wrote: ... >>> That's true today. But my experience while travelling and staying in >> random hotels towards the end of the dial-up era was that I often >> had to clamp the IPv4 MTU at (say) 512 to make things actually work. >> I've had experience with 6to4 of abject PMTUD failures with remote servers >> trying to do 1480. So I think that Remy is correct as far as a fail safe >> solution *today* goes. > And thank goodness we still don't fragment all IPv4 traffic >= 512 bytes. >> Since 6RD is very much a transitional technique >> before an ISP is ready to run native, I don't see this as a significant >> inefficiency. >> > The problem in this logic is that the argument for 1280 is not about the MTU > within the confines of the 6rd deployment, but outside across the Internet. > As such, it would apply equally to native IPv6 as it would to 6rd.
Yes, it DOES apply also to directly native IPv6. That's why it makes sense, in a 6rd RFC, to avoid dealing with any recommendation to advertise on a LAN link another MTU than that of the link itself. This means deleting this sentence: "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined automatically or configured directly, on the LAN side by setting the MTU option in Router Advertisements [RFC4861] messages to the 6rd Tunnel MTU." RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
