Re: Death of the Internet - details at 11
2004-01-28 11:05:01
Dave,
Just to pick a small nit or three...
--On Wednesday, 28 January, 2004 07:36 +0900 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
John,
JCK> but the only realistic solution for someone who needs high
JCK> reliability in that environment is multihoming, and there
seems JCK> to be no hope for multihoming of small-scale
networks with IPv4.
There is not much of a solution, today, for either IPv4 _or_
IPv6.
However there are nearly 10 different proposals under
consideration in the IETF, to deal with multihoming. Few are
restricted to IPv4.
or to IPv6, which I assume is what you intended.
In other words, when there is a serious solution to
multihoming -- ie, being able to preserve a connection when
using more than one IP Address -- it will likely work for IPv4.
Actually, that definition changes the problem into a much harder
one, and one that I think is unnecessary for the problem I was
discussing --unnecessary 99% of the time, if not always. The
reality is that there is very little that we do on the Internet
today that require connection persistence when a link goes bad
(or when "using more than one IP address"). If a connection
goes down, email retries, file transfer connections are
reconnected and the file (or the balance of the file if
checkpointing is in use) is transferred again, URLs are
refreshed, telnet and tunnel connections are recreated over
other paths, and so on. It might be claimed that our
applications, and our human work habits, are designed to work at
least moderately well when running over a TCP that is vunerable
to dropped physical connections.
Would it be good to have a TCP, or TCP-equivalent, that did not
have that vunerability, i.e., "could preserve a connection when
using more than one address"? Sure, if the cost was not too
high on normal operations and we could actually get it. But the
goal has proven elusive for the last 30-odd years -- at least in
the absence of running with full IP Mobility machinery all of
the time, which involves its own issues -- and, frankly, I'm not
holding my breath.
By contrast, the problem that I find of greatest concern is the
one in which, if I'm communicating with you, and one or the
other of us has multiple connections available, and the
connection path between us (using one address each) disappears
or goes bad, we can efficiently switch to a different
combination... even if all open TCP connections drop and have to
be reestablished in the interim. For _that_ problem, we had a
reasonably effective IPv4 solution (at least for those who could
afford it) for many years -- all one needed was multiple
interfaces on the relevant equipment (the hosts early on and the
router later) with, of course, a different connection and
address on each interface. But, when we imposed CIDR, and the
address-allocation restrictions that went with it, it became
impossible for someone to get the PI space that is required to
operate a LAN behind such an arrangement (at least without
having a NAT associated with the relevant router) unless one was
running a _very_ large network.
Now, I'll stipulate this is a routing problem as much, or more,
than it is an address-availability problem. And I'll also agree
that there appears to be little evidence that IPv6 is
significantly more routing-friendly than IPv4 and hence, that
any real routing-based solutions that help the one will help the
other. But,
(i) if any of the options turn out to require an
approach similar to the one that continue to work for
big enterprises with PI space in IPv4, then we are going
to need (lots) more address space. And
(ii) If any of the "multiple addresses per host" or
"tricks with prefixes" approaches are actually workable
and can be adequately defined and implemented at scale
--and there is some evidence that variations of them can
be, at least for leaf networks-- then they really do
depend on structure and facilities that appear to me to
are available in IPv6 and not in IPv4.
So, for the problem I was referring to (but perhaps not for your
much more general formulation), I stand by my comment and
analysis.
Most of these proposals are quite new. No more than a year
old and many less than 6 months.
This does not speak well for anything happening immediately, of
course. However quite a number of the proposals do not
require any significant infrastructure change. This bodes
well for rapid deployment, once they make it through the
standards process.
On the other hand, getting the IETF to produce standards track
specifications out of this large pack of candidates could take
another 10 years...
Yes. And it may speak to the IETF's sense of priorities that
the efforts to which you refer are predominantly going into the
much more complex and long-term problem, rather than the one
that is presumably easier to solve and higher leverage.
john
|
|