oberman at es
Oct 3, 2009, 3:00 PM
Post #12 of 19
(1181 views)
Permalink
|
> Date: Sat, 03 Oct 2009 23:29:41 +0200
> From: Christian Seitz <seitz [at] strato-rz>
>
> Hello,
>
> Kevin Oberman wrote:
> >> Date: Sat, 03 Oct 2009 09:27:27 +0100
> >> From: James Aldridge <jhma [at] mcvax>
> >>
> >> --On 2 October 2009 16:43:14 -0700 Kevin Oberman <oberman [at] es> 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: oberman [at] es Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
|
