Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

Fred Baker <fredbaker.ietf@gmail.com> Mon, 16 July 2018 11:47 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B26D131006 for <v6ops@ietfa.amsl.com>; Mon, 16 Jul 2018 04:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oGgtSx0UgGEr for <v6ops@ietfa.amsl.com>; Mon, 16 Jul 2018 04:47:53 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984DA131007 for <v6ops@ietf.org>; Mon, 16 Jul 2018 04:47:51 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id 198-v6so12590969ite.4 for <v6ops@ietf.org>; Mon, 16 Jul 2018 04:47:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=pBSrNaZPDMH/HS5djtiIcNgqc/juYwiR5CIlEPXC8LY=; b=qVHZU8QWaxlvNJ1TuDf1wlpypmnz2KaA2eceBWgY3N/85ay1f8MQMM9Xx+TEHEta9i mEFjPcz2lBh+fOZT7XHf7gyYSOUxd83GzQ9a/uf9PU++BqoBWxgWkS+zZZG8IMBVpnIj FcKnWE9RlhawQH8ZY7PjcIfbdJzWTqjfmnCSyDy28Gnh8TJ9nF2B9CBFH+p4XDviLP/G k4SGfB1Bf2nFEz6bitrijnmTFZkY+sExqVdb2jyX8WbtsAjeSCYuoAOukWrWqT9rnJq4 YV95Mn2vj2HObtK7157N1X90Z+HINuBoXV3/4vT9A1Eycjz6MkAbF6SemllsI0UXOULe pjew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pBSrNaZPDMH/HS5djtiIcNgqc/juYwiR5CIlEPXC8LY=; b=DiCTU7RLPLKYyjD6wapLyRGDpdtyjoSHNPSvAviKenDwMpfSeckTyYMdI5ZB1sQF8v I39iywsqvLTnH5qL7GIgm86vp+BVNCfZTXtj2FEEyM5ebfEQBNiO7+1F10OY2Z/QSJEH Lmw8W+r0J+cdXLVqGo6udUG0/3v+rj1I/YtITHiywPzmjDkhhpQRDF4BzvEV9//BdaMm 1b4LW3JxfcFFFqQMCiC0ibA+QiybPDhx3FuaiCl9ZPNWtr3vqzpOeQhDwFJfNl2n0Nrv u7GOQ80sxGHkEGpW87PelOUIjigfNczd1RoqQl/w6EqJ9AmHu0+uVzfLiOF5H1IEgt8x NNgg==
X-Gm-Message-State: AOUpUlE5eg9xuhxr/LFuN7WJWpA5OwzPJSRACnOI5WuIiEOxk085pmPt toLvPH5W7RDsKzGC++6Uvy8=
X-Google-Smtp-Source: AAOMgpf0V1gy/rU9fiTmIkQ0DLFQDzY0d+QL+T3h9Q15/emHIGm5U64w9pjcj3KJRsi/AMOG2+pNxA==
X-Received: by 2002:a02:10c6:: with SMTP id 189-v6mr14149356jay.54.1531741670944; Mon, 16 Jul 2018 04:47:50 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:61cc:64a:c911:a9ef? ([2001:67c:1232:144:61cc:64a:c911:a9ef]) by smtp.gmail.com with ESMTPSA id 7-v6sm8033299itz.12.2018.07.16.04.47.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jul 2018 04:47:50 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_9A0D0BEF-6BF8-4DD4-8FAA-EAB47163846F"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Fred Baker <fredbaker.ietf@gmail.com>
X-Priority: 3
In-Reply-To: <2018071609524852778154@chinatelecom.cn>
Date: Mon, 16 Jul 2018 07:47:48 -0400
Cc: "Rajiv Asati (rajiva)" <rajiva=40cisco.com@dmarc.ietf.org>, "nick.heatley@bt.com" <nick.heatley@bt.com>, v6ops <v6ops@ietf.org>, KOSSUT Tomasz O-PL <tomasz.kossut@orange.com>
Message-Id: <5E636164-1250-47A7-A440-378165B34347@gmail.com>
References: <CAD6AjGQqaQumYyBPVG6qkc9cs+jSGFKgUnGHkMfJmtes5Fk47g@mail.gmail.com> <AD5D4A8E-8A02-463B-A222-3D32A6235DF4@gmail.com> <CAD6AjGQsDq1ELdZPnaAtbZPq5SZoXbD--W5JS5tkN63J1D=W9g@mail.gmail.com> <2F5CCC76-4364-4B66-B956-199969CFFCB4@isc.org> <LO1P123MB009802AF44568758A8A3ECB4EA410@LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM> <3fa26b65c7c64eada0ae04caa0a94ddf@orange.com> <20180712130103.GQ11393@Space.Net> <787AE7BB302AE849A7480A190F8B93302DF599FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2B33FCAF-C612-45FC-AA9F-7F087F164937@cisco.com> <BA45FF0F-D492-43BF-A56F-6155A7F6B962@gmail.com> <2018071609524852778154@chinatelecom.cn>
To: xiechf.bri@chinatelecom.cn
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/taYR2e2GHA5UZ0tYgCTINdPePFE>
Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2018 11:47:54 -0000


> On Jul 15, 2018, at 9:52 PM, xiechf.bri@chinatelecom.cn wrote:
> 
> One of the debate about NAT64 is that it will slow down the transition process of IPv6, for it allow the existance of IPv4, especially in the content side, the OTT, especially smaller ones,  will have less incentive to move to IPv6. I do not mean that this point is right,  but this draft should give some explanation or clarification to this issue.

To my way of thinking, which may or may not be correct, that can be argued either way. The existence of stateless and stateful translation has enabled 464XLAT to be used to make some networks IPv6-only (the CLAT being stateless and the PLAT being stateful) although the entire world has not switched. I would expect that few would even consider turning IPv4 off without some means of accessing IPv4-hosted content. So the existence of translation hasn't slowed that rush; it has enabled it. On the other hand, if IPv4-hosted content is still accessible, there is also no pressure to make it IPv6-accessible.