3 ms·
Again, this is kind of making my point. IPv4 had an excuse for being a bit crap, because it was designed in the early 1980s. IPv6 should have been much better t
by gnfargbl 4y ago
Again, this is kind of making my point. IPv4 had an excuse for being a bit crap, because it was designed in the early 1980s. IPv6 should have been much better than it is.
Adoption was always going to be slow, but it never needed to be this slow. If the designers had thought a but more about usability and not done stupid stuff like making the address space contain twice as many bits as it actually needs, then we would have transitioned by now.
- keiyakins 4y agoIPv6 was designed in the late 80s/early 90s, before home users had internet access. At the time there was serious debate over switching to the OSI stack instead. You're showing your lack of history knowledge more than anything.
- NegativeK 4y agoIPv6's introduction is closer to IPv4's introduction that to now. By nearly twice as much.
- ipython 4y agoIt should be mentioned that 2^32 was widely considered to be unfathomongly large when ipv4 was developed as well. However now we are pumping out something like 4 ARM cores per person on the planet, per year. Clearly we will need to plan for those devices to communicate. Also the effective address space in ipv6 is much smaller than 2^128 as the default subnet prefix is /64. So in a sense, it has already “addressed” your concern? Pun intended.
- zamadatix 4y agoI could say IPv6 addresses should have been 8 bits because it would have been more usable but that's not reasoning I'm right and IPv6 is a mediocre design-by-committee protocol it's just me lambasting the designers based on some number I thought sounded nice. If the addresses were 64 bit instead of 128 bit the situation wouldn't be any different, beyond IPv6 would be harder to use. For humans unused bits end up hidden when written out and for machines most of the bits are used and are used in a way that make it scale and be simplified over using fewer bits. E.g. the assumption that every user subnet is a /64 instead of based on the number of devices in it is a massive simplification that hides a ton of complexity people ran into with IPv4 networks. /48 being the minimum aggregate advertisable on the internet makes the number of participants in the internet scale much better. Giving RIRs blocks of /23 leaves room to expand as assignments grow in the future - avoiding the problem we hit with IPv4. Just saying "half the bits is simpler" doesn't actually make your assumptions correct or the deployment happen any faster. To re-iterate on this part: The problem isn't the protocol it's that there is little incentive for the average user to switch to anything else on their own volition when most didn't even really set up what they are switching from (and already working on today) anyways. That's not to say the end user needs a more "usable" protocol so it becomes attractive to switch - that's not where the lack of attractiveness sources. The cost to use the protocol could be 0 (and IPv6 is actually extremely close to that to be honest) and there is still no incentive for consumers or businesses to make the switch yet. Even if everything goes perfect and is 100% done without any human intervention it still provides them no benefit until very recently when IPv4 prices started to rise so why would anyone have rushed to make the switch 20 years ago? An example of this comes back to the cell carriers - they didn't go to IPv6 because they just like and have the time to do complicated things it was the simplest way to enable mobility across their networks with a large scale of devices. They hit this need much sooner than the price of a /24 went up enough for people to start caring so they pushed for their networks and phones to support this faster (on top of needing to build out a lot of new greenfield stuff anyways so why bother building greenfield with the old).