[ih] IPv4 address size debate

[Noel Chiappa]

    > 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