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

[Alexandru Petrescu <[e-mail]>]

Le 13/02/2015 07:49, [e-mail] 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?

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?

Alex

>
> Thank you.
>
> Cheers, Med
>
> -----Message d'origine----- De : v6ops
> [mailto:[e-mail]] De la part de Alexandru Petrescu
> Envoyé : jeudi 12 février 2015 17:27 À : [e-mail] 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, [e-mail] 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
>>  [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
>
> _______________________________________________ v6ops mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>
>