Port Control Protocol support

stokito · January 15, 2022, 11:21pm

I'm not a network expert but was also interested in the topic and did some investigation.
In devel list was a long discussion IPv6 firewall and Port Control Protocol with a proposition to allow incoming connections for IPv6, at least for non root ports above 1024. But the idea was declined because users may not expect such behavior. Personally I think that any ephemeral port 32768–60999 must be open. Or even it may be some subrange of those ports that will be known to be public.

So a computer from a local network must clearly ask a router to open a port, renew it each 30 minutes and keep watching that it wasn't closed after router's reboot. This makes voip/p2p/gaming software more complicated. But OpenWRT definitely must support this.

To open the port the old solution was a UPNP IDG which is part of Plug-and-Play.
And this is an incredibly terrible protocol: it's kind of HTTP over UDP with SOAP style messages in XML. Specifications are unclear - that is probably the most worst documentation that I ever saw.

I wonder how it was implemented at all. But no wonder that it's very vendor specific and anybody violates spec. Anyway many routers do support it at least somehow. I had one such router but it doesn't worked

But just because nobody understands it was almost everywhere configured incorrectly and hackers from internet were able to open a hole to local network.
That's why the UPNP was simply removed or disabled by default by many manufactures: they just don't want to fix it
If you have a spare time there is a great talk Universal Pwn n Play

There is an open source minupnp project and you can install it on OpenWRT and it's even have a Luci app. But it's 140Kb quite too heavy for 4mb devices. And anyway the UPNP client is also too big and need for XML parsing library so it's not so widely used by regular programs.

In 2005 Apple developed their own lightweight protocol NAT-PMP as part of Bonjour. It's second version was renamed to Port Control Protocol because it's not only for NAT anymore.
Basically there is small differences and probably they are backward compatible.
But the PCP is widely used abbreviation so often people saying NAT-PMP/PCP or even just keep calling it in library names as NAT-PMP.
As far I know all Apple products supports it and looks like Juniper routers supports it too. But MikroTik doesn't support and users asking for it.

Looks like Apple never was interested to push this protocol, they just use for themselves with Airport Extreme routers.

Here is a good article that gives a basic understanding of IDG vs NAT-PMP Открываем порты за NAT при помощи NAT-PMP и UPnP IGD.

The NAT-PMP/PCP support was also added by the libpcp authors to the minupnp just because it does a similar thing. So this adds some confusion.
If you do want to use PCP you anyway have to install minupnp. I asked it's authors if it possible to create a PCP only miniupnpd so it can be used in 4mb routers https://github.com/miniupnp/miniupnp/issues/545

For clients there is a libnatpmp library that for example is used by Transmission. The library was developed by the miniupnp author Thomas Bernard.
OpenWRT also has a package for it with 4k size.

The libpcp that you mentioned was developed by two guys from Cisco and as Proof of Concept even tried to use libpcp for Transmission https://www.ietf.org/proceedings/87/slides/slides-87-pcp-12.pdf and submitted a patch #5415 Add PCP support for port forwarding

It's funny because looks like Transmission authors forgot about it

github.com/transmission/transmission

NAT-PMP/UPnP does not work properly in a dual stack network

opened 08:48PM - 20 May 20 UTC

lnpz1

Transmission version: 2.94 (d8e60ee44f) Router: OpenWrt 19.07.2 running miniupn…pd 2.1.20191006-4 In a dual stack network where UPnP IGDv2 is advertised over both IPv4 and IPv6, Transmission sometimes puts IPv6 address in IPv4 port mapping request resulting in failed mapping. Miniupnpd error message is like the one in https://github.com/miniupnp/miniupnp/issues/408#issuecomment-629051965 The correct behaviour in a dual stack network should be - for IPv4, it makes a port mapping request for IPv4 address - for IPv6, it makes a firewall pinhole request for IPv6 address as mentioned in https://github.com/transmission/transmission/issues/993 On a separate note, it would be better to allow users to choose preferred port mapping protocol, e.g. try PCP/NAT-PMP first, then fallback to UPnP (or vice versa). This is useful in a network where both NAT-PMP and UPnP are available (e.g. miniupnpd providing both services).

In the issue is also said that the libnatpmp doesn't support IPv6 while the libpcp seems that have a better compliance with protocol.

The miniupnp author also knows about the libpcp and even forked it to play with https://github.com/miniupnp/pcp

It looks for me like there is lack of communication between libpcp, miniupnp and transmission authors.

In the same time the libpcp doesn't have a server part, only it's mock. So the part that actually forwards packets must be implemented.
Also the libpcp client library is not published in Debian/Ubuntu and OpenWRT repos. So basically it seems not so widely used in real life.

To summarize:

It's not clear which one is better libpcp or libnatpmp. I think, ideally the libpcp must be just merged into libnatpmp because it's already used in production and can be easily upgraded by existing distribution channels. https://github.com/libpcp/pcp/issues/22
For new routers with a big storage OpenWRT may just include by default the miniupnpd and luci-app-upnp but it must be pre-configured carefully.
As an alternative we may try to develop a PCP only daemon or even just extend OpenWRT firewall. That pcpd will be small, easy to audit and configure and can be backported for tiny 4mb devices.

P.S.: some ISP may open a port for you with UPnP. So for example you may access your router from internet even without a static IP. This opens a door for next discussion about cascade PCP configurations.