Typically firewalls will record the src and dst header values of outbound IP packets then temporarily allows inbound IP packets that have those values flipped.
You're just asserting that without explination. Please correct me if I'm wrong, but afiak the only difference in NAT hole-punching is that clients don't know their public port mapping ahead of time. This actually doesn't make a huge difference to the process because in practice, you still want a central rendezvous server for automated peer IP discovery. The alternative being that each peer shares their IP with every other peer "offline", as in manually through an external service like IRC or discord, which is a horrible user experience.
They linked a whole article detailing the complexities of specifically NAT traversal.
I should think it obvious that by removing an entire leaky layer of abstraction the process would be much simpler. Yes, you still need a coordination server, but instead of having to deduce the incoming/outgoing port mappings you can just share the "external IP" of each client--which in the IPV6 case isn't "external," it's just "the IP".
>Also NAT is a pretty simple abstraction, it's literally a single table.
...And now, let's try punching a hole through this "simple" table. Oops, someone is using a port-restricted or symmetric NAT and hole punching has gotten just a tad more complicated.
How do you punch trough firewalls? You have to manually open them, punching through firewall would be a firewall vulnerability.
This is a common function of uPnP, which I've seen as features in router config pages since the mid 2000s.
https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_tr...
Typically firewalls will record the src and dst header values of outbound IP packets then temporarily allows inbound IP packets that have those values flipped.
You're just asserting that without explination. Please correct me if I'm wrong, but afiak the only difference in NAT hole-punching is that clients don't know their public port mapping ahead of time. This actually doesn't make a huge difference to the process because in practice, you still want a central rendezvous server for automated peer IP discovery. The alternative being that each peer shares their IP with every other peer "offline", as in manually through an external service like IRC or discord, which is a horrible user experience.
> You just asserted that without explanation.
They linked a whole article detailing the complexities of specifically NAT traversal.
I should think it obvious that by removing an entire leaky layer of abstraction the process would be much simpler. Yes, you still need a coordination server, but instead of having to deduce the incoming/outgoing port mappings you can just share the "external IP" of each client--which in the IPV6 case isn't "external," it's just "the IP".
I already am aware of how NAT traversal works. Linking a generic article explaining it is not a meaningful response.
Also NAT is a pretty simple abstraction, it's literally a single table.
>Also NAT is a pretty simple abstraction, it's literally a single table.
...And now, let's try punching a hole through this "simple" table. Oops, someone is using a port-restricted or symmetric NAT and hole punching has gotten just a tad more complicated.
Agreed; Or they're using CG-NAT, or consumer grade NAT behind CG-NAT, or....