Hi Ole,

> -----Original Message-----
> From: ipv6 [mailto:[email protected]] On Behalf Of [email protected]
> Sent: Saturday, February 11, 2017 2:59 PM
> To: C. M. Heard <[email protected]>
> Cc: 6man WG <[email protected]>; IETF <[email protected]>; Gen-ART 
> <[email protected]>; Suresh Krishnan <[email protected]>;
> Stewart Bryant <[email protected]>; [email protected]
> 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
> 
> 


_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to