Re: [nat66] Comments on draft-mrw-nat66-12

[Brian E Carpenter <[e-mail]>]

On 2011-03-16 20:09, S.P.Zeidler wrote:
> Thus wrote Brian E Carpenter ([e-mail]):
> 
>> On 2011-03-16 11:51, Fred Baker wrote:
>> ...
>>> people don't spend a lot of cycles thinking about NAPT44 route flap effects. 
>> The interesting thing is that people don't spend cycles thinking about
>> any of the NAT-induced glitches which cause end users to lose sessions;
>> some of these will apply to NPTv6 of course. I wonder if it's possible
>> to quantify this (rough % of sessions lost by NAPT44 glitches, and
>> how many of these would *not* occur with NPTv6)?
> 
> You get NAPT44 glitches under two circumstances, in my experience:
> - your NAT gateway is buggy or overwhelmed and loses NAT state ->
>   single sessions fail randomly
> - your NAT gateway reboots, all sessions that were going previously are
>   toast
> 
> Both are due to the statefulness of NAPT44. Since NPTv6 is stateless,
> I do not expect either to apply. (Modulo "it's buggy as an ant farm", but
> that's not a protocol failure, especially not of the protocol algorithm
> is fairly simple).
> 
> If an outside link fails, I would say it was unfair to blame the NPTv6 for
> the sessions across it failing; it's not the cause, the sessions would
> have died without translation just the same.

Well, I think Fred was comparing two multihoming solutions:

1. RFC4116 (PI/BGP4) based multihoming), where user sessions should survive
   if a single ISP link goes down;
2. NAPT based multihoming, where the external address will change if
   an ISP link goes down, so the NAPT session inevitably dies.

I don't know how common that failure is in practice.

However, I agree - the user experience with NPTv6 based multihoming
should be much less prone to glitches than NAPT.

   Brian