This is a common misconception. Apart from the kind of NATs we have now, there is no way that IPv4 could have been expanded. A lot of routing hardware was ASIC based (I'm sure plenty still is), so packet headers were fixed and couldn't be changed without changing all the routers. Just like they had to be changed with IPv6. Any server would need to understand the old system and the new system simultaneously to be able to be backwards compatible - just like with dual stack now. Big parts of the internet wouldn't be reachable until the host, the server, and every router and middle box along the path had been upgraded. Just like with IPv6.

So you'd have all the same problems, just in a slightly different way...

> his is a common misconception. Apart from the kind of NATs we have now, there is no way that IPv4 could have been expanded.

The misconception is that IPv4 could have been expanded in a compatible way. That's not GP's point though as I read it. They could have made an incompatible IPv5 which was exactly like IPv4, except with additional address bits.

Then the operational side would be similar, and you wouldn't have to learn everything over again.

Instead they changed just about everything.

If you are going to have to break backward compatibility anyway, of course you are going to use that as a chance to change other things, fix some things that weren't broken but weren't great either, try for some nice to haves while you are at it.

Especially if you were predicting a migration across any compatibility break would take decades or more (or potentially forever live side-by-side), there's very pragmatic reason "rip the bandaid off" and to change everything all at once rather than make a series of far more painful "smaller" migrations that would each individually take nearly as long.

>hey could have made an incompatible IPv5 which was exactly like IPv4, except with additional address bits.

That exists, it's called enhanced IP or something. I'm having trouble finding it now since it's been a few years, but I've had a customer using it. Of course nothing besides the endpoints understood it, so it had to be wrapped in UDP. Horrible.

IPv6 isn't that different than IPv4. Neighbor Discovery is just ARP. Not having in-path fragmentation and loads of other IPv4 legacy crap is a good thing.

The only major change is that instead of the smallest routeable unit being a single address the smallest unit is now a whole 64 bit subnet so hosts have a bunch of bits they can use for various purposes. Network administrators don't have to worry about that for the most part, the hosts figure that out on their own.

I guess there might be a security implication if someone has built their security system around knowing everything on the network via DHCP. But that was always a mistake. If you want real security you need to use 802.1x or similar. Being told you can't use DHCP to secure your network anymore is probably shock to some admins, but hopefully they take the opportunity to reconsider their system from the ground up.

There are a lot of changes needed, especially in (old) corporate environments.

I do use ipv6 at home, and at some of our customers, but some of them would have to essentially redesign their entire networking/vpn/security plan (and yes, existing ones are not good, split horizon DNS is almost always present, DHCP is not only used for security, but also for provisioning, there are products that scan subnets and provide reports on devices required for various compliances ...). And that is a hard sell, for what they see as next to no benefits.

I wonder if it's perhaps time to write off IPv6, for this reason, and come up with a different standard that is more like that.

Because we're decades in here, and it's still not dominant, for the reasons given.

Based on this

https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...

we're probably 15-20 years away from "enough people have IPv6 that you can start dropping IPv4". There's zero chance you could make an IPv5 and have any adoption at all in that time.

You would start from scratch to develop chips that would support your new formats.

IPv4+TCP and IPv6+TCP is literally baked into hard silicon on many, many devices, even if not for all phases of the protocol. We're talking redesigning switching chips, redesigning TCAM (content-addressable memories used to cache routes), etc. on top of designing yet another protocol.

At least old IPv9 had the benefit of some level of support in sw/hw when it was proposed (as it reused CLNS from OSI for internetwork protocol)

What are the security concerns with V6 that don't exist with V4?

Not the op, but there are basic things like having to enable privacy addresses otherwise you expose your MAC in your IPv6 address.

This can be fixed not only with privacy addresses but also with DHCPv6 instead of SLAAC. The use of the MAC in this way was a bad bit of design but it's easily remedied. There is nothing in IPv6 that mandates that addresses be assigned this way. Like IPv4 they can be anything.

I personally like stuff like :feed:cafe:babe:beef or :dead:d00d :).

I agree they can be fixed, although I disagree that DHCPv6 is the solution given Android doesn't support DHCPv6. In practice most vendors I know of just use privacy addresses by default now for IPv6, at least outside servers, so it's mostly a non-issue but the fact remains it's something not applicable to IPv4. And for quite a while it was an issue, it's just that IPv6 hasn't been popular enough for consumers to care instead of just security people.

> There is nothing in IPv6 that mandates that addresses be assigned this way. Like IPv4 they can be anything.

Yes but that's nitpicking at the core RFCs vs the many other supporting RFCs. There's no IPv4 RFC for using a MAC in the IP address, whereas there is with IPv6 (rfc2373 from a quick look, maybe others).

Sure, you can fix it, but you have to fix it; with v4 it just wasn't a problem.

It's not really a problem in v6 either. Most OSs ship with privacy extensions enabled.

Is exposing a MAC a considerable issue? Also I feel like you can randomize your MAC easily enough.

It allows for tracking users since the second half of your address is always constant. It's a fixed problem though since basically all consumer devices these days use privacy extension addresses, which don't expose your MAC address and periodically change to a new random IP address

Then operating systems shall start shipping with that option enabled by default.

They already do, both the mac and windows computers on my desk have it enabled.

Yes, and it's additional overhead for the people designing the operating system to worry about. More complexity, more attack surface.

I'm guessing OP is under the impression that IPsec is mandatory in v6. There was an intent in the 1990s to do exactly that, but it was recanted.

https://hpc.mil/images/hpcdocs/ipv6/nsa-router-security-conf... [PDF warning]

Here's a guide on secure router configs and an overview of some threats that are new in ipv6.

Also, this ignores the fact that IP address scanning is tremendously harder on IPv6 than it is on IPv4. That's a significant security improvement right off the bat.

All of the dozens of Internet bots that try to portscan my router every day would cease to be an issue if I could turn off my IPv4 address.