North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Iljitsch van Beijnum
  • Date: Thu Mar 02 17:08:00 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.