Network Working Group M. Wasserman, Ed.
Request for Comments: 3314 Wind River
Category: Informational September 2002
Recommendations for IPv6 in
Third Generation Partnership Project (3GPP) Standards
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. Specifically, this document recommends that the 3GPP specify that multiple prefixes may be assigned to each primary PDP context, require that a given prefix must not be assigned to more than one primary PDP context, and allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers.
このドキュメントは、3GPP規格でのIPv6の使用に関する第三世代パートナーシッププロジェクト（3GPP）コミュニティにインターネットエンジニアリングタスクフォース（IETF）のIPv6作業部会からの勧告が含まれています。具体的には、この文書は、3GPPは、各プライマリPDPコンテキストに割り当てることができる、複数のプレフィックスを指定する指定されたプレフィックスが複数のプライマリPDPコンテキストに割り当てられてはならないことを必要とし、3GPPのノードは、それらの接頭語の中で複数の識別子を使用することを可能にすることをお勧めします、ランダムに生成された識別子を含みます。
The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document.
IPv6のワーキンググループは、3GPP内でのIPv6の使用をサポートし、IPv6のワーキンググループと3GPPコミュニティ間のオープンな協力の精神でこれらの推奨事項を提供しています。インターネットドラフトとしてこの文書の元の出版以来、3GPPは、この文書の主要勧告を採用しています。
Conventions Used In This Document
この文書で使用されている表記規則
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORD].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [KEYWORD]に記載されているように解釈されます。
Table of Contents
目次
1 Introduction............................................. 2
1.1 What is the 3GPP?........................................ 3
1.2 What is the IETF?........................................ 4
1.3 Terminology.............................................. 4
1.3.1 3GPP Terminology......................................... 4
1.3.2 IETF Terminology......................................... 5
1.4 Overview of the IPv6 Addressing Architecture............. 6
1.5 An IP-Centric View of the 3GPP System.................... 7
1.5.1 Overview of the UMTS Architecture........................ 7
1.5.2 The PDP Context.......................................... 10
1.5.3 IPv6 Address Autoconfiguration in GPRS................... 11
2 Recommendations to the 3GPP.............................. 13
2.1 Limitations of 3GPP Address Assignment................... 13
2.2 Advertising Multiple Prefixes............................ 14
2.3 Assigning a Prefix to Only One Primary PDP Context....... 14
2.3.1 Is a /64 per PDP Context Too Much?....................... 15
2.3.2 Prefix Information in the SGSN........................... 16
2.4 Multiple Identifiers per PDP Context..................... 16
3 Additional IPv6 Work Items............................... 16
4 Security Considerations.................................. 17
Appendix A: Analysis of Findings................................ 18
Address Assignment Solutions..................................... 18
References....................................................... 19
Authors and Acknowledgements..................................... 22
Editor's Address................................................. 22
Full Copyright Statement......................................... 23
In May 2001, the IPv6 Working Group (WG) held an interim meeting in Redmond, WA to discuss the use of IPv6 within the 3GPP standards. The first day of the meeting was a joint discussion with 3GPP, during which an architectural overview of 3GPP's usage of IPv6 was presented, and there was much discussion regarding particular aspects of IPv6 usage within 3GPP. At that meeting, a decision was made to form a design team to write a document offering advice from the IPv6 WG to the 3GPP community, regarding their use of IPv6. This document is the result of that effort.
2001年5月には、IPv6のワーキンググループ（WG）は、3GPP規格内でのIPv6の使用を議論するためにワシントン州にある中間会合を開催しました。会議の初日は、IPv6の3GPPの使用方法のアーキテクチャの概要が提示された時に、3GPP、との合同協議で、3GPP内でのIPv6の使用の特定の側面に関する多くの議論がありました。その会議では、意思決定は、IPv6の利用に関しては、3GPPのコミュニティへのIPv6 WGからのアドバイスを提供し、文書を書くために設計チームを形成しました。この文書では、その努力の結果です。
This document offers recommendations to the 3GPP community from the IETF IPv6 Working Group. It is organized into three main sections:
この文書は、IETFのIPv6作業部会から3GPPコミュニティに勧告を提供しています。これは、3つのセクションに分かれています。
1. An introduction (this section) that provides background information regarding the IETF IPv6 WG and the 3GPP and includes a high-level overview of the technologies discussed in this document.
IETFのIPv6 WG及び3GPPに関する背景情報を提供し、この文書で説明した技術の高レベルの概要を含む1.はじめに（このセクション）。
2. Recommendations from the IPv6 WG to the 3GPP community. These can be found in section 2.
3GPPコミュニティへのIPv6 WGから2勧告。これらは、セクション2に記載されています。
3. Further work items that should be considered by the IPv6 WG. These items are discussed in section 3.
IPv6のWGで検討すべきである。3.さらに、作業項目。これらの項目は、セクション3に記載されています。
It is the purpose of this document to provide advice from the IPv6 Working Group to the 3GPP community. We have limited the contents of this document to items that are directly related to the use of IPv6 within 3GPP. This document defines no standards, and it is not a definitive source of information regarding IPv6 or 3GPP. We have not chosen to explore 3GPP-related issues with other IETF protocols (i.e., SIP, IPv4, etc.), as they are outside the scope of the IPv6 Working Group.
3GPPのコミュニティへのIPv6作業部会からのアドバイスを提供するために、このドキュメントの目的です。私たちは、直接、3GPP内でのIPv6の使用に関連する項目に、この文書の内容が限られています。この文書では、何の基準を規定していない、そしてそれは、IPv6または3GPPに関する情報の決定的なソースではありません。彼らは、IPv6ワーキンググループの範囲外であるとして、我々は、他のIETFプロトコル（すなわち、SIPはIPv4など）と3GPP関連の問題を探求するために選択していません。
The IPv6 Working Group fully supports the use of IPv6 within 3GPP, and we encourage 3GPP implementers and operators to participate in the IETF process. We are offering these suggestions in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community, and we hope that our ongoing cooperation will help to strengthen both sets of standards.
IPv6のワーキンググループは、完全に、3GPP内でのIPv6の使用をサポートし、私たちはIETFプロセスに参加するために3GPPの実装と演算子を奨励します。私たちは、IPv6ワーキンググループと3GPPコミュニティ間のオープンな協力の精神でこれらの提案を提供している、と私たちは私たちの継続的な協力が基準の両方のセットを強化するのに役立つことを願っています。
The 3GPP address allocation information in this document is based on the 3GPP document TS 23.060 version 4.1.0 [OLD-TS23060]. At the 3GPP plenary meeting TSG #15 in March 2002, the 3GPP adopted the two primary recommendations contained in this document, allocating a unique prefix to each primary PDP context when IPv6 stateless address autoconfiguration is used, and allowing the terminals to use multiple interface identifiers. These changes were retroactively applied from 3GPP release 99 onwards, in TS23.060 versions 3.11.0, 4.4.0 and 5.1.0 [NEW-TS23060].
この文書に記載されている3GPPアドレス割当情報は、3GPP文書TS 23.060バージョン4.1.0 [OLD-TS23060]に基づいています。 3GPP総会で2002年3月TSG第15位、3GPPは、IPv6ステートレスアドレス自動設定を使用する場合、各一次PDPコンテキストに固有のプレフィックスを割り当て、この文書に含まれる2つの主要提言を採用し、端末が複数のインタフェース識別子を使用することを可能にします。これらの変更は遡及3GPPから適用されたTS23.060バージョン3.11.0、4.4.0および5.1.0 [NEW-TS23060]で、以降99を解放します。
The Third Generation Partnership Project (3GPP) is a global standardization partnership founded in late 1998. Its Organizational Partners have agreed to co-operate in the production of technical specifications for a Third Generation Mobile System, based on the evolved GSM core networks.
第三世代パートナーシッププロジェクト（3GPP）は、その組織のパートナーが進化したGSMコアネットワークに基づいて、第三世代携帯電話システムの技術仕様の生産に協働するように合意した後半に1998年に設立された世界的な標準化のパートナーシップです。
The 3GPP Organizational Partners consist of several different standardization organizations: ETSI from Europe, Standards Committee T1 Telecommunications (T1) in the USA, China Wireless Telecommunication Standard Group (CWTS), Korean Telecommunications Technology Association (TTA), the Association of Radio Industries and Businesses (ARIB), and the Telecommunication Technology Committee(TTC) in Japan.
3GPP組織のパートナーは、いくつかの異なる標準化団体で構成されています。アメリカのヨーロッパからのETSI、基準委員会T1テレコミュニケーション（T1）、中国無線通信標準グループ（CWTS）、韓国情報通信技術協会（TTA）、電波産業会（ARIB）、および日本における通信技術委員会（TTC）。
The work is coordinated by a Project Co-ordination Group (PCG), and structured into Technical Specification Groups (TSGs). There are five TSGs: Core Network (TSG CN), Radio Access Networks (TSG RAN), Services and System Aspects (TSG SA), GSM/EDGE Radio Access Network (GERAN), and the Terminals (TSG T). The TSGs are further divided into Working Groups (WGs). The technical work is done in the working groups, and later approved in the TSGs.
仕事はプロジェクトコーディネーショングループ（PCG）によって調整、および技術仕様グループ（のTSG）に構成されています。コアネットワーク（TSG CN）、無線アクセスネットワーク（TSG RANの）、サービス及びシステムアスペクト（TSG SA）、GSM / EDGE無線アクセスネットワーク（GERAN）、および端末（TSG T）：5つのTSGがあります。 TSGは、さらにワーキンググループ（作業部会）に分かれています。技術的な仕事は、ワーキンググループで行われ、以降のTSGに承認されています。
3GPP working methods are different from IETF working methods. The major difference is where the majority of the work is done. In 3GPP, the work is done in face-to-face meetings, and the mailing list is used mainly for distributing contributions, and for handling documents that were not handled in the meeting, due to lack of time. Decisions are usually made by consensus, though voting does exist. However, it is rather rare to vote. 3GPP documents are public and can be accessed via the 3GPP web site [3GPP-URL].
3GPP作業方法は、IETF作業方法とは異なります。作業の大部分が行われる場合の大きな違いです。 3GPPでは、仕事が対面会議で行われ、メーリングリストは、と時間不足のため、会議で扱われていなかった文書を処理するための拠出金を分配するために主に使用されています。投票は存在しないものの決定は通常、コンセンサスによって作られています。しかし、投票することはむしろ稀です。 3GPP文書は、公開されていると3GPPウェブサイト[3GPP-URL]を介してアクセスすることができます。
The Internet Engineering Task Force (IETF) is a large, open, international community of network designers, operators, vendors, and researchers, concerned with the evolution of the Internet architecture and the smooth operation of the Internet. The IETF is also the primary standards body developing Internet protocols and standards. It is open to any interested individual. More information about the IETF can be found at the IETF web site [IETF-URL].
IETF（Internet Engineering Task Force）は、インターネットアーキテクチャの進化とインターネットの円滑な運営に関わるネットワーク設計者、オペレータ、ベンダー、および研究者の大規模な、オープン、国際社会、です。 IETFは、インターネットプロトコルおよび標準を開発する主要な標準化団体です。これは、任意の興味を個々に開放されています。 IETFの詳細については、IETFのWebサイト[IETF-URL]で見つけることができます。
The actual technical work of the IETF is done in working groups, organized by topic into several areas (e.g., routing, transport, security, etc.). The IPv6 Working Group is chartered within the Internet area of the IETF. Much of the work is handled via mailing lists, and the IETF holds meetings three times per year.
IETFの実際の技術的な作業は、いくつかの領域（例えば、ルーティング、トランスポート、セキュリティなど）にトピック別に編成、ワーキンググループで行われます。 IPv6のワーキンググループは、IETFのインターネット領域内にチャーターされます。作品の多くはメーリングリストを介して処理され、IETFは年間ミーティング三回を保持しています。
This section defines the 3GPP and IETF terminology used in this document. The 3GPP terms and their meanings have been taken from [TR21905].
このセクションでは、この文書で使用される3GPP及びIETF用語を定義します。 3GPPの用語とその意味は[TR21905]から取られています。
APN Access Point Name. The APN is a logical name referring to a GGSN and an external network.
APNアクセスポイント名。 APNは、GGSNと外部ネットワークを参照する論理名です。
CS Circuit Switched
CS回線交換しました
GERAN GSM/EDGE Radio Access Network
GERAN GSM / EDGE無線アクセスネットワーク
GGSN Gateway GPRS Support Node. A router between the GPRS network and an external network (i.e., the Internet).
GGSNゲートウェイGPRSサポートノード。 GPRSネットワークと外部ネットワーク（すなわち、インターネット）との間のルータ。
GPRS General Packet Radio Services
GPRS汎用パケット無線サービス
GTP-U General Tunneling Protocol - User Plane
GTP-U一般的トンネリングプロトコル - ユーザ・プレーン
MT Mobile Termination. For example, a mobile phone handset.
MTモバイル終了。例えば、携帯電話機。
PDP Packet Data Protocol
PDPパケットデータプロトコル
PDP Context A PDP connection between the UE and the GGSN.
PDPコンテキストUEとGGSNとの間のPDP接続。
PS Packet Switched
PSパケット交換しました
SGSN Serving GPRS Support Node
サービングGPRSサポートノードSGSN
TE Terminal Equipment. For example, a laptop attached through a 3GPP handset.
TE端末装置。例えば、ラップトップは、3GPPハンドセットを介して結合しました。
UE User Equipment (TE + MT + USIM). An example would be a mobile handset with a USIM card inserted and a laptop attached.
UEユーザ装置（TE + MT + USIM）。例では、挿入されたUSIMカードおよび添付のラップトップと携帯電話であろう。
UMTS Universal Mobile Telecommunications System
UMTSユニバーサル移動体通信システム
USIM Universal Subscriber Identity Module. Typically, a card that is inserted into a mobile phone handset.
USIM汎用加入者識別モジュール。一般的に、携帯電話機に挿入されているカード。
UTRAN Universal Terrestrial Radio Access Network
UTRANユニバーサル地上無線アクセスネットワーク
IPv6 Internet Protocol version 6 [RFC 2460]
IPv6インターネットプロトコルバージョン6 [RFC 2460]
NAS Network Access Server
NASネットワークアクセスサーバ
NAT Network Address Translator
NATネットワークアドレス変換
NAT-PT Network Address Translation with Protocol Translation. An IPv6 transition mechanism. [NAT-PT]
プロトコル変換とNAT-PTネットワークアドレス変換。 IPv6移行メカニズム。 [NAT-PT]
PPP Point-to-Point Protocol [PPP]
PPPポイントツーポイントプロトコル[PPP]
SIIT Stateless IP/ICMP Transition Mechanism [SIIT]
HEREステートレスIP / ICMPの移行メカニズム[HERE]
The recommendations in this document are primarily related to IPv6 address assignment. To fully understand the recommended changes, it is necessary to understand the IPv6 addressing architecture, and current IPv6 address assignment mechanisms.
このドキュメントの推奨事項は、IPv6アドレスの割り当てに主に関連しています。完全に推奨される変更を理解するには、IPv6のアドレス体系、および現在のIPv6アドレス割り当てメカニズムを理解することが必要です。
The IPv6 addressing architecture represents a significant evolution from IPv4 addressing [ADDRARCH]. It is required that all IPv6 nodes be able to assemble their own addresses from interface identifiers and prefix information. This mechanism is called IPv6 Host Autoconfiguration [AUTOCONF], and it allows IPv6 nodes to configure themselves without the need for stateful configuration servers (i.e., DHCPv6) or statically configured addresses.
IPv6のアドレス体系は、[ADDRARCH]アドレッシングIPv4から著しい進化を表します。すべてのIPv6ノードは、インターフェース識別子とプレフィックス情報から自分のアドレスを組み立てることができることが必要です。このメカニズムは、IPv6ホストの自動[AUTOCONF]を呼ばれ、それは、IPv6ノードは、ステートフル構成サーバ（すなわち、DHCPv6の）または静的に設定されたアドレスを必要とせずに自分自身を設定することを可能にします。
Interface identifiers can be globally unique, such as modified EUI-64 addresses [ADDRARCH], or non-unique, such as randomly generated identifiers. Hosts that have a globally unique identifier available may also choose to use randomly generated addresses for privacy [PRIVADDR] or for other reasons. IPv6 hosts are free to generate new identifiers at any time, and Duplicate Address Detection (DAD) is used to protect against the use of duplicate identifiers on a single link [IPV6ND].
インタフェース識別子は、例えば、ランダムに生成された識別子などの修飾EUI-64アドレス[ADDRARCH]、または非固有など、グローバルに一意であることができます。利用できるグローバル一意識別子を持っているホストはまた、[PRIVADDR]またはその他の理由のためにプライバシー保護のため、ランダムに生成されたアドレスを使用することもできます。 IPv6ホストは、いつでも新しい識別子を生成して自由であり、重複を検出（DAD）をアドレス[IPV6ND]単一リンク上で重複した識別子の使用から保護するために使用されます。
A constant link-local prefix can be combined with any interface identifier to build an address for communication on a locally attached link. IPv6 routers may advertise additional prefixes (site-local and/or global prefixes)[IPV6ND]. Hosts can combine advertised prefixes with their own interface identifiers to create addresses for site-local and global communication.
一定のリンクローカルプレフィックスがローカルに接続されたリンク上で通信するためのアドレスを構築するために、任意のインタフェース識別子と組み合わせることができます。 IPv6ルータは、追加のプレフィックス（サイトローカル及び/又はグローバルプレフィックス）IPV6ND]を広告することができます。ホストは、サイトローカルおよびグローバルなコミュニケーションのためのアドレスを作成するための独自のインターフェース識別子にアドバタイズされるプレフィクスを組み合わせることができます。
IPv6 introduces architectural support for scoped unicast addressing [SCOPARCH]. A single interface will typically have multiple addresses for communication within different scopes: link-local, site-local and/or global [ADDRARCH]. Link-local addresses allow for local communication, even when an IPv6 router is not present. Some IPv6 protocols (i.e., routing protocols) require the use of link-local addresses. Site-local addressing allows communication to be administratively contained within a single site. Link-local or site-local connections may also survive changes to global prefix information (e.g., site renumbering).
IPv6は[SCOPARCH]アドレッシングスコープユニキャストのアーキテクチャのサポートを導入します。単一のインターフェースは、典型的には、異なるスコープ内で通信するための複数のアドレスを有することになる：リンクローカル、サイトローカルおよび/またはグローバル[ADDRARCH]。リンクローカルアドレスは、IPv6ルーターが存在しない場合でも、ローカル通信を可能とします。いくつかのIPv6プロトコル（すなわち、ルーティングプロトコル）がリンクローカルアドレスの使用を必要とします。サイトローカルアドレス指定の通信が管理上の単一サイトに含まれていることを可能にします。リンクローカルまたはサイトローカル接続は、グローバルプレフィックス情報（例えば、サイトのリナンバリング）への変更を生き残ることがあります。
IPv6 explicitly associates each address with an interface. Multiple-interface hosts may have interfaces on more than one link or in more than one site. Links and sites are internally identified using zone identifiers. Proper routing of non-global traffic and proper address selection are ensured by the IPv6 scoped addressing architecture [SCOPARCH].
IPv6は、明示的インターフェイスで各アドレスを関連付けます。複数のインタフェースホストは、複数のリンク上または複数のサイトのインターフェイスを有していてもよいです。リンクやサイトは、内部ゾーン識別子を使用して識別されます。非グローバルトラフィックと適切なアドレス選択の適切なルーティングは、IPv6によって保証されているアーキテクチャ[SCOPARCH]をアドレス指定するスコープ。
IPv6 introduces the concept of privacy addresses [PRIVADDR]. These addresses are generated from an advertised global prefix and a randomly generated identifier, and are used for anonymous access to Internet services. Applications control the generation of privacy addresses, and new addresses can be generated at any time.
IPv6は[PRIVADDR]プライバシーアドレスの概念を導入しています。これらのアドレスは、広告を出してグローバルプレフィックスとランダムに生成された識別子から生成され、およびインターネットサービスへの匿名アクセスに使用されています。アプリケーションは、プライバシーアドレスの生成を制御し、新しいアドレスはいつでも生成することができます。
The IPv6 site renumbering specification [SITEREN] relies upon the fact that IPv6 nodes will generate new addresses when new prefixes are advertised on the link, and that they will deprecate addresses that use deprecated prefixes.
IPv6サイトリナンバリング仕様[SITEREN]はIPv6ノードが新しいプレフィックスがリンク上で宣伝されているときに、新しいアドレスを生成し、彼らは非推奨プレフィックスを使用するアドレスを廃止することになるという事実に依存しています。
In the future, additional IPv6 specifications may rely upon the ability of IPv6 nodes to use multiple prefixes and/or multiple identifiers to dynamically create new addresses.
将来的には、追加のIPv6仕様は、動的に新しいアドレスを作成するために、複数のプレフィックスおよび/または複数の識別子を使用するには、IPv6ノードの能力に依存していることがあります。
The 3GPP specifications define a Third Generation Mobile System. An overview of the packet switched (PS) domain of the 3GPP Release 99 system is described in the following sections. The authors hope that this description is sufficient for the reader who is unfamiliar with the UMTS packet switched service, to understand how the UMTS system works, and how IPv6 is currently defined to be used within it.
3GPP仕様は、第三世代携帯電話システムを定義します。パケットの概要は、3GPPリリース99システム（PS）ドメインは、以下のセクションに記載されて切り替えます。著者は、この記述は、UMTSパケットは、UMTSシステムがどのように機能するかを理解するために、サービスを切り替え、およびIPv6は、現在、その中で使用されるように定義される方法に不慣れな読者のために十分であることを願っています。
The UMTS architecture can be divided into two main domains -- the packet switched (PS) domain, and the circuit switched (CS) domain. In this document, we will concentrate on the PS domain, or General Packet Radio Services (GPRS).
UMTSアーキテクチャは、2つの主な領域に分けることができる - パケット（PS）ドメインを切り替え、及び回路は、（CS）ドメインを切り替えます。この文書では、我々は、PSドメインに集中し、または汎用パケット無線サービス（GPRS）。
------
| TE |
------
|
+R
|
------ Uu ----------- Iu ----------- Gn ----------- Gi
| MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+--
------ ----------- ----------- -----------
(UE)
Figure 1: Simplified GPRS Architecture
図1：簡体GPRSアーキテクチャ
------
| |
| App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
| |
|------| -------------
| IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |->
| v4/6 | | v4/6 |
|------| ------------- ------------- |------ |
| | | \ Relay / | | \ Relay / | | | |
| | | \ / | | \ / | | | |
| | | \ / | | \ / | | | |
| PDCP |- - -| PDCP\ /GTP_U|- - -|GTP_U\ /GTP_U|- - -|GTP_U | |
| | | | | | | | | | |
|------| |------|------| |------|------| |------| |
| | | | UDP |- - -| UDP | UDP |- - -| UDP | |
| | | |------| |------|------| |------| |
| RLC |- - -| RLC | IP |- - -| IP | IP |- - -| IP | |
| | | | v4/6 | | v4/6 | v4/6 | |v4/6 | |
|------| |------|------| |------|------| |------|------|
| MAC | | MAC | AAL5 |- - -| AAL5 | L2 |- - -| L2 | L2 |
|------| |------|------| |------|------| |------|------|
| L1 |- - -| L1 | ATM |- - -| ATM | L1 |- - -| L1 | L1 |
------ ------------- ------------- -------------
UE UTRAN SGSN GGSN (handset)
UE UTRAN SGSN GGSN（受話器）
Figure 2: GPRS Protocol Stacks
図2：GPRSプロトコルスタック
------
| |
| App. |- - - - - - - - - - - - - - - - - - - - - - (to app peer)
| |
|------|
| |
| IP |- - - - - - - - - - - - - - - - - - - - - - (to GGSN)
| v4/6 |
| | | |
|------| |-------------|
| | | \ Relay / |
| | | \ / |
| | | \ / |
| | | \ / PDCP|- - - (to UTRAN)
| | | | |
| PPP |- - -| PPP |------|
| | | | RLC |- - - (to UTRAN)
| | | |------|
| | | | MAC |
|------| |------|------|
| L1a |- - -| L1a | L1b |- - - (to UTRAN)
------ -------------
TE MT
(laptop) (handset)
Figure 3: Laptop Attached to 3GPP Handset
図3：ノートパソコンの3GPPハンドセットに添付
The GPRS core network elements, shown in Figures 1 and 2, are the User Equipment (UE), Serving GPRS Support Node (SGSN), and Gateway GPRS Support Node (GGSN). The UTRAN comprises Radio Access Network Controllers (RNC) and the UTRAN base stations.
図1および図2に示すGPRSコアネットワーク要素は、GPRSサポートノード（SGSN）、ゲートウェイGPRSサポートノード（GGSN）をサービング、ユーザ機器（UE）です。 UTRANは、無線アクセスネットワークコントローラ（RNC）とUTRANの基地局を含みます。
GGSN: A specialized router that functions as the gateway between the GPRS network and the external networks, e.g., Internet. It also gathers charging information about the connections. In many ways, the GGSN is similar to a Network Access Server (NAS).
GGSN：GPRSネットワークと外部ネットワーク、例えば、インターネットとの間のゲートウェイとして機能する特殊なルータ。また、接続に関する情報を課金収集します。多くの点では、GGSNは、ネットワークアクセスサーバ（NAS）に似ています。
SGSN: The SGSN's main functions include authentication, authorization, mobility management, and collection of billing information. The SGSN is connected to the SS7 network and through that, to the Home Location Register (HLR), so that it can perform user profile handling, authentication, and authorization.
SGSN：SGSNの主な機能は、認証、許可、モビリティ管理、および課金情報の収集が含まれています。それは、ユーザー・プロファイル・ハンドリング、認証、および承認を行うことができるようにSGSNは、ホーム・ロケーション・レジスタ（HLR）に、SS7ネットワークに、その介して接続されています。
GTP-U: A simple tunnelling protocol running over UDP/IP and used to route packets between RNC, SGSN and GGSN within the same, or between different, UMTS backbone(s). A GTP-U tunnel is identified at each end by a Tunnel Endpoint Identifier (TEID).
GTP-U：単純なトンネリング・プロトコルUDP / IP上で動作し、同じ、または異なる間、UMTSバックボーン（S）内RNC、SGSNとGGSNとの間でパケットをルーティングするために使用されます。 GTP-Uトンネルは、トンネルエンドポイント識別子（TEID）によって各端部で識別されます。
Only the most significant elements of the GPRS system are discussed in this document. More information about the GPRS system can be found in [OLD-TS23060].
GPRSシステムの唯一の最も重要な要素は、このドキュメントで説明されています。 GPRS方式の詳細については、[OLD-TS23060]で見つけることができます。
The most important 3GPP concept in this context is a PDP Context. A PDP Context is a connection between the UE and the GGSN, over which the packets are transferred. There are two kinds of PDP Contexts -- primary, and secondary.
この文脈の中で最も重要なの3GPP概念がPDPコンテキストです。 PDPコンテキストは、パケットが転送され、その上UEとGGSNとの間の接続です。プライマリー、および二 - PDPコンテキストの2種類があります。
The primary PDP Context initially defines the link to the GGSN. For instance, an IP address is assigned to each primary PDP Context. In addition, one or more secondary PDP Contexts can be added to a primary PDP Context, sharing the same IP address. These secondary PDP Contexts can have different Quality of Service characteristics than the primary PDP Context.
主なPDPコンテキストが最初にGGSNへのリンクを定義します。例えば、IPアドレスが各プライマリPDPコンテキストに割り当てられています。加えて、1つ以上の二次PDPコンテキストは、同じIPアドレスを共有し、一次PDPコンテキストに追加することができます。これらの二次PDPコンテキストは、プライマリPDPコンテキストよりも異なるサービスクオリティ特性を持つことができます。
Together, a primary PDP Context and zero or more secondary PDP Contexts define, in IETF terms, a link. GPRS links are point-to-point. Once activated, all PDP contexts have equal status, meaning that a primary PDP context can be deleted while keeping the link between the UE and the GGSN, as long as there are other (secondary) PDP contexts active for the same IP address.
一緒に、プライマリPDPコンテキスト及びゼロ以上の二次PDPコンテキストは、IETF用語で、リンクを定義します。 GPRSリンクはポイントツーポイントです。一度活性化された、全てのPDPコンテキストは、UEとGGSNとの間のリンクを維持しながら、プライマリPDPコンテキストがあれば、同じIPアドレスのアクティブ他の（二次）PDPコンテキストが存在するように、削除することができることを意味し、同じ状態を有しています。
There are currently three PDP Types supported in GPRS -- IPv4, IPv6, and PPP. This document will only discuss the IPv6 PDP Type.
IPv4の、IPv6、およびPPP - GPRSでサポートされる3つのPDPタイプは現在ありません。この文書は、IPv6のみPDPタイプについて説明します。
There are three basic actions that can be performed on a PDP Context: PDP Context Activation, Modification, and Deactivation. These actions are described in the following.
PDPコンテキスト起動、修正、および無効化：PDPコンテキストで実行することができる3つの基本的なアクションがあります。これらのアクションは、以下に記載されています。
Activate PDP Context
PDPコンテキストのアクティブ化
Opens a new PDP Context to a GGSN. If a new primary PDP
Context is activated, there is a new link created between a UE
and a GGSN. A UE can open multiple primary PDP Contexts to one
or more GGSNs.
Modify PDP Context
PDPコンテキストを変更します。
Changes the characteristics of a PDP Context, for example QoS
attributes.
Deactivate PDP Context
PDPコンテキストを非アクティブ化
Deactivates a PDP Context. If a primary PDP Context and all
secondary PDP contexts associated with it are deactivated, a
link between the UE and the GGSN is removed.
The APN is a name which is logically linked to a GGSN. The APN may identify a service or an external network. The syntax of the APN corresponds to a fully qualified domain name. At PDP context activation, the SGSN performs a DNS query to find out the GGSN(s) serving the APN requested by the terminal. The DNS response contains a list of GGSN addresses from which the SGSN selects one (in a round-robin fashion).
APNは、論理的にGGSNにリンクされている名前です。 APNは、サービスまたは外部ネットワークを識別することができます。 APNの構文は、完全修飾ドメイン名に対応しています。 PDPコンテキスト起動時に、SGSNは、端末によって要求されたAPNにサービスを提供するGGSN（単数または複数）を見つけるためにDNSクエリを実行します。 DNS応答は、SGSNは、（ラウンドロビン方式で）いずれかを選択し、そこからGGSNアドレスのリストを含みます。
--------- --------
| | | GGSN |
| | LINK 1 | |
| -======== PDP Context A ========- - - -> ISP X
| | | |
| | | |
| | | |
| /======= PDP Context B =======\ |
| - | LINK 2 | - - - -> ISP Y
| \======= PDP Context C =======/ |
| | | |
| MT | --------
|(handset)|
| | --------
-------- | | | GGSN |
| | | | LINK 3 | |
| | | -======== PDP Context D ========- |
| TE | | | | |
|(laptop)| | | | - - -> ISP Z
| | | | LINK 4 | |
| -====PPP====-----======== PDP Context E ========- |
| | | | | |
| | | | | |
-------- --------- --------
Figure 3: Correspondence of PDP Contexts to IPv6 Links
図3：IPv6のリンクへのPDPコンテキストの対応
GPRS supports static and dynamic address allocation. Two types of dynamic address allocation are supported -- stateless, and stateful. Stateful address configuration uses an external protocol to connect to a server that gives the IP address, e.g., DHCP.
GPRSは、静的および動的アドレス割り当てをサポートしています。ステートレス、およびステートフル - 動的アドレス割り当ての二つのタイプがサポートされています。ステートフルアドレス設定は、IPアドレス、例えば、DHCPを与えるサーバーに接続する外部のプロトコルを使用しています。
The stateless IPv6 autoconfiguration works differently in GPRS than in Ethernet networks. GPRS nodes have no unique identifier, whereas Ethernet nodes can create an identifier from their EUI-48 address. Because GPRS networks are similar to dialup networks, the stateless address autoconfiguration in GPRS was based on PPPv6 [PPPV6].
ステートレスIPv6自動設定は、イーサネット・ネットワークよりもGPRSに動作が異なります。イーサネットノードがEUI-48アドレスからの識別子を作成することができ、一方、GPRSノードは、一意の識別子を持っていません。 GPRSネットワークはネットワークのダイアルアップに似ているので、GPRSでのステートレスアドレス自動設定は、PPPv6 [PPPV6]に基づいていました。
3GPP address autoconfiguration has the following steps:
3GPPのアドレス自動設定は、以下のステップがあります。
1. The Activate PDP Context message is sent to the SGSN (PDP Type=IPv6, PDP Address = 0, etc.).
1.アクティブPDPコンテキストメッセージは、SGSN（PDPタイプ= IPv6の、PDPアドレス= 0、等）に送信されます。
2. The SGSN sends a Create PDP Context message to the GGSN with the above parameters.
前記SGSNは、上記のパラメータを使用してGGSNにPDPコンテキストメッセージを作成し送信します。
3. GGSN chooses an interface identifier for the PDP Context and creates the link-local address. It answers the SGSN with a Create PDP Context response (PDP Address = link-local address).
前記GGSNは、PDPコンテキストのインタフェース識別子を選択し、リンクローカルアドレスを生成します。これは、PDPコンテキスト作成応答（PDPアドレス=リンクローカルアドレス）をSGSNに答えます。
4. The SGSN sends an Activate PDP Context accept message to the UE (PDP Address = link-local address).
前記SGSNは、PDPコンテキスト起動は、UE（PDPアドレス=リンクローカルアドレス）にメッセージを受け入れる送信します。
5. The UE keeps the link-local address, and extracts the interface identifier for later use. The UE may send a Router Solicitation message to the GGSN (first hop router).
前記UEは、リンクローカルアドレスを保持し、そして後の使用のためのインタフェース識別子を抽出します。 UEは、GGSN（最初のホップルータ）にルータ要請メッセージを送信することができます。
6. After the PDP Context Activation, the GGSN sends a Router Advertisement to the UE.
6. PDPコンテキスト活性化の後、GGSNはUEにルータ通知を送信します。
7. The UE should be configured not to send a Neighbor Solicitation message. However, if one is sent, the GGSN will silently discard it.
7. UEは近隣要請メッセージを送信しないように構成されるべきです。 1が送信される場合には、GGSNは黙ってそれを破棄します。
Each connected handset or laptop will create a primary PDP context for communication on the Internet. A handset may create many primary and/or secondary PDP contexts throughout the life of its connection with a GGSN.
各接続のハンドセットまたはラップトップは、インターネット上の通信のためのプライマリPDPコンテキストを作成します。携帯電話は、GGSNとの接続の人生の多くのプライマリおよび/またはセカンダリPDPコンテキストを作成することができます。
Within 3GPP, the GGSN assigns a single 64-bit identifier to each primary PDP context. The GGSN also advertises a single /64 prefix to the handset, and these two items are assembled into a single IPv6 address. Later, the GGSN modifies the PDP context entry in the SGSN to include the whole IPv6 address, so that the SGSN can know the single address of each 3GPP node (e.g., for billing purposes). This address is also used in the GGSN to identify the PDP context associated with each packet. It is assumed that 3GPP nodes will not generate any addresses, except for the single identifier/prefix combination assigned by the GGSN. DAD is not performed, as the GGSN will not assign the same address to multiple nodes.
3GPP内で、GGSNは、各一次PDPコンテキストに単一の64ビットの識別子を割り当てます。 GGSNはまた、ハンドセットに単一/ 64プレフィックスを広告し、そしてこれらの2つの項目が単一のIPv6アドレスに組み込まれています。その後、GGSNは、SGSNは、各3GPPノードの単一のアドレスを知ることができるように、全体のIPv6アドレスを含むようにSGSNにPDPコンテキストエントリを変更（例えば、課金目的のために）。このアドレスは、各パケットに関連するPDPコンテキストを識別するためにGGSNに使用されます。 3GPPノードがGGSNによって割り当てられた単一の識別子/プレフィックス組み合わせを除き、任意のアドレスを生成しないことが想定されます。 GGSNは複数のノードに同一のアドレスを割り当てないので、DADは、行われません。
2 Recommendations to the 3GPP
3GPPへの提言2
In the spirit of productive cooperation, the IPv6 Working Group recommends that the 3GPP consider three changes regarding the use of IPv6 within GPRS. Specifically, we recommend that the 3GPP:
生産的な協力の精神では、IPv6の作業部会は、3GPPは、GPRS内のIPv6の使用に関する3つの変更を検討することをお勧めします。具体的には、3GPPことをお勧めします。
1. Specify that multiple prefixes may be assigned to each primary PDP context,
1は、複数のプレフィックスが各プライマリPDPコンテキストに割り当てることができることを指定します
2. Require that a given prefix must not be assigned to more than one primary PDP context, and
2.指定されたプレフィックスが複数のプライマリPDPコンテキストに割り当てられてはならないことを必要とし、
3. Allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers.
3. 3GPPノードはランダムに生成された識別子を含む、それらのプレフィックス内の複数の識別子を使用することを許可します。
Making these changes would provide several advantages for 3GPP implementers and users:
これらの変更を加えることは、3GPPの実装とユーザーのためのいくつかの利点を提供します：
Laptops that connect to 3GPP handsets will work without any software changes. Their implementation of the standard IPv6 over PPP, address assignment, and autoconfiguration mechanisms will work without any modification. This will eliminate the need for vendors and operators to build and test special 3GPP drivers and related software. As currently specified, the 3GPP standards will be incompatible with laptop implementations that generate their own identifiers for privacy or other purposes.
3GPP携帯電話に接続するラップトップは、任意のソフトウェアを変更することなく動作します。彼らのPPPを超える標準のIPv6の実装、アドレス割り当て、および自動設定メカニズムはそのまま動作します。これは特殊な3GPPドライバおよび関連ソフトウェアを構築し、テストするためのベンダーとオペレーターの必要性を排除します。現在指定されているように、3GPP規格は、プライバシーまたは他の目的のために独自の識別子を生成するノートパソコンの実装と互換性がありません。
IPv6 software implementations could be used in 3GPP handsets without any modifications to the IPv6 protocol mechanisms. This will make it easier to build and test 3GPP handsets.
IPv6のソフトウェア実装では、IPv6プロトコルメカニズムに変更せず、3GPP携帯電話で使用することができます。これは、簡単に3GPPの携帯電話を構築し、テストすることになります。
Applications in 3GPP handsets will be able to take advantage of different types of IPv6 addresses (e.g., static addresses, temporary addresses for privacy, site-scoped addresses for site only communication, etc.)
3GPP携帯電話でのアプリケーションは、IPv6アドレスの異なるタイプの利点取ることができるようになります（例えば、静的アドレス、プライバシーのための一時的なアドレスを、サイトのみ通信などのためのサイトスコープのアドレス）
The GPRS system will be better positioned to take advantage of new IPv6 features that are built around the current addressing architecture.
GPRSシステムは、より良い現在のアドレス体系を中心に構築された新しいIPv6の機能を利用するように配置されます。
The current 3GPP address assignment mechanism has the following limitations:
現在の3GPPアドレス割り当てメカニズムは、次の制限があります。
The GGSN only advertises a single /64 prefix, rather than a set of prefixes. This will prevent the participation of 3GPP nodes (e.g., handsets or 3GPP-attached laptops) in IPv6 site renumbering, or in other mechanisms that expect IPv6 hosts to create addresses based on multiple advertised prefixes.
GGSNは、単一/ 64のプレフィックスではなく、接頭語のセットをアドバタイズします。これは、IPv6サイトの番号を付け替えることで、3GPPのノード（例えば、携帯電話または3GPP付きラップトップ）の参加を防ぐ、またはIPv6が複数のアドバタイズされたプレフィックスに基づくアドレスを作成するために、ホスト期待する他のメカニズムであろう。
A 3GPP node is assigned a single identifier and is not allowed to generate additional identifiers. This will prevent the use of privacy addresses by 3GPP nodes. This also makes 3GPP mechanisms not fully compliant with the expected behavior of IPv6 nodes, which will result in incompatibility with popular laptop IPv6 stacks. For example, a laptop that uses privacy addresses for web browser connections could not currently establish a web browser connection over a 3GPP link.
3GPPノードは単一の識別子が割り当てられ、追加の識別子を生成することができません。これは、3GPPノードによってプライバシーアドレスの使用を防ぐことができます。これも人気のラップトップのIPv6スタックとの非互換性になりますIPv6ノードの予想される動作、に完全に準拠していない3GPPメカニズムになります。たとえば、Webブラウザの接続のためのプライバシーアドレスを使用するラップトップは、現在、3GPPリンクを介してWebブラウザの接続を確立できませんでした。
These limitations could be avoided by enabling the standard IPv6 address allocation mechanisms in 3GPP nodes. The GGSN could advertise one or more prefixes for the local link in standard IPv6 Router Advertisements, and IPv6 addresses could be assembled, as needed, by the IPv6 stack on the handset or laptop. An interface identifier could still be assigned by the GGSN, as is currently specified in the 3GPP standards. However, the handset or laptop could generate additional identifiers, as needed for privacy or other reasons.
これらの制限は、3GPPノードにおける標準のIPv6アドレス割当メカニズムを可能にすることによって回避することができます。 GGSNは標準のIPv6ルータ広告でローカルリンクのための一つ以上のプレフィックスを通知でき、必要に応じてIPv6アドレスは、ハンドセットまたはラップトップ上のIPv6スタックにより、組み立てることができます。現在の3GPP規格で規定されるインタフェース識別子は、依然として、GGSNによって割り当てられることができます。プライバシーや他の理由のために、必要に応じしかし、携帯電話やノートパソコンには、追加の識別子を生成することがありました。
For compliance with current and future IPv6 standards, the IPv6 WG recommends that the 3GPP allow multiple prefixes to be advertised for each primary PDP context. This would have several advantages, including:
現在および将来のIPv6規格に準拠するため、IPv6のWGは、3GPPは、複数のプレフィックスが各プライマリPDPコンテキストのためにアドバタイズされることを可能にすることをお勧めします。これは、以下を含むいくつかの利点を持っています：
3GPP nodes could participate in site renumbering and future IPv6 mechanisms that rely on the use of multiple global prefixes on a single link.
3GPPノードは、サイトリナンバリングと単一リンク上で複数のグローバルプレフィックスの使用に依存して、将来のIPv6メカニズムに参加できます。
Site-local prefixes could be advertised on 3GPP links, if desired, allowing for site-constrained communication that could survive changes to global prefix information (e.g., site renumbering).
所望であれば、サイトローカルプレフィックスは、グローバルプレフィックス情報（例えば、サイトの番号を付け替える）への変更を生き残ることができ、サイト制約通信を可能にする、3GPPリンクで宣伝することができます。
The IPv6 WG recommends that the 3GPP treat a primary PDP context, along with its secondary PDP contexts, as a single IPv6 link, and that the GGSN view each primary PDP context as a single subnet. Accordingly, a given global (or site-local) prefix should not be assigned to more than one PDP context.
IPv6のWGは、3GPPは、単一のIPv6リンクとして、セカンダリPDPコンテキストと共に、一次PDPコンテキストを治療することをお勧めし、GGSNは、単一のサブネットとして各一次PDPコンテキストを表示すること。したがって、所与のグローバル（またはサイトローカル）の接頭辞は、複数のPDPコンテキストに割り当てられるべきではありません。
Because multiple IPv6 hosts may attach through a 3GPP handset, the IPv6 WG recommends that one or more /64 prefixes should be assigned to each primary PDP context. This will allow sufficient address space for a 3GPP-attached node to allocate privacy addresses and/or route to a multi-link subnet [MULTLINK], and will discourage the use of NAT within 3GPP-attached devices.
複数のIPv6ホストは、3GPPハンドセットを介して取り付けることができるので、IPv6のWGは、一つ以上の/ 64プレフィックスが各プライマリPDPコンテキストに割り当てられるべきであることをお勧めします。これは、マルチリンクサブネット[MULTLINK]にプライバシーアドレス及び/又は経路を割り当てる3GPPに接続されたノードのために十分なアドレス空間を可能にする、および3GPP-接続デバイス内でNATを使用することを妨げるであろう。
If an operator assigns a /64 per PDP context, can we be assured that there is enough address space for millions of mobile devices? This question can be answered in the positive using the Host Density (HD) Ratio for address assignment efficiency [HD]. This is a measure of the number of addresses that can practically and easily be assigned to hosts, taking into consideration the inefficiencies in usage resulting from the various address assignment processes. The HD ratio was empirically derived from actual telephone number and data network address assignment cases.
オペレータはPDPコンテキストごとに/ 64を割り当てた場合、私たちは、モバイルデバイスの何百万人のための十分なアドレス空間があることを保証することができますか？この質問は[HD]アドレス割り当ての効率化のためのホスト密度（HD）比を使用してポジティブに答えることができます。これは、実際に、容易に考慮様々なアドレス割り当てプロセスに起因する使用の非効率を取って、ホストに割り当てることができるアドレスの数の尺度です。 HD比は、経験的に実際の電話番号とデータネットワークアドレス割り当ての場合に由来しました。
We can calculate the number of easily assignable /64's making the following assumptions:
私たちは、以下の仮定を作る簡単にアサイン/ 64年代の数を計算することができます：
An HD ratio of 0.8 (representing the efficiency that can be achieved with no particular difficulty).
0.8のHD比（NO特に困難で達成することができる効率を表します）。
Only addresses with the 3-bit prefix 001 (the Aggregatable Global Unicast Addresses defined by RFC 2373) are used, resulting in 61 bits of assignable address space.
3ビットのプレフィックス001（RFC 2373によって定義された集約グローバルユニキャストアドレス）を持つ唯一のアドレスが割り当て可能なアドレス空間の61ビットで、その結果、使用されています。
Using these assumptions, a total of 490 trillion (490x10^12) /64 prefixes can be assigned. This translates into around 80,000 PDP Contexts per person on the earth today. Even assuming that a majority of these IPv6 /64 prefixes will be used by non-3GPP networks, there is still clearly a sufficient number of /64 prefixes.
これらの仮定を用いて、490000000000000（490x10 ^ 12）/ 64プレフィックスの合計を割り当てることができます。これは、今日、地球上で一人あたり約8万PDPコンテキストに変換されます。これらのIPv6 / 64プレフィックスの大部分が非3GPPネットワークによって使用されると仮定すると、明らかにまだ/ 64プレフィックスの十分な数があります。
Given this, it can be safely concluded that the IPv6 address space will not be exhausted if /64 prefixes are allocated to primary PDP contexts.
このことを考えると、安全に/ 64のプレフィックスがプライマリPDPコンテキストに割り当てられている場合、IPv6アドレス空間が枯渇されないことを結論することができます。
For more information regarding policies for IPv6 address assignment, refer to the IAB/IESG recommendations regarding address assignment [IABAA], and the APNIC, ARIN and RIPE address allocation policy [AAPOL].
IPv6アドレス割り当てのポリシーを詳細については、アドレス割り当て[IABAA]、およびAPNIC、ARINおよびRIPEアドレス割当ポリシー[AAPOL]に関するIAB / IESG勧告を参照。
Currently, the 3GPP standards allow only one prefix and one identifier for each PDP context. So, the GGSN can send a single IPv6 address to the SGSN, to be used for billing purposes, etc.
現在、3GPP規格は、唯一のプレフィックスと、各PDPコンテキストに対して1つの識別子を許可します。だから、GGSNはSGSNに、単一のIPv6アドレスを送信することができ、課金目的などに使用されます
Instead of using the full IPv6 address to identify a PDP context, the IPv6 WG recommends that the SGSN be informed of each prefix that is currently assigned to a PDP context. By assigning a prefix to only one primary PDP context, the SGSN can associate a prefix list with each PDP context.
代わりに、PDPコンテキストを識別するために、完全なIPv6アドレスを使用する、IPv6のWGは、SGSNは、現在のPDPコンテキストに割り当てられている各プレフィックスを通知することをお勧めします。 1つのプライマリPDPコンテキストにプレフィックスを割り当てることにより、SGSNは、各PDPコンテキストにプレフィクスリストを関連付けることができます。
The IPv6 WG also recommends that the 3GPP standards be modified to allow multiple identifiers, including randomly generated identifiers, to be used within each assigned prefix. This would allow 3GPP nodes to generate and use privacy addresses, and would be compatible with future IPv6 standards that may depend on the ability of IPv6 nodes to generate new interface identifiers for communication.
IPv6のWGはまた、3GPP規格は、各割り当てプレフィックス内で使用されるランダムに生成された識別子を含む複数の識別子を、可能にするように改変することをお勧めします。これは、3GPPノードが生成し、プライバシーのアドレスを使用できるようになる、との通信のための新しいインタフェース識別子を生成するためのIPv6ノードの能力に依存してもよい将来のIPv6標準規格と互換性があるでしょう。
This is a vital change, necessary to allow standards-compliant IPv6 nodes to connect to the Internet through 3GPP handsets, without modification. It is expected that most IPv6 nodes, including the most popular laptop stacks, will generate privacy addresses. The current 3GPP specifications will not be compatible with those implementations.
これは修正なしで標準に準拠したIPv6ノードは、3GPP携帯電話を介してインターネットに接続できるようにするために必要不可欠な変更、です。最も人気のあるラップトップ・スタックを含むほとんどのIPv6ノードは、プライバシーアドレスを生成することが期待されます。現在の3GPP仕様では、これらの実装と互換性がないであろう。
3 Additional IPv6 Work Items
3つの追加のIPv6の作業項目
During our work on this document, we have discovered several areas that could benefit from further informational or standards-track work within the IPv6 Working Group.
この文書で私たちの仕事中、当社は、IPv6ワーキンググループ内の更なる情報提供または標準トラック仕事から利益を得ることができるいくつかの領域を発見しました。
The IPv6 WG should work to define a point-to-point architecture and specify how the standard IPv6 address assignment mechanisms are applicable to IPv6 over point-to-point links. We should also review and clarify the IPv6 over PPP specification [PPP] to match the current IPv6 addressing architecture [ADDRARCH].
IPv6のWGは、ポイントツーポイントアーキテクチャを定義し、標準のIPv6アドレス割当メカニズムは、ポイントツーポイントリンク上でIPv6への適用方法を指定するために動作するはずです。また、[ADDRARCH]現在のIPv6アドレス体系に合わせて、[PPP] PPPの仕様上のIPv6を見直し、明確にすべきです。
The IPv6 WG should consider publishing an "IPv6 over PDP Contexts" (or similar) document. This document would be useful for developers writing drivers for IPv6 stacks to work over 3GPP PDP Contexts.
IPv6のWGは、「PDPコンテキスト上のIPv6」（または類似の）文書を公開検討すべきです。この文書は、IPv6が3GPP PDPコンテキスト上で動作するようにスタック用のドライバを書く開発者にとって有用であろう。
The IPv6 working group should undertake an effort to define the minimal requirements for all IPv6 nodes.
IPv6のワーキンググループは、すべてのIPv6ノードのための最低限の要件を定義するための努力を行う必要があります。
4 Security Considerations
4つのセキュリティの考慮事項
This document contains recommendations on the use of the IPv6 protocol in 3GPP standards. It does not specify a protocol, and it introduces no new security considerations.
このドキュメントは、3GPP規格におけるIPv6プロトコルの使用に関する推奨事項が含まれています。これは、プロトコルが指定されていない、そしてそれはどんな新しいセキュリティ問題も紹介しません。
Appendix A: Analysis of Findings
付録A：調査結果の分析
This section includes some analysis that may be useful to understanding why the IPv6 working group is making the above recommendations. It also includes some other options that were explored, and the reasons why those options were less suitable than the recommendations outlined above.
このセクションでは、IPv6ワーキンググループは、上記の提言を行っている理由を理解するのに有用である可能性があるいくつかの分析が含まれます。また、調査した他のいくつかのオプション、およびそれらのオプションは、上記で概説した勧告未満適していた理由を含んでいます。
A.1 Address Assignment Solutions
A.1アドレス割り当てソリューション
In order to allow for the configuration and use of multiple IPv6 addresses per primary PDP Context having different interface identifiers, some modifications to the current 3GPP specifications would be required.
異なるインタフェース識別子を有する一次PDPコンテキストごとに複数のIPv6アドレスの構成および使用を可能にするために、現在の3GPP仕様にいくつかの変更が必要とされるであろう。
The solutions to achieve this were evaluated against the following factors:
これを達成するためのソリューションは、以下の要因に対して評価しました。
- Scarcity and high cost of wireless spectrum - Complexity of implementation and state maintenance - Stability of the relevant IETF standards - Impact on current 3GPP standards
現在の3GPP標準規格への影響 - - 希少性及び無線スペクトルの高コスト - 実装と状態維持の複雑さ - 関連するIETF標準の安定性
Two solutions to allow autoconfiguration of multiple addresses on the same primary PDP Context were considered:
同じプライマリPDPコンテキストに複数のアドレスの自動構成を許可するには、2つの解決策が検討されました。
1. Assign one or more entire prefixes (/64s) to a PDP Context upon PDP Context activation and allow the autoconfiguration of multiple addresses.
1. PDPコンテキスト活性化の際にPDPコンテキストへの1つ以上の全体プレフィックス（/ 64S）を割り当て、複数のアドレスの自動設定を可能にします。
a) The assignment may be performed by having the GGSN advertise one or more /64 prefixes to the mobile device.
A）割り当ては、GGSNは、モバイルデバイスへの1つ以上の/ 64プレフィックスを広告有することによって行ってもよいです。
b) The assignment may be performed by building "prefix delegation" functionality into the PDP Context messages or by using layer 3 mechanisms such as [PREFDEL]. In this way, the prefix is not assigned to the link between the GGSN and the mobile device (as in 1a), but it is assigned to the mobile device itself. Note that [PREFDEL] cannot be considered stable and has not, at this stage, been adopted by the IPv6 WG as a WG document.
B）割り当てはPDPコンテキストメッセージに「プレフィックス委譲」機能を構築することにより、またはそのような[PREFDEL]などのレイヤ3つの機構を用いて行うことができます。このように、プレフィックスはGGSN及び（1aにおけるように）モバイルデバイスとの間のリンクに割り当てられていないが、それは、モバイルデバイス自体に割り当てられます。 【PREFDEL】安定したと考えることができないと、この段階で、WG文書としてのIPv6 WGによって採用されていないことに留意されたいです。
2. Share the same prefix between multiple PDP Contexts connected to the same GGSN (and APN). Given that mobile devices may generate multiple addresses using more than one interface identifier, this would require DAD for the newly generated addresses over the air interface, and a proxy DAD, function which would increase the complexity and the amount of state to be kept in the GGSN. Also, the GGSN would need to determine when the temporary addresses are no longer in use, which would be difficult. One possible solution could be using periodic unicast neighbor solicitations for the temporary addresses [IPV6ND].
2.同じGGSN（及びAPN）に接続された複数のPDPコンテキストの間で同じプレフィックスを共有します。モバイルデバイスが中に保持される、これはエアインタフェースを介して新たに生成されたアドレスに対するDAD、及び複雑さ及び状態の量を増加させるプロキシDAD、機能を必要とする複数のインタフェース識別子を使用して複数のアドレスを生成することができることを考えるとGGSN。一時アドレスが使用されなくなった場合にも、GGSNは難しいだろうどの、決定する必要がないだろう。一つの可能な解決策は、一時アドレス[IPV6ND]のために定期的なユニキャスト近隣要請を使用することができます。
Considering all the factors when evaluating the solutions, the recommendation is to use Solution 1a. This solution requires the least modification to the current 3GPP standards and maintains all the advantages of the other solutions.
ソリューションを評価する際に、すべての要因を考慮すると、勧告はソリューション部1aを使用することです。このソリューションは、現在の3GPP規格に少なくとも修正を必要とし、他のソリューションのすべての利点を維持します。
Effectively, this would mean that each APN in a GGSN would have a certain number of /64 prefixes that can be handed out at PDP context Activation, through Router Advertisements. Therefore, instead of using the full IPv6 address to identify a primary PDP context, the IPv6 WG recommends that the GGSN use the entire prefix (together with other 3GPP specific information) and that the SGSN be informed of the prefixes that are assigned to a PDP context. By assigning a given prefix to only one primary PDP context, the GGSN and SGSN can associate a prefix list with each PDP context, as needed.
効果的に、これは、GGSNの各APNは、ルータ広告を通して、PDPコンテキストアクティブ化で配布することができる/ 64プレフィックスの特定の数を有するであろうことを意味します。したがって、代わりに一次PDPコンテキストを識別するために、完全なIPv6アドレスを使用する、IPv6のWGは、GGSNが（一緒に他の3GPP特定の情報を含む）全体の接頭辞を使用することを推奨し、SGSNは、PDPに割り当てられているプレフィックスを通知すること状況。必要に応じて、1つのプライマリPDPコンテキストに指定されたプレフィックスを割り当てることによって、GGSN及びSGSNは、各PDPコンテキストにプレフィクスリストを関連付けることができます。
Note that the recommended solution does not imply or assume that the mobile device is a router. The MT is expected to use the /64 for itself and may also use this prefix for devices attached to it. However, this is not necessary if each device behind the MT is connected to a separate primary PDP Context and therefore can use a /64, which is not shared with other devices. The MT is also expected to handle DAD locally for devices attached to it (e.g., laptops) without forwarding Neighbor Solicitations over the air to the GGSN.
推奨される解決策は、暗示やモバイルデバイスがルータであることを想定していないことに注意してください。 MTは、自分自身のために/ 64を使用することが予想され、また、それに接続されたデバイスのために、この接頭辞を使用することができます。 MTの後ろに各装置が別々の一次PDPコンテキストに接続されており、したがって、他のデバイスと共有されていない/ 64を使用することができる場合は、これは必要ではありません。 MTはまた、GGSNに空中近隣要請を転送することなく、それに接続されたデバイスのための局所的DAD（例えば、ラップトップ）を処理することが期待されます。
References
リファレンス
[OLD-TS23060] TS 23.060, "General Packet Radio Service (GPRS); Service description; Stage 2", V4.1.0
[OLD-TS23060] TS 23.060、 "汎用パケット無線サービス（GPRS）;サービス解説;ステージ2"、V4.1.0
[NEW-TS23060] TS 23.060 version 3.11.0 (release 99), 4.4.0 (release 4) and 5.1.0 (release 5).
[NEW-TS23060] TS 23.060バージョン3.11.0（リリース99）、4.4.0（リリース4）及び5.1.0（リリース5）。
[3GPP-URL] http://www.3gpp.org
[3GPP-URL] http://www.3gpp.org
[IETF-URL] http://www.ietf.org
[IETF-URL] http://www.ietf.org
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1999.
[KEYWORD]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1999年3月。
[TR21905] 3GPP TR 21.905, "Vocabulary for 3GPP Specifications", V5.0.0
[TR21905] 3GPP TR 21.905、 "3GPP仕様のための語彙"、V5.0.0
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[NAT-PT] Tsirtsis, G. and P. Shrisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[ネットストレッチ] tsirtasisa、C。そして、指定します。 Srisuresa、 "ネットワークアドレス変換 - プロトコル変換（NAT-パット）"、RFC 2766、2000年2月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[PPP]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[SIIT] Nordmark, N., "Stateless IP/ICMP Translation Algorithm", RFC 2765, February 2000.
[SIIT] Nordmarkと、N.、 "ステートレスIP / ICMP翻訳アルゴリズム"、RFC 2765、2000年2月。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ADDRARCH] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[IPV6ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[IPV6ND] Narten氏、T.、Nordmarkと、E.およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998
[AUTOCONF]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月
[PRIVADDR] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[PRIVADDR] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[IPV6ETH] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[IPV6ETH]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[PPPv6] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[PPPv6] Haskin、D.およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 2472、1998年12月。
[MULTLINK] C. Huitema, D. Thaler, "Multi-link Subnet Support in IPv6", Work in Progress.
[MULTLINK] C.のHuitema、D.ターラー、 "IPv6でのマルチリンクサブネットのサポート" が進行中で働いています。
[SITEREN] C. Huitema, "IPv6 Site Renumbering", Work in Progress.
[SITEREN] C.のHuitema、 "IPv6のサイトリナンバリング" が進行中で働いています。
[HD] Durand, A. and C. Huitema, "The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio", RFC 3194, November 2001.
[HD]デュラン、A.およびC.のHuitema、「アドレス割り当ての効率化のためのホスト密度比：H比の更新」、RFC 3194、2001年11月。
[IABAA] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[IABAA] IAB、IESG、 "サイトへのIPv6アドレスの割り当てにIAB / IESG勧告"、RFC 3177、2001年9月。
[AAPOL] APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment Global Policy", Work in Progress.
[AAPOL] APNIC、ARIN、RIPE-NCC、 "IPv6アドレス割り振りおよび割り当てグローバルポリシー" が進行中で働いています。
[SCOPARCH] S. Deering, et. al., "IPv6 Scoped Address Architecture", Work in Progress.
【SCOPARCH] S.デアリング、ら。ら、「IPv6のスコープアドレスアーキテクチャ」が進行中で働いて。
[CELLREQ] J. Arkko, et. al., "Minimum IPv6 Functionality for a Cellular Host", Work in Progress.
【CELLREQ] J. Arkkoら。ら、「細胞宿主のための最小のIPv6機能」が進行中で働いています。
[PREFDEL] J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", Work in Progress.
[PREFDEL] J.マーチン、B.ハーバーマン、「インターネットプロトコルバージョン6（IPv6）のための自動プレフィックス委任議定書」が進行中で働いています。
Authors and Acknowledgements
著者と謝辞
This document was written by the IPv6 3GPP design team:
この文書は、IPv6の3GPPデザインチームによって書かれました：
Steve Deering, Cisco Systems EMail: deering@cisco.com
スティーブデアリング、シスコシステムズ電子メール：deering@cisco.com
Karim El-Malki, Ericsson Radio Systems EMail: Karim.El-Malki@era.ericsson.se
カリム・エルMalki、Eritsssonラジオシステムズ電子メール：Karim.El-Malki@era.eritssson.se
Paul Francis, Tahoe Networks EMail: francis@tahoenetworks.com
ポール・フランシス、タホNetworksのEメール：francis@tahoenetworks.com
Bob Hinden, Nokia EMail: hinden@iprg.nokia.com
ボブHindenと、ノキアのEメール：hinden@iprg.nokia.com
Christian Huitema, Microsoft EMail: huitema@windows.microsoft.com
クリスチャンのHuitema、マイクロソフトの電子メール：huitema@windows.microsoft.com
Niall Richard Murphy, Hutchison 3G EMail: niallm@enigma.ie
ニールリチャード・マーフィー、ハチソン3G Eメール：niallm@enigma.ie
Markku Savela, Technical Research Centre of Finland Email: Markku.Savela@vtt.fi
マルックSavela、フィンランドメールの技術研究センター：Markku.Savela@vtt.fi
Jonne Soininen, Nokia EMail: Jonne.Soininen@nokia.com
Jonne Soininen、ノキアのEメール：Jonne.Soininen@nokia.com
Margaret Wasserman, Wind River EMail: mrw@windriver.com
マーガレットワッサーマン、ウインドリバーEメール：mrw@windriver.com
Information was incorporated from a presentation co-authored by:
情報が共著のプレゼンテーションから取り込まれました。
Juan-Antonio Ibanez, Ericsson Eurolab
フアン・アントニオ・アイバニーズ、エリクソンEUROLAB
Editor's Address
編集者の住所
Comments or questions regarding this document should be sent to:
本書に関するコメントや質問がに送信する必要があります。
Margaret Wasserman Wind River 10 Tara Blvd., Suite 330 Nashua, NH 03062 USA
マーガレットワッサーマンウインドリバー10タラブルバード、スイート330ナシュア、ニューハンプシャー03062 USA
Phone: (603) 897-2067 EMail: mrw@windriver.com
電話：（603）897-2067 Eメール：mrw@windriver.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。