You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the import of multiple RIR files (afrinic, apnic, ripe, arin) we end up with multiple "root" nodes of the allocation, i.e.: multiple entries of 0.0.0.0/0:
193.0.0.0/8 | RIPE-CIDR-BLOCK | AU | Not allocated by APNIC | MAINT-APNIC-AP | | 2008-09-04 06:51:29 | apnic
0.0.0.0/0 | IANA-BLK | EU # Country is really world wide | The whole IPv4 address space | AFRINIC-HM-MNT | | | afrinic
0.0.0.0/0 | IANA-BLOCK | AU | General placeholder reference for all IPv4 addresses | MAINT-APNIC-AP | | 2008-09-04 06:51:49 | apnic
Proposal: the supplied SELECT statements should either dedup these or... we leave it as is (and every user needs to dedup) or we create a UNIQUE index on block.inetnum..
What's the best way to approach this? As a user of the DB , I would implicitly assume there is only one entry per inetnum and it's assigned to one of the RIRs.
The text was updated successfully, but these errors were encountered:
Yes, I think that makes sense. If we still have the tree structure of the assignments / sub-allocations iterable via the DB then that reflects the IP address space. Thanks :)
On 25.06.2020, at 22:53, Christian Mehlmauer ***@***.***> wrote:
it looks like there are overlapping netranges too which sucks :/
As in:
one range completely embedded in another but within different RIRs
or as in:
range A goes from a_1.... a_n and B from b_1.... b_m and a_1 < b_1 < a_n < b_m ?
Due to the import of multiple RIR files (afrinic, apnic, ripe, arin) we end up with multiple "root" nodes of the allocation, i.e.: multiple entries of 0.0.0.0/0:
Proposal: the supplied SELECT statements should either dedup these or... we leave it as is (and every user needs to dedup) or we create a UNIQUE index on block.inetnum..
What's the best way to approach this? As a user of the DB , I would implicitly assume there is only one entry per inetnum and it's assigned to one of the RIRs.
The text was updated successfully, but these errors were encountered: