Subject: Feedback on draft-hinden-6man-mtu-option

From: Fernando Gont <[email-masked]>
Date: Sun, 17 Mar 2019 15:40:56 -0300

Folks,

I happened to read the aforementioned document. These are my comments:

I read the doc, but cannot the benefit of pursuing this. For at least
the following reasons:

1) This, at least at the begining, is going to be less reliable than
PMTUD. Since you cannot rely on this, you have to have a fall-back
mechanism... and that gets us where we started.

2) In the general case, Hop-by-Hop options are dropped even more that
ICMPv6 PTB (see RFC7872). For "controlled environments... why don't you
just make RFC8201 work by not droping ICMPv6 PTB?

Put another way: if you ahve the "power" to make this work, you also
have the power to make RFC8201 work. RFC8201 is already widely
implemented.. and has a fall-back mechanism (RFC4821, which can be used
along RFC8201 for recovering from blackholes).

3) Unless there's chain of links with monotonically-drecreasing from the
pov of the sender, RFC8201 is most likely going to work faster, too.

4) For scenarios where you can make IPv6 EHs work (I would assume
limited domains), why not just build the network with large-MTU
technologies?

5) If I read the document correctly, the reason for which you propose
this alternative is because RFC8201 does not work, because e.g. ICMPv6
PTB are dropped. BUt then you use ICMPv6 PTB for the remote end to
signal the MTU value back to the sending node.This will have *more*
problems than RFC8201: now you need to get both ICMPv6 and IPv6 EHs to work.

6) For the security considerations, you may want to take a look at RFC5927.

Thanks!

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

---

From: Tom Herbert <[email-masked]>
Date: Sun, 17 Mar 2019 13:30:23 -0700

> along RFC8201 for recovering from blackholes).
Hi Fernando,

If EHs aren't working on some path then the obvious fallback is to not
use them on that path.

> limited domains), why not just build the network with large-MTU
Because precisely configuring MTUs in large scale networks crossing
continents and use different technologies isn't always easy or
desirable. It's the same reason we can't obsolete fragmentation.
Besides that, the MTU option is just one use case of EH, there are
others in development (IOAM, FAST, SR, etc.).

> problems than RFC8201: now you need to get both ICMPv6 and IPv6 EHs to work.
There is a suggestion to use EH in the reverse path to return the
information instead of ICMP to facilitate delivery.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 18 Mar 2019 09:04:11 +0000

Hi Fernando,

Thanks for looking at this and I think we can clarify why we have 
written this, see below.

On 17/03/2019, 20:30, Tom Herbert wrote:
> On Sun, Mar 17, 2019 at 11:51 AM Fernando Gont<[email-masked]>  wrote:
>> Folks,
>>
I'm not sure I agree.  We'd be interested in understanding whether a 
ICMP PTB from the destination node has a greater chance of reception 
than one from a router on the forward path.There are many, many, reasons 
why an ICMP PTB message may be lost. One of them, is when the router on 
the forward path has no route to the sender - for instance behind a load 
balancer.
>> implemented. and has a fall-back mechanism (RFC4821, which can be used
We know this - and we're sad about the state of support, so indeed we'll 
provide fallback,  where this is need.
>> 3) Unless there's chain of links with monotonically-decreasing from the
Perhaps, marginally if one chose the probe size correct (you didn't need 
to traverse the full path). But, if jumboframes
start to be used, then we can expect cases where the edges have 
different sizes of MTU, and then this method wins. It depends on where 
the bottlenecks are.
> others in development (IOAM, FAST, SR, etc.).
I agree with Tom Herbert here. Many transit networks have jumboframes 
enabled, many edge and overlay networks use tunnesl/encapuslation. It's 
not feasible to tell everyone to make a network provide the same PMTU - 
and if we did
try we'd still need to catch accidental changes from configuration issues.
> information instead of ICMP to facilitate delivery.
Fenando, I think we will need measurements to know what works in 
reality. As Tom Herbert notes
we could also provide other ways to offer feedback - even using a field 
inside the transport protocol itself.
>> 6) For the security considerations, you may want to take a look at RFC5927.
Yes, I looked at that, and we'll take off-path attacks seriously when we 
experiment with protocol mechanisms around this.
>> Cheers,
Gorry

---

From: Fernando Gont <[email-masked]>
Date: Mon, 18 Mar 2019 01:55:24 -0300

> If EHs aren't working on some path then the obvious fallback is to not

Since you don't know the paths, then it boils down to mechanisms relying
on EHs being unreliable.

You should have something that you can use when EHs don't work. And if
you have such a thing, why bother with EHs in the first place?

> desirable. It's the same reason we can't obsolete fragmentation.

The reason for which we cannot obsolete fragmentation is because we
still have protocols wishing it worked.

> information instead of ICMP to facilitate delivery.

EHs are unrealiable... just as ICMPv6 PTBs

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Mar 2019 11:27:49 -0700

> you have such a thing, why bother with EHs in the first place?
Fernando,

It's falling back to a rudimentary mode for which we get degraded
service. It is no different than when we fallback to using IPv4 when
IPv6 doesn't work, or when we fallback to using TCP when QUIC doesn't
work.

> still have protocols wishing it worked.
It can't be obsoleted because it's still in deployment. I see no
reason to tell someone who's been happily using it for years that they
need to now stop.

> EHs are unrealiable... just as ICMPv6 PTBs

So is SCTP, so is UDP, so is IPv6 for that matter. There's a lot of
things that are "unreliable" on the Internet.

EH is the means to extend the IP protocol. HBH options are the _only_
means outside of the IP header for hosts to signal the network or to
get information from the network inline with the data path. The reason
EHs are considered unrealiable on the Internet is because of some
non-conformant devices. IMO, it's better work around or fix the
non-conformant implementations, as opposed to abandoning the mechanism
and hence surrendering a major avenue for innovation.

Tom