RE: IPv6 only host NAT64 requirements?

<mohamed.boucadair@orange.com> Mon, 20 November 2017 12:21 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 C10B4129568 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 04:21:32 -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 zt3rF12J93ZN for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 04:21:31 -0800 (PST)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00C01200FC for <ipv6@ietf.org>; Mon, 20 Nov 2017 04:21:30 -0800 (PST)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 39B2840E57; Mon, 20 Nov 2017 13:21:29 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 1AE201C0070; Mon, 20 Nov 2017 13:21:29 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 13:21:28 +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: AQHTYeum5aCFTrEcrUibDPVkNExo9aMdK0uA
Date: Mon, 20 Nov 2017 12:21:27 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07D63D@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> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org>
In-Reply-To: <26A31D20-46C2-473E-9565-59E5BA85ED8B@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/AV8a5AVmNKlWqgDJgVd6nLsMmP4>
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 12:21:33 -0000

Re-,

Please see inline. 

Cheers,
Med

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

[Med] You should admit that there are questions that don't make sense if not contextualized.  

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

[Med] These are generic statements, Ole. We are talking about the IETF case. 
* The IETF has no control on the hosts that connect to the IETF network,
* IETF attendees who are using corporate devices, have no control on these hosts

So, how forcing devices to use "IPv6+nat64" will help here? 

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

[Med] It depends for "which user", Ole. Consider the example of a bittorrent user who may prefer IPv6 vs. IPv4.

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

[Med] I know. There is no reco to achieve NAT64 load-balancing. It is legitimate to hear from both of them. 

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

[Med] More concretely? 

> 
> Cheers,
> Ole