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

Ca By <cb.list6@gmail.com> Fri, 13 February 2015 17:39 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC58E1A006F for <v6ops@ietfa.amsl.com>; Fri, 13 Feb 2015 09:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acy6AanVIN3X for <v6ops@ietfa.amsl.com>; Fri, 13 Feb 2015 09:38:59 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222BC1A0060 for <v6ops@ietf.org>; Fri, 13 Feb 2015 09:37:37 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id k48so18001489wev.3 for <v6ops@ietf.org>; Fri, 13 Feb 2015 09:37:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OjzEJC8tu5wgNDHR9YyX9L+3u1IPC7RDDz4jbBrVZlU=; b=U4VkRiec9k9QwhThDHUL7VnO9LDTIp/zdV64NaF3xat/WnrnsSZQhJdAcvIi3F3Uo9 fCCIy1q8hQTKLSWatIv2w5Yz1bBpnp3vl/Nc0Qw4y8PP9tE4jCoZY8N/ac+D4MorbAhi b1xdV/JqB67DzTaw6MyzzWLpil5mhhF8eAWfHPA8VJqVFNti55xZvJhzG/zCN/YR7gyk odJKm7lXU4aNTUtsBSYYqW88YbnVGnCG8wxpdEC01Mbf3omnKFx8z2fY0yVMvwdpAqrI 7xiTzSheK4S9/3Un1ieNxGYv1LNTFmrg42IvHj/8f9CcPYe1FmIRItxMP7P8x1ocAf1J UnoA==
MIME-Version: 1.0
X-Received: by 10.194.2.43 with SMTP id 11mr9390520wjr.104.1423849054222; Fri, 13 Feb 2015 09:37:34 -0800 (PST)
Received: by 10.216.107.198 with HTTP; Fri, 13 Feb 2015 09:37:34 -0800 (PST)
In-Reply-To: <54DE227D.9050303@gmail.com>
References: <20150212124226.3282.9774.idtracker@ietfa.amsl.com> <54DCD464.3000907@gmail.com> <787AE7BB302AE849A7480A190F8B93300490A7DD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303DEA4B0@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DDF37D.1050405@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA605@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE0BA8.8020908@gmail.com> <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK> <54DE227D.9050303@gmail.com>
Date: Fri, 13 Feb 2015 09:37:34 -0800
Message-ID: <CAD6AjGRCvc314QaiGfMGLF2Wakn8ueQK55E-sxw3qW4FXLApOw@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b3a82b2173e8e050efbb1ac"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/VkX_z5UfzU9owWHbs8dCkt3Y5uQ>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2015 17:39:08 -0000

On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu <
alexandru.petrescu@gmail.com> wrote:

> Le 13/02/2015 16:33, Heatley, Nick a écrit :
>
>>
>>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:alexandru.petrescu@gmail.com] Sent: 13 February 2015 14:35
>> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org
>> 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.

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] Sent: 13 February 2015 12:52
>>> To: Heatley, Nick; mohamed.boucadair@orange.com Cc: v6ops@ietf.org
>>> 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:v6ops-bounces@ietf.org] On Behalf Of
>>>> mohamed.boucadair@orange.com Sent: 13 February 2015 06:49 To:
>>>> Alexandru Petrescu Cc: v6ops@ietf.org 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:v6ops-bounces@ietf.org] De la part de Alexandru Petrescu
>>>> Envoyé : jeudi 12 février 2015 17:27 À : v6ops@ietf.org 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, internet-drafts@ietf.org 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
>>>>>
>>>>>
>>>>>  i
>
>> 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-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.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________ v6ops mailing
>>>>> list v6ops@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list v6ops@ietf.org 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>