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 11:29 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 9A65C1A87E0 for <v6ops@ietfa.amsl.com>; Mon, 16 Feb 2015 03:29:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.383
X-Spam-Level:
X-Spam-Status: No, score=-4.383 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, J_CHICKENPOX_62=0.6, 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 YqwXlcIp1zW6 for <v6ops@ietfa.amsl.com>; Mon, 16 Feb 2015 03:29:54 -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 389CC1A885C for <v6ops@ietf.org>; Mon, 16 Feb 2015 03:29:46 -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 t1GBTg58014913; Mon, 16 Feb 2015 12:29:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BE4C520851D; Mon, 16 Feb 2015 12:30:42 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AB640208509; Mon, 16 Feb 2015 12:30:42 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1GBRfnH017378; Mon, 16 Feb 2015 12:29:42 +0100
Message-ID: <54E1D42C.5040605@gmail.com>
Date: Mon, 16 Feb 2015 12:27:40 +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: Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com>, BOUCADAIR Mohamed IMT/OLN <mohamed.boucadair@orange.com>, "Heatley, Nick" <nick.heatley@ee.co.uk>
References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com> <787AE7BB302AE849A7480A190F8B93300490B969@OPEXCLILM23.corporate.adroot.infra.ftgroup> <A0BB7AD89EA705449C486BDB5FDCBC7B2851152A@OPE10MB06.tp.gk.corp.tepenet>
In-Reply-To: <A0BB7AD89EA705449C486BDB5FDCBC7B2851152A@OPE10MB06.tp.gk.corp.tepenet>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ljnp6SIAK3WEJ3Zv2hHJlf6u2qM>
Cc: "v6ops@ietf.org" <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 11:29:56 -0000

Le 16/02/2015 11:47, Kossut Tomasz - Hurt a écrit :
> Hi, IPv6-only + CLAT+NAT64(no dns64) is used in Orange Poland -
> somewhere~ 30% mobile users. You won't see this in worldwide IPv6
> stats {"No." of IPv6 users are measured form traffic -ipv4/ipv6 -
> typical mobile user (smartphone) generates up to 6 times lower
> traffic comparing to lines users..}
>
> Assuming our experience:
> 1. The best for mobile nowadays is CLAT+PLAT+DNS
> *One path for IPv4 traffic (always via CLAT)
> *ALG’s treated as NAT44
> *IPv4 literal & domain use same path
> *One path for IPv6 traffic (native IPv6)
> *Motivation for native IPv6 content
> *Application address family independent
> *65% - traffic from subscribers is native IPv6
> *Google Nexus, Sony,HTC, Samung,LG, WindowsPhone, supports CLAT.

Hi,

Thank you for the report. It is good to see how good consideration is
given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having
embraced the CLAT technology.

Is the network considering Machine-class devices (M2M)? For example
Sierra Wireless Airprime?

More than the typical smartphone users (yes, it represents already a
large market) is the LTE network considering connections from more
dedicated settings like: connected public transportation, home
electricity counters, electric vehicle charging stations, harbour
installations, connected roads?

These dedicated settings look up to wireless LTE access networks as good
hope to get on the Internet, especially in areas where land lines are
too expensive to deploy.

Alex

>
> Cheers,
> tk
>
>
> -----Original Message-----
> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
> Sent: Monday, February 16, 2015 7:43 AM
> To: Alexandru Petrescu; Heatley, Nick
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
>
> Hi Alex,
>
> Please see inline.
>
> Cheers,
> Med
>
> -----Message d'origine-----
> De : Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
> Envoyé : vendredi 13 février 2015 17:13
> À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN Cc : v6ops@ietf.org Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
>
> Le 13/02/2015 16:33, Heatley, Nick a écrit :
>>
>>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 14:35
>> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org
>> Subject: Re: [v6ops] I-D Action:
>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
>>
>> Le 13/02/2015 14:14, Heatley, Nick a écrit :
>>> Hi Alex, Yes, that is wrong. You can ping any IPv4 literal from a
>>> 464xlat device. My handset only has an IPv6 address + CLAT and I am
>>> pinging 8.8.8.8 :-))
>>
>> Ok, I see.  I didnt know CLAT-on-device was required when using
>> v6-only APNs.
>>
>> [Heatley, Nick] For service continuity with IPv4, on an IPv6-only
>> bearer use CLAT. A slightly pedantic note,  if you have a "dual stack
>> APN" but the device only requests IPv6 then the device will receive an
>> IPv6 bearer and requires CLAT. You will hear from Ross and me talking
>> about having a single APN supporting all modes, IPv4, IPv4v6 and IPv6
>> bearers. There may be business reasons for this, as well as avoiding
>> consumers having to change APNs.
>
> In my understanding 464xlat/clat are trials these days.
>
> [Med] No, it is in use in live networks, including within our Group.
>
>    They could be
> improved before going live.  If the 464xlat/clat happened elsewhere than on the user terminal (e.g. BAse Station) I think more of these terminals could be accommodated, more business.
>
> [Med] If all applications are AF-independent (including IPv4 referrals are not in use or address synthesis a la RFC6052 is supported), then CLAT can be avoided. Some operators want to adopt an IPv6-only connectivity mode but with a condition to provide the same level of service as IPv4; For those CLAT is even a must. It might happen that other operators can judge that the broken applications under an IPv6-only mode + NAT64 are not important; for those CLAT is not needed. These reasons, among others, are why we set the language to 'should'.
>
>> That means that the device vendors MUST implement CLAT in the
>> smartphones which connect to a v6-only APN.  It is a too strong
>> requirement.
>>
>> [Heatley, Nick] Today's reality is that operators cannot take devices
>> to IPv6-only mode of operation without CLAT. In the future will other
>> alternatives appear?
>
> Alternatives there are very many.
>
> E.g. 464lat/clat to run on an operator-controlled network device, not on end-user terminal.
>
> E.g. use a v4-APN and v6-in-v4 encapsulation on the end-user device.
>
> 3GPP also designed a DS-MIPv6, not sure whether you are aware of it.  It had the same goal of terminal on v6-only link.
>
> [Med] All those are no options in the mobile context. IPv6-only + NAT64 is the mode that is currently adopted by several operators.
>