NAT64 for reaching overlapping IPv4 IPs

[vdbergp11]

I want to reach multiple VPNs that contain overlapping IPv4 addresses from a single device.

Network diagram:

Is this possible? What type of device might be needed? (ideal current candidates include a 650x switch (with Supervisor Engine 720), or a FWSM with a recent ASA version in a 650x switch)

This seems like a nice candidate for stateless NAT64 (probably combined with VRFs), but I can't find documentation for specifying multiple prefixes. (The "nat64 prefix stateless" command seem to only allow a single prefix) (Or is is possible to apply it within a VRF?)

So summary (based on diagram):

Translation device has 3 subinterfaces, one for each VPN (with unique IPs for now)

A unique /96 prefix is assigned to each VPN, so a IPv6 device that want to address the IPv4 device with IP 10.101.22.12 within VPN1, it adresses 2001:DB8:1:10.101.22.12. The device should then do NAT64 to map it to a source IP within the VPN range (Something like 198.51.100.5 for the example) (Multiple IPv6 servers should be supported)

Is this possible with Cisco equipment? Can it be done with NAT64 (or which other mechanism if not)? What type of equipment would be necessary for the NAT and how would the configuration look? (Translation device is R1 in the diagram)

This seems like a nice, clean efficient way to deal with providing common services to multiple VPNs that have overlapping IPs, but the configuration stll seems like it might be difficult, if at all possible currently...

Another note: I don't care about DNS64 currently, so that is optional.

[Marc Luethi]

Hi!

I've been having the same ideas. After studying Tore Andersen's documents...

(older paper, based on stateless NAT64 with it's requirement for IPv4 translatable addresses):

https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf

(newer paper, based on (not quite so-)stateful NAT64)

http://fud.no/talks/20150317-V6_World_Congress_2015-SIIT_DC_IPv4_Service_Continuity_for_IPv6_Data_Centres.pdf

... I gave it a go on an CSR1000V - both stateless and not-so-stateful approaches turned out to be working, but only traffic coming from one single "external IPv4 domain" was being mapped into one single IPv6 prefix.

That's one problem: you can only define a single NAT64 prefix into which the IPv4 domain gets NATted.

There's a second problem:

In the return packet/outbound packet, after NAT64 extracts the (overlapping) v4-destination-address-to-be from the IPv6 address, there will be ambiguity which route is the correct one - into VPN1, VPN2, VPN3, all of which have overlapping IPv4 address space?

I don't think that policy routing would help here, as PBR is done upon ingress and fixes the outbound interface.  IPv6 PBR would then still have to pass along the packet to the NAT64 engine while giving a hint about the intended choice of egress interface. I' not quite shure, but that seems a loooong shot to me.

In short: I think NAT64 currently can only be used once per routing instance. So either...

• it's one IOS XE router per customer/overlapping IPv4 domain (CSR1000V might come in handy, here)
• we get an IOS XE release that has VRF aware NAT64 capabilities (and while wer'e at that - som DNS Fixup Engine right along would be really cool!)

Cheers
Marc