Re: Non-Last Small IPv6 Fragments

[Warren Kumari <[e-mail]>]

On Mon, Jan 14, 2019 at 5:19 PM Fernando Gont <[e-mail]> wrote:

> 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
>
>
https://media.giphy.com/media/3o6ZthnDqxfAOFIhdC/giphy.gif
Because there are deployed systems already, I don't think that this can be
deployed **and fully relied upon**, but I do think that it might actually
be really useful. If the first 2 bits of the flow label are '11' or '10' or
something, then it could mean that the next N (13?) bits of the flow label
contain the minimum MTU along the path. It doesn't matter that it cannot be
relied upon, because it could simply be used as a hint to the path MTU
discovery (I tried to figure out where in RFC8201 if could be tied).
Basically, if the N bits are less than 1280, ignore them. If they are
larger than the host MTU, ignore them. If they fall between 1280 and
$host_mtu, guess that they might be valid and prime the path MTU discovery
process with this hint.
Initially devices along the path will a: not touch the flow ID or b:
scribble all over it like they currently do. Over time, new devices could
be updated to do this, and the signal would slowly become more useable.

It *does* mean that we would be removing (by convention) some of the
possible entropy in the flow ID which might make ECMP harder, and may also
discourage some of the other "lets scribble marking X into this field"
ideas, but that might be a feature, not a bug.

I cannot tell if I've just taken a sharp turn into crazy town, or if this
really is a good idea (and I haven't thought about it in depth - this is
all a knee jerk reaction to something sufficiently hacky that it entertains
me...)



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


What if you view it as an (initially) noisy hint, becoming more believable
over time? As far as I can tell, an on-path attacker could degrade service
by artificially signalling a lower MTU than really exists, but an onpath
attacker could already do this (and much worse!).
W



>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf