- db-wg - mailman.ripe.net

"status:" attribute values in the RIPE database
by Edward Shryane 30 Aug '21

30 Aug '21

Dear colleagues, In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that resource "status:" attribute values may not always be all UPPERCASE. This is because the RIPE database is case-insensitive and case preserving in general, meaning a "status:" attribute value is the same regardless of the case. However, this may make parsing this value more difficult as the case should be ignored. Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency? Regards Ed Shryane RIPE NCC

13 24

Bogon Route object update
by Ronald F. Guilmette 26 Aug '21

26 Aug '21

NONAUTH / IPv4: 41.217.128.0/19 37034 2018-09-04 41.217.144.0/20 37034 2018-09-04 41.217.144.0/21 37034 2018-09-04 41.242.128.0/22 327933 2018-09-04 41.242.129.0/24 327933 2018-09-04 41.242.131.0/24 327933 2018-09-04 107.168.204.0/24 47447 2018-09-04 192.31.196.0/24 112 2018-09-04 192.88.99.0/24 1101 2018-09-04 192.88.99.0/24 12816 2018-09-04 192.88.99.0/24 12871 2018-09-04 192.88.99.0/24 15598 2021-02-25 192.88.99.0/24 1741 2018-09-04 192.88.99.0/24 1835 2018-09-04 192.88.99.0/24 20640 2018-09-04 192.88.99.0/24 21416 2018-09-04 192.88.99.0/24 25192 2018-09-04 192.88.99.0/24 25308 2018-09-04 192.88.99.0/24 2847 2018-09-04 192.88.99.0/24 29076 2018-09-04 192.88.99.0/24 29259 2018-09-04 192.88.99.0/24 29432 2018-09-04 192.88.99.0/24 29632 2018-09-04 192.88.99.0/24 3243 2018-09-04 192.88.99.0/24 3344 2018-09-04 192.88.99.0/24 35244 2018-09-04 192.88.99.0/24 39326 2018-09-04 192.88.99.0/24 43097 2018-09-04 192.88.99.0/24 50113 2018-09-04 192.88.99.0/24 5408 2018-09-04 192.88.99.0/24 5413 2018-09-04 192.88.99.0/24 680 2018-09-04 192.88.99.0/24 8473 2018-09-04 192.88.99.0/24 8903 2020-11-18 NONAUTH / IPv6: 2001::/32 1101 2018-09-04 2001::/32 12816 2018-09-04 2001::/32 12871 2018-09-04 2001::/32 1741 2018-09-04 2001::/32 21155 2018-09-04 2001::/32 25192 2018-09-04 2001::/32 25308 2018-09-04 2001::/32 25525 2018-09-04 2001::/32 29259 2018-09-04 2001::/32 29432 2018-09-04 2001::/32 44980 2018-09-04 2001::/32 57801 2018-09-04 2001:4:112::/48 112 2018-09-04 2002::/16 1101 2018-09-04 2002::/16 12871 2018-09-04 2002::/16 15598 2021-02-23 2002::/16 1741 2018-09-04 2002::/16 1835 2018-09-04 2002::/16 20640 2018-09-04 2002::/16 21416 2018-09-04 2002::/16 25192 2018-09-04 2002::/16 25308 2018-09-04 2002::/16 2847 2018-09-04 2002::/16 29259 2018-09-04 2002::/16 29432 2018-09-04 2002::/16 29632 2018-09-04 2002::/16 3344 2018-09-04 2002::/16 35244 2018-09-04 2002::/16 39326 2018-09-04 2002::/16 43097 2018-09-04 2002::/16 5413 2018-09-04 2002::/16 559 2018-09-04 2002::/16 680 2018-09-04 2002::/16 8473 2018-09-04 2002::/16 8903 2018-09-04 2011:4188::/48 12880 2018-09-04

2 1

Historical queries
by denis walker 20 Aug '21

20 Aug '21

Colleagues At RIPE 82 during the NWI review, the chairs recommended two changes to the way historical queries for operational data work: 1/ Drop arbitrary restriction of most recent deletion point of re-created objects 2/ Allow access to history of deleted objects that have not been re-created These recommendations are based on positive comments made by the community in recent years. The restrictions were arbitrary at the time historical queries were implemented in the absence of any hard requirements. So if no one objects the chairs will ask the RIPE NCC to do an impact analysis on these changes. cheers denis co-chair DB-WG

2 1

Corrected LIR Organisation "address:" Attribute Values
by Edward Shryane 18 Aug '21

18 Aug '21

Dear Colleagues, Today, Wednesday 18th August, the RIPE NCC updated the "address:" attributes on 1,141 LIR organisation objects. A bug was introduced in a synchronisation script that copied LIR contact details from an internal registry to the RIPE database, which caused the "address:" attributes to be reversed. This bug is fixed, and we have now corrected the affected organisation objects. The maintainers of these organisation objects were notified by email. If you have any questions, please let me know. Regards Ed Shryane RIPE NCC

1 0

Smallest IPv4 allocation size (in the RIPE region)?
by Ronald F. Guilmette 18 Aug '21

18 Aug '21

As I understand it, IPv4 route announcement smaller than a /24 do not propagate very well, if at all. I have thus been surprised to see the following blocks listed separately as "allocated" in the daily "stats" file for RIPE. Can anyone explain to me why these small IPv4 blocks are listed in there separately? (Note: I have found no such small blocks in the daily stats files for any of the other four Regional Internet Registries... only RIPE seems to have such things.) 91.227.79.0/25 ripe 91.227.79.128/25 ripe 156.67.6.0/29 ripe 156.67.6.8/29 ripe 156.67.6.16/29 ripe 156.67.6.24/29 ripe 156.67.6.32/29 ripe 156.67.6.40/29 ripe 156.67.6.48/28 ripe 156.67.6.64/26 ripe 156.67.6.128/25 ripe 185.30.232.0/26 ripe 185.30.232.64/26 ripe 185.30.232.128/25 ripe 193.34.192.0/25 ripe 193.34.192.128/25 ripe 193.34.193.0/25 ripe 193.34.195.0/25 ripe 193.34.195.128/25 ripe 193.34.196.0/25 ripe 193.34.197.0/25 ripe 193.34.197.128/25 ripe 193.34.198.0/25 ripe 193.34.198.128/25 ripe 193.34.199.0/25 ripe 193.34.200.0/25 ripe 193.34.200.128/25 ripe 193.34.203.0/25 ripe 193.34.203.128/25 ripe 193.43.0.0/26 ripe 193.43.0.64/27 ripe 193.43.0.96/27 ripe 193.43.0.128/25 ripe 193.58.0.0/27 ripe 193.58.0.32/28 ripe 193.58.0.56/29 ripe 193.58.0.64/26 ripe 193.58.0.128/25 ripe 193.164.232.0/26 ripe 193.164.232.64/27 ripe 193.164.232.160/27 ripe 193.164.232.192/27 ripe 193.188.134.0/26 ripe 193.188.134.64/27 ripe 193.188.134.96/28 ripe 193.188.134.112/29 ripe 193.188.134.120/29 ripe 193.188.134.128/29 ripe 193.188.134.144/28 ripe 193.188.134.160/29 ripe 193.188.134.168/29 ripe 193.188.134.176/28 ripe 193.188.134.192/29 ripe 193.192.12.128/25 ripe 193.201.144.0/25 ripe 193.201.144.128/25 ripe 193.201.145.0/25 ripe 193.201.146.0/25 ripe 193.201.146.128/25 ripe 193.201.147.0/26 ripe 193.201.147.64/27 ripe 193.201.147.96/27 ripe 193.201.147.128/27 ripe 193.201.147.160/27 ripe 193.201.147.224/27 ripe 193.201.148.0/26 ripe 193.201.148.64/26 ripe 193.201.148.192/26 ripe 193.201.149.64/26 ripe 193.201.149.192/26 ripe 193.201.150.0/26 ripe 193.201.150.64/26 ripe 193.201.150.128/26 ripe 193.201.151.0/26 ripe 193.201.151.192/26 ripe 193.201.152.0/25 ripe 193.201.152.128/25 ripe 193.201.154.0/25 ripe 193.201.154.128/25 ripe 193.201.155.128/25 ripe 193.201.156.0/25 ripe 193.201.156.128/25 ripe 193.201.157.0/25 ripe 193.201.159.128/25 ripe 193.218.205.0/26 ripe 193.218.205.64/26 ripe 193.218.205.128/26 ripe 193.218.205.192/27 ripe 193.218.207.0/28 ripe 193.218.207.16/28 ripe 193.218.207.32/27 ripe 193.218.207.80/28 ripe 193.218.207.96/27 ripe 193.218.207.128/25 ripe 193.243.183.64/26 ripe 193.243.183.192/26 ripe 193.254.23.0/25 ripe 193.254.23.128/25 ripe 194.42.47.128/25 ripe 194.42.55.0/27 ripe 194.42.55.32/27 ripe 194.42.55.64/26 ripe 194.42.55.128/27 ripe 194.42.55.160/27 ripe 194.42.55.192/27 ripe 194.42.55.224/27 ripe 194.55.1.0/25 ripe 194.55.1.128/25 ripe 194.93.123.128/25 ripe 194.117.50.128/25 ripe 194.117.52.0/25 ripe 194.117.53.128/25 ripe 194.117.54.0/25 ripe 194.117.54.128/25 ripe 194.117.55.128/25 ripe 194.153.152.0/25 ripe 194.153.152.128/25 ripe 194.153.153.128/25 ripe 194.153.154.0/25 ripe 194.153.154.128/25 ripe 194.153.156.0/26 ripe 194.153.156.64/26 ripe 194.153.156.128/25 ripe 194.153.157.128/27 ripe 194.153.157.160/27 ripe 194.153.157.192/26 ripe 194.153.158.128/25 ripe 194.153.159.0/26 ripe 194.153.159.64/26 ripe 194.153.215.0/25 ripe 194.153.215.128/25 ripe 194.180.159.240/28 ripe 194.180.226.152/29 ripe 194.246.39.96/27 ripe 194.246.39.128/26 ripe 194.246.39.224/27 ripe 195.13.37.0/25 ripe 195.13.46.0/25 ripe 195.13.46.128/25 ripe 195.35.104.32/27 ripe 195.35.104.64/26 ripe 195.35.104.128/25 ripe 195.60.80.96/27 ripe 195.60.80.128/27 ripe 195.60.80.160/27 ripe 195.60.80.192/27 ripe 195.60.80.224/27 ripe 195.60.81.0/26 ripe 195.60.81.64/26 ripe 195.60.81.192/26 ripe 195.60.82.0/26 ripe 195.60.82.64/26 ripe 195.60.82.128/26 ripe 195.60.82.192/26 ripe 195.60.83.0/27 ripe 195.60.83.64/27 ripe 195.60.83.96/27 ripe 195.60.83.160/27 ripe 195.60.83.192/27 ripe 195.60.83.224/27 ripe 195.60.84.0/25 ripe 195.60.85.0/25 ripe 195.60.87.0/25 ripe 195.60.87.128/25 ripe 195.60.89.0/25 ripe 195.60.89.128/25 ripe 195.60.90.0/25 ripe 195.60.90.128/25 ripe 195.60.91.0/25 ripe 195.60.92.0/26 ripe 195.60.92.64/26 ripe 195.60.92.128/26 ripe 195.60.93.0/26 ripe 195.60.93.128/26 ripe 195.60.93.192/26 ripe 195.60.95.0/25 ripe 195.60.95.128/25 ripe

4 5

Update: Bogon Route objects (part 2)
by Ronald F. Guilmette 06 Aug '21

06 Aug '21

There remain a number of route objects in the AUTH data base that refer to bogon AS numbers. I would like to suggest that at the very least these should be moved to NONAUTH, but preferably deleted altogether. Use of bogon AS numbers should neither be condoned nor assisted by any RIR. I mean what is the point of having RIRs if people are just going to use whatever numbers they want, willy nilly, and without formal assignments? Also, the overwhelming majority of these route objects do not correspond to active route announcements anyway, and thus deleting them would provably have -no- operational significance. Examples: https://bgp.he.net/AS198738 https://bgp.he.net/AS8295 https://bgp.he.net/AS36879 https://bgp.he.net/AS31419 https://bgp.he.net/AS46723 ... AUTH / IPv4 (80): ----------------- 5.1.112.0/24 198738 2012-05-16 5.1.113.0/24 198738 2012-05-16 5.160.196.0/24 62280 2014-05-10 5.160.197.0/24 62280 2014-05-10 5.160.240.0/24 62280 2014-11-02 5.160.241.0/24 62280 2014-11-02 45.8.92.0/24 397796 2020-06-11 45.8.92.0/24 46723 2020-06-11 45.8.93.0/24 46723 2020-05-26 45.8.94.0/24 397796 2020-05-26 45.8.94.0/24 46723 2020-05-26 45.8.95.0/24 397796 2020-05-26 45.8.95.0/24 46723 2020-05-26 45.14.212.0/22 2209013 2019-05-09 45.95.0.0/24 46723 2020-06-11 45.95.1.0/24 46723 2020-06-11 45.95.2.0/24 46723 2020-06-11 45.95.3.0/24 46723 2020-05-30 77.246.74.0/24 37631 2015-05-29 81.52.165.0/24 36879 2013-10-01 81.52.166.0/24 36879 2013-10-02 81.52.167.0/24 36879 2013-10-02 81.52.168.0/24 36879 2013-10-02 81.52.169.0/24 36879 2013-10-02 82.98.78.0/24 394935 2016-10-26 83.136.64.0/21 8871 2020-12-29 83.216.160.0/19 31419 2011-01-03 83.216.160.0/20 31419 2011-01-03 83.216.160.0/21 31419 2011-01-03 83.216.168.0/21 31419 2011-01-03 83.216.176.0/20 31419 2011-01-03 83.216.176.0/21 31419 2011-01-03 83.216.184.0/21 31419 2011-01-03 86.110.128.0/19 31419 2011-01-03 86.110.128.0/20 31419 2011-01-03 86.110.128.0/21 31419 2011-01-03 86.110.136.0/21 31419 2011-01-03 86.110.144.0/20 31419 2011-01-03 86.110.144.0/21 31419 2011-01-03 86.110.152.0/21 31419 2011-01-03 91.102.168.0/21 8295 2006-11-17 91.102.168.0/24 8295 2020-02-25 91.102.169.0/24 8295 2020-02-25 91.102.170.0/24 8295 2020-02-25 91.102.171.0/24 8295 2020-02-25 91.102.172.0/24 8295 2020-02-25 91.102.173.0/24 8295 2020-02-25 91.102.174.0/24 8295 2020-02-25 91.102.175.0/24 8295 2020-02-25 91.107.84.0/24 202532 2019-07-08 91.220.83.0/24 46414 2010-10-28 93.92.104.0/22 1975505 2018-12-12 141.98.12.0/24 208469 2020-03-25 158.255.59.0/24 203655 2015-11-27 185.18.88.0/23 196803 2019-09-18 185.48.220.0/22 199724 2014-03-05 185.62.220.0/22 1975505 2018-12-12 185.62.221.0/24 1975505 2018-12-12 185.106.44.0/24 200968 2015-06-29 185.148.136.0/22 198738 2019-07-08 185.148.138.0/23 198738 2016-09-12 185.164.160.0/22 14076 2016-11-02 185.194.4.0/22 205740 2020-04-05 185.200.32.0/22 33431 2017-06-13 185.225.136.0/22 33431 2017-10-13 185.244.144.0/22 204634 2018-02-02 185.250.112.0/22 20180320 2019-07-25 188.92.121.0/24 40178 2020-04-01 193.33.110.0/23 42796 2012-06-28 193.110.94.0/24 16712 2021-03-18 193.135.119.0/24 46723 2020-05-30 193.201.204.0/24 14880 2007-11-23 193.201.205.0/24 14880 2007-11-23 194.99.204.0/22 36895 2006-05-04 194.165.87.0/24 21389 2012-12-10 194.201.253.0/24 25568 2014-04-08 212.68.170.0/23 20873 2013-12-20 213.156.70.0/24 20873 2005-09-06 213.156.71.0/24 20873 2005-09-06 213.228.244.0/24 31453 2005-01-04 AUTH / IPv6 (19): ----------------- 2001:678:d44:100::/64 999998 2021-02-13 2001:678:d44:200::/64 999999 2021-02-13 2a00:9700:1::/48 47497 2017-01-14 2a00:e640::/32 198738 2012-04-26 2a01:9ba0::/32 199724 2014-03-05 2a03:1960::/32 201400 2017-07-24 2a03:9c00:f::/48 210323 2019-12-18 2a03:b600::/29 46723 2019-03-14 2a07:7e40:1::/48 34676 2020-07-28 2a09:be40:3620::/48 208577 2019-08-15 2a09:f700::/29 46723 2019-03-06 2a0a:7740::/48 46076 2020-10-30 2a0b:1040::/29 31005 2017-06-04 2a0b:3e00::/32 14076 2016-11-02 2a0b:4340:a0:3ec::/64 139734 2020-03-18 2a0d:1a40:faf::/48 138987 2020-06-13 2a0e:aa07:f030::/44 132352 2019-04-26 2a0e:b107:680::/48 140540 2020-04-02 2a10:cc46:100::/44 655312 2021-06-03

3 4

Update: Bogon Route objects
by Ronald F. Guilmette 05 Aug '21

05 Aug '21

It would appear that we may have acquired a few new bogon route objects within 41/8 which I believe is 100% AFRINIC space. I can only guess that this is most likely due to some fresh reclamations recently performed by AFRINIC. Note that I am still including the questionable routes relating to the 192.31.196.0/24 and 192.88.99.0/24 blocks which have been discussed here previously, as well as some of the IPv6 routes that some people have also suggested should fall into the "questionable" category. (If I could get some further clarity on RIPE NCC's official position on the questionable bits, that would be helpful.) NONAUTH / IPv4: --------------- 41.217.128.0/19 37034 2018-09-04 41.217.144.0/20 37034 2018-09-04 41.217.144.0/21 37034 2018-09-04 192.31.196.0/24 112 2018-09-04 192.88.99.0/24 1101 2018-09-04 192.88.99.0/24 12816 2018-09-04 192.88.99.0/24 12871 2018-09-04 192.88.99.0/24 15598 2021-02-25 192.88.99.0/24 1741 2018-09-04 192.88.99.0/24 1835 2018-09-04 192.88.99.0/24 20640 2018-09-04 192.88.99.0/24 21416 2018-09-04 192.88.99.0/24 25192 2018-09-04 192.88.99.0/24 25308 2018-09-04 192.88.99.0/24 2847 2018-09-04 192.88.99.0/24 29076 2018-09-04 192.88.99.0/24 29259 2018-09-04 192.88.99.0/24 29432 2018-09-04 192.88.99.0/24 29632 2018-09-04 192.88.99.0/24 3243 2018-09-04 192.88.99.0/24 3344 2018-09-04 192.88.99.0/24 35244 2018-09-04 192.88.99.0/24 39326 2018-09-04 192.88.99.0/24 43097 2018-09-04 192.88.99.0/24 50113 2018-09-04 192.88.99.0/24 5408 2018-09-04 192.88.99.0/24 5413 2018-09-04 192.88.99.0/24 680 2018-09-04 192.88.99.0/24 8473 2018-09-04 192.88.99.0/24 8903 2020-11-18 NONAUTH / IPv6: --------------- 2001::/32 1101 2018-09-04 2001::/32 12816 2018-09-04 2001::/32 12871 2018-09-04 2001::/32 1741 2018-09-04 2001::/32 21155 2018-09-04 2001::/32 25192 2018-09-04 2001::/32 25308 2018-09-04 2001::/32 25525 2018-09-04 2001::/32 29259 2018-09-04 2001::/32 29432 2018-09-04 2001::/32 44980 2018-09-04 2001::/32 57801 2018-09-04 2001:4:112::/48 112 2018-09-04 2002::/16 1101 2018-09-04 2002::/16 12871 2018-09-04 2002::/16 15598 2021-02-23 2002::/16 1741 2018-09-04 2002::/16 1835 2018-09-04 2002::/16 20640 2018-09-04 2002::/16 21416 2018-09-04 2002::/16 25192 2018-09-04 2002::/16 25308 2018-09-04 2002::/16 2847 2018-09-04 2002::/16 29259 2018-09-04 2002::/16 29432 2018-09-04 2002::/16 29632 2018-09-04 2002::/16 3344 2018-09-04 2002::/16 35244 2018-09-04 2002::/16 39326 2018-09-04 2002::/16 43097 2018-09-04 2002::/16 5413 2018-09-04 2002::/16 559 2018-09-04 2002::/16 680 2018-09-04 2002::/16 8473 2018-09-04 2002::/16 8903 2018-09-04 2011:4188::/48 12880 2018-09-04

2 1

Bogon cleanup -- Current anomalies
by Ronald F. Guilmette 24 Jul '21

24 Jul '21

According to information given to me by Edward Shryane <eshryane(a)ripe.net>, the cleanup of bogon route objects which made reference to bogon IP address space should have been completed the night before last. My latest analysis suggests that a few such route objects escaped the net and are still present within the NONAUTH data base. These route objects are summarized below. I'd appreciate it if others would take a look at these and tell me if they think that these route objects should or should not be present within the data base. Note that both batches of bogon routes given below are really rather curious due to the fact that nearly all of the routes have the exact same last-modified date (2018-09-04) and a great many of them refer either to the 192.88.99.0/24 IPv4 block, which is apparently reserved by RFC 3068, or to some IPv6 block which is *not* clearly related to RFC 3068. I am frankly not sure what to make of any of these, but I do suspect that they are all invalid, because no RIR has assigned any of the relevant IP space to any resource member. NONAUTH / IPv4 routes (36): --------------------------- 41.217.128.0/19 37034 2018-09-04 41.217.144.0/20 37034 2018-09-04 41.217.144.0/21 37034 2018-09-04 41.242.84.0/22 37609 2018-09-04 170.56.0.0/16 15854 2018-09-04 170.56.0.0/16 702 2018-09-04 192.31.196.0/24 112 2018-09-04 192.88.99.0/24 1741 2018-09-04 192.88.99.0/24 29259 2018-09-04 192.88.99.0/24 2847 2018-09-04 192.88.99.0/24 12816 2018-09-04 192.88.99.0/24 3344 2018-09-04 192.88.99.0/24 20640 2018-09-04 192.88.99.0/24 5408 2018-09-04 192.88.99.0/24 1835 2018-09-04 192.88.99.0/24 8473 2018-09-04 192.88.99.0/24 15598 2021-02-25 192.88.99.0/24 1101 2018-09-04 192.88.99.0/24 12871 2018-09-04 192.88.99.0/24 680 2018-09-04 192.88.99.0/24 25192 2018-09-04 192.88.99.0/24 35244 2018-09-04 192.88.99.0/24 39326 2018-09-04 192.88.99.0/24 5413 2018-09-04 192.88.99.0/24 25308 2018-09-04 192.88.99.0/24 3243 2018-09-04 192.88.99.0/24 29076 2018-09-04 192.88.99.0/24 29632 2018-09-04 192.88.99.0/24 8903 2020-11-18 192.88.99.0/24 21416 2018-09-04 192.88.99.0/24 43097 2018-09-04 192.88.99.0/24 29432 2018-09-04 192.88.99.0/24 50113 2018-09-04 192.107.242.0/24 394784 2018-09-04 204.144.127.0/24 40142 2018-09-04 205.166.145.0/24 394784 2018-09-04 NONAUTH / IPv6 routes (37): --------------------------- 2001::/32 1101 2018-09-04 2001::/32 12816 2018-09-04 2001::/32 12871 2018-09-04 2001::/32 1741 2018-09-04 2001::/32 21155 2018-09-04 2001::/32 25192 2018-09-04 2001::/32 25308 2018-09-04 2001::/32 25525 2018-09-04 2001::/32 29259 2018-09-04 2001::/32 29432 2018-09-04 2001::/32 44980 2018-09-04 2001::/32 57801 2018-09-04 2001:4:112::/48 112 2018-09-04 2002::/16 1101 2018-09-04 2002::/16 12871 2018-09-04 2002::/16 15598 2021-02-23 2002::/16 1741 2018-09-04 2002::/16 1835 2018-09-04 2002::/16 20640 2018-09-04 2002::/16 21416 2018-09-04 2002::/16 25192 2018-09-04 2002::/16 25308 2018-09-04 2002::/16 2847 2018-09-04 2002::/16 29259 2018-09-04 2002::/16 29432 2018-09-04 2002::/16 29632 2018-09-04 2002::/16 3344 2018-09-04 2002::/16 35244 2018-09-04 2002::/16 39326 2018-09-04 2002::/16 43097 2018-09-04 2002::/16 5413 2018-09-04 2002::/16 559 2018-09-04 2002::/16 680 2018-09-04 2002::/16 8473 2018-09-04 2002::/16 8903 2018-09-04 2011:4188::/48 12880 2018-09-04 2c0f:f260::/32 36924 2018-09-04

7 16

consensus on AS23456
by denis walker 13 Jul '21

13 Jul '21

Colleagues Whilst part of the discussion continues, there does seem to be a consensus on adding AS23456 to the reserved list maintained by the RIPE NCC. This would prevent anyone creating a ROUTE(6) object with AS23456 as the origin. The chairs also recognise the consensus to not delete or modify any set objects that reference AS23456. This is in line with past views not to purge set objects when an AUT-NUM object is deleted for any reason. The chairs therefore ask the RIPE NCC to add AS23456 to the RIPE Database reserved list. Regards William & denis co-chairs DB-WG

3 2

Re: [db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects
by Ronald F. Guilmette 13 Jul '21

13 Jul '21

Job Snijders <job(a)sobornost.net> wrote: >Should the database server software impose brittle restrictions >on that field? No, not worth the headache. I never suggested any changes to the data base software. I have merely suggested that *existing* route objects that make reference to bogon ASNs should be deleted from the data base, just as is already and currently being done in the case of those route objects that make reference to bogon IP space. The overwhelming majority of these "bogon-ASN" route objects are quite obviously leftovers that just never got cleaned up... some having languished unattended in the data base for as much as 20 years or more (and even some of the people who put those there originally are no doubt dead by now). We are in agreement in our (idealistic?) hops that someday RPKI will make all of these issues moot. By for today, there is no good reason not to remove the decades long accumulation of rust. It isn't doing anybody any good, and I fear it is an active enticement to mischief makers, of which the Internet has an over-supply these days. Regards, rfg

4 7