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

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.

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.

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.

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