Re: IPv6 only host NAT64 requirements?

Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> Mon, 13 November 2017 23:08 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
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 39BB312717E for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 15:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 l8kYZOo3bKrU for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 15:08:31 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 5EDF6120227 for <ipv6@ietf.org>; Mon, 13 Nov 2017 15:08:30 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eENq7-0000FkC; Tue, 14 Nov 2017 00:08:27 +0100
Message-Id: <m1eENq7-0000FkC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Mark Andrews <marka@isc.org>
Subject: Re: IPv6 only host NAT64 requirements?
From: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.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>
In-reply-to: Your message of "Tue, 14 Nov 2017 09:46:10 +1100 ." <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
Date: Tue, 14 Nov 2017 00:08:26 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/y53u3mLwQMeIl_1gCTPv1FZH6CI>
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, 13 Nov 2017 23:08:33 -0000

> Is there any reason to
> run DNS64 at all these days?  ipv4only.arpa can be a preconfigured
> zone which allows CLAT to get its mapping.  All the phones have
> CLAT support.  Can we just make DNS64 historic and let the phones
> run all IPv4 connections through CLAT rather than having to stuff
> up DNSSEC and have IPv6 connections terminate in IPv4 servers
> without the application knowing?

If NAT64 was limited to 3GPP interfaces then not a lot of people would care.

The problem started when a vocal group tried to push NAT64 as a general
purpose mechanism for providing IPv4 access.

In that context, there are lots of devices that do implement IPv6, but
do not implement CLAT.

So without DNS64 those devices would lose access to the IPv4 internet.

If you are willing have a stateful NAT box in your network, and requiring
host changes is acceptable, then ds lite is in interesting alternative. 
One that avoids having a NAT function on the host.