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