Network Working Group J. Arkko
Request for Comments: 3316 G. Kuijpers
Category: Informational H. Soliman
Ericsson
J. Loughney
J. Wiljakka
Nokia
April 2003
Internet Protocol Version 6 (IPv6)
for Some Second and Third Generation Cellular Hosts
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
第二および第三世代携帯電話ネットワークの展開が進むにつれて、細胞宿主の多くは、インターネットに接続されています。標準化団体は、その仕様で必須のインターネットプロトコルバージョン6（IPv6）を作っています。ただし、IPv6の概念は多くの側面と数多くの仕様をカバーしています。また、帯域幅、コストや遅延に関しては、細胞のリンクの特性は、IPv6を使用する方法についての特別な要件を置きます。この文書では、汎用パケット無線サービス（GPRS）、またはユニバーサル移動通信システム（UMTS）ネットワークに接続する細胞宿主にIPv6を考慮します。この文書はまた、IPv6機能の基本的なコンポーネントをリストし、これらのネットワークで動作し、これらのコンポーネントの使用に関連するいくつかの問題について説明します。
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 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（ユニバーサル移動体通信システム）と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リリース99ネットワークとホストから始まります。 IPv6がリリース5から始まるIPマルチメディアサブシステム（IMS）のためにサポートされる唯一のIPバージョンとして指定されています。
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リリース99リリース4、5、だけでなく、将来の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規格文書[RFC-2026]を、置き換え更新、または矛盾するものではありません。
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 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.
本書の主な読者は、以下のとおりです。GPRS、UMTS 3GPPリリース99で使用される細胞宿主の実装者は、UMTSの5、または将来のリリースで、4をリリース。文書は、そのような細胞宿主に実装するのIPv6の部品に関するガイダンスを提供します。このドキュメントの一部はまた、他の細胞のリンクタイプに適用される場合がありますが、そのような詳細な分析はまだ行われていないと、将来の仕事のトピックがあります。この文書では、上記以外の携帯リンクのための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.
- ホストがIP通信を持つことができるアプリケーションを追加したり、ダウンロードするには無い可能性が、非常にコンパクトなサイズと最適化されたアプリケーションで、「閉じた2Gまたは3Gホスト」することができます。このような宿主の例としては、携帯電話の非常にシンプルな形です。
- 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.
細胞宿主は、（などイーサネット（登録商標）、WLAN、ブルートゥース、など）IPが使用されている追加のインタフェースを有している場合は、この文書に記載されているものを超えて、デバイスのための追加の要件があるかもしれません。また、この文書は、セルラリンク上のリンク特定の動作を推奨以外の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基、[RFC-3155]における性能にエラープローンリンクの影響の分析、または[RFC-3481]でTCPの作業で行われ、ヘッダ圧縮の仕事を含みます。
Transition mechanisms used by cellular hosts are not described in this document and are left for further study.
細胞宿主で使用される移行メカニズムは、この文書に記載されておらず、さらなる研究のために残されています。
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第二世代移動体通信、。このようUMTS技術などの3G第三世代移動体通信、。 3GPP第3世代パートナーシッププロジェクト。明細書を通して、用語3GPP（第3世代パートナーシッププロジェクト）ネットワークは、第二および第三世代のリリースでは、3GPPによって標準化アーキテクチャを指す：99、4、及び5、並びに将来のリリース。 AH認証ヘッダーAPNアクセスポイント名。 APNは、GGSNと外部ネットワークを参照する論理名です。
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
ESPカプセル化セキュリティペイロードETSI欧州電気通信標準化協会IMS IPマルチメディアサブシステムGGSNゲートウェイGPRSサポートノード（3GPP IPv6の細胞宿主のためのデフォルトルータ）モバイルコミュニケーションズIKEインターネットキー交換ISAKMPインターネットセキュリティ協会とキー管理のためのGPRS汎用パケット無線サービスGSMグローバルシステムプロトコルMT携帯端末、例えば、携帯電話機。 GPRSサポートノードTE端末装置にサービスを提供MTU最大伝送単位PDPパケットデータプロトコルSGSNは、例えば、ラップトップは、3GPP携帯電話を介して結合しています。 UMTSユニバーサル移動体通信システムWLAN無線ローカル・エリア・ネットワーク
This specification defines IPv6 features for cellular hosts in three groups.
この仕様は三つのグループ内の細胞宿主に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セキュリティ部分が記述されています。
Mobility
可動性
In this group, IP layer mobility issues are described.
このグループでは、IP層のモビリティの問題が記載されています。
2 Basic IP
2基本的なIP
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より大きいリンクMTU（1280オクテット）との細胞宿主には、実際のパスMTUを発見するためにパスMTUディスカバリを使用することができます。 IPv6ヘッダーの相対的なオーバーヘッドは、このように、利用可能な帯域幅をより良く利用して、より長いパケットの使用によって最小化されます。
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仕様[RFC-2460]「最小IPv6実装（例えば、ブートROMで）は、単にパケット大きくない1280よりオクテットの送信に自身を制限し、パスMTU探索の実行を省略してもよい。」と第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.
パスMTU探索が実装されていない場合、送信パケットサイズ1280個のオクテット（[RFC-2460]で規格限界）に制限されます。これが行われる場合は、細胞宿主は、再構築する前に、リンクのMTUのサイズを上にしてパケットを受信することができなければなりません。リンクの反対側のノードがMTUを受け付けた未満を知る方法がないからです。
The IPv6 Addressing Architecture [RFC-3513] is a mandatory part of IPv6.
IPv6アドレス指定アーキテクチャ[RFC-3513]のIPv6の必須部分です。
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:
したがって、細胞宿主は、RFC 2460に記載されるように処理を受ける。これは、ICMPv6エラーレポートの生成、および、少なくとも以下の拡張ヘッダの処理を含むすべての非ルータのパケットを実装する必要があります。
- Hop-by-Hop Options header: at least the Pad1 and PadN options
- ホップバイホップオプションヘッダ：少なくともパッド1およびパッドNオプション
- Destination Options header: at least the Pad1 and PadN options
- 宛先オプションヘッダー：少なくともパッド1とパッドNオプション
- 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とESPヘッダ（セクション3における様々な目的のためのIPsecの使用に関する説明を参照）
- The No Next Header value
- いいえ、次ヘッダ値
Unrecognized options in Hop-by-Hop Options or Destination Options extensions must be processed as described in RFC 2460.
RFC 2460で説明したようにホップバイホップオプションや宛先オプションの拡張機能で認識できないオプションが処理されなければなりません。
The cellular host must follow the packet transmission rules in RFC 2460.
細胞宿主は、RFC 2460でパケット送信の規則に従わなければなりません。
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).
細胞宿主は、常にフラグメントヘッダを受信して組み立て直すことができなければなりません。それはまた、（RFC2460のセクション5を参照）、それが翻訳を介してIPv4ホストと通信を行う場合にはフラグメントヘッダを送信できるようにする必要があります。
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）攻撃にリレーまたはコンポーネントとして使用されないことを保証します。先として作用すると、次を含む：細胞宿主は、ヘッダ内のフィールドを左セグメントをチェックし、それが0または1であり、次のアドレスは、ホストのアドレスのいずれかである場合に進行しなければなりません。ない場合はルーティングヘッダを送信するホストのための必要はありませんRFC 2460のセクション4.4で指定されるように、しかし、ホストはエラーチェックを実装する必要があります。
Neighbor Discovery is described in [RFC-2461]. This specification is a mandatory part of IPv6.
近隣探索は、[RFC-2461]に記載されています。この仕様は、IPv6の必須部分です。
A cellular host must support Neighbor Solicitation and Advertisement messages.
細胞宿主は、近隣要請や広告メッセージをサポートしている必要があります。
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ネットワークでは、いくつかの近隣探索メッセージは、特定の場合には不要にすることができます。 GPRSおよびUMTSリンクは、ポイントツーポイントリンクに似ています。したがって、セルラーリンク上の細胞宿主の唯一の隣人は、すでにルータディスカバリーを通じて知られているデフォルトルータです。何のリンク層アドレスがありません。したがって、アドレス解決及び次ホップ決意が必要とされません。
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に関連したメッセージの抑制が可能になります。
Host TCP implementation should provide reachability confirmation in the manner explained in RFC 2461, Section 7.3.1.
ホストのTCP実装は、的に到達可能性確認を提供しなければならないRFC 2461、セクション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リクエストの受信を解釈することができます。
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This specification is a mandatory part of IPv6.
IPv6のステートレスアドレス自動設定は、[RFC-2462]で定義されています。この仕様は、IPv6の必須部分です。
A cellular host in a 3GPP network must process a Router Advertisement as stated in Section 2.4.
2.4節で述べたように、3GPPネットワーク内の細胞宿主には、ルータ広告を処理しなければなりません。
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のIPv6ステートレスアドレス自動設定を使用して割り当てられた場合に、各委譲されたプレフィックスが、その範囲内で一意であるように、3GPPネットワーク内のホストは、ゼロに等しくDupAddrDetectTransmitsを設定することができます。また、デフォルトルータ（GGSN）は設定しないか、又はそのインターフェイス、IPv6ホストに委任プレフィックスに基づいて、任意のアドレスに割り当てます。したがって、ホストは、セルラインタフェース上で重複アドレス検出を実行するために必要とされません。
See Appendix A for more details on 3GPP IPv6 Stateless Address Autoconfiguration.
3GPP IPv6のステートレスアドレス自動設定の詳細については、付録Aを参照してください。
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のインターネット制御メッセージプロトコルが定義されている[RFC-2463]。この仕様は、IPv6の必須部分です。現在、この作業は更新されています。
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.
RFC 2463第2節ごとに、ICMPv6の要件は完全にすべてのIPv6ノードによって実装されなければなりません。 ICMPv6の通信を保護するためのIPsecの使用についての説明も第3節を参照してください。
IPv6 over PPP [RFC-2472] must be supported for cellular hosts that implement PPP.
PPP上のIPv6 [RFC-2472]はPPPを実装細胞宿主のためにサポートしなければなりません。
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コンテキスト起動を行います。インタフェース識別子でこの結果は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を排除するものではありません。
Generic Packet Tunneling [RFC-2473] may be supported if needed for transition mechanisms.
遷移メカニズムのために必要であれば、汎用パケットトンネリング[RFC-2473]はサポートされてもよいです。
Multicast Listener Discovery [RFC-2710] must be supported by cellular hosts.
マルチキャストリスナ発見[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 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.
MLDは、MLDメッセージが（全ノードのアドレスを除く）リンクローカルマルチキャストアドレスに対して送信されている必要があります。 MLDをもリンクローカルアドレス補助層個のデバイス（例えば、イーサネット・ブリッジ）のために実行することが必要ないリスナーが存在しない層、2つのネットワークの一部にリンク層マルチキャストパケットの転送を抑制することを試みます。 MLDは、（リンクローカルマルチキャストアドレスを含む）すべてのIPマルチキャストアドレスのリスナーの存在を通知するために使用される場合、レイヤ2デバイスを確実にIPマルチキャストメッセージが転送される必要があるネットワークの部分を決定するために、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）に接続します。また、ポイントツーポイントリンクに接続された2つのIPデバイスが正確にあり、そして試みは、マルチキャストトラフィックの転送を抑制すること（リンク層において）行われません。その結果、MLDは、3GPP環境でリンクローカルアドレスのためのレポートを送信することは必ずしも必要ではないかもしれません。
MLD is needed for multicast group knowledge that is not link-local.
MLDは、リンクローカルでないマルチキャストグループの知識を必要とされています。
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.
ルータ警告オプション[RFC-2711]サポートされなければならない、そしてMLDを使用する場合、その使用が必要である（2.9節を参照）またはRSVP [RFC-2205]は使用されている場合。
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.
ステートレスアドレス自動設定[RFC-3041]のための個人情報保護の拡張機能がサポートされなければなりません。一般的にはRFC 3041、およびプライバシーは、インターネットのために重要です。しかし、RFC 3041で説明したように携帯電話のホストが一時アドレスを使用して、IPv6アドレスが短命された環境でのプライバシー拡張を使用することは必要ではないかもしれません。この文書が書かれた時点では、どのように長寿命のセルラーネットワークアドレスの割り当て（ネットワークへのすなわち、添付ファイル）には経験がありません。アドレス割り当ての長さは、無線カバレッジ、デバイスステータスとユーザの好みのような多くの要因に依存します。また、IPsecで一時アドレスを使用すると、セキュリティアソシエーションのために、より頻繁な再交渉につながる可能性があります。
Refer to Section 5 for a discussion of the benefits of privacy extensions in a 3GPP network.
3GPPネットワークにおけるプライバシーの拡張の利点の議論については、セクション5を参照してください。
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の]のための動的ホスト構成プロトコルを使用することができます。 IPv6のステートレス自動設定を使用する場合のDHCPv6は、アドレス自動設定は必要ありません。しかし、DHCPv6のは、細胞宿主の他の構成のニーズのために有用である可能性があります。
Default Address Selection [RFC-3484] is needed for cellular hosts.
デフォルトアドレス選択[RFC-3484]は細胞宿主のために必要とされます。
Cellular hosts should support DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], and [RFC-3152].
[RFC-1034]に記載されているように細胞宿主は、[RFC-1035]、[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セキュリティのセキュリティ上の利点は、常に彼らと達成することはできません。
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とESPのサポート仕様で必須として記載されています。
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.
このセクションの最初の部分は、細胞宿主での一般的なタスクのためのIPセキュリティと他のセキュリティ・メカニズムの適用可能性を論じています。第二の部分は、セクション3.13から3.1、のIPsecに関連する仕様を示し及び細胞の状況のIPsecのこれらの部分の使用を論じています。
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.
一般的には、セキュリティ・メカニズムを使用する必要性は、それのために意図された用途に依存します。異なるセキュリティメカニズムが異なる文脈において有用であり、そして異なる制限があります。一部のアプリケーションでは、IPsecが使用されているいくつかの状況ではTLS [RFC-2246]、使用する必要があります。
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.
次のセクションでは、IPsec機能に関連する仕様を一覧表示し、細胞の状況で彼らの適用性を議論します。この議論は、IPsecの使用に焦点を当てています。一部のアプリケーションでは、プロトコルの異なるセットを採用する必要があるかもしれません。具体的には、以下の議論は、IPsec以外のセキュリティ・サービスを使用するアプリケーションには関係ありません。
This specification [RFC-2104] must be supported. It is referenced by RFC 2403 that describes how IPsec protects the integrity of packets.
この仕様[RFC-2104]はサポートされなければなりません。これは、IPsecは、パケットの完全性を保護する方法について説明し、RFC 2403で参照されています。
This specification [RFC-2401] must be supported.
この仕様[RFC-2401]はサポートされなければなりません。
This specification [RFC-2402] must be supported.
この仕様[RFC-2402]はサポートされなければなりません。
This specification [RFC-2403] must be supported.
この仕様[RFC-2403]はサポートされなければなりません。
This specification [RFC-2404] must be supported.
この仕様[RFC-2404]はサポートされなければなりません。
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.
本明細書[RFC-2405]サポートされてもよいです。しかし、DESよりも強力なアルゴリズムを使用することをお勧めします。 AESなどのアルゴリズムは、IPsecワーキンググループで仕事を受けています。これらの新しいアルゴリズムは有用であり、できるだけ早くその標準化の準備ができるようサポートしなければなりません。
This specification [RFC-2406] must be supported.
この仕様[RFC-2406]はサポートされなければなりません。
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.
自動キー管理、[RFC-2408]と[RFC-2409]は、IPセキュリティアーキテクチャの必須部分ではありません。細胞環境内のホストのIPアドレスが動的に変更される可能性があること、しかし、注意してください。このため、手動で構成されたセキュリティアソシエーションの使用は、最新のホストアドレスは、同様に、ピアのSAデータベースに更新しなければならないであろうと、実用的ではありません。
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].
たとえそうだとしても、すべてのアプリケーションが鍵管理にIKEを使用することは明らかではありません。例えば、ホストは、[3GPP-ACC] IMS内のSIPシグナリングを保護するためにIPsec ESP [RFC-2406]を使用してもよいが、このようなUMTS AKA（認証及び鍵共有）UMTS-AKA]などの別の機構を介して認証及び鍵管理を提供します。
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.
いくつかの単純化の仮定はIPセキュリティDOI、ISAKMP、およびIKEの義務付け部に対して、細胞環境で行うことができると考えられます。そのような単純化の作業は役立つことが、この文書の範囲外であるだろう。
3.9 - The Internet Security Association and Key Management Protocol
3.9 - インターネットSecurity AssociationとKey Managementプロトコル
This specification [RFC-2408] is optional according to the IPv6 specifications, but may be necessary in some applications, as described in Section 3.8.
本明細書[RFC-2408]のIPv6仕様に応じて任意であるが、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.
本明細書[RFC-2409]のIPv6仕様に応じて任意であるが、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.
いくつかの特別な処理を実装して行われていない限りのICMPv6パケットおよびIPsecポリシーとの相互作用は、IKEベースのSAネゴシエーションのための予期しない動作を引き起こす可能性があります。
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.
ICMPv6のプロトコルは、IPv4に存在しない、または下位層によって提供されるいずれかであった多くの機能を提供します。例えば、IPv6は、IPパケット、ICMPv6の近隣要請メッセージを使用してアドレス解決を実現します。対照的に、IPv4が下層にARPメッセージを使用します。
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.
IPsecのアーキテクチャは保護され、どのようにされたトラフィックを指定するセキュリティポリシーデータベースを持っています。これは、ICMPv6のトラフィックの存在下での政策の仕様は容易ではないことが判明します。たとえば、同じネットワーク上の2つのホスト間のすべてのトラフィックを保護する簡単なポリシーは、トラップも、IKE UDPパケットを送信するために、1つは持っていたであろうからIKEはセキュリティアソシエーションを確立することができない状況につながる、解像度のメッセージに対処う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.
この問題を回避するために、近隣要請、近隣広告、ルーター要請、およびルーターアドバタイズメッセージは、IKEベースのSAネゴシエーションの使用につながらない必要があります。リダイレクトメッセージは、IKEベースのSAネゴシエーションの使用につながるべきではありません。セキュリティポリシーデータベースで望まれているように、他のICMPv6メッセージは、IKEベースのSAネゴシエーションを使用することができます。
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 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.)
上記すべてのICMPv6の通信を保護するのIPsecの有用性を制限することに留意されたいです。例えば、細胞宿主とその次のホップルータの間のICMPv6トラフィックを保護することはできないかもしれません。 （どの原因に適した公開鍵基盤を確立する必要性にどのような場合には難しいかもしれない。ローミングが許可されているので、このインフラストラクチャは、すべてのルータにすべてのホストを認証する必要があります。）
This specification [RFC-2410] must be supported.
本明細書[RFC-2410]サポートされなければなりません。
This specification [RFC-2451] must be supported if encryption algorithms other than DES are implemented, e.g., CAST-128, RC5, IDEA, Blowfish, 3DES.
本明細書[RFC-2451]はサポートされなければならないDES以外の暗号化アルゴリズムが実装されている場合、例えば、CAST-128、RC5、IDEA、フグ、3DES。
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.
このドキュメントの目的のために、IPモビリティは関係ありません。モバイルIPv6の仕様が承認されると、モバイルIPによるすべてのIPv6ホストにいくつかの影響があるかもしれないとして、このドキュメントの将来のアップデートでは、これらの問題に対処することができます。 3GPPネットワーク内の細胞宿主の移動は、リンクレイヤ機構によって処理されます。
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:
このドキュメントは、新しいプロトコルや機能を指定していない、そのように、それはどんな新しいセキュリティの脆弱性を導入しません。しかし、IPv6機能の特定のプロファイルは異なる状況のために提案されており、脆弱性が開いたり、近くには機能が含まれているかに依存してものではありません。脆弱性の特定の種類は、より厳しい作る細胞環境の側面もあります。以下の問題が議論されています。
- The suggested limitations (Section 2.3) in the processing of routing headers limits also exposure to DoS attacks through cellular hosts.
- 細胞宿主からもDoS攻撃への曝露をヘッダー制限をルーティングする処理で推奨限界（2.3節）。
- 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 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.
- プライバシー[RFC3041]をIPv6アドレスは、細胞宿主で使用することができます。しかし、細胞宿主は、PDPコンテキストをアクティブにしたときに、3GPPモデルでは、ネットワークはまた、ホストローミングの状況では、一般的に、ほとんどの場合、新しいアドレスを割り当てることに留意しなければなりません。これは、3GPPネットワークが既にプライバシーに対処する限定された形を提供することを意味し、単一のホストのグローバルな追跡は、そのアドレスによって可能ではありません。 GGSNのカバレッジエリアは、現在展開デフォルトルータ（GGSNとの間にはハンドオーバーが可能ではない）と比較して非常に大きくなることが予想されるので、一方、細胞宿主は、長い時間のためのアドレスを維持することができます。したがって、プライバシーをIPv6アドレスは、ホストが上と同じエリアにある時間の間、追加のプライバシーのために使用することができます。プライバシー機能も、例えば異なるトランスポートセッションは異なるIPアドレスから来るように見えるために使用することができます。しかし、彼らが唯一のネットワークプレフィックス部分を監視することができるよう、これらの追加の努力は、任意の更なる潜在的なオブザーバーを混同することは明らかではありません。
- 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.
- そのような細胞宿主における典型的なアプリケーションの接続のIPsec又はTLSなどの様々なセキュリティ・サービスの使用は、第3節で議論されており、推奨はそこ挙げられます。
- Section 3 also discusses under what conditions it is possible to provide IPsec protection of e.g., ICMPv6 communications.
- 第3節はまた、例えば、ICMPv6の通信のIPsec保護を提供することができるどのような条件の下で説明します。
- 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.
- 細胞宿主で使用される放送時間は高価です。いくつかのケースでは、ユーザーは、それらが、そのホストから転送するデータの量に応じて課金されます。これは、放送時間が正しく使用され、余分な電荷が第三者に不正な動作のためにユーザーに適用されていないことを、ネットワークとユーザーの両方のために非常に重要です。セルラーのリンクはまた、彼らは必ずしも、このようなマルチメディア呼び出しとして、ユーザーが選択したものよりもより多くのトラフィックに対応することができないかもしれないということを意味限られた容量を、持っています。追加のトラフィックは、ユーザが経験するサービスレベルに干渉する可能性があります。サービス品質のメカニズムは、ある程度、これらの問題を軽減するが、DoS攻撃の側面は細胞環境で強調表示することができるということはまだ明らかです。これは、この環境では、実質的により有害であることをインスタンスパケット増幅のために使用する既存のDoS攻撃が可能です。どのようにこれらの攻撃は、まださらなる研究の分野で保護することができます。追加または大きなパケットで両側にセルラーリンクとキューを埋めるためにも、多くの場合は簡単です。
- 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.
- ローカルインタフェースを適切な方法で固定されていない限り（例えばIrDAのまたはBluetoothなど）、ローカルネットワークインタフェースを有する携帯電話装置は、それらを介して攻撃を仕掛けるために使用されてもよいです。したがって、ローカルネットワークインタフェースは、媒体として細胞宿主を使用して他人を防ぐために、アクセス制御を有するべきです。
[RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC-1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC-1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6, RFC 1886, December 1995.
[RFC-1886]トムソン、S.とC.のHuitema、「DNSの拡張機能IPバージョン6をサポートするために、RFC 1886、1995年12月。
[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-1981]マッキャン、J.、ムガール人、J.とS.デアリング、 "パスMTUディスカバリIPバージョン6のために"、RFC 1981、1996年8月。
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC-2104] Krawczyk, K., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104] Krawczyk、K.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC-2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC-2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC-2403] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP and AH", RFC 2403, November 1998.
[RFC-2403] Madson、C.、およびR.グレン、 "ESPおよびAH内のHMAC-MD5の使用"、RFC 2403、1998年11月。
[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.、およびR.グレン、 "ESPおよびAH内HMAC-SHA-1の使用"、RFC 2404、1998年11月。
[RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC-2405] Madson、C.およびN. Doraswamy、 "明示的なIVとESP DES-CBC暗号アルゴリズム"、RFC 2405、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[RFC-2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティプロトコル（ESP）"、RFC 2406、1998年11月。
[RFC-2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC-2407]パイパー、D.、RFC 2407 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、1998年11月。
[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]モーガン、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408、1998年11月。
[RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC-2409]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC-2410]グレン、R.とS.ケント、 "NULL暗号化アルゴリズムとIPsecでの使用"、RFC 2410、1998年11月。
[RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC-2451]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[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.およびW.シンプソン、RFC 2461 "IPバージョン6（IPv6）のための近隣探索"、1998年12月。
[RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC-2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC-2463] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[RFC-2463]コンタ、A.とS.デアリング、RFC 2463 "インターネットプロトコルバージョン6（IPv6）のためのICMP"、1998年12月。
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC-2473]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC-2710]デアリング、S.、フェナー、W.およびB.ハーバーマン、 "マルチキャストリスナ発見（MLD）IPv6の"、RFC 2710、1999年10月。
[RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC-2711]ヤマウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[RFC-2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC-2874]クロフォード、M.とC.のHuitemaは、RFC 2874、2000年7月 "DNSの拡張機能は、IPv6アドレスの集約とリナンバリングを支援します"。
[RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC-3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC-3152]ブッシュ、R.、 "IP6.ARPAの委任"、BCP 49、RFC 3152、2001年8月。
[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]ドーキンス、S.、モンテネグロ、G.、古城、M.、Magret、V.およびN. Vaidya、 "エラーとのリンクのエンド・ツー・エンドのパフォーマンスへの影響"、BCP 50、RFC 3155年8月2001。
[RFC-3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC-3484] Draves、R.、 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、RFC 3484、2003年2月。
[RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC-3513] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[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技術仕様3GPP TS 33.203、 "技術仕様グループサービスおよびシステムアスペクト; 3Gセキュリティ; IPベースのサービスのアクセスセキュリティ（リリース5）"、第3世代パートナーシップ・プロジェクト、2002年3月。
[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]第3世代パートナーシッププロジェクト。グループサービス及びシステムアスペクト技術仕様; IPマルチメディア（IM）サブシステム - ステージ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]第3世代パートナーシッププロジェクト。グループサービス及びシステムアスペクト技術仕様「建築要件」（TS 23.221）
[DHCPv6] Bound, J., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in progress.
[DHCPv6の】バウンド、J.、ら。、 "IPv6のための動的ホスト構成プロトコル（DHCPv6の）" は、進行中の作業します。
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC-1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC-2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC-2529]大工、B.及びC.チョン、 "明示的なトンネルなしでのIPv4ドメイン上のIPv6の送信"、RFC 2529、1999年3月。
[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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC-3314] Wasserman, M., Editor, "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, RFC 3314, September 2002.
[RFC-3314]ワッサーマン、M.、エディタ、第三世代パートナーシッププロジェクト（3GPP）規格、RFC 3314でのIPv6のための「勧告、2002年9月。
[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]稲村、H.、モンテネグロ、G.、ルートヴィヒ、R.、Gurtov、A.及びF. Khafizov、BCP 71 "セカンド（2.5G）と第3（3G）世代無線ネットワーク上でTCP"、 RFC 3481、2003年2月。
[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技術仕様3GPP TS 33.102、 "技術仕様グループサービスおよびシステムアスペクト; 3Gセキュリティ;セキュリティアーキテクチャ（リリース4）"、第3世代パートナーシップ・プロジェクト、2001年12月。
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.
このドキュメントは、作者に加えて、ピーターHedmanとPertti Suomelaを含め、チームの結果に基づいています。ピーターとPerttiは、本文書にテキストとそのIPv6の経験の両方に貢献してきました。
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.
作者は彼らのコメントや入力のためのIPv6 WGメーリングリストでバウンドジム、ブライアン・カーペンター、スティーブデアリング、ボブHindenとキース・ムーア、トーマスNarten氏、エリックNordmarkと、マイケル・トーマス、マーガレットワッサーマンと他の人に感謝したいと思います。
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.
また、本文書の作成に彼らのコメント入力のためにデビッドDeCamp、カリム・エルMalki、マルクスIsomaki、ペター・ヨンセン、ヤンネリンネ、Jonne Soininen、ヴラドStirbuとShabnamスルタナに感謝したいと思います。
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model
付録A - 細胞宿主IPv6は、3GPPモデルに対処します
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.
付録には、非常に簡単に2G（GPRS）と3G（UMTS）以降リリース99から携帯電話ネットワークのための3GPPのIPv6アドレス指定のモデルを記述することを目指しています。詳細については、3GPP技術仕様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).
ステートレスとステートフル自動設定：IPv6ノードのアドレスを割り当てるには、2つの可能性があります。ステートフルアドレス割り当てメカニズムは、IPv6ノードのアドレスを割り当てるDHCPサーバを必要とします。一方、ステートレス自動設定手順は、（離れて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).
標準のIPv6ステートレスアドレス自動設定機構をサポートするために、IETFによって推奨されるように、GGSNは、IPv6ステートレスアドレス自動設定を使用する各プライマリPDPコンテキストにその範囲内で一意のプレフィックスを割り当てなければなりません。これは、モバイルホストによって構築されたすべてのアドレスのネットワークレベルでの重複アドレス検出を実行する必要性を回避します。 GGSNは、常にモバイルホストへのインタフェース識別子を提供します。モバイルホストはそのリンクローカルアドレスを生成するために、GGSNによって提供されるインターフェイス識別子を使用します。 GGSNは、通常、ランダムに、インタフェース識別子を持つ細胞宿主を提供します。これは、リンク上で、そのような識別子の一意性を保証しなければならない（すなわち、独自のリンクローカルアドレスと、細胞宿主の間の衝突なし）。
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.
また、GGSNは自身のアドレスのいずれかを生成するために、細胞宿主に割り当てられたプレフィックスのいずれかを使用しません。各PDPコンテキストは一意のプレフィックスを割り当てられているという事実と組み合わさインタフェース識別子の使用は、エアインタフェースを介してDADメッセージの必要性を排除し、その結果、帯域幅の効率的な使用を可能にするであろう。さらに、各PDPコンテキストにプレフィックスの割り当ては、ホストがさらにDADメッセージを必要とせずにRFC 3041でのプライバシーの拡張を実装することができます。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson 02420 Jorvas Finland
ヤリArkkoエリクソン02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
Gerben Kuijpers Ericsson Skanderborgvej 232 DK-8260 Viby J Denmark
Gerben KuijpersエリクソンSkanderborgvej 232 DK-8260ヴィビーデンマーク
EMail: gerben.a.kuijpers@ted.ericsson.se
メールアドレス：gerben.a.kuijpers@ted.ericsson.se
John Loughney Nokia Research Center Itamerenkatu 11 - 13 FIN-00180 HELSINKI Finland
じょｈん ぉうｇｈねｙ のきあ れせあｒｃｈ せんてｒ いためれんかつ １１ ー １３ ふぃんー００１８０ へＬしんき ふぃんぁんｄ
EMail: john.loughney@nokia.com
メールアドレス：john.loughney@nokia.com
Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 23, Kista, Stockholm Sweden
Heshamソリマン、エリクソン無線システムAB Torshamnsgatan 23、ストックホルム、スウェーデン
EMail: hesham.soliman@era.ericsson.se
メールアドレス：hesham.soliman@era.ericsson.se
Juha Wiljakka Nokia Mobile Phones Sinitaival 5 FIN-33720 TAMPERE Finland
ユハWiljakkaノキア携帯電話ブルーTaivalkoski 5 FIN-33720 TAMPEREフィンランド
EMail: juha.wiljakka@nokia.com
メールアドレス：juha.wiljakka@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。