Subject: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?]

From: Pekka Savola <[email-masked]>
Date: Sat, 1 May 2004 07:48:52 +0300 (EEST)

On Sat, 1 May 2004, JORDI PALET MARTINEZ wrote:
> 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.).
> 
[...]
> 
> 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).

I'm having difficulty figuring out what you mean, yes :).

Relay doesn't need to be configured.  Server must be configured, and
typically would probably have to be unless there would be an anycast
prefix which could be used to find the closest serving server (like
with 6to4 relays).  (Vendors shipping products which use their server
pre-configure this so no user config is needed.)  Anycast discovery
was removed from the spec some time ago, but it it's deemed useful, it
could maybe be added back so that you would only use the anycast
address to discover the relay, and use a unicast address after that
(or something).

With regard to the end-points, you could devise a tunnel server
solution that's usable by Teredo clients out-of-the-box.  If you
hijack a popular Teredo server's IP address, you can even force your
users to use the tunnel server ;-).

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

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sun, 2 May 2004 10:31:33 +0200

Pekka,

When we started to work on the auto-discovery, you suggested that the goal could be not just the TB/TSs, but other transition mechanism, as all they require an "end-point". That was I was trying to mean ;-)

I think we should try to offer the best service to the people starting to use IPv6 and at the same time the easier way for ISPs to deploy it. Less protocols (or a few of them using common mechanisms, at least in part), could help on this, I believe.

If anycast was already part of Teredo, why don't get it back. I think that having this option could be part of the "better service", in the sense that the box can try to find an anycast address, and if it's not available, fall-back into the manual configuration (or preconfiguracion from the vendor, or both). At this way, some ISPs willing to offer the service, will facilitate the task of the user, that will not need to manually change it. At the same time, users traveling, could have better service when attached to some networks (like we have with 6to4 more and more frequently).

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, May 01, 2004 6:48 AM
Subject: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?]

> users to use the tunnel server ;-).

**********************************
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: Brian E Carpenter <[email-masked]>
Date: Sun, 02 May 2004 09:59:25 +0200

I can't see any grounds not to proceed with Teredo, though I would
suggest considering a dedicated, very focussed WG, to get it done
more quickly and without de-focussing this WG. (But only if the
IESG is willing to move quickly.) Hence a).

I don't think we should complicate life by mixing this with the
issue of automatic tunnel broker discovery. That is new thinking
brought in by Jordi's draft, and let's keep it separate.

     Brian

JORDI PALET MARTINEZ wrote:
> 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
> 
> From: "Bound, Jim" <[email-masked]>
> To: <[email-masked]>
> 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 
>><[email-masked]> 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
>>------------------------------------------
>>
>>
>>
> 
> 
> 
> 
>