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

plakhera <> Thu, 13 December 2018 06:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBA8112F1AB for <>; Wed, 12 Dec 2018 22:58:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.46
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TTKFwxoOdlmx for <>; Wed, 12 Dec 2018 22:58:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1C0112875B for <>; Wed, 12 Dec 2018 22:58:46 -0800 (PST)
Date: Wed, 12 Dec 2018 22:58:46 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1544684326; bh=44yuumK+S5YbVLWyWPFZkxGROP5kdqwKr2cihAvv5Z8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=b3Ky53S8OjhxQoFG2iPiRYRFr++QAcXyPuq4pAjsxuPJGYLNqi+8paoIyJe1tT7r3 aDrln6njHLiSAuS00G2wLhGJE9z+5KsMOjmDKyGIIic3yclTJUJGOaa2e1OCNmDLaM 4okESKTdZ7WbiMymszh92lipIzVKS4kF1TFgUdQ0=
From: plakhera <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2122/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
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_5c1203264d529_23c83ffa4dad45bc548924"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: plakhera
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: Thu, 13 Dec 2018 06:58:49 -0000

> I think we can get the low-hanging fruit here by having alternate_address_v4 and alternate_address_v6 transport parameters. 

+1. Just that bit by itself (either having two new TPs alternate_address_v4 or  alternate_address_v6 or splitting preferred_address to _v4 and v6) would help in most cases.

> That said, I'm not convinced of how important this is to solve in v1. This affects only migrations, and then only those that are from networks on one address family to a different one.

It is increasingly becoming common for cellular carriers to deploy IPv6 only NAT64/DNS64 networks, even in countries where ISPs have stayed IPv4 only on the CPE, mostly because of differences in how connectivity is achieved in two scenarios and the use-cases.
It won't be far fetched to think that this disparity would be widened by end of next year.

The current limitation introduces legitimate concerns of deploying dual stack configuration for services that still desire transport protocol level connection migration support.

Also we should probably try our best to have version one be address family agnostic. The fact that there is only one preferred_address family parameter doesn't help.

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