Hi, Mark Smith <[email protected]> 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. 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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
