On Jun 2, 2013, at 10:15 AM, John C Klensin <john-ietf@xxxxxxx> wrote:
> --On Saturday, June 01, 2013 11:28 -0400 Warren Kumari <warren@xxxxxxxxxx> wrote:
>> ...
>>> It turns out that as soon as you envisage a network in which
>>> some nodes only support 32 bit addresses and other nodes
>>> can't get a globally unique 32 bit address, you are forced
>>> into a world of hurt that requires some combination of NAT,
>>> tunnels and dual-stack. That is completely independent of the
>>> design of IPng, and we knew it 1994.
>>
>> Yes, hindsight always makes things *much* clearer. It also
>> provides a nice sandbox to stand on….
>
> But the "knew it in 1994" part means that this is _not_
> hindsight. Several of the other comments we have made aren't
> either -- they were well-understood in the community in 1994 and
> then rejected or ignored for one reason or another. One can
> complain about the rejection in hindsight, but not about lack of
> information.
Indeed, it was well-understood that there needed to be some solution
involving NAT to provide for basic interoperability (even if no one
liked standardizing that aspect); specifically, "The IPng transition
plan must define the procedures required to successfully implement
the functions which vendors will be likely to include in their devices.
This is the case even if there are good arguments to recommend against
a particular function, header translation for example. If products
will exist it is better to have them interoperate than not." [RFC 1752,
Section 16.1]
The problem was that the IETF felt enormous pressure _for its own
efficiency_ to come to a decision about IPng; i.e. we did not have
operators clamoring that they needed IPng to be decided ASAP (I'd
wager that most commercial service providers were far too busy trying
to keep up with the epic customer demand in the early 90's to pay
much attention to the IPv4 depletion problem which was many, many
years away...) As you know, there were real concerns about transition
expressed by operators at the IPdecide BoF ('93 Amsterdam IETF) -
"It was stated frequently and forcibly that the transition costs
should be a significant factor in the selection criteria. Concerns
were expressed by several service providers that the developers
had little appreciation of the real-world networking complexities
that transition would force people to cope with. If the cost of
transition outweighed the pain of other solutions (application
gateways or address translators) customers would not deploy IPng."
[ftp://ftp.ietf.org/ietf/93jul/ipdecide-minutes-93jul.txt]
(Highly recommended reading for folks who are interested in
the history of IPv6)
In the end, the IETF decided it should take active steps toward making
the technical decision on IPng (rather than waiting for the "marketplace"
to decide) and that IESG would form the IPng Directorate [RFC 1719] which
was to evaluate how long we had to IPv4 runout and develop the technical
requirements and criteria for IPng. Once this was completed at the end
of 1994, there was enormous pressure to select a single IPng candidate
protocol to work on (despite the unresolved issues regarding transition)
so that the work of the IETF could be focused in a single effort going
forward. This approach might have worked out fine, but once the actual
IPng candidate decision was made, all of the prioritization on transition
requirements dissipated as the work was shuffled off to various working
groups in the years that followed, with the result being that the once
mandatory IPng requirement for a straightforward transition plan from
IPv4 was never fulfilled.
I was asked to be more specific on how to avoid such issues the future,
so here goes:
If multiple solutions can readily coexist, let the market decide.
If not, define the problem from the perspective of those who must
deploy the solution, including their inherent need for a clear and
functional transition mechanism.
In retrospect, it's fairly obvious that there's a huge difference between
problem spaces which allow for multiple solutions (e.g. interior routing
protocols) versus problem spaces which the IETF is aiming for only _one_
protocol in the final solution (e.g. IP, DNS); the process making that
type of architectural decision should probably be quite visible and rather
explicit because it comes with a huge responsibility for addressing all
necessary transition aspects. This responsibility for the transition
aspects should not be set aside by the IETF for convenience or due to the
level of effort that results, as it is the price to be paid when making
an architectural decision to have a single protocol solution for a given
problem space.
FYI,
/John
p.s. John - you made a comparison to electrical power standards with
respect to operator & end-user participation: I guess the parallel
would be that the electrical equipment manufacturers (along with
engineers from electrical production and distribution companies who
have the right background) may indeed make new standards without
end-user input, but when they do so, it is done such that end-users
plugging in old equipment never results in explosion and fire...
We now have service providers running into real challenges trying
to accomplish the same logical result with IPv6, which implies that
the electrical distribution folks pay more attention to transition
aspects of their new standards than we do, and is actually why end-
users and even property developers in general don't worry about
changes in power distribution standards. (You may have to learn
about them if you want take advantage of new features, but if you
don't care, existing practices won't blow up in your face.)
Disclaimers: My views alone. Your mileage may vary; feel free to use,
abuse, or discard these views as you desire.