RFC4215 日本語訳
4215 Analysis on IPv6 Transition in Third Generation PartnershipProject (3GPP) Networks. J. Wiljakka, Ed.. October 2005. (Format: TXT=52903 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Wiljakka, Ed. Request for Comments: 4215 Nokia Category: Informational October 2005
ワーキンググループJ.Wiljakka、エドをネットワークでつないでください。コメントのために以下を要求してください。 4215年のノキアカテゴリ: 情報の2005年10月
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)インターネット協会(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.
このドキュメントはThird Generation Partnership Project(3GPP)パケット網でIPv6への変遷を分析します。 これらのネットワークは汎用パケット無線システム(GPRS)技術に基づいています、そして、ラジオネットワークアーキテクチャは汎欧州デジタルセルラーシステム(GSM)かUniversalのモバイルTelecommunications System(UMTS)/W-CDMA方式(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.
焦点が異なった変遷シナリオと適切な変遷メカニズムを分析して、それらの変遷シナリオに関してソリューションを見つけるところにあります。 これらのシナリオでは、User Equipment(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
1. 序論…2 1.1. このドキュメントの範囲…3 1.2. 略語…3 1.3. 用語…5 2. 変遷メカニズムとDNSガイドライン…5 2.1. デュアルスタック…5 2.2. トンネリング…6 2.3. 翻訳者について議定書の中で述べてください…6 2.4. IPv4/IPv6変遷のためのDNSガイドライン…6 3. GPRS変遷シナリオ…7 3.1. IPv4とIPv6ノードとのデュアルスタックUE接続…7 3.2. IPv4ネットワークを通したIPv6ノードとのIPv6 UE接続…8
Wiljakka Informational [Page 1] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[1ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
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
3.2.1. 3GPPオペレータのネットワークの中でトンネルを堀ります…9 3.2.2. 3GPPオペレータのネットワークの外でトンネルを堀ります…10 3.3. IPv6ネットワークを通したIPv4ノードとのIPv4 UE接続…10 3.4. IPv4ノードとのIPv6 UE接続…11 3.5. IPv6ノードとのIPv4 UE接続…12 4. IMS変遷シナリオ…12 4.1. IMSを通してIPv4ネットワークでノードに接続するUE…12 4.2. IPv4 Networkを通した2IPv6 IMS Connected…15 5. 3GPP UE IPv4/IPv6構成に関して…15 6. 概要と推薦…16 7. セキュリティ問題…17 8. 参照…17 8.1. 標準の参照…17 8.2. 有益な参照…18 9. 貢献者…20 10. 作者と承認…20
1. Introduction
1. 序論
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.
このドキュメントは、Third Generation Partnership Project(3GPP)汎用パケット無線システム(GPRS)パケット網[3GPP-23.060]でIPv6に移行へのプロセスを説明して、分析します、ラジオネットワークアーキテクチャが汎欧州デジタルセルラーシステム(GSM)かUniversalのモバイルTelecommunications System(UMTS)/W-CDMA方式(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].
本書では分析されたシナリオは2つのカテゴリに分割されます: 本書ではGPRSシナリオと呼ばれた汎用パケットサービスシナリオ、およびIP Multimedia Subsystem(IMS)シナリオ。(そのシナリオはSession Initiationプロトコル(SIP)問題を含んでいます)。 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
- IPv6ノード--IPv4ネットワークを通してIPv6ノードに接続するIPv6 UE--IPv4とIPv6ネットワークを通してIPv4ノードに接続するIPv4 UEに接続する二元的なStack User Equipment(UE)--IPv4ノードに接続するIPv6 UE
Wiljakka Informational [Page 2] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[2ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
- IPv4 UE connecting to an IPv6 node
- IPv6ノードに接続する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ネットワークを通して接続された2IPv6 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.
焦点が異なった変遷シナリオと適切な変遷メカニズムを分析して、それらの変遷シナリオに関してソリューションを見つけるところにあります。 シナリオでは、User Equipment(UE)は他のネットワークでノードに接続します、例えば、インターネットで、そして、IPv6/IPv4変遷メカニズムが必要です。
1.1. Scope of This Document
1.1. このドキュメントの範囲
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 Multimedia Core Network Subsystem(IMS)の使用のあるなしにかかわらずシナリオをカバーしています。 このドキュメントはラジオインタフェース詳細問題に焦点を合わせません。 3GPP SecondとThird Generationラジオネットワークアーキテクチャ(GSM、Enhanced DataはGSM Evolution(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 Working Groupsによって指定された変遷メカニズムは使用されるものとします。 このメモは、どんな新しい変遷メカニズムも指定しませんが、新しいものの必要性を記録するだけです(適切であるなら)。
1.2. Abbreviations
1.2. 略語
2G Second Generation Mobile Telecommunications, e.g., GSM
and GPRS technologies
2G第2GenerationのモバイルTelecommunications、例えば、GSMとGPRS技術
3G Third Generation Mobile Telecommunications, e.g., UMTS
technology
3G第3GenerationのモバイルTelecommunications、例えば、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について言及する論理的な名前と外部のネットワークです。
Wiljakka Informational [Page 3] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[3ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
B2BUA Back-to-Back User Agent
B2BUA背中合わせのユーザエージェント
CSCF Call Session Control Function (in 3GPP Release 5 IMS)
CSCF呼び出しセッション制御機能(3GPPリリース5IMSの)
DNS Domain Name System
DNSドメインネームシステム
EDGE Enhanced Data rates for GSM Evolution
GSM EvolutionのEDGE Enhanced Dataレート
GGSN Gateway GPRS Support Node (default router for 3GPP User
Equipment)
GGSNゲートウェイGPRSサポートノード(3GPP User Equipmentのためのデフォルトルータ)
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 Multimedia(コアNetwork)サブシステム、ネットワークの3GPP Release5IPv6だけ部分
ISP Internet Service Provider
ISPインターネットサービスプロバイダ
NAT Network Address Translation
NATネットワークアドレス変換
NAPT-PT Network Address Port Translation - Protocol Translation
太平洋標準時のNAPTナプト--プロトコル変換
NAT-PT Network Address Translation - Protocol Translation
太平洋標準時のNATネットワークアドレス変換--プロトコル変換
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
一口セッション開始プロトコル
UE User Equipment, e.g., a UMTS mobile handset
UE User Equipment、例えば、UMTS移動体端末
UMTS Universal Mobile Telecommunications System
UMTSの普遍的な移動体通信システム
WCDMA Wideband Code Division Multiple Access
WCDMA W-CDMA方式
Wiljakka Informational [Page 4] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[4ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
1.3. Terminology
1.3. 用語
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.
二元的なStack UE Dual Stack UEはIPv4とIPv6スタックの両方がある3GPP移動体端末です。 それはIPv4とIPv6 Packet Dataプロトコル(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.
UEがコミュニケートしているIPv4できるノードになるように定義されて、IPv4ノード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.
UEがコミュニケートしているIPv6できるノードになるように定義されて、IPv6ノード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 Context Packet Dataプロトコル(PDP)文脈はUEとGGSNの間との接続です。そこでは、パケットがわたっています。 現在、3つのPDPタイプがあります: IPv4、IPv6、およびppp。
2. Transition Mechanisms and DNS Guidelines
2. 変遷メカニズムとDNSガイドライン
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推薦を与えます。 セクション3と4で3GPPネットワークへの異なった変遷メカニズムの適用性について議論します。
2.1. Dual Stack
2.1. デュアルスタック
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
二元的なIPv4/IPv6スタックは[RFC4213]で指定されます。 私たちが3GPP GPRSコアネットワークを考えるなら、ゲートウェイGPRS Support Node(GGSN)のデュアルスタック実装はIPv4のサポートとIPv6 PDP文脈を可能にします。 デュアルスタックがあるUEsと公共(グローバルな)のIPアドレスはそうすることができます。
Wiljakka Informational [Page 5] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[5ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
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サービスの両方に通常アクセスしてください。 しかしながら、個人的なIPv4アドレスとNATs[RFC2663]が使用されて、モバイルネットワークに使用されるつもりであったのを覚えているのは十分です。 また、公共の、または、グローバルなIPアドレスがピアツーピアサービスに必要です: ノードは他のノードに目に見える公共の、または、グローバルなIPアドレスを必要とします。
2.2. Tunneling
2.2. トンネリング
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.
トンネリングはカプセル化してノードをdecapsulatingする際に二元的なIPv4/IPv6スタックの機能性を必要とする変遷メカニズムです。 基本的なトンネリング選択肢は、IPv4のIPv6とIPv6のIPv4です。
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リンクです。
2.3. Protocol Translators
2.3. プロトコル翻訳者
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パケットのヘッダーに変換されるか、逆もまた同様です、必要なら、チェックサムは、調整されるか、または再計算されます。 Stateless IP/ICMP Translation[RFC2765]を使用する太平洋標準時のNAT(ネットワークAddress Translation/プロトコルTranslation)[RFC2766]はそのようなメカニズムに関する例です。
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プロキシを使用する)、または応用層で行われることができます(アプリケーションリレーを使用して)。
2.4. DNS Guidelines for IPv4/IPv6 Transition
2.4. IPv4/IPv6変遷のためのDNSガイドライン
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可能にした1つを保って、再帰的なDNSサーバがIPv4をサポートするのを保証することです。 詳しい情報に関してDNS IPv6輸送ガイドライン[RFC3901]を見てください。
Wiljakka Informational [Page 6] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[6ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
3. GPRS Transition Scenarios
3. GPRS変遷シナリオ
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がサービスか他のノード(例えば、インターネットのウェブサーバー)に連絡するとき起こるかもしれないシナリオについて論じます。
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の少なくとも1つのルータがあるネットワークの一部です、そして、UEは異なったネットワークでノードに接続しています。
1) Dual Stack UE connecting to IPv4 and IPv6 nodes
1) IPv4とIPv6ノードに接続する二元的なStack UE
2) IPv6 UE connecting to an IPv6 node through an IPv4 network
2) IPv4ネットワークを通してIPv6ノードに接続するIPv6 UE
3) IPv4 UE connecting to an IPv4 node through an IPv6 network
3) IPv6ネットワークを通してIPv4ノードに接続するIPv4 UE
4) IPv6 UE connecting to an IPv4 node
4) IPv4ノードに接続するIPv6 UE
5) IPv4 UE connecting to an IPv6 node
5) IPv6ノードに接続するIPv4 UE
3.1. Dual Stack UE Connecting to IPv4 and IPv6 Nodes
3.1. 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 implementers、アプリケーション開発者、およびオペレータはPDP文脈起動方針を決めさせられます。 1つの議論された可能性はあらかじめIPv4とPDP文脈のIPv6タイプの両方を動かすことです、PDP文脈の起動が通常ある程度時間がかかっているので。 しかしながら、それはたぶんネットワーク資源の良い使用法ではありません。 概して、それが、IPv4のIPv6トンネリングがネットワークで必要であることを(その他の詳細に関してセクション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
UEはデュアルスタックですが、UEは気付くとServing GPRS Support Node(SGSN)、GGSN、およびホームLocation Register(HLR)がIPv4 PDPに文脈をサポートする3GPPネットワークに付けられているかもしれませんが、IPv6 PDPに文脈をサポートしないでください。 これはIPv6展開の早めのフェーズで起こるかもしれません、またはUEがそうしたのでIPv6をサポートする3GPPネットワークからそうしないものまで「移動されて」。 3GPPネットワークがIPv6 PDPに文脈をサポートしないで、UEにおけるアプリケーションが、サポートする必要があるなら
Wiljakka Informational [Page 7] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[7ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
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.
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アドレスが使用されるかもしれないトンネリングメカニズムと展開シナリオがあるか、またはトンネリングメカニズムはIPv4NATを終えます。
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自身でトンネルを堀りながらIPv4のIPv6を実行して、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がサポートであると配布することを強く勧めます。 それで、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 NATsに直面している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アドレスの使用はNATsの使用を意味します。 大きいネットワークでは、NATシステムは非常に複雑で、高価で、維持するのが難しくなることができます。
3.2. IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
3.2. IPv4ネットワークを通してIPv6ノードに接続するIPv6 UE
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
トンネリングでこのシナリオのための最も良いソリューションを得ます。 すなわち、IPv4のIPv6トンネリングは要件です。 IPv6 PDP文脈はUEとGGSNの間で活性化します。 IPv6 UEにはトンネリングに必要であるデュアルスタックの機能性がないので、トンネリングはネットワークで扱われます。 そして要約ノードがGGSNであるかもしれなく、間の縁のルータがオペレータのIPv6ネットワークの境界である。
Wiljakka Informational [Page 8] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[8ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
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.
公共のインターネット、またはオペレータの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島の間のIPv4のIPv6トンネルは、静的であるか、またはダイナミックである場合があります。 トンネリングメカニズムのタイプの選択はオペレータ/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自体です。 IPv6へのISPネットワークの変遷は[RFC4029]で分析されます。
3.2.1. Tunneling Inside the 3GPP Operator's Network
3.2.1. 3GPPオペレータのネットワークの中でトンネルを堀ること。
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に通常配布しました。 変遷の第1段階でかなりまれであると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のIPv6トンネルが3GPPオペレータのIPv4ネットワークの上にIPv6島をつなげるのに必要であるところで手動で構成されたトンネルは使用できます。 3GPPネットワークでは、別の島がオペレータのIPv6アプリケーション・サーバーを含むことができる間、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ルーティング・プロトコルの使用などのように。
Wiljakka Informational [Page 9] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[9ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
3.2.2. Tunneling Outside the 3GPP Operator's Network
3.2.2. 3GPPオペレータのネットワークの外でトンネルを堀ること。
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.
この小区分はオペレータのネットワークの外に同輩ノードがある場合を含んでいます。 その場合、IPv4のIPv6トンネリングが、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をサポートします。 次に、3GPPオペレータはどんなトンネルも構成する必要はありません、上流のISPがルーティングIPv6パケットの世話をするので。 上流のISPがIPv6の接続性を提供しないなら、IPv4のIPv6トンネルは構成されるべきです、例えば境界ルータからIPv6の接続性を提供している別のISPによって操作されたデュアルスタック境界ゲートウェイまで。
3.3. IPv4 UE Connecting to an IPv4 Node through an IPv6 Network
3.3. IPv6ネットワークを通してIPv4ノードに接続するIPv4 UE
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をGGSNへのUEとv4NODEへのGGSNへのIPv4ノードコミュニケーションに分割するのは役に立ちます。 これで、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だけをサポートして、デュアルスタックにわたるでしょう、これらのネットワークが既に配布されるので。 したがって、IPv6のIPv4のトンネリングがGGSNから外部のIPv4ネットワークまで必要であることが考えられません。 より長い走行では、3GPPオペレータは、IPv4 UEsとIPv4転送ネットワークを段階的に廃止するのを選ぶかもしれません。 これはIPv6 UEsだけを残すでしょう。
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ネットワークで非常にありそうであると考えられません。
Wiljakka Informational [Page 10] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[10ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
3.4. IPv6 UE Connecting to an IPv4 Node
3.4. IPv4ノードに接続するIPv6 UE
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の上で利用されるのを必要とするでしょう、そして、概して、IPv6だけUEsは管理するのが、より簡単であるかもしれませんが、IPv6の普遍的な展開は近い将来、たぶん現実的ではありません。 デュアルスタック実装はIPv4とIPv6ネットワークの両方を管理に要求します、そして、1つのアプローチは「レガシー」アプリケーションが予見できる未来にIPv4を使用し続けて、終わりまでの終わりの接続性(例えば、ピアツーピアサービス)を必要とする新しいアプリケーションがIPv6を使用するということです。 一般的ガイドラインとして、IPv6展開がIPv4(-単に)ノードとのダイレクトコミュニケーションが規則ではなく、例外になるほど一般的になるまで、IPv6だけUEsは変遷の早めのフェーズで推薦されません。 IPv4がかなり長い時間の役に立ったままで残ると思われて、一般に、UEのデュアルスタック実装を推薦できます。 この推薦は、IPv4だけUEsの代わりにデュアルスタックUEsを製造しているのを自然に含んでいます。
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(-単に)ノードに接続する必要があれば、特定の翻訳とproxyingのテクニックを使用するのはお勧めです。 ジェネリックIPプロトコル変換は推薦されません。 3つの主な方法で、コミュニケートするIPv6(-単に)ノードのために、IPv4(-単に)ノード(第一にそのようなコミュニケーションを避けることを除いた)があります:
1. the use of generic-purpose translator (e.g., NAT-PT [RFC2766])
in the local network (not recommended as a general solution),
1. 企業内情報通信網(一般解として、推薦されない)におけるジェネリック目的翻訳者(例えば、太平洋標準時のNAT[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. 明確な目標プロトコルの使用が企業内情報通信網で(例えばIPv4 TCPリレーが2、3のポートだけに構成したIPv6<->[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 UEsでこれらのプロキシを構成するのに使用されるべきです。 例えば、GGSNの外部のインタフェース(「兵士」の)の上、または、サービスネットワークの中にアプリケーションプロキシを置くことができます。
Wiljakka Informational [Page 11] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[11ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
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の適用性について議論することに注意します、そして、[NATPTexp]はすべての形式に関するIPv6-IPv4翻訳の一般答弁について議論します。 3GPPネットワークで太平洋標準時のNAT用法に関連する問題はAppendix Aに記録されます。
3.5. IPv4 UE Connecting to an IPv6 Node
3.5. IPv6ノードに接続するIPv4 UE
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インターネットでポピュラーなアプリケーションを支えるノードです: ほとんど電子メールとウェブ閲覧。 これらのアプリケーションはもちろん将来のIPv6インターネットでサポートされるでしょう。 しかしながら、将来のアプリケーションをサポートするためにレガシーIPv4 UEsをアップデートしないでしょう。 これらのアプリケーションが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 UEからのトラフィックはいくつかのアプリケーションに制限されます。 これらのアプリケーションは、プライベート・アドレス宇宙ネットワークとインターネットの間で交信するために既にプロキシかローカルサーバをほとんど当てにします。 IPv4からIPv6への変遷に同じメソッドと技術を使用できます。
4. IMS Transition Scenarios
4. IMS変遷シナリオ
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) IMS2)を通してIPv4ネットワークでノードに接続するUE IPv4ネットワークを通して接続された2IPv6 IMS
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だけ自然と共に中ではありません。
4.1. UE Connecting to a Node in an IPv4 Network through IMS
4.1. IMSを通してIPv4ネットワークでノードに接続するUE
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より異系統の一部であるときに、これは起こります、例えば、固定PC、IPv4能力だけで。
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ノードをデュアルスタックにアップグレードさせるでしょう、しばしば全体のノードを置き換えることによって、その特定の展開におけるこの特定の問題を解決して。
Wiljakka Informational [Page 12] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[12ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
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 UEsとコミュニケートするといくつの非アップグレード可能レガシー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のアプリケーションの多くのために、ある種の翻訳者が、IPv6 IMSとレガシーIPv4ホストとのコミュニケーションでこれらのレガシー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関連のWorking Groupsの中で指定されることを勧めます。
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呼び出しで切り離されます、そして、その結果、2つのレベルでIMS(IMSトラフィックのIPv6からIPv4までの変遷)を扱わなければなりません:
1. Session Initiation Protocol (SIP) [RFC3261], and Session
Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface)
1. セッション開始プロトコル(一口)[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の織り込む例のセットアップを示しています。「織り込むユニット」はメディアトラフィックのために2つの内部の要素デュアルスタックSIPサーバと変遷ゲートウェイ(TrGW)を包括します。 これらの2つの要素が、SIPシグナリングとメディアトラフィックを織り込むことを連動させるようにインタコネクトされます。
Wiljakka Informational [Page 13] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[13ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
+-------------------------------+ +------------+
| +------+ | | +--------+ |
| |S-CSCF|---| |SIP Serv| |\
| | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------
| |-----------------------------------|| TrGW ||/
+--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+
+-------------------------------+ +------------+ | +------+ | | +--------+ | | |S-CSCF|---| |一口Serv| |\ | | +------+ | | +--------+ | \ -------- +-|+ | / | | | | | | | | | +------+ +------+ | | + | -| |- | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | | +------+ +------+ | |+----------+| / ------ | |-----------------------------------|| TrGW||/ +--+ | IPv6| |+----------+| IPv4 UE| | |織り込むこと| | IPマルチメディアCNサブシステム| |ユニット| +-------------------------------+ +------------+
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サーバはIPv4とIPv6のためにTrGWからIPアドレスとポートを予約します。 次に、SIPサーバは、B2BUA(支持するために戻っているUserエージェント)として機能して、2つの終点の間のメディア流動の中央の変遷ゲートウェイを挿入するためにINVITEのSDPを書き直します。
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サーバはUA(ユーザエージェント)としてIMSとIPv4ホストの両方に向かって機能します。 その結果、SIPサーバは、セッションに適用して、Requireに記載されているすべての拡大に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だけではなく、また、B2BUAsもアップグレードさせるのを必要とします。
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.
B2BUAsの使用に関連する問題を考えて、SIP関連のWorking Groupsがこのアプローチの欠点に打ち勝つためにすぐにソリューションに取り組むのは、お勧めです。
Wiljakka Informational [Page 14] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[14ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
4.2. Two IPv6 IMS Connected via an IPv4 Network
4.2. IPv4 Networkを通した2IPv6 IMS Connected
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の上の島がネットワークでつなぐ2IPv6だけIMSの間の接続を作ることです。 このシナリオは密接にセクション3.2に表されたGPRSシナリオに関連します、そして、同様のトンネリングソリューションはこのシナリオでも適切です。
5. About 3GPP UE IPv4/IPv6 Configuration
5. 3GPP UE IPv4/IPv6構成に関して
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 Access Pointは定義されなければなりません。 使用には1つの可能性がある、過剰、空気、GPRS設定を構成する構成[OMA-CP]。 ユーザは、例えば、オペレータWWWページを見て、その人のUEにGPRS Access Point設定を申し込んで、Short Message Service(SMS)を通して設定を受けることができます。 ユーザが設定を受け入れて、PDP文脈が活性化した後に、その人は、ブラウズし始めることができます。 Access Point設定をまた、手動でタイプするか、またはオペレータか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文脈の場合では、PDP文脈起動(制御飛行機メカニズム)で(IPv4)DNSサーバアドレスを受け取ることができます。 また、同様のメカニズムもIPv6に利用可能です: 3GPP[3GPP-24.008]でそのように呼ばれたプロトコルConfiguration Options情報Element(PCO-IE)は指定しました。 また、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
IMSサービスにアクセスするとき、UEは、Proxy-呼び出しSession Control Function(P-CSCF)IPv6アドレスを知る必要があります。 3GPPの特定のPCO-IEメカニズムかDHCPv6ベースのメカニズム([RFC3736]と[RFC3319])のどちらかを使用できます。 手動の構成か構成、終わっている。
Wiljakka Informational [Page 15] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[15ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
the air is also possible. IMS subscriber authentication and registration to the IMS and SIP integrity protection are not discussed here.
また、空気も可能です。 ここでIMSとSIP保全保護へのIMS加入者認証と登録について議論しません。
6. Summary and Recommendations
6. 概要と推薦
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:
このドキュメントは5GPRSと2つのIMS IPv6変遷シナリオを分析しました。 多数の3GPPネットワークは今日個人的なIPv4アドレスを使用しています、そして、IPv6を導入するのは重要です。 2/1の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.
- デュアルスタックUEsはIPv4だけかIPv6だけUEsの代わりにお勧めです。 UEsのアプリケーションがIPv6をサポートすることに注意するのは重要です。 言い換えれば、アプリケーションはIPバージョン独立者であるべきです。 IPv6がネットワークで広く配布されるとき、IPv6だけUEsは可能になることができます、そして、ほとんどのサービスが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 NATsに直面している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がサポートであると配布することを強く勧めます。 それで、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.
- UEのトンネリングメカニズムがIPv6変遷プロセスの早めの段階の間、必要であるかもしれません。 軽量の、そして、自動であるトンネリングメカニズムは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.
- 作者は、一般的なSIP/SDP/メディアIPv4/IPv6変遷問題のための詳細なソリューションができるだけ早くタスクとしてIETFのSIP関連のWorking Groupsの中で指定されることを勧めます。
Wiljakka Informational [Page 16] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[16ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
7. Security Considerations
7. セキュリティ問題
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だけUEsからの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か他の翻訳者
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E.、「状態がないIP/ICMP変換アルゴリズム(SIIT)」、RFC2765、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)について議定書の中で述べてください」、RFC2766、2000年2月。
Wiljakka Informational [Page 17] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[17ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks",
RFC 3574, August 2003.
[RFC3574] Soininen、J.、「3GPPネットワークのための変遷シナリオ」、RFC3574、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ホストとルータのための基本的な変遷メカニズム」、RFC4213、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 t23.060V5.4.0、「汎用パケット無線システム(GPRS)」。 記述を修理してください。 2002年12月の「ステージ2(リリース5)。」
[3GPP-23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements
(Release 5)", December 2002.
[3GPP-23.221]3GPP TS23.221V5.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 t23.228V5.7.0、「IPマルチメディアサブシステム(IMS)」。 2002年12月の「ステージ2(リリース5)。」
[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 TS24.228V5.3.0、「合図はSIPとSDPに基づくIPマルチメディア呼び出しコントロールのために流れます」。 2002年12月の「ステージ3(リリース5)。」
[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 TS24.229V5.3.0と、「IPのSIPに基づくMultimedia Call ControlプロトコルとSDP」。 2002年12月の「ステージ3(リリース5)。」
8.2. Informative References
8.2. 有益な参照
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC2327] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
Relay Translator", RFC 3142, June 2001.
[RFC3142]HaginoとJ.とK.山本、「IPv6からIPv4への輸送リレー翻訳者」(RFC3142)2001年6月。
[RFC3266] Olson, S., Camarillo, G., and A. Roach, "Support for
IPv6 in Session Description Protocol (SDP)", RFC 3266,
June 2002.
オルソン、S.、キャマリロ、G.、およびA.ローチが「IPv6のためにセッション記述プロトコル(SDP)でサポートする」[RFC3266]、RFC3266、2002年6月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", RFC
3314, September 2002.
[RFC3314]ワッサーマン、M.、「第三世代パートナーシッププロジェクト(3GPP)規格におけるIPv6のための推薦」、RFC3314、2002年9月。
Wiljakka Informational [Page 18] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[18ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
[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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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.フォルツ、「セッション開始のためのDynamic Host Configuration Protocol(DHCPv6)オプションは(一口)サーバについて議定書の中で述べます」、RFC3319、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)のためのDynamic Host Configuration ProtocolのためのDNS Configurationオプション」、RFC3646、2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736, April
2004.
[RFC3736] Droms、R.「(DHCP)がIPv6"、RFC3736年のために修理する状態がないダイナミックなホスト構成プロトコル、2004年4月」。
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport
Operational Guidelines", BCP 91, RFC 3901, September
2004.
[RFC3901] ジュランドとA.とJ.Ihren、「DNS IPv6輸送運用指針」、BCP91、RFC3901、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.、Baudot、A.、およびP.Savola、「ISPネットワークにIPv6を取り入れるためのシナリオと分析」(RFC4029)は2005を行進させます。
[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.ローゼンバーグ、「代替のネットワーク・アドレスはセッション記述プロトコル(SDP)組分けフレームワークのために(ANAT)意味論をタイプします」、RFC4091、2005年6月。
[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)」、RFC4214、2005年9月。
[NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.
and H. Wang, "NAT-PT Applicability", Work in Progress,
October 2003.
[NATPTappl] 「太平洋標準時のNATの適用性」というSatapati、S.、Sivakumar、S.、バラニー、P.、岡崎、S.、およびH.ワングは進歩、2003年10月に働いています。
[NATPTexp] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", Work in Progress, July 2005.
[NATPTexp] 「太平洋標準時のNATを実験的に動かす理由」というAoun、C.、およびE.デイヴィースは進歩、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.
[ステップ]Savola、P.: 「簡単なIPv4のIPv6トンネル設立手順(ステップ)」、処理中の作業、2004年1月。
Wiljakka Informational [Page 19] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[19ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
[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.、殻、J.、J.、およびJ.Wiljakka、「3GPPの無構成トンネリングの目標」というSoininenは進行中(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 TS24.008V5.8.0、「移動無線インタフェースLayer3仕様」。 コアネットワーク・プロトコル。 2003年6月の「ステージ3(リリース5)。」
[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-20021112C、モバイル同盟、2002年11月12日を開いてください。
9. Contributors
9. 貢献者
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 Scenario1(セクション4.1)のためにテキストを寄付しました。
10. Authors and Acknowledgements
10. 作者と承認
This document was written by:
このドキュメントは以下によって書かれました。
Alain Durand, Comcast
<alain_durand@cable.comcast.com>
アラン・ジュランド、 Comcast <alain_durand@cable.comcast.com 、gt。
Karim El-Malki, Ericsson Radio Systems
<Karim.El-Malki@era.ericsson.se>
カリム高架鉄道-Malki、エリクソンラジオ Systems <Karim.El-Malki@era.ericsson.se 、gt。
Niall Richard Murphy, Enigma Consulting Limited
<niallm@enigma.ie>
ニオール・リチャード・マーフィー、謎のコンサルティング Limited <niallm@enigma.ie 、gt。
Hugh Shieh, AT&T Wireless
<hugh.shieh@attws.com>
ヒューShieh、AT&T Wireless <hugh.shieh@attws.com 、gt。
Jonne Soininen, Nokia
<jonne.soininen@nokia.com>
Jonne Soininen、 Nokia <jonne.soininen@nokia.com 、gt。
Hesham Soliman, Flarion
<h.soliman@flarion.com>
Heshamソリマン、 Flarion <h.soliman@flarion.com 、gt。
Wiljakka Informational [Page 20] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[20ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
Margaret Wasserman, ThingMagic
<margaret@thingmagic.com>
マーガレット・ワッサーマン、 ThingMagic <margaret@thingmagic.com 、gt。
Juha Wiljakka, Nokia
<juha.wiljakka@nokia.com>
ユハWiljakka、 Nokia <juha.wiljakka@nokia.com 、gt。
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.
作者は彼らの貴重な入力についてHeikkiアルメイ、ガボールBajko、ゴンサロ・キャマリロ、ジャイナ教のAjayヤルッコJouppi、デヴィッドKessens、イワン・ラルー、アリソン・マンキン、Jasminko Mulahusic、ヤンネ・リンネ、アンドレアス・シュミッド、ペドロ・セルナ、フレッド・テンプリン、アナンド・タークル、およびRodヴァンMeterに感謝したがっています。
Wiljakka Informational [Page 21] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[21ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
Appendix A - On the Use of Generic Translators in the 3GPP Networks
3GPPネットワークにおけるジェネリック翻訳者の使用での付録A
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)にとって、必要な特徴である傾向があります。 太平洋標準時のNAPTが使用されているなら、それは、(兵士)の、そして、GGSNから通常別々のGGSN外部のインタフェースに置かれる必要があります。 例えば、オペレータのネットワークの縁と公共のインターネットに太平洋標準時のNAPTをインストールできます。 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は3GPPアーキテクチャの中で拡大されると予想される制限を導入します。 [NATPTappl]はさらに詳細に太平洋標準時のNATの適用性について議論します。 [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の外部のインタフェースでの1ポイントの失敗は総合的なネットワークの信頼性に関心を高めるでしょう。 さらに、IPv6ユーザがIMSによって提供された遅れ敏感な利用を使用すると予想されます。したがって、IPバックボーンの中で推進遅れを最小にする必要があります。 その上、デフォルトルータ(GGSN)によって3GPPネットワークで扱われた接続の空前の数のため、トラフィックがネットワーク(典型的な太平洋標準時のNAPT構成)の縁でやむを得ずただ一つのノードを調べるネットワークデザインは比例しそうにはありません。 変換メカニズムは複数の翻訳者、負荷分割法と冗長のために目的を許容するはずです。
To minimize the problems associated with NAPT-PT, the following actions can be recommended:
太平洋標準時のNAPTに関連している問題を最小にするために、以下の動作を推薦できます:
1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to
IPv4" case).
1. 中、太平洋標準時のNAPTノードとDNS ALGを切り離してください、(「IPv4"ケースへのIPv6)」
2. Ensure (if possible) that NAPT-PT does not become a single
point of failure.
2. 太平洋標準時のNAPTが1ポイントの失敗にならないのを確実にしてください(できれば)。
Wiljakka Informational [Page 22] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[22ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
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が1ポイントの失敗になるのを防がないことに注意してください。
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ノキアVisiokatu3フィン-33720タンペレ(フィンランド)
Phone: +358 7180 48372 EMail: juha.wiljakka@nokia.com
以下に電話をしてください。 +358 7180 48372はメールされます: juha.wiljakka@nokia.com
Wiljakka Informational [Page 23] RFC 4215 IPv6 Transition in 3GPP Networks October 2005
3GPPのWiljakkaの情報[23ページ]のRFC4215IPv6変遷は2005年10月をネットワークでつなぎます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Wiljakka Informational [Page 24]
Wiljakka情報です。[24ページ]
一覧
スポンサーリンク
