UPNP alternative for v6 statefull firewalls
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 6.9k
- Forks
- 1.3k
- Avg merge
- 13d 21h
- Merged PRs (30d)
- 1
Description
Even tho NAT was originally meant as a tool to make IT management easier when merging different company networks after merger and acquisitions, it has been extremely widely deployed due to the IPv4 starvation and users started relying on it for security as it allows them to play it loosy goosy on a private network without being exposed to internet (which is terrible horizontal security but whatever, it's convenient and I did used to do that myself).
To meet this security expectation from customers, here where I live (and I expect in most places) all off the shelf residential and business IPv6 deployments ship with stateful IPv6 firewalls by default. It would be nice if we could not rely on DCUTR if the router allows us to do so because the extra hops of DCUTR add latency and make it unsuitable for use-cases like DHT servers.
Alternatives:
- RFC3633 would allow us to request a delegated range, FWIW the 2 routers I have tried this with also add a firewall exception to the delegated range, maybe this is a flag in the request ? Overall I have only ever seen it used with `/64` which is a bit overkill, I don't know if it's possible to just request a `/128`. I think this also requires `root` (or equivalent) permissions or some advanced networking capabilities for the libp2p process.
- UPNP `AddPinHole` https://github.com/libp2p/go-libp2p/issues/2496#issuecomment-1689895095
- ... ? ***ideas wanted***
Asking people to change the config option of their router is not an option for the same reason asking people to port forward does not work and why we have upnp and dcutr.
---
Priority requirement: low ~ very low
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing DCUTR behavior and the issue's proposed RFC3633 and UPnP AddPinHole alternatives. The issue does not name implementation files or tests; the work is complete when a viable IPv6 stateful-firewall traversal approach is selected and implemented without relying on DCUTR.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100