Slashdot Mirror

← Back to Stories (view on slashdot.org)

What Vint Cerf Would Do Differently (computerworld.com)

Posted by EditorDavid on from the 73-year-old-dreamer dept.

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.

83 of 125 comments (clear)

  1. IoA by Anonymous Coward · · Score: 2, Insightful

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

    1. Re:IoA by hcs_$reboot · · Score: 2

      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!

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    2. Re:IoA by vtcodger · · Score: 1

      Are you sure that one IP address per atom is sufficient? Just to be safe, throw in another address byte. So, 272 bit addresses it will be.

      --
      You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
    3. Re:IoA by jellomizer · · Score: 3, Interesting

      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.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    4. Re:IoA by arth1 · · Score: 1

      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.

      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. Then there are DHCP addressing schemes that use the MAC as part of the address, further reducing it.
      Sure, it can be planned better, but we're doing our damndest already to use up parts of the IPv6 address space through thoughtless assignments and rules.

    5. Re:IoA by suutar · · Score: 1

      we should really round that up to a power of 2, so make it 512 bits.

      Then we can assign addresses to the universes next door too, once we can get there.

    6. Re:IoA by JesseMcDonald · · Score: 3, Informative

      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.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    7. Re:IoA by flargleblarg · · Score: 1

      64bit or 128 bit would take much longer, and slow down nearly everything.

      FTFY.

      Slowdown is a noun. Slow down is the verb you wanted.

    8. Re:IoA by jandrese · · Score: 2

      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.

      --

      I read the internet for the articles.
    9. Re:IoA by Rutulian · · Score: 1

      1 IPv4 address hosting a subnet with NAT vs. an IPv6 /64 prefix are roughly equivalent

      Uhhh....
          2^32 = ~4.3 billion
          2^64 = ~18 billion billion

      So they are only "roughly equivalent" if by that you mean "within 10 orders of magnitude of each other".

      I think you meant "one IPv4 Internet (4.3 billion hosts) where each host NATs an entire IPv4 internet vs. one IPv6 /64 prefix (4.3 billion IPv4 Internets) are exactly equivalent".

      In practice you can't assign anything smaller than a /64
      -- snip --
      It's still way more address space than we'll ever reasonably need, but not quite as ridiculous as it looks at first glance.

      While true, you will get that /64 assigned to you within a /64 prefix. In other words, there are 18 billion billion prefixes each with 18 billion billion addresses, so it really is as ridiculous as it looks at first glance. Not complaining, though....

    10. Re:IoA by Agripa · · Score: 1

      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.

      No worries, ISPs will soon figure out how to issue single IPv6 addresses or at least block all but one unless you pay for the feature of having a complete allocation.

    11. Re:IoA by StikyPad · · Score: 1

      Why not just make it 640k bits? 640k ought to be enough for anybody.

      --
      https://www.eff.org/https-everywhere
    12. Re:IoA by StikyPad · · Score: 1

      NAT is still possible with IPv6. It would really just force people to "break" the internet if they tried something like that.

      --
      https://www.eff.org/https-everywhere
    13. Re:IoA by Agripa · · Score: 1

      NAT is still possible with IPv6. It would really just force people to "break" the internet if they tried something like that.

      Sure NAT is still possible although I would not put it beyond them to eventually try getting people charged with violations of the CFAA or some other law for using it without permission.

      And why wouldn't they want to break the internet? We are after all talking about companies like AT&T who once told me that they were blocking IPv6 tunneling because otherwise customers could get free static IPv6 IPs without paying for them.

    14. Re:IoA by jandrese · · Score: 1

      They're roughly equivalent in that's what you'll be assigned by your ISP. And in practice it doesn't matter if you have 32 bits for your local network or 64, they're effectively unlimited.

      --

      I read the internet for the articles.
  2. Marty... by hcs_$reboot · · Score: 1

    ...it works!.

    --
    Slashdot, fix the reply notifications... You won't get away with it...
  3. I wouldn't have by darkain · · Score: 1

    I personally wouldn't have really changed much. Today, in retrospect, yes, these things are more important. But in the earlier days, adoption was the most important goal of the internet. IPv4 is a relatively easy spec to implement. This goes for routing tables, system administration, hardware support, etc. Yes, the migration to IPv6 is a pain in the ass, but the learning curve for admins and hobbyists as well as the implementation burden on manufacturers some 20-30 years ago simply wouldn't be feasible.

    1. Re: I wouldn't have by ArmoredDragon · · Score: 1

      Especially given how we shed two digits from the year to save memory, I kinda doubt having quadruple the number of bytes in an IP address would fly.

      Still though, it occurs to me that the first internet protocol implementation could have even longer address space than ipv6 without mandating (at the time) unfathomable memory needs. Why did they change that?

    2. Re:I wouldn't have by toejam13 · · Score: 1

      I doubt that using 64 bit or 128 bit addresses would have increased the complexity for users that much. It just would have been a couple of extra characters to type in. IPX used 12 byte protocol addresses and it wasn't that big of a deal.

      For developers, the biggest hassle would have been switching from a single dword to an array of some sort to hold the protocol address on 32 bit systems. No more simple register compares. But next to the logic for handling fragmentation/reassembly and IP options, it still would have been simple.

      It would have been nice to have had something like IPSec transport mode from the start, but only if it were an optional component and if it didn't hard-code encryption or integrity algorithms. Also, for lightweight and low-end systems during the '80s and '90s, mandatory encryption support in the stack would have been overkill. Hobbyists would have preferred a smaller memory footprint.

      I kinda wish that IPv4 would have made IP options a separate header, as they are in IPv6. Variable length IP headers are a little bit of a pain to work with.

    3. Re: I wouldn't have by jgfenix · · Score: 1

      Make the packet size 96 bytes longer. Problem solved.

    4. Re: I wouldn't have by demonlapin · · Score: 5, Insightful

      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.

    5. Re: I wouldn't have by lars_stefan_axelsson · · Score: 1

      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.

      OTOH we didn't run SLIP (PPP wasn't invented yet) over our 1200BPS/2400BPS modems, at least I don't know of anyone who did, except as a test. We ran terminal software to login to the university computers remotely. So address space wouldn't have impacted that much. In fact, where I was, TCP/IP didn't become a thing until we were connected to the internet proper. (1988), but of course YMMV.

      That said, 16 bytes for an address would probably not have flown. But 6 I can sort of see.

      --
      Stefan Axelsson
    6. Re: I wouldn't have by Arnold+Reinhold · · Score: 2

      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.

    7. Re:I wouldn't have by Anonymous Coward · · Score: 1

      That is a common mistake from people not in the field. Packet header size is a concern, but it has never been the worst, or the key concern.

      IPv6 requires at least *double* the TCAM size (it actually requires 4x TCAM than IPv4, but most routers will only hardware-route/forward based on the top 64bits, anything else degrades performance to a crawl by being bumped to the RE CPU for software-based routing). That would be the reason most hardware-based routing hardware has half the route capacity in IPv6 when compared to IPv4.

      TCAM is ECC-protected ultra-fast content-addressed SRAM. It is just as expensive as L1 processor cache, and its latency is a direct low bound on the packet forwarding pace. And you need quite a lot of it to hold the entire FIB.

    8. Re:I wouldn't have by unixisc · · Score: 1

      ipv6 doubles the packet header size.. back then, that would've had significant impacts on performance.

      Yeah, particularly since what we had then were 8 and 16 bit CPUs, and 32 bit was just entering the market. So that would have had a significant hit on an already slow internet at the time. But for those sort of applications, one would already have implemented them in FPGAs and ASICs.

      I agree w/ darkain - we would not have had the opportunity to learn everything we did w/ IPv4. Also, another thing worth considering - at the time IP was conceived in DARPA, the idea was that it would be used only by the DoD, in which case, 32-bits was pretty adequate. Proliferating it in the open market was what exposed its limitations rather quickly, w/ the result that several types of NAT had to be devised.

      However, I think that had we known what we know now, we could have created IPv4 and restricted it to DoD, while we could have created IPv6 and spread it to the world.

    9. Re:I wouldn't have by unixisc · · Score: 1

      As far as routers go, the top 64 bits is the address - anything beyond that would really be handled by the switches. As far as the TCAM goes, w/ all the advances in process technology and CPUs, wouldn't the TCAMs have advanced as well? And if they are that expensive, as they would be since they don't normally go into consumer goods, then wouldn't companies like Intel be giving them capacity in some of their most advanced fabs?? I would sure prefer manufacturing that over SRAM, not to mention DRAM

    10. Re:I wouldn't have by unixisc · · Score: 1

      Actually, it was not so much the hoarding - it was the idea of Class addresses that was IPv4's undoing. By having Class A and Class B routable addresses, companies like DEC ended up w/ whole blocks that they were never going to exhaust. Not a bad idea when IPv4 was just the domain of the DoD. It's when it became the de facto internet standard that the shortcomings of Class addresses showed through

  4. 32 bits address by hcs_$reboot · · Score: 3, Insightful

    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.

    --
    Slashdot, fix the reply notifications... You won't get away with it...
    1. Re:32 bits address by hcs_$reboot · · Score: 1

      Vint Cerf did an awesome technical and visionary job*

      *and still does! (at Google)

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    2. Re:32 bits address by Dutch+Gun · · Score: 2

      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.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    3. Re:32 bits address by rjstanford · · Score: 1

      You're welcome to pay for the memory upgrades to the world's routers to hold the routing table full of those /32s (16M per /8 that you've "freed"); the current full routing table is ~620k entries.

      And as we all remember, 640k should be enough for everyone!

      Still leaves 20k though, as long as we're mixing our units...

      --
      You're special forces then? That's great! I just love your olympics!
    4. Re:32 bits address by unixisc · · Score: 1

      I don't agree that 4 billion was ludicrous. Just theoretically. I mean, the world had more than a billion people then, which could easily be imagined as growing to 4 billion. If one imagined that each person would have something in his hand that would require an IP address, there was the case right there that 4 billion wouldn't suffice.

      64 would have - if we had that, then we could have had Class B size subnets for everything, and everything beyond address 16 would have been the network address.

    5. Re:32 bits address by unixisc · · Score: 1

      I agree w/ that, but how many .us websites or domains have you come across?

  5. Encryption was expensive by Lieutenant_Dan · · Score: 1

    Computationally that is, I don't think it would have flown in the early 90s and the adoption rate would have been the same it was with SSL (and TLS). It wasn't not so long ago that I actually had to provide resource impact reports on servers where everything would be encrypted. Nowadays (unless you deal with extreme large volumes), encrypting (using an symmetric key that is) doesn't have a significant impact. Web servers, load-balancers, etc can support it without breaking a sweat.

    --
    Wearing pants should always be optional.
  6. How dare you! by Masked+Coward · · Score: 1

    I really hate these people who take credit for my brilliant invention. Something you peons refer to as "the internets."

    Oh well, at least I can still take full credit for my hockey stick.

    Sincerley,
    Al Gore

    1. Re: How dare you! by K.+S.+Kyosuke · · Score: 1

      Vint Cerf certainly used a lot of algoreithms when inventing the Internet. So Al Gore totally deserves some credit.

      --
      Ezekiel 23:20
    2. Re: How dare you! by wonkey_monkey · · Score: 1

      First, All Gore never said that.

      That's okay, because GP isn't actually Al Gore.

      --
      systemd is Roko's Basilisk.
    3. Re: How dare you! by unixisc · · Score: 1

      And I give him full credit for his brilliant concept of an 'open source website' (story there on /. somewhere)

  7. UTF-8 style would have been better by Kjella · · Score: 3, Insightful

    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.

    --
    Live today, because you never know what tomorrow brings
    1. Re:UTF-8 style would have been better by Shimbo · · Score: 1

      Variable length addresses aren't a new idea, and there were some advocates for IPv6. However, a lot of the IPv6 changes were made to streamline the IP header, to make it faster for intermediate systems to process. Using a variable length field would add complexity. More general isn't necessarily better, else we would be using BigInts everywhere.

    2. Re:UTF-8 style would have been better by 91degrees · · Score: 1

      I can see a justification for fixed size packets though. Still, nice to have the flexibility. My other thought is that you should have a gateway with a short address and anything that uses it a longer address. E.g. find some way to have 123.45 as your gateway, and 123.45.1 through 123.45.256 as machines on the subnet. Maybe just zero terminate the addresses.

      I thought it might have been possible to do some sort of nested packet idea. Something like 0-7FFFFFFF are global addresses, 80000000-FFFFFFFF are local subnets allocated as the administrator sees fit. So either each can be an individual machine, or there could be a second, third or greater level of subnet. Each level only need to understand how the level below it works.

      You encapsulate a local subnet packet as part o the packet. Top level then sends that to the right place. No idea how the "from" address would work though.

  8. 48 bit IPs would have been nice by aberglas · · Score: 2

    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.

    1. Re:48 bit IPs would have been nice by hcs_$reboot · · Score: 1

      1976...! You were only 40 years old!

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    2. Re:48 bit IPs would have been nice by NoNonAlphaCharsHere · · Score: 1

      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.

      Ummmmmmm... Have you ever seen an IP (v4) address?

    3. Re:48 bit IPs would have been nice by Megane · · Score: 1

      48 or 64 bit addresses would have been enough, IPv6 only used 128 bits because its designers wanted to be really, really, really sure that we wouldn't run out, this time, for sure. The initial classful address allocations didn't help, but we eventually reached a point where a single wasted class A only puts off exhaustion by a few months. What broke everything in the end was the sheer enormous number of addresses used by mobile networks. Now we have enough bits that we can use Ethernet MACs as part of routable addresses and still have plenty.

      The problem is that back when IP was new, even 56Kbps was considered fast. TCP headers are already 20 bytes. The overhead of 4 more bytes per packet would have been significant, but 12 more bytes per packet? That's 2ms per packet at 56K asynchronous, and 12ms at 9600 bps. PPP had a way to shorten headers for this reason, but it was a later protocol, after the more obvious SLIP had already been in use.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    4. Re:48 bit IPs would have been nice by unixisc · · Score: 1

      In a Classful IPv4 setup, the max you have is Class A, or 2^24. I've never heard of a Class A being superneted to support a larger network.

      Therefore, I think that in IPv6, having a whole 64 bits dedicated to the interface ID is a total waste, even allowing for autoconfiguration. Even if they had assigned the bottom 32 bits to the interface ID, they'd have a subnet equal to the entire IPv4 network (sans NAT'ed ones). Then the entire top half of the address would have been the Global Prefix, and the subnet would have been bits 64-95. Which would also support the maximum number of classful subnets that IPv4 would have as well

  9. Bit fields by Alomex · · Score: 2

    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.

    1. Re:Bit fields by godrik · · Score: 2

      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.

    2. Re: Bit fields by tylersoze · · Score: 1

      From the linked article: "There was debate about the possibility of variable-length addresses, but proponents of the idea were ultimately defeated because of the extra processing power "

    3. Re: Bit fields by Alomex · · Score: 1

      I know that was the excuse, and it is bogus, since you can simply ignore the extensible field in the first hardware implementation. It's not until the extension is used, many years into the future, that you have to have the processing power to handle it.

    4. Re:Bit fields by Alomex · · Score: 1

      Not any more of a nightmare than the IPv4 to IPv6 conversion which has been in the making for twenty years now.

    5. Re:Bit fields by Kjella · · Score: 1

      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.

      Yes, but it would have put more pressure on the existing user base like Y2K compliance to follow the "full" standard. Right now it's like we're on IPv4, tagged WORKS4ME so why bother with IPv6. But I know I've made many more "shortcuts" than limiting something to 4 billion...

      --
      Live today, because you never know what tomorrow brings
    6. Re:Bit fields by hcs_$reboot · · Score: 1

      Some ranges were reserved! But due to Internet explosion they were used at some time, anyway

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    7. Re:Bit fields by AmiMoJo · · Score: 1

      I think you could solve the old, incompatible device issue with something like NAT. It would be horrible of course, but so is IPv6. And most stuff would be updated - IPv6 has been supported since the 90s.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    8. Re:Bit fields by Junta · · Score: 1

      It seems funny, because that *ultimately* is the reality of IPv6.

      The difference is that in the above scheme, *knowing* whether a hop in the network could or could not do 'big addresses' would be more difficult. With IPv6, it allows things to be very clearly delineated whether the communication is IPv6 capable or not.

      The biggest obstacle to IPv6 was the stubborn resistance to any form of NAT. That IPv6 should be all or nothing. The piece needed to make IPv6-only *clients* possible was carrier grade NAT64. Yes, on the server and as a carrier, you need IPv4 *and* IPv6, but the vast bulk of endpoints can be IPv6-only now, taking the pressure off of IPv4. Of course this would have been nice to do a decade ago instead of the last two years or so, so that new servers could have a more comfortable time getting IPv4.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    9. Re:Bit fields by Junta · · Score: 1

      Actually, I'd say it would be more of a nightmare. Here we have the devils we know. In that scenario, it would be hellish even *knowing* what can't handle things.

      Every hop in the network not being certain whether the next hop could or could not handle the conversation would be a nightmare in the making.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  10. who cares by lucm · · Score: 1

    that's like asking Henry Ford how he would make tesla autopilot problems go away

    --
    lucm, indeed.
  11. public routing table vs connection tuple by epine · · Score: 1

    Even a 64-bit address would have been seen as doubling memory requirements of routing hardware for no good reason.

    There could have been an optional 32-bit client sub-address ignored by the public routing backbone.

    Then, for most purposes, non-backbone routers need two routing tables: a routing table for the public network (if more complex than a few simple gateways), and an organization-local internal routing table (with 32-bit addresses, just like the public table).

    The actual problem is that each TCP/IP connection would require for the connection tuple (src_IP, src_port, dst_IP, dst_port) not 12 bytes, but 20 bytes.

    Probably something could have been done to mitigate that, too, as things stood long ago, but I don't feel like speculating further just now.

    Even without mitigation, let's suppose you have an FTP server and you want to guarantee at least 16 kb/s for each active FTP connection (circa 14.4/28.8 modem technology). You need to provide nearly a kbit/s network bandwidth per byte of connection tuple held in system memory (we'll ignore the messy nature of FTP, much of whose ugliness could have been averted by a better original IP design).

    At the same time, NAT isn't all bad. It does help to conceal the internal structure of your network from the evil public network (and makes exposing your non-firewall hosts more of a sin of commission rather than a simple sin of omission).

    NAT also erects a barrier to ultimate host fingerprinting and traffic analysis, at least until HTTP came along to ruin things with user agent strings and cookies.

    Some people are quick to point out that a low barrier is no barrier at all, but I like to force my adversaries to at least put on their ballet shoes before attacking my network, and then to stay alert for people with trunks full of tools good at hopping low barriers.

    My proposal doesn't much complicate the backbone routing table, except for Sandvine, who would have—once we got there—been pissed in a big way (counterfactually), to much rejoicing.

    1. Re:public routing table vs connection tuple by Sique · · Score: 1

      As soon as you have regulary data transfers from any point to a publicly accessible network, you can do fingerprinting. It's not HTTP per se, that's the culprit. Any other protocol becoming popular could have been used. HTTP is just the one most popular.

      --
      .sig: Sique *sigh*
    2. Re:public routing table vs connection tuple by swb · · Score: 3, Interesting

      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.

    3. Re:public routing table vs connection tuple by unixisc · · Score: 1

      There are 3 ways of assigning IPv6 addresses. One is SLAAC, which is the usage of MAC addresses in EUI-64. Another is privacy extensions. The third is the use of DHCP v6, which would be analogous to DHCP v4 in IPv4. The third would be the ideal way to do it - manage the networks logically, and avoid needing >1 /64.

      'NAT' on IPv6 is a Prefix translator, which avoids the pitfalls of NAT on IPv4, while retaining its advantages. It is a 1:1 relationship b/w a global unicast address and a site local address: it doesn't touch the interface ID. So you can use it for load balancing, you can use it if you change ISPs w/o disturbing the internal network, but you don't need to map one global unicast address to several site local addresses. So one avoids the need to consume port numbers that may be needed by applications.

  12. Crypto? They *removed* that from IPv6... by Anonymous Coward · · Score: 2, Interesting

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

  13. I manage Internet connections in 148 locations... by Anonymous Coward · · Score: 1

    and none support IPv6. I think the move from 4 to 6 has already failed.

  14. Who? by Hognoxious · · Score: 2, Funny

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

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  15. CIDR, large memory, and bps(and baud) by gavron · · Score: 1

    Going from 32-bit addresses to 128-bit addresses at the outset would have meant the IMPs and then the NSFnet routers (Cisco AGS+s) would have had the routing tables take up 4x the space (well 257/65s but who's counting). That would have meant a more severe and quicker router memory exhaustion with backbone routes, and a quicker move to CIDR (where we specify NETWORK/NUMBER-OF-CONSECUTIVE-1-BITS instead of NETWORK/MASK).

    For every choice we ever make (routers, IP design, freeway offramp selection, etc.) if the choice has no downside and an upside... we do it... because it's stupid not to. For most of the choices, however, there's a tradeoff of an upside and a downside. In the IPv4 design 32 bits was (in the late 1970s!!! long before PCs, smartphones, IoT, etc.) was assumed to be more IP addresses than anyone would want... which is why more than 1/4 of them were never made available for assignment (Class "D", Net10, Net26, Net127, etc. and RFC-1918 taken out because sysadmins left their boxes configured with mfg default IP addresses.)

    I appreciate the contributions Vint Cerf made but I can tell you that running IPv4 on 9600bps modems (back then "MODEMs") meant that we tried to send LARGE packets to make the payload-to-header ratio high but then SHORT packets to make the "responsiveness" (latency) seem acceptable. If each packet header went from 40-64 bytes to 192 bytes larger... that ratio would have significantly impacted any "real-time" (low-latency) performance. That would have impacted those of us using TELNET (ssh not yet invented), accessing BBSs, BiX, Compuserve, etc.

    It's wishful thinking to look at a world where our smartphones have 32GB of memory and our data communication speed are measured in 10s of Mbps and long wistfully to have designed the header structure of RFC-793 where computers had 64KBytes (not MBytes) and communication speeds of 110baud (1970s).

    Ehud Gavron
    Tucson AZ

  16. There *was* a proposal simpler than IPv6.. IPxl by Anonymous Coward · · Score: 3, Interesting

    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.

    1. Re:There *was* a proposal simpler than IPv6.. IPxl by Dagger2 · · Score: 1

      IPv6 is a one-page solution too, if you ignore all of the actual details.

      As a small example, consider these two paragraphs that the page says for DNS:

      Name to address mapping is performed with the AX record. AX returns a 64-bit IP address instead of a 32-bit IP address. A DNS server which supports IPxl should automatically translate any known A records for a given name to AX records by prepending 0.0.0.1 to the address. It should likewise automatically translate any AX records with the prefix 0.0.0.1 into A records.

      PTR records for IPxl are located under "ipxl.arpa" and work the same way as the records in "in-addr.arpa". A special tree will be created for *.1.0.0.0.ipxl.arpa which CNAMEs each individual record to the respective record in in-addr.arpa leaving the in-addr.arpa zone authoritative.

      And here's what the v6 equivalent would look like:

      Name to address mapping is performed with the AAAA record. AAAA returns a 128-bit IP address instead of a 32-bit IP address.

      PTR records for IPv6 are located under "ip6.arpa" and work in much the same way as the records in "in-addr.arpa", except that each level of the hierarchy represents one hex nibble rather than one byte.

      It's a lot simpler, even. And then it comes time to actually specify the standards, and you need to issue an RFC that adds an AAAA (AX) record type to DNS, and an RFC that specifies rDNS and instructs IANA to create the reverse zone, and RFCs that tell people how to handle a mixture of AAAA (AX) and A, and RFCs that cover SMTP's MX record interaction with AAAAs/AXs, and oh let's not forget that there's no standard API for looking up non-A records in programs so you've got to specify that too.

      The only reason IPv6 is so "complicated" is because we did go through and specify the necessary changes to all affected protocols. All of these "one page alternatives" would've had to do the exact same thing to get them operational, and thus would have ended up with just as much "make-work" as v6. Except it's not make work, it's the necessary work to support expanded addresses.

    2. Re:There *was* a proposal simpler than IPv6.. IPxl by headbulb · · Score: 1

      What hardware concerns does IPv6 actually address? Far as I can tell it was created without too much concern for hardware. 128 bits for example. Most cpu's are going to have to use multiple cpu cycles. Due to registers being 32/64 bit (not including simd extensions.) These aren't really a concern considering how fast our computers are and that networking gear has special processors.

      IPv6 fails in a few areas that some people refuse to even acknowledge. If they wanted IPv6 to be successful they would have kept it simple. For example getting rid of broadcast in favor or multicast. Another is the complete waste of addresses, each of my interfaces gets multiple /64 and then assigns the rest of the 64bit (randomly or from the mac address) if we were going to waste that many address we should have just stuck with 64bit.

      64 bit addresses would have hit all the boxes of needs that ipv6 provides. BGP routes not taking up so much memory and being simpler globally. Every device being able to reasonably have it's own globally unique address.(Not every device needs a unique address) 128 bits is stupidly large, 33 bits for example is double the size of 32 bits. For each bit we are doubling.

      IPv6 fails because they didn't think to make it simple. Embedded devices need to be simple, not every manufacturer is going to pay for the best programmers. I've dealt with too many "modems/routers" that barely understood ipv4 let alone ipv6.

      IPxl if implemented could work. I see it as the same hack that UTF8 uses. It faces the same exact problem the IPv6 faces, Software/hardware would have to be upgraded. IPxl could then take the good stuff such as prefix delegation. (We are keeping dhcp and arp)

  17. Yeah Right by williamyf · · Score: 1

    At the same time he was doing IPv4, CLNS/CLNP was using 20BYTE Addresses (variable lenght). And Xerox (which Cerf himself credits with inspiration to his project) was using 12Byte Addresses. So that excuse of "could not have done it" is Bollocks.

    As for encryption, that's what optional headers are for! Should have defined two or three of those fron the start: Weak encription (to handle export/munitions restrictions of the time), strong encription (either for countries which are not under US influence, or when the exports/munition restrictions were lifted) and PKC encription (for the nascent field of public key crypto).

    Besides, i am not sure what was his influence on the IPv6 designers, and their ill fated idea of removing the IP checksums... :-(

     

    --
    *** Suerte a todos y Feliz dia!
    1. Re:Yeah Right by Megane · · Score: 1

      But were those long address protocols designed to be routable in a worldwide network? Sure, Ethernet had a 48-bit address too, but it was only intended to be a unique hardware ID. There is no way to contact an arbitrary Ethernet MAC address outside of your LAN, even if you already know that it exists. Were they designed to work with the low-speed serial links that were common back in the day? Sure, you can spare a few extra bits when you've got over a million per second, but not when you've got a mere thousands of bits per second.

      Back in those days communications were slow (56Kbps was about 6 characters per second, or 7cps synchronous). And CPUs weren't fast. People wouldn't have tolerated protocols that took up a significant percentage of CPU time. More importantly, fast routing depends on custom logic to handle headers without a CPU, and variable-length headers make this much harder. IPv6's optional headers are tricky enough, but variable address lengths would have been very hard to process with custom logic.

      And encryption? It was literally a non-issue for network protocols back in those days because it is so compute-intensive. The point of a network protocol is to route data, you don't stick something as expensive as encryption on the lower layers without a good reason, such as wireless transmission. WiFi has link-layer encryption, but that disappears once the data goes onto a wire. And if you're not going to encrypt the headers anyhow (how do you use the options that specify encryption in an already encrypted header?), then why the fuck even bother? If the data needs to be encrypted, put that at layer 5 or 6 or 7 of the protocol.

      Also, which algorithm? Any sufficiently fast algorithm from those days would be useless today. DES was brand new in the '70s, and eventually got chips, but you're going to require one of those in every network node? There are still unanswered questions about how its specific design was chosen. All specifying an algorithm would do is keep a bad algorithm alive forever. SSL is still trying to shake off bad algorithms. We've already thrown away at least two generations of encryption just for WiFi alone, that you can still use, and it's barely 20 years old. And yes, the munitions bullshit was another reason why they would have kept it completely out of the network protocol. It just isn't the business of a routing protocol to deal with encryption.

      Hindsight is easy when you don't consider the limitations of what was knowable or possible back in the day. Very few things (other than perhaps the limitations of classful routing) could have been foreseen in what was still considered a mostly experimental system. There was no way they could have known that TCP/IP (which wasn't even their first protocol!) would have ended up the winner and persisted for decades until long after the point where it had run out of addresses.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    2. Re:Yeah Right by david_thornley · · Score: 1

      At the time, I saw some people claiming that 300bps was all people really needed, since as text it was about 300 wpm, and most people couldn't read that fast.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  18. Re:Encode as ASCII by bruce_the_loon · · Score: 3, Insightful

    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.

    --
    Trying to become famous by taking photos. Visit my homepage please.
  19. What I would do different is DNS related by houghi · · Score: 1

    Sure, security would have been nice. I do understand that it was not an issue when this came up. Here is what I would different that would affect ALL of the Internet and that is DNS.
    1) First I would have done only countries and no other TLD. I can hear people scream "What about "Debian.org" and other non-profit or international companies?
    Well, they all have an address, so it would have become Debian.us or they look at countries where it wouid have been cheaper or easier and it could have been debian.cc or debian.de or any other that they wanted, Each country then could have selected their respective solution, like com.au or not as they pleased.

    2) Change the order So we begin with the country and then the TLD, next whatever you want. So http://us.debian.www/directory...
    Or http://us.slashdot.tech/dir/fi...

    --
    Don't fight for your country, if your country does not fight for you.
    1. Re:What I would do different is DNS related by JesseMcDonald · · Score: 1

      1) First I would have done only countries and no other TLD.

      Personally, I would have done the opposite, and demoted country-specific sites to a second-level domain like .us.gov. The Internet is an international network; forcing every domain to be classified first and foremost according to its national origin would cause needless discord. Only a small minority of sites are truly country-specific.

      it could have been debian.cc or debian.de or any other that they wanted

      In which case the country code would communicate zero information about the site—so why have it at all?

      What might make more sense would be using registrars as TLDs (e.g. google.mm for MarkMonitor), with a convention that multiple TLDs can contain the same subdomains if and only if they mirror each other. This would tie in well with DNSSEC while also avoiding the need to defend one's domain name against scammers in a million separate TLDs. If a government just happens to run its own registrar it could use the country code for its TLD alongside non-country TLDs. The main difference from the current system would be that TLDs would be generic rather than catering to a particular kind of site, which is mostly the case in practice anyway: .com no longer implies commerce, not every .org is a non-profit, .net does not imply an ISP, etc. Instead, the TLD would imply a trust relationship; the name "google.mm" would imply looking up the "google" subdomain in the MarkMonitor domain registry, which would presumably be listed among the user's local trust anchors. If there were an alternative domain like "google.vs" (for VeriSign) it would be required to resolve to the same address.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
  20. Re:what all of us would do differently, if by Big+Hairy+Ian · · Score: 1

    Hindsight: The ability to look back at past events and state that we should have done things we didn't even dream were possible at the time.

    --

    Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

  21. Why not a scalable address space? by master_p · · Score: 1

    Why hard code the size of addresses? for just a single bit of information, the ip headers could contain either the standard address or an extensible one.

    That would have been really clever from his part.

  22. Re: I manage Internet connections in 148 locations by Dagger2 · · Score: 1

    Assuming you meant Comcast, they should have v6 deployed over their entire network. Qwest are apparently doing 6rd so you should be able to get v6 with them too, albeit over a tunnel.

    Can't comment on dialup though. I suspect most ISPs would rather just let their dialup platforms die rather than change anything about them.

  23. Re:I manage Internet connections in 148 locations. by Junta · · Score: 1

    When I pull up my cell phone ip information, it's IPv6.

    Now that there's carrier-grade nat to allow ipv6-only endpoints to speak to ipv4-only hosts, it *finally* is plausible to offer most mobile/residential ipv6-only. So a lot of the people who are ipv6-only are precisely the ones that would never realize it.

    For enterprise networks and internal networks, those are ipv4 and likely to stay ipv4-only (which is a bummer for software development, because IPv4/IPv6 agnostic code is still relatively rare, since there's so many subtle bugs trying to use AF_INET6 for both, and it's more complicated to have both AF_INET and AF_INET6 addresses).

    --
    XML is like violence. If it doesn't solve the problem, use more.
  24. Re:Crypto? They *removed* that from IPv6... by Junta · · Score: 1

    I personally would rather *not* have crypto at the IP or TCP layer. Reason being is that in practical terms, updates *must* be delivered through kernel updates. Given the nature of crypto updates, I'd much rather have librariers in userspace be the channel for updates.

    I don't think I need a big conspiracy about AH/ESP. They were really awkward approaches, and largely redundant with higher layer strategies.

    The issues with DNS/DNSSEC are more reasonably addressed in the DNS layer. There is a lack of will to tackle that problem, but that's the same lack of will that would make implementing at a lower layer impractical as well.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  25. what else? by bodog · · Score: 1

    OK, so what was a viable competitor to IPv.4 or v.anything, actually.....

  26. Re: I manage Internet connections in 148 locations by JesseMcDonald · · Score: 1

    Qwest are apparently doing 6rd so you should be able to get v6 with them too, albeit over a tunnel.

    I have this set up, and can attest that it works reasonably well. The only real problem is that (presumably unlike native IPv6) you aren't assigned a static IPv6 prefix; it's tied to your dynamic IPv4 address. Consequently, I also have a Hurricane Electric tunnel configured with a static IPv6 prefix for use in DNS. This required some complicated source-based routing rules, though, so it's not for everyone. (You can't route HE packets out over the 6rd tunnel or vice-versa, and normal routing only looks at the destination address. To make it work you have to set up multiple routing tables ("ip route table ...") and select the proper one based on the source address ("ip rule add from ... table ...").

    Of course, one could just pay extra $$$ for a static IPv4 address, which would provide a static 6rd prefix...

    --
    "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
  27. Re:Crypto? They *removed* that from IPv6... by Agripa · · Score: 1

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

    Better to kill AH now to prevent people from thinking they have a right to any unapproved and secure cryptography. Plus there is the whole wanting to inject false traffic issue.

  28. Re:Crypto? They *removed* that from IPv6... by Agripa · · Score: 1

    I don't think I need a big conspiracy about AH/ESP. They were really awkward approaches, and largely redundant with higher layer strategies.

    They were made really awkward by the conspiracy to prevent usage.