Breaking News

Talking IP: The challenge of NAT in IPv6 (2)

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.


Comments expressed here do not reflect the opinions of vanguard newspapers or any employee thereof.