[rpd] AfriNIC audit data

[Andrew Alston]

You also have to remember, that space allocated prior to soft-landing has
no geographic restrictions on where it can be used - geographic
restrictions only applied to space allocated under soft landing.

Secondly - geo-location is horrifically inaccurate - I can point to
numerous blocks which claim they are in Mauritius but 100% aren't.  I can
point to blocks where geo-location claims they are in Las Vegas - when they
are 100% used in Africa - the fact is most geo-location providers seem to
be either using the whois data or using other metrics and are incredibly
often very very far from accurate.  Sadly, most of the geo-location
providers refuse to implement anything resembling RFC8805 either, which
would at least allow providers to publish accurate data.

Thirdly - traceroutes are meaningless in terms of geo-location - for one
thing - you have people using non-LEO based satellite connectivity - more
than you would imagine, the latency there will tell you absolutely
nothing.  For another thing, when you add MPLS ttl-no-decrement to
networks, which hides hops , you have no way to know where the space is
being routed via - and hence latency measurements are totally out of
whack.  I point out that it was just yesterday when I saw the latency of a
particular prefix go from 120ms odd to well over 200, purely because the
provider receiving the prefix screwed up the return path - a return path
which was of course invisible on the traceroute.  The space was still used
on continent - but the traceroute latencies told a vastly misleading story.

So no - determining geographic location of space is not as simple as you
make it out to be, in fact, its a massive headache that I've had to spend
copious amounts of time dealing with over the years because of faulty
geo-location data and geo-location ring fencing on services - so IP's
showing up in the wrong location and as a result being unable to access
certain things.

Andrew


On Fri, Oct 24, 2025 at 4:39 PM Fernando Frediani <fhfrediani at gmail.com>
wrote:

>
> On Fri, 24 Oct 2025, 10:18 Andrew Alston, <aa at alstonnetworks.net> wrote:
>
>>
>> With regards to space being used out of region - that's extremely
>> difficult to actually know - because the BGP table has no knowledge of
>> geography :)
>>
>
> I wouldn't say it is trivial but with geolocation data plus some
> traveroutes and latency check it is not extremelly dificult to find out.
>
> With some intended work that can be found out and further investigate to
> give AfriNic all necessary information.
>
> Fernanso
>
>>
>> On Fri, Oct 24, 2025 at 4:11 PM Fernando Frediani <fhfrediani at gmail.com>
>> wrote:
>>
>>> Yes there are legitimate cases, but when this happens it may be a signal
>>> of alert. The point is to find two things: 1) If the ASN announcing it
>>> doesn't have any relation to the resource holder and 2) If resources are
>>> being used out of the region (the worst).
>>> For the case of parent/sub-company ideally resources should be
>>> transferred among companies using them in reality then.
>>>
>>> Fernando
>>>
>>> On 10/24/2025 7:45 AM, Andrew Alston wrote:
>>> > Hi All,
>>> >
>>> > While I haven't got around to publishing the code behind this - mainly
>>> > because it by necessity exposes certain data and requires a BGP dump
>>> > from a juniper router which is hundreds of megs big, I've attached the
>>> > output of the code I wrote.
>>> >
>>> > One caveat with this data - There is nothing inherently wrong with
>>> > space allocated to an organisation being announced by a non-AfriNIC
>>> > ASN, there are many legitimate cases and reasons behind this.  The
>>> > same thing happens when space is allocated to one organisation but
>>> > announced by another, and this can happen when a sub-company of a
>>> > parent company is announcing space from their own ASN when the space
>>> > was originally allocated to the parent.  As such, when reading this
>>> > data, it's important to understand that the abnormalities detected do
>>> > not necessarily indicate anything nefarious - and this data should not
>>> > be seen as accusations of malfeasance against anyone.
>>> >
>>> > Let's see if the lists let this post through!
>>> >
>>> > Thanks
>>> >
>>> > Andrew
>>> >
>>> >
>>> > _______________________________________________
>>> > RPD mailing list
>>> > RPD at afrinic.net
>>> > https://lists.afrinic.net/mailman/listinfo/rpd
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20251024/156acf37/attachment.html>