[bind10-dev] #1534, IPV6_USE_MIN_MTU and similar

Shane Kerr shane at isc.org
Wed Feb 22 11:41:05 UTC 2012


Jinmei,

On Tuesday, 2012-02-21 20:07:18 -0800, 
JINMEI Tatuya / 神明達哉 <jinmei at isc.org> wrote:
> 
> Hmm, actually, if I checked the actual packet size with IPV6_MTU, it
> seems to be working.  I compiled the small program copied below and
> invoked it with a reachable IPv6 address on git.bind10, and saw this
> output:
> 
> getsockopt: Transport endpoint is not connected
> set IPV6_MTU to 1234
> 
> I did tcpdump at the other end and confirmed that the packet was
> actually fragmented at 1280 octets:
> 
> 17:04:29.887207 IP6 2001:4f8:3:d:20f:1fff:fe04:919b >
> 2001:4f8:3:36::162: frag (0|1232) 38462 > 8888: UDP, length 2000
> 17:04:29.887278 IP6 2001:4f8:3:d:20f:1fff:fe04:919b >
> 2001:4f8:3:36::162: frag (1232|776)
> 
> So, apparently, this OS shows a deviant behavior again and it's
> difficult to confirm it with a standalone unit test, but it somehow
> provides the expected feature.

Interesting.

I tried this with a connected socket, and then getsockopt() returns the
MTU of the interface (16436 for my loopback, 1500 for my Ethernet),
regardless of the IPV6_MTU value used in a previous setsockopt().

When sending on a connected socket, I see the same thing you see for
disconnected, which is that the MTU requested is actually used.

So, yes, this is write-only and we have no way to test it. 

Cheers,

--
Shane


More information about the bind10-dev mailing list