[要約] 要約：RFC 5026は、モバイルIPv6のブートストラップを分割シナリオで行うための手法を提案しています。 目的：このRFCの目的は、モバイルIPv6ネットワークでのブートストラッププロセスを改善し、モバイルデバイスのシームレスな移動をサポートすることです。
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
スプリットシナリオでのモバイル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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（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）を付与するためのモバイルノードを認証するネットワークオペレーター間の関係に応じて、いくつかのブートストラップシナリオを特定できます。Authorizer、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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サービスを提供できます。コーヒーショップの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]で定義されているモデルは、ユーザーを認証および承認するエンティティからサービスを提供するエンティティを分離します。これは、ネットワークアクセスのローミングモデルに似ています。したがって、分割シナリオでは、モビリティサービス（つまり、モビリティサービスプロバイダー、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)
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ネットワークから遠く、パフォーマンスを最適化するためにより近いHAを割り当てられている場合、またはMSAがホームエージェントを提供できず、サードパーティ（つまり、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)
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 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.
代わりに、公開キーインフラストラクチャ（PKI）が使用されている場合、モバイルノードとHAは証明書を使用して互いに認証され、AAAサーバーは関与していません[9]。これは、Homeエージェントを除くMSP == MSA、および潜在的にモバイルノードを除くMSP == MSAには、認定機関（CA）の証明書取消リストチェック（CRLチェック）が必要になる場合があるため、図1と概念的に類似しています。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
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.
モバイルノードは、ホームエージェントのアドレスを発見する必要があります。ブートストラップソリューションの主な目的は、モバイルノードで事前に構成されたデータを最小限に抑えることです。このため、[1]で定義されているDHAADは、モバイルノードがホームネットワークプレフィックスと事前に構成され、モバイルノードを動的に割り当ててモバイルノードを使用してオペレーターがバランスを読み込むことを許可しないため、実際の展開に適用できない場合があります。異なるサブネットにあるホームエージェントに。このドキュメントでは、ドメイン名サービス（DNS）に基づいたホームエージェントアドレス発見のソリューションを定義し、新しいDNS SRVレコードを導入します[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操作をブートストラップするために、自宅の住所を知る必要があります。ホームアドレスは、IKEV2交換中にホームエージェントによって割り当てられます（[3]で説明されています）。このドキュメントで定義されているソリューションにより、モバイルノードは、ステートレスの自動構成[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.
ブートストラップのオプションの部分には、モバイルノードが完全に適格なドメイン名（FQDN）をDNSで動的に割り当てられたホームアドレスを更新する方法を提供することが含まれます。すべてのアプリケーションがこのサービスを必要とするわけではありませんが、多くのネットワーキングアプリケーションはFQDNを使用して、IPトラフィックを開始する前にノードのアドレスを取得します。このドキュメントで定義されているソリューションは、動的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サーバーが必要であるため、モバイルノードが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つのオプションが特定されています。Homeエージェント名による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がSRV RR優先順位を動的に更新して、MSPのホームエージェントのコレクションの現在の負荷を反映することにより、粗粒の負荷分散を実現することができます。その後、モバイルノードは優先メカニズムを使用して、ロードされていない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.
この場合、モバイルノードは、ホームエージェントの完全に適格なドメイン名で構成されています。例として、モバイルノードは「ha1.example.com」という名前で構成できます。ここで、「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.
モバイルノードは、QNameをホームエージェントの名前に設定することにより、DNS要求を構築します。リクエストにはQTYPEが「AAAA」に設定されているため、DNSサーバーがホームエージェントのIPv6アドレスを送信します。DNSサーバーがこのクエリに返信すると、モバイルノードはホームエージェントアドレスを知っており、IPSEC SASをセットアップしてホームアドレスを取得するために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レコードには、ホームエージェントFQDNSに加えて、モバイルノードが利用できる複数のホームエージェントの好みと重量値が含まれている場合があります。DNS SRVレコードで複数のホームエージェントが利用できる場合、モバイルノードは、ポリシーに従って情報を処理し、1人のホームエージェントを選択する責任があります。選択したホームエージェントが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 transport name cannot be used here because Mobile IPv6 does not run over a transport protocol.
RFC 2782で要求されるモバイルIPv6ホームエージェントサービスのサービス名は「MIP6」であり、プロトコル名は「IPv6」です。モバイル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です。例として、モバイルはQNAMEを「_MIP6._IPv6.example.com」に設定してリクエストを構築し、QTypeをSRVに構成します。返信には、1つ以上のサーバーのFQDNSが含まれており、IPアドレスへの別のDNSトランザクションで解決できます。ただし、SRVの返信にスペースがある場合は、DNSサーバーが追加データセクションの一部としてAAAAレコードのホームエージェントのIPアドレスを返すことをお勧めします（解決するために追加のDNSラウンドトリップが必要であることを避けるためにfqdns）。
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にホームアドレスを登録することを望んでいる場合、FQDNをIKEV2 Exchange（IDI）のIKE_AUTHステップで開始者IDとして使用する必要があります。これは、モバイルノードが後続の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 Exchangeの構成ペイロードを介して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.
前のセクションで説明されている割り当てのタイプでは、暗号化されたアドレス（CGA）[12]に基づいて、またはステートレス自動構成のためのプライバシー拡張機能[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タイプの構成ペイロードに内部_IP6_ADDRESS属性を含むホームエージェントに送信します。ホームアドレスが有効な場合、ホームエージェントは、同じアドレスを持つInternal_IP6_Addressを含むCFG_REPLYで返信します。モバイルノードが提供するホームアドレスが有効でない場合、ホームエージェントは、新しい値を持つ内部_IP6_ADDRESS属性を含む別のホームアドレスを割り当てます。[5]によると、モバイルノードはホームエージェントから送信されたアドレスを使用する必要があります。後で、モバイルノードが自動構成のホームアドレスを使用する場合（たとえば、CGAに基づいて）、モバイルプレフィックス発見を実行し、プレフィックスを取得し、新しいホームアドレスを自動構成してから、新しいCreate_Child_SA Exchangeを実行できます。
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 Exchangeの開始前にホームプレフィックスを知らないため、モバイルは構成ペイロードで自動構成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.
簡単なソリューションの1つは、モバイルノードがホームリンクのプレフィックスの長さが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ペイロード内の内部_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 Exchangeを介してホームリンクのプレフィックスを取得する必要があります。IKE_AUTH Exchange中の構成ペイロードでは、モバイルノードにはCFG_REQUESTメッセージにMIP6_HOME_PREFIX属性が含まれます。ホームエージェントは、このメッセージを処理する場合、ホームリンクの1つのプレフィックスのCFG_REPLYペイロードプレフィックス情報に含める必要があります。このプレフィックス情報には、プレフィックスの長さが含まれています（セクション8.2を参照）。モバイルノードは、CFG_REPLYメッセージで返されたプレフィックスのホームアドレスを自動構成し、CREATE_CHILD_SA Exchangeを実行して新しいホームアドレスのセキュリティアソシエーションを作成します。
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を受信すると、Notify Payload Type "use_assigned_hoa"およびInternal_ip6_address属性の関連ホームアドレスが含まれます。モバイルノードが「use_assigned_hoa」を取得した場合、mip6_home_prefix属性を含む構成ペイロードに応答してペイロードを通知する場合、内部_ip6_address属性を探し、後続のcreate_child_sa Exchangeに含まれるアドレスを使用する必要があります。
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を実行します。お父さんが失敗した場合、ホームエージェントはバインディングアップデートを拒否します。モバイルノードがステータス134（お父さんが失敗した）で拘束力のある承認を受信した場合、現在のホームアドレスの使用を停止し、新しいHOAを構成し、IKEV2 create_child_sa Exchangeを実行して新しいHOAに基づいてセキュリティ関連を作成する必要があります。モバイルノードは、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属性に含まれるプレフィックス情報には、1つのプレフィックスのみが含まれており、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エクスチェンジ中にモバイルノードによって提供される資格情報を独自に検証できない可能性が非常に高いです。さらに、モビリティサービスは、ユーザーのプロフィールに基づいて明示的に承認される必要があります。例として、ホームエージェントは、モビリティサービスが1日の特定の時期に付与できるかどうか、またはモバイルノードのクレジットが期限切れになるかどうかを認識していない場合があります。
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]は、バックエンド通信の半径と直径の拡張をそれぞれ定義します。
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ルックアップを使用してノードを見つけるため、モバイルノードにIPリーチ性を提供するためにはDNSアップデートが不可欠です。これはモバイルIPv6プロトコルの主な目的です。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 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).
したがって、セキュリティと管理上の理由により、ホームエージェントはモバイルノードのDNSエントリアップデートを実行することをお勧めします。この目的のために、モバイルノードには、バインディングアップデートに新しいモビリティオプション、DNSアップデートオプションが含まれている場合があり、フラグRはオプションに設定されていません。このオプションはセクション8で定義されており、更新する必要があるFQDNが含まれています。バインディングアップデートを受信した後、ホームエージェントは、モバイルノードが提供する識別子とホームアドレスオプションに含まれるホームアドレスでDNSエントリを更新する必要があります。動的DNS更新メッセージを送信する手順は、[6]で指定されています。動的DNSアップデートは安全な方法で実行する必要があります。このため、TKEYとTSECまたはDNSSECの使用法をお勧めします（詳細については、セクション9.5を参照）。ホームエージェントがDNSを更新するとすぐに、ステータスフィールドに正しい値を持つDNS更新モビリティオプションを含む、モバイルノードにバインディング確認メッセージを送信する必要があります（セクション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.
この手順は、ホームエージェントがモバイルノードの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に属するFQDNを介して到達可能になりたい場合、更新する必要があるホームエージェントとDNSサーバーは、異なる管理ドメインに属します。この場合、ホームエージェントは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エントリを削除するには、モバイルノードにバインディングアップデートに、DNS更新モビリティオプションをオプションに設定した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更新モビリティオプションがバインディングアップデートメッセージに含まれている場合、0に設定し、受信機によって無視する必要があります。DNSアップデートモビリティオプションがバインディング確認メッセージに含まれている場合、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.
設定されている場合、モバイルノードはHAに、このオプションで指定されたFQDNとモバイルノードのHOAで識別されたDNSエントリを削除するように要求しています。設定されていない場合、モバイルノードはHAにHOAとオプションで指定されたFQDNを使用してDNSエントリを作成または更新するように要求しています。
Reserved
予約済み
MUST be set to 0.
0に設定する必要があります。
MN identity
MNアイデンティティ
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.
動的なDNSアップデートを送信するためにホームエージェントが使用するFQDN形式のモバイルノードのID。可変長さフィールドです。
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ペイロードのモバイルノードに含まれている場合、長さフィールドの値は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トランザクションを実施するために必要であるため、緩和されます。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攻撃は、IKEV2トランザクション中にフォイルする必要があります。IKEV2の実装は、保存された状態なしでCookieを生成し、頻繁にクッキー生成パラメーターを頻繁に生成することが期待され、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のリスクを軽減できますが、これらのセキュリティ対策はエンドノードに広く展開されていません。ただし、これらのセキュリティ対策は、DOS攻撃に対してホームエージェントアドレスを保護するのに十分ではありません。これは、DNSサーバーとの正当なセキュリティ関連を持つノードは、それにもかかわらず、ホームエージェントアドレスを意図的または不注意に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認証プロセスとホームアドレスで使用されるモバイルノードIDのリンクに基づいています。ホームエージェントは、少なくとも次の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.
アドレスは、少なくともバインディングが存在する限り使用されているようにマークされ、割り当てを行ったモバイルノードのIDに関連付けられている必要があります。
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.
さらに、ホームエージェントは、要求されたアドレスが他のモバイルノードの承認されたアドレスではないことを確認する必要があります。つまり、FCFと構成されたモードの両方が同じアドレススペースを使用している場合です。
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シグナル伝達のセキュリティ協会が必要である場合、ホームエージェントはモバイルノードのFQDNをHA-AAAサーバーの下のAAAサーバーに送信できますセキュリティ協会、および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 ExchangeのIKE_AUTHステップのIDIとして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 Exchangeで実行される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証明書 - 署名」（推奨タイプの1つ）の場合、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アップデートモビリティオプションのステータスフィールドの将来の値は、標準アクションまたは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 Patil、Alpesh Patel、Jari Arkko、James Kempf、Yoshihiro Ohba、Gopal Dommety、Alper Yegin、Junghoon Jee、Vijay Devarapalli、Kuntal Chowdury、およびJulien Bournelleが含まれます。
The design team members can be reached at:
デザインチームのメンバーには、
Gerardo Giaretta, gerardog@qualcomm.com
Gerardo Giaretta、gerardog@qualcomm.com
Basavaraj Patil, basavaraj.patil@nokia.com
Basavaraj Patil、basavaraj.patil@nokia.com
Alpesh Patel, alpesh@cisco.com
Alpesh Patel、alpesh@cisco.com
Jari Arkko, jari.arkko@kolumbus.fi
Jari Arkko、jari.arkko@kolumbus.fi
James Kempf, kempf@docomolabs-usa.com
James Kempf、kempf@docomolabs-usa.com
Yoshihiro Ohba, yohba@tari.toshiba.com
Yoshihiro Ohba、Yohba@tari.toshiba.com
Gopal Dommety, gdommety@cisco.com
Gopal dommety、gdommety@cisco.com
Alper Yegin, alper.yegin@samsung.com
Alper Yegin、alper.yegin@samsung.com
Vijay Devarapalli, vijay.devarapalli@azairenet.com
Vijay Devarapalli、vijay.devarapalli@azairenet.com
Kuntal Chowdury, kchowdury@starentnetworks.com
Kuntal Chowdury、kchowdury@starentnetworks.com
Junghoon Jee, jhjee@etri.re.kr
Junghoon Jee、jhjee@etri.re.kr
Julien Bournelle, julien.bournelle@gmail.com
Julien 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.
著者は、Rafa Lopez、Francis Dupont、Jari Arkko、Kilian Weniger、Vidya Narayanan、Ryuji Wakikawa、Michael Yeに貴重なコメントに感謝したいと思います。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson、D.、Perkins、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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. Dupont、「IKEV2および改訂されたIPSECアーキテクチャによるモバイルIPv6操作」、RFC 4877、2007年4月。
[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）」、RFC 2782、2000年2月。
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[5] Kaufman、C。、「Internet Key Exchange（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] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[7] Patel、A。およびG. Giaretta、「モバイルIPv6（MIPV6）のブートストラップの問題声明」、RFC 4640、2006年9月。
[8] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[8] Mather、J。およびM. Kojo、「Mobility関連用語」、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] Adams、C.、Farrell、S.、Kause、T。、およびT. Mononen、「Internet 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] Korver、B。、「IKEV1/ISAKMP、IKEV2、およびPKIXのインターネットIPセキュリティPKIプロファイル」、RFC 4945、2007年8月。
[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.、Simpson、W。、およびH. Soliman、「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. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、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。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[15] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, June 2007.
[15] Chowdhury、K。およびA. Yegin、「統合シナリオのMIP6-BOOTSTRAPPING」、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] Chowdhury、K。、「Radius Mobile IPv6 Support」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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.、Gudmundsson、O.、Eastlake、D。、およびB. Wellington、「DNSのSecret Key Transaction Authentication（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] Jang、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.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
Authors' Addresses
著者のアドレス
Gerardo Giaretta Qualcomm
ジェラルド・ジアレッタ・クアルコム
EMail: gerardog@qualcomm.com
James Kempf DoCoMo Labs USA 181 Metro Drive San Jose, CA 95110 USA
James Kempf Docomo Labs USA 181 Metro Drive San Jose、CA 95110 USA
EMail: kempf@docomolabs-usa.com
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara、CA 95054 USA
EMail: vijay.devarapalli@azairenet.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。