Export userland ND options through netlink (RDNSS support)
Subsystems (3)
RFC 1/1 Export userland ND options through netlink (RDNSS support)
As discussed before, this patch provides userland with a way to access relevant options in Router Advertisements, after they are processed and validated by the kernel. Extra options are processed in a generic way; this patch only exports RDNSS options described in RFC5006, but support to control which options are exported could be easily added.
Options are exported using a new message type of rtnetlink. I am totally new to netlink, so help would be greatly appreciated to design a right interface. For now each message only contains a single ND option, in its raw format. Should they contains several options when possible?
Also, depending on the option, userland might need context information contained in the rest of the RA packet. For example, RFC5006 states:
"Note: An RDNSS address MUST be used only as long as both the RA router lifetime and the RDNSS option lifetime have not expired."
which implies that a userland daemon processing RDNSS options needs a way to associate the option to the router that sent it, and fetch its lifetime. This kind of information could be included in a header in the rtnetlink message (in this version of the patch there is none).
Regards,
include/linux/rtnetlink.h +5 -0
@@ -97,6 +97,9 @@ enum { RTM_SETNEIGHTBL,#define RTM_SETNEIGHTBL RTM_SETNEIGHTBL + RTM_NEWNDUSEROPT = 68, +#define RTM_NEWNDUSEROPT RTM_NEWNDUSEROPT + __RTM_MAX,#define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1) };
@@ -542,6 +545,8 @@ enum rtnetlink_groups {#define RTNLGRP_IPV6_PREFIX RTNLGRP_IPV6_PREFIX RTNLGRP_IPV6_RULE,#define RTNLGRP_IPV6_RULE RTNLGRP_IPV6_RULE + RTNLGRP_ND_USEROPT, +#define RTNLGRP_ND_USEROPT RTNLGRP_ND_USEROPT __RTNLGRP_MAX };#define RTNLGRP_MAX (__RTNLGRP_MAX - 1)
include/net/ndisc.h +1 -0
@@ -24,6 +24,7 @@ enum {ND_OPT_MTU =5 ,/* RFC2461 */ __ND_OPT_ARRAY_MAX,ND_OPT_ROUTE_INFO =24 ,/* RFC4191 */ +ND_OPT_RDNSS =25 ,/* RFC5006 */ __ND_OPT_MAX };
net/ipv6/ndisc.c +74 -9
127 lines not on this page · raw message
Signature · 3 lines
Pierre Ynard For hire in Quebec City, Canada, during Fall 2007 "Une âme dans un corps, c'est comme un dessin sur une feuille de papier."
Hello.
In article <[email protected]> (at Sat, 29 Sep 2007 19:47:20 +0200), Pierre Ynard <[email protected]> says:
Quoted 5 lines
As discussed before, this patch provides userland with a way to access relevant options in Router Advertisements, after they are processed and validated by the kernel. Extra options are processed in a generic way; this patch only exports RDNSS options described in RFC5006, but support to control which options are exported could be easily added.
I basically like this approach at first sight.
Quoted 10 lines
which implies that a userland daemon processing RDNSS options needs a way to associate the option to the router that sent it, and fetch its lifetime. This kind of information could be included in a header in the rtnetlink message (in this version of the patch there is none).
include/linux/rtnetlink.h +0
-0
include/linux/rtnetlink.h enum { · line 103
Quoted 7 lines
include/linux/rtnetlink.h +3
-0@@ -97,6 +97,9 @@ enum { RTM_SETNEIGHTBL,#define RTM_SETNEIGHTBL RTM_SETNEIGHTBL + RTM_NEWNDUSEROPT = 68, +#define RTM_NEWNDUSEROPT RTM_NEWNDUSEROPT + __RTM_MAX,
Does this imply that we could extend (or reuse) this for all of NS/NA/RS/RA/Redirect messages? I think you need to include the code, type and basic semantics of the message.
If this is only for RA, we should say "RTM_NEWRAUSEROPT" or something.
Regards,
--yoshfuji