Hi John, > Should we consider clarifying the IPv6 specs to state that routers and > end-user nodes will send ICMP packet-too-big responses when receiving a > too-big packet *OF ANY SIZE* which they can't forward onto the next > interface due to an MTU limit? (Or which the end node can't process > due to a limit in its NIC or elsewhere in its implementation.)
That is the way it is supposed to work already. ICMP PTB is supposed to be sent whenever a too-big packet of any size is dropped due to a link size restriction. But, it is not always possible to rely on PTBs regardless of the size of the restricting link. Fred > -----Original Message----- > From: John Gilmore [mailto:g...@toad.com] > Sent: Thursday, March 24, 2022 3:48 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > Cc: Joel M. Halpern <j...@joelhalpern.com>; int-area <int-area@ietf.org> > Subject: [EXTERNAL] Re: [Int-area] IP Parcels & jumbo frames > > EXT email: be mindful of links/attachments. > > > > I have general sympathy for things that would improve the ability of end > nodes to send larger packet sizes. As LAN and WAN speeds rise, latency > goes down since each packet takes less time on the medium, but packet > processing overhead goes up, since you must be able to receive 10x as > many existing-size packets in a given second over a 10xfaster link. > > In that regard, Herbie Robertson raised what seems like an important > issue that could be addressed with a small "nit" fix to the IPv6 specs: > > I still remember implementing path MTU discovery thinking about the > big performance win I was going to get in IPv6 from 9K packets (vs > 1500 byte packets) only to discover that certain router vendors had > interpreted one of the RFCs to mean they didn't have to send > packet-too-big messages if the packet in question was larger then 1500 > bytes (because one of the RFCs stated that IPv6 implementations only > have to support 1500 bytes). Yes, the RFCs could be interpreted that > way, but that interpretation clearly violates the intent (to make path > MTU reliable). The real world upshot of that is that anything over > 1500 bytes is still a black hole and using path MTU can really only > get you a whopping 300 bytes (from 1200 to 1500). > > Should we consider clarifying the IPv6 specs to state that routers and > end-user nodes will send ICMP packet-too-big responses when receiving a > too-big packet *OF ANY SIZE* which they can't forward onto the next > interface due to an MTU limit? (Or which the end node can't process > due to a limit in its NIC or elsewhere in its implementation.) > > If so, Intarea could take a tiny step toward nodes being able to > eventually detect and use existing 9000 byte jumbo frame support by > default. Having working auto-detection of 9000 byte frames would also > encourage future hardware to increase frame sizes further, knowing that > existing software will automatically use them where possible. > > John > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
