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

Hi Ole, apologies for the indirect reply, but Gmail appears to have
filtered your email.

>  From my perspective PCP from customers to control CGNs is not going to be
deployed. I'd be happy to hear otherwise.

I'm in two minds about this.  On one hand it may help existing applications
when used alongside the UPnP IWF, but on the other it would be at best,
intermittent.
This intermittent-ness could allow an Xbox to successfully open up port
3074 on Monday during the day, when no other customers sharing the IPv4
address have already taken it, but would fail on Friday night when another
customer turned their Xbox on first and already mapped the port.
Intermittent faults like this could drive more inbound calls to our call
centre, which have a tangible cost impact on the business, not to mention
arguably a worse customer experience.  I'm inclined to prefer reproducible
and predictable failures so the fault can be more reliable identified.

We did trial PCP with the RFC6970 IWF on our CPEs using NAT444, but only as
a staff trial, we never deployed it (NAT444) to production customers.

-Rich

On Fri, 27 Apr 2018 at 08:54, <mohamed.boucadair@orange.com> wrote:

> Hi Ole,

> Please see inline.

> Cheers,
> Med

> > -----Message d'origine-----
> > De : Ole Troan [mailto:otroan@employees.org]
> > Envoyé : vendredi 27 avril 2018 08:34
> > À : V6 Ops List
> > Cc : JORDI PALET MARTINEZ; BOUCADAIR Mohamed IMT/OLN
> > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
> >
> >
> > > 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.
> >
> > I think that requirement needs to be reality checked.
> > Has any of the operators of CGNs deployed PCP?

> [Med] Yes, I confirm. PCP is a deployment reality (DS-Lite context in
particular). Please refer to the file shared by Lee about IPv6 deployments.

>   Would they allow customers to
> > control NAT mappings at all?

> [Med] Yes.

>   Or would that just be a different subscription
> > plan?

> [Med] This is part of the normal service:
> * a GUI is provided on the CPE to allow creating mappings
> * an UPnP IGD/PCP IWF is enabled to allow internal hosts to instantiate
mappings on the CGN.

> > For the other IPv4aaS mechanisms it isn't even an option...
> >
> > From my perspective PCP from customers to control CGNs is not going to
be
> > deployed.

> [Med] You lose! This is already deployed.

>   I'd be happy to hear otherwise.
> [Med] Now you are :)

> >
> > Ole
> >
> > >
> > > 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
> > > _______________________________________________
> > > 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