[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WGLC ent-analysis-03: DSTM

On Thu, 25 Aug 2005, Francis Dupont wrote: 
  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 :) ?

Yes -- at least it will encourage people to see the benefits of v6 in a different light :)

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


Yes, it doesn't work, but what I'm asking here is a reality check.

I guess what you're saying is that some sites have binary-only, 10+ old applications which have embedded addresses. Those applications work just fine if you use them internally in the site only (using RFC1918 addresses).

Do you want to provide such an application to the outside? -- REALLY? Even if you do, I don't think a site has dozens of such applications on dozens of hosts. Those applications are required to work reliably (otherwise they would not still be provided, at great pains). Thus I don't see why the addresses would need to be set up and torn down dynamically -- manual config would probably be more reliable and more useful.

Or do you want to use such an application (provided by someone else) from the outside? Again, I'm not sure if I'd buy the argument that these are commonplace enough to be worth the trouble -- remember that NATs are already so widely deployed, that these applications cannot be used from the majority of the networks.

  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.

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.

  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?

If an application is still in use (but the host may have very much difficulty in figuring out whether it's used or not!), the address lease should not expire, otherwise you've prematurely taken off an address and the application ceases to work.

  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.

I'm not sure I understand the implementation well enough to say whether that would work or not (I guess it will work as long as the application regularly sends packets and "uses" the default route), but how would that work for a server application which just binds to an address and doesn't send out anything? Or a client application which just happens to sit quietly for some time?

  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?

Sure, NAT can be fragile as well. The users and administrators typically understand the main fragilities of NATs though. This is of a different kind. The mechanisms used by DSTM are typically implementation-dependent (such as the way you use the default route refcount). So, every implementor has to figure out his/her own mechanisms on your own, and each approach is likely to have some issues; the specification cannot help here as there we're too deep in the realm of implementation-specificity.

As I said earlier, this approach may or may not be something that a vendor could implement, but there don't seem to be bits in the wire that need standardizing, and the generic concept is probably NOT something we want to specify due to its fragilities, implementation-specificity, etc.

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

Are we talking about the same (very old, binary-only) applications? The strongest encryption in these I've seen has been "XOR" (for just a part of the payload), and even that was a surprise :)

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