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

41–50 of 111 posts

Re: A most elegant TCP hole punching algorithm

#41

Post by enoint »

Veserv wrote: post #22
lxgr wrote: post #16

Earlier quoted context omitted.

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

It is always a mystery how people just randomly misinterpret what I write. At literally no point did I mention port mapping. I am pointing out how the problem NAT “solves” is just dynamic address configuration. They have implemented a N+K bit address where the N-bit prefix is routed and allocated using IP and the low K-bits are routed and allocated like a custom fever dream. You can just do it all the same way instea…

I didn’t see it as mysterious. 25 years ago, the problem as stated went through lots of consensus to become IPv6. It took a few years for SLAAC to emerge. But we don’t need it to be homogeneous; the router advertises different feature levels via ICMPv6.

Re: A most elegant TCP hole punching algorithm

#42

Post by ufocia »

sholladay wrote: post #40
CamelCaseCondo wrote: post #20

Earlier quoted context omitted.

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)

Yes, but a computer is just a paperweight without its software. Also, increasingly the hardware is being specifically designed and optimized for that non-deterministic software. The experience of using computers is changing and we’re still in the early days of that shift. Of course there’s still plenty of deterministic software you can run… for now.

I can almost guarantee that all of AI runs on deterministic hardware and software. AI is just (near?) the top of the stack. There is no reason, and probably never will be to have a purely heuristic computer. Deterministic systems are way simpler and cheaper to handle very routine well defined tasks. Even AI authors code behind the scenes to process data files deterministically.

Re: A most elegant TCP hole punching algorithm

#45

Post by hdgvhicv »

lxgr wrote: post #36
hdgvhicv wrote: post #34

Earlier quoted context omitted.

Basically the same thing. If you legitimately need to establish a connection then put a firewall rule in, whether that needs nat or pat is a function of your available addresses. If you are tying to work around your firewall because it isn’t yours, that’s not a legitimate use.

Love it when random people tell me whether my use case is legitimate or not without apparently even knowing it exists! Take mobile data connections, for example: Most people don't want to pay for metered (by the byte) inbound traffic they didn't ask for that also drains their battery, but do want to be able to establish P2P connections for lower latency VoIP etc. This is a firewall that's definitionally "not theirs",…

If you are trying to break through a firewall you don’t own then that’s not legitimate.

If you are buying firewall as a service then request a user interface or change your service provider.

Re: A most elegant TCP hole punching algorithm

#46

Post by ufocia »

hdgvhicv wrote: post #34
lxgr wrote: post #31

Earlier quoted context omitted.

Firewalls aren't nearly as bad as NAT.

Basically the same thing. If you legitimately need to establish a connection then put a firewall rule in, whether that needs nat or pat is a function of your available addresses. If you are tying to work around your firewall because it isn’t yours, that’s not a legitimate use.

You're assuming that the firewall was configured correctly or that the firewall admin is cooperative. That's a big ask.

On the other hand, there is plenty of badly written networked software. I bet most of the networked software developers have no idea how to correctly plumb their software. They just open whatever connection, e.g. sockets, their OS provides and just run with it without care of the underlying layers. The OSI model theory in fact encourages this ignorance.

Re: A most elegant TCP hole punching algorithm

#48

Post by ignoramous »

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…

> 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

NAT Behavioural Requirements for Unicast UDP, https://datatracker.ietf.org/doc/html/rfc4787

NAT Behavioural Requirements for TCP, https://datatracker.ietf.org/doc/html/rfc5382

Re: A most elegant TCP hole punching algorithm

#49

Post by lxgr »

hdgvhicv wrote: post #45
lxgr wrote: post #36

Earlier quoted context omitted.

Love it when random people tell me whether my use case is legitimate or not without apparently even knowing it exists! Take mobile data connections, for example: Most people don't want to pay for metered (by the byte) inbound traffic they didn't ask for that also drains their battery, but do want to be able to establish P2P connections for lower latency VoIP etc. This is a firewall that's definitionally "not theirs",…

If you are trying to break through a firewall you don’t own then that’s not legitimate. If you are buying firewall as a service then request a user interface or change your service provider.

Are you even acknowledging my example? Where does it exist in your bimodal model of reality of "my firewall" and "somebody else's firewall"?

What provider would you suggest somebody wanting to make VoIP calls on their smartphone switch to that allows port forwarding of the kind you describe? And which popular VoIP app would support statically forwarded ports like that?

Re: A most elegant TCP hole punching algorithm

#50

Post by lxgr »

ignoramous wrote: post #48
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…

> 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 NAT Behavioural Requirements for Unicast UDP , https://datatracker.ietf.org/doc/html/rfc4787 NAT Behavioural Requirements for TCP , https://datatracker.ietf.org/doc/html/rfc5382

> NAT Behavioural Requirements for TCP

TIL, thank you! I've been looking for this for quite a while after hearing it indirectly referenced recently, but only found host-side specifications for TCP simultaneous open.

Do you happen to know if common firewalls and NATs support it? If they do, I really wonder why TCP hole punching isn't more common.

Post reply on HN