Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Alexandru Petrescu <alexandru.petrescu@gmail.com> Mon, 16 February 2015 10:56 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566071A87CD for <v6ops@ietfa.amsl.com>; Mon, 16 Feb 2015 02:56:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TTxW5Km8pAA for <v6ops@ietfa.amsl.com>; Mon, 16 Feb 2015 02:56:50 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83D51A87BC for <v6ops@ietf.org>; Mon, 16 Feb 2015 02:56:49 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1GAuft7002264; Mon, 16 Feb 2015 11:56:41 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C509E208365; Mon, 16 Feb 2015 11:57:41 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B761720832A; Mon, 16 Feb 2015 11:57:41 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GAsfmu006769; Mon, 16 Feb 2015 11:56:41 +0100
Message-ID: <54E1CC71.2010108@gmail.com>
Date: Mon, 16 Feb 2015 11:54:41 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Tore Anderson <tore@fud.no>
References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <5A769BF0-2A4C-4BA0-88DD-96D94514021D@eircom.net> <54DDEDB8.90001@gmail.com> <D90DE03A-E171-40CD-9C84-4B715229CEC2@eircom.net> <54E0F83F.3020403@gmail.com> <20150216112305.375cdf9b@envy.fud.no>
In-Reply-To: <20150216112305.375cdf9b@envy.fud.no>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/BSReLBrBswhCUF5UanSWo_zII3Y>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Feb 2015 10:56:52 -0000

Le 16/02/2015 11:23, Tore Anderson a écrit :
[...]
> 464XLAT exists entirely inside the customer's device.

What is the name of the software that must exist inside the customer's
device?

> In other words, the operator does not need to configure or provision
>  anything beyond Stateful NAT64 + DNS64 for 464XLAT to function.

But it seems to mandate "464XLAT" to exist inside the customer's device,
for IPv4-literals, and for non-DNS-based apps.

> Stateful NAT64 + DNS64 works just fine without 464XLAT as well, only
>  that IPv4 literals do not work, nor does applications that does not
>  use DNS or that hard-code the use of AF_INET network sockets.

Ok!

I think that an IPv4 access for which IPv4 literals dont work and where
apps MUST use DNS, is not really an IPv4 access.

> I think you've got this the wrong way around. 464XLAT was developed
> to make the IPv6-only APN type work well enough for the general
> populace.

Ok.

I also heard that 464XLAT was imported into the cellular world from DSL 
IPv6 deployments.

> At that point the IPV4V6 APN type didn't really work well enough
> because it was too new and poorly supported, while the IPV6 type is
> older and is well supported.

I can understand that.  The IPv4IPv6 access I used worked just fine for
my applications.  It was 3G+ only, not LTE, but it worked excellent.

> With the advent of LTE networks, this situation is changing.

I can understand that.  LTE networks bring in high bandwidth; but from
the networking point of view there is reason to fear regression (no
more publicly routable IPv4 addresses, no more ping 8.8.8.8, apps must
use DNS, etc).

> My own provider Telenor is now moving from
> IPV6+v4CGN(NAT64/DNS64)+464XLAT to IPV4V6+v4CGN(NAT44), for example.
>  I guess the biggest advantage of this latter approach is that it
> works with Apple devices.

I guess this move is promissing, thanks for mentioning it.

Using IPV4V6 may allow not only Apple devices but may enable more
devices beyond smartphones: machine-class devices and in general all
computers small or large which connect through a dedicated LTE USB key,
or smarter 4G modules.

Alex

>
> Tore
>
>