35

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:

  1. 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

  2. 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?

Kindle Q
  • 149
  • 8
eggyal
  • 475
  • 4
  • 7
  • 3
    Same reason why `640 kB ought to be enough for anybody.` Nobody expected toasters and fridges to have internet access. –  May 15 '14 at 17:32
  • 1
    @afwe: Hm. The question wasn't *why didn't they choose a bigger number to begin with?* aka *why only 32-bits?* (which is really the point that \@Jens' excellent answer addresses), but more *what was so special about 32-bits (rather than, say, 16-bits or 24-bits or 48-bits)?* – eggyal May 15 '14 at 18:01
  • 1
    @Downvoter: Care to comment? – eggyal May 23 '14 at 21:51

3 Answers3

35

Easy answer: because Vint Cerf decided so. He thought that he was designing an experimental protocol and considered 32-bits to be more than sufficient for that purpose; he did not expect IPv4 to be used in production systems and so no greater thought was given to the size of the address space.

At the Google IPv6 Conference 2008, he hosted a panel discussion titled What will the IPv6 Internet look like? during which he recounted:

The decision to put a 32-bit address space on there was the result of a year’s battle among a bunch of engineers who couldn’t make up their minds about 32, 128 or variable length. And after a year of fighting I said — I’m now at ARPA, I’m running the program, I’m paying for this stuff and using American tax dollars — and I wanted some progress because we didn’t know if this is going to work. So I said 32 bits, it is enough for an experiment, it is 4.3 billion terminations — even the defense department doesn’t need 4.3 billion of anything and it couldn’t afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing a experiment to prove the technology and that if it worked we’d have an opportunity to do a production version of it. Well — [laughter] — it just escaped! — it got out and people started to use it and then it became a commercial thing.

Transcript by Peter E. Murray.

eggyal
  • 475
  • 4
  • 7
  • 7
    Agh, how foolish of me! [Occam's razor](http://en.wikipedia.org/wiki/Occam's_razor) strikes again. At least you have given me the smug satisfaction of knowing that the interviewer was wrong. – eggyal May 15 '14 at 15:43
  • Well the interviewer might not believe this answer. ;-) –  May 15 '14 at 15:52
  • @eggyal isn't it possible for there to be multiple reasons for choosing a 32-bit ip length? – user5025 May 15 '14 at 15:54
  • 2
    @user5025: Yes, it is possible (in the general case). But if Vint says those were his reasons for choosing 32-bits for IPv4, then it's hard to argue that he also had others. – eggyal May 15 '14 at 15:56
  • 1
    He didn't say it was the only reason. He simply explained the reason for choosing 32 bit addresses over various other options. – user5025 May 15 '14 at 15:59
  • 5
    @user5025: Okay, that's a fair point. Indeed, he mentions that the engineers were squabbling over what the length should be, with some advocating 32-bit. So I suppose the question is what were *their* motivations for advocating 32-bit (i.e. what made it acceptable to Vint)? – eggyal May 15 '14 at 16:15
  • 1
    @eggyal: Returning to the original question, it would seem very likely that those pushing 32 bits were motivated by the fact that 16 would likely prove too limiting even for advanced testing, and 32 would be easier to work with than any other number of bits greater than 16. – supercat May 15 '14 at 20:58
  • @supercat: When you say "*easier to work with*", to what are you referring? CPU word sizes, operating systems and programming languages were all heterogenous and non-standard at the time... so in what way was 32 easier than, say, 24? – eggyal May 15 '14 at 21:59
  • 1
    @eggyal: IPV4 was designed for systems with octet-addressable memory, and I would be surprised if initial development did not use an octet-based machine. All C compilers were required to have an unsigned type which could handle numbers from 0 to at least 4294967295, and I would be surprised if any compilers for octet-based machines didn't have a type which took *exactly* four octets to store. On an octet-based machine, if a buffer is word-aligned, and an IP address appears at a multiple-of-four offset, one may use pointer typecast and dereference to fetch the IP address into a single variable. – supercat May 15 '14 at 22:56
  • @eggyal: Once IP addresses are stored in variables, operators like `==` may be used to compare them. Use of 24-bit addresses would have required either defining a 24-bit type (which wouldn't allow direct comparisons) or assembling an `int` from multiple discrete bytes. – supercat May 15 '14 at 22:57
  • @supercat: You've made a number of assumptions there. First, that the capabilities of C compilers was in any way influential to the design of IP. Second, that it was deemed desirable to access the complete address in a single operation, despite the (then) fixed separation between network and host parts. These are the exact same points that I already made in my question. – eggyal May 15 '14 at 23:03
  • @supercat: Moreover, the predecessor protocols that IP superseded didn't satisfy your objectives: ARPANET IMP messages, for example, had 32-bit addresses that were spread across three non-contiguous fields in the message leader - none of which were aligned to 32-bit word boundaries. The PARC Universal Packet, another contributing influence, had only 16-bit addresses. Taken together with Vint's comments that some engineers were pushing for variable-length addressing, I don't find your suggestion that 32-bit word boundaries were "intrinsically" desirable very satisfying. – eggyal May 15 '14 at 23:04
  • 2
    @eggyal: My point is not that 32 bit integers were "definitely" a motivating factor, but rather to suggest that I would consider it *highly plausible* that enough of the engineers suggesting that size might have considered that a factor that, absent evidence to the contrary, I don't think it could be ruled out as a factor in the eventual choice. – supercat May 15 '14 at 23:20
  • @supercat: Aye, I can agree with that. By all means post in an answer for an upvote! :) – eggyal May 15 '14 at 23:23
  • 2
    @eggyal: You asked what *might* have motivated engineers to pick 32 bits. My intention was to answer that particular question. I've written a TCP/IP stack on "bare metal" and had to deal with addresses on various occasions but was never interested in parsing them--only in determining whether they matched [this particular stack only handled incoming TCP/IP connections, so it had to deal with ARP, but not gateways]. – supercat May 15 '14 at 23:32
  • @JensLink Here's a more current (Apr. 2014) interview expaining his decision [Hangout with Vint Cerf, TWiT Live](https://www.youtube.com/watch?v=17GtmwyvmWE&feature=share&t=25m30s) listen for about 5 minutes. Maybe it'll be useful to expand your answer. – Daniel F May 16 '14 at 19:53
23

Here's a link to a Hangout with Vint Cerf (Apr. 2014) where he explains how he thought that this internet was supposed to be an experiment only:

As we were thinking about the Internet (thinking well, this is going to be some arbitrary number of networks all interconnected — we don't know how many and we don't know how they'll be connected), but national scale networks we thought "well, maybe there'll be two per country" (because it was expensive: at this point Ethernet had been invented but it wasn't proliferating everywhere, as it did do a few years later).

Then we said "how many countries are there?" (two networks per country, how many networks?) and we didn't have Google to ask, so we guessed at 128 and that would be 2 times 128 is 256 networks (that's 8 bits) and then we said "how many computers will there be on each network?" and we said "how about 16 million?" (that's another 24 bits) so we had a 32-bit address which allowed 4.3 billion terminations — which I thought in 1974/3 was enough to do the experiment!

I had already posted this as a comment to Jens Link's answer, but I felt it shoud surface a bit more.

Anton Karazeev
  • 103
  • 3
Daniel F
  • 368
  • 3
  • 12
  • More than "surface a bit more", I think that this answers the *actual* question more directly than Jens's answer. – eggyal May 19 '14 at 08:21
  • 1
    This feels like someone rationalising a descision they had already made. Really 32-bits is the obvious answer, 16 bits is obviously too small and few if any platforms at the time would have had support for 64-bit numbers, so a 64-bit address would have to be split up and handled in multiple parts. – Peter Green Jan 22 '20 at 18:12
0

Word size. They were writing software, not designing computer hardware - although I'm sure they had performance and portability in mind. At that time, 32 bit was the word, the longword, or int or longInt or whatever. See Word Size Choice.

They wrote this software "during the first decades of 32-bit architectures (the 1960s to the 1980s)." -Wikipedia

Ronnie Royston
  • 4,379
  • 1
  • 12
  • 28
  • 3
    Unless you're suggesting that the architects of TCP/IP had a particular machine architecture in mind, I'm not sure where you're going with this argument... do you have any evidence that they were using/designing for 32-bit architectures, or even that the word size was a relevant consideration to the length they selected for the network address? – eggyal Jan 08 '17 at 18:01
  • @eggyal: Languages for 8-bit and 16-bit machines often included a 32-bit integer data type, but it was far less common for languages on 32-bit machines to have multi-word integer data types. At least at the source-code level, working with 32-bit values is essentially as convenient as working with 16-bit values, and is definitely more convenient than working with larger types. Further, for devices that have limited communications needs, 32-bit addressing could be just fine if they communicate through more sophisticated gateways. – supercat Oct 16 '18 at 17:43