Re: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed

[Per Heldal <heldal at eml.cc>]

On Fri, 2007-07-20 at 12:20 +1000, Robin Whittle wrote:
> Thanks for answering my questions about /48s and for pointing me
> to the guidelines which some or many people follow - Gert
> Doering's page:
> 
>   http://www.space.net/~gert/RIPE/ipv6-filters.html
> 

In the absence of scalable IDR and route-certificates you'll also find
people using more strict filters in an attempt to achieve operational
stability. Such filters aim to keep the maximum numbers of prefixes
within the capacity of available hardware. Thus, if a registry allocates
blocks out of e.g. a /23 only a small fraction of that /23 may initially
be accepted, especially if it is used for PI /48s. The current v6
routing-table may be small, but I'm sure attitudes will change as more
people realise the potential impact on their infrastructure as it
becomes increasingly common to operate dual-stack networks.

A practical approach to the process of building v6 filters would be:

1. Look at IANA's assignments to RIRs

2. Examine policies for each block to check if they are sub-divided into
smaller blocks with individual allocation policies.

3. Obtain prefix-length-recommendations from the RIRs' routing policies
for each address-block.

4. Examine (download&process) the records of the RIR's allocations to
LIRs and end-users to determine the last allocation (highest number) in
each block.  

This, combined with a wish to allow some extra prefix-bits for shorter
AS-paths (traffic-engineering) defines a "baseline" for prefix-filters.
Note: It's not unusual to use a similar approach for ipv4 -- either for
operational filters or in tools used to analyse various aspects of the
DFZ. 

(The task would of course be much simpler if this information was
available in a consistent/unified/standardised format from all parties
involved ;))


//per


_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram