[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opportunistic Tunneling



Hi all,

My reply in-line.

Regards,
Jordi


----- Original Message ----- 
From: "Pekka Savola" <pekkas@netcore.fi>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Thursday, February 19, 2004 3:34 PM
Subject: Re: Opportunistic Tunneling


> Responding a to few points you raised..
> 
> On Tue, 17 Feb 2004, JORDI PALET MARTINEZ wrote:
> > I believe proto-41 is also one of the proposals on the table for
> > both unmanaged and 3GPP.
> > 
> > For example, TSP can make use of it. We also have a Tunnel Broker
> > implementation that does.
> 
> Note that while proto-41 forwarding is probably useful in e.g. 
> unmanaged scope in general, it is not really applicable to this 
> specific topic, "opportunistic tunneling", where the tunneling is 
> autoomatic, and requires no supporting ISPs.  E.g., tunnel brokers are 
> out of scope for this topic.
> 
> Ignoring proto-41 however...

It will depend on what we consider "opportunistic". For me is clear that we can have tunnel brokers that work like 6to4, i.e., no user registration. Then you use proto-41 (or other means) ... also TSP here can play the game, if no user authentication is required.

> 
> [...]
> > When users start moving with IPv6 devices, we need to ensure that
> > they are able to use it, despite what network they are sitting on.
> > 
> > I've this experience myself, traveling ... and I can solve it
> > manually most of the time, but the users don't know how to. It
> > should be automatic.
> > 
> > There are already applications that only work with IPv6, a few at
> > the time being, but more coming, for sure. The reason is that you
> > need addresses, for example to access multiple devices that are
> > located behind a NAT box.
> 
> I totally agree (about part of your statement) that tunneling should 
> just work, whether the user is behind NAT or not.
> 
> However, regarding this discussion, I'm not sure if you're actually 
> taking a stance whether you you believe a mechanism like 6to4 or 
> Teredo is *required*.  That is, do you think the users must be able to 
> switch on IPv6, without any interaction with any ISP, and have it work 
> (at least with a subset of other IPv6 users)?  Or do you think the 
> user can be required to get a "tunnel broker" -like service (or 
> whatever) from some ISP explicitly?

Yes, I believe 6to4 and Teredo (or equivalent alternatives), are required.

And yes, users have the right to switch to IPv6 w/o any ISP interaction.

Is the ISP business to provide a better service, add value, and gain or lose users, and hopefully they will do, but not all them will do initially until there is some number of users.

The user can also choose to access via a TB or equivalent service.

I'm not convinced however that we should have the users willing to access IPv6 isolated from the rest of the IPv6 users ...

>  
> [...]
> > In Euro6IX we are already working around this idea, but we don't
> > have a draft ready for this meeting, unfortunately. Basically we
> > call it "auto-transition". We need to ensure that the best possible
> > transition mechanism work automatically at any time, in any network.
> [...]
> 
> Yep -- this is pretty important work, and one important issue in the 
> unmanaged evaluation document (spanning both "opportunistic" and 

I miss the end of your sentence ;-)

We will try to have something for the next San Diego meeting.

> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.