I was wonder how cloud providers seemed to have a bottomless pits of IPv4 addresses and weren’t more resistant to handing them out like candy. They should be charging more for this scarce resource. AWS was, until now, the only cloud provider to not charge for static public IPv4 addresses, as long as the elastic IP is in use.

I fully expect there will be more pressure in the future to have cloud customers to use dual-stack (both IPv4 and IPv6) or IPv6 only on externally facing services and pool services behind application load-balancers or web application firewalls (WAFs). WAFs should support sending incoming IP4v and IPv6 traffic to an IPv6 only server.

Looking at Imperva’s (a WAF) documentation that should work. I haven’t tested this, so I might just have to do that.

By default Imperva handles load balancing of IPv4 and IPv6 as follows:

  • IPv4 traffic is sent to all servers.
  • IPv6 traffic is only sent to the servers that support IPv6.
  • However, if all your servers that support IPv6 are down, then IPv6 traffic is sent to your IPv4 servers.

Imperva also enables you to configure load balancing so that IPv6 traffic is only sent to IPv6 servers and IPv4 traffic is only sent IPv4 servers. Alternatively, you can configure that Imperva sends traffic to any origin server, regardless of whether it is IPv4 or IPv6.

https://docs.imperva.com/bundle/cloud-application-security/page/more/ipv6-support.htm

  • You would have to use an external tunnel service that will give you an IPv6 address on the internet. As you are sending your traffic through an external provider, it will be slower and they could be monitoring your traffic. Some ISPs even use these tunnelling service to quickly enable IPv6 access.

    Tunnel brokers (RFC 3053) are organizations that provide, often for free, a manually or dynamically configured tunnel that encapsulates your IPv6 packets within IPv4 packets. The IPv6 packets at your home are encapsulated into IPv4 packets and sent across the IPv4-only ISP network to the tunnel broker service. When those packets reach the tunnel broker, they are decapsulated and the IPv6 packets are forwarded to the IPv6 Internet. This method can use a traditional GRE tunnel, an IPv4 protocol 41 tunnel, or might leverage the Tunnel Setup Protocol (TSP) (RFC 5572).

    It is looking like Hurricane Electric (https://www.tunnelbroker.net/) is the only one still providing this service, as far as I can find.

    If you use a VPN that could be another option, if the VPN provider isn’t disabling IPv6 out of a potential privacy concern (PIA). Even if the VPN service supports IPv6, most VPN clients do not and your IPv6 DNS queries could get routed to your ISP. If you were using a VPN for privacy concerns, that would expose what websites you are accessing and defeat the purpose of a VPN. That is why VPN providers will sometime go out of their way to ensure IPv6 is disabled when the VPN is in use.