Re: [quicwg/base-drafts] 5-tuple routing and SPA (#3608)

Martin Thomson <> Mon, 04 May 2020 05:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3B7A3A0C67 for <>; Sun, 3 May 2020 22:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Status: No, score=-1.483 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 nCoBK5-40KdX for <>; Sun, 3 May 2020 22:41:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BD703A0C66 for <>; Sun, 3 May 2020 22:41:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B17382C0CC9 for <>; Sun, 3 May 2020 22:41:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588570883; bh=zal30yNEPkf4coKzkk0VRRSFcMru4nWZGhpMV/qW0dY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=G7IBDW05v2NQ5VH5S2cfGqOltpkHsSftkAO3PsAWS9HR37ETbSAYppelOub5w10Vb SRqBfnz4A2C/64vAFbps3mjuXv8dAao8LlkynV6dbBxzhlkbuRGPbiAlOTruIsK5qs tfKEJK26ThIaAFNIHPflzjJiS/G69E7wPMRcu190=
Date: Sun, 03 May 2020 22:41:23 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3608/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] 5-tuple routing and SPA (#3608)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eafab03a1a4e_5ac53ff87d4cd96024402"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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, 04 May 2020 05:41:26 -0000

A truth table might help here.

... | migration supported (no signal) | disable_active_migration set | 
no preferred address | normal (migrate as you like);  | don't migrate |
preferred address | normal (migrate at your leisure) | don't migrate |

Right now, our definition of disable_active_migration is a simple "don't migrate".  But the argument here says that the server that provides a preferred address is *probably* capable of handling migrations on the basis that it has to support one.  We might insist on the source address not change, but the fact is that some NATs (those with address-dependent mappings) will change the source address.

Changing to a definition where disable_active_migration is instead "don't move to a new address unless you use a preferred address" is a little more complicated, but doable.

Is it worth the extra complexity this late in the process?  Is that complexity justified when it would be trivially possible to define another extension that said "I support migration on my preferred address"?

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