[要約] 要約：RFC 6342は、IPv6の展開に関するモバイルネットワークの考慮事項についてのガイドラインです。 目的：このRFCの目的は、モバイルネットワークにおける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
IPv6展開に関するモバイルネットワークの考慮事項
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6342で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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;
o パブリックおよびプライベートIPv4は、モバイルネットワークの展開アーキテクチャへの疲労と影響に対処します。
o Placement of Network Address Translation (NAT) functionality and its implications;
o ネットワークアドレス変換（NAT）の機能とその意味の配置。
o IPv6-only deployment considerations and roaming implications; and
o IPv6のみの展開に関する考慮事項とローミングの意味合い。と
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]で指定された第3世代パートナーシッププロジェクト（3GPP）3Gおよび4Gネットワークアーキテクチャを想定しています。ただし、考慮事項は、他のモバイルネットワークアーキテクチャにも十分に一般的です[3GPP2.EHRPD]。
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
モバイルノード（MN）は、ホームネットワークを介して、またはユーザーがホームネットワークの外でローミングしているときに訪問されたネットワークを介してモバイルネットワークに接続します。3GPPネットワークアーキテクチャでは、MNがモバイルゲートウェイにマップするアクセスポイント名（APN）に接続することにより、ネットワークにアクセスします。大まかに言えば、APNはワイヤレスLANのサービスセット識別子（SSID）に似ています。APNは、MNが権利を与えられるインターネットアクセス、高解像度のビデオストリーミング、コンテンツが豊富なゲームなど、どの種類のサービスを指定するために使用できる論理的概念です。各APNは指定できます
what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN.
その特定のAPNでは、どのタイプのIP接続（つまり、IPv4、IPv6、IPv4v6）が有効になっています。
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 Universal Mobile Telecommunications System（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.
o Access Network Gateway（ANG）：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.
o モバイルネットワークゲートウェイ（MNG）：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 Border Router（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.
o 認証、承認、および会計（AAA）：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.
このドキュメントの残りの部分では、「オペレーター」、「サービスプロバイダー」、「プロバイダー」という用語を互換性があります。
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は、地域のインターネットレジストリ（RIRS）への割り当てのために利用可能な「/8」ブロックを使い果たしました。RIR自体は、ブロックを「使い果たした」か、近い将来にそれらを使い果たすと予測されています。これにより、サービスプロバイダー間の意識が高まり、インターネットの運用を維持するためのテクノロジーの導入を検討しました。プロバイダーの場合、ランアウトの問題に対処するための2つの同時アプローチがあります。IPv4アドレスプールの疲労を遅らせる（つまり、既存のプールの保存）と運用ネットワークにIPv6を導入することです。以下の両方で検討します。
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（つまり、パブリックIPv6からパブリックIPv4への翻訳、逆）などの翻訳ベースのメカニズムに焦点を当てています。これは、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
モバイルネットワークでは、MNのIPv4アドレスの割り当てがMNGによって実行されます。3GPPネットワークアーキテクチャでは、この割り当ては、パケットデータネットワーク（PDN）接続の確立に関連して実行されます。PDN接続は、MNからMNGへのエンドエンドリンク（つまり、4G LTEのEPSベアラーまたは3G UMTのPDPコンテキスト）を意味します。各MNに対して、いつでも1つ以上のPDN接続がアクティブになる可能性があります。PDN接続は、4G LTEネットワークのデュアルスタックPDNのように）IPv4とIPv6トラフィックの両方をサポートするか、2つのトラフィックタイプのいずれか（既存の3G UMTSネットワークのように）のみをサポートする場合があります。IPv4アドレスは、PDN接続の確立時に割り当てられているか、PDN接続が確立された後にDHCPを使用して割り当てられます。パブリックIPv4アドレスの消耗を遅らせるために、このIPアドレスは共有されたパブリックIPv4に変換されるプライベートIPv4アドレスである必要があります
address. Hence, there is a need for a private-public IPv4 translation mechanism in the mobile network.
住所。したがって、モバイルネットワークでプライベート公立の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ネットワークでは、All-IPネットワークでモバイルユーザーに確実にリーチするために、常にオンになっているPDN接続の要件があります。この要件は、回路ベースのインフラストラクチャを持たないLTEでの音声オーバーIPサービスをサポートする必要があるためです。このPDN接続がIPv4アドレス指定を使用する場合、ネットワークに接続するすべてのMNにプライベートIPv4アドレスが必要です。これは、プライベートIPv4アドレスの可用性と使用に大きく影響する可能性があります。これに対処する1つの方法は、常にオンのPDN（音声サービスが必要）をIPv6にすることです。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コンテキストをめったに放棄することはめったにないにもかかわらず、常時接続の要件はありません。既存のいわゆるPre-Release-8展開は、デュアルスタックPDP接続をサポートしていません。したがって、IPv4とIPv6のトラフィックをサポートするには、2つの個別のPDP接続が必要です。一部のMN、特にスマートフォンは今日使用されている場合でも、IPv6スタックがある場合がありますが、残りの2つの考慮事項があります。まず、これらの既存のスタックを使用した運用エクスペリエンスとコンプライアンステストはほとんどありません。したがって、大規模な展開での使用は、そのようなホストのIPv6に基づいてサービスを提供することを阻害するソフトウェアエラーと相互運用性の問題を明らかにする可能性があると予想されます。第二に、使用中の現在の携帯電話のほんの一部のみがそのようなスタックを持っています。その結果、プロバイダーは新しい携帯電話を導入する際にIPv6をテスト、展開、および運用する必要があります。これは、主にIPv4インターネットへのアクセスも必要です。
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
先行段落からの考慮事項は、次の観察につながります。まず、モバイルネットワークでのプライベートIPv4アドレス指定をサポートする必要性が増えています。
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翻訳が必要です。第二に、PDPコンテキストとPDN接続の形ですでに3Gおよび4G LTEネットワークの両方でIPv6のサポートがあります。そもそも、オペレーターは独自のアプリケーションとサービスのためにIPv6を導入できます。言い換えれば、デュアルスタックIPv6およびIPv4ネットワークのIETFの推奨モデルは、異なるAPNSをサポートし、PDP/PDN接続でIPv6トラフィックを運ぶ機能を備えたモバイルネットワークに容易に適用できます。IETFデュアルスタックモデルは、リリース-8以降の単一のIPv4v6 PDN接続を使用して適用できますが、以前のリリースでは個別のPDPコンテキストが必要です。最後に、オペレーターは、IPv46PDNまたはIPv6 PDNのいずれかを使用して、常に常にオンモバイル接続のデフォルトになり、必要に応じてIPv4 PDNを使用できます。
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.
前のセクションでは、利用可能なプールを節約し、パブリックIPv4アドレスの疲労を遅らせるために、NAT44機能が必要であることを観察しました。ただし、利用可能なプライベート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
上記の開発に加えて、NATの配置は他の理由でも重要です。通常、アクセスネットワークは、請求および会計のためにネットワークおよびサービスの使用記録を作成する必要があります。これは、「サブスクライバー管理」機能（QoS、ポリシー、請求および会計）がかなり詳細にできるモバイルネットワークにも当てはまります。NATは2つのアドレス間にバインディングを導入するため、バインディング自体が加入者管理に必要な情報になります。たとえば、プライベートIPv4アドレスと（共有）パブリックIPv4アドレスで提供されるQoSは、会計目的で相関する必要がある場合があります。別の例として、プロバイダーネットワーク内のアプリケーションサーバーは、PCRFが提供するポリシーに基づいてトラフィックを処理する必要がある場合があります。これらのアプリケーションサーバーで見られるIPアドレスが一意ではない場合、PCRFは個々のMNの間で非微分をするためにNATバインディングを検査できる必要があります。サブスクライバーセッション管理情報とサービスの使用情報も、調和したレコードを作成するために相関する必要があります。さらに、NATバインディングレコードを保存するための法的要件がある場合があります。確かに、これらの問題はで消えます
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.
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などの共通ノードによって管理され、複数のMNGが共有するプールがすべて同じBRに接続されている「集中モデル」を使用します。このモデルは、3G以前の展開でうまく機能しています。このモバイルインターネットにアクセスするサブスクライバーの数は、利用可能なアドレスプールを超えていません。ただし、3Gネットワークの出現と、モバイルインターネット上のユーザー数のその後の劇的な成長により、サービスプロバイダーは既存のネットワーク設計と選択を検討することをますます強制されています。具体的には、プロバイダーは、スケーラブルなNATソリューションだけでなく、プライベートIPv4プールの疲労に対処することを余儀なくされています。
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アドレスをサポートする必要があります。言い換えれば、2つ以上のMN（同じMNGに接続される可能性がある）で使用されるIPアドレスは、集中化されたNATでオーバーラップする可能性が非常に高いため、トラフィックを区別できる必要があります。ジェネリックルーティングカプセル化（GRE）[RFC2784] [RFC2890]、MPLS [RFC3031] VPNトンネル、またはIP-in-IPカプセル化[RFC2003]などのトンネルメカニズムは、NATセッションにユニークな識別子を提供することができます。[GI-DS-Lite]で説明されているように、プライベートIPv4トラフィックの重複。NATを集中化し、重複するプライベートIPv4アドレス指定を使用するという利点は、限られたプライベートIPv4プールを保存することです。また、オペレーターのエンタープライズネットワークがMNGからBRにIPv6を使用できるようになります。これ（つまり、IPv6-Routed Enterprise Networkの必要性）は、一部のプロバイダーによる追加要件と見なされる場合があります。欠点には、NAT状態（共通ノードで）をサブスクライバーセッション情報（ゲートウェイのそれぞれ）と相関させるための追加のプロトコルの必要性、最適ではないMN-MN通信、サブスクライバーAware 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
分散モデルでは、Private IPv4アドレス管理はMNGによって実行され、NAT機能も実行されます。このモデルでは、各MNGには1670万の一意のアドレスのブロックがあり、各MNGでアクティブなモバイルサブスクライバーの数と比較して十分です。NAT機能をネットワークの端に分配することにより、各MNGは利用可能な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が重複する問題を回避します。さらに、MNGはサブスクライバー管理機能が位置する場所であるため、NAT状態の相関が容易に有効になります。さらに、MNGには、AAAやPCRFなどの関数への既存のインターフェイスが既にあり、一意のプライベートIPv4アドレスを使用してサブスクライバー管理関数を実行できます。最後に、MNGは、サービスプロバイダーのドメイン内にあるアプリケーションサーバーにNATを実行せずに特定のトラフィックタイプをパススルーすることもできます。これにより、サーバーは一意のプライベートIPv4アドレスを持つサブスクライバーセッションを識別できます。「分散モデル」の欠点には、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デバイスは、必要なNATセッションバインディング情報を外部エンティティ（AAAやPCRFなど）に提供できる必要があります。。
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の共通管理に関心のあるプロバイダーは、集中モデルがより説得力があると感じるかもしれません。
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機能の存在は、それ以外の場合は存在しない複数の問題をもたらします。NATは、IPv6が広く利用可能になるまで暫定ソリューションと見なす必要があります。つまり、IPv6はすべての（またはほとんどの）実用的な目的でモバイルユーザーが利用できます。プロバイダーの施設のNATは、パブリックIPv4アドレスの消耗を遅くする可能性がありますが、インターネットを「進み、成長させる」ためには、運用ネットワークでのIPv6の迅速かつ同時に同時に導入される可能性があります。この目標に向けて、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.
IPv6のみの展開には3つのディメンションがあります。ネットワーク自体、モバイルノード、および3タプル{NW、MN、AP}で表されるアプリケーションです。目標は、{IPv4、IPv4、IPv4}からCoordinate {IPv6、IPv6、IPv6}に到達することです。ただし、この目標に到達するための複数のパスがあります。古典的なデュアルスタックモデルは、座標{IPv4v6、IPv4v6、IPv4v6}を通過し、各寸法はIPv4とIPv6の共存をサポートします。これは、ネットワークで大規模なNATをサポートすることの意味に直面していますが、これは最も混乱の少ない道であるように見えます。既存の3G UMTSネットワークで個別のPDPコンテキストをサポートするコストもあります。対象のもう1つの中間座標は{IPv6、IPv6、IPv4}であり、ネットワークとMNはIPv6のみであり、インターネットアプリケーションは主にIPv4であると認識されています。皮肉なことに、この移行パスは、IPv6のみのMNSがインターネット上のIPv4サービスとアプリケーションにアクセスできるようにするために、IPv6とIPv4の間のインターワーキングが必要です。言い換えれば、NAT（IPv4-IPV4の場合）を外すには、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アドレスの問題はありません。したがって、（IPv6）アドレスの再利用の要件もありません。つまり、集中モデルではNATセッションを乱用するためにプロトコルは必要ありません。ただし、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
モバイルネットワークでのIPv6のみの展開は、以下の考慮事項を考慮する必要があります。まず、ネットワークとMNSの両方がIPv6対応である必要があります。IPv6を使用したMNSのロールアウトと同様に、迅速なネットワークのアップグレードがこれを大幅に促進します。幸いなことに、LTEの3GPPネットワーク設計には、ネットワークノードと
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をサポートするモバイルノード。トランスポートネットワークがIPv6になるための要件はありませんが、IPv4のみのトランスポートネットワークに適切な既存のトンネリングメカニズムを使用して、運用上のIPv6接続サービスを展開できます。したがって、サービスプロバイダーは、IPv6のみのPDNを実施し、ホームネットワーク内の独自のサブスクライバーの割り当てに対処することを選択できます（図1を参照）。これは、モバイルネットワークがIPv6のみのPDNサポートとインターネットアクセスのためにIPv6-IPV4インターワーキングを提供できる場合に、新しいMNSにとって可能です。ただし、既存のMNSの場合、プロバイダーは依然として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接続を伴うMNSでのIPv6へのアプリケーションの移行は、課題をもたらします。プロバイダーが提供するアプリケーションとサービスは、明らかにIPv6対応である必要があります。ただし、MNは他のアプリケーションをホストする場合があります。これは、IPv6のみの展開でもIPv6対応である必要があります。これは「ロングテール」現象になる可能性があります。ただし、いくつかの顕著なアプリケーションがIPv6の提供を開始すると、アプリケーションレイヤー（ソケットインターフェイスなど）をIPv6にアップグレードするための強力なインセンティブがある可能性があります。また、一部のIPv4のみのアプリケーションは、利用可能な場合はWiFiなどの代替アクセスを使用できる場合があります。アプリケーションの移行に関連する課題は、アプリケーションレイヤープロトコル（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.
Voice over 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のサブスクライバーがIPv6を提供しないネットワークにRoamをローミングする場合のIPv4アドレス指定もサポートします。たとえば、LTE展開がIPv6のみである場合、Roeam 3GネットワークはIPv6 PDN接続を提供しない場合があります。PDN接続には無線ベースステーション、ANG、およびMNGが含まれるため（図1を参照）、ネットワークサポートをノーミングせずにIPv6 PDN接続を有効にすることはできません。これらの考慮事項は、いわゆるローカルブレイクアウトモデルでVolteなどのサービスを提供するために訪問されたネットワークを使用する場合にも適用されます。Roaming MNの機能と、IPv6を使用してVoLTEをサポートするROAMEDネットワーク機能は、IPv4へのフォールバックが必要かどうかを判断します。同様に、IPv6対応プロバイダーネットワークには、MNSが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）をサポートし、独自のアウトバウンドローミングユーザーとインバウンドローミングユーザーのために。ただし、IPv6-を新しいMNSのみに導入するイニシアチブを採用することにより、モバイルネットワークはプライベートIPv4アドレスの需要を大幅に削減できます。
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.
多くのサービスプロバイダーには、固定ブロードバンドネットワークとモバイルネットワークの両方があります。アクセスネットワークは一般に異なるものであり、いくつかの一般的な特性がありますが、「収束」を達成するのに挑戦するのに十分な違いがあります。たとえば、ローミングは固定アクセスネットワークでは考慮されません。ボイスサービスを提供するには、All-IPモバイルネットワークサービスプロバイダーが必要ですが、これは固定ネットワークプロバイダーには必要ありません。固定ネットワークの「リンク」は一般にIPv6およびIPv4トラフィックを運ぶことができますが、すべてのモバイルネットワークがIPv6およびIPv4をサポートできる「リンク」（つまり、PDP/PDN接続）を持っているわけではありません。実際、ローミングは、リンクの一部（図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.
o 6番目[RFC5969]などのカプセル化ベースのメカニズムは、オペレーターがネイティブまたはダイレクト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.
o モバイルネットワークプロバイダーには、MN識別用の一意のプライベートIPv4アドレスを必要とするネットワークにアプリケーションサーバー（電子メールサーバーなど）がありますが、固定ネットワークプロバイダーにはそのような要件またはサービス自体がない場合があります。
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.
プロバイダーのさまざまなアクセスネットワークは、共通コアネットワークを共有する可能性が高くなります。したがって、コアネットワークで一般的なソリューションをより簡単に適用できます。たとえば、モバイルネットワークと固定ネットワークの両方からゲートウェイから構成されたトンネルまたはMPLS VPNを使用して、コアネットワーク全体がIPv6対応になるまでトラフィックをコアルーターに運ぶことができます。
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の使用により、考慮事項があります。FEMTOネットワークなどのソリューションは、通常、IPSECトンネルを介して、モバイルネットワーク上のピアと通信するために、FEMTOベースステーションが利用できる固定インターネット接続に依存しています。FEMTOベースステーションがプライベートIPv4アドレスを使用する必要がある場合、FEMTOベースステーションを介したモバイルネットワークアクセスは、定期的なクリーンアップやNAT状態のパージなど、NAT政策管理の対象となります。このようなポリシーは、FEMTOネットワークの使いやすさに影響し、モバイルネットワークプロバイダーに影響を与えます。FEMTO（またはその他のアクセステクノロジー）にIPv6を使用すると、IPV6通信がNATをバイパスできる場合、これらの懸念の一部を軽減できます。
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.
要約すると、少なくとも一部のプロバイダーの間では、固定モバイルの収束に関心があります。ネットワークを可能な限り調和させることには利点がありますが、収束に影響を与える異なるアクセスネットワークの特異性もあります。おそらく、より高いサービスレイヤー、たとえば、サービスとアプリケーションに統一されたユーザーエクスペリエンスを提供するという点で、より大きな調和が実現可能です。コアネットワークへのアクセスネットワーク全体の関数のいくつかの調和が実現可能です。プロバイダーのコアネットワークは、ほとんどの収束が実行可能な場所のようです。
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:
モバイルネットワークでのIPv6の展開は、モバイルインターネットにとって重要です。このドキュメントでは、モバイルネットワークにIPv6を展開する際の考慮事項について説明しました。以下の議論を要約します。
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.
o IPv4アドレスの使い果たしとモバイルネットワークへの影響：モバイルサービスプロバイダーがIPv6の展開を開始すると、利用可能なIPv4プールを保存することは、モバイルネットワークでのネットワークアドレス変換の必要性を意味します。同時に、プロバイダーは、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.
o モバイルネットワークにおけるNAT機能の配置：プライベートIPv4アドレスプール管理の集中および分散モデルの両方に相対的なメリットがあります。各MNGが独自のNet10プールを管理できるようにすることにより、分散モデルは利用可能なプライベートIPv4プールの再利用を実現し、追加のプロトコルメカニズムなしにMNSの非ユニークなプライベートIPv4アドレスに関連する問題を回避します。分散モデルは、MNGでの「サブスクライバー管理」関数を強化します。たとえば、サブスクライバーセッション状態の残りの部分とNATセッションの相関を容易に可能にします。一方、集中化された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.
o IPv6のみのモバイルネットワーク展開：この展開モデルは、オペレーター自身のサービスとアプリケーションのLTEアーキテクチャで実行可能です。既存のMNSは、IPv4アドレスの割り当てを引き続き期待しています。さらに、モバイルネットワークに固有のローミングでは、（アウトバウンド）ユーザーがIPv6-を有効にしていないモバイルネットワークにローミングするときに、プロバイダーがIPv4接続をサポートする必要があります。同様に、プロバイダーは、MNSがIPv6対応ではない（インバウンド）ユーザーのIPv4接続をサポートする必要があります。IPv6-IPV4インターワーキングは、IPv6のみのMNSが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 固定モバイルの収束：説明した例は、固定ネットワークとモバイルネットワークの要件の違いを示しています。アクセスネットワーク全体で機能のいくつかの調和が可能になる場合がありますが、サービスプロバイダーのコアネットワークは、おそらく収束したネットワークアーキテクチャに適している可能性があります。収束の同様の利益は、サービスレイヤーとアプリケーション層で実行可能です。
This document does not introduce any new security vulnerabilities.
このドキュメントでは、新しいセキュリティの脆弱性は導入されません。
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.
この文書は、キャメロン・バーン、デビッド・クロウ、フイ・デン、レミ・デスプレス、フレドリック・ガルニージ、ジュニア・コルホネン、ティーム・サヴォラーネン、ダン・ウィングとの議論とレビューの恩恵を受けています。それらすべてに感謝します。このドキュメントのドラフトバージョンの広範なレビューを提供してくれたMohamed Boucadairに感謝します。Cameron Byrne、Kent Leung、Kathleen Moriarty、Jari Arkkoは、この文書の改善に役立つレビューを提供しました。Volteに関する貴重なレビューと入力を提供してくれたNick Heatleyに感謝します。
[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]「進化した普遍的な陸生ラジオアクセスネットワーク（E-UTRAN）アクセスのための一般的なパケットラジオサービス（GPRS）強化」、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/ specs/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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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。、「Key and Sequence Number GREへの拡張」、RFC 2890、2000年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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. Gilligan、「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、「IPv6インフラストラクチャのIPv6迅速な展開（6rd） - プロトコル仕様」、RFC 5969、2010年8月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「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.、Matthews、P。、およびI. Van Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、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.、Sullivan、A.、Matthews、P。、およびI. Van Beijnum、 "DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換の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.、Speicher、S.、およびD. Ward、「Gatewayはデュアルスタックのライト展開を開始しました」、2011年7月の進行中。
Author's Address
著者の連絡先
Rajeev Koodli Cisco Systems USA
Rajeev Koodli Cisco Systems USA
EMail: rkoodli@cisco.com