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]
Thus spake "Iljitsch van Beijnum" <[email protected]>
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.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.
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.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.
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.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.
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.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.
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