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.
One of the many Free Software projects I work on is JFFNMS, which is a network management system written in PHP. In light that the last IPv4 address blocks have now been allocated to APNIC it’s probably timely to look at how to manage network devices in a new IPv6 world.
First you need to get the basics sorted out and for that it is best to use the net-snmp command line utilities to check all is well. Then its onto what to do in JFFNMS itself.
Now fixed with proper markup, I hope.
There has been some discussion on the Debian IPv6 list about how the function gethostbyname() has changed. The manual page says this function is obsolete and with good reason.
A new feature of the function is that if a hostname has both IPv4 and IPv6 entries then the order of the return values is not predefined. In fact it used to be you’d get the IPv4 addresses first, then the IPv6. That has now changed and with the more recent glibc you will get an IPv6 address first. Quite often old code doesn’t even check the address family or the size of address structure but just copies the relevant 4 bytes. You then get the first part of an 16-byte IPv6 address wedged into a 4-byte IPv4 address structure which basically means you get a mess.
The fix is pretty simple by changing the system call from gethostbyname() and using getaddrinfo() instead. If you only want the IPv4 addresses, perhaps because other parts of the code have not been checked or changed, then set the hints variable to return only IPv4 addresses.
If one of your packages is starting to play up and unable to connect to certain remote places and is instead trying to get to some “random” address, have a quick check for gethostbyname(). A quick grep across the source code may save a lot of debugging time.
