Re: [quicwg/base-drafts] Allow servers to send a preferred address of each address family (#2296)

ianswett <notifications@github.com> Sun, 13 January 2019 02:56 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 F0786128B14 for <quic-issues@ietfa.amsl.com>; Sat, 12 Jan 2019 18:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.552
X-Spam-Level:
X-Spam-Status: No, score=-12.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 iFOvc8YBzyS7 for <quic-issues@ietfa.amsl.com>; Sat, 12 Jan 2019 18:56:48 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6F1128AFB for <quic-issues@ietf.org>; Sat, 12 Jan 2019 18:56:48 -0800 (PST)
Date: Sat, 12 Jan 2019 18:56:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1547348205; bh=bpSgT9DryoWrICEG6s7yBzHiIX39uIwxC94kq9btek4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=X0bgjHsBKPXH2C+61uLbmuIRgmpVBUPgXxViIPKCbQznturzORRU/mbbU46C1FzzS gWDR9rBA/LKdE44tfrVdssorXKTpeJl8cP4z4t0SLwe/E0uChGU1XJ5F4+VFlefxKT rMwvkzdviidFWeFXJU9BiC7wM7wsTvBNaMhuAV+g=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab0249a77c723467bb859d2664cf3ca8265183ac4d92cf0000000118526aed92a169ce179bec73@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2296/review/191958658@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2296@github.com>
References: <quicwg/base-drafts/pull/2296@github.com>
Subject: Re: [quicwg/base-drafts] Allow servers to send a preferred address of each address family (#2296)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c3aa8eddbe72_12c33f84854d45c41117934"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/sLRfeNRr51L6k0iZ5GXewXgnYvg>
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: Sun, 13 Jan 2019 02:56:50 -0000

ianswett requested changes on this pull request.



> @@ -2116,6 +2116,9 @@ packets.
 A server conveys a preferred address by including the preferred_address
 transport parameter in the TLS handshake.
 
+Servers MAY communicate a preferred address of each address family (IPv4 and

I realize, looking back on the issue, why Jana mentioned alternate.  There are two separate cases: Connection migration and Server's Preferred Address.

In one case, you want to make sure connection migration doesn't fail when moving from v6 to v4 only, but you don't want them to do anything after the handshake.  In the other case, you want them to migrate to a more stable IP after the handshake.

If the server omits the address family you connected on, but supplies a preferred address on the other address family, do you try to migrate?

I suspect we need to change the structure from what's in this PR, and if not, we need to nail down the critical use cases and make sure they all work.  

-- 
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/pull/2296#pullrequestreview-191958658