464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network

Problem Statement

As noted in draft-arkko-ipv6-only-experienceIPv6-only networks, even with NAT64 / DNS64, cannot meet service level parity with traditional IPv4-only networks. Some applications and services just fail to work correctly over IPv6.  IPv4 is required because of poor programming practices that referencing IPv4 specific networking APIs instead of address family agnostic APIs, signaling IPv4 literals, or failing to use DNS FQDN names instead of IPv4 literals does.  All of the above failure scenarios are preventable and will need to be resolved for applications to thrive in the new Internet reality where there are IPv4-only, IPv6-only, and dual-stack clients.

One survey of IPv6 readiness in the Android Market showed approximately 85% of applications being IPv6-capable, while approximately 15% failed to work on an IPv6-only networks.  The data is here.  Most of applications that failed are in the peer-to-peer communications space (Skype, Google Hangouts, Tango, ...).

464XLAT Background

T-Mobile USA has been supporting a beta implementation of IPv6 GSM and UMTS service for over 2 years now.  Trying to solve some limitations in the IPv6-only experience, some technically minded IPv6 early adopters began experimenting with translating IPv4 to IPv6 locally on the N900 handset.  This allowed various application to function properly on an IPv6-only networks that would otherwise require IPv4.  This same idea and code has now been ported to Android and submitted to the Android Open Source Project.  At the same time in Japan, JPIX and NEC have been working on the same solution of IPv6-only access network with shared IPv4 addresses in the core.

464XLAT As Proposed Solution

RFC 6877 is now published!

   This document describes an architecture (464XLAT) for providing
   limited IPv4 connectivity across an IPv6-only network by combining
   existing and well-known stateful protocol translation RFC 6146 in the
   core and stateless protocol translation RFC 6145 at the edge. 464XLAT
   is a simple and scalable technique to quickly deploy limited IPv4
   access service to mobile and wireline IPv6-only edge networks without

Diagram By Dan Drown

The above diagram by Dan Drown

Proof of Concept

The purpose of this section is to provide enough information so that various network operators can reproduce, test, and deploy 464XLAT

Android + CLAT on a UMTS IPv6-only network with DNS64/NAT64

  1. The mobile handset is a Nexus S phone running the CLAT software
    • The CLAT software discovers the Pref64 using draft-ietf-behave-nat64-discovery-heuristic
    • The mobile network provides the WAN interface of the handset with an /64 size IPv6 address, /96 of this space used for mapping to IPv4 addresses
    • The CLAT interface provides the required route and IPv4 OS level interface for IPv4-only applications to properly function
  2. The mobile network used is the T-Mobile USA IPv6 Beta
    • The network is compliant with 3GPP Release 7 and allows for the establishment of IPv6 PDP
    • The network has stateful NAT64 and DNS64 services available, the provided DNS server is DNS64 enabled.
    • For NAT64, network specific prefix is used for traffic engineering reasons.  The well known prefix is not used.
    • No changes were required to the existing T-Mobile USA IPv6-only + NAT64/DNS64 to support the 464XLAT architecture.  The stateless RFC6145 translation on the handset was the only modification needed.
  3. Outcomes
    • On test-ipv6.com, the handset scores 10/10 for IPv4 and 10/10 for IPv6 connectivity, previously the score was 7/10 for IPv4 since IPv4 literal connections failed.
    • Skype, Netflix, and other applications that were otherwise broken on an IPv6-only network now function properly.  Note column H in the data
  • rmnet0 interface is IPv6-only and CLAT interface has IPv4 and IPv6

  • CLAT on the device allows for 10/10 scores for both IPv4 and IPv6 on test-ipv6.com 

  • Skype makes a successful call, signalling of IPv4 addresses works since the application can bind to the CLAT IPv4 address

Skype over IPv6-only with 464XLAT

  • Google Talk Video Chat works correctly despite signalling IPv4 literals, the CLAT interface allows this application when it would otherwise be broken on IPv6-only

Google Talk Video

  • Netflix logs in and plays video correctly

Netflix Streaming

Cisco ASR 1000 as CLAT and LITNET public implementation of Linux NAT64 and BIND DNS64 as PLAT

  1. Cisco ASR 1000 CLAT configuration here 
    • CLAT has IPv4-only network with 1 Windows 7 PC on it (other scenarios also described below for dual-stack and using DNS64)
    • CLAT is configured to forward all IPv4 traffic to the LITNET NAT64, there was no coordination with LITNET to support this test.
    • CLAT passes all IPv6 traffic withtout any modification.
    • All IPv4 traffic from G0/0/0 (IPv4-only LAN)  is RFC6145 translated as it is routed to G0/0/3 (IPv6-only WAN)
  2. Details of the LITNET PLAT are here
  3. Outcomes
    • The dual-stack windows PC with 464XLAT and IPv6-only WAN scores 10/10 for both IPv4 and IPv6 test-ipv6.com
    • Normal IPv4 web browsing works correctly
    • DNS request can be made from IPv4-only host to any arbitrary public DNS server such as
    • When a dual-stack host is used, it may use the DNS64 to minimize translation on the CLAT since the dual-stack host will always receive AAAA answers for DNS queries.

  • NOT 464XLAT Case: IPv6-only host, IPv6-only WAN, using LITNET NAT64/DNS64, no CLAT

  • IPv6-only Windows 7 PC with LITNET DNS64 configured as the DNS server

  • IPv6-only PC cannot reach IPv4 literals, while other tests that use DNS will succeed.

  • 464XLAT Case: Dual-stack host, IPv6-only WAN, using LITNET NAT64/DNS64 + ASR 1000 as CLAT

  • 10/10 for both IPv4 and IPv6 is achieved by allowing the host to send IPv4 packets to the CLAT to be translated to IPv6 in the 464XLAT model.  In this way, IPv4 literal and IPv4-only applications can be supported across an IPv6-only network.

  • 464XLAT Case: IPv4-only host, IPv6-only WAN, using LITNET NAT64, DNS,  and ASR 1000 as CLAT

  • This use case shows how an IPv4-only host may reach IPv4-only destination across an IPv6-only WAN

Next Steps

  1. Android CLAT code accepted and available on commercial Android devices
  2. More sharing of lessons learned and best practices
  3. 464XLAT is no longer needed because the applications now function on IPv6 !


Q: Why did you make this web page?
A: To demonstrate that 464XLAT is a useful architecture with running code.  It is also intended to help guide network operators begin their own research, testing, and deployment of 464XLAT.

Q: All of the above test were done with IPv6-only access network ?
A: Yes, 464XLAT is about scaling better with IPv6-only edge networks.

Q: All of the above test demonstrate how 464XLAT allows the edge network to grow without being tighly coupled IPv4 resources, since IPv4 is all shared on the stateful NAT PLAT?
A: Yes, 464XLAT allows for very efficient stateful sharing of limited IPv4 resources.

Q:  Is there a way to demonstrate this only using free and open source code?
A:  A:  Yes, there are free PLAT (Linux NAT64, OpenBSD PF, Ecdysis ....) and CLAT ( Android , Vyatta/ASAMAP -- configuration, CLATd for Linux)

Q:  My organization does not like open source, can this be done with commercial gear?
A:  Yes, there are several NAT64 PLAT platforms from:  Cisco, Juniper, Brocade, A10 and others.  You can also use the ASR 1000 as CLAT using stateless translation (demonstrated above)

Q:  Can i try 464XLAT on the T-Mobile USA network?
A:  Yes, T-Mobile provides a beta IPv6 service today that includes NAT64/DNS64.  If you attach to the T-Mobile USA network with a CLAT enabled Android phone, you will be doing 464XLAT.

Q:  Where can i get more information or suggest something about 464XLAT?
A:  A good starting point is the 464XLAT IETF RFC 6877,