Projecting Views of Legacy IP into Modern IP

Published on 2024-09-14 by ADAM

If you've got an IPv6-only network, or you're on the road to it, then you've deployed NAT64. Even if you don't plan to go IPv6 only for a while, there's a lot of good reasons to deploy NAT64. It's not a "compatibility tool" for accessing the legacy IP internet. It can be used such. But instead it's a network address translation tool, which really means that it's used to project addresses from one address space into another.

For NAT44 (classic NAT you use at home with Legacy IP), this is normally a many-to-one reduction. It doesn't have to be, but that's where it's most useful, and that's all that NAT44 does. It projects your RFC 1918 space into a single public IP. But it also does the same projection in reverse. All public IPs only see the single public IP of the NAT44 and the NAT44 will distribute the traffic to the correct client behind its view.

When hooked together, these NAT44s can form a many-to-many distribution, a projection if you will. A simple case with home networks could be like this.

I have:

You have:

Which sets up a many-to-many projection on both ends.

From my end, 5.6.7.8:2202 is a projection of your ssh server. Some of your IP range was projected into the port space of TCP and UDP. A similar projection exists on your end.

With a bit of ssh port forwarding magic on my end, I could even dedicate a single machine on my network under the IP 10.0.2.22 which opens port 2202 and forwards the connection to 5.6.7.8:2202. This would have the effect of "mapping" your ssh server into my host space. I could also setup a single machine as a "port projection" host and map 2202 to the IP:port it needs and similarly for all the other IP:port pairs. All the ports were projected onto that machine and IP. We could both put a machine like that (with slightly altered configuration) at 10.0.3.1 and ssh 10.0.3.1:2202 would always go to your ssh server, regardless of which network the command was handling that traffic. These could, of course, be VMs not full fledged machines -- the idea is simply that we've got a mechanism to project an address into a network, not just a single host machine with a strange routing table.

This concept could even be applied to things like VPNs for your job at a corporate office. When you connect to that VPN, perhaps with openvpn client, a number of routing commands are run by the openvpn client to "attach" that foreign network to your machine. Packets to 10.128.0.0/9 might be routed to your corporate network, over the VPN, for example. Sometimes corporate VPN implementations are lazy -- they'll just add a new default route over v4 that goes through their network. You'll often see this manifest itself in odd ways. Your traffic, even to outside the corporate network, is slower when connected. If you go to a food delivery site, it'll show you in central Chicago near the Loop, instead of your cushy condo out in East Garfield Park. Or you'll see your office in Chelsea when you want to order food to your condo in Gramercy. Or your office in the Finacial District and your walk up in SoMa. This is a result of the VPN client projecting the remote side's view of the entire legacy IP network into your machine.

The point is -- Network projection is already a fact of life today. But for legacy IP, it's always projected into the same space as overlays. This means that, inevitably, addresses on your local end are going to be shadowed by addresses on the remote end, even if the projection is limited. If your corporate VPN connection routes 192.168.1.0/24 into their network, then you'd better hope that your local network has nothing hanging out there. Worse, if you are visiting another location, perhaps a customer site for whom you are consulting, that location has to also have space which doesn't collide with your home company's space. Or if your company is acquired by another company or merges with another company, there's inevitably two VPNs you'll wind up having to use during the transition. And it's likely that you cannot use both simultaneously due to address overlaps.

Now, with enough patience, a small amount of resources, and perhaps a renumbering of your entire network, you could setup a projection of the remote side's network into yours. Find a machine and dedicate it to running the VPN client -- make it run always, on startup. Run NAT44 on that machine and turn it into a router. forward all incoming packets destined to 10.128.0.0/9, for example, over to the VPN by going through the NAT44 and coming out of the VPN's IP within that network. Over on your main router, add a route from 10.128.0.0/9 (in our example) to this VPN client/server machine, and presto! You've permanently glued that corporate network onto yours! You've projected part of its view of legacy IP space into your legacy IP space.

You could even do this for multiple VPNs! For your company's VPN, for the bigger company that just ate your company up for breakfast, for the company that you're secretly moonlighting for, for your spouse's corporate VPN... even for the corporate VPN that your deadbeat sister-in-law's husband needs for his job, ever since you let them crash in your guest room two years ago, when the bank foreclosed on their house... Whatever you need... you could glue together a really bizarre view of a network via this projection. However, you'll have to carefully make sure that there's no legacy IP collisions. If deadbeat-bro's work uses 10.128.0.0/9 also... well, maybe you could put that under 10.0.0.0/9 and make him remember to subtract 128 from the second digit... But then that breaks DNS a lot. Getting multiple projections to live together in the same space is tricky.

But let's look at modern IP, IPv6. For modern IP the legacy IP space of IPv4 is a paltry rounding error if taken out of any one of its vast subnets, of which it has a near limitless supply as well. This affords us a very intriguing opportunity -- we can map the IPv4 space into IPv6 multiple times... one for each view we might need... and you can't even measure the imposition on your address space by losing that sliver of it. Thus you can project for different mixes of RFC 1918 space for different networks into your modern IP space in some ULA or another and it works amazingly well!

If you're running your network IPv6-mostly, this is a task you've already done once! Your NAT64 device (maybe running on your gateway/router?) is such a projection. I, for example, use fd64::/96 as my NAT64 prefix. This means that the entirety of legacy IP (IPv4) space, as seen from the device running NAT64, is projected up into modern IP space. fd64::8.8.8.8 is Google's public DNS over IPv4, projected into my IPv6 space. Yes there's 2001:4860:4860::8888 to get to it as well... but that's in native IPv6. fd64::10.100.5.1 is the NAT64's view of 10.100.5.1 projected up into IPv6. And Google already offer a DNS that works with a different projection. Using 2001:4860:4860::6464 as your DNS server, google will serve up fake AAAA records for sites without them, projecting their legacy addresses into 64:ff9b::/96. If you put your NAT64 gateway over there, then that's where your projection lives.

But that's not the ONLY projection you can have! Take the VPN client/server from a few paragraphs up... Run NAT64 on it in addition to NAT44... Give it a different nat prefix. Perhaps you work for Beef Book (a popular social networking site for cows)... You can map the view of legacy IP space seen by their VPN to fd64:beef:b00c::/96, for example. In that absurdly crowded house, fd64:1::/96 could be a projection for your first job, fd64:2::/96 for your second, fd64:babe::/96 could be for your spouse, and fd64:f00c:0ff::/96 could be for your deadbeat sister-in-law's husband. You just teach them to write their prefix before an IPv4 literal that they have to type, and everything just works. For example, teach your spouse to write fd64:babe::192.168.1.5 to get to the Windows Terminal Server to start an RDP session -- you'll get tons of brownie points for babe in the name! You can tell that deadbeat what you really think of him, every time he types ssh fd64:f00c:0ff::10.71.33.44 when he has to login to a build server... And none of this breaks anything for them, except for DNS.

To fix this in DNS, you could manually add a few entries to your zone (or pirate their work zones!) and point them at the right NAT64 prefix. You could also give each of them a different IP to get to your dns fd00::53 for yourself fd00:babe::53 for your spouse, etc... And set the NAT64 prefix on each view's DNS64 options to the right one for that person. You can use Bind's mapped ACL keyword in the configuration to only map RFC1918 space IPs to those per-user prefixes. Alternatively, if they need DNS to work for their mapped RFC1918 space you can give folks static IPs on your network and use the clients ACL in Bind to give different DNS64 suffixes per querying IP. Overall, there's a few different options.

The overall idea here, though, is that multiple views of the IPv4 address space can be easily projected into your ULA space on IPv6. There's incredible practical uses to this. For example, if your company was acquired and you have to scp a directory from one server in one network to another, you can do this from a shell on your network easily: scp -r username_for_corp_1@fd64:1::10.1.2.3:/path/to/tree username_for_corp_2@fd64:2::10.1.2.3:/path/to/tree and away you go!

This insight can be applied at the corporate level, during a merger or acquisition. It's long been known that RFC 1918 collisions are a major pain point in inter-company networking and that IPv6 migration helps with that. I suggest that when a merger or acquisition happens, if the companies are not IPv6 enabled before the relationshp that they should NOT focus efforts on a years long RFC 1918 unification and renumbering project. Instead, they should focus on deploying IPv6 in both companies. Then resort to projecting views of both companies' legacy IP space into IPv6. These two IPv6 networks needn't even be unified yet. As long as ULA prefixes are chosen cleanly, then the unification can be done painlessly.

The fact is that the end users of the networks will have to tolerate toggling between two different VPN connections or IPv4 network views until the unification is completed. And that takes years. Whereas an IPv6 roll-out can proceed along fairly quickly for end-user desktops and a set of NAT64 projections to both legacy networks can be rolled out fairly quickly (without having to resort to VPN client hacks, but instead just using the appropriate routing). And IPv6 rollouts can be done non-disruptively with Dual Stack and other solutions. Every desktop OS today is IPv6-Ready: Just turn it on!

In such a scenario, once IPv6 is available at the destkop and the user has Dual Stack, then the IPv4 view of either company's network can remain unchanged but the user can be trained to type 64:ff9b:1::10.1.2.3 for company 1's network and 64:ff9b:2::10.1.2.3. Or the network admin could be a bit daring and go for a really simple prefix, like 1::1.2.3.4 and 2::1.2.3.4... but that might break some things.

In summary, recognize that NAT64 is a projection tool which projects a particular view of the legacy IP (IPv4) space into a miniscule segment of the IPv6 space, and that nothing prevents one from doing this multiple times for different views. This means that adoption of IPv6 with NAT64 can be used to directly solve the problem of overlapping IPv4 allocations, instead of delaying the adoption until "everything settles down". IPv6 doesn't just prevent further such overlapping allocations once adopted, but it can mitigate any that exist immediately upon adoption.