Can a global IPv6 address be NAT'd to an internal IPv4 address at a firewall-level?

As an organisation we've just requested our first IPv6 allocation. At present we are a wholly IPv4 organisation with a global IPv4 address allocation configured on our edge router and used (predominately) to NAT via an edge firewall to internally hosted web servers with private IPv4 addresses.

I appreciate that one way to make our external facing services available to the IPv6 internet would be to implement IPv6 dual-stack across the internal network and directly assign globally accessible IPv6 addresses (in addition to their existing IPv4 addresses) to those servers.

However, even after reading lots of posts and articles on IPv6 transition technologies and the pro's and con's of NAT in an IPv6 world I'm still not entirely sure whether we could essentially replicate our existing set-up but with IPv6 addresses, i.e. could we configure a globally routable IPv6 interface on our edge router with an associated IPv6 'external' interface on our firewall and simply 1:1 NAT globally facing IPv6 addresses to an IPv4 address?

This is obviously based on the principle that we have an IPv6 BGP peering arrangement with our ISP and that our internal addressing needs are met by RFC1918 but we'd like to make selected external services IPv6 accessible.

Solution 1:

As said in the first comment, I also strongly suggest moving to dual-stack, since, in the long run, it is cheaper than implementing NAT solutions. (You will have to do it anyway, so why not now?)

But still, for your problem, there are two possible solutions/workarounds:

• a router with NAT64 support;
• a load balancer with native IPv6 support, balancing servers behind it via IPv4.

Solution 2:

That way of making IPv4 services available over IPv6 is quite common. You need a firewall that can do static NAT64 mappings. I have done it using Juniper SSG boxes myself.

I did see some issues with fragmentation though. Because an IPv6 header is bigger than an IPv4 header the conversion will make the packet slightly bigger. That might cause the IPv6 packet to be fragmented, and I have seen devices that ignore all fragmented traffic. To avoid problems with users that have such a broken device it is better to reduce the MTU on the IPv4 side a bit (1480 or 1400 are common values) so that even after the conversion the packet is smaller than 1500 bytes.

Solution 3:

Can it be done?

Yes.

You will need a stateful NAT64 implementation. Normally these are used to provide local IPv6 clients with access to resources on the public IPv4 internet but there is nothing stopping you using one to allow IPv6 clients on the public internet to access local IPv4 resources. Firewalls can be used to limit what hosts can be accessed through the NAT64 gateway.

Should it be done?

In general I would say no.

The key problem with this approach is that you will lose information on the source IP address of the traffic. There is simply no way to cram a 128 bit source IP into a 32-bit field. So it will be hard to track down and report abuse.

What are the alternatives?

There are serveral. I will present them in what I consider to be decreasing order of preference.

The first option is to deploy dual stack on those segements of your network between the servers and the network edge. This is good practice for when you start deploying IPv6 throughout your network.

The second option is to deploy tunnels leading from your network edge to the servers in question. The tunnels can bring the ipv6 traffic over the IPv4 network to the servers which can then process it natively.

The third option is a reverse proxy. Since it works at the application level it can encode the external IP address information into an application level header. Application side changes may be needed to take advantage of this information but many applications will already support it as reverse proxy setups are quite common in large deployments for other reasons.