Re: WGLC ent-analysis-03: DSTM

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 29 Aug 2005, Tim Chown wrote:
> On Mon, Aug 29, 2005 at 10:34:39AM +0300, Pekka Savola wrote:
> > I don't think the purpose of any v6ops document is solve problems in
> > one's *v4* network by *v4* mechanisms, so it's not entirely clear if
> > the mechanism is in the scope of this WG.
>
> If you deplay a v6-only network infrastructure then v4 transport is a 'v6
> problem'.   I guess he crux of your argument is
> a) why not run dual stack, even with v4+NAT
> b) why can't apps be updated to use IPv6

Depends on what you mean by 'dual stack'.  For this particular thread, 
I think my main arguments are:

 - if you want to run v6-only network but dual-stack hosts, that's 
fine, you can run stuff in v4-in-v6 tunnels -- for example, scenario 
a) or b.1) from the list below.  HOWEVER, I don't see why you [in 
practical scenarios] need mechanisms to give (very) temporary global 
v4 addresses on the nodes, and then take them away (e.g., c) or d) 
from the list below).  You can just deploy private v4 addresses if you 
have address shortage, or use more stable v4 global addresses.

 - the mechanisms which go beyond DHCPv4-like functions for address 
assignment on v4-in-v6 tunnels do not have any bits-on-the-wire 
interoperability requirements, and thus do not require 
standardization.  Such mechanisms can also be brittle and very 
implementation-specific, and I'd be hesitant to even try to encourage 
them.

 - the DSTM spec is not clear enough on its scope and intent and 
should not be referred to in a WG document.  My own take here is (if I 
understand the intent of the spec) that we don't (anymore) require a 
document like that, but rather should concentrate (in some other WG 
like softwires, it's out of charter here) on creating the actual 
protocol specification(s).

.........................

 a) (manually configured) v4-in-v6 tunnels [RFC2473]

 b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel
    server(s) which can happen without user intervention, e.g., using
    a process described in draft-palet-v6ops-tun-auto-disc-03.txt.
    This must include a way to auto-configure a v4 address [e.g.,
    DHCPv4-like method].

 b.2)  the automatic set-up of v4-in-v6 tunnels, so that between each
    host, an ad-hoc tunnel can be signalled and set up" [6to4-like
    traffic optimization]

[ everything below here doesn't have any direct bits-on-the-wire 
interop requirement (maybe except e), it can be just a local vendor's 
optimization ]

 c) assignment of an address on top of v4-in-v6 tunnel(s), but
    deferred until the application wants to create v4 socket.
    [issues with dual-stack server apps, for example]

 d.1) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
      when an address lifetime expires (and is not renewed)

 d.2) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
       when the host detects it no longer needs the address/connectivity

 e) plus a number of extensions for even more colorful setups (e.g.,
    instead of just assigning an address, assign only certain _ports_
    of an address).

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