[要約] RFC 3314は、3GPP標準におけるIPv6の推奨事項をまとめたものであり、IPv6の導入と運用に関するガイドラインを提供しています。このRFCの目的は、3GPPネットワークにおけるIPv6の効果的な利用を促進し、ネットワークのパフォーマンスと拡張性を向上させることです。
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
第三世代パートナーシッププロジェクト（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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（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.
このドキュメントには、インターネットエンジニアリングタスクフォース（IETF）IPv6ワーキンググループから、3GPP標準でのIPv6の使用に関する第3世代パートナーシッププロジェクト（3GPP）コミュニティへの推奨事項が含まれています。具体的には、このドキュメントでは、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [キーワード]に記載されているように解釈される。
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の使用について議論しました。会議の初日は3GPPとの共同議論であり、その間に3GPPのIPv6の使用に関するアーキテクチャの概要が提示され、3GPP内のIPv6使用の特定の側面に関する多くの議論がありました。その会議では、IPv6の使用に関するIPv6 WGから3GPPコミュニティへのアドバイスを提供するドキュメントを書くための設計チームを設立する決定が下されました。この文書は、その努力の結果です。
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.
1. IETF IPv6 WGおよび3GPPに関する背景情報を提供し、このドキュメントで説明したテクノロジーの高レベルの概要を含む紹介（このセクション）。
2. Recommendations from the IPv6 WG to the 3GPP community. These can be found in section 2.
2. IPv6 WGから3GPPコミュニティへの推奨事項。これらはセクション2にあります。
3. Further work items that should be considered by the IPv6 WG. These items are discussed in section 3.
3. IPv6 WGが考慮すべきさらなる作業項目。これらの項目については、セクション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.
このドキュメントの目的は、IPv6ワーキンググループから3GPPコミュニティにアドバイスを提供することです。このドキュメントの内容は、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の使用を完全にサポートしており、3GPPの実装者とオペレーターがIETFプロセスに参加することをお勧めします。私たちは、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]に基づいています。2002年3月の3GPP全体会議TSG＃15で、3GPPはこのドキュメントに含まれる2つの主要な推奨事項を採用し、IPv6 StatelessアドレスAutoconfigurationを使用した場合に各プライマリPDPコンテキストに一意のプレフィックスを割り当て、端子が複数のインターフェイス識別子を使用できるようにします。。これらの変更は、TS23.060バージョン3.11.0、4.4.0、および5.1.0 [New-TS23060]で、3GPPリリース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.
第3世代パートナーシッププロジェクト（3GPP）は、1998年後半に設立されたグローバル標準化パートナーシップです。その組織パートナーは、進化したGSMコアネットワークに基づいて、第3世代のモバイルシステムの技術仕様の生産を協力することに同意しています。
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/エッジラジオアクセスネットワーク（GERAN）、および端子（TSG T）の5つのTSGがあります。TSGはさらにワーキンググループ（WGS）に分割されます。技術作業はワーキンググループで行われ、後にTSGSで承認されます。
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 Webサイト[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）は、インターネットアーキテクチャの進化とインターネットのスムーズな運用に関係する、ネットワーク設計者、オペレーター、ベンダー、および研究者の大規模でオープンな国際コミュニティです。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は年間3回会議を開催します。
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 GGSN Gateway GPRS Support Node. A router between the GPRS network and an external network (i.e., the Internet).
Geran GSM/Edge Radio Access Network GGSNゲートウェイGPRSサポートノード。GPRSネットワークと外部ネットワーク（つまり、インターネット）の間のルーター。
GPRS General Packet Radio Services
GPRS General Packet Radio Services
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
SGSNサービングGPRSサポートノード
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ユニバーサルサブスクライバーIDモジュール。通常、携帯電話の携帯電話に挿入されたカード。
UTRAN Universal Terrestrial Radio Access Network
ユトランユニバーサル地上ラジオアクセスネットワーク
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]
SIIT STATELESSIP/ICMP遷移メカニズム[SIIT]
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ホストAutoconfiguration [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ホストはいつでも新しい識別子を生成でき、1つのリンク[IPv6nd]で複製識別子の使用から保護するために、複製アドレス検出（DAD）が使用されます。
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]。Link-Localアドレスは、IPv6ルーターが存在しない場合でも、ローカル通信を可能にします。一部のIPv6プロトコル（つまり、ルーティングプロトコル）には、リンクローカルアドレスの使用が必要です。Site-Localアドレス指定により、通信を1つのサイト内に管理的に含めることができます。Link-LocalまたはSite-Local Connectionsは、グローバルプレフィックス情報の変更に耐えることもあります（例：サイトの変更）。
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仕様は、第3世代のモバイルシステムを定義します。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つの主要なドメインの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)
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コアネットワーク要素は、ユーザー機器（UE）であり、GPRSサポートノード（SGSN）を提供し、ゲートウェイGPRSサポートノード（GGSN）を提供しています。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は、SS7ネットワークに接続され、それを通じてホームロケーションレジスタ（HLR）に接続されているため、ユーザープロファイルの処理、認証、および承認を実行できます。
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バックボーン内の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コンテキストをプライマリPDPコンテキストに追加して、同じIPアドレスを共有できます。これらの二次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コンテキストは等しいステータスになります。つまり、同じIPアドレスに対してアクティブにアクティブになっている限り、UEとGGSNの間のリンクを保持しながら、プライマリPDPコンテキストを削除できます。
There are currently three PDP Types supported in GPRS -- IPv4, IPv6, and PPP. This document will only discuss the IPv6 PDP Type.
現在、GPRSでサポートされている3つのPDPタイプのIPv4、IPv6、およびPPPがあります。このドキュメントでは、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コンテキストで実行できる3つの基本的なアクションがあります：PDPコンテキストのアクティベーション、変更、および非アクティブ化。これらのアクションは、以下で説明されています。
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.
GGSNに新しいPDPコンテキストを開きます。新しいプライマリPDPコンテキストがアクティブになっている場合、UEとGGSNの間に新しいリンクが作成されます。UEは、1つ以上のGGSNに複数のプライマリPDPコンテキストを開くことができます。
Modify PDP Context
PDPコンテキストを変更します
Changes the characteristics of a PDP Context, for example QoS attributes.
QoS属性など、PDPコンテキストの特性を変更します。
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.
PDPコンテキストを非アクティブ化します。プライマリPDPコンテキストとそれに関連するすべての二次PDPコンテキストが無効になっている場合、UEとGGSNの間のリンクが削除されます。
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はDNSクエリを実行して、端末が要求したAPNを提供するGGSNを見つけます。DNS応答には、SGSNが1つ（ラウンドロビンの方法で）を選択する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は、静的および動的アドレスの割り当てをサポートします。2種類の動的アドレス割り当てがサポートされています - ステートレスとステートフル。Statefulアドレス構成は、外部プロトコルを使用して、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 Autoconfigurationは、GPRSの方がイーサネットネットワークとは異なる動作をします。GPRSノードには一意の識別子はありませんが、イーサネットノードはEUI48アドレスから識別子を作成できます。GPRSネットワークはダイヤルアップネットワークに似ているため、GPRSのステートレスアドレスAutoconfigurationはPPPv6 [PPPV6]に基づいていました。
3GPP address autoconfiguration has the following steps:
3GPPアドレスAutoconfigurationには次の手順があります。
1. The Activate PDP Context message is sent to the SGSN (PDP Type=IPv6, PDP Address = 0, etc.).
1. Activate PDPコンテキストメッセージはSGSNに送信されます（PDP Type = IPv6、PDPアドレス= 0など）。
2. The SGSN sends a Create PDP Context message to the GGSN with the above parameters.
2. SGSNは、上記のパラメーターを使用して、create pdpコンテキストメッセージをGGSNに送信します。
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).
3. GGSNは、PDPコンテキストのインターフェイス識別子を選択し、Link-Localアドレスを作成します。Create PDPコンテキスト応答（PDPアドレス= Link-Localアドレス）でSGSNに回答します。
4. The SGSN sends an Activate PDP Context accept message to the UE (PDP Address = link-local address).
4. SGSNは、Activate PDPコンテキストをUEに受け入れるメッセージを送信します（PDPアドレス= link-localアドレス）。
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).
5. UEはリンクローカルアドレスを保持し、後で使用するためにインターフェイス識別子を抽出します。UEは、ルーター勧誘メッセージをGGSN（First Hopルーター）に送信する場合があります。
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は、近隣の勧誘メッセージを送信しないように構成する必要があります。ただし、送信された場合、GGSNは静かに廃棄します。
8. The GGSN updates the SGSN with the whole IPv6 address.
8. GGSNは、IPv6アドレス全体でSGSNを更新します。
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のPDPコンテキストエントリを変更してIPv6アドレス全体を含め、SGSNが各3GPPノードの単一アドレスを知ることができるようにします（請求目的など）。このアドレスは、各パケットに関連付けられたPDPコンテキストを識別するためにGGSNでも使用されます。3GPPノードは、GGSNによって割り当てられた単一の識別子/プレフィックスの組み合わせを除き、アドレスを生成しないと想定されています。GGSNは複数のノードに同じアドレスを割り当てないため、お父さんは実行されません。
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がGPR内での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サイトの変更またはIPv6ホストが複数の宣伝されたプレフィックスに基づいてアドレスを作成することを期待する他のメカニズムに、3GPPノード（携帯電話や3GPP接続ラップトップなど）の参加が妨げられます。
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ノードによるプライバシーアドレスの使用が妨げられます。これにより、3GPPメカニズムがIPv6ノードの予想される動作に完全に準拠していないようになり、人気のあるラップトップIPv6スタックと非互換性が生じます。たとえば、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ルーター広告のローカルリンクの1つ以上のプレフィックスを宣伝することができ、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がプライマリPDPコンテキストとそのセカンダリPDPコンテキストを単一のIPv6リンクとして扱い、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は、各プライマリPDPコンテキストに1つ以上の /64プレフィックスを割り当てることを推奨しています。これにより、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コンテキストごとにA /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比（特に困難なく達成できる効率を表します）。
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.
これらの仮定を使用して、合計490兆（490x10^12） /64プレフィックスを割り当てることができます。これは、今日の地球上の1人あたり約80,000の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つのプレフィックスと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.
完全なIPv6アドレスを使用してPDPコンテキストを識別する代わりに、IPv6 WGは、現在PDPコンテキストに割り当てられている各プレフィックスをSGSNに通知することを推奨します。プレフィックスを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
追加の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に適用できる方法を指定するように機能する必要があります。また、現在のIPv6アドレス指定アーキテクチャ[AddRarch]に一致するように、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ワーキンググループが上記の推奨事項を作成している理由を理解するのに役立つ分析が含まれています。また、調査された他のオプションと、これらのオプションが上記の推奨事項よりも適していない理由も含まれています。
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
- ワイヤレススペクトルの希少性と高コスト - 実装と状態メンテナンスの複雑さ - 関連するIETF標準の安定性 - 現在の3GPP標準への影響
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つ以上のプレフィックス（/64）を割り当て、複数のアドレスの自動構成を可能にします。
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のように）に割り当てられていませんが、モバイルデバイス自体に割り当てられます。[プリフデル]は安定していると見なすことができず、この段階ではIPv6 WGによって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が必要になります。ggsn。また、GGSNは、一時的なアドレスがいつ使用されなくなったかを判断する必要がありますが、これは困難です。考えられる解決策の1つは、一時的なアドレスに定期的なユニキャスト隣接の勧誘を使用することです[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プレフィックスがあることを意味します。したがって、完全なIPv6アドレスを使用してプライマリPDPコンテキストを識別する代わりに、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コンテキストに接続されているため、他のデバイスと共有されていないA /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、 "General Packet Radio Service（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] Bradner、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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Deering、S。and 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.
[Nat-Pt] Tsirtsis、G。およびP. Shrisuresh、「ネットワークアドレス変換 - プロトコル翻訳（NAT-PT）」、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。、「Stateless IP/ICMP翻訳アルゴリズム」、RFC 2765、2000年2月。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Addrarch] Hinden、R。and S. Deering、「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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998
[Autoconf] Thomson、S。and T. Narten、「IPv6 Stateless Address Autoconfiguration」、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のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[IPV6ETH] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[IPv6eth] Crawford、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. Allen、「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。Thaler、「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] Durand、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.ディアリング、他al。、「IPv6スコープアドレスアーキテクチャ」、進行中の作業。
[CELLREQ] J. Arkko, et. al., "Minimum IPv6 Functionality for a Cellular Host", Work in Progress.
[Cellreq] J. Arkko、他al。、「セルラー宿主の最小IPv6機能」、進行中の作業。
[PREFDEL] J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", Work in Progress.
[Prefdel] J. Martin、B。Haberman、「インターネットプロトコルバージョン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
Steve Deering、Cisco Systems Email：Deeering@cisco.com
Karim El-Malki, Ericsson Radio Systems EMail: Karim.El-Malki@era.ericsson.se
Karim El-Malki、Ericsson Radio Systems Email：Karim.el-malki@era.ericsson.se
Paul Francis, Tahoe Networks EMail: francis@tahoenetworks.com
Paul Francis、Tahoe Networksメール：francis@tahoenetworks.com
Bob Hinden, Nokia EMail: hinden@iprg.nokia.com
ボブ・ヒンデン、ノキアメール：hinden@iprg.nokia.com
Christian Huitema, Microsoft EMail: huitema@windows.microsoft.com
Christian Huitema、Microsoftメール：huitema@windows.microsoft.com
Niall Richard Murphy, Hutchison 3G EMail: niallm@enigma.ie
Niall Richard Murphy、Hutchison 3Gメール：niallm@enigma.ie
Markku Savela, Technical Research Centre of Finland Email: Markku.Savela@vtt.fi
フィンランドのテクニカルリサーチセンター、マーククサベラメール：markku.savela@vtt.fi
Jonne Soininen, Nokia EMail: Jonne.Soininen@nokia.com
Jonne Soininen、Nokiaメール：jonne.soininen@nokia.com
Margaret Wasserman, Wind River EMail: mrw@windriver.com
マーガレットワッサーマン、ウィンドリバーメール：mrw@windriver.com
Information was incorporated from a presentation co-authored by:
情報は、次のように共同執筆したプレゼンテーションから組み込まれました。
Juan-Antonio Ibanez, Ericsson Eurolab
Juan-Antonio Ibanez、Ericsson 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ナシュア、NH 03062 USA
Phone: (603) 897-2067 EMail: mrw@windriver.com
電話：（603）897-2067メール：mrw@windriver.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。