IPv6 Fragment Retransmission

["Templin (US), Fred L" <[e-mail]>]

Hi, there were many questions and concerns on the chat during my talk at today's
6man session and I think most/all can be directly addressed.

First and foremost - it is a truth that some applications will see greater performance
by sending IP packets larger than the path MTU while invoking IP fragmentation and
reassembly. This has been known since 1986 when Sun Microsystems came out with
their Network File System (NFS) and delivered their code to the DEC Ultrix team where
I was working at the time. This would have been with IPv4, but iperf3 clearly shows
that the same truth holds for IPv6 today.

The Sun/Solaris workstations were well equipped to handle the performance, but
the DEC VAXstations of the time had inadequate network gear and fragment bursts
under the largest NFS/UDP/IP packet size caused the NIC to crash. This was a big
deal; people took note of it and made darned sure to design their future networking
gear to handle fragmentation and reassembly at high data rates. And, what we have
today is a very capable set of devices that would be asked to engage in fragmentation
and reassembly.

That said, fragmentation and reassembly does not belong everywhere - you might
not want it on a high-speed core router or on a low end IoT device. But, by locating
the fragmentation and reassembly functions on key nodes in the network everything
gets more efficient and sees improved performance. I will offer that AERO/OMNI
give full discussion of the role of IP fragmentation/reassembly in a truly advanced
networking solution and I would recommend folks to have a look.

Many of the comments on chat got down in the weeds about security, and they can
be addressed very simply. First and foremost, a node should only accept a fragment
if it has some way of verifying  data origin - but, even that is not 100% necessary
if the reassembly cache is instrumented to quickly flush bogus reassemblies rather
than hold onto all fragments for a full MSL. And, modern reassembly implementations
are designed to do exactly that.

So the whole purpose of data origin authentication is really just to keep garbage out
of the reassembly cache to keep things working smoothly. Again, you can read about
all this in AERO/OMNI but this draft is intended for general IPv6 operations and not
just for AERO/OMNI. So, the next draft version will have a brief and crisp security
considerations section.

I would like to now invite a discussion of any other comments/questions/concerns
anyone might have here on the list. The draft can be found here:

https://datatracker.ietf.org/doc/draft-templin-6man-fragrep/

Thanks - Fred