IPNL Review

NATs are viewed by many as a dirty hack to solve the temporary
shortage of IPv4 addresses until the world is ready to transition to
IPv6. However, NATs are not without their benefits and they have
become a common part of the Internet architecture that is likely to
serve us for a long time to come, especially considering the delays in
deploying IPv6. This paper proposes an extension to NATs which would
allow us keep their benefits while removing the disadvantages.

NATs are desirable because they expand the IPv4 space and isolate the
internal and external network address spaces, but they interfere with
external addressability of hosts and complicate the development of new
applications. The proposed solution uses two addresses: the static
FQDN (each host is given a DNS name) and the IPNL which is more
dynamic. IPNL is basically one more layer between IP and UDP/TCP, and
because it layers on top of IP, IPNL can reuse much of the existing
network architecture such as BGP. IPNL addresses are 10 bytes long
consisting of a "regular" IP, a "Realm Number", and an end host IP.
When a host initiates a connection, it only knows its own end host IP
and the FQDNs of itself and the remote host. The client can learn the
remote host's middle realm IP through a DNS lookup but it relies on
dynamic rewriting of the other portions of the address as the packet
makes its way to its destination. The required changes are
implemented in NAT hardware and end-hosts.

The paper explains how this system preserves the desirable properties
of IPv4s and NATs such as site address isolation and robustness. The
issue of "overloaded addressing" comes up because this system
separates routing from identification and this allows for connection
hijacking and packet spoofing.

Overall, I think this is a neat idea and I agree with their insight
into the desirability and longevity of NATs. However, the feasibility
of deploying their solution is limited by the amount of change
required to adapt each host to a new kind of addressing. The authors
seem to realize the shortcomings of their proposal and at the end
suggest that it may be better if portions of the system are integrated
into IPv6.
Received on Thu Nov 30 2006 - 11:13:53 EST