IPv6 and VoIP: The Transition Nobody Wants to Talk About

The IPv6 transition has been "almost here" for two decades, and for most of the internet it finally, quietly arrived. On March 28, 2026, Google's adoption measurement crossed 50% for the first time: half of the users reaching Google did so over IPv6. APNIC Labs, which measures capability rather than preference and tends to run lower, puts worldwide IPv6 capability at roughly 42% as of spring 2026. Either way, IPv6 is the address family for something like half the internet's users.

VoIP did not get the memo. Production SIP deployments -- trunks, hosted PBX registrations, on-premises systems, the phones on desks -- remain overwhelmingly IPv4. Most VoIP providers do not publish AAAA records for their SIP infrastructure at all. The few that support IPv6 usually treat it as an edge feature terminated at a border element, with everything behind it still speaking IPv4.

This post is about why that gap exists, where the actual breakage lives when IPv6 shows up on a voice network, and what to check when it lands on yours.

Why VoIP is still IPv4

The short answer: SIP is one of the worst-positioned protocols on the internet for an address-family transition, and nobody involved has a strong incentive to move first.

A web browser's addresses live only in packet headers, where the OS and the network can handle translation transparently. SIP is different in a way regular readers of this blog will recognize from the NAT traversal post: it writes literal IP addresses into the application payload, at multiple layers, and expects them to be reachable by whoever reads them.

Add to that the installed base: deskphones with ten-year lifecycles, PBX software with IPv4 assumptions baked into its NAT-workaround logic, and carrier interconnects certified on IPv4 that will not be re-certified without a commercial reason. Voice is also the service where "it works, don't touch it" carries the most weight, because failures are immediately audible and users escalate them fast. The result is a protocol ecosystem running on the old address family while the networks underneath it turn dual-stack.

Where the pain actually lives: addresses inside the message

Take any SIP INVITE apart (the anatomy of a SIP message post does this line by line) and you find IP addresses in at least three places:

Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
Contact: <sip:[email protected]:5060>
...
c=IN IP4 192.0.2.10
m=audio 49170 RTP/AVP 0

The Via header tells responses where to return. The Contact header tells the far end where to send future requests. The c= line in the SDP body tells the other endpoint where to send RTP. On an IPv6 call, each of those becomes IN IP6 with an IPv6 literal. On a dual-stack call, the endpoint has to pick -- and there is no guarantee it picks an address family the other side can reach.

This is the core problem. Signaling and media are negotiated in-band, address by address, and nothing in baseline SIP says "here are both of my addresses, use whichever works for you."

The IETF did try. ANAT (Alternative Network Address Types, RFC 4091 and RFC 4092) defined an SDP grouping mechanism that let an offer carry both an IPv4 and an IPv6 media address so the answerer could choose. It saw almost no deployment outside some IMS profiles, the IETF later recommended against its use, and in practice it is dead. The mechanism that actually solved address-family selection is ICE: gather candidates of both families, run connectivity checks, use what works. That is how WebRTC handles dual-stack every day without anyone noticing. But classic SIP deskphones and PBXs mostly do not do ICE, so in the SIP world the job falls to a middlebox rewriting addresses and bridging media between families. SBCs end up as the practical v4/v6 boundary in almost every real deployment, terminating IPv6 on one side and re-originating IPv4 on the other.

No happy eyeballs for SIP

Web browsers solved the dual-stack client problem years ago with Happy Eyeballs (RFC 8305): try IPv6 and IPv4 nearly in parallel and use whichever connects first, so the user never sees a stall from a broken IPv6 path. It works so well that networks with quietly broken IPv6 mostly go unnoticed by web users.

SIP user agents have no equivalent standard behavior, and most implementations have nothing like it. RFC 3263 tells a UA how to resolve a SIP domain through NAPTR and SRV down to A and AAAA records, but when resolution yields both families, what happens next is implementation-defined. Some phones try AAAA first and wait out a full transaction timeout -- 32 seconds for an unacknowledged INVITE over UDP -- before trying IPv4, if they try at all. Some ignore AAAA records entirely. Some use whichever record the resolver returned first.

This interacts badly with DNS in exactly the ways described in DNS and VoIP. A provider that publishes both A and AAAA records for its SIP hostname is trusting every customer's phone firmware to handle the pair sensibly. If IPv6 is enabled but broken -- a stale router advertisement, a firewall that permits v6 outbound but mishandles the return path -- phones fail to register or take half a minute to place a call, and the failure is intermittent because it depends on record ordering and cache state. "Some phones work and some don't" is the classic DNS-outage symptom; mixed A/AAAA on a half-working dual-stack network produces the same maddening pattern.

NAT64, DNS64, and the embedded-literal problem

IPv6-only networks reach the IPv4 internet through NAT64: a translator with a well-known prefix (64:ff9b::/96) that maps IPv4 destinations into IPv6 addresses. DNS64 makes it transparent by synthesizing AAAA records for names that only have A records, pointing at the translator.

For web traffic this works. For SIP it fails in a familiar way, because DNS64 can only rewrite DNS answers. It cannot rewrite the IPv4 literals inside a SIP message. A registrar that returns a Contact with an IPv4 address, an SDP answer whose c= line says IN IP4 203.0.113.5, a redirect to an IP-literal URI -- none of these pass through DNS, so none get translated. The IPv6-only client is handed an address it has no interface for. Signaling might limp along if it flows through a proxy, but media negotiated by address in the SDP simply has nowhere to go. If SDP negotiation lands on an address family the endpoint cannot use, the call connects and the audio does not.

If that failure shape sounds familiar, it should. It is NAT-breaks-SIP all over again: a device in the middle rewrites headers but not payloads, and the payload is where SIP keeps its addresses.

464XLAT (RFC 6877) is the patch that made IPv6-only mobile networks livable. A translator on the device (the CLAT) presents a fake IPv4 interface to applications and translates their traffic to IPv6 before it leaves the phone; the carrier's NAT64 (the PLAT) translates it back at the far edge. IPv4-only apps -- including SIP clients that write IN IP4 literals into their SDP -- keep working, because from the app's point of view there is a real IPv4 network. The cost: that "IPv4" is a double translation with NAT-like address and port rewriting in the path, so every NAT behavior you have ever fought is potentially present even though there is no NAT box anywhere on your network diagram.

The irony

Here is the part that stings. IPv6, fully deployed, eliminates the single largest source of VoIP misery. No private addresses means no NAT. No NAT means no one-way audio from unroutable SDP, no STUN, no rport fix-ups, no keepalives racing UDP mapping timeouts, no SIP ALG mangling your INVITEs. The entire workaround stack documented in the NAT traversal post exists because IPv4 ran out of addresses; IPv6's whole reason for being is that it doesn't.

And yet the transition mechanics recreate the same class of bug in new clothes. Dual-stack lets signaling negotiate over one family while the SDP offers media on the other: one-way or no-way audio, with globally routable addresses on both ends. NAT64 leaves IPv4 literals stranded in message bodies: unreachable media, again. Different decade, same autopsy: the address in the SDP is not an address the other side can send packets to.

Dual-stack operational reality

If you run voice on a dual-stack network, a few specific things determine whether life is boring or exciting:

Which family a phone registers over matters. The registrar stores the Contact from the REGISTER. If the phone registered over IPv6, inbound signaling comes to its IPv6 address, and any element in the inbound path that is IPv4-only needs something to bridge the gap. Registration family effectively pins the call path.

Signaling family and media family are negotiated separately. Nothing forces RTP onto the same family the SIP dialog used. A well-behaved endpoint offers media on the family it registered over; not all endpoints are well-behaved, and config options like "prefer IPv6" often apply to one layer and not the other.

The SBC is the transition plan. In nearly every deployment that genuinely supports both families, the answer is not endpoint intelligence, it is an SBC doing interworking: IPv6 signaling and media on one leg, IPv4 on the other, with the SBC rewriting Via, Contact, and SDP, and relaying RTP between families. This is the same "terminate and re-originate" trick that solves NAT, applied to the v4/v6 boundary. It works, and it means the "IPv6 support" on your provider's datasheet is usually one box deep.

Mobile clients already live in this world. The big US mobile carriers have run IPv6-only or IPv6-mostly data networks with 464XLAT for years -- Akamai's per-network measurements put the major US mobile operators at roughly 74-88% IPv6 traffic. Every softphone on those networks is either speaking IPv6 natively or being carried by the CLAT, so if your users run mobile SIP clients on carrier data, you have IPv6 traffic today. Any weirdness that only reproduces "on cellular but not on Wi-Fi" deserves an address-family suspect.

Practical guidance

If IPv6 is enabled on a network where you are deploying voice -- or it just got enabled underneath you -- work through this list:

1. Find out what your provider actually supports. dig AAAA their SIP hostnames, and check the SRV targets from their DNS chain too. No AAAA records means your phones should never attempt IPv6 SIP to them, and any IPv6-related failure is local resolution or firmware behavior, not the provider.
2. Check what your endpoints do with dual-stack answers. On a test phone, watch a capture during registration: does it try AAAA first, how long does it wait before falling back, does it fall back at all? This single behavior explains most "phones take forever to register on the new network" tickets.
3. Confirm signaling and media use the same family. In a capture, compare the family the dialog runs over with the c= line in the SDP. A mismatch without an ICE-capable or SBC-mediated path is a one-way-audio incident waiting for its first call.
4. On IPv6-only or NAT64 networks, assume embedded literals break. Any config field holding a raw IPv4 address -- outbound proxy set by IP, provisioning URLs, STUN server IPs -- can fail where a hostname would have been rescued by DNS64 or the CLAT.
5. Test the path, not the checkbox. Run an end-to-end quality test from the actual network segment, on the address family the phones will really use. A browser-based VoIP test uses ICE and will happily pick whichever family works -- useful for proving the network path, but remember your deskphones lack that adaptability.

And then there is the folk remedy: just disable IPv6. It is the first suggestion in every forum thread, and on a dual-stack network with broken v6 it genuinely makes symptoms vanish, which is why it persists. Understand what it costs. You are masking the misconfiguration, so it will return on the next device that cannot disable IPv6. You give up the better path where the provider supports v6 end to end -- a path with no NAT and none of its failure modes. And on IPv6-only access networks the option does not exist: on a 464XLAT mobile network, "disabling IPv6" means disabling the network. The remedy has an expiry date.

The bottom line

IPv6 crossed the halfway mark for the internet at large in 2026, and VoIP remains the conspicuous holdout for structural reasons: SIP embeds addresses everywhere, and the fix-it-in-the-middle machinery is being rebuilt for the v4/v6 boundary quietly inside SBCs rather than in endpoints. The endgame is worth wanting -- native IPv6 voice deletes the entire NAT traversal problem class. Getting there means a long stretch where calls cross an address-family boundary somewhere, and every crossing is a place where the address in the message and the address on the wire can disagree. You know what that sounds like: a call that connects, and silence. Test the paths you actually use, on the families they actually use, before your users do it for you.

Related reading: NAT Traversal: Why SIP and NAT Don't Get Along for the IPv4 version of this misery, and SBC Fundamentals for the box doing the interworking in the meantime.