- NANOG - lists.nanog.org

Geolocation Data : MAX MIND - Out of Sync
by Paschal Masha 14 Mar '22

14 Mar '22

Hello, Not sure whether anyone out there is also experiencing this, seems MAX MIND ( [ https://www.maxmind.com/en/geoip2-precision-demo | https://www.maxmind.com/en/geoip2-precision-demo ] ) geo database is extremely out of sync with whois records on RIRs DBs. It's ok(not 100%) to submit corrections for a few(if not less than few) blocks, but getting it all wrong for more that 4 to many blocks- that's a big deal..especially when other services( like, whatsmyip), believe you more that other DBs e.g 102.217.58.0/24 an AFRNIC allocation, appears in Turkey on MAX MIND, while ip2location and other geoDBs correctly displays this. IS there anyone- with power- from MAX MIND in this list that can help out? Please contact me offlist - sorry for the broadcast to the other members. Regards Paschal Masha | Engineering Skype ID: paschal.masha

9 9

Re: V6 still not supported (was Re: CC: s to Non List, Members, (was Making Use of 240/4, NetBlock))
by Abraham Y. Chen 14 Mar '22

14 Mar '22

Hi, Fred: 0) Thanks for sharing your references to IPv6 statistics. 1) However, you might have looked this topic too deeply and missed the overview. Through our study of EzIP, we have discovered two aspects of this topic that frequently mislead readers: A. IPv6 equipment */Capability/* vs. IPv6 traffic */Volume/*: The former is about equipment "readiness". The latter is about the actual traffic "amount". High value of the former does not necessarily imply the same to the latter. Without explicitly stating which one is being presented, wasteful debates based on these numbers persist. In fact, this is where the big smoke screen that our team had to go through to finally see more clearly about the true reference that we have to base upon. B. The scope of the candidates for the source data set: Comparisons of the incident type needs to find the largest domain, not several sub-domains, to extract data from. This is important because an author can pick up a few datasets that support the "theory", while overlooking others that may be more significant and introduce counter views. This is also tricky, because how can one tell which type of domain is bigger than the others? Since we are discussing a global event, any domain that implies worldwide coverage is much more trustworthy than multiple full datasets, each is country-based . 2) Although all of your citations contain "IPv6", some even include "status", none of them clearly defines which one of the two choices in Pt. 1) A. it is referring to. Except, the browser tab of the following reads "IPv6 */Capability/* Metrics". This confirms, at least to me, that you have been looking at Capabilities instead of Volume. The former tends to show much higher numbers because it is just a report of how many devices online are ready to use IPv6 (I heard that such indication is carried in the IP packet somewhere?). This is because when users actually use IPv6, it then contributes to the Volume statistics. https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=IN 3) Allow me to share with you the IPv6 statistics that we have been following. On top of the two criteria in Pt. 1) above, we also look for consistency through time, i.e., track records such as how long and how frequently the data is updated. A. IPv6 Deployment / Readiness: The following has been updated every few days for quite sometime. Whatever metrics that it is based upon, we can assume that it is applied worldwide. This appears to be a superset of what you cited. https://stats.labs.apnic.net/ipv6/ B. IPv6 Traffic Volume: There was an annual report series by Cisco. But, the last one was in 2017. We could not find any later versions. Interestingly, Cisco TechSupport confirmed so. https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813… 4) These days, we primarily monitor the following two statistics to keep up with the IPv6 performance status: A. Google IPv6 Adoption: This is a daily report that goes back to 2008 Oct. The current peak is around 38%, while the average is around 36%. Also, a very interesting phenomenon can be observed if you zoom into a small segment of the graph. It shows the weekly fluctuations that peak during weekends or holidays when users are mostly accessing Google services from homes. In fact, the lock-down during the COVID-19 pandemic pushed the average up notably. Although this is only within Google, it is a worldwide statistics. More importantly, Google is one of the stronger IPv6 promoters. Similar statistics from other business should logically be capped by this graph. https://www.google.com/intl/en/ipv6/statistics.html B. AMS-IX Traffic Statistics: There are various measurements that are constantly (between every 7 to 15 minutes) updated. The URL below leads you to a set of composite graphs showing the percentages of various type of protocols being transported through AMS-IX. What you will find in the below graph is that IPv6 Traffic is only around 4.5% which is in the 10% range of that in the Google graph above. https://stats.ams-ix.net/sflow/ether_type.html 5) Pt. 4) B. is a surprise statistics. We have not been able to pin-point exactly how could this happen. Two factors should be kept in mind: A. AMS-IX may not be the largest IX (Internet eXchange), but their operation is worldwide. They are the only business of this kind that has been providing the continuous reports (This kind of reports have been going on for ages. AMS-IX does not provide archived data. But, you can search Archive.org for historical data as far back as 2010-06.). So, we believe that this is more reliable than others. B. IX businesses take the overflow traffic from Internet backbone carriers' peering arrangements. So, the ratio between IPv4 and IPv6 could be different from the bulk in the core. However, one historical event (see URL below) hints that the IPv6 traffic on AMS-IX should have been even lower than what is reported if its peering agreements had been settled in a similar manner as those for IPv4. https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/ Hope this run-down of background and history enable us to synchronize our perspective of the IPv6 status. Regards, Abe (2022-03-14 14:04) ------------------------------ NANOG Digest, Vol 170, Issue 15 Message: 15 Date: Sun, 13 Mar 2022 21:06:51 -0700 From: Fred Baker<fredbaker.ietf(a)gmail.com> To: Joe Maimon<jmaimon(a)jmaimon.com>, "Chen, Abraham Y." <AYChen(a)alum.mit.edu>, "Abraham Y. Chen"<aychen(a)avinta.com>, Ca By <cb.list6(a)gmail.com> Cc: NANOG<nanog(a)nanog.org> Subject: Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock)) Message-ID:<7E0B159F-43AC-4507-8FB9-3120B2B9046A(a)gmail.com> Content-Type: text/plain; charset=us-ascii > On Mar 11, 2022, at 8:39 AM, Joe Maimon<jmaimon(a)jmaimon.com> wrote: > > Google's statistics... I'm not sure which of you I'm replying to. The comment was made on NANOG the other day that we should discount Google statistics because they have been promoting IPv6 for a decade. It's true that they have been doing so. But they aren't the only people with statistics. https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=in,my,sa,b… You might look at the following links. Eric Vyncke has been putting up charts basically on Google, Akamai, and APNIC statistics for a while. One thing to consider is that around 90 countries (92 in this capture, as low as 89 a couple of days ago) have 5% or greater response rate using IPv6. Google and Akamai have their own content networks, and in at least some countries only externalize AAAA records or respond to IPv6 requests. APNI isn't that way; they don't operate a content network, but rather accept traffic from across the backbone. Consider that a content network essentially reports traffic from a customer network to their first hop ISP, while when APNIC reports an IPv6 access, the father form APNIC to the collector in question has to include every network and every router in the path. Now look at these: https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=in https://www.vyncke.org/ipv6status/compare.php?metric=k&countries=in https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=IN I think the APNIC numbers demonstrate that paths through the backbone generally support IPv6 end to end, and that from a routing perspective there is no reason to favor IPv4. There are 8 Countries (this evening) that Google reports roughly equal response rates from using IPv4 or IPv6. cfhttps://www.vyncke.org/ipv6status/compare.php?metric=p&countries=in,my,sa…. This doesn't prove that IPv6 has taken over the world, but it does prove that those who would discount available statistics sources are a little too shrill in doing so. Where IPv6 has a problem today is with enterprise. IMHO, this is basically because enterprise is looking at the bottom line. If ISPs were to do what Mythic Beasts says they do, which is charge their users for address space, IPv6 is virtually free while IPv4 costs something. I suspect that enterprise would change its tune dramatically. ------------------------------ -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Docusign
by Bruno Vane 14 Mar '22

14 Mar '22

Hello, Anyone from Docusign here?

4 3

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))
by Abraham Y. Chen 14 Mar '22

14 Mar '22

Dear Ca By: 1) It appears that you are reading the Google graph too optimistically, or incorrectly. That is, the highest peaks of the graph are about 38%. The average of the graph is about 36%. Citing "over 40%" from these is a gross exaggeration. In fact, the peaks were reached on weekends and holidays due to more residential usage, you can clearly see such by zooming into the graph. In addition, the graph has been exhibiting an asymptomatic trend ever since a few years back. The COVID-19 pushed this graph up a bit due to the lock-down and work-from-home factors. Below was an analysis pre-pandemic: https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_… 2) Since Google is one of the stronger IPv6 promoters, usage of IPv6 outside of the Google domain can only be lower, by simple logic deduction. Regards, Abe (2022-03-11 10:11) ------------------------------ NANOG Digest, Vol 170, Issue 12 Message: 12 Date: Thu, 10 Mar 2022 08:00:17 -0800 From: Ca By<cb.list6(a)gmail.com> To: Saku Ytti<saku(a)ytti.fi> Cc: Joe Greco<jgreco(a)ns.sol.net>,nanog(a)nanog.org Subject: Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)) Message-ID: <CAD6AjGTyQT-OMq_KXxFe-sozWq3mSJ5gC_tKswdpJpi7mMEwFQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti<saku(a)ytti.fi> wrote: > On Wed, 9 Mar 2022 at 21:00, Joe Greco<jgreco(a)ns.sol.net> wrote: > >> I really never thought it'd be 2022 and my networks would be still >> heavily v4. Mind boggling. > Same. And if we don't voluntarily agree to do something to it, it'll > be the same in 2042, we fucked up and those who come after us pay the > price of the insane amount of work and cost dual stack causes. > > It is solvable, easily and cheaply, like most problems (energy, > climate), but not when so many poor leaders participate in decision > making. > > -- > ++ytti Ah, the quarterly ipv6 thread? where i remind you all? most of the USA is on ipv6 (all your smartphone, many of your home router, a growing amount of your clouds [i see you aws]) https://www.worldipv6launch.org/measurements/ Google sees over 40% of their users on ipv6, with superior latency https://www.google.com/intl/en/ipv6/statistics.html

11 12

Re: Making Use of 240/4 NetBlock Re: 202203140004.AYC
by Abraham Y. Chen 14 Mar '22

14 Mar '22

Hi, John: 0) Thanks for your comments. 1) Re: Ur. Pt. 1): I have recently been informed of such activities. So far, my attempt to submit a draft and to reach the group chairs have not been successful. 2) Re: Ur. Pt. 2): Our work looks very much inline with your Unicast project. My quick reaction is that EzIP appears to be a practical application that can benefit from your proposal. Although we further limit the application of 240/4 netblock to be "on-premises" (from the Internet core's perspective) use, the scheme of the EzIP deployment actually makes the scope bigger. Since I am not very familiar with the terminologies, does this interpretation make any sense? Please comment. Regards, Abe (2022-03-14 00:22) On 2022-03-12 23:26, John Gilmore wrote: > Abraham Y. Chen<aychen(a)avinta.com> wrote: >> 1) Thanks for confirming my understanding of the 240/4 history. >> Basically, those in charge of the Internet appear to be leaving the >> community in the state of informal debates, since there is no more >> formal IPv4 working group. > There is one; it's called "intarea" and is a working group of the IETF. > >> 2) On the other hand, there was a recent APNIC blog that specifically >> reminded us of a fairly formal request for re-designating the 240/4 >> netblock back in 2008 (second grey background box). To me, this means >> whether to change the 240/4 status is not an issue. The question is >> whether we can identify an application that can maximize its impact. >> >> https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/ > Please read our recent Internet-Draft on the subject: > > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ > > In section 2, you will find references to all the previous allocations > (and requests for allocation) of the 240/4 address block. > > John -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Making Use of 240/4 NetBlock
by Abraham Y. Chen 14 Mar '22

14 Mar '22

Hi, Jordi: 1) " ... Because it is a single Internet, and what we do in some parts of Internet will affect others? ... ": The nice thing about the EzIP scheme is that it proposes a collection of overlay network modules (the RAN - Regional Area Network), each is tethered from the existing Internet core via one IPv4 public address as the umbilical cord which isolates the two, except exchanging IP packets conforming to the established Internet protocol. So, EzIP essentially proposes to create a parallel cyberspace practically independent of the current one. There should be no concern about interfering each other. 2) " ... many previous unsuccessful discussions at IETF about 240/4: ... ": Perhaps I am from the old engineer school, I was inspired by a street legend that, After Thomas Edison tried over one thousand types of material to replace the lead-acid battery, people with conventional wisdom declared that he had failed one thousand times. Edison responded by saying that "I now know there are at least one thousand types of material that can not replace the lead-acid battery. The moral of the story is that after one century, we are now beginning to use Lithium based battery which by itself went through tremendous amount of R&D efforts. So, I highly respect those who focus on alternative possibilities, instead of those regurgitating on unsuccessful discussions of proposals, let alone those avoid studying the root cause of the failed experiments. Regards, Abe (2022-03-13 21:45) ------------------------------ NANOG Digest, Vol 170, Issue 13 Message: 23 Date: Sat, 12 Mar 2022 09:21:01 +0100 From: JORDI PALET MARTINEZ<jordi.palet(a)consulintel.es> To: North American Network Operators' Group<nanog(a)nanog.org> Subject: Re: Making Use of 240/4 NetBlock Message-ID:<BE38196A-ABE8-4445-BF65-CB3E02B8C343(a)consulintel.es> Content-Type: text/plain; charset="UTF-8" Because it is a single Internet, and what we do in some parts of Internet will affect others? Because, at least in my case, I'm investing my efforts in what it seems to be the best in the long-term for the global community, not my personal preferences? ?El 12/3/22 9:10, "William Herrin"<bill(a)herrin.us> escribi?: On Fri, Mar 11, 2022 at 11:58 PM JORDI PALET MARTINEZ via NANOG <nanog(a)nanog.org> wrote: > Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6 is the only viable long-term solution. > > The effort to ?reinvent? any part of IPv4 or patches to it, then test that everything keeps working as expected, versus the benefits and gained time, it is much best invested in continue the IPv6 deployment which is already going on in this region and the rest of the world. > > It would not make sense, to throw away all the efforts that have been already done with IPv6 and we should avoid confusing people. > > I just think that even this thread is a waste of time (and will not further participate on it), time that can be employed in continue deploying IPv6. Why are so many otherwise smart engineers so vulnerable to false dilemma style fallacies? There's no "either/or" here. It's not a zero sum game. If you don't see value in doing more with IPv4 then why don't you get out of the way of folks who do? Regards, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/ ********************************************** -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Cogent cutting links to Russia?
by Michael Thomas 11 Mar '22

11 Mar '22

I know the link is paywalled, but it's super high level so not much is lost. But what does everybody think of this? I imagine that just Cogent cutting them off isn't going to make much difference. https://www.washingtonpost.com/technology/2022/03/04/russia-ukraine-interne… Mike

22 34

Weekly Global IPv4 Routing Table Report
by Routing Table Analysis Role Account 11 Mar '22

11 Mar '22

This is an automated weekly mailing describing the state of the Global IPv4 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(a)lists.apnic.net. For historical data, please see https://thyme.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. IPv4 Routing Table Report 04:00 +10GMT Sat 12 Mar, 2022 BGP Table (Global) as seen in Japan. Report Website: https://thyme.apnic.net Detailed Analysis: https://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 892760 Prefixes after maximum aggregation (per Origin AS): 335982 Deaggregation factor: 2.66 Unique aggregates announced (without unneeded subnets): 428829 Total ASes present in the Internet Routing Table: 72817 Prefixes per ASN: 12.26 Origin-only ASes present in the Internet Routing Table: 62477 Origin ASes announcing only one prefix: 25673 Transit ASes present in the Internet Routing Table: 10340 Transit-only ASes present in the Internet Routing Table: 383 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 53 Max AS path prepend of ASN (265020) 50 Prefixes from unregistered ASNs in the Routing Table: 935 Number of instances of unregistered ASNs: 938 Number of 32-bit ASNs allocated by the RIRs: 38762 Number of 32-bit ASNs visible in the Routing Table: 32261 Prefixes from 32-bit ASNs in the Routing Table: 151001 Number of bogon 32-bit ASNs visible in the Routing Table: 24 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 527 Number of addresses announced to Internet: 3068579968 Equivalent to 182 /8s, 230 /16s and 208 /24s Percentage of available address space announced: 82.9 Percentage of allocated address space announced: 82.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 303160 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 233372 Total APNIC prefixes after maximum aggregation: 66144 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 228376 Unique aggregates announced from the APNIC address blocks: 94526 APNIC Region origin ASes present in the Internet Routing Table: 12459 APNIC Prefixes per ASN: 18.33 APNIC Region origin ASes announcing only one prefix: 3550 APNIC Region transit ASes present in the Internet Routing Table: 1723 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 7662 Number of APNIC addresses announced to Internet: 774176768 Equivalent to 46 /8s, 37 /16s and 0 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-151865 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 260476 Total ARIN prefixes after maximum aggregation: 119468 ARIN Deaggregation factor: 2.18 Prefixes being announced from the ARIN address blocks: 260455 Unique aggregates announced from the ARIN address blocks: 123999 ARIN Region origin ASes present in the Internet Routing Table: 18970 ARIN Prefixes per ASN: 13.73 ARIN Region origin ASes announcing only one prefix: 6883 ARIN Region transit ASes present in the Internet Routing Table: 1967 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 28 Number of ARIN region 32-bit ASNs visible in the Routing Table: 4385 Number of ARIN addresses announced to Internet: 1295718912 Equivalent to 77 /8s, 59 /16s and 26 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-401308 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 255917 Total RIPE prefixes after maximum aggregation: 116864 RIPE Deaggregation factor: 2.19 Prefixes being announced from the RIPE address blocks: 253109 Unique aggregates announced from the RIPE address blocks: 149852 RIPE Region origin ASes present in the Internet Routing Table: 28083 RIPE Prefixes per ASN: 9.01 RIPE Region origin ASes announcing only one prefix: 12050 RIPE Region transit ASes present in the Internet Routing Table: 3960 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 10650 Number of RIPE addresses announced to Internet: 714185600 Equivalent to 42 /8s, 145 /16s and 155 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-213403 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 114404 Total LACNIC prefixes after maximum aggregation: 27401 LACNIC Deaggregation factor: 4.18 Prefixes being announced from the LACNIC address blocks: 114406 Unique aggregates announced from the LACNIC address blocks: 48173 LACNIC Region origin ASes present in the Internet Routing Table: 10932 LACNIC Prefixes per ASN: 10.47 LACNIC Region origin ASes announcing only one prefix: 2638 LACNIC Region transit ASes present in the Internet Routing Table: 2207 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 53 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8627 Number of LACNIC addresses announced to Internet: 176305920 Equivalent to 10 /8s, 130 /16s and 55 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-273820 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 27656 Total AfriNIC prefixes after maximum aggregation: 5413 AfriNIC Deaggregation factor: 5.11 Prefixes being announced from the AfriNIC address blocks: 35887 Unique aggregates announced from the AfriNIC address blocks: 11840 AfriNIC Region origin ASes present in the Internet Routing Table: 1603 AfriNIC Prefixes per ASN: 22.39 AfriNIC Region origin ASes announcing only one prefix: 552 AfriNIC Region transit ASes present in the Internet Routing Table: 322 Average AfriNIC Region AS path length visible: 5.2 Max AfriNIC Region AS path length visible: 34 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 937 Number of AfriNIC addresses announced to Internet: 107850240 Equivalent to 6 /8s, 109 /16s and 170 /24s AfriNIC AS Blocks 36864-37887, 327680-329727 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 9808 9104 8886 46 CHINAMOBILE-CN China Mobile Communicati 7545 5881 788 692 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4676 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3603 1330 19 VIETEL-AS-AP Viettel Group, VN 7713 3491 1038 51 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 3435 1880 56 VNPT-AS-VN VNPT Corp, VN 4766 2545 11122 623 KIXS-AS-KR Korea Telecom, KR 9498 2385 475 238 BBIL-AP BHARTI Airtel Ltd., IN 45090 2169 1438 79 TENCENT-NET-AP Shenzhen Tencent Compute 4755 2109 429 197 TATACOMM-AS TATA Communications formerl Complete listing at https://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 16509 6367 10249 2644 AMAZON-02, US 11492 4448 295 738 CABLEONE, US 22773 3946 3061 369 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3895 263 26 VIASAT-SP-BACKBONE, US 16625 3652 1882 2573 AKAMAI-AS, US 6327 3401 1318 62 SHAW, CA 749 2884 50780 2140 DNIC-AS-00749, US 30036 2613 374 136 MEDIACOM-ENTERPRISE-BUSINESS, US 209 2513 4962 426 CENTURYLINK-US-LEGACY-QWEST, US 20115 2256 3042 499 CHARTER-20115, US Complete listing at https://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 6803 1730 149 UNI2-AS, ES 9121 6698 1692 17 TTNET, TR 8551 4014 378 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 3935 3348 214 AKAMAI-ASN1, NL 39891 3818 220 33 ALJAWWALSTC-AS, SA 12389 2959 2274 909 ROSTELECOM-AS, RU 6849 2828 355 21 UKRTELNET, UA 9009 2470 250 1288 M247, GB 34984 2239 359 614 TELLCOM-AS, TR 47331 2069 328 1583 TTNET, TR Complete listing at https://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 10455 3427 554 Uninet S.A. de C.V., MX 10620 3468 518 715 Telmex Colombia S.A., CO 11830 2429 369 62 Instituto Costarricense de Electricidad 13999 1706 291 473 Mega Cable, S.A. de C.V., MX 6503 1441 354 524 Axtel, S.A.B. de C.V., MX 28573 1396 2332 248 CLARO S.A., BR 3816 1254 666 146 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 26615 1133 2349 136 TIM SA, BR 6147 1092 369 21 Telefonica del Peru S.A.A., PE 11664 1008 192 447 Techtel LMDS Comunicaciones Interactiva Complete listing at https://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1588 393 21 LINKdotNET-AS, EG 24835 1545 523 32 RAYA-AS, EG 36992 1300 1518 262 ETISALAT-MISR, EG 36903 1199 545 114 MT-MPLS, MA 29571 908 64 62 ORANGE-COTE-IVOIRE, CI 36935 729 521 40 Vodafone-, EG 6713 613 1863 34 IAM-AS, MA 15399 517 51 34 WANANCHI-, KE 37342 469 32 1 MOVITEL, MZ 23889 421 232 15 MauritiusTelecom, MU Complete listing at https://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 10455 3427 554 Uninet S.A. de C.V., MX 9808 9104 8886 46 CHINAMOBILE-CN China Mobile Communicati 12479 6803 1730 149 UNI2-AS, ES 9121 6698 1692 17 TTNET, TR 16509 6367 10249 2644 AMAZON-02, US 7545 5881 788 692 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4676 4192 74 ERX-CERNET-BKB China Education and Rese 11492 4448 295 738 CABLEONE, US 8551 4014 378 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 22773 3946 3061 369 ASN-CXA-ALL-CCI-22773-RDC, US Complete listing at https://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 9808 9104 9058 CHINAMOBILE-CN China Mobile Communications Grou 9121 6698 6681 TTNET, TR 12479 6803 6654 UNI2-AS, ES 7545 5881 5189 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4676 4602 ERX-CERNET-BKB China Education and Research Net 8551 4014 3975 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7155 3895 3869 VIASAT-SP-BACKBONE, US 39891 3818 3785 ALJAWWALSTC-AS, SA 16509 6367 3723 AMAZON-02, US 20940 3935 3721 AKAMAI-ASN1, NL Complete listing at https://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 398083 UNALLOCATED 5.133.124.0/24 399587 UT, US 33123 UNALLOCATED 8.10.69.0/24 11168 SCC, US 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 46887 LIGHTOWER, US 18604 UNALLOCATED 8.25.204.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 22442 HOU-PHONOSCOPE, US 54338 UNALLOCATED 8.33.241.0/24 6461 ZAYO-6461, US 395438 UNALLOCATED 8.42.206.0/24 3356 LEVEL3, US 395056 UNALLOCATED 8.45.133.0/24 3356 LEVEL3, US 32306 UNALLOCATED 8.46.80.0/24 33652 CMCS, US Complete listing at https://thyme.apnic.net/current/data-badAS Prefixes from the Special Purpose Address Registry (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at https://thyme.apnic.net/current/data-spar Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 23.141.0.0/24 Origin: 395350 UNASSIGNED 23.141.0.0/24 Transit: 11426 TWC-11426-CAROLINAS, US 27.100.7.0/24 Origin: 56096 UNASSIGNED 27.100.7.0/24 Transit: 45455 TH-2S1N-AP Two S One N Co Ltd, Internet 41.57.124.0/22 Origin: 37442 UNASSIGNED 41.57.124.0/22 Transit: 37204 TELONE, ZW 41.57.124.0/23 Origin: 37442 UNASSIGNED 41.57.124.0/23 Transit: 37204 TELONE, ZW 41.57.124.0/24 Origin: 37442 UNASSIGNED 41.57.124.0/24 Transit: 37204 TELONE, ZW Complete listing at https://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:40 /11:102 /12:305 /13:589 /14:1205 /15:2034 /16:13584 /17:8326 /18:13921 /19:25184 /20:43225 /21:52430 /22:108288 /23:95464 /24:527238 /25:796 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 9121 5848 6698 TTNET, TR 12479 5784 6803 UNI2-AS, ES 8151 4111 10455 Uninet S.A. de C.V., MX 8551 3479 4014 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3361 4448 CABLEONE, US 6327 3213 3401 SHAW, CA 39891 3130 3818 ALJAWWALSTC-AS, SA 7155 2988 3895 VIASAT-SP-BACKBONE, US 22773 2936 3946 ASN-CXA-ALL-CCI-22773-RDC, US 6849 2683 2828 UKRTELNET, UA Complete listing at https://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1720 2:1060 3:154 4:7 5:3784 6:112 7:5 8:1558 9:1 11:172 12:1714 13:305 14:2392 15:176 16:42 17:376 18:146 20:183 21:4 22:188 23:5517 24:2333 25:6 27:2605 29:19 31:2420 32:96 34:1 35:64 36:1749 37:4361 38:2603 39:696 40:150 41:3946 42:846 43:2100 44:297 45:16063 46:4127 47:347 49:1685 50:1925 51:107 52:1374 53:1 54:328 55:760 56:8 57:58 58:1771 59:1199 60:966 61:2264 62:2455 63:1945 64:5493 65:2307 66:4867 67:2951 68:1195 69:4156 70:1352 71:670 72:3075 74:2639 75:1517 76:716 77:2108 78:3874 79:3105 80:1951 81:1688 82:1476 83:1215 84:1346 85:3639 86:720 87:1952 88:2656 89:3244 90:516 91:7611 92:2005 93:2584 94:3496 95:4782 96:1314 97:347 98:988 99:866 100:75 101:1035 102:1969 103:28539 104:4259 105:461 106:851 107:2506 108:796 109:4193 110:2073 111:3278 112:2007 113:1495 114:1492 115:1957 116:1893 117:2481 118:2251 119:1860 120:1673 121:1060 122:2557 123:2112 124:1614 125:2107 128:1198 129:1188 130:922 131:2072 132:754 133:373 134:1932 135:290 136:876 137:871 138:2437 139:1239 140:1138 141:1382 142:1277 143:1490 144:1237 145:344 146:1765 147:1497 148:2210 149:1714 150:854 151:1082 152:1829 153:456 154:3626 155:1434 156:1879 157:1238 158:1025 159:2073 160:2411 161:1320 162:3455 163:1226 164:1667 165:1602 166:675 167:1719 168:3730 169:694 170:4425 171:823 172:3044 173:3079 174:1021 175:1128 176:3498 177:4593 178:3440 179:1984 180:2275 181:2934 182:3249 183:1944 184:2389 185:19382 186:4312 187:3674 188:3856 189:3098 190:8860 191:1310 192:11053 193:8551 194:6957 195:4967 196:2944 197:2352 198:5999 199:6006 200:7498 201:5666 202:10445 203:9981 204:4563 205:3384 206:3778 207:3387 208:4057 209:4652 210:4252 211:2446 212:4002 213:3388 214:1161 215:66 216:6432 217:2632 218:1246 219:596 220:1949 221:984 222:847 223:2172 End of report

1 0

The role of Internet governance in sanctions
by Bill Woodcock 11 Mar '22

11 Mar '22

I very much thank all of you who participated in this drafting effort, and I’m really happy that the document is out: https://www.pch.net/resources/Papers/Multistakeholder-Imposition-of-Interne… Now we can focus on operationalization. Mailing list, web site, etc. are in the process of being set up. The goal is to have a minimal, lightweight mechanism with BGP and RPZ feeds that networks can voluntarily subscribe to. 99% of the time, they’d be empty. Occasionally, when the Internet community believes that a military or propaganda agency is problematic enough to be worth sanctioning, IPs and domains would be added to the feed. The mechanism is exactly the same as is currently used for blackholing abuse IPs and domains, so doesn’t take anything new on the subscribing network’s side, just one more feed. We’re anticipating that debate over what goes into the list will only happen very occasionally, and the discussion list will be quiet the rest of the time. A lot like NSP-Sec and Outages. And there’ll probably be a lot of overlap with those groups. All are welcome, look for an announcement in a few more days. Thanks, -Bill

9 16

Asia Apac networks
by Edvinas Kairys 11 Mar '22

11 Mar '22

Hello, We've introduced Cogent network in Equinix Honk Kong DC. But seems via that link we're just receiving just only 5% of our traffic, other part of incoming traffic is received via our other ISPs like NTT, Simcentrc, and Equinix IXP. I know it's very naïve to expect the traffic load balance equally between 3 ISPs (4 if IXP is counted) using just one /24 subnet. According to most of BGP looking glasses in Asia, traffic via Cogent is least preferred even when i've added 6x prepend AS on our other mentioned providers to make route via Cogent more attractive. But nothing helps - seems main providers in Asia made routes via Cogent least preferable by lowering the local preference to it, that why prepending from our side doesn't help. Maybe someone has experience or similar problems with ISPs in Asia network ?

5 4