On Wed, 20 May 2026 12:12:08 +0900
Yuya Kusakabe [off-list ref] wrote:

Hi Yuya,

Thanks for the reply. Inline answers below.

On Sun, May 17, 2026 at 1:26 AM Andrea Mayer [off-list ref]
wrote:

quoted

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.