Subject: Operational feedback on PMTUD

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Mar 2017 19:56:46 +0900

Hi all;

Just a procedural question.

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?

It seems to me that rfc1981 operationally failed and rfc4821 was
developed, which means PMTUD can be IS only when rfc4821 become IS.

Or, do I misunderstand something?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 18 Mar 2017 21:03:11 +0900

>    protocol or service provides significant benefit to the Internet

But, no response yet.

> It seems to me that rfc1981 operationally failed

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

as a proof accepted by operational community that rfc1981 style
PMTUD has been, is and will continue to be failing.

							Masataka Ohta

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 20 Mar 2017 03:22:39 +0000

Hi Ohta-san,
  Thanks for your comment.

> On Mar 18, 2017, at 8:03 AM, Masataka Ohta <[email-masked]> wrote:
> 
> I wrote:
> 

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.

> PMTUD has been, is and will continue to be failing.

I went through the presentation (very interesting) and it looks like you are talking about multicast PMTUD. Your point about ICMP filtering breaking PMTUD is valid has been raised many times during the last call. It has not really been *quantified* though (i.e. how much ICMPv6 filtering is there on the Internet). One piece of work (from 2012) that I am aware of

http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf <http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf>

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

Thanks
Suresh

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 20 Mar 2017 14:50:29 +0900

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.

> 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