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

[Simon Perreault <[e-mail]>]

On 12/05/2009 03:27 AM, Reinaldo Penno wrote:
> If a certain mapping on NAT64-A does not send ICMPv4 packets back
> for unsolicited sessions and another mapping does, this behavior must remain
> the same on the fail-over box.

This is arguable. IMHO, this behaviour could be different without 
negative impact in many situations.

But the point is that the state sync protocol is completely unconcerned 
with this.

> NAT state is the mapping state + ICMP behavior (discussed above) + filtering
> behavior + timer settings (discussed below for ICMP) + log behavior
> (yes/no/format) + others not discussed. Each of these can be different for
> different NAT entries.

We have different definitions of state it seems.

ICMP behaviour, filtering behaviour, timer settings, log behaviour, and 
others do not vary over time. (Or we could impose the constraint that 
the state sync connection be renegotiated when they do vary.)

The state sync protocol is only concerned with stuff that varies over 
time, i.e. bindings and sessions. That's it.

> Some people made the opposite case and it brings to some of the basics. NAT
> operational complexity is high and therefore brings special requirements to
> the table. Based on your statement it seems you think there are similar
> cases.

"NAT operational complexity is high" is a blanket statement. For 
example, nowadays most everyone has a NAT at home without even knowing it.

> Can you give an example that has the same characteristics as hot-standby for
> NATs based on the few things that were discussed? If there are we should
> look into how hot-standy across different devices&  vendors was achieved in
> that case.

I don't know. But are you saying we shouldn't do something because 
nobody has done it before?

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