public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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
>>>>
>>>
>>>
>>


  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