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

[Simon Perreault <[e-mail]>]

Reinaldo Penno wrote, on 2009-12-03 16:43:
> First of all you state that all NAT64 implementations will be the same
> because the standard is new.

This is exaggerated. I think that because NAT64 is *well specified* (compared
with NAT44), chances are higher that a standard state sync protocol will work.

> 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.

> * 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)

These will need to be taken into account by an eventual state sync protocol. For
example, we could have a phase at connection establishment where these
parameters are explicitly stated and we make sure that the two are configured
with the same values. Or we could do dynamic configuration in master/slave fashion.

I don't see this as anything more than a requirement for a state sync protocol.

> And do not even get me started in generic address-filtering behavior which
> is much more complex and have more implementation choices.

Please do! This is helpful design work! ;)

> And this the way things are because different providers have different
> networks and provider service to customer with different needs.

I don't see how this is relevant.

> Second, you indicate that operational complexity is something on the side.

Again, this is exaggerated. Of course you need NAT devices that are spec'ed
correctly. I don't see how this affects a state sync protocol.

> 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
stuff works fine, we should only use stuff from a single vendor? This statement
has nothing to do with NATs and applies in many other cases you know...

> 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
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org