IETF Logo Mail Archive

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

plakhera <notifications@github.com> Thu, 13 December 2018 06:41 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 B8F0C128CFD for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 22:41:55 -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 l4b54AXYwoRV for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 22:41:54 -0800 (PST)
Received: from out-12.smtp.github.com (out-12.smtp.github.com [192.30.254.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B9F12875B for <quic-issues@ietf.org>; Wed, 12 Dec 2018 22:41:54 -0800 (PST)
Date: Wed, 12 Dec 2018 22:41:53 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544683313; bh=HxQwIK2by6JQrErHCprlWdeu+quOVbB2oO7keZG4K74=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=nvAiZAUALG/lRUW/5IyXMD6GWCcnp8dEt44YC2fUmTjOvbuKYx/H/+I940nruWGXB dIrAuaeWHsbRxb0yZBz2iBM/3xcnxg6tnjjx8py43THrK1dl9Sulc6E+Cjo5WWV0Dp lgqwIIabQTy1dNpyLt/2RaD5h3Agk3WwpcnwzIkI=
From: plakhera <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abeba1bd47a4d43740752dd74982e0b3850b1b6cd892cf000000011829c13192a169ce1742d117@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/446859554@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_5c11ff3133eb9_22933fe97bcd45c04004a5"; 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-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/WRkrEd82fqMgocUZz5h0LbdS6yc>
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 06:41:56 -0000

> @plakhera, my comment about addresses local to the client was thinking more about a server which is v4-only won't know how to construct a corresponding IPv6 address for the client network's NAT64. The client would expect to discover those via DNS64 and needn't know that there's a relationship between the addresses.
> 
> Is there precedent for the NAT64 address mapping being (un)done on the client?

Server need not know about the DNS64 prefix in client's network. It would only needs to share its addressing information with client. it's the responsibility of the client to synthesize IPv6 address from it if needed (post PLAT discovery).

-- 
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-446859554

v2.23.0 | Report a Bug | By Email