1
NAT-PMP allows a computer in a private network to automatically configure the router to forward ports to it.
Contrary to UPnP, NAT-PMP focuses only on NAT-traversal, and does not try to reinvent the wheel implementing a pile of different feature in a single protocol spec.
Many router/networks support only NAT-PMP and not UPnP, so it’s implementatation would help Syncthing work on those environments.
Should this be debated/do we need to discuss this further, or should this have been a github feature request?
2 Likes
calmh (Jakob Borg) 2
There’s no debate needed here as far as I’m concerned - it should be supported. Compared to the grisly monstrosity that is UPnP, NAT-PMP is a small, easy and nifty protocol too.
1 Like
hobarrera (Hugo Osvaldo Barrera) 3
That’s mostly because UPnP tries to be natpmp+zeroconf+bonjour+aBunchOfOtherStuff all in one huge blob. 
Should I open a github ticket for this?
calmh (Jakob Borg) 4
Yeah but still, HTTP over multicast UDP… 
Yeah, please do open an issue.
fingon (Markus Stenberg) 5
To be precise, what you really want is PCP support. PCP is the protocol version #2, NAT-PMP #0. Something like GitHub - libpcp/pcp: PCP client library enables PCP support fairly easily (and it should also work for NAT-PMP). If I knew Go, I would probably do this myself.
Disclaimer: I have contributed patch or two to that library 
hobarrera (Hugo Osvaldo Barrera) 6
Huh, interesting. I was unaware of PCP. Looks like my router’s NATPMP daemon also support PCP, which is nice to know. Also, PCP support NAT64, which is what I run on several networks. 
I do like the fact that PCP is actually an IETF Standard too. Plus, that lib support both NATPMP and PCP, so that’s an additional plus to using it.
1 Like