ALPN and QUIC versions

Martin Duke <> Wed, 19 May 2021 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EF0E3A141B for <>; Wed, 19 May 2021 08:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KMFqK-Nt8W73 for <>; Wed, 19 May 2021 08:27:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56A223A13BD for <>; Wed, 19 May 2021 08:27:03 -0700 (PDT)
Received: by with SMTP id p8so13342623iol.11 for <>; Wed, 19 May 2021 08:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4PIExWu6+it0m1KjYBnvYk6FaH6oPb0ISZEK3TOZkgc=; b=pjEiczNKUX5Z/7GoKHLL+sewh4ihHGLmmvva0qkJc9FYGz2a4qxDKASXBiORj8TDbf h1VOLWTG6wxPJuLhdD/Y1x+vnumReW+xejKyGpzDVbDHfFtB7boeNsA2AZtyxIJghugW TexEEmBEO75hoVW0Tc9URRuqI6MoVMd0iftJvmkQh9aUp7XmE9seEV4fhsZ0uWe/ySHX NGSWpZs7XfkZ1xZ6uq6uiyzUXx9UP+2iFOnTztYQLbuh4nb1Kw/JOwC+5qLCfWQICHBP HAxRP1juqscBo8NJCfYS++klBhy8V3hf2po6yAuCl1jJkmY51hilDdi+82Mgd7qVRcLz 8LtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4PIExWu6+it0m1KjYBnvYk6FaH6oPb0ISZEK3TOZkgc=; b=iZGtLabzJz3Umpyy6qbYw+qzZB8esPZIDJK4wKM2IaQNRRKcl1SPPwT2v6SmX7NmBW IkidvYge64Xqc9sd83jeHKD3XR8F8XLyu6bQQy+g//zgzRj8DRCO6gsWC8t0S4KpNBLp 50lYmIneSA7p4SUXr97eNLURoml6BVwUqe44bXMZF4yO5SUzOrHdNWibg5MBB4Ra+T7c Ki/u5xvCvdS7lSHZy9lT3aCXMrL/y1LpUgQ+C7RKg6Lvhzcq/00nvIjmrP5b8i4jAq5l V9UqRJNgnvqPZ8qoYxvzbGmVEKTt+1DmIFMKH2dsPd1tx3yO0uktG07dXqhsKGiKkk3g bJug==
X-Gm-Message-State: AOAM531nQzXuJ5e8mVCYAWC94wSLDjIogEzfK/OXf4a+pduxrfUNpHvn FDjnzTm8T1mYXl8/68aX6ta0o9pqawvLSbJiBxUW1dtUV4j5iQ==
X-Google-Smtp-Source: ABdhPJzOEmVT85KeasfPHCT5dD7BgheZthwjYrTCQgEhgsDTaNZH3qsyro2obByY8cicr5pLbhW78yVhi7UBBrVgIMo=
X-Received: by 2002:a02:c98a:: with SMTP id b10mr13724595jap.103.1621438021584; Wed, 19 May 2021 08:27:01 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <>
Date: Wed, 19 May 2021 08:26:58 -0700
Message-ID: <>
Subject: ALPN and QUIC versions
Content-Type: multipart/alternative; boundary="0000000000004d498505c2b075c0"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 May 2021 15:27:08 -0000

There appears to be an under-examined sentiment in this WG that the 'h3'
ALPN specifically indicates QUIC version 1. The only spec explicitly
stating it, that I can find, is the applicability draft, and I've
filed an issue
against it <> [1]. I might
be in the rough here, but I'd like to push back on this design during WGLC
in case others share my concerns.

[TL;DR one ALPN per QUIC version will not scale with many versions and we
should do something else]

quic-http says "HTTP/3 relies on QUIC version 1 as the underlying
transport. The use of other QUIC transport versions with HTTP/3 MAY be
defined by future specifications.," which to me is not quite the same thing
as saying we need a new ALPN.

For the QUICv2 draft there has been some discussion
<> of what the
correct way <> to
specify support for HTTP/3 is. [2,3]

I'm fine with the quic-http wording, but I dislike the text in the
applicability draft. There are a few ways we could actually design the
interaction of applications and versions:

1) As stated in the applicability draft, the ALPN includes the QUIC
version. Then every new version document has to review the set of
QUIC-specific ALPN codes and register new ALPNs. As these version numbers
are 32 bit integers and may not simply increment up from 1, ALPN codes will
often look like h3-0x4384abc0, doq-0x4384abc0 [4], etc. Similarly, each new
application of QUIC has to review the set of QUIC versions and register new
ALPNs for each version. This has the advantage of reducing the need for
version negotiation, but it's not scalable if there are a lot of versions
and applications. The ALPN registry will essentially have a matrix of
applications and QUIC versions with the combination that signifies each.

I imagine most QUIC implementation APIs would present an interface for an
application to declare its ALPNs. I'm not sure how that implementation
easily deploys new versions (or deprecates old ones) if all the apps then
have to change, unless it's mutating the ALPN from an application-provided
root. That seems error-prone.

2) A draft with a new QUIC version MUST formally update any QUIC
application RFC for which it wants to use the same ALPN. Application RFCs
would say which versions can transport them at the time of writing without
a formal update. So to find the available QUIC versions for a given
application RFC, one could see the versions listed in that RFC (which
obviously predate the application) and then note in the header which RFCs
update it (all the compatible versions released since). Mike Bishop suggested
this course of action
<> in [3]. This
property is somewhat convenient, but again, I don't think it scales
incredibly well: if there are many versions, the front page of HTTP/3 could
be filled with RFCs that update it, merely because they say "you can use h3
with this"

3) Add a column to the IANA ALPN Registry
[5] that specifically lists the compatible QUIC versions. For most current
entries (which are not QUIC-compatible), this would be empty. New
application or version RFCs could simply update the registry, which will
scale somewhat better than (1) and still be easily discoverable. I am happy
to write a short draft to change the registry if that's how we want to

4) There is no formal trail of linkages. New version RFCs should say what
apps they support (possibly as generic as "all v1 applications work with
the new version") and applications should say if (a) the list of usable
versions is other than the full known set and (b) what properties it needs
from a QUIC version to operate. This is the path I took in a v2 PR
<> [3], which has no
official standing whatsoever. This makes the forensics to obtain the full
list of usable versions quite a bit harder, but won't explode the ALPN
registry or the front page of HTTP/3.

There are probably other solutions I haven't thought of. I have
purposefully ignored the whole question of provisional and experimental
versions to keep this at a manageable length.

As you might tell, I would prefer (3) or (4). I would like to confirm I am
in the rough before we ship the applicability draft that [informatively]
mandates (1).


[4] I'm happy to bikeshed on decimals vs. hex, if we choose this option.