For several months, I’ve been writing about different aspects of IPv6. This week, I’ll invite you to visit my normal area of work – Open Realtime Communication. The SIP protocol – session initiation 
protocol – is at the heart of this and something I work with almost every day. SIP is ten years old and was written for IPv4 and IPv6 in the original RFC, RFC 3261. What wasn’t considered enough was the migration phase with dual stack use. I see several problems here. What I see in the SIP standards probably also applies to other protocols, including your own application layer protocols. Spend 30 minutes and follow me through the world of SIP and you’ll understand a bit better!
The SIP architecture – clients, proxys and various types of servers
The SIP architecture has a number of components. These are the major ones:
- SIP clients ur User Agents (UA) : In the case of VoIP this is the phone
- SIP proxys: Forwards SIP signalling to the next hop – another proxy or a phone (UA)
- SIP b2bua servers: Terminates a SIP dialog (call) and sets up another call – typically a PBX
There are also additional servers that can help with the IPv6 migration and NAT traversal in IPv4:
- TURN/STUN servers: Media gateways used both for NAT and IPv4/IPv6 traversal
- RTP proxys: Media gateways usually controlled by SIP servers
Dual stack SIP user agents
A dual stack SIP user agent REGISTER with a dual stack location server to receive calls. In the REGISTER the phone updates the server with it’s IP address. Most phones select ONE address. Reading the standard, it’s allowed to have multiple addresses (in multiple Contact headers) but there are no examples of this in any RFC. There are ways for the user agent to indicate that both contacts result in the same UA (by using a UUID identifier). Few proxys support this today. The question here is if a dual stack proxy receives a call to a specific address, how does it know whether the device supports IPv4 and/or IPv6? There’s no clear answer in the documents, even though it’s doable – but I have seen no device do it.
When a phone actually places a call with media it can use ICE to indicate media support for both IPv4 and IPv6. The RFC covering SIP migration to IPv6 puts the burden on this migration on the phones that support IPv6. Since the existing phones mostly support IPv4, it is almost impossible to force these to upgrade to dual stack. The phones that support IPv6 is most likely a dual stack phone – it’s impossible to sell a phone without IPv4 support today.
What the IETF proposes is that an IPv6 only phone (when and if they exist) has to request IPv4 support from a dual stack TURN server before the call, so that the call request (INVITE) has both IPv4 and IPv6 media addresses.
Locating a dual stack SIP server
RFC 3263 documents how a SIP phone or server locates the next hop server. If there’s no route set from previous communication between the entities or from configuration, SIP used the domain name system – like e-mail. The RFC unfortunately says that the SIP software should look up IPv4 or IPv6 addresses – not both. This is wrong and needs to be corrected. The software needs to check DNS for both A and AAAA records.
When the software has found DNS records for both IPv4 and IPv6 the current standard says that a TCP/IP client using any protocol should try IPv6 first. In the world of the web, this lead to a lot of issues that caused web site owners to disable IPv6 on their web – or in some cases move IPv6 connectivity to a separate host name. Many PCs enabled IPv6 automatically (by various kinds of tunnels) so that the web browser thought it had a working IPv6 connection – and a firewall disabled it. When surfing to a site the browser tried for around 20 seconds to connect over IPv6 (following the RFC, trying IPv6 first). In good cases, the browser timed out and tried IPv4 with great success. In worst case, the browser failed and claimed that the web address was not reachable.
To solve this, the IETF has developed a proposal named Happy Eyeballs. With this scheme, that is already implemented in most modern web browsers (with different implementations), the client sets up two connections at the same time – one over IPv4 and one over IPv6. This way, the user doesn’t have to wait for one of the connections to fail before the software tries the next address family.
If a SIP phone fails for 10 seconds before you hear any tone – busy or ringing – you probably already hung up. We can’t have it that way. The SIP world needs to adopt happy eyeballs (or happy earlobes for audio calls) and set up dual connections – both from a user agent to a SIP server and between SIP servers in different domains.
What if the phone doesn’t support dual stack – or you don’t know?
If a SIP proxy receives a call from another domain over IPv6 to a SIP address that only registered with IPv4 there are a few possible ways to handle this:
- It can assume that media support is the same as SIP signaling support. In this case, the incoming call can not be connected to the phone registered for the UA. There’s no standardized and used way for the registered SIP phone to indicate support for both address families. The proxy now either refuse the call or try to fix the situation. The fix is the same as many SIP proxys has handled NAT situations – use a RTP proxy (between IPv4 and IPv6) for the call and rewrite the SIP messages to update the addresses. The IPv6 phone will believe that the phone it rings has IPv6 support and the IPv4 phone that answers the call will believe the caller is using IPv4.
- If there was an error code that indicates to the caller that the call can’t be completed because of address family incompatibility, the caller could retry and use a TURN server to get IPv4 addresses. This code doesn’t exist.
- The proxy can ignore the issue and forward the message, letting the phone handle the situation. After all, the phone that registered an IPv4 address may still be a dual stack user agent – there’s no way for it to indicate dual stack support for media in the registration. If the phone really is dual stack, the call completes happily. If the phone only supports IPv4 the call fails.
To summarize: Supporting both address families, doesn’t automatically indicate support of dual stack situations
The SIP protocol RFC was written for IPv4 and IPv6 – but totally missed many of the issues with dual stack situations. SIP according to RFC 3261 and 3263 works well in an IPv4 or an IPv6 network, but there’s still some standardization to do for handling dual stack deployments. SIP needs Happy Eyeballs.
This article focused on SIP, but many of the issues here can be applied to many other protocols. For SIP we have to measure milliseconds and seconds – the user has very little patience with us. For other protocols that operate in the background, like exchanging mail between mail servers, seconds doesn’t matter, but we need to make sure that both families are used either in parallel or sequentially. You need to check your clients and protocols to make sure you handle situations like this properly and do not harm the communication. If that happens, IPv6 migration will be delayed and we can’t accept that.
The IPv6 World Launch is just a few weeks away!
/Olle
Links: