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

Re: Enterprise Analysis DSTM Issue: dynamic setup

On Wed, 10 Aug 2005, Stig Venaas wrote:
On Wed, Aug 10, 2005 at 06:31:45PM +0300, Pekka Savola wrote: 
  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? 

If you have sufficient amount of IPv4 addresses you could probably
use several mechanisms where you set up tunnels and assign addresses
to every client in the network. As I understand it, DSTM is in
particularly useful when you have hosts that rarely need IPv4
communications, you have enough IPv4 addresses to serve the hosts
using IPv4 at any given time, but not for all the IPv4-capable
hosts simultaneously. Hence the idea of being triggered by apps
trying to use IPv4 (e.g. creation of v4 socket).

First off, the mechanism which triggers the activation of the tunnel is purely a local decision (no bits on the wire), right? So, it's not clear that this even requires a protocol specification. (Especially if the protocol specification doesn't really help the implementor in implementing the algorithm.)

But I'm not sure that v4 access is triggered by apps can even work (the number of possible failure modes is one reason why I've been very troubled by the approach).

For example, almost all server apps try to create a socket both for v6 and v4 when they start up. Many client programs also do similar things. Are you saying that the hosts would not have any of these applications or couldn't use them without lots of manual configuration (i.e., forcing to use only v6 socket) ?

In fact, this dynamic setup when a v4 socket creation is attempted could even be undesirable. There have certainly been folks which don't want to enable v6 when apps try to create v6 sockets (some systems have done this automatically). It seems clear that the same also holds for v4. I.e., a quick failure in the socket loop might be better (and intended) than trying to obtain the address.

I'm not sure b2 makes sense above. You could automatic setup
v4-in-v6 tunnel when hosts boots provided you have enough IPv4
addresses. However, I think IPv6-only core only makes sense if
IPv4 is rarely used. In that case it makes sense to have tunneling
state only when needed. And as I said above, this may also make
sense if you have lack of addresses. So the tunnel setup and the
assignment of IPv4 address should only be done when needed. One
way of detecting need, is request an IPv4 socket.
[...] 
There are also some networks today that struggle getting enough
IPv4 addresses for the network infrastructure...

Yes, but one could say that those networks are also the ones who are most likely to use private addresses and NAT.

Given that the assumption is that v6 is already deployed basically everywhere (at least in the enterprise):
1) public v4 addresses are typically needed by public server apps or
some p2p softwares and similar
2) p2p softwares and similar are also the ones which have most
profits of being ported to v6
3) public server apps are those (e.g., the enterprise web servers)
which require very high amount of reliability. Would you as
a system/network admin trust a transition mechanism to
automatically get [often dynamic] address (and update DNS etc.)
using mechanisms like this?

That is, frankly, I don't think there is really big justification for dynamic "enablement" due to address space scarcity. Private addresses would be just fine in those deployments AFAICS. So whether to enable the tunnels dynamically or not seems to be just a matter of whether you want all the hosts which you know should run v4 apps to get connectivity reliably w/o complexity at the startup (or some locally defined) time.

In other words, IMHO "dynamic setup" seems like an interesting problem (e.g., to be fussed about by geeks like you and me :), but not something we need to solve.. Less is More.

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