NAT is so well-integrated into the structure of today’s internet that it cannot be omitted even now with IPv6, despite being a temporary solution initially. In this NAT series of posts, I would talk about NAT, its problems and the various solutions and techniques which have been developed pertaining to NAT.
In this post, I would introduce NAT and its problems specifically its disagreeability with UDP and P2P protocols.
Network Address Translation (NAT) came into picture in 90s with the unprecedented increase in the number of required IP addresses which couldn’t be matched with the available ones of IPv4. Using NAT, an entirely private network can be connected to internet via a gateway which would make an entry whenever a system (in the private network) initiates a connection. This entry would help in rerouting the server response back to the intended node. This technique of IP masquerading thus, would conserve global IP addresses by allowing reuse of private ones. One of the basic principle of computer science – reusability – at use.
But what should also be noted is that in this whole process it also ends up breaking the end-to-end connectivity principal of the Internet. And there are a lot of other problems associated with it.
NAT requires the connection to be started from the internal network. So that the mapping entry in the NAT table could be made. In case, an external node tries to connect, NAT gateway wouldn’t know to which internal host is the connection meant for. This implies that server cannot be hosted on the internal network as there would be no way for an interested external host to reach it. (‘NO WAY’ in the pure form of NAT. There are workarounds, of course.)
Not just hosting server, but it is also problematic for clients using certain protocols. For example, FTP. When the server connects back to the client for transferring file on a different port number , even then it will cause a failure. (For those unfamiliar with FTP mechanism, client connects with the FTP server on port 21 and then a data channel is established by the server on port 20).
Another problem which we encounter with NAT is sending data on top of UDP. Before I begin with relationship between NAT and UDP, it is important to understand a few things about TCP and UDP. In UDP each and every packet is complete in itself; it is not at all associated with packets before or after it. This is unlike TCP. In case of TCP, packets are like a stream with each packet numbered serially; a flow of numbers. (For this reason, TCP is referred to as (data) stream-oriented where as UDP is packet-oriented.) This means that for UDP, there is no need for explicit connection, as such. No connection set-up!
TCP, the more reliable transport protocol has a three-way handshake mechanism with SYN flag indicating initiation of a conversation and FYN flag announcing the end. NAT gateway with the help of SYN and FYN understands the state of conversation and knows when to make an entry and when to delete. This is not the case with UDP. UDP doesn’t need any no specific connection set up phase. Hence, there is no obvious criteria for NAT gateway to realize the connection start and connection end. It is difficult to work UDP and NAT together. (But again there are workarounds.)
Third point of failure are the peer-to-peer protocol. In case when two peers are behind two different NAT gateways, it is impossible to establish a connection. Suppose NAT A host, lets call it HA makes the first move. It will pass through its network gateway, move through external network and reach the NAT B gateway. At this point, the packet would be dropped. NAT B wouldn’t recognize it as there is no corresponding entry for the source IP: source Port. Similarly connection set up would fail for HB as well. Hence, it is “impossible”.
For those interested in knowing NAT problems in more detail and for drawing further patterns among them, refer to RFC 3027.