All true, but based on the information available at the time, I am not sure
how a different outcome would have been arrived at.
Having a group to make unpopular but right decisions always seems a great
idea in hindsight. But there is a real practical difficulty distinguishing
such groups form similar groups whose ideas are both unpopular and wrong.
The reason the IAB has no authority is that the selection mechanism is
designed to ensure that it has no accountability. No accountability means no
authority.
What you seem to be saying is that the IETF should have made deployment a
much higher priority in the design of IPv6. Which is what I have been saying
for years.
I treat deployment as an engineering problem. I have been constructing
models and running simulations to test various approaches to deployment
since 1992.
I can construct a plausible deployment model for IPv6 based on NAT boxes.
But I can't see a plausible model which does not involve NAT44, NAT46 and
NAT66 during the transition period and since I am anticipating that lasting
around thirty years, I can't see much point in modeling what comes after.
On Thu, Oct 7, 2010 at 10:58 AM, Keith Moore
<moore(_at_)network-heretics(_dot_)com>wrote:
On Oct 7, 2010, at 10:20 AM, Noel Chiappa wrote:
From: Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
The problem is that the creation of disjoint addressing realms (due to
NAT and to IPv4/IPv6 coexistence) has made distributed application
design almost impossible without kludges.
See, this is the kind of thing I was talking about in my early post in
the
recent incarnation of this thread. Complaining about the existence of
disjoint naming realms, and how it has complicated our lives, is like a
rocket scientist complaining about gravity, and how hard it makes their
job.
(OK, it's not quite a perfect analogy, since gravity is fundamental, but
I
think my point is clear.)
They were inevitable, end of story.
No, they were not inevitable, at least not in the long term. Two cases:
1. There were IPng proposals that would have made IPng an extension of
IPv4 space, and allowed (at least in the interim) all IPng traffic to be
tunneled over IPv4 networks. This understandably made routing people and
network operators uneasy as nobody wanted to live with the Class C swamp
forever. But in hindsight there were probably other ways of dealing with
that problem. And being able to leverage the existing IPv4 network in a
general way would have made IPng easier to deploy. (Admittedly, what looked
deployable in the early 1990s when these tradeoffs were being discussed is
very different from what looks deployable now. In 1991, say, it was much
easier to imagine the whole Internet migrating to a new protocol than it was
even a couple of years later.)
2. In the late 1990s when it became apparent that NATs were causing
problems, IETF had an opportunity to put a stake in the ground. It could
have tried to find a way to integrate NATs into an explicit Internet
architecture; it could have explained why NATs presented difficult problems
for which there were no good solutions; it could have tried to define NAT in
such a way as to permit a more graceful migration to IPv6. It failed at
all three of these, not because of insurmountable technical difficulties,
but because (a) too many people were afraid of alienating NAT vendors, and
(b) IAB, the only part of IETF that had any responsibility for architectural
direction, had been stripped of its power in the wake of Kobe.
In fact, as we should realize by now, IAB's concerns that dictated the Kobe
decision were extremely well founded, even if a lot of us (myself included)
didn't like the specific choice they made. But as it turned out, we didn't
really have enough time to use our normal "rough consensus" process to
specify IPng.
All of this is water that has already flowed under the bridge, of course.
But I think there is at least one thing that we need to learn from this
going forward, and that is that there really is a need for a small group of
wise and widely-trusted people to be able to set architectural direction for
the internet. And occasionally, they're going to make unpopular decisions.
But those are the sort of issues for which a rough consensus process
demonstrably does not work.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf