Re: WGLC ent-analysis-03: DSTM

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

 In your previous mail you wrote:

   > => RFC 1918 and a NAT? Is it really your idea??
   
   Yes.  People use it, and seem to be pretty happy about doing so.
   
=> this is a philosophical issue... Here is not the right place
to discuss it.

   Remember, we're offering *v6* as an end-to-end protocol which doesn't 
   have to deal with NAT etc.  In that light providing this functionality 
   for v4 might even be counterproductive :)
   
=> and say that RFC 1918 and a NAT will solve any problem is productive :) ?

   > => Do you argue there is not realistic scenarios where there is no
   > choice and the IPv4 address space has to aggressively be conserved?
   
   No, I'm not saying that.  What I'm saying is that people will use 
   different (simpler) tools to perform this conservation.  The easiest 
   one at their disposal is RFC1918 and NAT.

=> NAT is not a general solution: it doesn't work with embedded addresses.
So you have no real counter-argument.

   My argument is that let people use RFC1918, NAT, or whatever 
   mechanisms they want for *v4* address conservation, let us focus on 
   *v6* transition, not finding means how to prolong v4 address usage 
   under aggressive conservation.
   
=> the purpose of the v6ops document is to help to solve problems,
not to enforce something. So as the previous scenario is credible
DTSM (i.e. c)) has to be referenced.

   Maybe d) could be split off to something like:
   
         d.1) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
            when an address lifetime expires (and is not renewed)
   
=> d.1) is the thing I think about.

         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
   
=> d.2) should be loosely done by a good choice of parameters (initial
and renew lifetimes), i.e., it should not be necessary to be so
aggressive.

   (I don't see how the host checks that it no longer needs the address 
   in d.2

=> I know: this is a standard garbage collection problem (see below).

   but that's a separate point -- or how you'd prevent premature 
   revokation of the address w/ a lifetime..)

=> I can't see what is the "premature revokation" here: if an address
is still in use and is near to expire, just renew?
   
   I think you are proposing something that seems to significantly differ 
   from what has been deployed today: DHCPv4 is typically used to give 
   you an address "for good" (to be refreshed periodically though).  It 
   doesn't have provisions (AFAICS) to detect whether the address is in 
   use or not when deciding whether to try to refresh the lease or not. 

=> in fact it is very easy to do because the problem is not about
the address use but the global IPv4 use. In my implementation I
simply use the reference count of the default route because the
neighbor cache is implemented as cloned children of it.

   You're adding a component of potentially fragile nature in the system.
   
=> anything is potentially fragile. Do you really believe that a NAT
is not fragile?

   > Just say there is a binary only application using embedded addresses
   > (unfortunately not a silly assumption, don't forget this is about
   > enterprise scenarios).
   
   Such applications likely work fine through a TCP proxy or NAT?
   
=> they don't work through a NAT so an ALG is needed per application...
Can I add "encrypted" or "ciphered" before embedded?

Regards

Francis.Dupont@enst-bretagne.fr