Re: WGLC ent-analysis-03: DSTM

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   and in 8.4:
   
   DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
   enterprise transition or deployment of IPv6-dominant network links
   is desired. DSTM is to being submitted as an IETF Experimental RFC.
   
   ==> as it is, DSTM is a way too overloaded a mechanism to be referred to
   without more disclaimers or description.

=> the overload (if any) should be solved by the references...

    As it is, different people use
   "DSTM" to mean at least the following things:

=> I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent Toutain's DTI.

     a) v4-in-v6 tunnels
     b) automatically set-up v4-in-v6 tunnels

=> this (b-a) is DTI

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

=> this (c-b) is AIIH

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

=> this (d-c) is an operational consequence of AIIH.

     e) plus a number of extensions for even more colorful setups.
   
=> I believe you mean DSTM+

   a) doesn't require DSTM;

=> I agree, there are 3 kinds of tunnel interface:
 - static (the state is per interface)
 - dynamic (the state is in a table, one interface is enough to handle
   many tunnels. Note this is implementation)
 - algo (the state (end-point addresses) is taken from the packet
   (inner addresses). An example is 6to4)
DTI is exactly the dynamic flavour and is needed in DSTM for scalable
Tunnel End-Points.

   b) can be achieved using a tunnel broker;

=> this is both true and false: how the state is managed can be orthogonal
to the tunnel interface itself.
BTW the point is critical for the interoperability.

   c) does not require IETF interoperability (a local implementation choice
   when/how to launch the v4-in-v6 activation).

=> I don't understand your comment: the idea (AIIH) is more than useful
when a global IPv4 address is required.
PS: AIIH is the by-need allocation of an IPv4 address.

   d) could also be considered in
   the same category (there are no bits in the wire or anything requiring
   interoperability AFAICS on when the host removes the tunnel), though I'm
   skeptical whether even providing that would be a good engineering choice.
   
=> d is a consequence of the possible allocation of global IPv4 addresses
and is managed exactly as DHCPv4 does. To compare with similar mechanisms,
IKEv2 CFG_REQUEST can allocate home IPv4 addresses with expire/renew/...

   My point is that I'm having hard time figuring out:
     1) what the document means when it's recommending DSTM, and

=> the references

     2) based on my analysis above, I do not believe that DSTM (in the way
     that I think it's being referred to) is even needed.

=> DTI is needed as soon as the TEP has to be scalable, AIIH is needed
as soon as global IPv4 addresses are needed. Note that extra capabilities
should not be a problem, i.e., DSTM works well with static IPv4 addresses,
and even when they are not needed they can bring some advantages, exactly
as DHCPv4 can be used as a management tool where it only gives static
addresses (aka BOOTP mode).
   
Regards

Francis.Dupont@enst-bretagne.fr