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
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).
著作権（C）インターネット協会（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.
この文書では、第三世代パートナーシッププロジェクト（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.
この文書では、説明し、（GSMの無線ネットワークアーキテクチャは、グローバル移動体通信システムに基づいている第3世代パートナーシッププロジェクト（3GPP）汎用パケット無線サービス（GPRS）パケット・ネットワーク[3GPP-23.060]内の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
- デュアルスタックユーザ機器（UE）、IPv4およびIPv6ノードに接続する - IPv4ネットワークを介してIPv6ノードに接続しているIPv6のUE - IPv6ネットワークを介してIPv4ノードに接続したIPv4 UE - IPv6のUEは、IPv4ノードに接続します
- IPv4 UE connecting to an IPv6 node
- IPv4のUEは、IPv6ノードに接続します
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
- UE IMSを介してIPv4ネットワーク内のノードに接続する - IPv4ネットワークを介して接続された2つのIPv6 IMS
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第二および第三世代無線ネットワークアーキテクチャの両方が（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第二世代移動体通信、例えば、GSMおよびGPRS技術
3G Third Generation Mobile Telecommunications, e.g., UMTS technology
3G第三世代移動体通信、例えば、UMTS技術
3GPP Third Generation Partnership Project
3GPP第三世代パートナーシッププロジェクト
ALG Application Level Gateway
ALGアプリケーションレベルゲートウェイ
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)
（3GPPリリース5 IMS中）CSCF呼セッション制御機能
DNS Domain Name System
DNSドメインネームシステム
EDGE Enhanced Data rates for GSM Evolution
GSMの進化のためのEDGEの拡張データレート
GGSN Gateway GPRS Support Node (default router for 3GPP User Equipment)
GGSNゲートウェイGPRSサポートノード（3GPPユーザー機器のためのデフォルトルータ）
GPRS General Packet Radio Service
GPRS汎用パケット無線サービス
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
サービングGPRSサポートノードSGSN
SIIT Stateless IP/ICMP Translation Algorithm
SIITステートレス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との間の接続です。 IPv4の、IPv6、およびPPP：3つのPDPタイプは現在ありません。
This section briefly introduces these IETF IPv4/IPv6 transition mechanisms:
このセクションでは、簡単にこれらのIETFのIPv4 / IPv6移行メカニズムが導入されています。
- dual IPv4/IPv6 stack [RFC4213] - tunneling [RFC4213] - protocol translators [RFC2766], [RFC2765]
- デュアルIPv4 / IPv6スタック[RFC4213] - トンネリング[RFC4213] - プロトコルトランスレータ[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コアネットワークを考慮した場合、ゲートウェイ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-で-IPv4およびIPv4のイン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]ステートレス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名前空間を回避するために、（これを書いているように）勧告は、常に少なくとも一つの権威サーバのIPv4対応を維持するために、かつ確実にするためであります再帰的なDNSサーバがIPv4をサポートしています。詳細については、DNSのIPv6トランスポート・ガイドライン[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バージョン、すなわち、GGSNの少なくとも一つのルータが存在するネットワークの一部であり、UEは、異なるネットワークのノードに接続されています。
1) Dual Stack UE connecting to IPv4 and IPv6 nodes
1）デュアルスタックUEは、IPv4とIPv6ノードに接続します
2) IPv6 UE connecting to an IPv6 node through an IPv4 network
2）IPv6のUEは、IPv4ネットワークを介してIPv6ノードに接続します
3) IPv4 UE connecting to an IPv4 node through an IPv6 network
3）のIPv4 UEは、IPv6ネットワークを介してIPv4ノードに接続します
4) IPv6 UE connecting to an IPv4 node
4）は、IPv6 UEは、IPv4ノードに接続します
5) IPv4 UE connecting to an IPv6 node
5）のIPv4 UEは、IPv6ノードに接続します
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.
IPv4のピア・ノードと通信するときのIPv6ピア・ノードとIPv4 PDPコンテキストとの通信時のIPv6 PDPコンテキストをアクティブにすることが推奨されます。 3GPPネットワークは、IPv4とIPv6の両方のPDPコンテキストをサポートする場合、UEは、それが起動またはそれと通信する必要がピア・ホストのアドレスに応じたアプリケーションの種類に応じて適切なPDPコンテキストを起動します。著者らは、UEの実装、アプリケーション開発者、およびオペレータによって決定されるPDPコンテキストアクティブ化ポリシーを残します。一つの議論の可能性は、PDPコンテキストの活性化は、通常、いくつかの時間がかかるので、予めPDPコンテキストのIPv4とIPv6の両方のタイプを活性化することです。しかし、それはおそらく、ネットワーク資源の良い使い方ではありません。それは、IPv6インのIPv4トンネリングが（詳細は3.2節を参照）は、ネットワークに必要とされるであろうものであっても一般的に言って、IPv6のPDPコンテキストが好まれるべきです。これは、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コンテキストをサポートしていますが、IPv6のPDPをサポートしていないようなの3GPPネットワークに接続されているかもしれませんコンテキスト。これは、IPv6展開の初期段階で発生する可能性があり、またはUEはないものにIPv6をサポートする3GPPネットワークからの「ローミング」したため。 3GPPネットワークがIPv6 PDPコンテキストをサポートしていない、及びUE上のアプリケーションがIPv6（のみの）ノードと通信する必要がある場合、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.
一つの展開シナリオは、ラップトップコンピュータやモデムなどの3GPP UEを使用しています。 IPv6パケットは、ラップトップコンピュータにIPv4パケットにカプセル化され、IPv4 PDPコンテキストが活性化されます。トンネリングメカニズムは、トンネリングメカニズムのラップトップコンピュータのサポートに依存します。別の展開シナリオは、UE自体にIPv6の型の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]含めると[STEP]はまだありません。特に、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サポートを展開することをお勧めします。それは、UEでのトランジション効果を軽減することが可能となります。
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を経由するのIPv4通信に好適です。
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の型のIPv4トンネリングが必要です。 IPv6のPDPコンテキストは、UEとGGSNとの間に活性化されます。 IPv6のUEは、トンネリングのために必要なデュアルスタック機能を持っていないので、トンネリングは、ネットワーク内で処理されます。カプセル化ノードは、GGSN、事業者のIPv6ネットワークの境界と公衆インターネット、または事業者のIPネットワーク内の他のデュアルスタックノード間のエッジルータになることができます。カプセル化（アップリンク）および逆カプセル化（ダウンリンク）は、同じネットワーク要素によって処理することができます。一般的に、ネットワーク要素によって処理されるトンネリングは、UEに透明であり、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イン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].
ピア・ノードは、オペレータのネットワークまたはオペレータのネットワークの外にある場合、以下のサブセクションは、異なるトンネリングメカニズムの使用に焦点を当てています。著者らはまた、展開シナリオに依存ISP（S）に属する場合、実際の3GPPネットワークが終了しているネットワークの一部ことに注意してください。著者は、3GPPオペレータが実行する必要がありますどのように多くのISPの機能にコメントされていません。しかし、多くの3GPP事業者は、いくつかの並べ替え自身のISPがあります。 IPv6へのISPネットワーク遷移が[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.
IPv6の型のIPv4トンネルの小さな数は、3GPPオペレータのIPv4ネットワーク上のIPv6アイランドを接続するために必要とされる初期のIPv6展開では、手動で構成されたトンネルを使用することができます。別の島は事業者のIPv6のアプリケーションサーバーを含めることができますしながら、3GPPネットワークでは、1つのIPv6の島は、GGSNを含むことができます。従って、島の数とが上昇をトンネルしかし、手動で設定されたトンネルは、管理者の負担とすることができます。その場合には、デュアルスタックに背骨の一部をアップグレードする最も簡単な選択かもしれません。管理負担も自動化された管理ツールを使用することによって軽減することができます。
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の型のIPv4トンネリングは、IPv6接続性を取得し、他のIPv6ノードに到達するために必要であることができます。一般的に、構成されたトンネリングをお勧めすることができます。
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の型の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の両方をサポートすることが期待されます。このシナリオでは、UE-GGSN-およびGGSNツーv4NODEにIPv4ノードと通信するエンド・ツー・エンドのIPv4 UEを分割することが有用です。これは、IPv4専用UEは、IPv6ネットワークを介して通信することなく、GGSNに接続するためにIPv4リンク（IPv4のPDPコンテキスト）を使用することを可能にします。
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のインのIPv6のトンネリングは、いずれかの外部のIPv4ネットワークにGGSNから要求されることが想定されていません。長期的に、3GPP事業者は、IPv4のUEとIPv4トランスポートネットワークを段階的に廃止することもできます。これは、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.
したがって、全体として、IPv6ネットワークを通る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の両方のネットワークの管理を必要とし、一つのアプローチは、「レガシー」アプリケーションが当面IPv4を使用しておくことで、エンドツーエンド接続を必要とする新しいアプリケーション（例えば、ピア・ツー・ピア・サービス）の使用IPv6の。 IPv6展開がIPv4との直接通信が（のみの）ノードは例外としないルールとなるように普及しているまで、一般的なガイドラインとして、IPv6のみのUEは、遷移の初期段階では推奨されません。一般的には、UEにおけるデュアルスタックの実装を推奨できるようにIPv4のは、かなり長い時間のために有用残ることが想定されます。この勧告は、自然の代わりに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（のみの）ノードに接続する必要がある場合は、特定の翻訳およびプロキシ技術を使用することが推奨されます。一般的なIPプロトコル変換は推奨されません。 IPv4の（のみの）（第一の場所でこのような通信を避ける除く）ノードと通信するためのIPv6（のみの）ノードのための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.特定用途プロトコルリレーの使用（例えば、IPv6の< - >ポートのカップルのために設定されたIPv4 TCPリレーのみ[RFC3142]）またはアプリケーションプロキシ（例えば、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.
主に電子メールやWebブラウジング：レガシーIPv4ノードは、通常のIPv4インターネットで今日普及しているアプリケーションをサポートするノードです。これらのアプリケーションは、当然のことながら、将来の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から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）UEは、IMS 2）IPv4ネットワークを介して接続された2つのIPv6 IMSを通してIPv4ネットワーク内のノードに接続します
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インターネットノード、またはその逆に接続するとき、このシナリオが発生します。他のノードがIPv4のみの機能で、例えば、3GPP、固定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.
それでも、IPv4ノードは、IMS UEと通信する必要がありますどのように多くの非アップグレードレガシー推定することは困難です。なお、ここで説明するソリューションは、従来の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の高レベルのビューを提供します。著者は、一般的なSIP / SDP /メディアのIPv4 / IPv6移行の問題の詳細なソリューションは、すぐIETFにおけるSIP関連のワーキング・グループ内のタスク、できるだけ指定されることをお勧めします。
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トラフィックの遷移は、二つのレベルで扱わなければなりません。
1. Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface)
1.セッション開始プロトコル（SIP）[RFC3261]、およびセッション記述プロトコル（SDP）[RFC2327]、[RFC3266]（MM-インタフェース）
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インターワーキングのための例示的なセットアップを示します。 「インターワーキングユニット」は、2つの内部要素デュアルスタックSIPサーバとメディアトラフィックのための遷移ゲートウェイ（TRGW）を含みます。これら二つの要素は、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.
INVITEを受信すると、SIPサーバは、IPアドレスとIPv4とIPv6の両方TRGWからポートを予約します。次に、SIPサーバB2BUA（バックツーバックユーザエージェント）として作用し、書き換えのSDP 2つのエンドポイント間のメディアフローの途中に遷移ゲートウェイを挿入するINVITE。
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.
IMSとIPv4ホストの両方に向かってB2BUAの役割、UA（ユーザエージェント）としてSIPサーバの動作を実行します。このため、SIPサーバは、SIPメッセージのRequireヘッダーフィールドにリストされているセッションに適用されるすべての拡張機能を、サポートする必要があります。
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サーバでサポートされている拡張機能によって制限されます。つまり、新しい拡張機能の導入は、ユーザーエージェントが、型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ネットワークによって分離されている場合があります。ここでのUEと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内の他のアプリケーション固有の設定が存在する場合があります。
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.
UE構成はIPv6-またはIPv4ベースのサービスにアクセスするために必要とされます。 GGSNアクセスポイントは、例えば、ウェブブラウジングアプリケーションを使用する際に定義する必要があります。一つの可能性は、GPRSの設定を構成する過剰空気構成[OMA-CP]を使用することです。ユーザは、例えば、オペレータのWWWページを訪問し、彼/彼女のUEにGPRSアクセスポイントの設定をサブスクライブし、ショートメッセージサービス（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コンテキスト起動（制御プレーン機構）で受信することができます。同様のメカニズムは、IPv6のために利用可能である：3GPP [3GPP-24.008]で指定された、いわゆるプロトコル設定オプション情報要素（PCO-IE）。 DNSサーバのアドレスを受信するために[RFC3736]（または[RFC3315]）と[RFC3646]を使用することも可能です。 DNSディスカバリメカニズムのActive IETF作業が進行中であり、時間をかけて利用可能になって他のメカニズムになる可能性があります。 DNSサーバアドレスもUEで手動で空気（使用SMS）[OMA-CP]上で受信または入力することができます。
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
IMSサービスにアクセスする場合、UEは、プロキシ呼セッション制御機能（P-CSCF）IPv6アドレスを知っている必要があります。 3GPP固有PCO-IE機構やDHCPv6のベース機構（[RFC3736]及び[RFC3319]）のいずれかを使用することができます。手動設定や構成を超えます
the air is also possible. IMS subscriber authentication and registration to the IMS and SIP integrity protection are not discussed here.
空気も可能です。 IMSおよびSIP完全性保護へのIMS加入者認証と登録は、ここで議論されていません。
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つのGPRSおよび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.
- デュアルスタックのUEは、IPv4のみまたはIPv6- UEのみの代わりに推奨されています。 UE内のアプリケーションがIPv6をサポートして世話をすることが重要です。つまり、アプリケーションは、IPバージョン独立していなければなりません。 IPv6のみのIPv6が広くネットワークに配置されたとき、UEは、可能になることができ、そしてほとんどのサービスは、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.
- IPv4のピア・ノードと通信するときのIPv6ピア・ノードとIPv4 PDPコンテキストとの通信時のIPv6 PDPコンテキストをアクティブにすることが推奨されます。
- IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node.
- IPv6通信は、同じデュアルスタックピア・ノードへのIPv4 NATを経由するのIPv4通信に好適です。
- 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サポートを展開することをお勧めします。それは、UEでのトランジション効果を軽減することが可能となります。
- 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.
- UEにおけるトンネリングメカニズムは、IPv6移行プロセスの初期段階の間に必要とされるかもしれません。軽量、自動トンネリングメカニズムは、IETFで標準化されなければなりません。詳細については、[ゼロ設定]を参照してください。
- 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.
- 著者らは、一般的なSIP / SDP /メディアのIPv4 / IPv6への移行の問題の詳細なソリューションはIETFにおけるSIP関連ワーキンググループ内のタスクとして、できるだけ早く指定することをお勧めします。
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導入は1つが[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のみのUEからのIPv4（のみの）ノードに到達するために、特定の目的のプロトコルリレーとアプリケーションプロキシを導入し、または使用
- 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.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmarkと、E.、 "ステートレス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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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.ギリガン、 "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.
"SIP及びSDPに基づいたIPマルチメディア呼制御のフローをシグナリング、ステージ3（リリース5）" [3GPP-24.228] 3GPP TS 24.228 V5.3.0、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]ハンドリー、M.および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]萩野、J.及びK.山本の "IPv6からIPv4輸送リレー翻訳"、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]オルソン、S.、カマリロ、G.、およびA.ローチ、 "セッション記述プロトコル（SDP）におけるIPv6のサポート"、RFC 3266、2002年6月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]ワッサーマン、M.、RFC 3314、2002年9月、 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための提言"。
[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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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.フォルツ、RFC 3319、2003年7月 "セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPv6）オプション"。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] Droms、R.、RFC 3646、2003年12月の "IPv6のための動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。
[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]デュラン、A.とJ.のあなた、 "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]リンド、M.、Ksinant、V.、公園、S.、ボドー、A.、およびP. Savola、 "ISPネットワークにIPv6を導入するためのシナリオと分析"、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]キャマリロ、G.およびJ.ローゼンバーグ、RFC 4091、2005年6月 "セッション記述プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス"。
[ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, September 2005.
[ISATAP]テンプリン、F.、グリーソン、T.、Talwar、M.、およびD.ターレル、 "イントラサイト自動トンネルプロトコル（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.、シバクマー、S.、Barany、P.、岡崎、S.およびH.王、 "NAT-PTの適用"、進歩、2003年10月に作業。
[NATPTexp] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", Work in Progress, July 2005.
[NATPTexp]アウン、C.およびE.デイヴィス、 "実験的に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.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、進歩、2004年4月に作業。
[STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress, January 2004.
[STEP] Savola、P： "シンプルIPv6のインのIPv4トンネルの確立手順（STEP）"、進歩、2004年1月での作業。
[V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security Considerations", Work in Progress, February 2004.
[V6SEC] Savola、P： "IPv6移行/共存のセキュリティの考慮事項"、進歩、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]ニールセン、K.、モレーリ、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、オープン・モバイル・アライアンス、12 - 11月 - 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).
ペッカSavolaは、本文書にテキストと彼のIPv6経験の両方に貢献しています。彼はメーリングリストv6ops上の有益なコメントを多数提供してきました。アリソンマンキンは、IMSシナリオ1（4.1節）のテキストを貢献してきました。
This document was written by:
この文書は、によって書かれました：
Alain Durand, Comcast <alain_durand@cable.comcast.com>
アラン・デュラン、コムキャスト<alain_durand@cable.comcast.com>
Karim El-Malki, Ericsson Radio Systems <Karim.El-Malki@era.ericsson.se>
カリム・エルMalki、Eritsssonラジオシステムズ<Карим.Ел-Малки@ера.ерицссон.се>
Niall Richard Murphy, Enigma Consulting Limited <niallm@enigma.ie>
ニールリチャード・マーフィー、エニグマコンサルティング株式会社<niallm@enigma.ie>
Hugh Shieh, AT&T Wireless <hugh.shieh@attws.com>
ヒューShieh、AT＆Tワイヤレス<hugh.shieh@attws.com>
Jonne Soininen, Nokia <jonne.soininen@nokia.com>
Jonne Soininen、ノキア<jonne.soininen@nokia.com>
Hesham Soliman, Flarion <h.soliman@flarion.com>
ヒシャムスレイマン、フライヤー<ه.سليمان@فلير.كوم>
Margaret Wasserman, ThingMagic <margaret@thingmagic.com>
マーガレットワッサーマン、ThingMagic <margaret@thingmagic.com>
Juha Wiljakka, Nokia <juha.wiljakka@nokia.com>
ユハWiljakka、ノキア<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.
著者はヘイッキAlmay、ガボールBajko、ゴンサロ・カマリロ、アジャイジャイナ教、ヤルコJouppi、デビッドKessens、イワンLaloux、アリソンマンキン、Jasminko Mulahusic、ヤンネリンネ、アンドレアス・シュミット、ペドロ・セルナ、フレッド・テンプリン、アナンドタクール、およびロッドに感謝したいと思います彼らの貴重な入力のためのヴァンメーター。
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の外部インタフェース（GI）、典型的には、GGSNから分離に配置する必要があります。 NAPT-PTは、オペレータのネットワークのエッジ及び公衆インターネット上で、例えば、インストールすることができます。 NAPT-PTは、そのIPv4インタフェースを介して、DNS要求とそのペイロードにIPアドレスを含む他のアプリケーションをインターセプト（必要に応じて、いくつかの用途のため及びペイロード）IPヘッダを変換し、パケットを転送します。
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.（ "IPv6のIPv4のに" 場合）NAPT-PTノードからDNS ALGを分離。
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
ユハWiljakkaノキアビジョンストリート3 FIN-33720 TAMPERE、フィンランド
Phone: +358 7180 48372 EMail: juha.wiljakka@nokia.com
電話：+358 7180 48372電子メール：juha.wiljakka@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。