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

plakhera <> Wed, 12 December 2018 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C0BD12777C for <>; Wed, 12 Dec 2018 07:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.46
X-Spam-Status: No, score=-4.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_NONE=-0.0001, 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 iRjkftxRNkKO for <>; Wed, 12 Dec 2018 07:00:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F20E21200B3 for <>; Wed, 12 Dec 2018 07:00:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=hFXRz59NE5T5new/HQ7ej5IGRw8=; b=VxPOdvDfsV+EfeOc 4s+Jnbm9EOB5zFsVjuEhqQFA8QtZuCvVO0tMhVTCiwYrdXM/ymXjOfv7YMe7NHAq sQYSH1QUKz1R8bWOYGQLmK6CuNwQxIvVxbm6IWLD8IGJNkDjRJwQeC+Nh2N0DL37 dXp03wIr/WZvr3vj3fe6prtWH8c=
Received: by with SMTP id filter0082p1iad2-20191-5C11227E-47 2018-12-12 15:00:14.75815383 +0000 UTC m=+142452.385879791
Received: from (unknown []) by (SG) with ESMTP id OkquWYRaQC6QrmDOITVfgg for <>; Wed, 12 Dec 2018 15:00:14.940 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id B8F64C14A9 for <>; Wed, 12 Dec 2018 07:00:14 -0800 (PST)
Date: Wed, 12 Dec 2018 15:00:14 +0000
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_5c11227eb79ed_376a3f8d8fed45c014647"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak0qLPfhpX6aBXsjs0tvNgtYVIwhPdnJnqr2cL KwZdWLTZoQgCUtE6CtM/mqZhbuPpiK4lQ6sZGYoMsOIzBzo8Xg5yDM5na1zwkpPTKcWB6HH7mJgKGv miwniMzcdfP7b/AeobdftyI3HYfyX8pEiesvsfySOeMmU/b/jrpCoARIlyLNeNlFfYzYDJPfoCWnYe Q=
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: Wed, 12 Dec 2018 15:00:18 -0000

"It would effectively require the server not only to have multiple addresses from the client's perspective"

Not necessarily. The issue is making existing deployments work with the clients.
For now most server deployments are IPv4 only or Dual stack.
If servers are IPv4 only, they can remain IPv4 and a client side solution can work even when one interface has IPv4 only and the other one has IPv6 only connectivity.

For servers that are IPv4 only servers, one could begin on WiFi and then synthesize IPv6 address when WiFi goes away and the connection is being migrated to cellular with IPv6 only NAT64/DNS64 connectivity.
For the other way around, if one gets synthesized AAAA from DNS64, one could try and parse out the last 32 bits and attempt a connection over WiFi with v4 only configuration.


The problem that needs more than just client side work-around is for making things work with dual stack sever deployments which I would become more and more common going forward.

"but require the server to have addresses that it can't tell the client about because they're local to the client (NAT64)."

I didn't get this. Can you please elaborate? Server must only communicate their public addresses that are global in scope.

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