IPV6_USE_MIN_MTU

[Wolfgang Solfrank]

Hi,

finally I got around to analyzing a problem I had with dnssec and
named. Actually, I didn't find the final cause of the problem yet
(something is eating ipv6 fragments), however, the analysis
led me to some sub-optimal implementation detail of our IPv6 stack.

Since path mtu discovery doesn't work too well with the short lived
tcp connections that are occasionally used with dns, BIND software
tries to set the mtu to the minimum when using IPv6. For this it
sets the IPV6_USE_MIN_MTU option to IP6PO_MINMTU_ALL. The intention
is to use the minimum mtu (1280 bytes) for TCP connections over IPv6.

However, the code in tcp_output, which constructs the TCP packet
for a connection, doesn't know about this option. It uses the path
mtu (in the problematic case I investigated 1500 bytes). Only after
constructing the TCP packet and handing it over to ip6_output, that
routine recognizes the IP6PO_MINMTU_ALL option and fragments the
1500 byte packet in one with 1280 bytes and one with the rest.

The net result is that the use of the IPV6_USE_MIN_MTU option,
meant to avoid fragmentation, actually ensures that the packets
are fragmented (at least most of the time).

To fix this we need to make tcp_output aware of the option so it
can use the same value for mtu as is later used by ip6_output.

Comments?

Ciao,
Wolfgang

[Robert Elz]

Date: Fri, 18 Dec 2015 15:11:13 +0100
From: Wolfgang Solfrank <***@Solfrank.net>
Message-ID: <***@Solfrank.net>

| The net result is that the use of the IPV6_USE_MIN_MTU option,
| meant to avoid fragmentation,

That's not actually its purpose. The idea is to guarantee packet arrival,
when the Path MTU is not known - and as you said earlier in the message,
because DNS TCP connections, when needed at all (other than when doing zone
transfers) are typically not suited to PMTUD. Avoiding fragmentation
isn't actually the objective, just ensuring that packets don't cause
"packet too big" replies from somewhere in the path.

But ..

| actually ensures that the packets
| are fragmented (at least most of the time).

this is still not good, fragmentation is mostly evil, and should be
avoided wherever possible. TCP (with sufficient info) should always
be able to avoid it.

| To fix this we need to make tcp_output aware of the option so it
| can use the same value for mtu as is later used by ip6_output.

Seems reasonable to me, though I'm not sure the packet option that's
being used is the overall best solution to the problem. For these
short TCP connections, a TCP socket option to set the max outgoing
seg size would seem like a better idea. Even just the initial outgoing
seg size, with PMTUD allowed to adjust it up (DNS query/response connections
would be finished before PMTUD decides to start probing for bigger...)

kre



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de