IPv6: RTM_GETROUTE NLM_F_MATCH handled as stated in RFC 3549

Hi Dee Ho!

RFC 3549 states:

Additional flag bits for GET requests on config information in
the FEC.
NLM_F_ROOT Return the complete table instead of a
single entry.
NLM_F_MATCH Return all entries matching criteria passed in
message content.
NLM_F_ATOMIC Return an atomic snapshot of the table being
referenced. This may require special privileges because it has the potential to interrupt service in the FE for a longer time.

Convenience macros for flag bits:
NLM_F_DUMP This is NLM_F_ROOT or'ed with NLM_F_MATCH

However, currently requests with NLM_F_ROOT or NLM_F_MATCH or both (NLM_F_DUMP) specified will return all the (routing) entries.

To me it sounds that the NLM_F_MATCH was originally meant to allow user to ask only entries (routes) fulfilling conditions given in request. This would further simplify userland applications which need to get only certain entries - and I believe that is often the case. I believe the current operation which differs from RFC makes netlink socket usage even more confusing. (There really is not too much up-to-date documentation telling how these requests+all the attributes work).

This patch makes ipv6 module to return only routes which match attributes / filled fields in RTM_GETROUTE, if NLM_F_MATCH is specified and NLM_F_ROOT is not. This patch has not been tested, and is meant more to be for visualization of what I thought of doing. If the NLM_F_MATCH support is considered to be good idea, then I will check this more thoroughly and send another patch.

I assume this would not break *many* existing userspace applications, since specifying NLM_F_MATCH (especially with no NLM_F_ROOT) sounds pretty stupid - if no entries should be filtered.

I checked iproute2, and it uses NLM_F_DUMP and does filtering entries in userspace - thus it is not affected.

I guess this same idea could be brought in RTM_GETADDR and RTM_GETLINK too? Maybe also on IPv4 side?

Any comments?

This patch demonstrates how RTM_GETROUTE request behaviour for IPv6 could be changed to better match RFC 3549 when NLM_F_MATCH flag is specified.

"NLM_F_MATCH Return all entries matching criteria passed in
message content."

---

index 2ad92ca..27313ad 100644
@@ -139,12 +139,21 @@ extern void			rt6_pmtu_discovery(const struct in6_addr *daddr,
 struct netlink_callback;
 
 struct rt6_rtnl_dump_arg {
+	long maxtbl;
 	struct sk_buff *skb;
 	struct netlink_callback *cb;
 	struct net *net;
 };
+struct rt6_rtnl_match_arg {
+	long maxtbl;
+	struct sk_buff *skb;
+	struct netlink_callback *cb;
+	struct net *net;
+	struct fib6_config *cfg;
+};
 
 extern int rt6_dump_route(struct rt6_info *rt, void *p_arg);
+extern int rt6_dump_route_if_match(struct rt6_info *rt, void *p_arg);
 extern void rt6_ifdown(struct net *net, struct net_device *dev);
 extern void rt6_mtu_change(struct net_device *dev, unsigned mtu);
 extern void rt6_remove_prefsrc(struct inet6_ifaddr *ifp);

From: Matti Vaittinen <[email protected]>
Date: Wed, 28 Dec 2011 16:01:55 +0200

The problem is that you can't avoid writing the user level filters even if we add this behavior now.

Any tool which wants to work on every single Linux system out there right now has to accomodate the case where NLM_F_MATCH isn't done by the kernel. It will take several years before this would be widely deployed even if it went in right now.

This means applications are not simplified at all, in fact they become more complex, since they have to accomodate not just one but two possible cases.

Specifying this behavior in RFC 3549 is pretty pointless, given the existing situation.

So the value proposition of adding this change doesn't add up to me.

I'm therefore not inclined to apply a patch like this, sorry. And even if I was, I'd ask that ipv4 get it first or at the same time.

I can't argue. Like Metallica sang, "Sad but true".

No need to be sorry. I guess I can live with this ;) Thanks for closing the case.

--Matti

Matti Vaittinen
+358 504863070
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Told a UDP joke the other night...
...but I'm not sure everyone got it...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~