This series adds the in-kernel data path for the SRv6 Mobile User
Plane (MUP) architecture defined in RFC 9433.  SRv6 MUP integrates
GTP-U mobile traffic into an SRv6 transport domain by mapping the
5-tuple (TEID, QFI, R, U, PDU Session ID) into a single SID, allowing
operators to replace the GTP-U overlay between the gNB and the
upstream UPF with native SRv6 forwarding while keeping the radio side
unchanged.

The series implements the six MUP behaviors that an SRv6 MUP gateway
typically needs:

  End.MAP         (RFC 9433 Section 6.2) -- swap DA with the next SID
                                            without consuming the SRH
  End.M.GTP6.D    (Section 6.3) -- IPv6/GTP-U to SRv6 headend encap
  End.M.GTP6.D.Di (Section 6.4) -- drop-in mode variant of the above
                                   (preserves the original outer DA at
                                   SRH[0] and discards TEID/QFI)
  End.M.GTP6.E    (Section 6.5) -- SRv6 to IPv6/GTP-U egress encap
  End.M.GTP4.E    (Section 6.6) -- SRv6 to IPv4/GTP-U egress encap
  H.M.GTP4.D      (Section 6.7) -- IPv4/GTP-U to SRv6 headend encap

End.Limit (RFC 9433 Section 6.8) is intentionally out of scope.

All behaviors plug into the existing seg6_local lwtunnel framework, so
they are configurable through the standard "ip route ... encap
seg6local action ..." interface.  No new netlink families are
introduced -- the new SEG6_LOCAL_MOBILE_* attributes extend
SEG6_LOCAL_MAX in an add-only way, and the new SEG6_LOCAL_ACTION_*
values are appended.

The egress behaviors (End.M.GTP4.E and End.M.GTP6.E) accept an
optional per-route pdu_type attribute that is the sole control
for inserting the GTP-U PDU Session Container (3GPP TS 38.415 Section
5.5.2).  When pdu_type is set (dl/ul/0..15), every emitted GTP-U
packet carries the container with that PDU Type and the QFI extracted
from Args.Mob.Session.  When pdu_type is unset, the egress emits
a short GTPv1-U header with no container.  pdu_type must be
configured on egress routes serving 5G N3 traffic; omitting it is
intended only for LTE-only / S1-U-style deployments where no PDU
Session Container is exchanged.

The matching iproute2 patch series has been posted to iproute2-next:
https://lore.kernel.org/netdev/20260505-seg6-mobile-v2-0-93291b7b0134@gmail.com/

Link: https://www.rfc-editor.org/rfc/rfc9433

Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
---
Changes in v2 (all reported by netdev CI, except the End.MAP one
which was caught while reviewing v1):
- patch 1 (End.MAP): drop the explicit hop_limit decrement and
  the hop_limit <= 1 ICMPv6 Time Exceeded check; ip6_forward()
  on the way out already does both, so the explicit ones caused
  a double decrement (verified hlim=64 -> 62 instead of 63).
  Now consistent with End / End.X / End.M.GTP*.
- patch 3 (End.M.GTP6.E): add missing #include
  <net/ip6_checksum.h> to fix clang / allmodconfig build.
- selftests: silence shellcheck false positives (SC2034/SC2154)
  and sort TEST_PROGS entries alphabetically.
- Link to v1: https://lore.kernel.org/netdev/20260504-srv6-mup-v1-v1-0-e0a6791575cb@gmail.com

---
Yuya Kusakabe (7):
      seg6: add End.MAP behavior
      seg6: add End.M.GTP4.E behavior
      seg6: add End.M.GTP6.E behavior
      seg6: add End.M.GTP6.D behavior
      seg6: add End.M.GTP6.D.Di behavior
      seg6: add H.M.GTP4.D behavior
      Documentation: networking: add seg6_mobile guide

 Documentation/networking/index.rst                 |    1 +
 Documentation/networking/seg6_mobile.rst           |  236 ++
 include/net/dropreason-core.h                      |   40 +
 include/uapi/linux/seg6_local.h                    |   17 +
 net/ipv6/seg6_local.c                              | 2660 ++++++++++++++++++--
 tools/testing/selftests/net/Makefile               |    6 +
 .../selftests/net/srv6_end_m_gtp4_e_test.sh        |  486 ++++
 .../selftests/net/srv6_end_m_gtp6_d_di_test.sh     |  427 ++++
 .../selftests/net/srv6_end_m_gtp6_d_test.sh        |  497 ++++
 .../selftests/net/srv6_end_m_gtp6_e_test.sh        |  402 +++
 tools/testing/selftests/net/srv6_end_map_test.sh   |  103 +
 .../testing/selftests/net/srv6_h_m_gtp4_d_test.sh  |  487 ++++
 12 files changed, 5155 insertions(+), 207 deletions(-)
---
base-commit: 98878ed91b68a3150126fccef125ee7b1bb86ab2
change-id: 20260504-seg6-mobile-f78e282e615c

Best regards,
--  
Yuya Kusakabe <yuya.kusakabe@gmail.com>

On Tue, 05 May 2026 01:30:10 +0900
Yuya Kusakabe <yuya.kusakabe@gmail.com> wrote:

Hi Yuya,

Thanks for the work. Some comments on the overall design below. I will
reply on the individual patches separately.

> This series adds the in-kernel data path for the SRv6 Mobile User
> Plane (MUP) architecture defined in RFC 9433.  SRv6 MUP integrates
> GTP-U mobile traffic into an SRv6 transport domain by mapping the
> 5-tuple (TEID, QFI, R, U, PDU Session ID) into a single SID, allowing
> operators to replace the GTP-U overlay between the gNB and the
> upstream UPF with native SRv6 forwarding while keeping the radio side
> unchanged.
>
> The series implements the six MUP behaviors that an SRv6 MUP gateway
> typically needs:
>
>   End.MAP         (RFC 9433 Section 6.2) -- swap DA with the next SID
>                                             without consuming the SRH
>   End.M.GTP6.D    (Section 6.3) -- IPv6/GTP-U to SRv6 headend encap
>   End.M.GTP6.D.Di (Section 6.4) -- drop-in mode variant of the above
>                                    (preserves the original outer DA at
>                                    SRH[0] and discards TEID/QFI)
>   End.M.GTP6.E    (Section 6.5) -- SRv6 to IPv6/GTP-U egress encap
>   End.M.GTP4.E    (Section 6.6) -- SRv6 to IPv4/GTP-U egress encap
>   H.M.GTP4.D      (Section 6.7) -- IPv4/GTP-U to SRv6 headend encap

RFC 9433 Section 6 is titled "SRv6 Segment Endpoint Mobility Behaviors",
but Section 6.7 defines H.M.GTP4.D as "SR Policy Headend with tunnel
decapsulation and map to an SRv6 policy". This behavior receives IPv4
packets and is not bound to any SID, so it does not fit the endpoint
model that seg6_local implements. Placing it there required relaxing the
ETH_P_IPV6 guard to accept ETH_P_IP and adding input_family to
seg6_action_desc, for a single behavior that does not share the endpoint
model.

seg6_local is not the natural place for this behavior. The UAPI cannot
be undone once merged, so where it should live needs discussion on the
list before we proceed.

>
> End.Limit (RFC 9433 Section 6.8) is intentionally out of scope.

>
> All behaviors plug into the existing seg6_local lwtunnel framework, so
> they are configurable through the standard "ip route ... encap
> seg6local action ..." interface.

This adds ~2.2k lines to seg6_local.c, bringing it from ~2.7k to ~5k
lines. The behaviors reuse the existing seg6_local infrastructure (SRH
validation, seg6_do_srh_encap, seg6_lookup_nexthop), while the GTP-U
parsing, encapsulation, and PDU Session handling, for example, is new
and self-contained. Given the volume, moving the MUP code into a
separate seg6_mobile.c (say CONFIG_IPV6_SEG6_MUP) would keep seg6_local
focused on the RFC 8986 endpoint framework. There are trade-offs
either way and I think this deserves discussion on the list.

There is significant duplication across the introduced behaviors: for
example the GTP-U parsing, inner protocol dispatch, and NF_HOOK plumbing
are nearly identical each time, and the small differences are already
hiding issues (HMAC validation missing in some, malformed SRH silently
accepted in others, wrong drop reasons). Some of the individual
functions are also well over 100 lines. Splitting them with helpers
would help.
The new code also has some style drift from seg6_local.c (variable
declaration ordering, scope blocks, blank lines) that should be fixed.

I think this patchset should be broken into smaller patchsets, one per
behavior, each with the behavior, its selftest, and any needed helpers as
separate patches. The same approach was used for End.DT4/End.DT6 and
End.DT46. End.M.GTP4.E alone is ~1.2k lines in a single diff.

> No new netlink families are
> introduced -- the new SEG6_LOCAL_MOBILE_* attributes extend
> SEG6_LOCAL_MAX in an add-only way, and the new SEG6_LOCAL_ACTION_*
> values are appended.

The attribute layout and semantics are probably the most sensitive part
of the series and need to be settled before it can go in, since the UAPI
cannot be changed once merged.

The series reuses SEG6_LOCAL_NH6, SEG6_LOCAL_SRH and SEG6_LOCAL_OIF with
semantics that differ from the existing behaviors. NH6 today means
next-hop in End.X/DX6. This series reuses it as DA replacement in
End.MAP and as prefix template in H.M.GTP4.D.
SRH is inserted verbatim in End.B6/B6.Encaps but augmented per-packet in
the mobile behaviors. These attributes have established UAPI semantics
from their existing behaviors. Giving them a different meaning in new
behaviors is a UAPI semantic divergence.

The selftests use OIF on all five GTP behaviors to select a VRF for the
lookup, but that is what TABLE and VRFTABLE are for (End.DT4, End.DT6).
OIF in the existing behaviors means output interface (End.X) or L2
egress device (End.DX2). VRF support is a nice-to-have that can be added
later as a separate optional attribute.

>
> The egress behaviors (End.M.GTP4.E and End.M.GTP6.E) accept an
> optional per-route pdu_type attribute that is the sole control
> for inserting the GTP-U PDU Session Container (3GPP TS 38.415 Section
> 5.5.2).  When pdu_type is set (dl/ul/0..15), every emitted GTP-U
> packet carries the container with that PDU Type and the QFI extracted
> from Args.Mob.Session.  When pdu_type is unset, the egress emits
> a short GTPv1-U header with no container.  pdu_type must be
> configured on egress routes serving 5G N3 traffic; omitting it is
> intended only for LTE-only / S1-U-style deployments where no PDU
> Session Container is exchanged.
>
> The matching iproute2 patch series has been posted to iproute2-next:
> https://lore.kernel.org/netdev/20260505-seg6-mobile-v2-0-93291b7b0134@gmail.com/

The user-facing parameter names and their semantics are defined in the
iproute2 series (where the man page lives), so that is probably the
better place to discuss keyword choices and attribute naming.

> [snip]
>  include/net/dropreason-core.h                      |   40 +

The series introduces six mobile-specific drop reasons. Drop reasons are
visible to userspace via the kfree_skb tracepoint (perf, bpftrace,
dropwatch), so they look like a kind of interface and their names should
match the actual failure.

BAD_SID and BAD_GTPU make sense as mobile-specific reasons. The other
four have issues: NOMEM and MTU_EXCEEDED duplicate existing generic
reasons (NOMEM and PKT_TOO_BIG). INVALID_SRH_SL is used for multiple SRH
validation failures, not just Segments Left (HMAC failure is also
reported as INVALID_SRH_SL). BAD_INNER is used as a catch-all for outer
header pull failures and encapsulation errors, neither of which involves
the inner payload.

We could think about a prep patch introducing SRv6-level drop reasons
(SEG6_INVALID_SRH, SEG6_HMAC, etc.) that both the existing behaviors and
the MUP ones can share.

> [snip]
>  .../selftests/net/srv6_end_m_gtp4_e_test.sh        |  486 ++++
>  .../selftests/net/srv6_end_m_gtp6_d_di_test.sh     |  427 ++++
>  .../selftests/net/srv6_end_m_gtp6_d_test.sh        |  497 ++++
>  .../selftests/net/srv6_end_m_gtp6_e_test.sh        |  402 +++
>  tools/testing/selftests/net/srv6_end_map_test.sh   |  103 +
>  .../testing/selftests/net/srv6_h_m_gtp4_d_test.sh  |  487 ++++

Selftests for the five GTP behaviors heavily depend on python3 and scapy
heredocs embedded in the shell scripts for packet construction and
validation, which adds an external runtime dependency. A statically
compiled C helper would remove it and avoid embedding python heredocs
in shell scripts.
A few cases worth covering: SRH and no-SRH input paths where the
behavior accepts both, missing SRH where the behavior requires
it, malformed SRH, and invalid attribute values.

The five GTP behaviors pass per-packet context to a finish callback through
skb->cb, and recover the lwtstate via skb_dst(skb)->lwtstate.
When nf_hooks_lwtunnel is enabled, an NF_HOOK sits between the input
handler and the finish callback. Netfilter processing at this hook can then
corrupt the cb (IPCB/IP6CB aliases skb->cb) or drop/replace the skb dst, so
the finish callback dereferences a NULL or unrelated dst.
Even if the dst is preserved, the cb may have been modified.

The dst problem is pre-existing from 7a3f5b0de364 ("netfilter: add
netfilter hooks to SRv6 data plane") and affects seg6_iptunnel too. Both
issues need a robust fix before this series can go in. I want to look at
this myself and will Cc you when I do, as the five new behaviors may need
to be adjusted on top.

> [snip]

> Best regards,
> --
> Yuya Kusakabe <yuya.kusakabe@gmail.com>

Ciao,
Andrea

On Sun, May 17, 2026 at 1:26 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote:
> RFC 9433 Section 6 is titled "SRv6 Segment Endpoint Mobility Behaviors",
> but Section 6.7 defines H.M.GTP4.D as "SR Policy Headend with tunnel
> decapsulation and map to an SRv6 policy". This behavior receives IPv4
> packets and is not bound to any SID, so it does not fit the endpoint
> model that seg6_local implements. Placing it there required relaxing the
> ETH_P_IPV6 guard to accept ETH_P_IP and adding input_family to
> seg6_action_desc, for a single behavior that does not share the endpoint
> model.
>
> seg6_local is not the natural place for this behavior. The UAPI cannot
> be undone once merged, so where it should live needs discussion on the
> list before we proceed.
>
> Given the volume, moving the MUP code into a separate seg6_mobile.c
> (say CONFIG_IPV6_SEG6_MUP) would keep seg6_local focused on the RFC
> 8986 endpoint framework.

I will move the MUP code out of seg6_local into a new
net/ipv6/seg6_mobile.c under a new Kconfig symbol, and register the
behaviors under a new lwtunnel encap type rather than
LWTUNNEL_ENCAP_SEG6_LOCAL.

For naming I was thinking CONFIG_IPV6_SEG6_MOBILE and
LWTUNNEL_ENCAP_SEG6_MOBILE to match the file name, but I have no strong
preference over CONFIG_IPV6_SEG6_MUP if the list prefers that.

Once LWTUNNEL_ENCAP_SEG6_MOBILE is its own encap type, it feels
natural to me to put H.M.GTP4.D there too rather than adding a
separate LWTUNNEL_ENCAP_SEG6_MOBILE_HEADEND. What do you think?

> I think this patchset should be broken into smaller patchsets, one per
> behavior, each with the behavior, its selftest, and any needed helpers as
> separate patches. The same approach was used for End.DT4/End.DT6 and
> End.DT46. End.M.GTP4.E alone is ~1.2k lines in a single diff.

Will do, following the End.DT4/End.DT6/End.DT46 model: one patchset
per behavior, with the behavior, helpers, and selftest as separate
patches. The new code will be aligned with seg6_local.c style as
part of this rework.

> The series reuses SEG6_LOCAL_NH6, SEG6_LOCAL_SRH and SEG6_LOCAL_OIF with
> semantics that differ from the existing behaviors. NH6 today means
> next-hop in End.X/DX6. This series reuses it as DA replacement in
> End.MAP and as prefix template in H.M.GTP4.D.
> SRH is inserted verbatim in End.B6/B6.Encaps but augmented per-packet in
> the mobile behaviors. These attributes have established UAPI semantics
> from their existing behaviors. Giving them a different meaning in new
> behaviors is a UAPI semantic divergence.

The mobile behaviors will define their own SEG6_MOBILE_* attribute
namespace under LWTUNNEL_ENCAP_SEG6_MOBILE, with no reuse of any
SEG6_LOCAL_* attribute. That keeps the established SEG6_LOCAL_*
semantics untouched.

> The selftests use OIF on all five GTP behaviors to select a VRF for the
> lookup, but that is what TABLE and VRFTABLE are for (End.DT4, End.DT6).
> OIF in the existing behaviors means output interface (End.X) or L2
> egress device (End.DX2). VRF support is a nice-to-have that can be added
> later as a separate optional attribute.

I will drop VRF support from the initial behaviors and revisit it
later as a separate optional attribute.

> The user-facing parameter names and their semantics are defined in the
> iproute2 series (where the man page lives), so that is probably the
> better place to discuss keyword choices and attribute naming.

Thanks for the pointer.

> We could think about a prep patch introducing SRv6-level drop reasons
> (SEG6_INVALID_SRH, SEG6_HMAC, etc.) that both the existing behaviors and
> the MUP ones can share.

Good idea. The prep patchset would introduce the SRv6-level reasons
(SEG6_INVALID_SRH, SEG6_HMAC, ...) and convert the existing seg6_local
and seg6_iptunnel call sites to use them. The mobile-specific reasons
(BAD_SID, BAD_GTPU) would then be added together with the first
behavior that uses them and reused by subsequent behaviors. NOMEM and
MTU_EXCEEDED would be dropped in favor of the existing generic
reasons, and the current INVALID_SRH_SL / BAD_INNER misuses would be
replaced by the new SRv6-level reasons from the prep patchset.

Would you prefer to lead on the prep patchset yourself, or would you
like me to prepare it?

> Selftests for the five GTP behaviors heavily depend on python3 and scapy
> heredocs embedded in the shell scripts for packet construction and
> validation, which adds an external runtime dependency. A statically
> compiled C helper would remove it and avoid embedding python heredocs
> in shell scripts.
> A few cases worth covering: SRH and no-SRH input paths where the
> behavior accepts both, missing SRH where the behavior requires
> it, malformed SRH, and invalid attribute values.

I will replace the python3/scapy heredocs with a statically compiled
C helper for packet construction and validation, and extend the
selftests to cover the cases you mention (SRH / no-SRH input paths,
missing SRH where required, malformed SRH, and invalid attribute
values).

> The dst problem is pre-existing from 7a3f5b0de364 ("netfilter: add
> netfilter hooks to SRv6 data plane") and affects seg6_iptunnel too. Both
> issues need a robust fix before this series can go in. I want to look at
> this myself and will Cc you when I do, as the five new behaviors may need
> to be adjusted on top.

Thanks for taking that on. Given the cb/dst issues you described, I
am inclined to drop NF_HOOK support from the initial mobile behaviors
and add it in a follow-up patchset once your fix lands. The initial
behaviors would then do a direct input -> output flow without the
cb-context/finish-callback pattern, which avoids the issues entirely
on day one and decouples this series from the pre-existing fix. Does
that work for you, or would you prefer NF_HOOK to be present from the
start and rebased on top of your fix?

Thanks,
Yuya

On Wed, 20 May 2026 12:12:08 +0900
Yuya Kusakabe <yuya.kusakabe@gmail.com> wrote:

Hi Yuya,

Thanks for the reply. Inline answers below.

> On Sun, May 17, 2026 at 1:26 AM Andrea Mayer <andrea.mayer@uniroma2.it>
> wrote:
>
> > RFC 9433 Section 6 is titled "SRv6 Segment Endpoint Mobility
> > Behaviors", but Section 6.7 defines H.M.GTP4.D as "SR Policy Headend
> > with tunnel decapsulation and map to an SRv6 policy". This behavior
> > receives IPv4 packets and is not bound to any SID, so it does not fit
> > the endpoint model that seg6_local implements. Placing it there
> > required relaxing the ETH_P_IPV6 guard to accept ETH_P_IP and adding
> > input_family to seg6_action_desc, for a single behavior that does not
> > share the endpoint model.
> >
> > seg6_local is not the natural place for this behavior. The UAPI cannot
> > be undone once merged, so where it should live needs discussion on the
> > list before we proceed.
> >
> > Given the volume, moving the MUP code into a separate seg6_mobile.c
> > (say CONFIG_IPV6_SEG6_MUP) would keep seg6_local focused on the RFC
> > 8986 endpoint framework.
>
> I will move the MUP code out of seg6_local into a new
> net/ipv6/seg6_mobile.c under a new Kconfig symbol, and register the
> behaviors under a new lwtunnel encap type rather than
> LWTUNNEL_ENCAP_SEG6_LOCAL.
>

On the placement, the new lwtunnel encap type you propose could be a way to
implement the seg6_mobile.c separation. Since this touches UAPI in
include/uapi/linux/lwtunnel.h beyond the SRv6 subsystem and cannot be
undone once merged, it needs careful design.

> For naming I was thinking CONFIG_IPV6_SEG6_MOBILE and
> LWTUNNEL_ENCAP_SEG6_MOBILE to match the file name, but I have no strong
> preference over CONFIG_IPV6_SEG6_MUP if the list prefers that.

On the Kconfig symbol I agree, CONFIG_IPV6_SEG6_MOBILE matches the RFC 9433
Section 6 terminology better than CONFIG_IPV6_SEG6_MUP. Section 6 is titled
"SRv6 Segment Endpoint Mobility Behaviors".

> Once LWTUNNEL_ENCAP_SEG6_MOBILE is its own encap type, it feels
> natural to me to put H.M.GTP4.D there too rather than adding a
> separate LWTUNNEL_ENCAP_SEG6_MOBILE_HEADEND. What do you think?

H.M.GTP4.D in v2 shares the SEG6_LOCAL_MOBILE_* attributes and processing
helpers with the End.M.* behaviors. A separate
LWTUNNEL_ENCAP_SEG6_MOBILE_HEADEND would require its own attribute set,
lwtunnel_encap_ops, and iproute2 parser, similar to the current
implementation of RFC 8986 in the kernel (seg6 and seg6local).

As far as I can see, RFC 9433 has only one Headend behavior, and no L2 or
reduced variants. So a single LWTUNNEL_ENCAP_SEG6_MOBILE handling both
End.M.* and H.M.GTP4.D could be viable if accepting both input families
(ETH_P_IPV6 for End.M.*, ETH_P_IP for H.M.GTP4.D) is treated as a design
choice of the new encap type, not a stretching of the seg6_local endpoint
processing model.

These trade-offs are worth weighing in the final design. The patchset
rework (shared helper functions, the layout of the new UAPI attributes,
etc.) feeds into this decision. Like the encap type above, this is a UAPI
choice and cannot be undone once merged. I think the lwtunnel direction
will need feedback and comments from its community and maintainers.

> Will do, following the End.DT4/End.DT6/End.DT46 model: one patchset
> per behavior, with the behavior, helpers, and selftest as separate
> patches. The new code will be aligned with seg6_local.c style as
> part of this rework.

Sounds good.

> The mobile behaviors will define their own SEG6_MOBILE_* attribute
> namespace under LWTUNNEL_ENCAP_SEG6_MOBILE, with no reuse of any
> SEG6_LOCAL_* attribute. That keeps the established SEG6_LOCAL_*
> semantics untouched.

If LWTUNNEL_ENCAP_SEG6_MOBILE is added, using SEG6_MOBILE_* attributes
instead of SEG6_LOCAL_* removes the NH6/SRH/OIF overload raised in v2.
After solving the above, additional issues remain in the patchset,
for example src is overloaded across MUP behaviors, and v4_mask_len
needs revision. These are independent of the lwtunnel decision.

> I will drop VRF support from the initial behaviors and revisit it
> later as a separate optional attribute.

OK.

> Good idea. The prep patchset would introduce the SRv6-level reasons
> (SEG6_INVALID_SRH, SEG6_HMAC, ...) and convert the existing
> seg6_local and seg6_iptunnel call sites to use them. The
> mobile-specific reasons (BAD_SID, BAD_GTPU) would then be added
> together with the first behavior that uses them and reused by
> subsequent behaviors. NOMEM and MTU_EXCEEDED would be dropped in
> favor of the existing generic reasons, and the current
> INVALID_SRH_SL / BAD_INNER misuses would be replaced by the new
> SRv6-level reasons from the prep patchset.
>
> Would you prefer to lead on the prep patchset yourself, or would you
> like me to prepare it?

I can lead it. I have been evaluating the SRv6 drop reasons with my
research group, alongside other pending SRv6 patches.

We can sync offline on which SRv6 reasons fit your MUP behaviors, which
v2 MUP-specific reasons would fit better as SRv6 or generic, and what
stays MUP-specific.

> I will replace the python3/scapy heredocs with a statically compiled
> C helper for packet construction and validation, and extend the
> selftests to cover the cases you mention (SRH / no-SRH input paths,
> missing SRH where required, malformed SRH, and invalid attribute
> values).

Thanks. Maybe also worth covering bad packets, like fragmented input or
malformed GTP-U extensions.

> Thanks for taking that on. Given the cb/dst issues you described, I
> am inclined to drop NF_HOOK support from the initial mobile
> behaviors and add it in a follow-up patchset once your fix lands.
> The initial behaviors would then do a direct input -> output flow
> without the cb-context/finish-callback pattern, which avoids the
> issues entirely on day one and decouples this series from the
> pre-existing fix. Does that work for you, or would you prefer
> NF_HOOK to be present from the start and rebased on top of your fix?

Works for me. What matters is that the upcoming patches are well structured
so NF_HOOK can be wired in cleanly in the follow-up.

I am already working on the fix.

Thanks,
Andrea

P.S. I am temporarily writing from another address due to a mail
delivery issue at my @uniroma2.it address. Please always Cc my default
andrea.mayer@uniroma2.it address on replies.

On Tue, 05 May 2026 01:30:10 +0900 Yuya Kusakabe wrote:
> This series adds the in-kernel data path for the SRv6 Mobile User
> Plane (MUP) architecture defined in RFC 9433.  SRv6 MUP integrates
> GTP-U mobile traffic into an SRv6 transport domain by mapping the
> 5-tuple (TEID, QFI, R, U, PDU Session ID) into a single SID, allowing
> operators to replace the GTP-U overlay between the gNB and the
> upstream UPF with native SRv6 forwarding while keeping the radio side
> unchanged.

Could you switch to posting this as an RFC until you gather some review
tags? Our CI require manual intervention to add the necessary iproute2
patches, I suspect there may be some uAPI changes therefore requiring
iproute2 changes here.

2026年5月5日火曜日 Jakub Kicinski <kuba@kernel.org>:
> Could you switch to posting this as an RFC until you gather some review
> tags? Our CI require manual intervention to add the necessary iproute2
> patches, I suspect there may be some uAPI changes therefore requiring
> iproute2 changes here.

Will do.  Yes, this series adds new SEG6_LOCAL_* / SEG6_LOCAL_MOBILE_*
uAPI in include/uapi/linux/seg6_local.h; the matching iproute2-next
series is posted separately:

  https://lore.kernel.org/netdev/20260505-seg6-mobile-v2-0-93291b7b0134@gmail.com/

Just to confirm the workflow you'd prefer: should I repost the
current series immediately as [PATCH RFC net-next v3 ...], or wait
for technical review on v2 to land and fold it into a v3 RFC?

Thanks,
Yuya

On Tue, 5 May 2026 10:22:58 +0900 Yuya Kusakabe wrote:
> Just to confirm the workflow you'd prefer: should I repost the
> current series immediately as [PATCH RFC net-next v3 ...], or wait
> for technical review on v2 to land and fold it into a v3 RFC?

Let's wait for reviews (adding Justin to CC as well FWIW)

On Mon, 4 May 2026 18:28:33 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Tue, 5 May 2026 10:22:58 +0900 Yuya Kusakabe wrote:
> > Just to confirm the workflow you'd prefer: should I repost the
> > current series immediately as [PATCH RFC net-next v3 ...], or wait
> > for technical review on v2 to land and fold it into a v3 RFC?
> 
> Let's wait for reviews (adding Justin to CC as well FWIW)

Hi Yuya,

just a heads-up: I am going through the series (kernel and iproute2)
and will send detailed comments within the next few days. It is a
substantial addition so I want to take the time to review it properly.

Thanks,
Andrea

On Fri, May 8, 2026 at 10:32 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote:
> just a heads-up: I am going through the series (kernel and iproute2)
> and will send detailed comments within the next few days. It is a
> substantial addition so I want to take the time to review it properly.

Hi Andrea,

Thank you for the heads-up and for dedicating your time to review this
substantial series.
I will stand by for your detailed comments and prepare to address them.

Thanks,
Yuya

On Fri, May 8, 2026 at 10:32 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote:
> just a heads-up: I am going through the series (kernel and iproute2)
> and will send detailed comments within the next few days. It is a
> substantial addition so I want to take the time to review it properly.

Quick note from my side before you spend more time on patch 4/7:

While preparing v3 I noticed that v2's patch 4/7 ("End.M.GTP6.D")
implements RFC 9433 Section 6.4 (D.Di) by mistake -- it shares the
SRH-augmenting builder with patch 5/7 and preserves the original
outer DA in segments[0].  Per Section 6.3 it should push the SR
Policy verbatim and write Args.Mob.Session into segments[0].
Already fixed in the local v3 branch.

Feel free to skip the End.M.GTP6.D-specific comments on v2 patch
4/7; patch 5/7 (D.Di) is unaffected.  Per Jakub's guidance I will
hold the v3 repost until your review lands.

Thanks,
Yuya