[要約] RFC 5447は、ネットワークアクセスサーバ（NAS）とDiameterサーバの相互作用をサポートするためのMobile IPv6の拡張に関するものです。このRFCの目的は、NASとDiameterサーバ間の通信を改善し、Mobile IPv6の機能を拡張することです。
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
直径モバイルIPv6：ネットワークアクセスサーバーのDiameter Serverインタラクションのサポート
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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）インフラストラクチャとの相互作用をサポートすることです。このドキュメントでは、Home AAA ServerインターフェイスへのDiameter Network Access Serverを使用した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]では、モバイルノード（MN）が、現在のアタッチメントポイントに関する情報を使用してホームエージェント（HA）と登録を実行する必要があります（住所の世話）。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の）ネットワーク内の直径サーバーは、これらのパラメーターを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):
ホーム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（LAAA）：
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).
訪問されたネットワーク、つまり訪問された領域にある認証、承認、および会計プロキシ。ローミングの場合、ローカル直径プロキシにはVAAAの役割があります（図1を参照）。
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-To-HAAA（Home AAA）サーバー通信の直径ベースの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インターフェイスを介して直径サーバーと対話します。
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 Serverがネットワークアクセスの認証と承認を実行すると、ユーザーがMIPV6サービスに対して承認されているかどうかも判断します。MIPV6サービスの承認とユーザーのポリシープロファイルに基づいて、DiameterサーバーはNASにいくつかのMIPV6ブートストラップに関連するパラメーターを返すことができます。このドキュメントで説明されているNASからHAAAへのインターフェイスは、NAS/直径クライアントからモバイルノードに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ブートストラップの統合シナリオのために、NASからHAAAのインターフェースで使用される多くの属性値ペア（AVP）を定義します。これらのAVPは、コマンドABNFによって許可されている現在および将来の直径アプリケーションで使用できます。次のセクションで既存のアプリケーションとそのコマンドを使用した例は、情報提供のみを目的としています。このドキュメントの例は、拡張可能な認証プロトコル（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-Agent-INFO AVP（AVPコード486）はグループ化されたタイプで、MNにHAを割り当てるために必要な情報が含まれています。MIP6-Agent-INFO AVPがメッセージに存在する場合、MIP-Home-Agent-Address AVP、MIP-Home-Agent-Host 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.
MIP6-Agent-INFOにMIP-Home-Agent-AddressとMIP-Home-Agent-Host APVが両方である場合、MIP-Home-Agent-AddressはMIP-Home-Agent-Hostよりも優先されるはずです。この推奨の理由は、MIP-Home-Agent-Addressが特定のホームエージェントを指しているのに対し、MIP-Home-Agent-Hostは同じ領域内にあるグループのグループを指している可能性があるためです。たとえば、直径のクライアントまたはエージェントは、MIP-Home-Agent-Host AVPを使用して、HAがどの領域に配置されているかを調べることができます。
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の両方のアドレスを備えている展開に役立つ機能であり、特にデュアルスタックモバイルIPv6（DSMIPV6）展開シナリオ[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.
MIP6-Agent-INFO AVPは、ローカルに割り当てられたHAのヒントとして直径サーバーに送信された場合、NASまたは中間の直径プロキシによってリクエストメッセージ内の中間直径プロキシによって添付される場合があります。このAVPは、局所的に割り当てられている場合、直径サーバーによって承認されている場合、直径サーバーからの返信メッセージに中間の直径プロキシによって添付される場合があります。たとえば、NASがMNのホームネットワークからHA情報を受け取り、訪問されたネットワークからローカルに割り当てられたHA情報を受け取る場合、直径メッセージのMIP6-AGENT-INFO 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-Home-Agent-Address AVP（AVPコード334 [RFC4004]）はタイプアドレスであり、MIPV6 HAのIPv6またはIPv4アドレスが含まれています。Diameterサーバーは、添付ファイルのポイントに近接しているMNにHAを割り当てることを決定する場合があります（たとえば、NAS-IDENTIFIER AVPによって決定されます）。たとえば、トラフィックの負荷を共有するために、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-Home-Agent-Host AVP（AVPコード348 [RFC4004]）はグループ化されており、割り当てられたMIPV6 HAのアイデンティティが含まれています。HAの宛先リアルムと宛先ホストAVPの両方が、グループ化されたAVPに含まれています。MIP-Home-Agent-Host AVPの使用は、MIP-Home-Agent-Address AVPに相当しますが、DNSインフラストラクチャを使用して追加のレベルの間接を提供します。宛先ホストAVPは、HAを識別するために使用され、宛先-RealM 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が正確に1つの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-Home-Agent-Host AVPは、常にMIP6-Agent-INFO AVPに含まれることをお勧めします。このように、HAは、MIP6-Agent-RealM AVPを使用してMIP6-Agent-INFO AVPを追加した直径エンティティの対応する領域に関連付けられます。これは、MIP-Home-Agent-Host 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-Home-Link-Prefix AVP（AVPコード125）はタイプのオクテットストリングで、モバイルIPv6ホームネットワークプレフィックス情報がネットワークバイト順に含まれています。ホームネットワークのプレフィックスは、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は、MNSのプレフィックスを管理する中央エンティティとして機能する場合があります。この場合、HAAAはMNに割り当てられた接頭辞をNASに戻します。NAS/ASPは、[統合]で説明されているメカニズムを使用して、MNにホームリンクのプレフィックスをMNに配信します。NAS/ASPは、リクエストメッセージにMIP6-Home-Link-Prefix 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-feature-Vector AVP（AVPコード124）は、signed64のタイプで、NAS/ ASPのサポートされた機能の64ビットフラグフィールドが含まれています。値0でmip6-feature-vector 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には、NAS/ASP to the Diameterサーバーの機能を示すために、このAVPを含めることができます。たとえば、NASは、ローカルHAを提供できることを示している場合があります。同様に、Diameterサーバーには、NAS/ASPにASA/MSA（/MSP）によってサポートまたは承認されているNAS/ASPのどの機能がサポートまたは承認されているかをNAS/ASPに通知するために、このAVPを含めることができます。
The following capabilities are defined in this document: MIP6_INTEGRATED (0x0000000000000001)
このドキュメントでは、次の機能が定義されています。MIP6_INTEGREATED（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に割り当てられる場合があります。このフラグがAnswerメッセージのDiameterサーバーによって設定されると、Localの割り当てはDiameterサーバーによって承認されます。
A local HA may be assigned by the NAS, LAAA, or VAAA depending on the network architecture and the deployment.
ネットワークアーキテクチャと展開に応じて、NAS、LAAA、またはVAAAによってローカルHAが割り当てられる場合があります。
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:
次の例は、local_home_agent_assignment（例ではローカルビットと呼ばれる）能力とmip-agent-info avp（例ではha-infoと呼ばれる）が、hasを割り当てるためにどのように使用されるかを示しています。l-ha）またはホームネットワークha（h-ha）。以下は、HAAAで見られるリクエストメッセージの組み合わせの例です。
LOCAL-bit HA-Info Meaning
ローカルビットHA-INFOの意味
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-infoは無視する必要があります。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
ローカルビットHA-INFOの意味
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-assigned 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-Agent-INFO 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が地元のHAをMNに割り当てたい場合を検討します。NASはまた、訪問MNに割り当てたHAアドレスについて直径サーバーに通知します（例：2001：DB8：1：C020 :: 1）。したがって、直径-Eap-Requestメッセージには、local_home_agent_assignmentとmip6_integratedセットを備えたmip6-feature-vectorがあります。MIP6-Agent-INFO AVPには、提案されたHAのアドレスを含むMIP-Home-Agent-Address 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 Serverの構成とユーザーのサブスクリプションプロファイルに応じて、DiameterサーバーはNASによって割り当てられたローカルHAを受け入れるか拒否します。この例では、Diameterサーバーは提案を受け入れ、local_home_agent_assignmentフラグを使用したmip6-feature-vector avp（mip6_integratedフラグと一緒に）が設定され、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-Feature-Vector AVPには、MIP6_integratedフラグが設定されています。Diameterサーバーは、HAをモバイルノードに割り当て、MIP6-Agent-INFO AVPにカプセル化されているMIP-Home-Agent-Address AVPのアドレスを伝えます。さらに、MIP6-Feature-Vector 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.
このセクションでは、MIPV6統合シナリオブートストラップの別のメッセージフローを示しています。NASは、MNにHAをローカルに割り当てることができることを直径サーバーに通知します。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または直径サーバーが割り当てられたHAをMNに提供するかどうかは、この例では、ローカル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または直径サーバーによるホームエージェントの割り当て
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.
直径サーバーがMNがローカルに割り当てられたHAを使用できない場合、DiameterサーバーはMNにMIP6-Feature-Vector AVPに戻り、local_home_agent_assignmentビットが表示され、HAは割り当てられました。
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に、MIPV6ブートストラップNAS-To-HAAAインターフェイスAVPと、各新しいAVPの数が直径コマンドに含まれる可能性があるかどうかを決定する仕様を示します。それらは、任意の直径アプリケーションリクエストと回答コマンドに存在する場合があります。
+-----------+
| 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コードスペースから割り当てられた次のAVPを定義します（Value> = 256）：
MIP6-Agent-Info is set to 486
MIP6-AGENT-INFOは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):
次の新しいAVPは、RADIUS属性タイプスペース[RFC2865]から割り当てられ、半径の後方互換性（AVPコード値は0〜255）になります。
MIP6-Feature-Vector is set to 124
MIP6-Home-Link-Prefix is set to 125
IANA has created a new registry for the Mobility Capability as described in Section 4.2.5.
IANAは、セクション4.2.5で説明されているように、モビリティ機能のための新しいレジストリを作成しました。
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の電力、x> = 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.
統合シナリオを達成するために必要な直径相互作用のセキュリティ上の考慮事項は、[統合]で説明されています。さらに、直径ベースプロトコル[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.
さらに、直径メッセージは、1つ以上のAAAブローカーまたは直径エージェント（プロキシなど）を介してNASと直径サーバーの間で輸送される場合があります。この場合、NASから直径サーバーへのAAA通信は、中間AAAブローカーと直径エージェントのセキュリティプロパティに依存しています。
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月）の著者に感謝したいと思います。MIPV6の文脈での作業について、フランク・ル、バサヴァラジ・パティル、チャールズ・E・パーキンス、ステファノ・フェイシン - 直径のインターワーキング。彼らの仕事はこの文書に影響を与えました。Jouni Korhonenは、フィンランドアカデミーとTekes Mercone Projectに、彼がTeliasoneraと一緒にいる間にこの文書に取り組むための資金提供を提供してくれたことに感謝したいと思います。ジュリアン・ボーンレルは、彼が雇用中にこの文書に取り組み始めたので、Get/intに感謝したいと思います。著者はまた、地元のHA割り当てとWolfgang Fritscheについての彼の徹底的なレビューのために彼の貴重なフィードバックについてRaymond HSUを認めたいと思います。さらに、彼のレビューコメントについては、Domagoj Premecを希望しています。
Finally, we would like to thank Alper Yegin, Robert Marks, and David Frascone for their comments at the second WG Last Call.
最後に、2回目のWGラストコールでのコメントについて、Alper Yegin、Robert Marks、David Frasconeに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T。、およびP. McCann、「直径モバイルIPv4アプリケーション」、RFC 4004、2005年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（EAP）アプリケーション」、RFC 4072、2005年8月。
[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. Lopez、「Mobile 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。、「デュアルスタックホストとルーター（DSMIPV6）のモバイルIPv6サポート」、2008年12月、進行中の作業。
[INTEGRATED] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[統合] Chowdhury、K。およびA. Yegin、「統合シナリオのMIP6ブートストラップ」、2008年4月、進行中の作業。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] MANER、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[RFC4640] Patel、A。およびG. Giaretta、「モバイルIPv6（MIPV6）のブートストラップの問題声明」、RFC 4640、2006年9月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026] Giaretta、G.、Kempf、J。、およびV. Devarapalli、「分割シナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[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（編集者）Nokia Siemens Networks Linnoitustie 6 Espoo Fin-02600フィンランド
EMail: jouni.nospam@gmail.com
Julien Bournelle Orange Labs 38-4O rue du general Leclerc Issy-Les-Moulineaux 92794 France
Julien Bournelle Orange Labs 38-4o Rue General Leclerc Issy-Les-Moulineaux 92794 France
EMail: julien.bournelle@orange-ftgroup.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
EMail: 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
Charles E. Perkins Wichorus Inc. 3590 North First St.、Suite 300 San Jose、CA 95134 US
EMail: charliep@wichorus.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury、MA 01876 US
EMail: kchowdhury@starentnetworks.com