Dave,
Just to pick a small nit or three...
--On Wednesday, 28 January, 2004 07:36 +0900 Dave Crocker <dhc@xxxxxxxxxxxx> 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.
Yes.. SCTP solves the problem for V4 and V6 (missed that bit last time).
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.
Yes.. it is true we have trained folks to hit the reload button... there is no
doubt about that :->
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
John, please go look at RFC2960... it does this.. it is TCP equivalent.. and yes the
cost is not to high.
It is available in Linux 2.6, all of the BSD via KAME, Solaris (via package I am told), HP
and you can purchase it for many other platforms...
You can find information on this at:
http://www.sctp.org/implementations.html
It always seems to me like typical engineers... we solve the problem
one place and then rush out and try to solve it in yet another place... when
all we have to do is use what is already defined... I guess it is the ole NIH syndrom... :-<
-- 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.
The web server that I mention above has two addresses that are on the Big-I. And if
you connect via SCTP to the apache engine .. guess what.. you will use both of them..
and no I don't need a large block of lan allocation.. SCTP takes care of all of
this for me...
Will it work (multi-homed) behind a nat.. nope.. you reduce down to singly homed .. but that is the price you pay for NAT..
I suppose one could define a inter-nat protocol so one could support multi-homing but
that is a swamp I would not care to walk down...
R
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
-- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone)