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