[ppml] IPv6 flawed?

[Dean Anderson]

On Wed, 5 Sep 2007, David Conrad wrote:

> On Sep 4, 2007, at 11:13 AM, briand at ca.afilias.info wrote:
> > - breaking the hard limit will most likely result in IPv6 getting  
> > tossed
> 
> Very true.  An interesting point I hadn't really considered.

Of course, one might use separate hardware for IPv4 and IPv6 as a
solution to such problems.

There seems to be way too much emphasis on trying to load IPv6 onto
IPv4.  While I can see that you might want to send IPv4 and IPv6 packets
over the same WAN connections, and over the same LAN hardware, there is
no reason to mix them further. Indeed, probably there are more good
reasons not to mix them.  Indeed, embedded systems builders have to
replace some IPv4/IPv6-muddled programs when they turn off IPv6, or 
suffer build problems.

> This would seem to imply IPv6 could get strangled long before it could
> take off, regardless of RIR allocation policies.

Its sort of ironic that the motivation for creating IPv6 was address
depletion, when address depletion will kill IPv6.

IPv6 was supposed to "take off" between 1995 and 2005.  Seems we are
behind schedule by a lot. Maybe IPv6 is already dead, suffocated by a
variety of things, but most notably by market rejection and government
refusal.

The IPng book is a useful roadmap to what's wrong with IPv6:  (just a
few quotes)

"It should be explicitly noted that the reasons which are compelling the
Internet Community to create IPng [...] are not themselves adequate
motivations for users to deploy IPng within their own private networks"

"The IETF firmly believed that it must "own" the standards" pg 199

"Therefore, for a number of reasons, unfortunately including prejudice 
in a few cases..." pg 199

So, here it is: 'the users won't want it, and unsavory politics drives
the process.' Hmm... Let me think... No, not something I want to buy
into, I think.  Unsavory politics has since turned into bad science.  
(e.g. Stateful Anycast fraud, Patent fraud, see
http://www.av8.net/IETF-watch/)  

I bought the IPng book in 1996. I haven't looked at it in years.  In
retrospect, this book contains just exactly the things one hopes not to
hear. So, I think it means more now than it did then.  Its no wonder
things are not working out...

The important question is whether there is an alternative.  

Indeed, there might still be a viable alternative. I think if we have to
pull together an alternative in the next few years, it has to be
ISO/CLNP TUBA (TCP/UDP over CLNP, RFC1347, RFC1561, et al). This was an
early contentious proposal for IPng.  In retrospect, maybe that would be
better. The reason it is still viable is that CLNP is already (still)
supported by router vendors, and still used for IS-IS.  To entirely
replace IPv6 with CLNP/TUBA requires:

 CLNP stacks for host computers
 setting up a Nameservice 
 Allocating global address space
 setting up IDRP (basically BGP for OSI)
 porting/deploying applications

Basically, this is about the same as what remains to do with IPv6. [hmm.  
after 14+ years work on IPv6, we are still where we were in 1993...sigh] 
There are some advantages, though:

An advantage is that CLNP interoperability between vendors is already
guaranteed, and developers of host implmentations can test with existing
working implementations, rather than trying to read unimplemented
specifications and hoping they do what everyone else will do. No such
problems plague CLNP, so, we have none of the interoperability problems
that continue to plague IPv6.

Large private networks could keep their IPv4 infrastructure, and connect
via IPv4 gateways and proxies and upgrade to CLNP/TUBA as necessary.  
Doing 'gateway/proxy of IPv4' is probably same as they would otherwise
do with IPv6, so this will be pretty transparent to most users. Private
networks that need CLNS features directly could upgrade all or part of
their network as necessary.

The situation is even better for ISPs: Dual stack (IPv4/CLNP) network
operation is _already_ implemented, so ISPs don't need to upgrade very
much, or make very much change at all--basically just

  configure/upgrade for IDRP (the OSI BGP), 
  perform address assignment to customers,
  configure ISIS for CLNP routing

The big one: Customers continue to run IPv4 until they choose to
upgrade.

Bringing up CLNP stack on hosts is easier than IPv6 because the protocol
is stable and well-defined, and already implemented by multiple vendors
who solved interoperation problems long ago.

Another advantage is that we all can completely bypass the IPv6
profiteers and their baggage, including Root DNS mismanagement.

Cisco and other vendors support CLNP now.  Here's a Cisco page on CLNP:
http://www.cisco.com/warp/public/535/2.html

Maybe we can still get IPv6 to work; the saying goes that one can't
polish a t*rd; I think one can get just about anything to run, though
maybe not well.



		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000