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

Fri Mar 3 19:23:20 UTC 2006

Thus spake "Iljitsch van Beijnum" <iljitsch at muada.com>
> 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 