Re: Non-Last Small IPv6 Fragments

[Erik Kline <[e-mail]>]

Clearly I'm way behind in my document reading!!

I'd just add that it seems reasonable to see about broader Internet
usage at some point.

On Mon, 14 Jan 2019 at 13:34, Ole Troan <[e-mail]> wrote:
>
>
>
> On 14 Jan 2019, at 21:40, Erik Kline <[e-mail]> wrote:
>
> 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.)
>
>
> https://tools.ietf.org/html/draft-hinden-6man-mtu-option-00
>
>
>
> [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.