Subject: RE: POLL: Consensus for moving forward with Teredo?

From: "Liu Min" <[email-masked]>
Date: Sat, 1 May 2004 13:19:19 +0800

I think NAT traversal in IPv6 transition is a very important issue and
should be solved. Although Teredo needs special IPv6 address prefix and
need Teredo relay in every IPv6 network, it is reasonably secure and
already out there. There are also other mechanisms for this issue and
each of them has different properties and applying scenarios. We should
go forward with these transition mechanisms and let the market to make
the final decision.

Best Wishes,
 
Liu Min
Institute of Computing Technology
Chinese Academy of Sciences
Tel: (86-10) 6256 5533-9240 
E-mail: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Pekka Savola
> Sent: Saturday, May 01, 2004 1:32 AM
> To: [email-masked]
> Subject: POLL: Consensus for moving forward with Teredo?
> 
> 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)
> 
>

---

From: "EricLKlein" <[email-masked]>
Date: Sat, 1 May 2004 16:03:11 +0300

I vote a, as this will allow us to insure a proper design and implementation
plan for the future implementations.
Eric

---

From: Jeroen Massar <[email-masked]>
Date: 02 May 2004 22:22:38 +0200

> (co-chair hat on)
<SNIP>
> If you have an opinion, please state it within a week, i.e., by next

I go for 'a' and actually I am wondering why this hasn't been done quite
some time ago. Thus please proceed ;)

Greets,
 Jeroen

---

From: Bill Cerveny <[email-masked]>
Date: Mon, 03 May 2004 12:10:55 -0400

I think "a" is the right choice.

In the Abilene network we have one 6to4 relay active with two more in 
deployment. I'd be happy to promote deployment of one or more Teredo relays 
once I understand how to make this happen in a low maintenance fashion. In 
my opinion, Teredo provides a useful function not available with other 
options.

Bill Cerveny
Backbone Network Infrastructure Engineering
Internet2

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 03 May 2004 20:48:39 -0400

- rereading the initial poll text, it appears as if there are two requests
in the same poll:
 a) to have teredo as v6ops wg item
 b) to have teredo to "go forward" as PS
- looking at all scenarios documents, it appears to me that the current
off-v6ops-wg tools (teredo, isatap, tsp tunnel broker) all apply to one or
many scenarios. dstm-(dhcpv6|tsp) is not really covered in current
scenarios, but have sufficient use for specific networks. 
- my suggestion is to:
 1) have teredo, isatap, tsp tunnel broker and dstm-(dhcpv6|tsp) as v6ops
working group items. all together.
 2) work further on these.
 3) decide later on which track (experimental, proposed standard, ...).
Experimental would be for a tool which does not have wg concensus to be
proposed standard, but would have implementation/use in the field that
would be useful to have a stable RFC document.
- there is nothing that prevents steps 2 and 3 be done "fast", given that
some tools are already implemented and running on the field.
- <biaised comment> to note that tsp tunnel broker is the only one who
applies to most scenarios including v4 in v6...</biaised comment>

My 2 cents.

Marc.

> If you have an opinion, please state it within a week, i.e., by next

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Wed, 5 May 2004 12:41:39 +0200

I support option a) , giving the same reasons that 
Pekka has already pointed out.

Bye.

-- 
******
JFRH
******

It is easier to be a "humanitarian" than to render your own country its
proper due; it is easier to be a "patriot" than to make your community
a better place to live in; it is easier to be a "civic leader" than to
treat your own family with loving understanding; for the smaller the
focus of attention, the harder the task.
		-- Sydney J. Harris

---

From: Bob Hinden <[email-masked]>
Date: Thu, 06 May 2004 16:19:18 -0700

Pekka,

>     unmanaged analysis in parallel (if and as appropriate),

My preference is for a).  I agree with the reasons you and others specified.

Suggest publishing the current draft real soon now and plan on revising it 
in a year or two after there is more implementation and operational experience.

Bob

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 May 2004 23:04:43 +0300 (EEST)

Hi,

(co-chair hat on)

Thank you for participation.

The chairs judge that there exists rough consensus in the WG for
moving forward with Teredo (option a) below).

However, let's continue to try the address (the best we can) the
concerns raised by those participants with a different opinion.

 Pekka & Jonne

(co-chair hat off)