Re: IPv6 only host NAT64 requirements?

Mark Andrews <marka@isc.org> Wed, 15 November 2017 10:17 UTC

Return-Path: <marka@isc.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 099FE129459 for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 02:17:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 3xq9RjsC9yCU for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 02:17:40 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 0D7F9126CE8 for <ipv6@ietf.org>; Wed, 15 Nov 2017 02:17:40 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id AED503B33A7; Wed, 15 Nov 2017 10:17:36 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7339A16003F; Wed, 15 Nov 2017 10:17:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 61535160087; Wed, 15 Nov 2017 10:17:36 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZtV7EdIyMdyQ; Wed, 15 Nov 2017 10:17:36 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 859C916003F; Wed, 15 Nov 2017 10:17:35 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Mark Andrews <marka@isc.org>
In-Reply-To: <71004332-84A3-4175-93C0-AE69D777F04D@consulintel.es>
Date: Wed, 15 Nov 2017 21:17:32 +1100
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9160BE92-BA4B-4442-B8FB-46B86A5E8858@isc.org>
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> <71004332-84A3-4175-93C0-AE69D777F04D@consulintel.es>
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/cIRLKpuY_lHHd03YJqWHSTtKJq0>
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: Wed, 15 Nov 2017 10:17:42 -0000

> On 15 Nov 2017, at 7:06 pm, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
> 
> 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?
> 
> [Jordi] Mark, this will not work: You need to consider that even if the phone is dual stack, there may be IPv4-only devices behind the phone (tethering), that NEED a DNS64. If the IPv4 device is validating, then is broken. If the IPv4 devices is not validating, then because the phone act as DHCP server for it, and provides the DNS, the phone acts as the DNS64 and even validator, then we are set … but phones today don’t do DNSSEC.

and the IPv4 device sends a IPv4 packet to the phone which then runs it through the CLAT to
translate it into a IPv6 packet which is sent to the NAT64 which turns it back into a IPv4 packet.
None if this requires a DNS64 server.   All DNS64 does is reduce the number of IPv4 packets
that are translated by the CLAT.  It does not reduce the work of the NAT64.


>    Mark
> 
>> On 14 Nov 2017, at 4:11 am, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
>> 
>>>> (c) Every ICMPv6 error message (type < 128) MUST include as much of
>>>>  the IPv6 offending (invoking) packet (the packet that caused the
>>>>  error) as possible without making the error message packet exceed
>>>>  the minimum IPv6 MTU
>>> 
>>> Right. But when is that an actual issue for applications?
>> 
>> First, I naively put this in my TCP implementation. Technically that's
>> not an application, though user land TCP does occur.
>> 
>> It also breaks my traceroute implementation.
>> 
>>> Then we are stuck with dual stack.
>>> What Randy and Jen set out to try in the IETF experiment was to figure 
>>> out if it would be possible to do IPv6 only + NAT64. Identify what was 
>>> broken and then get that fixed. If we're stuck with dual stack (or IPv4 
>>> only), then we're not moving towards the end-goal, are we?
>> 
>>> From a host point of view, I very much want to be dual stack. No magic.
>> What goes over the wire is what the application sees. IPv6 is complex enough
>> on its own. Adding DNS64/NAT64 make it less likely that people can actually
>> understand what is going on. 
>> 
>> Hosts being dual stack doesn't say anything about backbone networks. You
>> can do 464xlat on access routers or any other kind of IPv4 tunneling
>> technology. By tunneling on access routers you can even preserve a 1500 octet
>> MTU for IPv4.
>> 
>> In my view, the way we move to the end goal is when some networks really don't
>> have any IPv4 anymore. 
>> 
>> When IPv6-only eyeball networks appear that don't offer any kind of IPv4
>> connectivity, content providers either add support for IPv6 or they lose that
>> group of potential customers.
>> 
>> After a while, cheap consumer networks just drop IPv4 because it too expensive
>> to maintain. 
>> 
>> That's when IPv4 becomes truly legacy: you may have IPv4 connectivity at work,
>> but possible not at home. Not at a random place that offers wifi, not in
>> your hotel.
>> 
>> In corporate environments, assuming that all legacy applications can get
>> rewritten to support IPv6, the next step is to install proxies that offer
>> access to the few essential external services that are still IPv4 only.
>> Though possibly, those services start installing reverse proxies to offer
>> IPv6.
>> 
>> The only thing offering NAT64 to hosts does is making access networks IPv6-only
>> while introducing a lot of complexity without increasing end-to-end IPv6
>> connectivity.
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
>    -- 
>    Mark Andrews, ISC
>    1 Seymour St., Dundas Valley, NSW 2117, Australia
>    PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> 
>    --------------------------------------------------------------------
>    IETF IPv6 working group mailing list
>    ipv6@ietf.org
>    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>    --------------------------------------------------------------------
> 
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org