IPv6 is often touted as being the solution to the problem of the rapidly declining number of free IPv4 addresses. Although this is true, IPv6 also offers a number of other significant improvements over the existing IPv4 system, many of which will play a significant role in the future of VoIP protocols such as the Session Initiation Protocol (SIP).

This article describes the benefits of using SIP in an IPv6 network and illustrates how you can configure ZXTM to give you the benefits of using IPv6 on your local SIP network while still allowing IPv4 users to access your services.

VoIP as a catalyst for address exhaustion

Despite the fact that it is widely accepted that IPv4 is not sufficient to cover the needs of the ever-expanding internet, as highlighted in this article the vast majority of websites still exclusively use IPv4. One of the main reasons for this is the lack of interoperability between IPv4 and IPv6.

As VoIP becomes more and more popular, however, an increasing number of devices are being VoIP-enabled. Desk phones are an obvious example of a device that would not usually require a connection to the internet to operate and many mobile phones are now VoIP enabled as well. Even radios are getting in on the action! Each of these devices must be assigned an IP in order to function, greatly accelerating the rate at which IPv4 addresses are being used.

The benefits of IPv6

Clearly, then, there is a strong case for establishing an IPv6 infrastructure in the interests of future-proofing your network, but as a VoIP provider are there any more pragmatic reasons for switching to IPv6?

1. Quality of Service

One of the greatest advantages of the traditional telephony network (the Public Switched Telephone Network, or PSTN) is that it can guarantee call quality using a technique called Time-Division Multiplexing. This technique provides a constant latency between any two devices that want to communicate over the network.

The IP network, on the other hand, provides no such guarantee – data packets can be delayed, get corrupted or even just go missing, resulting in a poor quality connection between the two devices trying to communicate. Phenomena such as jittering, echo, delays and drop-outs are symptomatic of this problem. The problem is also exacerbated as the distance between the users increases, if any of the users have a poor connection to the service provider or if the network is congested. Although some Quality of Service features have been built around the IPv4 network, such as the Real-Time Control Protocol (RTCP), they are still hampered by the inherent unreliability of the underlying network.

IPv4 was not designed to carry vast quantities of streaming media over the network. IPv6, on the other hand, was, and as such contains inherent Quality of Service assurances. Flow Labels allow the IPv6 network both to see which packets of data are related to each other and to provide them with sufficient priority over other packets in the network based on the type of information they are carrying. As a result, a packet carrying data that a user is more likely to notice missing (for example, containing low-fidelity audio) will not be dropped when the network gets congested.

2. Security

When IPv4 was created, the need for security was not high on the agenda because it was intended to be used on a small scale between trusted peers. As the network grew, however, it inevitably attracted malicious users and security became an issue. A series of protocols, collectively known as Internet Protocol Security (IPsec), were developed to protect data as it traveled across the network. These protocols include the IP Authentication Header, to provide authentication for IP packets, and the IP Encapsulating Security Payload (ESP) protocol, to ensure their confidentiality.

Unfortunately, because IPsec is not an integral part of IPv4, its usage is quite limited. It is, however, built in to the basic IPv6 protocol, greatly enhancing the security of IP traffic. In terms of your VoIP applications, this means users are protected from common VoIP attacks including eavesdropping, man-in-the-middle attacks, replay attacks and false authentication. Best of all, this protection comes free of charge – applications do not have to add any special functionality to use these features like they must for some other forms of security, such as SSL.

3. Mobility

IPv6 already has obvious benefits for VoIP applications, not least of which is the ability to assign a unique, permanent IP to as many mobile devices as one can imagine. An additional IPv6 protocol, Mobile IPv6, has been developed to take advantage of this and extend it so that such devices can move freely between networks without changing that IP or even losing existing connections on that IP. All this happens seamlessly, efficiently, and without the need for a special router when the user is away from their home network. It is also designed to work across many different kinds of network, from Wireless LAN to WiMAX.

This feature will have a huge impact on VoIP devices, allowing them to be reachable at the same address at any time no matter where they are or where they go.

4. NAT

Network Address Translation (NAT) is a feature of IP networks that allows a network of private addresses to exist behind one public address. When IP packets are sent out of the private network onto the public network, the NAT device translates the IP address in the packet to be the public address. Any responses to these packets that are received by the NAT device are translated back to the private IP address of the device that sent them.

This process causes many problems with VoIP devices, which desire to communicate with each other directly. Packets must have traveled out of the private network into the public one before the NAT device can route responses back to the correct private IP address. If both devices wanting to communicate are behind NAT devices, neither can route a packet to the other! A common solution to this is to route all the data through an intermediate proxy, which is not an ideal solution, and not how VoIP was intended to be implemented.

Clients require an intermediate proxy in order to traverse in through a remote NAT firewall

Due to the sheer number of possible IPv6 addresses, each node in the network can easily be assigned a unique IPv6 address. This eliminates the need to have private IP networks and thus the need for NAT devices, making peer-to-peer communication a lot simpler.

Transitioning to IPv6

Clearly, there are a lot of benefits to using VoIP protocols such as SIP over IPv6. Inevitably, though, the changeover will take time so it is still vital to offer these services over IPv4. This is where ZXTM steps in. If you already use ZXTM to load-balance your SIP traffic or if, like many SIP proxy servers, your proxy does not fully support using IPv4 and IPv6 at the same time, ZXTM can help.

The rest of this article will demonstrate how you can use ZXTM to create a gateway between an IPv4 network and a SIP-enabled IPv6 network. This gateway will allow you to take advantage of all the benefits IPv6 has to offer VoIP communications in your private network, while still allowing people to access your VoIP services over IPv4.

Running SIP over IPv4 and IPv6

The above diagram highlights a possible infrastructure that might be used to implement an IPv4/IPv6 SIP network. On the left are several clients running over IPv4 exclusively, on the right are more clients and a SIP proxy (such as OpenSER) running on the local IPv6 network. In the middle are ZXTM and (optionally) an RTP proxy with both IPv4 and IPv6 interfaces. It is assumed that the ZXTM already has an IPv6 IP configured on it.

Configuring ZXTM

IPv4 to IPv6

Setting up ZXTM as an IPv4/IPv6 SIP gateway is quite straightforward. Firstly, you need to create a virtual server to receive incoming IPv4 SIP traffic. For this example, it is assumed that the SIP traffic will be sent over UDP, so create a SIP (UDP) virtual server using the Manage a New Service Wizard and call it “SIP Inbound”. Set the server's port to be the default SIP port, 5060, and set the back-end node to be your SIP proxy's IPv6 address.

Now, go to the virtual server's settings page and enter the “Connection Management” settings page. Unfold the “SIP-Specific Settings” section. By default, the requests that your SIP proxy receives will be addressed to ZXTM's IPv4 IP or domain name. If your SIP proxy is not configured to handle requests that aren't addressed to it, as is often the case, then change the sip_rewrite_uri setting to “Yes”. The other settings we will leave as they are for now.

Now we have a very basic gateway, where incoming IPv4 requests will be translated to IPv6 and passed on to the proxy. As a result of this, people on the IPv4 network can contact the people on the IPv6 network. This is great, but unfortunately people on the IPv6 network can't yet communicate back, and people on the IPv4 network can't use your proxy to talk to other people on the IPv4 network!

IPv6 to IPv4

To solve this problem we'll need another virtual server...

To create this second virtual server, go to the Virtual Servers page and enter the details in the boxes at the bottom of the page. Call the server “SIP Outbound”, set the protocol to SIP (UDP), set the server's port to be some unused port number, in this example we'll use 5090, and set the default pool to the discard pool. Again, go into the virtual server's “Connection Management” settings. Change the value of sip_rewrite_uri to “Yes” and also change the value of sip_dangerous_requests to “Forward the request to its target URI”. This setting permits ZXTM to forward requests to their intended destination.

Allowing this is somewhat dangerous as a user could create a request containing malicious body data and use ZXTM to forward it to a target computer, but because we only want requests from the IPv6 network to behave in this way it is possible to protect against this¹.

Configuring the SIP Proxy server

Now we have a proper gateway that can receive IPv4 requests from one side and IPv6 requests from the other side and transfer them on to the opposite network. The next step is to configure the SIP proxy server to use this gateway.

There are many different SIP proxy servers around and they all work in different ways. In this article some example code will be given for the OpenSER proxy, but it should be possible to apply the same configuration to any other SIP proxy.

The change to the proxy's configuration should occur in the section that controls how outbound requests are routed. In OpenSER this is the “route” section of the openser.cfg file. Your proxy server might have a more complex configuration, but in general when the request is routed the proxy should check to see if the destination is an IPv4 address and, if so, it should send it via ZXTM's IPv6 IP.

One way of doing this in OpenSER might be:

   if( avp_check( "$ruri", "re/([0-9]{1,3}\.){3}[0-9]{1,3}/g" ) ) {
      # This is an IPv4 destination
      if (!t_relay("udp:[{ZXTM's IPv6 IP}]:5090")) {
         xlog( "L_INFO", "Could not relay message via ZXTM!" );
         sl_reply_error();
      };
      exit;
   };
   t_relay();

Now the proxy will route all IPv6 traffic itself and all IPv4 traffic via ZXTM.

When a user on the IPv4 network registers with the proxy, the proxy will save their IPv4 location in its location database. When someone tries to contact this user, the proxy will set the request URI of the invitation to their IPv4 address and, as a result of the configuration above, will route this request to the ZXTM's port 5090. When the ZXTM receives this request it will forward it to the intended target: the IPv4 IP in the request URI.

Finally, there is the question of the session data that the SIP messages have been used to establish. Many networks that handle large volumes of SIP traffic will have a dedicated RTP proxy. This proxy is used to solve the previously mentioned problems of NAT traversal and can also be used to measure the length of calls, amongst other things. If you already have an RTP proxy then this should be able to solve the problem of converting the session data between IPv4 and IPv6 and your gateway is complete!

If you do not have an RTP proxy then ZXTM can perform the role itself. If you set the sip_mode setting to “Full Gateway” (located in the Connection Management settings) for both the inbound and outbound virtual servers then ZXTM will proxy all the voice data that travels on the IPv4 network, allowing devices on the IPv4 network to send session data to those on the IPv6 network and vice-versa.

---

¹To protect your gateway from being used to proxy dangerous requests, go to the virtual server's basic settings section and set the “Listening on” option to “Domain names and IP addresses...” and enter your ZXTM's IPv6 IP into the box that appears. It is still necessary, however, to listen for requests that are part of an existing dialogue on our IPv4 IP, such as BYE requests. These are the potentially dangerous requests that should not be forwarded to an external IP. Set up another virtual server identical to the outbound one but set it to listen on ZXTM's IPv4 IP. Set the sip_dangerous_requests setting to the default “Send the request to a back-end node”. Now any requests that just want to use ZXTM as a proxy will be given to the SIP proxy to determine if they are legitimate.