Re: Path MTU Hop-by-Hop Option

[Fernando Gont <[e-mail]>]

On 10/24/18 3:57 AM, Tom Herbert wrote:
> On Tue, Oct 23, 2018 at 11:03 AM, Fernando Gont <[e-mail]> wrote:
>> On 10/17/18 6:49 AM, Carsten Bormann wrote:
>>> On Oct 17, 2018, at 00:55, Bob Hinden <[e-mail]> wrote:
>>>>
>>>> This document specifies a new Hop-by-Hop IPv6 option that is used to
>>>>   record the minimum Path MTU
>>>
>>> A while ago I proposed something similar to collect information about adaptation layer fragmentation MTUs (information about which is truly not available in any other way):
>>>
>>> https://tools.ietf.org/html/draft-bormann-intarea-alfi-04
>>>
>>> (I also only looked at the Internet layer here — leaving it as an exercise to put in transport/application protocol support.)
>>>
>>> After mulling an initial version of the proposal, there was pretty much consensus that hop-by-hop options were not really available on the Internet.  So I put in an alternative way to collect the information, see above if you are interested.  Then at some point SPUD came along and I was hoping that would lead to a framework within in which this information could be better handled.
>>>
>>> Maybe it’s time to pull the old draft out again.  The hop-by-hop option problem of course hasn’t gone away.
>>
>> IPv6 EHs are not readily available on the public IPv6 Internet. See
>> RFC7872. While not included in RFC7872, my measurements indicate that
>> the same applies even to IPsec EHs. :(
> 
> Fernando,
> 
> If I'm reading RFC7872 correctly, it is more accurate to say that the
> drop rates for EH vary between 12% and 55% depending on type and
> destination. We cannot say that EH always works on the Internet, but
> neither is it correct to say that EH never works on the Internet.
> Success rate is somewhere in between.

Can you depend on something that fails in 10% (or more) of cases?



> While the data in RFC7872 is objective, the conclusions being drawn
> are not. I think there are two possible conclusions 1) Success rate of
> EH is abysmal, EH is a failure and should be deprecated, and the
> would-be contents of EH need to be moved to other layers somehow

Tags aside, the reality is that if you need the the would-be contents to
be reliable, you'd put them else where. Not that I like it... but
whatever my personal taste is, it doesn't solve problems by itself.

(see what happened to ip options... the ipv6 eh case is worse).



> 2) EH
> support is less than desirable, but this is a current condition that
> may be improve over time with new deployments, protocol
> clarifications, definition of some "useful" options. 

Yes, it could improve. One never knows. Me, my gut feeling is that's
unlikely.


> IMO, until EH is
> officially deprecated, it is entirely appropriate to define new uses
> such as the Path MTU Option here.

No matter how EHs are flagged, we're doing engineering. It works, or it
doesn't. (as unfortunate as that may be).

To me, it all looks like they are reliable in controlled domains (within
your network, where you control everything), but not elsewhere (public
Internet)

> Since we know up front that the
> option might not always be viable on the Internet, the mechanism will
> need a fallback;

If the fall-back "just works" why not keep it simple?


> but the need for a fallback is hardly unique: IPv6
> falls back  IPv4 via happy eyeballs, UDP falls back to TCP when
> firewalls block UDP, etc.

I'd compare such a fall-back with e.g. retrying TCP connections without
the ECN bits set. When doing the fall-back, you lose the benefits of
ECN. - but I would expect that in most EH cases, loosig the
functionality is not a viable option. e.g., what would the fall-back be
for IPsec packets that get blackholed?   (I tel you *my* workaround: I
tunel over TLS over a transport protocol.. don't even bother to try to
do IPsec in the general case)

Just to make my point clear:not that I like the situation. BUt
pretending it doesn't exist doesn't make it go away.

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