[v6ops] Re: Traffic control protocols (PCP and UPnP IGD)

[Daryll Swer <[e-mail]>]

Mohamed

I confirm for 5G. PCP was even designed to avoid draining batteries and
> avoid frequent keepalive.

Good to know. PCP makes 100% sense for LTE/5G for *IPv4* (over 464xlat).
Thanks for confirming.

However, I do not see a reason for LTE/5G PCP on IPv6, unless we are
referring to greedy Telcos that breaks IPv6 P2P intentionally with a
stateful firewall under the guise of “Public IPv6 on your iPhone drains
battery”, in order to justify selling more expensive “business plans” with
“unfiltered IPv6”.

Reliance Jio was the first large-scale carrier to roll out native IPv6 on
mobility from day one, in 2016, they have around 472 million subs in 2024
<https://en.wikipedia.org/wiki/List_of_mobile_network_operators#Terrestrial>.
>From 2016 to 2024, Reliance Jio has always provided *native*,
*unfiltered* IPv6,
with native P2P working just fine (because no firewall and no NAT66), I
find it hard to believe that from 2016 to 2024 against 472 million subs,
this “battery drain” claim wouldn't have been caught already by Indian
users if it was true. I doubt any European or American Telco has 472
million subs as a sampling size, data source, to back up this “battery
drain” claim for native IPv6 on mobile handsets.

To illustrate, I just opened up port 8000 on my iPhone, behind Reliance Jio
LTE/5G SIM Card, as we can see no filtering of end-to-end reachability and
definitely no “battery drain” on native IPv6 since 2016:
[image: image.png]

Native stateless (no stateful firewall) IPv6 for mobility, shouldn't have
keep-alive traffic at all and therefore no need for PCP on mobility for v6.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/31932ac12039bf6bac70687654218bad0a75c700?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=841becceff49e838>


On Fri, 26 Jul 2024 at 19:44, <[e-mail]> wrote:

> Hi Daryll,
>
>
>
> I confirm for 5G. PCP was even designed to avoid draining batteries and
> avoid frequent keepalive.
>
>
>
> RFC6887 has that
>
>
>
>    Many NAT-friendly applications send frequent application-level
>
>    messages to ensure that their session will not be timed out by a NAT.
>
>    These are commonly called "NAT keepalive" messages, even though they
>
>    are not sent to the NAT itself (rather, they are sent 'through' the
>
>    NAT).  These applications can reduce the frequency of such NAT
>
>    keepalive messages by using PCP to learn (and influence) the NAT
>
>    mapping lifetime.  This helps reduce bandwidth on the subscriber's
>
>    access network, traffic to the server, and battery consumption on
>
>                                               **********************
>
>    mobile devices.
>
>    *************
>
>
>
> Or
>
>
>
>    However, the FILTER option is a
>
>    particularly useful performance optimization for battery powered
>
>    wireless devices, because it can enable them to conserve battery
>
>    power by not having to wake up just to reject unwanted traffic.
>
>
>
> You can also refer for example to rfc7849, which included the following:
>
>
>
> ==
>
>    A_REC#2:  The cellular host should support PCP [RFC6887].
>
>
>
>                 The support of PCP is seen as a driver to save battery
>
>                 consumption exacerbated by keep-alive messages.  PCP
>
>                 also gives the possibility of enabling incoming
>
>                 connections to the cellular device.  Indeed, because
>
>                 several stateful devices may be deployed in wireless
>
>                 networks (e.g., NAT64 and/or IPv6 Firewalls), PCP can be
>
>                 used by the cellular host to control network-based NAT64
>
>                 and IPv6 Firewall functions that will reduce per-
>
>                 application signaling and save battery consumption.
>
>
>
>                 ..
>
> ==
>
>
>
> On the VoIP question, you can refer to
> https://datatracker.ietf.org/doc/html/rfc7225#autoid-14 for detailed flow
> examples how this works without requiring ALGs in the network, hosted nat
> traversal techniques, TURN, etc.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Daryll Swer <contact=[e-mail]>
> *Envoyé :* vendredi 26 juillet 2024 15:51
> *À :* Ted Lemon <[e-mail]>
> *Cc :* [e-mail]
> *Objet :* [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
>
>
>
> > Anything that uses the APIs on macOS/iOS will work with both upnp and
> pcp.
>
>
>
> Good to know. So it's just a matter of the application software making use
> of already existing APIs on Apple OSes.
>
>
>
> Ted, does PCP work with LTE/5G? I am not an expert in mobility, but I am
> curious. If the LTE/5G access network is 464xlat (or maybe MAP-T in the
> future?), can an application software request the upstream carrier via PCP
> to open up a port for IPv4, dynamically for temporary IPv4 P2P session to
> go through? Say VoIP calls without TURN?
>
>
>
> > Regarding security holes, the question would be, what holes does it
> create t that aren’t already there with a firewall that allows outbound
> connections?  I suppose it makes being a DoS attack server slightly easier?
>
>
>
> Many ISPs have DDoS detection/mitigation/re-routing in place anyway, so if
> some gets DDoSed (or DoSed), their /32 will be temporarily blackholed or
> re-routed over a scrubbing infrastructure.
>
>
>
> I see no issues here, if you want a port open, it'll be open.
>
>
> *--*
>
> Best Regards
>
> Daryll Swer
>
> Website: daryllswer.com
> <https://mailtrack.io/l/d9660c15f7ba73f852ecacc9dd726a97f16ecaba?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=fcf70f25da532337>
>
>
>
>
> On Fri, 26 Jul 2024 at 19:13, Ted Lemon <[e-mail]> wrote:
>
> Anything that uses the APIs on macOS/iOS will work with both upnp and pcp.
>
>
>
> Regarding security holes, the question would be, what holes does it create
> t that aren’t already there with a firewall that allows outbound
> connections?  I suppose it makes being a DoS attack server slightly easier?
>
>
>
> Op vr 26 jul 2024 om 06:08 schreef Daryll Swer <contact=
> [e-mail]>
>
> Are there actually any common/popular application software used by people,
> that supports PCP? I've always only found UPnP and the obsolete NAT-PMP.
>
>
> *--*
>
> Best Regards
>
> Daryll Swer
>
> Website: daryllswer.com
> <https://mailtrack.io/l/bd01f399b82a8baf04f66715cc1a7f080a88af17?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=82a4bd12b2a97f5a>
>
>
>
>
> On Fri, 26 Jul 2024 at 16:06, Ole Troan <otroan=
> [e-mail]> wrote:
>
> If there is a desire that the IPv6 CE router acts as a firewall, just
> requiring PCP RFC6887 may not be enough.
> At least RFC6887 opens up quite a few security trust issues. At least if
> we have to deal with the threat that an inside client is not under the
> control of the party interested in security.
> Then something like RFC7652 would be required.
> (Which leads one to wonder if it isn’t simpler to configure this through a
> UI on the IPv6 CE router instead of a through a protocol…)
>
> Ole
>
> > On 26 Jul 2024, at 03:34, Kawashima Masanobu(川島 正伸) <kawashimam=
> [e-mail]> wrote:
> >
> >  It’s clear now. Thank you.  Regards, Masanobu   From: Ted Lemon <
> [e-mail]>
> > Sent: Friday, July 26, 2024 10:12 AM
> > To: Kawashima Masanobu(川島 正伸) <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
> >  I think it should be fine to do that, yes.
> >  Op do 25 jul 2024 om 17:15 schreef Kawashima Masanobu(川島 正伸) <
> [e-mail]>
> >
> > Ted,
> >
> > Thank you for your reply.  It’s almost clear now. :-)
> >
> > How about RFC 6970((UPnP IGD-PCP IWF)?
> > It is ‘Standard Track’. Should we mention something? Regards, Masanobu
> ========================  NEC Platforms, Ltd.                   KAWASHIMA
> Masanobu               [e-mail]
> https://www.necplatforms.co.jp/en/    ========================
> >    From: Ted Lemon <[e-mail]>
> > Sent: Friday, July 26, 2024 8:59 AM
> > To: Kawashima Masanobu(川島 正伸) <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
> >  As a router vendor, you have more than one set of requirements you need
> to satisfy. Nobody's saying "don't do uPNP." We're saying "do PCP." We're
> saying "the IETF is not asking you to do uPNP," not "the IETF is telling
> you not to do uPNP."
> >  On Thu, Jul 25, 2024 at 4:50 PM Kawashima Masanobu(川島 正伸) <kawashimam=
> [e-mail]> wrote:
> >
> > Hi all,
> >
> > > In today’s v6ops meeting there was mention of UPnP. Having a way for
> client
> > > devices to signal to network infrastructure what traffic they want to
> receive is a
> > > good idea. However, doing that using the UPnP IGD protocol would be a
> > > disastrously bad idea.
> >
> > I agree with having a way for client devices to signal to network
> infrastructure.
> > However, I'm still not sure UPnP IGD is bad idea.
> >
> > As you may know, Broadband Forum has released TR-124 issue 9 on July
> 2024.
> > https://rg-device-requirements.broadband-forum.org/index.htm
> >
> > Related parts are as follows.
> >
> > [WAN.PCP.1]
> >  The RG MUST support Port Control Protocol (PCP) Client as specified in
> RFC 6887
> >
> > [WAN.PCP.7]
> >  The RG MUST embed an interworking function to ensure interworking
> between the UPnP IGD (Internet Gateway Device) used by CPE LAN devices in
> the LAN and PCP as defined in RFC 6970
> >
> > [MGMT.UPnP.IGD.ACRF.1]
> > The RG MUST support UPnP Internet Gateway Device:2 root device. This
> specification is available for download at
> http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
> >
> > As one of CE router vendor, what should I do?
> > Should I ignore TR-124 because UPnP will be deprecated soon?
> > or should we mention UPnP in some form in RFC 7084bis?
> >
> > As I commented on v6ops WG meeting a while ago, UPnP IGDv2(for IPv6) is
> increasing in Japan.
> > Because our CE router support it, and some gaming title support UPnP
> controll point as well.
> > Syncthing(file sharing app) has also supported UPnP IGDv2.
> > Addition to this, we also recognized UPnP IGDv2 implementation
> increasing in some countries.
> >
> > Please let me know your opinion.
> >
> > Regards,
> > Masanobu
> >
> > ========================
> >  NEC Platforms, Ltd.
> >  KAWASHIMA Masanobu
> >  [e-mail]
> >  https://www.necplatforms.co.jp/en/
> > ========================
> >
> >
> >
> > > -----Original Message-----
> > > From: Stuart Cheshire <cheshire=[e-mail]>
> > > Sent: Friday, July 26, 2024 5:33 AM
> > > To: [e-mail]
> > > Subject: [v6ops] Traffic control protocols (PCP and UPnP IGD)
> > >
> > > In today’s v6ops meeting there was mention of UPnP. Having a way for
> client
> > > devices to signal to network infrastructure what traffic they want to
> receive is a
> > > good idea. However, doing that using the UPnP IGD protocol would be a
> > > disastrously bad idea.
> > >
> > > For a list of the many flaws of UPnP IGD see RFC 6886:
> > >
> > > <https://datatracker.ietf.org/doc/html/rfc6886#section-9>
> > >
> > > This is why the IETF needed to create a robust reliable protocol for
> doing this, Port
> > > Control Protocol:
> > >
> > > <https://datatracker.ietf.org/doc/html/rfc6887>
> > >
> > > If an IETF document is going to recommend or require a way of doing
> this, it should
> > > be using RFC 6887, both because that is an IETF Standards Track
> protocol, and
> > > (more importantly) because of the technical merits of that protocol.
> > >
> > > If the UPnP organization still existed then maybe they could try to
> design a
> > > replacement for IGD that works reliably, but what would be the point
> when the
> > > IETF has already done that?
> > >
> > > Stuart Cheshire
> > >
> > > _______________________________________________
> > > v6ops mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > _______________________________________________
> > v6ops mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > _______________________________________________
> > v6ops mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>