First, IPv4’s minimum is 68, not 64. The header can be up to 60 octets and the smallest fragment is 8 bytes.
Second, the problem with the logic that “bigger avoids fragmentation” is that the very specification of ANY minimum MTU, coupled with IP-in-IP tunnels (for their own sake, or as part of IPsec tunnel mode), ends up then requiring fragmentation. There’s no way around that - once there’s a required minimum and once it’s recursive, the game is over. (BTW, the only thing that bails you out is to then ensure you have fragmentation and that the receiver reassembly minimum is large enough to cover two fragments, one as large as you can fit as a payload and the other that fits a payload at least as large as the rest of the MTU). Joe > On Sep 10, 2019, at 3:53 PM, Geoff Huston <g...@apnic.net> wrote: > > >>> >>> This would seem to be incorrect. IP has a minimum MTU of 68 bytes, and >>> IPv6 has a minimum MTU of 1280. Hence if you send packets smaller than >>> or equal to the minimum MTU, the packets should go through. >> >> Even if the original source uses the IPv6 minimum MTU of 1280, a tunnel >> somewhere >> further down the path could add encapsulations that would cause the >> (encapsulated) >> packet to exceed 1280 bytes. The tunnel therefore has to apply fragmentation. > > I hesitate to venture into this thread but I did a bit of digging around in > the mail archives some time ago to figure out “why 1280?” as the IPv6 MTU. > The desire was to lift the minimum unfragmented packet from 64 bytes (IPv4) > to something that would reflect what was possible that would all but > eliminate the need for fragmentation in IPv6. But at the same time there was > the awareness of various forms of encapsulation and the possibility of > multiple levels. 1500 octets was taken as the stating point and in the end > 1280 was proposed. Why 1280? Because its the number you get when you add 1024 > and 256. However, it expressed a basic idea that 1480 (IPv6 in IPv4), 1460 > (IPv6 in IPv6), or any other number ‘close’ to 1500 could not. It allowed for > almost any form of encapsulation of an IPv6 packet that we would be likely to > see and the result would still be within the 1500 ethernet framing limit and > hence avoid a path MTU mismatch. From this starting point it is odd odd to > see an argument about packet size that _starts_ with 1280 as some lower level > media-related packet limit (it isn’t) and then applies encapsulation models > on this. If we really are going to go through such an exercise then it would > be more realistic to start with the number 1500 and apply encapsulation to > that number. > > Secondly, it is interesting to look at what IPv6 stacks actually do with > local MTU values. Do they all use 1280? nope! The most common value is 1430. > (see http://www.potaroo.net/ispcol/2019-07/mss.html) > > So I personally don't see any practical value in this line of logic that > says: "start with a source using a MTU of 1280 and apply encapsulation” > > But I’ve said enough - I’m heading back back to lurking in this rather > protracted and messy thread. > > g > > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
