Date: Wed, 12 Dec 2018 15:00:14 +0000 (UTC)
From: plakhera <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abf14322525c740e4bec8dd603fbf7a54123b8b4ab92cf000000011828e47e92a169ce1742d117@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/446617371@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_5c11227eb79ed_376a3f8d8fed45c014647";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/uquuBvLngQIX-aSqRiDM_wgzrQ4>

----==_mimepart_5c11227eb79ed_376a3f8d8fed45c014647
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

"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:
https://github.com/quicwg/base-drafts/issues/2122#issuecomment-446617371
----==_mimepart_5c11227eb79ed_376a3f8d8fed45c014647
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>"It would effectively require the server not only to have multiple addre=
sses from the client's perspective"</p>
<p>Not necessarily. The issue is making existing deployments work with the =
clients.<br>
For now most server deployments are IPv4 only or Dual stack.<br>
If servers are IPv4 only, they can remain IPv4 and a client side solution c=
an work even when one interface has IPv4 only and the other one has IPv6 on=
ly connectivity.</p>
<p>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 mi=
grated to cellular with IPv6 only NAT64/DNS64 connectivity.<br>
For the other way around, if one gets synthesized AAAA from DNS64, one coul=
d try and parse out the last 32 bits and attempt a connection over WiFi wit=
h v4 only configuration.</p>
<p>=3D=3D=3D</p>
<p>The problem that needs more than just client side work-around is for mak=
ing things work with dual stack sever deployments which I would become more=
 and more common going forward.</p>
<p>"but require the server to have addresses that it can't tell the client =
about because they're local to the client (NAT64)."</p>
<p>I didn't get this. Can you please elaborate? Server must only communicat=
e their public addresses that are global in scope.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&mda=
sh;<br />You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, <a href=3D"https://github.com/quicwg/bas=
e-drafts/issues/2122#issuecomment-446617371">view it on GitHub</a>, or <a h=
ref=3D"https://github.com/notifications/unsubscribe-auth/AWbkq0xoNollvHscBN=
o3wfhF6uEokZWwks5u4Rn-gaJpZM4ZPkXE">mute the thread</a>.<img src=3D"https:/=
/github.com/notifications/beacon/AWbkq3NrT_7iNLXhLqMi_4V9LnM3CCshks5u4Rn-ga=
JpZM4ZPkXE.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"=
:"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi=
tHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg=
/base-drafts","subtitle":"GitHub repository","main_image_url":"https://asse=
ts-cdn.github.com/images/email/message_cards/header.png","avatar_image_url"=
:"https://assets-cdn.github.com/images/email/message_cards/avatar.png","act=
ion":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"=
}},"updates":{"snippets":[{"icon":"PERSON","message":"@plakhera in #2122: \=
"It would effectively require the server not only to have multiple addresse=
s from the client's perspective\"\r\n\r\nNot necessarily. The issue is maki=
ng existing deployments work with the clients.\r\nFor now most server deplo=
yments are IPv4 only or Dual stack.\r\nIf servers are IPv4 only, they can r=
emain IPv4 and a client side solution can work even when one interface has =
IPv4 only and the other one has IPv6 only connectivity.\r\n\r\nFor servers =
that are IPv4 only servers, one could begin on WiFi and then synthesize IPv=
6 address when WiFi goes away and the connection is being migrated to cellu=
lar with IPv6 only NAT64/DNS64 connectivity.\r\nFor the other way around, i=
f one gets synthesized AAAA from DNS64, one could try and parse out the las=
t 32 bits and attempt a connection over WiFi with v4 only configuration.\r\=
n\r\n=3D=3D=3D\r\n\r\nThe problem that needs more than just client side wor=
k-around is for making things work with dual stack sever deployments which =
I would become more and more common going forward.\r\n\r\n\"but require the=
 server to have addresses that it can't tell the client about because they'=
re local to the client (NAT64).\"\r\n\r\nI didn't get this. Can you please =
elaborate? Server must only communicate their public addresses that are glo=
bal in scope."}],"action":{"name":"View Issue","url":"https://github.com/qu=
icwg/base-drafts/issues/2122#issuecomment-446617371"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2122#issuecomment-4=
46617371",
"url": "https://github.com/quicwg/base-drafts/issues/2122#issuecomment-4466=
17371",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c11227eb79ed_376a3f8d8fed45c014647--