Subject: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis (GangChen)

From: Pete Vickers <[email-masked]>
Date: Thu, 25 Jul 2013 09:18:09 +0200

Some minor typos & comments on your doc:

2.  Roaming Descriptions
dual-tack -> dual-stack
That are -> They are
equipments -> equipment
restored -> stored
different IPv6 supports -> different IPv6 support
The following is like to document the failure cases -> The following are likely failure cases scenarios (?)

3.2.  Roaming to early dual-stack networks
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.  Some
operators may turn off the function only allow one PDP/PDN is alive
for each subscriber. 

This is also likely to fail in more subtle ways, e.g. a visited network commonly permits two concurrent PDP, since it is usual for MMS (picture messaging) services to be accessed via a seperate APN to Internet services. Thus if both available PDPs are in use for IPv4+IPv6 Internet access, then attempts to send/recieve picture messages would (silently?) fail due to lack of PDP resourses. 

Therefore, the subscriber may lost -> lose IPv6 connection in the visited network
Even /if/ the two parallel PDP/PDN activations are allowed

4.1.  Roaming to IPv4-only networks
Those fallback mechanisms 'are deserved' -> 'deserve' to be implemented and standardized

5.  Discussions
but didn't support /it/ well in the third generation network.
The situations may cause the roaming issues/,/ dropping

As an alternative solution for dual-stack, operators may change a
unified PDP/PDN request into two separated single IP version
requests.  However, this approach is problematic in the Charging
records and QoS policy enforcement.  In addition, it doubles the PDP
resource uses.  It may be unappealing for the deployment.

I think you should also add 'licensing costs' to the point about additional PDP resource usage - that is a very significant issues in many operators.

There are also several other failure senarios, for example where the visited operator has a 'Gp' (GRX border) GTP aware firewall, and this (by design or inappropriate configuration) filters out GTP traffic containing certain flavours of IPv6 PDP requests/responses.  It may thus be approriate to mention that connectivity/security devices can also cause  IPv6 related roaming issues.

I agree with the comment about IR.21 - the purpose of that document (and the IREG testing procedure that reference it) is to ensure that such issues are identified and corrected such that roaming is seamless. As Deng commented to me on Google's mobile-ipv6-networks group several months ago, the IR.21 appears overdue an update. However I note that IR.88 is the equivalent for LTE/EPC environments, so perhaps that is more appropriate ?

/Pete

---

From: GangChen <[email-masked]>
Date: Sat, 27 Jul 2013 14:00:30 +0800

Hi Pete,
Thank you for the times to review. Sorry for the delay (I'm being the
trip to IETF meeting)

> likely failure cases scenarios (?)

I will fix those in the next update

> This is also likely to fail in more subtle ways, e.g. a visited network
> commonly permits two concurrent PDP, since it is usual for MMS (picture
> messaging) services to be accessed via a seperate APN to Internet services.
> Thus if both available PDPs are in use for IPv4+IPv6 Internet access, then
> attempts to send/recieve picture messages would (silently?) fail due to lack
> of PDP resourses.
>

Your case seems assuming only two PDP activation are allowed for each
subscriber. I'm not sure that is a common case. It may be different
with my experience. Multiple PDPs are allowed to be activated if a
subscriber intends to access separated APNs.

> Even /if/ the two parallel PDP/PDN activations are allowed

I guess it may be worth to list your consumption, for example "in some
cases a subscriber only allowed to activate two PDP contexts, ..."

> I think you should also add 'licensing costs' to the point about additional
> PDP resource usage - that is a very significant issues in many operators.
>
Good. I will add it.

>
> There are also several other failure senarios, for example where the visited
> operator has a 'Gp' (GRX border) GTP aware firewall, and this (by design or
> inappropriate configuration) filters out GTP traffic containing certain
> flavours of IPv6 PDP requests/responses.  It may thus be approriate to
> mention that connectivity/security devices can also cause  IPv6 related
> roaming issues.

Thanks for sharing your experiences. That may be caused by incorrect
configurations on the firewall. I will add the suggestion to avoid the
issue.

>
> I agree with the comment about IR.21 - the purpose of that document (and the
> IREG testing procedure that reference it) is to ensure that such issues are
> identified and corrected such that roaming is seamless. As Deng commented to
> me on Google's mobile-ipv6-networks group several months ago, the IR.21
> appears overdue an update. However I note that IR.88 is the equivalent for
> LTE/EPC environments, so perhaps that is more appropriate ?
>
IR.88 didn't deprecate the IR.21. They cover different areas. IR.88
cited IR.21 as a reference for roaming database configuration. I would
include both for a complete view.

Best Regards

Gang

---

From: Pete Vickers <[email-masked]>
Date: Sun, 28 Jul 2013 11:15:10 +0200

> subscriber intends to access separated APNs.

Sorry for the lack of clarity, my intension was not to make any assumption/example of common cases; instead it was an attempt to show how the introduction of IPv6 services can 'break' other unrelated services in non-obvious ways.