Re: IPv6 only host NAT64 requirements?

Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> Mon, 13 November 2017 16:16 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 31189129AF9 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 08:16:35 -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 sEiN7NMj9yx4 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 08:16:34 -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 980FC1200F1 for <ipv6@ietf.org>; Mon, 13 Nov 2017 08:16:33 -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 m1eEHPS-0000FyC; Mon, 13 Nov 2017 17:16:30 +0100
Message-Id: <m1eEHPS-0000FyC@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>
In-reply-to: Your message of "Mon, 13 Nov 2017 23:35:43 +0800 ." <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org>
Date: Mon, 13 Nov 2017 17:16:29 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/cpA2WTC3P5rhde5ZUh-s3JgXPUM>
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 16:16:35 -0000

>Yes, that's certainly the bind we are in. Are we going to require all 
>IPv6 only nodes to be able to communicate with IPv4? And what does that 
>entail? Do you have examples of "all kinds of IPv4 issues"?
>
>Apart from the requirement of NAT64 prefix discovery and IPv4 
>synthesising, is there anything you don't need to do anyway?

One that really breaks my code, and is relevant to 6man is the guarantee in
IPv6 error ICMPs:

(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


>While I'm also concerned about the consequences of carrying IPv4 debt in 
>all IPv6 implementations, the alternative seems to be that we are stuck 
>with Dual stack forever (for some definition of forever). This would at 
>least allow us to move to single stack IPv6. Which appears to me to be a 
>step forward. And we're very close to that already, and there are 
>millions of devices already implementing it.

In new applications that are simple from a networking point of view, it should
be possible to come up with a design that works well for both dual stack and
NAT64.

Operators who have lots of legacy devices are likely to run a dual stack
network. So hosts that are expected to work in such an environment have to
implement dual stack.

I'm not sure how (outside 3GPP) anyone can transition to NAT64. You have to
make sure that all devices that need to connect support NAT64. To do that,
you probably want to run dual stack for a while to make sure everything 
supports IPv6 properly. 

But for host software there is a lot more incentive to support dual stack then
to do the extra step for NAT64.

The big problem I see for NAT64 is that for old IPv4-only applications you 
have to make two fundamental changes to the application. The first to 
make sure that the application handles IPv6 in every possible way. And a
second pass that makes sure that every place where an IPv4 address literal 
is handled, works with NAT64. 

For an application writer it is better to try to avoid doing the second pass.