Dudes: IPv6, please, come on, meh.
A most elegant TCP hole punching algorithm
101–110 of 111 posts
Re: A most elegant TCP hole punching algorithm
#102Earlier quoted context omitted.
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
#103Earlier 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.
P2P traffic is illegitimate according to you? Like Skype calls? You think Skype should not exist? (Well it doesn't exist any more, but whatever replaced it)
I can’t do it on someone else’s network as they have granted me a limited access and do big slow me to open such holes.
Re: A most elegant TCP hole punching algorithm
#104Earlier 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.
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.…
Typically these complaints come from people using other people’s firewalls against the policy of that firewall.
Re: A most elegant TCP hole punching algorithm
#105- you know each others IP's (or have a way to signal it) - can't decide on a port in the same message - don't suffer from NAT port randomization I'm not saying it will never happen, but the Venn diagram of this being the minimum complexity solution just doesn't seem very large?
The real problem is the port randomization if any client is behind a symmetric NAT. The search space for randomly trying port numbers is too large.
There are some ways to reduce the search space, like port prediction. But ultimately, a large dose of port scanning is the only way I know of to make the connection reliably. And there’s only so much of that you can do before triggering IPS or overwhelming the NAT.
IPv6 makes this way easier, of course!
Re: A most elegant TCP hole punching algorithm
#106Earlier 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.
The name "equal delta" just means a type of NAT with a delta that tries to preserve the source port. Not to be confused with "preserving" type deltas (that preserve "the same numerical distance" between successive mappings -- e.g. a "preserving delta" type with a value of +1 means each successive NAT allocation is one more than the previous.)
Edit: It took me a while but I am pretty sure this was the original paper that goes into mapping allocations. https://www.usenix.org/legacy/events/imc05/tech/full_papers/...
In my mind there was a neat table with named deltas and examples but maybe that was what I pulled from the text.
Re: A most elegant TCP hole punching algorithm
#107Dudes: IPv6, please, come on, meh.
maybe in another 20 years my local monopoly will consider IPv6 adoption, but I'm not holding my breath
In my country: only a few mobile ISPs are not yet native IPv6. The thing now would be to get a fixed IPv6 for mobile internet (which would remove the need of a name->IP "resolver"), but I wonder if the mobile ISPs can handle the quality of "security" this requires. (we all know about enshitific*tion).
Re: A most elegant TCP hole punching algorithm
#108Earlier quoted context omitted.
P2P traffic is illegitimate according to you? Like Skype calls? You think Skype should not exist? (Well it doesn't exist any more, but whatever replaced it)
I have no problem with p2p traffic as I can open whatever holes I want in my firewall. I can’t do it on someone else’s network as they have granted me a limited access and do big slow me to open such holes.
Re: A most elegant TCP hole punching algorithm
#109Earlier quoted context omitted.
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.
> It’s the same assumption is required for any hole punching handshake (including STUN). This is incorrect. Hole punching requires being able to predict external port. That's it. If the port remains the same, it certainly simplifies things, but ports going up (or down) by 1 (or 2, or 5) with each new mapping is quite common, trivial to detect and to punch through.
Re: A most elegant TCP hole punching algorithm
#110Earlier 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)
Are you saying that "Artificial Intelligence" is just not properly named for now.we.currently use it? Feels like at least the distinction of qualifying it with the term, "LLM" is popular.