I honestly think the creators of IPv6 thought their customer was all the folks buying devices and forgot their real customers were all the sysadmins. They totally failed at making it an easy and rewarding jump from IPv4 to IPv6. Enthusiastic sysadmins would have got the conversion done years ago.
... which is what all those people say over and over who don't have the slightest clue how one could possibly build a system that has an "easier or more rewarding jump". It's always just a completely unsubstantiated "it should have been easier" (when nothing about it is actually difficult) and "it should simply have been backwards compatible" (with no word about how this inherent impossibility should have been accomplished).
Every criticism of IPv6 is downvoted into oblivion, but it doesn't change the fact that great technology is adopted by the target audience quickly if there is this much effort behind it. Where IPv6 hasn't been because it is painful and doesn't make things easier for the folks who have to implement it. It is difficult, and it is different, and they did a poor job of dealing with the conversion from how IPv4 is used (NAT). Sun spent money on Java and got a huge adoption because it solved some serious problems for C++. The amount of broken IPv6 code should have been a clue.
So, you are doing exactly what I said: You say it should have been easier and (more) backwards compatible. With absolutely no word about how that could possibly have been done, nor really even about what the supposed problems actually are, other than a vague "difficult and different". Absolutely nothing of substance.
So, you are doing exactly what I said: You say it should have been easier and (more) backwards compatible. With absolutely no word about how that could possibly have been done, nor really even about what the supposed problems actually are, other than a vague "difficult and different". Absolutely nothing of substance.
No, you aren't getting it. The "supposed problems" start with most networks using NAT and a real lack of conversion or easy bridge strategy. Are you actually saying a network of any size is easily converted to IPv6 with all services coming up fine? Its work and utter disdain for the folks who have to do the work just adds to the problem. They built a second system with all the problems of feature creep when what we needed was some more address space.
Also, what broken IPv6 code?
Check the Windows 10 Spring Creators Update for the latest examples, but a simple search on broken IPv6 code would have yielded the results.
> The "supposed problems" start with most networks using NAT and a real lack of conversion or easy bridge strategy.
First of all, NAT is neither a part of IPv4 nor specific to IPv4. IPv4 works just fine without NAT, apart from the lack of addresses, obviously, and there is nothing in IPv6 that prevents you from doing NAT. It's a stupid idea, but you can do NAT with IPv6 if you insist.
But I guess more importantly: IPv6 was invented when NAT wasn't all that common yet, so really, the original choice was between deploying IPv6 and installing NAT everywhere, and people chose to deploy NAT ... to then complain that there is no transition mechanism from the NAT dead end they chose to the IPv6 alternative they had right from the start?
And also, I don't really see the problem. Why would you need a special transition mechanism? Just don't use NAT?! There is relatively little actual benefit to using NAT anywhere, other than working around the address shortage.
> Are you actually saying a network of any size is easily converted to IPv6 with all services coming up fine?
Why would you possibly want to "convert to IPv6"? You just roll out IPv6 in addition to IPv4 and enable IPv6 on one service at a time and fix up any problems you see!?
NAT is not something that should be preserved, it is 100% a hack that fundamentally breaks the nature of ipv4 and introduces a shitload of statefulness in an otherwise stateless protocol. You can achieve (effectively) identical security semantics with a network firewall, NAT is not something that should be propagated forward.
How about some specifics, rather than rhetorical noise about HOW exactly do you propose that converting any network should have been easier. No matter what it would involve upgrading every network service, and every endpoint. This problem is not avoidable, if it was we could just use the same mechanism to make ipv4 last longer.
Regardless of your feelings on NAT, it exists, its deployed, and it needs to be part of the conversation from the start. If you want people to move off NAT, then it really needed to be gradual. Look at Perl 5 to 6 for how bad this stuff can go (heck, even Python 2 -> 3 was painful).
How about you add the additional 96-bits to the protocol (why 128-bits - that's boil the ocean numbers) and then the protocol sees all the 0.0.0.0 numbers as a short cut for a standard 32-bit range (I supposed with bits above and below for the eventual address expansion) while the : notation is the real full address. Then my day one experience is install the new software that is 128-bit aware and leave all my configs alone since I already have been assigned those in the IPv4 address space. Now we can do some phase 2 to get rid of the evil NAT and clean other clean up.
There are a lot of much smarter people than myself, and I cannot believe someone didn't have a great suggestion to cause a minimum impact on all the folks running systems in the field. I hate burn the bridges system conversion.
> Regardless of your feelings on NAT, it exists, its deployed, and it needs to be part of the conversation from the start.
Why?
> If you want people to move off NAT, then it really needed to be gradual.
Why?
> How about you add the additional 96-bits to the protocol
Yeah, that's a common variant of "they should just have made it backwards compatible".
> (why 128-bits - that's boil the ocean numbers)
That is not how efficient routing works. You cannot expect to fill the complete address space unless you spend excessive amounts of resources on the routing equipment, which has exactly one effect: Boiling the oceans (and/or slowing down the network). In order to keep routing efficiency up, you need a far larger address space than the theoretical minimum required to contain all nodes, because that is how you keep routes aggregated, and therefore the routing tables in the core of the network small, so you can use cheap equipment to move massive amounts of data at low prices.
> and then the protocol sees all the 0.0.0.0 numbers as a short cut for a standard 32-bit range (I supposed with bits above and below for the eventual address expansion) while the : notation is the real full address. Then my day one experience is install the new software that is 128-bit aware and leave all my configs alone since I already have been assigned those in the IPv4 address space. Now we can do some phase 2 to get rid of the evil NAT and clean other clean up.
In other words: You don't have the faintest clue what you are talking about, what you are describing makes no sense, though it sounds somewhat like the common anti-IPv6 crackpot theories.
If you add even a single bit to the address, you have a protocol that is unavoidably completely impossible to interoperate with IPv4. IP is not some markup language, it's a frame format. IPv4 has a fixed sequence of bytes forming the packet header, and in a fixed position in that sequence there are 32 bits for the destination address. Every single IPv4 router and host on the planet uses exactly those 32 bits to make routing decisions. If you insert a bit somewhere, that just moves everything following that bit one bit to the right and therefore makes everything following that bit incomprehensible to every single IPv4 router and host on the planet. The only solution to that is to add support for the additional bit to every single router and host. Sounds familiar?
And it's not just that you have to upgrade every single router and host to complete the transition, it's also that a node that suports the additional bit cannot use that to talk to any node that hasn't been upgraded yet. If you only have an address with the additional bit, and you send a packet to someone who has only a legacy address and doesn't support the new format, they cannot send you a reply, because in order to do so they would have to know how to send a packet to your extended address, and every router along the path would have to be able to do so as well.
So, the only thing that remains that could theoretically have been done would be to reuse the existing IPv4 address space allocations as IPv6 allocations. But first of all, there is no advantage to doing so. The difficult part is adding the protocol support, address allocation isn't difficult. And then, there is a very good reason to start with fresh allocations for IPv6: Routing table fragmentation. The global IPv4 routing table now has ~ 700,000 entries as most ISPs or larger companies have tons of prefixes that they have collected over the decades. The global IPv6 routing table has ~ 50,000 entries, because most ISPs and companies have only one prefix. That means that a pure IPv6 backbone router needs less than a tenth of the TCAM of an IPv4 router, which should considerably reduce costs/improve throughput.
> There are a lot of much smarter people than myself, and I cannot believe someone didn't have a great suggestion to cause a minimum impact on all the folks running systems in the field.
Just as I said: You have no idea how it could have been done, you just know it should have been done better, because doing it better is easy, even though you don't have the slightest clue how.
> I hate burn the bridges system conversion.
Well, great then that IPv6 isn't one of those. You just deploy it in parallel with IPv4, gradually enable IPv6 everywhere, and at some point when you think IPv4 isn't worth it anymore, you switch it off.
It's not like that. People here can come up with plenty of ideas of how to do better, but they have no say in it or even ability to somehow influence it. It's those large corps that push for crappy ideas, as they always need them to be used to sell more stuff, raise barriers to entry, hurt competition, etc. Rule of thumb here is that if doesn't bankrupt a corporation like Cisco it's not a good enough idea.
