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

[Ca By <[e-mail]>]

On Fri, Feb 13, 2015 at 10:02 AM, Alexandru Petrescu <
[e-mail]> wrote:

> Le 13/02/2015 18:37, Ca By a écrit :
>
>>
>>
>> On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>>
>>     Le 13/02/2015 16:33, Heatley, Nick a écrit :
>>
>>
>>
>>         -----Original Message----- From: Alexandru Petrescu
>>         [mailto:alexandru.petrescu@__gmail.com
>>         <mailto:[e-mail]>] Sent: 13 February 2015
>> 14:35
>>         To: Heatley, Nick; [e-mail]
>>         <mailto:[e-mail]> Cc: [e-mail]
>>         <mailto:[e-mail]>
>>         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.  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.
>>
>>
>> Hi,
>>
>> T-Mobile US's IPv6 deployment is 100% 464XLAT.
>>
>> According to measurements, 49% of connections to major internet content
>> is over IPv6 from T-Mobile US
>>
>> http://www.worldipv6launch.org/measurements/
>>
>> According to public statement, T-Mobile US has 50+ million subscribers
>> in q3 2014
>>
>> So, 49% of 50 Million -- i do not think it is fair to characterize
>> 464XLAT as only being a trial.
>>
>
> Hi Cameron,
>
> I am impressed by the figures, it's good for IPv6 in general.
>
> In other places 464xlat is still a trial. In these trials, my suggestion
> is to not make CLAT mandatory on the device, and still offer native IPv4
> and native IPv6 to the end user.
>
>
Offering native IPv4 is not an option due to IPv4 address exhaustion.


> If this is realized (avoid CLAT), do you think T-Mobile subscribers
> would talk easier to subscribers of these networks currently trialled?
>
> Or is it that subscribers of other networks MUST have CLAT in their
> phones in order to talk to CLAT phones of T-Mobile?
>
> Alex
>
>
It is my recommendations that networks and service use IPv6 to avoid any
undue complications related to CGN / NAT44 / NAT64 / MAP and so on.

IPv4 is fundamentally problematic  in any network that exceeds 4 billion
nodes in size. I do not recommend using IPv4 on the Internet.

Regards,

Cameron


>
>> Regards,
>>
>> Cameron
>>
>>
>>
>>         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.
>>
>>     It's hard to justify requiring just one of them on all end-user
>>     terminals because it will surely affect the other.
>>
>>         It is easier for an end user to connect to a pure v4-APN rather
>> than
>>         a v6 APN with CLAT.
>>
>>         [Heatley, Nick] If they have the choice....when the element of
>>         choice
>>         is taken away, the operator must make their network bullet proof
>> for
>>         all devices supported.
>>
>>
>>     Well, historic operators, MVNOs?
>>
>>     Historic operators today no longer 'own' the device as in the recent
>>     past.  Yes, they have contracts with well-funded manufacturers, but
>>     they also accept any other device to connect to their networks.
>>     They sell SIM cards with DATA plans regardless of the device in
>>     which this SIM card ends: they must offer unlocking codes of all
>>     devices they sell. Finally they must accept phone number portability
>>     for free.
>>
>>     If this 464xlat/clat requirement is between a Historic operator and
>>     an MVNOs, then it may make sense.
>>
>>     But one can not require the end-user to run CLAT translation.
>>
>>     Alex
>>
>>
>>             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:alexandru.petrescu@__gmail.com
>>             <mailto:[e-mail]>] Sent: 13 February
>>             2015 12:52
>>             To: Heatley, Nick; [e-mail]
>>             <mailto:[e-mail]> Cc: [e-mail]
>>             <mailto:[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]
>>                 <mailto:[e-mail]>__] On Behalf Of
>>                 [e-mail]
>>                 <mailto:[e-mail]> Sent: 13 February
>>                 2015 06:49 To:
>>                 Alexandru Petrescu Cc: [e-mail]
>>                 <mailto:[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]
>>                 <mailto:[e-mail]>__] De la part de
>>                 Alexandru Petrescu
>>                 Envoyé : jeudi 12 février 2015 17:27 À : [e-mail]
>>                 <mailto:[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]
>>                 <mailto:[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-prof
>>                     <https://datatracker.ietf.org/
>> doc/draft-ietf-v6ops-mobile-device-prof>
>>
>>
>>     i
>>
>>                     l
>>
>>
>>             e/
>>
>>
>>                     There's also a htmlized version available at:
>>                     http://tools.ietf.org/html/__
>> draft-ietf-v6ops-mobile-__device-profile-17
>>                     <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-prof
>>                     <http://www.ietf.org/rfcdiff?
>> url2=draft-ietf-v6ops-mobile-device-prof>
>>
>>
>>     i
>>
>>                     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 <http://tools.ietf.org>.
>>
>>                     Internet-Drafts are also available by anonymous FTP
>> at:
>>                     ftp://ftp.ietf.org/internet-__drafts/
>>                     <ftp://ftp.ietf.org/internet-drafts/>
>>
>>                     _________________________________________________
>>                     v6ops mailing
>>                     list [e-mail] <mailto:[e-mail]>
>>                     https://www.ietf.org/mailman/__listinfo/v6ops
>>                     <https://www.ietf.org/mailman/listinfo/v6ops>
>>
>>
>>
>>
>>                 _________________________________________________ v6ops
>>                 mailing
>>                 list [e-mail] <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/__listinfo/v6ops
>>                 <https://www.ietf.org/mailman/listinfo/v6ops>
>>
>>                 _________________________________________________ v6ops
>>                 mailing
>>                 list [e-mail] <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/__listinfo/v6ops
>>
>>                 <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.
>>
>>
>>
>>
>>         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.
>>
>>
>>
>>     _________________________________________________
>>     v6ops mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/__listinfo/v6ops
>>     <https://www.ietf.org/mailman/listinfo/v6ops>
>>
>>
>>
>
>