[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed way forward with the transition mechanisms
Fred,
I was talking about ISATAP as it exists today. So, as an intra-site
protocol.
Cheers,
Jonne.
On Sat, 2004-07-31 at 02:52, 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.
> >>
> >>
--
Jonne Soininen
Nokia
Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com