Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

Mailman List Mirror (Read Only)
1

Rob Seastrom wrote:

"Ricky Beam" <jfbeam at gmail.com<http://mailman.nanog.org/mailman/listinfo/nanog&gt;&gt;
writes:
>
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com
<http://mailman.nanog.org/mailman/listinfo/nanog&gt;&gt; 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

2

Brian Dickson <brian.peter.dickson@gmail.com> writes:

Rob Seastrom wrote:

"Ricky Beam" <jfbeam at gmail.com<http://mailman.nanog.org/mailman/listinfo/nanog&gt;&gt;
writes:
>
* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com
<http://mailman.nanog.org/mailman/listinfo/nanog&gt;&gt; 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. :slight_smile:

-r

3

16384 'isp' which is really 'transit asn' right?

4

Brian Dickson <brian.peter.dickson@gmail.com> writes:

> Rob Seastrom wrote:
>
>> "Ricky Beam" <jfbeam at gmail.com<
http://mailman.nanog.org/mailman/listinfo/nanog&gt;&gt;
>> writes:
>> >
>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com
>> <http://mailman.nanog.org/mailman/listinfo/nanog&gt;&gt; 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. :slight_smile:

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

5

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

6

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

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

7

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.

8

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

9

Rob Seastrom wrote:

"Ricky Beam" <jfbeam at gmail.com<http://mailman.nanog.org/mailman/listinfo/nanog&gt;&gt;
writes:

* On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at seastrom.com
<http://mailman.nanog.org/mailman/listinfo/nanog&gt;&gt; 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

10

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.

11

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

12

where does the 1M come from?

13

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

Owen

14

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

15

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.

16

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)