[要約] RFC 4640は、モバイルIPv6（MIPv6）のブートストラップに関する問題を述べたものであり、MIPv6の導入と展開の際に生じる課題を明確にすることを目的としています。
Network Working Group A. Patel, Ed.
Request for Comments: 4640 Cisco
Category: Informational G. Giaretta, Ed.
Telecom Italia
September 2006
Problem Statement for Bootstrapping Mobile IPv6 (MIPv6)
ブートストラップモバイルIPv6（MIPV6）の問題ステートメント
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping.
モバイルノードには、少なくとも次の情報が必要です。ホームアドレス、ホームエージェントアドレス、およびホームエージェントとのセキュリティ協会がホームエージェントに登録します。この情報を取得するプロセスは、ブートストラップと呼ばれます。このドキュメントでは、モバイルIPv6（MIPV6）のモバイルノードをブートストラップする方法と、モバイルノードブートストラップのさまざまな潜在的な展開シナリオに関する問題について説明します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Bootstrapping ..............................................3
1.3. Terminology ................................................4
2. Assumptions .....................................................5
3. Design Goals ....................................................6
4. Non-goals .......................................................7
5. Motivation for bootstrapping ....................................7
5.1. Addressing .................................................7
5.1.1. Dynamic Home Address Assignment .....................7
5.1.2. Dynamic Home Agent Assignment .......................9
5.1.3. "Opportunistic" or "Local" Discovery ................9
5.1.4. Management Requirements .............................9
5.2. Security Infrastructure ...................................10
5.2.1. Integration with AAA Infrastructure ................10
5.3. Topology Change ...........................................10
5.3.1. Dormant Mode Mobile Nodes ..........................10
6. Network Access and Mobility Services ...........................11
7. Deployment Scenarios ...........................................13
7.1. Mobility Service Subscription Scenario ....................13
7.2. Integrated ASP Network Scenario ...........................14
7.3. Third-Party MSP Scenario ..................................14
7.4. Infrastructure-less Scenario ..............................15
8. Parameters for Authentication ..................................15
9. Security Considerations ........................................17
9.1. Security Requirements of Mobile IPv6 ......................17
9.2. Threats to the Bootstrapping Process ......................18
10. Contributors ..................................................19
11. Acknowledgements ..............................................20
12. Informative References ........................................20
Mobile IPv6 [RFC3775] specifies mobility support based on the assumption that a mobile node (MN) has a trust relationship with an entity called the home agent. Once the home agent address has been learned (for example, via manual configuration, anycast discovery mechanisms, or DNS lookup), Mobile IPv6 signaling messages between the mobile node and the home agent are secured with IPsec or with the authentication protocol, as defined in [RFC4285]. The requirements for this security architecture are created with [RFC3775], and the details of this procedure are described in [RFC3776].
モバイルIPv6 [RFC3775]は、モバイルノード（MN）がホームエージェントと呼ばれるエンティティとの信頼関係を持っているという仮定に基づいて、モビリティサポートを指定します。ホームエージェントアドレスが学習されると（たとえば、手動構成、Anycastディスカバリーメカニズム、DNSルックアップを介して）、モバイルノードとホームエージェント間のモバイルIPv6シグナリングメッセージは、IPSECまたは認証プロトコルで固定されます。[RFC4285]。このセキュリティアーキテクチャの要件は[RFC3775]で作成され、この手順の詳細は[RFC3776]で説明されています。
In [RFC3775], there is an implicit requirement that the MN be provisioned with enough information that will permit it to register successfully with its home agent. However, having this information statically provisioned creates practical deployment issues.
[RFC3775]では、MNにホームエージェントに正常に登録できる十分な情報をMNにプロビジョニングするという暗黙の要件があります。ただし、この情報を静的にプロビジョニングすると、実用的な展開の問題が作成されます。
This document serves to define the problem of bootstrapping. Bootstrapping is defined as the process of obtaining enough information at the mobile node that it can successfully register with an appropriate home agent.
このドキュメントは、ブートストラップの問題を定義するのに役立ちます。ブートストラップは、適切なホームエージェントに正常に登録できるモバイルノードで十分な情報を取得するプロセスとして定義されます。
The requirements for bootstrapping could consider various scenarios/network deployment issues. It is the basic assumption of this document that certain minimal parameters (seed information) are available to the mobile node to aid in bootstrapping. The exact seed information available differs depending on the deployment scenario. This document describes various deployment scenarios and provides a set of minimal parameters that are available in each deployment scenario.
ブートストラップの要件は、さまざまなシナリオ/ネットワーク展開の問題を考慮することができます。このドキュメントの基本的な仮定は、特定の最小パラメーター（シード情報）がモバイルノードで利用可能であり、ブートストラップを支援することです。利用可能な正確な種子情報は、展開シナリオによって異なります。このドキュメントでは、さまざまな展開シナリオについて説明し、各展開シナリオで使用できる一連の最小パラメーターを提供します。
This document stops short of suggesting the preferred solutions for how the mobile node should obtain information. Such details will be available from separate documents.
このドキュメントは、モバイルノードが情報を取得する方法についての好ましいソリューションを提案していないことを停止します。このような詳細は、個別のドキュメントから入手できます。
Mobile IPv6 [RFC3775] expects the mobile node to have a static home address, a home agent address (which can be derived from an anycast address), and a security association with a home agent (or multiple home agents).
モバイルIPv6 [RFC3775]は、モバイルノードに静的なホームアドレス、ホームエージェントアドレス（Anycastアドレスから派生できる）、およびホームエージェント（または複数のホームエージェント）とのセキュリティ関連があることを期待しています。
This static provisioning of information has various problems, as discussed in Section 5.
セクション5で説明したように、この情報の静的プロビジョニングにはさまざまな問題があります。
The aim of this document is:
このドキュメントの目的は次のとおりです。
o To define bootstrapping;
o ブートストラップを定義します。
o To identify sample deployment scenarios where Mobile Internet Protocol version 6 (MIPv6) will be deployed, taking into account the relationship between the subscriber and the service provider; and
o サブスクライバーとサービスプロバイダーの関係を考慮して、モバイルインターネットプロトコルバージョン6（MIPV6）が展開されるサンプル展開シナリオを特定するため。と
o To identify the minimal set of information required on the Mobile Node and in the network in order for the mobile node to obtain address and security credentials, to register with the home agent.
o モバイルノードがアドレスとセキュリティの資格情報を取得するために、モバイルノードとネットワークで必要な最小限の情報セットを特定し、ホームエージェントに登録します。
Bootstrapping is defined as obtaining enough information at the mobile node that the mobile node can successfully register with an appropriate home agent. Specifically, this means obtaining the home agent address and home address, and for the mobile node and home agent to authenticate and mutually construct security credentials for Mobile IPv6.
ブートストラップは、モバイルノードで適切なホームエージェントに正常に登録できるモバイルノードで十分な情報を取得することとして定義されます。具体的には、これはホームエージェントアドレスとホームアドレスを取得し、モバイルノードとホームエージェントがモバイルIPv6のセキュリティ資格情報を認証および相互に構築することを意味します。
Typically, bootstrapping happens when a mobile node does not have all the information it needs to set up the Mobile IPv6 service. This includes, but is not limited to, situations in which the mobile node does not having any information when it boots up for the first time (out of the box), or does not retain any information during reboots.
通常、ブートストラップは、モバイルノードにモバイルIPv6サービスをセットアップするために必要なすべての情報がない場合に発生します。これには、モバイルノードが初めて（箱から出して）起動したときに情報がない場合、または再起動中に情報を保持しない状況が含まれますが、これらに限定されません。
Also, in certain scenarios, after the MN bootstraps for the first time (out of the box), the need for subsequent bootstrapping is implementation dependent. For instance, the MN may bootstrap every time it boots, bootstrap every time on prefix change, or bootstrap periodically to anchor to an optimal HA (based on distance, load, etc.).
また、特定のシナリオでは、MN Bootstrapsの初めて（箱から出して）後、その後のブートストラップの必要性は実装に依存します。たとえば、MNは、プレフィックスの変更時に毎回起動、ブートストラップ、または定期的にブートストラップするたびにブートストラップをブートストラップして、最適なHA（距離、負荷などに基づいて）に固定することができます。
General mobility terminology can be found in [RFC3753]. The following additional terms are used here:
一般的なモビリティの用語は[RFC3753]にあります。ここでは、次の追加項が使用されています。
Trust relationship
信頼関係
In the context of this document, trust relationship means that the two parties in question, typically the user of the mobile host and the mobility or access service authorizer, have some sort of prior contact in which the mobile node was provisioned with credentials. These credentials allow the mobile node to authenticate itself to the mobility or access service provider and to prove its authorization to obtain service.
このドキュメントのコンテキストでは、信頼関係は、問題の2つの関係者、通常はモバイルホストのユーザーとモビリティまたはアクセスサービスの承認者が、モバイルノードが資格情報でプロビジョニングされたある種の連絡先を持っていることを意味します。これらの資格情報により、モバイルノードはモビリティまたはアクセスサービスプロバイダーに認証され、サービスを取得する許可を証明できます。
Infrastructureless relationship
インフラストラクチャレス関係
In the context of this document, an infrastructureless relationship is one in which the user of the mobile node and the mobility or access service provider have no previous contact and the mobile node is not required to supply credentials to authenticate and prove authorization for service. Mobility and/or network access service is provided without any authentication or authorization. Infrastructureless in this context does not mean that there is no network infrastructure, such as would be the case for an ad hoc network.
このドキュメントのコンテキストでは、インフラストラクチャレス関係は、モバイルノードとモビリティまたはアクセスサービスプロバイダーのユーザーが以前の連絡先を持たず、モバイルノードがサービスの許可を認証および証明するために資格情報を提供する必要はありません。モビリティおよび/またはネットワークアクセスサービスは、認証や許可なしに提供されます。このコンテキストでは、インフラストラクチャレスは、アドホックネットワークの場合のようなネットワークインフラストラクチャがないことを意味するものではありません。
Credentials
資格
Data used by a mobile node to authenticate itself to a mobility or access network service authorizer and to prove authorization to receive service. User name/passwords, one time password cards, public/private key pairs with certificates, and biometric information are some examples.
モバイルノードで使用されるデータは、モビリティまたはアクセスネットワークサービスの承認者に認証され、サービスを受信する許可を証明するために使用されます。ユーザー名/パスワード、1回限りのパスワードカード、証明書付きのパブリック/秘密キーペア、および生体認証情報がいくつかの例です。
ASA
として
Access Service Authorizer. A network operator that authenticates a mobile node and establishes the mobile node's authorization to receive Internet service.
アクセスサービス承認者。モバイルノードを認証し、モバイルノードのインターネットサービスを受信する許可を確立するネットワークオペレーター。
ASP
ASP
Access Service Provider. A network operator that provides direct IP packet forwarding to and from the end host.
アクセスサービスプロバイダー。エンドホストとの間で直接IPパケット転送を提供するネットワークオペレーター。
Serving Network Access Provider
ネットワークアクセスプロバイダーにサービスを提供します
A network operator that is the mobile node's ASP but not its ASA. The serving network access provider may or may not additionally provide mobility service.
モバイルノードのASPであるが、ASAではないネットワークオペレーター。サービングネットワークアクセスプロバイダーは、さらにモビリティサービスを提供する場合とそうでない場合があります。
Home Network Access Provider
ホームネットワークアクセスプロバイダー
A network operator that is both the mobile node's ASP and ASA. The home network access provider may or may not additionally provide mobility service (note that this is a slightly different definition from that in RFC 3775).
モバイルノードのASPとASAの両方であるネットワークオペレーター。ホームネットワークアクセスプロバイダーは、さらにモビリティサービスを提供する場合とそうでない場合があります（これは、RFC 3775の定義とはわずかに異なる定義であることに注意してください）。
IASP
iasp
Integrated Access Service Provider. A service provider that provides both authorization for network access and mobility service.
統合アクセスサービスプロバイダー。ネットワークアクセスとモビリティサービスの許可の両方を提供するサービスプロバイダー。
MSA
MSA
Mobility Service Authorizer. A service provider that authorizes Mobile IPv6 service.
モビリティサービスオーサイザー。モバイルIPv6サービスを承認するサービスプロバイダー。
MSP
MSP
Mobility Service Provider. A service provider that provides Mobile IPv6 service. In order to obtain such service, the mobile node must be authenticated and prove authorization to obtain the service. Home Mobility Service Provider
モビリティサービスプロバイダー。モバイルIPv6サービスを提供するサービスプロバイダー。このようなサービスを取得するには、モバイルノードを認証し、サービスを取得するための許可を証明する必要があります。ホームモビリティサービスプロバイダー
A MSP that both provides mobility service and authorizes it.
両方ともモビリティサービスを提供し、それを許可するMSP。
Serving Mobility Service Provider
モビリティサービスプロバイダーにサービスを提供します
A MSP that provides mobility service but depends on another service provider to authorize it.
モビリティサービスを提供するが、別のサービスプロバイダーに依存するMSPは、それを許可します。
o A basic assumption in Mobile IPv6 [RFC3775] is that there is a trust relationship between the mobile node and its home agent(s). This trust relationship can be direct, or indirect through, for instance, an ASP that has a contract with the MSP. This trust relationship can be used to bootstrap the MN.
o モバイルIPv6 [RFC3775]の基本的な仮定は、モバイルノードとそのホームエージェントの間に信頼関係があることです。この信頼関係は、たとえば、MSPと契約を結ぶASPを通じて直接的であるか、間接的である可能性があります。この信頼関係は、MNをブートストラップするために使用できます。
One typical way of verifying the trust relationship is using authentication, authorization, and accounting (AAA) infrastructure. In this document, two distinct uses of AAA are considered:
信頼関係を検証する1つの典型的な方法は、認証、承認、会計（AAA）インフラストラクチャを使用することです。このドキュメントでは、AAAの2つの異なる用途が考慮されます。
AAA for Network Access
ネットワークアクセス用のAAA
This functionality provides authentication and authorization to access the network (obtain address and send/receive packets).
この機能は、ネットワークにアクセスするための認証と承認を提供します（アドレスを取得してパケットを送信/受信します）。
AAA for Mobility Service
モビリティサービスのAAA
This functionality provides authentication and authorization for mobility services.
この機能は、モビリティサービスの認証と承認を提供します。
These functionalities may be implemented in a single entity or in different entities, depending on the service models described in Section 6 or deployment scenarios as described in Section 7.
これらの機能は、セクション6で説明されているサービスモデルまたはセクション7で説明されている展開シナリオに応じて、単一のエンティティまたは異なるエンティティで実装できます。
o Some identifier, such as an Network Access Identifier (NAI), as defined in [RFC4283] or [RFC2794], is provisioned on the MN that permits the MN to identify itself to the ASP and MSP.
o [RFC4283]または[RFC2794]で定義されているネットワークアクセス識別子（NAI）などの一部の識別子は、MNがASPとMSPに同定できるようにするMNにプロビジョニングされます。
A solution to the bootstrapping problem has the following design goals:
ブートストラップの問題の解決策には、次の設計目標があります。
o The following information must be available at the end of bootstrapping, to enable the MN to register with the HA.
o MNがHAに登録できるようにするには、ブートストラップの終了時に次の情報を利用できる必要があります。
* MN's home agent address
* MNのホームエージェントアドレス
* MN's home address
* MNの自宅の住所
* IPsec Security Association (SA) between MN and HA, Intenet Key Exchange Protocol (IKE) pre-shared secret between MN and HA
* MNとHAの間のIPSECセキュリティ協会（SA）、Intenet Key Exchange Protocol（IKE）MNとHAの間の事前共有秘密
o The bootstrapping procedure can be triggered at any time, either by the MN or by the network. Bootstrapping can occur, for instance, due to administrative action, information going stale, or HA indicating the MN. Bootstrapping may be initiated even when the MN is registered with the HA and has all the required credentials. This may typically happen to refresh/renew the credentials.
o ブートストラップ手順は、MNまたはネットワークによっていつでもトリガーできます。たとえば、管理アクション、情報が古くなっている、またはMNを示すHAのために、ブートストラップが発生する可能性があります。ブートストラップは、MNがHAに登録され、必要なすべての資格情報を持っている場合でも、開始される場合があります。これは通常、資格情報を更新/更新するために起こる可能性があります。
o Subsequent protocol interaction (for example, updating the IPsec SA) can be executed between the MN and the HA itself without involving the infrastructure that was used during bootstrapping.
o 後続のプロトコル相互作用（たとえば、IPSEC SAの更新）は、ブートストラップ中に使用されたインフラストラクチャを含めることなく、MNとHA自体の間で実行できます。
o Solutions to the bootstrapping problem should enable storage of user-specific information on entities other than the home agent.
o ブートストラップの問題の解決策は、ホームエージェント以外のエンティティに関するユーザー固有の情報を保存できるようにする必要があります。
o Solutions to the bootstrapping problem should not exclude storage of user-specific information on entities other than the home agent.
o ブートストラップの問題の解決策は、ホームエージェント以外のエンティティに関するユーザー固有の情報のストレージを除外すべきではありません。
o Configuration information which is exchanged between the mobile node and the home agent must be secured using integrity and replay protection. Confidentiality protection should be provided if necessary.
o モバイルノードとホームエージェントの間で交換される構成情報は、整合性とリプレイ保護を使用して保護する必要があります。必要に応じて、機密保護を提供する必要があります。
o The solution should be applicable to all feasible deployment scenarios that can be envisaged, along with the relevant authentication/authorization models.
o ソリューションは、関連する認証/承認モデルとともに、想定できるすべての実行可能な展開シナリオに適用できる必要があります。
This following issues are clearly outside the scope of bootstrapping:
この次の問題は、明らかにブートストラップの範囲外です。
o Home prefix renumbering is not explicitly supported as part of bootstrapping. If the MN executes the bootstrap procedures every time it powers on (as opposed to caching state information from previous bootstrap process), then home network renumbering is taken care of automatically.
o ホームプレフィックスの変更は、ブートストラップの一部として明示的にサポートされていません。MNが、以前のブートストラッププロセスからの状態情報をキャッシュするのではなく）を使用するたびにブートストラップ手順を実行する場合、ホームネットワークの変更は自動的に処理されます。
o Bootstrapping in the absence of a trust relationship between MN and any provider is not considered.
o MNとプロバイダーとの間に信頼関係がない場合のブートストラップは考慮されません。
The default bootstrapping described in the Mobile IPv6 base specification [RFC3775] has a tight binding to the home addresses and home agent addresses.
モバイルIPv6ベース仕様[RFC3775]で説明されているデフォルトのブートストラップは、ホームアドレスとホームエージェントアドレスに緊密なバインディングを持っています。
In this section, we discuss the problems caused by the currently tight binding to home addresses and home agent addresses.
このセクションでは、自宅の住所とホームエージェントアドレスへの現在緊密な拘束力によって引き起こされる問題について説明します。
Currently, the home agent uses the mobile node's home address for authorization. When manual keying is used, this happens through the security policy database, which specifies that a certain security association may only be used for a specific home address. When dynamic keying is used, the home agent ensures that the IKE Phase 1 identity is authorized to request security associations for the given home address. Mobile IPv6 uses IKEv1, which is unable to update the security policy database according to a dynamically assigned home address. As a result, static home address assignment is really the only home address configuration technique compatible with the base specification.
現在、ホームエージェントは、承認のためにモバイルノードのホームアドレスを使用しています。手動キーを使用すると、これはセキュリティポリシーデータベースを介して発生します。これは、特定のセキュリティ協会が特定のホームアドレスにのみ使用される可能性があることを指定します。動的キーイングが使用されると、ホームエージェントは、IKEフェーズ1のIDが、指定されたホームアドレスのセキュリティ協会を要求することを許可されることを保証します。モバイルIPv6はIKEV1を使用します。IKEV1は、動的に割り当てられたホームアドレスに従ってセキュリティポリシーデータベースを更新できません。その結果、静的ホームアドレスの割り当ては、ベース仕様と互換性のある唯一のホームアドレス構成手法です。
However, support for dynamic home address assignment would be desirable for the following reasons:
ただし、次の理由により、動的なホームアドレスの割り当てのサポートが望ましいでしょう。
Dynamic Host Configuration Protocol (DHCP)-based address assignment. Some providers may want to use DHCPv6 or other dynamic address assignment (e.g., IKEv2) from the home network to configure home addresses.
動的ホスト構成プロトコル（DHCP）ベースのアドレス割り当て。一部のプロバイダーは、ホームネットワークからDHCPV6またはその他の動的アドレス割り当て（IKEV2など）を使用して、ホームアドレスを構成することをお勧めします。
Recovery from a duplicate address collision. It may be necessary to recover from a collision of addresses on the home network by one of the mobile nodes changing its home address.
複製アドレスの衝突からの回復。ホームアドレスを変更するモバイルノードの1つによって、ホームネットワーク上の住所の衝突から回復する必要がある場合があります。
Addressing privacy. It may be desirable to establish randomly generated addresses as in [RFC3041] and use them for a short period of time. Unfortunately, current protocols make it possible to use such addresses only from the visited network. As a result, these addresses cannot be used for communications lasting longer than the attachment to a particular visited network.
プライバシーへの対処。[RFC3041]のようにランダムに生成されたアドレスを確立し、それらを短時間使用することが望ましい場合があります。残念ながら、現在のプロトコルにより、訪問されたネットワークからのみそのようなアドレスを使用できます。その結果、これらのアドレスは、特定の訪問ネットワークへの添付ファイルよりも長持ちする通信に使用することはできません。
Ease of deployment. In order to simplify the deployment of Mobile IPv6, it is desirable to free users and administrators from the task of allocating home addresses and specifying them in the security policy database. This is consistent with the general IPv6 design goal of using autoconfiguration wherever possible.
展開の容易さ。モバイルIPv6の展開を簡素化するために、自宅の住所を割り当ててセキュリティポリシーデータベースで指定するタスクからユーザーや管理者を無料で無料で使用することが望ましいです。これは、可能な限りAutoConfigurationを使用するという一般的なIPv6設計の目標と一致しています。
Prefix changes in the home network. The Mobile IPv6 specification contains support for a mobile node to autoconfigure a home address as based on its discovery of prefix information on the home subnet [RFC3775]. Autoconfiguration in case of network renumbering is done by replacing the existing network prefix with the new network prefix.
ホームネットワークのプレフィックスの変更。モバイルIPv6仕様には、ホームサブネット[RFC3775]のプレフィックス情報の発見に基づいて、ホームアドレスを自動構成するモバイルノードのサポートが含まれています。autoconfigurationネットワークの変更の場合は、既存のネットワークプレフィックスを新しいネットワークプレフィックスに置き換えることで行われます。
Subsequently, the MN needs to update the mobility binding in the HA to register the newly configured Home Address. However, the MN may not be able to register the newly configured address with the HA if a security association related to that reconfigured Home Address does not exist in the MN and the HA. This situation is not handled in the current MIPv6 specification [RFC3775].
その後、MNはHAのモビリティバインディングを更新して、新しく構成されたホームアドレスを登録する必要があります。ただし、MNとHAに再構成されたホームアドレスに関連するセキュリティ協会が存在しない場合、MNは、新しく構成された住所をHAに登録できない場合があります。この状況は、現在のMIPV6仕様[RFC3775]で処理されていません。
Currently, the address of the home agent is specified in the security policy database. Support for multiple home agents requires the configuration of multiple security policy database entries.
現在、ホームエージェントのアドレスは、セキュリティポリシーデータベースで指定されています。複数のホームエージェントのサポートには、複数のセキュリティポリシーデータベースエントリの構成が必要です。
However, support for dynamic home agent assignment would be desirable for the following reasons:
ただし、次の理由により、動的ホームエージェントの割り当てのサポートが望ましいでしょう。
Home agent discovery. The Mobile IPv6 specification contains support for a mobile node to autoconfigure a home agent address as based on a discovery protocol [RFC3775].
ホームエージェントディスカバリー。モバイルIPv6仕様には、ディスカバリープロトコル[RFC3775]に基づいて、ホームエージェントアドレスを自動構成するモバイルノードのサポートが含まれています。
Independent network management. An MSP may want to assign home agents dynamically in different subnets; for instance, not require that a roaming mobile node have a fixed home subnet.
独立したネットワーク管理。MSPは、異なるサブネットでホームエージェントを動的に割り当てることをお勧めします。たとえば、ローミングモバイルノードに固定ホームサブネットがあることを必要としません。
Local home agents. The mobile node's MSP may want to allow the serving MSP to assign a local home agent for the mobile node. This is useful from the point of view of communications efficiency and has also been mentioned as one approach to support location privacy.
地元のホームエージェント。モバイルノードのMSPは、サービングMSPがモバイルノードにローカルホームエージェントを割り当てることを許可する場合があります。これは、通信効率の観点からは有用であり、ロケーションプライバシーをサポートするための1つのアプローチとしても言及されています。
Ease of deployment. In order to simplify the deployment of Mobile IPv6, it is desirable to free users and administrators from the task of allocating home agent addresses in a static manner. Moreover, an MSP may want to have a dynamic home agent assignment mechanism to load balance users among home agents located on different links.
展開の容易さ。モバイルIPv6の展開を簡素化するために、ホームエージェントアドレスを静的な方法で割り当てるタスクからユーザーや管理者を無料で無料で使用することが望ましいです。さらに、MSPには、さまざまなリンクにあるホームエージェント間でユーザーのバランスバランスをロードするための動的なホームエージェント割り当てメカニズムが必要な場合があります。
The home agent discovery protocol does not support an "opportunistic" or local discovery mechanisms in an ASP's local access network. It is expected that the mobile node must know the prefix of the home subnet in order to be able to discover a home agent. It must either obtain that information through prefix update or have it statically configured. A more typical pattern for inter-domain service discovery in the Internet is that the client (mobile node in this case) knows the domain name of the service and uses DNS to find the server in the visited domain. For local service discovery, DHCP is typically used.
ホームエージェントディスカバリープロトコルは、ASPのローカルアクセスネットワークで「日和見的」またはローカル発見メカニズムをサポートしていません。ホームエージェントを発見できるように、モバイルノードはホームサブネットのプレフィックスを知っている必要があると予想されます。プレフィックスの更新を介してその情報を取得するか、静的に構成する必要があります。インターネットでのドメイン間サービスの発見のより典型的なパターンは、クライアント（この場合はモバイルノード）がサービスのドメイン名を把握し、DNSを使用して訪問ドメイン内のサーバーを見つけることです。ローカルサービスの発見には、通常、DHCPが使用されます。
As described earlier, new addresses invalidate configured security policy databases and authorization tables. Regardless of the specific protocols used, there is a need for either an automatic system for updating the security policy entries or manual configuration. These requirements apply to both home agents and mobile nodes, but it cannot be expected that mobile node users are capable of performing the required tasks.
前述のように、新しいアドレスは、構成されたセキュリティポリシーデータベースと承認表を無効にします。使用される特定のプロトコルに関係なく、セキュリティポリシーエントリを更新するための自動システムまたは手動構成のいずれかが必要です。これらの要件は、ホームエージェントとモバイルノードの両方に適用されますが、モバイルノードユーザーが必要なタスクを実行できることは予想できません。
The current IKEv1-based dynamic key exchange protocol, described in [RFC3776], has no integration with backend authentication, authorization, and accounting techniques unless the authentication credentials and trust relationships use certificates or pre-shared secrets.
[RFC3776]に記載されている現在のIKEV1ベースの動的キー交換プロトコルは、認証資格と信頼関係が証明書または恥ずかしさの秘密を使用しない限り、バックエンド認証、承認、および会計手法と統合されていません。
Certificates are not easily supported by traditional AAA infrastructures. Where a traditional AAA infrastructure is used, the home agent is not able to leverage authentication and authorization information established between the mobile node, the foreign AAA server, and the home AAA server. This would be desirable when the mobile node gains access to the foreign network, in order to authenticate the mobile node's identity and determine whether the mobile node is authorized for mobility service.
証明書は、従来のAAAインフラストラクチャによって簡単にサポートされません。従来のAAAインフラストラクチャが使用されている場合、ホームエージェントは、モバイルノード、外国AAAサーバー、およびホームAAAサーバーの間に確立された認証と承認情報を活用できません。これは、モバイルノードのアイデンティティを認証し、モバイルノードがモビリティサービスを許可されているかどうかを判断するために、モバイルノードが外部ネットワークへのアクセスを獲得する場合に望ましいでしょう。
The lack of connection to the AAA infrastructure also means that the home agent does not know where to send accounting records at appropriate times during the mobile node's session, as determined by the business relationship between the MSP and the mobile node's owner.
AAAインフラストラクチャへの接続の欠如はまた、MSPとモバイルノードの所有者とのビジネス関係によって決定されるように、モバイルノードのセッション中に適切な時間に会計レコードを送信する場所をホームエージェントが知らないことを意味します。
Presumably, some backend AAA protocol between the home agent and home AAA could be utilized, but IKEv1 does not contain support for exchanging full AAA credentials with the mobile node. It is worthwhile to note that IKEv2 provides this feature.
おそらく、ホームエージェントとホームAAAの間のバックエンドAAAプロトコルを利用することができますが、IKEV1にはモバイルノードと完全なAAA資格情報を交換するためのサポートは含まれていません。IKEV2がこの機能を提供していることに注意する価値があります。
The description of the protocol to push prefix information to mobile nodes in Section 10.6 of [RFC3775] has an implicit assumption that the mobile node is active and taking IP traffic. In fact, many, if not most, mobile devices will be in a low power "dormant mode" to save battery power, or will even be switched off, so they will miss any propagation of prefix information. As a practical matter, if this protocol is used, an MSP will need to keep the old prefix around and handle any queries to the old home agent anycast address on the old subnet, whereby the mobile node asks for a new home agent as described in Section 11.4, until all mobile nodes are accounted for. Even then, since some mobile nodes are likely to be turned off for long periods, some owners would need to be contacted by other means, reducing the utility of the protocol.
[RFC3775]のセクション10.6のモバイルノードにプレフィックス情報をプッシュするプロトコルの説明には、モバイルノードがアクティブでIPトラフィックを取得しているという暗黙の仮定があります。実際、ほとんどではないにしても、多くのモバイルデバイスはバッテリー電源を節約するために低電力の「休眠モード」になります。または、オフにされることもあるため、プレフィックス情報の伝播を見逃します。実用的な問題として、このプロトコルを使用する場合、MSPは古い接頭辞を維持し、古いサブネットの古いホームエージェントAnycastアドレスのクエリを処理する必要があります。すべてのモバイルノードが考慮されるまで、セクション11.4。それでも、一部のモバイルノードは長期間オフになる可能性が高いため、一部の所有者は他の手段で連絡する必要があり、プロトコルの有用性を減らします。
Bootstrapping does not explicitly try to solve this problem of home network renumbering when MN is in dormant mode. If the MN can configure itself after it 'comes back on' by reinitiating the bootstrapping process, then network renumbering problem is fixed as a side effect.
ブートストラップは、MNが休眠モードになった場合、ホームネットワークの名前を変更するというこの問題を明示的に解決しようとはしません。MNがブートストラッププロセスを再考して「戻ってきた」後にMNが自らを設定できる場合、ネットワークの変更問題は副作用として修正されます。
This section defines some terms as they pertain to authentication and practical network deployment/roaming scenarios. This description lays the groundwork for Section 7. The focus is on the 'service' model since, ultimately, it is the provider providing the service that wants to authenticate the mobile (and vice versa for mutual authentication between provider and the user of the service).
このセクションでは、認証と実用的なネットワーク展開/ローミングシナリオに関係する用語を定義します。この説明にはセクション7の基礎があります。最終的には、モバイルを認証したいサービスを提供するプロバイダーであるため、「サービス」モデルに焦点が当てられています（プロバイダーとサービスのユーザー間の相互認証のために逆も同様です。）。
Network access service enables a host to send and receive IP packets on the Internet or an intranet. IP address configuration and IP packet forwarding capabilities are required to deliver this service. A network operator providing this service is called an access service provider (ASP). An ASP can, for example, be a commercial ASP, the IT department of an enterprise network, or the maintainer of a home (residential) network.
ネットワークアクセスサービスにより、ホストはインターネットまたはイントラネットでIPパケットを送信および受信できます。このサービスを提供するには、IPアドレスの構成とIPパケット転送機能が必要です。このサービスを提供するネットワークオペレーターは、アクセスサービスプロバイダー（ASP）と呼ばれます。たとえば、ASPは、商業ASP、エンタープライズネットワークのIT部門、または家庭（住宅）ネットワークのメンテナーである可能性があります。
If the mobile node is not directly usable for communication at the current location of the MN in which network access service is provided by its home ASP, the mobile node is roaming. In this case, the home ASP acts as the access service authorizer, but the actual network access is provided by the serving network access provider. During the authentication and authorization prior to the mobile nodes having Internet access, the serving network access provider may simply act as a routing agent for authentication and authorization back to the access service authorizer, or it may require an additional authentication and authorization step itself. An example of a roaming situation is when a business person is using a hotspot service in an airport and the hotspot service provider has a roaming agreement with the business person's cellular provider. In that case, the hotspot network is acting as the serving network access provider, and the cellular network is acting as the access service authorizer. When the business person moves from the hotspot network to the cellular network, the cellular network is both the home access service provider and the access service authorizer.
モバイルノードが、Home ASPによってネットワークアクセスサービスが提供されるMNの現在の場所での通信に直接使用できない場合、モバイルノードはローミングしています。この場合、Home ASPはAccess Service Authorizerとして機能しますが、実際のネットワークアクセスはサービングネットワークアクセスプロバイダーによって提供されます。モバイルノードがインターネットにアクセスできる前の認証と承認中に、サービングネットワークアクセスプロバイダーは、アクセスサービスオーサイザーに戻る認証と承認のためのルーティングエージェントとして単に機能するか、追加の認証と承認ステップ自体が必要になる場合があります。ローミングの状況の例は、ビジネスパーソンが空港でホットスポットサービスを使用しており、ホットスポットサービスプロバイダーがビジネスパーソンの携帯電話プロバイダーとローミング契約を結んでいることです。その場合、Hotspot Networkはサービングネットワークアクセスプロバイダーとして機能し、Cellular Networkはアクセスサービスオーサイザーとして機能しています。ビジネス担当者がホットスポットネットワークからセルラーネットワークに移動すると、セルラーネットワークはホームアクセスサービスプロバイダーとアクセスサービスオーサイザーの両方です。
Mobility service using Mobile IPv6 is conceptually and possibly also in practice separate from network access service, though of course network access is required prior to providing mobility. Mobile IPv6 service enables an IPv6 host to maintain its reachability despite changing its network attachment point (subnets). A network operator providing Mobile IPv6 service is called a mobility service provider (MSP). Granting Mobile IPv6 service requires that a host authenticate and prove authorization for the service. A network operator that authenticates a mobile node and authorizes mobility service is called a mobility service authorizer (MSA). If both types of operation are performed by the same operator, that operator is called a home mobility service provider. If authentication and authorization is provided by one operator and the actual service is provided by another, the operator providing the service is called the serving mobility service provider. The serving MSP must contact the mobile node's mobility service authorizer to check the mobile node's authorization prior to granting mobility service.
モバイルIPv6を使用したモビリティサービスは、モビリティを提供する前にネットワークアクセスが必要ですが、ネットワークアクセスサービスとは別に概念的に、そしておそらく実際には実際にもあります。モバイルIPv6サービスにより、IPv6ホストは、ネットワークアタッチメントポイント（サブネット）を変更しても、到達可能性を維持できます。モバイルIPv6サービスを提供するネットワークオペレーターは、モビリティサービスプロバイダー（MSP）と呼ばれます。モバイルIPv6サービスを付与するには、ホストがサービスの認証を認識し、証明する必要があります。モバイルノードを認証し、モビリティサービスを承認するネットワークオペレーターは、モビリティサービスオーサイザー（MSA）と呼ばれます。両方のタイプの操作が同じオペレーターによって実行される場合、そのオペレーターはホームモビリティサービスプロバイダーと呼ばれます。認証と承認が1つのオペレーターによって提供され、実際のサービスが別のオペレーターによって提供されている場合、サービスを提供するオペレーターはサービスモビリティサービスプロバイダーと呼ばれます。サービングMSPは、モバイルノードのモビリティサービスオーサイザーに連絡して、モビリティサービスを付与する前にモバイルノードの承認を確認する必要があります。
The service model defined here clearly separates the entity providing the service from the entity that authenticates and authorizes the service. In the case of basic network access, this supports the traditional and well-known roaming model, in which inter-operator roaming agreements allow a host to obtain network access in areas where their home network access provider does not have coverage. In the case of mobility service, this allows a roaming mobile node to obtain mobility service in the local operator's network while having that service authorized by the home operator. The service model also allows mobility service and network access service to be provided by different entities. This allows a network operator with no wireless access, such as, for example, an enterprise network operator, to deploy a Mobile IPv6 home agent for mobility service while the actual wireless network access is provided by the serving network access providers with which the enterprise operator has a contract. Here are some other possible combinations of ASPs and MSPs:
ここで定義されているサービスモデルは、サービスを認証および承認するエンティティからサービスを提供するエンティティを明確に分離しています。基本的なネットワークアクセスの場合、これは従来の有名なローミングモデルをサポートします。このモデルでは、操作者間ローミング契約により、ホストがホームネットワークアクセスプロバイダーにカバレッジがないエリアでネットワークアクセスを取得できます。モビリティサービスの場合、これにより、ローミングモバイルノードがホームオペレーターによってそのサービスを許可しながら、ローカルオペレーターのネットワークでモビリティサービスを取得できます。また、サービスモデルにより、モビリティサービスとネットワークアクセスサービスをさまざまなエンティティから提供できます。これにより、たとえばエンタープライズネットワークオペレーターなど、ワイヤレスアクセスを持たないネットワークオペレーターがモバイルIPv6ホームエージェントをモビリティサービス用に展開できます。契約があります。ASPとMSPの他の可能な組み合わせを次に示します。
o The serving ASP might be the home ASP. Similarly, the serving MSP might be the home MSP.
o サービングASPはホームASPかもしれません。同様に、サービングMSPはホームMSPである可能性があります。
o The home ASP and the home MSP may be the same operator, or not. When they are the same, the same set of credentials may be used for both services.
o Home ASPとHome MSPは同じオペレーターであるかどうかです。それらが同じ場合、両方のサービスに同じセットの資格情報が使用される場合があります。
o The serving ASP and the serving MSP may be the same operator, or not.
o サービングASPとサービングMSPは同じオペレーターであるかどうかです。
o It is possible that serving ASP and home MSP are the same operator.
o ASPとホームMSPにサービスを提供することは同じオペレーターである可能性があります。
Similarly the home ASP and serving MSP may be the same. Also, the ASA and MSA may be the same.
同様に、Home ASPとサービスを提供するMSPは同じかもしれません。また、ASAとMSAは同じかもしれません。
These entities and all combinations that are reasonable from a deployment perspective must be taken into consideration to solve the Mobile IPv6 bootstrapping problem. They impact home agent discovery, home address configuration, and mobile node-to-home agent authentication aspects.
これらのエンティティと、展開の観点から合理的なすべての組み合わせを、モバイルIPv6ブートストラップの問題を解決するために考慮する必要があります。ホームエージェントの発見、ホームアドレスの構成、モバイルノード間エージェント認証の側面に影響を与えます。
This section describes the various network deployment scenarios. The various combinations of service providers described in Section 6 are considered.
このセクションでは、さまざまなネットワーク展開シナリオについて説明します。セクション6で説明されているサービスプロバイダーのさまざまな組み合わせを考慮します。
For each scenario, the underlying assumptions are described. The basic assumption is that there is a trust relationship between mobile user and the MSA. Typically, this trust relationship is between the mobile user and AAA in the MSA's network. Seed information needed to bootstrap the mobile node is considered in two cases:
各シナリオについて、根本的な仮定について説明します。基本的な仮定は、モバイルユーザーとMSAの間に信頼関係があるということです。通常、この信頼関係は、MSAのネットワークのモバイルユーザーとAAAの間です。モバイルノードをブートストラップするために必要なシード情報は、2つのケースで考慮されます。
o AAA authentication is mandatory for network access.
o AAA認証は、ネットワークアクセスに必須です。
o AAA authentication is not part of network access.
o AAA認証は、ネットワークアクセスの一部ではありません。
The seed information is described further in Section 8.
シード情報については、セクション8でさらに説明します。
Many commercial deployments are based on the assumption that mobile nodes have a subscription with a service provider. In this scenario the MN has a subscription with an MSA, also called the home MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is responsible for setting up a home agent on a subnet that acts as a Mobile IPv6 home link. As a consequence, the home MSP should explicitly authorize and control the whole bootstrapping procedure.
多くの商用展開は、モバイルノードにサービスプロバイダーとサブスクリプションがあるという仮定に基づいています。このシナリオでは、MNには、モバイルIPv6サービス用のHome MSPとも呼ばれるMSAのサブスクリプションがあります。セクション6で述べたように、MSPは、モバイルIPv6ホームリンクとして機能するサブネットにホームエージェントを設定する責任があります。結果として、Home MSPは、ブートストラップ手順全体を明示的に承認および制御する必要があります。
Since the MN is assumed to have a pre-established trust relationship with its home provider, it must be configured with an identity and credentials; for instance, an NAI and a shared secret by some out-of-band means (i.e., manual configuration) before bootstrapping.
MNは、そのホームプロバイダーとの事前に確立された信頼関係を持っていると想定されるため、IDと資格情報で構成する必要があります。たとえば、ブートストラップ前のいくつかの帯域外の手段（つまり、手動構成）によるNAIと共有秘密。
In order to guarantee ubiquitous service, the MN should be able to bootstrap MIPv6 operations with its home MSP from any possible access location, such as an open network or a network managed by an ASP, that may be different from the MSP and that may not have any pre-established trust relationship with it.
ユビキタスサービスを保証するために、MNは、MSPとは異なる場合があり、そうでない場合があります。事前に確立された信頼関係を持っています。
In this scenario, the ASA and MSA are the same entity. The MN has security credentials for access to the network, and these credentials can also be used to bootstrap MIPv6.
このシナリオでは、ASAとMSAは同じエンティティです。MNには、ネットワークへのアクセスのためのセキュリティ資格情報があり、これらの資格情報を使用してMIPV6をブートストラップすることもできます。
Figure 1 describes an AAA design example for integrated ASP scenario.
図1は、統合されたASPシナリオのAAAデザインの例を説明しています。
+----------------------------+
| IASP(ASA+MSA) |
+----+ +-----+ +----+ |
| MN |--- | NAS | | HA | |
+----+ +-----+ +----+ |
| \ \ |
| \ +------+ \ +-------+ |
| -|AAA-NA| -|AAA-MIP| |
| +------+ +-------+ |
+----------------------------+
NAS: Network Access Server AAA-NA: AAA for network access AAA-MIP: AAA for Mobile IP service
NAS：ネットワークアクセスサーバーAAA-NA：ネットワークアクセス用AAA AAA-MIP：モバイルIPサービスのAAA
Figure 1. Integrated ASP network
図1.統合されたASPネットワーク
Mobility service has traditionally been provided by the same entity that authenticates and authorizes the subscriber for network access. This is certainly the only model supported by the base Mobile IPv6 specification.
モビリティサービスは、従来、ネットワークアクセスのためにサブスクライバーを認証および承認するのと同じエンティティによって提供されてきました。これは確かに、ベースモバイルIPv6仕様によってサポートされる唯一のモデルです。
In the third-party mobility service provider scenario, the subscription for mobility service is made with one entity (the MSA, is for instance, a corporate), but the actual mobility service is provided by yet another entity (such as an operator specializing in this service, the serving MSP). These two entities have a trust relationship. Transitive trust among the mobile node and these two entities may be used to assure the participants that they are dealing with trustworthy peers.
サードパーティモビリティサービスプロバイダーのシナリオでは、モビリティサービスのサブスクリプションは1つのエンティティ（MSA、たとえば企業）で行われますが、実際のモビリティサービスは、さらに別のエンティティによって提供されます（このサービス、サービングMSP）。これらの2つのエンティティには信頼関係があります。モバイルノードとこれら2つのエンティティ間の推移的信頼を使用して、参加者が信頼できる仲間を扱っていることを保証することができます。
This arrangement is similar to the visited - home operator roaming arrangement for network access.
この配置は、訪問されたものと似ています - ネットワークアクセスのためのホームオペレーターローミングアレンジメント。
Figure 2 describes an example of a network for the third-party MSP scenario.
図2は、サードパーティのMSPシナリオのネットワークの例を説明しています。
+--------------+ +--------+
| | |Serving |
| ASP | | MSP |
+----+ +-----+ | | +----+ |
| MN |--- | NAS | | | | HA | | +-------------------+
+----+ +-----+ |===| +----+ | | MSA |
| \ | | \ || (e.g., corporate NW)|
| \ +------+ | | \ | +-------+ |
| -|AAA-NA| | | -------|AAA-MIP| |
| +------+ | | | | +-------+ |
+------------ + +--------+ +-------------------+
Figure 2. Third-Party MSP network
図2.サードパーティMSPネットワーク
Infrastructure refers to network entities like AAA, Public-Key Infrastructure (PKI), and Home Location Register (HLR). "Infrastructure-less" implies that there is no dependency on any elements in the network with which the user has any form of trust relationship.
インフラストラクチャとは、AAA、パブリックキーインフラストラクチャ（PKI）、ホームロケーションレジスタ（HLR）などのネットワークエンティティを指します。「インフラストラクチャレス」は、ユーザーが何らかの形の信頼関係を持っているネットワーク内の要素に依存していないことを意味します。
In such a scenario, there is absolutely no relationship between host and infrastructure.
このようなシナリオでは、ホストとインフラストラクチャの間にはまったく関係がありません。
A good example of infrastructure-less environment for MIPv6 bootstrapping is the IETF network at IETF meetings. It is possible that there could be MIP6 service available on this network (i.e., a MIPv6 HA). However, there is not really any AAA infrastructure or, for that matter, any trust relationship that a user attending the meeting has with any entity in the network.
MIPV6ブートストラップのインフラストラクチャレス環境の良い例は、IETFミーティングのIETFネットワークです。このネットワークでMIP6サービスを利用できる可能性があります（つまり、MIPV6 HA）。ただし、AAAインフラストラクチャや、会議に出席するユーザーがネットワーク内のエンティティと持っている信頼関係は実際にはありません。
This specific scenario is not supported in this document. The reason for this is described in Section 9.
この特定のシナリオは、このドキュメントではサポートされていません。この理由は、セクション9で説明されています。
The following is a list of parameters that are used as the seed for the bootstrapping procedure. The parameters vary depending on whether authentication for network access is independent of authentication for mobility services. If different client identities are used for network access and mobility services, authentication for network access is independent of authentication for mobility services.
以下は、ブートストラップ手順のシードとして使用されるパラメーターのリストです。パラメーターは、ネットワークアクセスの認証がモビリティサービスの認証とは無関係かどうかによって異なります。ネットワークアクセスとモビリティサービスに異なるクライアントIDが使用される場合、ネットワークアクセスの認証はモビリティサービスの認証とは無関係です。
o Parameter Set 1
o パラメーターセット1
In this case, authentication for network access is independent of authentication for mobility services.
この場合、ネットワークアクセスの認証は、モビリティサービスの認証とは無関係です。
If the home agent address is not known to the mobile node, the following parameter is needed for discovering the home agent address:
ホームエージェントアドレスがモバイルノードに不明な場合、ホームエージェントアドレスを発見するには、次のパラメーターが必要です。
* The domain name or Fully Qualified Domain Name (FQDN) of the home agent
* ホームエージェントのドメイン名または完全資格のドメイン名（FQDN）
This parameter may be derived in various ways, such as (but not limited to) static configuration, use of the domain name from the network access NAI (even if AAA for network access is not otherwise used), or use of the domain name of the serving ASP, where the domain name may be obtained via DHCP in the serving ASP.
このパラメーターは、静的構成、ネットワークアクセスNAIのドメイン名の使用（ネットワークアクセスのAAAが使用されない場合でも）、またはドメイン名の使用など、さまざまな方法で導出される場合があります。サービングASP。ドメイン名は、サービングASPのDHCPを介して取得できます。
If the home agent address is not known but the home subnet prefix is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may be used for discovering the home agent address, and the above parameter may not be used.
ホームエージェントのアドレスが不明であるがホームサブネットのプレフィックスがわかっている場合、モバイルIPv6の動的ホームエージェントアドレスの発見は、ホームエージェントアドレスを発見するために使用される場合があり、上記のパラメーターは使用されない場合があります。
When the home agent address is known to the mobile node, the following parameter is needed for performing mutual authentication between the mobile node and the home agent by using IKE:
ホームエージェントアドレスがモバイルノードに知られている場合、IKEを使用してモバイルノードとホームエージェント間で相互認証を実行するために、次のパラメーターが必要です。
* IKE credentials (*)
* IKE資格情報（*）
In the case where the home agent does not have the entire set of IKE credentials, the home agent may communicate with another entity (for example, an AAA server) to perform mutual authentication in IKE. In such a case, the IKE credentials include the credentials used between the mobile node and the other entity. In the case where an AAA protocol is used for the communication between the home agent and the other entity during the IKE procedure, AAA for Mobile IPv6 service may be involved in IKE. If the authentication protocol [RFC4285] is used, the shared key-based security association with the home agent is needed.
ホームエージェントがIKE資格情報のセット全体を持っていない場合、ホームエージェントはIKEで相互認証を実行するために別のエンティティ（AAAサーバーなど）と通信することができます。そのような場合、IKE資格情報には、モバイルノードと他のエンティティ間で使用される資格情報が含まれます。IKE手順中にホームエージェントと他のエンティティ間の通信にAAAプロトコルが使用される場合、モバイルIPv6サービスのAAAがIKEに関与する可能性があります。認証プロトコル[RFC4285]が使用される場合、ホームエージェントとの共有キーベースのセキュリティ関連が必要です。
o Parameter Set 2
o パラメーターセット2
In this case, some dependency exists between authentication for network access and authentication for mobility services in that a security association that is established as a result of authentication for network access is re-used for authentication for mobility services.
この場合、ネットワークアクセスの認証とモビリティサービスの認証との間に依存関係が存在します。これは、ネットワークアクセスの認証の結果として確立されたセキュリティ協会がモビリティサービスの認証のために再利用されるからです。
All required information, including IKE credentials, is bootstrapped from the following parameter:
IKE資格情報を含むすべての必要な情報は、次のパラメーターからブートストラップされています。
* Network access credentials(*)
* ネットワークアクセス資格情報（*）
(*) A pair of an NAI and a pre-shared secret is an example of a set of credentials. A pair of an NAI and a public key, which may be provided as a digital certificate, is another example of a set of credentials.
（*）NAIのペアと事前に共有された秘密は、資格情報のセットの例です。デジタル証明書として提供される可能性のあるNAIと公開鍵のペアは、資格情報のセットの別の例です。
There are two aspects of security for the Mobile IPv6 bootstrapping problem:
モバイルIPv6ブートストラップの問題には、セキュリティには2つの側面があります。
1. The security requirements imposed on the outcome of the bootstrapping process by RFC 3775 and other RFCs used by Mobile IPv6 for security.
1. RFC 3775およびモバイルIPv6がセキュリティに使用する他のRFCによるブートストラッププロセスの結果に課されるセキュリティ要件。
2. The security of the bootstrapping process itself, in the sense of threats to the bootstrapping process imposed by active or passive attackers.
2. アクティブまたはパッシブ攻撃者によって課されるブートストラッププロセスに対する脅威の意味で、ブートストラッププロセス自体のセキュリティ。
Note that the two are related; if the bootstrapping process is compromised, the level of security required by RFC 3775 may not be achieved.
2つは関連していることに注意してください。ブートストラッププロセスが損なわれている場合、RFC 3775が必要とするセキュリティのレベルは達成されない場合があります。
The following two sections discuss these issues.
次の2つのセクションでは、これらの問題について説明します。
The Mobile IPv6 specification in RFC 3775 requires the establishment of a collection of IPsec SAs between the home agent and mobile node to secure the signaling traffic for Mobile IP, and, optionally, also to secure data traffic. The security of an IPsec SA required by the relevant IPsec RFCs must be quite strong. Provisioning of keys and other cryptographic material during the establishment of the SA through bootstrapping must be done in a manner such that authenticity is proved and confidentiality is ensured. In addition, the generation of any keying material or other cryptographic material for the SA must be done in a way such that the probability of compromise after the SA is in place is minimized. The best way to minimize the probability of such a compromise is to have the cryptographic material only known or calculable by the two end nodes that share the SA -- in this case, the home agent and mobile node. If other parties are involved in establishing the SA (through key distribution, for example) the process should follow the constraints designed to provide equivalent security.
RFC 3775のモバイルIPv6仕様では、モバイルIPのシグナリングトラフィックを保護するために、ホームエージェントとモバイルノードの間にIPSEC SASのコレクションを確立する必要があります。関連するIPSEC RFCに必要なIPSEC SAのセキュリティは非常に強力でなければなりません。ブートストラップによるSAの確立中のキーやその他の暗号化資料のプロビジョニングは、信頼性が証明され、機密性が確保されるように、方法で行う必要があります。さらに、SAのキーイング材料またはその他の暗号化材料の生成は、SAが所定の位置にある後の妥協の可能性が最小限に抑えるように行う必要があります。このような妥協の確率を最小限に抑える最良の方法は、SAを共有する2つのエンドノード、この場合はホームエージェントとモバイルノードによってのみ既知または計算可能な暗号化材料を既知または計算できることです。他の当事者が（たとえば、重要な分布を通じて）SAの確立に関与している場合、プロセスは、同等のセキュリティを提供するように設計された制約に従う必要があります。
RFC 3775 also requires a trust relationship, as defined in Section 1.3, between the mobile node and its home agent(s). This is necessary, for instance, to ensure that fraudulent mobile nodes that attempt to flood other mobile nodes with traffic be not only shut off but tracked down. An infrastructureless relationship as defined in Section 1.3 does not satisfy this requirement. Any bootstrapping solution must include a trust relationship between mobile node and mobility service provider. Solutions that depend on an infrastructureless relationship are out of scope for bootstrapping.
RFC 3775には、モバイルノードとそのホームエージェントの間でセクション1.3で定義されているように、信頼関係が必要です。たとえば、これは、他のモバイルノードをトラフィックであふれさせようとする詐欺的なモバイルノードが遮断されるだけでなく、追跡されるようにするために必要です。セクション1.3で定義されているインフラストラクチャレス関係は、この要件を満たしていません。ブートストラップソリューションには、モバイルノードとモビリティサービスプロバイダーの間の信頼関係を含める必要があります。インフラストラクチャのない関係に依存するソリューションは、ブートストラップの範囲外です。
Another requirement is that a home address be authorized to one specific host at a time. RFC 3775 requires this so that misbehaving mobile nodes can be shut down. This implies that, in addition to the IPsec SA, the home agent must somehow authorize the mobile node for a home address. The authorization can be either implicit (for example, as a side effect of the authentication for mobility service) or explicit. The authorization can either be done at the time the SA is created or be dynamically managed through a first come, first served allocation policy.
別の要件は、自宅の住所が一度に1つの特定のホストに対して許可されることです。RFC 3775では、モバイルノードを誤動作するようにこれを必要とします。これは、IPSEC SAに加えて、ホームエージェントがホームアドレスのモバイルノードを何らかの形で承認する必要があることを意味します。承認は、暗黙的（たとえば、モビリティサービスの認証の副作用として）または明示的なものです。承認は、SAが作成されたときに実行するか、最初の提供された割り当てポリシーを通じて動的に管理することができます。
Various attacks are possible on the bootstrapping process itself. These attacks can compromise the process such that the RFC 3775 requirements for Mobile IP security are not met, or they can serve simply to disrupt the process such that bootstrapping cannot be completed. Here are some possible attacks:
ブートストラッププロセス自体では、さまざまな攻撃が可能です。これらの攻撃は、モバイルIPセキュリティのRFC 3775要件が満たされないようにプロセスを侵害するか、ブートストラップを完了できないようにプロセスを混乱させるためだけに役立つことができます。ここにいくつかの可能な攻撃があります：
o An attacking network entity purporting to offer the mobile node a legitimate home agent address or bootstrapping for the IPsec SAs may instead offer a bogus home agent address or configure bogus SAs that allow the home agent to steal the mobile node's traffic or otherwise disrupt the mobile node's mobility service.
o モバイルノードに正当なホームエージェントアドレスを提供することを目的とする攻撃ネットワークエンティティは、IPSEC SASの正当なホームエージェントアドレスまたはブートストラップを提供する場合があります。モビリティサービス。
o An attacking mobile node may attempt to steal mobility service by offering up fake credentials to a bootstrapping network entity or otherwise disrupting the home agent's ability to offer mobility service.
o 攻撃するモバイルノードは、ブートストラップネットワークエンティティに偽の資格情報を提供するか、モビリティサービスを提供するホームエージェントの能力を混乱させることにより、モビリティサービスを盗もうとする場合があります。
o A man in the middle on the link between the mobile node and the bootstrapping network entity could steal credentials or other sensitive information and use that to steal mobility service or deny it to the legitimate owner of the credentials. Refer to Section 7.15 in [RFC3748] and [AAA-EAP-LLA] for further information.
o モバイルノードとブートストラップネットワークエンティティの間のリンク上の真ん中の男性は、資格情報またはその他の機密情報を盗み、それを使用してモビリティサービスを盗んだり、資格情報の正当な所有者に拒否したりすることができます。詳細については、[RFC3748]および[AAA-eap-lla]のセクション7.15を参照してください。
o An attacker could arrange for a distributed denial-of-service attack on the bootstrapping entity, to disrupt legitimate users from bootstrapping.
o 攻撃者は、ブートストラップのエンティティに対する分散型サービス拒否攻撃を手配して、正当なユーザーをブートストラップから混乱させることができます。
In addition to these attacks, there are other considerations that are important in achieving a good security design. As mobility and network access authentication are separate services, keys generated for these services need to be cryptographically separate, to be separately named, and to have separate lifetimes. This needs to be achieved even though the keys are generated from the same authentication credentials. This is necessary because a mobile node must be able to move from one serving (or roaming) network access provider to another without needing to change its mobility access provider. Finally, basic cryptographic processes must provide for multiple algorithms in order to accommodate the widely varying deployment needs; the need for replacement of algorithms when attacks become possible must also be considered in the design.
これらの攻撃に加えて、優れたセキュリティデザインを達成する上で重要な他の考慮事項があります。モビリティとネットワークアクセス認証は個別のサービスであるため、これらのサービス用に生成されるキーは、暗号化された別々の名前を付けて、別々の寿命を持つ必要があります。キーが同じ認証資格情報から生成されている場合でも、これを達成する必要があります。これは、モバイルノードがモビリティアクセスプロバイダーを変更する必要なく、1つのサービング（またはローミング）ネットワークアクセスプロバイダーに移動できる必要があるためです。最後に、基本的な暗号化プロセスは、大きく異なる展開のニーズに対応するために、複数のアルゴリズムを提供する必要があります。攻撃が可能になったときにアルゴリズムを交換する必要性も、設計で考慮する必要があります。
This contribution is a joint effort of the problem statement design team of the Mobile IPv6 WG. The contributors include Basavaraj Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba, Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti, Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay Devarapalli, and Kuntal Chowdury.
この貢献は、モバイルIPv6 WGの問題ステートメント設計チームの共同の努力です。貢献者には、バサヴァラジ・パティル、ジェラルド・ジアレッタ、ジャリ・アークコ、ジェームズ・ケンプフ、ヨシヒロ・オバ、林川陽子、ヨウジュキ・オニシ、マユミヤナギヤ・サミタ・チャクラバルティ、ゴパル・ドメティ、ケント・レオン、ヴィジーニュ、ハニス、アル・チャウドリー。
The design team members can be reached at the following email addresses:
デザインチームのメンバーは、次のメールアドレスでアクセスできます。
Basavaraj Patil: basavaraj.patil@nokia.com
basavaraj patil：basavaraj.patil@nokia.com
Gerardo Giaretta: gerardo.giaretta@telecomitalia.it
Gerardo giaretta：gerardo.giaretta@telecomitalia.it
Jari Arkko: jari.arkko@kolumbus.fi
Jari Arkko：jari.arkko@kolumbus.fi
James Kempf: kempf@docomolabs-usa.com
James Kempf：kempf@docomolabs-usa.com
Yoshihiro Ohba: yohba@tari.toshiba.com
Yoshihiro Ohba：yohba@tari.toshiba.com
Ryuji Wakikawa: ryuji@sfc.wide.ad.jp
ワキカワRyuji：ryuji@sfc.wide.ad.jp
Hiroyuki Ohnishi: ohnishi.hiroyuki@lab.ntt.co.jp
Hiroyuki ohnishi：ohnishi.hiroyuki@lab.ntt.co.jp
Mayumi Yanagiya: yanagiya.mayumi@lab.ntt.co.jp
Yanagiya Mayumi：Yanagiya.mayumi@lab.ntt.co.jp
Samita Chakrabarti: Samita.Chakrabarti@eng.sun.com
Gopal Dommety: gdommety@cisco.com
Kent Leung: kleung@cisco.com
Kent Leung：kleung@cisco.com
Alper Yegin: alper.yegin@samsung.com
Alper Yegin：alper.yegin@samsung.com
Hannes Tschofenig: hannes.tschofenig@siemens.com
Hannes Tschofenig：hannes.tschofenig@siemens.com
Vijay Devarapalli: vijayd@iprg.nokia.com
vijay devarapalli：vijayd@iprg.nokia.com
Kuntal Chowdhury: kchowdhury@starentnetworks.com
Kuntal Chowdhury：kchowdhury@starentnetworks.com
Special thanks to James Kempf and Jari Arkko for writing the initial version of the bootstrapping statement. Thanks to John Loughney and T.J. Kniveton for their detailed reviews.
ブートストラップステートメントの初期バージョンを書いてくれたJames KempfとJari Arkkoに感謝します。ジョン・ラウニーとT.J.に感謝します。詳細なレビューについてはKniveton。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[AAA-EAP-LLA] Mariblanca, D., "EAP lower layer attributes for AAA protocols", Work in Progress, May 2004.
[AAA-EAP-LLA] Mariblanca、D。、「AAAプロトコルのEAP下層属性属性」、2004年5月、進行中の作業。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794] Calhoun、P。およびC. Perkins、「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年3月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] MANER、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[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月。
[RFC3776] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.
[RFC3776] Galvin、J。、「IABおよびIESGの選択、確認、およびリコールプロセス：指名およびリコール委員会の運用」、BCP 10、RFC 3777、2004年6月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6（MIPV6）のモバイルノード識別子オプション」、RFC 4283、2005年11月。
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[RFC4285] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6の認証プロトコル」、RFC 4285、2006年1月。
Authors' Addresses
著者のアドレス
Alpesh Patel Cisco 170 W. Tasman Drive San Jose, CA 95134 USA
Alpesh Patel Cisco 170 W. Tasman Drive San Jose、CA 95134 USA
Phone: +1 408 853 9580
EMail: alpesh@cisco.com
Gerardo Giaretta Telecom Italia via Reiss Romoli 274 Torino 10148 Italy
ジェラルド・ジアレッタ・テレコム・イタリア・ライス・ロモリ274トリノ10148イタリア
Phone: +39 011 228 6904
EMail: gerardo.giaretta@telecomitalia.it
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。