John,
See below for an attempt at a more nuanced position.
Steve
On Oct 8, 2010, at 10:49 AM, John C Klensin wrote:
--On Friday, October 08, 2010 09:47 -0400 Steve Crocker
<steve(_at_)shinkuro(_dot_)com> wrote:
Let me say this more strongly. These two defects, "it wasn't
economically feasible ... and it didn't offer any
interesting/desirable new capabilities" were mild compared to
an even bigger defect: There simply wasn't a technically
feasible plan on the table for co-existence and
intercommunication of IPv4 and IPv6 networks.
In addition to working our way through the IPv6 adoption and
co-existence process, I think it would be useful to do a
little soul-searching and ask ourselves if we're so smart, how
come we couldn't design a next generation IP protocol and work
out a technically viable adoption and co-existence strategy.
The "dual stack" approach implicitly assumed everyone would
have both an IPv6 and an IPv4 address. If everyone has both
kinds of addresses, that implicitly asserts there's no visible
shortage of IPv4 addresses, which is contrary to fundamental
reason IPv6 is needed. Further, although some scenarios
suggest IPv4 usage will start to decline steeply once IPv6
transport, products and services are widely available, the
safer bet is that IPv4 networks will persist for a fairly long
time, say 20 to 50 years.
Steve,
While I agree with what you say (and most of what Noel says),
hindsight is pretty easy. I even agree with your 20 to 50 year
estimate although an optimist might draw some comfort from how
quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI
machinery), Vines and Netware, etc., disappeared once the
network effects set in and the writing appeared on the wall.
Predicting timing is the very hardest part of introduction of new technology.
Sometimes it goes fast; sometimes not. I'd be surprised if IPv4 disappears in
substantially less than 20 years. 50 years does seem kind of long, but I think
that's the right horizon to consider. If it disappears more quickly, that's
fine.
To put a slight bit more structure on this, I think there are five epochs:
1. Pure IPv4
2. IPv4 is dominant; IPv6 is showing up in pockets
3. Strong operation of both IPv4 and IPv6
4. IPv6 is dominant but IPv4 is still heavily used
5. IPv6 dominates and IPv4 has essentially disappeared. (More or less
symmetric with pure IPv4, but there's likely to be some isolated pockets or
enclaves.)
We're in the early stages of the second epoch, in my view.
However, certainly Noel's position was part of the discussion
15-odd years ago. Certainly the positions that IPng must
either be strictly forward compatible or that it should
introduce enough new and valuable functionality to make people
want to incur the pain were part of the discussion.
I don't think these are the only two choices, though I agree that either of
these would have been more attractive than the position we're in.
In lieu of compatibility, we needed a viable co-existence and transition plan.
I don't think the dual stack approach was ever viable, no matter how optimistic
one might have been about the adoption of IPv6. As I understand it, the idea
behind dual stack is that all new end systems, all wide area and enterprise
networks, and all services would become IPv6 capable, and all new systems would
operate smoothly in both IPv6 and IPv4 mode. Then, when it was evident that
everyone who had an IPv4 address also has an IPv6 address, new systems could
appear that were IPv6 only. And all of this would happen before IPv4 addresses
ran out.
I think it would have been -- and still is -- sensible to dissect the picture
in terms of the different types of players -- end users, enterprise operators,
ISPs, content providers and perhaps others. Further, imagine that each type of
players have a mixture of early, medium and late adopters. Or, perhaps more
usefully stated, at any given point in time, some are IPv4-only, some are
IPv6-only and some are operating in both IPv6 and IPv4 mode. Is there a
sequence of transitions that allows each type of player to move through its own
transitions and still interoperate with everyone else?
Without going into extensive discussion of the details, it seems to me
inescapable that we would need application level gateways, and that there will
be some breakage because some of the protocols have IP addresses embedded as
data.
The good news, from my point of view, is that the requisite steps are now being
taken to design and build the components that will permit IPv4 and IPv6 systems
to co-exist and interoperate.
Nonetheless, the IETF community selected what is now IPv6. What
does this say about the IETF and how we make decisions? Does
that need adjusting?
A compatible solution would have been better, but I don't think IPv4 -- and its
predecessors! -- were designed in a way that permitted a compatible extension.
I think we missed the boat in not designing the transition and co-existence
scenarios, and I think that ought to cause us to examine our internal standards
for knowing when we have a viable design.
Cheers,
Steve
Finally, and perhaps more important right now, while it is easy
to observe that the 1995 (or 2000) predictions for IPv6
deployment rates have not come close to being satisfied and
recriminations based on hindsight may be satisfying in some
ways, the question is what to do going forward. There are
communities out there who believe that we have managed to
"prove" that datagram networks, with packet-level routing, are a
failure at scale and that we should be going back to an
essentially connection-oriented design at the network level.
If they were to be right, then it may be that we are having
entirely the wrong discussion and maybe that we are on the wrong
road (sic) entirely. If not, then there are other focused
discussions that would be helpful. The latter discussions that
have almost started in this and related threads, but have (I
believe) gotten drowned out by the noise, personal accusations
about fault, and general finger-pointing.
How would you propose moving forward?
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf