[135446] in North American Network Operators' Group
Re: Another v6 question
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Jan 25 14:50:03 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <AANLkTikEZVYFz+bx7MVXeht_qNnpkUEC_Mx0qhE6J9SR@mail.gmail.com>
Date: Tue, 25 Jan 2011 11:46:24 -0800
To: Max Pierson <nmaxpierson@gmail.com>
Cc: nanog group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 25, 2011, at 10:19 AM, Max Pierson wrote:
> Hi List,
>=20
> Sorry to bring up yet ANOTHER v6 question/topic, but this seems to be =
one
> that I cannot get a solid answer on (and probably won't and in the =
event
> that I do, it will probably change down the road anyways), but here =
goes.
>=20
>> =46rom the provider perspective, what is the prefix-length that most =
are
> accepting to be injected into your tables?? 2 or so years ago, I read =
where
> someone stated that they were told by ATT that they weren't planning =
on
> accepting anything smaller than a /32. So what if I get my shiny new =
/48
> from ARIN and am already multi-homed??? Does ATT not want my business =
(which
> they wouldn't get if the first place, but for argument sake, yes, I =
chose to
> pick on ATT, sorry if I offended anyone :) I already see /40's /48's =
,etc
> in the v6 table, so some folks are allowing /48 and smaller, so what =
is the
> new /24 in v6?
>=20
Today, the vast majority of providers are accepting /48s in IPv6.
Verizon was holding the line at /32 for a while, but, they moved to /48
a few months ago.
Let's be clear on terminology. I don't think anyone is allowing smaller
than /48, but, most are allowing /48 and shorter. (shorter prefix =3D
bigger network).
> I only ask due to the fact that ARIN's policy for end-users is /48 =
minimum
> (which is what i've been telling folks to apply for or applying for it =
on
> behalf of them).
>=20
That's correct.
> 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.
There are 4 billion IPv4 /32s. There aren't 4 billion LIRs that will get =
/32s.
There are 256 trillion IPv4 /48s (roughly). There are not 256 trillion
end sites that will apply for /48s.
The whole point of IPv6 is that the number of prefixes vastly exceeds
the number of applicants that will use them.
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.
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).
>=20
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
