# IPv6 NAT'ing to IPv4?



## BlueCoder (Jan 31, 2013)

I don't really need to do anything I'm just playing around to see what I can do it. Yesterday for giggles I converted my home network to ipv6. I setup named to only bind to ipv6 and added AAAA records. Everything fine with that. I converted my jails so that they only talk over ipv6. I am sshing only over ipv6.

With ipv4 I nated through pf to get to the internet. I'm wondering if I can still ipv4 nat externally with ipv6 internally. But I'm still rather new to the implementation of ipv6.

First I have get an application to use converted ipv4 to v6 dns addresses I think; more named setup I'm guessing. Then I have to get the packets to route to the firewall+router. No more default routes, router advertisements replace while I have setup rtadvd I'm still blurry on the details. Then as soon as they come over the internal network interface I have to get pf to remap the packets to ipv4.

I thought it would be easy for an ipv6 app to talk to an ipv4 server? With ipv6 it really seems like there are two internets.


----------



## BlueCoder (Feb 3, 2013)

Everything I said before is basically right. IPv6 and IPv4 were designed to coexist in a dual stack but other than that it takes what is called DNS64 (dns 4 to 6 translation) where A records are turned into AAAA records the v4 IP address translated to ::ffff:0:a.b.c.d. You then nat between ipv6 and ipv4.

But sadly it's not built into base. For DNS64 you need dns/bind99 since the named in base is older. And I don't know about pf yet.

There seems to be quite a bit of politics involved with pf. The pf in base is essentially forked from Openbsd. The progressives want new features and to track with the Openbsd features and syntax within a relatively recent time frame. The conservatives want a stable syntax and don't need a newer version. So any specific new features seems to need to be backported and adapted such that it doesn't change the syntax too dramatically to annoy the conservatives.

It sounds to me like pf shouldn't even be in base but be relegated to ports where people can each choose the proper version for themselves. For such an important piece of software I'm surprised the foundation doesn't put more funding and manpower into it.


----------



## J65nko (Feb 4, 2013)

BlueCoder said:
			
		

> I thought it would be easy for an ipv6 app to talk to an ipv4 server? With ipv6 it really seems like there are two internets.


Yes that is a major problem. From Bernstein's article The IPv6 mess:



> The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
> 
> In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other.


----------



## gkontos (Feb 4, 2013)

Given the age of IPv4 it would be almost impossible to design a new IP protocol with backwards compatibility. 

If you start implementing dual stack systems using IPv6 as your main protocol you will see that it is not that hard. Of course, the transition of old systems is still problematic but given the fact that you can use 4to6 and 6to4 techniques, bypassing certain restrictions is not impossible.


----------



## BlueCoder (Feb 5, 2013)

I don't see the reason for the focus on getting servers on IPv6. Servers for decades to come will need to be dual stacked. Servers need the IPv4 address, not users so the focus should be on migrating users. The more users using IPv6 the more servers will migrate to dual stack.

The main focus can and should be on getting clients on IPv6 and getting them on a single stack and then doing the magic at the router/firewall. I don't know about everyone else but I use Freebsd at home on a Firewall, server, workstation, and laptop.

After playing with it I'm convinced DNS64 and NAT64 are how the magic has to happen. NAT is perfectly fine for the temporary connections that IPV6 clients will need for connecting to IPv4 servers. First we will all have it on our firewalls with the firewall handling the tunneling and NATing then ISP's can implement NAT64 upstream when they actually switch to IPv6 only. Only thing that really breaks is DNSSEC from DNS64. But that in itself is a selling point to get servers a real IPv6 address.

GIF tunnels or 6to4 or others, they are just different tunneling techniques and all achieve the same thing. They are pretty simple and a bit of a distraction to the real issues of integration. Quite frankly ISP's can implement it hidden in their cable modems without it even being visible. In fact now that I think about it ISP's probably as a matter of course implement tunneling in their networks already to separate a portion of their internal network from customers.


----------



## BlueCoder (Apr 20, 2013)

Just an update. I resetup my firewall to dual boot OpenBSD and FreeBSD as well as an empty third partition for trying other operating systems later.

I finally have NAT64 working with OpenBSD! I connected to the Internet now through my IPv6 only connected FreeBSD workstation. I had to install BIND 9.9 on OpenBSD to get DNS64 working.

Setup Issues:

First you need to setup IPv6 preference on IPv6 only hosts so it resolves AAAA records first on DNS lookups.

There was a change of syntax as regards to DNS64. With BIND 9.9 I had to set up a wrapper "view" statement around all the zone data. Second I was initially trying to use 0:0:0:0:0:FFFF:0:0/96 and 0:0:0:0:FFFF:0:0:0/96 prefixes. Some sources said to use one prefix or another. Obviously one of them is wrong. I couldn't ping6 with the ::FFFF:0:0/96 prefix. I tried using ::FFFF:0:0:0 and while I could ping6 it and DNS64 would translate, pf seemed to refuse to "af-to" it. As soon as I switched to the prefix "64 : ff9b/96" it would nat it perfectly fine.

One thing to note is that with this ON at home you either need to have the DNS server first drop all AAAA records and then dns64 the A records, or you need an IPv6 connection or IPv6 tunnel, to handle true IPv6 addresses.

I seem to be able to browse from the IPv6 only host. I'll update later with any issues I discover. For now it seems to work. Ideally NAT64 is something that all ISP's should be implementing right now and convert to an IPv6 only network. Then implement IPv4 locally in premises routers for legacy application. Legacy servers can be NAT'd locally to an IPv6 address.

With this strategy IPv6 would be adopted to 90% or greater within 5 years. For the majority of home users it wouldn't only require a new home router or a firmware upgrade to their existing router if they are lucky.


----------

