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
Mobile IPv6 Bootstrapping in Split Scenario
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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セキュリティアソシエーション。 RFC 3775は、これらの一部またはすべてが静的に設定されていることが必要です。この文書では、モバイルIPv6ノードが非トポロジ情報とセキュリティ資格情報の移動ノード上で事前に構成されたからこの情報をブートストラップする方法を定義します。この文書で定義されたソリューションは、分割シナリオは、モバイルノードのモビリティ・サービスは、基本的なネットワークアクセスとは異なるサービスプロバイダによって許可されている場合を指し、RFC 4640.にモバイルIPv6ブートストラップの問題文で説明したスプリットのシナリオを解決します。他のシナリオは、分割シナリオのより具体的な実現しているので、この文書に記載された溶液は、また、任意のブートストラップの場合に一般的に適用可能です。
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
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]はそのホームエージェントアドレス、自身のホームアドレス、および暗号材料を知っているモバイルノードを必要とする（例えば、共有鍵または証明書）に順番にホームエージェント（HA）とのIPsecセキュリティアソシエーションを設定するために必要なモバイルIPv6シグナリングを保護します。これは、一般的にモバイルIPv6ブートストラップ問題と呼ばれている[7]。
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ベースプロトコルは、ネットワーク管理者は、通常、手動でモバイルノードに設定データを設定したために必要とされることを意味し、この情報を自動的に取得する任意の方法を指定していません。しかし、実際の配備で、手動設定の数は、モバイルノードの増加として拡張できません。
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]、いくつかのブートストラップのシナリオは、ネットワークアクセスサービス（アクセス・サービス・オーソライザ、ASA）およびモバイルIPv6サービス（モビリティサービスを許可するサービスプロバイダを付与するための移動ノードを認証するネットワークオペレータとの間の関係に依存して特定することができます承認者、MSA）。この文書では、MSA及びASAは異なるエンティティ（すなわち、分割シナリオ）であるシナリオに適用可能であるブートストラップ問題の解決策を記載しています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
General mobility terminology can be found in [8]. The following additional terms are used here:
一般的なモビリティの用語は、[8]に記載されています。次の追加の用語をここで使用されています。
Access Service Authorizer (ASA)
アクセスサービスオーソライザ（ASA）
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パケット転送を提供するネットワークオペレータ。
Mobility Service Authorizer (MSA)
モビリティサービスオーソライザ（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と異なっていることを意味します。
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サービスを提供することができますコーヒーショップでのWi-Fiホットスポットのアカウント）。
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]で定義されたモデルは、認証し、ユーザを認証エンティティからサービスを提供するエンティティを分離します。これは、ネットワークアクセスのためのローミングモデルに似ています。したがって、分割シナリオでは、2つの異なるケースがモビリティ・サービスを提供するエンティティとの関係に応じて特定することができる（すなわち、モビリティサービスプロバイダMSP）と認証したユーザ（すなわち、モビリティ・サービス・オーソライザを許可エンティティMSA）。
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.
図1は、MSPおよびMSAは同じエンティティである分割シナリオを示します。これは、ホームエージェントを提供するネットワークオペレータは認証およびモビリティサービスをユーザーに許可することを意味します。
Mobility Service
Provider and Authorizer
+-------------------------------------------+
| |
| +-------------+ +--+ |
| | MSA/MSP AAA | <-------------> |HA| |
| | server | AAA protocol +--+ |
| +-------------+ |
| |
+-------------------------------------------+
+--+
|MN|
+--+
Figure 1 -- Split Scenario (MSA == MSP)
図1 - スプリットシナリオ（MSA == MSP）
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ネットワークから離れているとMSAは、任意のホームエージェントを提供することができない場合は、パフォーマンスを最適化したりするより近いHAを割り当てられ、そのユーザーにモビリティサービスを許可する第三者（すなわち、MSP）に依存している場合に発生する可能性があります。 MSPは、あるいはまた、ネットワーク・アクセス（すなわち、ASP、アクセスサービスプロバイダ）が提供しているネットワークオペレータではないかもしれないかもしれないことに注意してください。
Mobility Service
Authorizer
+-------------+
| MSA AAA |
| server |
+-------------+
^
|
AAA protocol |
| Mobility Service
| Provider
+--------|----------------------------------+
| V |
| +-------------+ +--+ |
| | MSP AAA | <-------------> |HA| |
| | server | AAA protocol +--+ |
| +-------------+ |
| |
+-------------------------------------------+
+--+
|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は、認証およびモビリティサービスのためのモバイルノードを認証するための認証、許可、アカウンティング（AAA）プロトコルの使用を前提としています。しかし、インターネット鍵交換プロトコル（IKEv2のは）のみ拡張認証プロトコル（EAP）クライアント認証可能で、サーバー認証は証明書や公開鍵に基づいて実行する必要がある、モバイルノードは、潜在的に証明書失効リストのチェック（CRLチェックを必要とするので）AAAプロトコルは、モビリティサービスのためのモバイルノードを認証および承認するために使用されていても。
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）が使用されている場合は、[9]モバイルノードとHAはお互いを認証するために証明書を使用し、関連する一切AAAサーバはありません。これは、ホームエージェントを除いて、MSP == MSAいるので、図1に概念的に類似しており、潜在的に
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.
モバイルノードは、認証局（CA）と証明書失効リストの確認（CRLチェックを）必要とするかもしれません。 CAは、MSPの内部または外部のいずれであってもよいです。図3はこれを示します。
Certification
Authority
+-------------+
| CA |
| server |
+-------------+
^
|
CRL Check |
| Mobility Service
| Provider and Authorizer
+--------|----------+
| V |
| +-------------+ |
| | HA | |
| | | |
| +-------------+ |
| |
+-------------------+
+--+
|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].
IKEv2の認証のためのPKIの使用に関する詳細については、[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]統合型アクセス・ネットワークの展開モデルにも適用することができます。
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.
ブートストラップ問題がモジュラー方法で独立して解くことができる異なるサブ問題で構成されています。コンポーネントを特定し、その解決策の概要は以下の通りです。
HA address discovery
はい住所disakaveri
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.
モバイルノードは、そのホームエージェントのアドレスを発見する必要があります。ブートストラップ溶液の主な目的は、モバイルノードに事前構成されたデータを最小にすることです。この理由のため、DHAADはで定義される[1]モバイルノードがホーム・ネットワーク・プレフィクスと事前に設定され、オペレータがモバイルノード動的に割り当てを有することによって、負荷を分散することができないことが要求されるので、実際の展開で適用可能でないかもしれません異なるサブネットにあるホームエージェントへ。この文書は、新しいDNS SRVレコードを導入し、ドメインネームサービス（DNS）に基づいており、ホームエージェントアドレス発見のためのソリューションを定義する[4]。モバイルノード上で事前に設定する必要があり、固有の情報は、MSPのドメイン名です。
IPsec Security Associations setup
IPsecセキュリティアソシエーションの設定
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は、モバイルノードとそのホームエージェントが結合更新やその他のモバイルIPv6シグナリングを保護するためにIPsecのSAを共有することが必要です。この文書では、IKEv2のに基づいているソリューションを提供し、[3]で指定されているものに従います。 IKEv2ピア認証は、両方の証明書を使用して、ネットワークオペレータの展開モデルに応じて、EAPを使用して行うことができます。
Home Address (HoA) assignment
ホームアドレス（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].
モバイルノードは、モバイルIPv6操作を起動するためにそのホームアドレスを知っている必要があります。 （[3]に記載されているように）ホームアドレスは、IKEv2の交換中に、ホームエージェントによって割り当てられます。この文書で定義された溶液は、ステートレス自動設定に基づいて自動設定し、そのホームアドレスにモバイルノードを可能に[11]、暗号化生成アドレス[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のピア認証時とバックエンドインフラ（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 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.
ブートストラップのオプションの一部は、モバイルノードが動的に割り当てられたホームアドレスとDNSに更新され、その完全修飾ドメイン名（FQDN）を持ってする方法を提供することを含みます。いないすべてのアプリケーションがこのサービスを必要としますが、多くのネットワーク・アプリケーションは、以前のそれとIPトラフィックを開始するノードのアドレスを取得するためにFQDNを使用します。この文書で定義されたソリューションは、ダイナミックDNSの更新が代わりに信頼関係に応じて、ホームエージェントによって、またはAAAインフラストラクチャを介して実行されることを指定します。
This section describes in detail the procedures needed to perform Mobile IPv6 bootstrapping based on the components identified in the previous section.
このセクションでは、詳細には、前のセクションで同定された成分に基づいて、モバイルIPv6ブートストラップを実行するために必要な手順が記載されています。
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.
モバイルノードは、ネットワークへのアクセスを取得した後は、モバイルIPv6のブートストラップを実行することができます。この目的のために、モバイルノードは、ホームエージェントサービスに関する情報を要求するために、DNSサーバーを照会します。文書で前に述べたように、モバイルノードは、モビリティサービスプロバイダのドメイン名を事前に設定する必要があります。
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.
モバイルノードは、DNS要求を送信する前に、DNSサーバーのIPアドレスを取得する必要があります。これは、モバイルノード上で設定または訪問リンク[14]からのDHCPv6によって得ることができます。いずれかの場合には、DNSサーバーは、多くの他の理由のために必要とされるので、移動ノードが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つのオプションは、この文書で識別されます。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.
この文書では、ホームエージェントのバランス異なるモバイルノードをロードするための具体的なメカニズムを提供しません。 MSPは、動的ホームエージェントのMSPのコレクションの現在の負荷を反映するために、SRV RRの優先順位を更新することにより、粗粒の負荷分散を実現することが可能です。モバイルノードは、優先的に最も負荷の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.
この文書はDNSに基づいてホームエージェントアドレスディスカバリー・ソリューションを指定しますがASPとMSPが同じエンティティである場合に、DHCPを使用することができます。詳細については、[15]を参照してください。
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.
この場合、モバイルノードは、ホームエージェントの完全修飾ドメイン名で構成されています。一例として、モバイルノードは、「example.com」モビリティ・サービスを許可するMSPのドメイン名である名称「ha1.example.com」と共に構成することができます。
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.
モバイルノードは、ホームエージェントの名前にQNAMEを設定することにより、DNS要求を構築します。 DNSサーバは、ホームエージェントのIPv6アドレスを送信するように要求がQTYPEは「AAAA」に設定されています。 DNSサーバーはこのクエリに応答すると、モバイルノードは、そのホームエージェントのアドレスを知っているとIPsec SAを設定し、ホームアドレスを取得するために、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の設定も動的に訪問先ネットワークからローカルホームエージェントを割り当てるために拡張することができることに注意してください。そのような動的割り当ては、双方向トンネリングモードでルーティング効率を向上させる観点から、例えば、有用であろう。ローカルホームエージェントを動的に割り当てるための機能強化や規則は、この仕様の範囲外です。
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.
RFC 2782 [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.
RFC 2782 [4]また、嗜好及び重み値に基づいて、サービス・エージェントを選択するポリシーを記述する。 DNS SRVレコードは、ホームエージェントのFQDNに加えて、モバイルノードに利用可能な複数のホームエージェントのための好みと体重の値が含まれる場合があります。複数のホームエージェントは、DNS SRVレコードで使用可能な場合には、モバイルノードは、ポリシーごとに一つのホームエージェントを選ぶための情報を処理するための責任があります。選択したホームエージェントは、IKE_SA_INITメッセージに応答しない場合、またはIKEv2の認証が失敗した場合、モバイルノードは、リスト上の次のホーム・エージェントを試す必要がある場合。ホームエージェント応答のいずれも場合は、モバイルノードは、移動ノード上で設定された時間の経過後にもう一度試してみてください。 IKEv2の認証がすべてのホームエージェントで失敗した場合、それは、モバイルノード上のエラーです。
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
RFC 2782で要求されるようモバイルIPv6ホームエージェントサービスのサービス名は、「MIP6」で、プロトコル名は、「IPv6の」です。そのAに注意してください。
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は一例として33のDNSタイプコードを持つ、モバイルSRVに「_mip6._ipv6.example.com」とQTYPEに設定QNAMEで要求を構築します。返信は、IPアドレスに別のDNSトランザクションで解決することができ、1台のまたは複数のサーバのFQDNが含まれています。 SRV応答に余裕がある場合は、それを解決するために、追加のDNSラウンドトリップを必要としないようにするためにDNSサーバは、追加データセクション（の一部としてAAAAレコードでホームエージェントのIPアドレスを返すことが推奨されますFQDN）。
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.
すぐにモバイルノードがホームエージェントのアドレスを発見したとして、それはホームエージェントのIKEv2を通じて自分自身とのIPsecセキュリティアソシエーションを確立します。この手順の詳細な説明は、[3]に設けられています。モバイルノードは、HAは、DNSでのホームアドレスを登録したい場合は、IKEv2の交換（IDiを）のIKE_AUTHステップでイニシエータIDとしてFQDNを使用しなければなりません。モバイルノードは、それがその後のDNSの更新オプションで提供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のモバイルノードのホームエージェントの認証にIKEv2の公開鍵署名または拡張認証プロトコル（EAP）のいずれかを使用して行うことができます。 IKEv2の認証を使用する方法については、に記載されている[3]、[5]。 IKEv2のピア認証方法の選択は、展開に依存します。モバイルノードは、IKEv2の認証方式を使用するかの情報で構成されるべきです。ただし、IKEv2のは、公開鍵署名ベースの認証を使用するようにモバイルノードの認証にホームエージェントを制限します。
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.
ホームアドレスの割り当ては、IKEv2の交換中に行われます。ホームアドレスは、ホームエージェントによって直接割り当てることができますまたはそれはモバイルノードによって自動設定することができます。
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 for the actual home address allocation. This is explained in detail in [3].
モバイルノードがホームエージェントとのIKEv2を実行すると、それはINTERNAL_IP6_ADDRESS属性を含めることによって、IKE_AUTH交換で設定ペイロードを通じてのHoAを要求することができます。ホーム・エージェントがメッセージを処理するときに、HoAをを割り当て、それをCFG_REPLYメッセージを送信します。ホームエージェントは、実際のホームアドレス割り当てのためのホームリンク上でDHCPサーバを参照してください可能性があります。これは、[3]に詳細に説明します。
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.
前のセクションで説明した割当のタイプと、ホームアドレスは、[12]暗号化生成アドレス（CGAs）に基づいて、またはステートレス自動設定のためのプライバシーの拡張に基づいて生成することができない[13]。しかし、モバイルノードは、これらのメカニズムに基づいて自動設定されたHoAを持っている場合があります。ホームエージェントが許さホームアドレスのプールでプロビジョニングされる場合がありますので、このセクションで説明する自動設定手順は、いくつかの可能な展開で使用することができないことを言及する価値があります。
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.
最も単純なケースでは、モバイルノードは事前構成されたホームプレフィックス及びホームプレフィックス長さを備えています。この場合、モバイルノードは、事前に設定されたプレフィックスに基づいて、ホームアドレスを作成し、型CFG_REQUESTの設定ペイロードでINTERNAL_IP6_ADDRESS属性を含め、ホームエージェントに送信します。ホームアドレスが有効であれば、ホームエージェントは、同じアドレスを持つINTERNAL_IP6_ADDRESS含め、CFG_REPLYで応答します。モバイルノードが提供するホームアドレスが有効でない場合、ホームエージェントは、新しい値でINTERNAL_IP6_ADDRESS属性を含むさまざまなホームアドレスを割り当てます。 [5]によると、モバイルノードは、ホームエージェントによって送信されたアドレスを使用する必要があります。モバイルノードは、（CGAに基づいて、例えば、）自動設定のホームアドレスを使用したい場合は、後で、それは、モバイルプレフィックスディスカバリーを実行する接頭辞を取得し、新しいホームアドレスを自動設定し、新しい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.
モバイルノードが事前に設定ホームプレフィックスが設けられていない場合は、モバイルノードがIKEv2の交換を開始する前に、ホームプレフィックスを知らないため、モバイルは、単に設定ペイロードに自動設定されたHoAを提案することはできません。それはホームアドレスを設定する前に、モバイルノードは、ホームプレフィックスとホームプレフィックス長を取得する必要があります。
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.
モバイルノードがちょうどホームリンク上のプレフィックス長が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 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.
モバイルノードがホームリンク上のプレフィックス長が64ビットであると仮定し、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.
このため、モバイルノードは、IKEv2の交換を通じてホームリンクプレフィックスを取得する必要があります。 IKE_AUTH交換時の設定ペイロードでは、モバイルノードはCFG_REQUESTメッセージにMIP6_HOME_PREFIX属性を含んでいます。それは、このメッセージを処理するホームエージェントは、ホームリンク上の1つのプレフィックスのCFG_REPLYペイロードプレフィックス情報に含まなければなりません。このプレフィックス情報は、プレフィックス長を（8.2節を参照）が含まれます。モバイルノードCFG_REPLYメッセージで返さプレフィックスからのホームアドレスを自動設定し、新しいホームアドレスのためのセキュリティアソシエーションを作成するために、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.
このドキュメントで前述したように、ホームアドレスの自動設定を使用することができない展開があります。ホームエージェントは、後続のIKE応答でMIP6_HOME_PREFIX属性が含まCFG_REQUESTを受信したときに、この場合、それは通知ペイロードタイプ「USE_ASSIGNED_HoA」とINTERNAL_IP6_ADDRESS属性に関連するホームアドレスを含んでいます。モバイルノードがMIP6_HOME_PREFIX属性を含む設定ペイロードに応じて「USE_ASSIGNED_HoAは、」通知ペイロードを取得した場合、それは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.
ホームエージェントは、モバイルノードのバインディング更新を受信すると、自動設定のホームアドレスのプロキシDADを実行します。 DADが失敗した場合、ホームエージェントはバインディング更新を拒否します。モバイルノードは、ステータス134（DADが失敗した）との結合肯定応答を受信した場合、それは新しいのHoAを設定し、現在のホームアドレスの使用を停止し、新しいのHoAに基づいてセキュリティアソシエーションを作成するためのIKEv2 CREATE_CHILD_SA交換を実行する必要があります。モバイルノードは、再びIKE_INITとIKE_AUTH交換を実行する必要はありません。必要なセキュリティアソシエーションが作成されると、モバイルノードは、新たなホームアドレスのバインディングアップデートを送信します。
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_HOME_PREFIX属性で運ばれたプレフィックス情報が一つだけの接頭辞が含まれており、IPv6ルータアドバタイズメントを介して受信したときに通常存在するすべての情報を運ばないことは注目に値します。モバイルプレフィックスの発見は、RFC 3775で指定され、モバイルノードがホームリンクと関連するすべての情報にすべてのプレフィックスを取得することができますするメカニズムです。それはMIP6_HOME_PREFIX属性のみがホームアドレスの自動設定のために使用され、RFC 3775で詳述の目的のために、モバイルプレフィックスディスカバリーの使用に代わるものではありませんことを意味します。
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.
ホームエージェントは、モバイルノードによって動的に検出されたシナリオでは、ホームエージェントは、自身でのIKEv2交換の間にモバイルノードによって提供された資格情報を確認することができない可能性が非常に高いです。また、モビリティサービスは、明示的にユーザーのプロファイルに基づいて許可する必要があります。例として、ホームエージェントは、モビリティサービスは、一日の特定の時間に付与することができるかどうかモバイルノードのクレジットが期限切れに起こっているときに気づいてないかもしれません。
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.
すべてのこれらの理由には、ホームエージェントは、モバイルノードを認証し、モビリティサービスを認可するために、MSAに連絡する必要があるかもしれません。これは、証明書が使用されている場合は、公開鍵インフラストラクチャに基づいて達成することができ、PKIは、MSPおよびMSAによって展開されます。モバイルノードが資格情報の他のタイプを備えている一方、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拡張を定義します。
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.
モバイルノードが動的に割り当てられたホームアドレス経由で到達可能であるようにするために、DNSは、新しいホームアドレスを更新する必要があります。アプリケーションはノードを見つけるために、FQDNにDNS検索を利用しているので、DNSの更新は、モバイルIPv6プロトコルの主な目的であるモバイルノードにIP到達可能性を提供するために不可欠です。それはモバイルノードが静的ホームアドレスがプロビジョニングされていることを前提としているのでDNS更新の必要性は、RFC 3775で説明されていません。しかし、動的なホームアドレスは、モバイルノードに割り当てられている場合、既存のDNSエントリが無効になり、DNSの更新が行われない限り、モバイルノードが到達不能になりました。
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サーバとのセキュリティアソシエーションを共有しなければなりません。 MSPのDNSサーバとセキュリティアソシエーションを共有するすべての可能なモバイルノードを持つことは、管理上の観点から、面倒かもしれません。また、モバイルノードは、その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エントリの更新を実行することをお勧めします
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).
モバイルノード。この目的のために、モバイルノードは、オプションで設定されていないフラグRとの結合更新の新しいモビリティオプション、DNSの更新オプションを含むことができます。このオプションは、第8項で定義され、更新する必要があるFQDNが含まれています。バインディングアップデートを受け取った後、ホームエージェントは、モバイルノードとホームアドレスオプションに含まホームアドレスが提供する識別子を持つDNSエントリを更新する必要があります。動的DNS更新メッセージを送信するための手順は、[6]で指定されています。動的DNS更新が安全な方法で行うべきです。このような理由のために、TKEYおよびTSECやDNSSECの使用方法（詳細は9.5節を参照）が推奨されます。すぐにホームエージェントは、DNSを更新したとして、それは、Statusフィールドに正しい値を持つDNSアップデートのモビリティオプション（8.1節を参照）を含め、モバイルノードにBinding Acknowledgementメッセージを送らなければなりません。
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.
ホームエージェントは、移動ノードの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].
モバイルノードは、MSA、ホームエージェントと更新されなければならないDNSサーバに属しているFQDNを通じて到達可能であることを望んでいる一方、異なる管理ドメインに属しています。この場合、ホームエージェントは、DNSサーバとDNSのエントリ更新とセキュリティアソシエーションは、MSAのAAAサーバによって実行することができる共有することはできません。これを実現するためには、ホームエージェントは、AAAプロトコルを介してAAAサーバにFQDN-HoAとペアを送信します。このメッセージは、MSPのAAAインフラストラクチャによってプロキシされ、MSAのAAAサーバによって受信されます。 MSAのAAAサーバは、[6]に基づいて、DNS更新を実行します。これは常にMSPのDNSサーバで実行されているので、この場合でも、ホームエージェントは、常に、逆エントリのための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エントリを削除するメカニズムが必要とされています。関連のホームアドレスがモバイルノードによって使用されなくなったとき、DNSエントリが古くなりません。 DNSエントリを削除するために、モバイルノードは、バインディング更新にオプションで設定されたフラグRとDNSアップデートモビリティオプションを含みます。バインディングアップデートを受け取った後、ホームエージェントは、モバイルノードとホームアドレスオプションに含まホームアドレスが提供するFQDNで識別されるDNSエントリを削除する必要があります。動的DNS更新メッセージを送信するための手順は、[6]で指定されています。上述したように、動的DNS更新が安全な方法で行うべきです。このような理由のために、TKEYおよびTSECやDNSSECの使用方法（詳細は9.5節を参照）が推奨されます。
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.
モバイルノードからの明示的な登録解除BUがない場合、HAは、DNSエントリを削除するトリガとしてバインディングキャッシュエントリの有効期限を使用するかもしれません。
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 |
+----+ +----+ +-----+
IKEv2 exchange
(HoA configuration)
<======================>
BU (DNS update option)
----------------------->
DNS update
<------------------->
BA (DNS update option)
<-----------------------
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|
+----+ +----+ +---+ +---+
IKEv2 exchange
(HoA configuration)
<======================>
BU (DNS update option)
----------------------->
AAA request
(FQDN, HoA)
<-------------->
DNS update
<----------->
AAA answer
(FQDN, HoA)
<-------------->
BA (DNS update option)
<-----------------------
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.
これは常にMSPのDNSサーバで実行されるためにも、この最後の場合には、ホームエージェントは、常に、逆エントリのための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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
DNS-UPDATE-TYPE (17)
DNS-UPDATE-TYPE（17）
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アップデートのモビリティオプションがBinding Updateメッセージに含まれている場合、このフィールドは0に設定され、受信機で無視しなければなりません。 DNSアップデートのモビリティオプションはBinding Acknowledgementメッセージに含まれている場合、Statusフィールド128未満の値は、ダイナミックDNSの更新がホームエージェントによって正常に実行されたことを示しています。 128以上の値は、動的DNS更新がHAによって完了しなかったことを示しています。以下のステータス値が現在定義されています：
0 DNS update performed
0 DNSの更新が行われ
128 Reason unspecified
指定されていない128の理由
129 Administratively prohibited
管理上禁止さ129
130 DNS update failed
130 DNSの更新に失敗しました
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.
設定されている場合、モバイルノードは、このオプションで指定されたFQDNとモバイルノードのHoAをで識別されるDNSエントリを削除するには、HAを要求しています。設定されていない場合は、モバイルノードは、そのHoAとオプションで指定されたFQDNとDNSエントリを作成または更新するためにHAを要求しています。
Reserved
予約済み
MUST be set to 0.
0に設定しなければなりません。
MN identity
Azntiから
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.
FQDN形式のモバイルノードのアイデンティティは、ダイナミックDNSアップデートを送信するためにホームエージェントによって使用されます。これは、可変長フィールドです。
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_HOME_PREFIX属性は、IKEv2の設定ペイロードメッセージで運ばれます。この属性は、モバイルノードのホームアドレスを自動設定し、そこからホームプレフィックスを伝えるために使用されます。
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 |
+-+-+-+-+-+-+-+-+
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_HOME_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.
値フィールドのオクテットの長さ（ホームプレフィックス、プレフィックスの有効期間とプレフィックス長）。これは、0または21ことができます。
Prefix Lifetime (4 octets)
プレフィックスの有効期間（4つのオクテット）
The lifetime of the Home Prefix.
ホームプレフィックスの寿命。
Home Prefix (16 octets)
ホームプレフィックス（16オクテット）
The prefix of the home link through which the Mobile Node may auto-configure its Home Address.
モバイルノードがホームアドレスを自動設定することができ、それを通してホームリンクの接頭語。
Prefix Length (1 octet)
プレフィックス長（1つのオクテット）
The length in bits of the home prefix specified in the field Home Prefix.
フィールドホームプレフィックスで指定したホームプレフィックスのビットの長さ。
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_HOME_PREFIX属性がCFG_REQUESTペイロードにモバイルノードによって含まれている場合は、Lengthフィールドの値が0 MIP6_HOME_PREFIX属性はホームエージェントによってCFG_REPLYペイロードに含まれている場合は、長さフィールドの値が21で、属性また、ホームプレフィックス情報が含まれています。
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.
モバイルノードは、モバイルIPv6サービスを確立するためにバインディングアップデートを実行する前にホームエージェントとIKEの取引を行うために必要とされているため、ケース1でのリスクが軽減されます。 IKEv2の仕様[5]によると、レスポンダは、応答者の公開鍵を含む有効な証明書、および証明書の公開鍵を使用して計算オーセンティケータで保護されなければならないIKE_AUTHメッセージを開始剤に対する応答と開始剤を提示しなければなりません。このため、攻撃者は被害者、移動ノードが検証できた証明書を使用して偽のDNSサーバと偽のホームエージェント、およびプロビジョニングホームエージェントの両方を設定する必要があります。モバイルノードは、証明書が信頼できないことを検出することができた場合、攻撃は、モバイルノードが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.
攻撃者がホームエージェントでの認証に適切な資格情報を所有していない場合はケース2におけるリスクは、ホームエージェントトランザクションに単一のモバイルノードのために限定されています。攻撃モバイルノードは、ホームエージェントで自身を認証しようとしたときに、IKE SAの確立は失敗します。モバイルノードは、有効な資格情報を持っていない限りかかわらず、ホームエージェントは、モバイルノードを認証するEAPまたはホスト側の証明書を利用するかどうかの、認証が失敗します。
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 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.
攻撃者がホームエージェントにサービス拒否（DoS）攻撃を伝播しようとすることができるので、別のリスクは、ケース2内に存在します。その場合、攻撃者がDNSからホームエージェントアドレスを取得し、その後、トラフィックをホームエージェントに衝突するホストを攻撃するネットワークにアドレスを伝播します。この攻撃は、しかし、それは任意のモバイルIPv6ホームエージェントのインストールが直面しているリスクは、実際には、ブートストラップ・ソリューションに固有のものではありません。実際には、リスクは、クライアントへのユニキャストグローバルにルーティング可能なアドレスを配布し、インターネットのいずれかのサービスが直面しています。モバイルIPv6は、モバイルノードがホームエージェントのグローバルにルーティング可能なユニキャストアドレスを介して通信することを必要とするので、ホームエージェントアドレスがモバイルノードにインストールされた様々な手段によって、攻撃者（モバイルノードの盗難、マルウェアに伝播する可能性があります、ホームアドレスを手動でモバイルノード上に構成されている場合でも、モバイルノードの所有者、彼/彼女自身、などの悪意）。その結果、すべてのモバイル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.
そのようなDNSSEC [19]またはTSIG / TKEY [20] [21]などのDNSサーバとホストとの間の明示的なセキュリティ対策は、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]で覆われています。
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の取引を通じてホームアドレスを割り当てます。モバイルノードは、DHCPに似たアドレスを、要求することを選択するか、またはモバイルノードは、アドレスを自動設定し、ホームリンク上のプレフィックスを要求することができます。
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:
RFC 3775 [1]はホームアドレスのホームエージェントチェック承認バインディング更新中に受信する必要があります。したがって、ホームエージェントは、各ホームアドレスの割り当てと使用を許可する必要があります。この権限は、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設定されたホームアドレス（複数可）。このモードでは、その背後にあるホーム・エージェントまたはインフラストラクチャのノードは、特定のモバイルノードが使用を許可されているアドレスを知っています。モバイルノードは、これらのアドレスを要求することが許可されている、またはモバイルノードがホームアドレスを要求した場合、これらのアドレスは、それに返されます。
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及び構成モードの両方が同じアドレス空間を使用する場合、要求されたアドレスが、すなわち、他の移動ノードの許可アドレスでないことを確認しなければなりません。
Security considerations for authentication of the IKE transaction using EAP are covered in [3] .
EAPを使用したIKEトランザクションの認証のためのセキュリティ上の考慮事項は、[3]で覆われています。
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]を参照してください。
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サーバーと直接モバイルノードに代わって、ダイナミックDNSの更新を実行する場合は、ホームエージェントは、DNSサーバといくつかの種類のセキュリティアソシエーションを持たなければなりません。セキュリティアソシエーションは、DNSSEC [19]またはTSIG / TKEY [20] [21]を使用してのいずれかで確立されてもよいです。セキュリティアソシエーションは、DNSサーバは、ホームエージェントと同じ管理ドメイン内にある場合でも必要です。セキュリティアソシエーションは、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.
モビリティサービスプロバイダは、モビリティサービスオーソライザと異なっている場合には、ネットワーク管理者は、クロス管理ドメインのセキュリティアソシエーションの数を制限することもできます。移動ノードのFQDNは、モビリティサービスオーソライザのドメイン内にある場合は、モビリティサービスの認可に関わるAAAシグナリングのためのセキュリティアソシエーションは、どのような場合に必要とされているので、ホームエージェントは、HA-AAAサーバの下でAAAサーバに移動ノードのFQDNを送信することができますセキュリティアソシエーション、およびAAAサーバが更新を実行することができます。その場合には、セキュリティ・アソシエーションは、動的DNS更新のためにAAAサーバとDNSサーバとの間で必要とされます。 AAAサーバインタフェースにホームエージェントのより深い議論については[16]を参照してください。
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.
かかわらず、AAAサーバまたはホームエージェントは、DNSの更新を実行するかどうかの、FQDNを更新するために、モバイルノードの許可は、更新前のパフォーマンスにチェックしなければなりません。それは、認可の決定方法へと実装の問題です。しかし、この認証ステップを可能にするために、モバイルノードは、IKEv2の交換のIDiをIKE_AUTHのステップとしてFQDNを使用しなければなりません。 FQDNがDNSアップデートオプションでモバイルノードによって提供される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バックエンドの通信を経由して移動ノードのFQDNについての認証情報を取得します。このステップの結果は、ホームエージェントにモバイルノードの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 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].
場合に証明書をIKEv2のに使用され、DNS更新のためのFQDNについての許可情報は、移動ノードによって提供される証明書に存在していなければなりません。 IKEv2の仕様は、必要な証明書の種類が含まれていないので、モバイルノードのFQDNが証明書に表示されます正確にどのように指定することはできません。証明書の種類がある場合は、一例として、「X.509証明書 - 署名」（推奨されるタイプのもの）、次にFQDNはのsubjectAltName属性エクステンション[23]に表示されてもよいです。
This document defines a new Mobility Option and a new IKEv2 Configuration Attribute Type.
この文書は、新しいモビリティオプションと新しいIKEv2の設定属性タイプを定義します。
The following values have been assigned:
以下の値が割り当てられています：
o from the "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE, 17 (Section 8.1)
O "モビリティオプション" 名前空間（[1]）から：DNS-UPDATE-TYPE、17（8.1節）
o from the "IKEv2 Configuration Payload Attribute Types" namespace ([5]): MIP6_HOME_PREFIX attribute, 16 (Section 8.2)
oから "のIKEv2設定ペイロードタイプ属性" 名前空間（[5]）：MIP6_HOME_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]）：USE_ASSIGNED_HoAエラータイプ、42（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アップデートモビリティオプション）」を作成します。電流値は、8.1節に記載されており、以下に列挙する。
0 DNS update performed
0 DNSの更新が行われ
128 Reason unspecified
指定されていない128の理由
129 Administratively prohibited
管理上禁止さ129
130 DNS update failed
130 DNSの更新に失敗しました
Future values of the Status field in the DNS Update mobility option can be allocated using Standards Action or IESG approval.
DNSアップデートのモビリティオプションのStatusフィールドの将来の値は、標準アクションまたはIESGの承認を使用して割り当てることができます。
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、アルパースYegin、Junghoonジヨン、ビジェイDevarapalli、Kuntal Chowdury、そしてジュリアンBournelleが含まれます。
The design team members can be reached at:
設計チームのメンバーはに到達することができます。
Gerardo Giaretta, gerardog@qualcomm.com
ヘラルドGiaretta、gerardog@qualcomm.com
Basavaraj Patil, basavaraj.patil@nokia.com
Bsvrajパティル、बसवराज.पाटिल@नोकिआ.कॉम
Alpesh Patel, alpesh@cisco.com
Alpeshパテル、अल्पेश@सिस्को.कॉम
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
アルパースYeğin、alper.yegin@samsung.co
Vijay Devarapalli, vijay.devarapalli@azairenet.com
ビジェイdevarapalli、విజయ్.దేవరపల్లి@అజయరెన్ట్.కం
Kuntal Chowdury, kchowdury@starentnetworks.com
キンタルChaudry、कचौदर्य@स्टॉरेंट्नेटवर्कस.कॉम
Junghoon Jee, jhjee@etri.re.kr
Junghoonジヨン、jhjee@etri.re.kr
Julien Bournelle, julien.bournelle@gmail.com
ジュリアンBournelle、julien.bournelle@gmail.com
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.
作者は彼らの貴重なコメントのためにラファ・ロペス、フランシスデュポン、ヤリArkko、キリアンWeniger、Vidyaナラヤナン、竜二Wakikawa、そしてマイケル・イェジンに感謝したいと思います。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[3] Devarapalli、V.とF.デュポン、RFC 4877、2007年4月 "のIKEv2および改訂のIPsecアーキテクチャとのモバイルIPv6の操作"。
[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のSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[5]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、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.
[6]、RFC 2136 "ドメインネームシステム（DNS更新）における動的更新" いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、4月1997。
[7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[7]パテル、A.およびG. Giaretta、RFC 4640、2006年9月 "ブートストラップモバイルIPv6（MIPv6の）のための問題文"。
[8] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[8]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、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）"、RFC 4210、2005年9月。
[10] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[10]コーバー、B.、RFC 4945、2007年8月 "のIKEv1 / ISAKMP、IKEv2の、およびPKIXのインターネットIPセキュリティPKIプロファイル"。
[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）のための近隣探索"、RFC 4861、2007年9月。
[12] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[12]オーラ、T.、 "暗号化生成アドレス（CGA）"、RFC 3972、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におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[14] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[14] Droms、R.、RFC 3646、2003年12月の "IPv6のための動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。
[15] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, June 2007.
[15]チョードリー、K.とA. Yegin、 "統合シナリオのためのMIP6-ブートストラップ"、進歩、2007年6月に作業。
[16] Giaretta, G., "AAA Goals for Mobile IPv6", Work in Progress, September 2006.
[16] Giaretta、G.、 "モバイルIPv6のためのAAAの目標"、進歩、2006年9月での作業。
[17] Chowdhury, K., "RADIUS Mobile IPv6 Support", Work in Progress, March 2007.
[17]チョードリー、K.、 "RADIUSモバイルIPv6のサポート"、進歩、2007年3月に作業。
[18] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support", Work in Progress, May 2007.
[18] Bournelle、J.、 "直径モバイルIPv6：HA < - > HAAAサポート"、進歩、2007年5月での作業。
[19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[19]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[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）"、RFC 2845、2000年5月。
[21] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[21]イーストレイク、D.、 "DNSのための秘密鍵確立（TKEYのRR）"、RFC 2930、2000年9月。
[22] Jang, H., "DHCP Option for Home Information Discovery in MIPv6", Work in Progress, June 2007.
[22]チャン、H.、 "MIPv6のホーム情報発見のためのDHCPオプション"、進歩、2007年6月に作業。
[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.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、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
ジェームズ・ケンプドコモ研究所USA 181メトロドライブサンノゼ、CA 95110 USA
EMail: kempf@docomolabs-usa.com
メールアドレス：kempf@docomolabs-usa.com
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
ビジェイDevarapalli Azaireネットワーク3121ジェイ・ストリートサンタクララ、CA 95054 USA
EMail: vijay.devarapalli@azairenet.com
メールアドレス：vijay.devarapalli@azairenet.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。