- NANOG - lists.nanog.org

.bv ccTLD
by Jay R. Ashworth 06 Dec '21

06 Dec '21

My favorite youtuber has just pointed out that Bougainville will separate formally from Papua New Guinea in 2027, which, surprisingly, is only 5 or 6 years from now. So I looked up .bv, and of course... it's assigned to Bouvet Island, an uninhabited island whose political superior says anything that might go in that TLD will go in .no instead. [Wikipedia] So, what's the actual status of .bv? Assigned, or reserved? And if it is reserved at the 3166 secretariat level, can they reassign it? NORID might try to make a case that BV is the common corporate abbreviation in their political subdivision... but they're not selling those domains now, so that doesn't seem compelling. Anyone here got a buddy on the secretariat? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

15 30

Re: questions about ARIN ipv6 allocation
by Owen DeLong 05 Dec '21

05 Dec '21

> On Dec 4, 2021, at 8:24 PM, Sylvain Baya <abscoco(a)gmail.com> wrote: > > Dear NANOGers, > > Le dim. 5 déc. 2021 04:00, Owen DeLong via NANOG <nanog(a)nanog.org <mailto:nanog@nanog.org>> a écrit : > I would be more than happy to consilolidate my ipv6 addresses under my lrsa, but ARIN will not allow it. > > > Hi Owen, > ...so you want to convert community-based > INRs into legacy INRs? Nope… I see no difference between community and legacy INRs… They’re all community INRs, the only difference is when they were registered and with which registry they were originally registered. > Please, brother, explain your peculiar need. The difference between the lRSA and the RSA is strictly some base protections on how fast the fees can increase, protections which ARIN has already, in fact, found clever ways to violate. It’s not all that peculiar… I’m just more vocal about it than others with both types of resources, in part, because those with vast holdings are more likely to participate in ARIN processes and those with little are less likely to even be fully aware of that ability. Those with vast holdings are receiving a subsidy in this latest fee structure change by the ARIN board, but that subsidy is being provided on the backs of those with less. Owen > > Thanks. > > Shalom, > --sb. > > > > Owen > > >> On Dec 4, 2021, at 17:43, John Curran <jcurran(a)arin.net <mailto:jcurran@arin.net>> wrote: >> >> Yes Owen, that is correct… >> >> If an organization insists on maintaining multiple contractual relationships with ARIN (for whatever reason) then they will be billed for each relation separately - and that is indeed likely to be more than having a single consolidated agreement for all number resources. >> >> Thanks, >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers >> >>> On Dec 4, 2021, at 7:09 PM, Owen DeLong <owen(a)delong.com <mailto:owen@delong.com>> wrote: >>> >>> >>> >>>> On Dec 4, 2021, at 8:59 AM, John Curran <jcurran(a)arin.net <mailto:jcurran@arin.net>> wrote: >>>> >>>> Just for clarity - ARIN’s fee schedule is such that ISP customers (i.e. those with registration service plans) pay an annual services fee based on their higher category of IPv4 or IPv6 resources – i.e. those with IPv4 resources can obtain a corresponding size of IPv6 resources without any change in size category or increase in their annual fee. >>>> >>>> [Also worth noting - as of January 2022, all end-user customers are moving to the same registration services plan, and similarly those with just IPv4 number resources be able to obtain corresponding IPv6 resources without change to their annual fee.] >>> >>> This, whether they want to or not… In many cases resulting in significant unwanted fee increases, especially if you have a mix of resources covered under RSA and LRSA due to ARIN’s accounting limitations that they are perversely disincentivized against fixing because it allows them to essentially double-bill. >>> >>> Owen >>>> >>>

1 0

Weekly Global IPv4 Routing Table Report
by Routing Table Analysis Role Account 03 Dec '21

03 Dec '21

This is an automated weekly mailing describing the state of the Gobal 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>. Global IPv4 Routing Table Report 04:00 +10GMT Sat 04 Dec, 2021 BGP Table as seen in Japan. Report Website: https://thyme.apnic.net Detailed Analysis: https://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 872006 Prefixes after maximum aggregation (per Origin AS): 330232 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 422156 Number of IPv4 prefixes with ROAs (including AS0): 249668 Total ASes present in the Internet Routing Table: 72344 Prefixes per ASN: 12.05 Origin-only ASes present in the Internet Routing Table: 62105 Origin ASes announcing only one prefix: 25642 Transit ASes present in the Internet Routing Table: 10239 Transit-only ASes present in the Internet Routing Table: 369 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: 887 Number of instances of unregistered ASNs: 889 Number of 32-bit ASNs allocated by the RIRs: 37979 Number of 32-bit ASNs visible in the Routing Table: 31483 Prefixes from 32-bit ASNs in the Routing Table: 145463 Number of bogon 32-bit ASNs visible in the Routing Table: 26 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 846 Number of addresses announced to Internet: 3072974336 Equivalent to 183 /8s, 41 /16s and 222 /24s Percentage of available address space announced: 83.0 Percentage of allocated address space announced: 83.0 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: 290540 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 231180 Total APNIC prefixes after maximum aggregation: 64867 APNIC Deaggregation factor: 3.56 Prefixes being announced from the APNIC address blocks: 226302 Unique aggregates announced from the APNIC address blocks: 93047 APNIC Region origin ASes present in the Internet Routing Table: 12095 APNIC Prefixes per ASN: 18.71 APNIC Region origin ASes announcing only one prefix: 3445 APNIC Region transit ASes present in the Internet Routing Table: 1696 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 37 Number of APNIC region 32-bit ASNs visible in the Routing Table: 7281 Number of APNIC addresses announced to Internet: 772945024 Equivalent to 46 /8s, 18 /16s and 52 /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: 256286 Total ARIN prefixes after maximum aggregation: 118209 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 255988 Unique aggregates announced from the ARIN address blocks: 122305 ARIN Region origin ASes present in the Internet Routing Table: 18945 ARIN Prefixes per ASN: 13.51 ARIN Region origin ASes announcing only one prefix: 6864 ARIN Region transit ASes present in the Internet Routing Table: 1961 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 35 Number of ARIN region 32-bit ASNs visible in the Routing Table: 4238 Number of ARIN addresses announced to Internet: 1301094144 Equivalent to 77 /8s, 141 /16s and 31 /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: 243471 Total RIPE prefixes after maximum aggregation: 114034 RIPE Deaggregation factor: 2.14 Prefixes being announced from the RIPE address blocks: 239594 Unique aggregates announced from the RIPE address blocks: 147010 RIPE Region origin ASes present in the Internet Routing Table: 28167 RIPE Prefixes per ASN: 8.51 RIPE Region origin ASes announcing only one prefix: 12154 RIPE Region transit ASes present in the Internet Routing Table: 3936 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: 10564 Number of RIPE addresses announced to Internet: 713663360 Equivalent to 42 /8s, 137 /16s and 163 /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: 113023 Total LACNIC prefixes after maximum aggregation: 27152 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 113869 Unique aggregates announced from the LACNIC address blocks: 47730 LACNIC Region origin ASes present in the Internet Routing Table: 10809 LACNIC Prefixes per ASN: 10.53 LACNIC Region origin ASes announcing only one prefix: 2625 LACNIC Region transit ASes present in the Internet Routing Table: 2149 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 53 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8489 Number of LACNIC addresses announced to Internet: 176382720 Equivalent to 10 /8s, 131 /16s and 99 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-272796 + 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: 27159 Total AfriNIC prefixes after maximum aggregation: 5293 AfriNIC Deaggregation factor: 5.13 Prefixes being announced from the AfriNIC address blocks: 35407 Unique aggregates announced from the AfriNIC address blocks: 11292 AfriNIC Region origin ASes present in the Internet Routing Table: 1581 AfriNIC Prefixes per ASN: 22.40 AfriNIC Region origin ASes announcing only one prefix: 554 AfriNIC Region transit ASes present in the Internet Routing Table: 310 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 42 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 911 Number of AfriNIC addresses announced to Internet: 108346624 Equivalent to 6 /8s, 117 /16s and 61 /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 8752 9000 57 CHINAMOBILE-CN China Mobile Communicati 7545 5859 787 681 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4670 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3575 1330 20 VIETEL-AS-AP Viettel Group, VN 7713 3480 1022 56 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 3251 1896 54 VNPT-AS-VN VNPT Corp, VN 4766 2501 11119 579 KIXS-AS-KR Korea Telecom, KR 9498 2187 476 238 BBIL-AP BHARTI Airtel Ltd., IN 45090 2136 1198 75 TENCENT-NET-AP Shenzhen Tencent Compute 4755 2121 429 203 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 6009 10029 2575 AMAZON-02, US 11492 4593 304 819 CABLEONE, US 22773 4016 3046 371 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3950 264 30 VIASAT-SP-BACKBONE, US 16625 3677 1896 2557 AKAMAI-AS, US 6327 3390 1318 64 SHAW, CA 749 2890 50784 2146 DNIC-AS-00749, US 30036 2604 374 129 MEDIACOM-ENTERPRISE-BUSINESS, US 209 2525 5043 435 CENTURYLINK-US-LEGACY-QWEST, US 20115 2236 3032 502 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 6855 1733 150 UNI2-AS, ES 20940 3872 3348 209 AKAMAI-ASN1, NL 8551 3453 378 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 39891 3271 187 23 ALJAWWALSTC-AS, SA 12389 2935 2279 899 ROSTELECOM-AS, RU 9009 2568 264 1347 M247, GB 34984 2204 355 598 TELLCOM-AS, TR 58224 1753 917 576 TCI, IR 61317 1654 215 932 ASDETUK www.heficed.com, GB 13188 1610 100 27 TRIOLAN, UA 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 10498 3450 583 Uninet S.A. de C.V., MX 10620 3252 491 832 Telmex Colombia S.A., CO 11830 2469 369 62 Instituto Costarricense de Electricidad 13999 1617 284 456 Mega Cable, S.A. de C.V., MX 6503 1434 354 521 Axtel, S.A.B. de C.V., MX 28573 1396 2317 261 CLARO S.A., BR 3816 1240 651 153 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 26615 1145 2351 141 TIM SA, BR 6147 1089 370 21 Telefonica del Peru S.A.A., PE 11664 981 189 442 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 1625 393 21 LINKdotNET-AS, EG 24835 1549 499 32 RAYA-AS, EG 36992 1287 1430 268 ETISALAT-MISR, EG 36903 1195 543 114 MT-MPLS, MA 29571 821 68 11 ORANGE-COTE-IVOIRE, CI 36935 704 523 44 Vodafone-, EG 6713 612 1863 34 IAM-AS, MA 15399 517 50 31 WANANCHI-, KE 37342 470 32 1 MOVITEL, MZ 23889 428 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 10498 3450 583 Uninet S.A. de C.V., MX 9808 8752 9000 57 CHINAMOBILE-CN China Mobile Communicati 12479 6855 1733 150 UNI2-AS, ES 16509 6009 10029 2575 AMAZON-02, US 7545 5859 787 681 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4670 4192 74 ERX-CERNET-BKB China Education and Rese 11492 4593 304 819 CABLEONE, US 22773 4016 3046 371 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3950 264 30 VIASAT-SP-BACKBONE, US 20940 3872 3348 209 AKAMAI-ASN1, NL Complete listing at https://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 9808 8752 8695 CHINAMOBILE-CN China Mobile Communications Grou 12479 6855 6705 UNI2-AS, ES 7545 5859 5178 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4670 4596 ERX-CERNET-BKB China Education and Research Net 7155 3950 3920 VIASAT-SP-BACKBONE, US 11492 4593 3774 CABLEONE, US 20940 3872 3663 AKAMAI-ASN1, NL 22773 4016 3645 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3575 3555 VIETEL-AS-AP Viettel Group, VN 16509 6009 3434 AMAZON-02, US 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 46990 UNALLOCATED 8.5.242.0/23 3356 LEVEL3, 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 174 COGENT-174, US 54338 UNALLOCATED 8.33.241.0/24 6461 ZAYO-6461, US 1782 UNALLOCATED 8.42.19.0/24 46887 LIGHTOWER, 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 private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at https://thyme.apnic.net/current/data-dsua 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 23.252.160.0/24 Origin: 398968 GROUP-IID-01, US 23.252.160.0/24 Transit: 1299 TWELVE99 Twelve99, Telia Carrier, SE 23.252.161.0/24 Origin: 398968 GROUP-IID-01, US 23.252.161.0/24 Transit: 1299 TWELVE99 Twelve99, Telia Carrier, SE 23.252.162.0/24 Origin: 398968 GROUP-IID-01, US 23.252.162.0/24 Transit: 1299 TWELVE99 Twelve99, Telia Carrier, SE 23.252.163.0/24 Origin: 398968 GROUP-IID-01, US 23.252.163.0/24 Transit: 1299 TWELVE99 Twelve99, Telia Carrier, SE 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:41 /11:101 /12:305 /13:596 /14:1213 /15:2044 /16:13546 /17:8288 /18:13917 /19:25220 /20:43065 /21:50996 /22:107561 /23:93845 /24:510449 /25:790 /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 12479 5786 6855 UNI2-AS, ES 8151 4324 10498 Uninet S.A. de C.V., MX 11492 3546 4593 CABLEONE, US 6327 3199 3390 SHAW, CA 7155 3040 3950 VIASAT-SP-BACKBONE, US 22773 2994 4016 ASN-CXA-ALL-CCI-22773-RDC, US 8551 2918 3453 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 39891 2807 3271 ALJAWWALSTC-AS, SA 30036 2259 2604 MEDIACOM-ENTERPRISE-BUSINESS, US 11830 1924 2469 Instituto Costarricense de Electricidad y Telec Complete listing at https://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1912 2:1022 3:147 4:18 5:3709 6:100 7:5 8:1556 9:1 11:172 12:1706 13:407 14:2301 15:133 16:32 17:374 18:130 20:142 21:4 22:188 23:5325 24:2372 25:4 27:2552 29:19 31:2374 32:106 34:1 35:48 36:1726 37:3918 38:2381 39:659 40:149 41:3870 42:1041 43:2081 44:294 45:15643 46:3697 47:321 49:1661 50:1885 51:104 52:1343 54:290 55:725 56:4 57:55 58:1747 59:1130 60:940 61:2246 62:2395 63:1956 64:5402 65:2349 66:4914 67:2903 68:1184 69:4147 70:1343 71:676 72:3097 74:2613 75:1502 76:710 77:2137 78:1752 79:2706 80:1878 81:1489 82:1420 83:1176 84:1302 85:2819 86:700 87:1886 88:978 89:3117 90:478 91:7486 92:1886 93:2584 94:3219 95:3604 96:1301 97:342 98:985 99:899 100:76 101:1052 102:1814 103:27485 104:4078 105:429 106:844 107:2383 108:754 109:4003 110:2067 111:3140 112:1965 113:1519 114:1541 115:1939 116:1888 117:2467 118:2303 119:1844 120:1614 121:1042 122:2547 123:2136 124:1600 125:2047 128:1377 129:1114 130:915 131:2074 132:752 133:364 134:1919 135:287 136:792 137:861 138:2445 139:1206 140:814 141:1318 142:1231 143:1372 144:1256 145:330 146:1706 147:1465 148:2222 149:1579 150:852 151:1066 152:1655 153:443 154:3367 155:1352 156:1840 157:1197 158:987 159:2016 160:2329 161:1272 162:3408 163:1178 164:1658 165:1505 166:615 167:1662 168:3638 169:681 170:4309 171:807 172:2858 173:3052 174:1007 175:1143 176:3428 177:4489 178:3003 179:1951 180:2264 181:2656 182:3159 183:1925 184:2412 185:19066 186:4250 187:3515 188:3500 189:3086 190:8739 191:1333 192:11021 193:8460 194:6888 195:4957 196:2924 197:2354 198:6011 199:6005 200:7405 201:5547 202:10485 203:10020 204:4509 205:3371 206:3856 207:3361 208:4008 209:4633 210:4217 211:2416 212:3877 213:3406 214:1161 215:62 216:6394 217:2603 218:1214 219:621 220:1955 221:985 222:850 223:2119 End of report

1 0

Linode and/or Google Fiber contacts?
by Chris Adams 02 Dec '21

02 Dec '21

Anybody here from Linode and/or Google Fiber that can help out with packet loss between these networks at NYIIX peering? It's been going on for almost a week... opened a Linode case and they looked at the VM host, also opened a Google Fiber case and got zero response (don't think front-line support on either side is really getting it). I can MTR in each direction and the path appears symmetric, through NYIIX peering IPs (on both v4 and v6), and each sees packet loss at the first hop into the other network. I'm guessing one side or the other is having errors or has a congested port, but the regular support channels aren't getting this to the right people. Off-list contact is fine. -- Chris Adams <cma(a)cmadams.net>

1 1

Upcoming Webinar + More - VIDEO | New Ep. of Internet Innovators
by Nanog News 02 Dec '21

02 Dec '21

*Upcoming Webinar: Mark the Date * *Register TODAY for Network Automation Panel Discussion! * *Date + Time: *December 10, 11am - 12pm PDT / 2pm - 3pm EDT *Agenda: * Purpose of Network Automation Panel Discussion: Advantages/Challenges of Network Automation How to Prepare for a Career in Network Automation *Moderator:* Kat Ronay, Network Acquisition Specialist, Microsoft *Panelists:* Michael Costello, Director of Engineering, Netflix Ying Zhang, Senior Engineering Manager, Facebook Matt Turner Network Manager, Qualcomm, Inc. Zoe Blevins, Senior Software Engineer, Netflix *REGISTER NOW <https://www.nanog.org/events/webinar-network-automation-panel-discussion/>* *Watch Ep.3 of "Internet Innovators" * *Internet Pioneer Scott Bradner joins NANOG for a candid conversation* Internet Pioneer Scott Bradner has been involved in the design, operation, and use of data networks at Harvard University since the early days of the ARPANET. He is additionally a senior figure in the area of Internet governance. Join us for an open conversation as NANOG producer Elizabeth Drolet talks to Bradner about his own historic evolution with the Internet, what he thinks "the real power of the Internet" is + why he thinks the Internet cannot continue to exist in it's current state. *WATCH NOW <https://www.nanog.org/news-stories/nanog-tv/internet-innovators/scott-bradn…>* *Ready for NANOG 84? * We can't be more excited about our next in-person + virtual meeting, NANOG 84! The meeting will take place February 14-16 in Austin, Texas. Mark your calendars now + stay tuned for details regarding registration and presentation submissions! *"Notes from NANOG 83" * *Internet Pioneer Geoff Huston Recaps our Last Meeting* Digital pioneer + chief scientist at APNIC Geoff Huston was a virtual attendee at our most recent hybrid NANOG 83 meeting. In typical Huston manner (and lucky for us) he had much to say about it. Here are notes from talks that sparked Huston’s interest, pulled from his blog post, “Notes from NANOG 83.” Feel free to compare your own notes or soak up some new perspective. *READ MORE * <https://www.nanog.org/stories/top-takeaways-from-nanog-83-by-geoff-huston/>

1 0

IMPORTANT - Fwd: [arin-announce] Retirement of ARIN Non-Authenticated IRR on 31 March 2022
by John Curran 01 Dec '21

01 Dec '21

Network Operators - Please read and take note that ARIN’s Non-Authenticated IRR service will be retired on 31 March 2022. FYI, /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] Retirement of ARIN Non-Authenticated IRR on 31 March 2022 Date: 1 December 2021 at 8:32:30 AM EST To: arin-announce <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> ARIN has been engaged in a multi-year project to create and deploy a new and improved Internet Routing Registry (IRR). As a result of these efforts, ARIN now provides users with the ability to create, update, and delete objects in ARIN’s authenticated IRR database using ARIN Online or ARIN’s RESTful API. Unfortunately, use of ARIN’s previous non-authenticated email-based IRR service actually increased after ARIN released its authenticated IRR, in opposition to the outcome ARIN anticipated when improving its IRR. On 8 February 2021, ARIN held a consultation to solicit input on the retirement of ARIN’s non-authenticated email-based IRR service. This retirement was originally scheduled for 30 September 2021. Based on community input, the proposed date for the ARIN-NONAUTH retirement was delayed to 31 March 2022 to allow more transition time for users. We also notified by email Points of Contact (POCs) of organizations who have objects in the ARIN-NONAUTH database of the retirement date and offered them our assistance with the transition. This announcement serves as a reminder that ARIN will retire its ARIN-NONAUTH IRR database on 31 March 2022. After this date, users will no longer be able to create, update, or delete records in the ARIN-NONAUTH database, and the ARIN-NONAUTH data stream will no longer be available in Near Real Time Mirroring (NRTM) or via FTP or Whois Port 43. If you have questions about this transition or need assistance, you can contact us by: - submitting an Ask ARIN ticket or chat with us using your ARIN Online account - emailing the Routing Security Team at mailto:routing.security@arin.net - contacting the Registration Services Help Desk by phone Monday through Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660 Regards, Brad Gorman Senior Product Owner, Routing Security American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues.

1 0

Theorical question about cyclic dependency in IRR filtering
by Anurag Bhatia 30 Nov '21

30 Nov '21

Hello everyone, While discussing IRR on some groups recently, I was thinking if there can be (and if there is) cycling dependency in filtering where IRR (run by whoever APNIC, RIPE, RADB etc) uses some upstream and accepts only routes with existing & valid route object. So hypothetical case (can apply to any IRR): 1. APNIC registry source is whois.apnic.net and points to 202.12.28.136 / 2001:dc0:1:0:4777::136. The aggregate of both these has a valid route object at the APNIC registry itself. 2. Their upstreams say AS X, Y and Z have tooling in place to generate and push filters by checking all popular IRRs. All is well till this point. 3. Say APNIC has some server/service issue for a few mins and X Y and Z are updating their filters at the same time. They cannot contact whois.apnic.net and hence miss generating filters for all APNIC IRR hosted prefixes. 4. X, Y and Z drop APNIC prefixes including those of IRR & the loop goes on from this point onwards. So my question is: Can that actually happen? If not, do X, Y and Z and possible all upstreams till default-free zone treat these prefixes in a special manner to avoid such loop in resolution? Thanks! -- Anurag Bhatia anuragbhatia.com

5 5

Redploying most of 127/8 as unicast public
by Jay R. Ashworth 29 Nov '21

29 Nov '21

This seems like a really bad idea to me; am I really the only one who noticed? https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html That's over a week old and I don't see 3000 comments on it, so maybe it's just me. So many things are just me. [ Hat tip to Lauren Weinstein, whom I stole it from ] Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

48 145

IPv6 and CDN's
by Marco Davids 29 Nov '21

29 Nov '21

Hi! We currently live in times where is actually fun to go IPv6-only. In my case, as in: running a FreeBSD kernel compiled without the IPv4-stack. A few years back doing such thing was mostly disappointing, but nowadays is actually quite doable and entertaining. So, the other day I decided to take this experiment to the next level by disconnecting my local resolver from IPv4 as well. Then things started to break. LinkedIn, Bing, Openstreetmap... Although they all work great on IPv6-only, now they no longer did. It turns out that there underlying CDN's with domain names such as ‘l-msedge.net’ and ‘trafficmanager.net’ (Microsoft) or 'fastly.net', that reside on authoritative name servers that *only* have an IPv4 address. I guess my question is simple: Why? Are there good architectural reason for this? Or is it just something that is overlooked and forgotten about? I would love to find out! Thank you. -- Marco This is also fun by the way. Look at that nice banner on https://clintonwhitehouse2.archives.gov/ :-)

40 129

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast
by John Gilmore 27 Nov '21

27 Nov '21

Steven Bakker <steven.bakker(a)ams-ix.net> wrote: > The ask is to update every ip stack in the world (including validation, > equipment retirement, reconfiguration, etc)... This raises a great question. Is it even *doable*? What's the *risk*? What will it *cost* to upgrade every node on the Internet? And *how long* might it take? We succeeded in upgrading every end-node and every router in the Internet in the late '90s and early 2000's, when we deployed CIDR. It was doable. We know that because we did it! (And if we hadn't done it, the Internet would not have scaled to world scale.) So today if we decide that unicast use of the 268 million addresses in 240/4 is worth doing, we can upgrade every node. If we do, we might as well support unicast on the other 16 million addresses in 0/8, and the 16 million in 127/8, and the other about 16 million reserved for 4.2BSD's pre-standardized subnet broadcast address that nobody has used since 1985. And take a hard look at another hundred million addresses in the vast empty multicast space, that have never been assigned by IANA for anybody or anything. Adding the address blocks around the edges makes sense; you only have to upgrade everything once, but the 268 million addresses becomes closer to 400 million formerly wasted addresses. That would be worth half again as much to end users, compared to just doing 240/4! That may not be worth it to you. Or to your friends. But it would be useful to a lot of people -- hundreds of millions of people who you may never know. People who didn't get IP addresses when they were free, people outside the US and Europe, who will be able to buy and use them in 5 or 10 years, rather than leaving them unused and rotting on the vine. We already know that making these one-line patches is almost risk-free. 240/4 unicast support is in billions of nodes already, without trouble. Linux, Android, MacOS, iOS, and Solaris all started supporting unicast use of 240/4 in 2008! Most people -- even most people in NANOG -- didn't even notice. 0/8 unicast has been in Linux and Android kernels for multiple years, again with no problems. Unicast use of the lowest address in each subnet is now in Linux and NetBSD, recently (see the drafts for specifics). If anyone knows of security issues that we haven't addressed in the drafts, please tell us the details! There has been some arm-waving about a need to update firewalls, but most of these addresses have been usable as unicast on LANs and private networks for more than a decade, and nobody's reported any firewall vulnerabilities to CERT. Given the low risk, the natural way for these unicast extensions to roll out is to simply include them in new releases of the various operating systems and router OS's that implement the Internet protocols. It is already happening, we're just asking that the process be adopted universally, which is why we wrote Internet-Drafts for IETF. Microsoft Windows is the biggest laggard; they drop any packet whose destination OR SOURCE address is in 240/4. When standards said 240/4 was reserved for what might become future arcane (variable-length, anycast, 6to4, etc) addressing modes, that made sense. It doesn't make sense in 2021. IPv4 is stable and won't be inventing any new addressing modes. The future is here, and all it wants out of 240/4 is more unicast addresses. By following the normal OS upgrade path, the cost of upgrading is almost zero. People naturally upgrade their OS's every few years. They replace their server or laptop with a more capable one that has the latest OS. Laggards might take 5 or 10 years. Peoples' home WiFi routers break, or are upgraded to faster models, or they change ISPs and throw the old one out, every 3 to 5 years. A huge proportion of end-users get automatic over-the-net upgrades, via an infrastructure that had not yet been built for consumers during the CIDR transition. "Patch Tuesday" could put some or all of these extensions into billions of systems at scale, for a one-time fixed engineering and testing cost. We have tested major routers, and none so far require software updates to enable most of these addresses (except on the lowest address per subnet). At worst, the ISP would have to turn off or reconfigure a bogon filter with a config setting. Also, many "Martian address" bogon lists are centrally maintained (e.g. https://team-cymru.com/community-services/bogon-reference/ ) and can easily be updated. We have found no ASIC IP implementations that hardwire in assumptions about specific IP address ranges. If you know of any, please let us know, otherwise, let's let that strawman rest. Our drafts don't propose to choose between public and private use of the newly usable unicast addresses (so the prior subject line that said "unicast public" was incorrect). Since the kernel and router implementation is the same in either case, we're trying to get those fixed first. There will be plenty of years and plenty of forums (NANOG, IETF, ICANN, IANA, and the RIRs) in which to wrestle the public-vs-private questions to the ground and make community decisions on actual allocations. But if we don't fix the kernels and routers first, none of those decisions would be implementable. Finally, as suggested by David Conrad, there is a well understood process for "de-bogonizing" an address range on the global Internet, once support for it exists in OS's. Cloudflare used it on 1.1.1.1; RIPE used it on 128.0/16 and on 2a10::/12. You introduce a global BGP route for some part of the range, stand up a server on it, and use various distributed measurement testbeds to see who can reach that server. When chunks of the Internet can't, an engineer figures out where the blockage is, and communicates with that ISP or vendor to resolve the issue. Lather, rinse and repeat for a year or more, until reachability is "high enough". Addresses that later end up allocated to private address blocks would never need 100% global reachability, but global testing would still help to locate low-volume OS implementations that might need to be updated. Addresses bought to number retail cellphones need not be as reachable as ones used on public-facing servers, etc. The beauty of a market for IP addresses, rather than one-size-fits-all allocation models, is that ones with different reachability can sell for different prices, at different times, into different niches where they can be put to use. John

23 40