Summary: IPNL

This paper explores an extension to NAT that restores long-lived globally
routable addresses to all hosts, among other things. It does this by adding
another layer in between IP and TCP that handles forwarding connections
between realms with independent IP addresses. FQDNs are used for global
routing and identification. The idea seems to be that connections begin with
an application opening a connection to another host by hostname. As the
packet proceeds through the network, lookups are performed in order to
determine the internal/external IPs (along with a realm number).

The use of FQDNs as IPs seems to imply that the user-level APIs will need to
be modified to use this system. Calls to connect() will need to be adjusted
to take FQDNs instead of IPs like they do now. The authors don't point this
out... so it is certainly possible that I am missing something. If
applications do in fact require source-code changes in order to use this
system, I'm not sure it is any easier to deploy than IPv6.

The emphasis that the authors placed on IP renumbering seemed to be a little
too high. It wasn't clear to me why renumbering should be nearly as bad as
they claim given the prevalence of DHCP. Even in situations where you need
to make a large number of address changes atomically, it seems that simply
setting the DHCP leases carefully so as to cause the flipover to happen
around a small window late at night should be enough.

The paper didn't seem to explicitly present an analysis of the latency that
their system adds for the normal (ie. non failed link) case. Maybe
the "netperf" results are enough to show that there is no latency effects,
but it would have been helpful if they explicitly pointed this out.

One of the key advantages to NAT (at least when it first came out) is that it
allows the user to have many hosts in my home network without having to pay
the ISP for each one. When broadband first came out, ISPs forbade any sort
of sharing of the network connection across multiple devices. I think the
main reason why they eventually gave up this clause in their ToS was that
they realized it was pretty unenforceable.

This solution would appear to require that ISPs maintain DNS entries for each
host. They would therefore be able to charge per device. Perhaps there will
be enough push-back to prevent this from happening since enough people have
used broadband to attach whole networks to the Internet rather than just
individual hosts. However, the fact that it makes it possible for ISPs to
charge per DNS entry could be a problem. (IPv6 sort of suffers from this as
well, although I think the minimum assignable address unit might be specified
to be much greater than one, which makes it harder for ISPs to justify
charging more for more machines).
Received on Thu Nov 30 2006 - 14:25:54 EST