Skip to contentSkip to conversation

Export userland ND options through netlink (RDNSS support)

RFC In review Pierre Ynard 2 participants 2 messages Sep 29, 2007 – Oct 1, 2007

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

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
index dff3192..f69d415 100644
@@ -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
index 475b10c..6684f7e 100644
@@ -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."
#1 lore raw

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
index dff3192..f69d415 100644

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