Rate of growth on IPv6 not fast enough?

Tue Apr 20 13:23:14 UTC 2010

On Mon, 19 Apr 2010 19:57:04 -0700
Owen DeLong <owen at delong.com> wrote:

> 
> On Apr 19, 2010, at 3:10 PM, Florian Weimer wrote:
> 
> > * Leo Bicknell:
> > 
> >> I know of no platform that does hardware NAT.  Rather, NAT is a CPU
> >> function.  While this is another interesting scaling issue, it means
> >> this data is not going in the FIB (hardware forwarding database),
> >> but rather is stored in a CPU accessible database.
> > 
> > If you NAT all traffic, the NAT database needs the same level of
> > efficiency as the FIB.
> > 
> > You could probably even join the two (you should check that the
> > corresponding RIB entry is still current, but that can probably be
> > forced to be cheap).
> 
> More likely, if you're going to do this (and I would not wish it on my
> worst competitors), you would want to push smaller NATs out towards
> the customer aggregation point where you can get away with cheaper
> commodity hardware that can later be repurposed. Yes, more boxes,
> but, much less expensive and keeps the router doing what routers do
> best rather than NATing everything on the router.
> 

Pushing functions as closer to the edge of the network usually makes
them easier to scale and more robust and resilient to failure.
There might be more chance of failure, but there is less consequence.

Specific to CGN/LSN, I think the best idea is that if we can't have
a 1 to 1 relationship between subscriber and global IPv4 address (in
the ISP network that is), the next best thing is to try to keep as
close to that as possible e.g. if you share a single IPv4 address
between two customers, you've halved your IPv4 addressing
requirements / doubled your growth opportunity, and allowed for e.g.
32K TCP or UDP ports for each of those customers. 

Regards,
Mark.