[要約] RFC 6611は、統合シナリオにおけるMobile IPv6（MIPv6）のブートストラッピングに関するものであり、MIPv6のネットワーク参加者の初期化と認証をサポートするための手順を提供しています。このRFCの目的は、MIPv6のブートストラッピングプロセスを標準化し、モバイルデバイスのネットワーク参加を容易にすることです。
Internet Engineering Task Force (IETF) K. Chowdhury, Ed.
Request for Comments: 6611 Radio Mobile Access, Inc.
Category: Standards Track A. Yegin
ISSN: 2070-1721 Samsung
May 2012
Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario
統合シナリオのモバイルIPv6（MIPv6）ブートストラップ
Abstract
概要
Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario.
モバイルIPv6ブートストラップは、2つの主要なシナリオに分類できます。分割シナリオと統合シナリオです。分割シナリオでは、モバイルノードのモビリティサービスは、ネットワークアクセス承認者とは異なるサービス承認者によって承認されます。統合シナリオでは、モバイルノードのモビリティサービスは、ネットワークアクセスサービス承認者と同じサービス承認者によって承認されます。このドキュメントでは、統合シナリオのホームエージェント情報検出の方法を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6611.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6611で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction and Scope ..........................................2
2. Terminology .....................................................3
3. Assumptions and Conformance .....................................4
4. Solution Overview ...............................................5
4.1. Logical View of the Integrated Scenario ....................5
4.2. Bootstrapping Message Sequence .............................6
4.2.1. Home Agent Allocation in the MSP ....................7
4.2.2. Home Agent Allocation in the ASP ....................9
4.3. Bootstrapping Message Sequence: Fallback Case .............10
4.4. HoA and IKEv2 SA Bootstrapping in the Integrated
Scenario ..................................................10
5. Security Considerations ........................................10
6. Acknowledgements ...............................................11
7. Contributors ...................................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
The Mobile IPv6 protocol [RFC6275] requires the mobile node to have the following information:
モバイルIPv6プロトコル[RFC6275]では、モバイルノードに次の情報が必要です。
o the Home Address (HoA),
o 自宅の住所（HoA）、
o the home agent address, and
o ホームエージェントアドレス、および
o the cryptographic materials for establishing an IPsec security association with the home agent.
o ホームエージェントとのIPsecセキュリティアソシエーションを確立するための暗号化資料。
The cryptographic materials need to be established prior to initiating the registration process. The mechanism via which the mobile node obtains this information is called "Mobile IPv6 bootstrapping". In order to allow a flexible deployment model for Mobile IPv6, it is desirable to define a bootstrapping mechanism for the mobile node to acquire these parameters dynamically. [RFC4640] describes the problem statement for Mobile IPv6 bootstrapping. It also defines the bootstrapping scenarios based on the relationship between the entity that authenticates and authorizes the mobile node for network access (i.e., the Access Service Authorizer, ASA) and the entity that authenticates and authorizes the mobile node for mobility service (i.e., the Mobility Service Authorizer, MSA). The scenario in which the Access Service Authorizer is not the Mobility Service Authorizer is called the "split" scenario. The bootstrapping solution for the split scenario is defined in [RFC5026]. The scenario in which the Access Service Authorizer is also the Mobility Service Authorizer is called the "integrated" scenario. This document defines a bootstrapping solution for the integrated scenario.
暗号化マテリアルは、登録プロセスを開始する前に確立する必要があります。モバイルノードがこの情報を取得するメカニズムは、「モバイルIPv6ブートストラップ」と呼ばれます。モバイルIPv6の柔軟な導入モデルを可能にするために、モバイルノードがこれらのパラメータを動的に取得するためのブートストラップメカニズムを定義することが望ましいです。 [RFC4640]は、モバイルIPv6ブートストラップの問題ステートメントについて説明しています。また、ネットワークアクセスのためにモバイルノードを認証および許可するエンティティ（Access Service Authorizer、ASA）とモビリティサービスのためにモバイルノードを認証および許可するエンティティ（つまり、 Mobility Service Authorizer、MSA）。 Access Service AuthorizerがMobility Service Authorizerではないシナリオは、「分割」シナリオと呼ばれます。分割シナリオのブートストラップソリューションは、[RFC5026]で定義されています。 Access Service AuthorizerがMobility Service Authorizerでもあるシナリオは、「統合された」シナリオと呼ばれます。このドキュメントでは、統合シナリオのブートストラップソリューションを定義します。
[RFC5026] identifies four different components of the bootstrapping problem: home agent address discovery, HoA assignment, IPsec Security Association [RFC4301] setup, and Authentication and Authorization with the MSA. This document defines a mechanism for home agent address discovery. The other components of bootstrapping are as per [RFC5026].
[RFC5026]は、ブートストラップ問題の4つの異なるコンポーネントを識別します。ホームエージェントアドレスの検出、HoA割り当て、IPsecセキュリティアソシエーション[RFC4301]のセットアップ、MSAによる認証と承認です。このドキュメントでは、ホームエージェントアドレス検出のメカニズムを定義しています。ブートストラップの他のコンポーネントは[RFC5026]によるものです。
In the integrated scenario, the bootstrapping of the home agent information can be achieved via DHCPv6. This document defines the MIPv6 bootstrapping procedures for the integrated scenario. It enables home agent assignment in the integrated scenario by utilizing DHCP and Authentication, Authorization, and Accounting (AAA) protocols. The specification utilizes DHCP and AAA options and attribute-value pairs (AVPs) that are defined in [RFC6610] and [RFC5447]. This document specifies the interworking among Mobile Node (MN), Network Access Server (NAS), DHCP, and AAA entities for the bootstrapping procedure in the integrated scenario.
統合シナリオでは、ホームエージェント情報のブートストラップはDHCPv6を介して実現できます。このドキュメントでは、統合シナリオのMIPv6ブートストラップ手順を定義します。 DHCPと認証、承認、およびアカウンティング（AAA）プロトコルを利用することにより、統合シナリオでのホームエージェントの割り当てを可能にします。この仕様では、[RFC6610]と[RFC5447]で定義されているDHCPとAAAのオプションと属性と値のペア（AVP）を利用しています。このドキュメントでは、統合シナリオでのブートストラップ手順のモバイルノード（MN）、ネットワークアクセスサーバー（NAS）、DHCP、および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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
General mobility terminology can be found in [RFC3753]. The following additional terms, as defined in [RFC4640], are used in this document:
一般的なモビリティ用語は、[RFC3753]にあります。このドキュメントでは、[RFC4640]で定義されている次の追加の用語が使用されています。
Access Service Authorizer (ASA): A network operator that authenticates a mobile node and establishes the mobile node's authorization to receive Internet service.
Access Service Authorizer（ASA）：モバイルノードを認証し、インターネットサービスを受信するためのモバイルノードの承認を確立するネットワークオペレーター。
Access Service Provider (ASP): A network operator that provides direct IP packet forwarding to and from the mobile node.
アクセスサービスプロバイダー（ASP）：モバイルノードとの直接のIPパケット転送を提供するネットワークオペレーター。
Mobility Service Authorizer (MSA): A service provider that authorizes Mobile IPv6 service.
Mobility Service Authorizer（MSA）：モバイルIPv6サービスを承認するサービスプロバイダー。
Mobility Service Provider (MSP): A service provider that provides Mobile IPv6 service. An MSP is called a "home MSP" when MSP == MSA. In this document, the term MSP means a Mobility Service Provider that has a roaming relationship with the MSA but it is not the MSA.
モビリティサービスプロバイダー（MSP）：モバイルIPv6サービスを提供するサービスプロバイダー。 MSP == MSAの場合、MSPは「ホームMSP」と呼ばれます。このドキュメントでは、MSPという用語は、MSAとローミング関係にあるモビリティサービスプロバイダーを意味しますが、MSAではありません。
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.
統合シナリオ：モビリティサービスとネットワークアクセスサービスが同じエンティティによって承認されるシナリオ。
The following assumptions are made in this document:
このドキュメントでは、次のことを前提としています。
(a) MSA == ASA.
（A）MSA == 5月。
(b) MSA and MSP have a roaming relationship.
（b）MSAとMSPにはローミング関係があります。
(c) DHCP relay and NAS are either co-located or there is a mechanism to transfer received AAA information from the NAS to the DHCP relay.
（c）DHCPリレーとNASが同じ場所にあるか、受信したAAA情報をNASからDHCPリレーに転送するメカニズムがあります。
Note: If assignment of a home agent in the home MSP is not required by a deployment, co-location of the NAS and the DHCP relay functions or a mechanism to transfer received AAA information from the NAS to the DHCP relay won't be necessary. In such a case, only the implementation of the options and procedures defined in [RFC6610] should suffice.
注：展開でホームMSPでのホームエージェントの割り当てが不要な場合、NASとDHCPリレー機能のコロケーション、または受信したAAA情報をNASからDHCPリレーに転送するメカニズムは必要ありません。 。そのような場合、[RFC6610]で定義されているオプションと手順の実装だけで十分です。
(d) The NAS shall support MIPv6-specific AAA attributes as specified in [RFC5447].
（d）NASは、[RFC5447]で指定されているMIPv6固有のAAA属性をサポートします。
(e) The AAA server in the home domain (AAAH) used for network access authentication (ASA) has access to the same database as the AAAH used for the mobility service authentication (MSA).
（e）ネットワークアクセス認証（ASA）に使用されるホームドメイン（AAAH）のAAAサーバーは、モビリティサービス認証（MSA）に使用されるAAAHと同じデータベースにアクセスできます。
If home agent assignment is required only in the ASP by the deployment, a minimal implementation of this specification MAY only support the delivery of information from the DHCP server to the DHCP client through [RFC6610]. However, if home agent assignment in the MSP is required by the deployment, an implementation conforming to this specification SHALL be able to transfer the information received from the AAA server to the NAS, and from the NAS to the DHCP relay function. This can be achieved either by co-locating the NAS and the DHCP relay functions or via an interface between these functions. The details of this interface are out of the scope of this specification.
展開によってホームエージェントの割り当てがASPでのみ必要な場合、この仕様の最小限の実装は、[RFC6610]を介したDHCPサーバーからDHCPクライアントへの情報の配信のみをサポートする場合があります。ただし、展開でMSPでのホームエージェントの割り当てが必要な場合、この仕様に準拠した実装では、AAAサーバーからNASに、NASからDHCPリレー機能に受信した情報を転送できる必要があります（SHALL）。これは、NASとDHCPリレー機能を同じ場所に配置するか、これらの機能間のインターフェイスを介して実現できます。このインターフェースの詳細は、この仕様の範囲外です。
In the integrated scenario, the mobile node utilizes the network access authentication process to bootstrap Mobile IPv6. It is assumed that the access service authorizer is mobility service aware. This allows for Mobile IPv6 bootstrapping at the time of access authentication and authorization. Also, the mechanism defined in this document requires the NAS to support MIP6-specific AAA attributes and a co-located DHCP relay agent.
統合シナリオでは、モバイルノードはネットワークアクセス認証プロセスを利用してモバイルIPv6をブートストラップします。アクセスサービス認可者はモビリティサービスを認識していると想定されます。これにより、アクセス認証および承認時にモバイルIPv6ブートストラップが可能になります。また、このドキュメントで定義されているメカニズムでは、NASがMIP6固有のAAA属性と同じ場所に配置されたDHCPリレーエージェントをサポートする必要があります。
Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA proxy in the visited network (AAAV), and a AAA server in the home network (AAAH).
図1は、AAAクライアント（NAS）、訪問先ネットワーク（AAAV）のAAAプロキシ、およびホームネットワーク（AAAH）のAAAサーバーを備えたAAAインフラストラクチャを示しています。
|
ASP(/MSP) | ASA/MSA(/MSP)
|
|
+-------+ | +-------+
| | | | |
|AAAV |-----------|--------|AAAH |
| | | | |
+-------+ | +-------+
| |
| |
| |
| |
+-----+ +------+ |
+----+ | NAS/| |DHCP | |
| MN |------|DHCP |----|Server| |
+----+ |Relay| | | |
+-----+ +------+ |
|
|
+--------+ | +--------+
| HA | | | HA |
| in ASP | | |in MSP |
+--------+ | +--------+
Figure 1: Integrated Scenario, Network Diagram with DHCP Server
図1：DHCPサーバーを使用した統合シナリオ、ネットワーク図
The user's home network authorizes the mobile node for network access and mobility services. Note that usage of a home agent with the mobile node might be selected in the access service provider's network or alternatively in the mobility service provider's network.
ユーザーのホームネットワークは、モバイルノードにネットワークアクセスとモビリティサービスを許可します。モバイルノードでのホームエージェントの使用は、アクセスサービスプロバイダーのネットワークまたはモビリティサービスプロバイダーのネットワークで選択できることに注意してください。
The MSP may be co-located with the ASP, or the ASA/MSA, or independent of the two.
MSPは、ASPまたはASA / MSAと同じ場所に配置することも、2つから独立させることもできます。
The mobile node interacts with the DHCP server via the relay agent after the network access authentication as part of the mobile node configuration procedure.
モバイルノードは、モバイルノード構成手順の一部としてネットワークアクセス認証の後で、リレーエージェントを介してDHCPサーバーと対話します。
In this case, the mobile node is able to acquire the home agent address via a DHCPv6 query. In the integrated scenario, the ASA and the MSA are the same; it can be safely assumed that the AAAH used for network access authentication (ASA) has access to the same database as the AAAH used for the mobility service authentication (MSA). Hence, the same AAAH can authorize the mobile node for network access and mobility service at the same time. When the MN performs Mobile IPv6 registration, the AAAH ensures that the MN is accessing the assigned home agent for that MSP.
この場合、モバイルノードはDHCPv6クエリを介してホームエージェントアドレスを取得できます。統合シナリオでは、ASAとMSAは同じです。ネットワークアクセス認証（ASA）に使用されるAAAHは、モビリティサービス認証（MSA）に使用されるAAAHと同じデータベースにアクセスできると考えることができます。したがって、同じAAAHが、モバイルノードにネットワークアクセスとモビリティサービスを同時に許可できます。 MNがモバイルIPv6登録を実行すると、AAAHは、MNがそのMSPに割り当てられたホームエージェントにアクセスしていることを確認します。
Figure 2 shows the message sequence for home agent allocation in both scenarios -- HA in the ASP (which is co-located with the MSP), or HA in an MSP that is separate from ASP and possibly from the ASA/MSA as well.
図2は、両方のシナリオでのホームエージェント割り当てのメッセージシーケンスを示しています。ASPのHA（MSPと同じ場所に配置されています）、またはASPから、そしておそらくASA / MSAからも分離されているMSPのHAです。
|
--------------ASP------>|<--ASA+MSA--
|
+----+ +------+ +-------+ +-----+
| | | | | | | |
| MN/| |NAS/ | | DHCP | |AAAH |
|User| |DHCP | | Server| | |
| | |relay | | | | |
+----+ +------+ +-------+ +-----+
| | | |
| 1 | 1 | |
|<------------->|<---------------------->|
| | | |
| | | |
| 2 | | |
|-------------->| | |
| | | |
| | 3 | |
| |------------>| |
| | | |
| | 4 | |
| |<------------| |
| | | |
| 5 | | |
|<--------------| | |
| | | |
Figure 2: Message Sequence for Home Agent Allocation
図2：ホームエージェント割り当てのメッセージシーケンス
This section describes a scenario where the home agent is allocated in the mobile node's MSP network(s) that is (are) not co-located with the ASP. In order to provide the mobile node with information about the assigned home agent, the AAAH conveys the assigned home agent's information to the NAS via a AAA protocol, e.g., [RFC5447].
このセクションでは、ホームエージェントが、ASPと同じ場所にないモバイルノードのMSPネットワークに割り当てられるシナリオについて説明します。モバイルノードに割り当てられたホームエージェントに関する情報を提供するために、AAAHは割り当てられたホームエージェントの情報をAAAプロトコル（たとえば[RFC5447]）を介してNASに伝えます。
Figure 2 shows the message sequence for home agent allocation. In the scenario with HA in the MSP, the following details apply.
図2は、ホームエージェント割り当てのメッセージシーケンスを示しています。 MSPにHAがあるシナリオでは、次の詳細が適用されます。
(1) The mobile node executes the network access authentication procedure (e.g., IEEE 802.11i/802.1X), and it interacts with the NAS. The NAS is in the ASP, and it interacts with the AAAH, which is in the ASA/MSA, to authenticate the mobile node. In the process of authorizing the mobile node, the AAAH verifies in the AAA profile that the mobile node is allowed to use the Mobile IPv6 service. The AAAH assigns a home agent in the home MSP, and it assigns one or more home agents in other authorized MSPs and returns this information to the NAS. The NAS may keep the received information for a configurable duration, or it may keep the information for as long as the MN is connected to the NAS.
（1）モバイルノードはネットワークアクセス認証手順（IEEE 802.11i / 802.1Xなど）を実行し、NASと対話します。 NASはASPにあり、ASA / MSAにあるAAAHと対話して、モバイルノードを認証します。モバイルノードを承認するプロセスでは、AAAHは、モバイルノードがモバイルIPv6サービスの使用を許可されていることをAAAプロファイルで確認します。 AAAHはホームMSPにホームエージェントを割り当て、他の許可されたMSPに1つ以上のホームエージェントを割り当て、この情報をNASに返します。 NASは受信した情報を構成可能な期間保持するか、MNがNASに接続されている限りその情報を保持します。
(2) The mobile node sends a DHCPv6 Information-request message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. In this message, the mobile node (DHCP client) SHALL include the following:
（2）モバイルノードはDHCPv6情報要求メッセージ[RFC3315]をAll_DHCP_Relay_Agents_and_Serversマルチキャストアドレスに送信します。このメッセージには、モバイルノード（DHCPクライアント）に以下が含まれている必要があります。
* the Option Code for the Visited Home Network Information option [RFC6610] in the OPTION_ORO.
* OPTION_OROのVisited Home Network Informationオプション[RFC6610]のオプションコード。
* Client Home Network ID FQDN option identifying the MSP.
* MSPを識別するクライアントホームネットワークID FQDNオプション。
* the OPTION_CLIENTID to identify itself to the DHCP server
* DHCPサーバーに対して自分自身を識別するOPTION_CLIENTID
(3) The relay agent intercepts the Information Request from the mobile node and forwards it to the DHCP server. The relay agent also includes the received home agent information from the AAAH in the Relay-Supplied Options option [RFC6610]. If a NAS implementation does not store the received information as long as the MN's session remains in the ASP, and if the MN delays sending a DHCP request, the NAS/DHCP relay does not include the Relay-Supplied Options option in the Relay Forward message.
（3）リレーエージェントは、モバイルノードからの情報要求を傍受し、DHCPサーバーに転送します。また、リレーエージェントは、AAAHから受信したホームエージェント情報をリレー提供オプションオプション[RFC6610]に含めます。 MNのセッションがASPに残っている限り、NAS実装が受信した情報を保存せず、MNがDHCP要求の送信を遅らせる場合、NAS / DHCPリレーは、リレー転送メッセージにリレー提供オプションオプションを含めません。 。
(4) The DHCP server:
（4）DHCPサーバー：
* identifies the client by looking at the DHCP Unique Identifier (DUID) for the client in the OPTION_CLIENTID.
* OPTION_CLIENTIDでクライアントのDHCP一意識別子（DUID）を調べることにより、クライアントを識別します。
* determines that the mobile node is requesting home agent information in the MSP by looking at the Home Network ID FQDN option.
* ホームネットワークID FQDNオプションを調べて、モバイルノードがMSPでホームエージェント情報を要求していることを確認します。
* determines that the home agent is allocated by the AAAH by looking at the Relay-Supplied Options option.
* Relay-Supplied Optionsオプションを調べることにより、ホームエージェントがAAAHによって割り当てられていることを確認します。
* extracts the allocated home agent information from the Relay-Supplied Options option and includes it in the Identified Home Network Information option [RFC6610] in the Reply Message. If the requested information is not available in the DHCP server, it follows the behavior described in [RFC6610].
* リレー提供オプションオプションから割り当てられたホームエージェント情報を抽出し、それを応答メッセージの識別されたホームネットワーク情報オプション[RFC6610]に含めます。要求された情報がDHCPサーバーで利用できない場合、[RFC6610]で説明されている動作に従います。
(5) The relay agent relays the Reply Message from the DHCP server to the mobile node. At this point, the mobile node has the home agent information that it requested.
（5）リレーエージェントは、DHCPサーバーからモバイルノードに応答メッセージをリレーします。この時点で、モバイルノードには、要求したホームエージェント情報があります。
This section describes a scenario where the mobile node requests home agent allocation in the ASP by setting the id-type field to zero in the Home Network Identifier Option [RFC6610] in the DHCPv6 request message. In this scenario, the ASP becomes the MSP for the duration of the network access authentication session.
このセクションでは、DHCPv6要求メッセージのホームネットワーク識別子オプション[RFC6610]でid-typeフィールドをゼロに設定することにより、モバイルノードがASPでホームエージェントの割り当てを要求するシナリオについて説明します。このシナリオでは、ネットワークアクセス認証セッションの間、ASPがMSPになります。
Figure 2 shows the message sequence for home agent allocation. In the scenario with HA in the ASP, the following details apply.
図2は、ホームエージェント割り当てのメッセージシーケンスを示しています。 ASPにHAがあるシナリオでは、次の詳細が適用されます。
(1) The mobile node executes the network access authentication procedure (e.g., IEEE 802.11i/802.1X) and interacts with the NAS. The NAS is in the ASP, and it interacts with the AAAH, which is in the ASA/MSA, to authenticate the mobile node. In the process of authorizing the mobile node, the AAAH verifies in the AAA profile that the mobile node is allowed to use the Mobile IPv6 services. The AAAH assigns a home agent in the home MSP, and it assigns one or more home agents in other authorized MSPs and returns this information to the NAS. Note that the AAAH is not aware of the fact that the mobile node prefers a home agent allocation in the ASP. Therefore, the assigned home agent may not be used by the mobile node. This leaves the location of the mobility anchor point decision to the mobile node.
（1）モバイルノードがネットワークアクセス認証手順（IEEE 802.11i / 802.1Xなど）を実行し、NASと対話します。 NASはASPにあり、ASA / MSAにあるAAAHと対話して、モバイルノードを認証します。モバイルノードを承認するプロセスでは、AAAHは、モバイルノードがモバイルIPv6サービスの使用を許可されていることをAAAプロファイルで確認します。 AAAHはホームMSPにホームエージェントを割り当て、他の許可されたMSPに1つ以上のホームエージェントを割り当て、この情報をNASに返します。 AAAHは、モバイルノードがASPでのホームエージェント割り当てを優先しているという事実を認識していないことに注意してください。したがって、割り当てられたホームエージェントがモバイルノードで使用されない場合があります。これにより、モビリティアンカーポイントの決定場所がモバイルノードに残ります。
(2) The mobile node sends a DHCPv6 Information Request message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. In this message, the mobile node (DHCP client) SHALL include the following:
（2）モバイルノードはDHCPv6情報要求メッセージ[RFC3315]をAll_DHCP_Relay_Agents_and_Serversマルチキャストアドレスに送信します。このメッセージには、モバイルノード（DHCPクライアント）に以下が含まれている必要があります。
* the Option Code for the Home Network Identifier Option [RFC6610] in the OPTION_ORO.
* OPTION_OROのホームネットワーク識別子オプション[RFC6610]のオプションコード。
* the OPTION_CLIENTID to identify itself to the DHCP server.
* DHCPサーバーに対して自分自身を識別するOPTION_CLIENTID。
(3) The relay agent (which is the NAS) intercepts the Information Request from the mobile node and forwards it to the DHCP server. The relay agent also includes the received AAA AVP from the AAAH in the Relay-Supplied Options option [RFC6610].
（3）リレーエージェント（NAS）は、モバイルノードからの情報要求を傍受し、DHCPサーバーに転送します。リレーエージェントは、AAAHから受信したAAA AVPをリレー提供オプションオプション[RFC6610]に含めます。
(4) The DHCP server identifies the client by looking at the DUID for the client in the OPTION_CLIENTID. The DHCP server also determines that the mobile node is requesting home agent information in the ASP by looking at the Visited Home Network Information option. If configured to do so, the DHCP server allocates a home agent from its configured list of home agents and includes it in the Visited Home Network Information Option [RFC6610] in the Reply Message. Note that in this case, the DHCP server does not use the received information in the Relay-Supplied Options option.
（4）DHCPサーバーは、OPTION_CLIENTIDでクライアントのDUIDを調べることにより、クライアントを識別します。 DHCPサーバーは、Visited Home Network Informationオプションを確認して、モバイルノードがASP内のホームエージェント情報を要求していることも確認します。そのように構成されている場合、DHCPサーバーは、構成されたホームエージェントのリストからホームエージェントを割り当て、返信メッセージのVisited Home Network Information Option [RFC6610]に含めます。この場合、DHCPサーバーは、Relay-Supplied Optionsオプションで受信した情報を使用しないことに注意してください。
(5) The relay agent relays the Reply Message from the DHCP server to the mobile node. At this point, the mobile node has the home agent information that it requested.
（5）リレーエージェントは、DHCPサーバーからモバイルノードに応答メッセージをリレーします。この時点で、モバイルノードには、要求したホームエージェント情報があります。
In the fallback case, the mobile node is not able to acquire the home agent information via DHCPv6. The mobile node MAY perform DNS queries to discover the home agent address as defined in [RFC5026]. To perform DNS-based home agent discovery, the mobile node needs to know the DNS server address. The details of how the MN is configured with the DNS server address are outside the scope of this document.
フォールバックの場合、モバイルノードはDHCPv6経由でホームエージェント情報を取得できません。 [RFC5026]で定義されているように、モバイルノードはDNSクエリを実行してホームエージェントアドレスを検出してもよい（MAY）。 DNSベースのホームエージェント検出を実行するには、モバイルノードがDNSサーバーアドレスを知っている必要があります。 MNにDNSサーバーアドレスを構成する方法の詳細は、このドキュメントの範囲外です。
In the integrated scenario, the HoA, IPsec Security Association setup, and Authentication and Authorization with the MSA are bootstrapped via the same mechanism as described in the bootstrapping solution for the split scenario [RFC5026].
統合シナリオでは、HoA、IPsecセキュリティアソシエーションのセットアップ、MSAでの認証と承認は、分割シナリオのブートストラップソリューション[RFC5026]で説明されているのと同じメカニズムでブートストラップされます。
The transport of the assigned home agent information via the AAA infrastructure (i.e., from the AAA server to the AAA client) to the NAS may only be integrity protected as per standard Diameter or other AAA protocol security mechanisms. No additional security considerations are imposed by the usage of this document. The security mechanisms provided by [RFC3588] are applicable for this purpose. This document does not introduce any new security issues to Mobile IPv6.
AAAインフラストラクチャを介した（つまり、AAAサーバーからAAAクライアントへの）割り当てられたホームエージェント情報のNASへのトランスポートは、標準のDiameterまたは他のAAAプロトコルセキュリティメカニズムに従ってのみ整合性を保護できます。このドキュメントの使用により、セキュリティに関する追加の考慮事項は課されません。 [RFC3588]が提供するセキュリティメカニズムは、この目的に適用できます。このドキュメントでは、モバイルIPv6に新しいセキュリティの問題を紹介していません。
The authors would like to thank Kilian Weniger, Vidya Narayanan, and George Tsirtsis for their review and comments. Thanks to Alfred Hoenes for thorough review and valuable suggestions to improve the readability of the document.
著者らは、レビューとコメントを提供してくれたKilian Weniger、Vidya Narayanan、およびGeorge Tsirtsisに感謝します。ドキュメントの読みやすさを改善するための徹底的なレビューと貴重な提案を提供してくれたAlfred Hoenesに感謝します。
This contribution is a joint effort of the bootstrapping solution design team of the MEXT WG. The contributors include Jari Arkko, Julien Bournelle, Kuntal Chowdhury, Vijay Devarapalli, Gopal Dommety, Gerardo Giaretta, Junghoon Jee, James Kempf, Alpesh Patel, Basavaraj Patil, Hannes Tschofenig, and Alper Yegin.
この貢献は、文部科学省WGのブートストラップソリューション設計チームの共同の取り組みです。寄稿者には、Jari Arkko、Julien Bournelle、Kuntal Chowdhury、Vijay Devarapalli、Gopal Dommety、Gerardo Giaretta、Junghoon Jee、James Kempf、Alpesh Patel、Basavaraj Patil、Hannes Tschofenig、Alper Yeginが含まれます。
The design team members can be reached at the following email addresses:
設計チームのメンバーには、次のメールアドレスから連絡できます。
Jari Arkko jari.arkko@kolumbus.fi Julien Bournelle julien.bournelle@orange-ftgroup.com Kuntal Chowdhury kc@radiomobiles.com Vijay Devarapalli Vijay.Devarapalli@AzaireNet.com Gopal Dommety dommety@yahoo.com Gerardo Giaretta gerardog@qualcomm.com Junghoon Jee jhjee@etri.re.kr James Kempf kempf@docomolabs-usa.com Alpesh Patel alpesh@cisco.com Basavaraj Patil basavaraj.patil@nsn.com Hannes Tschofenig hannes.tschofenig@nsn.com Alper Yegin alper.yegin@yegin.org
Jari Arkko jari.arkko@columbus.fi Julien Bournelle julien.bournelle@orange-ftgroup.com Kuntal Chowdhury kcradiomobiles.com Vijay Devarapalli Vijay.Devarapalli@AzaireNet.com Gopal Dommety dommetyoyahoo.com Gerardoga.com Junghoon Jee jhjee@etri.re.kr James Kempf kempf@docomolabs-usa.com Alpesh Patel alpesh@cisco.com Basavaraj Patil basavaraj.patil@nsn.com Hannes Tschofenig hannes.tschofenig@nsn.com Alper Yegin alper.yegin@yegin .org
[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月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[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、「Diameter Base Protocol」、RFC 3588、2003年9月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]ジャレッタ、G。、ケンプ、J。、およびV.デバラパリ、「スプリットシナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009.
[RFC5447] Korhonen、J.、Bournelle、J.、Tschofenig、H.、Perkins、C。、およびK. Chowdhury、「Diameter Mobile IPv6：Support for Network Access Server to Diameter Server Interaction」、RFC 5447、2009年2月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. Lemon, "DHCP Option for Home Agent Discovery in Mobile IPv6 (MIPv6)", RFC 6610, May 2012.
[RFC6610] Jang、H.、Yegin、A.、Chowdhury、K.、Choi、J。、およびT. Lemon、「DHCP Option for Home Agent Discovery in Mobile IPv6（MIPv6）」、RFC 6610、2012年5月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] Manner、J。およびM. Kojo、「Mobility Related Terminology」、RFC 3753、2004年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[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月。
Authors' Addresses
著者のアドレス
Kuntal Chowdhury (editor) Radio Mobile Access, Inc. 100 Ames Pond Dr. Tewksbury MA 01876
Kuntal Chowdhury（editor）Radio Mobile Access、Inc. 100 Ames Pond Dr. Tewksbury MA 01876
EMail: kc@radiomobiles.com
Alper Yegin Samsung Istanbul Turkey
Alper Yegin Samsungイスタンブールトルコ
EMail: alper.yegin@yegin.org