Re: Path MTU Hop-by-Hop Option

[Tom Herbert <[e-mail]>]

On Wed, Oct 24, 2018 at 3:00 PM, Fernando Gont <[e-mail]> wrote:
> Hello, Tom,
>
> On 10/24/18 5:45 PM, Tom Herbert wrote:
>> On Tue, Oct 23, 2018 at 8:14 PM, Fernando Gont <[e-mail]> wrote:
>>> 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?
>>>
>> Well, aren't we also trying to depend on IPv6 itself which still has a
>> pretty high failure rate on the Internet?
>
> I haven't measured IPv6 failure rate, I should say.
>
>
>
>> If we're restricted to only
>> use protocols that we can absolutely depend on to work then the only
>> choice is to use plain TCP over plain IPv4.
>
> I guess that there are things that are likely to be workable, and others
> that aren't. The structure of EHs doesn't seem to be friendly wth modern
> router architectures
> (https://iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf), so
> there's not much of an indication that things will move in a different
> direction.

I believe the emergence of programmable devices, like those with P4,
change that. RFC8200 also allows devices to skip over HBH, this should
be trivial code in P4.

>
>
>
>> Also, I think "depend" is an interesting word in this context. By
>> definition the Path MTU option is an *option*, it cannot be required
>> for basic communications. No one can depend on it.
>
> Either you have a reliable PMTUD, or you prepare to send1280-byte
> packets (or smaller). So in such case the algorithm should be "the MTU
> is 1280. Upon receipt of a PTMU option, rase it to, at most, the MTU of
> your outgoing interface". Otherwise traffic can get blackholed and you
> get a DoS.
>
>
>>>
>>>> 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.
>>>
>> The problem there is that no one has yet to define the alternative
>> that would work any better.
>
> Currently (SR aside), you need EHs from fragmentation and IPsec. For
> fragmentation, it remains to be researched how things are working out
> (maybe fall back to v4 for the DNS,.. but I don't know). For IPsec...
> well, you probably avoid native IPsec traffic as you did for v4, anyway.
>
> Put another way, looks like nobody   looked for an alternative because
> nobody "needed" it.

There also been a number of proposals to get OAM data into the packet.
Suggestions have included stealing bits from flow label, diffserv
bits, or putting them in TCP. None of these have been shown to be
viable. And of course there was SPUD proposal, which in the end would
have more issues than getting EH to work.

>
>
>
>>>> 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).
>>>
>> I disagree that it has to be a global binary choice. Happy eyeballs
>> has shown how to deal with a protocol that has greater than zero, but
>> less than 100% support.
>
> It's a different thing. Happy eyeballs essentially deal with multiple
> choices where all of them are equivalent. You just need one to work.
> Happy Eyeballs wouldn't work if you tried to use it when acecss stes
> behind a firewall that filters port 80 and 443.
>
> If, say, IPsec fails, you can't just "disable ipsec". or "well, lets try
> a TLS tunnel".
>
>
>
>
>>> To me, it all looks like they are reliable in controlled domains (within
>>> your network, where you control everything), but not elsewhere (public
>>> Internet)
>>>
>> That's not clear at all. For a small domain this might be plausible,
>> but for large sprawling domains like the big DC operators that use
>> multiple vendors it may or may not be true. Besides that, if the plan
>> is to only use features like EH in a controlled domain, then we need
>> to have an implementation at host to determine whether the destination
>> is in the controlled domain-- that is not necessarily easy to do. A
>> common solution should consider whether the feature is viable to each
>> particular destination.
>
> So, just as a sample scenario: how ould you workaround non-working IPse
> (due to filtering of IPsec EHs?)

I'd probably tunnel it over UDP (GUE to be precise). If UDP doesn't
work because it's blocked by a firewall, then I'd tunnel over TCP (GTE
described in https://tools.ietf.org/html/draft-herbert-tsvwg-gte-00).

Tom

>
>
>>
>>>> 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?
>>>
>> Because fallback means we don't get the advantages of the feature.
>
> That means that the possible outcome, for the pmtu option , is that you
> end up using 1280 instead of some larger PMTU.  (The pmtu option is
> subject to blackholes... hence the fall back needs to be the minimum
> IPv6 MTU, or PLPMTUD).
>
>
>
>>>> 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)
>>>
>> I think IPsec is an extreme. For other use cases of EH, particularly
>> DO and HBH, like Path MTU option, OAM, FAST the fallback is not to use
>> the option. Communication can proceed but advantages is lost possibly
>> resulting in a degraded mode of service relative to using the option.
>
> For some of these cases, I'd agree. But for PMTUD, it's tricky (see above).
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>