[要約] 要約： RFC 6653は、LTEネットワークでのDHCPv6プレフィックスデリゲーションに関する標準化ドキュメントです。このRFCの目的は、LTEネットワークでのIPv6プレフィックスの効率的な配布を可能にするためのガイドラインを提供することです。目的： 1. LTEネットワークでのDHCPv6プレフィックスデリゲーションの標準化。 2. IPv6プレフィックスの効率的な配布を実現するためのガイドラインの提供。 3. LTEネットワークにおけるIPv6ネットワーキングの改善。
Independent Submission B. Sarikaya
Request for Comments: 6653 F. Xia
Category: Informational Huawei USA
ISSN: 2070-1721 T. Lemon
Nominum
July 2012
DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks
長期進化（LTE）ネットワークでのDHCPv6プレフィックス委任
Abstract
概要
As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers.
セルラーネットワークでのIPv6展開への関心が高まるにつれ、いくつかの移行の問題が発生しています。 IPv6プレフィックス管理は、このドキュメントで扱われる問題です。 DHCPv6サーバーはプレフィックスを管理できるという考えに基づいて、DHCPv6プレフィックス委任を使用して、プレフィックスの委任をオフロードするアクセスルーターやDHCPv6サーバーへのタスクの解放などのプレフィックス管理の問題に対処します。アクセスルータは最初に、着信モバイルノードのプレフィックスをDHCPv6サーバーに要求します。次に、アクセスルーターは、例えばルーター通知を使用して、またはDHCPを使用して、モバイルノードへのステートレスまたはステートフルアドレス割り当てを実行します。また、認証、承認、およびアカウンティング（AAA）サーバーを使用したプレフィックス管理についても説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6653.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6653で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology and Acronyms ........................................4
3. Prefix Delegation Using DHCPv6 ..................................5
3.1. Prefix Request Procedure for Stateless Address
Configuration ..............................................5
3.2. Prefix Request Procedure for Stateful Address
Configuration ..............................................7
3.3. The MN as Requesting Router in Prefix Delegation ...........8
3.4. Prefix Release Procedure ...................................9
3.5. Miscellaneous Considerations ...............................9
3.5.1. How to Generate an IAID .............................9
3.5.2. Policy to Delegate Prefixes ........................10
4. Prefix Delegation Using RADIUS and Diameter ....................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................12
7. Informative References .........................................12
Figure 1 illustrates the key elements of a typical cellular access network. In a Long-Term Evolution (LTE) network, the Access Router (AR) is the Packet Data Network (PDN) Gateway [3GPP-23401].
図1は、一般的なセルラーアクセスネットワークの主要な要素を示しています。 Long-Term Evolution（LTE）ネットワークでは、アクセスルーター（AR）はパケットデータネットワーク（PDN）ゲートウェイです[3GPP-23401]。
+-------------+
| +------+ |
| |DHCP | |
+-----+ +-----+ +------+ +------+ | |Server| | +------+
| MN |--| BS |--+Access+--+Access+-+ +------+ +-+Border|
+-----+ +-----+ | GW | |Router| |IP Network(s)| |Router+-Internet
+--+---+ +--+---+ | | +------+
| | +-------------+
+-----+ +-----+ | | +------+
| MN |--| BS |-----+ | |AAA |
+-----+ +-----+ +--- |Server|
+------+
Figure 1: Key Elements of a Typical Cellular Network
図1：一般的なセルラーネットワークの主要な要素
The Mobile Node (MN) attaches to a Base Station (BS) through an LTE air interface. A BS manages connectivity of User Equipment (UE) and extends connections to an Access Gateway (GW), e.g., the Serving Gateway (S-GW) in an LTE network. The access GW and the AR are connected via an IP network. The AR is the first-hop router of the MNs and is in charge of address/prefix management.
モバイルノード（MN）は、LTEエアインターフェースを介してベースステーション（BS）に接続します。 BSはユーザー機器（UE）の接続を管理し、アクセスゲートウェイ（GW）、たとえばLTEネットワークのサービングゲートウェイ（S-GW）への接続を拡張します。アクセスＧＷとＡＲは、ＩＰネットワークを介して接続されている。 ARはMNのファーストホップルータであり、アドレス/プレフィックス管理を担当します。
The AR is connected to an IP network that is owned by the operator; this network is connected to the public Internet via a border router. The network contains servers for subscriber management, including Quality of Service, billing, and accounting, as well as a Dynamic Host Configuration Protocol (DHCP) server [RFC6342].
ARは、オペレーターが所有するIPネットワークに接続されています。このネットワークは、境界ルーターを介して公衆インターネットに接続されています。ネットワークには、Quality of Service、課金、アカウンティングなどの加入者管理用のサーバーと、動的ホスト構成プロトコル（DHCP）サーバー[RFC6342]が含まれています。
With IPv6 addressing, because mobile network links are point-to-point (P2P), the per-MN interface prefix model is used [RFC3314] [RFC3316]. In the per-MN interface prefix model, prefix management is an issue.
IPv6アドレッシングでは、モバイルネットワークリンクがポイントツーポイント（P2P）であるため、MNごとのインターフェイスプレフィックスモデルが使用されます[RFC3314] [RFC3316]。 MNごとのインターフェイスプレフィックスモデルでは、プレフィックス管理が問題になります。
When an MN attaches to an AR, the AR requests one or more prefixes for the MN. When the MN detaches from the AR, the prefixes should be released. When the MN becomes idle, the AR should keep (i.e., not release) the allocated prefixes.
MNがARに接続すると、ARはMNに1つ以上のプレフィックスを要求します。 MNがARから切り離されると、プレフィックスが解放されます。 MNがアイドルになると、ARは割り当てられたプレフィックスを保持する（つまり、解放しない）必要があります。
This document describes how to use DHCPv6 Prefix Delegation (DHCPv6-PD) in mobile networks, such as networks based on standards developed by the 3rd Generation Partnership Project (3GPP) and it could easily be adopted by the Worldwide Interoperability for Microwave Access (WiMAX) Forum as well. In view of migration to IPv6, the number of MNs connected to the network at a given time may become very high. Traditional techniques such as prefix pools are not scalable. In such cases, DHCPv6-PD becomes the viable approach to take.
このドキュメントでは、第3世代パートナーシッププロジェクト（3GPP）によって開発された標準に基づくネットワークなどのモバイルネットワークでDHCPv6プレフィックスデリゲーション（DHCPv6-PD）を使用する方法について説明し、マイクロ波アクセス（WiMAX）の世界的な相互運用性によって簡単に採用できます。フォーラムも。 IPv6への移行を考慮すると、特定の時間にネットワークに接続されているMNの数が非常に多くなる可能性があります。プレフィックスプールなどの従来の技術はスケーラブルではありません。このような場合、DHCPv6-PDが実行可能なアプローチになります。
The techniques described in this document have not been approved by the IETF or the 3GPP, except for those techniques described below in Section 3.3. This document is not a Standard or Best Current Practice. This document is published only for possible consideration by operators.
このドキュメントで説明する手法は、以下のセクション3.3で説明する手法を除き、IETFまたは3GPPによって承認されていません。このドキュメントは、標準または現在のベストプラクティスではありません。このドキュメントは、オペレーターが検討する可能性がある場合にのみ公開されます。
This document is useful when address space needs to be managed by DHCPv6-PD. There are obviously other means of managing address space, including having the AR track internally what address space is used by what mobile.
このドキュメントは、アドレス空間をDHCPv6-PDで管理する必要がある場合に役立ちます。アドレススペースを管理する他の方法が明らかにあります。たとえば、どのモバイルでどのアドレススペースが使用されているかをARで追跡するなどです。
3GPP - 3rd Generation Partnership Project
3GPP-3rd Generation Partnership Project
AAA - Authentication, Authorization, and Accounting
AAA-認証、承認、およびアカウンティング
AR - Access Router
AR-アクセスルーター
BS - Base Station
BS-ベースステーション
DHCP - Dynamic Host Configuration Protocol
DHCP-動的ホスト構成プロトコル
E-UTRAN - Evolved Universal Terrestrial Radio Access Network
E-UTRAN-進化したユニバーサル地上無線アクセスネットワーク
GPRS - General Packet Radio Service
GPRS-一般パケット無線サービス
LTE - Long-Term Evolution
LTE-長期的な進化
MN - Mobile Node
誰-モービルヌード
P2P - Point-to-Point
P2P-ポイントツーポイント
PD - Prefix Delegation
PD-プレフィックス委任
PDN - Packet Data Network
PDN-パケットデータネットワーク
S-GW - Serving Gateway
S-GW-サービングゲートウェイ
WiMAX - Worldwide Interoperability for Microwave Access
WiMAX-マイクロ波アクセスの世界的な相互運用性
"Access router" refers to the cellular network entity that has a DHCP client. According to [3GPP-23401], the DHCP client is located in the PDN Gateway, and so the AR is the PDN Gateway in the LTE architecture.
「アクセスルーター」とは、DHCPクライアントを持つセルラーネットワークエンティティを指します。 [3GPP-23401]によれば、DHCPクライアントはPDNゲートウェイにあるため、ARはLTEアーキテクチャのPDNゲートウェイです。
There are two function modules in the AR: the DHCP client and the DHCP relay. DHCP messages should be relayed if the AR and a DHCP server are not directly connected; otherwise, the DHCP relay function in the AR is not necessary. Figure 2 illustrates a scenario in which the AR and the DHCP server aren't directly connected:
ARには、DHCPクライアントとDHCPリレーの2つの汎用モジュールがあります。 ARとDHCPサーバーが直接接続されていない場合は、DHCPメッセージをリレーする必要があります。それ以外の場合、ARのDHCPリレー機能は必要ありません。図2は、ARとDHCPサーバーが直接接続されていないシナリオを示しています。
+-------+ +----------------------+ +-----------+
| MN | | AR | |DHCP Server|
+-------+ |DHCP | Relay | +-----------+
| |Client | Agent | |
| +----------------------+ |
|1 Initial NW entry | |
|or attach procedure| |
|<----------------->| |
| |2 Solicit |
| |---------> Relay-forward |
| | --------------->|
| | 3 Relay-reply |
| |Advertise <---------------|
| |<-------- |
| |4 Request |
| |---------> Relay-forward |
| | --------------->|
| | 5 Relay-reply |
| |Reply <---------------|
| |<-------- |
|6 Attach | |
| Completed | |
|<----------------->| |
|7 Router | |
| Solicitation | |
|------------------>| |
| 8 Router | |
| Advertisement | |
|<------------------| |
Figure 2: Prefix Request
図2：プレフィックス要求
1. An MN (also referred to as UE, or User Equipment, by the 3GPP) performs initial network entry and authentication procedures, a.k.a. the attach procedure.
1. MN（3GPPではUEまたはユーザー機器とも呼ばれます）は、接続手順とも呼ばれる初期ネットワークエントリおよび認証手順を実行します。
2. On successful completion of Step 1, the AR initiates the DHCP Solicit procedure to request prefixes for the MN. The DHCP client in the AR creates and transmits a Solicit message as described in Sections 17.1.1 ("Creation of Solicit Messages") and 17.1.2 ("Transmission of Solicit Messages") of [RFC3315]. The DHCP client in an AR that supports DHCPv6 Prefix Delegation [RFC3633] creates an Identity Association for Prefix Delegation (IA_PD) and assigns it an Identity Association IDentifier (IAID). The client must include the IA_PD option in the Solicit message. The DHCP client as Requesting Router (RR) must set the prefix-length field to a value less than, e.g., 48 or equal to 64 to request a /64 prefix. Next, the relay agent in the AR sends to the DHCP server a Relay-forward message in which a Solicit message is encapsulated.
2. ステップ1が正常に完了すると、ARはDHCP要請手順を開始して、MNのプレフィックスを要求します。 ARのDHCPクライアントは、[RFC3315]のセクション17.1.1（「要請メッセージの作成」）および17.1.2（「要請メッセージの送信」）で説明されているように要請メッセージを作成して送信します。 DHCPv6プレフィックス委任をサポートするARのDHCPクライアント[RFC3633]は、プレフィックス委任のIDアソシエーション（IA_PD）を作成し、それにIDアソシエーションIDentifier（IAID）を割り当てます。クライアントは、要請メッセージにIA_PDオプションを含める必要があります。 / 64接頭辞を要求するには、要求元ルーター（RR）としてのDHCPクライアントは、接頭辞長フィールドを、たとえば48以下の値に設定して64にする必要があります。次に、AR内のリレーエージェントがDHCPサーバーに、Solicitメッセージがカプセル化されたリレー転送メッセージを送信します。
3. The DHCP server sends an Advertise message to the AR in the same way as that described in Section 17.2.2 ("Creation and Transmission of Advertise Messages") of [RFC3315]. An Advertise message with the IA_PD shows that the DHCP server is capable of delegating prefixes. This message is received encapsulated in a Relay-reply message by the relay agent in the AR and is sent as an Advertise message to the DHCP client in the AR.
3. DHCPサーバーは、[RFC3315]のセクション17.2.2（「アドバタイズメッセージの作成と送信」）で説明されているのと同じ方法で、アドバタイズメッセージをARに送信します。 IA_PDを含むアドバタイズメッセージは、DHCPサーバーがプレフィックスを委任できることを示しています。このメッセージは、ARのリレーエージェントによってリレー応答メッセージにカプセル化されて受信され、ARのDHCPクライアントにアドバタイズメッセージとして送信されます。
4. The AR (DHCP client and relay agent) uses the same message exchanges as those described in Section 18 ("DHCP Client-Initiated Configuration Exchange") of [RFC3315] and in [RFC3633] to obtain or update prefixes from the DHCP server. The AR (DHCP client and relay agent) and the DHCP server use the IA_PD Prefix option to exchange information about prefixes in much the same way as IA Address options are used for assigned addresses. This is accomplished by the AR sending a DHCP Request message and the DHCP server sending a DHCP Reply message.
4. AR（DHCPクライアントおよびリレーエージェント）は、[RFC3315]のセクション18（「DHCPクライアントが開始する構成交換」）および[RFC3633]で説明されているものと同じメッセージ交換を使用して、DHCPサーバーからプレフィックスを取得または更新します。 AR（DHCPクライアントおよびリレーエージェント）およびDHCPサーバーは、IA_PDプレフィックスオプションを使用して、割り当てられたアドレスに対してIAアドレスオプションが使用されるのとほぼ同じ方法で、プレフィックスに関する情報を交換します。これは、ARがDHCP要求メッセージを送信し、DHCPサーバーがDHCP応答メッセージを送信することで実現されます。
5. The AR stores the prefix information it received in the Reply message.
5. ARは、受信したプレフィックス情報を応答メッセージに格納します。
6. A connection between the MN and AR is established, and the link becomes active. This step completes the Packet Data Protocol (PDP) Context Activation Procedure in Universal Mobile Telecommunications System (UMTS) and PDN connection establishment in LTE networks.
6. MNとAR間の接続が確立され、リンクがアクティブになります。この手順により、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）でのパケットデータプロトコル（PDP）コンテキストのアクティブ化手順と、LTEネットワークでのPDN接続の確立が完了します。
7. The MN may send a Router Solicitation message to solicit the AR to send a Router Advertisement (RA) message.
7. ＭＮは、ルータ要請メッセージを送信して、ＡＲにルータ広告（ＲＡ）メッセージを送信するように要請することができる。
8. The AR advertises the prefixes received in the IA_PD option to the MN via an RA once the PDP Context/PDN connection is established, or in response to a Router Solicitation message sent from the MN.
8. PDPコンテキスト/ PDN接続が確立されると、またはMNから送信されたルーター要請メッセージに応じて、ARはIA_PDオプションで受信したプレフィックスをRA経由でMNにアドバタイズします。
The 4-way exchange between the AR as RR and the DHCP server as Delegating Router (DR), as shown in Figure 2, may be reduced to a two-message exchange by using the Rapid Commit option [RFC3315]. The DHCP client in the AR acting as RR includes a Rapid Commit option in the Solicit message. The DR then sends a Reply message containing one or more prefixes.
図2に示すように、RRとしてのARと委任ルーター（DR）としてのDHCPサーバー間の4ウェイ交換は、Rapid Commitオプション[RFC3315]を使用することにより、2メッセージ交換に削減できます。 RRとして機能するARのDHCPクライアントには、要請メッセージにRapid Commitオプションが含まれています。次に、DRは1つ以上のプレフィックスを含む応答メッセージを送信します。
Stateful address configuration requires a different architecture than that shown in Figure 2; in this type of configuration, there are two function modules in the AR: the DHCP server and the DHCP client.
ステートフルアドレス構成には、図2に示すものとは異なるアーキテクチャが必要です。このタイプの構成では、ARにDHCPサーバーとDHCPクライアントの2つの機能モジュールがあります。
After the initial attach is completed, a connection to the AR is established for the MN. The DHCP client function at the AR as RR and the DHCP server as DR follow Steps 2 through 5 of the procedure shown in Figure 2 to get the new prefix for this interface of the MN from the IA_PD option exchange defined in [RFC3633].
最初の接続が完了すると、MNに対してARへの接続が確立されます。 ARでのRRとしてのDHCPクライアント機能とDRとしてのDHCPサーバーは、図2に示す手順のステップ2〜5に従って、[RFC3633]で定義されているIA_PDオプション交換から、MNのこのインターフェイスの新しいプレフィックスを取得します。
The DHCPv6 client at the MN sends the DHCP Request to the AR. The DHCP server function at the AR must use the IA_PD option received in the DHCPv6-PD exchange to assign an address to the MN. The IA_PD option must contain the prefix. The AR sends to the MN a DHCP Reply message containing the IA address option (IAADDR). Figure 3 shows the message sequence.
MNのDHCPv6クライアントはDHCP要求をARに送信します。 ARのDHCPサーバー機能は、DHCPv6-PD交換で受信したIA_PDオプションを使用して、MNにアドレスを割り当てる必要があります。 IA_PDオプションには、プレフィックスを含める必要があります。 ARは、IAアドレスオプション（IAADDR）を含むDHCP応答メッセージをMNに送信します。図3は、メッセージシーケンスを示しています。
The MN configures its interface with the address assigned by the DHCP server in the DHCP Reply message.
MNは、DHCP応答メッセージでDHCPサーバーによって割り当てられたアドレスを使用して、そのインターフェースを構成します。
In Figure 3, the AR may be the home gateway of a fixed network to which the MN gets connected during the MN's handover.
図3では、ARは、MNのハンドオーバー中にMNが接続される固定ネットワークのホームゲートウェイである場合があります。
+----------+ +--------------+ +-----------+
| MN | | AR | |DHCP Server|
| |DHCP | | DHCP |DHCP | +-----------+
| |Client| |Server|Client |
+----------+ +--------------+
| Initial NW entry | |
|or attach procedure | |
|<-----------------> | |
| | DHCPv6-PD exchange |
| | similar to Steps 2-5 |
| Solicit | of Figure 2 (IA_PD) |
|---------------------->| |
| Advertise | |
|<----------------------| |
| Request | |
|---------------------->| |
| | |
| | |
| | Use prefix in IA_PD |
| Reply | to assign IAADDR |
|<--------------------- | |
Figure 3: Stateful Address Configuration Following PD
図3：PD後のステートフルアドレス構成
The AR may use a DHCPv6 Prefix Delegation exchange to get a delegated prefix shorter than /64 by setting the prefix-length field to a value less than 64, e.g., 56 to get a /56 prefix. Each newly attaching MN first goes through the steps in Figure 2, in which the AR requests a shorter prefix to establish a default connection with the MN.
ARは、DHCPv6プレフィックス委任交換を使用して、prefix-lengthフィールドを64未満の値に設定することにより、/ 64より短い委任されたプレフィックスを取得できます。たとえば、56で/ 56プレフィックスを取得します。新しく接続する各MNは、最初に図2の手順を実行します。この手順では、ARはMNとのデフォルト接続を確立するために短いプレフィックスを要求します。
The MN may next request additional prefixes (/64 or shorter) from the AR using DHCPv6 Prefix Delegation, where the MN is the RR and the AR is the DR (see [RFC6459] and Section 5.3.1.2.6 of [3GPP-23401]). In this case, the call flow is similar to that shown in Figure 3. The Solicit message must include the IA_PD option with the prefix-length field set to 64. The MN may request more than one /64 prefix. The AR as DR must delegate these prefixes, excluding the prefix assigned to the default connection.
次に、MNはDHCPv6 Prefix Delegationを使用してARに追加のプレフィックス（/ 64以下）を要求できます。MNはRR、ARはDRです（[RFC6459]および[3GPP-23401のセクション5.3.1.2.6を参照してください。 ]）。この場合、コールフローは図3に示すものと同様です。要請メッセージには、プレフィックス長フィールドを64に設定したIA_PDオプションを含める必要があります。MNは、複数の/ 64プレフィックスを要求する場合があります。 DRとしてのARは、デフォルトの接続に割り当てられたプレフィックスを除いて、これらのプレフィックスを委任する必要があります。
Prefixes can be released in two ways: via prefix aging, or via the DHCP release procedure. In prefix aging, a prefix should not be used by an MN when the prefix ages, and the DHCP server can delegate it to another MN. A prefix lifetime is delivered from the DHCPv6 server to the MN via the DHCP IA_PD Prefix option [RFC3633] and the RA Prefix Information option [RFC4861]. Figure 4 illustrates how the AR releases prefixes to a DHCP server that isn't directly connected to the AR:
プレフィックスは、プレフィックスエージングによる方法とDHCPリリース手順による方法の2つの方法で解放できます。プレフィックスエージングでは、プレフィックスがエージングするときにMNがプレフィックスを使用しないでください。DHCPサーバーは、プレフィックスを別のMNに委任できます。プレフィックスライフタイムは、DHCP IA_PDプレフィックスオプション[RFC3633]およびRAプレフィックス情報オプション[RFC4861]を介してDHCPv6サーバーからMNに配信されます。図4は、ARに直接接続されていないDHCPサーバーにプレフィックスを解放する方法を示しています。
1. A signal that an MN has detached, such as switch-off or handover, triggers the prefix release procedure.
1. スイッチオフやハンドオーバーなど、MNがデタッチした信号は、プレフィックス解放手順をトリガーします。
2. The AR initiates a Release message to give the prefixes back to the DHCP server.
2. ARはリリースメッセージを開始して、プレフィックスをDHCPサーバーに返します。
3. The server responds with a Reply message. The prefixes can then be reused by other MNs.
3. サーバーは応答メッセージで応答します。プレフィックスは、他のMNで再利用できます。
+-------+ +-------+ +-----------+
| MN | | AR | |DHCP Server|
+-------+ +-------+ +-----------+
| | |
| 1 De-registration | |
| handover, or other | |
|<--------------------->| |
| |2 Relay-forward/Release|
| |---------------------->|
| | |
| |3 Relay-reply/Reply |
| |<--------------------- |
| | |
| | |
Figure 4: Prefix Release
図4：プレフィックスリリース
The IAID is 4 bytes in length and should be unique in the scope of an AR. The prefix table should be maintained; this table contains the IAID, the Media Access Control (MAC) address, and the prefix(es) assigned to the MN. In LTE networks, the International Mobile Equipment Identity (IMEI) uniquely identifies the MN's interface and thus corresponds to the MAC address. The MAC address of the interface should be stored in the prefix table and is used as the key for searching the table.
IAIDの長さは4バイトであり、ARの範囲内で一意である必要があります。プレフィックステーブルは維持する必要があります。このテーブルには、IAID、メディアアクセスコントロール（MAC）アドレス、およびMNに割り当てられたプレフィックスが含まれています。 LTEネットワークでは、International Mobile Equipment Identity（IMEI）がMNのインターフェースを一意に識別し、MACアドレスに対応します。インターフェイスのMACアドレスはプレフィックステーブルに保存する必要があり、テーブルを検索するためのキーとして使用されます。
The IAID should be set to Start_IAID; Start_IAID is an integer of 4 octets. The following algorithm is used to generate the IAID:
IAIDはStart_IAIDに設定する必要があります。 Start_IAIDは4オクテットの整数です。 IAIDの生成には、次のアルゴリズムが使用されます。
1. Set this IAID value in the IA_PD Prefix option. Request a prefix for this MN as described in Section 3.1 or Section 3.2.
1. このIAID値をIA_PD Prefixオプションに設定します。セクションMNまたはセクション3.2で説明されているように、このMNのプレフィックスを要求します。
2. Store the IAID, MAC address, and received prefix(es) in the next entry of the prefix table.
2. IAID、MACアドレス、および受信したプレフィックスをプレフィックステーブルの次のエントリに保存します。
3. Increment the IAID.
3. IAIDを増分します。
A prefix table entry for an MN that hands over to another AR must be removed. The IAID value is released and can then be reused.
別のARにハンドオーバーするMNのプレフィックステーブルエントリは削除する必要があります。 IAID値は解放され、再利用できます。
In P2P links, if /64 prefixes of all MNs connected to one or more ARs are broadcast dynamically upstream as route information, high routing-protocol traffic (IGP, OSPF, etc.) due to per-MN interface prefixes will result. There are two solutions to this problem. One solution is to use static configuration, which would be preferable in many cases. No routing protocols are needed, because each AR has a known piece of address space. If the DHCP servers also know that address space, then they will assign to a particular AR a prefix from that space.
P2Pリンクでは、1つ以上のARに接続されたすべてのMNの/ 64プレフィックスがルート情報として動的にアップストリームにブロードキャストされる場合、MNインターフェースごとのプレフィックスによる高ルーティングプロトコルトラフィック（IGP、OSPFなど）が発生します。この問題には2つの解決策があります。 1つの解決策は、静的構成を使用することです。これは多くの場合に適しています。各ARには既知のアドレス空間があるため、ルーティングプロトコルは必要ありません。 DHCPサーバーがそのアドレススペースも知っている場合、DHCPサーバーはそのスペースからのプレフィックスを特定のARに割り当てます。
The other solution is to use route aggregation. For example, each AR can be assigned a /48 or /32 prefix (an aggregate prefix, a.k.a service provider common prefix), while each interface of an MN can be assigned a /64 prefix. The /64 prefix is an extension of the /48 prefix -- for example, an AR's /48 prefix is 2001:db8:0::/48 -- while an interface of the MN is assigned a 2001:db8:0:2::/64 prefix. The border router in Figure 1 may be manually configured to broadcast only an individual AR's /48 or /32 prefix information to the Internet.
もう1つの解決策は、ルート集約を使用することです。たとえば、各ARには/ 48または/ 32プレフィックス（集約プレフィックス、別名サービスプロバイダー共通プレフィックス）を割り当てることができ、MNの各インターフェースには/ 64プレフィックスを割り当てることができます。 / 64プレフィックスは/ 48プレフィックスの拡張です。たとえば、ARの/ 48プレフィックスは2001：db8：0 :: / 48ですが、MNのインターフェースには2001：db8：0：2が割り当てられています。 :: / 64プレフィックス。図1の境界ルーターは、個々のARの/ 48または/ 32プレフィックス情報のみをインターネットにブロードキャストするように手動で構成できます。
In the initial network entry procedure shown in Figure 2, the AR as Remote Authentication Dial In User Service (RADIUS) client sends an Access-Request message with MN information to the RADIUS server. If the MN passes the authentication, the RADIUS server may send an Access-Accept message with prefix information to the AR using the Framed-IPv6-Prefix attribute. The AAA server also provides routing information to be configured for the MN on the AR using the Framed-IPv6-Route attribute. Using such a process, the AR can handle initial prefix assignments to MNs, but managing the lifetime of the prefixes is totally left to the AR. The Framed-IPv6-Prefix is not designed to support delegation of IPv6 prefixes. For this situation, the Delegated-IPv6-Prefix attribute, which is discussed below, can be used.
図2に示す初期ネットワークエントリ手順では、リモート認証ダイヤルインユーザーサービス（RADIUS）クライアントとしてのARが、MN情報を含むAccess-RequestメッセージをRADIUSサーバーに送信します。 MNが認証に合格すると、RADIUSサーバーは、Framed-IPv6-Prefix属性を使用して、プレフィックス情報を含むAccess-AcceptメッセージをARに送信できます。 AAAサーバーは、Framed-IPv6-Route属性を使用して、AR上のMNに構成するルーティング情報も提供します。そのようなプロセスを使用して、ARはMNへの初期プレフィックス割り当てを処理できますが、プレフィックスのライフタイムの管理は完全にARに任されています。 Framed-IPv6-Prefixは、IPv6プレフィックスの委任をサポートするようには設計されていません。この状況では、以下で説明するDelegated-IPv6-Prefix属性を使用できます。
[RFC4818] defines a RADIUS attribute, Delegated-IPv6-Prefix, which carries an IPv6 prefix to be delegated. This attribute is usable within either RADIUS or Diameter. [RFC4818] recommends that the DR use the AAA server to receive the prefixes to be delegated, by using the Delegated-IPv6-Prefix attribute/Attribute-Value Pair (AVP).
[RFC4818]は、委任されるIPv6プレフィックスを運ぶRADIUS属性Delegated-IPv6-Prefixを定義します。この属性は、RADIUSまたはDiameter内で使用できます。 [RFC4818]は、DRがDelegated-IPv6-Prefix属性/属性値ペア（AVP）を使用して、委任されるプレフィックスを受信するためにAAAサーバーを使用することを推奨します。
The DHCP server as DR, as shown in Figure 2, may send an Access-Request packet containing the Delegated-IPv6-Prefix attribute to the RADIUS server to request prefixes. In the Access-Request message, the DR may provide a hint that it would prefer a prefix -- for example, a /48 prefix. As the RADIUS server is not required to honor the hint, the server may delegate a longer prefix -- e.g., /56 or /64 -- in an Access-Accept message containing the Delegated-IPv6-Prefix attribute [RFC4818]. The attribute can appear multiple times when the RADIUS server delegates multiple prefixes to the DR. The DR sends the prefixes to the RR using the IA_PD option, and the AR as RR uses them for MNs, as described in Section 3.
DRとしてのDHCPサーバーは、図2に示すように、Delegated-IPv6-Prefix属性を含むAccess-RequestパケットをRADIUSサーバーに送信して、プレフィックスを要求します。 Access-Requestメッセージでは、DRは接頭辞（たとえば/ 48接頭辞）を好むというヒントを提供します。 RADIUSサーバーはヒントを尊重する必要がないため、サーバーはDelegated-IPv6-Prefix属性[RFC4818]を含むAccess-Acceptメッセージで、より長いプレフィックス（/ 56や/ 64など）を委任する場合があります。 RADIUSサーバーが複数のプレフィックスをDRに委任する場合、属性は複数回表示される可能性があります。セクション3で説明するように、DRはIA_PDオプションを使用してプレフィックスをRRに送信し、RRがMNに使用するARとしてプレフィックスを送信します。
When Diameter is used, the DHCP server as DR, as shown in Figure 2, sends an AA-Request message. The AA-Request message may contain a Delegated-IPv6-Prefix AVP. The Diameter server replies with an AA-Answer message. The AA-Answer message may contain a Delegated-IPv6-Prefix AVP. The AVP can appear multiple times when the Diameter server assigns multiple prefixes to an MN. The Delegated-IPv6-Prefix AVP may appear in an AA-Request packet as a hint from the AR to the Diameter server that it would prefer a prefix -- for example, a /48 prefix. The Diameter server may delegate in the AA-Answer message a /64 prefix, which is an extension of the /48 prefix. As in the case of RADIUS, the DR sends the prefixes to the RR using the IA_PD option, and the AR as RR uses them for the MNs as described in Section 3.
Diameterを使用すると、DRとしてのDHCPサーバーは、図2に示すように、AA-Requestメッセージを送信します。 AA-Requestメッセージには、Delegated-IPv6-Prefix AVPが含まれる場合があります。 DiameterサーバーはAA-Answerメッセージで応答します。 AA-Answerメッセージには、Delegated-IPv6-Prefix AVPが含まれる場合があります。 DiameterサーバーがMNに複数のプレフィックスを割り当てると、AVPが複数回出現する可能性があります。 Delegated-IPv6-Prefix AVPは、ARからDiameterサーバーへのプレフィックス（たとえば/ 48プレフィックス）を優先するヒントとして、AA-Requestパケットに表示される場合があります。 Diameterサーバーは、AA応答メッセージで/ 64プレフィックスを委任する場合があります。これは、/ 48プレフィックスの拡張です。 RADIUSの場合と同様に、DRはIA_PDオプションを使用してプレフィックスをRRに送信し、セクション3で説明するように、RRがMNに使用するARとしてプレフィックスを送信します。
This document does not introduce any additional message types and therefore does not introduce any additional threats. The security procedures for DHCPv6 [RFC3633], RADIUS [RFC2865], and Diameter [RFC3588] apply.
このドキュメントでは、追加のメッセージタイプを紹介していないため、追加の脅威を紹介していません。 DHCPv6 [RFC3633]、RADIUS [RFC2865]、およびDiameter [RFC3588]のセキュリティ手順が適用されます。
We are grateful to Suresh Krishnan, Hemant Singh, Qiang Zhao, Ole Troan, Qin Wu, Jouni Korhonen, Cameron Byrne, Brian Carpenter, Jari Arkko, and Jason Lin, whose in-depth reviews of this document led to several improvements.
Suresh Krishnan、Hemant Singh、Qiang Zhao、Ole Troan、Qin Wu、Jouni Korhonen、Cameron Byrne、Brian Carpenter、Jari Arkko、Jason Linに感謝します。
[3GPP-23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 11)", TS 23.401 V11.0.0, December 2011.
[3GPP-23401] 3GPP、「進化したユニバーサル地上無線アクセスネットワーク（E-UTRAN）アクセス用の一般的なパケットラジオサービス（GPRS）の拡張（リリース11）」、TS 23.401 V11.0.0、2011年12月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314] Wasserman、M。、「Recommendations for IPv6 in Third Generation Partnership Project（3GPP）Standards」、RFC 3314、2002年9月。
[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年
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。
[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月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4818] Salowey、J。およびR. Droms、「RADIUS Delegated-IPv6-Prefix Attribute」、RFC 4818、2007年4月。
[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月。
[RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", RFC 6342, August 2011.
[RFC6342] Koodli、R。、「IPv6展開に関するモバイルネットワークの考慮事項」、RFC 6342、2011年8月。
[RFC6459] Korhonen, J., Ed., 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.、Ed。、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G.、and K. Iisakkila、 "IPv6 in the 3rd Generation Partnership Project（3GPP）Evolved Packet System（ EPS）」、RFC 6459、2012年1月。
Authors' Addresses
著者のアドレス
Behcet Sarikaya Huawei USA 5340 Legacy Dr. Plano, TX 75074
Behcet Sarikaya Huawei USA 5340 Legacy Dr. Plano、TX 75074
EMail: sarikaya@ieee.org
Frank Xia Huawei USA 1700 Alma Drive, Suite 500 Plano, TX 75075
フランクξああUAは米国1700アルマドライブ、スイート500プラノ、テキサス州75075
Phone: +1 972-509-5599
EMail: xiayangsong@huawei.com
Ted Lemon Nominum 2000 Seaport Blvd. Redwood City, CA 94063
テッドレモンノミナム2000シーポートブルバード。レッドウッドシティ、カリフォルニア94063
EMail: mellon@nominum.com