IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 16 July 2018 12:03 UTC

Return-Path: <brian.e.carpenter@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 0DFC1130EAB for <v6ops@ietfa.amsl.com>; Mon, 16 Jul 2018 05:03:06 -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 WKN2FaiIMYes for <v6ops@ietfa.amsl.com>; Mon, 16 Jul 2018 05:03:03 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 11B86130DC7 for <v6ops@ietf.org>; Mon, 16 Jul 2018 05:03:03 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id l14-v6so27592702iob.7 for <v6ops@ietf.org>; Mon, 16 Jul 2018 05:03:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dRNcrFrfcaPvDEhifjy5chHy7dkVfQrNB/rrnSByee4=; b=vSG7wR3ZyzZHF/GAnUkysQYDlQoY+8//j8DbAuf8MBObi8WUDFxewM5MjrIDCTxhEU omjU1Fk8Tsksud3JGcG4FxhAACqCJ975aRhjmFQVO+hX+8/nTb6PABIa8zLEJKse1ebi u2hswt1Ah3lr8QfZIotXyekSSbkHebgg6puOSmwR9XsiEjW+UK4ZlmTQf3/Ci239b46R 56TG4WEIgUzgnjFHo48jV9TYNrVGZTXv46ixsGj0tvnzn9W04AK3NTuJWUUftijuw4ML 38yLwirwIDXDipjk2PgSrjjWV7BOfHUh0QH2F7rPEVKTMERj24ukQTamokYVrJ1/SCyO 1wkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dRNcrFrfcaPvDEhifjy5chHy7dkVfQrNB/rrnSByee4=; b=EYPGQdWOCQhFTrpYZ1HSc1Kz30GRrUOEhg1Yfvp/xY92yQNuBsm5/oY0lpWrfVNKNd hjXM+pizzfG/TTuJZg3dfDwgfIej1/j9GuSgL5RqtGpSqxZLokylRLLZH0nOaWhEyyEh M9IItr+MaguEeG+YNoHSz3u94yUb0vIjUyFIAXmnvfcSHG4V/VSWocoPfAQHA03G/+oJ +HkuNF2tw9dPISN3tzbg3q1SXA2R1LtJqe5loLV20RA3k/mb0K5ItMKJE0U/waMcSP1B 1tHAMLCtdyBVAJWqs/ZV1VQrXtPq6OI8GBCSbR4I60CfyzbX47ItgNTN24vb6DZI+gPR EQwQ==
X-Gm-Message-State: AOUpUlGDu/hYDgfcG9mR9wE3yqbNUMJpSCBT5D71Fp6rIEU1EFuSjSrQ bu4Am9TgHnl0DXKsJgpLuo0=
X-Google-Smtp-Source: AAOMgpf17h/20Mzly1IQO0/VaRqTyw4/E02+YYJTGhEZMIfF6qA5vUu7n0Eu/n9U7eH2RMWXX5h5Ug==
X-Received: by 2002:a6b:8dc7:: with SMTP id p190-v6mr40620318iod.303.1531742582330; Mon, 16 Jul 2018 05:03:02 -0700 (PDT)
Received: from [31.133.156.209] (dhcp-9cd1.meeting.ietf.org. [31.133.156.209]) by smtp.gmail.com with ESMTPSA id r18-v6sm6300104ita.15.2018.07.16.05.03.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jul 2018 05:03:01 -0700 (PDT)
To: Fred Baker <fredbaker.ietf@gmail.com>, xiechf.bri@chinatelecom.cn
Cc: "nick.heatley@bt.com" <nick.heatley@bt.com>, v6ops <v6ops@ietf.org>, KOSSUT Tomasz O-PL <tomasz.kossut@orange.com>, "Rajiv Asati (rajiva)" <rajiva=40cisco.com@dmarc.ietf.org>
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> <5E636164-1250-47A7-A440-378165B34347@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <9e1358aa-b962-539f-558b-dbd478ef3327@gmail.com>
Date: Tue, 17 Jul 2018 00:02:59 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5E636164-1250-47A7-A440-378165B34347@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6RBKgHHOz4awph9q7j_L6WQAmiA>
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 12:03:06 -0000

Fred,

On 16/07/2018 23:47, Fred Baker wrote:
> 
> 
>> 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.

That's true, but it applies regardless of whether the client accesses the
IPv4 content via a dual stack ISP or a NAT64 solution. The only way to
force a content provider to use IPv6 is by removing its IPv4 clients.
I don't think many consumer ISPs are going to do that.

So what we need is for IPv4 to be slower and less functional than IPv6,
which we can only reasonably arrange by making IPv6 better...

    Brian

v2.23.0 | Report a Bug | By Email