Network Working Group J. Korhonen, Ed.
Request for Comments: 5447 Nokia Siemens Networks
Category: Standards Track J. Bournelle
Orange Labs
H. Tschofenig
Nokia Siemens Networks
C. Perkins
WiChorus
K. Chowdhury
Starent Networks
February 2009
Diameter Mobile IPv6:
Support for Network Access Server to Diameter Server Interaction
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home AAA server interface.
それはモバイルIPv6を利用し始めることができる前に、モバイルIPv6ノードがホームエージェントアドレス、自宅住所、およびそのホームエージェントとのセキュリティアソシエーションが必要です。 RFC 3775は、これらのパラメータの一部またはすべてが静的に構成されている必要があります。モバイルIPv6ブートストラップの仕事は、モバイルノードにこの情報を動的に利用できるようにすることを目指しています。モバイルIPv6ブートストラップ溶液の重要な態様は、既存の認証、許可、アカウンティング（AAA）インフラストラクチャとのインターワーキングをサポートすることです。この文書では、ホームAAAサーバインターフェイスに直径ネットワークアクセスサーバーを使用してMIPv6のブートストラップについて説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Commands, Attribute-Value Pairs, and Advertising
Application Support . . . . . . . . . . . . . . . . . . . . . 6
4.1. Advertising Application Support . . . . . . . . . . . . . 6
4.2. Attribute-Value Pair Definitions . . . . . . . . . . . . . 6
4.2.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . 6
4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 7
4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 7
4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 8
4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 10
5.2. Home Agent Assignment by the Diameter Server . . . . . . . 11
5.3. Home Agent Assignment by the NAS or Diameter Server . . . 11
6. Attribute-Value Pair Occurrence Tables . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Registration of New AVPs . . . . . . . . . . . . . . . . . 13
7.2. New Registry: Mobility Capability . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
The Mobile IPv6 (MIPv6) specification [RFC3775] requires a mobile node (MN) to perform registration with a home agent (HA) with information about its current point of attachment (care-of address). The HA creates and maintains the binding between the MN's home address and the MN's care-of address.
モバイルIPv6（MIPv6の）仕様[RFC3775]はアタッチメント（気付アドレス）の現在の位置に関する情報を、ホームエージェント（HA）への登録を実行するために、モバイルノード（MN）が必要。 HAは、作成され、MNのホームアドレスとMNの気付アドレスとの間の結合を維持します。
In order to register with an HA, the MN needs to know some information, such as the home link prefix, the HA address, the home address(es), the home link prefix length, and security-association-related information.
HAに登録するためには、MNは、ホームリンクプレフィックス、HAアドレス、ホームアドレス（複数可）、ホームリンクのプレフィックス長、およびセキュリティアソシエーション関連情報として、いくつかの情報を知っている必要があります。
The aforementioned information may be statically configured. However, static provisioning becomes an administrative burden for an operator. Moreover, it does not address load balancing, failover, opportunistic home link assignment, or assignment of local HAs in close proximity to the MN. Also, the ability to react to sudden environmental or topological changes is minimal. Static provisioning may not be desirable, in light of these limitations.
前述の情報は、静的に構成されてもよいです。しかし、静的プロビジョニングは、オペレータのための管理上の負担となります。また、それは負荷分散、フェイルオーバー、日和見ホームリンクの割り当て、またはローカルの割り当てに対応していませんMNに近接しています。また、突然の環境またはトポロジの変更に反応する能力は最小限です。静的プロビジョニングは、これらの制限に照らして、望ましくないかもしれません。
Dynamic assignment of MIPv6 home registration information is a desirable feature for ease of deployment and network maintenance. For this purpose, the AAA infrastructure, which is used for access authentication, can be leveraged to assign some or all of the necessary parameters. The Diameter server in the Access Service Provider's (ASP's) or Mobility Service Provider's (MSP's) network may return these parameters to the AAA client. Regarding the bootstrapping procedures, the AAA client might either be the Network Access Server, in case of the integrated scenario, or the HA, in case of the split scenario [RFC5026]. The terms "integrated" and "split" are described in the following terminology section and were introduced in [RFC4640] and [AAA].
MIPv6のホーム登録情報の動的な割り当ては、展開およびネットワークメンテナンスの容易さのために望ましい特徴です。この目的のために、アクセス認証のために使用されるAAAインフラストラクチャは、必要なパラメータの一部またはすべてを割り当てるために活用することができます。アクセスサービスプロバイダ（ASPの）またはモビリティサービスプロバイダ（MSPの）ネットワーク内Diameterサーバは、AAAクライアントにこれらのパラメータを返すことがあります。ブートストラップの手順については、AAAクライアントは[RFC5026]スプリットのシナリオの場合には、統合シナリオの場合のネットワークアクセスサーバー、またはHAかもしれませんどちらか。用語「一体化」と「分割」は、以下の用語セクションに記載されており、[RFC4640]と[AAA]に導入しました。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
General mobility terminology can be found in [RFC3753]. The following additional terms are either borrowed from [RFC4640] or [RFC5026] or are introduced in this document:
一般的なモビリティの用語は、[RFC3753]で見つけることができます。以下の追加条件は、いずれかの[RFC4640]か[RFC5026]から借りているか、このドキュメントで紹介されています。
Access Service Authorizer (ASA):
アクセスサービスオーソライザ（ASA）：
A network operator that authenticates an MN and establishes the MN's authorization to receive Internet service.
MNを認証し、MNの認可を確立し、ネットワークオペレータは、インターネットサービスを受信します。
Access Service Provider (ASP):
アクセス・サービス・プロバイダ（ASP）：
A network operator that provides direct IP packet-forwarding to and from the MN.
し、MNから直接IPパケット転送を提供するネットワークオペレータ。
Mobility Service Authorizer (MSA):
モビリティサービスオーソライザ（MSA）：
A service provider that authorizes MIPv6 service.
MIPv6のサービスを承認サービスプロバイダ。
Mobility Service Provider (MSP):
モビリティ・サービス・プロバイダ（MSP）：
A service provider that provides MIPv6 service. In order to obtain such service, the MN must be authenticated and authorized to do so.
MIPv6のサービスを提供するサービスプロバイダ。そのようなサービスを得るためには、MNは、認証され、そうすることを許可しなければなりません。
Split Scenario:
スプリットシナリオ：
A scenario where the mobility service and the network access service are authorized by different entities.
モビリティサービスとネットワークアクセスサービスが異なるエンティティによって許可されているシナリオ。
Integrated Scenario:
統合シナリオ：
A scenario where the mobility service and the network access service are authorized by the same entity.
モビリティサービスとネットワークアクセスサービスが同じエンティティによって許可されているシナリオ。
Network Access Server (NAS):
ネットワークアクセスサーバー（NAS）：
A device that provides an access service for a user to a network.
ネットワークへのユーザのアクセスサービスを提供する装置。
Home AAA (HAAA):
この家（ありました）：
An Authentication, Authorization, and Accounting server located in the user's home network, i.e., in the home realm.
ホーム領域での認証、許可、およびユーザのホームネットワーク内に位置する会計サーバ、すなわち、。
Local AAA (LAAA):
ローカルAAA（もたらしました）：
An Authentication, Authorization, and Accounting proxy located in the local (ASP) network.
ローカル（ASP）ネットワーク内に位置する認証、許可、アカウンティングプロキシ。
Visited AAA (VAAA):
AAA（VAAA）訪問：
An Authentication, Authorization, and Accounting proxy located in a visited network, i.e., in the visited realm. In a roaming case, the local Diameter proxy has the VAAA role (see Figure 1).
訪問分野で訪問先ネットワーク、即ち、に位置する認証、許可、アカウンティングプロキシ。ローミングの場合には、ローカルのDiameterプロキシは（図1参照）VAAA役割を持ちます。
This document addresses the Authentication, Authorization, and Accounting (AAA) functionality required for the MIPv6 bootstrapping solutions outlined in [RFC4640], and focuses on the Diameter-based AAA functionality for the NAS-to-HAAA (home AAA) server communication.
このドキュメントは[RFC4640]に概説MIPv6のブートストラップ・ソリューションに必要な認証、許可、アカウンティング（AAA）機能に対処し、そしてNASツーHAAA（ホームAAA）サーバ通信用のDiameterベースのAAA機能に焦点を当てています。
In the integrated scenario, MIPv6 bootstrapping is provided as part of the network access authentication procedure. Figure 1 shows the participating entities.
統合シナリオでは、MIPv6のブートストラップは、ネットワークアクセス認証手順の一部として提供されます。図1は、参加エンティティを示しています。
+---------------------------+ +-----------------+
|Access Service Provider | |ASA/MSA/(MSP) |
|(Mobility Service Provider)| | |
| | | |
| +--------+ | | +--------+ |
| |Local | Diameter | | |Home | |
| |Diameter|<---------------------->|Diameter| |
| |Proxy | (*) | | |Server | |
| +--------+ | | +--------+ |
| ^ ^ | | ^ |
| | | | | |(+) |
| | | | | | |
| Diameter | | v |
| | |(+) +-------+ | | +-------+ |
| | | |Home | | | |Home | |
| | +-------->|Agent | | | |Agent | |
| (*)| |in ASP | | | |in MSP | |
| v +-------+ | | +-------+ |
+-------+ IEEE | +-----------+ +-------+ | +-----------------+
|Mobile | 802.1X | |NAS/Relay | |DHCPv6 | |
|Node |------------|Diameter |---|Server | |
| | PANA, | |Client |(+)| | |
+-------+ IKEv2, | +-----------+ +-------+ |
DHCP,... +---------------------------+
(+)
Legend: (*): Functionality in scope of this specification. (+): Extensions described in other documents.
凡例：（*）：この仕様の範囲内の機能。 （+）：他の文献に記載の拡張機能。
Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario
図1：統合シナリオにおけるモバイルIPv6ブートストラップ
In a typical MIPv6 access scenario, an MN is attached to an ASP's network. During the network attachment procedure, the MN interacts with the NAS/Diameter client. Subsequently, the NAS/Diameter client interacts with the Diameter server over the NAS-to-HAAA interface.
典型的なMIPv6のアクセスシナリオでは、MNは、ASPのネットワークに接続されています。ネットワーク接続手順の間、MNは、NAS / Diameterクライアントと対話します。その後、NAS / Diameterクライアントは、NASツーHAAAインタフェースを介しDiameterサーバと対話します。
When the Diameter server performs the authentication and authorization for network access, it also determines whether the user is authorized for the MIPv6 service. Based on the MIPv6 service authorization and the user's policy profile, the Diameter server may return several MIPv6 bootstrapping-related parameters to the NAS. The NAS-to-HAAA interface described in this document is not tied to the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) as the only mechanism to convey MIPv6-related configuration parameters from the NAS/Diameter client to the mobile node.
Diameterサーバは、ネットワークアクセスの認証および許可を行う場合、それはまた、ユーザがMIPv6のサービスのために認可されたか否かを判定する。 MIPv6のサービス認証とユーザーのポリシープロファイルに基づいて、Diameterサーバは、NASにいくつかのMIPv6ブートストラップ関連のパラメータを返すことがあります。本書では説明NASツーHAAAインタフェースが移動ノードにNAS / DiameterクライアントからのMIPv6関連の構成パラメータを伝達する唯一のメカニズムとしてのIPv6（DHCPv6の）動的ホスト構成プロトコルに関連付けられていません。
While this specification addresses the bootstrapping of MIPv6 HA information and possibly the assignment of the home link prefix, it does not address how the Security Association (SA) between the MN and the HA for MIPv6 purposes is created. The creation or the use of the SA between the MN and the HA takes places after the procedures described in this specification, and therefore are out of scope.
この仕様は、MIPv6のHA情報のブートストラップと、おそらくホームリンクプレフィックスの割り当てを扱うが、それはMIPv6の目的のためのMNとHA間のセキュリティアソシエーション（SA）が作成される方法を扱っていません。作成またはMNとHAの間のSAの使用は、本明細書に記載された手順の後に場所を取り、したがって範囲外です。
This document does not define a new application. On the other hand, it defines a number of attribute-value pairs (AVPs) used in the interface between NAS to HAAA for the integrated scenario of MIPv6 bootstrapping. These AVPs can be used with any present and future Diameter applications, where permitted by the command ABNF. The examples using existing applications and their commands in the following sections are for informational purposes only. The examples in this document reuse the Extensible Authentication Protocol (EAP) [RFC4072] application and its respective commands.
この文書は、新しいアプリケーションを定義していません。一方、MIPv6のブートストラップの統合シナリオのHAAAにNASとの間のインターフェースに使用される属性値ペア（AVPの）の数を定義します。これらのAVPは、コマンドABNFによって許可任意の現在および将来のDiameterアプリケーションで使用することができます。次のセクションでは、既存のアプリケーションとそれらのコマンドを使用しての例は、情報提供のみを目的としています。この文書の例では、拡張認証プロトコル（EAP）[RFC4072]アプリケーションとそのそれぞれのコマンドを再利用します。
The MIP6-Agent-Info AVP (AVP code 486) is of type Grouped and contains necessary information to assign an HA to the MN. When the MIP6-Agent-Info AVP is present in a message, it MUST contain either the MIP-Home-Agent-Address AVP, the MIP-Home-Agent-Host AVP, or both AVPs. The grouped AVP has the following modified ABNF (as defined in [RFC3588]):
MIP6-エージェント情報AVP（AVPコード486）がグループ化されたタイプのものであり、MNにHAを割り当てるために必要な情報を含みます。 MIP6-エージェント情報AVPがメッセージに存在している場合、それはMIP-ホーム・エージェント・アドレスAVP、MIP-ホーム・エージェントホストAVP、またはその両方のAVPのいずれかを含まなければなりません。グループ化AVPは、以下の改変をABNF（[RFC3588]で定義される）を有します。
MIP6-Agent-Info ::= < AVP-Header: 486 >
*2[ MIP-Home-Agent-Address ]
[ MIP-Home-Agent-Host ]
[ MIP6-Home-Link-Prefix ]
* [ AVP ]
If both the MIP-Home-Agent-Address and MIP-Home-Agent-Host APVs are present in the MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD have a precedence over the MIP-Home-Agent-Host. The reason for this recommendation is that the MIP-Home-Agent-Address points to a specific home agent, whereas the MIP-Home-Agent-Host may point to a group of HAs located within the same realm. A Diameter client or agent may use the MIP-Home-Agent-Host AVP, for instance, to find out in which realm the HA is located.
MIP-ホーム・エージェント・アドレスおよびMIP-ホーム・エージェントホストの両方APVsがMIP6-エージェント情報に存在している場合は、MIP-ホーム・エージェント・アドレスは、MIP-ホーム・エージェントホストに優先を持つべきである（SHOULD） 。 MIP-ホーム・エージェントホストが同じレルム内に位置しているのグループを指す場合がある。この勧告の理由は、特定のホームエージェントにMIP-ホーム・エージェント・アドレスのポイントということです。 Diameterクライアントまたはエージェントは、HAが配置されている領域で見つけるために、例えば、MIP-ホーム・エージェントホストAVPを使用することができます。
The ABNF allows returning up to two MIPv6 HA addresses. This is a useful feature for deployments where the HA has both IPv6 and IPv4 addresses, and particularly addresses Dual Stack Mobile IPv6 (DSMIPv6) deployment scenarios [DSMIPv6].
ABNFは2つのMIPv6のHAアドレスまで戻っことができます。これは、HAはIPv6とIPv4アドレスの両方を有し、特に[DSMIPv6】デュアルスタックモバイルIPv6（DSMIPv6）展開シナリオに対処する展開するために有用な特徴です。
The MIP6-Agent-Info AVP MAY also be attached by the NAS or by the intermediating Diameter proxies in a request message when sent to the Diameter server as a hint of a locally assigned HA. This AVP MAY also be attached by the intermediating Diameter proxies in a reply message from the Diameter server, if locally assigned HAs are authorized by the Diameter server. There MAY be multiple instances of the MIP6-Agent-Info AVP in Diameter messages, for example, in cases where the NAS receives HA information from an MN's home network and locally allocated HA information from the visited network. See Section 4.2.5 for further discussion on possible scenarios.
ローカルに割り当てられたHAのヒントとして、ダイアメータサーバに送信するときMIP6-エージェント情報AVPはまた、NASによって、または要求メッセージ内の仲介のDiameterプロキシによって取り付けられてもよいです。ローカルに割り当てられたが、Diameterサーバによって許可された場合には、このAVPは、Diameterサーバからの応答メッセージに仲介するDiameterプロキシによって取り付けられてもよいです。 NASは、MNのホームネットワークからHA情報を受信して、ローカルに訪問したネットワークからのHA情報を割り当てられた場合には、例えば、DiameterメッセージにMIP6-エージェントインフォメーションAVPの複数のインスタンスがあるかもしれません。可能なシナリオのさらなる議論については、セクション4.2.5を参照してください。
The MIP-Home-Agent-Address AVP (AVP Code 334 [RFC4004]) is of type Address and contains the IPv6 or IPv4 address of the MIPv6 HA. The Diameter server MAY decide to assign an HA to the MN that is in close proximity to the point of attachment (e.g., determined by the NAS-Identifier AVP). There may be other reasons for dynamically assigning HAs to the MN, for example, to share the traffic load.
MIP-ホーム・エージェント・アドレスAVP（AVPコード334 [RFC4004]）はタイプのアドレスであり、MIPv6のHAのIPv4またはIPv6アドレスが含まれています。ダイアメータサーバは、（例えば、NAS-識別子AVPによって決定される）の結合点に近接しているMNにHAを割り当てることを決定することができます。動的に割り当てるための他の理由があるかもしれMNに、例えば、トラフィック負荷を共有することがあります。
The MIP-Home-Agent-Host AVP (AVP Code 348 [RFC4004]) is of type Grouped and contains the identity of the assigned MIPv6 HA. Both the Destination-Realm and the Destination-Host AVPs of the HA are included in the grouped AVP. The usage of the MIP-Home-Agent-Host AVP is equivalent to the MIP-Home-Agent-Address AVP but offers an additional level of indirection by using the DNS infrastructure. The Destination-Host AVP is used to identify an HA, and the Destination-Realm AVP is used to identify the realm where the HA is located.
MIP-ホーム・エージェントホストAVP（AVPコード348 [RFC4004]）はタイプグループ化であり、割り当てられたMIPv6のHAのアイデンティティが含まれています。宛先領域およびHAの宛先ホストのAVPの両方がグループ化されたAVPに含まれています。 MIP-ホーム・エージェントホストAVPの使用は、MIP-ホーム・エージェント・アドレスAVPと同等ですが、DNSインフラストラクチャを使用することにより、間接の追加レベルを提供しています。宛先ホストAVPは、HAを同定するために使用され、宛先レルムAVPは、HAが配置されている領域を識別するために使用されます。
Depending on the actual deployment and DNS configuration, the Destination-Host AVP MAY represent one or more home agents. It is RECOMMENDED that the Destination-Host AVP identifies exactly one HA.
実際の展開とDNSの設定に応じて、宛先ホストAVPは、1つ以上のホーム・エージェントを表すことができます。宛先ホストAVPは正確に一つのHAを識別することが推奨されます。
It is RECOMMENDED that the MIP-Home-Agent-Host AVP is always included in the MIP6-Agent-Info AVP. In this way, the HA can be associated with the corresponding realm of the Diameter entity that added the MIP6-Agent-Info AVP using the Destination-Realm AVP, which is included in the MIP-Home-Agent-Host AVP.
MIP-ホーム・エージェントホストAVPは常にMIP6エージェント・インフォメーションAVPに含まれていることが推奨されます。このように、HAは、MIP-ホーム・エージェントホストAVPに含まれている宛先レルムAVPを使用して、MIP6-エージェント情報AVPを追加した直径エンティティの対応する領域に関連付けることができます。
The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString and contains the Mobile IPv6 home network prefix information in a network byte order. The home network prefix MUST be encoded as the 8-bit prefix length information (one octet) followed by the 128-bit field (16 octets) for the available home network prefix. The trailing bits of the IPv6 prefix after the prefix length bits MUST be set to zero (e.g., if the prefix length is 60, then the remaining 68 bits MUST be set to zero).
MIP6-ホームリンクプレフィックスAVP（AVPコード125）はタイプOctetStringにあり、ネットワークバイトオーダーでモバイルIPv6ホームネットワークプレフィックス情報が含まれています。ホーム・ネットワーク・プレフィクスは、利用可能なホーム・ネットワーク・プレフィクスのための128ビットフィールド（16オクテット）に続く8ビットのプレフィックス長情報（1つのオクテット）として符号化されなければなりません。プレフィックス長のビットはゼロに設定しなければなりませんした後にIPv6プレフィックスの末尾のビット（プレフィックス長が60である場合、例えば、残りの68ビットはゼロに設定しなければなりません）。
The HAAA MAY act as a central entity managing prefixes for MNs. In this case, the HAAA returns to the NAS the prefix allocated to the MN. The NAS/ASP then delivers the home link prefix to the MN using, e.g., mechanisms described in [INTEGRATED]. The NAS/ASP MAY propose to the HAAA a specific prefix to allocate to the MN by including the MIP6-Home-Link-Prefix AVP in the request message. However, the HAAA MAY override the prefix allocation hint proposed by the NAS/ASP and return a different prefix in the response message.
HAAAは、MNのための接頭辞を管理する中央エンティティとして動作することができます。この場合は、HAAAは、NASにMNに割り当てられた接頭辞を返します。 NAS / ASPは、次いで、例えば、[INTEGRATED]で説明されたメカニズムを使用してMNにホーム・リンク・プレフィックスを配信します。 NAS / ASPは、要求メッセージにMIP6-ホームリンクプレフィックスAVPを含むことにより、MNに割り当てるHAAAに特定の接頭辞を提案することができます。しかし、HAAAは、NAS / ASPによって提案されたプレフィクス割り当てヒントをオーバーライドし、応答メッセージに異なるプレフィックスを返すことができます。
The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and contains a 64-bit flags field of supported capabilities of the NAS/ ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 MUST be supported, although that does not provide much guidance about specific needs of bootstrapping.
MIP6-特徴ベクトルAVP（AVPコード124）はタイプUnsigned64にであり、NAS / ASPのサポート能力の64ビットのフラグフィールドを含みます。それは、ブートストラップの特定のニーズについて多くのガイダンスを提供していないが、送信と値0とMIP6-特徴ベクトルAVPを受けるには、サポートしなければなりません。
The NAS MAY include this AVP to indicate capabilities of the NAS/ASP to the Diameter server. For example, the NAS may indicate that a local HA can be provided. Similarly, the Diameter server MAY include this AVP to inform the NAS/ASP about which of the NAS/ASP indicated capabilities are supported or authorized by the ASA/MSA(/MSP).
NASは、DiameterサーバにNAS / ASPの能力を示すために、このAVPを含むかもしれません。例えば、NASは、ローカルHAを提供することができることを示してもよいです。同様に、ダイアメータサーバは、機能がサポートまたはASA / MSA（/ MSP）によって認可され示さNAS / ASPのどのNAS / ASPに通知するために、このAVPを含むかもしれません。
The following capabilities are defined in this document:
次の機能は、この文書で定義されています。
MIP6_INTEGRATED (0x0000000000000001)
MIP6_INTEGRATED（0x0000000000000001）
When this flag is set by the NAS, it means that the Mobile IPv6 integrated scenario bootstrapping functionality is supported by the NAS. When this flag is set by the Diameter server, then the Mobile IPv6 integrated scenario bootstrapping is supported by the Diameter server.
このフラグは、NASにより設定されている場合は、モバイルIPv6統合シナリオブートストラップ機能は、NASによってサポートされていることを意味します。このフラグは、Diameterサーバによって設定されている場合、次にモバイルIPv6統合シナリオブートストラップは、Diameterサーバによってサポートされています。
LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002)
LOCAL_HOME_AGENT_ASSIGNMENT（0x0000000000000002）
When this flag is set in the request message, a local home agent outside the home realm is requested and may be assigned to the MN. When this flag is set by the Diameter server in the answer message, then the assignment of local HAs is authorized by the Diameter server.
このフラグは、要求メッセージに設定されている場合は、ホーム領域外のローカルホームエージェントが要求され、MNに割り当てることができます。このフラグは、応答メッセージ内のDiameterサーバによって設定されている場合、ローカルの割り当ては、Diameterサーバによって承認されました。
A local HA may be assigned by the NAS, LAAA, or VAAA depending on the network architecture and the deployment.
ローカルHAは、ネットワークアーキテクチャおよび展開に応じてNAS、LAAA、又はVAAAによって割り当てられてもよいです。
The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT (referred to as LOCAL-bit in the examples) capability and the MIP-Agent-Info AVP (referred to as HA-Info in the examples) are used to assign HAs -- either a local HA (L-HA) or a home network HA (H-HA). Below are examples of request message combinations as seen by the HAAA:
いずれかのローカルHA（ - 以下の実施例は、LOCAL_HOME_AGENT_ASSIGNMENT（実施例内のローカルビットと呼ばれる）能力およびMIP-エージェント情報AVP（実施例にHA-情報と称する）を割り当てるために使用されているが持っているかを示しL-HA）またはホームネットワークHA（H-HA）。以下HAAAから見た要求メッセージの組み合わせの例です。
LOCAL-bit HA-Info Meaning
意味LOCALビットHA-情報
0 - ASP or [LV]AAA is not able to assign an L-HA. 0 L-HA Same as above. HA-Info must be ignored. 1 - ASP or [LV]AAA can/wishes to assign an L-HA. 1 L-HA Same as above but the ASP or [LV]AAA also provides a hint of the assigned L-HA.
0 - ASPまたは[LV] AAAは、L-HAを割り当てることができません。 0 L-HA上記と同じ。 HA-情報は無視されなければなりません。 1 - ASPまたは[LV] AAAは/ L-HAを割り当てることを望むことができます。 1同上L-HAが、Aspまたは[LV] AAAはまた、割り当てられたL-HAのヒントを提供します。
The same as above but for answer message combinations as seen by the NAS:
NASで見られるように上記のが、応答メッセージの組み合わせの場合と同じ：
LOCAL-bit HA-Info Meaning
意味LOCALビットHA-情報
0 - No HA assignment allowed for HAAA or [LV]AAA. 0 H-HA L-HA is not allowed. HAAA assigns an H-HA. 1 - L-HA is allowed. No HAAA- or [LV]AAA-assigned HA. 1 L-HA L-HA is allowed. [LV]AAA also assigns an L-HA. 1 H-HA L-HA is allowed. HAAA also assigns an HA. 1 H-HA L-HA is allowed. HAAA assigns an H-HA and + L-HA [LV]AAA also assigns an L-HA.
0 - HAAAまたは[LV] AAAため不可HA割り当て。 0 H-HA L-HAが許可されていません。 HAAAは、H-HAを割り当てます。 1 - L-HAが許可されます。 HAAA-ないか、または[LV] AAA割り当てられたHA全く。 1 L-HA L-HAが許可されています。 [LV] AAAはまた、L-HAを割り当てます。 1 H-HA L-HAが許可されています。 HAAAはまた、HAを割り当てます。 1 H-HA L-HAが許可されています。 HAAAは、H-HAと+ L-HAを割り当てる[LV] AAAはまた、L-HAを割り当てます。
An NAS should expect to receive multiple MIP6-Agent-Info AVPs.
NASは、複数のMIP6-エージェント情報AVPを受け取ることを期待すべきです。
In this scenario, we consider the case where the NAS wishes to allocate a local HA to the MN. The NAS will also inform the Diameter server about the HA address it has assigned to the visiting MN (e.g., 2001:db8:1:c020::1). The Diameter-EAP-Request message, therefore, has the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and the MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-Home-Agent-Address AVP with the address of the proposed HA.
このシナリオでは、NASは、MNにローカルHAを割り当てるしたい場合を考えます。 NASはまた、それが訪問MNに割り当てられた対処HAについてDiameterサーバに通知します（例えば、2001：DB8：1：C020 :: 1）。直径-EAP-Requestメッセージは、従って、LOCAL_HOME_AGENT_ASSIGNMENTとMIP6_INTEGRATEDセットとMIP6-特徴ベクトルを有しています。 MIP6-エージェント情報AVPは、提案されたHAのアドレスをMIP-ホーム・エージェント・アドレスAVPが含まれています。
Diameter
NAS/VAAA Server
| |
| Diameter-EAP-Request |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) |
| MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:1:c020::1)} |
| } |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| |
: ...more EAP Request/Response pairs... :
| |
| |
| Diameter-EAP-Answer |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
| ... |
|<----------------------------------------------------------------|
| |
Figure 2: Home Agent Assignment by the NAS
図2：NASによってホームエージェントの割り当て
Depending on the Diameter server's configuration and the user's subscription profile, the Diameter server either accepts or rejects the local HA allocated by the NAS. In our example, the Diameter server accepts the proposal, and the MIP6-Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT flag (together with the MIP6_INTEGRATED flag) is set and returned to the NAS.
Diameterサーバの設定とユーザの加入プロファイルに応じて、Diameterサーバは、NASによって割り当てられたローカルHAを受け入れるか拒否のいずれか。この例では、ダイアメータサーバは、提案を受け入れ、（一緒にMIP6_INTEGRATEDフラグ付き）LOCAL_HOME_AGENT_ASSIGNMENTフラグとMIP6-特徴ベクトルAVPを設定し、NASに戻されます。
In this scenario, we consider the case where the NAS supports the Diameter MIPv6 integrated scenario as defined in this document, but does not offer local HA assignment. Hence, the MIP6-Feature-Vector AVP only has the MIP6_INTEGRATED flag set. The Diameter server allocates an HA to the mobile node and conveys the address in the MIP-Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-Info AVP. Additionally, the MIP6-Feature-Vector AVP has the MIP6_INTEGRATED flag set.
このシナリオでは、NASは、この文書で定義されている直径MIPv6の統合シナリオをサポートしていますが、地元のHAの割り当てを提供していない場合を考えます。したがって、MIP6-特徴ベクトルAVPのみMIP6_INTEGRATEDフラグが設定されています。 Diameterサーバは、モバイルノードにHAを割り当て、MIP6-エージェント情報AVPにカプセル化さMIP-ホーム・エージェント・アドレスAVPのアドレスを伝えます。また、MIP6-特徴ベクトルAVPはMIP6_INTEGRATEDフラグが設定されています。
Diameter
NAS Server
| |
| Diameter-EAP-Request |
| MIP6-Feature-Vector=(MIP6_INTEGRATED) |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| |
: ...more EAP Request/Response pairs... :
| |
| |
| Diameter-EAP-Answer |
| MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:6000:302::1) |
| } |
| MIP6-Feature-Vector=(MIP6_INTEGRATED) |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
| ... |
|<----------------------------------------------------------------|
| |
Figure 3: Home Agent Assignment by the Diameter Server
図3：直径サーバによるホームエージェントの割り当て
This section shows another message flow for the MIPv6 integrated scenario bootstrapping where the NAS informs the Diameter server that it is able to locally assign an HA to the MN. The Diameter server is able to provide an HA to the MN but also authorizes the assignment of the local HA. The Diameter server then replies to the NAS with HA-related bootstrapping information.
このセクションでは、NASは、ローカルにMNにHAを割り当てることができるDiameterサーバに通知MIPv6の統合シナリオブートストラップのための別のメッセージフローを示します。 Diameterサーバは、MNにHAを提供することができるだけでなく、地元のHAの割り当てを許可します。 Diameterサーバは、HA関連のブートストラップ情報をNASに返信します。
Whether the NAS/ASP then offers a locally assigned HA or the Diameter-server-assigned HA to the MN is, in this example, based on the local ASP policy.
NAS / ASPは、その後、ローカルに割り当てられたHAまたはMNに対する直径サーバーに割り当てられたHAを提供するかどうか、この例では、ローカルASPの方針に基づいています。
Diameter
NAS/VAAA Server
| |
| Diameter-EAP-Request |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) |
| MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:1:c020::1)} |
| } |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| |
: ...more EAP Request/Response pairs... :
| |
| |
| Diameter-EAP-Answer |
| MIP6-Agent-Info{ |
| MIP-Home-Agent-Address(2001:db8:6000:302::1)} |
| MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT |
| | MIP6_INTEGRATED) |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
| ... |
|<----------------------------------------------------------------|
| |
Figure 4: Home Agent Assignment by the NAS or Diameter Server
図4：NASやDiameterサーバによってホームエージェントの割り当て
If the Diameter server does not allow the MN to use a locally assigned HA, the Diameter server returns to the MN the MIP6-Feature-Vector AVP with the LOCAL_HOME_AGENT_ASSIGNMENT bit unset and the HA address it allocated.
Diameterサーバは、MNがLOCAL_HOME_AGENT_ASSIGNMENTビット設定を解除し、それが割り振られたアドレスHAとMN MIP6-特徴ベクトルAVPにローカルに割り当てられたHA、Diameterサーバリターンを使用することを許可していない場合。
Figure 5 lists the MIPv6 bootstrapping NAS-to-HAAA interface AVPs along with a specification determining how many of each new AVP may be included in a Diameter command. They may be present in any Diameter application request and answer commands, where permitted by the command ABNF.
図5のリスト仕様は、それぞれの新しいAVPの方法は、多くの決定と共にNASツーHAAAインターフェースのAVPは、直径コマンドに含まれていてもよいMIPv6のブートストラップ。彼らは、コマンドABNFによって許可任意のDiameterアプリケーションの要求及び回答コマンド、中に存在してもよいです。
+-----------+
| Command |
|-----+-----+
Attribute Name | Req | Ans |
-------------------------------|-----+-----|
MIP6-Agent-Info | 0+ | 0+ |
MIP6-Feature-Vector | 0-1 | 0-1 |
+-----+-----+
Figure 5: Generic Request and Answer Commands AVP Table
図5：一般的な要求とコマンドAVP表を回答
This specification defines the following AVPs that have been allocated from a normal Diameter AVP Code space (values >= 256):
この仕様は、通常直径AVPコード空間（値> = 256）から割り当てられた次のAVPを定義しています。
MIP6-Agent-Info is set to 486
MIP6-エージェント情報は486に設定されています
The following new AVPs are to be allocated from RADIUS Attribute Type space [RFC2865] so that they are RADIUS backward-compatible (AVP Code values between 0-255):
それらはRADIUS下位互換性（AVPコード値は0〜255の間）になるように、次の新しいのAVPはRADIUS属性タイプスペース[RFC2865]から割り当てされるべきです。
MIP6-Feature-Vector is set to 124 MIP6-Home-Link-Prefix is set to 125
MIP6-特徴ベクトルは125に設定されている124 MIP6-ホームリンクプレフィックスに設定されています
IANA has created a new registry for the Mobility Capability as described in Section 4.2.5.
4.2.5項で説明したようにIANAは、モビリティ機能のための新しいレジストリを作成しました。
Token | Value | Description
----------------------------------+---------------------+------------
MIP6_INTEGRATED | 0x0000000000000001 | [RFC5447]
LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC5447]
Available for Assignment via IANA | 2^x |
Allocation rule: Only numeric values that are 2^x (power of two, where x >= 2) are allowed, based on the allocation policy described below.
割り当てルール：2 ^ X（X> = 2 2の累乗）であるだけ数値は、後述する割当ポリシーに基づいて、許可されています。
Following the example policies described in [RFC5226], new values for the Mobility Capability Registry will be assigned based on the "Specification Required" policy. No mechanism to mark entries as "deprecated" is envisioned.
[RFC5226]で説明した例の方針に続いて、モビリティ機能のレジストリの新しい値は、「仕様が必要である」というポリシーに基づいて割り当てられます。 「非推奨」としてエントリをマークするメカニズムが想定されていません。
The security considerations for the Diameter interaction required to accomplish the integrated scenario are described in [INTEGRATED]. Additionally, the security considerations for the Diameter base protocol [RFC3588], the Diameter NASREQ application [RFC4005], and the Diameter EAP application (with respect to network access authentication and the transport of keying material) [RFC4072] are applicable to this document. Developers should insure that special attention is paid to configuring the security associations protecting the messages that enable the global positioning and allocation of home agents, for instance, as outlined in Section 5.
統合シナリオを達成するために必要な直径の相互作用のためのセキュリティ問題は、[INTEGRATED]に記載されています。また、直径ベースプロトコル[RFC3588]、直径NASREQアプリケーション[RFC4005]、および（ネットワークアクセス認証及び鍵材料の輸送に関して）直径EAPアプリケーション[RFC4072]のためのセキュリティ問題は、この文書に適用可能です。開発者は、特別な注意は第5節で概説したように、例えば、ホームエージェントのグローバル・ポジショニングと割り当てを可能にするメッセージを保護するセキュリティアソシエーションを設定するに支払われることを保証すべきです。
Furthermore, the Diameter messages may be transported between the NAS and the Diameter server via one or more AAA brokers or Diameter agents (such as proxies). In this case, the AAA communication from the NAS to the Diameter server relies on the security properties of the intermediate AAA brokers and Diameter agents.
また、Diameterメッセージは、（プロキシとして）は、1つまたは複数のAAAブローカーまたは直径剤を介してNASとDiameterサーバ間で転送することができます。この場合には、ダイアメータサーバにNASからAAA通信は、中間AAAブローカーとDiameterエージェントのセキュリティ特性に依存しています。
This document is heavily based on the ongoing work for RADIUS MIPv6 interaction. Hence, credits go to respective authors for their work with "RADIUS Mobile IPv6 Support" (November 2008). Furthermore, the authors of this document would like to thank the authors of "Diameter Mobile IPv6 Application" (November 2004) -- Franck Le, Basavaraj Patil, Charles E. Perkins, and Stefano Faccin -- for their work in the context of MIPv6 Diameter interworking. Their work influenced this document. Jouni Korhonen would like to thank the Academy of Finland and TEKES MERCoNe Project for providing funding to work on this document while he was with TeliaSonera. Julien Bournelle would like to thank GET/INT since he began to work on this document while he was in their employ. Authors would also like to acknowledge Raymond Hsu for his valuable feedback on local HA assignment and Wolfgang Fritsche for his thorough review. Additionally, we would like to Domagoj Premec for his review comments.
この文書は大きくRADIUS MIPv6の対話のための進行中の作業に基づいています。このため、クレジットは「RADIUSモバイルIPv6のサポート」（2008年11月）での自分の仕事のために、それぞれの作者に行きます。さらに、本書の著者は、「直径モバイルIPv6アプリケーション」（2004年11月）の著者に感謝したいと思います - フランクル、Basavarajパティル、チャールズE.パーキンス、そしてステファノFaccin - のMIPv6の文脈で自分の仕事のために直径のインターワーキング。彼らの作品は、この文書に影響を与えました。 Jouni Korhonenは、彼がテリアソネラであったが、この文書で作業するために資金を提供するためのフィンランドのアカデミーとTEKES MERCoNeプロジェクトに感謝したいと思います。彼は彼らの採用であったが、この文書で作業を始めたので、ジュリアンBournelleはGET / INT感謝したいと思います。著者らはまた、彼の徹底的な見直しのためのローカルHAの割り当てとヴォルフガングFritscheの彼の貴重なフィードバックのためのレイモンド・スーを確認したいと思います。さらに、我々は彼のレビューコメントをDomagoj Premecしたいと思います。
Finally, we would like to thank Alper Yegin, Robert Marks, and David Frascone for their comments at the second WG Last Call.
最後に、我々は、第二のWGラストコールで彼らのコメントのためにアルパースYegin、ロバート・マークス、とデビッドFrasconeに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004]カルフーン、P.、ヨハンソン、T.、パーキンス、C.、ヒラー、T.、およびP.マッキャン、 "直径モバイルIPv4アプリケーション"、RFC 4004、2005年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、RFC 4005、2005年8月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル（EAP）アプリケーション"、RFC 4072、2005年8月。
[AAA] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. Lopez, "AAA Goals for Mobile IPv6", Work in Progress, May 2008.
[AAA] Giaretta、G.、Guardini、I.、DEMARIA、E.、Bournelle、J.、およびR.ロペス、 "モバイルIPv6のためのAAA目標"、進歩、2008年5月に働いています。
[DSMIPv6] Solimand, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6)", Work in Progress, December 2008.
[DSMIPv6] Solimand、H.、 "デュアルスタックホストとルータのためのモバイルIPv6のサポート（DSMIPv6）"、進歩、2008年12月に作業。
[INTEGRATED] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[INTEGRATED]チョードリー、K.とA. Yegin、 "統合シナリオのためのMIP6-ブートストラップ"、進歩、2008年4月の作業。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[RFC4640]パテル、A.およびG. Giaretta、 "ブートストラップモバイルIPv6（MIPv6の）のための問題文"、RFC 4640、2006年9月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026] Giaretta、G.、ケンプ、J.、およびV. Devarapalli、 "分割シナリオにおけるモバイルIPv6ブートストラップ"、RFC 5026、2007年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Jouni Korhonen（編集）、ノキアシーメンスネットワークスLinnoitustie 6 FIN-02600エスポーフィンランド
EMail: jouni.nospam@gmail.com
メールアドレス：jouni.nospam@gmail.com
Julien Bournelle Orange Labs 38-4O rue du general Leclerc Issy-Les-Moulineaux 92794 France
ジュリアンBournelleオレンジLabsの38-4O RUE一般ルクレールイシレムリノー、フランス92794
EMail: julien.bournelle@orange-ftgroup.com
メールアドレス：julien.bournelle@orange-ftgroup.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
電子メール：Hannes.Tschofenig@nsn.com URI：http://www.tschofenig.priv.at
Charles E. Perkins WiChorus Inc. 3590 North First St., Suite 300 San Jose, CA 95134 US
チャールズE.パーキンスWiChorus株式会社3590北まず聖、スイート300サンノゼ、CA 95134米国
EMail: charliep@wichorus.com
メールアドレス：charliep@wichorus.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US
Kuntalチョードリースタレントネットワークス30・インターナショナル・プレイステュークスベリー、マサチューセッツ州01876米国
EMail: kchowdhury@starentnetworks.com
メールアドレス：kchowdhury@starentnetworks.com