From hrobert at africacert.org  Wed Jul  1 08:40:08 2026
From: hrobert at africacert.org (Jean-Robert Hountomey)
Date: Wed, 1 Jul 2026 03:40:08 -0500 (CDT)
Subject: [afnog] SANS and AfricaCERT presentent the upcoming webinar:
	Securing Africa's Internet: Understanding and Defending
	Against Attacks on Critical Internet Infrastructure
Message-ID: <1782895208.669531584@apps.rackspace.com>



Greetings Colleagues,

We are hosting an upcoming AfricaCERT and SANS webinar. We are extending the invitation to the AfNOG community and would like to have you with us.

Date: Thursday, 9 July 2026 ? 9:00 AM?1:00 PM EAT (UTC+3).

Proposed Title:
Securing Africa's Internet: Understanding and Defending Against Attacks on Critical Internet Infrastructure

Organisers
AfricaCERT and SANS

Session Overview
The Internet has become a critical enabler of economic growth, digital transformation, financial services, government operations, and regional connectivity across Africa. As dependence on digital infrastructure continues to grow, protecting the systems that underpin the Internet has become increasingly important.

This session will provide a practical overview of today's cyber threats targeting critical Internet infrastructure across Africa, including Internet Service Providers (ISPs), telecommunications operators, Internet Exchange Points (IXPs), DNS Operators, and the broader Internet ecosystem. As key stewards of Internet availability and resilience, Internet Infrastructure operators play a particularly important role in supporting trusted communications, economic activity, and essential digital services.

The discussion will explore common threats targeting Internet infrastructure, emerging challenges facing operators and national ecosystems, lessons learned from recent incidents, and practical approaches to strengthening resilience through preparedness, collaboration, and information sharing among operators, CERTs/CSIRTs, and cybersecurity stakeholders.

Instructor
Jason Jordaan is a SANS Certified Instructor who has supported organizations across Africa and internationally in addressing complex cyber threats and strengthening cyber resilience for more than two decades. He previously served with the South African Police Service and established digital forensics capabilities within South Africa's Special Investigating Unit. His experience spans cyber investigations, incident response, and resilience initiatives across both public- and private-sector organizations.
Instructor Profile: https://www.sans.org/profiles/jason-jordaan/

Link.
Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_yiA-BytaQFu59g15vq9m2g










From roderick.beck at networksourcing.net  Wed Jul  1 12:28:02 2026
From: roderick.beck at networksourcing.net (Roderick Beck)
Date: Wed, 1 Jul 2026 15:28:02 +0300
Subject: [afnog] Article On 2Africa and WACS Outages
Message-ID: <CAL5j7Uk15x=+1Oc8gXM1Cg+=vGYChxsz=Z9f+iZRJOv37Xu5MA@mail.gmail.com>

https://subseacables.blogspot.com/2026/07/wacs-down-hard-turbidity-current-due-to.html

https://subseacables.blogspot.com/2026/06/2africa-outage-due-to-turbidity-current.html

-- 
Roderick Beck
Network Capacity Sourcing - Broker
Hungarian Mobile: 00-36-70-605-5144.
Estonian Mobile: 372-5855-6840.
Email: roderick.beck at networksourcing.net
Articles: https://subseacables.blogspot.com/
Telegram: @RoderickBeck
Tallinn & Budapest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20260701/f27f2fe0/attachment.html>

From cscora at apnic.net  Fri Jul  3 18:03:45 2026
From: cscora at apnic.net (Routing Table Analysis Role Account)
Date: Sat, 4 Jul 2026 04:03:45 +1000 (AEST)
Subject: [afnog] Weekly Global IPv4 Routing Table Report
In-Reply-To: 20260704.040001@thyme.apnic.net
Message-ID: <20260703180345.B84C0C0DEC@thyme.rand.apnic.net>

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
UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

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

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

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

IPv4 Routing Table Report   04:00 +10GMT Sat 04 Jul, 2026

  IPv4 BGP Table (Global) as seen at Japan.

Report Website:     https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                             1061643
    Prefixes after maximum aggregation (per Origin AS):          408286
    Deaggregation factor:                                          2.60
    Unique aggregates announced (without unneeded subnets):      525596
    Number of IPv4 prefixes with a valid ROA:                    710771
    Number of IPv4 prefixes with an invalid ROA:                   1407
    Number of IPv4 prefixes with no ROA:                         349465
Total ASes present in the Internet Routing Table:                 78799
    Prefixes per ASN:                                             13.47
Origin-only ASes present in the Internet Routing Table:           67692
Origin ASes announcing only one prefix:                           27539
Transit ASes present in the Internet Routing Table:               11107
Transit-only ASes present in the Internet Routing Table:            589
Average AS path length visible in the Internet Routing Table:       4.7
    Max AS path length visible:                                      69
    Max AS path prepend of ASN (269326)                              61
Prefixes from unregistered ASNs in the Routing Table:              1366
    Number of instances of unregistered ASNs:                      1396
Number of 32-bit ASNs allocated by the RIRs:                      50306
Number of 32-bit ASNs visible in the Routing Table:               41025
Prefixes from 32-bit ASNs in the Routing Table:                  235654
Number of bogon 32-bit ASNs visible in the Routing Table:           115
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            489
Number of addresses announced to Internet:                   3120122624
    Equivalent to 185 /8s, 249 /16s and 75 /24s
    Percentage of available address space announced:               84.3
    Percentage of allocated address space announced:               84.3
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               99.6
Total number of prefixes smaller than registry allocations:      346695

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   291933
    Total APNIC prefixes after maximum aggregation:               85345
    APNIC Deaggregation factor:                                    3.42
Prefixes being announced from the APNIC address blocks:          277912
    Unique aggregates announced from the APNIC address blocks:   109523
APNIC Region origin ASes present in the Internet Routing Table:   15311
    APNIC Prefixes per ASN:                                       18.15
APNIC Region origin ASes announcing only one prefix:               4725
APNIC Region transit ASes present in the Internet Routing Table:   2025
Average APNIC Region AS path length visible:                        4.7
    Max APNIC Region AS path length visible:                         55
Number of APNIC region 32-bit ASNs visible in the Routing Table:  10885
Number of APNIC addresses announced to Internet:              749828992
    Equivalent to 44 /8s, 177 /16s and 123 /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-155961
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:                    307138
    Total ARIN prefixes after maximum aggregation:               138030
    ARIN Deaggregation factor:                                     2.23
Prefixes being announced from the ARIN address blocks:           305542
    Unique aggregates announced from the ARIN address blocks:    149871
ARIN Region origin ASes present in the Internet Routing Table:    19460
    ARIN Prefixes per ASN:                                        15.70
ARIN Region origin ASes announcing only one prefix:                7103
ARIN Region transit ASes present in the Internet Routing Table:    1919
Average ARIN Region AS path length visible:                         4.3
    Max ARIN Region AS path length visible:                          35
Number of ARIN region 32-bit ASNs visible in the Routing Table:    5653
Number of ARIN addresses announced to Internet:              1348392960
    Equivalent to 80 /8s, 94 /16s and 216 /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-404380
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,  45/8,  47/8,  48/8,  50/8,  52/8,
                        54/8,  55/8,  56/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:                    293677
    Total RIPE prefixes after maximum aggregation:               146072
    RIPE Deaggregation factor:                                     2.01
Prefixes being announced from the RIPE address blocks:           298156
    Unique aggregates announced from the RIPE address blocks:    195641
RIPE Region origin ASes present in the Internet Routing Table:    29590
    RIPE Prefixes per ASN:                                        10.08
RIPE Region origin ASes announcing only one prefix:               12247
RIPE Region transit ASes present in the Internet Routing Table:    4005
Average RIPE Region AS path length visible:                         4.8
    Max RIPE Region AS path length visible:                          46
Number of RIPE region 32-bit ASNs visible in the Routing Table:   13585
Number of RIPE addresses announced to Internet:               749659264
    Equivalent to 44 /8s, 174 /16s and 228 /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-219547
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        53/8,  57/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:                  129734
    Total LACNIC prefixes after maximum aggregation:              30949
    LACNIC Deaggregation factor:                                   4.19
Prefixes being announced from the LACNIC address blocks:         124484
    Unique aggregates announced from the LACNIC address blocks:   50421
LACNIC Region origin ASes present in the Internet Routing Table:  11432
    LACNIC Prefixes per ASN:                                      10.89
LACNIC Region origin ASes announcing only one prefix:              2737
LACNIC Region transit ASes present in the Internet Routing Table:  2595
Average LACNIC Region AS path length visible:                       5.3
    Max LACNIC Region AS path length visible:                        69
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  9499
Number of LACNIC addresses announced to Internet:             167757312
    Equivalent to 9 /8s, 255 /16s and 198 /24s
LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-275868 + 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:                  37795
    Total AfriNIC prefixes after maximum aggregation:              7101
    AfriNIC Deaggregation factor:                                  5.32
Prefixes being announced from the AfriNIC address blocks:         55060
    Unique aggregates announced from the AfriNIC address blocks:  19727
AfriNIC Region origin ASes present in the Internet Routing Table:  2041
    AfriNIC Prefixes per ASN:                                     26.98
AfriNIC Region origin ASes announcing only one prefix:              727
AfriNIC Region transit ASes present in the Internet Routing Table:  389
Average AfriNIC Region AS path length visible:                      5.4
    Max AfriNIC Region AS path length visible:                       57
Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 1403
Number of AfriNIC addresses announced to Internet:            104211712
    Equivalent to 6 /8s, 54 /16s and 37 /24s
AfriNIC AS Blocks      36864-37887, 327680-330751 & ERX transfers
AfriNIC Address Blocks  41/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       14078       8921     101  CHINAMOBILE-CN - China Mobile Communicati
  7545        5853        818     468  TPG-INTERNET-AP - TPG Telecom Limited, AU
  4538        5062       4192      74  ERX-CERNET-BKB - China Education and Rese
  9498        4990        554     336  BBIL-AP - BHARTI Airtel Ltd., IN
 18403        4618        347      25  FPT-VN - FPT Telecom Company, VN
  7552        4060       1331      24  VIETEL-AS-AP - Viettel Group, VN
  7713        3732       1044      64  telkomnet-as-ap - PT Telekomunikasi Indon
 56046        3569        887     178  CMNET-Jiangsu-AP - China Mobile communica
 45899        3393       1868      99  VNPT-AS-VN - VNPT Corp, VN
 17561        3388        213     602  LCS-AS-AP - LARUS Limited, HK

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       15498      41509    5604  AMAZON-02 - Amazon.com, Inc., US
 22773        4782       3116     362  ASN-CXA-ALL-CCI-22773-RDC - Cox Communica
 11492        4554        303    1128  CABLEONE - CABLE ONE, INC., US
  7155        3962        286     111  VIASAT-SP-BACKBONE - ViaSat,Inc., US
  6327        3720       1305      74  SHAW - Shaw Communications, CA
396982        3414       4871     525  GOOGLE-CLOUD-PLATFORM - Google LLC, US
 36352        3156        237    1087  AS-COLOCROSSING - HostPapa, US
   749        3138      54728    2389  DNIC-AS-00749 - United States Department 
  7029        2660       2536     888  WINDSTREAM - Windstream Communications LL
 30036        2552        354     560  MEDIACOM-ENTERPRISE-BUSINESS - Mediacom C

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        7070       1711     150  UNI2-AS - Orange Espagne SA, ES
 39891        4975        307      72  ALJAWWALSTC-AS - Saudi Telecom Company JS
  9009        4186        377    2556  M247 - M247 Europe SRL, RO
 20940        3804       3389     109  AKAMAI-ASN1 - Akamai International B.V., 
212238        3389        242    2536  CDNEXT - Datacamp Limited, GB
 12389        3152       2322     873  ROSTELECOM-AS - PJSC Rostelecom, RU
 34984        2494        367     586  TELLCOM-AS - Superonline Iletisim Hizmetl
 44559        1724        108     821  ITHOSTLINE - IT HOSTLINE LTD, CY
  8452        1710       1852      17  TE-AS - IDDQD-AS, EG
203020        1658        253     828  HostRoyale - HostRoyale Technologies Pvt 

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       12786       3257     626  AS8151 - UNINET, MX
 10620        3440        450    1104  AS10620 - Telmex Colombia S.A., CO
 13999        2299        502     335  AS13999 - Mega Cable, S.A. de C.V., MX
 11830        1909        369      65  AS11830 - Instituto Costarricense de Elec
 11664        1499        277      34  AS11664 - Techtel LMDS Comunicaciones Int
 28573        1374       2431     269  AS28573 - Claro NXT Telecomunicacoes Ltda
  3816        1342        768     213  AS3816 - COLOMBIA TELECOMUNICACIONES S.A.
  6147        1207        371      22  AS6147 - INTEGRATEL PERU S.A.A., PE
 22884        1100         70     388  AS22884 - TOTAL PLAY TELECOMUNICACIONES, 
 26615        1063       2385      96  AS26615 - TIM S/A, BR

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
 24835        1991        617      34  Vodafone Data - Vodafone Data, EG
 36992        1926       1543     334  ETISALAT MISR - ETISALAT MISR, EG
 36903        1351        587     105  Office National des Postes et Telecommuni
 36935        1306        521      46  Vodafone Data - Vodafone Data, EG
 24863        1298        389      16  Link Egypt (Link.NET) - Link Egypt (Link.
 37069        1116       1100      11  The Egyptian Company for Mobile Services 
 29571        1086         70      18  Orange C??te d'Ivoire - Orange C??te d'Iv
328608         616         56     208  Africa on Cloud - Africa on Cloud, ZA
 15399         564         58      63  Wananchi Group (Kenya) Limited - Wananchi
 36914         556         82       3  Kenya Education Network - Kenya Education

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
 16509       15498      41509    5604  AMAZON-02 - Amazon.com, Inc., US
  9808       14078       8921     101  CHINAMOBILE-CN - China Mobile Communicati
  8151       12786       3257     626  AS8151 - UNINET, MX
 12479        7070       1711     150  UNI2-AS - Orange Espagne SA, ES
  7545        5853        818     468  TPG-INTERNET-AP - TPG Telecom Limited, AU
  4538        5062       4192      74  ERX-CERNET-BKB - China Education and Rese
  9498        4990        554     336  BBIL-AP - BHARTI Airtel Ltd., IN
 39891        4975        307      72  ALJAWWALSTC-AS - Saudi Telecom Company JS
 22773        4782       3116     362  ASN-CXA-ALL-CCI-22773-RDC - Cox Communica
 18403        4618        347      25  FPT-VN - FPT Telecom Company, VN

Complete listing at https://thyme.apnic.net/current/data-ASnet

Global Per AS Maximum Aggregation summary
-----------------------------------------

   ASN  No of nets  Net Savings  Description
  9808       14078        13977  CHINAMOBILE-CN - China Mobile Communications Gr
  8151       12786        12160  AS8151 - UNINET, MX
 12479        7070         6920  UNI2-AS - Orange Espagne SA, ES
  7545        5853         5385  TPG-INTERNET-AP - TPG Telecom Limited, AU
  4538        5062         4988  ERX-CERNET-BKB - China Education and Research N
 39891        4975         4903  ALJAWWALSTC-AS - Saudi Telecom Company JSC, SA
  9498        4990         4654  BBIL-AP - BHARTI Airtel Ltd., IN
 18403        4618         4593  FPT-VN - FPT Telecom Company, VN
 22773        4782         4420  ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 
  7552        4060         4036  VIETEL-AS-AP - Viettel Group, VN

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
     64501  DOCUMENT     5.255.139.0/24            9140  HYPERNEPH - Hyperneph L
    395729  UNALLOCATED  8.28.60.0/24             32787  PROLEXIC-TECHNOLOGIES-D
    396894  UNALLOCATED  8.28.201.0/24             3356  LEVEL3 - Level 3 Parent
    394936  UNALLOCATED  8.33.224.0/24            22442  HOU-PHONOSCOPE - Phonos
    396243  UNALLOCATED  8.34.113.0/24             3356  LEVEL3 - Level 3 Parent
    397274  UNALLOCATED  8.36.79.0/24              3356  LEVEL3 - Level 3 Parent
    396243  UNALLOCATED  8.37.112.0/24             3356  LEVEL3 - Level 3 Parent
    396243  UNALLOCATED  8.37.123.0/24             3356  LEVEL3 - Level 3 Parent
    395195  UNALLOCATED  8.38.115.0/24             3356  LEVEL3 - Level 3 Parent
    397274  UNALLOCATED  8.40.70.0/24              3356  LEVEL3 - Level 3 Parent

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 - Hurricane Electric LLC, US

Complete listing at https://thyme.apnic.net/current/data-spar

Advertised Unallocated Addresses
--------------------------------

Unassigned Network     ASN Information  AS Name
23.131.100.0/24      Origin:    401541  UNASSIGNED
23.131.100.0/24     Transit:     38733  CMCTELECOM-VN - CMC Telecom Infrastructu
23.131.156.0/24      Origin:    401541  UNASSIGNED
23.131.156.0/24     Transit:     38733  CMCTELECOM-VN - CMC Telecom Infrastructu
23.131.212.0/24      Origin:    401541  UNASSIGNED
23.131.212.0/24     Transit:     38733  CMCTELECOM-VN - CMC Telecom Infrastructu
23.132.252.0/24      Origin:    401541  UNASSIGNED
23.132.252.0/24     Transit:     38733  CMCTELECOM-VN - CMC Telecom Infrastructu
23.133.212.0/24      Origin:     18604  UNASSIGNED
23.133.212.0/24     Transit:     32217  GPIEX - GPIEX INC, US

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:14      /10:39      /11:97      /12:299     
/13:587     /14:1184    /15:2119    /16:13726   /17:8387    /18:13441   
/19:25727   /20:47074   /21:53233   /22:113941  /23:109379  /24:671685  
/25:695     /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
  8151        6999       12786  AS8151 - UNINET, MX
 12479        5997        7070  UNI2-AS - Orange Espagne SA, ES
 39891        3660        4975  ALJAWWALSTC-AS - Saudi Telecom Company JSC, SA
  6327        3501        3720  SHAW - Shaw Communications, CA
 11492        3444        4554  CABLEONE - CABLE ONE, INC., US
 22773        3053        4782  ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc., US
  7155        2916        3962  VIASAT-SP-BACKBONE - ViaSat,Inc., US
 16509        2881       15498  AMAZON-02 - Amazon.com, Inc., US
 10620        2244        3440  AS10620 - Telmex Colombia S.A., CO
 30036        2206        2552  MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp, US

Complete listing at https://thyme.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:2606      2:2052      3:1023      4:5         5:5219      6:207    
   7:6         8:1423      9:76       11:172      12:1113     13:766    
  14:2760     15:474      16:447      17:448      18:945      20:599    
  21:4        22:188      23:8481     24:2782     25:2        27:2743   
  28:1        29:19       31:3831     32:37       34:90       35:290    
  36:4830     37:4424     38:10113    39:1342     40:437      41:4570   
  42:2191     43:3259     44:466      45:19876    46:4966     47:462    
  48:168      49:2274     50:2010     51:914      52:1363     54:303    
  55:1172     56:11       57:328      58:2830     59:1546     60:1208   
  61:3140     62:3177     63:1697     64:6489     65:2152     66:6077   
  67:3319     68:1283     69:4092     70:1053     71:610      72:3243   
  74:3064     75:1508     76:601      77:2907     78:2133     79:1798   
  80:2373     81:2300     82:4333     83:1484     84:2203     85:3886   
  86:1093     87:2910     88:1314     89:4843     90:777      91:8492   
  92:2767     93:3030     94:4681     95:4708     96:1451     97:312    
  98:937      99:971     100:72      101:1375    102:4725    103:32363  
 104:5612    105:831     106:906     107:2949    108:1336    109:3894   
 110:2288    111:4207    112:3119    113:1982    114:2532    115:2240   
 116:2091    117:3632    118:3021    119:2082    120:2784    121:1687   
 122:3027    123:2224    124:2039    125:3036    126:158     128:1583   
 129:981     130:1708    131:2519    132:896     133:488     134:1755   
 135:638     136:1526    137:1446    138:3418    139:1794    140:1927   
 141:1736    142:2626    143:2102    144:1832    145:673     146:2193   
 147:2267    148:2807    149:3341    150:1313    151:2955    152:2394   
 153:1880    154:10014   155:2357    156:4627    157:2421    158:1602   
 159:2882    160:3884    161:2040    162:4155    163:2643    164:2432   
 165:2772    166:1311    167:2361    168:4087    169:876     170:5620   
 171:1140    172:4892    173:3484    174:898     175:1359    176:4034   
 177:5176    178:4518    179:2489    180:3398    181:4645    182:4025   
 183:2876    184:2040    185:21907   186:6474    187:5534    188:4823   
 189:4676    190:9952    191:1811    192:11823   193:9650    194:7937   
 195:5916    196:3442    197:3242    198:6312    199:6088    200:8375   
 201:6590    202:10779   203:10531   204:4747    205:3809    206:4464   
 207:4078    208:4342    209:5503    210:4900    211:2785    212:5203   
 213:4112    214:1036    215:47      216:7282    217:3737    218:1829   
 219:582     220:2214    221:1331    222:1088    223:3586   

End of report


From loganaden at gmail.com  Tue Jul  7 18:09:04 2026
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Tue, 7 Jul 2026 22:09:04 +0400
Subject: [afnog] (o/t) More countries restricting access to their AI models
Message-ID: <CAOp4FwS3xsOoB2TVc-=2i+Ja95bRPyngG3YUMniuQOkcQWn6aw@mail.gmail.com>

Hi folks,

It is unfortunate to see what is happening around the world:
https://www.reuters.com/world/beijing-is-looking-curbing-overseas-access-chinas-top-ai-models-sources-say-2026-07-07/

As I've made the point before, it's time for African countries to
build our own DNS, web, CDN, and now AI infrastructure. Supporting
local African companies is the right way forward.

Kind regards,
//Logan


From adeoyeayan at gmail.com  Tue Jul  7 21:39:54 2026
From: adeoyeayan at gmail.com (Adeoye Malumi)
Date: Tue, 7 Jul 2026 22:39:54 +0100
Subject: [afnog] (o/t) More countries restricting access to their AI
	models
In-Reply-To: <CAOp4FwS3xsOoB2TVc-=2i+Ja95bRPyngG3YUMniuQOkcQWn6aw@mail.gmail.com>
References: <CAOp4FwS3xsOoB2TVc-=2i+Ja95bRPyngG3YUMniuQOkcQWn6aw@mail.gmail.com>
Message-ID: <CAEWwMpzo5-iN--acSSMDqP-u3pcJMZx4ZtJQ3mJkSrfy2hka0g@mail.gmail.com>

Hi Logan,

I agree. The growing fragmentation of access to critical AI infrastructure
makes a strong case for Africa investing in digital sovereignty.

I think estimating the cost of developing a small indigenous model from
scratch, including data, preprocessing, training, compute, and
infrastructure, would be a good first step.

I also have experience with data preprocessing and would be happy to
collaborate or volunteer if there?s interest.

Kind regards,
Adeoye


On Tue, 7 Jul 2026 at 19:40, Loganaden Velvindron <loganaden at gmail.com>
wrote:

> Hi folks,
>
> It is unfortunate to see what is happening around the world:
>
> https://www.reuters.com/world/beijing-is-looking-curbing-overseas-access-chinas-top-ai-models-sources-say-2026-07-07/
>
> As I've made the point before, it's time for African countries to
> build our own DNS, web, CDN, and now AI infrastructure. Supporting
> local African companies is the right way forward.
>
> Kind regards,
> //Logan
>
> _______________________________________________
> afnog mailing list
> https://www.afnog.org/mailman/listinfo/afnog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20260707/31e5cf28/attachment.html>

From loganaden at gmail.com  Wed Jul  8 04:29:26 2026
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Wed, 8 Jul 2026 08:29:26 +0400
Subject: [afnog] (o/t) More countries restricting access to their AI
	models
In-Reply-To: <CAEWwMpzo5-iN--acSSMDqP-u3pcJMZx4ZtJQ3mJkSrfy2hka0g@mail.gmail.com>
References: <CAOp4FwS3xsOoB2TVc-=2i+Ja95bRPyngG3YUMniuQOkcQWn6aw@mail.gmail.com>
 <CAEWwMpzo5-iN--acSSMDqP-u3pcJMZx4ZtJQ3mJkSrfy2hka0g@mail.gmail.com>
Message-ID: <CAOp4FwQdouAX+MTZ2tPi7kGKBHE9dRZU41MtQHsmx644DsBTmQ@mail.gmail.com>

Dear Adeoye,

I agree with you. Beyond AI infrastructure, we need to ensure that the
lower levels of the stack are still under
our control. DNS, web, Email and even small things like calendar scheduling.






On Wed, 8 Jul 2026 at 01:40, Adeoye Malumi <adeoyeayan at gmail.com> wrote:
>
> Hi Logan,
>
> I agree. The growing fragmentation of access to critical AI infrastructure makes a strong case for Africa investing in digital sovereignty.
>
> I think estimating the cost of developing a small indigenous model from scratch, including data, preprocessing, training, compute, and infrastructure, would be a good first step.
>
> I also have experience with data preprocessing and would be happy to collaborate or volunteer if there?s interest.
>
> Kind regards,
> Adeoye
>
>
> On Tue, 7 Jul 2026 at 19:40, Loganaden Velvindron <loganaden at gmail.com> wrote:
>>
>> Hi folks,
>>
>> It is unfortunate to see what is happening around the world:
>> https://www.reuters.com/world/beijing-is-looking-curbing-overseas-access-chinas-top-ai-models-sources-say-2026-07-07/
>>
>> As I've made the point before, it's time for African countries to
>> build our own DNS, web, CDN, and now AI infrastructure. Supporting
>> local African companies is the right way forward.
>>
>> Kind regards,
>> //Logan
>>
>> _______________________________________________
>> afnog mailing list
>> https://www.afnog.org/mailman/listinfo/afnog


From sm+afrinic at elandsys.com  Thu Jul  9 04:41:24 2026
From: sm+afrinic at elandsys.com (sm+afrinic at elandsys.com)
Date: Wed, 08 Jul 2026 21:41:24 -0700
Subject: [afnog] Network termination point
Message-ID: <6.2.5.6.2.20260708210138.0a48d5f0@elandnews.com>

Hi Jaco,

I saw your comments about IPv6.  There is an assumption that the IPv4 
and IPv6 path are somewhat similar [1][2].  It is not always the 
case.  The comment also mentioned "European standard of 
users".  There is an article (in German) about that at 
https://www.heise.de/news/Umfrage-in-Europa-Umsetzung-der-Routerfreiheit-nach-wie-vor-problematisch-9056401.html

Your comment got me to look into the network termination point 
angle.  The optical network terminal (ONT) is where that it (it may 
be different for you).  It could be leveraged to look into the 
internal network.  If there is a concern [3] about that, it could be 
mitigated by placing another box between the ONT and the internal network.

Regards,
S. Moonesamy

1. A web browser would try the IPv6 address, wait for 250 ms and 
fallback to IPv4.
2. https://dl.acm.org/doi/pdf/10.1145/3730567.3732925
3. It depends on the local regulations.



From jordi.palet at consulintel.es  Thu Jul  9 07:45:42 2026
From: jordi.palet at consulintel.es (jordi.palet at consulintel.es)
Date: Thu, 9 Jul 2026 09:45:42 +0200
Subject: [afnog] Network termination point
In-Reply-To: <6.2.5.6.2.20260708210138.0a48d5f0@elandnews.com>
References: <6.2.5.6.2.20260708210138.0a48d5f0@elandnews.com>
Message-ID: <77AB58A8-28C6-49B8-9BBB-69C760C2FF46@consulintel.es>

Hi,

Exactly. Working with customers in many EU countries, the reality is that many operators try to avoid you enter into the CPE, but if you ask them, they are enforced to provide the PWD. All the EU countries have a regulator figure that accepts ?quick? complains from the users and they act really fast on that. Just telling the operator ?if you don?t give me full access I will place a complain to the regulator?,  it works. Of course many people don?t know that, but that?s a different history, because google will tell you quickly.

Usually regulators understand that the ONT is still part of the operator network. So if they provide you an integrated CPE with ONT, you must use either:
1) A certified ONT (for example in Spain Movistar/Telefonica has 8 certified models for up to 1 Gbps symmetric GPON, which you can buy by less than 10-15 Euros), and then you place whatever CPE you want behind it.
2) A certified router with ONT. In this case you have much less models to choose.

Regarding the IPv6 paths and Happy Eyeballs (HE), if you read the relevant RFC8305 (v2, v1 was 6555), you will see that the first timer is only 50ms. If the resolution of AAAA is slower than the A one. You already have a fallback. This is what could create already lower % of IPv6 traffic than expected. Of course, then you have the other timer, which adds on top of that. Vendors can adapt those timers to their own needs, typically based on telemetry data that collect from users.

In fact, Apple tested this HE implementation during 2 years with real users around the world before proposing it in IETF, and from those measurements they gathered the initial suggested timings.

One of the problems with HE is that many operators, unfortunately, don?t pay the same attention and monitoring to IPv6 than IPv4. So if there are too many fallbacks to IPv4, you could know it. Also HE itself doesn?t have a ?reporting? mechanism. I?ve proposed it for years in IETF, but didn?t gained sufficient consensus.
https://www.ietf.org/archive/id/draft-palet-v6ops-he-reporting-00.txt
https://www.ietf.org/archive/id/draft-xie-v6ops-network-happyeyeballs-00.txt

In any case, this situation is going to change a bit, becase now we have more problem, such as the fallback from QUIC to TCP, etc. If you take a look at the chapter and document of this WG, which is progressing quickly, now the reporting should be an integral part of the protocol:

https://datatracker.ietf.org/wg/happy/about/


Regards,
Jordi

@jordipalet

> El 9 jul 2026, a las 6:41, sm+afrinic at elandsys.com escribi?:
> 
> Hi Jaco,
> 
> I saw your comments about IPv6.  There is an assumption that the IPv4 and IPv6 path are somewhat similar [1][2].  It is not always the case.  The comment also mentioned "European standard of users".  There is an article (in German) about that at https://www.heise.de/news/Umfrage-in-Europa-Umsetzung-der-Routerfreiheit-nach-wie-vor-problematisch-9056401.html
> 
> Your comment got me to look into the network termination point angle.  The optical network terminal (ONT) is where that it (it may be different for you).  It could be leveraged to look into the internal network.  If there is a concern [3] about that, it could be mitigated by placing another box between the ONT and the internal network.
> 
> Regards,
> S. Moonesamy
> 
> 1. A web browser would try the IPv6 address, wait for 250 ms and fallback to IPv4.
> 2. https://dl.acm.org/doi/pdf/10.1145/3730567.3732925
> 3. It depends on the local regulations.
> 
> 
> _______________________________________________
> afnog mailing list
> https://www.afnog.org/mailman/listinfo/afnog



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20260709/028459fc/attachment.html>

From sm+afrinic at elandsys.com  Thu Jul  9 10:32:59 2026
From: sm+afrinic at elandsys.com (sm+afrinic at elandsys.com)
Date: Thu, 09 Jul 2026 03:32:59 -0700
Subject: [afnog] Network termination point
In-Reply-To: <f72da3d3-53db-46d8-97ec-d95b26731eeb@uls.co.za>
References: <6.2.5.6.2.20260708210138.0a48d5f0@elandnews.com>
 <f72da3d3-53db-46d8-97ec-d95b26731eeb@uls.co.za>
Message-ID: <6.2.5.6.2.20260709010720.0f8ed6b8@elandnews.com>

Hi Jaco, Jordi,
At 12:01 AM 09-07-2026, Jaco Kroon wrote:
>I'm assuming you're referring to the speed commentary?

Yes.

>There are a few assumptions that I make with a high degree of certainty.
>
>1.  FNO will hand off to the C(P)E using a 1Gbps *ethernet* port.
>2.  FNO will shape/police to the relevant speed 
>at L3 on the egress 1Gbps port to the customer.
>2.1.  Specifically for 1Gbps services, this will 
>effectively become an L1 measured service - 
>which is the values I calculated; else
>2.2.  For <1Gbps services, the effect, due to 
>being able to ignore L1+L2 overheads, will be less pronounced but still there.
>3.  Customers will fire up speedtest (typically 
>Ookla) and use the download and upload speed 
>values as a measure of how good a specific service performs.
>
>The point I was trying to make isn't that 
>IPv4 >>> IPv6, I *firmly* believe IPv6 is the 
>way to go and that actual performance that 
>matters in pretty much every possible imaginable 
>scenario should be better.  My point is that *consumers* don't see it this

I view IP[insert number] as an address.  The way 
to go depends on how it works for me.  It may be 
different for you as we don't, for example, use the same network operator.

>  way, and the only metric that matters, and on 
> which FNO+ISP get measured by *consumers* is 
> raw speed as measured by tools such as Ookla 
> Speedtest - which invariably will ignore 
> overheads and at best count full L7 
> throughput.  My calculation didn't even 
> consider L5 (TLS) overheads, which fortunately 
> is less since typically a speedtest will pack 
> 16KB at a time here, with a tiny header (IIRC 
> about 5 bytes header, 16-24 byte HMAC, and 
> between 1 and 16 bytes tail padding (Google 
> says between 21 and 40 bytes), even working on 
> the higher value we're talking <0.25% overhead on this layer.

The above would be how it works in ideal conditions.

>This mis-metric in my opinion is also a large 
>reason as to why we suffer so greatly from 
>problems such as buffer bloat.  Because if raw 
>throughput is what you get measured on you want 
>to make sure you keep that link capacity maxed 
>out.  The simplest way to achieve that is to make the buffers larger.

The customer/consumer does not even know about the above.

>The point I'm trying to make towards Jordi is 
>that you cannot punish network operators for 
>shitty end-customer behaviour, which is exactly 
>what his policy proposal will do.  If the 
>measurement changes to something more sensible, 
>I'll be the first to support his proposal, but 
>raw percentage of traffic must be IPv6 is a 
>shitty measure.  I have proposed alternatives.  No response.

I have not even read what the proposal was trying 
to do.  I just saw an email from Jordi.  I'll comment below.

At 12:45 AM 09-07-2026, jordi.palet at consulintel.es wrote:
>Exactly. Working with customers in many EU 
>countries, the reality is that many operators 
>try to avoid you enter into the CPE, but if you 
>ask them, they are enforced to provide the PWD. 
>All the EU countries have a regulator figure 
>that accepts "quick"? complains from the users 
>and they act really fast on that. Just telling 
>the operator if you don't give me full access I 
>will place a complain to the regulator,  it 
>works. Of course many people don't know that, 
>but that's a different history, because google will tell you quickly.

Here's what I found (in German): 
https://fsfe.org/news/2025/news-20250124-01.de.html 
That worked because there is actually a group of 
people who will not give up easily.

The regulations are not the same in every 
country.  I doubt that there is a regulation 
similar to the one in the European Union over 
here.  There isn't anything similar to the FSFE over here.

>Usually regulators understand that the ONT is 
>still part of the operator network. So if they 
>provide you an integrated CPE with ONT, you must use either:
>1) A certified ONT (for example in Spain 
>Movistar/Telefonica has 8 certified models for 
>up to 1 Gbps symmetric GPON, which you can buy 
>by less than 10-15 Euros), and then you place whatever CPE you want behind it.
>2) A certified router with ONT. In this case you 
>have much less models to choose.

There isn't any choice of certified ONT over here.

>Regarding the IPv6 paths and Happy Eyeballs 
>(HE), if you read the relevant RFC8305 (v2, v1 
>was 6555), you will see that the first timer is 
>only 50ms. If the resolution of AAAA is slower 
>than the A one. You already have a fallback. 
>This is what could create already lower % of 
>IPv6 traffic than expected. Of course, then you 
>have the other timer, which adds on top of that. 
>Vendors can adapt those timers to their own 
>needs, typically based on telemetry data that collect from users.

I looked up the RFC before I sent this comment: 
https://mailarchive.ietf.org/arch/msg/v6ops/KseRpIh2LqJoNxlo8rq977nLKug

The user will turn off the IPv6 stuff when it is 
the suggested solution to the "speed" problem.

>In fact, Apple tested this HE implementation 
>during 2 years with real users around the world 
>before proposing it in IETF, and from those 
>measurements they gathered the initial suggested timings.

The "real users around the world" is 
imprecise.  As an example, Jaco probably does not 
reside near me.  His measurements would give him 
a better view than, for example, Apple.

>One of the problems with HE is that many 
>operators, unfortunately, don't pay the same 
>attention and monitoring to IPv6 than IPv4. So 
>if there are too many fallbacks to IPv4, you 
>could know it. Also HE itself doesn't have a 
>"reporting"? mechanism. I've proposed it for 
>years in IETF, but didn't gained sufficient consensus.

If I may, it's not really the task of the 
operator to track the number of IPv6 connection 
items which failed.  I would defer to the 
operators as I don't operate their networks.

>In any case, this situation is going to change a 
>bit, becase now we have more problem, such as 
>the fallback from QUIC to TCP, etc. If you take 
>a look at the chapter and document of this WG, 
>which is progressing quickly, now the reporting 
>should be an integral part of the protocol:

I don't usually enable data collection.  I doubt 
that is the position of the users over here; it's 
their choice to make. The last presentation I 
watched about QUIC (it was several years ago) 
explained that what the documented 
assumptions/mechanisms did not match how things worked in the real world.

Regards,
S. Moonesamy  



From jordi.palet at consulintel.es  Thu Jul  9 14:04:36 2026
From: jordi.palet at consulintel.es (jordi.palet at consulintel.es)
Date: Thu, 9 Jul 2026 16:04:36 +0200
Subject: [afnog] Network termination point
In-Reply-To: <6.2.5.6.2.20260709010720.0f8ed6b8@elandnews.com>
References: <6.2.5.6.2.20260708210138.0a48d5f0@elandnews.com>
 <f72da3d3-53db-46d8-97ec-d95b26731eeb@uls.co.za>
 <6.2.5.6.2.20260709010720.0f8ed6b8@elandnews.com>
Message-ID: <183163F6-953C-4F52-AB35-EF656344243B@consulintel.es>

Responding below in-line just a couple of points.

Saludos,
Jordi

@jordipalet

> El 9 jul 2026, a las 12:32, sm+afrinic at elandsys.com escribi?:
> 
> Hi Jaco, Jordi,
> At 12:01 AM 09-07-2026, Jaco Kroon wrote:
>> I'm assuming you're referring to the speed commentary?
> 
> Yes.
> 
>> There are a few assumptions that I make with a high degree of certainty.
>> 
>> 1.  FNO will hand off to the C(P)E using a 1Gbps *ethernet* port.
>> 2.  FNO will shape/police to the relevant speed at L3 on the egress 1Gbps port to the customer.
>> 2.1.  Specifically for 1Gbps services, this will effectively become an L1 measured service - which is the values I calculated; else
>> 2.2.  For <1Gbps services, the effect, due to being able to ignore L1+L2 overheads, will be less pronounced but still there.
>> 3.  Customers will fire up speedtest (typically Ookla) and use the download and upload speed values as a measure of how good a specific service performs.
>> 
>> The point I was trying to make isn't that IPv4 >>> IPv6, I *firmly* believe IPv6 is the way to go and that actual performance that matters in pretty much every possible imaginable scenario should be better.  My point is that *consumers* don't see it this
> 
> I view IP[insert number] as an address.  The way to go depends on how it works for me.  It may be different for you as we don't, for example, use the same network operator.
> 
>> way, and the only metric that matters, and on which FNO+ISP get measured by *consumers* is raw speed as measured by tools such as Ookla Speedtest - which invariably will ignore overheads and at best count full L7 throughput.  My calculation didn't even consider L5 (TLS) overheads, which fortunately is less since typically a speedtest will pack 16KB at a time here, with a tiny header (IIRC about 5 bytes header, 16-24 byte HMAC, and between 1 and 16 bytes tail padding (Google says between 21 and 40 bytes), even working on the higher value we're talking <0.25% overhead on this layer.
> 
> The above would be how it works in ideal conditions.
> 
>> This mis-metric in my opinion is also a large reason as to why we suffer so greatly from problems such as buffer bloat.  Because if raw throughput is what you get measured on you want to make sure you keep that link capacity maxed out.  The simplest way to achieve that is to make the buffers larger.
> 
> The customer/consumer does not even know about the above.
> 
>> The point I'm trying to make towards Jordi is that you cannot punish network operators for shitty end-customer behaviour, which is exactly what his policy proposal will do.  If the measurement changes to something more sensible, I'll be the first to support his proposal, but raw percentage of traffic must be IPv6 is a shitty measure.  I have proposed alternatives.  No response.
> 
> I have not even read what the proposal was trying to do.  I just saw an email from Jordi.  I'll comment below.
> 
> At 12:45 AM 09-07-2026, jordi.palet at consulintel.es wrote:
>> Exactly. Working with customers in many EU countries, the reality is that many operators try to avoid you enter into the CPE, but if you ask them, they are enforced to provide the PWD. All the EU countries have a regulator figure that accepts "quick"? complains from the users and they act really fast on that. Just telling the operator if you don't give me full access I will place a complain to the regulator,  it works. Of course many people don't know that, but that's a different history, because google will tell you quickly.
> 
> Here's what I found (in German): https://fsfe.org/news/2025/news-20250124-01.de.html That worked because there is actually a group of people who will not give up easily.
> 
> The regulations are not the same in every country.  I doubt that there is a regulation similar to the one in the European Union over here.  There isn't anything similar to the FSFE over here.

Even better if you don?t have a regulator asking to enforce that, because it may mean it is already allowed without an enforcement.

I?ve worked in a few projects in different countries in Africa, and there was not in any of them an enforcement to use the operator provided equipment, but just a few doesn?t provide a good average.

> 
>> Usually regulators understand that the ONT is still part of the operator network. So if they provide you an integrated CPE with ONT, you must use either:
>> 1) A certified ONT (for example in Spain Movistar/Telefonica has 8 certified models for up to 1 Gbps symmetric GPON, which you can buy by less than 10-15 Euros), and then you place whatever CPE you want behind it.
>> 2) A certified router with ONT. In this case you have much less models to choose.
> 
> There isn't any choice of certified ONT over here.

It basically depends on what OLT you have. There are standards, but some vendors do weird things that disallow some other vendors of ONTs being used ?correctly?. This may imply that the TDMA slots among the ONT in the passive fiber network (so shared by multiple ONTs), aren?t properly ?sequenced? so a badly behaving ONT can impact the speed of other users and it is difficult to diagnose. So basically the OLT may ?block? ONTs that aren?t identified as ?certified?.

> 
>> Regarding the IPv6 paths and Happy Eyeballs (HE), if you read the relevant RFC8305 (v2, v1 was 6555), you will see that the first timer is only 50ms. If the resolution of AAAA is slower than the A one. You already have a fallback. This is what could create already lower % of IPv6 traffic than expected. Of course, then you have the other timer, which adds on top of that. Vendors can adapt those timers to their own needs, typically based on telemetry data that collect from users.
> 
> I looked up the RFC before I sent this comment: https://mailarchive.ietf.org/arch/msg/v6ops/KseRpIh2LqJoNxlo8rq977nLKug
> 
> The user will turn off the IPv6 stuff when it is the suggested solution to the "speed" problem.

And this has been done by some gaming companies, because their games have bugs. A terrible thing to do. Who suggests that IPv6 should be disabled because there is a bug, even not related to IPv6, but only visible when you enable IPv6, should be in jail. The right thing to do is to fix your bug.

> 
>> In fact, Apple tested this HE implementation during 2 years with real users around the world before proposing it in IETF, and from those measurements they gathered the initial suggested timings.
> 
> The "real users around the world" is imprecise.  As an example, Jaco probably does not reside near me.  His measurements would give him a better view than, for example, Apple.

Sorry, I should have said worldwide. They tested in every iOS user in the world using telemetry tools.

> 
>> One of the problems with HE is that many operators, unfortunately, don't pay the same attention and monitoring to IPv6 than IPv4. So if there are too many fallbacks to IPv4, you could know it. Also HE itself doesn't have a "reporting"? mechanism. I've proposed it for years in IETF, but didn't gained sufficient consensus.
> 
> If I may, it's not really the task of the operator to track the number of IPv6 connection items which failed.  I would defer to the operators as I don't operate their networks.

Nooo, this is terrible. All the operators, if they really care about providing a good service, should be doing all kind of measurements and monitoring. It is a must for any operator, otherwise, don?t call yourself an operator!

> 
>> In any case, this situation is going to change a bit, becase now we have more problem, such as the fallback from QUIC to TCP, etc. If you take a look at the chapter and document of this WG, which is progressing quickly, now the reporting should be an integral part of the protocol:
> 
> I don't usually enable data collection.  I doubt that is the position of the users over here; it's their choice to make. The last presentation I watched about QUIC (it was several years ago) explained that what the documented assumptions/mechanisms did not match how things worked in the real world.

QUIC  is already over 50%.

https://w3techs.com/technologies/details/ce-http3

https://www.cellstream.com/2025/02/14/an-update-on-quic-adoption-and-traffic-levels/

https://blog.apnic.net/2025/06/17/a-quic-progress-report/

This is very easy to understand, as is similar to what happens with IPv6.

If the top-25 destinations (even just 5-10 top) such as Meta, Google, and few CDNs, deploy a protocol and uses OSs (and networks) are able to use it, then the operator traffic for that operator will jump from 0 to 70-75% overnight, as those content providers are the ones offering the 70-75% (or even more) contents in Internet.

The advantage of QUIC compared with IPv6, is that the operator doesn?t need to do anything in their network.

> 
> Regards,
> S. Moonesamy  



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20260709/a25586eb/attachment.html>

From sm+afrinic at elandsys.com  Thu Jul  9 18:12:19 2026
From: sm+afrinic at elandsys.com (sm+afrinic at elandsys.com)
Date: Thu, 09 Jul 2026 11:12:19 -0700
Subject: [afnog] Network termination point
In-Reply-To: <183163F6-953C-4F52-AB35-EF656344243B@consulintel.es>
References: <6.2.5.6.2.20260708210138.0a48d5f0@elandnews.com>
 <f72da3d3-53db-46d8-97ec-d95b26731eeb@uls.co.za>
 <6.2.5.6.2.20260709010720.0f8ed6b8@elandnews.com>
 <183163F6-953C-4F52-AB35-EF656344243B@consulintel.es>
Message-ID: <6.2.5.6.2.20260709094656.0a7bcce8@elandnews.com>

Hi Jordi,
At 07:04 AM 09-07-2026, jordi.palet at consulintel.es wrote:
>Even better if you don't have a regulator asking 
>to enforce that, because it may mean it is 
>already allowed without an enforcement.

The regulations where I am are different from the 
ones where you are.  I would have to seek expert help on that.

>I've worked in a few projects in different 
>countries in Africa, and there was not in any of 
>them an enforcement to use the operator provided 
>equipment, but just a few doesn't provide a good average.

I don't know much about that.  The people I have met use mobile data.

>It basically depends on what OLT you have. There 
>are standards, but some vendors do weird things 
>that disallow some other vendors of ONTs being 
>used "correctly"?. This may imply that the TDMA 
>slots among the ONT in the passive fiber network 
>(so shared by multiple ONTs), aren't properly 
>"sequenced" so a badly behaving ONT can impact 
>the speed of other users and it is difficult to 
>diagnose. So basically the OLT may "block"? ONTs 
>that aren't identified as "certified".

Here's the one which was used before: 
https://www.elandsys.com/r/00576 A SFP ONT stick 
would cost approximately EUR 9.  The are some 
younger people who are very efficient at customer 
deliveries.  I never got around to ask them to 
get me one.  I looked up the lock-in techniques 
used to keep the ONT vendor-specific a few years ago.

>And this has been done by some gaming companies, 
>because their games have bugs. A terrible thing 
>to do. Who suggests that IPv6 should be disabled 
>because there is a bug, even not related to 
>IPv6, but only visible when you enable IPv6, 
>should be in jail. The right thing to do is to fix your bug.

My younger friends are into gaming.  I agree with 
you on the right fix.  I would not tell them that 
as they are very good at finding the quick fixes.

>Sorry, I should have said worldwide. They tested 
>in every iOS user in the world using telemetry tools.

It's okay.

>Nooo, this is terrible. All the operators, if 
>they really care about providing a good service, 
>should be doing all kind of measurements and 
>monitoring. It is a must for any operator, 
>otherwise, don't call yourself an operator!

Good service does not necessarily equate with 
good for business.  The monitoring is most likely outsourced to someone else.

>QUIC  is already over 50%.
>
>https://w3techs.com/technologies/details/ce-http3
>
>https://www.cellstream.com/2025/02/14/an-update-on-quic-adoption-and-traffic-levels/
>
>https://blog.apnic.net/2025/06/17/a-quic-progress-report/
>
>This is very easy to understand, as is similar to what happens with IPv6.
>
>If the top-25 destinations (even just 5-10 top) 
>such as Meta, Google, and few CDNs, deploy a 
>protocol and uses OSs (and networks) are able to 
>use it, then the operator traffic for that 
>operator will jump from 0 to 70-75% overnight, 
>as those content providers are the ones offering 
>the 70-75% (or even more) contents in Internet.
>
>The advantage of QUIC compared with IPv6, is 
>that the operator doesn't need to do anything in their network.

One of the listed reports was written with 
ChatGPT.  I shared this a few days ago: 
https://www.elandsys.com/r/20790  It explains the 
changes.  It's easier to change things when one 
has some control over both the server side and the consumer side.

Regards,
S. Moonesamy  



