"ip route save" stores a route dump and "ip route restore" sends it
back to the kernel unchanged.  The kernel dumps RTA_ENCAP, and some of
the attributes nested in it, without NLA_F_NESTED, but rpl, ioam6,
xfrm and the geneve, vxlan and erspan options of the ip and ip6 encaps
require the flag when parsing them.  Restoring such a route fails with
"NLA_F_NESTED is missing", and none of them has been restorable in any
release.

Setting the flag in the dumps would change the UAPI: userspace that
does not mask it off the attribute type, such as parse_rtattr() in
iproute2, would no longer find RTA_ENCAP, and dumps that have already
been saved would still fail.  The series therefore only makes the
parsers accept what the kernel itself dumps.  The dumps, and the
attributes accepted with the flag set, stay as they are.

Patch 1 adds lwtunnel_nla_parse() to the lwtunnel core, so that the
missing flag is documented once next to the build_state callback
instead of being worked around in each lwtunnel.  It is
nla_parse_nested() without the flag check: the nested attributes are
still validated strictly, which nla_parse_nested_deprecated(), used by
the older lwtunnels, would not do.  Patch 1 uses it in rpl and ioam6,
and patch 2 in xfrm.

Patch 3 does the same for the ip and ip6 encaps, whose geneve, vxlan
and erspan options are nested one level further down: the level shared
by all options is validated through lwtunnel_nla_validate(), the
counterpart of lwtunnel_nla_parse() for nla_validate().  Nothing but
the NLA_F_NESTED check is relaxed.

Patch 4 adds a selftest that saves and restores a route of each kind.

---
Yuya Kusakabe (4):
      net: lwtunnel: accept RTA_ENCAP without NLA_F_NESTED
      xfrm: lwtunnel: accept RTA_ENCAP without NLA_F_NESTED
      net: ip_tunnel: accept tunnel options without NLA_F_NESTED
      selftests: net: add lwtunnel route save and restore test

 include/net/lwtunnel.h                          |  49 ++++++++++
 net/ipv4/ip_tunnel_core.c                       |  24 +++--
 net/ipv6/ioam6_iptunnel.c                       |   4 +-
 net/ipv6/rpl_iptunnel.c                         |   4 +-
 net/xfrm/xfrm_interface_core.c                  |   3 +-
 tools/testing/selftests/net/Makefile            |   1 +
 tools/testing/selftests/net/lwt_save_restore.sh | 116 ++++++++++++++++++++++++
 7 files changed, 186 insertions(+), 15 deletions(-)
---
base-commit: 17741334d00bf5ebd37f8c1c36bc9c146a351deb
change-id: 20260918-lwt-encap-noflag-ae795af30b52

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

On Wed, Sep 23, 2026 at 09:36:55AM +0900, Yuya Kusakabe wrote:
> "ip route save" stores a route dump and "ip route restore" sends it
> back to the kernel unchanged.  The kernel dumps RTA_ENCAP, and some of
> the attributes nested in it, without NLA_F_NESTED, but rpl, ioam6,
> xfrm and the geneve, vxlan and erspan options of the ip and ip6 encaps
> require the flag when parsing them.  Restoring such a route fails with
> "NLA_F_NESTED is missing", and none of them has been restorable in any
> release.

If this never worked, then why target these patches at net and blaming
up to 7 years old commits? I try to follow [1] when deciding between net
and net-next.

Also, did you hit this in practice or was this flagged by AI? If nobody
is using save/restore and hitting this in practice, then maybe it's not
worth to loosen the validation performed by the kernel.

Note that nowadays many deployments program routes using nexthop objects
and ip-nexthop completely lacks save/restore functionality.

[1] https://lkml.org/lkml/2018/6/24/113

On Wed, Sep 23, 2026 at 02:29:17PM +0300, Ido Schimmel wrote:
> If this never worked, then why target these patches at net and blaming
> up to 7 years old commits? I try to follow [1] when deciding between net
> and net-next.
You are right, it is not a regression.  If there is a v2 it will go to
net-next without the Fixes tags.

> Also, did you hit this in practice or was this flagged by AI? If nobody
> is using save/restore and hitting this in practice, then maybe it's not
> worth to loosen the validation performed by the kernel.
It was flagged by an AI review of a new encap I am working on (SRv6
Mobile User Plane, still RFC).  I reproduced it there, and checking the
existing encaps showed rpl, ioam6, xfrm and the ip tunnel options behave
the same.  I have no report from their users.

My motivation was that a feature which exists should not silently fail,
and the series only drops the flag check on the container; everything
nested inside is still validated strictly.  But if nobody relies on
save/restore for these encaps, I am fine dropping the series, and the
new encap will keep nla_parse_nested() like rpl, ioam6 and xfrm.

Thanks