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

[Justin Iurman <justin.iurman@gmail.com>]

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.

>> +					 */
>> +#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
>>
> 
>