Re: [v6ops] 464XLAT Trial Deployment Report

[Xing Li <[e-mail]>]

Hi, Cameron,

> No, i disagree.  The MAP work seems to be a "design by committee" and
> the 464XLAT is more of a ground-up "solve for x", where x is whatever
> it takes to make IPv6-only networks have service parity with IPv4-only
> status quo networks.  And, it works today.  I sent the deployment
> report showing 100% service parity with IPv4 on Android phones, no one
> has challenged those results.

The MAP work has solid roots. For example, MAP-T is a new name of dIVI. 
The dIVI has been running at CERNET2 for more than two years and it has 
also been tested at China Telecoms network.  Some references are:

http://tools.ietf.org/html/draft-xli-behave-divi-04
http://tools.ietf.org/id/draft-sunq-v6ops-ivi-sp-02.txt

Regards,

xing

>
> In all honesty, i turned my own nose up at NAT46 on the handset at
> first.  I had the same perspective as James Woodyatt, those IPv4-only
> apps will get their just desserts....   But, then the folks on this
> board changed my mind  http://talk.maemo.org/showthread.php?t=60320
> They solved their own problems with NAT46 on the handset, and it
> worked.
>
> I can't argue with results and running code.
>
> CB
>
>> Regards,
>> Wojciech
>>
>>
>> On 3 February 2012 21:17, Cameron Byrne<[e-mail]>  wrote:
>>> 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
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>