> > 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
>
>
