[bind10-dev] Solaris doesn't honor IPV6_USE_MIN_MTU?

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Tue Feb 28 19:05:33 UTC 2012


At Tue, 28 Feb 2012 15:51:59 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > would not help in this case, IPV6_MTU isn't defined on solaris.
> > 
> > Btw, it's not the only flag that gets ignored on setsockopt
> 
> Ah, stupid solaris. We still have the raw interface and could forge the packets
> ourself, but I'd rather avoid that. Could we just say if it doesn't work on
> solaris, it's their problem? O:-)

To be fair in this specific case (IPV6_USE_MIN_MTU) Linux is equally
"stupid" in that it ignores the standard option and only reinvents its
own proprietry option (IPV6_MTU).

Anyway, regarding the Solaris issue, I'd wait for a while to see if
we can get any suggestion on workaround.  Then I'd try at least one
more API knob: using IPV6_USE_MIN_MTU as ancillary data (using it with
ASIO may not be realistic, though).  As a last resort option I'd
propose the one I suggested for Linux before: truncate responses at
1280 - (IPv6 + UDP headers) octets for such systems.

> Considering we did a mostly copy of what both bind9 and NSD does, and nobody
> complained to them (I assume), does the problem actually exist?

As Shane pointed out, the indicents may have just been hidden for now.
As IPv6 servers/connectivity deploys more widely and as DNSSEC deploys
more widely (which tends to increase the response message size) the
problem may become more annoying (although it will be still okay if
the path MTU is equal to the MTU of the outgoing link, and as IPv6 is
deplayed such smaller-MTU links are probably/hopefully going to vanish
- they often appear in IPv6/IPv4 tunnels as a transition technology).

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


More information about the bind10-dev mailing list