Subject: Proposed way forward with the transition mechanisms

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 29 Jul 2004 23:07:17 +0300

Dear v6ops WG,

our very own AD, David, sent the WG list mail on the July 1st about the
way forward and how he sees the way forward for our little WG. Pekka and
I have discussed the topic and found enough consensus among ourselves to
propose a way forward for the WG. Of course, you the WG, have to say if
you agree with the following approach. We believe that the discussion
should be started now on the WG list and then continue it in the
face-to-face meeting in San Diego to work the details further. The final
decision for the way forward is of course for the WG to make in the
mailing list - as always in the IETF.

The proposal is to derive the different transition mechanisms from the
Scenarios/Analysis documents and identify either the matching, existing
mechanism, or identify gap and list possible solutions. We have done our
own preliminary analysis. The proposal bellow is for discussion and
should not be considered the final list. We would like to have
discussion if it really does identify all needed mechanisms and just the
needed mechanisms. 

Bellow there is a list of mechanisms. This the list that Pekka and I put
together in quite short time. It may or may not be correct and that's
something that we have to discuss on the list and in the face-to-face in
the meeting. So, this is just the baseline to start the discussion.

In the interest of time, we propose to do this on the list and after
running the process document it into a draft. I can do the draft editing
myself.

In the following, is the analysis of the different scenarios/analysis
documents (in no particular order).

3gpp-analysis:
 SIP v4/v6 transition mechanism
 Zero-configured IPv6-over-IPv4 tunneling mechanism

unmanaged:
  Teredo*
  Configured tunneling through NAT
  IPv4 over IPv6 tunneling mechanism

ISP:
  BGP-tunneling*
  Tunnel server/broker

Enterprise:
  Analysis not done.

Summary:
  Teredo*
  BGP-Tunneling*
  SIP v4/v6 transition mechanism - No candidates
  Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates
  Configured tunneling through NATs - No (direct) candidates, but Tunnel
        Server/Broker also addresses this
  Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP,
        ISATAP possible candidates.
  IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many
        tunnel server/broker approaches also address this.

(* Teredo and BGP-tunneling are already moving forward)

The suggestion is to go forward with Teredo/BGP-Tunneling immediately,
work on SIP v4/v6 transition in SIP WG(s), and find the correct place
for finding suitable solution for the following:
 
  a) zero-configuration both at the client or the server,
  b) IPv6-over-IPv4 tunnels (with NAT traversal support), and
  c) IPv4-over-IPv6 tunnels

This work should take use of 
draft-ietf-v6ops-assisted-tunneling-requirements-00.txt.

Cheers,

Jonne & Pekka - the chairs.
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 29 Jul 2004 23:22:12 +0300

Hello everybody,
(chair hat off - this is totally my personal view)

when writing the proposal for the WG, Pekka and I noticed that we have
different view on some issues. In one topic especially, we seemed to
have pretty opposing views. This topic is the role of ISATAP. 

I do personally believe that ISATAP is pointed as the most promising
solution for automatic tunneling in the 3GPP analysis document and thus,
should be listed as a solution to be standardized. 

I thought even that there was at least some support in the WG for ISATAP
and it had been seen also at least somewhat applicable for enterprise
scenarios. This is of course difficult to say as the enterprise analysis
document is not existing, yet. 

However, I would hereby propose as an individual the addition of ISATAP
in the list of mechanisms that should be standardized on standards
track. (Of course, there has to be consensus in the WG to do that.)

I would like to hear what other people feel about this! (Pekka's view I,
at least, know already.)

Cheers,

Jonne.
On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki)
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Tim Chown <[email-masked]>
Date: Thu, 29 Jul 2004 23:21:45 +0100

> should be listed as a solution to be standardized. 

Our own experience (non-small enterprise) is that we prefer to deploy
a structured (configured) transition mechanism - in our case VLAN-based 
IPv6 propogation - rather than an unstructured (automatic) method.  So
we don't see any need for ISATP in our particular scenario.   However,
I can see why some others see some attraction.
 
> I would like to hear what other people feel about this! (Pekka's view I,

I think also maybe 6to4 relays should be considered for ISP analysis, 
where at the moment brokers and 6PE are cited.   In the case of European
NRENs, 66% have a 6to4 relay, less than 33% a broker, aimed at local
NREN communities.

I also believe an enterprise (university, in our case) can offer a broker 
or 6to4 relay in the absence of the NREN doing so, or in the case of a
staff or student users in a home network, their home network ISP not 
offering one (because the RTT from the national commercial network to the
national academic network will be low).

What's the agenda again for v6ops?  How much time do we have for this
minor little topic? ;)

Tim

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Jul 2004 01:30:26 +0300 (EEST)

> NRENs, 66% have a 6to4 relay, less than 33% a broker, aimed at local

The document does mention them, but kind of takes it for given as it's 
already on the table:

   The ISP may offer opportunistic services, mainly a 6to4 relay,    
   especially as a test when no actual service is offered yet. At the
   later phases, ISPs might also deploy 6to4 relays and Teredo servers
   (or similar) to optimize their customers' connectivity to 6to4 and   
   Teredo nodes.

> What's the agenda again for v6ops?  How much time do we have for this

The agenda is available at http://www.ietf.org/ietf/04aug/v6ops.txt.
There will be sufficient time for this :-)

(If folks in general have specific ideas how you think we should
discuss these topics in the meeting, feel free to drop me and Jonne a 
note off-list..)

-- 
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: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jul 2004 11:06:55 +0200

Tim Chown wrote:
...
> national academic network will be low).

6to4 is already Proposed Standard, so its status is not currently
under discussion. Deployment is its own reward.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jul 2004 11:10:11 +0200

> I can see why some others see some attraction.

I think many enterprise networks will agree, not to mention that since
ISATAP solves the NBMA problem, it has some intrinsic complexity. So I do
echo Alain's question: what makes ISATAP fit better than ordinary tunnels,
in the 3GPP secnario?

    Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 30 Jul 2004 10:12:26 +0100

> under discussion. Deployment is its own reward.

I was only commenting on Jonne's list, which includes tunnel broker (an
existing RFC) but not 6to4.   The list should be draft-only, or all
mechanisms, I think, to avoid confusion.

Tim

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Jul 2004 12:34:35 +0300 (EEST)

> mechanisms, I think, to avoid confusion.

It is draft-only, in the sense that the tunnel broker RFC (3053) does
not document the actual protocol, just the concept.  If we go down
that path, an additional spec would be needed.

---

From: "EricLKlein" <[email-masked]>
Date: Fri, 30 Jul 2004 13:54:56 +0300

> that path, an additional spec would be needed. - Pekka Savola

It looks to me like the WG should look at an enhanced draft to explain the
additional requirements /specifications / recommendations rather than
letting these pop up with out consideration.

So in short I wonder if we shouldn't look for the actual protocol issues for
tunnel broker.

Eric

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 30 Jul 2004 12:57:53 +0200

Hi Jonne,

In general I agree with your view, but from our point of view, you're missing some work already being done that cover some of the gaps we are missing:
1) draft-palet-v6ops-tun-auto-disc work fits perfectly to fill the analysis of Zero-configured IPv6-over-IPv4 tunneling mechanism, and in addition we are already since a few weeks working in the solution document. Of course, this should be considered, same as the rest of the candidates, or even looking for a solution that could take components from the different candidates. Our target is to have a document submitted at the end of August as latest.

2) We are also working, in combination with the previous documents, in the IPv4 over IPv6 tunneling mechanism with NAT traversal support. This is already described in the draft-palet-v6ops-auto-trans, and a new accompanying document with the proposed solutions (may be several). Our target is also end of August. Also I guess this is what you call zero-configuration both at the client or the server ?

3) Regarding Tunnel Server/Broker, our work on this is obviously very complementary and we have already worked on ideas for improving TSP, with the view on 1) and 2).

4) Our proposed solutions should also work for IPv4 over IPv6 Tunneling, but this has not been our main goal for the August target, but probably we can also take a look on that, and include at least some hints to be further developed later on.

We are implementing also all those solutions, and our target is to have everything ready before end of this year. The way we are doing this, will most probably allow the auto-transition to take advantage of other existing mechanism, in a modular approach, allowing also new future mechanism to be easily integrated, both in the client and the "server" or "tunnel end point" or whatever we call it.

I will provide more details in my presentation.

Regards,
Jordi

---- Original Message ----
From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 29, 2004 10:07 PM
Subject: Proposed way forward with the transition mechanisms

> Jonne & Pekka - the chairs.

**********************************
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: Pekka Savola <[email-masked]>
Date: Fri, 30 Jul 2004 14:24:51 +0300 (EEST)

> letting these pop up with out consideration.

Lucky for you -- it's already there and in WG last call:  
draft-ietf-v6ops-assisted-tunneling-requirements-00.txt :-)

> So in short I wonder if we shouldn't look for the actual protocol issues for

See above.  The point is probably whether folks agree (or not) whether
such a protocol would be sufficient to solve their problems.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 30 Jul 2004 16:02:27 +0200

I forgot to mention something else ...

We are also working in the possibility of a policy based transition "helper" than could be installed in the ISPs to provide better service to the customers, as a complement to the "zero-configuration" or auto-trans, whatever we call it.

Regards,
Jordi

----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 30, 2004 12:57 PM
Subject: Re: Proposed way forward with the transition mechanisms

Hi Jonne,

Regards,
Jordi

---

From: Fred Templin <[email-masked]>
Date: Fri, 30 Jul 2004 16:52:28 -0700

Jonne,

Obviously, I support ISATAP progressing on standards-track as long
as it can go forward in the correct way. The current I-D documents
widely-deployed implementations and is suitable for intra-site operation
when there are no NATs in the path, which might be OK for experimental
purposes. But further discussion may be necessary to determine what
is needed for standards-track.

In a recent series of I-Ds, I proposed an operational model for ISATAP
similar to host-specific relay/personal tunnel broker, but the approach
didn't seem to garner much interest. I'd like to propose a somewhat
different approach now; for more details, please see:

  http://www.geocities.com/osprey67/v6v4inet-01a.txt

Thanks - Fred
[email-masked]

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Sun, 01 Aug 2004 02:37:05 +0300

Fred,

I was talking about ISATAP as it exists today. So, as an intra-site
protocol.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34