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

From: [email-masked]
Date: Sat, 29 Sep 2001 16:08:36 +0300

Dear list,

Sorry to ask at the last call phase, but have you compared Shipworm with
other IPoverUDP proposals? I know of at least two: IPSec
(draft-ietf-ipsec-udp-encaps-00.txt) and Mobile IP
(draft-levkowetz-mobileip-nat-tunnel-00.txt). At least their hints about IPR
should be checked.

BTW, by tea leaves tell me that also WAP people would be interested in a
generic IPoverUDP RFC...

-- Lassi

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Oct 2001 11:35:10 -0400

and then there was 6overNAT: draft-moore-6overnat-00.txt

I really think it's inappropriate to consider just shipworm when there
were other proposals in the same space.  OTOH, if shipworm works just
as well as the others, I don't care too much which one we pick.

I'm still trying to find time to evaluate shipworm but one thing
that bugs me is the idea that shipworm doesn't supply you with
a stable IPv6 prefix.  it seems to me that unless IPv6 prefixes
are reasonably stable and can be used as reliable endpoint identifers
by p2p apps, we haven't provided much value added over IPv4 with NAT.

> (draft-levkowetz-mobileip-nat-tunnel-00.txt).

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Oct 2001 02:09:29 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    Keith> I'm still trying to find time to evaluate shipworm but one thing
    Keith> that bugs me is the idea that shipworm doesn't supply you with
    Keith> a stable IPv6 prefix.  it seems to me that unless IPv6 prefixes
    Keith> are reasonably stable and can be used as reliable endpoint identifers
    Keith> by p2p apps, we haven't provided much value added over IPv4 with NAT.

  For "stable" machines, I agree --- shipworm isn't too hot. It doesn't get
around various "always on" providers that have forced NAT on their customers.

  For being able to do IPv6 from a hotel ADSL, I think it is great.

  I'd actually rather see shipworm rather than draft-ietf-ipsec-udp-encaps-00.txt
go forward. Run IPv4/IPsec/IPv6/UDP/v4 rather with some very nice migration
paths rather than the horrible kludges which ipsec-udp-encaps seems to
require because they insist on running on the IKE port.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Oct 2001 09:26:30 +0300 (EEST)

>   For being able to do IPv6 from a hotel ADSL, I think it is great.

Why do you think shipworm won't get around various "always on" providers 
that have forced NAT?  This remains to be seen when there are 
implementations, of course.

At least in the specification, I can see nothing that would prevent the
prefix from staying alive for at least days, assuming your Shipworm Client
is a server/router that's always on.

Personally, I think a huge potential gain of shipworm is ISP's that have
forced NAT due to the lack of proper public addresses.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Oct 2001 04:21:34 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:
    >> For being able to do IPv6 from a hotel ADSL, I think it is great.

    Pekka> Why do you think shipworm won't get around various "always on" providers 
    Pekka> that have forced NAT?  This remains to be seen when there are 
    Pekka> implementations, of course.

  Alone, it doesn't give me an address that I'm willing to put into DNS
with a reasonable TTL. E.g. www.example.com. I'm with Keith here.

  But, I think it is *extremely* useful to have.

  With MobileIP or IPsec extruded subnets, yes you can have everything.

  (I actually implemented something very similar last Winter, and I think
that Keith implemented something too)

    Pekka> Personally, I think a huge potential gain of shipworm is ISP's that have
    Pekka> forced NAT due to the lack of proper public addresses.

  I know a number of telco-always-on ISPs that have forced NAT onto their
customers because it keeps them from running servers of any kind. The cost
savings due to allocation space was not important from what I can tell.

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 Oct 2001 19:46:16 -0400

>     Pekka> Why do you think shipworm won't get around various "always on"
>     Pekka> providers that have forced NAT?  This remains to be seen when 
>     Pekka> there are implementations, of course.
> 
> with a reasonable TTL. E.g. www.example.com. 

personally, I don't consider "good enough to put in DNS with a reasonable TTL"
a very useful criterion for address stability - because there are numerous
applications that use IP addresses rather than DNS names as endpoint 
identifiers.  and they have good reasons for doing so - for short- to
medium-term associations (say anything less than several weeks), IP 
addresses are faster, more stable, and more reliable identifiers 
in practice than DNS names.

I don't know where people got the idea that stability of DNS names is 
the only thing that is important, but it's simply incorrect.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Oct 2001 21:15:19 -0400

>> with a reasonable TTL. E.g. www.example.com. 

    Keith> personally, I don't consider "good enough to put in DNS with a reasonable TTL"
    Keith> a very useful criterion for address stability - because there are numerous
    Keith> applications that use IP addresses rather than DNS names as
    Keith> endpoint 

  Keith, I think you are violently agreeing with me.

  For applications that are happy with IP addresses and can rendezvous
somewhere to get it, I find shipworm to be pretty much ideal. 
  (Dynamic DNS with low TTLs counts as "rendezvous"!!)

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Oct 2001 09:42:17 -0400

>   Keith, I think you are violently agreeing with me.

I wasn't intending to violently disagree - just to point something out.
However, based on your next statement I'm not sure we're even on the same
page.
 
> (Dynamic DNS with low TTLs counts as "rendezvous"!!)

this is precisely what I'm saying won't work.  many applications need 
IP addresses that are stable for the entire running time of the 
application - which could be days or even weeks.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 16:52:36 +0300 (EEST)

> application - which could be days or even weeks.

I'm not sure if there are actually that many of those applications.  If 
there are some obvious ones I've missed, could you name a few?

Sure, endpoints of a TCP connection must not change.  But in my eyes,
Shipworm is heavily geared towards users that just want to escape from a
NAT trap.  Quite often they don't care _that much_ about connections
staying alive for a week (e.g. SSH session).

Address lifetime of a week is very much ok for email, web surfing, voip,
online gaming, etc.etc.

"Power users" that do care about this often try to avoid NATs altogether
(and often can, by paying ISP extra cash), or maybe use other methods like
MIPv6 to achieve the stability.

So IMO if we could assume the address would in average remain stable for
at least a week, that would probably be sufficient in at least >95% needs.

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Oct 2001 10:55:51 -0400

> there are some obvious ones I've missed, could you name a few?

the ones with which I'm most familiar are distributed computing applications 
such as PVM, MPI, Globus, NetSolve, and peer to peer applications like 
Gnutella.  but there are others.

of course one reason why there aren't (apparently) "that many" of these 
applications might be because a NATted net is hostile to them.

> Sure, endpoints of a TCP connection must not change. 

sure, but why do people assume that addresses only need to remain stable 
during a TCP connection?  it's not as if the only state in the endpoints 
that contains (or should contain) the addresses is within the kernels' 
TCP tables. that's a rather arbitrary constraint.  nor is it reasonable
to expect hosts to have stable DNS names, nor to expect applications to 
be able to detect and recover from address changes.

> NAT trap.  

absolutely.  but it doesn't do terribly much good if they escape from that
trap to find themselves in an only slightly less constraining trap.

> Quite often they don't care _that much_ about connections

quite often they don't know anything at all about connections, but they 
care about whether their applications work.  when the applications fail,
they don't know what is the problem.  and when new applications cannot be
deployed because of these limitations, the users may never notice - but
they still lose.

> Address lifetime of a week is very much ok for email, web surfing, voip,

not clear even for all of the above.  for instance, a single online game 
could last for weeks even though no individual participant remains
online for that long. and even a small percentage of voip calls being 
dropped due to address changes might not be seen as acceptable service -
particularly if the failures were periodic such that they were consistently 
affecting some group of users.

> MIPv6 to achieve the stability.

I think the distinction between "users" and "power users" is misleading.
Users don't have to be wealthy or sophisticated in order to want (and 
expect) to run long-running applications.

> at least a week, that would probably be sufficient in at least >95% needs.

seems like many ISPs change addresses every day or so.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Oct 2001 12:24:43 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    Keith> this is precisely what I'm saying won't work.  many applications need 
    Keith> IP addresses that are stable for the entire running time of the 
    Keith> application - which could be days or even weeks.

  I guess we do disagree about length of time for "stable"

  I agree that shipworm is unlikely to get one an address stable for
weeks. While there is no theorectical reason why the NAT mapping would not
stay there, I would not wish to rely on it. ISPs with NATs often have them to 
keep people from running long standing applications.

  If I can get an address stable for 10s of days, then I'd be happy to put it 
into DNS. You seem to define this as a medium length of time. 

  I'm measuring time wrt time spent behind the NAT. If I know that I'm going
to be there for that period of time and I have an application that needs a
stable address for that period of time (and that can't deal with failing
over. Gnutella can do that, btw), then I have motivation to set something
more stable up (some other tunnel perhaps) or switch ISPs.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 20:49:50 +0300 (EEST)

> applications might be because a NATted net is hostile to them.

You imply that these would be used in a server-push -only mode.  Why 
couldn't they be designed so that the user shows some sign of life now and 
then, and then the other end would would know where to connect this week.

Sure, one should be able to design "pathological" systems, but 
unfortunately the world is not a perfect place.
 
> deployed because of these limitations, the users may never notice - but

IMO, we should not lose the perspective:

1) If ISP doesn't give the user native IPv6 connectivity, the user loses.
2) If ISP doesn't give the user a static public IPv4 address, the user 
loses.
3) If ISP doesn't give the user a dynamic public IPv4 address, the user 
loses.
4) If ISP performs NAT, but doesn't co-locate IPv6-router (e.g. 6to4) with 
it, providing IPv6 connectivity, the user loses.
5) If ISP performs NAT, but doesn't create a tunnel broker service with 
private IPv4 addresses, enabling IPv6 connectivity, the user loses.

If all of these and possibly other mechanisms fail, we go for Shipworm 
(or under certain scenarios, perhaps even with 4-5).

Please note that this issue is pretty much identical with dynamic IPv4
addresses and 6to4, which was one of 6to4's "target platforms" I think.

The user has already "lost" IMO both hands and feet.  He's in a very bad
shape already, barraged by the unfriendly/uncaring ISP.  One would think
the user would be glad to get _at least something_, which would work until
the competition etc. drives the ISP out of the business or the user can
manage something better.

Trying to achieve the perfection may lead into achieving nothing.

> affecting some group of users.

Online game -- only applies if the client is running the online game 
server, or if the game authenticates the gamers based on IP address or the 
like.

voip call -- the problem is generic; IPv6 routers get rebooted too.

etc.  most issues are not necessarily that huge, but of course, in a 
perfect world they should not exist.

> seems like many ISPs change addresses every day or so.

This is an issue that would need to investigated.

I've came across ISP's that perform 1:1 mappings between private addresses 
and public addresses, and shuffle public addresses like daily.  I'm not 
sure if this is what you mean.  If this is the case, the user cannot 
escape from the malice of the ISP (at least without MIPv6).

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Oct 2001 14:34:36 -0400

> > the ones with which I'm most familiar are distributed computing 
> > applications such as PVM, MPI, Globus, NetSolve, and peer to peer 
> > applications like Gnutella.  but there are others.
> > 

the simple answer is that the "user" is not always human and your notion 
of where the "user" is located in the network does not consistently hold,
for reasons which are quite sound - not "pathological" as you suggest.

> the competition etc. drives the ISP out of the business or the user can

the other side of that argument is if that "something" that the user gets 
from shipworm is too little to support new applications then the user sees
no significant benefit from (what he sees as) "IPv6", and IPv6 will be seen
as useless or worse. IPv6 has already gotten too much bad press from its 
detractors.  And I don't think that the public will perceive the differences 
between shipworm and native IPv6.

> Trying to achieve the perfection may lead into achieving nothing.

true, the "best" is the enemy of the "good".   
but the "not quite good enough" can also be the enemy of the good.

I'm convinced that shipworm can be extended to allow for stable IPv6
addresses even when the outer IPv4 addresses are subject to change.
However this does require support for authentication, which complicates
things somewhat.  I am supportive of shipworm provided we do the remainder
of the work to provide that authentication; I just don't want to see us 
be content with the "not quite good enough" solution.

> server, or if the game authenticates the gamers based on IP address or the 

who says the game has a centralized server?  not all do.
 
> voip call -- the problem is generic; IPv6 routers get rebooted too.

rebooting a router shouldn't cause a voip call to fail.  
remember fate-sharing?
 
Keith

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 21:53:58 +0300 (EEST)

[snip a lot]

> be content with the "not quite good enough" solution.

What kind of authentication do you have in mind?  In worst case this could
get to be a "forever-project" like MIPv6, or an overly complex
implementation when most don't need complexity.

> rebooting a router shouldn't cause a voip call to fail.  

Packets will be lost for at least a couple of minutes.  In practise an
ongoing call is hosed.  This amounts to the same thing with changing
prefix as with native ipv6.  And for new calls, the current address can be
checked from DNS or whatever.

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Oct 2001 14:59:25 -0400

> implementation when most don't need complexity.

granted the danger exists.  obviously we need to avoid that.

I don't want to make an off-the-top-of-my-head proposal about how to
do the authentication, though I'll suggest that it probably needs to 
be compatible with radius back-ends.

> ongoing call is hosed.  

well, hopefully there is no router which is a single point of failure- 
that's just bad network design.  and the time it takes for the network 
to react to routers or links going down is a separate problem.

> This amounts to the same thing with changing prefix as with native ipv6.  

with voip calls perhaps, but this is not true in general.

it's simply not the case that every host (or even most hosts) have a 
useful DNS name.

Keith

---

From: JJ Behrens <[email-masked]>
Date: Tue, 16 Oct 2001 12:18:13 -0700 (PDT)

> be content with the "not quite good enough" solution.

Keith, 

I look forward to your draft.

JJ Behrens