With all this talk of 1280 as the minimum *link* MTU, I think it's easy to forget that 2460 states:
> A node must be able to accept a fragmented packet that, after > reassembly, is as large as 1500 octets. A node is permitted to > accept fragmented packets that reassemble to more than 1500 octets. > An upper-layer protocol or application that depends on IPv6 > fragmentation to send packets larger than the MTU of a path should > not send packets larger than 1500 octets unless it has assurance that > the destination is capable of reassembling packets of that larger > size. So there was a very clear expectation that the *application level API* could always rely on being able to transmit as much data as it wanted as long as it didn't exceed a *1500* octet packet, and that this would always be reliably transmitted end to end. Anyone not transmitting this data across their network is currently ignoring a must in 2460. We should not forget the effect that changing such an important API parameter will have. I think Brian Carpenter has certainly got that in his suggestion. But perhaps some additional limits on the sanity of fragments might allow us to maintain a minimum 1500 octet limit at the API level, whilst allowing middleware boxes to process them correctly? [ I do realise that (nested) tunnels will always be problematic, no matter where you set any MTU limit, but that's nothing new and we have ways of dealing with that] regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
