[bind10-dev] msgq and dhcp4

[JINMEI Tatuya / 神明達哉]

At Mon, 21 May 2012 13:07:32 +0200,
Shane Kerr <shane at isc.org> wrote:

> > > 1. For DNS, we need to know the destination IP address+port and use
> > >    that as the source for reply packets.

> We can use IP_PKTINFO as you mention on Linux and Windows. FreeBSD
> seems to have IP_RECVDSTADDR/IP_SENDSRCADDR which should do the
> equivalent.
> 
> Still, there are probably systems that offer no way to get this
> information. If it was just AIX or HP-UX, I might be inclined to say
> "bad luck for those platforms", but I am guessing that Solaris also has
> this problem (Google didn't show any likely solutions for Solaris).

And other BSD variants.

> One possibility that may work for all systems is to require the use of
> IPv6 when someone is using a wildcard address, at least on systems that
> do not support the IPv4-equivalent of IPV6_PKTINFO. In this case, we
> can bind to :: and we should receive IPv4 packets as IPv4-mapped IPv6
> addresses.

As far as I know, there's no kernel implementation that makes it work.
The API spec is also silent about this usage (in fact, such open
behavior/API spec was one of the points in the mostly religious
discussions on whether "mapped address is harmful/useful"), so I
suspect it's less promising than selectively using the IPv4-specific
API.

> On the one hand this may be a it of a hard sell, since it may not be
> easy for some administrators, and also it is not *exactly* the same.
> You may also really want different behavior on IPv4 and IPv6 wildcard,
> although I can hardly imagine this is a very common case. On the other
> hand, it's 2012 and everyone should be running IPv6-capable systems.
> This doesn't require anything other than IPv6 on the IP stack of the
> server, and it seems less radical when looking at the rest of our
> system requirements. :)

If you are talking about getting/setting IPv4 address on an AF_INET6
socket with IPV6_PKTINFO, I'm afraid it doesn't work as noted above.

Even a more radical requirement would be that "since it's already in
the middle of the 21st century, just forget the stale IP version.
BIND 10 still provides minimum level of support for it for legacy
environments, but it may not always work.  The only real solution is
to use the modern IP version".  I wish we could say that:-)

So, in reality, I'm afraid we cannot avoid to do this anyway:

> If we don't go for this, then we'll need to monitor interfaces and
> bind to them directly. This has a couple of advantages:
> 
> * Although interface detection is non-portable, it can be implemented
>   anywhere, and we need this for DHCP no matter what.
> * No need to worry about ASIO changes! ;)
> 
> It also has disadvantages:
> 
> * We need to scan for interface changes, creating a delay plus extra
>   work, or we need to implement OS-specific methods to be alerted to
>   changes in interfaces.

Since the scan itself would be OS-specific, I don't think real-time
interface monitoring is so different from it in terms of portability.
And, if we do this, we can at least avoid the disadvantage of the
delay.  The additional amount of work could be an issue of course, and
I know we have tons of basic things to complete even before thinking
about this.

> * Potentially lots of extra file descriptors, which incurs some
>   overhead (although I admit probably not much).

I suspect it's not significant, either.

---
JINMEI, Tatuya