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

"Heatley, Nick" <nick.heatley@ee.co.uk> Fri, 13 February 2015 15:33 UTC

Return-Path: <nick.heatley@ee.co.uk>
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 87E611A8748 for <v6ops@ietfa.amsl.com>; Fri, 13 Feb 2015 07:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
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 rEbiRL3xIoNP for <v6ops@ietfa.amsl.com>; Fri, 13 Feb 2015 07:33:30 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508871A873B for <v6ops@ietf.org>; Fri, 13 Feb 2015 07:33:30 -0800 (PST)
Received: from [85.158.136.3] by server-10.bemta-5.messagelabs.com id 65/02-02756-8491ED45; Fri, 13 Feb 2015 15:33:28 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-5.tower-123.messagelabs.com!1423841607!38748163!1
X-Originating-IP: [149.254.241.76]
X-StarScan-Received:
X-StarScan-Version: 6.13.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13933 invoked from network); 13 Feb 2015 15:33:28 -0000
Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-5.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2015 15:33:28 -0000
Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id <B54de19410000>; Fri, 13 Feb 2015 15:33:21 +0000
Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id <B54de19460001>; Fri, 13 Feb 2015 15:33:26 +0000
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 15:33:23 +0000
From: "Heatley, Nick" <nick.heatley@ee.co.uk>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
Thread-Index: AQHQRuDyH0P8VsyAQ0msn8bBnn4Z5ZzuJKAAgAA1/FCAAC9ogIAABSbAgAAXqQCAAAP9EA==
Date: Fri, 13 Feb 2015 15:33:23 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303DEA722@UK30S005EXS06.EEAD.EEINT.CO.UK>
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>
In-Reply-To: <54DE0BA8.8020908@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/TngQFsXiUxTZKjprSqpF2ib4XF4>
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 15:33:34 -0000


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

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?

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.

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