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



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.



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