Jim,
I fully agree with this view, and moreover, if we allow the auto-discovery of the TB, then even more clearly, the TB will be applicable to unman and other scenarios.
I wonder if Teredo could take advantage of the auto-discovery idea (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt), making sure that if required both the 6to4, TB/TS/TSP, ISATAP and the Teredo relays, can coexist automatically in the same box. This could easily simplify the deployment and be an important multiplicative factor.
So, I will suggest a new option "a.bis)": The idea is to make a very quick move on defining a solution for the auto-discovery, and include this in a revised Teredo version (same with ISATAP, TSP, etc.).
Note that I will not like to delay the "go forward" of a) option for a long time, but I'm convinced that if Christian and some other people related to other transition mechanism (TB/TS, may be ISATAP) that need to discover end-point work together.
If we have inputs on the auto-discovery solution, I'm sure that a small team of "hard workers" could make it even before the next IETF. This is a small delay, but I believe the result could be worthy.
Christian, Pekka what do you think ? (I've not read the latest versions of Teredo, so I'm not sure if what I'm saying is actually meaningful, but I understand that the server/relay need to be pre-configured, so can we make it auto-discovered ?, indeed we didn't included Teredo in our I-D, but may be an option for the next revision).
Regards,
Jordi
----- Original Message -----
From: "Bound, Jim" <jim.bound@hp.com>
To: <v6ops@ops.ietf.org>
Sent: Friday, April 30, 2004 10:38 PM
Subject: RE: POLL: Consensus for moving forward with Teredo?
We must work on Teredo, ISATAP, DSTM, and Tunnel Broker. All are being
deployed all will exist. So I vote for (a) but I think Tunnel Broker is
also a choice for UMAN and if asked in the market tell them try both and
see what you like best each have different properties. And I hope there
are more good and innovative transition mechanisms invented the more the
better. We will build many types of IPv6 networks I am sure we do not
have all the tools for transition done and all of the above will be used
and are useful for deployment.
/jim
-- Friday, April 30, 2004 20:32:26 +0300 Pekka Savola
<pekkas@netcore.fi> wrote/a ecrit:
Hi,
(co-chair hat on)
As identified in the scenarios analysis at IETF59 and in
draft-savola-v6ops-tunneling-01.txt, there appears to a need which
cannot be filled by another mechanism for Teredo at least
in one major
Unmanaged scenario.
Is there rough consensus to move forward with Teredo?
(i.e., to adopt
it as WG document in this WG or elsewhere, for Proposed Standard.)
The main issue raised has been to call for a more extensive
analysis
for the deployment implications of native, 6to4, and
Teredo. There is
already discussion of this in the Unmanaged Analysis
document. There
seemed to be very little energy or interest in the WG to drive this
much further.
The options regarrding Teredo at this stage seem to be:
a) Go forward with Teredo, hone the deployment implications in the
unmanaged analysis in parallel (if and as appropriate),
b) Conclude that there is no sufficiently strong need for
Teredo, and
not support its advancement (for PS) at this stage, or
c) Decide that we need to analyze the scenarios or deployment more
before being able to make a decision.
If so, please state where you believe more analysis is needed..
and volunteer if possible :)
If you have an opinion, please state it within a week,
i.e., by next
Friday, 7th May.
Thanks!
(co-chair hat off)
------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
**********************************
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.