- Test - lists.nanog.org

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

11 Mar '22

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

1 0

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

11 Mar '22

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

9 16

Asia Apac networks
by Edvinas Kairys 11 Mar '22

11 Mar '22

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

5 4

Fwd: Re: The role of Internet governance in sanctions
by surfer＠mauigateway.com 10 Mar '22

10 Mar '22

Using a few emails... - otoh, i would likely close such meager services as i provide to russian - I think it is a colossal mistake to weaponize the Internet. - Keeping the rest of the internet as functional as possible It is not "Russia" doing this. It is the Russian government doing this to the dismay of many of the Russian people. 20,000+ have already left Russia over this. If we don't keep the internet up and functional as best we can and start to block or otherwise stop/slow the flow of traffic, it is not the gov't mules that suffer, rather it is the regular, everyday Russian population that suffers. Many (most?) of the regular Russian folks want access to the global internet for info that is not gov't controlled. They can't get that with TV, radio or print media, but they can get that with the internet until the gov't blocks it. So, my 'vote' is "keep the internet up" to the best of our abilities and block/slow no one as much as possible. scott

1 0

RE: WISPA (was Making Use of 240/4 NetBlock)
by Travis Garrison 10 Mar '22

10 Mar '22

I will be attending also. We should try to do a meetup of the NANOG members Thank you Travis Garrison -----Original Message----- From: NANOG <nanog-bounces+tgarrison=netviscom.com(a)nanog.org> On Behalf Of Dave Taht Sent: Wednesday, March 9, 2022 1:25 PM To: Tim Howe <tim.h(a)bendtel.com> Cc: NANOG <nanog(a)nanog.org> Subject: Re: V6 still not supported (was Making Use of 240/4 NetBlock) I am going to attend the WISPA conference in New Orleans next week. (anyone going)

4 3

Re: 202203090732.AYC Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: Making Use of 240/4 NetBlock)
by Abraham Y. Chen 09 Mar '22

09 Mar '22

Dear Mel & Bill: 0) Thank you for your kind advice. 1) To be honest, I am a bit of lost with multiple comments about my eMail Header at the same time. Especially, some seem not in agreement with the other. Rather than opening up a discussion thread, such as "eMail Header Rules" that for sure will distract us from the real topic on the table, I have sent a request to Valerie Wittkop (Program Director) for a copy of the "official" rules for me to follow. Regards, Abe (2022-03-09 23:13) On 2022-03-09 14:23, Abraham Y. Chen wrote: > On 2022-03-09 13:16, Mel Beckman wrote: >> Alternatively, just use BCC. There is no reason for you to tell us >> who else you want to hear what you say. There’s nothing wrong with >> CCing, and nothing in the rules against it, but your recipients may >> not appreciate you distributing their email addresses on this list, >> to which they are not a member. >> >> -mel beckman >> >>> On Mar 9, 2022, at 9:29 AM, William Herrin <bill(a)herrin.us> wrote: >>> >>> >>> Mr. Chen: >>> >>> Would you please stop changing the subject line with an added date >>> stamp every time you post? It fouls threaded email readers and is >>> most inconsiderate. >>> >>> In addition, I respectfully encourage you to trim the recipients to >>> just the mailnig list and the specific individual to whom you are >>> sending a reply. >>> >>> Thanks, >>> Bill Herrin >>> >>> >>> On Wed, Mar 9, 2022 at 9:19 AM William Herrin <bill(a)herrin.us> wrote: >>> >>> Mr. Chen: >>> >>> Would you please stop changing the subject line with an added >>> date stamp every time you post? It fouls threaded email readers >>> and is most inconsiderate. >>> >>> Thanks, >>> Bill Herrin >>> >>> >>> On Wed, Mar 9, 2022 at 9:09 AM Abraham Y. Chen >>> <aychen(a)avinta.com> wrote: >>> >>> Dear John: >>> >>> 1) Thanks for your comment on how eMail headers could be >>> used. >>> >>> Dear Bill: >>> >>> 2) I am glad that you agree that it should be a viable >>> discussion on making use of the 240/4 netblock, while >>> waiting for IPv6 to deliver its promises. >>> >>> 3) As to your question about where does IPv6 stand today >>> and where is it heading, I like to highlight a recent APNIC >>> blog that you may have read. It also appeared on CircleID. >>> After a long recount of the history, the author seems to >>> hint that 1995 may be the new starting point for looking >>> forward. >>> >>> https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?u… >>> <https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?u…> >>> >>> >>> https://circleid.com/posts/20220220-another-year-of-the-transition-to-ipv6 >>> >>> 4) We fully realize that the EzIP approach is quite >>> unorthodox. As such, we received numerous quick criticisms >>> in the past. With the proposal now put together, we do hope >>> colleagues on this list will take the time to review its >>> specifics. I look forward to comments and critiques on its >>> merits. >>> >>> Regards, >>> >>> >>> Abe (2022-03-09 12:08) >>> >>> >>> Message: 7 >>> Date: 8 Mar 2022 15:32:36 -0500 >>> From: "John Levine"<johnl(a)iecc.com> <mailto:johnl@iecc.com> >>> To:nanog@nanog.org >>> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: >>> 202203071610.AYC Re: Making Use of 240/4 NetBlock) >>> Message-ID:<20220308203237.53E7038B1B83(a)ary.qy> <mailto:20220308203237.53E7038B1B83@ary.qy> >>> Content-Type: text/plain; charset=utf-8 >>> >>> It appears that Anne Mitchell<amitchell(a)isipp.com> <mailto:amitchell@isipp.com> said: >>> >>>>> Cc: NANOG<nanog(a)nanog.org> <mailto:nanog@nanog.org>, Greg Skinner<gregskinner0(a)icloud.com> <mailto:gregskinner0@icloud.com>, "Karandikar, Abhay"<Director(a)iitk.ac.in> <mailto:Director@iitk.ac.in>, Rama Ati >>>> <rama_ati(a)outlook.com> <mailto:rama_ati@outlook.com>, Bob Corner GMAIL<bobbiecorner(a)gmail.com> <mailto:bobbiecorner@gmail.com>, "Hsing, T. Russell"<tHsing(a)ieee.org> <mailto:tHsing@ieee.org>, "Chen, Henry C.J." >>>> <hcjchen(a)avinta.com> <mailto:hcjchen@avinta.com>, ST Hsieh<uschinaeetc(a)gmail.com> <mailto:uschinaeetc@gmail.com>, "Chen, Abraham Y."<AYChen(a)alum.mit.edu> <mailto:AYChen@alum.mit.edu> >>>> This is a whole lot of cc:s to people who aren't even part of this group/list. One wonders with this many cc:s, how many bcc:s there also were, and to whom. >>> >>> There are several thousand people on the NANOG list, and public web archives. I don't think this >>> is a useful question. >>> >>> FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require >>> that every host on the Internet update its network stack, which would take on the order of >>> a decade, to free up some space that would likely be depleted in a year or two. It's basically >>> the same amount of work as getting everything to work on IPv6. >>> >>> R's, >>> John >>> >>> >>> ------------------------------ >>> >>> Message: 8 >>> Date: Tue, 8 Mar 2022 13:11:58 -0800 >>> From: William Herrin<bill(a)herrin.us> <mailto:bill@herrin.us> >>> To: John Levine<johnl(a)iecc.com> <mailto:johnl@iecc.com> >>> Cc:"nanog(a)nanog.org" <mailto:nanog@nanog.org> <nanog(a)nanog.org> <mailto:nanog@nanog.org> >>> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: >>> 202203071610.AYC Re: Making Use of 240/4 NetBlock) >>> Message-ID: >>> <CAP-guGVCXC_8H+wgriM=Vv0bqPg4+arw0pXhcQhh7rccrxVxEg(a)mail.gmail.com> <mailto:CAP-guGVCXC_8H+wgriM=Vv0bqPg4+arw0pXhcQhh7rccrxVxEg@mail.gmail.com> >>> Content-Type: text/plain; charset="UTF-8" >>> >>> On Tue, Mar 8, 2022 at 12:34 PM John Levine<johnl(a)iecc.com> <mailto:johnl@iecc.com> wrote: >>> >>>> FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require >>>> that every host on the Internet update its network stack, >>> >>> Hi John, >>> >>> That's incorrect and obviously so. While repurposing 240/4 as general >>> purpose Internet addresses might require that level of effort, other >>> uses such as local LAN addressing would only require the equipment on >>> that one lan to be updated -- a much more attainable goal. >>> >>> Reallocating 240/4 as unpurposed unicast address space would allow >>> some standards-compliant uses to become practical before others. A few >>> quite quickly. >>> >>> >>>> which would take on the order of >>>> a decade, to free up some space that would likely be depleted in a year or two. It's basically >>>> the same amount of work as getting everything to work on IPv6. >>> >>> Is it not past time we admit that we have no real idea what the >>> schedule or level of effort will be for making IPv6 ubiquitous? This >>> year it was more than last year and next year it'll probably be more >>> than this year. The more precise predictions all seem to have fallen >>> flat. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- William Herrin bill(a)herrin.us https://bill.herrin.us/ >>> ------------------------------ >>> >>> >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >>> Virus-free. www.avast.com >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >>> >>> >>> >>> >>> -- >>> William Herrin >>> bill(a)herrin.us >>> <https://bill.herrin.us/> >>> https://bill.herrin.us/ >>> >>> >>> >>> -- >>> William Herrin >>> bill(a)herrin.us >>> <https://bill.herrin.us/> >>> https://bill.herrin.us/ > > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

NANOG 85 Call for Presentations + More
by Nanog News 09 Mar '22

09 Mar '22

*NANOG 85: Call For Presentations * *Are you a top mind in the industry? *Do you have what it takes to spark our imagination, encourage dialogue, + drive new solutions to our greatest networking challenges? We are now accepting proposals for in-person or remote presentations at all sessions of NANOG 85 taking place in Montréal, QC, Canada on June 6 - 8, 2022. Presentations may cover current technologies, soon-to-be deployed technologies, and/or industry innovation. *Requested Topics: * June 6 is the 10 year anniversary of World IPv6 Launch Day! We are actively seeking talks about IPv6. Additionally, based on feedback from our survey results, we have seen numerous requests for the following topics: - Network Automation - Tutorials (IPv6, BGP, Segment Routing, DNS) - Security (developments in, problems/solutions, various protocols) Don’t wait! Presentation abstracts and draft slides should be submitted no later than *Monday, April 25, 2022.* *MORE INFO <https://www.nanog.org/program/call-presentations/>* *NANOG 84 Pictures Now Available* All the unforgettable moments of NANOG 84 are captured in the archives. View the full NANOG 84 photo album today. Download your favorite picture, share on social and tag us! #WeAreNANOG *NANOG 84 PHOTO ALBUM <https://www.flickr.com/photos/nanog/albums/with/72177720297019307>* *Monthly LinkedIn Poll Questions * *We Want Your Feedback!* *NANOG believes in community in its truest sense. * We want to continue the conversation with you. Therefore, we will be hosting monthly LinkedIn Polls to facilitate space for your feedback. Have a question you would like to be polled? Contact us today. Have you joined our thriving LinkedIn community page: NANOG — A Community-Moderated Group? Join now. <https://www.linkedin.com/groups/40718/> *FOLLOW US * <https://www.linkedin.com/company/nanog/posts/?feedView=all>

1 0

Re: 202203090732.AYC Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: Making Use of 240/4 NetBlock)
by William Herrin 09 Mar '22

09 Mar '22

Mr. Chen: Would you please stop changing the subject line with an added date stamp every time you post? It fouls threaded email readers and is most inconsiderate. In addition, I respectfully encourage you to trim the recipients to just the mailnig list and the specific individual to whom you are sending a reply. Thanks, Bill Herrin On Wed, Mar 9, 2022 at 9:19 AM William Herrin <bill(a)herrin.us> wrote: > Mr. Chen: > > Would you please stop changing the subject line with an added date stamp > every time you post? It fouls threaded email readers and is most > inconsiderate. > > Thanks, > Bill Herrin > > > On Wed, Mar 9, 2022 at 9:09 AM Abraham Y. Chen <aychen(a)avinta.com> wrote: > >> Dear John: >> >> 1) Thanks for your comment on how eMail headers could be used. >> >> Dear Bill: >> >> 2) I am glad that you agree that it should be a viable discussion on >> making use of the 240/4 netblock, while waiting for IPv6 to deliver its >> promises. >> >> 3) As to your question about where does IPv6 stand today and where is >> it heading, I like to highlight a recent APNIC blog that you may have read. >> It also appeared on CircleID. After a long recount of the history, the >> author seems to hint that 1995 may be the new starting point for looking >> forward. >> >> >> https://blog.apnic.net/2022/02/21/another-year-of-the-transition-to-ipv6/?u… >> >> >> >> https://circleid.com/posts/20220220-another-year-of-the-transition-to-ipv6 >> >> 4) We fully realize that the EzIP approach is quite unorthodox. As >> such, we received numerous quick criticisms in the past. With the proposal >> now put together, we do hope colleagues on this list will take the time >> to review its specifics. I look forward to comments and critiques on its >> merits. >> >> Regards, >> >> >> Abe (2022-03-09 12:08) >> >> >> Message: 7 >> Date: 8 Mar 2022 15:32:36 -0500 >> From: "John Levine" <johnl(a)iecc.com> <johnl(a)iecc.com> >> To: nanog(a)nanog.org >> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: >> 202203071610.AYC Re: Making Use of 240/4 NetBlock) >> Message-ID: <20220308203237.53E7038B1B83(a)ary.qy> <20220308203237.53E7038B1B83(a)ary.qy> >> Content-Type: text/plain; charset=utf-8 >> >> It appears that Anne Mitchell <amitchell(a)isipp.com> <amitchell(a)isipp.com> said: >> >> Cc: NANOG <nanog(a)nanog.org> <nanog(a)nanog.org>, Greg Skinner <gregskinner0(a)icloud.com> <gregskinner0(a)icloud.com>, "Karandikar, Abhay" <Director(a)iitk.ac.in> <Director(a)iitk.ac.in>, Rama Ati >> >> <rama_ati(a)outlook.com> <rama_ati(a)outlook.com>, Bob Corner GMAIL <bobbiecorner(a)gmail.com> <bobbiecorner(a)gmail.com>, "Hsing, T. Russell" <tHsing(a)ieee.org> <tHsing(a)ieee.org>, "Chen, Henry C.J."<hcjchen(a)avinta.com> <hcjchen(a)avinta.com>, ST Hsieh <uschinaeetc(a)gmail.com> <uschinaeetc(a)gmail.com>, "Chen, Abraham Y." <AYChen(a)alum.mit.edu> <AYChen(a)alum.mit.edu> >> >> This is a whole lot of cc:s to people who aren't even part of this group/list. One wonders with this many cc:s, how many bcc:s there also were, and to whom. >> >> There are several thousand people on the NANOG list, and public web archives. I don't think this >> is a useful question. >> >> FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require >> that every host on the Internet update its network stack, which would take on the order of >> a decade, to free up some space that would likely be depleted in a year or two. It's basically >> the same amount of work as getting everything to work on IPv6. >> >> R's, >> John >> >> >> ------------------------------ >> >> Message: 8 >> Date: Tue, 8 Mar 2022 13:11:58 -0800 >> From: William Herrin <bill(a)herrin.us> <bill(a)herrin.us> >> To: John Levine <johnl(a)iecc.com> <johnl(a)iecc.com> >> Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> <nanog(a)nanog.org> <nanog(a)nanog.org> >> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: >> 202203071610.AYC Re: Making Use of 240/4 NetBlock) >> Message-ID: >> <CAP-guGVCXC_8H+wgriM=Vv0bqPg4+arw0pXhcQhh7rccrxVxEg(a)mail.gmail.com> <CAP-guGVCXC_8H+wgriM=Vv0bqPg4+arw0pXhcQhh7rccrxVxEg(a)mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> On Tue, Mar 8, 2022 at 12:34 PM John Levine <johnl(a)iecc.com> <johnl(a)iecc.com> wrote: >> >> FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require >> that every host on the Internet update its network stack, >> >> Hi John, >> >> That's incorrect and obviously so. While repurposing 240/4 as general >> purpose Internet addresses might require that level of effort, other >> uses such as local LAN addressing would only require the equipment on >> that one lan to be updated -- a much more attainable goal. >> >> Reallocating 240/4 as unpurposed unicast address space would allow >> some standards-compliant uses to become practical before others. A few >> quite quickly. >> >> >> >> which would take on the order of >> a decade, to free up some space that would likely be depleted in a year or two. It's basically >> the same amount of work as getting everything to work on IPv6. >> >> Is it not past time we admit that we have no real idea what the >> schedule or level of effort will be for making IPv6 ubiquitous? This >> year it was more than last year and next year it'll probably be more >> than this year. The more precise predictions all seem to have fallen >> flat. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrinbill@herrin.ushttps://bill.herrin.us/ >> >> >> ------------------------------ >> >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. >> www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> <#m_1889185439734392099_m_-9011500040057407468_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > > > -- > William Herrin > bill(a)herrin.us > <https://bill.herrin.us/> > https://bill.herrin.us/ > -- William Herrin bill(a)herrin.us <https://bill.herrin.us/> https://bill.herrin.us/

2 2

202203081821.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock
by Abraham Y. Chen 08 Mar '22

08 Mar '22

Hi, Stephen: 1) First, logistics: Since I have been waiting for the moderation of my first posting on NANOG, could I assume that you are sending me this personal eMail as a Moderator? 2) Perhaps the material provided in my writing was not sufficient, you seem to be expressing concerns from other perspectives. As concisely characterized by one of the "Internet fathers", the EzIP is an overlay network relative to the current Internet. As such, the EzIP deployment is pretty much independent of the hurdles that the current Internet equipment or convention may impose on it. That is, we can start the EzIP deployment leaving everything in the current Internet alone. This is because each EzIP deployment module, called RAN (Regional Area Network) is tethered via one IPv4 public address onto the Internet core. Since each RAN appears to be a private network, it can be set up according to its own requirements. That is, each RAN can make use of any desired IPv4 technology, while leaving others aside. As long as the packets on that single access path between the RAN and the Internet conform to the Internet conventions, the deployment of the EzIP proposal should work. 3) " ... if you plan on endpoint computers (such as those in homes) to use the 240/4 netblock. ... ": No, we do not. As presented by the RAN demonstration cited by the whitepaper, one of the primary criteria of the EzIP proposal is not to affect the current private network setups. Although, other than Windows OS based products, there are more and more IoTs do support 240/4 netblock. Even some Internet routers appear to do so, as well. 4) " ... DD-WRT project? ... ": EzIP does not have any ambition to alter or replace the existing Internet equipment in any sense. Fortunately, we can deploy our solution without such complication due to the overlay characteristics. Our main goal is to demonstrate that "*/there exists/*" one feasible configuration that can operate EzIP in parallel to the existing Internet for providing equivalent services. From such a skeletal reference, one can expand to larger deployments, as well as put on desired features and capabilities. For example, we have utilized OpenWrt 19.07.3 to demonstrate the feasibility of the EzIP scheme. Since the enabling technique is "disabling the program code that has been disabling the use of the 240/4 netblock", any other projects such as DD-WRT can replicate it just as well, if so inclined. 5) "... Firewalls ... NIST ... ": Since EzIP is only identifying the additional address resources from the "Reserve" and suggesting how to use it, I am not clear why high level functionalities such as security related firewall tasks get involved here. Do NIST Guidelines specify blocking any packet with the 240/4 netblock address? I failed to spot such. Since there is no natural division between the 240/4 netblock from the rest of IPv4 address pool, I can't see any reason to single this netblock out in the firewall related tasks anyway. Do you know the reason why? I would appreciate very much if you could elaborate your concerns. 6) By the way, the EzIP's RAN is actually very much the same as CG-NAT or CDN, architecturally. The only difference is that EzIP Project manged to identify a larger usable address pool enabling the practice of static addressing to simplify operation logistics, mitigate cyber insecurity, etc. I look forward to your thoughts. Regards, Abe (2022-03-09 23:28 EST) On 2022-03-08 13:08, Stephen Satchell wrote: > On 3/7/22 2:14 PM, Abraham Y. Chen wrote: >> In a nutshell, EzIP proposes to disable the program codes in >> current routers that have been disabling the use of the 240/4 >> NetBlock. The cost of this software engineering should be minimal. >> The EzIP deployment architecture is the same as that of the existing >> CG-NAT (Carrier Grade Network Address Translation). Consequently, >> there is no need to modify any hardware equipment. There is an online >> setup description (Reference II), called RAN (Regional Area Network), >> that demonstrates the feasibility of this approach. > > You have another surface that will need to dealt with if you plan on > endpoint computers (such as those in homes) to use the 240/4 netblock. > You will need to talk to the authors of firewall books and web sites > to update the examples to remove all-traffic blocks on 240/4. Then > individual administrations, not just ISP/Service-Provider, will need > to know to modify any home-brew firewalls to open all addresses except > 255.255.255.255 (and perhaps 240.0.0.0). > > That includes my publications about firewall configurations. > > If you haven't already, you will need to include makers of access > points and companies such as SonicWALL. Have you talked to pfSense? > DD-WRT project? UFW project? firewalld project? The Berkeley Packet > Filter project? How about authors of the NIST _Guidelines on > Firewalls and Firewall Policy_ publication > (https://www.govinfo.gov/content/pkg/GOVPUB-C13-f52fdee3827e2f5d903fa8b4b66d…) > > I wish you luck. And that's only the things I found in English. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

VoLTE and SRTP
by Michael Thomas 08 Mar '22

08 Mar '22

Hi, I was reading an article on why Russia hasn't taken out Ukraine's mobile networks and one of the premises was that they could use it to eavesdrop on calls. Depending on how old their infrastructure is, that doesn't make sense as I would assume that along with e2e SIP that they'd be using SRTP with the SRTP keys exchanged using DTLS which is my understanding of the way they are secured. My understanding could be wrong though, or either outdated, or not uniformly deployed. The other thing that's weird is that the same article says they want to keep it up so they can use their bandwidth too which strikes me as sort of a crazy assumption in a war, but that's not much of an operational issue. https://www.politico.com/news/2022/03/07/ukraine-phones-internet-still-work… Mike

5 6