RE: IPv6 only host NAT64 requirements?

<mohamed.boucadair@orange.com> Mon, 20 November 2017 09:52 UTC

Return-Path: <mohamed.boucadair@orange.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 B5933129511 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 01:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6u_6qUhSheOz for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 01:52:24 -0800 (PST)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B6812762F for <ipv6@ietf.org>; Mon, 20 Nov 2017 01:52:24 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 9D98C100DF8; Mon, 20 Nov 2017 10:52:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 7A9E180086; Mon, 20 Nov 2017 10:52:22 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 10:52:22 +0100
From: mohamed.boucadair@orange.com
To: Ole Troan <otroan@employees.org>
CC: Jen Linkova <furry13@gmail.com>, 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTYdpD3uy1rjGI6UW4xb2YAmW0iqMc+Ubw
Date: Mon, 20 Nov 2017 09:52:22 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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>
In-Reply-To: <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9Vcl7VfmSTgEIApF91TB_fPWrAk>
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 09:52:26 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ole Troan [mailto:otroan@employees.org]
> Envoyé : lundi 20 novembre 2017 09:34
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Jen Linkova; 6man WG; Mark Andrews
> Objet : Re: IPv6 only host NAT64 requirements?
> 
> 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?

[Med] Because dual-stack can do the job without any extra effort.

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

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

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

> 
> Cheers,
> Ole