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

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

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