Re: Operational feedback on PMTUD

[Masataka Ohta <[e-mail]>]

Suresh Krishnan wrote:

>>> Though rfc2026 says:
>>>
>>> A specification for which significant implementation and
>>> successful operational experience has been obtained may be
>>> elevated to the Internet Standard level.  An Internet Standard
>>> (which may simply be referred to as a Standard) is characterized
>>> by a high degree of technical maturity and by a generally held
>>> belief that the specified protocol or service provides
>>> significant benefit to the Internet community.
>>>
>>> does rfc1981bis qualify?

> In all fairness, your message was received two weeks after the end of
> a four week IETF last call (March 1). The editor and the shepherd are
> busy going through the responses received during the last call period
> trying to converge on text change proposals.

So, I can judge that text changes won't resolve operational failures.

Note that I'm not proposing any text change.

Though I now recognize text of rfc1981bis is wrong (ICMPv6-based
PMTUD works even if ICMPv6 packets are sometimes lost, because of
retransmissions by upper layer connection) and rfc1981bis PMTUD
fails with some upper layer connection (e.g. some IoT device
may use connection with retransmission intervals of 20 minutes),
that is not my point on this thread.

But, it should be noted that such failures could be found
with extensive operational experiences on paketization
layer PMTUD, which is one of a reason why PMTUD can be
IS only after packetization layer PMTUD gains much
operational experience and becomes IS.

>> For example, see my presentation at APNIC32
>>
>> How Path MTU Discovery Doesn't work
>> https://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf

> I went through the presentation (very interesting) and it looks like
> you are talking about multicast PMTUD.

No, as I wrote on page 12:

    Or, as it is already a violation, simply
    – stop generating any ICMP
    – filter all the ICMP
    – “it’s against an RFC” is not a valid criticism

unicast PMTUD is also proven to fail.

Note that destination address of an IPv6 packet in an ICMPv6 PTB
is more than 64B away from the beginning of the IMCPv6 PTB packet
but some network processor can filter packets based only on the
first 64B of a packet, which is why:

    Or, as it is already a violation, simply
    – filter all the ICMP

will be a likely case.

 > Your point about ICMP
> filtering breaking PMTUD is valid has been raised many times during
> the last call.

Yes, for example, on 2017/02/02 9:37 (GMT), Eggert, Lars wrote:

    Given that ICMP delivery cannot be assured over the vast majority
    of paths in the current Internet, should this document make a
    recommendation to implement RFC4821?

so, at least he thinks:

    ICMP delivery cannot be assured over the vast majority
    of paths in the current Internet

 > It has not really been *quantified* though (i.e. how
> much ICMPv6 filtering is there on the Internet).

Do you really think so? Then, that's enough to stop the
draft become IS.

Onus of proof is on those who want to make something IS.

 > One piece of work
> (from 2012) that I am aware of
 >
 > 
http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

I'm afraid it is too old. After 2012, those who are not enthusiastic
to deploy IPv6 start deploying it, which means they don't mind
filtering ICMP PTB so much.

Moreover,

>  did a fairly large scale study using RIPE Atlas probes (~1000
> vantage points for IPv4 and ~400 vantage points for IPv6) that showed
> that ICMPv4 was filtered for between 4-6% of the paths while ICMPv6
> was filtered for only 0.77-1.07% of the paths.

0.77~1.07% among ~400 points means 4 or 5 points, too small number
of samples to make statistic variation negligibly small.

> I would like to know
> if there is any more recent measurement information that indicates
> ICMPv6 is not workable on the Internet. That would certainly help me
> judge whether 1981bis will qualify or not in the “successful
> operational experience”.

The more important point of rfc2026 is:

    the specified protocol or service provides
    significant benefit to the Internet community.

and 1% failure possibility is bad enough.

							Masataka Ohta