From fgont en si6networks.com Sat Aug 1 05:26:12 2026 From: fgont en si6networks.com (Fernando Gont) Date: Sat, 1 Aug 2026 05:26:12 -0300 Subject: [lacnog] The mistakes and missed opportunities in the design of IPv6 Message-ID: Estimados, Dado que en otro thread hubieron discusiones sobre cuestiones de diseno de IPv6, les comparto este articulo y slides (de Ole Troan): * https://medium.com/@oletroan/the-mistakes-and-missed-opportunities-in-ipv6-d88ceb3d7feb * https://grnog.indico.nogalliance.org/event/11/contributions/118/attachments/97/166/grnog18-ipv6-mistakes.pdf Y como tambien hubo una discusion sobre dudas sobre IPv6, y reutilizar el conocimiento de IPv4, les comparto estos dos (algo mas extensos), mios: * https://www.internetsociety.org/wp-content/uploads/2019/03/deploy360-ipv6-security-v1.0.pdf * https://www.internetsociety.org/wp-content/uploads/2019/02/Deploy360-IPv6-Security-FAQ.pdf Buen finde, -- Fernando Gont SI6 Networks e-mail: fgont en si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 From weeklyipv6report en gmail.com Thu Aug 6 11:50:40 2026 From: weeklyipv6report en gmail.com (weeklyipv6report en gmail.com) Date: Thu, 06 Aug 2026 07:50:40 -0700 (PDT) Subject: [lacnog] Weekly Global IPv6 Routing Table Summary Message-ID: <6a749f40.0c0d0188.b099d.8acd@mx.google.com> This is an automated weekly mailing describing the state of the Global IPv6 Routing Table as seen from route-views.routeviews.org The posting is sent to VENOG, APOPS, PACNOG and LACNOG. If you wish to be added please send an email to: info.venog en gmail.com Global Analysis Summary -------------------------------------------------------------------------------------- BGP routing table entries examined: 254525 Prefix with the most prepends: {'PREFIX': '2803:6850:1::/48', 'Count': 29, 'AS': '273113'} Unidentified prefixes: 0 Number of AS_SET found in the Routing Table: 0 Longest Global AS PATH: 33 Prefixes identified as IANA: 9 Global Average Prefix Length: 42.96 Number of /48s globally: 116643 Prefixes after maximum aggregation (per Origin AS): 141870 IPv6 deaggregation factor: 1.8 Global - Prefixes with a valid RPKI status: 205193 Global - Prefixes with an invalid RPKI status: 1298 Global - ROA?uncovered prefixes: 48034 Total ASes present in the Internet Routing Table: 36872 Global - Average number of prefixes according to the number of ASes: 6.9 Number of 32-bit ASes globally: 23924 Number of 16-bit ASes globally: 12948 Number of ASes that are only origin: 33613 Number of 16-bit ASes that are only origin: 11022 Number of 32-bit ASes that are only origin: 22591 Number of ASes that are only transit: 201 Number of 16-bit ASes that are only transit: 130 Number of 32-bit ASes that are only transit: 71 Number of Transit ASes that also announce prefixes: 3259 Number of bogon 16-bit ASNs visible in the Routing Table: 0 Number of bogon 32-bit ASNs visible in the Routing Table: 0 Unidentified ASes: 0 APNIC Region Analysis Summary -------------------------------------------------------------------------------------- APNIC IPv6 prefixes: 2001:200::/23 2001:c00::/23 2001:e00::/23 2001:4400::/23 2001:8000::/19 2001:a000::/20 2001:b000::/20 2400::/12 2410::/12 Number of prefixes analyzed in APNIC: 87447 Average number of prefixes according to the number of ASes in APNIC: 9.0 Average Prefix Length in APNIC: 43.52 Number of /48s in APNIC: 34683 Longest PATH in APNIC: 25 Prefix with most prepends in APNIC {'PREFIX': '2001:DF4:5FC0::/48', 'Count': 20, 'AS': '138804'} Prefixes after maximum aggregation (per Origin AS): 38726 IPv6 deaggregation factor: 2.2 APNIC - Prefixes with a valid RPKI status: 79087 APNIC - Prefixes with an invalid RPKI status: 870 APNIC - ROA?uncovered prefixes: 7490 Number of ASes in APNIC: 9717 Number of 32-bit ASes in APNIC: 7962 Number of 16-bit ASes that are only origin in APNIC: 1423 Number of 32-bit ASes that are only origin in APNIC: 7745 Number of 16-bit ASes that are only transit in APNIC: 36 Number of 32-bit ASes that are only transit in APNIC: 22 Number of Transit ASes that also announce prefixes in APNIC: 548 ARIN Region Analysis Summary -------------------------------------------------------------------------------------- ARIN IPv6 prefixes: 2001:400::/23 2001:1800::/23 2001:4800::/23 2600::/12 2610::/23 2620::/23 2630::/12 Number of prefixes analyzed in ARIN: 42709 Average number of prefixes according to the number of ASes in ARIN: 8.04 Average Prefix Length in ARIN: 44.52 Number of /48s in ARIN: 24220 Longest AS PATH in ARIN: 28 Prefix with most prepends in ARIN {'PREFIX': '2604:5500::/42', 'Count': 25, 'AS': '19165'} Prefixes after maximum aggregation (per Origin AS): 35347 IPv6 deaggregation factor: 1.6 ARIN - Prefixes with a valid RPKI status: 32469 ARIN - Prefixes with an invalid RPKI status: 57 ARIN - ROA?uncovered prefixes: 10183 Number of ASes in ARIN: 5313 Number of 32-bit ASes in ARIN: 1603 Number of 16-bit ASes that are only origin in ARIN: 3309 Number of 32-bit ASes that are only origin in ARIN: 1556 Number of 16-bit ASes that are only transit in ARIN: 30 Number of 32-bit ASes that are only transit in ARIN: 6 Number of Transit ASes that also announce prefixes in ARIN: 445 LACNIC Region Analysis Summary -------------------------------------------------------------------------------------- LACNIC IPv6 prefixes: 2001:1200::/23 2800::/12 Number of prefixes analyzed in LACNIC: 54932 Average number of prefixes according to the number of ASes in LACNIC: 5.74 Average Prefix Length in LACNIC: 41.1 Number of /48s in LACNIC: 20923 Longest AS PATH in LACNIC: 33 Prefix with most prepends in LACNIC {'PREFIX': '2803:6850:1::/48', 'Count': 29, 'AS': '273113'} Prefixes after maximum aggregation (per Origin AS): 32585 IPv6 deaggregation factor: 1.61 LACNIC - Prefixes with a valid RPKI status: 34524 LACNIC - Prefixes with an invalid RPKI status: 111 LACNIC - ROA?uncovered prefixes: 20297 Number of ASes in LACNIC: 9576 Number of 32-bit ASes in LACNIC: 8144 Number of 16-bit ASes that are only origin in LACNIC: 1106 Number of 32-bit ASes that are only origin in LACNIC: 7320 Number of 16-bit ASes that are only transit in LACNIC: 5 Number of 32-bit ASes that are only transit in LACNIC: 15 Number of Transit ASes that also announce prefixes in LACNIC: 1146 AFRINIC Region Analysis Summary -------------------------------------------------------------------------------------- AFRINIC IPv6 prefixes: 2001:4200::/23 2c00::/12 Number of prefixes analyzed in AFRINIC: 4309 Average number of prefixes according to the number of ASes in AFRINIC: 6.44 Average Prefix Length in AFRINIC: 43.65 Number of /48s in AFRINIC: 2412 Longest AS PATH in AFRINIC: 16 Prefix with most prepends in AFRINIC {'PREFIX': '2001:43FD:F000::/48', 'Count': 12, 'AS': '37440'} Prefixes after maximum aggregation (per Origin AS): 1701 IPv6 deaggregation factor: 2.39 AFRINIC - Prefixes with a valid RPKI status: 3000 AFRINIC - Prefixes with an invalid RPKI status: 0 AFRINIC - ROA?uncovered prefixes: 1309 Number of ASes in AFRINIC: 669 Number of 32-bit ASes in AFRINIC: 393 Number of 16-bit ASes that are only origin in AFRINIC: 224 Number of 32-bit ASes that are only origin in AFRINIC: 378 Number of 16-bit ASes that are only transit in AFRINIC: 3 Number of 32-bit ASes that are only transit in AFRINIC: 2 Number of Transit ASes that also announce prefixes in AFRINIC: 67 RIPE Region Analysis Summary --------------------------------------------------------------------------------- RIPE IPv6 prefixes: 2001:600::/23 2001:800::/22 2001:1400::/22 2001:1a00::/23 2001:1c00::/22 2001:2000::/19 2001:4000::/23 2001:4600::/23 2001:4a00::/23 2001:4c00::/23 2001:5000::/20 2003::/18 2a00::/12 2a10::/12 Number of prefixes analyzed in RIPE: 65119 Average number of prefixes according to the number of ASes in RIPE: 5.62 Average Prefix Length in RIPE: 42.7 Number of /48s in RIPE: 34399 Longest AS PATH in RIPE: 30 Prefix with most prepends in RIPE {'PREFIX': '2A06:9801:111::/48', 'Count': 20, 'AS': '204261'} Prefixes after maximum aggregation (per Origin AS): 34148 IPv6 deaggregation factor: 1.67 RIPE - Prefixes with a valid RPKI status: 56112 RIPE - Prefixes with an invalid RPKI status: 260 RIPE - ROA?uncovered prefixes: 8747 Number of ASes in RIPE: 11597 Number of 32-bit ASes in RIPE: 5815 Number of 16-bit ASes that are only origin in RIPE: 4956 Number of 32-bit ASes that are only origin in RIPE: 5585 Number of 16-bit ASes that are only transit in RIPE: 55 Number of 32-bit ASes that are only transit in RIPE: 23 Number of Transit ASes that also announce prefixes in RIPE: 1053 End of report Based on Philip Smith's IPv4 Weekly Report Hosted by LACNIC From cscora en apnic.net Fri Aug 7 15:04:09 2026 From: cscora en apnic.net (Routing Table Analysis Role Account) Date: Sat, 8 Aug 2026 04:04:09 +1000 (AEST) Subject: [lacnog] Weekly Global IPv4 Routing Table Report In-Reply-To: 20260808.040001@thyme.apnic.net Message-ID: <20260807180409.42495C1384@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 en lists.apnic.net. For historical data, please see https://thyme.apnic.net. If you have any comments please contact Philip Smith . IPv4 Routing Table Report 04:00 +10GMT Sat 08 Aug, 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: 1067434 Prefixes after maximum aggregation (per Origin AS): 409019 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 527192 Number of IPv4 prefixes with a valid ROA: 729400 Number of IPv4 prefixes with an invalid ROA: 1683 Number of IPv4 prefixes with no ROA: 336351 Total ASes present in the Internet Routing Table: 79012 Prefixes per ASN: 13.51 Origin-only ASes present in the Internet Routing Table: 67900 Origin ASes announcing only one prefix: 27693 Transit ASes present in the Internet Routing Table: 11112 Transit-only ASes present in the Internet Routing Table: 606 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: 1287 Number of instances of unregistered ASNs: 1337 Number of 32-bit ASNs allocated by the RIRs: 50748 Number of 32-bit ASNs visible in the Routing Table: 41288 Prefixes from 32-bit ASNs in the Routing Table: 236859 Number of bogon 32-bit ASNs visible in the Routing Table: 137 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 494 Number of addresses announced to Internet: 3118732032 Equivalent to 185 /8s, 228 /16s and 19 /24s Percentage of available address space announced: 84.2 Percentage of allocated address space announced: 84.2 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: 349172 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 292789 Total APNIC prefixes after maximum aggregation: 84950 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 278558 Unique aggregates announced from the APNIC address blocks: 109120 APNIC Region origin ASes present in the Internet Routing Table: 15335 APNIC Prefixes per ASN: 18.16 APNIC Region origin ASes announcing only one prefix: 4751 APNIC Region transit ASes present in the Internet Routing Table: 2022 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 37 Number of APNIC region 32-bit ASNs visible in the Routing Table: 10918 Number of APNIC addresses announced to Internet: 749228928 Equivalent to 44 /8s, 168 /16s and 83 /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: 308562 Total ARIN prefixes after maximum aggregation: 138343 ARIN Deaggregation factor: 2.23 Prefixes being announced from the ARIN address blocks: 306972 Unique aggregates announced from the ARIN address blocks: 150502 ARIN Region origin ASes present in the Internet Routing Table: 19501 ARIN Prefixes per ASN: 15.74 ARIN Region origin ASes announcing only one prefix: 7151 ARIN Region transit ASes present in the Internet Routing Table: 1907 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: 5715 Number of ARIN addresses announced to Internet: 1348075008 Equivalent to 80 /8s, 89 /16s and 254 /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: 296242 Total RIPE prefixes after maximum aggregation: 146564 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 301121 Unique aggregates announced from the RIPE address blocks: 196217 RIPE Region origin ASes present in the Internet Routing Table: 29670 RIPE Prefixes per ASN: 10.15 RIPE Region origin ASes announcing only one prefix: 12274 RIPE Region transit ASes present in the Internet Routing Table: 4024 Average RIPE Region AS path length visible: 4.8 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 13683 Number of RIPE addresses announced to Internet: 749176192 Equivalent to 44 /8s, 167 /16s and 133 /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: 130726 Total LACNIC prefixes after maximum aggregation: 31409 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 125104 Unique aggregates announced from the LACNIC address blocks: 51095 LACNIC Region origin ASes present in the Internet Routing Table: 11476 LACNIC Prefixes per ASN: 10.90 LACNIC Region origin ASes announcing only one prefix: 2775 LACNIC Region transit ASes present in the Internet Routing Table: 2602 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: 9551 Number of LACNIC addresses announced to Internet: 168372736 Equivalent to 10 /8s, 9 /16s and 42 /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: 37828 Total AfriNIC prefixes after maximum aggregation: 7027 AfriNIC Deaggregation factor: 5.38 Prefixes being announced from the AfriNIC address blocks: 55185 Unique aggregates announced from the AfriNIC address blocks: 19832 AfriNIC Region origin ASes present in the Internet Routing Table: 2051 AfriNIC Prefixes per ASN: 26.91 AfriNIC Region origin ASes announcing only one prefix: 742 AfriNIC Region transit ASes present in the Internet Routing Table: 384 Average AfriNIC Region AS path length visible: 5.3 Max AfriNIC Region AS path length visible: 54 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 1421 Number of AfriNIC addresses announced to Internet: 103615232 Equivalent to 6 /8s, 45 /16s and 11 /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 14200 8919 100 CHINAMOBILE-CN - China Mobile Communicati 7545 5837 818 450 TPG-INTERNET-AP - TPG Telecom Limited, AU 4538 5070 4192 74 ERX-CERNET-BKB - China Education and Rese 9498 5061 558 341 BBIL-AP - BHARTI Airtel Ltd., IN 18403 4651 347 24 FPT-VN - FPT Telecom Company, VN 7552 4026 1331 24 VIETEL-AS-AP - Viettel Group, VN 7713 3766 1044 63 telkomnet-as-ap - PT Telekomunikasi Indon 17561 3658 230 636 LCS-AS-AP - LARUS Limited, HK 56046 3596 887 179 CMNET-Jiangsu-AP - China Mobile communica 45899 3396 1868 99 VNPT-AS-VN - VNPT Corp, VN 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 15711 41558 5640 AMAZON-02 - Amazon.com, Inc., US 22773 4810 3182 373 ASN-CXA-ALL-CCI-22773-RDC - Cox Communica 11492 4617 307 1126 CABLEONE - CABLE ONE, INC., US 7155 3992 286 98 VIASAT-SP-BACKBONE - ViaSat,Inc., US 6327 3731 1305 75 SHAW - Shaw Communications, CA 396982 3461 4879 547 GOOGLE-CLOUD-PLATFORM - Google LLC, US 36352 3191 238 1114 AS-COLOCROSSING - HostPapa, US 749 3135 54727 2386 DNIC-AS-00749 - United States Department 7029 2718 2534 878 WINDSTREAM - Windstream Communications LL 31898 2583 1325 1141 ORACLE-BMC-31898 - Oracle Corporation, 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 7004 1711 150 UNI2-AS - Orange Espagne SA, ES 39891 4907 302 76 ALJAWWALSTC-AS - Saudi Telecom Company JS 9009 4173 378 2556 M247 - M247 Europe SRL, RO 20940 3802 3388 101 AKAMAI-ASN1 - Akamai International B.V., 212238 3508 252 2648 CDNEXT - Datacamp Limited, GB 12389 3161 2332 871 ROSTELECOM-AS - PJSC Rostelecom, RU 29355 2545 151 24 KCELL-AS - Kcell JSC, KZ 34984 2485 367 588 TELLCOM-AS - Superonline Iletisim Hizmetl 44559 1944 122 909 ITHOSTLINE - IT HOSTLINE LTD, CY 8452 1716 1852 17 TE-AS - IDDQD-AS, EG 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 12968 3289 616 AS8151 - UNINET, MX 10620 3444 451 1107 AS10620 - Telmex Colombia S.A., CO 13999 2279 499 331 AS13999 - Mega Cable, S.A. de C.V., MX 11830 1885 369 65 AS11830 - Instituto Costarricense de Elec 11664 1498 277 34 AS11664 - Techtel LMDS Comunicaciones Int 28573 1375 2429 271 AS28573 - Claro NXT Telecomunicacoes Ltda 3816 1342 768 213 AS3816 - COLOMBIA TELECOMUNICACIONES S.A. 6147 1210 371 21 AS6147 - INTEGRATEL PERU S.A.A., PE 22884 1097 70 386 AS22884 - TOTAL PLAY TELECOMUNICACIONES, 26615 1052 2384 95 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 1986 585 33 Vodafone Data - Vodafone Data, EG 36992 1928 1543 333 ETISALAT MISR - ETISALAT MISR, EG 36903 1350 587 104 Office National des Postes et Telecommuni 24863 1320 389 16 Link Egypt (Link.NET) - Link Egypt (Link. 36935 1277 524 47 Vodafone Data - Vodafone Data, EG 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 617 55 201 Africa on Cloud - Africa on Cloud, ZA 15399 570 58 64 Wananchi Group (Kenya) Limited - Wananchi 36914 546 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 15711 41558 5640 AMAZON-02 - Amazon.com, Inc., US 9808 14200 8919 100 CHINAMOBILE-CN - China Mobile Communicati 8151 12968 3289 616 AS8151 - UNINET, MX 12479 7004 1711 150 UNI2-AS - Orange Espagne SA, ES 7545 5837 818 450 TPG-INTERNET-AP - TPG Telecom Limited, AU 4538 5070 4192 74 ERX-CERNET-BKB - China Education and Rese 9498 5061 558 341 BBIL-AP - BHARTI Airtel Ltd., IN 39891 4907 302 76 ALJAWWALSTC-AS - Saudi Telecom Company JS 22773 4810 3182 373 ASN-CXA-ALL-CCI-22773-RDC - Cox Communica 18403 4651 347 24 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 14200 14100 CHINAMOBILE-CN - China Mobile Communications Gr 8151 12968 12352 AS8151 - UNINET, MX 12479 7004 6854 UNI2-AS - Orange Espagne SA, ES 7545 5837 5387 TPG-INTERNET-AP - TPG Telecom Limited, AU 4538 5070 4996 ERX-CERNET-BKB - China Education and Research N 39891 4907 4831 ALJAWWALSTC-AS - Saudi Telecom Company JSC, SA 9498 5061 4720 BBIL-AP - BHARTI Airtel Ltd., IN 18403 4651 4627 FPT-VN - FPT Telecom Company, VN 22773 4810 4437 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 4026 4002 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 394928 UNALLOCATED 8.2.70.0/24 3356 LEVEL3 - Level 3 Parent 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 174 COGENT-174 - Cogent Com 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.133.212.0/24 Origin: 18604 UNASSIGNED 23.133.212.0/24 Transit: 394625 WHITELABELIT - WhiteLabel IT Solutions C 23.137.48.0/24 Origin: 16904 ARVIG-16904 - Arvig Enterprises Inc., US 23.137.48.0/24 Transit: 3257 GTT-BACKBONE - GTT Communications Inc., 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:586 /14:1183 /15:2125 /16:13729 /17:8378 /18:13357 /19:25730 /20:46921 /21:54011 /22:113897 /23:110485 /24:675869 /25:698 /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 7156 12968 AS8151 - UNINET, MX 12479 5931 7004 UNI2-AS - Orange Espagne SA, ES 39891 3656 4907 ALJAWWALSTC-AS - Saudi Telecom Company JSC, SA 11492 3512 4617 CABLEONE - CABLE ONE, INC., US 6327 3510 3731 SHAW - Shaw Communications, CA 22773 3056 4810 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc., US 16509 2994 15711 AMAZON-02 - Amazon.com, Inc., US 7155 2946 3992 VIASAT-SP-BACKBONE - ViaSat,Inc., US 10620 2248 3444 AS10620 - Telmex Colombia S.A., CO 30036 2210 2556 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:2677 2:2855 3:1020 4:5 5:5282 6:207 7:6 8:1391 9:96 11:172 12:1103 13:825 14:2787 15:486 16:264 17:454 18:944 20:602 21:4 22:188 23:8580 24:2790 25:2 27:2806 28:6 29:19 31:3834 32:37 34:94 35:293 36:4894 37:4466 38:10306 39:1383 40:432 41:4620 42:2254 43:3343 44:477 45:20076 46:5002 47:460 48:168 49:2269 50:2018 51:838 52:1371 54:307 55:1184 56:11 57:331 58:2498 59:1421 60:1239 61:3218 62:3176 63:1749 64:6556 65:2148 66:6236 67:3334 68:1286 69:4047 70:1055 71:606 72:3265 74:3082 75:1600 76:593 77:2924 78:2117 79:1846 80:2389 81:2288 82:4310 83:1495 84:2167 85:3919 86:1114 87:2909 88:1329 89:4821 90:770 91:8518 92:2751 93:3045 94:4484 95:4732 96:1448 97:307 98:936 99:970 100:73 101:1349 102:4736 103:32434 104:5664 105:835 106:918 107:2979 108:1380 109:3929 110:2285 111:4269 112:3149 113:1932 114:2530 115:2243 116:2102 117:3686 118:3016 119:2106 120:2829 121:1720 122:3053 123:2241 124:1734 125:3030 126:157 128:1573 129:979 130:1726 131:2523 132:901 133:493 134:1788 135:647 136:1559 137:1456 138:3412 139:1811 140:1977 141:1820 142:2611 143:2192 144:1869 145:670 146:2196 147:2333 148:2822 149:3614 150:1412 151:3020 152:2452 153:1955 154:9961 155:2384 156:4660 157:2451 158:1631 159:2911 160:4003 161:2070 162:4215 163:2683 164:2386 165:2784 166:1193 167:2383 168:4242 169:908 170:5653 171:1129 172:4921 173:3484 174:890 175:1401 176:4041 177:5261 178:4564 179:2505 180:3291 181:4671 182:4060 183:2864 184:2053 185:21958 186:6554 187:5592 188:4769 189:4674 190:9981 191:1790 192:11831 193:9640 194:7972 195:5932 196:3445 197:3203 198:6364 199:6114 200:8464 201:6719 202:10758 203:10520 204:4756 205:3782 206:4449 207:4105 208:4337 209:5492 210:4905 211:2802 212:5232 213:4133 214:1021 215:47 216:7306 217:3740 218:1947 219:583 220:2267 221:1394 222:1122 223:3589 End of report From salvadorb en gmail.com Sat Aug 8 15:46:50 2026 From: salvadorb en gmail.com (Salvador Bertenbreiter) Date: Sat, 8 Aug 2026 13:46:50 -0500 Subject: [lacnog] RTBH y RPKI Message-ID: Hola a todos, Una consulta para quienes usan RTBH junto con RPKI. ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo tiene un ROA con maxLength /24 o /48? Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence porque también haría válidos otros more-specifics. La otra sería mantener el ROA como está y anunciar igual el host route para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente hacen alguna excepción para rutas marcadas como blackhole, o las descartan antes por RPKI? Crear un ROA específico en el momento tampoco parece muy práctico por los tiempos de propagación. ¿Cómo lo están manejando ustedes en producción? Saludos, Salvador ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From tomas.lynch en gmail.com Sun Aug 9 22:59:42 2026 From: tomas.lynch en gmail.com (Tomas Lynch) Date: Sun, 9 Aug 2026 21:59:42 -0400 Subject: [lacnog] RTBH y RPKI In-Reply-To: References: Message-ID: Salvador, Level3 (AS3356) nos exige que las ROAs tengan longitud /32 para IPv4 y /128 para IPv6 para el manejo de RTBH. Para los prefijos IPv4 no tuve problemas ni en ARIN, ni RIPE, ni APNIC; todavía no tenemos asignaciones en LACNIC ni AFRINIC. Con IPv6 si tuvimos temas con APNIC ya que los ROAs al mismo tiempo creaban entradas en el IRR de APNIC, te imaginaras que eso no escala para un /32 de IPv6. No descarto que mi ignorancia haya sido el problema con APNIC. Con otros proveedores no tengo la exigencia de Level3 y simplemente confían en los IRRs de los RIRs y RADb. Es decir, que si enviamos un /32 o /64 con la comunidad de RTBH, los proveedores no verifican la ROA y aceptan el prefijo. Nosotros con los clientes hacemos lo mismo. Por un lado la firma de ROAs hasta /32 o /128 es una buena idea, ya que como dices los prefijos serían válidos. Por otro es horrible ya que cualquiera con un FRR se pone a propagar tus /32s o /64s a un RTBH. Aquí vendría el ASPA a ayudar un poco pero ya nos pasó que alguien contrató a un proveedor mundialmente reconocido, hizo peering con nuestro ASN y empezó a propagar nuestras rutas, y ese es otro tema a discutir Saludos, Tomás Lynch On Sat, Aug 8, 2026 at 2:47?PM Salvador Bertenbreiter wrote: > Hola a todos, > > Una consulta para quienes usan RTBH junto con RPKI. > > ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo > tiene un ROA con maxLength /24 o /48? > > Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence > porque también haría válidos otros more-specifics. > > La otra sería mantener el ROA como está y anunciar igual el host route > para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente > hacen alguna excepción para rutas marcadas como blackhole, o las descartan > antes por RPKI? > > Crear un ROA específico en el momento tampoco parece muy práctico por los > tiempos de propagación. > > ¿Cómo lo están manejando ustedes en producción? > > Saludos, > > Salvador > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From salvadorb en gmail.com Mon Aug 10 00:59:37 2026 From: salvadorb en gmail.com (Salvador Bertenbreiter) Date: Sun, 9 Aug 2026 22:59:37 -0500 Subject: [lacnog] RTBH y RPKI In-Reply-To: References: Message-ID: Hola Tomás, Interesante conocer tu experiencia y cómo lo manejan otros Carriers. Ese es el tema dejar abiertos los RoAs hasta /32 en IPv4 y /128 en IPv6 me parece un riesgo muy grande, pero al mismo tiempo si no lo haces el RTBH con AS3356 no funciona. Estaba pensando en dejar los RoAs solo hasta /24 y /48 (o lo que corresponda según el caso) y crear un segundo ser de RoAs específicos para los /32 y /128 solo en el momento que sea necesario el RTBH, el problema es que el tiempo que demoran los validadores RPKI de los upstreams para sincronizarse. Saludos Salvador El El dom, 9 ago. 2026 a la(s) 21:00, Tomas Lynch escribió: > Salvador, > > Level3 (AS3356) nos exige que las ROAs tengan longitud /32 para IPv4 y > /128 para IPv6 para el manejo de RTBH. Para los prefijos IPv4 no tuve > problemas ni en ARIN, ni RIPE, ni APNIC; todavía no tenemos asignaciones en > LACNIC ni AFRINIC. Con IPv6 si tuvimos temas con APNIC ya que los ROAs al > mismo tiempo creaban entradas en el IRR de APNIC, te imaginaras que eso no > escala para un /32 de IPv6. No descarto que mi ignorancia haya sido el > problema con APNIC. > > Con otros proveedores no tengo la exigencia de Level3 y simplemente > confían en los IRRs de los RIRs y RADb. Es decir, que si enviamos un /32 o > /64 con la comunidad de RTBH, los proveedores no verifican la ROA y aceptan > el prefijo. Nosotros con los clientes hacemos lo mismo. > > Por un lado la firma de ROAs hasta /32 o /128 es una buena idea, ya que > como dices los prefijos serían válidos. Por otro es horrible ya que > cualquiera con un FRR se pone a propagar tus /32s o /64s a un RTBH. Aquí > vendría el ASPA a ayudar un poco pero ya nos pasó que alguien contrató a un > proveedor mundialmente reconocido, hizo peering con nuestro ASN y empezó a > propagar nuestras rutas, y ese es otro tema a discutir > > Saludos, > > Tomás Lynch > > On Sat, Aug 8, 2026 at 2:47?PM Salvador Bertenbreiter > wrote: > >> Hola a todos, >> >> Una consulta para quienes usan RTBH junto con RPKI. >> >> ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo >> tiene un ROA con maxLength /24 o /48? >> >> Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence >> porque también haría válidos otros more-specifics. >> >> La otra sería mantener el ROA como está y anunciar igual el host route >> para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente >> hacen alguna excepción para rutas marcadas como blackhole, o las descartan >> antes por RPKI? >> >> Crear un ROA específico en el momento tampoco parece muy práctico por los >> tiempos de propagación. >> >> ¿Cómo lo están manejando ustedes en producción? >> >> Saludos, >> >> Salvador >> > _______________________________________________ >> LACNOG mailing list >> LACNOG en lacnic.net >> https://mail.lacnic.net/mailman/listinfo/lacnog >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >> > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From fischerdouglas en gmail.com Mon Aug 10 08:44:13 2026 From: fischerdouglas en gmail.com (Douglas Fischer) Date: Mon, 10 Aug 2026 08:44:13 -0300 Subject: [lacnog] RTBH y RPKI In-Reply-To: References: Message-ID: Lo cierto es que el ROA de RPKI estaba mal diseñado desde su creación. P.S.: Ahora, algunos que no me conocen me tacharán de negacionista de RPKI. Yo... Que creo que participé directamente en la implementación de RPKI (ROA y filtrado) de más de 400 ASNs. Los ROA de RPKI ya cuentan con LE (Less Equal). Lo que realmente le falta a RPKI es GE (Greater Equal). Creo que es importante que quien hable de esto sepa que fue uno de los temas más candentes en los intercambios de correo electrónico durante las discusiones del Draft de RPKI. Y que, prácticamente de forma arbitraria, se dejó de lado la idea de lo GE. Mucho con el argumento de "economía de recursos computacionales". Si se hubiera incluido GE, como se discutió durante el período de Draft de la RFC... Solo se necesitaría algo como: - ROA 198.18.80.0/22 LE 24 - ROA 198.18.80.0/22 GE 32 LE 32 Y eso habría resuelto el problema de RTBH y algunos otros. Em sáb., 8 de ago. de 2026 às 15:47, Salvador Bertenbreiter < salvadorb en gmail.com> escreveu: > Hola a todos, > > Una consulta para quienes usan RTBH junto con RPKI. > > ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo > tiene un ROA con maxLength /24 o /48? > > Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence > porque también haría válidos otros more-specifics. > > La otra sería mantener el ROA como está y anunciar igual el host route > para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente > hacen alguna excepción para rutas marcadas como blackhole, o las descartan > antes por RPKI? > > Crear un ROA específico en el momento tampoco parece muy práctico por los > tiempos de propagación. > > ¿Cómo lo están manejando ustedes en producción? > > Saludos, > > Salvador > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > -- Douglas Fernando Fischer Engº de Controle e Automação ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From fischerdouglas en gmail.com Mon Aug 10 08:47:53 2026 From: fischerdouglas en gmail.com (Douglas Fischer) Date: Mon, 10 Aug 2026 08:47:53 -0300 Subject: [lacnog] RTBH y RPKI In-Reply-To: References: Message-ID: La forma más efectiva que encontré para solucionar esto es ir más allá del protocolo RTR. No podrás evitarlo con equipos que operen estrictamente dentro de las definiciones de RFC. P.S.: Por lo tanto, recomiendo otra sesión BGP, con un servidor de rutas, en eBGP MultiHop, dedicada a RTBH (y quizás flowspec). Necesitarás una Engine BGP BGP software-based para gestionar las rutas y un deamon de validación RPKI para gestionar las ROA y no solo las VRP. Y con esta información, en los casos en que el prefijo sea inválido, tendrás que investigar por qué se clasificó como inválido. Ejemplos: - Si el prefijo es inválido porque las fechas del certificado han expirado o la ROA ha sido revocada... Entonces no hay nada que puedas hacer. - Lo mismo se aplica si el ASN de la ruta IPv4 /32 no contiene el ASN que coincide con el ROA que cubre esa /32. Pero si el motivo de la clasificación como inválida es únicamente la longitud de la máscara... Si existe un VRP que cubre la ruta IPv4 /32 menos específica, coincide con el ASN y cumple con las especificaciones del certificado... Entonces, dentro de la interpretación individual del RFC RPKI. Dentro de las definiciones de autonomía de un ASN, se puede optar por aceptar rutas /32 (IPv4) que tengan un blackhole BGP de comunidad válido dentro de su ASN y que se clasifiquen como inválidas en RPKI solo debido a la longitud del prefijo, siendo válidas para todos los demás aspectos. Em seg., 10 de ago. de 2026 às 08:44, Douglas Fischer < fischerdouglas en gmail.com> escreveu: > Lo cierto es que el ROA de RPKI estaba mal diseñado desde su creación. > > P.S.: Ahora, algunos que no me conocen me tacharán de negacionista de RPKI. > Yo... Que creo que participé directamente en la implementación de RPKI > (ROA y filtrado) de más de 400 ASNs. > > Los ROA de RPKI ya cuentan con LE (Less Equal). > Lo que realmente le falta a RPKI es GE (Greater Equal). > > Creo que es importante que quien hable de esto sepa que fue uno de los > temas más candentes en los intercambios de correo electrónico durante las > discusiones del Draft de RPKI. Y que, prácticamente de forma arbitraria, se > dejó de lado la idea de lo GE. Mucho con el argumento de "economía de > recursos computacionales". > > Si se hubiera incluido GE, como se discutió durante el período de Draft de > la RFC... Solo se necesitaría algo como: > - ROA 198.18.80.0/22 LE 24 > - ROA 198.18.80.0/22 GE 32 LE 32 > Y eso habría resuelto el problema de RTBH y algunos otros. > > > > Em sáb., 8 de ago. de 2026 às 15:47, Salvador Bertenbreiter < > salvadorb en gmail.com> escreveu: > >> Hola a todos, >> >> Una consulta para quienes usan RTBH junto con RPKI. >> >> ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo >> tiene un ROA con maxLength /24 o /48? >> >> Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence >> porque también haría válidos otros more-specifics. >> >> La otra sería mantener el ROA como está y anunciar igual el host route >> para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente >> hacen alguna excepción para rutas marcadas como blackhole, o las descartan >> antes por RPKI? >> >> Crear un ROA específico en el momento tampoco parece muy práctico por los >> tiempos de propagación. >> >> ¿Cómo lo están manejando ustedes en producción? >> >> Saludos, >> >> Salvador >> _______________________________________________ >> LACNOG mailing list >> LACNOG en lacnic.net >> https://mail.lacnic.net/mailman/listinfo/lacnog >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >> > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From carlos en cagnazzo.uy Mon Aug 10 09:13:05 2026 From: carlos en cagnazzo.uy (Carlos Martinez) Date: Mon, 10 Aug 2026 09:13:05 -0300 Subject: [lacnog] RTBH y RPKI In-Reply-To: References: Message-ID: <87d4bddb-1a58-4be9-a4c6-ee39e5c56f7a@Canary> No seria un buen caso de uso de SLURM este ? -- Sent from Canary (https://canarymail.io) > On Monday, Aug 10, 2026 at 8:47 AM, Douglas Fischer wrote: > La forma más efectiva que encontré para solucionar esto es ir más allá del protocolo RTR. > No podrás evitarlo con equipos que operen estrictamente dentro de las definiciones de RFC. > > P.S.: Por lo tanto, recomiendo otra sesión BGP, con un servidor de rutas, en eBGP MultiHop, dedicada a RTBH (y quizás flowspec). > > Necesitarás una Engine BGP BGP software-based para gestionar las rutas y un deamon de validación RPKI para gestionar las ROA y no solo las VRP. > Y con esta información, en los casos en que el prefijo sea inválido, tendrás que investigar por qué se clasificó como inválido. > > Ejemplos: > - Si el prefijo es inválido porque las fechas del certificado han expirado o la ROA ha sido revocada... Entonces no hay nada que puedas hacer. > - Lo mismo se aplica si el ASN de la ruta IPv4 /32 no contiene el ASN que coincide con el ROA que cubre esa /32. > > Pero si el motivo de la clasificación como inválida es únicamente la longitud de la máscara... Si existe un VRP que cubre la ruta IPv4 /32 menos específica, coincide con el ASN y cumple con las especificaciones del certificado... > > Entonces, dentro de la interpretación individual del RFC RPKI. > Dentro de las definiciones de autonomía de un ASN, se puede optar por aceptar rutas /32 (IPv4) que tengan un blackhole BGP de comunidad válido dentro de su ASN y que se clasifiquen como inválidas en RPKI solo debido a la longitud del prefijo, siendo válidas para todos los demás aspectos. > > Em seg., 10 de ago. de 2026 às 08:44, Douglas Fischer escreveu: > > Lo cierto es que el ROA de RPKI estaba mal diseñado desde su creación. > > > > P.S.: Ahora, algunos que no me conocen me tacharán de negacionista de RPKI. > > Yo... Que creo que participé directamente en la implementación de RPKI (ROA y filtrado) de más de 400 ASNs. > > > > Los ROA de RPKI ya cuentan con LE (Less Equal). > > Lo que realmente le falta a RPKI es GE (Greater Equal). > > > > Creo que es importante que quien hable de esto sepa que fue uno de los temas más candentes en los intercambios de correo electrónico durante las discusiones del Draft de RPKI. Y que, prácticamente de forma arbitraria, se dejó de lado la idea de lo GE. Mucho con el argumento de "economía de recursos computacionales". > > > > Si se hubiera incluido GE, como se discutió durante el período de Draft de la RFC... Solo se necesitaría algo como: > > - ROA 198.18.80.0/22 (http://198.18.80.0/22) LE 24 > > - ROA 198.18.80.0/22 (http://198.18.80.0/22) GE 32 LE 32 > > Y eso habría resuelto el problema de RTBH y algunos otros. > > > > > > > > Em sáb., 8 de ago. de 2026 às 15:47, Salvador Bertenbreiter escreveu: > > > Hola a todos, > > > > > > Una consulta para quienes usan RTBH junto con RPKI. > > > > > > ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo tiene un ROA con maxLength /24 o /48? > > > > > > Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence porque también haría válidos otros more-specifics. > > > > > > La otra sería mantener el ROA como está y anunciar igual el host route para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente hacen alguna excepción para rutas marcadas como blackhole, o las descartan antes por RPKI? > > > > > > Crear un ROA específico en el momento tampoco parece muy práctico por los tiempos de propagación. > > > > > > ¿Cómo lo están manejando ustedes en producción? > > > > > > Saludos, > > > > > > Salvador _______________________________________________ > > > LACNOG mailing list > > > LACNOG en lacnic.net (mailto:LACNOG en lacnic.net) > > > https://mail.lacnic.net/mailman/listinfo/lacnog > > > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > > > > > > -- > > Douglas Fernando Fischer > > Engº de Controle e Automação > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: ------------ próxima parte ------------ Se ha borrado un mensaje adjunto que no está en formato texto plano... Nombre : signature.asc Tipo : application/pgp-signature Tamaño : 917 bytes Descripción: no disponible Url : From fischerdouglas en gmail.com Mon Aug 10 09:33:24 2026 From: fischerdouglas en gmail.com (Douglas Fischer) Date: Mon, 10 Aug 2026 09:33:24 -0300 Subject: [lacnog] RTBH y RPKI In-Reply-To: <87d4bddb-1a58-4be9-a4c6-ee39e5c56f7a@Canary> References: <87d4bddb-1a58-4be9-a4c6-ee39e5c56f7a@Canary> Message-ID: Seria! Seria lindo! Pero, apesar de ser de 2018 la https://www.rfc-editor.org/rfc/rfc8416.txt ... Em 2022 quando yo estaba procurando una solucion para esto, nadie existia como código listo. Entonces fue a BIRD. Aprovechando que Bird aun no tenía RTR. Em seg., 10 de ago. de 2026 às 09:13, Carlos Martinez escreveu: > No seria un buen caso de uso de SLURM este ? > > -- > Sent from Canary > > On Monday, Aug 10, 2026 at 8:47 AM, Douglas Fischer < > fischerdouglas en gmail.com> wrote: > La forma más efectiva que encontré para solucionar esto es ir más allá del > protocolo RTR. > No podrás evitarlo con equipos que operen estrictamente dentro de las > definiciones de RFC. > > P.S.: Por lo tanto, recomiendo otra sesión BGP, con un servidor de rutas, > en eBGP MultiHop, dedicada a RTBH (y quizás flowspec). > > Necesitarás una Engine BGP BGP software-based para gestionar las rutas y > un deamon de validación RPKI para gestionar las ROA y no solo las VRP. > Y con esta información, en los casos en que el prefijo sea inválido, > tendrás que investigar por qué se clasificó como inválido. > > Ejemplos: > - Si el prefijo es inválido porque las fechas del certificado han expirado > o la ROA ha sido revocada... Entonces no hay nada que puedas hacer. > - Lo mismo se aplica si el ASN de la ruta IPv4 /32 no contiene el ASN que > coincide con el ROA que cubre esa /32. > > Pero si el motivo de la clasificación como inválida es únicamente la > longitud de la máscara... Si existe un VRP que cubre la ruta IPv4 /32 menos > específica, coincide con el ASN y cumple con las especificaciones del > certificado... > > Entonces, dentro de la interpretación individual del RFC RPKI. > Dentro de las definiciones de autonomía de un ASN, se puede optar por > aceptar rutas /32 (IPv4) que tengan un blackhole BGP de comunidad válido > dentro de su ASN y que se clasifiquen como inválidas en RPKI solo debido a > la longitud del prefijo, siendo válidas para todos los demás aspectos. > > Em seg., 10 de ago. de 2026 às 08:44, Douglas Fischer < > fischerdouglas en gmail.com> escreveu: > >> Lo cierto es que el ROA de RPKI estaba mal diseñado desde su creación. >> >> P.S.: Ahora, algunos que no me conocen me tacharán de negacionista de >> RPKI. >> Yo... Que creo que participé directamente en la implementación de RPKI >> (ROA y filtrado) de más de 400 ASNs. >> >> Los ROA de RPKI ya cuentan con LE (Less Equal). >> Lo que realmente le falta a RPKI es GE (Greater Equal). >> >> Creo que es importante que quien hable de esto sepa que fue uno de los >> temas más candentes en los intercambios de correo electrónico durante las >> discusiones del Draft de RPKI. Y que, prácticamente de forma arbitraria, se >> dejó de lado la idea de lo GE. Mucho con el argumento de "economía de >> recursos computacionales". >> >> Si se hubiera incluido GE, como se discutió durante el período de Draft >> de la RFC... Solo se necesitaría algo como: >> - ROA 198.18.80.0/22 LE 24 >> - ROA 198.18.80.0/22 GE 32 LE 32 >> Y eso habría resuelto el problema de RTBH y algunos otros. >> >> >> >> Em sáb., 8 de ago. de 2026 às 15:47, Salvador Bertenbreiter < >> salvadorb en gmail.com> escreveu: >> >>> Hola a todos, >>> >>> Una consulta para quienes usan RTBH junto con RPKI. >>> >>> ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo >>> tiene un ROA con maxLength /24 o /48? >>> >>> Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence >>> porque también haría válidos otros more-specifics. >>> >>> La otra sería mantener el ROA como está y anunciar igual el host route >>> para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente >>> hacen alguna excepción para rutas marcadas como blackhole, o las descartan >>> antes por RPKI? >>> >>> Crear un ROA específico en el momento tampoco parece muy práctico por >>> los tiempos de propagación. >>> >>> ¿Cómo lo están manejando ustedes en producción? >>> >>> Saludos, >>> >>> Salvador >>> _______________________________________________ >>> LACNOG mailing list >>> LACNOG en lacnic.net >>> https://mail.lacnic.net/mailman/listinfo/lacnog >>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >>> >> >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > -- Douglas Fernando Fischer Engº de Controle e Automação ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From carlos en cagnazzo.uy Mon Aug 10 09:37:55 2026 From: carlos en cagnazzo.uy (Carlos Martinez) Date: Mon, 10 Aug 2026 09:37:55 -0300 Subject: [lacnog] RTBH y RPKI In-Reply-To: References: <87d4bddb-1a58-4be9-a4c6-ee39e5c56f7a@Canary> Message-ID: Entiendo, mas ahora? lo seria? -- Sent from Canary (https://canarymail.io) > On Monday, Aug 10, 2026 at 9:33 AM, Douglas Fischer wrote: > Seria! Seria lindo! > Pero, apesar de ser de 2018 la https://www.rfc-editor.org/rfc/rfc8416.txt ... > Em 2022 quando yo estaba procurando una solucion para esto, nadie existia como código listo. > > Entonces fue a BIRD. > Aprovechando que Bird aun no tenía RTR. > > > Em seg., 10 de ago. de 2026 às 09:13, Carlos Martinez escreveu: > > No seria un buen caso de uso de SLURM este ? > > > > -- > > Sent from Canary (https://canarymail.io) > > > > > On Monday, Aug 10, 2026 at 8:47 AM, Douglas Fischer wrote: > > > La forma más efectiva que encontré para solucionar esto es ir más allá del protocolo RTR. > > > No podrás evitarlo con equipos que operen estrictamente dentro de las definiciones de RFC. > > > > > > P.S.: Por lo tanto, recomiendo otra sesión BGP, con un servidor de rutas, en eBGP MultiHop, dedicada a RTBH (y quizás flowspec). > > > > > > Necesitarás una Engine BGP BGP software-based para gestionar las rutas y un deamon de validación RPKI para gestionar las ROA y no solo las VRP. > > > Y con esta información, en los casos en que el prefijo sea inválido, tendrás que investigar por qué se clasificó como inválido. > > > > > > Ejemplos: > > > - Si el prefijo es inválido porque las fechas del certificado han expirado o la ROA ha sido revocada... Entonces no hay nada que puedas hacer. > > > - Lo mismo se aplica si el ASN de la ruta IPv4 /32 no contiene el ASN que coincide con el ROA que cubre esa /32. > > > > > > Pero si el motivo de la clasificación como inválida es únicamente la longitud de la máscara... Si existe un VRP que cubre la ruta IPv4 /32 menos específica, coincide con el ASN y cumple con las especificaciones del certificado... > > > > > > Entonces, dentro de la interpretación individual del RFC RPKI. > > > Dentro de las definiciones de autonomía de un ASN, se puede optar por aceptar rutas /32 (IPv4) que tengan un blackhole BGP de comunidad válido dentro de su ASN y que se clasifiquen como inválidas en RPKI solo debido a la longitud del prefijo, siendo válidas para todos los demás aspectos. > > > > > > Em seg., 10 de ago. de 2026 às 08:44, Douglas Fischer escreveu: > > > > Lo cierto es que el ROA de RPKI estaba mal diseñado desde su creación. > > > > > > > > P.S.: Ahora, algunos que no me conocen me tacharán de negacionista de RPKI. > > > > Yo... Que creo que participé directamente en la implementación de RPKI (ROA y filtrado) de más de 400 ASNs. > > > > > > > > Los ROA de RPKI ya cuentan con LE (Less Equal). > > > > Lo que realmente le falta a RPKI es GE (Greater Equal). > > > > > > > > Creo que es importante que quien hable de esto sepa que fue uno de los temas más candentes en los intercambios de correo electrónico durante las discusiones del Draft de RPKI. Y que, prácticamente de forma arbitraria, se dejó de lado la idea de lo GE. Mucho con el argumento de "economía de recursos computacionales". > > > > > > > > Si se hubiera incluido GE, como se discutió durante el período de Draft de la RFC... Solo se necesitaría algo como: > > > > - ROA 198.18.80.0/22 (http://198.18.80.0/22) LE 24 > > > > - ROA 198.18.80.0/22 (http://198.18.80.0/22) GE 32 LE 32 > > > > Y eso habría resuelto el problema de RTBH y algunos otros. > > > > > > > > > > > > > > > > Em sáb., 8 de ago. de 2026 às 15:47, Salvador Bertenbreiter escreveu: > > > > > Hola a todos, > > > > > > > > > > Una consulta para quienes usan RTBH junto con RPKI. > > > > > > > > > > ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo tiene un ROA con maxLength /24 o /48? > > > > > > > > > > Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence porque también haría válidos otros more-specifics. > > > > > > > > > > La otra sería mantener el ROA como está y anunciar igual el host route para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente hacen alguna excepción para rutas marcadas como blackhole, o las descartan antes por RPKI? > > > > > > > > > > Crear un ROA específico en el momento tampoco parece muy práctico por los tiempos de propagación. > > > > > > > > > > ¿Cómo lo están manejando ustedes en producción? > > > > > > > > > > Saludos, > > > > > > > > > > Salvador _______________________________________________ > > > > > LACNOG mailing list > > > > > LACNOG en lacnic.net (mailto:LACNOG en lacnic.net) > > > > > https://mail.lacnic.net/mailman/listinfo/lacnog > > > > > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > > > > > > > > > > > > -- > > > > Douglas Fernando Fischer > > > > Engº de Controle e Automação > > > > > > > > > -- > > > Douglas Fernando Fischer > > > Engº de Controle e Automação > > > _______________________________________________ > > > LACNOG mailing list > > > LACNOG en lacnic.net (mailto:LACNOG en lacnic.net) > > > https://mail.lacnic.net/mailman/listinfo/lacnog > > > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > > _______________________________________________ > > LACNOG mailing list > > LACNOG en lacnic.net (mailto:LACNOG en lacnic.net) > > https://mail.lacnic.net/mailman/listinfo/lacnog > > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: ------------ próxima parte ------------ Se ha borrado un mensaje adjunto que no está en formato texto plano... Nombre : signature.asc Tipo : application/pgp-signature Tamaño : 917 bytes Descripción: no disponible Url : From fischerdouglas en gmail.com Mon Aug 10 10:13:23 2026 From: fischerdouglas en gmail.com (Douglas Fischer) Date: Mon, 10 Aug 2026 10:13:23 -0300 Subject: [lacnog] RTBH y RPKI In-Reply-To: References: <87d4bddb-1a58-4be9-a4c6-ee39e5c56f7a@Canary> Message-ID: Sería un excelente proyecto para dedicar varias horas. Un proyecto que creo que podría incluso tener un resultado mucho-mucho elegante. Si yo tuviese un proyecto con la meta de resolver esto, ahora? ¡Ciertamente iría con esto! Seguiría con la idea de sesión BGP MP-BGP en un Route-Server dedicada para recibir RTBH y Flowspec. Esto tras mucha flexibilidad a la solución. Y principalmente trás un alcance mucho más robusto de validación de los prefixos frente a múltiples demandas como: - Comparar RTBH con ruta recibidas de Downstream y validar si las rutas efectivas cubren la RTBH. - Dejar RTBH como RTBH mismo y aplicar en su propia FIB? - Crear un IP de Blackhole Blackhole dedicado a cada Cliente, de manera generar información al cliente de cuanto fuera a blackhole. - Exportar RTBH para los Upstreams que aceptan? - Convertir RTBH en FlowSpec simple-drop y aplicar solo en los puertos de salida a lo downstream? Y también conceptos similares aplicados a FlowSpec. Em seg., 10 de ago. de 2026 às 09:38, Carlos Martinez escreveu: > Entiendo, mas ahora? lo seria? > > -- > Sent from Canary > > On Monday, Aug 10, 2026 at 9:33 AM, Douglas Fischer < > fischerdouglas en gmail.com> wrote: > Seria! Seria lindo! > Pero, apesar de ser de 2018 la https://www.rfc-editor.org/rfc/rfc8416.txt > ... > Em 2022 quando yo estaba procurando una solucion para esto, nadie existia > como código listo. > > Entonces fue a BIRD. > Aprovechando que Bird aun no tenía RTR. > > > Em seg., 10 de ago. de 2026 às 09:13, Carlos Martinez > escreveu: > >> No seria un buen caso de uso de SLURM este ? >> >> -- >> Sent from Canary >> >> On Monday, Aug 10, 2026 at 8:47 AM, Douglas Fischer < >> fischerdouglas en gmail.com> wrote: >> La forma más efectiva que encontré para solucionar esto es ir más allá >> del protocolo RTR. >> No podrás evitarlo con equipos que operen estrictamente dentro de las >> definiciones de RFC. >> >> P.S.: Por lo tanto, recomiendo otra sesión BGP, con un servidor de rutas, >> en eBGP MultiHop, dedicada a RTBH (y quizás flowspec). >> >> Necesitarás una Engine BGP BGP software-based para gestionar las rutas y >> un deamon de validación RPKI para gestionar las ROA y no solo las VRP. >> Y con esta información, en los casos en que el prefijo sea inválido, >> tendrás que investigar por qué se clasificó como inválido. >> >> Ejemplos: >> - Si el prefijo es inválido porque las fechas del certificado han >> expirado o la ROA ha sido revocada... Entonces no hay nada que puedas hacer. >> - Lo mismo se aplica si el ASN de la ruta IPv4 /32 no contiene el ASN que >> coincide con el ROA que cubre esa /32. >> >> Pero si el motivo de la clasificación como inválida es únicamente la >> longitud de la máscara... Si existe un VRP que cubre la ruta IPv4 /32 menos >> específica, coincide con el ASN y cumple con las especificaciones del >> certificado... >> >> Entonces, dentro de la interpretación individual del RFC RPKI. >> Dentro de las definiciones de autonomía de un ASN, se puede optar por >> aceptar rutas /32 (IPv4) que tengan un blackhole BGP de comunidad válido >> dentro de su ASN y que se clasifiquen como inválidas en RPKI solo debido a >> la longitud del prefijo, siendo válidas para todos los demás aspectos. >> >> Em seg., 10 de ago. de 2026 às 08:44, Douglas Fischer < >> fischerdouglas en gmail.com> escreveu: >> >>> Lo cierto es que el ROA de RPKI estaba mal diseñado desde su creación. >>> >>> P.S.: Ahora, algunos que no me conocen me tacharán de negacionista de >>> RPKI. >>> Yo... Que creo que participé directamente en la implementación de RPKI >>> (ROA y filtrado) de más de 400 ASNs. >>> >>> Los ROA de RPKI ya cuentan con LE (Less Equal). >>> Lo que realmente le falta a RPKI es GE (Greater Equal). >>> >>> Creo que es importante que quien hable de esto sepa que fue uno de los >>> temas más candentes en los intercambios de correo electrónico durante las >>> discusiones del Draft de RPKI. Y que, prácticamente de forma arbitraria, se >>> dejó de lado la idea de lo GE. Mucho con el argumento de "economía de >>> recursos computacionales". >>> >>> Si se hubiera incluido GE, como se discutió durante el período de Draft >>> de la RFC... Solo se necesitaría algo como: >>> - ROA 198.18.80.0/22 LE 24 >>> - ROA 198.18.80.0/22 GE 32 LE 32 >>> Y eso habría resuelto el problema de RTBH y algunos otros. >>> >>> >>> >>> Em sáb., 8 de ago. de 2026 às 15:47, Salvador Bertenbreiter < >>> salvadorb en gmail.com> escreveu: >>> >>>> Hola a todos, >>>> >>>> Una consulta para quienes usan RTBH junto con RPKI. >>>> >>>> ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo >>>> tiene un ROA con maxLength /24 o /48? >>>> >>>> Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence >>>> porque también haría válidos otros more-specifics. >>>> >>>> La otra sería mantener el ROA como está y anunciar igual el host route >>>> para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente >>>> hacen alguna excepción para rutas marcadas como blackhole, o las descartan >>>> antes por RPKI? >>>> >>>> Crear un ROA específico en el momento tampoco parece muy práctico por >>>> los tiempos de propagación. >>>> >>>> ¿Cómo lo están manejando ustedes en producción? >>>> >>>> Saludos, >>>> >>>> Salvador >>>> _______________________________________________ >>>> LACNOG mailing list >>>> LACNOG en lacnic.net >>>> https://mail.lacnic.net/mailman/listinfo/lacnog >>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >>>> >>> >>> >>> -- >>> Douglas Fernando Fischer >>> Engº de Controle e Automação >>> >> >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> _______________________________________________ >> LACNOG mailing list >> LACNOG en lacnic.net >> https://mail.lacnic.net/mailman/listinfo/lacnog >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >> >> _______________________________________________ >> LACNOG mailing list >> LACNOG en lacnic.net >> https://mail.lacnic.net/mailman/listinfo/lacnog >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >> > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > -- Douglas Fernando Fischer Engº de Controle e Automação ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From nantoniello en gmail.com Mon Aug 10 11:28:17 2026 From: nantoniello en gmail.com (Nicolas Antoniello) Date: Mon, 10 Aug 2026 11:28:17 -0300 Subject: [lacnog] RTBH y RPKI In-Reply-To: References: <87d4bddb-1a58-4be9-a4c6-ee39e5c56f7a@Canary> Message-ID: Hola Douglas y estimados, Justamente desde hace unos días, en los tiempos que me voy haciendo, estoy probando una solución bastante parecida a eso, usando posiblemente FORT y SLURM. Vamos a ensayar algo con Carlos M. sobre esto y les contamos más cuando tengamos algo más concreto, técnicamente sólido, escalable y probado! Saludos, Nico El El lun, ago 10, 2026 a la(s) 10:13, Douglas Fischer < fischerdouglas en gmail.com> escribió: > Sería un excelente proyecto para dedicar varias horas. > Un proyecto que creo que podría incluso tener un resultado mucho-mucho > elegante. > > Si yo tuviese un proyecto con la meta de resolver esto, ahora? > ¡Ciertamente iría con esto! > > Seguiría con la idea de sesión BGP MP-BGP en un Route-Server dedicada para > recibir RTBH y Flowspec. > Esto tras mucha flexibilidad a la solución. > Y principalmente trás un alcance mucho más robusto de validación de los > prefixos frente a múltiples demandas como: > - Comparar RTBH con ruta recibidas de Downstream y validar si las rutas > efectivas cubren la RTBH. > - Dejar RTBH como RTBH mismo y aplicar en su propia FIB? > - Crear un IP de Blackhole Blackhole dedicado a cada Cliente, de manera > generar información al cliente de cuanto fuera a blackhole. > - Exportar RTBH para los Upstreams que aceptan? > - Convertir RTBH en FlowSpec simple-drop y aplicar solo en los puertos de > salida a lo downstream? > Y también conceptos similares aplicados a FlowSpec. > > > > > Em seg., 10 de ago. de 2026 às 09:38, Carlos Martinez > escreveu: > >> Entiendo, mas ahora? lo seria? >> >> -- >> Sent from Canary >> >> On Monday, Aug 10, 2026 at 9:33 AM, Douglas Fischer < >> fischerdouglas en gmail.com> wrote: >> Seria! Seria lindo! >> Pero, apesar de ser de 2018 la https://www.rfc-editor.org/rfc/rfc8416.txt >> ... >> Em 2022 quando yo estaba procurando una solucion para esto, nadie existia >> como código listo. >> >> Entonces fue a BIRD. >> Aprovechando que Bird aun no tenía RTR. >> >> >> Em seg., 10 de ago. de 2026 às 09:13, Carlos Martinez >> escreveu: >> >>> No seria un buen caso de uso de SLURM este ? >>> >>> -- >>> Sent from Canary >>> >>> On Monday, Aug 10, 2026 at 8:47 AM, Douglas Fischer < >>> fischerdouglas en gmail.com> wrote: >>> La forma más efectiva que encontré para solucionar esto es ir más allá >>> del protocolo RTR. >>> No podrás evitarlo con equipos que operen estrictamente dentro de las >>> definiciones de RFC. >>> >>> P.S.: Por lo tanto, recomiendo otra sesión BGP, con un servidor de >>> rutas, en eBGP MultiHop, dedicada a RTBH (y quizás flowspec). >>> >>> Necesitarás una Engine BGP BGP software-based para gestionar las rutas y >>> un deamon de validación RPKI para gestionar las ROA y no solo las VRP. >>> Y con esta información, en los casos en que el prefijo sea inválido, >>> tendrás que investigar por qué se clasificó como inválido. >>> >>> Ejemplos: >>> - Si el prefijo es inválido porque las fechas del certificado han >>> expirado o la ROA ha sido revocada... Entonces no hay nada que puedas hacer. >>> - Lo mismo se aplica si el ASN de la ruta IPv4 /32 no contiene el ASN >>> que coincide con el ROA que cubre esa /32. >>> >>> Pero si el motivo de la clasificación como inválida es únicamente la >>> longitud de la máscara... Si existe un VRP que cubre la ruta IPv4 /32 menos >>> específica, coincide con el ASN y cumple con las especificaciones del >>> certificado... >>> >>> Entonces, dentro de la interpretación individual del RFC RPKI. >>> Dentro de las definiciones de autonomía de un ASN, se puede optar por >>> aceptar rutas /32 (IPv4) que tengan un blackhole BGP de comunidad válido >>> dentro de su ASN y que se clasifiquen como inválidas en RPKI solo debido a >>> la longitud del prefijo, siendo válidas para todos los demás aspectos. >>> >>> Em seg., 10 de ago. de 2026 às 08:44, Douglas Fischer < >>> fischerdouglas en gmail.com> escreveu: >>> >>>> Lo cierto es que el ROA de RPKI estaba mal diseñado desde su creación. >>>> >>>> P.S.: Ahora, algunos que no me conocen me tacharán de negacionista de >>>> RPKI. >>>> Yo... Que creo que participé directamente en la implementación de RPKI >>>> (ROA y filtrado) de más de 400 ASNs. >>>> >>>> Los ROA de RPKI ya cuentan con LE (Less Equal). >>>> Lo que realmente le falta a RPKI es GE (Greater Equal). >>>> >>>> Creo que es importante que quien hable de esto sepa que fue uno de los >>>> temas más candentes en los intercambios de correo electrónico durante las >>>> discusiones del Draft de RPKI. Y que, prácticamente de forma arbitraria, se >>>> dejó de lado la idea de lo GE. Mucho con el argumento de "economía de >>>> recursos computacionales". >>>> >>>> Si se hubiera incluido GE, como se discutió durante el período de Draft >>>> de la RFC... Solo se necesitaría algo como: >>>> - ROA 198.18.80.0/22 LE 24 >>>> - ROA 198.18.80.0/22 GE 32 LE 32 >>>> Y eso habría resuelto el problema de RTBH y algunos otros. >>>> >>>> >>>> >>>> Em sáb., 8 de ago. de 2026 às 15:47, Salvador Bertenbreiter < >>>> salvadorb en gmail.com> escreveu: >>>> >>>>> Hola a todos, >>>>> >>>>> Una consulta para quienes usan RTBH junto con RPKI. >>>>> >>>>> ¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el >>>>> prefijo tiene un ROA con maxLength /24 o /48? >>>>> >>>>> Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence >>>>> porque también haría válidos otros more-specifics. >>>>> >>>>> La otra sería mantener el ROA como está y anunciar igual el host route >>>>> para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams normalmente >>>>> hacen alguna excepción para rutas marcadas como blackhole, o las descartan >>>>> antes por RPKI? >>>>> >>>>> Crear un ROA específico en el momento tampoco parece muy práctico por >>>>> los tiempos de propagación. >>>>> >>>>> ¿Cómo lo están manejando ustedes en producción? >>>>> >>>>> Saludos, >>>>> >>>>> Salvador >>>>> _______________________________________________ >>>>> LACNOG mailing list >>>>> LACNOG en lacnic.net >>>>> https://mail.lacnic.net/mailman/listinfo/lacnog >>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >>>>> >>>> >>>> >>>> -- >>>> Douglas Fernando Fischer >>>> Engº de Controle e Automação >>>> >>> >>> >>> -- >>> Douglas Fernando Fischer >>> Engº de Controle e Automação >>> _______________________________________________ >>> LACNOG mailing list >>> LACNOG en lacnic.net >>> https://mail.lacnic.net/mailman/listinfo/lacnog >>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >>> >>> _______________________________________________ >>> LACNOG mailing list >>> LACNOG en lacnic.net >>> https://mail.lacnic.net/mailman/listinfo/lacnog >>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >>> >> >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> _______________________________________________ >> LACNOG mailing list >> LACNOG en lacnic.net >> https://mail.lacnic.net/mailman/listinfo/lacnog >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >> >> _______________________________________________ >> LACNOG mailing list >> LACNOG en lacnic.net >> https://mail.lacnic.net/mailman/listinfo/lacnog >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog >> > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From sperezc en isoc.org.pa Mon Aug 10 18:45:35 2026 From: sperezc en isoc.org.pa (=?iso-8859-1?Q?Sim=F3n_P=E9rez_C=2E?=) Date: Mon, 10 Aug 2026 21:45:35 +0000 Subject: [lacnog] =?iso-8859-1?q?Webinar=3A_=22Impacto_del_Mundial_2026_e?= =?iso-8859-1?q?n_el_Tr=E1fico_de_Internet_en_IXPs=22?= Message-ID: ¿Cómo impactó el Mundial 2026 el tráfico de internet en la región? Acompáñanos a analizar los datos, picos de tráfico y aprendizajes en la red y siguientes pasos, junto a Digital Academy, PIT Chile, LACNOG e ISOC Carmen Denis Jaime Cruz [??] Miércoles 12 de Agosto de 2026 [?] 11:00 MX [????] | 13:00 CL [????] | 14:00 AR [????] [??] ¡Asegura tu lugar y regístrate ahora! Meeting Registration - Zoom [cid:6f11253e-556d-4f44-ac2c-e343c60ca2ab] ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: ------------ próxima parte ------------ Se ha borrado un mensaje adjunto que no está en formato texto plano... Nombre : Outlook-fxxftquv.png Tipo : image/png Tamaño : 2563100 bytes Descripción: Outlook-fxxftquv.png Url : From sperezc en isoc.org.pa Mon Aug 10 18:45:35 2026 From: sperezc en isoc.org.pa (=?iso-8859-1?Q?Sim=F3n_P=E9rez_C=2E?=) Date: Mon, 10 Aug 2026 21:45:35 +0000 Subject: [lacnog] =?iso-8859-1?q?Webinar=3A_=22Impacto_del_Mundial_2026_e?= =?iso-8859-1?q?n_el_Tr=E1fico_de_Internet_en_IXPs=22?= Message-ID: ¿Cómo impactó el Mundial 2026 el tráfico de internet en la región? Acompáñanos a analizar los datos, picos de tráfico y aprendizajes en la red y siguientes pasos, junto a Digital Academy, PIT Chile, LACNOG e ISOC Carmen Denis Jaime Cruz [??] Miércoles 12 de Agosto de 2026 [?] 11:00 MX [????] | 13:00 CL [????] | 14:00 AR [????] [??] ¡Asegura tu lugar y regístrate ahora! Meeting Registration - Zoom [cid:6f11253e-556d-4f44-ac2c-e343c60ca2ab] ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: ------------ próxima parte ------------ Se ha borrado un mensaje adjunto que no está en formato texto plano... Nombre : Outlook-fxxftquv.png Tipo : image/png Tamaño : 2563100 bytes Descripción: Outlook-fxxftquv.png Url :