Re: IPv6 only host NAT64 requirements?

Mark Andrews <marka@isc.org> Mon, 13 November 2017 22:46 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 480F5124239 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 14:46:19 -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 zxu1IGD2Y2Qo for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 14:46:17 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 8C63A120724 for <ipv6@ietf.org>; Mon, 13 Nov 2017 14:46:17 -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 0E8FD3B6B87; Mon, 13 Nov 2017 22:46:14 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D9DF3160086; Mon, 13 Nov 2017 22:46:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BDA9F160087; Mon, 13 Nov 2017 22:46:13 +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 082STSCnrzUV; Mon, 13 Nov 2017 22:46:13 +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 E0AC9160086; Mon, 13 Nov 2017 22:46:12 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
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: <m1eEIGX-0000FjC@stereo.hq.phicoh.net>
Date: Tue, 14 Nov 2017 09:46:10 +1100
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <73231F8D-498E-4C77-8DA8-044365368FC9@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>
To: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/N3Q7ZVNgQ8oc91KHZ5SluIwaRK8>
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 22:46:19 -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?

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