Thread (7 messages) flat view 7 messages, 2 authors, 2021-08-27

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

From: Justin Iurman <hidden>
Date: 2021-08-27 07:51:44

[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. 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).

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help