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