IPv6 in Mobile Networks: 464XLAT, NAT64, and DNS64 Explained Simply

Picture this: you open an IP checker on your phone and it shows an IPv4 address. But when you peek at the phone's network interface settings, you see a shiny long IPv6 address. How is that possible? The device lives in an IPv6 world, yet the website confidently logs four dotted decimal numbers. Where's the switcheroo?

It's not a bug and it's not magic. It's a carefully designed translation system that carriers have been rolling out worldwide for over a decade. And if you work with mobile proxies, scraping, multi-accounting, or simply want to understand what happens to your traffic, getting this mechanic down is crucial.

In this guide, we'll follow a packet's full journey — from an app on your phone to the target website. We'll break down 464XLAT into its components, understand the roles of NAT64 and DNS64, see exactly where the outgoing IPv4 address originates, and learn how to diagnose the connection stack yourself. This isn't a shallow overview. It's a deep dive for those who want to know not just what happens, but how and why.

Introduction: Why the Phone Gets IPv6 but the Website Sees IPv4

Let's start with the paradox at the heart of it all. A modern smartphone on a major carrier's mobile network is almost certainly connected via IPv6. In fact, it often doesn't even have a real IPv4 address on the radio interface. The carrier simply doesn't assign one. And this is a deliberate decision driven by a severe shortage of address space.

But the internet isn't uniform. A huge number of websites, APIs, and services are still only reachable over IPv4. They have no AAAA record in DNS; their servers don't listen on IPv6. If phones could only speak IPv6, half the internet would be inaccessible. So we have a contradiction: the device speaks a new language, but its conversation partner only understands the old one.

Resolving this contradiction is the main topic of our discussion. A technology called 464XLAT, together with NAT64 and DNS64, creates an invisible bridge. The device sends packets over IPv6, and somewhere deep in the carrier's network, those packets are transformed into IPv4 and sent to the target server with a real IPv4 address. The server responds, and the return path goes through the same transformation in reverse.

That's why the target website sees IPv4. That's why a mobile proxy built on a real phone or modem from a carrier delivers an IPv4 address externally, even though inside the device everything runs on IPv6. The switch doesn't happen on the phone or at the website. It happens on an intermediate node in the carrier's network called the PLAT.

What you'll learn by the end of this article:

• How the IPv4 address shortage works and why it forced carriers to adopt IPv6
• What APN types are and how IPv4v6 differs from pure IPv6
• How 464XLAT works step by step, where CLAT lives, and where PLAT lives
• How NAT64 and DNS64 make a website without an AAAA record accessible
• Where a mobile proxy's outgoing IPv4 address comes from
• How happy eyeballs makes an IP checker display IPv4 one time and IPv6 the next
• Practical commands to diagnose the connection stack
• Why the /64 subnet is treated as a single client and what that means for accounts

Let's set clear boundaries upfront. We're talking exclusively about network mechanics. We won't discuss what's cheaper to buy or which protocol is better from a business perspective. This is an engineering guide, not a market overview.

Basics: The IPv4 Shortage, the Move to IPv6, and APN Types

To understand the whole structure, we start with the foundation. And the foundation here is one thing: the catastrophic shortage of IPv4 addresses.

Why IPv4 ran out

The IPv4 protocol uses 32-bit addresses. That gives about 4.3 billion unique combinations. Back in 1981, when the protocol was standardized, that seemed astronomically large. Who could have imagined there would be more devices than people on the planet?

Reality was harsh. Smartphones, tablets, smartwatches, refrigerators, cameras, cars — all need addresses. By the early 2010s, regional internet registries began exhausting free blocks. Today, getting a large block of public IPv4 addresses is practically impossible, and on the secondary market they trade for tens of dollars each.

For a mobile carrier with tens of millions of subscribers, this is a fundamental problem. Giving every smartphone its own public IPv4 address is physically unrealistic. There simply aren't enough addresses.

How IPv6 solves the problem

The IPv6 protocol uses 128-bit addresses. The number of possible combinations is so vast that the human mind can't grasp it — roughly 340 undecillion addresses. Roughly speaking, you could assign multiple addresses to every atom on Earth's surface and still have plenty left.

A carrier gets a huge IPv6 block from a registry and hands them out to subscribers with enormous generosity. Typical practice is to assign each subscriber device an entire /64 subnet. That's 18 quintillion addresses for a single phone. Keep this fact in mind — it will play an important role in the section on multi-accounting.

What an APN is and why its types matter

APN stands for Access Point Name. It's a configuration profile that tells the phone how to connect to the carrier's packet network. When a smartphone sets up data transfer, it asks the network to create a session with a specific protocol type.

There are three main types of PDN or PDP context:

• IPv4 — the device gets only an IPv4 address. Classic legacy setup. Works, but requires addresses that don't exist.
• IPv6 — the device gets only an IPv6 prefix. No IPv4 on the interface at all. Most economical for the carrier.
• IPv4v6 — dual stack. The device asks for both types of addresses within the same session.

Here's the subtle point. Even if the phone asks for IPv4v6, the carrier may only hand out the IPv6 part and either refuse the IPv4 part or assign a private address through translation. Many large carriers are configured so that the subscriber gets pure IPv6 by default, and compatibility with the IPv4 internet is provided by the 464XLAT technology we already mentioned.

Here's a helpful analogy. Imagine the whole world switched to a new language for communication, but a bunch of old institutions still only accept documents in the old language. The government can't give every citizen a personal old-style passport — there aren't enough. So they issue everyone new documents, and at the entrance to old institutions they place an interpreter. That interpreter is 464XLAT.

Deep Dive: 464XLAT by Components

Now we're ready to dissect the technology itself. The name 464XLAT is read as four-six-four translation. The numbers capture the essence: a packet starts life as IPv4 inside the app, travels over the network as IPv6, then becomes IPv4 again at the exit. XLAT is short for translation.

At the core is a standard for translating addresses between protocols, described in IETF specifications. But 464XLAT adds an architecture of two components that work together.

CLAT — translator on the device

CLAT stands for Customer-side translator. It lives right on your smartphone, built into the operating system. On Android, a special daemon performs this function; other systems have similar modules.

CLAT has one job, but it's important. When an app on the phone wants to send a packet over IPv4 — for example, it uses an IPv4 socket directly or reaches an IP address directly — CLAT intercepts that IPv4 packet and wraps it in IPv6. Technically, it performs header translation using a stateless translation algorithm, converting the IPv4 source and destination addresses into corresponding IPv6 addresses using a pre-known prefix.

CLAT creates a virtual network interface on the device, assigned a private IPv4 address. Apps see this address and think they're living in a normal IPv4 environment. They have no idea that underneath it all, everything has long since moved to IPv6.

PLAT — translator in the carrier's network

PLAT stands for Provider-side translator. This is a powerful node somewhere in the carrier's core network, implementing the NAT64 function. This is where the final transformation happens.

PLAT receives IPv6 packets coming from the device and extracts the original IPv4 destination information. It then performs stateful translation: turns the IPv6 packet back into an IPv4 packet, substitutes one of the carrier's public IPv4 addresses from its pool as the source address, and sends the packet out onto the regular IPv4 internet.

The key word is stateful — maintaining state. PLAT keeps a table of mappings so that reply packets from the server are correctly returned to the device that initiated the connection. This is essentially the same principle as classic NAT, but between different protocols.

Why two translators

A reasonable question arises: why do we need CLAT on the device if PLAT is going to translate everything anyway? The answer lies in apps that don't understand IPv6.

Many applications are written with hard-coded IPv4 usage. They request an IPv4 socket, work with IPv4 literal addresses, and some protocols like old implementations pass IP addresses inside the payload. If the device only had pure IPv6, such apps would simply break. CLAT gives them the illusion of a full IPv4 environment while remaining invisible.

So the pair works like this: CLAT solves compatibility on the device, PLAT solves compatibility in the internet. Together, they form a seamless bridge.

NAT64 and DNS64: How a Site Without an AAAA Record Comes Alive

We've covered packet translation. But there's another fundamental problem — how does the device even know where to send an IPv6 packet if the target site exists only in the IPv4 world and has no IPv6 record at all?

Here enters the duo of NAT64 and DNS64. They work closely together, and you can't understand one without the other.

The problem of a missing AAAA record

In the domain name system, addresses of different protocols are stored in different record types. An IPv4 address is stored in an A record. An IPv6 address is stored in an AAAA record, often pronounced quad-A.

When a pure-IPv6 device wants to open a website, it asks DNS for an AAAA record. But if the site has no IPv6 infrastructure, it also has no AAAA record. It only has an A record with an IPv4 address. The device gets an empty response, and in theory it would say: site unreachable. But thanks to DNS64, that doesn't happen.

How DNS64 works

DNS64 is a special DNS resolver operated by the carrier with a superpower. When the device requests an AAAA record for a domain and a real AAAA record doesn't exist, DNS64 doesn't give up. It does the following:

1. Asks the authoritative server for a regular A record and gets the site's IPv4 address
2. Takes that IPv4 address and synthesizes a fake AAAA record from it
3. For the synthesis, it embeds the 32 bits of the IPv4 address into a special IPv6 prefix
4. Returns this synthesized AAAA record to the device as if nothing happened

The device receives a valid IPv6 address and happily sends packets to it. It doesn't know and doesn't need to know that this address is artificial.

The synthesized prefix 64:ff9b::/96

Now we've reached one of the most recognizable artifacts of the whole system. For address synthesis, a specially reserved prefix 64:ff9b::/96 is used. It's called the Well-Known Prefix and is standardized specifically for NAT64 translation.

The mechanics are simple and elegant. The prefix occupies the first 96 bits of the address. The remaining 32 bits are exactly the size of an IPv4 address. DNS64 simply appends the site's IPv4 address to the end of the prefix.

For example, if a site's IPv4 address is expressed as four numbers, the synthesized IPv6 address will look like the prefix 64:ff9b followed by those four numbers encoded in the last 32 bits. When such a packet reaches PLAT, the node sees the familiar prefix, understands it's a NAT64 translation, extracts the last 32 bits, and gets the real IPv4 destination. Then it sends out a regular IPv4 packet.

Some carriers use their own network prefix from their address space instead of the well-known prefix. The logic is the same; only the specific value of the first bits changes.

How the pair works together

Put the puzzle together. DNS64 is responsible for ensuring the device gets an IPv6 address for reaching the IPv4 internet. NAT64 in the form of PLAT is responsible for making the packet to that address actually reach the IPv4 server. One without the other is useless: DNS64 creates an address that only NAT64 can handle, and NAT64 only handles addresses that DNS64 synthesized.

What about sites that have a real AAAA record? Things are simpler here. DNS64 sees a real AAAA record and simply returns it without any synthesis. The device connects to the site directly over IPv6, bypassing the entire translation machinery. That's the optimal end-to-end path.

The Packet's Path from App to Site with 464XLAT: A Walkthrough

It's time to put all the mechanics together into a single step-by-step diagram. Let's follow one packet from its birth in an app to its arrival at the target IPv4 server and back. This is the exact route that mobile proxy traffic takes.

Forward path: from phone to site

1. Step 1. The app wants to connect. An app on the phone decides to open a site that has only IPv4. It asks DNS for an address.
2. Step 2. DNS64 synthesizes an address. The carrier's resolver doesn't find a real AAAA record, takes the A record, embeds the IPv4 address into the 64:ff9b::/96 prefix, and returns a synthesized AAAA record.
3. Step 3. The app sends a packet. Two possibilities. If the app works over IPv6, it immediately sends an IPv6 packet to the synthesized address. If the app is hard-wired to IPv4, it sends an IPv4 packet to the CLAT virtual interface.
4. Step 4. CLAT translates IPv4 to IPv6. In the case of an IPv4 app, the CLAT daemon intercepts the packet and, according to stateless translation rules, turns it into an IPv6 packet using the same NAT64 prefix.
5. Step 5. The packet travels over the radio network. Now it's a pure IPv6 packet. It passes through the base station and the carrier's mobile core network. Inside the entire radio part, only IPv6 lives.
6. Step 6. The packet reaches PLAT. In the network core sits the PLAT node with the NAT64 function. It sees a packet with a destination starting with the NAT64 prefix.
7. Step 7. PLAT translates IPv6 to IPv4. The node extracts the last 32 bits of the destination address — that's the real IPv4 of the site. Then it substitutes a public IPv4 from its pool as the source, records the mapping in its state table.
8. Step 8. The packet goes out to the internet. Now it's a regular IPv4 packet. It travels over the global network to the target server.
9. Step 9. The site sees IPv4. The server receives a connection from the carrier's public IPv4 address. In its logs, it records that IPv4. This is the moment of truth: the site never knows the packet originally started life in an IPv6 environment.

Return path: from site to phone

1. Step 10. The server replies. The site sends a reply IPv4 packet to the public address it saw.
2. Step 11. PLAT finds the mapping. The NAT64 node looks in its state table, determines which device the connection belongs to, and reconstructs the IPv6 address.
3. Step 12. Reverse translation to IPv6. PLAT turns the IPv4 reply into an IPv6 packet and sends it back through the network core to the phone.
4. Step 13. CLAT returns IPv4 to the app. If the app originally worked over IPv4, CLAT on the device translates the IPv6 reply back to IPv4 and delivers it to the app through the virtual interface.
5. Step 14. The app receives the reply. To the app, it all looks like a normal IPv4 exchange. The circle is closed.

Pause for a second and appreciate the elegance of this design. The packet changed its protocol identity four times, passed through two translators, and the endpoints — the app and the site — never suspected a thing. Each sees only its own familiar IPv4 world.

What This All Means for Proxies: Where the Outgoing Address Is Born

Now let's apply all the theory to the practice of mobile proxies. This is the most important section for anyone working with traffic.

Where the outgoing address is born

A mobile proxy is essentially an entry point to the network via a real mobile device or modem connected to a carrier. When you route traffic through such a proxy, it goes out to the internet exactly as traffic from a phone would.

And we already know what happens to that traffic. It goes through 464XLAT, reaches PLAT, and there it is assigned a public IPv4 address from the carrier's pool. That PLAT address becomes the outgoing address of your proxy. It is born not on the device, not on the modem, but at the NAT64 node in the carrier's network core.

That's why a mobile exit is usually IPv4. The device itself lives in IPv6, but the point where traffic exits to the global internet toward IPv4 sites is PLAT, which delivers IPv4.

What the target site ultimately sees

The target site sees the carrier's public IPv4 address. This is the address of the CGN or NAT64 node, behind which many subscribers may be hidden. The site does not see the device's internal IPv6 address, nor does it see the virtual IPv4 of the CLAT interface. Only the external IPv4 of PLAT.

This is a fundamental point. Mobile proxies are valued because their IPv4 addresses look like those of real subscribers — because technically, they are. Many real users share the same public IPv4 through a single PLAT. From the perspective of the target site, such an address is indistinguishable from a regular mobile client.

When a site might see IPv6

But the outgoing address isn't always IPv4. If the target site has a real AAAA record and full IPv6 infrastructure, the device will connect to it directly over IPv6, bypassing PLAT. In that case, the site will see an IPv6 address from the subnet allocated to the subscriber by the carrier.

That's why the same mobile proxy can show different address types to different sites. For a site without IPv6, it's a public IPv4 via NAT64. For a site with IPv6, it's a real IPv6 directly. This is not a glitch; it's the normal behavior of a dual-stack system.

Checklist for understanding the outgoing address

• Device in an IPv6 network — yes, almost always with major carriers
• Outgoing address to an IPv4 site — public IPv4 of the carrier's PLAT node
• Outgoing address to an IPv6 site — real IPv6 from the subscriber's subnet
• Where translation happens — at PLAT in the network core, not on the device
• What the IPv4 site sees — the carrier's shared IPv4 address, shared among subscribers

Dual Stack and Happy Eyeballs: Why the Check Shows IPv4 One Time and IPv6 Another

You've certainly encountered situations where an IP checker displays different addresses on repeated requests — sometimes IPv4, sometimes IPv6. That's puzzling. Let's sort out why.

What dual stack is

Dual stack means the device simultaneously has both an IPv4 address and an IPv6 address and can use both protocols. In a mobile environment, this is often implemented through an IPv4v6 APN or through a combination of native IPv6 plus CLAT delivering a local IPv4.

When a client has a choice of two protocols, the question arises: which one to use for a particular connection? In the past, this was handled crudely and led to delays. If the IPv6 path was broken, the browser would wait a long time for a timeout before falling back to IPv4. Users suffered from slow loading.

The happy eyeballs algorithm

To solve this, the happy eyeballs algorithm was invented. The idea is not to guess which protocol is better in advance, but to run a race.

Here's how it works in a nutshell:

1. The client requests both an A record and an AAAA record for the domain simultaneously
2. After receiving addresses for both protocols, it starts establishing connections almost in parallel
3. The IPv6 attempt usually starts first with a small head start of a few tens or hundreds of milliseconds
4. If the IPv6 connection establishes quickly, it is used
5. If IPv6 lags or doesn't respond, the client switches to IPv4 almost immediately
6. The winner of the race is used for data transfer; the losing connection is closed

The algorithm favors IPv6 when it works well, but doesn't let it slow things down if something goes wrong. Hence the name — eyes stay happy because there are no delays.

Why the checker shows different addresses

Now it's clear where the inconsistency comes from. When you open an IP checker, here's what happens:

• If the checker has both A and AAAA records, happy eyeballs kicks in
• Depending on which connection wins the race at that particular moment, you'll see either IPv4 or IPv6
• Network conditions, load, connection cache — all influence the race outcome
• On the next request, the race may end differently, and the address changes

This is not a proxy error or connection instability. It's the expected behavior of dual stack under happy eyeballs. If you need a predictable result, you have to force a specific protocol version — more on that in the next section.

Practical insight

Many mistakenly think a mobile proxy is unstable when they see jumping addresses on a checker. In reality, it's healthy behavior of a modern network. If you want to see only an IPv4 exit, reach services without an AAAA record or force IPv4 at the client level. Then the picture will stabilize.

Practice: How to Check Which Stack Your Connection Uses

Theory without practice is dead. Let's arm ourselves with specific commands to see with your own eyes what's happening with your connection. All tools are standard and available on most systems.

Look at interface addresses

The first thing to do is see what addresses are assigned to network interfaces. For IPv6 use:

• ip -6 addr — shows all IPv6 addresses on all interfaces
• ip -4 addr — same for IPv4
• ip addr — shows everything at once

Pay attention to address types. Global IPv6 addresses usually start with 2000::/3. Link-local addresses start with fe80 and are not routed externally. If you see a global IPv6, the device has full IPv6 connectivity. If you also see a private IPv4 on a separate interface, that's likely the CLAT interface.

Check reachability with ping

To test whether a specific protocol works, ping helps:

• ping6
  or ping -6

  — checks IPv6 connectivity
• ping -4
  — checks IPv4 connectivity

If ping over IPv6 to a global node works, you have working IPv6 connectivity. If only IPv4 works, then IPv6 is either not configured or not working.

Force protocol in curl

The most powerful diagnostic tool for web traffic is curl with flags to force a protocol:

• curl -4 — force IPv4 only
• curl -6 — force IPv6 only
• curl -v — verbose mode, shows which address you actually connected to

By combining flags, you can precisely know which address the remote site sees. Send a request with -4 to a service that returns your IP, and you'll see the pure IPv4 exit. Send with -6, and you'll see IPv6 if available. This separates the influence of happy eyeballs and shows the real picture per protocol.

Test on an IPv6-only endpoint

An especially valuable trick is to reach a service available only over IPv6, with no A record at all. If such a connection establishes, you have guaranteed native IPv6 connectivity, not just translation. If the connection fails even with forced -6, then there is no real IPv6 exit, and all your IPv6 activity revolves around the NAT64 prefix.

Practical test scenario:

1. Run curl -6 on an IPv6-only endpoint — checks native IPv6 connectivity
2. Run curl -4 on an IP detection service — see the outgoing IPv4 via PLAT
3. Compare addresses — if the IPv6 exit is from the subscriber's subnet and the IPv4 exit is from the carrier's pool, then a full dual stack with 464XLAT is in effect.

How to detect the NAT64 prefix

To find out if your network uses NAT64, you can look at synthesized addresses. Request an AAAA record for a domain that definitely has no IPv6 and inspect the response. If it returns an address starting with 64:ff9b, that's a clear sign that DNS64 and NAT64 are active. Some systems have built-in mechanisms to detect the NAT64 prefix that do exactly this: query a known name and look at the structure of the response.

Diagnostics checklist

• ip -6 addr — is there a global IPv6?
• ip -4 addr — is there an IPv4, and is it a private CLAT address?
• ping -6 to a global node — does IPv6 connectivity work?
• curl -4 to an IP service — which IPv4 does the site see?
• curl -6 to an IPv6-only endpoint — is there native IPv6?
• AAAA query for an IPv4-only domain — is the 64:ff9b prefix visible?

Compatibility: Why the /64 Subnet Is Treated as One Client

We now move to a question of enormous practical importance for anyone working with multiple accounts. We're talking about how platforms treat IPv6 connections.

Why some platforms are less friendly to IPv6

Historically, many major platforms built their anti-fraud and reputation systems around IPv4. Accumulated databases, reputation scoring, rate limiting rules — all were tailored to 32-bit addresses. IPv6 came later, and not all systems adapted equally well.

There's also a structural reason. In IPv4, each address is a scarce resource, typically representing a single node or a node behind NAT. In IPv6, addresses are so abundant that a single client can easily change its address a thousand times an hour within its subnet. This breaks the familiar logic where address equals client identifier.

That's why platforms have developed a special approach to IPv6, and understanding it is critically important.

How the /64 subnet is interpreted

Remember what we said in the basics section: a carrier allocates an entire /64 subnet to each subscriber. That's a gigantic number of addresses for one device.

Smart reputation systems understand this. Instead of evaluating each individual IPv6 address, they aggregate the entire /64 subnet and treat it as a single identifier. The logic is simple: since the entire subnet belongs to one subscriber, it should be treated as one client.

This means that changing the IPv6 address within the same /64 does not create a new identifier for such platforms. You can shuffle the last bits of the address as much as you like, but from the platform's perspective, it's still the same client because the /64 prefix hasn't changed.

What this means for working with multiple accounts

From this comes an important practical takeaway. If you try to separate accounts over different IPv6 addresses within the same /64 subnet, for advanced platforms they will look like a single client. Different addresses don't give separation if the common prefix matches.

Compare this with the behavior of IPv4 through NAT64. The public IPv4 of the PLAT node is shared by many different subscribers of the carrier. From the platform's perspective, behind one IPv4 there are dozens of real people. That gives a completely different traffic mixing profile.

Key takeaways for multi-accounting:

• Changing the last bits of an IPv6 address within the same /64 does not change the identifier for smart platforms
• The meaningful unit for IPv6 is the /64 prefix, not the individual address
• Separation should happen at the level of different /64 subnets, not addresses within one
• IPv4 through NAT64 mixes you with other subscribers, giving a different reputation dynamic
• Always understand which protocol is actually used to connect to a specific platform

Practical recommendation for protocol control

Given all this, it makes sense to control which protocol your connection uses to the target platform. If you know you need an IPv4 exit via a mobile carrier, force IPv4 at the client level. Then you are guaranteed to get the shared public PLAT address, not a subnet tied to your device.

Common Mistakes When Working with IPv6 in Mobile Networks

Now let's gather the most widespread misconceptions and errors in one place. Study them carefully — each one can ruin your work or lead to wrong conclusions.

Mistake #1: Assuming an IPv6 address on the phone means an IPv6 exit

Many people see a global IPv6 on the interface and conclude that all traffic goes over IPv6. In reality, traffic to IPv4 sites is still converted to IPv4 at PLAT. The IPv6 on the device is transport within the carrier's network, not a guarantee of an IPv6 exit to any particular site.

Mistake #2: Confusing the outgoing address with the interface address

The address on the device's network interface and the address the site sees are different things. Between them stand CLAT and PLAT with translation and NAT. Never judge the outgoing address from what ip addr shows. Always check with a real external service.

Mistake #3: Panicking over jumping addresses on a checker

We already explained that happy eyeballs makes a dual-stack connection show IPv4 one time and IPv6 another. That's normal. Don't take it as a sign of a broken proxy. If you need stability, force the protocol.

Mistake #4: Thinking changing an IPv6 address within /64 gives a new identifier

This is one of the most expensive mistakes in multi-accounting. Smart platforms aggregate the entire /64. Changing the last bits of the address is pointless for separating accounts. The meaningful unit is the prefix.

Mistake #5: Ignoring the APN type

The APN type — IPv4, IPv6, or IPv4v6 — directly determines what will happen to the traffic. Without understanding which type is used, you're working blind. Always find out the session configuration.

Mistake #6: Testing connectivity with only one protocol

Testing only IPv4 or only IPv6 gives an incomplete picture. Real diagnostics require checking both protocols separately with -4 and -6 flags, as well as reaching an IPv6-only endpoint.

Mistake #7: Confusing the NAT64 prefix with a real IPv6 site

A synthesized address with the 64:ff9b prefix looks like IPv6, but behind it is an IPv4 server. If you connect over such an address, you're effectively going through NAT64 to an IPv4 server, not talking to a real IPv6 node. Don't draw conclusions about a site's native IPv6 support just from seeing a synthesized address.

Mistake #8: Thinking CLAT and PLAT are the same

CLAT lives on the device and performs stateless translation for apps. PLAT lives in the carrier's network and performs stateful translation with NAT. They are different components with different tasks. Confusing them prevents you from understanding where exactly the outgoing address is born.

Tools and Resources for Working with the Protocol Stack

Let's assemble an arsenal of tools that will help you diagnose and understand the network stack in a mobile environment. All of them are standard and don't require anything exotic.

Command line

• ip addr and its variants ip -4 addr, ip -6 addr — basic tools for viewing interface addresses
• ping and ping6 — test connectivity over a specific protocol
• curl with -4 and -6 flags — the main tool for diagnosing web connections and checking the outgoing address
• traceroute and traceroute6 — route tracing, helps see which nodes the traffic passes through
• dig and nslookup — DNS queries to check A and AAAA records, detect synthesized addresses
• ip route — view routing table for both protocols

Online checker services

• External IP detection services — show what the remote site sees
• IPv6-only test endpoints — check for native IPv6 connectivity
• Services that show IPv4 and IPv6 separately — help see the dual stack
• Tools to check a domain's IPv6 support — show if an AAAA record exists

DNS diagnostics

DNS queries help understand if DNS64 is in play. Request an AAAA record for a domain that has no IPv6 and look at the structure of the response. The presence of the 64:ff9b prefix reveals synthesis in action. This is the most direct way to verify the presence of a NAT64 mechanism in the network.

Systematic stack diagnostic framework

Here's a step-by-step framework to run when you first encounter any mobile network:

1. Inventory addresses. Run ip addr, identify the presence of a global IPv6 and the nature of IPv4
2. Identify CLAT. Find a virtual interface with a private IPv4 — this is a sign of 464XLAT
3. Check for NAT64. Request AAAA for an IPv4-only domain, look for the 64:ff9b prefix
4. Test native IPv6. curl -6 to an IPv6-only endpoint
5. Determine outgoing IPv4. curl -4 to an IP detection service
6. Determine outgoing IPv6. curl -6 to a service that supports IPv6
7. Analyze dual-stack behavior. Plain request without forced protocol, observe happy eyeballs

After completing all seven steps, you'll have a comprehensive picture: what type of connectivity the network has, whether translation is in place, what addresses different types of sites see, and how the dual stack behaves. That's your standard audit.

Case Studies and Results: Real Scenario Breakdowns

Abstract mechanics are best understood through concrete examples. Let's break down a few typical scenarios encountered in practice.

Case #1: A site logs one IPv4 for many clients

Situation. An analyst looks at site logs and notices that a huge number of distinct users with different behavior come from a single IPv4 address. First thought — it's a proxy or a botnet.

Analysis. In reality, this is a classic public IPv4 of a NAT64 or CGN node of a large mobile carrier. Behind such an address there really are dozens or hundreds of real subscribers. Their traffic exits through a single PLAT. That's not an anomaly; it's standard operation of 464XLAT in the face of IPv4 scarcity.

Conclusion. Judging mobile clients solely by their IPv4 address is ineffective. One address does not equal one user in a mobile environment. This very feature is what makes mobile IPv4 addresses so distinctive — a high density of real users behind a single address.

Case #2: Inconsistent responses from an IP checker

Situation. A mobile proxy operator complains that the IP checker shows IPv4 one time and IPv6 another, and concludes the proxy is unstable.

Analysis. The checker has both A and AAAA records. The client is in dual-stack mode. Each request triggers happy eyeballs, and depending on the race outcome, a different address type is returned. The proxy is working perfectly stable; only the protocol chosen by the algorithm changes.

Solution. Force the protocol using curl -4 or corresponding client settings. After fixing to IPv4, the address became predictable. The stability issue turned out to be imaginary.

Case #3: Accounts got linked despite different IPv6 addresses

Situation. Work with multiple accounts over IPv6, each account assigned a separate IPv6 address. Yet the platform links the accounts together.

Analysis. All assigned addresses were within the same /64 subnet allocated by the carrier to the device. The advanced reputation system aggregated the entire /64 and treated it as a single identifier. Different addresses within the same prefix provided no separation.

Conclusion. For IPv6, the meaningful unit is the /64 prefix, not the individual address. Separation requires different prefixes. In this case, it would have been wiser to work through the IPv4 NAT64 exit, where traffic mixes with other subscribers of the carrier.

Case #4: An app that doesn't support IPv6

Situation. An old app that directly reaches an IPv4 literal address should break on a pure IPv6 network. But it works.

Analysis. CLAT is running on the device. The app sends an IPv4 packet to the virtual interface; CLAT translates it to IPv6; the packet then goes through PLAT to the IPv4 internet. The app lives in the illusion of a full IPv4 environment and has no idea about the translation. This is exactly the task CLAT exists to solve.

Conclusion. 464XLAT provides transparent compatibility for legacy applications. That's why carriers' move to IPv6 didn't break the ecosystem of IPv4 software.

FAQ: Frequently Asked Questions

Why does my phone show IPv6, but the site logs capture IPv4?

Because the switch happens at the PLAT node in the carrier's network core. The device sends traffic over IPv6, but when it exits toward an IPv4 site, the NAT64 node translates the packet to IPv4 and substitutes the carrier's public address. The site sees exactly that outgoing IPv4, not the device's internal IPv6.

What is the 64:ff9b prefix and where does it come from?

This is the standardized well-known prefix for NAT64 translation. DNS64 uses it to synthesize artificial IPv6 addresses from the IPv4 addresses of sites without an AAAA record. The last 32 bits of such an address contain the real IPv4, which PLAT extracts during translation.

How is CLAT different from PLAT?

CLAT runs on the device and does stateless translation of IPv4 to IPv6 for apps that need IPv4. PLAT runs in the carrier's network and does stateful translation of IPv6 to IPv4 with NAT, substituting a public address. CLAT solves device compatibility; PLAT solves compatibility with the IPv4 internet.

Why does the IP checker show different addresses on refresh?

Because of the happy eyeballs algorithm in a dual-stack environment. If the checker is available on both IPv4 and IPv6, the client runs a connection race, and at different times different protocols win. This is normal behavior, not a bug. Force the protocol with a flag for a stable result.

How can I tell if I have real IPv6 exit and not just NAT64?

Reach an endpoint that is only available over IPv6 using the command curl -6. If the connection establishes, you have native IPv6 connectivity. If it fails even with forced -6, then there is no real IPv6 exit, and all IPv6 activity revolves around the synthesized NAT64 prefix.

Why doesn't changing the IPv6 address help separate accounts?

Because the carrier allocates a whole /64 subnet to the device, and advanced platforms aggregate this entire subnet as a single identifier. Changing the last bits of the address doesn't change the prefix, so from the platform's perspective it's still one client. The meaningful unit is the /64, not the individual address.

Why does a mobile proxy usually have an outgoing IPv4 instead of IPv6?

Because most target sites don't have IPv6 infrastructure, and traffic to them goes through NAT64. The PLAT node translates packets to IPv4 and assigns the carrier's public address. That address becomes the outgoing one. For sites with a real AAAA record, the proxy can connect directly over IPv6.

How can I force a client to use a specific protocol version?

At the curl level, use the -4 flag for IPv4 and -6 for IPv6. Many applications and libraries have similar protocol preference settings. You can also control it through system-level address policy priority settings. This turns off the non-determinism of happy eyeballs and gives a predictable exit.

What does the target site see when connecting through a mobile network?

If the site has only IPv4, it sees the carrier's public IPv4 address of the NAT64 node, shared by many subscribers. If the site has real IPv6, it sees an IPv6 address from the subscriber's allocated subnet. The device's internal addresses and the virtual CLAT address are never seen by the site.

Does the APN type affect which address the site sees?

Indirectly, yes. The APN type determines which protocols are available to the device. With IPv4v6 or pure IPv6 with CLAT, the entire described translation mechanism works. With a pure IPv4 APN, translation is not needed, but such a setup is rare among large carriers due to address scarcity.

Conclusion: The Main Things About IPv6 Mechanics in Mobile Networks

We've come a long way. We started with a puzzle — phone on IPv6, site sees IPv4 — and we've fully solved it. Let's solidify the key takeaways.

First and foremost. The shortage of IPv4 addresses forced carriers to switch to IPv6. Devices live in an IPv6 environment, often without any public IPv4 on the radio interface. Compatibility with the old IPv4 internet is provided by 464XLAT technology.

Second. 464XLAT consists of two translators. CLAT on the device turns app IPv4 traffic into IPv6. PLAT in the carrier's network turns IPv6 back into IPv4 and assigns a public address. It's at PLAT that the outgoing IPv4 address that the site sees is born.

Third. NAT64 and DNS64 work as a pair. DNS64 synthesizes IPv6 addresses from IPv4 for sites without AAAA records, using the 64:ff9b prefix. NAT64 in the form of PLAT delivers packets to these addresses to the real IPv4 servers. Together, they make the entire IPv4 internet accessible to a pure-IPv6 device.

Fourth. Dual stack and happy eyeballs explain why a checker displays one protocol and then another. The client runs a connection race and chooses the winner. For stability, force the protocol with -4 or -6 flags.

Fifth. For multi-accounting, it's critical to understand that a /64 subnet is perceived by smart platforms as one client. Changing the address within a single /64 is useless for separation. IPv4 through NAT64, on the other hand, mixes you with other subscribers of the carrier.

What are the next steps? Make it a habit to run a systematic stack diagnostic in any new mobile network using our seven-step framework. Master curl with -4 and -6 flags as your primary tool. Always check the outgoing address on a real external service, not from the device interface. And keep in mind the difference between where the device lives and where the traffic actually exits to the internet.

Understanding this mechanics transforms you from a user puzzled by jumping addresses into an engineer who knows exactly what happens to every packet. And knowledge, as they say, is control. Let this article be your go-to cheat sheet on IPv6 in mobile networks. Come back to it whenever you face another network mystery — and it will cease to be a mystery.