[ih] order of source and destination address in IP header

Noel Chiappa jnc at mercury.lcs.mit.edu
Tue Mar 22 09:48:19 PST 2005


    > From: Pieter-Tjerk de Boer <ptdeboer at cs.utwente.nl>

    > Why is the source address located *before* the destination address
    > in the IPv4 header?
    > ...
    > One possible explanation is that the designers of the IPv4 header
    > simply didn't care; possibly the IP header was not expected to be
    > processed until the entire packet had already been received.

Yes, exactly. Not only were all packets processed in software back then,
the machine we were using were relatively slow (several hundred KIPS).
Processing these things in hardware wasn't even a thought we had back
then. The packets were completely received from the network interface
before the software looked at them, so the address order simply didn't
matter.

I don't have any definitive memory on the matter, but I would guess they
are in the order "source, destination" simply because that seemed logical
(source -> destination).

(I do recall distinctly being paired up with Ed Cain at one INWG meeting
and being set to the task of editing the draft IPv4 RFC, but I have no
memory of what changes we suggested!)

    > However, studying some historical documents shows that the order of
    > source and destination address was changed twice between 1973 and
    > 1979, suggesting that there may actually have been a reason for
    > this.

Not as far as I know. Perhaps David Reed has a memory of why the order
was changed?

(In any event, looking at it from the viewpoint of being able to process
it in hardware, there's only limited utility to being able to read the
destination IP address early. For one, you don't need to see it quickly
to know if the packet's for you - i.e. you need to read the whole thing
in - by definition, the network-level header says that it is. For
another, if there's a speed mismatch, you can't do "cut-through" routing,
you'll have to buffer the whole packet anyway. The same thing is true if
the output network is shared, and busy.)


    > To be precise, this is what I have been able to find so far:

In addition to the list of versions you have there, there was also an
IP/TCP version 3.5. It had the fixed length addresses of TCP 2, but was
split into separate IP and TCP a la TCP 3. IIRC, there were basically no
changes between IP/TCP 3.5 and IP/TCP 4 (except maybe some minor TCP
changes like maybe getting rid of Rubber Baby Buffer Bumpers [aka Rubber
EOL]). The best places to look for documentation of it are the IEN 26/28
pair, I would think.

Also, I think some of the dates on those documents lag reality a little
bit. I think that by January 1978 (the date on the TCP 3 spec) it had
already been replaced by TCP 3.5. Again, my memory is not really to be
relied on here; perhaps Dave Reed can corroborate this?

(Also, I"m not sure anyone ever implemented TCP 3, actually - my guess is
that keeping as much as possible of the implementations of TCP 2 was one
reasons that variable length addresses were backed out of TCP 3.5.)

	Noel



More information about the Internet-history mailing list