Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 20 November 2017 08:33 UTC

Return-Path: <otroan@employees.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 1C1041294B7 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 00:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 M7DUrwPmBS4e for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 00:33:37 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85621294B8 for <ipv6@ietf.org>; Mon, 20 Nov 2017 00:33:34 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 079FD2D4F99; Mon, 20 Nov 2017 08:33:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 48A1D200C8E3FB; Mon, 20 Nov 2017 09:33:31 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_6B8DAD20-9F85-4D2D-8535-8836E7CD519C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 09:33:30 +0100
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Cc: Jen Linkova <furry13@gmail.com>, 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
To: Mohamed Boucadair <mohamed.boucadair@orange.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> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAFU7BARoXgodiTJfTGc1dUfQ8-ER_r8UOE1c3h-+G0KTeCgBew@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/745oFc5-QDpyb3ogvDyaBVqDrG8>
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, 20 Nov 2017 08:33:39 -0000

Hi Med,

>> 
>> For the IETF NAT64 IMHO
> 
> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the appropriate "IPv4 service continuity" solution here.

Why not?
Interesting to hear your views here, especially since it "almost" worked at IETF100.

> I need:
>> - No dependency on DNS64. Want to use recursive resolver I trust plus
>> local validating resolver.
>> - Not depend on the success of PCP for NAT64 prefix discovery
>> - If the host couldn't learn the NAT64 prefix any other way, I suppose it
>> could throw an ICMP echo towards
>>   64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)
>> 
> 
> [Med] Fair. That is another "add my favorite solution" to the list.
> 
>> But I also see there being different deployment options here.
>> Btw, for multiple NSPs, couldn't you partly solve that by injecting more
>> specifics into routing?
> 
> [Med] It is not only about forwarding/routing, but also how a host can pick the appropriate prefix64 for address synthesis. Things may be obvious if you can consider the example of RFC7050:
> 
> 
>                      NAT64 "A" ----- IPv4-only servers in a data center
>                     /
>   IPv6-only node---<
>                     \
>                      NAT64 "B" ----- IPv4 Internet

Firstly this seems like it is over engineered. Has anyone actually deployed NAT64 this way?
(Given that this is quite rare even in IPv6 only or IPv4 only scenarios. Look at implementation status of RIO for example).

Secondly, RFC7050 says:

   The heuristic discovery method described herein does not support
   learning of the possible rules used by a DNS64 server for mapping
   specific IPv4 address ranges to separate Pref64::/n prefixes.
   Therefore, nodes will use the same discovered Pref64::/n to
   synthesize IPv6 addresses from any IPv4 address.  This can cause
   issues for routing and connectivity establishment procedures.  The
   operator of the NAT64 and the DNS64 ought to take this into account
   in the network design.

Which to me reads, this just doesn't work.

If we think NAT64 is a fundamental piece of technology to make progress on the transition, then I think we should focus on making it as simple and deployable as possible.

Cheers,
Ole