nanog mailing list archives

Re: Minimum IPv6 size


From: "Kevin Oberman" <oberman () es net>
Date: Sat, 03 Oct 2009 15:00:48 -0700

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>

--On 2 October 2009 16:43:14 -0700 Kevin Oberman <oberman () es net> 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 () es net                       Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


Current thread: