SIP over dual stacks - IPv4 and IPv6

Stay Connected - learn more about SIP & IPv6

Yesterday I found an Internet Draft called Testing Eyeball Happiness that gives examples on how to test dual stack deployments. There is a known issue with applications that retrieves multiple IP addresses from the same host name in DNS and , following current RFCs, test them sequentially with a preference for IPv6 addresses. The timeouts when things go bad with one flow are far longer than what the user accepts. Let’s say that Bob (you know him) use his SIP phone to place a call to Alice. Bob’s phone calls an outbound proxy, that wants to forward to another domain. This domain announces both IPv4 and IPv6 addresses in DNS for their proxy. Now, Bob’s proxy actually has an IPv6 address, but is not connected to the Internet with IPv6. The proxy will try connecting to Alice’s domain SIP proxy over IPv6 for quite a long time before it recognizes that there’s no connectivity. Hopefully it will then try another address, but the question is if the user is waiting for that to happen. In telephony, loosing seconds is a catastrophe, especially between requesting a call and getting the first ringing signal. Remember – this is not about media, this is only about signaling. Without signaling, we’ll never get into any media issues.

HTTP and Happy Eyeballs

We’ve seen this problem on the web. Browsers suddenly told us that large sites was not available. Turned out that the new home router enabled IPv6 tunnels and announced IPv6 prefixes on the LAN, something that the firewall blocked. By disabling IPv6 in the laptop, we could reach the web site again. This caused web sites to stop announcing IPv6 and computer owners to disable IPv6. This was no good for the IPv6 migration so the browser developers started to try to find solutions. The Happy Eyeballs discussion in the IETF is about finding algorithms where the browser connects to all addresses in parallel and selects a candidate that answers quickly. In SIP, we need to implement the same fix, over UDP, TCP and STCP. I’ll try to set up some tests at SIPit to see what the current state is.

A quote from the abstract section of the IETF draft:

In a dual stack network (i.e., one that contains both IPv4 [RFC0791] and IPv6 [RFC2460] prefixes and routes), or in an IPv6-only network that uses multiple prefixes allocated by upstream providers that implement BCP 38 Ingress Filtering [RFC2827], the fact that two hosts that need to communicate have addresses using the same architecture does not imply that the network has usable routes connecting them, or that those addresses are useful to the applications in question. In addition, the process of establishing a session using the Sockets API [RFC3493] is generally described in terms of obtaining a list of possible addresses for a peer (which will normally include both IPv4 and IPv6 addresses) using getaddrinfo() and trying them in sequence until one succeeds or all have failed. This naive algorithm, if implemented as described, has the side-effect of making the worst case delay in establishing a session far longer than human patience normally allows. This has the effect of discouraging users from enabling IPv6 in their equipment, or content providers from offering AAAA records for their services.