In message <[email protected]>, Doug Barton writes:
> Given that larger and faster pipes are becoming more common, and given
> that we know that larger packet sizes make for more efficient
> utilization of those pipes, IMO it's a really bad idea to "give up the
> fight" at this early stage in IPv6 deployment.
>
> Until there is dramatic evidence to the contrary it seems to me that
> it's still worthwhile to push for making the protocol work as designed.
>
> Doug
For DNS PMTUD is just too slow (TCP) or doesn't work (UDP) as the
servers don't keep query state to resend replies on ICMPv6 frag
required and client retries are just too slow to trigger the resend.
This is why I pushed for a way to say fragment at 1280 back in
'98[1] which became IPv6_USE_MIN_MTU[2].
A recursive server has around 3 seconds to do a DNS lookup before
the client gives up. In that time it has to talk to multiple
servers. Deal with dead servers. Deal with packet loss due to
congestion. Deal with broken servers that don't respond. Deal
with PMTUD. Deal with broken firewalls that don't pass fragments.
PMTUD can be eliminated by setting IPv6_USE_MIN_MTU. This should
result in UDP fragments and TCP segments that don't get blocked due
to IP packet size. Some TCP stacks are broken as IPv6_USE_MIN_MTU
is ignored when they do their MSS negotiation.
As far as I can see the main reason fragmentation becomes a issue
is that firewalls and load balancers can't determine what to do
with a fragment as some information from the L4 header is missing.
If we supply that information in every fragment as a hop-by-hop
option{s} most of the problems are addressed.
You still have some firewalls that want to do deep inspection of
the packet but even then they could reassemble after filtering based
on the hop-by-hop option{s} which would provide some protection to
the reassembly queues on the firewall.
I also don't see what the deep inspection of UDP/DNS packets is
trying to accomplish when the same firewall passes TCP/DNS messages
without reassembling them. If you are a malicious server you would
just set TC=1 and attack the client over TCP. Yes, most clients
do correctly handle TC=1.
Mark
[1] https://datatracker.ietf.org/doc/draft-ietf-ipngwg-bsd-frag/
[2] http://tools.ietf.org/html/rfc3542
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
