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

[Daryll Swer <[e-mail]>]

> Assumed IPv6 mostly network deployment, 464XLAT is the appropriate choice.

464xlat is *stateful*, MAP-T is *stateless*, I heavily prefer stateless
approaches, why avoid chances to minimise computing overhead in general…

There are multiple deployments of MAP-T, some example:
https://pc.nanog.org/static/published/meetings/NANOG71/1452/20171004_Gottlieb_Mapping_Of_Address_v1.pdf

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


On Fri, 26 Jul 2024 at 22:17, Kawashima Masanobu(川島 正伸) <kawashimam=
[e-mail]> wrote:

>
>
> Hi Daryll,
>
>
> ＞Don't get me wrong, I'm in favour of PCP for only-IPv4 on LTE/5G with
> 464xlat.
> >I'm in favour of PCP for CPE devices for both Dual-Stack IPv4/IPv6 and
> IPv6-only CPEs (MAP-T).
>
>
> I'm in favour of PCP for CPE devices for both Dual-Stack IPv4/IPv6 and
> IPv6-only CPEs (464XLAT). :-)
> Assumed IPv6 mostly network deployment, 464XLAT is the appropriate choice.
>
> As for firewall control protocol, IMHO, CSA Matter is the appropriate
> protocol for the future.
>
> Regards,
>
> Masanobu
>
>
>
> ========================
>
>  NEC Platforms, Ltd.
>
>  KAWASHIMA Masanobu
>
>  [e-mail]
>
>  https://www.necplatforms.co.jp/en/
>
> ========================
>
>
>
>
>
>
>
> *From:* Daryll Swer <contact=[e-mail]>
> *Sent:* Saturday, July 27, 2024 1:20 AM
> *To:* Kawashima Masanobu(川島 正伸) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [v6ops] Re: Traffic control protocols (PCP and UPnP IGD)
>
>
>
> Kawashima
>
>
>
> Yeah, that's why I asked if there's ANY application software in the public
> domain that actually uses PCP. I've never seen one.
>
>
>
> Don't get me wrong, I'm in favour of PCP for *only*-IPv4 on *LTE*/*5G*
> with 464xlat. I'm in favour of PCP for CPE devices for both Dual-Stack
> IPv4/IPv6 and IPv6-only CPEs (MAP-T).
>
>
> *--*
>
> Best Regards
>
> Daryll Swer
>
> Website: daryllswer.com
> <https://mailtrack.io/l/bfcb5ab50fca7ddb397e36d1b73183be0c56a937?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=b4d24d1084f8368f>
>
>
>
>
> On Fri, 26 Jul 2024 at 21:42, Kawashima Masanobu(川島 正伸) <kawashimam=
> [e-mail]> wrote:
>
>
>
> Hi Daryll,
>
>
> Just FYI, in Japan, NTT docomo is using 464XLAT on their 5G network.
> However, I’ve never seen PCP implementation.
> Press Releases : DOCOMO to Roll Out IPv6 Single-stack Support Beginning
> Feb. 1
> <https://www.docomo.ne.jp/english/info/media_center/pr/2022/0131_00.html>
>
> It is the chiken and egg problem.
> If there is no actual app with PCP client, there is no PCP server as well.
> We can use PCP on mobile network technically though.
>
> Regards,
>
> Masanobu
>
>
>
> ========================
>
>  NEC Platforms, Ltd.
>
>  KAWASHIMA Masanobu
>
>  [e-mail]
>
>  https://www.necplatforms.co.jp/en/
>
> ========================
>
>
>
>
>
>
>
> *From:* Daryll Swer <contact=[e-mail]>
> *Sent:* Friday, July 26, 2024 10:51 PM
> *To:* Ted Lemon <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* [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]
>
>