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

[<[e-mail]>]

Hi Richard, 

Thank you for sharing this information. 

As you know, this a problem of UPnP IGD:1 not UPnP IGD:2 and the behavior adopted by applications, e.g., 

* An app calls GetSpecificPortMapping until it finds an external available port, and then calls AddPortMapping(). This one will work just fine.
* An app calls AddPortMapping, after it finds the external port is not available, then it tries the same port 5 more times by calling AddPortMapping, then it returns an error. This behavior increases the chance to get a port. 
* An app calls GetSpecificPortMapping, after finding the external port not available, returns an error without issuing AddPortMapping. This one is broken.
* An appl calls AddPortMapping, after it finds the external port is not available, then it returns an error. This one is borken 
* etc. 

I know some applications are still using IGD:1, but I hope they will move to the IGD:2.

Please note that PCP addresses both the interworking with UPnP (which is one part of the problem), but also mappings that can be instantiated directly by a customer from a GUI exposed by the CPE. People running servers or want to access their CPE when outside are happy with the PCP feature. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[e-mail]] De la part de Richard Patterson
> Envoyé : vendredi 27 avril 2018 13:30
> À : [e-mail] list
> Objet : 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, <[e-mail]> wrote:
> 
> > Hi Ole,
> 
> > Please see inline.
> 
> > Cheers,
> > Med
> 
> > > -----Message d'origine-----
> > > De : Ole Troan [mailto:[e-mail]]
> > > 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:[e-mail]] 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 <[e-mail]> en nombre de Richard Patterson
> > > >> <[e-mail]>
> > > >> Fecha: miércoles, 25 de abril de 2018, 11:16
> > > >> Para: V6 Ops List <[e-mail]>
> > > >> 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 <[e-mail]>
> wrote:
> > > >>>
> > > >>>
> > > >>>> On Apr 24, 2018, at 12:13 PM, STARK, BARBARA H <[e-mail]>
> 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
> > > >>> [e-mail]
> > > >>> https://www.ietf.org/mailman/listinfo/v6ops
> > > >>>
> > > >>
> > > >>    _______________________________________________
> > > >>    v6ops mailing list
> > > >>    [e-mail]
> > > >>    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
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/v6ops
> > > > _______________________________________________
> > > > v6ops mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/v6ops
> 
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops