Re: [quicwg/base-drafts] Better describe the use of Preferred Address (#3354)

Eric Kinnear <> Mon, 10 February 2020 07:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63412120091 for <>; Sun, 9 Feb 2020 23:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 14yw6qjnRptA for <>; Sun, 9 Feb 2020 23:30:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAD04120077 for <>; Sun, 9 Feb 2020 23:30:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C47F452018B for <>; Sun, 9 Feb 2020 23:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581319845; bh=SaVltS5DEr5rNwTAYv1+X1eL1gmFb2YdaSfulnh30HA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1PFuGHQRmlVccqWMWKmQ2MdWFiiRRcdw4+QoXa122uoJS5GbbyLR7fRNPsz/eercu oX6VMbu413E2tJ3B/VcR6HIgnwF5sSpv9FX/Z2mvxlDw7nvZ4+16jIt74OXbrrnCMx hiQ9W8kopVaj0M6fHj4u1lWCBHouwTZpQ220ocSQ=
Date: Sun, 09 Feb 2020 23:30:45 -0800
From: Eric Kinnear <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3354/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Better describe the use of Preferred Address (#3354)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e4106a5b41e3_48a53fe1f8ccd96c4480b5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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: Mon, 10 Feb 2020 07:30:48 -0000

erickinnear commented on this pull request.

> @@ -2194,11 +2194,13 @@ linked by any other entity.
 At any time, endpoints MAY change the Destination Connection ID they send to a
 value that has not been used on another path.
-An endpoint MUST use a new connection ID if it initiates connection migration as
-described in {{initiating-migration}} or probes a new network path as described
-in {{probing}}.  An endpoint MUST use a new connection ID in response to a
-change in the address of a peer if the packet with the new peer address uses an
-active connection ID that has not been previously used by the peer.
+An endpoint MUST use a new connection ID when it initiates connection migration
+as described in {{initiating-migration}} or {{preferred-address}}, or when it
+probes a new network path as described in {{probing}}, and MUST NOT reuse

Writing down the results of a discussion in ZRH about stating this in terms of endpoints (not client/server) and addresses (not paths):
- An endpoint MUST NOT reuse a CID when sending from more than one local address
- An endpoint MUST NOT reuse a CID when sending to more than one destination address

With the following exceptions/additions:
- An endpoint SHOULD NOT respond to a newly seen incoming CID with an outgoing CID that it has used before (should since it may not have a new one to use)
- An endpoint MAY skip switching if it has strong reason to believe that the remote endpoint didn't try to change (i.e. if CID didn't change and only port changed, it's likely NAT rebinding), although this exception is only necessary if it doesn't have a new one to use

(Modulo some wording tweaks)

I *think* this is the current state of the text, just rearranging to collapse the separate requirements into one cluster that's hopefully easy to understand. Will incorporate this into the SPA PR if that seems reasonable to you.

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