shim6 @ NANOG

Mon Mar 6 12:38:53 UTC 2006

On 5-mrt-2006, at 20:38, Matthew Petach wrote:

> Hotmail runs shim6 so that multihomed Hotmail users can keep sending
> mail even when one ISP fails, while Gmail doesn't?

> The customers who can't reach gmail will call their ISP to complain  
> about
> the Internet being broken.  They're not going to call Google and  
> ask why
> they aren't installing/configuring shim6 on 150,000+ servers.  This is
> observable today, and is not a matter of conjecture.

People who go through the expense of adding a second ISP are likely  
to be a bit more clueful than that, especially when they see that  
Gmail doesn't work and Hotmail does.

> I think the trend has been pretty clear thus far--large networks/ 
> large providers
> have been getting PI /32 allocations in order to be able to  
> multihome in v6 in
> the same way they multihome in v4 today.  And for those  
> organizations that
> today have multiple locations that aren't connected but still need  
> to talk to the
> Internet, they have separate v4 allocations and separate ASNs

Some of them, certainly. But others use one AS number and one prefix  
and break the prefix into smaller pieces that are announced from  
different locations.

> Installing shim6 will not provide companies with the
> same level of redundancy that multihoming with PI space provides in  
> the
> IPv4 world today,

In a world where most hosts are shim-capable it would.

It doesn't buy you fast and painless provider switching that having  
your own PI block does, but that's another issue.

> In case you've never had to discuss network upgrades/conversions/ 
> migrations
> with executives before, the answer to any proposal that increases  
> the risk to
> the company's business without clear benefits that well exceed the  
> added risk
> is "NO".

Letting business people make engineering decisions is not a good  
idea, just like having engineers make business decisions. If the risk  
is too great, just let them wait and the risk will become smaller.  
And that's exactly what they're doing anyway.

> 2 million prefixes in a router that supports 1 million is also a non-
> starter.

> And in 1996, we would have said 200,000 prefixes in a router that
> supports 100,000 is a non-starter.  And yet here we are, with everyone
> in the core holding 200,000 prefixes without complaint.

> 2 million prefixes in a router that supports 1 million is a non- 
> starter
> *today*;

No, it's a non-starter ALWAYS. The only variables are whether routers  
of the required capacity are available and if so, how much they cost.  
I think the only time that routing table size wasn't a consideration  
when buying routers for me and my customers was a few years around  
2000 when a Cisco 7200 was fast enough to handle the required amounts  
of traffic, supported memory to do full routing and was affordable  
with regard to revenues in the internet business as I knew/know it (=  
in the Netherlands). Before that, a C7200 was too expensive for many  
ISPs that I knew and these days, traffic volumes are such that you  
really need something with hardware support but then you either have  
cheap multilayer switches that can't do full routing or routers that  
are too expensive for small ASes.

> Routing table growth is more limited by the ability of entities to get
> physical links installed, obtain an AS, and learn how to spell BGP
> than it is by our allocation policies.

Conjecture.

> Yes, someday we'll get to
> 2 million prefixes, as more people learn to speak BGP, and purchasing
> multiple physical links becomes cheaper.  But it won't be  
> overnight, and
> routers will continue to scale, as they have from the CIDR crisis  
> of the 90's
> to our IPv6 non-crisis of today.

There is no way of knowing that. Moore's Law certainly appeared to be  
in bad shape a few years back as the traditional process shrinking in  
the chip industry hit some walls. We're back on track now, but  
there's no telling what will happen in the future.

IPv4 has been in operation for 25 years now. Let me be generous and  
assume that the switch to IPv6 happens 5 years from now. With more  
and more stuff connected to networks the switch to IPv7 isn't going  
to be faster than the one from v4 to v6, so IPv6 will have to last  
for at least 30 years like IPv4 before it. So we have to make certain  
that what we do today still works in 2041. That is a LONG time to  
keep doubling performance every 18 months.

> Now, for the rest of us, let's move on to draft a useful allocation  
> strategy
> that allows for PI multihoming in IPv6 in the same way companies  
> are able
> to do so in the IPv4 world.

Bad idea.

> If we aren't comfortable doing that, then let's draft
> up the terms of the market economy that will develop in buying and  
> selling IPv4
> addresses as the pool runs dry

If you're happy with that as an alternative for PI in IPv6, then go  
right ahead. Personally, I don't like the idea of organizations who  
got a /8 now reaping huge benefits from that and the moment this is  
seriously suggested you can forget about anyone giving back address  
space voluntarily, but if that's what it takes, fine by me.

> > I have more faith in our ability to deal with route table growth
> > than I do in our ability to come up with a viable instantiation  
> of shim6.

> Engineering based on faith is insane. Even with today's science we
> have balconies falling off of appartment buildings and roofs
> collapsing when it rains or snows a bit harder than usual, so a
> little caution here and there isn't too much to ask for.

> And engineering based on FUD is equally insane.  Designing a bridge
> for a two-lane country highway to support 20,000 ton loads "because
> someday someone might want to drive a cavalcade of dump trucks
> packed to overflowing with ozmium across it" is ridiculous, and won't
> get you funding.  Engineers plan for reasonable safety margins, and
> then post the safe operating loads.

Right. And that's why your analogy doesn't work. It's more like  
building a bridge that can handle 20000 tons and then it turns out  
people really like to live on the bridge (for some reason, good  
analogies are hard...). Some people then say, fine, as long as you  
use trailers or similar mobile homes so you can move them off the  
bridge when necessary. Others say: go ahead, just build houses, when  
the load increases we'll just reinforce the bridge. Obviously this  
will work for a while but at some point you'll have a complete city  
on the bridge and all the economic activity draws more and more new  
people that the reinforcement efforts can no longer support. At this  
point, moving off the bridge becomes incredibly painful but there's  
no easy way out anymore.

> If you take a rational look at the ASN allocation curve, I think  
> it's clear who is  the real FUD-monger here.  We can safely give  
> out a PI IPv6 allocation to every ASN on the Internet, and not  
> worry about hitting 2 million prefixes any time in the lifespan of  
> our current routers.  Companies that have multiple locations with  
> different AS's today will get a prefix for each AS at each location  
> in IPv6, *and the sky will not fall*.

There are currently some 17k ASes in the US and 265 in China. China  
has about four times the inhabitants of the US. If all the world  
reaches the same amount of multihoming as the US that would be 300k  
ASes today. Between 2000 and 2004 the number of IPv4 addresses given  
out averaged 80 million/year. Last year it was 165 million. We simply  
do not have enough data points to make reasonable projections,  
especially not over the course of 30 years.

The problem with opening a can of worms is that rarely, the worms go  
back into the can. We have to opportunity to start from scratch with  
IPv6, let's not waste this because in our hubris we think we know  
what's going to happen in the future even though we got it wrong so  
many times in the past.