[要約] RFC 5778は、ホームエージェントとDiameterサーバーの相互作用をサポートするための仕様です。このRFCの目的は、モバイルIPv6環境でのホームエージェントとDiameterサーバーの連携を向上させることです。
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 5778 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 J. Bournelle
Orange Labs
G. Giaretta
Qualcomm
M. Nakhjiri
Motorola
February 2010
Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction
直径モバイルIPv6：ホームエージェントへのサポート直径サーバーインタラクション
Abstract
概要
Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and a Diameter server.
モバイルIPv6の展開は、ホームエージェントとモバイルサービスプロバイダーの直径サーバーとの間の相互作用に基づいて、動作を動的にブートストラップしたい場合があります。このドキュメントは、モバイルIPホームエージェントと直径サーバー間の相互作用を指定します。
This document defines the home agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document.
このドキュメントでは、モバイルノードがインターネットキーExchange V2プロトコルを拡張可能な認証プロトコルを使用して認証するとき、またはモバイルIPv6認証プロトコルを使用して、Home AgentをDiameter Server通信に定義します。認証と承認に加えて、このドキュメントでは、モバイルIPv6固有のパラメーターと会計の構成が指定されています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5778.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5778で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Application Identifiers .........................................6
4. Protocol Description ............................................7
4.1. Support for Mobile IPv6 with IKEv2 and EAP .................7
4.2. Support for the Mobile IPv6 Authentication Protocol .......10
4.3. Mobile IPv6 Session Management ............................11
4.3.1. Session-Termination-Request ........................11
4.3.2. Session-Termination-Answer .........................11
4.3.3. Abort-Session-Request ..............................12
4.3.4. Abort-Session-Answer ...............................12
4.4. Accounting for Mobile IPv6 Services .......................12
4.4.1. Accounting-Request .................................13
4.4.2. Accounting-Answer ..................................13
5. Command Codes ..................................................13
5.1. Command Code for Mobile IPv6 with IKEv2 and EAP ...........13
5.1.1. Diameter-EAP-Request ...............................13
5.1.2. Diameter-EAP-Answer ................................14
5.2. Command Codes for Mobile IPv6 Authentication
Protocol Support ..........................................15
5.2.1. MIP6-Request .......................................16
5.2.2. MIP6-Answer ........................................17
6. AVPs ...........................................................18
6.1. User-Name AVP .............................................21
6.2. Service-Selection AVP .....................................21
6.3. MIP-MN-AAA-SPI AVP ........................................21
6.4. MIP-MN-HA-SPI AVP .........................................22
6.5. MIP-Mobile-Node-Address AVP ...............................22
6.6. MIP6-Agent-Info AVP .......................................22
6.7. MIP-Careof-Address AVP ....................................23
6.8. MIP-Authenticator AVP .....................................23
6.9. MIP-MAC-Mobility-Data AVP .................................23
6.10. MIP-Session-Key AVP ......................................23
6.11. MIP-MSA-Lifetime AVP .....................................23
6.12. MIP-MN-HA-MSA AVP ........................................24
6.13. MIP-Algorithm-Type AVP ...................................24
6.14. MIP-Replay-Mode AVP ......................................24
6.15. MIP6-Feature-Vector AVP ..................................25
6.16. MIP-Timestamp AVP ........................................25
6.17. QoS-Capability AVP .......................................25
6.18. QoS-Resources AVP ........................................25
6.19. Chargeable-User-Identity AVP .............................25
6.20. MIP6-Auth-Mode AVP .......................................25
6.21. Accounting AVPs ..........................................26
7. Result-Code AVP Values .........................................27
7.1. Success ...................................................27
7.2. Permanent Failures ........................................27
8. AVP Occurrence Tables ..........................................27
8.1. DER, DEA, MIR, and MIA AVP/Command-Code Table .............28
8.2. Coupled Accounting Model AVP Table ........................28
9. IANA Considerations ............................................29
9.1. Command Codes .............................................29
9.2. AVP Codes .................................................29
9.3. Result-Code AVP Values ....................................30
9.4. Application Identifier ....................................30
9.5. Namespaces ................................................30
10. Security Considerations .......................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................33
Performing the Mobile IPv6 protocol [RFC3775] requires the mobile node (MN) to own a home address and to have an assigned home agent (HA) to the MN. The MN needs to register with the HA in order to enable its reachability and mobility, when away from its home link. The registration process itself may require an establishment of IPsec security associations (SAs) and cryptographic material between the MN and the HA. Alternatively, the registration process may be secured using a mobility message authentication option, which enables IPv6 mobility in an MN without having to establish an IPsec SA with its HA. Providing the collection of home address, HA address, and keying material is generally referred to as the Mobile IPv6 bootstrapping problem [RFC4640]. The purpose of this specification is to provide Diameter support for the interaction between the HA and the Authentication, Authorization, and Accounting (AAA) server. This specification satisfies the requirements defined in [RFC5637] for the bootstrapping problem in the split scenario [RFC5026] and also specifies Diameter support for the Authentication Protocol for Mobile IPv6 [RFC4285]. The Diameter support defined in this specification also applies to Dual Stack Mobile IPv6 [RFC5555].
モバイルIPv6プロトコル[RFC3775]を実行するには、モバイルノード（MN）がホームアドレスを所有し、MNに割り当てられたホームエージェント（HA）を持つ必要があります。MNは、ホームリンクから離れているときに、到達可能性とモビリティを可能にするために、HAに登録する必要があります。登録プロセス自体には、MNとHAの間のIPSECセキュリティ協会（SAS）と暗号化資料の確立が必要になる場合があります。あるいは、登録プロセスは、Mobilityメッセージ認証オプションを使用して保護される場合があります。これにより、HAでIPSEC SAを確立することなく、MNのIPv6モビリティが可能になります。ホームアドレス、HAアドレス、キーイン素材のコレクションを提供することは、一般にモバイルIPv6ブートストラップ問題[RFC4640]と呼ばれます。この仕様の目的は、HAと認証、承認、および会計（AAA）サーバーの間の相互作用の直径サポートを提供することです。この仕様は、分割シナリオ[RFC5026]のブートストラップ問題について[RFC5637]で定義されている要件を満たし、モバイルIPv6 [RFC4285]の認証プロトコルの直径サポートも指定します。この仕様で定義されている直径サポートは、デュアルスタックモバイルIPv6 [RFC5555]にも適用されます。
From a Mobility Service Provider (MSP) perspective, it is important to verify that the MN is authenticated and authorized to utilize Mobile IPv6 service, and is accounted for those. Only when the MN is authenticated and authorized does the MSP allow the bootstrapping of Mobile IPv6 parameters. Thus, prior to processing the Mobile IPv6 registrations, the HA participates in the authentication of the MN to verify the MN's identity. The HA also participates in the Mobile IPv6 authorization process involving the Diameter infrastructure. The HA, due to its role in traffic forwarding, may also perform accounting for the Mobile IPv6 service provided to the MN.
Mobility Service Provider（MSP）の観点からは、MNがモバイルIPv6サービスを利用することを認証および許可され、それらを考慮していることを確認することが重要です。MNが認証され、承認されている場合にのみ、MSPがモバイルIPv6パラメーターのブートストラップを許可します。したがって、モバイルIPv6登録を処理する前に、HAはMNのIDを確認するためにMNの認証に参加します。HAは、直径インフラストラクチャを含むモバイルIPv6認証プロセスにも参加しています。HAは、交通転送における役割により、MNに提供されるモバイルIPv6サービスの会計を実行することもできます。
This document enables the following functionality:
このドキュメントは、次の機能を有効にします。
Authentication: The MN's identity needs to be verified. As a Diameter client supporting the new Diameter Mobile IPv6 application, the HA may need to support more than one authentication type depending on the environment. Although the authentication is performed by the AAA server, there is an impact for the HA as different sets of command codes are needed for the respective authentication procedures.
認証：MNのIDを検証する必要があります。新しい直径のモバイルIPv6アプリケーションをサポートする直径クライアントとして、HAは環境に応じて複数の認証タイプをサポートする必要がある場合があります。認証はAAAサーバーによって実行されますが、それぞれの認証手順にはさまざまなコマンドコードが必要であるため、HAに影響があります。
Authorization: The HA must verify that the user is authorized to the Mobile IPv6 service using the assistance of the MSP Diameter servers. This is accomplished through the use of new Diameter applications specifically designed for performing Mobile IPv6 authorization decisions. This document defines required AAA procedures and requires the HA to support them and to participate in this authorization signaling.
承認：HAは、MSP直径サーバーの支援を使用して、ユーザーがモバイルIPv6サービスに対して許可されていることを確認する必要があります。これは、モバイルIPv6許可決定を実行するために特別に設計された新しい直径アプリケーションの使用によって達成されます。このドキュメントでは、必要なAAA手順を定義し、HAがそれらをサポートし、この承認シグナル伝達に参加する必要があります。
Accounting: For accounting purposes and capacity planning, it is required that the HA provides accounting reports to the Diameter infrastructure and thus supports the related Diameter accounting procedures.
会計：会計目的と能力計画のために、HAは直径インフラストラクチャに会計レポートを提供し、関連する直径の会計手順をサポートすることが必要です。
Session Management: The management of the mobility services may require the Diameter server or the HA to terminate the Mobile IPv6 service before the binding expires. This document defines procedures for the AAA-based session management.
セッション管理：モビリティサービスの管理には、バインディングの有効期限が切れる前にモバイルIPv6サービスを終了するために、直径サーバーまたはHAが必要になる場合があります。このドキュメントでは、AAAベースのセッション管理の手順を定義しています。
Figure 1 depicts the reference architecture for this document.
図1は、このドキュメントの参照アーキテクチャを示しています。
+--------+
|Diameter|
|Server |
+--------+
^
Back-End | Diameter Mobile IPv6
Protocol | HA<->AAA Server
Support | Interaction
| (this document)
v
+---------+ +---------------+
| Mobile | Front-End Protocol |Home Agent / |
| Node |<-------------------->|Diameter Client|
+---------+ IKEv2 or RFC 4285 +---------------+
Figure 1: Architecture Overview
図1：アーキテクチャの概要
Mobile IPv6 signaling between the MN and the HA can be protected using two different mechanisms, namely, using IPsec or the Authentication Protocol for Mobile IPv6 [RFC4285]. For these two approaches, several different authentication and key exchange solutions are available. When IPsec is used to protect Mobile IPv6 signaling messages, Internet Key Exchange v2 (IKEv2) is used [RFC4877] for the setup of the IPsec SAs. IKEv2 supports EAP-based (Extensible Authentication Protocol) initiator authentication, certificates, and pre-shared secrets. Alternatively, the Authentication Protocol for Mobile IPv6 uses a mechanism that is very similar to the one used for protecting Mobile IPv4 signaling messages.
MNとHAの間のモバイルIPv6シグナル伝達は、2つの異なるメカニズム、つまりモバイルIPv6のIPSECまたは認証プロトコルを使用して保護できます[RFC4285]。これら2つのアプローチでは、いくつかの異なる認証とキー交換ソリューションが利用可能です。IPSECを使用してモバイルIPv6シグナル伝達メッセージを保護する場合、IPSEC SASのセットアップには、インターネットキーエクスチェンジV2（IKEV2）が使用されます[RFC4877]。IKEV2は、EAPベースの（拡張可能な認証プロトコル）イニシエーター認証、証明書、および事前共有秘密をサポートしています。あるいは、モバイルIPv6の認証プロトコルは、モバイルIPv4シグナリングメッセージの保護に使用されるメカニズムと非常によく似たメカニズムを使用します。
The ability to use different credentials and methods to authenticate the MN has an impact on the AAA interactions between the HA (acting as a Diameter client) and the Diameter server. This specification is only limited to the following MN authentication methods:
異なる資格情報と方法を使用してMNを認証する機能は、HA（直径クライアントとして機能する）と直径サーバーの間のAAA相互作用に影響を与えます。この仕様は、次のMN認証方法に限定されます。
o IKEv2 usage with EAP
o EAPでのIKEV2の使用
o Mobile IPv6 Authentication Protocol
o モバイルIPv6認証プロトコル
New authentication mechanisms may be added later by separate specifications.
新しい認証メカニズムは、後で別々の仕様によって追加される場合があります。
For accounting of Mobile IPv6 services provided to the MN, this specification uses the Diameter base protocol accounting defined in [RFC3588].
MNに提供されるモバイルIPv6サービスの会計には、この仕様では[RFC3588]で定義された直径ベースプロトコルアカウンティングを使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The Mobile IPv6 bootstrapping terminology is taken from [RFC4640]. Additional terminology is defined below:
モバイルIPv6ブートストラップ用語は[RFC4640]から取得されます。追加の用語を以下に定義します。
Authentication, Authorization, and Accounting (AAA):
認証、承認、および会計（AAA）：
AAA protocol based on Diameter [RFC3588] with required EAP support [RFC4072].
必要なEAPサポート[RFC4072]を備えた直径[RFC3588]に基づくAAAプロトコル。
Home AAA (AAAH):
ホームAAA（AAAH）：
An authentication, authorization, and accounting server located in the user's home network, i.e., in the home realm.
ユーザーのホームネットワーク、つまりホームレルムにある認証、承認、および会計サーバー。
This specification defines two new Diameter applications and their respective Application Identifiers:
この仕様では、2つの新しい直径アプリケーションとそれぞれのアプリケーション識別子を定義します。
Diameter Mobile IPv6 IKE (MIP6I) 7 Diameter Mobile IPv6 Auth (MIP6A) 8
直径モバイルIPv6 IKE（MIP6I）7直径モバイルIPv6 AUTH（MIP6A）8
The MIP6I Application Identifier is used when the MN is authenticated and authorized using IKEv2. The MIP6A Application Identifier is used when the MN is authenticated and authorized using the Mobile IPv6 Authentication Protocol.
MIP6Iアプリケーション識別子は、MNがIKEV2を使用して認証および承認されている場合に使用されます。MIP6Aアプリケーション識別子は、MNがモバイルIPv6認証プロトコルを使用して認証および承認されている場合に使用されます。
Mobile IPv6-related accounting information generated by the HA uses either the MIP6I or the MIP6A Application Identifier in the case of the coupled accounting model. The Diameter Base Accounting Application Identifier (value of 3) is used in the case of the split accounting model. Refer to Section 4.4 for more information regarding the accounting models.
HAによって生成されたモバイルIPv6関連の会計情報は、結合会計モデルの場合にMIP6IまたはMIP6Aアプリケーション識別子のいずれかを使用します。分割会計モデルの場合、直径ベースアカウンティングアプリケーション識別子（3の値）が使用されます。会計モデルに関する詳細については、セクション4.4を参照してください。
The use of IKEv2 with EAP between the MN and the HA allows the AAA to authenticate the MN. When EAP is used with IKEv2, the Diameter EAP application logic and procedures, as defined in [RFC4072], are re-used. EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks as stated in Section 2.16 and Section 5 of [RFC4306]. Attribute-value pairs (AVPs) specific to Mobile IPv6 bootstrapping are added to the EAP application commands.
MNとHAの間にEAPでIKEV2を使用すると、AAAはMNを認証できます。EAPがIKEV2で使用される場合、[RFC4072]で定義されている直径EAPアプリケーションロジックと手順が再利用されます。共有キーを確立しないEAPメソッドは、[RFC4306]のセクション2.16およびセクション5に記載されているように、多くの中間攻撃の対象となるため、使用すべきではありません。モバイルIPv6ブートストラップに固有の属性値ペア（AVP）がEAPアプリケーションコマンドに追加されます。
Figure 2 shows the message flow involved during the authentication phase when EAP is used. The communication between the mobile node and the home agent uses the conventions defined in [RFC4306]. Similarly, the communication between the home agent and the Diameter server uses the conventions defined in [RFC4072].
図2は、EAPが使用されたときの認証フェーズ中に関与するメッセージフローを示しています。モバイルノードとホームエージェントの間の通信は、[RFC4306]で定義された規則を使用します。同様に、ホームエージェントと直径サーバー間の通信は、[RFC4072]で定義されている規則を使用します。
Mobile Home Diameter
Node Agent Server
| | |
| HDR, SAi1, KEi, Ni (1) | |
|-------------------------------->| |
| | |
| HDR, SAr1, KEr, Nr, [CERTREQ](2)| |
|<--------------------------------| |
| | |
| HDR, SK{IDi,[CERTREQ,] [IDr,] | |
| [CP(CFG_REQUEST),] | |
| SAi2, TSi, TSr} (3) | DER (EAP-Response) (4) + |
|-------------------------------->| MIP6 Bootstrapping AVPs |
| |------------------------->|
| | |
| | DEA (EAP-Request) (5) |
| HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------|
|<------------------------------- | |
| | |
| HDR, SK{EAP} | |
|-------------------------------->| DER (EAP-Response) |
| |------------------------->|
| | |
| | DEA (EAP-Request) |
| HDR, SK{EAP-Request} |<-------------------------|
|<--------------------------------| |
| | |
| HDR, SK{EAP-Response} | |
|-------------------------------->| DER (EAP-Response) |
| |------------------------->|
: ... : ... :
| | |
| | DEA (EAP-Success) + |
| | MIP6 Bootstrapping AVPs |
| HDR, SK{EAP-Success} |<-------------------------|
|<--------------------------------| |
| | |
| HDR, SK{AUTH} | |
|-------------------------------->| |
| | |
| HDR, SK{AUTH, [CP(CFG_REPLY,] | |
| SAr2, TSi, TSr} | |
|<--------------------------------| |
| | |
Figure 2: Mobile IPv6 Bootstrapping Using IKEv2 and EAP
図2：IKEV2とEAPを使用したモバイルIPv6ブートストラップ
The MN and the HA start the interaction with an IKE_SA_INIT exchange.
MNとHAは、IKE_SA_INIT Exchangeとの相互作用を開始します。
In this phase, cryptographic algorithms are negotiated, and nonces and Diffie-Hellman parameters are exchanged. Message (3) starts the IKE_AUTH phase. This second phase authenticates the previous messages, exchanges identities and certificates, and establishes the first CHILD_SA. It is used to mutually authenticate the MN (acting as an IKEv2 initiator) and the HA (acting as an IKEv2 responder). The identity of the user/MN is provided in the IDi field. The MN indicates its willingness to be authenticated via EAP by omitting the AUTH field in message (3) (see Section 2.16 of [RFC4306]).
このフェーズでは、暗号化アルゴリズムがネゴシエートされ、NoncesとDiffie-Hellmanパラメーターが交換されます。メッセージ（3）はIKE_AUTHフェーズを開始します。この第2フェーズは、以前のメッセージを認証し、アイデンティティと証明書を交換し、最初のchild_saを確立します。これは、MN（IKEV2イニシエーターとして機能する）およびHA（IKEV2レスポンダーとして機能する）を相互に認証するために使用されます。ユーザー/MNの身元はIDIフィールドで提供されます。MNは、メッセージ（3）で認証フィールドを省略することにより、EAPを介して認証される意欲を示しています（[RFC4306]のセクション2.16を参照）。
As part of the authentication process, the MN MAY request a home address or a home prefix or suggest one (see [RFC4877]), using a CFG_REQUEST payload in the message (3).
認証プロセスの一環として、MNは、メッセージのCFG_REQUESTペイロードを使用して、自宅の住所またはホームアドレスを要求するか（[RFC4877]を参照）（[rfc4877]を参照）（3））を要求する場合があります（3）。
The HA extracts the IDi field from the message (3) and sends a Diameter-EAP-Request (DER) message (4) towards the authenticating Diameter server. The EAP-Payload AVP contains a EAP-Response/ Identity with the identity extracted from the IDi field.
HAはメッセージ（3）からIDIフィールドを抽出し、Authenticating Diameter Serverに直径-Eap-Request（der）メッセージ（4）を送信します。EAP-Payload AVPには、IDIフィールドから抽出されたアイデンティティとのEAP応答/アイデンティティが含まれています。
This message is routed to the MN's Diameter server/EAP server. The Diameter server selects the EAP method and replies with the Diameter-EAP-Answer (DEA) message. Depending on the type of EAP method chosen, a number of DER and DEA messages carry the method-specific exchanges between the MN and the Diameter server/EAP server.
このメッセージは、MNのDiameter Server/EAPサーバーにルーティングされます。直径サーバーはEAPメソッドを選択し、Aimeter-Eap-Answer（DEA）メッセージで返信します。選択したEAPメソッドのタイプに応じて、多くのDERおよびDEAメッセージには、MNとDiameter Server/EAPサーバーの間のメソッド固有の交換が含まれます。
At the end of the EAP authentication phase, the Diameter server indicates the result of the authentication in the Result-Code AVP and provides the corresponding EAP packet (EAP Success or EAP Failure). The last IKEv2 message sent by the HA contains the home address or the home prefix. In the latter case, a CREATE_CHILD_SA exchange is necessary to set up IPsec SAs for Mobile IPv6 signaling.
EAP認証フェーズの終わりに、直径サーバーは結果コードAVPの認証の結果を示し、対応するEAPパケット（EAP成功またはEAP障害）を提供します。HAから送信された最後のIKEV2メッセージには、ホームアドレスまたはホームプレフィックスが含まれています。後者の場合、モバイルIPv6シグナル伝達用のIPSEC SASをセットアップするには、create_child_sa交換が必要です。
In some deployment scenarios, the HA may also act as an IKEv2 responder for a conventional IPsec VPN access. The challenge in this case is that the IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service or for IPsec VPN access service. A network operator needs to be aware of this limitation. One solution already supported by IKEv2 is to use different responder identities when operating as a conventional IPsec VPN gateway or as an HA. The MN can then indicate the preferred responder type using the appropriate IDr payload in the IKE_AUTH message.
一部の展開シナリオでは、HAは、従来のIPSEC VPNアクセスのIKEV2レスポンダーとしても機能する場合があります。この場合の課題は、IKEV2レスポンダーがIKEV2がモバイルIPv6サービスまたはIPSEC VPNアクセスサービスに使用されているかどうかを知らない可能性があることです。ネットワークオペレーターは、この制限を認識する必要があります。IKEV2ですでにサポートされているソリューションの1つは、従来のIPSEC VPNゲートウェイとして、またはHAとして動作する場合、異なるレスポンダーアイデンティティを使用することです。MNは、IKE_AUTHメッセージの適切なIDRペイロードを使用して、優先レスポンダータイプを示すことができます。
Eventually, when the HA receives a Binding Update (BU), the HA authenticates and authorizes the MN. It is RECOMMENDED that the HA sends an accounting request message every time it receives a BU.
最終的に、HAがバインディングアップデート（BU）を受信すると、HAはMNを認証および承認します。HAは、BUを受信するたびに会計リクエストメッセージを送信することをお勧めします。
Figure 3 shows the message sequence between the MN, the HA, and the Diameter server during the registration when Mobile IPv6 Authentication Protocol is used. A BU and a Binding Acknowledgement (BA) messages are used in the binding registration process.
図3は、モバイルIPv6認証プロトコルが使用されている登録中のMN、HA、および直径サーバーの間のメッセージシーケンスを示しています。BUおよび拘束力のある承認（BA）メッセージは、拘束力のある登録プロセスで使用されます。
Receiving a BU at the HA initiates a MIP6-Request to be sent to the Diameter server. The Diameter server in turn responds with a MIP6- Answer. The HA may assign a home address to the MN and provide it to the Diameter server in the MIP-Mobile-Node-Address AVP.
HAでBUを受信すると、MIP6-RequestがDiameterサーバーに送信されるようになります。直径サーバーは、MIP6-の回答で応答します。HAは、MNにホームアドレスを割り当て、MIP-Mobile-Node-Address AVPのDiameterサーバーに提供する場合があります。
According to [RFC4285], the MN uses the Mobile Node Identifier Option, specifically the MN-NAI mobility option (as defined in [RFC4283]) to identify itself. The HA MUST copy the MN-NAI mobility option value to the User-Name AVP in the subsequent request messages.
[RFC4285]によると、MNはモバイルノード識別子オプション、特にMN-NAIモビリティオプション（[RFC4283]で定義されている）を使用して自らを識別します。HAは、後続のリクエストメッセージでMN-NAIモビリティオプション値をユーザー名AVPにコピーする必要があります。
The procedure described in this specification for the Mobile IPv6 Authentication Protocol is only needed for the initially received BU for which the HA does not have an existing security association. When the HA receives subsequent BUs, they are processed locally in the HA. It is RECOMMENDED that the HA sends an accounting request message every time it receives a Binding Update. However, the HA MAY re-authorize the MN with the Diameter server at any time depending on the deployment and the local policy.
モバイルIPv6認証プロトコルのこの仕様で説明されている手順は、HAに既存のセキュリティ関連がない最初のBUにのみ必要です。HAが後続のバスを受け取ると、それらはHAでローカルに処理されます。HAは、バインディングアップデートを受信するたびに会計リクエストメッセージを送信することをお勧めします。ただし、HAは、展開とローカルポリシーに応じて、いつでも直径サーバーを使用してMNを再承認する場合があります。
This specification assumes that in the case where Mobile IPv6 Authentication Protocol is used, the MN-AAA option is included in the BU as defined in [RFC4285] and the Diameter server computes required session keys after having successfully authenticated the MN. The computation of the session keys is out of scope of this specification. Other possible ways of using the Mobile IPv6 Authentication Protocol are also out of scope of this specification and would require a new specification to describe the detailed behavior of the HA-AAAH interface and corresponding session key derivation.
この仕様は、モバイルIPv6認証プロトコルが使用される場合、MN-AAAオプションが[RFC4285]で定義されているようにBUに含まれ、MNを正常に認証した後に必要なセッションキーを計算するDiameter Serverが含まれることを前提としています。セッションキーの計算は、この仕様の範囲外です。モバイルIPv6認証プロトコルを使用する他の可能な方法も、この仕様の範囲外であり、HA-AAAHインターフェイスの詳細な動作と対応するセッションキー派生を記述するための新しい仕様が必要です。
Mobile Home Diameter
Node Agent Server
| | |
| | MIP6-Request + MIP6 |
| Binding Update | Bootstrapping AVPs |
|------------------------------------>|-------------------->|
| (Mobile Node Identifier Option, | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
| | |
| | MIP6-Answer + MIP6 |
| Binding Acknowledgement | Bootstrapping AVPs |
|<------------------------------------|<--------------------|
| (Mobile Node Identifier Option | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
Figure 3: Mobile IPv6 Bootstrapping Using the Mobile IPv6 Authentication Protocol
図3：モバイルIPv6認証プロトコルを使用したモバイルIPv6ブートストラップ
The Diameter server may maintain state or may be stateless. This is indicated in the Auth-Session-State AVP (or its absence). The HA MUST support the Authorization Session State Machine defined in [RFC3588].
直径サーバーは状態を維持する場合や、ステートレスである場合があります。これは、Auth-Session-State AVP（またはその不在）に示されています。HAは、[RFC3588]で定義されている認証セッションステートマシンをサポートする必要があります。
This specification makes an assumption that each SA created between the MN and the HA as a result of a successful IKEv2 negotiation or a Mobile IPv6 Authentication Protocol exchange corresponds to one Diameter session. In the IKEv2 case, we specifically mean the created IKE SA.
この仕様は、IKEV2交渉の成功またはモバイルIPv6認証プロトコル交換の結果としてMNとHAの間に作成された各SAが1つの直径セッションに対応すると仮定します。IKEV2の場合、特に作成されたIKE SAを意味します。
The Session-Termination-Request (STR) message [RFC3588] is sent by the HA to inform the Diameter server that an authorized session is being terminated. This means that the HA MUST terminate the corresponding Mobile IPv6 binding and also terminate the corresponding SA.
Session-Termination-Request（STR）メッセージ[RFC3588]は、HAによって送信され、承認されたセッションが終了していることを直径サーバーに通知します。これは、HAが対応するモバイルIPv6結合を終了し、対応するSAも終了する必要があることを意味します。
The Session-Termination-Answer (STA) message [RFC3588] is sent by the Diameter server to acknowledge the notification that the session has been terminated.
セッション終了回答（STA）メッセージ[RFC3588]は、Diameterサーバーによって送信され、セッションが終了したという通知を確認します。
The Abort-Session-Request (ASR) message [RFC3588] is sent by the Diameter server to the HA to terminate the authorized session. This fulfills one of the requirement described in [RFC5637]. When the HA receives the ASR message, it MUST terminate the corresponding SA. Subsequently, the HA MUST take further actions to terminate the corresponding Mobile IPv6 binding.
中止セッションレクエスト（ASR）メッセージ[RFC3588]は、承認されたセッションを終了するために、直径サーバーによってHAに送信されます。これは、[RFC5637]で説明されている要件の1つを満たします。HAがASRメッセージを受信するとき、対応するSAを終了する必要があります。その後、HAは、対応するモバイルIPv6バインディングを終了するためにさらなる措置を講じる必要があります。
The Abort-Session-Answer (ASA) message [RFC3588] is sent by the home agent in response to an ASR message.
中止セッションアンスワー（ASA）メッセージ[RFC3588]は、ASRメッセージに応じてホームエージェントによって送信されます。
The HA MUST be able act as a Diameter client collecting accounting records needed for service control and charging. The HA MUST support the accounting procedures (specifically the command codes mentioned below) and the Accounting Session State Machine as defined in [RFC3588]. The command codes, exchanged between the HA and Diameter server for accounting purposes, are provided in the following subsections.
HAは、サービス制御と充電に必要な直径クライアントを収集する会計記録として機能することができなければなりません。HAは、[RFC3588]で定義されているように、会計手順（具体的に言及したコマンドコード）と会計セッション状態マシンをサポートする必要があります。会計目的でHAとDiameterサーバーの間で交換されるコマンドコードは、以下のサブセクションで提供されます。
The Diameter application design guideline [DIME-APP] defines two separate models for accounting:
直径アプリケーションの設計ガイドライン[DIME-APP]は、会計の2つの別々のモデルを定義します。
Split accounting model:
分割会計モデル：
According to this model, the accounting messages use the Diameter Base Accounting Application Identifier (value of 3). Since accounting is treated as an independent application, accounting commands may be routed separately from the rest of application messages and thus the accounting messages generally end up in a central accounting server. Since the Diameter Mobile IPv6 application does not define its own unique accounting commands, this is the preferred choice, since it permits use of centralized accounting for several applications.
このモデルによると、会計メッセージは直径ベースの会計アプリケーション識別子（値3）を使用します。会計は独立したアプリケーションとして扱われるため、会計コマンドは他のアプリケーションメッセージとは別にルーティングされる可能性があるため、会計メッセージは一般に中央会計サーバーになります。直径モバイルIPv6アプリケーションは独自の独自の会計コマンドを定義していないため、これはいくつかのアプリケーションの集中会計の使用を許可するため、好ましい選択です。
Coupled accounting model:
結合会計モデル：
In this model, the accounting messages will use either the MIP6I or the MIP6A Application Identifiers. This means that accounting messages will be routed like any other Mobile IPv6 application messages. This requires the Diameter server in charge of Mobile IPv6 application to handle the accounting records (e.g., sends them to a proper accounting server).
このモデルでは、会計メッセージはMIP6IまたはMIP6Aアプリケーション識別子のいずれかを使用します。これは、アカウンティングメッセージが他のモバイルIPv6アプリケーションメッセージと同様にルーティングされることを意味します。これには、会計レコードを処理するためにモバイルIPv6アプリケーションを担当する直径サーバーが必要です（たとえば、適切な会計サーバーに送信します）。
As mentioned above, the preferred choice is to use the split accounting model and thus to choose Diameter Base Accounting Application Identifier (value of 3) for accounting messages.
上記のように、好みの選択肢は、分割会計モデルを使用して、会計メッセージに対して直径ベースアカウンティングアプリケーション識別子（値3）を選択することです。
The Accounting-Request command [RFC3588] is sent by the HA to the Diameter server to exchange accounting information regarding the MN with the Diameter server.
Accounting-Requestコマンド[RFC3588]は、HAから直径サーバーに送信され、MNに関する会計情報をDiameterサーバーと交換します。
The Accounting-Answer command [RFC3588] is sent by the Diameter server to the HA to acknowledge an Accounting-Request.
Accounting-Answerコマンド[RFC3588]は、Acounting-Requestを認めるために、直径サーバーによってHAに送信されます。
For the use of Mobile IPv6 with IKEv2 and EAP, this document reuses the Diameter EAP application [RFC4072] commands: Diameter-EAP-Request (DER) and Diameter-EAP-Answer (DEA). This specification extends the existing DER and DEA command ABNFs with a number of AVPs to support Mobile IPv6 split scenario bootstrapping. Other than new additional AVPs and the corresponding additions to the command ABNFs, the Diameter EAP application command ABNFs remain unchanged. The ABNF language is defined in [RFC3588].
IKEV2およびEAPでモバイルIPv6を使用するために、このドキュメントでは、直径EAPアプリケーション[RFC4072]コマンドを再利用します。この仕様は、モバイルIPv6分割シナリオブートストラップをサポートするために、既存のDerおよびDEAコマンドABNFを多数のAVPSで拡張します。新しい追加のAVPとコマンドABNFSへの対応する追加を除き、直径EAPアプリケーションコマンドABNFは変更されません。ABNF言語は[RFC3588]で定義されています。
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
Diameter-EAP-Request DER 268 RFC 4072 Diameter Mobile IPv6 IKE
Diameter-EAP-Answer DEA 268 RFC 4072 Diameter Mobile IPv6 IKE
Figure 4: Command Codes
図4：コマンドコード
The Diameter-EAP-Request (DER) message, indicated by the Command-Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by the HA to the Diameter server to initiate a Mobile IPv6 service authentication and authorization procedure. The Application-ID field of the Diameter Header MUST be set to the Diameter Mobile IPv6 IKE Application ID (value of 7). The grouped AVP has the following modified ABNF (as defined in [RFC3588]):
268に設定されたコマンドコードフィールドとコマンドフラグフィールドに設定された「r」ビットで設定された直径 - エアプレクエスト（der）メッセージは、HAによって直径サーバーに送信され、モバイルIPv6サービス認証を開始するおよび許可手順。直径ヘッダーのアプリケーション-IDフィールドは、直径モバイルIPv6 IKEアプリケーションID（値7）に設定する必要があります。グループ化されたAVPには、次の変更されたABNFがあります（[RFC3588]で定義されています）：
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ User-Name ]
...
{ EAP-Payload }
...
[ MIP6-Feature-Vector ]
[ MIP6-Agent-Info ]
*2[ MIP-Mobile-Node-Address ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ QoS-Capability ]
* [ QoS-Resources ]
...
* [ AVP ]
Mobile IPv6 bootstrapping AVPs are only included in the first DER message send by the HA. The subsequent DER messages required by the EAP method do not need to include any Mobile IPv6 bootstrapping AVPs. The MN is both authenticated and authorized for the mobility service during the EAP authentication. Thus, the Auth-Request-Type AVP MUST be set to the value AUTHORIZE_AUTHENTICATE.
モバイルIPv6ブートストラップAVPは、HAが最初のderメッセージ送信にのみ含まれます。EAPメソッドで必要な後続のderメッセージには、モバイルIPv6ブートストラップAVPを含める必要はありません。MNは、EAP認証中にモビリティサービスに対して認証され、許可されています。したがって、auth-request-type AVPは、authorize_authenticateの値に設定する必要があります。
The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-EAP-Request (DER) message. The Application-Id field in the Diameter message header MUST be set to the Diameter Mobile IPv6 IKE Application-Id (value of 7). If the Mobile IPv6 authentication procedure was successful, then the response MAY include any set of bootstrapping AVPs.
268に設定されたコマンドコードフィールドとコマンドフラグフィールドでクリアされた「r」ビットで示される直径（DEA）メッセージは、直径-eap-Request（der）メッセージに応じて送信されます。直径メッセージヘッダーのアプリケーション-IDフィールドは、直径モバイルIPv6 IKEアプリケーションID（値7）に設定する必要があります。モバイルIPv6認証手順が成功した場合、応答にはブートストラップAVPのセットが含まれる場合があります。
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time ]
...
*2[ MIP-Mobile-Node-Address ]
[ MIP6-Feature-Vector ]
[ MIP6-Agent-Info ]
[ Service-Selection ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
...
* [ AVP ]
If the EAP-based authentication and the authorization for the mobility service succeeds, then the Mobile IPv6 bootstrapping AVPs are included in the last DEA message that also carries the EAP-Success EAP payload. The other DEA messages required by the used EAP-method do not include any Mobile IPv6 bootstrapping AVPs.
EAPベースの認証とモビリティサービスの承認が成功した場合、モバイルIPv6ブートストラップAVPは、EAPサクセスEAPペイロードも運ぶ最後のDEAメッセージに含まれています。使用済みのEAPメソッドで必要な他のDEAメッセージには、モバイルIPv6ブートストラップAVPは含まれていません。
This section defines the commands that are used for support with the Mobile IPv6 Authentication Protocol.
このセクションでは、モバイルIPv6認証プロトコルでサポートに使用されるコマンドを定義します。
There are multiple ways of deploying and utilizing the Mobile IPv6 Authentication Protocol, especially regarding the associated AAA interactions. In order to support multiple deployment models, this specification defines the MIP6-Auth-Mode AVP that in the request message tells the mode that the HA supports. This specification defines a method that requires the use of the MN-AAA option with the Mobile IPv6 Authentication Protocol.
特に関連するAAA相互作用に関して、モバイルIPv6認証プロトコルを展開および利用する方法は複数あります。複数の展開モデルをサポートするために、この仕様では、リクエストメッセージでHAがサポートするモードを指示するMIP6-Auth-Mode AVPを定義します。この仕様は、モバイルIPv6認証プロトコルでMN-AAAオプションを使用する必要がある方法を定義します。
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
MIP6-Request MIR 325 5.3.1 Diameter Mobile IPv6 Auth
MIP6-Answer MIA 325 5.3.2 Diameter Mobile IPv6 Auth
Command Codes
コマンドコード
The MIP6-Request (MIR), indicated by the Command-Code field set to 325 and the 'R' bit set in the Command Flags field, is sent by the HA, acting as a Diameter client, in order to request the authentication and authorization of an MN.
MIP6-Request（miR）は、325に設定されたコマンドコードフィールドとコマンドフラグフィールドに設定された「R」ビットで示されており、認証を要求するために、直径クライアントとして機能するHAによって送信されます。MNの承認。
Although the HA provides the Diameter server with replay protection-related information, the HA is responsible for the replay protection.
HAはDiameterサーバーにリプレイ保護関連の情報を提供しますが、HAはリプレイ保護を担当します。
The message format is shown below.
メッセージ形式を以下に示します。
<MIP6-Request> ::= < Diameter Header: 325, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ Origin-State-Id ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ MIP6-Feature-Vector ]
{ MIP6-Auth-Mode }
[ MIP-MN-AAA-SPI ]
[ MIP-MN-HA-SPI ]
1*2{ MIP-Mobile-Node-Address }
{ MIP6-Agent-Info }
{ MIP-Careof-Address }
[ MIP-Authenticator ]
[ MIP-MAC-Mobility-Data ]
[ MIP-Timestamp ]
[ QoS-Capability ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
If the MN is both authenticated and authorized for the mobility service, then the Auth-Request-Type AVP is set to the value AUTHORIZE_AUTHENTICATE. This is the case when the MIP6-Auth-Mode is set to the value MIP6_AUTH_MN_AAA.
MNがモビリティサービスに対して認証され、承認されている場合、Auth-RequestタイプのAVPはValue Authorize_Authenticateに設定されます。これは、mip6-auth-modeが値mip6_auth_mn_aaaに設定されている場合です。
The MIP6-Answer (MIA) message, indicated by the Command-Code field set to 325 and the 'R' bit cleared in the Command Flags field, is sent by the Diameter server in response to the MIP6-Request message.
325に設定されたコマンドコードフィールドとコマンドフラグフィールドで「R」ビットがクリアされた「R」で示されるMIP6-ANSWER（MIA）メッセージは、MIP6-Requestメッセージに応じて直径サーバーによって送信されます。
The User-Name AVP MAY be included in the MIA if it is present in the MIR. The Result-Code AVP MAY contain one of the values defined in Section 7, in addition to the values defined in [RFC3588].
ユーザー名AVPは、MIRに存在する場合、MIAに含まれる場合があります。結果コードAVPには、[RFC3588]で定義されている値に加えて、セクション7で定義された値の1つを含めることができます。
An MIA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Mobile-Node-Address AVP.
結果コードAVPをDiameter_Successに設定したMIAメッセージには、MIP-Mobile-Node-Address AVPを含める必要があります。
The message format is shown below.
メッセージ形式を以下に示します。
<MIP6-Answer> ::= < Diameter Header: 325, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Request-Type }
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP6-Feature-Vector ]
[ MIP-Agent-Info ]
*2[ MIP-Mobile-Node-Address ]
[ MIP-MN-HA-MSA ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Failed-AVP ]
* [ AVP ]
To provide support for [RFC4285] and for [RFC4877], the AVPs in the following subsections are needed. [RFC3588], [RFC4004], and [RFC4005] defined AVPs are reused whenever possible without changing the existing semantics of those AVPs.
[RFC4285]および[RFC4877]のサポートを提供するには、次のサブセクションのAVPが必要です。[RFC3588]、[RFC4004]、および[RFC4005]は、AVPの既存のセマンティクスを変更せずに、可能な限りAVPを定義します。
+--------------------+
| AVP Flag Rules |
+----+---+------+----+----+
AVP Defined | | |SHOULD|MUST|MAY |
Attribute Name Code in Value Type |MUST|MAY| NOT | NOT|Encr|
+------------------------------------------+----+---+------+----+----+
|MIP6-Feature- 124 RFC 5447 Unsigned64 | M | P | | V | Y |
| Vector | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Mobile- | M | P | | V | Y |
| Node-Address 333 RFC 4004 Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Agent-Info 486 RFC 5447 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|User-Name 1 RFC 3588 UTF8String | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Service- 493 6.2 UTF8String | M | P | | V | Y |
| Selection | | | | | |
+------------------------------------------+----+---+------+----+----+
|QoS-Capability 578 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Resources 508 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-MSA 492 6.12 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Chargeable-User- OctetString| M | P | | V | Y |
| Identity 89 6.19 | | | | | |
+------------------------------------------+----+---+------+----+----+
AVPs for Mobile IPv6 IKE Application
モバイルIPv6 IKEアプリケーション用AVPS
Note 1: The QoS-Capability and the QoS-Resource AVPs are defined in Sections 4.1 and 4.3 of [RFC5777].
注1：QOSの能力とQoSリソースAVPは、[RFC5777]のセクション4.1および4.3で定義されています。
+--------------------+
| AVP Flag Rules |
+----+---+------+----+----+
AVP Section | | |SHOULD|MUST|MAY |
Attribute Name Code Defined Value Type |MUST|MAY| NOT | NOT|Encr|
+------------------------------------------+----+---+------+----+----+
|MIP6-Feature- 124 RFC 5447 Unsigned64 | M | P | | V | Y |
| Vector | | | | | |
+------------------------------------------+----+---+------+----+----+
|User-Name 1 RFC 3588 UTF8String | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Service- 493 6.2 UTF8String | M | P | | V | Y |
| Selection | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-AAA-SPI 341 RFC 4004 Unsigned32 | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-SPI 491 6.4 Unsigned32 | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Mobile- 333 RFC 4004 Address | M | P | | V | Y |
| Node-Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Agent-Info 486 RFC 5447 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Careof- 487 6.7 Address | M | P | | V | Y |
| Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP- 488 6.8 OctetString| M | P | | V | Y |
| Authenticator | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MAC- 489 6.9 OctetString| M | P | | V | Y |
| Mobility-Data | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Session-Key 343 6.10 OctetString| M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MSA- 367 RFC 4004 Unsigned32 | M | P | | V | Y |
| Lifetime | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-MSA 492 6.12 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Algorithm- 345 6.13 Enumerated | M | P | | V | Y |
| Type | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Replay-Mode 346 6.14 Enumerated | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Timestamp 490 6.16 OctetString| M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Capability 578 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Resources 508 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Chargeable-User- OctetString| M | P | | V | Y |
| Identity 89 6.19 | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Auth-Mode 494 6.20 Enumerated | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Rest of the AVPs RFC 3588 | M | P | | V | Y |
|in the MIR & MIA RFC 4005 | | | | | |
|excluding *[AVP] | | | | | |
+------------------------------------------+----+---+------+----+----+
AVPs for the Mobile IPv6 Auth Application
モバイルIPv6認証アプリケーション用AVPS
Note 1: The QoS-Capability and the QoS-Resource AVPs are defined in Sections 4.1 and 4.3 of [RFC5777].
注1：QOSの能力とQoSリソースAVPは、[RFC5777]のセクション4.1および4.3で定義されています。
The User-Name AVP (AVP Code 1) is of type UTF8String and contains a Network Access Identifier (NAI) extracted from the MN-NAI mobility option included in the received BU message. Alternatively, the NAI can be extracted from the IKEv2 IDi payload included in the IKE_AUTH message sent by the IKE initiator.
ユーザー名AVP（AVPコード1）は型UTF8STRINGであり、受信BUメッセージに含まれるMN-NAIモビリティオプションから抽出されたネットワークアクセス識別子（NAI）が含まれています。あるいは、NAIは、IKEイニシエーターが送信したIKE_AUTHメッセージに含まれるIKEV2 IDIペイロードから抽出できます。
The Service-Selection AVP (AVP Code 493) is of type UTF8String and contains the name of the service or the external network with which the mobility service should be associated. In the scope of this specification, the value can be extracted from the IKEv2 IDr payload, if available in the IKE_AUTH message sent by the IKE initiator. Alternatively, if the Mobile IPv6 Authentication Protocol is used, then the Service-Selection AVP contains the string extracted from the Service Selection Mobility Option [RFC5149], if available in the received BU. Future specifications may define additional ways to populate the Service-Selection AVP with the required information.
サービス選択AVP（AVPコード493）は型UTF8STRINGであり、モビリティサービスを関連付けるサービスまたは外部ネットワークの名前が含まれています。この仕様の範囲では、IKEイニシエーターが送信したIKE_AUTHメッセージで使用可能な場合、IKEV2 IDRペイロードから値を抽出できます。または、モバイルIPv6認証プロトコルを使用する場合、サービス選択AVPには、受信BUで利用可能な場合、サービス選択モビリティオプション[RFC5149]から抽出された文字列が含まれています。将来の仕様では、サービス選択AVPに必要な情報を入力する追加の方法を定義する場合があります。
The AVP is also available to be used in messages sent from the Diameter server to the Diameter client. For example, if the request message did not contain the Service-Selection AVP but the MN was assigned with a default service, the Diameter server MAY return the name of the assigned default service to the HA.
AVPは、DiameterサーバーからDiameterクライアントに送信されたメッセージで使用できます。たとえば、リクエストメッセージにサービス選択AVPが含まれていないが、MNがデフォルトのサービスで割り当てられた場合、Diameterサーバーは割り当てられたデフォルトサービスの名前をHAに返すことができます。
If the Service-Selection AVP is present in both the request and the reply messages, it SHOULD contain the same service name. If the services differ, the HA MAY treat that as authorization failure.
リクエストメッセージと返信メッセージの両方にサービス選択AVPが存在する場合、同じサービス名が含まれている必要があります。サービスが異なる場合、HAはそれを許可の失敗として扱う可能性があります。
The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and contains a Security Parameter Index (SPI) code extracted from the Mobility Message Authentication Option included in the received BU message. This AVP is reused from [RFC4004].
MIP-MN-AAA-SPI AVP（AVPコード341）は型Unsigned32であり、受信BUメッセージに含まれるMobilityメッセージ認証オプションから抽出されたセキュリティパラメーターインデックス（SPI）コードが含まれています。このAVPは[RFC4004]から再利用されます。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, this AVP MUST be present in the MIR message.
MIP6-Auth-Mode AVPがMIP6_AUTH_MN_AAAを評価するように設定されている場合、このAVPはmiRメッセージに存在する必要があります。
The MIP-MN-HA-SPI AVP (AVP Code 491) is of type Unsigned32 and contains an SPI value that can be used with other parameters for identifying the security association required for the validation of the Mobile IPv6 MN-HA Authentication Option.
MIP-MN-HA-SPI AVP（AVPコード491）は型Unsigned32であり、モバイルIPv6 MN-HA認証オプションの検証に必要なセキュリティアソシエーションを識別するために他のパラメーターとともに使用できるSPI値が含まれています。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, and the Diameter server returns a valid MIP-MN-HA-MSA AVP in the MIA message, this AVP MUST be present inside the MIP-MN-HA-MSA AVP.
MIP6-Auth-Mode AVPがMIP6_AUTH_MN_AAAを値に設定し、DiameterサーバーがMIAメッセージで有効なMIP-MN-HA-MSA AVPを返す場合、このAVPはMIP-MN-HA-MSA AVP内に存在する必要があります。
The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and contains the HA assigned IPv6 or IPv4 home address of the mobile node.
MIP-Mobile-Node-Address AVP（AVPコード333）はタイプアドレスであり、モバイルノードのHA割り当てられたIPv6またはIPv4ホームアドレスが含まれています。
If the MIP-Mobile-Node-Address AVP contains the unspecified IPv6 address (0::0) or the all-zeroes IPv4 address (0.0.0.0) in a request message, then the HA expects the Diameter server to assign the home address in a subsequent answer message. If the Diameter server assigns only an IPv6 home network prefix to the mobile node, the lower 64 bits of the MIP-Mobile-Node-Address AVP provided address MUST be set to zero.
MIP-Mobile-Node-Address AVPに、要求メッセージに不特定のIPv6アドレス（0 :: 0）またはAll-ゼロIPv4アドレス（0.0.0.0）が含まれている場合、HAは直径サーバーがホームアドレスを割り当てることを期待します。その後の回答メッセージで。DiameterサーバーがモバイルノードにIPv6ホームネットワークプレフィックスのみを割り当てる場合、MIP-Mobile-Node-Address AVP提供アドレスの64ビットをゼロに設定する必要があります。
This AVP is reused from [RFC4004].
このAVPは[RFC4004]から再利用されます。
The MIP6-Agent-Info AVP (AVP Code 486) is defined in Section 4.2.1 of [RFC5447] and contains the IPv6 or the IPv4 address information of the HA. The HA address in a request message is the same as in the received BU message that triggered the authentication and authorization procedure towards the Diameter server. One use case is, e.g., to inform the Diameter server of the dynamically assigned HA.
MIP6-Agent-INFO AVP（AVPコード486）は、[RFC5447]のセクション4.2.1で定義されており、HAのIPv6またはIPv4アドレス情報が含まれています。リクエストメッセージのHAアドレスは、直径サーバーに向けて認証と承認の手順をトリガーした受信BUメッセージと同じです。1つのユースケースは、たとえば、動的に割り当てられたHAの直径サーバーに通知することです。
If the MIP6-Agent-Info AVP is present in an answer message and the Result-Code AVP is set to DIAMETER_SUCCESS_RELOCATE_HA, then the Diameter server is indicating to the HA that it MUST initiate an HA switch procedure towards the MN (e.g., using the procedure defined in [RFC5142]). If the Result-Code AVP is set to any other value, then the HA SHOULD initiate the HA switch procedure towards the MN. The address information of the assigned HA is defined in the MIP6-Agent-Info AVP.
MIP6-Agent-INFO AVPが回答メッセージに存在し、結果コードAVPがdiameter_success_relocate_haに設定されている場合、直径サーバーはHAにMNに向かってHAスイッチ手順を開始する必要があることを示しています（例えば、使用して、[RFC5142]で定義されている手順）。結果コードAVPが他の値に設定されている場合、HAはHAスイッチ手順をMNに向けて開始する必要があります。割り当てられたHAのアドレス情報は、MIP6-Agent-INFO AVPで定義されています。
The MIP-Careof-Address AVP (AVP Code 487) is of type Address and contains the IPv6 or the IPv4 care-of address of the mobile node. The HA extracts this IP address from the received BU message.
MIP-Careof-Address AVP（AVPコード487）はタイプアドレスであり、モバイルノードのIPv6またはIPv4ケアオブアドレスが含まれています。HAは、受信したBUメッセージからこのIPアドレスを抽出します。
The MIP-Authenticator AVP (AVP Code 488) is of type OctetString and contains the Authenticator Data from the received BU message. The HA extracts this data from the MN-AAA Mobility Message Authentication Option included in the received BU message.
MIP-Authenticator AVP（AVPコード488）はタイプのオクテットストリングであり、受信したBUメッセージの認証データが含まれています。HAは、受信BUメッセージに含まれるMN-AAAモビリティメッセージ認証オプションからこのデータを抽出します。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, this AVP MUST be present in the MIR message.
MIP6-Auth-Mode AVPがMIP6_AUTH_MN_AAAを評価するように設定されている場合、このAVPはmiRメッセージに存在する必要があります。
The MIP-MAC-Mobility-Data AVP (AVP Code 489) is of type OctetString and contains the MAC_Mobility_Data calculated by the HA as defined in [RFC4285] for the MN-AAA Mobility Message Authentication Option.
MIP-MAC-Mobility-Data AVP（AVPコード489）はタイプのオクテットストリングであり、MN-AAAモビリティメッセージ認証オプションの[RFC4285]で定義されているHAによって計算されたMAC_MOBILITY_DATAが含まれています。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, this AVP MUST be present in the MIR message.
MIP6-Auth-Mode AVPがMIP6_AUTH_MN_AAAを評価するように設定されている場合、このAVPはmiRメッセージに存在する必要があります。
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and contains the MN-HA shared secret (i.e., the session key) for the associated Mobile IPv6 MN-HA authentication option. When the Diameter server computes the session key, it is placed in this AVP. How the Diameter server computes the session key is not defined in this specification. The Session key derivation is deployment specific and needs to be defined in a respective deployment-specific system specification.
MIP-Session-Key AVP（AVPコード343）はタイプのオクテットストリングであり、関連するモバイルIPv6 MN-HA認証オプションのMN-HA共有秘密（つまり、セッションキー）が含まれています。直径サーバーがセッションキーを計算すると、このAVPに配置されます。Diameter Serverがセッションキーを計算する方法は、この仕様では定義されていません。セッションキーの派生は展開固有であり、それぞれの展開固有のシステム仕様で定義する必要があります。
This AVP is reused from [RFC4004].
このAVPは[RFC4004]から再利用されます。
The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and represents the period of time (in seconds) for which the session key (see Section 6.10) is valid. The associated session key MUST NOT be used if the lifetime has expired.
MIP-MSA-LIFETIME AVP（AVPコード367）は、符号なし32型であり、セッションキー（セクション6.10を参照）が有効な期間（秒）を表します。寿命が切れた場合、関連するセッションキーを使用しないでください。
This AVP is reused from [RFC4004].
このAVPは[RFC4004]から再利用されます。
The MIP-MN-HA-MSA AVP (AVP Code 492) is of type Grouped and contains the session-related information for use with the Mobile IPv6 Authentication Protocol.
MIP-MN-HA-MSA AVP（AVPコード492）はグループ化されたタイプで、モバイルIPv6認証プロトコルで使用するセッション関連情報が含まれています。
MIP-MN-HA-MSA ::= < AVP Header: 492 >
{ MIP-Session-Key }
{ MIP-MSA-Lifetime }
[ MIP-MN-HA-SPI ]
[ MIP-Algorithm-Type ]
[ MIP-Replay-Mode ]
* [ AVP ]
The MIP-MN-HA-SPI sub-AVP within the MIP-MN-HA-MSA grouped AVP identifies the security association required for the validation of the Mobile IPv6 MN-HA Authentication Option. The absence of the MIP-Replay-Mode AVP MUST be treated as no replay protection was selected.
MIP-MN-HA-MSAグループ化されたAVP内のMIP-MN-HA-SPIサブAVPは、モバイルIPv6 MN-HA認証オプションの検証に必要なセキュリティ協会を識別します。MIP-Replay-Mode AVPの欠如は、リプレイ保護が選択されていないため、扱う必要があります。
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and contains the Algorithm identifier for the associated Mobile IPv6 MN-HA Authentication Option. The Diameter server selects the algorithm type. Existing algorithm types are defined in [RFC4004] that also fulfill current RFC 4285 requirements. This AVP is reused from [RFC4004].
MIP-ALGORITHM-TYPE AVP（AVPコード345）は列挙されており、関連するモバイルIPv6 MN-HA認証オプションのアルゴリズム識別子が含まれています。直径サーバーは、アルゴリズムタイプを選択します。既存のアルゴリズムタイプは[RFC4004]で定義されており、現在のRFC 4285要件も満たしています。このAVPは[RFC4004]から再利用されます。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, and the Diameter server returns a valid MIP-MN-HA-MSA AVP in the MIA message, this AVP MUST be present inside the MIP-MN-HA-MSA AVP.
MIP6-Auth-Mode AVPがMIP6_AUTH_MN_AAAを値に設定し、DiameterサーバーがMIAメッセージで有効なMIP-MN-HA-MSA AVPを返す場合、このAVPはMIP-MN-HA-MSA AVP内に存在する必要があります。
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode of the HA for authenticating the mobile node. Out of all possible replay modes defined in [RFC4004], the following are supported by this specification:
MIP-Replay-Mode AVP（AVPコード346）は列挙されており、モバイルノードを認証するためのHAのリプレイモードが含まれています。[RFC4004]で定義されているすべての可能なリプレイモードのうち、以下はこの仕様でサポートされています。
1 None 2 Timestamp
1なし2タイムスタンプ
This AVP is reused from [RFC4004].
このAVPは[RFC4004]から再利用されます。
The MIP6-Feature-Vector AVP (AVP Code 124) is defined in [RFC5447]. However, this specification does not define any Mobile IPv6 split scenario bootstrapping specific capability flag.
MIP6-Feature-Vector AVP（AVPコード124）は[RFC5447]で定義されています。ただし、この仕様では、モバイルIPv6スプリットシナリオのブートストラップ特定の機能フラグを定義するものではありません。
The MIP-Timestamp AVP (AVP Code 490) is of type OctetString and contains an 8-octet timestamp value (i.e., 64-bit timestamp) from the Mobility message replay protection option, defined in [RFC4285]. The HA extracts this value from the received BU message, if available. The HA includes this AVP in the MIR message when the MN-AAA Mobility Message Authentication Option is available in the received BU and the Diameter server is expected to return the key material required for the calculation and validation of the Mobile IPv6 MN-HA Authentication Option (and the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA).
MIP-Timestamp AVP（AVPコード490）はタイプのオクテットストリングであり、[RFC4285]で定義されたモビリティメッセージリプレイ保護オプションの8オクテットのタイムスタンプ値（つまり、64ビットタイムスタンプ）が含まれています。HAは、利用可能な場合、受信したBUメッセージからこの値を抽出します。HAには、MIRメッセージにこのAVPが含まれています。MN-AAAモビリティメッセージ認証オプションが受信BUで利用可能であり、直径サーバーは、モバイルIPv6MN-HA認証オプションの計算と検証に必要な重要な資料を返すことが期待されます。（そしてMIP6-Auth-Mode AVPは、MIP6_AUTH_MN_AAAを値に設定されています）。
The QoS-Capability AVP is defined in [RFC5777] and contains a list of supported Quality of Service profiles.
QOSキャピールAVPは[RFC5777]で定義されており、サポートされているサービス品質プロファイルのリストが含まれています。
The QoS-Resources AVP is defined in [RFC5777] and provides QoS and packet filtering capabilities.
QOSリソースAVPは[RFC5777]で定義されており、QOSおよびパケットフィルタリング機能を提供します。
The Chargeable-User-Identity AVP (AVP Code 89) is of type OctetString and contains a unique temporary handle of the user. The Chargeable-User-Identity is defined in [RFC4372].
充電可能なユーザーアイデンティティAVP（AVPコード89）はタイプのオクテットストリングで、ユーザーの一意の一時的なハンドルが含まれています。充電可能なユーザーアイデンティティは[RFC4372]で定義されています。
The MIP6-Auth-Mode (AVP Code 494) is of type Enumerated and contains information of the used Mobile IPv6 Authentication Protocol mode. This specification defines only one value MIP6_AUTH_MN_AAA and the corresponding AAA interactions when MN-AAA security association is used to authenticate the Binding Update as described in [RFC4285]. When the MIP6-Auth_Mode AVP is set to the value of MIP6_AUTH_MN_AAA, the Auth-Request-Type AVP MUST be set to the value of AUTHORIZE_AUTHENTICATE.
MIP6-Auth-Mode（AVP Code 494）は列挙されており、使用されているモバイルIPv6認証プロトコルモードの情報が含まれています。この仕様では、MN-AAAセキュリティ協会を使用して[RFC4285]に記載されているようにバインディングアップデートを認証するために、MIP6_AUTH_MN_AAAと対応するAAA相互作用のみを定義します。MIP6-AUTH_MODE AVPがMIP6_AUTH_MN_AAAの値に設定されている場合、Auth-Request-Type AVPはauthorize_authenticateの値に設定する必要があります。
If the Diameter server does not support the Mobile IPv6 Authentication Protocol usage mode proposed by the HA, then the Diameter server MUST fail the authentication/authorization and MUST set the Result-Code AVP to the value of DIAMETER_ERROR_AUTH_MODE.
Diameter ServerがHAによって提案されたモバイルIPv6認証プロトコル使用モードをサポートしていない場合、Diameterサーバーは認証/承認に失敗し、結果コードAVPをdiame_error_auth_modeの値に設定する必要があります。
Diameter Mobile IPv6 applications, either MIP6I or MIP6A, are used in the case of the coupled account model. Diameter Mobile IPv4 application [RFC4004] accounting AVPs are reused in this document. The following AVPs SHOULD be included in the accounting request message:
直径モバイルIPv6アプリケーションは、MIP6IまたはMIP6Aのいずれかが、結合アカウントモデルの場合に使用されます。直径モバイルIPv4アプリケーション[RFC4004]アカウンティングAVPは、このドキュメントで再利用されています。次のAVPは、会計リクエストメッセージに含める必要があります。
o Accounting-Input-Octets: Number of octets in IP packets received from the mobile node.
o アカウンティング入力オクテット：モバイルノードから受信したIPパケットのオクテット数。
o Accounting-Output-Octets: Number of octets in IP packets sent by the mobile node.
o 会計出力オクテット：モバイルノードから送信されたIPパケットのオクテット数。
o Accounting-Input-Packets: Number of IP packets received from the mobile node.
o アカウンティング入力パケット：モバイルノードから受信したIPパケットの数。
o Accounting-Output-Packets: Number of IP packets sent by the mobile node.
o 会計出力パケット：モバイルノードから送信されるIPパケットの数。
o Acct-Multi-Session-Id: Used to link together multiple related accounting sessions, where each session would have a unique Session-Id, but the same Acct-Multi-Session-Id AVP.
o ACCT-Multi-Session-ID：複数の関連する会計セッションをリンクするために使用されます。各セッションには一意のセッションIDがありますが、同じACCT-Multi-Session-ID AVPがあります。
o Acct-Session-Time: Indicates the length of the current session in seconds.
o ACCTセッションタイム：現在のセッションの長さを秒単位で示します。
o MIP6-Feature-Vector: The supported features for this mobility service session.
o MIP6-Feature-Vector：このモビリティサービスセッションのサポートされている機能。
o MIP-Mobile-Node-Address: The home address of the mobile node.
o MIP-Mobile-Node-Address：モバイルノードのホームアドレス。
o MIP-Agent-Info: The current home agent of the mobile node.
o MIP-Agent-INFO：モバイルノードの現在のホームエージェント。
o Chargeable-User-Identity: The unique temporary identity of the user. This AVP MUST be included if it is available in the home agent.
o 課金可能なユーザーアイデンティティ：ユーザーのユニークな一時的なアイデンティティ。このAVPは、ホームエージェントで利用できる場合は含める必要があります。
o Service-Selection: Currently selected mobility service.
o サービス選択：現在選択されているモビリティサービス。
o QoS-Resources: Assigned Quality-of-Service (QoS) resources for the mobile node.
o QOS-Resources：モバイルノードに割り当てられたサービス品質（QOS）リソース。
o QoS-Capability: The QoS capability related to the assigned QoS-Resources.
o QOSの能力：割り当てられたQoSリソースに関連するQoS機能。
o MIP-Careof-Address: The current care-of address of the mobile node.
o MIP-Careof-Address：モバイルノードの現在のケアアドレス。
This section defines new Result-Code [RFC3588] values that MUST be supported by all Diameter implementations that conform to this specification.
このセクションでは、この仕様に準拠するすべての直径の実装でサポートする必要がある新しい結果コード[RFC3588]値を定義します。
Errors that fall within the Success category are used to inform a peer that a request has been successfully completed.
成功カテゴリ内にあるエラーは、リクエストが正常に完了したことをピアに通知するために使用されます。
DIAMETER_SUCCESS_RELOCATE_HA (Status Code 2009)
diameter_success_relocate_ha（ステータスコード2009）
This result code is used by the Diameter server to inform the HA that the MN MUST be switched to another HA.
この結果コードは、直径サーバーによって使用され、MNを別のHAに切り替える必要があることをHAに通知します。
Errors that fall within the Permanent Failures category are used to inform the peer that the request failed and SHOULD NOT be attempted again.
永続的な障害カテゴリ内にあるエラーは、リクエストが失敗し、再度試行すべきではないことをピアに通知するために使用されます。
DIAMETER_ERROR_MIP6_AUTH_MODE (Status Code 5041)
diameter_error_mip6_auth_mode（ステータスコード5041）
This error code is used by the Diameter server to inform the peer that the requested Mobile IPv6 Authentication Protocol usage mode is not supported.
このエラーコードは、Diameter Serverによって使用され、要求されたモバイルIPv6認証プロトコル使用モードがサポートされていないことをピアに通知します。
The following tables present the AVPs defined in this document and their occurrences in Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not represented in this table.
次のテーブルは、このドキュメントで定義されているAVPと、直径メッセージの発生を示しています。グループ化されたAVP内にのみ存在できるAVPは、この表には表されないことに注意してください。
The tables use the following symbols:
テーブルは次のシンボルを使用します。
0:
0：
The AVP MUST NOT be present in the message.
AVPがメッセージに存在してはなりません。
0+:
0：
Zero or more instances of the AVP MAY be present in the message.
AVPのゼロ以上のインスタンスがメッセージに存在する場合があります。
0-1:
0-1：
Zero or one instance of the AVP MAY be present in the message.
AVPのゼロまたは1つのインスタンスがメッセージに存在する場合があります。
1:
1：
One instance of the AVP MUST be present in the message.
AVPの1つのインスタンスがメッセージに存在する必要があります。
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
AVP Name | DER | DEA | MIR | MIA |
-------------------------------|-----+-----+-----+-----+
MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 1-2 | 0-2 | 1-2 | 0-2 |
MIP-MN-AAA-SPI | 0 | 0 | 0-1 | 0 |
MIP-MN-HA-SPI | 0 | 0 | 0-1 | 0 |
MIP6-Agent-Info | 1 | 0-1 | 1 | 0-1 |
MIP-Careof-Address | 0 | 0 | 0-1 | 0 |
MIP-Authenticator | 0 | 0 | 0-1 | 0 |
MIP-MAC-Mobility-Data | 0 | 0 | 0-1 | 0 |
MIP-MSA-Lifetime | 0 | 0 | 0 | 1 |
MIP-MN-HA-MSA | 0 | 0 | 0 | 0-1 |
MIP-Timestamp | 0 | 0 | 0-1 | 0-1 |
User-Name | 0-1 | 0-1 | 1 | 0-1 |
Service-Selection | 0-1 | 0-1 | 0-1 | 0-1 |
QoS-Resources | 0+ | 0+ | 0+ | 0+ |
QoS-Capability | 0-1 | 0 | 0-1 | 0 |
Chargeable-User-Identity | 0-1 | 0-1 | 0-1 | 0-1 |
MIP6-Auth-Mode | 0 | 0 | 1 | 0 |
+-----+-----+-----+-----+
The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages, as defined in [RFC3588].
このセクションの表は、[RFC3588]で定義されているように、このドキュメントで定義されているAVPが会計メッセージに存在することを表すために使用されます。
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 0-1 | 0-1 |
Accounting-Input-Packets | 0-1 | 0-1 |
Accounting-Output-Octets | 0-1 | 0-1 |
Accounting-Output-Packets | 0-1 | 0-1 |
Acct-Multi-Session-Id | 0-1 | 0-1 |
Acct-Session-Time | 0-1 | 0-1 |
MIP6-Feature-Vector | 0-1 | 0-1 |
MIP6-Agent-Info | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 0-2 | 0-2 |
Event-Timestamp | 0-1 | 0 |
MIP-Careof-Address | 0-1 | 0 |
Service-Selection | 0-1 | 0 |
QoS-Capability | 0+ | 0+ |
QoS-Resources | 0+ | 0+ |
Chargeable-User-Identity | 0-1 | 0 |
-------------------------------------|------+------+
This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA.
このセクションには、この仕様で作成されたか、IANAが管理する既存の名前空間に値を割り当てた名前空間が含まれています。
IANA has allocated a command code value for the following new command from the Command Code namespace defined in [RFC3588]. See Section 5 for the assignment of the namespace in this specification.
IANAは、[RFC3588]で定義されているコマンドコード名空間から次の新しいコマンドにコマンドコード値を割り当てました。この仕様の名前空間の割り当てについては、セクション5を参照してください。
Command Code | Value
-----------------------------------+------
MIP6-Request/Answer (MIR/MIA) | 325
IANA has registered the following new AVPs from the AVP Code namespace defined in [RFC3588].
IANAは、[RFC3588]で定義されているAVPコード名空間から次の新しいAVPを登録しています。
o MIP-Careof-Address o MIP-Authenticator
o mip-careof-address o mip-authenticator
o MIP-MAC-Mobility-Data
o MIP-MAC-Mobility-Data
o MIP-Timestamp
o MIP-TIMESTAMP
o MIP-MN-HA-SPI
o mip-mn-ha-spi
o MIP-MN-HA-MSA
o MIP-MN-HA-MSA
o Service-Selection
o サービス選択
o MIP6-Auth-Mode
o mip6-auth-mode
The AVPs are defined in Section 6.
AVPはセクション6で定義されています。
IANA has allocated new values to the Result-Code AVP (AVP Code 268) namespace defined in [RFC3588]. See Section 7 for the assignment of the namespace in this specification.
IANAは、[RFC3588]で定義されている結果コードAVP（AVPコード268）の名前空間に新しい値を割り当てました。この仕様の名前空間の割り当てについては、セクション7を参照してください。
Result-Code | Value
----------------------------------------------+------
DIAMETER_SUCCESS_RELOCATE_HA | 2009
DIAMETER_ERROR_MIP6_AUTH_MODE | 5041
IANA has allocated two new values "Diameter Mobile IPv6 IKE" and "Diameter Mobile IPv6 Auth" from the Application Identifier namespace defined in [RFC3588].
IANAは、[RFC3588]で定義されたアプリケーション識別子名空間から「直径モバイルIPv6 IKE」と「直径モバイルIPv6 AUTH」2つの新しい値を割り当てました。
Application Identifier | Value
-----------------------------------+------
Diameter Mobile IPv6 IKE (MIP6I) | 7
Diameter Mobile IPv6 Auth (MIP6A) | 8
IANA has created a new registry, "MIP6 Authentication Mode Registry",
for use with the enumerated MIP6-Auth-Mode AVP. The registry
initially contains the following value:
Token | Value | Description
---------------------------------------------+----------+------------
MIP6_AUTH_MN_AAA | 1 | RFC 5778
Allocation of new values follow the example policies described in [RFC5226]. New values for the MIP6-Auth-Mode AVP will be assigned based on the "Specification Required" policy. The value 0 (zero) is reserved, and the maximum value is 4294967295 (i.e., 2^32-1).
新しい値の割り当ては、[RFC5226]で説明されているポリシーの例に従います。MIP6-Auth-Mode AVPの新しい値は、「必要な仕様」ポリシーに基づいて割り当てられます。値0（ゼロ）は予約されており、最大値は4294967295（つまり、2^32-1）です。
The security considerations for the Diameter interaction required to accomplish the split scenario are described in [RFC5026]. Additionally, the security considerations of the Diameter base protocol [RFC3588], and Diameter EAP application [RFC4072] are applicable to this document.
分割シナリオを達成するために必要な直径相互作用のセキュリティ上の考慮事項は、[RFC5026]で説明されています。さらに、直径ベースプロトコル[RFC3588]および直径EAPアプリケーション[RFC4072]のセキュリティに関する考慮事項は、このドキュメントに適用できます。
The Diameter messages may be transported between the HA and the Diameter server via one or more AAA brokers or Diameter agents. In this case, the HA to the Diameter server AAA communication relies on the security properties of the intermediating AAA inter-connection networks, AAA brokers, and Diameter agents (such as proxies).
直径メッセージは、1つ以上のAAAブローカーまたは直径エージェントを介して、HAと直径サーバーの間で輸送される場合があります。この場合、HAからDiameter Server AAA通信は、中間化されたAAA間接続ネットワーク、AAAブローカー、および直径エージェント（プロキシなど）のセキュリティプロパティに依存しています。
In the case of the Authentication Protocol for Mobile IPv6 [RFC4285], this specification expects that the Diameter server derives the MN-HA Security Association and returns the associated session key (i.e., the MN-HA shared session key) to the HA. However, this specification does not define nor do other IETF specifications define how the Diameter server actually derives required keys. The details of the key derivation depends on the deployment where this specification is used and therefore the security properties of the system depend on how this is done.
モバイルIPv6 [RFC4285]の認証プロトコルの場合、この仕様は、直径サーバーがMN-HAセキュリティ協会を導出し、関連するセッションキー（つまり、MN-HA共有セッションキー）をHAに返すことを期待しています。ただし、この仕様では、他のIETF仕様を定義するものではなく、Diameterサーバーが実際に必要なキーを導出する方法を定義していません。キー派生の詳細は、この仕様が使用される展開に依存し、したがってシステムのセキュリティプロパティはこれの行為によって異なります。
The authors would like to thank Jari Arkko, Tolga Asversen, Pasi Eronen, Santiago Zapata Hernandez, Anders Kristensen, Avi Lior, John Loughney, Ahmad Muhanna, Behcet Sarikaya, Basavaraj Patil, Vijay Devarapalli, Lionel Morand, Domagoj Premec, Semyon Mizikovsky, and Yoshihiro Ohba for all the useful discussions. Ahmad Muhanna provided a detailed review of the document in August 2007. Pasi Eronen provided detailed comments and text proposals during the IESG review that helped to improved this document greatly.
著者は、Jari Arkko、Tolga Asversen、Pasi Eronen、Santiago Zapata Hernandez、Anders Kristensen、Avi Lior、John Loughney、Ahmad Muhannaに感謝したいと思います。すべての有用な議論のためにヨシヒロ・オバ。Ahmad Muhannaは、2007年8月に文書の詳細なレビューを提供しました。PasiEronenは、IESGレビュー中に詳細なコメントとテキスト提案を提供し、このドキュメントを大幅に改善するのに役立ちました。
We would also like to thank our Area Director, Dan Romascanu, for his support.
また、エリアディレクターのダンロマスカヌに感謝します。
Hannes Tschofenig would like to thank the European Commission support in the co-funding of the ENABLE project, where this work is partly being developed.
Hannes Tschofenigは、この作業が部分的に開発されているEnableプロジェクトの共同資産における欧州委員会の支援に感謝したいと思います。
Julien Bournelle would like to thank GET/INT since he began this work while he was under their employ.
ジュリアン・ボーンレルは、彼が彼らの雇用中にこの仕事を始めたので、Get/intに感謝したいと思います。
Madjid Nakhjiri would like to thank Huawei USA as most of his contributions to this document were possible while he was under their employ.
Madjid Nakhjiriは、この文書への貢献のほとんどが彼らの雇用中に可能であったため、Huawei USAに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T。、およびP. McCann、「直径モバイルIPv4アプリケーション」、RFC 4004、2005年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（EAP）アプリケーション」、RFC 4072、2005年8月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6（MIPV6）のモバイルノード識別子オプション」、RFC 4283、2005年11月。
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[RFC4285] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6の認証プロトコル」、RFC 4285、2006年1月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
[RFC4372] Adrangi、F.、Lior、A.、Korhonen、J。、およびJ. Loughney、「chargeable user Identity」、RFC 4372、2006年1月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V。およびF. Dupont、「IKEV2および改訂されたIPSECアーキテクチャによるモバイルIPv6操作」、RFC 4877、2007年4月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026] Giaretta、G.、Kempf、J。、およびV. Devarapalli、「分割シナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008.
[RFC5142] Haley、B.、Devarapalli、V.、Deng、H。、およびJ. Kempf、「Mobility Header Home Agent Switch Message」、RFC 5142、2008年1月。
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC5149] Korhonen、J.、Nilsson、U。、およびV. Devarapalli、「Mobile IPv6のサービス選択」、RFC 5149、2008年2月。
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009.
[RFC5447] Korhonen、J.、Bournelle、J.、Tschofenig、H.、Perkins、C。、およびK. Chowdhury、「Diameter Mobile IPv6：Network Access Server to Diameter Server Interactionのサポート」、RFC 5447、2009年2月。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010.
[RFC5777] Korhonen、J.、Tschofenig、H.、Arumaithurai、M.、Jones、M.、Ed。、およびA. Lior、「直径の交通分類とサービス品質（QoS）属性」、RFC 5777、2月2010年。
[DIME-APP] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. Loughney, "Diameter Applications Design Guidelines", Work in Progress, July 2009.
[Dime-App] Fajardo、V.、Asveren、T.、Tschofenig、H.、McGregor、G。、およびJ. Loughney、「Diameter Applications Design Guidelines」、2009年7月の作業。
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[RFC4640] Patel、A。およびG. Giaretta、「ブートストラップモバイルIPv6（MIPV6）の問題声明」、RFC 4640、2006年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555] Soliman、H。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC5637] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. Lopez, "Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6", RFC 5637, September 2009.
[RFC5637] Giaretta、G.、Guardini、I.、Demaria、E.、Bournelle、J。、およびR. Lopez、「モバイルIPv6の認証、承認、および会計（AAA）目標」、RFC 5637、2009年9月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Jouni Korhonen（編集者）Nokia Siemens Networks Linnoitustie 6 Espoo Fin-02600フィンランド
EMail: jouni.nospam@gmail.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo Fin-02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Julien Bournelle Orange Labs 38-4O rue du general Leclerc Issy-Les-Moulineaux 92794 France
Julien Bournelle Orange Labs 38-4o Rue du General Leclerc Issy-Les-Moulineaux 92794 France
EMail: julien.bournelle@orange-ftgroup.com
Gerardo Giaretta Qualcomm 5775 Morehouse Dr San Diego, CA 92121 USA
ジェラルドジアレッタクアルコム5775モアハウス博士サンディエゴ、カリフォルニア92121アメリカ
EMail: gerardo.giaretta@gmail.com
Madjid Nakhjiri Motorola USA
Madjid Nakhjiri Motorola USA
EMail: madjid.nakhjiri@motorola.com