- db-wg - mailman.ripe.net

Re: [db-wg] running in whios-circles...?
by Lutz Donnerhacke 16 Sep '21

16 Sep '21

* Ronald F. Guilmette wrote: > Gert Doering <gert(a)space.net> wrote: > >Ideally, IANA should point to the final RIR right away. > > That would certainly be more helpful than the present state of affairs, > within which the IANA WHOIS server is not merely failing to give out > correct referrals, but is actually giving out demonstratably incorrect > referrals. > > Functionally and operationally, the portion of the IANA WHOIS service that > provides referrals for IP addresses is, at present, worse than useless > due to the innumerable incorrect referrals it provides. If IANA does not > wish to correct that, then they should at least configure the thing so that > it will stop providing *any* responses at all when queried about IP > addresses. Did you ever tried to correct wrong entries in the IANA whois? I did and the entries were fixed (within a period of about a year). It's certainly possible to have correct data in the IANA server. OTOH if the problem is serious enough, an IANA review can be triggered.

3 4

What do you think of our new UI?
by Edward Shryane 02 Sep '21

02 Sep '21

Dear colleagues, We have created a short survey to get your feedback and comments on the new user interface (UI) we have deployed across RIPE NCC’s services, including the RIPE DB website. We kindly ask you to take part in the survey and help us improve the user experience for you. You can access the survey at: https://www.surveymonkey.com/r/RIPENCCservicesUI The survey is anonymous and will remain open until 30 September 2021. Regards Ed Shryane RIPE NCC

3 3

"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

RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*
by Edward Shryane 08 Jul '21

08 Jul '21

Dear colleagues, The implementation of the cleanup of RIPE NONAUTH route(6) objects using unregistered space is now complete, we plan to deploy to production *today*. This means that the cleanup job will run for the first time tonight. * Each night, all RIPE NONAUTH route(6) objects with an unregistered prefix ("available" or "reserved" in delegated stats) are selected. * If a prefix remains unregistered for 1 week, notify the maintainers of any related route(6) objects. * The maintainer can ask to make an exception, not to delete a route(6) object. * Otherwise, after a further 2 weeks, delete the route(6) objects. See the solution definition for more details: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html Note for now, the AS origin status is *not* considered. Please discuss further whether this should be included. If you have any feedback, please let us know. Regards Ed Shryane RIPE NCC

9 31

Whois Release 1.101
by Edward Shryane 01 Jul '21

01 Jul '21

Dear Working Group, RIPE Database release 1.101 has been deployed to the Release Candidate environment. We plan to deploy to production on Thursday 1st July. This release includes the following main changes: * Switch RIPE database to UTC timezone (all timestamps will be in UTC and all timestamps specify the 'Z' timezone) * Display an error on NRTM if client is blocked by ACL limit (#812) * Added rewrite rules to embedded Jetty (#801) * RDAP nameserver queries always return Not Implemented (#811) * Updated dependencies *Additionally* some operational changes will also be made to the production environment on 1st July: * Remove support for TLS versions 1.0 and 1.1 on HTTPS connections * The IETF has formally deprecated these TLS versions, now only versions 1.2 and 1.3 are recommended. * Remove insecure TLS cipher algorithms * TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA * TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA * TLS_DHE_RSA_WITH_SEED_CBC_SHA * TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA * Remove HTTP redirects for whois.ripe.net and www.db.ripe.net * HTTP requests to these hosts will no longer redirect to https://apps.db.ripe.net but will return 400 Bad Request. * Remove HTTP redirects for the legacy Whois REST API * The legacy Whois REST API was retired in 2015, a temporary redirect to https://rest.db.ripe.net will be removed. * HTTP requests to the legacy API at http://apps.db.ripe.net/whois/lookup/ripe will return 400 Bad Request. Please check your Whois client in case you are affected by these changes. The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Removie ALL bogus route objects from BOTH data bases
by Ronald F. Guilmette 21 Jun '21

21 Jun '21

I guess I'll try this again, since I don't recall seeing either any ascent nor any pushback the last time I tried to raise this point here. Al long as those bogus route objects that refer to bogon IP address space are being removed from the data, why not also remove all of the equally bogus route objects that refer to bogon AS numbers? I hope that I'm not actually the only one who sees the wisdom in cleaning up the whole mess that currently exists in the RIPE data bases. There are, at present, on the order of about 80 or so bogus route objects in the "regular" data base that refer to bogon AS numbers, and there are, give or take, about 1,500 of such bogus route objects currently within the (separate) RIPE-NONAUTH data base. Is anyone passionately in favor of keeping all of this useless and potentially fraudlent or misleading garbage in the data base? If not, then why not clear it all out? I mean seriously, the RIRs data bases are *supposed* to be the definitive guides to who has what and who may use what. And yet RIPE is, in effect, tacitly -appproving- of the use of bogon AS numbers. So I need to ask: Why? Regards, rfg

1 0

Removal of bogon route objects
by Ronald F. Guilmette 15 Jun '21

15 Jun '21

Friends, As previously discussed, the decision was made awhile back to remove from the data base all RIPE-NONAUTH route objects which refer to currently unallocated IP space: https://www.ripe.net/ripe/mail/archives/db-wg/2021-May/006952.html In recent days I stumbled upon one such object that was still present in the data base. Upon seeing that object, I necessarily assumed that it was most likely not a "one off", and that it probably had siblings. In the spirit of trying to help out, and after a fair bit of fooling around on my part, I managed to concoct a rather simple method for finding all such bogon route objects that remain in the data base, and I wrote a small Perl script to do that exact thing. A copy of the script may be obtained here, for anyone who may be interested: https://pastebin.com/raw/LsvZ05tX Notes: *) The script assumes the presence of two external programs and their presence on the user's current $PATH, i.e. the widely used wget progarm, and also John Levine's version of a thing called grepcidr, sources for which may be obtained here: https://github.com/jrlevine/grepcidr3 *) The initial line of the script may have to be adjusted depending on the location, in the filesystem, of your local Perl interpreter. *) The script computes its results based upon the following two input data files, both of which are automagically fetched by the script using wget: https://www.nro.net/wp-content/uploads/delegated-stats/nro-extended-stats ftp://ftp.ripe.net/ripe/dbase/ripe-nonauth.db.gz (It is my understanding that each of these is updated on a daily basis.) *) The script DOES NOT verify that the entirety of any given RIPE-NONAUTH route object in fact refers to bogon space. Rather the script only checks to see whether or not the first IPv4 address of each current RIPE-NONAUTH route object does or does not refer to current bogon space. If it does, then the entire IPv4 CIDR of the route object is printed to stdout. *) Assuming that the script is installed as "ripebogonroutes" and in one's path, it may be invoked simply as: ripebogonroutes > bogon-route-cidrs *) At present there are 55,964 RIPE-NONAUTH objects in the data base. Of these, the first address of 857 of them refers to current bogon space. It is my fervent hope that the corresponding RIPE-NONAUTH route objects will be removed from the data base as soon as reasonably practical. Regards, rfg

6 18

RIPE-NONAUTH route object anomalies
by Ronald F. Guilmette 14 Jun '21

14 Jun '21

It appears that, by and large, the route objects currently present within the ripe-nonauth.db.gz file refer either to bogons (which I've already provided a list of) or else they refer to out-of-region IP address blocks. The latter group seems at least explainable. The former group I am hoping will disappear from the data base soon. Checking now however I find there are a very small number of anomalous route objects within the latest edition of the ripe-nonauth.db.gz file, i.e. ones that refer to in-region IP blocks: 192.124.252.0/22 192.70.0.0/17 192.76.32.0/21 192.108.160.0/20 I'm not sure how these should be made to go away, but I wish they would. They offend my personal sense of fastidiousness, and I don't like unexplainable mysteries. Note that the RIPE-NONAUTH route object 192.76.32.0/21 appears to have some counterpart route objects for sub-blocks of that /21 and these sub-blocks route objects are *not* marked as RIPE-NONAUTH, suggesting that there is no compelling reason for the 192.76.32.0/21 route object to be marked as RIPE-NONAUTH. The same sort of syndrome appears to apply also in the case of the 192.124.252.0/22 RIPE-NONAUTH route object, i.e. in this case also there appear to be valid non-RIPE-NONAUTH route objects in the data base for sub-blocks of 192.124.252.0/22, which begs the question: Why is the 192.124.252.0/22 markes as RIPE-NONAUTH? Regards, rfg

3 5

Issue creating new AS-SET
by Denis Fondras 09 Jun '21

09 Jun '21

Hi all, I am trying to add a new AS-SET but I get an error : as-set: Syntax error in AS201376:AS-MEMBERS:DIRECT Here is the object I try to create : AS-SET: AS201376:AS-MEMBERS:DIRECT members: AS60983 TECH-C: DF5400-RIPE ADMIN-C: DF5400-RIPE MNT-BY: AUVERNIX-MNT MNT-BY: DF39378-MNT SOURCE: RIPE AS201376:AS-MEMBERS already exists in the database. I cannot see what I do wrong here. Can anybody help ? Also I tried to do some tests on the test DB but I get a 404 error when clicking 'submit'. I don't know if it is me or a bug. Thank you in advance. -- Denis Fondras / Liopen

4 6

NWI-4 - role of status: field in multivalued status context - reprise
by Carsten Schiefner 08 Jun '21

08 Jun '21

Dear all - after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate: Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects. I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve the challenge to have an assignment that shall have the size of an allocation. In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives. All the best, -C.

6 7

Re: [db-wg] "status:" attribute values in the RIPE database
by Edward Shryane 07 Jun '21

07 Jun '21

Hi Carsten, > On 7 Jun 2021, at 12:57, Carsten Schiefner <carsten(a)schiefner.de> wrote: > > Ed & all - > > makes sense to me, too. > > However: Instead of forcing this on the creator/updater of an object - > how about the NCC to be as liberal as possible (John Postel's law, the > robustness principle) and to accept any case combination, e.g. "aSSigNED > pi", but very conservatively keep the attribute sored in the DB in > uppercase only? > I agree, apologies I wasn't clear, by force the "status:" attribute value to uppercase, I mean that the value should be automatically changed to all-uppercase, and we should still accept the value in any case. Also, we should perform a cleanup on currently inconsistent values (affecting less than 1% of total inetnum and inet6num objects). Regards Ed > ATB, > > -C. >

2 1

Restricting WHOIS searches to type: netname
by Ronald F. Guilmette 29 May '21

29 May '21

One of the helpful options provided by the RIPE WHOIS server is the --types option which provides a list of what specific object types a given set of query results may be restricted to. That list is as follows: inetnum inet6num as-block aut-num as-set route route6 route-set inet-rtr filter-set peering-set rtr-set domain poetic-form poem mntner irt key-cert organisation role person Can anyone explain to me why "netname" is not on the above list? I would like to be able to query the data base for "ABC" but restrict the query so that I only get back the records for the dozen or so IP blocks whose registrants have (unwisely?) elected to label their networks as "ABC", while NOT also getting back all 16 or so of the organisation objects whose org-name: field contains the substring "ABC", much less the numerous and additional person and role records whose person: and role: fields also and likewise contain the substring "ABC". If I can selectively query just for poems, is there some reason why netnames deserve less respect? And as long as we are on the subject, may I safely infer from the presence, in the data base, of a dozen different networks named "ABC" that no attempt has ever been made to insure uniqueness of netnames within the data base? Are netnames even restricted, as they seem to be, to having a form which is rather strikingly reminicent of actual unique data base handles, i.e. consisting of only alphanumerics and hyphens? Regards, rfg P.S. I do not mean to pick on RIPE specifically here. A quick check reveals that whois.apnic.net and whois.afrinic.net also fail to support selective querying for just netnames... although in those two cases selective quering for poems is also not an option... a sad fact that has left me rather entirely bereft, as I'm sure you can all imagine.

4 4

created: field value
by Ronald F. Guilmette 29 May '21

29 May '21

My apologies to all. I don't intend to be a complainer. I'm just trying to understand fully what's going on in the data base. I must say however that I am getting the impression that the value in the created: field for some (many?) inetnum objects may not be entirely reliable, or even entirely consistant with other available historical data. Example: inetnum: 138.201.0.0 - 138.201.255.255 netname: HETZNER-RZ-BLK-ERX4 descr: Server Block country: DE org: ORG-HOA1-RIPE admin-c: HOAC1-RIPE tech-c: HOAC1-RIPE status: LEGACY mnt-by: HOS-GUN mnt-lower: HOS-GUN mnt-routes: HOS-GUN mnt-domains: HOS-GUN created: 1970-01-01T00:00:00Z last-modified: 2019-12-04T13:10:40Z source: RIPE Given that 1970-01-01T00:00:00Z is rather well known to be the beginning of UNIX time (i.e. time: 0) I could not help but be a bit suspicious of the value in the created: field of the record shown above. A quick look at version #1 of the data base object for the 138.201.0.0/16 block suggests that a rather more appropriate value might have been something more like 2003-12-11T17:11:00Z ======================================================================== % Version 1 of object "138.201.0.0 - 138.201.255.255" % This version was a UPDATE operation on 2003-12-11 17:11 inetnum: 138.201.0.0 - 138.201.255.255 remarks: remarks: This inetnum has been transfered as part of the ERX. remarks: It was present in both the ARIN and RIPE databases, so remarks: the information from both databases has been merged. remarks: If you are the mntner of this object, please update it remarks: to reflect the correct information. remarks: remarks: Please see the information for this process: remarks: http://www.ripe.net/db/erx/erx-ip/network-138.html remarks: remarks: **** INFORMATION FROM ARIN OBJECT **** remarks: netname: NETCS-CUST4 descr: netCS Informationstechnik GmbH descr: Feuerbachstrasse 47/49 descr: D-1000 Berlin 41 remarks: country: DE remarks: changed: hostmaster(a)arin.net 19900523 remarks: changed: hostmaster(a)arin.net 20010220 remarks: **** INFORMATION FROM RIPE OBJECT **** netname: KIEZ-NET1 descr: Kiez-Net WAN country: DE rev-srv: DNS-A.Kiez.Net rev-srv: DNS-B.Kiez.Net status: ASSIGNED PI mnt-by: KIEZ-MNT source: RIPE # Filtered Am I the only one who thinks so? It is certainly my hope that the value in the created: field should accurately reflect the date & time when any given object was in fact created within the RIPE WHOIS data base. Is there any compelling reason why this should ever not be the case? Regards, rfg

4 5

BOGON => 103.86.68.0/22
by Ronald F. Guilmette 28 May '21

28 May '21

My apologies to all. My interests and attention are getting pulled in so many different directions these days that I tend to forget the answers to questions that I seem to vaguely remember having already asked. So, at the risk of repeating myself, what's the current policy on stale route objects in the data base that refer to current bogon address space? I'm specifically interested in 103.86.68.0/22 at the moment. route: 103.86.68.0/22 origin: AS131477 mnt-by: HUAJUAN-MJJ-MNT created: 2018-02-24T19:00:10Z last-modified: 2018-09-04T19:09:05Z source: RIPE-NONAUTH

4 7

status: LEGACY -- Stranger and stranger
by Ronald F. Guilmette 28 May '21

28 May '21

Regarding one of the "LEGACY" blocks mentioned in my prior email, on a whim I decided to take a look at the full history of the block. That full history is reproduced below. This history causes me to have even more questions than I have already asked. I'm still totally befuddled by the fact that this block apparently is and always was marked as "status: LEGACY", even though it's original allocation date still seems to be 2015-09-23, which seems relatively recent to me. Just as perplexing is the apparent direct transfer of the block from a department of the UK government to a private for-profit Internet company. Has the UK government been so hard up for cash in recent years that it has taken to selling off any spare /16 blocks that it happens to have lying around? If so, who should I talk to about placing a bid for the next one they decide to unload? ======================================================================== % Version 1 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2015-09-23 15:10 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-DWP descr: UK Government Department for Work and Pensions country: GB status: LEGACY mnt-by: DWP-MNT created: 2015-09-23T13:10:05Z last-modified: 2015-09-23T13:10:05Z source: RIPE ======================================================================== % Version 2 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2015-09-23 15:15 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-DWP descr: UK Government Department for Work and Pensions country: GB org: ORG-DWP1-RIPE status: LEGACY mnt-by: DWP-MNT created: 2015-09-23T13:10:05Z last-modified: 2015-09-23T13:15:16Z source: RIPE ======================================================================== % Version 3 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2015-11-05 17:51 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-DWP1-RIPE status: LEGACY mnt-by: ZEN-MNT created: 2015-09-23T13:10:05Z last-modified: 2015-11-05T16:51:50Z source: RIPE ======================================================================== % Version 4 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2015-11-05 18:43 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-ZIL1-RIPE status: LEGACY mnt-by: ZEN-MNT created: 2015-09-23T13:10:05Z last-modified: 2015-11-05T17:43:45Z source: RIPE ======================================================================== % Version 5 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2019-07-04 12:43 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-ZIL1-RIPE status: LEGACY mnt-by: ZEN-MNT mnt-by: ZEN-NOC-MNT created: 2015-09-23T13:10:05Z last-modified: 2019-07-04T10:43:36Z source: RIPE ======================================================================== % Version 6 (current version) of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2020-02-03 12:55 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-ZIL1-RIPE status: LEGACY mnt-by: RIPE-NCC-LEGACY-MNT mnt-by: ZEN-MNT mnt-by: ZEN-NOC-MNT created: 2015-09-23T13:10:05Z last-modified: 2020-02-03T11:55:22Z source: RIPE

2 1

Questions about status: LEGACY
by Ronald F. Guilmette 28 May '21

28 May '21

Could someone be so kind as to enlighten me about the intended semantics of "status: LEGACY"? I'm back to trying to do parsing of the data base, en mass, and I've just now noticed that the annotation "status: LEGACY" within a given inetnum record may not mean what I thought it meant. (And by the way, there seem to be several tens of thousands of inetnum records in the data base, at present, which are all marked as "status: LEGACY".) Here are just a couple of randomly chosen samples that are confusing me: inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-ZIL1-RIPE admin-c: RT1337-RIPE tech-c: ZIRA1-RIPE status: LEGACY mnt-by: RIPE-NCC-LEGACY-MNT mnt-by: ZEN-MNT mnt-by: ZEN-NOC-MNT created: 2015-09-23T13:10:05Z last-modified: 2020-02-03T11:55:22Z source: RIPE inetnum: 51.155.91.64 - 51.155.91.71 netname: ZEN20210525-NOC-NYCOMM-LIMITED descr: Nycomm Limited descr: leased-line country: GB admin-c: RT1337-RIPE tech-c: ZIRA1-RIPE status: LEGACY mnt-by: ZEN-NOC-MNT created: 2021-05-25T16:49:09Z last-modified: 2021-05-25T16:49:09Z source: RIPE In what sense is the first inetnum record above denoting a "LEGACY" block? The block appears to have been first assigned by RIPE to ORG-ZIL1-RIPE on 2015-09-23. Aren't LEGACY blocks just the ones left-over from the very old days? I have the same questions also for the second inetnum record shown above, which is a sub-assignment / sub-allocation of the first one. Well, here's another one. This also seems rather un-LEGACY, based on the apparent creation date. inetnum: 162.55.0.0 - 162.55.255.255 netname: DE-HETZNER-19920803 country: DE org: ORG-HOA1-RIPE admin-c: HOAC1-RIPE tech-c: HOAC1-RIPE status: LEGACY mnt-by: RIPE-NCC-LEGACY-MNT mnt-by: HOS-GUN mnt-lower: HOS-GUN mnt-domains: HOS-GUN mnt-routes: HOS-GUN created: 2019-11-18T15:01:35Z last-modified: 2019-11-18T15:01:35Z source: RIPE I'm sure that there is a perfectly rational explanation for all of this. I would greatly appreciate it if someone would guide me to it. Whatever is going on here, I obviously didn't get (or didn't read) the memo. Regards, rfg

1 0