shim6 @ NANOG

Sun Mar 5 19:16:20 UTC 2006

> 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.
> 
It flies if you look at changing the routing paradigm instead of pushing
routing decisions out of the routers and off to the hosts.  Source Routing
is a technology that most of the internet figured out is problematic
years ago.  Making source routing more complicated and calling it something
else doesn't make it less of a bad idea.

>> 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.
> 
Sure, it's really easy to test shim6 between two hosts without involving
the internet.  I'll buy that.  I'm not sure what the benefit of that is
supposed to be to the average end user, but, I can accept that as a reason
that developers of shim6 might like it.

> But again, it cuts both ways: if only two people run shim6 code,  those
> two people gain shim6 benefits immediately.
> 
Only to the extent that they are talking to each other.  If I deploy shim6,
but, the top 5000 web sites that my users need to talk to do not, then,
there's no benefit whatsoever to shim6 to the majority of my users.

> 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.
> 
That's a small step in the right direction.  Looking at the possibility
to change the fundamental routing paradigm for interdomain routing
is probably a better possibility.  Of course, these options are not
technically mutually exclusive, but, I think the latter will be actually
easier to deploy and yield greater benefit.

>> 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.
> 
A good PI policy is easy.  Coming up with a scalable routing solution
that supports good PI policy is hard.  That's what we should be working
on.  A good PI policy is "If you need PI space, you get it."  What
we are trying to come up with in the meantime is a PI policy that will
meet the needs of the majority of users while somewhat constraining
growth in the routing table until that problem can be solved.
(At least that's my intent with 2005-1)

>> 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.)
> 
Yeah, and it worked right up to the point that SSL became improtant
and then it pretty much went away as a practical matter.

> 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.
> 
And you think it won't be years before shim6 provides tangible benefits?
You're dreaming.

> 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.
> 
There were ways of handling this for NBVH initially too.

>> 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.
> 
I would argue that you are putting the cart before the horse in this case.
The solution must be sufficiently adequate that users do not feel the
need to create routing table growth, or, the solution must be considered
insufficient.

>> 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.
> 
IPv4 addresses are not hard to get.  Portable IPv4 addresses are relatively
harder to get than they should be, but, Portable IPv6 addresses are even
harder to get than portable IPv4 addresses.  People aren't turning to IPv6
because as things stand right now, it's harder to deploy and presents even
less value than IPv4.  The lack of PI space availability in IPv6 is one
of the reasons for this.  The lack of ISPs providing native v6 routing
is another.  The higher cost of IPv6 address space is a third.  So far,
from a business perspective, IPv6 is all cost and no benefit compared
to IPv4.

> 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 don't think it will be as expensive as you think to fix it.  I think if
we start working on a new routing paradigm today in order to support IDR
based on AS PATH instead of Prefix, we would realistically see this in
deployable workable code within 3-5 years.  I think that we would see
reasonable deployment in less than 10 years.  I think that if we have this
routing paradigm ready before the routing table starts to "overflow", we
will see an accelerated adoption of this routing paradigm, much like the
deployment of CIDR.  Further, this routing paradigm would only need to
be deployed on DFZ routers, which is a much smaller subset of more
frequently updated hosts than the end-nodes.

>> 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.

It is not clear that IPv6 is inevitable.  In fact, at this point, it's not
even clear that IPv6 has any long term viability at all.  As it stands right
now, for most situations, IPv4 with NAT is more desirable than IPv6.
For servers, IPv4 remains more desirable until addresses start becoming
prohibitively expensive (I think we are at least 15 years from that point).
A lot can happen in 15 years, but, unless we start addressing the real
end user requirements in IPv6 instead of continuing to focus on ways
to extend CIDR and keep it alive (am I the only one who remembers that
CIDR was originally viewed as a gross hack that was temporarily necessary
until we came up with a real solution in IPv6?) I think that IPv6 will
remain less than desirable.  So, I accept that eventually, IPv6 may become
unavoidable, but, I'd rather see it become desirable.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20060305/6e370589/attachment.sig>