[89184] in North American Network Operators' Group
Re: shim6 @ NANOG
daemon@ATHENA.MIT.EDU (Matthew Petach)
Sat Mar 4 16:32:20 2006
Date: Sat, 4 Mar 2006 13:31:44 -0800
From: "Matthew Petach" <mpetach@netflight.com>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>
Cc: "North American Noise and Off-topic Gripes" <nanog@merit.edu>
In-Reply-To: <8B1FA1CF-4BEF-442A-9158-334B4EAE025E@muada.com>
Errors-To: owner-nanog@merit.edu
------=_Part_18153_15232690.1141507904773
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On 3/4/06, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
> 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.
And given that any network big enough to get their own PI /32 has *zero*
incentive to install/support shim6 means that all those smaller networks
that are pushed to install shim6 are going to see *zero* benefit when they
try to reach the major sites on the internet.
What benefit does shim6 bring, if only the little guys are using it?
This dog won't hunt. Move on to something useful.
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.
And no major company supports/allows automated software update
mechanisms to run on their production machines--it adds too much
of an element of randomness to an environment that has to be as much
as possible deterministic in its behaviour.
But again, it cuts both ways: if only two people run shim6 code,
> those two people gain shim6 benefits immediately.
Cool. So let individuals make a choice to install it if they want. But
that's a choice they make, and should not be part of a mandated IP
allocation policy, because otherwise we're codifying a split between
"big" companies and everyone else. The companies that can justify /32
allocations _aren't_ going to install shim6; they already have their
multihoming options (for the most part) covered--so the little guys who
install shim6 to "multihome" are going to discover it doesn't do diddly
squat for helping them reach any major sites on the internet during an
outage of one of their providers. You haven't preserved end-to-end
connectivity this way, you've just waved a pretty picture in front of the
smaller company's face to make them think they'll have the benefits of
multihoming when they really don't.
> 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.
Won't matter. shim6 on a middle box still won't be able to re-route to the
majority of the large sites on the Internet during an outage on one of the
upstream providers given that the large content players and large network
providers aren't going to be installing shim6 on their servers and load
balancers.
> 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.
You failed to note that the smaller company, *even after spending money
upgrading hardware and software to shim6 compatible solution* won't achieve
the same reliability as their bigger competitors. (see above if you missed
it).
shim6 is _more_ anti-competitive than extending the existing IP allocation
policies from v4 into v6, and is therefore not going to garner the support
of
the companies that actually spend money to create this thing we call the
Internet. And without money behind it, the effort is a non-starter.
> 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.
But the smaller sites who enable shim6 don't gain any benefit when
talking to the large sites on the internet--so they've gone through a lot
of pain and effort for very little actual benefit, since they still aren't
usefully multihomed. There's just no real benefit to shim6 unless you
require *EVERY* site to support it; and I can tell you that the large
content sites will simply stay on v4 rather than install the complexity
that is shim6 on their production webservers.
> 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.
Consolidation will likely occur; those that need address space will
find that buying less-fortunate companies in order to swallow their
address space will become a normal, understood part of their
business planning cycle. Competition will decrease, and the shift
towards larger and larger companies will ensue, as smaller players
gobble each other up in order to become large enough such that
any needed migration to IPv6 can happen directly onto a PI /32.
If we persist on following this path, we'll simply end up in a world
where the large entities control the resources, and the barriers for
entry turn out to be the very ones we set up in our own well-meaning
bumbling.
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.
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.
> 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.
IPv6 may be inevitable; but the way shim6 is pushing allocation policies,
it will be in a world in which only big players multihome, and everyone els=
e
must buy from a big player and won't get to multihome. Yes, people will
wave the shim6 flag around to make small startups think they can multihome
and pretend to be a big player, but at the first outage, the little guy wil=
l
discover
his multihoming is a facade, and that none of the major sites on the
Internet
that he wants to talk to are interested in playing his shim6 games with his
end
hosts--and his customers will quickly realize that any independance from th=
e
upstream networks is all smoke and mirrors, and not worth the paper such
claims may be printed upon.
If that's the direction we're heading, let's just stop beating around the
bush and
say it plainly: Shim6 is just a handwaving panacea to make the smaller
enterprises shut up and stop obstructing v6 deployment for the short term s=
o
that we can get more critical mass on the v6 networks and maybe justify
getting
some of the large players to start making useful material available via v6
which
might finally show a few dollars of real revenue flowing due to v6
deployments.
But it's insulting to keep pretending that shim6 is going to offer any leve=
l
of
real multihoming-style reliability benefit for the smaller players when
talking to
engineers. Save it for the marketing literature for the customers.
Matt
------=_Part_18153_15232690.1141507904773
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On 3/4/06, <b class=3D"gmail_sendername">Iljitsch van Beijnum</b> <<a hr=
ef=3D"mailto:iljitsch@muada.com">iljitsch@muada.com</a>> wrote:<div><spa=
n class=3D"gmail_quote"></span><br><blockquote class=3D"gmail_quote" style=
=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p=
adding-left: 1ex;">
On 4-mrt-2006, at 14:07, Kevin Day wrote:<br><br>>> We got lucky with=
CIDR because even though all default free<br>>> routers had to be up=
graded in a short time, it really wasn't that<br>>> painful.<br><br>
[Because there was no need to renumber]<br><br>> Isn't that an excellent=
argument against shim6 though?<br><br>> In IPv4, something unanticipate=
d occurred by the original developers<br>> (the need for CIDR), and ever=
yone said "Oh, thank god that all we
<br>> have to do is upgrade DFZ routers."<br><br>You are absolutely=
right that having to upgrade not only all hosts in<br>a multihomed site, b=
ut also all the hosts they communicate with is an<br>important weakness of =
shim6. We looked very hard at ways to do this
<br>type of multihoming that would work if only the hosts in the<br>multiho=
med site were updated, but that just wouldn't fly.</blockquote><div><br>And=
given that any network big enough to get their own PI /32 has *zero*<br>
incentive to install/support shim6 means that all those smaller networks<br=
>that are pushed to install shim6 are going to see *zero* benefit when they=
<br>try to reach the major sites on the internet.<br><br>What benefit does =
shim6 bring, if only the little guys are using it?
<br><br>This dog won't hunt. Move on to something useful.<br><br></di=
v><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yes, this i=
s an issue. If we have to wait for a major release or even
<br>a service pack, that will take some time. But OS vendors have<br>softwa=
re update mechanisms in place so they could send out shim6 code<br>in betwe=
en.</blockquote><div><br>And no major company supports/allows automated sof=
tware update
<br>mechanisms to run on their production machines--it adds too much <br>of=
an element of randomness to an environment that has to be as much<br>as po=
ssible deterministic in its behaviour.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt =
0pt 0pt 0.8ex; padding-left: 1ex;">
But again, it cuts both ways: if only two people run shim6 code,<br>those t=
wo people gain shim6 benefits immediately.</blockquote><div><br>Cool. =
So let individuals make a choice to install it if they want. But<br>=
that's a choice they make, and should not be part of a mandated IP
<br>allocation policy, because otherwise we're codifying a split between<br=
>"big" companies and everyone else. The companies that can =
justify /32<br>allocations _aren't_ going to install shim6; they already ha=
ve their
<br>multihoming options (for the most part) covered--so the little guys who=
<br>install shim6 to "multihome" are going to discover it doesn't=
do diddly<br>squat for helping them reach any major sites on the internet =
during an
<br>outage of one of their providers. You haven't preserved end-to-en=
d<br>connectivity this way, you've just waved a pretty picture in front of =
the<br>smaller company's face to make them think they'll have the benefits =
of
<br>multihoming when they really don't.<br><br></div><br><blockquote class=
=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin=
: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Getting systems not controlle=
d by the networking department of an
<br>> organization upgraded, when it's for reasons that are not easily<b=
r>> visible to the end user, will be extraordinarily difficult to start<=
br>> with. Adding shim6 at all to hosts will be one fight. Any upgrades
<br>> or changes later to add features will be another.<br><br>One thing=
I'll take away from these discussions is that we should<br>redouble our ef=
forts to support shim6 in middleboxes as an<br>alternative for doing it in =
individual hosts, so deployment can be
<br>easier.</blockquote><div><br><br>Won't matter. shim6 on a middle =
box still won't be able to re-route to the<br>majority of the large sites o=
n the Internet during an outage on one of the<br>upstream providers given t=
hat the large content players and large network
<br>providers aren't going to be installing shim6 on their servers and load=
<br>balancers.<br><br></div><blockquote class=3D"gmail_quote" style=3D"bord=
er-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-l=
eft: 1ex;">
> The real "injustice" about this is that it's creating two cl=
asses<br>> of organizations on the internet. One that's meets the guidel=
ines<br>> to get PI space, multihomes with BGP, and can run their whole
<br>> network(including shim6less legacy devices) with full redundancy,<=
br>> even when talking to shim6 unaware clients. Another(most likely<br>=
> smaller) that can't meet the rules to get PI space, is forced to<br>
> spend money upgrading hardware and software to shim6 compatible<br>>=
; solution or face a lower reliability than their bigger competitors.<br><b=
r>And that's exactly why it's so hard to come up with a good PI policy:
<br>you can't just impose an arbitrary limit, because that would be anti-<b=
r>competitive.</blockquote><div><br>You failed to note that the smaller com=
pany, *even after spending money<br>upgrading hardware and software to shim=
6 compatible solution* won't achieve
<br>the same reliability as their bigger competitors. (see above if y=
ou missed it).<br><br>shim6 is _more_ anti-competitive than extending the e=
xisting IP allocation<br>policies from v4 into v6, and is therefore not goi=
ng to garner the support of
<br>the companies that actually spend money to create this thing we call th=
e<br>Internet. And without money behind it, the effort is a non-start=
er.<br><br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1p=
x solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Someone earlier brought up that a move to shim6, or not being able<br>=
> to get PI space was similar to the move to name based vhosting(HTTP/<b=
r>> 1.1 shared IP hosting). It is, somewhat. It was developed to allow
<br>> hosting companies to preserve address space, instead of assigning<=
br>> one IP address per hostname. (Again, however, this could be done<br=
>> slowly, without forcing end users to do anything.)<br><br>Tthis isn't=
that good an analogy. With name based virtual hosting,
<br>the server either is name based or IP based. If you run name based,<br>=
old HTTP 1.0 clients won't be served the content they're looking for.<br>So=
people running servers had to wait until a large enough percentage<br>
of users ran clients that supported HTTP 1.1 (or HTTP 1.0 with the<br>host:=
variable). Fortunately, there was a browser war on at that time<br>so peop=
le upgraded their web browser software relatively often, but<br>it still to=
ok a few years before name based virtual hosting became
<br>viable.<br><br>Shim6 is completely backward compatible. If either end d=
oesn't<br>support the protocol, everything still works, but without multiho=
ming<br>benefits of course. So everyone can enable shim6 as soon as their O=
S
<br>supports it with no ill effects.</blockquote><div><br>But the smaller s=
ites who enable shim6 don't gain any benefit when<br>talking to the large s=
ites on the internet--so they've gone through a lot<br>of pain and effort f=
or very little actual benefit, since they still aren't
<br>usefully multihomed. There's just no real benefit to shim6 unless=
you<br>require *EVERY* site to support it; and I can tell you that the lar=
ge <br>content sites will simply stay on v4 rather than install the complex=
ity
<br>that is shim6 on their production webservers.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); m=
argin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> If you could justify why=
shim6 isn't sufficient for your network,
<br>> and receive PI space... I'd have zero objections to anything shim6=
<br>> wanted to do.<br><br>Actually that's not the worst idea ever. The =
main problem would be<br>coming objective criteria that determine shim6-ins=
ufficientness and
<br>of course the bar must be sufficiently high that we don't have to<br>wo=
rry about excessive numbers of PI prefixes in the IPv6 global<br>routing ta=
ble.<br><br>> Unless we start now working on getting people moved to IPv=
6, the
<br>> pain of running out of IPv4 before IPv6 has reached critical mass<=
br>> is going to be much much worse than a long term problem of IPv6<br>=
> route size.<br><br>I disagree. You assume that IPv6 will be able to ga=
in critical mass
<br>before IPv4 addresses run out. I don't think that will happen,<br>becau=
se of the chicken/egg problem. "Running out" is a relative term.<=
br>John Klensin says we've effictively already run out because IPv4<br>
addresses are too hard to get for some applications. That may be true<br>bu=
t people aren't turning to IPv6 (yet) to run those applications. My<br>pred=
iction is that we'll see interesting things happen when the<br>remaining IP=
v4 address suppy < 3 * addresses used per year. That will
<br>probably happen around the end of this decade. At that point, there<br>=
is likely to be hoarding and/or the allocation policies will become<br>stri=
cter, and people will start to think about a future where it's no<br>longer=
possible to get IPv4 addresses. At this point, there will
<br>still be time to migrate.</blockquote><div><br>Consolidation will likel=
y occur; those that need address space will<br>find that buying less-fortun=
ate companies in order to swallow their<br>address space will become a norm=
al, understood part of their
<br>business planning cycle. Competition will decrease, and the shift=
<br>towards larger and larger companies will ensue, as smaller players<br>g=
obble each other up in order to become large enough such that<br>any needed=
migration to IPv6 can happen directly onto a PI /32.
<br><br>If we persist on following this path, we'll simply end up in a worl=
d<br>where the large entities control the resources, and the barriers for<b=
r>entry turn out to be the very ones we set up in our own well-meaning<br>
bumbling.<br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-l=
eft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:=
1ex;">If we screw up the routing table real good on the other hand, we're<=
br>
in trouble immediately and it will be both expensive to do nothing<br>and t=
o fix it.</blockquote><div><br><br>I have more faith in our ability to deal=
with route table growth than I do <br>in our ability to come up with a via=
ble instantiation of shim6.
<br> </div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px =
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&g=
t; The question of IPv6 migration and IPv6 route size are *two<br>> diff=
erent problems*. Solve them independently or neither will get
<br>> solved. We can't try to force our views of how the internet should=
<br>> work on networks when we've already got a fight on our hands just<=
br>> convincing them to deploy IPv6 at all.<br><br>I see this differentl=
y: as long as people are postponing deployment,
<br>we have the opportunity to improve IPv6 without too much trouble. So<br=
>not having significant deployment isn't such a bad thing, as long as<br>it=
's clear that IPv6 is inevitable. As long as we're debating whether<br>
IPv6 will be deployed at all we're wasting time. In another year or<br>mayb=
e two that debate will probably be over, though.</blockquote><div><br><br>I=
Pv6 may be inevitable; but the way shim6 is pushing allocation policies,
<br>it will be in a world in which only big players multihome, and everyone=
else<br>must buy from a big player and won't get to multihome. Yes, =
people will<br>wave the shim6 flag around to make small startups think they=
can multihome
<br>and pretend to be a big player, but at the first outage, the little guy=
will discover<br>his multihoming is a facade, and that none of the major s=
ites on the Internet<br>that he wants to talk to are interested in playing =
his shim6 games with his end
<br>hosts--and his customers will quickly realize that any independance fro=
m the<br>upstream networks is all smoke and mirrors, and not worth the pape=
r such<br>claims may be printed upon.<br><br>If that's the direction we're =
heading, let's just stop beating around the bush and
<br>say it plainly: Shim6 is just a handwaving panacea to make the sm=
aller<br>enterprises shut up and stop obstructing v6 deployment for the sho=
rt term so<br>that we can get more critical mass on the v6 networks and may=
be justify getting
<br>some of the large players to start making useful material available via=
v6 which<br>might finally show a few dollars of real revenue flowing due t=
o v6 deployments.<br><br>But it's insulting to keep pretending that shim6 i=
s going to offer any level of
<br>real multihoming-style reliability benefit for the smaller players when=
talking to<br>engineers. Save it for the marketing literature for th=
e customers.<br><br>Matt<br><br><br><br><br></div><br></div><br>
------=_Part_18153_15232690.1141507904773--
