0

This is not a question about tunnelling, although that may be part of a solution.

With public cloud providers it's trivial to request a load balancer due to providers owning large class A/B/C public IPv4 blocks. However, whilst it's trivial to own an ipv6 block, it's non-trivial to issue load balancer addresses because you can't assume incoming traffic supports ipv6. How to bridge this gap?

Trying to achieve: Given limited ipv4 public addresses (4), instead , generate layer 7 http load balancer A records, which map to ipv4 addresses. These ip4 addresses then route to in-cluster ipv6 cluster addresses. Perhaps SNI is needed here?

Constraints: Can't assume that Ingres traffic supports ipv6, so (if possible) SNAT is needed to rewrite ipv6 -> ipv6 and back again (is this possible?), iptables , and conntrack for connection tracking?

E.g ingress
Load balancer A records   Public ipv4 address  <mapping (not tunnelling)>  Public ipv6 address range  
lb[1-n].example.com  ------>  192.0.2.0/24         ---->   2001:DB8::/32

E.g. egress
ipv6 address range        Public ipv4 address
2001:DB8::/32             ----->  192.0.2.0/24        ----> source ip ipv4 or ipv6

https://sookocheff.com/post/kubernetes/understanding-kubernetes-networking-model/ https://kubernetes.io/docs/concepts/services-networking/dual-stack/ netfilter https://metallb.universe.tf/ https://linux.die.net/man/8/ip6tables https://community.hetzner.com/tutorials/install-kubernetes-cluster

user885983
  • 153
  • 1
  • 4
  • "_These ip4 addresses then route to in-cluster ipv6 cluster addresses._ You cannot route IPv4 packets to IPv6 addresses. The IPv4 header only has 32 bit for the destination address, which is how packets are routed, but IPv6 addresses are 128 bits. Also, if the destination is not running IPv4, any IPv4 packets reaching it would be dropped. You cannot get an IPv4 packet to the IPv6 process in the network stack, and the IPv6 process would not even know what to do with an IPv4 packet, anyway. – Ron Maupin Apr 10 '21 at 20:55
  • Thanks Ron, often questions are not well formed using correct terminology, a little flexibility in thinking what the questioner is trying to ask, or asking for clarification is beneficial . Hope this feedback will be helpful. https://networkengineering.stackexchange.com/questions/73444/route-ipv4-to-ipv6-as-mechanism-to-overcome-not-owning-an-ipv4-block-for-load-ba – user885983 Apr 11 '21 at 14:06

1 Answers1

1

Running services on well-known ports, the server part of the IP tuple is mostly constant. Such as the ever popular https over 443/tcp. Layer 4 load balancer would need an IP address per service, which is not practical with IPv4 exhaustion.

Name based virtual hosts to the rescue. Probably http host headers or SNI.

No, SNAT is not required.

Proxy based load balancers should be able to terminate a IP connection and make a new one, possibly with a different address family. For example, both a.example.net and b.example.net have A records of the load balancer at 203.0.113.69. Virtual host A's backend could be 2001:db8:26:74::a while B's is 2001:db8:26:83::b. If all traffic goes through the load balancer, the backends do not need IPv4 addresses.

Or, getting v4 and v6 to talk to each other can be done at layer 4 without an application proxy or a stateful firewall. SIIT is a stateless way of doing such translation. However, this doesn't solve the problem of needing many v4 address for many services, your one IPv4 gets mapped to one IPv6 on the backend. So likely this does not replace application layer virtual hosts. Still useful if you want to go v6 only in the data center and provide v4 only where needed.

None of this proxying or translation is actually routing. IPv4 and IPv6 are different protocols, they cannot be forwarded unmodified.

Really bridging the gap would be v6 end to end. Not there yet for much of the internet.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • Thanks John I'm digesting the above in detail. Couldn't have put it better myself: "v6 only in the data center and provide v4 only where needed."+the backends do not need IPv4 addresses. For Layer 4 proxying the , if my reading is correct, the Proxy protocol popularised by HAProxy https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt section 4.2. , if the direction can be flipped, gobetween.io implements this protocol with service discovery and appears to be able to proxy the layer 4 ipv6 -> ipv4 so I'm going to experiment with the reverse and wrap my head around SNI which it supports – user885983 Apr 11 '21 at 13:39
  • For anyone else researching Mythic beasts have a reasonable example of ipv4 -> ipv6 backends using application layer for virtual hosts https://web.archive.org/web/20210122090752/https://www.mythic-beasts.com/support/topics/proxy – user885983 Apr 11 '21 at 14:19
  • Not necessarily haproxy's proxy protocol. Reverse proxy in general, terminating on the load balancer which does new connections to backends on behalf of frontend clients. This pattern is everywhere. – John Mahowald Apr 11 '21 at 16:07