# NAT-PMP support
**URL:** https://forum.syncthing.net/t/nat-pmp-support/939
**Category:** Feature
**Created:** [September 15, 2014, 2:50pm UTC](https://forum.syncthing.net/t/nat-pmp-support/939 "2014-09-15T14:50:55Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@hobarrera](https://forum.syncthing.net/u/hobarrera)
#### Post date: [September 15, 2014, 2:50pm UTC](https://forum.syncthing.net/t/nat-pmp-support/939/1 "2014-09-15T14:50:55Z")
[NAT-PMP](https://tools.ietf.org/html/rfc6886) 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?
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [September 15, 2014, 4:00pm UTC](https://forum.syncthing.net/t/nat-pmp-support/939/2 "2014-09-15T16:00:47Z")
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.
---
### Author:  [@hobarrera](https://forum.syncthing.net/u/hobarrera)
#### Post date: [September 15, 2014, 4:43pm UTC](https://forum.syncthing.net/t/nat-pmp-support/939/3 "2014-09-15T16:43:09Z")
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?
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [September 16, 2014, 10:06am UTC](https://forum.syncthing.net/t/nat-pmp-support/939/4 "2014-09-16T10:06:02Z")
Yeah but still, HTTP over multicast UDP… 😬
Yeah, please do open an issue.
---
### Author:  [@fingon](https://forum.syncthing.net/u/fingon)
#### Post date: [September 16, 2014, 10:16am UTC](https://forum.syncthing.net/t/nat-pmp-support/939/5 "2014-09-16T10:16:54Z")
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](https://github.com/libpcp/pcp) 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 🙂
---
### Author:  [@hobarrera](https://forum.syncthing.net/u/hobarrera)
#### Post date: [September 17, 2014, 1:03am UTC](https://forum.syncthing.net/t/nat-pmp-support/939/6 "2014-09-17T01:03:16Z")
> [@fingon](#):
>
> To be precise, what you really want is PCP support.
Huh, interesting. I was unaware of PCP. Looks like my router’s [NATPMP daemon](https://github.com/bodgit/natpmpd) 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](http://tools.ietf.org/html/rfc6887) too. Plus, that lib support both NATPMP _and_ PCP, so that’s an additional plus to using it.
> [@calmh](#):
>
> Yeah, please do open an issue.
>
>
> Originally discussed in \[discourse\](https://discourse.syncthing.net/t/nat-pmp-su…pport/939/), it was agreed that \[NATPMP\](https://tools.ietf.org/html/rfc6886) & \[PCP\](http://tools.ietf.org/html/rfc6887) is very important for NAT traversal, especially in scenarios with no UPnP support.
>
> \[This library\](https://github.com/libpcp/pcp) was mentioned, and covers both protocols, though I'm unsure if a C library can be used from golang.
---
### Author:  [@system](https://forum.syncthing.net/u/system)
#### Post date: [May 12, 2017, 1:19pm UTC](https://forum.syncthing.net/t/nat-pmp-support/939/7 "2017-05-12T13:19:39Z")