AddPinhole vs NAT66

[motohiko-sato]

We are creating a game client that runs AddPinhole so that UPnP functions for IPv6 can be used in router environments that use miniupnpd. At present, NAT does not exist in many IPv6 environments around the world. However, the existence of NAT66 is steadily becoming apparent, starting in some regions. I think that UPnP functions for IPv6 are also effective in NAT66 environments, but WANIPv6FirewallControl Service is designed on the premise of IPv6 without NAT, so it has some problems, and these need to be improved in order to support it as a product. From the perspective of miniupnpd, what are your thoughts on supporting NAT in IPv6 environments?

---

The results of the NAT survey for IPv6 from the perspective of games are available as a presentation at CEDEC, a conference for game developers in Japan. https://cedil.cesa.or.jp/cedil_sessions/view/2928

For reference, we have attached a few English translations of the linked documents.

[miniupnp]

As far as I understand, the IGD standard doesn't support NAT66. I think you should have a look at PCP (RFC6887).

How to use PCP in a NAT66 scenario is not explicit in the RFC, but it may be possible. You should look for a PCP server that support it.

[motohiko-sato]

I think that PCP is a good alternative to UPnP.

However, I am concerned that using UPnP for IPv4 and PCP for IPv6 will make client implementations more complex and cause unnecessary confusion. Also, I think that the fact that UPnP, which was used for IPv4, cannot be used for IPv6 is a negative factor in terms of the spread of IPv6.

Is there any particular reason for promoting PCP rather than an extension of the existing UPnP specification?

[miniupnp]

Any extension to the existing UPnP specification is doomed to fail due to the wish of a major actor : https://miniupnp.tuxfamily.org/forum/viewtopic.php?t=1840

[motohiko-sato]

There is a QoS service for GeforceNOW created by ASUS as a successful example of a specific UPnP extension, but as you say, it is hard to get it to work well with many environments using a specific extension.

So, how about first proposing an extension specification to OCF (https://openconnectivity.org) and then proceeding with UPnP implementation in line with that? We are currently discussing the extension specification with several router vendors. As most of the UPnP libraries that many router vendors have recently adopted are miniupnpd, therefore, we would be grateful if the miniupnp project would propose the extension specification to OCF with us.

[miniupnp]

@motohiko-sato If you develop the reference implementation of you extension specification proposed to OCF into miniupnpd, I will integrate it.

As long as the extension is not official specification, we could make it an "enable on build" option.

[axet]

@motohiko-sato Apps need to implement different options for user to choose of IP configurations, even that RFC saying here should be no additional configuration based on ipv4/6.

For example here a few common configs:

1. ipv4 only with public ip
2. ipv4 behind nat
3. ipv4 behind nat + ipv6 public ip
4. ipv4 behind nat + ipv6 behind nat.
5. ipv6 only with public ip
6. ipv6 behind nat

Apps (especially internet sharing apps) should let user to choose what connection should be used based on preferences. I may want to use only ipv4 connection. Or my router may has single ipv6 with PinHole daemon (like miniupnpd). Or app should use ipv6 public ip assigned by router. Even that is possible to detect, good apps should let user choose what connection to use.