Re: [PATCH net-next v2] seg6: add per-route tunnel source address

[Andrea Mayer <andrea.mayer@uniroma2.it>]

Hi Justin, Nicolas,

First of all, thanks both for the discussion on the link-local addresses.

On Fri, 13 Mar 2026 14:06:26 +0000
Justin Iurman <justin.iurman@6wind.com> wrote:

> On Fri, Mar 13, 2026 at 10:59 AM Nicolas Dichtel
> <nicolas.dichtel@6wind.com> wrote:
> >
> > Le 13/03/2026 à 11:20, Justin Iurman a écrit :
> > > On Fri, Mar 13, 2026 at 9:47 AM Nicolas Dichtel
> > > <nicolas.dichtel@6wind.com> wrote:
> > >>
> > >> Le 13/03/2026 à 09:44, Justin Iurman a écrit :
> > >>> On Fri, Mar 13, 2026 at 2:02 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote:
> > >>>>
> > >>>> On Wed, 11 Mar 2026 16:28:45 +0100
> > >>>> Justin Iurman <justin.iurman@6wind.com> wrote:
> > >>
> > >
> > > [snip]
> > >
> > >>>> Whether to also reject link-local is debatable: ip6_forward() does
> > >>>> drop it, but is there a legitimate use case where a link-local tunnel
> > >>>> source would actually be needed?!
> > >>>> I'd argue we should reject link-local addresses as well.
> > >>>> For instance, using them as a tunnel source violates scope boundaries and
> > >>>> breaks ICMPv6 error reporting.
> > >>>
> > >>> IMHO, I also think we could reasonably forbid LLs.
> > >>
> > >> Why rejecting LL? It's legal to use LL as a source address of a tunnel (and
> > >> forwarding packets in this tunnel). Is this forbidden with srv6?
> > >
> > > Well, this is indeed legal (at least nothing prevents it), but they're
> > > not routable. So question is does it make sense at all? We're talking
> > > about two nodes on the same layer-2 link as the only valid use-case
> > > here. I'm not sure it makes sense, especially in the context of SRv6.
> > Yes, you're probably right. I'm usually uncomfortable with a configuration being
> > forbidden without any real problem/reason.
> 
> After consideration, it looks like ip6_forward() does filter LL source
> addresses (see [1]), so such packets are never forwarded and there is
> no violation of scope boundaries. I agree it makes little sense to
> allow LL source addresses in the context of SRv6, but Nicolas has a
> point too (i.e., it's not harmful, let's not restrict things
> unnecessarily). I guess both ways are fine, maybe others can shim in
> and share their opinions. For v3, I'll just keep it as is, we can
> still make a change later.
> 
>  [1] https://elixir.bootlin.com/linux/v6.19.7/source/net/ipv6/ip6_output.c#L643

Justin, the ip6_forward() check is exactly the drop behavior I was referring
to. My initial concern was architectural, since a router wouldn't forward a
packet with a LL source anyway.

Nicolas, you make a fair point: nothing explicitly forbids using it.
I initially raised the question just to be on the safe side from the very
beginning and figure out the best path forward.
While it is a niche scenario, there can indeed exist valid use cases
(e.g., a host doing SRv6 encap with a LL source, sending it to a
directly connected SRv6 router that simply applies a decap behavior).

Since it doesn't harm the kernel, I agree we shouldn't artificially
forbid it. Allowing LLs in v3 is fine by me. Let's also see if anyone
else on the list has further thoughts on this.



Justin, regarding the other questions from your previous email about
selftests:
 
On Fri, 13 Mar 2026 08:44:04 +0000
Justin Iurman <justin.iurman@6wind.com> wrote:

> On Fri, Mar 13, 2026 at 2:02 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote:
> >
> > On Wed, 11 Mar 2026 16:28:45 +0100
> > Justin Iurman <justin.iurman@6wind.com> wrote:
> >
> > > Add SEG6_IPTUNNEL_SRC in the uapi for users to configure a specific
> > > tunnel source address. Make seg6_iptunnel handle the new attribute
> > > correctly. It has priority over the configured per-netns tunnel
> > > source address, if any.
> > >
> > > Signed-off-by: Justin Iurman <justin.iurman@6wind.com>
> > > ---
> [snip]
> 
> I agree. The reason why I did not is simply that, IIRC, none of the
> srv6 selftests actually check the source address ("ip sr tunsrc set
> xxx" is not even used, and dynamic resolution is the default
> behavior). Note that the source address is specifically checked in
> ioam6 selftest though (packet capture + parsing), but srv6 selftests
> are not designed the same way. What I suggest is to not overcomplicate
> things and simply modify srv6_hencap_red_l3vpn_test.sh and
> srv6_hl2encap_red_l2vpn_test.sh to include a test that does encap with
> "tunsrc" (and we could also add the same with "ip sr tunsrc set xxx").
> It wouldn't check for a specific source address though, would just
> make sure connectivity doesn't break like for other tests. Also, the
> other question is should we duplicate all tests for those cases: with
> "ip sr tunsrc set xxx", and with "tunsrc". WDYT?

To answer your questions:

1) Just checking for connectivity might not be sufficient here. If an
   issue causes the kernel to fall back to the default interface IP, a
   simple ping would still succeed, giving us a false positive. To verify
   the actual outer source address without overcomplicating things, we
   could maybe use policy routing (ip -6 rule) or a simple ip6tables/nftables
   rule on the receiving netns to drop the probe (ping) packet if its source
   address doesn't match the expected tunsrc.
   This is just a suggestion, of course; if you want, we can sync offline
   on this to figure out the best way to handle the selftest.

2) I don't think we need to duplicate the tests right now. We can
   consider extending the per-route tunsrc selftest to also cover the
   per-netns tunsrc later, when we start working on that specific
   per-netns fix.

>
> [snip]
>
> I agree. We could synchronize offline to squash the same fix for ioam6_iptunnel.

Yes, for sure!

Thanks,
Andrea