Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

From: "C. M. Heard" <[email-masked]>
Date: Sat, 11 Feb 2017 10:05:14 -0800

On Fri, Feb 10, 2017 at 10:42 PM, Suresh Krishnan <[email-masked]
> wrote:

> On Feb 10, 2017 11:30 PM, "C. M. Heard" <[email-masked]> wrote:
>
> On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> > On 10/02/2017 23:20, Stewart Bryant wrote:
> > > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > > I wonder if we would best serve both our future and our heritage
> > > > > if we declared RFC1981 as historic, and either left the idea there,
> > > > > or declared it as historic and wrote a new text from a clean start?
> > > >
> > > > I don't see that. It's a stable, widely deployed, interoperable
> > > > mechanism. That is rather orthogonal to the issue that has been
> raised,
> > > > which is that faulty ICMPv6 filtering blocks it on many, many paths
> > > > across the Internet.
> > >
> > > I will not debate whether it is faulty or not,
> >
> > It's faulty by the standard of RFC4890 (which is Informational).
> >
> > > but it seems that in practice the Internet breaks the mechanism.
> > > However it breaks it is a way that seems disruptive to some user
> > > traffic. The document is really guidance one how hosts might use
> > > ICMP for optimization, and arguabl[y] need not be a standard at all.
> >
> > I think that's a mischaracterisation of the mechanism (and the draft).
> > PMTUD is not an optimisation. Without it, you get black holes.
>
> Actually, no. You do not have to use PMTUD to avoid black holes.
> Other options include:
>
> - Send packets no larger than 1280 bytes (this is always an option)
> - Use PLPMTUD (for transports that do their own packetization and
>   that can detect packet loss)
>
>
> How does this work for UDP?
>

Sending packets no larger than 1280 bytes is always an option, and in
the case of UDP-based request-response protocols such as DNS that do
not have connection state, it may be the only feasible option.

Anyway, the point I was trying to make was not to argue about better
or worse methods but rather to dispute the statement that PMTUD is
essential for avoiding black holes. I don't believe that it is. The
draft itself explicitly says that "IPv6 nodes are not required to
implement Path MTU Discovery."

> > My remark about heritage is that this vintage draft is very much a
> > > product of its time, and really needs modernizing, and after
> > > modernizing ought to look quite different, and thus maybe we
> > > should employ a procedure other than a simple replacement.
>
> I am afraid that I have to agree with this. Classic PMTUD by itself
> is today not enough, but it can be a very useful optimization to
> augment other techniques.
>
>
> OK.
>
>
> > It's proposed for Internet Standard. That means it must replace the
> > PS document and must specify the same thing, plus corrections,
> > minus unused features.
>
> All true, and my conclusion is that is it should not be promoted to IS.
>
>
> What criteria for advancement to IS do you think are not met by this
> document?
>

I do not dispute that the document has met the formal criteria for IS in
Section
2.2 of RFC 6410. I would argue, however, that its failure to provide a
complete
solution for environments where delivery of ICMP messages is not assured
constitutes a significant technical omission for today's Internet, and I
note
that per RFC 2026 Section 4.1.1, even a PS "should have no known technical
omissions." What I am asking the community, and the IESG, is whether it is
wise to advance a document with known technical omissions; it seems to me
that the Gen-ART reviewer has raised much the same question.

I would have no problem with republishing at PS to correct the errata
> and aid the eventual advance of RFC 4821 (PLPMTUD).
>
> If this document does go forward, the words in Appendix B (Changes
> Since RFC 1981) relating to RFC 4821 should be removed, since
> there was no mention of RFC 4821 in RFC 1981.
>
>
> Not sure I understand your concern. This is a change log since RFC1981.
>
And it is a fact that the reference to RFC4821 was added into this draft.
Can you clarify?

My apologies, I wrote that too hastily, before reading the complete change
log, which contains a description of what changed in each draft as the
document proceeded through the WG process. The comment that I should
have made is that many of those details are not useful to readers of an
archival document. Looking at a diff between RFC 1981 and this draft,
the substantive changes pretty much boil down to these:

      - In Section 1, added a reference to RFC4821 along with a short
        summary of what it does.

      - In Section 4, added text to discard an ICMP Packet Too Big message
        containing an MTU less than the IPv6 minimum link MTU and removed
        the corresponding note specifying actions that were removed from
        [I-D.ietf-6man-rfc2460bis].

      - In Section 5.2, removed text regarding RH0 (since it was deprecated
        by RFC5095) and removed text about obsolete security
classifications.

      - In Section 5.2, clarified that the tentative PMTU must not be made
        smaller that the IPv6 minimum link MTU.

Regarding that last change, I got confused when I was reading the current
text
in the draft:

   The node then uses the value in the MTU field in the Packet Too Big
   message as a tentative PMTU value or the minimum IPv6 next hope MTU
   if that is larger, and compares the tentative PMTU to the existing
   PMTU.  If the tentative PMTU is less than the existing PMTU estimate,
   the tentative PMTU replaces the existing PMTU as the PMTU value for
   the path.

I initially took the words "minimum IPv6 next hope [sic] MTU" to mean the
next
hop MTU of any link on the node, which of course is not what it meant. Maybe
I'm being dense, but it wasn't until I looked at Donald Eastlake's INT-DIR
review (https://www.ietf.org/mail-archive/web/int-dir/current/msg00339.html)
that the correct meaning finally dawned on me. May I suggest saying
 instead:

   The node then uses the value in the MTU field in the Packet Too Big
   message as a tentative PMTU value or the IPv6 minimum link MTU if
   that is larger, and compares the tentative PMTU to the existing
   PMTU.  If the tentative PMTU is less than the existing PMTU estimate,
   the tentative PMTU replaces the existing PMTU as the PMTU value for
   the path.

In other words, s/minimum IPv6 next hope MTU/IPv6 minimum link MTU/.
That makes the terminology consistent with the rest of the document.

Thanks and regards,

Mike Heard

---

From: [email-masked]
Date: Sat, 11 Feb 2017 23:59:20 +0100

> not have connection state, it may be the only feasible option.

Yes, but DNS tend to use IP fragmentation that suffers an order of magnitude worse fate than ICMP messages. ;-)

> implement Path MTU Discovery."

That's correct. But it then must restrict itself to sending packets at the minimum MTU size.
You cannot implement RFC2473 (IP in IP) without PMTUD for example.

[...]

> What criteria for advancement to IS do you think are not met by this document?
> 
> I do not dispute that the document has met the formal criteria for IS in Section
> 2.2 of RFC 6410. I would argue, however, that its failure to provide a complete
> constitutes a significant technical omission for today's Internet, and I note

For IPv6, because of the removal of fragmentation by intermediate nodes, failure to provide a path where ICMP message delivery is assured is a considered a configuration error.

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

"We observed that for IPV4 between 4% and 6% of the paths between the vantage points and our experimental setup filter ICMP PTB packets. For IPV6 this was between 0.77% and 1.07%. Furthermore, we found that when IPV4 Domain Name System (DNS) servers do not act on the receipt of ICMP PTB packets, between 11% and 14% of the answers from these DNS servers are lost. For IPV6 DNS servers this was between 40% and 42%. Lastly, we found that for IPV4 approximately 6% of the paths between the vantage points and our experimental setup filter IP fragments. For IPV6 this was approximately 10%."

From that data it looks like we have been quite successful. ICMPv6 PMTUD is treated a lot better (about a 1% loss) than its IPv4 counterpart.
Unless better data exists I tend to conclude that the claim that the Internet breaks PTUMD for IPv6 is a myth.

Fragmentation on the other hand...
And please don't get me wrong, I think we have a big job to do on MTU issues. I just don't see data showing that PMTUD isn't doing what it was designed to do.

Best regards,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Mon, 13 Feb 2017 16:30:18 +1100

In message <[email-masked]>, [email-masked] writes:
> Yes, but DNS tend to use IP fragmentation that suffers an order of
> magnitude worse fate than ICMP messages. ;-)

Yep.  Idiots with firewalls break otherwise working protocols.
 
> For IPv6, because of the removal of fragmentation by intermediate nodes,
> failure to provide a path where ICMP message delivery is assured is a
> considered a configuration error.
>
> From
> http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis
> .pdf:
>
> "We observed that for IPV4 between 4% and 6% of the paths between the
> vantage points and our experimental setup filter ICMP PTB packets. For
> IPV6 this was between 0.77% and 1.07%. Furthermore, we found that when
> IPV4 Domain Name System (DNS) servers do not act on the receipt of ICMP
> PTB packets, between 11% and 14% of the answers from these DNS servers
> are lost. For IPV6 DNS servers this was between 40% and 42%. Lastly, we
> found that for IPV4 approximately 6% of the paths between the vantage
> points and our experimental setup filter IP fragments. For IPV6 this was
> approximately 10%."

There isn't a lot a DNS server can do unless the host OS records
the path MTU for that destination.  I suppose theoretically it could
listen for PTB then set IPV6_USE_MIN_MTU for destinations that it
has received a PTB for but that is not optimal.  Unfortunately the
OPT/TSIG/SIG records are towards the end of the packet so it generally
isn't possible to resend the response that triggered the PTB.

> From that data it looks like we have been quite successful. ICMPv6 PMTUD
> is treated a lot better (about a 1% loss) than its IPv4 counterpart.
> Unless better data exists I tend to conclude that the claim that the
> Internet breaks PTUMD for IPv6 is a myth.
>

Fragmentation failing is basically gun, foot, shoot by blocking all
fragments at the firewall.  Nameservers don't need to support
fragmentation for request traffic which is what at least one of the
fragmentation is broken tested.  Firewall could reassemble or be
more selective about the fragments they drop.

It doesn't help that there is this myth that IPv6 packets will never
be fragmented.

Mark

> And please don't get me wrong, I think we have a big job to do on MTU
> issues. I just don't see data showing that PMTUD isn't doing what it was
> designed to do.
>
> Best regards,
> Ole
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Feb 2017 15:31:12 +0000

Hi Ole,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Saturday, February 11, 2017 2:59 PM
> To: C. M. Heard <[email-masked]>
> Cc: 6man WG <[email-masked]>; IETF <[email-masked]>; Gen-ART <[email-masked]>; Suresh Krishnan <[email-masked]>;
> Stewart Bryant <[email-masked]>; [email-masked]
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 

Right, but RFC2473 also has other problems, e.g., integrity.

Thanks - Fred

> For IPv6, because of the removal of fragmentation by intermediate nodes, failure to provide a path where ICMP message delivery is
> assured is a considered a configuration error.
> 
> "We observed that for IPV4 between 4% and 6% of the paths between the vantage points and our experimental setup filter ICMP PTB
> packets. For IPV6 this was between 0.77% and 1.07%. Furthermore, we found that when IPV4 Domain Name System (DNS) servers do
> not act on the receipt of ICMP PTB packets, between 11% and 14% of the answers from these DNS servers are lost. For IPV6 DNS
> servers this was between 40% and 42%. Lastly, we found that for IPV4 approximately 6% of the paths between the vantage points and
> our experimental setup filter IP fragments. For IPV6 this was approximately 10%."
>