On Thu, 23 Sep 2010 10:32:11 +0200 a...@natisbad.org (Arnaud Ebalard) wrote:
> Hi, > > Mark Smith <i...@69706e6720323030352d30312d31340a.nosense.org> writes: > > > 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. > > ND is about *basic* operations of the IPv6 nodes to support its > communications on the link (including w/ routers). Most of the changes > done are usually against kernel structures (routing table, neighbor > cache, ...). This is IMHO the reason why it makes sense for it to be > in kernel space by default. > I was talking about RAs/SLAAC, not ND. > Then, if more needs to be done with ND (as long as it is useful and > logical extensions, to support basic and simple things) it is easier to > export the content of messages to userspace (ND options are simple > enough). Just as it is done for RDNSS in Linux kernel. > > The question of where to best suppor SEND does not belong here I think. > > > 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. > > Compared to ND, the additional stuff supported by DHCP are for providing > additional info for various higher level functions of the system or > devices that are very advanced nodes (router, servers, ...). > > > 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. > > You would still need the interfaces to interact with the routing table, > the neighbor cache, ... Most of those interfaces will probably be more > complex than the parsing of RA in kernel space (even if Microsoft > managed to prove me wrong with MS10-009). > > > 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) > > I implemented support for both protocols in Scapy and AFAICT DHCPv6 does > not belong to kernel space: it is too complex and far from the basic > operations the kernel is here to do. > > > Appletalk in the Linux kernel follows the model of having address > > autoconfiguration operate as a process in user space. > > I am not familiar w/ the protocol. > > Cheers, > > a+ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
