IPv4 NAT and IPv6

[mscottini]

What is the best option for integrating a new link (ISP B) that has few IPv4 addresses available for NAT? In the scenario it is necessary that IPv4 Internet users can access all services (more than fifty) through ISP B that provides a /56 IPv6. Is it possible? The Firewall is fully compatiple with IPv6.

[Georg Pauwen]

Hello,

before going into the details of the configuration, what firewall do you have ?

If it is an ASA, you could simply use a default route that points to the ISP CE router:

ipv6 route outside ::/0 next_hop_ipv6_addr

That would take care of the IPv6 part. For the IPv4 part, you could use route maps on the CE routers. Or you could use basic load balancing on the firewall (have a look at the link below, again, this is for an ASA):

https://supportforums.cisco.com/t5/security-documents/loadbalancing-dual-isp-on-asa/ta-p/3127108

[mscottini]

First off all, thanks for the answer.
The firewall is an ASA 5525-x.
I think the routing is the easiest part of the configuration.

But if the ISP A has a problem, the only way for the IPv4 Internet Users is the ISP B and this company has more than fifty servers allowed to users that coming from the IPv4 internet, How is it possible to atend these users from a ISP B that has few public IPv4 IPs? (only 14) but has a lot of IPv6 avaible. NAt64? 464XLAT? Reserve Proxy? Dual Stack?

[James Leinweber · Accepted solution]

If I am understanding your issue correctly, a company wants to set up backup inbound connectivity via ISP-b in case ISP-a is down.  This is a hard problem if the company is not an autonomous system; if they were, they would have their own IPv4 and IPv6 subnets direct from LACNIC and could simply have lower priority routes via ISP-b in parallel with their ISP-a routes.  Outbound connectivity is an easier issue, provided the IPv4 egress traffic isn't so large that ISP-b's small IPv4 subnet runs out of PAT ports - just have lower priority routes to ISP-b on the ASA firewall with a separate set of NAT statements.

If one simply sets up DNS mappings for a server via ISP-a and in parallel via ISP-b, clients will randomly load balance across them.  This is problematic for two reasons: the pipes might not be the same size; if ISP-b is a slower path it could congest.  Also, ISP-b doesn't have enough NAT44 addresses to independently map all of the servers.

NAT64 won't help; that is a technology for IPv6-only clients to access IPv4-only servers via an ISP DNS+NAT gateway.  This is common for LTE4 cell phone network clients, at least in the USA, because those tend to provisioned as v6 only.  464xlat ditto; that helps e.g. obsolete Android apps which only bind v4 addresses in a v6-only transport environment by setting up the mobile device with two v6 prefixes, one for native traffic v6 traffic which goes directly, and another tunneling v4 traffic to a NAT64-style gateway.  The client OS has to support this, and cooperate with the v6-only ISP.  v4-only clients where you have no control over the OS or ISP are your problem, and they won't fit either of those solutions.

Similarly, dual-stacking the servers is a lovely future plan, but only helps dual-stack clients access the servers via either ISP-a or IPS-b over v6; the v4-only clients would still be stuck when ISP-a was down.

Best bet is to set up a dual-stack reverse proxy, accessible via both ISP-a and ISP-b, and route all the inbound connections through it.

The pain here is of course the IPv4 exhaustion problem predicted back around 1992; as a planet we didn't move to IPv6 fast enough to avoid it.

-- Jim Leinweber, Wisconsin State Lab of Hygiene (USA)

[mscottini]

Thanks for your answer!!!