Hi Ole, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@xxxxxxxx] On Behalf Of otroan@xxxxxxxxxxxxx > Sent: Saturday, February 11, 2017 2:59 PM > To: C. M. Heard <heard@xxxxxxxxx> > Cc: 6man WG <ipv6@xxxxxxxx>; IETF <ietf@xxxxxxxx>; Gen-ART <gen-art@xxxxxxxx>; Suresh Krishnan <suresh.krishnan@xxxxxxxxx>; > Stewart Bryant <stewart@xxxxxxxxxxxx>; draft-ietf-6man-rfc1981bis.all@xxxxxxxx > 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 > >