RFC5026 日本語訳
5026 Mobile IPv6 Bootstrapping in Split Scenario. G. Giaretta, Ed., J.Kempf, V. Devarapalli, Ed.. October 2007. (Format: TXT=63138 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Giaretta, Ed.
Request for Comments: 5026 Qualcomm
Category: Standards Track J. Kempf
DoCoMo Labs USA
V. Devarapalli, Ed.
Azaire Networks
October 2007
ワーキンググループG.Giaretta、エドをネットワークでつないでください。コメントのために以下を要求してください。 5026年のクアルコムカテゴリ: 規格は2007年10月にエドJ.ケンフDoCoMo研究室米国V.Devarapalli、Azaireネットワークを追跡します。
Mobile IPv6 Bootstrapping in Split Scenario
分裂シナリオを独力で進むモバイルIPv6
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario.
モバイルIPv6サービスを利用し始めることができる前にモバイルIPv6ノードはホームのエージェントとのホームエージェントアドレス、ホームアドレス、およびIPsecセキュリティ仲間を必要とします。 RFC3775は、これらのいくつかかすべてが静的に構成されるのを必要とします。 このドキュメントは非位相的な情報とモバイルNodeであらかじめ設定されたセキュリティー証明書からモバイルIPv6ノードがどうこの情報を独力で進むことができるかを定義します。 本書では定義されたソリューションはRFC4640での問題声明を独力で進むモバイルIPv6で説明された分裂シナリオを解決します。 分裂シナリオはモバイルNodeの移動性サービスが基本的なネットワークアクセサリーと異なったサービスプロバイダーによって認可されるケースを示します。 また、本書では説明されたソリューションも一般的にどんなブートストラップ法ケースにも適切です、他のシナリオが分裂シナリオの、より特定の実現であるので。
Giaretta, et al. Standards Track [Page 1] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[1ページ]RFC5026MIP6
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Split Scenario ..................................................4
4. Components of the Solution ......................................7
5. Protocol Operations .............................................9
5.1. Home Agent Address Discovery ...............................9
5.1.1. DNS Lookup by Home Agent Name ......................10
5.1.2. DNS Lookup by Service Name .........................10
5.2. IPsec Security Associations Setup .........................11
5.3. Home Address Assignment ...................................11
5.3.1. Home Address Assignment by the Home Agent ..........11
5.3.2. Home Address Auto-Configuration by the
Mobile Node ........................................12
5.4. Authorization and Authentication with MSA .................14
6. Home Address Registration in the DNS ...........................14
7. Summary of Bootstrapping Protocol Flow .........................16
8. Option and Attribute Format ....................................17
8.1. DNS Update Mobility Option ................................17
8.2. MIP6_HOME_PREFIX Attribute ................................19
9. Security Considerations ........................................20
9.1. HA Address Discovery ......................................20
9.2. Home Address Assignment through IKEv2 .....................22
9.3. SA Establishment Using EAP through IKEv2 ..................22
9.4. Backend Security between the HA and AAA Server ............22
9.5. Dynamic DNS Update ........................................23
10. IANA Considerations ...........................................24
11. Contributors ..................................................24
12. Acknowledgements ..............................................25
13. References ....................................................25
13.1. Normative References .....................................25
13.2. Informative References ...................................26
1. 序論…3 2. 用語…3 3. シナリオを分けてください…4 4. ソリューションの成分…7 5. 操作について議定書の中で述べてください…9 5.1. ホームエージェントアドレス発見…9 5.1.1. ホームエージェント名のDNSルックアップ…10 5.1.2. サービス名によるDNSルックアップ…10 5.2. IPsecセキュリティ協会はセットアップされます…11 5.3. ホームアドレス課題…11 5.3.1. ホームのエージェントによるホームアドレス課題…11 5.3.2. モバイルノードによるホームアドレス自動構成…12 5.4. MSAとの承認と認証…14 6. DNSでのホームアドレス登録…14 7. ブートストラップ法プロトコル流動の概要…16 8. オプションと属性形式…17 8.1. DNSは移動性オプションをアップデートします…17 8.2. MIP6_ホーム_は属性を前に置きます…19 9. セキュリティ問題…20 9.1. ハ、アドレスディスカバリー…20 9.2. IKEv2を通したホームアドレス課題…22 9.3. IKEv2を通してEAPを使用するSA設立…22 9.4. そして、間のバックエンドセキュリティ、ハ、AAAサーバ…22 9.5. ダイナミックなDNSアップデート…23 10. IANA問題…24 11. 貢献者…24 12. 承認…25 13. 参照…25 13.1. 標準の参照…25 13.2. 有益な参照…26
Giaretta, et al. Standards Track [Page 2] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[2ページ]RFC5026MIP6
1. Introduction
1. 序論
Mobile IPv6 [1] requires the Mobile Node to know its Home Agent Address, its own Home Address, and the cryptographic materials (e.g., shared keys or certificates) needed to set up IPsec security associations with the Home Agent (HA) in order to protect Mobile IPv6 signaling. This is generally referred to as the Mobile IPv6 bootstrapping problem [7].
モバイルIPv6[1]は、モバイルNodeがホームのエージェントAddress(それ自身のホームAddress)を知るのを必要とします、そして、暗号の材料(例えば、共有されたキーか証明書)はモバイルIPv6シグナリングを保護するためにホームのエージェント(HA)とのIPsecセキュリティ仲間をセットアップする必要がありました。 一般に、これは問題[7]を独力で進むモバイルIPv6と呼ばれます。
The Mobile IPv6 base protocol does not specify any method to automatically acquire this information, which means that network administrators are normally required to manually set configuration data on Mobile Nodes and HAs. However, in real deployments, manual configuration does not scale as the Mobile Nodes increase in number.
モバイルIPv6ベースプロトコルはモバイルNodesとHAsで自動的に通常、ネットワーク管理者が手動でコンフィギュレーション・データを設定しなければならないことを意味するこの情報を取得する少しのメソッドも指定しません。 しかしながら、本当の展開では、モバイルNodesが数が増えるのに従って、手動の構成は比例しません。
As discussed in [7], several bootstrapping scenarios can be identified depending on the relationship between the network operator that authenticates a mobile node for granting network access service (Access Service Authorizer, ASA) and the service provider that authorizes Mobile IPv6 service (Mobility Service Authorizer, MSA). This document describes a solution to the bootstrapping problem that is applicable in a scenario where the MSA and the ASA are different entities (i.e., a split scenario).
[7]で議論するように、ネットワークアクセス・サービス(Service Authorizerにアクセスしてください、ASA)を承諾するためのモバイルノードを認証するネットワーク・オペレータとモバイルIPv6サービス(移動性Service Authorizer、MSA)を認可するサービスプロバイダーとの関係によって、いくつかのブートストラップ法シナリオを特定できます。 このドキュメントはMSAとASAが異なった実体(すなわち、分裂シナリオ)であるシナリオで適用可能なブートストラップ法問題にソリューションについて説明します。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
General mobility terminology can be found in [8]. The following additional terms are used here:
[8]で一般移動性用語を見つけることができます。 次の追加用語はここで使用されます:
Access Service Authorizer (ASA)
アクセス・サービスAuthorizer(アサ)
A network operator that authenticates a mobile node and
establishes the mobile node's authorization to receive Internet
service.
モバイルノードを認証して、インターネットのサービスを受けるためにモバイルノードの承認を確立するネットワーク・オペレータ。
Access Service Provider (ASP)
アクセス・サービスプロバイダー(ASP)
A network operator that provides direct IP packet forwarding to
and from the end host.
ホストと終わりのホストからダイレクトIPパケット推進を提供するネットワーク・オペレータ。
Giaretta, et al. Standards Track [Page 3] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[3ページ]RFC5026MIP6
Mobility Service Authorizer (MSA)
移動性サービスAuthorizer(MSA)
A service provider that authorizes Mobile IPv6 service.
モバイルIPv6サービスを認可するサービスプロバイダー。
Mobility Service Provider (MSP)
移動性サービスプロバイダー(MSP)
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.
モバイルIPv6サービスを提供するサービスプロバイダー。 そのようなサービスを得るために、モバイルノードは、認証されて、承認がサービスを得ると立証しなければなりません。
Split scenario
分裂シナリオ
A scenario where mobility service and network access service are
authorized by different entities. This implies that MSA is
different from ASA.
移動性サービスとネットワークアクセス・サービスが異なった実体によって認可されるシナリオ。 これは、MSAがASAと異なっているのを含意します。
3. Split Scenario
3. 分裂シナリオ
In the problem statement description [7], there is a clear assumption that mobility service and network access service can be separate. This assumption implies that mobility service and network access service may be authorized by different entities. As an example, the service model defined in [7] allows an enterprise network to deploy a Home Agent and offer Mobile IPv6 service to a user, even if the user is accessing the Internet independent of its enterprise account (e.g., by using his personal WiFi hotspot account at a coffee shop).
問題声明記述[7]には、移動性サービスとネットワークアクセス・サービスが別々である場合があるという明確な仮定があります。 この仮定は、移動性サービスとネットワークアクセス・サービスが異なった実体によって認可されるかもしれないのを含意します。 例として、[7]で定義されたサービスモデルは、企業網にホームのエージェントを配布して、ユーザに対するモバイルIPv6サービスを提供させます、ユーザが企業アカウント(例えば、喫茶店で彼の個人的なWiFiホットスポットアカウントを使用するのによる)の如何にかかわらずインターネットにアクセスしていても。
Therefore, in this document it is assumed that network access and mobility service are authorized by different entities, which means that authentication and authorization for mobility service and network access will be considered separately. This scenario is called split scenario.
したがって、このドキュメントでは、想定されて、ネットワーク社会参加サービスが移動性サービスのために異なった実体、どれがその認証を意味するか、そして、および承認によって認可されて、アクセスをネットワークでつなぐのは別々に考えられるでしょう。 このシナリオは分裂シナリオと呼ばれます。
Moreover, the model defined in [7] separates the entity providing the service from the entity that authenticates and authorizes the user. This is similar to the roaming model for network access. Therefore, in the split scenario, two different cases can be identified depending on the relationship between the entity that provides the mobility service (i.e., Mobility Service Provider, MSP) and the entity that authenticates and authorizes the user (i.e., Mobility Service Authorizer, MSA).
そのうえ、[7]で定義されたモデルは、ユーザを認証して、権限を与える実体からサービスを提供しながら、実体を切り離します。 ネットワークアクセサリーに、これはローミングモデルと同様です。 したがって、分裂シナリオでは、移動性サービスを提供する実体(すなわち、Mobility Service Provider、MSP)とユーザを認証して、権限を与える実体(すなわち、Mobility Service Authorizer、MSA)との関係によって、2つの異なったケースを特定できます。
Giaretta, et al. Standards Track [Page 4] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[4ページ]RFC5026MIP6
Figure 1 depicts the split scenario when the MSP and the MSA are the same entity. This means that the network operator that provides the Home Agent authenticates and authorizes the user for mobility service.
MSPとMSAが同じ実体であるときに、図1は分裂シナリオについて表現します。 これは、ホームのエージェントを提供するネットワーク・オペレータが移動性サービスのためにユーザを認証して、権限を与えることを意味します。
Mobility Service
Provider and Authorizer
+-------------------------------------------+
| |
| +-------------+ +--+ |
| | MSA/MSP AAA | <-------------> |HA| |
| | server | AAA protocol +--+ |
| +-------------+ |
| |
+-------------------------------------------+
移動性サービスプロバイダーとAuthorizer+-------------------------------------------+ | | | +-------------+ +--+ | | | MSA/MSP AAA| <、-、-、-、-、-、-、-、-、-、-、-、-->| ハ| | | | サーバ| AAAプロトコル+--+| | +-------------+ | | | +-------------------------------------------+
+--+
|MN|
+--+
+--+ |ミネソタ| +--+
Figure 1 -- Split Scenario (MSA == MSP)
図1--分裂シナリオ(MSA=MSP)
Giaretta, et al. Standards Track [Page 5] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[5ページ]RFC5026MIP6
Figure 2 shows the split scenario in case the MSA and the MSP are two different entities. This might happen if the Mobile Node is far from its MSA network and is assigned a closer HA to optimize performance or if the MSA cannot provide any Home Agent and relies on a third party (i.e., the MSP) to grant mobility service to its users. Notice that the MSP might or might not also be the network operator that is providing network access (i.e., ASP, Access Service Provider).
図2は、MSAとMSPが2つの異なった実体であるといけないのに分裂シナリオを示しています。 MSAがユーザに対する移動性サービスを承諾するために、モバイルNodeはMSAネットワークから遠く、性能を最適化するために、より近いHAを割り当てられるか、どんなホームのエージェントも提供できないで、または第三者(すなわち、MSP)に頼るなら、これは起こるかもしれません。 MSPがネットワーク・オペレータであるかもしれないか、また、ネットワークアクセス(すなわち、ASP、Access Service Provider)を提供しているネットワーク・オペレータでないかもしれないのに注意してください。
Mobility Service
Authorizer
+-------------+
| MSA AAA |
| server |
+-------------+
^
|
AAA protocol |
| Mobility Service
| Provider
+--------|----------------------------------+
| V |
| +-------------+ +--+ |
| | MSP AAA | <-------------> |HA| |
| | server | AAA protocol +--+ |
| +-------------+ |
| |
+-------------------------------------------+
移動性サービスAuthorizer+-------------+ | MSA AAA| | サーバ| +-------------+ ^ | AAAプロトコル| | 移動性サービス| プロバイダー+--------|----------------------------------+ | V| | +-------------+ +--+ | | | MSP AAA| <、-、-、-、-、-、-、-、-、-、-、-、-->| ハ| | | | サーバ| AAAプロトコル+--+| | +-------------+ | | | +-------------------------------------------+
+--+
|MN|
+--+
+--+ |ミネソタ| +--+
Figure 2 -- Split Scenario (MSA != MSP)
図2--分裂シナリオ(MSA!=MSP)
Note that Figure 1 and Figure 2 assume the use of an Authentication, Authorization, and Accounting (AAA) protocol to authenticate and authorize the Mobile Node for mobility service. However, since the Internet Key Exchange Protocol (IKEv2) allows an Extensible Authentication Protocol (EAP) client authentication only and the server authentication needs to be performed based on certificates or public keys, the Mobile Node potentially requires a Certificate Revocation List check (CRL check) even though an AAA protocol is used to authenticate and authorize the Mobile Node for mobility service.
図1と図2が移動性サービスのためにモバイルNodeを認証して、認可するためにAuthentication、Authorization、およびAccounting(AAA)プロトコルの使用を仮定することに注意してください。 しかしながら、インターネット・キー・エクスチェンジプロトコル(IKEv2)が拡張認証プロトコル(EAP)クライアント認証だけを許容して、サーバ証明が、証明書か公開鍵に基づいて実行される必要があるので、AAAプロトコルは移動性サービスのためにモバイルNodeを認証して、認可するのに使用されますが、モバイルNodeは潜在的に、Certificate Revocation Listチェック(CRLはチェックする)を必要とします。
If, instead, a Public Key Infrastructure (PKI) is used, the Mobile Node and HA use certificates to authenticate each other and there is no AAA server involved [9]. This is conceptually similar to Figure 1, since the MSP == MSA, except the Home Agent, and potentially the
公開鍵暗号基盤(PKI)が代わりに使用されているなら、モバイルNodeとHAは互いを認証するのに証明書を使用します、そして、どんなAAAサーバかかわった[9]もありません。 MSP=MSA以来ホームのエージェントを除いて、これは概念的に潜在的に図1と同様です。
Giaretta, et al. Standards Track [Page 6] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[6ページ]RFC5026MIP6
Mobile Node, may require a certificate revocation list check (CRL check) with the Certification Authority (CA). The CA may be either internal or external to the MSP. Figure 3 illustrates this.
モバイルNode、認証局(カリフォルニア)と共に証明書失効リストチェックを必要とするかもしれません(CRLはチェックします)。 カリフォルニアは、MSPに内部である、または外部であるかもしれません。 図3はこれを例証します。
Certification
Authority
+-------------+
| CA |
| server |
+-------------+
^
|
CRL Check |
| Mobility Service
| Provider and Authorizer
+--------|----------+
| V |
| +-------------+ |
| | HA | |
| | | |
| +-------------+ |
| |
+-------------------+
認証局+-------------+ | カリフォルニア| | サーバ| +-------------+ ^ | CRLはチェックします。| | 移動性サービス| プロバイダーとAuthorizer+--------|----------+ | V| | +-------------+ | | | ハ| | | | | | | +-------------+ | | | +-------------------+
+--+
|MN|
+--+
+--+ |ミネソタ| +--+
Figure 3 -- Split Scenario with PKI
図3--PKIがある分裂シナリオ
For more details on the use of PKI for IKEv2 authentication, please refer to [3] and [10].
PKIのIKEv2認証の使用に関するその他の詳細について、[3]と[10]を参照してください。
The split scenario is the simplest model that can be identified, since no assumptions about the access network are made. This implies that the mobility service is bootstrapped independently from the authentication protocol for network access used (e.g., EAP or even open access). For this reason, the solution described in this document and developed for this scenario could also be applied to the integrated access-network deployment model [7], even if it might not be optimized.
分裂シナリオはアクセスネットワークに関する仮定が全くされないので特定できる中で最も簡単なモデルです。 これは、移動性サービスがアクセスが使用したネットワーク(例えば、EAPか開架さえ)のために認証プロトコルから独自に独力で進まれるのを含意します。 この理由で、また、本書では説明されて、このシナリオのために見いだされた解決策は統合アクセスネットワーク展開モデル[7]に適用できました、それが最適化されないかもしれなくても。
4. Components of the Solution
4. ソリューションの成分
The bootstrapping problem is composed of different sub-problems that can be solved independently in a modular way. The components are identified and a brief overview of their solution follow.
ブートストラップ法問題は独自にモジュールの方法で解決できる異なったサブ問題で構成されます。 コンポーネントは特定されます、そして、それらのソリューションの簡潔な概要は続きます。
Giaretta, et al. Standards Track [Page 7] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[7ページ]RFC5026MIP6
HA address discovery
HAアドレス発見
The Mobile Node needs to discover the address of its Home Agent.
The main objective of a bootstrapping solution is to minimize the
data pre-configured on the Mobile Node. For this reason, the
DHAAD defined in [1] may not be applicable in real deployments
since it is required that the Mobile Node is pre-configured with
the home network prefix and does not allow an operator to load
balance by having Mobile Nodes dynamically assigned to Home Agents
located in different subnets. This document defines a solution
for Home Agent address discovery that is based on Domain Name
Service (DNS), introducing a new DNS SRV record [4]. The unique
information that needs to be pre-configured on the Mobile Node is
the domain name of the MSP.
モバイルNodeは、ホームのエージェントのアドレスを発見する必要があります。 ブートストラップ法解決の主な目標はモバイルNodeであらかじめ設定されたデータを最小にすることです。 この理由で、[1]で定義されたDHAADは、モバイルNodeがホームネットワーク接頭語であらかじめ設定されるのが必要であるので、本当の展開で適切でないかもしれなく、またオペレータが異なったサブネットで位置するホームのエージェントにモバイルNodesをダイナミックに割り当てさせることによってバランスをロードするのを許容しません。 このドキュメントはDomain Name Service(DNS)に基づいているホームエージェントアドレス発見のためにソリューションを定義します、新しいDNS SRV記録[4]を紹介して。 モバイルNodeであらかじめ設定される必要があるユニークな情報はMSPのドメイン名です。
IPsec Security Associations setup
IPsec Security Associationsセットアップ
Mobile IPv6 requires that a Mobile Node and its Home Agent share
an IPsec SA in order to protect binding updates and other Mobile
IPv6 signaling. This document provides a solution that is based
on IKEv2 and follows what is specified in [3]. The IKEv2 peer
authentication can be performed both using certificates and using
EAP depending on the network operator's deployment model.
モバイルIPv6は、モバイルNodeとそのホームのエージェントが拘束力があるアップデートと他のモバイルIPv6シグナリングを保護するためにIPsec SAを共有するのを必要とします。 このドキュメントは、IKEv2に基づいている解決法を提供して、[3]で指定されることに続きます。 証明書を使用して、ネットワーク・オペレータの展開モデルに頼るEAPを使用することでIKEv2同輩認証を実行できます。
Home Address (HoA) assignment
ホームAddress(HoA)課題
The Mobile Node needs to know its Home Address in order to
bootstrap Mobile IPv6 operation. The Home Address is assigned by
the Home Agent during the IKEv2 exchange (as described in [3]).
The solution defined in this document also allows the Mobile Node
to auto-configure its Home Address based on stateless auto-
configuration [11], Cryptographically Generated Addresses [12], or
privacy addresses [13].
モバイルNodeは、モバイルIPv6操作を独力で進むためにホームAddressを知る必要があります。 ホームAddressはIKEv2交換の間、ホームのエージェントによって割り当てられます。([3])で説明されるように。 また、本書では定義されたソリューションで、モバイルNodeは状態がない自動構成[11]に基づくホームAddressを自動構成できます、Cryptographically Generated Addresses[12]かプライバシーが[13]を扱います。
Authentication and Authorization with MSA
MSAがある認証と承認
The user must be authenticated in order for the MSP to grant the
service. Since the user credentials can be verified only by the
MSA, this authorization step is performed by the MSA. Moreover,
the mobility service must be explicitly authorized by the MSA
based on the user's profile. These operations are performed in
different ways depending on the credentials used by the Mobile
Node during the IKEv2 peer authentication and on the backend
infrastructure (PKI or AAA).
MSPがサービスを承諾するように、ユーザを認証しなければなりません。 単にMSAがユーザ資格証明書について確かめることができるので、この承認ステップはMSAによって実行されます。 そのうえ、ユーザのプロフィールに基づくMSAは明らかに移動性サービスを認可しなければなりません。 これらの操作は資格証明書によるのがIKEv2同輩認証の間のモバイルNodeの近くと、そして、バックエンドインフラストラクチャの上で(PKIかAAA)を使用した異なった方法で実行されます。
An optional part of bootstrapping involves providing a way for the Mobile Node to have its Fully Qualified Domain Name (FQDN) updated in the DNS with a dynamically assigned home address. While not all
ブートストラップ法の任意の部分は、モバイルNodeがDNSでダイナミックに割り当てられたホームアドレスでFully Qualified Domain Name(FQDN)をアップデートさせる方法を提供することを伴います。 すべてをゆったり過ごすというわけではなくなってください。
Giaretta, et al. Standards Track [Page 8] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[8ページ]RFC5026MIP6
applications will require this service, many networking applications use the FQDN to obtain an address for a node prior to starting IP traffic with it. The solution defined in this document specifies that the dynamic DNS update is performed by the Home Agent or through the AAA infrastructure, depending on the trust relationship in place.
アプリケーションはこのサービスを必要として、多くのネットワークアプリケーションが、始めのIPトラフィックの前にそれでノードのためのアドレスを得るのにFQDNを使用します。 本書では定義されたソリューションは、ダイナミックなDNSアップデートがホームのエージェントの近く、または、AAAインフラストラクチャを通して実行されると指定します、適所にある信頼関係によって。
5. Protocol Operations
5. プロトコル操作
This section describes in detail the procedures needed to perform Mobile IPv6 bootstrapping based on the components identified in the previous section.
このセクションは詳細に前項で特定されたコンポーネントに基づいて独力で進むモバイルIPv6を実行するのに必要である手順について説明します。
5.1. Home Agent Address Discovery
5.1. ホームエージェントアドレス発見
Once a Mobile Node has obtained network access, it can perform Mobile IPv6 bootstrapping. For this purpose, the Mobile Node queries the DNS server to request information on Home Agent service. As mentioned before in the document, the Mobile Node should be pre- configured with the domain name of the Mobility Service Provider.
モバイルNodeがいったんネットワークアクセスを得ると、それはモバイルIPv6ブートストラップ法を実行できます。 このために、モバイルNodeは、ホームエージェントサービスの情報を要求するためにDNSサーバについて質問します。 以前ドキュメントで言及されるように、モバイルNodeはMobility Service Providerのドメイン名によってあらかじめ構成されるべきです。
The Mobile Node needs to obtain the IP address of a DNS server before it can send a DNS request. This can be configured on the Mobile Node or obtained through DHCPv6 from the visited link [14]. In any case, it is assumed that there is some kind of mechanism by which the Mobile Node is configured with a DNS server since a DNS server is needed for many other reasons.
モバイルNodeは、DNS要求を送ることができる前にDNSサーバのIPアドレスを得る必要があります。 これをモバイルNodeで構成するか、またはDHCPv6を通して訪問されたリンク[14]から得ることができます。 どのような場合でも、DNSサーバが他の多くの理由に必要であるのでモバイルNodeが構成されるある種のメカニズムがDNSサーバであると思われます。
Two options for DNS lookup for a Home Agent address are identified in this document: DNS lookup by Home Agent Name and DNS lookup by service name.
ホームエージェントアドレスのためのDNSルックアップのための2つのオプションが本書では特定されます: ホームエージェントNameによるDNSルックアップとサービス名によるDNSルックアップ。
This document does not provide a specific mechanism to load balance different Mobile Nodes among Home Agents. It is possible for an MSP to achieve coarse-grained load balancing by dynamically updating the SRV RR priorities to reflect the current load on the MSP's collection of Home Agents. Mobile Nodes then use the priority mechanism to preferentially select the least loaded HA. The effectiveness of this technique depends on how much of a load it will place on the DNS servers, particularly if dynamic DNS is used for frequent updates.
このドキュメントは、ホームのエージェントの中でバランスの異なったモバイルNodesを積み込むために特定のメカニズムを提供しません。 MSPがMSPのホームのエージェントの収集のときに現在の負荷を反映するためにダイナミックにSRV RRプライオリティをアップデートすることによって下品なロードバランシングを達成するのは、可能です。 そして、モバイルNodesは、優先的に最も積み込まれなかったHAを選択するのに優先権メカニズムを使用します。 このテクニックの有効性をそれがDNSサーバに負荷のどのくらいを置くかに依存します、特にダイナミックなDNSが頻繁なアップデートに使用されるなら。
While this document specifies a Home Agent Address Discovery solution based on DNS, when the ASP and the MSP are the same entity, DHCP may be used. See [15] for details.
ASPとMSPが同じ実体であるときに、このドキュメントがDNSに基づくホームエージェントAddressディスカバリーソリューションを指定している間、DHCPは使用されるかもしれません。 詳細のための[15]を見てください。
Giaretta, et al. Standards Track [Page 9] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[9ページ]RFC5026MIP6
5.1.1. DNS Lookup by Home Agent Name
5.1.1. ホームエージェント名のDNSルックアップ
In this case, the Mobile Node is configured with the Fully Qualified Domain Name of the Home Agent. As an example, the Mobile Node could be configured with the name "ha1.example.com", where "example.com" is the domain name of the MSP granting the mobility service.
この場合、モバイルNodeはホームのエージェントのFully Qualified Domain Nameによって構成されます。 例として、"ha1.example.com"という名前はモバイルNodeを構成できました。そこでは、"example.com"が移動性サービスを承諾するMSPのドメイン名です。
The Mobile Node constructs a DNS request by setting the QNAME to the name of the Home Agent. The request has QTYPE set to "AAAA" so that the DNS server sends the IPv6 address of the Home Agent. Once the DNS server replies to this query, the Mobile Node knows its Home Agent address and can run IKEv2 in order to set up the IPsec SAs and get a Home Address.
モバイルNodeは、ホームのエージェントの名前にQNAMEを設定することによって、DNS要求を構成します。 要求で"AAAA"にQTYPEを用意ができさせるので、DNSサーバはホームのエージェントのIPv6アドレスを送ります。 かつてのこの質問に関するDNSサーバ回答、モバイルNodeはIPsec SAsをセットアップして、ホームAddressを手に入れるためにホームエージェントアドレスを知って、IKEv2を実行できます。
Note that the configuration of a home agent FQDN on the mobile node can also be extended to dynamically assign a local home agent from the visited network. Such dynamic assignment would be useful, for instance, from the point of view of improving routing efficiency in bidirectional tunneling mode. Enhancements or conventions for dynamic assignment of local home agents are outside the scope of this specification.
また、訪問されたネットワークから地元のホームのエージェントをダイナミックに選任するためにモバイルノードの上のホームのエージェントFQDNの構成を広げることができることに注意してください。 例えば、そのようなダイナミックな課題は、双方向のトンネリングモードによる効率を発送しながら、向上の観点から役に立つでしょう。 この仕様の範囲の外に地元のホームのエージェントのダイナミックな課題のための増進かコンベンションがあります。
5.1.2. DNS Lookup by Service Name
5.1.2. サービス名によるDNSルックアップ
RFC 2782 [4] defines the service resource record (SRV RR) that allows an operator to use several servers for a single domain, to move services from host to host, and to designate some hosts as primary servers for a service and others as backups. Clients ask for a specific service/protocol for a specific domain and get back the names of any available servers.
RFC2782[4]はオペレータが単一領域にいくつかのサーバを使用して、サービスをホストからホストに動かして、バックアップとしてのサービスと他のもののためにプライマリサーバとして何人かのホストを任命するサービスリソース記録(SRV RR)を、定義します。 クライアントは、特定のサービス/プロトコルを特定のドメインに求めて、どんな利用可能なサーバの名前も取り戻します。
RFC 2782 [4] also describes the policies to choose a service agent based on the preference and weight values. The DNS SRV record may contain the preference and weight values for multiple Home Agents available to the Mobile Node in addition to the Home Agent FQDNs. If multiple Home Agents are available in the DNS SRV record, then the Mobile Node is responsible for processing the information as per policy and for picking one Home Agent. If the Home Agent of choice does not respond to the IKE_SA_INIT messages or if IKEv2 authentication fails, the Mobile Node SHOULD try the next Home Agent on the list. If none of the Home Agents respond, the Mobile Node SHOULD try again after a period of time that is configurable on the Mobile Node. If IKEv2 authentication fails with all Home Agents, it is an unrecoverable error on the Mobile Node.
また、RFC2782[4]は、好みに基づくサービスエージェントを選んで、値に重みを加えるために方針を説明します。 DNS SRV記録は、モバイルNodeに手があいている複数のホームのエージェントのためにホームのエージェントFQDNsに加えて好みを含んでいて、値に重みを加えるかもしれません。 複数のホームのエージェントがDNS SRV記録に手があくなら、モバイルNodeは方針に従って情報を処理して、1人のホームのエージェントを選ぶのに責任があります。 選択のホームのエージェントがイケ_SA_INITメッセージに応じないか、またはIKEv2認証が失敗するなら、モバイルNode SHOULDはリストで次期ホームのエージェントを裁きます。 ホームのエージェントのだれも応じないなら、モバイルNode SHOULDはモバイルNodeで構成可能な期間の後に再試行します。 IKEv2認証がすべてのホームのエージェントと共に失敗するなら、それはモバイルNodeの上の回復不能エラーです。
The service name for Mobile IPv6 Home Agent service, as required by RFC 2782, is "mip6" and the protocol name is "ipv6". Note that a
サービスは必要に応じてRFC2782でモバイルIPv6にちなんでエージェントサービスとホームを命名して、ある、「mip6"と存在というプロトコル名の"ipv6""。 そのaに注意してください。
Giaretta, et al. Standards Track [Page 10] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[10ページ]RFC5026MIP6
transport name cannot be used here because Mobile IPv6 does not run over a transport protocol.
モバイルIPv6がトランスポート・プロトコルをひかないので、ここで輸送名を使用できません。
The SRV RR has a DNS type code of 33. As an example, the Mobile constructs a request with QNAME set to "_mip6._ipv6.example.com" and QTYPE to SRV. The reply contains the FQDNs of one or more servers that can then be resolved in a separate DNS transaction to the IP addresses. However, if there is room in the SRV reply, it is RECOMMENDED that the DNS server also return the IP addresses of the Home Agents in AAAA records as part of the additional data section (in order to avoid requiring an additional DNS round trip to resolve the FQDNs).
SRV RRはDNSに33のコードをタイプさせます。 「例として、モバイルは」 _mip6_ipv6.example.comに用意ができているQNAMEとの要求を構成し」てSRVへのQTYPE。 回答は次に別々のDNSトランザクションでIPアドレスに決議できる1つ以上のサーバのFQDNsを含んでいます。 しかしながら、SRV回答に余地があれば、また、DNSサーバが追加資料課の一部としてAAAA記録でホームのエージェントのIPアドレスを返すのは、RECOMMENDED(FQDNsを決議するために追加DNS周遊旅行を必要とするのを避けるために)です。
5.2. IPsec Security Associations Setup
5.2. IPsecセキュリティ協会セットアップ
As soon as the Mobile Node has discovered the Home Agent Address, it establishes an IPsec Security Association with the Home Agent itself through IKEv2. The detailed description of this procedure is provided in [3]. If the Mobile Node wants the HA to register the Home Address in the DNS, it MUST use the FQDN as the initiator identity in the IKE_AUTH step of the IKEv2 exchange (IDi). This is needed because the Mobile Node has to prove it is the owner of the FQDN provided in the subsequent DNS Update Option. See Sections 6 and 9 for a more detailed analysis on this issue.
モバイルNodeがホームのエージェントAddressを発見するとすぐに、それはホームのエージェント自身と共にIKEv2を通してIPsec Security Associationを設立します。 この手順の詳述を[3]に提供します。 モバイルNodeが、HAにDNSにホームAddressを登録して欲しいなら、それは創始者のアイデンティティとしてIKEv2交換(IDi)のイケ_AUTHステップでFQDNを使用しなければなりません。 モバイルNodeが、それがその後のDNS Update Optionに提供されたFQDNの所有者であると立証しなければならないので、これが必要です。 この問題の、より詳細な分析に関してセクション6と9を見てください。
The IKEv2 Mobile Node to Home Agent authentication can be performed using either IKEv2 public key signatures or the Extensible Authentication Protocol (EAP). The details about how to use IKEv2 authentication are described in [3] and [5]. The choice of an IKEv2 peer authentication method depends on the deployment. The Mobile Node should be configured with the information on which IKEv2 authentication method to use. However, IKEv2 restricts the Home Agent to Mobile Node authentication to use public key signature-based authentication.
IKEv2公開鍵署名か拡張認証プロトコル(EAP)のどちらかを使用することでホームエージェント認証へのIKEv2のモバイルNodeを実行できます。 どうIKEv2認証を使用するかに関する詳細は[3]と[5]で説明されます。 IKEv2同輩認証方法のこの選択は展開次第です。 モバイルNodeはどのIKEv2認証方法を使用したらよいかの情報によって構成されるべきです。 しかしながら、IKEv2は、公開鍵の署名ベースの認証を使用するためにホームのエージェントをモバイルNode認証に制限します。
5.3. Home Address Assignment
5.3. ホームアドレス課題
Home Address assignment is performed during the IKEv2 exchange. The Home Address can be assigned directly by the Home Agent or it can be auto-configured by the Mobile Node.
ホームAddress課題はIKEv2交換の間、実行されます。 直接ホームのエージェントがホームAddressを割り当てることができますか、またはモバイルNodeはそれを自動構成できます。
5.3.1. Home Address Assignment by the Home Agent
5.3.1. ホームのエージェントによるホームアドレス課題
When the Mobile Node runs IKEv2 with its Home Agent, it can request a HoA through the Configuration Payload in the IKE_AUTH exchange by including an INTERNAL_IP6_ADDRESS attribute. When the Home Agent processes the message, it allocates a HoA and sends it a CFG_REPLY message. The Home Agent could consult a DHCP server on the home link
モバイルNodeがホームのエージェントと共にIKEv2を実行するとき、それは、Configuration有効搭載量を通してイケ_AUTH交換でINTERNAL_IP6_ADDRESS属性を含んでいることによって、HoAを要求できます。 ホームのエージェントがメッセージを処理するとき、それは、HoAを割り当てて、CFG_REPLYメッセージをそれに送ります。 ホームのエージェントはホームのリンクに関してDHCPサーバに相談できました。
Giaretta, et al. Standards Track [Page 11] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[11ページ]RFC5026MIP6
for the actual home address allocation. This is explained in detail in [3].
実際のホームアドレス配分のために。 これは[3]で詳細に説明されます。
5.3.2. Home Address Auto-Configuration by the Mobile Node
5.3.2. モバイルノードによるホームアドレス自動構成
With the type of assignment described in the previous section, the Home Address cannot be generated based on Cryptographically Generated Addresses (CGAs) [12] or based on the privacy extensions for stateless auto-configuration [13]. However, the Mobile Node might want to have an auto-configured HoA based on these mechanisms. It is worthwhile to mention that the auto-configuration procedure described in this section cannot be used in some possible deployments, since the Home Agents might be provisioned with pools of allowed Home Addresses.
課題のタイプが前項で説明されている状態で、ホームAddressはCryptographically Generated Addresses(CGAs)[12]に基づいて生成することができませんし、状態がない自動構成[13]のためにプライバシー拡大に基づくことができません。 しかしながら、モバイルNodeは自動構成されたHoAをこれらのメカニズムに基礎づけて頂きたいかもしれません。いくつかの可能な展開でこのセクションで説明された自動構成手順は用いることができないと言及する価値があります、ホームのエージェントが許容ホームAddressesのプールで食糧を供給されるかもしれないので。
In the simplest case, the Mobile Node is provided with a pre- configured home prefix and home prefix length. In this case, the Mobile Node creates a Home Address based on the pre-configured prefix and sends it to the Home Agent, including an INTERNAL_IP6_ADDRESS attribute in a Configuration Payload of type CFG_REQUEST. If the Home Address is valid, the Home Agent replies with a CFG_REPLY, including an INTERNAL_IP6_ADDRESS with the same address. If the Home Address provided by the Mobile Node is not valid, the Home Agent assigns a different Home Address including an INTERNAL_IP6_ADDRESS attribute with a new value. According to [5], the Mobile Node MUST use the address sent by the Home Agent. Later, if the Mobile Node wants to use an auto-configured Home Address (e.g., based on CGA), it can run Mobile Prefix Discovery, obtain a prefix, auto-configure a new Home Address, and then perform a new CREATE_CHILD_SA exchange.
最も簡単な場合では、あらかじめ構成されたホーム接頭語とホーム接頭語の長さをモバイルNodeに提供します。 この場合、モバイルNodeはあらかじめ設定された接頭語に基づくホームAddressを作成して、ホームAddressが有効であるなら、タイプCFG_REQUESTのConfiguration有効搭載量にINTERNAL_IP6_ADDRESS属性を含むホームのエージェントにそれを送ります、CFG_REPLYとのホームエージェント回答、同じアドレスでINTERNAL_IP6_ADDRESSを含んでいて。 モバイルNodeによって提供されたホームAddressが有効でないなら、ホームのエージェントは新しい値でINTERNAL_IP6_ADDRESS属性を含む異なったホームAddressを割り当てます。 [5]によると、モバイルNodeはホームのエージェントによって送られたアドレスを使用しなければなりません。 その後、モバイルNodeが自動構成されたホームAddress(例えば、CGAに基づいている)を使用したいと思うなら、それは、モバイルPrefixディスカバリーを実行して、接頭語を得て、新しいホームAddressを自動構成して、次に、新しいCREATE_CHILD_SA交換を実行できます。
If the Mobile Node is not provided with a pre-configured Home Prefix, the Mobile cannot simply propose an auto-configured HoA in the Configuration Payload since the Mobile Node does not know the home prefix before the start of the IKEv2 exchange. The Mobile Node must obtain the home prefix and the home prefix length before it can configure a home address.
モバイルNodeがIKEv2交換の始まりの前にホーム接頭語を知らないので、あらかじめ設定されたホームPrefixがモバイルNodeに提供されないなら、モバイルはConfiguration有効搭載量で自動構成されたHoAを絶対に提案できません。 ホームアドレスを構成できる前にモバイルNodeはホーム接頭語とホーム接頭語の長さを得なければなりません。
One simple solution would be for the Mobile Node to just assume that the prefix length on the home link is 64 bits and extract the home prefix from the Home Agent's address. The disadvantage with this solution is that the home prefix cannot be anything other than /64. Moreover, this ties the prefix on the home link and the Home Agent's address, but, in general, a Home Agent with a particular address should be able to serve a number of prefixes on the home link, not just the prefix from which its address is configured.
1つの簡単なソリューションがモバイルNodeが、ホームのリンクの接頭語の長さが64ビットであるとただ仮定するだろうことであり、抽出はホームのエージェントのアドレスからのホーム接頭語です。 このソリューションがある不都合は/64を除いて、ホーム接頭語が何かであるはずがないということです。 そのうえ、これはホームのリンクとホームのエージェントのアドレスに接頭語を結びますが、一般に、特定のアドレスをもっているホームのエージェントはアドレスが構成される接頭語だけではなく、ホームのリンクの上の多くの接頭語に役立つことができるべきです。
Another solution would be for the Mobile Node to assume that the prefix length on the home link is 64 bits and send its interface
他の解決法は、モバイルNodeがホームのリンクの接頭語の長さが64ビットであると仮定して、インタフェースを送るだろうことです。
Giaretta, et al. Standards Track [Page 12] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[12ページ]RFC5026MIP6
identifier to the Home Agent in the INTERNAL_IP6_ADDRESS attribute within the CFG_REQ payload. Even though this approach does not tie the prefix on the home link and the Home Agent's address, it still requires that the home prefix length is 64 bits.
CFG_REQペイロードの中のINTERNAL_IP6_ADDRESS属性におけるホームのエージェントへの識別子。 このアプローチはホームのリンクとホームのエージェントのアドレスに接頭語を結びませんが、それは、ホーム接頭語の長さが64ビットであることをまだ必要としています。
For this reason, the Mobile Node needs to obtain the home link prefixes through the IKEv2 exchange. In the Configuration Payload during the IKE_AUTH exchange, the Mobile Node includes the MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home Agent, when it processes this message, MUST include in the CFG_REPLY payload prefix information for one prefix on the home link. This prefix information includes the prefix length (see Section 8.2). The Mobile Node auto-configures a Home Address from the prefix returned in the CFG_REPLY message and runs a CREATE_CHILD_SA exchange to create security associations for the new Home Address.
この理由で、モバイルNodeは、IKEv2交換を通してホームリンク接頭語を得る必要があります。 イケ_AUTH交換の間のConfiguration有効搭載量では、モバイルNodeはCFG_REQUESTメッセージにMIP6_ホーム_PREFIX属性を含んでいます。 このメッセージを処理するとき、ホームのエージェントはCFG_REPLYでホームのリンクの上の1つの接頭語のためのペイロード接頭語情報を入れなければなりません。 この接頭語情報は接頭語の長さを含んでいます(セクション8.2を見てください)。 モバイルNodeは、CFG_REPLYメッセージで返された接頭語からホームAddressを自動構成して、新しいホームAddressのためにセキュリティ協会を創設するためにCREATE_CHILD_SA交換を実行します。
As mentioned before in this document, there are deployments where auto-configuration of the Home Address cannot be used. In this case, when the Home Agent receives a CFG_REQUEST that includes a MIP6_HOME_PREFIX attribute in the subsequent IKE response, it includes a Notify Payload type "USE_ASSIGNED_HoA" and the related Home Address in a INTERNAL_IP6_ADDRESS attribute. If the Mobile Node gets a "USE_ASSIGNED_HoA" Notify Payload in response to the Configuration Payload containing the MIP6_HOME_PREFIX attribute, it looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the address contained in it in the subsequent CREATE_CHILD_SA exchange.
以前本書では言及されるように、展開がホームAddressの自動構成を使用できないところにあります。 ホームのエージェントがこの場合その後のIKE応答にMIP6_ホーム_PREFIX属性を含んでいるCFG_REQUESTを受け取るとき、それは「_が_HoAを割り当てた使用」とINTERNAL_IP6_ADDRESSの関連するホームAddressが結果と考えるNotify有効搭載量タイプを含んでいます。 モバイルNodeがMIP6_ホーム_PREFIX属性を含むConfiguration有効搭載量に対応して「_HoAが割り当てられた_を使用してください」というNotify有効搭載量を得るなら、それは、INTERNAL_IP6_ADDRESS属性を探して、それにその後のCREATE_CHILD_SA交換に含まれたアドレスを使用しなければなりません。
When the Home Agent receives a Binding Update for the Mobile Node, it performs proxy DAD for the auto-configured Home Address. If DAD fails, the Home Agent rejects the Binding Update. If the Mobile Node receives a Binding Acknowledgement with status 134 (DAD failed), it MUST stop using the current Home Address, configure a new HoA, and then run IKEv2 CREATE_CHILD_SA exchange to create security associations based on the new HoA. The Mobile Node does not need to run IKE_INIT and IKE_AUTH exchanges again. Once the necessary security associations are created, the Mobile Node sends a Binding Update for the new Home Address.
ホームのエージェントがモバイルNodeのためにBinding Updateを受け取るとき、それは自動構成されたホームAddressのためにプロキシDADを実行します。 DADが失敗するなら、ホームのエージェントはBinding Updateを拒絶します。 モバイルNodeが状態134があるBinding Acknowledgementを受けるなら(DADは失敗しました)、それは、新しいHoAに基づくセキュリティ協会を創設するために現在のホームAddressを使用するのを止めて、新しいHoAを構成して、IKEv2 CREATE_CHILD_SA交換を述べなければなりません。 モバイルNodeは再びイケ_INITとイケ_AUTH交換を実行する必要はありません。 必要なセキュリティ協会がいったん創設されると、モバイルNodeは新しいホームAddressのためにBinding Updateを送ります。
It is worth noting that with this mechanism, the prefix information carried in MIP6_HOME_PREFIX attribute includes only one prefix and does not carry all the information that is typically present when received through a IPv6 router advertisement. Mobile Prefix Discovery, specified in RFC 3775, is the mechanism through which the Mobile Node can get all prefixes on the home link and all related information. That means that MIP6_HOME_PREFIX attribute is only used for Home Address auto-configuration and does not replace the usage of Mobile Prefix Discovery for the purposes detailed in RFC 3775.
MIP6_ホーム_PREFIX属性で運ばれた接頭語情報がこのメカニズムで、1つの接頭語だけを含んで、すべてのIPv6ルータ通知で受け取ると通常存在している情報を運ぶというわけではないことに注意する価値があります。 RFC3775で指定されたモバイルPrefixディスカバリーはモバイルNodeがホームのリンクとすべての関連情報ですべての接頭語を得ることができるメカニズムです。 それは、MIP6_ホーム_PREFIX属性がホームAddress自動構成に使用されるだけであることを意味して、RFC3775で詳細な目的のためにモバイルPrefixディスカバリーの使用法を置き換えません。
Giaretta, et al. Standards Track [Page 13] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[13ページ]RFC5026MIP6
5.4. Authorization and Authentication with MSA
5.4. MSAとの承認と認証
In a scenario where the Home Agent is discovered dynamically by the Mobile Node, it is very likely that the Home Agent is not able to verify by its own the credentials provided by the Mobile Node during the IKEv2 exchange. Moreover, the mobility service needs to be explicitly authorized based on the user's profile. As an example, the Home Agent might not be aware of whether the mobility service can be granted at a particular time of the day or when the credit of the Mobile Node is going to expire.
ホームのエージェントがモバイルNodeによってダイナミックに発見されるシナリオでは、ホームのエージェントはそれ自身のものでIKEv2交換の間にモバイルNodeによって提供された資格証明書について非常に確かめることができなさそうです。 そのうえ、移動性サービスは、ユーザのプロフィールに基づいて明らかに認可される必要があります。 例として、ホームのエージェントは1日の特定の時に移動性サービスを承諾できるかどうか、またはモバイルNodeのクレジットがいつ期限が切れるかを意識していないかもしれません。
Due to all these reasons, the Home Agent may need to contact the MSA in order to authenticate the Mobile Node and authorize mobility service. This can be accomplished based on a Public Key Infrastructure if certificates are used and a PKI is deployed by the MSP and MSA. On the other hand, if the Mobile Node is provided with other types of credentials, the AAA infrastructure must be used.
これらのすべての理由のため、ホームのエージェントは、モバイルNodeを認証して、移動性サービスを認可するためにMSAに連絡する必要があるかもしれません。 証明書が使用されているなら、公開鍵暗号基盤に基づいてこれを達成できます、そして、PKIはMSPとMSAによって配布されます。 他方では、他のタイプの資格証明書をモバイルNodeに提供するなら、AAAインフラストラクチャを使用しなければなりません。
The definition of this backend communication is out of the scope of this document. In [16], a list of goals for such a communication is provided. [17] and [18] define the RADIUS and Diameter extensions, respectively, for the backend communication.
このドキュメントの範囲の外にこのバックエンドコミュニケーションの定義があります。 そのようなコミュニケーションの目標のリストを[16]に提供します。 [17]と[18]はバックエンドコミュニケーションのためにそれぞれRADIUSとDiameter拡張子を定義します。
6. Home Address Registration in the DNS
6. DNSでのホームアドレス登録
In order that the Mobile Node is reachable through its dynamically assigned Home Address, the DNS needs to be updated with the new Home Address. Since applications make use of DNS lookups on FQDN to find a node, the DNS update is essential for providing IP reachability to the Mobile Node, which is the main purpose of the Mobile IPv6 protocol. The need for DNS updating is not discussed in RFC 3775 since it assumes that the Mobile Node is provisioned with a static Home Address. However, when a dynamic Home Address is assigned to the Mobile Node, any existing DNS entry becomes invalid and the Mobile Node becomes unreachable unless a DNS update is performed.
モバイルNodeがダイナミックに割り当てられたホームAddressを通して届いているように、DNSは、新しいホームAddressと共にアップデートする必要があります。 アプリケーションがノードを見つけるのにFQDNでDNSルックアップを利用するので、IPの可到達性をモバイルNodeに供給するのに、DNSアップデートは不可欠です。(NodeはモバイルIPv6プロトコルの主な目的です)。 モバイルNodeに静的なホームAddressと共に食糧を供給されると仮定するので、RFC3775でDNSアップデートの必要性について議論しません。 しかしながら、ダイナミックなホームAddressがモバイルNodeに割り当てられるとき、どんな既存のDNSエントリーも無効になります、そして、DNSアップデートが実行されない場合、モバイルNodeは手が届かなくなります。
Since the DNS update must be performed securely in order to prevent attacks or modifications from malicious nodes, the node performing this update must share a security association with the DNS server. Having all possible Mobile Nodes sharing a security association with the DNS servers of the MSP might be cumbersome from an administrative perspective. Moreover, even if a Mobile Node has a security association with a DNS server of its MSP, an address authorization issue comes into the picture. A detailed analysis of possible threats against DNS update is provided in Section 9.5.
悪意があるノードから攻撃か変更を防ぐためにしっかりとDNSアップデートを実行しなければならないので、このアップデートを実行するノードはDNSサーバとのセキュリティ協会を共有しなければなりません。すべての可能なモバイルNodesにMSPのDNSサーバとのセキュリティ協会を共有させるのは、管理見解から厄介であるかもしれません。 そのうえ、モバイルNodeにMSPのDNSサーバとのセキュリティ協会があっても、アドレス承認問題は登場します。 DNSアップデートに対する可能な脅威の詳細に渡る分析をセクション9.5に提供します。
Therefore, due to security and administrative reasons, it is RECOMMENDED that the Home Agent perform DNS entry updates for the
したがって、セキュリティと管理理由のために、それはホームのエージェントがDNSエントリーアップデートを実行するRECOMMENDEDです。
Giaretta, et al. Standards Track [Page 14] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[14ページ]RFC5026MIP6
Mobile Node. For this purpose, the Mobile Node MAY include a new mobility option in the Binding Update, the DNS Update option, with the flag R not set in the option. This option is defined in Section 8 and includes the FQDN that needs to be updated. After receiving the Binding Update, the Home Agent MUST update the DNS entry with the identifier provided by the Mobile Node and the Home Address included in the Home Address Option. The procedure for sending a dynamic DNS update message is specified in [6]. The dynamic DNS update SHOULD be performed in a secure way; for this reason, the usage of TKEY and TSEC or DNSSEC is recommended (see Section 9.5 for details). As soon as the Home Agent has updated the DNS, it MUST send a Binding Acknowledgement message to the Mobile Node, including the DNS Update mobility option with the correct value in the Status field (see Section 8.1).
モバイルノード。 このために、モバイルNodeはBinding Updateの新しい移動性オプションを含むかもしれません、DNS Updateオプション、オプションで設定されなかった旗Rで。 このオプションは、セクション8で定義されて、アップデートする必要があるFQDNを含んでいます。 Binding Updateを受けた後に、ホームのエージェントはモバイルNodeによって提供される識別子とホームAddress OptionにAddressを含んでいるホームでDNSエントリーをアップデートしなければなりません。 ダイナミックなDNSアップデートメッセージを送るための手順は[6]で指定されます。 ダイナミックなDNSは実行されたコネが安全な道であったならSHOULDをアップデートします。 この理由で、TKEYとTSECかDNSSECの使用法はお勧めです(詳細に関してセクション9.5を見てください)。 ホームのエージェントがDNSをアップデートするとすぐに、Binding AcknowledgementメッセージをモバイルNodeに送らなければなりません、正しい値がStatus分野にあるDNS Update移動性オプションを含んでいて(セクション8.1を見てください)。
This procedure can be performed directly by the Home Agent if the Home Agent has a security association with the domain specified in the Mobile Node's FQDN.
ホームのエージェントにモバイルNodeのFQDNで指定されるドメインとのセキュリティ協会があるなら、直接ホームのエージェントはこの手順を実行できます。
On the other hand, if the Mobile Node wants to be reachable through a FQDN that belongs to the MSA, the Home Agent and the DNS server that must be updated belong to different administrative domains. In this case, the Home Agent may not share a security association with the DNS server and the DNS entry update can be performed by the AAA server of the MSA. In order to accomplish this, the Home Agent sends to the AAA server the FQDN-HoA pair through the AAA protocol. This message is proxied by the AAA infrastructure of the MSP and is received by the AAA server of the MSA. The AAA server of the MSA performs the DNS update based on [6]. Notice that, even in this case, the Home Agent is always required to perform a DNS update for the reverse entry, since this is always performed in the DNS server of the MSP. The detailed description of the communication between Home Agent and AAA is out of the scope of this document. More details are provided in [16].
他方では、モバイルNodeがMSAに属すFQDNを通して届くようになりたがっているなら、アップデートしなければならないホームのエージェントとDNSサーバは異なった管理ドメインに属します。 この場合、ホームのエージェントはDNSサーバとのセキュリティ協会を共有しないかもしれません、そして、MSAのAAAサーバはDNSエントリーアップデートを実行できます。 これを達成するために、ホームのエージェントはAAAプロトコルを通してFQDN-HoA組をAAAサーバに送ります。 このメッセージをMSPのAAAインフラストラクチャでproxiedして、MSAのAAAサーバは受け取ります。 MSAのAAAサーバは[6]に基づくDNSアップデートを実行します。 この場合さえホームのエージェントがいつも逆のエントリーのためのDNSアップデートを実行しなければならないのに注意してください、これがMSPのDNSサーバでいつも実行されるので。 このドキュメントの範囲の外にホームのエージェントとAAAとのコミュニケーションの詳述があります。 その他の詳細を[16]に提供します。
A mechanism to remove stale DNS entries is needed. A DNS entry becomes stale when the related Home Address is no longer used by the Mobile Node. To remove a DNS entry, the Mobile Node includes in the Binding Update the DNS Update mobility option, with the flag R set in the option. After receiving the Binding Update, the Home Agent MUST remove the DNS entry identified by the FQDN provided by the Mobile Node and the Home Address included in the Home Address Option. The procedure for sending a dynamic DNS update message is specified in [6]. As mentioned above, the dynamic DNS update SHOULD be performed in a secure way; for this reason, the usage of TKEY and TSEC or DNSSEC is recommended (see Section 9.5 for details).
聞き古したDNSエントリーを取り除くメカニズムが必要です。 関連するホームAddressがもうモバイルNodeによって使用されないとき、DNSエントリーは聞き古したであるなります。 DNSエントリーを取り除くために、モバイルNodeはBinding UpdateにDNS Update移動性オプションを含んでいます、オプションで設定された旗Rで。 Binding Updateを受けた後に、ホームのエージェントはモバイルNodeによって提供されて、ホームAddress OptionにホームAddressを含んでいて、FQDNによって特定されたDNSエントリーを取り除かなければなりません。 ダイナミックなDNSアップデートメッセージを送るための手順は[6]で指定されます。 ダイナミックなDNSがSHOULDをアップデートすると上に言及するように、安全な方法で実行されてください。 この理由で、TKEYとTSECかDNSSECの使用法はお勧めです(詳細に関してセクション9.5を見てください)。
Giaretta, et al. Standards Track [Page 15] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[15ページ]RFC5026MIP6
If there is no explicit de-registration BU from the Mobile Node, then the HA MAY use the binding cache entry expiration as a trigger to remove the DNS entry.
モバイルNodeからのどんな明白な反-登録BUもなければ、HA MAYは、DNSエントリーを取り除くのに引き金として拘束力があるキャッシュエントリー満了を使用します。
7. Summary of Bootstrapping Protocol Flow
7. ブートストラップ法プロトコル流動の概要
The message flow of the whole bootstrapping procedure when the dynamic DNS update is performed by the Home Agent is depicted below.
ダイナミックなDNSアップデートがホームのエージェントによって実行されるとき、全体のブートストラップ法手順のメッセージ流動は以下に表現されます。
+----+ +----+ +-----+
| MN | | HA | | DNS |
+----+ +----+ +-----+
+----+ +----+ +-----+ | ミネソタ| | ハ| | DNS| +----+ +----+ +-----+
IKEv2 exchange
(HoA configuration)
<======================>
IKEv2交換(HoA構成)<。======================>。
BU (DNS update option)
----------------------->
DNS update
<------------------->
BA (DNS update option)
<-----------------------
BU(DNSアップデートオプション)----------------------->DNSアップデート<。------------------->BA(DNSアップデートオプション)<。-----------------------
Giaretta, et al. Standards Track [Page 16] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[16ページ]RFC5026MIP6
On the contrary, the figure below shows the message flow of the whole bootstrapping procedure when the dynamic DNS update is performed by the AAA server of the MSA.
これに反して、以下の図は、ダイナミックなDNSアップデートがいつMSAのAAAサーバによって実行されるかを全体のブートストラップ法手順のメッセージ流動に示します。
+----+ +----+ +---+ +---+
| MN | | HA | |AAA| |DNS|
+----+ +----+ +---+ +---+
+----+ +----+ +---+ +---+ | ミネソタ| | ハ| |AAA| |DNS| +----+ +----+ +---+ +---+
IKEv2 exchange
(HoA configuration)
<======================>
IKEv2交換(HoA構成)<。======================>。
BU (DNS update option)
----------------------->
BU(DNSアップデートオプション)----------------------->。
AAA request
(FQDN, HoA)
<-------------->
AAA要求(FQDN、HoA)<。-------------->。
DNS update
<----------->
AAA answer
(FQDN, HoA)
<-------------->
BA (DNS update option)
<-----------------------
DNSアップデート<。----------->AAA答え(FQDN、HoA)<。-------------->BA(DNSアップデートオプション)<。-----------------------
Notice that even in this last case, the Home Agent is always required to perform a DNS update for the reverse entry, since this is always performed in the DNS server of the MSP. This is not depicted in the figure above.
この最後の場合ではさえ、ホームのエージェントが逆のエントリーのためのDNSアップデートをいつも実行しなければならないのに注意してください、これがMSPのDNSサーバでいつも実行されるので。 これは上の図形に表現されません。
8. Option and Attribute Format
8. オプションと属性形式
8.1. DNS Update Mobility Option
8.1. DNSアップデート移動性オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |R| Reserved | MN identity (FQDN) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態|R| 予約されます。| ミネソタのアイデンティティ(FQDN)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
DNS-UPDATE-TYPE (17)
DNSアップデートタイプ(17)
Giaretta, et al. Standards Track [Page 17] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[17ページ]RFC5026MIP6
Option Length
オプションの長さ
8-bit unsigned integer indicating the length of the option
excluding the type and length fields
タイプと長さの分野を除いたオプションの長さを示す8ビットの符号のない整数
Status
状態
8-bit unsigned integer indicating the result of the dynamic DNS
update procedure. This field MUST be set to 0 and ignored by the
receiver when the DNS Update mobility option is included in a
Binding Update message. When the DNS Update mobility option is
included in the Binding Acknowledgement message, values of the
Status field less than 128 indicate that the dynamic DNS update
was performed successfully by the Home Agent. Values greater than
or equal to 128 indicate that the dynamic DNS update was not
completed by the HA. The following Status values are currently
defined:
ダイナミックなDNSアップデート手順の結果を示す8ビットの符号のない整数。 DNS Update移動性オプションがBinding Updateメッセージに含まれているとき、この分野を0に設定されて、受信機で無視しなければなりません。 DNS Update移動性オプションがBinding Acknowledgementメッセージに含まれているとき、128未満のStatus分野の値は、ダイナミックなDNSアップデートがホームのエージェントによって首尾よく実行されたのを示します。 値より多くの128は、ダイナミックなDNSアップデートがHAによって終了しなかったのを示します。 以下のStatus値は現在、定義されます:
0 DNS update performed
アップデートが実行した0DNS
128 Reason unspecified
128は不特定の状態で推論します。
129 Administratively prohibited
129は行政上禁止しました。
130 DNS update failed
アップデートが失敗した130DNS
R flag
R旗
If set, the Mobile Node is requesting the HA to remove the DNS
entry identified by the FQDN specified in this option and the HoA
of the Mobile Node. If not set, the Mobile Node is requesting the
HA to create or update a DNS entry with its HoA and the FQDN
specified in the option.
設定されるなら、モバイルNodeは、このオプションで指定されたFQDNとモバイルNodeのHoAによって特定されたDNSエントリーを取り除くようHAに要求しています。 設定されないなら、モバイルNodeは、HoAとFQDNがオプションで指定されている状態で、DNSエントリーを作成するか、またはアップデートするようHAに要求しています。
Reserved
予約されます。
MUST be set to 0.
0に設定しなければなりません。
MN identity
ミネソタのアイデンティティ
The identity of the Mobile Node in FQDN format to be used by the
Home Agent to send a Dynamic DNS update. It is a variable length
field.
Dynamic DNSアップデートを送るのにホームのエージェントによって使用されるべきFQDN形式における、モバイルNodeのアイデンティティ。 それは可変長フィールドです。
Giaretta, et al. Standards Track [Page 18] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[18ページ]RFC5026MIP6
8.2. MIP6_HOME_PREFIX Attribute
8.2. MIP6_ホーム_接頭語属性
The MIP6_HOME_PREFIX attribute is carried in IKEv2 Configuration Payload messages. This attribute is used to convey the home prefix from which the Mobile Node auto-configures its home address.
MIP6_ホーム_PREFIX属性はIKEv2 Configuration有効搭載量メッセージで運ばれます。 この属性は、モバイルNodeがホームアドレスを自動構成するホーム接頭語を伝えるのに使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Home Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| 属性タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯を前に置いてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ホーム接頭語| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| +-+-+-+-+-+-+-+-+
Reserved (1 bit)
予約されます。(1ビット)
This bit MUST be set to zero and MUST be ignored on receipt.
このビットをゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Attribute Type (15 bits)
属性タイプ(15ビット)
A unique identifier for the MIP6_HOME_PREFIX attribute (16).
MIP6_ホーム_PREFIX属性(16)のためのユニークな識別子。
Length (2 octets)
長さ(2つの八重奏)
Length in octets of Value field (Home Prefix, Prefix Lifetime and
Prefix Length). This can be 0 or 21.
Value分野(ホームPrefix、Prefix Lifetime、およびPrefix Length)の八重奏における長さ。 これは、0か21であるかもしれません。
Prefix Lifetime (4 octets)
生涯を前に置いてください。(4つの八重奏)
The lifetime of the Home Prefix.
ホームPrefixの生涯。
Home Prefix (16 octets)
ホーム接頭語(16の八重奏)
The prefix of the home link through which the Mobile Node may
auto-configure its Home Address.
モバイルNodeがホームAddressを自動構成するかもしれないホームのリンクの接頭語。
Prefix Length (1 octet)
接頭語の長さ(1つの八重奏)
The length in bits of the home prefix specified in the field Home
Prefix.
ホーム接頭語のビットの長さは分野ホームPrefixで指定しました。
Giaretta, et al. Standards Track [Page 19] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[19ページ]RFC5026MIP6
When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in the CFG_REQUEST payload, the value of the Length field is 0. When the MIP6_HOME_PREFIX attribute is included in the CFG_REPLY payload by the Home Agent, the value of the Length field is 21 and the attribute contains also the home prefix information.
MIP6_ホーム_PREFIX属性がCFG_REQUESTペイロードにモバイルNodeによって含まれているとき、Length分野の値は0です。 MIP6_ホーム_PREFIX属性がCFG_REPLYペイロードでホームのエージェントによって入れられているとき、Length分野の値は21です、そして、また、属性はホーム接頭語情報を含んでいます。
9. Security Considerations
9. セキュリティ問題
9.1. HA Address Discovery
9.1. ハ、アドレスディスカバリー
Use of DNS for address discovery carries certain security risks. DNS transactions in the Internet are typically done without any authentication of the DNS server by the client or of the client by the server. There are two risks involved:
DNSのアドレス発見の使用はあるセキュリティ危険を運びます。 サーバは通常クライアントによるDNSサーバかクライアントの少しも認証なしでインターネットのDNSトランザクションをします。かかわった2つのリスクがあります:
1. A legitimate client obtains a bogus Home Agent address from a
bogus DNS server. This is sometimes called a "pharming" attack.
1. 正統のクライアントはにせのDNSサーバからにせのホームエージェントアドレスを得ます。これは時々「なりすまし詐欺」攻撃と呼ばれます。
2. An attacking client obtains a legitimate Home Agent address from
a legitimate server.
2. 攻撃しているクライアントは正統のサーバから正統のホームエージェントアドレスを得ます。
The risk in Case 1 is mitigated because the Mobile Node is required to conduct an IKE transaction with the Home Agent prior to performing a Binding Update to establish Mobile IPv6 service. According to the IKEv2 specification [5], the responder must present the initiator with a valid certificate containing the responder's public key, and the responder to initiator IKE_AUTH message must be protected with an authenticator calculated using the public key in the certificate. Thus, an attacker would have to set up both a bogus DNS server and a bogus Home Agent, and provision the Home Agent with a certificate that a victim Mobile Node could verify. If the Mobile Node can detect that the certificate is not trustworthy, the attack will be foiled when the Mobile Node attempts to set up the IKE SA.
モバイルNodeがモバイルIPv6サービスを証明するためにBinding Updateを実行する前のホームのエージェントと共にIKEトランザクションを行わなければならないので、Case1の危険は緩和されます。 IKEv2仕様[5]に従って、応答者は応答者の公開鍵を含む有効な証明書を創始者に与えなければなりません、そして、固有識別文字が計算されている状態で、証明書で公開鍵を使用することで創始者イケ_AUTHメッセージへの応答者を保護しなければなりません。 したがって、攻撃者は犠牲者のモバイルNodeが確かめることができた証明書でにせのDNSサーバとにせのホームのエージェントと支給の両方にホームのエージェントを設定しなければならないでしょう。 モバイルNodeがそれを検出できるなら証明書が信頼できない、モバイルNodeが、IKE SAをセットアップするのを試みると、攻撃はくじかれるでしょう。
The risk in Case 2 is limited for a single Mobile Node to Home Agent transaction if the attacker does not possess proper credentials to authenticate with the Home Agent. The IKE SA establishment will fail when the attacking Mobile Node attempts to authenticate itself with the Home Agent. Regardless of whether the Home Agent utilizes EAP or host-side certificates to authenticate the Mobile Node, the authentication will fail unless the Mobile Node has valid credentials.
攻撃者にホームのエージェントと共に認証する適切な資格証明書がないなら、Case2の危険は独身のモバイルNodeのためにホームエージェントトランザクションに制限されます。 攻撃しているモバイルNodeが、ホームのエージェントと共にそれ自体を認証するのを試みるとき、IKE SA設立は行き詰まるでしょう。 ホームのエージェントがモバイルNodeを認証するのにEAPかホストサイド証明書を利用するかどうかにかかわらず、モバイルNodeに正当な証明書がないと、認証は失敗するでしょう。
Another risk exists in Case 2 because the attacker may be attempting to propagate a Denial of Service (DoS) attack on the Home Agent. In that case, the attacker obtains the Home Agent address from the DNS, then propagates the address to a network of attacking hosts that bombard the Home Agent with traffic. This attack is not unique to
攻撃者が、ホームのエージェントに対するサービス妨害(DoS)攻撃を伝播するのを試みているかもしれないので、別のリスクはCase2に存在しています。 その場合、攻撃者は、DNSからホームエージェントアドレスを得て、次に、トラフィックでホームのエージェントを砲撃する攻撃しているホストのネットワークにアドレスを伝播します。 この攻撃は特有ではありません。
Giaretta, et al. Standards Track [Page 20] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[20ページ]RFC5026MIP6
the bootstrapping solution, however, it is actually a risk that any Mobile IPv6 Home Agent installation faces. In fact, the risk is faced by any service in the Internet that distributes a unicast globally routable address to clients. Since Mobile IPv6 requires that the Mobile Node communicate through a globally routable unicast address of a Home Agent, it is possible that the Home Agent address could be propagated to an attacker by various means (theft of the Mobile Node, malware installed on the Mobile Node, evil intent of the Mobile Node owner him/herself, etc.) even if the home address is manually configured on the Mobile Node. Consequently, every Mobile IPv6 Home Agent installation will likely be required to mount anti- DoS measures. Such measures include overprovisioning of links to and from Home Agents and of Home Agent processing capacity, vigilant monitoring of traffic on the Home Agent networks to detect when traffic volume increases abnormally indicating a possible DoS attack, and hot spares that can quickly be switched on in the event an attack is mounted on an operating collection of Home Agents. DoS attacks of moderate intensity should be foiled during the IKEv2 transaction. IKEv2 implementations are expected to generate their cookies without any saved state, and to time out cookie generation parameters frequently, with the timeout value increasing if a DoS attack is suspected. This should prevent state depletion attacks, and should assure continued service to legitimate clients until the practical limits on the network bandwidth and processing capacity of the Home Agent network are reached.
しかしながら、ブートストラップ法解決であり、それは実際にどんなモバイルIPv6ホームエージェントインストールも直面している危険です。 事実上、リスクはいずれによっても面されていて、ユニキャストを分配するインターネットでのサービスがクライアントにアドレスをグローバルに発送可能するということです。 モバイルIPv6が、モバイルNodeがホームのエージェントのグローバルに発送可能なユニキャストアドレスを通って交信するのを必要とするので、ホームアドレスがモバイルNodeで手動で構成されてもホームエージェントアドレスがあの手この手で(モバイルNode、モバイルNodeの上にインストールされたマルウェア、モバイルNode所有者自身の不吉な意図などの窃盗)攻撃者に伝播されるかもしれないのは、可能です。 その結果、あらゆるモバイルIPv6ホームエージェントインストールが、反DoS測定を取り付けるのにおそらく必要でしょう。 そのような測定は、エージェントとホームのエージェントからリンクに過剰食糧を供給するのを含んでいます、そして、ホームエージェント処理容量、検出するホームエージェントネットワークでのトラフィックの用心深いモニターでは、交通量が異常に、可能なDoS攻撃、およびイベントですばやくつけることができるホットスペアを示しながら増加すると攻撃はホームのエージェントの操作収集のときに仕掛けられます。 適度の強度のDoS攻撃はIKEv2トランザクションの間、くじかれるべきです。 IKEv2実装が頻繁にどんな保存している状態なしでもタイムアウトクッキー世代パラメタにそれらのクッキーを生成すると予想されます、DoS攻撃が疑われるならタイムアウト値が増加していて。 これは、州の減少攻撃を防ぐべきであり、ネットワーク回線容量と容量を処理するときのホームエージェントネットワークの実用的な限界に達するまで、正統のクライアントに対する継続的なサービスを保証するべきです。
Explicit security measures between the DNS server and host, such as DNSSEC [19] or TSIG/TKEY [20] [21], can mitigate the risk of 1) and 2), but these security measures are not widely deployed on end nodes. These security measures are not sufficient to protect the Home Agent address against DoS attack, however, because a node having a legitimate security association with the DNS server could nevertheless intentionally or inadvertently cause the Home Agent address to become the target of DoS.
DNSサーバとホストの間のDNSSEC[19]かTSIG/TKEY[20][21]などの明白な安全策は1と)2の)危険を緩和できますが、これらの安全策はエンドノードで広く配布されません。 これらの安全策は、しかしながら、それにもかかわらず、ホームエージェントアドレスがDNSサーバとの正統のセキュリティ協会を持っているノードによって故意にかうっかりDoSの目標になることができたのでDoS攻撃に対してホームエージェントアドレスを保護するために十分ではありません。
Finally, notice that the assignment of a home agent from the serving network access provider's (local home agent) or a home agent from a nearby network (nearby home agent) may set up the potential to compromise a mobile node's location privacy. A home address anchored at such a home agent contains some information about the topological location of the mobile node. Consequently, a mobile node requiring location privacy should not disclose this home address to nodes that are not authorized to learn the mobile node's location, e.g., by updating DNS with the new home address.
最終的に、アクセスプロバイダの給仕ネットワークものからのホームのエージェント(地元のホームのエージェント)か近いネットワークからのホームのエージェント(近いホームのエージェント)の課題がモバイルノードの位置のプライバシーに感染する可能性をセットアップするかもしれないのに注意してください。 そのようなホームのエージェントに据えつけられたホームアドレスはモバイルノードの位相的な位置の何らかの情報を含んでいます。 その結果、位置のプライバシーを必要とするモバイルノードはモバイルノードの位置を学ぶのは認可されないノードにこのホームアドレスを明らかにするはずがありません、例えば、新しいホームアドレスでDNSをアップデートすることによって。
Security considerations for discovering HA using DHCP are covered in [22].
DHCPを使用することでHAを発見するためのセキュリティ問題は[22]でカバーされています。
Giaretta, et al. Standards Track [Page 21] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[21ページ]RFC5026MIP6
9.2. Home Address Assignment through IKEv2
9.2. IKEv2を通したホームアドレス課題
Mobile IPv6 bootstrapping assigns the home address through the IKEv2 transaction. The Mobile Node can either choose to request an address, similar to DHCP, or the Mobile Node can request a prefix on the home link, then auto-configure an address.
モバイルIPv6ブートストラップ法はIKEv2トランザクションを通してホームアドレスを割り当てます。 モバイルNodeは、アドレスを要求するのを選ぶことができます、DHCPと同様であるか、モバイルNodeがホームのリンクの上に接頭語を要求して、次に、アドレスを自動構成できます。
RFC 3775 [1] requires that a Home Agent check authorization of a home address received during a Binding Update. Therefore, the home agent MUST authorize each home address allocation and use. This authorization is based on linking the mobile node identity used in the IKEv2 authentication process and the home address. Home agents MUST implement at least the following two modes of authorization:
RFC3775[1]は、ホームアドレスのホームエージェントチェック承認がBinding Updateの間受信されたのを必要とします。 したがって、ホームのエージェントは各ホームアドレス配分と使用を認可しなければなりません。 この承認はIKEv2認証過程とホームアドレスで使用されるモバイルノードのアイデンティティをリンクするのに基づいています。 ホームのエージェントは、少なくとも↓これが承認の2つのモードであると実装しなければなりません:
o Configured home address(es) for each mobile node. In this mode,
the home agent or infrastructure nodes behind it know what
addresses a specific mobile node is authorized to use. The mobile
node is allowed to request these addresses, or if the mobile node
requests any home address, these addresses are returned to it.
o それぞれのモバイルノードのための構成されたホームアドレス(es)。 それの後ろのこのモード、ホームのエージェントまたはインフラストラクチャノードでは、特定のモバイルノードがどんなアドレスを使用するのが認可されるかを知ってください。 モバイルノードがこれらのアドレスを要求できますか、またはモバイルノードが何かホームアドレスを要求するなら、これらのアドレスをそれに返します。
o First-come-first-served (FCFS). In this mode, the home agent
maintains a pool of "used" addresses, and allows mobile nodes to
request any address, as long as it is not used by another mobile
node.
o 先着順(FCFS)。 このモードで、ホームのエージェントは、「中古」のアドレスのプールを主張して、モバイルノードがどんなアドレスも要求するのを許します、それが別のモバイルノードによって使用されない限り。
Addresses MUST be marked as used for at least as long as the binding exists, and are associated with the identity of the mobile node that made the allocation.
アドレスは、少なくとも同じくらい長い間結合が存在しているのと同じくらい使用されているとマークしなければならなくて、配分をしたモバイルノードのアイデンティティに関連しています。
In addition, the home agent MUST ensure that the requested address is not the authorized address of any other mobile node, i.e., if both FCFS and configured modes use the same address space.
さらに、ホームのエージェントは、要求されたアドレスがいかなる他のモバイルノードの認可されたアドレスでないことも保証しなければなりません、すなわち、FCFSと構成されたモードの両方が同じアドレス空間を使用するなら。
9.3. SA Establishment Using EAP through IKEv2
9.3. IKEv2を通してEAPを使用するSA設立
Security considerations for authentication of the IKE transaction using EAP are covered in [3] .
EAPを使用するIKEトランザクションの認証のためのセキュリティ問題は[3]でカバーされています。
9.4. Backend Security between the HA and AAA Server
9.4. 間のバックエンドセキュリティ、ハ、AAAサーバ
Some deployments of Mobile IPv6 bootstrapping may use an AAA server to handle authorization for mobility service. This process has its own security requirements, but the backend protocol for a Home Agent to an AAA server interface is not covered in this document. Please see [16] for a discussion of this interface.
モバイルIPv6ブートストラップ法のいくつかの展開が、移動性サービスのために承認を扱うのにAAAサーバを使用するかもしれません。 このプロセスには、それ自身のセキュリティ要件がありますが、AAAサーバインタフェースへのホームのエージェントのためのバックエンドプロトコルは本書ではカバーされていません。 このインタフェースの議論のための[16]を見てください。
Giaretta, et al. Standards Track [Page 22] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[22ページ]RFC5026MIP6
9.5. Dynamic DNS Update
9.5. ダイナミックなDNSアップデート
If a Home Agent performs dynamic DNS update on behalf of the Mobile Node directly with the DNS server, the Home Agent MUST have a security association of some type with the DNS server. The security association MAY be established either using DNSSEC [19] or TSIG/TKEY [20][21]. A security association is REQUIRED even if the DNS server is in the same administrative domain as the Home Agent. The security association SHOULD be separate from the security associations used for other purposes, such as AAA.
ホームのエージェントが直接DNSサーバがあるモバイルNodeを代表してダイナミックなDNSアップデートを実行するなら、ホームのエージェントにはタイプのセキュリティ協会がDNSサーバでなければなりません。セキュリティ協会はDNSSEC[19]かTSIG/TKEY[20][21]を使用するのにおいて設立されているかもしれません。 DNSサーバがホームのエージェントと同じ管理ドメインにあっても、セキュリティ協会はREQUIREDです。 セキュリティ協会SHOULD、AAAなどの他の目的に使用されるセキュリティ協会から、別々であってください。
In the case where the Mobility Service Provider is different from the Mobility Service Authorizer, the network administrators may want to limit the number of cross-administrative domain security associations. If the Mobile Node's FQDN is in the Mobility Service Authorizer's domain, since a security association for AAA signaling involved in mobility service authorization is required in any case, the Home Agent can send the Mobile Node's FQDN to the AAA server under the HA-AAA server security association, and the AAA server can perform the update. In that case, a security association is required between the AAA server and DNS server for the dynamic DNS update. See [16] for a deeper discussion of the Home Agent to AAA server interface.
Mobility Service ProviderがMobility Service Authorizerと異なっている場合では、ネットワーク管理者は十字管理のドメインセキュリティ協会の数を制限したがっているかもしれません。 モバイルNodeのFQDNがMobility Service Authorizerのドメインにあるなら、移動性サービス承認にかかわるAAAシグナリングのためのセキュリティ協会がどのような場合でも必要であるので、ホームのエージェントはHA-AAAサーバセキュリティ協会の下でモバイルNodeのFQDNをAAAサーバに送ることができます、そして、AAAサーバはアップデートを実行できます。 その場合、セキュリティ協会がダイナミックなDNSアップデートのためのAAAサーバとDNSサーバの間で必要です。 ホームのエージェントの、より深い議論のための[16]をAAAサーバインタフェースに見てください。
Regardless of whether the AAA server or Home Agent performs DNS update, the authorization of the Mobile Node to update a FQDN MUST be checked prior to the performance of the update. It is an implementation issue as to how authorization is determined. However, in order to allow this authorization step, the Mobile Node MUST use a FQDN as the IDi in IKE_AUTH step of the IKEv2 exchange. The FQDN MUST be the same as the FQDN that will be provided by the Mobile Node in the DNS Update Option.
FQDN MUSTをアップデートするモバイルNodeの承認はAAAサーバかホームのエージェントがDNSアップデートを実行するかどうかチェックされます。にかかわらず、前、アップデートの性能。 それは承認がどう決定しているかに関する導入問題です。 しかしながら、この承認ステップを許容するために、モバイルNodeはIDiとしてIKEv2交換のイケ_AUTHステップでFQDNを使用しなければなりません。 FQDN MUST、DNS Update OptionのモバイルNodeによって提供されるFQDNと同じにしてください。
In case EAP over IKEv2 is used to set-up the IPsec SA, the Home Agent gets authorization information about the Mobile Node's FQDN via the AAA back end communication performed during IKEv2 exchange. The outcome of this step will give the Home Agent the necessary information to authorize the DNS update request of the Mobile Node. See [16] for details about the communication between the AAA server and the Home Agent needed to perform the authorization.
IKEv2の上のEAPがIPsec SAをセットアップするのに使用されるといけないので、ホームのエージェントはIKEv2交換の間に実行されたAAAバックエンドコミュニケーションでモバイルNodeのFQDNの承認情報を得ます。 このステップの結果は、モバイルNodeに関するDNS更新要求を認可するためにホームのエージェントに必要事項を与えるでしょう。 AAAサーバとホームのエージェントとのコミュニケーションに関する詳細のための[16]が、承認を実行する必要だったのを確実にしてください。
In case certificates are used in IKEv2, the authorization information about the FQDN for DNS update MUST be present in the certificate provided by the Mobile Node. Since the IKEv2 specification does not include a required certificate type, it is not possible to specify precisely how the Mobile Node's FQDN should appear in the
証明書がIKEv2で使用されるといけないので、DNSアップデートのためのFQDNの承認情報はモバイルNodeによって提供された証明書に存在していなければなりません。 IKEv2仕様が必要な証明書タイプを含んでいないので、モバイルNodeのFQDNが正確にどのように中に現れるはずであるかを指定するのは可能ではありません。
Giaretta, et al. Standards Track [Page 23] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[23ページ]RFC5026MIP6
certificate. However, as an example, if the certificate type is "X.509 Certificate - Signature" (one of the recommended types), then the FQDN may appear in the subjectAltName attribute extension [23].
証明します。 しかしながら、証明書であるなら例として、タイプがそうである、「X.509、証明書--署名、」 (お勧めのタイプのひとり)、そして、FQDNはsubjectAltName属性拡張子[23]に現れるかもしれません。
10. IANA Considerations
10. IANA問題
This document defines a new Mobility Option and a new IKEv2 Configuration Attribute Type.
このドキュメントは新しいMobility Optionと新しいIKEv2 Configuration Attribute Typeを定義します。
The following values have been assigned:
以下の値を割り当ててあります:
o from the "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE, 17
(Section 8.1)
o 「移動性オプション」名前空間([1])から: 17歳のDNSアップデートタイプ(セクション8.1)
o from the "IKEv2 Configuration Payload Attribute Types" namespace
([5]): MIP6_HOME_PREFIX attribute, 16 (Section 8.2)
o 「IKEv2構成有効搭載量属性タイプ」名前空間([5])から: MIP6_ホーム_PREFIX属性、16(セクション8.2)
o from the "IKEv2 Notify Payload Error Types" namespace ([5]):
USE_ASSIGNED_HoA error type, 42 (Section 5.3.2)
o 「IKEv2は有効搭載量誤りタイプに通知する」という名前空間([5])から: 42歳のUSE_ASSIGNED_HoA誤りタイプ(セクション5.3.2)
This document creates a new name space "Status Codes (DNS Update Mobility Option)" for the status field in the DNS Update mobility option. The current values are described in Section 8.1 and are listed below.
このドキュメントは「状態はコード化(DNSアップデート移動性オプション)」新しい名前スペースをDNS Update移動性オプションにおける状態分野に作成します。 現行価値は、セクション8.1で説明されて、以下に記載されています。
0 DNS update performed
アップデートが実行した0DNS
128 Reason unspecified
128は不特定の状態で推論します。
129 Administratively prohibited
129は行政上禁止しました。
130 DNS update failed
アップデートが失敗した130DNS
Future values of the Status field in the DNS Update mobility option can be allocated using Standards Action or IESG approval.
Standards ActionかIESG承認を使用することでDNS Update移動性オプションにおけるStatus分野の将来価値を割り当てることができます。
11. Contributors
11. 貢献者
This contribution is a joint effort of the bootstrapping solution design team of the MIP6 WG. The contributors include Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal Chowdury, and Julien Bournelle.
この貢献はMIP6 WGのブートストラップ法ソリューションデザインチームの共同努力です。 貢献者はBasavarajパティル、Alpeshパテル、ヤリArkko、ジェームス・ケンフ、芳広オオバ、ゴパルDommety、Alper Yegin、Junghoon Jee、ビジェイDevarapalli、Kuntalチョードリ、およびジュリアンBournelleを入れます。
Giaretta, et al. Standards Track [Page 24] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[24ページ]RFC5026MIP6
The design team members can be reached at:
以下でデザインチームメンバーに連絡できます。
Gerardo Giaretta, gerardog@qualcomm.com
ヘラルドGiaretta、 gerardog@qualcomm.com
Basavaraj Patil, basavaraj.patil@nokia.com
Basavarajパティル、 basavaraj.patil@nokia.com
Alpesh Patel, alpesh@cisco.com
Alpeshパテル、 alpesh@cisco.com
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
Gopal Dommety, gdommety@cisco.com
ゴパルDommety、 gdommety@cisco.com
Alper Yegin, alper.yegin@samsung.com
Alper Yegin、 alper.yegin@samsung.com
Vijay Devarapalli, vijay.devarapalli@azairenet.com
ビジェイDevarapalli、 vijay.devarapalli@azairenet.com
Kuntal Chowdury, kchowdury@starentnetworks.com
Kuntalチョードリ、 kchowdury@starentnetworks.com
Junghoon Jee, jhjee@etri.re.kr
Junghoon Jee、 jhjee@etri.re.kr
Julien Bournelle, julien.bournelle@gmail.com
ジュリアンBournelle、 julien.bournelle@gmail.com
12. Acknowledgements
12. 承認
The authors would like to thank Rafa Lopez, Francis Dupont, Jari Arkko, Kilian Weniger, Vidya Narayanan, Ryuji Wakikawa, and Michael Ye for their valuable comments.
作者は彼らの貴重なコメントについてRafaロペス、フランシス・デュポン、ヤリArkko、キリアン・ウェニガー、Vidyaナラヤナン、龍治Wakikawa、およびマイケルYeに感謝したがっています。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[1] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April
2007.
[3]DevarapalliとV.とF.デュポン、「IKEv2と改訂されたIPsecアーキテクチャとのモバイルIPv6操作」、RFC4877、2007年4月。
Giaretta, et al. Standards Track [Page 25] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[25ページ]RFC5026MIP6
[4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[4]Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[5] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[6]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
13.2. Informative References
13.2. 有益な参照
[7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[7] パテルとA.とG.Giaretta、「モバイルIPv6(MIPv6)を独力で進むための問題Statement」、RFC4640、2006年9月。
[8] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[8] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[9] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet
X.509 Public Key Infrastructure Certificate Management Protocol
(CMP)", RFC 4210, September 2005.
[9] アダムス、C.、ファレル、S.、Kause、T.、およびT.Mononen、「インターネットX.509公開鍵暗号基盤証明書経営者側は(CMP)について議定書の中で述べます」、RFC4210、2005年9月。
[10] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[10]Korver、2007年8月のB.、「IKEv1/ISAKMP、IKEv2、およびPKIXのインターネットIPセキュリティPKIプロフィール」RFC4945。
[11] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[11]Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
[12] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
3972, March 2005.
[12] 香気、T.、「アドレス(CGA)であると暗号で生成された」RFC3972、2005年3月。
[13] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941,
September 2007.
[13]Narten、T.、Draves、R.、およびS.クリシュナン、「IPv6"、RFC4941、2007年9月の状態がないアドレス自動構成のためのプライバシー拡大。」
[14] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
2003.
[14]Droms、R.、「IPv6(DHCPv6)のためのDynamic Host Configuration ProtocolのためのDNS Configurationオプション」、RFC3646、2003年12月。
[15] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Work in Progress, June 2007.
[15] 「統合シナリオのためのMIP6-ブートストラップ法」というチョードリ、K.、およびA.Yeginは進歩、2007年6月に働いています。
[16] Giaretta, G., "AAA Goals for Mobile IPv6", Work in Progress,
September 2006.
[16]Giaretta、G.、「モバイルIPv6"のAAA目標、処理中の作業、2006年9月。」
Giaretta, et al. Standards Track [Page 26] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[26ページ]RFC5026MIP6
[17] Chowdhury, K., "RADIUS Mobile IPv6 Support", Work in Progress,
March 2007.
[17] チョードリ、K.、「半径のモバイルIPv6サポート」が進歩、2007年3月に働いています。
[18] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support",
Work in Progress, May 2007.
[18]Bournelle、J.、「直径のモバイルIPv6:」 「ハ、HAAAがサポートする<->」(処理中の作業)は2007がそうするかもしれません。
[19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[19]はArendsします、R.、Austein、R.、ラーソン、M.、マッシー、D.、S.ローズと、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[20] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[20] Vixie(P.、グドムンソン、O.、イーストレーク、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[21] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.
[21] イーストレーク、D.、「DNS(TKEY RR)のための秘密鍵設立」、RFC2930、2000年9月。
[22] Jang, H., "DHCP Option for Home Information Discovery in
MIPv6", Work in Progress, June 2007.
[22]Jang、H.、「MIPv6"でのホーム情報発見、処理中の作業、2007年6月のためのDHCPオプション。」
[23] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[23]Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
Authors' Addresses
作者のアドレス
Gerardo Giaretta Qualcomm
ヘラルドGiarettaクアルコム
EMail: gerardog@qualcomm.com
メール: gerardog@qualcomm.com
James Kempf DoCoMo Labs USA 181 Metro Drive San Jose, CA 95110 USA
ジェームスケンフDoCoMo研究室米国181地下鉄Driveカリフォルニア95110サンノゼ(米国)
EMail: kempf@docomolabs-usa.com
メール: kempf@docomolabs-usa.com
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
ビジェイDevarapalli Azaireは3121ジェイ・通りカリフォルニア95054サンタクララ(米国)をネットワークでつなぎます。
EMail: vijay.devarapalli@azairenet.com
メール: vijay.devarapalli@azairenet.com
Giaretta, et al. Standards Track [Page 27] RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
Giaretta、他 分裂シナリオ2007年10月に独力で進む標準化過程[27ページ]RFC5026MIP6
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を扱ってください。
Giaretta, et al. Standards Track [Page 28]
Giaretta、他 標準化過程[28ページ]
一覧
スポンサーリンク
