Rémi and Simon give my responses very eloquently. Although you could
have yet-another-network-daemon redundantly process RA messages, the
kernel is doing it already and it makes sense to just push this
information to userland using /proc and/or netlink. Although parsing
RA messages and processing expiry in userland looks barely-possible
now, SeND support is really necessary for long-term IPv6 security, and
duplicating SeND functionality in userland would be a nightmare.
Futher, the neighbor discover protocol involves Router Solicitation
messages which elicit the Router Advertisement reply, and we really
don't want userland sending redundant Router Solicitation messages
around, just because the kernel doesn't want to tell it what Router
Advertisements it received. I considered storing the *complete*
Router Advertisement messages received and pushing them unparsed to
userland, just to get around the bogus "DNS in the kernel" politics
(hint: it's not a resolver in the kernel, it's just nameserver
addresses being stored). Does anyone really suggest that this would
be a better solution?
The goal is to push the userland component into glibc, likely through
a NSS resolver plugin. Current glibc doesn't do any processing to
determine when /etc/resolv.conf has changed, which is a problem for
long-running applications. Exporting RDNSS-in-RA via netlink messages
(or by poll() on a /proc file as is done for /proc/<pid>/mounts, which
was suggested in linux-kernel) is an elegant solution that (as Rémi
noted) cleanly handles interface up/down/reconfig, route expiration,
and (eventually) the cryptographic neighbor discovery protocol without
weaving a web of hairs from the kernel to the resolver.
--scott
--
( http://cscott.net/ )
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
