[v6ops] Fwd: 464XLAT Trial Deployment Report

[Fred Baker <[e-mail]>]

So - I have a question for the working group. We have a draft and a deployment report on

http://datatracker.ietf.org/doc/draft-mawatari-v6ops-464xlat
http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat
  "464XLAT: Combination of Stateful and Stateless Translation", Masataka
  Mawatari, Masanobu Kawashima, Cameron Byrne, 15-Jan-12

indicating that it is useful in a live network. It is, an rfcdiff will tell you, a rework of draft-mawatari-softwire-464xlat. The technique has similarities and differences from the concepts in the various dIVI drafts and

http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-cpe
http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe
  "NAT64 Operational Considerations", Gang Chen, 31-Oct-11

http://datatracker.ietf.org/doc/draft-sunq-v6ops-contents-transition
http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition
  "Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun,
  Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, Qin Zhao,
  29-Oct-11

The authors argue that this is about operational experience with a protocol translation technology defined in behave, and that it has current deployment.

I need to know what the working group, and especially the operators in it, wants to do with this. Do you want to adopt it as a working group draft? Do you want to discuss it but leave it individual? Do you think it belongs in another working group, and if so which? Do you have another opinion?


> From: Cameron Byrne <[e-mail]>
> Date: February 3, 2012 12:17:08 PM PST
> To: IPv6 Ops WG <[e-mail]>
> Subject: [v6ops] 464XLAT Trial Deployment Report
> 
> Hi,
> 
> 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
> service.
> 
> 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].
> 
> Thanks,
> 
> Cameron
> 
> 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
> https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc
> 
> [5]  http://goo.gl/W55YQ or http
> ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops