Re: shim6 @ NANOG

[Iljitsch van Beijnum <iljitsch () muada com>]

On 4-mrt-2006, at 14:07, Kevin Day wrote:

> > We got lucky with CIDR because even though all default free  
> > routers had to be upgraded in a short time, it really wasn't that  
> > painful.

[Because there was no need to renumber]

> Isn't that an excellent argument against shim6 though?

> In IPv4, something unanticipated occurred by the original developers 
> (the need for CIDR), and everyone said "Oh, thank god that all we  
> have to do is upgrade DFZ routers."

You are absolutely right that having to upgrade not only all hosts in  
a multihomed site, but also all the hosts they communicate with is an  
important weakness of shim6. We looked very hard at ways to do this  
type of multihoming that would work if only the hosts in the  
multihomed site were updated, but that just wouldn't fly.

> In IPv6/shim6 what happens if shim6 has an unanticipated  
> bottleneck, security issue, or scaleability problem? Everyone,  
> everywhere, has to upgrade at some point. This means that upgrade/ 
> workaround has to backwards compatible indefinitely, since it isn't  
> going to be possible to force all the world's servers, desktops and  
> devices to upgrade by some flag day.

That's why it's extremely important to get it right the first time.  
On the other hand, the fact that shim6 works between just two hosts  
without having to upgrade the whole internet first makes it a lot  
easier to test and work out the kinks.

> If it requires an OS update to add a feature, you can't rely on  
> having 90% penetration within YEARS of it being released. After XP  
> Service Pack 2 was released, only 24% had upgraded after 9 months.  
> According to one of our website's stats, we still see 5% of our  
> users on Windows 98, and 13% on Windows 2000.

Yes, this is an issue. If we have to wait for a major release or even  
a service pack, that will take some time. But OS vendors have  
software update mechanisms in place so they could send out shim6 code  
in between.

But again, it cuts both ways: if only two people run shim6 code,  
those two people gain shim6 benefits immediately.

> Getting systems not controlled by the networking department of an  
> organization upgraded, when it's for reasons that are not easily  
> visible to the end user, will be extraordinarily difficult to start  
> with. Adding shim6 at all to hosts will be one fight. Any upgrades  
> or changes later to add features will be another.

One thing I'll take away from these discussions is that we should  
redouble our efforts to support shim6 in middleboxes as an  
alternative for doing it in individual hosts, so deployment can be  
easier.

> In an enterprise environment, you're not talking the DBA of your  
> Oracle box into installing service packs, upgrades or new software  
> just because you want to use a new routing feature that wasn't  
> around when their OS was released. I know of several enterprises  
> still running NT 4.0 and Mac OS 9 boxes for some legacy applications.

Ah, but in the world of shim6 "legacy" takes on a whole new meaning,  
because it relates to today's IPv6 which the OSes you mention don't  
even implement.  (-:

And don't forget that in enterprises, most boxes don't talk directly  
(or at least not much) to the outside world.

> The real "injustice" about this is that it's creating two classes  
> of organizations on the internet. One that's meets the guidelines  
> to get PI space, multihomes with BGP, and can run their whole  
> network(including shim6less legacy devices) with full redundancy,  
> even when talking to shim6 unaware clients. Another(most likely  
> smaller) that can't meet the rules to get PI space, is forced to  
> spend money upgrading hardware and software to shim6 compatible  
> solution or face a lower reliability than their bigger competitors.

And that's exactly why it's so hard to come up with a good PI policy:  
you can't just impose an arbitrary limit, because that would be anti- 
competitive.

> Someone earlier brought up that a move to shim6, or not being able  
> to get PI space was similar to the move to name based vhosting(HTTP/ 
> 1.1 shared IP hosting). It is, somewhat. It was developed to allow  
> hosting companies to preserve address space, instead of assigning  
> one IP address per hostname. (Again, however, this could be done  
> slowly, without forcing end users to do anything.)

Tthis isn't that good an analogy. With name based virtual hosting,  
the server either is name based or IP based. If you run name based,  
old HTTP 1.0 clients won't be served the content they're looking for.  
So people running servers had to wait until a large enough percentage  
of users ran clients that supported HTTP 1.1 (or HTTP 1.0 with the  
host: variable). Fortunately, there was a browser war on at that time  
so people upgraded their web browser software relatively often, but  
it still took a few years before name based virtual hosting became  
viable.

Shim6 is completely backward compatible. If either end doesn't  
support the protocol, everything still works, but without multihoming  
benefits of course. So everyone can enable shim6 as soon as their OS  
supports it with no ill effects.

> If you could justify why shim6 isn't sufficient for your network,  
> and receive PI space... I'd have zero objections to anything shim6  
> wanted to do.

Actually that's not the worst idea ever. The main problem would be  
coming objective criteria that determine shim6-insufficientness and  
of course the bar must be sufficiently high that we don't have to  
worry about excessive numbers of PI prefixes in the IPv6 global  
routing table.

> Unless we start now working on getting people moved to IPv6, the  
> pain of running out of IPv4 before IPv6 has reached critical mass  
> is going to be much much worse than a long term problem of IPv6  
> route size.

I disagree. You assume that IPv6 will be able to gain critical mass  
before IPv4 addresses run out. I don't think that will happen,  
because of the chicken/egg problem. "Running out" is a relative term.  
John Klensin says we've effictively already run out because IPv4  
addresses are too hard to get for some applications. That may be true  
but people aren't turning to IPv6 (yet) to run those applications. My  
prediction is that we'll see interesting things happen when the  
remaining IPv4 address suppy < 3 * addresses used per year. That will  
probably happen around the end of this decade. At that point, there  
is likely to be hoarding and/or the allocation policies will become  
stricter, and people will start to think about a future where it's no  
longer possible to get IPv4 addresses. At this point, there will  
still be time to migrate.

If we screw up the routing table real good on the other hand, we're  
in trouble immediately and it will be both expensive to do nothing  
and to fix it.

> The question of IPv6 migration and IPv6 route size are *two  
> different problems*. Solve them independently or neither will get  
> solved. We can't try to force our views of how the internet should  
> work on networks when we've already got a fight on our hands just  
> convincing them to deploy IPv6 at all.

I see this differently: as long as people are postponing deployment,  
we have the opportunity to improve IPv6 without too much trouble. So  
not having significant deployment isn't such a bad thing, as long as  
it's clear that IPv6 is inevitable. As long as we're debating whether  
IPv6 will be deployed at all we're wasting time. In another year or  
maybe two that debate will probably be over, though.