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

From: GangChen <[email-masked]>
Date: Sat, 21 Sep 2013 16:33:03 +0800

Hi Dave,

thank you for the comments. Please see my reply inline.

2013/9/20, Dave Michaud <[email-masked]>:
> Hi Gang,
>
> There has been a lot of comments on this draft already and a presentation at
> IETF87 but nothing has been included in a revised version yet so it's
> difficult to have a clear view of where we stand at this point and comment
> further.
As you may know, there is a design team to polish the draft. We intend
to speed up the revision by gathering the comments from participants.
You are welcome to join.

> Nonetheless, I'd like to share our own experience in deploying IPv6 for our
> home subscribers and the expected roaming impact. I guess it can serve as
> input for this draft or for a future BCP. Our target is to enable IPv6-only
> (and not dual-stack) for as many subscriber as we can, roaming or not but
> obviously we want to ensure that the service keeps working as it does today.
> We are also not using vPLMN local breakout (which is the case for most
> operators) but may change for IMS situations in the future.

Thank you for the inputs. Your comments will be incorporated into the
next revision. Please see more detailed discussions as below.

> ---- UE Configuration ----
> UE can be set to request a PDP/PDN Type IPv4, IPv4v6 or IPv6. Certain UE
> have the ability a different configuration for home network / visited
> network. Since this is related to roaming case, my comments apply to the
> roaming profile or the home/roaming profile if there is no distinction. This
> is what the UE request, not necessarily the final PDP/PDN Type...
>
> - IPv4: has been working for years, no issue
> - IPv6: if the UE request IPv6-only and a node in the path can't support it
> (ie. visited SGSN), there is no possible fallback and data is broken. This
> configuration should be avoided.
> - IPv4v6: this is least supported configuration (based on required 3GPP
> release in SGSN) but also the configuration that offers the most
> flexibility. As per 3GPP 24.008, this PDP/PDN Type should be interpreted as
> IPv4 by the SGSN/MME if it doesn't understand it.
>
> We have had some UE models configured to request this PDP/PDN type in
> circulation for over a year now and we have observed cases where the vSGSN
> was simply rejecting the PDP Context Creation message with a cause code #27
> (Unknown or missing APN) because it stopped processing the message at the
> PDP type (APN name comes right after). This however has been an extremely
> limited corner case with 2 confirmed operators.

That is the case we are also observing for the time being. I guess we
have to justify whether that is a corner case, because I heard the
issue from at least 2 operators.

>Ultimately, we are now
> configuring most UE to request IPv4v6 while roaming (we kept some flagship
> devices as IPv4-only for now as we build a database of working PLMNs).

If the behavior complies with 24.008, IPv4v6 roaming is a workable
solution. But, how could this recommendation related to your goal(i.e.
Our target is to enable IPv6-only (and not dual-stack)?

> ---- SGSN/MME for Mobility Management Procedures (Attach) ----
> On attach, the SGSN/MME must contact the home HLR/HSS and obtain the
> subscriber profile. It is well known now and has been observed first hand by
> some of us here that multiple SGSN/MME will be unable to correctly process a
> subscriber profile received in the Insert Subscriber Data procedure if it
> contains an Ext-PDP-Type (3GPP TS 29.002 / 3GPP TS 29.060). In that case, it
> breaks data so this situation must be avoided.
>
> Details on the solution are in the HLR section below but ultimately, unless
> we know for sure that an SGSN (and the operator in general as per IR.21),
> the SGSN will receive a subscriber profile that contains IPv4-only as the
> available PDP type (not presence of IPv6 at all).
>
> At this stage, the SGSN should therefore receive a subscriber profile
> containing only fields it can understand and this attach will complete
> successfully.

Yes. That is the issue identified in the current draft. We didn't
provide the solution, because the draft not intends to make a
suggestion to modify 3GPP node. That is the conclusion from last
meeting discussion. The solution you described below may be an
approach to solve the issue. If that is formally published or planned
to be a 3GPP CR, the draft may include to convey this information.

> ---- SGSN/MME for Session Management Procedures (PDP Context/Bearer) ----
> When the SGSN/MME receives a session creation request from the UE (PDP/PDN
> Type IPv4v6), the following situations are possible:
>
> 1. SGSN/MME does not understand IPv4v6 so it falls back to IPv4 as per spec
> 2. SGSN/MME understands IPv4v6 but the subscriber profile did not contain
> Ext-PDP-Type so it falls back to IPv4
> 3. SGSN/MME understands IPv4v6 but as per a local policy does not allow it
> so it falls back to IPv4
>    a. IPv6 billing not supported
>    b. IPv6 not licensed
>    c. Local decision...
> 4. SGSN/MME does not understand IPv4v6 and it does not fall back to IPv4.
>
> Point 4 is for us the most critical aspect and the one we are following
> closely.
>
> Based on the above options, the SGSN/MME forwards to the GGSN/S-GW a session
> creation request with either a PDP Type of IPv4 or IPv4v6.

To be clear, SGSN/MME would forward a PDP Type of IPv4 in the case of #1,2,3
Would SGSN/MME in #4 directly reject the request?

> ---- HLR/HSS ----
> When the HLR receives an Update GPRS Location message, it has to provide the
> subscriber profile to the requesting entity. All subscribers have their APNs
> set for IPv4-only with extended PDP support (IPv4v6).
>
> When receiving this message, the HLR compares the SGSN VLR address with a
> whitelist database and decide if the SGSN is deemed IPv6 compliant. At
> first, this database will be empty but as IPv6 support is confirmed through
> either testing, confirmation from the operator or the IR.21, we will
> populate this database.
>
> Ultimately, the HLR sends out a profile that either contains IPv4 only or
> IPv4 + IPv4v6 based on this whitelist database.
>
> Unfortunately, this is not yet a standard feature in any HLR but our HLR
> vendor has been cooperative to develop this market customization for us.
>
> ---- GGSN/S-GW/P-GW ----
> When the GGSN/P-GW receives a session creation request, it came in as either
> IPv4 or IPv4v6 (see SGSN/MME for Session Management). The APNs on the
> GGSN/P-GW that the customers are requesting are configured to support IPv4v6
> (and by extension IPv4-only and IPv6-only). On session creation request, the
> GGSN/P-GW sends an Access-Request to a AAA server, sending the vSGSN
> MCC+MNC, the IMEI and the PDP Type received.
>
> The AAA Access-Accept contains a new APN name that the GGSN/P-GW will use to
> effectively establish the session. The redirection APN is used make a final
> selection on the IP type used (IPv4 or IPv6 or IPv4v6)
>
> Requested APN: internet
> Possible AAA output: v4.internet, ds.internet or v6.internet
>
> ---- AAA Server ----
> The AAA receives the Access-Request from the GGSN/P-GW. It implements a
> logic that will ultimately decide what type of PDP we should use for this
> session.
>
> The following checks are performed:
> - Requested PDP Type: if IPv4 or IPv6, any change will break the data
> session so allow as is (v4 would be for older devices or a fallback scenario
> along the path; v6 would be because the user reconfigured his UE to directly
> request IPv6 instead of the default IPv4v6)
> - SGSN MCC-MNC: without a confirmation that this PLMN ID supports IPv6,
> fallback to IPv4
> - IMEI: extract TAC and SV components and verify if device has 464XLAT
> support. If it does, allow IPv6-only, otherwise allow dual-stack
>
> Based on the above checks, the AAA will decide which APN to send the
> customer to and this is what will ultimately decide if we allow IPv6-only
> roaming or not.

AAA is located in the Gi/SGi interface. If the signal comes to AAA
server, that means there is no issues with the interworking between
vSGSN/SGW and HSS/HLR.
If I understand correctly, you may recommend using AAA server to guide
the user's request to IPv6-only+464xlat or dual-stack or IPv4 fallback
As per 23.401 and 29.061, AAA server is one of deployment options. Did
you evaluate if the recommendation is applicable widely?

Best Regards

Gang

>
> Dave Michaud
>
>
>
>
> This e-mail (and attachment(s)) is confidential, proprietary, may be subject
> to copyright and legal privilege and no related rights are waived. If you
> are not the intended recipient or its agent, any review, dissemination,
> distribution or copying of this e-mail or any of its content is strictly
> prohibited and may be unlawful. All messages may be monitored as permitted
> by applicable law and regulations and our policies to protect our business.
> E-mails are not secure and you are deemed to have accepted any risk if you
> communicate with us by e-mail. If received in error, please notify us
> immediately and delete the e-mail (and any attachments) from any computer or
> any storage medium without printing a copy.
>
> Ce courriel (ainsi que ses pièces jointes) est confidentiel, exclusif, et
> peut faire l’objet de droit d’auteur et de privilège juridique; aucun droit
> connexe n’est exclu. Si vous n’êtes pas le destinataire visé ou son
> représentant, toute étude, diffusion, transmission ou copie de ce courriel
> en tout ou en partie, est strictement interdite et peut être illégale. Tous
> les messages peuvent être surveillés, selon les lois et règlements
> applicables et les politiques de protection de notre entreprise. Les
> courriels ne sont pas sécurisés et vous êtes réputés avoir accepté tous les
> risques qui y sont liés si vous choisissez de communiquer avec nous par ce
> moyen. Si vous avez reçu ce message par erreur, veuillez nous en aviser
> immédiatement et supprimer ce courriel (ainsi que toutes ses pièces jointes)
> de tout ordinateur ou support de données sans en imprimer une copie.
>

---

From: "Dave Michaud" <[email-masked]>
Date: Mon, 23 Sep 2013 10:32:52 -0400

Clarifications/comments are inline

Dave Michaud

> -----Original Message-----
> From: GangChen [mailto:[email-masked]]
> Sent: Saturday, September 21, 2013 4:33 AM
> To: Dave Michaud
> Cc: IPv6 Ops WG; [email-masked]; Jouni;
> Cameron Byrne; Victor Kuarsingh; Vízdal Aleš; Hui Deng; [email-masked]; John
> Jason Brzozowski; BINET David IMT/OLN; [email-masked]
> Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis
> 
> Hi Dave,
> 

I'd be more than willing to participate.

> issue from at least 2 operators.

All the failures we have observed are in Korea. I am trying to obtain an exact list of devices currently set to request IPv4v6 while roaming and will run an analysis on our CDRs to build a list of operators where this configuration has worked correctly.

> Our target is to enable IPv6-only (and not dual-stack)?

As detailed below, we have the UE request IPv4v6 so that we keep full flexibility in further controlling the type of PDP from the network. If the UE requests IPv4 or IPv6, we cannot override it from the network.

> Would SGSN/MME in #4 directly reject the request?

This is the corner case we observed in Korea and the SGSN/MME rejects the request but it doesn't use an appropriate error code.
In both cases observed, the rejection came with cause code #27 (Missing or unknown APN).

> server, that means there is no issues with the interworking between

There is no interworking issue but it is still possible that the visited network changed the PDP type from IPv4v6 to IPv4.

> you evaluate if the recommendation is applicable widely?

The standard deployment option as per the spec would be to perform IP address allocation through the AAA server and thus decide the type of resource to allocate. From my understanding, it is a valid and widely deployable option.

In our case however, we are not using AAA for IP allocation so this was not the best option. We are currently using a local pool (on the GGSN/P-GW) and moving towards a DHCP.

What is however available from our equipment vendor is the ability to modify the UE requested APN by returning AVP Called-Station-Id with a new APN name in the Access-Accept message. This "selected" APN is configured on the GGSN/P-GW to be either IPv4-Only, IPv6-Only or dual-stack with no further AAA Authentication procedures.

UE requested APN: data
AAA selected APN: v4.data or v6.data or ds.data

Dave Michaud

This e-mail (and attachment(s)) is confidential, proprietary, may be subject to copyright and legal privilege and no related rights are waived. If you are not the intended recipient or its agent, any review, dissemination, distribution or copying of this e-mail or any of its content is strictly prohibited and may be unlawful. All messages may be monitored as permitted by applicable law and regulations and our policies to protect our business. E-mails are not secure and you are deemed to have accepted any risk if you communicate with us by e-mail. If received in error, please notify us immediately and delete the e-mail (and any attachments) from any computer or any storage medium without printing a copy.

Ce courriel (ainsi que ses pièces jointes) est confidentiel, exclusif, et peut faire l’objet de droit d’auteur et de privilège juridique; aucun droit connexe n’est exclu. Si vous n’êtes pas le destinataire visé ou son représentant, toute étude, diffusion, transmission ou copie de ce courriel en tout ou en partie, est strictement interdite et peut être illégale. Tous les messages peuvent être surveillés, selon les lois et règlements applicables et les politiques de protection de notre entreprise. Les courriels ne sont pas sécurisés et vous êtes réputés avoir accepté tous les risques qui y sont liés si vous choisissez de communiquer avec nous par ce moyen. Si vous avez reçu ce message par erreur, veuillez nous en aviser immédiatement et supprimer ce courriel (ainsi que toutes ses pièces jointes) de tout ordinateur ou support de données sans en imprimer une copie.

---

From: "Dave Michaud" <[email-masked]>
Date: Mon, 23 Sep 2013 16:55:43 -0400

Thanks for the clarifications on differences between SGSN and MME. We still have limited LTE roaming so we are not running into these issues yet...

Regarding your question about our GPRSSubscriptionData in the HLR, I can't tell for sure about this one. Given Cameron's experience, we stopped the deployment and requested a patch from our HLR vendor before it went live.

Dave Michaud

> From: Jouni Korhonen [mailto:[email-masked]]
> Sent: Monday, September 23, 2013 3:55 PM
> To: Dave Michaud
> Cc: GangChen; IPv6 Ops WG; draft-chen-v6ops-ipv6-roaming-
> [email-masked]; Cameron Byrne; Victor Kuarsingh; Vízdal Aleš; Hui
> Deng; [email-masked]; John Jason Brzozowski; BINET David IMT/OLN;
> [email-masked]
> Just some nitpicking inline. Great stuff btw and thanks for sharing it.
> 
> On Sep 20, 2013, at 5:10 PM, Dave Michaud <[email-masked]>
> wrote:
> 
> > Hi Gang,
> >
> IETF87 but nothing has been included in a revised version yet so it's difficult to
> have a clear view of where we stand at this point and comment further.
> >
> input for this draft or for a future BCP. Our target is to enable IPv6-only (and
> not dual-stack) for as many subscriber as we can, roaming or not but obviously
> we want to ensure that the service keeps working as it does today. We are also
> not using vPLMN local breakout (which is the case for most operators) but may
> change for IMS situations in the future.
> >
> have the ability a different configuration for home network / visited network.
> Since this is related to roaming case, my comments apply to the roaming
> profile or the home/roaming profile if there is no distinction. This is what the
> UE request, not necessarily the final PDP/PDN Type...
> >
> > - IPv6: if the UE request IPv6-only and a node in the path can't support it (ie.
> visited SGSN), there is no possible fallback and data is broken. This
> release in SGSN) but also the configuration that offers the most flexibility. As
> per 3GPP 24.008, this PDP/PDN Type should be interpreted as IPv4 by the
> SGSN/MME if it doesn't understand it.
> 
> Regarding the MME part see below.
> 
> limited corner case with 2 confirmed operators. Ultimately, we are now
> subscriber profile received in the Insert Subscriber Data procedure if it contains
> an Ext-PDP-Type (3GPP TS 29.002 / 3GPP TS 29.060). In that case, it breaks data
> so this situation must be avoided.
> 
> Yep. SGSNs prior release-9 (or in some cases pre-rel-8) are not supposed to
> understand Ext-PDP-Type.. and sadly reject the context request entirely on
> cases I came across. Postel's law does not seem to apply here ;)
> 
> Btw, just asking for clarification. Did your GPRSSubscriptionData contain
> multiple PDP-Contexts or only one (the one with Ext-PDP-Type)?
> 
> 
> > Details on the solution are in the HLR section below but ultimately, unless we
> know for sure that an SGSN (and the operator in general as per IR.21), the SGSN
> will receive a subscriber profile that contains IPv4-only as the available PDP
> type (not presence of IPv6 at all).
> >
> > When the SGSN/MME receives a session creation request from the UE
> (PDP/PDN Type IPv4v6), the following situations are possible:
> >
> MME should not fall back to IPv4.. for EPC nodes unknown PDN Type is
> supposed to be treated as IPv6.
> 
> MME should not be affected by Gr interface (unless there is some IWF setup in
> place)..
> 
> Same as 1.
> - Jouni
> > Point 4 is for us the most critical aspect and the one we are following closely.
> >
> > Based on the above options, the SGSN/MME forwards to the GGSN/S-GW a
> session creation request with either a PDP Type of IPv4 or IPv4v6.
> >
> > ---- HLR/HSS ----
> > When the HLR receives an Update GPRS Location message, it has to provide
> the subscriber profile to the requesting entity. All subscribers have their APNs
> whitelist database and decide if the SGSN is deemed IPv6 compliant. At first,
> this database will be empty but as IPv6 support is confirmed through either
> testing, confirmation from the operator or the IR.21, we will populate this
> database.
> >
> > Ultimately, the HLR sends out a profile that either contains IPv4 only or IPv4 +
> IPv4v6 based on this whitelist database.
> >
> > When the GGSN/P-GW receives a session creation request, it came in as
> either IPv4 or IPv4v6 (see SGSN/MME for Session Management). The APNs on
> the GGSN/P-GW that the customers are requesting are configured to support
> IPv4v6 (and by extension IPv4-only and IPv6-only). On session creation request,
> the GGSN/P-GW sends an Access-Request to a AAA server, sending the vSGSN
> > The AAA Access-Accept contains a new APN name that the GGSN/P-GW will
> use to effectively establish the session. The redirection APN is used make a final
> logic that will ultimately decide what type of PDP we should use for this session.
> >
> > - Requested PDP Type: if IPv4 or IPv6, any change will break the data session
> so allow as is (v4 would be for older devices or a fallback scenario along the
> path; v6 would be because the user reconfigured his UE to directly request IPv6
> instead of the default IPv4v6)
> > This e-mail (and attachment(s)) is confidential, proprietary, may be subject to
> copyright and legal privilege and no related rights are waived. If you are not
> the intended recipient or its agent, any review, dissemination, distribution or
> copying of this e-mail or any of its content is strictly prohibited and may be
> unlawful. All messages may be monitored as permitted by applicable law and
> regulations and our policies to protect our business. E-mails are not secure and
> you are deemed to have accepted any risk if you communicate with us by e-
> mail. If received in error, please notify us immediately and delete the e-mail
> (and any attachments) from any computer or any storage medium without
> printing a copy.
> >
> > Ce courriel (ainsi que ses pièces jointes) est confidentiel, exclusif, et peut
> faire l’objet de droit d’auteur et de privilège juridique; aucun droit connexe
> n’est exclu. Si vous n’êtes pas le destinataire visé ou son représentant, toute
> étude, diffusion, transmission ou copie de ce courriel en tout ou en partie, est
> strictement interdite et peut être illégale. Tous les messages peuvent être
> surveillés, selon les lois et règlements applicables et les politiques de
> protection de notre entreprise. Les courriels ne sont pas sécurisés et vous êtes
> réputés avoir accepté tous les risques qui y sont liés si vous choisissez de
> communiquer avec nous par ce moyen. Si vous avez reçu ce message par
> erreur, veuillez nous en aviser immédiatement et supprimer ce courriel (ainsi
> que toutes ses pièces jointes) de tout ordinateur ou support de données sans en
> imprimer une copie.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 24 Sep 2013 08:30:04 +0300

> Regarding your question about our GPRSSubscriptionData in the HLR, I can't tell for sure about this one. Given Cameron's experience, we stopped the deployment and requested a patch from our HLR ven…

I am just interested on the GPRSSubscriptionData because if the SGSN would not drop whole GPRSSubscriptionData based on one PDP-Context it does not understand, then it could be possible to include another PDP-Type IPv4 PDP-Context for the same APN in the GPRSSubscriptionData.. and the SGSN could supposedly use that. I am sure I tried this is one setup but cannot remember the outcome anymore :(  (anyway, such setup involves quite many assumptions in an SGSN and a GGSN regarding e.g. the fallback  behaviour..)

- JOuni

---

From: "Dave Michaud" <[email-masked]>
Date: Tue, 24 Sep 2013 09:20:15 -0400

> Sent: Tuesday, September 24, 2013 1:30 AM
> > Thanks for the clarifications on differences between SGSN and MME. We still
> have limited LTE roaming so we are not running into these issues yet...
> >
> > Regarding your question about our GPRSSubscriptionData in the HLR, I can't
> tell for sure about this one. Given Cameron's experience, we stopped the
> deployment and requested a patch from our HLR vendor before it went live.
> 
> I am just interested on the GPRSSubscriptionData because if the SGSN would
> not drop whole GPRSSubscriptionData based on one PDP-Context it does not
> understand, then it could be possible to include another PDP-Type IPv4 PDP-
> Context for the same APN in the GPRSSubscriptionData.. and the SGSN could
> supposedly use that. I am sure I tried this is one setup but cannot remember the
> outcome anymore :(  (anyway, such setup involves quite many assumptions in
> an SGSN and a GGSN regarding e.g. the fallback  behaviour..)
> 
> - JOuni

In any case, the behavior could be different depending on the equipment manufacturer and release. It is likely not something we can count on for a production deployment, not at this point at least.

Dave Michaud