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

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

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@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.

Sounds great. Thanks for that context.