IETF Logo Mail Archive

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

Kazuho Oku <notifications@github.com> Mon, 18 May 2020 03:52 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25153A08CD for <quic-issues@ietfa.amsl.com>; Sun, 17 May 2020 20:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.082
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pukAczEf_jpW for <quic-issues@ietfa.amsl.com>; Sun, 17 May 2020 20:52:56 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47613A08CC for <quic-issues@ietf.org>; Sun, 17 May 2020 20:52:56 -0700 (PDT)
Received: from github-lowworker-ca5950c.va3-iad.github.net (github-lowworker-ca5950c.va3-iad.github.net [10.48.17.57]) by smtp.github.com (Postfix) with ESMTP id E8C3D9604FE for <quic-issues@ietf.org>; Sun, 17 May 2020 20:52:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1589773974; bh=VWQdhQZmcgbg9fu+DFjQ2iRKtboFLzG96MSZe4dIlF8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hpuxWl18XdpOQFrh0w4zJBdh1Bb9crQWnt74FoTNoI6FLHzRIvF6G1fKtbA5MOFy2 vZwGYhSdl4WVF6+WLK1isHJUHqWVr1a76PeZHUyhVZ1STuD2n0WDObVBsDP2iNVjD4 M52JcRi/RYyHHIpljwc3r9UJFNe+4cm1q8MALv9s=
Date: Sun, 17 May 2020 20:52:54 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3W2LB7H57PSCMFFVV4ZXTZNEVBNHHCITYZTQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3608/629930947@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3608@github.com>
References: <quicwg/base-drafts/issues/3608@github.com>
Subject: Re: [quicwg/base-drafts] 5-tuple routing and SPA (#3608)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ec20696d9df7_345a3fc0da2cd9604479d3"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/7fPydTXJPDe0274I8njIOy7IpRw>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2020 03:52:58 -0000

@martinthomson 
> I realize that you could change the meaning of disable_active_migration to apply to the address the server uses in the handshake, but there are interesting corner cases and I don't think we need to concern ourselves with those. For instance, if you connect over V4 and get disable_active_migration and server_preferred_address. If that SPA includes a V6 address you can't use, along with the same V4 address, what then? Does the server really support migration?

If this example is concerning, I'd argue that is an issue that already exists, orthogonal to what we are discussing here. I am still not convinced that limiting the scope of disable_active_migration to just the original address is going to cause any _new_ issue.

That said, if nobody needs this change, I'm more than happy to move on with status-quo.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3608#issuecomment-629930947

v2.23.0 | Report a Bug | By Email