RFC 6342 - Mobile Networks Considerations for IPv6 Deployment 日本語訳

URL : https://tools.ietf.org/html/rfc6342
タイトル : RFC 6342 - IPv6の展開のためのモバイルネットワークの考慮事項
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                         R. Koodli
Request for Comments: 6342                                 Cisco Systems
Obsoletes: 6312                                              August 2011
Category: Informational
ISSN: 2070-1721

           Mobile Networks Considerations for IPv6 Deployment

Abstract

抽象

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers.

スマートフォンなどのモバイル機器からモバイルインターネットアクセスは、IPv4アドレスの枯渇を加速しています。 IPv6が広く、インターネットの継続的な操作と成長のための重要なと見られ、特に、それは、モバイルネットワークで重要です。この文書では、モバイルネットワークでIPv6を展開するときに発生する問題について説明します。したがって、この文書は、サービスプロバイダやネットワーク設計者にとって便利な参照することができます。

RFC Editor Note

RFCエディタ注意

This document obsoletes RFC 6312.

この文書はRFC 6312を廃止します。

Due to a publishing error, RFC 6312 contains the incorrect RFC number in its header. This document corrects that error with a new RFC number. The specification herein is otherwise unchanged with respect to RFC 6312.

出版誤差に、RFC 6312は、ヘッダ内の誤ったRFC番号を含みます。この文書は、新しいRFC番号とそのエラーを訂正します。明細書は、本明細書RFC 6312に対して別段変わりません。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。

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）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6342.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6342で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1. Introduction ....................................................2
   2. Reference Architecture and Terminology ..........................3
   3. IPv6 Considerations .............................................4
      3.1. IPv4 Address Exhaustion ....................................4
      3.2. NAT Placement in Mobile Networks ...........................7
      3.3. IPv6-Only Deployment Considerations .......................10
      3.4. Fixed-Mobile Convergence ..................................13
   4. Summary and Conclusion .........................................14
   5. Security Considerations ........................................16
   6. Acknowledgements ...............................................16
   7. Informative References .........................................16

1. Introduction

1. はじめに

The dramatic growth of the Mobile Internet is accelerating the exhaustion of the available IPv4 addresses. It is widely accepted that IPv6 is necessary for the continued operation and growth of the Internet in general and of the Mobile Internet in particular. While IPv6 brings many benefits, certain unique challenges arise when deploying it in mobile networks. This document describes such challenges and outlines the applicability of the existing IPv6 deployment solutions. As such, it can be a useful reference document for service providers as well as network designers. This document does not propose any new protocols or suggest new protocol specification work.

モバイルインターネットの飛躍的な成長が可能なIPv4アドレスの枯渇を加速しています。広くIPv6が一般的で、特にモバイルインターネットの継続的な動作とインターネットの成長のために必要であることが認められています。 IPv6は多くの利点をもたらす一方で、モバイルネットワークでそれを展開するときに、特定のユニークな課題が発生します。この文書では、このような課題を説明し、既存のIPv6展開ソリューションの適用可能性を概説します。このように、それは、サービスプロバイダだけでなく、ネットワーク設計者にとって有益な参考文書にすることができます。このドキュメントは、新しいプロトコルを提案したり、新しいプロトコル仕様の仕事を示唆していません。

The primary considerations that we address in this document on IPv6 deployment in mobile networks are:

私たちは、モバイルネットワークにおけるIPv6の展開上、本書で扱う主な検討事項は以下のとおりです。

o Public and Private IPv4 address exhaustion and implications to mobile network deployment architecture;

パブリックおよびプライベートIPv4のアドレス枯渇とモバイルネットワーク展開アーキテクチャへの影響O;

o Placement of Network Address Translation (NAT) functionality and its implications;

Oの配置ネットワークのアドレス変換（NAT）機能性とその意義。

o IPv6-only deployment considerations and roaming implications; and

IPv6のみの展開の考慮事項およびローミング意味合いO;そして

o Fixed-Mobile Convergence and implications to overall architecture.

O固定モバイルコンバージェンスおよびアーキテクチャ全体への影響。

In the following sections, we discuss each of these in detail.

次のセクションでは、我々は詳細にこれらのそれぞれについて説明します。

For the most part, we assume the Third Generation Partnership Project (3GPP) 3G and 4G network architectures specified in [3GPP.3G] and [3GPP.4G]. However, the considerations are general enough for other mobile network architectures as well [3GPP2.EHRPD].

ほとんどの部分については、我々は[3GPP.3G]と[3GPP.4G]で指定した第三世代パートナーシッププロジェクト（3GPP）、3Gおよび4Gネットワークアーキテクチャを前提としています。しかし、考察は[3GPP2.EHRPD]ならびに他のモバイルネットワークアーキテクチャのために十分一般的です。

2. Reference Architecture and Terminology

2.リファレンスアーキテクチャと用語

The following is a reference architecture of a mobile network.

以下は、モバイルネットワークの参照アーキテクチャです。

                                +-----+    +-----+
                                | AAA |    | PCRF|
                                +-----+    +-----+
              Home Network         \          /
                                    \        /                       /-
                                     \      /                       / I
  MN     BS                           \    /                       /  n
   |     /\    +-----+ /-----------\ +-----+ /-----------\ +----+ /   t
 +-+    /_ \---| ANG |/ Operator's  \| MNG |/ Operator's  \| BR |/    e
 | |---/    \  +-----+\ IP Network  /+-----+\ IP Network  /+----+\    r
 +-+                   \-----------/    /    \-----------/        \   n
                       ----------------/------                     \  e
                     Visited Network  /                             \ t
                                     /                               \-
         +-----+ /------------------\
         | ANG |/ Visited Operator's \
         +-----+\     IP Network     /
                 \------------------/

Figure 1: Mobile Network Architecture

図1：モバイルネットワークアーキテクチャ

A Mobile Node (MN) connects to the mobile network either via its Home Network or via a Visited Network when the user is roaming outside of the Home Network. In the 3GPP network architecture, an MN accesses the network by connecting to an Access Point Name (APN), which maps to a mobile gateway. Roughly speaking, an APN is similar to a Service Set Identifier (SSID) in wireless LAN. An APN is a logical concept that can be used to specify what kinds of services, such as Internet access, high-definition video streaming, content-rich gaming, and so on, that an MN is entitled to. Each APN can specify what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN.

モバイルノード（MN）は、ホームネットワークを介して、またはユーザがホームネットワークの外にローミングしている訪問先ネットワークを介してのいずれかでモバイルネットワークに接続します。 3GPPネットワークアーキテクチャでは、MNは、モバイルゲートウェイにマップアクセスポイント名（APN）に接続してネットワークにアクセスします。大雑把に言えば、APNは、無線LANでのサービスセット識別子（SSID）に似ています。 APNは、MNがに資格を与えられるようにようにインターネット接続、高精細ビデオストリーミング、コンテンツが豊富なゲーム、などのサービス、何の種類を指定するために使用することができる論理的な概念です。各APN（すなわち、のIPv4、IPv6の、IPv4v6）は、その特定のAPNで有効になっているIP接続の種類を指定することができます。

While an APN directs an MN to an appropriate gateway, the MN needs an end-to-end "link" to that gateway. In the Long-Term Evolution (LTE) networks, this link is realized through an Evolved Packet System (EPS) bearer. In the 3G Universal Mobile Telecommunications System (UMTS) networks, such a link is realized through a Packet Data Protocol (PDP) context. The end-to-end link traverses multiple nodes, which are defined below:

APNは、適切なゲートウェイにMNに指示しながら、MNはそのゲートウェイへのエンドツーエンドの「リンク」を必要とします。ロングタームエボリューション（LTE）ネットワークでは、このリンクは、発展型パケットシステム（EPS）ベアラを介して実現されます。 3Gユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）ネットワークでは、このようなリンクは、パケットデータプロトコル（PDP）コンテキストを介して実現されます。エンドツーエンドのリンクは、以下に定義されている複数のノードを横断します：

o Base Station (BS): The radio Base Station provides wireless connectivity to the MN.

O基地局（BS）、無線基地局は、MNに無線接続を提供します。

o Access Network Gateway (ANG): The ANG forwards IP packets to and from the MN. Typically, this is not the MN's default router, and the ANG does not perform IP address allocation and management for the mobile nodes. The ANG is located either in the Home Network or in the Visited Network.

アクセス・ネットワーク・ゲートウェイ（ANG）O：ANGは、MNへとからIPパケットを転送します。通常、これはMNのデフォルトルータではなく、ANGは、モバイルノードのIPアドレスの割り当てと管理を実行しません。 ANGは、ホームネットワークや訪問先ネットワークのいずれかに位置しています。

o The Mobile Network Gateway (MNG): The MNG is the MN's default router, which provides IP address management. The MNG performs functions such as offering Quality of Service (QoS), applying subscriber-specific policy, and enabling billing and accounting; these functions are sometimes collectively referred to as "subscriber-management" operations. The mobile network architecture, as shown in Figure 1, defines the necessary protocol interfaces to enable subscriber-management operations. The MNG is typically located in the Home Network.

モバイルネットワークゲートウェイ（MNG）O：MNGは、IPアドレス管理を提供MNのデフォルトルータ、です。 MNGは、例えば、サービス品質（QoS）を提供し、加入者固有のポリシーを適用し、課金及びアカウンティングを可能にするような機能を実行します。これらの機能は、総称「加入者管理」動作と呼ばれます。モバイルネットワークアーキテクチャは、図1に示すように、加入者管理操作を可能にするために必要なプロトコルインターフェースを定義します。 MNGは通常、ホームネットワークに位置しています。

o Border Router (BR): As the name implies, a BR borders the Internet for the mobile network. The BR does not perform subscriber management for the mobile network.

Oボーダールータ（BR）：名前が示すように、BRは、モバイルネットワークのためのインターネットに接し。 BRは、モバイルネットワークの加入者管理を実行しません。

o Authentication, Authorization, and Accounting (AAA): The general functionality of AAA is used for subscriber authentication and authorization for services as well as for generating billing and accounting information.

認証、許可、アカウンティング（AAA）O：AAAの一般的な機能は、サービスのための加入者認証および許可のために、ならびに課金を生成し、会計情報のために使用されます。

In 3GPP network environments, the subscriber authentication and the subsequent authorization for connectivity and services is provided using the "Home Location Register" (HLR) / "Home Subscriber Server" (HSS) functionality.

3GPPネットワーク環境では、加入者認証および接続およびサービスに対する後続の認可は、「ホーム・ロケーション・レジスタ」（HLR）/「ホーム加入者サーバ」（HSS）機能を使用して提供されます。

o Policy and Charging Rule Function (PCRF): The PCRF enables applying policy and charging rules at the MNG.

Oポリシーおよび課金ルール機能（PCRF）：PCRFは、ポリシーを適用し、MNGでルールを充電可能。

In the rest of this document, we use the terms "operator", "service provider", and "provider" interchangeably.

このドキュメントの残りの部分では、我々は、交換可能に用語「オペレータ」、「サービスプロバイダ」、および「プロバイダー」を使用します。

3. IPv6 Considerations

3. IPv6の上の考慮事項

3.1. IPv4 Address Exhaustion

3.1. IPアドレス枯渇問題

It is generally agreed that the pool of public IPv4 addresses is nearing its exhaustion. The IANA has exhausted the available '/8' blocks for allocation to the Regional Internet Registries (RIRs). The RIRs themselves have either "run out" of their blocks or are projected to exhaust them in the near future. This has led to a heightened awareness among service providers to consider introducing technologies to keep the Internet operational. For providers, there are two simultaneous approaches to addressing the run-out problem: delaying the IPv4 address pool exhaustion (i.e., conserving their existing pool) and introducing IPv6 in operational networks. We consider both in the following.

一般的にパブリックIPv4アドレスのプールが枯渇に近づいていることが合意されています。 IANAは、地域インターネットレジストリ（のRIR）に割り当て可能な「/ 8」ブロックを使い果たしました。自身はどちらか持っているRIRはそのブロックの「切れ」または近い将来にそれらを排出すると予測されています。これは、運用インターネットを維持するための技術の導入を検討するために、サービスプロバイダーの間で意識の高まりにつながっています。（すなわち、既存のプールを節約）のIPv4アドレスプールの枯渇を遅らせると運用ネットワークでIPv6を導入：プロバイダの場合は、振れの問題に対処するため、2つの同時アプローチがあります。私たちは、次のように両方を検討してください。

Delaying public IPv4 address exhaustion for providers involves assigning private IPv4 addressing for end-users or extending an IPv4 address with the use of port ranges, which requires tunneling and additional signaling. A mechanism such as the Network Address Translator (NAT) is used at the provider premises (as opposed to customer premises) to manage the private IP address assignment and access to the Internet. In the following, we primarily focus on translation-based mechanisms such as NAT44 (i.e., translation from public IPv4 to private IPv4 and vice versa) and NAT64 (i.e., translation from public IPv6 to public IPv4 and vice versa). We do this because the 3GPP architecture already defines a tunneling infrastructure with the General Packet Radio Service (GPRS) Tunneling Protocol (GTP), and the architecture allows for dual-stack and IPv6-only deployments.

プロバイダのパブリックIPv4アドレスの枯渇を遅らせることは、エンドユーザのためのアドレス指定又はトンネリングと追加のシグナリングを必要とするポート範囲の使用でIPv4アドレスを拡張プライベートIPv4を割り当てることを含みます。（顧客宅内ではなく）ネットワークアドレス変換（NAT）は、プロバイダの構内に使用されるような仕組みは、インターネットにプライベートIPアドレスの割り当てとアクセスを管理します。以下では、我々は、主に、NAT44（即ち、プライベートIPv4のパブリックIPv4から翻訳およびその逆）とNAT64（即ち、パブリックIPv4へ公共のIPv6から変換およびその逆）として翻訳ベースのメカニズムに焦点を当てます。 3GPPアーキテクチャはすでに汎用パケット無線サービス（GPRS）トンネリングプロトコル（GTP）と、トンネルインフラストラクチャを定義し、アーキテクチャは、デュアルスタックとIPv6のみの展開が可能になりますので、我々はこれを行います。

In a mobile network, the IPv4 address assignment for an MN is performed by the MNG. In the 3GPP network architecture, this assignment is performed in conjunction with the Packet Data Network (PDN) connectivity establishment. A PDN connection implies an end-end link (i.e., an EPS bearer in 4G LTE or a PDP context in 3G UMTS) from the MN to the MNG. There can be one or more PDN connections active at any given time for each MN. A PDN connection may support both IPv4 and IPv6 traffic (as in a dual-stack PDN in 4G LTE networks), or it may support only one of the two traffic types (as in the existing 3G UMTS networks). The IPv4 address is assigned at the time of PDN connectivity establishment or is assigned using DHCP after the PDN connectivity is established. In order to delay the exhaustion of public IPv4 addresses, this IP address needs to be a private IPv4 address that is translated into a shared public IPv4 address. Hence, there is a need for a private-public IPv4 translation mechanism in the mobile network.

モバイルネットワークでは、MNのIPv4アドレスの割り当ては、MNGによって行われます。 3GPPネットワークアーキテクチャでは、この割り当ては、パケットデータネットワーク（PDN）接続の確立に関連して行われます。 PDN接続は、エンドエンドのリンクを意味し（すなわち、4G LTEにおけるEPSベアラまたは3G UMTSにおけるPDPコンテキスト）MNGにMNから。各MNのための任意の時点でアクティブな1つのまたは複数のPDN接続が存在する場合があります。 PDN接続が（4G LTEネットワークにおけるデュアルスタックPDNのように）、IPv4とIPv6の両方のトラフィックをサポートすることができる、またはそれは、（既存の3G UMTSネットワークのような）2つのトラフィックタイプのうち1つだけをサポートすることができます。 IPv4アドレスは、PDN接続の確立時に割り当てられているか、PDN接続が確立された後にDHCPを使用して割り当てられます。パブリックIPv4アドレスの枯渇を遅らせるためには、このIPアドレスは、共有パブリックIPv4アドレスに変換されたプライベートIPv4アドレスである必要があります。したがって、モバイルネットワークにおける官民のIPv4変換メカニズムの必要性があります。

In the Long-Term Evolution (LTE) 4G network, there is a requirement for an always-on PDN connection in order to reliably reach a mobile user in the All-IP network. This requirement is due to the need for supporting Voice over IP service in LTE, which does not have circuit-based infrastructure. If this PDN connection were to use IPv4 addressing, a private IPv4 address is needed for every MN that attaches to the network. This could significantly affect the availability and usage of private IPv4 addresses. One way to address this is by making the always-on PDN (that requires voice service) to be IPv6. The IPv4 PDN is only established when the user needs it.

ロングタームエボリューション（LTE）、4Gネットワークでは、確実にすべてのIPネットワークにおけるモバイルユーザに到達するためにPDN常時接続の必要があります。この要件は、回線ベースのインフラストラクチャを持っていないLTEでのIPサービス、ボイスオーバーを支援する必要性によるものです。このPDN接続がIPv4アドレスを使用した場合、プライベートIPv4アドレスは、ネットワークに接続するすべてのMNのために必要とされています。これはかなりプライベートIPv4アドレスの可用性と使用方法に影響を与える可能性があります。これに対処する1つの方法は、IPv6であることを常にオンのPDN（つまり、音声サービスを必要とする）ことによって、です。ユーザーがそれを必要とするときはIPv4 PDNにのみ確立されています。

The 3GPP standards also specify a deferred IPv4 address allocation on a dual-stack IPv4v6 PDN at the time of connection establishment. This has the advantage of a single PDN for IPv6 and IPv4 along with deferring IPv4 address allocation until an application needs it. The deferred address allocation requires support for a dynamic configuration protocol such as DHCP as well as appropriate triggers to invoke the protocol. Such a support does not exist today in mobile phones. The newer iterations of smartphones could provide such support. Also, the tethering of smartphones to laptops (which typically support DHCP) could use deferred allocation depending on when a laptop attaches to the smartphone. Until appropriate triggers and host stack support is available, the applicability of the address-deferring option may be limited.

3GPP規格は、接続確立時にデュアルスタックIPv4v6 PDN上の繰延IPv4アドレスの割り当てを指定します。これは、アプリケーションがそれを必要とするまでIPv4アドレスの割り当てを遅らせるとともに、IPv6とIPv4のための単一のPDNの利点を有します。遅延アドレスの割り当ては、DHCPなどの動的構成プロトコルのためのサポート、ならびにプロトコルを呼び出すための適切なトリガーを必要とします。このようなサポートは、携帯電話で、今日存在していません。スマートフォンの新しい反復が、そのようなサポートを提供することができます。また、（通常はDHCPをサポート）のノートパソコンへのスマートフォンのテザリングは、ラップトップ、スマートフォンに接続するときに応じて、繰延割り当てを使用することができます。適切なトリガとホストスタックのサポートが利用可能になるまで、アドレス・延期オプションの適用が制限される場合があります。

On the other hand, in the existing 3G UMTS networks, there is no requirement for an always-on connection even though many smartphones seldom relinquish an established PDP context. The existing so-called pre-Release-8 deployments do not support the dual-stack PDP connection. Hence, two separate PDP connections are necessary to support IPv4 and IPv6 traffic. Even though some MNs, especially the smartphones, in use today may have IPv6 stack, there are two remaining considerations. First, there is little operational experience and compliance testing with these existing stacks. Hence, it is expected that their use in large deployments may uncover software errors and interoperability problems that inhibit providing services based on IPv6 for such hosts. Second, only a fraction of current phones in use have such a stack. As a result, providers need to test, deploy, and operationalize IPv6 as they introduce new handsets, which also continue to need access to the predominantly IPv4 Internet.

一方、既存の3G UMTSネットワークでは、のための要件は、多くのスマートフォンはほとんど確立されたPDPコンテキストを放棄しないにも関わらず常時接続はありません。既存のいわゆるプレリリース-8の展開は、デュアルスタックPDP接続をサポートしていません。従って、二つの別々のPDPの接続は、IPv4とIPv6のトラフィックをサポートするために必要です。使用中のいくつかのMN、特にスマートフォン、今日はIPv6スタックを持っている場合でも、残りの2つの考慮事項があります。まず、これらの既存のスタックと少し運用経験とコンプライアンス・テストがあります。したがって、大規模な展開での使用は、ソフトウェアのエラーや、ホストのIPv6に基づいたサービスを提供する阻害相互運用性の問題を明らかにすることが期待されます。第二に、現在使用中の携帯電話の一部のみが、このようなスタックを持っています。その結果、プロバイダは、テスト、デプロイ、彼らはまた、主にIPv4インターネットへのアクセスを必要としていき、新しい携帯電話を、ご紹介してIPv6を運用可能にする必要があります。

The considerations from the preceeding paragraphs lead to the following observations. First, there is an increasing need to support private IPv4 addressing in mobile networks because of the public IPv4 address run-out problem. Correspondingly, there is a greater need for private-public IPv4 translation in mobile networks. Second, there is support for IPv6 in both 3G and 4G LTE networks already in the form of PDP context and PDN connections. To begin with, operators can introduce IPv6 for their own applications and services. In other words, the IETF's recommended model of dual-stack IPv6 and IPv4 networks is readily applicable to mobile networks with the support for distinct APNs and the ability to carry IPv6 traffic on PDP/PDN connections. The IETF dual-stack model can be applied using a single IPv4v6 PDN connection in Release-8 and onwards but requires separate PDP contexts in the earlier releases. Finally, operators can make IPv6 the default for always-on mobile connections using either the IPv4v6 PDN or the IPv6 PDN and use IPv4 PDNs as necessary.

先行段落からの考慮事項は以下の観察につながります。まず、理由はパブリックIPv4アドレス振れ問題のモバイルネットワークに取り組むプライベートIPv4をサポートする必要性が高まっています。これに対応し、モバイルネットワークにおける官民のIPv4翻訳のための大きい必要性があります。第二に、既にPDPコンテキストとPDN接続の形で3Gおよび4G LTE両方のネットワークにおけるIPv6のサポートがあります。まず、事業者は、独自のアプリケーションやサービスのためにIPv6を導入することができます。つまり、デュアルスタックIPv6とIPv4ネットワークのIETFの推奨モデルが明確なのAPNとPDP / PDN接続でIPv6トラフィックを運ぶ能力をサポートするモバイルネットワークに容易に適用することができます。 IETFデュアルスタックモデルがリリース-8での単一IPv4v6 PDNコネクションを使用して適用し、以降はなく、以前のリリースでは、別のPDPコンテキストを必要とすることができます。最後に、オペレータは、IPv6 IPv4v6 PDNまたはIPv6 PDNのいずれかを使用してモバイル接続、常時オンし、必要に応じてのIPv4のPDNを使用するためのデフォルトにすることができます。

3.2. NAT Placement in Mobile Networks

3.2. モバイルネットワークでのNATの配置

In the previous section, we observed that NAT44 functionality is needed in order to conserve the available pool and delay public IPv4 address exhaustion. However, the available private IPv4 pool itself is not abundant for large networks such as mobile networks. For instance, the so-called NET10 block [RFC1918] has approximately 16.7 million private IPv4 addresses starting with 10.0.0.0. A large mobile service provider network can easily have more than 16.7 million subscribers attached to the network at a given time. Hence, the private IPv4 address pool management and the placement of NAT44 functionality becomes important.

前のセクションでは、我々は、NAT44機能が利用可能なプールを節約し、パブリックIPv4アドレスの枯渇を遅らせるために必要とされていることを観察しました。ただし、利用できるプライベートIPv4プール自体は、モバイルネットワークなどの大規模なネットワークのための豊富ではありません。例えば、いわゆるNET10ブロック[RFC1918]は10.0.0.0で始まる約1670万のプライベートIPv4アドレスを持っています。大規模なモバイルサービスプロバイダのネットワークを簡単に与えられた時間に、ネットワークに接続されている以上の1670万人の加入者を持つことができます。したがって、プライベートIPv4アドレスプール管理とNAT44機能の配置が重要になります。

In addition to the developments cited above, NAT placement is important for other reasons as well. Access networks generally need to produce network and service usage records for billing and accounting. This is true also for mobile networks where "subscriber management" features (i.e., QoS, Policy, and Billing and Accounting) can be fairly detailed. Since a NAT introduces a binding between two addresses, the bindings themselves become necessary information for subscriber management. For instance, the offered QoS on private IPv4 address and the (shared) public IPv4 address may need to be correlated for accounting purposes. As another example, the Application Servers within the provider network may need to treat traffic based on policy provided by the PCRF. If the IP address seen by these Application Servers is not unique, the PCRF needs to be able to inspect the NAT binding to disambiguate among the individual MNs. The subscriber session management information and the service usage information also need to be correlated in order to produce harmonized records. Furthermore, there may be legal requirements for storing the NAT binding records. Indeed, these problems disappear with the transition to IPv6. For now, it suffices to assert that NAT introduces state, which needs to be correlated and possibly stored with other routine subscriber information.

上に引用動向に加えて、NATの配置は、同様に他の理由のために重要です。アクセスネットワークは、一般的に課金および会計のためのネットワークとサービス使用状況レコードを生成する必要があります。これは、「加入者管理」機能（すなわち、QoSの、ポリシー、および課金および会計）はかなり詳細なことができ、モバイルネットワークについても同様です。 NATは、2つのアドレス間の結合を導入するため、バインディング自体は、加入者管理に必要な情報となります。たとえば、プライベートIPv4アドレスにQoSを提供し、（共有）パブリックIPv4アドレスは、会計目的のために相関させる必要があるかもしれません。別の例として、プロバイダーネットワーク内のアプリケーションサーバは、PCRFによって提供されるポリシーに基づいてトラフィックを処理する必要があるかもしれません。これらのアプリケーションサーバーから見たIPアドレスが一意でない場合、PCRFは、個々のMNの間で明確にするために結合NATを検査できるようにする必要があります。加入者セッション管理情報とサービス利用情報は、調和のとれたレコードを生成するために相関する必要があります。さらに、NATバインディングレコードを格納するための法的要件があるかもしれません。確かに、これらの問題は、IPv6への移行で消えます。今のところ、それは、NATが相関する必要があり、場合によっては他のルーチンの加入者情報が格納された状態を導入することを主張すればよいです。

Mobile network deployments vary in their allocation of IP address pools. Some network deployments use the "centralized model" where the pool is managed by a common node, such as the PDN's BR, and the pool shared by multiple MNGs all attached to the same BR. This model has served well in the pre-3G deployments where the number of subscribers accessing the Mobile Internet at any given time has not exceeded the available address pool. However, with the advent of 3G networks and the subsequent dramatic growth in the number of users on the Mobile Internet, service providers are increasingly forced to consider their existing network design and choices. Specifically, providers are forced to address private IPv4 pool exhaustion as well as scalable NAT solutions.

モバイルネットワークの展開は、IPアドレスプールの彼らの配分が異なります。いくつかのネットワーク展開では、プールは、PDNのBRとして、共通ノードによって管理される「集中型モデル」と同じBRに取り付けられた複数MNGS全てによって共有プールを使用します。このモデルは、任意の時点でモバイルインターネットにアクセスする加入者の数が利用可能なアドレスプールを超えていない前の3G展開にも役立っています。しかし、3Gネットワークおよびモバイルインターネット上のユーザー数で、その後の飛躍的な成長の出現により、サービスプロバイダは、ますます彼らの既存のネットワーク設計と選択肢を検討することを余儀なくされています。具体的には、プロバイダは、プライベートIPv4プールの枯渇だけでなく、スケーラブルなNATソリューションに対処することを余儀なくされています。

In order to tackle the private IPv4 exhaustion in the centralized model, there would be a need to support overlapped private IPv4 addresses in the common NAT functionality as well as in each of the gateways. In other words, the IP addresses used by two or more MNs (which may be attached to the same MNG) are very likely to overlap at the centralized NAT, which needs to be able to differentiate traffic. Tunneling mechanisms such as Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890], MPLS [RFC3031] VPN tunnels, or even IP-in-IP encapsulation [RFC2003] that can provide a unique identifier for a NAT session can be used to separate overlapping private IPv4 traffic as described in [GI-DS-LITE]. An advantage of centralizing the NAT and using the overlapped private IPv4 addressing is conserving the limited private IPv4 pool. It also enables the operator's enterprise network to use IPv6 from the MNG to the BR; this (i.e., the need for an IPv6-routed enterprise network) may be viewed as an additional requirement by some providers. The disadvantages include the need for additional protocols to correlate the NAT state (at the common node) with subscriber session information (at each of the gateways), suboptimal MN-MN communication, absence of subscriber-aware NAT (and policy) function, and, of course, the need for a protocol from the MNG to BR itself. Also, if the NAT function were to experience failure, all the connected gateway service will be affected. These drawbacks are not present in the "distributed" model, which we discuss in the following.

集中型モデルでのプライベートIPv4枯渇に対処するためには、一般的なNAT機能ならびに各ゲートウェイに重複プライベートIPv4アドレスをサポートする必要があるだろう。換言すれば、（同じMNGに取り付けられていてもよい）は、2つの以上のMNによって使用されるIPアドレスは、トラフィックを区別できるようにする必要が集中NAT、に重なる可能性が非常に高いです。このような汎用ルーティングカプセル化（GRE）[RFC2784]、[RFC2890]、MPLS [RFC3031] VPNトンネル、あるいはIP-in-IPカプセル化などのトンネリングメカニズムNATセッションの一意の識別子を提供することができる[RFC2003]は分離することができます[GI-DS-LITE]で説明したように、重複プライベートIPv4トラフィック。 NATを集中して取り組む重複プライベートIPv4を使用することの利点は、限られたプライベートIPv4プールが節約されます。また、BRにMNGからIPv6を使用する事業者の企業ネットワークを可能にします。これは（即ち、IPv6のルーティング企業ネットワークの必要性）は、いくつかのプロバイダによって追加の要件として見ることができます。不利な点は、（ゲートウェイのそれぞれにおいて）加入者セッション情報と（共通ノードで）NAT状態を相関させる付加的なプロトコルの必要性、次善のMN-MN通信、加入者認識NAT（およびポリシー）関数が存在しない、とを含みますもちろん、MNGからプロトコルの必要性は、それ自体をBRにします。 NAT機能は、障害が発生した場合にも、接続されているすべてのゲートウェイサービスが影響を受けることになります。これらの欠点は、我々は、以下で議論する「分散型」モデル、中には存在しません。

In a distributed model, the private IPv4 address management is performed by the MNG, which also performs the NAT functionality. In this model, each MNG has a block of 16.7 million unique addresses, which is sufficient compared to the number of mobile subscribers active on each MNG. By distributing the NAT functionality to the edge of the network, each MNG is allowed to reuse the available NET10 block, which avoids the problem of overlapped private IPv4 addressing at the network core. In addition, since the MNG is where subscriber management functions are located, the NAT state correlation is readily enabled. Furthermore, an MNG already has existing interfaces to functions such as AAA and PCRF, which allows it to perform subscriber management functions with the unique private IPv4 addresses. Finally, the MNG can also pass-through certain traffic types without performing NAT to the Application Servers located within the service provider's domain, which allows the servers to also identify subscriber sessions with unique private IPv4 addresses. The disadvantages of the "distributed model" include the absence of centralized addressing and centralized management of NAT.

分散モデルでは、プライベートIPv4アドレス管理はまた、NAT機能を実行MNG、によって行われます。このモデルでは、各MNG各MNG上のアクティブ移動体加入者の数に比べて十分である1670万個のユニークなアドレスのブロックを有しています。ネットワークのエッジにNAT機能を分散することにより、各MNGは、ネットワークコアでアドレッシング重複プライベートIPv4の問題を回避する利用可能なNET10ブロックを、再利用することができます。また、MNGので、加入者管理機能が置かれている場合、NAT状態の相関が容易に使用可能です。さらに、MNGはすでにそれがユニークなプライベートIPv4アドレスと加入者管理機能を実行することを可能にするAAAとPCRFとして機能へのインタフェースを既存ました。最後に、MNGもパススルーすることができ、特定のトラフィックタイプのサーバーも独自のプライベートIPv4アドレスと加入者セッションを識別することを可能にするサービスプロバイダのドメイン内にあるアプリケーション・サーバーへのNATを実行せずに。「分散型モデル」の欠点は、NATのアドレス指定を集中管理と集中管理の欠如が含まれます。

In addition to the two models described above, a hybrid model is to locate NAT in a dedicated device other than the MNG or the BR. Such a model would be similar to the distributed model if the IP pool supports unique private addressing for the mobile nodes, or it would be similar to the centralized model if it supports overlapped private IP addresses. In any case, the NAT device has to be able to provide the necessary NAT session binding information to an external entity (such as AAA or PCRF), which then needs to be able to correlate those records with the user's session state present at the MNG.

上述した2つのモデルに加えて、ハイブリッドモデルは、MNG又はBR以外の専用装置でNATを配置することです。 IPプールは、モバイルノードのためのアドレッシング固有の秘密サポートしている場合、このようなモデルは、分散モデルと同様である、またはそれが重複プライベートIPアドレスをサポートしている場合には、集中型モデルと同様です。いずれの場合においても、NATデバイスは、MNGで存在するユーザのセッション状態にこれらのレコードを相関させることができる必要がある（例えば、AAAまたはPCRFのような）外部のエンティティに必要なNATセッションバインディング情報を提供することができなければなりません。

The foregoing discussion can be summarized as follows. First, the management of the available private IPv4 pool has become important given the increase in Mobile Internet users. Mechanisms that enable reuse of the available pool are required. Second, in the context of private IPv4 pool management, the placement of NAT functionality has implications to the network deployment and operations. The centralized models with a common NAT have the advantages of continuing their legacy deployments and the reuse of private IPv4 addressing. However, they need additional functions to enable traffic differentiation and NAT state correlation with subscriber state management at the MNG. The distributed models also achieve private IPv4 address reuse and avoid overlapping private IPv4 traffic in the operator's core, but without the need for additional mechanisms. Since the MNG performs (unique) IPv4 address assignment and has standard interfaces to AAA and PCRF, the distributed model also enables a single point for subscriber and NAT state reporting as well as policy application. In summary, providers interested in readily integrating NAT with other subscriber management functions, as well as conserving and reusing their private IPv4 pool, may find the distributed model compelling. On the other hand, those providers interested in common management of NAT may find the centralized model more compelling.

次のように前述の議論をまとめることができます。まず、利用可能プライベートIPv4プールの管理は、モバイルインターネットユーザーの増加与えられた重要になってきました。利用可能なプールの再利用を可能にするメカニズムが必要とされています。第二に、プライベートIPv4プール管理の文脈では、NAT機能の配置は、ネットワークの展開と運用への影響があります。一般的なNATを備えた集中モデルは、そのレガシー展開とアドレッシングプライベートIPv4の再利用を継続する利点を有しています。しかし、彼らは、トラフィックの差別化とMNGの加入者の状態管理とNAT状態相関を有効にするには、追加機能を必要とします。分散モデルは、プライベートIPv4アドレスの再利用を実現し、事業者のコアではなく、追加メカニズムを必要とせずにプライベートIPv4トラフィックの重複を避けます。 MNGは（ユニーク）のIPv4アドレスの割り当てを行い、AAAとPCRFに標準インターフェースを有しているので、分散モデルは、加入者と報告NAT状態ならびにポリシーの適用のための単一のポイントを可能にします。要約すると、容易に他の加入者管理機能とNATを統合するだけでなく、彼らのプライベートIPv4プールの節約と再利用に興味のプロバイダは、分散型モデルは魅力的かもしれません。一方、NATの一般的な管理に興味のある人のプロバイダは、集中型モデルは、より説得力のあるかもしれません。

3.3. IPv6-Only Deployment Considerations

3.3. IPv6のみの展開に関する考慮事項

As we observed in the previous section, the presence of NAT functionality in the network brings up multiple issues that would otherwise be absent. NAT should be viewed as an interim solution until IPv6 is widely available, i.e., IPv6 is available for mobile users for all (or most) practical purposes. Whereas NATs at provider premises may slow down the exhaustion of public IPv4 addresses, expeditious and simultaneous introduction of IPv6 in the operational networks is necessary to keep the Internet "going and growing". Towards this goal, it is important to understand the considerations in deploying IPv6-only networks.

私たちは前のセクションで観察されたように、ネットワーク内のNAT機能の存在は、それ以外の場合は不在となり、複数の問題が表示されます。 IPv6は即ち、IPv6は、モバイルすべてに対するユーザー（またはほとんど）の実用的な目的のために利用可能であり、広く利用可能になるまで、NATは、暫定的な解決策として見なされるべきです。一方で、プロバイダ構内でのNATは運用ネットワークでのIPv6の迅速かつ同時の導入は、「行って、成長している」インターネットを保つ必要がある、パブリックIPv4アドレスの枯渇が遅くなる場合があります。この目標に向かって、IPv6のみのネットワークを展開して考慮事項を理解することが重要です。

There are three dimensions to IPv6-only deployments: the network itself, the mobile nodes, and the applications, represented by the 3-tuple {nw, mn, ap}. The goal is to reach the coordinate {IPv6, IPv6, IPv6} from {IPv4, IPv4, IPv4}. However, there are multiple paths to arrive at this goal. The classic dual-stack model would traverse the coordinate {IPv4v6, IPv4v6, IPv4v6}, where each dimension supports co-existence of IPv4 and IPv6. This appears to be the path of least disruption, although we are faced with the implications of supporting large-scale NAT in the network. There is also the cost of supporting separate PDP contexts in the existing 3G UMTS networks. The other intermediate coordinate of interest is {IPv6, IPv6, IPv4}, where the network and the MN are IPv6-only, and the Internet applications are recognized to be predominantly IPv4. This transition path would, ironically, require interworking between IPv6 and IPv4 in order for the IPv6-only MNs to be able to access IPv4 services and applications on the Internet. In other words, in order to disengage NAT (for IPv4-IPv4), we need to introduce another form of NAT (i.e., IPv6-IPv4) to expedite the adoption of IPv6.

ネットワーク自体は、モバイルノード、及びアプリケーション、3タプル{NW、MN、AP}によって表される：展開IPv6専用の三次元があります。目標は{たIPv4、IPv4のはIPv4}から{たIPv6、IPv6の、IPv6を}座標に到達することです。しかし、この目標に到達する複数の経路があります。古典的なデュアルスタックモデルは、各次元は、IPv4とIPv6の共存をサポート{IPv4v6、IPv4v6、IPv4v6を}、座標横切ることになります。私たちは、ネットワーク内の大規模NATをサポートしている場合の影響に直面しているが、これは、少なくとも混乱のパスに表示されます。既存の3G UMTSネットワーク内の別のPDPコンテキストをサポートするコストもあります。関心の座標他の中間ネットワーク及びMNがIPv6のみであり、インターネットアプリケーションは、主にはIPv4であることが認識されている{たIPv6、IPv6の、IPv4の}、です。この移行パスは、皮肉にも、IPv6のみのMNは、インターネット上でのIPv4サービスやアプリケーションにアクセスできるようにするためには、IPv6とIPv4の間のインターワーキングを必要とします。換言すれば、（IPv4の-IPv4の）NATを解放するために、我々は、IPv6の導入を促進するためにNAT（即ち、IPv6をIPv4）の別の形態を導入する必要があります。

It is interesting to consider the preceeding discussion surrounding the placement of NAT for IPv6-IPv4 interworking. There is no overlapping private IPv4 address problem because each IPv6 address is unique and there are plenty of them available. Hence, there is also no requirement for (IPv6) address reuse, which means no protocol is necessary in the centralized model to disambiguate NAT sessions. However, there is an additional requirement of DNS64 [RFC6147] functionality for IPv6-IPv4 translation. This DNS64 functionality must ensure that the synthesized AAAA record correctly maps to the IPv6-IPv4 translator.

IPv6-IPv4のインターワーキングのためのNATの配置を囲む先行の議論を検討することは興味深いです。各IPv6アドレスが固有で利用できるそれらの多くがあるので、重複プライベートIPv4アドレスの問題はありません。したがって、また、何らのプロトコルは、NATセッションを明確にするために集中型モデルに必要でないことを意味する（IPv6）のアドレスの再利用のための必要はありません。ただし、IPv6-IPv4の変換のためDNS64 [RFC6147]機能の追加の要件があります。このDNS64機能は、合成されたAAAAレコードが正しくのIPv6-IPv4トランスレータにマップすることを確認する必要があります。

IPv6-only deployments in mobile networks need to reckon with the following considerations. First, both the network and the MNs need to be IPv6 capable. Expedited network upgrades as well as rollout of MNs with IPv6 would greatly facilitate this. Fortunately, the 3GPP network design for LTE already requires the network nodes and the mobile nodes to support IPv6. Even though there are no requirements for the transport network to be IPv6, an operational IPv6 connectivity service can be deployed with appropriate existing tunneling mechanisms in the IPv4-only transport network. Hence, a service provider may choose to enforce IPv6-only PDN and address assignment for their own subscribers in their Home Networks (see Figure 1). This is feasible for the newer MNs when the mobile network is able to provide IPv6-only PDN support and IPv6-IPv4 interworking for Internet access. For the existing MNs, however, the provider still needs to be able to support IPv4-only PDP/PDN connectivity.

モバイルネットワークにおけるIPv6のみの展開では、次の点を考慮して数える必要があります。まず、ネットワークとのMNの両方をIPv6対応にする必要があります。 IPv6でのMNの迅速なネットワークのアップグレードだけでなく、展開が大幅にこれを容易にするでしょう。幸いなことに、LTE用の3GPPネットワークの設計は、すでにIPv6をサポートするために、ネットワークノードおよびモバイルノードが必要です。 IPv6のすべきトランスポートネットワークのための要件が存在しないにもかかわらず、動作IPv6接続サービスは、IPv4専用トランスポートネットワーク内の適切な既存のトンネリング機構を配備することができます。そのため、サービスプロバイダは、彼らのホームネットワーク（図1を参照）で、自分の加入者のためのIPv6のみのPDNとアドレスの割り当てを強制することもできます。モバイルネットワークは、インターネットアクセスのためのIPv6のみのPDNのサポートとIPv6-IPv4のインターワーキングを提供することができるとき、これは新しいのMNのために実現可能です。既存のMNのために、しかし、プロバイダは依然としてIPv4のみPDP / PDN接続をサポートすることができる必要があります。

Migration of applications to IPv6 in MNs with IPv6-only PDN connectivity brings challenges. The applications and services offered by the provider obviously need to be IPv6-capable. However, an MN may host other applications, which also need to be IPv6-capable in IPv6-only deployments. This can be a "long-tail" phenomenon; however, when a few prominent applications start offering IPv6, there can be a strong incentive to provide application-layer (e.g., socket interface) upgrades to IPv6. Also, some IPv4-only applications may be able to make use of alternative access such as WiFi when available. A related challenge in the migration of applications is the use of IPv4 literals in application layer protocols (such as XMPP) or content (as in HTML or XML). Some Internet applications expect their clients to supply IPv4 addresses as literals, and this will not be possible with IPv6-only deployments. Some of these experiences and the related considerations in deploying an IPv6-only network are documented in [ARKKO-V6]. In summary, migration of applications to IPv6 needs to be done, and such a migration is not expected to be uniform across all subsets of existing applications.

IPv6のみのPDN接続とのMNにおけるIPv6へのアプリケーションの移行が課題をもたらします。プロバイダが提供するアプリケーションやサービスは明らかにIPv6に対応する必要があります。しかし、MNはまた、IPv6のみの展開でIPv6に対応する必要があり、他のアプリケーションを、ホストすることができます。これは、「ロングテール」現象であることができます。いくつかの著名なアプリケーションがIPv6を提供開始したときただし、アプリケーション層（例えば、ソケット・インタフェース）を提供する強い動機が存在することができるIPv6へのアップグレード。また、一部のIPv4のみのアプリケーションが利用可能な場合、このような無線LANなどの代替アクセスを利用することができる可能性があります。アプリケーションの移行に関連する課題は、アプリケーション層（例えば、XMPPなど）プロトコルまたは（HTMLまたはXMLのような）コンテンツ内のIPv4リテラルを使用することです。一部のインターネットアプリケーションでは、顧客がリテラルとしてIPv4アドレスを供給することを期待し、これは、IPv6のみの展開では不可能だろう。 IPv6のみのネットワークを展開し、これらの経験と関連する検討事項の一部は、[ARKKO-V6]に記載されています。要約すると、IPv6へのアプリケーションの移行を行う必要があり、そのような移行は、既存のアプリケーションのすべての部分集合にわたって均一であることが期待されていません。

Voice over LTE (VoLTE) also brings some unique challenges. The signaling for voice is generally expected to be available for free while the actual voice call itself is typically charged on its duration. Such a separation of signaling and the payload is unique to voice, whereas an Internet connection is accounted without specifically considering application signaling and payload traffic. This model is expected to be supported even during roaming. Furthermore, providers and users generally require voice service regardless of roaming, whereas Internet usage is subject to subscriber preferences and roaming agreements. This requirement to ubiquitously support voice service while providing the flexibility for Internet usage exacerbates the addressing problem and may hasten provisioning of VoLTE using the IPv6-only PDN.

LTE（VoLTEの）ボイスオーバーはまた、いくつかのユニークな課題をもたらします。音声のためのシグナリングは、一般的に、実際の音声通話自体は、典型的には、その期間に充電されている間、無料で利用できることが期待されます。インターネット接続は、特にアプリケーションシグナリング及びペイロードトラフィックを考慮せずに説明される一方で、シグナリングおよびペイロードのような分離は、音声に固有のものです。このモデルは、ローミング中であってもサポートされる予定です。インターネットの利用が加入者の好みとローミング契約の対象であるのに対し、さらに、プロバイダとユーザは、一般的に、かかわらず、ローミングの音声サービスを必要とします。インターネット利用のための柔軟性を提供しながら、普遍的に音声サービスをサポートするために、この要件は、アドレス指定の問題を悪化させるとIPv6のみのPDNを使用してVoLTEののプロビジョニングを早めることがあります。

As seen earlier, roaming is unique to mobile networks, and it introduces new challenges. Service providers can control their own network design but not their peers' networks, which they rely on for roaming. Users expect uniformity in experience even when they are roaming. This imposes a constraint on providers interested in IPv6-only deployments to also support IPv4 addressing when their own (outbound) subscribers roam to networks that do not offer IPv6. For instance, when an LTE deployment is IPv6-only, a roamed 3G network may not offer IPv6 PDN connectivity. Since a PDN connection involves the radio base station, the ANG, and the MNG (see Figure 1), it would not be possible to enable IPv6 PDN connectivity without roamed network support. These considerations also apply when the visited network is used for offering services such as VoLTE in the so-called Local Breakout model; the roaming MN's capability as well as the roamed network capability to support VoLTE using IPv6 determine whether fallback to IPv4 would be necessary. Similarly, there are inbound roamers to an IPv6-ready provider network whose MNs are not capable of IPv6. The IPv6-ready provider network has to be able to support IPv4 PDN connectivity for such inbound roamers. There are encouraging signs that the existing deployed network nodes in the 3GPP architecture already provide support for IPv6 PDP context. It would be necessary to scale this support for a (very) large number of mobile users and offer it as a ubiquitous service that can be accounted for.

先に見られるように、ローミングは、モバイルネットワークにユニークであり、それは新たな課題を紹介します。サービスプロバイダは、独自のネットワーク設計ではなく、彼らはローミングに依存している彼らのピアのネットワークを、制御することができます。ユーザーがローミングしても経験の均一性を期待しています。これは、IPv6のみに興味のプロバイダに制約を課しては、自分の（アウトバウンド）加入者がIPv6を提供していないネットワークにローミングするときにもIPv4アドレスをサポートするために、デプロイメント。 LTEの展開がIPv6のみである場合、例えば、ローミング3Gネットワークは、IPv6 PDN接続性を提供しないかもしれません。 PDN接続は、無線基地局、ANG、およびMNGを（図1参照）を含むので、ローミングネットワークサポートなしのIPv6 PDN接続を可能にすることはできません。これらの考慮事項は、また訪問先ネットワークは、いわゆるローカルブレイクアウトモデルにおけるVoLTEのようなサービスを提供するために使用される場合に適用されます。ローミングMNの能力だけでなく、ローミング先のネットワーク機能は、IPv6は、IPv4へのフォールバックが必要であるかどうかを判断使用してVoLTEのをサポートします。同様のMNのIPv6することができないIPv6対応プロバイダーネットワークへのインバウンドローミングがあります。 IPv6対応プロバイダネットワークは、インバウンドローミングのIPv4 PDN接続をサポートすることができなければなりません。 3GPPアーキテクチャでは、既存の展開のネットワーク・ノードが既にIPv6のPDPコンテキストのためのサポートを提供心強い兆候があります。モバイルユーザーの（非常に）多数のために、このサポートを拡張し、説明することができるユビキタスサービスとしてそれを提供することが必要となります。

In summary, IPv6-only deployments should be encouraged alongside the dual-stack model, which is the recommended IETF approach. This is relatively straightforward for an operator's own services and applications, provisioned through an appropriate APN and the corresponding IPv6-only PDP or EPS bearer. Some providers may consider IPv6-only deployment for Internet access as well, and this would require IPv6-IPv4 interworking. When the IPv6-IPv4 translation mechanisms are used in IPv6-only deployments, the protocols and the associated considerations specified in [RFC6146] and [RFC6145] apply. Finally, such IPv6-only deployments can be phased-in for newer mobile nodes, while the existing ones continue to demand IPv4-only connectivity.

要約すると、IPv6のみの展開が推奨IETFアプローチであるデュアルスタックモデル、一緒に奨励されるべきです。これは、適切なAPNと対応するIPv6のみPDPやEPSベアラを通じてプロビジョニング、オペレータの独自のサービスやアプリケーションのための比較的簡単です。一部のプロバイダは、同様にインターネットにアクセスするためのIPv6のみの展開を考慮することができる、これはIPv6にIPv4のインターワーキングを必要とします。 IPv6-IPv4の変換機構がIPv6のみの展開で使用される場合、プロトコル及び[RFC6146]及び[RFC6145]で指定された関連する考慮事項が当てはまります。最後に、IPv6のみの展開では、段階的で使用することができる、新しいモバイルノードのために、既存のIPv4のみの接続を要求し続けながら。

Roaming is important in mobile networks, and roaming introduces diversity in network deployments. Until IPv6 connectivity is available in all mobile networks, IPv6-only mobile network deployments need to be prepared to support IPv4 connectivity (and NAT44) for their own outbound roaming users as well as for inbound roaming users. However, by taking the initiative to introduce IPv6- only for the newer MNs, the mobile networks can significantly reduce the demand for private IPv4 addresses.

ローミングは、モバイルネットワークでは重要であり、ローミングはネットワーク展開の多様性を紹介します。 IPv6接続は、すべてのモバイルネットワークで利用可能になるまで、IPv6のみのモバイルネットワークの展開は、自分の発信ローミングユーザーのためだけでなく、インバウンドローミングユーザーのためのIPv4接続（およびNAT44）をサポートするために準備する必要があります。しかし、唯一の新しいのMNのためのIPv6-を導入するためのイニシアチブを取ることによって、モバイルネットワークが大幅にプライベートIPv4アドレスの需要を減らすことができます。

3.4. Fixed-Mobile Convergence

3.4. 固定モバイルコンバージェンス

Many service providers have both fixed broadband and mobile networks. Access networks are generally disparate, with some common characteristics but with enough differences to make it challenging to achieve "convergence". For instance, roaming is not a consideration in fixed access networks. An All-IP mobile network service provider is required to provide voice service, whereas this is not required for a fixed network provider. A "link" in fixed networks is generally capable of carrying IPv6 and IPv4 traffic, whereas not all mobile networks have "links" (i.e., PDP/PDN connections) capable of supporting IPv6 and IPv4. Indeed, roaming makes this problem worse when a portion of the link (i.e., the Home Network in Figure 1) is capable of supporting IPv6 and the other portion of the link (i.e., the Visited Network in Figure 1) is not. Such architectural differences, as well as policy and business model differences make convergence challenging.

多くのサービスプロバイダーは、固定ブロードバンドとモバイルネットワークの両方を持っています。アクセスネットワークは、いくつかの共通の特性ではなく、「収束」を達成することを難しくするために十分な違いは、一般的に異種のです。例えば、ローミングは、固定アクセスネットワークにおける考慮事項ではありません。これは、固定ネットワークプロバイダに必要とされていないのに対し、オールIPモバイルネットワークサービスプロバイダは、音声サービスを提供するために必要とされます。ないすべてのモバイルネットワークはIPv6とIPv4をサポートすることができる「リンク」（即ち、PDP / PDN接続）を有し、一方、固定ネットワーク内の「リンク」は、IPv6とIPv4トラフィックを運ぶ一般可能です。リンク（図1の、すなわち、ホームネットワーク）の一部は、IPv6をサポートすることが可能であり、リンク（図1の、すなわち、訪問先ネットワーク）の他の部分がない場合に実際にローミングはこの問題を悪化させます。このようなアーキテクチャの違いだけでなく、政策やビジネスモデルの違いは収束が挑戦します。

Nevertheless, within the same provider's space, some common considerations may apply. For instance, IPv4 address management is a common concern for both of the access networks. This implies that the same mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion and introducing IPv6 in operational networks, apply for the converged networks as well. However, the exact solutions deployed for each access network can vary for a variety of reasons, such as:

それにもかかわらず、同じプロバイダの空間内で、いくつかの一般的な考慮事項が適用される場合があります。たとえば、IPv4アドレスの管理は、アクセスネットワークの両方に共通の関心事です。これは、同じメカニズム、すなわち、ならびに統合ネットワークに適用、IPv4アドレスの枯渇を遅らせると運用ネットワークでIPv6を導入し、先に述べたことを意味します。しかしながら、各アクセスネットワークの展開厳密解は、次のような理由により、種々のため変更することができます。

o Tunneling of private IPv4 packets within IPv6 is feasible in fixed networks where the endpoint is often a cable or DSL modem. This is not the case in mobile networks where the endpoint is an MN itself.

O IPv6の内のプライベートIPv4パケットのトンネリングは、エンドポイントは、多くの場合、ケーブルまたはDSLモデムである固定網で実現可能です。これは、エンドポイントがMN自身であるモバイルネットワークではそうではありません。

o Encapsulation-based mechanisms such as 6rd [RFC5969] are useful where the operator is unable to provide native or direct IPv6 connectivity and a residential gateway can become a tunnel endpoint for providing this service. In mobile networks, the operator could provide IPv6 connectivity using the existing mobile network tunneling mechanisms without introducing an additional layer of tunneling.

そのような6rd [RFC5969]としてOカプセル化ベースのメカニズムオペレータは、天然または直接IPv6接続を提供することができず、住宅用ゲートウェイがこのサービスを提供するためのトンネルエンドポイントになることができる場合に有用です。モバイルネットワークでは、オペレータは、トンネルの追加の層を導入することなく、既存のモバイルネットワークトンネリングメカニズムを使用してIPv6接続を提供することができます。

o A mobile network provider may have Application Servers (e.g., an email server) in its network that require unique private IPv4 addresses for MN identification, whereas a fixed network provider may not have such a requirement or the service itself.

モバイルネットワークプロバイダは、固定ネットワークプロバイダは、要求又はサービス自体を有していなくてもよいのに対して、MNの識別のためのユニークなプライベートIPv4アドレスを必要とするアプリケーションサーバ（例えば、電子メールサーバ）のネットワーク内に有していてもよい、O。

These examples illustrate that the actual solutions used in an access network are largely determined by the requirements specific to that access network. Nevertheless, some sharing between an access and core network may be possible depending on the nature of the requirement and the functionality itself. For example, when a fixed network does not require a subscriber-aware feature such as NAT, the functionality may be provided at a core router while the mobile access network continues to provide the NAT functionality at the mobile gateway. If a provider chooses to offer common subscriber management at the MNG for both fixed and wireless networks, the MNG itself becomes a convergence node that needs to support the applicable transition mechanisms for both fixed and wireless access networks.

これらの例は、アクセスネットワークで使用される実際のソリューションは、主にそのアクセスネットワークに特定の要件によって決定されることを示しています。それにもかかわらず、アクセスとコアネットワークとの間のいくつかの共有が必要と機能自体の性質に依存して可能です。モバイルアクセスネットワークは、モバイルゲートウェイでNAT機能を提供し続けている間、例えば、固定ネットワークは、NATのように加入者認識機能を必要としない場合、機能は、コアルータに設けてもよいです。プロバイダは、両方の固定および無線ネットワークのためのMNGで共通の加入者管理を提供することを選択した場合、MNG自体は固定され、無線アクセスネットワークの両方に適用可能な移行メカニズムをサポートする必要が収束ノードとなります。

Different access networks of a provider are more likely to share a common core network. Hence, common solutions can be more easily applied in the core network. For instance, configured tunnels or MPLS VPNs from the gateways from both mobile and fixed networks can be used to carry traffic to the core routers until the entire core network is IPv6-enabled.

プロバイダの異なるアクセスネットワークは、共通のコアネットワークを共有する可能性が高くなります。したがって、一般的な解決策は、より簡単に、コアネットワークに適用することができます。全体のコアネットワークがIPv6対応するまで、例えば、両方のモバイルおよび固定ネットワークのゲートウェイから構成されるトンネル又はMPLS VPNはコアルータにトラフィックを伝送するために使用することができます。

There can also be considerations due to the use of NAT in access networks. Solutions such as Femto Networks rely on a fixed Internet connection being available for the Femto Base Station to communicate with its peer on the mobile network, typically via an IPsec tunnel. When the Femto Base Station needs to use a private IPv4 address, the mobile network access through the Femto Base Station will be subject to NAT policy administration including periodic cleanup and purge of NAT state. Such policies affect the usability of the Femto Network and have implications to the mobile network provider. Using IPv6 for the Femto (or any other access technology) could alleviate some of these concerns if the IPv6 communication could bypass the NAT.

また、アクセスネットワークでNATを使用するための配慮が存在する場合があります。そのようなフェムト・ネットワークのようなソリューションは、フェムト基地局は、典型的には、IPsecトンネルを介して、モバイルネットワーク上のピアと通信するために利用可能である固定のインターネット接続に依存しています。フェムト基地局は、プライベートIPv4アドレスを使用する必要がある場合には、フェムト基地局を介してモバイルネットワークへのアクセスは、NATの状態の定期的な清掃やパージなどのNATポリシー管理の対象となります。このような政策は、フェムト・ネットワークの使いやすさに影響し、モバイルネットワークプロバイダへの影響を持っています。 IPv6通信はNATをバイパスすることができればフェムト（またはその他のアクセス技術）のためにIPv6を使用すると、これらの懸念のいくつかを軽減することができます。

In summary, there is interest in Fixed-Mobile Convergence, at least among some providers. While there are benefits to harmonizing the network as much as possible, there are also idiosyncrasies of disparate access networks that influence the convergence. Perhaps greater harmonization is feasible at the higher service layers, e.g., in terms of offering unified user experience for services and applications. Some harmonization of functions across access networks into the core network may be feasible. A provider's core network appears to be the place where most convergence is feasible.

要約すると、少なくとも一部のプロバイダの間で固定モバイルコンバージェンス、に関心があります。できるだけ多くのネットワークを調和へのメリットがありますが、収束に影響を与える異種のアクセス網の特異性もあります。おそらく、より大きな調和はサービスやアプリケーションのための統一されたユーザー体験を提供するという点で、例えば、上位サービスレイヤで実現可能です。コアネットワークへのアクセスネットワーク全体の機能のいくつかの調和が実現可能です。プロバイダーのコアネットワークは、ほとんどの収束が実現可能である場所であるように思われます。

4. Summary and Conclusion

4.まとめと結論

IPv6 deployment in mobile networks is crucial for the Mobile Internet. In this document, we discussed the considerations in deploying IPv6 in mobile networks. We summarize the discussion in the following: o IPv4 address exhaustion and its implications to mobile networks: As mobile service providers begin to deploy IPv6, conserving their available IPv4 pool implies the need for network address translation in mobile networks. At the same time, providers can make use of the 3GPP architecture constructs such as APN and PDN connectivity to introduce IPv6 without affecting the predominantly IPv4 Internet access. The IETF dual-stack model [RFC4213] can be applied to the mobile networks readily.

モバイルネットワークにおけるIPv6の展開は、モバイルインターネットのために重要です。この文書では、モバイルネットワークでIPv6を導入するに配慮について議論しました。 IPv4アドレスの枯渇やモバイルネットワークへの含意：O：モバイルサービスプロバイダーが利用できるIPv4のプールは、モバイルネットワークのネットワークアドレス変換の必要性を暗示節約、IPv6を展開し始めると私たちは次のように議論をまとめます。同時に、プロバイダは、このようなAPNとPDN接続などの3GPPアーキテクチャの構築物の使用は、主にIPv4インターネットへのアクセスに影響を与えずにIPv6を導入することができます。 IETFデュアルスタックモデル[RFC4213]は、容易にモバイルネットワークに適用することができます。

o The placement of NAT functionality in mobile networks: Both the centralized and distributed models of private IPv4 address pool management have their relative merits. By enabling each MNG to manage its own NET10 pool, the distributed model achieves reuse of the available private IPv4 pool and avoids the problems associated with the non-unique private IPv4 addresses for the MNs without additional protocol mechanisms. The distributed model also augments the "subscriber management" functions at an MNG, such as readily enabling NAT session correlation with the rest of the subscriber session state. On the other hand, existing deployments that have used the centralized IP address management can continue their legacy architecture by placing the NAT at a common node. The centralized model also achieves private IPv4 address reuse but needs additional protocol extensions to differentiate overlapping addresses at the common NAT as well as to integrate with policy and billing infrastructure.

モバイルネットワークでのNAT機能の配置○：プライベートIPv4アドレスプール管理の中央集中と分散モデルの両方がそれらの相対的なメリットがあります。独自NET10プールを管理する各MNGを可能にすることによって、分散モデルは、利用可能なプライベートIPv4プールの再利用を実現し、追加のプロトコルメカニズムなしでのMNのための非固有のプライベートIPv4アドレスに関連する問題を回避します。分散モデルはまた、容易に加入者セッション状態の残りの部分とNATセッション相関を可能にするように、MNGの「加入者管理」機能を増強します。一方、中央集中型のIPアドレスの管理を使用している既存の配備は、共通のノードでNATを配置することによって、彼らのレガシー・アーキテクチャを継続することができます。集中型モデルは、プライベートIPv4アドレスの再利用を実現しますが、共通のNATでの重複アドレスを区別するだけでなく、ポリシーおよび課金インフラストラクチャと統合するために、追加のプロトコル拡張を必要とします。

o IPv6-only mobile network deployments: This deployment model is feasible in the LTE architecture for an operator's own services and applications. The existing MNs still expect IPv4 address assignment. Furthermore, roaming, which is unique to mobile networks, requires that a provider support IPv4 connectivity when its (outbound) users roam into a mobile network that is not IPv6- enabled. Similarly, a provider needs to support IPv4 connectivity for (inbound) users whose MNs are not IPv6-capable. The IPv6-IPv4 interworking is necessary for IPv6-only MNs to access the IPv4 Internet.

IPv6のみのモバイルネットワークの展開○：この展開モデルでは、事業者の独自のサービスやアプリケーションのためのLTEアーキテクチャで実現可能です。既存のMNは、まだIPv4アドレスの割り当てを期待しています。さらに、モバイルネットワークに固有であり、ローミング、プロバイダサポートIPv4接続その（アウトバウンド）ユーザがIPv6-有効化されていないモバイルネットワークにローミングするときに必要となります。同様に、プロバイダは、そのMNのIPv6に対応していない（受信）ユーザのIPv4接続をサポートする必要があります。 IPv6のみのMNがIPv4インターネットにアクセスするためのIPv6-IPv4のインターワーキングが必要です。

o Fixed-Mobile Convergence: The examples discussed illustrate the differences in the requirements of fixed and mobile networks. While some harmonization of functions may be possible across the access networks, the service provider's core network is perhaps better-suited for converged network architecture. Similar gains in convergence are feasible in the service and application layers.

O固定モバイルコンバージェンス：論じた実施例は、固定およびモバイルネットワークの要件の違いを示しています。機能の一部調和は、アクセスネットワークを介して可能であるかもしれないが、サービスプロバイダのコアネットワークは、おそらく統合ネットワークアーキテクチャのためのよりよい最適です。コンバージェンスにおける同様の利益は、サービスとアプリケーション層で実現可能です。

5. Security Considerations

5.セキュリティについての考慮事項

This document does not introduce any new security vulnerabilities.

このドキュメントは、新しいセキュリティの脆弱性を導入しません。

6. Acknowledgements

6.謝辞

This document has benefitted from discussions with and reviews from Cameron Byrne, David Crowe, Hui Deng, Remi Despres, Fredrik Garneij, Jouni Korhonen, Teemu Savolainen, and Dan Wing. Thanks to all of them. Many thanks to Mohamed Boucadair for providing an extensive review of a draft version of this document. Cameron Byrne, Kent Leung, Kathleen Moriarty, and Jari Arkko provided reviews that helped improve this document. Thanks to Nick Heatley for providing valuable review and input on VoLTE.

この文書では、キャメロン・バーン、デビッド・クロウ、ホイ鄧小、レミ・デプレ、フレドリックGarneij、Jouni Korhonen、テームSavolainenの、そしてダン・ウィングからとの協議・レビューの恩恵を受けています。それらのすべてに感謝します。この文書のドラフト版の大規模な見直しを提供するためのモハメド・Boucadairに感謝します。キャメロン・バーン、ケントレオン、キャスリーン・モリアーティ、とヤリArkkoは、このドキュメントを改善する助けたレビューを提供します。 VoLTEの上の貴重なレビューと入力を提供するためのニック・ヒートリーに感謝します。

7. Informative References

7.参考文献

[3GPP.3G] "General Packet Radio Service (GPRS); Service description; Stage 2, 3GPP TS 23.060, December 2006".

[3GPP.3G] "汎用パケット無線サービス（GPRS）;サービスの説明;ステージ2、3GPP TS 23.060、2006年12月"。

[3GPP.4G] "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 8.8.0, December 2009.

[3GPP.4G] "汎用パケット無線サービス（GPRS）発展型ユニバーサル地上無線アクセスネットワーク（E-UTRAN）アクセスのための機能強化"、3GPP TS 23.401 8.8.0、2009年12月。

[3GPP2.EHRPD] "E-UTRAN - eHRPD Connectivity and Interworking: Core Network Aspects", http://www.3gpp2.org/public_html/ Specs/X.S0057-0_v1.0_090406.pdf.

【3GPP2.EHRPD "E-UTRAN - eHRPD接続及びインターワーキング：コアネットワークの態様"、http://www.3gpp2.org/public_html/仕様/ X.S0057-0_v1.0_090406.pdf。

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。

[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.

[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。

[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.

[RFC2890] Dommety、G.、 "GREのキーと一連番号拡大"、RFC 2890、2000年9月。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.

[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。

[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.

[RFC5969] Townsley、W.およびO. Troan、 "IPv4の基盤のIPv6のRapid Deployment（6rd） - プロトコル仕様"、RFC 5969、2010年8月。

[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.

[RFC6145]のLi、X.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年4月。

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

[RFC6146] Bagnulo、M.、マシューズ、P.、およびI.バンBeijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、RFC 6146、2011年4月。

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

[RFC6147] Bagnulo、M.、サリバン、A.、マシューズ、P.、およびI.バンBeijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNS拡張機能"、RFC 6147、2011年4月。

[ARKKO-V6] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", Work in Progress, April 2011.

[ARKKO-V6] Arkko、J.、およびA. Keranen、 "IPv6のみのネットワークからの経験" 進行中、仕事、2011年4月。

[GI-DS-LITE] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway Initiated Dual-Stack Lite Deployment", Work in Progress, July 2011.

[GI-DS-LITE] Brockners、F.、Gundavelli、S.、シュパイヒャー、S.、およびD.区、進歩、2011年7月の作業 "ゲートウェイは、デュアルスタックLiteの展開を開始しました"。

Author's Address

著者のアドレス

Rajeev Koodli Cisco Systems USA

ラジブkudliシスコシステムズ米国

EMail: rkoodli@cisco.com

メールアドレス：rkoodli@cisco.com