[要約] 要約：RFC 4215は、第3世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6移行の分析を提供しています。 目的：このRFCの目的は、3GPPネットワークにおけるIPv6移行の課題と解決策を特定し、ネットワークの進化と将来の展望を支援することです。
Network Working Group J. Wiljakka, Ed.
Request for Comments: 4215 Nokia
Category: Informational October 2005
Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
第三世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6トランジションに関する分析
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
このドキュメントは、第3世代パートナーシッププロジェクト（3GPP）パケットネットワークでのIPv6への移行を分析します。これらのネットワークは、一般的なパケットラジオサービス（GPRS）テクノロジーに基づいており、ラジオネットワークアーキテクチャは、モバイルコミュニケーション（GSM）またはユニバーサルモバイルテレコミュニケーションシステム（UMTS）/ワイドバンドコードディビジョン多重アクセス（WCDMA）テクノロジーのグローバルシステムに基づいています。
The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.
焦点は、さまざまな遷移シナリオと適用可能な移行メカニズムの分析と、これらの遷移シナリオのソリューションを見つけることです。これらのシナリオでは、ユーザー機器（UE）が他のノードに接続します。たとえば、インターネットでは、IPv6/IPv4遷移メカニズムが必要です。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Scope of This Document .....................................3
1.2. Abbreviations ..............................................3
1.3. Terminology ................................................5
2. Transition Mechanisms and DNS Guidelines ........................5
2.1. Dual Stack .................................................5
2.2. Tunneling ..................................................6
2.3. Protocol Translators .......................................6
2.4. DNS Guidelines for IPv4/IPv6 Transition ....................6
3. GPRS Transition Scenarios .......................................7
3.1. Dual Stack UE Connecting to IPv4 and IPv6 Nodes ............7
3.2. IPv6 UE Connecting to an IPv6 Node through an IPv4
Network ....................................................8
3.2.1. Tunneling Inside the 3GPP Operator's Network ........9
3.2.2. Tunneling Outside the 3GPP Operator's Network ......10
3.3. IPv4 UE Connecting to an IPv4 Node through an IPv6
Network ...................................................10
3.4. IPv6 UE Connecting to an IPv4 Node ........................11
3.5. IPv4 UE Connecting to an IPv6 Node ........................12
4. IMS Transition Scenarios .......................................12
4.1. UE Connecting to a Node in an IPv4 Network through IMS ....12
4.2. Two IPv6 IMS Connected via an IPv4 Network ................15
5. About 3GPP UE IPv4/IPv6 Configuration ..........................15
6. Summary and Recommendations ....................................16
7. Security Considerations ........................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
9. Contributors ...................................................20
10. Authors and Acknowledgements ..................................20
This document describes and analyzes the process of transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks [3GPP-23.060], in which the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
このドキュメントでは、第3世代パートナーシッププロジェクト（3GPP）一般的なパケットラジオサービス（GPRS）パケットネットワークでのIPv6への移行プロセスについて説明および分析します。）またはユニバーサルモバイルテレコミュニケーションシステム（UMTS）/ワイドバンドコード分割多重アクセス（WCDMA）テクノロジー。
This document analyzes the transition scenarios that may come up in the deployment phase of IPv6 in 3GPP packet data networks.
このドキュメントは、3GPPパケットデータネットワークのIPv6の展開フェーズで登場する可能性のある遷移シナリオを分析します。
The 3GPP network architecture is described in [RFC3314], and relevant transition scenarios are documented in [RFC3574]. The reader of this specification should be familiar with the material presented in these documents.
3GPPネットワークアーキテクチャは[RFC3314]で説明されており、関連する遷移シナリオは[RFC3574]に文書化されています。この仕様の読者は、これらの文書に示されている資料に精通している必要があります。
The scenarios analyzed in this document are divided into two categories: general-purpose packet service scenarios, referred to as GPRS scenarios in this document, and IP Multimedia Subsystem (IMS) scenarios, which include Session Initiation Protocol (SIP) considerations. For more information about IMS, see [3GPP-23.228], [3GPP-24.228], and [3GPP-24.229].
このドキュメントで分析されたシナリオは、このドキュメントのGPRSシナリオと呼ばれる汎用パケットサービスシナリオと、セッション開始プロトコル（SIP）の考慮事項を含むIPマルチメディアサブシステム（IMS）シナリオの2つのカテゴリに分けられます。IMSの詳細については、[3GPP-23.228]、[3GPP-24.228]、および[3GPP-24.229]を参照してください。
GPRS scenarios are the following:
GPRSシナリオは次のとおりです。
- Dual Stack User Equipment (UE) connecting to IPv4 and IPv6 nodes - IPv6 UE connecting to an IPv6 node through an IPv4 network - IPv4 UE connecting to an IPv4 node through an IPv6 network - IPv6 UE connecting to an IPv4 node
- IPv4およびIPv6ノードに接続するデュアルスタックユーザー機器（UE）-IPv4ネットワークを介してIPv6ノードに接続するIPv6 UE -IPv6ネットワークを介してIPv4ノードに接続する-IPv4ノード-IPv4ノードに接続するIPv4ノード
- IPv4 UE connecting to an IPv6 node
- IPv4ノードに接続するIPv4 UE
IMS scenarios are the following:
IMSシナリオは次のとおりです。
- UE connecting to a node in an IPv4 network through IMS - Two IPv6 IMS connected via an IPv4 network
- IMSを介してIPv4ネットワーク内のノードに接続するUE -IPv4ネットワークを介して接続されている2つのIPv6IMS
The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In the scenarios, the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.
焦点は、さまざまな遷移シナリオと適用可能な移行メカニズムの分析と、これらの遷移シナリオのソリューションを見つけることです。シナリオでは、ユーザー機器（UE）が他のネットワークのノードに接続します。たとえば、インターネットでは、IPv6/IPv4遷移メカニズムが必要です。
The scope of this document is to analyze the possible transition scenarios in the 3GPP-defined GPRS network in which a UE connects to, or is contacted from, another node on the Internet. This document covers scenarios with and without the use of the SIP-based IP Multimedia Core Network Subsystem (IMS). This document does not focus on radio-interface-specific issues; both 3GPP Second and Third Generation radio network architectures (GSM, Enhanced Data rates for GSM Evolution (EDGE) and UMTS/WCDMA) will be covered by this analysis.
このドキュメントの範囲は、UEがインターネット上の別のノードに接続する、または接触する3GPP定義GPRSネットワークの可能な遷移シナリオを分析することです。このドキュメントでは、SIPベースのIPマルチメディアコアネットワークサブシステム（IMS）の使用の有無にかかわらずシナリオをカバーしています。このドキュメントは、ラジオインターフェイス固有の問題に焦点を当てていません。3GPP第2世代と第3世代の無線ネットワークアーキテクチャ（GSM、GSM進化（EDGE）およびUMTS/WCDMAのデータレートの強化）の両方が、この分析でカバーされます。
The 3GPP2 architecture is similar to 3GPP in many ways, but differs in enough details that this document does not include these variations in its analysis.
3GPP2アーキテクチャは多くの点で3GPPに似ていますが、このドキュメントが分析にこれらのバリエーションを含めないほど十分な詳細が異なります。
The transition mechanisms specified by the IETF Ngtrans and v6ops Working Groups shall be used. This memo shall not specify any new transition mechanisms, but only documents the need for new ones (if appropriate).
IETF NGTRANSおよびV6OPSワーキンググループによって指定された遷移メカニズムを使用するものとします。このメモは、新しい遷移メカニズムを指定するものではなく、新しい遷移メカニズムのみを文書化します（必要に応じて）。
2G Second Generation Mobile Telecommunications, e.g., GSM and GPRS technologies
2G第2世代のモバイル通信、例えばGSMおよびGPRSテクノロジー
3G Third Generation Mobile Telecommunications, e.g., UMTS technology
3Gサードジェネレーションモバイル通信、例えばUMTSテクノロジー
3GPP Third Generation Partnership Project
3GPP第三世代パートナーシッププロジェクト
ALG Application Level Gateway
アルグアプリケーションレベルゲートウェイ
APN Access Point Name. The APN is a logical name referring to a GGSN and an external network.
APNアクセスポイント名。APNは、GGSNと外部ネットワークを指す論理名です。
B2BUA Back-to-Back User Agent
B2BUAバックツーバックユーザーエージェント
CSCF Call Session Control Function (in 3GPP Release 5 IMS)
CSCFコールセッション制御機能（3GPPリリース5 IMS）
DNS Domain Name System
DNSドメイン名システム
EDGE Enhanced Data rates for GSM Evolution
GSM進化のエッジ強化データレート
GGSN Gateway GPRS Support Node (default router for 3GPP User Equipment)
GGSNゲートウェイGPRSサポートノード（3GPPユーザー機器のデフォルトルーター）
GPRS General Packet Radio Service
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
モバイル通信用のGSMグローバルシステム
HLR Home Location Register
HLRホームロケーションレジスタ
IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 IPv6-only part of the network
IMS IPマルチメディア（コアネットワーク）サブシステム、3GPPリリース5 IPv6のみのネットワークの部分
ISP Internet Service Provider
ISPインターネットサービスプロバイダー
NAT Network Address Translation
NATネットワークアドレスの変換
NAPT-PT Network Address Port Translation - Protocol Translation
NAPT -PTネットワークアドレスポート翻訳 - プロトコル翻訳
NAT-PT Network Address Translation - Protocol Translation
NAT -PTネットワークアドレス変換 - プロトコル変換
PCO-IE Protocol Configuration Options Information Element
PCO-IEプロトコル構成オプション情報要素
PDP Packet Data Protocol
PDPパケットデータプロトコル
PPP Point-to-Point Protocol
PPPポイントツーポイントプロトコル
SDP Session Description Protocol
SDPセッション説明プロトコル
SGSN Serving GPRS Support Node
SGSNサービングGPRSサポートノード
SIIT Stateless IP/ICMP Translation Algorithm
SIIT STATELESS IP/ICMP翻訳アルゴリズム
SIP Session Initiation Protocol
SIPセッション開始プロトコル
UE User Equipment, e.g., a UMTS mobile handset
UEユーザー機器、例えば、UMTSモバイルハンドセット
UMTS Universal Mobile Telecommunications System
UMTSユニバーサルモバイル通信システム
WCDMA Wideband Code Division Multiple Access
WCDMAワイドバンドコード分割複数アクセス
Some terms used in 3GPP transition scenarios and analysis documents are briefly defined here.
3GPPトランジションシナリオと分析ドキュメントで使用されるいくつかの用語は、ここで簡単に定義されています。
Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both IPv4 and IPv6 stacks. It is capable of activating both IPv4 and IPv6 Packet Data Protocol (PDP) contexts. Dual stack UE may be capable of tunneling.
デュアルスタックUEデュアルスタックUEは、IPv4とIPv6スタックの両方を備えた3GPPモバイルハンドセットです。IPv4とIPv6パケットデータプロトコル（PDP）コンテキストの両方をアクティブにすることができます。デュアルスタックUEは、トンネリングが可能になる場合があります。
IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is only capable of activating IPv6 PDP contexts.
IPv6 UE IPv6 UEはIPv6のみの3GPPモバイルハンドセットです。IPv6 PDPコンテキストをアクティブにすることのみです。
IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is only capable of activating IPv4 PDP contexts.
IPv4 UE IPv4 UEはIPv4のみの3GPPモバイルハンドセットです。IPv4 PDPコンテキストをアクティブにすることのみです。
IPv4 node IPv4 node is here defined to be the IPv4-capable node the UE is communicating with. The IPv4 node can be, e.g., an application server or another UE.
IPv4ノードIPv4ノードは、UEが通信しているIPv4対応ノードであると定義されています。IPv4ノードは、たとえば、アプリケーションサーバーまたは別のUEにすることができます。
IPv6 node IPv6 node is here defined to be the IPv6-capable node the UE is communicating with. The IPv6 node can be, e.g., an application server or another UE.
IPv6ノードIPv6ノードは、UEが通信しているIPv6対応ノードであると定義されています。IPv6ノードは、たとえば、アプリケーションサーバーまたは別のUEにすることができます。
PDP Context Packet Data Protocol (PDP) Context is a connection between the UE and the GGSN, over which the packets are transferred. There are currently three PDP types: IPv4, IPv6, and PPP.
PDPコンテキストパケットデータプロトコル（PDP）コンテキストは、UEとGGSNの間の接続であり、その上にパケットが転送されます。現在、3つのPDPタイプがあります：IPv4、IPv6、およびPPP。
This section briefly introduces these IETF IPv4/IPv6 transition mechanisms:
このセクションでは、これらのIETF IPv4/IPv6遷移メカニズムを簡単に紹介します。
- dual IPv4/IPv6 stack [RFC4213] - tunneling [RFC4213] - protocol translators [RFC2766], [RFC2765]
- Dual IPv4/IPv6スタック[RFC4213] - トンネリング[RFC4213] -Protocol翻訳者[RFC2766]、[RFC2765]
In addition, DNS recommendations are given. The applicability of different transition mechanisms to 3GPP networks is discussed in sections 3 and 4.
さらに、DNSの推奨事項が与えられます。3GPPネットワークへのさまざまな遷移メカニズムの適用性については、セクション3および4で説明します。
The dual IPv4/IPv6 stack is specified in [RFC4213]. If we consider the 3GPP GPRS core network, dual stack implementation in the Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack and public (global) IP addresses can typically access both IPv4 and IPv6 services without additional translators in the network. However, it is good to remember that private IPv4 addresses and NATs [RFC2663] have been used and will be used in mobile networks. Public/global IP addresses are also needed for peer-to-peer services: the node needs a public/global IP address that is visible to other nodes.
デュアルIPv4/IPv6スタックは[RFC4213]で指定されています。3GPP GPRSコアネットワークを考慮すると、GATEWAY GPRSサポートノード（GGSN）のデュアルスタック実装により、IPv4およびIPv6 PDPコンテキストのサポートが可能になります。デュアルスタックとパブリック（グローバル）IPアドレスを持つUEは、通常、ネットワーク内の追加の翻訳者なしでIPv4サービスとIPv6サービスの両方にアクセスできます。ただし、プライベートIPv4アドレスとNAT [RFC2663]が使用され、モバイルネットワークで使用されることを覚えておくとよいでしょう。ピアツーピアサービスにはパブリック/グローバルIPアドレスも必要です。ノードには、他のノードに表示されるパブリック/グローバルIPアドレスが必要です。
Tunneling is a transition mechanism that requires dual IPv4/IPv6 stack functionality in the encapsulating and decapsulating nodes. Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6.
トンネリングは、カプセンシングおよび脱カプセル化ノードにデュアルIPv4/IPv6スタック機能を必要とする遷移メカニズムです。基本的なトンネルの代替品は、IPv6-in-IPV4およびIPv4-in-IPV6です。
Tunneling can be static or dynamic. Static (configured) tunnels are fixed IPv6 links over IPv4, and they are specified in [RFC4213]. Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where the tunnel endpoints are not configured, i.e., the links are created dynamically.
トンネリングは静的または動的にすることができます。静的（構成）トンネルはIPv4よりも固定IPv6リンクであり、[RFC4213]で指定されています。動的（自動）トンネルは、トンネルエンドポイントが構成されていないIPv4を介した仮想IPv6リンクです。つまり、リンクは動的に作成されます。
A translator can be defined as an intermediate component between a native IPv4 node and a native IPv6 node to enable direct communication between them without requiring any modifications to the end nodes.
翻訳者は、ネイティブIPv4ノードとネイティブIPv6ノードの間の中間コンポーネントとして定義して、エンドノードの変更を必要とせずにそれらの間の直接通信を有効にすることができます。
Header conversion is a translation mechanism. In header conversion, IPv6 packet headers are converted to IPv4 packet headers, or vice versa, and checksums are adjusted or recalculated if necessary. NAT-PT (Network Address Translation/Protocol Translation) [RFC2766] using Stateless IP/ICMP Translation [RFC2765] is an example of such a mechanism.
ヘッダー変換は翻訳メカニズムです。ヘッダー変換では、IPv6パケットヘッダーがIPv4パケットヘッダーに変換され、その逆に変換され、必要に応じてチェックサムが調整または再計算されます。NAT-PT（ネットワークアドレス変換/プロトコル翻訳）[RFC2766] STATELLESS IP/ICMP翻訳[RFC2765]を使用することは、このようなメカニズムの例です。
Translators may be needed in some cases when the communicating nodes do not share the same IP version; in others, it may be possible to avoid such communication altogether. Translation can take place at the network layer (using NAT-like techniques), the transport layer (using a TCP/UDP proxy), or the application layer (using application relays).
通信ノードが同じIPバージョンを共有しない場合には、翻訳者が必要になる場合があります。他の人では、そのようなコミュニケーションを完全に回避することが可能かもしれません。翻訳は、ネットワークレイヤー（NATのような手法を使用）、輸送層（TCP/UDPプロキシを使用）、またはアプリケーションレイヤー（アプリケーションリレーを使用）で行うことができます。
To avoid the DNS name space from fragmenting into parts where some parts of DNS are visible only using IPv4 (or IPv6) transport, the recommendation (as of this writing) is to always keep at least one authoritative server IPv4-enabled, and to ensure that recursive DNS servers support IPv4. See DNS IPv6 transport guidelines [RFC3901] for more information.
DNS名スペースがIPv4（またはIPv6）トランスポートを使用してDNSの一部が表示される部分に断片化するのを回避するために、推奨事項（この記事の記事の時点）は、少なくとも1つの信頼できるサーバーIPv4対応を常に保持することであり、確実にすることです。再帰的なDNSサーバーはIPv4をサポートしています。詳細については、DNS IPv6 Transport Guidelines [RFC3901]を参照してください。
This section discusses the scenarios that might occur when a GPRS UE contacts services or other nodes, e.g., a web server in the Internet.
このセクションでは、GPRS UEがサービスまたは他のノード、たとえばインターネット内のWebサーバーに接触したときに発生する可能性のあるシナリオについて説明します。
The following scenarios described by [RFC3574] are analyzed here. In all of the scenarios, the UE is part of a network where there is at least one router of the same IP version, i.e., the GGSN, and the UE is connecting to a node in a different network.
[RFC3574]で説明されている以下のシナリオは、ここで分析されています。すべてのシナリオで、UEは同じIPバージョンの少なくとも1つのルーター、つまりGGSNとUEが別のネットワーク内のノードに接続しているネットワークの一部です。
1) Dual Stack UE connecting to IPv4 and IPv6 nodes
1) IPv4およびIPv6ノードに接続するデュアルスタックUE
2) IPv6 UE connecting to an IPv6 node through an IPv4 network
2) IPv4ネットワークを介してIPv6ノードに接続するIPv6UE
3) IPv4 UE connecting to an IPv4 node through an IPv6 network
3) IPv6ネットワークを介してIPv4ノードに接続するIPv4UE
4) IPv6 UE connecting to an IPv4 node
4) IPv4ノードに接続するIPv6 UE
5) IPv4 UE connecting to an IPv6 node
5) IPv4ノードに接続するIPv4 UE
In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes.
このシナリオでは、デュアルスタックUEは、IPv4ノードとIPv6ノードの両方と通信できます。
It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE activates the appropriate PDP context depending on the type of application it has started or depending on the address of the peer host it needs to communicate with. The authors leave the PDP context activation policy to be decided by UE implementers, application developers, and operators. One discussed possibility is to activate both IPv4 and IPv6 types of PDP contexts in advance, because activation of a PDP context usually takes some time. However, that probably is not good usage of network resources. Generally speaking, IPv6 PDP contexts should be preferred even if that meant IPv6-in-IPv4 tunneling would be needed in the network (see Section 3.2 for more details). Note that this is transparent to the UE.
IPv6ピアノードと通信するときにIPv6 PDPコンテキストをアクティブにすることをお勧めします。IPv4ピアノードと通信するときは、IPv4 PDPコンテキストを通信します。3GPPネットワークがIPv4とIPv6 PDPコンテキストの両方をサポートする場合、UEは、通信する必要があるピアホストのアドレスに応じて、適切なPDPコンテキストをアクティブにします。著者は、PDPコンテキストアクティベーションポリシーを、UE実装者、アプリケーション開発者、およびオペレーターによって決定されるようにします。議論された可能性の1つは、PDPコンテキストのアクティブ化には通常時間がかかるため、事前にIPv4とIPv6タイプのPDPコンテキストの両方をアクティブにすることです。ただし、それはおそらくネットワークリソースの適切な使用ではありません。一般的に言えば、IPv6 PDPコンテキストは、ネットワークでIPv6-in-IPV4トンネリングが必要になることを意味していても、優先される必要があります（詳細についてはセクション3.2を参照）。これはUEに対して透明であることに注意してください。
Although the UE is dual stack, the UE may find itself attached to a 3GPP network in which the Serving GPRS Support Node (SGSN), the GGSN, and the Home Location Register (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP contexts. This may happen in early phases of IPv6 deployment, or because the UE has "roamed" from a 3GPP network that supports IPv6 to one that does not. If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism.
UEはデュアルスタックですが、UEは、サービングGPRSサポートノード（SGSN）、GGSN、およびホームロケーションレジスタ（HLR）がIPv4 PDPコンテキストをサポートする3GPPネットワークに接続する可能性がありますが、IPv6 PDPをサポートしていませんコンテキスト。これは、IPv6の展開の初期段階で発生する可能性があります。または、UEがIPv6をサポートしていない3GPPネットワークからそうでないネットワークに「ローマイン」しているためです。3GPPネットワークがIPv6 PDPコンテキストをサポートしておらず、UEのアプリケーションがIPv6（-only）ノードと通信する必要がある場合、UEはIPv4 PDPコンテキストをアクティブにし、トンネルメカニズムを使用してIPv4パケットのIPv6パケットをカプセル化する場合があります。
The tunneling mechanism may require public IPv4 addresses, but there are tunneling mechanisms and deployment scenarios in which private IPv4 addresses may be used, for instance, if the tunnel endpoints are in the same private domain, or the tunneling mechanism works through IPv4 NAT.
トンネリングメカニズムにはパブリックIPv4アドレスが必要になる場合がありますが、たとえばトンネルエンドポイントが同じプライベートドメインにある場合、またはトンネルメカニズムがIPv4 NATを介して機能する場合、プライベートIPv4アドレスを使用できるトンネリングメカニズムと展開シナリオがあります。
One deployment scenario uses a laptop computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and an IPv4 PDP context is activated. The tunneling mechanism depends on the laptop computer's support of tunneling mechanisms. Another deployment scenario is performing IPv6-in-IPv4 tunneling in the UE itself and activating an IPv4 PDP context.
1つの展開シナリオでは、ラップトップコンピューターと3GPP UEをモデムとして使用します。IPv6パケットは、ラップトップコンピューターのIPv4パケットにカプセル化されており、IPv4 PDPコンテキストがアクティブになっています。トンネルメカニズムは、ラップトップコンピューターのトンネルメカニズムのサポートに依存します。別の展開シナリオは、UE自体でIPv6-in-IPV4トンネリングを実行し、IPv4 PDPコンテキストをアクティブにすることです。
Closer details for an applicable tunneling mechanism are not analyzed in this document. However, a simple host-to-router (automatic) tunneling mechanism can be a good fit. There is not yet consensus on the right approach, and proposed mechanisms so far include [ISATAP] and [STEP]. Especially ISATAP has had some support in the working group. Goals for 3GPP zero-configuration tunneling are documented in [zeroconf].
該当するトンネルメカニズムの詳細は、このドキュメントでは分析されていません。ただし、シンプルなホストからルーター（自動）トンネリングメカニズムは適している場合があります。適切なアプローチに関するコンセンサスはまだありません。これまでのところ、提案されているメカニズムには[ISATAP]および[ステップ]が含まれます。特にISATAPは、ワーキンググループでいくらかのサポートを受けています。3GPPゼロコンフィグラートンネルの目標は、[Zeroconf]に文書化されています。
This document strongly recommends that the 3GPP operators deploy basic IPv6 support in their GPRS networks. That makes it possible to lessen the transition effects in the UEs.
このドキュメントでは、3GPPオペレーターがGPRSネットワークに基本的なIPv6サポートを展開することを強く推奨しています。これにより、UESの遷移効果を軽減できます。
As a general guideline, IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node.
一般的なガイドラインとして、IPv6通信は、IPv4 NATを介して同じデュアルスタックピアノードに移動するよりも好まれます。
Public IPv4 addresses are often a scarce resource for the operator, and usually it is not possible for a UE to have a public IPv4 address (continuously) allocated for its use. Use of private IPv4 addresses means use of NATs when communicating with a peer node outside the operator's network. In large networks, NAT systems can become very complex, expensive, and difficult to maintain.
パブリックIPv4アドレスは、多くの場合、オペレーターにとって希少なリソースであり、通常、UEがパブリックIPv4アドレス（継続的に）を使用するために割り当てられることは不可能です。プライベートIPv4アドレスの使用とは、オペレーターのネットワークの外側のピアノードと通信する際のNATを使用することを意味します。大規模なネットワークでは、NATシステムは非常に複雑で高価になり、維持が困難になる可能性があります。
The best solution for this scenario is obtained with tunneling; i.e., IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context is activated between the UE and the GGSN. Tunneling is handled in the network, because IPv6 UE does not have the dual stack functionality needed for tunneling. The encapsulating node can be the GGSN, the edge router between the border of the operator's IPv6 network and the public Internet, or any other dual stack node within the operator's IP network. The encapsulation (uplink) and decapsulation (downlink) can be handled by the same network element. Typically, the tunneling handled by the network elements is transparent to the UEs and IP traffic looks like native IPv6 traffic to them. For the applications and transport protocols, tunneling enables end-to-end IPv6 connectivity.
このシナリオの最良のソリューションは、トンネリングで取得されます。つまり、IPv6-in-IPV4トンネリングが要件です。IPv6 PDPコンテキストは、UEとGGSNの間でアクティブになります。IPv6 UEにはトンネリングに必要なデュアルスタック機能がないため、トンネルはネットワークで処理されます。カプセル化ノードは、GGSN、オペレーターのIPv6ネットワークとパブリックインターネットの境界の間のエッジルーター、またはオペレーターのIPネットワーク内の他のデュアルスタックノードです。カプセル化（アップリンク）と脱カプセル化（ダウンリンク）は、同じネットワーク要素で処理できます。通常、ネットワーク要素によって処理されるトンネルはUESに対して透明であり、IPトラフィックはネイティブIPv6トラフィックのように見えます。アプリケーションおよび輸送プロトコルの場合、トンネリングによりエンドツーエンドのIPv6接続が可能になります。
IPv6-in-IPv4 tunnels between IPv6 islands can be either static or dynamic. The selection of the type of tunneling mechanism is a policy decision for the operator/ISP deployment scenario, and only generic recommendations can be given in this document.
IPv6島間のIPv6-in-IPV4トンネルは、静的または動的にすることができます。トンネリングメカニズムのタイプの選択は、オペレーター/ISP展開シナリオのポリシー決定であり、このドキュメントでは一般的な推奨事項のみを示すことができます。
The following subsections are focused on the usage of different tunneling mechanisms when the peer node is in the operator's network or outside the operator's network. The authors note that where the actual 3GPP network ends and which parts of the network belong to the ISP(s) also depend on the deployment scenario. The authors are not commenting on how many ISP functions the 3GPP operator should perform. However, many 3GPP operators are ISPs of some sort themselves. ISP networks' transition to IPv6 is analyzed in [RFC4029].
次のサブセクションは、ピアノードがオペレーターのネットワークまたはオペレーターのネットワーク外にある場合、さまざまなトンネルメカニズムの使用に焦点を当てています。著者は、実際の3GPPネットワークが終了し、ネットワークのどの部分がISPに属しているかは、展開シナリオにも依存することに注目しています。著者は、3GPPオペレーターが実行すべきISP関数の数についてコメントしていません。ただし、多くの3GPP演算子は、ある種のISPです。ISPネットワークのIPv6への移行は[RFC4029]で分析されています。
GPRS operators today have typically deployed IPv4 backbone networks. IPv6 backbones can be considered quite rare in the first phases of the transition.
今日、GPRSオペレーターは通常、IPv4バックボーンネットワークを展開しています。IPv6バックボーンは、遷移の最初のフェーズでは非常にまれであると考えられます。
In initial IPv6 deployment, where a small number of IPv6-in-IPv4 tunnels are required to connect the IPv6 islands over the 3GPP operator's IPv4 network, manually configured tunnels can be used. In a 3GPP network, one IPv6 island can contain the GGSN while another island can contain the operator's IPv6 application servers. However, manually configured tunnels can be an administrative burden when the number of islands and therefore tunnels rises. In that case, upgrading parts of the backbone to dual stack may be the simplest choice. The administrative burden could also be mitigated by using automated management tools.
3GPPオペレーターのIPv4ネットワークでIPv6島を接続するために少数のIPv6-in-IPV4トンネルが必要な最初のIPv6展開では、手動で構成されたトンネルを使用できます。3GPPネットワークでは、1つのIPv6島にGGSNを含めることができ、別の島にはオペレーターのIPv6アプリケーションサーバーを含めることができます。ただし、手動で構成されたトンネルは、島の数、したがってトンネルが上昇する場合の管理上の負担になる可能性があります。その場合、バックボーンの部分をデュアルスタックにアップグレードすることが最も簡単な選択かもしれません。自動化された管理ツールを使用して、管理上の負担を軽減することもできます。
Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels alone do not provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they can provide an adequate solution depending on the design of the network and the presence of other router redundancy mechanisms, such as the use of IPv6 routing protocols.
接続冗長性は、3GPPネットワークの重要な要件としても注意する必要があります。静的トンネルだけでは、IPv6ルートが下がるすべてのシナリオにルーティングリカバリソリューションを提供しません。ただし、ネットワークの設計とIPv6ルーティングプロトコルの使用など、他のルーター冗長機構の存在に応じて適切なソリューションを提供できます。
This subsection includes the case in which the peer node is outside the operator's network. In that case, IPv6-in-IPv4 tunneling can be necessary to obtain IPv6 connectivity and reach other IPv6 nodes. In general, configured tunneling can be recommended.
このサブセクションには、ピアノードがオペレーターのネットワークの外側にあるケースが含まれています。その場合、IPv6接続を取得し、他のIPv6ノードに到達するには、IPv6-in-IPV4トンネリングが必要です。一般に、構成されたトンネリングを推奨できます。
Tunnel starting point can be in the operator's network depending on how far the 3GPP operator has come in implementing IPv6. If the 3GPP operator has not deployed IPv6 in its backbone, the encapsulating node can be the GGSN. If the 3GPP operator has deployed IPv6 in its backbone but the upstream ISP does not provide IPv6 connectivity, the encapsulating node could be the 3GPP operator's border router.
トンネルの出発点は、3GPPオペレーターがIPv6の実装にどの程度来たかに応じて、オペレーターのネットワークにあります。3GPPオペレーターがバックボーンにIPv6を展開していない場合、カプセル化ノードはGGSNになります。3GPPオペレーターがバックボーンにIPv6を展開しているが、上流ISPがIPv6接続を提供しない場合、カプセル化ノードは3GPPオペレーターのボーダールーターになる可能性があります。
The case is pretty straightforward if the upstream ISP provides IPv6 connectivity to the Internet and the operator's backbone network supports IPv6. Then the 3GPP operator does not have to configure any tunnels, since the upstream ISP will take care of routing IPv6 packets. If the upstream ISP does not provide IPv6 connectivity, an IPv6-in-IPv4 tunnel should be configured, e.g., from the border router to a dual stack border gateway operated by another ISP that is offering IPv6 connectivity.
上流のISPがインターネットにIPv6接続を提供し、オペレーターのバックボーンネットワークがIPv6をサポートしている場合、ケースは非常に簡単です。上流のISPはルーティングIPv6パケットの処理を行うため、3GPP演算子はトンネルを構成する必要はありません。アップストリームISPがIPv6接続を提供しない場合、IPv6-in-IPV4トンネルは、たとえば、境界ルーターからIPv6接続を提供する別のISPが操作するデュアルスタックボーダーゲートウェイまで構成する必要があります。
3GPP networks are expected to support both IPv4 and IPv6 for a long time, on the UE-GGSN link and between the GGSN and external networks. For this scenario, it is useful to split the end-to-end IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to-v4NODE. This allows an IPv4-only UE to use an IPv4 link (an IPv4 PDP context) to connect to the GGSN without communicating over an IPv6 network.
3GPPネットワークは、UE-GGSNリンクとGGSNと外部ネットワークの間で、長い間IPv4とIPv6の両方をサポートすることが期待されています。このシナリオでは、エンドツーエンドのIPv4 UEをIPv4ノード通信をUE-to-GGSNおよびGGSN-to-V4Nodeに分割すると便利です。これにより、IPv4のみのUEがIPv4リンク（IPv4 PDPコンテキスト）を使用して、IPv6ネットワーク上で通信せずにGGSNに接続できます。
Regarding the GGSN-to-v4NODE communication, typically the transport network between the GGSN and external networks will support only IPv4 in the early stages and migrate to dual stack, since these networks are already deployed. Therefore, it is not envisaged that tunneling of IPv4-in-IPv6 will be required from the GGSN to external IPv4 networks either. In the longer run, 3GPP operators may choose to phase out IPv4 UEs and the IPv4 transport network. This would leave only IPv6 UEs.
GGSNからV4Node通信に関しては、通常、GGSNと外部ネットワーク間のトランスポートネットワークは、初期段階でIPv4のみをサポートし、これらのネットワークが既に展開されているため、デュアルスタックに移行します。したがって、IPv4-in-IPV6のトンネルがGGSNから外部IPv4ネットワークにも必要とされることは想定されていません。長期的には、3GPPオペレーターがIPv4 UESとIPv4 Transport Networkを段階的に廃止することを選択できます。これにより、IPv6 UEのみが残ります。
Therefore, overall, the transition scenario involving an IPv4 UE communicating with an IPv4 peer through an IPv6 network is not considered very likely in 3GPP networks.
したがって、全体として、IPv4ネットワークを介してIPv4ピアと通信するIPv4 UEが関与する遷移シナリオは、3GPPネットワークではそれほど可能性が高いとは見なされません。
Generally speaking, IPv6-only UEs may be easier to manage, but that would require all services to be used over IPv6, and the universal deployment of IPv6 probably is not realistic in the near future. Dual stack implementation requires management of both IPv4 and IPv6 networks, and one approach is that "legacy" applications keep using IPv4 for the foreseeable future and new applications requiring end-to-end connectivity (for example, peer-to-peer services) use IPv6. As a general guideline, IPv6-only UEs are not recommended in the early phases of transition until the IPv6 deployment has become so prevalent that direct communication with IPv4(-only) nodes will be the exception and not the rule. It is assumed that IPv4 will remain useful for quite a long time, so in general, dual stack implementation in the UE can be recommended. This recommendation naturally includes manufacturing dual stack UEs instead of IPv4-only UEs.
一般的に言えば、IPv6のみのUEは管理しやすいかもしれませんが、IPv6を介してすべてのサービスを使用する必要があり、IPv6のユニバーサル展開はおそらく近い将来現実的ではありません。デュアルスタックの実装には、IPv4ネットワークとIPv6ネットワークの両方の管理が必要であり、1つのアプローチは、「レガシー」アプリケーションが、エンドツーエンドの接続性（たとえば、ピアツーピアサービス）の使用を必要とする近い将来および新しいアプリケーションにIPv4を使用し続けることです。IPv6。一般的なガイドラインとして、IPv6のみの展開が非常に一般的になるまで、IPv6のみのUEは移行の初期段階では推奨されません。IPv4は非常に長い間有用であると想定されているため、一般に、UEでのデュアルスタック実装を推奨できます。この推奨事項には、当然、IPv4のみのUEの代わりにデュアルスタックUEの製造が含まれます。
However, if there is a need to connect to an IPv4(-only) node from an IPv6-only UE, it is recommended to use specific translation and proxying techniques; generic IP protocol translation is not recommended. There are three main ways for IPv6(-only) nodes to communicate with IPv4(-only) nodes (excluding avoiding such communication in the first place):
ただし、IPv6のみのUEからIPv4（-only）ノードに接続する必要がある場合は、特定の翻訳およびプロキシテクニックを使用することをお勧めします。一般的なIPプロトコル翻訳はお勧めしません。IPv6（-only）ノードがIPv4（-only）ノードと通信するための3つの主な方法があります（そもそもそのような通信を避けることを除く）：
1. the use of generic-purpose translator (e.g., NAT-PT [RFC2766]) in the local network (not recommended as a general solution),
1. ローカルネットワークでのジェネリックパス翻訳者（例：NAT-PT [RFC2766]）の使用（一般的なソリューションとしては推奨されません）、
2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 TCP relay configured for a couple of ports only [RFC3142]) or application proxies (e.g., HTTP proxy, SMTP relay) in the local network, or
2. いくつかのポートのみで構成された[RFC3142]のみで構成されたIPv6 < - > IPv4 TCPリレーなど、特定の目的プロトコルリレー（例：IPv6 <-> IPv4 TCPリレー）またはアプリケーションプロキシ（例えば、HTTPプロキシ、SMTPリレー）、またはローカルネットワークで、または
3. the use of specific-purpose mechanisms (as described above in 2) in the foreign network; these are indistinguishable from the IPv6-enabled services from the IPv6 UE's perspective and are not discussed further here.
3. 外国ネットワークでの特定の目的メカニズム（上記の2で説明されている）の使用。これらは、IPv6 UEの観点からIPv6対応サービスと区別できないものであり、ここではこれ以上議論されていません。
For many applications, application proxies can be appropriate (e.g., HTTP proxies, SMTP relays, etc.) Such application proxies will not be transparent to the UE. Hence, a flexible mechanism with minimal manual intervention should be used to configure these proxies on IPv6 UEs. Application proxies can be placed, for example, on the GGSN external interface ("Gi"), or inside the service network.
多くのアプリケーションでは、アプリケーションプロキシが適切になります（例：HTTPプロキシ、SMTPリレーなど）。そのようなアプリケーションプロキシはUEに対して透明ではありません。したがって、最小限の手動介入を伴う柔軟なメカニズムを使用して、IPv6 UEでこれらのプロキシを構成する必要があります。アプリケーションプロキシは、たとえば、GGSN外部インターフェイス（ "GI"）に、またはサービスネットワーク内に配置できます。
The authors note that [NATPTappl] discusses the applicability of NAT-PT, and [NATPTexp] discusses general issues with all forms of IPv6-IPv4 translation. The problems related to NAT-PT usage in 3GPP networks are documented in Appendix A.
著者らは、[NatPtAppl]がNAT-PTの適用性について議論し、[NatPtexp]はすべての形式のIPv6-IPv4翻訳で一般的な問題を議論していることを指摘しています。3GPPネットワークのNAT-PT使用に関連する問題は、付録Aに文書化されています。
The legacy IPv4 nodes are typically nodes that support the applications that are popular today in the IPv4 Internet: mostly e-mail and web browsing. These applications will, of course, be supported in the future IPv6 Internet. However, the legacy IPv4 UEs are not going to be updated to support future applications. As these applications are designed for IPv6, and to use the advantages of newer platforms, the legacy IPv4 nodes will not be able to take advantage of them. Thus, they will continue to support legacy services.
レガシーIPv4ノードは、通常、IPv4インターネットで今日人気のあるアプリケーションをサポートするノードです。主に電子メールとWebブラウジングです。もちろん、これらのアプリケーションは、将来のIPv6インターネットでサポートされます。ただし、レガシーIPv4 UEは、将来のアプリケーションをサポートするために更新されることはありません。これらのアプリケーションはIPv6向けに設計されており、新しいプラットフォームの利点を使用するために、レガシーIPv4ノードはそれらを利用することはできません。したがって、彼らは引き続きレガシーサービスをサポートします。
Taking the above into account, the traffic to and from the legacy IPv4 UE is restricted to a few applications. These applications already mostly rely on proxies or local servers to communicate between private address space networks and the Internet. The same methods and technology can be used for IPv4-to-IPv6 transition.
上記を考慮に入れて、レガシーIPv4 UEとの間のトラフィックは、いくつかのアプリケーションに制限されています。これらのアプリケーションは、すでに主にプロキシまたはローカルサーバーに依存して、プライベートアドレススペースネットワークとインターネット間で通信しています。同じ方法と技術は、IPv4-to-IPV6遷移に使用できます。
As IMS is exclusively IPv6, the number of possible transition scenarios is reduced dramatically. The possible IMS scenarios are listed below and analyzed in Sections 4.1 and 4.2.
IMSはIPv6のみであるため、可能な移行シナリオの数は劇的に減少します。可能なIMSシナリオを以下にリストし、セクション4.1および4.2で分析します。
1) UE connecting to a node in an IPv4 network through IMS 2) Two IPv6 IMS connected via an IPv4 network
1) IMSを介してIPv4ネットワーク内のノードに接続するUE 2）IPv4ネットワークを介して接続されている2つのIPv6IMS
For DNS recommendations, we refer to Section 2.4. As DNS traffic is not directly related to the IMS functionality, the recommendations are not in contradiction with the IPv6-only nature of the IMS.
DNSの推奨事項については、セクション2.4を参照してください。DNSトラフィックはIMS機能に直接関係していないため、推奨事項はIMSのIPv6のみの性質と矛盾していません。
This scenario occurs when an (IPv6) IMS UE connects to a node in the IPv4 Internet through the IMS, or vice versa. This happens when the other node is a part of a different system than 3GPP, e.g., a fixed PC, with only IPv4 capabilities.
このシナリオは、（IPv6）IMS UEがIMSを介してIPv4インターネットのノードに接続する場合、またはその逆で発生します。これは、他のノードが3GPPとは異なるシステムの一部である場合に発生します。たとえば、IPv4機能のみを備えた固定PCです。
Over time, users will upgrade the legacy IPv4 nodes to dual-stack, often by replacing the entire node, eliminating this particular problem in that specific deployment.
時間が経つにつれて、ユーザーはレガシーIPv4ノードをデュアルスタックにアップグレードします。多くの場合、ノード全体を交換し、その特定の展開でこの特定の問題を排除します。
Still, it is difficult to estimate how many non-upgradable legacy IPv4 nodes need to communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed.
それでも、IMS UEと通信するために必要な非アップグレード可能なレガシーIPv4ノードの数を推定することは困難です。ここで説明するソリューションは、少数のレガシーIPv4 SIP機器との通信が必要である限られたケースに使用されると想定されています。
As the IMS is exclusively IPv6 [3GPP-23.221], for many of the applications in the IMS, some kind of translators may need to be used in the communication between the IPv6 IMS and the legacy IPv4 hosts in cases where these legacy IPv4 hosts cannot be upgraded to support IPv6.
IMSはIPv6 [3GPP-23.221]のみであるため、IMSの多くのアプリケーションでは、これらのレガシーIPv4ホストができない場合に、IPv6 IMSとレガシーIPv4ホストの間の通信に何らかの翻訳者を使用する必要がある場合があります。IPv6をサポートするためにアップグレードされます。
This section gives a brief analysis of the IMS interworking issues and presents a high-level view of SIP within the IMS. The authors recommend that a detailed solution for the general SIP/SDP/media IPv4/IPv6 transition problem will be specified as soon as possible as a task within the SIP-related Working Groups in the IETF.
このセクションでは、IMSインターワーキングの問題の簡単な分析を示し、IMS内のSIPの高レベルのビューを示します。著者は、IETFのSIP関連ワーキンググループ内のタスクとして、一般的なSIP/SDP/MEDIA IPv4/IPv6遷移問題の詳細なソリューションができるだけ早く指定されることを推奨しています。
The issue of the IPv4/IPv6 interworking in SIP is somewhat more challenging than many other protocols. The control (or signaling) and user (or data) traffic are separated in SIP calls, and thus, the IMS, the transition of IMS traffic from IPv6 to IPv4, must be handled at two levels:
SIPでのIPv4/IPv6インターワーキングの問題は、他の多くのプロトコルよりもやや挑戦的です。コントロール（または信号）およびユーザー（またはデータ）トラフィックはSIPコールで分離されているため、IMS、IPv6からIPv4へのIMSトラフィックの遷移は、2つのレベルで処理する必要があります。
1. Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface)
1. セッション開始プロトコル（SIP）[RFC3261]、およびセッション説明プロトコル（SDP）[RFC2327] [RFC3266]（MMインターフェイス）
2. the user data traffic (Mb-interface)
2. ユーザーデータトラフィック（MBインターフェイス）
In addition, SIP carries an SDP body containing the addressing and other parameters for establishing the user data traffic (the media). Hence, the two levels of interworking cannot be made independently.
さらに、SIPには、ユーザーデータトラフィック（メディア）を確立するためのアドレス指定とその他のパラメーターを含むSDP本体が搭載されています。したがって、インターワーキングの2つのレベルを独立して作成することはできません。
Figure 1 shows an example setup for IPv4 and IPv6 interworking in IMS. The "Interworking Unit" comprises two internal elements a dual stack SIP server and a transition gateway (TrGW) for the media traffic. These two elements are interconnected for synchronizing the interworking of the SIP signaling and the media traffic.
図1は、IMSのIPv4とIPv6インターワーキングのサンプルセットアップを示しています。「インターワーキングユニット」は、デュアルスタックSIPサーバーと、メディアトラフィック用のトランジションゲートウェイ（TRGW）の2つの内部要素を含みます。これらの2つの要素は、SIPシグナルとメディアトラフィックの相互作用を同期するために相互に接続されています。
+-------------------------------+ +------------+
| +------+ | | +--------+ |
| |S-CSCF|---| |SIP Serv| |\
| | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------
| |-----------------------------------|| TrGW ||/
+--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+
Figure 1: UE using IMS to contact a legacy phone
図1：IMSを使用してレガシー電話に連絡するUE
On reception of an INVITE, the SIP server reserves an IP address and a port from the TrGW both for IPv4 and IPv6. Then, the SIP server acts as a B2BUA (Back-to-Back User Agent) and rewrites the SDP of the INVITE to insert the transition gateway in the middle of the media flow between the two endpoints.
招待状を受信すると、SIPサーバーは、IPv4とIPv6の両方でTRGWからIPアドレスとポートを予約します。次に、SIPサーバーはB2BUA（連続したユーザーエージェント）として機能し、招待のSDPを書き直して、2つのエンドポイント間のメディアフローの中央に遷移ゲートウェイを挿入します。
When performing its B2BUA role, the SIP server acts as a UA (User Agent) toward both the IMS and the IPv4 host. Consequently, the SIP server needs to support all the extensions that apply to the session, which are listed in the Require header fields of the SIP messages.
B2BUAの役割を実行するとき、SIPサーバーはIMSとIPv4ホストの両方に向けてUA（ユーザーエージェント）として機能します。したがって、SIPサーバーは、SIPメッセージの要求ヘッダーフィールドにリストされているセッションに適用されるすべての拡張機能をサポートする必要があります。
This approach has a number of important drawbacks, however. The biggest drawback is that the rewriting of the SDP in the SIP signaling prevents securing the SDP payload between the two endpoints. In addition, it breaks the end-to-end negotiation of SIP extensions required for each session. Therefore, the extensions to be used in a particular session are limited by the extensions supported by the SIP server acting as a B2BUA. That is, the introduction of a new extension requires upgrading not only the UAs but the B2BUAs as well.
ただし、このアプローチには多くの重要な欠点があります。最大の欠点は、SIPシグナル伝達におけるSDPの書き換えにより、2つのエンドポイント間のSDPペイロードの確保が妨げられることです。さらに、各セッションに必要なSIP拡張機能のエンドツーエンドの交渉を破ります。したがって、特定のセッションで使用される拡張機能は、B2BUAとして機能するSIPサーバーによってサポートされる拡張機能によって制限されます。つまり、新しい拡張機能を導入するには、UASだけでなくB2BUAもアップグレードする必要があります。
This analysis clearly shows that a new solution for IPv4-IPv6 interworking in SIP networks is needed. The ability to convey multiple alternative addresses in SDP session descriptions [RFC4091] represents a step in this direction.
この分析は、SIPネットワークでのIPV4-IPV6インターワーキングの新しいソリューションが必要であることを明確に示しています。SDPセッションの説明[RFC4091]で複数の代替アドレスを伝える機能は、この方向へのステップを表しています。
Given the problems related to the use of B2BUAs, it is recommended that the SIP-related Working Groups quickly work on a solution to overcome the drawbacks of this approach.
B2BUAの使用に関連する問題を考えると、SIP関連のワーキンググループは、このアプローチの欠点を克服するためのソリューションに迅速に作業することをお勧めします。
At the early stages of IMS deployment, there may be cases where two IMS islands are separated by an IPv4 network such as the legacy Internet. Here both the UEs and the IMS islands are IPv6 only. However, the IPv6 islands are not connected natively with IPv6.
IMS展開の初期段階では、2つのIMS島がレガシーインターネットなどのIPv4ネットワークによって分離されている場合があります。ここでは、UESとIMS島の両方がIPv6のみです。ただし、IPv6島はIPv6とネイティブに接続されていません。
In this scenario, the end-to-end SIP connections are based on IPv6. The only issue is to make connection between two IPv6-only IMS islands over IPv4 network. This scenario is closely related to GPRS scenario represented in Section 3.2. and similar tunneling solutions are applicable also in this scenario.
このシナリオでは、エンドツーエンドのSIP接続はIPv6に基づいています。唯一の問題は、IPv4ネットワーク上の2つのIPv6のみのIMS島間を接続することです。このシナリオは、セクション3.2で表されるGPRSシナリオと密接に関連しています。また、このシナリオでも同様のトンネルソリューションが適用されます。
This informative section aims to give a brief overview of the configuration needed in the UE in order to access IP-based services. There can also be other application-specific settings in the UE that are not described here.
この有益なセクションは、IPベースのサービスにアクセスするためにUEで必要な構成の簡単な概要を説明することを目的としています。また、ここでは説明されていない他のアプリケーション固有の設定もあります。
UE configuration is required in order to access IPv6- or IPv4-based services. The GGSN Access Point has to be defined when using, for example, the web-browsing application. One possibility is to use over-the-air configuration [OMA-CP] to configure the GPRS settings. The user can, for example, visit the operator WWW page and subscribe the GPRS Access Point settings to his/her UE and receive the settings via Short Message Service (SMS). After the user has accepted the settings and a PDP context has been activated, he/she can start browsing. The Access Point settings can also be typed in manually or be pre-configured by the operator or the UE manufacturer.
IPv6-またはIPv4ベースのサービスにアクセスするには、UE構成が必要です。GGSNアクセスポイントは、たとえばWebブラウジングアプリケーションを使用するときに定義する必要があります。1つの可能性は、A-AIR-THE-AIR構成[OMA-CP]を使用してGPRS設定を構成することです。たとえば、ユーザーはオペレーターwwwページにアクセスして、GPRSアクセスポイント設定をueに購読し、Shortメッセージサービス（SMS）を介して設定を受信できます。ユーザーが設定を受け入れ、PDPコンテキストがアクティブ化された後、閲覧を開始できます。アクセスポイントの設定は、手動で入力したり、オペレーターまたはUEメーカーによって事前に構成されたりすることもできます。
DNS server addresses typically also need to be configured in the UE. In the case of IPv4 type PDP context, the (IPv4) DNS server addresses can be received in the PDP context activation (a control plane mechanism). A similar mechanism is also available for IPv6: so-called Protocol Configuration Options Information Element (PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible to use [RFC3736] (or [RFC3315]) and [RFC3646] for receiving DNS server addresses. Active IETF work on DNS discovery mechanisms is ongoing and might result in other mechanisms becoming available over time. The DNS server addresses can also be received over the air (using SMS) [OMA-CP] or typed in manually in the UE.
通常、DNSサーバーアドレスはUEで構成する必要があります。IPv4タイプPDPコンテキストの場合、（IPv4）DNSサーバーアドレスは、PDPコンテキストアクティベーション（コントロールプレーンメカニズム）で受信できます。同様のメカニズムは、3GPP [3GPP-24.008]で指定されたIPv6：いわゆるプロトコル構成オプション情報要素（PCO-II）にも使用できます。また、DNSサーバーアドレスを受信するために[RFC3736]（または[RFC3315]）および[RFC3646]を使用することもできます。DNS発見メカニズムでのアクティブなIETF作業は進行中であり、時間の経過とともに他のメカニズムが利用可能になる可能性があります。DNSサーバーアドレスは、空中（SMSを使用）[OMA-CP]を介して受信するか、UEで手動で入力することもできます。
When accessing IMS services, the UE needs to know the Proxy-Call Session Control Function (P-CSCF) IPv6 address. Either a 3GPP-specific PCO-IE mechanism or a DHCPv6-based mechanism ([RFC3736] and [RFC3319]) can be used. Manual configuration or configuration over the air is also possible. IMS subscriber authentication and registration to the IMS and SIP integrity protection are not discussed here.
IMSサービスにアクセスするとき、UEはプロキシコールセッション制御機能（P-CSCF）IPv6アドレスを知る必要があります。3GPP固有のPCO-IEメカニズムまたはDHCPV6ベースのメカニズム（[RFC3736]および[RFC3319]）を使用できます。空中上の手動構成または構成も可能です。IMSサブスクライバー認証とIMSおよびSIPの整合性保護への登録については、ここでは説明しません。
This document has analyzed five GPRS and two IMS IPv6 transition scenarios. Numerous 3GPP networks are using private IPv4 addresses today, and introducing IPv6 is important. The two first GPRS scenarios and both IMS scenarios are seen as the most relevant. The authors summarize some main recommendations here:
このドキュメントでは、5つのGPRと2つのIMS IPv6遷移シナリオを分析しました。多数の3GPPネットワークが今日プライベートIPv4アドレスを使用しており、IPv6を導入することが重要です。2つの最初のGPRSシナリオと両方のIMSシナリオは、最も関連性が高いと見なされます。著者は、ここにいくつかの主な推奨事項を要約しています。
- Dual stack UEs are recommended instead of IPv4-only or IPv6- only UEs. It is important to take care that applications in the UEs support IPv6. In other words, applications should be IP version independent. IPv6-only UEs can become feasible when IPv6 is widely deployed in the networks, and most services work on IPv6.
- IPv4のみまたはIPv6-のみのUEの代わりに、デュアルスタックUEが推奨されます。UESのアプリケーションがIPv6をサポートすることに注意することが重要です。言い換えれば、アプリケーションはIPバージョンに依存する必要があります。IPv6のみのUEは、IPv6がネットワークに広く展開され、ほとんどのサービスがIPv6で動作する場合に実行可能になる可能性があります。
- It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node.
- IPv6ピアノードと通信するときにIPv6 PDPコンテキストをアクティブにすることをお勧めします。IPv4ピアノードと通信するときは、IPv4 PDPコンテキストを通信します。
- IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node.
- IPv6通信は、IPv4 NATを介して同じデュアルスタックピアノードに移動するよりも好まれます。
- This document strongly recommends that the 3GPP operators deploy basic IPv6 support in their GPRS networks as soon as possible. That makes it possible to lessen the transition effects in the UEs.
- このドキュメントでは、3GPPオペレーターがGPRSネットワークに基本的なIPv6サポートをできるだけ早く展開することを強く推奨しています。これにより、UESの遷移効果を軽減できます。
- A tunneling mechanism in the UE may be needed during the early phases of the IPv6 transition process. A lightweight, automatic tunneling mechanism should be standardized in the IETF. See [zeroconf] for more details.
- IPv6遷移プロセスの初期段階では、UEのトンネルメカニズムが必要になる場合があります。軽量の自動トンネルメカニズムは、IETFで標準化する必要があります。詳細については、[Zeroconf]を参照してください。
- Tunneling mechanisms can be used in 3GPP networks, and only generic recommendations are given in this document. More details can be found, for example, in [RFC4029].
- トンネルメカニズムは3GPPネットワークで使用でき、このドキュメントでは一般的な推奨事項のみが示されています。たとえば、[RFC4029]で詳細をご覧ください。
- The authors recommend that a detailed solution for the general SIP/SDP/media IPv4/IPv6 transition problem be specified as soon as possible as a task within the SIP-related Working Groups in the IETF.
- 著者は、IETFのSIP関連ワーキンググループ内のタスクとして、一般的なSIP/SDP/MEDIA IPv4/IPv6遷移問題の詳細なソリューションをできるだけ早く指定することを推奨しています。
Deploying IPv6 has some generic security considerations one should be aware of [V6SEC]; however, these are not specific to 3GPP transition and are therefore out of the scope of this memo.
IPv6の展開には、[V6SEC]に注意する必要がある一般的なセキュリティ上の考慮事項があります。ただし、これらは3GPP遷移に固有ではないため、このメモの範囲外です。
This memo recommends the use of a relatively small number of techniques. Each technique has its own security considerations, including:
このメモは、比較的少数のテクニックの使用を推奨しています。各手法には、次のようなセキュリティ上の考慮事項があります。
- native upstream access or tunneling by the 3GPP network operator,
- 3GPPネットワークオペレーターによるネイティブアップストリームアクセスまたはトンネリング、
- use of routing protocols to ensure redundancy,
- 冗長性を確保するためのルーティングプロトコルの使用、
- use of locally deployed specific-purpose protocol relays and application proxies to reach IPv4(-only) nodes from IPv6-only UEs, or
- IPv6のみのUESからIPv4（-only）ノードに到達するために、ローカルに展開された特定の対応プロトコルリレーとアプリケーションプロキシの使用、または
- a specific mechanism for SIP signaling and media translation.
- SIPシグナル伝達とメディア翻訳のための特定のメカニズム。
The threats of configured tunneling are described in [RFC4213]. Attacks against routing protocols are described in the respective documents and in general in [ROUTESEC]. Threats related to protocol relays have been described in [RFC3142]. The security properties of SIP internetworking are to be specified when the mechanism is specified.
構成されたトンネリングの脅威は[RFC4213]で説明されています。ルーティングプロトコルに対する攻撃は、それぞれのドキュメントで、一般的には[Routesec]で説明されています。プロトコルリレーに関連する脅威は[RFC3142]で説明されています。SIPインターネットワーキングのセキュリティプロパティは、メカニズムが指定されたときに指定されます。
In particular, this memo does not recommend the following technique, which has security issues, not further analyzed here:
特に、このメモでは、セキュリティの問題がある次の手法を推奨していません。ここではさらに分析されていません。
- NAT-PT or other translator as a general-purpose transition mechanism
- 汎用遷移メカニズムとしてのNAT-PTまたはその他の翻訳者
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス翻訳 - プロトコル翻訳（NAT -PT）」、RFC 2766、2000年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003.
[RFC3574] Soininen、J。、「3GPPネットワークの遷移シナリオ」、RFC 3574、2003年8月。
[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月。
[3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[3GPP-23.060] 3GPP TS 23.060 V5.4.0、「一般的なパケットラジオサービス（GPRS）;サービス説明;ステージ2（リリース5）」、2002年12月。
[3GPP-23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements (Release 5)", December 2002.
[3GPP-23.221] 3GPP TS 23.221 v5.7.0、「建築要件（リリース5）」、2002年12月。
[3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem (IMS); Stage 2 (Release 5)", December 2002.
[3GPP-23.228] 3GPP TS 23.228 v5.7.0、「IPマルチメディアサブシステム（IMS）;ステージ2（リリース5）」、2002年12月。
[3GPP-24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP multimedia call control based on SIP and SDP; Stage 3 (Release 5)", December 2002.
[3GPP-24.228] 3GPP TS 24.228 V5.3.0、「SIPとSDP、ステージ3（リリース5）に基づくIPマルチメディアコールコントロールのシグナリングフロー」、2002年12月。
[3GPP-24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002.
[3GPP-24.229] 3GPP TS 24.229 V5.3.0、「SIPおよびSDPに基づくIPマルチメディアコールコントロールプロトコル、ステージ3（リリース5）」、2002年12月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001.
[RFC3142] Hagino、J。およびK. Yamamoto、「IPv6-to-IPV4 Transport Relay Translator」、RFC 3142、2001年6月。
[RFC3266] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, June 2002.
[RFC3266] Olson、S.、Camarillo、G。、およびA. Roach、「セッション説明プロトコル（SDP）のIPv6のサポート」、RFC 3266、2002年6月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314] Wasserman、M。、「第三世代パートナーシッププロジェクト（3GPP）標準におけるIPv6の推奨」、RFC 3314、2002年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3319] Schulzrinne、H。およびB. Volz、「セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPV6）オプション」、RFC 3319、2003年7月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] DROMS、R。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, September 2004.
[RFC3901] Durand、A。およびJ. Ihren、「DNS IPv6輸送運用ガイドライン」、BCP 91、RFC 3901、2004年9月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029] Lind、M.、Ksinant、V.、Park、S.、Baudot、A。、およびP. Savola、「IPv6をISPネットワークに導入するためのシナリオと分析」、RFC 4029、2005年3月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091] Camarillo、G。およびJ. Rosenberg、「セッション説明プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス」、RFC 4091、2005年6月。
[ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, September 2005.
[ISATAP] Templin、F.、Gleeson、T.、Talwar、M。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 4214、2005年9月。
[NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S. and H. Wang, "NAT-PT Applicability", Work in Progress, October 2003.
[Natptappl] Satapati、S.、Sivakumar、S.、Barany、P.、Okazaki、S.、H。Wang、「Nat-Pt Applicability」、2003年10月の進行中。
[NATPTexp] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", Work in Progress, July 2005.
[Natptexp] Aoun、C。およびE. Davies、「Nat-PTを実験的に移動する理由」、2005年7月、進行中の作業。
[ROUTESEC] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", Work in Progress, April 2004.
[RouteSec] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、2004年4月、進行中の作業。
[STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress, January 2004.
[Step] Savola、P。：「Simple IPv6-in-IPV4トンネル設立手順（STEP）」、2004年1月、進行中の作業。
[V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security Considerations", Work in Progress, February 2004.
[V6Sec] Savola、P。：「IPv6 Transition/Co-Existence Security Scomincations」、Work in Progress、2004年2月。
[zeroconf] Nielsen, K., Morelli, M., Palet, J., Soininen, J., and J. Wiljakka, "Goals for Zero-Configuration Tunneling in 3GPP", Work in Progress, October 2004.
[Zeroconf] Nielsen、K.、Morelli、M.、Palet、J。、Soininen、J。、およびJ. Wiljakka、「3GPPでのゼロコンフィ分成分トンネルの目標」、2004年10月の作業。
[3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003.
[3GPP-24.008] 3GPP TS 24.008 V5.8.0、「モバイル無線インターフェイスレイヤー3仕様、コアネットワークプロトコル、ステージ3（リリース5）」、2003年6月。
[OMA-CP] OMA Client Provisioning: Provisioning Architecture Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C, Open Mobile Alliance, 12-Nov-2002.
[OMA-CP] OMAクライアントプロビジョニング：プロビジョニングアーキテクチャの概要バージョン1.1、OMA-WAP-Provarch-V1_1-20021112-C、Open Mobile Alliance、12-NOV-2002。
Pekka Savola has contributed both text and his IPv6 experience to this document. He has provided a large number of helpful comments on the v6ops mailing list. Allison Mankin has contributed text for IMS Scenario 1 (Section 4.1).
Pekka Savolaは、このドキュメントにテキストと彼のIPv6エクスペリエンスの両方を提供しました。彼はV6OPSメーリングリストに多数の有益なコメントを提供しています。Allison Mankinは、IMSシナリオ1（セクション4.1）にテキストを提供しました。
This document was written by:
このドキュメントは次のように書かれています。
Alain Durand, Comcast <alain_durand@cable.comcast.com>
Alain Durand、comcast <alain_durand@cable.comcast.com>
Karim El-Malki, Ericsson Radio Systems <Karim.El-Malki@era.ericsson.se>
Karim El-Malki、Ericsson Radio Systems <Karim.el-malki@era.ericsson.se>
Niall Richard Murphy, Enigma Consulting Limited <niallm@enigma.ie>
Niall Richard Murphy、Enigma Consulting Limited <niallm@enigma.ie>
Hugh Shieh, AT&T Wireless <hugh.shieh@attws.com>
Hugh Shieh、AT＆T Wireless <hugh.shieh@attws.com>
Jonne Soininen, Nokia <jonne.soininen@nokia.com>
Jonne Soininen、Nokia <jonne.soininen@nokia.com>
Hesham Soliman, Flarion
<h.soliman@flarion.com>
Margaret Wasserman, ThingMagic
<margaret@thingmagic.com>
Juha Wiljakka, Nokia <juha.wiljakka@nokia.com>
Juha Wiljakka、Nokia <juha.wiljakka@nokia.com>
The authors would like to give special thanks to Spencer Dawkins for proofreading.
著者は、校正についてスペンサー・ドーキンスに特別な感謝を捧げたいと思います。
The authors would like to thank Heikki Almay, Gabor Bajko, Gonzalo Camarillo, Ajay Jain, Jarkko Jouppi, David Kessens, Ivan Laloux, Allison Mankin, Jasminko Mulahusic, Janne Rinne, Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur, and Rod Van Meter for their valuable input.
著者は、ハイクキ・アルメイ、ガボール・バジコ、ゴンザロ・カマリロ、アジャイ・ジャイン、ジャルコ・ジュッピー、デビッド・ケッセン、イヴァン・ラロウ、アリソン・マンキン、ジャスミンコ・ムラフジック、ジャンヌ・リンヌ、アンドリー・シュミッド、ペドロ・セルナ、ペドロ・セルナ、アナンド・シュミットに感謝したいと思います。貴重な入力のためのヴァンメーター。
Appendix A - On the Use of Generic Translators in the 3GPP Networks
付録A- 3GPPネットワークでの一般的な翻訳者の使用
This appendix lists mainly 3GPP-specific arguments about generic translators, even though the use of generic translators is discouraged.
この付録には、一般的な翻訳者の使用が推奨されていても、主に一般的な翻訳者に関する3GPP固有の引数がリストされています。
Due to the significant lack of IPv4 addresses in some domains, port multiplexing is likely to be a necessary feature for translators (i.e., NAPT-PT). If NAPT-PT is used, it needs to be placed on the GGSN external interface (Gi), typically separate from the GGSN. NAPT-PT can be installed, for example, on the edge of the operator's network and the public Internet. NAPT-PT will intercept DNS requests and other applications that include IP addresses in their payloads, translate the IP header (and payload for some applications if necessary), and forward packets through its IPv4 interface.
一部のドメインにはIPv4アドレスが大幅に不足しているため、ポートマルチプレックスは翻訳者に必要な機能になる可能性があります（つまり、NAPT-PT）。NAPT-PTを使用する場合は、通常GGSNとは別に分離されているGGSN外部インターフェイス（GI）に配置する必要があります。NAPT-PTは、たとえば、オペレーターのネットワークとパブリックインターネットの端にインストールできます。NAPT-PTは、ペイロード内のIPアドレスを含むDNSリクエストやその他のアプリケーションを傍受し、IPヘッダー（および必要に応じて一部のアプリケーションのペイロード）を翻訳し、IPv4インターフェイスを介してパケットを転送します。
NAPT-PT introduces limitations that are expected to be magnified within the 3GPP architecture. [NATPTappl] discusses the applicability of NAT-PT in more detail. [NATPTexp] discusses general issues with all forms of IPv6-IPv4 translation.
NAPT-PTは、3GPPアーキテクチャ内で拡大すると予想される制限を導入します。[NatptAppl] NAT-PTの適用性についてさらに詳しく説明します。[Natptexp]は、IPv6-IPV4翻訳のあらゆる形態の一般的な問題について説明します。
3GPP networks are expected to handle a very large number of subscribers on a single GGSN (default router). Each GGSN is expected to handle hundreds of thousands of connections. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface would raise concerns on the overall network reliability. In addition, IPv6 users are expected to use delay-sensitive applications provided by IMS. Hence, there is a need to minimize forwarding delays within the IP backbone. Furthermore, due to the unprecedented number of connections handled by the default routers (GGSN) in 3GPP networks, a network design that forces traffic to go through a single node at the edge of the network (typical NAPT-PT configuration) is not likely to scale. Translation mechanisms should allow for multiple translators, for load sharing and redundancy purposes.
3GPPネットワークは、単一のGGSN（デフォルトルーター）で非常に多数のサブスクライバーを処理することが期待されています。各GGSNは、数十万の接続を処理することが期待されています。さらに、3GPPネットワークでは高い信頼性が予想されます。その結果、GGSN外部インターフェイスの単一の障害のポイントは、ネットワーク全体の信頼性に関する懸念を引き起こします。さらに、IPv6ユーザーは、IMSが提供する遅延に敏感なアプリケーションを使用することが期待されています。したがって、IPバックボーン内の転送遅延を最小限に抑える必要があります。さらに、3GPPネットワークのデフォルトのルーター（GGSN）によって処理される前例のない接続数のため、ネットワークの端でトラフィックを強制するネットワーク設計（典型的なNAPT-PT構成）はそうではありません。規模。翻訳メカニズムは、負荷共有と冗長性の目的で、複数の翻訳者を可能にする必要があります。
To minimize the problems associated with NAPT-PT, the following actions can be recommended:
NAPT-PTに関連する問題を最小限に抑えるために、次のアクションを推奨できます。
1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to IPv4" case).
1. DNSアルグをNAPT-PTノード（「IPv6からIPv4」ケース）から分離します。
2. Ensure (if possible) that NAPT-PT does not become a single point of failure.
2. Napt-PTが単一の障害点にならないことを（可能であれば）確認してください。
3. Allow for load sharing between different translators. That is, it should be possible for different connections to go through different translators. Note that load sharing alone does not prevent NAPT-PT from becoming a single point of failure.
3. 異なる翻訳者間の負荷共有を可能にします。つまり、異なる接続が異なる翻訳者を通過することが可能であるはずです。負荷共有だけでも、NAPT-PTが単一の障害ポイントになることを妨げないことに注意してください。
Editor's Contact Information
編集者の連絡先情報
Comments or questions regarding this document should be sent to the v6ops mailing list or directly to the document editor:
このドキュメントに関するコメントまたは質問は、V6OPSメーリングリストに、またはドキュメントエディターに直接送信する必要があります。
Juha Wiljakka Nokia Visiokatu 3 FIN-33720 TAMPERE, Finland
Juha Wiljakka Nokia Visiokatu 3 Fin-33720タンペレ、フィンランド
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。