- Sun Nov 01, 2015 5:34 pm
Ernesto Alvarez 818262 wrote:the simplest way is to think of it like a revolving door. door opens and closes letting packets in and out. occasionally someone gets their foot stuck in the door and poof, doors stuck in either direction until someone removes the jam which is what port forwarding essentially does in kinda simple terms, pushes it through
That's not what port forwarding does, at all. The problem is that the VVL was written for an Internet that doesn't exist anymore. Bear with me, it's a long story.
In the old days when the Internet was populated by crazy dudes with awesome facial hair, everything had its own, unique IP address and was more or less reachable from everywhere. Life was simple, and good. When machines wanted to talk to each other, it was straightforward. If a machine wanted to talk to another, it would open a random, local port
and connect to a known destination port on the other machine. When the destination machine did an accept() it would keep the known destination port open (assuming you wanted multiple connections). The point us that while you have a known port, it's really only needed on the destination. The source ports should be random.
Pretty soon, people discovered that having machines wide-open to everyone made as much sense as not putting locks on your doors, so we made firewalls and restricted what machines can talk on what ports, but that didn't change matters very much. Either you could talk to each other or not.
Where the Internet completely changed was when we ran out of IPv4 addresses. There's room for a bit under 4 billion, but that assumes proper utilization; which doesn't happen. For a while I was employed by a subsidiary of GE so my desktop IP address started with 3.4..... but was entirely non-routable to the outside world. That's 16 million addresses, wasted. Combined with the world getting access to the Internet instead of bearded academics, we had an explosion of devices connected to the Internet.
In my household, I have two servers, five desktops and a laptop. There are three phones, five tablets and two music players. There are two TVs, two set-top boxes and one DVD player with Internet connections. Then there are three thermostats a Wifi-enabled light switch and probably by the end of the year we'll have a pair of smoke detectors and a webcam for doing time-lapses out of the back deck. Add to that my router and WiFi access point each have an IP address. That's a lot of addresses - and while we're somewhat tech-savvy and ahead of the curve, the reality is that most households with consumer electronics and teens are going to be using around a dozen or two addresses. Home automation (thermostats, smoke detectors, switches, timers) is going to explode because with Wifi or Bluetooth you no longer need to retrofit a house with low voltage wiring.
This is where Network Address Translation (or NAT) comes in. It's awesome, but really annoying.
There's a bunch of addresses that are defined in the RFC1918 spec as "non-routable". The one you're most familiar with is the 192.168.0.0/16 block, but there's 10.0.0.0/24 and 172.16.0.0/20. That's why in a lot of cases your home router gives you an IP address starting with 192.168.0 - millions of you can have that same address without conflicts. What happens is that NAT works on the router to make all of your traffic look like it's coming from the router. When there's only one of you behind it, that's not much; when there is more than one of you that's where the magic happens.
Let's say there's two computers connecting to the same server on port 3290. The router creates two connections using two local ports to the destination port on the server. It keeps track of which connection and port is for which computer in a small in-memory table and as it gets back packets from the server it sends them to the right machine on the non-routable address. It seemed like magic the first time I saw it; most people today just expect that's how the Internet is supposed to work. It's not - it's a giant hack.
So long as you're using TCP, life is good. Because the protocol is connection-oriented, it deals with state and disconnections well. The router's TCP/IP stack gets notified on disconnects and it can easily keep its little table updated. There's a limit, but most consumer grade routers can easily handle a dozen or two connections for a dozen or two machines without much trouble. No port forwarding or anything required.
NAT gives you some neat security advantages. Because those machines' addresses are "non-routable", you can't connect to them via the Internet. The only way those machines can talk to anyone is if they initiate
the connection. So long as you don't have malware on your computer, you get basic firewalling for free. Now there are cases where you want to run something behind a NAT gateway, and this is where port forwarding comes in - you can tell the gateway to forward all packets on port X to a given private IP address. But you only need port forwarding if you're running a server
, and even then it's a blunt instrument. You are limited to 1 IP address/port combination. (This is important later).
Where our tidy little world goes to you know where in a handbasket is when UDP crashes the party. Unlike TCP, UDP doesn't handle connections or state. It doesn't guarantee in order transmission. This tempts people a great deal when writing network software because UDP is technically a little faster than TCP because it doesn't have the same overhead and for voice, the guarantees TCP provides can be somewhat unhelpful.
Because there's no connection support, our poor little NAT router has to make a lot of guesses. When it sees a UDP packet come from an internal machine, it adds another entry to its little table so that when the response comes back from the server it knows who to send it back to. But since UDP has no concept of a "connection", our router has to make guesses. If a packet isn't sent from the internal machine in a while, it assumes the link is gone and drops the entry from the table. And if the entry isn't in the table, then when a packet comes from the server it gets discarded, because our router doesn't know which internal address to send it to.
This is why VVL stops working after a while if you don't transmit. If you don't transmit, your router doesn't see any packets from you, times out the forwarding rule and then you can't hear anything because the UDP packets aren't being forwarded.
(On a side note, UDP has another big problem with NAT that I'm not sure if VATSIM has ever run into - if your server has multiple IP addresses, you absolutely need to keep track server-side of what IP address the incoming packets came in on, and send the response back on the same address, otherwise the NAT router doesn't know who to send them to. TCP does this automatically for you; not so UDP.)
This is where people advise others to either increase their router timeouts or port forward 3290. Both are bad ideas, one worse than the other. The first one isn't terrible, but the point is that you shouldn't have to tweak NAT to make things work. It should work out of the box. Period.
The second is a bad idea because what happens when more than one person behind a NAT wants to use VVL? Port forwarding as we mentioned before is limited to 1 address/port combination, and the world where each user has their own IP address fundamentally breaks down with NAT - you can have dozens, maybe hundreds of people coming from behind a NAT gateway. (Read up on carrier-grade NAT.) It's no longer a 1 IP to 1 computer, or even 1 IP to one residence or site.
What's more disturbing is that the problem is so darn easy to fix. All VVL needs to do is send a ping every few seconds. A nice small UDP packet whose entire purpose is to remind any NAT gateways in between that "I'm still here". Compared to the bandwidth utilized by voice traffic, it's pretty trivial - and it's similar to TCP keepalives. (This, by the way, is why I tell anyone wanting to use UDP that unless they really know what they're doing - I've been doing this for over a decade and I don't qualify - all they will end up doing is reimplementing TCP. Badly.)
So port forwarding with UDP isn't a matter of stuck packets or blockages of any kind. It's actually due to an absence
of data, and an implementation that is woefully out of touch with how the Internet exists today.
I won't get into IPv6 support - each day hundreds of new users are added to the Internet that have no IPv4 connectivity or are going through NAT. If VATSIM cannot support IPv6 and NAT properly they are excluding far more users than the deaf or blind ones we seem to worry endlessly about at times.
... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts.
... Normal in my household makes you a member of a visible minority.