Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 20 November 2017 10:38 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 63DD8129530 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 02:38:04 -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, 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 xS6bpCL7Eh7r for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 02:38:02 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1C8120046 for <ipv6@ietf.org>; Mon, 20 Nov 2017 02:38:02 -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 E78EE2D5104; Mon, 20 Nov 2017 10:38:00 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 75160200C97B4B; Mon, 20 Nov 2017 11:37:57 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_024077A9-37BC-4D41-BCC1-4B0AC5C524BB"; 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 11:37:56 +0100
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07D534@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> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/aSRMMAOdmo4p3u_C3EsFK6wVZQM>
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 10:38:04 -0000

Med,

>>> 
>>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
>> appropriate "IPv4 service continuity" solution here.
>> 
>> Why not?
> 
> [Med] Because dual-stack can do the job without any extra effort.

That's not a valid answer, when the question to be explored is "Is it possible to run IPv6 only hosts?".

The arguments against dual stack:
 - expensive to operate
 - little progress towards the end goal of IPv6 only

I think you can make a fair case that the end-user experience today is best with IPv4 only.

>> Interesting to hear your views here, especially since it "almost" worked
>> at IETF100.
> 
> [Med] I don't have any doubt that NAT64 will work module some issues and fixes (more can be found in https://tools.ietf.org/html/rfc6889#section-3 (Analysis of Stateful 64 Translation)). There are deployments cases where these fixes are wroth to be enforced, while it is not justified in others. I'm for NAT64 as an "IPv4 service continuity" for mobile networks where there is a pressure on private IPv4 addresses, but I'm for DS-Lite and MAP-E for fixed networks given there is no implications on the host itself; the "complexity" will be hidden by a CPE.
> 
> It is a case by case exercise.

Again, trying to move us forward with IPv6 only hosts.

>>> 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?
> 
> [Med] This is a scenario that can be considered by some mobile operators at the Gi interface. Multiple prefixes are discussed in Section 4.2. of RFC7269 (NAT64 Deployment Options and Experience) that was produced by v6ops.

You can achieve load-balancing without having to push that requirement all the way down to the host.

>> (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.
> 
> [Med] Correct. This is one of the limitations of the heuristic approach.
> 
>> 
>> 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.
> 
> [Med] NAT64 spec does not make any assumption about the deployment case. Its limitations are well-known and documented since years.
> 
> IMHO, the required pieces for "simple" deployment scenarios are out there:
> - prefix discovery using the heuristic
> - local address synthesis to solve issues related to address literals/referrals.
> 
> Advanced features have been also specified, e.g.,
> - if you want to allow for incoming connections: e.g., access a video server
> - if you want to avoid overloading NAT64 with all sorts of ALGs
> - if you want to avoid draining the battery of your mobile because of the keepalive messages

Yep, but I think the cat is largely out of the bag here, and an application must work in the "smallest common denominator" network.

Cheers,
Ole