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
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の展開は、ホームエージェントとモバイルサービスプロバイダーのDiameterサーバ間の相互作用に基づいて動的に業務をブートストラップすることができます。この文書では、モバイルIPホームエージェントとDiameterサーバ間の相互作用を指定します。
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.
モバイルノードは、拡張認証プロトコルとインターネット鍵交換v2プロトコルを使用して、またはモバイルIPv6認証プロトコルを使用して認証する場合は、この文書では、Diameterサーバ通信にホームエージェントを定義します。認証および承認に加えて、モバイル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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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セキュリティアソシエーション（SA）と暗号化材料の確立を必要とするかもしれません。代替的に、登録プロセスは、そのHAとのIPsec SAを確立することなく、MNのIPv6でのモビリティを可能にするモビリティメッセージ認証オプションを使用して固定することができます。ホームアドレスの収集、HAアドレス、および鍵材料を提供することが一般的にモバイルIPv6のブートストラップの問題[RFC4640]と呼ばれています。本明細書の目的は、HAおよび認証、許可、アカウンティング（AAA）サーバとの間の相互作用のためのDiameterサポートを提供することです。この仕様は、分割シナリオにおけるブートストラップの問題のために[RFC5637]で定義された要件[RFC5026]を満たし、また、モバイルIPv6 [RFC4285]のための認証プロトコルのためのDiameterサポートを指定します。本明細書で定義された直径の支持体はまた、デュアルスタックモバイル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.
モビリティ・サービス・プロバイダ（MSP）の観点から、MNが認証され、モバイルIPv6サービスを利用する権限を与え、そしてそれらを占めているされていることを確認することが重要です。 MNは、認証および承認された場合にのみMSPは、Mobile IPv6パラメータのブートストラップを認めていません。このように、モバイルIPv6の登録を処理する前に、HAは、MNの身元を確認するために、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の身元を検証する必要があります。新しい直径モバイルIPv6アプリケーションをサポートするDiameterクライアントとして、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認可決定を行うために設計された新しいDiameterアプリケーションを使用することにより達成されます。この文書では、必要な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サービスを終了するためにDiameterサーバまたは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は、モバイルIPv6 [RFC4285]にIPsecまたは認証プロトコルを使用して、すなわち、二つの異なるメカニズムを使用して保護することができます。これら二つのアプローチのために、いくつかの異なる認証及び鍵交換ソリューションが利用可能です。 IPsecはシグナリングメッセージをモバイルIPv6を保護するために使用された場合は、インターネットキー交換V2（IKEv2のは）のIPsec SAの設定のために[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を認証するために別の資格情報および方法を使用する能力は、（Diameterクライアントとして作用する）HA及びDiameterサーバとの間のAAA相互作用に影響を与えます。この仕様は、次のMNの認証方式にのみ限定されます。
o IKEv2 usage with EAP
EAPとO IKEv2の使用状況
o Mobile IPv6 Authentication Protocol
モバイルIPv6認証プロトコルO
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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アプリケーションと、それぞれのアプリケーション識別子を定義しています。
Diameter Mobile IPv6 IKE (MIP6I) 7 Diameter Mobile IPv6 Auth (MIP6A) 8
直径モバイルIPv6 IKE（MIP6I）7直径モバイルIPv6認証（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.
MNが認証とのIKEv2を使用して許可された場合にMIP6Iアプリケーション識別子が使用されます。 MNが認証及びモバイルIPv6認証プロトコルを使用して許可された場合にMIP6Aアプリケーション識別子が使用されます。
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アプリケーション識別子のいずれかを使用します。 Diameter基本会計アプリケーション識別子（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を認証することができます。 [RFC4072]で定義されるようにEAPは、IKEv2の直径EAPアプリケーションロジックおよび手順を使用した場合、再利用されます。彼らは、セクション2.16および[RFC4306]のセクション5で述べたようにman-in-the-middle攻撃の数を受けているとして共有キーを確立していないEAPメソッドを使用するべきではありません。モバイル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]で定義された規則を使用します。同様に、ホームエージェントとDiameterサーバとの間の通信は、[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：モバイルIPv6ブートストラップのIKEv2およびEAPを使用し
The MN and the HA start the interaction with an IKE_SA_INIT exchange.
MNとHAは、IKE_SA_INIT交換との対話を開始します。
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]).
この段階では、暗号化アルゴリズムがネゴシエートされ、およびノンスおよびDiffie-Hellmanパラメータが交換されます。メッセージは、（3）IKE_AUTHフェーズを開始します。この第二段階では、前のメッセージを認証アイデンティティと証明書を交換し、そして最初のCHILD_SAを確立します。 （IKEv2のレスポンダとして機能する）相互MN（IKEv2のイニシエータとして作用する）とHAを認証するために使用されます。ユーザー/ MNのアイデンティティはのIDIフィールドで提供されます。 MNは、（3）（[RFC4306]のセクション2.16を参照）、その意欲がメッセージにAUTHフィールドを省略することによりEAPを介して認証することを示しています。
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).
メッセージにCFG_REQUESTペイロードを使用して、認証プロセスの一環として、MNはホームアドレスまたはホームプレフィックスを要求することができるか、1（参照[RFC4877]）提案（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フィールドを抽出し、認証ダイアメータサーバに向かって直径-EAP-要求（DER）メッセージ（4）を送信します。 EAP-ペイロード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サーバ/ EAPサーバにルーティングされます。ダイアメータサーバは、EAPメソッドを選択し、直径-EAP-回答（DEA）メッセージで応答します。選択されたEAPメソッドの種類に応じて、DER及びDEAメッセージの数は、MNとDiameterサーバ/ 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メッセージはホームアドレスまたはホームプレフィックスが含まれています。後者の場合には、CREATE_CHILD_SA交換はモバイルIPv6シグナリングのためのIPsec 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のモバイルIPv6サービスのためやIPsec VPNアクセスサービスのために使用されている場合のIKEv2応答者が知らないかもしれないということです。ネットワークオペレータは、この制限を認識する必要があります。既にのIKEv2によってサポートされる一つの解決策は、従来のIPsec VPNゲートウェイとして又はHAとして動作するとき、異なる応答IDを使用することです。 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は、バインディング更新（BY）を受信した場合、最終的に、HAは、認証及びMANを許可します。 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は、MN、HA、及びモバイルIPv6認証プロトコルが使用されている登録時Diameterサーバ間のメッセージシーケンスを示します。 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を受信すると、Diameterサーバに送信するMIP6-Requestを開始します。順番にDiameterサーバはMIP6-回答で応答します。 HAは、MNにホームアドレスを割り当て、MIP-モバイルノードアドレス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は、後続の要求メッセージにユーザ名AVPにMN-NAI移動性オプションの値をコピーする必要があります。
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は、展開し、ローカルポリシーに応じて、任意の時点でDiameterサーバと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.
この仕様は、[RFC4285]で定義されるようにモバイルIPv6認証プロトコルが使用される場合には、MN-AAAオプションがBUに含まれ、Diameterサーバが正常にMNを認証した後に必要なセッションキーを計算することを想定しています。セッション鍵の計算は、この仕様の範囲外です。モバイル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
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].
ダイアメータサーバは、状態を維持することができるか、ステートレスであってもよいです。これは、認証、セッション状態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.
この仕様は、各SAが成功のIKEv2ネゴシエーションの結果として、MNとHAとの間に作成されるか、またはモバイルIPv6認証プロトコル交換一つのDiameterセッションに対応するという仮定をします。 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.
セッション終了リクエスト（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にDiameterサーバによって送信されます。これは、[RFC5637]に記載の要件のいずれかを満たします。 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は、サービス制御し、充電に必要な会計記録を収集Diameterクライアントとしてできる行為でなければなりません。 HAは、会計処理[RFC3588]で定義されるように（具体的には下記のコマンドコード）とアカウンティングセッションステートマシンをサポートしなければなりません。コマンドコードは、以下のサブセクションで提供され、会計目的のためにHA及びダイアメータサーバとの間で交換しました。
The Diameter application design guideline [DIME-APP] defines two separate models for accounting:
Diameterアプリケーション設計ガイドライン[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.
このモデルによれば、課金メッセージは、Diameterベース会計アプリケーション識別子（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アプリケーションの担当Diameterサーバを必要とする（例えば、適切なアカウンティングサーバに送信します）。
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.
上述したように、好ましい選択は、分割会計モデルを使用するので、アカウンティングメッセージのためのDiameterベースの会計アプリケーション識別子（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.
アカウンティング要求コマンド[RFC3588]はDiameterサーバとMNに関する会計情報を交換するためにDiameterサーバにHAによって送信されます。
The Accounting-Answer command [RFC3588] is sent by the Diameter server to the HA to acknowledge an Accounting-Request.
アカウンティング回答コマンド[RFC3588]はアカウンティング要求を確認するためにHAへDiameterサーバによって送信されます。
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].
直径-EAP-要求（DER）とDiameter-EAP-回答（DEA）のIKEv2およびEAPとモバイルIPv6を使用するため、この文書では、EAPアプリケーション[RFC4072]はコマンド直径を再利用します。この仕様は、モバイルIPv6分割シナリオブートストラップをサポートするためのAVPの数と既存のDERとDEAコマンドABNFsを拡張します。新しい追加のAVPおよびコマンドABNFsに対応する追加のほか、直径EAPアプリケーションのコマンドABNFsは変わりません。 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へのコマンドコードフィールドセットによって示される直径-EAP-要求（DER）メッセージ、及びR「」は、コマンドフラグフィールドに設定モバイルIPv6サービスの認証を開始するためにDiameterサーバにHAによって送信されるビットそして、承認手続き。直径ヘッダのアプリケーションIDフィールドは、Diameterモバイル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認証時のモビリティサービスのために許可されています。したがって、認証リクエストタイプ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」に設定コマンドコードフィールドによって示される直径-EAP-回答（DEA）メッセージは、コマンドフラグフィールドにビットクリア直径-EAP-要求（DER）メッセージに応答して送信されます。 Diameterメッセージヘッダ内のアプリケーション-IDフィールドは、Diameterモバイル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-モード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.
325へのコマンドコードフィールドセットによって示さMIP6-要求（MIR）、及びR「」は、コマンドフラグフィールドに設定された認証を要求するために、Diameterクライアントとして動作する、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は、認証およびモビリティサービスのために許可されている場合は、認証リクエスト型AVPは値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」に設定コマンドコードフィールドによって示さMIP6-回答（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].
それはMIR中に存在している場合はユーザー名AVPはMIAに含まれるかもしれません。結果 - コードAVPは[RFC3588]で定義された値に加えて、セクション7で定義された値のいずれかを含むかもしれません。
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-モバイルノードアドレス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アプリケーションのAVP
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は、セクション4.1と[RFC5777]の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認証アプリケーションのAVP
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は、セクション4.1と[RFC5777]の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をであり、MN-NAI移動性オプションから抽出されたネットワークアクセス識別子（NAI）を受信したBUメッセージに含ま含ま。あるいは、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メッセージにおいて利用可能な場合、本明細書の範囲では、値は、IDRのIKEv2ペイロードから抽出することができます。モバイル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メッセージに含まれるモビリティメッセージ認証オプションから抽出されたセキュリティパラメータインデックス（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モード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モードAVPはMIP6_AUTH_MN_AAAの値に設定さ、および直径サーバが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-モバイルノードアドレス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-モバイルノードアドレスAVPは、要求メッセージに指定されていないIPv6アドレス（0 :: 0）またはすべてゼロIPv4アドレス（0.0.0.0）が含まれている場合は、HAは、Diameterサーバは、ホームアドレスを割り当てることを期待しますその後の応答メッセージインチダイアメータサーバは、移動ノードにIPv6のみホームネットワークプレフィックスを割り当てた場合、MIP-モバイルノードアドレス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-エージェント情報AVP（AVPコード486）[RFC5447]のセクション4.2.1で定義され、HAのIPv6のまたはIPv4アドレス情報が含まれています。要求メッセージ内のHAアドレスは、Diameterサーバに向かって認証および許可手続きをトリガし、受信したBUメッセージと同じです。一つのユースケースは、動的に割り当てられるHAのDiameterサーバに通知するために、例えば、です。
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-エージェント情報AVPは、回答メッセージ内に存在し、その結果、コードAVPがDIAMETER_SUCCESS_RELOCATE_HAに設定され、その後、Diameterサーバは、それが使用して、例えば（MNに向けてHAスイッチ手続きを開始しなければならないことをHAに指示された場合[RFC5142]で定義された手順）。結果 - コードAVPが他の値に設定されている場合、HAは、MNに向けてHAスイッチ手順を開始すべきです。割り当てられたHAのアドレス情報がMIP6-エージェント情報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アドレス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-認証AVP（AVPコード488）はタイプOctetStringにあり、受信した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モード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-モビリティ・データAVP（AVPコード489）はタイプOctetStringにあり、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モード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-セッションキーAVP（AVPコード343）はタイプOctetStringにあるとMN-HAは、関連するモバイルIPv6 MN-HA認証オプションのための秘密（すなわち、セッションキー）を共有含まれています。 Diameterサーバがセッションキーを計算するとき、それはこのAVPに配置されます。 Diameterサーバは、セッション鍵は、この仕様で定義されていない計算方法。セッションキーの導出は、展開固有のものであり、それぞれの展開固有のシステム仕様で定義される必要があります。
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-生涯AVP（AVPコード367）はタイプUnsigned32にあり、セッション鍵は（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-リプレイモード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-アルゴリズムタイプAVP（AVPコード345）がタイプ列挙であり、関連するモバイルIPv6 MN-HA認証オプションのためのアルゴリズム識別子を含みます。 Diameterサーバは、アルゴリズムの種類を選択します。既存のアルゴリズムタイプは、現在のRFCに4285点の要件を満たす[RFC4004]で定義されています。この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モードAVPはMIP6_AUTH_MN_AAAの値に設定さ、および直径サーバが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-リプレイモードAVP（AVPコード346）がタイプ列挙であり、モバイルノードを認証するためのHAの再生モードを含んでいます。 [RFC4004]で定義されたすべての可能な再生モードのうち、以下は、本明細書によってサポートされています。
1 None
2 Timestamp
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-特徴ベクトル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-タイムスタンプAVP（AVPコード490）はタイプOctetStringにあり、[RFC4285]で定義されたモビリティメッセージリプレイ保護オプションから8オクテットのタイムスタンプ値（すなわち、64ビットのタイムスタンプ）を含みます。利用可能な場合、HAは、受信したBUメッセージからこの値を抽出します。 MN-AAAモビリティメッセージ認証オプションは、受信したBUで利用可能で、DiameterサーバがモバイルIPv6 MN-HA認証オプションの計算および妥当性確認に必要な鍵素材を返すことが予想される場合、HAは、MIRメッセージ内のこのAVPを含みます（とMIP6-AUTHモード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）はタイプOctetStringにあり、ユーザーの一意の一時ハンドルが含まれています。有料-ユーザ識別は、[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モード（AVPコード494）がタイプ列挙であり、使用されるモバイルIPv6認証プロトコルモードの情報が含まれています。この仕様は、MN-AAAセキュリティアソシエーションは、[RFC4285]に記載されているようにバインディング更新を認証するために使用される唯一の値MIP6_AUTH_MN_AAAと対応するAAA相互作用を定義します。 MIP6-Auth_Mode AVPはMIP6_AUTH_MN_AAAの値に設定されている場合、認証リクエストタイプ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サーバは、HAによって提案されたモバイルIPv6認証プロトコルの使用モードをサポートしていない場合は、Diameterサーバは、認証/認可が失敗しなければなりませんし、DIAMETER_ERROR_AUTH_MODEの値に結果-コードAVPを設定しなければなりません。
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：秒で、現在のセッションの長さを示します。
o MIP6-Feature-Vector: The supported features for this mobility service session.
O MIP6-特徴ベクトル：このモビリティサービスセッションのためにサポートしている機能。
o MIP-Mobile-Node-Address: The home address of the mobile node.
O MIP-モバイル・ノードアドレス：モバイルノードのホームアドレス。
o MIP-Agent-Info: The current home agent of the mobile node.
O MIP-エージェント情報：モバイルノードの現在のホームエージェント。
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-資源：モバイルノードのためのサービス品質（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-アドレス：モバイルノードの気付アドレスの現在。
This section defines new Result-Code [RFC3588] values that MUST be supported by all Diameter implementations that conform to this specification.
このセクションでは、この仕様に準拠するすべてのDiameter実装でサポートしなければならない新しい結果、コード[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に通知するためにDiameterサーバによって使用されます。
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.
このエラーコードは、要求されたモバイルIPv6認証プロトコルの使用モードがサポートされていないことをピアに通知するためにDiameterサーバによって使用されます。
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.
次の表は、このドキュメントとDiameterメッセージでの出現で定義されたAVPを提示します。唯一のグループ化されたAVPの中に存在することができるのAVPは、この表に示されていないことに留意されたいです。
The tables use the following symbols:
テーブルには、以下の記号を使用しています。
0:
０：
The AVP MUST NOT be present in the message.
AVPはメッセージ中に存在してはなりません。
0+:
０＋：
Zero or more instances of the AVP MAY be present in the message.
AVPのゼロ以上のインスタンスは、メッセージ中に存在してもよいです。
0-1:
０ー１：
Zero or one instance of the AVP MAY be present in the message.
AVPのゼロまたは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].
このセクションのテーブルは、この文書で定義されたのAVP表すために使用されている[RFC3588]で定義されるように、会計メッセージに存在することがあります。
+-------------+
| 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
MIP-認証〇〇MIP-Careof-住所
o MIP-MAC-Mobility-Data
O MIP-MAC-モビリティ - データ
o MIP-Timestamp
O MIP-タイムスタンプ
o MIP-MN-HA-SPI
MIP-MN-HA-SPIの
o MIP-MN-HA-MSA
Mbmenhmsa
o Service-Selection
Oサービス - セレクション
o MIP6-Auth-Mode
O MIP6-認証モード
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認証」二つの新しい値を割り当てました。
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:
IANAは、列挙MIP6-認証モードAVPで使用するために、新しいレジストリ、「MIP6認証モードレジストリ」を作成しました。レジストリは、最初に次の値が含まれています。
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-認証モード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).
Diameterメッセージは、一つ以上のAAAブローカーまたは直径剤を介してHA及びDiameterサーバ間で転送することができます。この場合には、ダイアメータサーバAAA通信のHAは、仲介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]のための認証プロトコルの場合には、本明細書は、Diameterサーバは、MN-HAセキュリティアソシエーションを導出し、HAに関連するセッション鍵（すなわち、MN-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.
著者はヤリArkko、トルガAsversen、パシEronen、サンティアゴサパタヘルナンデス、アンダース・クリステンセン、アビLIOR、ジョンLoughney、アフマドMuhanna、ベーチェットSarikaya、Basavarajパティル、ビジェイDevarapalli、ライオネル・モラン、Domagoj Premec、セミヨンMizikovsky、とに感謝したいと思いますすべての有用な議論のための義弘大場。アフマドMuhannaは、2007年8月パシEronenにおけるドキュメントの詳細なレビューを提供大幅に改善本書に助けIESGレビュー中に詳細なコメントやテキスト提案を提供します。
We would also like to thank our Area Director, Dan Romascanu, for his support.
我々はまた、彼のサポートのために私たちの地域ディレクター、ダンRomascanuを、感謝したいと思います。
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.
ハンネスTschofenigは、この研究の一部は開発されているENABLEプロジェクトの共同資金調達に欧州委員会の支援に感謝したいと思います。
Julien Bournelle would like to thank GET/INT since he began this work while he was under their employ.
彼はこの仕事を始めて以来、彼は彼らの採用の下にあったジュリアンBournelleは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.
このドキュメントへの貢献のほとんどが可能だったとして、彼は彼らの採用の下にあったマジドNakhjiriは、Huawei社は、米国に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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]カルフーン、P.、ヨハンソン、T.、パーキンス、C.、ヒラー、T.、およびP.マッキャン、 "直径モバイル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]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、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.、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル（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]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイル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]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6のための認証プロトコル"、RFC 4285、2006年1月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（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、 "有料ユーザーID"、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.デュポン、 "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.、ケンプ、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]ヘイリー、B.、Devarapalli、V.、鄧小平、H.、およびJ.ケンプ、 "モビリティヘッダホーム・エージェント・スイッチ・メッセージ"、RFC 5142、2008年1月。
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC5149] Korhonen、J.、ニルソン、U.、およびV. Devarapalli、 "モバイル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.、パーキンス、C.、およびK.チョードリ、 "直径モバイルIPv6：直径サーバの対話へのネットワーク・アクセス・サーバのサポート"、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.、ジョーンズ、M.、編、及びA. LIOR、RFC 5777年2月、 "トラフィック分類とサービス品質（QoS）は直径の属性" 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]ファハルド、V.、Asveren、T.、Tschofenig、H.、マクレガー、G.、およびJ. Loughney、 "Diameterアプリケーション設計ガイドライン"、進歩、2009年7月での作業。
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[RFC4640]パテル、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]ソリマン、H.、RFC 5555 "デュアルスタックホストとルータのためのモバイルIPv6のサポート"、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.ロペス、 "モバイルIPv6のための認証、許可、アカウンティング（AAA）ゴール"、RFC 5637、2009年9月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Jouni Korhonen（編集）、ノキアシーメンスネットワークスLinnoitustie 6 FIN-02600エスポーフィンランド
EMail: jouni.nospam@gmail.com
メールアドレス：jouni.nospam@gmail.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 FIN-02600エスポーフィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：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
ジュリアンBournelleオレンジLabsの38-4O RUE一般ルクレールイシレムリノー、フランス92794
EMail: julien.bournelle@orange-ftgroup.com
メールアドレス：julien.bournelle@orange-ftgroup.com
Gerardo Giaretta Qualcomm 5775 Morehouse Dr San Diego, CA 92121 USA
ヘラルドGiarettaクアルコム5775モアハウス博士サンディエゴ、CA 92121 USA
EMail: gerardo.giaretta@gmail.com
メールアドレス：gerardo.giaretta@gmail.com
Madjid Nakhjiri Motorola USA
マジドNakhjiriモトローラUSA
EMail: madjid.nakhjiri@motorola.com
メールアドレス：madjid.nakhjiri@motorola.com