NAT - Network Address Translation is a work around for the IPv4 shortage, allowing several devices to share an IP public address. Allowing several hosts to form a private internal network, using IPs from a special range. One device, the NAT, forwards packets between this private network and the public internet (though in principle could be another NAT network). It rewrites addresses, and port numbers in this forwarding, hiding the whole private network behind it.
Connection
In this case, instead of using the IP addresses that the ISP provides, the private network uses IP addresses from one of the private IP address ranges, in this case:
192.168.0.0-192.168.255.255
Again with the NAT/Router’s internal address being the first available address of that range , and the external being part of the standard ISP network
NAT performs address translation on packets traversing it:
- Change source IP address in packet header to match external address of NAT
- Change source TCP/UDP port in packet header to some unused value
- Records the mapping, so the reverse changes can be made to any incoming replies as they traverse the NAT in the reverse direction
For the server, the packet appears to come from the NAT, and will send the reply to the NAT, the NAT will then look at the source of the reply, and looks at the table of rewrites, to see how to reverse the rewrite, before forwarding onto the private network
Private IP Networks
There are 3 private IP ranges:
- 10.0.0.0/8 (i.e.
10.0.0.0 - 10.255.255.255) - 176.16.0.0/12
- 192.168.0.0/16 ( This is super popular for home networks)
Issues with NAT
- NATs encourage Centralization
- Servers behind NATs fail, → They need explicit port forwarding This is because NATs work off a translation table, so if they haven’t seen an outgoing packet from the server they can’t interpret where the client’s message is going. It’s usually easier to just pay a large company to host something on “the cloud”
- Peer to Peer fails. Complex NAT traversal algorithms are needed, as devices don’t know their public address
Why use NATs at all?
- IPv4 Shortage
- Translate between IPv4 & IPv6:
ISP network runs IPv6 only, so customers have public IPv6 addresses
Translate IPv4 → IPv6 as we pass through NAT
- If a message is bound for a IPv4 host, translate back to IPv4 on the way out of the ISP network
- Otherwise forward directly for IPv6 - Avoid IP re-numbering Despite it being a bad idea, people hard code IP addresses of services instead of DNS names, which means it breaks every time the IPs change, such as a company being bought.
NAT Timeouts:
TCP:
Typically for the translation states, NATs will listen for the SYN->SYN-ACK->ACK and FIN->FIN-ACK->ACK messages to know when to delete old translation data.
They also implement timeouts in case message ends or something else are lost. This is suggested to be 2 hours but most applications have it much closer to the order of 15 mins
UDP:
There is not explicit connection or open or close of connection, which means it relies completely on timeout, but since DNS is the largest application for UDP, and that sends many small requests, it beings that you need to send some form of stay alive message every 15 seconds. The lack of connection establishment means its more permissive for incoming packets, meaning anywhere can send to an open port, which makes it much more simple for P2P traffic.
NAT Traversal
NAT and dual stack operation complicates connection establishment; encourages centralization onto cloud services
NAT traversal → binding discovery, exchange, probing
- STUN, TURN, and the ICE algorithm
- Requires a server with public IP address for binding discovery; centralized point of control
- Complex, slow, unreliable, wastes power, generates unnecessary traffic
Dual stack → connection racing • Some paths support IPv4, some IPv6; probing and connection timeouts slow for client-server applications • Race connections by probing in parallel: hard to implement, wastes resources
P2P Traversal Concepts
NATs don’t know how to translate incoming packets meaning using standard P2P fails, however:
P2P connections can succeed if both NATs think a client-server connection is being opened, and therefore the response is coming from the server.
The following figure shows two hosts trying to connect a P2P connection from 2 private networks
If they are both home networks, they are most likely on the 192.168.0.0 range of IP addresses, but this is typically fine as they are private IPs, and could even be identical, so it can’t send with this.
This means they must use their public IPs, but how? They aren’t able to access this typically?
*NAT Binding Discovery
The solution is for both hosts to send a message to a server on the public internet, which will be able to see their public IP, and therefore return this information to the hosts. Both hosts will then exchange addresses on that public server and then proceed to probe connectivity, by trying to establish a connection using every possible combination, and then check if the NAT translation tables have been created and messages have been received/returned. If this succeeds, they can switch to direct P2P communication, otherwise they may have to use the referral server
The STUN Protocol (Session Traversal Utilities for NAT), is a standard discovery mechanism