Re: [quicwg/base-drafts] Equivalence of preferred_address and NEW_CONNECTION_ID (#3560)

Kazuho Oku <> Wed, 01 April 2020 04:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 854D33A0A14 for <>; Tue, 31 Mar 2020 21:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.082
X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.282, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iycf-gBAZMkG for <>; Tue, 31 Mar 2020 21:44:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E8483A0A13 for <>; Tue, 31 Mar 2020 21:44:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CCF332616D4 for <>; Tue, 31 Mar 2020 21:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585716294; bh=mmKs0D+KuFN+keI3jki9LYzgrI1mJY4I3xN4wLn2mrY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=A1kEy6SH7Qb0nMh2RFeMSuHwgFjhT+Xaav6Pm1EPL6Ynt+CxHol+fl8CUbgd1AVDh +Rzt0U0UlRDSZi3m/N+PUKXJDrDZP1ZC4PJ4KUjPCTePA2z6r4p/7qrMHYU1VSWrv0 /BinYiko0Wsrd9MscVGBGtqnr+H+23ZVlCLD7UqQ=
Date: Tue, 31 Mar 2020 21:44:54 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3560/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Equivalence of preferred_address and NEW_CONNECTION_ID (#3560)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e841c4685a71_24583fc1fbecd96420664b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2020 04:44:57 -0000

@martinthomson My personal take would be that people would not do that. When a client migrates to the preferred address, there's fair chance that the client's address tuple will change. That means that the server should be capable of receiving short header packets with 0-byte CID from any address, and determine that the packet belongs to the connection that is migrating to the preferred address.

That's possible theoretically, but in practice ...

I agree that a server might want to switch to zero-byte CID _after_ migration to SPA completes. But to do that, we need a NEW_CONNECTION_ID that can carry a zero-byte CID, which is forbidden at the moment. I do not think we'd want to change the spec now to allow that.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: