- Test - lists.nanog.org

Weekly Global IPv4 Routing Table Report
by Routing Table Analysis Role Account 01 Apr '22

01 Apr '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 02 Apr, 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: 894261 Prefixes after maximum aggregation (per Origin AS): 336800 Deaggregation factor: 2.66 Unique aggregates announced (without unneeded subnets): 429313 Total ASes present in the Internet Routing Table: 72943 Prefixes per ASN: 12.26 Origin-only ASes present in the Internet Routing Table: 62600 Origin ASes announcing only one prefix: 25737 Transit ASes present in the Internet Routing Table: 10343 Transit-only ASes present in the Internet Routing Table: 374 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 64 Max AS path prepend of ASN (267602) 58 Prefixes from unregistered ASNs in the Routing Table: 857 Number of instances of unregistered ASNs: 862 Number of 32-bit ASNs allocated by the RIRs: 38970 Number of 32-bit ASNs visible in the Routing Table: 32390 Prefixes from 32-bit ASNs in the Routing Table: 151943 Number of bogon 32-bit ASNs visible in the Routing Table: 25 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 458 Number of addresses announced to Internet: 3067757056 Equivalent to 182 /8s, 218 /16s and 66 /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: 303502 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 234083 Total APNIC prefixes after maximum aggregation: 66355 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 229063 Unique aggregates announced from the APNIC address blocks: 94311 APNIC Region origin ASes present in the Internet Routing Table: 12508 APNIC Prefixes per ASN: 18.31 APNIC Region origin ASes announcing only one prefix: 3558 APNIC Region transit ASes present in the Internet Routing Table: 1718 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 7709 Number of APNIC addresses announced to Internet: 773920384 Equivalent to 46 /8s, 33 /16s and 22 /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: 260493 Total ARIN prefixes after maximum aggregation: 119704 ARIN Deaggregation factor: 2.18 Prefixes being announced from the ARIN address blocks: 260322 Unique aggregates announced from the ARIN address blocks: 124053 ARIN Region origin ASes present in the Internet Routing Table: 19004 ARIN Prefixes per ASN: 13.70 ARIN Region origin ASes announcing only one prefix: 6901 ARIN Region transit ASes present in the Internet Routing Table: 1950 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: 4423 Number of ARIN addresses announced to Internet: 1295374080 Equivalent to 77 /8s, 53 /16s and 215 /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: 256769 Total RIPE prefixes after maximum aggregation: 117224 RIPE Deaggregation factor: 2.19 Prefixes being announced from the RIPE address blocks: 254143 Unique aggregates announced from the RIPE address blocks: 150645 RIPE Region origin ASes present in the Internet Routing Table: 28112 RIPE Prefixes per ASN: 9.04 RIPE Region origin ASes announcing only one prefix: 12060 RIPE Region transit ASes present in the Internet Routing Table: 3974 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: 10661 Number of RIPE addresses announced to Internet: 714114944 Equivalent to 42 /8s, 144 /16s and 135 /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: 114180 Total LACNIC prefixes after maximum aggregation: 27436 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 114160 Unique aggregates announced from the LACNIC address blocks: 48228 LACNIC Region origin ASes present in the Internet Routing Table: 10948 LACNIC Prefixes per ASN: 10.43 LACNIC Region origin ASes announcing only one prefix: 2654 LACNIC Region transit ASes present in the Internet Routing Table: 2205 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 64 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8643 Number of LACNIC addresses announced to Internet: 176362240 Equivalent to 10 /8s, 131 /16s and 19 /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: 27879 Total AfriNIC prefixes after maximum aggregation: 5433 AfriNIC Deaggregation factor: 5.13 Prefixes being announced from the AfriNIC address blocks: 36115 Unique aggregates announced from the AfriNIC address blocks: 11686 AfriNIC Region origin ASes present in the Internet Routing Table: 1622 AfriNIC Prefixes per ASN: 22.27 AfriNIC Region origin ASes announcing only one prefix: 564 AfriNIC Region transit ASes present in the Internet Routing Table: 327 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: 954 Number of AfriNIC addresses announced to Internet: 107723520 Equivalent to 6 /8s, 107 /16s and 187 /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 9146 8884 44 CHINAMOBILE-CN China Mobile Communicati 7545 5906 789 699 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4713 4192 75 ERX-CERNET-BKB China Education and Rese 7552 3607 1330 19 VIETEL-AS-AP Viettel Group, VN 7713 3499 1038 51 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 3435 1880 56 VNPT-AS-VN VNPT Corp, VN 4766 2497 11121 601 KIXS-AS-KR Korea Telecom, KR 9498 2391 491 238 BBIL-AP BHARTI Airtel Ltd., IN 45090 2147 1438 79 TENCENT-NET-AP Shenzhen Tencent Compute 4755 2114 429 196 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 6152 10256 2661 AMAZON-02, US 11492 4456 296 714 CABLEONE, US 22773 3938 3060 365 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3900 264 31 VIASAT-SP-BACKBONE, US 16625 3635 1870 2562 AKAMAI-AS, US 6327 3419 1318 62 SHAW, CA 749 2882 50780 2138 DNIC-AS-00749, US 30036 2610 373 153 MEDIACOM-ENTERPRISE-BUSINESS, US 209 2522 4962 425 CENTURYLINK-US-LEGACY-QWEST, US 20115 2256 3042 495 CHARTER-20115, US Complete listing at https://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 6801 1730 149 UNI2-AS, ES 9121 6714 1692 17 TTNET, TR 8551 4001 374 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 3928 3360 200 AKAMAI-ASN1, NL 39891 3819 220 34 ALJAWWALSTC-AS, SA 12389 2959 2274 909 ROSTELECOM-AS, RU 6849 2859 355 21 UKRTELNET, UA 9009 2472 248 1292 M247, GB 34984 2214 356 620 TELLCOM-AS, TR 47331 2084 328 1596 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 10511 3404 556 Uninet S.A. de C.V., MX 10620 3475 519 714 Telmex Colombia S.A., CO 11830 2430 369 62 Instituto Costarricense de Electricidad 13999 1729 293 471 Mega Cable, S.A. de C.V., MX 6503 1447 355 524 Axtel, S.A.B. de C.V., MX 28573 1393 2332 253 CLARO S.A., BR 3816 1256 667 148 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 1084 369 21 Telefonica del Peru S.A.A., PE 11664 1006 192 447 Techtel LMDS Comunicaciones Interactiva 11172 956 133 63 Alestra, S. de R.L. de C.V., MX Complete listing at https://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1583 393 21 LINKdotNET-AS, EG 24835 1548 523 33 RAYA-AS, EG 36992 1303 1518 261 ETISALAT-MISR, EG 36903 1199 545 114 MT-MPLS, MA 29571 894 64 59 ORANGE-COTE-IVOIRE, CI 36935 771 520 42 Vodafone-, EG 6713 612 1863 34 IAM-AS, MA 15399 517 51 34 WANANCHI-, KE 37342 469 32 1 MOVITEL, MZ 23889 424 232 16 MauritiusTelecom, MU Complete listing at https://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 10511 3404 556 Uninet S.A. de C.V., MX 9808 9146 8884 44 CHINAMOBILE-CN China Mobile Communicati 12479 6801 1730 149 UNI2-AS, ES 9121 6714 1692 17 TTNET, TR 16509 6152 10256 2661 AMAZON-02, US 7545 5906 789 699 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4713 4192 75 ERX-CERNET-BKB China Education and Rese 11492 4456 296 714 CABLEONE, US 8551 4001 374 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 22773 3938 3060 365 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 9146 9102 CHINAMOBILE-CN China Mobile Communications Grou 9121 6714 6697 TTNET, TR 12479 6801 6652 UNI2-AS, ES 7545 5906 5207 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4713 4638 ERX-CERNET-BKB China Education and Research Net 8551 4001 3962 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7155 3900 3869 VIASAT-SP-BACKBONE, US 39891 3819 3785 ALJAWWALSTC-AS, SA 11492 4456 3742 CABLEONE, US 20940 3928 3728 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:307 /13:588 /14:1204 /15:2055 /16:13552 /17:8313 /18:13886 /19:25175 /20:43277 /21:52232 /22:108492 /23:95605 /24:528595 /25:809 /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 5869 6714 TTNET, TR 12479 5780 6801 UNI2-AS, ES 8151 4165 10511 Uninet S.A. de C.V., MX 8551 3475 4001 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3364 4456 CABLEONE, US 6327 3231 3419 SHAW, CA 39891 3131 3819 ALJAWWALSTC-AS, SA 7155 2990 3900 VIASAT-SP-BACKBONE, US 22773 2936 3938 ASN-CXA-ALL-CCI-22773-RDC, US 6849 2712 2859 UKRTELNET, UA Complete listing at https://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1843 2:1036 3:154 4:7 5:3792 6:112 7:5 8:1563 9:1 11:172 12:1709 13:288 14:2386 15:189 16:44 17:380 18:148 20:194 21:4 22:188 23:5581 24:2291 25:6 27:2594 29:19 31:2440 32:96 34:1 35:69 36:1756 37:4416 38:2667 39:708 40:151 41:3930 42:998 43:2157 44:288 45:16106 46:4139 47:349 49:1682 50:1923 51:107 52:1409 53:1 54:362 55:710 56:8 57:58 58:1805 59:1196 60:955 61:2268 62:2487 63:1945 64:5512 65:2301 66:4859 67:2973 68:1180 69:4159 70:1343 71:658 72:3064 74:2661 75:1389 76:588 77:2149 78:3895 79:3104 80:1984 81:1738 82:1479 83:1197 84:1333 85:3645 86:714 87:1970 88:2697 89:3280 90:519 91:7620 92:1986 93:2607 94:3489 95:4752 96:1312 97:347 98:991 99:770 100:74 101:1029 102:2017 103:28748 104:4294 105:466 106:842 107:2510 108:824 109:4227 110:2068 111:3296 112:2011 113:1523 114:1480 115:1956 116:1904 117:2518 118:2268 119:1865 120:1679 121:1060 122:2553 123:2123 124:1594 125:2112 128:1196 129:1212 130:913 131:2073 132:763 133:373 134:1931 135:290 136:876 137:874 138:2427 139:1496 140:852 141:1389 142:1283 143:1483 144:1235 145:342 146:1772 147:1473 148:2214 149:1706 150:849 151:1077 152:1837 153:459 154:3513 155:1434 156:1899 157:1236 158:1029 159:2082 160:2440 161:1326 162:3464 163:1236 164:1643 165:1603 166:693 167:1717 168:3756 169:701 170:4435 171:823 172:3103 173:3075 174:1019 175:1129 176:3509 177:4569 178:3449 179:2000 180:2276 181:2950 182:3249 183:1942 184:2385 185:19483 186:4370 187:3667 188:3878 189:3139 190:8861 191:1309 192:11012 193:8588 194:6945 195:4970 196:2980 197:2407 198:6024 199:6016 200:7485 201:5663 202:10498 203:10016 204:4551 205:3380 206:3766 207:3400 208:4041 209:4662 210:4256 211:2453 212:4009 213:3407 214:1155 215:67 216:6448 217:2659 218:1261 219:573 220:1951 221:980 222:846 223:2140 End of report

1 0

AS21299 - 46.42.196.0/24 ASN prepending 255 times
by Erik Sundberg 01 Apr '22

01 Apr '22

If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks! This is a Kazakhstan register IP Block and ASN Network Next Hop Metric LocPrf Weight Path *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

13 20

Proper Planning for Cellular Networks in Ukraine
by Sean Donelan 01 Apr '22

01 Apr '22

Whether its preparing for a natural disaster like a hurricane or a russian invasion, proper advance planning makes a difference. The cellular network operators and national regulator in Ukraine have been preparing for years. "It must be kept in mind, that many of these changes could not have taken place over-night, that they are the culmination of months, and in some cases years of preparation." The Mobile Network Battlefield in Ukraine - Part 1 https://blog.adaptivemobile.com/the-mobile-network-battlefield-in-ukraine-p… The Mobile Network Battlefield in Ukraine - Part 2 https://blog.adaptivemobile.com/the-mobile-network-battlefield-in-ukraine-p… "Finally, one unusual perspective that has been taken by some observers, in trying to explain why Ukrainian Mobile Networks were still functioning after several weeks of war, was to put it all down to decisions made by the Russian forces. [...] We believe that this viewpoint is fundamentally wrong, as the cadence and scope of the decisions made by the Ukrainian Mobile Operators, both before and after the Invasion - as well as their ongoing work to keep them active - show that they are clearly engaged in the fight to keep these networks alive."

1 0

deadly wifi
by William Herrin 01 Apr '22

01 Apr '22

In Venezuela, asking for the wifi password can get you killed. https://www.washingtonpost.com/world/2022/03/31/venezuela-army-yanomami-kil… -- William Herrin bill(a)herrin.us https://bill.herrin.us/

1 0

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
by Abraham Y. Chen 01 Apr '22

01 Apr '22

Hi, Pascal: What I would appreciate is an IP packet header design/definition layout, word-by-word, ideally in bit-map style, of an explicit presentation of all IP addresses involved from one IoT in one realm to that in the second realm. This will provide a clearer picture of how the real world implementation may look like. Thanks, Abe (2022-04-01 09:48) On 2022-04-01 08:49, Vasilenko Eduard wrote: > > As I understand: “IPv4 Realms” between “Shaft” should be capable to > have a plain IPv4 header (or else why all of these). > > Then Gateway in the Shaft should change headers (from IPv4 to IPv6). > > Who should implement this gateway and why? He should be formally > appointed to such an exercise, right? > > Map this 2 level hierarchy to the real world – you may fail with this. > > Ed/ > > *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > *Sent:* Friday, April 1, 2022 3:41 PM > *To:* Vasilenko Eduard <vasilenko.eduard(a)huawei.com>; Justin Streiner > <streinerj(a)gmail.com>; Abraham Y. Chen <aychen(a)avinta.com> > *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not > supported re: 202203261833.AYC > > Hello Eduard: > > Did you just demonstrate that POPs cannot exist? Or that there cannot > be a Default Free Zone? > > I agree with your real world issue that some things will have to be > planned between stake holders, and that it will not be easy. > > But you know what the French say about “impossible”. > > Or to paraphrase Sir Arthur, now that we have eliminated all the > impossible transition scenarios, whatever remains… > > There will be YADA prefixes just like there are root DNS. To be > managed by different players as you point out. And all routable within > the same shaft. > > Keep safe; > > Pascal > > *From:* Vasilenko Eduard <vasilenko.eduard(a)huawei.com> > *Sent:* vendredi 1 avril 2022 14:32 > *To:* Pascal Thubert (pthubert) <pthubert(a)cisco.com>; Justin Streiner > <streinerj(a)gmail.com>; Abraham Y. Chen <aychen(a)avinta.com> > *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not > supported re: 202203261833.AYC > > Hi Pascal, > > In general, your idea to create a hierarchy is good. > > In practice, it would fail because you have created a virtual > hierarchy that does not map to any administrative border. Who should > implement gateways for the “Shaft”? Why? > > If you would appoint Carrier as the Shaft responsible then it is not > enough bits for Shaft. > > If you would appoint Governments as the Shaft responsible then would > be a so big scandal that you would regret the proposal. > > Hence, I do not see proper mapping for the hierarchy to make YADA > successful. > > Eduard > > *From:* NANOG > [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org > <mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org>] *On > Behalf Of *Pascal Thubert (pthubert) via NANOG > *Sent:* Friday, April 1, 2022 2:26 PM > *To:* Justin Streiner <streinerj(a)gmail.com>; Abraham Y. Chen > <aychen(a)avinta.com> > *Cc:* NANOG <nanog(a)nanog.org> > *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not > supported re: 202203261833.AYC > > For the sake of it, Justin, I just published > https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/. > > The first section of the draft (YADA) extends IPv4 range in an > IPv4-only world. For some people that might be enough and I’m totally > fine with that. > > Keep safe; > > Pascal > > *From:* NANOG <nanog-bounces+pthubert=cisco.com(a)nanog.org> *On Behalf > Of *Justin Streiner > *Sent:* dimanche 27 mars 2022 18:12 > *To:* Abraham Y. Chen <aychen(a)avinta.com> > *Cc:* NANOG <nanog(a)nanog.org> > *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not > supported re: 202203261833.AYC > > Abe: > > To your first point about denying that anyone is being stopped from > working on IPv4, I'm referring to users being able to communicate via > IPv4. I have seen no evidence of that. > > I'm not familiar with the process of submitting ideas to IETF, so I'll > leave that for others who are more knowledgeable on that to speak up > if they're so inclined. > > Thank you > > jms > > On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen <aychen(a)avinta.com> wrote: > > 1) "... no one is stopping anyone from working on IPv4 ... ": > After all these discussions, are you still denying this basic > issue? For example, there has not been any straightforward way to > introduce IPv4 enhancement ideas to IETF since at least 2015. If > you know the way, please make it public. I am sure that many are > eager to learn about it. Thanks. > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

IPv6 "bloat"
by Michael Thomas 01 Apr '22

01 Apr '22

So out of the current discussions a lot of people have claimed that ipv6 is bloated or suffers from second system syndrome, etc. So I decided to look at a linux kernel (HEAD I assume) and look at the differences between the v6 and v4 directories. I just crudely did a line count as a quick measure: ipv6: 68k lines ipv4: 97k lines ipv4 looks to have the tcp and udp implementations (35k) so backing that out it is about 62k lines. That's pretty comparable. Linux has full routing capability so the kernel implements it for both. So I'm just not getting where this "bloat" is. 10% growth for a second system syndrome seems almost miraculously good, imo. What am i missing? This is in complete agreement with my intuition 30 years ago that it was no big deal, at least from a software standpoint. Mike

10 32

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
by Abraham Y. Chen 01 Apr '22

01 Apr '22

Hi, Justin: 1) "... no one is stopping anyone from working on IPv4 ... ": After all these discussions, are you still denying this basic issue? For example, there has not been any straightforward way to introduce IPv4 enhancement ideas to IETF since at least 2015. If you know the way, please make it public. I am sure that many are eager to learn about it. Thanks. Regards, Abe (2022-03-26 18:42) On 2022-03-26 11:20, Justin Streiner wrote: > While the Internet is intended to allow the free exchange of > information, the means of getting that information from place to place > is and has to be defined by protocols that are implemented in a > consistent manner (see: BGP, among many other examples). It's > important to separate the ideas from the plumbing. > > That said, no one is stopping anyone from working on IPv4, so what > personal freedoms are being impacted by working toward deploying IPv6, > with an eye toward sunsetting IPv4 in the future? > > Keep in mind that IPv4 started out as an experiment that found its way > into wider use. It's a classic case of a test deployment that > suddenly mutated into a production service. Why should we continue to > expend effort to perpetuate the sins of the past, rather work toward > getting v6 into wider use? > > Is IPv6 a perfect protocol? Absolutely not, but it addresses the key > pain point of IPv4 - address space exhaustion. > > Thank you > jms > > On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen <aychen(a)avinta.com> wrote: > > > 3) Re: Ur. Pts. 5) & 6): I believe that there is a > philosophic / logic baseline that we need to sort out, first. That > is, we must keep in mind that the Internet community strongly > promotes "*/personal freedom/*". Assuming that by stopping others > from working on IPv4 will shift their energy to IPv6 is totally > contradicting such a principle. A project attracts contributors by > its own merits, not by relying on artificial barriers to the > competitions. Based on my best understanding, IPv6 failed right > after the decision of "not emphasizing the backward compatibility > with IPv4". It broke one of the golden rules in the system > engineering discipline. After nearly three decades, still evading > such fact, but defusing IPv6 issues by various tactics is the real > impedance to progress, not only to IPv4 but also to IPv6. > > > > <#m_4226728999263060367_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

9 19

What's a "normal" ratio of web sites to IP addresses...
by Bill Woodcock 01 Apr '22

01 Apr '22

…in a run-of-the-mill web hoster? This is really a question specifically for folks with web-site-hosting businesses. If you had, say, ten million web site customers, each with their own unique domain name, how many IPv4 addresses would you think was a reasonable number to host those on? HTTP name-based virtual-hosting means that you could, hypothetically, pile all ten million into a single IP address. At the other end of the spectrum, you could chew up ten million IPv4 addresses, giving a unique one to each customer. Presumably the actual practice lies somewhere in-between. But what ratio do people in that business think is reasonable? 10:1? 100:1? 1,000:1? I’m happy to take private replies and summarize/anonymize back to the list, if people prefer. Thanks! -Bill

4 4

End of Mariupol's Internet
by Sean Donelan 01 Apr '22

01 Apr '22

The Last Days Of Mariupol’s Internet https://www.forbes.com/sites/thomasbrewster/2022/03/31/the-last-days-of-mar… "Engineers who kept Ukraine’s port city online have gone missing or died in the carnage inflicted by Russia’s siege. Hope remains that Ukrainian cities knocked off the internet map will come back online fast once the shelling ends."

1 0

IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
by Jacques Latour 01 Apr '22

01 Apr '22

So, in 25, 50 or 100 years from now, are we still going to be dual stack IPv4/IPv6? When are we going to give up on IPv4? People can run IPv4 all they want inside their networks for 1000s of years. What will it take to be IPv6 only? 😊 From: NANOG <nanog-bounces+jacques.latour=cira.ca(a)nanog.org> On Behalf Of Owen DeLong via NANOG Sent: March 29, 2022 3:52 PM To: Abraham Y. Chen <aychen(a)avinta.com> Cc: NANOG <nanog(a)nanog.org> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Submit an Internet draft, same as any other IP related enhancement gets introduced. What you’re really complaining about is that it’s been virtually impossible to gain consensus to move anything IPv4 related forward in the IETF since at least 2015. Well… It’s a consensus process. If your idea isn’t getting consensus, then perhaps it’s simply that the group you are seeking consensus from doesn’t like your idea. Your inability to convince the members of the various working groups that your idea has merit isn’t necessarily a defect in the IETF process… It might simply be a lack of merit in your ideas. Owen On Mar 26, 2022, at 15:43 , Abraham Y. Chen <aychen(a)avinta.com<mailto:aychen@avinta.com>> wrote: Hi, Justin: 1) "... no one is stopping anyone from working on IPv4 ... ": After all these discussions, are you still denying this basic issue? For example, there has not been any straightforward way to introduce IPv4 enhancement ideas to IETF since at least 2015. If you know the way, please make it public. I am sure that many are eager to learn about it. Thanks. Regards, Abe (2022-03-26 18:42) On 2022-03-26 11:20, Justin Streiner wrote: While the Internet is intended to allow the free exchange of information, the means of getting that information from place to place is and has to be defined by protocols that are implemented in a consistent manner (see: BGP, among many other examples). It's important to separate the ideas from the plumbing. That said, no one is stopping anyone from working on IPv4, so what personal freedoms are being impacted by working toward deploying IPv6, with an eye toward sunsetting IPv4 in the future? Keep in mind that IPv4 started out as an experiment that found its way into wider use. It's a classic case of a test deployment that suddenly mutated into a production service. Why should we continue to expend effort to perpetuate the sins of the past, rather work toward getting v6 into wider use? Is IPv6 a perfect protocol? Absolutely not, but it addresses the key pain point of IPv4 - address space exhaustion. Thank you jms On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen <aychen(a)avinta.com<mailto:aychen@avinta.com>> wrote: 3) Re: Ur. Pts. 5) & 6): I believe that there is a philosophic / logic baseline that we need to sort out, first. That is, we must keep in mind that the Internet community strongly promotes "personal freedom". Assuming that by stopping others from working on IPv4 will shift their energy to IPv6 is totally contradicting such a principle. A project attracts contributors by its own merits, not by relying on artificial barriers to the competitions. Based on my best understanding, IPv6 failed right after the decision of "not emphasizing the backward compatibility with IPv4". It broke one of the golden rules in the system engineering discipline. After nearly three decades, still evading such fact, but defusing IPv6 issues by various tactics is the real impedance to progress, not only to IPv4 but also to IPv6.

5 5