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