In message <A33FF8C9-E244-4404-9596-503D82F20B47(_at_)employees(_dot_)org>,
otroan(_at_)employees(_dot_)org writes:
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. ;-)
Yep. Idiots with firewalls break otherwise working protocols.
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.
[...]
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%."
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 on the other hand...
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: marka(_at_)isc(_dot_)org