nanog mailing list archives
Re: legacy /8
From: Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>
Date: Sun, 4 Apr 2010 13:01:45 +0930
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:To: "George Bonser" <gbonser () seven com>No. But that isn't the point. The point isthat v6 was a bad solutionto the problem. Rather than simply address theaddress depletionproblem, it also "solves" a lot of problems thatnobody has whilecreating 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.
Current thread:
- RE: legacy /8, (continued)
- RE: legacy /8 George Bonser (Apr 03)
- Re: legacy /8 Larry Sheldon (Apr 03)
- RE: legacy /8 George Bonser (Apr 03)
- RE: legacy /8 George Bonser (Apr 03)
- Re: legacy /8 Mark Andrews (Apr 03)
- RE: legacy /8 George Bonser (Apr 03)
- Re: legacy /8 David Conrad (Apr 03)
- Re: legacy /8 Randy Bush (Apr 03)
- Re: legacy /8 Mark Smith (Apr 03)
- Re: legacy /8 David Barak (Apr 03)
- Re: legacy /8 Mark Smith (Apr 03)
- Re: legacy /8 Vadim Antonov (Apr 03)
- Re: legacy /8 Adrian Chadd (Apr 03)
- Re: legacy /8 Dan White (Apr 03)
- Re: legacy /8 Zaid Ali (Apr 04)
- Re: legacy /8 Vadim Antonov (Apr 04)
- Re: legacy /8 Zaid Ali (Apr 04)
- Re: legacy /8 joel jaeggli (Apr 04)
- Re: legacy /8 Mark Smith (Apr 04)
- Re: legacy /8 James Hess (Apr 03)
- RE: legacy /8 Stephen Repetski (Apr 03)
