Date: Wed, 12 Dec 2018 17:46:22 -0800
From: janaiyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abd2f1c3fcf022197c632acc304dd858bc4e14525392cf0000000118297bee92a169ce1742d117@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/446811780@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_5c11b9ee26d09_6b7d3ff607ed45bc4297f";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/0Hi9xQtHIsvkpfOIV45fhqmlLac>


----==_mimepart_5c11b9ee26d09_6b7d3ff607ed45bc4297f
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

So, preferred_address has slightly different semantics than what you're asking for. It currently means that the server prefers that the client use the indicated address. What you want is an _alternate_ address, something that the client can use if it migrates to a network on a different address family.

I think we can get the low-hanging fruit here by having alternate_address_v4 and alternate_address_v6 transport parameters. 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.

I'll note that an explicit ADD/DELETE_ADDR doesn't work because of NATs (as @mikkelfj notes).  That is fine; in the spec, we've basically used receiving a packet from a new address as an implicit ADD_ADDR signal. The problem you're running into right now is that we don't support server migration in v1, which doesn't allow a server to send a packet from an unknown address to a client.

-- 
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-446811780
----==_mimepart_5c11b9ee26d09_6b7d3ff607ed45bc4297f
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>So, preferred_address has slightly different semantics than what you'r=
e asking for. It currently means that the server prefers that the client =
use the indicated address. What you want is an <em>alternate</em> address=
, something that the client can use if it migrates to a network on a diff=
erent address family.</p>
<p>I think we can get the low-hanging fruit here by having alternate_addr=
ess_v4 and alternate_address_v6 transport parameters. That said, I'm not =
convinced of how important this is to solve in v1. This affects only migr=
ations, and then only those that are from networks on one address family =
to a different one.</p>
<p>I'll note that an explicit ADD/DELETE_ADDR doesn't work because of NAT=
s (as <a class=3D"user-mention" data-hovercard-type=3D"user" data-hoverca=
rd-url=3D"/hovercards?user_id=3D193335" data-octo-click=3D"hovercard-link=
-click" data-octo-dimensions=3D"link_type:self" href=3D"https://github.co=
m/mikkelfj">@mikkelfj</a> notes).  That is fine; in the spec, we've basic=
ally used receiving a packet from a new address as an implicit ADD_ADDR s=
ignal. The problem you're running into right now is that we don't support=
 server migration in v1, which doesn't allow a server to send a packet fr=
om an unknown address to a client.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/issues/2122#issuecomment-446811780">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq7G4=
lU3zHEoo9oSKvP-kr47urc--ks5u4bFugaJpZM4ZPkXE">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq531keUce072rQ3V-W0pMmMC=
iYpxks5u4bFugaJpZM4ZPkXE.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://assets-cdn.github.com/images/email/message_cards/header.png","avatar_=
image_url":"https://assets-cdn.github.com/images/email/message_cards/avat=
ar.png","action":{"name":"Open in GitHub","url":"https://github.com/quicw=
g/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@jana=
iyengar in #2122: So, preferred_address has slightly different semantics =
than what you're asking for. It currently means that the server prefers t=
hat the client use the indicated address. What you want is an _alternate_=
 address, something that the client can use if it migrates to a network o=
n a different address family.\r\n\r\nI think we can get the low-hanging f=
ruit here by having alternate_address_v4 and alternate_address_v6 transpo=
rt parameters. That said, I'm not convinced of how important this is to s=
olve in v1. This affects only migrations, and then only those that are fr=
om networks on one address family to a different one.\r\n\r\nI'll note th=
at an explicit ADD/DELETE_ADDR doesn't work because of NATs (as @mikkelfj=
 notes).  That is fine; in the spec, we've basically used receiving a pac=
ket from a new address as an implicit ADD_ADDR signal. The problem you're=
 running into right now is that we don't support server migration in v1, =
which doesn't allow a server to send a packet from an unknown address to =
a client."}],"action":{"name":"View Issue","url":"https://github.com/quic=
wg/base-drafts/issues/2122#issuecomment-446811780"}}}</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=
-446811780",
"url": "https://github.com/quicwg/base-drafts/issues/2122#issuecomment-44=
6811780",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c11b9ee26d09_6b7d3ff607ed45bc4297f--