SIPv6: Living in a dual stack world

SIP and IPv6 on an IPv6-only network is very much like running SIP on an IPv4-only network. The SIP v2 protocol was designed for IPv6 and it has been in the specification from the very start. The problem starts with devices and servers that live in both worlds and have two stacks with connections to both networks, and networks with gateways between the protocols.

Even IPv4-only devices can meet IPv6 addresses

An IPv4-only device may place a call through a proxy that is dual stack. The proxy forwards according to the DNS records to an IPv6-only end point. This end point rings, then answers and

SIP dual stack proxy server

sends an SDP with IPv6 addresses. The proxy forwards the response and no call can go through since caller and calle are living in different worlds, connected by a dual stack SIP proxy. The interesting part with this scenario is the IPv4 device – will it recognize and be able to parse the response? Will it handle it properly? Will it crash?

The same situation applies for SIP devices on IPv6. The risk of them crashing is almost none, since almost all SIP stacks are written for IPv4 and understands it.

Because of these issues, new additions to the SIP SDP offer/answer model defines new rules to handle this scenario:

  1.  In some cases, especially those dealing with third party call
       control (see Section 4.2 of [12]), there arises a need to specify
       the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in
       the SDP offer.  For this, IPv6 implementations MUST use a domain
       name within the .invalid DNS top-level domain instead of using
       the IPv6 unspecified address (i.e., ::).
   2.  Each media description in the SDP answer MUST use the same
       network type as the corresponding media description in the offer.
       Thus, if the applicable "c=" line for a media description in the
       offer contained a network type with the value "IP4", the
       applicable "c=" line for the corresponding media description in
       the answer MUST contain "IP4" as the network type.  Similarly, if
       the applicable "c=" line for a media description in the offer
       contained a network type with the value "IP6", the applicable
       "c=" line for the corresponding media description in the answer
       MUST contain "IP6" as the network type.

From http://www.ietf.org/id/draft-ietf-sipping-v6-transition-07

This means that the above scenario should not happen – if a device sends an IPv4 offer to a device not supporting IPv4, the media stream should be denied – and the same for IPv6 only offers to IPv4-only devices.

SIP application layer gateways for IPv4 and IPv6

The proper way for the proxy would have been to handle this like it might handle NAT, by using an RTP proxy and do some address translation. Maybe forward the call to an Application Layer Gateway (ALG) – a SIP b2bua that can handle the media streams on both stacks and bridge the call properly. This works as long as we do not require any form of end-to-end security in the call. The IETF documents in this area strongly suggests using STUN relay servers for this.

Showing preference for incoming calls in DNS

DNS works the same for IPv4 and IPv6. Now, if your domain has support for both stacks, but IPv6 is on a tunnelled connection with poor performance, you can suggest a preference for IPv4 in your SRV records. If you have a proper IPv6 connection, you can have the same priority for IPv4 and IPv6 hosts.

The question here is if the calling device – server or user-agent – will understand preferences shown in SRV records. If your server calls a domain that has no IPv4 in the first priority of SRV records – will it look at the second priority or will it give up?

SIP Security and IPv6

From a security perspective, there’s no difference between SIP on IPv4 and IPv6. The same issues that exist and are SIP-specific in the IPv4 network – authentication, identity, confidentiality and non-repudiation – are handled the same way on IPv6. Remember that IPv6 is not a new addition to SIP, it was part of the original design.

The important difference is that network managers have much more knowledge and experience on how to handle security in the IPv4 networks than in the IPv6 networks. While the protocols are very much alike, there are important differences when it comes to security. ICMP and DHCP have different roles in IPv6 networks, broadcast is replaced by multicast, IPv6 packet headers are chained and not fixed and a few more changes that affect the general security framework. Dual stack networks opens up new challenges where traffic arriving on one network can depart on the other. These issues are however not SIP-specific, but needs to be handled in all networks that integrate IPv6.