[要約] RFC 7066は、第3世代パートナーシッププロジェクト（3GPP）の携帯ホストにおけるIPv6に関する仕様です。このRFCの目的は、3GPPネットワークでのIPv6の使用を促進し、モバイルホストのIPv6サポートを向上させることです。
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 7066 Broadcom
Obsoletes: 3316 J. Arkko, Ed.
Category: Informational Ericsson
ISSN: 2070-1721 T. Savolainen
Nokia
S. Krishnan
Ericsson
November 2013
IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts
第3世代パートナーシッププロジェクト（3GPP）セルラーホストのIPv6
Abstract
概要
As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the 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), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316.
第3世代および第4世代のセルラーネットワークの導入が進むにつれて、多数のセルラーホストがインターネットに接続されています。標準化組織は、インターネットプロトコルバージョン6（IPv6）を仕様に必須にしています。ただし、IPv6の概念は、多くの側面と多数の仕様をカバーしています。さらに、帯域幅、コスト、および遅延に関するセルラーリンクの特性により、IPv6の使用方法に特別な要件が課されます。このドキュメントでは、General Packet Radio Service（GPRS）、Universal Mobile Telecommunications System（UMTS）、またはEvolved Packet System（EPS）ネットワーク（以降、総称してThird Generation Partnership Project（3GPP）ネットワークと呼びます）に接続するセルラーホストのIPv6について検討します。このドキュメントには、IPv6ノード要件ドキュメント（RFC 6434）で既に規定されているものに加えて、実装する必要がある特定のIPv6機能もリストされています。また、これらのネットワークで動作するときのこれらのコンポーネントの使用に関連するいくつかの問題についても説明します。このドキュメントはRFC 3316を廃止します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7066.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7066で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope of This Document .....................................3
1.2. Abbreviations ..............................................5
1.3. Cellular Host IPv6 Features ................................6
2. Basic IP ........................................................6
2.1. Internet Protocol Version 6 ................................6
2.2. Neighbor Discovery in 3GPP Networks ........................6
2.3. Stateless Address Autoconfiguration ........................8
2.4. IP Version 6 over PPP ......................................8
2.5. Multicast Listener Discovery (MLD) for IPv6 ................9
2.6. Privacy Extensions for Address Configuration in IPv6 .......9
2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ......9
2.8. DHCPv6 Prefix Delegation ..................................10
2.9. Router Preferences and More-Specific Routes ...............10
2.10. Neighbor Discovery and Additional Host Configuration .....10
3. IP Security ....................................................11
3.1. Extension Header Considerations ...........................11
4. Mobility .......................................................11
5. Acknowledgements ...............................................11
6. Security Considerations ........................................12
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model .......17
Appendix B. Changes from RFC 3316 .................................18
Technologies such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), Evolved Packet System (EPS), CDMA2000 (Code Division Multiple Access 2000), and eHRPD (Enhanced High Rate Packet Data) are making it possible for cellular hosts to have an always-on connection to the Internet. IPv6 [RFC2460] has become essential to such networks as the number of cellular hosts is increasing rapidly. Standardization organizations working with cellular technologies have recognized this and made IPv6 mandatory in their specifications.
GPRS（General Packet Radio Service）、UMTS（Universal Mobile Telecommunications System）、Evolved Packet System（EPS）、CDMA2000（Code Division Multiple Access 2000）、eHRPD（Enhanced High Rate Packet Data）などのテクノロジーにより、インターネットに常時接続するホスト。 IPv6 [RFC2460]は、セルラーホストの数が急速に増加しているため、このようなネットワークに不可欠になっています。セルラー技術を扱う標準化組織はこれを認識しており、仕様でIPv6を義務化しています。
Support for IPv6 and the introduction of UMTS started with 3GPP Release-99 networks and hosts. For a detailed description of IPv6 in 3GPP networks, including the Evolved Packet System, see [RFC6459].
IPv6のサポートとUMTSの導入は、3GPPリリース99ネットワークとホストで始まりました。 Evolved Packet Systemを含む3GPPネットワークのIPv6の詳細については、[RFC6459]を参照してください。
For the purpose 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 and Release-4 to Release-11; EPS Release-8 to Release-11; and future UMTS or EPS releases. A cellular host is considered to be a host with such a cellular interface.
このドキュメントでは、セルラーインターフェイスは、次の標準に基づくセルラーアクセスネットワークへのインターフェイスと見なされます。3GPPGPRSおよびUMTSリリース99およびリリース4からリリース11。 EPSリリース8からリリース11。および将来のUMTSまたはEPSリリース。セルラーホストは、このようなセルラーインターフェイスを持つホストと見なされます。
This document complements the IPv6 Node Requirements [RFC6434] in places where clarifications are needed with discussion on the use of these selected IPv6 specifications when operating over a cellular interface. Such a specification is necessary in order to enable the optimal use of IPv6 in a cellular network environment. The description is made from the point of view of a cellular host. Complementary access technologies may be supported by the cellular host, but those are not discussed in detail. Important considerations are given in order to eliminate unnecessary user confusion over configuration options, ensure interoperability, and provide an easy reference for those who are implementing IPv6 in a cellular host. It is necessary to ensure that cellular hosts are good citizens of the Internet.
このドキュメントは、セルラーインターフェイス上で動作するときのこれらの選択されたIPv6仕様の使用についての議論で明確化が必要な場所でIPv6ノード要件[RFC6434]を補足します。このような仕様は、セルラーネットワーク環境でIPv6を最適に使用できるようにするために必要です。説明は、細胞宿主の観点からなされている。補完的なアクセス技術は携帯電話ホストによってサポートされるかもしれません、しかしそれらは詳細に議論されません。構成オプションに対するユーザーの不要な混乱を排除し、相互運用性を確保し、セルラーホストにIPv6を実装しているユーザーに簡単なリファレンスを提供するために、重要な考慮事項が与えられます。セルラーホストがインターネットの良き市民であることを確認する必要があります。
This document is informational in its nature, and it is not intended to replace, update, or contradict any IPv6 standards documents or the IPv6 Node Requirements [RFC6434].
このドキュメントは、その性質上情報を提供するものであり、IPv6標準ドキュメントまたはIPv6ノード要件[RFC6434]の置き換え、更新、または矛盾を意図したものではありません。
This document is primarily targeted to the implementers of cellular hosts that will be used with the cellular networks listed in this document. This document provides guidance on which IPv6-related specifications are to be implemented in such cellular hosts. Parts of this document may also apply to other cellular link types, but this document does not provide any detailed analysis on other link types. This document should not be used as a definitive list of IPv6 functionalities for cellular links other than those listed above. Future changes in 3GPP networks that impact host implementations may result in updates to this document.
このドキュメントは主に、このドキュメントに記載されているセルラーネットワークで使用されるセルラーホストの実装者を対象としています。このドキュメントでは、このようなセルラーホストに実装されるIPv6関連の仕様に関するガイダンスを提供します。このドキュメントの一部は他のセルラーリンクタイプにも適用される場合がありますが、このドキュメントでは他のリンクタイプの詳細な分析は提供していません。このドキュメントは、上記以外のセルラーリンクのIPv6機能の完全なリストとして使用しないでください。ホストの実装に影響を与える3GPPネットワークの将来の変更により、このドキュメントが更新される可能性があります。
There are different ways to implement cellular hosts:
セルラーホストを実装する方法はいくつかあります。
o The host can be a "closed" device with optimized built-in 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.
o ホストは、最適化された組み込みアプリケーションを備えた「クローズド」デバイスにすることができ、IP通信が可能なアプリケーションを追加またはダウンロードすることはできません。そのようなホストの例は、携帯電話の非常に単純な形式です。
o The host can be an open device, e.g., a "smart phone" where it is possible to download applications to expand the functionality of the device.
o ホストは、デバイスの機能を拡張するアプリケーションをダウンロードできる「スマートフォン」などのオープンデバイスにすることができます。
o The cellular radio modem part can be separated from the host IP stack with an interface. One example of such a host is a laptop computer that uses a USB cellular modem for cellular access.
o セルラー無線モデム部分は、インターフェースを使用してホストIPスタックから分離できます。このようなホストの一例は、セルラーアクセスにUSBセルラーモデムを使用するラップトップコンピューターです。
If a cellular host has additional IP-capable interfaces (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 an embedded modem or a USB modem stick, other than recommending link-specific behavior on the cellular link.
セルラーホストに追加のIP対応インターフェイス（イーサネット、WLAN、Bluetoothなど）がある場合、このドキュメントで説明されているもの以外に、デバイスに追加の要件がある可能性があります。さらに、このドキュメントでは、セルラーリンクでのリンク固有の動作を推奨すること以外は、組み込みモデムやUSBモデムスティックなどのセルラーインターフェイスを備えたラップトップコンピューターに必要な機能については推奨していません。
This document discusses IPv6 functionality as of the time when this document was written. Ongoing work on IPv6 may affect what is required of future hosts.
このドキュメントでは、このドキュメントが作成された時点でのIPv6機能について説明します。 IPv6で進行中の作業は、将来のホストに必要なものに影響を与える可能性があります。
Transition mechanisms used by cellular hosts are not in the scope of this document and are left for further study. The primary transition mechanism supported by 3GPP is dual-stack [RFC4213]. Dual-stack-capable bearer support has been added to GPRS starting from 3GPP Release-9 and to EPS starting from Release-8 [RFC6459], whereas the earlier 3GPP releases required multiple single IP version bearers to support dual-stack.
セルラーホストによって使用される移行メカニズムは、このドキュメントの範囲外であり、今後の研究に残します。 3GPPでサポートされる主要な移行メカニズムは、デュアルスタック[RFC4213]です。デュアルスタック対応のベアラーサポートは、3GPPリリース9以降のGPRSおよびリリース8 [RFC6459]以降のEPSに追加されていますが、以前の3GPPリリースでは、デュアルスタックをサポートするために複数の単一IPバージョンベアラーが必要でした。
2G Second Generation Mobile Telecommunications, such as Global System for Mobile Communications (GSM) and GPRS technologies.
グローバルシステムモバイルコミュニケーション（GSM）やGPRSテクノロジーなどの2G第二世代モバイルテレコミュニケーション。
3G Third Generation Mobile Telecommunications, such as UMTS technology.
UMTSテクノロジーなどの3G第三世代モバイル通信。
4G Fourth Generation Mobile Telecommunications, such as LTE technology.
LTEテクノロジーなどの4G第4世代モバイル通信。
3GPP Third Generation Partnership Project. Throughout the document, the term "3GPP networks" refers to architectures standardized by 3GPP, in Second, Third, and Fourth Generation releases: 99, 4, and 5, as well as future releases.
3GPP第三世代パートナーシッププロジェクト。このドキュメント全体を通じて、「3GPPネットワーク」という用語は、第2、第3、および第4世代のリリース（99、4、5、および将来のリリース）で3GPPによって標準化されたアーキテクチャを指します。
EPS Evolved Packet System.
EPS Evolved Packet System。
GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6 cellular hosts in GPRS).
GGSNゲートウェイGPRSサポートノード（GPRSの3GPP IPv6セルラーホストのデフォルトルーター）。
GPRS General Packet Radio Service.
GPRS General Packet Radio Service。
LTE Long Term Evolution.
LTE Long Term Evolution。
MT Mobile Terminal, for example, a mobile phone handset.
MT Mobile Terminal、たとえば携帯電話の受話器。
MTU Maximum Transmission Unit.
MTU最大伝送ユニット。
PDN Packet Data Network.
PDNパケットデータネットワーク。
PDP Packet Data Protocol.
PDPパケットデータプロトコル。
PGW Packet Data Network Gateway (the default router for 3GPP IPv6 cellular hosts in EPS).
PGWパケットデータネットワークゲートウェイ（EPSの3GPP IPv6セルラーホストのデフォルトルーター）。
SGW Serving Gateway (the user plane equivalent of a Serving GPRS Support Node (SGSN) in EPS (and the default router for 3GPP IPv6 cellular hosts when using Proxy Mobile IPv6 (PMIPv6))).
SGWサービングゲートウェイ（EPSのサービングGPRSサポートノード（SGSN）に相当するユーザープレーン（およびプロキシモバイルIPv6（PMIPv6）を使用する場合の3GPP IPv6セルラーホストのデフォルトルーター））。
TE Terminal Equipment, for example, a laptop attached through a 3GPP handset.
TE端末機器。たとえば、3GPPハンドセットを介して接続されたラップトップ。
UMTS Universal Mobile Telecommunications System.
UMTSユニバーサルモバイルテレコミュニケーションシステム。
WLAN Wireless Local Area Network.
WLANワイヤレスローカルエリアネットワーク。
This document lists IPv6 features for cellular hosts; these features are split into three groups and are discussed below.
このドキュメントでは、セルラーホストのIPv6機能について説明します。これらの機能は3つのグループに分かれており、以下で説明します。
Basic IP
基本的なIP
In this group, the basic IPv6 features essential for cellular hosts are listed and described.
このグループでは、セルラーホストに不可欠な基本的なIPv6機能がリストされ、説明されています。
IP Security
IPセキュリティ
In this group, the parts related to IP Security are described.
このグループでは、IPセキュリティに関連する部分について説明します。
Mobility
可動性
In this group, IP-layer mobility issues are described.
このグループでは、IP層のモビリティの問題について説明します。
For most parts, refer to the IPv6 Node Requirements document [RFC6434].
ほとんどの部分については、IPv6ノード要件ドキュメント[RFC6434]を参照してください。
The Internet Protocol version 6 (IPv6) is specified in [RFC2460]. This specification is a mandatory part of IPv6. A cellular host must conform to the generic IPv6 host requirements [RFC6434], unless specifically pointed out otherwise in this document.
インターネットプロトコルバージョン6（IPv6）は、[RFC2460]で指定されています。この仕様はIPv6の必須部分です。セルラーホストは、このドキュメントで特に指摘されていない限り、一般的なIPv6ホスト要件[RFC6434]に準拠する必要があります。
A cellular host must support Neighbor Solicitation and Neighbor Advertisement messages [RFC4861]. Some further notes on how Neighbor Discovery is applied in the particular type of an interface can be useful.
セルラーホストは、近隣要請メッセージおよび近隣アドバタイズメッセージ[RFC4861]をサポートする必要があります。特定の種類のインターフェイスで近隣探索がどのように適用されるかについてのいくつかの追加のメモが役立ちます。
In 3GPP networks, some Neighbor Discovery messages can be unnecessary in certain cases. GPRS, UMTS, and EPS 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. The cellular host always solicits for routers when the cellular interface is brought up (as described in [RFC4861], Section 6.3.7).
3GPPネットワークでは、場合によっては一部の近隣探索メッセージが不要になることがあります。 GPRS、UMTS、およびEPSリンクは、ポイントツーポイントリンクに似ています。したがって、セルラーリンク上のセルラーホストの唯一のネイバーは、ルーター探索によって既に認識されているデフォルトルーターです。セルラーホストは、セルラーインターフェースが起動したときに常にルーターを要求します（[RFC4861]のセクション6.3.7を参照）。
There are no link-layer addresses on the 3GPP cellular link technology. Therefore, address resolution and next-hop determination are not needed. If the cellular host still attempts to do address resolution, e.g., for the default router, it must be understood that the GGSN/PGW may not even answer the address resolution Neighbor Solicitations. And even if it does, the Neighbor Advertisement is unlikely to contain the Target link-layer address option as there are no link-layer addresses on the 3GPP cellular link technology.
3GPPセルラーリンクテクノロジーにはリンク層アドレスはありません。したがって、アドレス解決とネクストホップの決定は必要ありません。セルラーホストが引き続きデフォルトのルーターなどのアドレス解決を試行する場合は、GGSN / PGWがアドレス解決の近隣要請に応答しないこともあることを理解する必要があります。また、3GPPセルラーリンクテクノロジにはリンク層アドレスがないため、近隣広告にターゲットリンク層アドレスオプションが含まれることはほとんどありません。
The cellular host must support Neighbor Unreachability Detection (NUD) as specified in [RFC4861]. Note that the link-layer address considerations above also apply to NUD. The NUD-triggered Neighbor Advertisement is also unlikely to contain the Target link-layer address option as there are no link-layer addresses. The cellular host should also be prepared for NUD initiated by a router (i.e., GGSN/PGW). However, it is unlikely a router-to-host NUD would ever take place on GPRS, UMTS, or EPS links. See Appendix A for more discussion on the router-to-host NUD.
セルラーホストは、[RFC4861]で指定されているネイバー到達不能検出（NUD）をサポートする必要があります。上記のリンク層アドレスの考慮事項は、NUDにも適用されることに注意してください。リンク層アドレスがないため、NUDでトリガーされたネイバーアドバタイズメントにもターゲットリンク層アドレスオプションが含まれる可能性は低いです。セルラーホストは、ルーター（つまり、GGSN / PGW）によって開始されるNUDに対しても準備する必要があります。ただし、ルーターからホストへのNUDがGPRS、UMTS、またはEPSリンクで発生することはほとんどありません。ルータからホストへのNUDの詳細については、付録Aを参照してください。
In 3GPP networks, it is desirable to reduce any additional periodic signaling. Therefore, the cellular host should include a mechanism in upper-layer protocols to provide reachability confirmations when two-way IP-layer reachability can be confirmed (see [RFC4861], Section 7.3.1). These confirmations would allow the suppression of NUD-related messages in most cases.
3GPPネットワークでは、追加の定期的なシグナリングを減らすことが望ましいです。したがって、セルラーホストは、双方向のIP層の到達可能性を確認できる場合に到達可能性を確認できるメカニズムを上位層プロトコルに含める必要があります（[RFC4861]、セクション7.3.1を参照）。これらの確認により、ほとんどの場合、NUD関連のメッセージを抑制できます。
Host TCP implementation should provide reachability confirmation in the manner explained in [RFC4861], Section 7.3.1.
ホストTCP実装は、[RFC4861]のセクション7.3.1で説明されている方法で到達可能性の確認を提供する必要があります。
The widespread use of UDP in 3GPP networks poses a problem for providing reachability confirmation. As UDP itself is unable to provide such confirmation, applications running on top of UDP should provide the confirmation where possible. In particular, when UDP is used for transporting DNS, the DNS response should be used as a basis for reachability confirmation. Similarly, when UDP is used to transport RTP [RFC3550], the RTP Control Protocol (RTCP) [RFC3550] 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上で実行されているアプリケーションは、可能な場合は確認を提供する必要があります。特に、DNSの転送にUDPが使用される場合、到達可能性の確認の基礎としてDNS応答を使用する必要があります。同様に、UDPを使用してRTP [RFC3550]を転送する場合、RTP制御プロトコル（RTCP）[RFC3550]フィードバックを到達可能性確認の基礎として使用する必要があります。いくつかのパケットが通過したことを示す受信レポートブロックを含むRTCPパケットが受信された場合、パケットはピアに到達しています。ピアに到達している場合は、ネイバーにも到達しています。
When UDP is used for transporting SIP [RFC3261], 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 [RFC3261]を転送する場合、SIP要求への応答は、ピアに送信されたパケットが到達することの確認として使用する必要があります。セルラーホストがサーバー側のSIPノードとして機能している場合、そのような確認は一般に利用できません。ただし、ホストは、SIP ACK要求の受信を、以前に送信されたSIP INVITE要求に対する応答がピアに到達したことの確認として解釈する場合があります。
IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. This specification is a mandatory part of IPv6 and also the only mandatory method to configure an IPv6 address in a 3GPP cellular host.
IPv6ステートレスアドレス自動設定は[RFC4862]で定義されています。この仕様はIPv6の必須の部分であり、3GPPセルラーホストでIPv6アドレスを構成するための唯一の必須の方法でもあります。
A cellular host in a 3GPP network must process a Router Advertisement as stated in [RFC4862]. The Router Advertisement contains a maximum of one prefix information option with lifetimes set to infinite (both valid and preferred lifetimes). The advertised prefix cannot ever be used for on-link determination (see [RFC6459], Section 5.2), and the lifetime of the advertised prefix is tied to the PDP Context/PDN Connection lifetime. Keeping the forward compatibility in mind, there is no reason for the 3GPP cellular host to have 3GPP-specific handling of the prefix information option(s) although 3GPP specifications state that the Router Advertisement may contain a maximum of one prefix information option and the lifetimes are set to infinite.
[RFC4862]で述べられているように、3GPPネットワークのセルラーホストはルーター通知を処理する必要があります。ルーターアドバタイズメントには、最大1つのプレフィックス情報オプションが含まれ、ライフタイムは無限に設定されます（有効なライフタイムと優先するライフタイムの両方）。アドバタイズされたプレフィックスは、オンリンクの決定には使用できず（[RFC6459]、セクション5.2を参照）、アドバタイズされたプレフィックスのライフタイムは、PDPコンテキスト/ PDN接続のライフタイムに関連付けられます。上位互換性を念頭に置いて、3GPPセルラーホストが3GPP固有のプレフィックス情報オプションを処理する理由はありませんが、3GPP仕様には、ルーターアドバタイズメントに最大1つのプレフィックス情報オプションとライフタイムが含まれる可能性があると記載されています無限に設定されています。
Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, as each assigned prefix is unique within its scope when advertised using 3GPP IPv6 Stateless Address Autoconfiguration. In addition, the default router (GGSN/PGW) will not configure any addresses on its interfaces based on prefixes advertised to IPv6 cellular hosts on those interfaces. Thus, the host is not required to perform Duplicate Address Detection on the cellular interface.
3GPP IPv6ステートレスアドレス自動構成を使用してアドバタイズされる場合、割り当てられた各プレフィックスはスコープ内で一意であるため、3GPPネットワークのホストはDupAddrDetectTransmitsをゼロに設定できます。さらに、デフォルトルーター（GGSN / PGW）は、それらのインターフェイスのIPv6セルラーホストにアドバタイズされたプレフィックスに基づいて、インターフェイスにアドレスを設定しません。したがって、ホストはセルラーインターフェイスで重複アドレス検出を実行する必要はありません。
Furthermore, the GGSN/PGW will provide the cellular host with an interface identifier that must be used for link-local address configuration. The link-local address configured from this interface identifier is guaranteed not to collide with the link-local address that the GGSN/PGW uses. Thus, the cellular host is not required to perform Duplicate Address Detection for the link-local address on the cellular interface.
さらに、GGSN / PGWは、リンクローカルアドレスの構成に使用する必要があるインターフェイス識別子をセルラーホストに提供します。このインターフェイス識別子から構成されたリンクローカルアドレスは、GGSN / PGWが使用するリンクローカルアドレスと衝突しないことが保証されています。したがって、セルラーホストは、セルラーインターフェイスでリンクローカルアドレスの重複アドレス検出を実行する必要はありません。
See Appendix A for more details on 3GPP IPv6 Stateless Address Autoconfiguration.
3GPP IPv6ステートレスアドレス自動構成の詳細については、付録Aを参照してください。
A cellular host in a 3GPP network that supports PPP [RFC1661] on the interface between the MT and the TE must support the IPv6 Control Protocol (IPV6CP) [RFC5072] 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, e.g., a USB dongle) 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/PGW, 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/PGW for its link-local address.
MTとTE間のインターフェイスでPPP [RFC1661]をサポートする3GPPネットワークのセルラーホストは、IPv6制御プロトコル（IPV6CP）[RFC5072]インターフェイス識別子オプションをサポートする必要があります。このオプションは、セルラーデバイス（MT、たとえば、USBドングル）と他のデバイス（TE、たとえば、ラップトップ）の間のPPPリンクを使用して他のデバイスをインターネットに接続できるようにするために必要です。 MTは、TEからの要求に基づいてPDPコンテキストのアクティブ化を実行します。これにより、IPV6CPオプションを使用して、MTからTEにインターフェイス識別子が提案されます。 TEとGGSN / PGWの間のリンクローカルアドレスの重複を回避するために、MTはTEによって提案された他のインターフェイス識別子を常に拒否する必要があります。その結果、TEは、GGSN / PGWによって提案されたインターフェイス識別子を常にリンクローカルアドレスに使用します。
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 [RFC4941] or similar technologies for unique local IPv6 unicast addresses [RFC4193] and global addresses is not affected by the above procedure.
3GPP仕様によれば、TEによって提案されたインターフェイス識別子の拒否は、リンクローカルアドレスの作成のためにのみ行われます。固有のローカルIPv6ユニキャストアドレス[RFC4193]およびグローバルアドレスに対するプライバシーアドレス[RFC4941]または同様のテクノロジーの使用は、上記の手順の影響を受けません。
Within 3GPP networks, hosts connect to their default routers (GGSN/PGW) 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 is not necessary, although sending them causes no harm or interoperability issues. Refer to Section 5.10 of [RFC6434] for MLD usage for multicast group knowledge that is not link-local.
3GPPネットワーク内では、ホストはポイントツーポイントリンク経由でデフォルトルーター（GGSN / PGW）に接続します。さらに、ポイントツーポイントリンクに接続されているIPデバイスは2つだけであり、マルチキャストトラフィックの転送を抑制する試みは（リンク層で）行われません。したがって、3GPP環境でリンクローカルアドレスのMLDレポートを送信する必要はありませんが、それらを送信しても害や相互運用性の問題は発生しません。リンクローカルではないマルチキャストグループナレッジのMLDの使用法については、[RFC6434]のセクション5.10を参照してください。
Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] or other similar technologies may be supported by a cellular host. Privacy, in general, is important for the Internet. In 3GPP networks, the lifetime of an address assignment depends on many factors such as radio coverage, device status, and user preferences. As a result, the prefix the cellular host uses is also subject to frequent changes.
ステートレスアドレス自動構成のプライバシー拡張[RFC4941]または他の同様のテクノロジが、セルラーホストでサポートされている場合があります。一般に、プライバシーはインターネットにとって重要です。 3GPPネットワークでは、アドレス割り当ての有効期間は、無線カバレッジ、デバイスステータス、ユーザー設定などの多くの要因に依存します。その結果、セルラーホストが使用するプレフィックスも頻繁に変更されます。
Refer to Section 6 for a discussion of the benefits of Privacy Extensions in a 3GPP network.
3GPPネットワークにおけるプライバシー拡張の利点については、セクション6を参照してください。
As of 3GPP Release-11, the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address autoconfiguration. IPv6 Stateless Address Autoconfiguration still remains the only mandatory address configuration method. However, DHCPv6 may be useful for other configuration needs on a cellular host, e.g., Stateless DHCPv6 [RFC3736] may be used to configure DNS and SIP server addresses, and DHCPv6 Prefix Delegation [RFC3633] may be used to delegate a prefix to the cellular host for use on its downstream non-cellular links.
3GPPリリース-11の時点では、IPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]は、アドレスの自動構成には必要もサポートもされていません。 IPv6ステートレスアドレス自動設定は、依然として唯一の必須アドレス設定方法です。ただし、DHCPv6はセルラーホストの他の構成ニーズに役立つ場合があります。たとえば、ステートレスDHCPv6 [RFC3736]を使用してDNSおよびSIPサーバーアドレスを構成し、DHCPv6プレフィックス委任[RFC3633]を使用してセルラーにプレフィックスを委任できます。ダウンストリームの非セルラーリンクで使用するためのホスト。
Starting from Release-10, DHCPv6 Prefix Delegation was added as an optional feature to the 3GPP system architecture [RFC3633]. The Prefix Delegation model defined for Release-10 requires that the /64 IPv6 prefix assigned to the cellular host on the 3GPP link must aggregate with the shorter delegated IPv6 prefix. The cellular host should implement the Prefix Exclude Option for DHCPv6 Prefix Delegation [RFC6603] (see [RFC6459], Section 5.3 for further discussion).
リリース10以降、DHCPv6プレフィックス委任がオプション機能として3GPPシステムアーキテクチャに追加されました[RFC3633]。リリース10で定義されたプレフィックス委任モデルでは、3GPPリンク上のセルラーホストに割り当てられた/ 64 IPv6プレフィックスが、より短い委任されたIPv6プレフィックスと集約される必要があります。セルラーホストは、DHCPv6プレフィックス委任のプレフィックス除外オプション[RFC6603]を実装する必要があります（詳細については、[RFC6459]、セクション5.3を参照してください）。
The cellular host should implement the Default Router Preferences and More-Specific Routes extension to Router Advertisement messages [RFC4191]. These options may be useful for cellular hosts that also have additional interfaces on which IPv6 is used.
セルラーホストは、ルーターアドバタイズメッセージ[RFC4191]のデフォルトルーター設定とより具体的なルート拡張を実装する必要があります。これらのオプションは、IPv6が使用される追加のインターフェイスも備えたセルラーホストに役立つ場合があります。
The DNS server configuration is learned from the 3GPP link-layer signaling. However, the cellular host should also implement the IPv6 Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6 is still optional for cellular hosts, and learning the DNS server addresses from the link-layer signaling can be cumbersome when the MT and the TE are separated using techniques other than the PPP interface.
DNSサーバー構成は、3GPPリンク層シグナリングから学習されます。ただし、セルラーホストは、DNS構成のIPv6ルーターアドバタイズメントオプションも実装する必要があります[RFC6106]。 DHCPv6は引き続きセルラーホストではオプションであり、PPPインターフェイス以外の手法を使用してMTとTEを分離すると、リンク層シグナリングからDNSサーバーアドレスを学習するのが面倒になる可能性があります。
The cellular host should also honor the MTU option in the Router Advertisement (see [RFC4861], Section 4.6.4). The 3GPP system architecture uses extensive tunneling in its packet core network below the 3GPP link, and this may lead to packet fragmentation issues. Therefore, the GGSN/PGW may propose to the cellular host an MTU that takes the additional tunneling overhead into account.
セルラーホストは、ルーターアドバタイズメントのMTUオプションも尊重する必要があります（[RFC4861]、セクション4.6.4を参照）。 3GPPシステムアーキテクチャは、3GPPリンクの下のパケットコアネットワークで広範なトンネリングを使用しているため、パケットの断片化の問題が発生する可能性があります。したがって、GGSN / PGWは、追加のトンネリングオーバーヘッドを考慮に入れたMTUをセルラーホストに提案します。
IPsec [RFC4301] is a fundamental, but not mandatory, part of IPv6. Refer to the IPv6 Node Requirements (Section 11 of [RFC6434]) for the security requirements that also apply to cellular hosts.
IPsec [RFC4301]はIPv6の基本ですが、必須ではありません。セルラーホストにも適用されるセキュリティ要件については、IPv6ノードの要件（[RFC6434]のセクション11）を参照してください。
Support for the Routing Header Type 0 (RH0) has been deprecated [RFC5095]. Therefore, the cellular host should by default follow the RH0 processing described in Section 3 of [RFC5095].
ルーティングヘッダータイプ0（RH0）のサポートは非推奨になりました[RFC5095]。したがって、セルラーホストはデフォルトで[RFC5095]のセクション3で説明されているRH0処理に従う必要があります。
IPv6 packet fragmentation has known security concerns. The cellular host must follow the handling of overlapping fragments as described in [RFC5722], and the cellular host must not fragment any Neighbor Discovery messages as described in [RFC6980].
IPv6パケットの断片化には、セキュリティ上の既知の問題があります。セルラーホストは、[RFC5722]で説明されているように、重複するフラグメントの処理に従う必要があり、セルラーホストは、[RFC6980]で説明されているように、近隣探索メッセージをフラグメント化してはなりません。
For the purposes of this document, IP mobility is not relevant. The movement of cellular hosts within 3GPP networks is handled by link-layer mechanisms in the majority of cases. 3GPP Release-8 introduced Dual-Stack Mobile IPv6 (DSMIPv6) for client-based mobility [RFC5555]. Client-based IP mobility is optional in the 3GPP architecture.
このドキュメントでは、IPモビリティは関係ありません。 3GPPネットワーク内のセルラーホストの移動は、ほとんどの場合、リンク層メカニズムによって処理されます。 3GPPリリース8では、クライアントベースのモビリティ[RFC5555]のためにデュアルスタックモバイルIPv6（DSMIPv6）が導入されました。 3GPPアーキテクチャでは、クライアントベースのIPモビリティはオプションです。
The authors would like to thank the original authors for their groundwork for this document: Gerben Kuijpers, John Loughney, Hesham Soliman, and Juha Wiljakka.
著者は、この文書の基礎知識を提供してくれた元の著者、Gerben Kuijpers、John Loughney、Hesham Soliman、Juha Wiljakkaに感謝します。
The original [RFC3316] document was 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.
元の[RFC3316]ドキュメントは、著者に加えてPeter HedmanとPertti Suomelaを含むチームの結果に基づいていました。 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 on 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.
また、このドキュメントの準備におけるコメントと入力について、David DeCamp、Karim El Malki、Markus Isomaki、Petter Johnsen、Janne Rinne、Jonne Soininen、Vlad Stirbu、Shabnam Sultanaに感謝します。
For this revised version of [RFC3316] the authors would like to thank Dave Thaler, Ales Vizdal, Gang Chen, Ray Hunter, Charlie Kaufman, Owen DeLong, and Alexey Melnikov for their comments, reviews, and input.
[RFC3316]のこの改訂版について、コメント、レビュー、および入力してくださったDave Thaler、Ales Vizdal、Gang Chen、Ray Hunter、Charlie Kaufman、Owen DeLong、およびAlexey Melnikovに感謝します。
This document does not specify any new protocols or functionalities, 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機能の特定のプロファイルが提案されており、含まれている機能と含まれていない機能に応じて、脆弱性が開閉する可能性があります。特定のタイプの脆弱性をより深刻にするセルラー環境の側面もあります。次の問題について説明します。
o The suggested limitations (Section 3.1) in the processing of extension headers also limits exposure to Denial-of-Service (DoS) attacks through cellular hosts.
o 拡張ヘッダーの処理で提案されている制限（3.1節）は、セルラーホストを介したサービス拒否（DoS）攻撃への露出も制限します。
o IPv6 addressing privacy [RFC4941] or similar technology may be used in cellular hosts. However, it should be noted that in the 3GPP model, the network would assign a new prefix, in most cases, to hosts in roaming situations; the network would also typically assign a new prefix when the cellular hosts activate a PDP Context or a PDN Connection. 3GPP devices must not use interface identifiers that are unique to the device, so the only difference in address between 3GPP devices using Stateless Address Autoconfiguration is in the prefix. 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/PGW's coverage area is expected to be very large when compared to currently deployed default routers (no handovers between GGSN/PGWs are possible), a cellular host can keep a prefix 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.
o IPv6アドレッシングプライバシー[RFC4941]または同様のテクノロジーが、セルラーホストで使用される場合があります。ただし、3GPPモデルでは、ネットワークは、ほとんどの場合、ローミング状況のホストに新しいプレフィックスを割り当てることに注意してください。また、ネットワークは通常、セルラーホストがPDPコンテキストまたはPDN接続をアクティブ化するときに、新しいプレフィックスを割り当てます。 3GPPデバイスは、デバイスに固有のインターフェイス識別子を使用しないでください。したがって、ステートレスアドレス自動構成を使用する3GPPデバイス間のアドレスの唯一の違いは、プレフィックスです。これは、3GPPネットワークがすでに限定された形式のアドレッシングプライバシーを提供することを意味し、そのアドレスを介して単一のホストのグローバルトラッキングは不可能です。一方、GGSN / PGWのカバレッジエリアは、現在デプロイされているデフォルトルータと比較すると非常に大きいと予想されるため（GGSN / PGW間のハンドオーバーは不可能）、セルラーホストはプレフィックスを長期間維持できます。したがって、IPv6アドレッシングプライバシーを使用して、ホストがオンで同じエリアにいる間、プライバシーを追加できます。プライバシー機能は、たとえば、異なるトランスポートセッションが異なるIPアドレスから送信されているように見せるために使用することもできます。ただし、これらの追加の取り組みは、ネットワークプレフィックス部分のみを監視できるため、潜在的なオブザーバーをさらに混乱させることは明らかではありません。
o The use and recommendations of various security services such as IPsec or Transport Layer Security (TLS) [RFC5246] in the connection of typical applications that also apply to cellular hosts are discussed in Section 11 of [RFC6434].
o セルラーホストにも適用される一般的なアプリケーションの接続におけるIPsecやトランスポート層セキュリティ（TLS）[RFC5246]などのさまざまなセキュリティサービスの使用と推奨事項は、[RFC6434]のセクション11で説明されています。
o 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 for further study. It is also often easy to fill the cellular link and queues on both sides with additional or large packets.
o セルラーホストが使用する通信時間は高価です。場合によっては、ユーザーは、ホストとの間で転送するデータ量に応じて課金されます。ネットワークとユーザーの両方にとって、通信時間が正しく使用され、サードパーティの誤動作によりユーザーに追加料金が適用されないことが重要です。セルラーリンクの容量も限られているため、マルチメディアコールなど、ユーザーが選択したトラフィックよりも多くのトラフィックに対応できるとは限りません。追加のトラフィックは、ユーザーが体験するサービスレベルに干渉する可能性があります。サービス品質メカニズムはこれらの問題をある程度緩和しますが、DoSの側面がセルラー環境で強調されることはまだ明らかです。たとえば、パケット増幅を使用する既存のDoS攻撃は、この環境でかなり大きな損害を与える可能性があります。これらの攻撃をどのように防御できるかについては、さらに調査する必要があります。多くの場合、セルラーリンクと両側のキューを追加または大きなパケットで埋めることも簡単です。
o 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.
o 一部のサービスプロバイダーネットワーク内では、個人識別情報を提示せずにプリペイドセルラーサブスクリプションを購入できます。未確認のままにしたい攻撃者は、これを利用することができます。ユーザーは識別されていませんが、機器はまだ識別されています。オペレーターはデバイスのIDを追跡し、今後の使用をブロックすることができます。オペレーターは、顧客のデバイスの使用に関するサードパーティの苦情を通知するための適切な手順を用意する必要があります。また、オペレーターがセルラーホストから起動された攻撃を効率的に検出できるようにする攻撃検出ツールが必要になる場合もあります。
o Cellular devices that have local network interfaces (such as WLAN 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.
o ローカルインターフェイスが適切な方法で保護されていない限り、ローカルネットワークインターフェイス（WLANやBluetoothなど）を備えたセルラーデバイスを使用して、それらを介して攻撃を開始できます。したがって、ローカルネットワークインターフェイスには、他の人がセルラーホストを仲介者として使用できないようにアクセス制御が必要です。
o The 3GPP link model mitigates most of the known IPv6 on-link and neighbor cache targeted attacks (see Section 2.2 and Appendix A).
o 3GPPリンクモデルは、既知のIPv6オンリンクおよびネイバーキャッシュターゲット攻撃のほとんどを軽減します（セクション2.2および付録Aを参照）。
o Advice for implementations in the face of Neighbor Discovery DoS attacks may be useful in some environments [RFC6583].
o 近隣探索DoS攻撃に直面した場合の実装に関するアドバイスは、一部の環境で役立つ場合があります[RFC6583]。
o Section 9 of [RFC6459] further discusses some recent concerns related to the security of cellular hosts.
o [RFC6459]のセクション9では、セルラーホストのセキュリティに関連する最近のいくつかの懸念についてさらに説明しています。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6におけるステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、2007年9月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、2007年12月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722] Krishnan、S。、「Handling of Overlapping IPv6 Fragments」、RFC 5722、2009年12月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、2011年12月。
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, August 2013.
[RFC6980] Gont、F。、「IPv6ネイバー探索によるIPv6フラグメンテーションのセキュリティ上の影響」、RFC 6980、2013年8月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003.
[RFC3316] Arkko、J.、Kuijpers、G.、Soliman、H.、Loughney、J.、and J. Wiljakka、 "Internet Protocol Version 6（IPv6）for some Second Generation and Third Generation Cellular Hosts"、RFC 3316、April 2003年
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R。、「IPv6用のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、2005年11月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072] Varada、S.、Haskins、D。、およびE. Allen、「IPバージョン6 over PPP」、RFC 5072、2007年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]ソリマンH.、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 6106、2010年11月。
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012.
[RFC6459] Korhonen、J.、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G。、およびK. Iisakkila、「IPv6 in the 3rd Generation Partnership Project（3GPP）Evolved Packet System（EPS）」 、RFC 6459、2012年1月。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6583] Gashinsky、I.、Jaeggli、J。、およびW. Kumari、「Operational Neighbor Discovery Problems」、RFC 6583、2012年3月。
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012.
[RFC6603] Korhonen、J.、Savolainen、T.、Krishnan、S。、およびO. Troan、「DHCPv6ベースのプレフィックス委任のプレフィックス除外オプション」、RFC 6603、2012年5月。
[TS.23060] 3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2", 3GPP TS 23.060 11.5.0, March 2013.
[TS.23060] 3GPP、「General Packet Radio Service（GPRS）; Service description; Stage 2」、3GPP TS 23.060 11.5.0、March 2013。
[TS.23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 11.5.0, March 2013.
[TS.23401] 3GPP、「進化したユニバーサル地上無線アクセスネットワーク（E-UTRAN）アクセスのための一般パケット無線サービス（GPRS）の拡張機能」、3GPP TS 23.401 11.5.0、2013年3月。
[TS.23402] 3GPP, "Architectural enhancements for non-3GPP accesses", 3GPP TS 23.402 11.6.0, March 2013.
[TS.23402] 3GPP、「非3GPPアクセスのアーキテクチャの強化」、3GPP TS 23.402 11.6.0、2013年3月。
[TS.29061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)", 3GPP TS 29.061 11.4.0, March 2013.
[TS.29061] 3GPP、「パケットベースのサービスをサポートする公衆陸上移動網（PLMN）とパケットデータネットワーク（PDN）の間のインターワーキング」、3GPP TS 29.061 11.4.0、2013年3月。
This appendix aims to very briefly describe the 3GPP IPv6 addressing model for 2G (GPRS), 3G (UMTS), and 4G (EPS) cellular networks from Release-99 onwards. More information for 2G and 3G can be found in 3GPP Technical Specifications [TS.23060] and [TS.29061]. The equivalent documentation for 4G can be found in 3GPP Technical Specifications [TS.23401], [TS.23402], and [TS.29061].
この付録では、リリース99以降の2G（GPRS）、3G（UMTS）、および4G（EPS）セルラーネットワークの3GPP IPv6アドレッシングモデルについて簡単に説明します。 2Gおよび3Gの詳細については、3GPP技術仕様[TS.23060]および[TS.29061]を参照してください。 4Gの同等のドキュメントは、3GPP技術仕様[TS.23401]、[TS.23402]、および[TS.29061]にあります。
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 Address Autoconfiguration procedure does not need any external entity involved in the address autoconfiguration (apart from the GGSN/PGW). At the time of writing this document, the IPv6 Stateless Address Autoconfiguration mechanism is still the only mandatory and supported address configuration method for the cellular 3GPP link.
IPv6ノードにアドレスを割り当てる方法には、ステートレスおよびステートフル自動構成の2つがあります。ステートフルアドレス割り当てメカニズムでは、IPv6ノードにアドレスを割り当てるためにDHCPサーバーが必要です。一方、ステートレスアドレス自動構成手順では、（GGSN / PGWを除いて）アドレス自動構成に関与する外部エンティティは必要ありません。このドキュメントの執筆時点では、IPv6ステートレスアドレス自動構成メカニズムは、セルラー3GPPリンクの唯一の必須でサポートされているアドレス構成方法です。
In order to support the standard IPv6 Stateless Address Autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW shall assign a single /64 IPv6 prefix that is unique within its scope to each primary PDP Context or PDN Connection that uses IPv6 Stateless Address Autoconfiguration. This avoids the necessity to perform Duplicate Address Detection (DAD) at the network level for any address built by the mobile host. The GGSN/PGW always provides an interface identifier to the mobile host. The mobile host uses the interface identifier provided by the GGSN/PGW to generate its link-local address. The GGSN/PGW provides the cellular host with the interface identifier, usually in a random manner. It must ensure the uniqueness of such an identifier on the link (i.e., no collisions between its own link-local address and the cellular host's).
IETFが推奨する標準のIPv6ステートレスアドレス自動構成メカニズムをサポートするために、GGSN / PGWは、スコープ内で一意の/ 64 IPv6プレフィックスを、IPv6ステートレスアドレス自動構成を使用する各プライマリPDPコンテキストまたはPDN接続に割り当てます。これにより、モバイルホストによって構築されたアドレスに対してネットワークレベルで重複アドレス検出（DAD）を実行する必要がなくなります。 GGSN / PGWは常にモバイルホストにインターフェイス識別子を提供します。モバイルホストは、GGSN / PGWによって提供されるインターフェイス識別子を使用して、リンクローカルアドレスを生成します。 GGSN / PGWは、通常はランダムな方法で、セルラーホストにインターフェイス識別子を提供します。リンク上のそのような識別子の一意性を保証する必要があります（つまり、自身のリンクローカルアドレスとセルラーホストの衝突がないこと）。
In addition, the GGSN/PGW 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 or PDN Connection is allocated a unique prefix, will eliminate the need for DAD messages over the air interface and consequently reduces inefficient use of radio resources. Furthermore, the allocation of a prefix to each PDP Context or PDN Connection will allow hosts to implement the Privacy Extensions in [RFC4941] without the need for further DAD messages.
さらに、GGSN / PGWは、セルラーホストに割り当てられたプレフィックスを使用して、独自のアドレスを生成しません。このインターフェイス識別子の使用は、各PDPコンテキストまたはPDN接続に一意のプレフィックスが割り当てられるという事実と相まって、エアインターフェイスを介したDADメッセージの必要性を排除し、その結果、無線リソースの非効率的な使用を減らします。さらに、各PDPコンテキストまたはPDN接続へのプレフィックスの割り当てにより、ホストは[RFC4941]でプライバシー拡張を実装することができ、追加のDADメッセージは必要ありません。
In practice, the GGSN/PGW only needs to route all traffic destined to the cellular host that falls under the prefix assigned to it. This implies the GGSN/PGW may implement a minimal Neighbor Discovery protocol subset since, due to the point-to-point link model and the absence of link-layer addressing, the address resolution can be entirely statically configured per PDP Context or PDN Connection, and there is no need to defend any addresses other than the link-local addresses for very unlikely duplicates. This also has an additional effect on a router-to-host NUD. There is really no need for the NUD, since from the point of view of GGSN/PGW, GGSN/PGW does not need to care for a single address but just routes the whole prefix to the cellular host. However, the cellular host must be prepared for the unlikely event of receiving a NUD against its link-local address. It should be noted that the 3GPP specifications at the time of writing this document are silent about what should happen if the router-to-host NUD fails.
実際には、GGSN / PGWは、割り当てられたプレフィックスに該当するセルラーホスト宛てのすべてのトラフィックをルーティングするだけで済みます。これは、GGSN / PGWが最小限の近隣探索プロトコルサブセットを実装する可能性があることを意味します。これは、ポイントツーポイントリンクモデルとリンク層アドレス指定がないため、PDPコンテキストまたはPDN接続ごとにアドレス解決を完全に静的に構成できるためです。また、リンクローカルアドレス以外の重複を防ぐために、アドレスを防御する必要はありません。これは、ルーターからホストへのNUDにも追加の影響があります。 GGSN / PGWの観点からは、GGSN / PGWは単一のアドレスを処理する必要はなく、プレフィックス全体をセルラーホストにルーティングするだけなので、NUDは実際には必要ありません。ただし、セルラーホストは、リンクローカルアドレスに対してNUDを受信するという万が一の事態に備える必要があります。このドキュメントを書いている時点での3GPP仕様は、ルーターからホストへのNUDが失敗した場合にどうなるかについては触れていません。
See Section 5 of [RFC6459] for further discussion on 3GPP address allocation and the 3GPP link model.
3GPPアドレスの割り当てと3GPPリンクモデルの詳細については、[RFC6459]のセクション5をご覧ください。
o Clarified that [RFC4941] or similar technologies may be used for privacy purposes (as stated in [RFC6459]).
o [RFC4941]または同様のテクノロジーがプライバシーの目的で使用される可能性があることを明記（[RFC6459]に記載）。
o Clarified that MLD for link-local addresses is not necessary, but doing it causes no harm (instead of saying it may not be needed in some cases).
o リンクローカルアドレスのMLDは必要ないことを明記しましたが、MLDを実行しても害はありません（場合によっては必要ないかもしれないと言う代わりに）。
o Clarified that a cellular host should not do any changes in its stack to meet the 3GPP link restriction on the Router Advertisement Prefix Information Options (PIOs).
o セルラーホストは、ルーターアドバタイズメントプレフィックス情報オプション（PIO）の3GPPリンク制限を満たすために、スタックで変更を行わないでください。
o Clarified that a cellular host should not do any changes in its stack to meet the infinite prefix lifetime requirement the 3GPP link has.
o 3GPPリンクが持つ無限のプレフィックスライフタイム要件を満たすために、セルラーホストはスタックで変更を行うべきではないことを明確にしました。
o Clarified that the prefix lifetime is tied to the PDP Context/PDN Connection lifetime.
o プレフィックスの有効期間がPDPコンテキスト/ PDN接続の有効期間に関連付けられていることを明確にしました。
o Clarified explicitly that a NUD from the gateway side to the User Equipment's link-local address is possible.
o ゲートウェイ側からユーザー機器のリンクローカルアドレスへのNUDが可能であることを明示的に明確化。
o Added references to 3GPP specifications.
o 3GPP仕様への参照を追加しました。
o Provided additional clarification on NUD on 3GPP cellular links.
o 3GPPセルラーリンクのNUDに関する追加の説明を提供しました。
o Added an explicit note that the prefix on the link is /64.
o リンクのプレフィックスが/ 64であるという明確な注記を追加しました。
o Clarified that DHCPv6 ([RFC3315]) is not used at all for address autoconfiguration.
o DHCPv6（[RFC3315]）がアドレスの自動構成にまったく使用されないことを明確にしました。
o Removed all sections that can be directly found in [RFC6434].
o [RFC6434]に直接あるすべてのセクションを削除しました。
o Added clarifications to 3GPP link model and how Neighbor Discovery works on it.
o 3GPPリンクモデルと、近隣探索がどのように機能するかについての説明が追加されました。
o Added [RFC4191] recommendations.
o [RFC4191]の推奨事項を追加しました。
o Added DHCPv6-based Prefix Delegation recommendations.
o DHCPv6ベースのプレフィックス委任に関する推奨事項を追加しました。
o Added [RFC6106] recommendations.
o [RFC6106]の推奨事項を追加しました。
o Added reference to [RFC5555] regarding client-based mobility.
o クライアントベースのモビリティに関する[RFC5555]への参照を追加しました。
o Added text regarding Router Advertisement MTU option handling.
o ルーターアドバタイズMTUオプションの処理に関するテキストを追加しました。
o Added Evolved Packet System text.
o Evolved Packet Systemのテキストを追加しました。
o Added clarification on the primary 3GPP IPv6 transition mechanism.
o プライマリ3GPP IPv6移行メカニズムに関する説明が追加されました。
o Added reference to [RFC5095], which deprecates the RH0.
o RH0を廃止する[RFC5095]への参照を追加しました。
o Added references to [RFC5722] and [RFC6980] regarding IPv6 fragmentation handling.
o IPv6フラグメンテーション処理に関する[RFC5722]および[RFC6980]への参照を追加しました。
o Added reference to [RFC6583] for Neighbor Discovery denial-of-service attack considerations.
o Neighbor Discoveryのサービス拒否攻撃に関する考慮事項について、[RFC6583]への参照を追加しました。
o Made the PPP IPV6CP [RFC5072] support text conditional.
o PPP IPV6CP [RFC5072]サポートテキストを条件付きにしました。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Broadcom Porkkalankatu 24 FIN-00180 Helsinki Finland
Jouni Korhonen（編集者）Broadcom Porkkalankatu 24 FIN-00180ヘルシンキフィンランド
EMail: jouni.nospam@gmail.com
Jari Arkko (editor) Ericsson Jorvas 02420 Finland
発行されたロック（編集者）エリクソンジャーバス024フィンランド
EMail: jari.arkko@piuha.net
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720タンペレフィンランド
EMail: teemu.savolainen@nokia.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.マウントロイヤルの町、QCカナダ
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com