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: Stephen Sprunk
  • Date: Fri Mar 03 14:26:00 2006

Thus spake "Iljitsch van Beijnum" <[email protected]>
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's a general lack of competition over there; remember, it's a communist country, not a capitalist one. If one _wanted_ to multihome in China, there's a limited business possibility of doing so. That's changing slowly, but it's still the reality today.

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.
That's particularly telling. Of all companies, I'd have expected Google to go IPv6 long before there was a compelling business reason. It'd be interesting to hear from someone there why they haven't rolled it out yet.

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?
Current ARIN policy allows assigning a /32 to an LIR if they're merely "a known ISP in the ARIN region". The 200 site requirement is only for new entrants to the ISP world, or for enterprises that want to pretend to be an LIR.

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.
I'm not sure it'll create a swamp, but at least one (I don't have both in front of me) of the proposals allows for assignment of a shorter prefix if it is justified. One could make a reasonable case that announcing /48s in four locations justifies a /46 (or even /45).

Conversely, one could convince their upstream(s) to accept longer prefixes as long as they're tagged no-export. That keeps the routing tables at other ISPs to a minimum, but still gets you the majority of the benefit of deaggregating.

Either way, be sure to announce the agregate in all locations as well.

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.
This is why we've proposed assigning mainly /48s to end-user orgs: ISPs can easily filter at the /48 boundary. These assignments should be out of a single block, which would make it easy for ISPs to set different limits on the PI block (just like the microallocation block(s)) and, if necessary, drop all routes from it if it actually turns into a swamp.

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 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.
There's a different policy for IPv6 microallocations, and your ISP messed up by not noticing it. Not surprising given how little time and attention folks have been spending on IPv6 to date.


Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin