What Vint Cerf Would Do Differently (computerworld.com)

An anonymous Slashdot reader quotes ComputerWorld: Vint Cerf is considered a father of the internet, but that doesn't mean there aren't things he would do differently if given a fresh chance to create it all over again. "If I could have justified it, putting in a 128-bit address space would have been nice so we wouldn't have to go through this painful, 20-year process of going from IPv4 to IPv6," Cerf told an audience of journalists Thursday... For security, public key cryptography is another thing Cerf would like to have added, had it been feasible.

Trouble is, neither idea is likely to have made it into the final result at the time. "I doubt I could have gotten away with either one," said Cerf, who won a Turing Award in 2004 and is now vice president and chief internet evangelist at Google. "So today we have to retrofit... If I could go back and put in public key crypto, I probably would try."
Vint Cerf answered questions from Slashdot users back in 2011.

Comments

IoA

[Anonymous Coward]

Is 128 bits enough? We really need to have enough bits to assign every atom in the universe an IP address.

Re:IoA

[hcs_$reboot]

There are 10^80 atoms in the Universe. So we only need an address of 266 bits to ensure all atoms will safely have an IP at their disposal!

Re:IoA

[jellomizer]

At the time 32 bits seemed like a lot of data to send.
On a 300bps modem it would take a noticeable fraction of a second. 64bit or 128 bit would take much longer, and slowdown nearly everything. Also RAM was small think kilobytes having to store that much data would be sacrificing it somewhere else in the code.

In short if it were implement back then, it would never catch on, and we would be using a different networking protocol now. Perhaps one with much more problematic limitations.

Today using 128bit address having the ability to give more IP Addresses than possible in the universe, really make sure that just randomly picking an address probably will not create a duplicate address.

Re:IoA

[JesseMcDonald]

That would be well and fine if most IPv6 addresses didn't have a 64-bit or even 80-bit prefix, identical for everything routable at the endpoint.

That 64-bit network prefix is the equivalent of 4 billion entire IPv4 internets—and each "host" in each of those internets contains its very own set of 2**32 IPv4 internets in the 64-bit suffix. Quadrupling the number of bits from 32 to 128 means raising the number of addresses to the fourth power (2**32 vs. 2**128 = (2**32)**4). We can afford to spare a few bits for the sake of a more hierarchical and yet automated allocation policy that addresses some of the more glaring issues with IPv4, like the address conflicts which inevitably occur when merging two existing private networks.

Think of it this way: If we manage to be just half as efficient in our use of address bits compared to IPv4, it will still be enough to give every public IPv4 address its own private 32-bit IPv4 internet. Right now the vast majority of IPv6 unicast space is still classified as "reserved", so we have plenty of time to adjust our policies if it turns out that we need to be more frugal.

Then there are DHCP addressing schemes that use the MAC as part of the address, further reducing it.

Automatic address assignment (based on MAC or random addresses or whatever) comes out of the host-specific suffix, not the network prefix, so it doesn't reduce the number of usable addresses any more than the prefix alone. It does imply that you need at least a 64-bit host part in order to ensure globally uniqueness without manual assignment, but the recommended 64-bit split between network and host was already part of the standard.

Re:IoA

[jandrese]

When people talk about an IPv6 address being 128 bits they're technically true but they miss the bigger picture. In practice you can't assign anything smaller than a /64 so really there are only 64 bits of address space as we think of it today. 1 IPv4 address hosting a subnet with NAT vs. an IPv6 /64 prefix are roughly equivalent. It's still way more address space than we'll ever reasonably need, but not quite as ridiculous as it looks at first glance. This also means that 64 bit machines (most of them these days) can compare addresses easily, since you can often ignore either the top or bottom half of the address.

32 bits address

[hcs_$reboot]

It seems Vint engages in self-flagellation each time someone raises the number of limited IPv4 addresses available (like "here"). At the time (40 years ago! The "640k is enough" meme is 'only' 35 y.o!), who would have anticipated the success of Internet? (and for starters, everyone would have reserved the juicy .com domains in the early 90's!). Vint Cerf did an awesome technical and visionary job and deserves a lot of credit for that.

Re:32 bits address

[Dutch Gun]

Yeah, at the time, the thought of needing more than four billion internet addresses probably seemed a bit ludicrous when it was still mostly just government and university mainframes connecting. That number must have seemed like a nearly never-ending well, especially seeing how generously it was initially carved up into massive blocks. Some of the earliest corporations and universities to receive allocations still have a relatively ridiculous number of Class A blocks allocated addresses (16+ million).

We'd probably still have plenty of addresses were those initial blocks handed out a bit more judiciously, but again, part of that was done, if I understand correctly, for simplicity of routing. It's easy to criticize with the hindsight of today's hardware and needs, but those early computers were incredibly restrained on memory and CPU speeds. Even a 64-bit address would have been seen as doubling memory requirements of routing hardware for no good reason.

UTF-8 style would have been better

[Kjella]

So the 1992 UTF-8 specification didn't exist when the 1983 IP specification was created, but they could have done:

First 2^31: 0(31)
Next 2^59: 110(29) 10(30)
Next 2^88: 1110(28) 10(30) 10(30)
Next 2^117: 11110(27) 10(30) 10(30) 10(30)

And just declared that for now it's 0(31) - still 2 billion addresses but the sky is the limit. Heck, they might even have used shorts (16 bit) that way and declared that hardware/software should update as the need approached:

First 2^15: 0(15)
Next 2^27: 110(13) 10(14)
Next 2^40: 1110(12) 10(14) 10(14)
Next 2^53: 11110(11) 10(14) 10(14) 10(14)
(...)
Next 2^140: 1111111111111111(0) 10(14) 10(14) 10(14) 10(14) 10(14) 10(14) 10(14) 10(14) 10(14)

As for PKI, that couldn't possibly have happened. US export regulations wouldn't have allowed it at the time, this was long before Zimmerman and PGP.

48 bit IPs would have been nice

[aberglas]

Would be enough to support even the internet of things, possibly with some very minor NATing. And spared us from the 128 bit monsters. 48 bits is what early Ethernet used, and seemed like a good number.

But I can understand that when IP was developed there were only a few thousand computers in the world likely to be connected, so 16 bits would seem adequate. Using 32 bits would have been a bit of a stretch at that time. Memory and bandwidth were expensive back then.

Bit fields

[Alomex]

Remember boys and girls, always make bit fields extensible. He could have reserved the last part of the upper range (e.g. the ones presently wasted in multicast) for an extended range to be defined in the future. I.e. an address in the upper 224.0.0.0 range is followed by another 32 bits whose meaning would be IPV6 like.

Re:Bit fields

[godrik]

that probably would not have made much of a difference. People would have assumed that this would never happen and would have made practical implementation assuming a fixed 32 bit space. By the time it became a practical problem, we would have had a creep of devices that does not follow the norm, and managing that would be a nightmare.

Just see the sorry state of utf-8. We still have so many code bases that are not utf-8 compliant despite we have seen the need for it over 15 years ago.

Re: I wouldn't have

[demonlapin]

96 bytes was a lot of data in the mid-80s. On a 1200 bps connection, that's almost an entire second per packet. When I was a college student in the early 90s, we had 2400 bps modems in the dialup pool, and the entire university (~3000 students) lived on a 56k leased line. Nowadays, that's trivial. In 1984, not so much.

Crypto? They *removed* that from IPv6...

[Anonymous Coward]

You know, IPv6 AH (authentication -- forged packets are "impossible"), and IPv6 ESP (encryption, for privacy) through IPSEC were a non-optional part of the protocol until a few years ago.

But industry-wide incompetence, the interference from the usual suspects, as well as the usual shit pulled by the embedded space crowd killed it down to "optional". Yes, IPSEC can be nasty (mostly because of IKE), but it would be *something*.

For one, it would have killed DNS poisoning much better, and much earlier, than DNSSEC ever could (hint: DNSSEC has pathetic security as deployed right now).

It is not like the usual suspects had to kill AH to protect their need for mass-spying, making ESP optional would be enough (and outlaw it where required). But no, they need to actually be able to inject false traffic (which *is* against the !@#$!@#$ law everywhere, even for governments)...

Who?

[Hognoxious]

I don't care what this Vince dude thinks. I want to hear what Bennet Haselton has to say.

There *was* a proposal simpler than IPv6.. IPxl

[Anonymous Coward]

http://bill.herrin.us/network/ipxl.html

A one-page solution, too simple of course for a huge committee to accept.

If only someone could have convinced a few key router manufacturers (Cisco) and Linux to adopt this, perhaps we could get critical mass and make IPv6 irrelevant. I guess it wouldn't have been enough of a make-work project though.

Re:Encode as ASCII

[bruce_the_loon]

The major problem your concept would cause is the massive increase in CPU load required to process text instead of simple bit masks, it may not matter for processing a couple of requests a second, but a core router handles trillions of packets and the text comparison process would require massive CPU capacity.

IP address space was designed for very rapid and low processor load bit masking to do route matching. To decide whether a route applies to an address, the netmask is applied to get rid of the more specific parts of the address and reduce the comparison to a simple equality operation.

We see IP addresses as a string of period separated numbers, but the address is the whole 8 byte number as a whole.

Additionally, your concept prevents the multiple path topology of the internet that results in the high resilience to damage we all know and love. Your system results in a single path into any domain space and that domain space is an invisible blob to the rest of the world.

Re:public routing table vs connection tuple

[swb]

I always thought the Netware IPX/SPX network numbering system was quite clever -- 32 bits of network addressing and a 48 bit node address, usually based on MAC addresses.

I always think of how much simpler IP would have been with a similar structure -- subnets could have scaled easily without renumbering or routing when common /24 limits were hit. The use of MAC addresses for node addresses would have eliminated DHCP for the most part or essentially automated it as clients would have only had to query for a network number, not a node address.

Re: I wouldn't have

[Arnold Reinhold]

I attended a persentation about ARPANET by BB&N back in 1971 and I asked about encryption. I was told that if encryption was included, the project would have to be classified, which they didn't want. Instead they expected each link would be encrypted for military use, employing NSA black boxes. On the other hand, Ethernet, developed at Xerox PARC a couple of years later, used 48-bit addressing. If ARPANET had done that, the added two bytes would have been insignificant even then, and we'd have 32,768 times as many addresses in IPv4, and we'd be just fine even with IoT.