From: Justin Iurman <justin.iurman@gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v5 2/7] ipv6: Cleanup IPv6 TLV definitions
Date: Sun, 1 Feb 2026 09:48:46 +0100 [thread overview]
Message-ID: <d0b4b06a-94ba-4665-9593-2c507ffb552a@gmail.com> (raw)
In-Reply-To: <CALx6S35Z63WDMOkZLJ7PzR6BcEV4h5f7Jm-Okw9izcuFcygNoA@mail.gmail.com>
On 1/30/26 18:22, Tom Herbert wrote:
> On Thu, Jan 29, 2026 at 10:13 AM Justin Iurman <justin.iurman@gmail.com> wrote:
>>
>> On 1/29/26 06:30, Willem de Bruijn wrote:
>>> Tom Herbert wrote:
>>>> Move IPV6_TLV_TNL_ENCAP_LIMIT to uapi/linux/in6.h to be with the rest
>>>> of the TLV definitions. Label each of the TLV definitions as to whether
>>>> they are a Hop-by-Hop option, Destination option, or both.
>>>>
>>>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>>>> ---
>>>> include/uapi/linux/in6.h | 21 ++++++++++++++-------
>>>> include/uapi/linux/ip6_tunnel.h | 1 -
>>>> 2 files changed, 14 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
>>>> index 5a47339ef7d7..438283dc5fde 100644
>>>> --- a/include/uapi/linux/in6.h
>>>> +++ b/include/uapi/linux/in6.h
>>>> @@ -140,14 +140,21 @@ struct in6_flowlabel_req {
>>>>
>>>> /*
>>>> * IPv6 TLV options.
>>>> + *
>>>> + * Hop-by-Hop and Destination options share the same number space.
>>>> + * For each option below whether it is a Hop-by-Hop option or
>>>> + * a Destination option is indicated by HBH or DestOpt.
>>>> */
>>>> -#define IPV6_TLV_PAD1 0
>>>> -#define IPV6_TLV_PADN 1
>>>> -#define IPV6_TLV_ROUTERALERT 5
>>>> -#define IPV6_TLV_CALIPSO 7 /* RFC 5570 */
>>>> -#define IPV6_TLV_IOAM 49 /* RFC 9486 */
>>>> -#define IPV6_TLV_JUMBO 194
>>>> -#define IPV6_TLV_HAO 201 /* home address option */
>>>> +#define IPV6_TLV_PAD1 0 /* HBH or DestOpt */
>>>> +#define IPV6_TLV_PADN 1 /* HBH or DestOpt */
>>>> +#define IPV6_TLV_TNL_ENCAP_LIMIT 4 /* RFC 2473, DestOpt */
>>>> +#define IPV6_TLV_ROUTERALERT 5 /* HBH */
>>>> +#define IPV6_TLV_CALIPSO 7 /* RFC 5570, HBH */
>>>> +#define IPV6_TLV_IOAM 49 /* RFC 9486, HBH or Destopt
>>>> + * IOAM sent and rcvd as HBH
>>>
>>> Explicit labeling with HBH or Destopt is quite informative.
>>>
>>> Does this mean that IPV6_TLV_IOAM should also be accepted in ip6_parse_tlv
>>> in the Destopt branch? RFC 9486 indeed did reserve a number.
>>
>> Nope, not right now. The only IOAM option currently implemented in the
>> kernel is the Pre-allocated Trace, which uses a Hop-by-Hop option. It
>> wouldn't make sense to have it in a Destination option, although you
>> could (i.e., it's not forbidden, just weird). Actually, the only IOAM
>> option that would make sense to carry in a Destination Option is the
>> Edge-to-Edge (E2E), but it's not implemented in the kernel. Should it be
>> implemented at some point, then yes, you'd have IPV6_TLV_IOAM in the
>> Destopt branch as well.
>
> Justin,
>
> Conceptually, someone could put IOAM in Destination Options before the
> Routing Header. There's about 0% of that ever happening though.
Tom,
Correct. However, I wouldn't say there's about 0% of that ever
happening. At some point, I remember that we even thought about using
the IOAM Pre-allocated Trace in the Destination Options header (the
first one, before the RH). The goal was to use it with SRv6 and collect
telemetry for the overlay. There was also an attempt at including IOAM
within SRv6 directly (draft-ali-spring-ioam-srv6), which didn't get
consensus at that time.
Justin
> Tom
>
>>
>>>> + */
>>>> +#define IPV6_TLV_JUMBO 194 /* HBH */
>>>> +#define IPV6_TLV_HAO 201 /* home address option, DestOpt */
>>>>
>>>> /*
>>>> * IPV6 socket options
>>>> diff --git a/include/uapi/linux/ip6_tunnel.h b/include/uapi/linux/ip6_tunnel.h
>>>> index 85182a839d42..35af4d9c35fb 100644
>>>> --- a/include/uapi/linux/ip6_tunnel.h
>>>> +++ b/include/uapi/linux/ip6_tunnel.h
>>>> @@ -6,7 +6,6 @@
>>>> #include <linux/if.h> /* For IFNAMSIZ. */
>>>> #include <linux/in6.h> /* For struct in6_addr. */
>>>>
>>>> -#define IPV6_TLV_TNL_ENCAP_LIMIT 4
>>>> #define IPV6_DEFAULT_TNL_ENCAP_LIMIT 4
>>>>
>>>> /* don't add encapsulation limit if one isn't present in inner packet */
>>>> --
>>>> 2.43.0
>>>>
>>>
>>>
>>
next prev parent reply other threads:[~2026-02-01 8:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 19:48 [PATCH net-next v5 0/7] ipv6: Address ext hdr DoS vulnerabilities Tom Herbert
2026-01-26 19:48 ` [PATCH net-next v5 1/7] ipv6: Check of max HBH or DestOp sysctl is zero and drop if it is Tom Herbert
2026-01-27 17:49 ` Justin Iurman
2026-01-27 17:50 ` Justin Iurman
2026-01-26 19:48 ` [PATCH net-next v5 2/7] ipv6: Cleanup IPv6 TLV definitions Tom Herbert
2026-01-27 17:51 ` Justin Iurman
2026-01-29 5:30 ` Willem de Bruijn
2026-01-29 18:13 ` Justin Iurman
2026-01-29 19:01 ` Willem de Bruijn
2026-01-30 17:22 ` Tom Herbert
2026-02-01 8:48 ` Justin Iurman [this message]
2026-02-02 22:37 ` Tom Herbert
2026-01-26 19:48 ` [PATCH net-next v5 3/7] ipv6: Add case for IPV6_TLV_TNL_ENCAP_LIMIT in EH TLV switch Tom Herbert
2026-01-27 17:52 ` Justin Iurman
2026-01-29 5:31 ` Willem de Bruijn
2026-01-26 19:48 ` [PATCH net-next v5 4/7] ipv6: Set HBH and DestOpt limits to 2 Tom Herbert
2026-01-27 17:55 ` Justin Iurman
2026-01-26 19:48 ` [PATCH net-next v5 5/7] ipv6: Document defaults for max_{dst|hbh}_opts_number sysctls Tom Herbert
2026-01-27 17:57 ` Justin Iurman
2026-01-26 19:48 ` [PATCH net-next v5 6/7] ipv6: Enforce Extension Header ordering Tom Herbert
2026-01-27 19:48 ` Justin Iurman
2026-01-29 5:18 ` Willem de Bruijn
2026-01-29 18:07 ` Justin Iurman
2026-01-29 19:05 ` Willem de Bruijn
2026-01-29 20:13 ` Justin Iurman
2026-01-30 17:06 ` Tom Herbert
2026-01-31 17:24 ` Willem de Bruijn
2026-02-02 22:21 ` Tom Herbert
2026-01-26 19:48 ` [PATCH net-next v5 7/7] ipv6: Document enforce_ext_hdr_order sysctl Tom Herbert
2026-01-27 18:00 ` 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=d0b4b06a-94ba-4665-9593-2c507ffb552a@gmail.com \
--to=justin.iurman@gmail.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.com \
--cc=willemdebruijn.kernel@gmail.com \
/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