ietf
[Top] [All Lists]

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

2017-02-13 09:31:36
Hi Ole,

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces(_at_)ietf(_dot_)org] On Behalf Of 
otroan(_at_)employees(_dot_)org
Sent: Saturday, February 11, 2017 2:59 PM
To: C. M. Heard <heard(_at_)pobox(_dot_)com>
Cc: 6man WG <ipv6(_at_)ietf(_dot_)org>; IETF <ietf(_at_)ietf(_dot_)org>; 
Gen-ART <gen-art(_at_)ietf(_dot_)org>; Suresh Krishnan 
<suresh(_dot_)krishnan(_at_)gmail(_dot_)com>;
Stewart Bryant <stewart(_at_)g3ysx(_dot_)org(_dot_)uk>; 
draft-ietf-6man-rfc1981bis(_dot_)all(_at_)ietf(_dot_)org
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