Cleaning up SixXS inet6nums & 400.000++ junk inet6nums from 2a07:7ec0::/29 in the RIPE database

TLDR:
  - SixXS inet6nums will be cleansed out from RIPE DB
  - Somebody has 400k junk inet6nums (40% of total) in there...

Hola,

In regards to https://www.sixxs.net/sunset/, a few hours ago I let our
little robot do one last chore: remove all SixXS inet6num's from the
RIPEdb as those prefixes are now unused and if any abuse claims where
outstanding (we didn't receive any over the last multiple years
actually) then those folks had enough time to whois them...

Normally, that robot was responsible for ensuring that all tunnels &
subnets where properly registered in the database and also removed when
they where not used (marked deleted) by that user for two weeks. I now
instructed it to consider all prefixes (tunnels and subnets) as deleted
and then let it batch out the changes (the RIPE mailserver does not like
very large mails it seems...).

It is already taking a few hours, but it seems that the mails that where
sent in a period of 9 minutes, are being processed slowly, as responses
of the updates are coming in.

I am looking forward to the graph updating:
https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates
to see how much impact it had, as it seems that it is very slow...


# Some stats

Some stats, the robot takes:
ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz

$ cat ripe.db.inet6num |grep "^inet6num:" | wc -l
1000583

(that number is way too high, see below for why)

13 years ago in 2004 I wrote:
https://www.ripe.net/ripe/mail/archives/db-wg/2004-May/002728.html
"Thus SixXS takes care of 53.98% of the inet6num's"
when we had 2898 prefixes ;)

This time the robot found 70581 prefixes to clean (quite a few have been
wiped already in the last months btw, thus that was not the max number,
just the ones still left ;)

Tomorrow all these SixXS prefixes should be gone.

According to that number, SixXS would be 7% of the prefixes, that is
rather quite a different number, thus I wondered, why is that.


# Why are there now 1 million inet6nums? Junk!

Thus lets look at the prefixes with more than 10k inet6nums registered:

$ cat ripe.db.inet6num.clean | grep "^inet6num:" | awk '{print $2}' |
cut -f1,2 -d: | sort -n |uniq -c | sort -n
...
  10575 2001:6f8   <---- Easynet, mostly SixXS prefixes
  13675 2001:4dd0  <---- Netcologne, mostly SixXS
  14038 2001:41f0  <---- Ziggo, wow! now to actually enable users...
  33982 2a02:1630  <---- AS30848 "TWT Spa" in .it nice!
  37372 2a00:2381  <---- British Telecom nice!
  61500 2a07:7ec4  <---- vv junk registrations
  61501 2a07:7ec2
  64575 2a07:7ec1
  64575 2a07:7ec5
  64577 2a07:7ec0
  65600 2a07:7ec3
  65600 2a07:7ec6
  65600 2a07:7ec7  <---- ^^ junk registrations
 210219 2a01:4f8   <---- Hetzner (makes sense to me...)

So apparently, somebody who is not a LIR and who was last year caught
with inserting bogus entries:

 https://www.ripe.net/ripe/mail/archives/db-wg//2016-May/005264.html

currently has !!!!~400k!!!! inet6nums in there, that is ~40% of the
total!!!!

I picked a random few, most of them do not appear to actually be routed.
If you look at the contents, you also notice that the details are bogus.



Thus the big question: why does the RIPE NCC allow that junk to exist
there? (Noting that it was shown last year that that "organisation"
inserted bogus stuff too... and it has not been resolved)


On top of that those 400k++ inet6nums all show bogus geo location (and
are generally useless as they do not contain info at all), lets look at
what registers that:

inet6num:       2a07:7ec0::/29
netname:        NL-OSP-20160517
country:        GB
...
address:        Spuistraat 249-II
address:        1012VP Amsterdam
...
org-type:       OTHER
...

Really, a Dutch address, claiming a British country, while the prefix
clearly show "NL" as prefix.

Website at http://www.onlineserviceproviderbv.nl/ is empty, hosted on
throw-away Digital Ocean, not on "own" infrastructure (the prefixes they
have..).

Checking RIS:

https://stat.ripe.net/2a07%3A7ec0%3A%3A%2F29#tabId=routing


Next to storing junk in RIPEDB, apparently also wasting a lot of routing
space, as they all end up in a land of randomness.


As that office address is close by RIPE NCC, can somebody maybe visit
them and try to educate these folks (if anybody is there), to become
quite a bit better netizen.... though, I bet you'll find people more
home at:

aut-num:        AS202792
as-name:        CLOUDSRV
...
org-name:       CloudSRV Limited
org-type:       LIR
address:        Unit 24 Oakleigh Court, Church Hill Road
address:        EN4 8UX
address:        East Barnet
address:        UNITED KINGDOM

who are announcing a /31 of that space...

I guess that after all these years it is still a very good idea to apply:
https://www.space.net/~gert/RIPE/ipv6-filters.html

Greets,
 Jeroen