Re: [v6ops] Fwd: 464XLAT Trial Deployment Report

["Rajiv Asati (rajiva)" <[e-mail]>]

I support this as a WG document.

Cheers,
Rajiv

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Fred Baker (fred)
> Sent: Friday, February 03, 2012 3:40 PM
> To: v6ops v6ops WG
> Subject: [v6ops] Fwd: 464XLAT Trial Deployment Report
> 
> 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=0AnVbRg3DotzFdGVwZWlWeG5
> wXzVMcG5qczZEZloxWGc
> >
> > [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
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops