> I don't really see the point of it. I mean, where is even any significant difference to IPv6? IPv4+ solves the same problems that IPv6 does, is much simpler

> I don't really see the point of it. I mean, where is even any significant difference to IPv6? IPv4+ solves the same problems that IPv6 does, is much simpler than IPv6, is cheaper than IPv6, and could have been deployed in less time than IPv6. If we're going to learn from IPv6, then that means studying things like IPv4+. Note I'm not suggesting we stop IPv6 efforts: I used to say that, but that's only because I think we'll have a 50% solution in another ten years, and IPv4+ could take up to ten years if we had consensus. > while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by. If you run a service on IPv4+, your router needs to support IPv4+, and your users need to support IPv4+. That's it. This is very similar to the challenges that upgrading HTTP and HTTPS do had. Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT. > addresses based on IPv4 addresses you already have, that's called 6to4 6to4 is a lot more complicated than IPv4+. It was harder to deploy, and building on IPv6 instead of IPv4 was probably a mistake. If we don't consider the complexity of the implementation, 6to4 still took much longer to be suggested than IPv4+ (or similar) was. > What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet. NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT.