RE: Enterprise Analysis DSTM Issue

["Chakravorty,Sham" <SCHAKRA@mitre.org>]

I will second Steve by saying that when I was working on the transition
issues last year, the issue of IPv6 core with IPv4 islands around was
the scenario we had to deal with  most (contrary to the commercial
scenario), and DSTM was one of the very few mechanisms that scored high
as a solution. 

I would like to request its continuance in the WG with necessary changes
in the text.

Sham 

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Klynsma,Steven L.
Sent: Wednesday, August 10, 2005 12:05 PM
To: Tim Chown; v6ops@ops.ietf.org
Subject: RE: Enterprise Analysis DSTM Issue

I'd have to concur with Tim's analysis.  Here, in the Army at least, we
are convinced that it makes sense economically to transition to
v6-dominant networks as soon as possible.  Under DoD guidance (and
frankly, OMB has just issued similar guidance to other US Govt
agencies), we are to migrate to IPv6 (probably dual-stacked) by Sep
2008.  However, there are several large wireless systems I'm aware of
that are planning to implement Ipv6 only in their core with transition
mechanisms at edges to ensure interop with v4 legacy.

Combine that with DoD and OMB's strong push to go to dual-stacked
backbone infrastructure by 2008, and I see the department being in a
position to require DSTM (or DSTM-like) mechanisms (probably combined
with scaleable tunnel brokers) to support v4 islands as soon as three
years from now.  

Having said that, I agree with Pekka that the term "dual-stack" is
overused and increasingly ambiguous, but don't really have any position
one-way or other on whether DSTM is properly named or not.  Got no
problem softening section 8.1 per Tim's suggestion.  


vr,
 
Steve
703-983-6469
 
"Lead your life so you won't be ashamed to sell the family parrot to the
town gossip."  Will Rogers, Jr.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Tim Chown
Sent: Wednesday, August 10, 2005 10:00 AM
To: v6ops@ops.ietf.org
Subject: Re: Enterprise Analysis DSTM Issue

On Wed, Aug 10, 2005 at 04:34:54PM +0300, Pekka Savola wrote:
> On Wed, 10 Aug 2005, Stig Venaas wrote:
> >Right, might be confusing to change the name again (or go back to the
> >AIIH name...). I don't care that much about the name though. There
are
> >some people deploying IPv6-only networks today, and I'm sure there
will
> >be more in the future. So I do see the need for IPv4 over IPv6
tunneling.
> 
> Yeah, but your last sentence was exactly my point.
> 
> You don't need the mechanism labeled as DSTM to do "IPv4 over IPv6 
> tunneling".
> 
> If that's what we wanted, we could just say we need v4-over-v6 and be 
> done.

But you could say the same for other protocols mentioned.
 
My view is that the style of DSTM commentary in 8.4 is good, but 8.1 is
too strong.   We should keep DSTM cited as a 'useful tool for IPv6
dominant infrastructures'.  We can state in the analysis that we need
a protocol for that scenario (#3 of RFC4057) that supports:

  a) v4-in-v6 tunnels
  b) automatic set up of v4-in-v6 tunnels when the host
     doesn't have v4 address and an app wants to create a v4 socket
  c) authentication for tunnel setup

And maybe:

>  d) automatic monitoring and tear-down of said v4-over-v6 tunnel
>     when the host detects it no longer needs the address/connectivity
>  e) plus a number of extensions for even more colorful setups.

but these are too specific for the analysis text.

Look at RFC3904.  That cited Teredo as 'work in progress'.  I see no
reason
why we can't state what generic problem DSTM is solving (assuming we can
agree
that!) and cite DSTM as an example, and 'work in progress'.   We could
even add a recommendation, as per section 7 of RFC3904, saying we should
develop DSTM or something 'DSTM-like'.   

Scenario 3 of Section 3.1 of RFC4057 means we need text for this case.

I could also point out Section 6.2 of RFC3094:

   6.2.  IPv4 Connectivity Requirements 

   Local IPv4 capable hosts may still want to access IPv4-only services.
   The proper way to do this for dual-stack nodes in the unmanaged
   network is to develop a form of "IPv4 over IPv6" tunneling.  There
   are no standardized solutions and the IETF has devoted very little
   effort to this issue, although there is ongoing work with [DSTM] and
   [TSP].  A solution needs to be standardized.  The standardization
   will have to cover configuration issues, i.e., how to provision the
   IPv4 capable hosts with the address of the local IPv4 tunnel servers.

I think this still applies.  If anything, it adds to the case for the
IETF to get active in this issue, via lrw WG or whereever.   So we have
unman and ent cases anting some solution in this space.

-- 
Tim/::1