I'm not going to tie up this list with a long protocol war, since
this isn't the forum, but I'll answer a few questions. You can see
some more stuff on my web site and especially the Pouzin Society
site, but there will be more coming out later.
At 1/16/2011 03:36 PM, JeromieR wrote:
I must have missed something along the way. I keep seeing postings
here that IPv6 is worthless, yet when I read the posts on NANOG,
ARIN and IETF mail lists, it is a viable and in production
protocol. So, would some one please post the facts that make IPv6 so bad.
The facts that I'm concerned with begin with the fact that IPv4
itself has a lot of flaws. It was a nice experimental protocol for
1978, when v4 came out, but even then it carried on mistakes that
were known by 1972. Starting with the fact that it addresses
interfaces, not nodes or applications, and thus an IP address is
really just a layer 2 address (hence multihoming often requires a
separate AS, etc.). This was pure arrogance, copying from NCP
something that was a quick expedient at th time (NCP, 1969) and
treating it as revealed truth, though it was known to be problematic
by the. The key problem with IPv6 is that they decided explicitly to
NOT fix any of these things, and to ONLY fix the assumed
address-shortage problem. And then they made it incompatible, so
it's a really costly fix for little gain.
They've been pushing hard to sell this turkey for 17 years now and
only this Y2K-redux hysteria about IPv4 homestead address spaces is
causing real interest.
JonA added,
It is a protocol wonk holy war :-)
Yes. Heck, we've been having these since the 1970s, if not
longer. Ever wonder why X.25 had so many options?
IPv6 is "worse" OSI is "better" Using the definition from
http://en.wikipedia.org/wiki/Worse_is_better
Not sure where that comes from. OSI was a failed attempt at
committee creation. It tried to have two incompatible factions work
together, so it created its own split stack. The reference model
also had a fatal flaw (layers 5 and 6; these were properly
application layer functions) and while that was eventually (after
anyone cared) fixed, the first (and last?) "free" implementation
(Marsh Rose, The Open Book) got it wrong and it worked
horribly. Much worse than Berkeley's free TCP/IP, which thus won.
I'm not pushing OSI. For historical purposes, I note that TUBA was
better, and it was based on the good part of OSI, but we're not
proposing going back there. I am suggesting that RINA is a better
long-term solution, and, most importantly, that it will be possible
to adopt RINA easier than to transition to IPv6. We (John Day,
really) designed RINA to be more compatible with IP than IPv6 is
compatible with IPv4. Plus it's just a whole lot simpler,
stack-wise, and does a whole lot more.
Does not matter to me because I have customers that need end-to-end
connectivity to China and mobile data in the US (that is going
native v6 with v4 NAT) so I'm deploying IPv6.
We still have to convince the cellcos that they're going the wrong
way, but I suspect they'll be doing header compression, to save bits
(= bandwidth, battery power).
There are certainty interesting aspects to the side Fred is on, as
indicated, I believe, in this book: http://amzn.to/gHQDax. I'm still
reading it so no comment there.
Yes, that's John Day's book, Patterns in Network Architecture: A
Return to Fundamentals. It lays out the principles behind RINA,
which is the newer marketing name for what was being called PNA at
the time of the book.
They have interesting ideas but they would be better off building a
overlay network stack ala Skype (P2P network stack, not the voip
program) for app developers, IMO.
I can't comment in public about who's doing what, but I can say that
RINA works *above* IP (like Skype), so you can indeed use IP as a
link layer for RINA applications, or to use RINA's encryption as an
alternative to IPSec. You can also run RINA *below* IP, as an
alternative to MPLS. Or in parallel, or gatewayed. Since the same
three protocols form a layer that recurses, the protocols can fit
into the customer stack wherever it's most useful. BTW, RINA solves
the address problem directly. Only the application is addressed, not
an interface *or* node. Addresses within a layer are hidden from the
outside, assigned topologically, and are just local identifiers. In
IP, the addresses are a per se layer violation, since they are used
both to route on and as part of the upper layer connection identifier.
The simple fact is I have customers that want IPv6 and they give me
money to provide it. If someone wants to give me money to tunnel
their NetBUI traffic over the internet I'll do that as well.
Indeed; I like to design my transport networks, both fiber and radio,
as "layer 2" switched (not bridged), so that they can carry IPv4,
IPv6, RINA, DECnet, NetBUEI, XNS, SNA...
Rather than carry on a debate here, I'll give a pointer to an article
that I wrote with John Day, "Moving Beyond TCP/IP", that summarizes
our positions:
http://www.ionary.com/PSOC-MovingBeyondTCP.pdf . Heck, it even
explains why "NAT is your friend". ;-)
--
Fred Goldstein k1io fgoldstein "at" ionary.com
ionary Consulting http://www.ionary.com/
+1 617 795 2701
--------------------------------------------------------------------------------
WISPA Wants You! Join today!
http://signup.wispa.org/
--------------------------------------------------------------------------------
WISPA Wireless List: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
