Subject: [v6ops] 464XLAT Trial Deployment Report

From: Cameron Byrne <[email-masked]>
Date: Fri, 3 Feb 2012 12:17:08 -0800

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/

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Feb 2012 12:40:16 -0800

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 <[email-masked]>
> Date: February 3, 2012 12:17:08 PM PST
> To: IPv6 Ops WG <[email-masked]>
> Subject: [v6ops] 464XLAT Trial Deployment Report
> 
> Hi,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 03 Feb 2012 21:49:24 +0100

On 2012-02-03 21:40 , Fred Baker wrote:
[..]
> 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?

I very much appreciate the folks writing these operational reports.

I do not think they fit in the RFC process, though they are great for
discussing pro's and con's about a certain solution. IMHO They are much
better fit for the various conferences out there.

Greets,
 Jeroen

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 3 Feb 2012 14:58:54 -0600

Hi Cameron,

As you know, many UEs can not connect to an UMTS network on IPv6 due
to the firmware problem.

How did this affect your experiments?

Cheers,

Behcet

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Feb 2012 06:04:07 +0900

> discussing pro's and con's about a certain solution. IMHO They are
> much better fit for the various conferences out there.

excuse!  for many kinds of protocols, i-ds/rfcs of operability and
interoperability are a required part of the ietf process.

randy

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 03 Feb 2012 22:21:21 +0100

> interoperability are a required part of the ietf process.

If reports are indeed solely published in IETF-form then that is a good
way, if they though are published through other means then those can
serve already as stable references. Thus either/or IMHO.

Greets,
 Jeroen

---

From: james woodyatt <[email-masked]>
Date: Fri, 03 Feb 2012 13:30:56 -0800

On Feb 3, 2012, at 12:17 , Cameron Byrne wrote:
>  Right now, some networks feel they are held back by "IPv6 spoilers" like Skype that require IPv4. [...]

Who knew networks could be so touchy-feely and civilized?  Me, I'm more of a barbarian.

"Conan, what is best in life?"
"To break obsolete IPv4-only applications, to see the revenues of their developers crushed, and to hear the lamentations of their abandoned users."
"Ah, yes... that is best."

But no, I don't think this should be a working group draft.  It might be worthy of publication by the individual track, but it would be a waste of valuable WG agenda slots.

> Please also comment to the folks at Android that this code should be brought into the Android main line distribution

Yes.  Please please please add 464XLAT to the Android main line distribution.  I will shout with joy if they do that.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 3 Feb 2012 13:53:03 -0800

On Feb 3, 2012 12:58 PM, "Behcet Sarikaya"
<sarikaya2012@<[email-masked]>
> As you know, many UEs can not connect to an UMTS network on IPv6 due

Absolutely

> How did this affect your experiments?

The goal was to test the ability of 464XLAT architecture to enable 100%
functionality of Android applications on an IPv6-only network

That goal was achieved on the Nexus S hardware, which is 1 of the 4 phones
that are capable of doing IPv6 on the T-Mobile USA UMTS network.  We
believe the pipeline of IPv6 phones is improving, we continue to push the
OEMs to support IPv6.

We are happy that the Nexus S has been enabled with IPv6 since the Nexus
line of phones are the official baseline developer phones for Android, and
so we are hopeful that the code can be pushed upstream without much
modification.

CB

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 3 Feb 2012 16:37:30 -0600

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.

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

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

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

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

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 3 Feb 2012 14:54:59 -0800

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

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

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

> fashioned dual stack network, if only we could resolve the technical

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 3 Feb 2012 17:18:00 -0600

> layer of translation in most of *my* cases.

My point was to ask you to add at least one paragraph explaining how
DNS64 is avoided.

> it is only scoped for IPv4 applications communicating with IPv6-only

I know the pnat story.

> challenge of provide IPv4 addresses that are no available.

Because in Section 3 you have this:

This is especially cost-effective in wireless 3GPP
       network that would otherwise require two separate PDP connections
       to support IPv4 and IPv6.

Regards,

Behcet

---

From: MAWATARI Masataka <[email-masked]>
Date: Mon, 06 Feb 2012 12:01:17 +0900

Dear James-san,

I appreciate your comments.

* On Fri, 03 Feb 2012 13:30:56 -0800

> But no, I don't think this should be a working group draft.  It might be worthy of publication by the individual track, but it would be a waste of valuable WG agenda slots.

We would like to enough provide information about how to use widely
implemented NAT64 feature (RFC 6146) as a PLAT other than using for
NAT64/DNS64 to operators (of course, you can adopt both ways at the
same time), so we hope that this 464XLAT is adopted as a working group
draft.

And it based on effective and reasonable IPv6 deployment and IPv4
address exhaustion issue, especially for ISPs and mobile operators
that does not have much IPv4 address pool.

> Yes.  Please please please add 464XLAT to the Android main line distribution.  I will shout with joy if they do that.

I also hope that 464XLAT is official implemented to android. :)

Kind Regards,
Masataka MAWATARI

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Feb 2012 16:53:45 +0900

On Sat, Feb 4, 2012 at 05:40, Fred Baker <[email-masked]> wrote:

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

Speaking as an Android developer, I think this is useful. Many GSM / UMTS
networks do not and will not support the IPV4V6 PDP type required for
dual-stack access, and running IPv4 and IPv6 on separate PDP contexts is
brittle and has scaling issues.

It would be nice if there was a WG draft aiming to take this to standards
track in addition to an implementation. As to which WG it belongs in, I
don't know.

---

From: Congxiao Bao <[email-masked]>
Date: Mon, 6 Feb 2012 23:46:29 +0800

Hi
I think 464 XLAT can work for the cases where scalability and user tracking
ability are not so critical, since it uses stateful XLAT in Core and
stateless XLAT in CPE, not stateless double translation for both Core and
CPE.

I support it adopted by WG as an experimental document.
Congxiao
2012/2/6 Lorenzo Colitti <[email-masked]>

>> 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: Victor Kuarsingh <[email-masked]>
Date: Mon, 06 Feb 2012 17:02:46 +0100

From:  Congxiao Bao <[email-masked]>

> I think 464 XLAT can work for the cases where scalability and user tracking
ability are not so critical, since it uses stateful XLAT in Core and stateless
XLAT in > > CPE, not stateless double translation for both Core and CPE.
 
> support it adopted by WG as an experimental document.
>Congxiao

+1.  I  agree this work has value.

Regards,

Victor K

---

From: james woodyatt <[email-masked]>
Date: Mon, 06 Feb 2012 10:33:17 -0800

On Feb 5, 2012, at 23:53 , Lorenzo Colitti wrote:
> 
> As to which WG it belongs in, I don't know.

I would say that if there is a WG where this belongs, then it would be BEHAVE and not V6OPS.  I fail to see why this needs a working group to develop any further.  Wouldn't the individual submission track be more appropriate?

--
j h woodyatt <[email-masked]>

---

From: "t.petch" <[email-masked]>
Date: Tue, 7 Feb 2012 10:23:02 +0100

----- Original Message -----
From: "james woodyatt" <[email-masked]>
To: "Lorenzo Colitti" <[email-masked]>
Cc: "v6ops v6ops WG" <[email-masked]>
Sent: Monday, February 06, 2012 7:33 PM
> I would say that if there is a WG where this belongs, then it would be BEHAVE
and not V6OPS.  I fail to see why this needs a working group to develop any
further.  Wouldn't the individual submission track be more appropriate?

When I have suggested an individual submission, I get told that it costs the
IETF more, that is that the necessary evils of publishing are amortised across a
wider spectrum of people when a WG is involved, so unless an AD is really
burning with desire to support an individual submission, then a WG is the way to
go.

V6OPS or BEHAVE?  I see the latter as more limited, more focussed in scope, so
would go for V6OPS.

Is it worth publishing as an RFC?  Yes, the IETF traditionally neglects
operators, favouring 'manufacturers' so this would help redress the balance.

Tom Petch

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Feb 2012 05:48:21 -0800

> burning with desire to support an individual submission, then a WG is the way to

You haven't heard that from me. I think that a WG is the preferred approach because you are likely to get better review and discussion, but the cost issues are largely a wash.

> V6OPS or BEHAVE?  I see the latter as more limited, more focussed in scope, so

The real question there is one of charter. Behave's charter (http://datatracker.ietf.org/wg/behave/charter/), which is written in incomplete sentences and has some important bits presumed rather than stated, is about the development of translation technologies - IPv4/IPv4 and IPv4/IPv6, in four scenarios. It is supposed to interact with v6ops on requirements and operational matters. V6ops' charter (http://datatracker.ietf.org/wg/v6ops/charter/), among other things, calls for us to "Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks.". By that rubric, v6ops is an obvious place it might go. One could also imagine opsawg or opsec under one rubric or another.

If it's going to be discussed, I'm personally happy to have it discussed here. I have, however, gotten a lot of commentary from the operators about documents coming into v6ops that they don't want to discuss. Hence, my question is whether the operators what to discuss it, and whether they specifically want to discuss it here.

> operators, favouring 'manufacturers' so this would help redress the balance.

Urban legend. This falls right in there with "operators don't get involved in the IETF". Hi. Welcome to the IETF. You're an operator, and you are participating in a discussion that is largely among operators within the IETF.

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Feb 2012 09:27:39 +0100

> further.  Wouldn't the individual submission track be more appropriate?

+1 

> operators, favouring 'manufacturers' so this would help redress the balance.

As individual submission and experimental, yes.
For anything else, Softwire would be the place  (the overlap with stateless solutions studied there is obvious).

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Feb 2012 09:28:31 +0100

Le 2012-02-03 à 22:53, Cameron Byrne a écrit :
> On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" <[email-masked]> wrote:
> 
...
> > As you know, many UEs can not connect to an UMTS network on IPv6 due
Consequence: 6rd would be very useful to permit rapid IPv6-service availability in mobile networks.
(AFAIK it is technically trivial, but does need the will to do it.)

Something missing?

Regards,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 9 Feb 2012 03:59:44 -0600

> (AFAIK it is technically trivial, but does need the will to do it.)

Maybe so (although many people doubt it). The point in draft-mawatari
is IPv6-only network, in 6rd that is not the case.

This effort needs some encouragement from the community, let's do so :-).

Cheers,

Behcet

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Feb 2012 11:06:18 +0100

> is IPv6-only network, in 6rd that is not the case.

Indeed different problems have different solutions.
But my point is only about IPv6 Rapid Deployment, without being blocked by lack of knowledge or lack of will.

Where the firmware is hard to change (an only there) IPv6 can very easily be offered. 
The advice is then "just do it, it's so easy".
Nothing more.

Cheers,
RD
,

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 9 Feb 2012 05:33:15 -0800

> (AFAIK it is technically trivial, but does need the will to do it.)

Yes, mobile operator network operator  support is missing

Cb

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 10 Feb 2012 10:31:22 -0600

I support this as a WG document.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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
> 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
> 
> 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?
> 
> 
> > [2] http://goo.gl/HGmsy or
https://sites.google.com/site/tmoipv6/lg-mytouch
> > [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/

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 15 Feb 2012 22:27:46 +0100

Hi Cameron, All,

I think that this work is very useful and am supporting that it be
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
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
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.

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

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.

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

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.

Regards,
Wojciech

On 3 February 2012 21:17, Cameron Byrne <[email-masked]> wrote:

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

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 15 Feb 2012 22:47:00 -0800

Trying to understand your feedback more

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

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

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

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

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

> IPv6 addressing mode restrictions (eg 128 bit addressing not being supported
> by 3GPP) - a topic that MAP-T faced initially.

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

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

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

> 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

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 16 Feb 2012 10:34:37 +0100

Hi,

> Please explain in detail about the new normative text and what this

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.

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

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?

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

> same

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,

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.

> the

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.

> supported

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

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