Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 18 February 2015 12:57 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 5F6461A87EE for <v6ops@ietfa.amsl.com>; Wed, 18 Feb 2015 04:57:26 -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 7Rca_hi8BYM8 for <v6ops@ietfa.amsl.com>; Wed, 18 Feb 2015 04:57:23 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454AE1A8827 for <v6ops@ietf.org>; Wed, 18 Feb 2015 04:57:21 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1ICvIGJ008836; Wed, 18 Feb 2015 13:57:18 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EF47D201D06; Wed, 18 Feb 2015 13:58:21 +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 DC090201B9C; Wed, 18 Feb 2015 13:58:21 +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 t1ICvI3g018367; Wed, 18 Feb 2015 13:57:18 +0100
Message-ID: <54E48C2E.2020703@gmail.com>
Date: Wed, 18 Feb 2015 13:57:18 +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> <54E1D42C.5040605@gmail.com> <A0BB7AD89EA705449C486BDB5FDCBC7B28511B64@OPE10MB06.tp.gk.corp.tepenet>
In-Reply-To: <A0BB7AD89EA705449C486BDB5FDCBC7B28511B64@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/WhIePhNKGqMdXJgOatc9rAZJlwI>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD
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: Wed, 18 Feb 2015 12:57:26 -0000

Hi,

Le 18/02/2015 12:13, Kossut Tomasz - Hurt a écrit :
> Hi,
>
> Inline comments:
>
> 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.
>
> (tk) - this is not only CLAT, (CLAT is in generic Android thanks to
> Lorenzo, Cameron, Dan & others) each vendor has its own
> customization based on MCCMNC/region to control "features" per
> operator. In our case we have :  dedicated clatd.conf (not generic
> one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS)

It's good to see these mentioned.

For tethering - is the network offering DHCPv6 Prefix Delegation
service?  Or is the device performing '64share' RFC7278?

There are some advantages on doing the former rather than the latter.

> EIT bit =1,

What is the EIT bit?

Alex

>
> Cheers, tk
>
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:alexandru.petrescu@gmail.com] Sent: Monday, February 16,
> 2015 12:28 PM To: Kossut Tomasz - Hurt; BOUCADAIR Mohamed IMT/OLN;
> Heatley, Nick Cc: v6ops@ietf.org; Czerwonka Michał 1 - Hurt Subject:
> Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt
> - C_REC#9 464XLAT
>
> 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.
>>
>
>