North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: shim6 @ NANOG
On Mar 4, 2006, at 2:21 AM, Iljitsch van Beijnum wrote:
Isn't that an excellent argument against shim6 though?... which is what I expect to happen. A few folks will see it coming, design a fix, and everyone will deploy it overnight when they discover they have no other choice. Isn't that about what happened with CIDR, in a nutshell?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.
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." Eventually all hosts got CIDR routing, but it didn't break anything if you didn't.
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.
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. 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.
I don't think (many) operators are really dreading having to eventually and slowly upgrade their DFZ routers to support 32 bit ASNs. It'll require an OS upgrade, probably an upgrade to a few tools (netflow parsers, etc), but nothing customer impacting. There will be a crossover period where the software will be available but no 32-bit ASNs will be visible, until one day some unlucky sap gets AS65536 and guinea-pigs the internet. It's a networking problem being solved by the guys who run the network, and it can get done in a reasonable timeframe, without bothering end users, other departments or touching boxes outside the network admin's control.
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. A parallel to that is going to still be happening in the next 4-8 years when shim6 would have to prove itself. There are going to be enterprises, end users, database servers, and embedded devices that have IPv6 support because they shipped with it (XP, Vista, OS X, Solaris, etc), but don't have shim6 support. The services either get an expensive upgrade or lose out on multihoming.
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.
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.) ARIN's policy is that you should use name based hosting wherever possible. However, if you're not using name based hosting(blowing through many IPs that could be consolidated if you didn't), all that's asked is that you justify why you can't/won't do it that way on your application for PI space. If IPv6 PI space worked the same way - 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. Let those who want to use it use it, and let those who can't do what they need to do use the existing alternatives. People aren't going to frivolously pay the yearly fees for an ASN and address space unless they truly believe they need it, and it would completely level the playing field. Small businesses won't have an unfair disadvantage to their larger competitors who get PI space. Let shim6 (or whatever takes its place for IPv6 multihoming) prove itself and seem like a more attractive solution than paying for PI space, and you have a winner.
No matter how much you think shim6 is the way to do it, you're not going to have willing users of it unless it's just as good as what they're doing now. 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. 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. Nothing at all precludes allowing people to start deploying multihomed IPv6 networks using the traditional system, and presenting alternatives when they've proven themselves. If shim6 truly is the perfect match for people who need to multihome, new networks will deploy it natively, and small companies will accept it as a way to stop paying a yearly fee for PI/ASN allocations. If you're not so sure that shim6 meets the "it's good enough that people will use it willingly" goal, it's not going to work to mandate its use by policy.
Right now, shim6 isn't even completed. There are networks who could be convinced to start deploying IPv6 today, if they had a multihoming solution. Let them do this! The sooner we get people publishing AAAA records, the smoother the transition is going to be for everyone. I really don't want to see the state of the internet if IPv4 is exhausted and IPv6 is still being shot down because of policy debates.
(Again, my organization already has a /32, I'm not out anything with the current policies, if anything I'm helping my competition by arguing this point)