On Fri, 12 Mar 2010 11:38:28 +0100 Rémi Després <[email protected]> wrote:
> > 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." > So all communications from hosts on the LAN is to the Internet? If you shrink the LAN MTU for the tunnel's benefit (or even just the native IPv6 Internet's benefit), you also shrink the LAN's MTU for any communications between the devices on the LAN. Consider the performance impact of dropping the LAN MTU to 1280 if the chosen LAN MTU is 9000 bytes for local LAN performance. I don't think the presence of a 6RD tunnel always implies that the dominant traffic path is to and from the Internet and the LAN - it could be there just for remote management / reachability e.g. ssh, email, snmp, occasional software / OS upgrades and updates. An example of such a scenario might be where somebody puts a HPC cluster in remote colo somewhere in the world to gain the benefits of cheaper cooling and power, and the ISP/Colo provider uses 6RD to provide interim IPv6 connectivity. Because a very high percentage of large amounts traffic is local to the cluster, larger LAN MTUs provide performance benefits. That's all assuming that the directly upstream router is the 6RD tunnel end-point. If there is a routed local IPv6 infrastructure, does the 6RD tunnel's MTU now force the whole site to have a 1280 byte MTU? These are the sorts of scenarios which have made me wonder whether there should be some sort of mechanism to express different off-link and on-link MTUs or on-site and off-site MTUs (distinguished by an on-site aggregate prefix). Regards, Mark. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
