March 2022 - Test - lists.nanog.org

Budget news: Proposed Puerto Rico FEMA distribution center (warehouse)
by Sean Donelan 29 Mar '22

29 Mar '22

Program Change 1 – Caribbean Area Office and Warehouse Support: Description The FY 2023 Budget includes an increase of $1.4M for the staffing and operational costs of the Puerto Rico Distribution Centers (DC). Staff will manage readiness, disaster response operations and the distribution of commodities for the FEMA DCs in Puerto Rico. [...] As a result of lesson learned responding during the 2017 and 2018 hurricane seasons, analysis of observed maritime parameters has determined the requirement for one week of supply necessary to bridge a tailored disaster supply chain from CONUS. [...] To meet these readiness targets, the sites require staffing that are prepared to respond to all future major declarations, in lieu of being temporarily funded by a single, current major disaster declaration. This will allow sustained continuity of disaster support within the Caribbean. Organization structure of these facilities are based on models used at other FEMA distribution centers. https://www.dhs.gov/sites/default/files/2022-03/Federal%20Emergency%20Manag… Reminder: The annual president's budget proposal is mostly imaginary. The traditional joke is Congress tosses it in the trash bin immediately after the press conference. Nevertheless, its good to see some of the problems after the 2017/2018 caribbean hurricanes mentioned. In 2017/2018 took over a month to get the disaster response supply chain from CONUS to the island territories (PR/USVI) working in spite of many heroic efforts at the time.

1 0

Routes to twitter via 8359 8359 8342
by Drew Weaver 28 Mar '22

28 Mar '22

Is anyone else seeing this route destined for Twitter in the US being directed through 8359 announced by 8342? 104.244.42.0/24 Just curious, replies off list welcome. -Drew

3 2

Would someone from Sling.com and Netflix contact me off-list
by Anthony Leto 28 Mar '22

28 Mar '22

Would someone from Sling.com and Netflix contact me off-list I am running into issues with several of my home internet users being blocked from your services. Thanks, Anthony Leto Flying Man Studio, LLC AS393941 anthony(a)fms.io

1 0

ISP data collection from home routers
by Giovane C. M. Moura 26 Mar '22

26 Mar '22

Hello there, Several years ago, a friend of mine was working for a large telco and his job was to detect which clients had the worst networking experience. To do that, the telco had this hadoop cluster, where it collected _tons_ of data from home users routers, and his job was to use ML to tell the signal from the noise. I remember seeing a sample csv from this data, which contained _thousands_ of data fields (features) from each client. I was _shocked_ by the amount of (meta)data they are able to pull from home routers. These even included your wifi network name _and_ password! (it's been several years since then). And home users are _completely_ unaware of this. So my question to you folks is: - What's the policy regulations on this? I don't remember the features (thousands) but I'm pretty sure you could some profiling with it. - Is anyone aware of any public discussion on this? I have never seen it. Thanks, Giovane Moura

19 26

Re: V6 still not supported R: 202203232156.AYC
by Abraham Y. Chen 25 Mar '22

25 Mar '22

********** Resend to go through NANOG *********** On 2022-03-23 23:11, Abraham Y. Chen wrote: > Dear Pascal: > > 1) " Did you propose this work at a WG in Vienna this week? > ": No, but I was invited to be a coauthor of a HuaWei study > comparing addressing schemes that was presented there. See material > attached. > > 2) " I coined the term elevator shaft for the description > below.... , but the lawyer language is hard to parse for the rest of > us so I paraphrased and exemplified. ... ": Well, the lawyer got > paid for his legalese. But, I doubt the essence of your patent. (See > more thoughts below.) > > 3) ".. And I just picked 240.0.0.0/8 as an example ... ": > This is not the way to link up with another Intellectual Property > work. You need to present your implementation, before paraphrasing to > others. Otherwise, it is more than misleading. > > 4) " Now that you’re aware of the possible prior art ... ": > Not too fast! As I stated, neither myself nor the patent examiner of > my case found your work. And, I characterize your claim as "more a > general /*concept*/*//*than practice." So, if the examiner did pick up > your patent, he probably decided to disregard it. What you need to > understand is that the basic criterion for granting a patent is: > > "The */first/* party who has the */original idea/* that has been > reduced to */practice/**//*for teaching the general public." > > I do not believe that yours could pass such a simple test, not to > mention that the proposed header changes were so extensive compared to > EzIP's simple no-change approach (using only the old-fashioned RFC791). > > Note: There was a historical issue about what qualified an > Internet related work for a patent (at least in US) around the turn of > this century. The most famous one was the "one-click purchase" scheme > by Amazon. Yours appear to be close to the other end of the extreme, > because fourteen years later (the patent life of seventeen years is > almost over) you are still paraphrasing, without a working model to > show. I do not want to burden colleagues on this List with the > details. If you want, I can give you a run-down offline. > > 5) " I guess we need to continue that discussion on an IETF ML > rather than here, ": Let me know where you feel is more appropriate, > after you have reviewed the above. > > Regards, > > > Abe (2022-03-23 23:10 EDT) > > > > On 2022-03-23 12:47, Pascal Thubert (pthubert) wrote: >> >> Dear Abe: >> >> Neat 😊 Did you propose this work at a WG in Vienna this week? >> >> Just a few points: >> >> * I coined the term elevator shaft for the description below. I just >> thought that it may help visualize this story; figuring the Internet >> as a 2-D flat in a building, and the special prefix bring a 3^rd >> dimension to interconnect levels as an elevator shaft does in the >> building. The 20 year old IPR did not use that term or that example, >> it was more generic than that, but the lawyer language is hard to >> parse for the rest of us so I paraphrased and exemplified. >> >> * And I just picked 240.0.0.0/8 as an example to show that you can >> easily build 1000000 parallel Internets because it was discussed in >> another thread that would provide a lot less value off it, which may >> hint that the way we use that prefix should be thought carefully. >> >> * Now that you’re aware of the possible prior art, I believe you are >> required by law to notify the USPTO so they determine what to do with >> the reference. Sorry for the hassle. >> >> * I guess we need to continue that discussion on an IETF ML rather >> than here, unless people in the list ask for more. I’ll read with >> interest the details of your proposal. >> >> The bottom line for NANOG is that the dev guys are willing to help, >> whether by evolving IPv6 or proposing IPv4 ideas like the ones below. >> But we need push / support from your side to pass the PM bar. >> >> Keep safe; >> >> Pascal >> >> *From:* Abraham Y. Chen <aychen(a)avinta.com> >> *Sent:* mercredi 23 mars 2022 16:59 >> *To:* Pascal Thubert (pthubert) <pthubert(a)cisco.com> >> *Cc:* Michael Thomas <mike(a)mtcc.com>; nanog(a)nanog.org >> *Subject:* Re: V6 still not supported Re: 202203231017.AYC >> >> Dear Pascal: >> >> 0) So glad to see your recount of the history and the analysis! >> >> 1) We have recently formulated a proposal called EzIP (Phonetic >> for Easy IPv4) that is very much along the line of what you just >> described below, but with a few twists. I browsed through US patent >> 7,356,031, but failed to spot the key word "240. It appears to me >> that it was more a general concept than practice. Did you submit a >> draft on your work to IETF? Perhaps due to these, our (including >> patent examiner's) prior art search never came across your work. >> Although, your patent was granted in the same year as the Normative >> Reference [2] of our IETF draft. Please have a quick read of the >> below whitepaper. It provides you an overview of EzIP as well as >> references to US Pat. No.11,159,425, the current IETFdraft and a >> feasibility demonstration setup. >> >> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf >> >> 2) Here is a few quick comparisons between our two teams' work and >> the outline of EzIP benefits: >> >> A. Your "Realm" is very much equivalent to our RAN (Regional >> Area Network). However, instead of utilizing 240.0.0/8, we propose to >> use the full 240/4 each to maximize its effectiveness. Each RAN can >> serve up to 39M population as large as Tokyo Metro, even before >> utilizing the three private netblocks. >> >> B. Your "Elevator Shaft" making use of part of the 240/4 pool >> is equivalent to our single IPv4 public address to tether a RAN from >> the Internet core. Ours is a "micro" building block approach that >> provides more flexibility. For example, up to 75% of the smaller >> countries around the world need only one IPv4 each to achieve the >> "Elevator Shaft" configuration. >> >> C. Your "Inter-Realm Router" is simply the current Internet >> core routers in the EzIP scheme. >> >> D. Instead of proposing any modification to the IP packet >> header, EzIP can deploy within the capability of the RFC791. That is, >> when inter-RAN traffic is needed, the Option Word mechanism is >> activated to carry the 240/4 addresses within the RAN, leaving the >> basic source and destination address fields to carry the public IPv4 >> addresses of the RANs at either end. >> >> E. EzIP implementation is very straightforward. We have >> identified at least one case that only requires "*/disabling/* the >> program code that has been */disabling/* the use of the 240/4 >> netblock". With your software expertise, you likely know other >> configurations. >> >> F. EzIP essentially proposes to expand the address pool >> currently used by CG-NAT without any hardware change. In addition, >> the simplification in administrating the 240/4 addresses >> deterministically can mitigate the root cause to the cyber >> insecurity, thus reducing the OpEx. >> >> G. Treating 240/4 as the fourth netblock in RFC1918 allows the >> RAN to operate pretty much independent of the Internet core. On the >> other hand, being rejected by current routers enables RANs to be >> deployed worldwide by themselves without interference in either >> direction. This forms an */overlay /*network providing Internet-like >> services while having individualized flexibility per RAN. >> >> H. As more and more RANs are deployed, there will be >> increasing number of IPv4 public addresses becoming "spares". Each >> can support one RAN to serve other purposes, such as true test beds >> for experimenting new protocols. >> >> I. There probably are a few more parallelisms that we can >> identify, as we discuss more. >> >> I look forward to your thoughts and critiques. >> >> Regards, >> >> Abe (2022-03-23 11:59 EDT) >> >> On 2022-03-23 05:01, Pascal Thubert (pthubert) via NANOG wrote: >> >> I see the same thing from the other side, being a S/W developer >> for switching and routing boxes since the early 90's. The PM >> barrier is a high wall indeed. And yet some techs succeed to pass >> it. What I'm arguing is that we can pass that wall if we work >> together with the same objective. >> >> I've been monitoring this list for a while, very insightful, very >> happy with what I learn in the process. But here I feel compelled >> to react. I read that IPv6 did not succeed in 25 years. But >> unless I miss something, complaining did not succeed either, did it? >> >> My frustration is that indeed (as a dev guy) we have been trying >> hard to serve users our best. We proposed a number of things in >> the IPv4 evolution direction that I see being asked on this list. >> For larger IPv4 space and smooth migration, I'm personally fond >> of the IP-in-IP variation that filed in 20+ years ago as US >> patent 7,356,031. Basically we reserve a /8, say, since it is so >> popular at this time, 240.0.0./8, and make it the "elevator >> shaft" between IPv4 realms. Say the current IPv4 Internet is >> realm 1, that Internet would have IP address 240.0.0.1/8 in the >> shaft, and would continue operating as is, without a change in >> hosts and routers for traffic staying inside the current >> Internet. Now say China builds realm 2; that Internet would have >> IP address 240.0.0.2/8 in the shaft. A host in the Internet that >> wants to talk to a host in China would require an update to parse >> new DNS double-A (realm, address) records to encapsulate the >> packet IP-in-IP, outer src= 240.0.0.1 outer dest=240.0.0.2. The >> router that serves the shaft at level 1 attracts 240.0.0.0/8 >> within realm 1 and routes up the elevator for more specific >> (host) routes within that prefix. The router that serves the >> shaft at level 2 attracts 240.0.0.2/32 inside the shaft; upon the >> said packet it would swap the inner and outer destination and the >> packet would reach the Chinese address with classical routing >> within realm 2. Routers serving the shaft need an update, but >> then, only those do. Obviously the host in China can only reply >> if its stack is updated to understand the format. But all the >> other hosts and routers in China can be classical IPv4 as we know >> them long as their traffic stays in China. To migrate to IPv6 >> what you can do is map the elevator shaft prefix in, say, 400::/3 >> (sadly cannot use F00/3 that would map 240 neatly but is already >> assigned). The current internet would own 400:1::/32, China would >> own 400:2::/32, etc... You encode the double-A of the host in the >> prefix, reserve a well known suffix for IPv4 mapped double-A, and >> you have an IPv6 address that can be mapped both ways >> statelessly. When migrating to v6, each IPv4 node that owns a >> public IPv4 address in one realm gets a full IPv6 /64 for free. >> >> This kind of ideas have existed for long but apparently did not >> meet their public. >> >> So we tried evolving IPv6 instead. And we did. I've witnessed >> deep evolution in networking technology with, e.g., IoT and SRv6. >> I've seen both being despised on this list and I'm not asking for >> more fuel on that fire. I just want to use these techs as a proof >> that evolution is indeed possible, that it happens in the context >> of IPv6, and that done in your direction it could make some folks >> happier than the current state of affairs. On the side, since I >> see the name, please consider that Cisco ships both techs above, >> so it is indeed capable of risk taking, the PM wall can indeed be >> passed, as long as there's enough pressure from both side. >> >> For those interested, I'd be happy to chat on how IPv6 ND has >> evolved (on paper) but is stuck behind the PM wall as well. >> >> Keep safe; >> >> Pascal >> >> Message----- >> >> From: NANOG <nanog-bounces+pthubert=cisco.com(a)nanog.org> >> <mailto:nanog-bounces+pthubert=cisco.com@nanog.org> On Behalf Of >> >> Michael Thomas >> >> Sent: mardi 22 mars 2022 22:37 >> >> To: nanog(a)nanog.org >> >> Subject: Re: V6 still not supported >> >> On 3/22/22 5:45 AM, Randy Bush wrote: >> >> john, >> >> fwiw your story matches what is left of my memory. one >> nuance >> >> That’s not to say that there wasn’t "IETF politics” >> involved, but >> >> rather that such politics were expressed as enormous >> pressure to >> >> “make a decision” >> >> my take was that cidr had done a lot to relieve the immediate >> >> technical pressure for the short term; but there was a >> deep fear that >> >> the industry press was stirring a major poolpah about the >> end of the >> >> internet due to >> >> ipv4 exhaustion. i.e. a seriously flawed technical >> compromise was >> >> pushed on us in reaction to a perception of bad press. >> >> i have learned that, when i am under great pressure to DO >> SOMETHING, >> >> it's time to step back, go make a cup of tea, and think. >> the ietf did >> >> not. and here we are, a quarter of a century later, >> still trying to >> >> clean up the mess. >> >> So are you saying that an ipng that came out in, say, 2000 >> which was >> >> according to you was vastly superior having taken the time to >> get it >> >> right would have had any better chance of being adopted? My >> experience >> >> with Cisco product managers at the time is that they couldn't >> give a >> >> shit about the technical aspects of an ipng. If their silicon >> forwarding >> >> couldn't handle it, they weren't interested unless customers were >> >> clamoring for it. I can't see how that negative feedback loop >> could have >> >> ever been prevented other than other ipng being done in, oh >> say, 1993 >> >> when it was all still software forwarding. >> >> Mike >> >> Image removed by sender. >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> >> >> >> Virus-free. www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> >> > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

WP: Russian military behind hack of satellite communication devices
by Sean Donelan 25 Mar '22

25 Mar '22

Not yet official, but the U.S. intelligence community seems to continue its rapid release of intelligence. I think everyone was expecting it, especially since Viasat executives declined to say it earlier this week at the SATCOM 2022 conference. https://www.washingtonpost.com/national-security/2022/03/24/russian-militar… By Ellen Nakashima Today at 10:25 p.m. EDT U.S. intelligence analysts have concluded that Russian military spy hackers were behind a cyberattack on a satellite broadband service that disrupted Ukraine’s military communications at the start of the war last month, according to U.S. officials familiar with the matter. The U.S. government, however, has not announced its conclusion publicly. [...] The modems were part of Viasat’s European satellite network, KA-SAT. The company uses distributors in Europe to sell Internet service, which relies on modems, to customers. The company is shipping new modems to the distributors so they can get them to affected customers, the official said.

2 2

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

25 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 26 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: 894229 Prefixes after maximum aggregation (per Origin AS): 336759 Deaggregation factor: 2.66 Unique aggregates announced (without unneeded subnets): 428489 Total ASes present in the Internet Routing Table: 72908 Prefixes per ASN: 12.27 Origin-only ASes present in the Internet Routing Table: 62546 Origin ASes announcing only one prefix: 25701 Transit ASes present in the Internet Routing Table: 10362 Transit-only ASes present in the Internet Routing Table: 381 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 65 Max AS path prepend of ASN (267602) 58 Prefixes from unregistered ASNs in the Routing Table: 868 Number of instances of unregistered ASNs: 874 Number of 32-bit ASNs allocated by the RIRs: 38896 Number of 32-bit ASNs visible in the Routing Table: 32344 Prefixes from 32-bit ASNs in the Routing Table: 151610 Number of bogon 32-bit ASNs visible in the Routing Table: 31 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 479 Number of addresses announced to Internet: 3068372992 Equivalent to 182 /8s, 227 /16s and 168 /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: 303143 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 234292 Total APNIC prefixes after maximum aggregation: 66359 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 229205 Unique aggregates announced from the APNIC address blocks: 94106 APNIC Region origin ASes present in the Internet Routing Table: 12501 APNIC Prefixes per ASN: 18.33 APNIC Region origin ASes announcing only one prefix: 3558 APNIC Region transit ASes present in the Internet Routing Table: 1723 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 7696 Number of APNIC addresses announced to Internet: 774201472 Equivalent to 46 /8s, 37 /16s and 96 /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: 261013 Total ARIN prefixes after maximum aggregation: 119721 ARIN Deaggregation factor: 2.18 Prefixes being announced from the ARIN address blocks: 260865 Unique aggregates announced from the ARIN address blocks: 124035 ARIN Region origin ASes present in the Internet Routing Table: 18992 ARIN Prefixes per ASN: 13.74 ARIN Region origin ASes announcing only one prefix: 6895 ARIN Region transit ASes present in the Internet Routing Table: 1953 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: 4406 Number of ARIN addresses announced to Internet: 1295812864 Equivalent to 77 /8s, 60 /16s and 137 /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: 256375 Total RIPE prefixes after maximum aggregation: 117145 RIPE Deaggregation factor: 2.19 Prefixes being announced from the RIPE address blocks: 253772 Unique aggregates announced from the RIPE address blocks: 150114 RIPE Region origin ASes present in the Internet Routing Table: 28102 RIPE Prefixes per ASN: 9.03 RIPE Region origin ASes announcing only one prefix: 12050 RIPE Region transit ASes present in the Internet Routing Table: 3993 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: 10659 Number of RIPE addresses announced to Internet: 714103424 Equivalent to 42 /8s, 144 /16s and 90 /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: 114098 Total LACNIC prefixes after maximum aggregation: 27461 LACNIC Deaggregation factor: 4.15 Prefixes being announced from the LACNIC address blocks: 114067 Unique aggregates announced from the LACNIC address blocks: 48178 LACNIC Region origin ASes present in the Internet Routing Table: 10936 LACNIC Prefixes per ASN: 10.43 LACNIC Region origin ASes announcing only one prefix: 2635 LACNIC Region transit ASes present in the Internet Routing Table: 2204 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 65 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8632 Number of LACNIC addresses announced to Internet: 176288768 Equivalent to 10 /8s, 129 /16s and 244 /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: 27583 Total AfriNIC prefixes after maximum aggregation: 5417 AfriNIC Deaggregation factor: 5.09 Prefixes being announced from the AfriNIC address blocks: 35841 Unique aggregates announced from the AfriNIC address blocks: 11646 AfriNIC Region origin ASes present in the Internet Routing Table: 1618 AfriNIC Prefixes per ASN: 22.15 AfriNIC Region origin ASes announcing only one prefix: 563 AfriNIC Region transit ASes present in the Internet Routing Table: 325 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: 951 Number of AfriNIC addresses announced to Internet: 107692288 Equivalent to 6 /8s, 107 /16s and 65 /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 9136 8884 44 CHINAMOBILE-CN China Mobile Communicati 7545 5903 789 696 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4707 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3600 1330 19 VIETEL-AS-AP Viettel Group, VN 7713 3487 1038 51 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 3434 1880 56 VNPT-AS-VN VNPT Corp, VN 4766 2498 11121 602 KIXS-AS-KR Korea Telecom, KR 9498 2389 491 238 BBIL-AP BHARTI Airtel Ltd., IN 45090 2146 1438 79 TENCENT-NET-AP Shenzhen Tencent Compute 4755 2108 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 6299 10252 2665 AMAZON-02, US 11492 4452 295 717 CABLEONE, US 22773 3945 3061 366 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3895 263 26 VIASAT-SP-BACKBONE, US 16625 3648 1879 2562 AKAMAI-AS, US 6327 3418 1318 62 SHAW, CA 749 2882 50780 2138 DNIC-AS-00749, US 30036 2607 373 177 MEDIACOM-ENTERPRISE-BUSINESS, US 209 2520 4962 428 CENTURYLINK-US-LEGACY-QWEST, US 20115 2256 3042 495 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 6807 1730 149 UNI2-AS, ES 9121 6721 1692 17 TTNET, TR 8551 4003 374 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 3916 3360 200 AKAMAI-ASN1, NL 39891 3819 220 34 ALJAWWALSTC-AS, SA 12389 2960 2274 909 ROSTELECOM-AS, RU 6849 2783 355 21 UKRTELNET, UA 9009 2468 248 1287 M247, GB 34984 2199 355 622 TELLCOM-AS, TR 47331 2089 329 1599 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 10477 3408 551 Uninet S.A. de C.V., MX 10620 3473 519 715 Telmex Colombia S.A., CO 11830 2431 369 62 Instituto Costarricense de Electricidad 13999 1725 292 478 Mega Cable, S.A. de C.V., MX 6503 1446 354 524 Axtel, S.A.B. de C.V., MX 28573 1397 2332 253 CLARO S.A., BR 3816 1254 666 146 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 1090 369 21 Telefonica del Peru S.A.A., PE 11664 1006 192 450 Techtel LMDS Comunicaciones Interactiva 11172 956 133 63 Alestra, S. de R.L. de C.V., MX 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 1584 393 21 LINKdotNET-AS, EG 24835 1518 515 32 RAYA-AS, EG 36992 1300 1518 261 ETISALAT-MISR, EG 36903 1199 545 114 MT-MPLS, MA 29571 911 64 63 ORANGE-COTE-IVOIRE, CI 6713 612 1863 34 IAM-AS, MA 36935 560 520 43 Vodafone-, EG 15399 514 51 34 WANANCHI-, KE 37342 469 32 1 MOVITEL, MZ 23889 422 232 16 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 10477 3408 551 Uninet S.A. de C.V., MX 9808 9136 8884 44 CHINAMOBILE-CN China Mobile Communicati 12479 6807 1730 149 UNI2-AS, ES 9121 6721 1692 17 TTNET, TR 16509 6299 10252 2665 AMAZON-02, US 7545 5903 789 696 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4707 4192 74 ERX-CERNET-BKB China Education and Rese 11492 4452 295 717 CABLEONE, US 8551 4003 374 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 22773 3945 3061 366 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 9136 9092 CHINAMOBILE-CN China Mobile Communications Grou 9121 6721 6704 TTNET, TR 12479 6807 6658 UNI2-AS, ES 7545 5903 5207 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4707 4633 ERX-CERNET-BKB China Education and Research Net 8551 4003 3964 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7155 3895 3869 VIASAT-SP-BACKBONE, US 39891 3819 3785 ALJAWWALSTC-AS, SA 11492 4452 3735 CABLEONE, US 20940 3916 3716 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 1333342 UNALLOCATED 2.58.228.0/22 133334 DCNBSI-AS-AP DCTV Cable Netw 398083 UNALLOCATED 5.104.72.0/24 399587 UT, US 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 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:307 /13:588 /14:1205 /15:2057 /16:13563 /17:8323 /18:13882 /19:25167 /20:43299 /21:52208 /22:108372 /23:95539 /24:528740 /25:808 /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 5871 6721 TTNET, TR 12479 5788 6807 UNI2-AS, ES 8151 4133 10477 Uninet S.A. de C.V., MX 8551 3477 4003 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3364 4452 CABLEONE, US 6327 3230 3418 SHAW, CA 39891 3131 3819 ALJAWWALSTC-AS, SA 7155 2988 3895 VIASAT-SP-BACKBONE, US 22773 2936 3945 ASN-CXA-ALL-CCI-22773-RDC, US 6849 2636 2783 UKRTELNET, UA Complete listing at https://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1842 2:1052 3:154 4:7 5:3781 6:112 7:5 8:1564 9:1 11:172 12:1710 13:301 14:2389 15:182 16:42 17:380 18:147 20:194 21:4 22:188 23:5550 24:2357 25:4 27:2600 29:19 31:2415 32:96 34:1 35:66 36:1752 37:4388 38:2685 39:710 40:150 41:3934 42:987 43:2100 44:291 45:16171 46:4062 47:348 49:1669 50:1926 51:107 52:1407 53:1 54:362 55:808 56:8 57:59 58:1816 59:1197 60:956 61:2269 62:2475 63:1942 64:5523 65:2302 66:4847 67:2974 68:1177 69:4165 70:1344 71:659 72:3072 74:2669 75:1389 76:700 77:2123 78:3895 79:3102 80:1976 81:1701 82:1476 83:1213 84:1350 85:3653 86:716 87:1973 88:2691 89:3247 90:519 91:7621 92:1975 93:2603 94:3474 95:4748 96:1311 97:348 98:993 99:866 100:75 101:1034 102:1993 103:28862 104:4310 105:464 106:853 107:2503 108:804 109:4146 110:2073 111:3285 112:2007 113:1523 114:1492 115:1962 116:1902 117:2517 118:2277 119:1866 120:1677 121:1063 122:2575 123:2120 124:1614 125:2113 128:1200 129:1212 130:916 131:2078 132:761 133:374 134:1931 135:290 136:878 137:866 138:2419 139:1494 140:1116 141:1359 142:1282 143:1482 144:1233 145:344 146:1774 147:1464 148:2216 149:1692 150:854 151:1079 152:1837 153:458 154:3542 155:1416 156:1886 157:1235 158:1030 159:2078 160:2433 161:1323 162:3461 163:1234 164:1645 165:1616 166:689 167:1719 168:3756 169:698 170:4440 171:817 172:3068 173:3072 174:1019 175:1126 176:3507 177:4561 178:3426 179:1983 180:2280 181:2934 182:3248 183:1941 184:2384 185:19461 186:4339 187:3650 188:3861 189:3118 190:8853 191:1294 192:11054 193:8560 194:6962 195:4976 196:2977 197:2391 198:6019 199:6029 200:7482 201:5652 202:10506 203:10013 204:4550 205:3386 206:3752 207:3391 208:4041 209:4660 210:4257 211:2433 212:3998 213:3381 214:1160 215:67 216:6444 217:2646 218:1259 219:597 220:1955 221:980 222:848 223:2142 End of report

1 0

IPvB performance header
by William Allen Simpson 25 Mar '22

25 Mar '22

This was the IPvB (nee original IPv6) *performance* header. We required that each IP variant have its own link layer designation. Therefore, the IP version number wasn't needed. We could simply set two upper bits to a value (0) that would distinguish it from every extant IP version. Also, many of us thought that the type of service was poorly defined and rarely used. The longer length field was requested by Fibre Channel, and later used for InfiniBand. Finally, the Flow Label was supposed to aid in NAT mapping, without the underlying transport layer. One field to rule them all. No chains of headers. High performance. 3.2. Performance Header Format +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | V | Maximal Length | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | Flow Label | Hop Limit | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | + Source + | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | + Destination + | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | Security Parameters Index (SPI) | A +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | Sequence Number | A +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | A E ~ Transform Data ~ A E | | A E +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ ... Padding | A E +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | ~ Authenticator ~ | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ For most fields, see above. Fields to be authenticated are designated by a trailing A. Fields to be encrypted are designated by a trailing E. V 2 bits. Always 0. This corresponds to the unused IP Versions 0 to 3, and is readily distinguished from all extant versions. Maximal Length 30 bits. The length of the datagram, including internet header(s) and payload data. The maximum length supported by the Destination is negotiated for each Flow Label. Flow Label 24 bits. The Flow Label is relative to the IP Source and Destination pairing, and assigned by the flow’s originating node. The Flow Label subsumes the Service and Next Header information. The Flow Label MUST NOT be altered by an intervening router. Routers that do not support Flow Label functionality, or lack state for this Source and Flow Label combination, MUST treat the Service as undifferentiated. Mechanisms for assignment and reservation of Flow Labels are beyond the scope of this specification.

1 0

IPvB translation header
by William Allen Simpson 25 Mar '22

25 Mar '22

This was the IPvB (nee original IPv6) *translation* header. Note that it was cleverly designed to translate from IPv4. Most of the fields are in exactly the same place. Especially, the 32-bit Source IP address is in exactly the same place, hoping that filters could operate on both stacks. We were implementing on then new i386 32-bit machines, but also tested on i286 16-bit machines. We knew there would be 64-bit machines (such as the DEC Alpha), so it was carefully designed for multiple environments. 3.1. Translation Header Format +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ |Version| IHV | Service | Minimal Length | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | Identification | Next Header | Hop Limit | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | + Source + | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ | | + Destination + | | +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+ Version 4 bits: constant 0xB (1011 binary). Indicates the format of the internet header. This document describes version 11. Note: The IPv4 Version is 0x4 (0100 binary). IPvB is the complement (binary inverse) of IPv4. Although this field is always present, and may be used internally by systems, different headers MUST be distinguished at the link layer. Some implementations of IPv4 failed to correctly check (or set) the IPv4 Version. IHV 4 bits. Internet Header Variant. 0x0 Invalid; MUST be silently discarded. 0x6 IPv4 header translation. The least significant bit here reflects the most significant IPv4 Flags bit, as some systems used that bit in the past. (See "IPvB Translation for IPv4" [].) 0x8 Flow header (see below). 0xA Reserved for future use. The IPvB header is a fixed minimum size. However, the Version field is a scarce resource Therefore, larger values are used for format variants, transient indications, and other purposes. Note: For IPv4, this field was the Internet Header Length (IHL) in 32‐bit words. The minimum value for a matching IPvB header is 6 words. Service 8 bits: default 0. Contains the IPv4 Type of Service (ToS). Minimal Length 16 bits: minimum 64 (bytes). Smaller values MUST be silently discarded. The length of the datagram, including internet header(s) and payload data. All nodes must be prepared to accept datagrams of up to 1480 octets. It is recommended that hosts send datagrams larger than 1480 octets only after assurance that the destination is prepared to accept the larger datagrams. The number 1480 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information, and to allow typical lower‐layer encapsulations room for their respective headers. Over time, memory limitations have eased considerably, and there have been some indications that a larger minimum datagram size throughout the internet would be beneficial. Note: IPv4 has minimum required 576 and maximum 65,535 octet datagrams. Translation to IPv4 requires that the IPvB limits are only applicable to nodes indicating the presence of IPvB. (See "IPvB Neighbor Discovery" [] and "IPvB Translation for IPv4" [].) Identification 16 bits: default 0. Assigned by the sender. Originally used in IPv4 to aid in assembling the fragments of a datagram. However, IPvB uses a Fragmentation Header instead, and treats all IPv4 datagrams as Don’t Fragment (DF). Next Header 8 bits. Identifies the type of header immediately following this header. Uses the same values as the IPv4 Protocol field. (See [RFC‐1700] et seq.) Hop Limit 8 bits: initially 255. Indicates the maximum time the datagram is allowed to remain in the internet routing system. The intent is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime. The time is measured in units of seconds, but is only an upper bound on the time a datagram may exist. This field is modified in internet header processing. Every node that routes the datagram between interfaces MUST decrement the value by at least one. For large bandwidth‐delay paths, the value SHOULD decrease by more than one, and MAY decrease by one for each anticipated second in transit (including queuing delay) over the outgoing interface. If this field contains the value zero (0) before sending, or some higher limit upon receipt as configured for each protocol, then the datagram MUST be discarded. Note: IPv4 defaults to an initial value of 64 []. (See also "IPvB Translation for IPv4" [].) Security considerations require that the initial value be well known, so that protocol implementations can detect the number of hops from its source. Source 64 bits. The location of the node originating the datagram. Note: The least significant 32 bits are aligned with the IPv4 Source field to permit serendipitous comparisons for network egress and ingress filtering of both header versions concurrently. Destination 64 bits. The location of the routing area where an interface of the intended communication peer might be found. The IPvB header maintains 64‐bit alignment. Together with an IPvB Encapsulating Security Protocol (ESP), the header combination maintains 128‐bit and 256‐bit alignment. Serendipitous alignment allows simple loads and stores, instead of slower byte by byte iterations.

1 0

Cogent pulled out of Russia based on risk analysis
by Lady Benjamin Cannon of Glencoe, ASCE 25 Mar '22

25 Mar '22

Confirmation from their CEO that Cogent shut down service in Russia due to increased use of the connections for cyberattacks, and because only $10m in rev came from Russia. Cogent had no equipment in Russia. Details: https://youtu.be/l_x2LQZOzF8 Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO lb(a)6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” FCC License KJ6FJJ Sent from my iPhone via RFC1149.

5 4