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

["Heatley, Nick" <[e-mail]>]

Hi Dave,
We are also interested in the use of home AAA (offline radius from PGW, not on Gi SGi interface) to control how a PDP type IPv4v6 request can return an PDP type IPv6 response, based on IMEI TAC.

Regarding IMEI TAC, we assume that we can find device hardware builds that unequivocally support 464xlat; our devices team are suspicious of forking of software and hardware builds, especially with a big grey market. We also assume that on all devices the 464xlat is invoked per APN based on the PDP type returned, not the PDP type requested (logical, but I don't think I have seen this written down).

May I ask a question on:
>SGSN MCC-MNC: without a confirmation that this PLMN ID supports IPv6, fallback to IPv4

Given that 1) the HSS/HLR whitelist has already been passed, 2) the request has to be IPv4v6, and 3) the visited SGSN has allowed the IPv4v6 request to reach the home network, can you assume the visited network can support IPv6 or not? I am wondering what problem scenarios does the PLMN id whitelist on AAA solve?

Great information, thanks for sharing your experience here.
Nick


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dave Michaud
Sent: 20 September 2013 15:13
To: GangChen; IPv6 Ops WG
Cc: Cameron Byrne
Subject: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis

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.

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.

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

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

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

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


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. 
_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops

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. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW