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 16:34, [e-mail] a écrit :
> Re-,
>
> CLAT is not a MUST, it is listed as a "should".

I think CLAT should be a MAY, for those who need it.

I think the operator should offer a high level of simultaneous IPv4 and
IPv6 access even though the end user forgets to run CLAT.

> The main motivation for it is to fix the "remaining" applications
> that are broken if IPv6-only mode is enabled: IPv4-only applications
> or those using IPv4 referrals (e.g., skype is usually presented as
> an example of such applications).

One wouldn't fix applications by improving routing, no.   One could
develop a CLAT checkbox in the skype Options menu.  But one would not
require all other IPv4 apps in the Host to go through the CLAT daemon.

> Some operators are seeing CLAT as critical because they don't want to
> have a service disruption compared to IPv4 when IPv6-only
> connectivity is provided to their customers.

I agree about the criticality of IPv4 apps when IPv6-only connectivity
is in place.

But why should there be IPv6-only connectivity in place today for the
masses?

Nobody but some ultra-geek do this IPv6-only today.

Even if the operator's network is IPv6 only, it should have means to
translate between v4 and v6 at its edges, such as to show pure IPv4 and
pure IPv6 to end user.

> The comparison with the DSL world is not accurate IMHO because
> encapsulation schemes are the rule in fixed environments (e.g.,
> DS-lite, MAP, lw4over6, etc.) even if there are recently some
> proposals relying on double translation (e.g., MAP-T).

Yes, in the DSL world encapsulations schemes are used.  But they don't
touch the end users.

I think even with 464xlat/clat there is some encapsulation, although
much of it is probably address or header rewriting.

An end-user wouldnt normally care how much of this is translation,
address rewriting, packet-in-packet encapsulation.  But would be
surprised to be imposed to do it.  Because it interacts with other
networking software like VPN, Mobile IP and has additional software
requirements.

> In the mobile world, NAT64 is the rule.

Well, IMHO it's delicate to attach importance to something having NAT
and IPv6 in a same term.

Yours,

Alex

>
> Cheers, Med
>
> -----Message d'origine----- De : Alexandru Petrescu
> [mailto:[e-mail]] Envoyé : vendredi 13 février
> 2015 15:35 À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN Cc :
> [e-mail] Objet : 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.
>
> 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.
>
> It is easier for an end user to connect to a pure v4-APN rather than
>  a v6 APN with CLAT.
>
>> Internet-side initiated traffic would be an issue, same as NAT44
>> CGN.
>
> YEs, I understand that reachability problem.
>
> But here we have a problem with requiring the end user device to run
> translation just because of IPv6.
>
> App writers have already solved the NAT44 reverse reachability
> problems - they work on non-CLAT devices behind NAT.  These apps will
> no longer work in the v6 world, if CLAT is not added.
>
> One would hardly migrate to IPv6 if too much translation is required,
> be it v4-v6 or v6-v4 translation.
>
> Compare this to the v6 migration in the DSL world: no additional CLAT
> is required on end-user devices.
>
> Alex
>
>> Nick
>>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[e-mail]] Sent: 13 February 2015 12:52
>> To: Heatley, Nick; [e-mail] Cc: [e-mail]
>> Subject: Re: [v6ops] I-D Action:
>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
>>
>> Le 13/02/2015 11:13, Heatley, Nick a écrit :
>>> A statement such as
>>>> The device should only invoke the CLAT in the absence of a the
>>>>  IPv4 AF i.e. when the network does not assign an IPv4 cellular
>>>>  address
>>> could be helpful?
>>>
>>> To go further, and define any additional requirement, then that
>>> would be defining how an Operator could/should manage their
>>> remaining IPv4 public and private addressing. This paper should
>>> only focus on the required device behaviour.
>>>
>>> As an aside 464xlat is a direct replacement for the NAT44
>>> environments, typical in mobile operators with large consumer
>>> bases.
>>
>> Nick,
>>
>> Am I wrong to say that one can not ping 8.8.8.8 from behind a
>> 464xlat, whereas one can ping 8.8.8.8 behind a nat44?
>>
>> If I am not wrong then 464xlat and nat44 are not really
>> equivalent.
>>
>> Alex
>>
>>> Ideal if an operator is exhausting both public and private
>>> address space. If an operator has ample public IPv4 and has
>>> consumer products that are NAT44-free, then they are in a
>>> different place (a utopia). Nick
>>>
>>>
>>> -----Original Message----- From: v6ops
>>> [mailto:[e-mail]] On Behalf Of
>>> [e-mail] Sent: 13 February 2015 06:49 To:
>>> Alexandru Petrescu Cc: [e-mail] Subject: Re: [v6ops] I-D
>>> Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9
>>> 464XLAT
>>>
>>> Hi Alex,
>>>
>>> The intent of this reco is to address broken IPv4-only
>>> applications over an IPv6-only connectivity. Ideally applications
>>> running on the device should be AF-independent.
>>>
>>> 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?
>>>
>>> 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-profi
>>>>
>>>>
>>>>
>>>>
l
>>>>
>>>>
>> e/
>>>>
>>>> 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-profi
>>>>
>>>>
>>>>
>>>>
l
>>>>
>>>>
>> e-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
>>>
>>> _______________________________________________ v6ops mailing
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>> NOTICE AND DISCLAIMER This e-mail (including any attachments) is
>>> intended for the above-named person(s).  If you are not the
>>> intended recipient, notify the sender immediately, delete this
>>> email from your system and do not disclose or use for any
>>> purpose.
>>>
>>> We may monitor all incoming and outgoing emails in line with
>>> current legislation. We have taken steps to ensure that this
>>> email and attachments are free from any virus, but it remains
>>> your responsibility to ensure that viruses do not adversely
>>> affect you.
>>>
>>> EE Limited Registered in England and Wales Company Registered
>>> Number: 02382161 Registered Office Address: Trident Place,
>>> Mosquito Way, Hatfield, Hertfordshire, AL10 9BW.
>>>
>>
>>
>>
>> NOTICE AND DISCLAIMER This e-mail (including any attachments) is
>> intended for the above-named person(s).  If you are not the
>> intended recipient, notify the sender immediately, delete this
>> email from your system and do not disclose or use for any purpose.
>>
>> We may monitor all incoming and outgoing emails in line with
>> current legislation. We have taken steps to ensure that this email
>>  and attachments are free from any virus, but it remains your
>> responsibility to ensure that viruses do not adversely affect you.
>>
>> EE Limited Registered in England and Wales Company Registered
>> Number: 02382161 Registered Office Address: Trident Place, Mosquito
>> Way, Hatfield, Hertfordshire, AL10 9BW.
>>
>
>