Re: Non-Last Small IPv6 Fragments

[Erik Kline <[e-mail]>]

On Sun, 13 Jan 2019 at 22:24, Fernando Gont <[e-mail]> wrote:
>
> Hi, Erik,
>
> On 14/1/19 02:19, Erik Kline wrote:
> >
> >     > Ole Troan wrote on 13/01/2019 20:03:
> >     >> Let’s fix path MTU discovery. There’s no fix for fragmentation.
> >     >
> >     > pmtu discovery is hard because it needs a way for an intermediate
> >     node to be able to signal a transmitting node to dynamically drop
> >     the MTU if network conditions change.  The only way to reliably work
> >     around this is to transmit at 1280 and claim implementation /
> >     operational breakage if this cannot get through.  This, however,
> >     robs the host devices of the ability to use higher MTUs.
> >
> >     “Fix” as in something different than rfc8201.
> >
> >
> > How about a version of the fragment header that:
> >
> >     (a) *always* has the L4 header (or a configurable number of bytes)
> > in every non-first fragment
> >
> > This could be documented on a per-L4+ basis how much needs to be
> > included, i.e. we could have one doc for UDP and (say) a separate doc
> > for information QUIC would need on a per-fragment basis.
>
> If you are requiring that the first frag always contains the L4 ehader,
> that's already achieved by RFC7112.

Not what I suggested.  I said every fragment header would include the
L4 header (or other specifiable bytes).

> If you really mean that the FH contains the L4 header, then:
>
> * There's the issue of EHs in the fragmentable part

That would be addressed in an associated L4 doc, and it would probably
say to ignore non-transport headers.

> * It may be hard to enforce in the presence of tunnels, unless the
> tunnel reassembles and refragments where necesary
>
>
> Still, that doesn't solve the biggest issues with fragmention:
>
> * a stateful operation for anotherwise stateless protocol
>
> * i'd argue that for the IPv6 case, one of the base reasons for which
> fragments are dropped is because they employ EHs
>
>
>
> > This increases the overhead in a given fragment, but also helps to
> > ensure that (eventually) intermediate systems can examine this field and
> > preemptively make a drop/no-drop decision.
>
> Then we're back on draft-gont-v6ops-ipv6-ehs-packet-drops

Understood, but any L3 solution is going to necessitate running into
this.  UDP trailers is certainly cute (and +1 from me), but every
transport will have to have some similar fix (or applications will
have to consider rfc8085#section-3.2 type guidelines).  If there's to
be an L3 solution to this L3 problem it will face some deployment
issues but if its usefulness is sufficiently attractive it could find
reasonably wide-spread support in due time (in the absence of ipng-ng,
IPv6 is it for the long haul).

[Silly Idea #1]

(/me thinks back to spud bof)

Here's another random suggestion that maybe belongs in panrg or (more
likely) the dumpster:

A new hop-by-hop header under "00 1", i.e.

    00 - skip over this option and continue processing the header

    1 - Option Data may change en route

of the form, for example, Option Type 00 1 00001, Opt Data Len 2,
Option Data == MTU.  Here, the observation is that the main thing we
have experience with "working" (for the most generous definition of
"works") in this problemspace in the internet today is TCP MSS
Clamping.  So let's have an MTU (or MSS) HbH option that can be
revised monotonically downwards but never lower than 1280.  If it
helps pad to 8 byte alignment we can have a 2nd 2-byte field that is
untouched representing the sender's original MTU/MSS.

In this way, a sender could include an HbH with either:

    [HbH | 0 | 0x0202 | 2 | (1500=0x5dc) | Pad1 | Pad1]

or

    [HbH | 0 | 0x0202 | 4 | (1500=0x5dc) | (1500=0x5dc) ]

with one of the MTU/MSS fields to be munged along the path.

If this were the only HbH option included it adds only 8 bytes, fits
(along with most L4 headers) within a 128 byte hardware classifier,
and end systems could explore its usefulness via ping.  (Separately,
there could of course be sockopt/cmsg things to set/get the values.)

[Silly Idea #2]
Separate, even sillier idea: everyone converges on using 16 bits of
the flow ID to encode the lowest MTU encountered along the path.  Here
again, TCP MSS clamping style behaviour would be applied to this
field.