Subject: [v6ops] draft-ietf-v6ops-464xlat WGLC

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 21 Aug 2012 15:45:20 +0000

This is to open a two week Working Group last Call on 

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
  "464XLAT: Combination of Stateful and Stateless Translation", Masataka
  Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12

Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 21 Aug 2012 18:41:19 +0000

I should note that the current thread has a subject line reading -06.txt, but the current version is -07.txt. You may find the diffs (fairly extensive) at

http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-07.txt

On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Tore Anderson <[email-masked]>
Date: Mon, 27 Aug 2012 09:31:57 +0200

* Fred Baker (fred)

> "464XLAT: Combination of Stateful and Stateless Translation",
> Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12
> 
> Please read it now. We are interested in, among other things,
> technical commentary on the draft and the working group's perception
> on its usefulness to its target audience.

I've voluntarily used IPv6+NAT64/DNS64 as my primary mobile data
connection for well over a year, and while most things work just fine,
there is a small, but significant, percentage of apps and services which
fails to function correctly. Because of these, I can fully understand
that deploying IPv6 as a default connectivity method to «ordinary» users
in current 3G networks is simply not feasible.

That said, there is a pressing need to get IPv6 more widely deployed,
perhaps especially in mobile networks. In my opinion, 464XLAT appears to
allow those problematic apps and services to function correctly on
IPv6-only mobile networks, thus making IPv6-only service a commercially
viable strategy for the operators. That, I feel, is extremely valuable,
and not to mention urgent.

As to the current bickering going on about ND-Proxy and IANA-reserved
IID...we need a bike shed like 464XLAT *now*, regardless of hue. It
doesn't even have to be perfect and able fit all weird sorts of
velocipedes, trikes and future inventions - after all, its function is
only to support a small and diminishing number of legacy apps and
services that cannot make use of native IPv6 themselves. It's a stop-gap
measure, not the future of mobile networking.

I therefore support this document wholeheartedly, and hope I'll get an
implementation of it delivered to my phone «over the air» in the near
future.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 Aug 2012 14:11:40 +0200

Hi,

On Mon, Aug 27, 2012 at 09:31:57AM +0200, Tore Anderson wrote:
> IID...we need a bike shed like 464XLAT *now*, regardless of hue. 

Amen.  Or "+1".

Gert Doering
        -- Operator.
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Teemu Savolainen <[email-masked]>
Date: Mon, 27 Aug 2012 15:53:04 +0300

Draft says (almost the same text in two places, here only once):

   The CLAT MAY discover the Pref64::/n of the PLAT via some method such
   as DHCPv6 option, TR-069, DNS APL RR [RFC3123] or
   [I-D.ietf-behave-nat64-discovery-heuristic].

The heuristic is on Standard Track at Behave WG, while RFC3123 is
experimental and for DHCPv6 option afaik there are no proposals on the
table. About TR-069 I have no idea if it touches this topic (reference
missing at least).

Furthermore, the
http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03 (RFC
Editor's queue) determined the heuristic as way to go, so should the text
in draft say instead something like this:

--
The CLAT MAY discover the Pref64::/n of the PLAT via
[I-D.ietf-behave-nat64-discovery-heuristic]. In the future some other
mechanisms, such as one using DNS APL RR [RFC3123] or a new DHCPv6 option,
will possibly be defined.
--

If you want for some reason list undefined options (I'd rather drop them
and just say):
--
The CLAT MAY discover the Pref64::/n of the PLAT via
[I-D.ietf-behave-nat64-discovery-heuristic].
--

?

Best regards,

Teemu

2012/8/21 Fred Baker (fred) <[email-masked]>

> Please read it now. We are interested in, among other things, technical
> commentary on the draft and the working group's perception on its
> usefulness to its target audience.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 28 Aug 2012 06:35:00 +0000

> in current 3G networks is simply not feasible.

The statement confuses me. You have run translated IPv6 for a year, and as a result believe that running native IPv6 is not feasible? Are you trying to say that you believe that running translation is not feasible for a certain set of applications?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Aug 2012 15:37:45 +0900

On Tue, Aug 28, 2012 at 3:35 PM, Fred Baker (fred) <[email-masked]> wrote:

> The statement confuses me. You have run translated IPv6 for a year, and as
> a result believe that running native IPv6 is not feasible? Are you trying
> to say that you believe that running translation is not feasible for a
> certain set of applications?

I think he means that deploying IPv6+NAT64 as the *only* connectivity
method to ordinary users is not feasible. Ordinarly users need to run
IPv4-only apps as well.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 28 Aug 2012 09:40:03 +0200

* Lorenzo Colitti

>> The statement confuses me. You have run translated IPv6 for a year,
>> and as a result believe that running native IPv6 is not feasible?

No, I've been running *native* IPv6, with translated access to *IPv4*
resources/services (using NAT64/DNS64).

>> Are you trying to say that you believe that running translation is
>>  not feasible for a certain set of applications?
> 
> I think he means that deploying IPv6+NAT64 as the *only*
> connectivity method to ordinary users is not feasible. Ordinarly
> users need to run IPv4-only apps as well.

Yes. *I* am sufficiently interested in IPv6 deployment and technology to
actually *want* to use it on my mobile phone, in spite of the fact that
it causes troubles for certain apps and services. When that happens, I
either simply opt not to use those apps or services, or I need to
manually change the APN configuration to use IPv4 PDP type every time I
want to use them.

It's an acceptable situation for me, but I would certainly not give a
phone that had to be operated in this way to, say, my mom. In fact, it
would greatly surprise me if any mobile operator would - and because of
this, IPv6 on current 3G networks is simply dead in the water, apart
from friendly user pilots/opt-in programmes. 464XLAT appears to be the
missing piece here, as it allows IPv6+NAT64 to function as well as IPv4
does from the end user perspective. We need that.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Aug 2012 10:28:27 +0200 (CEST)

> does from the end user perspective. We need that.

I concur.

As an operator, IPv6+NAT64+DNS64 is a no-go due to apps/programs not using 
dns and/or IPv6 APIs.

There needs to be a way for a program to call a IPv4 literal and this 
would properly get sent over the IPv6 only access and translated in the 
NAT64 gateway for IPv4 connectivity.

Not providing this means delaying IPv6 deployment until either all app 
menufacturers switch to DNS+IPv6API (will take time), or mobile phone 
networks (and handsets/dongles/routers) get v4v6 PDP context support (1-2 
years out at least).

464XLAT is a software feature that can hopefully be implemented with an 
existing device software update.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philipp Kern <[email-masked]>
Date: Tue, 28 Aug 2012 11:42:03 +0200

On Tue, Aug 28, 2012 at 10:28:27AM +0200, Mikael Abrahamsson wrote:
> As an operator, IPv6+NAT64+DNS64 is a no-go due to apps/programs not
> using dns and/or IPv6 APIs.
> 
> There needs to be a way for a program to call a IPv4 literal and
> this would properly get sent over the IPv6 only access and
> translated in the NAT64 gateway for IPv4 connectivity.

That's not confined to the mobile space, too. I wish Linux, for instance, could
be told the NAT64 prefix and transparently convert IPv4 access to IPv6 on the
client side. That would also solve the IPv4 literal embedding problem.

Kind regards
Philipp Kern

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Aug 2012 12:16:17 +0200 (CEST)

On Tue, 28 Aug 2012, Philipp Kern wrote:

> That's not confined to the mobile space, too. I wish Linux, for 
> instance, could be told the NAT64 prefix and transparently convert IPv4 
> access to IPv6 on the client side. That would also solve the IPv4 
> literal embedding problem.

Yes, 464XLAT is definitely applicable to Windows as well. There are a 
*lot* of software that doesn't work in the v6+NAT64/DNS64 scenario.