[ih] ARPANET pioneer Jack Haverty says the internet was never finished

[John Gilmore]

Jack is right that the Internet was an experiment that was never
finished.  In the last 2 or 3 years I have been trying to polish up a
few of the odd corners of the Internet experiment.  And the roadblocks
to finishing it are not the ones you might expect.

Louis Mamakos wrote:
>                                   So it was an exercise to understand the
> span and extent of a multicast distribution tree across backbone links for
> any given stream from a source, and some hand-waving over the cost of the
> forwarding state, back when memory was expensive and you had state based on
> both source and destination occupying resources.  At the time, this was not
> quite top-of-mind, but something to think hard about, having had to upgrade
> CPU boards in many routers as the default-free Internet routing table was
> growing quite rapidly in those days.

Back in the Mbone days I had multicast running in my basement over a T1.
But upstream, no major ISP would enable it in their Cisco routers,
mixing the packets into the default data stream.  This was because
Cisco's multicast routing code was much less mature than the unicast IP
routing and forwarding code that handled 99% of their paying traffic.
Having to update or merely reboot their core routers once a month was
far too much of an operational ask.  The few ISPs who offered multicast,
offered it via manually configured tunnels connected to side-servers
that were not their core routers.  These would only disrupt their few
multicast customers when they needed a reboot.

Michael Grant wrote:
> The address space (224.0.0.0 to 239.255.255.255) was very small, I
> never understood how that was supposed to work in a global context.

Global multicast turned out (for whatever reasons) to be so infrequently
used that more than half of that "very small" space has never even been
allocated to anyone by IETF or IANA, let alone used in the real
Internet.  This among other things reconfirms for me that *unicast
packets* are the key success of the Internet experiment.  Unicast
traffic outnumbers all other kinds of traffic by orders of magnitude.
Unicast address demand is far greater than demand for multicast,
broadcast, loopback, or reserved addresses.  It seems obvious and yet
most people don't think of it that way.  As a result, I propose that at
least the unused half of the multicast address space should be
re-allocated to unicast use.

Recently I have tried to improve some corner cases in the Internet
experiment.  In particular, reforming the mis-allocation of scarce
address space to things other than unicast traffic.  There are four
major address blocks that can't be used for unicast traffic, at a time
when the world is gasping for usable unicast IPv4 addresses.  These are
0/8 (a failed DHCP), 127/8 (loopback), 224/4 (multicast), and 240/4
("for future use").  In addition there are two allocations in every
subnet that are unusable for unicast: the highest (the subnet broadcast
address, deprecated in 1999), and the zeroth (the second subnet
broadcast address, reserved for 4.2BSD Unix compatability in 1989).

So far nobody has raised any serious arguments that these corners of the
IPv4 experiment should not be reformed.  The most prevalent argument is
not serious -- that since not everyone has adopted IPv6, we should
therefore abandon seeking all improvements of IPv4, in the hope that
inaction will provide an epsilon more impetus toward IPv6.  The code
changes required are typically one to two lines of code per address
block, usually removing a special-case so the addresses will be treated
like the unicast default case.  Yet the proposals have not progressed in
the IETF, only among OS implementers.

My small team has written Internet-Drafts that cover unicast use of 0/8,
127/8, 240/4, and the lowest subnet address, which are pending in the
"intarea" working group.  If you believe that the Internet experiment
isn't over, and that there are ways we can find consensus to improve the
Internet that we have, then help to support or improve those drafts.
Please show the doubters that it's safe to gently evolve our experiment.

	John Gilmore
	IPv4 Unicast Extensions Project