Export userland ND options through netlink (RDNSS support)
Subsystems (3)
PATCH 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.
A new rtnetlink message type is defined, to transport Neighbor Discovery options, along with optional context information. At the moment only the address of the router sending an RDNSS option is included, but additional attributes may be later defined, if needed by new use cases.
include/linux/rtnetlink.h +29 -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) };
@@ -479,6 +482,30 @@ enum#define TCA_RTA (r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct tcmsg))))#define TCA_PAYLOAD (n) NLMSG_PAYLOAD(n,sizeof(struct tcmsg)) +/******************************************************************** +* Neighbor Discovery userland options +****/ + +struct nduseroptmsg +{ +unsigned char nduseropt_family; +unsigned char nduseropt_pad1; +unsigned short nduseropt_opts_len;/* Total length of options */ +__u8 nduseropt_icmp_type; +__u8 nduseropt_icmp_code; +unsigned short nduseropt_pad2; +/* Followed by one or more ND options */ +}; + +enum +{ +NDUSEROPT_UNSPEC , +NDUSEROPT_SRCADDR , + __NDUSEROPT_MAX +}; + +#define NDUSEROPT_MAX (__NDUSEROPT_MAX - 1) +#ifndef __KERNEL__/* RTnetlink multicast groups - backwards compatibility for userspace */ #define RTMGRP_LINK 1
@@ -542,6 +569,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 +94 -9
147 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."
David Miller
maintainerFrom: Pierre Ynard <[email protected]>
Date: Fri, 5 Oct 2007 08:09:30 +0200
Quoted 6 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.
Quoted 6 lines
A new rtnetlink message type is defined, to transport Neighbor Discovery options, along with optional context information. At the moment only the address of the router sending an RDNSS option is included, but additional attributes may be later defined, if needed by new use cases.
Signed-off-by Pierre Ynard <[email protected]>
This seems to include the changes Yoshifuji requested in your first submission, so I have applied this.
Thanks.
Quoted 10 lines · Pierre Ynard
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.
A new rtnetlink message type is defined, to transport Neighbor Discovery options, along with optional context information. At the moment only the address of the router sending an RDNSS option is included, but additional attributes may be later defined, if needed by new use cases.
RFC5006 §6.1 says:
Note: An RDNSS address MUST be used only as long as both the RA
router lifetime and the RDNSS option lifetime have not expired. The reason is that the RDNSS may not be currently reachable or may not provide service to the host's current address (e.g., due to network ingress filtering [16][17]).
But when this option makes its way to userspace, we don't *know* the RA router lifetime, or even which interface it came in on. I'm not sure how we can use this correctly.
This is a start at using it in ConnMan... but unless I'm missing something, we don't have enough information to do it properly:
http://lists.connman.net/pipermail/connman/2010-December/002781.html
Signature · 2 lines
David Woodhouse Open Source Technology Centre [email protected] Intel Corporation