RE: IPv6 only host NAT64 requirements?

<mohamed.boucadair@orange.com> Thu, 16 November 2017 07:28 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 A9606120724 for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 23:28:42 -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 OBYBM-G54Kux for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 23:28:41 -0800 (PST)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF99124319 for <ipv6@ietf.org>; Wed, 15 Nov 2017 23:28:41 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 03B3E60F21; Thu, 16 Nov 2017 08:28:40 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id DA024C0062; Thu, 16 Nov 2017 08:28:39 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 08:28:39 +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: AQHTXkUPM5Da2AC8eUW6xsTjimyrvqMV6UmAgACh+9A=
Date: Thu, 16 Nov 2017 07:28:38 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07B59C@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>
In-Reply-To: <5D9D33A8-88F0-4758-84FA-BCB364E8013F@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/nZStMAzkG4JehWqYzqwJddQzRDU>
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:28:43 -0000

Hi Ole, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Ole Troan
> Envoyé : mercredi 15 novembre 2017 22:47
> À : 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?

[Med] IPv6 Firewalls, NAT64, and NPTv6 are target use cases for PCP. All those were taken into account when designing PCP. 

> Is PCP successful in IPv4?

[Med] PCP is a deployment reality. Most of CGN vendors are implementing PCP. 

 Or does it even work well with A+P based
> solutions?

[Med] Why do you want PCP for A+P? 

Please remember that we have indicated the following in draft-ietf-softwire-stateless-4v6-motivation: 

====
3.1.4.  No Additional Protocol for Port Control is Required

   Stateless solutions do not require activating a new dynamic signaling
   protocol in the end-user CPE in addition to those already used.  In
   particular, existing protocols (e.g., UPnP IGD:2 [UPnP-IGD]) can be
   used to control the NAT mappings in the CPE.

      Note: To overcome some security concerns, IGD:2 authorization
      framework [UPnP-IGD] should be used and security considerations
      elaborated in [Sec_DCP] should be taken into account.
====

> 
> >
> >>  (I do not believe that information needs to be duplicated in DHCP at
> all)
> >
> > Totally agree about that.
> 
> Appears this isn't as simple a problem as I thought. Let me read 7051 in
> it's excruciating detail.
> 
> Guess we're stuck.
> 
> Best regards,
> Ole