Re: Enterprise Analysis DSTM Issue

[Tim Chown <tjc@ecs.soton.ac.uk>]

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