smd@clock.org, Sunday, September 10, 2000 6:38 AM wrote:

Excellent Post, BTW.

| The bottom-line appears that everyone is waiting for everyone else to | twitch first, then the shoot-out starts. However, no one is all that | interested in twitching.

Also, nobody is willing to get shot!

The deployment of IPv6 is going to be EXPENSIVE in terms of real opex and probably real capex as well, it IS going to be visible on the bottom line of every ISP on the planet, eroding whatever margins one has.

| The real question is whom is benefiting from sustaining the current | situation?

Now, ironically, in the whole IPv6 selection process in the IETF, there were multiple proposals which paid a considerable amount of attention to the problems of partial, incremental deployment at the initial design level. CATNIP in particular was clever, because it provided not just a new packet format (which is all IPv6 did), but also a strategy to transition to practically ANY new packet format, should the initial assumptions about the pervasiveness of IPX and CLNP be wrong (which they were).

IPv6's initial assumptions are WRONG (we will die from routing dynamicism

I tend to agree here that routing is one of our largest bugga-boos. What we have is held together with spit, baling-wire, and liberal amounts of the "racer's edge" (duct-tape). With CERF.NET bouncing all over the place, for the past three weeks, maybe I've become hyper-sensitive to those issues. But, it appears to me that the entire BGP system is a very brittle patch. It is for this reason that I recommend ABOVE.NET to all my globally visible portal/ASP/B2B clients. However, this doesn't relieve the problem of the end-user being outside the ABOVE.NET system and having to live with cold-potato routing, for uploading files to the site. We have too few public peering-points and they are under-sized (what happened to the regional NAP idea?).

Who will take the chance of a huge investment in managing IPv6 deployment, when it is not a given that IPv6 really will be the header networks will use after IPv4? We're talking about stranded assets being the only thing one gets for the money...

What you are saying is that going to IPv6 is a one-way function? I've actually looked at some of this. At the risk of ridicule, may I mention Flemming's IPv8? It nested IPv4 inside the packet, as a sub-set, and actually planned for co-existance and inter-operability with IPv4. It also answered a LOT of routing issues. Regardless of specific implementation, that seems like a more prudent approach. Does anyone know why such an approach-policy wasn't followed by the IPv6 team? Yes, I agree that CATNIP was also clever. With a little work, it "could have been a contender" (Brando<g>). The choice of IPv4 and IPv6 shouldn't be an XOR function and the point remains that transition was not a consideration of the IPv6 design (this is obvious). In most commercial shops, such an approach would not have been accepted/tolerated. Let alone, win any sort of design contest, as did IPv6.