[bind10-dev] #1534, IPV6_USE_MIN_MTU and similar

[Michal 'vorner' Vaner]

Hello

On Tue, Feb 14, 2012 at 11:03:10AM -0800, JINMEI Tatuya / 神明達哉 wrote:
> > Looking into bind9, there's a whole bunch of options to work around things that
> > are missing here and there (IPV6_USE_MIN_MTU, IPV6_MTU, IPV6_MTU_DISCOVER, some
> > workaround for IPV6_PKTINFO). This looks pretty complicated. How should we
> > proceed? Port the whole thing? Try to find something easier that works
> > everywhere? Never send packets that are that large?
> 
> NSD seems to use IPV6_MIN_MTU.  We can probably do the same:
> # if defined(IPV6_USE_MIN_MTU)
> [...]
> # elif defined(IPV6_MTU)
> 			/*
> 			 * On Linux, PMTUD is disabled by default for datagrams
> 			 * so set the MTU equal to the MIN MTU to get the same.
> 			 */
> 			on = IPV6_MIN_MTU;
> 			if (setsockopt(nsd->udp[i].s, IPPROTO_IPV6, IPV6_MTU, 
> 				&on, sizeof(on)) < 0)
> 			{
> 				log_msg(LOG_ERR, "setsockopt(..., IPV6_MTU, ...) failed: %s",
> 					strerror(errno));
> 				return -1;
> 			}
> 			on = 1;
> # endif

Yes, that's a similar bunch of ifdefs as I saw in bind9. Definitely not a nice
code. But if have nothing better, well, whatever, we need to implement it this
way.

> IMO using the minimum MTU for UDP/IPv6 is the most reasonable default
> behavior (I don't know how a tftp could be an exception, but even if
> it could be it seems to be very unlikely we have it in BIND 10), so it
> makes more sense to do it by default.  If an application specifically
> wants to perform PMTU discovery for UDP/IPv6 itself (IMO which will be
> very, very unlikely), that specific application can then disable
> USE_MIN_MTU, set IPV6_RECVPATHMTU and follow MTU change from ancillary
> data, etc (again, only very, very few apps would bother to do that).

Well, I remember Shane telling us about dream where it would contain tftp also,
so it could do netbooting completely (with assigning names, addresses, providing
the correct kernels).

And tftp usually runs on one network (I don't think tftp is ever used for
anything else but network booting), so the fragment size would not change on the
path at all, and having larger packets would be better for performance.

> As for where to set the option (assuming "do it by default" is
> agreed), I personally don't think it too much for the socket creator.
> It basically just a single call to setsockopt (unfortunately with a
> couple of ifdefs due to the non compliant systems), and we do it
> unconditionally (the behavior doesn't change based on the apps
> request).  If we even don't want to add that amount of code to sock
> creator, we could do it in the boss, probably with a small C/C++
> wrapper module.

I don't know. Maybe if it is just „use it for everything“, it is OK for the
socket creator.

Is here somebody who uses both linux and non-linux on regular basis, to check
both the ifdef branches compile correctly? If not, I can write it and try to be
careful when writing the code that won't be compiled here, but it's always
problematic.

Thank you

-- 
Next sleep is scheduled after 1k lines of code

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120215/80071ef4/attachment.bin>