[89173] in North American Network Operators' Group
Re: shim6 @ NANOG
daemon@ATHENA.MIT.EDU (Kevin Day)
Sat Mar 4 08:08:11 2006
In-Reply-To: <A32D7FA8-4A8A-4374-8437-9E27A38AD1E6@muada.com>
Cc: Stephen Sprunk <stephen@sprunk.org>,
North American Noise and Off-topic Gripes <nanog@merit.edu>
From: Kevin Day <toasty@dragondata.com>
Date: Sat, 4 Mar 2006 07:07:48 -0600
To: Iljitsch van Beijnum <iljitsch@muada.com>
Errors-To: owner-nanog@merit.edu
On Mar 4, 2006, at 2:21 AM, Iljitsch van Beijnum wrote:
>
>> ... 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.
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." 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)
-- Kevin