Re: [RFC net-next] ipv6: Support for anonymous tunnel decapsulation

quoted

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

My bad, I missed the condition at the end and didn't test it. Indeed, you're correct.

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

quoted

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.

Totally agree, I know this is usually not ideal, especially now that I know ip6_tunnel can already do the job without tunnel configurations. The only "downside" is that you need the ip6_tunnel module but that's fine. Thanks for the feedback and clarification.