Minimum IPv6 size

Mailman List Mirror (Read Only)
1

Date: Fri, 02 Oct 2009 16:29:25 -0700
From: Seth Mattinen <sethm@rollernet.us>

Since we're on the topic of what's commonly accepted in IPv4 land (a
/24), what's the story in IPv6 land? It seems to me that a /32 is a fur
sure thing, but others will accept down to a /48, too.

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.

2

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)

James

3

[...]

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)

Why the whole /16 rather than just that /29 and a few other blocks set
aside for /48s? There are a lot of /48s in a /16, so protecting
against someone accidentally deaggregating their allocated /32 into /
48s seems legitimate.

Regards,

Leo

4

Indeed. By "within 2001::/16" I was just pointing out that, not having the definitive list, there were some blocks "within 2001::/16" which require a longer prefix.

James

5

In a message written on Sat, Oct 03, 2009 at 03:01:42AM -0700, Leo Vegoda wrote:

Why the whole /16 rather than just that /29 and a few other blocks set
aside for /48s? There are a lot of /48s in a /16, so protecting
against someone accidentally deaggregating their allocated /32 into /
48s seems legitimate.

Our track record of keeping up with these lists as in industry in
IPv4 is pretty poor, I see no reason to think IPv6 is any better.
The more restrictive, the greater the chance of inadvertently filtering
something you should not.

The problem of a peer deaggregating too many routes to you is better
handled with max-prefix settings. We've had this technology for a long
time, and if you're really concerned about getting an extra 10k routes
from a peer use max-prefix, not some draconian, static, never updated
prefix filter.