IETF Logo Mail Archive

Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Sun, 19 November 2017 01:03 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CA4126CE8 for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 17:03:28 -0800 (PST)
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 gy37AUGwBtG3 for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 17:03:27 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F7B126CBF for <ipv6@ietf.org>; Sat, 18 Nov 2017 17:03:27 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 6772A2D5126; Sun, 19 Nov 2017 01:03:26 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C0DB7200C79A4F; Sun, 19 Nov 2017 02:03:24 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <CFDD8D9E-0726-46C1-9CC7-5C88DD111E9D@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_4B0BE73A-47C3-49AE-B505-7E3A087F6716"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Sun, 19 Nov 2017 02:03:23 +0100
In-Reply-To: <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>
Cc: Jen Linkova <furry13@gmail.com>, 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <CAFU7BARaJHKOyrD1KAeorbYQwgsmxBLk1QELH+wZ4=HDCP1q-w@mail.gmail.com> <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MiqCvs7-aSfSpF2SvEkkswnN5SU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 01:03:29 -0000

Brian,

> To be clear: I used ietf-nat64 all week, and all the things that didn't work
> are not an issue on a dual-stack network. From the host's point of view,
> dual-stack is definitively superior, IMNSHO, and nothing is going to
> change that. NAT64 is second-best. It may appear to be cheaper for some
> operators in some scenarios, that's all.

From that perspective, "IPv4 only" is still best. But that's not where we want to be, is it?

The original transition plan was for all networks, hosts and application to be dual-stacked, then when that point was reached, there would be no more traffic on the "IPv4 Internet" and it could be turned off. We now know that this point is not within sight.

Dual-stack as a transition is a failure. Dual-stack is a deployment model where we bear the cost caused by the IPv4 laggards.

IPv6 only + NAT64 is progress. It relegates IPv4 to the edges.
We want a situation where IPv4 only services are fronted by IPv6, and the cost born by those operating those services.

The challenge we have in front of us is to make IPv6 only work.

Ole

v2.23.0 | Report a Bug | By Email