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

["Templin, Fred L" <[e-mail]>]

Hi Ole,

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Saturday, February 11, 2017 2:59 PM
> To: C. M. Heard <[e-mail]>
> Cc: 6man WG <[e-mail]>; IETF <[e-mail]>; Gen-ART <[e-mail]>; Suresh Krishnan <[e-mail]>;
> Stewart Bryant <[e-mail]>; [e-mail]
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> > 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.
> 
> Yes, but DNS tend to use IP fragmentation that suffers an order of magnitude worse fate than ICMP messages. ;-)
> 
> > 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."
> 
> 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.

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

Thanks - Fred

> [...]
> 
> > 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.
> 
> 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
> 
>