[db-wg] Re: The Cidr Report

I used the term "completely unreliable" as an unwarranted exaggeration - my 
apologies.

However there are some obvious incorrect entries in the RIPE database such 
as  entries for

BT-NORTH-BLOCK-CAMBRIDGE inetnum: 2.6.190.56 - 2.6.190.63 2.6.190.56/29

SE-MARINEX inetnum: 5.163.66.80 - 5.163.66.95 5.163.66.80/28

Such entries as those above are easy to spot simply because they refer to 
prefixes from /8 address blocks that are in the IANA reserved pool.

Unfortunately this raises the larger question of whether there are similar 
erroneous entries in address blocks that are part of the RIR-allocated 
address block pool, and at this stage I have no way of making a clear call 
here. In this report I've erred on the basis of high caution. Perhaps it 
would be more useful in terms of listing potential bogons to accept the 
RIPE database entries as allocated even where there is no corresponding 
stats file entry (blocks that appear to have been transferred via ERX, for 
example).


thanks,

    Geoff




At 01:27 AM 23/06/2005, Hank Nussbacher wrote:
>On Wed, 22 Jun 2005, Geoff Huston wrote:
>
>One potential problem: ERX data.  I am looking at all the Israeli entries
>for example, from 192.114.x.x-192.118.x.x
>
>You will find it in RIPE whois, but you won't find it in the RIPE stats
>file since the block was ERXed as were probably many others.
>
>Not sure how you can handle that.
>
>Regards,
>Hank
>
>
> > cleared up BUT changed in one important respect:
> >
> > If an entry isin the RIPE whois database but NOT in the RIPE stats file I'm
> > marking it as potentially bogus. I would like to see the RIPE stats file be
> > an accurate picture of RIPE managed address space, and the database is
> > completely unreliable :-(
> >
> > Geoff
> >
> >
> >
> > At 01:08 AM 18/06/2005, Hank Nussbacher wrote:
> >
> > >I was hoping the report would be cleaned up by now but it hasn't so sorry
> > >for the multiple list post.  The Bogon section is IMHO, broken.
> > >
> > >Taking just the 1st line as an example:
> > >Prefix Origin AS   AS Description Unallocated block
> > >3.0.0.0/8   AS80   GE-CRD - General Electric Company 0.0.0.0 - 3.0.0.0
> > >
> > >3.0.0.0/8 is allocated, as is AS80.  I suspect the algorithm, which
> > >determines the unallocated block of 0.0.0.0 - 3.0.0.0 to be somewhat
> > >broken.
> > >
> > >There are thousands of lines like that.
> > >
> > >The bogus AS section also appears to be broken.
> > >
> > >-Hank
> >
> >
> >
> >  +++++++++++++++++++++++++++++++++++++++++++
> >  This Mail Was Scanned By Mail-seCure System
> >  at the Tel-Aviv University CC.
> >