From: Andrea Mayer <andrea.mayer@uniroma2.it>
To: netdev@vger.kernel.org
Cc: "David S . Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Stefano Salsano <stefano.salsano@uniroma2.it>,
Paolo Lungaroni <paolo.lungaroni@uniroma2.it>,
Ahmed Abdelsalam <ahabdels@cisco.com>,
Justin Iurman <justin.iurman@6wind.com>,
linux-kernel@vger.kernel.org,
Andrea Mayer <andrea.mayer@uniroma2.it>
Subject: [RFC PATCH net-next 0/3] seg6: SRv6 L2 VPN with End.DT2U and srl2 device
Date: Sun, 22 Mar 2026 01:05:54 +0100 [thread overview]
Message-ID: <20260322000557.12559-1-andrea.mayer@uniroma2.it> (raw)
Hi all,
this RFC series adds support for the SRv6 End.DT2U behavior and
introduces the srl2 Ethernet pseudowire device, together with
corresponding selftests.
Motivation
==========
The main goal is to enable L2 service delivery through an internal
SRv6 L2 endpoint, in a way similar to how VXLAN provides L2 services
through a VXLAN netdevice.
Today, Linux supports SRv6 L2 decapsulation only through an
End.DX2-style model, where the exposed Ethernet frame is forwarded
to a configured egress interface. The current implementation does
not provide a native netdevice representing the SRv6 L2 service
endpoint. This is a significant limitation compared to VXLAN, where
the tunnel endpoint is represented by a netdevice that can be
attached to a bridge and integrated naturally into the local L2
data plane.
On the encapsulation side, the existing H.L2.Encaps mode is
implemented as a route-based lwtunnel, which only intercepts packets
entering the IP routing path. Non-IP protocols such as ARP are
never routed and therefore cannot be encapsulated, making it
unsuitable for full L2 service delivery.
Design
======
This series addresses that limitation by introducing srl2, a native
SRv6 L2 endpoint interface. The intent is to make SRv6 L2 delivery
usable in the same deployment model already familiar from VXLAN: an
internal interface that represents the L2 service endpoint and can
participate naturally in local L2 forwarding.
On top of that, the series adds support for End.DT2U so that Ethernet
payloads carried over SRv6 can be decapsulated and delivered into an
L2 domain through either a bridge port or an srl2 interface.
Relation to RFC 8986
====================
RFC 8986 describes End.DT2U in terms of an abstract L2 table
associated with the SID. That abstraction specifies the externally
observable forwarding behavior of the node, but it does not mandate a
specific internal implementation. What matters is functional
equivalence.
This series enforces that property by restricting valid End.DT2U
decapsulation targets to endpoints that provide the required L2
forwarding semantics by construction.
When the target device is a bridge port, the Linux bridge provides
the expected behavior directly: source MAC learning, destination MAC
lookup, and unknown-unicast flooding within the corresponding L2
domain.
When the target device is an srl2 interface, the same model is
realized in a degenerate but valid form, corresponding to a minimal
two-port L2 domain in which one endpoint is srl2. In that case,
forwarding is trivial: frames are delivered to srl2 only when
addressed to its MAC address, or when they are broadcast or multicast.
No general FDB is required in this case because there are no
additional L2 destinations to learn.
Any other type of decapsulation target is rejected at configuration
time, since it would not guarantee the forwarding behavior required by
End.DT2U.
The srl2 device is the minimal baseline implementation providing
point-to-point L2 encapsulation with a single segment list.
Additional features can be added incrementally based on community
feedback and use cases.
Usage
=====
ip link add srl2-0 type srl2 segs fc00::a,fc00::b
ip link set srl2-0 master br0
ip -6 route add fc00::100/128 encap seg6local action End.DT2U \
l2dev srl2-0 dev dum0
# encapsulating traffic from veth-hs into srl2-0
ip link set veth-hs master br0
Selftest topology
=================
cafe::1 cafe::2
10.0.0.1 10.0.0.2
+--------+ +--------+
| hs-1 | | hs-2 |
+---+----+ +----+---+
| |
+-----+------+ +------+-----+
| veth-hs | | veth-hs |
| | | fcf0:0:1:2::/64 | | |
| br0 +-------------------------+ br0 |
| | | | | |
| srl2-0 | | srl2-0 |
| rt-1 | | rt-2 |
+------------+ +------------+
The test verifies IPv4/IPv6 host-to-host and host-to-gateway
connectivity over the SRv6 L2 VPN, including ARP resolution
through the tunnel.
A companion iproute2 series provides userspace support:
[RFC PATCH iproute2-next 0/4] seg6: add SRv6 End.DT2U and srl2 support
This is an RFC posting to collect feedback on both the overall design
and the userspace API before moving forward with a formal submission.
Comments are very welcome, especially on:
- the introduction of srl2 as an internal SRv6 L2 endpoint
- the choice of constraining End.DT2U targets to bridge ports
and srl2 devices
- the netlink/uAPI exposure
- the selftest coverage and topology
Thanks,
Andrea and Stefano
Andrea Mayer (3):
seg6: add support for the SRv6 End.DT2U behavior
seg6: add SRv6 L2 tunnel device (srl2)
selftests: seg6: add SRv6 srl2 + End.DT2U L2 VPN test
include/linux/srl2.h | 7 +
include/uapi/linux/seg6_local.h | 3 +
include/uapi/linux/srl2.h | 20 +
net/ipv6/Kconfig | 16 +
net/ipv6/Makefile | 1 +
net/ipv6/seg6.c | 1 +
net/ipv6/seg6_local.c | 160 ++++-
net/ipv6/srl2.c | 269 ++++++++
tools/testing/selftests/net/Makefile | 1 +
tools/testing/selftests/net/config | 1 +
.../selftests/net/srv6_srl2_l2vpn_test.sh | 621 ++++++++++++++++++
11 files changed, 1094 insertions(+), 6 deletions(-)
create mode 100644 include/linux/srl2.h
create mode 100644 include/uapi/linux/srl2.h
create mode 100644 net/ipv6/srl2.c
create mode 100755 tools/testing/selftests/net/srv6_srl2_l2vpn_test.sh
--
2.20.1
next reply other threads:[~2026-03-22 0:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-22 0:05 Andrea Mayer [this message]
2026-03-22 0:05 ` [RFC PATCH net-next 1/3] seg6: add support for the SRv6 End.DT2U behavior Andrea Mayer
2026-03-22 0:05 ` [RFC PATCH net-next 2/3] seg6: add SRv6 L2 tunnel device (srl2) Andrea Mayer
2026-03-24 16:08 ` Justin Iurman
2026-03-24 16:24 ` Justin Iurman
2026-03-25 13:43 ` Justin Iurman
2026-03-22 0:05 ` [RFC PATCH net-next 3/3] selftests: seg6: add SRv6 srl2 + End.DT2U L2 VPN test Andrea Mayer
2026-03-24 16:00 ` [RFC PATCH net-next 0/3] seg6: SRv6 L2 VPN with End.DT2U and srl2 device Justin Iurman
2026-03-25 7:10 ` Stefano Salsano
2026-03-25 8:35 ` Justin Iurman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260322000557.12559-1-andrea.mayer@uniroma2.it \
--to=andrea.mayer@uniroma2.it \
--cc=ahabdels@cisco.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=justin.iurman@6wind.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paolo.lungaroni@uniroma2.it \
--cc=stefano.salsano@uniroma2.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox