Subject: RE: DSTM

From: "Bound, Jim" <[email-masked]>
Date: Thu, 24 Jun 2004 10:03:36 -0400

> In DSTM there is a single place where this happens: the 
> gateway where the tunnels terminate. "4over6" could be more 
> flexible as packets don't necessarily flow through a single 
> gateway. We may even provide for some kind of "proxy 4over6" 
> tunneling so that IPv4-only hosts in otherwise IPv6-only 
> networks may enjoy connectivity.

Multiple TEPs can be provided to the client for redundancy and router
failover deploying dual rail routers supports the mission critical case,
and if the link is cut or blown up there is custom software to inform
clients of that etc.  I see your point it is worth discussion and we
need to say something about this in our next draft.  Thanks

Note I believe your concern applys to all transition mechanisms and do
we need to put this health warning on all transition mechanisms and in
our scenarios as we do security?   Again is this just picking on DSTM or
should the question be applied to all mechanisms (not mean't as negative
question just a question)?  As a question of fair and open process?

I don't think we can solve this problem in specs but implementation will
resolve it is my view today but listening to the list.

In DSTM it is assumed that an IPv4 address from the DNS returned which
begins the DSTM client the TSP or DHCPv6 or RPC to the server will match
correct TEP and CIDR or IPv4 high order bits of address for network
route.

Regards,
/jim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jun 2004 16:47:05 +0200

On 24-jun-04, at 16:03, Bound, Jim wrote:

> clients of that etc.

This sounds awfully complex to me... I'd rather take advantage of 
existing redundancy features such as VRRP.

> our scenarios as we do security?

We are engineers; we build reliable networks from unreliable parts. So 
much goes without saying, or at least without saying it over and over 
untill we're all sick of hearing it...  :-)

With security, every little thing must be secure. With redundancy, it's 
acceptable to have unreliable parts as long as you have several of them 
and switching from one to the other isn't too fatal. So I think those 
two issues are in different categories.

I'm not very comfortable with the phrase "all transition mechanisms" as 
most of the transition mechanisms that were created at one time or 
another turned out to be fairly useless ("automatich tunneling", 
6over4, isatap). There is some risk that this will happen again now 
that we're looking at the other side of the coin (tunneling 6 over 4) 
unless we're very careful.

> Again is this just picking on DSTM or

I guess it depends. If there is stuff that's clearly useful and maybe 
even deployed, but there is no good way to add redundancy, so be it. On 
the other hand, if we have the choice between solving a problem in a 
way that allows for redundancy and in a way that doesn't, then it makes 
sense to go with the redundancy-friendly way.

With regard to DSTM: I applaud the goal, but I'm doubtful if the way to 
get there is the optimal one, for the reasons listed earlier, and also 
because having some special purpose software handling all kinds of 
details isn't very attractive (to me at least), as opposed to having a 
more generic encapsulation mechanism over which we can run a variety of 
existing mechanisms such as ARP, DHCP and VRRP.

But I understand you guys already have code. I guess the best way 
forward would be to deploy this code and see how well it behaves in the 
real world. If it turns out it works very well, we should probably 
standardize it, even if there are theoretical flaws. On the other hand, 
if the issues I pointed out and/or others turn out to be of concern in 
practice, we may want to start from scratch at some point in the 
future, heeding the lessons learned.

> correct TEP and CIDR or IPv4 high order bits of address for network

??? I don't understand. If I connect to more than one IPv4 destination, 
do I talk to more than one tunnel endpoint? That doesn't make sense.

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Jun 2004 15:54:47 +0100

On Thu, Jun 24, 2004 at 04:47:05PM +0200, Iljitsch van Beijnum wrote:
> 6over4, isatap). 

I'm not sure I agree with that sentiment for ISATAP (though I have not
found a use for it in my own deployment environment).

Tim

---

From: "Todd T. Fries" <[email-masked]>
Date: Mon, 28 Jun 2004 15:25:16 +0000

It seems strange to me that VRRP is mentioned on a v6ops mailing list
when, as far as I have been lead to believe, VRRP does not support V6.

CARP, on the other hand, does.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jun 2004 23:43:48 +0200

> when, as far as I have been lead to believe, VRRP does not support V6.

We were discussing providing IPv4 service over native IPv6 networks. In 
today's IPv4 networks routers acting as default gateway for a number of 
hosts are often "clustered" using HSRP or VRRP. This works very well, 
it would be a shame if this functionality wouldn't be available when 
running IPv4 over IPv6.

Note that in IPv6 the need for VRRP isn't as acute as in IPv4 as there 
isn't much reliance on statically configured default gateways.