> > If I go by the list published the RIPE NCC themself. > https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest > The 188.64.224.0/21 prefix is not allocated at all. > > Why Twitter is announcing it. < scratching head for answers > > https://stat.ripe.net/188.64.224.0-188.64.231.255?sourceapp=ripedb#tabId=database
I see 7 such announcements originated by AS13414: 188.64.224.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255 188.64.225.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255 188.64.226.0/23 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255 188.64.226.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255 188.64.227.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255 188.64.228.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255 188.64.229.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255 Of course Twitter is doing nothing uniquely unusual in this respect, as these are just 7 examples from a pool of some 300 announcements of unallocated address space (a list of such bogons can be found at http://www.cidr-report.org/as2.0/#Bogons) - Why is Twitter announcing these prefixes? I have no idea. Something has gone wrong here and the address has come back to the RIR and Twitter apper to be unaware of this. - How and why is this prefix in RADB, given that it is unallocated space? Good question - I wonder what periodic checks the RADB undertakes on the data held in its registry? - Why do upstream AS’s accept these advertised prefixes? Maybe they chose to believe that RADB performs robust periodic integrity checks? Or <insert reason here>? Geoff
