[ih] IPv4 address size debate

[Jack Haverty]

Answering a few messages...

I don't recall any significant discussion of variable-length addresses.
There was discussion of the fixed size of the address field, and
especially of the way to split it up into class A/B/C/etc, which was I
guess a form of variable addressing.  There weren't all that many
computers around, but a new concern was the number of *networks* that
could be handled (256 wasn't enough), and the number of hosts that could
be on a particular net.  So IP4 *does* have variable-length addresses.
Sort of. 

This also was I think when the need for ARP surfaced, since there wasn't
enough "host" space left in the IP address to contain a full lower-layer
address for the then-new LANs.  I think that the limitation to 32 bits
may have partially been to force the issue of dealing with physical nets
whose addresses were "too big" to just stuff into the IP address host
part.  If the IP address had been 64 bits, you can bet that 48 of them
would have held Ethernet MACs...it would have been too tempting.

Lastly, there was some real concern about efficiency.  A lot of traffic
was Telnet, much of it character-at-a-time, which meant each TCP/IP
packet often carried exactly one byte of user data, reaching an
astounding wire efficiency of less than 5%.  So 95+% of the $$$s buying
those expensive leased lines was for overhead.  More if you considered
that you never wanted to run lines at 100%.  If you took an analyzer and
snooped on the IMP/IMP circuits, it was sometimes really hard to see any
actual user data for all the headers and control packets (TCP ACKs).
Not so good. 

The 32-bit decision and the various splits of net/host space got things
from discussion to coding.

As Vint points out, you have to remember that all this work was an
experiment.  That's what ARPA did.  In fact, sometimes decisions were
made to try an unproven approach, even when a known proven approach was
applicable, because that was the mission - in Star Trek terms, to "go
where no man has gone before".

Besides, in just a couple of years we had gone from TCP 2, through a
slew of point-releases (I remember TCP 2.5 and TCP "2.5+epsilon"), TCP 3
(for a few weeks) and were working on TCP 4.  Everyone I think pretty
much believed that TCP 5, 6, etc. would come along in short order and
the headers could be readily changed again if the experimentation
results warranted.  We surely didn't think it would take decades and the
TCP4 design would have to last that long...so 32 bits fixed could easily
handle the needs for the next 12 months or so!

When the government made TCP a DoD standard, the concrete set really
quickly...

Ah yes, Ethernet hacking sounds like a BSD project.  I may also be
confusing the TCP and IP checksumming - it's been a long time.  There
was some reason for considering trailers though.  Can't remember..

/Jack


On Fri, 2009-11-13 at 16:34 -0500, Noel Chiappa wrote:
> > From: Jack Haverty <jack at 3kitty.org>
> 
>     > Since I was one of the people arguing for fixed-length addresses back
>     > in those days, I guess maybe it's time to explain why...
> 
> I don't disagree that fixed-length addresses were the right choice _at the
> time_; I was actually interested in why we didn't pick something with a
> little more long-term flexibility (i.e. flexible syntax, with 'temporarily'
> subsetted semantics to produce _effectively_ fixed-length addresses), and if
> that option was even considered.
> 
> Did people think 32 bits was 'more than enough for any conceivable
> circumstances', or did they not think that TCP/IP would be anything other
> than a large-scale trial that would be supplanted by something new, or what?
> 
> Had someone suggested a format with address-length fields, and the only
> allowed/supported value in them being '4', do you think that would have been
> accepted?
> 
> 
>     > It was very very desirable to have the hardware put the data into the
>     > "right place" for subsequent processing.
> 
> I take your point (I used techniques to do the same thing in the router code
> I did, to avoid having to ever move data), but at the same time it undermines
> the then-current reasoning that 'if we need to do anything else, we can do it
> with a header option' - since (as you point out below) using options produces
> variable-length headers, and those negate the advantages of a fixed-length
> header.
> 
>     > IP packets with no options would be fast, those with options would
>     > suffer.
> 
> Which is still the situation today... I was going to say 'sadly', but I'm not
> sure that's warranted. But it is certainly a very high bar to the use of
> options for extensions that are anything other than 'low-duty-cycle' (i.e. in
> few packets), and that definitely limits the value of the option-based
> extensibility mechanism.
> 
>     > There was at least one implementation of Ethernet (MIT? IIRC) that put
>     > the Ethernet header at the *back end* of the packet on the wire - i.e.,
>     > it became a trailer rather than a header. 
> 
> Ah, no. That was Berzerkley. (See RFC 893.) (Gratuitous comment suppressed... ;-)
> 
>     > This would have required, among other things, redefining the IP header
>     > so that the checksum was kept in a trailer - since you couldn't finish
>     > computing the checksum until all of the data had come in.
> 
> ??? The IP checksum covers only the IP header, no?
> 
> 
>     > Essentially you would end up with a circuit-switched network that had
>     > an IP datagram interface ... In this architecture, IP is an interface
>     > spec at the edges only, and what goes on inside is hidden and could be
>     > anything. I wonder if today's routers play such tricks....
> 
> That's exactly how today's networks actually operate. Things like Frame Relay
> and MPLS avoid processing IP headers on many hops - although on a local basis
> only (i.e. not system-wide).
> 
> I do forsee IP becoming an interface-spec at the edges, with something new
> being used _inside_ the network, i.e. router-router (much like an RJ11 analog
> jack is an old interface to a wholly different/modern internals), but then
> again this is hardly a new idea - the Nimrod deployment plan used the same
> concept! So my crystal ball may be a bit out of focus, timewise... :-)
> 
> At the moment IP is in fact still used for the generic router-router
> interface, but I do think the day is drawing closer when something else will
> (slowly, admittedly) replace it in that role.
> 
> 	Noel
>