Re: Enterprise Analysis DSTM Issue

[Pekka Savola <pekkas@netcore.fi>]

First note: you may have an assumption that I have something against 
v4-in-v6 tunnels in general.  Even though I don't see the management 
simplicity considerations myself, I don't object to having a simple 
solution.

So, a v4-in-v6 solution is "just OK".  But this is already provided 
under "tunnel broker" section.  I don't see the _other_ requirements 
for the additional DSTM features at least yet.

On Wed, 10 Aug 2005, Tim Chown wrote:
> 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

OK, this is good.  Let's try to separate b) into three:

  b1) automatic set up of v4-in-v6 tunnels

  b2) automatic set up of v4-in-v6 tunnels when the host
     doesn't have v4 address

  b3) 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

What are the requirements, exactly?

> 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.

Maybe, maybe not -- but we need to figure out what's the thing that 
people are looking for.

> 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'.

Yes, but Teredo has a very clear applicability and scenarios.

[More or less automatic] IPv4-in-IPv6 tunneling also can also be 
argued for.  That can be solved with a tunnel broker; DSTM specifies 
much more.

So, the point here is, do we just need [automatic] v4-in-v6 tunnel 
set-up mechanism (provided by tunnel brokers), or something more (it 
isn't clear _what_, exactly).

> 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.

Yes, there is no doubt v4-in-v6 tunneling is needed.  A standards 
track solution already exists (RFC 2473).   But if you need more, 
tunnel server/broker concept is widely used, and I believe that's what 
lrw is aiming to solve.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings