NAT444 vs IPv6 (was RE: legacy /8)

Lee Howard lee at asgard.org
Wed Apr 7 16:29:54 CDT 2010


> > Nobody promised you a free lunch. In any case, the investment required
to
> > turn up IPv6 support is a lot less than the cost of carrier grade NAT.
And
> > the running costs of IPv6 are also lower,
> 
> Can you provide pointers to these analyses?  Any evidence-backed data
showing how CGN
> is more expensive would be very helpful.

It depends.  If you plan to do IPv6 eventually, it's probably cheaper to do
it now than to depend on NAT444.
NAT444 breaks some things (fewer than you might expect, so it might not be
as expensive as you think).  
Some of those things can be fixed by doing static port forwarding, but that
means a support call explaining how to configure port forwarding on the LSN,
and troubleshooting through the CPE.  Cost analysis:  more support calls,
but might be even with IPv6 support calls.

If your provisioning and OSS are centralized, you may need multiple
instances inside each LSN (or tunnels, or some other way to cope with the
fact that you now have multiple domains of 10/8 inside your network).  Cost
analysis:  may be the same amount of development required to add IPv6
functionality, but additional hardware may be required.

You need a pretty big logging infrastructure, so you have an answer when
Smokey says, "Who had this address with this source port at time T six
months ago?" and lawyers on hand to explain why you won't tell them all 500
customers who were using that address at the time.  And a variety of things
documented in draft-ford-shared-addressing-issues.  Cost analysis:  lots of
disk, lawyers, for issues that don't exist in IPv6.

All of your hardware already speaks IPv4, very little requires updates to
support private addressing.  Cost analysis:  you probably have some hardware
that doesn't support IPv6.

If cost were the only criterion, it might be an even split between NAT444
and IPv6.  Using NAT444 to delay  replacing non-IPv6 hardware  until the
regular depreciation cycle  means spending twice on development labor  just
to delay the capex.  That math may or may not make sense for your network..

Lee





More information about the NANOG mailing list