6 ms·

Does GPC support ipv6 only subnets? Some cursory pokes around I can not tell. (I really only work with AWS). Azure? Any other notable services providers have do

by rsmets 5y ago

Does GPC support ipv6 only subnets? Some cursory pokes around I can not tell. (I really only work with AWS). Azure? Any other notable services providers have done this yet? I can not tell if this is long overdue or actually something to take note of.

X-Istence 5y ago
GCP has support for IPv6 dual stack in only 4 or so regions: https://cloud.google.com/vpc/docs/vpc#ipv6-regions https://cloud.google.com/vpc/docs/vpc#ipv6-regions not only that but enabling IPv6 is not as simple as it is in AWS and requires a lot of manual fiddling with the subnets. Once enabled it does give you a prefix that is automatically assigned to each VM in the subnet which you can use for containers and the like. Azure's IPv6 support is terrible, and does not support IPv6 only networks: https://docs.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview https://docs.microsoft.com/en-us/azure/virtual-network/ip-se... including limitations on the prefix size you can get for your VM's: https://docs.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-address-prefix https://docs.microsoft.com/en-us/azure/virtual-network/ip-se... no /56 like you can get in AWS that you can then slice /64's out of for subnets and no prefix delegation for running container workloads on their own GUA. Where Azure was ahead was that its load balancers supported targeting IPv6 addresses and thus didn't require IPv4 for forwarding traffic. AWS fixed that today. AWS should be lauded, and while it is long overdue (IPv6 core, with IPv4 only on the edge makes so much sense) AWS is the first hyperscaler to do so.
deathanatos 5y ago
> Azure? I tried a dual-stack vnet in Azure earlier this year, and eventually had to rip IPv6 out of it: flexible Postgres servers couldn't be instantiated into an IPv4-only subnet (yes, IPv4) if the vnet had IPv6 at all. (Worse, attempting to do so caused the API call to create the flexible PG instance to just time out, and it for some odd reason has a two hour timeout that suggests it's a transient internal error & you should retry. So, four hours.) I didn't really expect flexible PG to support IPv6, but that it seemed to poison the support for IPv6 for the rest of the vnet was really, really disappointing.
- jiggawatts 5y ago
  It's not the only such service. NAT Gateways, VPN, Virtual WAN, and a whole host of others break if you enable IPv6 anywhere. The reason things like Postgres break is because internally they use what is essentially a VPN Gateway to communicate with your vNet.
jiggawatts 5y ago
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. Shame, shame.
- deleted 5y ago
  [deleted]
- FridgeSeal 5y ago
  This is incredible, as if I needed more reasons to dislike Azure hahaha
- nayuki 5y ago
  > Azure engineers restricted IPv6 public address prefixes to blocks of just 16 addresses. That's a /124, right?
- londons_explore 5y ago
  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)

by rsmets 5y ago

X-Istence 5y ago

GCP has support for IPv6 dual stack in only 4 or so regions: https://cloud.google.com/vpc/docs/vpc#ipv6-regions https://cloud.google.com/vpc/docs/vpc#ipv6-regions not only that but enabling IPv6 is not as simple as it is in AWS and requires a lot of manual fiddling with the subnets. Once enabled it does give you a prefix that is automatically assigned to each VM in the subnet which you can use for containers and the like. Azure's IPv6 support is terrible, and does not support IPv6 only networks: https://docs.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview https://docs.microsoft.com/en-us/azure/virtual-network/ip-se... including limitations on the prefix size you can get for your VM's: https://docs.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-address-prefix https://docs.microsoft.com/en-us/azure/virtual-network/ip-se... no /56 like you can get in AWS that you can then slice /64's out of for subnets and no prefix delegation for running container workloads on their own GUA. Where Azure was ahead was that its load balancers supported targeting IPv6 addresses and thus didn't require IPv4 for forwarding traffic. AWS fixed that today. AWS should be lauded, and while it is long overdue (IPv6 core, with IPv4 only on the edge makes so much sense) AWS is the first hyperscaler to do so.

deathanatos 5y ago

> Azure? I tried a dual-stack vnet in Azure earlier this year, and eventually had to rip IPv6 out of it: flexible Postgres servers couldn't be instantiated into an IPv4-only subnet (yes, IPv4) if the vnet had IPv6 at all. (Worse, attempting to do so caused the API call to create the flexible PG instance to just time out, and it for some odd reason has a two hour timeout that suggests it's a transient internal error & you should retry. So, four hours.) I didn't really expect flexible PG to support IPv6, but that it seemed to poison the support for IPv6 for the rest of the vnet was really, really disappointing.

jiggawatts 5y ago
It's not the only such service. NAT Gateways, VPN, Virtual WAN, and a whole host of others break if you enable IPv6 anywhere. The reason things like Postgres break is because internally they use what is essentially a VPN Gateway to communicate with your vNet.

jiggawatts 5y ago

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. Shame, shame.

deleted 5y ago
[deleted]
FridgeSeal 5y ago
This is incredible, as if I needed more reasons to dislike Azure hahaha
nayuki 5y ago
> Azure engineers restricted IPv6 public address prefixes to blocks of just 16 addresses. That's a /124, right?
londons_explore 5y ago
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)