Re: Non-Last Small IPv6 Fragments

[Fernando Gont <[e-mail]>]

On 15/1/19 21:31, Warren Kumari wrote:

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

Next question is: This of course implies that, since using this would
make the FL take a few deterministic values, it cannot be used for e.g.
ECMP. Hence processing the EH chain becomes a requirement (well, in
practice it already is).



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

Depends on whether you want the FL to work as a FL, and for it to be
useable for hashing input when doing ECMP.


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

Somewhere I got lost in this discussion:

RFC1981 doesn't reliably work due to ICMP filtering
RFC4821 has long convergence time

[then we come up with this discussion]

It would seem to be the easier and best way to go is to do RFC4821 for
blackhole detection, while still processing ICMP messages (in fact,
that's one of the possible approaches in RFC4821)

Put another way: how would anything else makes since better, and become
more feasible?


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