Weekly Routing Table Report

Mailman List Mirror (Read Only)
1

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz@gmail.com>.

Routing Table Report 04:00 +10GMT Sat 31 Aug, 2019

Report Website: http://thyme.rand.apnic.net
Detailed Analysis: http://thyme.rand.apnic.net/current/

Analysis Summary

2

A very long time ago, I commented on this report hitting 250,000 prefixes. It was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow….

Then I did it again at 500,000. People commented that I should have waited for 512,000 - especially since a popular piece of kit was expected to fall over at 512K prefixes. But I said I liked round numbers.

This time I waited for 768,000. (Everyone happy now?)

To say “the Internet grew more than anyone expected” is beyond cliché these days, but that does not make it any less true. The Internet has transformed from a curiosity into something my son[*] and a good portion of his entire generation cannot conceive of living without. A great many people on this list had a part in making all that happen.

Stop and think about that for a second. You had a part in literally changing the world.

It is a 3-day weekend in the US. A good time to pause for a few minutes and consider what all of us accomplished together. Pat yourselves on the back, raise a glass or whatever your personal traditions are, and bask in the glory of a job well done.

3

These numbers are nothing. Wait till IPv6 really start taking off.

4

The hope is the v6 DFZ will not grow nearly as fast because of far less fragmentation.

But who knows?

Also, even today TCAM ain’t cheap. Let’s hope it those numbers are not “nothing”.

5

It doesn't bode well with deaggregation in IPv6 going down to the /48 in
places I see it happen. A large chunk of the /48s out there are from
/32s. If that carries on, we'll have to be more afraid then I remember
us being at 30k IPv4 prefixes, 100k IPv4 prefixes, etc. :frowning:

Actually when I started doing this back in early 1999, it was to
supplement with a regional view of what Tony Bates was producing in the
CIDR Report. Sloppy code on my part back then as we didn't have "too
many prefixes". Didn't think I'd be doing this still, and have had to
sort the code many times since too. :slight_smile:

philip

6

No, actually!

I came on board when there were about 32,000 prefixes and we were
panicked about that. "CIDRize or die", I think Sean Doran said. I
remember well the memory and cam struggles to keep up with growth. Its
phenomenal, yes, but also, "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE
ANYMORE???"

:slight_smile:

-Wayne

7

Patrick W. Gilmore wrote:

The hope is the v6 DFZ will not grow nearly as fast because of far
less fragmentation.

As the problem is caused by multihomed sites (including ISPs), there
is no such hope.

With the current way of multihoming to compute available routes to
multihomed sites by global routing system, the load, including routing
table size, to the global routing system increases at least linearly
to the number of multihomed sites.

Some people was aware of the problem when the size was 50,000.

With the current routing practice, the number will increase to 14M
with IPv4 and a lot more than that with IPv6.

The solution is:

  https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

but IETF is working on stupid things like LISP only to increase
load to the global routing system.

Also, even today TCAM ain’t cheap. Let’s hope it those numbers are
not "nothing".

The problem is serious especially because Moore's law is ending.

            Masataka Ohta

8

Some of us had a part in literally creating TheWorld(.com) :slight_smile:

9

Patrick W. Gilmore wrote:

The hope is the v6 DFZ will not grow nearly as fast because of far
less fragmentation.

As the problem is caused by multihomed sites (including ISPs), there
is no such hope.

Part of the problem is caused by multi homed sites. Much more of the problem is actually
caused by organizations needing multiple prefixes acquired over time through IPv4 slow
start and other similar rationing mechanisms deployed to try and create a fair allocation
strategy in light of IPv4 scarcity.

Consider, for example AS7922 which originates the following 124 prefixes according to
route-views:

23.7.80.0/20
23.24.0.0/15
23.30.0.0/15
23.33.186.0/24
23.40.176.0/20
23.41.0.0/20
23.49.56.0/24
23.58.92.0/24
23.67.49.0/24
23.68.0.0/14
23.194.116.0/22
23.213.134.0/23
23.217.129.0/24
24.0.0.0/12
24.16.0.0/13
24.30.0.0/17
24.34.0.0/16
24.40.0.0/18
24.40.64.0/20
24.60.0.0/14
24.91.0.0/16
24.98.0.0/15
24.104.0.0/17
24.104.128.0/19
24.118.0.0/16
24.124.128.0/17
24.125.0.0/16
24.126.0.0/15
24.128.0.0/16
24.129.0.0/17
24.130.0.0/15
24.147.0.0/16
24.153.64.0/19
24.218.0.0/16
24.245.0.0/18
50.73.0.0/16
50.76.0.0/14
50.128.0.0/9
50.227.16.0/22
50.227.20.0/22
64.56.32.0/19
64.139.64.0/19
65.34.128.0/17
65.96.0.0/16
66.30.0.0/15
66.41.0.0/16
66.56.0.0/18
66.176.0.0/15
66.208.192.0/18
66.229.0.0/16
66.240.0.0/18
67.160.0.0/11
68.32.0.0/11
68.80.0.0/13
68.86.80.0/20
69.136.0.0/13
69.180.0.0/15
69.240.0.0/12
70.88.0.0/14
71.24.0.0/14
71.56.0.0/13
71.192.0.0/12
71.224.0.0/12
72.55.0.0/17
72.247.190.0/24
74.16.0.0/12
74.92.0.0/14
74.144.0.0/12
75.64.0.0/13
75.72.0.0/15
75.74.0.0/16
75.75.0.0/17
75.75.128.0/18
75.144.0.0/13
76.16.0.0/12
76.96.0.0/11
76.128.0.0/11
96.6.80.0/20
96.17.145.0/24
96.17.164.0/24
96.17.165.0/24
96.17.166.0/24
96.64.0.0/11
96.96.0.0/12
96.112.0.0/13
96.120.0.0/14
96.124.0.0/16
96.128.0.0/10
96.192.0.0/11
98.32.0.0/11
98.192.0.0/10
104.69.216.0/22
104.69.220.0/23
104.70.48.0/20
104.70.64.0/20
104.70.178.0/24
104.77.121.0/24
104.77.150.0/24
104.109.53.0/24
107.0.0.0/14
107.4.0.0/15
162.148.0.0/14
173.8.0.0/13
173.160.0.0/13
173.222.176.0/22
174.48.0.0/12
174.160.0.0/11
184.25.157.0/24
184.28.64.0/23
184.28.68.0/23
184.28.117.0/24
184.51.52.0/22
184.51.207.0/24
184.86.251.0/24
184.108.0.0/14
184.112.0.0/12
198.0.0.0/16
198.137.252.0/23
198.178.8.0/21
204.11.116.0/22
208.39.128.0/18
209.23.192.0/22
209.23.192.0/18
216.45.128.0/17

A quick scan didn’t reveal significant overlap or even a lot of adjacent prefixes. As such, I don’t think you can blame multihoming or TE for this, but, rather organic customer growth and RIR applications over time.

That’s the kind of prefix growth we should be able to mostly avoid in IPv6 that is rather rampant in IPv4.

With the current way of multihoming to compute available routes to
multihomed sites by global routing system, the load, including routing
table size, to the global routing system increases at least linearly
to the number of multihomed sites.

Sure, but the number of multi homed sites is way WAY less than the IPv4 routing table size.

Some people was aware of the problem when the size was 50,000.

When the size was 50,000, that was the primary source of the problem. Today, long prefixes issued due to scarcity constitute a much larger fraction of the problem than multi homed sites originating single prefixes.

With the current routing practice, the number will increase to 14M
with IPv4 and a lot more than that with IPv6.

I’m curious as to why you think that the number is bounded at 14M for IPv4 and why you think there will be so many more multi homed sites in IPv6?

The solution is:

https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

but IETF is working on stupid things like LISP only to increase
load to the global routing system.

Not that you’d be prejudiced in favor of your own draft or anything.

Also, even today TCAM ain’t cheap. Let’s hope it those numbers are
not “nothing”.

The problem is serious especially because Moore’s law is ending.

People have been claiming that Moore’s law is at an end longer than we have been pushing for IPv6 deployment.

TCAM ain’t cheap, but it’s also not the only solution to the problem and solutions are getting cheaper (per prefix) over time.

Owen

10

Owen DeLong wrote:

Consider, for example AS7922

COMCAST is not a good example.

but, rather organic customer growth and RIR applications over time.

No, if you know theory and practice of how additional address ranges
are allocated as a result of growth, you could have noticed that the
large number of prefixes of COMCAST should mostly be a result of
mergers, where merged parts won't renumber their hosts.

That’s the kind of prefix growth we should be able to mostly avoid in
IPv6 that is rather rampant in IPv4.

Without automatic renumbering, IPv6 is of no help against mergers.

Sure, but the number of multi homed sites is way _WAY_ less than the
IPv4 routing table size.

The following page by Geoff Huston is better than your delusion.

  http://www.potaroo.net/ispcolumn/2001-03-bgp.html
  What is driving this recent change to exponential growth
  of the routing table?
  In a word, multi-homing.

With the current routing practice, the number will increase to 14Mwith IPv4 and a lot more than that with IPv6.

I’m curious as to why you think that the number is bounded at 14M for
IPv4 and why you think there will be so many more multi homed sites
in IPv6?

I don't think I must explain the current routing practice here.

The problem is serious especially because Moore's law is ending.

People have been claiming that Moore's law is at an end longer than
we have been pushing for IPv6 deployment.

I'm afraid you are not very familiar with semiconductor technology
trend.

            Masataka Ohta

11

nothing comes for free. Pushing the complexity down to the host level is not a "solution", just a workaround with its own set of problems.

Nick

12

Owen DeLong wrote:

>> With the current routing practice, the number will increase to 14M
>> with IPv4 and a lot more than that with IPv6.
>
> Ie$B!Ge(Bm curious as to why you think that the number is bounded at 14M fo

r

> IPv4 and why you think there will be so many more multi homed sites
> in IPv6?

I don't think I must explain the current routing practice here.

Actually, maybe you *should* explain how it will grow to 14M IPv4 routes.

Are there 13 million /24s still out there to be allocated? Where will these
routes come from?

13

Nick Hilliard wrote:

The solution is:

https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

but IETF is working on stupid things like LISP only to increaseload to the global routing system.

nothing comes for free. Pushing the complexity down to the host
level is not a "solution", just a workaround with its own set of
problems.

If you can't accept the following principle of the End to End
argument:

  The function in question can completely and correctly be
  implemented only with the knowledge and help of the
  application standing at the end points of the
  communication system.

validity of which is demonstrated by the Internet, and insist
that something complete and correct is not a solution
but a workaround, feel free to keep using POTS not smart phones.

          Masataka Ohta

14 
 The function in question can completely and correctly be
 implemented only with the knowledge and help of the
 application standing at the end points of the
 communication system\.

this is a straw man argument. E2E works regardless of the current network-based multihoming mechanism or the proposals in draft-ohta-e2e-multihoming.

validity of which is demonstrated by the Internet, and insist
that something complete and correct is not a solution
but a workaround

Your proposal is almost a text-book case of RFC1925, section 6:

   (6) It is easier to move a problem around (for example, by moving
        the problem to a different part of the overall network
        architecture) than it is to solve it.

I.e. instead of having network level complexity, you're proposing to shift the problem to maintaining both state and network into the host level. No doubt it has some benefits, but this comes at the cost of bringing dfz complexity down to the host and all the consequent support, scaling and management headaches associated with that. I.e. the problem space shifts, but is not solved.

> feel free to keep using POTS not smart phones.

Thank you, I certainly will. Conversely, please feel free to use arguments instead of rhetoric.

Nick

15

Nick Hilliard wrote:

If you can't accept the following principle of the End to End
argument:

 The function in question can completely and correctly be
 implemented only with the knowledge and help of the
 application standing at the end points of the
 communication system\.

this is a straw man argument.

The text is in the original paper on the principle:

  End-To-End Arguments in System Design
  J. H. SALTZER, D. P. REED, and D. D. CLARK
  http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

E2E works regardless of the current network-based multihoming mechanism or the proposals in draft-ohta-e2e-multihoming.

As the next sentence of the paper is:

  Therefore, providing that questioned function as a feature
  of the communication system itself is not possible

which means:

  Therefore, providing multihoming as a feature
  of the communication system itself is not possible

you are wrong.

Your proposal is almost a text-book case of RFC1925, section 6:

FYI, the rfc was published on 1 April.

I.e. instead of having network level complexity, you're proposing to shift the problem to maintaining both state and network into the host level. No doubt it has some benefits, but this comes at the cost of bringing dfz complexity down to the host and all the consequent support, scaling and management headaches associated with that. I.e. the problem space shifts, but is not solved.

So, you are joking, aren't you?

> feel free to keep using POTS not smart phones.

Thank you, I certainly will. Conversely, please feel free to use arguments instead of rhetoric.

Instead of rhetoric, I argue by quoting from papers, hopefully not
published on 1 April, validity of which is well recognized.

            Masataka Ohta

16

Owen DeLong wrote:

Consider, for example AS7922

COMCAST is not a good example.

It seemed as good as any… Also, note that many of the Comcast mergers ended up in other
Comcast ASNs, possibly not changing ASNs either?

However, since you don’t like Comcast, let’s try another one that has few (if any) mergers involved:

AS6939 — 125 prefixes…

5.152.177.0/24
5.152.179.0/24
5.152.181.0/24
5.152.182.0/24
5.152.183.0/24
12.177.5.0/24
12.192.16.0/24
12.192.17.0/24
23.142.192.0/24
23.164.160.0/24
23.175.160.0/24
27.50.32.0/21
38.72.144.0/20
38.87.144.0/23
45.33.128.0/22
45.33.132.0/22
45.33.136.0/22
45.33.140.0/24
45.33.140.0/22
45.40.118.0/23
52.129.12.0/23
64.62.128.0/18
64.62.128.0/17
64.71.128.0/18
64.209.56.0/21
64.209.68.0/22
64.214.184.0/21
65.19.128.0/18
65.49.0.0/17
65.49.2.0/24
65.49.14.0/24
65.49.68.0/24
65.49.108.0/22
66.97.177.0/24
66.119.119.0/24
66.160.128.0/18
66.160.192.0/20
66.178.176.0/20
66.207.160.0/20
66.220.0.0/19
67.43.48.0/20
72.14.64.0/24
72.14.65.0/24
72.14.66.0/24
72.14.67.0/24
72.14.89.0/24
72.52.64.0/18
72.52.71.0/24
72.52.92.0/24
74.82.0.0/18
74.82.22.0/23
74.82.46.0/24
74.82.48.0/22
74.116.112.0/22
74.121.104.0/22
74.122.152.0/21
103.6.216.0/22
103.96.214.0/24
103.100.138.0/24
103.193.186.0/23
104.36.120.0/22
104.194.216.0/23
104.247.128.0/22
104.247.132.0/23
104.254.152.0/21
104.255.240.0/21
107.178.32.0/24
107.178.33.0/24
107.178.34.0/23
107.178.36.0/22
107.178.40.0/21
124.252.248.0/21
139.56.8.0/24
139.60.15.0/24
141.193.188.0/23
148.51.0.0/17
161.129.140.0/22
162.213.130.0/24
162.247.12.0/22
162.247.75.0/24
162.249.152.0/23
162.249.154.0/23
167.136.239.0/24
168.245.149.0/24
170.199.208.0/23
173.242.48.0/20
184.75.240.0/21
184.104.0.0/17
184.104.0.0/15
184.104.200.0/21
184.104.208.0/20
184.105.7.0/24
184.105.16.0/20
184.105.32.0/20
184.105.48.0/20
184.105.62.0/24
184.105.88.0/21
184.105.100.0/22
184.105.248.0/21
185.101.97.0/24
185.101.98.0/24
185.114.36.0/24
185.149.69.0/24
185.242.47.0/24
199.164.248.0/23
199.192.144.0/22
204.13.226.0/23
207.126.64.0/19
208.64.56.0/21
208.75.96.0/21
208.79.140.0/22
209.51.160.0/19
209.130.152.0/22
209.135.0.0/19
209.150.160.0/19
216.66.0.0/19
216.66.32.0/19
216.66.64.0/19
216.66.72.0/21
216.66.80.0/20
216.99.220.0/23
216.218.128.0/17
216.224.64.0/21
216.224.64.0/19
216.229.96.0/20

Admittedly some of this appears to be TE routes, but compare with:

2001::/32
2001:470::/32
2001:470:1A::/48
2001:DF2:7900::/48
2001:49E8::/32
2002::/16
2400:7A00::/32
2600:7000::/24
2602:FECA::/36
2602:FF06:725::/48
2604:A100:100::/48
2604:C800:FFFF::/48
2605:4C0::/32
2620:0:50C0::/48
2620:64:6000::/48
2620:138:C001::/48
2620:138:C002::/48
2A03:B2C0::/29
2A06:1C80::/32
2A09:2580::/29
2A09:2780::/29
2A09:3880::/29
2A09:3B80::/29
2A09:3D80::/29
2A09:E500::/29
2A09:F480::/29
2A09:FA80::/29

27 prefixes with most of them being obvious TE or customer carve-outs.

In fact, the first prefix appears to be a bogon from the IANA reserve, so I’m not sure why HE is originating a route for that.

If you still think this isn’t a good example, then pick a decent sized transit AS of your choosing and I’ll run their statistics.

but, rather organic customer growth and RIR applications over time.

No, if you know theory and practice of how additional address ranges
are allocated as a result of growth, you could have noticed that the
large number of prefixes of COMCAST should mostly be a result of
mergers, where merged parts won’t renumber their hosts.

That’s the kind of prefix growth we should be able to mostly avoid in
IPv6 that is rather rampant in IPv4.

Without automatic renumbering, IPv6 is of no help against mergers.

Merging 10 organizations each of whom have 27 IPv6 prefixes = 270 prefixes.
Merging 10 organizations each of whom have 125 IPv4 prefixes = 1250 prefixes.

IPv6 is of some help even in the case of mergers…

Sure, but the number of multi homed sites is way WAY less than the
IPv4 routing table size.

The following page by Geoff Huston is better than your delusion.

http://www.potaroo.net/ispcolumn/2001-03-bgp.html
What is driving this recent change to exponential growth
of the routing table?
In a word, multi-homing.

Yeah, not quite the whole story in that one word… Let’s look at what is driving that increase
in “multihoming”…

While it’s true that cost reduction for circuits has made multihoming more practical, it’s also true
that IPv4 scarcity is driving a lot of this as ISPs are less and less willing to provide free addresses
to customers driving the economics for smaller and smaller customers to get tiny fractions of space
from the remaining limited pools at various RIRs (e.g. ARIN NRPM 4.10 set-aside for v6 transition,
APNIC last /8 policy, RIPE last /8 policy, etc.).

Once you’re getting to the point of BYOA with your ISP, it’s really not much of a farther step to get an
ASN to go with that and turn on BGP.

Geoff’s not entirely wrong about the economics he describes, but he does, IMHO, leave some things
out. For example, he seems to completely ignore (doesn’t even mention) the fact that this latest
exponential expansion also coincides with the rise of the IPv4 transfer markets and the fragmentation
of previously solid large blocks (e.g. MIT’s /8, AMPR selling off a /10 from 44/8, lots of /16s being
sold for /24 pieces, etc.).

With the current routing practice, the number will increase to 14Mwith IPv4 and a lot more than that with IPv6.

I’m curious as to why you think that the number is bounded at 14M for
IPv4 and why you think there will be so many more multi homed sites
in IPv6?

I don’t think I must explain the current routing practice here.

You don’t need to explain the current routing practice, but if you want to be taken seriously,
simply assuming that every possible /24 in IPv4 and/or every possible /48 in IPv6 will be
eventually advertised is a case of reductio ad absurdum. I was trying to give you a chance
to provide a better argument for your position.

The problem is serious especially because Moore’s law is ending.

People have been claiming that Moore’s law is at an end longer than
we have been pushing for IPv6 deployment.

I’m afraid you are not very familiar with semiconductor technology
trend.

While I appreciate that you enjoy speaking to people in condescending tones, looking at thehistory and current trends shows that we are in a period where Moore’s law is leveling off.
We’ve had such periods before and then someone eventually develops something new that
leads to a resumption of the curve.

Past examples have included sub micron technology, the shift from 5v0 to 3v3 and then
later 1v8 core logic, etc.

I stand by my statement. I have no idea what the next breakthrough will be, but I doubt that we
have seen the last breakthrough in computing efficiency.

Owen

17

FYI, the rfc was published on 1 April.

I'm aware of the date that rfc1925 was published and the significance of the date, and also that rfc1925 was intended to take a humorous approach towards some very fundamental, recurrent themes which continue to present themselves in networking theory and practice.

No-one is compelled to pay attention to anything rfc1925 for this reason, but anyone dismissing it will do so to their own disadvantage.

I.e. instead of having network level complexity, you're proposing to shift the problem to maintaining both state and network into the host level. No doubt it has some benefits, but this comes at the cost of bringing dfz complexity down to the host and all the consequent support, scaling and management headaches associated with that. I.e. the problem space shifts, but is not solved.

So, you are joking, aren't you?

We need agree to disagree then. I wish you well.

Nick

18

Nick Hilliard wrote:

Your proposal is almost a text-book case of RFC1925, section 6:

FYI, the rfc was published on 1 April.

I'm aware of the date that rfc1925 was published and the significance
of the date, and also that rfc1925 was intended to take a humorous
approach towards some very fundamental, recurrent themes which
continue to present themselves in networking theory and practice.

Thank you for your rhetoric.

            Masataka Ohta

19

Owen DeLong wrote:

However, since you don’t like Comcast, let’s try another one that has
few (if any) mergers involved:

I don't think so.

AS6939 — 125 prefixes...

Are you spamming?

Admittedly some of this appears to be TE routes, but compare with:

2001::/32 2001:470::/32 2001:470:1A::/48 2001:DF2:7900::/48

If you are saying some merger happened before v6 transition,
which explains why there are less v6 prefix than v4, I can agree
with you.

But, so what?

Without automatic renumbering, IPv6 is of no help against mergers.

Merging 10 organizations each of whom have 27 IPv6 prefixes = 270
prefixes. Merging 10 organizations each of whom have 125 IPv4
prefixes = 1250 prefixes.

The number of prefixes by swamp is recognized to be not a problem
even when we were discussing it in 1998 when there was only less
than 50000 prefixes.

Sure, but the number of multi homed sites is way _WAY_ less than
the IPv4 routing table size.

Yeah, not quite the whole story in that one word… Let's look at what
is driving that increase in "multihoming"…

OK. You admit that the problem is caused by multihoming. OK.

I don't think I must explain the current routing practice here.

You don’t need to explain the current routing practice, but if you
want to be taken seriously, simply assuming that every possible /24
in IPv4 and/or every possible /48 in IPv6 will be eventually
advertised is a case of reductio ad absurdum. I was trying to give
you a chance to provide a better argument for your position.

I don't think I need such chance as my argument is already good enough.

While I appreciate that you enjoy speaking to people in condescending
tones, looking at the history and current trends shows that we are in
a period where Moore's law is leveling off.

I'm afraid you are not very familiar with semiconductor technology
trend.

            Masataka Ohta

20

I don’t think I need such chance as my argument is already good enough.

I’m curious if you’re able to convince anyone that your thoughts are valid and correct with such an attitude.