Re: [v6ops] 464XLAT Trial Deployment Report

[Wojciech Dec <[e-mail]>]

Hi,

On 16 February 2012 07:47, Cameron Byrne <[e-mail]> wrote:

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

The draft contains rfc2119 text/type of requirements, that are specific to
this architecture specification. What this means, is that the draft is more
than a report on a trial/deployment/experiment.


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

xlat464 appears to selectively tailor nat64 use into a very specific case.
That's fine that for you that it's your case, but it shouldn't
automatically be the standards rule for all deployments, especially since
it appears eminently possible to have a common approach and actually quite
close.
On this note, I would like to ask, why do you think that such a common
approach is not desirable or relevant?



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

Ironically, that's what standardization is about. I'm not arguing that your
deployment model & solution be ignored, but I am arguing that it doesn't
need to create another splinter in the solution space. Past poor precedent
shouldn't necessarily be an excuse for more of it.


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

It's not quite the status quo. Most users in home broadband get an explicit
public IPv4 address from their SP.
The problem can be illustrated by this example:
- CLAT #1 has prefix 2001:db8:1::/64 and implicit address 192.168.0.1 for a
host. The CLAT address would be 2001:db8:1:<some random clat
stuff>:c0a8:0001
- CLAT #2 has prefix 2001:db8:2::/64 and implicit address 192.168.0.1 for a
host. The CLAT address would be 2001:db8:2:<some random clat
stuff>:c0a8:0001

There appears no way to have the above work in any practical sense with a
stateless NAT64 core.
The solution, in theory, would be to allow the CLAT to be configurable in
terms of the prefix it uses and the IPv4-in-IPv6 explicit addresses, eg
1.1.1.1, and 1.1.1.2 for each host. It would be fine except that the CLAT
spec does not allow this in practical terms since it casts a definition
around a /96 (the xlat464 address format in section 6.1). And, we know that
anything longer than a /64 doesn't work well for deployment in most SP
networks, esp 3gpp ones. Again the solution would be to allow to allow both
the prefix and addresses to be configurable, as required by an operator.


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

As I said, I think your work is valuable, worthwhile to document at least
in terms of experiment. In terms of running code, congrats and welcome, as
there's a bunch of it for the other solutions too.


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

It is core to the solution since without a consistent configuration method,
it won't work reliably (or at all). Again, this seems to be an area where a
common standard would be desirable.


> > 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 ?  :/
>

Well, it so happens that the NAT44 element would not be the likely culprit
for anything short of the 99% (judging by how the internet runs today). The
dual NAT64 aspect is something that both xlat464 and MAP-T utilize.

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

One could rather say that IPv4 resource coupling is a factor that varies
based on the type of deployment. One can see an XLAT464 PLAT function in
edge network devices.


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

Well, the thing is that if MAP solves your problem x, and along the way it
also solves other problems that are relevant, call it whatever you want,
but the process of getting it standardized is worth it, as opposed to the
point solution case.
There have been similar, perhaps less publicised results (and not specific
to Android) results for the other technologies too (presented at the
softwire intrim).

You called for the WG endorsement of a technical specification which IMO
carries both normative specification material and the results of your
experiments. I have no issue with documenting your results, or
endorsing/supporting the approach for that matter, but I also do think that
endorsing the specification part without wider consideration is premature.

Regards,
Woj.


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