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

[Reinaldo Penno <[e-mail]>]

A few comments inline...


On 12/3/09 2:00 PM, "Simon Perreault" <[e-mail]> wrote:
> 
>> I re-read a _single_ section of NAT64 (3.2.4.  ICMP Query Session Handling).
>> I found that developers have the following choices (and this does not go
>> into implementation details):
>> 
>> * Local Security Policy can drop ICMPv6 packets (yes/no)
>> * Local Security Policy can drop ICMPv6 packets configurable per
>>   interface/rule/etc (yes/no for each one)> * ICMPv4 message will be sent
>> back to sender (yes/no/configurable)
>> * ICMPv4 message will be sent back to sender per configuration
>>   interface/nat rule/etc (yes/no each one)
>> * ICMPv4 message will be sent back to sender in case of filtering
>>   (yes/no/configurable)
>> * ICMPv4 message will be sent back to sender per configuration
>>   (interface/rule/etc)
> 
> These do not affect state.

Why not? 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.

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.

> 
>> * ICMPv6 lifetime can be configurable (yes/no)
>> * ICMPv6 lifetime can be configurable within a certain range (yes/no)
>> * ICMPv6 lifetime can be configurable with a granularity of ms/seconds/etc
>>   (yes/no)
>> * ICMPv4 lifetime can be configurable (yes/no)
>> * ICMPv4 lifetime can be configurable within a certain range (yes/no)
>> * ICMPv4 lifetime can be configurable with a granularity of ms/seconds/etc
>>   (yes/no)
> 
> 
> 
>> Can you elaborate on which tests need to be done in order to guarantee that
>> this scenario will work between two different vendors?
> 
> So you mean that because vendor A and vendor B will not swear that each
> other's This 
> statement
> has nothing to do with NATs and applies in many other cases you know...
> 

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. 

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.


>> Finally, If you pin down all specific behavior you need within all possible
>> permutations of different vendors, weigh the operational cost of a
>> multi-dimensional testing to find two boxes that can provide the High
>> Availability with the NAT behavior you need, I think you will find out that
>> NAT64-A and NAT64-B are made by the same vendor.
> 
> That could very well be true. It is also often the case for e.g. BGP speakers.
> But some people like to run stuff from multiple vendors. And it works, and it
> has advantages and disadvantages. Tradeoffs, etc.
> 
> Thanks,
> Simon