Date: Sat, 03 Oct 2009 23:29:41 +0200
From: Christian Seitz <seitz@strato-rz.de>Hello,
Kevin Oberman wrote:
>> Date: Sat, 03 Oct 2009 09:27:27 +0100
>> From: James Aldridge <jhma@mcvax.org>
>>
>>> Depends on the address space it is assigned from. Most specify a maximum
>>> prefix length of 32, but the micro-allocations and the allocations for
>>> PI dual-homing are /48.
>>> We consider the following to be "legal":
>>> /* global unicast allocations */
>>> route-filter 2001::/16 prefix-length-range /19-/35;
>>> /* 6to4 prefix */
>>> route-filter 2002::/16 prefix-length-range /16-/16;
>>> /* RIPE allocations */
>>> route-filter 2003::/18 prefix-length-range /19-/32;
>>> /* APNIC allocations */
>>> route-filter 2400::/12 prefix-length-range /13-/32;
>>> /* ARIN allocations */
>>> route-filter 2600::/12 prefix-length-range /13-/32;
>>> /* ARIN allocations */
>>> route-filter 2610::/23 prefix-length-range /24-/32;
>>> /* LACNIC allocations */
>>> route-filter 2800::/12 prefix-length-range /13-/32;
>>> /* RIPE allocations */
>>> route-filter 2A00::/12 prefix-length-range /13-/32;
>>> /* AfriNIC allocations */
>>> route-filter 2C00::/12 prefix-length-range /13-/32;
>>> /* APNIC PI allocations */
>>> route-filter 2001:0DF0::/29 prefix-length-range /40-/48;
>>> /* AFRINIC PI allocations */
>>> route-filter 2001:43F8::/29 prefix-length-range /40-/48;
>>> /* ARIN PI allocations */
>>> route-filter 2620::/23 prefix-length-range /40-/48;
>>> /* ARIN Micro-allocations */
>>> route-filter 2001:0500::/24 prefix-length-range /44-/48;
>>>
>>> This means accepting prefixes ARIN says we should not, but ARIN does not
>>> set our routing policy and I will be on a panel on that issue at NANOG in
>>> Dearborn later this month.
>>
>> It might be worth relaxing filtering within 2001::/16. The RIPE NCC
>> appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the
>> RIPE Meeting next week will be using 2001:67c:64::/48)
>
> Looks like we need to relax 2001:678::/29 a bit, but I am not sure that
> we will open up the entire /16. I already have such for ARIN, AfriNIC,
> and APNIC.
>
> Is there some central repository for information on this? We usually
> seem to find out about such changes out of the ARIN region a bit after
> the fact.each RIR has an overview of their managed address space with the longest
prefixes they are assigning/allocating from their ranges. I currently use those
overviews to build IPv6 BGP filters manually. If you build very strict filters,
you have to check the overviews more often as with loose filters.https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html
http://www.arin.net/reference/ip_blocks.html
http://www.arin.net/reference/micro_allocations.html
http://www.apnic.net/db/min-alloc.html
http://lacnic.net/en/registro/index.html
http://www.afrinic.net/Registration/resources.htmThere ist also a loose and a strict filter recommendation by Gert Doering [1],
but the strict filter is very strict at the moment. It allows only /48s from
RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also
assignes /47 or /46 from this range. Also there should be some deaggregation
allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for
some reason, because he cannot get a second /32, he should be able to use (eg.)
4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32
prefixes, but I would accept prefixes up to a /36.
Thanks for the AfriNIC URL. I did had not seen that page. I'm pretty
sure that the PI space was not declared last time I looked for
something.
We do allow deaggregation of all space to /35. That is three bits
allowing for 8 different announcements. We are always re-evaluating this
policy and it is quite possible that it will be moved to a /36 in the
future. We also are considering loosening the PI down to /50 or even
/52. I really can't see much justification to go beyond that at this
time.
No matter how hard people try, I am sure that we will need to
continue to broaden filters and expand the route tables. I belive that,
in the long run (and not very long) the only solution will be some kind
of locator/identifier separation which has the potential to control the
size of the RIB and FIB for a very long time.