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
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. 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? 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
On Tue, 25 Jan 2011, Max Pierson wrote:
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?
From what I've seen, both in terms of policy and practice is that most 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 :) 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.
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
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
On Jan 25, 2011, at 12:03 PM, bmanning@vacation.karoshi.com wrote:
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. :)
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
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).
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 :) Once again, thanks for all on and off list responses! Max On Tue, Jan 25, 2011 at 1:46 PM, Owen DeLong <owen@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
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@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
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.
They will start to care when their ISP starts charging them for every
I don't think IPv4 will continue to grow for all that long. I think the
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). 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. 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@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@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
On Jan 25, 2011, at 3:35 PM, Max Pierson wrote:
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.
I'd like to see IPv4 go away in ~3 years. Any faster would be too
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. 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 On Wed, Jan 26, 2011 at 7:33 PM, Owen DeLong <owen@delong.com> wrote:
On Jan 25, 2011, at 3:35 PM, Max Pierson wrote:
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
On Jan 26, 2011, at 9:31 PM, Max Pierson wrote:
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
On Jan 27, 2011, at 1:29 PM, Owen DeLong wrote:
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.
Possibly, as long as we don't blow through them via exercises in profligacy nobody has heretofore thought of, heh. ;> ------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
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... http://www.apricot.net/apricot2007/presentation/apia-future-routing/apia-fut... 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 On Thu, Jan 27, 2011 at 12:29 AM, Owen DeLong <owen@delong.com> wrote:
On Jan 26, 2011, at 9:31 PM, Max Pierson wrote:
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
On Thu, 27 Jan 2011 09:20:01 -0600 Max Pierson <nmaxpierson@gmail.com> wrote:
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.
We know both what the IPv6 addressing architecture is and what the current IANA/RIR etc. addressing policies are - nothing is an "unknown unknown". *Unexpected* "mass address consumption" is not possible unless and until the current addressing policies change. It is only those who wish to play thought games with how they could abuse 128 bit addresses that are pretending these architectural decisions and policies don't exist and won't be enforced. Mark
On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote:
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 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
On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote:
On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote:
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 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
On Jan 27, 2011, at 10:04 AM, Owen DeLong wrote:
On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote:
On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote:
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 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.
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
On Thu, 27 Jan 2011 11:03:41 -0500 Jared Mauch <jared@puck.nether.net> wrote:
On Jan 27, 2011, at 10:04 AM, Owen DeLong wrote:
On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote:
On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote:
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 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.
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. '
I think you need to review what subnets originally and are still essential for - overcome link layer framing differences - isolate broadcast or multicast traffic from nodes that aren't interested in it or even the act of ignoring that type of traffic is unacceptably resource intensive for those types of nodes I agree with your comments about security shouldn't rely on addressing. My preferred model would be something like the bluetooth pairing model (i.e. trusted assocations) with time limit on the trust. Even then, it isn't really the machines you can't trust, it's the people behind them, and those people aren't bound to certain select machines. Subnets became security domain boundaries because (a) hosts didn't used to have any sort of firewalling capabilities, where as routers did (i.e. ACLs) and (b) hosts tended to naturally be grouped together based on where security domains would occur e.g. all of H.R.s PCs were attached to the same subnet as all those staff existed on the same building floor or area. However, even if an addressing agnostic host security association mechanisms emerges, we still have an interim period until then where security or policy by subnet is necessary, and we'll also have reasons to subnet after then - the original and same reasons why routers were invented and bridges couldn't do the job. Regards, mark.
On Thu, 27 Jan 2011 07:04:31 PST, Owen DeLong said:
On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote: 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".
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
Even at the low end - a Belkin Play wireless router with that basic config can be had for $45 now: http://www.google.com/products/catalog?oe=utf-8&q=belkin+play+router+wireless&um=1&ie=UTF-8&cid=8536738187275945735&ei=B5JBTaPwJYjVgAfPh7ngAQ&sa=X&oi=product_catalog_result&ct=result&resnum=3&ved=0CDcQ8wIwAg# Nice unit, works reasonably well for me. Too bad I'll probably have to replace both that and the Linksys cablemodem in front of it when Comcast gets me IPv6 (I'm not holding my breath waiting for firmware upgrades for either to enable IPv6, at that price level the flash memory must be fairly tiny and IPv6 will cause the image to grow a bunch). On Thu, 27 Jan 2011 11:03:41 EST, Jared Mauch said:
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.
Enterprises don't use $45 Belkin wireless routers. The segmentation security model works just fine for a home network - I give my kids the SSID and key for the one wireless net, and if they have friends along when they visit, they get the SSID and key for the *other* network off the post-it note stuck to the side of the Belkin. (That security model works too - if you can read the post-it, my wireless is the least of my security problems). Feel free to suggest a significantly better security model that involves less management work for me. ;)
On Thu, 27 Jan 2011, Jared Mauch wrote:
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".
I don't agree at all. I have 3 /64s in use in my home already. I could fairly easily go down to 2, but I definitely need at least 2. I don't want to handle people like me differently, thus /56 for all residential customers makes a lot of sense. I see no downside. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Jan 27, 2011, at 11:32 AM, Mikael Abrahamsson wrote:
On Thu, 27 Jan 2011, Jared Mauch wrote:
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".
I don't agree at all. I have 3 /64s in use in my home already. I could fairly easily go down to 2, but I definitely need at least 2.
I don't want to handle people like me differently, thus /56 for all residential customers makes a lot of sense. I see no downside.
-- Mikael Abrahamsson email: swmike@swm.pp.se
The downside is that it doesn't provide enough bits for certain kinds of auto-topology management that are being considered by CE vendors. I highly recommend /48 instead. Owen
Hi Owen.
The downside is that it doesn't provide enough bits for certain kinds of auto-topology management that are being considered by CE vendors. I highly recommend /48 instead.
I've seen this claim (you need a /48) from your side several times, but never seen any explanation why a /56 won't work. Is there any requirement that sub-delegations must happen on 8-bit boundaries? AFAICS there is at least nothing in the RFC. Wouldn't for example a nibble boundary work equally well (splitting a /56 into 16 /60s, each containing 16 /64s)? I don't challenge the claim, I'm just trying to understand the rationale behind it. -- Pelle RFC1925, truth 11: Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
In message <AANLkTinDQdH5Z==mbYvm-OstA2m-WVkxo7vKyLc8x7vf@mail.gmail.com>, Per Carlson writes:
Hi Owen.
The downside is that it doesn't provide enough bits for certain kinds of = auto-topology management that are being considered by CE vendors. I highly recommend /4= 8 instead.
I've seen this claim (you need a /48) from your side several times, but never seen any explanation why a /56 won't work.
Is there any requirement that sub-delegations must happen on 8-bit boundaries? AFAICS there is at least nothing in the RFC. Wouldn't for example a nibble boundary work equally well (splitting a /56 into 16 /60s, each containing 16 /64s)?
I don't challenge the claim, I'm just trying to understand the rationale behind it.
There is a model where the down stream CPE devices always request powers of two prefixes. It doesn't take many CPE devices daisy chained to exhaust 8 bits. The other model is to just request as many /64 as needed using multiple requests with different identifiers. You can daisy chain out past the limits of IPv6 to route packets with that model. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, Jan 27, 2011 at 8:49 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote: 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.
No... they are not.. the /56 assignments are for all types of end sites, whether business or not. What makes a service "business class" or not has nothing directly to do with the number of IP addresses used. The only reason more IP addresses available was associated with higher classes of service in IPv4, and different end sites had different sizes of assignments, was because IP addresses were so scarce, and costly. Business class connections provide data rates suitable for larger networks, or generally come with SLAs; committed data rates, or assurances of reliability. The IP addressing needed for hosts is independent of the class of service. Under IPv6; it should be possible to upgrade service levels, or add networks, with no renumbering, or extra work required by the ISP to allocate more subnets. The /48 end-site assignments help future proof the LAN and help avoid the need to ever renumber to add subnets or to add discontinuous ones (aside from changing ISPs).
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".
98% of home users could probably live with _one_ IP address behind a NAT router; heck, most of them are doing just that with IPv4. Heck... most could probably live with 8 TCP port numbers and 8 UDP port numbers. What a waste of bits to give residential users 16-bit port numbers. Transition to IPv6 is not about what users can "live with" using current technology. The /48 end site assignments is supposed to provide opportunity for new technologies to be developed and provide useful innovations. Your wildest dreams are pretty limited, if you can't think of any way the additional subnets can be useful. Security and logical division are a few ideas. You might not care to do that now... but in 20 years, when you have 100000 smart chip / IP-based home automation enabled devices on your LAN. Subnetting starts to look more attractive; especially if common routers get the ability to do it automatically, and implement some passive isolation-based security mechanisms.
- Jared -JH
On 1/27/2011 7:03 PM, Jimmy Hess wrote:
Security and logical division are a few ideas. You might not care to do that now... but in 20 years, when you have 100000 smart chip / IP-based home automation enabled devices on your LAN.
My helpdesk decided to counter with "We'll run out because of the nanobots we'll be injected with to cure cancer and other diseases." They just don't understand the fact that a single /64 network is plenty to handle all the nanobots in the human body (supposing we're still going to be human). Of course, the nanobots really do need their own isolated subnet. They do a lot of multicast, I'm guessing. Jack
On 1/25/2011 10:19, Max Pierson wrote:
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?
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).
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
On Tue, 25 Jan 2011 12:19:34 -0600 Max Pierson <nmaxpierson@gmail.com> 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.
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
TIA, Max
At 22-07-28164 20:59, Max Pierson wrote:
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?
Hi Max, There is a Wikipedia article all about that: http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_pro... And here is some more information about subnetting your IPv6 network: http://en.wikipedia.org/wiki/IPv6_subnetting_reference
participants (16)
-
bmanning＠vacation.karoshi.com -
George Bonser -
Jack Bates -
Jared Mauch -
Jimmy Hess -
Justin M. Streiner -
Mark Andrews -
Mark Smith -
Max Pierson -
Michiel Klaver -
Mikael Abrahamsson -
Owen DeLong -
Per Carlson -
Roland Dobbins -
Seth Mattinen -
Valdis.Kletnieks＠vt.edu