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)
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).
著作権（C）インターネット協会（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）は、ホームエージェントと呼ばれるエンティティとの信頼関係を持っているという仮定に基づいてモビリティサポートを指定します。ホーム・エージェント・アドレスは、（例えば、手動で設定を介して、エニーキャストのディスカバリメカニズム、または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がホームエージェントで正常に登録することを可能にするのに十分な情報をプロビジョニングすることが暗黙の要件があります。しかし、静的にプロビジョニングされたこの情報は実用的な展開の問題を作成しました。
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]は、移動ノードは、静的ホームアドレス（エニーキャストアドレスから導出することができる）ホーム・エージェント・アドレス、及びホームエージェント（または複数のホームエージェント）とのセキュリティアソシエーションを有することを期待します。
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
モバイルインターネットプロトコルバージョン6（MIPv6の）を考慮に加入者とサービスプロバイダとの間の関係を取って、展開されたサンプルの展開シナリオを識別するために、Oであり;そして
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のブートストラップの後、その後のブートストラップの必要性は実装依存です。例えば、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.
この文書の文脈では、信頼関係は、問題の二者、モバイルホストおよびモビリティまたはアクセスサービスの承認者の、典型的には、ユーザが、モバイルノードが資格情報を使用してプロビジョニングされた前の接触のいくつかの並べ替えを持っていることを意味します。これらの資格情報は、モバイルノードがモビリティまたはアクセスサービスプロバイダに対して自らを認証するために、サービスを取得するための許可を証明することができます。
Infrastructureless relationship
Infrastructureless関係
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.
この文書の文脈では、infrastructureless関係は、モバイルノードと移動性やアクセス、サービスプロバイダのユーザーは以前の接点を持っていないし、モバイルノードが認証し、サービスの許可を証明するために資格情報を提供するために必要とされていないものです。モビリティおよび/またはネットワークアクセスサービスは、任意の認証や承認なしで提供されています。この文脈でInfrastructurelessは、アドホックネットワークのための場合のように、そのようないかなるネットワークインフラストラクチャが存在しないことを意味するものではありません。
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.
モビリティやアクセスネットワークサービスの承認者に自分自身を認証するために、サービスを受けるために許可を証明するために、モバイルノードによって使用されるデータ。ユーザー名/パスワード、ワンタイムパスワードカード、証明書と公開鍵/秘密鍵のペア、および生体情報は、いくつかの例です。
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:
信頼関係を検証する一つの典型的な方法は、認証、許可、アカウンティング（AAA）インフラストラクチャを使用しています。この文書では、AAAの二つの異なる用途が考えられています。
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.
これらの機能は、第7節に記載したように第6または展開シナリオで説明したサービスモデルに応じて、単一のエンティティまたは異なるエンティティ内に実装されてもよいです。
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）などのいくつかの識別子が、ASPとMSPに自分自身を識別するために、MNを可能に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以下の情報は、HAに登録するMNを可能にするために、ブートストラップの終わりに利用可能でなければなりません。
* 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）MNとHAの間で、インターネットを完備鍵交換プロトコル（IKE）事前共有秘密
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を使用しています。その結果、静的なホームアドレスの割り当ては、実際のベース仕様と互換性のある唯一のホームアドレスの設定手法です。
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（Dynamic Host Configuration Protocol）は、アドレスの割り当てをベース。一部のプロバイダは、ホームアドレスを設定するには、ホームネットワークからの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.
重複アドレスの衝突からの回復。そのホームアドレスを変更するモバイルノードのいずれかにより、ホームネットワーク上のアドレスの衝突から回復する必要があるかもしれません。
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の展開を簡素化するためには、ホームアドレスを割り当て、セキュリティポリシーデータベースでそれらを指定する作業から解放ユーザーと管理者に望ましいです。これは、可能な限り自動設定を使用しての一般的な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]のプレフィックス情報のその発見に基づいてホームアドレスを自動設定するために、モバイルノードのためのサポートが含まれています。ネットワークリナンバリングの場合の自動設定は、新たなネットワークプレフィックスと、既存のネットワークプレフィックスを交換することによって行われます。
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は、周りの古い接頭辞を維持する必要がありますとで説明したように、モバイルノードは、新しいホームエージェントを要求することにより、古いサブネット、上の古いホームエージェントエニーキャストアドレスに任意のクエリを処理しますセクション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は、自分自身を設定することができます。
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.
移動ノードがネットワーク・アクセス・サービスがそのホームASPにより提供されたMNの現在位置の通信のために直接使用できない場合は、モバイルノードがローミングしています。この場合、ホームASPは、アクセス・サービス・承認者として動作するが、実際のネットワークアクセスがサービングネットワークアクセスプロバイダによって提供されます。前インターネットアクセスを有するモバイルノードに認証および許可の間、サービング・ネットワーク・アクセス・プロバイダは、単にバックアクセス・サービス・オーソライザの認証および認可のためのルーティング剤として作用することができる、又はそれは追加の認証と認可ステップ自体を必要とし得ます。事業者が空港でホットスポットサービスを使用しており、ホットスポットサービスプロバイダが事業者の携帯電話プロバイダとのローミング契約を締結しているとき、ローミング状況の例があります。その場合には、ホットスポットネットワークは、サービングネットワークアクセスプロバイダとして動作している、とセルラーネットワークは、アクセス・サービス・承認者として機能しています。事業者が携帯電話ネットワークへのホットスポットネットワークから移動した場合、携帯電話ネットワークは、ホームアクセスサービスプロバイダとアクセスサービスの承認者でもあります。
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家ASPおよびホーム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.
同様に、家庭用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は、MSAとサブスクリプションを持っている、また、モバイルIPv6サービスのために、家庭用MSPと呼ばれます。第6節で述べたように、MSPはモバイルIPv6のホームリンクとして動作するサブネット上にホームエージェントを設定する責任があります。その結果、家庭用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がホームプロバイダと事前に確立された信頼関係を持っていると想定されているので、それがアイデンティティと資格情報を使用して設定する必要があります。例えば、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と異なる場合がありASPが管理するネットワークから、そのホームMSPとMIPv6の操作をブートストラップすることができるはず、それはないかもしれませんそれに任意の事前に確立された信頼関係を持っています。
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
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.
サードパーティのモビリティ・サービス・プロバイダのシナリオでは、モビリティサービスのサブスクリプションは、（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でDHCPを介して取得することができるサービス提供ASP、。
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認証情報は、モバイルノードと他のエンティティとの間で使用される資格情報を含みます。 AAAプロトコルはIKEの手順の間、ホームエージェントと他のエンティティとの間の通信のために使用される場合には、モバイル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 SAのコレクションの確立を必要とします。関連の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.
モバイルノードとそのホームエージェント（複数可）の間で、セクション1.3で定義されたRFC 3775にも、信頼関係が必要です。これは、トラフィックを他のモバイルノードをあふれさせる試み詐欺モバイルノードが遮断が、ダウン追跡されていないだけということを保証するために、例えば、必要です。セクション1.3で定義されているようinfrastructureless関係は、この要件を満たしていません。任意のブートストラップ・ソリューションは、モバイルノードとモビリティ・サービス・プロバイダー間の信頼関係を含める必要があります。 infrastructureless関係に依存ソリューションは、ブートストラップの範囲外です。
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.
別の要件は、ホームアドレスは、一度に一つの特定のホストに許可されることです。モバイルノードの動作不良がシャットダウンすることができるように、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のSAの正当なホームエージェントアドレスまたはブートストラップを提供することを主張する攻撃ネットワークエンティティは、代わりに偽のホーム・エージェント・アドレスを提供したり、ホームエージェントがモバイルを混乱させるそうでない場合は、モバイルノードのトラフィックを盗んだりすることができます偽のSAを設定することもノードのモビリティサービス。
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]セクション7.15および詳細については、[AAA-EAP-LLA]を参照。
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.
これらの攻撃に加えて、優れたセキュリティ設計を実現する上で重要である他の考慮事項があります。モビリティとネットワークアクセス認証が別々のサービスであるため、キーはこれらのサービスは、暗号個別に命名されるように、分離し、独立した寿命を持つようにする必要がために生成しました。これは、キーが同じ認証資格情報から生成されていても達成する必要があります。モバイルノードがモビリティ・アクセス・プロバイダを変更することなく、別のサービング（またはローミング）ネットワークアクセスプロバイダから移動することができなければならないので、これが必要です。最後に、基本的な暗号化のプロセスは、広く様々な展開のニーズに対応するために複数のアルゴリズムを提供しなければなりません。アルゴリズムの交換の必要性攻撃が可能になり、設計で考慮しなければなりません。
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の問題文設計チームの共同の努力です。貢献者はBasavarajパティル、ヘラルド・Giaretta、ヤリArkko、ジェームズ・ケンプ、義弘大場竜二Wakikawa、博之大西真由美柳屋Samita Chakrabarti、ゴパルDommety、ケントレオン、アルパースYegin、ハンネスTschofenig、ビジェイDevarapalli、およびKuntal Chowduryが含まれます。
The design team members can be reached at the following email addresses:
設計チームのメンバーは以下のメールアドレスに到達することができます。
Basavaraj Patil: basavaraj.patil@nokia.com
Bsvrajパティル：बसवराज.पाटिल@नोकिआ.कॉम
Gerardo Giaretta: gerardo.giaretta@telecomitalia.it
ヘラルドGiaretta：gerardo.giaretta@telecomitalia.it
Jari Arkko: jari.arkko@kolumbus.fi
ヤリArkko：jari.arkko@kolumbus.fi
James Kempf: kempf@docomolabs-usa.com
ジェームズ・ケンプ：kempf@docomolabs-usa.com
Yoshihiro Ohba: yohba@tari.toshiba.com
義弘大場：yohba@tari.toshiba.com
Ryuji Wakikawa: ryuji@sfc.wide.ad.jp
りゅじ わきかわ： りゅじ＠ｓｆｃ。うぃで。あｄ。ｊｐ
Hiroyuki Ohnishi: ohnishi.hiroyuki@lab.ntt.co.jp
博之大西：ohnishi.hiroyuki@lab.ntt.co.jp
Mayumi Yanagiya: yanagiya.mayumi@lab.ntt.co.jp
まゆみ やなぎや： やなぎや。まゆみ＠ぁｂ。んっｔ。こ。ｊｐ
Samita Chakrabarti: Samita.Chakrabarti@eng.sun.com
サミットChakrabarti：Samita.Chakrabarti@eng.sun.com
Gopal Dommety: gdommety@cisco.com
ゴパルDommety：gdommety@cisco.com
Kent Leung: kleung@cisco.com
ケントレオン：kleung@cisco.com
Alper Yegin: alper.yegin@samsung.com
ティラーのアルパース：alper.yegin@samsung.co
Hannes Tschofenig: hannes.tschofenig@siemens.com
ハンネスTschofenig：hannes.tschofenig@siemens.com
Vijay Devarapalli: vijayd@iprg.nokia.com
ビジェイのdevarapalli：విజయ్డ్@ఇప్ర్గ్.నోకియా.కం
Kuntal Chowdhury: kchowdhury@starentnetworks.com
Kuntalチョードリ：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.
ブートストラップ文の最初のバージョンを記述するためのジェームズ・ケンプとヤリArkkoに感謝します。ジョンLoughneyと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.、ブルンク、L.、Vollbrecht、J.、カールソン、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.は、進捗状況、2004年5月で、作業 "EAP下位層は、AAAプロトコル属性"。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794]カルフーン、P.とC.パーキンス、 "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におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[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]ガルビン、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]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイル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]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6のための認証プロトコル"、RFC 4285、2006年1月。
Authors' Addresses
著者のアドレス
Alpesh Patel Cisco 170 W. Tasman Drive San Jose, CA 95134 USA
Alpeshパテルシスコ170 W.タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 408 853 9580 EMail: alpesh@cisco.com
電話：+1 408 853 9580 Eメール：alpesh@cisco.com
Gerardo Giaretta Telecom Italia via Reiss Romoli 274 Torino 10148 Italy
ライスRomoli 274トリノ10148イタリア経由ヘラルドGiarettaテレコムイタリア
Phone: +39 011 228 6904 EMail: gerardo.giaretta@telecomitalia.it
電話：+39 011 228 6904 Eメール：gerardo.giaretta@telecomitalia.it
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。