Re: [v6ops] 464XLAT Trial Deployment Report

[Cameron Byrne <[e-mail]>]

Trying to understand your feedback more

On Wed, Feb 15, 2012 at 1:27 PM, Wojciech Dec <[e-mail]> wrote:
> Hi Cameron, All,
>
> I think that this work is very useful and am supporting that it be

Thanks.  It is hard to argue with a solution that solves a real
problem (15% app breakage in the Android market)

> documented at least as an experiment, however in its current form it does
> carry new normative text, and it also has a handful of technical items that

Please explain in detail about the new normative text and what this
means to the draft.

> deserve to be seen in the context of related work.
> In particular both xlat464 and MAP-T (softwires) architecture utilize
> stateless NAT64 on their CLAT/CE elements but differ in how it's allowed to

Why is this relevant?  MAP-T and 464XLAT both reference and use RFC6145. So... ?

> be configured. Both documents carry normative requirements for such
> functionality beyond the base RFCs. Avoiding incompatible architectures,
> while both being based on NAT64, would appear to be a reasonable goal to
> have for standardization.
>

Why is this desirable?  The solution space is already very crowded,
one more does not really change that.  We have documented a network
architecture that effectively does RFC 6145 at the CPE/UE and RFC6146
in the network.  Relative to other solutions, we believe this is
simple and deployable. In fact, it is already coded and deployed.
Running code means a lot in the IETF.

> In some more detail the main contrasts between the current MAP-T and xlat464
> drafts appear to be the following:
>
> 1. CLAT/CE compatibility with "core" NAT64 element
> Xlat464 appears to assume the use of implicit IPv4-in-IPv6 addressing for
> the CLAT's address, whereby the IPv4 address "part" would likely be the same
> across multiple CLATs, and correspond to some private IPv4 address. This
> would be sufficent to communication brokenness should such a CLAT be

I would not call this brokenness.  We have made this out of scope, and
it is in fact the same status quo that most home broadband users have
today with IPv4.  Most home broadband users have 192.168.0.x/24
overlapping space in their homes and they cannot communicate with each
other directly.  The same is true for 464XLAT IPv4 services.  We are
not looking to improve the IPv4 service, we are looking to replace it
with IPv6-only and provide service level parity.

We believe this has been achieved.  Once again, running code in place,
live network.

> deployed with a stateless NAT64 "core". Regular IPv6 hosts do not have such
> an issue, since they would not use such implicit addresses. Hence, while the
> xlat464 architecture is shown to be used in the context of a stateful NAT64
> "core" element (PLAT), its current specification would actually not allowing
> the use of a stateless NAT64 core elment with a CLAT device.
> In contrast, MAP-T architecture, and MAP-T CE while depicted in terms of a
> stateless NAT64 core element, is compatible with a stateful core NAT64
> element too.
>
> 2. NAT64 prefix configuration
> Both a MAP-T CE and xlat464 CLAT need to find the prefix of the core NAT64
> translator. The MAP-T envisaged achieving this by configuration (eg the
> MAP-T DHCPv6 option being specified), while xlat464 indicates that a NAT64
> prefix discovery "via some method" (not specified, likely DNS) will be used.
>

We reference a BEHAVE draft on how this can be achieved, but we leave
it open for other methods as well since it is not core to the
solution. Regarding DNS heuristics for Pref64 discovery, we have
running code for this function.

> 3. Embedded IPv4-in-IPv6 address assignment to CE/CLAT
> xlat464 does not appear to deal with a a determinate IPv4inIPv6 address to
> be assigned and presented to a CLAT device, or not running into some severe
> IPv6 addressing mode restrictions (eg 128 bit addressing not being supported
> by 3GPP) - a topic that MAP-T faced initially.
> With MAP-T a determinate, public or private, IPv4 address is allowed to be
> allocated and presented to a CE device as part of its IPv6 prefix (eg /64)
> assignment and algorithm MAP address derivation.
>

I am not sure what you are talking about above.  We do not have any
requirements for determinate IPv4 addressing in 464XLAT.

> 4. The CLAT/CE NAT44 functionality and subtended IPv4 hosts.
> The xlat464 CLAT assumes no NAT44. Any subtended IPv4 host/address are
> mapped statelessly to individual IPv6 address within the CLAT's /96 prefix.
> With MAP-T a CE is taken to have a NAT44 component, and this multiplexes
> any/all subtended private IPv4 hosts behind the MAP derived IPv4 address
> which is then statelessly mapped to an IPv6 prefix.

So  MAP-T does NAT44 -> NAT46 -> NAT64 ?  3x NAT in all IPv4 server
cases? ..... so 99% of websites will run through that ?  :/

The 464XLAT architecture with DNS64 is 1 NAT in most cases (99% of the
web...ie nearly everything without an IPv4 literal / referral ).  It
is 2 NATs at most NAT46 <-> NAT64 in the case of IPv4 only
applications or hosts (Xbox?).  And of course, IPv6 native end to end
for all native flows.

> Disabling NAT44 on a MAP-T CE, would appear to be sufficient to allow a
> MAP-T CE to be used in an xlat464 mode.
>
> 5. Mesh vs hub-spoke communication modes
> xlat464 allows only hub-spoke communication between CLAT and the core PLAT.
> In MAP-T, both hub&spoke and mesh mode are allowed, with the latter being an
> optional extension/optimization enabled by specific additional configuration
> of the CE.
>

I am not sure how that would work in a real network or why it is
desirable.  Probably off topic.

That said, the DNS Pref64/n discovery is dynamic. This is a feature i
use for geo-redundancy and may also be used for load sharing.... it is
similar to mesh, but that is not a stated goal of the draft.

One could say that MAP-T keeps the IPv4 resource tightly coupled with
the edge network while 464XLAT allows them to be loosely coupled.

> Thus,in terms of specification, between xlat464 and MAP-T there appears to
> be a decent case for a converged stateless NAT64 mode of
> operation/configuration of CLAT/CE elements, allowing their use across both
> architectures. This would effectively make the type of "core" NAT to become
> a deployment choice, rather than a rule linked to the client devices.
>

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.

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
>
>