RE: When IPv6 ... if ever?

["Roeland M.J. Meyer" <rmeyer () MHSC com>]

> 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.