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

On Mon, Aug 18, 2025 at 12:20 PM Matthieu Baerts [off-list ref] wrote:

Hi Stefan, Xin,

On 18/08/2025 16:31, Stefan Metzmacher wrote:

quoted

Hi,

quoted

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.

I agree, it should not.

I wasn’t sure if any other project was using 257, so to minimize the risk
of conflicts, I’ve been using this large value from the beginning.

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 :)

Yes, this approach saves a lot of trouble for new protocols!

Thanks.