Le samedi 23 juin 2007, David Stevens a écrit : > The kernel should do the authentication, as it will for other > RA's, > and should not deliver (IMAO) unauthenticated packets. If it is, I > would consider that a bug (for all cases, not just this), and that > would be a good thing to fix. :-)
I am all for an interface whereby the kernel queues all "accepted" RAs for userland to process additionnal parameters... but that's totally NOT how ICMPv6 raw sockets currently work, and it would be a very significant departure from the Advanced IPv6 Socket API (RFC 3542, in particular §3.3): An implementation might perform additional validity checks on the ICMPv6 message content and discard malformed packets. However, a portable application must not assume that such validity checks have been performed. Being malformed does not include failing authentication, or the local host not using autoconf. I am all for a setsockopt() that limits delivery to "accepted" RAs, but it does not currently exist. > An interface going down doesn't directly invalidate a DNS > server address, though it may not be the best through another > interface. Since it is a list, I think "doing nothing" for this case > wouldn't be terrible. This is no worse than the existing resolver > code. That would encourage people into running open recursive DNS servers which is widely known and documented as a bad practice. Definitely a very bad idea. > But if you really need it, you can monitor netlink, or poll the > interface flags on whatever interval you require for detection. > As for autoconf, that's available from sysctl, I assume from > /proc somewhere, too. That usually doesn't change, but if you want to > account for runtime configuration changes, you can always monitor > netlink and reread when new addresses appear, too. There are a bunch of parameters that determine whether an interface accepts RAs or not. I doubt it's wise to try to reimplement that into userspace, particularly if it is subject to change. > There certainly may be complications I haven't thought of, > since I haven't implemented it. But I still don't see a good case for > using the kernel as a DNS database. I never said the kernel needed to parse DNS messages by itself. My point is raw IPv6 sockets are not usable for the time being, and I do not see anyway to fix without modifying the kernel. The userspace DNS configuration daemon might need to be started later than the kernel autoconf - another issue that needs help from the kernel. -- Rémi Denis-Courmont http://www.remlab.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
