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 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.
>