[要約] 要約： RFC 7445は、IPv6ローミングシナリオにおける障害事例の分析を提供しています。目的： このRFCの目的は、IPv6ローミングの障害事例を分析し、問題の特定と解決策の提案を行うことです。
Internet Engineering Task Force (IETF) G. Chen
Request for Comments: 7445 H. Deng
Category: Informational China Mobile
ISSN: 2070-1721 D. Michaud
Rogers Communications
J. Korhonen
Broadcom Corporation
M. Boucadair
France Telecom
March 2015
Analysis of Failure Cases in IPv6 Roaming Scenarios
IPv6ローミングシナリオの失敗例の分析
Abstract
概要
This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.
このドキュメントでは、ローミングシナリオでIPv6対応のモバイルカスタマーが遭遇する可能性がある一連の障害ケースを特定します。分析の結果、障害の原因には、不適切な構成、機器の不完全な機能サポート、およびホームネットワークと訪問先ネットワーク間のIPv6展開戦略の不整合が含まれていることがわかりました。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7445.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7445で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 4
2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4
2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5
2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6
3. Failure Case in the Network Attachment . . . . . . . . . . . 7
4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 9
4.1. Case 1: Splitting Dual-Stack Bearer . . . . . . . . . . . 9
4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 11
4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11
4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11
5. Failure Cases in the Service Requests . . . . . . . . . . . . 12
5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 12
5.2. 464XLAT Support . . . . . . . . . . . . . . . . . . . . . 12
6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 13
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Many mobile operators have deployed IPv6, or are about to, in their operational networks. A customer in such a network can be provided IPv6 connectivity if their User Equipment (UE) is IPv6 compliant. Operators may adopt various approaches to deploy IPv6 in mobile networks, such as the solutions described in [TR23.975]. Depending on network conditions, either dual-stack or IPv6-only deployment schemes can be enabled.
多くのモバイル事業者は、運用ネットワークにIPv6を導入したか、またはこれから導入しようとしています。このようなネットワークの顧客は、ユーザー機器（UE）がIPv6に準拠している場合、IPv6接続を提供できます。事業者は、[TR23.975]で説明されているソリューションなど、IPv6をモバイルネットワークに展開するためのさまざまなアプローチを採用できます。ネットワークの状態に応じて、デュアルスタックまたはIPv6のみの展開スキームを有効にできます。
A detailed overview of IPv6 support in 3GPP architectures is provided in [RFC6459].
3GPPアーキテクチャでのIPv6サポートの詳細な概要は、[RFC6459]で提供されています。
It has been observed and reported that a mobile subscriber roaming around a different operator's areas may experience service disruption due to inconsistent configurations and incomplete functionality of equipment in the network. This document focuses on these issues.
異なる事業者のエリアをローミングするモバイル加入者は、ネットワーク内の機器の構成の不整合や機能の不完全性により、サービスの中断を経験する可能性があることが観察および報告されています。このドキュメントでは、これらの問題に焦点を当てています。
This document makes use of these terms:
このドキュメントでは、次の用語を使用しています。
o Mobile networks refer to 3GPP mobile networks.
o モバイルネットワークとは、3GPPモバイルネットワークを指します。
o Mobile UE denotes a 3GPP device that can be connected to 3GPP mobile networks.
o モバイルUEは、3GPPモバイルネットワークに接続できる3GPPデバイスを表します。
o The Public Land Mobile Network (PLMN) is a network that is operated by a single administrative entity. A PLMN (and therefore also an operator) is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) operator providing mobile services has its own PLMN [RFC6459].
o Public Land Mobile Network（PLMN）は、単一の管理エンティティによって運営されるネットワークです。 PLMN（およびオペレーター）は、モバイル国コード（MCC）およびモバイルネットワークコード（MNC）によって識別されます。モバイルサービスを提供する各（通信）事業者には、独自のPLMN [RFC6459]があります。
o The Home Location Register (HLR) is a pre-Release 5 database (but is also used in real deployments of Release 5 and later) that contains subscriber data and information related to call routing. All subscribers of an operator and the subscribers' enabled services are provisioned in the HLR [RFC6459].
o ホームロケーションレジスタ（HLR）は、リリース5より前のデータベース（ただし、リリース5以降の実際の展開でも使用されます）であり、サブスクライバデータとコールルーティングに関連する情報が含まれています。オペレーターのすべてのサブスクライバーとサブスクライバーの有効なサービスは、HLR [RFC6459]でプロビジョニングされます。
o The Home Subscriber Server (HSS) is a database for a given subscriber and was introduced in 3GPP Release 5. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions [RFC6459].
o ホームサブスクライバーサーバー（HSS）は特定のサブスクライバーのデータベースであり、3GPPリリース5で導入されました。これは、実際に通話/セッションを処理するネットワークエンティティをサポートするためのサブスクリプション関連情報を含むエンティティです[RFC6459]。
o "HLR/HSS" is used collectively for the subscriber database unless referring to the failure case related to General Packet Radio Service (GPRS) Subscriber data from the HLR.
o 「HLR / HSS」は、HLRからの一般パケット無線サービス（GPRS）加入者データに関連する障害事例を参照しない限り、加入者データベースに対して集合的に使用されます。
An overview of key 3GPP functional elements is documented in [RFC6459].
主要な3GPP機能要素の概要は、[RFC6459]に文書化されています。
"Mobile device" and "mobile UE" are used interchangeably.
「モバイルデバイス」と「モバイルUE」は同じ意味で使用されます。
Roaming occurs in two scenarios:
ローミングは2つのシナリオで発生します。
o International roaming: a mobile UE enters a visited network operated by a different operator, where a different PLMN code is used. The UEs could, either in an automatic mode or in a manual mode, attach to the visited PLMN.
o 国際ローミング：モバイルUEは、別のPLMNコードが使用される別の事業者が運営する訪問先ネットワークに入ります。 UEは、自動モードまたは手動モードのいずれかで、訪問先PLMNに接続できます。
o Intra-PLMN mobility: an operator may have one or multiple PLMN codes. A mobile UE could pre-configure the codes to identify the Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN). Intra-PLMN mobility allows the UE to move to a different area of HPLMN and EHPLMN. When the subscriber profile is not stored in the visited area, HLR/HSS in the Home area will transmit the profile to the Serving GPRS Support Node (SGSN) / Mobility Management Entity (MME) in the visited area so as to complete network attachment.
o イントラPLMNモビリティ：オペレーターは1つまたは複数のPLMNコードを持っている場合があります。モバイルUEは、ホームPLMN（HPLMN）または同等のHPLMN（EHPLMN）を識別するためのコードを事前構成できます。 PLMN内モビリティにより、UEはHPLMNとEHPLMNの異なるエリアに移動できます。加入者プロファイルが訪問先エリアに保存されていない場合、ホームエリアのHLR / HSSは、ネットワーク接続を完了するために、訪問先エリアのサービングGPRSサポートノード（SGSN）/モビリティ管理エンティティ（MME）にプロファイルを送信します。
When a UE is turned on or is transferred via a handover to a visited network, the mobile device will scan all radio channels and find available PLMNs to attach to. The SGSN or the MME in the visited networks must contact the HLR or HSS to retrieve the subscriber profile.
UEがオンになるか、ハンドオーバーを介して訪問先ネットワークに転送されると、モバイルデバイスはすべての無線チャネルをスキャンし、接続可能なPLMNを見つけます。訪問先ネットワークのSGSNまたはMMEは、HLRまたはHSSに接続して、加入者プロファイルを取得する必要があります。
Steering of roaming may also be used by the HPLMN to further restrict which of the available networks the UE may be attached to. Once the authentication and registration stage is completed, the Packet Data Protocol (PDP) or Packet Data Networks (PDN) activation and traffic flows may be operated differently according to the subscriber profile stored in the HLR or the HSS.
ローミングのステアリングをHPLMNで使用して、UEが接続できるネットワークをさらに制限することもできます。認証と登録の段階が完了すると、パケットデータプロトコル（PDP）またはパケットデータネットワーク（PDN）のアクティブ化とトラフィックフローは、HLRまたはHSSに格納されている加入者プロファイルに従って異なる方法で操作できます。
The following subsections describe two roaming modes: Home-routed traffic (Section 2.1.1) and Local breakout (Section 2.1.2).
次のサブセクションでは、2つのローミングモードについて説明します。ホームルーティングされたトラフィック（セクション2.1.1）とローカルブレイクアウト（セクション2.1.2）です。
In this mode, the subscriber's UE gets IP addresses from the home network. All traffic belonging to that UE is therefore routed to the home network (Figure 1).
このモードでは、加入者のUEはホームネットワークからIPアドレスを取得します。したがって、そのUEに属するすべてのトラフィックはホームネットワークにルーティングされます（図1）。
GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX) networks [IR.34] are likely to be invoked as the transit network to deliver the traffic. This is the main mode for international roaming of Internet data services to facilitate the charging process between the two involved operators.
GPRSローミング交換（GRX）またはインターネットワークパケット交換（IPX）ネットワーク[IR.34]は、トラフィックを配信するための中継ネットワークとして呼び出される可能性があります。これは、インターネットデータサービスの国際ローミングのメインモードであり、関係する2つの事業者間の課金プロセスを容易にします。
+-----------------------------+ +------------------------+
|Visited Network | |Home Network |
| +----+ +----+---+ | (GRX/IPX) | +--------+ Traffic Flow
| | UE |=======>|SGSN/SGW|====================>|GGSN/PGW|============>
| +----+ +----+---+ | | +--------+ |
| |MME | | | |
| +----+ | Signaling | +--------+ |
| |-------------------------->|HLR/HSS | |
| | | +--------+ |
+-----------------------------+ +------------------------+
Figure 1: Home Routed Traffic
図1：ホームルーティングされたトラフィック
In the local breakout mode, IP addresses are assigned by the visited network to a roaming mobile UE. Unlike the home routed mode, the traffic doesn't have to traverse GRX/IPX; it is offloaded locally at a network node close to that device's point of attachment in the visited network. This mode ensures a more optimized forwarding path for the delivery of packets belonging to a visiting UE (Figure 2).
ローカルブレイクアウトモードでは、訪問先ネットワークによってローミングモバイルUEにIPアドレスが割り当てられます。ホームルーテッドモードとは異なり、トラフィックはGRX / IPXを通過する必要はありません。訪問先ネットワークのデバイスの接続ポイントに近いネットワークノードでローカルにオフロードされます。このモードは、巡回UEに属するパケットの配信のためのより最適化された転送パスを保証します（図2）。
+----------------------------+ +----------------+
|Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ |
| | UE |=======>|SGSN/MME|------------------->|HLR/HSS | |
| +----+ +---+----+ | (GRX/IPX) | +--------+ |
| |SGW| | | |
| +---+ | | |
| || | | |
| +--------+ | | |
| |GGSN/PGW| | | |
| +--------+ | | |
| Traffic Flow || | | |
+------------------||--------+ +----------------+
\/
Figure 2: Local Breakout
図2：ローカルブレイクアウト
The international roaming of services based on the IP Multimedia Subsystem (IMS), e.g., Voice over LTE (VoLTE)[IR.92], is claimed to select the local breakout mode in [IR.65]. Data service roaming
IPマルチメディアサブシステム（IMS）に基づくサービスの国際ローミング（Voice over LTE（VoLTE）[IR.92]など）は、[IR.65]でローカルブレークアウトモードを選択すると主張されています。データサービスローミング
across different areas within an operator network might use local breakout mode in order to get more efficient traffic forwarding and also ease emergency services. The local breakout mode could also be applied to an operator's alliance for international roaming of data service.
オペレータネットワーク内のさまざまなエリアにわたって、ローカルブレークアウトモードを使用して、より効率的なトラフィック転送を実現し、緊急サービスを容易にすることもできます。ローカルブレイクアウトモードは、データサービスの国際ローミングに関する事業者の同盟にも適用できます。
EU Roaming Regulation III [EU-Roaming-III] involves local breakout mode allowing European subscribers roaming in European 2G/3G networks to have their Internet data routed directly to the Internet from their current Visited Public Land Mobile Network (VPLMN).
EUローミング規制III [EU-Roaming-III]にはローカルブレイクアウトモードが含まれており、ヨーロッパの2G / 3Gネットワークでローミングするヨーロッパの加入者は、現在のVisited Public Land Mobile Network（VPLMN）からインターネットに直接インターネットデータをルーティングできます。
Specific local breakout-related configuration considerations are listed below:
特定のローカルブレイクアウト関連の構成に関する考慮事項を以下に示します。
o Operators may add the APN-OI-Replacement flag defined in 3GPP [TS29.272] into the user's subscription data. The visited network indicates a local domain name to replace the user requested Access Point Name (APN). Consequently, the traffic would be steered to the visited network. Those functions are normally deployed for the intra-PLMN mobility cases.
o オペレーターは、3GPP [TS29.272]で定義されているAPN-OI-Replacementフラグをユーザーのサブスクリプションデータに追加できます。アクセスしたネットワークは、ユーザーが要求したアクセスポイント名（APN）を置き換えるローカルドメイン名を示します。その結果、トラフィックは訪問先ネットワークに誘導されます。これらの機能は通常、PLMN内のモビリティの場合に展開されます。
o Operators may also configure the VPLMN-Dynamic-Address-Allowed flag [TS29.272] in the user's profile to enable local breakout mode in VPLMNs.
o オペレーターは、ユーザーのプロファイルでVPLMN-Dynamic-Address-Allowedフラグ[TS29.272]を構成して、VPLMNでローカルブレークアウトモードを有効にすることもできます。
o 3GPP specified the Selected IP Traffic Offload (SIPTO) function [TS23.401] since Release 10 in order to get efficient route paths. It enables an operator to offload a portion of the traffic at a network node close to the UE's point of attachment to the network.
o 3GPPは、効率的なルートパスを取得するために、リリース10以降、Selected IP Traffic Offload（SIPTO）関数[TS23.401]を指定しました。これにより、オペレーターは、ネットワークへのUEの接続ポイントに近いネットワークノードでトラフィックの一部をオフロードできます。
o The Global System for Mobile Communications Association (GSMA) has defined Roaming Architecture for Voice over LTE with Local Breakout (RAVEL) [IR.65] as the IMS international roaming architecture. Local breakout mode has been adopted for the IMS roaming architecture.
o Global Systems for Mobile Communications Association（GSMA）は、Local Breakout（RAVEL）[IR.65]を備えたVoice over LTEのローミングアーキテクチャを、IMS国際ローミングアーキテクチャとして定義しています。ローカルブレイクアウトモードは、IMSローミングアーキテクチャに採用されています。
Three stages occur when a subscriber roams to a visited network and intends to invoke services:
加入者が訪問したネットワークにローミングし、サービスを呼び出すつもりである場合、3つの段階が発生します。
o Network attachment: this occurs when the UE enters a visited network. During the attachment phase, the visited network should authenticate the subscriber and make a location update to the HSS/HLR in the home network of the subscriber. Accordingly, the subscriber profile is offered from the HSS/HLR. The subscriber profile contains the allowed APNs, the allowed PDP/PDN Types, and rules regarding the routing of data sessions (i.e., home routed or local breakout mode) [TS29.272]. The SGSN/MME in the visited network can use this information to facilitate the subsequent PDP/PDN session creation.
oネットワーク接続：これは、UEが訪問先ネットワークに入るときに発生します。接続フェーズ中に、訪問先ネットワークは加入者を認証し、加入者のホームネットワーク内のHSS / HLRの位置を更新する必要があります。したがって、加入者プロファイルはHSS / HLRから提供されます。加入者プロファイルには、許可されたAPN、許可されたPDP / PDNタイプ、およびデータセッションのルーティングに関するルール（つまり、ホームルーティングモードまたはローカルブレイクアウトモード）が含まれています[TS29.272]。訪問先ネットワークのSGSN / MMEは、この情報を使用して、後続のPDP / PDNセッションの作成を容易にすることができます。
o PDP/PDN context creation: this occurs after the subscriber's UE has been successfully attached to the network. This stage is integrated with the attachment stage in the case of 4G, but is a separate process in 2G/3G. 3GPP specifies three types of PDP/PDN to describe connections: PDP/PDN Type IPv4, PDP/PDN Type IPv6, and PDP/PDN Type IPv4v6. When a subscriber creates a data session, their device requests a particular PDP/PDN Type. The allowed PDP/PDN Types for that subscriber are learned in the attachment stage. Hence, the SGSN and MME via the Serving Gateway (SGW) could initiate a PDP/PDN request to Gateway GSN (GGSN) / Packet Data Network Gateway (PGW) modulo subscription grants.
o PDP / PDNコンテキストの作成：これは、加入者のUEがネットワークに正常に接続された後に発生します。このステージは、4Gの場合はアタッチメントステージと統合されていますが、2G / 3Gでは別のプロセスです。 3GPPは、接続を記述するためにPDP / PDNタイプIPv4、PDP / PDNタイプIPv6、およびPDP / PDNタイプIPv4v6の3つのタイプのPDP / PDNを指定します。加入者がデータセッションを作成すると、そのデバイスは特定のPDP / PDNタイプを要求します。そのサブスクライバーに許可されているPDP / PDNタイプは、接続段階で学習されます。したがって、Serving Gateway（SGW）を介したSGSNおよびMMEは、ゲートウェイGSN（GGSN）/パケットデータネットワークゲートウェイ（PGW）モジュロサブスクリプション許可へのPDP / PDN要求を開始できます。
o Service requests: when the PDP/PDN context is created successfully, UEs may launch applications and request services based on the allocated IP addresses. The service traffic will be transmitted via the visited network.
o サービス要求：PDP / PDNコンテキストが正常に作成されると、UEは割り当てられたIPアドレスに基づいてアプリケーションを起動し、サービスを要求できます。サービストラフィックは訪問先ネットワーク経由で送信されます。
Failures that occur at the attachment stage (Section 3) are independent of home routed and the local breakout modes. Most failure cases in the PDP/PDN context creation (Section 4) and in service requests (Section 5) occur in the local breakout mode.
接続の段階（セクション3）で発生する障害は、ホームルーテッドモードとローカルブレイクアウトモードには依存しません。 PDP / PDNコンテキストの作成（セクション4）およびサービスリクエスト（セクション5）でのほとんどの失敗ケースは、ローカルブレークアウトモードで発生します。
3GPP specified PDP/PDN Type IPv4v6 in order to allow a UE to get both an IPv4 address and an IPv6 prefix within a single PDP/PDN bearer. This option is stored as a part of subscription data for a subscriber in the HLR/HSS. PDP/PDN Type IPv4v6 has been introduced at the inception of the Evolved Packet System (EPS) in 4G networks.
3GPPは、UEが単一のPDP / PDNベアラ内でIPv4アドレスとIPv6プレフィックスの両方を取得できるようにするために、PDP / PDNタイプIPv4v6を指定しました。このオプションは、HLR / HSSのサブスクライバーのサブスクリプションデータの一部として保存されます。 PDP / PDNタイプIPv4v6は、4GネットワークのEvolved Packet System（EPS）の最初に導入されました。
The nodes in 4G networks should present no issues with the handling of this PDN Type. However, the level of support varies in 2G/3G networks depending on the SGSN software version. In theory, S4-SGSN (i.e., an SGSN with S4 interface) has supported the PDP/PDN Type IPv4v6 since Release 8, and Gn-SGSN (i.e., the SGSN with Gn interface) has supported it since Release 9. In most cases, operators normally use Gn-SGSN to connect either GGSN in 3G or Packet Data Network Gateway (PGW) in 4G.
4Gネットワーク内のノードは、このPDNタイプの処理に問題がないはずです。ただし、サポートのレベルは、SGSNソフトウェアのバージョンによって2G / 3Gネットワークで異なります。理論的には、S4-SGSN（つまり、S4インターフェースを備えたSGSN）はリリース8からPDP / PDNタイプIPv4v6をサポートしており、Gn-SGSN（つまり、Gnインターフェースを備えたSGSN）はリリース9からそれをサポートしています。 、オペレーターは通常、Gn-SGSNを使用して、3GのGGSNまたは4Gのパケットデータネットワークゲートウェイ（PGW）のいずれかに接続します。
The MAP (Mobile Application Part) protocol, as defined in 3GPP [TS29.002], is used over the Gr interface between SGSN and HLR. The MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP Type that is conveyed to SGSN from the HLR within the Insert Subscriber Data (ISD) MAP operation. If the SGSN does not support the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE; consequently, it must silently discard that IE and continue processing the rest of the ISD MAP message. An issue that has been observed is that multiple SGSNs are unable to correctly process a subscriber's data received in the Insert Subscriber Data Procedure [TS23.060]. As a consequence, it will likely discard the subscriber attach request. This is erroneous behavior due to the equipment not being compliant with 3GPP Release 9.
3GPP [TS29.002]で定義されているMAP（モバイルアプリケーションパーツ）プロトコルは、SGSNとHLRの間のGrインターフェイスを介して使用されます。 MAP情報要素（IE）の「ext-pdp-Type」には、加入者データの挿入（ISD）MAP操作内でHLRからSGSNに伝達されるIPv4v6 PDPタイプが含まれています。 SGSNがIPv4v6 PDPタイプをサポートしない場合、「ext-pdp-Type」IEはサポートされません。そのため、そのIEをサイレントに破棄し、ISD MAPメッセージの残りの処理を続行する必要があります。確認されている問題は、複数のSGSNが、サブスクライバデータの挿入手順[TS23.060]で受信したサブスクライバのデータを正しく処理できないことです。その結果、サブスクライバー接続要求は破棄される可能性があります。これは、機器が3GPPリリース9に準拠していないため、誤った動作です。
In order to avoid encountering this attach problem at a visited SGSN, both operators should make a comprehensive roaming agreement to support IPv6 and ensure that it aligns with the GSMA documents, e.g., [IR.33], [IR.88], and [IR.21]. Such an agreement requires the visited operator to get the necessary patch on all its SGSN nodes to support the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data-session continuity in Radio Access Technology (RAT) handovers, the PDN Type sent by the HSS to the MME should be consistent with the PDP Type sent by the HLR to the Gn-SGSN. Where roaming agreements and visited SGSN nodes have not been updated, the HPLMN also has to make use of specific implementations (not standardized by 3GPP, discussed further in Section 6) in the HLR/HSS of the home network. That is, when the HLR/HSS receives an Update Location message from a visited SGSN not known to support dual-stack in a single bearer, subscription data allowing only PDP/PDN Type IPv4 or IPv6 will be sent to that SGSN in the Insert Subscriber Data procedure. This guarantees that the user profile is compatible with the visited SGSN/MME capability. In addition, HSS may not have to change if the PGW is aware of the subscriber's roaming status and only restricts the accepted PDN Type consistent with PDP Type sent by the HLR. For example, a AAA server may coordinate with the PGW to decide the allowed PDN Type.
訪問したSGSNでこの接続の問題が発生するのを回避するために、両方の事業者はIPv6をサポートするために包括的なローミング契約を締結し、GSMAドキュメント、たとえば[IR.33]、[IR.88]、[ IR.21]。このような合意により、訪問先の事業者は、HLRによって送信された「ext-pdp-Type」MAP IEをサポートするために、すべてのSGSNノードで必要なパッチを取得する必要があります。 Radio Access Technology（RAT）ハンドオーバーでデータセッションの継続性を確保するには、HSSからMMEに送信されるPDNタイプが、HLRからGn-SGSNに送信されるPDPタイプと一致している必要があります。ローミング契約と訪問したSGSNノードが更新されていない場合、HPLMNは、ホームネットワークのHLR / HSSで特定の実装（3GPPで標準化されていない、セクション6でさらに説明）を利用する必要があります。つまり、HLR / HSSが、シングルベアラーでデュアルスタックをサポートすることが知られていない訪問先のSGSNからUpdate Locationメッセージを受信すると、PDP / PDN Type IPv4またはIPv6のみを許可するサブスクリプションデータがInsert SubscriberでそのSGSNに送信されます。データ手順。これにより、ユーザープロファイルがアクセスしたSGSN / MME機能と互換性があることが保証されます。さらに、PGWが加入者のローミングステータスを認識していて、HLRによって送信されたPDPタイプと一致する受け入れられたPDNタイプのみを制限している場合、HSSを変更する必要がない場合があります。たとえば、AAAサーバーはPGWと調整して、許可されるPDNタイプを決定できます。
Alternatively, HPLMNs without the non-standardized capability to suppress the sending of "ext-pdp-Type" by the HLR may have to remove this attribute from APNs with roaming service. PDN Type IPv4v6 must also be removed from the corresponding profile for the APN in the HSS. This will restrict their roaming UEs to only IPv4 or IPv6 PDP/PDN activation. This alternative has problems:
または、HLRによる「ext-pdp-Type」の送信を抑制する非標準化機能のないHPLMNは、ローミングサービスを使用してAPNからこの属性を削除する必要がある場合があります。 PDNタイプIPv4v6も、HSSのAPNの対応するプロファイルから削除する必要があります。これにより、ローミングUEがIPv4またはIPv6 PDP / PDNアクティベーションのみに制限されます。この代替案には問題があります：
o The HPLMN cannot support dual-stack in a single bearer at home where the APN profile in the HLR/HSS is also used for roaming.
o HPLMNは、HLR / HSSのAPNプロファイルがローミングにも使用される自宅の単一ベアラでデュアルスタックをサポートできません。
o The UE may set up separate parallel bearers for IPv4 and IPv6, where only single-stack IPv4 or IPv6 service is preferred by the operator.
o UEはIPv4とIPv6に個別の並列ベアラを設定できます。この場合、オペレータはシングルスタックIPv4またはIPv6サービスのみを優先します。
When a subscriber's UE succeeds in the attach stage, the IP allocation process takes place to retrieve IP addresses. In general, a PDP/PDN Type IPv4v6 request implicitly allows the network side to make several IP assignment options, including IPv4-only, IPv6-only, IPv4 and IPv6 in single PDP/PDN bearer, and IPv4 and IPv6 in separated PDP/PDN bearers.
加入者のUEがアタッチステージで成功すると、IP割り当てプロセスが実行され、IPアドレスが取得されます。一般に、PDP / PDNタイプのIPv4v6要求により、ネットワーク側は暗黙的に、IPv4のみ、IPv6のみ、単一のPDP / PDNベアラーでのIPv4とIPv6、個別のPDP / PDNでのIPv4とIPv6など、いくつかのIP割り当てオプションを作成できます無記名。
A PDP/PDN Type IPv4 or IPv6 restricts the network side to only allocate the requested IP address family.
PDP / PDNタイプIPv4またはIPv6は、ネットワーク側を制限して、要求されたIPアドレスファミリのみを割り当てる。
This section summarizes several failures in the Home Routed (HR) and Local Breakout (LBO) mode as shown in Table 1.
このセクションでは、表1に示すように、ホームルーテッド（HR）モードとローカルブレークアウト（LBO）モードでのいくつかの障害をまとめています。
+-------+-------------+------------------------+---------+
| Case# | UE request | PDP/PDN IP Type | Mode |
| | | permitted on GGSN/PGW | |
+-------+-------------+------------------------+---------+
| | IPv4v6 | IPv4v6 | HR |
| #1 |-------------+------------------------+---------+
| | IPv4v6 | IPv4 or IPv6 | LBO |
+-------+-------------+------------------------+---------+
| #2 | IPv6 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #3 | IPv4 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #4 | IPv6 | IPv4 | LBO |
+-------+-------------+------------------------+---------+
Table 1: Failure Cases in the PDP/PDN Creation
表1：PDP / PDN作成の失敗例
Dual-stack capability is provided using separate PDP/PDN activation in the visited network that doesn't support PDP/PDN Type IPv4v6. That means only separate, parallel, single-stack IPv4 and IPv6 PDP/PDN connections are allowed to be initiated to separately allocate an IPv4 address and an IPv6 prefix. The SGSN does not support the Dual Address Bearer Flag (DAF) or does not set the DAF because the operator uses single addressing per bearer to support interworking with nodes of earlier releases. Regardless of home routed or local breakout mode, GGSN/PGW will change PDN/PDP Type to a single address PDP/PDN Type and return the Session Management (SM) Cause #52 "single address bearers only allowed" or SM Cause #28 "unknown PDP address or PDP type" as per [TS24.008] and [TS24.301] to
デュアルスタック機能は、PDP / PDNタイプIPv4v6をサポートしない訪問先ネットワークで個別のPDP / PDNアクティベーションを使用して提供されます。つまり、IPv4アドレスとIPv6プレフィックスを個別に割り当てるために開始できるのは、個別の並列のシングルスタックIPv4およびIPv6 PDP / PDN接続のみです。オペレータは以前のリリースのノードとのインターワーキングをサポートするためにベアラごとに単一のアドレッシングを使用するため、SGSNはデュアルアドレスベアラフラグ（DAF）をサポートしないか、DAFを設定しません。ホームルーテッドモードまたはローカルブレイクアウトモードに関係なく、GGSN / PGWはPDN / PDPタイプを単一のアドレスPDP / PDNタイプに変更し、セッション管理（SM）を返します原因＃52「単一のアドレスベアラーのみ許可」またはSMの原因＃28 " [TS24.008]および[TS24.301]に従って、不明なPDPアドレスまたはPDPタイプ
the UE. In this case, the UE may make another PDP/PDN request with a single address PDP Type (IPv4 or IPv6) other than the one already activated.
UE。この場合、UEは、すでにアクティブになっているもの以外の単一のアドレスPDPタイプ（IPv4またはIPv6）を使用して、別のPDP / PDN要求を行うことがあります。
This approach suffers from the following drawbacks:
このアプローチには、次の欠点があります。
o The parallel PDP/PDN activation would likely double PDP/PDN bearer resource on the network side and Radio Access Bearer (RAB) resource on the Radio Access Network (RAN) side. It also impacts the capacity of the GGSN/PGW, since only a certain amount of PDP/PDN activation is allowed on those nodes.
o 並列のPDP / PDNアクティベーションは、ネットワーク側のPDP / PDNベアラリソースと、無線アクセスネットワーク（RAN）側の無線アクセスベアラ（RAB）リソースを2倍にする可能性があります。また、これらのノードで許可されるPDP / PDNアクティベーションの量は一定であるため、GGSN / PGWの容量にも影響します。
o Some networks may allow only one PDP/PDN to be alive for each subscriber. For example, an IPv6 PDP/PDN will be rejected if the subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber would not be able to obtain the IPv6 connection in the visited network. It is even worse, as they may have a risk of losing all data connectivity if the IPv6 PDP gets rejected with a permanent error at the APN level and not an error specific to the PDP-Type IPv6 requested.
o 一部のネットワークでは、各加入者に対して1つのPDP / PDNのみを有効にすることができます。たとえば、加入者がアクティブなIPv4 PDP / PDNを持っている場合、IPv6 PDP / PDNは拒否されます。したがって、加入者は訪問先ネットワークでIPv6接続を取得できません。さらに悪いのは、要求されたPDPタイプのIPv6に固有のエラーではなく、APNレベルの永続的なエラーでIPv6 PDPが拒否された場合、すべてのデータ接続が失われるリスクがあるためです。
o Additional correlations between those two PDP/PDN contexts are required on the charging system.
o これら2つのPDP / PDNコンテキスト間の追加の相関関係が課金システムで必要です。
o Policy and Charging Rules Function (PCRF) [TS29.212] / Policy and Charging Enforcement Function (PCEF) treats the IPv4 and IPv6 sessions as independent and performs different quality-of-service (QoS) policies. The subscriber may have an unstable experience due to different behaviors on each IP version connection.
o ポリシーおよび課金ルール機能（PCRF）[TS29.212] /ポリシーおよび課金実施機能（PCEF）は、IPv4セッションとIPv6セッションを独立したものとして扱い、異なるサービス品質（QoS）ポリシーを実行します。 IPバージョン接続ごとに動作が異なるため、サブスクライバーのエクスペリエンスが不安定になる可能性があります。
o Mobile devices may have a limitation on the number of allowed simultaneous PDP/PDN contexts. Excessive PDP/PDN activations may result in service disruption.
o モバイルデバイスでは、許可される同時PDP / PDNコンテキストの数に制限がある場合があります。過度のPDP / PDNアクティベーションは、サービスの中断を引き起こす可能性があります。
In order to avoid the issue, the roaming agreement in the home routed mode should make sure the visited SGSN supports and sets the DAF. Since the PDP/PDN Type IPv4v6 is supported in the GGSN/PGW of the home network, it's expected that the visited SGSN/MME could create a dual-stack bearer as the UE requested.
この問題を回避するには、ホームルーテッドモードのローミング契約で、訪問したSGSNがDAFをサポートおよび設定していることを確認する必要があります。 PDP / PDNタイプIPv4v6はホームネットワークのGGSN / PGWでサポートされているため、訪問したSGSN / MMEがUEの要求に応じてデュアルスタックベアラーを作成できることが期待されます。
In the local breakout mode, the visited SGSN may only allow single IP version addressing. In this case, the DAF on the visited SGSN/MME has to be unset. One approach is to set a dedicated APN [TS23.003] profile to only request PDP/PDN Type IPv4 in the roaming network. Some operators may also consider not adopting the local breakout mode to avoid the risks.
ローカルブレークアウトモードでは、アクセスされたSGSNは単一のIPバージョンのアドレス指定のみを許可する場合があります。この場合、訪問したSGSN / MMEのDAFを設定解除する必要があります。 1つの方法は、専用APN [TS23.003]プロファイルを設定して、ローミングネットワークでPDP / PDNタイプIPv4のみを要求することです。一部の事業者は、リスクを回避するためにローカルブレイクアウトモードを採用しないことを検討する場合もあります。
PDP/PDN Type IPv6 has good compatibility to visited networks during the network attachment. In order to support the IPv6-only visitors, SGSN/MME in the visited network is required to accept IPv6-only PDP/PDN activation requests and enable IPv6 on the user plane in the direction of the home network.
PDP / PDNタイプIPv6は、ネットワーク接続時に訪問先ネットワークとの互換性が良好です。 IPv6のみのビジターをサポートするには、訪問先ネットワークのSGSN / MMEがIPv6のみのPDP / PDNアクティベーション要求を受け入れ、ユーザープレーンでホームネットワーク方向のIPv6を有効にする必要があります。
In some cases, IPv6-only visitors may still be subject to the SGSN capability in visited networks. This becomes especially risky if the home operator performs roaming steering targeted to an operator that doesn't allow IPv6. The visited SGSN may just directly reject the PDP context activation. Therefore, it's expected that the visited network is IPv6 roaming-friendly to enable the functions on SGSN/MME by default. Otherwise, operators may consider steering the roaming traffic to the IPv6-enabled visited network that has an IPv6 roaming agreement.
場合によっては、IPv6のみのビジターが訪問先ネットワークのSGSN機能の対象になることがあります。これは、ホームオペレーターがIPv6を許可しないオペレーターを対象としたローミングステアリングを実行する場合に特に危険になります。訪問したSGSNは、PDPコンテキストのアクティブ化を直接拒否する場合があります。したがって、訪問先ネットワークはIPv6ローミングに対応しており、SGSN / MMEの機能をデフォルトで有効にすることが期待されています。そうでない場合、オペレーターは、IPv6ローミング契約があるIPv6対応の訪問済みネットワークにローミングトラフィックをステアリングすることを検討できます。
If IPv6 single stack with the home routed mode is deployed, the requested PDP/PDN Type should also be IPv6. Some implementations that support the roaming APN profile may set IPv4 as the default PDP/PDN Type, since the visited network is incapable of supporting PDP/PDN Types IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The PDP/PDN request will fail because the APN in the home network only allows IPv6. Therefore, the roaming APNs have to be compliant with the home network configuration when home routed mode is adopted.
ホームルーテッドモードのIPv6シングルスタックが展開されている場合、要求されたPDP / PDNタイプもIPv6である必要があります。アクセスされたネットワークはPDP / PDNタイプIPv4v6（セクション4.1）およびIPv6（セクション4.2）をサポートできないため、ローミングAPNプロファイルをサポートする一部の実装では、IPv4をデフォルトのPDP / PDNタイプとして設定する場合があります。ホームネットワークのAPNはIPv6のみを許可するため、PDP / PDN要求は失敗します。したがって、ホームルーテッドモードが採用されている場合、ローミングAPNはホームネットワーク構成に準拠している必要があります。
In the local breakout mode, PDP/PDN Type IPv6 should have no issues to pass through the network attachment process, since 3GPP specified the PDP/PDN Type IPv6 as early as PDP/PDN Type IPv4. When a visitor requests PDP/PDN Type IPv6, the network should only return the expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the visited network only allocates an IPv4 address. In this case, the visited network will reject the request and send the cause code to the UE.
ローカルブレイクアウトモードでは、3GPPがPDP / PDNタイプIPv4をPDP / PDNタイプIPv4と早くも指定したため、PDP / PDNタイプIPv6はネットワーク接続プロセスを通過するために問題がないはずです。訪問者がPDP / PDNタイプIPv6を要求した場合、ネットワークは期待されるIPv6プレフィックスのみを返す必要があります。訪問先ネットワークがIPv4アドレスのみを割り当てる場合、UEはIPv6プレフィックスの取得に失敗する場合があります。この場合、訪問先ネットワークは要求を拒否し、原因コードをUEに送信します。
A proper fallback scheme for PDP/PDN Type IPv6 is desirable; however, there is no standard way to specify this behavior. The roaming APN profile could help to address the issue by setting the PDP/PDN Type to IPv4. For instance, the Android system solves the issue by configuring the roaming protocol to IPv4 for the APN. It guarantees that UE will always initiate a PDP/PDN Type IPv4 in the roaming area.
PDP / PDNタイプIPv6の適切なフォールバックスキームが望ましい。ただし、この動作を指定する標準的な方法はありません。ローミングAPNプロファイルは、PDP / PDNタイプをIPv4に設定することで問題に対処するのに役立ちます。たとえば、AndroidシステムはAPNのローミングプロトコルをIPv4に構成することで問題を解決します。 UEがローミングエリアで常にPDP / PDNタイプIPv4を開始することが保証されます。
After the successful network attachment and IP address allocation, applications could start to request service based on the activated PDP/PDN context. The service request may depend on specific IP family or network collaboration. If traffic is offloaded locally (Section 2.1.2), the visited network may not be able to accommodate the UE's service requests. This section describes the failures.
ネットワーク接続とIPアドレスの割り当てが成功すると、アプリケーションは、アクティブ化されたPDP / PDNコンテキストに基づいてサービスを要求し始めることができます。サービスリクエストは、特定のIPファミリまたはネットワークコラボレーションに依存する場合があります。トラフィックがローカルでオフロードされている場合（セクション2.1.2）、訪問先ネットワークはUEのサービス要求に対応できない場合があります。このセクションでは、障害について説明します。
Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] and Rich Communication Suite (RCS) [RCC.07] use the APN to offer voice service for visitors. The IMS roaming in RAVEL architecture [IR.65] offloads voice and video traffic in the visited network; therefore, a dual-stack visitor can only be assigned with an IPv6 prefix but no IPv4 address. If the applications can't support IPv6, the service is likely to fail.
オペレーターは、IMS APNでのみIPv6を許可できます。 VoLTE [IR.92]およびRich Communication Suite（RCS）[RCC.07]は、APNを使用して訪問者に音声サービスを提供します。 RAVELアーキテクチャでのIMSローミング[IR.65]は、訪問先ネットワークの音声およびビデオトラフィックの負荷を軽減します。したがって、デュアルスタックビジターにはIPv6プレフィックスのみを割り当てることができ、IPv4アドレスは割り当てられません。アプリケーションがIPv6をサポートできない場合、サービスは失敗する可能性があります。
Translation-based methods, for example, 464XLAT [RFC6877] or Bump-in-the-Host (BIH) [RFC6535], may help to address the issue if there are IPv6 compatibility problems. The translation function could be enabled in an IPv6-only network and disabled in a dual-stack or IPv4 network; therefore, the IPv4 applications only get the translation in the IPv6 network and they perform normally in an IPv4 or dual-stack network.
たとえば464XLAT [RFC6877]やBump-in-the-Host（BIH）[RFC6535]などの変換ベースの方法は、IPv6互換性の問題がある場合に問題の解決に役立つことがあります。変換機能は、IPv6のみのネットワークでは有効にし、デュアルスタックまたはIPv4ネットワークでは無効にすることができます。したがって、IPv4アプリケーションはIPv6ネットワークでのみ変換を取得し、IPv4またはデュアルスタックネットワークで正常に実行されます。
464XLAT [RFC6877] is proposed to address the IPv4 compatibility issue in an IPv6-only connectivity environment. The customer-side translator (CLAT) function on a mobile device is likely used in conjunction with a PDP/PDN IPv6 Type request and cooperates with a remote NAT64 [RFC6146] device.
464XLAT [RFC6877]は、IPv6のみの接続環境におけるIPv4互換性の問題に対処するために提案されています。モバイルデバイスのカスタマーサイドトランスレータ（CLAT）機能は、PDP / PDN IPv6 Typeリクエストと組み合わせて使用され、リモートNAT64 [RFC6146]デバイスと連携します。
464XLAT may use the mechanism defined in [RFC7050] or [RFC7225] to detect the presence of NAT64 devices and to learn the IPv6 prefix used for protocol translation [RFC6052].
464XLATは、[RFC7050]または[RFC7225]で定義されたメカニズムを使用して、NAT64デバイスの存在を検出し、プロトコル変換[RFC6052]に使用されるIPv6プレフィックスを学習します。
In the local breakout approach, a UE with the 464XLAT function roaming on an IPv6 visited network may encounter various situations. For example, the visited network may not have deployed DNS64 [RFC6147] but only NAT64, or CLAT may not be able to discover the provider-side translator (PLAT) translation IPv6 prefix used as a destination of the PLAT. If the visited network doesn't have a NAT64 and DNS64 deployed, 464XLAT can't perform successfully due to the lack of PLAT collaboration. Even in the case of the presence of NAT64 and DNS64, a pre-configured PLAT IPv6 prefix in the CLAT may cause failure because it can't match the PLAT translation.
ローカルブレイクアウトアプローチでは、464XLAT機能を持つIPv6訪問ネットワークでローミングしているUEは、さまざまな状況に遭遇する可能性があります。たとえば、訪問したネットワークがDNS64 [RFC6147]を展開しておらず、NAT64しか展開していない場合や、CLATがPLATの宛先として使用されるプロバイダー側トランスレータ（PLAT）変換IPv6プレフィックスを検出できない場合があります。訪問したネットワークにNAT64とDNS64が導入されていない場合、PLATコラボレーションがないため、464XLATは正常に実行できません。 NAT64およびDNS64が存在する場合でも、CLATに事前構成されたPLAT IPv6プレフィックスがPLAT変換と一致しないため、失敗する可能性があります。
Considering the various network configurations, operators may turn off local breakout and use the home routed mode to perform 464XLAT. Alternatively, UE may support the different roaming profile configuration to adopt 464XLAT in the home network and use IPv4-only in the visited networks.
さまざまなネットワーク構成を考慮して、事業者はローカルブレイクアウトをオフにし、ホームルーテッドモードを使用して464XLATを実行できます。あるいは、UEは、ホームネットワークで464XLATを採用し、訪問先ネットワークでIPv4のみを使用するために、さまざまなローミングプロファイル構成をサポートできます。
A proper user profile configuration would provide a deterministic outcome to the PDP/PDN creation stage where dual-stack, IPv4-only, and IPv6-only connectivity requests may come from devices. The HLR/HSS may have to apply extra logic (not standardized by 3GPP) to achieve this. It is also desirable that the network be able to set up connectivity of any requested PDP/PDN context type.
適切なユーザープロファイル構成は、デュアルスタック、IPv4のみ、およびIPv6のみの接続要求がデバイスから送信される可能性があるPDP / PDN作成ステージに確定的な結果を提供します。 HLR / HSSは、これを実現するために（3GPPによって標準化されていない）追加のロジックを適用する必要がある場合があります。また、ネットワークは、要求されたPDP / PDNコンテキストタイプの接続をセットアップできることが望ましいです。
The following are examples to illustrate the settings for the scenarios and the decision criteria to be applied when returning user profile information from the HLR to the visited SGSN.
以下は、HLRから訪問先のSGSNにユーザープロファイル情報を返すときに適用されるシナリオと決定基準の設定を示す例です。
user profile #1:
ユーザープロファイル＃1：
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2:
ユーザープロファイル＃2：
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6
....
}
Scenario 1: Support of IPv6-Only, IPv4-Only, and Dual-Stack Devices
シナリオ1：IPv6のみ、IPv4のみ、およびデュアルスタックデバイスのサポート
The full PDP-context parameters are referred to Section 17.7.1 ("Mobile Service data types") of [TS29.002]. User profiles #1 and #2 share the same "ContextId". The setting of user profile #1 enables IPv4-only and dual-stack devices to work. User profile #2 fulfills the request if the device asks for IPv6-only PDP context.
完全なPDPコンテキストパラメータについては、[TS29.002]のセクション17.7.1（「モバイルサービスデータタイプ」）を参照してください。ユーザープロファイル＃1と＃2は同じ "ContextId"を共有しています。ユーザープロファイル＃1を設定すると、IPv4のみのデバイスとデュアルスタックデバイスが機能します。デバイスがIPv6のみのPDPコンテキストを要求する場合、ユーザープロファイル＃2は要求を満たします。
user profile #1:
ユーザープロファイル＃1：
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2:
ユーザープロファイル＃2：
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
}
Scenario 2: Support of Dual-Stack Devices with Pre-Release 9 Visited SGSN (vSGSN) Access
シナリオ2：プレリリース9のVisited SGSN（vSGSN）アクセスでのデュアルスタックデバイスのサポート
User profiles #1 and #2 share the same "ContextId". If a visited SGSN is identified as early as pre-Release 9, the HLR/HSS should only send user profile #2 to the visited SGSN.
ユーザープロファイル＃1と＃2は同じ "ContextId"を共有しています。訪問されたSGSNがリリース9以前の段階で識別された場合、HLR / HSSはユーザープロファイル＃2のみを訪問されたSGSNに送信する必要があります。
Several failure cases have been discussed in this document. It has been illustrated that the major problems happen at three stages: the initial network attachment, the PDP/PDN creation, and service requests.
このドキュメントでは、いくつかの障害事例について説明しています。主要な問題は、初期ネットワーク接続、PDP / PDN作成、およびサービス要求の3つの段階で発生することが示されています。
In the network attachment stage, PDP/PDN Type IPv4v6 is the major concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/PDN Type IPv4v6 in the earlier releases. That PDP/PDN Type is supported in the newly built EPS network, but it isn't supported well in the third-generation network. Visited SGSNs may discard the subscriber's attach requests because the SGSN is unable to correctly process PDP/PDN Type IPv4v6. Operators may have to adopt temporary solutions unless all the interworking nodes (i.e., the SGSN) in the visited network have been upgraded to support the ext-PDP-Type feature.
ネットワーク接続の段階では、PDP / PDNタイプIPv4v6は、訪問されたリリース9以前のSGSNの主な関心事です。以前のリリースでは、3GPPはPDP / PDNタイプIPv4v6を指定していませんでした。そのPDP / PDNタイプは、新しく構築されたEPSネットワークでサポートされていますが、第3世代ネットワークでは十分にサポートされていません。 SGSNはPDP / PDNタイプIPv4v6を正しく処理できないため、訪問したSGSNはサブスクライバの接続要求を破棄する可能性があります。訪問先ネットワークのすべてのインターワーキングノード（つまり、SGSN）がext-PDP-Type機能をサポートするようにアップグレードされていない限り、オペレーターは一時的なソリューションを採用する必要がある場合があります。
In the PDP/PDN creation stage, support of PDP/PDN Types IPv4v6 and IPv6 on the visited SGSN is the major concern. It has been observed that single-stack IPv6 in the home routed mode is a viable approach to deploy IPv6. It is desirable that the visited SGSN have the ability to enable IPv6 on the user plane by default. For support of the PDP/PDN Type IPv4v6, it is suggested to set the DAF. As a complementary function, the implementation of a roaming APN configuration is useful to accommodate the visited network. However, it should consider roaming architecture and the permitted PDP/PDN Type to properly set the UE. Roaming APN in the home routed mode is recommended to align with home network profile setting. In the local breakout case, PDP/PDN Type IPv4 could be selected as a safe way to initiate PDP/PDN activation.
PDP / PDNの作成段階では、訪問したSGSNでのPDP / PDNタイプIPv4v6およびIPv6のサポートが主な関心事です。ホームルーテッドモードのシングルスタックIPv6は、IPv6を展開するための実行可能なアプローチであることが確認されています。訪問したSGSNがデフォルトでユーザープレーンでIPv6を有効にする機能を持つことが望ましいです。 PDP / PDNタイプIPv4v6をサポートするには、DAFを設定することをお勧めします。補完的な機能として、ローミングAPN構成の実装は、訪問先ネットワークに対応するのに役立ちます。ただし、UEを適切に設定するには、ローミングアーキテクチャと許可されたPDP / PDNタイプを考慮する必要があります。ホームルーテッドモードでのローミングAPNは、ホームネットワークプロファイル設定に合わせるために推奨されます。ローカルブレイクアウトの場合、PDP / PDNアクティベーションを開始する安全な方法としてPDP / PDNタイプIPv4を選択できます。
In the service requests stage, the failure cases mostly occur in the local breakout case. The visited network may not be able to satisfy the requested capability from applications or UEs. Operators may consider using home routed mode to avoid these problems. Several solutions, in either the network side or mobile device side, can also help to address the issue. For example,
サービスリクエストの段階では、失敗のケースは主にローカルのブレイクアウトケースで発生します。訪問先ネットワークは、アプリケーションまたはUEからの要求された機能を満たすことができない場合があります。オペレーターは、これらの問題を回避するためにホームルーテッドモードの使用を検討する場合があります。ネットワーク側またはモバイルデバイス側のいくつかのソリューションも、問題の解決に役立ちます。例えば、
o 464XLAT could help IPv4 applications access IPv6 visited networks.
o 464XLATは、IPv4アプリケーションがIPv6訪問済みネットワークにアクセスするのに役立ちます。
o Networks can deploy a AAA server to coordinate the mobile device capability. Once the GGSN/PGW receives the session creation request, it will initiate a request to a AAA server in the home network via the RADIUS or Diameter protocol [TS29.061]. The request contains subscriber and visited network information, e.g., PDP/PDN Type, International Mobile Equipment Identity (IMEI), Software Version (SV) and visited SGSN/MME location code, etc. The AAA server could take mobile device capability and combine it with the visited network information to ultimately determine the type of session to be created, i.e., IPv4, IPv6, or IPv4v6.
o ネットワークは、AAAサーバーを展開して、モバイルデバイス機能を調整できます。 GGSN / PGWがセッション作成要求を受信すると、RADIUSまたはDiameterプロトコルを介して、ホームネットワーク内のAAAサーバーへの要求を開始します[TS29.061]。要求には、PDP / PDNタイプ、国際モバイル機器ID（IMEI）、ソフトウェアバージョン（SV）、訪問したSGSN / MMEロケーションコードなどの加入者および訪問したネットワーク情報が含まれます。AAAサーバーは、モバイルデバイスの機能を利用して、それを組み合わせることができます。訪問したネットワーク情報を使用して、作成するセッションのタイプ、つまりIPv4、IPv6、またはIPv4v6を最終的に決定します。
Although this document defines neither a new architecture nor a new protocol, the reader is encouraged to refer to [RFC6459] for a generic discussion on IPv6-related security considerations.
このドキュメントは新しいアーキテクチャも新しいプロトコルも定義していませんが、IPv6関連のセキュリティの考慮事項に関する一般的な説明については、[RFC6459]を参照することをお勧めします。
[IR.21] Global System for Mobile Communications Association (GSMA), "Roaming Database, Structure and Updating Procedures", IR.21, Version 7.4, November 2013.
[IR.21]グローバルシステムfor Mobile Communications Association（GSMA）、「ローミングデータベース、構造、および更新手順」、IR.21、バージョン7.4、2013年11月。
[IR.65] Global System for Mobile Communications Association (GSMA), "IMS Roaming and Interworking Guidelines", IR.65, Version 15.0, January 2015.
[IR.65] Global Systems for Mobile Communications Association（GSMA）、「IMS Roaming and Interworking Guidelines」、IR.65、バージョン15.0、2015年1月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、2011年4月、<http：//www.rfc -editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv6 Clients to IPv4 Servers」、RFC 6147、2011年4月、<http： //www.rfc-editor.org/info/rfc6147>。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877] Mawatari、M.、Kawashima、M.、C。Byrne、「464XLAT：Combination of Stateful and Stateless Translation」、RFC 6877、2013年4月、<http://www.rfc-editor.org/info/ rfc6877>。
[TS23.060] 3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2 v9.00", TS 23.060, March 2009.
[TS23.060] 3GPP、「General Packet Radio Service（GPRS）;サービスの説明、ステージ2 v9.00」、TS 23.060、2009年3月。
[TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access v9.00", TS 23.401, March 2009.
[TS23.401] 3GPP、「Evolved Universal Terrestrial Radio Access Network（E-UTRAN）access v9.00 "のGeneral Packet Radio Service（GPRS）の機能強化、TS 23.401、2009年3月。
[TS29.002] 3GPP, "Mobile Application Part (MAP) specification v9.12.0", TS 29.002, December 2009.
[TS29.002] 3GPP、「モバイルアプリケーションパーツ（MAP）仕様v9.12.0」、TS 29.002、2009年12月。
[TS29.272] 3GPP, "Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol v9.00", TS 29.272, September 2009.
[TS29.272] 3GPP、「Diameterプロトコルv9.00」に基づくモビリティ管理エンティティ（MME）およびサービングGPRSサポートノード（SGSN）関連のインターフェース、TS 29.272、2009年9月。
[EU-Roaming-III] Amdocs Inc., "Amdocs 2014 EU Roaming Regulation III Solution", July 2013, <http://www.amdocs.com/Products/ Revenue-Management/Documents/ amdocs-eu-roaming-regulation-III-solution.pdf>.
[EU-Roaming-III] Amdocs Inc。、「Amdocs 2014 EU Roaming Regulation III Solution」、2013年7月、<http://www.amdocs.com/Products/ Revenue-Management / Documents / amdocs-eu-roaming-regulation -III-solution.pdf>。
[IR.33] Global System for Mobile Communications Association (GSMA), "GPRS Roaming Guidelines", IR.33, Version 7.0, June 2014.
[IR.33] Global Systems for Mobile Communications Association（GSMA）、「GPRS Roaming Guidelines」、IR.33、バージョン7.0、2014年6月。
[IR.34] Global System for Mobile Communications Association (GSMA), "Guidelines for IPX Provider networks", IR.34 Version 11.0, January 2015.
[IR.34] Mobile Communications Association（GSMA）のグローバルシステム、「IPXプロバイダーネットワークのガイドライン」、IR.34バージョン11.0、2015年1月。
[IR.88] Global System for Mobile Communications Association (GSMA), "LTE Roaming Guidelines", IR.88, Version 12.0, January 2015.
[IR.88] Global System for Mobile Communications Association（GSMA）、「LTE Roaming Guidelines」、IR.88、Version 12.0、2015年1月。
[IR.92] Global System for Mobile Communications Association (GSMA), "IMS Profile for Voice and SMS", IR.92, Version 7.1, January 2015.
[IR.92] Global Systems for Mobile Communications Association（GSMA）、「IMS Profile for Voice and SMS」、IR.92、バージョン7.1、2015年1月。
[RCC.07] Global System for Mobile Communications Association (GSMA), "Rich Communication Suite 5.2 Advanced Communications Services and Client Specification", RCC.07, Version 5.0, May 2014.
[RCC.07] Global Systems for Mobile Communications Association（GSMA）、「Rich Communication Suite 5.2 Advanced Communications Services and Client Specification」、RCC.07、バージョン5.0、2014年5月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、2010年10月、<http：// www .rfc-editor.org / info / rfc6052>。
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012, <http://www.rfc-editor.org/info/rfc6459>.
[RFC6459] Korhonen、J.、Ed。、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G.、and K. Iisakkila、 "IPv6 in the 3rd Generation Partnership Project（3GPP）Evolved Packet System（ EPS） "、RFC 6459、2012年1月、<http://www.rfc-editor.org/info/rfc6459>。
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012, <http://www.rfc-editor.org/info/rfc6535>.
[RFC6535] Huang、B.、Deng、H。、およびT. Savolainen、「Bump-in-the-Host（BIH）を使用したデュアルスタックホスト」、RFC 6535、2012年2月、<http：// www .rfc-editor.org / info / rfc6535>。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013, <http://www.rfc-editor.org/info/rfc7050>.
[RFC7050] Savolainen、T.、Korhonen、J。、およびD. Wing、「IPv6アドレス合成に使用されるIPv6プレフィックスの発見」、RFC 7050、2013年11月、<http://www.rfc-editor.org/ info / rfc7050>。
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, May 2014, <http://www.rfc-editor.org/info/rfc7225>.
[RFC7225] Boucadair、M。、「Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol（PCP）」、RFC 7225、2014年5月、<http://www.rfc-editor.org/info/rfc7225>。
[TR23.975] 3GPP, "IPv6 migration guidelines", TR 23.975, June 2011.
[TR23.975] 3GPP、「IPv6移行ガイドライン」、TR 23.975、2011年6月。
[TS23.003] 3GPP, "Numbering, addressing and identification v9.0.0", TS 23.003, September 2009.
[TS23.003] 3GPP、「番号付け、アドレス指定および識別v9.0.0」、TS 23.003、2009年9月。
[TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 v9.00", TS 24.008, September 2009.
[TS24.008] 3GPP、「モバイル無線インターフェースレイヤー3仕様、コアネットワークプロトコル、ステージ3 v9.00」、TS 24.008、2009年9月。
[TS24.301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) ; Stage 3 v9.00", TS 24.301, September 2009.
[TS24.301] 3GPP、「進化したパケットシステム（EPS）の非アクセス層（NAS）プロトコル、ステージ3 v9.00」、TS 24.301、2009年9月。
[TS29.061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) v9.14.0", TS 29.061, January 2015.
[TS29.061] 3GPP、「パケットベースのサービスをサポートするPublic Land Mobile Network（PLMN）とパケットデータネットワーク（PDN）v9.14.0の間のインターワーキング」、TS 29.061、2015年1月。
[TS29.212] 3GPP, "Policy and Charging Control (PCC); Reference points v9.0.0", TS 29.212, September 2009.
[TS29.212] 3GPP、「Policy and Charging Control（PCC）; Reference points v9.0.0 "、TS 29.212、2009年9月。
Acknowledgements
謝辞
Many thanks to F. Baker and J. Brzozowski for their support.
F. BakerとJ. Brzozowskiのサポートに感謝します。
This document is the result of the IETF v6ops IPv6-Roaming design team effort.
このドキュメントは、IETF v6ops IPv6-Roaming設計チームの取り組みの成果です。
The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, Nick Heatley, Alexandru Petrescu, Tore Anderson, Cameron Byrne, Holger Metschulat, and Geir Egeland for their helpful discussions and comments.
著者は、有益な議論とコメントをしてくれたMikael Abrahamsson、Victor Kuarsingh、Nick Heatley、Alexandru Petrescu、Tore Anderson、Cameron Byrne、Holger Metschulat、およびGeir Egelandに感謝します。
The authors especially thank Fred Baker and Ross Chandler for their efforts and contributions that substantially improved the readability of the document.
著者は、フレッドベイカーとロスチャンドラーが、文書の可読性を大幅に向上させた取り組みと貢献に特に感謝します。
Contributors
貢献者
The following individual contributed to this document.
次の個人がこのドキュメントに貢献しました。
Vizdal Ales Deutsche Telekom AG Tomickova 2144/1 Prague 4, 149 00 Czech Republic
Vizdal Ales Deutsche Telekom AG Tomickova 2144/1 Prague 4、149 00 Czech Republic
EMail: ales.vizdal@t-mobile.cz
Authors' Addresses
著者のアドレス
Gang Chen China Mobile 53A,Xibianmennei Ave., Xicheng District, Beijing 100053 China
ギャングチェンチャイナモバイル53A、ξsidegate ave。、ξ成地区、北京100053中国
EMail: phdgang@gmail.com, chengang@chinamobile.com
Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China
Hui Deng China Mobile 53A、ξサイドドアアベニュー、X UA N、地区なし、北京100053中国
EMail: denghui@chinamobile.com
Dave Michaud Rogers Communications 8200 Dixie Rd. Brampton, ON L6T 0C1 Canada
Dave Michaud Rogers Communications 8200 Dixie Rd。ブランプトン、ON L6T 0C1カナダ
EMail: dave.michaud@rci.rogers.com
Jouni Korhonen Broadcom Corporation 3151 Zanker Rd. San Jose, CA 95134 United States
Jouni Korhonen Broadcom Corporation 3151 Zanker Rd。サンノゼ、CA 95134アメリカ合衆国
EMail: jouni.nospam@gmail.com
Mohamed Boucadair France Telecom Rennes, 35000 France
Mohamed Boucadair France Telecom Rennes、35000 France
EMail: mohamed.boucadair@orange.com