4 ms·

Jeez. Eventually someone is going to break down and invent a new IP solution that doubles the number of addresses that we have now. I mean if I were doing it,

Jeez. Eventually someone is going to break down and invent a new IP solution that doubles the number of addresses that we have now. I mean if I were doing it, I'd probably make it more like 1,028 times bigger but maybe it would present as hubris. Addresses would be so plentiful they'd basically be free. And since I am using magic to do all of this, I'd invent it over 20 years ago, so that it'd have been decades since we were still talking about it.

steve918 3y ago
So what's taking you so long?!
- tough 3y ago
  time travel machine mvp is taking a bit more than planned
  - cryptonector 3y ago
    So far it can only go forwards in time [at 1s/s].
VoodooJuJu 3y ago
You could do that, and if you did, I think you'd find a lot of success with your new solution, as people the world over would switch to using it. Just make sure you make it as user-friendly & functional as its predecessor and don't stuff a whole bunch of nonsensical half-baked features into it. Otherwise, people may have no choice but to keep using the older solution.
bastardoperator 3y ago
IPv5 xxx.xxx.xxx.xxx.xxx for the win! /s
- gtvwill 3y ago
  Tbh not sure why the protocol couldn't be upgraded so that xxx.xxx.xxx.xxx, xxxx.xxxx.xxxx.xxxx and xxx.xxx.xxx.xxx.xxx are all accepted. Seems a monumentally shite oversight to not be like that. I mean it's a freaking telephone book address system. Astounding they baked it in just xxx.xxx.xxx.xxx and didn't upgrade the protocol at all in the last 20 years (is this just entirely due to profit/asset protecting?). Response was to make a wholly new protocol when they could have just updated the standard and forced suppliers to patch updates? USB backwards compatability that shiz. The fact I can take a modern usb device and plug it in a 1.1 gen port and it still just works. Why the hell isn't ipv4 like that for upgrades? Seriously is there any real technical hurdle why we didn't do it this way?
  - kelnos 3y ago
    > Seriously is there any real technical hurdle why we didn't do it this way? Yes, because designing and implementing a protocol like USB is nothing like designing and implementing an internetworking protocol. > not sure why the protocol couldn't be upgraded so that xxx.xxx.xxx.xxx, xxxx.xxxx.xxxx.xxxx and xxx.xxx.xxx.xxx.xxx are all accepted You can't just add address bits to a fixed-size protocol header that wasn't intended to be extended in that manner. IP addresses don't actually look like those dotted strings you're talking about. Those representations are for convenience and ease of reading for humans. For computers, it's a 4-byte quantity that's sent over the wire in binary, not a string of base-10 numbers separated by dots. When these things were designed, CPUs, custom processing units, and RAM were incredibly expensive. When you designed a protocol, you designed it for efficiency in size and parsing speed. Otherwise no one would implement your protocol, because it wouldn't be cost-effective to do so. Today we throw around JSON payloads in our HTTP responses without a care for the bandwidth needed or processing power used to parse. If you tried to do something like that back in 1981 when IPv4 was introduced, you'd be laughed out of the room and fired. Your middle suggestion ("xxxx.xxxx.xxxx.xxxx") makes no sense: each part of the dotted-quad notation we're familiar with represents an 8 bit quantity (base-10 numbers 0 through 255). Adding another base-10 digit is nonsensical. The last example, a dotted-...er...quint? is certainly one option, which would increase the address field in the header from 4 to 5 bytes, giving us 256 times the current number of addresses (more or less). IPv6, instead of going from 4 to 5 address bytes, goes to 8 address bytes. That allows us to give every grain of sand on all the Earth's beaches an IPv6 address, several times over. Overkill? Maybe. Probably. But consider how long it's taken to adopt this new protocol. If we were to only add 1 more address byte, and then run out of addresses again, we'd likely have to wait even longer than this time for a future IPv7 to become adopted. Now, going back to the fairly modest 1-byte increase in the address fields (and presumably no other protocol changes). For some devices a fairly simple software update would suffice, but for many router-type hardware of the time (25+ years ago), it wouldn't have been feasible to solely upgrade the software or firmware. Consider that things like routing tables would now require 25% more memory per address, and memory was something routers of the time didn't have in abundance. And some of these older pieces of hardware actually had parts of the protocol "parsing" done in hardware, which you can't change after the fact; you need to scrap the entire thing and build something new. I do agree that it was foolish to design a whole new protocol. If they'd just released a new protocol where the only change was more address bits, I'm sure it'd be fully adopted by now and IPv4 would be a thing of the past.
listenallyall 3y ago
That's awesome. I have no doubt you would use common sense and make the addresses in this new system simple, recognizable, and just an extended version of what everybody is already used to, like 111.222.33.44.55.66
- jedberg 3y ago
  This right here was the biggest mistake for IPv6. Adoption would have been so much easier if IP6s were just "extra numbers" tacked onto the end so that if an old router saw it, it would ignore the extra bits and send it to the "IPv4" part of the address.
  - organsnyder 3y ago
    The potential number of edge cases in IPv4-only hardware is staggering.
    - jedberg 3y ago
      For sure, and they would have been found really quickly. But in either case, it would involve fixing or upgrading the hardware or software, which is true whether we do it with extra numbers or the whole new scheme for IPv6.
  - alphager 3y ago
    That's not how routers or routes work.
    - jedberg 3y ago
      I'm aware of how routers work and this is obviously simplified. But basically you would just have a high part of the address that would be outside the mask, and old routers would just ignore it. So your IPv6 would be 1.2.3.4.5.6.7.8, and old routers would just see 5.6.7.8 and route to the place where that IP should go. The router at 5.6.7.8 would be responsible for understanding IPv6 and how to route from there with the full address.
anyfactor 3y ago
"If we don't study the mistakes of the future, we're bound to repeat them for the first time." - Ken M
hn8305823 3y ago
And I would make sure it had complete feature parity with IPv4 (DHCP, VRRP etc) instead of embarking on a religious crusade to reinvent the way devices connect. It took over a decade to get feature parity from the non-network-operators that overtook the IETF, and that seriously delayed IPv6 adoption.
kelnos 3y ago
I know you're joking & making fun of glacial IPv6 adoption, but if IPv6 was just IPv4 + more address bits, I'm sure it'd be fully adopted by now and IPv4 would be something kids taking computer networking courses would be taught about in the "history" section. IPv6 involved too many other changes to make it a straightforward upgrade. I agree that it's ridiculous that we still don't have universal v6 support, but let's not pretend the protocol designers made it easy.
- cryptonector 3y ago
  To be fair, a lot of the growing pains with IPv6 were pains that had to be discovered as we went. I wish IPng had taken a totally different approach to addressing and routing: - for addressing, yes, very large (or even variable-length, like CNLP, see below) addresses fields in the IPng header - for routing, the IPng header should have had a source and destination ASN fields, with the source being filled in by the sender's router(s) (either immediately in the interior, or at the edge), and the destination ASN fields to be filled in by the sender by querying something like the DNS (but optimized for, essentially, CIDR-style IP->ASN lookups, though DNS can do it). This would have made routing much simpler and faster, since routing protocols would only have to exchange information about ASNs and not about any address prefixes, thus yielding much smaller routing tables. The address->ASN lookup service would have needed very little churn since its contents would change only when sites change Internet service providers. I wasn't there then, so don't blame me, but also honestly I probably wouldn't have thought of this either. In practice we ended up with something just like this but... without address number portability, which is a shame.
- fulafel 3y ago
  There's new features in IPv6 but if you don't use them, it's pretty just more bits as far as applications and users can see. The biggest change is probably replacing ARP, but that part has been unchanged and shipping since the start and invisible to users. And of course there's also simplifications vs IPv4. The biggest shock is for people who have gotten the NAT stockhold syndrome (which always went against IPv4 internet architecture, there's a reason it's outlawed in the standard track IP RFCs).
ericpauley 3y ago
This ongoing "IPv4 with more bits" meme needs to die. There was no way to change IPv4 to have more address space while maintaining compatibility with existing routers. Routers are hardware-accelerated so can't just support new protocols with a software update. If you need a new protocol, why just lengthen the address without fixing other weaknesses, since you'll never be able to change it again? This is IPv6, and while you can argue some changes weren't necessary, it is simply not true say that IPv4 with extra bits would have been easy.

steve918 3y ago

So what's taking you so long?!

tough 3y ago
time travel machine mvp is taking a bit more than planned
- cryptonector 3y ago
  So far it can only go forwards in time [at 1s/s].

VoodooJuJu 3y ago

You could do that, and if you did, I think you'd find a lot of success with your new solution, as people the world over would switch to using it. Just make sure you make it as user-friendly & functional as its predecessor and don't stuff a whole bunch of nonsensical half-baked features into it. Otherwise, people may have no choice but to keep using the older solution.

bastardoperator 3y ago

IPv5 xxx.xxx.xxx.xxx.xxx for the win! /s

gtvwill 3y ago
Tbh not sure why the protocol couldn't be upgraded so that xxx.xxx.xxx.xxx, xxxx.xxxx.xxxx.xxxx and xxx.xxx.xxx.xxx.xxx are all accepted. Seems a monumentally shite oversight to not be like that. I mean it's a freaking telephone book address system. Astounding they baked it in just xxx.xxx.xxx.xxx and didn't upgrade the protocol at all in the last 20 years (is this just entirely due to profit/asset protecting?). Response was to make a wholly new protocol when they could have just updated the standard and forced suppliers to patch updates? USB backwards compatability that shiz. The fact I can take a modern usb device and plug it in a 1.1 gen port and it still just works. Why the hell isn't ipv4 like that for upgrades? Seriously is there any real technical hurdle why we didn't do it this way?
- kelnos 3y ago
  > Seriously is there any real technical hurdle why we didn't do it this way? Yes, because designing and implementing a protocol like USB is nothing like designing and implementing an internetworking protocol. > not sure why the protocol couldn't be upgraded so that xxx.xxx.xxx.xxx, xxxx.xxxx.xxxx.xxxx and xxx.xxx.xxx.xxx.xxx are all accepted You can't just add address bits to a fixed-size protocol header that wasn't intended to be extended in that manner. IP addresses don't actually look like those dotted strings you're talking about. Those representations are for convenience and ease of reading for humans. For computers, it's a 4-byte quantity that's sent over the wire in binary, not a string of base-10 numbers separated by dots. When these things were designed, CPUs, custom processing units, and RAM were incredibly expensive. When you designed a protocol, you designed it for efficiency in size and parsing speed. Otherwise no one would implement your protocol, because it wouldn't be cost-effective to do so. Today we throw around JSON payloads in our HTTP responses without a care for the bandwidth needed or processing power used to parse. If you tried to do something like that back in 1981 when IPv4 was introduced, you'd be laughed out of the room and fired. Your middle suggestion ("xxxx.xxxx.xxxx.xxxx") makes no sense: each part of the dotted-quad notation we're familiar with represents an 8 bit quantity (base-10 numbers 0 through 255). Adding another base-10 digit is nonsensical. The last example, a dotted-...er...quint? is certainly one option, which would increase the address field in the header from 4 to 5 bytes, giving us 256 times the current number of addresses (more or less). IPv6, instead of going from 4 to 5 address bytes, goes to 8 address bytes. That allows us to give every grain of sand on all the Earth's beaches an IPv6 address, several times over. Overkill? Maybe. Probably. But consider how long it's taken to adopt this new protocol. If we were to only add 1 more address byte, and then run out of addresses again, we'd likely have to wait even longer than this time for a future IPv7 to become adopted. Now, going back to the fairly modest 1-byte increase in the address fields (and presumably no other protocol changes). For some devices a fairly simple software update would suffice, but for many router-type hardware of the time (25+ years ago), it wouldn't have been feasible to solely upgrade the software or firmware. Consider that things like routing tables would now require 25% more memory per address, and memory was something routers of the time didn't have in abundance. And some of these older pieces of hardware actually had parts of the protocol "parsing" done in hardware, which you can't change after the fact; you need to scrap the entire thing and build something new. I do agree that it was foolish to design a whole new protocol. If they'd just released a new protocol where the only change was more address bits, I'm sure it'd be fully adopted by now and IPv4 would be a thing of the past.

listenallyall 3y ago

That's awesome. I have no doubt you would use common sense and make the addresses in this new system simple, recognizable, and just an extended version of what everybody is already used to, like 111.222.33.44.55.66

jedberg 3y ago
This right here was the biggest mistake for IPv6. Adoption would have been so much easier if IP6s were just "extra numbers" tacked onto the end so that if an old router saw it, it would ignore the extra bits and send it to the "IPv4" part of the address.
- organsnyder 3y ago
  The potential number of edge cases in IPv4-only hardware is staggering.
  - jedberg 3y ago
    For sure, and they would have been found really quickly. But in either case, it would involve fixing or upgrading the hardware or software, which is true whether we do it with extra numbers or the whole new scheme for IPv6.
- alphager 3y ago
  That's not how routers or routes work.
  - jedberg 3y ago
    I'm aware of how routers work and this is obviously simplified. But basically you would just have a high part of the address that would be outside the mask, and old routers would just ignore it. So your IPv6 would be 1.2.3.4.5.6.7.8, and old routers would just see 5.6.7.8 and route to the place where that IP should go. The router at 5.6.7.8 would be responsible for understanding IPv6 and how to route from there with the full address.

anyfactor 3y ago

"If we don't study the mistakes of the future, we're bound to repeat them for the first time." - Ken M

hn8305823 3y ago

And I would make sure it had complete feature parity with IPv4 (DHCP, VRRP etc) instead of embarking on a religious crusade to reinvent the way devices connect. It took over a decade to get feature parity from the non-network-operators that overtook the IETF, and that seriously delayed IPv6 adoption.

kelnos 3y ago

I know you're joking & making fun of glacial IPv6 adoption, but if IPv6 was just IPv4 + more address bits, I'm sure it'd be fully adopted by now and IPv4 would be something kids taking computer networking courses would be taught about in the "history" section. IPv6 involved too many other changes to make it a straightforward upgrade. I agree that it's ridiculous that we still don't have universal v6 support, but let's not pretend the protocol designers made it easy.

cryptonector 3y ago
To be fair, a lot of the growing pains with IPv6 were pains that had to be discovered as we went. I wish IPng had taken a totally different approach to addressing and routing: - for addressing, yes, very large (or even variable-length, like CNLP, see below) addresses fields in the IPng header - for routing, the IPng header should have had a source and destination ASN fields, with the source being filled in by the sender's router(s) (either immediately in the interior, or at the edge), and the destination ASN fields to be filled in by the sender by querying something like the DNS (but optimized for, essentially, CIDR-style IP->ASN lookups, though DNS can do it). This would have made routing much simpler and faster, since routing protocols would only have to exchange information about ASNs and not about any address prefixes, thus yielding much smaller routing tables. The address->ASN lookup service would have needed very little churn since its contents would change only when sites change Internet service providers. I wasn't there then, so don't blame me, but also honestly I probably wouldn't have thought of this either. In practice we ended up with something just like this but... without address number portability, which is a shame.
fulafel 3y ago
There's new features in IPv6 but if you don't use them, it's pretty just more bits as far as applications and users can see. The biggest change is probably replacing ARP, but that part has been unchanged and shipping since the start and invisible to users. And of course there's also simplifications vs IPv4. The biggest shock is for people who have gotten the NAT stockhold syndrome (which always went against IPv4 internet architecture, there's a reason it's outlawed in the standard track IP RFCs).

ericpauley 3y ago

This ongoing "IPv4 with more bits" meme needs to die. There was no way to change IPv4 to have more address space while maintaining compatibility with existing routers. Routers are hardware-accelerated so can't just support new protocols with a software update. If you need a new protocol, why just lengthen the address without fixing other weaknesses, since you'll never be able to change it again? This is IPv6, and while you can argue some changes weren't necessary, it is simply not true say that IPv4 with extra bits would have been easy.