RFC4433 日本語訳
4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment. M. Kulkarni, A.Patel, K. Leung. March 2006. (Format: TXT=55636 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Kulkarni
Request for Comments: 4433 A. Patel
Category: Standards Track K. Leung
Cisco Systems Inc.
March 2006
Kulkarniがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4433年のA.パテルカテゴリ: 2006年の標準化過程K.レオンシスコシステムズの株式会社行進
Mobile IPv4 Dynamic Home Agent (HA) Assignment
モバイルIPv4ダイナミックなホームのエージェント(ハ)課題
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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(RFC3344)は、移動しているモバイルノード(ミネソタ)のセッションを据えつけるのに、ホームのエージェント(HA)を使用します。 このドキュメントはダイナミックなホームエージェント課題とHAリダイレクションのためにメッセージングメカニズムを提案します。 目標はモバイルIPセッションのためにHA選択のためのどんな適当なメソッドも許容している間、最適のHAを割り当てるためにメカニズムを提供することです。
Kulkarni, et al. Standards Track [Page 1] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[1ページ]。
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
1. 序論…3 2. 要件用語…3 3. 問題声明…5 3.1. 範囲…5 3.2. モバイルIPv4でのダイナミックなホームエージェント発見…5 3.3. NAI用法と動力、ハ、課題…6 3.4. ダイナミックである、ハ、拡大…6 3.4.1. ハよう要求する、拡大…7 3.4.2. 向け直す、ハ、拡大…7 4. 動力のためにメカニズムを通信させる、ハ、課題/リダイレクション…7 4.1. 動力のためにハを通信する、課題…7 4.1.1. メッセージフローチャートがある例…8 4.2. 通信する、ハ、リダイレクション…10 4.2.1. メッセージフローチャートがある例…12 5. 移動性エージェント問題…14 5.1. モバイルノード問題…14 5.1.1. ファCoAを使用するミネソタ…14 5.1.2. Mn使用はCoAの共同場所を見つけました…15 5.1.3. リフレッシュが割り当てた、ハ、モバイルノードに関するアドレス…16 5.2. 外国エージェント問題…16 5.3. ホームエージェント問題…17 5.3.1. ホームエージェント問題を割り当てます…17 6. ホームエージェント選択を要求します…19 7. 誤り値…20 8. IANA問題…20 9. セキュリティ問題…20 10. 後方の互換性問題…21 11. 承認…23 12. 標準の参照…23
Kulkarni, et al. Standards Track [Page 2] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[2ページ]。
1. Introduction
1. 序論
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を割り当てることです。 [2] ダイナミックに割り当てられたHAを要求するとき、モバイルノードはNetwork Access Identifier(NAI)拡張子を使用しなければなりません。
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).
ミネソタが初期のRegistration RequestにHA分野をはめ込むダイナミックに割り当てられたHAを要求する、すべて、-、ZERO-ONE-ADDR、(セクション2では、定義されます。) 要求を受け入れるなら、HAはHAの自己のアドレスを含むうまくいっているRegistration Replyを送ります。 要求されたHAは代替のHAを勧めることができます、そして、そうだとすれば、Registration Replyは新しいエラーコードREDIRECT-HA-REQと共に拒絶されます、そして、代替のHAアドレスは新しい拡大(HA Extensionを向け直す)で指定されます。
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分野が設定されるときこのドキュメントがRegistration Requestsにおける使用のために新しいRequested HA Extensionを定義する、すべて、-、ZERO-ONE-ADDR. Requested HAアドレスはミネソタの都合のよい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.
メッセージングメカニズムは、本書では、ミネソタがモバイルIPメッセージのダイナミックなHAアドレスを要求して、受け取ることができるように、定義されます。 しかしながら、このドキュメントの範囲の外にネットワークが課題のためにHAをミネソタに選択するメカニズムがあります。 例えば、Registration Request(または、Registration Requestの情報)を受けるどんなネットワーク・ノードでも選択をするかもしれません、Foreignエージェント、AAAサーバ、またはホームのエージェントなどのように。 HAを選択するノードは多くの評価基準に基づいて1つを選択するかもしれません、他のHA負荷分散、地理的な近接性、施政方針などを含んでいて
2. Requirements Terminology
2. 要件用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
The Mobile-IP-related terminology described in RFC 3344 [1] is used in this document. In addition, the following terms are used:
RFC3344[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.
オール1つの無ADDR: IPアドレス0.0.0.0か255.255、.255 .255。 アドレス、255.255 .255 .255 ホームドメインのHAのために優先を示します。 .0が家で訪問されたドメインに対して好みを全く示さない.0は0.0を扱います。
Kulkarni, et al. Standards Track [Page 3] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[3ページ]。
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.
ハよう要求します: Registration Requestが送られるホームのエージェントの送付先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".
この仕様が新しい状態でaを定義することに注意してください、「ハよう要求する、拡大、」 セクション3.4では、どれが用語と異なっているかが「ハよう要求しました」。
Assigned HA: The HA that accepts an MN's Registration Request
and returns a successful Registration Reply.
割り当て、ハ: ミネソタのRegistration Requestを受け入れて、うまくいっているRegistration Replyを返すHA。
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).
向け直す、ハ: 登録がエラーコードREDIRECT-HA-REQと共に拒絶されるなら、言及されるHAは新しい拡大(HA Extensionを向け直す)で指定されます。
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].
ミネソタ: モバイルIPv4[1]で定義されるモバイルノード。
HA: Home agent as defined in Mobile IPv4 [1].
ハ: モバイルIPv4[1]で定義されるホームのエージェント。
FA: Foreign Agent as defined in Mobile IPv4 [1].
ファ: モバイルIPv4[1]で定義される外国人のエージェント。
CoA: Care-of Address.
CoA: 注意、-、アドレス。
CCoA: Co-located Care-of Address.
CCoA: 共同見つけられている、注意、-、アドレス。
MN HoA: Mobile node's home address.
ミネソタ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: 登録要求。
Kulkarni, et al. Standards Track [Page 4] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[4ページ]。
3. Problem Statement
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. 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 ExtensionはNAIと可能なダイナミックなホームアドレス課題でミネソタを特定する概念を紹介しました。 ホームアドレスがダイナミックに割り当てられるとき、多数の使用への最適のHAに関して理由をダイナミックにホームのエージェントを発見するか、またはミネソタに知らせるのが以下のように望ましいです。
- 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.
- 訪問されたネットワークとモバイルノードのホームネットワークの間の距離が大きいなら、これらの登録証明書のためのシグナリング遅れは長いかもしれません。 このような場合には、ミネソタは冷ややかなホームのエージェントに据えつけられるでしょう、ホームのエージェントとモバイルノードの間の長距離を旅行するトンネルを堀られたトラフィックをもたらして。 モバイル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.
- ネットワークにおける複数のHAsの間の何らかのフォームのロードバランシングを達成するのは望ましいです。 ダイナミックなHA課題、そして/または、HAリダイレクションで、ネットワークは、HAsの1セットから最適のHAを選択して、その結果、HAsのグループにロードバランシングを実現します。
- Local administrative policies.
- ローカルの施政方針。
3.1. Scope
3.1. 範囲
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].
この仕様がミネソタと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.
ドキュメントは割り当てられたか用語Requested/向け直されたHA(セクション6)を導入します。 ネットワーク、そして/または、展開特有であり、したがってこの仕様の範囲の外にある様々な手段でRedirected HA Extensionへの挿入のための候補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.
それがどんなHAアドレスも意識していなくて、少なくとも1つのHAアドレスを意識してさえいるとき、ミネソタはダイナミックなHA課題を要求するかもしれません。
3.2. Dynamic Home Agent Discovery in Mobile IPv4
3.2. モバイルIPv4でのダイナミックなホームエージェント発見
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
モバイルIPv4[1]はRegistration Requestのホームエージェント分野でサブネットで指示された放送IPアドレスを使用することでモバイルノードのホームのエージェントを発見するのにメカニズムを指定します。 このメカニズムはそうでした。
Kulkarni, et al. Standards Track [Page 5] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[5ページ]。
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].
モバイルノードのために静的なホームアドレスとサブネット接頭語で設計されて、固定ホームネットワークに据えつけられます。 しかしながら、Registration Requestの送付先IPアドレスとしてサブネットの指示された放送を使用して、ルータがデフォルトでこれらのパケットを下げるのでRegistration Requestがホームサブネットに達するのは、ありそうもないです。 カリフォルニア-1998-01のCERT勧告Smurf IPサービス不能攻撃[3]を見てください。
3.3. NAI Usage and Dynamic HA Assignment
3.3. NAI用法と動力、ハ、課題
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 ExtensionはNAIと可能なダイナミックなホームアドレス課題でミネソタを特定する概念を紹介しました。 このドキュメントは、ミネソタがダイナミックなHA課題を使用している間NAIを使用して、ホームアドレスを得なければならないのを必要とします。 ミネソタは、まだRegistration Requestの静的なホームアドレスを示すことができますが、セッションのためのRegistration Replyのホームアドレスとしてのアドレスを取らなければなりません。 これはNAI仕様[2]に記録される手順と互換性があります。
3.4. Dynamic HA Extension
3.4. ダイナミックである、ハ、拡大
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で見せられたDynamic HA ExtensionはHAのアドレスを含んでいます。 これは、ジェネリック拡大であり、Registration RequestとReplyメッセージで使用できます。 それはskippable拡張子です。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| Subtype| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハ、-、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Dynamic HA Address Extension
図1: 動力、ハ、拡大を扱ってください。
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
Subtype Definesは以下としてこの拡張子の使用です。 「副-タイプ」1=は、HA Extension2=がHA Extensionを向け直したよう要求しました。
Length Indicates the length of the extension not
including the type, subtype, and length fields.
Length is always 4 bytes.
タイプを含まない拡大の長さの長さのIndicates、「副-タイプ」、および長さの分野。 いつも長さは4バイトです。
HA-Address Address of the home agent.
ホームのエージェントのHA-アドレスAddress。
Kulkarni, et al. Standards Track [Page 6] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[6ページ]。
3.4.1. Requested HA Extension
3.4.1. ハよう要求する、拡大
The Requested HA Extension is a Dynamic HA Extension of subtype 1.
Requested HA Extensionは「副-タイプ」1のDynamic HA Extensionです。
The MN may include the Requested HA Extension in the Registration Request as a hint to the network where it wishes to be anchored.
ミネソタはヒントとしてRegistration Requestでそれを据えつけられたいネットワークにRequested HA Extensionを含めるかもしれません。
This extension contains the address of the HA. A valid unicast IP address MUST be used as HA address in this extension.
この拡大はHAのアドレスを含んでいます。 HAアドレスとしてこの拡大に有効なユニキャストIPアドレスを使用しなければなりません。
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にRegistration Requestを送ります。 FAの存在では、FA MUSTはこの拡大でHAアドレスにRegistration Requestを送ります。
3.4.2. Redirected HA Extension
3.4.2. 向け直す、ハ、拡大
The Redirected HA Extension is a Dynamic HA Extension of subtype 2.
Redirected HA Extensionは「副-タイプ」2のDynamic HA Extensionです。
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.
Redirected HA Extensionはミネソタが次の登録を試みるべきであるHAのアドレスを含んでいます。 Registration Requestを受けるHAは代替のHAを勧めることができます、そして、そうだとすれば、新しいエラーコードREDIRECT-HA-REQと共にRegistration Replyを送ります、そして、この拡大で代替のHAアドレスを指定します。
The Redirected HA Extension MUST be included in Registration Reply when the reply code is REDIRECT-HA-REQ.
回答コードがREDIRECT-HA-REQであるときに、Registration ReplyにRedirected HA Extensionを含まなければなりません。
4. Messaging Mechanism for Dynamic HA Assignment/Redirection
4. 動力のためにメカニズムを通信させる、ハ、課題/リダイレクション
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では、説明されます)。
4.1. Messaging for Dynamic HA Assignment
4.1. 動力のためにハを通信する、課題
The following sequence of events occurs when the MN requests dynamic home agent assignment:
ミネソタがダイナミックなホームエージェント課題を要求するとき、イベントの以下の系列は起こります:
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. ミネソタがRegistration Requestのホームエージェントアドレス・フィールドを設定する、すべて、-、ZERO-ONE-ADDR. ミネソタが必要なHAアドレスを意識しているなら、それはRegistration RequestのRequested HA Extensionのそのアドレスを加えることができます。 HAがRequested HA Extensionをサポートしないなら、下でのステップ2を見てください。
Kulkarni, et al. Standards Track [Page 7] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[7ページ]。
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課題を望んでいるミネソタに。 また、経路かそれとも知られているHAが経路でないかどうかのFAがRequested HA Extensionをサポートするレガシーを発見するとき(セクション10を見てください)、ミネソタはこれ(HAアドレスを意識しているとき)に続きます。
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.
の代わりにする、ミネソタがHAアドレスへのRegistration Requestにホームエージェントアドレス・フィールドをはめ込む、(それを設定する、すべて、-、ZERO- ONE-ADDR、) また、ミネソタはRegistration RequestのRequested HA Extensionの同じ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. ミネソタ(共同見つけられたCoAを使用して、直接HAとともに記名するなら)かFA(ミネソタがFAを通して登録されているなら)がRegistration Requestを送る、「ハよう要求しました」。 Requested HA Extensionが存在しているなら、Requested 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分野のアドレスにRegistration Requestを送ります(その結果、ミネソタはステップ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. 「ハよう要求する、」 処理するホームのエージェントはモバイルIPv4[1]とこのドキュメントの仕様に従ってRegistration Requestですか? それはうまくいっているRegistration Requestにおいて拘束力があった状態で移動性を作成します。 また、それはRegistration Replyをミネソタに送ります。
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. ミネソタが得る、「割り当て、ハ、」 HA分野から、うまくいっているRegistration Replyと用途で、セッションの残りのためにそれを扱ってください。 (それに注意してください、「割り当て、ハ、」、同じである、「ハよう要求した」、)
6. Subsequent Registration Request messages for renewal are sent to
the Assigned HA.
6. 更新へのその後のRegistration RequestメッセージをAssigned 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 詳細にAssigned HAについて説明します。 どうRequested HAを選択するかに関するいくつかの考えがセクション6で簡潔にカバーされています。
4.1.1. Example with Message Flow Diagram
4.1.1. メッセージフローチャートがある例
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が、モバイルノードの1つの特定の例が使用するのを示す、FAによって見つけられる、Care、-、Address(FA CoA)とFAはこの仕様あたりのRequested HA Extensionを理解しています。
Kulkarni, et al. Standards Track [Page 8] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[8ページ]。
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 |
|----------------------------->|
| | |
Mnファが要求したか、または割り当てた、ハ。| 1 | | |、-、-、-、-、-、-、-、-、-、-、--、>| 2 | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| 3 | | 4 | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、| 5 | |----------------------------->| | | |
Figure 2: Example Message Flow for Dynamic HA Assignment
図2: 動力のための例のメッセージ流動、ハ、課題
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. ミネソタがRegistration Requestのホームエージェントアドレス・フィールドを設定する、すべて、-、ZERO-ONE-ADDR. ミネソタがこの例でFA CoAを使用しているので、それはRegistration RequestをFAに送ります。 Registration Requestは以下の通りフォーマットされます:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
+-----------------------------------------------------------+ | Src IP=| Dest IP=| ミネソタHoA| ハ、=を扱ってください。| CoA=| | ミネソタ| ファ| | オール1つの無ADDR|ファ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.
ミネソタが必要なHAアドレスを意識しているなら、それはRegistration RequestのRequested HA Extensionのヒントとしてのそのアドレスを加えることができます。 その拡大は上に示されません。
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はRegistration RequestをRequested HAに送ります。 Requested HA Extensionが存在しているなら、Requested HAはこの拡大でHAアドレスです。 Requested HA Extensionが存在していないなら、FAはこの仕様の範囲の外の手段でRequested HAを決定します。 Registration Requestは以下の通りフォーマットされます:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
+-----------------------------------------------------------+ | Src IP=| Dest IP=| ミネソタHoA| ハ、=を扱ってください。| CoA=| | ファ|ハよう要求します。| | オール1つの無ADDR|ファCoA| +-----------------------------------------------------------+
Kulkarni, et al. Standards Track [Page 9] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[9ページ]。
(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.)
(ミネソタがRequested HA Extensionを含めるなら、FAはその拡大をコピーします。 次に、FAはRegistration Requestを進めます、Requested HA Extensionと共に、Requested HA Extensionで指定されたHAアドレスに。)
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. モバイルIPv4[1]と本書では定義されたメッセージングによると、HAはRegistration Requestを処理します。 HAはうまくいっている要求において拘束力があった状態で移動性を作成して、Assigned HAになります。 そしてHAはRegistration ReplyをFAに送ります:(FAは以下の通りフォーマットされます)。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
|Assigned| Src IP of | | Assigned HA |FA CoA/|
| HA | the RRQ | | | |
+-----------------------------------------------------------+
+-----------------------------------------------------------+ | Src IP=| Dest IP=| ミネソタHoA| ハ、=を扱ってください。| CoA=| |割り当てられます。| IPをSrcします。| | 割り当て、ハ。|ファCoA/| | ハ| RRQ| | | | +-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows:
4. FAは以下の通りミネソタにRegistration Replyをリレーします:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | Assigned HA |FA CoA/|
+-----------------------------------------------------------+
+-----------------------------------------------------------+ | Src IP=| Dest IP=| ミネソタHoA| ハ、=を扱ってください。| CoA=| | ファ| ミネソタ| | 割り当て、ハ。|ファ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. ミネソタは、うまくいっているRegistration ReplyのHA分野からAssigned HAアドレスを得て、セッションの残りにそれを使用します。 ミネソタは残りセッションのためにその後のRe-登録かDe-登録Requestsを直接Assigned HAに送ります。 このRegistration Requestのホームエージェントアドレス・フィールドが設定される、すべて、-、ZERO-ONE-ADDR. Assigned HAがRequested HAと同じであることに注意してください。
4.2. Messaging for HA Redirection
4.2. 通信する、ハ、リダイレクション
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.
このセクションは、Requested HAがRegistration Requestを受け入れないとき、起こるイベントについて説明して、代わりに別のHA(通称Redirected HA)にモバイルノードを転送します。 レガシーHAによって示されないので、この振舞いは、以下での記述で参照されません。 レガシーFAの存在では、Registration Requestの特定の分野についてセクション4.1を参照してください。
1. The MN sets the Home Agent address field in the Registration
Request to ALL-ZERO-ONE-ADDR.
1. ミネソタがRegistration Requestのホームエージェントアドレス・フィールドを設定する、すべて、-、ZERO-ONE-ADDR
Kulkarni, et al. Standards Track [Page 10] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[10ページ]。
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. ミネソタ(共同見つけられたCoAを使用して、直接HAとともに記名するなら)かFA(ミネソタがFAを通して登録されているなら)がRegistration Requestを送る、「ハよう要求しました」。 ミネソタがHAアドレスを意識しているなら、それはRegistration RequestのRequested HA Extensionのそのアドレスを加えることができます。
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がRegistration Requestを受ける、すべて、-、ZERO-ONE-ADDR、HAはReplyコード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がRequestを拒絶するなら、ReplyのHA分野はこのHAのアドレスに設定されます。 リダイレクションの目標であるHAのIPアドレスはRedirected HA Extensionで指定されます。 回答コードがREDIRECT- HA-REQに設定されるとき、この拡大の存在は義務的です。 HAはFA/ミネソタにReplyを送ります。
4. FA sends the Reply to the MN.
4. FAはReplyをミネソタに送ります。
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. エラーコードがREDIRECT-HA-REQに設定されるなら、ミネソタはRedirected HA ExtensionからHAアドレスを得ます。 そして、ミネソタはRegistration RequestをRedirected HAに送ります。 ミネソタは、この新しいRegistration RequestでRequested HA Extensionを加えるのを選ぶかもしれません。 登録輪が現れるなら(Redirected HAがほかの場所に登録するよう既にミネソタに指示したHAであることのケース)、ミネソタは、どんな一層のRegistration Requestも送るのを止めて、輪のイベントが検出されたという指示を前提とします。 輪の検出のためにミネソタによって覚えていられた連続したRedirected HAsの数は実装パラメタです。
Kulkarni, et al. Standards Track [Page 11] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[11ページ]。
4.2.1. Example with Message Flow Diagram
4.2.1. メッセージフローチャートがある例
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つの特定の例を示している、Care、-、Address。(そこでは、FAがレガシーFAではありません)。
MN FA Requested HA Redirected HA
| 1 | | |
|------------>| 2 | |
| |--------------->| |
| | | |
| | | |
| | 3 | |
| 4 |<---------------| |
|<------------| | |
| | | |
| | 5 | |
|--------------------------------------------->|
| | | |
Mnファが、ハよう向け直された状態で要求した、ハ。| 1 | | | |、-、-、-、-、-、-、-、-、-、-、--、>| 2 | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、|、|、|、| 3 | | | 4 | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、|、| 5 | | |--------------------------------------------->| | | | |
Figure 3: Example Message Flow for HA Redirection
図3: 例が流れを通信させる、ハ、リダイレクション
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. ミネソタがRegistration Requestのホームエージェントアドレス・フィールドを設定する、すべて、-、ZERO-ONE-ADDR. ミネソタがこの例でFA CoAを使用しているので、それはRegistration RequestをFAに送ります。 Registration Requestは以下の通りフォーマットされます:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
+-----------------------------------------------------------+ | Src IP=| Dest IP=| ミネソタHoA| ハ、=を扱ってください。| CoA=| | ミネソタ| ファ| | オール1つの無ADDR|ファ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.
ミネソタがHAアドレスを意識しているなら、それはRegistration RequestのRequested HA Extensionのヒントとしてのそのアドレスを加えることができます。 その拡大は上に示されません。
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はRegistration RequestをRequested HAに送ります。 Requested HA Extensionが存在しているなら、Requested HAはこの拡大でHAアドレスです。 Requested HA Extensionが存在していないなら、FAはこの仕様の範囲の外の手段でRequested HAを決定します。 Registration Requestは以下の通りフォーマットされます:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
+-----------------------------------------------------------+ | Src IP=| Dest IP=| ミネソタHoA| ハ、=を扱ってください。| CoA=| | ファ|ハよう要求します。| | オール1つの無ADDR|ファCoA| +-----------------------------------------------------------+
Kulkarni, et al. Standards Track [Page 12] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[12ページ]。
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. モバイルIPv4[1]とこの仕様に基づき定義されたメッセージングによると、HAはRegistration Requestを処理します。 登録がうまくいっていますが、ローカルの構成/施政方針などが、別のHAをミネソタを参照するようHAに指示するなら、HAはエラーコードREDIRECT-HA-REQとの要求を拒絶します。 HAはRedirected HA ExtensionにRedirected HAのアドレスに記入します。 そしてHAはRegistration Reply廃棄物をFAに送ります:(FAは以下の通りフォーマットされます)。
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| | Src IP of | | HA |FA CoA |
| HA | the RRQ | | | |
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+
+-----------------------------------------------------------+ | Src IP=| Dest IP=| ミネソタHoA| ハ、=を扱ってください。| CoA=| | | IPをSrcします。| | ハ|ファCoA| | ハ| RRQ| | | | +-----------------------------------------------------------+ | 向け直す、ハ、拡大… | +-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows:
4. FAは以下の通りミネソタにRegistration Replyをリレーします:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | HA |FA CoA/|
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+
+-----------------------------------------------------------+ | Src IP=| Dest IP=| ミネソタHoA| ハ、=を扱ってください。| CoA=| | ファ| ミネソタ| | ハ|ファCoA/| +-----------------------------------------------------------+ | 向け直す、ハ、拡大… | +-----------------------------------------------------------+
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. ミネソタがReplyを認証できるなら、ミネソタはRedirected HA ExtensionからHAアドレスを抜粋します。 次に、ミネソタはRegistration RequestをRedirected HAに送ります、Registration Requestを処理している間、そのHAからリダイレクション応答を既に受けていない場合。 ミネソタは、この新しいRegistration RequestでRequested HA Extensionを加えるのを選ぶかもしれません。
Kulkarni, et al. Standards Track [Page 13] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[13ページ]。
5. Mobility Agent Considerations
5. 移動性エージェント問題
The following sections describe the behavior of each mobility agent in detail.
以下のセクションは詳細にそれぞれの移動性エージェントの振舞いについて説明します。
5.1. Mobile Node Considerations
5.1. モバイルノード問題
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拡張子を使用しなければなりません。 ミネソタがNAI拡張子を使用するので、ホームAddress分野は.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課題が進行していて、ミネソタがホームのエージェントで首尾よく投錨されていない間、ミネソタがホームエージェント分野をRegistration Requestにはめ込まなければならない、すべて、-、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 Challenge/応答Extensions[5]の指定されるとしての有効な固有識別文字でRegistration Requestを保護しなければなりません。 展開特有であり、したがって、この仕様の範囲の外でセキュリティ協会を構成する。 また、ミネソタと個々のHAとのセキュリティ協会はミネソタとAAAインフラストラクチャ[7]の間の共有秘密キーに基づいてダイナミックなHA課題の間、ダイナミックに引き出されるかもしれません。
The mobile node MUST maintain the remaining Mobile IP session with the Assigned HA.
モバイルノードはAssigned 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.
Security Considerations(セクション9)で言及されるように、1HAが移動性の拘束力があるエントリーを与えられたミネソタに作成する可能性があります、中央の凶暴なノードがRegistration Requestをキャプチャして、他のホームのエージェントにそれを送るなら。 ミネソタがホームエージェント分野があるRegistration Requestの(例えば、5秒)がセットした短い生涯を費やすことによってそのような状態を緩和できる、すべて、-、ZERO-ONE- ADDR
The following sections describe MN behavior in FA CoA mode and co- located CoA mode.
以下のセクションはFA CoAモードにおけるミネソタの振舞いと共同見つけられたCoAモードを説明します。
5.1.1. MN Using FA CoA
5.1.1. ファCoAを使用するミネソタ
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セッションを開始して、ホームエージェントアドレス・フィールドをRegistration Requestにはめ込まなければならないか、すべて、-、ZERO-ONE-ADDR. Registration Requestの送付先IPアドレスはFAです。 FAはRequested HAを決定して、Registration RequestをRequested HAに送るでしょう。 登録Request処理は仕様に従ってRequested HAで本書では行われます。
Kulkarni, et al. Standards Track [Page 14] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[14ページ]。
The Registration Request MUST be appropriately authenticated for the HA to validate the Request.
HAがRequestを有効にするように、適切にRegistration Requestを認証しなければなりません。
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.
うまくいっているRegistration Replyが受け取られているなら、ミネソタはReplyのHA分野からAssigned HAを入手します。 Assigned HAアドレスはRequested HA Extensionと同じになるでしょう、それがRegistration Requestでミネソタによって含められたなら。
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と共にRegistration Replyを受け取るなら、HAアドレスがRedirected HA Extensionで指定されている状態で、ミネソタはReplyと試みRegistrationのHA分野でHAアドレスに基づくReplyを認証しなければなりません。 ミネソタは新しいRegistration RequestのRequested HA ExtensionとしてRedirected 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.
いくつかの場合、最初のRegistration Requestに関して、ミネソタは、特定のHAに据えつけられるためにネットワークをほのめかしたがっているかもしれません。 MN SHOULDはRequested HA ExtensionのHAアドレスにそのアドレスを入れます。
5.1.2. MN Using Co-Located CoA
5.1.2. 共同見つけられたCoAを使用するミネソタ
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モードによるミネソタはZERO-ONE-ADDRへのRegistration Requestにホームエージェントアドレス・フィールドをはめ込まなければなりません。Registration Requestの送付先IPアドレスはRequested HAです。 どうRequested 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.
うまくいっているReplyが受け取られているなら、ミネソタはうまくいっているRegistration ReplyからAssigned HAアドレスを得ます。 Assigned HAはRegistration Requestが送られたRequested HAと同じになるでしょう。 ミネソタはモバイルIPセッションの長さのためのAssigned HAアドレスをキャッシュしなければなりません。 そして、モバイルノードはその後のRe-登録とDe-登録Request(s)におけるホームエージェントアドレスとしてこの以前にキャッシュされたAssigned 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と共にRegistration Replyを受け取るなら、HAアドレスがRedirected HA Extensionで指定されている状態で、ミネソタはReplyと試みRegistrationのHA分野でHAアドレスに基づくReplyを認証しなければなりません。 ミネソタは新しいRegistration RequestのRequested HA ExtensionにRedirected 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.
いくつかの場合、最初のRegistration Requestに関して、ミネソタは特定のHAに据えつけられるためにネットワークをほのめかしたがっているかもしれません、そして、MN SHOULDはRequested HA ExtensionのHAアドレスにそのアドレスを入れます。
Kulkarni, et al. Standards Track [Page 15] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[15ページ]。
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とともに記名している間、Requested HA Extensionは含まなければならなくて、Registration Requestが送られるHAのアドレスを含まなければなりません。 FA、共同見つけられたCoAを使用しますが、レガシーで登録するとき、Registration RequestのHA分野はRequested HAに設定されるかもしれません。
If the Registration Request contains the Requested HA Extension, the HA address in that extension MUST match the destination IP of the Request.
Registration RequestがRequested HA Extensionを含んでいるなら、その拡大におけるHAアドレスはRequestの目的地IPに合わなければなりません。
5.1.3. Refreshing Assigned HA Address on Mobile Node
5.1.3. リフレッシュが割り当てた、ハ、モバイルノードに関するアドレス
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セッションが終わると、モバイルノードはホームエージェントアドレスとしてキャッシュされたAssigned HAアドレスをクリアするかもしれません。 それは、Requested HA Extensionを含んでいないことによって、新しいモバイル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.
ミネソタが交互に、Assigned HAがアドレスであると保存して、Requested HA Extensionでそれを使用するかもしれない、すべて、-、ZERO-ONE-ADDR HA、新しいモバイルIPセッションのためのRegistration Requestのアドレス。
5.2. Foreign Agent Considerations
5.2. 外国エージェント問題
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を通していつも登録されます。 ミネソタが共同見つけられたCoAを使用しているとき、FAを通して登録するかもしれませんか、または直接HAとともに記名するかもしれません、それがFAのエージェント広告、FAを通していつもどのケースを登録するかでRビットが設定されない場合。
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.
HAアドレス・フィールドがセットした状態でFAがいつまでRegistration Requestを受けるか、すべて、-、ZERO-ONE-ADDR、それはRequested HA Extensionを含んでいなくて、FAは、この仕様の範囲の外で手段を使用することでRegistration Requestを進めるためにRequested HAアドレスを得ます。 どうRequested 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がRegistration Requestをミネソタから送るRequested HAを入手できないなら、それはエラーコードNONZERO-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.
ミネソタがRequested HA Extensionを含めたなら、FA MUSTはこの拡大でRegistration Requestをアドレスに送ります。 この拡大におけるHAアドレスが発送可能ユニキャストアドレスでないなら、FA MUSTはエラーコードNONZERO-HA- REQDとの要求を拒絶します。
Kulkarni, et al. Standards Track [Page 16] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[16ページ]。
If the Registration Request contains the Requested HA Extension, the FA uses that address as the destination for the relayed Registration Request.
Registration RequestがRequested HA Extensionを含んでいるなら、FAはリレーされたRegistration Requestに目的地としてそのアドレスを使用します。
Backward-compatibility issues related to the mobility agents are addressed in Section 10.
移動性エージェントと関係がある後方の互換性の問題はセクション10で扱われます。
5.3. Home Agent Considerations
5.3. ホームエージェント問題
A home agent can process an incoming Registration Request in one of the following two ways:
ホームのエージェントは以下の2つの方法の1つで入って来るRegistration Requestを処理できます:
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. ミネソタかFAがRegistration RequestをRequested HAに送ります。 Requested HAという用語には、Registration Requestメッセージの文脈での意味があります。 Requested HAが首尾よくRegistration Requestを処理して、結合を作成して、アドレスと共に返信するとき、それはAssigned HAになります。 Assigned HAという用語はRegistration Replyメッセージの文脈で重要です。
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. HA分野をセットしてある状態でRegistration Requestを受け取るホームのエージェント、すべて、-、ZERO-ONE-ADDR MAY、首尾よく認証されても、要求を拒絶してください、そして、Replyの代替のHAアドレスを示してください。 このような場合には、HAはReplyのHA分野にそれ自身のアドレスを置いて、ReplyコードをREDIRECT-HA-REQに設定して、Redirected HA Extensionを加えます。
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.
Registration RequestがRequested HA Extensionを含んでいるなら、その拡大におけるHAアドレスはRequestの目的地IPに合わなければなりません。 合っていないなら、Requested HAはエラーコード136でRegistration Requestを拒絶しなければなりません。
5.3.1. Assigned Home Agent Considerations
5.3.1. 割り当てられたホームエージェント問題
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]とこの仕様通りに入って来るRegistration Requestを完全に処理するHAはAssigned HAになります。 Registration RequestはAssigned 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.
Assigned HAは、ホームエージェント分野とReplyのソースIPアドレスとしてアドレスをコピーすることによって、1ミネソタあたり1つの移動性結合を作成して、Registration Replyをミネソタに送ります。
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.
以下のテーブルはRegistration Requestの送付先IPアドレスとホームエージェント分野の値に基づいてAssigned HAの動きをまとめます。
Kulkarni, et al. Standards Track [Page 17] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[17ページ]。
Dest IP Addr HA field Processing at Assigned HA ------------ ------------ ----------------------------------
Assigned HAのDest IP Addr HA分野Processing------------ ------------ ----------------------------------
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].
ユニキャストの非ユニキャストのモバイルIPv4[1]: 取り扱いにおける変化が全くこのような場合ない、(モバイルIPv4それがここに等しい状態で言及されるということでなければならない、参照だけのために. HA受信HAは[1]でRRQとの登録) エラーコード136とHAがセクション3.8.3に従って回答におけるそれ自身のIPアドレスとしてさばくセットに対して.2を否定します。
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.
オール無新しさ、振舞い: この1ONE-ADDRあたりの仕様としてRRQを認めてください。 RRQを認証してください、そして、HAがAssigned HAとして機能しているなら、拘束力があった状態で移動性を作成してください。 Registration Replyのそれ自身のIPアドレスにHA分野を設定してください。
OR
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.
新しい振舞い: 認証がうまくいくなら、新しい誤りがある廃棄物RRQはREDIRECT-HA-REQをコード化します。 HAはRejectのHAアドレス・フィールドにアドレスを置きます。 HAは新しいRedirected HA Extensionにおける使用に代替のHAを勧めます。
Table 1: Registration Request Handling at Assigned HA
テーブル1: 割り当てられるところの登録要求取り扱い、ハ。
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.
ここで提案されたメッセージングに従って、モバイルノード(または、外国人のエージェント)はRequested HAアドレスにRegistration Requestを送ります。(それは、ユニキャストアドレスです)。 したがって、このドキュメントはHAがセクション3.8.2で.1のモバイルIPv4仕様[1]を指定するのでサブネットの指示された放送Registration Requestを受けるケースのための少しの新しい振舞いも指定しません。 Registration Requestのホームエージェント分野はユニキャストアドレスではありませんが、送付先IPアドレスはユニキャストアドレスです。 これは応じることにおける複数のHAsをもたらすかもしれないサブネットで指示された放送送付先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アドレスがユニキャストアドレスであり、ホームエージェント分野がアドレスである、すべて、-、ZERO-ONE-ADDR、HAは回答におけるそれ自身のIPアドレスに登録を受け入れるか、または否定して、HA分野を設定します(すなわち、登録はエラーコード136で拒絶されません)。
Kulkarni, et al. Standards Track [Page 18] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[18ページ]。
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を勧めることができます。 ベースのロードバランシングに中古の、そして、地理的な近接が進行中であったならこのリダイレクションがそうすることができる、Care、-、Address、または他の理由。 HAはRegistration ReplyメッセージのHA分野にそれ自身のアドレスを置いて、向け直されたHAのアドレスをRedirected HA Extensionに入れます。 HAが要請を受け入れるなら、それはそれ自身のアドレスへのRegistration Replyに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].
Requested HAはいつも標準のバリディティチェックをRegistration Requestに実行します。 何か誤りがあれば、エラーコードがモバイルIPv4[1]で指定されている状態で、Registration Requestは拒絶されます。
6. Requested Home Agent Selection
6. 要求されたホームエージェント選択
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課題が要求されているとき、ミネソタ(または、FAを通した登録の場合におけるFA)はRegistration RequestをRequested HAに送ります。 このアドレスはユニキャストIPアドレスであるに違いありません。 ミネソタがRegistration RequestでRequested HA Extensionを含めたなら、この拡大におけるHAアドレスはRequested HAです。
Some examples of methods by which the MN or the FA may select the Requested HA are briefly described below:
ミネソタかFAがRequested 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.
ミネソタは、訪問されたネットワークに関するIPアドレスを得るためにDHCPを実行します。 Requested HAはDHCPのモバイルIPホームエージェントOption68[4]から学習されます。 ミネソタは、直接このHAにRegistration Requestを送って、モバイルIPセッションの残りに使用されるためにAssigned 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.
ミネソタはFAと共に挑戦/応答[5]を実行します。 FAはAAAサーバからRequested HAを検索して、直接このHAにRegistration Requestを送ります。 Assigned HAはRegistration ReplyをFAに送ります。(FAはミネソタにそれをリレーします)。 ミネソタはモバイルIPセッションの残りにAssigned 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に関するホスト名をミネソタで構成するか、またはある他の手段で得て、例えば、使用はサービス位置のプロトコルです。 ミネソタはHAホスト名にDNSルックアップを実行します。 DNSインフラストラクチャは、最適のHAをミネソタに特定するためにリソース記録に情報を提供します。 ミネソタは、直接HAにRegistration Requestを送って、モバイルIPセッションの残りに使用されるためにAssigned HAを受けます。
Kulkarni, et al. Standards Track [Page 19] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[19ページ]。
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アドレスはミネソタで静的に構成されます。 ミネソタは構成されたアドレスにRegistration Requestを送ります。 そして、Requested HAはRedirected HAにミネソタを向け直すかもしれません。
7. Error Values
7. 誤り値
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.
以下のテーブルの各エントリーはエラーコードがRegistration Replyで返される名前と値を含んでいます。 また、それはエラーコードが最初に本書では言及されるセクションを含んでいます。
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.
エラー名値のセクション記述--------------- ----- ------- ----------------------------- NONZERO-HA-REQD90 5.2Non-ゼロHAアドレスがRegistration Requestで必要です。 REDIRECT-HA-REQ143 5.3は向け直されたHAにRe登録します。
8. IANA Considerations
8. IANA問題
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).
コード値NONZERO-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).
Dynamic HA Extensionはホームのエージェント(すなわち、範囲128-255の値)におけるskippable拡張子に関連している値の範囲から割り当てられます。
IANA has recorded the values as defined in Sections 7 and 3.4.
IANAはセクション7と3.4で定義されるように値を記録しました。
9. Security Considerations
9. セキュリティ問題
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].
この仕様は、セキュリティ設定がミネソタとHAの間であらかじめ設定されるか、または[7]に従って初期のRegistration Request/登録Replyと共に構成されたと仮定します。
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
そして、1HAが移動性の拘束力があるエントリーを与えられたミネソタに作成する可能性があります、HA分野をセットしてある状態で中央の男性がRegistration Requestをキャプチャするならすべて、-、ZERO-ONE-ADDR、他のHAsにそれを送ります。 このシナリオは、凶暴なノードがRegistration Requestを認証できるHAsのアドレスを見つけることができると仮定します。 また、それは、凶暴なノードには他のHAsにパケットを保存して、コピーして、送る能力があると仮定します。
Kulkarni, et al. Standards Track [Page 20] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[20ページ]。
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.
再生ウィンドウの限られた時中に。 さもなければ、これらのHAsはとにかくRegistration Requestsを拒絶するでしょう。 Requested HA Extensionが登録メッセージに含まれていないときだけ、さらに、このタイプの攻撃は可能です。 モバイルノードは、Registration Requestで短い生涯(例えば、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].
このドキュメントのメッセージングに従って、AssignedホームのエージェントはモバイルIPv4[1]に従って入って来るRegistration Requestを処理するでしょう。 したがって、AssignedホームのエージェントはモバイルIPv4[1]にホームのエージェントのものと同じ安全上の配慮を持つでしょう。 それらはセクション5、モバイルIPv4[1]の「セキュリティ問題」で扱われます。
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.
Registration RequestとRegistration Replyメッセージはモバイル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].
または、例、どこがミネソタと個々のHAとのセキュリティ協会であるか、(要求、Assigned) [7]で定義されるようにミネソタとAAAインフラストラクチャの間の共有秘密キーに基づく登録手続の間、ダイナミックに引き出されます。 Registration Requestはミネソタ-AAA Authentication Extensionと共に保護されます、そして、Registration Replyはミネソタ-HA Authentication Extensionと共に保護されます。 セキュリティ協会が共有されるので、ミネソタと何かAAA、局所領域のダイナミックに割り当てられたHAの間では、プロキシは[7]に従ってAAAを使用することでミネソタを認証できますか?
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.
AssignedホームのエージェントはモバイルIPv4[1]、そして/または、RFC3012の指定されるとしてのモバイルノードから各Registration Requestを認証します。 また、ミネソタはAssigned HAからRegistration Replyを認証します。 したがって、モバイルIPv4[1]の既存の信頼モデルは維持されます。
10. Backward-Compatibility Considerations
10. 後方の互換性問題
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つのノードがそうする他のノードの文脈の仕様を履行しない「レガシー」ノードであるケースを考えます。
Kulkarni, et al. Standards Track [Page 21] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[21ページ]。
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でRegistration Requestを拒絶するかもしれません。 しかしながら、このドキュメントによると、いくつかのレガシーHA実装がRegistration Requestを一致して処理するかもしれません、Registration RequestのHA分野が設定されるときすべて、-、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.
家のエージェント分野をセットしてある状態で遺産の外国人のエージェントがRegistration Requestを進めるかもしれない、すべて、-、ZERO-ONE-ADDR、送付先IPアドレスを設定する、すべて、-、ZERO-ONE-ADDR. これはパケットをもたらして、低下するか次のホップHAによって偶然に扱われるでしょう、FAに隣接して。 ミネソタは、低下しているRegistration Requestを意識していないかもしれなくて、たぶん登録を再試行するかもしれません、その結果、登録の遅れを増加させます。
To reduce the delay in registration, the MN should take the following steps:
登録の遅れを減少させるために、ミネソタは以下の方法を採るべきです:
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. ミネソタは指定されるとしてのこの仕様によるRegistration Requestを送るべきです。 そして、言い換えれば、ミネソタがRegistration Requestのホームエージェント分野を設定するべきである、すべて、-、ZERO-ONE-ADDR、また、Requested HA Extensionを加えてください。
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. いつかいくつかのRegistration Requestsを送った後にミネソタがRegistration Replyを受けないなら、Registration Request(s)が落とされたと仮定できて、遺産で、どちらかが、FAか不正確なHAです。 さらに、登録がエラーコード70(不十分に形成されたRequest)で否定されるなら、ミネソタは、遺産FAがこのメッセージを処理できないと仮定できます。 どちらの場合ではも、ミネソタは回収機構へ後ろへ下がるべきです。 ミネソタはセクション4.1ステップ2で言及されるようにすばやく新しいRegistration Requestを送るべきです。 このステップは、FAがそうする遺産がその結果ダイナミックなHA課題を可能にしている家のエージェントにRegistration Requestを送るのを確実にするでしょう。
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分野を設定しないFAにRegistration Requestを送るミネソタ、すべて、-、ZERO-ONE-ADDR、ちょうどRFC3344によると、静的に構成されたHAに登録され続けるでしょう。
Kulkarni, et al. Standards Track [Page 22] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[22ページ]。
11. Acknowledgements
11. 承認
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.
作者が徹底的なレビュー、セキュリティ問題における提案、および定義のためのピートマッキャンに感謝したがっている、すべて、-、ZERO- ONE-ADDR. このドキュメントの大量のレビューとコメントをKuntalチョードリをありがとうございます。 また、詳細なレビューと提案のためにHenrik Levkowetzをありがとうございます。 トーマスNartenは遺産FA問題のために問題を強調しました。 Security Considerations部で記録されたHAsで複数の結合のシナリオをアフマドMuhannaに指摘してくださってありがとうございます。
The authors would like to thank Mike Andrews, Madhavi Chandra, and Yoshi Tsuda for their review and suggestions.
作者は彼らのレビューと提案のためのマイク・アンドリュース、Madhaviチャンドラ、およびYoshi津田に感謝したがっています。
12. Normative References
12. 引用規格
[1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[1] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[2] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000.
[2] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」
[3] Senie, D., "Changing the Default for Directed Broadcasts in
Routers", BCP 34, RFC 2644, August 1999.
[3]Senie、D.、「ルータにおける指示された放送のためのデフォルトを変えます」、BCP34、RFC2644、1999年8月。
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[4] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTP業者拡大」、RFC2132、1997年3月。
[5] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response
Extensions", RFC 3012, November 2000.
[5] パーキンスとC.とP.カルフーン、「モバイルIPv4挑戦/応答拡大」、RFC3012、2000年11月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Perkins, C. and P. Calhoun, "Authentication, Authorization, and
Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
March 2005.
[7] パーキンス、C.、P.カルフーン、「認証、認可、2005年3月にモバイルIPv4"、RFC3957年のためにRegistrationキーズを説明(AAA)であること」。
Kulkarni, et al. Standards Track [Page 23] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[23ページ]。
Authors' Addresses
作者のアドレス
Milind Kulkarni Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
Milind KulkarniシスコシステムズInc.170W.タスマンのドライブ、サンノゼ、カリフォルニア95134米国
Phone: +1 408-527-8382 EMail: mkulkarn@cisco.com
以下に電話をしてください。 +1 408-527-8382 メールしてください: mkulkarn@cisco.com
Alpesh Patel Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
AlpeshパテルシスコシステムズInc.170W.タスマンのドライブ、サンノゼ、カリフォルニア95134米国
Phone: +1 408-853-9580 EMail: alpesh@cisco.com
以下に電話をしてください。 +1 408-853-9580 メールしてください: alpesh@cisco.com
Kent Leung Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA
ケントレオンシスコシステムズ株式会社170W.タスマンのドライブ、サンノゼ、カリフォルニア95134米国
Phone: +1 408-526-5030 EMail: kleung@cisco.com
以下に電話をしてください。 +1 408-526-5030 メールしてください: kleung@cisco.com
Kulkarni, et al. Standards Track [Page 24] RFC 4433 Dynamic HA Assignment March 2006
Kulkarni、他 規格はハ、2006年の課題行進のときにRFC4433動力を追跡します[24ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Kulkarni, et al. Standards Track [Page 25]
Kulkarni、他 標準化過程[25ページ]
一覧
スポンサーリンク
