Re: [RFC net-next] ipv6: Support for anonymous tunnel decapsulation
From: Nicolas Dichtel <hidden>
Date: 2021-08-27 08:20:44
Le 27/08/2021 à 09:51, Justin Iurman a écrit :
quoted
[snip]quoted
quoted
quoted
Thoughts?I'm not sure to understand why the current code isn't enough. The fallback tunnels created by legacy IP tunnels drivers are able to receive and decapsulate any encapsulated packets.Because, right now, you need to use the ip6_tunnel module and explicitly configure a tunnel, as you described below. The goal of this patch is to provide a way to apply an ip6ip6 decapsulation *without* having to configure a tunnel.What is the difference between setting a sysctl somewhere and putting an interface up?Well, correct me if I'm wrong but, it's more than just putting an interface up. You'd first need ip6_tunnel (and so tunnel6) module loaded, but you'd also need to configure a tunnel on the decap node.
No, you just need to have the module. The fallback device is automatically created. And if the module is built-in, there is nothing to do. Indeed, the current ip6_tunnel fallback handler only works if a tunnel matches the packet (i.e., ipxip6_rcv will return -1 since ip6_tnl_lookup will return NULL, leading to *no* decapsulation from this handler). No. ip6_tnl_lookup() won't return NULL if the fallback device exists and is up. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/ip6_tunnel.c#n168 The tunnels lookup algorithm has several steps: - try to match local and remote addr - try to match only local addr - try to match only dst addr - return the lwt tunnel if it exists - return the fallback device if it exists and is up https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/ip6_tunnel.c#n100 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/sit.c#n96 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/ip_tunnel.c#n72
So, again, think about the case where you have lots of ingresses and egresses that should be linked (= a tunnel for each pair) altogether in a domain. You'd need to configure N tunnels on the decap node, where N is the number of ingresses. Well, actually no, you could just configure one tunnel with "remote any", but you'd still depend on the ip6_tunnel module and play with tunnel configuration and its interface. This patch provides a way to avoid that by just enabling the ip6ip6 decapsulation through a per interface sysctl.
I don't understand the problem of depending to the ip6_tunnel module. Duplicating a subset of the existing code to avoid a dependency to an existing module seems a bad idea for me, from a maintenance point of view. Regards, Nicolas