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