On Mon, 27 Oct 2003, Iljitsch van Beijnum wrote: > There is no need for any full-blown negotiation. A node can simply > announce the desired/supported maximum packet size at the time of > neighbor discovery and be done with it.
Some seem to want a full-blown option as well. Whether there would consensus to support it would be a different topic.. > I agree that it is unlikely a host with GE or similar would be unable > to support a decent maximum packet size, but it can't hurt to have the > option of triggering a smaller packet size. If such nodes are not expected to be common, it would seem to make sense to separate these very constrained nodes to a separate subnet (not necessarily even a separate link) if the full MTU size seems like a lucrative option. > > This is also the case for larger MTU's. This problem is nowhere near > > non-trivial. Consider e.g. an IPv6 link which is separated by two > > Ethernet switches, one which supports jumboframes (MTU=9K) and one > > which does not. How would the hosts be able to, with simple and > > robust mechanisms, to determine the MTUs to be used on such > > environment? > > This is why we need routers to explicitly advertise the maximum MTU > using a new option. No need for that, already supported now :-). > It is unlikely that people who need the extra > performance gained by the use of jumboframes are also the ones that > hook up a $20 switch to a $600 one. You would be surprised which vendors don't support jumbograms. The bit more expensive ones as well, for example, HP (very widely used around here at least). > > This approach seems to be adding complexity of L2 to IP layer where it > > doesn't belong. If we need to tackle this issue at L3, why not just > > simply use MTU 1280 or MTU 1500 and fragment the packet when needed? > > In IPv6, fragmentation overhead is too hideous and probably not > supported below 1280 bytes without changes anyway. But if this was only needed for very constrained nodes, one could argue that such nodes probably don't need do heavy communication anyway (otherwise they wouldn't be constrained nodes :-), so this shouldn't be a problem.. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
