Subject: [v6ops] State of IPv6 in Mobile Cellular Networks

From: Cameron Byrne <[email-masked]>
Date: Sun, 3 Feb 2013 17:37:53 -0800

<rant>

Since a lot of folks talk about IPv6 in mobile, i figured i would pen
my own view and experience here.  It hopefully will set some context
for the WG work products draft-ietf-v6ops-464xlat,
draft-ietf-v6ops-64share,
draft-binet-v6ops-cellular-host-requirements.  Please do note 464XLAT
is not 3GPP/mobile specific.

AFAIK, there is exactly 1 provider in the world of 3GPP that offers
dual-stack service by default, Verizon Wireless (hat tip).  I did not
count, but there is probably more that 50 LTE networks out there today
http://en.wikipedia.org/wiki/List_of_LTE_networks .. There may be some
others that support default-on dual-stack, i but i don't know of them.

So, conclusion #1 is that that LTE does not require or even help IPv6
deployment.  Look at the facts. There is a long list of LTE networks
that definitely do not have IPv6 or dual-stack by default:  AT&T,
Sprint, EE, T-Mobile DE, Rogers, Vodafone, ..

I believe a lot of folks, myself included, thought network upgrades
would bring about more IPv6 features and deployment.  In my own
experience, this is the exact opposite in reality.  Let me explain.

There are 4 major providers of 3GPP equipment.  I will exonerate
Huawei since i don't know anything about them and Cisco because i know
there stuff works (AFAIK).  The other 2 providers are specifically
defunct on the IPv4v6 front.  One -- has a brand new high capacity
P-GW/GGSN which does not support IPv4v6 (it supports v4 or v6).  And
the other, which is painfully wrecking my IPv4v6 deployment plans, has
a newish (few years old now) high capacity SGSN which does not support
IPv4v6 (also supports v4 or v6).  Witness, new gear does not result in
v4v6 (dual-stack).  In fact, the legacy SGSN that i had from the same
vendor does support v4v6, but it is now end of life (at least as far
as my network)!  It is just the new one that does not have dual-stack
support.

Thought i would just share, and dispel any misconceptions folks had
about 3GPP / LTE networks and IPv6, especially about dual-stack.
There is nothing wrong with the 3GPP specs, and i know the network
operators are asking but not getting the features ... That said,
draft-ietf-v6ops-464xlat and draft-ietf-v6ops-64share are both hacks
that try to route around the brokeness of economics, NAT444s, vendors
that don't ship 4+ year old 3GPP defined mandatory features (IPv4v6
LTE bearers), and IPV4-only apps like Skype.

</rant>

CB

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Feb 2013 10:30:52 +0100

Le 2013-02-04 02:37, Cameron Byrne a écrit :
> The other 2 providers are specifically defunct on the IPv4v6 front.
> One -- has a brand new high capacity P-GW/GGSN which does not support
> IPv4v6 (it supports v4 or v6).  And the other, which is painfully
> wrecking my IPv4v6 deployment plans, has a newish (few years old now)
> high capacity SGSN which does not support IPv4v6 (also supports v4 or
> v6).  Witness, new gear does not result in v4v6 (dual-stack).  In
> fact, the legacy SGSN that i had from the same vendor does support
> v4v6, but it is now end of life (at least as far as my network)!  It
> is just the new one that does not have dual-stack support.

Curious... Why is this happening? Is it malice or incompetence? Or some
other reason?

I'm not expecting perfect answers on a public list, but it might still 
be interesting...

Simon

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Feb 2013 15:18:12 +0100

Le 04/02/2013 10:30, Simon Perreault a écrit :
>> One -- has a brand new high capacity P-GW/GGSN which does not
>> support IPv4v6 (it supports v4 or v6).  And the other, which is
>> painfully wrecking my IPv4v6 deployment plans, has a newish (few
>> years old now) high capacity SGSN which does not support IPv4v6
>> (also supports v4 or v6).  Witness, new gear does not result in
>> v4v6 (dual-stack).  In fact, the legacy SGSN that i had from the
>> same vendor does support v4v6, but it is now end of life (at least
>> as far as my network)!  It is just the new one that does not have
>> dual-stack support.
>
> Curious... Why is this happening? Is it malice or incompetence? Or
> some other reason?

Let me add to this curiosity.  I doubt it's malice nor incompetence.

My local experience is that one operator's LTE deployment is IPv4 not
IPv6, and NAT not publicly routable addresses.  This is surprisingly
different than same operator's 3G deployment which offers publicly
routable IPv4 addresses for top class subscriptions and IPv6 for test
cases (not for the public).

(on another hand, the bandwidth, latency and fair-use limits on the
  subscription plan offered by the LTE network are better than 3G.)

When I express this kind of surprise - a future generation cellular
network with a past generation of IP protocols - I am not well
understood.  I am explained that the network is new, entirely
independent from 3G, and hence many of the achievements in 3G can't be
reused.

I suspect that they couldn't obtain new IPv4 publicly routable addresses
for the new LTE deployment.  I suspect that, absent IPv4 publicly
routable space - an operator prefers to offer NAT-IPv4 rather than IPv6.

I also suspect that although the things move slowly, they may move in
the right direction.

A parallel could be drawned between the GPRS-3G migration and 3G-LTE, in
terms of IP family of protocols.  If I remember correctly, the GPRS
deployment was IPv4 NAT and one had to wait for 2nd generation 3G
deployments to see publicly routable IPv4 addresses and IPv6 in
test.  Maybe now we wait the same - a second or 3rd generation LTE
deployment to see publicly routable IPv4 and IPv6.

So, I personnally wait for the following, in this order:
- 3G network to become IPv6 for everybody
- LTE network to become IPv4 publicly routable addresses
- LTE network to become IPv6 as test
- LTE network to become IPv6 for everybody
All this maybe in 3-6 years time.  At that time we'd talk 5G already I
believe.

Alex

>
> I'm not expecting perfect answers on a public list, but it might
> still be interesting...
>
> Simon _______________________________________________ v6ops mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 4 Feb 2013 17:43:06 +0100 (CET)

On Mon, 4 Feb 2013, Alexandru Petrescu wrote:

> deployments to see publicly routable IPv4 addresses and IPv6 in test. 
> Maybe now we wait the same - a second or 3rd generation LTE deployment 
> to see publicly routable IPv4 and IPv6.

This is really weird.

Personally, I'm trying to get 2G/3G/4G equal service with proper 
establishment and handover between the networks for a IPv4v6 PDP context.

> All this maybe in 3-6 years time.  At that time we'd talk 5G already I

Doing IPv4v6 on LTE is not that much of a problem, that's doable today (my 
experience). Getting the same IPv4v6 so the customer can establish a 
IPv4v6 PDP context in 3G, handing over to 4G and back to 3G, that's where 
it gets interesting. :P

For me 2G/3G/4G are different access technologies that should be 
transparent to the user, they should offer the same services just at 
increasingly higher speeds.

IPv6 only access on 2G/3G/4G is also doable (there are quite a few phones 
and usb dongles that do this), the problem is that IPv6 only + NAT64 gives 
a lousy end user experience without 464XLAT, so that's a no-go.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Geir Egeland <[email-masked]>
Date: Wed, 13 Feb 2013 13:08:41 +0100

On 04-02-13, at 17:43 , Mikael Abrahamsson <[email-masked]> wrote:

>> A parallel could be drawned between the GPRS-3G migration and 3G-LTE, in terms of IP family of protocols.  If I remember correctly, the GPRS deployment was IPv4 NAT and one had to wait for 2nd generation 3G deployments to see publicly routable IPv4 addresses and IPv6 in test. Maybe now we wait the same - a second or 3rd generation LTE deployment to see publicly routable IPv4 and IPv6.
> 
> This is really weird.
> 
> Personally, I'm trying to get 2G/3G/4G equal service with proper establishment and handover between the networks for a IPv4v6 PDP context.
You are not the only one...
> Doing IPv4v6 on LTE is not that much of a problem, that's doable today (my experience). Getting the same IPv4v6 so the customer can establish a IPv4v6 PDP context in 3G, handing over to 4G and back to 3G, that's where it gets interesting. :P
> 
> For me 2G/3G/4G are different access technologies that should be transparent to the user, they should offer the same services just at increasingly higher speeds.
This is our approach as well and I think many european operators have a similar 3G/LTE business model.
> 
> IPv6 only access on 2G/3G/4G is also doable (there are quite a few phones and usb dongles that do this), the problem is that IPv6 only + NAT64 gives a lousy end user experience without 464XLAT, so that's a no-go.
Some mobile terminals with IPv4v6 PDP support would be nice……terminal vendors, - any input here please?

Geir Egeland
Telenor Group/Norway
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Feb 2013 16:45:41 -0600

Hi Cameron,

sorry for my belated reply.

> Sprint, EE, T-Mobile DE, Rogers, Vodafone, ..
Maybe they realized that NAT44 is good enough for them to handle not so
many LTE customers they have? They already know NAT44 technology.

> P-GW/GGSN which does not support IPv4v6 (it supports v4 or v6).

>  And
> IPv4v6 (also supports v4 or v6).

 This should be OK for SGSN because you don't even need SGSN to support
IPv6 in order to support IPv6 in your network, right? because of the
inherent tunneling.

 Witness, new gear does not result in
> v4v6 (dual-stack).

I remember you voiced strongly against the dual stack approach. You seemed
to have advocated IPv6 only network with 4via6 approaches, v4 users can be
supported. This was what you were advocating, and for a good reason.

>  In fact, the legacy SGSN that i had from the same
> LTE bearers), and

> IPV4-only apps like Skype.
>
>
This seems to be the main issue.
What a pity :-).

Regards,

Behcet

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 21 Feb 2013 10:43:17 +0100

Behcet,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Wednesday, February 20, 2013 11:46 PM
To: Cameron Byrne
Cc: IPv6 Ops WG
Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks

Hi Cameron,

sorry for my belated reply.
On Sun, Feb 3, 2013 at 7:37 PM, Cameron Byrne <[email-masked]<mailto:[email-masked]>> wrote:
<rant>

Maybe they realized that NAT44 is good enough for them to handle not so many LTE customers they have? They already know NAT44 technology.

I would simply assume that IPv6/Dual-Stack would take much more time to implement, so the launch date would be in danger.

 And

 This should be OK for SGSN because you don't even need SGSN to support IPv6 in order to support IPv6 in your network, right? because of the inherent tunneling.

You don't need IPv6 support at the user plane level as the traffic is tunnelled in GTP (transparent to the SGSN/SGW), but you still need IPv6/Dual-Stack
support on the control plane level and that's the issue.

Regards,

Behcet

Cheers,
Ales

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 21 Feb 2013 12:40:37 -0800

Behcet,

On Wed, Feb 20, 2013 at 2:45 PM, Behcet Sarikaya <[email-masked]> wrote:
> Maybe they realized that NAT44 is good enough for them to handle not so many
> LTE customers they have? They already know NAT44 technology.
>

Correct.  NAT44 is good enough if you can number users from RFC1918.
If users (including M2M ...) and infrastructure exceed RFC1918 space
the problem becomes substantially more complicated and NAT44 is not
nearly as fit for the problem.  For many mobile networks, they have
always been on NAT44 so inertia supports staying on NAT44.  My
specific problem is that i have more users / gear / cell sites than
RFC1918, that is my driver for ipv6.

>  This should be OK for SGSN because you don't even need SGSN to support IPv6
> in order to support IPv6 in your network, right? because of the inherent
> tunneling.
>

As Ales noted, the issue is with control plane signalling and handover
between 2G/3G/4G.  If the features are not synchronized, it does not
work well... especially if features such as "CS Fall Back" are used to
push between 3G and 4G for voice calls.

> supported. This was what you were advocating, and for a good reason.

This was my "crazy" single-stack perspective, but i think it has
become more popular and therefore slightly less crazy :)

I am still making progress on rolling out 464XLAT.  The missing piece
right now is the handset, but it is making progress.  As noted in my
rant, unforunately many vendors ship new gear without IPv6.  It seems
counter-intuitive.  Many folks thought they might new gear to do IPv6,
but in these specific cases new gear removed IPv6 functions.

> This seems to be the main issue.

A pity indeed.  The lesson I learned over the last few years is that
it is easier to change the host than the apps.  It seems
counter-intuitive, but alas we must understand the things we can
control and the things we cannot control.

CB

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 26 Feb 2013 18:53:06 +0100

Le 21/02/2013 21:40, Cameron Byrne a écrit :
>>> Since a lot of folks talk about IPv6 in mobile, i figured i
>>> would pen my own view and experience here.  It hopefully will set
>>> some context for the WG work products draft-ietf-v6ops-464xlat,
>>> draft-binet-v6ops-cellular-host-requirements.  Please do note
>>> 464XLAT is not 3GPP/mobile specific.
>>>
>>> AFAIK, there is exactly 1 provider in the world of 3GPP that
>>> offers dual-stack service by default, Verizon Wireless (hat
>>> tip). I did not count, but there is probably more that 50 LTE
>>> networks out there today
>>> http://en.wikipedia.org/wiki/List_of_LTE_networks .. There may be
>>> some others that support default-on dual-stack, i but i don't
>>> know of them.
>>>
>>> So, conclusion #1 is that that LTE does not require or even help
>>> IPv6 deployment.  Look at the facts. There is a long list of LTE
>>> networks that definitely do not have IPv6 or dual-stack by
>>> default:  AT&T, Sprint, EE, T-Mobile DE, Rogers, Vodafone, ..
>>>
>>
>> Maybe they realized that NAT44 is good enough for them to handle
>> not so many LTE customers they have? They already know NAT44
>> technology.
>>
>

If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and
192.168.0.0/16) then there is this 100.64.0.0/10 new space from RFC6598.

> RFC1918, that is my driver for ipv6.

I think it is a good driver.

An additional driver I could think of is applications which don't work
when NAT is present.  I think webrtc - I think it works ok if there is a
rdv point, but may not work otherwise.

>>> I believe a lot of folks, myself included, thought network
>>> upgrades would bring about more IPv6 features and deployment.
>>> In my own experience, this is the exact opposite in reality.  Let
>>> me explain.
>>>
>>>  Huawei since i don't know anything about them and Cisco because
>>> i know there stuff works (AFAIK).  The other 2 providers are
>>> specifically defunct on the IPv4v6 front.  One -- has a brand
>>> new high capacity P-GW/GGSN which does not support IPv4v6 (it
>>> supports v4 or v6).
>>
>>
>>>
>>> And the other, which is painfully wrecking my IPv4v6 deployment
>>> plans, has a newish (few years old now) high capacity SGSN which
>>> does not support IPv4v6 (also supports v4 or v6).
>>
>>
>> This should be OK for SGSN because you don't even need SGSN to
>> support IPv6 in order to support IPv6 in your network, right?
>> because of the inherent tunneling.
>>
>
> As Ales noted, the issue is with control plane signalling and
> handover between 2G/3G/4G.  If the features are not synchronized, it
> does not work well... especially if features such as "CS Fall Back"
> are used to push between 3G and 4G for voice calls.
>
>>> Witness, new gear does not result in v4v6 (dual-stack).
>>
>>
>> I remember you voiced strongly against the dual stack approach.
>> You seemed to have advocated IPv6 only network with 4via6
>> approaches, v4 users can be supported. This was what you were
>> advocating, and for a good reason.
>>
>
> counter-intuitive.  Many folks thought they might new gear to do
> IPv6, but in these specific cases new gear removed IPv6 functions.
>
>>>
>>> In fact, the legacy SGSN that i had from the same vendor does
>>> support v4v6, but it is now end of life (at least as far as my
>>> network)!  It is just the new one that does not have dual-stack
>>> support.
>>>
>>> Thought i would just share, and dispel any misconceptions folks
>>> had about 3GPP / LTE networks and IPv6, especially about
>>> dual-stack. There is nothing wrong with the 3GPP specs, and i
>>> know the network operators are asking but not getting the
>>> features ... That said, draft-ietf-v6ops-464xlat and
>>> draft-ietf-v6ops-64share are both hacks that try to route around
>>> the brokeness of economics, NAT444s, vendors that don't ship 4+
>>> year old 3GPP defined mandatory features (IPv4v6 LTE bearers),
>>> and
>>
>>
>>>
>> This seems to be the main issue. What a pity :-).
>>
>

If LTE doesn't do IPv6, some needs to improve its IPv4 may exist.  For
example, I would appreciate if an IPv4 64share method were possible
('24share'?)...

Alex

>
> CB
>
>> Regards,
>>
>> Behcet
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 27 Feb 2013 00:59:29 +0100

> 192.168.0.0/16) then there is this 100.64.0.0/10 new space from RFC6598.

Unfortunately, 40-60 million customer base cannot be addressed by RFC1918/10.64/10
address space.

Ales