[要約] RFC 4004は、Diameter Mobile IPv4アプリケーションに関する仕様を定義しています。このRFCの目的は、モバイルIPv4ネットワークでの認証、認可、および課金のためのDiameterプロトコルの使用を提案することです。
Network Working Group
Request for Comments: 4004 P. Calhoun
Category: Standards Track Cisco Systems, Inc.
T. Johansson
Bytemobile Inc
C. Perkins
Nokia Research Center
T. Hiller, Ed.
P. McCann
Lucent Technologies
August 2005
Diameter Mobile IPv4 Application
直径モバイルIPv4アプリケーション
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers.
このドキュメントは、直径サーバーがモバイルノードにレンダリングされたモバイルIPv4サービスの会計情報を認証、承認、収集できるようにする直径アプリケーションを指定します。ベースプロトコルのリアル間能力と組み合わせると、このアプリケーションにより、モバイルノードは外国サービスプロバイダーからサービスを受信できます。直径の会計メッセージは、外国人およびホームエージェントによって使用され、使用情報が直径サーバーに転送されます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Entities and Relationships. . . . . . . . . . . . . . . . 4
1.2. Mobility Security Associations. . . . . . . . . . . . . . 4
1.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Structure of the Document . . . . . . . . . . . . . . . . 7
2. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Scenarios and Message Flows . . . . . . . . . . . . . . . . . . 7
3.1. Inter-Realm Mobile IPv4 . . . . . . . . . . . . . . . . . 8
3.2. Allocation of Home Agent in Foreign Network . . . . . . .13
3.3. Co-located Mobile Node. . . . . . . . . . . . . . . . . .16
3.4. Key Distribution. . . . . . . . . . . . . . . . . . . . .18
4. Diameter Protocol Considerations. . . . . . . . . . . . . . . .20
4.1. Diameter Session Management . . . . . . . . . . . . . . .20
5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . .23
5.1. AA-Mobile-Node-Request. . . . . . . . . . . . . . . . . .23
5.2. AA-Mobile-Node-Answer . . . . . . . . . . . . . . . . . .25
5.3. Home-Agent-MIP-Request. . . . . . . . . . . . . . . . . .26
5.4. Home-Agent-MIP-Answer . . . . . . . . . . . . . . . . . .27
6. Result-Code AVP Values. . . . . . . . . . . . . . . . . . . . .27
6.1. Transient Failures. . . . . . . . . . . . . . . . . . . .28
6.2. Permanent Failures. . . . . . . . . . . . . . . . . . . .28
7. Mandatory AVPs. . . . . . . . . . . . . . . . . . . . . . . . .28
7.1. MIP-Reg-Request AVP . . . . . . . . . . . . . . . . . . .29
7.2. MIP-Reg-Reply AVP . . . . . . . . . . . . . . . . . . . .29
7.3. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . .30
7.4. MIP-Home-Agent-Address AVP. . . . . . . . . . . . . . . .30
7.5. MIP-Feature-Vector AVP. . . . . . . . . . . . . . . . . .30
7.6. MIP-MN-AAA-Auth AVP . . . . . . . . . . . . . . . . . . .32
7.7. MIP-FA-Challenge AVP. . . . . . . . . . . . . . . . . . .33
7.8. MIP-Filter-Rule AVP . . . . . . . . . . . . . . . . . . .33
7.9. MIP-Candidate-Home-Agent-Host . . . . . . . . . . . . . .33
7.10. MIP-Originating-Foreign-AAA AVP . . . . . . . . . . . . .33
7.11. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . . .33
8. Key Distribution . . . . . . . . . . . . . . . . . . . . . . .34
8.1. Authorization Lifetime vs. MIP Key Lifetime. . . . . . . .34
8.2. Nonce vs. Session Key. . . . . . . . . . . . . . . . . . .35
8.3. Distributing the Mobile-Home Session Key . . . . . . . . .35
8.4. Distributing the Mobile-Foreign Session Key. . . . . . . .36
8.5. Distributing the Foreign-Home Session Key. . . . . . . . .37
9. Key Distribution AVPs . . . . . . . . . . . . . . . . . . . . .38
9.1. MIP-FA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.2. MIP-FA-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.3. MIP-HA-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.4. MIP-HA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.5. MIP-MN-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.6. MIP-MN-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .41
9.7. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . .41
9.8. MIP-Algorithm-Type AVP. . . . . . . . . . . . . . . . . .41
9.9. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . .42
9.10. MIP-FA-to-MN-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.11. MIP-FA-to-HA-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.12. MIP-Nonce AVP. . . . . . . . . . . . . . . . . . .. . . .42
9.13. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . .. . . .42
9.14. MIP-HA-to-FA-SPI AVP . . . . . . . . . . . . . . .. . . .43
10. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . .43
10.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . .43
10.2. Accounting-Output-Octets AVP. . . . . . . . . . . . . . .43
10.3. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . .43
10.4. Accounting-Input-Packets AVP. . . . . . . . . . . . . . .43
10.5. Accounting-Output-Packets AVP . . . . . . . . . . . . . .43
10.6. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . .44
11. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . .44
11.1. Mobile IP Command AVP Table . . . . . . . . . . . . . . .44
11.2. Accounting AVP Table. . . . . . . . . . . . . . . . . . .46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .46
12.1. Command Codes . . . . . . . . . . . . . . . . . . . . . .46
12.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .46
12.3. Result-Code AVP Values. . . . . . . . . . . . . . . . . .46
12.4. MIP-Feature-Vector AVP Values . . . . . . . . . . . . . .47
12.5. MIP-Algorithm-Type AVP Values . . . . . . . . . . . . . .47
12.6. MIP-Replay-Mode AVP Values. . . . . . . . . . . . . . . .47
12.7. Application Identifier . . . . . . . . . . . . . . . . .47
13. Security Considerations . . . . . . . . . . . . . . . . . . . .47
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . .49
14.1. Normative References. . . . . . . . . . . . . . . . . . .49
14.2. Informative References. . . . . . . . . . . . . . . . . .50
15. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .51
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .51
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .53
Mobile IPv4 [MOBILEIP] allows a Mobile Node (MN) to change its point of attachment to the Internet while maintaining its fixed home address. Packets directed to the home address are intercepted by a Home Agent (HA), encapsulated in a tunnel, and forwarded to the MN at its current point of attachment. Optionally, a Foreign Agent (FA) may be deployed at this point of attachment, which can serve as the tunnel endpoint and may also provide access control for the visited network link. In this role, the FA has to authenticate each MN that may attach to it, whether the MN is from the same or a different administrative domain. The FA has to verify that the MN is authorized to attach and use resources in the foreign domain. Also, the FA must provide information to the home administrative domain about the resources used by the MN while it is attached in the foreign domain.
モバイルIPv4 [MobileIP]により、モバイルノード（MN）は、固定ホームアドレスを維持しながら、インターネットへの添付ポイントを変更できます。自宅の住所に向けられたパケットは、ホームエージェント（HA）によって傍受され、トンネルにカプセル化され、現在の添付ファイルでMNに転送されます。オプションで、外国人エージェント（FA）は、この添付ファイルの時点で展開される場合があります。これは、トンネルエンドポイントとして機能し、訪問されたネットワークリンクのアクセス制御を提供する場合があります。この役割では、FAは、MNが同じ管理ドメインであろうと、それに付着する可能性のある各MNを認証する必要があります。FAは、MNが外国ドメインにリソースを添付および使用することを許可されていることを確認する必要があります。また、FAは、外国ドメインに添付されている間にMNが使用するリソースに関する情報をホーム管理ドメインに提供する必要があります。
The Authentication, Authorization, and Accounting (AAA) requirements for Mobile IPv4 are described in detail in other documents [MIPREQ, CDMA2000]. This document specifies a Diameter application to meet these requirements. This application is not applicable to the Mobile IPv6 protocol.
モバイルIPv4の認証、承認、および会計（AAA）要件は、他のドキュメント[MIPREQ、CDMA2000]で詳細に説明されています。このドキュメントは、これらの要件を満たすための直径アプリケーションを指定します。このアプリケーションは、モバイルIPv6プロトコルには適用されません。
Message formats (e.g., as in section 5.1) are specified as lists of Attribute-Value Pairs (AVPs) using the syntax as described in RFC 2234 [ABNF]. This includes the use of the "*" symbol to denote zero or more occurrences of an AVP.
メッセージ形式（例：セクション5.1のように）は、RFC 2234 [ABNF]で説明されている構文を使用して、属性値ペア（AVP）のリストとして指定されています。これには、AVPのゼロ以上の発生を示す「*」記号の使用が含まれます。
Conventions Used in This Document
このドキュメントで使用されている規則
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 RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
The Diameter Mobile IPv4 Application supports the HA and FA in providing Mobile IPv4 service to MNs. Both the HA and FA act as Diameter clients. The MNs interact with the HA and FA by using only Mobile IPv4 and therefore do not implement Diameter.
直径モバイルIPv4アプリケーションは、MNSにモバイルIPv4サービスを提供する際にHAとFAをサポートします。HAとFAの両方が直径クライアントとして機能します。MNSは、モバイルIPv4のみを使用してHAおよびFAと相互作用するため、直径を実装しません。
The FA, when present, is always assumed to exist in the visited administrative domain. The HA may be statically or dynamically allocated to the MN in the home administrative domain or may be dynamically allocated to the MN in a visited administrative domain. The home domain contains a home AAA server (AAAH), and the visited domain contains a foreign AAA server (AAAF). When the MN is "at home" (present on its home network), the AAAH and AAAF may be the same.
FAは、存在する場合、訪問された管理ドメインに常に存在すると想定されています。HAは、Home管理ドメインのMNに静的または動的に割り当てられたり、訪問された管理ドメインでMNに動的に割り当てられたりする場合があります。ホームドメインにはホームAAAサーバー（AAAH）が含まれており、訪問ドメインには外国のAAAサーバー（AAAF）が含まれています。MNが「自宅で」（ホームネットワークに存在する）場合、AAAHとAAAFは同じかもしれません。
The base Mobile IPv4 protocol [MOBILEIP] assumes the existence of a Mobility Security Association (MSA) between the MN and HA (MN-HA MSA). The MN-HA MSA is used to authenticate, by using a keyed hash-style algorithm, the Mobile IP Registration Request that is sent from the MN to the HA. It is important to authenticate Registration Requests, as they inform the HA about the MN's current Care-of-Address, which is the destination for tunneled packets from the home network. Without authentication, malicious attackers would be able to redirect packets to anywhere on the Internet. The MSA comprises an agreement on a Security Parameters Index (SPI, a 32-bit number) that will be used to refer to the MSA, an algorithm that will be used to compute keyed hashes over messages, and a shared secret key. To enable authentication of a message, the sender appends a Mobile IP Authentication Extension that contains the SPI and the result of running the keyed hash over the entire previous contents of the message. The recipient checks the Authentication Extension by looking up the MSA based on the SPI, re-computing the keyed hash, and verifying that the result is equal to the contents of the received Authentication Extension.
ベースモバイルIPv4プロトコル[MobileIP]は、MNとHA（MN-HA MSA）の間にモビリティセキュリティ協会（MSA）の存在を想定しています。MN-HA MSAは、キー付きハッシュスタイルのアルゴリズムを使用して、MNからHAに送信されるモバイルIP登録要求を使用することにより、認証に使用されます。HAにMNの現在のアドレスドレスのケアについて知らせるため、登録要求を認証することが重要です。認証がなければ、悪意のある攻撃者はインターネット上のどこにでもパケットをリダイレクトできます。MSAは、MSAを参照するために使用されるセキュリティパラメーターインデックス（SPI、32ビット番号）の契約、メッセージに対するキー付きハッシュを計算するために使用されるアルゴリズム、および共有秘密キーを含む契約を含みます。メッセージの認証を有効にするために、送信者は、SPIを含むモバイルIP認証拡張機能と、メッセージの以前のコンテンツ全体でキー付きハッシュを実行した結果を追加します。受信者は、SPIに基づいてMSAを調べ、キー付きハッシュを再計算し、結果が受信された認証拡張の内容に等しいことを確認することにより、認証拡張機能をチェックします。
The base Mobile IPv4 protocol also supports an optional MSA between the MN and FA (MN-FA MSA). If available, the MN-FA MSA is used by the FA to authenticate each Registration Request passing through it on the way to the HA. Although not critical to the operation of the base protocol, the MN-FA MSA is useful when the FA has to know the authenticity of a Registration Request; e.g., when it will be generating accounting records for a session. The MN-FA MSA may also be useful in future work related to handoff optimization.
ベースモバイルIPv4プロトコルは、MNとFA（MN-FA MSA）の間のオプションのMSAもサポートしています。利用可能な場合、MN-FA MSAはFAによって使用され、HAに向かう途中でそれを通過する各登録要求を認証します。基本プロトコルの操作には重要ではありませんが、MN-FA MSAは、FAが登録要求の信頼性を知る必要がある場合に役立ちます。たとえば、セッションの会計記録を生成する場合。MN-FA MSAは、ハンドオフの最適化に関連する将来の作業にも役立つ可能性があります。
Similarly, Mobile IPv4 supports an optional MSA between the FA and HA (FA-HA MSA). The FA-HA MSA is useful for authenticating messages between the FA and HA, such as when the HA seeks to inform the FA that it has revoked a Mobile IP registration.
同様に、モバイルIPv4は、FAとHA（FA-HA MSA）の間のオプションのMSAをサポートしています。FA-HA MSAは、FAとHAの間でメッセージを認証するのに役立ちます。これは、HAがFAにモバイルIP登録を取り消したことを通知しようとするときなどです。
Note that configuration of MSAs that involve FAs is substantially more difficult than configuring the one between the MN and HA, because the MN and HA are often in the same administrative domain and the MN will retain the same HA for long periods of time. In contrast, the MN is likely to encounter many FAs over time and may often find itself in foreign administrative domains.
FAを含むMSAの構成は、MNとHAの間で構成されたものを構成するよりも実質的に困難であることに注意してください。MNとHAは多くの場合同じ管理ドメインにあり、MNは長期間同じHAを保持することが多いためです。対照的に、MNは時間の経過とともに多くのFAに遭遇する可能性が高く、多くの場合、外国の管理領域に自分自身を見つける可能性があります。
The base Mobile IPv4 protocol assumes that MNs are identified by their static home IP addresses and that all MSAs are statically preconfigured. The Diameter Mobile IPv4 application, together with extensions [MIPNAI, MIPCHAL, MIPKEYS, AAANAI] to the base Mobile IPv4 protocol, allows an MN to be dynamically assigned a home address and/or home agent when it attaches to the Internet. This set of specifications also supports the dynamic configuration of the MN-HA, MN-FA, and FA-HA MSAs. The dynamic configuration of these relationships is important to support deployments in which the MN can attach to a visited network without having a pre-established relationship with it.
ベースモバイルIPv4プロトコルは、MNSが静的ホームIPアドレスによって識別され、すべてのMSAが静的に事前に設定されていると想定しています。直径のモバイルIPv4アプリケーションは、拡張機能[Mipnai、Mipchal、Mipkeys、aaanai]とともに、モバイルIPv4プロトコルに合わせて、インターネットに接続するとMNをホームアドレスおよび/またはホームエージェントを動的に割り当てることができます。この一連の仕様は、MN-HA、MN-FA、およびFA-HA MSAの動的な構成もサポートしています。これらの関係の動的な構成は、MNが事前に確立された関係を持たずに訪問したネットワークに接続できる展開をサポートするために重要です。
Initially, the MN is assumed to have a long-term AAA security association only with the AAAH. This security association is indexed by the MN's NAI, and, like the MSAs, comprises an agreement on a SPI, an algorithm, and a shared secret key. The MN enters a visited network and requests service from some FA by sending a Mobile IPv4 Registration Request. The FA contacts an AAAF in its own administrative domain to authenticate and authorize the request for service. The AAAF and AAAH may establish a Diameter session directly with each other, such as via a Diameter Redirect, or may pass messages via a network of Diameter proxies. Where the AAAF and AAAH route messages to each other through proxies, rather than a direct connection, transitive trust is assumed. MNs can include their Network Access Identifier (NAI) in a Mobile IPv4 Registration Request [MIPNAI], which serves in place of the home address to identify the MN. The NAI is used to route Diameter messages toward the correct AAAH. This use of the NAI is consistent with the roaming model defined by the ROAMOPS Working Group [EVALROAM, RFC2607].
当初、MNはAAAHとのみ長期的なAAAセキュリティ協会を持っていると想定されています。このセキュリティ協会はMNのNAIによってインデックス化されており、MSAと同様に、SPI、アルゴリズム、および共有秘密キーに関する合意を含んでいます。MNは訪問されたネットワークに入り、モバイルIPv4登録リクエストを送信することにより、FAからサービスをリクエストします。FAは、サービスのリクエストを認証および承認するために、独自の管理ドメインでAAAFに連絡します。AAAFとAAAHは、直径リダイレクトを介して直接直接的に直接セッションを確立する場合があります。また、直径プロキシのネットワークを介してメッセージを渡す場合があります。AAAFとAAAHが直接的な接続ではなく、プロキシを通じて互いに互いにルーティングする場合、推移的な信頼が想定されます。MNSには、MNを識別するために自宅の住所の代わりにサービスを提供するモバイルIPv4登録要求[MIPNAI]にネットワークアクセス識別子（NAI）を含めることができます。NAIは、正しいAAAHに向かって直径メッセージをルーティングするために使用されます。NAIのこの使用は、Roamopsワーキンググループ[EvalRoam、RFC2607]によって定義されたローミングモデルと一致しています。
The AAAH can authenticate the Registration Request with the use of the MN-AAA security association [MIPCHAL]. If authentication is successful, the AAAH then generates and distributes MSAs to the MN, HA, and FA. For each of the MSA pairs that involve the MN (i.e., MN-HA/HA-MN MSAs and MN-FA/FA-MN MSAs), the AAAH generates a nonce and then hashes it together with the MN-AAA shared key to derive the session key for the MSA pair. The nonces are sent to the HA that includes them in the Registration Reply, which enables the MN to derive the same keys [MIPKEYS]. At the same time, the AAAH must distribute the MN-HA/HA-MN MSAs and the FA-HA/HA-FA MSAs to the HA and must distribute the MN-FA/FA-MN MSAs and the FA-HA/HA-FA MSAs to the FA. These are sent in Diameter AVPs and must be independently secured by using IPSec or TLS between the AAAH and the FA and between the AAAH and the HA. See section 8 for more information on key derivation and distribution.
AAAHは、MN-AAAセキュリティ協会[Mipchal]を使用して登録要求を認証できます。認証が成功した場合、AAAHはMSAをMN、HA、およびFAに生成および配布します。MN（すなわち、MN-HA/HA-MN MSASおよびMN-FA/FA-MN MSA）を含む各MSAペアのペアごとに、AAAHはNonCEを生成し、MN-AAA共有キーと一緒にハッシュします。MSAペアのセッションキーを導き出します。Noncesは、登録返信にそれらを含むHAに送信されます。これにより、MNは同じキー[Mipkeys]を導き出すことができます。同時に、AAAHはMN-HA/HA-MN MSASとFA-HA/HA-FA MSAをHAに配布し、MN-FA/FA-MN MSASとFA-HA/HAを配布する必要があります。-FAへのFAへ。これらは直径AVPで送信され、AAAHとFAの間、およびAAAHとHAの間でIPSECまたはTLSを使用して独立して保護する必要があります。キー派生と分布の詳細については、セクション8を参照してください。
Note that MSAs in Mobile IP are unidirectional in that, for example, the MN-HA MSA (used to protect traffic from the MN to the HA) and the HA-MN MSA (used to protect traffic from the HA to the MN) can use different SPIs, algorithms, and shared secrets. This is true of the base Mobile IP protocol despite common existing practice during manual configuration of MSAs in which all parameters are set to the same value in both directions. This document supports the use of different SPIs in each direction; however, it only supports the distribution of a single session key for each pair of MSAs between two nodes. The security implications of this are discussed in section 13. This document sometimes names only one of the two unidirectional MSAs when referring to the distribution of the single shared secret and the pair of SPIs for the pair of MSAs between two entities.
モバイルIPのMSAは、たとえば、MN-HA MSA（MNからHAへのトラフィックを保護するために使用）とHA-MN MSA（HAからMNへのトラフィックを保護するために使用）では、単方向であることに注意してください。さまざまなSPI、アルゴリズム、共有秘密を使用します。これは、すべてのパラメーターが両方向に同じ値に設定されているMSAの手動構成中に一般的な既存の慣行にもかかわらず、ベースモバイルIPプロトコルに当てはまります。このドキュメントは、各方向に異なるSPIの使用をサポートしています。ただし、2つのノード間のMSAの各ペアの単一セッションキーの分布のみをサポートします。これのセキュリティへの影響については、セクション13で説明します。このドキュメントは、2つのエンティティ間のMSAのペアの単一共有秘密とSPIのペアの分布を参照する場合、2つの単方向MSAのうちの1つのみに名前を付けます。
In addition to supporting the derivation and transport of the MN-HA, MN-FA, and FA-HA MSAs, this application also supports MIPv4 handoff. When an MN moves from one point of attachment to another, the MN can continue the same Mobile IPv4 session by using its existing HA and home address.
MN-HA、MN-FA、およびFA-HA MSAの派生と輸送をサポートすることに加えて、このアプリケーションはMIPV4ハンドオフもサポートしています。MNがあるポイントの添付ファイルから別のポイントに移動すると、MNは既存のHAおよびホームアドレスを使用して同じモバイルIPv4セッションを継続できます。
The MN accomplishes this by sending a Mobile IPv4 Registration Request from its new point of attachment. To enable a single set of accounting records to be maintained for the entire session, including handoffs, it is necessary to allow the AAAH to bind the new registration to the pre-existing session. To enable the Mobile IPv4 Registration Request to be routed to the same AAAH, the MN SHOULD include the AAAH NAI [AAANAI] in such re-registrations. Also, to assist the AAAH in routing the messages to the MN's existing HA the mobile node SHOULD include the HA NAI [AAANAI] in such re-registrations. If the mobile node does not support the Mobile IPv4 AAA NAI extension [AAANAI], this functionality is not available.
MNは、新しい添付ポイントからモバイルIPv4登録要求を送信することにより、これを達成します。ハンドオフを含むセッション全体で、単一の会計記録を維持できるようにするには、AAAHが新しい登録を既存のセッションにバインドできるようにする必要があります。モバイルIPv4登録要求を同じAAAHにルーティングできるようにするには、MNはそのような再登録にAAAH NAI [AAANAI]を含める必要があります。また、AAAHがMNの既存のHAにメッセージをルーティングするのを支援するには、モバイルノードをそのような再登録にHa Nai [aaanai]を含める必要があります。モバイルノードがモバイルIPv4 AAA NAI拡張機能[AAANAI]をサポートしていない場合、この機能は利用できません。
The remainder of this document is structured as follows. Section 2 provides acronym definitions. Section 3 provides some examples and message flows illustrating both the Mobile IPv4 and Diameter messages that occur when a mobile node attaches to the Internet. Section 4 defines the relationship of this application to the Diameter Base Protocol. Section 5 defines the new command codes. Section 6 defines the new result codes used by this application. Section 7 defines the set of mandatory Attribute-Value-Pairs (AVPs). Section 8 gives an overview of the key distribution capability, and Section 9 defines the key distribution AVPs. Section 10 defines the accounting AVPs, and section 11 contains a listing of all AVPs and their occurrence in Diameter commands. Finally, sections 12 and 13 give IANA and security considerations, respectively.
このドキュメントの残りの部分は、次のように構成されています。セクション2では、頭字語の定義を提供します。セクション3では、モバイルノードがインターネットに接続されたときに発生するモバイルIPv4と直径メッセージの両方を示すいくつかの例とメッセージフローを示します。セクション4では、このアプリケーションの直径ベースプロトコルとの関係を定義します。セクション5では、新しいコマンドコードを定義します。セクション6では、このアプリケーションで使用されている新しい結果コードを定義します。セクション7では、必須属性値ペア（AVP）のセットを定義します。セクション8では、主要な分布機能の概要を示し、セクション9でキーディストリビューションAVPを定義します。セクション10では、会計AVPを定義し、セクション11にはすべてのAVPのリストとその発生が直径コマンドを含んでいます。最後に、セクション12と13は、それぞれIANAとセキュリティ上の考慮事項を示しています。
AAAH Authentication, Authorization, and Accounting Home
AAAF Authentication, Authorization, and Accounting Foreign
AMA AA-Mobile-Node-Answer
AMR AA-Mobile-Node-Request
ASR Abort-Session-Request
AVP Attribute Value Pair
CoA Care-of-Address
FA Foreign Agent
FQDN Fully Qualified Domain Name
HA Home Agent
HAA Home-Agent-MIP-Answer
HAR Home-Agent-MIP-Request
MN Mobile Node
MSA Mobility Security Association
NAI Network Access Identifier
RRQ Registration Request
SPI Security Parameters Index
STR Session-Termination-Request
This section presents four scenarios illustrating Diameter Mobile IPv4 application and describes the operation of key distribution.
このセクションでは、直径のモバイルIPv4アプリケーションを示す4つのシナリオを示し、キー分布の動作について説明します。
In this document, the role of the "attendant" [MIPREQ] is performed by either the FA (when it is present in a visited network) or the HA (for co-located mobile nodes not registering via an FA), and these terms will be used interchangeably in the following scenarios.
このドキュメントでは、「アテンダント」[MIPREQ]の役割は、FA（訪問されたネットワークに存在する場合）またはHA（FAを介して登録されていない共同住宅モバイルノードの場合）、およびこれらの用語によって実行されます。次のシナリオでは、交換可能に使用されます。
When a mobile node requests service by issuing a Registration Request to the foreign agent, the foreign agent creates the AA-Mobile-Node-Request (AMR) message, which includes the AVPs defined in section 7. The Home Address, Home Agent, Mobile Node NAI, and other important fields are extracted from the registration messages for possible inclusion as Diameter AVPs. The AMR message is then forwarded to the local Diameter server, known as the AAA-Foreign, or AAAF.
モバイルノードが外国人エージェントに登録要求を発行してサービスを要求する場合、外国人エージェントはセクション7で定義されたAVPを含むAA-Mobile-Node-Request（AMR）メッセージを作成します。ノードNAIおよびその他の重要なフィールドは、直径AVPとして含める可能性のある登録メッセージから抽出されます。AMRメッセージは、AAA-ForeignまたはAAAFとして知られるローカルDiameterサーバーに転送されます。
Visited Realm Home Realm
+-----------+ +-----------+
|example.net| AMR/AMA |example.org|
| AAAF |<------------------->| AAAH |
+->| server | server-server | server |
| +-----------+ communication +-----------+
| ^ ^
| AMR/AMA | client-server | HAR/HAA
| | communication |
v v v
+---------+ +---------+ +---------+
| Foreign | | Foreign | | Home |
| Agent | | Agent | | Agent |
+---------+ +---------+ +---------+
^
| Mobile IP
|
v
+--------+
| Mobile |
| Node | mn@example.org
+--------+
Figure 1. Inter-realm Mobility
図1.リアルム間のモビリティ
Upon receiving the AMR, the AAAF follows the procedures outlined in [DIAMBASE] to determine whether the AMR should be processed locally or forwarded to another Diameter server known as the AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node (mn@example.org) requests service from a foreign provider (example.net). The request received by the AAAF is forwarded to example.org's AAAH server.
AMRを受信すると、AAAFは[Diambase]で概説されている手順に従って、AMRをローカルで処理するか、AAA-HomeまたはAAAHとして知られる別の直径サーバーに転送する必要があるかを判断します。図1は、モバイルノード（mn@example.org）が外国人プロバイダー（example.net）からサービスを要求する例を示しています。AAAFが受け取ったリクエストは、example.orgのAAAHサーバーに転送されます。
Figure 2 shows the message flows involved when the foreign agent invokes the AAA infrastructure to request that a mobile node be authenticated and authorized. Note that it is not required that the foreign agent invoke AAA services every time a Registration Request is received from the mobile, but rather only when the prior authorization from the AAAH expires. The expiration time of the authorization is communicated through the Authorization-Lifetime AVP in the AA-Mobile-Node-Answer (AMA; see section 5.2) from the AAAH.
図2は、外国人エージェントがAAAインフラストラクチャを呼び出してモバイルノードを認証して承認するように要求したときのメッセージフローを示しています。外国人エージェントは、登録要求がモバイルから受信されるたびにAAAサービスを呼び出す必要はないことに注意してください。AAAHのAA-Mobile-Node-Answer（AMA;セクション5.2を参照）の認可-Lifetime AVPを通じて、承認の有効期限は伝えられます。
Mobile Node Foreign Agent AAAF AAAH Home
Agent
----------- ------------- ------------ ---------- -------
Advertisement &
<--------- Challenge
Reg-Req&MN-AAA ---->
AMR------------>
Session-Id = foo
AMR------------>
Session-Id = foo
HAR----------->
Session-Id = bar
<----------HAA
Session-Id = bar
<-----------AMA
Session-Id = foo
<------------AMA
Session-Id = foo
<-------Reg-Reply
Figure 2. Mobile IPv4/Diameter Message Exchange
図2.モバイルIPv4/直径メッセージ交換
The foreign agent (as shown in Figure 2) MAY provide a challenge, which would give it direct control over the replay protection in the Mobile IPv4 registration process, as described in [MIPCHAL]. The mobile node includes the Challenge and MN-AAA authentication extension to enable authorization by the AAAH. If the authentication data supplied in the MN-AAA extension is invalid, the AAAH returns the response (AMA) with the Result-Code AVP set to DIAMETER_AUTHENTICATION_REJECTED.
外国のエージェント（図2に示すように）は、[Mipchal]で説明されているように、モバイルIPv4登録プロセスのリプレイ保護を直接制御する課題を提供する場合があります。モバイルノードには、AAAHによる承認を可能にするためのチャレンジとMN-AAA認証拡張機能が含まれています。MN-AAA拡張機能で提供された認証データが無効である場合、AAAHは、結果コードAVPがdiameter_authentication_rejedに設定された応答（AMA）を返します。
The above scenario causes the MN-FA and MN-HA keys to be exposed to Diameter agents all along the Diameter route. If this is a concern, a more secure approach is to eliminate the AAAF and other Diameter agents, as shown in Figure 3.
上記のシナリオにより、MN-FAおよびMN-HAキーが直径ルート全体に沿って直径エージェントにさらされます。これが懸念事項である場合、図3に示すように、より安全なアプローチはAAAFおよびその他の直径エージェントを排除することです。
Redirect
FA AAAF Agent AAAH
AMR
---------------->
AMR
---------------->
AMA (Redirect)
<----------------
AMA (Redirect)
<----------------
Setup Security Association
<-------------------------------------------------->
AMR
amr
-------------------------------------------------->
AMA (MN-FA key)
<---------------------------------------------------
Figure 3. Use of a Redirect Server with AMR/AMA
図3. AMR/AMAを使用したリダイレクトサーバーの使用
In Figure 3, the FA sets up a TLS [TLS] or IPSec [IPSEC]-based security association with the AAAH directly and runs the AMR/AMA exchange over it. This provides end-to-end security for secret keys that may have to be distributed.
図3では、FAはTLS [TLS]またはIPSEC [IPSEC]ベースのセキュリティ関連をAAAHと直接設定し、AMR/AMA Exchangeを実行します。これにより、配布する必要がある秘密の鍵のエンドツーエンドのセキュリティが提供されます。
Figure 4 shows the interaction between the AAAH and HA with the help of a redirect agent. When the AAAH and HA are in the same network, it is likely that the AAAH knows the IP address of the HA, so the redirect server would therefore not be needed; however, it is shown anyway for completeness. The redirect server will most likely be used in the case where the HA is allocated in a foreign network (see section 3.2 for more details of HA allocation in foreign networks).
図4は、リダイレクトエージェントの助けを借りて、AAAHとHAの間の相互作用を示しています。AAAHとHAが同じネットワークにいる場合、AAAHはHAのIPアドレスを知っているため、リダイレクトサーバーは必要ありません。ただし、とにかく完全性のために表示されます。リダイレクトサーバーは、外国ネットワークでHAが割り当てられている場合に使用される可能性が最も高くなります（外国ネットワークでのHA割り当ての詳細については、セクション3.2を参照）。
Redirect
HA Agent AAAH
HAR
<--------------------
HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<-----------------------------------------
HAA
----------------------------------------->
Figure 4. Use of a Redirect Server with HAR/HAA
図4. HAR/HAAでリダイレクトサーバーの使用
As in Figure 2, the FA of Figure 3 would still provide the challenge and the mobile sends the RRQ, etc.; however, these steps were eliminated from Figure 3 to reduce clutter. The redirect server eliminates the AAAF and any other Diameter agents from seeing the keys as they are transported to the FA and HA. Note that the message flows in Figures 3 and 4 apply only to the initial authentication and key exchange. Accounting messages would still be sent via Diameter agents, not via the direct connection, unless network policies dictate otherwise.
図2のように、図3のFAは依然として課題を提供し、モバイルはRRQなどを送信します。ただし、これらの手順は図3から排除され、乱雑さを減らしました。リダイレクトサーバーは、AAAFおよびその他の直径エージェントがFAおよびHAに輸送されるキーを見ることから排除します。図3および4のメッセージの流れは、初期認証とキー交換にのみ適用されることに注意してください。会計メッセージは、ネットワークポリシーが特に指示しない限り、直接接続を介してではなく、直径エージェントを介して送信されます。
A mobile node that supports the AAA NAI extension [AAANAI], which has been previously authenticated and authorized, MUST always include the assigned home agent in the HA Identity subtype of the AAA NAI extension, and the authorizing Home AAA server in the AAAH Identity subtype of the AAA NAI extension, when re-authenticating. Therefore, in the event that the AMR generated by the FA is for a session that was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent-Host AVP with the identity and realm of the assigned HA found in the HA-NAI. If, on the other hand, the mobile node does not support the AAA NAI extension, the FA may not have the identity of the AAAH and the identity and realm of the assigned HA. This means that without support of the AAA NAI extension, the FA may not be able to guarantee that the AMR will be destined to the same AAAH, which previously authenticated and authorized the mobile node, as the FA may not know the identity of the AAAH.
以前に認証および承認されていたAAA Nai拡張機能[AAANAI]をサポートするモバイルノードは、AAA NAI拡張のHAアイデンティティサブタイプに割り当てられたホームエージェントと、AAAH IDサブタイプの認可ホームAAAサーバーを常に含める必要がありますAAA NAI拡張機能の場合、再認識の場合。したがって、FAによって生成されたAMRが以前に許可されたセッションの場合、AAAH-NAIで見つかったAAAHのアイデンティティとMIP-Home-Agentを含むDestination-Host AVPを含める必要があります。-ha-naiで見つかった割り当てられたHAのアイデンティティと領域を備えたAVP。一方、モバイルノードがAAA NAI拡張機能をサポートしていない場合、FAはAAAHのアイデンティティと割り当てられたHAのアイデンティティと領域を持たない場合があります。これは、AAA NAI拡張機能のサポートがなければ、FAはAAAHのアイデンティティを知らない可能性があるため、AMRがモバイルノードを以前に認証および承認した同じAAAHに運命づけられることを保証できない可能性があることを意味します。。
If the mobile node was successfully authenticated, the AAAH then determines which Home Agent to use for the session. First, the AAAH checks whether an HA has been requested by the MN by checking the MIP-Home-Agent-Address AVP and the MIP-Home-Agent-Host AVP. The administrative domain owning the HA may be determined from the realm portion of the MIP-Home-Agent-Host AVP, or by checking the Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP and the value of the MIP-Originating-Foreign-AAA AVP. If the requested HA belongs to a permitted administrative domain, the AAAH SHOULD use the given HA for the session. Otherwise, the AAAH returns the response (AMA) with the Result-Code AVP set to either DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE or DIAMETER_ERROR_HA_NOT_AVAILABLE.
モバイルノードが正常に認証された場合、AAAHはセッションに使用するホームエージェントを決定します。まず、AAAHは、MIP-Home-Agent-Address AVPとMIP-Home-Agent-Host AVPをチェックすることにより、MNによってHAが要求されたかどうかを確認します。HAを所有する管理ドメインは、MIP-Home-Agent-Host AVPの領域部分から、またはMIP-Feature-Vector AVPのHome-Agent-in-Foreign-Networkフラグをチェックし、MIP-Originating-Foreign-AAA AVP。要求されたHAが許可された管理ドメインに属している場合、AAAHはセッションに与えられたHAを使用する必要があります。それ以外の場合、AAAHは、結果コードAVPをDiameter_error_no_foreign_ha_serviceまたはdiameter_error_ha_not_availableのいずれかに設定して応答（AMA）を返します。
If the MN has not requested any particular HA, then an HA MUST be dynamically allocated. In this case the MIP-Feature-Vector will have the Home-Agent-Requested flag set. If the Home-Address-Allocatable-Only-in-Home-Realm flag is not set, and if the Foreign-Home-Agent-Available flag is set, then the AAAH SHOULD allow the foreign realm to allocate the HA (see section 3.2) but MAY allocate one itself in the home realm if dictated by local policy. If the Home-Address-Allocatable-Only-in-Home-Realm flag is set, then the AAAH MUST allocate an HA in the home realm on behalf of the MN. Allocation of the HA can be done in a variety of ways, including by using a load-balancing algorithm to keep the load on all home agents equal. The actual algorithm used and the method of discovering the home agents are outside the scope of this specification.
MNが特定のHAを要求していない場合、HAを動的に割り当てる必要があります。この場合、MIP-Feature-Vectorには、ホームエージェントが要求されたフラグが設定されます。Home-Address-Allocatableのみの在宅領域フラグが設定されていない場合、外国の在宅エージェント利用可能なフラグが設定されている場合、AAAHは外国の領域がHAを割り当てることを許可する必要があります（セクション3.2を参照してください）しかし、地元の政策によって決定された場合、ホームの領域にそれ自体を割り当てることができます。Home-Address-allocatableのみの在宅領域フラグが設定されている場合、AAAHはMNに代わってHAをホームレルムに割り当てる必要があります。HAの割り当ては、すべてのホームエージェントの負荷を等しく保つために負荷バランスアルゴリズムを使用するなど、さまざまな方法で実行できます。使用された実際のアルゴリズムとホームエージェントを発見する方法は、この仕様の範囲外です。
The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains the Mobile IPv4 Registration Request message data encapsulated in the MIP-Reg-Request AVP, to the assigned or requested Home Agent. Refer to Figure 4 if the AAAH does not have a direct path to the HA. The AAAH MAY allocate a home address for the mobile node, and the Home Agent MUST support home address allocation. In the event that the AAAH handles address allocation, it includes the home address in a MIP-Mobile-Node-Address AVP within the HAR. The absence of this AVP informs the Home Agent that it must perform the home address allocation.
AAAHは、MIP-Reg-Request AVPにカプセル化されたモバイルIPv4登録要求メッセージデータを含むHome-Agent-Mip-Request（HAR）を送信します。AAAHにHAへの直接的なパスがない場合は、図4を参照してください。AAAHは、モバイルノードのホームアドレスを割り当てる場合があり、ホームエージェントはホームアドレスの割り当てをサポートする必要があります。AAAHがアドレス割り当てを処理した場合、HAR内のMIP-Mobile-Node-Address AVPのホームアドレスが含まれています。このAVPがないことは、ホームエージェントにホームアドレスの割り当てを実行する必要があることを通知します。
Upon receipt of the HAR, the home agent first processes the Diameter message. The home agent processes the MIP-Reg-Request AVP and creates the Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. In the creation of the Registration Reply, the Home Agent MUST include the HA NAI and the AAAH NAI, which will be created from the Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is needed, the home agent MUST also assign one and include the address in both the Registration Reply and the MIP-Mobile-Node-Address AVP.
HARを受け取ると、ホームエージェントは最初に直径メッセージを処理します。ホームエージェントはMIP-Reg-Request AVPを処理し、登録返信を作成し、MIP-Reg Reply AVP内でカプセル化します。登録返信の作成において、ホームエージェントには、HAのOrigin-Host AVPおよびOrigin-Realm AVPから作成されるHa NaiとAaah Naiを含める必要があります。ホームアドレスが必要な場合は、ホームエージェントも1つを割り当て、登録返信とMIP-Mobile-Node-Address AVPの両方に住所を含める必要があります。
Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer (AMA) message, which includes the same Acct-Multi-Session-Id contained in the HAA and the MIP-Home-Agent-Address and MIP-Mobile- Node-Address AVPs in the AMA message. See Figures 3 and 4 for the use of the redirect agent for the secure transport of the HAA and AMA messages.
HAAを受け取ると、AAAHはAA-Mobile-Node-Answer（AMA）メッセージを作成します。-AMAメッセージのノードアドレスAVP。HAAおよびAMAメッセージの安全な輸送のためのリダイレクトエージェントの使用については、図3および4を参照してください。
See section 4.1 for information on the management of sessions and session identifiers by the Diameter Mobile IPv4 entities.
直径モバイルIPv4エンティティによるセッションの管理およびセッション識別子については、セクション4.1を参照してください。
The Diameter Mobile IPv4 application allows a home agent to be allocated in a foreign network, as required in [MIPREQ, CDMA2000]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag set to one. If the home agent address is set to 255.255.255.255, the foreign agent MUST set the Home-Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home agent address is set to 0.0.0.0, the foreign agent MUST set the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero.
直径モバイルIPv4アプリケーションにより、[MIPREQ、CDMA2000]で必要に応じて、ホームエージェントを外国ネットワークに割り当てることができます。登録要求メッセージで、外国人エージェントがモバイルノードが0.0.0.0または255.255.255.255に等しいホームエージェントアドレスを持っていることを検出した場合、ホームエージェント要求のフラグを1つに設定してMIP-Feature-Vector AVPを追加する必要があります。ホームエージェントの住所が255.255.255.255に設定されている場合、外国人エージェントはホームアドレスアロカティブのみの在宅勤務のみを1つに等しく設定する必要があります。ホームエージェントアドレスが0.0.0.0に設定されている場合、外国人エージェントは、ゼロに等しいホームアドレスアロカティブのみの在宅領域フラグを設定する必要があります。
When the AAAF receives an AMR message with the Home-Agent-Requested flag set to one and with the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in order to inform the AAAH that it is willing and able to assign a Home Agent for the mobile node. When doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-Agent-Host AVP contains the identity (i.e., a DiameterIdentity, which is an FQDN) of the home agent that would be assigned to the mobile node, and the MIP-Originating-Foreign-AAA AVP contains the identity of the AAAF. The AAAF now sends the AMR to the AAAH. However, as discussed above, the use of Diameter agents between the FA and AAAH would expose the MN-FA key. If this is deemed undesirable, a redirect server approach SHOULD be utilized to communicate the AMR to the AAAH. This causes the FA to communicate the AMR directly to the AAAH via a security association.
AAAFがHome-Agent-Requested Flagが1つに設定され、Home-Address-Allocatableのみの在宅勤務フラグがゼロに等しいAMRメッセージを受信すると、AAAFは外国の在宅エージェント - を設定する場合があります。MIP-Feature-Vector AVPの利用可能なフラグは、モバイルノードにホームエージェントを割り当てることができており、喜んで割り当てることができることをAAAHに通知するためです。そうするとき、AAAFには、MIP-Candidate-Home-Agent-Host AVPとMIP-Originating-Orign-AAA-AVPを含める必要があります。MIP-Candididate-Home-Agent-Host AVPには、モバイルノードに割り当てられるホームエージェントのID（すなわち、直径がFQDN）を含み、MIP-Originating-Orign-AAA AVPには含まれています。AAAFのアイデンティティ。AAAFは今、AMRをAAAHに送ります。ただし、上記のように、FAとAAAHの間の直径エージェントの使用は、MN-FAキーを公開します。これが望ましくないとみなされる場合、AMRをAAAHに伝えるためにリダイレクトサーバーアプローチを利用する必要があります。これにより、FAはセキュリティ協会を介してAMRをAAAHに直接伝えます。
If the mobile node with AAA NAI extension support [AAANAI] has been previously authorized by the AAAH, now has to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR, including the MIP-Home-Agent-Address AVP and the Destination-Host AVP based on the AAAH NAI, and include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
AAA NAI拡張サポートを備えたモバイルノード[AAANAI]が以前にAAAHによって許可されており、今は再認証されている必要があり、割り当てられたホームエージェントを外国ネットワークに維持するよう要求する場合、モバイルノードにはHA NAIとHA NAIと含まれている必要があります。FAへの登録要求におけるAaah Nai。受領時、FAはAAAH NAIに基づいたMIP-Home-Agent-Address AVPと宛先ホストAVPを含むAMRを作成し、ホームエージェントNAIに基づいたMIP-Home-Agent-Host AVPを含めます。AAAFが要求されたホームエージェントの使用を承認した場合、AAAFはMIP-Feature-Vector AVPにHome-Agent-in-Foregn-Networkビットを設定する必要があります。
If the mobile node has to be re-authenticated but does not support the AAA NAI extension, it sends a registration request without the AAA NAI and the HA NAI, even though it has previously been authorized by the AAAH and requests to keep the assigned home agent in the foreign network. Upon receipt, the FA will create the AMR, including the MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested home agent, and if it knows that the agent is in its own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
モバイルノードを再認証する必要がありますが、AAA NAI拡張機能をサポートしていない場合、AAAHによって以前に許可されていて、割り当てられた家を維持するように要求していても、AAA NAIとHa Naiなしで登録リクエストを送信します外国ネットワークのエージェント。受領すると、FAはMIP-Home-Agent-Address AVPを含むAMRを作成します。AAAFが要求されたホームエージェントの使用を承認し、エージェントが独自のドメインにあることを知っている場合、AAAFはMIP-Feature-Vector AVPでHome-Agent-in-Foreign-Networkビットを設定する必要があります。
When the AAAH receives an AMR message, it first checks the authentication data supplied by the mobile node, according to the MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node. If the AMR indicates that the AAAF has offered to allocate a Home Agent for the mobile node (i.e., the Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP), or if the AMR indicates that the AAAF has offered a previously allocated Home Agent for the mobile node (i.e., the Home-Agent-In-Foreign-Network is set in the MIP-Feature-Vector AVP), then the AAAH must decide whether its local policy would allow the user to have or keep a home agent in the foreign network. Assuming that the mobile node is permitted to do so, the AAAH determines the IP address of the HA based upon the FQDN of the HA by using DNS or learns it via an MIP-Home-Agent-Address AVP in a redirect response to an HAR (i.e., if the redirect server adds this AVP to the HAA). Then it sends an HAR message to Home Agent by including the Destination-Host AVP set to the value found in the AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP. If DNS is used to determine the HA IP address, it is assumed that the HA has a public address and that it can be resolved by DNS.
AAAHがAMRメッセージを受信すると、MIP-Reg-Request AVPおよびMIP-MN-AAA-Auth AVPに従って、最初にモバイルノードで提供された認証データをチェックし、モバイルノードを承認するかどうかを決定します。AMRがAAAFがモバイルノードにホームエージェントを割り当てることを申し出たことを示している場合（つまり、外国人ホームエージェント利用可能性がMIP-Feature-Vector AVPに設定されています）、またはAMRがAAAFが持っていることを示している場合モバイルノードに以前に割り当てられたホームエージェントを提供しました（つまり、Home-Agent-in-Foreign-NetworkはMIP-Feature-Vector AVPに設定されています）。または、外国ネットワークにホームエージェントを維持します。モバイルノードがそうすることが許可されていると仮定すると、AAAHはDNSを使用してHAのFQDNに基づいてHAのIPアドレスを決定するか、HAR HARのリダイレクト応答でMIP-Home-Agent-Address AVPを介してそれを学習します（つまり、リダイレクトサーバーがこのAVPをHAAに追加する場合）。次に、AMRのMIP-Candididate-Home-Agent-Host AVPまたはMIP-Home-Agent-Host AVPにある値に宛先ホストAVPセットを含めることにより、HARメッセージをホームエージェントに送信します。DNSがHA IPアドレスを決定するために使用される場合、HAには公開アドレスがあり、DNSによって解決できると想定されています。
Security considerations may require that the HAR be sent directly from the AAAH to the HA without the use of intermediary Diameter agents. This requires that a security association between the AAAH and HA be established, as in Figure 4. If no security association can be established, the AAAH MUST return an AMA with the Result-Code AVP set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
セキュリティ上の考慮事項には、HARが中間直径エージェントを使用せずにAAAHからHAに直接送信する必要がある場合があります。これには、図4のように、AAAHとHAの間のセキュリティ協会を確立する必要があります。セキュリティ関連を確立できない場合、AAAHは結果コードAVPをDiameter_Error_end_to_end_end_mip_key_encryptingに設定してAMAを返す必要があります。
If Diameter agents are being used (e.g., if there is no redirect server) the AAAH sends the HAR to the originating AAAF. In this HAR the Destination-Host AVP is set to the value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found in the AMR is copied into the HAR.
直径エージェントが使用されている場合（たとえば、リダイレクトサーバーがない場合）、AAAHはHARを元のAAAFに送信します。このHARでは、宛先ホストAVPは、AMRのMIP-Originating-Foreign-AAA AVP、MIP-Home-Agent-Host AVPまたはMIP-CANDIDATE-HOME-AGENT-HOST AVPで見つかった値に設定されています。AMRはHARにコピーされます。
Therefore, the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In cases when another AAAF receives the HAR, this new AAAF will send the HAR to the HA.
したがって、AAAHは常にMIP-Originating-Foreign-AAA AVPをAMRメッセージからHARメッセージにコピーする必要があります。別のAAAFがHARを受け取った場合、この新しいAAAFはHAをHAに送ります。
Visited Home
Realm Realm
+--------+ ------- AMR -------> +--------+
| AAAF | <------ HAR -------- | AAAH |
| | | |
+--->| server | ------- HAA -------> | server |
| +--------+ <------ AMA -------- +--------+
| ^ |
| | |
HAR/HAA | AMR | | AMA
v | v
+---------+ +---------+
| Home | | Foreign |
| Agent | | Agent |
+---------+ +---------+
^
+--------+ |
| Mobile |<----------+
| Node | Mobile IP
+--------+
Figure 5. Home Agent Allocated in Visited Realm
図5.訪問された領域に割り当てられたホームエージェント
Upon receipt of an HAA from the Home Agent in the visited realm, the AAAF forwards the HAA to the AAAH in the home realm. The AMA is then constructed and issued to the AAAF and, finally, to the FA. If the Result-Code indicates success, the HAA and AMA MUST include the MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs.
訪問された領域のホームエージェントからHAAを受け取ると、AAAFはHAAをホーム領域のAAAHに前進させます。その後、AMAは構築され、AAAFに、最後にFAに発行されます。結果コードが成功を示している場合、HAAとAMAには、MIP-Home-Agent-AddressとMIP-Mobile-Node-Address AVPSを含める必要があります。
If exposing keys to the Diameter Agents along the way represents an unacceptable security risk, then the redirect approach depicted in Figures 3 and 4 MUST be used instead.
途中で直径エージェントにキーを公開することが容認できないセキュリティリスクを表している場合、代わりに図3および4に描かれているリダイレクトアプローチを使用する必要があります。
Mobile Node Foreign Agent Home Agent AAAF AAAH
----------- ------------- ------------- ---------- ----------
<---Challenge----
Reg-Req (Response)->
-------------AMR----------->
------AMR---->
<-----HAR-----
<-----HAR------
------HAA----->
------HAA---->
<-----AMA-----
<------------AMA------------
<---Reg-Reply----
Figure 6. MIP/Diameter Exchange for HA Is Allocated in Visited Realm
図6. HAのMIP/直径の交換は、訪問された領域で割り当てられています
If the mobile node moves to another foreign Network, it MAY either request to keep the same Home Agent within the old foreign network or request to get a new one in the new foreign network. If the AAAH is willing to provide the requested service, the AAAH will have to provide services for both visited networks; e.g., key refresh.
モバイルノードが別の外国ネットワークに移動した場合、古い外国ネットワーク内に同じホームエージェントを維持することを要求するか、新しい外国ネットワークで新しいホームエージェントを取得するよう要求する場合があります。AAAHが要求されたサービスを喜んで提供する場合、AAAHは訪問されたネットワークの両方にサービスを提供する必要があります。たとえば、キーリフレッシュ。
If a mobile node registers with the Home Agent as a co-located mobile node, no foreign agent is involved. Therefore, when the Home Agent receives the Registration Request, an AMR message is sent to the local AAAH server, with the Co-Located-Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent also includes the Acct-Multi-Session-Id AVP (see sections 4.1.1 and 4.1.2) in the AMR sent to the AAAH, as the AAAH may find this piece of session-state or log entry information useful.
モバイルノードがホームエージェントを共同でモバイルノードとして登録する場合、外国人エージェントは関与しません。したがって、ホームエージェントが登録リクエストを受信すると、AMRメッセージがローカルAAAHサーバーに送信され、MIP-Feature-Vector AVPに共同住宅モバイルノードビットが設定されています。ホームエージェントには、AAAHがこのセッション状態またはログエントリ情報の一部が有用であると感じる可能性があるため、AAAHに送信されたAMRのACCT-Multi-Session-ID AVP（セクション4.1.1および4.1.2を参照）も含まれています。
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA
| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
Figure 7. Co-located Mobile Node
図7.共同配置されたモバイルノード
If the MN-HA-Key-Requested bit was set in the AMR message from the Home Agent, the home agent and mobile node's session keys would be present in the AMA message.
Mn-Ha-Key-Requested BitがホームエージェントからのAMRメッセージに設定された場合、HomeエージェントとモバイルノードのセッションキーがAMAメッセージに存在します。
Figure 8 shows a signaling diagram that indicates a secure way to set up the necessary security associations when using redirect servers. The Proxy AAA represents any AAA server or servers that the HA may use. This applies to the visited or home network.
図8は、リダイレクトサーバーを使用するときに必要なセキュリティ関連を設定するための安全な方法を示すシグナル図を示しています。プロキシAAAは、HAが使用する可能性のあるAAAサーバーまたはサーバーを表します。これは、訪問またはホームネットワークに適用されます。
Local redirect
HA Proxy AAA Agent AAAH
AMR
--------------->
AMR (Redirect)
-------------------->
AMA (Redirect)
<---------------------
AMA (Redirect)
<----------------
Setup Security Association
<------------------------------------------------------>
AMR
------------------------------------------------------->
AMA (MN-HA key)
<-------------------------------------------------------
Figure 8. Use of Redirect Server for Co-located CoA and AMR/AMA
図8.共同住宅COAおよびAMR/AMAのリダイレクトサーバーの使用
To allow the scaling of wireless data access across administrative domains, it is necessary to minimize the number of pre-existing Mobility Security Associations (MSAs) required. This means that each Foreign Agent should not be required to have a pre-configured MSA with each Home Agent on the Internet, nor should the mobile node be required to have a pre-configured MSA (as defined in [MOBILEIP]) with any specific foreign agent. Furthermore, when the mobile node requests a dynamically allocated home agent, it is likely to receive the address of a home agent for which it has no available mobility security association.
管理ドメイン全体でワイヤレスデータアクセスをスケーリングできるようにするには、既存のモビリティセキュリティ協会（MSA）の数を最小限に抑える必要があります。これは、各外国人エージェントがインターネット上の各ホームエージェントと事前に構成されたMSAを持つ必要がないことを意味します。また、モバイルノードは、特定の特定の事前に構成されたMSA（[mobileIp]で定義）を持つ必要がないことを意味します。外国人エージェント。さらに、モバイルノードが動的に割り当てられたホームエージェントを要求すると、利用可能なモビリティセキュリティ協会がないホームエージェントの住所を受信する可能性があります。
The Diameter Mobile IPv4 application solves this by including key distribution functionality, which means that after a Mobile Node is authenticated the authorization phase includes the generation of session keys and nonces. Specifically, three session keys and two nonces are generated:
直径のモバイルIPv4アプリケーションは、キー配布機能を含めることでこれを解決します。つまり、モバイルノードが認証された後、承認フェーズにはセッションキーとノンセの生成が含まれます。具体的には、3つのセッションキーと2つのノンセスが生成されます。
- K1: The MN-HA Session Key, which will be part of the MSA between the Mobile Node and the Home Agent. The MN-HA Session Key is derived from a nonce generated by AAA. The mobile node obtains that nonce in the Registration Reply and generates this key using the same formula that AAA uses.
- K1：モバイルノードとホームエージェントの間のMSAの一部となるMN-HAセッションキー。MN-HAセッションキーは、AAAによって生成されたNonCEから派生しています。モバイルノードは、登録返信でそのnonceを取得し、AAAが使用するのと同じ式を使用してこのキーを生成します。
- K2: The MN-FA Key, which will be part of the MSA between the Mobile Node and the Foreign Agent. The MN-FA Key is derived from a nonce generated by AAA. The mobile node obtains that nonce in the Registration Reply and generates the MN-FA key using the same formula that AAA uses.
- K2：モバイルノードと外国人エージェントの間のMSAの一部となるMN-FAキー。MN-FAキーは、AAAによって生成されたNonCEから派生しています。モバイルノードは、登録返信でそのnonceを取得し、AAAが使用するのと同じ式を使用してMN-FAキーを生成します。
- K3: The FA-HA Key, which will be part of the MSA between the Foreign Agent and the Home Agent.
- K3：FA-HAキー。これは、外国人エージェントとホームエージェントの間のMSAの一部となります。
The same session key is used in both directions between two entities; e.g., the Mobile Node and the Foreign Agent use the same session key for the MN-FA and the FA-MN authentication extensions. The security implications of this are examined in section 13. However, the SPIs may be different for the MN-FA and the FA-MN authentication extensions. The SPI for the MN-FA MSA is used on messages sent from the MN to the FA, and the SPI for the FA-MN MSA is used on messages sent from the FA to the MN.
同じセッションキーは、2つのエンティティ間の両方向で使用されます。たとえば、モバイルノードと外国エージェントは、MN-FAとFA-MN認証拡張機能に同じセッションキーを使用します。これのセキュリティへの影響については、セクション13で検討します。ただし、SPIはMN-FAとFA-MN認証拡張機能で異なる場合があります。MN-FA MSAのSPIは、MNからFAに送信されたメッセージで使用され、FA-MN MSAのSPIはFAからMNに送信されたメッセージで使用されます。
All keys and nonces are generated by the AAAH, even if a Home Agent is dynamically allocated in the foreign network.
ホームエージェントが外国ネットワークで動的に割り当てられていても、すべてのキーと非セースはAAAHによって生成されます。
Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity using the keys created by the DIAMETER server.
図9は、直径サーバーによって作成されたキーを使用して、モバイル-IPV4メッセージの整合性に使用されるMSAを示しています。
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
Figure 9. Mobility Security Associations after Session Key and Nonce Distribution
図9.セッションキーとノンセの分布後のモビリティセキュリティ協会
The keys destined for the foreign and home agent are propagated to the mobility agents via the Diameter protocol. If exposing keys to the Diameter Agents along the way represents an unacceptable security risk, then the keys MUST be protected either by IPSec or TLS security associations that exist directly between the HA and AAAH or the FA and AAAF, as explained above.
外国人およびホームエージェント向けのキーは、直径プロトコルを介してモビリティエージェントに伝播されます。途中で直径エージェントにキーを公開することは、容認できないセキュリティリスクを表している場合、上記のように、HAとAAAHまたはFAとAAAFの間に直接存在するIPSECまたはTLSセキュリティ協会のいずれかによってキーを保護する必要があります。
The keys destined for the mobile node MUST also be propagated via the Mobile IPv4 protocol and therefore MUST follow the mechanisms described in [MIPKEYS] instead. In [MIPKEYS], the mobile node receives a nonce for each key it needs, and the mobile node will use the nonce and the long-term shared secret to create the keys (see section 8).
モバイルノードに向けたキーもモバイルIPv4プロトコルを介して伝播する必要があるため、代わりに[Mipkeys]に記載されているメカニズムに従う必要があります。[Mipkeys]では、モバイルノードは必要な各キーのNONCEを受信し、モバイルノードはNONCEと長期共有秘密を使用してキーを作成します（セクション8を参照）。
Once the session keys have been established and propagated, the mobility devices can exchange registration information directly, as defined in [MOBILEIP], without the need of the Diameter infrastructure. However, the session keys have a lifetime, after which the Diameter infrastructure MUST be invoked again if new session keys and nonces are to be acquired.
セッションキーが確立され、伝播されると、モビリティデバイスは、[MobileIP]で定義されているように、直径インフラストラクチャを必要とせずに登録情報を直接交換できます。ただし、セッションキーには生涯があり、その後、新しいセッションキーとNoncesを取得する場合は、直径インフラストラクチャを再度呼び出す必要があります。
This section details the relationship of the Diameter Mobile IPv4 application to the Diameter base protocol.
このセクションでは、直径モバイルIPv4アプリケーションと直径ベースプロトコルとの関係について詳しく説明しています。
This document specifies Diameter Application-ID 2. Diameter nodes conforming to this specification MAY advertise support by including the value of two (2) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [DIAMBASE]. The value of two (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA commands. The value of two (2) MUST be used as the Application-Id in all ACR/ACA commands, as this application defines new, mandatory AVPs for accounting. The value of zero (0) SHOULD be used as the Application-Id in all STR/STA and ASR/ASA commands, as these are defined in the Diameter base protocol and no additional mandatory AVPs for those commands are defined in this document.
このドキュメントは、直径Application-ID 2を指定します。この仕様に準拠した直径ノードは、Auth-Application-IDまたはACCT-Application-ID AVPの2つの値を含めることにより、サポートを宣伝することができます。機能 - エクスチェンジアンスワーコマンド[Diambase]。2つの値は、すべてのAMR/AMAおよびHAR/HAAコマンドのアプリケーションIDとして使用する必要があります。このアプリケーションは会計用に新しい必須AVPを定義するため、2つの値の値をすべてのACR/ACAコマンドのアプリケーションIDとして使用する必要があります。ゼロ（0）の値は、すべてのSTR/STAおよびASR/ASAコマンドのアプリケーションIDとして使用する必要があります。これらは直径ベースプロトコルで定義されており、これらのコマンドの追加の必須AVPはこのドキュメントで定義されていません。
Given the nature of Mobile IPv4, re-authentication can only be initiated by a mobile node, which does not participate in the Diameter message exchanges. Therefore, Diameter server initiated re-auth does not apply to this application, and RAR/RAA commands MUST NOT be sent for Diameter Mobile IPv4 sessions.
モバイルIPv4の性質を考えると、再認証は、直径メッセージ交換に参加しないモバイルノードによってのみ開始できます。したがって、reauthを開始した直径サーバーはこのアプリケーションには適用されず、RAR/RAAコマンドを直径モバイルIPv4セッションに送信してはなりません。
The AAAH and AAAF MAY maintain session-state or MAY be session-stateless. AAA redirect agents and AAA relay agents MUST NOT maintain session-state. The AAAH, AAAF, proxies and relays agents MUST maintain transaction state.
AAAHとAAAFは、セッション状態を維持するか、セッションステートレスである場合があります。AAAリダイレクトエージェントとAAAリレーエージェントは、セッション状態を維持してはなりません。AAAH、AAAF、プロキシ、リレーエージェントは、トランザクション状態を維持する必要があります。
A mobile node's session is identified via its identity in the User-Name AVP and the MIP-Mobile-Node-Address, and the MIP-Home-Agent-Address AVPs. This is necessary in order to allow the session state machine, defined in the base protocol [DIAMBASE], to be used without modification for this application. However, as the MN may interact with more than one FA during the life of its session, it is important for the Diameter Mobile IPv4 application to distinguish the two pieces of the session (some state at the FA, some state at the HA) and to manage them independently. The following sub-sections give further details.
モバイルノードのセッションは、ユーザー名AVPおよびMIP-Mobile-Node-Address、およびMIP-Home-Agent-Address AVPでのIDを介して識別されます。これは、ベースプロトコル[Diambase]で定義されているセッション状態マシンを、このアプリケーションの変更なしに使用できるようにするために必要です。ただし、MNはセッションの存続期間中に複数のFAと相互作用する可能性があるため、直径のモバイルIPv4アプリケーションがセッションの2つの部分（FAの一部、HAの一部の状態）を区別することが重要です。それらを独立して管理します。次のサブセクションには詳細が記載されています。
During creation of the AMR, the FA will choose a session identifier. During the creation of the HAR, the AAAH MUST use a different session identifier than that used in the AMR/AMA. If the AAAH is session-stateful, it MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session. Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR.
AMRの作成中、FAはセッション識別子を選択します。HARの作成中、AAAHはAMR/AMAで使用されているものとは異なるセッション識別子を使用する必要があります。AAAHがセッション状態の場合、特定のモバイルノードのセッションに代わって開始されたすべてのHARに対して同じセッション識別子を送信する必要があります。それ以外の場合、AAAHがセッションステートレスの場合、すべてのHARごとにユニークなセッションIDを製造します。
When the HA is first allocated, it MUST create and include an Acct-Multi-Session-Id AVP in the HAA returned to the AAAH. This identifier will be kept constant for the life of the Mobile IPv4 session, as detailed in the next subsection.
HAが最初に割り当てられた場合、AAAHに戻ったHAAにACCT-Multi-Session-ID AVPを作成して含める必要があります。この識別子は、次のサブセクションで詳述されているように、モバイルIPv4セッションの寿命のために一定に保たれます。
Given the nature of Mobile IPv4, a mobile node MAY receive service from many foreign agents during a period of time. However, the home realm should not view these handoffs as different sessions, as this could affect billing systems. Furthermore, foreign agents usually do not communicate between each other, which implies that AAA information cannot be exchanged between these entities.
モバイルIPv4の性質を考えると、モバイルノードは、一定期間中に多くの外国人エージェントからサービスを受信する場合があります。ただし、ホームレルムは、これらのハンドオフをさまざまなセッションと見なすべきではありません。これは請求システムに影響を与える可能性があるためです。さらに、外国人エージェントは通常、互いに通信しません。これは、AAA情報をこれらのエンティティ間で交換できないことを意味します。
A handoff registration request from a mobile node will cause the FA to send an AMR to its AAAF. The AMR will include a new session identifier and MAY be sent to a new AAAF (i.e., a AAAF different from that used by the previous FA). However, the AMR shall be received by the AAAH to which the user is currently registered (possibly via the redirect mechanism depicted in Figure 3).
モバイルノードからのハンドオフ登録リクエストにより、FAはAAAFにAMRを送信します。AMRには新しいセッション識別子が含まれ、新しいAAAF（つまり、以前のFAが使用したものとは異なるAAAF）に送信できます。ただし、AMRは、ユーザーが現在登録されているAAAHによって受け取られます（おそらく図3に示すリダイレクトメカニズムを介して）。
As the AAAH may be session-stateless, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. If the HA receives an HAR for a mobile node with a new session identifier and the HA can guarantee that this request is to extend an existing service, then the HA MUST be able to modify its internal session state information to reflect the new session identifier.
AAAHはセッションステートレスである可能性があるため、HAが受け取った結果のHARが既存のセッションの継続として識別される必要があります。HAが新しいセッション識別子を備えたモバイルノードのHARを受信し、HAがこのリクエストが既存のサービスを拡張することを保証できる場合、HAは新しいセッション識別子を反映するために内部セッション状態情報を変更できる必要があります。
For correlation to occur, accounting records must have some commonality across handoffs. Therefore, the home agent MUST send the same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Acct-Multi-Session-Id when receiving an HAR for a new session and returns this same value in every HAA for the session. This Acct-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Acct-Multi-Session-Id in the accounting messages, as depicted in Figure 10.
相関関係が発生するには、会計記録にはハンドオフ全体で何らかの共通性が必要です。したがって、ホームエージェントは、モバイルのセッションですべてのHAAで同じACCT-Multi-Session-ID AVP値を送信する必要があります。つまり、HAは、新しいセッションのHARを受信するときに一意のACCT-Multi-Session-IDを生成し、セッションのすべてのHAAでこの同じ値を返します。このacct-multi-session-id AVPは、AMAのAAAHによって外国人エージェントに返されます。外国人とホームエージェントの両方が、図10に示すように、会計メッセージにACCT-Multi-Session-IDを含める必要があります。
A foreign and home agent following this specification MAY expect their respective Diameter servers to maintain session state information for each mobile node in their networks. For a Diameter Server to release any resources allocated to a specific mobile node, that server has to receive a Session-Termination-Request (STR) from a mobility agent. The mobility agents MUST issue the Session-Termination-Request (STR) if the Authorization Lifetime has expired and no subsequent MIP registration request has been received.
この仕様に続く外国人およびホームエージェントは、それぞれの直径サーバーがネットワーク内の各モバイルノードのセッション状態情報を維持することを期待する場合があります。直径サーバーが特定のモバイルノードに割り当てられたリソースをリリースするために、そのサーバーはモビリティエージェントからセッション終端-Request（STR）を受信する必要があります。モビリティエージェントは、承認の寿命が切れており、その後のMIP登録要求が受信されなかった場合、セッション終了再（STR）を発行する必要があります。
The AAAH SHOULD only deallocate all resources after the STR is received from the home agent. This ensures that a mobile node that moves from one foreign agent to another (for example, as a result of a handover) does not cause the Home Diameter Server to free all resources for the mobile node. Therefore, an STR from a foreign agent would free the session from the foreign agent, but not the session state associated with the home agent (see Figure 10).
AAAHは、STRがホームエージェントから受信された後にのみ、すべてのリソースを扱う必要があります。これにより、ある外国人エージェントから別のエージェントに移動するモバイルノード（たとえば、ハンドオーバーの結果）がモバイルノードのすべてのリソースをホームダイアメーターサーバーに解放することはできません。したがって、外国人のエージェントからのSTRは、外国人エージェントからセッションを解放しますが、ホームエージェントに関連するセッション状態ではありません（図10を参照）。
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
Figure 10. Session Termination and Session Identifiers
図10.セッション終了とセッション識別子
When deallocating all of the mobile node's resources, the home Diameter server (and the foreign Diameter server in the case of an HA allocated in foreign network) MUST destroy all session keys that may still be valid.
すべてのモバイルノードのリソースを扱う場合、ホーム直径サーバー（および外国ネットワークに割り当てられたHAの場合の外国直径サーバー）は、まだ有効なすべてのセッションキーを破壊する必要があります。
In the event that the AAAF wishes to terminate a session, its Abort-Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. Similarly, the AAAH SHOULD send its message to the Home Agent.
AAAFがセッションを終了したい場合、その中断セッションレクエスト（ASR）[Diambase]メッセージをFAに送信する必要があります。同様に、AAAHはそのメッセージをホームエージェントに送信する必要があります。
This section defines Command-Code [DIAMBASE] values that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this specification:
このセクションでは、この仕様に準拠したすべての直径の実装でサポートする必要があるコマンドコード[Diambase]値を定義します。次のコマンドコードは、この仕様で定義されています。
Command-Name Abbreviation Code Section
-----------------------------------------------------------
AA-Mobile-Node-Request AMR 260 5.1
AA-Mobile-Node-Answer AMA 260 5.2
Home-Agent-MIP-Request HAR 262 5.3
Home-Agent-MIP-Answer HAA 262 5.4
The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field set to 260 and the 'R' bit set in the Command Flags field, is sent by an attendant (i.e., the Foreign Agent), acting as a Diameter client, to an AAAF in order to request the authentication and authorization of a mobile node. The foreign agent (or home agent in the case of a co-located Mobile Node) uses information found in the Registration Request to construct the following AVPs, to be included as part of the AMR:
260に設定されたコマンドコードフィールドとコマンドフラグフィールドに設定された「R」ビットであるAA-Mobile-Node-Request（AMR）は、アテンダント（つまり、外国人エージェント）によって送信され、モバイルノードの認証と承認を要求するために、AAAFへの直径クライアント。外国人エージェント（または共同配置されたモバイルノードの場合のホームエージェント）は、登録要求で見つかった情報を使用して、AMRの一部として含まれる次のAVPを構築するために使用します。
Home Address (MIP-Mobile-Node-Address AVP) Home Agent Address (MIP-Home-Agent-Address AVP) Mobile Node NAI (User-Name AVP [DIAMBASE]) MN-HA Key Request (MIP-Feature-Vector AVP) MN-FA Key Request (MIP-Feature-Vector AVP) MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) Foreign Agent Challenge Extension (MIP-FA-Challenge AVP) Home Agent NAI (MIP-Home-Agent-Host AVP) Home AAA server NAI (Destination-Host AVP [DIAMBASE]) Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP)
ホームアドレス（MIP-Mobile-Node-Address AVP）ホームエージェントアドレス（MIP-Home-Agent-Address AVP）モバイルノードNAI（ユーザー名AVP [DiamBase]）Mn-HAキーリクエスト（MIP-Feature-Vector AVP）MN-FAキーリクエスト（MIP-Feature-Vector AVP）MN-AAA認証拡張（MIP-MN-AAA-AUTH AVP）外国人エージェントチャレンジ拡張（MIP-FA-Challenge AVP）ホームエージェントNAI（MIP-Home-Agent-ホストAVP）ホームAAAサーバーNAI（Destination-Host AVP [Diambase]）外国人エージェントSPIのホームエージェント（MIP-HA-TO-FA-SPI AVP）
If the mobile node's home address is zero, the foreign or home agent MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the home agent address is zero or all ones, the MIP-Home-Agent-Address AVP MUST NOT be present in the AMR.
モバイルノードのホームアドレスがゼロの場合、外国人またはホームエージェントには、AMRにMIP-Mobile-Node-Address AVPを含めてはなりません。ホームエージェントのアドレスがゼロまたはすべての場合、MIP-Home-Agent-Address AVPがAMRに存在してはなりません。
If a home agent is used in a visited network, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in the AMR message to indicate that it is willing to assign a Home Agent in the visited realm.
訪問されたネットワークでホームエージェントが使用されている場合、AAAFはAMRメッセージのMIP-Feature-Vector AVPに外国の家庭エージェント利用可能なフラグを設定して、訪問されたホームエージェントを訪問したホームエージェントを割り当てることをいとわないことを示します。領域。
If the mobile node's home address is all ones, the foreign or home agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones.
モバイルノードのホームアドレスがすべての場合、外国人またはホームエージェントには、すべてのものに設定されたMIP-Mobile-Node-Address AVPを含める必要があります。
If the mobile node includes the home agent NAI and the home AAA server NAI [AAANAI], the foreign agent MUST include the MIP-Home-Agent-Host AVP and the Destination-Host AVP in the AMR.
モバイルノードにホームエージェントNAIとホームAAAサーバーNAI [AAANAI]が含まれている場合、外国人エージェントには、AMRにMIP-Home-Agent-Host AVPと宛先ホストAVPを含める必要があります。
Message Format
メッセージ形式
<AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ MIP-Reg-Request }
{ MIP-MN-AAA-Auth }
[ Acct-Multi-Session-Id ]
[ Destination-Host ]
[ Origin-State-Id ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Feature-Vector ]
[ MIP-Originating-Foreign-AAA ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ MIP-FA-Challenge ]
[ MIP-Candidate-Home-Agent-Host ]
[ MIP-Home-Agent-Host ]
[ MIP-HA-to-FA-SPI ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field set to 260 and the 'R' bit cleared in the Command Flags field, is sent by the AAAH in response to the AA-Mobile-Node-Request message. The User-Name MAY be included in the AMA if it is present in the AMR. The Result-Code AVP MAY contain one of the values defined in section 6, in addition to the values defined in [DIAMBASE].
260に設定されたコマンドコードフィールドとコマンドフラグフィールドでビットがクリアされた「R」で示されるAA-Mobile-Node-Answer（AMA）は、AA-Mobile-Node-に応じてAAAHによって送信されます。メッセージを要求します。AMRに存在する場合、ユーザー名はAMAに含まれる場合があります。結果コードAVPには、[Diambase]で定義されている値に加えて、セクション6で定義された値の1つを含める場合があります。
An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned to the mobile node, while the MIP-Mobile-Node-Address AVP contains the home address that was assigned. The AMA message MUST contain the MIP-FA-to-HA-MSA and MIP-FA-to-MN-MSA if they were requested in the AMR and were present in the HAR. The MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA AVPs MUST be present if the session keys were requested in the AMR and the Co-Located-Mobile-Node bit was set in the MIP-Feature-Vector AVP.
結果コードAVPをDiameter_Successに設定したAMAメッセージには、MIP-Home-Agent-Address AVPを含める必要があり、MIP-Mobile-Node-Address AVPを含める必要があり、MIP-Reg-Reply AVPが含まれています。Co-Located-Mobile-Nodeビットは、MIP-Feature-Vector AVPには設定されていません。MIP-Home-Agent-Address AVPには、モバイルノードに割り当てられたホームエージェントが含まれ、MIP-Mobile-Node-Address AVPには割り当てられたホームアドレスが含まれています。AMAメッセージには、AMRでリクエストされ、HARに存在する場合、AMAメッセージにはMIP-FA-To-HA-MSAおよびMIP-FA-TO-MN-MSAが含まれている必要があります。MIP-MN-To-HA-MSAおよびMIP-HA-TO-MN-MSA AVPSが存在する必要があります。 - ベクトルAVP。
Message Format
メッセージ形式
<AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP-Feature-Vector ]
[ MIP-Reg-Reply ]
[ MIP-MN-to-FA-MSA ]
[ MIP-MN-to-HA-MSA ]
[ MIP-FA-to-MN-MSA ]
[ MIP-FA-to-HA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
The AAA sends the Home-Agent-MIP-Request (HAR), indicated by the Command-Code field set to 262 and the 'R' bit set in the Command Flags field, to the Home Agent. If the Home Agent is to be assigned in a foreign network, the HAR is issued by the AAAH and forwarded by the AAAF to the HA if no redirect servers are involved. If any are, the HAR is sent directly to the HA via a security association. If the HAR message does not include a MIP-Mobile-Node-Address AVP, the Registration Request has 0.0.0.0 for the home address, and the HAR is successfully processed, the Home Agent MUST allocate the mobile nodes address. If, on the other hand, the home agent's local AAA server allocates the mobile node's home address, the local AAA server MUST include the assigned address in a MIP-Mobile-Node-Address AVP.
AAAは、コマンドコードフィールドが262に設定され、コマンドフラグフィールドに設定された「R」ビットで、ホームエージェントに設定されたホームエージェントミップレクエスト（HAR）を送信します。ホームエージェントが外国ネットワークに割り当てられる場合、HARはAAAHによって発行され、リダイレクトサーバーが関与していない場合はAAAFによってHAに転送されます。ある場合、HARはセキュリティ協会を介してHAに直接送信されます。HARメッセージにMIP-Mobile-Node-Address AVPが含まれていない場合、登録要求にはホームアドレスの0.0.0.0があり、HARは正常に処理されます。ホームエージェントはモバイルノードアドレスを割り当てる必要があります。一方、ホームエージェントのローカルAAAサーバーがモバイルノードのホームアドレスを割り当てる場合、ローカルAAAサーバーには、MIP-Mobile-Node-Address AVPに割り当てられたアドレスを含める必要があります。
When session keys are requested for use by the mobile node, the AAAH MUST create them and include them in the HAR message. When a FA-HA session key is requested, it will be created and distributed by the AAAH server.
セッションキーがモバイルノードで使用されるように要求される場合、AAAHはそれらを作成し、HARメッセージに含める必要があります。FA-HAセッションキーが要求されると、AAAHサーバーによって作成および配布されます。
Message Format
メッセージ形式
<Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Session-State }
{ MIP-Reg-Request }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ MIP-Feature-Vector }
[ Destination-Host ]
[ MIP-MN-to-HA-MSA ]
[ MIP-MN-to-FA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-HA-to-FA-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Originating-Foreign-AAA ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
In response to a Home-Agent-MIP-Request, the Home Agent sends the Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field set to 262 and the 'R' bit cleared in the Command Flags field, to its local AAA server. The User-Name MAY be included in the HAA if it is present in the HAR. If the home agent allocated a home address for the mobile node, the address MUST be included in the MIP-Mobile-Node-Address AVP. The Result-Code AVP MAY contain one of the values defined in section 6 instead of the values defined in [DIAMBASE].
Home-Agent-Mip-Requestに応じて、ホームエージェントはホームエージェント-Mip-Answer（HAA）を送信します。、ローカルAAAサーバーへ。ユーザー名は、HARに存在する場合、HAAに含まれる場合があります。ホームエージェントがモバイルノードのホームアドレスを割り当てた場合、アドレスはMIP-Mobile-Node-Address AVPに含める必要があります。結果コードAVPには、[Diambase]で定義されている値の代わりに、セクション6で定義された値の1つを含める場合があります。
Message Format
メッセージ形式
<Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Error-Reporting-Host ]
[ Error-Message ]
[ MIP-Reg-Reply ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
[ MIP-FA-to-HA-SPI ]
[ MIP-FA-to-MN-SPI ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
This section defines new Result-Code [DIAMBASE] values that MUST be supported by all Diameter implementations that conform to this specification.
このセクションでは、この仕様に準拠するすべての直径の実装でサポートする必要がある新しい結果コード[Diambase]値を定義します。
Errors in the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but that it may be able to satisfy the request in the future.
過渡障害カテゴリのエラーは、受け取った時点でリクエストが満たされなかったが、将来的にリクエストを満たすことができるかもしれないことをピアに通知するために使用されます。
DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 This error code is used by the home agent when processing of the Registration Request has failed.
diameter_error_mip_reply_failure 4005このエラーコードは、登録要求の処理が失敗したときにホームエージェントによって使用されます。
DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 This error code is used to inform the foreign agent that the requested Home Agent cannot be assigned to the mobile node at this time. The foreign agent MUST return a Mobile IPv4 Registration Reply to the mobile node with an appropriate error code.
diameter_error_ha_not_available 4006このエラーコードは、この時点で要求されたホームエージェントをモバイルノードに割り当てることができないことを外部エージェントに通知するために使用されます。外国人エージェントは、適切なエラーコードを使用して、モバイルIPv4登録返信をモバイルノードに返信する必要があります。
DIAMETER_ERROR_BAD_KEY 4007 This error code is used by the home agent to indicate to the local Diameter server that the key generated is invalid.
diameter_error_bad_key 4007このエラーコードは、ホームエージェントによって使用されて、生成されたキーが無効であることをローカルDiameterサーバーに示すために使用されます。
DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008 This error code is used by a mobility agent to indicate to the home Diameter server that the requested packet filter Rules cannot be supported.
diameter_error_mip_filter_not_supported 4008このエラーコードは、モビリティエージェントによって使用されて、要求されたパケットフィルタールールをサポートできないことをホームダイアムサーバーに示すために使用されます。
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_NO_FOREIGN_HA_SERVICE 5024 This error is used by the AAAF to inform the AAAH that allocation of a home agent in the foreign domain is not permitted at this time.
diameter_error_no_foreign_ha_service 5024このエラーは、AAAFによって使用され、AAAHに、外国ドメインにホームエージェントの割り当てが許可されていないことを通知します。
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 This error is used by the AAAF/AAAH to inform the peer that the requested Mobile IPv4 session keys could not be delivered via a security association.
diameter_error_end_to_end_mip_key_encryption 5025このエラーは、AAAF/AAAHによって使用され、要求されたモバイルIPv4セッションキーがセキュリティ協会を介して配信できないことをピアに通知します。
The following table describes the Diameter AVPs defined in the Mobile IPv4 application; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted.
次の表は、モバイルIPv4アプリケーションで定義されている直径AVPを説明しています。AVPコード値、タイプ、および可能なフラグ値。AVPが暗号化されるかどうか。
Due to space constraints, the short form IPFiltrRule is used to represent IPFilterRule, and DiamIdent is used to represent DiameterIdentity.
スペースの制約により、IPFilTrruleの短い形式はIPFilterruleを表すために使用され、DiamedidentはAimeterIdentityを表すために使用されます。
+--------------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y |
MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y |
MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y |
MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y |
Address
MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y |
Address
MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N |
Home-Agent-Host
MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y |
Vector
MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y |
Data-Length
MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y |
Authenticator-Length
MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y |
Authenticator-Offset
MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y |
MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y |
MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y |
MIP-Originating- 347 7.10 Grouped | M | P | | V | Y |
Foreign-AAA
MIP-Home-Agent- 348 7.11 DiamIdent | M | P | | V | N |
Host
The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the mobile node to the foreign agent.
MIP-Reg-Request AVP（AVPコード320）はタイプのオクテットストリングであり、モバイルノードから外国エージェントに送信されるモバイルIPv4登録要求[MobileIP]が含まれています。
The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the home agent to the foreign agent.
MIP-Reg-Reply AVP（AVPコード321）はタイプのオクテットストリングであり、ホームエージェントから外国人エージェントに送信されるモバイルIPv4登録応答[MobileIP]が含まれています。
The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and contains the mobile node's home IP address.
MIP-Mobile-Node-Address AVP（AVPコード333）はタイプアドレスで、モバイルノードのホームIPアドレスが含まれています。
The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and contains the mobile node's home agent IP address.
MIP-Home-Agent-Address AVP（AVPコード334）はタイプアドレスで、モバイルノードのホームエージェントIPアドレスが含まれています。
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and is added with flag values set by the foreign agent or by the AAAF owned by the same administrative domain as the foreign agent. The foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR message it sends to the AAAF.
MIP-Feature-Vector AVP（AVPコード337）は、符号なし32型であり、外国人エージェントまたは外国人エージェントと同じ管理ドメインが所有するAAAFによって設定されたFLAG値で追加されています。外国人エージェントには、AAAFに送信するAMRメッセージ内にMIP-Feature-Vector AVPを含める必要があります。
Flag values currently defined include the following:
現在定義されているフラグの値には、以下が含まれます。
1 Mobile-Node-Home-Address-Requested 2 Home-Address-Allocatable-Only-in-Home-Realm 4 Home-Agent-Requested 8 Foreign-Home-Agent-Available 16 MN-HA-Key-Request 32 MN-FA-Key-Request 64 FA-HA-Key-Request 128 Home-Agent-In-Foreign-Network 256 Co-Located-Mobile-Node
1モバイルノードホームアドレス - リクエスト2ホームアドレスアロカチュア可能な在宅勤務済みのリアルム4ホームエージェント要求8 foreign-home-agent-abailable 16 mn-ha-key-request 32 mn-fa-key-request 64 fa-ha-key-request 128 Home-agent-in-foreign-network 256 Co-Located-Mobile-Node
The flags are set according to the following rules.
フラグは、次のルールに従って設定されます。
If the mobile node includes a valid home address (i.e., one not equal to 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign agent sets the Mobile-Node-Home-Address-Requested flag in the MIP-Feature-Vector AVP to zero.
モバイルノードに有効なホームアドレスが含まれている場合（つまり、0.0.0.0または255.255.255.255に等しくないもの）、登録リクエストで、外国人エージェントはMIP-Feature-にモバイルノードとホーム - アドレスの再クエストされたフラグを設定します。ベクトルAVPからゼロ。
If the mobile node sets the home agent field equal to 255.255.255.255 in its Registration Request, the foreign agent sets both the Home-Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home-Realm flag to one in the MIP-Feature-Vector AVP.
モバイルノードが登録リクエストでホームエージェントフィールドを255.255.255.255に設定した場合、外国人エージェントはホームエージェント要求のフラグとホームアドレスアロカテーブルのみの在宅旗の両方を設定します。MIP-Feature-Vector AVP。
If the mobile node sets the home agent field equal to 0.0.0.0 in its Registration Request, the foreign agent sets the Home-Agent-Requested flag to one and zeroes the Home-Address-Allocatable-Only-in-Home-Realm flag in the MIP-Feature-Vector AVP.
モバイルノードが登録リクエストでホームエージェントフィールドを0.0.0.0に設定した場合、外国人エージェントはホームエージェントのリクエストされたフラグを1つに設定し、Home-Address-Allocatableのみの在宅領域フラグをゼロにしますMIP-Feature-Vector AVP。
Whenever the foreign agent sets either the Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested flag to one, it MUST set the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set to one if the mobile node includes a "Generalized MN-HA Key Generation Nonce Request" [MIPKEYS] extension, with the subtype set to AAA.
外国人エージェントがモバイルノードホームアドレスリクエストされたフラグまたはホームエージェントリクエストされたフラグを1つに設定するときはいつでも、Mn-Ha-Key-Requestフラグを1つに設定する必要があります。Mn-Ha-Key-Requestフラグは、モバイルノードに「一般化されたMN-HAキージェネレーションノンセリクエスト」[Mipkeys]拡張機能が含まれている場合、1つに設定されています。サブタイプがAAAに設定されています。
If the mobile node includes a "Generalized MN-FA Key Generation Nonce Request" [MIPKEYS] extension with the AAA subtype (1) in its Registration Request, the foreign agent sets the MN-FA-Key-Request flag to one in the MIP-Feature-Vector AVP.
モバイルノードに「一般化されたMN-FAキージェネレーションノンセリクエスト」[MIPKEYS]拡張が登録要求にAAAサブタイプ（1）を含む場合、外国人エージェントはMN-FA-Key-RequestフラグをMIPに1つに設定します。-feature-Vector AVP。
If the mobile node requests a home agent in the foreign network either by setting the home address field to all ones, or by specifying a home agent in the foreign network, and the AAAF authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-Network bit to one.
モバイルノードは、すべてのものにホームアドレスフィールドを設定するか、外国ネットワークでホームエージェントを指定し、AAAFがリクエストを承認することにより、外国ネットワーク内のホームエージェントに要求する場合、AAAFはホームエージェントを設定する必要があります。in-foreign-networkビットから1つ。
If the AAAF is willing and able to assign a home agent in the foreign network, the AAAF sets the Foreign-Home-Agent-Available flag to one.
AAAFが外国のネットワークにホームエージェントを割り当てることを望んでいて、AAAFは外国の家のエージェント利用可能なフラグを1つに設定します。
If the Home Agent receives a Registration Request from the mobile node indicating that the MN is acting as a co-located mobile node, the home agent sets the Co-Located-Mobile-Node bit to one.
ホームエージェントがMNが共同でモバイルノードとして機能していることを示すモバイルノードから登録要求を受信した場合、ホームエージェントは共同ロケートモバイルノードビットを1に設定します。
If the foreign agent's local policy allows it to receive AAA session keys and it does not have any existing FA-HA key with the home agent, the foreign agent MAY set the FA-HA-Key-Request flag.
外国のエージェントのローカルポリシーでAAAセッションキーを受け取ることができ、ホームエージェントに既存のFA-HAキーがない場合、外国人エージェントはFA-Ha-Key-Requestフラグを設定することができます。
The foreign agent MUST NOT set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flag both to one.
外国人のエージェントは、外国の在宅エージェント利用可能であり、ホームエージェントの外国人ネットワークフラグを両方に設定してはなりません。
When the AAAF receives the AMR message, it MUST first verify that the sender was an authorized foreign agent. The AAAF then takes any actions indicated by the settings of the MIP-Feature-Vector AVP flags. The AAAF then MAY set additional flags. Only the AAAF may set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flags to one. This is done according to local administrative policy. When the AAAF has finished setting additional flags according to its local policy, then the AAAF transmits the AMR with the possibly modified MIP-Feature-Vector AVP to the AAAH.
AAAFがAMRメッセージを受信した場合、最初に送信者が許可された外国人エージェントであることを確認する必要があります。AAAFは、MIP-Feature-Vector AVPフラグの設定によって示されるアクションを実行します。AAAFは、追加のフラグを設定する場合があります。AAAFのみが、外国の在宅エージェント利用可能でホームエージェントの外国のネットワークフラグを1つに設定することができます。これは、現地の管理ポリシーに従って行われます。AAAFがローカルポリシーに従って追加のフラグの設定が完了したとき、AAAFはAMRを変更されたMIP-Feature-Vector AVPをAAAHに送信します。
The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains some ancillary data to simplify processing of the authentication data in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the target AAA server. Its value has the following ABNF grammar:
MN-AAA-Auth AVP（AVPコード322）はグループ化されたタイプで、ターゲットAAAサーバーによるモバイルIPv4登録要求[MobileIP、Mipchal]の認証データの処理を簡素化するための補助データを含んでいます。その価値には、次のABNF文法があります。
MIP-MN-AAA-Auth ::= < AVP Header: 322 >
{ MIP-MN-AAA-SPI }
{ MIP-Auth-Input-Data-Length }
{ MIP-Authenticator-Length }
{ MIP-Authenticator-Offset }
* [ AVP ]
The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and indicates the MSA by which the targeted AAA server (AAAH) should attempt to validate the Authenticator computed by the mobile node over the Registration Request data.
MIP-MN-AAA-SPI AVP（AVP Code 341）はsunsigned32型であり、ターゲットを絞ったAAAサーバー（AAAH）が登録要求データを介してモバイルノードによって計算された認証機を検証しようとするMSAを示します。
The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type Unsigned32 and contains the length, in bytes, of the Registration Request data (data portion of MIP-Reg-Request AVP) that should be used as input to the algorithm, as indicated by the MN-AAA-SPI AVP, used to determine whether the Authenticator Data supplied by the mobile node is valid.
MIP-Auth-Input-Data-Length AVP（AVP Code 338）はタイプunsigned32で、登録要求データ（MIP-Reg-Request AVPのデータ部分）の長さが入力として使用する必要があります。MN-AAA-SPI AVPで示されているように、アルゴリズムに対して、モバイルノードによって提供される認証データが有効かどうかを判断するために使用されます。
The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 and contains the length of the authenticator to be validated by the targeted AAA server (i.e., AAAH).
MIP-Authenticator-Length AVP（AVP Code 339）は型Unsigned32であり、ターゲットを絞ったAAAサーバー（つまり、AAAH）によって検証される認証器の長さが含まれています。
The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 and contains the offset into the Registration Request Data, of the authenticator to be validated by the targeted AAA server (i.e., AAAH).
MIP-authenticator-Offset AVP（AVPコード340）はタイプunsigned32であり、登録要求データへのオフセットを含み、ターゲットを絞ったAAAサーバー（つまり、AAAH）によって検証される認証器のオフセットが含まれています。
The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and contains the challenge advertised by the foreign agent to the mobile node. This AVP MUST be present in the AMR if the mobile node used the RADIUS-style MN-AAA computation algorithm [MIPCHAL].
MIP-FA-Challenge AVP（AVPコード344）はタイプのオクテットストリングであり、モバイルノードに外国人エージェントによって宣伝された課題が含まれています。モバイルノードがRadiusスタイルのMN-AAA計算アルゴリズム[Mipchal]を使用した場合、このAVPはAMRに存在する必要があります。
The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule and provides filter rules that have to be configured on the foreign or home agent for the user. The packet filtering rules are set by the AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if destined for the home agent and/or in the AMA if destined for the foreign agent.
MIP-Filter-Rule AVP（AVPコード342）はタイプIPFilterRuleであり、ユーザーの外国人またはホームエージェントで構成する必要があるフィルタールールを提供します。パケットフィルタリングルールは、HARに運命づけられている場合はHARに1つ以上のMIP-Filter-Rule AVPを追加し、外国人エージェントに向けてAMAに追加することにより、AAAHによって設定されます。
The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type DiameterIdentity and contains the identity of a home agent in the foreign network that the AAAF proposes to be dynamically assigned to the mobile node.
MIP-Candidate-Home-Agent-Host AVP（AVPコード336）は、直径のタイプであり、AAAFがモバイルノードに動的に割り当てることを提案する外国ネットワーク内のホームエージェントのIDが含まれています。
The MIP-Originating-Foreign-AAA AVP (AVP Code 347) is of type Grouped and contains the identity of the AAAF, which issues the AMR to the AAAH. The MIP-Originating-Foreign-AAA AVP MUST only be used in cases when the home agent is or may be allocated in a foreign domain. If the MIP-Originating-Foreign-AAA AVP is present in the AMR, the AAAH MUST copy it into the HAR.
MIP-Originating-Foreign-AAA AVP（AVPコード347）はグループ化されており、AAAFのアイデンティティが含まれており、AAAHにAMRを発行します。MIP-Originating-Foreign-AAA AVPは、ホームエージェントが外部ドメインで割り当てられる場合、または割り当てられる場合にのみ使用する必要があります。MIP-Originating-Foreign-AAA AVPがAMRに存在する場合、AAAHはそれをHARにコピーしなければなりません。
MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
{ Origin-Realm }
{ Origin-Host }
* [ AVP ]
The MIP-Home-Agent-Host AVP (AVP Code 348) is of type Grouped and contains the identity of the assigned Home Agent. If the MIP-Home-Agent-Host AVP is present in the AMR, the AAAH MUST copy it into the HAR.
MIP-Home-Agent-Host AVP（AVPコード348）はグループ化されたタイプで、割り当てられたホームエージェントのIDが含まれています。MIP-Home-Agent-Host AVPがAMRに存在する場合、AAAHはそれをHARにコピーする必要があります。
MIP-Home-Agent-Host ::= < AVP Header: 348 >
{ Destination-Realm }
{ Destination-Host }
* [ AVP ]
The mobile node and mobility agents use session keys (i.e., the MN-FA, FA-HA, and MN-HA session keys) to compute authentication extensions applied to MIP registration messages, as defined in [MOBILEIP]. If session keys are requested, the AAAH MUST return the keys and nonces after the mobile node is successfully authenticated and authorized.
モバイルノードとモビリティエージェントは、[MovelIP]で定義されているように、MIP登録メッセージに適用される認証拡張機能を計算するために、セッションキー（MN-FA、FA-HA、およびMN-HAセッションキー）を使用します。セッションキーが要求された場合、AAAHはモバイルノードが正常に認証され、承認された後にキーとノンセを返す必要があります。
The SPI values are used as key identifiers, and each session key has its own SPI value; nodes that share a key can have multiple different SPIs all referring to the same key. In all cases, the entity that receives an authentication extension (i.e., that verifies the authentication extension) is providing the entity that sends the authentication extension (i.e., that computes the authentication extension) the value of the SPI to use for that computation. Note that the keys in this model are symmetric in that they are used in both directions, even though the SPIs do not have to be symmetric.
SPI値はキー識別子として使用され、各セッションキーには独自のSPI値があります。キーを共有するノードは、同じキーを参照して、複数の異なるスピスを持つことができます。すべての場合において、認証拡張機能（つまり、認証拡張を検証する）を受信するエンティティは、認証拡張機能（つまり、認証拡張機能を計算する）を送信するエンティティを提供しています。このモデルのキーは、SPIが対称である必要がない場合でも、両方向に使用されるという点で対称であることに注意してください。
The mobile node allocates SPIs for use in the FA-MN and HA-MN mobility security associations, via the Mobile IPv4 AAA Key Request extensions [MIPKEYS]. The home agent allocates SPIs for the MN-HA and FA-HA mobility security association. The foreign agent chooses SPIs for the MN-FA and HA-FA mobility security associations.
モバイルノードは、モバイルIPv4 AAAキー要求拡張機能[MIPKEYS]を介して、FA-MNおよびHA-MNモビリティセキュリティアソシエーションで使用するためにSPIを割り当てます。ホームエージェントは、MN-HAおよびFA-HAモビリティセキュリティ協会にSPIを割り当てます。外国人エージェントは、MN-FAおよびHA-FAモビリティセキュリティ協会のSPIを選択します。
Once the session keys and nonces have been distributed, subsequent Mobile IPv4 registrations need not invoke the AAA infrastructure until the keys expire. As mandated by Mobile IPv4, these registrations MUST include the MN-HA authentication extension. Likewise, subsequent registrations MUST also include MN-FA authentication extension if the MN-FA session key was generated and distributed by AAA. The same hold true for subsequent use of the FA-HA authentication extensions.
セッションキーとNoncesが配布されると、その後のモバイルIPv4登録は、キーが期限切れになるまでAAAインフラストラクチャを呼び出す必要はありません。モバイルIPv4によって義務付けられているように、これらの登録にはMN-HA認証拡張機能を含める必要があります。同様に、後続の登録には、MN-FAセッションキーがAAAによって生成および配布された場合、MN-FA認証拡張機能も含める必要があります。同じことが、FA-HA認証拡張機能のその後の使用についても当てはまります。
The Diameter Mobile IPv4 application makes use of two timers: the Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP.
Diameter Mobile IPv4アプリケーションは、Authorization-Lifetime AVP [Diambase]とMIP-MSA-Lifetime AVPの2つのタイマーを使用します。
The Authorization-Lifetime contains the number of seconds before the mobile node must issue a subsequent MIP registration request. The content of the Authorization-Lifetime AVP corresponds to the Lifetime field in the MIP header [MOBILEIP].
Authorization-Lifetimeには、モバイルノードが後続のMIP登録リクエストを発行する必要がある秒数が含まれています。認証 - ラフタイムAVPの内容は、MIPヘッダー[MobileIP]の生涯フィールドに対応しています。
The MIP-MSA-Lifetime AVP contains the number of seconds before session keys destined for the mobility agents and the mobile node expire. A value of zero indicates infinity (no timeout). If not zero, the value of the MIP-MSA-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP.
MIP-MSA-Lifetime AVPには、モビリティエージェント用のセッションキーの前の秒数が含まれ、モバイルノードの有効期限が切れます。ゼロの値は、無限（タイムアウトなし）を示します。ゼロではない場合、MIP-MSA-Lifetime AVPの値は、承認ライフタイムAVPの値に少なくとも等しい必要があります。
As described in section 3.4, the AAAH generates session keys and transmits them to the home agent and foreign agent. The AAAH generates nonces that correspond to the same keys and transmits them to the mobile node. When it is necessary to protect the session keys and SPIs from un-trusted Diameter agents, end-to-end security mechanisms such as TLS or IPSec are required to eliminate all Diameter Agents between the FA or HA and the AAAH, as outlined above.
セクション3.4で説明されているように、AAAHはセッションキーを生成し、ホームエージェントと外国人エージェントに送信します。AAAHは、同じキーに対応するNoncesを生成し、モバイルノードに送信します。セッションキーとスピスをトラストされていない直径エージェントから保護する必要がある場合、上記のように、FAまたはHAとAAAHの間のすべての直径エージェントを排除するには、TLSやIPSECなどのエンドツーエンドのセキュリティメカニズムが必要です。
In [MIPKEYS], the mobility security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH must generate a random [RANDOM] value of at least 128 bits [MIPKEYS]. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys.
[Mipkeys]では、モバイルIPv4を介してモバイルノードに送信されたNoncesを介してモビリティセキュリティアソシエーションが確立されます。Noncesを提供するには、AAAHは少なくとも128ビット[Mipkeys]のランダム[ランダム]値を生成する必要があります。モバイルノードは、NonCEを使用してMN-HAおよびMN-FAセッションキーを導出します。
More details of the MN-HA and the MN-FA session key creation procedures are found in [MIPKEYS].
MN-HAおよびMN-FAセッションのキー作成手順の詳細については、[Mipkeys]にあります。
The hashing algorithm used by the mobile node to construct the session key has to be the same as that used by the AAAH in the session key generation procedure. The AAAH therefore indicates the algorithm used along with the nonce.
セッションキーを構築するためにモバイルノードで使用されるハッシュアルゴリズムは、セッションキー生成手順でAAAHが使用するものと同じでなければなりません。したがって、AAAHは、NonCeとともに使用されるアルゴリズムを示します。
The FA-HA and HA-FA session key is shared between the FA and HA. The AAAH generates a random [RANDOM] value of at least 128 bits for use as this session key.
FA-HAおよびHA-FAセッションキーは、FAとHAの間で共有されます。AAAHは、このセッションキーとして使用するために少なくとも128ビットのランダム[ランダム]値を生成します。
See sections 9 for details about the format of the AVPs used to transport the session keys.
セッションキーの輸送に使用されるAVPの形式の詳細については、セクション9を参照してください。
If the mobile node does not have an MN-HA session key, then the AAAH is likely to be the only trusted entity that is available to the mobile node. Thus, the AAAH has to generate the MN-HA session key.
モバイルノードにMN-HAセッションキーがない場合、AAAHはモバイルノードで利用可能な唯一の信頼できるエンティティである可能性があります。したがって、AAAHはMN-HAセッションキーを生成する必要があります。
The distribution of the HA-MN (session) key to the HA is specified in sections 1.2 and 3.4. The HA and AAAH establish a security association (IPSec or TLS) and transport the key over it. If no security association exists between the AAAH and the home agent and a security association cannot be established, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
HAのHA-MN（セッション）キーの分布は、セクション1.2および3.4で指定されています。HAとAAAHはセキュリティ協会（IPSECまたはTLS）を設立し、その上にキーを輸送します。AAAHとホームエージェントの間にセキュリティ協会が存在し、セキュリティ協会を確立できない場合、AAAHはdiameter_error_end_to_end_mip_key_encryptionで結果コードAVPを返す必要があります。
The AAAH also has to arrange for the key to be delivered to the mobile node. Unfortunately, the AAAH only knows about Diameter messages and AVPs, and the mobile node only knows about Mobile IPv4 messages and extensions [MOBILEIP]. For this purpose, AAAH includes the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added to the HAR (for FA COA style Mobile IPv4) or to the AMA (for collocated COA-style Mobile IPv4 messages) and delivered either to a local home agent or a home agent in the visited network. Note that the mobile node will use the nonce to create the MN-HA session key by using the MN-AAA key it shares with the AAAH [MIPKEYS]. The AAAH has to rely on the home agent (which also understands Diameter) to transfer the nonce into a Mobile IPv4 "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS] in the Registration Reply message. The HA includes the SPIs proposed by the mobile node and the home agent in the "Generalized MN-HA Key Generation Nonce Request" extension. The home agent can format the Reply message and extensions correctly for eventual delivery to the mobile node. The resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP.
また、AAAHは、キーをモバイルノードに配信するよう手配する必要があります。残念ながら、AAAHは直径メッセージとAVPについてのみ知っており、モバイルノードはモバイルIPv4メッセージと拡張機能[MobileIP]についてのみ知っています。この目的のために、AAAHはMN-HA MIP-Nonce AVPをMIP-MN-to-HA-MSA AVPに含め、HAR（FA COAスタイルのモバイルIPv4の場合）またはAMA（コロケートされたCOA-の場合）に追加されます。モバイルIPv4メッセージをスタイル）し、訪問したネットワークの地元のホームエージェントまたはホームエージェントに配信されます。モバイルノードは、AAAH [Mipkeys]と共有するMN-AAAキーを使用して、NonCEを使用してMN-HAセッションキーを作成することに注意してください。AAAHは、登録返信メッセージで、NonCEをモバイルIPv4 "一般化MN-HAキージェネレーションノンセの応答[Mipkeys]に移動するモバイルIPv4に移動するために、ホームエージェント（直径も理解しています）に依存する必要があります。HAには、「一般化されたMN-HAキージェネレーションノンセリクエスト」拡張機能で、モバイルノードとホームエージェントによって提案されたSPIが含まれます。ホームエージェントは、モバイルノードに最終的に配信するために、返信メッセージと拡張機能を正しくフォーマットできます。結果の登録返信は、HAAのMip-Reg-ReplyAVPに追加されます。
The AAAH parses the HAA message, transforms it into an AMA message containing an MIP-Reg-Reply AVP, and sends the AMA message to the foreign agent. The foreign agent then uses that AVP to recreate a Registration Reply message containing the "Generalized MN-HA Key Generation Nonce Reply" extension for delivery to the mobile node.
AAAHはHAAメッセージを解析し、MIP-RegReply AVPを含むAMAメッセージに変換し、AMAメッセージを外国人エージェントに送信します。その後、外国人エージェントはそのAVPを使用して、モバイルノードへの配信のための「一般化されたMN-HAキージェネレーションNonCE Reply」拡張を含む登録応答メッセージを再現します。
In summary, the AAAH generates the MN-HA nonce, which is added to the MIP-MN-to-HA-MSA AVP, and a session key, which is added to the MIP-HA-to-MN-MSA AVP. These AVPs are delivered to the home agent in HAR or AMA messages. The home agent retains the session key for its own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a "Generalized MN-HA Key Generation Nonce Reply" extension, which is appended to the Mobile IPv4 Registration Reply message. This Registration Reply message MUST also include the HA-MN authentication extension, which is created by using the newly allocated HA-MN session key. The home agent then includes the Registration Reply message and extensions into a MIP-Reg-Reply AVP as part of the HAA message to be sent back to the AAA server.
要約すると、AAAHはMN-HA Nonceを生成します。これは、MIP-MN-To-HA-MSA AVPに追加され、MIP-HA-To-MN-MSA AVPに追加されるセッションキーです。これらのAVPは、HARまたはAMAメッセージのホームエージェントに配信されます。ホームエージェントは、独自の使用のためにセッションキーを保持し、MIP-MN-HA-MSA AVPからNonCEを「一般化されたMN-HAキージェネレーションノンセ応答」にコピーします。メッセージ。この登録返信メッセージには、新しく割り当てられたHA-MNセッションキーを使用して作成されるHA-MN認証拡張機能も含める必要があります。ホームエージェントには、登録返信メッセージと、AAAサーバーに送信されるHAAメッセージの一部として、Mip-Reg-Reply AVPへの拡張機能を含めます。
The key derived by the MN from the MN-HA session nonce is identical to the HA-MN session key provided to the HA.
MN-HAセッションNonceからMNによって導出されたキーは、HAに提供されるHA-MNセッションキーと同一です。
The MN-FA session nonce is also generated by AAAH (upon request) and added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR and copied by the home agent into a "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS] of the Mobile IPv4 Registration Reply message. The HA also includes the SPIs proposed by the mobile node and foreign agent in the "Generalized MN-FA Key Generation Nonce Request" extension. The AAAH includes the FA-MN session key in the MIP-FA-to-MN-MSA AVP in the AMA, to be used by the foreign agent in the computation of the FA-MN authentication extension.
MN-FAセッションNonceはAAAHによっても生成され（リクエストに応じて）、MIP-MNからFA-MSA AVPに追加されます。Generation nonce Reply「モバイルIPv4登録応答メッセージの「拡張機能[mipkeys]」。HAには、「一般化されたMN-FAキージェネレーションノンセリクエスト」拡張機能でモバイルノードと外国人エージェントによって提案されたSPIも含まれています。AAAHには、AMAのMIP-FA-MN-MSA AVPのFA-MNセッションキーが含まれており、FA-MN認証拡張の計算において外国人エージェントが使用します。
The key derived by the MN from the MN-FA session nonce is identical to the FA-MN session key provided to the FA.
MN-FAセッションNonceからMNによって導出されたキーは、FAに提供されるFA-MNセッションキーと同一です。
If the foreign agent requests an FA-HA session key, it also includes a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the home agent for this purpose. The AAAH generates the FA-HA session key, which is identical to the HA-FA session key, and distributes that to both the HA and the FA over respective security associations by using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs. The HA conveys the SPI that the FA MUST use in the HAA; this is similar to the way in which the FA conveys that the SPI that the HA MUST use in the AMR. The AAAH later includes these SPIs in the MIP-FA-HA-MSA and MIP-HA-FA-MSA AVPs, respectively, along with the session key.
外国人エージェントがFA-HAセッションキーを要求する場合、AMRにMIP-HA-FA-FA-SPI AVPも含まれて、この目的のためにホームエージェントが使用するSPIを伝えます。AAAHは、HA-FAセッションキーと同一のFA-HAセッションキーを生成し、MIP-HA-To-FA-MSAとMIP-を使用して、それぞれのセキュリティ協会でHAとFAの両方にそれを分配します。fa-to-ha-msa avps。HAは、FAがHAAで使用しなければならないSPIを伝えます。これは、FAがHAがAMRで使用しなければならないSPIを伝える方法に似ています。AAAHには、後にMIP-FA-HA-MSAおよびMIP-HA-FA-MSA AVPのこれらのスピスがセッションキーとともに含まれます。
Refer to Figures 2, 3, 4, and 6 for the messages involved.
関係するメッセージについては、図2、3、4、および6を参照してください。
Note that if multiple MNs are registered on the same FA and HA pair, then multiple mobility security associations would be distributed. However, only one is required to protect the Mobile IP control traffic between FA and HA. This creates an unacceptable level of state (i.e., to store the two SPIs and shared key for each FA-HA mobility security association). To improve scalability, the FA and HA may discard FA-HA mobility security associations prior to the time when they actually expire. However, if a proper discard policy is not chosen, this could cause Mobile IP messages in transit or waiting in queues for transmission to fail authentication.
複数のMNが同じFAとHAペアに登録されている場合、複数のモビリティセキュリティ関連が分散されることに注意してください。ただし、FAとHAの間のモバイルIPコントロールトラフィックを保護するために必要なのは1つだけです。これにより、容認できないレベルの状態が作成されます（つまり、2つのSPIを保存し、FA-HAモビリティセキュリティ協会ごとに共有キーを保存します）。スケーラビリティを向上させるために、FAとHAは、実際に期限切れになる前にFA-HAモビリティセキュリティ協会を破棄する場合があります。ただし、適切な廃棄ポリシーが選択されていない場合、これにより、輸送中にモバイルIPメッセージが発生するか、認証に故障するためのキューで待機する可能性があります。
The FA MUST always use the FA-HA security association with the latest expiry time when computing authentication extensions on outgoing messages. The FA MAY discard HA-FA mobility security associations 10 seconds after a new HA-FA mobility security association arrives with a later expiry time.
FAは、発信メッセージの認証拡張機能を計算する際に、最新の有効期限とともにFA-HAセキュリティ協会を常に使用する必要があります。FAは、新しいHA-FA Mobility Security Associationがその後の期限切れに到着してから10秒後にHA-FAモビリティセキュリティ協会を捨てることができます。
The HA SHOULD use the HA-FA mobility security association that has the latest expiry time when computing authentication extensions in outgoing messages. However, when the HA receives a new HA-FA mobility security association with a later expiry time, the HA SHOULD wait 4 seconds for the AMA to propagate to the FA before using the new association. Note that the HA always uses the mobility security association from the HAR when constructing the Mobile IP Registration Reply in the corresponding HAA. The HA MAY discard an FA-HA mobility security association once it receives a message authenticated by a FA-HA mobility security association with a later expiry time.
HAは、発信メッセージで認証拡張機能を計算するときに最新の有効期限があるHA-FA Mobility Security Associationを使用する必要があります。ただし、HAが後の有効期限とともに新しいHA-FAモビリティセキュリティ協会を受け取った場合、HAはAMAが新しい協会を使用する前にFAに伝播するまで4秒待つ必要があります。HAは、対応するHAAでモバイルIP登録返信を構築する際に、常にHARからモビリティセキュリティ協会を使用していることに注意してください。HAは、FA-HA Mobility Security Associationによって認証されたメッセージを受け取った後、FA-HAモビリティセキュリティ協会を廃棄する場合があります。
The Mobile-IP protocol defines a set of mobility security associations shared between the mobile node, foreign agent, and home agent. These three mobility security associations (MN-HA, MN-FA, and FA-HA) are dynamically created by the AAAH and have previously been described in sections 3.4 and 8. AAA servers supporting the Diameter Mobile IP Application MUST implement the key distribution AVPs defined in this document.
モバイルIPプロトコルは、モバイルノード、外国人エージェント、およびホームエージェントの間で共有される一連のモビリティセキュリティ協会を定義します。これらの3つのモビリティセキュリティ協会（MN-HA、MN-FA、およびFA-HA）は、AAAHによって動的に作成され、以前にセクション3.4および8で説明されています。このドキュメントで定義されています。
The names of the key distribution AVPs indicate the two entities sharing the mobility security association. The first named entity in the AVP name will use the mobility security association to create authentication extensions using the given SPI and key. The second named entity in the AVP name will use the mobility security association to verify the authentication extensions of received Mobile IP messages.
主要な分布AVPの名前は、Mobility Security Associationを共有する2つのエンティティを示しています。AVP名の最初の名前のエンティティは、Mobility Security Associationを使用して、指定されたSPIとキーを使用して認証拡張機能を作成します。AVP名の2番目の指定されたエンティティは、Mobility Security Associationを使用して、受信したモバイルIPメッセージの認証拡張機能を確認します。
For instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce, which the mobile node will use to derive the MN-HA Key, and the MIP-HA-to-MN-MSA AVP contains the MN-HA key for the home agent. Note that mobility security associations are unidirectional; however, this application delivers only one key that is shared between both unidirectional security associations that exist between two peers. The security considerations of using the same key in each direction are given in section 13. The SPIs are, however, unique to each unidirectional security association and are chosen by the peer that will receive the Mobile IP messages authenticated with that security association.
たとえば、MIP-MN-to-HA-MSA AVPには、モバイルノードがMN-HAキーを導出するために使用するMN-HA NonCe、MIP-HA-T-MN-MSA AVPにはMNが含まれています。-haホームエージェントのキー。モビリティセキュリティ協会は単方向であることに注意してください。ただし、このアプリケーションは、2つのピア間に存在する単方向セキュリティ協会の両方の間で共有されるキーが1つだけ提供されます。各方向に同じキーを使用するというセキュリティ上の考慮事項は、セクション13に記載されています。ただし、SPIは各単方向セキュリティ協会に固有のものであり、そのセキュリティ協会で認証されたモバイルIPメッセージを受け取るピアによって選択されます。
The following table describes the Diameter AVPs defined in the Mobile IP application and their AVP Code values, types, and possible flag values.
次の表は、モバイルIPアプリケーションで定義されている直径AVPと、AVPコード値、タイプ、および可能なフラグ値を説明しています。
+--------------------------+
| AVP Flag Rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y |
MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y |
MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y |
MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y |
MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y |
MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y |
MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y |
MIP-Nonce 335 9.12 OctetString| M | P | | V | Y |
MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y |
MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y |
Type
MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y |
MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y |
The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped and contains the FA-MN session key. This AVP is conveyed to the FA in an AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA creates an FA-MN authentication extension by using the session key and algorithm, and the MN verifies that extension by using the same session key and algorithm. The data field of this AVP has the following ABNF grammar:
MIP-FA-to-MN-MSA AVP（AVPコード326）はグループ化されたタイプで、FA-MNセッションキーが含まれています。このAVPは、AMAメッセージでFAに伝えられます。MNはMIP-FA-to-MN-SPIを割り当てます。FAは、セッションキーとアルゴリズムを使用してFA-MN認証拡張機能を作成し、MNは同じセッションキーとアルゴリズムを使用してその拡張機能を検証します。このAVPのデータフィールドには、次のABNF文法があります。
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped and contains the FA-HA session key. This AVP is conveyed to the FA in an AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates the FA-HA authentication extension by using the session key and algorithm, and the HA verifies that extension by using the same key and algorithm. The AVP's data field has the following ABNF grammar:
MIP-FA-TO-HA-MSA AVP（AVPコード328）はグループ化されたタイプで、FA-HAセッションキーが含まれています。このAVPは、AMAメッセージでFAに伝えられます。HAは、MIP-FA-to-Ha-SPIを割り当てます。FAは、セッションキーとアルゴリズムを使用してFA-HA認証拡張機能を作成し、HAは同じキーとアルゴリズムを使用してその拡張機能を検証します。AVPのデータフィールドには、次のABNF文法があります。
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped and contains the Home Agent's session key, which it shares with the foreign agent. This AVP is conveyed to the HA in an HAR message. The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA authentication extension by using the session key and algorithm, and the FA verifies that extension by using the same session key and algorithm. The AVP's data field has the following ABNF grammar:
MIP-HA-to-FA-MSA AVP（AVPコード329）はグループ化されたタイプで、外国人エージェントと共有するホームエージェントのセッションキーが含まれています。このAVPは、HARメッセージでHAに伝えられます。FAは、MIP-HA-TO-FA-SPIを割り当てます。HAは、セッションキーとアルゴリズムを使用してHA-FA認証拡張機能を作成し、FAは同じセッションキーとアルゴリズムを使用してその拡張機能を検証します。AVPのデータフィールドには、次のABNF文法があります。
MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
{ MIP-HA-to-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and contains the HA-MN session key. This AVP is conveyed to the HA in an HAR for FA COA Mobile IPv4 and in an AMA for collocated COA Mobile IPv4. The MN allocates the MIP-HA-to-MN-SPI. The HA creates the HA-MN authentication extension by using the session key and algorithm, and the MN verifies that extension by using the same key and algorithm. The AVP's field has the following ABNF grammar:
MIP-HA-to-MN-MSA AVP（AVPコード332）はグループ化されており、HA-MNセッションキーが含まれています。このAVPは、FA COAモバイルIPv4のHARでHAに伝えられ、COAモバイルIPv4のコロークされたAMAで伝えられます。MNはMIP-HA-to-MN-SPIを割り当てます。HAは、セッションキーとアルゴリズムを使用してHA-MN認証拡張機能を作成し、MNは同じキーとアルゴリズムを使用してその拡張を検証します。AVPのフィールドには、次のABNF文法があります。
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped, and contains the MN-FA session nonce, which the mobile node uses to derive the MN-FA session key. This AVP is conveyed to the HA in an HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates the MN-FA authentication extension by using the session key and algorithm, and the FA verifies that extension using the same key and algorithm.
MIP-MN-To-FA-MSA AVP（AVPコード325）はグループ化されたタイプで、MN-FAセッションNonceが含まれています。これは、モバイルノードがMN-FAセッションキーを導出するために使用します。このAVPは、HARメッセージでHAに伝えられます。FAは、MIP-MNからFA-SPIを割り当てます。MNは、セッションキーとアルゴリズムを使用してMN-FA認証拡張機能を作成し、FAは同じキーとアルゴリズムを使用してその拡張機能を検証します。
The home agent uses this AVP in the construction of the Mobile IP "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS].
ホームエージェントは、モバイルIP「一般化されたMN-FAキージェネレーションNonCe Reply」の構築にこのAVPを使用します[mipkeys]。
MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
{ MIP-MN-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-nonce }
* [ AVP ]
The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped and contains the MN-HA session nonce, which the mobile node uses to derive the MN-HA session key. This AVP is conveyed to the HA in an HAR message for FA COA Mobile IPv4 and in an AMR for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-FA authentication extension using the session key and algorithm, and the HA verifies that extension using the same session key and algorithm.
MIP-MN-to-HA-MSA AVP（AVPコード331）はグループ化されたタイプで、MN-HAセッションNonceが含まれており、モバイルノードがMN-HAセッションキーを導出するために使用します。このAVPは、FA COAモバイルIPv4のHARメッセージと、コロケートされたモバイルIPv4のAMRでHAに伝えられます。HAは、MIP-MN-to-ha-spiを割り当てます。MNは、セッションキーとアルゴリズムを使用してMN-FA認証拡張機能を作成し、HAは同じセッションキーとアルゴリズムを使用してその拡張機能を確認します。
The Home Agent uses this AVP in the construction of the Mobile IP "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS].
ホームエージェントは、モバイルIP「一般化されたMN-HAキージェネレーションNonCe Reply」の構築にこのAVPを使用します。
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and contains the Session Key for the associated Mobile IPv4 authentication extension. The HAAA selects the session key.
MIP-Session-Key AVP（AVPコード343）はタイプのオクテットストリングで、関連するモバイルIPv4認証拡張機能のセッションキーが含まれています。HAAAはセッションキーを選択します。
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and contains the Algorithm identifier for the associated Mobile IPv4 authentication extension. The HAAA selects the algorithm type. The following values are currently defined:
MIP-ALGORITHM-TYPE AVP（AVPコード345）は列挙されており、関連するモバイルIPv4認証拡張機能のアルゴリズム識別子が含まれています。HAAAはアルゴリズムのタイプを選択します。現在、次の値が定義されています。
2 HMAC-SHA-1 [HMAC]
2 hmac-sha-1 [hmac]
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode the Home Agent for authenticating the mobile node. The HAAA selects the replay mode.
MIP-Replay-Mode AVP（AVPコード346）は列挙されており、モバイルノードを認証するためのホームエージェントにリプレイモードが含まれています。HAAAはリプレイモードを選択します。
The following values are supported (see [MOBILEIP] for more information):
次の値がサポートされています（詳細については[MobileIP]を参照）。
1 None 2 Timestamps 3 Nonces
1なし2タイムスタンプ3 Nonces
The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and it contains the Security Parameter Index the FA that and MN use to refer to the FA-MN mobility security association. The MN allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP-FA-to-MN-SPI AVP（AVPコード319）は、signed32のタイプであり、FAとMNがFA-MN Mobility Security Associationを参照するために使用するセキュリティパラメーターインデックスが含まれています。MNはSPIを割り当て、[MobileIP]で定義されている予約済みの名前空間であるゼロ（0）と255の間に値を持たないようにしてはなりません。
The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32 and contains the Security Parameter Index the FA and HA use to refer to the FA-HA mobility security association. The HA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP-FA-HA-SPI AVP（AVPコード318）は、signed32型であり、FAとHAがFA-HA Mobility Security Associationを参照するために使用するセキュリティパラメーターインデックスが含まれています。HAはSPIを割り当て、ゼロ（0）と255の間に値を持たないようにしてはなりません。
The MIP-Nonce AVP (AVP Code 335) is of type OctetString and contains the nonce sent to the mobile node for the associated authentication extension. The mobile node follows the procedures in [MIPKEYS] to generate the session key used to authenticate Mobile IPv4 registration messages. The HAAA selects the nonce.
MIP-Nonce AVP（AVPコード335）はタイプのオクテットストリングで、関連する認証拡張機能のためにモバイルノードに送信されたNonCEが含まれています。モバイルノードは、[Mipkeys]の手順に従って、モバイルIPv4登録メッセージの認証に使用されるセッションキーを生成します。HAAAはNONCEを選択します。
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 or nonce is valid. The associated session key or nonce, as the case may be, MUST NOT be used if the lifetime has expired; if the session key or nonce lifetime expires while the session to which it applies is still active, either the session key or nonce MUST be changed or the association Mobile IPv4 session MUST be terminated.
MIP-MSA-LIFETIME AVP（AVPコード367）は、符号なし32型であり、セッションキーまたは非CEが有効な期間（秒）を表します。場合によっては、関連するセッションキーまたは非CEは、寿命が切れた場合は使用しないでください。セッションキーまたはNonCe Lifetimeが適用されるセッションがまだアクティブになっている間に期限切れになった場合、セッションキーまたはNonCEを変更するか、AssociationモバイルIPv4セッションを終了する必要があります。
The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32 and contains the Security Parameter Index the HA and FA use to refer to the HA-FA mobility security association. The FA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP-HA-FA-FA-SPI AVP（AVPコード323）は、HAとFAがHA-FA Mobility Security Associationを参照するために使用するセキュリティパラメーターインデックスを順調に署名していないタイプです。FAはSPIを割り当て、ゼロ（0）と255の間に値を持たないようにしてはなりません。
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received from the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
ACOUNTING-INPUT-OCTETS AVP（AVP Code 363）は、符号なし64であり、ユーザーから受信したIPパケットにオクテットの数が含まれています。このAVPは、すべてのアカウンティングレクエストメッセージに含める必要があり、対応する会計応答メッセージにも存在する場合があります。
The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64 and contains the number of octets in IP packets sent to the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
ACOUNTING-OUTPUT-OCTETS AVP（AVP Code 364）は、signed64のタイプで、ユーザーに送信されるIPパケットにオクテットの数が含まれています。このAVPは、すべてのアカウンティングレクエストメッセージに含める必要があり、対応する会計応答メッセージにも存在する場合があります。
The Acct-Time AVP (AVP Code 46) is of type Unsigned32 and indicates the length of the current session in seconds. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
ACCT-TIME AVP（AVPコード46）は型signed32であり、現在のセッションの長さを秒単位で示します。このAVPは、すべてのアカウンティングレクエストメッセージに含める必要があり、対応する会計応答メッセージにも存在する場合があります。
The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and contains the number of IP packets received from the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
Accounting-Input-Packets（AVP Code 365）はタイプunsigned64で、ユーザーから受信したIPパケットの数が含まれています。このAVPは、すべてのアカウンティングレクエストメッセージに含める必要があり、対応する会計応答メッセージにも存在する場合があります。
The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64 and contains the number of IP packets sent to the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
会計出力パケット（AVPコード366）はタイプunsigned64で、ユーザーに送信されるIPパケットの数が含まれています。このAVPは、すべてのアカウンティングレクエストメッセージに含める必要があり、対応する会計応答メッセージにも存在する場合があります。
The Event-Timestamp (AVP Code 55) is of type Time and MAY be included in an Accounting-Request message to record the time at which this event occurred on the mobility agent, in seconds since January 1, 1970, 00:00 UTC.
イベント - チメスタンプ（AVPコード55）はタイプの時間であり、1970年1月1日以来数秒でこのイベントがモビリティエージェントで発生した時間を記録するために、会計レクエストメッセージに含まれる場合があります。
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 table uses the following symbols:
テーブルは次のシンボルを使用しています。
0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in the message. 0 - 1 Zero or one instance of the AVP MAY be present in the message. 1 One instance of the AVP MUST be present in the message.
0 AVPがメッセージに存在してはなりません。AVPの0ゼロ以上のインスタンスがメッセージに存在する場合があります。AVPの0-1ゼロまたは1つのインスタンスがメッセージに存在する場合があります。1 AVPの1つのインスタンスがメッセージに存在する必要があります。
The table in this section is limited to the Command Codes defined in this specification.
このセクションの表は、この仕様で定義されているコマンドコードに限定されています。
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 |
Auth-Application-Id | 1 | 1 | 1 | 1 |
Auth-Session-State | 0-1 | 0-1 | 1 | 0 |
Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 |
Destination-Host | 0-1 | 0 | 0-1 | 0 |
Destination-Realm | 1 | 0 | 1 | 0 |
Error-Message | 0 | 0-1 | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 |
MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 |
MIP-FA-Challenge | 0-1 | 0 | 0 | 0 |
MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 |
MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 |
MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 |
MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 | MIP-MN-to-HA-MSA | 0 | 0-1 | 0-1 | 0 | MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-FA-MSA |0 |0 |0-1 |0 |MIP-MN-to-ha-msa |0 |0-1 |0-1 |0 |mip-fa-to-ha-spi |0 |0 |0 |0-1 |mip-ha-to-fa-spi |0 |0 |0 |0-1 |
MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 |
mip-fa-to-mn-spi |0 |0 |0 |0-1 |mip-mn-to-fa-spi |0 |0 |0 |0-1 |
MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 |
MIP-Filter-Rule | 0 | 0+ | 0+ | 0 |
MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-MSA-Lifetime | 0 | 0-1 | 0-1 | 0 |
MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 |
MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 |
MIP-Reg-Request | 1 | 0 | 1 | 0 |
Origin-Host | 1 | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ | 0+ | 0+ |
Redirect-Host | 0 | 0+ | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 |
Result-Code | 0 | 1 | 0 | 1 |
Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 |
Route-Record | 0+ | 0 | 0+ | 0 |
Session-Id | 1 | 1 | 1 | 1 |
User-Name | 1 | 0-1 | 1 | 0-1 |
------------------------------|-----+-----+-----+-----|
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 [DIAMBASE].
このセクションの表は、[Diambase]で定義されているように、このドキュメントで定義されているAVPが会計メッセージに存在することを表すために使用されます。
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 1 | 0-1 |
Accounting-Input-Packets | 1 | 0-1 |
Accounting-Output-Octets | 1 | 0-1 |
Accounting-Output-Packets | 1 | 0-1 |
Acct-Multi-Session-Id | 1 | 0-1 |
Acct-Session-Time | 1 | 0-1 |
MIP-Feature-Vector | 1 | 0-1 |
MIP-Home-Agent-Address | 1 | 0-1 |
MIP-Mobile-Node-Address | 1 | 0-1 |
Event-Timestamp | 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が管理する既存の名前空間に値を割り当てた名前空間が含まれています。
This specification assigns the values 260 and 262 from the Command Code namespace defined in [DIAMBASE]. See section 5 for the assignment of the namespace in this specification.
この仕様は、[Diambase]で定義されているコマンドコード名空間から値260と262を割り当てます。この仕様の名前空間の割り当てについては、セクション5を参照してください。
This specification assigns the values 318 - 348 and 363 - 367 from the AVP Code namespace defined in [DIAMBASE]. See sections 7, 9, and 10 for the assignment of the namespace in this specification.
この仕様は、[Diambase]で定義されているAVPコード名空間から値318-348および363-367を割り当てます。この仕様の名前空間の割り当てについては、セクション7、9、および10を参照してください。
This specification assigns the values 4005 - 4008 and 5024 - 5025 from the Result-Code AVP (AVP Code 268) value namespace defined in [DIAMBASE]. See section 6 for the assignment of the namespace in this specification.
この仕様は、[Diambase]で定義されている結果コードAVP（AVPコード268）値名空間から値4005-4008および5024-5025を割り当てます。この仕様の名前空間の割り当てについては、セクション6を参照してください。
There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that are available for assignment. This document assigns bits 1 - 9, as listed in section 7.5. The remaining bits should only be assigned via Standards Action [IANA].
MIP-Feature-Vector AVP（AVPコード337）には、割り当てに使用できる32ビットがあります。このドキュメントには、セクション7.5にリストされているように、ビット1-9が割り当てられます。残りのビットは、標準アクション[IANA]によってのみ割り当てられる必要があります。
As defined in section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345) defines the value 2. All remaining values, except zero, are available for assignment via Designated Expert [IANA].
セクション9.8で定義されているように、MIP-ALGORITHM-TYPE AVP（AVPコード345）は値2を定義します。ゼロを除くすべての残りの値は、指定された専門家[IANA]を介して割り当てに使用できます。
As defined in section 9.9, the MIP-Replay-Mode AVP (AVP Code 346) defines the values 1 - 3. All remaining values, except zero, are available for assignment via Designated Expert [IANA].
セクション9.9で定義されているように、MIP-Replay-Mode AVP（AVPコード346）は、値1-3を定義します。ゼロを除くすべての残りの値は、指定されたエキスパート[IANA]を介して割り当て可能です。
This specification uses the value two (2) to the Application Identifier namespace defined in [DIAMBASE]. See section 4 for more information.
この仕様では、[Diambase]で定義されているアプリケーション識別子名空間に値2（2）を使用します。詳細については、セクション4を参照してください。
This specification describes a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm used is dependent on the transforms used within the Mobile IPv4 protocol, and [MIPCHAL]. This specification, in conjunction with [MIPKEYS], also defines a method by which the home Diameter server can create and distribute session keys and nonces for use in authenticating and integrity-protecting Mobile IPv4 registration messages [MOBILEIP]. The key distribution is asymmetric, as communication with the mobile node occurs via the Mobile IPv4 protocol [MIPKEYS, MOBILEIP], where as communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. Where untrusted Diameter agents are present, end-to-end security MUST be used. The end-to-end security takes the form of TLS or IPSec security associations between the AAAH and the FA and between the AAAH and the HA. These connections will be authenticated with the use of public keys and certificates; however, the identities that appear in the certificates must be authorized and bound to a particular Mobile IPv4 Diameter session before the AAAH can safely begin distribution of keys.
この仕様では、モバイルIPv4モバイルノードを認証および承認するためのモバイルIPv4直径アプリケーションについて説明します。使用される認証アルゴリズムは、モバイルIPv4プロトコル内で使用される変換と[Mipchal]に依存します。この仕様は、[Mipkeys]と併せて、Home Diameter ServerがモバイルIPv4登録メッセージ[MobileIP]を認証および整合性に保護するためのセッションキーとノンセを作成および配布できる方法を定義します。モバイルノードとの通信はモバイルIPv4プロトコル[Mipkeys、MobileIP]を介して発生するため、主要な分布は非対称です。ホームエージェントおよび外国エージェントとの通信が直径プロトコルを介して発生するためです。信頼されていない直径エージェントが存在する場合、エンドツーエンドのセキュリティを使用する必要があります。エンドツーエンドのセキュリティは、AAAHとFAの間、およびAAAHとHAの間のTLSまたはIPSECセキュリティ協会の形をとります。これらの接続は、パブリックキーと証明書の使用で認証されます。ただし、証明書に表示されるIDは、AAAHがキーの配布を安全に開始できる前に、特定のモバイルIPv4直径セッションに承認され、拘束される必要があります。
Note that the direct connections are established as a result of Diameter redirect messages. For example, in Figure 3, the FA gets a redirect response containing the Redirect-Host AVP of the AAAH. This is the identity that should be matched against the certificate presented by the AAAH when the secure connection is established. In this case, the network of Diameter proxies and redirect agents is trusted with the task of returning the correct AAAH identity to the FA.
直接接続は、直径リダイレクトメッセージの結果として確立されることに注意してください。たとえば、図3では、FAはAAAHのリダイレクトホストAVPを含むリダイレクト応答を取得します。これは、安全な接続が確立されたときにAAAHによって提示された証明書と一致する必要があるアイデンティティです。この場合、直径プロキシとリダイレクトエージェントのネットワークは、正しいAAAHアイデンティティをFAに返すタスクに信頼されています。
The AAAH must also make an authorization decision when the FA establishes the connection. If the AAAH and the redirect server are one and the same, then the AAAH may have observed and noted the original AMR message that contained the identity of the FA and so may authorize the establishment of a TLS or IPSec connection from the same entity. Otherwise, the AAAH would need to maintain a list of all authorized visited domains (roaming partners) and authorize TLS or IPSec connections based on this list. Note that establishment of the connection is only the first step, and the AAAH has another opportunity to deny service upon receipt of the AMR message itself. At this step, the AAAH can check the internal AVPs of the AMR to ensure that the FA is valid; for example, it can check that the Mobile IP COA is equal to the IP address used as the endpoint of the TLS or IPSec connection. However, such a policy would prevent the FA from using different interfaces for AAA and Mobile IP tunnel packets and may not be desirable in every deployment situation.
AAAHは、FAが接続を確立するときにも許可決定を下さなければなりません。AAAHとリダイレクトサーバーが同じである場合、AAAHはFAのIDを含む元のAMRメッセージを観察し、同じエンティティからのTLSまたはIPSEC接続の確立を承認する可能性がある場合があります。それ以外の場合、AAAHは、すべての承認された訪問ドメイン（ローミングパートナー）のリストを維持し、このリストに基づいてTLSまたはIPSEC接続を承認する必要があります。接続の確立は最初のステップにすぎないことに注意してください。AAAHには、AMRメッセージ自体を受け取ったときにサービスを拒否する別の機会があります。このステップで、AAAHはAMRの内部AVPをチェックして、FAが有効であることを確認できます。たとえば、モバイルIP COAがTLSまたはIPSEC接続のエンドポイントとして使用されるIPアドレスに等しいことを確認できます。ただし、このようなポリシーは、FAがAAAおよびモバイルIPトンネルパケットに異なるインターフェイスを使用することを妨げ、すべての展開状況では望ましくない場合があります。
A similar set of considerations applies to the connection between AAAH and HA when those entities are in different administrative domains. However, here the roles are reversed because it is the AAAH that contacts the HA via the HAR. The identity of the candidate HA is given to the AAAH in the AMR, and the AAAH should expect to receive the same identity in the public key certificates during TLS or IPSec negotiation. The HA may authorize individual connections by acting as its own redirect server, or it may maintain a list of trusted roaming partners.
同様の考慮事項は、これらのエンティティが異なる管理ドメインにある場合、AAAHとHAの間の接続に適用されます。ただし、ここでは、HAを介してHAに接触するのはAAAHであるため、役割が逆転しています。候補者の身元はAMRのAAAHに与えられ、AAAHはTLSまたはIPSEC交渉中に公開キー証明書で同じ身元を受け取ることを期待すべきです。HAは、独自のリダイレクトサーバーとして行動することにより、個々の接続を承認するか、信頼できるローミングパートナーのリストを維持する場合があります。
This application creates and distributes a single session key for each pair of MSAs between two entities; e.g., the same session key is used for the MN-HA MSA and the HA-MN MSA. This is safe to do from a security perspective, as the session keys are only used with keyed hash functions to generate authenticator values that protect the integrity of each Mobile IP control message. Mobile IP messages have built-in replay protection with the use of timestamps or nonces [MOBILEIP], and, due to the nature of the protocol, requests are always different bitwise from responses, at least in the message type code. This avoids problems that might arise in other situations where an attacker could mount a replay or reflection attack if the same key were used (for example) to encrypt otherwise unprotected traffic on more than one connection leg in the network.
このアプリケーションは、2つのエンティティ間でMSAのペアごとに単一のセッションキーを作成および配布します。たとえば、同じセッションキーがMN-HA MSAおよびHA-MN MSAに使用されます。セッションキーはキー付きハッシュ関数でのみ使用されるため、各モバイルIPコントロールメッセージの整合性を保護する認証因子値を生成するため、これはセキュリティの観点から安全です。モバイルIPメッセージには、タイムスタンプまたはノンセス[MobileIP]を使用してリプレイ保護が組み込まれており、プロトコルの性質上、少なくともメッセージタイプコードでは、リクエストは常に応答とビットごとに異なります。これにより、ネットワーク内の複数の接続脚で保護されていないトラフィックを暗号化するために同じキー（たとえば）が使用された場合、攻撃者がリプレイまたは反射攻撃を取り付けることができる他の状況で発生する可能性のある問題を回避します。
Nonces are sent to the mobile node, which are used to generate the session keys via the HMAC-SHA-1 one-way function. Because the nonces and authentication extensions may be observed by anyone with access to a clear-text copy of the Registration Reply, the pre-shared key between the mobile node and the home Diameter server would be vulnerable to an offline dictionary attack if it did not contain enough entropy. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits.
Noncesはモバイルノードに送信されます。モバイルノードは、HMAC-Sha-1一元配置関数を介してセッションキーを生成するために使用されます。登録返信のクリアテキストコピーにアクセスできる人は、Noncesと認証拡張機能が観察される可能性があるため、モバイルノードとホーム直径サーバーの間の事前共有キーは、オフラインの辞書攻撃に対して脆弱です。十分なエントロピーが含まれています。これを防ぐために、モバイルノードとホーム直径サーバーの間の事前に共有キーは、少なくとも96ビットのランダムに選択された量である必要があります。
Because the session key is determined by the long-term secret and the nonce, the nonce SHOULD be temporally and globally unique; if the nonce were to repeat, then so would the session key. To prevent this, a nonce is strongly recommended to be a random [RANDOM] value of at least 128 bits. The long-term secret between the MN and AAAH MUST be refreshed periodically, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is accomplished by using out-of-band mechanisms, which are not specified in this document.
セッションキーは長期的な秘密とノンセによって決定されるため、Nonceは時間的およびグローバルに一意でなければなりません。ノンセが繰り返される場合、セッションキーも繰り返されます。これを防ぐために、少なくとも128ビットのランダム[ランダム]値であることを強くお勧めします。MNとAAAHの間の長期的な秘密は、非CEの再利用またはその他の要因による長期的な秘密の回復を防ぐために、定期的にリフレッシュする必要があります。これは、このドキュメントでは指定されていないバンド外のメカニズムを使用することによって実現されます。
Note that it is not recommended to set the MIP-MSA-Lifetime AVP value to zero, as keeping session keys for a long time (no refresh) increases the level of vulnerability.
セッションキーを長期間維持する（更新なし）脆弱性のレベルを高めるため、MIP-MSA-Lifetime AVP値をゼロに設定することは推奨されないことに注意してください。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[Diambase] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[MOBILEIP] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[MobileIP] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[MIPCHAL] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
[Mipchal] Perkins、C。およびP. Calhoun、「モバイルIPv4チャレンジ/応答拡張機能」、RFC 3012、2000年11月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[Nai] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[MIPKEYS] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IP", RFC 3957, March 2005.
[Mipkeys] Perkins、C。and P. Calhoun、「認証、承認、および会計（AAA）モバイルIPの登録キー」、RFC 3957、2005年3月。
[AAANAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004.
[aaanai]ヨハンソン、F。およびT.ヨハンソン、「ネットワークアクセス識別子を携帯するためのモバイルIPv4拡張機能」、RFC 3846、2004年6月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[TLS] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[TLS] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 3546、2003年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MIPREQ] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[Mipreq] Glass、S.、Hiller、T.、Jacobs、S。、およびC. Perkins、「モバイルIP認証、承認、および会計要件」、RFC 2977、2000年10月。
[CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, G., Sivalingham, S., Lim, B., McCann, P., Shiino, H., Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu, Y., Baba, S., Ayaki, T., Seki, T., and A. Hameed, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001.
[CDMA2000] Hiller、T.、Walsh、P.、Chen、X.、Munson、M.、Dommety、G.、Sivalingham、S.、Lim、B.、McCann、P.、Shiino、H.、Hirschman、B.、Manning、S.、Hsu、R.、Koo、H.、Lipford、M.、Calhoun、P.、Lo、C.、Jaques、E.、Campbell、E.、Xu、Y.、Baba、S.、Ayaki、T.、Seki、T。、およびA. Hameed、「AAAのCDMA2000ワイヤレスデータ要件」、RFC 3141、2001年6月。
[EVALROAM] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[Evalroam] Aboba、B。およびG. Zorn、「ローミングプロトコルを評価するための基準」、RFC 2477、1999年1月。
[MIPNAI] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[Mipnai] Calhoun、P。およびC. Perkins、「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年3月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
The authors would like to thank Nenad Trifunovic, Haseeb Akhtar, and Pankaj Patel for their participation in the pre-IETF Document Reading Party; Erik Guttman for his very useful proposed text; and to Fredrik Johansson, Martin Julien, and Bob Kopacz for their very useful contributed text.
著者は、Nenad Trifunovic、Haseeb Akhtar、およびPankaj Patelに感謝したいと思います。彼の非常に有用な提案されたテキストのためにエリック・ガットマン。そして、非常に有用な貢献したテキストのために、フレドリックヨハンソン、マーティンジュリアン、ボブコパッチに。
The authors would also like to thank the participants of 3GPP2's TSG-X working group for their valuable feedback, and the following people for their contribution in the development of the protocol: Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael Chen, Henry Haverinen, and Johan Johansson. General redirect server text due to Pasi Eronen was borrowed from Diameter-EAP.
著者はまた、3GPP2のTSG-Xワーキンググループの参加者に貴重なフィードバックについて感謝し、プロトコルの開発に貢献したことについて次の人々に感謝します。ヘンリー・ハベリネン、ヨハン・ヨハンソン。Pasi Eronenによる一般的なリダイレクトサーバーのテキストは、直径-EAPから借用されました。
Pat Calhoun would like to thank Sun Microsystems, as most of the effort put into this document was done while he was in their employ.
パット・カルホーンは、この文書に入れられた努力の大部分が彼が彼らの雇用中に行われたので、Sun Microsystemsに感謝したいと思います。
Authors' Addresses
著者のアドレス
Questions about this memo can be directed to:
このメモに関する質問は、次のように向けることができます。
Pat Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
PAT Calhoun Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USA
Phone: +1 408-853-5269
EMail: pcalhoun@cisco.com
Tony Johansson Bytemobile, Inc. 2029 Stierlin Court Mountain View, CA 94043
Tony Johansson Bytemobile、Inc。2029 Stierlin Court Mountain View、CA 94043
Phone: +1 650-641-7817 Fax: +1 650-641-7701 EMail: tony.johansson@bytemobile.com Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
電話：1 650-641-7817ファックス：1 650-641-7701メール：tony.johansson@bytemobile.com
Phone: +1 650-625-2986
Fax: +1 650-625-2502
EMail: Charles.Perkins@nokia.com
Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville, IL 60566 USA
Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville、IL 60566 USA
Phone: +1 630-979-7673
EMail: tomhiller@lucent.com
Peter J. McCann Lucent Technologies 1960 Lucent Lane Naperville, IL 60563 USA
ピーター・J・マッキャン・ルーセント・テクノロジーズ1960ルーセント・レーン・ネーパービル、イリノイ州60563 USA
Phone: +1 630-713-9359
Fax: +1 630-713-1921
EMail: mccap@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。