On Wed, 22 Sep 2010 17:33:37 +0200 [email protected] (Arnaud Ebalard) wrote:
> Hi, > > Mikael Abrahamsson <[email protected]> writes: > > > On Wed, 22 Sep 2010, Arnaud Ebalard wrote: > > > >>> I never supported RA DNS, I think it is a genuinely bad idea. > >> > >> And you probably have some arguments to share ... > > > > DHCPv6 stateless seem more suited to put all these options in, DNS is > > just one (probably the most important one though), and since operating > > systems seem to handle RA in the kernel and not in userspace, > > extending RA to do more things is harder than doing it in DHCP (which > > is generally handled in userspace). > > Exporting stuff received in RA from kernel to userspace is not an > issue but that's not the point. RA *processing* is usually in kernel > space because the IPv6 stack is there, the mechanism is part of IPv6 > specification and it mainly serves address/link configuration purposes > which is usually done in the kernel. I think the kernel space/user space decision is about ubiquity. When it RAs/SLAAC is implemented in the kernel, then it's always there. If DHCPv6 had been implemented in kernels then we wouldn't have the availability issue we've got now. However, that's not a strong argument for kernel space address configuration either. DHCP for IPv4 is pretty much ubiquitous yet it isn't in the kernel - because it is installed by default by all OSes. Since the primary justification for kernel space is performance, it'd probably better and more secure if RA/SLAAC processing was moved into user space. I think a single RA/SLAAC/DHCPv6 process would better solve the stateless / stateful address configuration problem we've got now. It probably exists because RA/SLAAC processing is in kernel space in a lot of OSes where as DHCPv6 is seen to best reside in user space. (hopefully the last statement about configuration mechanism availability makes it on topic for this list) Appletalk in the Linux kernel follows the model of having address autoconfiguration operate as a process in user space. > > Most IPv6 nodes needs 2 main things to operate: > > 1) An address in subnet prefix (no matter which address) > 2) A DNS server > > RA provide 1) in *all* the subnets I have seen so far. SLAAC is a > builtin in all stacks (one would say even Mac OS X has it ;-) ), it is > light and efficient. > > When one has 1), providing 2) via RFC 5006 is straightforward: > support to export ND options to userspace was added to Linux kernel in > October 2007 (commit 31910575, 137 lines added). A simple RDNSS > userspace client is few lines of code. > > Now, when a network (not a client) has specific needs: > > - pushing various options which are useless for most clients > - give specific address to specific nodes > - support prefix delegation > - ... > > it may be worth using a common framework to do that and in that case the > initial complexity of DHCPv6 (RFC 3315 is more than 100 pages) might be > ok. > > In the end, the needs of most leaves of the networks (laptops, phones, > sensors, ...) are *usually* satisfied by ND alone and the features > brought by DHCPv6 get *usually* useful somewhat "higher" in the network > (possibly for routers and servers). > > I don't see the point in trying to replace ND by DHCPv6. DHCPv6 should > replace manual configuration where it is still there because ND is not > sufficient: the set of needed options should be deduced from the needs > of those environments. > > a+ > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
