John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
--On Wednesday, 28 January, 2004 07:36 +0900 Dave Crocker
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
Preserving a connection when using more that one IP address is
not _necessarily_ a much harder problem -- especially if we
stipulate that tunneling is a legitimate middleware operation.
The reality is that there is very little that we do on the Internet
today that require connection persistence when a link goes bad...
But we certainly _should_ be doing things that would greatly
benefit from connection persistence when a link goes bad.
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.
Alternatively, one might claim our work habits have "evolved"
to work moderately well...
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...
Might we do well to consider _why_ this is so?
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.
If I understand, John is looking for applications-level link
redundancy, which strikes me as unlikely to be easy to deploy.
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.
Aren't we now talking what John said "changes the problem into
a much harder one" -- namely preserving connection when using
more than one IP address?
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.
A /20 is _not_ "very large" -- just impractical to justify for
small-scale projects. (Thus, the allocation policies prevented
much of the small-scale experimentation which normally comes in
the early stages of design.)
Now, I'll stipulate this is a routing problem as much, or more,
than it is an address-availability problem.
I'm not sure I agree. It's true that address-availability
policies were driven by routing problems. One _could_ consider
the route-filtering policies to be "a routing problem", but this
doesn't strike me as useful.
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.
This gives the impression of overstating your case. Indeed, there
_will_ be solutions which require lots more IPv4 space; and there
will be solutions which depend on structure of IPv6. But these will
have to compete with other solutions which need neither.
So, for the problem I was referring to (but perhaps not for your
much more general formulation), I stand by my comment and
I won't attempt to restate your analysis. But I think your
analysis is too narrow. You quite ignore the tricks which many
smaller ISPs can perform -- especially when they cooperate.
We have a genuine problem in that we'd like something immediately
scalable -- and only larger ISPs can immediately reach large numbers
of users -- and larger ISPs impose arbitrary and capricious limits
on what their customers can do.
Nonetheless, larger ISPs will have so many problems deploying
IPv6 that I have no confidence they _can_ make it native to their
operations within five years. OTOH, if we need to tunnel it over
IPv4, the situation really isn't different from any other tunneling
Most of these proposals are quite new. No more than a year
old and many less than 6 months.
I'd love to investigate them...
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
I rather suspect many of them could be deployed _before_ 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.
There is a great tendency to broaden the scope of a project as
you add more people to it; and a very rational tendency to extend
the time-frame being considered as the time-to-approach-consensus
appears to grow. Lamenting this won't change it.
Where we go seriously wrong is requiring short-timeframe efforts
to coordinate their work with long-timeframe efforts.
John Leslie <john(_at_)jlc(_dot_)net>