Filters

[leo vegoda]

Hi Iljitsch,

On May 25, 2005, at 12:05 pm, Iljitsch van Beijnum wrote:

[...]

> The RIRs say you can filter at /32. (Well, except for micro  
> allocations.)
>
> But I don't keep all RIR allocations and assignments in a database,  
> so let's have a look:
>
> mysql> select count(*) as delegations, num as prefixlength from  
> addrspace where type="ipv6" group by num order by num;
> +-------------+--------------+
> | delegations | prefixlength |
> +-------------+--------------+
> |           1 |           19 |
> |           2 |           20 |
> |           2 |           21 |
> |           1 |           22 |
> |           1 |           23 |
> |           1 |           24 |
> |           2 |           27 |
> |           1 |           28 |
> |           1 |           29 |
> |           2 |           30 |
> |           3 |           31 |
> |         702 |           32 |
> |         112 |           33 |
> |         112 |           34 |
> |         231 |           35 |
> |          54 |           48 |
> |           5 |           64 |
> +-------------+--------------+
> 17 rows in set (0.31 sec)
>
> This is actually pretty shocking!

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.

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

but if you look in the Whois database you'll see a /32 with the  
ALLOCATED-BY-RIR status, not any more specific prefixes.

I hope this explains why you see a bunch of /33s and /34s in the  
statistics we publish.

Regards,

-- 
leo vegoda
Registration Services Manager
RIPE NCC