[mike_d]

The solution to IPv4 exhaustion. It is basically unused multicast and "reserved for future use."

Only thing standing in our way is the IPv6 proponents who know address space exhaustion is the only thing that will drive adoption of an otherwise shitty idea.

[Avamander]

Absolutely not the solution, a temporary relief at best. Better to bury this idea.

[mike_d]

This is the force exhaustion to drive adoption approach.

If your family is starving do you look over at a plate of sandwiches and say "we better not eat those, it is just a temporary relief" or do you use the available resources to solve the problem.

[account-5]

Can you elaborate on why ipv6 is so shitty?

[system2]

I'd assume legacy support isn't there for IPv6. At least for our environments, it wasn't feasible.

[kaliszad]

Could you please elaborate, what were some of the major blockers for you?

In some cases, you can "just" add a reverse proxy in front of the legacy services or use some kind of NAT64/ DNS64 setup on the server side. Internal systems can expect IPv4 only for addresses for some kind of accounting, configuration etc. But internal systems that you cannot evolve to support current requirements are a burden anyway. There might be other debt that keeps getting postponed because of these things.

I have had a client tell me that some services cannot get a different IPv4 because they don't know about all the things that only know it by its IP instead of its DNS name. I am pretty sure that as a man made software system their system could definitely switch to a different address with some preparation but I am not going to push for it too hard. (It would allow improving the segmentation of their network in turn making it easier to firewall things in a simpler manner. Also, with L3 switches now commonplace it is no longer a question of performance.)