Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A most elegant TCP hole punching algorithm

robertsdotpm.github.io

Post reply on HN
Print view View original

91–100 of 111 posts

Re: A most elegant TCP hole punching algorithm

#91

Post by lxgr »

aboardRat4 wrote: post #58
lxgr wrote: post #14

Does TCP hole punching actually work with common CPEs and CG-NATs? I don’t think I’ve ever seen it done successfully and have often wondered if it’s for a lack of use cases or due to its bad success rate and complexity compared to UDP hole punching. That said, I really wish there was a standardized way to do it. Some sort of explicit (or at least implicit but unambiguous) indicator to all firewalls that a connection…

The standard way to do it is called ipv6. Implementing it is probably easier than any of those RFCs

Firewalls exist in IPv6 too, so hole punching still has a reason to exist as well.

Re: A most elegant TCP hole punching algorithm

#92

Post by lxgr »

IgorPartola wrote: post #75
patrakov wrote: post #63

Earlier quoted context omitted.

No, it isn't. Many middleboxes (including OpenWrt by default) drop unsolicited inbound TCP connections even on IPv6, and therefore the same hole-punching algorithm is needed. The hole being punched is in the stateful firewall's connection tracker, not in the NAT. Basically, both parties need to convince their router that it is an outgoing connection initiated by them, not a prohibited-by-policy incoming connection.

There are two separate problems with IPv4 and only one applies to IPv6. Allowing incoming connections through a restrictive firewall is applicable to both. Address mangling via NAT applies only to one. Note also that in the IPv4 world you might be behind more than one layer of NAT which will make everything infinitely worse. Honestly ISPs really missed an opportunity to essentially provide IPv6-only as a service and…

> Honestly ISPs really missed an opportunity to essentially provide IPv6-only as a service

This is in fact how many 4G and 5G networks work today. I’m sending this reply via one right now.

For wired connections, many DOCSIS cable ISPs use DS-Lite, which is v6 only on the last hop as well.

Re: A most elegant TCP hole punching algorithm

#93

Post by lxgr »

ectospheno wrote: post #80
IgorPartola wrote: post #75

Earlier quoted context omitted.

There are two separate problems with IPv4 and only one applies to IPv6. Allowing incoming connections through a restrictive firewall is applicable to both. Address mangling via NAT applies only to one. Note also that in the IPv4 world you might be behind more than one layer of NAT which will make everything infinitely worse. Honestly ISPs really missed an opportunity to essentially provide IPv6-only as a service and…

IPv6 nat is a thing that exists and is used. IPv6 purists like to imagine it doesn't exist which is cute.

It’s extremely rare compared to v4, where it’s more common than not. I haven’t seen it with a single consumer ISP, and why should they use it?

Re: A most elegant TCP hole punching algorithm

#94

Post by kpil »

abcd_f wrote: post #73

Claimed elegance is based on a very bold assumption that the NAT device preserves the source port of outbound connection. Hardly the case in even half of typical deployment cases.

My internet provider didn't even maintain the ip-address. They have a pool of egress routes and seems to route round-robin. Basically every new connection can be from any address in the pool.

I had to call them to make it stop since it tripped the VPN solution at work, that interpreted it as a MIM attack. They disabled it no questions asked as soon as I called, so I guess it mostly works for most people, but not all.

But on that note, isn't it basically time now for IPv6 so we can stop shit like this and go to directly addressable devices like everyone did in the early 90s.

Re: A most elegant TCP hole punching algorithm

#95

Post by DetroitThrow »

killbot5000 wrote: post #85
taftster wrote: post #74

Earlier quoted context omitted.

I like your comment, but it seems the author acknowledged this as a caveat to the algorithm. >Many home routers try to preserve the source port in external mappings. This is a property called “equal delta mapping” – it won’t work on all routers but for our algorithm we’re sacrificing coverage for simplicity. So to what percentage is this coverage sacrificed exactly? No idea. Not as useful if the percentage is high, a…

It’s the same assumption is required for any hole punching handshake (including STUN). > This is a property called “equal delta mapping” FWIW I’ve worked in computer networking for 20 years and have never heard it called this. This blog is the only source that comes up when I search for that exact term. I wonder where the author got it from.

>equal delta mapping

Very clearly a hallucination

Re: A most elegant TCP hole punching algorithm

#96

Post by kordlessagain »

This perfectly eliminates the last centralized bottleneck for P2P agent networks.

We are dropping this deterministic punch directly into the grubcrawler.dev edge binaries. Instead of relying on STUN/TURN servers to coordinate a swarm, millions of nodes trapped behind residential NATs will use the unix timestamp to mathematically predict a collision course, aggressively punch through their firewalls, and instantly hand the raw TCP socket over to rust-lightning (LDK).

No DNS. No signaling servers. No legacy IP registries. Just a self-assembling Lightning mesh of autonomous agents spinning up encrypted channels and executing paid RPC calls entirely in the dark.

Re: A most elegant TCP hole punching algorithm

#97

Post by IgorPartola »

patrakov wrote: post #78
IgorPartola wrote: post #75

Earlier quoted context omitted.

There are two separate problems with IPv4 and only one applies to IPv6. Allowing incoming connections through a restrictive firewall is applicable to both. Address mangling via NAT applies only to one. Note also that in the IPv4 world you might be behind more than one layer of NAT which will make everything infinitely worse. Honestly ISPs really missed an opportunity to essentially provide IPv6-only as a service and…

Exactly. And look, the linked Python script only solves one problem: making both firewalls believe that the party behind them is the one who initiated the connection. Address/port mangling is not addressed at all, both public addresses need to be provided externally. And it's simply not true that there is no NAT in the wild with IPv6: every OPNsense installation with two uplinks and the need for anything better than…

If you have two uplinks and running OPNSense (saying this as someone that does exactly this), you have a particular setup that you have clearly taken ownership of. If that breaks your experience with standard tech, that is part of what you traded off when you customized your setup as such.

IPv6 is strictly worse for this precisely because it is treated as a second class citizen. If it was the default in all the tutorials and we started naming IPv4 as the legacy protocol developers would know better.

Re: A most elegant TCP hole punching algorithm

#99

Post by ranger_danger »

gzread wrote: post #71
brewmarche wrote: post #57

Earlier quoted context omitted.

That’s true we won’t get rid of hole-punching with IPv6. But at least it will get rid of TURN.

The hole punching is so much simpler because you don't need to guess your own address and port - you just know it

Doesn't that assume that your machine is given its own world-routable (and unfiltered) v6 address?

Re: A most elegant TCP hole punching algorithm

#100

Post by majorchord »

brewmarche wrote: post #57
TuxPowered wrote: post #39

Earlier quoted context omitted.

Even with IPv6 you still might have stateful firewalls allowing only for outbound connection at both ends (e.g. a CPE a.k.a. “WiFi router”) and to establish communication you’d need to punch a hole in those firewalls.

That’s true we won’t get rid of hole-punching with IPv6. But at least it will get rid of TURN.

How will it get rid of TURN? Can't IPv6 addresses still be firewalled by your carrier like they do already for IPv4?
Post reply on HN