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.

▲

tenacious_tuna 14 hours ago | parent [-]

> 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".

▲

mightyham 12 hours ago | parent [-]

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.

▲

orangeboats 10 hours ago | parent [-]

>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.

	▲	tenacious_tuna 5 hours ago \| parent [-]
		Agreed; Or they're using CG-NAT, or consumer grade NAT behind CG-NAT, or....