[要約] RFC 5944は、IPv4のためのIPモビリティサポートに関する規格であり、モビリティの管理と通信の維持を改善することを目的としています。
Internet Engineering Task Force (IETF) C. Perkins, Ed.
Request for Comments: 5944 WiChorus Inc.
Obsoletes: 3344 November 2010
Category: Standards Track
ISSN: 2070-1721
IP Mobility Support for IPv4, Revised
IPv4のIPモビリティサポート、改訂
Abstract
概要
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
このドキュメントは、インターネット内のモバイルノードへのIPデータグラムの透明なルーティングを可能にするプロトコルの強化を指定します。各モバイルノードは、インターネットへの現在の添付ポイントに関係なく、常に自宅の住所によって識別されます。自宅から離れている間、モバイルノードはまた、インターネットへの現在の添付ポイントに関する情報を提供する住所にも関連付けられています。プロトコルは、住所のケアをホームエージェントに登録することを規定しています。ホームエージェントは、トンネルを介してモバイルノード用に運命づけられたデータグラムを住所まで送信します。トンネルの終わりに到着した後、各データグラムはモバイルノードに配信されます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5944.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5944で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Protocol Requirements ......................................5
1.2. Goals ......................................................6
1.3. Assumptions ................................................6
1.4. Applicability ..............................................6
1.5. New Architectural Entities .................................7
1.6. Terminology ................................................7
1.7. Protocol Overview .........................................11
1.8. Message Format and Protocol Extensibility .................14
1.9. Type-Length-Value Extension Format for Mobile IP
Extensions ................................................16
1.10. Long Extension Format ....................................17
1.11. Short Extension Format ...................................18
2. Agent Discovery ................................................18
2.1. Agent Advertisement .......................................19
2.1.1. Mobility Agent Advertisement Extension .............21
2.1.2. Prefix-Lengths Extension ...........................23
2.1.3. One-Byte Padding Extension .........................24
2.2. Agent Solicitation ........................................24
2.3. Foreign Agent and Home Agent Considerations ...............24
2.3.1. Advertised Router Addresses ........................26
2.3.2. Sequence Numbers and Rollover Handling .............26
2.4. Mobile Node Considerations ................................26
2.4.1. Registration Required ..............................28
2.4.2. Move Detection .....................................28
2.4.3. Returning Home .....................................29
2.4.4. Sequence Numbers and Rollover Handling .............29
3. Registration ...................................................29
3.1. Registration Overview .....................................30
3.2. Authentication ............................................31
3.3. Registration Request ......................................32
3.4. Registration Reply ........................................34
3.5. Registration Extensions ...................................38
3.5.1. Computing Authentication Extension Values ..........38
3.5.2. Mobile-Home Authentication Extension ...............39
3.5.3. Mobile-Foreign Authentication Extension ............40
3.5.4. Foreign-Home Authentication Extension ..............40
3.6. Mobile Node Considerations ................................41
3.6.1. Sending Registration Requests ......................43
3.6.2. Receiving Registration Replies .....................47
3.6.3. Registration Retransmission ........................50
3.7. Foreign Agent Considerations ..............................50
3.7.1. Configuration and Registration Tables ..............51
3.7.2. Receiving Registration Requests ....................52
3.7.3. Receiving Registration Replies .....................56
3.8. Home Agent Considerations .................................58
3.8.1. Configuration and Registration Tables ..............58
3.8.2. Receiving Registration Requests ....................59
3.8.3. Sending Registration Replies .......................64
4. Routing Considerations .........................................66
4.1. Encapsulation Types .......................................67
4.2. Unicast Datagram Routing ..................................67
4.2.1. Mobile Node Considerations .........................67
4.2.2. Foreign Agent Considerations .......................68
4.2.3. Home Agent Considerations ..........................69
4.3. Broadcast Datagrams .......................................70
4.4. Multicast Datagram Routing ................................71
4.5. Mobile Routers ............................................72
4.6. ARP, Proxy ARP, and Gratuitous ARP ........................74
5. Security Considerations ........................................77
5.1. Message Authentication Codes ..............................77
5.2. Areas of Security Concern in This Protocol ................78
5.3. Key Management ............................................78
5.4. Picking Good Random Numbers ...............................78
5.5. Privacy ...................................................79
5.6. Ingress Filtering .........................................79
5.7. Replay Protection for Registration Requests ...............79
5.7.1. Replay Protection Using Timestamps .................80
5.7.2. Replay Protection Using Nonces .....................81
6. IANA Considerations ............................................82
6.1. Mobile IP Message Types ...................................82
6.2. Extensions to RFC 1256 Router Advertisement Messages ......83
6.3. Extensions to Mobile IP Registration Messages .............83
6.4. Code Values for Mobile IP Registration Reply Messages .....84
7. Acknowledgments ................................................84
8. References .....................................................86
8.1. Normative References ......................................86
8.2. Informative References ....................................87
Appendix A. Link-Layer Considerations .............................90
Appendix B. TCP Considerations ....................................90
B.1. TCP Timers ................................................90
B.2. TCP Congestion Management .................................91
Appendix C. Example Scenarios ....................................92
C.1. Registering with a Foreign Agent Care-of Address ..........92
C.2. Registering with a Co-Located Care-of Address .............93
C.3. Deregistration ............................................94
Appendix D. Applicability of Prefix-Lengths Extension .............94
Appendix E. Interoperability Considerations .......................95
Appendix F. Changes since RFC 3344 ................................96
Appendix G. Example Messages ......................................98
G.1. Example ICMP Agent Advertisement Message Format ...........98
G.2. Example Registration Request Message Format ...............99
G.3. Example Registration Reply Message Format ................100
IP version 4 assumes that a node's IP address uniquely identifies the node's point of attachment to the Internet. Therefore, a node must be located on the network indicated by its IP address in order to receive datagrams destined to it; otherwise, datagrams destined to the node would be undeliverable. For a node to change its point of attachment without losing its ability to communicate, currently one of the two following mechanisms must typically be employed:
IPバージョン4は、ノードのIPアドレスがインターネットへのノードの添付ポイントを一意に識別すると想定しています。したがって、Nodeは、それに向けられたデータグラムを受信するために、IPアドレスで示されるネットワーク上に配置する必要があります。それ以外の場合、ノードに運命づけられているデータグラムは配達不可能です。ノードが通信能力を失うことなく添付ファイルのポイントを変更するには、現在、次の2つのメカニズムの1つを通常採用する必要があります。
o the node must change its IP address whenever it changes its point of attachment, or
o ノードは、IPアドレスが添付のポイントを変更するたびに変更する必要があります。
o host-specific routes must be propagated throughout much of the Internet routing fabric.
o ホスト固有のルートは、インターネットルーティングファブリックの多くで伝播する必要があります。
Both of these alternatives are often unacceptable. The first makes it impossible for a node to maintain transport and higher-layer connections when the node changes location. The second has obvious and severe scaling problems, especially relevant considering the explosive growth in sales of notebook (mobile) computers.
これらの選択肢は両方とも受け入れられないことがよくあります。1つ目は、ノードが位置を変更したときにノードが輸送と高層接続を維持することを不可能にします。2つ目には、ノートブック（モバイル）コンピューターの販売の爆発的な成長を考慮すると、特に関連する明らかなスケーリングの問題があります。
A new, scalable mechanism is required for accommodating node mobility within the Internet. This document defines such a mechanism, which enables nodes to change their point of attachment to the Internet without changing their IP address.
インターネット内のノードモビリティに対応するには、新しいスケーラブルなメカニズムが必要です。このドキュメントでは、このようなメカニズムを定義しているため、ノードはIPアドレスを変更せずにインターネットへの添付ポイントを変更できます。
Changes between this revised specification for Mobile IP and the original specifications (see [44], [14], [15], [20], [4], and [50]) are detailed in Appendix F.
モバイルIPのこの改訂された仕様と元の仕様の間の変更（[44]、[14]、[15]、[20]、[4]、および[50]を参照）については、付録Fに詳しく説明します。
A mobile node must be able to communicate with other nodes after changing its link-layer point of attachment to the Internet, yet without changing its IP address.
モバイルノードは、IPアドレスを変更せずに、インターネットへのリンク層の添付ポイントを変更した後、他のノードと通信できる必要があります。
A mobile node must be able to communicate with other nodes that do not implement these mobility functions. No protocol enhancements are required in hosts or routers that are not acting as any of the new architectural entities introduced in Section 1.5.
モバイルノードは、これらのモビリティ関数を実装していない他のノードと通信できる必要があります。セクション1.5で導入された新しいアーキテクチャエンティティのいずれとしても作用していないホストまたはルーターでは、プロトコルの強化は必要ありません。
All messages used to update another node as to the location of a mobile node must be authenticated in order to protect against remote redirection attacks.
モバイルノードの場所に関する別のノードを更新するために使用されるすべてのメッセージは、リモートリダイレクト攻撃から保護するために認証する必要があります。
The link by which a mobile node is directly attached to the Internet may often be a wireless link. This link may thus have a substantially lower bandwidth and higher error rate than traditional wired networks. Moreover, mobile nodes are likely to be battery powered, and minimizing power consumption is important. Therefore, the number of administrative messages sent over the link by which a mobile node is directly attached to the Internet should be minimized, and the size of these messages should be kept as small as is reasonably possible.
モバイルノードがインターネットに直接接続されるリンクは、多くの場合、ワイヤレスリンクになる可能性があります。したがって、このリンクは、従来の有線ネットワークよりも帯域幅が大幅に低く、エラー率が高い場合があります。さらに、モバイルノードはバッテリー駆動の可能性が高く、消費電力を最小限に抑えることが重要です。したがって、モバイルノードがインターネットに直接接続されるリンク上に送信される管理メッセージの数を最小限に抑え、これらのメッセージのサイズは合理的に可能な限り小さく保つ必要があります。
The protocols defined in this document place no additional constraints on the assignment of IP addresses. That is, a mobile node can be assigned an IP address by the organization that owns the machine.
このドキュメントで定義されているプロトコルは、IPアドレスの割り当てに追加の制約がありません。つまり、モバイルノードには、マシンを所有する組織によってIPアドレスを割り当てることができます。
This protocol assumes that mobile nodes will generally not change their point of attachment to the Internet more frequently than once per second.
このプロトコルは、モバイルノードが一般に、1秒あたり1回よりも頻繁にインターネットへの添付ポイントを変更しないと想定しています。
This protocol assumes that IP unicast datagrams are routed based on the Destination Address in the datagram header (and not, for example, by source address).
このプロトコルは、IPユニキャストデータグラムがデータグラムヘッダーの宛先アドレスに基づいてルーティングされることを前提としています（たとえば、ソースアドレスではそうではありません）。
Mobile IP is intended to enable nodes to move from one IP subnet to another. It is just as suitable for mobility across homogeneous media as it is for mobility across heterogeneous media. That is, Mobile IP facilitates node movement from one Ethernet segment to another, as well as from an Ethernet segment to a wireless LAN, as long as the mobile node's IP address remains the same after such a movement.
モバイルIPは、ノードをあるIPサブネットから別のIPサブネットに移動できるようにすることを目的としています。不均一なメディア全体のモビリティと同様に、同種のメディア全体のモビリティに適しています。つまり、モバイルノードのIPアドレスがそのような動きの後も同じままである限り、モバイルIPは、あるイーサネットセグメントから別のイーサネットセグメントから別のイーサネットセグメントへ、およびワイヤレスLANへのノードの動きを促進します。
One can think of Mobile IP as solving the "macro" mobility management problem. It is less well suited for more "micro" mobility management applications -- for example, handoff amongst wireless transceivers, each of which covers only a very small geographic area. As long as node movement does not occur between points of attachment on different IP subnets, link-layer mechanisms for mobility (i.e., link-layer handoff) may offer faster convergence and far less overhead than Mobile IP.
モバイルIPは、「マクロ」モビリティ管理の問題を解決すると考えることができます。より「マイクロ」モビリティ管理アプリケーションにはあまり適していません。たとえば、それぞれが非常に小さな地理的領域のみをカバーするワイヤレストランシーバー間のハンドオフです。異なるIPサブネットのアタッチメントポイント間でノードの動きが発生しない限り、モビリティのためのリンク層メカニズム（つまり、リンク層ハンドオフ）は、モバイルIPよりも速い収束とはるかに少ないオーバーヘッドを提供する可能性があります。
Mobile IP introduces the following new functional entities:
モバイルIPは、次の新しい機能エンティティを紹介します。
Mobile Node
モバイルノード
A host or router that changes its point of attachment from one network or subnetwork to another. A mobile node may change its location without changing its IP address; it may continue to communicate with other Internet nodes at any location using its (constant) IP address, assuming link-layer connectivity to a point of attachment is available.
あるネットワークまたはサブネットワークから別のネットワークに添付のポイントを変更するホストまたはルーター。モバイルノードは、IPアドレスを変更せずに場所を変更する場合があります。（定数）IPアドレスを使用して、任意の場所で他のインターネットノードと通信し続けることがあります。これは、添付ファイルへのリンク層の接続が利用可能であると仮定します。
Home Agent
ホームエージェント
A router on a mobile node's home network that tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node.
モバイルノードのホームネットワーク上のルーターは、自宅から離れたときにモバイルノードに配信し、モバイルノードの現在の位置情報を維持するためにデータグラムをトンネルにします。
Foreign Agent
外国人エージェント
A router on a mobile node's visited network that provides routing services to the mobile node while registered. The foreign agent detunnels and delivers to the mobile node datagrams that were tunneled by the mobile node's home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes.
登録中にモバイルノードにルーティングサービスを提供するモバイルノードの訪問ネットワーク上のルーター。外国のエージェントは、モバイルノードのホームエージェントによってトンネルされたモバイルノードデータグラムにデトゥンネルスと配信します。モバイルノードから送信されたデータグラムの場合、外部エージェントは登録されたモバイルノードのデフォルトルーターとして機能する場合があります。
A mobile node is given a long-term IP address on a home network. This home address is administered in the same way that a "permanent" IP address is provided to a stationary host. When away from its home network, a "care-of address" is associated with the mobile node and reflects the mobile node's current point of attachment. The mobile node uses its home address as the source address of all IP datagrams that it sends, except where otherwise described in this document for datagrams sent for certain mobility management functions (e.g., as in Section 3.6.1.1).
モバイルノードには、ホームネットワークに長期のIPアドレスが与えられます。このホームアドレスは、「永続的な」IPアドレスが固定ホストに提供されるのと同じように管理されます。ホームネットワークから離れると、「アドレスのケア」はモバイルノードに関連付けられており、モバイルノードの現在の添付ポイントを反映しています。モバイルノードは、特定のモビリティ管理関数に送信されたデータグラムのこのドキュメントで説明されている場合を除き、送信するすべてのIPデータグラムのソースアドレスとしてホームアドレスを使用します（例：セクション3.6.1.1のように）。
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 [1].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
In addition, this document frequently uses the following terms:
さらに、このドキュメントは頻繁に次の用語を使用します。
Authorization-Enabling Extension
承認を有する拡張機能
An authentication that makes a (registration) message acceptable to the ultimate recipient of the registration message. An authorization-enabling extension MUST contain a Security Parameter Index (SPI).
（登録）メッセージを登録メッセージの究極の受信者に受け入れられる認証。承認を有する拡張機能には、セキュリティパラメーターインデックス（SPI）を含める必要があります。
In this document, all uses of authorization-enabling extension refer to authentication extensions that enable the Registration Request message to be acceptable to the home agent. Using additional protocol structures specified outside of this document, it may be possible for the mobile node to provide authentication of its registration to the home agent, by way of another authenticating entity within the network that is acceptable to the home agent (for example, see RFC 2794 [2]).
このドキュメントでは、承認を有する拡張機能のすべての使用法は、登録要求メッセージをホームエージェントに受け入れることができる認証拡張機能を参照しています。このドキュメントの外部で指定された追加のプロトコル構造を使用すると、モバイルノードがホームエージェントに登録の認証を提供することが可能である可能性があります。RFC 2794 [2]）。
Agent Advertisement
エージェント広告
An advertisement message constructed by attaching a special Extension to a Router Advertisement [5] message.
ルーター広告[5]メッセージに特別な拡張機能を添付して作成された広告メッセージ。
Authentication
認証
The process of verifying (using cryptographic techniques, for all applications in this specification) the identity of the originator of a message.
メッセージの発信者の身元を検証するプロセス（この仕様のすべてのアプリケーションに対して、暗号化手法を使用）。
Care-of Address
住所の世話
The termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it is away from home. The protocol can use two different types of care-of address: a "foreign agent care-of address" is an address of a foreign agent with which the mobile node is registered, and a "co-located care-of address" is an externally obtained local address that the mobile node has associated with one of its own network interfaces.
モバイルノードに向かうトンネルの終了点は、自宅から離れている間にモバイルノードに転送されるデータグラム用です。プロトコルは、2つの異なるタイプのケアオブアドレスを使用できます。「外国人エージェントケアオブアドレス」は、モバイルノードが登録されている外国人エージェントのアドレスであり、「共同住民の住所」はモバイルノードが独自のネットワークインターフェイスの1つに関連付けられているというローカルアドレスを外部から取得しました。
Correspondent Node
特派員ノード
A peer with which a mobile node is communicating. A correspondent node may be either mobile or stationary.
モバイルノードが通信しているピア。特派員ノードは、モバイルまたは固定性のいずれかです。
Foreign Network
外国ネットワーク
Any network other than the mobile node's home network.
モバイルノードのホームネットワーク以外のネットワーク。
Gratuitous ARP
無償のARP
An Address Resolution Protocol (ARP) packet sent by a node in order to spontaneously cause other nodes to update an entry in their ARP cache [45]. See Section 4.6.
ノードによって送信されるアドレス解像度プロトコル（ARP）パケットにより、他のノードがARPキャッシュのエントリを更新するようにします[45]。セクション4.6を参照してください。
Home Address
自宅の住所
An IP address that is assigned for an extended period of time to a mobile node. It remains unchanged regardless of where the node is attached to the Internet.
モバイルノードに長期間割り当てられたIPアドレス。ノードがインターネットに接続されている場所に関係なく、変更されていません。
Home Network
ホーム・ネットワーク
A network, possibly virtual, having a network prefix matching that of a mobile node's home address. Note that standard IP routing mechanisms will deliver datagrams destined to a mobile node's home address to the mobile node's home network.
おそらく仮想的なネットワークは、モバイルノードのホームアドレスのネットワークのプレフィックスと一致するネットワークのプレフィックスを持っています。標準のIPルーティングメカニズムは、モバイルノードのホームアドレスに移動モバイルノードのホームネットワークに運命づけられているデータグラムを提供することに注意してください。
Link
リンク
A facility or medium over which nodes can communicate at the link layer. A link underlies the network layer.
ノードがリンクレイヤーで通信できる施設または中程度。リンクはネットワークレイヤーの根底にあります。
Link-Layer Address
リンク層アドレス
The address used to identify an endpoint of some communication over a physical link. Typically, the link-layer address is an interface's Media Access Control (MAC) address.
アドレスは、物理的なリンクを介したいくつかの通信のエンドポイントを識別するために使用されます。通常、リンク層アドレスは、インターフェイスのメディアアクセス制御（MAC）アドレスです。
Mobility Agent
モビリティエージェント
Either a home agent or a foreign agent.
ホームエージェントまたは外国人エージェントのいずれか。
Mobility Binding
モビリティバインディング
The association of a home address with a care-of address, along with the remaining Lifetime of that association.
自宅の住所との協会と、その協会の残りの寿命とともに。
Mobility Security Association
モビリティセキュリティ協会
A collection of security contexts, between a pair of nodes, which may be applied to Mobile IP protocol messages exchanged between them. Each context indicates an authentication algorithm and mode (Section 5.1), a secret (a shared key, or appropriate public/ private key pair), and a style of replay protection in use (Section 5.7).
ノードのペア間のセキュリティコンテキストのコレクションは、それらの間で交換されるモバイルIPプロトコルメッセージに適用される場合があります。各コンテキストは、認証アルゴリズムとモード（セクション5.1）、秘密（共有キー、または適切なパブリック/秘密キーペア）、および使用中のリプレイ保護スタイル（セクション5.7）を示します。
Node
ノード
A host or a router.
ホストまたはルーター。
Nonce
nonce
A randomly chosen value, different from previous choices, inserted in a message to protect against replays.
以前の選択肢とは異なるランダムに選択された値は、リプレイから保護するためにメッセージに挿入されました。
Security Parameter Index (SPI)
セキュリティパラメーターインデックス（SPI）
An index identifying a security context between a pair of nodes, among the contexts available in the Mobility Security Association. SPI values 0 through 255 are reserved and MUST NOT be used in any Mobility Security Association.
モビリティセキュリティ協会で利用可能なコンテキストの中で、ノードのペア間のセキュリティコンテキストを識別するインデックス。SPI値0〜255は予約されており、モビリティセキュリティ協会で使用してはなりません。
Tunnel
トンネル
The path followed by a datagram while it is encapsulated. The model is that, while it is encapsulated, a datagram is routed to a knowledgeable decapsulating agent, which decapsulates the datagram and then correctly delivers it to its ultimate destination.
パスに続いて、データグラムがカプセル化されている間にデータグラムが続きます。モデルは、カプセル化されている間、データグラムは知識豊富な脱カプセンティングエージェントにルーティングされ、データグラムを脱カプセル化してから最終的な目的地に正しく配信します。
Virtual Network
仮想ネットワーク
A network with no physical instantiation beyond a router (with a physical network interface on another network). The router (e.g., a home agent) generally advertises reachability to the virtual network using conventional routing protocols.
ルーターを超えて物理的なインスタンス化のないネットワーク（別のネットワークに物理ネットワークインターフェイスがあります）。ルーター（ホームエージェントなど）は、通常、従来のルーティングプロトコルを使用して仮想ネットワークの到達可能性を宣伝します。
Visited Network
訪問ネットワーク
A network other than a mobile node's home network, to which the mobile node is currently connected.
モバイルノードが現在接続されているモバイルノードのホームネットワーク以外のネットワーク。
Visitor List
訪問者リスト
The list of mobile nodes visiting a foreign agent.
外国人エージェントを訪れるモバイルノードのリスト。
The following support services are defined for Mobile IP:
次のサポートサービスは、モバイルIP用に定義されています。
Agent Discovery
エージェントの発見
Home agents and foreign agents may advertise their availability on each link for which they provide service. A newly arrived mobile node can send a solicitation on the link to learn if any prospective agents are present.
ホームエージェントと外国人エージェントは、サービスを提供する各リンクで可用性を宣伝する場合があります。新しく到着したモバイルノードは、リンクに勧誘を送信して、見込み客が存在するかどうかを学習できます。
Registration
登録
When the mobile node is away from home, it registers its care-of address with its home agent. Depending on its method of attachment, the mobile node will register either directly with its home agent, or through a foreign agent that forwards the registration to the home agent.
モバイルノードが自宅から離れると、ホームエージェントとの住所の世話を登録します。添付の方法に応じて、モバイルノードはホームエージェントに直接登録するか、登録をホームエージェントに転送する外国人エージェントを介して登録します。
Silently Discard
静かに捨てます
The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
実装は、さらに処理することなく、および送信者へのエラーを示すことなくデータグラムを破棄します。実装は、破棄されたデータグラムの内容を含むエラーを記録する機能を提供する必要があり、統計カウンターにイベントを記録する必要があります。
The following steps provide a rough outline of operation of the Mobile IP protocol:
次の手順は、モバイルIPプロトコルの操作の大まかな概要を提供します。
o Mobility agents (i.e., foreign agents and home agents) advertise their presence via Agent Advertisement messages (Section 2). A mobile node may optionally solicit an Agent Advertisement message from any locally attached mobility agents through an Agent Solicitation message.
o モビリティエージェント（つまり、外国人エージェントとホームエージェント）は、エージェント広告メッセージを介して存在感を宣伝しています（セクション2）。モバイルノードは、オプションで、エージェントの勧誘メッセージを介して、ローカルに添付されたモビリティエージェントからのエージェント広告メッセージを募集する場合があります。
o A mobile node receives these Agent Advertisements and determines whether it is on its home network or a foreign network.
o モバイルノードはこれらのエージェント広告を受信し、ホームネットワークまたは外国ネットワーク上にあるかどうかを決定します。
o When the mobile node detects that it is located on its home network, it operates without mobility services. If returning to its home network from being registered elsewhere, the mobile node deregisters with its home agent, through exchange of a Registration Request and Registration Reply message with it.
o モバイルノードがホームネットワークにあることを検出すると、モビリティサービスなしで動作します。他の場所に登録されてからホームネットワークに戻ると、登録要求と登録返信メッセージの交換を通じて、ホームエージェントとモバイルノードデレギスターがデレギスターを登録します。
o When a mobile node detects that it has moved to a foreign network, it obtains a care-of address on the foreign network. The care-of address can either be determined from a foreign agent's advertisements (a foreign agent care-of address), or by some external assignment mechanism such as DHCP [34] (a co-located care-of address).
o モバイルノードが外国ネットワークに移動したことを検出すると、外国ネットワーク上の住所の世話を取得します。住所のケアは、外国人のエージェントの広告（外国人エージェントの世話）から決定するか、DHCP [34]などの外部割り当てメカニズム（共同主よ、住所）によって決定できます。
o The mobile node operating away from home then registers its new care-of address with its home agent through exchange of a Registration Request and Registration Reply message with the home agent, possibly via a foreign agent (Section 3).
o 自宅から離れて動作するモバイルノードは、おそらく外国人エージェントを介して、登録要求と登録返信メッセージの交換を通じて、ホームエージェントとの新しいケアのケアをホームエージェントと登録します（セクション3）。
o Datagrams sent to the mobile node's home address are intercepted by its home agent, tunneled by the home agent to the mobile node's care-of address, received at the tunnel endpoint (either at a foreign agent or at the mobile node itself), and finally delivered to the mobile node (Section 4.2.3).
o モバイルノードのホームアドレスに送信されたデータグラムは、ホームエージェントによってモバイルノードのケアオブアドレスにトンネリングされ、トンネルエンドポイント（外国人エージェントまたはモバイルノード自体）、そして最後に受け取ったホームエージェントによって傍受されます。モバイルノードに配信されます（セクション4.2.3）。
o In the reverse direction, datagrams sent by the mobile node are generally delivered to their destination using standard IP routing mechanisms, not necessarily passing through the home agent.
o 逆方向には、モバイルノードによって送信されたデータグラムは、通常、標準のIPルーティングメカニズムを使用して宛先に配信され、必ずしもホームエージェントを通過するわけではありません。
When away from home, Mobile IP uses protocol tunneling to hide a mobile node's home address from intervening routers between its home network and its current location. The tunnel terminates at the mobile node's care-of address. The care-of address must be an address to which datagrams can be delivered via conventional IP routing. At the care-of address, the original datagram is removed from the tunnel and delivered to the mobile node.
自宅から離れると、モバイルIPはプロトコルトンネリングを使用して、ホームネットワークと現在の場所の間に介在するルーターからモバイルノードのホームアドレスを非表示にします。トンネルは、モバイルノードのケアオブアドレスで終了します。住所の世話は、従来のIPルーティングを介してデータグラムを配信できるアドレスでなければなりません。アドレスのケアでは、元のデータグラムがトンネルから削除され、モバイルノードに配信されます。
Mobile IP provides two alternative modes for the acquisition of a care-of address:
モバイルIPは、住所のケアを取得するための2つの代替モードを提供します。
a. A "foreign agent care-of address" is a care-of address provided by a foreign agent through its Agent Advertisement messages. In this case, the care-of address is an IP address of the foreign agent. In this mode, the foreign agent is the endpoint of the tunnel and, upon receiving tunneled datagrams, decapsulates them and delivers the inner datagram to the mobile node. This mode of acquisition is preferred because it allows many mobile nodes to share the same care-of address and therefore does not place unnecessary demands on the already limited IPv4 address space.
a. 「外国人エージェントのケアオブアドレス」は、エージェントの広告メッセージを通じて外国人エージェントが提供する住所です。この場合、ケアオブアドレスは外国人エージェントのIPアドレスです。このモードでは、外部エージェントはトンネルのエンドポイントであり、トンネル付きデータグラムを受信すると、それらを脱カプセル化し、内側のデータグラムをモバイルノードに配信します。この取得モードは、多くのモバイルノードが同じアドレスのケアを共有できるため、すでに限られたIPv4アドレススペースに不必要な要求を置かないため、好ましいです。
b. A "co-located care-of address" is a care-of address acquired by the mobile node as a local IP address through some external means, which the mobile node then associates with one of its own network interfaces. The address may be dynamically acquired as a temporary address by the mobile node, such as through DHCP [34], or may be owned by the mobile node as a long-term address for its use only while visiting some foreign network. Specific external methods of acquiring a local IP address for use as a co-located care-of address are beyond the scope of this document. When using a co-located care-of address, the mobile node serves as the endpoint of the tunnel and itself performs decapsulation of the datagrams tunneled to it.
b. 「共同配置されたアドレス」は、モバイルノードがいくつかの外部手段を介してローカルIPアドレスとして取得したケアアドレスであり、モバイルノードが独自のネットワークインターフェイスの1つに関連付けます。アドレスは、DHCP [34]などのモバイルノードによって一時的なアドレスとして動的に取得されるか、外国のネットワークにアクセスする際にのみ使用するための長期的なアドレスとしてモバイルノードによって所有される場合があります。共同配置されたケアオブアドレスとして使用するためにローカルIPアドレスを取得する特定の外部方法は、このドキュメントの範囲を超えています。共同配置されたアドレスのケアを使用する場合、モバイルノードはトンネルのエンドポイントとして機能し、それ自体がそれにトンネルされたデータグラムの脱カプセル化を実行します。
The mode of using a co-located care-of address has the advantage that it allows a mobile node to function without a foreign agent, for example, in networks that have not yet deployed a foreign agent. It does, however, place additional burden on the IPv4 address space because it requires a pool of addresses within the foreign network to be made available to visiting mobile nodes. It is difficult to efficiently maintain pools of addresses for each subnet that may permit mobile nodes to visit.
共同配置された住所を使用するモードには、たとえば外国人エージェントをまだ展開していないネットワークで、外国人エージェントなしでモバイルノードが機能できるという利点があります。ただし、外国ネットワーク内のアドレスのプールがモバイルノードにアクセスできるようにする必要があるため、IPv4アドレススペースに追加の負担をかけます。モバイルノードがアクセスできる可能性のある各サブネットのアドレスのプールを効率的に維持することは困難です。
It is important to understand the distinction between the care-of address and the foreign agent functions. The care-of address is simply the endpoint of the tunnel. It might indeed be an address of a foreign agent (a foreign agent care-of address), but it might instead be an address temporarily acquired by the mobile node (a co-located care-of address). A foreign agent, on the other hand, is a mobility agent that provides services to mobile nodes. See Sections 3.7 and 4.2.2 for additional details.
住所のケアと外国のエージェント機能の区別を理解することが重要です。住所の世話は、単にトンネルのエンドポイントです。それは確かに外国人エージェント（外国人エージェントのケアオブアドレス）の住所かもしれませんが、代わりにモバイルノード（共同開催のケアオブアドレス）によって一時的に取得される住所かもしれません。一方、外国のエージェントは、モバイルノードにサービスを提供するモビリティエージェントです。詳細については、セクション3.7および4.2.2を参照してください。
A home agent MUST be able to attract and intercept datagrams that are destined to the home address of any of its registered mobile nodes. Using the proxy and gratuitous ARP mechanisms described in Section 4.6, this requirement can be satisfied if the home agent has a network interface on the link indicated by the mobile node's home address. Other placements of the home agent relative to the mobile node's home location MAY also be possible using other mechanisms for intercepting datagrams destined to the mobile node's home address. Such placements are beyond the scope of this document.
ホームエージェントは、登録されたモバイルノードのいずれかのホームアドレスに運命づけられているデータグラムを引き付けて傍受できる必要があります。セクション4.6で説明したプロキシおよび無償のARPメカニズムを使用して、ホームエージェントがモバイルノードのホームアドレスで示されるリンクにネットワークインターフェイスを持っている場合、この要件を満たすことができます。モバイルノードのホームロケーションに対するホームエージェントのその他の配置は、モバイルノードのホームアドレスに向けられたデータグラムを傍受するために他のメカニズムを使用して可能になる場合があります。このような配置は、このドキュメントの範囲を超えています。
Similarly, a mobile node and a prospective or current foreign agent MUST be able to exchange datagrams without relying on standard IP routing mechanisms; that is, those mechanisms that make forwarding decisions based upon the network-prefix of the Destination Address in the IP header. This requirement can be satisfied if the foreign agent and the visiting mobile node have an interface on the same link. In this case, the mobile node and foreign agent simply bypass their normal IP routing mechanism when sending datagrams to each other, addressing the underlying link-layer packets to their respective link-layer addresses. Other placements of the foreign agent relative to the mobile node MAY also be possible using other mechanisms to exchange datagrams between these nodes, but such placements are beyond the scope of this document.
同様に、モバイルノードと将来の外国人エージェントは、標準のIPルーティングメカニズムに依存せずにデータグラムを交換できる必要があります。つまり、IPヘッダー内の宛先アドレスのネットワークプレフィックスに基づいて転送決定を下すメカニズムです。この要件は、外国人エージェントと訪問モバイルノードが同じリンクにインターフェイスを持っている場合に満たすことができます。この場合、モバイルノードと外部エージェントは、データグラムを相互に送信するときに通常のIPルーティングメカニズムをバイパスし、基礎となるリンク層パケットをそれぞれのリンク層アドレスにアドレス指定します。モバイルノードに対する外国エージェントの他の配置も、他のメカニズムを使用してこれらのノード間でデータグラムを交換する可能性がありますが、そのような配置はこのドキュメントの範囲を超えています。
2) Datagram is intercepted 3) Datagram is
by home agent and detunneled and
is tunneled to the delivered to the
care-of address. mobile node.
+-----+ +-------+ +------+
|home | =======> |foreign| ------> |mobile|
|agent| | agent | <------ | node |
+-----+ +-------+ +------+
1) Datagram to /|\ /
mobile node | / 4) For datagrams sent by the
arrives on | / mobile node, standard IP
home network | / routing delivers each to its
via standard | |_ destination. In this figure,
IP routing. +----+ the foreign agent is the
|host| mobile node's default router.
+----+
Figure 1: Operation of Mobile IPv4
図1：モバイルIPv4の動作
If a mobile node is using a co-located care-of address (as described in item (b) above), the mobile node MUST be located on the link identified by the network prefix of this care-of address. Otherwise, datagrams destined to the care-of address would be undeliverable.
モバイルノードが共同配置のケアオブアドレスを使用している場合（上記のアイテム（b）項目（b）で説明されている）、モバイルノードは、このアドレスのネットワークプレフィックスで識別されるリンクに配置する必要があります。それ以外の場合、住所のケアに運命づけられているデータグラムは配信不可能です。
For example, Figure 1 illustrates the routing of datagrams to and from a mobile node away from home, once the mobile node has registered with its home agent. In Figure 1, the mobile node is using a foreign agent care-of address, not a co-located care-of address.
たとえば、図1は、モバイルノードがホームエージェントに登録された後、自宅から離れたモバイルノードとの間のデータグラムのルーティングを示しています。図1では、モバイルノードは、共同配置されたケアオブアドレスではなく、外国のエージェントケアオブアドレスを使用しています。
Mobile IP defines a set of new control messages, sent with UDP [17] using well-known port number 434. The following two message types are defined in this document:
モバイルIPは、有名なポート番号434を使用してUDP [17]で送信された新しい制御メッセージのセットを定義します。次の2つのメッセージタイプは、このドキュメントで定義されています。
1 Registration Request
1登録リクエスト
3 Registration Reply
3登録返信
Up-to-date values for the message types for Mobile IP control messages are specified in the IANA online database [48].
モバイルIPコントロールメッセージのメッセージタイプの最新の値は、IANAオンラインデータベース[48]で指定されています。
In addition, for Agent Discovery, Mobile IP makes use of the existing Router Advertisement and Router Solicitation messages defined for ICMP Router Discovery [5].
さらに、エージェントの発見のために、モバイルIPは、ICMPルーターの発見に定義された既存のルーター広告とルーターの勧誘メッセージを利用しています[5]。
Mobile IP defines a general Extension mechanism to allow optional information to be carried by Mobile IP control messages or by ICMP Router Discovery messages. Some extensions have been specified to be encoded in the simple Type-Length-Value format described in Section 1.9.
モバイルIPは、モバイルIP制御メッセージまたはICMPルーターディスカバリーメッセージによってオプションの情報を実施できるようにする一般的な拡張メカニズムを定義します。一部の拡張機能は、セクション1.9で説明されている単純なタイプ長価値形式でエンコードされるように指定されています。
Extensions allow variable amounts of information to be carried within each datagram. The end of the list of extensions is indicated by the total length of the IP datagram.
拡張機能を使用すると、各データグラム内で変動量の情報を運ぶことができます。拡張機能のリストの終了は、IPデータグラムの全長で示されます。
Two separately maintained sets of numbering spaces, from which Extension Type values are allocated, are used in Mobile IP:
拡張タイプの値が割り当てられる2つの個別に保守されている番号付けスペースのセットが、モバイルIPで使用されます。
o The first set consists of those Extensions that may appear in Mobile IP control messages (those sent to and from UDP port number 434). In this document, the following types are defined for Extensions appearing in Mobile IP control messages:
o 最初のセットは、モバイルIPコントロールメッセージ（UDPポート番号434に送信されるもの）に表示される可能性のある拡張機能で構成されています。このドキュメントでは、モバイルIPコントロールメッセージに表示される拡張機能に対して次のタイプが定義されています。
0 One-byte Padding (encoded with neither Length nor Data field) 32 Mobile-Home Authentication 33 Mobile-Foreign Authentication 34 Foreign-Home Authentication
0ワンバイトパディング（長さもデータフィールドもエンコード）32モバイルホーム認証33モバイル外国認証
o The second set consists of those Extensions that may appear in ICMP Router Discovery messages [5]. In this document, the following types are defined for Extensions appearing in ICMP Router Discovery messages:
o 2番目のセットは、ICMPルーターディスカバリーメッセージに表示される可能性のある拡張機能で構成されています[5]。このドキュメントでは、ICMPルーターディスカバリーメッセージに表示される拡張機能に対して、次のタイプが定義されています。
0 One-byte Padding (encoded with neither Length nor Data field) 16 Mobility Agent Advertisement 19 Prefix-Lengths
0ワンバイトパディング（長さもデータフィールドもエンコード）16モビリティエージェント広告19プレフィックスレングス
Each individual Extension is described in detail in a separate section later in this document. Up-to-date values for these Extension Type numbers are specified in the IANA online database [48].
個々の拡張機能については、このドキュメントの後半の別のセクションで詳細に説明されています。これらの拡張型タイプ番号の最新の値は、IANAオンラインデータベース[48]で指定されています。
Due to the separation (orthogonality) of these sets, it is conceivable that two Extensions that are defined at a later date could have identical Type values, so long as one of the Extensions may be used only in Mobile IP control messages and the other may be used only in ICMP Router Discovery messages.
これらのセットの分離（直交）により、後日定義される2つの拡張機能が同一のタイプ値を持つ可能性があると考えられます。ICMPルーターディスカバリーメッセージでのみ使用します。
The Type field in the Mobile IP extension structure can support up to 255 (skippable and non-skippable) uniquely identifiable extensions. When an Extension numbered in either of these sets within the range 0 through 127 is encountered but not recognized, the message containing that Extension MUST be silently discarded. When an Extension numbered in the range 128 through 255 is encountered that is not recognized, that particular Extension is ignored, but the rest of the Extensions and message data MUST still be processed. The Length field of the Extension is used to skip the Data field in searching for the next Extension.
モバイルIP拡張構造のタイプフィールドは、最大255（スキップ可能でスキップできない）をサポートできます。範囲0〜127内のこれらのセットのいずれかに番号が付けられた拡張機能が遭遇したが、認識されていない場合、拡張機能を含むメッセージは静かに廃棄する必要があります。範囲128〜255で番号が付けられた拡張機能が認識されていない場合、特定の拡張機能は無視されますが、残りの拡張データとメッセージデータを処理する必要があります。拡張機能の長さフィールドは、次の拡張機能を検索する際にデータフィールドをスキップするために使用されます。
Unless additional structure is utilized for the extension types, new developments or additions to Mobile IP might require so many new extensions that the available space for extension types might run out. Two new extension structures are proposed to solve this problem. Certain types of extensions can be aggregated, using subtypes to identify the precise extension, for example as has been done with the Generic Authentication Keys extensions [46]. In many cases, this may reduce the rate of allocation for new values of the Type field.
拡張タイプに追加の構造が利用されない限り、モバイルIPへの新しい開発または追加には非常に多くの新しい拡張機能が必要になるため、拡張タイプに使用できるスペースがなくなる可能性があります。この問題を解決するために、2つの新しい拡張構造が提案されています。サブタイプを使用して正確な拡張機能を識別するために、特定のタイプの拡張機能を集約できます。たとえば、一般的な認証キー拡張機能で行われているように[46]。多くの場合、これにより、タイプフィールドの新しい値の割り当て速度が低下する可能性があります。
Since the new extension structures will cause an efficient usage of the extension type space, it is recommended that new Mobile IP extensions follow one of the two new extension formats whenever there may be the possibility of grouping related extensions together.
新しい拡張構造は、拡張タイプのスペースを効率的に使用するため、関連する拡張機能をグループ化する可能性がある場合は、新しいモバイルIP拡張機能のいずれかに従うことをお勧めします。
The following subsections provide details about three distinct structures for Mobile IP extensions:
次のサブセクションは、モバイルIP拡張機能の3つの異なる構造に関する詳細を提供します。
o The simple extension format
o 簡単な拡張形式
o The long extension format
o 長い拡張形式
o The short extension format
o 短い拡張形式
The Type-Length-Value format illustrated in Figure 2 is used for extensions that are specified in this document. Since this simple extension structure does not encourage the most efficient usage of the extension type space, it is recommended that new Mobile IP extensions follow one of the two new extension formats specified in Section 1.10 or Section 1.11 whenever there may be the possibility of grouping related extensions together.
図2に示すタイプ長価値形式は、このドキュメントで指定されている拡張機能に使用されます。この単純な拡張構造は、拡張型タイプスペースの最も効率的な使用を促進しないため、新しいモバイルIP拡張機能は、グループ化関連のグループ化が可能な場合はいつでもセクション1.10またはセクション1.11で指定された2つの新しい拡張フォーマットのいずれかに従うことをお勧めします。一緒に拡張機能。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: Type-Length-Value Extension Format for Mobile IPv4
図2：モバイルIPv4のタイプ長値拡張形式
Type Indicates the particular type of Extension.
タイプは、特定のタイプの拡張機能を示します。
Length Indicates the length (in bytes) of the Data field within this Extension. The length does NOT include the Type and Length bytes.
長さは、この拡張機能内のデータフィールドの長さ（バイト単位）を示します。長さには、タイプと長さのバイトが含まれません。
Data The particular data associated with this Extension. This field may be zero or more bytes in length. The format and length of the Data field is determined by the Type and Length fields.
データこの拡張機能に関連する特定のデータ。このフィールドの長さはゼロ以上のバイトです。データフィールドの形式と長さは、タイプと長さのフィールドによって決定されます。
This format is applicable for non-skippable extensions that carry information of more than 256 bytes. Skippable extensions can never use the long format, because the receiver is not required to include parsing code and is likely to treat the 8 bits immediately following the Type as the Length field.
この形式は、256バイト以上の情報を運ぶスキップ不可の拡張機能に適用できます。Skippable Extensionsは、レシーバーが解析コードを含める必要がないため、長さのフィールドとしてタイプの直後に8ビットを処理する可能性が高いため、長い形式を使用することはできません。
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 | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Long Extension format requires that the following fields be specified as the first fields of the extension.
長い拡張形式では、次のフィールドを拡張の最初のフィールドとして指定する必要があります。
Type is the type, which describes a collection of extensions having a common data type.
タイプはタイプで、共通のデータ型を持つ拡張機能のコレクションを記述します。
Sub-Type is a unique number given to each member in the aggregated type.
サブタイプは、集約されたタイプの各メンバーに与えられる一意の番号です。
Length indicates the length (in bytes) of the Data field within this Extension. It does NOT include the Type, Length, and Sub-Type bytes.
長さは、この拡張機能内のデータフィールドの長さ（バイト単位）を示します。タイプ、長さ、およびサブタイプのバイトは含まれません。
Data is the data associated with the subtype of this extension. This specification does not place any additional structure on the subtype data.
データは、この拡張機能のサブタイプに関連付けられたデータです。この仕様では、サブタイプデータに追加の構造はありません。
Since the Length field is 16 bits wide, the extension data can exceed 256 bytes in length.
長さのフィールドは16ビット幅であるため、拡張データの長さは256バイトを超える可能性があります。
This format is compatible with the skippable extensions defined in Section 1.9. It is not applicable for extensions that require more than 256 bytes of data; for such extensions, use the format described in Section 1.10.
この形式は、セクション1.9で定義されているスキップ可能な拡張機能と互換性があります。256バイト以上のデータを必要とする拡張機能には適用されません。このような拡張機能には、セクション1.10で説明されている形式を使用します。
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 | Length | Sub-Type | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Short Extension format requires that the following fields be specified as the first fields of the extension:
短い拡張形式では、次のフィールドを拡張の最初のフィールドとして指定する必要があります。
Type is the type, which describes a collection of extensions having a common data type.
タイプはタイプで、共通のデータ型を持つ拡張機能のコレクションを記述します。
Sub-Type is a unique number given to each member in the aggregated type.
サブタイプは、集約されたタイプの各メンバーに与えられる一意の番号です。
Length 8-bit unsigned integer. Length of the extension, in bytes, excluding the extension Type and the extension Length fields. This field MUST be set to 1 plus the total length of the Data field.
長さ8ビット符号なし整数。拡張の長さは、拡張タイプと拡張長のフィールドを除くバイト単位です。このフィールドは、データフィールドの合計長さに1に設定する必要があります。
Data is the data associated with this extension. This specification does not place any additional structure on the subtype data.
データは、この拡張機能に関連付けられているデータです。この仕様では、サブタイプデータに追加の構造はありません。
Agent Discovery is the method by which a mobile node determines whether it is currently connected to its home network or to a foreign network, and by which a mobile node can detect when it has moved from one network to another. When connected to a foreign network, the methods specified in this section also allow the mobile node to determine the foreign agent care-of address being offered by each foreign agent on that network.
エージェントディスカバリーは、モバイルノードが現在ホームネットワークまたは外国ネットワークに接続されているかどうかを決定し、モバイルノードがあるネットワークから別のネットワークに移動したときに検出できる方法です。外国ネットワークに接続されている場合、このセクションで指定された方法により、モバイルノードは、そのネットワーク上の各外国人エージェントが提供する外国人エージェントのケアアドレスを決定することもできます。
Mobile IP extends ICMP Router Discovery [5] as its primary mechanism for Agent Discovery. An Agent Advertisement is formed by including a Mobility Agent Advertisement Extension in an ICMP Router Advertisement message (Section 2.1). An Agent Solicitation message is identical to an ICMP Router Solicitation, except that its IP Time to Live (TTL) MUST be set to 1 (Section 2.2). This section describes the message formats and procedures by which mobile nodes, foreign agents, and home agents cooperate to realize Agent Discovery.
モバイルIPは、ICMPルーターの発見[5]をエージェント発見の主要なメカニズムとして拡張します。エージェント広告は、ICMPルーター広告メッセージ（セクション2.1）にモビリティエージェント広告拡張機能を含めることによって形成されます。エージェントの勧誘メッセージは、IP Live（TTL）を1（セクション2.2）に設定する必要があることを除いて、ICMPルーターの勧誘と同一です。このセクションでは、モバイルノード、外国人エージェント、およびホームエージェントが協力してエージェントの発見を実現するメッセージの形式と手順について説明します。
Agent Advertisement and Agent Solicitation may not be necessary for link layers that already provide this functionality. The method by which mobile nodes establish link-layer connections with prospective agents is outside the scope of this document (but see Appendix A). The procedures described below assume that such link-layer connectivity has already been established.
この機能を既に提供するリンクレイヤーには、エージェント広告とエージェントの勧誘は必要ない場合があります。モバイルノードが将来のエージェントとのリンク層接続を確立する方法は、このドキュメントの範囲外です（ただし、付録Aを参照）。以下に説明する手順は、そのようなリンク層の接続性がすでに確立されていると仮定しています。
No authentication is required for Agent Advertisement and Agent Solicitation messages. They MAY be authenticated using the IP Authentication Header [9], which is unrelated to the messages described in this document. Further specification of the way in which Advertisement and Solicitation messages may be authenticated is outside of the scope of this document.
エージェント広告とエージェントの勧誘メッセージには認証は必要ありません。これらは、このドキュメントで説明されているメッセージとは無関係のIP認証ヘッダー[9]を使用して認証される場合があります。広告メッセージと勧誘メッセージの認証方法をさらに指定することは、このドキュメントの範囲外です。
Agent Advertisements are transmitted by a mobility agent to advertise its services on a link. Mobile nodes use these advertisements to determine their current point of attachment to the Internet. An Agent Advertisement is an ICMP Router Advertisement that has been extended to also carry a Mobility Agent Advertisement Extension (Section 2.1.1) and, optionally, a Prefix-Lengths Extension (Section 2.1.2), One-byte Padding Extension (Section 2.1.3), or other Extensions that might be defined in the future.
エージェント広告は、モビリティエージェントによって送信され、リンク上のサービスを宣伝します。モバイルノードは、これらの広告を使用して、インターネットへの現在の添付ポイントを決定します。エージェント広告は、モビリティエージェント広告拡張機能（セクション2.1.1）、およびオプションでは、プレフィックス長拡張（セクション2.1.2）、1バイトパディングエクステンション（セクション2.1）も運ぶように拡張されたICMPルーター広告です。.3）、または将来定義される可能性のあるその他の拡張機能。
Within an Agent Advertisement message, ICMP Router Advertisement fields of the message are required to conform to the following additional specifications:
エージェント広告メッセージ内で、メッセージのICMPルーター広告フィールドは、次の追加の仕様に準拠するために必要です。
- Link-Layer Fields
- リンク層フィールド
Destination Address
宛先アドレス
The link-layer Destination Address of a unicast Agent Advertisement MUST be the same as the source link-layer address of the Agent Solicitation that prompted the Advertisement.
ユニキャストエージェント広告のリンク層宛先アドレスは、広告を促したエージェントの勧誘のソースリンクレイヤーアドレスと同じでなければなりません。
- IP Fields
- IPフィールド
TTL The TTL for all Agent Advertisements MUST be set to 1.
TTLすべてのエージェント広告のTTLは1に設定する必要があります。
Destination Address
宛先アドレス
As specified for ICMP Router Discovery [5], the IP Destination Address of a multicast Agent Advertisement MUST be either the "all systems on this link" multicast address (224.0.0.1) [6] or the "limited broadcast" address (255.255.255.255). The subnet-directed broadcast address of the form <prefix>.<-1> cannot be used since mobile nodes will not generally know the prefix of the foreign network. When the Agent Advertisement is unicast to a mobile node, the IP home address of the mobile node SHOULD be used as the Destination Address.
ICMPルーターの発見[5]に指定されているように、マルチキャストエージェント広告のIP宛先アドレスは、「このリンク上のすべてのシステム」マルチキャストアドレス（224.0.0.1）[6]または「限定放送」アドレス（255.255のいずれかでなければなりません。255.255）。モバイルノードは一般に外部ネットワークのプレフィックスを知らないため、フォーム<プレフィックス>。<-1>のサブネット指向ブロードキャストアドレスは使用できません。エージェント広告がモバイルノードのユニキャストである場合、モバイルノードのIPホームアドレスを宛先アドレスとして使用する必要があります。
- ICMP Fields
- ICMPフィールド
Code The Code field of the Agent Advertisement is interpreted as follows:
コードエージェント広告のコードフィールドは次のように解釈されます。
0 The mobility agent handles common traffic -- that is, it acts as a router for IP datagrams not necessarily related to mobile nodes.
0モビリティエージェントは、一般的なトラフィックを処理します。つまり、モバイルノードに必ずしも関連していないIPデータグラムのルーターとして機能します。
16 The mobility agent does not route common traffic. However, all foreign agents MUST (minimally) forward to a default router any datagrams received from a registered mobile node (Section 4.2.2).
16モビリティエージェントは、一般的なトラフィックをルーティングしません。ただし、すべての外国人エージェントは、登録されたモバイルノード（セクション4.2.2）から受信したデータグラムをデフォルトのルーターに（最小限に）転送する必要があります。
Lifetime
一生
The maximum length of time that the Advertisement is considered valid in the absence of further Advertisements.
広告がさらに広告がない場合、広告が有効と見なされる最大時間の長さ。
Router Address(es)
ルーターアドレス（es）
See Section 2.3.1 for a discussion of the addresses that may appear in this portion of the Agent Advertisement.
エージェント広告のこの部分に表示されるアドレスの議論については、セクション2.3.1を参照してください。
Num Addrs
numアドレス
The number of router addresses advertised in this message. Note that in an Agent Advertisement message, the number of router addresses specified in the ICMP Router Advertisement portion of the message MAY be set to 0. See Section 2.3.1 for details.
このメッセージで宣伝されているルーターの数。エージェント広告メッセージでは、メッセージのICMPルーター広告部分で指定されているルーターのアドレスの数を0に設定できることに注意してください。詳細については、セクション2.3.1を参照してください。
If sent periodically, the nominal interval at which Agent Advertisements are sent SHOULD be no longer than 1/3 of the advertisement Lifetime given in the ICMP header. This interval MAY be shorter than 1/3 the advertised Lifetime. This allows a mobile node to miss three successive advertisements before deleting the agent from its list of valid agents. The actual transmission time for each advertisement SHOULD be slightly randomized [5] in order to avoid synchronization and subsequent collisions with other Agent Advertisements that may be sent by other agents (or with other Router Advertisements sent by other routers). Note that this field has no relation to the "Registration Lifetime" field within the Mobility Agent Advertisement Extension defined below.
定期的に送信された場合、エージェント広告が送信される名目間隔は、ICMPヘッダーに与えられた広告寿命の1/3以下でなければなりません。この間隔は、広告された寿命の1/3よりも短い場合があります。これにより、有効なエージェントのリストからエージェントを削除する前に、モバイルノードが3つの連続した広告を逃すことができます。各広告の実際の送信時間は、同期を回避し、他のエージェント（または他のルーターから送信された他のルーター広告）が送信する可能性のある他のエージェント広告との衝突を回避するために、わずかにランダム化する必要があります。このフィールドには、以下に定義されているモビリティエージェント広告拡張機能内の「登録ライフタイム」フィールドとの関係がないことに注意してください。
The Mobility Agent Advertisement Extension follows the ICMP Router Advertisement fields. It is used to indicate that an ICMP Router Advertisement message is also an Agent Advertisement being sent by a mobility agent. The Mobility Agent Advertisement Extension is defined as follows:
モビリティエージェント広告拡張機能は、ICMPルーター広告フィールドに従います。ICMPルーター広告メッセージは、モビリティエージェントによって送信されるエージェント広告でもあることを示すために使用されます。モビリティエージェントの広告拡張機能は、次のように定義されています。
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 | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|r|T|U|X|I|reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
Type 16
タイプ16
Length (6 + 4*N), where 6 accounts for the number of bytes in the Sequence Number, Registration Lifetime, flags, and reserved fields, and N is the number of care-of addresses advertised.
長さ（6 4*n）。ここで、シーケンス数のバイト数、登録寿命、フラグ、および予約フィールド、nは宣伝されている住所のケア数です。
Sequence Number
シーケンス番号
The count of Agent Advertisement messages sent since the agent was initialized (Section 2.3.2).
エージェントが初期化されてから送信されたエージェント広告メッセージのカウント（セクション2.3.2）。
Registration Lifetime
登録寿命
The longest lifetime (measured in seconds) that this agent is willing to accept in any Registration Request. A value of 0xffff indicates infinity. This field has no relation to the "Lifetime" field within the ICMP Router Advertisement portion of the Agent Advertisement.
このエージェントが登録リクエストで受け入れることをいとわない最長の寿命（数秒で測定）。0xffffの値は、無限を示します。このフィールドは、エージェント広告のICMPルーター広告部分内の「生涯」フィールドとは関係ありません。
R Registration required. Registration with this foreign agent (or another foreign agent on this link) is required even when using a co-located care-of address.
R登録が必要です。この外国人エージェント（またはこのリンク上の別の外国人エージェント）との登録は、共同配置された住所を使用する場合でも必要です。
B Busy. The foreign agent will not accept registrations from additional mobile nodes.
b忙しい。外国人エージェントは、追加のモバイルノードからの登録を受け入れません。
H Home agent. This agent offers service as a home agent on the link on which this Agent Advertisement message is sent.
Hホームエージェント。このエージェントは、このエージェント広告メッセージが送信されるリンク上のホームエージェントとしてサービスを提供します。
F Foreign agent. This agent offers service as a foreign agent on the link on which this Agent Advertisement message is sent.
f外国人エージェント。このエージェントは、このエージェント広告メッセージが送信されるリンク上の外国人エージェントとしてサービスを提供します。
M Minimal encapsulation. This agent implements receiving tunneled datagrams that use minimal encapsulation [15].
m最小限のカプセル化。このエージェントは、最小限のカプセル化を使用するトンネル化されたデータグラムを受信します[15]。
G Generic Routing Encapsulation (GRE) encapsulation. This agent implements receiving tunneled datagrams that use GRE encapsulation [13].
Gジェネリックルーティングカプセル化（GRE）カプセル化。このエージェントは、GREカプセル化を使用するトンネル化されたデータグラムの受信を実装します[13]。
r Sent as zero; ignored on reception. SHOULD NOT be allocated for any other uses.
rはゼロとして送信されました。レセプションで無視されます。他の用途には割り当てられないでください。
T Foreign agent supports reverse tunneling as specified in [12].
T外部エージェントは、[12]で指定されているように逆トンネリングをサポートします。
U Mobility agent supports UDP Tunneling as specified in [27].
Uモビリティエージェントは、[27]で指定されているUDPトンネルをサポートしています。
X Mobility agent supports Registration Revocation as specified in [28].
Xモビリティエージェントは、[28]で指定されている登録の取り消しをサポートしています。
I Foreign agent supports Regional Registration as specified in [29].
I外国人エージェントは、[29]で指定されている地域登録をサポートしています。
reserved Sent as zero; ignored on reception.
ゼロとして送信された予約。レセプションで無視されます。
Care-of Address(es)
ケアオブアドレス（es）
The advertised foreign agent care-of address(es) provided by this foreign agent. An Agent Advertisement MUST include at least one care-of address if the 'F' bit is set. The number of care-of addresses present is determined by the Length field in the Extension.
この外国人エージェントによって提供される広告外国のエージェントケアオブアドレス（ES）。エージェント広告には、「F」ビットが設定されている場合、少なくとも1つのケアオブアドレスを含める必要があります。存在するアドレスのケアの数は、拡張の長さフィールドによって決まります。
A home agent MUST always be prepared to serve the mobile nodes for which it is the home agent. A foreign agent may at times be too busy to serve additional mobile nodes; even so, it must continue to send Agent Advertisements, so that any mobile nodes already registered with it will know that they have not moved out of range of the foreign agent and that the foreign agent has not failed. A foreign agent may indicate that it is "too busy" to allow new mobile nodes to register with it, by setting the 'B' bit in its Agent Advertisements. An Agent Advertisement message MUST NOT have the 'B' bit set if the 'F' bit is not also set. Furthermore, at least one of the 'F' bit and the 'H' bit MUST be set in any Agent Advertisement message sent.
ホームエージェントは、ホームエージェントであるモバイルノードを常に提供する準備をする必要があります。外国人エージェントは、忙しすぎて追加のモバイルノードを提供できない場合があります。それでも、既に登録されているモバイルノードは、外国人のエージェントの範囲外に移動しておらず、外国人エージェントが失敗していないことを知っているため、エージェントの広告を送信し続ける必要があります。外国人エージェントは、エージェント広告に「B」ビットを設定することにより、新しいモバイルノードが登録できるようにするには「忙しすぎる」ことを示している場合があります。エージェント広告メッセージには、「F」ビットが設定されていない場合、「B」ビットが設定されていない必要があります。さらに、「F」ビットの少なくとも1つと「H」ビットを、送信したエージェント広告メッセージで設定する必要があります。
When a foreign agent wishes to require registration even from those mobile nodes that have acquired a co-located care-of address, it sets the 'R' bit to one. Because this bit applies only to foreign agents, an agent MUST NOT set the 'R' bit to one unless the 'F' bit is also set to one.
外国人エージェントが、共同住宅のケアオブアドレスを取得したモバイルノードからでも登録を要求したい場合、「R」ビットを1に設定します。このビットは外国のエージェントにのみ適用されるため、エージェントは「f」ビットも1つに設定されていない限り、「r」ビットを1に設定してはなりません。
The Prefix-Lengths Extension MAY follow the Mobility Agent Advertisement Extension. It is used to indicate the number of bits of network prefix that applies to each router address listed in the ICMP Router Advertisement portion of the Agent Advertisement. Note that the prefix lengths given DO NOT apply to care-of address(es) listed in the Mobility Agent Advertisement Extension. The Prefix-Lengths Extension is defined as follows:
プレフィックスレングス拡張機能は、モビリティエージェントの広告拡張機能に従うことがあります。エージェント広告のICMPルーター広告部分にリストされている各ルーターアドレスに適用されるネットワークプレフィックスのビット数を示すために使用されます。与えられたプレフィックスの長さは、モビリティエージェント広告拡張機能にリストされている住所に適用されないことに注意してください。プレフィックスレングスの拡張は次のように定義されています。
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 | Length | Prefix Length | ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 19 (Prefix-Lengths Extension)
タイプ19（プレフィックスレングス拡張）
Length N, where N is the value (possibly zero) of the Num Addrs field in the ICMP Router Advertisement portion of the Agent Advertisement.
長さn、ここで、nはエージェント広告のICMPルーター広告部分のnum addrsフィールドの値（おそらくゼロ）です。
Prefix Length(s)
プレフィックスの長さ
The number of leading bits that define the network number of the corresponding router address listed in the ICMP Router Advertisement portion of the message. The prefix length for each router address is encoded as a separate byte, in the order that the router addresses are listed in the ICMP Router Advertisement portion of the message.
メッセージのICMPルーター広告部分にリストされている対応するルーターアドレスのネットワーク番号を定義する主要ビットの数。各ルーターアドレスのプレフィックスの長さは、メッセージのICMPルーター広告部分にルーターアドレスがリストされる順に、個別のバイトとしてエンコードされます。
See Section 2.4.2 for information about how the Prefix-Lengths Extension MAY be used by a mobile node when determining whether it has moved. See Appendix D for implementation details about the use of this Extension.
移動したかどうかを判断する際に、モバイルノードでプレフィックスレングス拡張を使用する方法については、セクション2.4.2を参照してください。この拡張機能の使用に関する実装の詳細については、付録Dを参照してください。
Some IP protocol implementations insist upon padding ICMP messages to an even number of bytes. If the ICMP length of an Agent Advertisement is odd, this Extension MAY be included in order to make the ICMP length even. Note that this Extension is NOT intended to be a general-purpose Extension to be included in order to word- or long-align the various fields of the Agent Advertisement. An Agent Advertisement SHOULD NOT include more than one One-byte Padding Extension and if present, this Extension SHOULD be the last Extension in the Agent Advertisement.
一部のIPプロトコルの実装は、ICMPメッセージを偶数バイトにパディングすることを主張しています。エージェント広告のICMPの長さが奇妙な場合、この拡張機能はICMPの長さを均等にするために含めることができます。この拡張機能は、エージェント広告のさまざまなフィールドを単語または長時間調整するために含まれる汎用拡張機能ではないことに注意してください。エージェント広告には、1バイト以上のパディング拡張機能を1つ以上含めるべきではありません。存在する場合は、この拡張機能がエージェント広告の最後の拡張機能である必要があります。
Note that, unlike other Extensions used in Mobile IP, the One-byte Padding Extension is encoded as a single byte, with no Length nor Data field present. The One-byte Padding Extension is defined as follows:
モバイルIPで使用される他の拡張機能とは異なり、1バイトのパディング拡張機能は単一のバイトとしてエンコードされ、長さもデータフィールドも存在しないことに注意してください。1バイバイトのパディングエクステンションは、次のように定義されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+
Type 0 (One-byte Padding Extension)
タイプ0（1バイトのパディングエクステンション）
An Agent Solicitation is identical to an ICMP Router Solicitation with the further restriction that the IP TTL Field MUST be set to 1.
エージェントの勧誘は、IP TTLフィールドを1に設定する必要があるというさらなる制限を伴うICMPルーターの勧誘と同一です。
Any mobility agent that cannot be discovered by a link-layer protocol MUST send Agent Advertisements. An agent that can be discovered by a link-layer protocol SHOULD also implement Agent Advertisements.
リンク層プロトコルで発見できないモビリティエージェントは、エージェント広告を送信する必要があります。リンク層プロトコルで発見できるエージェントもエージェント広告を実装する必要があります。
However, the Advertisements need not be sent, except when the site policy requires registration with the agent (i.e., when the 'R' bit is set), or as a response to a specific Agent Solicitation. All mobility agents MUST process packets that they receive addressed to the Mobile-Agents multicast group, at address 224.0.0.11. A mobile node MAY send an Agent Solicitation to 224.0.0.11. All mobility agents SHOULD respond to Agent Solicitations.
ただし、サイトポリシーがエージェントとの登録が必要な場合（つまり、「r」ビットが設定されている場合）、または特定のエージェントの勧誘への応答として、広告を送信する必要はありません。すべてのモビリティエージェントは、アドレス224.0.0.11で、モバイルエージェントマルチキャストグループに宛てられたアドレス指定されたパケットを処理する必要があります。モバイルノードは、エージェントの勧誘を224.0.0.11に送信する場合があります。すべてのモビリティエージェントは、エージェントの勧誘に対応する必要があります。
The same procedures, defaults, and constants are used in Agent Advertisement messages and Agent Solicitation messages as specified for ICMP Router Discovery [5], except that:
同じ手順、デフォルト、および定数は、ICMPルーターの発見[5]に指定されているエージェント広告メッセージとエージェント勧誘メッセージで使用されます。
o a mobility agent MUST limit the rate at which it sends broadcast or multicast Agent Advertisements; the maximum rate SHOULD be chosen so that the Advertisements do not consume a significant amount of network bandwidth, AND
o モビリティエージェントは、放送またはマルチキャストエージェントの広告を送信するレートを制限する必要があります。広告がかなりの量のネットワーク帯域幅を消費しないように、最大レートを選択する必要があります。
o a mobility agent that receives a Router Solicitation MUST NOT require that the IP Source Address is the address of a neighbor (i.e., an address that matches one of the router's own addresses on the arrival interface, under the subnet mask associated with that address of the router).
o ルーターの勧誘を受けるモビリティエージェントは、IPソースアドレスが近隣のアドレスであることを要求してはなりません（つまり、到着インターフェイスのルーター自身のアドレスの1つに一致するアドレス、そのアドレスの下にあるサブネットマスクの下にあるアドレスは、ルーター）。
o a mobility agent MAY be configured to send Agent Advertisements only in response to an Agent Solicitation message.
o モビリティエージェントは、エージェントの勧誘メッセージに応じてのみエージェント広告を送信するように構成できます。
If the home network is not a virtual network, then the home agent for any mobile node SHOULD be located on the link identified by the mobile node's home address, and Agent Advertisement messages sent by the home agent on this link MUST have the 'H' bit set. In this way, mobile nodes on their own home network will be able to determine that they are indeed at home. Any Agent Advertisement messages sent by the home agent on another link to which it may be attached (if it is a mobility agent serving more than one link), MUST NOT have the 'H' bit set unless the home agent also serves as a home agent (to other mobile nodes) on that other link. A mobility agent MAY use different settings for each of the 'R', 'H', and 'F' bits on different network interfaces.
ホームネットワークが仮想ネットワークではない場合、モバイルノードのホームエージェントは、モバイルノードのホームアドレスによって識別されたリンクに配置する必要があり、このリンクでホームエージェントが送信したエージェント広告メッセージには「H」が必要ですビットセット。このようにして、独自のホームネットワーク上のモバイルノードは、実際に自宅にいることを判断できます。ホームエージェントから添付される可能性のある別のリンクで送信されたエージェント広告メッセージ（複数のリンクを提供するモビリティエージェントの場合）は、ホームエージェントがホームとしても機能しない限り、「H」ビットセットを持たないでくださいその他のリンクのエージェント（他のモバイルノードへ）。モビリティエージェントは、異なるネットワークインターフェイスで「R」、「H」、および「F」ビットごとに異なる設定を使用できます。
If the home network is a virtual network, the home network has no physical realization external to the home agent itself. In this case, there is no physical network link on which to send Agent Advertisement messages advertising the home agent. Mobile nodes for which this is the home network are always treated as being away from home.
ホームネットワークが仮想ネットワークの場合、ホームネットワークにはホームエージェント自体の外部の物理的実現はありません。この場合、ホームエージェントを宣伝するエージェント広告メッセージを送信するための物理ネットワークリンクはありません。これがホームネットワークであるモバイルノードは、常に家から離れていると扱われます。
On a particular subnet, either all mobility agents MUST include the Prefix-Lengths Extension or all of them MUST NOT include this Extension. Equivalently, it is prohibited for some agents on a given subnet to include the Extension but for others not to include it. Otherwise, one of the move detection algorithms designed for mobile nodes will not function properly (Section 2.4.2).
特定のサブネットでは、すべてのモビリティエージェントにプレフィックスレングス拡張機能を含める必要があるか、すべてがこの拡張機能を含めてはなりません。同様に、特定のサブネットの一部のエージェントが拡張機能を含めることは禁止されていますが、他のエージェントはそれを含めません。それ以外の場合、モバイルノード用に設計された移動検出アルゴリズムの1つは適切に機能しません（セクション2.4.2）。
The ICMP Router Advertisement portion of the Agent Advertisement MAY contain one or more router addresses. An agent SHOULD only put its own addresses, if any, in the advertisement. Whether or not its own address appears in the router addresses, a foreign agent MUST route datagrams it receives from registered mobile nodes (Section 3.7).
エージェント広告のICMPルーター広告部分には、1つ以上のルーターアドレスが含まれる場合があります。エージェントは、広告に独自のアドレスのみを配置する必要があります。ルーターアドレスに独自のアドレスが表示されるかどうかにかかわらず、外国人エージェントは登録されたモバイルノードから受信するデータグラムをルーティングする必要があります（セクション3.7）。
The sequence number in Agent Advertisements ranges from 0 to 0xffff. After booting, an agent MUST use the number 0 for its first advertisement. Each subsequent advertisement MUST use the sequence number one greater, with the exception that the sequence number 0xffff MUST be followed by sequence number 256. In this way, mobile nodes can distinguish a reduction in the sequence number that occurs after a reboot from a reduction that results in rollover of the sequence number after it attains the value 0xffff.
エージェント広告のシーケンス番号の範囲は0〜0xffffです。起動後、エージェントは最初の広告に番号0を使用する必要があります。次の各広告は、シーケンス番号0xffffの後にシーケンス番号256が続く必要があることを除いて、シーケンス番号1を大きく使用する必要があります。このように、モバイルノードは、リブートの減少から発生するシーケンス番号の減少を区別できます。値0xffffを達成した後、シーケンス番号がロールオーバーされます。
Every mobile node MUST implement Agent Solicitation. Solicitations SHOULD only be sent in the absence of Agent Advertisements and when a care-of address has not been determined through a link-layer protocol or other means. The mobile node uses the same procedures, defaults, and constants for Agent Solicitation as specified for ICMP Router Solicitation messages [5], except that the mobile node MAY solicit more often than once every three seconds, and that a mobile node that is currently not connected to any foreign agent MAY solicit more times than MAX_SOLICITATIONS.
すべてのモバイルノードは、エージェントの勧誘を実装する必要があります。勧誘は、エージェント広告がない場合にのみ送信され、リンク層プロトコルまたはその他の手段を介して住所のケアが決定されていない場合にのみ送信する必要があります。モバイルノードは、モバイルノードが3秒ごとに1回より頻繁に募集する場合があり、現在そうではないモバイルノードがあることを除いて、ICMPルーター勧誘メッセージ[5]で指定されたエージェント勧誘の同じ手順、デフォルト、および定数を使用します。外国人エージェントに接続されている場合は、MAX_SOLICITATIONSよりも多くの回数を求める場合があります。
The rate at which a mobile node sends solicitations MUST be limited by the mobile node. The mobile node MAY send three initial solicitations at a maximum rate of one per second while searching for an agent. After this, the rate at which solicitations are sent MUST be reduced so as to limit the overhead on the local link. Subsequent solicitations MUST be sent using a binary exponential backoff mechanism, doubling the interval between consecutive solicitations, up to a maximum interval. The maximum interval SHOULD be chosen appropriately based upon the characteristics of the media over which the mobile node is soliciting. This maximum interval SHOULD be at least one minute between solicitations.
モバイルノードが勧誘を送信するレートは、モバイルノードによって制限されなければなりません。モバイルノードは、エージェントの検索中に、1秒あたり1秒の最大レートで3つの初期勧誘を送信する場合があります。この後、ローカルリンクのオーバーヘッドを制限するために、勧誘が送信されるレートを減らす必要があります。その後の勧誘は、バイナリ指数バックオフメカニズムを使用して送信する必要があり、連続した勧誘の間隔を2倍にし、最大間隔まで。最大間隔は、モバイルノードが求めているメディアの特性に基づいて適切に選択する必要があります。この最大間隔は、勧誘の間に少なくとも1分でなければなりません。
While still searching for an agent, the mobile node MUST NOT increase the rate at which it sends solicitations unless it has received a positive indication that it has moved to a new link. After successfully registering with an agent, the mobile node SHOULD also increase the rate at which it will send solicitations when it next begins searching for a new agent with which to register. The increased solicitation rate MAY revert to the maximum rate, but then MUST be limited in the manner described above. In all cases, the recommended solicitation intervals are nominal values. Mobile nodes MUST randomize their solicitation times around these nominal values as specified for ICMP Router Discovery [5].
それでもエージェントを検索している間、モバイルノードは、新しいリンクに移動したという肯定的な兆候を受け取っていない限り、勧誘を送信する速度を上げてはなりません。エージェントに正常に登録した後、モバイルノードは、次に登録する新しいエージェントの検索を開始したときに勧誘が送信されるレートを上げる必要があります。勧誘率の増加は最大速度に戻る可能性がありますが、上記の方法で制限する必要があります。すべての場合において、推奨される勧誘間隔は名目値です。モバイルノードは、ICMPルーターの発見に指定されているように、これらの公称値の周りの勧誘時間をランダム化する必要があります[5]。
Mobile nodes MUST process received Agent Advertisements. A mobile node can distinguish an Agent Advertisement message from other uses of the ICMP Router Advertisement message by examining the number of advertised addresses and the IP Total Length field. When the IP total length indicates that the ICMP message is longer than needed for the number of advertised addresses, the remaining data is interpreted as one or more Extensions. The presence of a Mobility Agent Advertisement Extension identifies the advertisement as an Agent Advertisement.
モバイルノードは、受信したエージェント広告を処理する必要があります。モバイルノードは、広告されたアドレスの数とIP合計長さフィールドを調べることにより、Agent AdvertisementメッセージをICMPルーター広告メッセージの他の使用と区別できます。IPの合計長さが、広告されたアドレスの数にICMPメッセージが必要よりも長いことを示している場合、残りのデータは1つ以上の拡張機能として解釈されます。モビリティエージェント広告拡張機能の存在は、広告をエージェント広告として識別します。
If there is more than one advertised address, the mobile node SHOULD pick the first address for its initial registration attempt. If the registration attempt fails with a status code indicating rejection by the foreign agent, the mobile node MAY retry the attempt with each subsequent advertised address in turn.
複数のアドレスがある場合、モバイルノードは最初の登録試行の最初のアドレスを選択する必要があります。登録試行が外国人エージェントによる拒否を示すステータスコードで失敗した場合、モバイルノードは、後続のアドレスごとに順番に試行を再試行することができます。
When multiple methods of agent discovery are in use, the mobile node SHOULD first attempt registration with agents including Mobility Agent Advertisement Extensions in their advertisements, in preference to those discovered by other means. This preference maximizes the likelihood that the registration will be recognized, thereby minimizing the number of registration attempts.
エージェント発見の複数の方法が使用されている場合、モバイルノードは、他の手段で発見されたものよりも優先されて、広告のモビリティエージェント広告拡張機能を含むエージェントとの登録を最初に試みる必要があります。この好みは、登録が認識される可能性を最大化し、それにより登録の試みの数を最小限に抑えます。
A mobile node MUST ignore reserved bits in Agent Advertisements, as opposed to discarding such advertisements. In this way, new bits can be defined later, without affecting the ability for mobile nodes to use the advertisements even when the newly defined bits are not understood.
モバイルノードは、そのような広告を破棄するのではなく、エージェント広告の予約ビットを無視する必要があります。このようにして、新たに定義されたビットが理解されていない場合でも、モバイルノードが広告を使用する機能に影響を与えることなく、新しいビットを後で定義できます。
When the mobile node receives an Agent Advertisement with the 'R' bit set, the mobile node SHOULD register through the foreign agent, even when the mobile node might be able to acquire its own co-located care-of address. This feature is intended to allow sites to enforce visiting policies (such as accounting) that require exchanges of authorization.
モバイルノードが「R」ビットセットを使用してエージェント広告を受信すると、モバイルノードが独自のコロア付きケアオブアドレスを取得できる場合でも、モバイルノードは外国エージェントを介して登録する必要があります。この機能は、サイトが承認の交換を必要とする訪問ポリシー（会計など）を実施できるようにすることを目的としています。
If formerly reserved bits require some kind of monitoring/enforcement at the foreign link, foreign agents implementing the new specification for the formerly reserved bits can set the 'R' bit. This has the effect of forcing the mobile node to register through the foreign agent, so the foreign agent could then monitor/enforce the policy.
以前に予約されていたビットに外国リンクで何らかの監視/執行が必要な場合、以前に予約されていたビットの新しい仕様を実装する外国人エージェントは、「R」ビットを設定できます。これは、モバイルノードに外国人エージェントを介して登録することを強制する効果があるため、外国人エージェントはポリシーを監視/施行することができます。
Two primary mechanisms are provided for mobile nodes to detect when they have moved from one subnet to another. Other mechanisms MAY also be used. When the mobile node detects that it has moved, it SHOULD register (Section 3) with a suitable care-of address on the new foreign network. However, the mobile node MUST NOT register more frequently than once per second on average, as specified in Section 3.6.3.
モバイルノードが1つのサブネットから別のサブネットに移動したときに検出するための2つの主要なメカニズムが提供されています。他のメカニズムも使用できます。モバイルノードが移動したことを検出すると、新しい外国ネットワーク上の適切なケアオブアドレスに登録（セクション3）が登録する必要があります。ただし、セクション3.6.3で指定されているように、モバイルノードは平均して1秒あたり1回以上登録してはなりません。
The first method of move detection is based upon the Lifetime field within the main body of the ICMP Router Advertisement portion of the Agent Advertisement. A mobile node SHOULD record the Lifetime received in any Agent Advertisements, until that Lifetime expires. If the mobile node fails to receive another advertisement from the same agent within the specified Lifetime, it SHOULD assume that it has lost contact with that agent. If the mobile node has previously received an Agent Advertisement from another agent for which the Lifetime field has not yet expired, the mobile node MAY immediately attempt registration with that other agent. Otherwise, the mobile node SHOULD attempt to discover a new agent with which to register.
移動検出の最初の方法は、エージェント広告のICMPルーター広告部分の本体内の生涯フィールドに基づいています。モバイルノードは、その寿命が切れるまで、あらゆるエージェント広告で受け取った生涯を記録する必要があります。モバイルノードが指定された寿命以内に同じエージェントから別の広告を受信できない場合、そのエージェントとの接触が失われたと仮定する必要があります。モバイルノードが以前に、生涯フィールドがまだ期限切れになっていない別のエージェントからエージェント広告を受け取った場合、モバイルノードはすぐにその他のエージェントとの登録を試みることができます。それ以外の場合、モバイルノードは、登録する新しいエージェントを発見しようとする必要があります。
The second method uses network prefixes. The Prefix-Lengths Extension MAY be used in some cases by a mobile node to determine whether or not a newly received Agent Advertisement was received on the same subnet as the mobile node's current care-of address. If the prefixes differ, the mobile node MAY assume that it has moved. If a mobile node is currently using a foreign agent care-of address, the mobile node SHOULD NOT use this method of move detection unless both the current agent and the new agent include the Prefix-Lengths Extension in their respective Agent Advertisements; if this Extension is missing from one or both of the advertisements, this method of move detection SHOULD NOT be used. Similarly, if a mobile node is using a co-located care-of address, it SHOULD NOT use this method of move detection unless the new agent includes the Prefix-Lengths Extension in its Advertisement and the mobile node knows the network prefix of its current co-located care-of address. On the expiration of its current registration, if this method indicates that the mobile node has moved, rather than re-registering with its current care-of address, a mobile node MAY choose instead to register with the foreign agent sending the new Advertisement with the different network prefix. The Agent Advertisement on which the new registration is based MUST NOT have expired according to its Lifetime field.
2番目の方法では、ネットワークプレフィックスを使用します。プレフィックスレングス拡張機能は、モバイルノードによって使用される場合があり、新しく受信したエージェント広告がモバイルノードの現在のケアアドレスと同じサブネットで受信されたかどうかを判断することができます。接頭辞が異なる場合、モバイルノードが移動したと仮定する場合があります。現在、モバイルノードが外国のエージェントのケアオブアドレスを使用している場合、モバイルノードは、現在のエージェントと新しいエージェントの両方がそれぞれのエージェント広告にプレフィックスレングス拡張機能を含めない限り、この移動検出方法を使用してはなりません。この拡張機能が広告の一方または両方から欠落している場合、この移動検出方法は使用しないでください。同様に、モバイルノードが共同位置のケアオブアドレスを使用している場合、新しいエージェントがその広告にプレフィックス長拡張を含め、モバイルノードが現在のネットワークプレフィックスを知っている場合を除き、この移動検出方法を使用しないでください共同主よ、住所。現在の登録の有効期限は、この方法でモバイルノードが移動したことを示している場合、現在のアドレスで再登録するのではなく、モバイルノードは代わりに外国のエージェントに登録することを選択できます。異なるネットワークプレフィックス。新しい登録に基づいているエージェント広告は、その生涯分野に従って有効期限が切れてはなりません。
A mobile node can detect that it has returned to its home network when it receives an Agent Advertisement from its own home agent. If so, it SHOULD deregister with its home agent (Section 3). Before attempting to deregister, the mobile node SHOULD configure its routing table appropriately for its home network (Section 4.2.1). In addition, if the home network is using ARP [16], the mobile node MUST follow the procedures described in Section 4.6 with regard to ARP, proxy ARP, and gratuitous ARP.
モバイルノードは、独自のホームエージェントからエージェント広告を受信したときにホームネットワークに戻ったことを検出できます。もしそうなら、それはホームエージェント（セクション3）と登録する必要があります。登録を試みる前に、モバイルノードはホームネットワーク用にルーティングテーブルを適切に構成する必要があります（セクション4.2.1）。さらに、ホームネットワークがARP [16]を使用している場合、モバイルノードは、ARP、プロキシARP、および無償ARPに関して、セクション4.6で説明されている手順に従う必要があります。
If a mobile node detects two successive values of the sequence number in the Agent Advertisements from the foreign agent with which it is registered, the second of which is less than the first and inside the range 0 to 255, the mobile node SHOULD register again. If the second value is less than the first but is greater than or equal to 256, the mobile node SHOULD assume that the sequence number has rolled over past its maximum value (0xffff), and that re-registration is not necessary (Section 2.3).
モバイルノードが、登録されている外国人エージェントからのエージェント広告のシーケンス番号の2つの連続した値を検出すると、2番目は最初のエージェントよりも少なく、範囲0〜255の内側では、モバイルノードが再び登録する必要があります。2番目の値が最初の値よりも少ないが256以上の場合、モバイルノードは、シーケンス番号が最大値（0xFFFF）を超えて転がっていると仮定し、再登録は必要ありません（セクション2.3）。
Mobile IP registration provides a flexible mechanism for mobile nodes to communicate their current reachability information to their home agent. It is the method by which mobile nodes:
モバイルIP登録は、モバイルノードが現在の到達可能性情報をホームエージェントに伝えるための柔軟なメカニズムを提供します。これは、モバイルノードの方法です。
o request forwarding services when visiting a foreign network,
o 外国ネットワークにアクセスするときに転送サービスを要求し、
o inform their home agent of their current care-of address, o renew a registration that is due to expire, and/or
o 彼らの現在の住所を彼らのホームエージェントに通知し、o期限切れになっている登録を更新する、および/または
o deregister when they return home.
o 彼らが家に帰るとき、登録者。
Registration messages exchange information between a mobile node, (optionally) a foreign agent, and the home agent. Registration creates or modifies a mobility binding at the home agent, associating the mobile node's home address with its care-of address for the specified Lifetime.
登録メッセージは、モバイルノード（オプションで）外国人エージェントとホームエージェント間の情報を交換します。登録は、ホームエージェントでモビリティバインディングを作成または変更し、モバイルノードのホームアドレスを指定された寿命にわたってケアオブアドレスと関連付けます。
Several other (optional) capabilities are available through the registration procedure, which enable a mobile node to:
他のいくつかの（オプションの）機能は、登録手順を通じて利用できます。これにより、モバイルノードが次のようになります。
o discover its home address, if the mobile node is not configured with this information,
o モバイルノードがこの情報で構成されていない場合は、自宅の住所を発見してください。
o maintain multiple simultaneous registrations, so that a copy of each datagram will be tunneled to each active care-of address,
o 複数の同時登録を維持するため、各データグラムのコピーが各アクティブなケアオブアドレスにトンネリングされます。
o deregister specific care-of addresses while retaining other mobility bindings, and
o 他のモビリティバインディングを保持しながら、特定のケアのアドレスを免除し、
o discover the address of a home agent if the mobile node is not configured with this information.
o この情報でモバイルノードが構成されていない場合は、ホームエージェントのアドレスを発見してください。
Mobile IP defines two different registration procedures, one via a foreign agent that relays the registration to the mobile node's home agent, and one directly with the mobile node's home agent. The following rules determine which of these two registration procedures to use in any particular circumstance:
モバイルIPは、2つの異なる登録手順を定義します。1つは、モバイルノードのホームエージェントに登録を中継する外国人エージェントを介して、もう1つはモバイルノードのホームエージェントに直接登録します。以下のルールでは、特定の状況で使用するこれら2つの登録手順のどれを決定します。
o If a mobile node is registering a foreign agent care-of address, the mobile node MUST register via that foreign agent.
o モバイルノードが外国のエージェントのケアオブアドレスを登録している場合、モバイルノードはその外国人エージェントを介して登録する必要があります。
o If a mobile node is using a co-located care-of address, and receives an Agent Advertisement from a foreign agent on the link on which it is using this care-of address, the mobile node SHOULD register via that foreign agent (or via another foreign agent on this link) if the 'R' bit is set in the received Agent Advertisement message.
o モバイルノードが共同配置された住所を使用しており、このアドレスを使用しているリンク上の外国人エージェントからエージェント広告を受信している場合、モバイルノードはその外国人エージェントを介して登録する必要があります（またはこのリンク上の別の外国人エージェント）は、受信したエージェント広告メッセージに「R」ビットが設定されている場合。
o If a mobile node is otherwise using a co-located care-of address, the mobile node MUST register directly with its home agent.
o モバイルノードがそれ以外の場合は、共同配列のケアオブアドレスを使用している場合、モバイルノードはホームエージェントに直接登録する必要があります。
o If a mobile node has returned to its home network and is (de)registering with its home agent, the mobile node MUST register directly with its home agent.
o モバイルノードがホームネットワークに戻り、ホームエージェントに登録している場合、モバイルノードはホームエージェントに直接登録する必要があります。
Both registration procedures involve the exchange of Registration Request and Registration Reply messages (Section 3.3 and Section 3.4). When registering via a foreign agent, the registration procedure requires the following four messages:
両方の登録手順には、登録要求の交換と登録返信メッセージが含まれます（セクション3.3およびセクション3.4）。外国人エージェントを介して登録する場合、登録手続きには次の4つのメッセージが必要です。
a. The mobile node sends a Registration Request to the prospective foreign agent to begin the registration process.
a. モバイルノードは、登録プロセスを開始するために登録リクエストを外国人エージェントに送信します。
b. The foreign agent processes the Registration Request and then relays it to the home agent.
b. 外国人エージェントは登録要求を処理し、それをホームエージェントに中継します。
c. The home agent sends a Registration Reply to the foreign agent to grant or deny the Request.
c. ホームエージェントは、外国人エージェントに登録返信を送信して、リクエストを許可または拒否します。
d. The foreign agent processes the Registration Reply and then relays it to the mobile node to inform it of the disposition of its Request.
d. 外国人エージェントは登録返信を処理し、それをモバイルノードに中継して、その要求の処分を通知します。
When the mobile node instead registers directly with its home agent, the registration procedure requires only the following two messages:
代わりにモバイルノードがホームエージェントと直接登録する場合、登録手順では次の2つのメッセージのみが必要です。
a. The mobile node sends a Registration Request to the home agent.
a. モバイルノードは、ホームエージェントに登録リクエストを送信します。
b. The home agent sends a Registration Reply to the mobile node, granting or denying the Request.
b. ホームエージェントは、モバイルノードへの登録返信を送信し、リクエストを許可または拒否します。
The registration messages defined in Sections 3.3 and 3.4 use the User Datagram Protocol (UDP) [17]. A nonzero UDP checksum SHOULD be included in the header, and MUST be checked by the recipient. A zero UDP checksum SHOULD be accepted by the recipient. The behavior of the mobile node and the home agent with respect to their mutual acceptance of packets with zero UDP checksums SHOULD be defined as part of the Mobility Security Association that exists between them.
セクション3.3および3.4で定義されている登録メッセージは、ユーザーデータグラムプロトコル（UDP）[17]を使用します。非ゼロUDPチェックサムをヘッダーに含める必要があり、受信者がチェックする必要があります。ゼロUDPチェックサムは、受信者が受け入れる必要があります。ゼロUDPチェックサムを使用したパケットの相互受け入れに関するモバイルノードとホームエージェントの動作は、それらの間に存在するモビリティセキュリティ協会の一部として定義する必要があります。
Each mobile node, foreign agent, and home agent MUST be able to support a Mobility Security Association for mobile entities, indexed by their SPI and IP address. In the case of the mobile node, this must be its home address. See Section 5.1 for requirements for support of authentication algorithms. Registration messages between a mobile node and its home agent MUST be authenticated with an authorization-enabling extension, e.g., the Mobile-Home Authentication Extension (Section 3.5.2). This extension MUST be the first authentication extension; other foreign-agent-specific extensions MAY be added to the message after the mobile node computes the authentication.
各モバイルノード、外国人エージェント、およびホームエージェントは、SPIおよびIPアドレスによってインデックス付けされたモバイルエンティティのモビリティセキュリティ協会をサポートできる必要があります。モバイルノードの場合、これは自宅の住所でなければなりません。認証アルゴリズムのサポートの要件については、セクション5.1を参照してください。モバイルノードとそのホームエージェント間の登録メッセージは、モバイルホーム認証拡張機能（セクション3.5.2）など、承認を有する拡張機能で認証する必要があります。この拡張機能は、最初の認証拡張機能でなければなりません。モバイルノードが認証を計算した後、他の外部エージェント固有の拡張機能がメッセージに追加される場合があります。
A mobile node registers with its home agent using a Registration Request message so that its home agent can create or modify a mobility binding for that mobile node (e.g., with a new Lifetime). The Request may be relayed to the home agent by the foreign agent through which the mobile node is registering, or it may be sent directly to the home agent in the case in which the mobile node is registering a co-located care-of address.
モバイルノードは、登録要求メッセージを使用してホームエージェントに登録して、ホームエージェントがそのモバイルノードのモビリティバインディングを作成または変更できるようにします（例：新しい生涯）。リクエストは、モバイルノードが登録されている外国人エージェントによってホームエージェントに中継されるか、モバイルノードが共同住宅のケアのケアを登録している場合、ホームエージェントに直接送信される場合があります。
IP fields:
IPフィールド：
Source Address
ソースアドレス
Typically the interface address from which the message is sent.
通常、メッセージが送信されるインターフェイスアドレス。
Destination Address
宛先アドレス
Typically that of the foreign agent or the home agent.
通常、外国人エージェントまたはホームエージェントのエージェント。
See Sections 3.6.1.1 and 3.7.2.2 for details.
詳細については、セクション3.6.1.1および3.7.2.2を参照してください。
UDP fields:
UDPフィールド：
Source Port variable
ソースポート変数
Destination Port 434
宛先ポート434
The UDP header is followed by the Mobile IP fields shown below:
UDPヘッダーの後に、以下に示すモバイルIPフィールドが続きます。
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 |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 1 (Registration Request)
タイプ1（登録リクエスト）
S Simultaneous bindings. If the 'S' bit is set, the mobile node is requesting that the home agent retain its prior mobility bindings, as described in Section 3.6.1.2.
s同時バインディング。「S」ビットが設定されている場合、モバイルノードは、セクション3.6.1.2で説明されているように、ホームエージェントが以前のモビリティバインディングを保持することを要求しています。
B Broadcast datagrams. If the 'B' bit is set, the mobile node requests that the home agent tunnel to it any broadcast datagrams that it receives on the home network, as described in Section 4.3.
bデータグラムのブロードキャスト。「b」ビットが設定されている場合、モバイルノードは、セクション4.3で説明されているように、ホームエージェントがホームネットワークで受信する放送データグラムにトンネルをトンネルにトンネルにトンネルに要求します。
D Decapsulation by mobile node. If the 'D' bit is set, the mobile node will itself decapsulate datagrams that are sent to the care-of address. That is, the mobile node is using a co-located care-of address.
モバイルノードによるD脱カプセル化。「D」ビットが設定されている場合、モバイルノード自体は、ケアオブアドレスに送信されるデータグラムを脱カプセル化します。つまり、モバイルノードは、共同配置されたアドレスのケアを使用しています。
M Minimal encapsulation. If the 'M' bit is set, the mobile node requests that its home agent use minimal encapsulation [16] for datagrams tunneled to the mobile node.
m最小限のカプセル化。「M」ビットが設定されている場合、モバイルノードは、モバイルノードにトンネルを掲載したデータグラムに対して、ホームエージェントが最小限のカプセル化[16]を使用することを要求します。
G GRE encapsulation. If the 'G' bit is set, the mobile node requests that its home agent use GRE encapsulation [13] for datagrams tunneled to the mobile node.
G GREカプセル化。「g」ビットが設定されている場合、モバイルノードは、モバイルノードにトンネルされたデータグラムに対して、ホームエージェントがGREカプセル化[13]を使用することを要求します。
r Sent as zero; ignored on reception. SHOULD NOT be allocated for any other uses.
rはゼロとして送信されました。レセプションで無視されます。他の用途には割り当てられないでください。
T Reverse Tunneling requested; see [12].
t逆トンネリングが要求されました。[12]を参照してください。
x Sent as zero; ignored on reception.
xはゼロとして送信されます。レセプションで無視されます。
Lifetime
一生
The number of seconds remaining before the registration is considered expired. A value of zero indicates a request for deregistration. A value of 0xffff indicates infinity.
登録前に残っている秒数は、期限切れと見なされます。ゼロの値は、登録の要求を示します。0xffffの値は、無限を示します。
Home Address
自宅の住所
The IP address of the mobile node.
モバイルノードのIPアドレス。
Home Agent
ホームエージェント
The IP address of the mobile node's home agent.
モバイルノードのホームエージェントのIPアドレス。
Care-of Address
住所の世話
The IP address for the end of the tunnel.
トンネルの終わりのIPアドレス。
Identification
身元
A 64-bit number, constructed by the mobile node, used for matching Registration Requests with Registration Replies, and for protecting against replay attacks of registration messages. See Sections 5.4 and 5.7.
モバイルノードによって構築された64ビット番号は、登録リクエストを登録返信と一致させるために使用され、登録メッセージのリプレイ攻撃から保護するために使用されます。セクション5.4および5.7を参照してください。
Extensions
拡張機能
The fixed portion of the Registration Request is followed by one or more of the Extensions listed in Section 3.5. An authorization-enabling extension MUST be included in all Registration Requests. See Sections 3.6.1.3 and 3.7.2.2 for information on the relative order in which different extensions, when present, MUST be placed in a Registration Request message.
登録要求の固定部分の後に、セクション3.5にリストされている拡張機能の1つ以上が続きます。すべての登録リクエストに承認を有する拡張機能を含める必要があります。登録要求メッセージに異なる拡張機能を配置する必要がある相対順序の詳細については、セクション3.6.1.3および3.7.2.2を参照してください。
A mobility agent typically returns a Registration Reply message to a mobile node that has sent a Registration Request message. If the mobile node is requesting service from a foreign agent, that foreign agent will typically receive the Reply from the home agent and subsequently relay it to the mobile node. Reply messages contain the necessary codes to inform the mobile node about the status of its Request, along with the lifetime granted by the home agent, which MAY be smaller than the original Request.
モビリティエージェントは、通常、登録リクエストメッセージを送信したモバイルノードに登録返信メッセージを返します。モバイルノードが外国人エージェントからサービスを要求している場合、その外国人エージェントは通常、ホームエージェントから返信を受け取り、その後モバイルノードに中継します。返信メッセージには、元のリクエストよりも小さい場合があるホームエージェントによって付与された生涯とともに、リクエストのステータスについてモバイルノードに通知するために必要なコードが含まれています。
The foreign agent MUST NOT increase the Lifetime selected by the mobile node in the Registration Request, since the Lifetime is covered by an authentication extension that enables authorization by the home agent. Such an extension contains authentication data that cannot be correctly (re)computed by the foreign agent. The home agent MUST NOT increase the Lifetime selected by the mobile node in the Registration Request, since doing so could increase it beyond the maximum Registration Lifetime allowed by the foreign agent. If the Lifetime received in the Registration Reply is greater than that in the Registration Request, the Lifetime in the Request MUST be used. When the Lifetime received in the Registration Reply is less than that in the Registration Request, the Lifetime in the Reply MUST be used.
外国のエージェントは、登録要求でモバイルノードによって選択された寿命を増やしてはなりません。これは、寿命はホームエージェントによる認可を可能にする認証拡張機能でカバーされているためです。このような拡張機能には、外国のエージェントによって正しく（再）計算できない認証データが含まれています。ホームエージェントは、登録要求でモバイルノードによって選択された寿命を増やしてはなりません。なぜなら、そうすることで、外国人が許可されている最大登録寿命を超えて増加させることができるからです。登録返信で受け取った寿命が登録要求のそれよりも大きい場合、リクエストの生涯を使用する必要があります。登録返信で受け取った寿命が登録要求のそれよりも少ない場合、返信の生涯を使用する必要があります。
IP fields:
IPフィールド：
Source Address
ソースアドレス
Typically copied from the Destination Address of the Registration Request to which the agent is replying. See Sections 3.7.2.3 and 3.8.3.2 for complete details.
通常、エージェントが返信している登録要求の宛先アドレスからコピーされます。詳細については、セクション3.7.2.3および3.8.3.2を参照してください。
Destination Address
宛先アドレス
Copied from the source address of the Registration Request to which the agent is replying.
エージェントが返信している登録要求のソースアドレスからコピーされました。
UDP fields:
UDPフィールド：
Source Port
ソースポート
Copied from the UDP Destination Port of the corresponding Registration Request.
対応する登録要求のUDP宛先ポートからコピーされました。
Destination Port
宛先ポート
Copied from the source port of the corresponding Registration Request (Section 3.7.1).
対応する登録要求のソースポート（セクション3.7.1）からコピーされました。
The UDP header is followed by the Mobile IP fields shown below:
UDPヘッダーの後に、以下に示すモバイルIPフィールドが続きます。
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 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 3 (Registration Reply)
タイプ3（登録返信）
Code
コード
A value indicating the result of the Registration Request. See below for a list of currently defined code values.
登録要求の結果を示す値。現在定義されているコード値のリストについては、以下を参照してください。
Lifetime
一生
If the Code field indicates that the registration was accepted, the Lifetime field is set to the number of seconds remaining before the registration is considered expired. A value of zero indicates that the mobile node has been deregistered. A value of 0xffff indicates infinity. If the Code field indicates that the registration was denied, the contents of the Lifetime field are unspecified and MUST be ignored on reception.
コードフィールドが登録が受け入れられたことを示した場合、登録が期限切れと見なされる前に残りの秒数に生涯フィールドが設定されます。ゼロの値は、モバイルノードが登録されていることを示します。0xffffの値は、無限を示します。コードフィールドが登録が拒否されたことを示した場合、生涯フィールドの内容は不特定であり、受信で無視する必要があります。
Home Address
自宅の住所
The IP address of the mobile node.
モバイルノードのIPアドレス。
Home Agent
ホームエージェント
The IP address of the mobile node's home agent.
モバイルノードのホームエージェントのIPアドレス。
Identification
身元
A 64-bit number used for matching Registration Requests with Registration Replies, and for protecting against replay attacks of registration messages. The value is based on the Identification field from the Registration Request message from the mobile node, and on the style of replay protection used in the security context between the mobile node and its home agent (defined by the Mobility Security Association between them, and SPI value in the authorization-enabling extension). See Sections 5.4 and 5.7.
登録リクエストを登録返信と一致させるために使用される64ビット番号、および登録メッセージのリプレイ攻撃から保護するために使用されます。値は、モバイルノードからの登録要求メッセージからの識別フィールドと、モバイルノードとそのホームエージェントの間のセキュリティコンテキストで使用されるリプレイ保護のスタイルに基づいています（それらとSPIの間のMobility Security Associationによって定義されます承認を有する拡張機能の価値）。セクション5.4および5.7を参照してください。
Extensions
拡張機能
The fixed portion of the Registration Reply is followed by one or more of the Extensions listed in Section 3.5. An authorization-enabling extension MUST be included in all Registration Replies returned by the home agent. See Sections 3.7.2.2 and 3.8.3.3 for rules on placement of extensions to Reply messages.
登録返信の固定部分の後に、セクション3.5にリストされている拡張機能の1つ以上が続きます。Home Agentが返したすべての登録返信に認可を有する拡張機能を含める必要があります。メッセージを返信するための拡張機能の配置に関するルールについては、セクション3.7.2.2および3.8.3.3を参照してください。
The following values are defined for use within the Code field. Registration successful:
次の値は、コードフィールド内で使用するために定義されています。登録に成功：
0 registration accepted 1 registration accepted, but simultaneous mobility bindings unsupported
0登録が受け入れられた1件の登録が受け入れられましたが、同時モビリティバインディングはサポートされていません
Registration denied by the foreign agent:
外国人エージェントによる登録：
64 reason unspecified 65 administratively prohibited 66 insufficient resources 67 mobile node failed authentication 68 home agent failed authentication 69 requested Lifetime too long 70 poorly formed Request 71 poorly formed Reply 72 requested encapsulation unavailable 73 reserved and unavailable 77 invalid care-of address 78 registration timeout 80 home network unreachable (ICMP error received) 81 home agent host unreachable (ICMP error received) 82 home agent port unreachable (ICMP error received) 88 home agent unreachable (other ICMP error received) 194 Invalid Home Agent Address
64不特定65管理上禁止65管理禁止66リソース不足67モバイルノード失敗認証68ホームエージェント失敗認証69リクエストリクエスト寿命ホームネットワークの到達不能（ICMPエラーの受信）81ホームエージェントホストの到達不能（ICMPエラーが受信）82ホームエージェントポート到達不能（ICMPエラーが受信）
Registration denied by the home agent:
ホームエージェントが拒否した登録：
128 reason unspecified 129 administratively prohibited 130 insufficient resources 131 mobile node failed authentication 132 foreign agent failed authentication 133 registration Identification mismatch 134 poorly formed Request 135 too many simultaneous mobility bindings 136 unknown home agent address
128不特定の129管理上禁止130不十分なリソース131モバイルノードの失敗認証132外国人エージェントの失敗認証133登録識別不一致134リクエスト不良135あまりにも多くの同時モビリティバインディング136不明なホームエージェントアドレス
Up-to-date values of the Code field are specified in the IANA online database [48].
コードフィールドの最新の値は、IANAオンラインデータベース[48]で指定されています。
The Authenticator value computed for each authentication Extension MUST protect the following fields from the registration message:
各認証拡張機能に計算された認証値は、登録メッセージから次のフィールドを保護する必要があります。
o the UDP payload (that is, the Registration Request or Registration Reply data),
o UDPペイロード（つまり、登録要求または登録返信データ）、
o all prior Extensions in their entirety, and
o すべての以前の拡張機能全体、および
o the Type, Length, and SPI of this Extension.
o この拡張機能のタイプ、長さ、およびSPI。
The default authentication algorithm uses HMAC-MD5 [10] to compute a 128-bit "message digest" of the registration message. The data over which the HMAC is computed is defined as:
デフォルトの認証アルゴリズムは、HMAC-MD5 [10]を使用して、登録メッセージの128ビットの「メッセージダイジェスト」を計算します。HMACが計算されるデータは、次のように定義されます。
o the UDP payload (that is, the Registration Request or Registration Reply data),
o UDPペイロード（つまり、登録要求または登録返信データ）、
o all prior Extensions in their entirety, and
o すべての以前の拡張機能全体、および
o the Type, Length, and SPI of this Extension.
o この拡張機能のタイプ、長さ、およびSPI。
Note that the Authenticator field itself and the UDP header are NOT included in the computation of the default Authenticator value. See Section 5.1 for information about support requirements for message authentication codes, which are to be used with the various authentication Extensions.
Authenticatorフィールド自体とUDPヘッダーは、デフォルトのAuthenticator値の計算に含まれていないことに注意してください。さまざまな認証拡張機能で使用するメッセージ認証コードのサポート要件については、セクション5.1を参照してください。
The Security Parameter Index (SPI) within any of the authentication Extensions defines the security context that is used to compute the Authenticator value and that MUST be used by the receiver to check that value. In particular, the SPI selects the authentication algorithm and mode (Section 5.1) and secret (a shared key, or appropriate public/private key pair) used in computing the Authenticator. In order to ensure interoperability between different implementations of the Mobile IP protocol, an implementation MUST be able to associate any SPI value with any authentication algorithm and mode that it implements. In addition, all implementations of Mobile IP MUST implement the default authentication algorithm (HMAC-MD5) specified above.
認証拡張機能のいずれか内のセキュリティパラメーターインデックス（SPI）は、認証因子値を計算するために使用されるセキュリティコンテキストを定義します。特に、SPIは、認証アルゴリズムとモード（セクション5.1）とSecret（共有キー、または適切なパブリック/秘密キーペア）を選択します。モバイルIPプロトコルの異なる実装間の相互運用性を確保するために、実装は、任意のSPI値を実装する認証アルゴリズムとモードに関連付けることができなければなりません。さらに、モバイルIPのすべての実装は、上記で指定されたデフォルトの認証アルゴリズム（HMAC-MD5）を実装する必要があります。
At least one authorization-enabling extension MUST be present in all Registration Requests, and also in all Registration Replies generated by the home agent. The Mobile-Home Authentication Extension is always an authorization-enabling extension for registration messages specified in this document. This requirement is intended to eliminate problems [30] that result from the uncontrolled propagation of remote redirects in the Internet. The location of the authorization-enabling extension marks the end of the data to be authenticated by the authorizing agent interpreting that authorization-enabling extension.
少なくとも1つの承認を有する拡張機能は、すべての登録要求に、またホームエージェントによって生成されたすべての登録返信にも存在する必要があります。モバイルホーム認証拡張機能は、常にこのドキュメントで指定された登録メッセージの認証可能な拡張機能です。この要件は、インターネットでのリモートリダイレクトの制御されていない伝播に起因する問題を排除することを目的としています[30]。承認を有する拡張機能の位置は、その認可を有する拡張機能を解釈する認可エージェントによって認証されるデータの終わりをマークします。
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 | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 32
タイプ32
Length 4 plus the number of bytes in the Authenticator.
長さ4と、認証器のバイト数。
SPI Security Parameter Index (4 bytes). An opaque identifier (see Section 1.6).
SPIセキュリティパラメーターインデックス（4バイト）。不透明な識別子（セクション1.6を参照）。
Authenticator
認証者
(variable length) (See Section 3.5.1.)
（変数長）（セクション3.5.1を参照）
This Extension MAY be included in Registration Requests and Replies in cases in which a Mobility Security Association exists between the mobile node and the foreign agent. See Section 5.1 for information about support requirements for message authentication codes.
この拡張機能は、モバイルノードと外国人エージェントの間にモビリティセキュリティ協会が存在する場合の登録要求と返信に含まれる場合があります。メッセージ認証コードのサポート要件については、セクション5.1を参照してください。
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 | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 33
タイプ33
Length 4 plus the number of bytes in the Authenticator.
長さ4と、認証器のバイト数。
SPI Security Parameter Index (4 bytes). An opaque identifier (see Section 1.6).
SPIセキュリティパラメーターインデックス（4バイト）。不透明な識別子（セクション1.6を参照）。
Authenticator
認証者
(variable length) (See Section 3.5.1.)
（変数長）（セクション3.5.1を参照）
This Extension MAY be included in Registration Requests and Replies in cases in which a Mobility Security Association exists between the foreign agent and the home agent, as long as the Registration Request is not a deregistration (i.e., the mobile node requested a nonzero Lifetime and the home address is different than the care-of address). The Foreign-Home Authentication extension MUST NOT be applied to deregistration messages. See Section 5.1 for information about support requirements for message authentication codes.
この拡張機能は、登録要求が登録契約ではない限り、外国人エージェントとホームエージェントの間にモビリティセキュリティ協会が存在する場合の登録要求と返信に含めることができます（つまり、モバイルノードはゼロ以外の生涯を要求しました。ホームアドレスは、ケアオブアドレスとは異なります）。外国在宅認証拡張機能は、登録メッセージに適用してはなりません。メッセージ認証コードのサポート要件については、セクション5.1を参照してください。
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 | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 34
タイプ34
Length 4 plus the number of bytes in the Authenticator.
長さ4と、認証器のバイト数。
SPI Security Parameter Index (4 bytes). An opaque identifier (see Section 1.6).
SPIセキュリティパラメーターインデックス（4バイト）。不透明な識別子（セクション1.6を参照）。
Authenticator
認証者
(variable length) (See Section 3.5.1).
（変数長）（セクション3.5.1を参照）。
In order to perform the authentication, the home agent and the foreign agent are configured with a Mobility Security Association that is indexed by the SPI (in the appended Foreign-Home Authentication Extension) and the IP Source Address of the Registration Request. When the extension is used with a Registration Reply message, the foreign agent address MUST be used as the Destination IP Address in the IP header.
認証を実行するために、ホームエージェントと外国人エージェントは、SPI（Appeded Foreign-Home認証拡張機能）と登録リクエストのIPソースアドレスによってインデックス付けされたモビリティセキュリティ協会で構成されています。拡張機能が登録返信メッセージで使用される場合、外国人エージェントアドレスをIPヘッダーの宛先IPアドレスとして使用する必要があります。
When this extension is applied to a Registration Request message, the Mobility Security Association for verifying the correctness of the authentication data is selected by the home agent based on the value of the Source IP Address field of the Registration Request and the SPI of the Authentication extension. The Source IP Address will be the same as the Care-of Address field of the Registration Request (see Section 3.7.2.2).
この拡張機能が登録要求メッセージに適用されると、認証データの正しさを確認するためのモビリティセキュリティ協会は、登録要求のソースIPアドレスフィールドの値と認証拡張機能のSPIに基づいてホームエージェントによって選択されます。ソースIPアドレスは、登録要求のケアオブアドレスフィールドと同じです（セクション3.7.2.2を参照）。
When this extension is applied to a Registration Reply message, the Mobility Security Association for verifying the correctness of the authentication data is selected by the foreign agent based on the value of the home agent Address field of the Registration Reply.
この拡張機能が登録返信メッセージに適用されると、認証データの正しさを確認するためのモビリティセキュリティ協会は、登録返信のホームエージェントアドレスフィールドの値に基づいて外国人エージェントによって選択されます。
If the Care-of Address in the Registration Request is not in the Agent Advertisement, then the foreign agent MUST NOT append the Foreign-Home Authentication Extension when relaying the message to the home agent. Moreover, for a deregistration message (i.e., Lifetime = 0), the foreign agent MUST NOT append the Foreign-Home Authentication Extension when relaying the message to the home agent. Consequently, when the home agent (HA) receives a deregistration request that does not contain a Foreign-Home Authentication Extension, it MUST NOT for this reason discard the request as part of security association processing.
登録リクエストの住所の世話がエージェント広告にない場合、外国人エージェントは、ホームエージェントにメッセージを中継するときに外国在宅認証拡張機能を追加してはなりません。さらに、登録メッセージ（つまり、Lifetime = 0）の場合、外国人エージェントは、ホームエージェントにメッセージを中継するときに外国在宅認証拡張機能を追加してはなりません。その結果、ホームエージェント（HA）が外国の在宅認証拡張機能を含まない登録要求を受け取った場合、この理由でセキュリティ協会の処理の一環として要求を破棄してはなりません。
A mobile node MUST be configured (statically or dynamically) with a netmask and a Mobility Security Association for each of its home agents. In addition, a mobile node MAY be configured with its home address, and the IP address of one or more of its home agents; otherwise, the mobile node MAY discover a home agent using the procedures described in Section 3.6.1.2.
モバイルノードは、各ホームエージェントのネットマスクとモビリティセキュリティアソシエーションを使用して（静的または動的に）構成する必要があります。さらに、モバイルノードは、ホームアドレスと、1つ以上のホームエージェントのIPアドレスで構成できます。それ以外の場合、モバイルノードは、セクション3.6.1.2で説明されている手順を使用してホームエージェントを発見する場合があります。
If the mobile node is not configured with a home address, it MAY use the Mobile Node Network Access Identifier (NAI) extension [2] to identify itself, and set the Home Address field of the Registration Request to 0.0.0.0. In this case, the mobile node MUST be able to assign its home address after extracting this information from the Registration Reply from the home agent.
モバイルノードがホームアドレスで構成されていない場合、モバイルノードネットワークアクセス識別子（NAI）拡張機能[2]を使用して、登録要求のホームアドレスフィールドを0.0.0.0に設定できます。この場合、モバイルノードは、ホームエージェントからの登録返信からこの情報を抽出した後、ホームアドレスを割り当てることができる必要があります。
For each pending registration, the mobile node maintains the following information:
保留中の登録ごとに、モバイルノードは次の情報を維持します。
o the link-layer address of the foreign agent to which the Registration Request was sent, if applicable,
o 登録要求が送信された外国人エージェントのリンク層アドレス（該当する場合）
o the IP Destination Address of the Registration Request,
o 登録要求のIP宛先アドレス、
o the care-of address used in the registration,
o 登録で使用される住所のケア、
o the Identification value sent in the registration,
o 登録で送信された識別値、
o the originally requested Lifetime, and
o 元々要求された生涯、そして
o the remaining Lifetime of the pending registration.
o 保留中の登録の残りの寿命。
A mobile node SHOULD initiate a registration whenever it detects a change in its network connectivity. See Section 2.4.2 for methods by which mobile nodes MAY make such a determination. When it is away from home, the mobile node's Registration Request allows its home agent to create or modify a mobility binding for it. When it is at home, the mobile node's (de)Registration Request allows its home agent to delete any previous mobility binding(s) for it. A mobile node operates without the support of mobility functions when it is at home.
モバイルノードは、ネットワーク接続の変更を検出するたびに登録を開始する必要があります。モバイルノードがそのような決定を下す可能性のある方法については、セクション2.4.2を参照してください。自宅から離れている場合、モバイルノードの登録要求により、ホームエージェントはモビリティバインディングを作成または変更できます。自宅にいる場合、モバイルノード（DE）登録要求により、ホームエージェントは以前のモビリティバインディングを削除できます。モバイルノードは、自宅にいるときにモビリティ機能をサポートせずに動作します。
There are other conditions under which the mobile node SHOULD (re)register with its foreign agent, such as when the mobile node detects that the foreign agent has rebooted (as specified in Section 2.4.4) and when the current registration's Lifetime is near expiration.
モバイルノードが外国人ノードが外国人エージェントが再起動したこと（セクション2.4.4で指定されているように）を検出したときや、現在の登録の寿命が近づいている場合など、モバイルノードが外部エージェントに（再）登録する必要がある他の条件があります。。
In the absence of link-layer indications of changes in point of attachment, Agent Advertisements from new agents SHOULD NOT cause a mobile node to attempt a new registration, if its current registration has not expired and it is still also receiving Agent Advertisements from the foreign agent with which it is currently registered. In the absence of link-layer indications, a mobile node MUST NOT attempt to register more often than once per second.
添付ファイルの変化のリンク層指標がない場合、新しいエージェントからのエージェント広告は、現在の登録が期限切れになっておらず、外国人からのエージェント広告も受信している場合、モバイルノードに新しい登録を試みるべきではありません。現在登録されているエージェント。リンク層指示がない場合、モバイルノードは1秒あたり1回以上登録しようとしてはなりません。
A mobile node MAY register with a different agent when transport-layer protocols indicate excessive retransmissions. A mobile node MUST NOT consider reception of an ICMP Redirect from a foreign agent that is currently providing service to it as reason to register with a new foreign agent. Within these constraints, the mobile node MAY register again at any time.
輸送層プロトコルが過度の再送信を示す場合、モバイルノードは異なるエージェントに登録する場合があります。モバイルノードは、新しい外国人エージェントに登録する理由として現在サービスを提供している外国人エージェントからのICMPリダイレクトの受信を考慮してはなりません。これらの制約内で、モバイルノードはいつでも再び登録できます。
Appendix C shows some examples of how the fields in registration messages would be set up in some typical registration scenarios.
付録Cは、登録メッセージのフィールドがいくつかの典型的な登録シナリオでどのように設定されるかの例を示しています。
The following sections specify details for the values that the mobile node MUST supply in the fields of Registration Request messages.
次のセクションでは、登録要求メッセージのフィールドにモバイルノードが提供する必要がある値の詳細を指定します。
This section provides the specific rules by which mobile nodes pick values for the IP header fields of a Registration Request.
このセクションでは、登録要求のIPヘッダーフィールドのモバイルノードを選択する特定のルールを提供します。
IP Source Address:
IPソースアドレス：
o When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address.
o 共同住民の住所を使用して外国ネットワークに登録する場合、IPソースアドレスはケアオブアドレスでなければなりません。
o Otherwise, if the mobile node does not have a home address, the IP source address MUST be 0.0.0.0.
o それ以外の場合、モバイルノードにホームアドレスがない場合、IPソースアドレスは0.0.0.0でなければなりません。
o In all other circumstances, the IP source address MUST be the mobile node's home address.
o 他のすべての状況では、IPソースアドレスはモバイルノードのホームアドレスでなければなりません。
IP Destination Address:
IP宛先アドレス：
o When the mobile node has discovered the agent with which it is registering, through some means (e.g., link-layer) that does not provide the IP address of the agent (the IP address of the agent is unknown to the mobile node), then the "All Mobility Agents" multicast address (224.0.0.11) MUST be used. In this case, the mobile node MUST use the agent's link-layer unicast address in order to deliver the datagram to the correct agent.
o モバイルノードが、エージェントのIPアドレス（エージェントのIPアドレスがモバイルノードに不明）を提供しない何らかの手段（例：リンク層）を通じて、登録しているエージェントを発見したとき、「すべてのモビリティエージェント」マルチキャストアドレス（224.0.0.11）を使用する必要があります。この場合、モバイルノードは、データグラムを正しいエージェントに配信するために、エージェントのリンク層ユニキャストアドレスを使用する必要があります。
o When registering with a foreign agent, the address of the agent as learned from the IP source address of the corresponding Agent Advertisement MUST be used. This MAY be an address that does not appear as an advertised care-of address in the Agent Advertisement. In addition, when transmitting this Registration Request message, the mobile node MUST use a link-layer Destination Address copied from the link-layer source address of the Agent Advertisement message in which it learned this foreign agent's IP address.
o 外国人エージェントに登録する場合、対応するエージェント広告のIPソースアドレスから学習したエージェントのアドレスを使用する必要があります。これは、エージェント広告に宣伝されている住所として表示されないアドレスかもしれません。さらに、この登録要求メッセージを送信する場合、モバイルノードは、この外国人エージェントのIPアドレスを学習したエージェント広告メッセージのリンク層ソースアドレスからコピーされたリンク層宛先アドレスを使用する必要があります。
o When the mobile node is registering directly with its home agent and knows the (unicast) IP address of its home agent, the Destination Address MUST be set to this address.
o モバイルノードがホームエージェントに直接登録し、ホームエージェントの（ユニキャスト）IPアドレスを知っている場合、宛先アドレスをこのアドレスに設定する必要があります。
o If the mobile node is registering directly with its home agent, but does not know the IP address of its home agent, the mobile node may use dynamic home agent address resolution to automatically determine the IP address of its home agent (Section 3.6.1.2). In this case, the IP Destination Address is set to the subnet-directed broadcast address of the mobile node's home network. This address MUST NOT be used as the Destination IP Address if the mobile node is registering via a foreign agent, although it MAY be used as the home agent address in the body of the Registration Request when registering via a foreign agent.
o モバイルノードがホームエージェントに直接登録しているがホームエージェントのIPアドレスがわからない場合、モバイルノードは動的ホームエージェントアドレス解像度を使用してホームエージェントのIPアドレスを自動的に決定できます（セクション3.6.1.2）。この場合、IP宛先アドレスは、モバイルノードのホームネットワークのサブネット指向ブロードキャストアドレスに設定されます。モバイルノードが外国人エージェントを介して登録されている場合、このアドレスは宛先IPアドレスとして使用してはなりませんが、外国人エージェントを介して登録する際に登録要求の本文でホームエージェントアドレスとして使用できます。
IP Time to Live:
ライブのIP時間：
o The IP TTL field MUST be set to 1 if the IP Destination Address is set to the "All Mobility Agents" multicast address as described above. Otherwise, a suitable value should be chosen in accordance with standard IP practice [18].
o IP宛先アドレスが上記のように「すべてのモビリティエージェント」マルチキャストアドレスに設定されている場合、IP TTLフィールドを1に設定する必要があります。それ以外の場合、標準的なIPプラクティスに従って適切な値を選択する必要があります[18]。
This section provides specific rules by which mobile nodes pick values for the fields within the fixed portion of a Registration Request.
このセクションでは、登録要求の固定部分内のフィールドのモバイルノードを選択する特定のルールを提供します。
A mobile node MAY set the 'S' bit in order to request that the home agent maintain prior mobility binding(s). Otherwise, the home agent deletes any previous binding(s) and replaces them with the new binding specified in the Registration Request. Multiple simultaneous mobility bindings are likely to be useful when a mobile node using at least one wireless network interface moves within wireless transmission range of more than one foreign agent. IP explicitly allows duplication of datagrams. When the home agent allows simultaneous bindings, it will tunnel a separate copy of each arriving datagram to each care-of address, and the mobile node will receive multiple copies of datagrams destined to it.
モバイルノードは、ホームエージェントが以前のモビリティバインディングを維持するように要求するために、「S」ビットを設定する場合があります。それ以外の場合、ホームエージェントは以前のバインディングを削除し、登録要求で指定された新しいバインディングに置き換えます。複数の同時モビリティバインディングは、少なくとも1つのワイヤレスネットワークインターフェイスを使用するモバイルノードが、複数の外国人エージェントのワイヤレス送信範囲内で移動する場合に役立つ可能性があります。IPは、データグラムの複製を明示的に許可します。ホームエージェントが同時にバインディングを許可すると、到着する各データグラムの個別のコピーを各アドレスにトンネルし、モバイルノードはそれに向けられたデータグラムの複数のコピーを受け取ります。
The mobile node SHOULD set the 'D' bit if it is registering with a co-located care-of address. Otherwise, the 'D' bit MUST NOT be set.
モバイルノードは、共同住宅のケアオブアドレスに登録している場合、「D」ビットを設定する必要があります。それ以外の場合、「D」ビットを設定してはなりません。
A mobile node MAY set the 'B' bit to request its home agent to forward to it a copy of broadcast datagrams received by its home agent from the home network. The method used by the home agent to forward broadcast datagrams depends on the type of care-of address registered by the mobile node, as determined by the 'D' bit in the mobile node's Registration Request:
モバイルノードは、「B」ビットを設定して、ホームエージェントがホームエージェントから受け取ったブロードキャストデータグラムのコピーをホームネットワークから転送するように要求する場合があります。ホームエージェントがブロードキャストデータグラムを転送するために使用する方法は、モバイルノードの登録リクエストの「D」ビットによって決定されるように、モバイルノードによって登録されたアドレスのケアの種類によって異なります。
o If the 'D' bit is set, then the mobile node has indicated that it will decapsulate any datagrams tunneled to this care-of address itself (the mobile node is using a co-located care-of address). In this case, to forward such a received broadcast datagram to the mobile node, the home agent MUST tunnel it to this care-of address. The mobile node detunnels the received datagram in the same way as any other datagram tunneled directly to it.
o 「d」ビットが設定されている場合、モバイルノードは、このアドレス自体にトンネルされたデータグラムを脱カプセル化することを示しています（モバイルノードは、共同住宅のケアオブアドレスを使用しています）。この場合、このような受信したブロードキャストデータグラムをモバイルノードに転送するには、ホームエージェントがこの住所にそれをトンネルする必要があります。モバイルノードは、他のデータグラムが直接トンネリングしたのと同じ方法で、受信したデータグラムをデトゥンネルします。
o If the 'D' bit is NOT set, then the mobile node has indicated that it is using a foreign agent care-of address, and that the foreign agent will thus decapsulate arriving datagrams before forwarding them to the mobile node. In this case, to forward such a received broadcast datagram to the mobile node, the home agent MUST first encapsulate the broadcast datagram in a unicast datagram addressed to the mobile node's home address, and then MUST tunnel this resulting datagram to the mobile node's care-of address.
o 「D」ビットが設定されていない場合、モバイルノードは、外国人エージェントのケアオブアドレスを使用していること、および外国人エージェントがモバイルノードに転送する前に到着データグラムを脱カプセル化することを示しています。この場合、このような受信したブロードキャストデータグラムをモバイルノードに転送するには、ホームエージェントが最初にモバイルノードのホームアドレスにアドレス指定されたユニキャストデータグラムのブロードキャストデータグラムをカプセル化する必要があります。住所の。
When decapsulated by the foreign agent, the inner datagram will thus be a unicast IP datagram addressed to the mobile node, identifying to the foreign agent the intended destination of the encapsulated broadcast datagram, and will be delivered to the mobile node in the same way as any tunneled datagram arriving for the mobile node. The foreign agent MUST NOT decapsulate the encapsulated broadcast datagram and MUST NOT use a local network broadcast to transmit it to the mobile node. The mobile node thus MUST decapsulate the encapsulated broadcast datagram itself, and thus MUST NOT set the 'B' bit in its Registration Request in this case unless it is capable of decapsulating datagrams.
外部エージェントによって脱カプセル化されると、内側のデータグラムはモバイルノードにアドレス指定されたユニキャストIPデータグラムになり、カプセル化されたブロードキャストデータグラムの意図した宛先を外部エージェントに識別し、モバイルノードに同じ方法でモバイルノードに配信されます。モバイルノードに到着するトンネリングデータグラム。外国のエージェントは、カプセル化されたブロードキャストデータグラムを脱カプセル化してはならず、ローカルネットワークブロードキャストを使用してモバイルノードに送信してはなりません。したがって、モバイルノードは、カプセル化されたブロードキャストデータグラム自体を脱カプセル化する必要があります。したがって、データグラムを脱カプセル化できない限り、この場合、登録要求に「B」ビットを設定してはなりません。
The mobile node MAY request alternative forms of encapsulation by setting the 'M' bit and/or the 'G' bit, but only if the mobile node is decapsulating its own datagrams (the mobile node is using a co-located care-of address) or if its foreign agent has indicated support for these forms of encapsulation by setting the corresponding bits in the Mobility Agent Advertisement Extension of an Agent Advertisement received by the mobile node. Otherwise, the mobile node MUST NOT set these bits.
モバイルノードは、モバイルノードが独自のデータグラムを脱カプセル化している場合にのみ、「M」ビットおよび/または「G」ビットを設定することにより、代替形式のカプセル化を要求することができます（モバイルノードは、共同配置されたアドレスのケアを使用しています）または、その外国人が、モバイルノードで受信したエージェント広告のモビリティエージェント広告拡張に対応するビットを設定することにより、これらの形式のカプセル化のサポートを示している場合。それ以外の場合、モバイルノードはこれらのビットを設定してはなりません。
The Lifetime field is chosen as follows:
生涯フィールドは次のように選択されます。
o If the mobile node is registering with a foreign agent, the Lifetime SHOULD NOT exceed the value in the Registration Lifetime field of the Agent Advertisement message received from the foreign agent. When the method by which the care-of address is learned does not include a Lifetime, the default ICMP Router Advertisement Lifetime (1800 seconds) MAY be used.
o モバイルノードが外国のエージェントに登録している場合、生涯は、外国人エージェントから受け取ったエージェント広告メッセージの登録生涯フィールドの値を超えてはなりません。住所のケアが学習される方法に寿命が含まれていない場合、デフォルトのICMPルーター広告寿命（1800秒）を使用できます。
o The mobile node MAY ask a home agent to delete a particular mobility binding, by sending a Registration Request with the care-of address for this binding, with the Lifetime field set to zero (Section 3.8.2).
o モバイルノードは、このバインディングのケアオブアドレスで登録要求を送信して、ゼロに設定されたライフタイムフィールドを使用して、ホームエージェントに特定のモビリティバインディングを削除するように依頼する場合があります（セクション3.8.2）。
o Similarly, a Lifetime of zero is used when the mobile node deregisters all care-of addresses, such as upon returning home.
o 同様に、モバイルノードが家に帰るときなど、すべてのケアオフアドレスをデレギスターする場合、ゼロの寿命が使用されます。
The Home Address field MUST be set to the mobile node's home address, if this information is known. Otherwise, the Home Address field MUST be set to zeroes.
この情報がわかっている場合は、ホームアドレスフィールドをモバイルノードの自宅アドレスに設定する必要があります。それ以外の場合、ホームアドレスフィールドはゼロに設定する必要があります。
The Home Agent field MUST be set to the address of the mobile node's home agent, if the mobile node knows this address. Otherwise, the mobile node MAY use dynamic home agent address resolution to learn the address of its home agent. In this case, the mobile node MUST set the Home Agent field to the subnet-directed broadcast address of the mobile node's home network. Each home agent receiving such a Registration Request with a broadcast Destination Address MUST reject the mobile node's registration and SHOULD return a rejection Registration Reply indicating its unicast IP address for use by the mobile node in a future registration attempt.
モバイルノードがこのアドレスを知っている場合、ホームエージェントフィールドは、モバイルノードのホームエージェントのアドレスに設定する必要があります。それ以外の場合、モバイルノードは、動的ホームエージェントアドレス解像度を使用して、ホームエージェントのアドレスを学習できます。この場合、モバイルノードは、モバイルノードのホームネットワークのサブネット指向ブロードキャストアドレスにホームエージェントフィールドを設定する必要があります。ブロードキャスト宛先アドレスでそのような登録要求を受信する各ホームエージェントは、モバイルノードの登録を拒否する必要があり、将来の登録の試みでモバイルノードが使用するためのユニキャストIPアドレスを示す拒否登録返信を返す必要があります。
The Care-of Address field MUST be set to the value of the particular care-of address that the mobile node wishes to (de)register. In the special case in which a mobile node wishes to deregister all care-of addresses, it MUST set this field to its home address.
住所のケアフィールドは、モバイルノードが（DE）登録することを望む特定の住所の価値に設定する必要があります。モバイルノードがすべてのアドレスを登録したい特別なケースでは、このフィールドを自宅の住所に設定する必要があります。
The mobile node chooses the Identification field in accordance with the style of replay protection it uses with its home agent. This is part of the Mobility Security Association the mobile node shares with its home agent. See Section 5.7 for the method by which the mobile node computes the Identification field.
モバイルノードは、ホームエージェントで使用するリプレイ保護のスタイルに従って識別フィールドを選択します。これは、モバイルノードがホームエージェントと共有するモビリティセキュリティ協会の一部です。モバイルノードが識別フィールドを計算する方法については、セクション5.7を参照してください。
This section describes the ordering of any mandatory and any optional Extensions that a mobile node appends to a Registration Request. This ordering is REQUIRED: a. The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by
このセクションでは、モバイルノードが登録リクエストに追加する必須およびオプションの拡張機能の順序について説明します。この注文が必要です。IPヘッダー、続いてUDPヘッダーが続き、その後に登録要求の固定長い部分が続き、その後
b. If present, any non-authentication Extensions expected to be used by the home agent or other authorizing agent (which may or may not also be useful to the foreign agent), followed by
b. 存在する場合、ホームエージェントまたは他の認可エージェント（外国人エージェントにとっても有用である場合とそうでない場合がある場合）が使用することが予想される非認証拡張機能に続いて
c. All authorization-enabling extensions (see Section 1.6), followed by
c. すべての承認を有する拡張機能（セクション1.6を参照）、続いて
d. If present, any non-authentication Extensions used only by the foreign agent, followed by
d. 存在する場合、外国のエージェントのみが使用する非認証拡張機能に続いて
e. The Mobile-Foreign Authentication Extension, if present.
e. 存在する場合、モバイル外定認証拡張機能。
Note that items (a) and (c) MUST appear in every Registration Request sent by the mobile node. Items (b), (d), and (e) are optional. However, item (e) MUST be included when the mobile node and the foreign agent share a Mobility Security Association.
項目（a）および（c）は、モバイルノードから送信されたすべての登録要求に表示される必要があることに注意してください。項目（b）、（d）、および（e）はオプションです。ただし、モバイルノードと外国人エージェントがモビリティセキュリティ協会を共有している場合は、アイテム（E）を含める必要があります。
Registration Replies will be received by the mobile node in response to its Registration Requests. Registration Replies generally fall into three categories:
登録返信は、登録リクエストに応じてモバイルノードによって受信されます。通常、登録返信は3つのカテゴリに分類されます。
o the registration was accepted,
o 登録は受け入れられました、
o the registration was denied by the foreign agent, or
o 登録は外国人エージェントによって拒否された、または
o the registration was denied by the home agent.
o 登録はホームエージェントによって拒否されました。
The remainder of this section describes the Registration Reply handling by a mobile node in each of these three categories.
このセクションの残りの部分では、これらの3つのカテゴリのそれぞれのモバイルノードによる登録返信処理について説明します。
Registration Replies with an invalid, non-zero UDP checksum MUST be silently discarded.
登録は無効で、ゼロ以外のUDPチェックサムを静かに廃棄する必要があります。
In addition, the low-order 32 bits of the Identification field in the Registration Reply MUST be compared to the low-order 32 bits of the Identification field in the most recent Registration Request sent to the replying agent. If they do not match, the Reply MUST be silently discarded.
さらに、登録応答の識別フィールドの低次の32ビットを、応答エージェントに送信した最新の登録要求の低次の32ビットの識別フィールドと比較する必要があります。それらが一致しない場合、返信は静かに破棄する必要があります。
Also, the Registration Reply MUST be checked for presence of an authorization-enabling extension. For all Registration Reply messages containing a status code indicating status from the home agent, the mobile node MUST check for the presence of an authorization-enabling extension, acting in accordance with the Code field in the Reply. The rules are as follows:
また、登録返信は、承認を有する拡張機能の存在を確認する必要があります。ホームエージェントからのステータスを示すステータスコードを含むすべての登録返信メッセージについては、モバイルノードは、返信のコードフィールドに従って機能する承認を有する拡張機能の存在を確認する必要があります。ルールは次のとおりです。
a. If the mobile node and the foreign agent share a Mobility Security Association, exactly one Mobile-Foreign Authentication Extension MUST be present in the Registration Reply, and the mobile node MUST check the Authenticator value in the Extension. If no Mobile-Foreign Authentication Extension is found, or if more than one Mobile-Foreign Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Reply and SHOULD log the event as a security exception.
a. モバイルノードと外国人エージェントがモビリティセキュリティ協会を共有する場合、登録返信に1つのモバイル外定認証拡張機能が正確に存在する必要があり、モバイルノードは拡張機能の認証因子値を確認する必要があります。モバイル外定認証拡張機能が見つからない場合、または複数のモバイル外定認証拡張機能が見つかった場合、または認証器が無効である場合、モバイルノードは回答を静かに破棄し、セキュリティ例外としてイベントを記録する必要があります。
b. If the Code field indicates that service is denied by the home agent, or if the Code field indicates that the registration was accepted by the home agent, exactly one Mobile-Home Authentication Extension MUST be present in the Registration Reply, and the mobile node MUST check the Authenticator value in the Extension. If the Registration Reply was generated by the home agent but no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Reply and SHOULD log the event as a security exception.
b. コードフィールドがホームエージェントによってサービスが拒否されていることを示している場合、またはコードフィールドがホームエージェントによって登録が受け入れられたことを示した場合、登録返信に正確に1つのモバイルホーム認証拡張機能が存在する必要があり、モバイルノードは拡張機能の認証値を確認してください。登録返信がホームエージェントによって生成されたが、モバイルホーム認証拡張機能が見つからない場合、または複数のモバイルホーム認証拡張機能が見つかった場合、または認証器が無効である場合、モバイルノードは回答を静かに廃棄する必要があります。セキュリティ例外としてイベントを記録します。
If the Code field indicates an authentication failure, either at the foreign agent or the home agent, then it is quite possible that any authenticators in the Registration Reply will also be in error. This could happen, for example, if the shared secret between the mobile node and home agent was erroneously configured. The mobile node SHOULD log such errors as security exceptions.
コードフィールドが、外国のエージェントまたはホームエージェントのいずれかで認証障害を示している場合、登録返信の認証者も誤っている可能性があります。これは、たとえば、モバイルノードとホームエージェントの間の共有秘密が誤って構成されている場合に発生する可能性があります。モバイルノードは、セキュリティの例外としてそのようなエラーを記録する必要があります。
If the Code field indicates that the request has been accepted, the mobile node SHOULD configure its routing table appropriately for its current point of attachment (Section 4.2.1).
コードフィールドが要求が受け入れられていることを示した場合、モバイルノードは、現在の添付ファイルのためにルーティングテーブルを適切に構成する必要があります（セクション4.2.1）。
If the mobile node is returning to its home network and that network is one that implements ARP, the mobile node MUST follow the procedures described in Section 4.6 with regard to ARP, proxy ARP, and gratuitous ARP.
モバイルノードがホームネットワークに戻っており、そのネットワークがARPを実装する場合、モバイルノードは、ARP、プロキシARP、および無償ARPに関してセクション4.6で説明されている手順に従う必要があります。
If the mobile node has registered on a foreign network, it SHOULD re-register before the expiration of the Lifetime of its registration. As described in Section 3.6, for each pending Registration Request, the mobile node MUST maintain the remaining lifetime of this pending registration, as well as the original Lifetime from the Registration Request. When the mobile node receives a valid Registration Reply, the mobile node MUST decrease its view of the remaining lifetime of the registration by the amount by which the home agent decreased the originally requested Lifetime. This procedure is equivalent to the mobile node starting a timer for the granted Lifetime at the time it sent the Registration Request, even though the granted Lifetime is not known to the mobile node until the Registration Reply is received. Since the Registration Request is certainly sent before the home agent begins timing the registration Lifetime (also based on the granted Lifetime), this procedure ensures that the mobile node will re-register before the home agent expires and deletes the registration, in spite of possibly non-negligible transmission delays for the original Registration Request and Reply that started the timing of the Lifetime at the mobile node and its home agent.
モバイルノードが外部ネットワークに登録されている場合、登録の寿命が切れる前に再登録する必要があります。セクション3.6で説明されているように、保留中の登録要求ごとに、モバイルノードは、この保留中の登録の残りの寿命と、登録要求からの元の寿命を維持する必要があります。モバイルノードが有効な登録返信を受信した場合、モバイルノードは、ホームエージェントが元々要求された寿命を減らす金額によって、登録の残りの寿命のビューを減らす必要があります。この手順は、登録リクエストを送信した時点で、付与された生涯のタイマーを起動するモバイルノードと同等です。ホームエージェントが登録寿命のタイミングを開始する前に登録要求が確実に送信されるため（付与された生涯に基づいて）、この手順により、ホームエージェントが期限切れになる前にモバイルノードが再登録されることが保証されます。元の登録リクエストのための無視できない送信遅延と、モバイルノードとそのホームエージェントでのライフタイミングのタイミングを開始した返信。
If the Code field indicates that service is being denied, the mobile node SHOULD log the error. In certain cases, the mobile node may be able to "repair" the error. These include:
コードフィールドがサービスが拒否されていることを示した場合、モバイルノードはエラーをログに記録する必要があります。特定の場合、モバイルノードはエラーを「修復」できる場合があります。これらには以下が含まれます：
Code 69: (Denied by foreign agent, requested Lifetime too long)
コード69 ：（外国人エージェントによって拒否された、寿命が長すぎます）
In this case, the Lifetime field in the Registration Reply will contain the maximum Lifetime value that the foreign agent is willing to accept in any Registration Request. The mobile node MAY attempt to register with this same agent, using a Lifetime in the Registration Request that MUST be less than or equal to the value specified in the Reply.
この場合、登録返信の生涯フィールドには、外国人が登録要求に受け入れる意思がある最大生涯値が含まれます。モバイルノードは、この同じエージェントに登録しようとする場合があります。これは、返信で指定された値と等しくなければならない登録要求で寿命を使用して使用します。
Code 133: (Denied by home agent, registration Identification mismatch)
コード133 ：（ホームエージェントによって拒否された、登録識別の不一致）
In this case, the Identification field in the Registration Reply will contain a value that allows the mobile node to synchronize with the home agent, based upon the style of replay protection in effect (Section 5.7). The mobile node MUST adjust the parameters it uses to compute the Identification field based upon the information in the Registration Reply, before issuing any future Registration Requests.
この場合、登録返信の識別フィールドには、有効なリプレイ保護のスタイルに基づいて、モバイルノードがホームエージェントと同期できるようにする値が含まれます（セクション5.7）。将来の登録リクエストを発行する前に、モバイルノードは、登録返信の情報に基づいて識別フィールドを計算するために使用するパラメーターを調整する必要があります。
Code 136: (Denied by home agent, unknown home agent address)
コード136 ：（ホームエージェント、不明なホームエージェントアドレスによる拒否）
This code is returned by a home agent when the mobile node is performing dynamic home agent address resolution as described in Sections 3.6.1.1 and 3.6.1.2. In this case, the Home Agent field within the Reply will contain the unicast IP address of the home agent returning the Reply. The mobile node MAY then attempt to register with this home agent in future Registration Requests. In addition, the mobile node SHOULD adjust the parameters it uses to compute the Identification field based upon the corresponding field in the Registration Reply, before issuing any future Registration Requests.
このコードは、セクション3.6.1.1および3.6.1.2で説明されているように、モバイルノードが動的ホームエージェントアドレス解像度を実行しているときにホームエージェントによって返されます。この場合、返信内のホームエージェントフィールドには、返信を返すホームエージェントのユニキャストIPアドレスが含まれます。モバイルノードは、将来の登録リクエストでこのホームエージェントに登録しようとする場合があります。さらに、モバイルノードは、将来の登録リクエストを発行する前に、登録返信の対応するフィールドに基づいて識別フィールドを計算するために使用するパラメーターを調整する必要があります。
When no Registration Reply has been received within a reasonable time, another Registration Request MAY be transmitted. When timestamps are used, a new registration Identification is chosen for each retransmission; thus, it counts as a new registration. When nonces are used, the unanswered Request is retransmitted unchanged; thus, the retransmission does not count as a new registration (Section 5.7). In this way, a retransmission will not require the home agent to resynchronize with the mobile node by issuing another nonce in the case in which the original Registration Request (rather than its Registration Reply) was lost by the network.
合理的な時間内に登録返信が受信されていない場合、別の登録要求が送信される場合があります。タイムスタンプを使用すると、再送信ごとに新しい登録識別が選択されます。したがって、新しい登録としてカウントされます。Noncesを使用すると、未回答の要求が変更されていないことを再送信します。したがって、再送信は新しい登録としてカウントされません（セクション5.7）。このようにして、再送信では、ネットワークによって（登録返信ではなく）元の登録要求が失われた場合に別のNONCEを発行することにより、ホームエージェントがモバイルノードと再同期する必要はありません。
The maximum time until a new Registration Request is sent SHOULD be no greater than the requested Lifetime of the Registration Request. The minimum value SHOULD be large enough to account for the size of the messages, twice the round-trip time for transmission to the home agent, and at least an additional 100 milliseconds to allow for processing the messages before responding. The round-trip time for transmission to the home agent will be at least as large as the time required to transmit the messages at the link speed of the mobile node's current point of attachment. Some circuits add another 200 milliseconds of satellite delay in the total round-trip time to the home agent. The minimum time between Registration Requests MUST NOT be less than 1 second. Each successive retransmission timeout period SHOULD be at least twice the previous period, as long as that is less than the maximum as specified above.
新しい登録要求が送信されるまでの最大時間は、登録要求の要求された寿命よりも大きくなければなりません。最小値は、メッセージのサイズを考慮するのに十分な大きさでなければなりません。ホームエージェントへの送信のための往復時間の2倍、および応答する前にメッセージを処理できるように追加の100ミリ秒を追加する必要があります。ホームエージェントへの送信の往復時間は、少なくともモバイルノードの現在の添付ファイルのリンク速度でメッセージを送信するのに必要な時間と同じくらい大きくなります。一部の回路では、ホームエージェントへの合計往復時間にさらに200ミリ秒の衛星遅延が追加されます。登録リクエスト間の最小時間は、1秒以上でなければなりません。連続する各再送信タイムアウト期間は、上記の最大値よりも少ない限り、少なくとも前の期間の少なくとも2倍である必要があります。
The foreign agent plays a mostly passive role in Mobile IP registration. It relays Registration Requests between mobile nodes and home agents, and, when it provides the care-of address, decapsulates datagrams for delivery to the mobile node. It SHOULD also send periodic Agent Advertisement messages to advertise its presence as described in Section 2.3, if not detectable by link-layer means.
外国人エージェントは、モバイルIP登録において主に受動的な役割を果たします。モバイルノードとホームエージェント間の登録要求を中継し、アドレスのケアを提供すると、モバイルノードへの配信のためにデータグラムを脱カプセル化します。また、リンク層手段で検出できない場合、セクション2.3で説明されているように、その存在感を宣伝するために、周期的なエージェント広告メッセージを送信する必要があります。
A foreign agent MUST NOT transmit a Registration Request, unless the request is being relayed from a mobile node to that mobile node's home agent. A foreign agent MUST NOT transmit a Registration Reply except when relaying a Registration Reply received from a mobile node's home agent, or when replying to a Registration Request received from a mobile node in the case in which the foreign agent is denying service to the mobile node. In particular, a foreign agent MUST NOT generate a Registration Request or Reply because a mobile node's registration Lifetime has expired. A foreign agent also MUST NOT originate a Registration Request message that asks for deregistration of a mobile node; however, it MUST relay well-formed (de)Registration Requests originated by a mobile node.
外国人エージェントは、モバイルノードからそのモバイルノードのホームエージェントにリクエストが中継されていない限り、登録要求を送信してはなりません。外国人エージェントは、モバイルノードのホームエージェントから受信した登録返信を中継する場合、または外国人エージェントがモバイルノードへのサービスを拒否している場合のモバイルノードから受信した登録リクエストに返信する場合を除き、登録返信を送信してはなりません。。特に、モバイルノードの登録寿命が切れているため、外国人エージェントは登録リクエストまたは返信を生成してはなりません。また、外国人エージェントは、モバイルノードの登録を要求する登録要求メッセージを発信してはなりません。ただし、モバイルノードから発信される適切に形成された（DE）登録リクエストを中継する必要があります。
Each foreign agent MUST be configured with a care-of address. In addition, for each pending or current registration the foreign agent MUST maintain a visitor list entry containing the following information obtained from the mobile node's Registration Request:
各外国人エージェントは、ケアオブアドレスで構成する必要があります。さらに、保留中または現在の登録ごとに、外国人エージェントは、モバイルノードの登録要求から取得した以下の情報を含む訪問者リストエントリを維持する必要があります。
o the link-layer source address of the mobile node
o モバイルノードのリンク層ソースアドレス
o the IP Source Address (the mobile node's home address) or its co-located care-of address (see description of the 'R' bit in Section 2.1.1)
o IPソースアドレス（モバイルノードのホームアドレス）またはその共同住所のケアのケア（セクション2.1.1の「R」ビットの説明を参照）
o the IP Destination Address (as specified in Section 3.6.1.1)
o IP宛先アドレス（セクション3.6.1.1で指定）
o the UDP Source Port
o UDPソースポート
o the home agent address
o ホームエージェントアドレス
o the Identification field
o 識別フィールド
o the requested registration Lifetime, and
o 要求された登録寿命、および
o the remaining Lifetime of the pending or current registration
o 保留中または現在の登録の残りの寿命
If there is an NAI extension in the Registration Request message (often, for example, when the mobile node's Home Address is zero), then the foreign agent MUST follow the procedures specified in RFC 2794 [2]. In particular, if the foreign agent cannot manage pending Registration Request records with such a zero Home Address for the mobile node, the foreign agent MUST return a Registration Reply with a code indicating NONZERO_HOMEADDR_REQD (see [2]).
登録要求メッセージにNAI拡張機能がある場合（たとえば、モバイルノードのホームアドレスがゼロの場合）、外国人エージェントはRFC 2794で指定された手順に従う必要があります[2]。特に、外国人エージェントがモバイルノードのこのようなゼロホームアドレスを持つ登録要求レコードを保留中の登録要求レコードを管理できない場合、外国人エージェントは、nonzero_homeaddr_reqdを示すコードで登録返信を返す必要があります（[2]を参照）。
The foreign agent MAY configure a maximum number of pending registrations that it is willing to maintain (typically 5). Additional registrations SHOULD then be rejected by the foreign agent with Code 66. The foreign agent MAY delete any pending Registration Request after the request has been pending for more than 7 seconds; in this case, the foreign agent SHOULD reject the Request with Code 78 (registration timeout).
外国人エージェントは、維持する意思のある保留中の登録の最大数を構成する場合があります（通常5）。その後、追加の登録は、コード66の外国人エージェントによって拒否される必要があります。外国人エージェントは、リクエストが7秒以上保留中に保留中の登録要求を削除することができます。この場合、外国人エージェントはコード78（登録タイムアウト）でリクエストを拒否する必要があります。
As with any node on the Internet, a foreign agent MAY also share Mobility Security Associations with any other nodes. When relaying a Registration Request from a mobile node to its home agent, if the foreign agent shares a Mobility Security Association with the home agent, it MUST add a Foreign-Home Authentication Extension to the Request. In this case, when the Registration Reply has nonzero Lifetime, the foreign agent MUST check the required Foreign-Home Authentication Extension in the Registration Reply from the home agent (Sections 3.3 and 3.4). Similarly, when receiving a Registration Request from a mobile node, if the foreign agent shares a Mobility Security Association with the mobile node, it MUST check the required Mobile-Foreign Authentication Extension in the Request and MUST add a Mobile-Foreign Authentication Extension to the Registration Reply to the mobile node.
インターネット上の任意のノードと同様に、外国人エージェントは、他のノードとモビリティセキュリティ関連を共有する場合があります。モバイルノードからホームエージェントに登録要求を中継する場合、外国人エージェントがホームエージェントとモビリティセキュリティ協会を共有する場合、リクエストに外国在宅認証拡張機能を追加する必要があります。この場合、登録返信の寿命以外の場合、外国人エージェントは、ホームエージェントからの登録返信で必要な外国家認証拡張機能を確認する必要があります（セクション3.3および3.4）。同様に、モバイルノードから登録要求を受信する場合、外国人エージェントがモバイルノードとモビリティセキュリティ関連を共有する場合、リクエストで必要なモバイル外定認証拡張機能を確認する必要があり、モバイル外定認証拡張機能を追加する必要があります。登録モバイルノードへの返信。
If the foreign agent accepts a Registration Request from a mobile node, it checks to make sure that the indicated home agent address does not belong to any network interface of the foreign agent. If not, the foreign agent then MUST relay the Request to the indicated home agent. Otherwise, if the foreign agent denies the Request, it MUST send a Registration Reply to the mobile node with an appropriate denial code, except in cases where the foreign agent would be required to send out more than one such denial per second to the same mobile node. The following sections describe this behavior in more detail.
外国人エージェントがモバイルノードからの登録要求を受け入れる場合、指定されたホームエージェントアドレスが外国人エージェントのネットワークインターフェイスに属していないことを確認するためにチェックします。そうでない場合、外国人エージェントは、指定されたホームエージェントにリクエストを中継する必要があります。それ以外の場合、外国人エージェントがリクエストを拒否した場合、外国人エージェントが同じモバイルにそのような拒否を複数送信する必要がある場合を除き、適切な拒否コードでモバイルノードへの登録返信を送信する必要がありますノード。次のセクションでは、この動作をより詳細に説明します。
If the foreign agent has configured one of its network interfaces with the IP address specified by the mobile node as its home agent address, the foreign agent MUST NOT forward the Request again. If the foreign agent serves the mobile node as a home agent, the foreign agent follows the procedures specified in Section 3.8.2. Otherwise, if the foreign agent does not serve the mobile node as a home agent, the foreign agent rejects the Registration Request with Code 194 (Invalid Home Agent Address).
外国人エージェントが、モバイルノードによって指定されたIPアドレスとホームエージェントアドレスとしてネットワークインターフェイスの1つを構成した場合、外国人エージェントは再びリクエストを転送してはなりません。外国人エージェントがモバイルノードをホームエージェントとして提供する場合、外国人エージェントはセクション3.8.2で指定された手順に従います。それ以外の場合、外国人エージェントがモバイルノードをホームエージェントとして提供していない場合、外国人エージェントはコード194（無効なホームエージェントアドレス）で登録要求を拒否します。
If a foreign agent receives a Registration Request from a mobile node in its visitor list, the existing visitor list entry for the mobile node SHOULD NOT be deleted or modified until the foreign agent receives a valid Registration Reply from the home agent with a code indicating success. The foreign agent MUST record the new pending Request as a separate part of the existing visitor list entry for the mobile node. If the Registration Request asks for deregistration, the existing visitor list entry for the mobile node SHOULD NOT be deleted until the foreign agent has received a successful Registration Reply. If the Registration Reply indicates that the Request (for registration or deregistration) was denied by the home agent, the existing visitor list entry for the mobile node MUST NOT be modified as a result of receiving the Registration Reply.
外国人エージェントが訪問者リストのモバイルノードから登録リクエストを受信した場合、モバイルノードの既存の訪問者リストエントリは、外国人エージェントがコードを持つホームエージェントから有効な登録返信を受信するまで削除または変更してはなりません。。外国人エージェントは、モバイルノードの既存の訪問者リストエントリの別の部分として、新しい保留リクエストを記録する必要があります。登録リクエストが規制緩和を要求した場合、外国人エージェントが登録返信を成功させるまで、モバイルノードの既存の訪問者リストエントリを削除する必要はありません。登録返信が、リクエスト（登録または登録のため）がホームエージェントによって拒否されたことを示している場合、登録返信の結果としてモバイルノードの既存の訪問者リストエントリを変更してはなりません。
Registration Requests with an invalid, non-zero UDP checksum MUST be silently discarded. Requests with non-zero bits in reserved fields MUST be rejected with Code 70 (poorly formed Request). Requests with the 'D' bit set to 0, nonzero Lifetime, and specifying a care-of address not offered by the foreign agent, MUST be rejected with Code 77 (invalid care-of address).
無効でゼロ以外のUDPチェックサムを備えた登録要求は、静かに廃棄する必要があります。予約済みのフィールドにゼロ以外のビットを持つリクエストは、コード70（形成されていないリクエスト）で拒否する必要があります。「D」ビットが0に設定され、ゼロ以外の寿命があり、外国人エージェントが提供していないアドレスの指定を使用したリクエストは、コード77（無効なケアオブアドレス）で拒否する必要があります。
Also, the authentication in the Registration Request MUST be checked. If the foreign agent and the mobile node share a Mobility Security Association, exactly one Mobile-Foreign Authentication Extension MUST be present in the Registration Request, and the foreign agent MUST check the Authenticator value in the Extension. If no Mobile-Foreign Authentication Extension is found, or if more than one Mobile-Foreign Authentication Extension is found, or if the Authenticator is invalid, the foreign agent MUST silently discard the Request and SHOULD log the event as a security exception. The foreign agent also SHOULD send a Registration Reply to the mobile node with Code 67.
また、登録要求の認証を確認する必要があります。外国人エージェントとモバイルノードがモビリティセキュリティ協会を共有する場合、登録要求に1つのモバイル外定認証拡張機能が正確に存在する必要があり、外国人エージェントは拡張機能の認証因子値を確認する必要があります。モバイル外定認証拡張機能が見つからない場合、または複数のモバイル外定認証拡張機能が見つかった場合、または認証器が無効である場合、外国人エージェントはリクエストを静かに破棄し、セキュリティ例外としてイベントを記録する必要があります。また、外国人エージェントは、コード67を使用してモバイルノードに登録返信を送信する必要があります。
If the foreign agent accepts the mobile node's Registration Request, it MUST relay the Request to the mobile node's home agent as specified in the Home Agent field of the Registration Request. The foreign agent MUST NOT modify any of the fields beginning with the fixed portion of the Registration Request up through and including the Mobile-Home Authentication Extension or other authentication extension supplied by the mobile node as an authorization-enabling extension for the home agent. Otherwise, an authentication failure is very likely to occur at the home agent. In addition, the foreign agent proceeds as follows:
外国人エージェントがモバイルノードの登録要求を受け入れる場合、登録要求のホームエージェントフィールドで指定されているように、モバイルノードのホームエージェントにリクエストを中継する必要があります。外国人エージェントは、登録要求の固定部分から始まるフィールドを変更してはなりません。モバイルホーム認証拡張機能またはモバイルノードから提供されたその他の認証拡張機能をホームエージェントの許可を有する拡張機能として変更する必要はありません。そうしないと、認証障害がホームエージェントで発生する可能性が非常に高いです。さらに、外国のエージェントは次のように進行します。
o It MUST process and remove any extensions that do not precede any authorization-enabling extension,
o 許可を有する拡張機能に先行しない拡張機能を処理および削除する必要があります。
o It MAY append any of its own non-authentication Extensions of relevance to the home agent, if applicable, and
o 該当する場合は、ホームエージェントに関連する独自の非認証拡張のいずれかを追加し、
o If the foreign agent shares a Mobility Security Association with the home agent, and the Request has Lifetime != 0, then it MUST append the Foreign-Home Authentication Extension.
o 外国人エージェントがホームエージェントとモビリティセキュリティ協会を共有し、リクエストに寿命！= 0の場合、外国在宅認証拡張機能を追加する必要があります。
Specific fields within the IP header and the UDP header of the relayed Registration Request MUST be set as follows:
IPヘッダー内の特定のフィールドとリレー登録リクエストのUDPヘッダーは、次のように設定する必要があります。
IP Source Address
IPソースアドレス
The care-of address offered by the foreign agent for the mobile node sending the Registration Request.
登録要求を送信するモバイルノードの外国人エージェントが提供する住所の世話。
IP Destination Address
IP宛先アドレス
Copied from the Home Agent field within the Registration Request.
登録リクエスト内のホームエージェントフィールドからコピーされました。
UDP Source Port
UDPソースポート
variable
変数
UDP Destination Port
UDP宛先ポート
434
434
After forwarding a valid Registration Request to the home agent, the foreign agent MUST begin timing the remaining lifetime of the pending registration based on the Lifetime in the Registration Request. If this lifetime expires before receiving a valid Registration Reply, the foreign agent MUST delete its visitor list entry for this pending registration.
有効な登録要求をホームエージェントに転送した後、外国人エージェントは、登録要求の生涯に基づいて、保留中の登録の残りの寿命のタイミングを開始する必要があります。有効な登録返信を受ける前にこの生涯が期限切れになった場合、外国人エージェントは、この保留中の登録のために訪問者リストエントリを削除する必要があります。
If the foreign agent denies the mobile node's Registration Request for any reason, it SHOULD send the mobile node a Registration Reply with a suitable denial code. In such a case, the Home Address, Home Agent, and Identification fields within the Registration Reply are copied from the corresponding fields of the Registration Request.
外国人エージェントが何らかの理由でモバイルノードの登録要求を拒否した場合、適切な拒否コードを使用してモバイルノードに登録返信を送信する必要があります。そのような場合、登録返信内のホームアドレス、ホームエージェント、および識別フィールドは、登録要求の対応するフィールドからコピーされます。
If the Reserved field is nonzero, the foreign agent MUST deny the Request and SHOULD return a Registration Reply with Status Code 70 to the mobile node. If the Request is being denied because the requested Lifetime is too long, the foreign agent sets the Lifetime in the Reply to the maximum Lifetime value it is willing to accept in any Registration Request, and sets the Code field to 69. Otherwise, the Lifetime SHOULD be copied from the Lifetime field in the Request.
予約済みのフィールドがゼロでない場合、外国人エージェントはリクエストを拒否し、ステータスコード70の登録返信をモバイルノードに返す必要があります。要求された寿命が長すぎるためにリクエストが拒否されている場合、外国人エージェントは、登録要求で受け入れたい最大生涯値への返信に生涯を設定し、コードフィールドを69に設定します。リクエストでは、生涯フィールドからコピーする必要があります。
Specific fields within the IP header and the UDP header of the Registration Reply MUST be set as follows:
IPヘッダー内の特定のフィールドと登録返信のUDPヘッダーは、次のように設定する必要があります。
IP Source Address
IPソースアドレス
Copied from the IP Destination Address of the Registration Request, unless the "All Agents Multicast" address was used. In this case, the foreign agent's address (on the interface from which the message will be sent) MUST be used.
「すべてのエージェントマルチキャスト」アドレスが使用されない限り、登録要求のIP宛先アドレスからコピーされました。この場合、外国人エージェントの住所（メッセージが送信されるインターフェイス上）を使用する必要があります。
IP Destination Address
IP宛先アドレス
If the Registration Reply is generated by the foreign agent in order to reject a mobile node's Registration Request, and the Registration Request contains a Home Address that is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Request. Otherwise, if the Registration Reply is received from the home agent, and contains a Home Address that is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Reply. Otherwise, the IP Destination Address of the Registration Reply is set to be 255.255.255.255.
モバイルノードの登録リクエストを拒否するために登録返信が外国人エージェントによって生成され、登録リクエストに0.0.0.0ではないホームアドレスが含まれている場合、IP宛先アドレスは登録のホームアドレスフィールドからコピーされますリクエスト。それ以外の場合、登録返信がホームエージェントから受信され、0.0.0.0ではないホームアドレスが含まれている場合、IP宛先アドレスは登録返信のホームアドレスフィールドからコピーされます。それ以外の場合、登録返信のIP宛先アドレスは255.255.255.255に設定されています。
UDP Source Port
UDPソースポート
434
434
UDP Destination Port
UDP宛先ポート
Copied from the UDP Source Port of the Registration Request.
登録要求のUDPソースポートからコピーされました。
The foreign agent updates its visitor list when it receives a valid Registration Reply from a home agent. It then relays the Registration Reply to the mobile node. The following sections describe this behavior in more detail.
外国人エージェントは、ホームエージェントから有効な登録返信を受け取ったときに訪問者リストを更新します。次に、モバイルノードへの登録返信を中継します。次のセクションでは、この動作をより詳細に説明します。
If upon relaying a Registration Request to a home agent, the foreign agent receives an ICMP error message instead of a Registration Reply, then the foreign agent SHOULD send to the mobile node a Registration Reply with an appropriate "home agent unreachable" failure code (within the range 80-95, inclusive). See Section 3.7.2.3 for details on building the Registration Reply.
ホームエージェントに登録要求を中継すると、外国人エージェントが登録返信の代わりにICMPエラーメッセージを受信する場合、外国人エージェントは、適切な「ホームエージェントのない」障害コードを持つ登録返信をモバイルノードに送信する必要があります（内範囲80〜95、包括的）。登録返信の作成の詳細については、セクション3.7.2.3を参照してください。
Registration Replies with an invalid, non-zero UDP checksum MUST be silently discarded.
登録は無効で、ゼロ以外のUDPチェックサムを静かに廃棄する必要があります。
When a foreign agent receives a Registration Reply message, it MUST search its visitor list for a pending Registration Request with the same mobile node home address as indicated in the Reply. If there are multiple entries with the same home address, and if the Registration Reply has the Mobile Node NAI extension [2], the foreign agent MUST use the NAI to disambiguate the pending Registration Requests with the same home address. If no matching pending Request is found, and if the Registration Reply does not correspond with any pending Registration Request with a zero mobile node home address (see Section 3.7.1), the foreign agent MUST silently discard the Reply. The foreign agent MUST also silently discard the Reply if the low-order 32 bits of the Identification field in the Reply do not match those in the Request.
外国人エージェントが登録返信メッセージを受信した場合、返信に示されているように、同じモバイルノードホームアドレスを使用した保留中の登録リクエストを訪問者リストを検索する必要があります。同じホームアドレスを持つ複数のエントリがあり、登録返信にモバイルノードNAI拡張機能[2]がある場合、外国人エージェントはNAIを使用して、同じホームアドレスで保留中の登録要求を描写する必要があります。一致する保留中の要求が見つからず、登録返信がゼロモバイルノードホームアドレスを備えた保留中の登録要求に対応していない場合（セクション3.7.1を参照）、外国人エージェントは回答を静かに廃棄する必要があります。また、外国人エージェントは、返信の識別フィールドの低次の32ビットがリクエストのそれらと一致しない場合、回答を静かに廃棄する必要があります。
Also, the authentication in the Registration Reply MUST be checked. If the foreign agent and the home agent share a Mobility Security Association, exactly one Foreign-Home Authentication Extension MUST be present in the Registration Reply, and the foreign agent MUST check the Authenticator value in the Extension. If no Foreign-Home Authentication Extension is found, or if more than one Foreign-Home Authentication Extension is found, or if the Authenticator is invalid, the foreign agent MUST silently discard the Reply and SHOULD log the event as a security exception. The foreign agent also MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 68.
また、登録返信の認証を確認する必要があります。外国人エージェントとホームエージェントがモビリティセキュリティ協会を共有する場合、登録返信には正確に1つの外国在宅認証拡張機能が存在する必要があり、外国人エージェントは拡張機能の認証因子値を確認する必要があります。外国の在宅認証拡張機能が見つからない場合、または複数の外国在宅認証拡張機能が見つかった場合、または認証機が無効である場合、外国人エージェントは回答を静かに破棄し、セキュリティ例外としてイベントを記録する必要があります。また、外国人エージェントはモバイルノードの登録を拒否する必要があり、コード68を使用してモバイルノードに登録返信を送信する必要があります。
A Registration Reply that satisfies the validity checks of Section 3.8.2.1 is relayed to the mobile node. The foreign agent MUST also update its visitor list entry for the mobile node to reflect the results of the Registration Request, as indicated by the Code field in the Reply. If the code indicates that the home agent has accepted the registration and the Lifetime field is nonzero, the foreign agent SHOULD set the Lifetime in the visitor list entry to the minimum of the following two values:
セクション3.8.2.1の有効性チェックを満たす登録返信は、モバイルノードに中継されます。また、外国人エージェントは、返信のコードフィールドで示されるように、登録要求の結果を反映するために、モバイルノードの訪問者リストエントリを更新する必要があります。コードがホームエージェントが登録を受け入れ、生涯フィールドがゼロであることを示している場合、外国人エージェントは訪問者リストエントリで生涯を次の2つの値の最小値に設定する必要があります。
o the value specified in the Lifetime field of the Registration Reply, and
o 登録返信の生涯フィールドで指定された値、および
o the foreign agent's own maximum value for allowable registration Lifetime.
o 許容可能な登録寿命の外国人エージェント自身の最大値。
If, instead, the code indicates that the Lifetime field is zero, the foreign agent MUST delete its visitor list entry for the mobile node. Finally, if the code indicates that the registration was denied by the home agent, the foreign agent MUST delete its pending registration list entry, but not its visitor list entry, for the mobile node.
代わりに、コードが生涯フィールドがゼロであることを示している場合、外国人エージェントはモバイルノードの訪問者リストエントリを削除する必要があります。最後に、コードがホームエージェントによって登録が拒否されたことを示した場合、外国人エージェントは、モバイルノードの訪問者リストエントリではなく、保留中の登録リストエントリを削除する必要があります。
The foreign agent MUST NOT modify any of the fields beginning with the fixed portion of the Registration Reply up through and including the Mobile-Home Authentication Extension. Otherwise, an authentication failure is very likely to occur at the mobile node. In addition, the foreign agent SHOULD perform the following additional procedures:
外国人エージェントは、登録の固定部分から始まるフィールドのいずれかを変更してはなりません。それ以外の場合、モバイルノードで認証障害が発生する可能性が非常に高いです。さらに、外国人エージェントは次の追加手順を実行する必要があります。
o It MUST process and remove any Extensions that are not covered by any authorization-enabling extension,
o 許可を有する拡張機能でカバーされていない拡張機能を処理および削除する必要があります。
o It MAY append its own non-authentication Extensions that supply information to the mobile node, if applicable, and
o 該当する場合は、モバイルノードに情報を提供する独自の非認証拡張機能を追加し、
o It MUST append the Mobile-Foreign Authentication Extension, if the foreign agent shares a Mobility Security Association with the mobile node.
o 外国人エージェントがモバイルノードとモビリティセキュリティ協会を共有している場合、モバイル外定認証拡張機能を追加する必要があります。
Specific fields within the IP header and the UDP header of the relayed Registration Reply are set according to the same rules specified in Section 3.7.2.3.
IPヘッダー内の特定のフィールドとリレー登録応答のUDPヘッダーは、セクション3.7.2.3で指定された同じルールに従って設定されます。
After forwarding a valid Registration Reply to the mobile node, the foreign agent MUST update its visitor list entry for this registration as follows. If the Registration Reply indicates that the registration was accepted by the home agent, the foreign agent resets its timer of the lifetime of the registration to the Lifetime granted in the Registration Reply; unlike the mobile node's timing of the registration lifetime as described in Section 3.6.2.2, the foreign agent considers this lifetime to begin when it forwards the Registration Reply message, ensuring that the foreign agent will not expire the registration before the mobile node does. On the other hand, if the Registration Reply indicates that the registration was rejected by the home agent, the foreign agent deletes its visitor list entry for this attempted registration.
有効な登録返信をモバイルノードに転送した後、外国人エージェントは次のようにこの登録の訪問者リストエントリを更新する必要があります。登録回答が登録がホームエージェントによって受け入れられたことを示した場合、外国人エージェントは登録の寿命のタイマーを登録返信で付与された生涯にリセットします。セクション3.6.2.2で説明されているように、モバイルノードの登録寿命のタイミングとは異なり、外国人エージェントは、この寿命が登録返信メッセージを転送するときに開始すると考え、外国人エージェントがモバイルノードの前に登録を期限切れにしないようにします。一方、登録返信が登録がホームエージェントによって拒否されたことを示した場合、外国人エージェントはこの試みの登録のために訪問者リストエントリを削除します。
Home agents play a reactive role in the registration process. The home agent receives Registration Requests from the mobile node (perhaps relayed by a foreign agent), updates its record of the mobility bindings for this mobile node, and issues a suitable Registration Reply in response to each.
ホームエージェントは、登録プロセスで反応的な役割を果たします。ホームエージェントは、モバイルノード（おそらく外国人エージェントによって中継される）から登録要求を受け取り、このモバイルノードのモビリティバインディングの記録を更新し、それぞれに応じて適切な登録返信を発行します。
A home agent MUST NOT transmit a Registration Reply except when replying to a Registration Request received from a mobile node. In particular, the home agent MUST NOT generate a Registration Reply to indicate that the Lifetime has expired.
ホームエージェントは、モバイルノードから受信した登録リクエストに返信する場合を除き、登録返信を送信してはなりません。特に、ホームエージェントは、寿命が期限切れになったことを示すために登録返信を生成してはなりません。
Each home agent MUST be configured with an IP address and with the prefix size for the home network. The home agent MUST be configured with the Mobility Security Association of each authorized mobile node that it is serving as a home agent.
各ホームエージェントは、IPアドレスとホームネットワークのプレフィックスサイズで構成する必要があります。ホームエージェントは、ホームエージェントとして機能する各認定モバイルノードのモビリティセキュリティ協会で構成する必要があります。
When the home agent accepts a valid Registration Request from a mobile node that it serves as a home agent, the home agent MUST create or modify the entry for this mobile node in its mobility binding list containing:
ホームエージェントがホームエージェントとして機能するモバイルノードからの有効な登録要求を受け入れる場合、ホームエージェントは、次のモビリティバインディングリストにこのモバイルノードのエントリを作成または変更する必要があります。
o the mobile node's home address
o モバイルノードのホームアドレス
o the mobile node's care-of address
o モバイルノードのケアアドレス
o the Identification field from the Registration Reply
o 登録返信からの識別フィールド
o the remaining Lifetime of the registration
o 登録の残りの寿命
The home agent MAY optionally offer the capability to dynamically associate a home address to a mobile node upon receiving a Registration Request from that mobile node. The method by which a home address is allocated to the mobile node is beyond the scope of this document, but see [2]. After the home agent makes the association of the home address to the mobile node, the home agent MUST put that home address into the Home Address field of the Registration Reply.
ホームエージェントは、オプションで、そのモバイルノードから登録リクエストを受信する際に、ホームアドレスをモバイルノードに動的に関連付ける機能を提供する場合があります。ホームアドレスがモバイルノードに割り当てられる方法は、このドキュメントの範囲を超えていますが、[2]を参照してください。ホームエージェントがホームアドレスとモバイルノードとの関連付けを行った後、ホームエージェントはそのホームアドレスを登録返信のホームアドレスフィールドに入れなければなりません。
The home agent MAY also maintain Mobility Security Associations with various foreign agents. When receiving a Registration Request from a foreign agent, if the home agent shares a Mobility Security Association with the foreign agent, the home agent MUST check the Authenticator in the required Foreign-Home Authentication Extension in the message, based on this Mobility Security Association, unless the Lifetime field equals 0. When processing a Registration Request with Lifetime = 0, the HA MAY skip checking for the presence and validity of a Foreign-Home Authentication Extension. Similarly, when sending a Registration Reply to a foreign agent, if the home agent shares a Mobility Security Association with the foreign agent, the home agent MUST include a Foreign-Home Authentication Extension in the message, based on this Mobility Security Association.
ホームエージェントは、さまざまな外国人エージェントとのモビリティセキュリティ協会を維持することもできます。外国人エージェントから登録要求を受け取るとき、ホームエージェントが外国人エージェントとモビリティセキュリティ協会を共有する場合、ホームエージェントは、このモビリティセキュリティ協会に基づいて、メッセージの必要な外国在宅認証拡張機能の認証者をチェックする必要があります。生涯フィールドが0に等しい場合を除き、Lifetime = 0で登録要求を処理する場合、HAは外国在宅認証拡張の存在と有効性をチェックすることができます。同様に、外国人エージェントに登録返信を送信する場合、ホームエージェントが外国人エージェントとモビリティセキュリティ協会を共有している場合、ホームエージェントは、このモビリティセキュリティ協会に基づいて、メッセージに外国在宅認証拡張機能を含める必要があります。
If the home agent accepts an incoming Registration Request, it MUST update its record of the mobile node's mobility binding(s) and SHOULD send a Registration Reply with a suitable code. Otherwise (the home agent has denied the Request), it SHOULD in most cases send a Registration Reply with an appropriate code specifying the reason the Request was denied. The following sections describe this behavior in more detail. If the home agent does not support broadcasts (see Section 4.3), it MUST ignore the 'B' bit (as opposed to rejecting the Registration Request).
ホームエージェントが着信登録要求を受け入れる場合、モバイルノードのモビリティバインディングの記録を更新する必要があり、適切なコードで登録返信を送信する必要があります。それ以外の場合は（ホームエージェントはリクエストを拒否しました）、ほとんどの場合、リクエストが拒否された理由を指定する適切なコードで登録返信を送信する必要があります。次のセクションでは、この動作をより詳細に説明します。ホームエージェントがブロードキャストをサポートしていない場合（セクション4.3を参照）、「b」ビットを無視する必要があります（登録リクエストを拒否するのではなく）。
Registration Requests with an invalid, non-zero UDP checksum MUST be silently discarded by the home agent.
無効でゼロ以外のUDPチェックサムを備えた登録要求は、ホームエージェントによって静かに廃棄する必要があります。
The authentication in the Registration Request MUST be checked. This involves the following operations:
登録要求の認証は確認する必要があります。これには、次の操作が含まれます。
a. The home agent MUST check for the presence of at least one authorization-enabling extension, and ensure that all indicated authentications are carried out. At least one authorization-enabling extension MUST be present in the Registration Request, and the home agent MUST either check the Authenticator value in the extension or verify that the Authenticator Value has been checked by another agent with which it has a security association.
a. ホームエージェントは、少なくとも1つの承認を有する拡張機能の存在を確認し、すべての指定された認証が実行されることを確認する必要があります。少なくとも1つの承認を有する拡張機能が登録リクエストに存在する必要があり、ホームエージェントは拡張機能の認証因子値を確認するか、セキュリティ協会がある別のエージェントによって認証機の値がチェックされていることを確認する必要があります。
If the home agent receives a Registration Request from a mobile node with which it does not have any security association, the home agent MUST silently discard the Registration Request.
ホームエージェントがセキュリティ協会のないモバイルノードから登録要求を受け取った場合、ホームエージェントは登録要求を静かに廃棄する必要があります。
If the home agent receives a Registration Request without any authorization-enabling extension, the home agent MUST silently discard the Registration Request.
ホームエージェントが許可を有する拡張機能なしに登録要求を受け取った場合、ホームエージェントは登録要求を静かに廃棄する必要があります。
If the Authenticator is invalid, the home agent MUST reject the mobile node's registration. Further action to be taken in this case depends upon whether the Request has a valid Foreign-Home authentication extension (as follows):
認証器が無効である場合、ホームエージェントはモバイルノードの登録を拒否する必要があります。この場合に行われるさらなる措置は、リクエストに有効な外国在宅認証拡張機能があるかどうかによって異なります（次のとおり）。
* If there is a valid Foreign-Home authentication extension, the home agent MUST send a Registration Reply with Code 131.
* 有効な外国在宅認証拡張機能がある場合、ホームエージェントはコード131に登録返信を送信する必要があります。
* Otherwise, if there is no Foreign-Home Security Association, the home agent MAY send a Registration Reply with Code 131. If the home agent sends a Registration Reply, it MUST contain a valid Mobile-Home Authentication Extension. In constructing the Reply, the home agent SHOULD choose a security association that is likely to exist in the mobile node; for example, this may be an older security association or one with a longer lifetime than the one that the mobile node attempted to use in its Request. Deployments should take care when updating security associations to ensure that there is at least one common security association shared between the mobile node and home agent. In any case of a failed Authenticator, the home agent MUST then discard the Request without further processing and SHOULD log the error as a security exception.
* それ以外の場合、外国の自宅のセキュリティ協会がない場合、ホームエージェントはコード131に登録返信を送信できます。ホームエージェントが登録返信を送信する場合、有効なモバイルホーム認証拡張機能を含める必要があります。返信を構築する際に、ホームエージェントはモバイルノードに存在する可能性が高いセキュリティ協会を選択する必要があります。たとえば、これは、モバイルノードがリクエストで使用しようとしたものよりも、古いセキュリティ協会または寿命が長い場合があります。セキュリティ協会を更新する際には、モバイルノードとホームエージェントの間に少なくとも1つの一般的なセキュリティ協会が共有されていることを確認する際には、展開が注意する必要があります。認証機に失敗した場合、ホームエージェントはさらに処理せずにリクエストを破棄し、セキュリティ例外としてエラーを記録する必要があります。
b. The home agent MUST check that the registration Identification field is correct using the context selected by the SPI within the authorization-enabling extension that the home agent used to authenticate the mobile node's Registration Request. See Section 5.7 for a description of how this is performed. If incorrect, the home agent MUST reject the Request and SHOULD send a Registration Reply to the mobile node with Code 133, including an Identification field computed in accordance with the rules specified in Section 5.7. The home agent MUST do no further processing with such a Request, though it SHOULD log the error as a security exception.
b. ホームエージェントは、モバイルノードの登録リクエストの認証に使用されていた承認を有する拡張機能内のSPIによって選択されたコンテキストを使用して、登録識別フィールドが正しいことを確認する必要があります。これがどのように実行されるかについての説明については、セクション5.7を参照してください。正しくない場合、ホームエージェントはリクエストを拒否し、セクション5.7で指定されたルールに従って計算された識別フィールドを含むコード133を使用してモバイルノードへの登録返信を送信する必要があります。ホームエージェントは、セキュリティの例外としてエラーを記録する必要がありますが、そのようなリクエストでさらに処理する必要はありません。
c. If the home agent shares a Mobility Security Association with the foreign agent, and this is a Registration Request (has non-zero Lifetime), the home agent MUST check for the presence of a valid Foreign-Home Authentication Extension. Exactly one Foreign-Home Authentication Extension MUST be present in the Registration Request in this case, and the home agent MUST check the Authenticator Value in the Extension. If no Foreign-Home Authentication Extension is found, or if more than one Foreign-Home Authentication Extension is found, or if the Authenticator is invalid, the home agent MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 132. The home agent MUST then discard the Request and SHOULD log the error as a security exception.
c. ホームエージェントが外国人エージェントとモビリティセキュリティ協会を共有し、これが登録リクエスト（ゼロ以外の生涯）である場合、ホームエージェントは有効な外国在宅認証拡張機能の存在を確認する必要があります。この場合、登録リクエストに正確に1つの外国在宅認証拡張機能が存在する必要があり、ホームエージェントは拡張機能の認証因子値を確認する必要があります。Foreign-Home認証拡張機能が見つからない場合、または複数のForeign-Home認証拡張機能が見つかった場合、または認証器が無効である場合、ホームエージェントはモバイルノードの登録を拒否し、モバイルノードへの登録返信を送信する必要があります。コード132.ホームエージェントは、リクエストを破棄し、セキュリティ例外としてエラーを記録する必要があります。
d. If the home agent and the foreign agent do not share a Mobility Security Association, and the Registration contains a Foreign-Home Authentication Extension, the home agent MUST discard the Request and SHOULD log the error as a security exception.
d. ホームエージェントと外国人エージェントがモビリティセキュリティ協会を共有しておらず、登録に外国在宅認証拡張機能が含まれている場合、ホームエージェントはリクエストを破棄し、セキュリティ例外としてエラーを記録する必要があります。
In addition to checking the authentication in the Registration Request, home agents MUST deny Registration Requests that are sent to the subnet-directed broadcast address of the home network (as opposed to being unicast to the home agent). The home agent MUST discard the Request and SHOULD return a Registration Reply with a Code of 136. In this case, the Registration Reply will contain the home agent's unicast address, so that the mobile node can re-issue the Registration Request with the correct home agent address.
登録要求の認証を確認することに加えて、ホームエージェントは、ホームネットワークのサブネット指向ブロードキャストアドレスに送信される登録リクエストを拒否する必要があります（ホームエージェントのユニキャストとは対照的に）。ホームエージェントはリクエストを廃棄する必要があり、136のコードで登録返信を返す必要があります。この場合、登録返信には、モバイルノードが正しいホームで登録要求を再発行できるように、ホームエージェントのユニキャストアドレスが含まれます。エージェントアドレス。
Note that some routers change the IP Destination Address of a datagram from a subnet-directed broadcast address to 255.255.255.255 before injecting it into the destination subnet. In this case, home agents that attempt to pick up dynamic home agent discovery requests by binding a socket explicitly to the subnet-directed broadcast address will not see such packets. Home agent implementors should be prepared for both the subnet-directed broadcast address and 255.255.255.255 if they wish to support dynamic home agent discovery.
一部のルーターは、宛先サブネットに注入する前に、サブネット指向ブロードキャストアドレスからデータグラムのIP宛先アドレスを255.255.255.255に変更することに注意してください。この場合、ソケットをサブネット指向のブロードキャストアドレスに明示的にバインドしてダイナミックホームエージェントディスカバリーリクエストをピックアップしようとするホームエージェントは、そのようなパケットが表示されません。ホームエージェントの実装者は、ダイナミックホームエージェントの発見をサポートしたい場合は、サブネット指向の放送アドレスと255.255.255.255の両方に備えてください。
If the Registration Request satisfies the validity checks in Section 3.8.2.1, and the home agent is able to accommodate the Request, the home agent MUST update its mobility binding list for the requesting mobile node and MUST return a Registration Reply to the mobile node. In this case, the code in the Registration Reply will be either 0 if the home agent supports simultaneous mobility bindings, or 1 if it does not. See Section 3.8.3 for details on building the Registration Reply message.
登録要求がセクション3.8.2.1の有効性チェックを満たし、ホームエージェントがリクエストに対応できる場合、ホームエージェントはリクエストモバイルノードのモビリティバインディングリストを更新する必要があり、モバイルノードへの登録返信を返す必要があります。この場合、登録返信のコードは、ホームエージェントが同時モビリティバインディングをサポートする場合は0、またはそうでない場合は1になります。登録返信メッセージの作成の詳細については、セクション3.8.3を参照してください。
The home agent updates its record of the mobile node's mobility bindings as follows, based on the fields in the Registration Request: o If the Lifetime is zero and the Care-of Address equals the mobile node's home address, the home agent deletes all of the entries in the mobility binding list for the requesting mobile node. This is how a mobile node requests that its home agent cease providing mobility services.
ホームエージェントは、登録リクエストのフィールドに基づいて、次のようにモバイルノードのモビリティバインディングの記録を更新します。O寿命がゼロであり、モバイルノードのホームアドレスに等しい場合、ホームエージェントはすべてのすべてを削除します要求するモバイルノードのモビリティバインディングリストのエントリ。これは、モバイルノードがホームエージェントがモビリティサービスを提供するのをやめることを要求する方法です。
o If the Lifetime is zero and the Care-of Address does not equal the mobile node's home address, the home agent deletes only the entry containing the specified Care-of Address from the mobility binding list for the requesting mobile node. Any other active entries containing other care-of addresses will remain active.
o 寿命がゼロであり、住所がモバイルノードのホームアドレスに等しくない場合、ホームエージェントは、要求するモバイルノードのモビリティバインディングリストから指定されたケアオブアドレスを含むエントリのみを削除します。他のケアを含む他のアクティブなエントリは、アクティブのままです。
o If the Lifetime is nonzero, the home agent adds an entry containing the requested Care-of Address to the mobility binding list for the mobile node. If the 'S' bit is set and the home agent supports simultaneous mobility bindings, the previous mobility binding entries are retained. Otherwise, the home agent removes all previous entries in the mobility binding list for the mobile node.
o 寿命がゼロでない場合、ホームエージェントは、モバイルノードのモビリティバインディングリストに要求されたケアのケアを含むエントリを追加します。「S」ビットが設定され、ホームエージェントが同時モビリティバインディングをサポートすると、以前のモビリティバインディングエントリが保持されます。それ以外の場合、ホームエージェントは、モバイルノードのモビリティバインディングリストのすべての以前のエントリを削除します。
In all cases, the home agent MUST send a Registration Reply to the source of the Registration Request, which might indeed be a different foreign agent than that whose care-of address is being (de)registered. If the home agent shares a Mobility Security Association with the foreign agent whose care-of address is being deregistered, and that foreign agent is different from the one that relayed the Registration Request, the home agent MAY additionally send a Registration Reply to the foreign agent whose care-of address is being deregistered. The home agent MUST NOT send such a Reply if it does not share a Mobility Security Association with the foreign agent. If no Reply is sent, the foreign agent's visitor list will expire naturally when the original Lifetime expires.
すべての場合において、ホームエージェントは登録リクエストのソースに登録返信を送信する必要があります。これは、実際には、住所が登録されている（DE）登録されているものとは異なる外国のエージェントである可能性があります。ホームエージェントが住所のケアが登録されている外国人エージェントとモビリティセキュリティ協会を共有し、外国人が登録要求を中継したエージェントとは異なる場合、ホームエージェントはさらに外国人エージェントに登録返信を送信することができますその住所の世話は登録されています。ホームエージェントは、外国人エージェントとモビリティセキュリティ協会を共有しない場合、そのような返信を送信してはなりません。返信が送信されない場合、元の生涯が期限切れになると、外国人エージェントの訪問者リストが自然に期限切れになります。
When a foreign agent relays a deregistration message containing a care-of address that it does not own, it MUST NOT add a Foreign-Home Authentication Extension to that deregistration. See Section 3.5.4 for more details.
外国のエージェントが所有していない住所を含む登録メッセージを中継する場合、その廃止に外国の在宅認証拡張機能を追加してはなりません。詳細については、セクション3.5.4を参照してください。
The home agent MUST NOT increase the Lifetime above that specified by the mobile node in the Registration Request. However, it is not an error for the mobile node to request a Lifetime longer than the home agent is willing to accept. In this case, the home agent simply reduces the Lifetime to a permissible value and returns this value in the Registration Reply. The Lifetime value in the Registration Reply informs the mobile node of the granted Lifetime of the registration, indicating when it SHOULD re-register in order to maintain continued service. After the expiration of this registration Lifetime, the home agent MUST delete its entry for this registration in its mobility binding list.
ホームエージェントは、登録リクエストでモバイルノードによって指定された寿命を上回ってはなりません。ただし、モバイルノードがホームエージェントが受け入れる意思があるよりも長い時間を要求することはエラーではありません。この場合、ホームエージェントは単に寿命を許容値に短縮し、登録返信でこの値を返します。登録返信の生涯値は、登録の付与された生涯のモバイルノードに通知され、継続的なサービスを維持するためにいつ再登録すべきかを示します。この登録寿命の有効期限が切れた後、ホームエージェントはこの登録のエントリをモビリティバインディングリストに削除する必要があります。
If the Registration Request duplicates an accepted current Registration Request, the new Lifetime MUST NOT extend beyond the Lifetime originally granted. A Registration Request is a duplicate if the home address, care-of address, and Identification fields all equal those of an accepted current registration.
登録要求が受け入れられている現在の登録要求を複製している場合、新しい生涯は、当初付与された生涯を超えて拡張してはなりません。登録要求は、自宅の住所、ケアオブアドレス、および識別フィールドがすべて受け入れられている現在の登録のフィールドに等しい場合に複製されます。
In addition, if the home network implements ARP [16], and the Registration Request asks the home agent to create a mobility binding for a mobile node that previously had no binding (the mobile node was previously assumed to be at home), then the home agent MUST follow the procedures described in Section 4.6 with regard to ARP, proxy ARP, and gratuitous ARP. If the mobile node already had a previous mobility binding, the home agent MUST continue to follow the rules for proxy ARP described in Section 4.6.
さらに、ホームネットワークがARP [16]を実装し、登録リクエストがホームエージェントに、以前はバインディングがなかったモバイルノードのモビリティバインディングを作成するよう求めた場合（モバイルノードは以前は自宅にあると想定されていました）、ホームエージェントは、ARP、プロキシARP、および無償のARPに関して、セクション4.6で説明されている手順に従う必要があります。モバイルノードに以前のモビリティバインディングが既にある場合、ホームエージェントはセクション4.6で説明されているプロキシARPのルールに従って続けなければなりません。
If the Registration Request does not satisfy all of the validity checks in Section 3.8.2.1, or the home agent is unable to accommodate the Request, the home agent SHOULD return a Registration Reply to the mobile node with a Code that indicates the reason for the error. If a foreign agent was involved in relaying the Request, this allows the foreign agent to delete its pending visitor list entry. Also, this informs the mobile node of the reason for the error such that it may attempt to fix the error and issue another Request.
登録要求がセクション3.8.2.1のすべての有効性チェックを満たさない場合、またはホームエージェントがリクエストに対応できない場合、ホームエージェントは、エラー。外国人エージェントがリクエストの中継に関与していた場合、これにより、外国人エージェントが保留中の訪問者リストエントリを削除することができます。また、これにより、エラーを修正して別の要求を発行しようとするために、エラーの理由をモバイルノードに通知します。
This section lists a number of reasons the home agent might reject a Request, and provides the code value it should use in each instance. See Section 3.8.3 for additional details on building the Registration Reply message.
このセクションには、ホームエージェントがリクエストを拒否する可能性のあるいくつかの理由をリストし、各インスタンスで使用するコード値を提供します。登録返信メッセージの作成に関する詳細については、セクション3.8.3を参照してください。
Many reasons for rejecting a registration are administrative in nature. For example, a home agent can limit the number of simultaneous registrations for a mobile node, by rejecting any registrations that would cause its limit to be exceeded, and returning a Registration Reply with a Code of 135. Similarly, a home agent may refuse to grant service to mobile nodes that have entered unauthorized service areas by returning a Registration Reply with a Code of 129.
登録を拒否する多くの理由は、本質的に管理的です。たとえば、ホームエージェントは、制限を超える登録を拒否し、135のコードで登録返信を返すことにより、モバイルノードの同時登録の数を制限できます。同様に、ホームエージェントは129のコードで登録返信を返すことにより、不正なサービスエリアに入ったモバイルノードにサービスを提供します。
Requests with non-zero bits in reserved fields MUST be rejected with Code 134 (poorly formed Request).
予約済みフィールドにゼロ以外のビットを持つリクエストは、コード134（形成されていない要求）で拒否する必要があります。
If the home agent accepts a Registration Request, it then MUST update its record of the mobile node's mobility binding(s) and SHOULD send a Registration Reply with a suitable Code. Otherwise (the home agent has denied the Request), it SHOULD in most cases send a Registration Reply with an appropriate Code specifying the reason the Request was denied. The following sections provide additional detail for the values the home agent MUST supply in the fields of Registration Reply messages.
ホームエージェントが登録要求を受け入れる場合、モバイルノードのモビリティバインディングの記録を更新し、適切なコードで登録返信を送信する必要があります。それ以外の場合は（ホームエージェントはリクエストを拒否しました）、ほとんどの場合、リクエストが拒否された理由を指定する適切なコードで登録返信を送信する必要があります。次のセクションでは、ホームエージェントが登録応答メッセージの分野で提供する必要がある値の追加の詳細を提供します。
This section provides the specific rules by which home agents pick values for the IP and UDP header fields of a Registration Reply.
このセクションでは、ホームエージェントが登録返信のIPおよびUDPヘッダーフィールドの値を選択する特定のルールを提供します。
IP Source Address
IPソースアドレス
Copied from the IP Destination Address of the Registration Request, unless a multicast or broadcast address was used. If the IP Destination Address of the Registration Request was a broadcast or multicast address, the IP Source Address of the Registration Reply MUST be set to the home agent's (unicast) IP address.
マルチキャストまたはブロードキャストアドレスが使用されていない限り、登録要求のIP宛先アドレスからコピーされました。登録要求のIP宛先アドレスがブロードキャストまたはマルチキャストアドレスである場合、登録返信のIPソースアドレスをホームエージェント（ユニキャスト）IPアドレスに設定する必要があります。
IP Destination Address
IP宛先アドレス
Copied from the IP Source Address of the Registration Request.
登録要求のIPソースアドレスからコピーされました。
UDP Source Port
UDPソースポート
Copied from the UDP Destination Port of the Registration Request.
登録要求のUDP宛先ポートからコピーされました。
UDP Destination Port
UDP宛先ポート
Copied from the UDP Source Port of the Registration Request.
登録要求のUDPソースポートからコピーされました。
When sending a Registration Reply in response to a Registration Request that requested deregistration of the mobile node (the Lifetime is zero and the Care-of Address equals the mobile node's home address) and in which the IP Source Address was also set to the mobile node's home address (this is the normal method used by a mobile node to deregister when it returns to its home network), the IP Destination Address in the Registration Reply will be set to the mobile node's home address, as copied from the IP Source Address of the Request.
登録返信を送信して、モバイルノードの控除を要求する登録要求（寿命はゼロであり、モバイルノードのホームアドレスに等しい）とIPソースアドレスもモバイルノードに設定されたものであるホームアドレス（これは、モバイルノードがホームネットワークに戻すときに登録するために使用される通常の方法です）、登録返信のIP宛先アドレスは、モバイルノードのホームアドレスに設定されます。リクエスト。
In this case, when transmitting the Registration Reply, the home agent MUST transmit the Reply directly onto the home network as if the mobile node were at home, bypassing any mobility binding list entry that may still exist at the home agent for the destination mobile node. In particular, for a mobile node returning home after being registered with a care-of address, if the mobile node's new Registration Request is not accepted by the home agent, the mobility binding list entry for the mobile node will still indicate that datagrams addressed to the mobile node should be tunneled to the mobile node's registered care-of address; when sending the Registration Reply indicating the rejection of this Request, this existing binding list entry MUST be ignored, and the home agent MUST transmit this Reply as if the mobile node were at home.
この場合、登録返信を送信する場合、ホームエージェントはモバイルノードが自宅にあるかのようにホームネットワークに直接返信を送信する必要があります。。特に、モバイルノードが住所に登録された後に家に戻る場合、モバイルノードの新しい登録要求がホームエージェントによって受け入れられない場合、モバイルノードのモビリティバインディングリストエントリは、モバイルノードは、モバイルノードの登録されたケアオブアドレスにトンネリングする必要があります。このリクエストの拒否を示す登録返信を送信する場合、この既存のバインディングリストエントリは無視する必要があり、ホームエージェントはモバイルノードが自宅にあるかのようにこの返信を送信する必要があります。
This section provides the specific rules by which home agents pick values for the fields within the fixed portion of a Registration Reply.
このセクションでは、ホームエージェントが登録返信の固定部分内のフィールドの値を選択する特定のルールを提供します。
The Code field of the Registration Reply is chosen in accordance with the rules specified in the previous sections. When replying to an accepted registration, a home agent SHOULD respond with Code 1 if it does not support simultaneous registrations.
登録返信のコードフィールドは、前のセクションで指定されたルールに従って選択されます。受け入れられた登録に返信する場合、ホームエージェントが同時登録をサポートしていない場合は、コード1で応答する必要があります。
The Lifetime field MUST be copied from the corresponding field in the Registration Request, unless the requested value is greater than the maximum length of time the home agent is willing to provide the requested service. In such a case, the Lifetime MUST be set to the length of time that service will actually be provided by the home agent. This reduced Lifetime SHOULD be the maximum Lifetime allowed by the home agent (for this mobile node and care-of address).
要求された値がホームエージェントが要求されたサービスを喜んで提供することをいとわない時間よりも大きい場合を除き、登録要求の対応するフィールドから生涯フィールドをコピーする必要があります。そのような場合、生涯は、サービスが実際にホームエージェントによって提供される時間の長さに設定する必要があります。この減少した寿命は、ホームエージェント（このモバイルノードとケアオブアドレス用）によって許可される最大寿命である必要があります。
If the Home Address field of the Registration Request is non-zero, it MUST be copied into the Home Address field of the Registration Reply message. If the home agent cannot support the specified nonzero unicast address in the Home Address field of the Registration Request, then the home agent MUST reject the Registration Request with a Code of 129.
登録要求のホームアドレスフィールドがゼロでない場合、登録返信メッセージのホームアドレスフィールドにコピーする必要があります。ホームエージェントが登録要求のホームアドレスフィールドに指定された非ゼロユニキャストアドレスをサポートできない場合、ホームエージェントは129のコードで登録要求を拒否する必要があります。
Otherwise, if the Home Address field of the Registration Request is zero as specified in Section 3.6, the home agent SHOULD arrange for the selection of a home address for the mobile node, and insert the selected address into the Home Address field of the Registration Reply message. See [2] for further relevant details in the case where mobile nodes identify themselves using an NAI instead of their IP home address.
それ以外の場合は、セクション3.6で指定されているように登録要求のホームアドレスフィールドがゼロの場合、ホームエージェントはモバイルノードのホームアドレスの選択を手配し、登録返信のホームアドレスフィールドに選択したアドレスを挿入する必要がありますメッセージ。[2]を参照して、モバイルノードがIPホームアドレスの代わりにNAIを使用して自分自身を識別する場合の詳細については、参照してください。
If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, the home agent MUST reject the registration with a suitable code (e.g., Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more home agents.
登録要求のホームエージェントフィールドにこのホームエージェントのユニキャストアドレスが含まれている場合、そのフィールドは登録返信のホームエージェントフィールドにコピーする必要があります。それ以外の場合、ホームエージェントは、ユニキャストアドレスへの登録返信にホームエージェントフィールドを設定する必要があります。この後者の場合、ホームエージェントは、モバイルノードが2人以上のホームエージェントと同時に登録されないように、適切なコード（コード136など）で登録を拒否する必要があります。
This section describes the ordering of any required and any optional Mobile IP Extensions that a home agent appends to a Registration Reply. The following ordering MUST be followed:
このセクションでは、ホームエージェントが登録返信に追加した必要なモバイルIP拡張機能とオプションのモバイルIP拡張機能の注文について説明します。次の注文に従う必要があります。
a. The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Reply,
a. IPヘッダー、続いてUDPヘッダーが続き、その後に登録応答の固定長い部分が続きます。
b. If present, any non-authentication Extensions used by the mobile node (which may or may not also be used by the foreign agent),
b. 存在する場合、モバイルノードで使用される非認証拡張機能（外国人エージェントが使用する場合と使用する場合もあります）、
c. The Mobile-Home Authentication Extension,
c. モバイルホーム認証拡張機能、
d. If present, any non-authentication Extensions used only by the foreign agent, and
d. 存在する場合、外国人エージェントのみが使用する非認証拡張機能、および
e. The Foreign-Home Authentication Extension, if present.
e. 存在する場合、外国在宅認証拡張機能。
Note that items (a) and (c) MUST appear in every Registration Reply sent by the home agent. Items (b), (d), and (e) are optional. However, item (e) MUST be included when the home agent and the foreign agent share a Mobility Security Association.
項目（a）および（c）は、ホームエージェントから送信されたすべての登録返信に表示される必要があることに注意してください。項目（b）、（d）、および（e）はオプションです。ただし、ホームエージェントと外国人エージェントがモビリティセキュリティ協会を共有している場合、アイテム（E）を含める必要があります。
This section describes how mobile nodes, home agents, and (possibly) foreign agents cooperate to route datagrams to/from mobile nodes that are connected to a foreign network. The mobile node informs its home agent of its current location using the registration procedure described in Section 3. See the protocol overview in Section 1.7 for the relative locations of the mobile node's home address with respect to its home agent, and the mobile node itself with respect to any foreign agent with which it might attempt to register.
このセクションでは、モバイルノード、ホームエージェント、および（おそらく）外国人エージェントが、外国ネットワークに接続されているモバイルノードにデータグラムをルーティングする方法について説明します。モバイルノードは、セクション3で説明した登録手順を使用して、現在の場所をホームエージェントに通知します。モバイルノードのホームアドレスの相対的な場所については、セクション1.7のプロトコルの概要を参照してください。登録しようとするかもしれない外国人エージェントを尊重します。
Home agents and foreign agents MUST support tunneling datagrams using IP in IP encapsulation [14]. Any mobile node that uses a co-located care-of address MUST support receiving datagrams tunneled using IP in IP encapsulation. Minimal encapsulation [15] and GRE encapsulation [13] are alternate encapsulation methods that MAY optionally be supported by mobility agents and mobile nodes. The use of these alternative forms of encapsulation, when requested by the mobile node, is otherwise at the discretion of the home agent.
ホームエージェントと外国人エージェントは、IPカプセル化のIPを使用してTunnelingデータグラムをサポートする必要があります[14]。コロアのCare of Addressを使用するモバイルノードは、IPカプセル化のIPを使用してトンネル化されたデータグラムの受信をサポートする必要があります。最小限のカプセル化[15]およびGREカプセル化[13]は、オプションでモビリティエージェントとモバイルノードによってサポートされる可能性のある代替カプセル化方法です。モバイルノードから要求された場合、これらの代替形式のカプセル化の使用は、それ以外の場合はホームエージェントの裁量にあります。
When connected to its home network, a mobile node operates without the support of mobility services. That is, it operates in the same way as any other (fixed) host or router. The method by which a mobile node selects a default router when connected to its home network, or when away from home and using a co-located care-of address, is outside the scope of this document. ICMP Router Advertisement [5] is one such method.
ホームネットワークに接続すると、モバイルノードはモビリティサービスのサポートなしで動作します。つまり、他の（固定）ホストまたはルーターと同じ方法で動作します。モバイルノードがホームネットワークに接続したとき、または自宅から離れて共同配置されたアドレスを使用するときにデフォルトのルーターを選択する方法は、このドキュメントの範囲外です。ICMPルーター広告[5]は、そのような方法の1つです。
When registered on a foreign network, the mobile node chooses a default router by the following rules:
外部ネットワークに登録されると、モバイルノードは次のルールでデフォルトのルーターを選択します。
o If the mobile node is registered using a foreign agent care-of address, it MAY use its foreign agent as a first-hop router. The foreign agent's MAC address can be learned from the foreign agent's Agent Advertisement message. Otherwise, the mobile node MUST choose its default router from among the router addresses advertised in the ICMP Router Advertisement portion of that Agent Advertisement message.
o モバイルノードが外国人エージェントのケアオブアドレスを使用して登録されている場合、外国人エージェントを最初のホップルーターとして使用する場合があります。外国のエージェントのMACアドレスは、外国のエージェントのエージェント広告メッセージから学ぶことができます。それ以外の場合、モバイルノードは、そのエージェント広告メッセージのICMPルーター広告部分に宣伝されているルーターアドレスの中からデフォルトのルーターを選択する必要があります。
o If the mobile node is registered directly with its home agent using a co-located care-of address, then the mobile node SHOULD choose its default router from among those advertised in any ICMP Router Advertisement message that it receives for which its externally obtained care-of address and the router address match under the network prefix. If the mobile node's externally obtained care-of address matches the IP source address of the Agent Advertisement under the network prefix, the mobile node MAY also consider that IP source address as another possible choice for the IP address of a default router. The network prefix MAY be obtained from the Prefix-Lengths Extension in the Router Advertisement, if present. The prefix MAY also be obtained through other mechanisms beyond the scope of this document.
o モバイルノードが共同配置されたアドレスを使用してホームエージェントに直接登録されている場合、モバイルノードは、外部から取得したケアを受信するICMPルーター広告メッセージで宣伝されているものからデフォルトのルーターを選択する必要があります - ネットワークプレフィックスの下でのアドレスとルーターアドレスの一致。モバイルノードの外部から得られたケアオブアドレスが、ネットワークプレフィックスの下でエージェント広告のIPソースアドレスと一致する場合、モバイルノードは、そのIPソースアドレスをデフォルトルーターのIPアドレスの別の可能な選択肢と見なすこともできます。ネットワークプレフィックスは、存在する場合、ルーター広告のプレフィックス長拡張から取得できます。プレフィックスは、このドキュメントの範囲を超えて他のメカニズムを介して取得することもできます。
While they are away from the home network, mobile nodes MUST NOT broadcast ARP packets to find the MAC address of another Internet node. Thus, the (possibly empty) list of router addresses from the ICMP Router Advertisement portion of the message is not useful for selecting a default router, unless the mobile node has some means not involving broadcast ARP and not specified within this document for obtaining the MAC address of one of the routers in the list. Similarly, in the absence of unspecified mechanisms for obtaining MAC addresses on foreign networks, the mobile node MUST ignore redirects to other routers on foreign networks.
ホームネットワークから離れている間、モバイルノードはARPパケットをブロードキャストして、別のインターネットノードのMACアドレスを見つけるべきではありません。したがって、メッセージのICMPルーター広告部分からのルーターアドレスの（おそらく空の）リストは、モバイルノードにブロードキャストARPが含まれておらず、MACを取得するためにこのドキュメント内で指定されていない何らかの手段がない限り、デフォルトのルーターを選択するのに役立ちません。リスト内のルーターの1つのアドレス。同様に、外国ネットワークでMACアドレスを取得するための不特定のメカニズムがない場合、モバイルノードは外国ネットワーク上の他のルーターへのリダイレクトを無視する必要があります。
Upon receipt of an encapsulated datagram sent to its advertised care-of address, a foreign agent MUST compare the inner Destination Address to those entries in its visitor list. When the Destination does not match the address of any mobile node currently in the visitor list, the foreign agent MUST NOT forward the datagram without modifications to the original IP header, because otherwise a routing loop is likely to result. The datagram SHOULD be silently discarded. ICMP Destination Unreachable MUST NOT be sent when a foreign agent is unable to forward an incoming tunneled datagram. Otherwise, the foreign agent forwards the decapsulated datagram to the mobile node.
広告された住所に送信されたカプセル化されたデータグラムを受信すると、外国人エージェントは、訪問者リストの内側の宛先アドレスをそれらのエントリと比較する必要があります。宛先が現在訪問者リストにあるモバイルノードのアドレスと一致しない場合、外国人エージェントは、ルーティングループが生じる可能性が高いため、元のIPヘッダーに変更なしでデータグラムを転送してはなりません。データグラムは静かに破棄する必要があります。外国人エージェントが着信トンネリングデータグラムを転送できない場合、ICMPの宛先が送信できないでください。それ以外の場合、外国人エージェントは、脱カプセル化データグラムをモバイルノードに転送します。
The foreign agent MUST NOT advertise to other routers in its routing domain, nor to any other mobile node, the presence of a mobile router (Section 4.5) or mobile node in its visitor list.
外国人エージェントは、ルーティングドメインの他のルーター、他のモバイルノード、モバイルルーター（セクション4.5）の存在、または訪問者リストにモバイルノードの存在に宣伝してはなりません。
The foreign agent MUST route datagrams it receives from registered mobile nodes. At a minimum, this means that the foreign agent must verify the IP Header Checksum, decrement the IP Time To Live, recompute the IP Header Checksum, and forward such datagrams to a default router.
外国のエージェントは、登録されたモバイルノードから受信するデータグラムをルーティングする必要があります。少なくとも、これは、外国人エージェントがIPヘッダーチェックサムを検証し、IP時間を延長してライブの時間を減らし、IPヘッダーチェックサムを再計算し、そのようなデータグラムをデフォルトのルーターに転送する必要があることを意味します。
A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC address on a foreign network. It may obtain the MAC address by copying the information from an Agent Solicitation or a Registration Request transmitted from a mobile node. A foreign agent's ARP cache for the mobile node's IP address MUST NOT be allowed to expire before the mobile node's visitor list entry expires, unless the foreign agent has some way other than broadcast ARP to refresh its MAC address associated with the mobile node's IP address.
外国のエージェントは、外国ネットワーク上のモバイルノードのMACアドレスにブロードキャストARPを使用してはなりません。エージェントの勧誘またはモバイルノードから送信された登録リクエストから情報をコピーすることにより、MACアドレスを取得できます。モバイルノードのIPアドレスの外国人エージェントのARPキャッシュは、モバイルエージェントがモバイルノードのIPアドレスに関連付けられたMACアドレスを更新するために放送ARP以外の方法を持っている場合を除き、モバイルノードの訪問者リストエントリが期限切れになる前に有効期限を切ることを許可してはなりません。
Each foreign agent SHOULD support the mandatory features for reverse tunneling [12].
各外国人エージェントは、逆トンネリングのための必須機能をサポートする必要があります[12]。
The home agent MUST be able to intercept any datagrams on the home network addressed to the mobile node while the mobile node is registered away from home. Proxy and gratuitous ARP MAY be used in enabling this interception, as specified in Section 4.6.
ホームエージェントは、モバイルノードが自宅から登録されている間に、モバイルノードにアドレス指定されたホームネットワーク上のデータグラムを傍受できる必要があります。セクション4.6で指定されているように、この傍受を有効にする際に、プロキシと無償のARPを使用できます。
The home agent must examine the IP Destination Address of all arriving datagrams to see if it is equal to the home address of any of its mobile nodes registered away from home. If so, the home agent tunnels the datagram to the mobile node's currently registered care-of address or addresses. If the home agent supports the optional capability of multiple simultaneous mobility bindings, it tunnels a copy to each care-of address in the mobile node's mobility binding list. If the mobile node has no current mobility bindings, the home agent MUST NOT attempt to intercept datagrams destined for the mobile node, and thus will not in general receive such datagrams. However, if the home agent is also a router handling common IP traffic, it is possible that it will receive such datagrams for forwarding onto the home network. In this case, the home agent MUST assume the mobile node is at home and simply forward the datagram directly onto the home network.
ホームエージェントは、到着するすべてのデータグラムのIP宛先アドレスを調べて、自宅から登録されているモバイルノードのホームアドレスに等しいかどうかを確認する必要があります。その場合、ホームエージェントはデータグラムをモバイルノードの現在登録されている住所または住所にトンネルします。ホームエージェントが複数の同時モビリティバインディングのオプションの機能をサポートしている場合、モバイルノードのモビリティバインディングリストの各住所にコピーをトンネルします。モバイルノードに現在のモビリティバインディングがない場合、ホームエージェントはモバイルノードに向けられたデータグラムを傍受しようとしてはなりません。したがって、一般的にそのようなデータグラムを受信しません。ただし、ホームエージェントが一般的なIPトラフィックを処理するルーターでもある場合、ホームネットワークに転送するためにそのようなデータグラムを受信する可能性があります。この場合、ホームエージェントはモバイルノードが自宅にあると仮定し、データグラムをホームネットワークに直接転送する必要があります。
For multihomed home agents, the source address in the outer IP header of the encapsulated datagram MUST be the address sent to the mobile node in the Home Agent field of the Registration Reply. That is, the home agent cannot use the address of some other network interface as the source address.
マルチホームのホームエージェントの場合、カプセル化されたデータグラムの外側IPヘッダーのソースアドレスは、登録返信のホームエージェントフィールドのモバイルノードに送信されるアドレスでなければなりません。つまり、ホームエージェントは、他のネットワークインターフェイスのアドレスをソースアドレスとして使用することはできません。
See Section 4.1 regarding methods of encapsulation that may be used for tunneling. Nodes implementing tunneling SHOULD also implement the "tunnel soft state" mechanism [14], which allows ICMP error messages returned from the tunnel to correctly be reflected back to the original senders of the tunneled datagrams.
トンネリングに使用できるカプセル化方法については、セクション4.1を参照してください。トンネリングを実装するノードは、「トンネルソフトステート」メカニズム[14]を実装する必要があります。これにより、トンネルから返されたICMPエラーメッセージがトンネリングデータグラムの元の送信者に正しく反映されるようにします。
Home agents MUST decapsulate packets addressed to themselves, sent by a mobile node for the purpose of maintaining location privacy, as described in Section 5.5. This feature is also required for support of reverse tunneling [12].
ホームエージェントは、セクション5.5で説明されているように、ロケーションプライバシーを維持するためにモバイルノードによって送信された、自分自身に宛てられたパケットを脱カプセル化する必要があります。この機能は、逆トンネリングのサポートにも必要です[12]。
If the Lifetime for a given mobility binding expires before the home agent has received another valid Registration Request for that mobile node, then that binding is deleted from the mobility binding list. The home agent MUST NOT send any Registration Reply message simply because the mobile node's binding has expired. The entry in the visitor list of the mobile node's current foreign agent will expire naturally, probably at the same time as the binding expired at the home agent. When a mobility binding's lifetime expires, the home agent MUST delete the binding, but it MUST retain any other (non-expired) simultaneous mobility bindings that it holds for the mobile node.
ホームエージェントがそのモバイルノードの別の有効な登録要求を受け取る前に、特定のモビリティバインディングの寿命が期限切れになった場合、そのバインディングはモビリティバインディングリストから削除されます。ホームエージェントは、モバイルノードのバインディングが期限切れになったという理由だけで、登録返信メッセージを送信してはなりません。モバイルノードの現在の外国人エージェントの訪問者リストへのエントリは、おそらくホームエージェントで有効期限が切れたバインディングと同時に、自然に期限切れになります。モビリティバインディングの寿命が切れる場合、ホームエージェントはバインディングを削除する必要がありますが、モバイルノード用に保持する他の（エキスパートされていない）同時モビリティバインディングを保持する必要があります。
When a home agent receives a datagram, intercepted for one of its mobile nodes registered away from home, the home agent MUST examine the datagram to check if it is already encapsulated. If so, special rules apply in the forwarding of that datagram to the mobile node:
ホームエージェントがデータグラムを受信し、自宅から離れて登録されたモバイルノードの1つをインターセプトした場合、ホームエージェントはデータグラムを調べて、既にカプセル化されているかどうかを確認する必要があります。その場合、そのデータグラムのモバイルノードへの転送には特別なルールが適用されます。
o If the inner (encapsulated) Destination Address is the same as the outer Destination Address (the mobile node), then the home agent MUST also examine the outer Source Address of the encapsulated datagram (the source address of the tunnel). If this outer Source Address is the same as the mobile node's current care-of address, the home agent MUST silently discard that datagram in order to prevent a likely routing loop. If, instead, the outer Source Address is NOT the same as the mobile node's current care-of address, then the home agent SHOULD forward the datagram to the mobile node. In order to forward the datagram in this case, the home agent MAY simply alter the outer Destination Address to the care-of address, rather than re-encapsulating the datagram.
o 内側（カプセル化された）宛先アドレスが外側の宛先アドレス（モバイルノード）と同じ場合、ホームエージェントはカプセル化されたデータグラム（トンネルのソースアドレス）の外側のソースアドレスも調べる必要があります。この外側のソースアドレスがモバイルノードの現在のアドレスと同じである場合、ホームエージェントは、ルーティングループの可能性を防ぐために、そのデータグラムを静かに破棄する必要があります。代わりに、外側のソースアドレスがモバイルノードの現在のアドレスと同じでない場合、ホームエージェントはデータグラムをモバイルノードに転送する必要があります。この場合、データグラムを転送するために、ホームエージェントは、データグラムを再カプセルするのではなく、外側の宛先アドレスをアドレスのケアに変更するだけです。
o Otherwise (the inner Destination Address is NOT the same as the outer Destination Address), the home agent SHOULD encapsulate the datagram again (nested encapsulation), with the new outer Destination Address set equal to the mobile node's care-of address. That is, the home agent forwards the entire datagram to the mobile node in the same way as any other datagram (encapsulated already or not).
o それ以外の場合は、（内側の宛先アドレスは外側の宛先アドレスと同じではありません）、ホームエージェントは再びデータグラムをカプセル化する必要があります（ネストされたカプセル化）。新しい外側の宛先アドレスは、モバイルノードのケアオブアドレスに等しい。つまり、ホームエージェントは、他のデータグラムと同じ方法でデータグラム全体をモバイルノードに転送します（すでにカプセル化されているかどうか）。
When a home agent receives a broadcast datagram, it MUST NOT forward the datagram to any mobile nodes in its mobility binding list other than those that have requested forwarding of broadcast datagrams. A mobile node MAY request forwarding of broadcast datagrams by setting the 'B' bit in its Registration Request message (Section 3.3). For each such registered mobile node, the home agent SHOULD forward received broadcast datagrams to the mobile node, although it is a matter of configuration at the home agent as to which specific categories of broadcast datagrams will be forwarded to such mobile nodes.
ホームエージェントがブロードキャストデータグラムを受信した場合、ブロードキャストデータグラムの転送を要求したもの以外のモバイルバインディングリストのモバイルノードにデータグラムを転送してはなりません。モバイルノードは、登録要求メッセージに「B」ビットを設定することにより、ブロードキャストデータグラムの転送を要求する場合があります（セクション3.3）。このような登録されたモバイルノードごとに、ホームエージェントはブロードキャストデータグラムをモバイルノードに転送する必要がありますが、ホームエージェントでの構成の問題であるブロードキャストデータグラムの特定のカテゴリがそのようなモバイルノードに転送されるかについてです。
If the 'D' bit was set in the mobile node's Registration Request message, indicating that the mobile node is using a co-located care-of address, the home agent simply tunnels appropriate broadcast IP datagrams to the mobile node's care-of address. Otherwise (the 'D' bit was NOT set), the home agent first encapsulates the broadcast datagram in a unicast datagram addressed to the mobile node's home address, and then tunnels this encapsulated datagram to the foreign agent. This extra level of encapsulation is required so that the foreign agent can determine which mobile node should receive the datagram after it is decapsulated. When received by the foreign agent, the unicast encapsulated datagram is detunneled and delivered to the mobile node in the same way as any other datagram. In either case, the mobile node must decapsulate the datagram it receives in order to recover the original broadcast datagram.
モバイルノードの登録リクエストメッセージに「D」ビットが設定されている場合、モバイルノードが共同配置されたケアオブアドレスを使用していることを示している場合、ホームエージェントは単にモバイルノードのケアオブアドレスに適切なブロードキャストIPデータグラムをトンネルします。それ以外の場合は（「d」ビットは設定されていません）、ホームエージェントは最初にモバイルノードのホームアドレスにアドレス指定されたユニキャストデータグラムのブロードキャストデータグラムをカプセル化し、次にこのカプセル化されたデータグラムを外国エージェントにトンネルします。この余分なレベルのカプセル化が必要であるため、外国人エージェントが脱カプセル化後にどのモバイルノードを受信するかを決定できるようにします。外国のエージェントが受信した場合、ユニキャストカプセル化されたデータグラムは排出され、他のデータグラムと同じ方法でモバイルノードに配信されます。どちらの場合でも、モバイルノードは、元のブロードキャストデータグラムを回復するために受信するデータグラムを脱カプセル化する必要があります。
As mentioned previously, a mobile node that is connected to its home network functions in the same way as any other (fixed) host or router. Thus, when it is at home, a mobile node functions identically to other multicast senders and receivers. This section therefore describes the behavior of a mobile node that is visiting a foreign network.
前述のように、ホームネットワークに接続されているモバイルノードは、他の（固定）ホストまたはルーターと同じ方法で機能します。したがって、自宅にいる場合、モバイルノードは他のマルチキャスト送信者とレシーバーと同じように機能します。したがって、このセクションでは、外国ネットワークにアクセスしているモバイルノードの動作について説明します。
In order to receive multicasts, a mobile node MUST join the multicast group in one of two ways. First, a mobile node MAY join the group via a (local) multicast router on the visited subnet. This option assumes that there is a multicast router present on the visited subnet. If the mobile node is using a co-located care-of address, it SHOULD use this address as the source IP address of its IGMP [6] messages. Otherwise, it MAY use its home address.
マルチキャストを受信するには、モバイルノードが2つの方法のいずれかでマルチキャストグループに参加する必要があります。まず、モバイルノードは、訪問されたサブネットの（ローカル）マルチキャストルーターを介してグループに参加できます。このオプションは、訪問されたサブネットにマルチキャストルーターが存在することを前提としています。モバイルノードが共同配置されたアドレスを使用している場合、このアドレスをIGMP [6]メッセージのソースIPアドレスとして使用する必要があります。それ以外の場合は、自宅の住所を使用する場合があります。
Alternatively, a mobile node that wishes to receive multicasts MAY join groups via a bidirectional tunnel to its home agent, assuming that its home agent is a multicast router. The mobile node tunnels IGMP messages to its home agent, and the home agent forwards multicast datagrams down the tunnel to the mobile node. For packets tunneled to the home agent, the source address in the IP header SHOULD be the mobile node's home address.
あるいは、マルチキャストを受信したいモバイルノードは、ホームエージェントがマルチキャストルーターであると仮定して、双方向トンネルを介してホームエージェントにグループに参加する場合があります。モバイルノードトンネルIGMPメッセージはホームエージェントにメッセージを送り、ホームエージェントはマルチキャストデータグラムをトンネルからモバイルノードに転送します。ホームエージェントにトンネリングされたパケットの場合、IPヘッダーのソースアドレスはモバイルノードのホームアドレスである必要があります。
The rules for multicast datagram delivery to mobile nodes in this case are identical to those for broadcast datagrams (Section 4.3). Namely, if the mobile node is using a co-located care-of address (the 'D' bit was set in the mobile node's Registration Request), then the home agent SHOULD tunnel the datagram to this care-of address; otherwise, the home agent MUST first encapsulate the datagram in a unicast datagram addressed to the mobile node's home address and then MUST tunnel the resulting datagram (nested tunneling) to the mobile node's care-of address. For this reason, the mobile node MUST be capable of decapsulating packets sent to its home address in order to receive multicast datagrams using this method.
この場合のモバイルノードへのマルチキャストデータグラムの配信のルールは、ブロードキャストデータグラムのルールと同じです（セクション4.3）。つまり、モバイルノードが共同配置のケアオブアドレスを使用している場合（モバイルノードの登録リクエストで「d」ビットが設定されています）、ホームエージェントはデータグラムをこのケアオブアドレスにトンネルする必要があります。それ以外の場合、ホームエージェントは、最初にモバイルノードのホームアドレスにアドレス指定されたユニキャストデータグラムのデータグラムをカプセル化し、次に結果のデータグラム（ネストされたトンネリング）をモバイルノードのケアアドレスにトンネルする必要があります。このため、この方法を使用してマルチキャストデータグラムを受信するために、モバイルノードは自宅の住所に送信されるパケットを脱カプセル化できる必要があります。
A mobile node that wishes to send datagrams to a multicast group also has two options: (1) send directly on the visited network; or (2) send via a tunnel to its home agent. Because multicast routing in general depends upon the IP source address, a mobile node that sends multicast datagrams directly on the visited network MUST use a co-located care-of address as the IP source address. Similarly, a mobile node that tunnels a multicast datagram to its home agent MUST use its home address as the IP source address of both the (inner) multicast datagram and the (outer) encapsulating datagram. This second option assumes that the home agent is a multicast router.
データグラムをマルチキャストグループに送信したいモバイルノードには、次の2つのオプションもあります。（1）訪問されたネットワークで直接送信します。または（2）トンネルを介してホームエージェントに送信します。一般にマルチキャストルーティングはIPソースアドレスに依存するため、訪問されたネットワークでマルチキャストデータグラムを直接送信するモバイルノードは、IPソースアドレスとして共同配置されたケアオブアドレスを使用する必要があります。同様に、マルチキャストデータグラムをホームエージェントにトンネルするモバイルノードは、（内側の）マルチキャストデータグラムと（外側）カプセル化データグラムの両方のIPソースアドレスとしてホームアドレスを使用する必要があります。この2番目のオプションは、ホームエージェントがマルチキャストルーターであることを前提としています。
A mobile node can be a router that is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks".
モバイルノードは、おそらく飛行機、船、列車、自動車、自転車、またはカヤックの上で、1つ以上のネットワーク全体が一緒に移動することを担当するルーターになります。モバイルルーターが提供するネットワークに接続されたノード自体は、固定ノードまたはモバイルノードまたはルーターにする場合があります。このドキュメントでは、そのようなネットワークは「モバイルネットワーク」と呼ばれます。
A mobile router MAY act as a foreign agent and provide a foreign agent care-of address to mobile nodes connected to the mobile network. Typical routing to a mobile node via a mobile router in this case is illustrated by the following example:
モバイルルーターは、外国のエージェントとして機能し、モバイルネットワークに接続されたモバイルノードに外国のエージェントのケアオブアドレスを提供する場合があります。この場合、モバイルルーターを介したモバイルノードへの典型的なルーティングは、次の例で説明されています。
a. A laptop computer is disconnected from its home network and later attached to a network port in the seat back of an aircraft. The laptop computer uses Mobile IP to register on this foreign network, using a foreign agent care-of address discovered through an Agent Advertisement from the aircraft's foreign agent.
a. ラップトップコンピューターは、ホームネットワークから切断され、後に航空機の背面にあるネットワークポートに取り付けられます。ラップトップコンピューターは、航空機の外国人エージェントからのエージェント広告を通じて発見された外国のエージェントケアオブアドレスを使用して、モバイルIPを使用してこの外国ネットワークに登録します。
b. The aircraft network is itself mobile. Suppose the node serving as the foreign agent on the aircraft also serves as the default router that connects the aircraft network to the rest of the Internet. When the aircraft is at home, this router is attached to some fixed network at the airline's headquarters, which is the router's home network. While the aircraft is in flight, this router registers from time to time over its radio link with a series of foreign agents below it on the ground. This router's home agent is a node on the fixed network at the airline's headquarters.
b. 航空機ネットワーク自体はモバイルです。航空機の外国人エージェントとして機能するノードが、航空機ネットワークを他のインターネットに接続するデフォルトのルーターとしても機能するとします。航空機が自宅にいるとき、このルーターは、ルーターのホームネットワークである航空会社の本部の固定ネットワークに取り付けられています。航空機が飛行中に、このルーターは、地上の一連の外国人エージェントとの無線リンクを介して時々登録します。このルーターのホームエージェントは、航空会社の本部の固定ネットワーク上のノードです。
c. Some correspondent node sends a datagram to the laptop computer, addressing the datagram to the laptop's home address. This datagram is initially routed to the laptop's home network.
c. 一部の特派員ノードは、データグラムをラップトップコンピューターに送信し、データグラムをラップトップのホームアドレスにアドレス指定します。このデータグラムは、最初はラップトップのホームネットワークにルーティングされます。
d. The laptop's home agent intercepts the datagram on the home network and tunnels it to the laptop's care-of address, which in this example is an address of the node serving as the router and foreign agent on the aircraft. Normal IP routing will route the datagram to the fixed network at the airline's headquarters.
d. ラップトップのホームエージェントは、ホームネットワーク上のデータグラムをインターセプトし、ラップトップのケアオブアドレスにトンネルします。これは、この例では、航空機のルーターと外国人エージェントとして機能するノードのアドレスです。通常のIPルーティングは、航空会社の本部のデータグラムを固定ネットワークにルーティングします。
e. The aircraft router and foreign agent's home agent there intercept the datagram and tunnel it to its current care-of address, which in this example is some foreign agent on the ground below the aircraft. The original datagram from the correspondent node has now been encapsulated twice: once by the laptop's home agent and again by the aircraft's home agent.
e. そこで航空機のルーターと外国人エージェントのホームエージェントは、データグラムを傍受し、現在の住所にトンネルしています。この例では、この例では、航空機の下にある外国人エージェントです。特派員ノードの元のデータグラムは、ラップトップのホームエージェントによって1回、航空機のホームエージェントによって2回カプセル化されました。
f. The foreign agent on the ground decapsulates the datagram, yielding a datagram still encapsulated by the laptop's home agent, with a Destination Address of the laptop's care-of address. The ground foreign agent sends the resulting datagram over its radio link to the aircraft.
f. 地上の外国人エージェントはデータグラムを脱カプセル化し、ラップトップのホームエージェントによってまだカプセル化されたデータグラムを生成し、ラップトップのケアオブアドレスの宛先アドレスを備えています。グラウンド外国のエージェントは、結果のデータグラムを航空機への無線リンク上に送信します。
g. The foreign agent on the aircraft decapsulates the datagram, yielding the original datagram from the correspondent node, with a Destination Address of the laptop's home address. The aircraft foreign agent delivers the datagram over the aircraft network to the laptop's link-layer address.
g. 航空機の外国人エージェントはデータグラムを脱カプセル化し、特派員ノードから元のデータグラムを生成し、ラップトップの自宅アドレスの宛先アドレスがあります。航空機の外国人エージェントは、航空機ネットワーク上のデータグラムをラップトップのリンク層アドレスに配信します。
This example illustrates the case in which a mobile node is attached to a mobile network. That is, the mobile node is mobile with respect to the network, which itself is also mobile (here with respect to the ground). If, instead, the node is fixed with respect to the mobile network (the mobile network is the fixed node's home network), then either of two methods may be used to cause datagrams from correspondent nodes to be routed to the fixed node.
この例は、モバイルノードがモバイルネットワークに接続されている場合を示しています。つまり、モバイルノードはネットワークに対してモバイルであり、それ自体もモバイルです（ここでは地面に関して）。代わりに、ノードがモバイルネットワーク（モバイルネットワークが固定ノードのホームネットワーク）に対して固定されている場合、2つのメソッドのいずれかを使用して、特派員ノードのデータグラムを固定ノードにルーティングします。
For the fixed node, a home agent MAY be configured to have a permanent registration that indicates the mobile router's address as the fixed host's care-of address. The mobile router's home agent will normally be used for this purpose. The home agent is then responsible for advertising connectivity using normal routing protocols to the fixed node. Any datagrams sent to the fixed node will thus use nested tunneling as described above.
固定ノードの場合、ホームエージェントは、モバイルルーターのアドレスを固定ホストのケアオブアドレスとして示す永続的な登録を持つように構成される場合があります。モバイルルーターのホームエージェントは通常、この目的に使用されます。ホームエージェントは、固定ノードへの通常のルーティングプロトコルを使用して接続性を広告する責任があります。したがって、固定ノードに送信されたデータグラムは、上記のようにネストされたトンネリングを使用します。
Alternatively, the mobile router MAY advertise connectivity to the entire mobile network using normal IP routing protocols through a bidirectional tunnel to its own home agent. This method avoids the need for nested tunneling of datagrams.
あるいは、モバイルルーターは、双方向トンネルを介して独自のホームエージェントへの通常のIPルーティングプロトコルを使用して、モバイルネットワーク全体への接続を宣伝する場合があります。この方法は、データグラムのネストされたトンネルの必要性を回避します。
The use of ARP [16] requires special rules for correct operation when wireless or mobile nodes are involved. The requirements specified in this section apply to all home networks in which ARP is used for address resolution.
ARP [16]の使用には、ワイヤレスまたはモバイルノードが関与している場合、正しい操作のための特別なルールが必要です。このセクションで指定された要件は、ARPがアドレス解決に使用されるすべてのホームネットワークに適用されます。
In addition to the normal use of ARP for resolving a target node's link-layer address from its IP address, this document distinguishes two special uses of ARP:
IPアドレスからターゲットノードのリンク層アドレスを解決するためのARPの通常の使用に加えて、このドキュメントは、ARPの2つの特別な使用を区別します。
o A Proxy ARP [49] is an ARP Reply sent by one node on behalf of another node that is either unable or unwilling to answer its own ARP Requests. The sender of a Proxy ARP reverses the Sender and Target Protocol Address fields as described in [16], but supplies some configured link-layer address (generally, its own) in the Sender Hardware Address field. The node receiving the Reply will then associate this link-layer address with the IP address of the original target node, causing it to transmit future datagrams for this target node to the node with that link-layer address.
o プロキシARP [49]は、別のノードに代わって1つのノードから送信されたARP返信です。プロキシARPの送信者は、[16]で説明されているように送信者とターゲットプロトコルアドレスフィールドを逆転させますが、送信者ハードウェアアドレスフィールドに構成されたリンク層アドレス（一般的に、独自）を提供します。返信を受信するノードは、このリンク層アドレスを元のターゲットノードのIPアドレスに関連付け、このターゲットノードの将来のデータグラムをそのリンク層アドレスでノードに送信します。
o A Gratuitous ARP [45] is an ARP packet sent by a node in order to spontaneously cause other nodes to update an entry in their ARP cache. A gratuitous ARP MAY use either an ARP Request or an ARP Reply packet. In either case, the ARP Sender Protocol Address and ARP Target Protocol Address are both set to the IP address of the cache entry to be updated, and the ARP Sender Hardware Address is set to the link-layer address to which this cache entry should be updated. When using an ARP Reply packet, the Target Hardware Address is also set to the link-layer address to which this cache entry should be updated (this field is not used in an ARP Request packet).
o 無償のARP [45]は、他のノードがARPキャッシュのエントリを自然に更新するためにノードによって送信されるARPパケットです。無償のARPは、ARPリクエストまたはARP応答パケットのいずれかを使用する場合があります。どちらの場合でも、ARP Sender ProtocolアドレスとARPターゲットプロトコルアドレスはどちらも更新するキャッシュエントリのIPアドレスに設定され、ARP Senderハードウェアアドレスは、このキャッシュエントリが必要なリンク層アドレスに設定されます。更新しました。ARP Replyパケットを使用する場合、ターゲットハードウェアアドレスは、このキャッシュエントリを更新するリンクレイヤーアドレスにも設定されます（このフィールドはARPリクエストパケットで使用されません）。
In either case, for a gratuitous ARP, the ARP packet MUST be transmitted as a local broadcast packet on the local link. As specified in [16], any node receiving any ARP packet (Request or Reply) MUST update its local ARP cache with the Sender Protocol and Hardware Addresses in the ARP packet, if the receiving node has an entry for that IP address already in its ARP cache. This requirement in the ARP protocol applies even for ARP Request packets, and for ARP Reply packets that do not match any ARP Request transmitted by the receiving node [16].
どちらの場合でも、無償のARPの場合、ARPパケットはローカルリンクのローカルブロードキャストパケットとして送信する必要があります。[16]で指定されているように、ARPパケットを受信するノード（要求または返信）は、受信ノードにそのIPアドレスのエントリが既にある場合、ARPパケットの送信者プロトコルとハードウェアアドレスを使用してローカルARPキャッシュを更新する必要があります。ARPキャッシュ。ARPプロトコルのこの要件は、ARP要求パケット、および受信ノード[16]によって送信されるARP要求と一致しないARP応答パケットにも適用されます。
While a mobile node is registered on a foreign network, its home agent uses proxy ARP [49] to reply to ARP Requests it receives that seek the mobile node's link-layer address. When receiving an ARP Request, the home agent MUST examine the target IP address of the Request, and if this IP address matches the home address of any mobile node for which it has a registered mobility binding, the home agent MUST transmit an ARP Reply on behalf of the mobile node. After exchanging the sender and target addresses in the packet [49], the home agent MUST set the sender link-layer address in the packet to the link-layer address of its own interface over which the Reply will be sent.
モバイルノードは外部ネットワークに登録されていますが、ホームエージェントはプロキシARP [49]を使用して、モバイルノードのリンク層アドレスを求めるARPリクエストに返信します。ARP要求を受信するとき、ホームエージェントはリクエストのターゲットIPアドレスを調べる必要があり、このIPアドレスが登録されたモビリティバインディングを持つモバイルノードのホームアドレスと一致する場合、ホームエージェントはARPの返信を送信する必要がありますモバイルノードに代わって。パケット[49]で送信者とターゲットアドレスを交換した後、ホームエージェントは、返信が送信される独自のインターフェイスのリンク層アドレスに送信者リンク層アドレスをパケットに設定する必要があります。
When a mobile node leaves its home network and registers a binding on a foreign network, its home agent uses gratuitous ARP to update the ARP caches of nodes on the home network. This causes such nodes to associate the link-layer address of the home agent with the mobile node's home (IP) address. When registering a binding for a mobile node for which the home agent previously had no binding (the mobile node was assumed to be at home), the home agent MUST transmit a gratuitous ARP on behalf of the mobile node. This gratuitous ARP packet MUST be transmitted as a broadcast packet on the link on which the mobile node's home address is located. Since broadcasts on the local link (such as Ethernet) are typically not guaranteed to be reliable, the gratuitous ARP packet SHOULD be retransmitted a small number of times to increase its reliability.
モバイルノードがホームネットワークを離れ、外部ネットワークの拘束力を登録すると、ホームエージェントは無償のARPを使用してホームネットワーク上のノードのARPキャッシュを更新します。これにより、このようなノードは、ホームエージェントのリンク層アドレスをモバイルノードのホーム（IP）アドレスに関連付けます。ホームエージェントが以前にバインディングしていなかったモバイルノードのバインディングを登録する場合（モバイルノードは自宅にあると想定されていた）、ホームエージェントはモバイルノードに代わって無償ARPを送信する必要があります。この無償のARPパケットは、モバイルノードのホームアドレスが配置されているリンク上のブロードキャストパケットとして送信する必要があります。ローカルリンク（イーサネットなど）でのブロードキャストは通常、信頼性があることを保証されていないため、無償のARPパケットは、信頼性を高めるために少数回再送信する必要があります。
When a mobile node returns to its home network, the mobile node and its home agent use gratuitous ARP to cause all nodes on the mobile node's home network to update their ARP caches to once again associate the mobile node's own link-layer address with the mobile node's home (IP) address. Before transmitting the (de)Registration Request message to its home agent, the mobile node MUST transmit this gratuitous ARP on its home network as a local broadcast on this link. The gratuitous ARP packet SHOULD be retransmitted a small number of times to increase its reliability, but these retransmissions SHOULD proceed in parallel with the transmission and processing of the mobile node's (de)Registration Request.
モバイルノードがホームネットワークに戻ると、モバイルノードとホームエージェントは、モバイルノードのホームネットワーク上のすべてのノードを使用してARPキャッシュを更新し、モバイルノードの独自のリンク層アドレスをモバイルに再び関連付けるようにします。ノードのホーム（IP）アドレス。（de）登録要求メッセージをホームエージェントに送信する前に、モバイルノードは、このリンクのローカル放送として、ホームネットワークでこの無償のARPを送信する必要があります。無償のARPパケットは、信頼性を高めるために少数回再送信する必要がありますが、これらの再送信は、モバイルノード（DE）登録要求の送信と処理と並行して進行する必要があります。
When the mobile node's home agent receives and accepts this (de)Registration Request, the home agent MUST also transmit a gratuitous ARP on the mobile node's home network. This gratuitous ARP also is used to associate the mobile node's home address with the mobile node's own link-layer address. A gratuitous ARP is transmitted by both the mobile node and its home agent, since in the case of wireless network interfaces, the area within transmission range of the mobile node will likely differ from that within range of its home agent. The ARP packet from the home agent MUST be transmitted as a local broadcast on the mobile node's home link, and SHOULD be retransmitted a small number of times to increase its reliability; these retransmissions, however, SHOULD proceed in parallel with the transmission and processing of the mobile node's (de)Registration Reply.
モバイルノードのホームエージェントがこの（de）登録要求を受信して受け入れる場合、ホームエージェントはモバイルノードのホームネットワークに無償のARPを送信する必要があります。この無償のARPは、モバイルノードのホームアドレスをモバイルノードのリンク層アドレスに関連付けるためにも使用されます。ワイヤレスネットワークインターフェイスの場合、モバイルノードの領域内の領域がホームエージェントの範囲内の範囲とは異なる可能性が高いため、モバイルノードとホームエージェントの両方によって無償のARPが送信されます。ホームエージェントからのARPパケットは、モバイルノードのホームリンクでローカルブロードキャストとして送信する必要があり、信頼性を高めるために少数回再送信する必要があります。ただし、これらの再送信は、モバイルノード（DE）登録返信の送信と処理と並行して進行する必要があります。
While the mobile node is away from home, it MUST NOT transmit any broadcast ARP Request or ARP Reply messages. Finally, while the mobile node is away from home, it MUST NOT reply to ARP Requests in which the target IP address is its own home address unless the ARP Request is unicast by a foreign agent with which the mobile node is attempting to register or a foreign agent with which the mobile node has an unexpired registration. In the latter case, the mobile node MUST use a unicast ARP Reply to respond to the foreign agent. Note that if the mobile node is using a co-located care-of address and receives an ARP Request in which the target IP address is this care-of address, then the mobile node SHOULD reply to this ARP Request. Note also that, when transmitting a Registration Request on a foreign network, a mobile node may discover the link-layer address of a foreign agent by storing the address as it is received from the Agent Advertisement from that foreign agent, but not by transmitting a broadcast ARP Request message.
モバイルノードが自宅から離れている間、ブロードキャストARPリクエストやARP応答メッセージを送信してはなりません。最後に、モバイルノードが自宅から離れている間、ARPリクエストがモバイルノードが登録しようとしている外国人エージェントによってUnicastでない限り、ターゲットIPアドレスが独自のホームアドレスであるARPリクエストに返信してはなりません。モバイルノードが期限切れの登録を持っている外国人エージェント。後者の場合、モバイルノードはユニキャストARPの返信を使用して、外国人エージェントに応答する必要があります。モバイルノードが共同配置されたアドレスを使用しており、ターゲットIPアドレスがこのケアオブアドレスであるARPリクエストを受信している場合、モバイルノードはこのARPリクエストに返信する必要があることに注意してください。また、外国ネットワークで登録要求を送信する場合、モバイルノードは、その外国人エージェントからエージェント広告から受信されたアドレスを保存することにより、外国人エージェントのリンク層アドレスを発見する場合がありますが、ブロードキャストARP要求メッセージ。
The specific order in which each of the above requirements for the use of ARP, proxy ARP, and gratuitous ARP are applied, relative to the transmission and processing of the mobile node's Registration Request and Registration Reply messages when leaving home or returning home, are important to the correct operation of the protocol.
ARP、プロキシARP、および無償のARPを使用するための上記の各要件が、モバイルノードの登録要求の送信と処理と、家を出るときや家を出たときの登録返信メッセージを適用する特定の順序が重要です。プロトコルの正しい動作に。
To summarize the above requirements, when a mobile node leaves its home network, the following steps, in this order, MUST be performed:
上記の要件を要約するには、モバイルノードがホームネットワークを離れる場合、次の手順をこの順序で実行する必要があります。
o The mobile node decides to register away from home, perhaps because it has received an Agent Advertisement from a foreign agent and has not recently received one from its home agent.
o モバイルノードは、おそらく外国人エージェントからエージェント広告を受け取っており、最近ホームエージェントから1つを受け取っていないため、自宅から離れて登録することを決定しました。
o Before transmitting the Registration Request, the mobile node disables its own future processing of any ARP Requests it may subsequently receive requesting the link-layer address corresponding to its home address, except insofar as necessary to communicate with foreign agents on visited networks.
o 登録要求を送信する前に、モバイルノードは、訪問したネットワークで外国人エージェントと通信するために必要な場合を除き、自宅の住所に対応するリンク層アドレスを要求するARPリクエストの独自の将来の処理を無効にします。
o The mobile node transmits its Registration Request.
o モバイルノードは登録要求を送信します。
o When the mobile node's home agent receives and accepts the Registration Request, it performs a gratuitous ARP on behalf of the mobile node, and begins using proxy ARP to reply to ARP Requests that it receives requesting the mobile node's link-layer address. In the gratuitous ARP, the ARP Sender Hardware Address is set to the link-layer address of the home agent. If, instead, the home agent rejects the Registration Request, no ARP processing (neither gratuitous nor proxy) is performed by the home agent.
o モバイルノードのホームエージェントが登録リクエストを受信して受け入れると、モバイルノードに代わって無償のARPを実行し、プロキシARPを使用して、モバイルノードのリンクレイヤーアドレスのリクエストを受信するARPリクエストに返信します。無償のARPでは、ARP送信者のハードウェアアドレスがホームエージェントのリンクレイヤーアドレスに設定されます。代わりに、ホームエージェントが登録要求を拒否した場合、HomeエージェントによってARP処理（無償またはプロキシ）が実行されない場合。
When a mobile node later returns to its home network, the following steps, in this order, MUST be performed:
モバイルノードが後でホームネットワークに戻った場合、この順序で次の手順を実行する必要があります。
o The mobile node decides to register at home, perhaps because it has received an Agent Advertisement from its home agent.
o モバイルノードは、おそらくホームエージェントからエージェント広告を受け取ったために、自宅で登録することを決定しました。
o Before transmitting the Registration Request, the mobile node re-enables its own future processing of any ARP Requests it may subsequently receive requesting its link-layer address.
o 登録リクエストを送信する前に、モバイルノードは、ARPリクエストの独自の将来の処理を再確定します。その後、リンクレイヤーアドレスを要求することができます。
o The mobile node performs a gratuitous ARP for itself. In this gratuitous ARP, the ARP Sender Hardware Address is set to the link-layer address of the mobile node.
o モバイルノードは、それ自体に対して無償のARPを実行します。この無償のARPでは、ARP送信者のハードウェアアドレスがモバイルノードのリンクレイヤーアドレスに設定されています。
o The mobile node transmits its Registration Request.
o モバイルノードは登録要求を送信します。
o When the mobile node's home agent receives and accepts the Registration Request, it stops using proxy ARP to reply to ARP Requests that it receives requesting the mobile node's link-layer address, and then performs a gratuitous ARP on behalf of the mobile node. In this gratuitous ARP, the ARP Sender Hardware Address is set to the link-layer address of the mobile node. If, instead, the home agent rejects the Registration Request, the home agent MUST NOT make any change to the way it performs ARP processing (neither gratuitous nor proxy) for the mobile node. In this latter case, the home agent should operate as if the mobile node has not returned home, and continue to perform proxy ARP on behalf of the mobile node.
o モバイルノードのホームエージェントが登録リクエストを受信して受け入れると、プロキシARPを使用してARPリクエストに返信し、モバイルノードのリンク層アドレスを要求し、モバイルノードに代わって無償のARPを実行します。この無償のARPでは、ARP送信者のハードウェアアドレスがモバイルノードのリンクレイヤーアドレスに設定されています。代わりに、ホームエージェントが登録要求を拒否した場合、ホームエージェントは、モバイルノードのARP処理（無償またはプロキシのいずれでもない）の実行方法に変更を加えてはなりません。この後者の場合、ホームエージェントは、モバイルノードが家に帰っていないかのように動作し、モバイルノードに代わってプロキシARPを実行し続けます。
The mobile computing environment is potentially very different from the ordinary computing environment. In many cases, mobile computers will be connected to the network via wireless links. Such links are particularly vulnerable to passive eavesdropping, active replay attacks, and other active attacks.
モバイルコンピューティング環境は、通常のコンピューティング環境とは非常に異なる可能性があります。多くの場合、モバイルコンピューターはワイヤレスリンクを介してネットワークに接続されます。このようなリンクは、受動的な盗聴、アクティブなリプレイ攻撃、およびその他のアクティブな攻撃に対して特に脆弱です。
Home agents and mobile nodes MUST be able to perform authentication. The default algorithm is HMAC-MD5 [10], with a key size of 128 bits. The foreign agent MUST also support authentication using HMAC-MD5 and key sizes of 128 bits or greater, with manual key distribution. Keys with arbitrary binary values MUST be supported.
ホームエージェントとモバイルノードは、認証を実行できる必要があります。デフォルトのアルゴリズムはHMAC-MD5 [10]で、キーサイズは128ビットです。また、外国人エージェントは、HMAC-MD5と128ビット以上のキーサイズを使用した認証をサポートする必要があり、手動のキーディストリビューションを使用する必要があります。任意のバイナリ値を持つキーをサポートする必要があります。
The "prefix+suffix" use of MD5 to protect data and a shared secret is considered vulnerable to attack by the cryptographic community. Where backward compatibility with existing Mobile IP implementations that use this mode is needed, new implementations SHOULD include keyed MD5 [19] as one of the additional authentication algorithms for use when producing and verifying the authentication data that is supplied with Mobile IP registration messages, for instance, in the extensions specified in Sections 3.5.2, 3.5.3, and 3.5.4.
データと共有秘密を保護するためにMD5の「接頭接尾辞」を使用して、暗号化コミュニティによる攻撃に対して脆弱であると考えられています。このモードを使用する既存のモバイルIP実装との逆方向の互換性が必要な場合、新しい実装は、モバイルIP登録メッセージで提供される認証データを生成および検証する際に使用する追加の認証アルゴリズムの1つとして、キー付きMD5 [19]を含める必要があります。たとえば、セクション3.5.2、3.5.3、および3.5.4で指定された拡張機能で。
More authentication algorithms, algorithm modes, key distribution methods, and key sizes MAY also be supported for all of these extensions.
これらのすべての拡張機能では、より多くの認証アルゴリズム、アルゴリズムモード、キー配布方法、およびキーサイズもサポートされる場合があります。
The registration protocol described in this document will result in a mobile node's traffic being tunneled to its care-of address. This tunneling feature could be a significant vulnerability if the registration were not authenticated. Such remote redirection, for instance, as performed by the mobile registration protocol, is widely understood to be a security problem in the current Internet if not authenticated [30]. Moreover, the Address Resolution Protocol (ARP) is not authenticated, and can potentially be used to steal another host's traffic. The use of gratuitous ARP (Section 4.6) brings with it all of the risks associated with the use of ARP.
このドキュメントで説明されている登録プロトコルは、モバイルノードのトラフィックがその世話をすることになります。登録が認証されていない場合、このトンネリング機能は大きな脆弱性になる可能性があります。たとえば、モバイル登録プロトコルによって実行されるようなリモートリダイレクトは、認証されていない場合、現在のインターネットのセキュリティ問題であると広く理解されています[30]。さらに、アドレス解像度プロトコル（ARP）は認証されておらず、潜在的に別のホストのトラフィックを盗むために使用できます。無償のARP（セクション4.6）の使用は、ARPの使用に関連するすべてのリスクをもたらします。
This specification requires a strong authentication mechanism (keyed MD5) that precludes many potential attacks based on the Mobile IP registration protocol. However, because key distribution is difficult in the absence of a network key management protocol, messages with the foreign agent are not all required to be authenticated. In a commercial environment it might be important to authenticate all messages between the foreign agent and the home agent, so that billing is possible and service providers do not provide service to users that are not legitimate customers of that service provider.
この仕様には、モバイルIP登録プロトコルに基づいて多くの潜在的な攻撃を排除する強力な認証メカニズム（キー付きMD5）が必要です。ただし、ネットワークキーマネジメントプロトコルがない場合、キーディストリビューションは困難であるため、外国人エージェントとのメッセージはすべて認証される必要はありません。商業環境では、外国人エージェントとホームエージェント間のすべてのメッセージを認証することが重要である可能性があります。そうすれば、請求が可能であり、サービスプロバイダーはそのサービスプロバイダーの合法的な顧客ではないユーザーにサービスを提供しません。
The strength of any authentication mechanism depends on several factors, including the innate strength of the authentication algorithm, the secrecy of the key used, the strength of the key used, and the quality of the particular implementation. This specification requires implementation of keyed MD5 for authentication, but does not preclude the use of other authentication algorithms and modes. For keyed MD5 authentication to be useful, the 128-bit key must be both secret (that is, known only to authorized parties) and pseudo-random.
認証メカニズムの強度は、認証アルゴリズムの生来の強度、使用されるキーの秘密、使用されるキーの強度、特定の実装の品質など、いくつかの要因に依存します。この仕様には、認証用のキー付きMD5の実装が必要ですが、他の認証アルゴリズムとモードの使用を排除しません。キー付きMD5認証が有用であるためには、128ビットキーは秘密（つまり、認定当事者のみに知られている）と擬似ランダムの両方でなければなりません。
If nonces are used in connection with replay protection, they must also be selected carefully. RFC 4086 [8] written by Eastlake, et al. provides more information on generating pseudo-random numbers.
リプレイ保護に関連してNoncesが使用されている場合、それらも慎重に選択する必要があります。RFC 4086 [8] Eastlake、et al。擬似ランダム数の生成に関する詳細情報を提供します。
Users who have sensitive data that they do not wish others to see should use mechanisms outside the scope of this document (such as encryption) to provide appropriate protection. Users concerned about traffic analysis should consider appropriate use of link encryption. If absolute location privacy is desired, the mobile node can create a tunnel to its home agent. Then, datagrams destined for correspondent nodes will appear to emanate from the home network, and it may be more difficult to pinpoint the location of the mobile node. Such mechanisms are all beyond the scope of this document.
他の人に見たいと思っていない機密データを持っているユーザーは、適切な保護を提供するために、このドキュメントの範囲（暗号化など）の外側のメカニズムを使用する必要があります。トラフィック分析に関心のあるユーザーは、リンク暗号化の適切な使用を検討する必要があります。絶対的な場所のプライバシーが必要な場合、モバイルノードはホームエージェントにトンネルを作成できます。次に、特派員ノードに向けられたデータグラムは、ホームネットワークから発せられるように見え、モバイルノードの位置を特定することがより困難になる可能性があります。このようなメカニズムはすべて、このドキュメントの範囲を超えています。
Many routers implement security policies such as "ingress filtering" [35] that do not allow forwarding of packets that have a Source Address that appears topologically incorrect. In environments where this is a problem, mobile nodes may use reverse tunneling [12] with the foreign agent supplied care-of address as the Source Address. Reverse-tunneled packets will be able to pass normally through such routers, while ingress filtering rules will still be able to locate the true topological source of the packet in the same way as packets from non-mobile nodes.
多くのルーターは、「イングレスフィルタリング」[35]などのセキュリティポリシーを実装します。これは、トポロジカルに正しくないように見えるソースアドレスを持つパケットの転送を許可しません。これが問題である環境では、モバイルノードは、外国人エージェントがソースアドレスとして提供された住所を提供する逆トンネリング[12]を使用する場合があります。逆タンネルパケットはそのようなルーターを正常に通過できますが、イングレスフィルタリングルールは、非モバイルノードからのパケットと同じ方法でパケットの真のトポロジカルソースを見つけることができます。
The Identification field is used to let the home agent verify that a registration message has been freshly generated by the mobile node, not replayed by an attacker from some previous registration. Two methods are described in this section: timestamps (mandatory) and "nonces" (optional). All mobile nodes and home agents MUST implement timestamp-based replay protection. These nodes MAY also implement nonce-based replay protection.
識別フィールドは、ホームエージェントが登録メッセージがモバイルノードによって新たに生成されていることを確認できるようにします。このセクションでは、タイムスタンプ（必須）と「nonces」（オプション）の2つの方法について説明します。すべてのモバイルノードとホームエージェントは、タイムスタンプベースのリプレイ保護を実装する必要があります。これらのノードは、NonCeベースのリプレイ保護を実装する場合もあります。
The style of replay protection in effect between a mobile node and its home agent is part of the Mobility Security Association. A mobile node and its home agent MUST agree on which method of replay protection will be used. The interpretation of the Identification field depends on the method of replay protection as described in the subsequent subsections.
モバイルノードとそのホームエージェントの間で有効なリプレイ保護のスタイルは、モビリティセキュリティ協会の一部です。モバイルノードとそのホームエージェントは、どのリプレイ保護方法が使用されるかに同意する必要があります。識別フィールドの解釈は、後続のサブセクションで説明されているように、リプレイ保護の方法に依存します。
Whatever method is used, the low-order 32 bits of the Identification field MUST be copied unchanged from the Registration Request to the Reply. The foreign agent uses those bits (and the mobile node's home address) to match Registration Requests with corresponding replies. The mobile node MUST verify that the low-order 32 bits of any Registration Reply are identical to the bits it sent in the Registration Request.
どんな方法を使用しても、登録リクエストから返信への低次の32ビットの識別フィールドを変更せずにコピーする必要があります。外国人エージェントは、これらのビット（およびモバイルノードのホームアドレス）を使用して、登録要求を対応する返信と一致させます。モバイルノードは、登録返信の低次の32ビットが登録リクエストで送信されたビットと同じであることを確認する必要があります。
The Identification field in a new Registration Request MUST NOT be the same as in an immediately preceding Request, and SHOULD NOT repeat while the same security context is being used between the mobile node and the home agent. Retransmission as in Section 3.6.3 is allowed.
新しい登録要求の識別フィールドは、直前のリクエストと同じではなく、モバイルノードとホームエージェントの間で同じセキュリティコンテキストが使用されている間は繰り返さないでください。セクション3.6.3のように再送信が許可されています。
The basic principle of timestamp replay protection is that the node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day. Unless specified differently in the security association between the nodes, a default value of 7 seconds MAY be used to limit the time difference. This value SHOULD be greater than 3 seconds. Obviously the two nodes must have adequately synchronized time-of-day clocks. As with any messages, time synchronization messages may be protected against tampering by an authentication mechanism determined by the security context between the two nodes.
タイムスタンプリプレイ保護の基本原則は、メッセージを生成するノードが現在の時刻を挿入することであり、メッセージを受信するノードは、このタイムスタンプが自分の時刻に十分に近いことをチェックすることです。ノード間のセキュリティ関連で異なる方法で指定されていない限り、7秒のデフォルト値を使用して時間差を制限できます。この値は3秒を超える必要があります。明らかに、2つのノードには、日時の時計が適切に同期されている必要があります。他のメッセージと同様に、時間同期メッセージは、2つのノード間のセキュリティコンテキストによって決定される認証メカニズムによって改ざんから保護される場合があります。
If timestamps are used, the mobile node MUST set the Identification field to a 64-bit value formatted as specified by the Network Time Protocol [11]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits that are not available from a time source SHOULD be generated from a good source of randomness. Note, however, that when using timestamps, the 64-bit Identification used in a Registration Request from the mobile node MUST be greater than that used in any previous Registration Request, as the home agent uses this value as a sequence number. Without such a sequence number, it would be possible for a delayed duplicate of an earlier Registration Request to arrive at the home agent (within the clock synchronization required by the home agent), and thus be applied out of order, mistakenly altering the mobile node's current registered care-of address.
タイムスタンプを使用する場合、モバイルノードは、ネットワークタイムプロトコル[11]で指定されているように、識別フィールドを64ビット値に設定する必要があります。NTP形式の低次の32ビットは分数秒を表し、時間ソースから利用できないビットは、ランダム性の良いソースから生成する必要があります。ただし、タイムスタンプを使用する場合、モバイルノードからの登録要求で使用される64ビット識別は、ホームエージェントがこの値をシーケンス番号として使用するため、以前の登録要求で使用されたものよりも大きくなければならないことに注意してください。このようなシーケンス番号がなければ、以前の登録要求の遅延の複製がホームエージェント（ホームエージェントが必要とするクロック同期内）に到着し、故障して適用される可能性があり、モバイルノードを誤って変更します現在の登録済み住所。
Upon receipt of a Registration Request with an authorization-enabling extension, the home agent MUST check the Identification field for validity. In order to be valid, the timestamp contained in the Identification field MUST be close enough to the home agent's time-of-day clock, and the timestamp MUST be greater than all previously accepted timestamps for the requesting mobile node. Time tolerances and resynchronization details are specific to a particular Mobility Security Association.
承認を有効にする拡張機能を備えた登録要求を受信すると、ホームエージェントは識別フィールドの有効性を確認する必要があります。有効にするためには、識別フィールドに含まれるタイムスタンプは、ホームエージェントの時刻の時計に十分近くなければならず、タイムスタンプは、要求するモバイルノードの以前に受け入れられたすべてのタイムスタンプよりも大きくなければなりません。タイムトレランスと再同期の詳細は、特定のモビリティセキュリティ関連に固有のものです。
If the timestamp is valid, the home agent copies the entire Identification field into the Registration Reply it returns to the mobile node. If the timestamp is not valid, the home agent copies only the low-order 32 bits into the Registration Reply, and supplies the high-order 32 bits from its own time of day. In this latter case, the home agent MUST reject the registration by returning Code 133 (registration Identification mismatch) in the Registration Reply.
タイムスタンプが有効な場合、ホームエージェントは識別フィールド全体を登録応答にコピーします。モバイルノードに戻ります。タイムスタンプが有効でない場合、ホームエージェントは登録返信に低次の32ビットのみをコピーし、それ自身の時刻から高次の32ビットを提供します。この後者の場合、ホームエージェントは、登録返信でコード133（登録識別の不一致）を返すことにより、登録を拒否する必要があります。
As described in Section 3.6.2.1, the mobile node MUST verify that the low-order 32 bits of the Identification field in the Registration Reply are identical to those in the rejected registration attempt, before using the high-order bits for clock resynchronization.
セクション3.6.2.1で説明されているように、モバイルノードは、登録返信の識別フィールドの低次の32ビットが、クロック再同期に高次ビットを使用する前に、拒否された登録試行のものと同一であることを確認する必要があります。
The basic principle of nonce replay protection is that node A includes a new random number in every message to node B, and checks that node B returns that same number in its next message to node A. Both messages use an authentication code to protect against alteration by an attacker. At the same time, node B can send its own nonces in all messages to node A (to be echoed by node A), so that it too can verify that it is receiving fresh messages.
NonCe Replay Protectionの基本原則は、ノードAにノードBへのすべてのメッセージに新しい乱数が含まれ、ノードBが次のメッセージでその次のメッセージをノードAに返すことをチェックすることです。両方のメッセージは、変更から保護するために認証コードを使用します攻撃者によって。同時に、ノードBはすべてのメッセージで独自のノンセを送信して、ノードA（ノードAでエコーする）に送信できます。これにより、新鮮なメッセージが受信されていることを確認できます。
The home agent may be expected to have resources for computing pseudo-random numbers useful as nonces [8]. It inserts a new nonce as the high-order 32 bits of the Identification field of every Registration Reply. The home agent copies the low-order 32 bits of the Identification field from the Registration Request message into the low-order 32 bits of the Identification field in the Registration Reply. When the mobile node receives an authenticated Registration Reply from the home agent, it saves the high-order 32 bits of the Identification field for use as the high-order 32 bits of its next Registration Request.
ホームエージェントは、ノンセスとして役立つ擬似ランダム数を計算するためのリソースを持っていると予想される場合があります[8]。すべての登録返信の識別フィールドの高次32ビットとして、新しいNONCEを挿入します。ホームエージェントは、登録要求メッセージから識別フィールドの低次の32ビットを、登録返信の識別フィールドの低次の32ビットにコピーします。モバイルノードがホームエージェントから認証された登録返信を受信すると、次の登録リクエストの高次32ビットとして使用するために高次の32ビットの識別フィールドを保存します。
The mobile node is responsible for generating the low-order 32 bits of the Identification field in each Registration Request. Ideally, it should generate its own random nonces. However, it may use any expedient method, including duplication of the random value sent by the home agent. The method chosen is of concern only to the mobile node, because it is the node that checks for valid values in the Registration Reply. The high-order and low-order 32 bit values of the identification chosen SHOULD both differ from their previous values. The home agent uses a new high-order value, and the mobile node uses a new low-order value for each registration message. The foreign agent uses the low-order value (and the mobile host's home address) to correctly match registration replies with pending Requests (Section 3.7.1).
モバイルノードは、各登録要求で識別フィールドの低次の32ビットを生成する責任があります。理想的には、独自のランダムなノンセを生成する必要があります。ただし、ホームエージェントから送信されたランダム値の複製を含む、任意の便利な方法を使用する場合があります。選択された方法は、登録返信で有効な値をチェックするノードであるため、モバイルノードにのみ懸念されます。選択した識別の高次および低次の32ビット値は、両方とも以前の値と異なる必要があります。ホームエージェントは新しい高次値を使用し、モバイルノードは登録メッセージごとに新しい低次値を使用します。外国人エージェントは、低次の値（およびモバイルホストのホームアドレス）を使用して、保留中のリクエストと登録返信を正しく一致させます（セクション3.7.1）。
If a registration message is rejected because of an invalid nonce, the Reply always provides the mobile node with a new nonce to be used in the next registration. Thus, the nonce protocol is self-synchronizing.
無効なNONCEのために登録メッセージが拒否された場合、返信は常にモバイルノードに次の登録で使用される新しいNONCEを提供します。したがって、NonCeプロトコルは自己同期です。
Mobile IP specifies several new number spaces for values to be used in various message fields. These number spaces include the following:
モバイルIPは、さまざまなメッセージフィールドで使用される値のいくつかの新しい数字スペースを指定します。これらの数値スペースには次のものが含まれます。
o Mobile IP message types sent to UDP port 434, as defined in Section 1.8.
o セクション1.8で定義されているように、モバイルIPメッセージタイプはUDPポート434に送信されます。
o types of extensions to Registration Request and Registration Reply messages (see Sections 3.3 and 3.4, and also consult [12], [43], [2], [3], and [7]).
o 登録リクエストと登録の回答メッセージへの拡張機能の種類（セクション3.3および3.4を参照し、[12]、[43]、[2]、[3]、および[7]を参照）。
o values for the code in the Registration Reply message (see Section 3.4, and also consult [12], [43], [2], [3], and [7]).
o 登録返信メッセージのコードの値（セクション3.4を参照し、[12]、[43]、[2]、[3]、および[7]を参照）。
o Mobile IP defines so-called Agent Solicitation and Agent Advertisement messages. These messages are in fact Router Discovery messages [5] augmented with Mobile-IP-specific extensions. Thus, they do not define a new name space, but do define additional Router Discovery extensions as described below in Section 6.2. Also see Section 2.1, and consult [3] and [7].
o モバイルIPは、いわゆるエージェントの勧誘とエージェント広告メッセージを定義します。これらのメッセージは、実際には、モバイルIP固有の拡張機能で拡張されたルーター発見メッセージ[5]です。したがって、それらは新しい名前空間を定義するものではありませんが、セクション6.2で説明するように、追加のルーター発見拡張機能を定義します。セクション2.1も参照し、[3]および[7]を参照してください。
There are additional Mobile IP numbering spaces specified in [3].
[3]で指定された追加のモバイルIP番号のスペースがあります。
Information about assignment of Mobile IP numbers derived from specifications external to this document is given by IANA at http://www.iana.org/protocols. From that URL, see the "Mobile Internet Protocol (IP) Numbers" section.
このドキュメントの外部仕様から派生したモバイルIP番号の割り当てに関する情報は、http://www.iana.org/protocolsでIANAから与えられています。そのURLから、「モバイルインターネットプロトコル（IP）番号」セクションを参照してください。
In this revised specification, a new code value (for the field in the Registration Reply message) is needed within the range typically used for foreign agent messages. This error code is needed to indicate the status "Invalid Home Agent Address". See Section 3.7.2 for details.
この改訂された仕様では、外国のエージェントメッセージに通常使用される範囲内で、新しいコード値（登録返信メッセージのフィールド用）が必要です。このエラーコードは、ステータス「無効なホームエージェントアドレス」を示すために必要です。詳細については、セクション3.7.2を参照してください。
Mobile IP messages are defined to be those that are sent to a message recipient at port 434 (UDP or TCP). The number space for Mobile IP messages is specified in Section 1.8. Approval of new extension numbers is subject to Expert Review, and a specification is required [22]. The currently standardized message types have the following numbers, and are specified in the indicated sections.
モバイルIPメッセージは、ポート434（UDPまたはTCP）のメッセージ受信者に送信されるものであると定義されています。モバイルIPメッセージの番号スペースは、セクション1.8で指定されています。新しい拡張番号の承認は専門家のレビューの対象となり、仕様が必要です[22]。現在標準化されているメッセージタイプには次の数値があり、示されたセクションで指定されています。
Type Name Section
---- -------------------------------------------- ---------
1 Registration Request 3.3
3 Registration Reply 3.4
RFC 1256 defines two ICMP message types, Router Advertisement and Router Solicitation. Mobile IP defines a number space for extensions to Router Advertisement, which could be used by protocols other than Mobile IP. The extension types currently standardized for use with Mobile IP have the following numbers.
RFC 1256は、2つのICMPメッセージタイプ、ルーター広告とルーターの勧誘を定義します。モバイルIPは、モバイルIP以外のプロトコルで使用できるルーター広告への拡張機能の数スペースを定義します。モバイルIPで使用するために現在標準化されている拡張タイプには、次の数字があります。
Type Name Section
---- -------------------------------------------- ---------
0 One-byte Padding 2.1.3
16 Mobility Agent Advertisement 2.1.1
19 Prefix-Lengths 2.1.2
Approval of new extension numbers for use with Mobile IP is subject to Expert Review, and a specification is required [22].
モバイルIPで使用するための新しい拡張番号の承認は、専門家のレビューの対象となり、仕様が必要です[22]。
The Mobile IP messages specified within this document and listed in Sections 1.8 and 6.1 may have extensions. Mobile IP message extensions all share the same number space, even if they are to be applied to different Mobile IP messages. The number space for Mobile IP message extensions is specified within this document. Approval of new extension numbers is subject to Expert Review, and a specification is required [22].
このドキュメント内で指定され、セクション1.8および6.1にリストされているモバイルIPメッセージには、拡張機能がある場合があります。モバイルIPメッセージ拡張機能はすべて、異なるモバイルIPメッセージに適用される場合でも、すべて同じ番号スペースを共有します。モバイルIPメッセージ拡張機能の数値スペースは、このドキュメント内で指定されています。新しい拡張番号の承認は専門家のレビューの対象となり、仕様が必要です[22]。
Type Name Section
---- -------------------------------------------- ---------
0 One-byte Padding
32 Mobile-Home Authentication 3.5.2
33 Mobile-Foreign Authentication 3.5.3
34 Foreign-Home Authentication 3.5.4
The Mobile IP Registration Reply message, specified in Section 3.4, has a Code field. The number space for the Code field values is also specified in Section 3.4. The Code number space is structured according to whether the registration was successful, the foreign agent denied the Registration Request, or the home agent denied the Registration Request, as follows:
セクション3.4で指定されたモバイルIP登録返信メッセージには、コードフィールドがあります。コードフィールド値の数値スペースもセクション3.4で指定されています。コード番号スペースは、登録が成功したかどうか、外国人エージェントが登録要求を拒否したか、ホームエージェントが登録要求を拒否したかどうかに従って構成されています。
+---------+------------------------------------------------------+
| Code #s | Guideline |
+---------+------------------------------------------------------+
| 0-8 | Success Codes |
| | |
| 9-63 | Allocation guidelines not specified in this document |
| | |
| 64-127 | Error Codes from the Foreign Agent |
| | |
| 128-192 | Error Codes from the Home Agent |
| | |
| 193-200 | Error Codes from the Gateway Foreign Agent [29] |
| | |
| 201-255 | Allocation guidelines not specified in this document |
+---------+------------------------------------------------------+
Approval of new code values requires Expert Review [22].
新しいコード値の承認には、専門家のレビューが必要です[22]。
Table 1: Guidelines for Allocation of Code Values
表1：コード値の割り当てに関するガイドライン
Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp and John Ioannidis (JI) (Columbia University), for forming the working group, chairing it, and putting so much effort into its early development. Columbia's early Mobile IP work can be found in [37], [38], [39].
Dan DuchampとJohn Ioannidis（JI）（Columbia University）とともに、Steve Deering（Xerox Parc）と、ワーキンググループを結成し、議長を務め、初期の開発に大いに努力してくれたことに感謝します。コロンビアの初期のモバイルIP作業は、[37]、[38]、[39]にあります。
Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon, Erik Nordmark, Basavaraj Patil, and Phil Roberts for their contributions to the group while performing the duties of chairperson, as well as for their many useful comments.
Kannan Alaggapan、Greg Minshall、Tony Li、Jim Solomon、Erik Nordmark、Basavaraj Patil、およびPhil Robertsにも感謝します。
Thanks to the active members of the Mobile IP Working Group, particularly those who contributed text, including (in alphabetical order)
モバイルIPワーキンググループのアクティブなメンバー、特に（アルファベット順）を含むテキストを貢献した人に感謝します
Ran Atkinson (Naval Research Lab) Samita Chakrabarti (Sun Microsystems) Ken Imboden (Candlestick Networks, Inc.) Dave Johnson (Carnegie Mellon University) Frank Kastenholz (FTP Software) Anders Klemets (KTH) Chip Maguire (KTH) Alison Mankin (ISI) Andrew Myles (Macquarie University) Thomas Narten (IBM) Al Quirt (Bell Northern Research) Yakov Rekhter (IBM) Fumio Teraoka (Sony) Alper Yegin (NTT DoCoMo)
ラン・アトキンソン（海軍研究所）サミタ・チャクラバルティ（SUN Microsystems）Ken Imboden（Candlestick Networks、Inc。）Dave Johnson（Carnegie Mellon University）Frank Kastenholz（FTP Software）Anders Klemets（KTH）Chip Maguire（KTH）Alison Mankin（ISI）Andrew Myles（Macquarie University）Thomas Narten（IBM）Al Quirt（Bell Northern Research）Yakov Rekhter（IBM）Fumio Teraoka（Sony）Alper Yegin（NTT Docomo）
Thanks to Charlie Kunzinger and to Bill Simpson, the editors who produced the first drafts of this document, reflecting the discussions of the working group. Much of the new text in the later revisions preceding RFC 2002 is due to Jim Solomon and Dave Johnson.
Charlie Kunzingerと、ワーキンググループの議論を反映したこのドキュメントの最初のドラフトを作成した編集者であるBill Simpsonに感謝します。2002年のRFCに先行する後の改訂版の新しいテキストの多くは、ジムソロモンとデイブジョンソンによるものです。
Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for their generous support in hosting interim working group meetings.
Greg Minshall（Novell）、Phil Karn（Qualcomm）、Frank Kastenholz（FTP Software）、およびPat Calhoun（Sun Microsystems）に感謝します。
Sections 1.10 and 1.11, which specify new extension formats to be used with aggregatable extension types, were included from a specification document (entitled "Mobile IP Extensions Rationalization (MIER)", which was written by
集計可能な拡張タイプで使用する新しい拡張形式を指定するセクション1.10および1.11は、仕様ドキュメント（「モバイルIPエクステンションRationalization（MIER）」というタイトル）から含まれています。
Mohamed Khalil (Nortel Networks) Raja Narayanan (nVisible Networks) Haseeb Akhtar (Nortel Networks) Emad Qaddoura (Nortel Networks)
Mohamed Khalil（Nortel Networks）Raja Narayanan（Nvisible Networks）Haseeb Akhtar（Nortel Networks）Emad Qaddoura（Nortel Networks）
Thanks to these authors, and also for the additional work on MIER, which was contributed by Basavaraj Patil, Pat Calhoun, Neil Justusson, N. Asokan, and Jouni Malinen.
これらの著者のおかげで、また、Basavaraj Patil、Pat Calhoun、Neil Justusson、N。Asokan、Jouni Malinenによって貢献したMierの追加作業に感謝します。
Thanks to Vijay Devarapalli, who put in many hours to convert the source for this text document into XML format.
このテキストドキュメントのソースをXML形式に変換するために何時間もかかりたVijay Devarapalliに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[3] Perkins、C.、Calhoun、P。、およびJ. Bharatia、「Mobile IPv4 Challenge/Response Extensions（改訂）」、RFC 4721、2007年1月。
[4] Cong, D., Hamlen, M., and C. Perkins, "The Definitions of Managed Objects for IP Mobility Support using SMIv2", RFC 2006, October 1996.
[4] Cong、D.、Hamlen、M。、およびC. Perkins、「SMIV2を使用したIPモビリティサポートの管理オブジェクトの定義」、RFC 2006、1996年10月。
[5] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[5] Deering、S.、ed。、「ICMPルーターディスカバリーメッセージ」、RFC 1256、1991年9月。
[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[6] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[7] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-Specific Extensions", RFC 3115, April 2001.
[7] Dommety、G。およびK. Leung、「モバイルIPベンダー/組織固有の拡張機能」、RFC 3115、2001年4月。
[8] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[8] Eastlake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[9] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[9] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[10] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[10] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[11] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[11] Mills、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様」、RFC 5905、2010年6月。
[12] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[12] Montenegro、G.、ed。、「モバイルIPの逆トンネル、改訂版」、RFC 3024、2001年1月。
[13] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[13] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[14] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[14] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[15] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[16] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[16] Plummer、D。、「イーサネットアドレス解像度プロトコル：またはネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[17] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[17] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[18] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[18] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[19] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[19] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[20] Solomon, J., "Applicability Statement for IP Mobility Support", RFC 2005, October 1996.
[20] Solomon、J。、「IPモビリティサポートの適用声明」、RFC 2005、1996年10月。
[21] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[21] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[22] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[22] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[23] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.
[23] Solomon、J。およびS. Glass、「PPP IPCPのモバイルIPV4構成オプション」、RFC 2290、1998年2月。
[24] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[24] Montenegro、G.、Dawkins、S.、Kojo、M.、Magret、V。、およびN. Vaidya、「Long Thin Networks」、RFC 2757、2000年1月。
[25] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[25] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[26] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[26] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[27] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
[27] Levkowetz、H。およびS. Vaarala、「ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル」、RFC 3519、2003年4月。
[28] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[28] Glass、S。およびM. Chandra、「モバイルIPv4の登録取消」、RFC 3543、2003年8月。
[29] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", RFC 4857, June 2007.
[29] Fogelstroem、E.、Jonsson、A。、およびC. Perkins、「モバイルIPv4地域登録」、RFC 4857、2007年6月。
[30] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, 19(2), March 1989.
[30] Bellovin、S。、「TCP/IPプロトコルスイートのセキュリティ問題」、ACM Computer Communications Review、19（2）、1989年3月。
[31] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[31] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の劣化を緩和することを目的としたプロキシを向上させるパフォーマンス」、RFC 3135、2001年6月。
[32] Caceres, R. and L. Iftode, "Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments", IEEE Journal on Selected Areas in Communication, 13(5):850-857, June 1995.
[32] Caceres、R。およびL. Iftode、「モバイルコンピューティング環境での信頼できる輸送プロトコルのパフォーマンスの向上」、Communicationの選択された領域に関するIEEEジャーナル、13（5）：850-857、1995年6月。
[33] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[33] Dawkins、S.、Montenegro、G.、Kojo、M.、Magret、V。、およびN. Vaidya、「エラーによるリンクのエンドツーエンドのパフォーマンスへの影響」、BCP 50、RFC 3155、2001年8月。
[34] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[34] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[35] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[35] Ferguson、P。and D. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[36] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[36] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[37] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-Based Protocols for Mobile Internetworking", In Proceedings of the SIGCOMM '01 Conference: Communications Architectures and Protocols, pages 235-245, September 1991.
[37] Ioannidis、J.、Duchamp、D。、およびG. Maguire、「モバイルインターネットワーキングのためのIPベースのプロトコル」、Sigcomm '01 Conference：Communication Architectures and Protocols、Pages 235-245、1991年9月。
[38] Ioannidis, J. and G. Maguire, "The Design and Implementation of a Mobile Internetworking Architecture", In Proceedings of the Winter USENIX Technical Conference, pages 489-500, January 1993.
[38] Ioannidis、J。およびG. Maguire、「モバイルインターネットワークアーキテクチャの設計と実装」、1993年1月、489〜500ページの冬のUsenix技術会議の議事録。
[39] Ioannidis, J., "Protocols for Mobile Internetworking", PhD Dissertation - Columbia University in the City of New York, July 1993.
[39] Ioannidis、J。、「モバイルインターネットワークのためのプロトコル」、博士論文 - 1993年7月、ニューヨーク市のコロンビア大学。
[40] Jacobson, V., "Congestion Avoidance and Control", In Proceedings of the SIGCOMM '88 Workshop, ACM SIGCOMM, ACM Press, pages 314-329, August 1998.
[40] Jacobson、V。、「混雑回避と管理」、Sigcomm '88ワークショップ、ACM Sigcomm、ACM Press、1998年8月314〜329ページの議事録。
[41] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[41] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[42] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[42] McGregor、G。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[43] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[43] Montenegro、G。およびV. Gupta、「モバイルIPのSun's Skip Firewalversal」、RFC 2356、1998年6月。
[44] Perkins, C., Ed., "IP Mobility Support", RFC 2002, October 1996.
[44] Perkins、C.、ed。、「IP Mobility Support」、RFC 2002、1996年10月。
[45] Stevens, R., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, Reading, Massachusetts, 1994.
[45] Stevens、R。、「TCP/IP Illustrated、Volume 1：The Protocols」、Addison-Wesley、Reading、Massachusetts、1994。
[46] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[46] Perkins、C。and P. Calhoun、「モバイルIPv4の認証、承認、および会計（AAA）登録キー」、RFC 3957、2005年3月。
[47] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[47] Simpson、W.、ed。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[48] IANA, "Mobile IPv4 Numbers", http://www.iana.org.
[48] IANA、「モバイルIPv4番号」、http：//www.iana.org。
[49] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[49] Postel、J。、「マルチランアドレス解決」、RFC 925、1984年10月。
[50] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3220, January 2002.
[50] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3220、2002年1月。
The mobile node MAY use link-layer mechanisms to decide that its point of attachment has changed. Such indications include the Down/ Testing/Up interface status [41], and changes in cell or administration. The mechanisms will be specific to the particular link-layer technology, and are outside the scope of this document.
モバイルノードは、リンク層メカニズムを使用して、その添付ファイルが変更されたことを決定する場合があります。このような適応症には、ダウン/テスト/アップインターフェイスステータス[41]、および細胞または投与の変化が含まれます。メカニズムは、特定のリンク層技術に固有のものであり、このドキュメントの範囲外です。
The Point-to-Point-Protocol (PPP) [47] and its Internet Protocol Control Protocol (IPCP) [42] negotiate the use of IP addresses.
ポイントツーポイントプロトコル（PPP）[47]およびそのインターネットプロトコル制御プロトコル（IPCP）[42]は、IPアドレスの使用を交渉します。
The mobile node SHOULD first attempt to specify its home address, so that if the mobile node is attaching to its home network, the unrouted link will function correctly. When the home address is not accepted by the peer, but a transient IP address is dynamically assigned to the mobile node, and the mobile node is capable of supporting a co-located care-of address, the mobile node MAY register that address as a co-located care-of address. When the peer specifies its own IP address, that address MUST NOT be assumed to be a foreign agent care-of address or the IP address of a home agent. PPP extensions for Mobile IP have been specified in RFC 2290 [23]. Please consult that document for additional details for how to handle care-of address assignment from PPP in a more efficient manner.
モバイルノードは、最初にホームアドレスを指定しようとする必要があります。そうすれば、モバイルノードがホームネットワークに接続されている場合、Unrotedリンクが正しく機能します。ホームアドレスがピアによって受け入れられないが、一時的なIPアドレスがモバイルノードに動的に割り当てられ、モバイルノードが共同住宅のケアのケアをサポートできる場合、モバイルノードはアドレスを登録することができます。共同主よ、住所。ピアが独自のIPアドレスを指定した場合、そのアドレスは、外国人エージェントのケアオブアドレスまたはホームエージェントのIPアドレスであると想定してはなりません。モバイルIPのPPP拡張機能は、RFC 2290で指定されています[23]。より効率的な方法で、PPPからのアドレスのケアの割り当てを処理する方法については、そのドキュメントを参照してください。
When high-delay (e.g., SATCOM) or low-bandwidth (e.g., High-Frequency Radio) links are in use, some TCP stacks may have insufficiently adaptive (non-standard) retransmission timeouts. There may be spurious retransmission timeouts, even when the link and network are actually operating properly, but just with a high delay because of the medium in use. This can cause an inability to create or maintain TCP connections over such links, and can also cause unneeded retransmissions that consume already scarce bandwidth. Vendors are encouraged to follow the algorithms in RFC 2988 [26] when implementing TCP retransmission timers. Vendors of systems designed for low-bandwidth, high-delay links should consult RFCs 2757 and 2488 [24], [25]. Designers of applications targeted to operate on mobile nodes should be sensitive to the possibility of timer-related difficulties.
High-Delay（SATCOMなど）または低帯域幅（例：高周波無線）リンクが使用されている場合、一部のTCPスタックは、適応性のある（非標準）再送信タイムアウトが不十分な場合があります。リンクとネットワークが実際に適切に動作している場合でも、偽りの再送信タイムアウトがあるかもしれませんが、使用中の媒体のために高い遅延があります。これにより、このようなリンク上でTCP接続を作成または維持できない可能性があり、すでに不足している帯域幅を消費する不要な再送信を引き起こす可能性があります。ベンダーは、TCP再送信タイマーを実装する際に、RFC 2988 [26]のアルゴリズムに従うことをお勧めします。低帯域幅、高遅延リンク向けに設計されたシステムのベンダーは、RFCS 2757および2488 [24]、[25]を参照する必要があります。モバイルノードで動作することを目的としたアプリケーションの設計者は、タイマー関連の困難の可能性に敏感である必要があります。
Mobile nodes often use media that are more likely to introduce errors, effectively causing more packets to be dropped. This introduces a conflict with the mechanisms for congestion management found in modern versions of TCP [40]. Now, when a packet is dropped, the correspondent node's TCP implementation is likely to react as if there were a source of network congestion, and initiate the slow-start mechanisms [40] designed for controlling that problem. However, those mechanisms are inappropriate for overcoming errors introduced by the links themselves, and have the effect of magnifying the discontinuity introduced by the dropped packet. This problem has been analyzed by Caceres, et al. [32]. TCP approaches to the problem of handling errors that might interfere with congestion management are discussed in documents from the PILC working group [31] [33]. While such approaches are beyond the scope of this document, they illustrate that providing performance transparency to mobile nodes involves understanding mechanisms outside the network layer. Problems introduced by higher media error rates also indicate the need to avoid designs that systematically drop packets; such designs might otherwise be considered favorably when making engineering tradeoffs.
モバイルノードは、多くの場合、エラーを導入する可能性が高いメディアを使用し、より多くのパケットを削除する可能性が高くなります。これにより、TCPの現代バージョンに見られる混雑管理のメカニズムとの競合が導入されます[40]。これで、パケットがドロップされると、特派員ノードのTCP実装は、ネットワーク輻輳の原因があるかのように反応する可能性が高く、その問題を制御するために設計されたスロースタートメカニズム[40]を開始します。ただし、これらのメカニズムは、リンク自体によって導入されたエラーを克服するのに不適切であり、ドロップされたパケットによって導入された不連続性を拡大する効果があります。この問題は、Caceres et al。によって分析されています。[32]。混雑管理を妨げる可能性のあるエラーを処理する問題へのTCPアプローチについては、PILCワーキンググループ[31] [33]の文書で説明しています。このようなアプローチはこのドキュメントの範囲を超えていますが、モバイルノードにパフォーマンスの透明性を提供するには、ネットワークレイヤーの外側のメカニズムの理解が含まれることを示しています。より高いメディアエラー率によって導入された問題は、パケットを体系的にドロップするデザインを避ける必要性も示しています。そうでなければ、そのようなデザインは、エンジニアリングのトレードオフを行う際に好意的に考慮されるかもしれません。
This section shows example Registration Requests for several common scenarios.
このセクションは、いくつかの一般的なシナリオの登録要求の例を示しています。
The mobile node receives an Agent Advertisement from a foreign agent and wishes to register with that agent using the advertised foreign agent care-of address. The mobile node wishes only IP-in-IP encapsulation, does not want broadcasts, and does not want simultaneous mobility bindings:
モバイルノードは、外国人エージェントからエージェント広告を受け取り、広告された外国人エージェントのケアオブアドレスを使用してそのエージェントに登録したいと考えています。モバイルノードは、IP-in-IPカプセルのみを希望し、ブロードキャストを必要とせず、同時モビリティバインディングを必要としません。
IP fields:
Source Address = mobile node's home address
Destination Address = copied from the IP source address of the
Agent Advertisement
Time to Live = 1
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=0,D=0,M=0,G=0
Lifetime = the Registration Lifetime copied from the
Mobility Agent Advertisement Extension of the
Router Advertisement message
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = the Care-of Address copied from the
Mobility Agent Advertisement Extension of the
Router Advertisement message
Identification = Network Time Protocol timestamp or Nonce
Extensions:
An authorization-enabling extension (e.g., the Mobile-Home
Authentication Extension)
The mobile node enters a foreign network that contains no foreign agents. The mobile node obtains an address from a DHCP server [34] for use as a co-located care-of address. The mobile node supports all forms of encapsulation (IP-in-IP, minimal encapsulation, and GRE), desires a copy of broadcast datagrams on the home network, and does not want simultaneous mobility bindings:
モバイルノードは、外国のエージェントを含む外国ネットワークに入ります。モバイルノードは、共同配置されたアドレスとして使用するために、DHCPサーバー[34]からアドレスを取得します。モバイルノードは、あらゆる形態のカプセル化（IP-in-IP、最小カプセル化、およびGRE）をサポートし、ホームネットワーク上のブロードキャストデータグラムのコピーを希望し、同時モビリティバインディングを必要としません。
IP fields:
Source Address = care-of address obtained from DHCP server
Destination Address = IP address of home agent
Time to Live = 64
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=1,D=1,M=1,G=1
Lifetime = 1800 (seconds)
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = care-of address obtained from DHCP server
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home Authentication Extension
The mobile node returns home and wishes to deregister all care-of addresses with its home agent:
モバイルノードは家に帰り、ホームエージェントとのすべてのケアのケアを登録したいと考えています。
IP fields:
Source Address = mobile node's home address
Destination Address = IP address of home agent
Time to Live = 1
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=0,D=0,M=0,G=0
Lifetime = 0
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = the mobile node's home address
Identification = Network Time Protocol timestamp or Nonce
Extensions:
An authorization-enabling extension (e.g., the Mobile-Home
Authentication Extension)
Caution is indicated with the use of the Prefix-Lengths Extension over wireless links, due to the irregular coverage areas provided by wireless transmitters. As a result, it is possible that two foreign agents advertising the same prefix might indeed provide different connectivity to prospective mobile nodes. The Prefix-Lengths Extension SHOULD NOT be included in the advertisements sent by agents in such a configuration.
ワイヤレストランスミッターが提供する不規則なカバレッジエリアのため、ワイヤレスリンクでプレフィックス長拡張を使用することで注意が必要です。その結果、同じプレフィックスを宣伝する2人の外国人エージェントが実際に将来のモバイルノードに異なる接続を提供する可能性があります。プレフィックスレングス拡張機能は、このような構成でエージェントから送信された広告に含めないでください。
Foreign agents using different wireless interfaces would have to cooperate using special protocols to provide identical coverage in space, and thus be able to claim to have wireless interfaces situated on the same subnetwork. In the case of wired interfaces, a mobile node disconnecting and subsequently connecting to a new point of attachment may well send in a new Registration Request no matter whether the new advertisement is on the same medium as the last recorded advertisement. And, finally, in areas with dense populations of foreign agents it would seem unwise to require the propagation via routing protocols of the subnet prefixes associated with each individual wireless foreign agent; such a strategy could lead to quick depletion of available space for routing tables, unwarranted increases in the time required for processing routing updates, and longer decision times for route selection if routes (which are almost always unnecessary) are stored for wireless "subnets".
異なるワイヤレスインターフェイスを使用する外国人エージェントは、スペースで同一のカバレッジを提供するために特別なプロトコルを使用して協力する必要があり、したがって、同じサブネットワークにワイヤレスインターフェイスがあると主張することができます。有線インターフェイスの場合、モバイルノードが切断され、その後新しい添付ポイントに接続すると、新しい広告が最後に記録された広告と同じメディアにあるかどうかに関係なく、新しい登録要求をよく送信できます。そして最後に、外国人エージェントの密集した集団のある地域では、個々のワイヤレス外国人エージェントに関連付けられたサブネットプレフィックスのルーティングプロトコルを介して伝播を必要とすることは賢明ではないように思われます。このような戦略は、ルーティングテーブルのために利用可能なスペースの迅速な枯渇、ルーティングの更新の処理に必要な時間の不当な増加、およびルート（ほとんど常に不要な）の場合のルート選択の決定時間が長い場合、ワイヤレスの「サブネット」に保存される可能性があります。
This document specifies revisions to RFC 2002 that are intended to improve interoperability by resolving ambiguities contained in the earlier text. Implementations that perform authentication according to the new more precisely specified algorithm would be interoperable with earlier implementations that did what was originally expected for producing authentication data. That was a major source of non-interoperability before.
このドキュメントは、以前のテキストに含まれるあいまいさを解決することにより、相互運用性を改善することを目的としたRFC 2002の改訂を指定しています。より正確に指定された新しいアルゴリズムに従って認証を実行する実装は、認証データの生成に当初予想されていたことを行った以前の実装と相互運用可能になります。それは以前の非挿入性の主要な原因でした。
However, this specification does have new features that, if used, would cause interoperability problems with older implementations. All features specified in RFC 2002 will work with the new implementations, except for V-J compression [36]. The following list details some of the possible areas of compatibility problems that may be experienced by nodes conforming to this revised specification, when attempting to interoperate with nodes obeying RFC 2002.
ただし、この仕様には、使用すると、古い実装で相互運用性の問題を引き起こす新しい機能があります。RFC 2002で指定されたすべての機能は、V-J圧縮を除き、新しい実装で動作します[36]。次のリストには、RFC 2002に従うノードと相互運用しようとする際に、この修正された仕様に準拠しているノードが経験する可能性のある互換性の問題の可能な領域の一部を詳述しています。
o A client that expects some of the newly mandatory features (like reverse tunneling) from a foreign agent (FA) would still be interoperable as long as it pays attention to the 'T' bit.
o 外国人エージェント（FA）からの新たに必須の機能（逆トンネリングなど）のいくつかを期待するクライアントは、「T」ビットに注意を払う限り相互運用可能です。
o Mobile nodes (MNs) that use the NAI extension to identify themselves would not work with old mobility agents.
o NAI拡張機能を使用して自分自身を識別するモバイルノード（MNS）は、古いモビリティエージェントとは機能しません。
o Mobile nodes that use a zero home address and expect to receive their home address in the Registration Reply would not work with old mobility agents.
o ゼロホームアドレスを使用し、登録返信でホームアドレスを受け取ることを期待するモバイルノードは、古いモビリティエージェントでは機能しません。
o Mobile nodes that attempt to authenticate themselves without using the Mobile-Home authentication extension will be unable to successfully register with their home agent.
o モバイルホーム認証拡張機能を使用せずに自分自身を認証しようとするモバイルノードは、ホームエージェントに正常に登録することができません。
In all of these cases, a robust and well-configured mobile node is very likely to be able to recover if it takes reasonable actions upon receipt of a Registration Reply with an error code indicating the cause for rejection. For instance, if a mobile node sends a Registration Request that is rejected because it contains the wrong kind of authentication extension, then the mobile node could retry the registration with a mobile-home authentication extension, since the foreign agent and/or home agent in this case will not be configured to demand the alternative authentication data.
これらのすべてのケースで、堅牢でよく構成されたモバイルノードは、拒否の原因を示すエラーコードを備えた登録返信を受け取ったときに合理的なアクションをとると回復できる可能性が非常に高くなります。たとえば、モバイルノードが間違った種類の認証拡張機能を含むため拒否される登録リクエストを送信すると、モバイルノードは、外国人エージェントおよび/またはホームエージェントのモバイルホーム認証拡張機能で登録を再試行することができます。このケースは、代替認証データを要求するように構成されていません。
The following revisions to details of the specification in this document were made after RFC 3344 was published. A list of changes from RFC 2002 made during the development of RFC 3344 [21] may be found in the latter document. For items marked with issue numbers, more information is available by consulting the MIP4 mailing list archives.
このドキュメントの仕様の詳細の次の改訂は、RFC 3344が公開された後に行われました。RFC 3344 [21]の開発中に作成されたRFC 2002からの変更のリストは、後者の文書に記載されている場合があります。問題番号が付いたアイテムについては、MIP4メーリングリストアーカイブに相談して詳細情報を入手できます。
o Showed more bit definitions in the Agent Advertisement message structure (see Section 2.1.1). New advertisement bits have been defined by other specification documents, but not reflected in previous publications of this specification; this has led to confusion. Citations for the other specification documents have also been included.
o エージェント広告メッセージ構造でより多くのビット定義を示しました（セクション2.1.1を参照）。新しい広告ビットは他の仕様ドキュメントで定義されていますが、この仕様の以前の出版物には反映されていません。これは混乱をもたらしました。他の仕様文書の引用も含まれています。
o (Issue 6) The behavior of the home agent was changed to avoid mandating error replies to Registration Requests that were invalidated because the foreign agent failed authentication. The intention is to make the home agent more robust against Denial of Service attacks in which the malicious device has no intention of providing a valid Registration Request but only wants to congest traffic on the home network. See Section 3.8.2.1.
o （第6号）ホームエージェントの動作は、外国人エージェントが認証に失敗したために無効になった登録要求に対するエラー返信を義務付けないように変更されました。意図は、悪意のあるデバイスが有効な登録リクエストを提供するつもりはないが、ホームネットワークでの交通量のみを望んでいるサービス拒否攻撃に対して、ホームエージェントをより堅牢にすることです。セクション3.8.2.1を参照してください。
o Due to non-unique assignment of IPv4 addresses in many domains, it is possible for different mobile nodes to have the same home address. If they use the NAI, the foreign agent can still distinguish them. Language was added to Section 3.7.1 and Section 3.7.3.1 to specify that the foreign agent MUST use the NAI to distinguish mobile nodes with the same home address.
o 多くのドメインでのIPv4アドレスの非ユニークな割り当てにより、異なるモバイルノードが同じホームアドレスを持つことが可能です。彼らがNAIを使用している場合、外国人エージェントはまだそれらを区別できます。言語をセクション3.7.1およびセクション3.7.3.1に追加して、外国人エージェントがNAIを使用して同じホームアドレスでモバイルノードを区別する必要があることを指定しました。
o (Issue 45) Specified that a foreign agent MUST NOT apply a Foreign-Home Authentication extension to a mobile node's deregistration request. Also, the foreign agent MUST NOT apply a Foreign-Home Authentication extension unless the Care-of Address in the Registration Request matches an address advertised by the foreign agent.
o （第45号）外国のエージェントは、モバイルノードの登録リクエストに外国在宅認証拡張機能を適用してはならないことを指定しました。また、登録リクエストの住所の世話が外国人エージェントによって宣伝された住所と一致しない限り、外国人エージェントは外国の在宅認証拡張機能を適用してはなりません。
o Specified that the Mobility Security Association to be used by the foreign agent and home agent depends upon values contained in the message data, not the IP headers.
o 外国人エージェントとホームエージェントが使用するモビリティセキュリティ協会は、IPヘッダーではなくメッセージデータに含まれる値に依存することを指定しました。
o (Issues 9, 18) Created a new error code for use by the foreign agent, for the case when the foreign agent does not serve the mobile node as a home agent. Formerly, the foreign agent could use an error Code of 136 for this case.
o （問題9、18）は、外国人エージェントがホームエージェントとしてモバイルノードにサービスを提供しない場合に、外国人エージェントが使用するための新しいエラーコードを作成しました。以前は、外国人エージェントは、このケースに136のエラーコードを使用できます。
o (Issue 17) Specified that, if the home agent cannot support the requested nonzero unicast address in the Home Address field of the Registration Request, then it MUST reject the registration with an error Code of 129. See Section 3.8.3.2.
o （第17号）登録要求のホームアドレスフィールドでホームエージェントが要求された非ゼロユニキャストアドレスをサポートできない場合、登録は129のエラーコードで拒否する必要があることを指定しました。セクション3.8.3.2を参照してください。
o (Issue 19) Specified that multiple authorization-enabling extensions may be present in the Registration Request message, but that the home agent has to (somehow) ensure that all have been checked (see Section 3.8.3.1).
o （第19号）複数の承認を有する拡張機能が登録リクエストメッセージに存在する可能性があるが、ホームエージェントは（どういうわけか）すべてがチェックされていることを確認する必要があることを指定しました（セクション3.8.3.1を参照）。
o (Issue 20) Specified that the foreign agent SHOULD NOT modify any of the fields of the Registration Reply message that are covered by the Mobile-Home Authentication Extension, when it relays the packet to the mobile node.
o （第20号）外国人エージェントは、パケットをモバイルノードにリレーするときに、モバイルホーム認証拡張機能でカバーされている登録返信メッセージのフィールドを変更してはならないことを指定しました。
o (Issue 21) Clarified that the foreign agent removes extensions that do not precede any authorization-enabling extension, not just the Mobile-Home Authentication extension (Section 3.7.3.2).
o （第21号）外国人エージェントは、モバイルホーム認証拡張機能だけでなく、承認を有する拡張機能に先行しない拡張機能を削除することを明らかにしました（セクション3.7.3.2）。
o (Issue 44) Specified that the address advertised by the foreign agent in Agent Advertisements is the care-of address offered on that network interface, not necessarily the address of the network interface (Section 3.7.2.2).
o （第44号）エージェント広告で外国人エージェントによって宣伝されているアドレスは、そのネットワークインターフェイスで提供されるケアオブアドレスであり、必ずしもネットワークインターフェイスのアドレスではないことを指定しました（セクション3.7.2.2）。
o (Issue 45) Clarification in Section 3.7.2.1 that Code 77 can only apply to a Registration Request with nonzero Lifetime.
o （第45号）セクション3.7.2.1の明確化コード77は、ゼロ以外の寿命の登録要求にのみ適用できます。
o Created a new error code for use when a foreign agent can detect that the Home Agent address field is incorrect.
o 外国人エージェントがホームエージェントアドレスフィールドが正しくないことを検出できるときに使用する新しいエラーコードを作成しました。
o Prohibited the use of the Foreign-Home Authorization Extension on deregistration messages.
o Deregistrationメッセージでの外国家承認延長の使用を禁止しました。
o Cleaned up some more wording having to do with authorization-enabling extensions.
o 許可を有する拡張機能に関係して、さらに文言をクリーンアップしました。
o For consistency, changed some wording about copying UDP ports.
o 一貫性のために、UDPポートのコピーに関するいくつかの文言を変更しました。
o Added wording to clearly not disallow dynamically configuring netmask and security information at the mobile node.
o モバイルノードでNetMaskとセキュリティ情報を動的に構成することを明らかに許可しないように文言を追加しました。
o Revamped Changes section.
o 変更された変更セクション。
o Updated citations.
o 更新された引用。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs |Addr Entry Size| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|r|T|U|X|I|reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Extensions :
: .... ...... ...... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP header is followed by the Mobile IP fields shown below:
UDPヘッダーの後に、以下に示すモバイルIPフィールドが続きます。
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 = 1 |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Non-Auth Extensions for HA ... |
| ( variable length ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32 | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont.) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: MN-HA Authenticator ( variable length ) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Non-Auth Extensions for FA .........
: Optional MN-FA Authentication Extension...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP header is followed by the Mobile IP fields shown below:
UDPヘッダーの後に、以下に示すモバイルIPフィールドが続きます。
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 = 3 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional HA Non-Auth Extensions ... |
| ( variable length ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32 | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont.) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: MN-HA Authenticator ( variable length ) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Extensions used by FA.........
: Optional MN-FA Authentication Extension...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Author's Address
著者の連絡先
Charles E. Perkins (editor) WiChorus Inc. 3590 N. 1st Street, Suite 300 San Jose, CA 95134 USA
チャールズE.パーキンス（編集者）ウィチョルス社3590 N. 1st Street、Suite 300 San Jose、CA 95134 USA
EMail: charliep@computer.org