Many think that IPv6 is going to ease VoIP/SIP. With IPv6, SDP uses not a local but the public IP address. Consequently, NAT is not an issue anymore. However, IPv6 still has a Firewall. The negotiated ports are not open until the device behind the Firewall (usually the phone) uses those negotiated ports. Furthermore, manufacturer-specific NAT Session Timeouts are still an issue because the phone does not know when the Firewall closes the port again. Although I am using IPv6 since the year 2012, my own VoIP/SIP server is dual-stack capable, and I had two occurrences in which IPv6 made my day already (because the DHCPv4 server was down), I am skeptical whether IPv6 is the solution for VoIP/SIP. However, there are DS-Lite networks today which benefit from IPv6. To better understand the current situation, I looked deeper into this ‘IPv6’ written on the datasheets.
Any Internet device, and a SIP phone is an Internet device, has two questions at start: What is my IP address? Who does the DNS resolution? The following four approches answer those two questions.
In IPv4, the de-facto standard is DHCP, which provides the IP address and DNS server. In such a network, the phone has to decide which IP version it prefers. For example, the platform Nokia Symbian/S60 still preferred IPv4. For such phones, IPv6 can be tested only when the DHCP server is off. Nevertheless, if the phone is not able to find a DNS server via IPv6, the phone is able to use the DNS server from IPv4 and ask that for IPv6 resolutions (DNS-AAAA).
In IPv6, the de-facto standard are Router Advertisements (RA), which provide the IP address. Since Apple Mac OS X v10.7 Lion and Windows 10 Version 1703, the DNS server gets extracted from the Router Advertisement. This approach is explained in RFC 5006, RFC 6106, RFC 8106, and called RA option 25, or RDNSS. Consequently, in the year 2020, this rules out Windows 8.1 (till Jan. 2023) and Windows 10 Version 1603 LTSB (till Oct. 2021) only.
How did it work before RDNSS? RA flag O is set (RFC 4861). This means there are other configurations in DHCPv6, like the DNS server.
In this case, the RA flag M is set. This means the phone gets all its information from DHCPv6, including its IP address.
Thanks to those two RA flags, an end-user has not to care about this at all. Out of the box, the phone is dual-stack enabled, in IPv4 it tries to find a DHCP server, in IPv6 it looks for RA, and then continues as dictated by those RA flags. The only two things to consider: Which IP version should the phone prefer for SIP? Well, for VoIP/SIP, it gets IPv6, as everyone says. Which IP version should the phone prefer for RTP? Well, the same version as used for SIP.
There are zillions of test cases. I went for the case of an IPv6-only network (no DHCP server for IPv4 around). Because RDNSS is the newest part (its idea started in the year 2003), I did not go for a DHCPv6 server either. Not one of my phones worked out of the box with this scenario. None! Only five, how complex I configured the rest, support RDNSS.
These send no ICMPv6:
These do not work without IPv4:
These work if you manually configure DNSv6, for example, with 2606:4700:4700::1111:
Success; after manual intervention:
In this test case, RDNSS is not advertised. The phone determines its IPv6 via SLAAC as in test case 1 but has to find its DNS server via DHCPv6.
Worked with Test Case 1, fail Test Case 2:
These do not work without Stateful DHCPv6:
Success; after manual intervention (just enable IPv6, see Test Case 1):
Success:
In this test case, RA flag M is set instructing the device to get an IPv6 from the DHCPv6 server. Furthermore, RA flag A is not set. This tells the device to construct its IPv6 address not autonomously. That flag is not a general flag but located in each prefix information. Consequently, SLAAC is forbidden and the device may not have any other IPv6 address except the one from the DHCPv6 server. If you do not have a static IPv6 prefix, this case is not recommended. This case is possible with AVM FRITZ!OS, DrayTek Vigor, and Lancom LCOS but was not tested by me. If you are interested in a test, please, notify me!
Like with ‘SDES-sRTP’, which turned out not to be about security, this datasheet ‘IPv6’ is not about future interoperability but compatibility with IPv6-only VoIP/SIP services. It is the job of the local administrator to create a network envisioned by the phone manufacturer. Go figure!
The default of an AVM FRITZ!Box is a good example: It offers RDNSS plus Stateless DHCPv6 (RA flag O is set, RA flag M is not set). This is ideal for those devices which do not come with a DHCPv6 client anymore. Still, it catches those devices which do not support RDNSS yet. However, it does not cover those devices which require DHCPv6. If you want to cover those DHCPv6-only devices by offering a Stateful DHCPv6 server without setting the RA flag M, this cannot be done with AVM FRITZ!OS 07.2x. However, for example, DrayTek allows this: LAN → General → LAN 1 IPv6 → Enable IPv6 → (ULA: Off →) DNS: Deploy when WAN is up → Management: Stateless → RA flag O: set → DHCPv6 Server: Enable → Address Allocation: Random → Address Range: Automatic.
Why? Because those phones display the time, and you cannot turn that off. Because those phones check the not-valid-before of SSL/TLS certificates, and you cannot turn that off. One approach: DHCPv6 options 41 for time-zone (RFC 4833) and 56 for time-server (RFC 5908). The three (desk-phone) platforms which succeeded in test case 2 were Cisco, Grandstream, and Yealink. Grandstream does not support NTP via IPv6 at all. Which DHCPv6 options do the remaining two request:
DrayTek DrayOS 4.0.x does not offer any time via DHCPv6, only in DHCP via manually added options: LAN → General → DHCP Server Options → Number: 100; Type: ASCII; Data: CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00. AVM FRITZ!OS offers the time-server via DHCP option 42 (RFC 2132) and DHCPv6 option 56 (RFC 5908; as ULA) but not the deprecated DHCPv6 option 31 (RFC 4075). FRITZ!OS 07.2x does not offer a time-zone either and you cannot add options manually at all. Even if you use a DHCP(v6) server supporting those options, you have to set a time-zone manually with Cisco and Yealink. Again, a failure in the out-of-box experience (OOBE) for both, the desk phones and those two major platforms of routers here in Germany.
Just to outline some parts and their states:
And the combinations of those. For example, you can have (as part) a Stateless DHCPv6 server (as the state) without answering on the option DNS server. For example, you can have (as part) RDNSS (as the state) advertising (as part) a DNSv6 server (as state) via a ULA, and (as part) the phone connects to that server (as the state) via a non-ULA but a global scoped IPv6. If you want to read more about this, the IT security consulting company ERNW in Heidelberg, looked at this already in 2015 and revisited the situation again in 2017.