IETF Logo Mail Archive

Re: [quicwg/base-drafts] QUIC connection migration and IPv6 only NAT64/DNS64 Networks (#2122)

David Schinazi <notifications@github.com> Thu, 13 December 2018 17:59 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 976E2130E04 for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 09:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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_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 4MnsnzIM6NFX for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 09:59:14 -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 045ED1200B3 for <quic-issues@ietf.org>; Thu, 13 Dec 2018 09:59:13 -0800 (PST)
Date: Thu, 13 Dec 2018 09:59:12 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544723952; bh=6QfrF47mZKyyQH44a+ssxHii/uoffVXcoN7AVKh9MDQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hkw0OTYVOjlOdxdgFPnJllf0+eTgRanYb7wqHYuRsxuzg9VcgVmBPqbOqC4mp0Gkc kYq28X467P92tI80LAk5GuM+7ZIqHYDKilRbWD8CGlwIEWvk7iCAaZs6krYzVcvrxe QF44IFzZoSZuViEICdXcUSfn5ZMzoD2X+OstXqEo=
From: David Schinazi <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abd64409d3f20499e9a35cbff42603b8a15e34bcc392cf00000001182a5ff092a169ce1742d117@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2122/447062473@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2122@github.com>
References: <quicwg/base-drafts/issues/2122@github.com>
Subject: Re: [quicwg/base-drafts] QUIC connection migration and IPv6 only NAT64/DNS64 Networks (#2122)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c129df0ba275_54a53ffc3d6d45c45909e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
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/pDtYqv3heGtRLhaMnFshkjCEtFc>
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: Thu, 13 Dec 2018 17:59:16 -0000

I agree with @plakhera ,  this is an important issue, and will be increasingly common as more cellular carriers switch to IPv6-only. At Google we've been seeing some number of as-yet unexplained connection migration failures, and our working hypothesis is address family mismatch. I think this does work with the concept of `preferred_address`. If a QUIC server deployment uses anycast IPs for initial packets then asks the client to switch to an address that uniquely identifies this server, why constrain the client to one address family? If the client used a variant of Happy Eyeballs, it could have ended up connecting using IPv4 even though it prefers IPv6. Sending both address families in `preferred_address` allows the client to switch back to the best address family.

-- 
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/2122#issuecomment-447062473

v2.14.0 | Report a Bug | By Email