RE: IPv6 only host NAT64 requirements?

<mohamed.boucadair@orange.com> Thu, 16 November 2017 07:29 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 635CB126D73 for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 23:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 iDFbvOO7xL2z for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 23:29:47 -0800 (PST)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59045120724 for <ipv6@ietf.org>; Wed, 15 Nov 2017 23:29:47 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id EF03820FA8; Thu, 16 Nov 2017 08:29:45 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id D00F71A0059; Thu, 16 Nov 2017 08:29:45 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 08:29:45 +0100
From: <mohamed.boucadair@orange.com>
To: Ole Troan <otroan@employees.org>, james woodyatt <jhw@google.com>
CC: 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: AQHTXkUPM5Da2AC8eUW6xsTjimyrvqMV6UmAgAAVjYCAAAW7gIAAic2g
Date: Thu, 16 Nov 2017 07:29:44 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07B5B0@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> <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> <AEA51AB8-63B0-4CAA-A085-5290F5987E92@employees.org>
In-Reply-To: <AEA51AB8-63B0-4CAA-A085-5290F5987E92@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.6]
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/gkXKjRWYr02tnUOrWrJ4Qd_3GUk>
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: Thu, 16 Nov 2017 07:29:49 -0000

Ole, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Ole Troan
> Envoyé : jeudi 16 novembre 2017 00:25
> À : james woodyatt
> Cc : 6man WG; Mark Andrews
> Objet : Re: IPv6 only host NAT64 requirements?
> 
> James,
> 
> >>
> >>>> IMHO the optimal solution is:
> >>>> - the network SHOULD provide a host with NAT64 prefix information in
> RA;
> >>>
> >>> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye
> gods, this is the very last thing that should be jammed into RA messages.
> >>
> >> Do we really want PCP in IPv6?
> >
> > If we have any kind of NAT, then we need PCP. Using NAT without PCP
> considered harmful. That goes for NAT64 and NAT66.
> 
> It's not for the lack of trying that IPv6 isn't adopted everywhere.
> As IPv4 address sharing ratio's increase, say good bye to endpoint
> independent NATs, IP fragmentation...
> 
> But now I have to first implement a PCP client, discover the PCP server
> address, and then finally get the NAT64 prefix. ;-)

[Med] This is more subtle. You don't need to implement PCP to discover NAT64 prefixes, but because of other NAT64 problems (e.g., allow for incoming connection, referrals, reduce keepalive messages, etc.) PCP is your friend. In such case, prefix discovery using PCP is more determinist compared to the heuristic (there are also many other issues unsolved when using the heuristic). 

My take on this is this wording from RFC7849:

==
   C_REC#7:  In order to ensure IPv4 service continuity in an IPv6-only
             deployment context, the cellular host should support a
             method to learn PREFIX64(s).

                ...

                In environments based on the Port Control Protocol
                (PCP), cellular hosts should follow [RFC7225] to learn
                the IPv6 Prefix used by an upstream PCP-controlled NAT64
                device.  If PCP is not enabled, the cellular host should
                implement the method specified in [RFC7050] to retrieve
                the PREFIX64.
==
 

> 
> >> Is PCP successful in IPv4?
> >
> > Well, there was this:
> <https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>
> >
> >> Or does it even work well with A+P based solutions?
> >
> > Designed expressly for it.
> 
> Ah, yes so it does.
> Doesn't work well with address and port dependent filtering though.
> 
> Cheers,
> Ole