Great example of how fixing things "the correct way" does not seem to work sometimes.
They added those new addresses that can store more information.. but this requires a rewrite of old software to make it work.
If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work.
> If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work.
In every fucking IPv6 thread this "just add more addresses" idea comes up. There is no "just" in expanding the address space:
"""
Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:
1. You have to change the version number.
2. You have to add new code to handle the new version.
Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So,
3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol.
Two minutes of thought show that this third requirement has only two solutions:
(3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses between the old and new protocols.
This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it.
Yes, we want ipv5 that just does 1, 2, 3 instead of ipv6 which does the most complicated variants of those and more. We didn't have requirements 4. change all the pre-existing addresses 5. make addresses randomly assigned 6. make routers accept inbound connections by default 7. give every device its own public IP by default. Ipv6 did those anyway.
Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me.
> Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me.
Yeah… from the above link:
"""
Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The related "IPv4-Mapped IPv6 address" format is still valid and has a role in the POSIX socket API. Mappings of this kind also figured in the moderately successful coexistence technologies known as 6to4 [RFC3056, RFC3068] and Teredo [RFC4380], which have now been overtaken by events.
The people who created IPv6 weren't stupid: if you think you've thought up of a new idea, you probably haven't. Your "new idea" is either in the exact same situation as IPv6 or it was actually attempted and ended up being discarded.
6to4 wasn't that. 8.8.8.8 didn't get routed to you in v6, instead it went to a relay server that then translated to v4 then sent it to you. And even if you actually owned 8.8.8.8, it didn't give you 8.8.8.8.1 etc, because it was just some bolt-on for transitioning from v4. I just want to own 8.8.8.8(.0.0.0.0) in v6 and that's it, not have my v6 actually be abcd::1234::...
I don't think they were dumb, they wanted to start with a clean slate and underestimated the difficulty.
> 7. give every device its own public IP by default.
Both of these are optional. Don’t want them? Don’t use them - if you don’t configure them, it won’t happen.
> 6. make routers accept inbound connections by default
That’s not a new feature with v6.
> Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0.0 now. If anyone switches to the new thing, they know where to find me.
Now you (and everything in between) have to be able to handle packets addressed to 8.8.8.8 and 8.8.8.8.0.0.0.0, so you’ve done point 4 without knowing it.
Oh I mixed it up with 3. Yes you don't need #4. I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1, so it's 1:1 but not onto. Instead v6 did completely new /64s with random addrs inside, no association with the v4 addrs.
About the others being optional, no they aren't really, because most devices will implement the minimum. Android doesn't support dhcp6. My router is like most and has no option to enable dhcp6 or nat6 anyway.
Ipv6 spec also says that a router could either default allow in or not via its firewall. In reality it's usually default deny, but not always, hence the freakouts people have about security in v6. V4 spec doesn't know about NAT, but in real life the answer is no you don't get inbound connections or even a publicly routable address unless you deliberately configured that.
> I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1
"v-next" 8.8.8.8 isn't the same thing as IPv4 8.8.8.8, so you now have two "interfaces" running different versions of IP with identical addresses.
> because most devices will implement the minimum. Android doesn't support dhcp6. My router is like most and has no option to enable dhcp6 or nat6 anyway.
Sucks to be you but irrelevant to the protocol.
> Ipv6 spec also says that a router could either default allow in or not via its firewall.
Just like in IPv4 - in the pre-NAT world (or if your ISP assigned you a block of v4 addresses), if you were connecting a device to the public internet it would have be assigned a routable v4 address and it would be up to the administrator what traffic they accepted.
> "v-next" 8.8.8.8 isn't the same thing as IPv4 8.8.8.8, so you now have two "interfaces" running different versions of IP with identical addresses.
Yes that's what I wanted. You don't do #4 that way. But that doesn't mean entirely separate networks, as they share the same DHCP, DNS, NAT, and so on. Maybe separate ifaces on the host.
> Sucks to be you but irrelevant to the protocol.
The protocol defined SLAAC as the default. If everyone's holding it wrong, maybe the protocol sucks.
> Just like in IPv4 - in the pre-NAT world
We're not in the pre-NAT world of ipv4. That was decades ago.
The problem with IPv6 is really not the changes it made. Support was flaky for a while but that is pretty much over.
The problem is that you have to deploy it. You have to handle the bigger IP space safely, you have to assign the IPs, add DNS records, routing, etc. All this is work and the pressure is low. NAT has mostly taken that away.
Nothing would have saved us from that. There is no way to expand the number of addresses from IPv4 to more than 32 bits apart from a new protocol. There would always be software and infra changes. The server still needs to be changed to a new IPv4+ address, the client needs a new address, there needs to be internet routing for that address.
There were of course changes that were more than just a bigger address space. But I think that if you have to make software changes anyways you could also add some improvements. SLAAC is pretty nice (you can use DHCPv6 if you don't like it). Removing Broadcast is a good idea. Fixed header sizes are an improvement. There is a lot in IPv6 that are really smart ideas. None if these changes are the reason why it hasn't been fully adopted yet.
The problem is they designed v6 with no good compatibility in either direction. I get that there's no way for v6 to support v4, but at least going from v4 to v6 should've been easier. 6to4 etc didn't cut it. Assigning IPs, DNS records, etc is way easier if you don't need to change all of it immediately to get onto v5. You can just get to v5. Changing more things after is easier once nobody is using v4 anymore.
The other less important problem with v6 is that it's inherently less user-friendly. There's unclear guidance about firewall defaults that in practice has led to security issues vs just using NAT. The spec has the kitchen sink in it that aren't broadly supported, like DHCP6 and NAT6. SLAAC meant privacy issues that they had to resolve way later with the privacy extension, even though it's more technically elegant in other ways. And people don't like the long :: hex addrs, partially a consequence of using SLAAC.
> The problem is they designed v6 with no good compatibility in either direction. I get that there's no way for v6 to support v4, but at least going from v4 to v6 should've been easier.
Here are the constraints:
"""
Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:
1. You have to change the version number.
2. You have to add new code to handle the new version.
Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So,
3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol.
Two minutes of thought show that this third requirement has only two solutions:
(3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses between the old and new protocols.
This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it.
It is impossible for IPv4 to connect to IPv6: IPv4 data structures have 32-bit data structures, and this includes the fact that DNS A records are 32-bit only. You cannot have a more-than-32-bit-addresses protocol scheme that can be reach by non-updated IPv4 systems.
If you want to add more bits there is no way around adding/changing code, in which case you are in the exact same situation as we have now with IPv6. You either go with 3A or 3B above.
The issue the GP is making is that rather than devising a whole new protocol altogether, including resolution and assignments, other things like that, adoption likely would have been much faster and wider.
Had the original plan been simply "extend address space" instead of "extend address space and while we are at it revamp and rewrite every part of the whole scheme including assignment, discovery, and everything else we see wrong with ipv4"; we would be in a much better place.
Adding extra address bytes would of course require new changes across the internet, but that change would be easier to swallow compared to having to rip and replace large swaths of processes to make ipv6 work because of all of the other changes that came with ipv6.
Also, the stupid idea of turning addresses to hex as the default, and more specifically the dumb :: shortening methods really made it confusing for everyone and didnt help at all in the efforts.
Actually no software rewrite is needed because the Berkeley Sockets API is agnostic to address format. If your software requires a particular address format, that's a bug. if you pass an IPv6 literal to getaddrinfo, you get a result with an IPv6 address structure and it tells you the IPv6 socket type you need to connect to it.
There is no space to put the additional octets. Supporting this would have needed a rewrite anyways. Nothing won there. They took that as a chance to improve the protocol overall.
Software availability isn't really the problem. For most software there was no change at all ("connect to that host" or "listen to any device" and operating system will handle details), most software which needed adaption had it for a while (picking up a devices explicitly, handling of IPv6 addressees, ...) while maybe not equally good (missing GUI improvements for better handling of IPV6 addresses)
The problems, as I observe, are more in network infrastructure, routing, etc.
Are you just talking about how you write the addresses or are you talking about the actual protocol?
The IPv4 protocol has 4 octets each for source and destination address. Period. If you change that, your packets won't work on any IPv4 routers or software any more.
If you want to write IPv6 addresses as numbers separated by dots no one's stopping you but I don't see how it's better. They switched to hex because the old format was too long.
Exactly, it'd be horrible. They picked the right format for v6. The problem isn't the space size, it's the entropy. V6 addrs are randomly spread, but if you were using the most significant bytes first, you could have something like 42.0.20.80.64.
You have not heard if before, because that is the most naive and stupid take imaginable. It is the “let them eat cake” of networking.
It does not work like that. Put extra octets where exactly? Where would a hardware router put the extra bytes? Where would software with 32 bit buffers?
You would still need to replace all of the software and hardware and have the exact same problem.
You are aware that packets don't magically appear at the server side when sent by a client, right? All packets have to be routed to the destination by several routers. All these have to understand the full address to route the packet. The IPv4 header is strictly defined though. It says 32 bits for the source and 32 bits for the target. If you change anything about that all IP parsers will go haywire. If you put the information somewhere else, every router that doesn't understand that will send it somewhere else.
Every client, server, and router, every device that uses the address needs to understand where it comes from and where it's going. That means all the software needs to understand the protocol. So instead of having incompatible implementations live within the same protocol and make a lot of chaos it's better to have a new separate protocol that can be implemented gradually. Now the distinction is between having or not having IPv6 connectivity and my package on IPv4 goes no where because it hit a router that doesn't understand the extension.
They added those new addresses that can store more information.. but this requires a rewrite of old software to make it work.
If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work.