Re: Another v6 question

[bmanning () vacation karoshi com]

> > Second, as I was crunching a few numbers to get a rough estimate of what a
> > global table would look like in say 3 or 5 years after v4 is exhausted (I
> > understand that it's completely unpredictable to do this, but curiosity
> > killed the cat I guess), and in a few cases, I stopped due to the shear size
> > of the amount of prefixes I was coming with. Where i'm getting with this is
> > has anyone done any crunching on prefix count for v6 (as in estimates of
> > global table usage with the various prefix lengths seen above _based_ on the
> > initial allocation of the v6 space (not the entire v6 space itself)). I'm
>
> You really can't map prefix availability to prefix usage.

        this is so true. and yet you proceed, in your next few sentences
        to do -exactly- that. :)

> There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get /32s.

        presuming the LIR model holds...

> There are 256 trillion IPv4 /48s (roughly). There are not 256 trillion
> end sites that will apply for /48s.

        apply to whom? the RIR/LIR model is not the only place/venue
        for getting a /48.

> The whole point of IPv6 is that the number of prefixes vastly exceeds
> the number of applicants that will use them.

        not sure I buy that arguement.  

> To measure the likely content of the IPv6 global table, then, we need
> to look at the number and type of users rather than looking at the
> maximum available number of prefixes.

        if there is a global table that is interesting (debatable point)
        then I'd be more interested in curn rates and overlapping announcements.


> I haven't had trouble reaching anything I care about from my /48
> advertised through Hurricane Electric and Layer 42.
>
> > interested to see how long before we have 96Gb's of TCAM/Memory (take you
> > vendor of choice) in our routers just to take a full table. (Not to mention
> > still having all of the ipv4 de-agg crazyness going on today. Seriously, who
> > lets /28 and /32's in their tables today? And this will only get worse as v4
> > fades away).
> Yeah, that's not likely to happen. TCAM doesn't scale that way. As to the
> IPv4 de-agg, I think that's going to be one of the primary causes for
> an accelerated deprecation of IPv4 once IPv6 starts to become more
> ubiquitous.
>
> Owen