RIPE-NONAUTH route object anomalies
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
Hi Ronald,
On 10 Jun 2021, at 23:57, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
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.
Correct, the route objects with an unregistered prefix will be cleaned up 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:
In April I found 33 route objects in NONAUTH with a completely in-region range. I notified the maintainers and moved those routes to the RIPE database. The 4 cases you found are not completely in the RIPE region, so it's not clear if they should remain in NONAUTH or be (re)moved. None of the ranges appear to have been split by an inter-RIR transfer: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran... <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/inter-rir/inter-rir-ipv4-transfer-statistics> But the route prefix falls between 2 RIR assignments
192.124.252.0/22
This prefix is referenced from 1 NONAUTH route 192.124.252.0/22AS680 The prefix is split between RIPE and ARIN: ripencc|DE|ipv4|192.124.252.0|256|19920812|assigned|472b74a8-9fd5-4837-9024-f7574bdd7f7c ripencc|DE|ipv4|192.124.253.0|256|19931019|assigned|e68966fe-33c9-47f0-ad13-e83ca182b8bf ripencc|DE|ipv4|192.124.254.0|256|19840101|assigned|e4626976-484a-4850-897d-d7be3e709511 arin||ipv4|192.124.255.0|256||reserved| I see 3 routes in the RIPE database: 192.124.252.0/24AS3320 192.124.253.0/24AS680 192.124.254.0/24AS680
192.70.0.0/17
This prefix is referenced from 1 NONAUTH route: 192.70.0.0/17AS2200 The prefix is mostly assigned to the RIPE region, except for a /24: ripencc|FR|ipv4|192.70.0.0|23552|19930901|assigned|4c5e10ae-266a-4127-84ac-04b780309b1d ripencc|FR|ipv4|192.70.92.0|1280|20050411|assigned|b8f87e41-6e2a-427f-af98-60c978d51985 ripencc|FR|ipv4|192.70.97.0|4352|19930901|assigned|3e011729-91a0-412e-8947-1ac32eef22e2 192.70.113.0 - 192.70.113.255 not in *any* delegated stats file? ripencc|FR|ipv4|192.70.114.0|256|19900315|assigned|3e219d39-a2e5-476b-bf9b-835f172f89ae ripencc|FR|ipv4|192.70.115.0|256|19900315|assigned|4d073146-29da-45c5-a74c-e90c3963405f ripencc|FR|ipv4|192.70.116.0|256|19900315|assigned|ef2d7312-e300-4850-83d0-e99faa095c12 ripencc|FR|ipv4|192.70.117.0|256|19930520|assigned|a4b599d8-871f-4f0a-b5c3-5b5d96a614e4
192.76.32.0/21
This prefix is referenced from 1 NONAUTH route: 192.76.32.0/21AS786 The prefix is split between RIPE and ARIN: ripencc|GB|ipv4|192.76.24.0|3072|19900815|assigned|1ae99a59-4b02-4c77-8ce0-e7e359a12842 arin|US|ipv4|192.76.36.0|1024|19900828|allocated|eaf44477133ed73a4fc62658b886953b
192.108.160.0/20
This prefix is referenced from 1 NONAUTH route: 192.108.160.0/20AS2607 The prefix is split between RIPE and ARIN: ripencc|SK|ipv4|192.108.134.0|10496|19910724|assigned|755273b5-19e0-4fae-95c4-0e804f714dea arin|US|ipv4|192.108.175.0|256|19910724|assigned|c096bf755fee3dfb7b9046461595ebd0
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.
I suggest that the RIPE NCC emails the maintainer(s) of these objects, and ask them to update the routes so they align to the assigned regions. They are not using unregistered space, and are not eligible to be cleaned up. Regards Ed Shryane RIPE NCC
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
Hi Ronald,
On 11 Jun 2021, at 11:33, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
...
192.70.0.0/17
This prefix is referenced from 1 NONAUTH route: 192.70.0.0/17AS2200
The prefix is mostly assigned to the RIPE region, except for a /24:
ripencc|FR|ipv4|192.70.0.0|23552|19930901|assigned|4c5e10ae-266a-4127-84ac-04b780309b1d ripencc|FR|ipv4|192.70.92.0|1280|20050411|assigned|b8f87e41-6e2a-427f-af98-60c978d51985 ripencc|FR|ipv4|192.70.97.0|4352|19930901|assigned|3e011729-91a0-412e-8947-1ac32eef22e2 192.70.113.0 - 192.70.113.255 not in *any* delegated stats file?
Apologies, I mis-calculated this range: 4352 = /20 + /24, the 192.70.113.0/24 *is* assigned to the RIPE region.
ripencc|FR|ipv4|192.70.114.0|256|19900315|assigned|3e219d39-a2e5-476b-bf9b-835f172f89ae ripencc|FR|ipv4|192.70.115.0|256|19900315|assigned|4d073146-29da-45c5-a74c-e90c3963405f ripencc|FR|ipv4|192.70.116.0|256|19900315|assigned|ef2d7312-e300-4850-83d0-e99faa095c12 ripencc|FR|ipv4|192.70.117.0|256|19930520|assigned|a4b599d8-871f-4f0a-b5c3-5b5d96a614e4
I also omitted a few ranges, this prefix is also split between RIPE and ARIN: ripencc|FR|ipv4|192.70.118.0|256|20090824|assigned|93a1d9ff-0291-4ecd-a36d-6e231d34e12c ripencc|FR|ipv4|192.70.119.0|256|19930419|assigned|97f599a0-440b-4d6c-a58e-a56c5436a43a arin|US|ipv4|192.70.120.0|256|19900324|allocated|1f99771bc3e23e6097509a331544ab65 arin|US|ipv4|192.70.121.0|256|19900324|allocated|1f99771bc3e23e6097509a331544ab65 arin|US|ipv4|192.70.122.0|256|19900324|allocated|1f99771bc3e23e6097509a331544ab65 arin|US|ipv4|192.70.123.0|256|19900324|allocated|1f99771bc3e23e6097509a331544ab65 arin|US|ipv4|192.70.124.0|256|19900324|allocated|1f99771bc3e23e6097509a331544ab65 arin|US|ipv4|192.70.125.0|256|19900324|allocated|1f99771bc3e23e6097509a331544ab65 arin|US|ipv4|192.70.126.0|256|19900324|allocated|1f99771bc3e23e6097509a331544ab65 arin|US|ipv4|192.70.127.0|256|19900324|allocated|1f99771bc3e23e6097509a331544ab65 These 4 prefixes you mentioned are historically split between RIRs, and not due to an Inter-RIR transfer. Regards Ed Shryane RIPE NCC
In message <6B0C79DD-9646-44D8-9E04-F55D292D4956@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
The 4 cases you found are not completely in the RIPE region, so it's not clear if they should remain in NONAUTH or be (re)moved.
I have a standing policy with regards to anomalies generally. It can best be summarized as follows: "Kill them all. Let god sort them out." Of course, this attitude on my part tends to find more favor in and among the anti-spam community, e.g. when it comes to spammers & their domains and IP addresses, than it is likely to in the case of DB route objects, where a bit more caution & circumspection may be obligatory. I leave it to your good judgment as to how to resolve these 4 anomalies, and I will just reiterate my desire to see all four resolved in some manner so that when/if I (or you) perform this same sort of automated analysis in the future, these won't just keep on cropping up as unexplained oddities forever. Hopefully that can be made to happen in one way or another.
I suggest that the RIPE NCC emails the maintainer(s) of these objects, and ask them to update the routes so they align to the assigned regions.
That works for me.
They are not using unregistered space, and are not eligible to be cleaned up.
Well, if it were me, I would simply annihilate them anyway, for the sin of being goofy. (Perhaps this general preference on my part goes a long way towards explaining why I personally have never held any elected office.) Regards, rfg
Roland, I find your following language: On 11.06.2021 22:53, Ronald F. Guilmette via db-wg wrote:
I have a standing policy with regards to anomalies generally. It can best be summarized as follows:
"Kill them all. Let god sort them out."
quite offensive actually. Apart from the fact that it does not make any sense *) - at least not to me - I find it puzzling that anomalies should be killed. Even if this is meant in a strict tech context only. Thanks, -C. *) Either you kill all instances of something. Then there is nothing left for any "god" to sort it out. Or you want to leave it to some "god" to sort it out - then you better should not kill it.
On 14.06.2021 13:38, Carsten Schiefner via db-wg wrote:
Roland,
That, of course, should have read "Ronald" - my sincerest apologies!
I find your following language:
On 11.06.2021 22:53, Ronald F. Guilmette via db-wg wrote:
I have a standing policy with regards to anomalies generally. It can best be summarized as follows:
"Kill them all. Let god sort them out."
quite offensive actually.
Apart from the fact that it does not make any sense *) - at least not to me - I find it puzzling that anomalies should be killed. Even if this is meant in a strict tech context only.
Thanks,
-C.
*) Either you kill all instances of something. Then there is nothing left for any "god" to sort it out. Or you want to leave it to some "god" to sort it out - then you better should not kill it.
participants (3)
-
Carsten Schiefner -
Edward Shryane -
Ronald F. Guilmette