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

11–20 of 111 posts

Re: A most elegant TCP hole punching algorithm

#11

Post by takipsizad »

Veserv wrote: post #9

Needing to punch holes in NAT is one of the most idiotic own-goals in the entire field of networking. NAT is effectively your router doing DHCP with a 17-bit suffix (16-bit port + 1 bit for UDP vs TCP) to each of your applications and then not telling you the address it gave you or how long it is good for (which is what a regular DHCP lease does). This is in addition to it, most likely, already doing regular DHCP and…

it's been already done ISPs just don't properly implement it (NAT-PMP and it's relatives)

Re: A most elegant TCP hole punching algorithm

#12

Post by cbdevidal »

eptcyka wrote: post #10
Veserv wrote: post #9

Needing to punch holes in NAT is one of the most idiotic own-goals in the entire field of networking. NAT is effectively your router doing DHCP with a 17-bit suffix (16-bit port + 1 bit for UDP vs TCP) to each of your applications and then not telling you the address it gave you or how long it is good for (which is what a regular DHCP lease does). This is in addition to it, most likely, already doing regular DHCP and…

Why not use plain IPv6 instead?

V6 adoption has reached 46.82%[1]. So it is increasingly viable for this.

[1] https://www.google.com/intl/en/ipv6/statistics.html

Re: A most elegant TCP hole punching algorithm

#13

Post by getcrunk »

EnigmaCurry wrote: post #3

> 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. It is precisely this point that has flummoxed me when connecting my p2p wireguard config[1] with a friend that uses a pfsense router, no matter what we tried, pfsense always chooses a random source port…

[flagged]

Re: A most elegant TCP hole punching algorithm

#14

Post by lxgr »

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 from a given host/port pair is desired for the next few seconds. Basically a lightweight, in-band port mapping protocol.

It could have well been an official recommendation to facilitate TCP hole punching, but I guess it’s too late now, as firewall behaviors have had decades to evolve into different directions.

Re: A most elegant TCP hole punching algorithm

#15

Post by lxgr »

getcrunk wrote: post #13
EnigmaCurry wrote: post #3

> 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. It is precisely this point that has flummoxed me when connecting my p2p wireguard config[1] with a friend that uses a pfsense router, no matter what we tried, pfsense always chooses a random source port…

[flagged]

Did you validate this solution yourself?

Re: A most elegant TCP hole punching algorithm

#16

Post by lxgr »

Veserv wrote: post #9

Needing to punch holes in NAT is one of the most idiotic own-goals in the entire field of networking. NAT is effectively your router doing DHCP with a 17-bit suffix (16-bit port + 1 bit for UDP vs TCP) to each of your applications and then not telling you the address it gave you or how long it is good for (which is what a regular DHCP lease does). This is in addition to it, most likely, already doing regular DHCP and…

> If you could just ask your router for a lease on a chunk of IP+NAT addresses

The “just” is doing a lot of lifting there. I’m glad the various port mapping protocols didn’t really take off and it looks like IPv6 is going to actually make it instead. Much less complexity in most parts of the stack and network.

Re: A most elegant TCP hole punching algorithm

#18

Post by littlestymaar »

Veserv wrote: post #9

Needing to punch holes in NAT is one of the most idiotic own-goals in the entire field of networking. NAT is effectively your router doing DHCP with a 17-bit suffix (16-bit port + 1 bit for UDP vs TCP) to each of your applications and then not telling you the address it gave you or how long it is good for (which is what a regular DHCP lease does). This is in addition to it, most likely, already doing regular DHCP and…

Hole punching is doing exactly what you describe, just in a non-standardized way.

We could have a standard for doing that directly at the NAT box level instead of relying on a third party STUN server, it simply didn't happen (and in fairness, the benefits would be quite minimal).

Re: A most elegant TCP hole punching algorithm

#19

Post by nneonneo »

getcrunk wrote: post #17
lxgr wrote: post #15

Earlier quoted context omitted.

Did you validate this solution yourself?

No, hence the all caps ai disclaimer. But seems plausible

Lord, we're how many years into using LLMs, and people still don't understand that their whole shtick is to produce the most plausible output - not the most correct output?

The most plausible output might be correct, or it might be utter bullshit hallucinations that only sound correct; the only way to tell is to actually try it or cross-reference primary sources. Unless you do, the AI answer is worthless.

The reason why they're getting so good at code now is that they can check their output by running and testing it; if you're just prompting questions into a chatbot and then copying their output verbatim to a comment, you're not adding any meaningful value.

Re: A most elegant TCP hole punching algorithm

#20

Post by CamelCaseCondo »

sholladay wrote: post #7

This is a great algorithm! In this era where AI is eating away at how deterministic computers are, I really appreciate reading about an elegant solution to a real problem using deterministic logic.

We still live in an age of deterministic computers. It’s the software that’s become fuzzy. (And since we’re on the subject: there’s no AI)
Post reply on HN