Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)
Rob Seastrom wrote:
"Ricky Beam" <jfbeam at gmail.com<http://mailman.nanog.org/mailman/listinfo/nanog>> writes:
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com <http://mailman.nanog.org/mailman/listinfo/nanog>> wrote: *>> * So there really is no excuse on AT&T's part for the /60s on uverse 6rd... *> * ... *> * Handing out /56's like Pez is just wasting address space -- someone *> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> * networks when they're only ever likely to use one or two (or maybe *> * four), is intentionally wasting space you could've assigned to *> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> * the power of huge, but it's still finite. People like you are *> * repeating the same mistakes from the early days of IPv4... * There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Now give such a phone to every human on the face of the earth. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. -r
Here's the problem with the math, presuming everyone gets roughly the same answer: The efficiency (number of prefixes vs total space) is only achieved if there is a "flat" network, which carries every IPv6 prefix (i.e. that there is no aggregation being done). This means 1:1 router slots (for routes) vs prefixes, globally, or even internally on ISP networks. If any ISP has > 1M customers, oops. So, we need to aggregate. Basically, the problem space (waste) boils down to the question, "How many levels of aggregation are needed"? If you have variable POP sizes, region sizes, and assign/aggregate towards customers topologically, the result is: - the need to maintain power-of-2 address block sizes (for aggregation), plus - the need to aggregate at each level (to keep #prefixes sane) plus - asymmetric sizes which don't often end up being just short of the next power-of-2 - equals (necessarily) low utilization rates - i.e. much larger prefixes than would be suggested by "flat" allocation from a single pool. Here's a worked example, for a hypothetical big consumer ISP: - 22 POPs with "core" devices - each POP has anywhere from 2 to 20 "border" devices (feeding access devices) - each "border" has 5 to 100 "access" devices - each access device has up to 5000 customers Rounding up each, using max(count-per-level) as the basis, we get: 5000->8192 (2^13) 100->128 (2^7) 20->32 (2^5) 22->32 (2^5) 5+5+7+13=30 bits of aggregation 2^30 of /48 = /18 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. A thousand ISPs seems like a lot, but consider this: the ISP we did this for, might only have 3M customers. Scale this up (horizontally or vertically or both), and it is dangerously close to capacity already. The answer above (worked math) will be unique per ISP. It will also drive consumption at the apex, i.e. the size of allocations to ISPs. And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64. That's my 2 cents/observation. Brian
Brian Dickson <brian.peter.dickson@gmail.com> writes:
Rob Seastrom wrote:
"Ricky Beam" <jfbeam at gmail.com<http://mailman.nanog.org/mailman/listinfo/nanog>> writes:
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com <http://mailman.nanog.org/mailman/listinfo/nanog>> wrote: *>> * So there really is no excuse on AT&T's part for the /60s on uverse 6rd... *> * ... *> * Handing out /56's like Pez is just wasting address space -- someone *> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> * networks when they're only ever likely to use one or two (or maybe *> * four), is intentionally wasting space you could've assigned to *> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> * the power of huge, but it's still finite. People like you are *> * repeating the same mistakes from the early days of IPv4... * There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Now give such a phone to every human on the face of the earth. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. -r
Here's the problem with the math, presuming everyone gets roughly the same answer: The efficiency (number of prefixes vs total space) is only achieved if there is a "flat" network, which carries every IPv6 prefix (i.e. that there is no aggregation being done).
This means 1:1 router slots (for routes) vs prefixes, globally, or even internally on ISP networks.
If any ISP has > 1M customers, oops. So, we need to aggregate.
Basically, the problem space (waste) boils down to the question, "How many levels of aggregation are needed"?
If you have variable POP sizes, region sizes, and assign/aggregate towards customers topologically, the result is: - the need to maintain power-of-2 address block sizes (for aggregation), plus - the need to aggregate at each level (to keep #prefixes sane) plus - asymmetric sizes which don't often end up being just short of the next power-of-2 - equals (necessarily) low utilization rates - i.e. much larger prefixes than would be suggested by "flat" allocation from a single pool.
Here's a worked example, for a hypothetical big consumer ISP: - 22 POPs with "core" devices - each POP has anywhere from 2 to 20 "border" devices (feeding access devices) - each "border" has 5 to 100 "access" devices - each access device has up to 5000 customers
Rounding up each, using max(count-per-level) as the basis, we get: 5000->8192 (2^13) 100->128 (2^7) 20->32 (2^5) 22->32 (2^5) 5+5+7+13=30 bits of aggregation 2^30 of /48 = /18 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. A thousand ISPs seems like a lot, but consider this: the ISP we did this for, might only have 3M customers. Scale this up (horizontally or vertically or both), and it is dangerously close to capacity already.
The answer above (worked math) will be unique per ISP. It will also drive consumption at the apex, i.e. the size of allocations to ISPs.
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
That's my 2 cents/observation.
Brian
At a glance, I think there's an implicit assumption in your calculation that each ISP has to be able to hold the whole world (unlikely) and/or there is no such thing as mobile IP or any other kind of tunneling technology going on within the mobile network (also wrong from everything I understand). Also, I'm not sure where "from the current /8" comes from, as there's a /3 in play (1/8 of the total space, maybe that was it?) and each RIR is getting space in chunks of /12... Re-working your conclusion statement without redoing the math, "This leaves room for 2^15 such ISPs (a mere 16384), from the current /3." Oddly enough, I'm OK with that. :) -r
On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom <rs@seastrom.com> wrote:
Brian Dickson <brian.peter.dickson@gmail.com> writes:
Rob Seastrom wrote:
"Ricky Beam" <jfbeam at gmail.com<http://mailman.nanog.org/mailman/listinfo/nanog>> writes:
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com <http://mailman.nanog.org/mailman/listinfo/nanog>> wrote: *>> * So there really is no excuse on AT&T's part for the /60s on uverse 6rd... *> * ... *> * Handing out /56's like Pez is just wasting address space -- someone *> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> * networks when they're only ever likely to use one or two (or maybe *> * four), is intentionally wasting space you could've assigned to *> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> * the power of huge, but it's still finite. People like you are *> * repeating the same mistakes from the early days of IPv4... * There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Now give such a phone to every human on the face of the earth. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. -r
Here's the problem with the math, presuming everyone gets roughly the same answer: The efficiency (number of prefixes vs total space) is only achieved if there is a "flat" network, which carries every IPv6 prefix (i.e. that there is no aggregation being done).
This means 1:1 router slots (for routes) vs prefixes, globally, or even internally on ISP networks.
If any ISP has > 1M customers, oops. So, we need to aggregate.
Basically, the problem space (waste) boils down to the question, "How many levels of aggregation are needed"?
If you have variable POP sizes, region sizes, and assign/aggregate towards customers topologically, the result is: - the need to maintain power-of-2 address block sizes (for aggregation), plus - the need to aggregate at each level (to keep #prefixes sane) plus - asymmetric sizes which don't often end up being just short of the next power-of-2 - equals (necessarily) low utilization rates - i.e. much larger prefixes than would be suggested by "flat" allocation from a single pool.
Here's a worked example, for a hypothetical big consumer ISP: - 22 POPs with "core" devices - each POP has anywhere from 2 to 20 "border" devices (feeding access devices) - each "border" has 5 to 100 "access" devices - each access device has up to 5000 customers
Rounding up each, using max(count-per-level) as the basis, we get: 5000->8192 (2^13) 100->128 (2^7) 20->32 (2^5) 22->32 (2^5) 5+5+7+13=30 bits of aggregation 2^30 of /48 = /18 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. A thousand ISPs seems like a lot, but consider this: the ISP we did this for, might only have 3M customers. Scale this up (horizontally or vertically or both), and it is dangerously close to capacity already.
The answer above (worked math) will be unique per ISP. It will also drive consumption at the apex, i.e. the size of allocations to ISPs.
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
That's my 2 cents/observation.
Brian
At a glance, I think there's an implicit assumption in your calculation that each ISP has to be able to hold the whole world (unlikely) and/or there is no such thing as mobile IP or any other kind of tunneling technology going on within the mobile network (also wrong from everything I understand).
Also, I'm not sure where "from the current /8" comes from, as there's a /3 in play (1/8 of the total space, maybe that was it?) and each RIR is getting space in chunks of /12...
Re-working your conclusion statement without redoing the math, "This leaves room for 2^15 such ISPs (a mere 16384), from the current /3."
Oddly enough, I'm OK with that. :)
16384 'isp' which is really 'transit asn' right?
Not necessarily transit - leaf ASN ISP networks (which do IP transit for consumers, but do not have BGP customers) would also be counted in. They do still exist, right? Brian On Wed, Dec 4, 2013 at 1:35 PM, Christopher Morrow <morrowc.lists@gmail.com>wrote:
On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom <rs@seastrom.com> wrote:
Brian Dickson <brian.peter.dickson@gmail.com> writes:
Rob Seastrom wrote:
"Ricky Beam" <jfbeam at gmail.com<
writes:
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com <http://mailman.nanog.org/mailman/listinfo/nanog>> wrote: *>> * So there really is no excuse on AT&T's part for the /60s on uverse 6rd... *> * ... *> * Handing out /56's like Pez is just wasting address space -- someone *> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> * networks when they're only ever likely to use one or two (or maybe *> * four), is intentionally wasting space you could've assigned to *> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> * the power of huge, but it's still finite. People like you are *> * repeating the same mistakes from the early days of IPv4... * There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Now give such a phone to every human on the face of the earth. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. -r
Here's the problem with the math, presuming everyone gets roughly the same answer: The efficiency (number of prefixes vs total space) is only achieved if there is a "flat" network, which carries every IPv6 prefix (i.e. that there is no aggregation being done).
This means 1:1 router slots (for routes) vs prefixes, globally, or even internally on ISP networks.
If any ISP has > 1M customers, oops. So, we need to aggregate.
Basically, the problem space (waste) boils down to the question, "How many levels of aggregation are needed"?
If you have variable POP sizes, region sizes, and assign/aggregate towards customers topologically, the result is: - the need to maintain power-of-2 address block sizes (for aggregation), plus - the need to aggregate at each level (to keep #prefixes sane) plus - asymmetric sizes which don't often end up being just short of the next power-of-2 - equals (necessarily) low utilization rates - i.e. much larger prefixes than would be suggested by "flat" allocation from a single pool.
Here's a worked example, for a hypothetical big consumer ISP: - 22 POPs with "core" devices - each POP has anywhere from 2 to 20 "border" devices (feeding access devices) - each "border" has 5 to 100 "access" devices - each access device has up to 5000 customers
Rounding up each, using max(count-per-level) as the basis, we get: 5000->8192 (2^13) 100->128 (2^7) 20->32 (2^5) 22->32 (2^5) 5+5+7+13=30 bits of aggregation 2^30 of /48 = /18 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. A thousand ISPs seems like a lot, but consider this: the ISP we did this for, might only have 3M customers. Scale this up (horizontally or vertically or both), and it is dangerously close to capacity already.
The answer above (worked math) will be unique per ISP. It will also drive consumption at the apex, i.e. the size of allocations to ISPs.
And root of the problem was brought into existence by the insistence
http://mailman.nanog.org/mailman/listinfo/nanog>> that
every network (LAN) must be a /64.
That's my 2 cents/observation.
Brian
At a glance, I think there's an implicit assumption in your calculation that each ISP has to be able to hold the whole world (unlikely) and/or there is no such thing as mobile IP or any other kind of tunneling technology going on within the mobile network (also wrong from everything I understand).
Also, I'm not sure where "from the current /8" comes from, as there's a /3 in play (1/8 of the total space, maybe that was it?) and each RIR is getting space in chunks of /12...
Re-working your conclusion statement without redoing the math, "This leaves room for 2^15 such ISPs (a mere 16384), from the current /3."
Oddly enough, I'm OK with that. :)
16384 'isp' which is really 'transit asn' right?
On Wed, Dec 4, 2013 at 2:25 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Not necessarily transit - leaf ASN ISP networks (which do IP transit for consumers, but do not have BGP customers) would also be counted in. They do still exist, right?
that's still a transit as, right? I think your math means that there would only ever be 16k networks.. which seems small.
On Wed, Dec 4, 2013 at 1:35 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom <rs@seastrom.com> wrote:
Brian Dickson <brian.peter.dickson@gmail.com> writes:
Rob Seastrom wrote:
"Ricky Beam" <jfbeam at gmail.com<http://mailman.nanog.org/mailman/listinfo/nanog>> writes:
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com <http://mailman.nanog.org/mailman/listinfo/nanog>> wrote: *>> * So there really is no excuse on AT&T's part for the /60s on uverse 6rd... *> * ... *> * Handing out /56's like Pez is just wasting address space -- someone *> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> * networks when they're only ever likely to use one or two (or maybe *> * four), is intentionally wasting space you could've assigned to *> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> * the power of huge, but it's still finite. People like you are *> * repeating the same mistakes from the early days of IPv4... * There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Now give such a phone to every human on the face of the earth. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. -r
Here's the problem with the math, presuming everyone gets roughly the same answer: The efficiency (number of prefixes vs total space) is only achieved if there is a "flat" network, which carries every IPv6 prefix (i.e. that there is no aggregation being done).
This means 1:1 router slots (for routes) vs prefixes, globally, or even internally on ISP networks.
If any ISP has > 1M customers, oops. So, we need to aggregate.
Basically, the problem space (waste) boils down to the question, "How many levels of aggregation are needed"?
If you have variable POP sizes, region sizes, and assign/aggregate towards customers topologically, the result is: - the need to maintain power-of-2 address block sizes (for aggregation), plus - the need to aggregate at each level (to keep #prefixes sane) plus - asymmetric sizes which don't often end up being just short of the next power-of-2 - equals (necessarily) low utilization rates - i.e. much larger prefixes than would be suggested by "flat" allocation from a single pool.
Here's a worked example, for a hypothetical big consumer ISP: - 22 POPs with "core" devices - each POP has anywhere from 2 to 20 "border" devices (feeding access devices) - each "border" has 5 to 100 "access" devices - each access device has up to 5000 customers
Rounding up each, using max(count-per-level) as the basis, we get: 5000->8192 (2^13) 100->128 (2^7) 20->32 (2^5) 22->32 (2^5) 5+5+7+13=30 bits of aggregation 2^30 of /48 = /18 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. A thousand ISPs seems like a lot, but consider this: the ISP we did this for, might only have 3M customers. Scale this up (horizontally or vertically or both), and it is dangerously close to capacity already.
The answer above (worked math) will be unique per ISP. It will also drive consumption at the apex, i.e. the size of allocations to ISPs.
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
That's my 2 cents/observation.
Brian
At a glance, I think there's an implicit assumption in your calculation that each ISP has to be able to hold the whole world (unlikely) and/or there is no such thing as mobile IP or any other kind of tunneling technology going on within the mobile network (also wrong from everything I understand).
Also, I'm not sure where "from the current /8" comes from, as there's a /3 in play (1/8 of the total space, maybe that was it?) and each RIR is getting space in chunks of /12...
Re-working your conclusion statement without redoing the math, "This leaves room for 2^15 such ISPs (a mere 16384), from the current /3."
Oddly enough, I'm OK with that. :)
16384 'isp' which is really 'transit asn' right?
On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom <rs@seastrom.com> wrote:
Brian Dickson <brian.peter.dickson@gmail.com> writes:
Rob Seastrom wrote:
"Ricky Beam" <jfbeam at gmail.com< http://mailman.nanog.org/mailman/listinfo/nanog>> writes:
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com <http://mailman.nanog.org/mailman/listinfo/nanog>> wrote: *>> * So there really is no excuse on AT&T's part for the /60s on uverse 6rd... *> * ... *> * Handing out /56's like Pez is just wasting address space -- someone *> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> * networks when they're only ever likely to use one or two (or maybe *> * four), is intentionally wasting space you could've assigned to *> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> * the power of huge, but it's still finite. People like you are *> * repeating the same mistakes from the early days of IPv4... * There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Now give such a phone to every human on the face of the earth. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. -r
Here's the problem with the math, presuming everyone gets roughly the same answer: The efficiency (number of prefixes vs total space) is only achieved if there is a "flat" network, which carries every IPv6 prefix (i.e. that there is no aggregation being done).
This means 1:1 router slots (for routes) vs prefixes, globally, or even internally on ISP networks.
If any ISP has > 1M customers, oops. So, we need to aggregate.
Basically, the problem space (waste) boils down to the question, "How many levels of aggregation are needed"?
If you have variable POP sizes, region sizes, and assign/aggregate towards customers topologically, the result is: - the need to maintain power-of-2 address block sizes (for aggregation), plus - the need to aggregate at each level (to keep #prefixes sane) plus - asymmetric sizes which don't often end up being just short of the next power-of-2 - equals (necessarily) low utilization rates - i.e. much larger prefixes than would be suggested by "flat" allocation from a single pool.
Here's a worked example, for a hypothetical big consumer ISP: - 22 POPs with "core" devices - each POP has anywhere from 2 to 20 "border" devices (feeding access devices) - each "border" has 5 to 100 "access" devices - each access device has up to 5000 customers
Rounding up each, using max(count-per-level) as the basis, we get: 5000->8192 (2^13) 100->128 (2^7) 20->32 (2^5) 22->32 (2^5) 5+5+7+13=30 bits of aggregation 2^30 of /48 = /18 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. A thousand ISPs seems like a lot, but consider this: the ISP we did this for, might only have 3M customers. Scale this up (horizontally or vertically or both), and it is dangerously close to capacity already.
The answer above (worked math) will be unique per ISP. It will also drive consumption at the apex, i.e. the size of allocations to ISPs.
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
That's my 2 cents/observation.
Brian
At a glance, I think there's an implicit assumption in your calculation that each ISP has to be able to hold the whole world (unlikely) and/or there is no such thing as mobile IP or any other kind of tunneling technology going on within the mobile network (also wrong from everything I understand).
No, not the whole world, just that the combo of internal+external has to fit. If internal breaks the table, external is irrelevant, and flat/unaggregated would do that. As for tunneling - not sure that will hold forever, especially depending on the degree of stretch (contributes to latency and bandwidth doubling).
Also, I'm not sure where "from the current /8" comes from, as there's a /3 in play (1/8 of the total space, maybe that was it?) and each RIR is getting space in chunks of /12...
Doh! (I knew there was an "8" involved - need more caffeine). You're right, of course.
Re-working your conclusion statement without redoing the math, "This leaves room for 2^15 such ISPs (a mere 16384), from the current /3."
Oddly enough, I'm OK with that. :)
It's not dire, but I'd be more comfortable with a few more zeros in there (even one more zero). But my point was that every 10* multiplier is 2^3-ish, and in order to get to the numbers you were pointing to, there are several of those involved. E.g. In order to provide 68B instead of 3M, which my math worked out to, that is 23000-ish bigger. That is any combination of more and/or bigger ISPs. Flatter networks (mobile) helps, but to what degree will fixed non-tunnel ISPs contribute, is the real question? What percentage of 68B will have non-wireless service(s)? Brian
Brian Dickson wrote:
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
Get your history straight. The /64 was an outcome of operators deciding there was not enough room for hierarchy in the original proposal for the IPv6 address as 64 bits (including hosts), despite its ability to deliver 3 orders of magnitude more than the IAB goal statement. Given that position, the entire 64 bits was given to *ROUTING* and we argued for another year about how many bits to add for hosts on the lan. The fact it came out to 64 was an artifact of emerging 64 bit processors and the desire to avoid any more bit shifting than necessary. Yes, autoconfig using the mac was a consideration, but that was a convenient outcome, not the driving factor. Yet here we are 15 years later and the greedy, or math challenged, still insist on needing even more bits. Stop worrying about how many bits there are in the lan space. That abundance allows for technical innovation that will never be possible in the stingy world of centralized control. Consider a world where the 'central control' crowd only allows one application on the network (voice), and innovation is defined as 'only deploy something with an immediate income stream' (caller id). In an environment like that, were do new things come from? You can't prove a demand exists without deployment, yet you can't get deployment without a proven demand. Enter the ott Internet which leveraged the only allowed app via an audio modulation hack and built something entirely different, where innovation was allowed to flourish. Now go back to the concept of miserly central control of lan bits and figure out how one might come up with something like RFC3971 (SEND) that would work in any network. Rob Seastrom wrote:
Re-working your conclusion statement without redoing the math, "This leaves room for 2^15 such ISPs (a mere 16384), from the current /3."
Interesting; that was the IAB design goal for total end system count. >>> 2^12 networks supporting 2^15 end systems.
Oddly enough, I'm OK with that. :)
So am I, and if we do burn through that before a replacement network technology comes along, there are still 6 more buckets that large to do it differently. Tony
On Wed, Dec 4, 2013 at 2:34 PM, Tony Hain <alh-ietf@tndh.net> wrote:
Brian Dickson wrote:
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
[snip]
about how many bits to add for hosts on the lan. The fact it came out to 64
The point I'm making (and have made before), is not how many bits, but that it is a fixed number (64). And again, the concern isn't about bits, it is about slots in routing tables. Routing table hardware is generally: (a) non-upgradeable in currently deployed systems, and (b) very very expensive (at least for TCAMs). (c) for lots of routers, is per-linecard (not per-router) cost If you look back at the need for CIDR (where we went from class A, B, and C to variable-length subnet masks), it might be a bit more obvious. CIDR fixed the total number of available routes problem, but fundamentally cannot do anything about # route slots. Fixed sizes do not have the scalability that variable sizes do, when it comes to networks, even within a fixed total size (network + host). Variable sizes are needed for aggregation, which is the only solution to router slot issues. IF deployed by operators correctly, the global routing table should be 1 IPv6 route per ASN. However, that is only feasible if each ASN can efficiently aggregate forever (or 50 years at least). The math shows that 61 bits, given out in 16-bit chunks to end users, when aggregation is used hierarchically, runs the risk of not lasting 50 years. [snip]
Now go back to the concept of miserly central control of lan bits and figure out how one might come up with something like RFC3971 (SEND) that would work in any network.
There are two really easy ways, just off the top of my head: (1) prefix delegation. Host wanting SEND asks its upstream router to delegate a prefix of adequate size. The prefix is routed to the host, with only the immediate upstream router knowing the host's non-SEND address. The host picks SEND addresses from the prefix, rotates whenever it wants, problem solved. QED. (2) pass the prefix size to the host. Have the SEND math use whatever scheme it wants, modulo that size. E.g. rand(2**64-1) -> rand(2**prefix_size-1). Host redoes this whenever it changes addresses, problem solved. QED. (The question of how much space is adequate for the protection offered by SEND. I suggest that 32 bits as a minimum, would still be adequate.) As far as I have been able to determine, there are very few places where fixed /64 (as a requirement) actually makes sense. For example, the code for IPv6 on Linux, basically does "check that we're /64 and if not fail", but otherwise has no /64 dependencies. We can always do an IPv6-bis in future, to first fix SEND, then fix autoconf, and finally remove /64 from IPv6 -- if we think the usage rate justifies doing so. Brian
On Wed, Dec 4, 2013 at 3:04 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
IF deployed by operators correctly, the global routing table should be 1 IPv6 route per ASN. However, that is only feasible if each ASN can efficiently aggregate forever (or 50 years at least).
and if your capacity between 2 asn endpoints is always able to handle the traffic load offered, right? else you start having to traffic-engineer... which today means deaggregate (or announce some more specifics along with the aggregate). I'm not sure I'd make a bet that I can always have enough capacity between any two asn endpoints that I wouldn't need to TE.
On Dec 4, 2013, at 10:21 , Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Rob Seastrom wrote:
"Ricky Beam" <jfbeam at gmail.com<http://mailman.nanog.org/mailman/listinfo/nanog>> writes:
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com <http://mailman.nanog.org/mailman/listinfo/nanog>> wrote: *>> * So there really is no excuse on AT&T's part for the /60s on uverse 6rd... *> * ... *> * Handing out /56's like Pez is just wasting address space -- someone *> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> * networks when they're only ever likely to use one or two (or maybe *> * four), is intentionally wasting space you could've assigned to *> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> * the power of huge, but it's still finite. People like you are *> * repeating the same mistakes from the early days of IPv4... * There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Now give such a phone to every human on the face of the earth. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. -r
Here's the problem with the math, presuming everyone gets roughly the same answer: The efficiency (number of prefixes vs total space) is only achieved if there is a "flat" network, which carries every IPv6 prefix (i.e. that there is no aggregation being done).
Yes, but since our most exaggerated estimates only got to a /11, you can do up to 256x in waste in order to support aggregation and still fit within 2000::/3 (1/8th of the total address space).
This means 1:1 router slots (for routes) vs prefixes, globally, or even internally on ISP networks.
If any ISP has > 1M customers, oops. So, we need to aggregate.
Basically, the problem space (waste) boils down to the question, "How many levels of aggregation are needed"?
I argue that much of the waste needed for aggregation is available in the amount by which the model for the number of required is included in the pre-existing exaggeration of the model. However, there's still a 256x factor within 2000::/3 that can also absorb aggregation costs.
If you have variable POP sizes, region sizes, and assign/aggregate towards customers topologically, the result is: - the need to maintain power-of-2 address block sizes (for aggregation), plus - the need to aggregate at each level (to keep #prefixes sane) plus - asymmetric sizes which don't often end up being just short of the next power-of-2 - equals (necessarily) low utilization rates - i.e. much larger prefixes than would be suggested by "flat" allocation from a single pool.
Here's a worked example, for a hypothetical big consumer ISP: - 22 POPs with "core" devices - each POP has anywhere from 2 to 20 "border" devices (feeding access devices) - each "border" has 5 to 100 "access" devices - each access device has up to 5000 customers
But you don't have to (or even usually want to) aggregate at all of those levels.
Rounding up each, using max(count-per-level) as the basis, we get: 5000->8192 (2^13) 100->128 (2^7) 20->32 (2^5) 22->32 (2^5) 5+5+7+13=30 bits of aggregation 2^30 of /48 = /18 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. A thousand ISPs seems like a lot, but consider this: the ISP we did this for, might only have 3M customers. Scale this up (horizontally or vertically or both), and it is dangerously close to capacity already.
First of all, you are mistaken. There is no current /8, it's a /3, so there's room for 32 times that (32,768 such ISPs). Second of all, what would make much more sense in your scenario is to aggregate at one or two of those levels. I'd expect probably the POP and the Border device levels most likely, so what you're really looking at is 5000*100 = 500,000 /48s per border. To make this even, we'll round that up to 524,288 (2^19) and actually to make life easy, let's take that to a nibble boundary (2^20) 1,048,576, which gives us a /28 per Border Device. Now aggregating POPs, we have 22*20 border devices which fits in 8 bits, so we can build this ISP in a /20 quite easily. That leaves us 17 bits in the current /3 for assigning ISPs of this size (note, this is quite the sizeable ISP since we're supporting 220,000,000 customers in your count. Even so, since they only need a /20, I think that's OK. We've got room to support enough of those ISPs that even if they only have 3 million customers, since we can support 131,072 such ISPs in the current /3, that gives us the ability to address a total of 393,216,000,000 total customers. There are approximately 6,800,000,000 People on the planet, so we have almost 60x as many ISPs as we would possibly need.
The answer above (worked math) will be unique per ISP. It will also drive consumption at the apex, i.e. the size of allocations to ISPs.
Sure, but doing aggregation in the least efficient possible way against inflated numbers and you were still barely able to make it be a problem by dividing the currently available address space by 256 and ignoring the fact that the currently available address space is only 1/8th of the total address space.
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
Not really. The original plan was for everything to be 64 bits, so by adding another 64 bits and making every network a /64, we're actually better off than we would have been if we'd just gone to 64 bit addresses in toto. Thanks for playing. Owen
On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong <owen@delong.com> wrote:
On Dec 4, 2013, at 10:21 , Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Second of all, what would make much more sense in your scenario is to aggregate at one or two of those levels. I'd expect probably the POP and the Border device levels most likely, so what you're really looking at is 5000*100 = 500,000 /48s per border. To make this even, we'll round that up to 524,288 (2^19) and actually to make life easy, let's take that to a nibble boundary (2^20) 1,048,576, which gives us a /28 per Border Device.
Except that we have a hard limit of 1M total, which after a few 100K from the global routing tables (IPv4+IPv6), this 500,000 looks pretty dicey.
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
Not really. The original plan was for everything to be 64 bits, so by adding another 64 bits and making every network a /64, we're actually better off than we would have been if we'd just gone to 64 bit addresses in toto.
Thanks for playing.
Owen
Understand, I am not saying anyone got it wrong, but rather, that there is
a risk associated with continuing forever to use a /64 fixed LAN size. Yes, we are better than we were, but the point I'm making is, if push comes to shove, that the /64 is a small thing to sacrifice (at very small incremental cost, SEND + AUTOCONF modifications). I can't believe I just called 2**64 small. Brian
On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow <morrowc.lists@gmail.com>wrote:
On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Except that we have a hard limit of 1M total, which after a few 100K from
where does the 1M come from?
FIB table sizes, usually dictated by TCAM size. Think deployed hardware, lots of it. (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6 taking two slots of TCAM, IIRC. And a few other things also consume TCAM, maybe not as significantly.) (Newer boxes may handle more on some network's cores, but I don't believe it is ubiquitously the case across the DFZ.) Brian
On 12/4/13, 12:58 PM, Brian Dickson wrote:
On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow <morrowc.lists@gmail.com>wrote:
On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Except that we have a hard limit of 1M total, which after a few 100K from
where does the 1M come from?
FIB table sizes, usually dictated by TCAM size. Think deployed hardware, lots of it. (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6 taking two slots of TCAM, IIRC. And a few other things also consume TCAM, maybe not as significantly.)
(Newer boxes may handle more on some network's cores, but I don't believe it is ubiquitously the case across the DFZ.)
Table size growth has conveniently not outstripped the growth of available fib sizes in a quite a long time. There doesn't appear to be much reason to believe that won't continue baring us coming up with novel ways to blow up the size of the DFZ. Managing to aggregate in some way that respects your internal topology and addressing plan without blowing up your route count is an exercise for the reader. It's somewhat facile to relate fib size to the bounds of what ternary cam chips you can currently buy since not all routers use cams for longest match lookups.
Brian
On Wed, Dec 4, 2013 at 3:58 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Except that we have a hard limit of 1M total, which after a few 100K from
where does the 1M come from?
FIB table sizes, usually dictated by TCAM size. Think deployed hardware, lots of it. (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6 taking two slots of TCAM, IIRC. And a few other things also consume TCAM, maybe not as significantly.)
(Newer boxes may handle more on some network's cores, but I don't believe it is ubiquitously the case across the DFZ.)
ok, that's fair... but in ~5yrs time we'll work ourslves out of the 1M mark, right? to 5M or 10M? (or something more than 1M)
On Dec 4, 2013, at 12:43 , Brian Dickson <brian.peter.dickson@gmail.com> wrote:
On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong <owen@delong.com> wrote:
On Dec 4, 2013, at 10:21 , Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Second of all, what would make much more sense in your scenario is to aggregate at one or two of those levels. I'd expect probably the POP and the Border device levels most likely, so what you're really looking at is 5000*100 = 500,000 /48s per border. To make this even, we'll round that up to 524,288 (2^19) and actually to make life easy, let's take that to a nibble boundary (2^20) 1,048,576, which gives us a /28 per Border Device.
Except that we have a hard limit of 1M total, which after a few 100K from the global routing tables (IPv4+IPv6), this 500,000 looks pretty dicey.
Only if you feel the need to carry those global routes all the way down to your border devices (which is unlikely in the kind of residential scenario proposed).
And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64.
Not really. The original plan was for everything to be 64 bits, so by adding another 64 bits and making every network a /64, we're actually better off than we would have been if we'd just gone to 64 bit addresses in toto.
Thanks for playing.
Owen
Understand, I am not saying anyone got it wrong, but rather, that there is a risk associated with continuing forever to use a /64 fixed LAN size. Yes, we are better than we were, but the point I'm making is, if push comes to shove, that the /64 is a small thing to sacrifice (at very small incremental cost, SEND + AUTOCONF modifications).
I think it is already too entrenched to change, but I guess time will tell. Since we are only talking about how we use the first 1/8th of the address space and we didn't even exhaust that in your particularly overblown example, I am unconcerned.
I can't believe I just called 2**64 small.
Well, it's smaller than 2^128. ;-) Owen
participants (6)
-
Brian Dickson -
Christopher Morrow -
joel jaeggli -
Owen DeLong -
Rob Seastrom -
Tony Hain