On Sat, 3 Apr 2010 18:37:51 -0700 (PDT) David Barak <thegameiam@yahoo.com> wrote:
--- On Sat, 4/3/10, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
No. But that isn't the point. The point is
To: "George Bonser" <gbonser@seven.com> that v6 was a bad solution
to the problem. Rather than simply address the address depletion problem, it also "solves" a lot of problems that nobody has while creating a whole bunch more that we will have.
Ever used IPX or Appletalk? If you haven't, then you don't know how simple and capable networking can be. And those protocols were designed more than 20 years ago, yet they're still more capable than IPv4.
Spoken like someone who has forgotten how much {fun|trouble} cable range + zones were...
I'll admit I didn't do enough with Appletalk to fully understand Zones. However I do like how cable ranges allow you to have odd numbers of multipes of 256 nodes, rather than doubling or halving the subnet size, as is the case with IPv4.
IPX, AppleTalk, VINES, DECNet, SNA, and all of the other protocol suites which were kicking around in the 80s and early 90s each had the "one thing they do really really well," but none of them were sufficiently flexible, extensible, easy, or cheap to capture the market.
Examples of some things which those protocols *didn't* do well include (obviously the list is different for each individual protocol):
In a lot of cases they were add-ons to IPv4 too. Crypto was an add on, multicast was an add on, more than 256 networks was an add on, IPv4 isn't always cheap and easy to implement because of IPR clauses. Centralised, database driven address administration via DHCP is probably unique, however distributed centralised services were available in IPX and Appletalk via SAP, NDS, NBP and ZIP.
* interdomain routing - most were optimized for single-administrative control networks * multicast * handle an encryption layer at layer 3 * cheap + easy to implement, no license required * distributed centralized administration (i.e. DHCP servers) * tolerate a wide variety of {link|connection} performance characteristics
The following are worth having look at, as they show what was the state of the art when they were published in 1985. "Xerox Network Systems Architecture - Introduction to Xerox Network Systems" http://bitsavers.org/pdf/xerox/xns/XNSG058504_XNS_Introduction.pdf "Xerox Network Systems Architecture - General Information Manual" http://bitsavers.org/pdf/xerox/xns/XNSG068504_XNS_GenInfo.pdf Most of the things on your list are there, or could have been as added using the same methods used to add them to IPv4.
I think IPv6 has not just learnt from the history of IPv4, it has also learnt from the history of other protocols.
Sadly, though, it also picked up some of the mistaken optimizations from the other protocols. The mess that has been made of RA+SLAAC+DHCPv6+DNS is something which can't be described as "elegant," and I certainly don't find it an improvement over IPv4 DHCP+DNS.
Unfortunately I think that was always going to happen. I don't think there is as strong a need for centralised management of IP address space as what DHCP/BOOTP/RARP have provided. However as DHCP et al. is the only way to do autoconf in IPv4, I think people were always going to want to have a stateful equivalent in IPv6 as they're comfortable with it. If people were prepared to have given up the "DHCP way" of managing addresses, and had accepted using link layer addresses as layer 3 node addresses, like XNS did (and IPv4 originally did too - RFC826 is the in 800s for a reason), then IPv6 could have been simpler by not having to have a neighbor discovery protocol to map layer 3 to layer 2 addresses. I'm hoping multicast DNS and DNS-Service Discovery become more popular. In conjunction with IPv6 SLAAC, the Internet will have finally caught up with what people were easily doing in the early 1990s with Appletalk and IPX. Regards, Mark.