RFC3316 日本語訳
3316 Internet Protocol Version 6 (IPv6) for Some Second and ThirdGeneration Cellular Hosts. J. Arkko, G. Kuijpers, H. Soliman, J.Loughney, J. Wiljakka. April 2003. (Format: TXT=48741 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Arkko
Request for Comments: 3316 G. Kuijpers
Category: Informational H. Soliman
Ericsson
J. Loughney
J. Wiljakka
Nokia
April 2003
Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3316年のG.Kuijpersカテゴリ: 情報のH.のJ.Loughney J.Wiljakkaノキアソリマンエリクソン2003年4月
Internet Protocol Version 6 (IPv6)
for Some Second and Third Generation Cellular Hosts
何らかの2番目のためのインターネットプロトコルバージョン6(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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks.
2番目と第三世代セルラー・ネットワークの展開が進歩をするとき、多くのセルホストがインターネットに接続されています。 標準化組織はインターネットプロトコルをそれらの仕様で義務的なバージョン6(IPv6)にしています。 しかしながら、IPv6の概念は多くの局面と多数の仕様を含んでいます。 さらに、帯域幅、費用、および遅れに関するセルリンクの特性はIPv6がどう使用されているかに特別な要件を置きます。 このドキュメントは汎用パケット無線システム(GPRS)に付くセルホスト、またはUniversalのモバイルTelecommunications System(UMTS)ネットワークのためにIPv6を考えます。 これらのネットワークで作動するとき、このドキュメントは、また、IPv6の機能性の基本的な成分を記載して、これらのコンポーネントの使用に関連するいくつかの問題について議論します。
Arkko, et al. Informational [Page 1] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[1ページ]のRFC3316IPv6
Table of Contents
目次
1. Introduction.....................................................3
1.1 Scope of this Document......................................3
1.2 Abbreviations...............................................4
1.3 Cellular Host IPv6 Features.................................5
2. Basic IP.........................................................5
2.1 RFC1981 - Path MTU Discovery for IP Version 6...............5
2.2 RFC3513 - IP Version 6 Addressing Architecture..............6
2.3 RFC2460 - Internet Protocol Version 6.......................6
2.4 RFC2461 - Neighbor Discovery for IPv6.......................7
2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration..........8
2.6 RFC2463 - Internet Control Message Protocol for the IPv6....8
2.7 RFC2472 - IP version 6 over PPP.............................9
2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification....9
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6.......9
2.10 RFC2711 - IPv6 Router Alert Option.........................10
2.11 RFC3041 - Privacy Extensions for Address Configuration
in IPv6 .........................................10
2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)......10
2.13 RFC3484 - Default Address Selection for IPv6...............11
2.14 DNS........................................................11
3. IP Security.....................................................11
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication...12
3.2 RFC2401 - Security Architecture for the Internet Protocol..12
3.3 RFC2402 - IP Authentication Header.........................12
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH.........12
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH.........12
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With
Explicit IV......................................12
3.7 RFC2406 - IP Encapsulating Security Payload (ESP)..........12
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP..........12
3.9 RFC2408 - The Internet Security Association and Key
Management Protocol..............................13
3.10 RFC2409 - The Internet Key Exchange (IKE)..................13
3.11 RFC2410 - The NULL Encryption Algorithm & its Use
With IPsec.......................................14
3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms...............14
4. Mobility........................................................14
5. Security Considerations.........................................14
6. References......................................................16
6.1 Normative..................................................16
6.2 Informative................................................18
7. Contributors....................................................19
8. Acknowledgements................................................19
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model.......20
Authors' Addresses.................................................21
Full Copyright Statement...........................................22
1. 序論…3 1.1 このDocumentの範囲…3 1.2の略語…4 1.3 セルホストIPv6の特徴…5 2. 基本的なIP…5 2.1 RFC1981--IPバージョン6のための経路MTU発見…5 2.2 RFC3513--IPバージョン6アドレッシング体系…6 2.3 RFC2460--インターネットプロトコルバージョン6…6 2.4 RFC2461--IPv6のための隣人発見…7 2.5 RFC2462--IPv6の状態がないアドレス自動構成…8 2.6 RFC2463--IPv6のためのインターネット規制メッセージプロトコル…8 2.7 RFC2472--PPPの上のIPバージョン6…9 2.8 RFC2473--IPv6仕様によるジェネリックパケットトンネリング…9 2.9 RFC2710--IPv6のためのマルチキャストリスナー発見(MLD)…9 2.10 RFC2711--IPv6ルータ警戒オプション…10 2.11 RFC3041--IPv6でのアドレス構成のためのプライバシー拡大…10 2.12 IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル…10 2.13 RFC3484--IPv6のためのデフォルトアドレス選択…11 2.14DNS…11 3. IPセキュリティ…11 3.1RFC2104--HMAC、: 通報認証のための合わせられた論じ尽くすこと…12 3.2 RFC2401--インターネットプロトコルのためのセキュリティー体系。12 3.3 RFC2402--IP認証ヘッダー…そして、12 3.4RFC2403--超能力の中のHMAC-MD5-96の使用、ああ…そして、12 3.5RFC2404--超能力の中のHMAC-SHA-96の使用、ああ…12 3.6 RFC2405--超能力DES-CBCは明白なIVがあるアルゴリズムを解きます…12 3.7 RFC2406--IPのカプセル化しているセキュリティ有効搭載量(超能力)…12 3.8 RFC2407--ISAKMPのためのインターネットIPセキュリティDoI…12 3.9 RFC2408--インターネットセキュリティ協会とKey Managementは議定書を作ります…13 3.10 RFC2409--インターネット・キー・エクスチェンジ(IKE)…13 3.11 RFC2410--NULL Encryption AlgorithmとそのUse With IPsec…14 3.12 RFC2451--超能力CBC-モード暗号アルゴリズム…14 4. 移動性…14 5. セキュリティ問題…14 6. 参照…16 6.1 標準…16 6.2 有益…18 7. 貢献者…19 8. 承認…19 付録A--中で3GPPを扱う携帯電話ホストIPv6がモデル化します…20人の作者のアドレス…21 完全な著作権宣言文…22
Arkko, et al. Informational [Page 2] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[2ページ]のRFC3316IPv6
1 Introduction
1つの序論
Technologies such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System) and CDMA2000 (Code Division Multiple Access 2000) are making it possible for cellular hosts to have an always-on connection to the Internet. IPv6 becomes necessary, as it is expected that the number of such cellular hosts will increase rapidly. Standardization organizations working with cellular technologies have recognized this and are making IPv6 mandatory in their specifications.
GPRS(汎用パケット無線システム)や、UMTS(普遍的なモバイルTelecommunications System)やCDMA2000(符号分割多重アクセス方式2000)などの技術はセルホストがインターネットに常時接続を持っているのを可能にすることです。 そのようなセルホストの数が雨後の竹の子のように出ると予想されるとき、IPv6は必要になります。 携帯電話技術で働いている標準化組織は、これを認識して、IPv6をそれらの仕様で義務的にしています。
Support for IPv6 and the introduction of UMTS starts with 3GPP Release 99 networks and hosts. IPv6 is specified as the only IP version supported for IP Multimedia Subsystem (IMS) starting from Release 5.
IPv6のサポートとUMTSの導入は3GPP Release99ネットワークとホストから始まります。 Release5から始めて、唯一のIPバージョンがIPのために、Multimedia Subsystem(IMS)をサポートしたので、IPv6は指定されます。
1.1 Scope of this Document
1.1 このDocumentの範囲
For the purposes of this document, a cellular interface is considered to be the interface to a cellular access network based on the following standards: 3GPP GPRS and UMTS Release 99, Release 4, Release 5, as well as future UMTS releases. A cellular host is considered to be a host with such a cellular interface.
このドキュメントの目的のために、セルインタフェースは以下の規格に基づくセルアクセスネットワークへのインタフェースであると考えられます: 3GPP GPRS、UMTS Release99、Release4、Release5、および今後のUMTSリリース。 セルホストはそのようなセルインタフェースをもっているホストであると考えられます。
This document lists IPv6 specifications with discussion on the use of these specifications when operating over cellular interfaces. Such a specification is necessary in order for the optimal use of IPv6 in a cellular environment. The description is made from a cellular host point of view. Important considerations are given in order to eliminate unnecessary user confusion over configuration options, ensure interoperability and to provide an easy reference for those implementing IPv6 in a cellular host. It is necessary to ensure that cellular hosts are good citizens of the Internet.
セルインタフェースの上で作動するとき、このドキュメントはこれらの仕様の使用についての議論でIPv6仕様をリストアップします。 そのような仕様がセル環境におけるIPv6の最適の使用の注文で必要です。 セルホスト観点から記述をします。 設定オプションの上の不要なユーザ混乱を排除して、相互運用性を確実にして、セルホストでIPv6を実装するものの簡単な参照を提供するために重要な問題を与えます。 セルホストが良いインターネット市民であることを保証するのが必要です。
This document is informational in nature, and it is not intended to replace, update, or contradict any IPv6 standards documents [RFC- 2026].
このドキュメントが現実に情報であり、それは、どんなIPv6規格文書にも取り替えるか、アップデートするか、または矛盾することを意図しません[RFC2026]。
The main audience of this document are: the implementers of cellular hosts that will be used with GPRS, 3GPP UMTS Release 99, Release 4, Release 5, or future releases of UMTS. The document provides guidance on which parts of IPv6 to implement in such cellular hosts. Parts of this document may also apply to other cellular link types, but no such detailed analysis has been done yet and is a topic of future work. This document should not be used as a definitive list
このドキュメントの主な聴衆は以下の通りです。 UMTSのGPRS、3GPP UMTS Release99、Release4、Release5、または今後のリリースと共に使用されるセルホストのimplementers。 ドキュメントはそのようなセルホストでIPv6のどの部分を実装したらよいかに関して指導を提供します。 また、このドキュメントの部分が他のセルリンク型に適用するかもしれませんが、どんなそのような詳細に渡る分析も、まだしていて、今後の活動の話題ではありません。 決定的なリストとしてこのドキュメントを使用するべきではありません。
Arkko, et al. Informational [Page 3] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[3ページ]のRFC3316IPv6
of IPv6 functionality for cellular links other than those listed above. Future changes in 3GPP networks that require changes in host implementations may result in updates to this document.
IPv6では、それら以外のセルリンクのための機能性は上にリストアップされました。 ホスト導入で釣り銭がいる3GPPネットワークにおける将来の変化はこのドキュメントへのアップデートをもたらすかもしれません。
There are different ways to implement cellular hosts:
セルホストを実装する異なった方法があります:
- The host can be a "closed 2G or 3G host" with a very compact size
and optimized applications, with no possibility to add or download
applications that can have IP communications. An example of such a
host is a very simple form of a mobile phone.
- ホストは、非常にコンパクトなサイズがある「閉じている2Gか3Gホスト」であることができ、アプリケーションを最適化しました、IPコミュニケーションを持つことができるアプリケーションを加えるか、またはダウンロードする可能性なしで。 そのようなホストの例は携帯電話の非常に簡単なフォームです。
- The host can be an "open 2G or 3G host" with a compact size, but
where it is possible to download applications; such as a PDA-type
of phone.
- ホストは小型にもかかわらず、アプリケーションをダウンロードするのがどこで可能であるかがある「開いている2Gか3Gホスト」であることができます。 電話のPDAタイプのように。
If a cellular host has additional interfaces on which IP is used, (such as Ethernet, WLAN, Bluetooth, etc.) then there may be additional requirements for the device, beyond what is discussed in this document. Additionally, this document does not make any recommendations on the functionality required on laptop computers having a cellular interface such as a PC card, other than recommending link specific behavior on the cellular link.
デバイスのための追加要件があるかもしれません、セルホストにIPが使用されている追加インタフェース、(イーサネットとしてのそのような、WLAN、ブルートゥースなど)があるなら本書では議論することを超えて。 さらに、このドキュメントはPCカードなどのセルインタフェースを持ちながら、ラップトップコンピュータの上で必要である機能性で少しの推薦状もしません、セルリンクに特異的行動をリンクするように勧めるのを除いて。
This document discusses IPv6 functionality as specified when this document has been written. Ongoing work on IPv6 may affect what is needed from future hosts. The reader should also be advised other relevant work exists for various other layers. Examples of this include the header compression work done in the IETF ROHC group, the analysis of the effects of error-prone links to performance in [RFC- 3155], or the TCP work in [RFC-3481].
このドキュメントは指定されるとこのドキュメントが書かれるとIPv6の機能性について議論します。 IPv6への進行中の作業は将来のホストから必要であるものに影響するかもしれません。 また、読者は他の慎重な関連仕事が他の様々な層のために存在しているということであるべきです。 この例はIETF ROHCグループで行われたヘッダー圧縮仕事、[RFC3155]の性能への誤り傾向があるリンクの効果の分析、または[RFC-3481]でのTCP仕事を含んでいます。
Transition mechanisms used by cellular hosts are not described in this document and are left for further study.
セルホストによって使用された変遷メカニズムは、本書では説明されないで、さらなる研究に残されます。
1.2 Abbreviations
1.2 略語
2G Second Generation Mobile Telecommunications, such as GSM and
GPRS technologies.
3G Third Generation Mobile Telecommunications, such as UMTS
technology.
3GPP 3rd Generation Partnership Project. Throughout the document,
the term 3GPP (3rd Generation Partnership Project) networks
refers to architectures standardized by 3GPP, in Second and
Third Generation releases: 99, 4, and 5, as well as future
releases.
AH Authentication Header
APN Access Point Name. The APN is a logical name referring to a
GGSN and an external network.
GSMやGPRS技術などの2G第2GenerationのモバイルTelecommunications。 UMTS技術などの3G第3GenerationのモバイルTelecommunications。 3GPP第3世代パートナーシッププロジェクト。 ドキュメント中では、ネットワークという用語3GPP(第3Generation Partnership Project)は3GPPによって標準化されたアーキテクチャを示します、SecondとThird Generationリリースで: 今後のリリースと同様に99、4、および5。 ああ、APNアクセスポイントが命名する認証ヘッダー。 APNはGGSNについて言及する論理的な名前と外部のネットワークです。
Arkko, et al. Informational [Page 4] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[4ページ]のRFC3316IPv6
ESP Encapsulating Security Payload
ETSI European Telecommunications Standards Institute
IMS IP Multimedia Subsystem
GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6
cellular hosts)
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
IKE Internet Key Exchange
ISAKMP Internet Security Association and Key Management Protocol
MT Mobile Terminal, for example, a mobile phone handset.
MTU Maximum Transmission Unit
PDP Packet Data Protocol
SGSN Serving GPRS Support Node
TE Terminal Equipment, for example, a laptop attached through a
3GPP handset.
UMTS Universal Mobile Telecommunications System
WLAN Wireless Local Area Network
超能力Encapsulating SecurityのヨーロッパのTelecommunications Standards Institute IMS IP Multimedia Subsystem GGSNゲートウェイ有効搭載量ETSI GPRS Support Node(3GPP IPv6のセルホストのためのデフォルトルータ)GPRS汎用パケット無線システムGSM汎欧州デジタルセルラーシステムIKEインターネット・キー・エクスチェンジISAKMPインターネットSecurity AssociationとKey ManagementプロトコルのMTのモバイルTerminal、例えば、携帯電話受話器。 MTU Maximum Transmission Unit PDP Packet DataプロトコルSGSN Serving GPRS Support Node TE Terminal Equipment、例えば、ラップトップは3GPP受話器を通して付きました。 UMTSの普遍的な移動体通信システムWLANワイヤレスのローカル・エリア・ネットワーク
1.3 Cellular Host IPv6 Features
1.3 セルホストIPv6の特徴
This specification defines IPv6 features for cellular hosts in three groups.
この仕様はセルホストのために3つのグループでIPv6の特徴を定義します。
Basic IP
基本的なIP
In this group, basic parts of IPv6 are described.
このグループでは、IPv6の基本的な部分は説明されます。
IP Security
IPセキュリティ
In this group, the IP Security parts are described.
このグループでは、IP Securityの部品は説明されます。
Mobility
移動性
In this group, IP layer mobility issues are described.
このグループでは、IP層の移動性問題は説明されます。
2 Basic IP
2 基本的なIP
2.1 RFC1981 - Path MTU Discovery for IP Version 6
2.1RFC1981--IPバージョン6のための経路MTU発見
Path MTU Discovery [RFC-1981] may be used. Cellular hosts with a link MTU larger than the minimum IPv6 link MTU (1280 octets) can use Path MTU Discovery in order to discover the real path MTU. The relative overhead of IPv6 headers is minimized through the use of longer packets, thus making better use of the available bandwidth.
経路MTUディスカバリー[RFC-1981]は使用されるかもしれません。 最小のIPv6リンクMTU(1280の八重奏)より大きいリンクMTUのセルホストは、本当の経路MTUを発見するのにPath MTUディスカバリーを使用できます。 IPv6ヘッダーの相対的なオーバーヘッドは、より長いパケットの使用で最小にされます、その結果、有効に、利用可能な帯域幅を利用します。
Arkko, et al. Informational [Page 5] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[5ページ]のRFC3316IPv6
The IPv6 specification [RFC-2460] states in Section 5 that "a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery."
「最小量のIPv6実装(例えば、ブーツROMの)は、単にそれ自体を1280の八重奏ほど大きくない送付パケットに制限して、Path MTUディスカバリーの実装を省略するかもしれません。」と、IPv6仕様[RFC-2460]はセクション5に述べます。
If Path MTU Discovery is not implemented then the sending packet size is limited to 1280 octets (standard limit in [RFC-2460]). However, if this is done, the cellular host must be able to receive packets with size up to the link MTU before reassembly. This is because the node at the other side of the link has no way of knowing less than the MTU is accepted.
Path MTUディスカバリーが実装されないなら、送付パケットサイズは1280の八重奏([RFC-2460]の標準の限界)に制限されます。 しかしながら、これが完了しているなら、リンクMTUまでのサイズが以前再アセンブリでセルホストはパケットを受けることができなければなりません。 これはリンクの反対側のノードにはMTUを受け入れるほど知らない方法が全くないからです。
2.2 RFC3513 - IP Version 6 Addressing Architecture
2.2RFC3513--IPバージョン6アドレッシング体系
The IPv6 Addressing Architecture [RFC-3513] is a mandatory part of IPv6.
IPv6 Addressing Architecture[RFC-3513]はIPv6の義務的な部分です。
2.3 RFC2460 - Internet Protocol Version 6
2.3RFC2460--インターネットプロトコルバージョン6
The Internet Protocol Version 6 is specified in [RFC-2460]. This specification is a mandatory part of IPv6.
インターネットプロトコルバージョン6は[RFC-2460]で指定されます。 この仕様はIPv6の義務的な部分です。
By definition, a cellular host acts as a host, not as a router. Implementation requirements for a cellular router are not defined in this document.
定義上、セルホストはルータとして務めるのではなく、ホストとして務めます。 セルルータのための実装要件は本書では定義されません。
Consequently, the cellular host must implement all non-router packet receive processing as described in RFC 2460. This includes the generation of ICMPv6 error reports, and the processing of at least the following extension headers:
その結果、セルホストはRFC2460で説明されるように非ルータパケットが受けるすべてに処理を実装しなければなりません。 これはICMPv6エラー・レポートの世代、および少なくとも以下の拡張ヘッダーの処理を含んでいます:
- Hop-by-Hop Options header: at least the Pad1 and PadN options
- ホップごとのOptionsヘッダー: 少なくともPad1とPadNオプション
- Destination Options header: at least the Pad1 and PadN options
- 目的地Optionsヘッダー: 少なくともPad1とPadNオプション
- Routing (Type 0) header: final destination (host) processing only
- ルート設定(0をタイプする)ヘッダー: 最終的な目的地(接待する)処理専用
- Fragment header
- 断片ヘッダー
- AH and ESP headers (see also a discussion on the use of IPsec for
various purposes in Section 3)
- AHと超能力ヘッダー(また、IPsecのセクション3の様々な目的の使用についての議論を見ます)
- The No Next Header value
- いいえNext Header価値
Unrecognized options in Hop-by-Hop Options or Destination Options extensions must be processed as described in RFC 2460.
RFC2460で説明されるようにホップによるHop Optionsの認識されていないオプションかDestination Options拡張子を処理しなければなりません。
Arkko, et al. Informational [Page 6] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[6ページ]のRFC3316IPv6
The cellular host must follow the packet transmission rules in RFC 2460.
セルホストはRFC2460のパケット伝送規則に従わなければなりません。
The cellular host must always be able to receive and reassemble fragment headers. It will also need to be able to send a fragment header in cases where it communicates with an IPv4 host through a translator (see Section 5 of RFC2460).
セルホストは、断片ヘッダーを受けて、いつも組み立て直すことができなければなりません。 また、それは、それが翻訳者を通してIPv4ホストとコミュニケートする(RFC2460のセクション5を見てください)場合で断片ヘッダーを送ることができる必要があるでしょう。
Cellular hosts should only process routing headers when they are the final destination and return errors if the processing of the routing header requires them to forward the packet to another node. This will also ensure that the cellular hosts will not be inappropriately used as relays or components in Denial-of-Service (DoS) attacks. Acting as the destination involves the following: the cellular hosts must check the Segments Left field in the header, and proceed if it is zero or one and the next address is one of the host's addresses. If not, however, the host must implement error checks as specified in Section 4.4 of RFC 2460. There is no need for the host to send Routing Headers.
ルーティングヘッダーの処理が、別のノードにパケットを送るのを必要とするなら、セルホストは、彼らが最終的な目的地であるときにだけ、ルーティングヘッダーを処理して、誤りを返すべきです。 また、これは、セルホストがリレーかコンポーネントとしてサービス妨害(DoS)攻撃に不適当に使用されないのを確実にするでしょう。 目的地として機能するのは以下にかかわります: セルホストは、それがゼロか1であり、次のアドレスがホストのアドレスの1つであるならヘッダーのSegments Left分野をチェックして、続かなければなりません。 そうでなければ、しかしながら、ホストはRFC2460のセクション4.4における指定されるとしてのエラーチェックを実装しなければなりません。 ホストがルート設定Headersを送る必要は全くありません。
2.4 RFC2461 - Neighbor Discovery for IPv6
2.4RFC2461--IPv6のための隣人発見
Neighbor Discovery is described in [RFC-2461]. This specification is a mandatory part of IPv6.
隣人ディスカバリーは[RFC-2461]で説明されます。 この仕様はIPv6の義務的な部分です。
2.4.1 Neighbor Discovery in 3GPP Networks
2.4.1 3GPPネットワークにおける隣人発見
A cellular host must support Neighbor Solicitation and Advertisement messages.
セルホストは、Neighbor SolicitationとAdvertisementがメッセージであるとサポートしなければなりません。
In GPRS and UMTS networks, some Neighbor Discovery messages can be unnecessary in certain cases. GPRS and UMTS links resemble a point- to-point link; hence, the cellular host's only neighbor on the cellular link is the default router that is already known through Router Discovery. There are no link layer addresses. Therefore, address resolution and next-hop determination are not needed.
ある場合には、GPRSとUMTSネットワークでは、いくつかのNeighborディスカバリーメッセージが不要である場合があります。 GPRSとUMTSリンクはポイントへのポイントリンクに類似しています。 したがって、セルリンクの上のセルホストの唯一の隣人がRouterディスカバリーを通して既に知られているデフォルトルータです。 リンクレイヤアドレスが全くありません。 したがって、アドレス解決と次のホップ決断は必要ではありません。
The cellular host must support neighbor unreachability detection as specified in [RFC-2461].
セルホストは[RFC-2461]での指定されるとしての検出を隣人の「非-可到達性」にサポートしなければなりません。
In GPRS and UMTS networks, it is very desirable to conserve bandwidth. Therefore, the cellular host should include a mechanism in upper layer protocols to provide reachability confirmation when two-way IP layer reachability can be confirmed (see RFC-2461, Section 7.3.1). These confirmations will allow the suppression of most NUD- related messages in most cases.
GPRSとUMTSネットワークでは、帯域幅を保存するのは非常に望ましいです。 したがって、セルホストは、両用IP層の可到達性を確認できるとき(RFC-2461、セクション7.3.1を見てください)、可到達性確認を提供するために上側の層のプロトコルでメカニズムを入れるべきです。 多くの場合、これらの確認はほとんどのNUDの関連するメッセージの秘匿を許すでしょう。
Arkko, et al. Informational [Page 7] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[7ページ]のRFC3316IPv6
Host TCP implementation should provide reachability confirmation in the manner explained in RFC 2461, Section 7.3.1.
ホストTCP実装はRFC2461、セクション7.3.1で説明された方法で可到達性確認を提供するべきです。
The common use of UDP in 3GPP networks poses a problem for providing reachability confirmation. UDP itself is unable to provide such confirmation. Applications running over UDP should provide the confirmation where possible. In particular, when UDP is used for transporting RTP, the RTCP protocol feedback should be used as a basis for the reachability confirmation. If an RTCP packet is received with a reception report block indicating some packets have gone through, then packets are reaching the peer. If they have reached the peer, they have also reached the neighbor.
3GPPネットワークにおけるUDPの一般の使用は、可到達性確認を提供するために問題を設定します。 UDP自身はそのような確認を提供できません。 UDPをひくアプリケーションは可能であるところに確認を提供するべきです。 UDPがRTPを輸送するのに使用されるとき、特に、RTCPプロトコルフィードバックは可到達性確認の基礎として使用されるべきです。 レセプションレポートブロックが、いくつかのパケットが通られたのを示していてRTCPパケットを受け取るなら、パケットは同輩に届いています。 また、同輩に届いたなら、それらは隣人に届きました。
When UDP is used for transporting SIP, responses to SIP requests should be used as the confirmation that packets sent to the peer are reaching it. When the cellular host is acting as the server side SIP node, no such confirmation is generally available. However, a host may interpret the receipt of a SIP ACK request as confirmation that the previously sent response to a SIP INVITE request has reached the peer.
UDPがSIPを輸送するのに使用されるとき、SIP要求への応答はパケットが同輩に送った確認として使用されているのが、それに達することであるということであるべきです。 セルホストがサーバサイドSIPノードとして務めているとき、一般に、そのようなどんな確認も利用可能ではありません。 しかしながら、ホストはSIP INVITE要求への以前に送られた応答が同輩に届いたという確認としてのSIP ACK要求の領収書を解釈するかもしれません。
2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration
2.5RFC2462--IPv6の状態がないアドレス自動構成
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This specification is a mandatory part of IPv6.
IPv6 Stateless Address Autoconfigurationは[RFC-2462]で定義されます。 この仕様はIPv6の義務的な部分です。
2.5.1 Stateless Address Autoconfiguration in 3GPP Networks
2.5.1 3GPPネットワークにおける状態がないアドレス自動構成
A cellular host in a 3GPP network must process a Router Advertisement as stated in Section 2.4.
3GPPネットワークのセルホストはセクション2.4における述べられるとしてのRouter Advertisementを処理しなければなりません。
Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, as each delegated prefix is unique within its scope when allocated using the 3GPP IPv6 Stateless Address Autoconfiguration. In addition, the default router (GGSN) will not configure or assign to its interfaces, any addresses based on prefixes delegated to IPv6 hosts. Thus, the host is not required to perform Duplicate Address Detection on the cellular interface.
3GPPネットワークのホストはゼロに合わせるために等しいDupAddrDetectTransmitsを設定できます、3GPP IPv6 Stateless Address Autoconfigurationを使用することで割り当てるとそれぞれの代表として派遣された接頭語が範囲の中でユニークであるときに。 追加、(GGSN)がインタフェースに構成するか、または割り当てないデフォルトルータでは、接頭語に基づいたどんなアドレスもIPv6ホストに委任しました。 したがって、ホストはセルインタフェースにDuplicate Address Detectionを実行する必要はありません。
See Appendix A for more details on 3GPP IPv6 Stateless Address Autoconfiguration.
3GPP IPv6 Stateless Address Autoconfigurationに関するその他の詳細に関してAppendix Aを見てください。
2.6 RFC2463 - Internet Control Message Protocol for the IPv6
2.6RFC2463--IPv6のためのインターネット・コントロール・メッセージ・プロトコル
The Internet Control Message Protocol for the IPv6 is defined [RFC- 2463]. This specification is a mandatory part of IPv6. Currently, this work is being updated.
IPv6のためのインターネット・コントロール・メッセージ・プロトコルは定義されます[RFC2463]。 この仕様はIPv6の義務的な部分です。 現在、この仕事をアップデートしています。
Arkko, et al. Informational [Page 8] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[8ページ]のRFC3316IPv6
As per RFC 2463 Section 2, ICMPv6 requirements must be fully implemented by every IPv6 node. See also Section 3 for an explanation of the use of IPsec for protecting ICMPv6 communications.
RFC2463セクション2に従って、あらゆるIPv6ノードでICMPv6要件を完全に実装しなければなりません。 また、IPsecのICMPv6コミュニケーションを保護する使用の説明に関してセクション3を見てください。
2.7 RFC2472 - IP version 6 over PPP
2.7RFC2472--PPPの上のIPバージョン6
IPv6 over PPP [RFC-2472] must be supported for cellular hosts that implement PPP.
PPPを実装するセルホストのためにPPP[RFC-2472]の上のIPv6をサポートしなければなりません。
2.7.1 IP version 6 over PPP in 3GPP Networks
2.7.1 3GPP NetworksのPPPの上のIPバージョン6
A cellular host in a 3GPP network must support the IPv6CP interface identifier option. This option is needed to be able to connect other devices to the Internet using a PPP link between the cellular device (MT) and other devices (TE, e.g., a laptop). The MT performs the PDP Context activation based on a request from the TE. This results in an interface identifier being suggested by the MT to the TE, using the IPv6CP option. To avoid any duplication in link-local addresses between the TE and the GGSN, the MT must always reject other suggested interface identifiers by the TE. This results in the TE always using the interface identifier suggested by the GGSN for its link-local address.
3GPPネットワークのセルホストは、IPv6CPインタフェースが識別子オプションであるとサポートしなければなりません。 このオプションが、セルデバイス(MT)と他のデバイス(TE、例えば、ラップトップ)とのPPPリンクを使用することで対向機器をインターネットに接続できるように必要です。 MTはTEからの要求に基づくPDP Context起動を実行します。 これはIPv6CPオプションを使用して、TEへのMTによって示されるインタフェース識別子をもたらします。 TEとGGSN、MTの間のリンクローカルのアドレスにおけるどんな重複も避けるのはいつもTEで他の提案されたインタフェース識別子を拒絶しなければなりません。 これは、いつもリンクローカルアドレスのためにGGSNによって勧められたインタフェース識別子を使用することでTEをもたらします。
The rejection of interface identifiers suggested by the TE is only done for creation of link-local addresses, according to 3GPP specifications. The use of privacy addresses [RFC-3041] for site- local and global addresses is not affected by the above procedure. The above procedure is only concerned with assigning the interface identifier used for forming link-local addresses, and does not preclude TE from using other interface identifiers for addresses with larger scopes (i.e., site-local and global).
リンクローカルのアドレスの作成のためにTEによって勧められたインタフェース識別子の拒絶をするだけです、3GPP仕様通りに。 プライバシーアドレス[RFC-3041]のサイトの地方の、そして、グローバルなアドレスの使用は上の手順で影響を受けません。 上の手順は、インタフェース識別子を割り当てるのにリンクローカルのアドレスを形成するのに使用される関係があるだけであり、より大きい範囲が(すなわち、サイトローカルでグローバル)でアドレスに他のインタフェース識別子を使用するので、TEを排除しません。
2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification
2.8RFC2473--IPv6仕様によるジェネリックパケットトンネリング
Generic Packet Tunneling [RFC-2473] may be supported if needed for transition mechanisms.
変遷メカニズムに必要であるなら、ジェネリックPacket Tunneling[RFC-2473]はサポートされるかもしれません。
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6
2.9RFC2710--IPv6のためのマルチキャストリスナー発見(MLD)
Multicast Listener Discovery [RFC-2710] must be supported by cellular hosts.
セルホストはマルチキャストListenerディスカバリー[RFC-2710]をサポートしなければなりません。
MLD requires that MLD messages be sent for link-local multicast addresses (excluding the all-nodes address). The requirement that MLD be run even for link-local addresses aids layer-two devices (e.g., Ethernet bridges) that attempt to suppress the forwarding of link-layer multicast packets to portions of the layer-two network where there are no listeners. If MLD is used to announce the
MLDは、MLDメッセージがリンクローカルのマルチキャストアドレス(オールノードアドレスを除いた)のために送られるのを必要とします。 MLDがリンクローカルのアドレスのためにさえ実行されるという要件はリスナーが全くいない層-2ネットワークの一部にリンクレイヤマルチキャストパケットの推進を抑圧するのを試みる層-2台のデバイス(例えば、イーサネットブリッジ)を支援します。 MLDは、発表するのに使用されます。
Arkko, et al. Informational [Page 9] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[9ページ]のRFC3316IPv6
presence of listeners for all IP multicast addresses (including link-local multicast addresses), layer 2 devices can snoop MLD messages to reliably determine which portions of a network IP multicast messages need to be forwarded to.
すべてのIPマルチキャストアドレス(リンクローカルのマルチキャストアドレスを含んでいる)のためのリスナーの存在、層の2デバイスはIPマルチキャストメッセージが、ネットワークのどの一部に進められる必要であるかを確かに決定するMLDメッセージについて詮索できます。
2.9.1 MLD in 3GPP Networks
2.9.1 3GPPネットワークにおけるMLD
Within 3GPP networks, hosts connect to their default routers (GGSN) via point-to-point links. Moreover, there are exactly two IP devices connected to the point-to-point link, and no attempt is made (at the link-layer) to suppress the forwarding of multicast traffic. Consequently, sending MLD reports for link-local addresses in a 3GPP environment may not always be necessary.
3GPPネットワークの中では、ホストはポイントツーポイント接続を通して彼らのデフォルトルータ(GGSN)に接続します。 そのうえ、まさに指すポイントに関連しているIPデバイスがリンクする2があります、そして、マルチキャストトラフィックの推進を抑圧するのを試みを全くしません(リンクレイヤで)。 その結果、3GPP環境におけるリンクローカルのアドレスのための送付MLDレポートがいつも必要であるかもしれないというわけではありません。
MLD is needed for multicast group knowledge that is not link-local.
MLDがリンクローカルでないマルチキャストグループ知識に必要です。
2.10 RFC2711 - IPv6 Router Alert Option
2.10RFC2711--IPv6ルータ警戒オプション
The Router Alert Option [RFC-2711] must be supported, and its use is required when MLD is used (see Section 2.9) or when RSVP [RFC-2205] is used.
Router Alert Option[RFC-2711]をサポートしなければなりません、そして、MLDが使用されているか(セクション2.9を見てください)、またはRSVP[RFC-2205]が使用されているとき、使用が必要です。
2.11 RFC3041 - Privacy Extensions for Address Configuration in IPv6
2.11RFC3041--IPv6でのアドレス構成のためのプライバシー拡大
Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] should be supported. RFC 3041, and privacy in general, is important for the Internet. Cellular hosts may use the temporary addresses as described in RFC 3041. However, the use of the Privacy Extension in an environment where IPv6 addresses are short-lived may not be necessary. At the time this document has been written, there is no experience on how long-lived cellular network address assignments (i.e., attachments to the network) are. The length of the address assignments depends upon many factors such as radio coverage, device status and user preferences. Additionally, the use of temporary address with IPsec may lead to more frequent renegotiation for the Security Associations.
Stateless Address Autoconfiguration[RFC-3041]のためのプライバシーExtensionsはサポートされるべきです。 インターネットに、RFC3041、および一般に、プライバシーは重要です。 セルホストはRFC3041で説明されるように仮の住所を使用するかもしれません。 しかしながら、IPv6アドレスが短命である環境におけるPrivacy Extensionの使用は必要でないかもしれません。 このドキュメントが書かれていたとき、セルラー・ネットワークアドレス課題(すなわち、ネットワークへの付属)がどれくらい長命であるかに関して経験が全くありません。 アドレス課題の長さはラジオ適用範囲や、デバイス状態やユーザー選択などの多くの要素に依存します。 さらに、IPsecとの仮の住所の使用はSecurity Associationsのための、より頻繁な再交渉に通じるかもしれません。
Refer to Section 5 for a discussion of the benefits of privacy extensions in a 3GPP network.
3GPPネットワークにおける、プライバシー拡大の恩恵の議論についてセクション5を参照してください。
2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
2.12 IPv6のためのダイナミックなホスト構成プロトコル(DHCPv6)
The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be used. DHCPv6 is not required for address autoconfiguration when IPv6 stateless autoconfiguration is used. However, DHCPv6 may be useful for other configuration needs on a cellular host.
IPv6[DHCPv6]のためのDynamic Host Configuration Protocolは使用されるかもしれません。 IPv6の状態がない自動構成が使用されているとき、DHCPv6はアドレス自動構成に必要ではありません。 しかしながら、DHCPv6はセルホストで他の構成の必要性の役に立つかもしれません。
Arkko, et al. Informational [Page 10] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko、他 いくらかの2Gと3Gのセルホスト2003年4月のための情報[10ページ]のRFC3316IPv6
2.13 RFC3484 - Default Address Selection for IPv6
2.13RFC3484--IPv6のためのデフォルトアドレス選択
Default Address Selection [RFC-3484] is needed for cellular hosts.
デフォルトAddress Selection[RFC-3484]がセルホストに必要です。
2.14 DNS
2.14 DNS
Cellular hosts should support DNS, as described in [RFC-1034], [RFC- 1035], [RFC-1886], and [RFC-3152].
セルホストは[RFC-1034]、[RFC1035]、[RFC-1886]、および[RFC-3152]で説明されるようにDNSをサポートするべきです。
If DNS is used, a cellular host can perform DNS requests in the recursive mode, to limit signaling over the air interface. Both the iterative and the recursive approach should be supported, however, as the specifications require implementation of the iterative approach, and allow the recursive approach as an option. Furthermore, all DNS servers may not support recursive queries, and the security benefits of DNS Security cannot always be achieved with them.
DNSが使用されているなら、セルホストは、空気インタフェースの上でシグナリングを制限するために再帰的なモードによるDNS要求を実行できます。 しかしながら、ともに、仕様が繰り返しのアプローチの実装を必要として、オプションとして再帰的なアプローチを許すとき、繰り返しのアプローチと再帰的なアプローチはサポートされるべきです。 その上、すべてのDNSサーバは反復クエリーをサポートしないかもしれません、そして、それらでいつもDNS Securityのセキュリティ利益は実現できるというわけではありません。
3 IP Security
3 IPセキュリティ
IPsec [RFC-2401] is a fundamental part of IPv6, and support for AH and ESP is described as mandatory in the specifications.
IPsec[RFC-2401]はIPv6の基本的な部分です、そして、AHと超能力のサポートは仕様で義務的であると記述されています。
The first part of this section discusses the applicability of IP Security and other security mechanisms for common tasks in cellular hosts. The second part, Sections 3.1 to 3.13, lists the specifications related to IPsec and discusses the use of these parts of IPsec in a cellular context.
The first part of this section discusses the applicability of IP Security and other security mechanisms for common tasks in cellular hosts. The second part, Sections 3.1 to 3.13, lists the specifications related to IPsec and discusses the use of these parts of IPsec in a cellular context.
In general, the need to use a security mechanism depends on the intended application for it. Different security mechanisms are useful in different contexts, and have different limitations. Some applications require the use of TLS [RFC-2246], in some situations IPsec is used.
In general, the need to use a security mechanism depends on the intended application for it. Different security mechanisms are useful in different contexts, and have different limitations. Some applications require the use of TLS [RFC-2246], in some situations IPsec is used.
It is not realistic to list all possible services here, and it is expected that application protocol specifications have requirements on what security services they require. Note that cellular hosts able to download applications must be prepared to offer sufficient security services for these applications regardless of the needs of the initial set of applications in those hosts.
It is not realistic to list all possible services here, and it is expected that application protocol specifications have requirements on what security services they require. Note that cellular hosts able to download applications must be prepared to offer sufficient security services for these applications regardless of the needs of the initial set of applications in those hosts.
The following sections list specifications related to the IPsec functionality, and discuss their applicability in a cellular context. This discussion focuses on the use of IPsec. In some applications, a different set of protocols may need to be employed. In particular, the below discussion is not relevant for applications that use other security services than IPsec.
The following sections list specifications related to the IPsec functionality, and discuss their applicability in a cellular context. This discussion focuses on the use of IPsec. In some applications, a different set of protocols may need to be employed. In particular, the below discussion is not relevant for applications that use other security services than IPsec.
Arkko, et al. Informational [Page 11] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 11] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication
This specification [RFC-2104] must be supported. It is referenced by RFC 2403 that describes how IPsec protects the integrity of packets.
This specification [RFC-2104] must be supported. It is referenced by RFC 2403 that describes how IPsec protects the integrity of packets.
3.2 RFC2401 - Security Architecture for the Internet Protocol
3.2 RFC2401 - Security Architecture for the Internet Protocol
This specification [RFC-2401] must be supported.
This specification [RFC-2401] must be supported.
3.3 RFC2402 - IP Authentication Header
3.3 RFC2402 - IP Authentication Header
This specification [RFC-2402] must be supported.
This specification [RFC-2402] must be supported.
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH
This specification [RFC-2403] must be supported.
This specification [RFC-2403] must be supported.
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH
This specification [RFC-2404] must be supported.
This specification [RFC-2404] must be supported.
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
This specification [RFC-2405] may be supported. It is, however, recommended that stronger algorithms than DES be used. Algorithms, such as AES, are undergoing work in the IPsec working group. These new algorithms are useful, and should be supported as soon as their standardization is ready.
This specification [RFC-2405] may be supported. It is, however, recommended that stronger algorithms than DES be used. Algorithms, such as AES, are undergoing work in the IPsec working group. These new algorithms are useful, and should be supported as soon as their standardization is ready.
3.7 RFC2406 - IP Encapsulating Security Payload (ESP)
3.7 RFC2406 - IP Encapsulating Security Payload (ESP)
This specification [RFC-2406] must be supported.
This specification [RFC-2406] must be supported.
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP
Automatic key management, [RFC-2408] and [RFC-2409], is not a mandatory part of the IP Security Architecture. Note, however, that in the cellular environment the IP addresses of a host may change dynamically. For this reason the use of manually configured Security Associations is not practical, as the newest host address would have to be updated to the SA database of the peer as well.
Automatic key management, [RFC-2408] and [RFC-2409], is not a mandatory part of the IP Security Architecture. Note, however, that in the cellular environment the IP addresses of a host may change dynamically. For this reason the use of manually configured Security Associations is not practical, as the newest host address would have to be updated to the SA database of the peer as well.
Even so, it is not clear that all applications would use IKE for key management. For instance, hosts may use IPsec ESP [RFC-2406] for protecting SIP signaling in the IMS [3GPP-ACC] but provide authentication and key management through another mechanism such as UMTS AKA (Authentication and Key Agreement) [UMTS-AKA].
Even so, it is not clear that all applications would use IKE for key management. For instance, hosts may use IPsec ESP [RFC-2406] for protecting SIP signaling in the IMS [3GPP-ACC] but provide authentication and key management through another mechanism such as UMTS AKA (Authentication and Key Agreement) [UMTS-AKA].
Arkko, et al. Informational [Page 12] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 12] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
It is likely that several simplifying assumptions can be made in the cellular environment, with respect to the mandated parts of the IP Security DoI, ISAKMP, and IKE. Work on such simplifications would be useful, but is outside the scope of this document.
It is likely that several simplifying assumptions can be made in the cellular environment, with respect to the mandated parts of the IP Security DoI, ISAKMP, and IKE. Work on such simplifications would be useful, but is outside the scope of this document.
3.9 RFC2408 - The Internet Security Association and Key Management
Protocol
3.9 RFC2408 - The Internet Security Association and Key Management Protocol
This specification [RFC-2408] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8.
This specification [RFC-2408] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8.
3.10 RFC2409 - The Internet Key Exchange (IKE)
3.10 RFC2409 - The Internet Key Exchange (IKE)
This specification [RFC-2409] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8.
This specification [RFC-2409] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8.
Interactions with the ICMPv6 packets and IPsec policies may cause unexpected behavior for IKE-based SA negotiation unless some special handling is performed in the implementations.
Interactions with the ICMPv6 packets and IPsec policies may cause unexpected behavior for IKE-based SA negotiation unless some special handling is performed in the implementations.
The ICMPv6 protocol provides many functions, which in IPv4 were either non-existent or provided by lower layers. For instance, IPv6 implements address resolution using an IP packet, ICMPv6 Neighbor Solicitation message. In contrast, IPv4 uses an ARP message at a lower layer.
The ICMPv6 protocol provides many functions, which in IPv4 were either non-existent or provided by lower layers. For instance, IPv6 implements address resolution using an IP packet, ICMPv6 Neighbor Solicitation message. In contrast, IPv4 uses an ARP message at a lower layer.
The IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is not easy. For instance, a simple policy of protecting all traffic between two hosts on the same network would trap even address resolution messages, leading to a situation where IKE can't establish a Security Association since in order to send the IKE UDP packets one would have had to send the Neighbor Solicitation Message, which would have required an SA.
The IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is not easy. For instance, a simple policy of protecting all traffic between two hosts on the same network would trap even address resolution messages, leading to a situation where IKE can't establish a Security Association since in order to send the IKE UDP packets one would have had to send the Neighbor Solicitation Message, which would have required an SA.
In order to avoid this problem, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages must not lead to the use of IKE-based SA negotiation. The Redirect message should not lead to the use of IKE-based SA negotiation. Other ICMPv6 messages may use IKE-based SA negotiation as is desired in the Security Policy Data Base.
In order to avoid this problem, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages must not lead to the use of IKE-based SA negotiation. The Redirect message should not lead to the use of IKE-based SA negotiation. Other ICMPv6 messages may use IKE-based SA negotiation as is desired in the Security Policy Data Base.
Note that the above limits the usefulness of IPsec in protecting all ICMPv6 communications. For instance, it may not be possible to protect the ICMPv6 traffic between a cellular host and its next hop
Note that the above limits the usefulness of IPsec in protecting all ICMPv6 communications. For instance, it may not be possible to protect the ICMPv6 traffic between a cellular host and its next hop
Arkko, et al. Informational [Page 13] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 13] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
router. (Which may be hard in any case due to the need to establish a suitable public key infrastructure. Since roaming is allowed, this infrastructure would have to authenticate all hosts to all routers.)
router. (Which may be hard in any case due to the need to establish a suitable public key infrastructure. Since roaming is allowed, this infrastructure would have to authenticate all hosts to all routers.)
3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec
3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec
This specification [RFC-2410] must be supported.
This specification [RFC-2410] must be supported.
3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms
3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms
This specification [RFC-2451] must be supported if encryption algorithms other than DES are implemented, e.g., CAST-128, RC5, IDEA, Blowfish, 3DES.
This specification [RFC-2451] must be supported if encryption algorithms other than DES are implemented, e.g., CAST-128, RC5, IDEA, Blowfish, 3DES.
4. Mobility
4. Mobility
For the purposes of this document, IP mobility is not relevant. When Mobile IPv6 specification is approved, a future update to this document may address these issues, as there may be some effects on all IPv6 hosts due to Mobile IP. The movement of cellular hosts within 3GPP networks is handled by link layer mechanisms.
For the purposes of this document, IP mobility is not relevant. When Mobile IPv6 specification is approved, a future update to this document may address these issues, as there may be some effects on all IPv6 hosts due to Mobile IP. The movement of cellular hosts within 3GPP networks is handled by link layer mechanisms.
5. Security Considerations
5. Security Considerations
This document does not specify any new protocols or functionality, and as such, it does not introduce any new security vulnerabilities. However, specific profiles of IPv6 functionality are proposed for different situations, and vulnerabilities may open or close depending on which functionality is included and what is not. There are also aspects of the cellular environment that make certain types of vulnerabilities more severe. The following issues are discussed:
This document does not specify any new protocols or functionality, and as such, it does not introduce any new security vulnerabilities. However, specific profiles of IPv6 functionality are proposed for different situations, and vulnerabilities may open or close depending on which functionality is included and what is not. There are also aspects of the cellular environment that make certain types of vulnerabilities more severe. The following issues are discussed:
- The suggested limitations (Section 2.3) in the processing of
routing headers limits also exposure to DoS attacks through
cellular hosts.
- The suggested limitations (Section 2.3) in the processing of routing headers limits also exposure to DoS attacks through cellular hosts.
- IPv6 addressing privacy [RFC3041] may be used in cellular hosts.
However, it should be noted that in the 3GPP model, the network
would assign new addresses, in most cases, to hosts in roaming
situations and typically, also when the cellular hosts activate a
PDP context. This means that 3GPP networks will already provide a
limited form of addressing privacy, and no global tracking of a
single host is possible through its address. On the other hand,
since a GGSN's coverage area is expected to be very large when
compared to currently deployed default routers (no handovers
between GGSNs are possible), a cellular host can keep an address
for a long time. Hence, IPv6 addressing privacy can be used for
additional privacy during the time the host is on and in the same
- IPv6 addressing privacy [RFC3041] may be used in cellular hosts. However, it should be noted that in the 3GPP model, the network would assign new addresses, in most cases, to hosts in roaming situations and typically, also when the cellular hosts activate a PDP context. This means that 3GPP networks will already provide a limited form of addressing privacy, and no global tracking of a single host is possible through its address. On the other hand, since a GGSN's coverage area is expected to be very large when compared to currently deployed default routers (no handovers between GGSNs are possible), a cellular host can keep an address for a long time. Hence, IPv6 addressing privacy can be used for additional privacy during the time the host is on and in the same
Arkko, et al. Informational [Page 14] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 14] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
area. The privacy features can also be used to e.g., make
different transport sessions appear to come from different IP
addresses. However, it is not clear that these additional efforts
confuse potential observers any further, as they could monitor only
the network prefix part.
area. The privacy features can also be used to e.g., make different transport sessions appear to come from different IP addresses. However, it is not clear that these additional efforts confuse potential observers any further, as they could monitor only the network prefix part.
- The use of various security services such as IPsec or TLS in the
connection of typical applications in cellular hosts is discussed
in Section 3 and recommendations are given there.
- The use of various security services such as IPsec or TLS in the connection of typical applications in cellular hosts is discussed in Section 3 and recommendations are given there.
- Section 3 also discusses under what conditions it is possible to
provide IPsec protection of e.g., ICMPv6 communications.
- Section 3 also discusses under what conditions it is possible to provide IPsec protection of e.g., ICMPv6 communications.
- The airtime used by cellular hosts is expensive. In some cases,
users are billed according to the amount of data they transfer to
and from their host. It is crucial for both the network and the
users that the airtime is used correctly and no extra charges are
applied to users due to misbehaving third parties. The cellular
links also have a limited capacity, which means that they may not
necessarily be able to accommodate more traffic than what the user
selected, such as a multimedia call. Additional traffic might
interfere with the service level experienced by the user. While
Quality of Service mechanisms mitigate these problems to an extent,
it is still apparent that DoS aspects may be highlighted in the
cellular environment. It is possible for existing DoS attacks that
use for instance packet amplification to be substantially more
damaging in this environment. How these attacks can be protected
against is still an area of further study. It is also often easy
to fill the cellular link and queues on both sides with additional
or large packets.
- The airtime used by cellular hosts is expensive. In some cases, users are billed according to the amount of data they transfer to and from their host. It is crucial for both the network and the users that the airtime is used correctly and no extra charges are applied to users due to misbehaving third parties. The cellular links also have a limited capacity, which means that they may not necessarily be able to accommodate more traffic than what the user selected, such as a multimedia call. Additional traffic might interfere with the service level experienced by the user. While Quality of Service mechanisms mitigate these problems to an extent, it is still apparent that DoS aspects may be highlighted in the cellular environment. It is possible for existing DoS attacks that use for instance packet amplification to be substantially more damaging in this environment. How these attacks can be protected against is still an area of further study. It is also often easy to fill the cellular link and queues on both sides with additional or large packets.
- Within some service provider networks, it is possible to buy a
prepaid cellular subscription without presenting personal
identification. Attackers that wish to remain unidentified could
leverage this. Note that while the user hasn't been identified,
the equipment still is; the operators can follow the identity of
the device and block it from further use. The operators must have
procedures in place to take notice of third party complaints
regarding the use of their customers' devices. It may also be
necessary for the operators to have attack detection tools that
enable them to efficiently detect attacks launched from the
cellular hosts.
- Within some service provider networks, it is possible to buy a prepaid cellular subscription without presenting personal identification. Attackers that wish to remain unidentified could leverage this. Note that while the user hasn't been identified, the equipment still is; the operators can follow the identity of the device and block it from further use. The operators must have procedures in place to take notice of third party complaints regarding the use of their customers' devices. It may also be necessary for the operators to have attack detection tools that enable them to efficiently detect attacks launched from the cellular hosts.
- Cellular devices that have local network interfaces (such as IrDA
or Bluetooth) may be used to launch attacks through them, unless
the local interfaces are secured in an appropriate manner.
Therefore, local network interfaces should have access control to
prevent others from using the cellular host as an intermediary.
- Cellular devices that have local network interfaces (such as IrDA or Bluetooth) may be used to launch attacks through them, unless the local interfaces are secured in an appropriate manner. Therefore, local network interfaces should have access control to prevent others from using the cellular host as an intermediary.
Arkko, et al. Informational [Page 15] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 15] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
6. References
6. References
6.1. Normative
6.1. Normative
[RFC-1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC-1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6, RFC 1886, December 1995.
[RFC-1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6, RFC 1886, December 1995.
[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2104] Krawczyk, K., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC-2104] Krawczyk, K., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2403] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP
and AH", RFC 2403, November 1998.
[RFC-2403] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP and AH", RFC 2403, November 1998.
[RFC-2404] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within
ESP and AH", RFC 2404, November 1998.
[RFC-2404] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within ESP and AH", RFC 2404, November 1998.
[RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[RFC-2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC-2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC-2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC-2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
Arkko, et al. Informational [Page 16] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 16] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
[RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC-2463] Conta, A. and S. Deering, "ICMP for the Internet Protocol
Version 6 (IPv6)", RFC 2463, December 1998.
[RFC-2463] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC-2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
[RFC-2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
August 2001.
[RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC-3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N.
Vaidya, "End-to-end Performance Implications of Links
with Errors", BCP 50, RFC 3155, August 2001.
[RFC-3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
Arkko, et al. Informational [Page 17] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 17] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
[RFC-3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC-3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
6.2. Informative
6.2. Informative
[3GPP-ACC] 3GPP Technical Specification 3GPP TS 33.203, "Technical
Specification Group Services and System Aspects; 3G
Security; Access security for IP-based services (Release
5)", 3rd Generation Partnership Project, March 2002.
[3GPP-ACC] 3GPP Technical Specification 3GPP TS 33.203, "Technical Specification Group Services and System Aspects; 3G Security; Access security for IP-based services (Release 5)", 3rd Generation Partnership Project, March 2002.
[3GPP-IMS] 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; IP
Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228)
[3GPP-IMS] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228)
[3GPP-IPv6] 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects
"Architectural requirements" (TS 23.221)
[3GPP-IPv6] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects "Architectural requirements" (TS 23.221)
[DHCPv6] Bound, J., et al., "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", Work in progress.
[DHCPv6] Bound, J., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in progress.
[RFC-1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC-2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over
IPv4 Domains without Explicit Tunnels", RFC 2529, March
1999.
[RFC-2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC-3314] Wasserman, M., Editor, "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards, RFC
3314, September 2002.
[RFC-3314] Wasserman, M., Editor, "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, RFC 3314, September 2002.
[RFC-3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and
F. Khafizov, "TCP over Second (2.5G) and Third (3G)
Generation Wireless Networks", BCP 71, RFC 3481, February
2003.
[RFC-3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", BCP 71, RFC 3481, February 2003.
[UMTS-AKA] 3GPP Technical Specification 3GPP TS 33.102, "Technical
Specification Group Services and System Aspects; 3G
Security; Security Architecture (Release 4)", 3rd
Generation Partnership Project, December 2001.
[UMTS-AKA] 3GPP Technical Specification 3GPP TS 33.102, "Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 4)", 3rd Generation Partnership Project, December 2001.
Arkko, et al. Informational [Page 18] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 18] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
7. Contributors
7. Contributors
This document is based on the results of a team that included Peter Hedman and Pertti Suomela in addition to the authors. Peter and Pertti have contributed both text and their IPv6 experience to this document.
This document is based on the results of a team that included Peter Hedman and Pertti Suomela in addition to the authors. Peter and Pertti have contributed both text and their IPv6 experience to this document.
8. Acknowledgements
8. Acknowledgements
The authors would like to thank Jim Bound, Brian Carpenter, Steve Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing list for their comments and input.
The authors would like to thank Jim Bound, Brian Carpenter, Steve Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing list for their comments and input.
We would also like to thank David DeCamp, Karim El Malki, Markus Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and Shabnam Sultana for their comments and input in preparation of this document.
We would also like to thank David DeCamp, Karim El Malki, Markus Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and Shabnam Sultana for their comments and input in preparation of this document.
Arkko, et al. Informational [Page 19] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 19] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model
The appendix aims to very briefly describe the 3GPP IPv6 addressing model for 2G (GPRS) and 3G (UMTS) cellular networks from Release 99 onwards. More information can be found from 3GPP Technical Specification 23.060.
The appendix aims to very briefly describe the 3GPP IPv6 addressing model for 2G (GPRS) and 3G (UMTS) cellular networks from Release 99 onwards. More information can be found from 3GPP Technical Specification 23.060.
There are two possibilities to allocate the address for an IPv6 node: stateless and stateful autoconfiguration. The stateful address allocation mechanism needs a DHCP server to allocate the address for the IPv6 node. On the other hand, the stateless autoconfiguration procedure does not need any external entity involved in the address autoconfiguration (apart from the GGSN).
There are two possibilities to allocate the address for an IPv6 node: stateless and stateful autoconfiguration. The stateful address allocation mechanism needs a DHCP server to allocate the address for the IPv6 node. On the other hand, the stateless autoconfiguration procedure does not need any external entity involved in the address autoconfiguration (apart from the GGSN).
In order to support the standard IPv6 stateless address autoconfiguration mechanism, as recommended by the IETF, the GGSN shall assign a prefix that is unique within its scope to each primary PDP context that uses IPv6 stateless address autoconfiguration. This avoids the necessity to perform Duplicate Address Detection at the network level for every address built by the mobile host. The GGSN always provides an Interface Identifier to the mobile host. The Mobile host uses the interface identifier provided by the GGSN to generate its link-local address. The GGSN provides the cellular host with the interface identifier, usually in a random manner. It must ensure the uniqueness of such identifier on the link (i.e., no collisions between its own link-local address and the cellular host's).
In order to support the standard IPv6 stateless address autoconfiguration mechanism, as recommended by the IETF, the GGSN shall assign a prefix that is unique within its scope to each primary PDP context that uses IPv6 stateless address autoconfiguration. This avoids the necessity to perform Duplicate Address Detection at the network level for every address built by the mobile host. The GGSN always provides an Interface Identifier to the mobile host. The Mobile host uses the interface identifier provided by the GGSN to generate its link-local address. The GGSN provides the cellular host with the interface identifier, usually in a random manner. It must ensure the uniqueness of such identifier on the link (i.e., no collisions between its own link-local address and the cellular host's).
In addition, the GGSN will not use any of the prefixes assigned to cellular hosts to generate any of its own addresses. This use of the interface identifier, combined with the fact that each PDP context is allocated a unique prefix, will eliminate the need for DAD messages over the air interface, and consequently allows an efficient use of bandwidth. Furthermore, the allocation of a prefix to each PDP context will allow hosts to implement the privacy extensions in RFC 3041 without the need for further DAD messages.
In addition, the GGSN will not use any of the prefixes assigned to cellular hosts to generate any of its own addresses. This use of the interface identifier, combined with the fact that each PDP context is allocated a unique prefix, will eliminate the need for DAD messages over the air interface, and consequently allows an efficient use of bandwidth. Furthermore, the allocation of a prefix to each PDP context will allow hosts to implement the privacy extensions in RFC 3041 without the need for further DAD messages.
Arkko, et al. Informational [Page 20] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 20] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Authors' Addresses
Authors' Addresses
Jari Arkko Ericsson 02420 Jorvas Finland
Jari Arkko Ericsson 02420 Jorvas Finland
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
Gerben Kuijpers Ericsson Skanderborgvej 232 DK-8260 Viby J Denmark
Gerben Kuijpers Ericsson Skanderborgvej 232 DK-8260 Viby J Denmark
EMail: gerben.a.kuijpers@ted.ericsson.se
EMail: gerben.a.kuijpers@ted.ericsson.se
John Loughney Nokia Research Center Itamerenkatu 11 - 13 FIN-00180 HELSINKI Finland
John Loughney Nokia Research Center Itamerenkatu 11 - 13 FIN-00180 HELSINKI Finland
EMail: john.loughney@nokia.com
EMail: john.loughney@nokia.com
Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 23, Kista, Stockholm Sweden
Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 23, Kista, Stockholm Sweden
EMail: hesham.soliman@era.ericsson.se
EMail: hesham.soliman@era.ericsson.se
Juha Wiljakka Nokia Mobile Phones Sinitaival 5 FIN-33720 TAMPERE Finland
Juha Wiljakka Nokia Mobile Phones Sinitaival 5 FIN-33720 TAMPERE Finland
EMail: juha.wiljakka@nokia.com
EMail: juha.wiljakka@nokia.com
Arkko, et al. Informational [Page 21] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Arkko, et al. Informational [Page 21] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). 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.
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.
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.
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
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Arkko, et al. Informational [Page 22]
Arkko, et al. Informational [Page 22]
一覧
スポンサーリンク
