before I forget half of what we talked about here and to share it, here's how I think the network autoconfig stuff should work in the future.
from the user's PoV, there shouldn't be more needed than ifconfig <if> inet autoconf ifconfig <if> inet6 autoconf aka inet/inet6 autoconf in hostname.if. for inet6, we're almost there with the work done by florian and me from this week. not all of that is in yet. now for inet, I'm pretty damn certain we don't want to do DHCP in the kernel. turning on autoconf should lead to a new message on the routing socket, and a little userland daemon, let's call it autoconfd for the moment, reacts to that message insofar that it sends out the dhcp request(s) and deals with the answers. using the dhclient code of course. open question is what to do if inet autoconf is on on more than one interface - gotta select the default route somehow. inet6 does that and does it very different. we'll figure sth out it. if needed/useful dhcp6 could be integrated into that scheme kinda easily, too. i won't judge on whether that is the case; it isn't relevant yet. for the nameservers: in the inet case, autoconfd would know them from dhcp. i've been told the inet6 RAs can contain nameserver information, too. we can pass those up from the kernel using a message on the routing socket as well (this is inspired by the kernel-ipsec <-> iked/isakmpd model). the resolv.conf writing races / fights would be gone since autoconfd is the only one dealing with it. of course i don't insist on implementing all that myself, not remotely. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
