Re: IPv6 only host NAT64 requirements?

Lee Howard <lee@asgard.org> Mon, 20 November 2017 21:05 UTC

Return-Path: <lee@asgard.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 27AAC12E056 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 13:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=no 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 oo4q44D_6tcX for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 13:05:27 -0800 (PST)
Received: from atl4mhob17.registeredsite.com (atl4mhob17.registeredsite.com [209.17.115.110]) (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 9EE3D128CD5 for <ipv6@ietf.org>; Mon, 20 Nov 2017 13:05:27 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob17.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAKL5OTG046284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ipv6@ietf.org>; Mon, 20 Nov 2017 16:05:25 -0500
Received: (qmail 26200 invoked by uid 0); 20 Nov 2017 21:05:24 -0000
X-TCPREMOTEIP: 184.185.35.18
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.2.160?) (lee@asgard.org@184.185.35.18) by 0 with ESMTPA; 20 Nov 2017 21:05:24 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Mon, 20 Nov 2017 16:05:19 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: Lee Howard <lee@asgard.org>
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Message-ID: <D638AAD2.8C6F2%lee@asgard.org>
Thread-Topic: IPv6 only host NAT64 requirements?
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAFU7BARoXgodiTJfTGc1dUfQ8-ER_r8UOE1c3h-+G0KTeCgBew@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <F9E3BD88-38E0-4329-A4BF-22083A023268@employees.org> <f673d6c7-570e-b2b8-e8aa-15d73ea8ba3f@gmail.com> <e697e64116f245f0b462a1a2277c704b@XCH15-06-11.nw.nos.boeing.com>
In-Reply-To: <e697e64116f245f0b462a1a2277c704b@XCH15-06-11.nw.nos.boeing.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ntt3s_pHeWLu4i8GKFIGkabU7UE>
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: Mon, 20 Nov 2017 21:05:29 -0000


On 11/21/17, 4:12 AM, "ipv6 on behalf of Manfredi, Albert E"
<ipv6-bounces@ietf.org on behalf of albert.e.manfredi@boeing.com>; wrote:

>-----Original Message-----
>From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
>
>> However, as long as even one application, such as one VPN, or one
>> literal IPv4 address, fails, that represents millions of failure
>> cases if we consider the whole world (e.g. imagine every hotel
>> network in the world running IPv6+NAT64 only).
>
>Very instructive thread for me, I must say. I'm getting this sense of
>urgency, to be rid of IPv4, but it comes from the IETF 6man wg and some
>ISPs. Ultimately, it's not up to 6man to decide. It's up to device
>vendors, and up to the deployed base of devices. The IETF can only
>suggest, and ISP networks have to meet the real world needs.

It’s a multi-legged stool, where network operators, device vendors, and
content all have a role, and will make their own operational decisions.
Operators may decide not to support IPv4-only devices or applications, or
to charge more for them, or to provide translators. Device makers may
decide to support dual-stack, or CLAT, or IPv6-only, or IPv4-only. Etc.

>
>> Dual stack in every hotel room in the world is viable, from the
>> hotel guests' point of view.
>
>This seems the most practical answer, whether it's a client server model,
>such as in a hotel room, or a peer to peer network. In a mostly peer to
>peer network, the normal case would be for IPv6 hosts to be introduced
>gradually. I'm not sure how anything other than dual stack can work, in
>this case. If the goal is to have continuous robust operation of the
>network, during an indefinitely long transitional phase, because no one
>up the chain could care less about the nitty gritty, they just want
>everything to keep working flawlessly, then what motivation would there
>be for anything other than dual stack?

IPv4 addresses selling for US$15 each and rising? At what price do
operators stop doing native dual stack?

> The only practical solution is to introduce IPv6 hosts only if they are
>dual stack. And then carefully, on a case by case basis, individual
>subsystems that do not need to interoperate with IPv4 subsystems can shut
>off IPv4.

It’s too late for dual-stack to be the transition plan.

>
>I realize that such transition drag on for years. But again, in the
>greater scheme of things, this matters very little to those who must make
>sure the systems work at all times.

Yes, years.
https://pbs.twimg.com/media/C_vRuRUXYAAwxN5.jpg:large
Five years until 90% of hosts have IPv6. It’s going to be a bumpy few
years, especially for those who insist IPv6 is somebody else’s problem.

Lee