On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote:
From: Keith Moore <moore(_at_)network-heretics(_dot_)com>
What doesn't work well is to have everyone decide for himself how to
change the architecture.
The reason we have/had a free-for-all on the architectural front is that the
IETF's choice for architectural direction (15 years ago) was non-viable (i.e.
wrong); it wasn't economically feasible (in terms of providing economic
benefits to early adopters, or otherwise having an economically viable
deployment plan), and it didn't offer any interesting/desirable new
capabilities (which was a big factor in the former).
In hindsight, I suspect IETF could have made a better choice for IPv6. Or
even accepting the basic IPv6 approach that we ended up with, slight changes to
some of the details might have made a big difference. And it's worthwhile to
try to learn lessons from that choice and the consequences. However, I don't
see how it's constructive to say that the choice was "wrong". There is today
an increasingly widespread realization that "the worldwide deployment of IPv6"
is a better path forward than any of the likely alternatives. That doesn't
mean it's the best possible path forward, of course. But as we're both
painfully aware, having a better idea isn't sufficient. A necessary condition
for success is to get widespread buyin to the idea. For better or worse, IPv6
is still the only semi-viable long-term strategy that has anything like
With an 'approved direction' that didn't work, having people go off in their
own directions instead was an inevitable corollary.
Except that neither middleboxes in general nor NATs in particular were a direct
result of the decision to adopt IPv6. NATs were not originally driven by a
shortage of IPv4 addresses. In the consumer market they were driven by what
came to be a de facto standard of one IP address per customer, due partially to
this assumption being widespread within IETF itself. In the enterprise network
space they were initially driven by a misguided notion that having private
addresses would produce better network security. In both cases the adoption of
NATs was largely a consequence of IETF's failure to produce and adhere to a
comprehensive plug-and-ping autoconfiguration architecture.
The problem was that the 'approved direction' was wrong, it was that in many
important spaces for both IPv4 and IPv6, there was no approved direction - only
a hodgepodge of half-baked hacks that didn't fit together well.
Which is why I am urging the IETF to be _realistic_ now, and accept the world
as it actually is, and set direction from here on out based on that, and not
on what we wish would happen.
Sigh. Anytime someone makes an appeal to accept "reality" I wish a (small)
brick would fall on his head. That's exactly the same kind of argument that
was made in the late 1990s within IESG as to why IETF could not do anything to
make NATs predictable to applications.
But for what it's worth, I do share your assumption that we don't have the
luxury of working from a clean sheet design. And I agree that at least in the
near term it's going to be ugly. But I think the goal should be to facilitate
a transition to a world that's less ugly, or at least more functional.
Ietf mailing list