[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed way forward with the transition mechanisms

FYI,

The document mentioned in my earlier message (below) does contain
some elements which I believe could go towards an Enterprise Analysis
document - as I am well aware may also be true for some other documents.

Thanks - Fred
osprey67@yahoo.com

Fred Templin wrote: 
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
ftemplin@iprg.nokia.com

Soininen Jonne (Nokia-NET/Helsinki) wrote:

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)
wrote:


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.