[v6ops] 464XLAT Trial Deployment Report

Cameron Byrne <cb.list6@gmail.com> Fri, 03 February 2012 20:17 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0573A11E8074 for <v6ops@ietfa.amsl.com>; Fri, 3 Feb 2012 12:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.715
X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vGAeya5k2isl for <v6ops@ietfa.amsl.com>; Fri, 3 Feb 2012 12:17:08 -0800 (PST)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 52B8F11E8071 for <v6ops@ietf.org>; Fri, 3 Feb 2012 12:17:08 -0800 (PST)
Received: by dakl33 with SMTP id l33so3616752dak.31 for <v6ops@ietf.org>; Fri, 03 Feb 2012 12:17:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=85CYPn+qJcKPvc7uH+TLYqtS9mzVnKjxzNayAVLoUAY=; b=fA4tapDgZc4JOJj/vTb2URIZUx52j542t/cND6VZ/B+KQHLEX2znJ8X345JnHd06ZZ 7dHkksc6TZ7KhW8tzBzbDfVKmSWwlw8V3HNzcTdDwWh0MXpbG1GEGRTb03StplN0gwDb mbMXS9mU7GoTbC7c44Sr8rF9iaumAD8e+sDX4=
MIME-Version: 1.0
Received: by with SMTP id om4mr20281313pbc.19.1328300228114; Fri, 03 Feb 2012 12:17:08 -0800 (PST)
Received: by with HTTP; Fri, 3 Feb 2012 12:17:08 -0800 (PST)
Date: Fri, 3 Feb 2012 12:17:08 -0800
Message-ID: <CAD6AjGSRUdx32arseR26RzHNtMri8Vrif3dCQmuk7B52GmoHAw@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [v6ops] 464XLAT Trial Deployment Report
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2012 20:17:09 -0000


I have recently concluded a simple initial experimental deployment
464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android
Nexus S phone.

The high level summary is that a sample of the top ~200 free Android
apps that use network services (ie not a calculator with no ads),
~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a
stock Android 4.0 (ICS) on a stock Nexus S phone.

When using custom 464XLAT code [3] on Android, 100% of  the ~15% of
apps that failed in the initial test now work. The 464XLAT CLAT code
on the Android allowed for IPv4 socket bindings and IPv4 referrals to
proceed on the IPv6-only network by doing RFC 6145 protocol
translation locally on the phone.  The tested application sample set
is at [4].

I believe this simple experiment running real code on a real network
shows the value of draft-mawatari-v6ops-464xlat for enabling network
operators to embrace IPv6-only networks as the going forward future of
access networks. 464XLAT, like NAT64/DNS64, is a bridge technology
that makes IPv6 deployment feasible without harming the customer
experience.  464XLAT, like DNS64/NAT64, is not used when apps and
service are IPv6 native.  Thus, as IPv6 deployment progresses across
the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of

I hope the problem statement that draft-mawatari-v6ops-464xlat
addresses is clear as it applies to this trial: 15% of applications
for this sample in the Android market require IPv4 addresses.

And, i hope the proposed applicability and usefulness of 464XLAT is
clear as it applies to this trial:  464XLAT allows for 100%
functionality of all applications in the sample and is only used when
IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...).

I do have 2 requests of  the group.  First, please read and comment on
draft-mawatari-v6ops-464xlat [1].  We are looking for working group
adoption of this draft since we believe it will broadly support the
ability of network operators to move forward with IPv6 in the near
term (code is running, network is deployed).  Right now, some networks
feel they are held back by "IPv6 spoilers" like Skype that require
IPv4.  But now, even Skype works on IPv6 with the help of 464XLAT :) .
 I would like to emphasize that Skype and others MUST still deploy and
support IPv6.  That said, we cannot let their failure hold the rest of
us back.  Second, the IPv4 exhaustion problem is real and now, the
urgency must be high.  Please also comment to the folks at Android
that this code should be brought into the Android main line
distribution because network operators (v6ops) need it to continue
growing the Internet and restoring the end-to-end principle [5].



ps.  Big thanks to Dan Drown for open-sourcing his CLAT code!

[1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat

[2] http://goo.gl/HGmsy or https://sites.google.com/site/tmoipv6/lg-mytouch

[3]  http://code.google.com/p/android-clat/ and
http://dan.drown.org/android/clat/  and

[4] http://goo.gl/z3j3q  or

[5]  http://goo.gl/W55YQ or http