Sorry, the previous message was incomplete... On 2011-03-16 20:09, S.P.Zeidler wrote: > Thus wrote Brian E Carpenter ([email protected]): > >> 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. ==>This failure mode also exists for NPTv6. 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 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
