feda/doc/nat_types.txt

                                                   Andrey Vikt. Stolyarov


                       WHAT ARE THESE NAT TYPES?



  0.  What is NAT, first of all?


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.




  1.  Scope and limitations of this memo


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




  2.  Port number preservation


Suppose your computer has the address 10.11.12.13, and when you contact
something in 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
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.




  3.  Full cone NAT


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 initial
communication partner, but someone completely unknown to your NAT, sends a
datagram to the 198.51.100.200:54321 destination.

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




  4.  Restricted cone NAT


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 run 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, either permanently reserved for you, or even
new each time the program is launched.  Please note each computer on the
Internet has 65534 UDP ports available, so having two of them should not be
a big deal.  Certainly you can buy the VPS service yourself, and then you
can even invite other wanna-be nodemasters to have some of your ports.




  5.  Symmetric NAT


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.