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

Fri Mar 3 10:47:15 UTC 2006

On 3-mrt-2006, at 4:54, Marshall Eubanks wrote:

>> 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.

> The IETF is at serious risk of being overtaken by events here, in  
> my humble opinion. I have just returned from China, where there is  
> a serious effort focused on deploying IPv6, and where there are 111  
> million Internet users,
> most with broadband, according to government statistics. I do not  
> think that they and the other people waiting on
> IPv6 are going to wait a decade for this to be sorted out.

There are currently 265 AS numbers assigned in China (9 more than  
what Sweden has) so apparantly multihoming isn't too high on their  
list of priorities.

There haven't been any developments the last few years that warrant  
such a policy change. Yes, some people are saying that they won't  
deploy IPv6 without easy multihoming, but I've yet to hear someone  
say that they WILL deploy IPv6 within a year WITH easy multihoming.  
For instance, Google has had 2001:4860::/32 since april but I've yet  
to see any of their services work over IPv6.

Yes, there are problems with the current policy. For instance, if  
you're a large transit ISP and your customers all have their own  
address space, you're not going to assign address space to them so  
you don't qualify for IPv6 address space. However, it would be nice  
to be able to give your routers addresses. Why not create a policy  
that addresses these issues, rather than try to do a full 180 on  
what's been in place for years?

Last but not least, a /48 isn't going to give large hosting companies  
and large enterprises what they want/need, which is generally  
multiple address blocks for multiple locations. We can debate whether  
deagregating a /32 in IPv6 is going to work well (I say: don't count  
on it), but nobody in their right mind is going to accept prefixes  
longer than a /48.

So this policy will allow creating a swamp in IPv6 and still not  
address the needs it is supposed to address.

>> 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.

> This to be honest sounds like the sort of thing that router vendors  
> would love to build filters for, much like dampening routing flaps  
> or rate limiting MSDP storms.

I don't think creating a potential problem just so vendors can have a  
crack at trying to solve it is a good use of our collective time.

> After all, an ASN going from one address block to 65,000 should be  
> detectable automatically.

Not very easily. It means keeping statistics on the number of  
prefixes per origin AS, which is additional work and additional knobs  
that can be turned into the wrong direction.

> I see no reason why this will lead to the filtering of all IPv6 /48's.

A couple of years ago I discovered that the F root server has an IPv6  
address: 2001:500::1035. This was assigned as a /48 by ARIN even  
though their IPv6 policy (still) says:

[wait wait wait until I fall back to IPv4 because www.arin.net is  
currently unreachable over IPv6]

"6.4.3. Minimum Allocation
RIRs will apply a minimum size for IPv6 allocations, to facilitate  
prefix-based filtering.

The minimum allocation size for IPv6 address space is /32."

The ISP that I used at the time installed prefix length filters  
accordingly so I couldn't reach the F root server over IPv6.

Moral of the story: if you build in a way for people to screw up,  
they'll do it. After that, they'll start throwing out some babies  
with the bath water.