SIPv6 :: Overview of RFCs and drafts

Version 2011-03-08

This document is – and will propably be for a long time – work in progress. There’s a lot of drafts and RFCs that cover IPv6 and SIP – and a few that focus on solutions for handling the migration and dual stack issues. We need to be able to set up sessions between mono-stack and dual-stack user agents. We need the solution not to disturb the user experience. Finally, we need the solution to be easy to implement for developers and test for customers.

Developers need to get some clear guidelines on what to do for solving the problem. If the solution involves a lot of new functionality, that is not implemented in most SIP phones today, it will be harder to reach a level where we have good implementations out there and are ready for migration. Maybe we should find a multi-step approach where there is a “basic level” migration guideline and a “recommended level” guideline.
Let’s take a look at the smörgåsboard!

Signalling – managing sessions

Starting from the signalling layer, there are a few issues to handle:

• Telling the location server/registrar about the client’s capabilities (ipv4 and/or ipv6 support) :  A proxy needs to know when getting an inbound request that is forwarded to an AOR how to handle the contacts registred – does a specific contact need translation services? Should we continue the old NAT trick – rewrite the SDP in the proxy (and thus break S/MIME and/or SIP Identity)? How does the proxy understand that two registrations over different address families actually leads to the same UA?
• Finding the next hop without timeouts: If a UA or proxy finds the next hop by DNS, the rules in RFC 3484 (Default Address Selection for Internet Protocol version 6 (IPv6)) state that the IPv6 AAAA record should be used first if the target has both AAAA and A records. If the IPv6 path is broken (bad tunnel, bad IPv6 configuration…) it can take some time to time out before we retry with another family. For HTTP, there’s a new concept named “Happy eyeballs (IETF DRAFT)” that proposes a solution where the browser tries to set up connections over IPv4 and IPv6 at the same time. We need a similar proposal for SIP, something that handles both UDP and TCP. A 32 second (T1*64) timeout before the UA tries another address family is not a good solution. Since all proposals recommend dual stack proxys, we need to solve this.
• Record-routing issues: Only adding IPv4 addresses can lead to loss of optimal signalling path. As it also causes issues with TLS, the SIP world really has to add FQDNs
• Possibly other issues – please tell me!

RFC 3261: The session initiation protocol

RFC 3261 – the original SIP rfc clearly states that SIP supports both IPv4 and IPv6. The RFC doesn’t really cover issues with dual stack deployment, which is why new documents was needed.

The atypes media feature tag for SIP (expired draft)

This draft is really worth reading. It explains a lot of issues with signalling and media and goes through various solutions. It proposes a new capability tag so that an UA can indicate to a registrar or in call setup the various combinations of IP protocols it support. Go read this!

Example of contact indication dual stack support:

<br /> Contact: DS <sip:DS@192.168.25.5:5060>;atypes="ipv4,ipv6";expires=900<br /> 

Media handling

If we have a dual stack proxy, there needs to be rules for how to handle media setup. The proxy takes care of signalling, but what if both devices are on different address families? Or if one device is dual stack – can we simplify the media path? There are various solutions, involving SIP outbound, ICE, turn and some new proposals. The number of implementations of the combination SIP outbound, ICE and Turn in commercial phones is not very high and it’s not a quick and easy project to implement. Neither Asterisk, nor Kamailio – leading Open Source SIP platforms – have support for these. The Resiprocate stack is, as usual, leading the way.

IPv6 Transition in the Session Initiation Protocol (SIP) – RFC 6157 (soon)

This draft updates RFC 3264 (An Offer/Answer Model with the Session Description Protocol (SDP)) with new rules for negotiating sessions. It makes clear that the burden of the migration phase will be put on the new IPv6-enabled devices. If they want to communicate with IPv4 devices, they have to ask a TURN server for relay services of the media. SIP proxys are recommended to be dual stack. Another draft comments on this:

Draft-ietf-sipping-ipv6-transition provides recommendations to solve this issue including recommending Dual Stack (DS) nodes in the core service platform having the signalling and media path traverse these DS elements. While this is viable for big service providers it not viable for smaller ones especially at the earlier stages of IPv6 deployment. Upgrading existing networks to follow all these recommendations requires a large investment. (draft-boucadair-dispatch-ipv6-atypes)

Happy eardrums – Migrating SIP to IPv6 media without connectivity checks (expired draft)

This expired draft suggests that ICE connectivity checks might be to heavy and outlines a different proposal where media is sent over both IPv4 and IPv6 to make it possible to lock into the best stream.

Summary: I’m confused!

My personal feeling is that there are many bits and pieces, many in expired drafts, that is needed to create a working solution. In addition, we need to create a happy-signalling-solution that focuses on dual stack call setup using DNS to find the next hop and possibly Record-route issues. For developers, this is currently very confusing. It’s time to come up with clear guidelines.

I am looking forward to feedback to this page!

/Olle E. Johansson