ietf
[Top] [All Lists]

Re: US DoD and IPv6

2010-10-08 11:12:42
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 
widespread buyin.

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.

Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>