Stockholm Waterfront 25-26 november 2019

IPv6: Why should all VoIP people care about it?

The current version of the Internet is up for a big overhaul. We have to change the whole infrastructure it runs on, the famous IP protocol. A lot of work needs to be done and it affects everyone that works with the infrastructure. The result of all the hard work? Everything will work exactly as before. Nothing gained for the end-user experience. That’s why very few are paying attention to IPv6 – it is very hard to tell the people in charge of IT projects what the benefit is compared with upgrading all PCs to Windows 7 or installing that new spam filter for e-mail. IPv6 affects every networked application, which of course includes the Open Source VoIP platforms I work with as a developer.

Internet telephony needs IPv6 peer-to-peer addressing

It is easy to explain the need for a unified address space using telephony as an example. The fact that all companies and homes use a private address space that can’t be reached from the outside doesn’t matter when it comes to the old-fashioned Internet applications. The web browser contacts a server on the Internet. The e-mail client contacts an e-mail server on the Internet. The IM/Presence application contacts a server on the Internet. Nothing needs to reach in. Until you start using peer-2-peer applications. And telephony is a very common p2p application, something that everyone use.

  • -”You know that you have a broadband router that use one IP address from the Internet, assigned to you by the provider?”
  • – ”Yes”
  • – ”Do you also know that the broadband router let’s all your devices on the inside share this address by setting up a private address range that is unreachable from the outside?”
  • – ”Yes”
  • – ”If you add an IP phone on the inside – do you want to be able to receive calls?”
  • – ”Yes”
  • – ”How do you think I can call your phone  directly, if we don’t share the address space?”
  • – ”I don’t know. How?”

With IPv6, true p2p Internet telephony will become possible. When we get rid of the need for NAT, network address translation, we can finally separate access and policy. With a unified address plan, every device on the net has the possibility of reaching every other device. Policys might prevent that and we implement the policy in firewall software within the systems or in dedicated systems.

Without IPv6 we have to trick the broadband router to give us access. In order for a phone to work on the inside of a NAT, most implementations connect to a server on the Internet. In order for an incoming call to get through, the phone or the server keeps sending empty messages. As long as these messages are sent – occupying unneeded bandwidth and resources in the network – the NAT believes there’s a communication session going on and let the messages in.The NAT itself has no policy system, it just checks if there’s a client-initiated session going on or not. As long as the NAT believes there’s a session, it will forward packets from the outside to the inside device. When you have an incoming call, the server can forward an alert to the phone and the phone will start ringing. The same setup is used if your organization has a PBX system on the inside and use a SIP trunk provider on the Internet. This solution is uses by a range of applications and are not unique in any way for IP telephony.  IPv6 will make it easier to enable true Internet telephony and other p2p applications, as long as your firewalls let it happen.

The IPv4 addresses are getting harder to get

The heat is on. A growing concern is that even though we have 10% of the IPv4 address space left unassigned, the growth is huge. Virtualization hasn’t slowed down the need for addresses as more and more companies assign a virtual server for each service and need an IP address for each instance, instead of one per server hardware.

I have been working a lot in universities, where the whole IT infrastructure runs on public IP addresses. They will need addresses for each phone. That means not a few single IP addresses, we are talking about a need of at least 10.000 addresses a year for a few years.  And that’s for a single university. RIPE, the European body that assigns IP address ranges to ISPs, has made public their plans for the coming years. Every six months it’s going to be harder to apply for addresses. A few months ago, you could apply based on your predicted needs for the coming three years. 18 months from now, you can only  apply for your needs for the coming three months and you will have to prove that more than 50% of the addresses you apply for is going to be used directly. That’s a huge change and it will impact you as you build the corporate infrastructure for web services, cloud computing and Internet media services – including Unified Communication.

The VoIP business lacks experience and best current practises

The VoIP sector, where I work, hasn’t paid enough attention. The 3GPP IMS platform has in theory built on IPv6, but the implementations I’ve seen in production is based on IPv4. Those of us outside of the traditional telcos continue to build solutions for IPv4 and lack experience of IPv6. There’s a lot of questions to be answered and a lot of experience to build up. We need not only learn IPv6 based VoIP, but also make sure that we know how to handle the migration from IPv4 to IPv6. I am sure IPv4 will still be around when it’s time for me to stop working and take care of orchids in a green house in my garden. But we will soon see IPv6 only networks that we need to communicate with. And they will have to be able to communicate with the IPv4 old-timers.For us server-side developers as well as phone developers, we need to have a plan. This is how I see it, but it’s not a recipe that’s ready, just my current thoughts:

  • First, make sure that an IPv4-only based software understand IPv6 in SIP URI’s and DNS replies. If we can recognize these, we can send all communication through a default IPv6 gateway that will handle conversion. These types of services are often called Application Level Gateways – ALGs.
  • Second, add IPv6 ability to your application. Make sure it runs in an IPv6 only network and can handle communication to an IPv4 only network through the same type of gateway service.
  • Third, add dual stack ability to your application now that you support both IPv4 and IPv6. Make sure that the admin can configure priorities. If you want to reach a domain that responds with both IPv4 and IPv6 in DNS – what’s the preference? Can you handle failover if all servers on IPv6 are not responding? How shall we configure NAPTR and SRV records to indicate our preference on the receiving end? If we’re paying for the ALG service or have limited bandwidth on that link, we want to avoid using that as a default if the callee can handle going directly.

The state of Asterisk – the Open Source PBX

Asterisk is an open source telephony platform, which can be used as a pbx, a voip-to-pstn gateway, an ivr server (you know, ”press one for…”) and for many other telephony applications. It runs on a standard Linux system and is available for free. I’ve been contributing to the Asterisk project for many years and seen it grow from a very small project to a wordwide community and a market leader.

Currently, the official version of Asterisk hasn’t got any support for IPv6, which I’m ashamed of. I’ve had this on my agenda since the first Asterisk conference – Astricon – in Atlanta many years ago. Why hasn’t anything happened? Well, for the answer, please re-read the first paragraph of this article. It’s not a business problem – today. And it doesn’t add any cool new features. It requires huge changes in the Asterisk code, all the way into the core network handling.

The good part of the story is that we have a solution. Marc Blanchet at ViaGenie in Canada has written the code needed for Asterisk with IPv6 support. And it confirms what I just wrote – it’s a huge amount of changes. Marc has been testing this at SIPit – the interoperability events organized by the SIP forum. It’s a proven solution. But too huge a change for the Asterisk development team to swallow it in one bite. We need to make a plan a implement it gradually so that all parts are tested, documented and approved by the developers. There’s also a need for education, training and experience for the development team in IPv6.  A huge project. But very important for the future of Asterisk.

Time to start building the missing experience!

In order to make sure that developers of VoIP platforms get experience of this and to try to refine the above steps, I’m working to organize events that combine training with testing. I will also try to raise the pressure on IPv6 on the SIPit events I can participate in, like I’ve done with TLS during a few SIPits. Every SIP-related event should have sessions on IPv6 and try to understand the state of affairs, educate and raise the pressure.

At the heart of the issue is that if we succeed in all of this, if we get the industry to move to IPv6 not only for VoIP, but for all Internet and IP networks, there will be no visible change. Things will move on. Hopefully, a few new applications that will benefit from end-to-end connectivity will emerge, but the real benefit is that the Internet will continue to work as it does today. No one will thank us for that, we can’t add that to our CVs – ”saved the Internet from breaking down. Nothing happened”.  But if we don’t start doing this soon, chances are that all of us that work with TCP/IP-related issues will be blamed for breakage of the net and will have to retire sooner than expected.

The good thing? They won’t be able to call us and complain.