netdev - Re: [PATCH net-next v5 2/7] ipv6: Cleanup IPv6 TLV definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d0b4b06a-94ba-4665-9593-2c507ffb552a@gmail.com>
Date: Sun, 1 Feb 2026 09:48:46 +0100
From: Justin Iurman <justin.iurman@...il.com>
To: Tom Herbert <tom@...bertland.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, davem@...emloft.net,
 kuba@...nel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5 2/7] ipv6: Cleanup IPv6 TLV definitions

On 1/30/26 18:22, Tom Herbert wrote:
> On Thu, Jan 29, 2026 at 10:13 AM Justin Iurman <justin.iurman@...il.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@...bertland.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
>>>>
>>>
>>>
>>