By Segun Sorunke
Sorunke, addressing the topic here in the first instalment published last week ended by listing certain drawbacks on the use of NAT. He continues the discourse:
Because NAT stores dynamic address translation state within the unit, NATs do introduce a single point of failure for its set of associated clients. More fundamentally, NAT breaks the end-to-end transparency architecture of the Internet, and this can cause NATs to provide a very restricted view of the Internet. address into a very large number of private addresses, so a large number of computers can share that single public address.
The immediate benefit of NAT is that it allows a single internet connection with a single IP address to be shared. However, thereâ€™s a hidden cost: NAT breaks protocols that require incoming connections and protocols that carry IP addresses in them.
An example of this is VoIP: a VoIP application on a computer (a â€œsoftphoneâ€) or VoIP phone registers with a SIP server, and then the SIP server tells the application or phone when thereâ€™s an incoming call. The packets that carry the actual conversation are then exchanged directly between the calling parties with no involvement from the server. But in order to connect, the server must be able to tell each end where to send the VoIP packets. This must be a real, public address, and not the private address the VoIP application thinks it has. And each end must be able to receive those incoming packets, which donâ€™t match a prior outgoing session in the NAT.
There are of course ways to make this work, but they require the NAT to be aware of the applications and/or the applications to be aware of the NAT. NAT devices usually have â€œapplication layer gatewaysâ€ (ALGs) for popular protocols that donâ€™t normally work through NAT.
For instance, a SIP ALG will monitor the traffic between the VoIP application and the SIP server, rewrite the private addresses that it sees there into the NATâ€™s public address, and make sure the incoming packets from the remote VoIP application are delivered correctly.
Alternatively, the application can use protocols such as the uPnP Internet Gateway protocol or the NAT Port Mapping Protocol (NAT-PMP) to contact the NAT device to obtain the public address and ask the NAT to forward certain incoming packets.
One of the promises of IPv6 is that the almost infinite number of addresses and the better (but not perfect) renumbering makes NAT unnecessary so it will once again be possible to deploy new applications without cumbersome workarounds or random failures that the widespread use of NAT imposes in todayâ€™s IPv4.
The Internet Engineering Task Force (IETF) has traditionally been highly critical of NAT, but despite that, it developed a technique called Network Address Translation – Protocol Translation (NAT-PT, RFC 2766) as a means for hosts that run IPv6 to communicate with hosts that run IPv4. So far, the usual way to deploy IPv6 has been to run IPv4 and IPv6 side-by-side.
In addition to the list of practical issues, there is also the more fundamental question: do we want the IPv6 internet to inherit the same restrictions that are present in todayâ€™s IPv4 internet? IPv6 was developed before NAT was in general use, and so far, the assumption has always been that NAT in IPv6 is unnecessary and undesirable. But the use of NAT-PT would pretty much import the IPv4 NAT issues into the IPv6 world. On the other hand, some people argue that the lack of NAT makes it harder to transition to IPv6 because NAT is an integral part of the way that networks are deployed. Taking away this tool would make network operators less willing to deploy the new protocol.
However, this could just be â€œIPv4 thinkingâ€. For better or worse, IPv6 is different from IPv4, both as a natural result of the longer addresses and because the IETF used the opportunity to redesign IP to make some improvements unrelated to the address length.
Unless ISPs decide to give IPv6 users only a single address like with IPv4, there wonâ€™t be any need to use NAT for the majority of all consumers. This implies that itâ€™s not a given that the ALGs and other workarounds that make NAT tolerable will be available in IPv6, even if some enterprise users want to stick to NAT when moving to IPv6.