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

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Mar 2013 15:08:37 +0100

Le 27/02/2013 00:59, Vízdal Aleš a écrit :
>>> Correct.  NAT44 is good enough if you can number users from
>>> RFC1918. If users (including M2M ...) and infrastructure exceed
>>> RFC1918 space
>>
>> 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.
>
> Unfortunately, 40-60 million customer base cannot be addressed by
> RFC1918/10.64/10 address space.

Well.  I side with typical advocating of IPv6 and big numbers.  But let
me play devil's advocate here.

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 make up for
a total of unique 22 million (22085632) addresses.  This is indeed less
than the 40-60 million customer base.

But the nature of NAT is more than that.  It is also about
- multiple levels of NAT.
- NAT technology can be used with publicly routable addresses which
   are not RFC1918/RFC6598.
- dynamic address allocation.

With 3 levels of NAT and an additional not-used class B, one can easily
cover a 40-60 million customer base.  Not all 40-60 million customers
are connected simultaneously.  DHCP takes care to revoke use of an
address and deliver it to someone else needing it.

If all 40-60 million customers were connected simultaneously then the
core network would crash - but for other reasons than IPv4 address numbers.

Cellular network crashes exist yet they're not due to too small IPv4
addressing space.

There is not a problem in numbers when using NAT technology to cover
that 40-60 million customer base.  There are other problems, but not in
numbers of IPv4 addressing.

If these problems could be formulated then we could have a case for IPv6
in cellular networks.

Alex

> Ales

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Mar 2013 18:59:15 -0800

> - multiple levels of NAT.
		Breaks many NAT traversal solutions and makes NAT even more
		dysfunctional.

> - NAT technology can be used with publicly routable addresses which

		Breaks NAT-oriented assumptions that have been baked into some
		applications NAT traversal efforts.

> - dynamic address allocation.

		Has nothing whatsoever to do with NAT.

> address and deliver it to someone else needing it.

There are a lot of (not necessarily correct) assumptions about usage
patterns built into those numbers. I can guarantee you that if an ISP
were to inflict such an implementation on residential subscribers, they
would lose customers quickly. In mobile, maybe, maybe not. People
have become pretty tolerant of an impressive level of dysfunctionality
in mobile IP in the US.

> core network would crash - but for other reasons than IPv4 address numbers.

I'm not actually convinced that's true.

> Cellular network crashes exist yet they're not due to too small IPv4

Whether the lack of addresses crashes the network or not, it certainly
degrades the user experience.

> numbers of IPv4 addressing.

Yes, there is a real problem in IPv4 numbers, too. The fact that you're more
willing to add a bunch of hacks to IPv4 to try and prop it up instead of
implementing IPv6 really doesn't change the fact that there is a problem.

> If these problems could be formulated then we could have a case for IPv6

The problems have been formulated and a number of cellular networks have
started deploying IPv6. I believe Slovenia is completely dual-stacked on their
cellular networks, for example.

I know that Verizon and T-Mobile both have IPv6 on their wireless networks
to varying degrees.

Owen

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 01 Mar 2013 22:37:13 -0500

On 2013-03-01 9:59 PM, "Owen DeLong" <[email-masked]> wrote:

>>>>>. In mobile, maybe, maybe not. People

I think this is going to change.  I suspect as people start to use mobile
interchangeably with their traditional wired connections, they will demand
more robust connectivity.

I.e.  Exchanging your wired connection for Wireless to realize you can't
do all the stuff you did the day before is frustrating.

Although tolerated to date, I suspect the tides will change.  I also think
IPv6 is a good way to get there and that IPv4 can't IMHO (given this list,
I would guess that some may agree).

My 0.02.

Regards,

Victor Kuarsingh

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 17:59:11 +0100

Le 02/03/2013 03:59, Owen DeLong a écrit :
>>>>> RFC1918. If users (including M2M ...) and infrastructure
>>>>> exceed RFC1918 space
>>>>
>>>> 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.
>>
>> Well.  I side with typical advocating of IPv6 and big numbers.  But
>> let me play devil's advocate here.
>>
>> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 make up
>> for a total of unique 22 million (22085632) addresses.  This is
>> indeed less than the 40-60 million customer base.
>>
>> But the nature of NAT is more than that.  It is also about -
>> multiple levels of NAT.

It may, but I am not sure which ones?

The NAT Traversal of Mobile IP (based on UDP) works ok with this NAT.

Also, NAT Traversal is not absolutely necessary.   One may use Internet
without employing NAT Traversal.

>> - NAT technology can be used with publicly routable addresses
>> which are not RFC1918/RFC6598.
>

I didnt know that.  I wonder which NAT traversal solution is built in
with the assumption that the IP address is only RFC1918 space?

(remark these implementations will fail also when the new NAT space
100./10 is employed, instead of RFC1918).

> Has nothing whatsoever to do with NAT.

It has to do with the lack of addresses argument.

Although an operator may need 50million addresses, these are not needed
at the same time.  And the dynamic nature of DHCP allows for it.

>> With 3 levels of NAT and an additional not-used class B, one can
>> easily cover a 40-60 million customer base.  Not all 40-60 million
>> customers are connected simultaneously.  DHCP takes care to revoke
>> use of an address and deliver it to someone else needing it.
>
> patterns built into those numbers. I can guarantee you that if an
> ISP were to inflict such an implementation on residential
> subscribers, they would lose customers quickly.

Residential - I tend to agree, people tend to need a more comfortable IP 
connection when the place is as comfortable as at home.

> In mobile, maybe, maybe not. People have become pretty tolerant of an
> impressive level of dysfunctionality in mobile IP in the US.

Well, this is the case of how the computer is used.

When people are mobile they do less things on a computer than when at a 
desk.  IPv4 and NAT are maybe sufficient for that.

>> If all 40-60 million customers were connected simultaneously then
>> the core network would crash - but for other reasons than IPv4
>> address numbers.
>
>> Cellular network crashes exist yet they're not due to too small
>> IPv4 addressing space.
>
> Whether the lack of addresses crashes the network or not, it
> certainly degrades the user experience.

Operators are afraid of having to pay subscribers, rather than offering 
them a degraded service.

Operators pay subscribers when the service fails entirely.

>> There is not a problem in numbers when using NAT technology to
>> cover that 40-60 million customer base.  There are other problems,
>> but not in numbers of IPv4 addressing.
>
> Yes, there is a real problem in IPv4 numbers, too. The fact that
> you're more willing to add a bunch of hacks to IPv4 to try and prop
> it up instead of implementing IPv6 really doesn't change the fact
> that there is a problem.
>
>> If these problems could be formulated then we could have a case for
>> IPv6 in cellular networks.
>
> The problems have been formulated and a number of cellular networks
> have started deploying IPv6. I believe Slovenia is completely
> dual-stacked on their cellular networks, for example.

It is a good exemple.

But I would like to learn whether Slovenia deploys LTE. I think it does 
not look at it. An dif it does, I would be surprised that were IPv6 
(although Slovenia may look at deploying 3G and IPv6).

> I know that Verizon and T-Mobile both have IPv6 on their wireless
> networks to varying degrees.

Yes, varying degrees.  That is a detail point I am trying to understand 
- who deploys IPv6 and LTE/4G.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 18:12:33 +0100

Le 02/03/2013 04:37, Victor Kuarsingh a écrit :
>> have become pretty tolerant of an impressive level of
>> dysfunctionality in mobile IP in the US.
>
> I think this is going to change.  I suspect as people start to use
> mobile interchangeably with their traditional wired connections, they
> will demand more robust connectivity.

I dont think people use mobile interchangeably with their wired
connections.  For example, real Word and Excel never took off on
smartphones.

Moreover, there are now have a large number of smartphone-exclusive
Applications.  I doubt many of them do IPv6.  These applications were
written from scratch at a time when IPv6 existed and was mature enough
already.  Yet ignored.

> I.e.  Exchanging your wired connection for Wireless to realize you
> can't do all the stuff you did the day before is frustrating.

Wired to wireless - ok, but wireless WiFi, not cellular.

> Although tolerated to date, I suspect the tides will change. I also
> think IPv6 is a good way to get there and that  IPv4 can't IMHO (given
> this list, I would guess that some may agree).

Yes, the profile on this list is IPv6.  I will shut up :-)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 18:47:58 +0100

Le 04/02/2013 17:43, Mikael Abrahamsson a écrit :
> On Mon, 4 Feb 2013, Alexandru Petrescu 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.
>
>> 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.
>
> Doing IPv4v6 on LTE is not that much of a problem, that's doable
> today (my experience).

I am not sure what you mean by 'doable'.  Do you know of an operator 
having done some LTE IPv6 test?

Alex

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Mar 2013 19:00:13 +0100 (CET)

> having done some LTE IPv6 test?

I have IPv4v6 working in our LTE network today, network wide. Not in 
production to customers, but doing IPv4v6 in LTE is comparitively easy. We 
had it working 2-3 years ago.

I don't want to IPv6 enable our users when they're connected to the LTE 
network and then have customers lose their IPv6 connectivity if they 
happen to hand over to 2G or 3G.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Mon, 11 Mar 2013 19:07:29 +0100

* Mikael Abrahamsson

> production to customers, but doing IPv4v6 in LTE is comparitively easy.
> We had it working 2-3 years ago.
> 

Is this only a challenge for IPv4v6, or does it apply to IPv6 as well?

I know of several 3G networks that support IPv6 in production for their
customers, but I don't know if any of those also operate LTE networks
and if so whether or not the handover between the network types works.

Best regards,
-- 
Tore Anderson

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Mar 2013 19:28:33 +0100 (CET)

> Is this only a challenge for IPv4v6, or does it apply to IPv6 as well?

Well, it's a scaling issue as well. Currently supporting IPv4+IPv6 is not 
really a problem, but this increases the signalling load. For me it's been 
a problem to get IPv4v6 support in 2G+3G which I want before deploying.

> and if so whether or not the handover between the network types works.

One way is to go IPv4v6 in LTE and IPv4+IPv6 (dual bearers) in 2G/3G. I 
don't know how well this works in real life. This is one of the things I'm 
going to find out :P

---

From: Teemu Savolainen <[email-masked]>
Date: Mon, 11 Mar 2013 16:52:33 -0400

There is no handover specified for a case where UE has first IPv4v6 in LTE
and then handovers to 2G/3G where IPv4v6 is not supported. 3GPP looked at
that scenario, but there was no reasonable way to specify that (for
splitting a connection to two, and then merging back when handing over from
2G/3G to LTE:-).

That is the main reason, afaik, why status codes for "single-stack bearers
only" were created. I.e. operator can deploy LTE that would support IPv4v6,
and can even provision UEs to ask for IPv4v6, but until 2G/3G is upgraded
the PGW is configured to force UEs to fallback to parallel IPv4 and IPv6
until the day 2G and 3G have been upgraded to support IPv4v6.

Best regards,

Teemu

2013/3/11 Mikael Abrahamsson <[email-masked]>

> ______________________________**_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 11 Mar 2013 22:56:58 +0100

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Friday, March 01, 2013 9:09 AM
> To: Vízdal Aleš
> Cc: [email-masked]
> Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks
> 

3 levels of NAT will make the data retention much much harder than just one level.
It will hopefully be cheaper to deploy IPv6 ;-)

Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 11 Mar 2013 23:08:59 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tore
> Anderson
> Sent: Monday, March 11, 2013 2:07 PM
> To: Mikael Abrahamsson
> Cc: [email-masked]

In general if you doing a handover between two RATs (radio access technologies
such as 2G, 3G or LTE) you need to have the same PDP Types subscribed and supported, 
so both networks must have the same capabilities and matching user subscriptions.

IPv4v6 support for 2G/3G usually requires a network upgrade, so LTE deployments
are more likely to be IPv4v6 compliant than 2G/3G. In terms of IPv6, handovers
are likely to work as IPv6 PDP support is there for some time, but it comes down
to if IPv6 is supported in 2G/3G as IPv6 only not common and operators are trying
to avoid dual-stack support by two independent PDPs (IPv4 and IPv6) as the BSS
systems might have some issues.

Ales

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Mar 2013 15:11:55 -0700

> without employing NAT Traversal.

That depends on your application.

VPNs will, in many cases suffer here.
Also many peer-to-peer communications programs such as Skype, YIM, etc.
VOIP will often break from multi-layer NAT in interesting ways.

The internet is not the web. The web works without NAT traversal. Other
applications vary. Some applications don't work particularly well with NAT
even with NAT traversal.

> 100./10 is employed, instead of RFC1918).

No, they won't. The new space is intended not as an end-user space,
but for the intermediate space used by ISPs. The application should
never see it (or should see it as "public address" space on the other
side of the NAT.

> at the same time.  And the dynamic nature of DHCP allows for it.

Only to a very limited (and ever decreasing) extent. More and more things
are becoming always-on-always-connected.

> Residential - I tend to agree, people tend to need a more comfortable IP connection when the place is as comfortable as at home.
> 

I don't think that's the distinction that matters so much here. My point is that
customers have developed a certain level of expectation based on their
customer experience to date. In the mobile world, that experience has been
traditionally particularly poor and as a result, expectations are generally very
low. In the residential world, the experience has been generally poor, but not
nearly as poor as in the mobile world. As a result, expectations are a bit
higher.

> When people are mobile they do less things on a computer than when at a desk.  IPv4 and NAT are maybe sufficient for that.

That is an assumption which may have been valid 5 or possibly even 2 years ago. It certainly isn't valid today for many users and is becoming increasingly invalid for more and more users as time progresses.

> Operators are afraid of having to pay subscribers, rather than offering them a degraded service.
> 

Operators never pay subscribers in my experience. In some cases, if the network fails entirely (where fails entirely is viewed from the user's perspective more than from the operator's), operators may have to refund some of what the subscriber paid. Subscribers do not expect to pay for services they have not received or could not use.

Operators are afraid of many things:
	Service credits
	Departing customers
	Regulatory changes

Failed service leads to the first one. Degraded service leads to the second. Enough unhappy customers from either failed or degraded service tends to result in the third.

> But I would like to learn whether Slovenia deploys LTE. I think it does not look at it. An dif it does, I would be surprised that were IPv6 (although Slovenia may look at deploying 3G and IPv6).
> 

This makes no sense. It is actually easier to do IPv6 on LTE than on earlier cellular technologies.
I know that Verizon's IPv6 deployment is on their LTE network.

> Yes, varying degrees.  That is a detail point I am trying to understand - who deploys IPv6 and LTE/4G.

Verizon. T-Mobile.

The varying degrees part was more about the percentage of network coverage than about which of their technologies had IPv6.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Mar 2013 09:42:01 +1100

> never see it (or should see it as "public address" space on the other

Of course applications will see it.  If you are directly connected
applications are expected to see it.  100/10 prevents RFC 1918
either side of a CPE router.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 00:02:26 +0100

Le 11/03/2013 22:56, Vízdal Aleš a écrit :
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Friday, March 01, 2013
>> 9:09 AM To: Vízdal Aleš Cc: [email-masked] Subject: Re: [v6ops]
>> State of IPv6 in Mobile Cellular Networks
>>
>> multiple levels of NAT. - NAT technology can be used with publicly
>> routable addresses which are not RFC1918/RFC6598. - dynamic address
>> allocation.
>>

Well I dont know what is meant by data retention?

I did this scheme:

lte-wifi-wifi

with two NATs and it works fine for some web browsing I tried.

> It will hopefully be cheaper to deploy IPv6 ;-)

Hopefully :-)

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 12 Mar 2013 00:23:35 +0100

> Well I dont know what is meant by data retention?

http://en.wikipedia.org/wiki/Data_retention or call it logging

The ISPs are asked to keep records, so once asked by the court they must reveal 
who was using the IP address that's a subject of a query at a given time. The legislation
varies country by country.

Ales

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 12 Mar 2013 01:27:44 +0200

On Mar 11, 2013, at 8:28 PM, Mikael Abrahamsson <[email-masked]> wrote:

> Well, it's a scaling issue as well. Currently supporting IPv4+IPv6 is not really a problem, but this increases the signalling load. For me it's been a problem to get IPv4v6 support in 2G+3G which I want before deploying.
> 
> One way is to go IPv4v6 in LTE and IPv4+IPv6 (dual bearers) in 2G/3G. I don't know how well this works in real life. This is one of the things I'm going to find out :P

The context transfer messages will get rejected if the pre-rel-9 SGSN does not understand the dual-stack required extended addressing IEs. Some GTPv1 goodness ;)

- Jouni

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

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Mar 2013 17:04:55 -0700

> either side of a CPE router.

No… 100.64/10 is intended to provide for RFC-1918 on the customer
side of the CPE and 100.64/10 on the Carrier side.

You really should read the relevant drafts again if you are still confused
about this.

Owen

---

From: David Farmer <[email-masked]>
Date: Mon, 11 Mar 2013 19:26:31 -0500

> You really should read the relevant drafts again if you are still confused

Actually, 100.64.0.0/10 is allowed to be used on both the carrier side 
and the customer side of a CPE, IFF the CPE is capable of having the 
same addresses on both sides.  Sometimes referred to as bi-direction or 
double NAT.  Otherwise, it SHOULD only be use on the carrier side.  I'm 
not aware of most consumer grade NAT boxes meeting this requirement. 
Therefore generally, 100.64.0.0/10 should only be allow on the carrier 
side of a CPE NAT and RFC 1918 on the customer side.

So, I wouldn't make any absolute assumptions about 100.64.0.0/10.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Mar 2013 17:50:07 -0700

On Mar 11, 2013, at 5:26 PM, David Farmer <[email-masked]> wrote:

> Actually, 100.64.0.0/10 is allowed to be used on both the carrier side and the customer side of a CPE, IFF the CPE is capable of having the same addresses on both sides.  Sometimes referred to as bi-direction or double NAT.  Otherwise, it SHOULD only be use on the carrier side.  I'm not aware of most consumer grade NAT boxes meeting this requirement. Therefore generally, 100.64.0.0/10 should only be allow on the carrier side of a CPE NAT and RFC 1918 on the customer side.
> 

Hmm… It seems that the prohibition against that usage was lost when we abandoned the companion document (draft-bdgks). That's unfortunate.

However, I think RFC-6598 makes it pretty clear that use of 100.64/10 for customer-side networking is at the very least strongly discouraged and that the primary purpose for allocating 100.64/10 as shared transition space was to create a distinct space for CGN that would not conflict with customer-side use of RFC-1918.

> So, I wouldn't make any absolute assumptions about 100.64.0.0/10.

I think you could basically say the same thing about most of IPv4 in general at this point.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Mar 2013 12:58:57 +1100

In message <[email-masked]>, Owen DeLong writes:
> >=20
> > In message <[email-masked]>, Owen =
> DeLong writes:
> >>=20
> >>=20
> >=20
> No=85 100.64/10 is intended to provide for RFC-1918 on the customer
> You really should read the relevant drafts again if you are still =
> confused
> about this.

Sorry Owen, you are the one that is confused here.

The ISP assigns 100.64/10 to *all* its customers as it has no way
of knowing if the device is a router or host.  The home CPE router
masquerade as a host. 

Mark

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Mar 2013 19:15:48 -0700

> of knowing if the device is a router or host.  The home CPE router

Sure, but almost nobody does that these days.

I'm still having trouble figuring out what you meant by "100/10 prevents RFC 1918
either side of a CPE router." if you didn't mean that customers were expected not
to use RFC-1918 in an environment where the provider is using 100.64/10.

If that is what you meant, then I stand by my original statement with the exception that
those few remaining end-users without routers will, in fact, receive 100.64/10
addresses on their host directly from the provider.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Mar 2013 14:52:54 +1100

> to use RFC-1918 in an environment where the provider is using 100.64/10.

100.64/10 is designed to prevent RFC 1918 on both sides of the border
CPE router.

> addresses on their host directly from the provider.

Well you claimed "never".  If a host/router sees that one of its
addresses is in 100.64/10 then it can assume that the address is
behind a NAT.

---

From: Czerwonka Michał - Hurt TP <[email-masked]>
Date: Tue, 26 Mar 2013 11:16:35 +0000

Hi All,

I would like to inform that Orange Poland (OPL) officialy launched mobile access to Internet using IPv6 protocol for their subscribers. This is done by APN IPv6-only with NAT64/DNS64 funcionality. This feature is ready to support the 464xlat architecture. So, the mobile phone with CLAT are welcome.

Mobile Network Settings: 
APN name is "internetipv6" , APN protocol is "IPv6" 

Do not hesitate to test it if you have OPL sim card.

Thanks,
Mcz

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 26 Mar 2013 13:09:09 +0100

Hello,

Thank you for this information.

What is an 'OPL' SIM card?  Is  it 'Orange Poland'?   I have several SIM
cards in France.

Does this work with LTE as well?

Thanks,

Alex

Le 26/03/2013 12:16, Czerwonka Michał - Hurt TP a écrit :
> Hi All,
>
> I would like to inform that Orange Poland (OPL) officialy launched
> mobile access to Internet using IPv6 protocol for their subscribers.
> This is done by APN IPv6-only with NAT64/DNS64 funcionality. This
> feature is ready to support the 464xlat architecture. So, the mobile
> phone with CLAT are welcome.
>
>
> Mobile Network Settings: APN name is "internetipv6" , APN protocol
> is "IPv6"
>
>
> Thanks, Mcz
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Czerwonka Michał - Hurt TP <[email-masked]>
Date: Tue, 26 Mar 2013 12:19:05 +0000

Yes, you need Orange Poland (OPL) SIM card :)

Right now OPL support 2G/3G radio access, but in the future who knows :)

Mcz

-----Wiadomość oryginalna-----
Od: [email-masked] [mailto:[email-masked]] W imieniu Alexandru Petrescu
Wysłano: 26 marca 2013 13:09
Do: [email-masked]
Temat: Re: [v6ops] State of IPv6 in Mobile Cellular Networks

Hello,

Thanks,

Alex