RFC3314 日本語訳
3314 Recommendations for IPv6 in Third Generation Partnership Project(3GPP) Standards. M. Wasserman, Ed.. September 2002. (Format: TXT=48168 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Wasserman, Ed. Request for Comments: 3314 Wind River Category: Informational September 2002
ワーキンググループのM.ワッサーマン、エドをネットワークでつないでください。コメントのために以下を要求してください。 3314年の風の川のカテゴリ: 情報の2002年9月
Recommendations for IPv6 in
Third Generation Partnership Project (3GPP) Standards
第三世代パートナーシッププロジェクト(3GPP)規格におけるIPv6のための推薦
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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の使用に関してインターネット・エンジニアリング・タスク・フォース(IETF)IPv6作業部会からThird Generation Partnership Project(3GPP)共同体までの推薦を含んでいます。 明確に、このドキュメントは、3GPPが、複数の接頭語がそれぞれのプライマリPDP文脈に割り当てられるかもしれないと指定することを勧めます、そして、1つ以上のプライマリ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作業部会はIPv6作業部会と3GPP共同体との開いている協力の精神で3GPPと申し出の中のIPv6の使用にこれらの推薦をサポートします。 インターネット草稿としてのこのドキュメントのオリジナルの公表以来、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[キーワード]で説明されるように本書では解釈されることであるべきです。
Wasserman Informational [Page 1] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[1ページ]のRFC3314Recommendations
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
1つの序論… 2 1.1 3GPPは何ですか? 3 1.2 IETFは何ですか? 4 1.3用語… 4 1.3.1 3GPP用語… 4 1.3 .2 IETF用語… 5 IPv6アドレッシング体系の1.4概要… 6 1.5 3GPPシステムのIP中心の視点… 7 1.5 UMTSアーキテクチャの.1概要… 7 1.5 .2 PDP文脈… 10 1.5 .3 IPv6はGPRSで自動構成を扱います… 11 3GPPへの2つの推薦… 13 3GPPの2.1の限界が課題を扱います… 13 2.2 複数の接頭語の広告を出します… 14 2.3 1つのプライマリPDP文脈だけに接頭語を割り当てます… 14 2.3 .1 PDP文脈あたり1/64があまりに多くですか? 15 2.3 .2 SGSNの情報を前に置いてください… 16 2.4 複数のPDP文脈あたりの識別子… 16 3 追加IPv6は項目を扱います… 16 4 セキュリティ問題… 17 付録A: 調査結果の分析… 18 課題ソリューションを扱ってください… 18の参照箇所… 19の作者と承認… 22エディタのアドレス… 22 完全な著作権宣言文… 23
1. Introduction
1. 序論
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の使用法の建築概要は3GPPの間、提示されました)。 そのミーティングでは、IPv6 WGから3GPP共同体までアドバイスを提供するドキュメントを書くためにデザインチームを形成するのを決定をしました、彼らのIPv6の使用に関して。 このドキュメントはその取り組みの結果です。
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に関する基礎的な情報を提供して、本書では議論した技術のハイレベルの概要を含んでいる序論(このセクション)。
Wasserman Informational [Page 2] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[2ページ]のRFC3314Recommendations
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に関する決定的な情報源ではありません。 私たちは、他のIETFプロトコル(すなわち、SIP、IPv4など)の3GPP関連の問題を探るのを選んでいません、IPv6作業部会の範囲の外にそれらがあるとき。
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.
3GPP implementersとオペレータがIETFプロセスに参加するようIPv6作業部会は3GPPの中でIPv6の使用を完全にサポートして、私たちは、奨励します。 私たちは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ドキュメントTS23.060バージョン4.1.0[OLD-TS23060]に基づいています。 2002年3月の3GPP全体会議TSG#15では、3GPPはIPv6の状態がないアドレス自動構成が、使用されて、端末が複数のインタフェース識別子を使用するのを許容しているとき、それぞれのプライマリPDP文脈にユニークな接頭語を割り当てて、本書では含まれた2つのプライマリ推薦を採用しました。 3GPPリリース99から前方へ適用されて、これらの変化はTS23.060バージョン3.11.0、4.4.0で遡及してそうであり、5.1は.0[NEW-TS23060]でした。
1.1 What is the 3GPP?
1.1 3GPPは何ですか?
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.
Third Generation Partnership Project(3GPP)は1998年後半に設立された国際基準化パートナーシップです。 Organizational Partnersは、Third GenerationのモバイルSystemのための技術仕様書の生産に協力するのに同意しました、発展されたGSMコアネットワークに基づいて。
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 Organizational Partnersはいくつかの異なった標準化組織から成ります: 日本のヨーロッパからのETSI、米国での規格委員会のT1テレコミュニケーション(T1)、中国のワイヤレスの電気通信標準のグループ(ハンドレッドウェイト)、韓国の電気通信技術協会(TTA)、電波産業会(ARIB)、および情報通信技術委員会(TTC)。
Wasserman Informational [Page 3] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[3ページ]のRFC3314Recommendations
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.
仕事は、Project Co-叙階式Group(PCG)によって調整されて、仕様書Groups(TSGs)に構造化されます。 5TSGsがあります: コアネットワーク(TSG CN)とラジオアクセスネットワーク(TSGは走った)とサービスとシステム局面(TSG SA)、GSM/縁のラジオはネットワーク(GERAN)、および端末(TSG T)にアクセスします。 TSGsはさらにWorking Groups(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ウェブサイト[3GPP-URL]を通ってアクセスできます。
1.2 What is the IETF?
1.2 IETFは何ですか?
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 URL]でIETFに関する詳しい情報を見つけることができます。
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は1年に3回の会合を開きます。
1.3 Terminology
1.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]からかかりました。
1.3.1 3GPP Terminology
1.3.1 3 GPP用語
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/縁のラジオアクセスネットワーク
Wasserman Informational [Page 4] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[4ページ]のRFC3314Recommendations
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.
UEとGGSNとのPDP Context A 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の普遍的な地球のラジオアクセスネットワーク
1.3.2 IETF Terminology
1.3.2 IETF用語
IPv6 Internet Protocol version 6 [RFC 2460]
IPv6インターネットプロトコルバージョン6[RFC2460]
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はプロトコル変換でアドレス変換をネットワークでつなぎます。 IPv6変遷メカニズム。 [太平洋標準時のNAT]
PPP Point-to-Point Protocol [PPP]
pppポイントツーポイントプロトコル[ppp]
SIIT Stateless IP/ICMP Transition Mechanism [SIIT]
SIITの状態がないIP/ICMP変遷メカニズム[SIIT]
Wasserman Informational [Page 5] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[5ページ]のRFC3314Recommendations
1.4 Overview of the IPv6 Addressing Architecture
1.4 IPv6アドレッシング体系の概要
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 Host Autoconfiguration[AUTOCONF]と呼ばれます、そして、IPv6ノードはそれがstateful構成サーバ(すなわち、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ホストはいつでも自由に新しい識別子を生成することができます、そして、Duplicate Address Detection(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は明らかに各アドレスをインタフェースに関連づけます。 複数のインタフェースホストは1個以上のリンクの上、または、1つ以上のサイトにインタフェースを持っているかもしれません。 リンクとサイトは、ゾーン識別子を使用することで内部的に特定されます。 非グローバルなトラフィックと適切なアドレス選択の適切なルーティングはアーキテクチャが[SCOPARCH]であると扱いながら見られたIPv6によって確実にされます。
Wasserman Informational [Page 6] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[6ページ]のRFC3314Recommendations
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.
仕様[SITEREN]に番号を付け替えさせるIPv6サイトは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ノードがダイナミックに新しいアドレスを作成するのに複数の接頭語、そして/または、複数の識別子を使用する能力を当てにされるかもしれません。
1.5 An IP-Centric View of the 3GPP System
1.5 3GPPシステムのIP中心の視点
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仕様はThird GenerationのモバイルSystemを定義します。 3GPP Release99システムのパケットの切り換えられた(PS)ドメインの概要は以下のセクションで説明されます。 この記述がUMTSパケットになじみがない読者に十分であるという作者の望みは、UMTSシステムがどのように動作するか、そして、IPv6が現在それの中で使用されるためにどのように定義されるかを理解するためにサービスを切り換えました。
1.5.1 Overview of the UMTS Architecture
1.5.1 UMTSアーキテクチャの概要
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ドメイン、またはPacket Radio Services司令官(GPRS)に集中するつもりです。
------
| TE |
------
|
+R
|
------ Uu ----------- Iu ----------- Gn ----------- Gi
| MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+--
------ ----------- ----------- -----------
(UE)
------ | Te| ------ | + R| ------ Uu----------- Iu----------- Gn----------- 兵士| MT|--+--| UTRAN|--+--| SGSN|--+--| GGSN|--+-- ------ ----------- ----------- ----------- (UE)
Figure 1: Simplified GPRS Architecture
図1: 簡易型のGPRSアーキテクチャ
Wasserman Informational [Page 7] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[7ページ]のRFC3314Recommendations
------ | | | 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 | ------ ------------- ------------- -------------
------ | | | 装置|- - - - - - - - - - - - - - - - - - - - - - - - -(装置同輩への) | | |------| ------------- | IP|- - - - - - - - - - - - - - - - - - - - - - -| IP|、-、>、| v4/6| | v4/6| |------| ------------- ------------- |------ | | | | \リレー/| | \リレー/| | | | | | | \ / | | \ / | | | | | | | \ / | | \ / | | | | | 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| 気圧|- - -| 気圧| L1|- - -| L1| L1| ------ ------------- ------------- -------------
UE UTRAN SGSN GGSN
(handset)
UE UTRAN SGSN GGSN(受話器)
Figure 2: GPRS Protocol Stacks
図2: GPRSプロトコル・スタック
Wasserman Informational [Page 8] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[8ページ]のRFC3314Recommendations
------
| |
| 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)
------ | | | 装置。 |- - - - - - - - - - - - - - - - - - - - - - (装置同輩への) | | |------| | | | IP|- - - - - - - - - - - - - - - - - - - - - - (GGSNへの) | v4/6| | | | | |------| |-------------| | | | \リレー/| | | | \ / | | | | \ / | | | | \/PDCP|- - - (UTRANへの) | | | | | | ppp|- - -| ppp|------| | | | | RLC|- - - (UTRANへの) | | | |------| | | | | Mac| |------| |------|------| | L1a|- - -| L1a| L1b|- - - (UTRANへの) ------ ------------- Te MT(ラップトップ)(受話器)
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コアネットワーク要素は、User Equipment(UE)と、Serving GPRS Support Node(SGSN)と、ゲートウェイGPRS Support Node(GGSN)です。 UTRANはRadio Access Network Controllers(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はNetwork Access Server(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ネットワークとそれを通して接続されます、ホームLocation Register(HLR)に、ユーザ・プロファイル取り扱い、認証、および承認を実行できるように。
Wasserman Informational [Page 9] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[9ページ]のRFC3314Recommendations
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: 同じくらい中のRNCと、SGSNとGGSNの間、または、異なったUMTSバックボーンの間にパケットを発送するのにUDP/IPをひいて、使用される簡単なトンネルプロトコル。 GTP-Uトンネルは各端のときにTunnel Endpoint Identifier(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システムの最もかなりの原理だけについて議論します。 [OLD-TS23060]でGPRSシステムに関する詳しい情報を見つけることができます。
1.5.2 The PDP Context
1.5.2 PDP文脈
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 Contextです。 PDP ContextはUEとGGSNの間との接続です。そこでは、パケットがわたっています。 2種類のPDP Contextsがあります--プライマリであって、セカンダリです。
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 Contextは初めは、GGSNへのリンクを定義します。 例えば、IPアドレスはそれぞれのプライマリPDP Contextに割り当てられます。 さらに、1セカンダリPDP ContextsをプライマリPDP Contextに加えることができます、同じIPアドレスを共有して。 これらのセカンダリPDP ContextsはServiceの特性のプライマリPDP Contextと異なったQualityを持つことができます。
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 Contextとゼロか、よりセカンダリのPDP Contextsが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.
現在、GPRSでサポートされた3PDP Typesがあります--IPv4、IPv6、およびPPP。 このドキュメントはIPv6 PDP Typeについて議論するだけでしょう。
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 Contextに実行できる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.
新しいPDP ContextをGGSNに開きます。 新しいプライマリPDP Contextが活性であるなら、UEとGGSNの間で作成された新しいリンクがあります。 UEは複数のプライマリPDP Contextsを1GGSNsまで開くことができます。
Modify PDP Context
PDP文脈を変更してください。
Changes the characteristics of a PDP Context, for example QoS
attributes.
PDP Contextの特性、例えばQoS属性を変えます。
Wasserman Informational [Page 10] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[10ページ]のRFC3314Recommendations
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 Contextとすべてのセカンダリ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は、端末によって要求されたAPNに役立つGGSN(s)を見つけるためにDNS質問を実行します。 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 ========- |
| | | | | |
| | | | | |
-------- --------- --------
--------- -------- | | | GGSN| | | リンク1| | | -======== PDP文脈A========- - - ->ISP X| | | | | | | | | | | | | /======= PDP文脈B=======\ | | - | リンク2| - - - ->ISP Y| \======= PDP文脈C=======/ | | | | | | MT| -------- |(受話器)| | | -------- -------- | | | GGSN| | | | | リンク3| | | | | -======== PDP文脈D========- | | Te| | | | | |(ラップトップ)| | | | - - ->ISP Z| | | | リンク4| | | -====ppp====-----======== PDP文脈E========- | | | | | | | | | | | | | -------- --------- --------
Figure 3: Correspondence of PDP Contexts to IPv6 Links
図3: IPv6リンクへのPDP文脈の通信
1.5.3 IPv6 Address Autoconfiguration in GPRS
1.5.3 GPRSでのIPv6アドレス自動構成
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です。 Statefulは、IPアドレス、例えば、DHCPに与えるサーバに接続するために構成用途に外部のプロトコルを扱います。
Wasserman Informational [Page 11] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[11ページ]のRFC3314Recommendations
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で異なって働いています。 GPRSノードには、どんなユニークな識別子もありませんが、イーサネットノードはそれらのEUI-48アドレスから識別子を作成できます。 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. SGSN(PDP Type=IPv6、PDP Address=0など)にActivate PDP Contextメッセージを送ります。
2. The SGSN sends a Create PDP Context message to the GGSN with
the above parameters.
2. SGSNは上記のパラメタがあるGGSNにCreate PDP Contextメッセージを送ります。
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 Contextのためのインタフェース識別子を選んで、リンクローカルアドレスを作成します。 それはCreate PDP Context応答でSGSNに答えます(PDP Addressはリンクローカルアドレスと等しいです)。
4. The SGSN sends an Activate PDP Context accept message to the UE
(PDP Address = link-local address).
4. SGSNは発信します。Activate PDP ContextはメッセージをUEに受け入れます(PDP Addressはリンクローカルアドレスと等しいです)。
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(最初のホップルータ)にRouter Solicitationメッセージを送るかもしれません。
6. After the PDP Context Activation, the GGSN sends a Router
Advertisement to the UE.
6. PDP Context Activationの後に、GGSNはRouter Advertisementを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は、Neighbor Solicitationメッセージを送らないように構成されるべきです。 しかしながら、1つを送ると、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
3GPPの中では、GGSNはただ一つの64ビットの識別子をそれぞれのプライマリPDP文脈に割り当てます。 また、GGSNはシングル/64接頭語の受話器に広告を出します、そして、これらの2つの項目がただ一つのIPv6アドレスに組み立てられます。 その後、GGSNは全体のIPv6アドレスを含むようにSGSNでPDP文脈エントリーを変更します、SGSNがそれぞれの3GPPノード(例えば、支払い目的のための)のただ一つのアドレスを知ることができるように。 また、このアドレスは、各パケットに関連しているPDP文脈を特定するのにGGSNで使用されます。 3GPPノードがそうしないと思われません。
Wasserman Informational [Page 12] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[12ページ]のRFC3314Recommendations
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.
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. そして1つ以上のプライマリ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 implementersとユーザに供給されるでしょう:
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.
3GPP受話器でIPv6プロトコルメカニズムへの少しも変更なしでIPv6ソフトウェア実行を使用できました。これで、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.
現在のアドレッシング体系の周りで築き上げられる新しいIPv6の特徴を利用するために、GPRSシステムは、よりいい、な位置にあるでしょう。
2.1 Limitations of 3GPP Address Assignment
3GPPの2.1の限界が課題を扱います。
The current 3GPP address assignment mechanism has the following limitations:
現在の3GPPアドレス割当機構には、以下の制限があります:
Wasserman Informational [Page 13] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[13ページ]のRFC3314Recommendations
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は1セットの接頭語よりむしろシングル/64接頭語の広告を出すだけです。 これは、複数の広告を出している接頭語に基づくアドレスを作成するために3GPPノード(例えば、受話器か3GPPが付属しているラップトップ)のIPv6サイトの番号を付け替える、または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ノードでプライバシーアドレスの使用を防ぐでしょう。 また、これで、3GPPメカニズムはポピュラーなラップトップIPv6スタックで不一致をもたらすIPv6ノードの予想された動きで完全に言いなりになるというわけではないようになります。 例えば、ウェブブラウザ接続にプライバシーアドレスを使用するラップトップは現在、3GPPリンクの上のウェブブラウザ接続を確立できませんでした。
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 Router Advertisementsの地方のリンクに1つ以上の接頭語の広告を出すことができました、そして、IPv6アドレスは組み立てることができました、必要に応じて、受話器かラップトップの上のIPv6スタックで。 そのままなGGSNはまだ現在3GPP規格で指定されていた状態でインタフェース識別子を割り当てることができました。 しかしながら、受話器かラップトップがプライバシーか他の理由に必要であるように追加識別子を生成するかもしれません。
2.2 Advertising Multiple Prefixes
2.2 複数の接頭語の広告を出すこと。
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リンクの上にサイトローカルの接頭語の広告を出すことができました、望まれているなら、グローバルな接頭語情報(例えば、サイトの番号を付け替える)への変化を乗り切ることができたサイトで制約つきなコミュニケーションを考慮して。
2.3 Assigning a Prefix to Only One Primary PDP Context
2.3 1つのプライマリPDP文脈だけに接頭語を割り当てること。
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文脈をただ一つのサブネットであるとみなすことを勧めます。 それに従って、与えられたグローバルで(サイト地方)の接頭語を1つ以上のPDP文脈に割り当てるべきではありません。
Wasserman Informational [Page 14] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[14ページ]のRFC3314Recommendations
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は、1以上/64の接頭語がそれぞれのプライマリPDP文脈に割り当てられるべきであることを勧めます。 これは、アドレスをプライバシーに割り当てる、そして/または、[MULTLINK]をマルチリンクサブネットに発送するために3GPPが添付のノードのための十分なアドレス空間を許容して、3GPPが付属しているデバイスの中にNATの使用に水をさしているでしょう。
2.3.1 Is a /64 per PDP Context Too Much?
2.3.1 PDP文脈あたり1/64があまりに多くですか?
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文脈あたり1/64を割り当てるなら、私たちは何百万個ものモバイル機器のための十分なアドレス空間があると確信できますか? アドレス課題効率[HD]にHost Density(HD)比を使用することで積極的でこの質問に答えることができます。 これは実際に、容易にホストに割り当てることができるアドレスの数の基準です、様々なアドレス課題プロセスから生じる用法で非能率を考慮に入れて。 実際の電話番号とデータ網アドレス課題ケースからHD比を経験して得ました。
We can calculate the number of easily assignable /64's making the following assumptions:
私たちは容易にassignable /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(RFC2373によって定義されたAggregatable Global Unicast Addresses)があるアドレスだけが使用されています、「割り当て-可能」アドレス空間の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×10^12)/64が前に置く490兆を割り当てることができます。 これは今日、地球で1人あたりおよそ8万PDP Contextsに翻訳されます。 これらの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推薦を参照してください。
Wasserman Informational [Page 15] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[15ページ]のRFC3314Recommendations
2.3.2 Prefix Information in the SGSN
2.3.2 SGSNの接頭語情報
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は、支払い目的などに使用されるためにただ一つのIPv6アドレスをSGSNに送ることができます。
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文脈に接頭語リストを関連づけることができます。
2.4 Multiple Identifiers per PDP Context
2.4 複数の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 Contextsの上で働かせるドライバーに書いている開発者の役に立つでしょう。
The IPv6 working group should undertake an effort to define the minimal requirements for all IPv6 nodes.
IPv6ワーキンググループは、すべてのIPv6ノードのための最小量の要件を定義するために取り組みを引き受けるべきです。
Wasserman Informational [Page 16] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[16ページ]のRFC3314Recommendations
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プロトコルの使用に推薦を含んでいます。 それはプロトコルを指定しません、そして、どんな新しいセキュリティ問題も紹介しません。
Wasserman Informational [Page 17] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[17ページ]のRFC3314Recommendations
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 Contextあたりの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 Contextに関する複数のアドレスの自動構成を許す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 Context起動のときに1つ以上の全体の接頭語(/64年代)をPDP Contextに割り当ててください、そして、複数のアドレスの自動構成を許してください。
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 Contextメッセージに組み込むか、または[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
2. 同じGGSN(そして、APN)に接続された複数のPDP Contextsの間の同じ接頭語を共有してください。 モバイル機器が1つ以上のインタフェース識別子を使用することで複数のアドレスを作るかもしれないなら、これは新たに生成しているアドレスのために空気インタフェース、およびプロキシDADの上でDADを必要とするでしょう、複雑さと状態の量を増強する機能
Wasserman Informational [Page 18] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[18ページ]のRFC3314Recommendations
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].
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文脈Activationで与えることができるある数の/64接頭語があることを意味するでしょう、Router Advertisementsを通して。 したがって、プライマリ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 Contextに接続されて、したがって、/64(対向機器と共有されません)を使用できるなら、これは必要ではありません。 また、MTがそれ(例えば、ラップトップ)に取り付けられたデバイスのために空気の上で推進Neighbor SolicitationsなしでGGSNにDADを局所的に扱うと予想されます。
References
参照
[OLD-TS23060] TS 23.060, "General Packet Radio Service (GPRS);
Service description; Stage 2", V4.1.0
[古いTS23060] t23.060、「汎用パケット無線システム(GPRS)」。 記述を修理してください。 V4.1.0、2インチを上演してください。
[NEW-TS23060] TS 23.060 version 3.11.0 (release 99), 4.4.0 (release
4) and 5.1.0 (release 5).
99、)4.4をリリースしてください。[NEW-TS23060]TS23.060バージョン3.11.0、(.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インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月」
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1999.
[KEYWORD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1999年3月。
Wasserman Informational [Page 19] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[19ページ]のRFC3314Recommendations
[TR21905] 3GPP TR 21.905, "Vocabulary for 3GPP Specifications",
V5.0.0
[TR21905]3GPP TR21.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)仕様」、RFC2460、12月1998日
[NAT-PT] Tsirtsis, G. and P. Shrisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[太平洋標準時のNAT]TsirtsisとG.とP.Shrisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べる」、RFC2766、2000年2月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[ppp]シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[SIIT] Nordmark, N., "Stateless IP/ICMP Translation
Algorithm", RFC 2765, February 2000.
[SIIT] Nordmark、N.、「状態がないIP/ICMP変換アルゴリズム」、RFC2765、2000年2月。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[ADDRARCH] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、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)のための隣人発見」、RFC2461、1998年12月。
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998
[AUTOCONF] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、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"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[IPV6ETH] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[IPV6ETH] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[PPPv6] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
2472, December 1998.
[PPPv6] ハスキンとD.とE.アレン、「pppの上のIPバージョン6」、RFC2472、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比に関する最新情報」、RFC3194、2001年11月。
[IABAA] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[IABAA] IAB、IESG、「サイトへのIPv6アドレス配分のIAB/IESG推薦」、RFC3177、2001年9月。
Wasserman Informational [Page 20] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[20ページ]のRFC3314Recommendations
[AAPOL] APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and
Assignment Global Policy", Work in Progress.
ARINと、熟しているNCCと、「IPv6アドレス配分と課題のグローバルな方針」という[AAPOL]APNICは進行中で働いています。
[SCOPARCH] S. Deering, et. al., "IPv6 Scoped Address
Architecture", Work in Progress.
et[SCOPARCH]S.デアリング、アル、「IPv6はアドレス体系を見た」ProgressのWork。
[CELLREQ] J. Arkko, et. al., "Minimum IPv6 Functionality for a
Cellular Host", Work in Progress.
et[CELLREQ]J.Arkko、アル、「セルホストにとって、最小のIPv6の機能性」、ProgressのWork。
[PREFDEL] J. Martin, B. Haberman, "Automatic Prefix Delegation
Protocol for Internet Protocol Version 6 (IPv6)", Work
in Progress.
[PREFDEL] J.マーチン、B.ハーバーマン、「インターネットプロトコルバージョン6(IPv6)のための自動接頭語委譲プロトコル」は進行中で働いています。
Wasserman Informational [Page 21] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[21ページ]のRFC3314Recommendations
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、エリクソンラジオシステムはメールされます: Karim.El-Malki@era.ericsson.se
Paul Francis, Tahoe Networks EMail: francis@tahoenetworks.com
ポール・フランシス、タホネットワークはメールされます: francis@tahoenetworks.com
Bob Hinden, Nokia EMail: hinden@iprg.nokia.com
ボブHinden、ノキアメール: 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 EMail: 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、ノキアメール: 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
ホアン-アントニオ・イバニェス、エリクソン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の太良Blvd.、Suite330ナッシュア、ニューハンプシャー03062米国
Phone: (603) 897-2067 EMail: mrw@windriver.com
以下に電話をしてください。 (603) 897-2067 メールしてください: mrw@windriver.com
Wasserman Informational [Page 22] RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002
3GPP規格2002年9月のIPv6のためのワッサーマン情報[22ページ]のRFC3314Recommendations
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Wasserman Informational [Page 23]
ワッサーマンInformationalです。[23ページ]
一覧
スポンサーリンク
