Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt

From: [email-masked]
Date: Thu, 12 Feb 2015 04:42:26 -0800

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Feb 2015 17:27:16 +0100

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, [email-masked] a écrit :
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Ross Chandler <[email-masked]>
Date: Thu, 12 Feb 2015 19:39:08 +0000

> On 12 Feb 2015, at 16:27, Alexandru Petrescu <[email-masked]> wrote:
> 
> Hello,
> 
> 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 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.

Alex,

Are you saying all VPNs impossible or just ones not that don’t go through NAPT because they don’t use TCP/UDP or something else? Openvpn and IPSec over TCP/UDP work. In the pure IPv4 case their can also be problems with PPTP if the CGN doesn’t have an ALG.

> This leads to a situation where the operator requires end user to switch to another APN which is less IPv6.
> 
> 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).
> 

Perhaps it could be clarified in C_REC#9 that the IPv6-only deployment context refers to the 3GPP device? The data APN it accesses could support IPv4, IPv6 and dual-stack IPv4v6 PDP/PDNs.

BR
Ross

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Feb 2015 14:26:37 -0800

On Thu, Feb 12, 2015 at 11:39 AM, Ross Chandler <[email-masked]> wrote:

> Are you saying all VPNs impossible or just ones not that don’t go through
> NAPT because they don’t use TCP/UDP or something else? Openvpn and IPSec
> over TCP/UDP work. In the pure IPv4 case their can also be problems with
> PPTP if the CGN doesn’t have an ALG.
>

"IPsec over UDP works" is an overstatement. For example, GRE VPN does not
work without an ALG for GRE, and IPsec over UDP using certificates does not
work unless the NAT64 properly supports fragmentation. I have seen at least
one large deployment where that is not the case.

---

From: <[email-masked]>
Date: Fri, 13 Feb 2015 06:49:20 +0000

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:[email-masked]] De la part de Alexandru Petrescu
Envoyé : jeudi 12 février 2015 17:27
À : [email-masked]
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Hello,

Alex

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 13 Feb 2015 10:13:16 +0000

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.
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:[email-masked]] On Behalf Of [email-masked]
Sent: 13 February 2015 06:49
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Hi Alex, 

==

Thank you.

Cheers,
Med

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de Alexandru Petrescu Envoyé : jeudi 12 février 2015 17:27 À : [email-masked] Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Hello,

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

Alex

12/02/2015 13:42, [email-masked] a écrit :
> 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.
>

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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 13:27:36 +0100

Le 12/02/2015 20:39, Ross Chandler a écrit :
>>> 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].
>>>
>>> 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 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.
>>
>> 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.
>
> Alex,
>
> Are you saying all VPNs impossible or just ones not that don’t go
> through NAPT because they don’t use TCP/UDP or something else?
> Openvpn and IPSec over TCP/UDP work. In the pure IPv4 case their can
> also be problems with PPTP if the CGN doesn’t have an ALG.

Maybe some work, I dont doubt.

I doubt however a VPN tool which does not query the DNS will work behind 
464XLAT.

>> This leads to a situation where the operator requires end user to
>> switch to another APN which is less IPv6.
>>
>> 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).
>>
> Perhaps it could be clarified in C_REC#9 that the IPv6-only
> deployment context refers to the 3GPP device? The data APN it
> accesses could support IPv4, IPv6 and dual-stack IPv4v6 PDP/PDNs.

I think the current deployments of 464XLAT use the same APN for both 
3GPP and data services.

Alex

> BR Ross

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 13:50:13 +0100

Le 13/02/2015 07:49, [email-masked] a écrit :
> Hi Alex,
>
> The intent of this reco is to address broken IPv4-only applications
> over an IPv6-only connectivity.

Ok, makes sense.

> Ideally applications running on the device should be AF-independent.

That is an ideal, laudable goal.

There a number of professional applications that are Address Family 
dependent, and which do not query DNS to find an address.  They may 
distribute it by SDN.

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

PArtially yes.

But is it feasible to recommend something to the 3rd party providers of 
applications?

Is the mobile device vendor realizing that the 3rd party providers may 
prefer to connect to an IPv4-only APN instead of a 464XLAT APN?

Alex

>
> Thank you.
>
> Cheers, Med
>
> -----Message d'origine----- De : v6ops
> [mailto:[email-masked]] De la part de Alexandru Petrescu
> Envoyé : jeudi 12 février 2015 17:27 À : [email-masked] Objet : Re:
> [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt -
> C_REC#9 464XLAT
>
> Hello,
>
>> application and IPv4-referals to work on an IPv6-only connectivity.
>> CLAT function requires a NAT64 capability [RFC6146] in the core
>> network.
>>
> 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.
>
>  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).
>
>> 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.
>>
>>
>> _______________________________________________ v6ops mailing list
>>  [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 13:52:13 +0100

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:[email-masked]] On Behalf Of
> [email-masked] Sent: 13 February 2015 06:49 To:
> Alexandru Petrescu Cc: [email-masked] Subject: Re: [v6ops] I-D
> Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9
> 464XLAT
>
> Hi Alex,
>
> over an IPv6-only connectivity. Ideally applications running on the
> device should be AF-independent.
>
> == APP_REC#2:  Applications provided by the mobile device vendor must
> be independent of the underlying IP address family. ==
>
>> 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.
>>
>> 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
>>
>> 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.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profil
>>
>>
e/
A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profil
>>
>>
e-17
> 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.
>

---

From: <[email-masked]>
Date: Fri, 13 Feb 2015 13:00:36 +0000

Re-,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alexandru Petrescu [mailto:[email-masked]] 
Envoyé : vendredi 13 février 2015 13:50
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Ok, makes sense.

PArtially yes.

[Med] FWIW, the wording we had for this reco is among the lines you are hinting: 

"
   REQ#33:  Applications MUST be independent of the underlying IP
          address family.
"

but we changed the wording to cover applications that under the responsibility of the device vendor. This change was a result of a comment we received in the mailing list. That comment was fair IMHO.

[Med] This can be part of the internal validation process of the device vendors. I don't think we should interfere with those. Also, applications can be installed by the user so there is no guarantee those applications will behave well when IPv6 connectivity is provided. FYI, the reason we initially included this reco is that an app store from a vendor that is known to support IPv6 from a while is broken when an IPv6-only connectivity is in place. Having APP_REC#2 satisfied is already a high bar.

Alex

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 13 Feb 2015 13:14:03 +0000

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 :-))
Internet-side initiated traffic would be an issue, same as NAT44 CGN.
Nick

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 13 February 2015 12:52
To: Heatley, Nick; [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

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?

Alex

> -----Original Message----- From: v6ops [mailto:[email-masked]] 
> On Behalf Of [email-masked] Sent: 13 February 2015 06:49 
> To:
> -----Message d'origine----- De : v6ops [mailto:[email-masked]] 
> De la part de Alexandru Petrescu Envoyé : jeudi 12 février 2015 17:27 
> À : [email-masked] Objet : Re:
>> deployment context, the cellular host should implement the Customer 
>> Side Translator (CLAT, [RFC6877]) function which is compliant with 
>> [RFC6052][RFC6145][RFC6146].
>>
>> function requires a NAT64 capability [RFC6146] in the core network.
>>
>> directories. This draft is a work item of the IPv6 Operations Working 
>> Group of the IETF.
>>
>> Abstract: This document defines a profile that is a superset of that 
>> of the connection to IPv6 cellular networks defined in the
>> network and IEEE 802.11 network) with a special focus on IPv4 service 
>> continuity features.
>>
e/
e-17

NOTICE AND DISCLAIMER

EE Limited

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 15:35:20 +0100

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 16:04:20 +0100

Hi Med,

Le 13/02/2015 14:00, [email-masked] a écrit :
> Re-,
>
> Please see inline.
>
> Cheers, Med
>
> -----Message d'origine----- De : Alexandru Petrescu
> [mailto:[email-masked]] Envoyé : vendredi 13 février
> 2015 13:50 À : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked] Objet :
> Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt
> - C_REC#9 464XLAT
>
>> The draft relies on the IPv6 node requirements RFC that mandates
>> the supports of IPv6. Also, the I-D calls out applications that are
> But is it feasible to recommend something to the 3rd party providers
> of applications?
>
> " REQ#33:  Applications MUST be independent of the underlying IP
> address family. "

Well, it's a good goal.  But it is not the way many apps work.  We can't
delete them with a req in an RFC.

> but we changed the wording to cover applications that under the
> responsibility of the device vendor. This change was a result of a
> comment we received in the mailing list. That comment was fair IMHO.

Well, yes, you have made a good distinction.

But still there are many address family dependent applications written
even by the device vendors in question.

> Is the mobile device vendor realizing that the 3rd party providers
> may prefer to connect to an IPv4-only APN instead of a 464XLAT APN?
>
> [Med] This can be part of the internal validation process of the
> device vendors. I don't think we should interfere with those.

noted.

> Also, applications can be installed by the user so there is no
> guarantee those applications will behave well when IPv6 connectivity
>  is provided.

YEs.  Some will fault writing apps incompatible with a simultaneous 
v4-v6 access.  They should be told to either correct, or maybe use a 
464xlat/CLAT feature.

All the other apps who support ok simultaneous v4-v6 access should not 
be imposed to run CLAT/464xlat.

> FYI, the reason we initially included this reco is that an app store
> from a vendor that is known to support IPv6 from a while is broken
> when an IPv6-only connectivity is in place.

Noted.

But I think it is too early to propose large populations of users
v6-only access networks.

> Having APP_REC#2 satisfied is already a high bar.

YEs, a v6-only access network is a dream for the v6-inclined.  But it is 
too daring.

Consider how IPv6 migration happens in DSL networks, like the success at 
Free.  It is the box which does all sorts of translations, 6rd, whatever 
- this is all invisible to the user device.

In the same vein, a cellular network could do all sorts of translation 
in the Access Router, Base Station, SGSN; and offer native IPv4 and 
native IPv6 to the end user.  The user would switch to IPv6 when s/he 
feels like, free from translation hurdles.

Alex

>>> 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.
>>>
>>> Filename : draft-ietf-v6ops-mobile-device-profile-17.txt Pages :
>>> 18 Date            : 2015-02-12
>>>
>>> 3GPP cellular network and IEEE 802.11 network) with a special
>>> focus on IPv4 service continuity features.
>>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>
>>

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 13 Feb 2015 15:33:23 +0000

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 13 February 2015 14:35
To: Heatley, Nick; [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

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

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

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

> Subject: Re: [v6ops] I-D Action: 
> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
>
>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-prof
>>> i
>>> l
>>>
>>>
> e/
>>>
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-prof
>>> i
>>> l
>>>
>>>
> e-17
>>>
>>>

NOTICE AND DISCLAIMER

EE Limited

---

From: <[email-masked]>
Date: Fri, 13 Feb 2015 15:34:51 +0000

Re-,

CLAT is not a MUST, it is listed as a "should". The main motivation for it is to fix the "remaining" applications that are broken if IPv6-only mode is enabled: IPv4-only applications or those using IPv4 referrals (e.g., skype is usually presented as an example of such applications). 

Some operators are seeing CLAT as critical because they don't want to have a service disruption compared to IPv4 when IPv6-only connectivity is provided to their customers. 

The comparison with the DSL world is not accurate IMHO because encapsulation schemes are the rule in fixed environments (e.g., DS-lite, MAP, lw4over6, etc.) even if there are recently some proposals relying on double translation (e.g., MAP-T). 

In the mobile world, NAT64 is the rule.

Cheers,
Med

-----Message d'origine-----
De : Alexandru Petrescu [mailto:[email-masked]] 
Envoyé : vendredi 13 février 2015 15:35
À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 17:12:45 +0100

Le 13/02/2015 16:33, Heatley, Nick a écrit :
>
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: 13 February 2015 14:35
> To: Heatley, Nick; [email-masked] Cc: [email-masked]
>> 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 :-))
>
> [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.

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

> 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.
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: 13 February 2015 12:52
>> To: Heatley, Nick; [email-masked] Cc: [email-masked]
>>>> 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.
>>>
>> 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?
>>
>>> 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
>>>
>>>
>>> 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 supports of IPv6. Also, the I-D calls out applications that
>>> are provided by the vendor of the device:
>>>
>>> Envoyé : jeudi 12 février 2015 17:27 À : [email-masked] Objet :
>>> Re: [v6ops] I-D Action:
>>>> IPv6-only deployment context, the cellular host should
>>>> implement the Customer Side Translator (CLAT, [RFC6877])
>>>> function which is compliant with [RFC6052][RFC6145][RFC6146].
>>>>
>>> deceives in the end -  it leads to turn off IPv6 and come back
>>> to good ol' IPv4 and no IPv6.
>>>
>>> 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.
>>>
>>>> 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.
>>>>
i
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.
>>>>
>>>> list [email-masked]
>>> 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.
>>>
>>
>>
>>
>> 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
>> EE Limited Registered in England and Wales Company Registered
>> Number: 02382161 Registered Office Address: Trident Place, Mosquito
>> Way, Hatfield, Hertfordshire, AL10 9BW.
>>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 17:58:40 +0100

Le 13/02/2015 16:34, [email-masked] a écrit :
> Re-,
>
> CLAT is not a MUST, it is listed as a "should".

I think CLAT should be a MAY, for those who need it.

I think the operator should offer a high level of simultaneous IPv4 and
IPv6 access even though the end user forgets to run CLAT.

> The main motivation for it is to fix the "remaining" applications
> that are broken if IPv6-only mode is enabled: IPv4-only applications
> or those using IPv4 referrals (e.g., skype is usually presented as
> an example of such applications).

One wouldn't fix applications by improving routing, no.   One could
develop a CLAT checkbox in the skype Options menu.  But one would not
require all other IPv4 apps in the Host to go through the CLAT daemon.

> Some operators are seeing CLAT as critical because they don't want to
> have a service disruption compared to IPv4 when IPv6-only
> connectivity is provided to their customers.

I agree about the criticality of IPv4 apps when IPv6-only connectivity
is in place.

But why should there be IPv6-only connectivity in place today for the
masses?

Nobody but some ultra-geek do this IPv6-only today.

Even if the operator's network is IPv6 only, it should have means to
translate between v4 and v6 at its edges, such as to show pure IPv4 and
pure IPv6 to end user.

> The comparison with the DSL world is not accurate IMHO because
> encapsulation schemes are the rule in fixed environments (e.g.,
> DS-lite, MAP, lw4over6, etc.) even if there are recently some
> proposals relying on double translation (e.g., MAP-T).

Yes, in the DSL world encapsulations schemes are used.  But they don't
touch the end users.

I think even with 464xlat/clat there is some encapsulation, although
much of it is probably address or header rewriting.

An end-user wouldnt normally care how much of this is translation,
address rewriting, packet-in-packet encapsulation.  But would be
surprised to be imposed to do it.  Because it interacts with other
networking software like VPN, Mobile IP and has additional software
requirements.

> In the mobile world, NAT64 is the rule.

Well, IMHO it's delicate to attach importance to something having NAT
and IPv6 in a same term.

Yours,

Alex

> 2015 15:35 À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN Cc :
> [email-masked] Objet : Re: [v6ops] I-D Action:
>>>> devices to an IPv6-only or dual-stack wireless network
>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profi
>>>>
>>>>
>>>>
>>>>
l
A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profi
>>>>
>>>>
>>>>
>>>>
l
>>>>  of submission until the htmlized version and diff are
>>>> available at tools.ietf.org.
>>>>

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 13 Feb 2015 17:11:09 +0000

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

Not possible in mobile architecture.
The mobile bearer (a tunnel) is between device, and PGW in the core network, because it is the device that is mobile.
PGW assigns IP address to device, base station is just a relay.
For base station to take the role of CLAT means no seamless mobility. 

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 13 February 2015 16:13
To: Heatley, Nick; [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

NOTICE AND DISCLAIMER

EE Limited

---

From: Ca By <[email-masked]>
Date: Fri, 13 Feb 2015 09:37:34 -0800

On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu <
[email-masked]> wrote:

> 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

> It's hard to justify requiring just one of them on all end-user terminals
> because it will surely affect the other.
>
> 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.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 18:39:25 +0100

Le 13/02/2015 18:11, Heatley, Nick a écrit :
>> 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.
>

If it is not possible to have v4-v6 translation in the Base Station,
then it should be in the entity before it.  'PGW' mentioned?

> The mobile bearer (a tunnel) is between device, and PGW in the core
> network, because it is the device that is mobile. PGW assigns IP
> address to device, base station is just a relay.

In this case PGW (not the base station) should do translation.

I said 'base station' to refer to the cheap stations for femto-cell.
These run IP between an Ethernet cable and a 4G radio interface.
They're basically PCs easy to deploy.

It is easy to have many v4-v6 translation mechanisms on these PCs.

> For base station to take the role of CLAT means no seamless

Well, by deduction this implies that seamless mobility is possible only
if the end user implements CLAT.

On another hand, seamless mobility is also achieved by something else
which is called Mobile IP.  The end user in some cases prefers this
protocol over CLAT.

This Mobile IP protocol works fine when the cellular access is v4-only.
  Also, the Mobile IPv6 protocol works fine when the cellular access is
v6 only.  Finally, Mobile IPv4 and Mobile IPv6 implementations work fine
when the access is simultaneous v4 and v6.

There are a number of access networks (beyond cellular) which work fine
when the end user is Mobile IP.

This stops working fine when the access is v6-only with CLAT.

Alex

> [mailto:[email-masked]] Sent: 13 February 2015 16:13
>  recipient, notify the sender immediately, delete this email from
> your system and do not disclose or use for any purpose.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2015 19:02:45 +0100

Le 13/02/2015 18:37, Ca By a écrit :
>
>
> On Fri, Feb 13, 2015 at 8:12 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] Sent: 13 February 2015 14:35
>         <mailto:[email-masked]> Cc: [email-masked]
>         <mailto:[email-masked]>
>         draft-ietf-v6ops-mobile-__device-profile-17.txt - C_REC#9 464XLAT
>
>     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,
>
> According to measurements, 49% of connections to major internet content
> is over IPv6 from T-Mobile US
>
> 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

>     E.g. 464lat/clat to run on an operator-controlled network device,
>     not on end-user terminal.
>
>     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.
>
>     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.
>
>         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
>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>] Sent: 13 February
>             2015 12:52
>             <mailto:[email-masked]> Cc: [email-masked]
>             <mailto:[email-masked]>
>             draft-ietf-v6ops-mobile-__device-profile-17.txt - C_REC#9
>             464XLAT
>
>                 environments, typical in mobile operators with large
>                 consumer
>                 bases.
>
>
>             Nick,
>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>__] On Behalf Of
>                 [email-masked]
>                 <mailto:[email-masked]> Sent: 13 February
>                 2015 06:49 To:
>                 Alexandru Petrescu Cc: [email-masked]
>                 <mailto:[email-masked]> Subject: Re: [v6ops] I-D
>                 Action: draft-ietf-v6ops-mobile-__device-profile-17.txt
>                 - C_REC#9
>                 464XLAT
>
>                 Hi Alex,
>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>__] De la part de
>                 Alexandru Petrescu
>                 Envoyé : jeudi 12 février 2015 17:27 À : [email-masked]
>                 <mailto:[email-masked]> Objet :
>                 Re: [v6ops] I-D Action:
>                 draft-ietf-v6ops-mobile-__device-profile-17.txt -
>                 C_REC#9 464XLAT
>
>                 Hello,
>
>                     defined in
>                 12/02/2015 13:42, [email-masked]
>                 <mailto:[email-masked]> a écrit :
>
>
>                     Filename :
>                     draft-ietf-v6ops-mobile-__device-profile-17.txt Pages
>                     : 18 Date            : 2015-02-12
>
>                     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/
>
>
>                     http://tools.ietf.org/html/__draft-ietf-v6ops-mobile-__device-profile-17
>                     <http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17>
>
>
>
>
>
>                     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
>
>
>
>                     at tools.ietf.org <http://tools.ietf.org>.
>
>                     ftp://ftp.ietf.org/internet-__drafts/
>                     <ftp://ftp.ietf.org/internet-drafts/>
>
>                     _________________________________________________
>                     v6ops mailing
>                     list [email-masked] <mailto:[email-masked]>
>                     https://www.ietf.org/mailman/__listinfo/v6ops
>                     <https://www.ietf.org/mailman/listinfo/v6ops>
>
>
>
>
>                 _________________________________________________ v6ops
>                 mailing
>                 list [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/__listinfo/v6ops
>                 <https://www.ietf.org/mailman/listinfo/v6ops>
>
>                 _________________________________________________ v6ops
>                 mailing
>                 list [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/__listinfo/v6ops
>                 <https://www.ietf.org/mailman/listinfo/v6ops>
>
>             email
>         your
>         Number:
>     _________________________________________________
>     v6ops mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>
>

---

From: Ca By <[email-masked]>
Date: Fri, 13 Feb 2015 11:19:01 -0800

> and native IPv6 to the end user.
Offering native IPv4 is not an option due to IPv4 address exhaustion.

> phones in order to talk to CLAT phones of T-Mobile?
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

>>             Internet-side initiated traffic would be an issue, same as
>> NAT44
>>             CGN.
>>
>>
>>                     https://datatracker.ietf.org/_
>> _doc/draft-ietf-v6ops-mobile-__device-prof
>>                     http://tools.ietf.org/html/__
>> draft-ietf-v6ops-mobile-__device-profile-17
>>                     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
>>
>>
>>
>> intended
>> current

---

From: Ross Chandler <[email-masked]>
Date: Fri, 13 Feb 2015 20:44:10 +0000

> On 13 Feb 2015, at 12:27, Alexandru Petrescu <[email-masked]> wrote:
> 
> I think the current deployments of 464XLAT use the same APN for both 3GPP and data services.

I mean the APN configuration on the provider GGSN/PGW can simultaneously accept separate PDP/PDN connections of multiple types.
e.g The current APN name can be kept by the provider.  Their old devices use IPv4 with the APN and the newer devices use IPv6.  

Ross

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 13 Feb 2015 21:36:44 +0000

Hi,

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Friday, February 13, 2015 10:59 AM
> To: [email-masked]; Heatley, Nick
> Cc: [email-masked]
<snip/>
> > have a service disruption compared to IPv4 when IPv6-only connectivity
> > is provided to their customers.
> 
> I agree about the criticality of IPv4 apps when IPv6-only connectivity is in
> place.
> 
> But why should there be IPv6-only connectivity in place today for the masses?

Because whether it exists today, or not, that's the goal we are working toward.  It's far too late to be designing things based on some assumption that IPv6-only connectivity doesn't have to actually work anyway.  The ultimate goal is IPv6-only connectivity for the masses, and if we make no other assumptions, we ought to be able to start with the assumption that at least works to all internet connected IPv6 endpoints.

> Nobody but some ultra-geek do this IPv6-only today.

Ouch!

> 
> Even if the operator's network is IPv6 only, it should have means to translate
> between v4 and v6 at its edges, such as to show pure IPv4 and pure IPv6 t
> user.
> 

I think we should stay away from assumptions like this.  If no one is going to mandate that all ISPs MUST provide IPv6 connectivity, (and that hasn't happened yet), then it doesn't seem like we can make assumptions about where the translation needs to happen.

<snip/>

Thanks,

- Dan (part time ultra-geek I guess)

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Feb 2015 20:46:58 +0100

Hi,

> whereas one can ping 8.8.8.8 behind a nat44?

Yes, you are.

That is the whole point of a 464xlat: give applications that insist on
talking to numeric IPv4 addresses a way to do so.

Applications that use DNS and modern socket APIs do not need 464xlat, 
because NAT64/DNS64 will already solve their needs.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Feb 2015 20:49:00 +0100

Hi,

> smartphones which connect to a v6-only APN.  It is a too strong requirement.

It's not exactly hard.

> It is easier for an end user to connect to a pure v4-APN rather than a 

Why should the end user have to know?  This is completely transparent -
and available today: Android devices on T-Mobile USA's IPv6-only APN.

[..]
> required on end-user devices.

That's because there is still IPv4.  If you remove that from the DSL world,
and people want to keep using Skype, they need a CLAT.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 15 Feb 2015 20:47:15 +0100

On 13/02/2015 20:19, Ca By wrote:
>
>
> On Fri, Feb 13, 2015 at 10:02 AM, Alexandru Petrescu
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>                  [mailto:alexandru.petrescu@
>         <mailto:alexandru.petrescu@>__g__mail.com <http://gmail.com>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>] Sent: 13 February 2015 14:35
>         <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>> Cc: [email-masked]
>         <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>                  draft-ietf-v6ops-mobile-____device-profile-17.txt -
>         C_REC#9 464XLAT
>
>
>                      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.
>
>                  bearer use CLAT. A slightly pedantic note,  if you have
>         a "dual
>                  stack
>         http://www.worldipv6launch.__org/measurements/
>         <http://www.worldipv6launch.org/measurements/>
>
> nodes in size.

Numerous networks are not that large.

IPv4 deserves more consideration than what it seems to be implied above.

T-Mobile is not the only network out there.  If your goal is to present 
it as an example, I can agree with you - it's a good example, in one 
particular sense.

Alex

>  I do not recommend using IPv4 on the Internet.
>
> Regards,
>
> Cameron
>
>
>         Regards,
>
>         Cameron
>
>
>
>                  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?
>
>
>                  [Heatley, Nick] If they have the choice....when the
>         element of
>                  choice
>                      Internet-side initiated traffic would be an issue,
>         same as NAT44
>                      CGN.
>
>
>                  problems - they work on non-CLAT devices behind NAT.
>         These apps
>                  will
>                      [mailto:alexandru.petrescu@
>         <mailto:alexandru.petrescu@>__g__mail.com <http://gmail.com>
>                      <mailto:[email-masked]
>         <mailto:[email-masked]>>] Sent: 13 February
>                      2015 12:52
>         <mailto:[email-masked]>
>                      <mailto:[email-masked]
>         <mailto:[email-masked]>> Cc: [email-masked]
>         <mailto:[email-masked]>
>                      <mailto:[email-masked] <mailto:[email-masked]>>
>                      draft-ietf-v6ops-mobile-____device-profile-17.txt -
>         C_REC#9
>
>                      464XLAT
>
>                              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
>                          remaining IPv4 public and private addressing.
>         This paper
>                          should
>         <mailto:[email-masked]>
>                          <mailto:[email-masked]
>         <mailto:[email-masked]>__>__] On Behalf Of
>         [email-masked] <mailto:[email-masked]>
>                          <mailto:[email-masked]
>         <mailto:[email-masked]>> Sent: 13 February
>                          2015 06:49 To:
>                          <mailto:[email-masked] <mailto:[email-masked]>>
>         Subject: Re: [v6ops] I-D
>                          Action:
>         draft-ietf-v6ops-mobile-____device-profile-17.txt
>                          - C_REC#9
>                          464XLAT
>
>                          Hi Alex,
>
>                          applications over an IPv6-only connectivity.
>         Ideally
>                          applications
>                          The draft relies on the IPv6 node requirements
>         RFC that
>                          mandates
>         <mailto:[email-masked]>
>                          <mailto:[email-masked]
>         <mailto:[email-masked]>__>__] De la part de
>                          Alexandru Petrescu
>                          Envoyé : jeudi 12 février 2015 17:27 À :
>                          <mailto:[email-masked] <mailto:[email-masked]>>
>         Objet :
>                          Re: [v6ops] I-D Action:
>                          draft-ietf-v6ops-mobile-____device-profile-17.txt -
>
>                          C_REC#9 464XLAT
>
>                          Hello,
>
>                              C_REC#9:  In order to ensure IPv4 service
>         continuity
>                              in an
>                          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
>                          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
>                          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
>         <mailto:[email-masked]>
>                          <mailto:[email-masked]
>         <mailto:[email-masked]>> a écrit :
>
>
>                              Internet-Drafts directories. This draft is
>         a work
>                              item of the
>                              Title           : An Internet Protocol
>         Version 6
>                              (IPv6) Profile
>                              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
>                              Cellular Hosts document.  This document
>         defines an
>                              IPv6 profile
>                              that a number of operators recommend in
>         order to
>                              connect 3GPP
>                              (including 3GPP cellular network and IEEE
>         802.11
>                              network) with
>         https://datatracker.ietf.org/____doc/draft-ietf-v6ops-mobile-____device-prof
>         <https://datatracker.ietf.org/__doc/draft-ietf-v6ops-mobile-__device-prof>
>
>         <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/
>
>
>         http://tools.ietf.org/html/____draft-ietf-v6ops-mobile-____device-profile-17
>         <http://tools.ietf.org/html/__draft-ietf-v6ops-mobile-__device-profile-17>
>
>         <http://tools.ietf.org/html/__draft-ietf-v6ops-mobile-__device-profile-17
>         <http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-17>>
>
>
>
>
>
>         http://www.ietf.org/rfcdiff?____url2=draft-ietf-v6ops-mobile-____device-prof
>         <http://www.ietf.org/rfcdiff?__url2=draft-ietf-v6ops-mobile-__device-prof>
>
>         <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>
>         <http://tools.ietf.org>.
>
>         ftp://ftp.ietf.org/internet-____drafts/
>         <ftp://ftp.ietf.org/internet-__drafts/>
>                              <ftp://ftp.ietf.org/internet-__drafts/
>         <ftp://ftp.ietf.org/internet-drafts/>>
>
>
>         ___________________________________________________
>                              v6ops mailing
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/v6ops
>         <https://www.ietf.org/mailman/__listinfo/v6ops>
>
>         <https://www.ietf.org/mailman/__listinfo/v6ops
>         <https://www.ietf.org/mailman/listinfo/v6ops>>
>
>
>
>
>
>         ___________________________________________________ v6ops
>                          mailing
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/v6ops
>         <https://www.ietf.org/mailman/__listinfo/v6ops>
>                          <https://www.ietf.org/mailman/__listinfo/v6ops
>         <https://www.ietf.org/mailman/listinfo/v6ops>>
>
>
>         ___________________________________________________ v6ops
>                          mailing
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/v6ops
>         <https://www.ietf.org/mailman/__listinfo/v6ops>
>
>                          <https://www.ietf.org/mailman/__listinfo/v6ops
>         <https://www.ietf.org/mailman/listinfo/v6ops>>
>
>                          email and attachments are free from any virus,
>         but it
>                          remains
>              ___________________________________________________
>              v6ops mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/v6ops
>         <https://www.ietf.org/mailman/__listinfo/v6ops>
>              <https://www.ietf.org/mailman/__listinfo/v6ops
>         <https://www.ietf.org/mailman/listinfo/v6ops>>
>
>
>
>
>

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 15 Feb 2015 20:49:19 +0100

On 13/02/2015 21:44, Ross Chandler wrote:
> I mean the APN configuration on the provider GGSN/PGW can
> simultaneously accept separate PDP/PDN connections of multiple
> types. e.g The current APN name can be kept by the provider.  Their
> old devices use IPv4 with the APN and the newer devices use IPv6.

YEs, the APN type can be "IPv4IPv6", or something named like that.

Except that the 464xlat networks I am aware of to only "IPv6" kind  of APN.

In the past some of these networks were IPv4IPv6, but now they move to 
IPv6-only kind of type, and 464xlat/clat is given as reason why.

I disagree with that reason.

Alex

---

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 15 Feb 2015 20:56:19 +0100

On 13/02/2015 22:36, Metzler, Dan J wrote:
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Friday, February 13, 2015 10:59 AM To:
>> [email-masked]; Heatley, Nick Cc: [email-masked]
>>> Some operators are seeing CLAT as critical because they don't
>>> want to have a service disruption compared to IPv4 when
>>> IPv6-only connectivity is provided to their customers.
>>
>> I agree about the criticality of IPv4 apps when IPv6-only
>> connectivity is in place.
>>
> Because whether it exists today, or not, that's the goal we are
> working toward.  It's far too late to be designing things based on
> some assumption that IPv6-only connectivity doesn't have to actually
> work anyway.  The ultimate goal is IPv6-only connectivity for the
> masses, and if we make no other assumptions, we ought to be able to
> start with the assumption that at least works to all internet
> connected IPv6 endpoints.

Yes, I agree with the goal.  But I think it is too early to think
IPv6-only for the masses.

I talk to a number of professional deployers and the majority is still
questioning the necessity of IPv6.

>> Nobody but some ultra-geek do this IPv6-only today.

Sorry, didnt mean to hurt anyone's feelings.  Geek is said with respect.

One must be ultra-geek to turn off her IPv4 stack.  Have you tried?

>> Even if the operator's network is IPv6 only, it should have means
>> to translate between v4 and v6 at its edges, such as to show pure
>> IPv4 and pure IPv6 t user.
>>
>
> I think we should stay away from assumptions like this.

But 464xlat/clat is already doing translation. Except that it does
translation only on one edge and on the terminal.  It should have done
translation on both edges and let the terminal free of not implementing
CLAT.

> If no one is going to mandate that all ISPs MUST provide IPv6
> connectivity, (and that hasn't happened yet), then it doesn't seem
> like we can make assumptions about where the translation needs to
> happen.

I agree with you, IPv6 must be recommended.  But there several types in 
which to bring IPv6 in.  Some are smoother than others.

In the case I struggle with, in the current situation (CLAT required on 
the terminal), I will be forced to recommend and use an IPv4-only APN 
type, and leave IPv6 for a few years later.

The end users will not even have a chance to see an RA coming from the 
network and their Windows end-systems naturally self-configure an address.

The end user does not want IPv6, the backend system does not want to 
provide IPv6.  Only the cellular system imposes IPv6.

Alex

---

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 15 Feb 2015 21:01:59 +0100

> talking to numeric IPv4 addresses a way to do so.

Yes, I realized that, thanks for noting.  Except that it seems not only 
464xlat is required in the network, but also CLAT (TAYGA daemon?) is 
required on the end user terminal for ping v4-literal to work.

This CLAT is conflicting with other requirements.

In an IPv4-only world CLAT does not exist.

> Applications that use DNS and modern socket APIs do not need 464xlat,

Yes.

But there are apps that dont rely on DNS and no modern socket APIs. 
This functionality is replaced by SDN if you wish.

The apps I talk about are largely deployed.  They won't migrate to IPv6 
soon, it's not on the immediate product roadmap.  The hurdles are with 
making the app work, dont need additional burden of IPv4-or-IPv6 debates.

The network should be smooth in this respect.

Alex

---

---

From: Erik Kline <[email-masked]>
Date: Mon, 16 Feb 2015 12:49:42 +0900

Overall, I think what this document wants is to become an update to
something like https://www.ripe.net/ripe/docs/ripe-554 (or similar).
I don't think this is really an IETF operational document--mostly it
strikes me as fairly weak tea.

-----

* I really don't see that section 2.1 has any business being in this
document, and I would strike it altogether.

* Section 3, A_REC#2: I personally don't see any justification for PCP
support as pertains to IPv6.  The documented justification seems to be
about power savings w.r.t. NAT--not a v6ops thing, as far as I can
see.  Even if the document means to say that mobile nodes doing NAT64
need to support PCP for IPv4 communications, well I still don't see
the point of that.  I would remove this part.

* Section 3, A_REC#3: I think this should have been be phrased more
like "mobile nodes that perform DNSSEC validation AND perform some
kind of NAT64 must are advised to...", if it weren't for that fact
that it then falls into the "generally obvious" category.  I'd remove
it.

* Section 3, A_REC#4 seems to take RFC 6555 section 5.2 "MAY"
behaviour and tries to make it "should".  It also specifies some
"must" behaviour for DNS recursion libraries that I don't think we've
seen before, that I suspect DNS folks should review, and that I don't
think we really need.  I'd strike this section altogether too.

* Section 3, L_REC#1,#2,#3,#4:  All of these seem to be just
"deployments of type A must implement RFCs that specify type A
protocols/operations".  These seem obvious, don't add anything new or
useful, and I would strike them all.

I think by the time you remove all the non-useful sections there won't
be much left.

---

From: <[email-masked]>
Date: Mon, 16 Feb 2015 06:42:50 +0000

Hi Alex,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alexandru Petrescu [mailto:[email-masked]] 
Envoyé : vendredi 13 février 2015 17:13
À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

> avoiding consumers having to change APNs.

In my understanding 464xlat/clat are trials these days.

[Med] No, it is in use in live networks, including within our Group.

  They could be 

[Med] If all applications are AF-independent (including IPv4 referrals are not in use or address synthesis a la RFC6052 is supported), then CLAT can be avoided. Some operators want to adopt an IPv6-only connectivity mode but with a condition to provide the same level of service as IPv4; For those CLAT is even a must. It might happen that other operators can judge that the broken applications under an IPv6-only mode + NAT64 are not important; for those CLAT is not needed. These reasons, among others, are why we set the language to 'should'. 

[Med] All those are no options in the mobile context. IPv6-only + NAT64 is the mode that is currently adopted by several operators.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 16 Feb 2015 11:23:05 +0100

* Alexandru Petrescu

> Except that the 464xlat networks I am aware of to only "IPv6" kind of

«464XLAT networks» doesn't really exist. The provider's network is
simply IPv6-only, in addition to offering Stateful NAT64 (RFC6146) in
addition to provisioning the customer with a DNS64-enabled resolver
(RFC6147).

464XLAT exists entirely inside the customer's device. In other words,
the operator does not need to configure or provision anything beyond
Stateful NAT64 + DNS64 for 464XLAT to function. Stateful NAT64 + DNS64
works just fine without 464XLAT as well, only that IPv4 literals do not
work, nor does applications that does not use DNS or that hard-code the
use of AF_INET network sockets.

> IPv6-only kind of type, and 464xlat/clat is given as reason why.

I think you've got this the wrong way around. 464XLAT was developed to
make the IPv6-only APN type work well enough for the general populace.
At that point the IPV4V6 APN type didn't really work well enough because
it was too new and poorly supported, while the IPV6 type is older and
is well supported.

With the advent of LTE networks, this situation is changing. My own
provider Telenor is now moving from IPV6+v4CGN(NAT64/DNS64)+464XLAT to
IPV4V6+v4CGN(NAT44), for example. I guess the biggest advantage of this
latter approach is that it works with Apple devices.

Tore

---

From: "Heatley, Nick" <[email-masked]>
Date: Mon, 16 Feb 2015 10:42:52 +0000

With the advent of LTE networks, this situation is changing. My own provider Telenor is now moving from IPV6+v4CGN(NAT64/DNS64)+464XLAT to
IPV4V6+v4CGN(NAT44), for example. I guess the biggest advantage of this
latter approach is that it works with Apple devices.

[Heatley, Nick] And don't forget the disadvantage, you officially have 20M unique IPv4 addresses on the inside, before private address exhaustion means you have to look for another network cludge.
No need for IPv4 with 464XLAT.

Tore

NOTICE AND DISCLAIMER

EE Limited

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Mon, 16 Feb 2015 10:47:45 +0000

Hi,
IPv6-only + CLAT+NAT64(no dns64) is used in Orange Poland - somewhere~ 30% mobile users. You won't see this in worldwide IPv6 stats {"No." of IPv6 users are measured form traffic -ipv4/ipv6 - typical mobile user (smartphone) generates up to 6 times lower traffic comparing to lines users..} 

Assuming our experience:
1. The best for mobile nowadays is CLAT+PLAT+DNS 
*One path for IPv4 traffic (always via CLAT)
*ALG’s treated as NAT44
*IPv4 literal & domain use same path
*One path for IPv6 traffic (native IPv6)
*Motivation for native IPv6 content
*Application address family independent
*65% - traffic from subscribers is native IPv6
*Google Nexus, Sony,HTC, Samung,LG, WindowsPhone, supports CLAT.

Cheers,
tk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 16, 2015 7:43 AM
To: Alexandru Petrescu; Heatley, Nick
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Hi Alex,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alexandru Petrescu [mailto:[email-masked]]
Envoyé : vendredi 13 février 2015 17:13
À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN Cc : [email-masked] Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Le 13/02/2015 16:33, Heatley, Nick a écrit :
> 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.

  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.

E.g. 464lat/clat to run on an operator-controlled network device, not on end-user terminal.

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.

---

From: Gert Doering <[email-masked]>
Date: Mon, 16 Feb 2015 11:49:36 +0100

Hi,

> IPv6-only kind of type, and 464xlat/clat is given as reason why.

Care to elaborate?  I do not know of a single case of a 3G/4G network
moving from IPv4IPv6 to IPv6-only.

Some deploy dual-stack, some deploy single-stack, and all for good
reasons - but this is something different than "move to IPv6-only"

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2015 11:54:41 +0100

Le 16/02/2015 11:23, Tore Anderson a écrit :
[...]
> 464XLAT exists entirely inside the customer's device.

What is the name of the software that must exist inside the customer's
device?

> In other words, the operator does not need to configure or provision
>  anything beyond Stateful NAT64 + DNS64 for 464XLAT to function.

But it seems to mandate "464XLAT" to exist inside the customer's device,
for IPv4-literals, and for non-DNS-based apps.

> Stateful NAT64 + DNS64 works just fine without 464XLAT as well, only
>  that IPv4 literals do not work, nor does applications that does not
>  use DNS or that hard-code the use of AF_INET network sockets.

Ok!

I think that an IPv4 access for which IPv4 literals dont work and where
apps MUST use DNS, is not really an IPv4 access.

> I think you've got this the wrong way around. 464XLAT was developed
> to make the IPv6-only APN type work well enough for the general
> populace.

Ok.

I also heard that 464XLAT was imported into the cellular world from DSL 
IPv6 deployments.

> At that point the IPV4V6 APN type didn't really work well enough
> because it was too new and poorly supported, while the IPV6 type is
> older and is well supported.

I can understand that.  The IPv4IPv6 access I used worked just fine for
my applications.  It was 3G+ only, not LTE, but it worked excellent.

> With the advent of LTE networks, this situation is changing.

I can understand that.  LTE networks bring in high bandwidth; but from
the networking point of view there is reason to fear regression (no
more publicly routable IPv4 addresses, no more ping 8.8.8.8, apps must
use DNS, etc).

> My own provider Telenor is now moving from
> IPV6+v4CGN(NAT64/DNS64)+464XLAT to IPV4V6+v4CGN(NAT44), for example.
>  I guess the biggest advantage of this latter approach is that it
> works with Apple devices.

I guess this move is promissing, thanks for mentioning it.

Using IPV4V6 may allow not only Apple devices but may enable more
devices beyond smartphones: machine-class devices and in general all
computers small or large which connect through a dedicated LTE USB key,
or smarter 4G modules.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2015 12:27:40 +0100

Le 16/02/2015 11:47, Kossut Tomasz - Hurt a écrit :
> Hi, IPv6-only + CLAT+NAT64(no dns64) is used in Orange Poland -
> somewhere~ 30% mobile users. You won't see this in worldwide IPv6
> stats {"No." of IPv6 users are measured form traffic -ipv4/ipv6 -
> typical mobile user (smartphone) generates up to 6 times lower
> traffic comparing to lines users..}
>
> Assuming our experience:

Hi,

Thank you for the report. It is good to see how good consideration is
given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having
embraced the CLAT technology.

Is the network considering Machine-class devices (M2M)? For example
Sierra Wireless Airprime?

More than the typical smartphone users (yes, it represents already a
large market) is the LTE network considering connections from more
dedicated settings like: connected public transportation, home
electricity counters, electric vehicle charging stations, harbour
installations, connected roads?

These dedicated settings look up to wireless LTE access networks as good
hope to get on the Internet, especially in areas where land lines are
too expensive to deploy.

Alex

---

From: Tore Anderson <[email-masked]>
Date: Mon, 16 Feb 2015 12:45:46 +0100

* Alexandru Petrescu

> What is the name of the software that must exist inside the customer's

"CLAT". The device located in the provider's network, the "PLAT", is
really nothing but a completely standard Stateful NAT64.

> But it seems to mandate "464XLAT" to exist inside the customer's
> device, for IPv4-literals, and for non-DNS-based apps.

If you want IPv4 literals to work, you'll need the CLAT, yes. However,
the operator cannot really control this - if you have a device that
supports the IPV6 APN type, but no CLAT/464XLAT support, then you can
connect to the network just fine. You'll have access to IPv4-only
websites etc. through the provider's DNS64/NAT64, but you won't have
access to IPv4 literals.

The only control the network operator has here, is that it can ensure
that all the operator-branded devices it sells in its own store do
support 464XLAT (i.e., by containing a CLAT). If you bring your own
device bought from somewhere else, however, the operator has no way of
knowing if your device contains a CLAT or not.
 
> I also heard that 464XLAT was imported into the cellular world from
> DSL IPv6 deployments.

No, 464XLAT was designed specifically for mobile networks. I've never
heard of any DSL/wireline deployment that uses it (although it is
certainly technically possible).

> more publicly routable IPv4 addresses, no more ping 8.8.8.8, apps must

I think the need to support IPv4 literals and apps not using DNS
remains with LTE; the actual change is that LTE networks and devices
conform to newer 3GPP releases which include the IPV4V6 APN type.
Thus, devices and networks generally support it. Using IPV4V6, an
operator can provision the handset with both IPv4 and IPv6 addresses,
ensuring that IPv4 literals work - without requiring a CLAT. (As Nick
pointed out, RFC1918/RFC6598 exhaustion might still be an issue for
very large operators though.)

Tore

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2015 13:17:05 +0100

Le 16/02/2015 12:45, Tore Anderson a écrit :
> * Alexandru Petrescu
>
>> What is the name of the software that must exist inside the
>> customer's device?
>
>>> In other words, the operator does not need to configure or
>>> provision anything beyond Stateful NAT64 + DNS64 for 464XLAT to
>>> function.
>>
> If you want IPv4 literals to work, you'll need the CLAT, yes.
> However, the operator cannot really control this - if you have a
> device that supports the IPV6 APN type, but no CLAT/464XLAT support,
>  then you can connect to the network just fine. You'll have access to
>  IPv4-only websites etc. through the provider's DNS64/NAT64, but you
>  won't have access to IPv4 literals.

Ok.  But one would agree that access to websites is not access to
the Internet.

> The only control the network operator has here, is that it can
> ensure that all the operator-branded devices it sells in its own
> store do support 464XLAT (i.e., by containing a CLAT).

Ok, the operator may control these devices.

But some operators sell also SIM cards to put in other devices than
smartphones (to put in cars, for example), or in other devices than the
operator-controlled devices.

There would be little possibility for these operators to hope imposing
CLAT on each and every device connecting to 4G.

> If you bring your own device bought from somewhere else, however, the
> operator has no way of knowing if your device contains a CLAT or
> not.

Yes.  And at that point that particular operator no longer offers IPv4
literal access and some IPv4 applications will not work.

>> I also heard that 464XLAT was imported into the cellular world
>> from DSL IPv6 deployments.
>
> No, 464XLAT was designed specifically for mobile networks. I've
> never heard of any DSL/wireline deployment that uses it (although it
> is certainly technically possible).
>
>> I can understand that.  LTE networks bring in high bandwidth; but
>> from the networking point of view there is reason to fear
>> regression (no more publicly routable IPv4 addresses, no more ping
>>  8.8.8.8, apps must use DNS, etc).
>
> operator can provision the handset with both IPv4 and IPv6
> addresses, ensuring that IPv4 literals work - without requiring a
> CLAT. (As Nick pointed out, RFC1918/RFC6598 exhaustion might still be
> an issue for very large operators though.)

I think IPV4V6 is something good.  Many end devices support IPV4V6
out of the box - it's a below-IP feature.  But CLAT is an IP feature,
not in the kernel, and is something that has to be added, potentially in
conflict with other IP features like openvpn and mobile ip.

Yes I read point saying 20million addresses may be too small (a 10.x
class A supposedly); it is possible.  But several private class As are
afforded with multiple NATs or VPNs.  Address architecture problems
similar to this are common outside the cellular world: e.g. multi-site
international corporations on landlines; yet none uses 464XLAT, and none
enforces the end user terminal to implement NAT, CLAT, VPN.

IPv6 is independent of IPv4 and vice-versa.

Alex

---

From: Gert Doering <[email-masked]>
Date: Mon, 16 Feb 2015 13:24:40 +0100

Hi,

> literal access and some IPv4 applications will not work.

You *might* have heard about upcoming IPv4 exhaustion, and IPv4 going
away in the long run.

Brain cycles are spent way better on ensuring IPv6 works on new products
and service offerings than on complaining that specific application 
niches of IPv4 usage (read: applications that do not want to use DNS
and IP agnostic socket APIs) will break.

Yes, they will.  We all know that, but they will still break one day.

Get over it.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2015 13:35:03 +0100

> You *might* have heard about upcoming IPv4 exhaustion, and IPv4 going

Gert - let me clarify.  YEs, I know IPv4 exhaustion.  YEs, in the long 
run IPv4 disappears.

> and IP agnostic socket APIs) will break.

No.

What is niche for some is billion-making for others.

End-user products have independent roadmaps than the network.

This is a transition phase.  We need to bring in IPv4 deployments.  It 
should happen smoothly - IPv4 should be there as before and also is this 
IPv6.  It's up to the end user to switch to IPv6 when s/he feels like; 
it's not up to the network to impose this change.

Any transition scheme which requires effort from the end user (either 
upward transition, or retro-compatibility transition) is non inspiring.

Alex

---

From: Gert Doering <[email-masked]>
Date: Mon, 16 Feb 2015 13:52:28 +0100

Hi,

On Mon, Feb 16, 2015 at 01:35:03PM +0100, Alexandru Petrescu wrote:
> This is a transition phase.  We need to bring in IPv4 deployments.  

I don't think you understand the role of the IETF, or of the *v6*ops WG.

*We* are not here to make billions, or to help legacy technology survive
the attempt to resist the future.

There is v4sunset and other working groups where your contributions are
certainly welcome, but here, you're just barking up the wrong tree.

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2015 14:01:52 +0100

Ok.

> certainly welcome, but here, you're just barking up the wrong tree.

Ok, it's rather an argumented complain than a contribution proper.

What do you think of draft-ietf-v6ops-mobile-device-profile-17.txt?

Alex

---

From: <[email-masked]>
Date: Mon, 16 Feb 2015 13:47:32 +0000

Hi Alex, 

Based on the discussion in this thread, I don't think there is a justification to change the wording for this recommendation... but I understood you have some issues with CLAT being a hurdle to have AF-applications. What about the following change?

OLD:

NEW:

                CLAT function in the cellular host allows for IPv4-only
                application and IPv4-referals to work on an IPv6-only
                connectivity.  The more applications are address family
                independent, the less CLAT function is solicited.
                CLAT function requires a NAT64 capability [RFC6146] in
                the network.

                The activation of the CLAT function does not interfere
                with native IPv6 communications.

BTW, do you think a modification is needed for L_REC#4:

   L_REC#4:  In order to ensure IPv4 service continuity in an IPv6-only
             deployment context, the cellular device should support the
             Customer Side Translator (CLAT) [RFC6877].

                Various IP devices are likely to be connected to
                cellular device, acting as a CPE.  Some of these devices
                can be dual-stack, others are IPv6-only or IPv4-only.
                IPv6-only connectivity for cellular device does not
                allow IPv4-only sessions to be established for hosts
                connected on the LAN segment of cellular devices.

                In order to allow IPv4 sessions establishment initiated
                from devices located on LAN segment side and target IPv4
                nodes, a solution consists in integrating the CLAT
                function in the cellular device.  As elaborated in
                Section 2, the CLAT function allows also IPv4
                applications to continue running over an IPv6-only host.

Thank you.

Cheers,
Med

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de Alexandru Petrescu
Envoyé : lundi 16 février 2015 13:35
À : Gert Doering
Cc : [email-masked]; Tore Anderson
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

No.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2015 15:51:30 +0100

Le 16/02/2015 14:47, [email-masked] a écrit :
> Hi Alex,
>
> Based on the discussion in this thread, I don't think there is a
> justification to change the wording for this recommendation... but I
>  understood you have some issues with CLAT being a hurdle to have
> AF-applications. What about the following change?

Hello Med,

Thank you for the suggestion of better text.

> [RFC6052][RFC6145][RFC6146].

I disagree with that SHOULD.  It should be a MAY.  It should be
accompanied by all other mechanisms achieving the same, like tunnelling.

> and IPv4-referals to work on an IPv6-only connectivity.  The more
> applications are address family independent, the less CLAT function
> is solicited.

YEs, I agree with the more AF-independence, the less CLAT-requirement.

In addition, now reading it, I am afraid it may be circular.  I think
CLAT itself is not AF-independent and makes use of IPv4 and IPv6
literals. As such, it can't pretend to be a panacea solution to
IPv4-referral use.

I think this could be re-written:

>> Functions like CLAT and tunnelling in the Computer MAY allow for
>> IPv4-only applications using IPv4-referals (literals), and
>> applications not relying on DNS resolution, to still work when the
>> computer has only an IPv6 connection.  Note that setting up the
>> CLAT function itself does not rely on DNS and makes use of IPv4
>> and IPv6 literals.  The more the applications are AF-independent,
>> and more reliance on DNS, the less the functions like CLAT (or
>> tunnelling) are solicited.

> CLAT function requires a NAT64 capability [RFC6146] in the network.
>
> The activation of the CLAT function does not interfere with native
> IPv6 communications.

One should also consider:
- activation with CLAT interferes with native IPv4 communications.
- CLAT software itself involves manual configuration by way of literals
   IPv4 and IPv6.

For these reasons, I do not understand why making CLAT a SHOULD on the
end-user device.

One could write that CLAT may be used by some users in need of _some_
kind of IPv4 Internet connectivity, and that IPv4 connectivity is
limited in nature (interferes with some IPv4 applications, etc.)

> deployment context, the cellular device should support the Customer
> Side Translator (CLAT) [RFC6877].

On one hand, this makes think that if the end user device implements
CLAT then IPv4 access is fine.  It is not: one still has to use literals
to configure CLAT itself.

On another hand, there are several other ways in which better IPv4
access can be obtained when connecting to a v6-only access, and which do
not use CLAT nor address translation: for example tunnelling, Mobile IP,
VPN.

For these reasons, L_REC#4 could be a "MAY" only.

Also, the notion of "service continuity" could be understood as "session
continuity" - using Mobile IP.  Maybe one should clarify what is meant
by this continuity.

> Various IP devices are likely to be connected to cellular device,
> acting as a CPE.

I agree.

The cellular device is rather a 'cellular interface'.

'CPE' - Customer PRemisses Equipment - makes sense in fixed home/office
context, but when deployed out in the field, where there is no customer,
one would call it just a Router.  Or anything else but a CPE.

> Some of these devices can be dual-stack, others are IPv6-only or
> IPv4-only. IPv6-only connectivity for cellular device does not allow
>  IPv4-only sessions to be established for hosts connected on the LAN
>  segment of cellular devices.

Right.  Except that 'cellular devices' are actually cellular interfaces.
  I may have several cellular interfaces on a same unique Router, for
bandwidth augmentation.

> In order to allow IPv4 sessions establishment initiated from devices
>  located on LAN segment side and target IPv4 nodes, a solution
> consists in integrating the CLAT function in the cellular device. As

HEre instead of cellular device I would rather think "the Router on
which that cellular interface connects"

> elaborated in Section 2, the CLAT function allows also IPv4
                                   ^through          ^Router

YEs, I agree, that is one solution.  But it is just one.  It is not a
SHOULD because there are other solutions equally well qualified as CLAT.

If I were to use a SHOULD I would say that "an operator/equipmentvendor
should not enforce CLAT on the end user device."

Alex

> Envoyé : lundi 16 février 2015 13:35 À : Gert Doering Cc :
> [email-masked]; Tore Anderson Objet : Re: [v6ops] I-D Action:
>>> Yes.  And at that point that particular operator no longer offers
>>> IPv4 literal access and some IPv4 applications will not work.
>>
>> You *might* have heard about upcoming IPv4 exhaustion, and IPv4
>> going away in the long run.
>
> Gert - let me clarify.  YEs, I know IPv4 exhaustion.  YEs, in the
> long run IPv4 disappears.
>
>> Brain cycles are spent way better on ensuring IPv6 works on new
>> products and service offerings than on complaining that specific
>> application niches of IPv4 usage (read: applications that do not
>> want to use DNS and IP agnostic socket APIs) will break.
>
> No.
>
> It should happen smoothly - IPv4 should be there as before and also
> is this IPv6.  It's up to the end user to switch to IPv6 when s/he
> feels like; it's not up to the network to impose this change.
>
> Any transition scheme which requires effort from the end user
> (either upward transition, or retro-compatibility transition) is non
>  inspiring.
>
> Alex
>
>
>>
>> Gert Doering -- NetMaster
>>
>
>

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Wed, 18 Feb 2015 11:13:24 +0000

Hi,

Inline comments:

Hi,

Thank you for the report. It is good to see how good consideration is given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having embraced the CLAT technology.

(tk) - this is not only CLAT, (CLAT is in generic Android thanks to Lorenzo, Cameron, Dan & others) each vendor has its own customization based on MCCMNC/region to control "features" per operator. In our case we have :  dedicated clatd.conf (not generic one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS) EIT bit =1, moreover together with Samsung we developed "IPv6 patch" for Download Booster (Samsung feature to aggregate your LTE+WIFI connection for http download - now it works in Ipv6 networks with no DNS64 like Orange Poland ) 

Is the network considering Machine-class devices (M2M)? For example Sierra Wireless Airprime? 
Not really - we are working with one of the vendor to deliver IPv6 (CLAT) router expected in H1/15

More than the typical smartphone users (yes, it represents already a large market) is the LTE network considering connections from more dedicated settings like: connected public transportation, home electricity counters, electric vehicle charging stations, harbour installations, connected roads?

Yes, we are technically ready to create "IPv6 matrix" 

These dedicated settings look up to wireless LTE access networks as good hope to get on the Internet, especially in areas where land lines are too expensive to deploy.
LTE450 -in Brasil, LTE800 - Europe

Cheers,
tk

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Monday, February 16, 2015 12:28 PM
To: Kossut Tomasz - Hurt; BOUCADAIR Mohamed IMT/OLN; Heatley, Nick
Cc: [email-masked]; Czerwonka Michał 1 - Hurt
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

Le 16/02/2015 11:47, Kossut Tomasz - Hurt a écrit :
> typical mobile user (smartphone) generates up to 6 times lower traffic 
> comparing to lines users..}
>
> Assuming our experience:
> 1. The best for mobile nowadays is CLAT+PLAT+DNS *One path for IPv4 
> traffic (always via CLAT) *ALG’s treated as NAT44
> *One path for IPv6 traffic (native IPv6) *Motivation for native IPv6 
> content *Application address family independent *65% - traffic from 
> subscribers is native IPv6 *Google Nexus, Sony,HTC, Samung,LG, 
> WindowsPhone, supports CLAT.

Hi,

Thank you for the report. It is good to see how good consideration is given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having embraced the CLAT technology.

Is the network considering Machine-class devices (M2M)? For example Sierra Wireless Airprime?

More than the typical smartphone users (yes, it represents already a large market) is the LTE network considering connections from more dedicated settings like: connected public transportation, home electricity counters, electric vehicle charging stations, harbour installations, connected roads?

These dedicated settings look up to wireless LTE access networks as good hope to get on the Internet, especially in areas where land lines are too expensive to deploy.

Alex

> Envoyé : vendredi 13 février 2015 17:13 À : Heatley, Nick; BOUCADAIR 
> Mohamed IMT/OLN Cc : [email-masked] Objet : Re: [v6ops] I-D Action: 
>> an

---

From: "Metzler, Dan J" <[email-masked]>
Date: Wed, 18 Feb 2015 12:56:29 +0000

> Sent: Sunday, February 15, 2015 1:56 PM
> To: Metzler, Dan J; [email-masked]; Heatley, Nick
> Cc: [email-masked]
> >>> Some operators are seeing CLAT as critical because they don't want
> >>> to have a service disruption compared to IPv4 when IPv6-only
> Yes, I agree with the goal.  But I think it is too early to think IPv6-only for the
> masses.

In this group, it is too late not to think IPv6-only for the masses.  We past that point long ago.  Certainly, we aren't ready to stop thinking about transition technologies.

> questioning the necessity of IPv6.

I think you're suggesting that, since the majority of a few selected "professional deployers", are still questioning the necessity of IPv6, that v6ops should not be worried about IPv6 only actually working?  That doesn't make much sense.  
Our job at this point should be:
1) Make sure IPv6 works, and works better than IPv4.  (If we don't do this first, then there is no reason for number 2.)
2) Make sure there is a good and effective working long term migration path to get from IPv4 only to IPv6 only.

Without number 1, number 2 is not a viable option that I'm aware of.

> >> translate between v4 and v6 at its edges, such as to show pure
> But 464xlat/clat is already doing translation. Except that it does translation
> only on one edge and on the terminal.  It should have done translation on
> both edges and let the terminal free of not implementing CLAT.
> 
> I agree with you, IPv6 must be recommended.  But there several types in which
> to bring IPv6 in.  Some are smoother than others.
> 
> In the case I struggle with, in the current situation (CLAT required on the
> terminal), I will be forced to recommend and use an IPv4-only APN type, and
> leave IPv6 for a few years later.
> 

What do you mean by backend system?

The end user usually does not "want" IPv4, but we still gave it to them.  That the end user "does not want IPv6" is a questionable statement in light of the current state of the internet.  The end user really wants the Internet, and that's as far as it goes.  The typical end user is unaware of what they want at layer 3, because they tend not to look below layer 7.  The reality is, either the end user wants to run out of IPv4 addresses, or they want IPv6.  (They just might not be aware of it yet.)

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2015 13:56:52 +0100

> moreover together with Samsung we developed "IPv6 patch" for Download
> Booster (Samsung feature to aggregate your LTE+WIFI connection for
> http download -

This is a very useful feature.  I wonder whether the augmented bandwidth
concerns a single http connection, or several?  (there is a difference
between single connection enjoying its bandwidth augmented when an
interface is added, and pipelined http connections not disturbing each
other when several interfaces are added).

I am asking because two reasons.  One is that I have seen demos where
bandwidth is not really augmented, yet pipelined http apps give a better
feeling when multiple interfaces are used.

The other reason is that at IETF there are some activities about
bandwidth augmentation which may be interested in Download Booster.

In the MIF Working Group there is a bandwidth augmentation activity in
relationship to the BroadBand Forum: add a cellular interface to a DSL
box hoping to add bandwidth, and improve fail-over.

In the Mobile IPv4 Working Group there is a
draft-ietf-mip4-multiple-tunnel-support which may try to achieve the
same, and an RFC for samein IPv6.

> now it works in Ipv6 networks with no DNS64 like Orange Poland )

It is encouraging :-)

> Sierra Wireless Airprime? Not really - we are working with one of the
> vendor to deliver IPv6 (CLAT) router expected in H1/15
>
> These dedicated settings look up to wireless LTE access networks as
> good hope to get on the Internet, especially in areas where land
> lines are too expensive to deploy.
>

Ok, it is good to know.  For the moment we consider LTE2600 which is
also useful in remote areas, until LTE800 comes alive.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2015 13:57:18 +0100

Hi,

Le 18/02/2015 12:13, Kossut Tomasz - Hurt a écrit :
> Hi,
>
> Inline comments:
>
> Hi,
>
> Thank you for the report. It is good to see how good consideration
> is given to IPv6, and the two separated paths IPv4/IPv6.
>
> (tk) - this is not only CLAT, (CLAT is in generic Android thanks to
> Lorenzo, Cameron, Dan & others) each vendor has its own
> customization based on MCCMNC/region to control "features" per
> operator. In our case we have :  dedicated clatd.conf (not generic
> one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS)

It's good to see these mentioned.

For tethering - is the network offering DHCPv6 Prefix Delegation
service?  Or is the device performing '64share' RFC7278?

There are some advantages on doing the former rather than the latter.

> EIT bit =1,

What is the EIT bit?

Alex

> Cheers, tk
> [mailto:[email-masked]] Sent: Monday, February 16,
> 2015 12:28 PM To: Kossut Tomasz - Hurt; BOUCADAIR Mohamed IMT/OLN;
> Heatley, Nick Cc: [email-masked]; Czerwonka Michał 1 - Hurt Subject:
>> Assuming our experience: 1. The best for mobile nowadays is
>> CLAT+PLAT+DNS *One path for IPv4 traffic (always via CLAT) *ALG’s
>> treated as NAT44 *IPv4 literal & domain use same path *One path
>> for IPv6 traffic (native IPv6) *Motivation for native IPv6 content
>>  *Application address family independent *65% - traffic from
> Thank you for the report. It is good to see how good consideration
> is given to IPv6, and the two separated paths IPv4/IPv6.
>
>> Cheers, tk
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] Sent: Monday, February 16,
>> 2015 7:43 AM To: Alexandru Petrescu; Heatley, Nick Cc:
>> [email-masked] Subject: Re: [v6ops] I-D Action:
>> 2015 17:13 À : Heatley, Nick; BOUCADAIR Mohamed IMT/OLN Cc :
>>> [mailto:[email-masked]] Sent: 13 February 2015
>>> 14:35 To: Heatley, Nick; [email-masked] Cc:
>>> [email-masked] Subject: Re: [v6ops] I-D Action:
>>>> 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 :-))
>>>
>>> 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.
>>
>> 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.
>>
>> [Med] If all applications are AF-independent (including IPv4
>> referrals are not in use or address synthesis a la RFC6052 is
>> supported), then CLAT can be avoided. Some operators want to adopt
>> an IPv6-only connectivity mode but with a condition to provide the
>> same level of service as IPv4; For those CLAT is even a must. It
>> might happen that other operators can judge that the broken
>> applications under an IPv6-only mode + NAT64 are not important;
>> for those CLAT is not needed. These reasons, among others, are why
>> we set the language to 'should'.
>>
>>> [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?
>>
>> [Med] All those are no options in the mobile context. IPv6-only +
>> NAT64 is the mode that is currently adopted by several operators.
>>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2015 14:37:32 +0100

Le 18/02/2015 13:56, Metzler, Dan J a écrit :
>> [mailto:[email-masked]] Sent: Sunday, February 15,
>> 2015 1:56 PM To: Metzler, Dan J; [email-masked];
>> Heatley, Nick Cc: [email-masked] Subject: Re: [v6ops] I-D Action:
>>>> [mailto:[email-masked]] On Behalf Of Alexandru
>>>> Petrescu Sent: Friday, February 13, 2015 10:59 AM To:
>>> working toward.  It's far too late to be designing things based
>>> on some assumption that IPv6-only connectivity doesn't have to
>>> actually work anyway.  The ultimate goal is IPv6-only
>>> connectivity for the masses, and if we make no other assumptions,
>>> we ought to be able to start with the assumption that at least
>>> works to all internet connected IPv6 endpoints.
>>
> In this group, it is too late not to think IPv6-only for the masses.
>  We past that point long ago.  Certainly, we aren't ready to stop
> thinking about transition technologies.

I think IPv6-only for the masses is too early to plan for.  Most
notably I dont think linux platforms(2.x to 3.x) ready to turn
off their IPv4 stacks.

YEs, there could be a geeky Android out there not segfaulting upon IPv4
disable, but we're way away from devices sold at large which dont
support IPv4.  Nobody will buy a tablet without IPv4 an stack - it's 
perceived as a miss-feature: can't connect to all networks.  It's as 
when I naïvely bought a smartphone without WCDMA thinking I'd never go 
to Korea, or that 4G solves it - it's no and no.

Transition technologies: yes, but maybe we can learn from some of the
past IPv4-IPv6 transition methods.

Maybe the easiest transition is to offer both IPv4 and IPv6 to end user
and let her decide when to switch.

>> I talk to a number of professional deployers and the majority is
>> still questioning the necessity of IPv6.
>
> I think you're suggesting that, since the majority of a few selected
>  "professional deployers", are still questioning the necessity of
> IPv6, that v6ops should not be worried about IPv6 only actually
> working?

Right, no.  I suggest v6ops activities are well on track.  I disagree 
though with thinking an IPv6-only access is necessary today.

> That doesn't make much sense. Our job at this point should be: 1)
> Make sure IPv6 works, and works better than IPv4.

Agree with point 1.  But disagree to making it better than IPv4 (other
than the larger address space).

There is some time spent in migrating features from IPv6 back
to IPv4.  There is also resistance from IP deployers due to IPv6 being
so different than IPv4.

> (If we don't do this first, then there is no reason for number 2.) 2)
> Make sure there is a good and effective working long term migration
> path to get from IPv4 only to IPv6 only.
>

I agree with you about the long term towards IPv6.  It's just the near
term that I disagree with.  I think one is safe to plan for some good
years of side-by-side IPv4-IPv6 access.

>>>> Even if the operator's network is IPv6 only, it should have
>>>> means to translate between v4 and v6 at its edges, such as to
>>>> show pure IPv4 and pure IPv6 t user.
>>>>
>>>
>>  translation only on one edge and on the terminal.  It should have
>>  done translation on both edges and let the terminal free of not
>> implementing CLAT.
>>
>>> connectivity, (and that hasn't happened yet), then it doesn't
>>> seem like we can make assumptions about where the translation
>>> needs to happen.
>>
>> I agree with you, IPv6 must be recommended.  But there several
>> types in which to bring IPv6 in.  Some are smoother than others.
>>
>> In the case I struggle with, in the current situation (CLAT
>> required on the terminal), I will be forced to recommend and use an
>> IPv4-only APN type, and leave IPv6 for a few years later.
>>
>> The end users will not even have a chance to see an RA coming from
>>  the network and their Windows end-systems naturally self-configure
>>  an address.
>>
>> The end user does not want IPv6, the backend system does not want
>> to provide IPv6.  Only the cellular system imposes IPv6.
>

Clouds, server farms, services.  (and yes, I know google youtube
facebook are on IPv6).

> The end user usually does not "want" IPv4, but we still gave it to
> them.  That the end user "does not want IPv6" is a questionable
> statement in light of the current state of the internet.  The end
> user really wants the Internet, and that's as far as it goes.  The
> typical end user is unaware of what they want at layer 3, because
> they tend not to look below layer 7.  The reality is, either the end
>  user wants to run out of IPv4 addresses, or they want IPv6.  (They
> just might not be aware of it yet.)

Ok, yes, yes... But.

If by the 'current state of the internet' you mean IPv4 address exhaust...

IPv4 addresses exhaust unless they're NATted.  One wouldn't argue that
IPv6-only is a solution to IPv4 exhaustion; or that 464xlat/clat is such
a solution for that matter.   I suggest neither is a solution to IPv4
exhaust: IPv6-only does not accommodate IPv4 apps and 464xlat/clat
deployments I am aware of use non-routable IPv4 addresses.  In that
sense, NAT is a solution to IPv4 exhaust, as before.

If IPv6-only/464xlat/clat was offering a publicly routable IPv4 address
to the smartphone's AF-dependent literal-using applications - then I
would not complain about IPv6-only/464xlat/clat.

Alex

>> --- L'absence de virus dans ce courrier électronique a été vérifiée
>> par le logiciel antivirus Avast. http://www.avast.com
>

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 14:03:48 +0000

Hi Alex, 

Can you please elaborate on this part? 

I guess by "IPv6-only/464xlat/clat" you mean "IPv6-only/clat/NAT64", no?

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Alexandru Petrescu [mailto:[email-masked]] 
Envoyé : mercredi 18 février 2015 14:38
À : Metzler, Dan J; BOUCADAIR Mohamed IMT/OLN; Heatley, Nick
Cc : [email-masked]
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - rant

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2015 16:08:43 +0100

> I guess by "IPv6-only/464xlat/clat" you mean "IPv6-only/clat/NAT64", no?

464xlat is the same as saying NAT64 two times, no?

I meant to say that the *AT address translation involved in a 
NAT64-and-464XLAT-and-CLAT IPv6-only access network offers an IPv6 
address and a private IPv4 address to the end user.  Right?

Alex

---

From: jouni korhonen <[email-masked]>
Date: Wed, 18 Feb 2015 08:47:05 -0800

> There are some advantages on doing the former rather than the latter.

My wild guess is that it is the ESM information transfer flag bit in the ESM
information transfer flag information element. If it is, it does not really
have anything to do with IPv6 IMHO.

- Jouni

---

From: Ross Chandler <[email-masked]>
Date: Wed, 18 Feb 2015 20:48:08 +0000

> On 18 Feb 2015, at 16:47, jouni korhonen <[email-masked]> wrote:
> 
> 
> 
> On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> My wild guess is that it is the ESM information transfer flag bit in the ESM information transfer flag information element. If it is, it does not really have anything to do with IPv6 IMHO.
> 
> - Jouni

As far as I can tell from a previous answer on v6ops by Orange PL the EIT bit (think it is ESM info transfer flag IE) has an effect when the HSS has a default APN different from the one requested by the UE.  Without the EIT bit set the network doesn’t let the UE requested APN override the default from the HSS, so two PDN connections are set up, one with IPv4 (assuming the default is an IPv4 only APN) and the other IPv6 (assuming that was requested by the UE).  So strictly speaking it does look independent of IP version but it is being noticed as operators introduce IPv6.

Ross

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2015 13:25:02 +1300

> feeling when multiple interfaces are used.

I know nothing about HTTP/2 beyond blog posts and the FAQ, but if they
have done what they say, HTTP/2 will make all this irrelevant.

    Brian

---

From: jouni korhonen <[email-masked]>
Date: Thu, 19 Feb 2015 12:30:37 -0800

I still fail to see how EIT setting relates to IPv6 as a requirement.  It
is a normal procedure when the UE wants to connect (during the initial
attach) to another APN than the default one.

- Jouni

On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler <[email-masked]> wrote:

> As far as I can tell from a previous answer on v6ops by Orange PL the EIT
> bit (think it is ESM info transfer flag IE) has an effect when the HSS has
> a default APN different from the one requested by the UE.  Without the EIT
> bit set the network doesn’t let the UE requested APN override the default
> from the HSS, so two PDN connections are set up, one with IPv4 (assuming
> the default is an IPv4 only APN) and the other IPv6 (assuming that was
> requested by the UE).  So strictly speaking it does look independent of IP
> version but it is being noticed as operators introduce IPv6.
>
> Ross
>
>

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Fri, 20 Feb 2015 11:09:29 +0000

Hi,
IMHO EIT settings should be part of customization – vendor&generic  controlled by (MCCMNC) just like APN settings it has direct impact in HPLMN on IP (IPv4) allocation.

If network has IPv4 default bearer and EIT bit is not enabled in IPv6 terminals it results in default bearer activation and “selected”(IPv6) bearer activation, IPv6 terminal in a network with IPv4 default bearer will always establish 2 bearers. It’s observed in HPLMN for generic Google devices in our network:
vvvvvv CALLID   MSID            USERNAME               IP                                 TIME-IDLE
------ -------- --------------- ---------------------- ----------------------------- ---------
xTC.AT 0c3a069c 26003000000000 n/a                    2a00:f41:XXXX:XXX::4d1d:7001 00h00m02s
xTC.AI 0c3a069c 26003000000000 n/a                    10.000.000.000  00h00m02s

IPv6 subscriber is allocating unwanted IPv4 resource here - this apply to HPLMN only.

For VPLMN (roaming LTE) situation  gets complicated if you choose to use IPv4 for VPLMN (APN settings - use IPv4 when roaming)
Terminal in LTE with EIT bit=1 located in VPLMN will always request “selected” IPv6 bearer for attach (terminal attaching in LTE has no idea whether this is HPLMN or VPLMN) once terminal learned ”I’m in roaming” according to APN settings(use IPv4 when roaming) terminal will establish secondary IPv4 bearer –it results in multiple bearer activation…

Cheers,
TK

From: jouni korhonen [mailto:[email-masked]]
Sent: Thursday, February 19, 2015 9:31 PM
To: Ross Chandler
Cc: Alexandru Petrescu; [email-masked]; Kossut Tomasz - Hurt
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD

I still fail to see how EIT setting relates to IPv6 as a requirement.  It is a normal procedure when the UE wants to connect (during the initial attach) to another APN than the default one.
- Jouni

On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler <[email-masked]<mailto:[email-masked]>> wrote:

On 18 Feb 2015, at 16:47, jouni korhonen <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Inline comments:

Hi,

What is the EIT bit?

Ross

---

From: Ross Chandler <[email-masked]>
Date: Fri, 20 Feb 2015 12:13:24 +0000

It’s unfortunate this wasn’t captured in the roaming-analysis I-D. IMHO it looks like that operators must try harder to sort out their networks and billing mediation systems so IPv6 roaming is allowed.

Ross

> On 20 Feb 2015, at 11:09, Kossut Tomasz - Hurt <[email-masked]> wrote:
> 
> Hi,
> From: jouni korhonen [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Alexandru Petrescu; [email-masked] <mailto:[email-masked]>; Kossut Tomasz - Hurt
> On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler <[email-masked] <mailto:[email-masked]>> wrote:
>  
> On 18 Feb 2015, at 16:47, jouni korhonen <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Feb 2015 13:17:17 +0100

I find the description of the EIT bit (allow multiple APNs, IPv4
and/or IPv6) a tempting feature.

Can the EIT bit be set by using open-source software tools?  For
example, when I connect a linux computer to a 4G network I use
ModemManager and mmcli open source software, on a cheap USB 4G key.

Or is the EIT bit proprietary to one operator and smartphone manufacturer?

Alex

Le 20/02/2015 12:09, Kossut Tomasz - Hurt a écrit :
> Hi,
>
> IMHO EIT settings should be part of customization – vendor&generic
> controlled by (MCCMNC) just like APN settings it has direct impact
> in HPLMN on IP (IPv4) allocation.
>
> If network has IPv4 default bearer and EIT bit is not enabled in
> IPv6 terminals it results in default bearer activation and
> “selected”(IPv6) bearer activation, IPv6 terminal in a network with
> IPv4 default bearer will always establish 2 bearers. It’s observed
> in HPLMN for generic Google devices in our network:
>
> For VPLMN (roaming LTE) situation  gets complicated if you choose to
> use IPv4 for VPLMN (APN settings - use IPv4 when roaming)
>
> Terminal in LTE with EIT bit=1 located in VPLMN will always request
> “selected” IPv6 bearer for attach (terminal attaching in LTE has no
> idea whether this is HPLMN or VPLMN) once terminal learned ”I’m in
> roaming” according to APN settings(use IPv4 when roaming) terminal
> will establish secondary IPv4 bearer –it results in multiple bearer
> activation…
>
> Cheers,
>
> TK
>
> *From:*jouni korhonen [mailto:[email-masked]] *Sent:*
> Thursday, February 19, 2015 9:31 PM *To:* Ross Chandler *Cc:*
> Alexandru Petrescu; [email-masked]; Kossut Tomasz - Hurt *Subject:*
> Re: [v6ops] I-D Action:
> draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD
>
> I still fail to see how EIT setting relates to IPv6 as a
> requirement. It is a normal procedure when the UE wants to connect
> (during the initial attach) to another APN than the default one.
>
> - Jouni
>
> On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu
> My wild guess is that it is the ESM information transfer flag bit in
>  the ESM information transfer flag information element. If it is, it
>  does not really have anything to do with IPv6 IMHO.
>
> - Jouni
>
> As far as I can tell from a previous answer on v6ops by Orange PL
> the EIT bit (think it is ESM info transfer flag IE) has an effect
> when the HSS has a default APN different from the one requested by
> the UE. Without the EIT bit set the network doesn’t let the UE
> requested APN override the default from the HSS, so two PDN
> connections are set up, one with IPv4 (assuming the default is an
> IPv4 only APN) and the other IPv6 (assuming that was requested by the
> UE).  So strictly speaking it does look independent of IP version but
> it is being noticed as operators introduce IPv6.
>
> Ross
>