Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

[Simon Perreault <[e-mail]>]

Dan Wing wrote, on 2009-12-01 13:39:
> My point is that it shouldn't make things worse.  If the functioning
> NAT64's prefix changes and the old prefix no longer works, that makes
> things worse -- it effectively causes IPv6 addresses to change.  That
> breaks not just applications that are sensitive to IP address changes, 
> but also existing TCP sessions.  SCTP handles IP address changes
> better, but there is scant deployment of SCTP yet (due to many 
> reasons).

I don't understand where you're going.

There are two kinds of breakage:

1. One NAT64 box in a cluster* dies. No impact beyond the fact that you now have
a dead box that needs replacing.

2. A whole cluster dies. This is not pain-free, and it's not designed to be.
Suddenly, you need to redirect all clients to the new Pref64::/n. There are
known issues with that, but this event will happen rarely enough that it's worth
the risk.

If you're really afraid of breakage #2, you have to use bigger clusters. But
that has disadvantages too. It ends up being an operational issue. Tradeoffs, etc.

Another idea: have another cluster "take over" the prefix of the dead one. Use
routing to redirect clients to the new cluster. Tradeoffs, etc., again.

My point is that #2 doesn't need standardization. The solutions are diverse and
everyone will be dealing with it differently. On the other hand, #1 is a well
understood problem, with a well understood solution, with various proprietary
incarnations in use right now (hint! hint!).


* Cluster = A set of synchronized NAT64 boxes sharing a single Pref64::/n.

Cheers,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org