[ih] The history of "This" 0.0.0.0/8 network?

[Grant Taylor]

On 02/12/2019 01:20 PM, Jack Haverty wrote:
> Well, I was there during the transition from ARPANET to TCP version 
> 2.x to version 4, and I remember some of the issues and reasoning. 
> You probably won't find any of this written down in IENs or RFCs.

I hadn't even thought about TCP/IP prior to version 4.  That sounds like 
you went through two transitions.  Or was TCP/IP (?) version 2 used in 
parallel with ARPANET protocols.  (Memory is failing if ARPANET used 
it's own protocols between IMPs / TIPs / Hosts.)

> In the beginning, ... there was the ARPANET, the Packet Radio Net(s), 
> and SATNET.   All of these had their own addressing scheme, e.g., in 
> the ARPANET it was a concatenation of IMP# and Host# on that IMP (An IMP 
> was a packet switch to which phone lines and cables to "host computers" 
> were attached.

ACK

How were those IMP# & Host# typically written down or spoken between people?

> The IP address, expressed in x.x.x.x notation, could be used to specify 
> both a particular network and a Host address on that network.  …  The 
> ARPANET addresses could be encoded into 24 bits.  So, for ARPANET (and 
> some of its clones), an IP address like 10.2.0.5 would mean network #10, 
> Host #2 on IMP #5.  Host #2 identified a specific physical connector on 
> the back of the IMP cabinet.

Did "network #10" have meaning on the ARPANET?  Or was network #10 the 
representation of ARPANET vs PRNs / SATNET / etc?

I find the Host #2 on IMP #5 a bit odd thinking about the structure of 
an IPv4 address as we use them today.  I would have expected IMP #2 and 
Host #5.  At least if using a form of hierarchal routing.

If not, I'd be afraid that you would end up with a site having the 
following IP addresses:

  - 10.1.0.5 - host #1 on IMP #5
  - 10.2.0.5 - host #2 on IMP #5
  - 10.3.0.5 - host #3 on IMP #5

I feel like that wouldn't scale and route nearly as well as:

  - 10.5.0.1 - host #1 on IMP #5
  - 10.5.0.2 - host #2 on IMP #5
  - 10.5.0.3 - host #3 on IMP #5

Maybe I'm misunderstanding what you're saying.

> Routers (then known as gateways), hosts, and anybody else could take 
> an IP address, and figure out the network address on that particular 
> network by simple algorithm. This worked for ARPANET, SATNET, and PRNETs.

Yep.  I get that.  It makes sense to me.

I occasionally ask interview candidates why the "default gateway" is 
called "default" and "gateway".  Occasionally, a candidate surprises me 
and gets it correct.  :-)

> LANs broke this scheme.  In particular, Ethernet addresses were too big to 
> be stuffed into even the 24 bits of a class-A IP address.  So algorithmic 
> translations were not possible with those types of networks.  That led to 
> the creation of ARP, and the use of broadcast capabilities of Ethernets, 
> to implement a mechanism for doing translations.

Then there were things like DECnet Phase IV where the MAC address gets 
modified to match the protocol address.  I think I've heard of other 
protocols doing this too.  But not TCP/IP.

> I recall discussions of this in the ICCB/IAB, the Internet Meetings, the 
> hotel bars, etc.   The goal of the Internet was to be able to integrate 
> any type of network into the network as long as it met the very basic 
> requirements of being able to carry packets.  (We even mused about a 
> "network" based on carrier pigeons).

I think I've read stories where people have actually made such things 
work as a Proof of Concept.  TCP/IP over Bongo Drums comes to mind.

I've also heard people use UUCP, admittedly not TCP/IP, via avian 
carriers (read: homing pigeons) with USB flash drives containing bag 
files.  }:-)  It's not practical, but it does work.

> The unsolved problem (at the time) was how to deal with networks that 
> had addresses too big to fit in IP addresses, and that also did not have 
> any broadcast capability.

Ew.

I guess things like ATM qualify there.  Needing some sort of out of band 
mapping.

> I can't remember specifically, but that might have come up while we 
> implemented the "VAN Gateway", which used the public X.25 network to 
> interconnect between the US ARPANET and University College London in 
> Europe.

I guess X.25 qualifies there too.

> IIRC, we could manually configure the two gateways at either end of the 
> X.25 path to know each others addresses and be able to use the X.25 path 
> to carry IP traffic between routers.

It's my understanding that X.25 is (was) largely a switched serial 
circuit network.  Meaning that you had some management, similar to 
dialing a modem, which would establish a virtual circuit between X.25 
endpoints and then provide an end to end serial path, much like a (null) 
modem cable.

I'm guessing that the TCP/IP to X.25 gateways collective looked like a 
single hop in a TCP/IP traceroute.

> But that didn't provide any mechanism for a Host computer to interact 
> with the gateway, using the X.25 network as a "LAN" of sorts.  So the 
> entire public X.25 network was a network within the Internet, but we 
> didn't have any way to connect "host computers" on that network.

Yep.  Similar to how IPv4 can carry IPv6, or vice versa between 
endpoints.  But hosts on either side of the gateways (outer IPv{6,4} vs 
middle IPv{4,6}) don't have a (good) way to communicate directly with 
each other.  Such is the nature of bridged / tunneled / encapsulated 
traffic.

> Another unsolved problem was how host computers would find out basic 
> information that they needed to know how to use the Internet - e.g., 
> the address of the gateway(s) on their net, their network number, etc. 
> Manual configuration wasn't too bad when there were only large computers 
> on the ARPANET, but with the advent of workstations, the administration 
> became unwieldy.  That led to DHCP.

ACK

I remember when DHCP was a thing that big networks would set up.  Early 
in my career, many of the networks that I worked on didn't have DHCP 
yet.  Or they were IPX or NetBIOS.

> There was a lot of other experimental work going on, e.g., in handling 
> of voice and video, and the use of multicast capabilities, which led to 
> implementations such as MBone.  Lots of problems to be solved there.
> 
> I don't remember any specific discussions about 0.x.x.x, but I suspect 
> it was reserved as a placeholder for future use - i.e., don't assign 
> any network as network #0 - it may be useful when someone figures out 
> how to approach the problems above.

Was that same mentality extended to include the zeroth (all zero bit) 
host address?  Or was that something else?

> Remember, the Internet was always an Experiment (hence the IENs), so 
> lots of stuff in the Internet technology was there to help create an 
> experimental platform.

Yep.

> All of the above occurred in the 1978-1982 or so timeframe.   I assume 
> that the 0.x.x.x "hook" got used later as the Internet evolved.

ACK



-- 
Grant. . . .
unix || die