Subject: RE: (ngtrans) W.G. Last Call on "Shipworm: Tunneling IPv6 over UDP through NATs"

From: "Christian Huitema" <[email-masked]>
Date: Thu, 4 Oct 2001 11:04:40 -0700

> Shipworm is not good enough IMO if we are satisfied with 
> assuming it can
> only provide a couple hours' worth of address stability.  A 
> few days would
> feel like an absolute minimum for me.

As you said, this really depends of the local set up. If the network
remains stable, there is no reason that the shipworm address cannot be
kept for days; indeed, this is exactly what will happen if you have an
always on connection, e.g. a DSL connection; if the underlying network
is stable enough to let you conduct long duration FTP transfers, then
the shipworm address will definitely remain valid for the duration of
the transfer. On the other hand, if the network connection is through a
dial-up modem, then the local NAT is likely to get a different IPv4
address for each dial-up session. In that respect, there is not a lot of
difference between Shipworm and 6to4: the stability of the v6 address
depends on the stability of the underlying v4 set-up.

Keith and I disagree on the usefulness of transient addresses. In
Keith's opinion, they are hardly better than a NAT address; I disagree.
First, even a transient address at least allows the Shipworm node to
behave as an IPv6 client, use IPv6 servers, possibly use IPSEC end to
end; you cannot do either IPv6 or IPSEC through a NAT today. Then, there
is a whole raft of applications that require establishing relatively
short connections and that already have means of exchanging addresses:
VoIP using SIP proxies, application sharing such as Net Meeting,
videogames using game lobbies, p2p applications such as gnutella or
fasttrack, file transfer extension to instant messaging systems, and
probably many more; all these applications tend to fail in the presence
of NAT today, and the application designers have to resort to all kinds
of weird relays.

NATs do pollute the lanscape. To un-pollute it, we can make two
different trade-offs: permanent address, or low cost deployment. Low
cost deployment pretty much implies that you derive algorithmically the
IPv6 address from the underlying IPv4 set up. To obtain a permanent
address, you need essentially to route all your traffic through a stable
point in the network; this is pretty much what mobile IP does when
routing traffic through a home agent; you have to solve the same
security and configuration issues as between a mobile IP node and its
home agent. Shipworm engineers the "low cost deployment" alternative; I
have not heard that it is not technically sound for that purpose. There
probably is space for a "permanent address" alternative; it is probably
a fine work item for NGTRANS, just not the same work item as Shipworm.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Oct 2001 15:09:07 -0400

> > assuming it can only provide a couple hours' worth of address stability.  
> > A few days would feel like an absolute minimum for me.
> 

many (though by no means all) of the failures caused by NAT are caused 
to the lack of a stable address for the application components behind 
the NAT.  
 
> end; you cannot do either IPv6 or IPSEC through a NAT today. 

That's true.  However, much of the market for IPv6, and the reason for
users and networks to add IPv6 support, will be to support applications
that cannot be supported in a NATted v4 environment.  In other words,
I don't see much demand in the near term for IPv6 access to support
applications that could as easily be supported with NATted v4.

(of course IPSEC can be supported inside of any IP-over-IP tunnel, 
even over a NAT, so shipworm is not alone in being able to do this)

> Then, there

I disagree with your characterization of some of these as requiring 
relatively short connections - for instance instant messaging systems
and gnutella are often run for days at a time, or even indefinitely. 

I also disagree with the desirability of providing an IPv6 solution
that only works for relatively short connections.  

> different trade-offs: permanent address, or low cost deployment. 

I don't think these have to be mutually exclusive - why can't the
same tunneling protocol support both?   

Seems like what we need is not yet another limited-applicability
solution - but a general, one-size-fits-all IPv6-over-IPv4 tunneling
protocol that can be shipped and installed with an application and 
that will work in any IPv4 environment.  I'm not saying that it
has to provide stable addresses with no external forwarder, but I
do think that the protocol needs to be able to provide stable addresses
if a site or an ISP is willing to provide such a forwarder, without
having to upgrade each end-host to support yet another pseudo-interface.

> There probably is space for a "permanent address" alternative; it is 
> probably a fine work item for NGTRANS, just not the same work item 
> as Shipworm.

The divide-and-conquer approach is starting to look like one of Zeno's
paradoxes - it seems that we can never solve the IPv6 deployment problem 
because we keep dividing it in half.  but unlike Zeno's paradoxes,
each of our sub-problems takes almost as much time to solve as the whole
problem, so by dividing each problem in half we actually take longer.

Keith