legacy /8

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Sat Apr 3 22:31:45 CDT 2010

On Sat, 3 Apr 2010 18:37:51 -0700 (PDT)
David Barak <thegameiam at yahoo.com> wrote:

> --- On Sat, 4/3/10, Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
> > To: "George Bonser" <gbonser at seven.com>
> > > No.  But that isn't the point.  The point is
> > 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

"Xerox Network Systems Architecture - General Information Manual"

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

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


More information about the NANOG mailing list