RE: IPv6 only host NAT64 requirements?

"Manfredi, Albert E" <> Mon, 20 November 2017 20:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFAF3129C4B for <>; Mon, 20 Nov 2017 12:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ah7VvrknZ-BP for <>; Mon, 20 Nov 2017 12:12:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70BAE126BF7 for <>; Mon, 20 Nov 2017 12:12:22 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAKKCKjN001475; Mon, 20 Nov 2017 13:12:20 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vAKKCHZu001359 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 13:12:17 -0700
Received: from (2002:8988:efdc::8988:efdc) by (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 12:12:16 -0800
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 12:12:16 -0800
From: "Manfredi, Albert E" <>
To: Brian E Carpenter <>
CC: 6man WG <>
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 20:12:16 +0000
Message-ID: <>
References: <> <> <> <> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Nov 2017 20:12:24 -0000

-----Original Message-----
From: ipv6 [] 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.

> 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? 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.

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.