[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re :automatic tunnel mechanism selection [Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]
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" <soohong.park@samsung.com>
To: "Pekka Savola" <pekkas@netcore.fi>; <soohong.park@samsung.com>
Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>; <v6ops@ops.ietf.org>
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.
>
>
>
> 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<pekkas@netcore.fi>
> 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
>
>
**********************************
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.