Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
From: Dan Williams <[EMAIL PROTECTED]> Date: Sun, 24 Jun 2007 22:17:31 -0400 > The glibc guys rejected things like periodically stat()-ing resolv.conf. At least these days such a thing could be re-proposed using something like inotify(), although it might be difficult to get glibc to receive that even asynchronously and without eating a file descriptor. - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On Sat, 2007-06-23 at 10:47 -0400, C. Scott Ananian wrote: > 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 The glibc guys rejected things like periodically stat()-ing resolv.conf. The standard solution to this has been to push the responsibility for noticing resolv.conf changes to _each_ _app_, which must periodically call _res_init() to get glibc to re-read resolv.conf and notice any changes. This is what eg Mozilla/Firefox and other internet-type apps do right now. Or, run a caching nameserver and point resolv.conf to 127.0.0.1, or use nss_lwres, which hopefully is in much better shape than it was a year or two ago (ie, actually respecting TTL and such). Dan > long-running applications. Exporting RDNSS-in-RA via netlink messages > (or by poll() on a /proc file as is done for /proc//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 > - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On Saturday 23 June 2007 03:17, Simon Arlott wrote: > Because then it requires yet another network daemon, RA in > the kernel means there's no need for one to manage adding > auto-configured IP addresses... what's wrong with doing the > same for DNS? Actually I think an integrated network autoconfiguration daemon capable of doing DHCP, DHCP6, RDNSS, mDNS, you-name-it would be a nice thing. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
From: Michael Buesch <[EMAIL PROTECTED]> Date: Sat, 23 Jun 2007 11:07:14 +0200 > Yeah, it might work. But I think the compiler doesn't guarantee > you anything about it. The compiler actually does guarentee these things, and that's why we have the endian bitfield macros. You're overreacting, we've been using this stuff for more than 10 years in the basic IPV4 header structure, so stop this nonsense. - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On Sat, Jun 23, 2007, David Stevens wrote: > 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. Excuse me for being a bit confused by the approach that you suggest, as so far it doesn't look very good to me either: I would be glad if you could clarify some points for the sake of the discussion. > 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. :-) You were talking about a raw ICMPv6 socket, right? Though, isn't the point of a "raw" socket to be raw? Would it be a "not-so-raw" raw socket, dropping a few unwanted packets? > 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. 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. If I understand well you suggest that in order to do things properly, the application should keep track of a lot of kernel-related stuff? I mean, the daemon, as the simple piece of code that you seem to have in mind, should only care about processing RA options that it receives: network/RA/configuration/availability concerns are precisely the role of the kernel, which it is already fulfilling, isn't it? It just looks naturally workable in the case where the kernel processes these options first, and then handles them to the daemon. Also, I think that RAs can be considered as a part of IPv6, right? As opposed to DHCP that is indeed an applicative protocol, I can't see why parts of a network protocol should be managed by a (non-networking) userland application. Saying that "it can only be used at application layer" doesn't look like a very good case for having networking packets handled by userland instead of the kernel, and seems rather selfish from the OS. Am I expecting too much as a user? I had the understanding that it was a better design to clearly handle autoconfiguration in one place, and not to scatter it between kernel and userland. For some reason, it is done in the kernel: do you mean that now the kernel should only support partial, half-way handling of RAs? It may seem a bit awkward as a solution. To me, it looks much more consistent that since the kernel already parses RA options that it needs, it be in charge of wholly processing the RA and extract and export all its options. That would be indeed practical, less error-prone and maybe more efficient than duplicating all the work to userland. Couldn't it be? After all, the fact that RDNSS be accepted as an RA option is an argument to say that it belongs in the kernel, not as DNS, but as an RA option. As you are saying to Rémi, your intent is to fix or enhance the existing, generic means of the kernel to provide an accurate access to these RA options, right? Isn't it just what we all want? -- Pierre Ynard WTS #51 - No phone "Une âme dans un corps, c'est comme un dessin sur une feuille de papier." - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
Le samedi 23 juin 2007, David Stevens a écrit : > This doesn't say that unauthenticated packets must be > delivered, and I don't think the portability of an RDNS daemon is an > issue. But even if you really wanted to run the same code on a > non-Linux machine, it just means that your daemon code would have to > do its own authentication. > Reading /proc or netlink with packet formats you've defined to get > this information is not more portable to non-Linux machines, right? I > don't see any issue here. If an application is relying on the ability > to see forged packets for portability reasons, it's probably not an > application you want running on your machine. :-) It so happens that the very userland applications that are currently using raw ICMPv6 sockets to see RAs *DO* want to see them all. As far as I know, they are all monitoring softwares (radvdump from radvd, rdisc6 from ndisc6, and probably scapy as well) where you do want to see "problematic" packets. All in all, this would break well-behaved standard-abiding userland applications... > > The userspace DNS configuration daemon might need to be started > > later than the kernel autoconf - another issue that needs help from > > the kernel. > > Easily done; the init scripts are what bring the interfaces > up in the first place, so start the daemon before those run. Adding > an entry in inittab so it'll be automatically restarted if it dies is > also a reasonable thing. RA's are resent periodically, and they can > be lost anyway, so not the end of the world if you miss one, either. What about NFS root? the network interface will already be up before even the real init gets started, let alone the userland RDNSS daemon. "resent periodically"... at a default rate of one every 10 minutes! I surely hope your desktop boots up faster than that. Besides, some links do not have unsolicited advertisements at all (I have seen such a PPPoA link for instance). An ugly kludge would be to send a RS from userland, but that's not so great considering routers are rate-limiting their RAs. The only way is for the kernel to remember "something" about the last processed RA. That disqualifies raw ICMPv6 sockets. -- Rémi Denis-Courmont http://www.remlab.net/ signature.asc Description: This is a digitally signed message part.
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
Rémi Denis-Courmont <[EMAIL PROTECTED]> wrote on 06/23/2007 11:13:01 AM: >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. This doesn't say that unauthenticated packets must be delivered, and I don't think the portability of an RDNS daemon is an issue. But even if you really wanted to run the same code on a non-Linux machine, it just means that your daemon code would have to do its own authentication. Reading /proc or netlink with packet formats you've defined to get this information is not more portable to non-Linux machines, right? I don't see any issue here. If an application is relying on the ability to see forged packets for portability reasons, it's probably not an application you want running on your machine. :-) > 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. I don't understand your point here. I'm talking about client behaviour, and if the client fails for a server from a downed interface, I don't see how that's different from removing the client from the list, which is what you want to do. Nobody should feel encouraged to do anything different on the server side-- at least not by me! > > 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. I'm not suggesting re-implementing anything; I'm saying you can read the current state at application level, if you need it. If you think it's difficult to get the correct information from existing API's, then improving those API's is always worthwhile. I don't believe it's excessively difficult to determine if autoconf is in use, though. > 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. I disagree about raw sockets being usable, but "without modifying the kernel" isn't a constraint. "modifying the kernel" != "put DNS server info in the kernel"; if there's a bug, or some minor tweaking that'd help the feature along, I'd support that. The important point for me is that the basic mechanisms are already in place, and I think it'd be best to use those rather than creating a new interface for all of this. > The userspace DNS configuration daemon might need to be started later > than the kernel autoconf - another issue that needs help from the > kernel. Easily done; the init scripts are what bring the interfaces up in the first place, so start the daemon before those run. Adding an entry in inittab so it'll be automatically restarted if it dies is also a reasonable thing. RA's are resent periodically, and they can be lost anyway, so not the end of the world if you miss one, either. +-DLS - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
Rémi Denis-Courmont <[EMAIL PROTECTED]> wrote on 06/23/2007 09:51:55 AM: > How do I authenticate SeND RA? How do I deal with the link going down > before the expiration? How do I know "this" interface is doing autoconf > at all? 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. :-) 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. 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 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. +-DLS - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
Le samedi 23 juin 2007, David Stevens a écrit : > No, in fact! I didn't hear anyone suggesting that all of > neighbor discovery be pushed out of the kernel. All I suggested is > that you read a raw ICMPv6 socket for RA's that have the RDNS header > and the app _process_the_RDNS_header. The kernel should still > continue to do everything it needs to with the kernel data in the RA. > Then you just need a hash table (or maybe just a list -- there > shouldn't be a lot of them) and a timer to delete them when the RDNS > expiration hits. Easy, right? The exact thing I pointed out does not work. I *DID* write RA parsing in userland in the past. > You might have to change the icmp6_filter, if RA's are not > already copied to raw sockets (I don't know either way offhand), > but that's a trivial kernel patch; otherwise, I don't believe you > have to do anything but read the socket and process the RDNS header > on RAs you receive. To reiterate: How do I authenticate SeND RA? How do I deal with the link going down before the expiration? How do I know "this" interface is doing autoconf at all? -- Rémi Denis-Courmont http://www.remlab.net/ signature.asc Description: This is a digitally signed message part.
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
[EMAIL PROTECTED] wrote on 06/23/2007 07:47:06 AM: > 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 It would be two pieces looking at the same packet, but it isn't redundant processing. The kernel would ignore the RDNS header, and the app would ignore everything else; everything would be processed once. > Although parsing > RA messages and processing expiry in userland looks barely-possible > now, "barely possible"?? See below. > 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? No, in fact! I didn't hear anyone suggesting that all of neighbor discovery be pushed out of the kernel. All I suggested is that you read a raw ICMPv6 socket for RA's that have the RDNS header and the app _process_the_RDNS_header. The kernel should still continue to do everything it needs to with the kernel data in the RA. Then you just need a hash table (or maybe just a list -- there shouldn't be a lot of them) and a timer to delete them when the RDNS expiration hits. Easy, right? You might have to change the icmp6_filter, if RA's are not already copied to raw sockets (I don't know either way offhand), but that's a trivial kernel patch; otherwise, I don't believe you have to do anything but read the socket and process the RDNS header on RAs you receive. +-DLS - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On 23/06/07 15:47, C. Scott Ananian wrote: > 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? Yes, but I don't think it should be completely unparsed - it should be possible to retrieve the data for a specific attribute type with expiration information and with notification of changes. The kernel has to read RAs anyway, why shouldn't it store them in a way that userspace can access it on demand? A /proc file which is in resolv.conf format is definitely *wrong*, and while I'd argue for DNS being special enough to export its attributes is it really too much to have the kernel provide everything from the last valid message in a partially parsed format? Applications would then parse the data section for RA attributes they understand. -- Simon Arlott - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
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//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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
Hello, Le samedi 23 juin 2007, David Stevens a écrit : > Why not make the application that writes resolv.conf > also listen on a raw ICMPv6 socket? I don't believe you'd need > any kernel changes, then, and it seems pretty simple and > straightforward. Unfortunately, ICMPv6 raw sockets will not work quite properly here, without modifications. At the moment, such a socket will queue just about any Router Advertisement that is received by the host. Now, assuming the userland daemon did sanity check the message (properly formatted, source and destination addresses are sane, etc), it needs to know whether the IPv6 kernel stack has "accepted" it or not. It could be that the interface the RA was received on had autoconf disabled at the time the packet showed up, or it could be that the system is currently configured as a router, or it could be that we have a SeND-patched kernel and the RA did not pass authentication checks. And then, what happens if IPv6 networking has been initialized before init got the chance to start the daemon, for instance root over NFS/IPv6? The RA is lost. Similarly, the daemon has no way to know when information gathered from an RA becomes invalid. Of course, it can duplicate the lifetime timers in userland, but only the kernel knows if the link has been reset to off and on earlier than lifetime expiration. Whether parsing RDNSS-in-RA belong in the kernel is irrelevant to me, as the kernel does not provide any interface for userland to do it properly at the moment. -- Rémi Denis-Courmont http://www.remlab.net/ signature.asc Description: This is a digitally signed message part.
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On Saturday 23 June 2007 02:09:18 C. Scott Ananian wrote:
> > > diff -ruHpN -X dontdiff linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h
> > > linux-2.6.22-rc5/include/net/ip6_rdnss.h
> > > --- linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h1969-12-31
> > > 19:00:00.0 -0500
> > > +++ linux-2.6.22-rc5/include/net/ip6_rdnss.h2007-06-21
> > > 18:16:33.0 -0400 @@ -0,0 +1,58 @@
> > > +#ifndef _NET_IP6_RDNSS_H
> > > +#define _NET_IP6_RDNSS_H
> > > +
> > > +#ifdef __KERNEL__
> > > +
> > > +#include
> > > +
> > > +struct nd_opt_rdnss {
> > > +__u8type;
> > > +__u8length;
> > > +#if defined(__BIG_ENDIAN_BITFIELD)
> > > +__u8priority:4,
> > > +open:1,
> > > +reserved1:3;
> > > +#elif defined(__LITTLE_ENDIAN_BITFIELD)
> > > +__u8reserved1:3,
> > > +open:1,
> > > +priority:4;
> > > +#else
> > > +# error not little or big endian
> > > +#endif
> >
> > That is not endianess-safe. Don't use foo:x at all
> > for stuff where a specific endianess is needed. The
> > compiler doesn't make any guarantee about it.
>
> This was copied directly from include/net/ip6_route.h. I believe that
> it does in fact work, and I (for one) find this much more readable
> than the alternative. If it is in fact broken, then
> include/net/ip6_route.h (and the 35 other files which use this #ifdef
> in this manner) should be fixed.
Yeah, it might work. But I think the compiler doesn't guarantee
you anything about it.
--
Greetings Michael.
-
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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On Sat, Jun 23, 2007, David Miller wrote: > From: David Stevens <[EMAIL PROTECTED]> > > Auto-configured addresses are used by the kernel. It has to > > have those addresses. But the kernel doesn't do DNS look-ups, or > > write resolv.conf; that's the difference, for me. > > I totally agree with David, this stuff definitely does not belong > in the kernel. It is my understanding that you think that IP stack configuration belongs in the kernel whereas DNS does not, right? Then I have a question: does RS-RA management belong in the kernel or not? -- Pierre Ynard WTS #51 - No phone "Une âme dans un corps, c'est comme un dessin sur une feuille de papier." - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
From: David Stevens <[EMAIL PROTECTED]> Date: Fri, 22 Jun 2007 21:30:05 -0700 > [EMAIL PROTECTED] wrote on 06/22/2007 06:17:46 PM: > > > On 23/06/07 02:04, David Stevens wrote: > > > Why not make the application that writes resolv.conf > > > also listen on a raw ICMPv6 socket? I don't believe you'd need > > > any kernel changes, then, and it seems pretty simple and > > > straightforward. > > > > Because then it requires yet another network daemon, RA in > > the kernel means there's no need for one to manage adding > > auto-configured IP addresses... what's wrong with doing the > > same for DNS? > > It's not yet another one, since you have to run something > to get it in resolv.conf, anyway. That seems much better to me > than having the kernel track data that can only be used at the > application layer. The app itself looks like it'd be really simple. > Auto-configured addresses are used by the kernel. It has to > have those addresses. But the kernel doesn't do DNS look-ups, or > write resolv.conf; that's the difference, for me. I totally agree with David, this stuff definitely does not belong in the kernel. - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On 23/06/07 05:30, David Stevens wrote: > [EMAIL PROTECTED] wrote on 06/22/2007 06:17:46 PM: Is there a reason why you're CC:ing the Sender? Doesn't that end up in the mailbox(es) of the netdev admin(s)? >> On 23/06/07 02:04, David Stevens wrote: >>> Why not make the application that writes resolv.conf >>> also listen on a raw ICMPv6 socket? I don't believe you'd need >>> any kernel changes, then, and it seems pretty simple and >>> straightforward. >> Because then it requires yet another network daemon, RA in >> the kernel means there's no need for one to manage adding >> auto-configured IP addresses... what's wrong with doing the >> same for DNS? > > It's not yet another one, since you have to run something > to get it in resolv.conf, anyway. That seems much better to me Well, it'd be the library including it - so there'd be no daemon application involved. > than having the kernel track data that can only be used at the > application layer. The app itself looks like it'd be really simple. Keeping application data in the kernel does start to get silly though, e.g. everything in dhcp-options(5)... but DNS is used almost everywhere. This could be a configuration option so that anyone who doesn't want it can disable it completely. > Auto-configured addresses are used by the kernel. It has to > have those addresses. But the kernel doesn't do DNS look-ups, or > write resolv.conf; that's the difference, for me. Using DHCPv6 as an example, auto-configuration does not have to be in the kernel at all either. -- Simon Arlott - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
[EMAIL PROTECTED] wrote on 06/22/2007 06:17:46 PM: > On 23/06/07 02:04, David Stevens wrote: > > Why not make the application that writes resolv.conf > > also listen on a raw ICMPv6 socket? I don't believe you'd need > > any kernel changes, then, and it seems pretty simple and > > straightforward. > > Because then it requires yet another network daemon, RA in > the kernel means there's no need for one to manage adding > auto-configured IP addresses... what's wrong with doing the > same for DNS? It's not yet another one, since you have to run something to get it in resolv.conf, anyway. That seems much better to me than having the kernel track data that can only be used at the application layer. The app itself looks like it'd be really simple. Auto-configured addresses are used by the kernel. It has to have those addresses. But the kernel doesn't do DNS look-ups, or write resolv.conf; that's the difference, for me. +-DLS - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On Fri, 2007-06-22 at 20:09 -0400, C. Scott Ananian wrote:
> > > diff -ruHpN -X dontdiff linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h
> > > linux-2.6.22-rc5/include/net/ip6_rdnss.h
> > > --- linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h1969-12-31
> > > 19:00:00.0 -0500
> > > +++ linux-2.6.22-rc5/include/net/ip6_rdnss.h2007-06-21
> > > 18:16:33.0 -0400 @@ -0,0 +1,58 @@
> > > +#ifndef _NET_IP6_RDNSS_H
> > > +#define _NET_IP6_RDNSS_H
> > > +
> > > +#ifdef __KERNEL__
> > > +
> > > +#include
> > > +
> > > +struct nd_opt_rdnss {
> > > +__u8type;
> > > +__u8length;
> > > +#if defined(__BIG_ENDIAN_BITFIELD)
> > > +__u8priority:4,
> > > +open:1,
> > > +reserved1:3;
> > > +#elif defined(__LITTLE_ENDIAN_BITFIELD)
> > > +__u8reserved1:3,
> > > +open:1,
> > > +priority:4;
> > > +#else
> > > +# error not little or big endian
> > > +#endif
> >
> > That is not endianess-safe. Don't use foo:x at all
> > for stuff where a specific endianess is needed. The
> > compiler doesn't make any guarantee about it.
>
> This was copied directly from include/net/ip6_route.h. I believe that
> it does in fact work, and I (for one) find this much more readable
> than the alternative. If it is in fact broken, then
> include/net/ip6_route.h (and the 35 other files which use this #ifdef
> in this manner) should be fixed.
Though in general, we shouldn't be using bitfields, FYI. They are known
to generate really crappy code on many architectures, and patches that
contain them have been smacked down quite hard by people we all know are
better hackers than us :)
Dan
-
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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On 23/06/07 02:04, David Stevens wrote: > Why not make the application that writes resolv.conf > also listen on a raw ICMPv6 socket? I don't believe you'd need > any kernel changes, then, and it seems pretty simple and > straightforward. Because then it requires yet another network daemon, RA in the kernel means there's no need for one to manage adding auto-configured IP addresses... what's wrong with doing the same for DNS? I don't think it should be in resolv.conf format though. Can't you make a change to glibc too to have it use it properly? Something like "hosts: files rdnss dns" or an option that can be added to resolv.conf? -- Simon Arlott - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
Scott, Why not make the application that writes resolv.conf also listen on a raw ICMPv6 socket? I don't believe you'd need any kernel changes, then, and it seems pretty simple and straightforward. +-DLS - 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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
> diff -ruHpN -X dontdiff linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h
> linux-2.6.22-rc5/include/net/ip6_rdnss.h
> --- linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h1969-12-31
> 19:00:00.0 -0500
> +++ linux-2.6.22-rc5/include/net/ip6_rdnss.h2007-06-21
> 18:16:33.0 -0400 @@ -0,0 +1,58 @@
> +#ifndef _NET_IP6_RDNSS_H
> +#define _NET_IP6_RDNSS_H
> +
> +#ifdef __KERNEL__
> +
> +#include
> +
> +struct nd_opt_rdnss {
> +__u8type;
> +__u8length;
> +#if defined(__BIG_ENDIAN_BITFIELD)
> +__u8priority:4,
> +open:1,
> +reserved1:3;
> +#elif defined(__LITTLE_ENDIAN_BITFIELD)
> +__u8reserved1:3,
> +open:1,
> +priority:4;
> +#else
> +# error not little or big endian
> +#endif
That is not endianess-safe. Don't use foo:x at all
for stuff where a specific endianess is needed. The
compiler doesn't make any guarantee about it.
This was copied directly from include/net/ip6_route.h. I believe that
it does in fact work, and I (for one) find this much more readable
than the alternative. If it is in fact broken, then
include/net/ip6_route.h (and the 35 other files which use this #ifdef
in this manner) should be fixed.
--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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On Saturday 23 June 2007 01:26:19 C. Scott Ananian wrote:
> +struct rdns6_info {
> + rwlock_tlock;
> + struct timer_list expiry_timer;
> + struct rdns6_entry *rdnss_list;
> + struct inet6_dev * in6_dev; /* back pointer for netlink notify */
> + int expire_all : 1, /* remove entries on ifdown */
> + free_me : 1; /* safely free this struct */
> +};
Sparse will complain about that.
I suggest you do:
+struct rdns6_info {
+ rwlock_tlock;
+ struct timer_list expiry_timer;
+ struct rdns6_entry *rdnss_list;
+ struct inet6_dev * in6_dev; /* back pointer for netlink notify */
+ u8 expire_all; /* remove entries on ifdown */
+ u8 free_me; /* safely free this struct */
+};
Will generate better code and
struct size shouldn't increase. So it's a net win.
--
Greetings Michael.
-
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
Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration
On Saturday 23 June 2007 01:26:19 C. Scott Ananian wrote:
> Attached is my first draft of a patch to implement RDNSS-in-Router
> Advertisements support for IPv6 (
> http://tools.ietf.org/html/draft-jeong-dnsop-ipv6-dns-discovery-12 )
> as implemented in radvd ( http://www.litech.org/radvd/ ). It
> currently exports the autoconfigured DNS list as /proc/net/ipv6_dns --
> ultimately it ought to (a) implement inotify on this file, so that
> glibc could use it like /etc/resolv.conf and get notifications when
> the DNS list changes, and (b) export the DNS list via netlink as well.
>
> Comments & discussion, please!
> --scott
> diff -ruHpN -X dontdiff linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h
> linux-2.6.22-rc5/include/net/ip6_rdnss.h
> --- linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h 1969-12-31
> 19:00:00.0 -0500
> +++ linux-2.6.22-rc5/include/net/ip6_rdnss.h2007-06-21
> 18:16:33.0 -0400 @@ -0,0 +1,58 @@
> +#ifndef _NET_IP6_RDNSS_H
> +#define _NET_IP6_RDNSS_H
> +
> +#ifdef __KERNEL__
> +
> +#include
> +
> +struct nd_opt_rdnss {
> + __u8type;
> + __u8length;
> +#if defined(__BIG_ENDIAN_BITFIELD)
> + __u8priority:4,
> + open:1,
> + reserved1:3;
> +#elif defined(__LITTLE_ENDIAN_BITFIELD)
> + __u8reserved1:3,
> + open:1,
> + priority:4;
> +#else
> +# error not little or big endian
> +#endif
That is not endianess-safe. Don't use foo:x at all
for stuff where a specific endianess is needed. The
compiler doesn't make any guarantee about it.
Please do
__u8 flags;
#define FOOBAR_RESERVED 0x07
#define FOOBAR_OPEN 0x08
#define FOOBAR_PRIORITY 0xF0
and use them in the code.
In general I try to avoid the foo:x stuff, as it
has little or no gain. It just generates worse code.
--
Greetings Michael.
-
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
