[ipv6-wg@localhost] Re: /48 micro allocations for v6 root servers, was: national security

[Iljitsch van Beijnum <]

On 8-dec-03, at 22:01, Jeroen Massar wrote:

> There are currently quite some ISP's who filter anything >/35.
> Generally ISP's should be filtering on allocation boundaries.
> Thus if a certain prefix is allocated as a /32, they should not
> be accepting anything smaller (/33, /34 etc)
So how are ISPs supposed to know what the allocation size for a 
particular prefix is? This type of filtering only works if the filter 
list is relatively short and pretty much never changes. Anything else 
and the cure is worse than the disease.

> I would applaud a generic /32 that is 'allowed' to being cut up
> into multiple /48's for the purpose of critical infrastructure.
> But please, keep it to 1 *documented* /32. That way people will
> know that they will see more specifics from that prefix and that
> they should be accepting it too.
I'm not sure if it needs to be a /32 or if it needs to be just a single 
one, but I fully agree this should be documented very well and in a 
central place. Buried somewhere on a RIR website isn't good enough. 
(Try finding the the micro allocation list on the ARIN site without 
help from Google.)

I think this means it must be an RFC. RIR documents just don't have the 
same standing in the community, and, apparently, quality control.

> Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 
> 2001:7fa::/32)
> are seen being announced in pieces too. Maybe these IX blocks, which
> are common already could be used for assigning 'critical infra' from?
Note that announcing the actual prefix for an internet exchange subnet 
tickles an undesirable BGP feature in places where the prefix isn't 
filtered, so these prefixes are best not announced. The allocations 
seem to be /48s and not /64s though, so in practice this shouldn't be a 
problem but still no reason why these should be globally visible.

Root nameservers are a very different story of course...