Another v6 question

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 :slight_smile: 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?

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

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

Would love to hear comments from anyone that was rejected peering due to
only having a /48. Would also like to hear from anyone about projected table
sizes if anyone has done any research on this.

Heading back to my cave now to hopefully hear some good responses. (An
someone please correct me if any of the above is incorrect).

TIA,
Max

people are considering /48 to be 'the new /24'. A number of providers haven't published their v6 policies yet (at least in any place that's easy to find), but it looks like based on policy alone, NTT and Verizon will accept /48s.

Also, I don't know that the number of v6 prefixes will get completely out of control for a while. Many of the bigger consumers of v4 space are getting (or have gotten) initial v6 assignments that are large enough to satisfy their space needs for some time, so the number of v6 prefixes being announced to provide connectivity to a given number of ISP customers should actually go down somewhat. For example, Comcast has several /8s of v4 space, and they are announcing a /29 into the global v6 table at the moment. That could certainly change as they ramp up their deployment of v6, but I still think the number of v6 prefixes compared to v4 will be net-negative for a long time.

jms

From: Max Pierson
Sent: Tuesday, January 25, 2011 10:20 AM
To: nanog group
Subject: Another v6 question

>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 :slight_smile: 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?

Generally, a /48 from PI space and a /32 from PA space will be accepted.
If you were issued a /48 from ARIN it will generally be accepted. Some
accept all the way out to a /64. I do see some de-aggregated /64 nets
I am currently filtering but since the path is the same as the /32, I
haven't seen need to open those filters up yet. Can't figure out why
those are de-aggregated either as I don't see the more specific
announced anywhere else.

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

> 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. :slight_smile:

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.

Almost everyone of consequence accepts a /48. Verizon last year was very
firm at /32, but I've heard they recently changed their mind. Verizon
gave up on trying to get IPv6 to me before this and closed the account
after a calendar year's worth of attempts. I replaced them with Global
Crossing who got it right on the first try.

These days a provider that only accepts a /32 or shorter is the
exception, not the rule.

~Seth

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. :slight_smile:

Not really...

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

  presuming the LIR model holds...

Whatever.

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.

To whomever they are getting their addresses from. It's irrelevant to
the purposes of the discussion. The point was to show the total
amount of supply vastly exceeds any rational perception of demand.

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.

OK, maybe not the whole point, but, certainly the primary reason
for widespread IPv6 adoption is going to be to eliminate the shortage
of IP addresses present in IPv4.

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.

Whatever. The point is that to predict the likely size of such a table,
presuming it continues to exist, one must consider the size and
type of prefixes that will be in it rather than considering the maximum
possible size based on available prefixes.

Owen

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.

You could try the ipv6-ops mailing list, it is a bit more topic
specific to what you're asking about.

http://lists.cluenet.de/mailman/listinfo/ipv6-ops

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

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

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.

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

Once again, thanks for all on and off list responses!
Max

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

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

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

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

Hi Max,

There is a Wikipedia article all about that:
http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers

And here is some more information about subnetting your IPv6 network:
http://en.wikipedia.org/wiki/IPv6_subnetting_reference

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

V4 30 years ago -- expected consumption: ~60 /8s of 256.

IPv6 today -- expected consumption: Maybe 15 /12s of 4096.

The scales in question are vastly different.

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.

Not at all... In my opinion, IPv6 will probably last about 30-50 years. In my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I absolutely think we'll have to do this all again. I just don't think that addresses are going to be the thing we run out of next time.

I think people are arguing over what to give end users because people are generally bad at large-number arithmetic. The human brain can visualize things up to as much as a few hundred. Some people can even visualize a couple of thousand. Beyond that, our neurons just think of things as randomly larger magnitudes of "a really big number". It all gets lumped into "a whole lot" and we lose site of the numeric realities.

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

No, that's not what I said at all. What I said was that addressing isn't going to be the constraint that causes us to have to revamp it next time.

Let's put it in perspective... If we give a /48 to every end site, then, we have
enough addresses for 281,474,976,710,656 end sites. There are currently
<7,000,000,000 people on the planet, so, let's assume we give each of them
10 buildings (home, work, a summer cottage, and 7 spares for whatever).
That consumes 70,000,000,000 /48s. Now we're down to 281,404,976,710,656
/48s remaining. If we build 1,000 new end sites every second, we will
need 281,404,976,710 seconds to use them all up. At 86,400 seconds
per day, that's 3,257,002 days or 8,923 years.

I'm pretty sure that we will not be able to sustain building 1,000 new
structures per second for 8,923 years. To do it in 200 years, we
would have to build almost 50,000 new structures every second.

I realize there have been some amazing periods of growth on the
internet, but, even at the peak of the .COM boom, even Cisco wasn't
building at anywhere near that rate.

However, all of this is a bit out of context from what I was saying.
The point was that if you're trying to figure out how big routers are
going to have to be for near-term IPv6 or even medium-term IPv6
deployment, counting the total possible number of prefixes isn't
a useful metric because the actual utilization will be nowhere
near that large and the numbers are impossible to use as an
engineering spec. for any technology yet known.

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.

There will come a time (likely this year) when there isn't another provider with v4 space to spare that you can find. One that doesn't charge for it? That'll probably happen even earlier.

I think that the RIR/LIRs won't have to stop reissuing space. I think we'll rapidly reach a point where space isn't coming back to them to be reissued. At least not in meaningful quantities.

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

Well, that's <6-11 years from today.

I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic.
I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years
it will be because of significant foot-dragging by some key organizations.
I'm not convinced that foot-dragging is as likely as some people are, but,
there's enough probability to provide some wiggle room in the numbers.

Owen

V4 30 years ago -- expected consumption: ~60 /8s of 256.
IPv6 today -- expected consumption: Maybe 15 /12s of 4096.
The scales in question are vastly different.

I made no such comparison between the two. The scales are vastly different,
but I think you're still missing my point. 30 years ago, no one "expected"
cells phones to consume IP's. 30 years ago, no one "expected" xbox's and
playstations to consume IP's. Point being is the "unexpected".

Not at all... In my opinion, IPv6 will probably last about 30-50 years. In

my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I

absolutely think we'll have to do this all again. I just don't think that

addresses are going to be the thing we run out of next time.

Ok then, what is it exactly you think we'll run out of in 30-50 years??
Please elaborate.

No, that's not what I said at all. What I said was that addressing isn't

going to be the constraint that causes us to have to revamp it next time.

Once again, please elaborate.

The point was that if you're trying to figure out how big routers are
going to have to be for near-term IPv6 or even medium-term IPv6
deployment, counting the total possible number of prefixes isn't
a useful metric because the actual utilization will be nowhere
near that large and the numbers are impossible to use as an
engineering spec. for any technology yet known.

Actually, my original post may have been somewhat misleading due to "what a
global table would look like in say 3 or 5 years after v4 is exhausted" and
"in our routers just to take a full table". I wasn't referring to just v6
deployment moving forward. I didn't mean after v4 goes away completely. I
was adding v4 table + v6 table (assuming we dual-stack, if you separate the
two, ~4000 prefixes fit quite nicely on just about anything still running
today, and that also makes the second question of my original post
irrelevant). We won't need that amount of memory after v4 goes away
(probably for quite some time). The prefix count at that point will be
significantly lower. I understand that. Apologies for not being clearer.

I'd like to see IPv4 go away in ~3 years. Any faster would be too

traumatic.

I think 6 years is a perfectly reasonable time frame. I think if it takes

11 years

it will be because of significant foot-dragging by some key organizations.
I'm not convinced that foot-dragging is as likely as some people are, but,
there's enough probability to provide some wiggle room in the numbers.

I agree, although I do think there will be some foot-dragging, I just don't
think it will take 11 years. If anyone at that point is still speaking only
v4, IMO they'll only be speaking to "127.0.0.1".

M

>V4 30 years ago -- expected consumption: ~60 /8s of 256.
>IPv6 today -- expected consumption: Maybe 15 /12s of 4096.
>The scales in question are vastly different.

I made no such comparison between the two. The scales are vastly different, but I think you're still missing my point. 30 years ago, no one "expected" cells phones to consume IP's. 30 years ago, no one "expected" xbox's and playstations to consume IP's. Point being is the "unexpected".

I'm not missing your point. I'm saying that in IPv6, we've put enough addresses
in to allow for things nobody has thought of in 30, 60, 90, even 100 years and
then some.

>Not at all... In my opinion, IPv6 will probably last about 30-50 years. In my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I >absolutely think we'll have to do this all again. I just don't think that addresses are going to be the thing we run out of next time.

Ok then, what is it exactly you think we'll run out of in 30-50 years?? Please elaborate.

If I knew, then, I'd be well on my way to much greater wealth. Whatever it is, I am only
certain of the following things about it:

  1. We have no idea what the requirements will be at this time.
  2. We have no idea which particular scaling limit in IPv6 will actually drive
    us to the next protocol.
  3. Our needs in 30-50 years will be different than our needs today.
  4. This all assumes that we have a human race to care about having an
    internet in 50 years. Such is not necessarily a safe assumption.

>No, that's not what I said at all. What I said was that addressing isn't going to be the constraint that causes us to have to revamp it next time.

Once again, please elaborate.

See below... I pretty much did elaborate in another message about
the number of /48s and the construction rate required to consume
them.. I don't know what will cause us to
revamp it next time. I'm just sure there are enough numbers to make
it to that point.

>The point was that if you're trying to figure out how big routers are
>going to have to be for near-term IPv6 or even medium-term IPv6
>deployment, counting the total possible number of prefixes isn't
>a useful metric because the actual utilization will be nowhere
>near that large and the numbers are impossible to use as an
>engineering spec. for any technology yet known.

Actually, my original post may have been somewhat misleading due to "what a global table would look like in say 3 or 5 years after v4 is exhausted" and "in our routers just to take a full table". I wasn't referring to just v6 deployment moving forward. I didn't mean after v4 goes away completely. I was adding v4 table + v6 table (assuming we dual-stack, if you separate the two, ~4000 prefixes fit quite nicely on just about anything still running today, and that also makes the second question of my original post irrelevant). We won't need that amount of memory after v4 goes away (probably for quite some time). The prefix count at that point will be significantly lower. I understand that. Apologies for not being clearer.

Well, once IPv6 is more fully deployed, you'll be seeing at least 30,000 and more like 75,000 prefixes in IPv6. That's because there are about 30,000 active ASNs today and given tendencies towards traffic engineering, greater multihoming, easier address acquisition and some other factors, a 2+ growth factor over ASNs wouldn't surprise me in the short term.

>I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic.
>I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years
>it will be because of significant foot-dragging by some key organizations.
>I'm not convinced that foot-dragging is as likely as some people are, but,
>there's enough probability to provide some wiggle room in the numbers.

I agree, although I do think there will be some foot-dragging, I just don't think it will take 11 years. If anyone at that point is still speaking only v4, IMO they'll only be speaking to "127.0.0.1".

I think there will be quite a bit of foot dragging. I think you misunderstand me.
I'm expecting everyone to be pretty much dual-stacked in the next 3-4 years,
even with foot dragging. I'm expecting us to start seeing IPv4 actually deprecated
as in some providers won't route it any more (or if they do, they'll charge a lot
to do so) in 6-11 years. That's what I mean when I say I'd like to see IPv4
go away in that time frame.

Owen

Possibly, as long as we don't blow through them via exercises in profligacy nobody has heretofore thought of, heh.

;>

I expect that in ~3 years, we will see dual-stack and /64's handed out in conjunction with an IPv4 address as "common".

The ipv6 zealots talking about anything but a /64 for end-site are talking about a "business class" service. Even with my static IPs at home, I have no need for more than a single /64 to be used in my wildest dreams. I could live with ~256 ips for the future. I consider my tech density "above-average".

- Jared

As one of the IPv6 zealots talking about anything but a /64 for end sites, I
can assure you that I am talking about it for residential class service
not business class.

Your tech density may be above average for today, but, you lack vision
for the future.

Imagine a future where devices form autonomous network segments
and negotiate prefixes and routing for those segments in a semi-
or fully- autonomous fashion.

The appliance net in the kitchen will be managed by a router.
The RFID tags on the products in your fridge and your pantries
will form autnonous subnets with routers embedded in the
fridge and pantries. Each of your home entertainment clusters
will likely form its own subnet.

Even today, it is not uncommon for a residential gateway to support
at least five segments:

  1. External WAN segment shared with ISP
  2. Internal wired network
  3. Internal wireless network
  4. "DMZ" segment
  5. Guest wireless network

Seriously, it's important that we do not limit our IPv6 thinking by
our IPv4 mindset. The future is not the present and we will see
much more advanced capabilities in the residential world
going forward if we allow it to happen.

Owen

I'm not missing your point. I'm saying that in IPv6, we've put enough

addresses

in to allow for things nobody has thought of in 30, 60, 90, even 100 years

and

then some.

As Roland said,
"Possibly, as long as we don't blow through them via exercises in profligacy
nobody has heretofore thought of, heh."

If I knew, then, I'd be well on my way to much greater wealth. Whatever it

is, I am only

certain of the following things about it:
      1. We have no idea what the requirements will be at this time.

I believe it was Donald Rumsfeld that said...
"But there are also unknown unknowns – the ones we don't know we don't
know."

What if that unknown comes in the form of "mass address consumption"? But
from your view, that's not possible, so i'll just move on.

     2. We have no idea which particular scaling limit in IPv6 will

actually drive us to the next protocol.

I am aware that v6 still has some of the same issues that v4 has. Those have
been talked about for years. I'm sure you're aware of this as well...

The v6 train has already left the station. Scale at some point will be an
issue, I'm just not entirely convinced it's v6 that will need revamping.

I think you misunderstand me.

I understand you .... and all that you've stated. I just don't happen to
agree with some of it.

M

Let's put it in perspective... If we give a /48 to every end site, then, we

have

enough addresses for 281,474,976,710,656 end sites.

I get your point about sustainable growth. I even agree with it.

What you're referring to then is not

I'm not. There's certainly interesting use cases of this "IP" header type, independent of being v4 or v6.

You're talking about the various segments, and I'm thinking about the folks from Toyota doing their ipv6 local networks integrated into vehicles. But many people are also stuck in thinking that these people need to be segmented in the first place. This "security by obscurity" mentality that being behind a VPN, being air-gapped, wired, wireless, that you are deserving of a variable class of service is part of the discussion.

I could call out vendors that have highly sensitive data that is available "if only" you brought a cat5 cable to the office vs using their "guest" wireless. that segmentation ignores the authentication of end-stations, or person behind the keyboard. If you actually did that, you don't need to have a different 'guest' wireless vs the 'internal' wireless network.

Now, I don't think that by reading this that an enterprise is going to clean up their act, (wired vs wireless), or stop any other silly practices using these "packet eating" firewall/nat/vpn devices.

But tying those practices in to the equation can serve to validate the premise that these people actually need to be segmented vs solving the real security (trust) problem that exists on the end devices. You don't necessarily need to see my AppleTV on my home network, but as a guest at my home, (after authenticating to my local wireless network) you gain access to play music and control various elements of my network. I don't need to make these "public", but if they are on a public-IP, the devices should be able to be properly secured (and can be).

I don't think I need a public and private FridgeNet to determine the quantity and quality of the beverages and offer different SLAs based on if they are on the 'guestFridgeNet' vs 'privateFridgeNet'. This is taking it a step or three too far. Most people don't know or care what their IP subnet is. Even if every time I connected a device to my network (or re-connected after power saving, etc) I incremented the usable part of my /64, it would take me some time to consume that space fully.

I do think we're closer together than apart, but for 90% of home users, (and you can quote me on this in 10 years) a /64 will be sufficient for their uses. Anyone needing more than a /64 for their home is either going to some impractical extreme or better defined as a "prosumer" that will want a higher SLA in the first place, and therefore should pay a modest amount more.

- Jared