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