[bind10-dev] msgq and dhcp4

[Shane Kerr]

Jinmei,

On Wednesday, 2012-05-16 10:29:43 -0700,
JINMEI Tatuya / 神明達哉 <jinmei at isc.org> wrote:
> At Wed, 16 May 2012 17:40:08 +0200,
> Shane Kerr <shane at isc.org> wrote:
> 
> > I think this is the right thing to do. I spent a few cycles looking
> > around the ASIO mailing list and googling and the like, and found
> > people with similar problems but nothing that exactly matches.
> > 
> > So, just to be sure, I think we have two different problem
> > statements, one for DNS and one for DHCP:
> > 
> > 1. For DNS, we need to know the destination IP address+port and use
> >    that as the source for reply packets.
> 
> Note that there's no widely available (much less "standard") IPv4 API
> for that, unless we assume the world is Linux.

Sorry for the late reply, not sure why I didn't see this! I am also
sorry if this e-mail repeats a lot of stuff, I'm not sure what we have
discussed on-list, what is discussed face-to-face, and what is new. :-/

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).

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.

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 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.
* Potentially lots of extra file descriptors, which incurs some
  overhead (although I admit probably not much).

So... thoughts?

--
Shane