[bind10-dev] #1534, IPV6_USE_MIN_MTU and similar

[JINMEI Tatuya / 神明達哉]

At Tue, 21 Feb 2012 12:59:57 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > > So it looks like MTU is set per-destination, which means that a
> > > connected socket is required. :(
> > 
> > Michal points out on jabber that one can happily *set* the MTU, just
> > *reading* the value is not supported.
> > 
> > As we discussed on jabber, we can try to connect() during the tests,
> > which is where the pain lies.
> 
> The current error is following:
> [ RUN      ] get_sock.udp6_create
> sockcreator_tests.cc:140: Failure
> Value of: options
>   Actual: 16436
> Expected: 1280
> [  FAILED  ] get_sock.udp6_create (0 ms)

I think this proved we are doing a good job making sure that every
piece of code works as intended, btw.  Apparently no one else ever
noticed it doesn't work for Linux at all, possibly causing unexpected
response drops.

> This means that the setting doesn't work either, it just doesn't return any
> error (which is probably bug of somebody else. However, being it bug of somebody
> else doesn't solve our problem ‒ what to do in case of Linux. I'd have a
> proposal, consisting of three timelines:
> • Remove the setting of MTU from this ticket and be happy it works at last
>   somewhere.

I'd first note that we should still do this with IPV6_USE_MIN_MTU for
compliant OSes, and should do this within this ticket.

For Linux (or in general any OSes that don't support IPV6_USE_MIN_MTU
or provide any alternative), I'd suggest reducing the max response
size for UDP/IPv6 to 1280 - sizeof(IPv6 + UDP headers) so that larger
responses will be truncated and fallen back to TCP.

Other solutions seem to be too complicated as workaround for non
compliant systems.

We should also probably contact Linux kernel developers and ask for
supporting the IPV6_USE_MIN_MTU option.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.