August 2021 - db-wg - mailman.ripe.net

New NWI for geofeed?
by denis walker 14 Apr '22

14 Apr '22

Colleagues [Apologies for the length of this email...] The chairs would like to suggest creating a new NWI for the "geofeed:" attribute and suggest the following draft Problem statement and Solution definition. If there is agreement on this the RIPE NCC will do an impact assessment including legal review and summary of what the other RIRs are doing. There has already been quite a discussion in the WG on this issue with a lot of support. So hopefully we can reach a consensus quickly, at least on setting up the NWI and starting the impact assessment. Having read the latest draft IETF docs, there are some outstanding questions. Comments and changes are welcome... cheers denis co-chair DB-WG Problem statement Associating an approximate physical location with an IP address has proven to be a challenge to solve within the current constraints of the RIPE Database. Over the years the community has chosen to consider addresses in the RIPE Database to relate to entities in the assignment process itself, not the subsequent actual use of IP addresses after assignment. The working group is asked to consider whether the RIPE Database can be used as a springboard for parties wishing to correlate geographical information with IP addresses by allowing structured references in the RIPE Database towards information outside the RIPE Database which potentially helps answer Geo IP Location queries The IETF is currently discussing an update to RPSL to add a new attribute "geofeed: url". The url will reference a csv file containing location data. Some users have already started to make use of this feature via the "remarks: geofeed: url". It is never a good idea to try to overload structured data into the free format "remarks:" attribute. This has been done in the past, for example with abuse contact details before we introduced the "abuse-c:" attribute. There is no way to regulate what database users put into "remarks:" attributes. So even if the new "geofeed:" attribute is not agreed, the url data will still be included in the RIPE Database. Currently there are 24,408 INETNUM and 516,354 INET6NUM objects containing a "remarks: geofeed: url" attribute in the database. These have 7,731 distinct values in the INETNUMs and 1,045 distinct values in the INET6NUMs. Solution definition Implement a new "geofeed:" attribute according to the IETF's definition. Although the IETF has not yet concluded discussions on this attribute we can still implement it in the RIPE Database RPSL data definition. The RIPE Database already has many local differences to the RPSL standard. As expressed in the Problem statement, users are already using the geofeed data by overloading the "remarks:" attribute. That is a dirty hack which should be avoided. An invalid formated url will be a syntax error. The RIPE NCC will perform a one time conversion of the existing data to convert "remarks: geofeed: url" to "geofeed: url". If an update then contains a "remarks: geofeed: url" attribute, the update will be successful and the response should include an appropriate Warning message. At some point in the (near) future, this could be changed to an update failure as a syntax error. An update containing a "geofeed:" and a "remarks: geofeed:" attribute or more than one "remarks: geofeed:" will be a syntax error. The resource holder should be able to create, modify, delete the "geofeed:" attribute in allocation objects. Questions: -Should the database software do any checks on the existence/reachability of the url as part of the update with an error if the check fails? -Should the RIPE NCC do any periodic repeat checks on the continued existence/reachability of the url? -Should the RIPE NCC do any periodic checks on the content structure of the csv file referenced by the url? -Should the Solution definition define how this will be adopted into RDAP or should we simply ask the RIPE NCC to define this in their impact assessment? -The RIPE Database contains hierarchical address space objects. Should it be acceptable for "geofeed:" attributes to exist at multiple levels within a specific hierarchy? -Suppose a geofeed csv file referenced by a /16 INETNUM object contains location data for the whole /16. Then a more specific /24 INETNUM object references another geofeed csv file that contains conflicting location data for this /24. Should this be a concern for the RIPE Database? -Should geofeed data be inherited? If you query for a /24 that does not contain a "geofeed:" attribute, but a less specific /16 does contain a "geofeed:" attribute, should this data be returned? In other words could it be used in a similar way to "abuse-c:"? -Thinking ahead to how people will actually deploy this data and what short cuts they could make. It is said that when reading a geofeed csv file, consumers of the data should ignore all data within that file not directly concerning the address space queried in the RIPE Database. Could you therefore create a single csv file with location data for all your address space and reference the same file in all your RIPE Database address objects? The address space owner could rely on the data consumer to pick out the correct piece of data for the relevant address space. The manager of the csv file then only has to work with one file. If this is possible and does happen (which the IETF doc 'Finding geofeeds' seems to suggest is possible for unsigned geofeed data), would it therefore make sense to apply "geofeed:" hierarchically as with "abuse-c:"? Allow a single, default "geofeed:" attribute in the ORGANISATION object to be applied to all that organisations address space, with the option of specific localised "geofeed:" attributes in address space objects. That could be a neater solution, and easier to setup, than applying thousands of references to the same geofeed file at a more specific level in the database. -Relating to the above 3 questions, should geofeed data only be considered applicable if returned by a specific geofeed locater application which takes into account the hierarchical nature of address space in the database? Otherwise do the standard database query mechanisms have to take into account this hierarchy and locate the most specific "geofeed:" attribute from the less specific objects? -Should/could the RIPE Database return the csv file as part of the query? If so should the file be cached (for how long?) to avoid too many downloads? -Should we only allow HTTPS urls? (Which the IETF doc 'Finding geofeeds' seems to suggest) -Should the RIPE NCC go ahead and implement this now, with our own set of RIPE rules? Or should we try to coordinate this and agree a set of common rules between all the RIRs before any deployment in the RIPE Database? -For the legal review, there are 2 statements in the IETF doc 'Finding geofeeds' which may be of concern: *[RFC8805] geofeed data may reveal the approximate location of an IP address, which might in turn reveal the approximate location of an individual user. Unfortunately, [RFC8805] provides no privacy guidance on avoiding or ameliorating possible damage due to this exposure of the user. In publishing pointers to geofeed files as described in this document the operator should be aware of this exposure in geofeed data and be cautious. All the privacy considerations of [RFC8805] Section 4 apply to this document. *It is significant that geofeed data may have finer granularity than the inetnum: which refers to them. It is clear that the RIPE NCC cannot prevent this data being referenced by objects in the RIPE Database. It is already being referenced from "remarks:" attributes. Perhaps the RIPE NCC should require (as part of their service agreement) that it's members obtain written consent from their customers to publish this location data, or at least inform the customers in writing that it will be published. Also, although RFC8805 says postcode is deprecated it is still provided for in the csv files. So anyone can still enter location data to this detail. -The IETF doc 'Finding geofeeds' suggests that geofeed information 'will be' available in bulk accessed whois data. In view of the privacy concerns above, is this likely? -The IETF doc 'Finding geofeeds' says "To minimize the load on RIR whois [RFC3912] services, use of the RIR's FTP [RFC0959] services SHOULD be the preferred access." Is the RIPE NCC expected to download all the geofeed files and make them available through their FTP service? -The IETF doc 'Finding geofeeds' states that consumers of the geofeed data MUST NOT access this data in real time via the RPSL servers 'too frequently' or at 'magic times like midnight'. Some users will do whatever they want to do if they are able to do, regardless of any statements to the contrary. Should the RIPE NCC enforce such access rules by some means? References The IETF doc 'Finding geofeeds': https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/?includ… geofeed file format: https://www.rfc-editor.org/rfc/rfc8805.html

12 53

RIPE Database Requirements Task Force – Draft Report Published
by Bijal Sanghani 04 Oct '21

04 Oct '21

Dear colleagues, The RIPE Database Requirements Task Force has just published a draft report for your review: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… In this third draft, we’ve added new recommendations and edited our document based on feedback received via emails, survey and during our third BoF in May. Please review this draft and share any comments on the ripe-list before Friday, 13 August 2021. The task force will reconvene in August to discuss the feedback received and work on its final report that will be published ahead of RIPE 83. We look forward to your feedback. Best Regards, Bijal Sanghani

5 9

"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