[要約] RFC 4433は、Mobile IPv4における動的なホームエージェント（HA）の割り当てに関する仕様です。このRFCの目的は、モバイルノードがネットワーク内で動作する際に、動的にHAを割り当てるための手順とプロトコルを提供することです。
Network Working Group M. Kulkarni
Request for Comments: 4433 A. Patel
Category: Standards Track K. Leung
Cisco Systems Inc.
March 2006
Mobile IPv4 Dynamic Home Agent (HA) Assignment
モバイルIPv4ダイナミックホームエージェント（HA）割り当て
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection.
モバイルIPv4（RFC 3344）は、ホームエージェント（HA）を使用して、ローミングモバイルノード（MN）のセッションをアンカーします。このドキュメントは、動的ホームエージェントの割り当てとHAリダイレクトのメッセージングメカニズムを提案しています。目標は、HA選択に適した方法を許可しながら、モバイルIPセッションに最適なHAを割り当てるメカニズムを提供することです。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Terminology ........................................3
3. Problem Statement ...............................................5
3.1. Scope ......................................................5
3.2. Dynamic Home Agent Discovery in Mobile IPv4 ................5
3.3. NAI Usage and Dynamic HA Assignment ........................6
3.4. Dynamic HA Extension .......................................6
3.4.1. Requested HA Extension ..............................7
3.4.2. Redirected HA Extension .............................7
4. Messaging Mechanism for Dynamic HA Assignment/Redirection .......7
4.1. Messaging for Dynamic HA Assignment ........................7
4.1.1. Example with Message Flow Diagram ...................8
4.2. Messaging for HA Redirection ..............................10
4.2.1. Example with Message Flow Diagram ..................12
5. Mobility Agent Considerations ..................................14
5.1. Mobile Node Considerations ................................14
5.1.1. MN Using FA CoA ....................................14
5.1.2. MN Using Co-Located CoA ............................15
5.1.3. Refreshing Assigned HA Address on Mobile Node ......16
5.2. Foreign Agent Considerations ..............................16
5.3. Home Agent Considerations .................................17
5.3.1. Assigned Home Agent Considerations .................17
6. Requested Home Agent Selection .................................19
7. Error Values ...................................................20
8. IANA Considerations ............................................20
9. Security Considerations ........................................20
10. Backward-Compatibility Considerations .........................21
11. Acknowledgements ..............................................23
12. Normative References ..........................................23
This document adds to the Mobile IP protocol [1], by proposing a messaging mechanism for dynamic home agent assignment and home agent redirection during initial registration. The goal is to assign an optimal HA for a Mobile IP session. The mobile node MUST use the Network Access Identifier (NAI) extension [2] when requesting a dynamically assigned HA.
このドキュメントは、最初の登録中に動的ホームエージェントの割り当てとホームエージェントのリダイレクトのメッセージングメカニズムを提案することにより、モバイルIPプロトコル[1]に追加されます。目標は、モバイルIPセッションに最適なHAを割り当てることです。モバイルノードは、動的に割り当てられたHAを要求するときに、ネットワークアクセス識別子（NAI）拡張機能[2]を使用する必要があります。
The MN requests a dynamically assigned HA by setting the HA field in the initial Registration Request to ALL-ZERO-ONE-ADDR (defined in Section 2). If the request is accepted, the HA sends a successful Registration Reply containing the HA's own address. The requested HA can suggest an alternate HA and if so, the Registration Reply is rejected with a new error code REDIRECT-HA-REQ and the alternate HA address is specified in a new extension (Redirected HA Extension).
MNは、最初の登録要求でHAフィールドをAll-Zero-One-ADDRに設定することにより、動的に割り当てられたHAを要求します（セクション2で定義）。リクエストが受け入れられた場合、HAはHA独自の住所を含む登録返信を成功させます。要求されたHAは代替HAを提案できます。もしそうなら、登録返信は新しいエラーコードRedirect-HA-Reqで拒否され、代替HAアドレスは新しい拡張機能（リダイレクトHA拡張）で指定されます。
This document also defines a new Requested HA Extension for use in Registration Requests when the HA field is set to ALL-ZERO-ONE-ADDR. The Requested HA address is a hint to the network about the MN's preferred HA.
このドキュメントでは、HAフィールドがAll-Zero-One-ADDRに設定されている場合、登録要求で使用するための新しい要求されたHA拡張機能も定義しています。要求されたHAアドレスは、MNの好みのHAに関するネットワークへのヒントです。
The messaging mechanism is defined in this document so that the MN can request and receive a dynamic HA address in Mobile IP messages. However, the mechanism by which the network selects an HA for assignment to the MN is outside the scope of this document. For example, the selection may be made by any network node that receives the Registration Request (or information about the Registration Request), such as a Foreign Agent, AAA server, or home agent. The node that selects the HA may select one based on a number of criteria, including but not limited to HA load-balancing, geographical proximity, administrative policy, etc.
メッセージングメカニズムは、このドキュメントで定義されているため、MNはモバイルIPメッセージで動的なHAアドレスを要求および受信できます。ただし、ネットワークがMNへの割り当てのHAを選択するメカニズムは、このドキュメントの範囲外です。たとえば、選択は、外国人エージェント、AAAサーバー、ホームエージェントなど、登録要求（または登録リクエストに関する情報）を受信するネットワークノードによって行うことができます。HAを選択するノードは、HAロードバランス、地理的近接、管理ポリシーなどを含むがこれらに限定されない多くの基準に基づいて選択できます。
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 [6].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [6]に記載されているように解釈される。
The Mobile-IP-related terminology described in RFC 3344 [1] is used in this document. In addition, the following terms are used:
RFC 3344 [1]で説明されているモバイルIP関連の用語は、このドキュメントで使用されています。さらに、次の用語が使用されます。
ALL-ZERO-ONE-ADDR: IP address 0.0.0.0 or 255.255.255.255. An address of 255.255.255.255 indicates a preference for an HA in the home domain. An address of 0.0.0.0 indicates no preference for home vs. visited domain.
All-Zero-One-ADDR：IPアドレス0.0.0.0または255.255.255.255。255.255.255.255のアドレスは、ホームドメインのHAの好みを示しています。0.0.0.0のアドレスは、訪問ドメインと訪問ドメインの好みがないことを示します。
Requested HA: Destination IP address of home agent that the Registration Request is sent to. Must be a unicast IP address. This address can be obtained as described in Section 6.
リクエストha：登録要求が送信されるホームエージェントの宛先IPアドレス。ユニキャストIPアドレスである必要があります。このアドレスは、セクション6で説明されているように取得できます。
Note that this specification defines a new "Requested HA Extension" in Section 3.4, which is different from the term "Requested HA".
この仕様は、セクション3.4の新しい「要求されたHA拡張」を定義していることに注意してください。これは、「要求されたHA」という用語とは異なります。
Assigned HA: The HA that accepts an MN's Registration Request and returns a successful Registration Reply.
HAの割り当て：MNの登録要求を受け入れ、登録の成功した返信を返します。
Redirected HA: If the registration is rejected with error code REDIRECT-HA-REQ, the HA being referred to is specified in a new extension (Redirected HA Extension).
リダイレクトHA：登録がエラーコードリダイレクトHA-REQで拒否された場合、参照されるHAは新しい拡張機能（リダイレクトHA拡張）で指定されます。
AAA server: Authentication, Authorization, and Accounting Server.
AAAサーバー：認証、承認、および会計サーバー。
DNS: Domain Name System.
DNS：ドメイン名システム。
DHCP: Dynamic Host Configuration Protocol.
DHCP：動的ホスト構成プロトコル。
MN: Mobile node as defined in Mobile IPv4 [1].
MN：モバイルIPv4 [1]で定義されているモバイルノード。
HA: Home agent as defined in Mobile IPv4 [1].
HA：モバイルIPv4で定義されているホームエージェント[1]。
FA: Foreign Agent as defined in Mobile IPv4 [1].
FA：モバイルIPv4で定義されている外国エージェント[1]。
CoA: Care-of Address.
COA：住所の世話。
CCoA: Co-located Care-of Address.
CCOA：共同主よ、住所。
MN HoA: Mobile node's home address.
MN HOA：モバイルノードのホームアドレス。
NAI: Network Access Identifier [2].
NAI：ネットワークアクセス識別子[2]。
Src IP: Source IP address of the packet.
SRC IP：パケットのソースIPアドレス。
Dest IP: Destination IP address of the packet.
Dest IP：パケットの宛先IPアドレス。
RRQ: Registration Request.
RRQ：登録リクエスト。
The Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept of identifying an MN by the NAI and enabling dynamic home address assignment. When the home address is dynamically assigned, it is desirable to discover the home agent dynamically or inform the MN about an optimal HA to use for a multitude of reasons, such as:
IPv4 [2]のモバイルIPv4 NAI拡張機能は、NAIによってMNを識別し、動的ホームアドレスの割り当てを可能にするという概念を導入しました。ホームアドレスが動的に割り当てられている場合、ホームエージェントを動的に発見するか、次のようなさまざまな理由で使用する最適なHAについてMNに通知することが望ましいです。
- If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. In such a case, the MN will be anchored to its distant home agent, resulting in tunneled traffic traveling a long distance between home agent and the mobile node. When a Mobile IP session initiates, if the mobile node can be assigned a home agent that is close to the mobile node it can drastically reduce the latency between the home agent and mobile node.
- 訪問されたネットワークとモバイルノードのホームネットワーク間の距離が大きい場合、これらの登録のシグナリング遅延は長い場合があります。そのような場合、MNは遠くのホームエージェントに固定され、その結果、トンネル交通はホームエージェントとモバイルノードの間の長距離を移動します。モバイルIPセッションが開始されると、モバイルノードにモバイルノードに近いホームエージェントを割り当てることができる場合、ホームエージェントとモバイルノードの間の遅延を大幅に減らすことができます。
- In a large-scale Mobile IP deployment, it is cumbersome to provision MNs with multiple HA addresses.
- 大規模なモバイルIP展開では、複数のHAアドレスを持つMNSをプロビジョニングするのは面倒です。
- It is desirable to achieve some form of load balancing between multiple HAs in the network. Dynamic HA assignment and/or HA redirection lets the network select the optimal HA from among a set of HAs and thus achieve load balancing among a group of HAs.
- ネットワーク内の複数の間の何らかの形の負荷分散を達成することが望ましいです。動的HAの割り当ておよび/またはHAリダイレクトにより、ネットワークはHASのセットの中から最適なHAを選択できるため、HAのグループ間で負荷分散を達成できます。
- Local administrative policies.
- ローカル管理ポリシー。
This specification does not address the problem of distributing a security association between the MN and HA, and it can either be statically preconfigured or dynamically distributed using other mechanisms [7].
この仕様は、MNとHAの間にセキュリティ関連を分配する問題に対処するものではなく、他のメカニズムを使用して静的に事前に設定されるか、動的に分布することができます[7]。
The document introduces the terms Requested/Assigned/Redirected HA (Section 6). The discovery of candidate HA addresses for insertion into the Redirected HA Extension can be accomplished through various means that are network and/or deployment specific and hence are outside the scope of this specification.
このドキュメントでは、要求/割り当て/リダイレクトHA（セクション6）という用語を紹介します。リダイレクトされたHA拡張に挿入するための候補HAアドレスの発見は、ネットワークおよび/または展開固有のさまざまな手段を通じて達成でき、したがってこの仕様の範囲外です。
The MN MAY request dynamic HA assignment when it is not aware of any HA address and even when it is aware of at least one HA address.
MNは、HAアドレスを認識していない場合、および少なくとも1つのHAアドレスを認識している場合でも、動的HAの割り当てを要求する場合があります。
Mobile IPv4 [1] specifies the mechanism for discovering the mobile node's home agent using subnet-directed broadcast IP address in the home agent field of the Registration Request. This mechanism was designed for mobile nodes with a static home address and subnet prefix, anchored on fixed home network. However, using subnet-directed broadcast as the destination IP address of the Registration Request, it is unlikely that the Registration Request will reach the home subnet because routers will drop these packets by default. See CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks [3].
モバイルIPv4 [1]は、登録要求のホームエージェントフィールドでサブネット指向のブロードキャストIPアドレスを使用して、モバイルノードのホームエージェントを発見するためのメカニズムを指定します。このメカニズムは、固定ホームネットワークに固定された静的ホームアドレスとサブネットプレフィックスを備えたモバイルノード向けに設計されました。ただし、登録要求の宛先IPアドレスとしてSubnet-Directedブロードキャストを使用すると、ルーターがデフォルトでこれらのパケットをドロップするため、登録要求がホームサブネットに届くことはほとんどありません。CERT Advisory CA-1998-01 Smurf IP拒否攻撃[3]を参照してください。
The Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept of identifying an MN by the NAI and enabling dynamic home address assignment. This document requires that while using dynamic HA assignment, MN MUST use the NAI and obtain a home address. MN can still suggest a static home address in the Registration Request, but must take the address in the Registration Reply as the home address for the session. This is compatible with the procedures documented in the NAI specification [2].
IPv4 [2]のモバイルIPv4 NAI拡張機能は、NAIによってMNを識別し、動的ホームアドレスの割り当てを可能にするという概念を導入しました。このドキュメントでは、動的HA割り当てを使用している間、MNはNAIを使用して自宅の住所を取得する必要があります。MNは引き続き登録リクエストで静的ホームアドレスを提案できますが、セッションのホームアドレスとして登録返信の住所を取得する必要があります。これは、NAI仕様[2]に文書化された手順と互換性があります。
The Dynamic HA Extension, shown in Figure 1, contains the address of the HA. This is a generic extension and can be used in Registration Request and Reply messages. It is a skippable extension.
図1に示す動的HA拡張には、HAのアドレスが含まれています。これは一般的な拡張機能であり、登録リクエストと返信メッセージで使用できます。スキップ可能な拡張機能です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Dynamic HA Address Extension
図1：動的HAアドレス拡張
Type DYNAMIC-HA-ADDRESS (skippable) 139 is the type, which specifies the dynamic HA address.
型Dynamic-Ha-Address（skippable）139はタイプで、動的HAアドレスを指定します。
Subtype Defines the use of this extension as: subtype 1 = Requested HA Extension 2 = Redirected HA Extension
サブタイプは、この拡張機能の使用を次のように定義します。サブタイプ1 =要求されたha拡張機能2 =リダイレクトha拡張
Length Indicates the length of the extension not including the type, subtype, and length fields. Length is always 4 bytes.
長さは、タイプ、サブタイプ、および長さフィールドを含まない拡張機能の長さを示します。長さは常に4バイトです。
HA-Address Address of the home agent.
ホームエージェントのha-addressアドレス。
The Requested HA Extension is a Dynamic HA Extension of subtype 1.
要求されたHA拡張は、サブタイプ1の動的HA拡張です。
The MN may include the Requested HA Extension in the Registration Request as a hint to the network where it wishes to be anchored.
MNには、登録要求に要求されたHA拡張機能を含めることができます。
This extension contains the address of the HA. A valid unicast IP address MUST be used as HA address in this extension.
この拡張機能には、HAのアドレスが含まれています。この拡張機能の有効なユニキャストIPアドレスをHAアドレスとして使用する必要があります。
In absence of an FA, the Registration Request is forwarded to this HA. In presence of an FA, the FA MUST forward the Registration Request to the HA address in this extension.
FAがない場合、登録要求はこのHAに転送されます。FAが存在する場合、FAはこの拡張機能のHAアドレスに登録要求を転送する必要があります。
The Redirected HA Extension is a Dynamic HA Extension of subtype 2.
リダイレクトされたHA拡張は、サブタイプ2の動的HA拡張です。
The Redirected HA Extension contains the address of the HA where the MN should attempt the next registration. The HA receiving a Registration Request can suggest an alternate HA and, if so, the Registration Reply is sent with a new error code REDIRECT-HA-REQ and the alternate HA address is specified in this extension.
リダイレクトされたHA拡張には、MNが次の登録を試みるHAのアドレスが含まれています。登録リクエストを受信するHAは、代替HAを提案できます。もしそうなら、登録返信は新しいエラーコードRedirect-HA-Reqで送信され、この拡張機能では代替HAアドレスが指定されます。
The Redirected HA Extension MUST be included in Registration Reply when the reply code is REDIRECT-HA-REQ.
返信コードがRedirect-HA-Reqである場合、リダイレクトされたHA拡張機能を登録返信に含める必要があります。
This specification presents two alternatives for home agent assignment:
この仕様は、ホームエージェントの割り当ての2つの選択肢を示しています。
(a) Dynamic HA assignment (described in Section 4.1) and (b) HA redirection (described in Section 4.2).
(a) 動的HAの割り当て（セクション4.1で説明）および（b）HAリダイレクト（セクション4.2で説明）。
The following sequence of events occurs when the MN requests dynamic home agent assignment:
次の一連のイベントは、MNが動的ホームエージェントの割り当てを要求するときに発生します。
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. If the MN is aware of a desired HA address, it can add that address in the Requested HA Extension in the Registration Request. If the HA does not support the Requested HA Extension, see step 2 below.
1. MNは、登録要求でホームエージェントアドレスフィールドをAll-Zero-One-Addrに設定します。MNが目的のHAアドレスを認識している場合、登録要求に要求されたHA拡張機能にそのアドレスを追加できます。HAが要求されたHA拡張機能をサポートしていない場合は、以下のステップ2を参照してください。
2. This step is applicable, in lieu of step 1, for an MN that is aware of the HA address and desires dynamic HA assignment. Also, the MN follows this (when aware of a HA address) when it discovers a legacy FA in the path or if the known HA does not support the Requested HA Extension (see Section 10).
2. このステップは、ステップ1の代わりに、HAアドレスを認識し、ダイナミックなHAの割り当てを望んでいるMNに適用されます。また、MNは、パスでレガシーFAを発見した場合、または既知のHAが要求されたHA拡張をサポートしていない場合（HAアドレスを認識する場合）これに従います（セクション10を参照）。
The MN sets the Home Agent address field in the Registration Request to the HA address (instead of setting it to ALL-ZERO-ONE-ADDR). The MN also adds the same HA address in the Requested HA Extension in the Registration Request.
MNは、HAアドレスへの登録要求でホームエージェントアドレスフィールドを設定します（All-Zero-One-ADDRに設定する代わりに）。MNは、登録要求に要求されたHA拡張機能に同じHAアドレスを追加します。
3. The MN (if using co-located CoA and registering directly with the HA) or the FA (if the MN is registering via the FA) sends the Registration Request to the "Requested HA". If the Requested HA Extension is present, Requested HA is specified in the "HA Address" of this extension.
3. MN（共同配置COAを使用してHAに直接登録する場合）またはFA（MNがFAを介して登録している場合）は、登録要求を「要求されたHA」に送信します。要求されたHA拡張機能が存在する場合、要求されたHAは、この拡張機能の「HAアドレス」で指定されています。
Per Section 10, in case of a legacy FA, legacy FA forwards the Registration Request to the address in the HA field of the request (thus, MN uses step 2 above in case of legacy FA instead of step 1).
セクション10ごとに、レガシーFAの場合、レガシーFAは登録要求をリクエストのHAフィールドの住所に転送します（したがって、MNはステップ1の代わりにレガシーFAの場合に上記のステップ2を使用します）。
4. The "Requested HA" is the home agent that processes the Registration Request in accordance with Mobile IPv4 [1] and as per the specification in this document. It creates mobility binding for a successful Registration Request. It also sends a Registration Reply to the MN.
4. 「要求されたHA」は、モバイルIPv4 [1]に従って登録要求を処理するホームエージェントであり、このドキュメントの仕様に従って。登録リクエストを成功させるためにモビリティバインディングを作成します。また、MNへの登録返信も送信します。
5. The MN obtains an "Assigned HA" address from the HA field in the successful Registration Reply and uses it for the remainder of the session. (Note that the "Assigned HA" will be the same as the "Requested HA".)
5. MNは、成功した登録返信でHAフィールドから「割り当てられたHA」アドレスを取得し、セッションの残りの期間に使用します。（「割り当てられたha」は「要求されたha」と同じであることに注意してください。）
6. Subsequent Registration Request messages for renewal are sent to the Assigned HA.
6. その後の更新のための登録要求メッセージは、割り当てられたHAに送信されます。
Section 5.3.1 describes the Assigned HA in detail. Some ideas on how to select the Requested HA are briefly covered in Section 6.
セクション5.3.1では、割り当てられたHAを詳細に説明します。要求されたHAを選択する方法に関するいくつかのアイデアについては、セクション6で簡単に説明します。
Detailed explanation of this alternative is best described with the help of a message flow diagram and description.
この代替案の詳細な説明は、メッセージフロー図と説明の助けを借りて最もよく説明されています。
Figure 2 shows one specific example of a mobile node using an FA-located Care-of Address (FA CoA) and FA understands the Requested HA Extension per this specification.
図2は、FA-Located Care of Care of Care of Care（FA COA）を使用したモバイルノードの特定の例を示し、FAはこの仕様に従って要求されたHA拡張を理解しています。
Other scenarios such as when the mobile node uses a co-located care of address and presence of a legacy HA or FA are not described below, but the behavior is similar.
モバイルノードが住所の共同配置されたケアを使用し、レガシーHAまたはFAの存在を使用する場合など、他のシナリオは以下では説明されていませんが、動作は類似しています。
MN FA Requested/Assigned HA
| 1 | |
|------------>| 2 |
| |--------------->|
| | |
| | |
| | 3 |
| 4 |<---------------|
|<------------| |
| | |
| | 5 |
|----------------------------->|
| | |
Figure 2: Example Message Flow for Dynamic HA Assignment
図2：動的ha割り当てのためのメッセージフローの例
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. Since the MN is using FA CoA in this example, it sends the Registration Request to the FA. The Registration Request is formatted as follows:
1. MNは、登録要求でホームエージェントアドレスフィールドをAll-Zero-One-Addrに設定します。MNはこの例でFA COAを使用しているため、登録要求をFAに送信します。登録リクエストは次のようにフォーマットされます。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
If the MN is aware of a desired HA address, it can add that address in the Requested HA Extension in Registration Request as a hint. That extension is not shown above.
MNが目的のHAアドレスを認識している場合、ヒントとして登録要求の要求されたHA拡張機能のアドレスを追加できます。その拡張機能は上に示されていません。
2. The FA sends the Registration Request to the Requested HA. If the Requested HA Extension is present, Requested HA is the HA address in this extension. If the Requested HA Extension is not present, the FA determines the Requested HA through means outside the scope of this specification. The Registration Request is formatted as follows:
2. FAは、登録要求を要求されたHAに送信します。要求されたHA拡張機能が存在する場合、要求されたHAはこの拡張機能のHAアドレスです。要求されたHA拡張が存在しない場合、FAはこの仕様の範囲外の平均を通じて要求されたHAを決定します。登録リクエストは次のようにフォーマットされます。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
(If MN includes the Requested HA Extension, the FA copies that
extension. The FA then forwards the Registration Request, along
with the Requested HA Extension, to the HA address specified in
Requested HA Extension.)
3. The HA processes the Registration Request in accordance with Mobile IPv4 [1] and the messaging defined in this document. The HA creates mobility binding for successful request and becomes the Assigned HA. The HA then sends a Registration Reply to the FA, which is formatted as follows:
3. HAは、モバイルIPv4 [1]とこのドキュメントで定義されているメッセージングに従って登録要求を処理します。HAは、リクエストを成功させるためにモビリティバインディングを作成し、割り当てられたHAになります。その後、HAはFAへの登録返信を送信します。これは次のようにフォーマットされています。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
|Assigned| Src IP of | | Assigned HA |FA CoA/|
| HA | the RRQ | | | |
+-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows:
4. FAは、次のように、MNへの登録返信を中継します。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | Assigned HA |FA CoA/|
+-----------------------------------------------------------+
5. The MN obtains the Assigned HA address from the HA field in the successful Registration Reply and uses it for the remainder of the session. The MN sends subsequent Re-Registration or De-Registration Requests for the remainder session directly to the Assigned HA. The Home Agent address field in this Registration Request is set to ALL-ZERO-ONE-ADDR. Note that the Assigned HA is the same as the Requested HA.
5. MNは、成功した登録返信でHAフィールドから割り当てられたHAアドレスを取得し、セッションの残りの部分でそれを使用します。MNは、残りのセッションの後続の再登録または登録解除要求を、割り当てられたHAに直接送信します。この登録要求のホームエージェントアドレスフィールドは、すべてゼロ1-One-ADDRに設定されています。割り当てられたHAは、要求されたHAと同じであることに注意してください。
This section describes the events that occur when the Requested HA does not accept the Registration Request and redirects the mobile node to another HA (aka Redirected HA) instead. This behavior is not exhibited by a legacy HA and so is not referred in the description below. In presence of a legacy FA, please refer to Section 4.1 for the specific field in the Registration Request.
このセクションでは、要求されたHAが登録要求を受け入れず、代わりにモバイルノードを別のHA（別名リダイレクトHA）にリダイレクトした場合に発生するイベントについて説明します。この動作はレガシーHAによって示されていないため、以下の説明には参照されません。レガシーFAの存在下では、登録リクエストの特定のフィールドについては、セクション4.1を参照してください。
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR.
1. MNは、登録要求でホームエージェントアドレスフィールドをAll-Zero-One-Addrに設定します。
2. The MN (if using co-located CoA and registering directly with the HA) or FA (if the MN is registering via the FA) sends the Registration Request to the "Requested HA". If the MN is aware of an HA address, it can add that address in the Requested HA Extension in the Registration Request.
2. MN（Co-Located COAを使用してHAに直接登録する場合）またはFA（MNがFAを介して登録している場合）は、登録要求を「要求されたHA」に送信します。MNがHAアドレスを認識している場合、登録要求に要求されたHA拡張機能にそのアドレスを追加できます。
3. When the HA receives the Registration Request, if the HA field is set to ALL-ZERO-ONE-ADDR, the HA may reject the request with Reply code REDIRECT-HA-REQ and suggest an alternate HA.
3. HAが登録要求を受信すると、HAフィールドがAll-Zero-One-ADDRに設定されている場合、HAはReply Code Redirect-HA-Reqでリクエストを拒否し、代替HAを提案する場合があります。
The HA may reject the request for a number of reasons, which are outside the scope of this specification. If the HA rejects the Request, the HA field in the Reply is set to this HA's address. The IP address of the HA that is the target of the redirection is specified in Redirected HA Extension. The presence of this extension is mandatory when the reply code is set to REDIRECT-HA-REQ. HA sends the Reply to the FA/MN.
HAは、この仕様の範囲外であるいくつかの理由で要求を拒否する場合があります。HAがリクエストを拒否した場合、返信のHAフィールドがこのHAのアドレスに設定されます。リダイレクトのターゲットであるHAのIPアドレスは、リダイレクトHA拡張で指定されています。この拡張機能の存在は、返信コードがHa-Reqをリダイレクトするように設定されている場合に必須です。HAはFA/MNに返信を送信します。
4. FA sends the Reply to the MN.
4. FAはMNに返信を送信します。
5. If the error code is set to REDIRECT-HA-REQ, the MN obtains the HA address from Redirected HA Extension. The MN then sends a Registration Request to Redirected HA. The MN may choose to add Requested HA Extension in this new Registration Request. If a registration loop occurs (the case when the Redirected HA is an HA that had already directed the MN to register elsewhere), then the MN stops sending any further Registration Request and provides an indication that the loop event was detected. The number of consecutive Redirected HAs remembered by the MN for loop detection is an implementation parameter.
5. エラーコードがリダイレクトHA-Reqに設定されている場合、MNはリダイレクトされたHA拡張からHAアドレスを取得します。MNは、リダイレクトHAに登録リクエストを送信します。MNは、この新しい登録リクエストに要求されたHA拡張機能を追加することを選択できます。登録ループが発生した場合（リダイレクトされたHAが既にMNを他の場所に登録するように指示した場合）、MNはさらなる登録要求の送信を停止し、ループイベントが検出されたことを示しています。ループ検出のためのMNで記憶されている連続したリダイレクトの数は、実装パラメーターです。
Figure 3 shows one specific example of a mobile node using FA-located Care-of Address, where the FA is not a legacy FA.
図3は、FAに配置されたケアオブアドレスを使用したモバイルノードの1つの具体的な例を示しています。FAはレガシーFAではありません。
MN FA Requested HA Redirected HA
| 1 | | |
|------------>| 2 | |
| |--------------->| |
| | | |
| | | |
| | 3 | |
| 4 |<---------------| |
|<------------| | |
| | | |
| | 5 | |
|--------------------------------------------->|
| | | |
Figure 3: Example Message Flow for HA Redirection
図3：HAリダイレクトのメッセージフローの例
1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. Since the MN is using FA CoA in this example, it sends the Registration Request to the FA. The Registration Request is formatted as follows:
1. MNは、登録要求でホームエージェントアドレスフィールドをAll-Zero-One-Addrに設定します。MNはこの例でFA COAを使用しているため、登録要求をFAに送信します。登録リクエストは次のようにフォーマットされます。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
If the MN is aware of an HA address, it can add that address in the Requested HA Extension in the Registration Request as a hint. That extension is not shown above.
MNがHAアドレスを認識している場合、登録要求の要求されたHA拡張機能のアドレスをヒントとして追加できます。その拡張機能は上に示されていません。
2. The FA sends the Registration Request to the Requested HA. If Requested HA Extension is present, Requested HA is the HA address in this extension. If the Requested HA Extension is not present, the FA determines the Requested HA through means outside the scope of this specification. The Registration Request is formatted as follows:
2. FAは、登録要求を要求されたHAに送信します。要求されたHA拡張機能が存在する場合、要求されたHAはこの拡張機能のHAアドレスです。要求されたHA拡張が存在しない場合、FAはこの仕様の範囲外の平均を通じて要求されたHAを決定します。登録リクエストは次のようにフォーマットされます。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
3. The HA processes the Registration Request in accordance with Mobile IPv4 [1] and the messaging defined in this specification. If the registration is successful, but local configuration/administrative policy, etc., directs the HA to refer the MN to another HA, the HA rejects the request with error code REDIRECT-HA-REQ. The HA fills in the address of the Redirected HA in the Redirected HA Extension. The HA then sends Registration Reply reject to the FA, which is formatted as follows:
3. HAは、モバイルIPv4 [1]とこの仕様で定義されているメッセージングに従って登録要求を処理します。登録が成功しましたが、ローカル構成/管理ポリシーなどは、HAにMNを別のHAに照会するよう指示する場合、HAはエラーコードRedirect-HA-Reqで要求を拒否します。HAは、リダイレクトされたHA拡張のリダイレクトHAのアドレスを埋めます。HAは次に、登録返信を送信します。FAに拒否されます。これは次のようにフォーマットされています。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| | Src IP of | | HA |FA CoA |
| HA | the RRQ | | | |
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows:
4. FAは、次のように、MNへの登録返信を中継します。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | HA |FA CoA/|
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+
5. If the MN can authenticate the Reply, the MN extracts the HA address from the Redirected HA Extension. The MN then sends a Registration Request to the Redirected HA, unless it has already received a redirection response from that HA while processing the Registration Request. The MN may choose to add Requested HA Extension in this new Registration Request.
5. MNが応答を認証できる場合、MNはリダイレクトされたHA拡張からHAアドレスを抽出します。MNは、登録リクエストの処理中にそのHAからリダイレクト応答を既に受け取っていない限り、リダイレクトHAに登録要求を送信します。MNは、この新しい登録リクエストに要求されたHA拡張機能を追加することを選択できます。
The following sections describe the behavior of each mobility agent in detail.
次のセクションでは、各モビリティエージェントの動作について詳しく説明します。
The mobile node MUST use the NAI extension for home address assignment when using the messaging mechanism in this document. Since MN uses the NAI extension, the Home Address field is set to 0.0.0.0.
このドキュメントでメッセージングメカニズムを使用する場合、モバイルノードはホームアドレスの割り当てにNAI拡張機能を使用する必要があります。MNはNAI拡張機能を使用するため、ホームアドレスフィールドは0.0.0.0に設定されています。
While dynamic HA assignment is in progress and the MN has not successfully anchored at a home agent, the MN MUST set the Home Agent field in the Registration Request to an ALL-ZERO-ONE-ADDR, which is either 255.255.255.255 or 0.0.0.0.
動的HAの割り当てが進行中であり、MNはホームエージェントに正常に固定されていませんが、MNは登録要求でホームエージェントフィールドをAll-Zero-One-ADDRに設定する必要があります。これは255.255.255.255または0.0です。0.0。
The Registration Request MUST be protected by a valid authenticator as specified in Mobile IPv4 [1] or Mobile IPv4 Challenge/Response Extensions [5]. Configuring security associations is deployment specific and hence outside the scope of this specification. The security associations between an MN and an individual HA may also be dynamically derived during the dynamic HA assignment, based on a shared secret between MN and AAA infrastructure [7].
登録リクエストは、モバイルIPv4 [1]またはモバイルIPv4チャレンジ/応答拡張[5]で指定されている有効な認証器によって保護する必要があります。セキュリティ協会の構成は展開固有であり、したがってこの仕様の範囲外です。MNとAAAインフラストラクチャ間の共有秘密に基づいて、MNと個々のHAの間のセキュリティ関連は、動的HAの割り当て中に動的に導出される場合があります[7]。
The mobile node MUST maintain the remaining Mobile IP session with the Assigned HA.
モバイルノードは、割り当てられたHAで残りのモバイルIPセッションを維持する必要があります。
As mentioned in the Security Considerations (Section 9), there is a possibility of more than one HA creating a mobility binding entry for a given MN, if a rogue node in the middle captures the Registration Request and forwards it to other home agents. The MN can mitigate such condition by using a short lifetime (e.g., 5 seconds) in the Registration Request with the Home Agent field set to ALL-ZERO-ONE-ADDR.
セキュリティ上の考慮事項（セクション9）で述べたように、中央の不正なノードが登録要求をキャプチャし、他のホームエージェントに転送する場合、特定のMNのモビリティバインディングエントリを作成する可能性が複数あります。MNは、ホームエージェントフィールドをAll-Zero-One-ADDRに設定した登録リクエストで短い寿命（5秒）を使用することにより、そのような状態を軽減できます。
The following sections describe MN behavior in FA CoA mode and co-located CoA mode.
次のセクションでは、FA COAモードと共同住宅COAモードのMNの動作について説明します。
When a mobile node initiates a Mobile IP session requesting dynamic HA assignment, it MUST set the home agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. The destination IP address of the Registration Request is the FA. The FA will determine the Requested HA and forward the Registration Request to the Requested HA. Registration Request processing takes place on the Requested HA as per the specification in this document.
モバイルノードが動的なHA割り当てを要求するモバイルIPセッションを開始する場合、登録リクエストでホームエージェントアドレスフィールドをAll-Zero-One-ADDRに設定する必要があります。登録要求の宛先IPアドレスはFAです。FAは要求されたHAを決定し、登録要求を要求されたHAに転送します。登録要求処理は、このドキュメントの仕様に従って、要求されたHAで行われます。
The Registration Request MUST be appropriately authenticated for the HA to validate the Request.
登録要求は、HAがリクエストを検証するために適切に認証される必要があります。
If a successful Registration Reply is received, the MN obtains the Assigned HA from the HA field of Reply. The Assigned HA address will be the same as the Requested HA Extension, if it was included in the Registration Request by the MN.
登録返信が成功した場合、MNは返信のHAフィールドから割り当てられたHAを取得します。割り当てられたHAアドレスは、MNによる登録要求に含まれている場合、要求されたHA拡張機能と同じです。
If a Registration Reply is received with code REDIRECT-HA-REQ, the MN MUST authenticate the Reply based on HA address in HA field of Reply and attempt Registration with the HA address specified in the Redirected HA Extension. The MN MUST put the Redirected HA address as the Requested HA Extension of the new Registration Request.
登録返信がコードRedirect-HA-Reqで受信された場合、MNは、リダイレクトHA拡張で指定されたHAアドレスのHAアドレスに基づいて返信を認証する必要があります。MNは、新しい登録リクエストの要求されたHA延長として、リダイレクトされたHAアドレスを配置する必要があります。
In some cases, for the first Registration Request the MN may want to hint to the network to be anchored at a specific HA. The MN SHOULD put that address in the HA address of the Requested HA Extension.
場合によっては、最初の登録リクエストのために、MNは特定のHAに固定されるようにネットワークに示唆したい場合があります。MNは、要求されたHA拡張のHAアドレスにそのアドレスを配置する必要があります。
An MN in co-located CoA mode requesting dynamic HA assignment MUST set the home agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. The destination IP address of the Registration Request is the Requested HA. Some ideas on how to select a Requested HA are briefly covered in Section 6.
動的HAの割り当てを要求する共同配置COAモードのMNは、登録要求でホームエージェントアドレスフィールドをAll-Zero-One-ADDRに設定する必要があります。登録要求の宛先IPアドレスは、要求されたHAです。要求されたHAを選択する方法に関するいくつかのアイデアについては、セクション6で簡単に説明します。
If a successful Reply is received, the MN obtains the Assigned HA address from the successful Registration Reply. The Assigned HA will be the same as Requested HA to which the Registration Request was sent. The MN MUST cache the Assigned HA address for the length of the Mobile IP session. The mobile node then MUST use this previously cached Assigned HA address as the home agent address in subsequent Re-Registration and De-Registration Request(s). This will make sure that for the duration of the Mobile IP session, the mobile node will always be anchored to the assigned home agent with which it was initially registered.
成功した返信を受け取った場合、MNは登録の成功した返信から割り当てられたHAアドレスを取得します。割り当てられたHAは、登録要求が送信された要求HAと同じです。MNは、モバイルIPセッションの長さに対して割り当てられたHAアドレスをキャッシュする必要があります。その後、モバイルノードは、以前のキャッシュされた割り当てられたHAアドレスを、その後の再登録および登録解除リクエストでホームエージェントアドレスとして使用する必要があります。これにより、モバイルIPセッションの期間中、モバイルノードが常に最初に登録された割り当てられたホームエージェントに固定されることを確認します。
If a Registration Reply is received with code REDIRECT-HA-REQ, the MN MUST authenticate the Reply based on HA address in HA field of Reply and attempt Registration with the HA address specified in the Redirected HA Extension. The MN MUST put the Redirected HA in the Requested HA Extension of the new Registration Request.
登録返信がコードRedirect-HA-Reqで受信された場合、MNは、リダイレクトHA拡張で指定されたHAアドレスのHAアドレスに基づいて返信を認証する必要があります。MNは、新しい登録要求の要求されたHA拡張にリダイレクトされたHAを配置する必要があります。
In some cases, for the first Registration Request MN may want to hint to the network to be anchored at a specific HA and the MN SHOULD put that address in the HA address of the Requested HA Extension.
場合によっては、最初の登録要求の場合、MNは特定のHAに固定されるようにネットワークに示唆したい場合があり、MNは要求されたHA拡張のHAアドレスにそのアドレスを配置する必要があります。
While requesting dynamic HA assignment and registering directly with an HA, the Requested HA Extension MUST be included and MUST contain the address of the HA to which the Registration Request is sent. When using co-located CoA but registering via a legacy FA, the HA field in the Registration Request may be set to Requested HA.
動的なHAの割り当てを要求し、HAに直接登録している間、要求されたHA拡張機能を含める必要があり、登録要求が送信されるHAのアドレスを含める必要があります。共同配列COAを使用しているが、レガシーFAを介して登録する場合、登録要求のHAフィールドを要求するHAに設定することができます。
If the Registration Request contains the Requested HA Extension, the HA address in that extension MUST match the destination IP of the Request.
登録要求に要求されたHA拡張機能が含まれている場合、その拡張機能のHAアドレスは、リクエストの宛先IPと一致する必要があります。
When the Mobile IP session terminates, the mobile node MAY clear the Assigned HA address cached as the home agent address. It MAY request a new HA address for the new Mobile IP session by not including the Requested HA Extension. The advantage of this approach is that the mobile node will be always anchored to an optimal home agent from where it initiated the Mobile IP session.
モバイルIPセッションが終了すると、モバイルノードは、ホームエージェントアドレスとしてキャッシュされた割り当てられたHAアドレスをクリアする場合があります。要求されたHA拡張機能を含めないことにより、新しいモバイルIPセッションの新しいHAアドレスを要求する場合があります。このアプローチの利点は、モバイルノードが常にモバイルIPセッションを開始した最適なホームエージェントに固定されることです。
Alternately, the MN may save the Assigned HA address and use it in the Requested HA Extension along with ALL-ZERO-ONE-ADDR HA address in Registration Request for a new Mobile IP session.
あるいは、MNは割り当てられたHAアドレスを保存し、新しいモバイルIPセッションの登録リクエストで、すべてゼロ1-One-ADDR HAアドレスとともに要求されたHA拡張機能で使用する場合があります。
When the mobile node is using an FA CoA, it always registers via the FA. When the MN is using a co-located CoA, it may register through an FA or it may register directly with an HA, unless the R bit is set in the FA's agent advertisement, in which case it always registers through the FA.
モバイルノードがFA COAを使用している場合、常にFAを介して登録します。MNが共同配置COAを使用している場合、FAのエージェント広告にRビットが設定されていない限り、FAを介して登録するか、HAに直接登録する場合があります。
When the FA receives a Registration Request with HA address field set to ALL-ZERO-ONE-ADDR that doesn't contain the Requested HA Extension, the FA obtains the Requested HA address to forward the Registration Request using means outside the scope of this specification. Some ideas on how to select a Requested HA are briefly covered in Section 6.
FAが要求されたHA拡張機能を含まないAll-Zero-One-ADDRに設定されたHAアドレスフィールドを使用して登録要求を受け取った場合、FAはこの仕様の範囲外の平均を使用して登録要求を転送するために要求されたHAアドレスを取得します。要求されたHAを選択する方法に関するいくつかのアイデアについては、セクション6で簡単に説明します。
If the FA cannot obtain the Requested HA to which to forward a Registration Request from the MN, it MUST reject request with error code NONZERO-HA-REQD.
FAがMNから登録要求を転送するために要求されたHAを取得できない場合、エラーコードNon Zero-HA-Reqdでリクエストを拒否する必要があります。
If the MN has included the Requested HA Extension, the FA MUST forward the Registration Request to the address in this extension. If the HA address in this extension is not a routable unicast address, the FA MUST reject the request with error code NONZERO-HA-REQD.
MNに要求されたHA拡張機能が含まれている場合、FAはこの延長のアドレスに登録要求を転送する必要があります。この拡張機能のHAアドレスがルーティング可能なユニキャストアドレスではない場合、FAはエラーコードNon Zero-HA-Reqdでリクエストを拒否する必要があります。
If the Registration Request contains the Requested HA Extension, the FA uses that address as the destination for the relayed Registration Request.
登録要求に要求されたHA拡張機能が含まれている場合、FAはそのアドレスを中継登録要求の宛先として使用します。
Backward-compatibility issues related to the mobility agents are addressed in Section 10.
モビリティエージェントに関連する後方互換性の問題については、セクション10で説明します。
A home agent can process an incoming Registration Request in one of the following two ways:
ホームエージェントは、次の2つの方法のいずれかで着信登録リクエストを処理できます。
1. The MN or FA sends the Registration Request to the Requested HA. The term Requested HA has meaning in the context of a Registration Request message. When the Requested HA successfully processes the Registration Request and creates a binding and sends a Reply with its address, it becomes the Assigned HA. The term Assigned HA is meaningful in the context of a Registration Reply message.
1. MNまたはFAは、登録要求を要求されたHAに送信します。要求された用語は、登録要求メッセージのコンテキストで意味があります。要求されたHAが登録要求を正常に処理し、バインディングを作成し、そのアドレスで返信を送信すると、割り当てられたHAになります。HAが割り当てられた用語は、登録返信メッセージのコンテキストで意味があります。
2. A home agent receiving a Registration Request with HA field set to ALL-ZERO-ONE-ADDR MAY reject the request even if successfully authenticated and suggest an alternate HA address in Reply. In such a case, the HA puts its own address in HA field of Reply and sets the Reply code to REDIRECT-HA-REQ and adds the Redirected HA Extension.
2. All-Zero-One-ADDRに設定されたHAフィールドで登録要求を受け取ったホームエージェントは、正常に認証されていてもリクエストを拒否し、応答で代替のHAアドレスを提案する場合があります。このような場合、HAは独自のアドレスをHAフィールドの返信フィールドに配置し、Redirect-HA-Reqに応答コードを設定し、リダイレクトHA拡張を追加します。
If the Registration Request contains the Requested HA Extension, the HA address in that extension must match the destination IP of the Request. If it does not match, the Requested HA MUST reject the Registration Request with error code 136.
登録要求に要求されたHA拡張機能が含まれている場合、その拡張機能のHAアドレスは、リクエストの宛先IPと一致する必要があります。一致しない場合、要求されたHAはエラーコード136で登録要求を拒否する必要があります。
The HA that processes the incoming Registration Request fully in accordance with Mobile IPv4 [1] and this specification becomes the Assigned HA. The Registration Request terminates at the Assigned HA.
モバイルIPv4 [1]に従って着信登録要求を完全に処理するHAと、この仕様は割り当てられたHAになります。登録要求は、割り当てられたHAで終了します。
The Assigned HA creates one mobility binding per MN and sends the Registration Reply to the MN by copying its address in the Home Agent field and as the source IP address of the Reply.
割り当てられたHAは、MNごとに1つのモビリティバインディングを作成し、ホームエージェントフィールドのアドレスをコピーし、応答のソースIPアドレスとしてMNに登録返信を送信します。
The following table summarizes the behavior of the Assigned HA, based on the value of the destination IP address and Home Agent field of the Registration Request.
次の表は、登録要求の宛先IPアドレスとホームエージェントフィールドの値に基づいて、割り当てられたHAの動作をまとめたものです。
Dest IP Addr HA field Processing at Assigned HA
------------ ------------ ----------------------------------
Unicast non-unicast Mobile IPv4 [1]: There is no change
in handling for this case from
(Must be Mobile IPv4. It is mentioned here
equal to the for reference only.
HA receiving HA denies the registration with
the RRQ) error code 136 and sets HA field to
its own IP address in the reply as
per Section 3.8.3.2 in [1].
ALL-ZERO- New Behavior: Accept the RRQ as per ONE-ADDR this specification. Authenticate the RRQ and create mobility binding if the HA is acting as Assigned HA. Set HA field to its own IP address in the Registration Reply.
All-Zero-新しい動作：1つのADDRに従ってRRQを受け入れます。HAが割り当てられたHAとして作用している場合、RRQを認証し、モビリティバインディングを作成します。登録返信でHAフィールドを独自のIPアドレスに設定します。
OR
また
New Behavior: If authentication is successful, reject RRQ with a new error code REDIRECT-HA-REQ. HA puts its address in HA address field of Reject. HA suggests an alternate HA to use in the new Redirected HA Extension.
新しい動作：認証が成功した場合、新しいエラーコードRedirect-HA-ReqでRRQを拒否します。HAは、アドレスを拒否のHAアドレスフィールドに置きます。HAは、新しいリダイレクトHA拡張で使用する代替HAを提案します。
Table 1: Registration Request Handling at Assigned HA
表1：割り当てられたHAでの登録リクエスト処理
As per the messaging proposed here, the mobile node (or the foreign agent) sends the Registration Request to the Requested HA address, which is a unicast address. Therefore, this document does not specify any new behavior for the case where the HA receives a subnet directed broadcast Registration Request as specified in Section 3.8.2.1 of the Mobile IPv4 specification [1]. Although the Home Agent field in the Registration Request is not a unicast address, the destination IP address is a unicast address. This avoids the problem associated with subnet-directed broadcast destination IP address that may result in multiple HAs responding. Thus, there is no need to deny the registration as stated in Mobile IPv4 [1] Section 3.8.3.2.
ここで提案されているメッセージに従って、モバイルノード（または外国人エージェント）は、登録要求を要求されたHAアドレスに送信します。これはユニキャストアドレスです。したがって、このドキュメントでは、HAがモバイルIPv4仕様のセクション3.8.2.1で指定されているサブネット指向ブロードキャスト登録要求を受信した場合の新しい動作を指定しません[1]。登録要求のホームエージェントフィールドはユニキャストアドレスではありませんが、宛先IPアドレスはユニキャストアドレスです。これにより、複数の応答が発生する可能性のあるサブネット指向のブロードキャスト宛先IPアドレスに関連する問題が回避されます。したがって、モバイルIPv4 [1]セクション3.8.3.2に記載されているように、登録を拒否する必要はありません。
When the destination IP address is a unicast address and the Home Agent field is ALL-ZERO-ONE-ADDR, the HA accepts/denies registration and sets the HA field to its own IP address in the reply (i.e., the registration is not rejected with error code 136).
宛先IPアドレスがユニキャストアドレスであり、ホームエージェントフィールドがオールゼロ1-One-ADDRの場合、HAは登録を受け入れ/拒否し、HAフィールドを返信の独自のIPアドレスに設定します（つまり、登録は拒否されませんエラーコード136で）。
The HA can reject the request with the error code REDIRECT-HA-REQ and suggest an alternate HA. This redirection can be used for load balancing, geographical proximity based on Care-of Address, or other reasons. The HA puts its own address in the HA field of the Registration Reply message and puts the address of the redirected HA in the Redirected HA Extension. If the HA accepts the Request, it sets the HA field in the Registration Reply to its own address.
HAは、エラーコードRedirect-Ha-Reqでリクエストを拒否し、代替HAを提案できます。このリダイレクトは、荷物バランス、世話のケアに基づく地理的近接性、またはその他の理由に使用できます。HAは、登録応答メッセージのHAフィールドに独自のアドレスを置き、リダイレクトHA拡張にリダイレクトされたHAのアドレスを配置します。HAがリクエストを受け入れた場合、登録のHAフィールドを独自の住所への返信に設定します。
The Requested HA always performs standard validity checks on the Registration Request. If there is any error, the Registration Request is rejected with error codes specified in Mobile IPv4 [1].
要求されたHAは、登録リクエストで常に標準の有効性チェックを実行します。エラーがある場合、登録要求はモバイルIPv4 [1]で指定されたエラーコードで拒否されます。
When dynamic HA assignment is requested, the MN (or FA in the case of registration via FA) sends the Registration Request to the Requested HA. This address MUST be a unicast IP address. If the MN has included a Requested HA Extension in the Registration Request, the HA address in this extension is the Requested HA.
動的HAの割り当てが要求されると、MN（またはFAを介した登録の場合のFA）は、登録要求を要求されたHAに送信します。このアドレスは、ユニキャストIPアドレスでなければなりません。MNが登録要求に要求されたHA拡張機能を含めた場合、この拡張機能のHAアドレスは要求されたHAです。
Some examples of methods by which the MN or the FA may select the Requested HA are briefly described below:
MNまたはFAが要求されたHAを選択できる方法のいくつかの例を以下に簡単に説明します。
DHCP:
DHCP：
The MN performs DHCP to obtain an IP address on the visited network. The Requested HA is learned from the DHCP Mobile IP Home Agent Option 68 [4]. The MN sends the Registration Request directly to this HA and receives the Assigned HA to be used for the remainder of the Mobile IP session.
MNはDHCPを実行して、訪問されたネットワークでIPアドレスを取得します。要求されたHAは、DHCPモバイルIPホームエージェントオプション68 [4]から学習されます。MNは登録要求をこのHAに直接送信し、モバイルIPセッションの残りに使用される割り当てられたHAを受信します。
AAA:
AAA：
MN performs challenge/response [5] with the FA. The FA retrieves the Requested HA from the AAA server and forwards the Registration Request directly to this HA. The Assigned HA sends a Registration Reply to the FA, which relays it to the MN. MN uses the Assigned HA for the remainder of the Mobile IP session.
MNはFAでチャレンジ/応答[5]を実行します。FAは、要求されたHAをAAAサーバーから取得し、登録要求をこのHAに直接転送します。割り当てられたHAは、FAに登録返信を送信します。FAはMNに中継します。MNは、モバイルIPセッションの残りの部分に割り当てられたHAを使用します。
DNS:
DNS：
In this case, the hostname of the HA is configured on the MN or obtained by some other means, e.g., using a service location protocol. The MN performs DNS lookup on the HA hostname. The DNS infrastructure provides a resource record with information to identify the optimal HA to the MN. The MN sends a Registration Request directly to the HA and receives the Assigned HA to be used for the remainder of the Mobile IP session.
この場合、HAのホスト名はMNで構成されているか、他の手段、たとえばサービスロケーションプロトコルを使用して取得されます。MNは、HAホスト名でDNSルックアップを実行します。DNSインフラストラクチャは、MNに最適なHAを識別するための情報を含むリソースレコードを提供します。MNは登録リクエストをHAに直接送信し、モバイルIPセッションの残りに使用される割り当てられたHAを受信します。
Static configuration:
静的設定：
The HA address is statically configured on the MN. The MN sends the Registration Request to the configured address. The Requested HA may then redirect the MN to a Redirected HA.
HAアドレスは、MNで静的に構成されています。MNは、登録要求を構成されたアドレスに送信します。要求されたHAは、MNをリダイレクトHAにリダイレクトする場合があります。
Each entry in the following table contains the name and value for the error code to be returned in a Registration Reply. It also includes the section in which the error code is first mentioned in this document.
次の表の各エントリには、登録返信でエラーコードが返される名前と値が含まれています。また、このドキュメントでエラーコードが最初に言及されているセクションも含まれています。
Error Name Value Section Description
--------------- ----- ------- -----------------------------
NONZERO-HA-REQD 90 5.2 Non-zero HA address required
in Registration Request.
REDIRECT-HA-REQ 143 5.3 Re-register with redirected HA.
The code value NONZERO-HA-REQD is a Mobile IP response code [1] taken from the range of values associated with rejection by the foreign agent (i.e., value in the range 64-127).
コード値Non Zero-Ha-Reqdは、外国人エージェントによる拒否に関連する値の範囲（つまり、64-127の値）から取られたモバイルIP応答コード[1]です。
The code value REDIRECT-HA-REQ is a Mobile IP response code [1] taken from the range of values associated with rejection by the home agent (i.e., value in the range 128-192).
コード値Redirect-HA-Reqは、ホームエージェントによる拒否に関連する値の範囲（つまり、範囲128-192）から取られたモバイルIP応答コード[1]です。
The Dynamic HA Extension is assigned from the range of values associated with skippable extensions at the home agent (i.e., value in the range 128-255).
動的HA拡張は、ホームエージェントのスキップ可能な拡張機能に関連付けられた値の範囲（つまり、範囲128-255の値）から割り当てられます。
IANA has recorded the values as defined in Sections 7 and 3.4.
IANAは、セクション7および3.4で定義されている値を記録しました。
This specification assumes that a security configuration has been preconfigured between the MN and the HA or is configured along with the initial Registration Request/Registration Reply as per [7].
この仕様では、セキュリティ構成がMNとHAの間に事前に設定されているか、[7]に従って初期登録リクエスト/登録返信とともに構成されていることを前提としています。
There is a possibility of more than one HA creating a mobility binding entry for a given MN, if a man in the middle captures the Registration Request with the HA field set to ALL-ZERO-ONE-ADDR and forwards it to other HAs. This scenario assumes that the rogue node can find out the addresses of the HAs that are able to authenticate the Registration Request. It also assumes that the rogue node has the capability to store, duplicate, and send packets to the other HAs within the limited time of the replay window. Otherwise, these HAs will reject the Registration Requests anyway. In addition, this type of attack is only possible when the Requested HA Extension is not included in the registration message. The mobile node can minimize the duration of this condition by using a short lifetime (e.g., 5 seconds) in the Registration Request.
中央の男性がHAフィールドで登録要求をすべてゼロ1-One-ADDRに設定し、他のHASに転送する場合、特定のMNのモビリティバインディングエントリを作成する可能性が複数あります。このシナリオでは、Rogueノードが登録リクエストを認証できるHASのアドレスを見つけることができることを前提としています。また、Rogueノードには、リプレイウィンドウの限られた時間内にパケットを保存、重複、および送信する機能があることを前提としています。それ以外の場合、これらはとにかく登録リクエストを拒否します。さらに、このタイプの攻撃は、要求されたHA拡張機能が登録メッセージに含まれていない場合にのみ可能です。モバイルノードは、登録リクエストで短い寿命（5秒）を使用することにより、この状態の期間を最小限に抑えることができます。
This specification does not change the security model established in Mobile IPv4 [1]. Mobile nodes are often connected to the network via wireless links, which may be more prone to passive eavesdropping or replay attacks. Such an attack might lead to bogus registrations or redirection of traffic or denial of service.
この仕様は、モバイルIPv4で確立されたセキュリティモデルを変更しません[1]。モバイルノードは、多くの場合、ワイヤレスリンクを介してネットワークに接続されています。これは、受動的な盗聴またはリプレイ攻撃を起こしやすい場合があります。このような攻撃は、偽の登録または交通のリダイレクトまたはサービスの拒否につながる可能性があります。
As per the messaging in this document, the Assigned Home Agent will process the incoming Registration Request as per Mobile IPv4 [1]. Hence the Assigned Home Agent will have the same security concerns as those of the home agent in Mobile IPv4 [1]. They are addressed in Section 5, "Security Considerations", of Mobile IPv4 [1].
このドキュメントのメッセージに従って、割り当てられたホームエージェントは、モバイルIPv4 [1]に従って、着信登録要求を処理します。したがって、割り当てられたホームエージェントは、モバイルIPv4 [1]のホームエージェントのセキュリティエージェントと同じセキュリティ上の懸念を抱きます。それらは、モバイルIPv4 [1]のセクション5「セキュリティ上の考慮事項」で対処されています。
The Registration Request and Registration Reply messages are protected by a valid authenticator as specified in Mobile IPv4 [1]. Configuring security associations is a deployment-specific issue and is covered by other Mobile IP specifications. There can be many ways of configuring security associations, but this specification does not require any specific way.
登録リクエストと登録返信メッセージは、モバイルIPv4 [1]で指定されている有効な認証器によって保護されています。セキュリティ協会の構成は、展開固有の問題であり、他のモバイルIP仕様でカバーされています。セキュリティ協会を構成するには多くの方法がありますが、この仕様では特定の方法は必要ありません。
An example is where the security association between an MN and an individual HA (Requested or Assigned) is dynamically derived during the registration process based on a shared secret between MN and AAA infrastructure, as defined in [7]. The Registration Request is protected with MN-AAA Authentication Extension, and Registration Reply is protected with MN-HA Authentication Extension. Because the security association is shared between MN and AAA, any dynamically assigned HA in the local domain can proxy authenticate the MN using AAA as per [7].
例としては、MNと個々のHA（要求または割り当て）のセキュリティ関連は、[7]で定義されているように、MNとAAAインフラストラクチャ間の共有秘密に基づいて登録プロセス中に動的に導き出されます。登録要求はMN-AAA認証拡張機能で保護されており、登録返信はMN-HA認証拡張機能で保護されています。セキュリティ協会はMNとAAAの間で共有されるため、ローカルドメインで動的に割り当てられたHAは、[7]に従ってAAAを使用してMNを認証することができます。
The Assigned Home Agent authenticates each Registration Request from the mobile node as specified in Mobile IPv4 [1] and/or RFC 3012. The MN also authenticates the Registration Reply from the Assigned HA; thus, the existing trust model in Mobile IPv4 [1] is maintained.
割り当てられたホームエージェントは、モバイルIPv4 [1]および/またはRFC 3012で指定されているモバイルノードからの各登録要求を認証します。MNは、割り当てられたHAからの登録返信も認証します。したがって、モバイルIPv4 [1]の既存の信頼モデルが維持されます。
In this section, we examine concerns that may arise when using this specification in a mixed environment where some nodes implement the specification and others do not. In each of the examples below, we consider the case where one node is a "legacy" node, which does not implement the specification in the context of other nodes that do.
このセクションでは、一部のノードが仕様を実装し、他のノードが実装していない混合環境でこの仕様を使用する場合に発生する可能性のある懸念を調べます。以下のそれぞれの例では、1つのノードが「レガシー」ノードである場合を検討します。これは、他のノードのコンテキストで仕様を実装していません。
Legacy Home Agent:
レガシーホームエージェント：
Legacy home agents may reject the Registration Request with error code 136 because the Home Agent field is not a unicast address. However, some legacy HA implementations may coincidentally process the Registration Request in accordance with this document, when the HA field in Registration Request is set to ALL-ZERO-ONE-ADDR.
レガシーホームエージェントは、ホームエージェントフィールドがユニキャストアドレスではないため、エラーコード136で登録要求を拒否する場合があります。ただし、一部のレガシーHAの実装は、登録リクエストのHAフィールドがAll-Zero-One-ADDRに設定されている場合、このドキュメントに従って登録要求を偶然処理する場合があります。
Legacy Foreign Agent:
レガシー外国人エージェント：
Legacy foreign agents may forward a Registration Request with home agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP address to ALL-ZERO-ONE-ADDR. This will result in the packet being dropped or incidentally handled by a next-hop HA, adjacent to the FA. The MN may not be aware of the dropped Registration Request and may probably retry registration, thereby increasing the delay in registration.
レガシー外国人エージェントは、宛先IPアドレスをAll-Zero-One-ADDRに設定することにより、ホームエージェントフィールドセットをオールゼロワンADDRに設定したホームエージェントフィールドで登録リクエストを転送できます。これにより、パケットがドロップされるか、FAに隣接する次のホップHAによって偶然に処理されます。MNは登録要求の削除を認識しておらず、おそらく登録を再試行する可能性があり、それにより登録の遅延が増加する可能性があります。
To reduce the delay in registration, the MN should take the following steps:
登録の遅延を減らすには、MNは次の手順を実行する必要があります。
1. The MN should send the Registration Request as specified in this specification. In other words, the MN should set the Home Agent field in the Registration Request to ALL-ZERO-ONE-ADDR and also add the Requested HA Extension.
1. MNは、この仕様で指定されているように登録要求を送信する必要があります。言い換えれば、MNは登録要求にホームエージェントフィールドをAll-Zero-One-ADDRに設定し、要求されたHA拡張機能を追加する必要があります。
2. If the MN does not receive a Registration Reply within some time and/or after sending a few Registration Requests, it can assume that the Registration Request(s) has been dropped, either by a legacy FA or an incorrect HA. In addition, if the registration is denied with error code 70 (poorly formed Request), the MN can assume that the legacy FA cannot process this message. In either case, the MN should fall back to a recovery mechanism. The MN should quickly send a new Registration Request as mentioned in Section 4.1 step 2. This step will ensure that a legacy FA will forward the Registration Request to the home agent thereby making dynamic HA assignment possible.
2. MNがいくつかの時間内および/またはいくつかの登録リクエストを送信した後に登録返信を受け取らない場合、レガシーFAまたは誤ったHAによって登録要求が削除されたと仮定できます。さらに、登録がエラーコード70（形成されていない要求）で拒否された場合、MNはレガシーFAがこのメッセージを処理できないと想定できます。どちらの場合でも、MNは回復メカニズムに戻る必要があります。MNは、セクション4.1ステップ2に記載されているように、新しい登録リクエストをすばやく送信する必要があります。このステップにより、レガシーFAがホームエージェントに登録リクエストを転送し、それによりダイナミックHAの割り当てを可能にします。
Legacy Mobile Node:
レガシーモバイルノード：
An MN that sends a Registration Request to an FA that can do dynamic HA assignment, but does not set the HA field to ALL-ZERO-ONE-ADDR will continue to be registered with its statically configured HA, exactly according to RFC 3344.
動的なHA割り当てを行うことができるが、HAフィールドをAll-Zero-One-ADDRに設定しないFAに登録要求を送信するMNは、RFC 3344に従って、静的に構成されたHAに引き続き登録されます。
The authors would like to thank Pete McCann for thorough review, suggestions on security considerations, and definition of ALL-ZERO-ONE-ADDR. Thanks to Kuntal Chowdhury for extensive review and comments on this document. Also thanks to Henrik Levkowetz for detailed reviews and suggestions. Thomas Narten highlighted issues for legacy FA considerations. Thanks to Ahmad Muhanna for pointing out scenario of multiple bindings on HAs, documented in the Security Considerations section.
著者は、徹底的なレビュー、セキュリティ上の考慮事項に関する提案、および全ゼロ1-One-ADDRの定義について、Pete McCannに感謝したいと思います。この文書に関する広範なレビューとコメントをしてくれたKuntal Chowdhuryに感謝します。また、詳細なレビューと提案については、Henrik Levkowetzに感謝します。トーマス・ナルテンは、レガシーFAの考慮事項の問題を強調しました。複数のバインディングのシナリオを指摘してくれたAhmad Muhannaに感謝します。セキュリティに関する考慮事項セクションに文書化されています。
The authors would like to thank Mike Andrews, Madhavi Chandra, and Yoshi Tsuda for their review and suggestions.
著者は、マイク・アンドリュース、マダヴィ・チャンドラ、ヨッシー・ツダに、彼らのレビューと提案をしてくれたことに感謝したいと思います。
[1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[2] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[2] Calhoun、P。およびC. Perkins、「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年3月。
[3] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[3] Senie、D。、「ルーターでの監督ブロードキャストのデフォルトの変更」、BCP 34、RFC 2644、1999年8月。
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[4] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[5] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
[5] Perkins、C。およびP. Calhoun、「モバイルIPv4チャレンジ/応答拡張機能」、RFC 3012、2000年11月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[7] Perkins、C。and P. Calhoun、「モバイルIPv4の認証、承認、および会計（AAA）登録キー」、RFC 3957、2005年3月。
Authors' Addresses
著者のアドレス
Milind Kulkarni Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
Milind Kulkarni Cisco Systems Inc. 170 W. Tasman Drive、サンノゼ、CA 95134 USA
Phone: +1 408-527-8382
EMail: mkulkarn@cisco.com
Alpesh Patel Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
Alpesh Patel Cisco Systems Inc. 170 W. Tasman Drive、San Jose、CA 95134 USA
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Kent Leung Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
Kent Leung Cisco Systems Inc. 170 W. Tasman Drive、San Jose、CA 95134 USA
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。