IETF Logo Mail Archive

Re: [v6ops] draft-ietf-v6ops-nat64-srv

Gábor Lencse <lencse@hit.bme.hu> Thu, 16 May 2019 03:04 UTC

Return-Path: <lencse@hit.bme.hu>
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 060851200DE for <v6ops@ietfa.amsl.com>; Wed, 15 May 2019 20:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 9imSFF2xZLCU for <v6ops@ietfa.amsl.com>; Wed, 15 May 2019 20:04:25 -0700 (PDT)
Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F9E12029E for <v6ops@ietf.org>; Wed, 15 May 2019 20:04:25 -0700 (PDT)
Received: from [10.206.214.27] (71.65.214.202.bf.2iij.net [202.214.65.71]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x4G34EBI084006 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <v6ops@ietf.org>; Thu, 16 May 2019 05:04:21 +0200 (CEST) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host 71.65.214.202.bf.2iij.net [202.214.65.71] claimed to be [10.206.214.27]
To: v6ops@ietf.org
References: <BYAPR05MB4245A78BEC3D7E3622A38395AE0F0@BYAPR05MB4245.namprd05.prod.outlook.com> <alpine.DEB.2.20.1905131848190.1824@uplift.swm.pp.se> <CAAedzxrdKSricUvJxEBLP7Jb2UmoNbSmEpDwx9bGAzOYQNhNcQ@mail.gmail.com> <9520F111-F282-4B9A-8D50-BDF37793F8B9@gmail.com>
From: Gábor Lencse <lencse@hit.bme.hu>
Message-ID: <4ddf3ed2-fe9f-48a9-80ec-e0de7a4e9870@hit.bme.hu>
Date: Thu, 16 May 2019 12:04:09 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <9520F111-F282-4B9A-8D50-BDF37793F8B9@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu
X-Virus-Status: Clean
Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=202.214.65.71; helo=[10.206.214.27]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10;
X-DCC--Metrics: frogstar.hit.bme.hu; whitelist
X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ZCJkY1ghcUgR3QF5TZHax5WVoZY>
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 16 May 2019 03:04:32 -0000

On 5/16/2019 08:29, Dan Wing wrote:

[...]
> I agree with Erik that the NAT64 balancing seems a lot of effort for the client with little gain for the client. NAT64 as a technology will diminish as native IPv6 overcomes the IPv4 inertia so engineering fancy NAT64 solutions is not "where the hockey puck is going", as they say.

I agree that NAT64 should finally diminish, but I don't think that its 
diminishing would be imminent. On the contrary, I expect that it will be 
used for at least a decade or even more.

My student has just finished her BSc final project thesis about 
examining the transition to IPv6 on the basis of available statistics. 
Her conclusion is that the IPv6 transition technologies will remain with 
us for a long time. Some technologies that aimed to help the early 
adoption of IPv6 (such as 6to4 or 6rd) are diminishing and give their 
place to the IPv4aaS technologies, where also DNS64 and NAT64 belong to.

Therefore, I think it is worth dealing with this draft, which could be a 
useful update to RFC 7050.

Best regards,

Gábor Lencse

v2.23.0 | Report a Bug | By Email