RFC4640 日本語訳
4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6). A.Patel, Ed., G. Giaretta, Ed.. September 2006. (Format: TXT=49926 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Patel, Ed.
Request for Comments: 4640 Cisco
Category: Informational G. Giaretta, Ed.
Telecom Italia
September 2006
ワーキンググループのA.パテル、エドをネットワークでつないでください。コメントのために以下を要求してください。 4640年のコクチマスカテゴリ: エド情報のG.Giaretta、テレコムイタリア2006年9月
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)インターネット協会(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
1. 序論…2 1.1. 問題の概要…3 1.2. 独力で進みます…3 1.3. 用語…4 2. 仮定…5 3. 目標を設計してください…6 4. 非目標…7 5. ブートストラップ法に関する動機…7 5.1. 扱います。7 5.1.1. ダイナミックなホームアドレス課題…7 5.1.2. ダイナミックなホームエージェント課題…9 5.1.3. 「便宜主義的である」か「地方」の発見…9 5.1.4. 管理要件…9 5.2. セキュリティインフラストラクチャ…10 5.2.1. AAAインフラストラクチャとの統合…10 5.3. トポロジー変化…10
Patel & Giaretta Informational [Page 1] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[1ページ]のRFC4640PS
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
5.3.1. 休止状態のモードモバイルノード…10 6. 社会参加サービスをネットワークでつないでください…11 7. 展開シナリオ…13 7.1. 移動性サービス購読シナリオ…13 7.2. 統合ASPネットワークシナリオ…14 7.3. 第三者MSPシナリオ…14 7.4. インフラストラクチャなしのシナリオ…15 8. 認証のためのパラメタ…15 9. セキュリティ問題…17 9.1. モバイルIPv6のセキュリティ要件…17 9.2. ブートストラップ法への脅威は処理されます…18 10. 貢献者…19 11. 承認…20 12. 有益な参照…20
1. Introduction
1. 序論
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]はモバイルノード(ミネソタ)にはホームのエージェントと呼ばれる実体との信頼関係があるという仮定に基づく移動性サポートを指定します。 いったんホームエージェントアドレスについて学習すると(例えば手動の構成、anycast発見メカニズム、またはDNSルックアップで)、IPsecか認証プロトコルでモバイルノードとホームのエージェントの間のモバイルIPv6シグナリングメッセージを保証します、[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]に、ミネソタが首尾よくホームのエージェントとともに記名することを許可する十分な情報で食糧を供給されるという暗黙の要件があります。 しかしながら、この情報に静的に食糧を供給させると、実用的な展開問題は作成されます。
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.
ブートストラップ法のための要件は、様々なシナリオ/ネットワークが展開問題であると考えるかもしれません。 それはある最小量のパラメタ(種子情報)がブートストラップ法で支援するモバイルノードに利用可能であるというこのドキュメントの基本仮定です。 展開シナリオによって、利用可能な正確な種子情報は異なります。 このドキュメントは、様々な展開シナリオについて説明して、1セットの利用可能な最小量のパラメタをそれぞれの展開シナリオに提供します。
Patel & Giaretta Informational [Page 2] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[2ページ]のRFC4640PS
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.
このドキュメントは、モバイルノードがどう情報を得るはずであるように都合のよいソリューションを示すまでには至りません。 そのような詳細は別々のドキュメントから利用可能になるでしょう。
1.1. Overview of the Problem
1.1. 問題の概要
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 モバイルノードがアドレスとセキュリティー証明書を得るのにホームのエージェントとともに記名するのにモバイルNodeとネットワークで必要である情報の極小集合を特定するために。
1.2. Bootstrapping
1.2. 独力で進みます。
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.).
また、あるシナリオでは、ミネソタが初めて(創造的に)独力で進んだ後にその後のブートストラップ法の必要性も実装に依存しています。 例えば、ミネソタは、それがブートする毎回を独力で進むか、毎回接頭語変化の上を独力で進むか、または最適のHAに投錨するために定期的に独力で進むかもしれません(距離、負荷などに基づいています)。
Patel & Giaretta Informational [Page 3] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[3ページ]のRFC4640PS
1.3. Terminology
1.3. 用語
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回のパーティー(通常モバイルホストと移動性のユーザかアクセス・サービスauthorizer)にはある種の先の接触がモバイルノードが資格証明書で食糧を供給されたあることを意味します。 これらの資格証明書で、モバイルノードを移動性かアクセスサービスプロバイダーにそれ自体を認証して、承認がサービスを得ると立証します。
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.
モバイルノードによって使用される、移動性かアクセスネットワークサービスauthorizerにそれ自体を認証して、承認がサービスを受けると立証するデータ。 ユーザ名前/パスワード、使い捨てパスワードカード、証明書、およびバイオメトリックな情報がある公衆/秘密鍵組はいくつかの例です。
ASA
アサ
Access Service Authorizer. A network operator that authenticates
a mobile node and establishes the mobile node's authorization to
receive Internet service.
サービスAuthorizerにアクセスしてください。 モバイルノードを認証して、インターネットのサービスを受けるためにモバイルノードの承認を確立するネットワーク・オペレータ。
ASP
ASP
Access Service Provider. A network operator that provides direct
IP packet forwarding to and from the end host.
サービスプロバイダーにアクセスしてください。 ホストと終わりのホストからダイレクトIPパケット推進を提供するネットワーク・オペレータ。
Patel & Giaretta Informational [Page 4] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[4ページ]のRFC4640PS
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.
ASAではなく、モバイルノードのASPであるネットワーク・オペレータ。 給仕ネットワークアクセスプロバイダはさらに、移動性サービスを提供するかもしれません。
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の両方であるネットワーク・オペレータ。 ホームネットワークアクセスプロバイダはさらに、移動性サービスを提供するかもしれません(これがRFC3775のそれからのわずかに異なった定義であることに注意してください)。
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.
移動性サービスAuthorizer。 モバイル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は、それを認可するために別のサービスプロバイダーに頼っています。
2. Assumptions
2. 仮定
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を通して間接的である場合があります。 ミネソタを独力で進むのにこの信頼関係を使用できます。
Patel & Giaretta Informational [Page 5] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[5ページ]のRFC4640PS
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]で定義されるNetwork Access Identifierなどの何らかの識別子(NAI)がミネソタがASPとMSPにそれ自体を特定することを許可するミネソタで食糧を供給されます。
3. Design Goals
3. デザイン目標
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's home agent address
* ミネソタのホームエージェントアドレス
* MN's home address
* ミネソタのホームアドレス
* IPsec Security Association (SA) between MN and HA, Intenet Key
Exchange Protocol (IKE) pre-shared secret between MN and HA
* ミネソタとHAの間のIPsec Security Association(SA)、ミネソタとHAの間のIntenet Key Exchangeプロトコル(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 ミネソタかネットワークがいつでも、ブートストラップ法手順を引き起こすことができます。 例えば、ブートストラップ法は管理動作、聞き古したであるなる情報、またはミネソタを示すHAのため起こることができます。 ミネソタがHAに登録されて、すべての必要な資格証明書を持っていると、ブートストラップ法は着手されるかもしれません。 資格証明書をリフレッシュするか、またはこれはたまたま通常更新するかもしれません。
Patel & Giaretta Informational [Page 6] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[6ページ]のRFC4640PS
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 ブートストラップ法の間に使用されたインフラストラクチャにかかわらないで、ミネソタとHA自身の間でその後のプロトコル相互作用(例えば、IPsec SAをアップデートする)を実行できます。
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 ソリューションは関連認証/承認モデルと共に考えることができるすべての可能な展開シナリオに適切であるべきです。
4. Non-goals
4. 非目標
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 ホーム接頭語の番号を付け替えることはブートストラップ法の一部として明らかにサポートされません。 ミネソタが実行する、電源を入れて(前であるのからの州の情報をキャッシュすることと対照的に、プロセスを独力で進んでください)、次に、ホームネットワークの番号を付け替えることが自動的に世話をされるときはいつも、手順を独力で進んでください。
o Bootstrapping in the absence of a trust relationship between MN
and any provider is not considered.
o ミネソタとどんなプロバイダーとの信頼関係がないとき独力で進むのは考えられません。
5. Motivation for bootstrapping
5. ブートストラップ法に関する動機
5.1. Addressing
5.1. アドレシング
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.
このセクションで、私たちはホームアドレスとホームエージェントアドレスとの現在きつい結合で引き起こされた問題について議論します。
5.1.1. Dynamic Home Address Assignment
5.1.1. ダイナミックなホームアドレス課題
Currently, the home agent uses the mobile node's home address for authorization. When manual keying is used, this happens through the
現在、ホームのエージェントは承認にモバイルノードのホームアドレスを使用します。 手動の合わせるのが使用されている、これはいつまで起こるか。
Patel & Giaretta Informational [Page 7] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[7ページ]のRFC4640PS
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 Phase1のアイデンティティが与えられたホームアドレスのためにセキュリティ協会を要求するのが認可されるのを保証します。 モバイル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.
Dynamic Host Configuration Protocolの(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の展開を簡素化するために、安全保障政策データベースでホームアドレスを割り当てて、それらを指定するタスクからユーザと管理者を解放するのは望ましいです。 これはどこでも、可能であるところで自動構成を使用するという一般的な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].
次に、ミネソタは、新たに構成されたホームAddressを登録するためにHAで付く移動性をアップデートする必要があります。 しかしながら、ホームAddressを再構成した関連するセキュリティ協会がミネソタとHAに存在しないなら、ミネソタは新たに構成されたアドレスをHAに登録できないかもしれません。 この状況は現在のMIPv6仕様[RFC3775]で扱われません。
Patel & Giaretta Informational [Page 8] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[8ページ]のRFC4640PS
5.1.2. Dynamic Home Agent Assignment
5.1.2. ダイナミックなホームエージェント課題
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は、異なったリンクに見つけられたホームのエージェントの中でバランスユーザを積み込むためにダイナミックなホームエージェント割当機構が欲しいかもしれません。
5.1.3. "Opportunistic" or "Local" Discovery
5.1.3. 「便宜主義的である」か「地方」の発見
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は通常使用されます。
5.1.4. Management Requirements
5.1.4. 管理要件
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
より早く説明されるように、新しいアドレスは構成された安全保障政策データベースと承認テーブルを無効にします。 使用される特定のプロトコルにかかわらず、安全保障政策エントリーか手動の構成をアップデートするオートマティック・システムの必要があります。 そしてこれらの要件が両方のホームのエージェントに適用される。
Patel & Giaretta Informational [Page 9] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[9ページ]のRFC4640PS
mobile nodes, but it cannot be expected that mobile node users are capable of performing the required tasks.
しかし、モバイルノード、そんなにモバイルで予想されて、ノードユーザが必要なタスクを実行できるということであるはずがありません。
5.2. Security Infrastructure
5.2. セキュリティインフラストラクチャ
5.2.1. Integration with AAA Infrastructure
5.2.1. AAAインフラストラクチャとの統合
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がこの特徴を提供することに注意する価値があります。
5.3. Topology Change
5.3. トポロジー変化
5.3.1. Dormant Mode Mobile Nodes
5.3.1. 休止状態のモードモバイルノード
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
モバイルノードがアクティブであるという暗黙の仮定を持って、IPトラフィックを取りながら[RFC3775]のセクション10.6のモバイルノードに接頭語情報を押すプロトコルの記述。 事実上、多く、そうでなければ、モバイル機器が電池残量を節約するために安値で「眠っているモード」を動かすことである、または最も消されさえするので、それらは接頭語情報のどんな伝播も逃すでしょう。 実際問題として、このプロトコルが使用されていると、MSPは古いサブネットに関する懐かしい生家エージェントanycastアドレスに古い接頭語を置いて、どんな質問も扱う必要があるでしょう、すべてのモバイルノードは原因にならされるまで。モバイルノードはセクション11.4で説明されるようにサブネットで新しいホームのエージェントを求めます。 その時でさえ、何らかのモバイル以来、ノードはオフになられそうです。
Patel & Giaretta Informational [Page 10] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[10ページ]のRFC4640PS
long periods, some owners would need to be contacted by other means, reducing the utility of the protocol.
長い期間に、プロトコルに関するユーティリティを減らして、何人かの所有者が、他の手段で連絡される必要があるでしょう。
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.
ミネソタが眠っているモードであるとき、ブートストラップ法は明らかにホームネットワークの番号を付け替えることのこの問題を解決しようとしません。 ブートストラップ法プロセスを再開始することによって'来返した'後にミネソタがそれ自体を構成できるなら、ネットワーク番号を付け替える問題は副作用として修正されています。
6. Network Access and Mobility Services
6. ネットワーク社会参加サービス
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は企業網のIT部の商業ASPであるかもしれませんかホームの維持装置が(住宅)のネットワークです。
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によって提供されるミネソタの現在の位置のコミュニケーションには、モバイルノードが直接使用可能でないなら、モバイルノードは移動しています。 この場合、ホームASPはアクセス・サービスauthorizerとして機能しますが、給仕ネットワークアクセスプロバイダは実際のネットワークアクセスを提供します。 インターネット・アクセスを持っているモバイルノードの前の認証と承認の間、給仕ネットワークアクセスプロバイダが認証と承認後部へのルーティングエージェントとして単にアクセス・サービスauthorizerに務めるかもしれませんか、またはそれは追加認証と承認ステップ自体を必要とするかもしれません。 ローミング状況に関する例はビジネス人が空港でホットスポットサービスを利用している時です、そして、ホットスポットサービスプロバイダーには、ビジネス人のセルプロバイダーとのローミング協定があります。 その場合、ホットスポットネットワークは給仕ネットワークアクセスプロバイダとして機能しています、そして、セルラー・ネットワークはアクセス・サービスauthorizerとして機能しています。 ビジネス人がホットスポットネットワークからセルラー・ネットワークまで移行すると、セルラー・ネットワークはホームアクセスサービスプロバイダーとアクセス・サービスauthorizerの両方です。
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
概念的とことによるとネットワークアクセス・サービスから別々の習慣にはモバイルIPv6を使用する移動性サービスがあります、移動性を提供する前に、ネットワークアクセスがもちろん必要ですが。 モバイルIPv6
Patel & Giaretta Informational [Page 11] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[11ページ]のRFC4640PS
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サービスを提供するネットワーク・オペレータは移動性サービスプロバイダー(MSP)と呼ばれます。 モバイルIPv6サービスを承諾するのは、ホストがサービスのために承認を認証して、立証するのを必要とします。 モバイルノードを認証して、移動性サービスを認可するネットワーク・オペレータは移動性サービスauthorizer(MSA)と呼ばれます。 操作の両方のタイプが同じオペレータによって実行されるなら、そのオペレータはホーム移動性サービスプロバイダーと呼ばれます。 認証と承認が1人のオペレータによって提供されて、就航が別のものによって提供されるなら、サービスを提供するオペレータは給仕移動性サービスプロバイダーと呼ばれます。 給仕MSPは、移動性サービスを承諾する前にモバイルノードの承認をチェックするためにモバイルノードの移動性サービスauthorizerに連絡しなければなりません。
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とMSPsのある他の可能な組み合わせがあります:
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も同じであるかもしれません。
Patel & Giaretta Informational [Page 12] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[12ページ]のRFC4640PS
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ブートストラップ法問題を解決するために展開見解から合理的なこれらの実体とすべての組み合わせを考慮に入れなければなりません。 彼らはホームエージェント発見、ホームアドレス構成、およびノードからホームへのエージェント認証モバイル局面に影響を与えます。
7. Deployment Scenarios
7. 展開シナリオ
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で、より詳しく説明されます。
7.1. Mobility Service Subscription Scenario
7.1. 移動性サービス購読シナリオ
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.
多くの商業展開がモバイルノードにはサービスプロバイダーとの購読があるという仮定に基づいています。 このシナリオでは、ミネソタはモバイルIPv6サービスのためにまた、ホームMSPと呼ばれるMSAとの購読を持っています。 セクション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.
ミネソタにはホームプロバイダーとのプレ確立した信頼関係があると思われて、アイデンティティと資格証明書でそれを構成しなければなりません。 例えば、バンドのあるアウトによる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.
遍在しているサービスを保証するために、ミネソタはMSPと異なるかもしれなくて、それと共に少しのプレ確立した信頼関係も持っていないASPによって経営されたオープンネットワークかネットワークなどのどんな可能なアクセス位置からもホームMSPとのMIPv6操作を独力で進むことができるべきです。
Patel & Giaretta Informational [Page 13] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[13ページ]のRFC4640PS
7.2. Integrated ASP Network Scenario
7.2. 統合ASPネットワークシナリオ
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は同じ実体です。 ミネソタには、ネットワークへのアクセスのためのセキュリティー証明書があります、そして、また、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| |
| +------+ +-------+ |
+----------------------------+
+----------------------------+ | IASP(アサ+MSA)| +----+ +-----+ +----+ | | ミネソタ|--- | NAS| | ハ| | +----+ +-----+ +----+ | | \ \ | | \ +------+ \ +-------+ | | -|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-MIPのためのAAA: モバイルIPサービスのためのAAA
Figure 1. Integrated ASP network
図1。 統合ASPネットワーク
7.3. Third-Party MSP Scenario
7.3. 第三者MSPシナリオ
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がそう、a法人、)、さらに別の実体(このサービス、給仕MSPを専攻するオペレータなどの)で実際の移動性サービスだけを提供します。 これらの2つの実体には、信頼関係があります。 モバイルノードの中の遷移的な信頼とこれらの2つの実体が、彼らが信頼できる同輩に対応していることを関係者に知らせるのに使用されるかもしれません。
This arrangement is similar to the visited - home operator roaming arrangement for network access.
ホームのオペレータがネットワークアクセサリーのためのアレンジメントを歩き回って、このアレンジメントは訪問と同様です。
Patel & Giaretta Informational [Page 14] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[14ページ]のRFC4640PS
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| |
| +------+ | | | | +-------+ |
+------------ + +--------+ +-------------------+
+--------------+ +--------+ | | |役立ちます。| | ASP| | MSP| +----+ +-----+ | | +----+ | | ミネソタ|--- | NAS| | | | ハ| | +-------------------+ +----+ +-----+ |===| +----+ | | MSA| | \ | | \ || (例えば、法人のNW)| | \ +------+ | | \ | +-------+ | | -|AAA Na| | | -------|AAA-MIP| | | +------+ | | | | +-------+ | +------------ + +--------+ +-------------------+
Figure 2. Third-Party MSP network
図2。 第3パーティMSPネットワーク
7.4. Infrastructure-less Scenario
7.4. インフラストラクチャなしのシナリオ
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)、およびホームLocation Register(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ネットワークです。 このネットワーク(すなわち、MIPv6 HA)で利用可能なMIP6サービスがあるかもしれないのは、可能です。 しかしながら、本当でなく、ネットワークにはユーザがミーティングに出席して、どんな実体でもそうしたどんなAAAインフラストラクチャかさらに言えば、どんな信頼関係もあります。
This specific scenario is not supported in this document. The reason for this is described in Section 9.
この特定のシナリオは本書ではサポートされません。 この理由はセクション9で説明されます。
8. Parameters for Authentication
8. 認証のためのパラメタ
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.
↓これはブートストラップ法手順に種子として使用されるパラメタのリストです。 移動性サービスのためにネットワークアクセスのための認証が認証から独立しているかどうかによって、パラメタは異なります。 異なったクライアントのアイデンティティがネットワーク社会参加サービスに使用されるなら、ネットワークアクセスのための認証は移動性サービスのための認証から独立しています。
Patel & Giaretta Informational [Page 15] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[15ページ]のRFC4640PS
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
* ホームのエージェントのドメイン名かFully Qualified Domain Name(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のDynamicホームエージェントAddressディスカバリーはホームエージェントアドレスを発見するのに使用されるかもしれません、そして、上記のパラメタは使用されないかもしれません。
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資格証明書を持っていない場合では、別の実体(例えば、AAAサーバ)でホームのエージェントは、IKEで互いの認証を実行するために交信するかもしれません。 このような場合には、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.
ネットワークアクセスのための認証の結果、設立されるセキュリティ協会が移動性サービスのための認証に再使用されるので、この場合、何らかの依存がネットワークアクセスのための認証と移動性サービスのための認証の間に存在します。
Patel & Giaretta Informational [Page 16] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[16ページ]のRFC4640PS
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の1組とプレ共有秘密キーは1セットの資格証明書に関する例です。 NAIと公開鍵の1組は1セットの資格証明書に関する別の例です。(公開鍵はデジタル証明書として提供されるかもしれません)。
9. Security Considerations
9. セキュリティ問題
There are two aspects of security for the Mobile IPv6 bootstrapping problem:
セキュリティの2つの局面がモバイルIPv6ブートストラップ法問題によってあります:
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. ブートストラップ法の結果に課されたセキュリティ要件はセキュリティにモバイルIPv6によって使用されたRFC3775と他のRFCsによって処理されます。
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が関係づけられることに注意してください。 ブートストラップ法プロセスが感染されるなら、RFC3775によって必要とされたセキュリティのレベルは達成されないかもしれません。
The following two sections discuss these issues.
以下の2つのセクションがこれらの問題について論じます。
9.1. Security Requirements of Mobile IPv6
9.1. モバイルIPv6のセキュリティ要件
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.
RFC3775のモバイルIPv6仕様は、そして、モバイルIPのために任意にシグナリングトラフィックを保証して、また、データがトラフィックであることを保証するためにホームのエージェントとモバイルノードの間のIPsec SAsの収集を設立に要求します。 関連IPsec RFCsによって必要とされたIPsec SAのセキュリティはかなり強くなければなりません。 信憑性が立証されて、秘密性が確実にされるように、方法でブートストラップ法によるSAの設立の間のキーと他の暗号の材料の食糧を供給することをしなければなりません。 さらに、SAが適所にあった後に感染の確率が最小にされるように、方法でSAのための物質的であるか他の暗号の材料を合わせるいずれの世代をしなければなりません。 そのような感染の確率を最小にする最も良い方法はこの場合SAを共有する2つのエンドノードで知られているだけであるか、計算できる暗号の材料、ホームのエージェント、およびモバイルノードを持つことです。 相手がSA(例えば主要な分配で)を設立するのにかかわるなら、プロセスは同等なセキュリティを提供するように設計された規制に続くはずです。
Patel & Giaretta Informational [Page 17] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[17ページ]のRFC4640PS
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.
また、RFC3775はモバイルノードとそのホームのエージェントの間でセクション1.3で定義されるように信頼関係を必要とします。 例えば、これが、トラフィックで他のモバイルノードをあふれさせるのを試みる詐欺的なモバイルノードが止められるだけではありませんが、捜し出されるのを保証するのに必要です。 セクション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.
別の要件はホームアドレスが一度に1人の特定のホストに認可されるということです。 RFC3775は、ふらちな事することのモバイルノードを止めることができるようにこれを必要とします。 これは、ホームのエージェントがどうにかIPsec SAに加えてホームアドレスのためのモバイルノードを認可しなければならないのを含意します。 承認は、暗黙である(例えば移動性サービスのための認証の副作用として)、または明白である場合があります。 承認にSAを作成するときするか、または先着順の配分方針でダイナミックに対処できます。
9.2. Threats to the Bootstrapping Process
9.2. ブートストラップ法プロセスへの脅威
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セキュリティのための3775年のRFC必要条件が満たされないか、またはそれらは、ブートストラップ法が完成できないように単にプロセスを混乱させるのに役立つことができます。 ここに、いくつかの可能な攻撃があります:
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のために独力で進む攻撃しているネットワーク実体は、代わりににせのホームエージェントアドレスを提供するか、ホームのエージェントにモバイルノードのトラフィックを横取りさせるにせの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を参照してください。
Patel & Giaretta Informational [Page 18] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[18ページ]のRFC4640PS
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人の給仕(または、ローミング)のネットワークアクセスプロバイダから別のアクセスプロバイダまで移動性アクセスプロバイダを変える必要はなくて移行できなければならないので、これが必要です。 最終的に、基本的な暗号のプロセスは広く異なった展開の必要性を収容するために複数のアルゴリズムに備えなければなりません。 また、攻撃が可能になるとき、デザインでアルゴリズムの交換の必要性を考えなければなりません。
10. Contributors
10. 貢献者
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、ヒロユキOhnishi、マユミ柳屋Samita Chakrabarti、ゴパル・Dommety、ケントレオン、Alper Yegin、ハンネスTschofenig、ビジェイDevarapalli、およびKuntalチョードリを入れます。
The design team members can be reached at the following email addresses:
以下のEメールアドレスでデザインチームメンバーに連絡できます:
Basavaraj Patil: basavaraj.patil@nokia.com
Basavarajパティル: basavaraj.patil@nokia.com
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
龍治Wakikawa: ryuji@sfc.wide.ad.jp
Hiroyuki Ohnishi: ohnishi.hiroyuki@lab.ntt.co.jp
ヒロユキOhnishi: ohnishi.hiroyuki@lab.ntt.co.jp
Mayumi Yanagiya: yanagiya.mayumi@lab.ntt.co.jp
マユミ・柳屋: yanagiya.mayumi@lab.ntt.co.jp
Samita Chakrabarti: Samita.Chakrabarti@eng.sun.com
Samita Chakrabarti: Samita.Chakrabarti@eng.sun.com
Patel & Giaretta Informational [Page 19] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[19ページ]のRFC4640PS
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: alper.yegin@samsung.com
Hannes Tschofenig: hannes.tschofenig@siemens.com
ハンネスTschofenig: hannes.tschofenig@siemens.com
Vijay Devarapalli: vijayd@iprg.nokia.com
ビジェイDevarapalli: vijayd@iprg.nokia.com
Kuntal Chowdhury: kchowdhury@starentnetworks.com
Kuntalチョードリ: kchowdhury@starentnetworks.com
11. Acknowledgements
11. 承認
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をありがとうございます。
12. Informative References
12. 有益な参照
[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.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、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下層属性」、Progress、2004年5月のWork。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3041] NartenとT.とR.Draves、「IPv6"での国がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC3753] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、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選択、確認、およびリコールは処理します」。 「指名とリコール委員会の操作」、BCP10、RFC3777、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.、Akhtar、H.、およびK.チョードリ、「モバイルIPv6のためのモバイルノード識別子オプション(MIPv6)」、RFC4283(2005年11月)。
Patel & Giaretta Informational [Page 20] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[20ページ]のRFC4640PS
[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.とAkhtar、H.とK.チョードリ、「モバイルIPv6"、RFC4285、2006年1月のための認証プロトコル。」
Authors' Addresses
作者のアドレス
Alpesh Patel Cisco 170 W. Tasman Drive San Jose, CA 95134 USA
Alpeshパテルシスコ170W.タスマン・Driveカリフォルニア95134サンノゼ(米国)
Phone: +1 408 853 9580 EMail: alpesh@cisco.com
以下に電話をしてください。 +1 9580年の408 853メール: alpesh@cisco.com
Gerardo Giaretta Telecom Italia via Reiss Romoli 274 Torino 10148 Italy
ライス・ロモリ274・トリノ10148イタリア経由でヘラルドGiarettaテレコムイタリア
Phone: +39 011 228 6904 EMail: gerardo.giaretta@telecomitalia.it
以下に電話をしてください。 +39 6904年の011 228メール: gerardo.giaretta@telecomitalia.it
Patel & Giaretta Informational [Page 21] RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
モバイルIPv6 September 2006を独力で進むパテルとGiarettaの情報[21ページ]のRFC4640PS
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Patel & Giaretta Informational [Page 22]
パテルとGiaretta情報です。[22ページ]
一覧
スポンサーリンク
