IETF Logo Mail Archive

RE: IPv6 only host NAT64 requirements?

<mohamed.boucadair@orange.com> Fri, 17 November 2017 06: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 1D38D126B72 for <ipv6@ietfa.amsl.com>; Thu, 16 Nov 2017 22:52:56 -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 dILTVGPGR_oO for <ipv6@ietfa.amsl.com>; Thu, 16 Nov 2017 22:52:54 -0800 (PST)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419E31200E5 for <ipv6@ietf.org>; Thu, 16 Nov 2017 22:52:54 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 01F69100DCE; Fri, 17 Nov 2017 07:52:53 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id D83DD80070; Fri, 17 Nov 2017 07:52:52 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 07:52:52 +0100
From: mohamed.boucadair@orange.com
To: Michael Richardson <mcr@sandelman.ca>, 6man WG <ipv6@ietf.org>
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXxxYyuElU1W99UW2Cmkb+owWL6MYIL0Q
Date: Fri, 17 Nov 2017 06:52:51 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07C3DA@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> <20377.1510865334@obiwan.sandelman.ca>
In-Reply-To: <20377.1510865334@obiwan.sandelman.ca>
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/B7HZ7MYcl5hret10R4nJa8OWHGQ>
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: Fri, 17 Nov 2017 06:52:56 -0000

Hi Michael, 

For the particular case of NAT64, this requirement from RFC6888 applies: 

   REQ-9:  A CGN MUST implement a protocol giving subscribers explicit
      control over NAT mappings.  That protocol SHOULD be the Port
      Control Protocol [RFC6887].

I'm not aware of any requirement for the LAN. The only recommendation I'm aware of is on the WAN interface of an IPv6 CPE:

   W-6:  The WAN interface of the CE router SHOULD support a Port
         Control Protocol (PCP) client as specified in [RFC6887] for use
         by applications on the CE router.  The PCP client SHOULD follow
         the procedure specified in Section 8.1 of [RFC6887] to discover
         its PCP server.  This document takes no position on whether
         such functionality is enabled by default or mechanisms by which
         users would configure the functionality.  Handling PCP requests
         from PCP clients in the LAN side of the CE router is out of
         scope.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Michael Richardson
> Envoyé : jeudi 16 novembre 2017 21:49
> À : 6man WG
> Objet : Re: IPv6 only host NAT64 requirements?
> 
> 
> I thought we need PCP in order to enable any kind of incoming connections
> in
> the home.
> 
> The default security of rfc7084 section 4.5, which recommends using
> RFC6092:
> 
>               Recommended Simple Security Capabilities in
>                  Customer Premises Equipment (CPE) for
>               Providing Residential IPv6 Internet Service
> 
> denied incoming TCP SYN packets, although I can't find the exact sentence
> right now.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
> [

v2.23.0 | Report a Bug | By Email