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] [thread-next>] [day] [month] [year] [list]

Message-ID: <willemdebruijn.kernel.2b9253fe1797@gmail.com>
Date: Thu, 29 Jan 2026 14:01:11 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Justin Iurman <justin.iurman@...il.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 Tom Herbert <tom@...bertland.com>, 
 davem@...emloft.net, 
 kuba@...nel.org, 
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5 2/7] ipv6: Cleanup IPv6 TLV definitions

Justin Iurman 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.

Sounds great. Thanks for that context.