Re: IPv6 only host NAT64 requirements?

Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> Mon, 13 November 2017 17:11 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 BE8831205D3 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 09:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 x-aowBCXETdS for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 09:11:27 -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 69C6F129B20 for <ipv6@ietf.org>; Mon, 13 Nov 2017 09:11:26 -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 m1eEIGX-0000FjC; Mon, 13 Nov 2017 18:11:21 +0100
Message-Id: <m1eEIGX-0000FjC@stereo.hq.phicoh.net>
To: ipv6@ietf.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>
In-reply-to: Your message of "Tue, 14 Nov 2017 00:34:59 +0800 ." <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>
Date: Mon, 13 Nov 2017 18:11:15 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4ZtNVBtZbzNkuUtq0A6dPFQZG0Q>
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 17:11:29 -0000

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