Subject: Re :automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]

From: PARK SOO HONG <[email-masked]>
Date: Mon, 15 Mar 2004 20:12:52 +0000 (GMT)

not sure these draft are related to this thread since I didn't follow up
this issue.

http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ctep-opt-00.txt

These draft only addresses configured tunnel end point so far, but it can
be

expanded to include others easily IMHO.

Hope this help

------- Original Message -------
Sender : Pekka Savola<[email-masked]>
Date : Mar 15, 2004 20:05
Title : automatic tunnel mechanism selection [Re: tunnel broker deployment
[RE: Tunneling scenarios and mechanisms evaluation]
I'm replying to only one issue, under a new subject line, because I

think the others have been sufficiently addressed..

I think this mechanism selection work is also important, and it would

be nice to have something written out very soon so that we wouldn't

get stalled too soon.  If folks are interested in writing up something

quickly, please do line up.. :)

On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:

> > Remember, our goal is

> > not get IPv6 deployed to those guys who are reading this

> > mailing-list and can do a lot of technical stuff to set things up.

> > The target audience (which I have in mind at least) is much more

> > "dumber" than that.  I'd like to aim for the case where the most

> > the user would have to do is click an "activate IPv6" icon on the

> > desktop or network settings -- and not necessarily even that.

> > That function should try to send route solicitation on your link,

> > find a free tunnel broker provided by your own ISP, or set up

> > 6to4/Teredo all else failing.

> Agree, as said in a previous message, this is more or less what we

> are doing, and hopefully could present in San Diego (we call it

> auto-transition):

Yes, this is very useful work, but something that should be done much

sooner than San Diego (IMHO).  Draft out within a week or two would be

a good goal :-).  Actually I think this has already been discussed

quite a bit (e.g., the "unmanaged bar gathering" at Minneapolis at

IETF58), but not written out and fleshed out entirely.  It would be

very useful to get that at least started and something written out

soon.

Another related subject which needs to be worked at also is the

coexistance of all of these mechanisms.  It's not just what you're

using yourself, but what you should do to enable the others to use v6

to talk to you (e.g., local 6to4 or Teredo relays).  This may be out

of scope for this idea, but something to keep in mind in any case.

> - Native

> - 6to4

> - TB with 6in4 if a public IPv4 address is available

> - TB with proto-41-forwarding if NAT supports it

> - TB with UDP encapsulation

It may be worth noting that discovery of TB's is a rather delicate

process (see the other thread), and a subject which may be very

difficult to do properly.  But we can try...

> - Teredo

> - others (even IPv6 over HTTP in the worst case !)

Well, I'd leave that "even" out from here.. :-)

> The order not necessarily is what I wrote down, as it may depend on

> the "best performance" solution for every client, and even change if

> the client or network change.

True, though "perfomance" is hardly an easily measurable unit, so

difficult to use in practice algorithmically.

> The "activate IPv6" should not be needed if we can manage to have

> the process automatically, and alternatively we should offer the

> "deactivate IPv6", hopefully, if for whatever reason, the user

> choose to ;-)

Sure.

> The auto-transition might propose the user, if the IPv6 performance

> in a given situation is very bad, to use IPv4 (hopefully with the

> time less and less often).

That's possible, yes.  In most cases, the performance is actually

worse, but there are different ways to count it (e.g., v4 connectivity

through for P-2-P through a server vs. direct v6 connectivity; and

good v4 latency vs bad v6 latency).  This is probably something that

would be impossible to measure properly.  So I have doubts about this

being all that useful -- but one could certainly use this to say "hey,

the tunnel broker is 200 ms off on the other side of the globe --

maybe it's not a good idea to use it?"

--

Pekka Savola                 "You each name yourselves king, yet the

Netcore Oy                    kingdom bleeds."

Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Regards

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 15 Mar 2004 23:23:28 +0100

Hi Daniel,

We are considering referring to your documents and providing inputs to them, as part of our work. Keep in sycn ;-)

Regards,
Jordi

----- Original Message ----- 
From: "PARK SOO HONG" <[email-masked]>
To: "Pekka Savola" <[email-masked]>; <[email-masked]>
Cc: "JORDI PALET MARTINEZ" <[email-masked]>; <[email-masked]>
Sent: Monday, March 15, 2004 9:12 PM
Subject: Re :automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]

> Samsung Enterprise Portal mySinglenot sure these draft are related to this thread since I didn't follow up this issue.
> 
>  
> 
> These draft only addresses configured tunnel end point so far, but it can be
> 
> Title : automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]
> > > Remember, our goal is 
> > > not get IPv6 deployed to those guys who are reading this 
> > > mailing-list and can do a lot of technical stuff to set things up.   
> > > The target audience (which I have in mind at least) is much more 
> > > "dumber" than that.  I'd like to aim for the case where the most 
> > > the user would have to do is click an "activate IPv6" icon on the 
> > > desktop or network settings -- and not necessarily even that.   
> > > That function should try to send route solicitation on your link, 
> > > find a free tunnel broker provided by your own ISP, or set up 
> > > 6to4/Teredo all else failing. 
> >  

**********************************
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.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Mar 2004 11:35:17 -0800 (PST)

> > http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt 

I think the technique in this draft is useful to consider in what Alain
called case b) (where the ISP is providing the IPv6 service but
is doing it using tunneling over IPv4 to avoid upgrading all
their infrastructure to support IPv6 on day one).

  Erik

---

From: Alain Durand <[email-masked]>
Date: Tue, 16 Mar 2004 21:20:06 -0800

On Mar 15, 2004, at 12:12 PM, PARK SOO HONG wrote:

> not sure these draft are related to this thread since I didn't follow  
> up this issue.

Thank you for sharing those draft.

> http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-01.txt

The idea of using DHCP from the ISP to the CPE of the user to indicate
a tunnel endpoint which act as tunnel server is interesting.
However, I do not understand why you add a netmask to it.
Also, sending more than one IP address for tunnel endpoint seems
to add complexity for little gain, so I would favor a simpler version
that advertise only one endpoint.

> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ctep-opt 

This one makes me more perplex...
This seems to me like a routing protocol that does not want to say its  
name.
It somehow says: to reach IPv6 destination X, tunnel to Ipv6  
destination Y
I'm not sure I understand the purpose of this... Why doing routing with  
an IPv6 in Ipv6 encapsulation?

btw,  is it a DHC document or an individual submission?

	- Alain.

---

From: "S. Daniel Park" <[email-masked]>
Date: Tue, 30 Mar 2004 08:38:34 +0900

A revised draft is now available as below:

<http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-02.txt
http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-02.txt 
 
Any comments are most welcome !

Regards

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics.