Another v6 question

Tue Jan 25 23:35:02 UTC 2011

>I think you may still be missing my point...
>There are way more /48s available than will ever get used.
>There are way more /32s available than will ever get used.

No, I think you're missing my point. Your statements above are of your
opinion. The same opinion was said about v4 30 years ago which is why we are
where we are today (again, opinions). Reality shows otherwise.

In your opinion, IPv6 is it. We'll NEVER have to do this again. We'll never
have to implement NAT (or some other translation protocol) again. We'll
never have to worry about running out of space. If thats the case, then why
are so many folks arguing over what to give to end users?? It doesn't matter
by your opinion. Give em what they want!! There's no possible way we can use
that many addresses.

Lets get back to reality. No one, and i'll say it once more, NO ONE knows if
v6 is the end all be all. (I would agree with you in regards of our lifetime
we won't even use a drop in the bucket). It only took ~10 years to figure
out they did it all wrong the first time around. Can you speak for the next
100 years, what about 200 years?? (Not that it matters to us anyway, we'll
be long gone by then. But they way you put it is that this beast we're
dealing with will never have to be revamped again. Future proof! To me, that
line of thinking is a little short-sided).

>They will start to care when their ISP starts charging them for every
prefix they inject. If you don't think that IPv4 deagg will lead to an IPv4
prefix >injection charge once IPv6 is more widely deployed, think again.

Some will care and adapt as we all hope they would, some will simply find
another provider with v4 space to spare thats not charging. This won't stop
until RIR/LIR's stop re-issuing v4 space. At that point, then the squeeze is
on and I would imagine ALL ISP's will charge at that point because they're
getting charged for having v4 space.

>I don't think IPv4 will continue to grow for all that long. I think the
plug will get pulled by ISPs desperate to reduce the spiraling costs of
continuing to >support IPv4. When it starts becoming increasingly expensive
to get ISPs to provide IPv4 services, the rest of the internet will begin to
move rapidly >away from IPv4.

>I anticipate this will take about 5-10 years after IPv4 runout at
ARIN/APNIC/RIPE (which will be nearly simultaneous).

I would agree to this as well, 5-10 years of weaning off v4 at that point is
probably what we'll end up seeing, although I would say that 5-10 years in
this industry is a relatively long time. Probably much longer than any of us
want to see v4 stick around anyway.

Max

On Tue, Jan 25, 2011 at 4:17 PM, Owen DeLong <owen at delong.com> wrote:

>
> On Jan 25, 2011, at 1:43 PM, Max Pierson wrote:
>
> Great reply's on and off-list so far.
>
> To hit on a few points ...
>
> Owen, thank you for catching my terminology blunder there. I understand
> smaller is != shorter. Complete mistake :)
>
> Glad to see most have loosened that policy, as I figured it wouldn't hold
> at the time I originally heard it 2 or so years ago.
>
> >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.
>
> I wasn't exactly mapping prefix availability to usage, apologies if it came
> across like that. My crunching did not include host bits. I understand I
> won't see /64's from each of my neighbors down the street. (or I shouldn't
> anyways).
>
> I think you may still be missing my point...
>
> There are way more /48s available than will ever get used.
> There are way more /32s available than will ever get used.
>
> You need to look at the actual number of likely unaggregated sites
> and the number of ISPs. The sum of those numbers with some multiplier
> probably in the 2.5 range is probably about as close as you can get
> to an anticipated routing table size.
>
> That will be much smaller than then numbers you get if you crunch
> the number of available /48s.
>
> >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.
>
> I would agree from a SP perspective, however from and end-user and
> enterprise perspective, most don't care about table sizes and will be slow
> to move to v6 until "everyone else is doing it" ... (as in they have to now
> because their facebook status won't be offered over v4 anymore). Alot
> of organizations I've spoken with still don't know what v6 even is. I think
> alot of end-user land and even some enterprises will drag their feet on this
> as long as it costs money for hardware upgrade to support v6, also having
> staff to support v6, legacy v4 apps that won't be ported to v6, etc. (I
> understand there's ways around this, my point is the customer doesn't). I
> think v4 will be around longer than we want it to (unfortunately), but time
> will tell.
>
> They will start to care when their ISP starts charging them for every
> prefix they inject. If you don't think that IPv4 deagg will lead to an IPv4
> prefix injection charge once IPv6 is more widely deployed, think again.
>
> To Jusin's point,
> I agree that we will be net-negative for a while. My concerns is trying to
> dual-stack a v4 table and a v6 table. They both will grow over time, and
> until the powers that be "pull the plug" on re-issuing returned v4 space
> (which I completely disagree with), it'll continue that way. That's just my
> opinion though :)
>
> I don't think IPv4 will continue to grow for all that long. I think the
> plug will get pulled by ISPs desperate to reduce the spiraling costs of
> continuing to support IPv4. When it starts becoming increasingly expensive
> to get ISPs to provide IPv4 services, the rest of the internet will begin to
> move rapidly away from IPv4.
>
> I anticipate this will take about 5-10 years after IPv4 runout at
> ARIN/APNIC/RIPE (which will be nearly simultaneous).
>
> Owen
>
> Once again, thanks for all on and off list responses!
> Max
>
>
> On Tue, Jan 25, 2011 at 1:46 PM, Owen DeLong <owen at delong.com> wrote:
>
>>
>> On Jan 25, 2011, at 10:19 AM, Max Pierson wrote:
>>
>> > Hi List,
>> >
>> > 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.
>> >
>> >> From 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?
>> >
>> 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 =
>> 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).
>> >
>> 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).
>> >
>> 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
>>
>>
>
>