Re: [PATCH net-next v2 01/15] net: define IPPROTO_QUIC and SOL_QUIC constants

[Matthieu Baerts <matttbe@kernel.org>]

Hi Stefan, Xin,

On 18/08/2025 16:31, Stefan Metzmacher wrote:
> Hi,
> 
>> diff --git a/include/linux/socket.h b/include/linux/socket.h
>> index 3b262487ec06..a7c05b064583 100644
>> --- a/include/linux/socket.h
>> +++ b/include/linux/socket.h
>> @@ -386,6 +386,7 @@ struct ucred {
>>   #define SOL_MCTP    285
>>   #define SOL_SMC        286
>>   #define SOL_VSOCK    287
>> +#define SOL_QUIC    288
>>     /* IPX options */
>>   #define IPX_TYPE    1
>> diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
>> index ced0fc3c3aa5..34becd90d3a6 100644
>> --- a/include/uapi/linux/in.h
>> +++ b/include/uapi/linux/in.h
>> @@ -85,6 +85,8 @@ enum {
>>   #define IPPROTO_RAW        IPPROTO_RAW
>>     IPPROTO_SMC = 256,        /* Shared Memory Communications        */
>>   #define IPPROTO_SMC        IPPROTO_SMC
>> +  IPPROTO_QUIC = 261,        /* A UDP-Based Multiplexed and Secure
>> Transport    */
>> +#define IPPROTO_QUIC        IPPROTO_QUIC
>>     IPPROTO_MPTCP = 262,        /* Multipath TCP connection        */
>>   #define IPPROTO_MPTCP        IPPROTO_MPTCP
>>     IPPROTO_MAX
> 
> Can these constants be accepted, soon?
> 
> Samba 4.23.0 to be released early September will ship userspace code to
> use them. It would be good to have them correct when kernel's start to
> support this...
> 
> It would also mean less risk for conflicting projects with the need for
> such numbers.
> 
> I think it's useful to use a value lower than IPPROTO_MAX, because it means
> the kernel module can also be build against older kernels as out of tree
> module
> and still it would be transparent for userspace consumers like samba.
> There are hardcoded checks for IPPROTO_MAX in inet_create, inet6_create,
> inet_diag_register
> and the value of IPPROTO_MAX is 263 starting with commit
> d25a92ccae6bed02327b63d138e12e7806830f78 in 6.11.

I would also recommend not changing IPPROTO_MAX here. When IPPROTO_MAX
got increased to 263, this caused some (small) small issues because it
was hardcoded in some userspace code if I remember well.

It is unclear why IPPROTO_QUIC is using 261 and not 257, but it should
not make any differences I suppose.

Note that for MPTCP, we picked 262, just in case the protocol number was
limited to 8 bits, to fallback to IPPROTO_TCP: 262 & 0xFF = 6. At that
time, we thought it was important, because we were the first ones to use
a value higher than U8_MAX. At the end, it is good for new protocols,
not to increase IPPROTO_MAX each time :)

(@Xin: BTW, thank you for working on this!)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.