miniupnpd: Client permission rules do not support IPv6 or MAC addresses

[Self-Hosting-Group]

With IPv6 on most networks, clients derive their IPv6 address from the prefix using SLAAC, but it's not stable as it can be changed using one of the following extensions. It would be great if there were client permission rules for MAC addresses. One rule entry would allow ports to be opened for both IPv4 and IPv6.

It's not easy to get the incoming MAC address to match, but such rules would be brilliant.

Temporary address extension
https://datatracker.ietf.org/doc/html/rfc8981

Stable privacy / semantically opaque interface identifiers
https://datatracker.ietf.org/doc/html/rfc7217

Currently, if IPv6 is enabled in MiniUPnPd, all clients are allowed to open IPv6 ports.

[miniupnp]

Indeed it would be great. Anyway I don't think there so much demand about improving the WANIPv6FirewallControl:1 implementation.
I may be wrong, but most user are only interested in IGDv1 WANIPConnection:1 implementation, as that is what is used by MS Windows and game consoles.

[Self-Hosting-Group]

@miniupnp: UPnP IGD and PCP/NAT-PMP are also used for IPFS, Transmission (BitTorrent), audio/video RTC client applications and the self-hosting of applications, to name a few. The demand for IPv6 support is increasing, mainly due to the growing number of Internet subscriptions without assigned public IPv4 addresses (CG-NAT'ed), but with reachable IPv6 (e.g. with Dual-Stack Lite).
https://docs.ipfs.tech/how-to/nat-configuration/#enable-upnp
https://github.com/transmission/transmission/blob/main/docs/Port-Forwarding-Guide.md#nat-pmp--upnp

[miniupnp]

Your example illustrate what I was saying : as far as I know there is no support for WANIPv6FirewallControl:1 in Transmission.

I found it too bad, but that's just reality : WANIPv6FirewallControl:1 is not widely used.

[miniupnp]

To check the MAC address, miniupnpd would have to use the SIOCGARP ioctl.