Summary

  • IPv4-as-a-Service does not remove IPv4 dependence. It relocates it into DNS synthesis, prefix discovery, customer-side translation, provider-side state and shared port allocation.
  • Native IPv6 can remain healthy while IPv4-only names, literals or long-lived translated sessions fail, so an ordinary availability probe cannot identify the broken control.
  • Operators need a dated, privacy-bounded receipt that joins resolver output, Pref64, CLAT path, PLAT state, failover, attribution and explicitly unsupported inbound cases.

A subscriber changes the resolver on a home gateway. IPv6-native services continue to work. A name with only an A record no longer produces a synthetic AAAA answer, and an IPv4-only destination disappears. On another device, the same destination still works because a customer-side translator accepts the IPv4 packet and discovers the provider’s translation prefix by another route. “The broadband is up” is true in both homes. It is also almost useless as a diagnosis.

That selective failure is the operating reality behind IPv4-as-a-Service, or IPv4aaS. An operator can make much of its access or core network IPv6-only and preserve access to the remaining IPv4 Internet through translation. The public IPv4 address is no longer assigned end to end to one subscriber. Compatibility is assembled from several controls owned by different systems.

A synthesized address is a promise about a path

RFC 6147 defines DNS64. If a client asks for an AAAA record and an IPv4-only service has only an A record, a DNS64 function can embed that IPv4 address in an IPv6 translation prefix, or Pref64::/n, and return a synthetic AAAA record. The client then sends an IPv6 packet towards that address.

The answer is useful only if the same prefix leads to a translator configured to decode it. DNS64 and the translator do not negotiate this state for every query. Their configuration has to correspond. A successful DNS response therefore proves that synthesis occurred, not that the next hop has capacity, owns the same prefix or can preserve the session.

DNSSEC makes the boundary sharper. Synthesis changes an answer, while DNSSEC is designed to detect unauthorized changes. Validation can work when the validating and synthesizing roles are placed deliberately, but “turn on DNS64” is not a complete policy. The receipt must say which resolver answered, where validation happened, which A and AAAA records were observed, and which prefix was used.

The CLAT decides which old assumptions survive

RFC 6877 describes 464XLAT. A stateless customer-side translator, the CLAT, turns IPv4 packets into IPv6 at the endpoint or customer edge. A stateful provider-side translator, the PLAT, turns them back into IPv4 for the destination. When an application uses a name and DNS64 is available, it may reach the PLAT through one stateful translation. When an application uses an IPv4 literal or an older IPv4-only API, the CLAT supplies the missing first step.

This is why resolver changes do not produce one universal symptom. RFC 8683 explains that a network with NAT64 but no CLAT may lose IPv4-only destinations when a user selects a foreign resolver that does not synthesize addresses. A 464XLAT client can often keep working without DNS64, but only if the CLAT can learn the correct translation prefix. A network-specific prefix paired with a resolver that synthesizes another prefix can still point traffic away from the intended PLAT.

The CLAT does not recreate every property of native IPv4. RFC 6877 limits the architecture to client-server communication towards globally addressed IPv4 servers. It is not by itself a general inbound-IPv4 or peer-to-peer product. An operator that advertises “IPv4 compatibility” without listing those limits has described a slogan rather than a service.

Prefix discovery has a lifecycle

The translation prefix need not be hard-coded. RFC 8781 defines a PREF64 option for IPv6 Router Advertisements. It carries the prefix length and a lifetime. A zero lifetime tells the host to stop using the prefix. Hosts should scope the value to the interface—and to the relevant Provisioning Domain where that model is supported. Routers should detect and log inconsistent PREF64 advertisements on the same link.

That turns discovery into an observable control. The useful question is not merely “Does the customer edge know a Pref64?” It is “How was this prefix learned, on which interface or provisioning domain, with what remaining lifetime, and did every router on the link advertise a consistent value?” A stale prefix can outlive the translator it was meant to reach; a short lifetime can expire before the next useful advertisement.

State makes failover a service claim

At the provider edge, RFC 6146 defines stateful NAT64. It maintains bindings and per-session state so return packets can find the originating IPv6 client. The RFC requires bounded handling of fragmented traffic to prevent resource exhaustion, but it does not magically make two translators share live sessions.

A standby NAT64 can be reachable and still drop existing flows after cutover. New connections may succeed immediately while a payment terminal, game session, tunnel or long download resets. Health checks that open only a fresh TCP connection will report a clean recovery. The operating claim therefore needs a controlled before-and-after session test, the active PLAT site, its state-capacity margin, the failover event and the recovery expectation for established mappings.

RFC 9099 adds the security boundary. Stateful translation can face state-exhaustion pressure; DNS64 interacts with DNSSEC; NAT64 interferes with most IPsec deployments unless UDP encapsulation is used. 464XLAT can run without DNS64 and avoid that particular synthesis issue, but it inherits the other translation concerns. IPv6-only transport is not a security exemption.

Address efficiency moves the accounting problem

RFC 9313 compares five IPv4aaS technologies. In 464XLAT, per-flow state and dynamic public-port allocation sit at the provider NAT64. That can use a shared IPv4 address efficiently because ports are assigned on demand. The price is centralized state, capacity planning and potentially substantial logging.

When many subscribers share one public address, attributing an observed address and port requires time-bounded mapping evidence. Logging every session maximizes detail and cost. Allocating a port block for longer periods reduces log volume and consumes the port pool less efficiently. The choice is partly technical and partly legal; the RFC does not establish one universal retention regime.

Operator-side state also changes what a subscriber can offer. Without a control such as PCP or an explicit mapping, the architecture does not by itself make a public inbound transport port available. That limit belongs in product language, support scripts and incident classification. Otherwise, a deliberate architectural boundary will arrive in the help desk as an unexplained defect.

The sources do not establish how many 2026 subscribers use any one transition mechanism, a universal performance improvement, or a typical failure rate. They establish the control chain and the choices. That is enough to define a testable service.

Sources

  1. RFC 6146 — Stateful NAT64
  2. RFC 6147 — DNS64
  3. RFC 6877 — 464XLAT
  4. RFC 8683 — NAT64/464XLAT deployment guidelines
  5. RFC 8781 — Discovering PREF64 in Router Advertisements
  6. RFC 9099 — Operational security considerations for IPv6 networks
  7. RFC 9313 — Pros and cons of IPv4aaS technologies