Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

On Sun, Jan 13, 2019 at 10:25 PM 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.
>
> If you really mean that the FH contains the L4 header, then:
>
> * There's the issue of EHs in the fragmentable part
>
> * 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
>
Fernando,

There is no fundamental problem with fragmentation. The core problem
is that some intermediate nodes are processing headers and data beyond
the IP and Hop-by-Hop options header. That is non-conformant with
RFC8200: "Extension headers (except for the Hop-by-Hop Options header)
are not processed, inserted, or deleted by any node along a packet's
delivery path". This becomes a material interoperability problem when
intermediate nodes take invasive action, such as dropping packets or
degrading the service, when they encounter protocols they don't
understand. This problem applies not only to fragmentation, but also
other extension headers, non-TCP transport protocols, and other
protocols outside some narrow set of typically used protocols. To fix
this, either non-conformant implementations should be changed to
conform to the standard, or the standard should be changed to conform
to the implementation.

Tom


> * 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
>
>
>
> >     (b) state clearly that every non-last packet must contain
> > $CONSENSUS_MINIMUM_BYTES of actual fragment payload
>
> In which cases do you expect this to make a substantial difference?
>
> Thanks,
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------