While the question of IPv6 and NATs still seems open, the base architecture allows for a network without address translation as long as all of our devices are connected to the same network, the IPv6 part of the Internet. Unfortunately it will take a long time to reach that goal. I do believe that IPv4 will be around for a very long time but that the IPv6-only part will grow and become a significant part of the net 10 years from now. To handle that transition we will have to build connections and bridges between the networks. Meet the ALG and the new NAT – NAT64. This is the ugly truth about IPv6 migration – you will need new gateways and NATs in your network.
Spend 30 minutes on IPv6 and learn more!
The ALGs – Application layer gateways – connect the islands
The ALG is an application that bridges the two networks, IPv4 and IPv6, on an application level. It helps connecting single-stack systems on either end to the other part of the network. The ALG is connected to both networks and can handle any protocol-specific issues with bridging. Every server needs management so you want to have a strategy where you move all clients of a protocol to one side of the net as soon as possible internally. When you have that control, there is no longer any need for a the gateway. On the public services, you have no control and need to support both IPv4 and IPv6 from last year and for quite some time in the future.
SIP:: The Session Initiation Protocol and the IPv6 migration
One example of a protocol that is not easy to bridge is SIP, the Session Initiation Protocol, a protocol used for many applications, like IP telephony, chat and presense. The SIP protocol itself has IP addresses embedded in the messages which cause issues if you just build a simple IPv4 to IPv6 SIP gateway on UDP or TCP level. You need to handle the media too.
If you have a SIP platform for realtime communication that runs on IPv4 you seriously want to take a look at IPv6. In a SIP project, managing NAT traversal is complex and takes a lot of resources. Switching all existing phones to IPv6 or dual stack might not be an easy way forward, but adding new phones to a VLAN that operates IPv6 only is easy. In order for these to be able to connect you need a way for calls to connect from an IPv4 only phone to an IPv6 phone.
The SIP standards body, IETF, recommends using an ALG called TURN for the multimedia part of the call. The IPv6 phone allocates an IPv4 address in a dual stack TURN server and uses this when answering the call. The TURN server translates and forwards the media from the IPv4 network to the IPv6 network. For SIP, the solution is to use a dual stack proxy that connects the IPv4 side with the IPv6 side of the realtime network.
Another way is to use translation in the server, either by using a back-to-back SIP server like Asterisk or FreeSwitch or use a SIP proxy with a media relay like Kamailio or OpenSIPS. All of these open source servers can be configured to operate as an application layer gateway for SIP. This takes the burden off the clients, but makes it very hard to use security features in the SIP protocol that signs the messages, since the servers in the middle needs to rewrite the messages.
E-mail :: smart relays for IPv6 gateways
The hope is that all SMTP servers connected to the Internet will be dual stack so that they can connect to both worlds. If not, there will be a problem if you send e-mail to an IPv6-only domain, and your mail server operates only IPv4.
The only option you have in that case today is to set up or buy a service that operates a smart stack dual relay for your mail server, you can call it an e-mail proxy or SMTP ALG. This host receives all outbound e-mail from your mail server and connects to both IPv4 and IPv6. So far I haven’t seen any configuration settings for ”IPv6relay” or ”IPv4relay” in the mail servers I operate so if you’re running Postfix like me, you either install dual stack or send all your e-mail through someone else’s mail server.
HTTP:: The web ALG – a reverse or forward proxy
For web browsers to be able to reach both IPv4 and IPv6 you configure a web proxy that operates on dual stack interfaces. This way, all web browsers can reach all servers. The web proxy is an application layer gateway that can do the translation. This solution of course depends on all applets, active-x controls, javascript applications and other browser companions to use the web proxy.
If you operate a web server and wants to service that to the whole current Internet, not just part of it, you can do that by installing a reverse web proxy in front of your web server. This is a solution already used in large web sites, to offload SSL and to be able to share the load over a cluster of web servers.
Tore Andersson at LInpro-Redpill in Norway was one of the first to alert the world about the issues with dual stack browsers, something that lead to the work with Happy Eyeballs and eventually the World IPv6 day for testing. He recently blogged about his latest solution – to put the web server on IPv6 only and to have a proxy in front of it to serve the IPv4 part of the world. The problem I see with that is that all parts of the famous LAMP stack (Linux, Apache, MySQL, PHP) doesn’t operate on IPv6 only – MySQL still lacks proper IPv6 support. Your server will still have to be dual stack. I haven’t checked the status of the Windows Server, but rumours says that the next release will have improved IPv6 support on the server side.
Regardless if you choose to operate the web server on IPv4 or IPv6, a reverse proxy like Apache or Squid in front of it can handle the dual stack issue. You will still have to check all the browser side logic from both IPv4 and IPv6-only clients to make sure that your web site operates as you expect for all visitors.
A generic solution – NAT64
While many of us hope that the traditional IPv4 NAT will not be a default architecture for enterprise and home networks in the future, the NAT will still be around as a tool to connect networks. One new member of the NAT family is NAT64, a protocol neutral gateway that connects UDP and TCP protocols transparently. While IPv4 and IPv6 are different protocols, they carry the same old UDP, TCP and SCTP. NAT64 is a server that interoperates with a DNS resolver to translate sessions in a transparent way for the clients, that all run IPv6 only. This doesn’t handle the issue with protocols like SIP that embed IP addresses in the messages, but it will handle many protocols.
NAT64 is implemented by Cisco, Juniper, Microsoft and OpenBSD.
XMPP, IMAP, SSH, SMB, NFS, VPN, POP… the list grows
While many applications use HTTP as a transport layer protocol, there are still many different protocols in the TCP/IP world. For each of these, you need to find a solution that works for you – or avoid the problem by keeping dual stacks. The question is if it’s easier to install dual stack on your servers and keep new computers single stack IPv6 than to keep installing and managing dual stacks on every device. You need to come up with your own plan. Dual stacks will be needed on servers for quite a long time, but I doubt that it’s worth the effort on all clients a few years from now. If that’s going to happen, we need to make sure that all services work on IPv6 soon.
My personal bet is that the first devices I will operate IPv6 only will be SIP phones. I’m running a separate project called SIPv6 that you can follow on Facebook and Twitter. Together with the SIP Forum, we’ll start putting pressure on customers and vendors to embrace IPv6. Join us!
Have a great IPv6 Friday!
/Olle
Links: