If you think IPv6 is too complicated, you are either overestimating IPv6’s complexity or underestimating IPv4’s complexity. IPv6 is undeniably simpler. It has a cleaner header format that is simpler to parse, it has no need for on-path routers to perform fragmentation, it combines host/router discovery and various diagnostic control packets down into a single protocol called ICMPv6, it has stateless address autoconfiguration and correct link-local address behaviours amongst others. It fixes decades of mistakes that have accumulated in IPv4.
Perhaps to someone who's never been exposed to IPv4.
But for those who know IPv4 from before, it means almost a complete rewrite of all the knowledge. Just about every detail of setting up an IPv6 network is different from an IPv4 network, with just the superficial bits staying similar.
It also has bits that are undeniably more complex than IPv4, like dynamic address allocation. You got SLAAC, RA, stateful and stateless DHCPv6, with the latter being required in certain cases. And with that you now got two different ways to provide DNS servers to clients, and which one takes precedence is undeniably non-trivial[1] and even implementation dependent!
Any solution that requires updating clients, servers, and networking equipment to support the protocol and/or adjust the network address scheme of the environment will require the exact same steps doing an IPV4 to IPV6 migration would require.
Not so. IPv4->6 removes all existing v4 address blocks and redoes the addressing scheme. Those changes weren't necessary for expanding the address space. This implies that day 1 of using ipv6, all your addresses are different (and way longer), all your routes change, DNS DHCP etc all need to be swapped out, and bans/reputation are all reset with no clear replacement. And there were a bunch of smaller changes / new features.
Whatever you do to get more addresses, it will look similar in the end, but the steps could've been very different.
How would a computer with an expanded address scheme communicate with another device with an unexpanded IPV4 address? How would that client get its response back?
How would a router know what to do with it without updating its software?
At the end of the day, you are talking about using a different than IPV4 address scheme and using a different protocol than IPV4. Everything in the stack will need to be updated. Every hop on the route, every single piece of software that will interact with the network address. Backwards compatibility still requires everything but the older device to be updated.
Yes, everything has to be updated eventually, but going forward doesn't have to be this hard. A network and its hosts could start supporting ipv6 without changing anything else. Same addr and routes as before, same NAT, and no DNS6/DHCP6/etc, so very low effort and risk to turn it on. If a peer only supports v4, talk v4 to it for now.
Then once there's sufficient v6 adoption, you can disable v4 entirely and start using /40, /48, etc..
But same addr is the problem we are trying to solve in the first place. Using your IP-new proposal (let's call it IPv5): If every IPv5 addr is just a padded version of the same IPv4 addr, then once IPv4 addresses are exhausted the IPv4-mapped-into-IPv5 addresses are also exhausted.
At that point you need to start handing out IPv5 addresses to hosts without an IPv4 address. And then, how does a IPv5-only host talk to a IPv4-only legacy host? That's the fundamental issue!
The same addr thing only buys you time until the address exhaustion becomes real.
You still make the same big changes, but the difference is you don't have to do them all at the same time. You also skip the complicated add-ons of ipv6 and don't reassign everything.
Ipv5 as you call it: Phase 1 is getting routers/hosts to understand v5 headers, while users enable v5 and change nothing else. Phase 2 is the transition where people keep using padded addrs while things* are updated in-place to just support longer ones, which doesn't affect users**. Once that's done, we get to use the full space, which some users may ignore and some may use. For better and worse, the existing /32 blocks would still be around initially. Maybe this would appeal to previous ipv4 holders better; they still own the same % of the pie. Maybe 8.8.8.8 would stay forever.
What makes me kinda sure would've worked? Right now, the world has mostly already completed the equivalent of phases 1 and 2 for ipv6. There might even be a way to reuse the ipv6 protocol as-is for ipv5.
* DNS, NAT, DHCP, ARP, routers, VPSes, OSes...
** "User" includes corp network admins, cloud/datacenter operators, ISPs, and simple home customers.
But you can do that with IPV6? I have both an IPV4 and IPV6 address on this very device.
My confusion in the claims that we could do it differently is how the protocol could be updated without actually doing the work of updating everything on the network and adding the new address scheme.
That's my proposal, ipv6 with extra steps. As in, incremental steps instead of one impossibly big change. tl;dr keep the pre-existing v4 /32 blocks day 1, and the rest follows.
Edit: I said "my" proposal, but pretty sure the same idea has been brought up many times.
Getting rid of IPv4 address allocation is one of the huge advantages of IPv6. IPv4 is chopped up into little pieces and the routing table is mess from it. Starting from scratch, IPv6 can make that better.
IPv6 also realized that most people don't need their own address space. It is valuable in IPv4 to own an allocation, but IPv6 is so huge it doesn't matter.
For setup, IPv6 does it automatically for customers. Peering requires entering IPv6 addresses, but that is a one time thing.
> Getting rid of IPv4 address allocation is one of the huge advantages of IPv6. IPv4 is chopped up into little pieces and the routing table is mess from it.
Basically IPv6 only solves problems if you're paid full time to do network administration.
If you just run a small network among other things, it creates problems. Because you can't hold the new structure in your head if it's not your main job.
> Starting from scratch, IPv6 can make that better.
Yeah right. Want that "things you should never do" Joel link?
He was talking about Netscape, but I think IPv6 is a much better example.
The nice thing about IP v6 is there is effectively "no structure" to hold in your head. You never need to think about or find out what the netmask is, it's always /64. You never need to calculate the next subnet boundary, increment the digit before ::. You never need to do all sorts of the things associated with IPv4 structure, private addresses and conflicts, NATs and double NATs, DHCP server just to have clients automatically work...
The biggest downside for IPv6 in small networks is, ironically, something which was added later and not part of the initial (nor actually required, but devices opt to do it anyways) and that's "randomized auto rotating addresses" for security. Without them addresses look something like 1234:abcd::${mac} or 1234:abcd::12 but with them they look like 1234:abcd::4729:ab65:f902:7ee0 and a device might have 4 active if it's been running the whole day. I think this one extension is something like 80+% of people's reaction to IPv6 and it didn't even call for it originally.
These are all defaults, by the way. Subnets don't have to be /64 - that ended up being the default by historical accident; though it's nice that it forces every ISP to give you at least a /64 which you can subnet further if you want to, though without SLAAC.
Privacy addresses should be used for outgoing connections. Don't treat one as a static address. If you need to write down an address, give that machine an easily remembered static one.
I feel like residential ipv6 would be at least a little further along if routers simply always enabled NAT by default for it, like what cell providers do. Solves all these questions and problems for inexperienced users. Instead, you gotta ask, is the firewall enabled and default-deny, are ULAs enabled...
The second thing is the problem with not having NAT. On a home or corp network, I like NAT. I'm not trying to host 20 servers there. Sure ipv6 can use it too, but it's never default and often not supported on the router.
So yeah, 192.168.1.55 is my Mac's local ip, it's easy to remember.
Inside the home you can usually get away just using the internal link local addresses. E.g. my main PC is fe80::10, my wife's pc is fe80::11, my router is fe80::. You can even use that when you get "fancy" e.g. my NAS is fe80::12 internally or ${public_prefix}::12 "externally" (that one actually works on either side).
This address will also run afoul with the "privacy first" randomizations on most devices by default. This addition is truly the scourge of letting IPv6 seem dead simple to use.
Don't forget that IPv4's link local addresses (169.254.0.0/16) are also randomized for the same reason: making link-local addresses use sequential numbers by default requires a centralized node to coordinate them, which is counteractive because link-local address are designed to not require one.
IPv6's answer to IPv4 private addresses (e.g. 192.168.0.0/16) is ULA (fd00::/16). Newer routers are beginning to assign local hosts with ULA addresses, thus if you want to have a stable address to a local device, you can simply connect to it by ULA.
Yeah, the route fragmentation a disadvantage of what I've had in mind. My focus is just on getting things to speak v6 to fix the scarcity problem first. Maybe at some point the owners could've swapped addresses back to defrag things.
How is that better than IPv6? Remember that there is no way to squeeze more address bits into IPv4 header, that need to come up with a new protocol. In fact, need to come up with a whole suite of new protocols. You could just make the addresses bigger but still need to deploy.
IPv6 changed some things, most of them for the better, and it already works. The only problem is migrating and the problem is people who don't want to switch.
One example of how IPv6 is better than IPv4 with more address bits, is that 128-bit address is big enough to put the whole IPv4 address in. NAT64 put the IPv4 address in the 64-bit host section. MAP-T puts the whole NAT state in address, getting rid of expensive CGNAT.
I don't understand why all my devices randomly assign themselves non-functional IPv6 addresses with no involvement from any router. Often it's even multiple non-functional IPv6 addresses.
IPv6 assigns link-local addresses automatically. They are for talking to other computers on same the network. It works when you don't have router. It won't interfere with anything else.
IPv6 supports multiple addresses on each machine for different scopes: global, internal, local. IPv6 uses address hierarchy to figure out which one to use to reach destination.
