In Azure, enabling IPv6 in any way is a terrible mistake that will break your IPv4 network.
There is zero benefit to enabling IPv6 in Azure, because they carefully prevent any use of the beneficial features of IPv6 that make it worthwhile over IPv4.
A key purpose of IPv6 is no longer needing NAT to the point that IPv6 implementation typically do not support NAT at all -- so Azure engineers developed their own custom IPv6 NAT to force NAT on all of their IPv6 users.
Another key purpose of IPv6 is the enormous address space, which means you no longer need to carefully "carve up" and manually allocate addresses in a stateful way -- Azure engineers restricted IPv6 public address prefixes to blocks of just 16 addresses. Not /16 or anything like that. No. Sixteen.
To assist migration, IPv6 is designed to be dual stack and coexist side-by-side with IPv4 with no (or minimal) impact. Azure engineers made sure that if you turn it on, wildly unrelated IPv4 features will break. In other subnets. Even other virtual networks! Critical features are masked out, making this a non-starter for practically everybody.
To enable layered systems to be migrated, IPv6 is sufficiently "compatible" with IPv4 to allow the use of relatively simple protocol-translating middle boxes. So you can have IPv6 on the outside and IPv4 on the inside, or vice-versa. Not on Azure! It's only IPv4-to-IPv4 or IPv6-to-IPv6. You can't have both, and you can't translate. PICK ONE, NOW.
It's shameful.
Seriously, if any Microsoft network engineers stumble upon this post, you should feel bad. It's 2021 when I'm writing this, mere days from 2022, and you've utterly failed to even begin to support the transition to IPv6 in the public cloud.
All these things sound to me like their internal network only supports IPV4, and they simply maintain some mapping of which IPV6 address maps to which IPV4 address and they convert packets where needed so the customer sees IPv6 yet all packets flow over the wire as IPv4 with no additional headers (so that MTU doesn't need to be decreased)
To me it feels like the entire thing was engineered with only IPv4 in mind from day one, and a decade into it some customer demanded IPv6 support. So of course, some middle-manager at Microsoft gets assigned the "task" of enabling IPv6, and he dutifully went over to the engineers and asked them to turn it on. Horrified, they tried to explain that it's a ground up re-engineering of their entire network stack, at which point I don't need to have been in the room to play out the conversation that unfolded in that meeting room line by line:
"Just tell me what the minimum set of tasks is to enable IPv6!"
"You don't understand, it's not like turning on a tap! We have to redo all of the infrastructure around networking!"
"Do we need all that? Just tunnel the packets or something!"
"That's not the same thing, that's only supporting IPv6 in a technical sense, it doesn't really mean the same thing as doing it properly, and it won't work long term. It'll have to be ripped out and replaced, but while maintaining backwards compatibility with a jury-rigged IPv6 implementation. It'll be a nightmare!"
"Don't worry about that now, I just need to say that we've enabled IPv6 so I can satisfy this requirement."
"It'll just tick the check box! Nobody will be able to actually use it! Our customers will be confused and support will have to deal with the fallout!"
"Let me deal with that."
Etc, etc...
Translation: I just want my KPIs so that I can get my bonus. I'm quitting before the fallout hits.
There is zero benefit to enabling IPv6 in Azure, because they carefully prevent any use of the beneficial features of IPv6 that make it worthwhile over IPv4.
A key purpose of IPv6 is no longer needing NAT to the point that IPv6 implementation typically do not support NAT at all -- so Azure engineers developed their own custom IPv6 NAT to force NAT on all of their IPv6 users.
Another key purpose of IPv6 is the enormous address space, which means you no longer need to carefully "carve up" and manually allocate addresses in a stateful way -- Azure engineers restricted IPv6 public address prefixes to blocks of just 16 addresses. Not /16 or anything like that. No. Sixteen.
To assist migration, IPv6 is designed to be dual stack and coexist side-by-side with IPv4 with no (or minimal) impact. Azure engineers made sure that if you turn it on, wildly unrelated IPv4 features will break. In other subnets. Even other virtual networks! Critical features are masked out, making this a non-starter for practically everybody.
To enable layered systems to be migrated, IPv6 is sufficiently "compatible" with IPv4 to allow the use of relatively simple protocol-translating middle boxes. So you can have IPv6 on the outside and IPv4 on the inside, or vice-versa. Not on Azure! It's only IPv4-to-IPv4 or IPv6-to-IPv6. You can't have both, and you can't translate. PICK ONE, NOW.
It's shameful.
Seriously, if any Microsoft network engineers stumble upon this post, you should feel bad. It's 2021 when I'm writing this, mere days from 2022, and you've utterly failed to even begin to support the transition to IPv6 in the public cloud.
Shame, shame.