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

[Cameron Byrne <[e-mail]>]

On Fri, Feb 3, 2012 at 2:37 PM, Behcet Sarikaya <[e-mail]> wrote:
> Hi Fred,
>
> I have technical concerns:
>
> - RFC 6146 does use DNS64 as an integral component. In this draft
> DNS64 is not used however RFC 6146 is referenced. I think that this
> point should be clarified instead of just giving a reference to 6146.
>

RFC6146 is stateful NAT64.  It does not require DNS64.  They are
completely decoupled.  RFC6146 can function fine without DNS64.
draft-mawatari-v6ops-464xlat can also function fine without DNS64, in
my particular implementation i choose to use DNS64 since it reduces a
layer of translation in most of *my* cases.

> - As you will remember, in 3GPP-IETF workshop in 2010, pnat proposal
> was discussed in depth. I think 464XLAT is very much like pnat. The
> workshop did not endorse such approaches because of UE modification
> requirement. Instead, dual stack network was endorsed.
>

PNAT, AFAIK, had an on-host DNS64 ENR function and specified ALGs.  It
was overall a bit more complicated, and eventually that work evolved
into the BIH work that has been approved as an RFC.   PNAT was also
standards track work, as where this draft is informational.  From my
perspective, the BIH work does not solve my stated problem scope since
it is only scoped for IPv4 applications communicating with IPv6-only
servers.

> - Since Release 8, 3GPP has adopted v4v6 or dual stack PDP Context
> which is not mentioned in the draft.
>

Why would there be a mention of that?  The scope here is IPv6-only
access networks, not dual-stack networks.  That said, there are very
few Release 8+ networks deployed globally. And, dual-stack faces the
challenge of provide IPv4 addresses that are no available.

> I do like the principle of IPv6-only network instead of the old
> fashioned dual stack network, if only we could resolve the technical
> issues :-).
>

Good on this point !

> I also like the observation that Skype should be IPv6 friendly.
>

That application would go a long way helping network operators deploy
IPv6 networks.

CB

> Regards,
>
> Behcet
>
> On Fri, Feb 3, 2012 at 2:40 PM, Fred Baker <[e-mail]> wrote:
>> 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
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops