Re: Meta-issues: On the deprecation of the fragmentation function

["C. M. Heard" <[e-mail]>]

On Fri, 28 Jun 2013, Fernando Gont wrote:
Fernando> I wanted to comment on some met-issues regarding the deprecation of the
Fernando> IPv6 fragmentation function.
Fernando> 
Fernando> ** On the motivation of deprecating the fragmentation function **
Fernando> 
Fernando> So far (and without having read Ron's recent I-D -- shame on me), it
Fernando> looks like the main two reasons for deprecating the fragmentation
Fernando> function are:
Fernando> 
Fernando> 1) The inability of middle-boxes to parse past the first XXX bytes of a
Fernando> packet
Fernando> 
Fernando> 2) Unavailability of the connection-id (five-tuple) in the non-first
Fernando> fragments.

I disagree -- I think Mark Andrews got it (mostly) right in his message of Wed, 26 Jun 2013:

Mark> One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment.

The flow label, if properly set at or near the source, could plausibly address "2)" -- see 
https://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/?include_text=1

However, it won't help middle boxes that implement stateless packet filters.  Indeed, such 
boxes have fundamental problems with non-first fragments irrespective of how many bytes of 
extension headers they can parse or whether there are sufficient length limits on the extension 
header chain that guarantee that the L4 header always appears in the first fragment.

As I see it, the biggest meta-issue in this discussionis for the IPv6 WG is to decide out whether 
middle boxes that implement stateless packet filters with a "default-deny" policy will be a 
significant part of the landscape indefinitely, regardless of what the IETF says about their 
merits or lack thereof.  If so, fragmented IP datagrams will continue be problematic in the general 
case; and since the job of this (or any other) IETF WG is to make the internet work better, it will 
be incumbent on the WG to deal with the issue.  Ron Bonica and co-authors have made one proposal to 
do just that.

Thinking aloud ...

If we decide that the only path forward is to deprecate IPv6 fragmentation and reassambly (presumably 
not IPv4, since it's at end of life), the next question I see is what can or should be done to allow 
UDP and kin to send large datagrams.  A UDP replacement with fragmentation and reassembly built in to 
the transport layer is one possibility.  The questions that come to mind are (a) is this capability 
actually needed, and if so, (b) can it be incrementally deployed, in the face of middle boxes with 
"default deny" policies causing them to discard protocols that they don't know?

//cmh