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

<mohamed.boucadair@orange.com> Fri, 13 February 2015 13:00 UTC

Return-Path: <mohamed.boucadair@orange.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 D66B61A7013 for <v6ops@ietfa.amsl.com>; Fri, 13 Feb 2015 05:00:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 OMo_YNq3LIPI for <v6ops@ietfa.amsl.com>; Fri, 13 Feb 2015 05:00:45 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC7B1A1B27 for <v6ops@ietf.org>; Fri, 13 Feb 2015 05:00:38 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DA00722C75E; Fri, 13 Feb 2015 14:00:36 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B81994C125; Fri, 13 Feb 2015 14:00:36 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 14:00:36 +0100
From: mohamed.boucadair@orange.com
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
Thread-Index: AQHQR4ubH0P8VsyAQ0msn8bBnn4Z5ZzuiLAg
Date: Fri, 13 Feb 2015 13:00:36 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300490ACC7@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54DDF305.8080401@gmail.com>
In-Reply-To: <54DDF305.8080401@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.13.120922
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/oEhsHpmZXqGfpIRHdSJ4Q7CDZPg>
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: Fri, 13 Feb 2015 13:00:49 -0000

Re-,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] 
Envoyé : vendredi 13 février 2015 13:50
À : 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 07:49, mohamed.boucadair@orange.com a écrit :
> Hi Alex,
>
> The intent of this reco is to address broken IPv4-only applications
> over an IPv6-only connectivity.

Ok, makes sense.

> Ideally applications running on the device should be AF-independent.

That is an ideal, laudable goal.

There a number of professional applications that are Address Family 
dependent, and which do not query DNS to find an address.  They may 
distribute it by SDN.

> The draft relies on the IPv6 node requirements RFC that mandates the
> supports of IPv6. Also, the I-D calls out applications that are
> provided by the vendor of the device:
>
> == APP_REC#2:  Applications provided by the mobile device vendor
> must be independent of the underlying IP address family. ==
>
> Wouldn't this reco addresses your concern?

PArtially yes.

But is it feasible to recommend something to the 3rd party providers of 
applications?

[Med] FWIW, the wording we had for this reco is among the lines you are hinting: 

"
   REQ#33:  Applications MUST be independent of the underlying IP
          address family.
"

but we changed the wording to cover applications that under the responsibility of the device vendor. This change was a result of a comment we received in the mailing list. That comment was fair IMHO.

Is the mobile device vendor realizing that the 3rd party providers may 
prefer to connect to an IPv4-only APN instead of a 464XLAT APN?

[Med] This can be part of the internal validation process of the device vendors. I don't think we should interfere with those. Also, applications can be installed by the user so there is no guarantee those applications will behave well when IPv6 connectivity is provided. FYI, the reason we initially included this reco is that an app store from a vendor that is known to support IPv6 from a while is broken when an IPv6-only connectivity is in place. Having APP_REC#2 satisfied is already a high bar.

Alex

>
> Thank you.
>
> Cheers, Med
>
> -----Message d'origine----- De : v6ops
> [mailto:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu
> Envoyé : jeudi 12 février 2015 17:27 À : v6ops@ietf.org Objet : Re:
> [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt -
> C_REC#9 464XLAT
>
> Hello,
>
> Thank you for this new version of the draft.
>
> I have a doubt with respect to the 464XLAT requirement:
>> C_REC#9:  In order to ensure IPv4 service continuity in an
>> IPv6-only deployment context, the cellular host should implement
>> the Customer Side Translator (CLAT, [RFC6877]) function which is
>> compliant with [RFC6052][RFC6145][RFC6146].
>>
>> CLAT function in the cellular host allows for IPv4-only
>> application and IPv4-referals to work on an IPv6-only connectivity.
>> CLAT function requires a NAT64 capability [RFC6146] in the core
>> network.
>>
>> The IPv4 Service Continuity Prefix used by CLAT is defined in
>> [RFC7335].
>
> I think this requirement leads to a situation where the network
> operator deploys IPv6-native-only and IPv4 as an add-on partial
> feature.
>
> On one hand, it is encouraging to see native IPv6 and no IPv4.
>
> On another hand, _partial_ IPv4 support is a temptation which
> deceives in the end -  it leads to turn off IPv6 and come back to
> good ol' IPv4 and no IPv6.
>
> The 464XLAT is partial IPv4 support: does not offer full IPv4
> connectivity to the smartphone.  It is not possible to address the
> smartphone by its IPv4 address - DNS is required; this makes it
> impossible to make a VPN tunnel, or Mobile IP.  One can not a deploy
> a wireless IPv4 router along the road in a remote area, for example.
>
> This leads to a situation where the operator requires end user to
> switch to another APN which is less IPv6.
>
> I think it is not a happy situation.
>
> I would  suggest to qualify this requirement by another requirement.
>  This initial requirement would state that _first_, before any v4-v6
>  conversion mechanism is considered, both the network and the end
> user MUST implement a native IPv4 stack and a native IPv6 stack (not
> say 'dual' stack, which is much overloaded).
>
> We dont want to block IPv4 use when IPv6 arrives.
>
> Alex
>
> 12/02/2015 13:42, internet-drafts@ietf.org a écrit :
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the IPv6 Operations
>> Working Group of the IETF.
>>
>> Title           : An Internet Protocol Version 6 (IPv6) Profile
>> for 3GPP Mobile Devices Authors         : David Binet Mohamed
>> Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler
>> Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages
>> : 18 Date            : 2015-02-12
>>
>> Abstract: This document defines a profile that is a superset of
>> that of the connection to IPv6 cellular networks defined in the
>> IPv6 for Third Generation Partnership Project (3GPP) Cellular
>> Hosts document.  This document defines an IPv6 profile that a
>> number of operators recommend in order to connect 3GPP mobile
>> devices to an IPv6-only or dual-stack wireless network (including
>> 3GPP cellular network and IEEE 802.11 network) with a special focus
>> on IPv4 service continuity features.
>>
>> Both hosts and devices with capability to share their WAN (Wide
>> Area Network) connectivity are in scope.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/
>>
>>
>>
>>
There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17
>>
>>
>>
>>
A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-17
>>
>>
>>
>>
>>
Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________ v6ops mailing list
>>  v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>
>