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




On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote:

>> From: Keith Moore <moore@network-heretics.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).
> 
> With an 'approved direction' that didn't work, having people go off in their
> own directions instead was an inevitable corollary.
> 
> 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. Which means, for instance, that any design for
> architecural change (e.g. introducing separation of location and identity) is
> going to be somewhat ugly, because we don't have a clean sheet of paper to
> work with. It also means accepting that we have multiple naming domains at
> the end-end level, and will for the forseeable future; and trying to work out
> an architectual direction for coping with that ('get rid of it' doesn't
> count). Etc, etc, etc.
> 
> 	Noel
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf