IPNL: A NAT-Extended Internet Architecture

Paper Review: IPNL: A NAT-Extended Internet Architecture

The paper presents IP Next Layer (IPNL), a NAT-extended Internet
protocol architecture designed specifically to solve the address
depletion problem. Their scheme requires modification to hosts and
NAT boxes, but not to routers and support protocols. NATs have caused
the loss of end-to-end addressability. In client-server applications
they have no adverse affects as long as the server is not behind a
NAT. P2P applications, however, have been significantly affected by
NATs. NATs provide address isolation on the Internet, which has
several advantages. Little work has been done on NATs since the IETF
chose to ignore them thinking that IPV6 would take off.

Although the paper is admittedly late in designing a new Internet
layer protocol, they attempt to answer three questions: Can a
NAT-extended protocol achieve the original characteristics of IPv4?
Can the router scaling problem be solved while maintaining addressing
independence? Is a NAT-extended approach less expensive then a full
protocol replacement?

In IPNL the IP address space is extended such that the unique IP
address forms the high order part of the IPNL address while the
private IP address forms the low order part. Site addressing is
completely isolated from global addressing. The globally addressable
part of the Internet is known as the middle realm and the privately
addressable parts are known as private realms. Addresses in a realm
have no meaning outside of that realm and are therefore not included
in the IP headers.

For routing, every realm is associated with one or more DNS zones
which is necessary for the FQDNs to be routable. The zone routing
information is established using dynamic routing algorithms.

A noted benefit of their architecture is site address isolation. The
paper states that there are no ?renumbering? events where addresses of
all of a site?s hosts must be simultaneously updated when ever the
site?s prefix changes. The site isolation is provided by a
combination of intra-site headers, independent realm number
assignments, in-flight address resolution and a 2-bit Loc field in the
global header.

A level of robustness is provided by their scheme through the use of
several mechanisms. Robustness in IPv4 is provided by stateless
routers, dynamic router, neighbour pinging and decoupled name
resolution and routing. The same mechanisms are used in IPNL with the
exception of neighbour pinging. To overcome this flaw, they propose
two mechanisms: in-band trace and additional path discovery. For
in-band trace, it is necessary that the receiver host send a packet
back to the transmitter for the scheme to work.

The paper discusses an interesting design principle in Internet
architecture. The question is whether or not to overload addresses to
use them as identifiers. The benefit of this scheme is the added
security. Routing to an identity is guaranteed since it is dependent
on the location. The disadvantage, though, is the coupling of
identities to locations removes flexibility. In their scheme, they
use the FQDN, the IPNL address and random per connection ID (RID).

To test the feasibility of their system, they implemented the n-l
router functionality in Click and the host functionality in the Linux
TCP/IP stack. In their tests, they observed that IPNL caused no
degradation in achievable throughput. Furthermore, the latency in
updates for route failures was observed to be acceptable.

One interesting feature of their scheme is that there seems to be a
level of mobility provided through the FQDNs. This adds flexibility
in the system and could be utilized in many possible ways such as
multi-homing. The stated goal of this project was to become a
research project used to investigate mechanisms which can be adopted
in IPv6. Thus it does not make sense to discuss deployment and other
similar issues. The paper does a good job of addressing NATs, which
violate basic accessibility issues in Internet routing. However, I
feel for two reasons that NATs are not a major topic of research
interest. Firstly, we are pushing towards IPv6 and if we eventually
get there, NATs will not be a real issue. Even without IPv6,
applications seem to be bypassing some of the problems caused by NATs.
  Peer-to-peer applications, which are the most affected by NATs, have
yet to be crippled by NATs. Thus, the paper is interesting from a
design point of view, but perhaps is not solving a very important
research problem.

-- Nadeem Abji
Received on Thu Nov 30 2006 - 11:25:06 EST