Filters

[Iljitsch van Beijnum]

On 25-mei-2005, at 12:36, leo vegoda wrote:

> When you look at the statistics published by the RIPE NCC you will  
> often see several prefixes reported for a single allocation. This  
> is because we report each allocation event separately.

Argh, that is bad!

Now I have to go and filter those out.

I'm now trying to do this for v4 but it's incredibly slow.

For v6, I don't even know how to go about it as I can't do 128 bit  
integer math.

Why do you guys do this?

> In quite a few cases LIRs expanded their /35 allocations into /32s  
> (or even shorter prefixes where justified). In a situation where a / 
> 35 was 'grown' into a /32 you'll see prefixes like these reported:

> 2001:07b8::/35
> 2001:07b8:2000::/35
> 2001:07b8:4000::/34
> 2001:07b8:8000::/33

According to the policies, these > /32 prefixes can't exist, exept  
for the ARIN microallocations (and even those are still not properly  
documented in the policy documents).

 From your other message:

>> Back to the original thread at hand, it might be a good idea to  
>> filter
>> out these more specific internal prefixes in statistics-output.

> In some cases it is useful to filter that kind of information out.  
> However, some people do use it (mainly in IPv4 statistics, I  
> think). I know that people have used this information to research  
> the number of 'transactions' that took place for prefixes.

> We're always open to requests for how we can make the statistics  
> more useful, though. It may be possible to produce a 'filtered' and  
> an 'unfiltered' set of statistics if that is what people want from us.

Another thing that worries me is that AFAIK, the current stats only  
show the last allocation for an address block. So if a block is  
allocated in 1995 and then returned in 1999 and subsequently  
allocated again in 2001, I only see the 2001 allocation. So I can't  
make good stats for long ago as it looks like returned address space  
is never allocated.

What I'd like to see is all allocations along with a "deallocate"  
date or some such, so it's possible to see the entire history for an  
address block.

This will probably make the files a lot longer, though.