|
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]
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,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. 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:I see no reason why this will lead to the filtering of all IPv6 /48's. [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.
|