On 13/07/2018 18:40, Sandra Murphy via db-wg wrote: While we are on the topic, anyone have an idea about Cisco and 66.187.208.0/20?
Thanks, Hank > So that’s the change I saw visible in the RIPE stat files at > https://ftp.ripe.net/pub/stats/ripencc/. > > Twitter has been announcing that space for years. I wonder if they’ll report > what led them to start the announcements. > > —Sandy > >> On Jul 13, 2018, at 10:48 AM, Henriette Van Ingen via db-wg <[email protected]> >> wrote: >> >> Dear all, >> >> We would like to inform you that the RIPE NCC has de-registered >> 188.64.224.0/21 on 10 July 2018 according to our published procedures. We >> are in contact with the relevant party. >> >> Best Regards, >> >> Henriette van Ingen >> Customer Services >> RIPE NCC >> >> >>> On 13 Jul 2018, at 11:54, denis walker via db-wg <[email protected]> wrote: >>> >>> Hi Guys >>> >>> I am sure everyone will disagree with me, but this shows (to me) why it >>> would be better to have one authoritative, accurate, trusted, distributed >>> IRR managed by the 5 RIRs than many independent/commercial IRRs with non >>> authenticated data. >>> >>> cheers >>> denis >>> co-chair DB-WG >>> >>> >>> >>> From: Aftab Siddiqui via db-wg <[email protected]> >>> To: Geoff Huston <[email protected]> >>> Cc: RIPE Database Working Group <[email protected]> >>> Sent: Thursday, 12 July 2018, 18:40 >>> Subject: Re: [db-wg] Source GRS vs RIPE >>> >>> Hi Geoff, >>> >>> 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. >>> >>> No, Twitter is absolutely aware of this issue, I alerted their NOC when I >>> got the result this morning from CIDR report (yes, I scrop your data daily) >>> but unfortunately there response was "This prefix is valid and owned by us >>> in RIPE region. Please do your homework before making incorrect >>> accusations." But atleast I tried. >>> >>> - 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? >>> >>> No idea, it should be triggered right away when the RIR, who is the >>> authentic source of these resources marked them "Unalloacted". But in a >>> perfect world. >>> >>> - 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>? >>> >>> Yes, mostly follow RADB. >>> >>> >>> Geoff >>> >>> >>> >>> >>> >>> >>> >
