6 ms·

Google's own GCE still doesn't have IPv6 support on the instance level: https://googlecloudplatform.uservoice.com/forums/302595-compute-engine/suggestions/8518

by QUFB 8y ago

Google's own GCE still doesn't have IPv6 support on the instance level: https://googlecloudplatform.uservoice.com/forums/302595-compute-engine/suggestions/8518246-support-ipv6 https://googlecloudplatform.uservoice.com/forums/302595-comp...

pilif 8y ago
I'm a huge fan of IPv6 as it's a huge contributor to ensure the continued openness of the internet. Also, I'm in the privileged position of having a native dual-stack provided by my ISP, so I have native IPv4 and IPv6 both at home and in the office. And yet, even in this position, I think having IPv6 native inside of a production network isn't absolutely necessary (our production env runs in the RFC1918 space too even though v6 would be available at both ends): Access to the private production network should all happen over an encrypted and authenticated VPN and all access form the production network to the public network (if needed at all) should go through a filtering proxy server. Which means that the addressing used in your internal network becomes completely irrelevant and can easily be IPv4. This only becomes an issue once you need more hosts than the /8 offered by the 10/8 RFC1918 network, but the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off. If you want instance level IPv6 in order to access an instance directly or in order to access a resource directly, you're probably doing something wrong. Then again, as services become v6 only (which will still be a few years off) and you need to access them from your production network, then your frontend proxy will of course need access to the v6 network. At that point, yes, instance level v6 becomes necessary too.
- lisper 8y ago
  > the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off And the days when you need 16M nodes all of which need to talk to each other directly are probably even further off. (In fact, I would go even further and say that if you find yourself ever facing that situation you've done something badly wrong in your architectural design.)
- agwa 8y ago
  Using IPv4 internally becomes an issue as soon as you need to interconnect with someone else's internal network which uses overlapping IPv4 address space. The most famous example is probably Facebook's acquisition of Instagram, which required an incredible amount of iptables hackery to work around overlapping IPv4 address space: https://instagram-engineering.com/migrating-from-aws-to-fb-86b16f6766e2 https://instagram-engineering.com/migrating-from-aws-to-fb-8... In contrast, even if you use "private" IPv6 addresses (ULA), the address space is large enough that everyone can have their own prefix. Or better, just use public IPv6 addresses and firewall them.
  - endymi0n 8y ago
    Then again, IPv6 hasn't really been built with NAT in mind, precisely because "there are so many addresses out there you won't need it". So if you decide for an IPv6 deployment for your servers, you're essentially between a rock (you can't easily transfer an IPv6 address space from one cloud provider to the next) and a hard place (use ULA addresses internally and having to NAT to the outside anyway, but with less software and hardware support). As for me personally, I'm totally fine with IPv4 behind the load balancer: it gives me a much easier time with basically everything and I can still support both v4 and v6 for all clients connecting to my site as well.
    - agwa 8y ago
      Yes, renumbering is a PITA. NAT66 does exist and over time more software and hardware will support it. But you don't need NAT if you are using ULA; instead you would configure each system with both its ULA address and the global address from your provider (SLAAC can advertise multiple prefixes). Traffic to other internal systems would use the ULA addresses, while traffic to the Internet would use the global address.
    - clhodapp 8y ago
      Why would it be important to be able to switch cloud providers and keep the same addresses on your internal network? Changing providers while keeping addresses seems abstractly like a nice capability to have but it also seems that it might or might not end up being just as much logistical trouble as re-addressing everything when it came down to the implementation...
- zamadatix 8y ago
  Having two IP addresses is all that is necessary for most private networks, it's just a dumb and over complicated way of traversing nodes. Same with 2^24 IPs. "Access to the private production network should all happen over an encrypted and authenticated VPN" IPsec, likely the same thing that'd be encrypting your VPN, can just be used directly between hosts without complication if you have all public addresses. "and all access form the production network to the public network (if needed at all) should go through a filtering proxy server." Why does it have to be a proxy? Why not just a firewall sitting in the route path? Again, the way you're use to working around a limited address space is leading to complicated solutions to problems easily solved by having more addresses. In computing very little is "necessary" but it doesn't mean it makes much sense for it to be that way the same as programming your cloud application with NAND logic doesn't make sense.
- ec109685 8y ago
  Even if you need more IPs than the 10/8 network provides, there are other prefixes you can use, as long as your hosts do not need to ever directly connect to them, so you effectively have billions of private ips at your service.
  - zamadatix 8y ago
    Pro-tip: never do this outside of ranges explicitly reserved for private use. Multiple times a year I have to deal with some hospital somewhere saying "well <xyz> didn't use to come from that range!" and then dealing with the fact 10,000 medical devices can't have their IPs changed. Recently a similar thing happened with 1.1.1.1 and 1.0.0.1 when Cloudflare went live with them, nobody ever thought those IPs would be handed out.
- Oowee1Ee 8y ago
  > And yet, even in this position, I think having IPv6 native inside of a production network isn't absolutely necessary Not necessary, but it could be quite useful. The 64bit suffix of ULA addresses lets you group your containers into separate blocks with static prefixes. E.g. you could always have the :0000 - :FFFF block be your reverse proxies, the next block the storage shards and so on.
- api 8y ago
  It's not necessary for most applications, but it's extremely helpful for some. It can also be used to realize deployment scenarios where you cluster across clouds very easily provided you ensure connections are secure between nodes/containers/services.
- tambre 8y ago
  While GCP has IPv6 support for their global load balancers, it's very limited and not sufficient for many uses. For example, I've been working on contributing IPv6 support to GitLab.com [0], which is hosted on GCP. Turns out it's impossible for the main site right now, because none of the global load balancer types allow port 22, which is used for Git traffic. I've no idea why there are even such restrictions, but there's of course a "feature" request for allowing port 22 [1]. I was able to repurpose the work for other parts of GitLab.com, but I've yet to get even those to work, due to the load balancers gobbling up HTTPS/SSL requests [2]. [0] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merge_requests/427 https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg... [1] https://issuetracker.google.com/issues/77944636 https://issuetracker.google.com/issues/77944636 [2] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merge_requests/427#note_102821029 https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg...
  - dsl 8y ago
    GLB can't even support TCP and UDP listeners on the same IP, which means you can't put a DNS server behind it.
- X-Istence 8y ago
  The amount of work that was done at the last two ISP's I worked due to being out of RFC1918 space and thus needing to do overlay networks, and all kinds of fun translating and gateways and overall making a HUGE mess of everything... Because while there is a 10/8, once you start subnetting that and advertising it from multiple sites and start running labs that look and act like production that /8 goes quick. Give me IPv6 any day.
- Corrado 8y ago
  > This only becomes an issue once you need more hosts than the /8 offered by the 10/8 RFC1918 network, but the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off. It's not that you require more than a /8 can provide, it's more a function of convenience. I have 10 customers, each one of those has 4 environments (Dev, QA, Stage, Prod) and each of these environments need to live in 3 regions, and each region has 3 AZs, and each AZ has 6 subnets. Splitting that up with a 10.0.0.0/8 gets complicated. I would much rather say 2006:abcd:0001:::: is customer A, ::0002::: is customer B, etc. IPv6 gives me plenty of room to maneuver and eliminates the need to worry about IP exhaustion.
- all_blue_chucks 8y ago
  NAT is the devil. RFC1918 is the devil. Want to filter inbound traffic? It's called a firewall.
ggm 8y ago
But it does at the redirector/Traefik level. Worse, Kubernetes as a model doesn't use IPv6 internally when it should. No reason not to use e.g. ULAs.

by QUFB 8y ago

pilif 8y ago

I'm a huge fan of IPv6 as it's a huge contributor to ensure the continued openness of the internet. Also, I'm in the privileged position of having a native dual-stack provided by my ISP, so I have native IPv4 and IPv6 both at home and in the office. And yet, even in this position, I think having IPv6 native inside of a production network isn't absolutely necessary (our production env runs in the RFC1918 space too even though v6 would be available at both ends): Access to the private production network should all happen over an encrypted and authenticated VPN and all access form the production network to the public network (if needed at all) should go through a filtering proxy server. Which means that the addressing used in your internal network becomes completely irrelevant and can easily be IPv4. This only becomes an issue once you need more hosts than the /8 offered by the 10/8 RFC1918 network, but the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off. If you want instance level IPv6 in order to access an instance directly or in order to access a resource directly, you're probably doing something wrong. Then again, as services become v6 only (which will still be a few years off) and you need to access them from your production network, then your frontend proxy will of course need access to the v6 network. At that point, yes, instance level v6 becomes necessary too.

lisper 8y ago
> the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off And the days when you need 16M nodes all of which need to talk to each other directly are probably even further off. (In fact, I would go even further and say that if you find yourself ever facing that situation you've done something badly wrong in your architectural design.)
agwa 8y ago
Using IPv4 internally becomes an issue as soon as you need to interconnect with someone else's internal network which uses overlapping IPv4 address space. The most famous example is probably Facebook's acquisition of Instagram, which required an incredible amount of iptables hackery to work around overlapping IPv4 address space: https://instagram-engineering.com/migrating-from-aws-to-fb-86b16f6766e2 https://instagram-engineering.com/migrating-from-aws-to-fb-8... In contrast, even if you use "private" IPv6 addresses (ULA), the address space is large enough that everyone can have their own prefix. Or better, just use public IPv6 addresses and firewall them.
- endymi0n 8y ago
  Then again, IPv6 hasn't really been built with NAT in mind, precisely because "there are so many addresses out there you won't need it". So if you decide for an IPv6 deployment for your servers, you're essentially between a rock (you can't easily transfer an IPv6 address space from one cloud provider to the next) and a hard place (use ULA addresses internally and having to NAT to the outside anyway, but with less software and hardware support). As for me personally, I'm totally fine with IPv4 behind the load balancer: it gives me a much easier time with basically everything and I can still support both v4 and v6 for all clients connecting to my site as well.
  - agwa 8y ago
    Yes, renumbering is a PITA. NAT66 does exist and over time more software and hardware will support it. But you don't need NAT if you are using ULA; instead you would configure each system with both its ULA address and the global address from your provider (SLAAC can advertise multiple prefixes). Traffic to other internal systems would use the ULA addresses, while traffic to the Internet would use the global address.
  - clhodapp 8y ago
    Why would it be important to be able to switch cloud providers and keep the same addresses on your internal network? Changing providers while keeping addresses seems abstractly like a nice capability to have but it also seems that it might or might not end up being just as much logistical trouble as re-addressing everything when it came down to the implementation...
zamadatix 8y ago
Having two IP addresses is all that is necessary for most private networks, it's just a dumb and over complicated way of traversing nodes. Same with 2^24 IPs. "Access to the private production network should all happen over an encrypted and authenticated VPN" IPsec, likely the same thing that'd be encrypting your VPN, can just be used directly between hosts without complication if you have all public addresses. "and all access form the production network to the public network (if needed at all) should go through a filtering proxy server." Why does it have to be a proxy? Why not just a firewall sitting in the route path? Again, the way you're use to working around a limited address space is leading to complicated solutions to problems easily solved by having more addresses. In computing very little is "necessary" but it doesn't mean it makes much sense for it to be that way the same as programming your cloud application with NAND logic doesn't make sense.
ec109685 8y ago
Even if you need more IPs than the 10/8 network provides, there are other prefixes you can use, as long as your hosts do not need to ever directly connect to them, so you effectively have billions of private ips at your service.
- zamadatix 8y ago
  Pro-tip: never do this outside of ranges explicitly reserved for private use. Multiple times a year I have to deal with some hospital somewhere saying "well <xyz> didn't use to come from that range!" and then dealing with the fact 10,000 medical devices can't have their IPs changed. Recently a similar thing happened with 1.1.1.1 and 1.0.0.1 when Cloudflare went live with them, nobody ever thought those IPs would be handed out.
Oowee1Ee 8y ago
> And yet, even in this position, I think having IPv6 native inside of a production network isn't absolutely necessary Not necessary, but it could be quite useful. The 64bit suffix of ULA addresses lets you group your containers into separate blocks with static prefixes. E.g. you could always have the :0000 - :FFFF block be your reverse proxies, the next block the storage shards and so on.
api 8y ago
It's not necessary for most applications, but it's extremely helpful for some. It can also be used to realize deployment scenarios where you cluster across clouds very easily provided you ensure connections are secure between nodes/containers/services.
tambre 8y ago
While GCP has IPv6 support for their global load balancers, it's very limited and not sufficient for many uses. For example, I've been working on contributing IPv6 support to GitLab.com [0], which is hosted on GCP. Turns out it's impossible for the main site right now, because none of the global load balancer types allow port 22, which is used for Git traffic. I've no idea why there are even such restrictions, but there's of course a "feature" request for allowing port 22 [1]. I was able to repurpose the work for other parts of GitLab.com, but I've yet to get even those to work, due to the load balancers gobbling up HTTPS/SSL requests [2]. [0] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merge_requests/427 https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg... [1] https://issuetracker.google.com/issues/77944636 https://issuetracker.google.com/issues/77944636 [2] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merge_requests/427#note_102821029 https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg...
- dsl 8y ago
  GLB can't even support TCP and UDP listeners on the same IP, which means you can't put a DNS server behind it.
X-Istence 8y ago
The amount of work that was done at the last two ISP's I worked due to being out of RFC1918 space and thus needing to do overlay networks, and all kinds of fun translating and gateways and overall making a HUGE mess of everything... Because while there is a 10/8, once you start subnetting that and advertising it from multiple sites and start running labs that look and act like production that /8 goes quick. Give me IPv6 any day.
Corrado 8y ago
> This only becomes an issue once you need more hosts than the /8 offered by the 10/8 RFC1918 network, but the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off. It's not that you require more than a /8 can provide, it's more a function of convenience. I have 10 customers, each one of those has 4 environments (Dev, QA, Stage, Prod) and each of these environments need to live in 3 regions, and each region has 3 AZs, and each AZ has 6 subnets. Splitting that up with a 10.0.0.0/8 gets complicated. I would much rather say 2006:abcd:0001:::: is customer A, ::0002::: is customer B, etc. IPv6 gives me plenty of room to maneuver and eliminates the need to worry about IP exhaustion.
all_blue_chucks 8y ago
NAT is the devil. RFC1918 is the devil. Want to filter inbound traffic? It's called a firewall.

ggm 8y ago

But it does at the redirector/Traefik level. Worse, Kubernetes as a model doesn't use IPv6 internally when it should. No reason not to use e.g. ULAs.