IETF Logo Mail Archive

Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

<mohamed.boucadair@orange.com> Fri, 27 April 2018 14:01 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97041200E5 for <v6ops@ietfa.amsl.com>; Fri, 27 Apr 2018 07:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 IFuzt7f6q0a7 for <v6ops@ietfa.amsl.com>; Fri, 27 Apr 2018 07:01:26 -0700 (PDT)
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 500B41201F2 for <v6ops@ietf.org>; Fri, 27 Apr 2018 07:01:26 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id C0F96C078F; Fri, 27 Apr 2018 16:01:24 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 8FA93160081; Fri, 27 Apr 2018 16:01:24 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0389.001; Fri, 27 Apr 2018 16:01:24 +0200
From: mohamed.boucadair@orange.com
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops List <v6ops@ietf.org>
Thread-Topic: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
Thread-Index: AQHT3i9JExOGyBXHL0uYI7tEEWYoOqQUoqrQ
Date: Fri, 27 Apr 2018 14:01:23 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DF12BFE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <3A083AA8-41D3-4BF8-BE31-5071975B6F98@gmail.com> <CAHL_VyC1xUDDqZRz1r--u8nyuLaZRnsT0ZR7hzOw4HWUkgwPXg@mail.gmail.com> <52D64464-A1BB-4FFA-AA79-28B8953E3B93@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DD7F981@GAALPA1MSGUSRBF.ITServices.sbc.com> <ECDF4B32-1A4E-49A9-9255-091F2FEA78AF@gmail.com> <CAHL_VyBnRkmpNDcwqTTxu8DnUGFAdKgL+PB1pt9yFLQ==cM0aA@mail.gmail.com> <D8000940-273D-4C25-8B71-F75833B74462@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF126EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <EB620943-8AAC-4736-9BBB-3B0433C54A31@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF12819@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6EFCF64D-3D6E-4A05-BA29-EB18C13FF7B9@consulintel.es> <97D94545-B06B-46D7-8874-C7C2BE141745@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF128D1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <18D5AA86-E01A-4D0B-BDDA-8760454C870C@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF12930@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <EB927C88-58E9-4AE9-9334-DE565101AB57@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF12A08@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3ED28592-574A-4E76-AE01-F9861FE641BB@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF12A5B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <A3E483F2-621F-4ACF-A32D-957A198A2F8C@consulintel.es>
In-Reply-To: <A3E483F2-621F-4ACF-A32D-957A198A2F8C@consulintel.es>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.2]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/nZzEbpMqn6WytZV66oTvHDUA1cs>
Subject: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2018 14:01:30 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET MARTINEZ
> Envoyé : vendredi 27 avril 2018 15:55
> À : V6 Ops List
> Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
> 
> Typically, the NAT64 will be the default GW ... 

[Med] Not sure to understand what you meant. 

FWIW, in the context of current NAT64 deployments (mobile), the NAT64 is located at the Gi interface...that is upstream of the PGW.

but it is true that you may
> have also installed a more specific route for the NAT64 prefix/suffix (in
> addition to the default one).
> 
> Maybe what it makes sense anyway, is to have also a MUST for the RFC7291 y
> PCP is implemented by the CE.
> 

[Med] Agree. 

> Regards,
> Jordi
> 
> 
> -----Mensaje original-----
> De: <mohamed.boucadair@orange.com>
> Fecha: viernes, 27 de abril de 2018, 13:15
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops List
> <v6ops@ietf.org>
> Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
> 
>     Re-,
> 
>     Please see inline.
> 
>     Cheers,
>     Med
> 
>     > -----Message d'origine-----
>     > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET
> MARTINEZ
>     > Envoyé : vendredi 27 avril 2018 13:03
>     > À : V6 Ops List
>     > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
>     >
>     > I mean in the scenario when a CE or host behind a NAT64 want to ask the
> NAT64
>     > for specific IPv4 incoming traffic.
> 
>     [Med] Yes. See for example the experiments we did using an Android Phone:
> https://www.ietf.org/proceedings/85/slides/slides-85-pcp-6.pdf
> 
>      I thought you can do that as well if the
>     > NAT64 supports PCP, and if that's the case, the CE/host will need to
> tell the
>     > PCP server (so again, if no PCP server is configured, the CE could
> assume, by
>     > default, that the NAT64 is the PCP server).
> 
>     [Med] Yeah, but the CE is not aware of the NAT64. This is why it is
> needed to configure explicitly the PCP server on the CE for 464xlat case: RFC
> 7291.
> 
>     >
>     > Regards,
>     > Jordi
>     >
>     >
>     > -----Mensaje original-----
>     > De: <mohamed.boucadair@orange.com>
>     > Fecha: viernes, 27 de abril de 2018, 12:52
>     > Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops List
>     > <v6ops@ietf.org>
>     > Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
>     >
>     >     Re-,
>     >
>     >     It does not make sense to use the same text for the following
> reasons:
>     >
>     >     * NAT64 deployments do not require explicit configuration of the
> NAT64
>     > instance to use at the CPE/host side, while in DS-Lite the
> configuration of
>     > the AFTR is required.
>     >     * Packets from the host embedding the CLAT are native IPv6 packets,
> so
>     > PCP requests will just fly as native IPv6 packets. The situation is
> different
>     > for DS-Lite because IPv4 user traffic is encapsulated over IPv6 to the
> AFTR.
>     >
>     >     Cheers,
>     >     Med
>     >
>     >     > -----Message d'origine-----
>     >     > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI
> PALET
>     > MARTINEZ
>     >     > Envoyé : vendredi 27 avril 2018 12:26
>     >     > À : V6 Ops List
>     >     > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas
> discussion
>     >     >
>     >     > Agree, it makes sense.
>     >     >
>     >     > I don't know if other operators are using also the same approach
> when
>     > using
>     >     > NAT64. May be nobody considered, but I think it will make sense
> to have
>     > the
>     >     > same text as well?
>     >     >
>     >     > Regards,
>     >     > Jordi
>     >     >
>     >     >
>     >     > -----Mensaje original-----
>     >     > De: <mohamed.boucadair@orange.com>
>     >     > Fecha: viernes, 27 de abril de 2018, 11:21
>     >     > Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops
> List
>     >     > <v6ops@ietf.org>
>     >     > Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas
> discussion
>     >     >
>     >     >     Re-,
>     >     >
>     >     >     Thank you.
>     >     >
>     >     >     For DS-Lite, you may mention the following :
>     >     >     - when no PCP server is configured, the CPE assumes by
> default that
>     > the
>     >     > AFTR is the PCP server.
>     >     >     - a plain IPv6 mode is used to send PCP requests to the
> server.
>     >     >
>     >     >     This is how PCP is deployed today for DS-lite. It is worth to
> have
>     > it
>     >     > documented.
>     >     >
>     >     >     Cheers,
>     >     >     Med
>     >     >
>     >     >     > -----Message d'origine-----
>     >     >     > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de
> JORDI
>     > PALET
>     >     > MARTINEZ
>     >     >     > Envoyé : vendredi 27 avril 2018 11:04
>     >     >     > À : V6 Ops List
>     >     >     > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas
>     > discussion
>     >     >     >
>     >     >     > Done, thanks!
>     >     >     >
>     >     >     > So, I removed the SHOULD for PCP, as it is already in
> RFC7084,
>     > but
>     >     > added (DS-
>     >     >     > LITE and 464XLAT):
>     >     >     >
>     >     >     > 	The CE Router SHOULD support IGD-PCP IWF [RFC6970] (UPnP
>     >     >     >                Internet Gateway Device - Port Control
> Protocol
>     >     >     >                Interworking Function).
>     >     >     >
>     >     >     > Regards,
>     >     >     > Jordi
>     >     >     >
>     >     >     >
>     >     >     > -----Mensaje original-----
>     >     >     > De: <mohamed.boucadair@orange.com>
>     >     >     > Fecha: viernes, 27 de abril de 2018, 10:37
>     >     >     > Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6
> Ops
>     > List
>     >     >     > <v6ops@ietf.org>
>     >     >     > Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas
>     > discussion
>     >     >     >
>     >     >     >     Jordi,
>     >     >     >
>     >     >     >     That is what I was suggesting.
>     >     >     >
>     >     >     >     Cheers,
>     >     >     >     Med
>     >     >     >
>     >     >     >     > -----Message d'origine-----
>     >     >     >     > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part
> de
>     > JORDI
>     >     > PALET
>     >     >     > MARTINEZ
>     >     >     >     > Envoyé : vendredi 27 avril 2018 10:32
>     >     >     >     > À : V6 Ops List
>     >     >     >     > Objet : Re: [v6ops] draft-palet-v6ops-transition-
> ipv4aas
>     >     > discussion
>     >     >     >     >
>     >     >     >     > Responding to myself ... The alternative maybe to not
> say
>     >     > anything
>     >     >     > about
>     >     >     >     > RFC6887, so the SHOULD in RFC7084 is in effect and
> add a
>     > SHOULD
>     >     > for
>     >     >     > RFC6970.
>     >     >     >     >
>     >     >     >     > Regards,
>     >     >     >     > Jordi
>     >     >     >     >
>     >     >     >     >
>     >     >     >     > -----Mensaje original-----
>     >     >     >     > De: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
>     >     >     >     > Fecha: viernes, 27 de abril de 2018, 10:27
>     >     >     >     > Para: V6 Ops List <v6ops@ietf.org>
>     >     >     >     > Asunto: Re: [v6ops] draft-palet-v6ops-transition-
> ipv4aas
>     >     > discussion
>     >     >     >     >
>     >     >     >     >     The difference is in RFC7084 is a SHOULD for
> RFC6887,
>     > while
>     >     > here
>     >     >     > I'm
>     >     >     >     > suggesting a MUST when DS-LITE or 464XLAT are
> implemented.
>     >     >     >     >
>     >     >     >     >     Asking a MUST for RFC6970, and not having a MUST
> in
>     > RFC6887
>     >     > seems
>     >     >     > weird
>     >     >     >     > ...
>     >     >     >     >
>     >     >     >     >     Regards,
>     >     >     >     >     Jordi
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >     -----Mensaje original-----
>     >     >     >     >     De: <mohamed.boucadair@orange.com>
>     >     >     >     >     Fecha: viernes, 27 de abril de 2018, 9:45
>     >     >     >     >     Para: JORDI PALET MARTINEZ
>     > <jordi.palet@consulintel.es>, V6
>     >     > Ops
>     >     >     > List
>     >     >     >     > <v6ops@ietf.org>
>     >     >     >     >     Asunto: RE: [v6ops] draft-palet-v6ops-transition-
>     > ipv4aas
>     >     > discussion
>     >     >     >     >
>     >     >     >     >         Re-,
>     >     >     >     >
>     >     >     >     >         Please see inline.
>     >     >     >     >
>     >     >     >     >         Cheers,
>     >     >     >     >         Med
>     >     >     >     >
>     >     >     >     >         > -----Message d'origine-----
>     >     >     >     >         > De : v6ops [mailto:v6ops-bounces@ietf.org]
> De la
>     > part
>     >     > de
>     >     >     > JORDI
>     >     >     >     > PALET MARTINEZ
>     >     >     >     >         > Envoyé : vendredi 27 avril 2018 08:27
>     >     >     >     >         > À : V6 Ops List
>     >     >     >     >         > Objet : Re: [v6ops] draft-palet-v6ops-
> transition-
>     >     > ipv4aas
>     >     >     > discussion
>     >     >     >     >         >
>     >     >     >     >         > Hi Med,
>     >     >     >     >         >
>     >     >     >     >         > In the document I'm editing right now, I've
> it
>     > already
>     >     >     > support for
>     >     >     >     > RFC6887
>     >     >     >     >         > (464XLAT-2):
>     >     >     >     >
>     >     >     >     >         [Med] You don't need to add an item for 6887
> since
>     > this
>     >     > is
>     >     >     > already
>     >     >     >     > covered in 7084:
>     >     >     >     >
>     >     >     >     >            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.
>     >     >     >     >
>     >     >     >     >         My comment is about the IWF which is needed
> to
>     > allow an
>     >     > UPnP
>     >     >     > Control
>     >     >     >     > Point to interact with a PCP server.
>     >     >     >     >
>     >     >     >     >         >
>     >     >     >     >         >    464XLAT requirements:
>     >     >     >     >         >
>     >     >     >     >         >    464XLAT-1:  The CE Router MUST perform
> IPv4
>     > Network
>     >     >     > Address
>     >     >     >     >         >                Translation (NAT) on IPv4
> traffic
>     >     > translated
>     >     >     > using
>     >     >     >     > the
>     >     >     >     >         >                CLAT, unless a dedicated /64
>     > prefix has
>     >     > been
>     >     >     >     > acquired
>     >     >     >     >         >                using DHCPv6-PD [RFC3633]
> (IPv6
>     > Prefix
>     >     > Options
>     >     >     > for
>     >     >     >     >         >                DHCPv6).
>     >     >     >     >         >
>     >     >     >     >         >    464XLAT-2:  The CE Router MUST support
> PCP
>     > [RFC6887]
>     >     > (Port
>     >     >     >     > Control
>     >     >     >     >         >                Protocol), for explicit
> control
>     > over
>     >     > NAT64
>     >     >     > mappings.
>     >     >     >     >
>     >     >     >     >         [Med] This one should be removed since it
> overlaps
>     > with
>     >     > W-6 in
>     >     >     > 7084.
>     >     >     >     >
>     >     >     >     >         >
>     >     >     >     >         >    464XLAT-3:  The CE Router MUST implement
>     > [RFC7050]
>     >     >     > (Discovery of
>     >     >     >     > the
>     >     >     >     >         >                IPv6 Prefix Used for IPv6
> Address
>     >     > Synthesis)
>     >     >     > in
>     >     >     >     > order to
>     >     >     >     >         >                discover the PLAT-side
> translation
>     > IPv4
>     >     > and
>     >     >     > IPv6
>     >     >     >     >         >                prefix(es)/suffix(es).  The
> CE
>     > Router
>     >     > MUST
>     >     >     > follow
>     >     >     >     >         >                [RFC7225] (Discovering NAT64
> IPv6
>     >     > Prefixes
>     >     >     > Using the
>     >     >     >     >         >                PCP), in order to learn the
> PLAT-
>     > side
>     >     >     > translation
>     >     >     >     > IPv4
>     >     >     >     >         >                and IPv6
> prefix(es)/suffix(es)
>     > used by
>     >     > an
>     >     >     > upstream
>     >     >     >     > PCP-
>     >     >     >     >         >                controlled NAT64 device.
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         > But I now realice that it should be added
> as well
>     > to
>     >     > the DS-
>     >     >     > Lite
>     >     >     >     > section, as
>     >     >     >     >         > it was not present in RFC7084. This is what
> I've
>     > right
>     >     > now:
>     >     >     >     >         >
>     >     >     >     >         >   DS-Lite requirements:
>     >     >     >     >         >
>     >     >     >     >         >    DSLITE-1:  The IPv6 CE router MUST
> support
>     >     > configuration
>     >     >     > of DS-
>     >     >     >     > Lite
>     >     >     >     >         >               via the DS-Lite DHCPv6 option
>     > [RFC6334]
>     >     > (DHCPv6
>     >     >     >     > Option for
>     >     >     >     >         >               Dual-Stack Lite).  The IPv6
> CE
>     > router MAY
>     >     > use
>     >     >     > other
>     >     >     >     >         >               mechanisms to configure DS-
> Lite
>     >     > parameters.
>     >     >     > Such
>     >     >     >     >         >               mechanisms are outside the
> scope of
>     > this
>     >     >     > document.
>     >     >     >     >         >
>     >     >     >     >         >    DSLITE-2:  The IPv6 CE router MUST NOT
> perform
>     > IPv4
>     >     >     > Network
>     >     >     >     > Address
>     >     >     >     >         >               Translation (NAT) on IPv4
> traffic
>     >     > encapsulated
>     >     >     > using
>     >     >     >     > DS-
>     >     >     >     >         >               Lite.
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         > So just to make sure, you mean to add also
> to
>     > both,
>     >     > 464LAT
>     >     >     > and DS-
>     >     >     >     > LITE also a
>     >     >     >     >         > MUST for RFC6970 ?
>     >     >     >     >
>     >     >     >     >         [Med] Yes, I'd like to add an item for the
> IWF, not
>     > the
>     >     > PCP
>     >     >     > Client
>     >     >     >     > functionality.
>     >     >     >     >
>     >     >     >     >         >
>     >     >     >     >         > We have a new section with this text
> suggested by
>     >     > Richard:
>     >     >     >     >         >
>     >     >     >     >         > 5.  UPnP IGD-PCP IWF Support
>     >     >     >     >         >
>     >     >     >     >         >    UPnP MAY be enabled on the CE Router for
>     > stateless
>     >     >     > mechanisms
>     >     >     >     > that
>     >     >     >     >         >    forward unsolicited inbound packets
> through to
>     > the
>     >     > CE.  If
>     >     >     > UPnP
>     >     >     >     > is
>     >     >     >     >         >    enabled, the agent MUST reject any port
>     > mapping
>     >     > requests
>     >     >     > for
>     >     >     >     > ports
>     >     >     >     >         >    outside of the range(s) allocated to the
> CE
>     > Router.
>     >     >     >     >         >
>     >     >     >     >         >    UPnP SHOULD be disabled for stateful
>     > mechanisms that
>     >     > do
>     >     >     > not
>     >     >     >     > forward
>     >     >     >     >         >    unsolicited inbound packets to the CE
> Router,
>     > unless
>     >     >     > implemented
>     >     >     >     > in
>     >     >     >     >         >    conjunction with a method to control the
>     > external
>     >     > port
>     >     >     > mapping,
>     >     >     >     > such
>     >     >     >     >         >    as IGD-PCP IWF [RFC6970] (UPnP Internet
>     > Gateway
>     >     > Device -
>     >     >     > Port
>     >     >     >     > Control
>     >     >     >     >         >    Protocol Interworking Function).
>     >     >     >     >         >
>     >     >     >     >
>     >     >     >     >         [Med] this text does not recommend
> implementing the
>     > IWF.
>     >     >     >     >
>     >     >     >     >         >
>     >     >     >     >         > Regards,
>     >     >     >     >         > Jordi
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         > -----Mensaje original-----
>     >     >     >     >         > De: <mohamed.boucadair@orange.com>
>     >     >     >     >         > Fecha: viernes, 27 de abril de 2018, 7:26
>     >     >     >     >         > Para: JORDI PALET MARTINEZ
>     >     > <jordi.palet@consulintel.es>, V6
>     >     >     > Ops
>     >     >     >     > List
>     >     >     >     >         > <v6ops@ietf.org>
>     >     >     >     >         > Asunto: RE: [v6ops] draft-palet-v6ops-
> transition-
>     >     > ipv4aas
>     >     >     > discussion
>     >     >     >     >         >
>     >     >     >     >         >     Hi Jordi,
>     >     >     >     >         >
>     >     >     >     >         >     As you are on it, and given the IETF
>     > recommendation
>     >     > in
>     >     >     > RFC6888:
>     >     >     >     >         >
>     >     >     >     >         >        REQ-9:  A CGN MUST implement a
> protocol
>     > giving
>     >     >     > subscribers
>     >     >     >     > explicit
>     >     >     >     >         >           control over NAT mappings.  That
>     > protocol
>     >     > SHOULD be
>     >     >     > the
>     >     >     >     > Port
>     >     >     >     >         >           Control Protocol [RFC6887].
>     >     >     >     >         >
>     >     >     >     >         >     which would apply also to the PLAT, I
> suggest
>     > you
>     >     > add an
>     >     >     > item
>     >     >     >     > in the
>     >     >     >     >         > 464lat section to support RFC6970.
>     >     >     >     >         >
>     >     >     >     >         >     Cheers,
>     >     >     >     >         >     Med
>     >     >     >     >         >
>     >     >     >     >         >     > -----Message d'origine-----
>     >     >     >     >         >     > De : v6ops [mailto:v6ops-
> bounces@ietf.org]
>     > De la
>     >     > part
>     >     >     > de
>     >     >     >     > JORDI PALET
>     >     >     >     >         > MARTINEZ
>     >     >     >     >         >     > Envoyé : jeudi 26 avril 2018 21:41
>     >     >     >     >         >     > À : V6 Ops List
>     >     >     >     >         >     > Objet : Re: [v6ops] draft-palet-
> v6ops-
>     > transition-
>     >     >     > ipv4aas
>     >     >     >     > discussion
>     >     >     >     >         >     >
>     >     >     >     >         >     > Hi Richard,
>     >     >     >     >         >     >
>     >     >     >     >         >     > As I've moved sections 3 & 4 to the
> end of
>     > the
>     >     > document
>     >     >     > as
>     >     >     >     > annexes,
>     >     >     >     >         > I've
>     >     >     >     >         >     > added a new small section for UPnP
> with
>     > your
>     >     > text. I
>     >     >     > think
>     >     >     >     > this also
>     >     >     >     >         > helps to
>     >     >     >     >         >     > clarify one of the issues raised by
> Lee.
>     >     >     >     >         >     >
>     >     >     >     >         >     > I'm working on all this changes with
> my co-
>     >     > authors, and
>     >     >     > if we
>     >     >     >     > are good
>     >     >     >     >         > with
>     >     >     >     >         >     > them, we probably will submit the new
>     > version in
>     >     > a
>     >     >     > couple of
>     >     >     >     > days or
>     >     >     >     >         > so.
>     >     >     >     >         >     >
>     >     >     >     >         >     > Thanks!
>     >     >     >     >         >     >
>     >     >     >     >         >     > Regards,
>     >     >     >     >         >     > Jordi
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     >     >     >     >         >     > -----Mensaje original-----
>     >     >     >     >         >     > De: v6ops <v6ops-bounces@ietf.org> en
>     > nombre de
>     >     > Richard
>     >     >     >     > Patterson
>     >     >     >     >         >     > <richard@helix.net.nz>
>     >     >     >     >         >     > Fecha: miércoles, 25 de abril de
> 2018,
>     > 11:16
>     >     >     >     >         >     > Para: V6 Ops List <v6ops@ietf.org>
>     >     >     >     >         >     > Asunto: Re: [v6ops] draft-palet-
> v6ops-
>     > transition-
>     >     >     > ipv4aas
>     >     >     >     > discussion
>     >     >     >     >         >     >
>     >     >     >     >         >     >     Section 4 only briefly touches on
> UPnP,
>     > I'd
>     >     > like to
>     >     >     >     > propose that we
>     >     >     >     >         >     >     make a recommendation around its
>     > behaviour if
>     >     > it is
>     >     >     >     > enabled.
>     >     >     >     >         >     >
>     >     >     >     >         >     >     UPnP MAY be enabled on the IPv6
>     > transition
>     >     > CE, for
>     >     >     >     > stateless
>     >     >     >     >         >     >     mechanisms that forward
> unsolicited
>     > inbound
>     >     > packets
>     >     >     >     > through to the
>     >     >     >     >         > CE.
>     >     >     >     >         >     >     If UPnP is enabled, the agent
> MUST
>     > reject any
>     >     > port
>     >     >     >     > mapping requests
>     >     >     >     >         >     >     for ports outside of the range(s)
>     > allocated
>     >     > to the
>     >     >     > IPv6
>     >     >     >     > transition
>     >     >     >     >         > CE.
>     >     >     >     >         >     >
>     >     >     >     >         >     >     UPnP SHOULD be disabled for
> stateful
>     >     > mechanisms
>     >     >     > that do
>     >     >     >     > not forward
>     >     >     >     >         >     >     unsolicited inbound packets to
> the CE,
>     > unless
>     >     >     > implemented
>     >     >     >     > in
>     >     >     >     >         >     >     conjunction with a method to
> control
>     > the
>     >     > external
>     >     >     > port
>     >     >     >     > mapping,
>     >     >     >     >         > such
>     >     >     >     >         >     >     as IGD-PCP IWF [RFC6970].
>     >     >     >     >         >     >
>     >     >     >     >         >     >     -Richard
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     >     >     >     >         >     >     On 25 April 2018 at 01:38, Fred
> Baker
>     >     >     >     > <fredbaker.ietf@gmail.com>
>     >     >     >     >         > wrote:
>     >     >     >     >         >     >     >
>     >     >     >     >         >     >     >
>     >     >     >     >         >     >     >> On Apr 24, 2018, at 12:13 PM,
> STARK,
>     >     > BARBARA H
>     >     >     >     > <bs7652@att.com>
>     >     >     >     >         > wrote:
>     >     >     >     >         >     >     >>
>     >     >     >     >         >     >     >> But that doesn't mean I
> believe the
>     > draft
>     >     > has
>     >     >     > exactly
>     >     >     >     > the right
>     >     >     >     >         > set of
>     >     >     >     >         >     > features included. My understanding
> of
>     > "adoption"
>     >     > is
>     >     >     > that it
>     >     >     >     > is still
>     >     >     >     >         >     > possible post-adoption to discuss
> whether
>     >     > specific
>     >     >     > features /
>     >     >     >     >         > requirements do
>     >     >     >     >         >     > or don't belong. If the precise set
> of
>     > features
>     >     > and
>     >     >     >     > requirements must
>     >     >     >     >         > be
>     >     >     >     >         >     > agreed upon prior to adoption, then I
> would
>     > not
>     >     > be in
>     >     >     > support
>     >     >     >     > of
>     >     >     >     >         > adoption.
>     >     >     >     >         >     > Hopefully we aren't setting the bar
> that
>     > high?
>     >     >     >     >         >     >     >
>     >     >     >     >         >     >     > I understand "adoption as a
> working
>     > group
>     >     > draft"
>     >     >     > to
>     >     >     >     > mean that the
>     >     >     >     >         >     > working group has agreed to work on
> the
>     > draft.
>     >     > There
>     >     >     > are some
>     >     >     >     > working
>     >     >     >     >         > groups
>     >     >     >     >         >     > that seem to confuse "adoption as a
> work
>     > group
>     >     > draft"
>     >     >     > with
>     >     >     >     > "agreement
>     >     >     >     >         > to send
>     >     >     >     >         >     > it to the IESG"; I don't, but expect
>     > conversation
>     >     > in
>     >     >     > between
>     >     >     >     > those two
>     >     >     >     >         >     > events.
>     >     >     >     >         >     >     >
>     >     >     >     >         >     >     > That said, I'd like to believe
> that
>     > the
>     >     > draft is
>     >     >     > pretty
>     >     >     >     > close,
>     >     >     >     >         > and that
>     >     >     >     >         >     > changes that need to be made to it
> will
>     > have text
>     >     >     > offered by
>     >     >     >     > the people
>     >     >     >     >         > that
>     >     >     >     >         >     > want them. So - keep your cards and
> letters
>     >     > coming...
>     >     >     >     >         >     >     >
>     >     >     >     >         >     >     >
>     >     > _______________________________________________
>     >     >     >     >         >     >     > v6ops mailing list
>     >     >     >     >         >     >     > v6ops@ietf.org
>     >     >     >     >         >     >     >
>     > https://www.ietf.org/mailman/listinfo/v6ops
>     >     >     >     >         >     >     >
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     >     > _______________________________________________
>     >     >     >     >         >     >     v6ops mailing list
>     >     >     >     >         >     >     v6ops@ietf.org
>     >     >     >     >         >     >
>     > https://www.ietf.org/mailman/listinfo/v6ops
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     > **********************************************
>     >     >     >     >         >     > IPv4 is over
>     >     >     >     >         >     > Are you ready for the new Internet ?
>     >     >     >     >         >     > http://www.consulintel.es
>     >     >     >     >         >     > The IPv6 Company
>     >     >     >     >         >     >
>     >     >     >     >         >     > This electronic message contains
>     > information
>     >     > which may
>     >     >     > be
>     >     >     >     > privileged or
>     >     >     >     >         >     > confidential. The information is
> intended
>     > to be
>     >     > for the
>     >     >     >     > exclusive use
>     >     >     >     >         > of the
>     >     >     >     >         >     > individual(s) named above and further
> non-
>     >     > explicilty
>     >     >     >     > authorized
>     >     >     >     >         > disclosure,
>     >     >     >     >         >     > copying, distribution or use of the
>     > contents of
>     >     > this
>     >     >     >     > information, even
>     >     >     >     >         > if
>     >     >     >     >         >     > partially, including attached files,
> is
>     > strictly
>     >     >     > prohibited
>     >     >     >     > and will be
>     >     >     >     >         >     > considered a criminal offense. If you
> are
>     > not the
>     >     >     > intended
>     >     >     >     > recipient be
>     >     >     >     >         > aware
>     >     >     >     >         >     > that any disclosure, copying,
> distribution
>     > or use
>     >     > of
>     >     >     > the
>     >     >     >     > contents of
>     >     >     >     >         > this
>     >     >     >     >         >     > information, even if partially,
> including
>     >     > attached
>     >     >     > files, is
>     >     >     >     > strictly
>     >     >     >     >         >     > prohibited, will be considered a
> criminal
>     >     > offense, so
>     >     >     > you
>     >     >     >     > must reply to
>     >     >     >     >         > the
>     >     >     >     >         >     > original sender to inform about this
>     >     > communication and
>     >     >     > delete
>     >     >     >     > it.
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     >     >     >     >         >     >
>     > _______________________________________________
>     >     >     >     >         >     > v6ops mailing list
>     >     >     >     >         >     > v6ops@ietf.org
>     >     >     >     >         >     >
> https://www.ietf.org/mailman/listinfo/v6ops
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         >
> **********************************************
>     >     >     >     >         > IPv4 is over
>     >     >     >     >         > Are you ready for the new Internet ?
>     >     >     >     >         > http://www.consulintel.es
>     >     >     >     >         > The IPv6 Company
>     >     >     >     >         >
>     >     >     >     >         > This electronic message contains
> information
>     > which may
>     >     > be
>     >     >     >     > privileged or
>     >     >     >     >         > confidential. The information is intended
> to be
>     > for the
>     >     >     > exclusive
>     >     >     >     > use of the
>     >     >     >     >         > individual(s) named above and further non-
>     > explicilty
>     >     >     > authorized
>     >     >     >     > disclosure,
>     >     >     >     >         > copying, distribution or use of the
> contents of
>     > this
>     >     >     > information,
>     >     >     >     > even if
>     >     >     >     >         > partially, including attached files, is
> strictly
>     >     > prohibited
>     >     >     > and
>     >     >     >     > will be
>     >     >     >     >         > considered a criminal offense. If you are
> not the
>     >     > intended
>     >     >     >     > recipient be aware
>     >     >     >     >         > that any disclosure, copying, distribution
> or use
>     > of
>     >     > the
>     >     >     > contents
>     >     >     >     > of this
>     >     >     >     >         > information, even if partially, including
>     > attached
>     >     > files, is
>     >     >     >     > strictly
>     >     >     >     >         > prohibited, will be considered a criminal
>     > offense, so
>     >     > you
>     >     >     > must
>     >     >     >     > reply to the
>     >     >     >     >         > original sender to inform about this
>     > communication and
>     >     > delete
>     >     >     > it.
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         >
> _______________________________________________
>     >     >     >     >         > v6ops mailing list
>     >     >     >     >         > v6ops@ietf.org
>     >     >     >     >         > https://www.ietf.org/mailman/listinfo/v6ops
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >
>     >     >     >     > **********************************************
>     >     >     >     > IPv4 is over
>     >     >     >     > Are you ready for the new Internet ?
>     >     >     >     > http://www.consulintel.es
>     >     >     >     > The IPv6 Company
>     >     >     >     >
>     >     >     >     > This electronic message contains information which
> may be
>     >     > privileged or
>     >     >     >     > confidential. The information is intended to be for
> the
>     > exclusive
>     >     > use
>     >     >     > of the
>     >     >     >     > individual(s) named above and further non-explicilty
>     > authorized
>     >     >     > disclosure,
>     >     >     >     > copying, distribution or use of the contents of this
>     > information,
>     >     > even
>     >     >     > if
>     >     >     >     > partially, including attached files, is strictly
> prohibited
>     > and
>     >     > will be
>     >     >     >     > considered a criminal offense. If you are not the
> intended
>     >     > recipient be
>     >     >     > aware
>     >     >     >     > that any disclosure, copying, distribution or use of
> the
>     > contents
>     >     > of
>     >     >     > this
>     >     >     >     > information, even if partially, including attached
> files,
>     > is
>     >     > strictly
>     >     >     >     > prohibited, will be considered a criminal offense, so
> you
>     > must
>     >     > reply to
>     >     >     > the
>     >     >     >     > original sender to inform about this communication
> and
>     > delete it.
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >
>     >     >     >     > _______________________________________________
>     >     >     >     > v6ops mailing list
>     >     >     >     > v6ops@ietf.org
>     >     >     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     > **********************************************
>     >     >     > IPv4 is over
>     >     >     > Are you ready for the new Internet ?
>     >     >     > http://www.consulintel.es
>     >     >     > The IPv6 Company
>     >     >     >
>     >     >     > This electronic message contains information which may be
>     > privileged or
>     >     >     > confidential. The information is intended to be for the
> exclusive
>     > use
>     >     > of the
>     >     >     > individual(s) named above and further non-explicilty
> authorized
>     >     > disclosure,
>     >     >     > copying, distribution or use of the contents of this
> information,
>     > even
>     >     > if
>     >     >     > partially, including attached files, is strictly prohibited
> and
>     > will be
>     >     >     > considered a criminal offense. If you are not the intended
>     > recipient be
>     >     > aware
>     >     >     > that any disclosure, copying, distribution or use of the
> contents
>     > of
>     >     > this
>     >     >     > information, even if partially, including attached files,
> is
>     > strictly
>     >     >     > prohibited, will be considered a criminal offense, so you
> must
>     > reply to
>     >     > the
>     >     >     > original sender to inform about this communication and
> delete it.
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >     > _______________________________________________
>     >     >     > v6ops mailing list
>     >     >     > v6ops@ietf.org
>     >     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > **********************************************
>     >     > IPv4 is over
>     >     > Are you ready for the new Internet ?
>     >     > http://www.consulintel.es
>     >     > The IPv6 Company
>     >     >
>     >     > This electronic message contains information which may be
> privileged or
>     >     > confidential. The information is intended to be for the exclusive
> use
>     > of the
>     >     > individual(s) named above and further non-explicilty authorized
>     > disclosure,
>     >     > copying, distribution or use of the contents of this information,
> even
>     > if
>     >     > partially, including attached files, is strictly prohibited and
> will be
>     >     > considered a criminal offense. If you are not the intended
> recipient be
>     > aware
>     >     > that any disclosure, copying, distribution or use of the contents
> of
>     > this
>     >     > information, even if partially, including attached files, is
> strictly
>     >     > prohibited, will be considered a criminal offense, so you must
> reply to
>     > the
>     >     > original sender to inform about this communication and delete it.
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > v6ops mailing list
>     >     > v6ops@ietf.org
>     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >
>     >
>     >
>     >
>     > **********************************************
>     > IPv4 is over
>     > Are you ready for the new Internet ?
>     > http://www.consulintel.es
>     > The IPv6 Company
>     >
>     > This electronic message contains information which may be privileged or
>     > confidential. The information is intended to be for the exclusive use
> of the
>     > individual(s) named above and further non-explicilty authorized
> disclosure,
>     > copying, distribution or use of the contents of this information, even
> if
>     > partially, including attached files, is strictly prohibited and will be
>     > considered a criminal offense. If you are not the intended recipient be
> aware
>     > that any disclosure, copying, distribution or use of the contents of
> this
>     > information, even if partially, including attached files, is strictly
>     > prohibited, will be considered a criminal offense, so you must reply to
> the
>     > original sender to inform about this communication and delete it.
>     >
>     >
>     >
>     > _______________________________________________
>     > v6ops mailing list
>     > v6ops@ietf.org
>     > https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of the
> individual(s) named above and further non-explicilty authorized disclosure,
> copying, distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited and will be
> considered a criminal offense. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited, will be considered a criminal offense, so you must reply to the
> original sender to inform about this communication and delete it.
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email