> Date: Sat, 03 Oct 2009 23:29:41 +0200 > From: Christian Seitz <[email protected]> > > Hello, > > Kevin Oberman wrote: > >> Date: Sat, 03 Oct 2009 09:27:27 +0100 > >> From: James Aldridge <[email protected]> > >> > >> --On 2 October 2009 16:43:14 -0700 Kevin Oberman <[email protected]> wrote: > >>> 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.htm > > There 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. > > [1] http://www.space.net/~gert/RIPE/ipv6-filters.html
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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [email protected] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
