I found an interesting side-effect of the Juniper firewalls when you introduce IPv6. In hindsight it appears perfectly reasonable but if you are not aware of it in the first place you may have a much more permissive firewall than you thought. My setup is such that my internet address changes every time I connect to an ISP. I have services “behind” the Juniper that I want to expose onto the Internet, in this case a mailserver.
We’re in that in-between place where there is plenty of IPv4 out there, but sometimes you either need or want to get to IPv6 addresses. With the IPv4 address allocations out of ARIN now empty there is going to be an increased need of NAT either between the address families or within it. This is a quick overview of the different sorts of systems that do this address translations.
The best way to describe this is port forwarding across the address families. You can have a IPv4 port on your local device that when you connect to it forwards the connection via IPv6 to a remote device, perhaps on a different port. You can also do it the other way, so connecting to a local IPv6 port will connect to a remote IPv4 port. Of course “remote” could be another port on the same computer.
You could replace squid with any other sort of proxy server that can work as a reverse proxy and understands IPv6. From the deployments I’ve heard of, this arrangement where the IPv4 only webservers are front-ended with a dual stack IPv4/IPv6 squid (or other) reverse proxy server or set of servers. It is a real simple way of getting your webserver onto IPv6, if you cannot do it in the webserver itself. The usual advantages and disadvantages of using a reverse proxy apply here. The better long-term solution is to have the servers just run IPv6 natively, but this is a reasonable stop-gap.
That’s a brief overview of the various packages out there that can help with address translation to either get your servers understanding IPv6 or a client to get to an IPv6 server. Ideally these are only temporary measures but as some methods people use to write programs (the latest I’ve seen has weird hard-coded 4 byte offset tree-table with 256 long list inside – good luck fixing that!) they may be “temporary” for some time.
This program implements NAT64 which is a 1:1 address translation. It can work both ways so IPv6 clients can connect to IPv4 servers and vice-versa. You would normally use this for your own hosts, rather than for connecting to the internet as you need to specify prefixes. It works like the old style static nat ranges in IPv4 where 1.1.1.10-100 would map to 2.2.2.10-100
Now this package is a little back-to-front to the others in that it takes an existing IPv4 only application and makes it able to connect, at least at the socket level, to a IPv6 server. It works by preloading a library which overloads the socket functions like socket() and connect() so it can attempt to find IPv6 servers.
This is a small DNS proxy which can be used to translate IPv4 A records to IPv6 AAAA records. You often use it with translation technologies like Tayga.
This is a small DNS proxy which can be used to translate IPv4 A records to IPv6 AAAA records. You often use it with translation technologies like Tayga.
