Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis

From: <[email-masked]>
Date: Tue, 9 Jul 2013 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please take a look at it and comment.

---

From: "Alexis Munoz \(Gmail\)" <[email-masked]>
Date: Tue, 9 Jul 2013 10:22:05 -0500

It looks so interesting. I will check it and I will give you my comments
very soon.

Thanks,

Alexis Muñoz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, July 09, 2013 7:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis

A new draft has been posted, at
http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please
take a look at it and comment.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: GangChen <[email-masked]>
Date: Mon, 15 Jul 2013 10:56:14 +0800

Hi Alexis,

Thanks for the interests. We are experiencing the issues recently when
IPv6 is tested/deployed. For the goal of the draft, it reports that to
the community and hopes to mature IPv6 supports either by encouraging
proper implementations on mobile terminals or completing global
roaming contracts.

Your reviews/comments are appreciated

BRs

Gang

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 15 Jul 2013 17:35:57 +0300

Gang,

Regarding roaming in general, have you looked at what GSMA is doing
on this front? I was kind of expecting at least a reference to some
GSMA document since they are quite important when it comes to 3GPP
based networks & roaming.

- Jouni

---

From: GangChen <[email-masked]>
Date: Mon, 15 Jul 2013 23:28:10 +0800

> based networks & roaming.

I guess GSMA IR.21 could be cited here.
http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR2180.pdf
Most failures cases are occurred if a roaming partner's IR.21 only
states v4 support

-g

---

From: Tore Anderson <[email-masked]>
Date: Thu, 18 Jul 2013 02:44:28 +0200

> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis.

Section 4.1 states: "Roaming to IPv4-only networks with IPv6 PDP/PDN
request would fail to get addresses."

In my experience, this is seldom (if ever) the case.

My home network (Network Norway) supports IPv6 PDP context and in
recent years I've roamed in more European countries than I can enumerate
from the top of my head, in some Mid-East countries, in the U.S., and in
Japan. I've made a point out of trying all available PLMNs my phone can
see in the air, and I know for a fact that most of them are IPv4-only.
In spite of this I cannot recall last time I had a problem establishing
IPv6 connectivity when roaming. The way I see it, 3GPP IPv6 roaming is
one of those things that Just Works.

I'm not an expert on 3GPP network architecture, but as far as I've been
able to understand, the reason why this work is that the IPv6 gets
tunnelled back to my home network using GTP, and that the visited
network just considers the payload as "data" and doesn't really care
whether it is IPv4 or IPv6.

I'm sure there could be exceptions to the above. I've heard several
people suggest that Japan is particularly problematic in this regard -
but in my experience it Just Works there, too.

Tore

---

From: "GT RAMIREZ, Medel G." <[email-masked]>
Date: Thu, 18 Jul 2013 09:02:38 +0800

Hi,

---> Same experience with other countries (specifically guys from
Sweden) visiting the Philippines *but* problems arises with the Billing
Systems (TAP format)
And it was immediately corrected....

Regards
Medel
++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tore Anderson
Sent: Thursday, July 18, 2013 8:44 AM
To: [email-masked]
Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis

My home network (Network Norway) supports IPv6 PDP context and in recent
years I've roamed in more European countries than I can enumerate from
the top of my head, in some Mid-East countries, in the U.S., and in
Japan. I've made a point out of trying all available PLMNs my phone can
see in the air, and I know for a fact that most of them are IPv4-only.
In spite of this I cannot recall last time I had a problem establishing
IPv6 connectivity when roaming. The way I see it, 3GPP IPv6 roaming is
one of those things that Just Works.

Tore

This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately.

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 18 Jul 2013 01:01:53 -0400

Authors,

Dave Michaud from our technology team reviewed the document and had some
feedback.  I have included it below.

[Feedback]
Section 2, there should be a mention of HLR

Section 3.1 mixes two concepts that have different causes and impacts
-          The UE requesting IPv4v6 PDP/PDN Type

-          The HLR/HSS sending a profile with dual-stack enabled
(extended-PDP-IP parameter)

Section 3.2, there is a responsibility that is put on the UE where it
shouldn¹t:
A roaming subscriber with IPv4v6 PDP/PDN type should change the request to
two separated PDP/PDN messages of single IP version in order to achieve
equivalent results.
In reality, the UE will still request IPv4v6 but will be informed by the
network that only single address bearers are allowed (cause code #52)
along with the activation of one address type. Then and only then the UE
can go back and request another bearer with the secondary address type.

Section 3.3 a visited network that is IPv6-Only is not something I would
consider probable. Given that the address allocation is the burden of the
home network, I really don¹t see why an operator who wants to eb IPv6-Only
would block inbound roaming using IPv4 or IPv4v6.

Section 4.1 makes an assumption about support for IPv6 that has been in
place for as long as IPv4 and it is well supported. Given that this is an
optional feature that must be turned-on on vendor equipment, it¹s not
really the case. But then, this section goes on to describe that a user
could roam into an IPv4-Only network.

Section 4.2 I don¹t really understand what one is trying to say but there
is discussion about hard coding a PREFIX64 which could be a mismatch with
the visited network. These functions are all home network based unless
VPLMN local breakout is used but there is no mention of that.

Aside from the clarifications above, there should be a clear mention of
local breakout impacts in this document because it shift a large
proportion of the responsibility on the visited network.

Also, one thing note mentioned and that we use actively is a clear
separation between what the UE requests and what gets allocated by the
HPLMN. It is not enough to say ³Roaming behavior from a dual-stack
network². Our UEs will be requesting dual-stack to help with compatibility
but our PGW will make a selection (IPv4, IPv6 or IPv4v6). Does this fall
in the category ³from a dual-stack network²?

Regards,

Victor K

---

From: GangChen <[email-masked]>
Date: Thu, 18 Jul 2013 14:18:19 +0800

> whether it is IPv4 or IPv6.

Thanks for sharing your experience. Yes, you are right.
There is no such issue if the subscriber's traffic get back to the
gateway (e.g. GGSN) in the home network.
The described failure case occurred when the subscriber get an address
from the GGSN in the visited network. And traffic flows would be
transmitted in a local-breakout manner.  3GPP allows such
local-breakout because it has more efficient routing paths. 3GPP also
specified another architecture called "SIPTO". It guarantees the
subscriber would always select the closest GGSN to reside.

Best Regards

Gang

---

From: Tore Anderson <[email-masked]>
Date: Thu, 18 Jul 2013 09:17:20 +0200

* GangChen

> subscriber would always select the closest GGSN to reside.

I see. When roaming, I always get an IP address that belongs to my home
provider (this goes both for IPv4 and IPv6), so I assume that it is the
home network's choice whether or not to enable this "use closest GGSN"
feature?

If so, I'd suggest adding some text that ensuring this feature is
disabled (at least for the IPv6 PDP type, if it is possible to
differentiate between the two) is a good way to prevent IPv6 subscribers
from experiencing problems when roaming in IPv4-only networks.

Tore

---

From: GangChen <[email-masked]>
Date: Thu, 18 Jul 2013 16:46:23 +0800

> home network's choice whether or not to enable this "use closest GGSN"

Yes, those behaviors could be gauged by subscriber's profile. For
example, disable local-break-out

> from experiencing problems when roaming in IPv4-only networks.

Good suggestion. I would add the point in the next update.

Best Regards

Gang

---

From: <[email-masked]>
Date: Thu, 18 Jul 2013 11:14:57 +0200

Hi 

Some comments below
David

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de GangChen
> Envoyé : jeudi 18 juillet 2013 10:46
> À : Tore Anderson
> Cc : [email-masked]
> Objet : Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis
> 
> >> The described failure case occurred when the subscriber get an 
> >> address from the GGSN in the visited network. And traffic 
> flows would 
> >> be transmitted in a local-breakout manner.  3GPP allows such 
> > I see. When roaming, I always get an IP address that belongs to my 
> > home provider (this goes both for IPv4 and IPv6), so I 
> assume that it 
> > is the home network's choice whether or not to enable this 
> "use closest GGSN"
> > feature?
> 
> Yes, those behaviors could be gauged by subscriber's profile. 
> For example, disable local-break-out
David: Do you mean that you will use the "VPLMN address allowed" flag in the HLR ? Generally this flag is set to false and Home Routed is used by operators.
Use of Local Break Out means also that the APN name is recognized in visited network. 
I think it could be useful to include Local Break Out scenario in this document as it is envisaged at least for IMS services.  
> > differentiate between the two) is a good way to prevent IPv6 
> > subscribers from experiencing problems when roaming in 
> IPv4-only networks.
> 
David: Actually IPv6 PDP context has been specified for quite a long time and it is well supported in devices. As far as charging architecture is OK and visited operators does not filter
IPv6, I do not think it is the main issue in roaming context. IPv4v6 PDP context may bring more issues, in particular, if some visited SGSNs do not behave as they should do, considering unknown PDP
contexts as IPv4 ones.   
> > Tore
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Jul 2013 14:30:25 +0300

Gang,

I was more like thinking of IR.33, TAP documents and the IPv6 white paper,
etc stuff that GSMA has worked on. I think aligning with GSMA is important
since they are far more important for 3GPP roaming aspects than any IETF
document.

Then some other notes. When reading the draft I always get confused
when the draft assumes local breakout, when home routed traffic and
when a specific "phenomenon" is due visited/home APN/HLR intentional
configuration, licensing restriction or some known implementation
issue on some vendor equipment. Also some behaviour are due the UE
specific implementation beyond what 3GPP specs say. I would encourage
to detail these assumptions out on each claim/description so that
possible readers can map the issues to their deployments easier
without guesswork.

In Section 3.1 it states:

  "Subscriber Server).  When the subscriber roams to the IPv4 network,"

Does this mean the visited SGSN would not implement PDP Type IPv6? I
know such exist(ed) but how common are those on live today?

  "land to retrieve the subscriber profile.  Roaming with IPv4v6 type in
   the subscriber profile may cause issues because the visited SGSN/SGW
   can't parse the information.  The subscriber is failed to register in
   this case."

I guess you mean above SGSN/MME.. an SGW not implementing IPv4v6 would
be kind of surprising. I have seen a MME that did not implement IPv4v6 very
early of rel-8 testing phase, though. Here I would like to see text
describing what  is the actual failure scenario when the subscriber gets
no connection at all. I know one SGSN+HLR combination which is very
unlikely to happen in commercial networks.

In Section 3.2. it states:

  "of single IP version in order to achieve equivalent results.  Some
   operators may turn off the function only allow one PDP/PDN is alive
   for each subscriber.  For example, IPv6 PDP/PDN would be rejected if
   the subscriber has an active IPv4 PDP/PDN.  Therefore, the subscriber
   may lost IPv6 connection in the visited network.  Even the two"

I am confused here. Are we assuming visited GGSN here?

In Section 4.1. it states:

  "requested protocol and always adhere to IPv4 when roaming.  Those
   fallback mechanisms are deserved to be implemented and standardized
   timely."

Does the standardization mean fallback mechanisms beyond what 3GPP 
already defined?

- Jouni

On Jul 15, 2013, at 6:28 PM, GangChen <[email-masked]> wrote:

>>>> Of
>>>> Please

---

From: GangChen <[email-masked]>
Date: Fri, 19 Jul 2013 12:51:09 +0800

> feedback.  I have included it below.

Many thanks for your reviews/comments

> Section 2, there should be a mention of HLR

will add at the next version

> (extended-PDP-IP parameter)

Those are two different types. UE requests is a PDP/PDN message over
GTP. HLR/HSS send a subscriber's profile including supported PDP types
using Diameter. We will clarify that

> can go back and request another bearer with the secondary address type.

the texts are changed as:

A roaming subscriber with IPv4v6 PDP/PDN type should change the
request to IPv4 or IPv6 where the selection between IPv4 and IPv6 is
implementation specific. The mobile terminal should then initiate
another PDP Context Activation procedure to this APN in order to
activate a second PDP context with the other single address PDP type
which was not allocated by the network.

> home network,

The assumption is that visited networks will do local-breakout and
assign the address by the visited GGSN/PGW

> I really don¹t see why an operator who wants to eb IPv6-Only

> really the case.

The description intended to say IPv6-only PDP is a pre-R8 feature
compared to IPv4v6 PDP. Yes, the draft should consider implementation
aspects to suggest turn-on the function.

> But then, this section goes on to describe that a user

Here we actually consider the local-breakout case. Otherwise, there
are no issues if traffic would get back to home networks

> VPLMN local breakout is used but there is no mention of that.

The draft should mention that the failure happens if local breakout is
used. We will add at the next update

> network².

It can be more precise to say "Roaming behavior from a mobile terminal
sending IPv4v6 PDP/PDN"

> Our UEs will be requesting dual-stack to help with compatibility

We categorize the scenario depending on the requested PDP/PDN type. I
suppose the suitable network environment is a dual-stack network. As
you mentioned PGW may make further selection in the home network. I'm
not sure the reason PGW supporting IPv4v6 but only select single stack
ipv4, ipv6 address or home PGW only support single stack bearer, but
mobile phones ask IPv4v6 PDP/PDN.

Best Regards

Gang

---

From: GangChen <[email-masked]>
Date: Fri, 19 Jul 2013 12:59:57 +0800

Hi David,

2013/7/18, [email-masked] <[email-masked]>:
> David: Do you mean that you will use the "VPLMN address allowed" flag in the
> HLR ? Generally this flag is set to false and Home Routed is used by
> operators.
> I think it could be useful to include Local Break Out scenario in this
> document as it is envisaged at least for IMS services.

Some cases in the draft already assume local breakout condition. But I
guess it should be clarified in the next version.

> David: Actually IPv6 PDP context has been specified for quite a long time
> and it is well supported in devices.

In the previous message
http://www.ietf.org/mail-archive/web/v6ops/current/msg17187.html
Dave reported "Section 4.1 makes an assumption about support for IPv6
that has been in
place for as long as IPv4 and it is well supported. Given that this is an
optional feature that must be turned-on on vendor equipment, it¹s not
really the case."

I will add texts to suggest turn-on the IPv6 support

> As far as charging architecture is OK
> and visited operators does not filter
> IPv6, I do not think it is the main issue in roaming context.

If there is no breakout, IPv6-only doesn't have the issue.

> IPv4v6 PDP
> context may bring more issues, in particular, if some visited SGSNs do not
> behave as they should do, considering unknown PDP
> contexts as IPv4 ones.

I agree. We should consider that seriously

BRs

Gang

> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: GangChen <[email-masked]>
Date: Fri, 19 Jul 2013 15:36:47 +0800

Jouni,

> possible readers can map the issues to their deployments easier

I noticed that after the discussions on the list. We will complete the
descriptions to detail the assumed conditions. Also the GSMA document
would be cited to align the consideration.

> Does this mean the visited SGSN would not implement PDP Type IPv6?

The reason is visited SGSN doesn't support PDP Type IPv4v6, other than
PDP type IPv6. PDP type IPv6 has well been supported AFAIK.

>I know such exist(ed) but how common are those on live today?

When we do IPv6 trials, we have to upgrade all SGSN to understand PDP
Type IPv4v6. I also had some discussions with other operator
colleague. They also have same issues.

> early of rel-8 testing phase, though.

If I correct, SGSNs introduce IPv4v6 since Release-8; SGWs introduces
IPv4v6 since Release-9. You may be right it's a rare case if SGW
doesn't implement IPv4v6. The failure cases we are facing are mainly
on SGSN.  SGW is listed just because the rel-8 SGW implementations.
Thank you for the information there is no such case in the real world.
We will update the draft with your comments accordingly.

> Here I would like to see text

The failure scenario is subscriber can't register to the visited
network. Would you mind to add something to help me understand what's
your expected texts here?

> I am confused here. Are we assuming visited GGSN here?

Yes. The local breakout is considered here.

> Does the standardization mean fallback mechanisms beyond what 3GPP

A proper fallback mechanism is not defined in 3GPP.  The advocated
standardization more likes to do defacto standard. But the suggestion
is align with cuurent 3GPP spec. And some implementations are
available.

Best Regards

Gang

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 19 Jul 2013 11:35:24 +0300

Hi,

> PDP type IPv6. PDP type IPv6 has well been supported AFAIK.

Ok. But then what you write is not really what you intend to say. The network
in not IPv4 network, since it implements the IPv6 PDP Type. It is just the
standardized behavior that a Gn-based SGSN treats an unknown PDP Type as IPv4
PDP Type. In this case where a visited SGSN does understand IPv6 but not IPv4v6,
then it treats the context request as IPv4. That is different from the network
being IPv4.

Also, I would be careful when using SGSN and PDP Type IPv4v6. A Gn-based SGSN
had PDP Type IPv4v6 supported from Rel-9 onwards but S4-SGSN had since Rel-8. 
Also the treatment of unknown PDP/PDN type can be different from SGSN and S4-SGSN.

> colleague. They also have same issues.

I was talking about IPv4 _only_ SGSNs. Those were around and are still
possible e.g. due licensing/configuration.. not that it would make any
sense to have an IPv4-only SGSN around..

> IPv4v6 since Release-9. You may be right it's a rare case if SGW

Just the other way around. However, S4-SGSN had PDN Type IPv4v6 since Rel-8.

> your expected texts here?

Just list exactly what is configured in HLR, supported by SGSN and GGSN,
configured in GGSN and what the UE requests for. The combination and the
description why the combination fails is what people are interested in, IMHO. 

For the completeness, I would also like to see some discussion on the
DAF flag configuration in SGSN/MME, which also affects the context
creation end result.

> is align with cuurent 3GPP spec. And some implementations are

Ok.

- JOuni

---

From: GangChen <[email-masked]>
Date: Sat, 20 Jul 2013 22:07:25 +0800

2013/7/19, Jouni Korhonen <[email-masked]>:
> in not IPv4 network, since it implements the IPv6 PDP Type.

I just realize we may have different definition for "IPv4 network". In
my understanding, visited SGSN could implement PDP Type IPv6 in an
IPv4 network . But visited GGSN restricts IP address assignment only
to PDP type IPv4.

>It is just the
> then it treats the context request as IPv4.

The issue is not about SGSN receiving an unknow PDP request. That is
the home HSS sends the extended attribute for dual-stack as
a part of the subscriber profile. But old SGSN can't parse the
information and result failed registration.

> That is different from the
> network
> being IPv4.
>

That is a good clarification. We would add that in the next update.

> Just the other way around. However, S4-SGSN had PDN Type IPv4v6 since

Thanks for the correction.

> description why the combination fails is what people are interested in,

We would try to figure out the combination.

> DAF flag configuration in SGSN/MME, which also affects the context

Good. We will add it

Best Regards

Gang

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 20 Jul 2013 20:56:28 +0300

Gang,

> information and result failed registration.

The above are good examples that the draft needs to be much more exact
what it tries to say.  Specifically it needs to describe the assumed
network environment & configuration.

- Jouni

---

From: <[email-masked]>
Date: Tue, 23 Jul 2013 17:23:45 +0200

Hi all,

this is an interesting document that will help in the introduction of IPv6 and the combination of IPv4/IPv6 into mobile networks, however, I believe it needs a bit of evolution...

1. Can you distinguish between IP local breakout and home routed traffic, because there is a significant difference on what the visited network must support?
2. GSMA's IR.21 should be taken into account as well.
3. For home routed traffic, the visited network, and also the home network, have influence on the PDP context types that are successfully established, or that are rejected. Could this be described as well?

Should this document only enumerate "things that went wrong and lessons learnt", or should it go through all possible combinations of a roaming situation and provide information what does work and what does not work?

Holger

---

From: GangChen <[email-masked]>
Date: Wed, 24 Jul 2013 19:24:38 +0800

Hi Holger,

2013/7/23, [email-masked] <[email-masked]>:
> Hi all,
>
> this is an interesting document that will help in the introduction of IPv6
> and the combination of IPv4/IPv6 into mobile networks, however, I believe it
> needs a bit of evolution...

Thanks for your interests. The evolution would be made according to
discussions on the list.

> 1. Can you distinguish between IP local breakout and home routed traffic,
> because there is a significant difference on what the visited network must
> support?

We realized the importance to differentiate those two cases. Yes. It
will be distinguished.

> 2. GSMA's IR.21 should be taken into account as well.

It will be cited

> 3. For home routed traffic, the visited network, and also the home network,
> have influence on the PDP context types that are successfully established,
> or that are rejected. Could this be described as well?

Yes. As suggested by Jouni, the combination of HLR configuration, UE
PDP context requests and visited network supported will be described
in the next update.

> Should this document only enumerate "things that went wrong and lessons
> learnt", or should it go through all possible combinations of a roaming
> situation and provide information what does work and what does not work?

The original draft is trying to circulate all the possible roaming
cases, and, make a detailed description/analysis to the failure cases.
The audience could check with their own conditions.
We would also like to hear the group's opinions. The wg inputs are
most important to the document's evolution.

Best Regards

Gang

---

From: "cb.list6" <[email-masked]>
Date: Sun, 28 Jul 2013 08:48:11 -0700

As general feedback

1. As others have noted, it is important to clarify that home routed
is the default case and local-breakout is only relavent for IMS, but
IMS based roaming and local breakout is yet to see its first
deployment, and may still be years in the future for roaming to work
this way.  So, local breakout is not  a real case and seems to be
causing more confusion.

2.  There is a hazard in assuming the well known prefix is always
available.  Any device should not assume the well known prefix is
available.  This is essentially a misconfiguration that should not
occur.

3.  What i have learned

a.  dual-stack 2 PDP will never work, charging issues in the billing
system, and too much capacity wasted for no real gain

b.  dual-stack 1 PDP (v4v6) will not work any time soon.  Enabling
this feature in the HSS/HLR breaks roaming and there is no way to
ensure this issue is fixed in the hundreds of networks that are
potentially impacted.  There are some backs to do on the home network
that can make this easier but not exposing partner networks to the new
release 8 features.

c.  What does work and adds value (saves IPv4 address for the common
case of not-roaming) :  IPv6-only single PDP 464XLAT on the home
network, IPv4-only single PDP when roaming.  This is how i am moving
forward.  The when at home, the UE has default configs for ipv6-only
and when roaming the ue only attempts to connect using IPv4.  This
gets the vast majority of users in my home network off v4 and keeps
ipv4 for the complicated yet relatively small percentage of roaming
users.

---

From: GangChen <[email-masked]>
Date: Mon, 29 Jul 2013 02:23:21 +0800

Hi Cameron,

Thank you for the comments.

> is the default case and local-breakout is only relavent for IMS, but

local-breakout may not be only for IMS. We have deployed that for the
data roaming between different province's networks in China. It offers
efficient routes. Besides, 3GPP specified the SIPTO architecture for
roaming. That may bring impacts in the future.

> available.  This is essentially a misconfiguration that should not

Ok. You don't recommend using WKP. How about taking different priority
for the deployment

High priority:  nat64-discovery
Medium: WKP
Low: manual configuration

> ipv4 for the complicated yet relatively small percentage of roaming

Thanks for the good summary. That is the lesson we have leaned.

BRs

Gang

---

From: GangChen <[email-masked]>
Date: Mon, 29 Jul 2013 02:25:04 +0800

Hi Cameron,

> is the default case and local-breakout is only relavent for IMS, but

local-breakout may not be only for IMS. We have deployed that for all
the data roaming between different province's networks in China. It
offers efficient routes. Besides, 3GPP specified the SIPTO
architecture for roaming. That may bring impacts in the future.

BRs

Gang

---

From: "cb.list6" <[email-masked]>
Date: Sun, 28 Jul 2013 13:34:12 -0700

Gang,

> roaming. That may bring impacts in the future.

AFAIK, these are very different cases, but i do not know much about SIPTO

 SIPTO requires that the UE have an IP address from the home network.
So, in SIPTO cases, my customers always have an IP address from my
network and they also have an IP address from LAN.  In this way, SIPTO
is still home routed.

The IMS case, your receive the IP address from the visited network.
So, when my IMS subscribers roam to your network, they no longer have
an IP address from my network, they only have an IP address from the
visited network.

> Low: manual configuration

I would not put it that way, i would just say discovery is best.
Discovery can discover the wkp or nsp.

Manual configuration of pref64, wkp or nsp, can result in a lot of
trouble for nomadic / mobile nodes.

> Thanks for the good summary. That is the lesson we have leaned.

Then it must be a BCP :)

CB

---

From: GangChen <[email-masked]>
Date: Mon, 29 Jul 2013 05:20:02 +0800

> network and they also have an IP address from LAN.  In this way, SIPTO

The SIPTO process can be found at TS 23.060(R10) clause 5.3.12 and TS
23.401 clause 4.3.15. Once the proper GGSN is selected, the SGSN
should deactivate the attached subscribers. The subscriber should
initiate another PDP/PDN requests to the selected GGSN. So, I guess
the assigned address would belong to the visited network.

> an IP address from my network, they only have an IP address from the

I will add it to the draft. thanks

> trouble for nomadic / mobile nodes.

Yes. but do you have better idea in the case of non-DNS64?

>> Thanks for the good summary. That is the lesson we have leaned.

I'm in favor of the BCP ;)

BRs

Gang

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 29 Jul 2013 11:01:31 +0300

> architecture for roaming. That may bring impacts in the future.

Just to understand this better.. Does "data roaming between different
province's networks" mean the province's networks have different PLMN
codes? Do these "province's networks" belong to different operators or
to the same operator (from the administration/business point of view)?

- Jouni

---

From: GangChen <[email-masked]>
Date: Mon, 29 Jul 2013 18:10:35 +0800

> to the same operator (from the administration/business point of view)?

The different province's networks belong to the same operator. The
local-breakout roaming is enabled by adding APN-OI replacement into a
subscriber's profile

BRs

Gang

---

From: Czerwonka Michał - Hurt TP <[email-masked]>
Date: Mon, 29 Jul 2013 11:33:54 +0000

+1

NO IPv6 in roaming :(

BR,
Mcz

-----Wiadomość oryginalna-----
Od: [email-masked] [mailto:[email-masked]] W imieniu cb.list6
Wysłano: 28 lipca 2013 17:48
Do: Fred Baker
DW: IPv6 Ops WG; [email-masked]
Temat: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis

As general feedback

3.  What i have learned

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 29 Jul 2013 15:13:13 +0300

> local-breakout roaming is enabled by adding APN-OI replacement into a

So the PLMN codes are the same for all provinces? If that is the case, then
what you are doing hardly is "roaming" rather an intelligent gateway
selection.

Is the VPLMN dynamic address allowed flag set to ALLOWED? Does the APN-OI
replacement change dynamically in the subscriber profile based on the 
UE location or is it configured "statically" based on where the subscription
is assumed to be used most of the time?

- JOuni

---

From: GangChen <[email-masked]>
Date: Mon, 29 Jul 2013 21:31:46 +0800

> what you are doing hardly is "roaming" rather an intelligent gateway

That is a good question. At http://en.wikipedia.org/wiki/Roaming, the
roaming has been interpreted as "In wireless telecommunications,
roaming is a general term referring to the extension of connectivity
service in a location that is different from the home location where
the service was registered." Roaming behavior is justified by whether
the visited network has subscriber's registration information. MNC+MCC
may not be the matter.

> is assumed to be used most of the time?

The APN-OI replacement is configured in a static way and assumed to be
used in most times.

-Gang

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Jul 2013 16:58:58 +0200

> but in my experience it Just Works there, too.

As regards Japan, you got lucky. NTT does not support IPv6 roaming, and
Softbank was fixed a few weeks (days?) before you arrived.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 29 Jul 2013 18:01:12 +0300

> the visited network has subscriber's registration information. MNC+MCC

In 3GPP sense, you are in a visited network when the MNC+MCC codes
do not match your own expected HPLMN or EHPLMNs. I would stick with
3GPP definition of roaming when describing 3GPP specific things. I
agree that that a "HPLMN" may consist multiple PLMN codes. Again I
would be careful with the terminology when you mean a visited network
gateway or when a gateway (visited or home) that is topologically
selected close to the UE.. just to avoid confusion.

- Jouni

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 29 Jul 2013 19:00:51 +0000

Hi Cameron,

Could you please share more details about 3a and 3b below?

WOuldn't the UE fallback to v4 PDP, if v4v6 PDP wasn't available?

Cheers,
Rajiv

-----Original Message-----
From: Cameron Byrne <[email-masked]>
Date: Sunday, July 28, 2013 11:48 AM
To: "Fred Baker (fred)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis

>>Please take a look at it and comment.

---

From: "cb.list6" <[email-masked]>
Date: Mon, 29 Jul 2013 12:59:37 -0700

Rajiv

> Could you please share more details about 3a and 3b below?

Can you be more specific about the question?

Charging systems have a hard time to reconcile usage from 2 PDP
because they are 2 separate CDRs, 1 for each PDP.  Also, 2 PDP is 2x
as expensive in terms of signalling and licensing.

v4v6 as single PDP is not viable because not everything supports
release 8 in the GSM/3GPP ecosystem.  I tried to enable v4v6 for my
subscribers in my central database (HLR/HSS), and adding this
capability to all my subscribers made some existing ipv4 roaming
subscribers fail.   Why?  Because when my users attach into a roaming
partner network, their network downloads the capabilities of the
subscriber from my database (HLR/HSS)... and if one of the
capabilities includes v4v6, then the roaming partners's equipment
drops the users because they don't understand this term.

This is a roaming partner network device acting in a bad and
non-standard way.  It's a shame i have to turn off v4v6 globally
because of this issue.  There is one subscriber database, and because
some roaming partner gear fails, it is not safe to turn anywhere.  One
remediation is to limit attributes based on a whitelist / blacklist,
but this is not feature available today.

Luckily, the good people of v6ops have approved RFC6877 and Android
implemented it in 4.3 , so single v6 PDP works ok.

> WOuldn't the UE fallback to v4 PDP, if v4v6 PDP wasn't available?

Yes, it's supposed to work that way.  But, keep in mind what i said
above.  In the real world, it does not (for now, once everyone
upgrades maybe this wont be a problem).

Cameron

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 30 Jul 2013 17:55:48 +0100

Hi Cameron,

> b.  dual-stack 1 PDP (v4v6) will not work any time soon.  Enabling
this
> feature in the HSS/HLR breaks roaming and there is no way to ensure
> this issue is fixed in the hundreds of networks that are potentially
> impacted.  There are some backs to do on the home network that can
make
> this easier but not exposing partner networks to the new release 8
> features.

[NH] Cameron I assume you referring to the issue of extended MAP (for
Ipv4v6) causing exception at the visited operator's network? Thanks for
highlighting this issue. I guess I would like to know if the number of
problem operators is significant, or a few isolated cases. Do you or
anyone have information to infer this is widespread or systemic? If it
is unknown lets acknowledge it as such.
If cases are isolated, then there may be operational actions a dual
stack operator can take; for sake of argument, a roaming steering
solution could be applicable to blacklist a problem operator and steer
the outbound roamers away before the exception occurs.
I have not yet arrived at the conclusion that ipv4v6 roaming cannot be
made to work, but perhaps I haven't seen the extent of the problem?
Regards,
Nick
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. 

Everything Everywhere Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW

---

From: "cb.list6" <[email-masked]>
Date: Wed, 31 Jul 2013 21:40:35 -0700

Hi Nick,

On Jul 30, 2013 9:55 AM, "Heatley, Nick" <[email-masked]> wrote:
> Ipv4v6) causing exception at the visited operator's network?

Yes

Thanks for
> problem operators is significant, or a few isolated cases. Do you or

We saw a widespread issue in the 10 minutes before we rolled back the
changes.

> anyone have information to infer this is widespread or systemic? If it

The vendors gear / involved is highly deployed, afaik

> the outbound roamers away before the exception occurs.

Well, there is money involved in steering. Money is usually top of mind
for  the folks  involved,  not v6.

> made to work, but perhaps I haven't seen the extent of the problem?

I am sure it can be made to work, I am just noting there is operational
risk. I know because we hit it, but  our ops folks had the presence of mind
to roll back quickly

In the long run, we plan to have whitelist for the v4v6 extended
attribute,  but HLR features are on an 18 month cycle for us.  We would
like all our apns to support any combination  of v4, v4v6, or v6. But we
can only safely support v4 or v6 in 2013.  In the 2nd half of 2014, we may
be able to try v4v6 again.

CB

> Regards,
> Nick
> 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.