Main
News
Proposal
Readings
Download
License
Donate
Feedback
Guestbook
If you know what NAT is, scroll down to the next section heading.
NAT, which means "network address translation", is a service typically provided by routers for networks that use "private" (or "intranet") IP addresses. The whole space of IPv4 addresses has proven to be too small for the whole mankind in the ancient age of early 1990-s. Nowadays, it's almost for sure that all computers at your home or in your office use so-called "private" addresses, such as 192.168.*.*, or 10.*.*.*, or the lesser-known block of 172.16.*.* — 172.31.*.*. All willing people are free and welcome to use these addresses in any network they run, but there's one thing about these addresses: they are not accessible from the Internet. They can't be, because they are not unique: if you pick something like 192.168.115.27 for your computer, nothing prevents other people from doing the same. If you're running Linux or other Unix-like O.S., you can easily determine what address your computer uses in the local network: just type /sbin/ifconfig at the command prompt and see. If you don't run a Unix-like O.S., the rest of this document is useless for you anyway.
In order to communicate with the Internet, your computer needs to be reachable at least for the packets someone sends you in response on what you sent. This is what NATs are for. The router which performs NAT for you is acting like this: when it handles a packet sent by your computer to the Internet, it replaces your IP address with its own IP address and sends the modified packet where it shall go; when a reply is received, the router replaces its own address (which is destination address this time) with the address of your computer, and sends the packet to your computer.
Everything (well, mostly) works fine when you only communicate with computers that have their own "routable" (or "real", or "globally-unique", whatever you name it) IP address. The problem is how to communicate directly with someone who's behind one's own NAT. Low traffic services like email may be routed through external servers, but when it comes to things like video, well, it is too expensive to run such a server. Here is where the NAT type becomes important.
From the very start: we don't even try to do anything regarding TCP and any other connection-oriented transports. What we use is UDP. In certain conditions, it is possible to establish bi-directional communication between two computers residing behind NATs.
The terminology related to NAT types tend to vary from one source to another. In this memo, we explain the terms used by the “natcheck” program.
From the very start it should be clearly stated that we don't use STUN, and we don't even look to watch TURN (which boils down to passing all the traffic through an external server, and it is impractical if you're not a large corporatin having unlimited supply of money). FEDAnet has it's completely own implementation of all the stuff, and this implementation has nothing to do with “standard” protocols.
Hereinafter, we use 10.*.*.* as examples of intranet (private) addresses, and we use the 198.51.100.0/24 in the role of "routable" addresses. The latter is a subnet assigned for examples by IANA.
Suppose your computer has the address 10.11.12.13, and when you contact something on the Internet, they see you as coming from the address 198.51.100.200.
Suppose, besides that, your operating system assigned you (your program) the UDP port number 54321. So, what your router has to do is to map the addr:port 10.11.12.13:54321 to an address/port pair reachable from the Internet.
In most cases, it will be the pair 198.51.100.200:54321, because good NAT implementations try to preserve the port number. However, this is not always possible: someone on the same network with you might use (occasionally) the same port number, so it is (here and now) not available: the NAT has to continue serving your neighbor using that number. So, if the ports don't match, it doesn't really mean anything; however, if they DO match, it is at least a good sign.
So, let's continue with our setting. Your computer uses the 10.11.12.13:54321 pair to try communicating with someone, and after the NAT is done, it becomes 198.51.100.200:54321 (or may be with some other port number, it doesn't really matter). Whenever your communication partner ("peer") sends you a datagram, it uses 198.51.100.200:54321 as the destination address, and your NAT box turns it into 10.11.12.13:54321 so the datagram finally reaches your computer and the program which it runs. If you don't send/receive datagrams for a significant amount of time (which may vary from some seconds to some hours), the NAT box simply forgets the mapping, so it may be a good idea to send senseless datagrams back and forth just not to let the NAT decide we stopped to communicate; this is called "keepalive packets".
The real question is what happens if SOMEONE ELSE, not your communication partner, but someone completely unknown to your NAT, sends a datagram to the 198.51.100.200:54321.
Unfortunately, a lot of people around consider NAT as a safety/security measure (which is simply a wrong concept). Such a consideration may (and usually do) affect NAT implementations so that they reject datagrams from unknown source. This may provide some (false) sense of safety, but it obviously reduces our capabilities.
Anyway, sometimes you can find yourself in a network using a NAT implementation without this (stupid and harmful) restriction. This means that, once you sent a single datagram from your local address/port pair, the NAT reserves for you a port from its own space (with the same with a different number, no matter), and as long as the reservation remains active, anyone on the internet can reach you at that addr/port; the only thing they need is to know the actual addr/port pair. That's what "Full cone NAT" effectively is.
If this is the case for your home network, it means you're lucky: you can run a FEDAnet node at home, providing point access for your frends, and you don't need to pay for any additional services to do so.
Chances are you're not so lucky: you happily communicate with a single peer, but all datagrams anyone else sends you don't arrive: they are cowardly dropped by your NAT. The next thing to determine is what happens when YOU send a datagram (using the same socket and thus same addr/port pair) to someone else than your initial peer.
Let's recall we're using 10.11.12.13:54321 locally, and our initial peer sees us as using 198.51.100.200:54321 (or may be something like 198.51.100.200:43845, it doesn't really matter). For the sake of clarity, suppose our peer lives at 198.51.100.101:5555. Now we send a datagram (from the same socket) to, e.g., 198.51.100.27:27777. The question is, does the new peer see us as coming from the same address/port? That is, in our example, from 198.51.100.200:54321, or from 198.51.100.200:43845, but the same addr/port pair the first peer sees.
Actually, this means everyone who we try to communicate with, would see us as using the same addr/port pair. This is not as good as the abovementioned full cone NAT, but it's not as bad as it could be. At least it is still POSSIBLE to establish a bi-directional datagram exchange with someone who uses the same type of NAT: we need an external server (rendez-vous server) to do so, but it only has to relay one or two small datagrams, and after that, all traffic will go directly. What the rendez-vous server does is to tell both us and our partner something like "please contact this address/port pair". Once we both did so, we're in an established direct communication.
This type of NAT is called "Restricted cone NAT". Well... this is not sufficient to run a first-class FEDAnet node right at home, but this works perfectly if you're going to run a point or such a node that doesn't provide any service to other people, that is, all active "points" belong to you as the node master. To launch a first-class node however, you'll need to obtain a place to run the so called fedaproxy service. If one of your friends runs a server, like a VPS, on a "real" IP address, all you need is his/her permission to run a simple program that won't do much stress on the machine, and two UDP ports, at least one of them permanently reserved for you. Please note each computer on the Internet has 65534 UDP ports available, so having two of them should not be a big deal. No root access is needed, the fedaproxy is able to run from a totally unprivileged account. Certainly you can buy the VPS service yourself, and then you can even invite other wanna-be nodemasters to have some of your ports.
Okay, so you tried to contact two different parties, e.g., 198.51.100.101:5555 and 198.51.100.27:27777, using the same socket which locally has the 10.11.12.13:54321 address/port pair. And — oh no! — our peers report they see us as going from completely different addr/port pairs, e.g., 198.51.100.200:7263 and 198.51.100.200:48605. Even the IP address might change, not only the port number.
This (fascist) type of NAT implementation is called "symmetric NAT". No, you can't run even a single-user node with this kind of connectivity, and for a point, it is not very good too, as you'll have to use your node's service to send and receive all your traffic. However, this — running a point that completely relies upon the service provided by your nodemaster — is still possible. Remember however that you can only contact those who either has no NAT at all (that is, they're lucky enough to have a globally-visible IP address), or their NAT type is the full cone one.
Why you can't run a node, even a single-user one, is beause you'll have nobody to rely upon in this case.
There's a good news: this type of NAT is dying out.
The low quality of your NAT may be (and often happen to be) a result of settings on your own equipment. Android-based smartphones, being used in a hotspot mode, have to run their own NAT, but fortunately they aren't known to spoil anything here, so you may be nearly sure all limitations are imposed by your carrier (the cellular network operator). Not much can be done here.
However, SOHO routers (those small boxes popular nowadays, usually
with a WiFi antenna and some twisted pair ports) are known to be easily set
up for simple operations, but tricky to achieve anything unusual.
For a reason completely unknown, their
Most of the routers let the user do a thing they usually call port
forwarding; you can forward an "external" UDP port, e.g.
45555, to your computer's port with the same number, and then
try running natcheck with an option like -b
45555. Sometimes this improves the situation. Remember, your
goal is to gain a UDP port reachable from the Internet, and it doesn't
matter in which particular manner you achive it.