Many moons ago, when I was just a wee bairn commencing my career, I had a job interview for a low-level developer role. Having at that time just learned how CIDR was implemented, I was keen to show off my knowledge.
Sadly, that tactic didn't work out too well for me. I recall being completely floored by the very first question that was asked (and, then ruffled, it all went downhill). The question was:
Why are IPv4 addresses 32-bit?
I readily admitted that I didn't know the answer, but I did know that the original protocol design divided the address space into an 8-bit network number and a 24-bit host identifier—so I tried to rationalise it on the grounds that the protocol designers imagined an Internet of a few networks (after all, it was originally intended to link together a specific few) each comprising many hosts and, for simplicity of programming, kept everything aligned to byte boundaries.
I recall the interviewer being unsatisfied with my answer and suggesting to me that the real reason is that it's guaranteed to fit inside a
long int in C, so simplifies implementation details. Being young and green at the time, I accepted that as a reasonable answer and (before today) hadn't thought any more of it.
For some reason that conversation has just returned to me and, now that I reflect upon it, it doesn't seem entirely plausible:
Under the original addressing scheme comprising fixed-size network and host fields, it's unlikely that a developer would have wanted to assign the concatenation of the two fields to a single variable (I don't have access to any early IP implementations to verify what they actually did in practice); and
At the time that works on TCP/IP began, C was neither standardized nor the de facto "lingua franca" of low-level software development that it has become today.
Was the interviewer's suggestion actually founded in fact? If not, what were the real reasons that the protocol designers chose 32-bit addressing?