| Message ID | 20101212144300.68e0fb16@mjolnir.ossman.eu |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
I've also noticed a problem in the nduseropt code that I'm not sure how
to solve (given that this is now a stable userspace interface). Both
RFC5006 and RFC6106 state the following:
Note: An RDNSS address or a DNSSL domain name MUST be used only as
long as both the RA router Lifetime (advertised by a Router
Advertisement message [RFC4861]) and the corresponding option
Lifetime have not expired.
But the RA router lifetime is not included in the information sent.
Normally this is probably not an issue as the RDNSS and DNSSL lifetime
will be shorter than the router lifetime. One exception is when the
router is disabled at which point it will send a RA with router
lifetime to 0 (RFC4861 section 6.2.5). That means userspace will not be
informed that the DNS information should be removed immediately*.
Is there any way we can safely extend the interface with this
information? I'm not familiar enough with it myself yet to determine if
it's possible...
* Unless the router has a workaround for this client bug and also sets
RDNSS and DNSSL lifetimes to 0 as part of the final message.
Rgds
On Sun, 2010-12-12 at 14:43 +0100, Pierre Ossman wrote: > RFC 6106 specifies a new RA option for DNS resolver configuration that > therefore needs to end up in userspace. > > This first patch just exports the new option, but I started thinking > that this seems overly complex that the kernel needs to be updated > every time there is something new of interest to userspace in the RA. > So I also have a second patch that exports everything that the kernel > doesn't want. > > Patches only compile tested so far as I'm still hacking away at > userspace. Comments very much welcome though. Totally untested userspace support: http://git.infradead.org/users/dwmw2/connman.git
On Tue, 14 Dec 2010 13:10:15 +0000 David Woodhouse <dwmw2@infradead.org> wrote: > On Sun, 2010-12-12 at 14:43 +0100, Pierre Ossman wrote: > > RFC 6106 specifies a new RA option for DNS resolver configuration that > > therefore needs to end up in userspace. > > > > This first patch just exports the new option, but I started thinking > > that this seems overly complex that the kernel needs to be updated > > every time there is something new of interest to userspace in the RA. > > So I also have a second patch that exports everything that the kernel > > doesn't want. > > > > Patches only compile tested so far as I'm still hacking away at > > userspace. Comments very much welcome though. > > Totally untested userspace support: > http://git.infradead.org/users/dwmw2/connman.git > Tested userspace support in the form of NetworkManager: ;) https://bugzilla.gnome.org/show_bug.cgi?id=637077 And a radvd to send things out: http://lists.litech.org/pipermail/radvd-devel-l/2010-December/000507.html Rgds
On Tue, 2010-12-14 at 14:43 +0100, Pierre Ossman wrote: > On Tue, 14 Dec 2010 13:10:15 +0000 > David Woodhouse <dwmw2@infradead.org> wrote: > > > On Sun, 2010-12-12 at 14:43 +0100, Pierre Ossman wrote: > > > RFC 6106 specifies a new RA option for DNS resolver configuration that > > > therefore needs to end up in userspace. > > > > > > This first patch just exports the new option, but I started thinking > > > that this seems overly complex that the kernel needs to be updated > > > every time there is something new of interest to userspace in the RA. > > > So I also have a second patch that exports everything that the kernel > > > doesn't want. > > > > > > Patches only compile tested so far as I'm still hacking away at > > > userspace. Comments very much welcome though. > > > > Totally untested userspace support: > > http://git.infradead.org/users/dwmw2/connman.git > > > > Tested userspace support in the form of NetworkManager: ;) > > https://bugzilla.gnome.org/show_bug.cgi?id=637077 And pushed to master and stable branches too. Thanks for the work on this! Dan > And a radvd to send things out: > > http://lists.litech.org/pipermail/radvd-devel-l/2010-December/000507.html > > Rgds -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, Thanks for the patch! > From a5b60e80eeed87763c811ecfb0d7aa5695d0a2bf Mon Sep 17 00:00:00 2001 > From: Pierre Ossman <pierre@xxxxxxxxx> > Date: Sun, 12 Dec 2010 00:06:48 +0100 > Subject: [PATCH 1/2] ipv6: export DNS search list option to userspace > > Like DNS resolver addresses, the suffixes to be used in DNS lookups need > to be configured by userspace. Make sure userspace has access to the > option containing that information. > > Signed-off-by: Pierre Ossman <pierre@xxxxxxxxx> > --- > include/net/ndisc.h | 3 ++- > net/ipv6/ndisc.c | 8 +++++++- > 2 files changed, 9 insertions(+), 2 deletions(-) Acked-by: Pierre Ynard <linkfanel@yahoo.fr>
> I've also noticed a problem in the nduseropt code that I'm not sure how > to solve (given that this is now a stable userspace interface). Both > RFC5006 and RFC6106 state the following: > > Note: An RDNSS address or a DNSSL domain name MUST be used only as > long as both the RA router Lifetime (advertised by a Router > Advertisement message [RFC4861]) and the corresponding option > Lifetime have not expired. > > But the RA router lifetime is not included in the information sent. > Normally this is probably not an issue as the RDNSS and DNSSL lifetime > will be shorter than the router lifetime. One exception is when the > router is disabled at which point it will send a RA with router > lifetime to 0 (RFC4861 section 6.2.5). That means userspace will not be > informed that the DNS information should be removed immediately*. > > Is there any way we can safely extend the interface with this > information? I'm not familiar enough with it myself yet to determine if > it's possible... You could define a new netlink attribute to carry the lifetime of the router in that RA. But that seems pointless to me, since in my understanding, you have to track the lifetime of that router in future RAs too, independently of whether or not they contain an RDNSS/DNSSL option or not. So the nduseropt code path is not the right place to track this. I suppose it's possible to use a netlink socket to track events related to the corresponding router and/or directly query its lifetime, in the same way as any networking tool does, and remove the option when it expires. That's what I planned to do in rdnssd, although I haven't looked into details. Regards,
From a5b60e80eeed87763c811ecfb0d7aa5695d0a2bf Mon Sep 17 00:00:00 2001 From: Pierre Ossman <pierre@ossman.eu> Date: Sun, 12 Dec 2010 00:06:48 +0100 Subject: [PATCH 1/2] ipv6: export DNS search list option to userspace Like DNS resolver addresses, the suffixes to be used in DNS lookups need to be configured by userspace. Make sure userspace has access to the option containing that information. Signed-off-by: Pierre Ossman <pierre@ossman.eu> --- include/net/ndisc.h | 3 ++- net/ipv6/ndisc.c | 8 +++++++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/include/net/ndisc.h b/include/net/ndisc.h index 895997b..9c8698a 100644 --- a/include/net/ndisc.h +++ b/include/net/ndisc.h @@ -33,7 +33,8 @@ enum { ND_OPT_MTU = 5, /* RFC2461 */ __ND_OPT_ARRAY_MAX, ND_OPT_ROUTE_INFO = 24, /* RFC4191 */ - ND_OPT_RDNSS = 25, /* RFC5006 */ + ND_OPT_RDNSS = 25, /* RFC5006 / RFC6106 */ + ND_OPT_DNSSL = 31, /* RFC6106 */ __ND_OPT_MAX }; diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c index 58841c4..c5b01e3 100644 --- a/net/ipv6/ndisc.c +++ b/net/ipv6/ndisc.c @@ -233,7 +233,13 @@ static struct nd_opt_hdr *ndisc_next_option(struct nd_opt_hdr *cur, static inline int ndisc_is_useropt(struct nd_opt_hdr *opt) { - return (opt->nd_opt_type == ND_OPT_RDNSS); + switch (opt->nd_opt_type) { + case ND_OPT_RDNSS: + case ND_OPT_DNSSL: + return 1; + default: + return 0; + } } static struct nd_opt_hdr *ndisc_next_useropt(struct nd_opt_hdr *cur, -- 1.7.2.3