[要約] 要約： RFC 3316は、第2世代および第3世代の携帯ホストに対するIPv6の実装に関するガイドラインを提供しています。このRFCの目的は、携帯ネットワークでIPv6をサポートするための手順と要件を定義することです。目的： 1. 第2世代および第3世代の携帯ホストにIPv6を実装するためのガイドラインを提供する。 2. 携帯ネットワークでIPv6のサポートを促進するための手順と要件を定義する。 3. IPv6の普及を推進し、モバイルネットワークの進化に対応する。
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
インターネットプロトコルバージョン6（IPv6）いくつかの第2世代および第3世代のセルラーホストの
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.
Copyright（c）The Internet Society（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.
第2世代および第3世代のセルラーネットワークの展開が進むにつれて、多数のセルラーホストがインターネットに接続されています。標準化組織は、インターネットプロトコルバージョン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は、そのような細胞宿主の数が急速に増加すると予想されるため、必要になります。Cellular Technologiesを扱う標準化組織はこれを認識しており、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のサポートとUMTの導入は、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.
このドキュメントには、Cellular Interfaceを操作する際のこれらの仕様の使用に関する議論を伴う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、3GPP UMTSリリース99、リリース4、リリース5、またはUMTSの将来のリリースで使用されるセルラーホストの実装者です。このドキュメントは、そのような細胞宿主に実装する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.
- ホストは、非常にコンパクトなサイズと最適化されたアプリケーションを備えた「閉じた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、Bluetoothなど）がある場合、このドキュメントで説明されているものを超えて、デバイスに追加要件がある場合があります。さらに、このドキュメントでは、セルラーリンクでのリンク固有の動作を推奨する以外に、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の第2世代のモバイル通信。UMTSテクノロジーなど、3Gサードジェネレーションモバイル通信。3GPP第3世代パートナーシッププロジェクト。ドキュメント全体で、3GPP（第3世代パートナーシッププロジェクト）ネットワークという用語は、3GPPが標準化されたアーキテクチャを指し、第2世代および第3世代のリリース：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
セキュリティペイロードETSI欧州通信基準研究所IMS IPマルチメディアサブシステムGGSNゲートウェイGPRSサポートノード（3GPP IPv6セルラーホストのデフォルトルーター）GPRS一般パケットラジオサービスGSMグローバルシステムモバイルコミュニケーションIKEインターネットISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP MANAGELATION ANDACEProtocol MTモバイルターミナル、たとえば、携帯電話の携帯電話。MTU最大送信ユニットPDPパケットデータプロトコルSGSNサービングGPRSは、3GPPハンドセットを介して取り付けられたラップトップなど、ノードTEターミナル機器をサポートします。UMTSユニバーサルモバイルテレコミュニケーションシステムwlanワイヤレスローカルエリアネットワーク
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セキュリティパーツについて説明します。
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.
Path MTU Discovery [RFC-1981]を使用できます。最小IPv6リンクMTU（1280オクテット）よりも大きいリンクMTUを持つセルラーホストは、実際のパスMTUを発見するためにPATH 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]は、セクション5で、「最小限のIPv6実装（ブートROMなど）は、1280オクテット以下のパケットを送信することに単純に制限され、PATH MTU発見の実装を省略することを単に制限する可能性があると述べています。
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が受け入れられているよりも少ないことを知る方法がないためです。
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
- ホップバイホップオプションヘッダー：少なくともPAD1およびPADNオプション
- Destination Options header: at least the Pad1 and PadN 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および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).
セルラー宿主は、常にフラグメントヘッダーを受け取り、再組み立てできる必要があります。また、翻訳者を介して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つであるかどうかを進める必要があります。ただし、ホストは、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を介して実行されるアプリケーションは、可能であれば確認を提供する必要があります。特に、RTPの輸送にUDPを使用する場合、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 ACKリクエストの受領を、以前に送信したSIP招待リクエストへの応答がピアに到達したことを確認するとして解釈する場合があります。
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This specification is a mandatory part of IPv6.
IPv6ステートレスアドレスAutoconfigurationは[RFC-2462]で定義されています。この仕様は、IPv6の必須部分です。
A cellular host in a 3GPP network must process a Router Advertisement as stated in Section 2.4.
3GPPネットワークのセルラーホストは、セクション2.4に記載されているように、ルーター広告を処理する必要があります。
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 StatelessアドレスAutoconfigurationを使用して割り当てられた場合、各委任されたプレフィックスはその範囲内で一意であるため、3GPPネットワークのホストはdupaddrdeTecttransmitsをゼロに等しく設定できます。さらに、デフォルトのルーター（GGSN）は、IPv6ホストに委任された接頭辞に基づいたアドレスに基づくアドレスをインターフェイスに構成または割り当てません。したがって、ホストは、セルラー界面で重複するアドレス検出を実行する必要はありません。
See Appendix A for more details on 3GPP IPv6 Stateless Address Autoconfiguration.
3GPP IPv6ステートレスアドレスAutoconfigurationの詳細については、付録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を超えるPPP [RFC-2472]を超えるIPv6は、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オプションを使用して、MTがTEにMTによって提案されているインターフェイス識別子が提案されます。TEとGGSNの間のリンクローカルアドレスの重複を回避するには、MTは常にTEによる他の提案されたインターフェイス識別子を拒否する必要があります。これにより、Link-Localアドレスに対してGGSNによって提案されたインターフェイス識別子を常に使用します。
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メッセージをLink-Local Multicastアドレス（All-Nodesアドレスを除く）に送信する必要があります。Link-LocalアドレスでもMLDが実行されるという要件は、リンク層マルチキャストパケットの転送をリスナーがいないレイヤーツーネットワークの一部に抑制しようとするレイヤー2デバイス（例：イーサネットブリッジ）をAIDSレイヤー2デバイス（イーサネットブリッジなど）に支援します。MLDを使用して、すべてのIPマルチキャストアドレス（Link-Local Multicastアドレスを含む）のリスナーの存在を発表する場合、レイヤー2デバイスはMLDメッセージをスヌープして、ネットワークIPマルチキャストメッセージのどの部分を転送する必要があるかを確実に決定できます。
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デバイスが正確にあり、マルチキャストトラフィックの転送を抑制する試みは（リンク層で）行われません。その結果、3GPP環境でLink-LocalアドレスのMLDレポートを送信する必要があるとは限りません。
MLD is needed for multicast group knowledge that is not link-local.
MLDは、Link-Localではないマルチキャストグループの知識に必要です。
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.
Statelessアドレスのプライバシー拡張オートコンチュレーション[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 Stateless Autoconfigurationが使用される場合、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セキュリティおよびその他のセキュリティメカニズムの適用性について説明します。2番目の部分であるセクション3.1〜3.13には、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.
一般に、セキュリティメカニズムを使用する必要性は、意図したアプリケーションに依存します。さまざまなセキュリティメカニズムは、さまざまなコンテキストで有用であり、さまざまな制限があります。一部のアプリケーションでは、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を使用してキー管理に使用することは明らかではありません。たとえば、ホストはIPSEC ESP [RFC-2406]を使用してIMS [3GPP-ACC]のSIPシグナル伝達を保護することができますが、UMTS（認証と重要な契約）[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の義務付けられた部分に関して、セルラー環境でいくつかの単純化された仮定を作成できる可能性があります。このような単純化に取り組むことは有用ですが、このドキュメントの範囲外です。
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 Neighbor Solicitationメッセージを使用してアドレス解像度を実装します。対照的に、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パケットを送信するために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以外の暗号化アルゴリズムが実装されている場合は、サポートする必要があります。
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.
- ルーティングヘッダーの処理における提案された制限（セクション2.3）は、携帯電話宿主を介したDOS攻撃への曝露もあります。
- 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.
- Privacy [RFC3041]にアドレス指定するIPv6は、セルラー宿主で使用できます。ただし、3GPPモデルでは、ネットワークは、ほとんどの場合、新しいアドレスをローミング状況でホストに割り当て、通常、セルラーホストがPDPコンテキストをアクティブ化する場合にも割り当てます。これは、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など）を備えたセルラーデバイス（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] Thomson、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] McCann、J.、Mogul、J。およびS. Deering、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2026] Bradner、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.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC-2246] Dierks、T。およびC. Allen、「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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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. Glenn、「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. Glenn、「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、「ESP Des-CBC暗号アルゴリズムを備えたIVを備えた」、RFC 2405、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[RFC-2406] Kent、S。およびR. Atkinson、「IP Cankupsing Security Protocol（ESP）」、RFC 2406、1998年11月。
[RFC-2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC-2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、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] Maughan、D.、Schertler、M.、Schneider、M.、およびJ. Turner、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、1998年11月。
[RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC-2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Glenn、R。およびS. Kent、「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] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[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、バージョン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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC-2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）のICMP」、RFC 2463、1998年12月。
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC-2473] Conta、A。およびS. Deering、「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] Deering、S.、Fenner、W.およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC-2711] Partridge、C。およびA. Jackson、「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] Crawford、M。およびC. Huitema、「IPv6アドレスの集約と改修をサポートするDNS拡張」、RFC 2874、2000年7月。
[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のステートレスアドレスAutoconfigurationのプライバシー拡張」、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] Dawkins、S.、Montenegro、G.、Kojo、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. Deering、「インターネットプロトコルバージョン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）」、2002年3月、第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] Bound、J.、et al。、「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] Carpenter、B。およびC. Jung、「明示的なトンネルなしの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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Wasserman、M.、編集者、「第3世代パートナーシッププロジェクト（3GPP）標準におけるIPv6の推奨、RFC 3314、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.、ガルトフ、A。、およびF.カフィゾフ、「2番目（2.5g）および3番目（3g）の世代ワイヤレスネットワーク上のTCP」、BCP 71、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）」、2001年12月、第3世代パートナーシッププロジェクト。
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.
このドキュメントは、著者に加えてピーター・ヘドマンとペトティ・スメラを含むチームの結果に基づいています。Peterと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メーリングリストに、ジム・バウンド、ブライアン・カーペンター、スティーブ・ディアリング、ボブ・ヒンデン、キース・ムーア、トーマス・ナルテン、エリック・ノードマーク、マイケル・トーマス、マーガレット・ワッサーマンなどに感謝したいと思います。
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.
また、デビッド・デカンプ、カリム・エル・マルキ、マルクス・イソマキ、ペッター・ジョンセン、ジャンヌ・リンヌ、ジョンヌ・ソイニネン、ヴラッド・スターブ、シャブナム・スルタナのコメントとこの文書の準備の入力に感謝します。
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model
付録A- 3GPPモデルでアドレス指定するセルラーホストIPv6
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.
付録は、リリース99以降の2G（GPRS）および3G（UMTS）セルラーネットワークの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つあります。つまり、ステートレスとステートフルなオートコンチュレーションです。Statefulアドレスの割り当てメカニズムには、IPv6ノードのアドレスを割り当てるためにDHCPサーバーが必要です。一方、Stateless Autoconfiguration手順では、アドレスAutoconfiguration（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).
IETFが推奨するように、標準のIPv6ステートレスアドレスAutoconfigurationメカニズムをサポートするために、GGSNは、IPv6 StatelessアドレスAutoconfigurationを使用する各プライマリ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コンテキストへのプレフィックスの割り当てにより、ホストはさらなるお父さんメッセージを必要とせずにRFC 3041でプライバシー拡張機能を実装できます。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson 02420 Jorvas Finland
Jari Arkko Ericsson 02420 Jorvas Finland
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
John Loughney Nokia Research Center Itamerenkatu 11 - 13 FIN-00180 HELSINKI Finland
ジョン・ラフニー・ノキア研究センターitamerenkatu 11-13フィン-00180ヘルシンキフィンランド
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、ストックホルムスウェーデン
EMail: hesham.soliman@era.ericsson.se
Juha Wiljakka Nokia Mobile Phones Sinitaival 5 FIN-33720 TAMPERE Finland
Juha Wiljakka Nokia Nokia携帯電話Sinitaival 5 Fin-33720 Tampere Finland
EMail: juha.wiljakka@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。