Re: Non-Last Small IPv6 Fragments

[Fernando Gont <[e-mail]>]

On 14/1/19 17:40, Erik Kline wrote:
>
>> 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.

In that case, we should be removing EHs in the fragmentable part (not
that it would be a a big deal.. just pointing it out).



>>> 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.

Agreed.



>>
>> 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).

Certainly what you describe is better than what we have -- still, I'd
say not good enough for fragments to survive (e.g. cases where they need
to be reassembled at high speed) -- and there's still the fundamental
problem of processing EHs.


> 
> [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]

You mean as a kind of PMTUD?



> [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

I assume this is for PMTUD, too. This option would be way better than
the preovious one (node will just not process EHs), but...give the path
that we have followed for FL standrdization, it wouldn't be useful for
anything else other than random bits. One might hack some other fields
e.g... special value for Payload length, but.. that would certainly look
ugly.

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492