About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

[db-wg] Re: The Cidr Report

  • To: Hank Nussbacher <
    >
  • From: Geoff Huston <
    >
  • Date: Thu, 23 Jun 2005 04:34:50 +1000
  • Cc:
    ,

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.
>




 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | Copyright Statement
RIPE.NET Homepage LIR Portal RIPE Community