2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]

Thu Mar 2 22:06:52 UTC 2006

On 2-mrt-2006, at 21:42, Andre Oppermann wrote:

> To answer your question: I do support the rationale behind 2005-1
> to allow for PI address space according to current IPv4 rules but
> I think it is premature right now to make the decision in this way.
> Once the first /48 according to it went out we have to support and
> carry it forever in the DFZ.  Right now I'm against 2005-1.

This is in and of itself enough to reject 2005-1, and I urge the ARIN  
constituency to do exactly that. We've had restrictive policies  
around the world for many years now, and so far we've been able to  
live with it. The IETF is making good progress with its multihoming  
in IPv6 efforts: implementable RFCs should be forthcoming within a  
year. Currently, IPv6 deployment is not such that lack of multihoming  
is creating big problems. If this situation changes, a policy  
proposal like this one can presumably be adopted fast enough to avoid  
significant problems.

I've talked long and hard about why it's bad to have nearly  
unrestricted PI in IPv6 because the routing system can't scale  
(either at all or at reasonable cost) to accommodate this, but  
apparently this argument isn't universally convincing among  
operators. However, within the IETF there is reasonable consensus  
that there is enough of a risk to warrant efforts to provide  
multihoming benefits that don't impact routing.

Also, having /48s for PI is a bad choice as it procludes easy  
filtering of accidental deaggregated PA prefixes. ISPs are getting / 
32s or larger, and customers often get a /48. Deaggregating a /32  
into /48s has the potential to increase the global routing table by  
65000 routes. Such an event will almost certainly overload routers  
that don't filter those prefixes out. Experience in IPv4 shows us  
that accidental deaggregation is relatively common. The easiest way  
to avoid problems when this happens is filter out all /48s. Today,  
there must already be exceptions for root server /48s, but as the  
number of exceptions grows the filtes will become more fragile and  
the risk of deaggregation that isn't caught by filters increases.

Finallly, allow me to observe that deciding on this issues regionally  
while the resulting routes must be carried world wide doesn't make  
sense. We really need a global forum for this.