On Thu, 23 Sep 2010 19:12:34 +0930 Mark Smith <i...@69706e6720323030352d30312d31340a.nosense.org> wrote:
> 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. > To qualify that, I'm saying RS/RAs could be processed in user space, as part of a RS/RA/SLAAC/ Stateless/Stateful DHCPv6 process (i.e. an "address and routing configuration" process), while ND NS/NA could be left in kernel space. (I've somehow got into the habit of thinking that the term "neighbor discovery" is referring to layer 3 -> layer 2 address resolution. I blame Radia Perlman, because that's mostly what she talks about in her "Neighbor Discovery" chapter of "Interconnections" ;-) ) > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
