[要約] RFC 3344は、IPv4におけるIPモビリティサポートに関する規格であり、モバイルノードの移動性をサポートするための手法を提供しています。このRFCの目的は、IPv4ネットワーク上でのモバイルノードのシームレスな移動を実現することです。
Network Working Group C. Perkins, Ed.
Request for Comments: 3344 Nokia Research Center
Obsoletes: 3220 August 2002
Category: Standards Track
IP Mobility Support for IPv4
IPv4のIPモビリティサポート
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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データグラムの透明なルーティングを可能にするプロトコルの強化を指定します。各モバイルノードは、インターネットへの現在の添付ポイントに関係なく、常に自宅の住所によって識別されます。自宅から離れている間、モバイルノードはまた、インターネットへの現在の添付ポイントに関する情報を提供する住所にも関連付けられています。プロトコルは、住所のケアをホームエージェントに登録することを規定しています。ホームエージェントは、トンネルを介してモバイルノードに向けられたデータグラムを住所まで送信します。トンネルの端に到着した後、各データグラムはモバイルノードに配信されます。
Contents
コンテンツ
1. Introduction 3
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . 4
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . 5
1.5. New Architectural Entities . . . . . . . . . . . . . . 5
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . 9
1.8. Message Format and Protocol Extensibility . . . . . . . 13
1.9. Type-Length-Value Extension Format for Mobile IP
Extensions . . . . . . . . . . . . . . . . . . . . . 15
1.10. Long Extension Format . . . . . . . . . . . . . . . . . 16
1.11. Short Extension Format . . . . . . . . . . . . . . . . 16
2. Agent Discovery 17
2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . 18
2.1.1. Mobility Agent Advertisement Extension . . . . 20
2.1.2. Prefix-Lengths Extension . . . . . . . . . . . 22
2.1.3. One-byte Padding Extension . . . . . . . . . . 22
2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . 23
2.3. Foreign Agent and Home Agent Considerations . . . . . . 23
2.3.1. Advertised Router Addresses . . . . . . . . . . 24
2.3.2. Sequence Numbers and Rollover Handling . . . . 24
2.4. Mobile Node Considerations . . . . . . . . . . . . . . 25
2.4.1. Registration Required . . . . . . . . . . . . . 26
2.4.2. Move Detection . . . . . . . . . . . . . . . . 26
2.4.3. Returning Home . . . . . . . . . . . . . . . . 27
2.4.4. Sequence Numbers and Rollover Handling . . . . 28
3. Registration 28
3.1. Registration Overview . . . . . . . . . . . . . . . . . 29
3.2. Authentication . . . . . . . . . . . . . . . . . . . . 30
3.3. Registration Request . . . . . . . . . . . . . . . . . 30
3.4. Registration Reply . . . . . . . . . . . . . . . . . . 33
3.5. Registration Extensions . . . . . . . . . . . . . . . . 36
3.5.1. Computing Authentication Extension Values . . . 36
3.5.2. Mobile-Home Authentication Extension . . . . . 37
3.5.3. Mobile-Foreign Authentication Extension . . . . 37
3.5.4. Foreign-Home Authentication Extension . . . . . 38
3.6. Mobile Node Considerations . . . . . . . . . . . . . . 38
3.6.1. Sending Registration Requests . . . . . . . . . 40
3.6.2. Receiving Registration Replies . . . . . . . . 44
3.6.3. Registration Retransmission . . . . . . . . . . 47
3.7. Foreign Agent Considerations . . . . . . . . . . . . . 47
3.7.1. Configuration and Registration Tables . . . . . 48
3.7.2. Receiving Registration Requests . . . . . . . . 49
3.7.3. Receiving Registration Replies . . . . . . . . 52
3.8. Home Agent Considerations . . . . . . . . . . . . . . . 54
3.8.1. Configuration and Registration Tables . . . . . 55
3.8.2. Receiving Registration Requests . . . . . . . . 56
3.8.3. Sending Registration Replies . . . . . . . . . 59
4. Routing Considerations 62
4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . 62
4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . 62
4.2.1. Mobile Node Considerations . . . . . . . . . . 62
4.2.2. Foreign Agent Considerations . . . . . . . . . 63
4.2.3. Home Agent Considerations . . . . . . . . . . . 64
4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . 66
4.4. Multicast Datagram Routing . . . . . . . . . . . . . . 66
4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . 67
4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . 69
5. Security Considerations 73
5.1. Message Authentication Codes . . . . . . . . . . . . . 73
5.2. Areas of Security Concern in this Protocol . . . . . . 73
5.3. Key Management . . . . . . . . . . . . . . . . . . . . 74
5.4. Picking Good Random Numbers . . . . . . . . . . . . . . 74
5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6. Ingress Filtering . . . . . . . . . . . . . . . . . . . 75
5.7. Replay Protection for Registration Requests . . . . . . 75
5.7.1. Replay Protection using Timestamps . . . . . . 75
5.7.2. Replay Protection using Nonces . . . . . . . . 77
6. IANA Considerations 77
6.1. Mobile IP Message Types . . . . . . . . . . . . . . . . 78
6.2. Extensions to RFC 1256 Router Advertisement . . . . . . 78
6.3. Extensions to Mobile IP Registration Messages . . . . . 79
6.4. Code Values for Mobile IP Registration Reply
Messages. . . . . . . . . . . . . . . . . . . . . . 79
7. Acknowledgments 80
A. Patent Issues 82
B. Link-Layer Considerations 82
C. TCP Considerations 83
C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . 83
C.2. TCP Congestion Management . . . . . . . . . . . . . . . 83
D. Example Scenarios 84
D.1. Registering with a Foreign Agent Care-of Address . . . 84
D.2. Registering with a Co-Located Care-of Address . . . . . 84
D.3. Deregistration . . . . . . . . . . . . . . . . . . . . 85
E. Applicability of Prefix-Lengths Extension 86
F. Interoperability Considerations 86
G. Changes since RFC 2002 87
G.1. Major Changes . . . . . . . . . . . . . . . . . . . . . 87
G.2. Minor Changes . . . . . . . . . . . . . . . . . . . . . 89
G.3. Changes since revision 04 of RFC2002bis . . . . . . . . 91
H. Example Messages 92
H.1. Example ICMP Agent Advertisement Message Format . . . . 92
H.2. Example Registration Request Message Format . . . . . . 93
H.3. Example Registration Reply Message Format . . . . . . . 94
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 99
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つを通常採用する必要があります。
a) the node must change its IP address whenever it changes its point of attachment, or
a) ノードは、IPアドレスが添付のポイントを変更するたびに変更する必要があります。
b) host-specific routes must be propagated throughout much of the Internet routing fabric.
b) ホスト固有のルートは、インターネットルーティングファブリックの多くで伝播する必要があります。
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 [33, 32, 34, 43, 8]) are detailed in the appendix section G.
モバイルIPのこの改訂された仕様と元の仕様の間の変更（[33、32、34、43、8]を参照）については、付録セクションGで詳しく説明します。
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 it accommodates node movement 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は1つのイーサネットセグメントから別のイーサネットセグメントへのノードの動きを促進し、イーサネットセグメントからワイヤレス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 which 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 which provides routing services to the mobile node while registered. The foreign agent detunnels and delivers datagrams to the mobile node 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 as 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 [4].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [4]に記載されているように解釈される。
In addition, this document frequently uses the following terms:
さらに、このドキュメントは頻繁に次の用語を使用します。
Authorization-enabling extension
承認を有する拡張機能
An authentication which makes a (registration) message acceptable to the ultimate recipient of the registration message. An authorization-enabling extension MUST contain an 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 [6]).
このドキュメントでは、承認を有する拡張機能のすべての使用は、登録要求メッセージをホームエージェントに受け入れることができる認証拡張機能を参照しています。このドキュメントの外部で指定された追加のプロトコル構造を使用して、モバイルノードがホームエージェントに登録の認証を提供することが可能かもしれません。RFC 2794 [6]）。
Agent Advertisement
エージェント広告
An advertisement message constructed by attaching a special Extension to a router advertisement [10] message.
ルーター広告[10]メッセージに特別な拡張機能を添付して作成された広告メッセージ。
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 which 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 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.
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 which 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プロトコルの操作の大まかな概要を提供します。
- 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.
- モビリティエージェント（つまり、外国人エージェントとホームエージェント）は、エージェント広告メッセージを介して存在感を宣伝しています（セクション2）。モバイルノードは、オプションで、エージェントの勧誘メッセージを介して、ローカルに添付されたモビリティエージェントからのエージェント広告メッセージを募集する場合があります。
- A mobile node receives these Agent Advertisements and determines whether it is on its home network or a foreign network.
- モバイルノードは、これらのエージェント広告を受信し、ホームネットワークまたは外国ネットワーク上にあるかどうかを決定します。
- 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.
- モバイルノードがホームネットワークにあることを検出すると、モビリティサービスなしで動作します。ホームネットワークに他の場所に登録されてから戻ってくる場合、登録要求と登録返信メッセージの交換を通じて、ホームエージェントとのモバイルノードデレギスター。
- 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 [13] (a co-located care-of address).
- モバイルノードが外国ネットワークに移動したことを検出すると、外国ネットワーク上の住所のケアを取得します。住所のケアは、外国人のエージェントの広告（外国人エージェントのケアオブアドレス）から、またはDHCP [13]（共同住所のケア）などの外部割り当てメカニズムから決定できます。
- 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 it, possibly via a foreign agent (Section 3).
- 自宅から離れて動作するモバイルノードは、おそらく外国人エージェントを介して、登録要求と登録返信メッセージの交換を通じて、ホームエージェントとの新しい住所を登録します（セクション3）。
- 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).
- モバイルノードのホームアドレスに送信されたデータグラムは、ホームエージェントによってモバイルノードのケアオブアドレスにホームエージェントによってトンネルされ、トンネルエンドポイント（外国のエージェントまたはモバイルノード自体）、そして最終的に受け取ったホームエージェントによって傍受されます。モバイルノードに配信されます（セクション4.2.3）。
- 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.
- 逆方向には、モバイルノードによって送信されたデータグラムは、通常、標準の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 [13], 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 [13]などのモバイルノードによって一時的なアドレスとして動的に取得される場合があります。また、外国のネットワークにアクセスしてのみ使用するための長期的なアドレスとしてモバイルノードが所有する場合があります。共同配置されたケアオブアドレスとして使用するためにローカル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を参照してください。
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では、モバイルノードは、共同配置されたケアオブアドレスではなく、外国のエージェントケアオブアドレスを使用しています。
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の動作
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 which 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ルーティングメカニズムをバイパスし、基礎となるリンク層パケットをそれぞれのリンク層アドレスにアドレス指定します。モバイルノードに対する外国エージェントの他の配置も、他のメカニズムを使用してこれらのノード間でデータグラムを交換する可能性がありますが、そのような配置はこのドキュメントの範囲を超えています。
If a mobile node is using a co-located care-of address (as described in (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）に記載されているように）、モバイルノードは、このアドレスのネットワークプレフィックスによって識別されるリンクに配置する必要があります。それ以外の場合、住所のケアに導かれるデータグラムは展開できません。
Mobile IP defines a set of new control messages, sent with UDP [37] using well-known port number 434. The following two message types are defined in this document:
モバイルIPは、よく知られているポート番号434を使用してUDP [37]で送信された新しいコントロールメッセージのセットを定義します。次の2つのメッセージタイプは、このドキュメントで定義されています。
1 Registration Request 3 Registration Reply
1登録リクエスト3登録返信
Up-to-date values for the message types for Mobile IP control messages are specified in the most recent "Assigned Numbers" [40].
モバイルIPコントロールメッセージのメッセージタイプの最新の値は、最新の「割り当てられた数字」[40]で指定されています。
In addition, for Agent Discovery, Mobile IP makes use of the existing Router Advertisement and Router Solicitation messages defined for ICMP Router Discovery [10].
さらに、エージェントの発見のために、モバイルIPは、ICMPルーター発見のために定義された既存のルーター広告とルーターの勧誘メッセージを利用しています[10]。
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で使用されます。
- The first set consists of those Extensions which may appear only 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:
- 最初のセットは、モバイルIPコントロールメッセージ（UDPポート番号434に送信されるもの）にのみ表示される可能性のある拡張機能で構成されています。このドキュメントでは、モバイルIPコントロールメッセージに表示される拡張機能に対して次のタイプが定義されています。
32 Mobile-Home Authentication 33 Mobile-Foreign Authentication 34 Foreign-Home Authentication
32 Mobile-Home認証33モバイル外国認証34外FOERNY-HOME認証
- The second set consists of those extensions which may appear only in ICMP Router Discovery messages [10]. In this document, the following Types are defined for Extensions appearing in ICMP Router Discovery messages:
- 2番目のセットは、ICMPルーター発見メッセージにのみ表示される可能性のある拡張機能で構成されています[10]。このドキュメントでは、ICMPルーターディスカバリーメッセージに表示される拡張機能に対して、次のタイプが定義されています。
0 One-byte Padding (encoded with no 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 most recent "Assigned Numbers" [40].
個々の拡張機能については、このドキュメントの後半で別のセクションで詳細に説明されています。これらの拡張型タイプ番号の最新の値は、最新の「割り当てられた数字」[40]で指定されています。
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 not 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 which 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 [35]. In many cases, this may reduce the rate of allocation for new values of the type field.
拡張タイプに追加の構造が利用されない限り、モバイルIPへの新しい開発または追加には、拡張タイプのために利用可能なスペースがなくなる可能性がある非常に多くの新しい拡張機能が必要になる場合があります。この問題を解決するために、2つの新しい拡張構造が提案されています。サブタイプを使用して正確な拡張機能を識別するために、特定のタイプの拡張機能を集約できます。たとえば、一般的な認証キー拡張機能で行われているように[35]。多くの場合、これにより、タイプフィールドの新しい値の割り当て速度が低下する可能性があります。
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 to group related extensions together.
新しい拡張構造は、拡張型型スペースを効率的に使用するため、新しいモバイルIP拡張機能が2つの新しい拡張フォーマットのいずれかに従うことをお勧めします。
The following subsections provide details about three distinct structures for Mobile IP extensions:
次のサブセクションは、モバイルIP拡張機能の3つの異なる構造に関する詳細を提供します。
- The simple extension format - The long extension format - The short extension format
- シンプルな拡張フォーマット - 長い拡張フォーマット - 短い拡張形式
The Type-Length-Value format illustrated in figure 2 is used for extensions which 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 sections 1.10 or 1.11 whenever there may be the possibility to group 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 which carry information more than 256 bytes.
この形式は、256バイト以上の情報を運ぶスキップ不可の拡張機能に適用できます。
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, a 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 which 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 [10] 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 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ルーターの発見[10]をエージェント発見の主要なメカニズムとして拡張します。エージェント広告は、ICMPルーター広告メッセージ（セクション2.1）にモビリティエージェント広告拡張機能を含めることによって形成されます。エージェント勧誘メッセージは、IP 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 B). The procedures described below assume that such link-layer connectivity has already been established.
この機能を既に提供するリンクレイヤーには、エージェント広告とエージェントの勧誘は必要ない場合があります。モバイルノードが将来のエージェントとのリンク層接続を確立する方法は、このドキュメントの範囲外です（ただし、付録Bを参照）。以下に説明する手順は、そのようなリンク層の接続性がすでに確立されていると仮定しています。
No authentication is required for Agent Advertisement and Agent Solicitation messages. They MAY be authenticated using the IP Authentication Header [22], 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認証ヘッダー[22]を使用して認証される場合があります。このドキュメントの範囲外である広告と勧誘メッセージが認証される方法のさらに指定。
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 an 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 which 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 [10], the IP destination address of an multicast Agent Advertisement MUST be either the "all systems on this link" multicast address (224.0.0.1) [11] 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ルーターの発見[10]に指定されているように、マルチキャストエージェント広告のIP宛先アドレスは、「このリンク上のすべてのシステム」マルチキャストアドレス（224.0.0.1）[11]または「限定放送」アドレス（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. 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).
0モビリティエージェントは、一般的なトラフィックを処理します。つまり、モバイルノードに必ずしも関連していないIPデータグラムのルーターとして機能します。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 addrs
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 [10] in order to avoid synchronization and subsequent collisions with other Agent
定期的に送信された場合、エージェント広告が送信される名目間隔は、ICMPヘッダーに与えられた広告寿命の1/3以下でなければなりません。この間隔は、広告された寿命の1/3よりも短い場合があります。これにより、有効なエージェントのリストからエージェントを削除する前に、モバイルノードが3つの連続した広告を逃すことができます。各広告の実際の送信時間は、同期やその後の他のエージェントとの衝突を避けるために、わずかに無作為化する必要があります[10]
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.
他のエージェント（または他のルーターから送信される他のルーター広告）が送信する可能性のある広告。このフィールドには、以下に定義されているモビリティエージェント広告拡張機能内の「登録生涯」フィールドとの関係がないことに注意してください。
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| 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は宣伝されている住所のケアの数を6つ説明します。
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 [34].
m最小限のカプセル化。このエージェントは、最小限のカプセル化を使用するトンネル付きデータグラムの受信を実装します[34]。
G GRE encapsulation. This agent implements receiving tunneled datagrams that use GRE encapsulation [16].
G GREカプセル化。このエージェントは、GREカプセル化を使用するトンネル化されたデータグラムの受信を実装します[16]。
r Sent as zero; ignored on reception. SHOULD NOT be allocated for any other uses.
rはゼロとして送信されました。レセプションで無視されます。他の用途には割り当てられないでください。
T Foreign agent supports reverse tunneling [27].
T外国のエージェントは逆トンネリングをサポートしています[27]。
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」ビットと「H」ビットの少なくとも1つは、送信されたエージェント広告メッセージで設定する必要があります。
When a foreign agent wishes to require registration even from those mobile nodes which 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 E for implementation details about the use of this Extension.
移動したかどうかを判断する際に、モバイルノードでプレフィックスレングス拡張を使用する方法については、セクション2.4.2を参照してください。この拡張機能の使用に関する実装の詳細については、付録Eを参照してください。
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 which cannot be discovered by a link-layer protocol MUST send Agent Advertisements. An agent which 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 [10], except that:
同じ手順、デフォルト、および定数は、ICMPルーターの発見に指定されているエージェント広告メッセージとエージェント勧誘メッセージで使用されます[10]を除きます。
- 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
- モビリティエージェントは、放送またはマルチキャストエージェントの広告を送信するレートを制限する必要があります。広告がかなりの量のネットワーク帯域幅を消費しないように、最大レートを選択する必要があります。
- 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).
- ルーターの勧誘を受信するモビリティエージェントは、IPソースアドレスが隣人のアドレスであることを要求してはなりません（つまり、到着インターフェイス上のルーター自身のアドレスの1つと一致するアドレス、ルーター）。
- a mobility agent MAY be configured to send Agent Advertisements only in response to an Agent Solicitation message.
- モビリティエージェントは、エージェントの勧誘メッセージに応じてのみエージェント広告を送信するように構成できます。
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 4.2.2).
エージェント広告のICMPルーター広告部分には、1つ以上のルーターアドレスが含まれる場合があります。エージェントは、広告に独自のアドレスのみを配置する必要があります。ルーターアドレスに独自のアドレスが表示されるかどうかにかかわらず、外国人エージェントは登録されたモバイルノードから受信したデータグラムをルーティングする必要があります（セクション4.2.2）。
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 [10], 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ルーター勧誘メッセージ[10]で指定されているエージェント勧誘の同じ手順、デフォルト、および定数を使用します。外国人エージェントに接続されている場合は、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 [10].
エージェントを検索している間、モバイルノードは、新しいリンクに移動したという肯定的な兆候を受け取っていない限り、勧誘を送信するレートを上げてはなりません。エージェントに正常に登録した後、モバイルノードは、次に登録する新しいエージェントの検索を開始したときに勧誘が送信されるレートを上げる必要があります。勧誘率の増加は最大速度に戻る可能性がありますが、上記の方法で制限する必要があります。すべての場合において、推奨される勧誘間隔は名目値です。モバイルノードは、ICMPルーターの発見に指定されているように、これらの公称値の周りの勧誘時間をランダム化する必要があります[10]。
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) which 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 a 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 [36], 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 [36]を使用している場合、モバイルノードは、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 reregistration 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登録は、モバイルノードが現在の到達可能性情報をホームエージェントに伝えるための柔軟なメカニズムを提供します。これは、モバイルノードの方法です。
- request forwarding services when visiting a foreign network,
- 外国ネットワークにアクセスするときに転送サービスをリクエストし、
- inform their home agent of their current care-of address,
- 彼らの現在の住所を彼らのホームエージェントに通知し、
- renew a registration which is due to expire, and/or
- 有効期限が切れる予定の登録を更新する、および/または
- deregister when they return home.
- 彼らが家に戻ったときの登録者。
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:
他のいくつかの（オプションの）機能は、登録手順を通じて利用できます。これにより、モバイルノードが次のようになります。
- discover its home address, if the mobile node is not configured with this information.
- この情報でモバイルノードが構成されていない場合は、自宅の住所を発見してください。
- maintain multiple simultaneous registrations, so that a copy of each datagram will be tunneled to each active care-of address
- 複数の同時登録を維持し、各データグラムのコピーが各アクティブなケアオブアドレスにトンネリングされるようになります
- deregister specific care-of addresses while retaining other mobility bindings, and
- 他のモビリティのバインディングを保持しながら、特定のケアのアドレスを免除し、
- discover the address of a home agent if the mobile node is not configured with this information.
- この情報でモバイルノードが構成されていない場合は、ホームエージェントのアドレスを発見してください。
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つの登録手順のどれを決定します。
- If a mobile node is registering a foreign agent care-of address, the mobile node MUST register via that foreign agent.
- モバイルノードが外国のエージェントのケアオブアドレスを登録している場合、モバイルノードはその外国人エージェントを介して登録する必要があります。
- 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.
- モバイルノードが共同配列のケアオブアドレスを使用しており、このアドレスを使用しているリンク上の外国人エージェントからエージェント広告を受け取っている場合、モバイルノードはその外国人エージェントを介して登録する必要があります（またはこのリンク上の別の外国人エージェント）「R」ビットが受信エージェント広告メッセージに設定されている場合。
- If a mobile node is otherwise using a co-located care-of address, the mobile node MUST register directly with its home agent.
- モバイルノードがそれ以外の場合は、共同配置された住所を使用している場合、モバイルノードはホームエージェントに直接登録する必要があります。
- 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.
- モバイルノードがホームネットワークに戻り、ホームエージェントに登録している場合、モバイルノードはホームエージェントに直接登録する必要があります。
Both registration procedures involve the exchange of Registration Request and Registration Reply messages (Sections 3.3 and 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) [37]. 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 which exists between them.
セクション3.3および3.4で定義されている登録メッセージは、ユーザーデータグラムプロトコル（UDP）[37]を使用します。非ゼロ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. UDP fields:
詳細については、セクション3.6.1.1および3.7.2.2を参照してください。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 which 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 [34] for datagrams tunneled to the mobile node.
m最小限のカプセル化。「M」ビットが設定されている場合、モバイルノードは、モバイルノードにトンネルを掲載したデータグラムに対して、ホームエージェントが最小限のカプセル化[34]を使用することを要求します。
G GRE encapsulation. If the 'G' bit is set, the mobile node requests that its home agent use GRE encapsulation [16] for datagrams tunneled to the mobile node.
G GREカプセル化。「g」ビットが設定されている場合、モバイルノードは、モバイルノードにトンネルされたデータグラムに対して、ホームエージェントがGREカプセル化[16]を使用することを要求します。
r Sent as zero; ignored on reception. SHOULD NOT be allocated for any other uses.
rはゼロとして送信されました。レセプションで無視されます。他の用途には割り当てられないでください。
T Reverse Tunneling requested; see [27].
t逆トンネリングが要求されました。[27]を参照してください。
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 returns a Registration Reply message to a mobile node which has sent a Registration Request (Section 3.3) message. If the mobile node is requesting service from a foreign agent, that foreign agent will receive the Reply from the home agent and subsequently relay it to the mobile node. The Reply message contains 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.
モビリティエージェントは、登録リクエスト（セクション3.3）メッセージを送信したモバイルノードに登録返信メッセージを返します。モバイルノードが外国人エージェントからサービスを要求している場合、その外国人エージェントはホームエージェントから返信を受け取り、その後モバイルノードに伝えます。返信メッセージには、元のリクエストよりも小さい場合があるホームエージェントによって付与された生涯とともに、リクエストのステータスについてモバイルノードに通知するために必要なコードが含まれています。
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 which enables authorization by the home agent. Such an extension contains authentication data which 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.1 for complete details.
通常、ソースアドレスは、エージェントが返信している登録要求の宛先アドレスからコピーされます。詳細については、セクション3.7.2.3および3.8.3.1を参照してください。
Destination Address Copied from the source address of the Registration Request to which the agent is replying
エージェントが返信している登録要求のソースアドレスからコピーされた宛先アドレス
UDP fields:
UDPフィールド：
Source Port <variable>
ソースポート<変数>
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エージェントが返したすべての登録返信に認可を有する拡張機能を含める必要があります。メッセージを返信するための拡張機能の配置に関するルールについては、セクション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)
64不特定65管理上禁止66 66不十分なリソース67モバイルノード不足67モバイルノード失敗認証68ホームエージェント失敗認証69リクエストリクエストリクエストリクエストリクエストリクエスト71不十分に形成されたリクエスト71ホームネットワークの到達不能（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 most recent "Assigned Numbers" [40].
コードフィールドの最新の値は、最新の「割り当てられた数字」[40]で指定されています。
The Authenticator value computed for each authentication Extension MUST protect the following fields from the registration message:
各認証拡張機能に対して計算された認証値は、登録メッセージから次のフィールドを保護する必要があります。
- the UDP payload (that is, the Registration Request or Registration Reply data),
- UDPペイロード（つまり、登録要求または登録返信データ）、
- all prior Extensions in their entirety, and
- すべての以前の拡張機能全体、および
- the Type, Length, and SPI of this Extension.
- この拡張機能のタイプ、長さ、およびSPI。
The default authentication algorithm uses HMAC-MD5 [23] to compute a 128-bit "message digest" of the registration message. The data over which the HMAC is computed is defined as:
デフォルトの認証アルゴリズムは、HMAC-MD5 [23]を使用して、登録メッセージの128ビットの「メッセージダイジェスト」を計算します。HMACが計算されるデータは、次のように定義されます。
- the UDP payload (that is, the Registration Request or Registration Reply data),
- UDPペイロード（つまり、登録要求または登録返信データ）、
- all prior Extensions in their entirety, and
- すべての以前の拡張機能全体、および
- the Type, Length, and SPI of this Extension.
- この拡張機能のタイプ、長さ、および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 which is used to compute the Authenticator value and which 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 which 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）を実装する必要があります。
Exactly 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 for registration messages specified in this document. This requirement is intended to eliminate problems [2] which result from the uncontrolled propagation of remote redirects in the Internet. The location of the extension marks the end of the authenticated data.
すべての登録リクエストと、ホームエージェントによって生成されたすべての登録返信に、正確に1つの承認を有する拡張機能が存在する必要があります。モバイルホーム認証拡張機能は、常にこのドキュメントで指定された登録メッセージの許可を有効にすることです。この要件は、インターネット内のリモートリダイレクトの制御されていない伝播に起因する問題[2]を排除することを目的としています。拡張機能の位置は、認証されたデータの終わりを示します。
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.)
Authenticator（変数長）（セクション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.)
Authenticator（変数長）（セクション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. 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.)
Authenticator（変数長）（セクション3.5.1を参照）
A mobile node MUST be configured 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 NAI extension [6] 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拡張機能[6]を使用してそれ自体を識別し、登録要求のホームアドレスフィールドを0.0.0.0に設定することができます。この場合、モバイルノードは、ホームエージェントからの登録返信からこの情報を抽出した後、ホームアドレスを割り当てることができる必要があります。
For each pending registration, the mobile node maintains the following information:
保留中の登録ごとに、モバイルノードは次の情報を維持します。
- the link-layer address of the foreign agent to which the Registration Request was sent, if applicable, - the IP destination address of the Registration Request, - the care-of address used in the registration, - the Identification value sent in the registration, - the originally requested Lifetime, and - the remaining Lifetime of the pending registration.
- 登録要求が送信された外国人エージェントのリンク層アドレス該当する場合、登録要求のIP宛先アドレス、登録で使用されるケアオブアドレス、登録で送信された識別値、 - 元々要求された生涯、および保留中の登録の残りの寿命。
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 D shows some examples of how the fields in registration messages would be set up in some typical registration scenarios.
付録Dは、登録メッセージのフィールドがいくつかの典型的な登録シナリオでどのように設定されるかの例を示しています。
The following sections specify details for the values 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ソースアドレス：
- When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address.
- 共同住民の住所を使用して外国ネットワークに登録する場合、IPソースアドレスはケアオブアドレスでなければなりません。
- Otherwise, if the mobile node does not have a home address, the IP source address MUST be 0.0.0.0.
- それ以外の場合、モバイルノードにホームアドレスがない場合、IPソースアドレスは0.0.0.0でなければなりません。
- In all other circumstances, the IP source address MUST be the mobile node's home address.
- 他のすべての状況では、IPソースアドレスはモバイルノードのホームアドレスでなければなりません。
IP Destination Address:
IP宛先アドレス：
- 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.
- モバイルノードが、エージェントのIPアドレス（エージェントのIPアドレスがモバイルノードには不明）を提供しない何らかの手段（例：リンクレイヤー）を通じて、登録しているエージェントを発見したとき、「すべてのモビリティエージェント」マルチキャストアドレス（224.0.0.11）を使用する必要があります。この場合、モバイルノードは、データグラムを正しいエージェントに配信するために、エージェントのリンク層ユニキャストアドレスを使用する必要があります。
- 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 which 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.
- 外国人エージェントに登録する場合、対応するエージェント広告のIPソースアドレスから学習したエージェントのアドレスを使用する必要があります。これは、エージェント広告に宣伝されている住所として表示されないアドレスかもしれません。さらに、この登録要求メッセージを送信する場合、モバイルノードは、この外国人エージェントのIPアドレスを学習したエージェント広告メッセージのリンク層ソースアドレスからコピーされたリンクレイヤー宛先アドレスを使用する必要があります。
- 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.
- モバイルノードがホームエージェントに直接登録し、ホームエージェントの（ユニキャスト）IPアドレスを知っている場合、宛先アドレスをこのアドレスに設定する必要があります。
- 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.
- モバイルノードがホームエージェントに直接登録しているが、ホームエージェントのIPアドレスがわからない場合、モバイルノードは動的ホームエージェントアドレス解像度を使用してホームエージェントのIPアドレスを自動的に決定できます（セクション3.6.1.2）。この場合、IP宛先アドレスは、モバイルノードのホームネットワークのサブネット指向ブロードキャストアドレスに設定されます。モバイルノードが外国人エージェントを介して登録されている場合、このアドレスは宛先IPアドレスとして使用してはなりませんが、外国人エージェントを介して登録する際に登録要求の本文でホームエージェントアドレスとして使用できます。
IP Time to Live:
ライブのIP時間：
- 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 [38].
- IP宛先アドレスが上記のように「すべてのモビリティエージェント」マルチキャストアドレスに設定されている場合、IP TTLフィールドを1に設定する必要があります。そうしないと、標準のIPプラクティスに従って適切な値を選択する必要があります[38]。
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」ビットによって決定されるように、モバイルノードによって登録されているアドレスのケアの種類によって異なります。
- 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 de-tunnels the received datagram in the same way as any other datagram tunneled directly to it.
- 「d」ビットが設定されている場合、モバイルノードは、このアドレス自体にトンネルされたデータグラムを脱カプセル化することを示しています（モバイルノードは、共同住宅のケアオブアドレスを使用しています）。この場合、このような受信したブロードキャストデータグラムをモバイルノードに転送するには、ホームエージェントはこの住所にそれをトンネルにしなければなりません。モバイルノードは、他のデータグラムが直接トンネリングしたのと同じ方法で、受信したデータグラムを削除します。
- 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.
- 「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:
生涯フィールドは次のように選択されます。
- 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.
- モバイルノードが外国のエージェントに登録している場合、生涯は、外国人エージェントから受け取ったエージェント広告メッセージの登録生涯フィールドの値を超えてはなりません。住所のケアが学習される方法に寿命が含まれていない場合、デフォルトのICMPルーター広告寿命（1800秒）を使用できます。
- 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).
- モバイルノードは、このバインディングのケアオブアドレスで登録リクエストを送信して、ライフタイムフィールドをゼロに設定して、ホームエージェントに特定のモビリティバインディングを削除するように依頼する場合があります（セクション3.8.2）。
- Similarly, a Lifetime of zero is used when the mobile node deregisters all care-of addresses, such as upon returning home.
- 同様に、モバイルノードが帰国後など、すべてのケアのアドレスを装飾する場合、ゼロの寿命が使用されます。
The Home Address field MUST be set to the mobile node's home address, if this information is known. Otherwise, the Home Address 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 following ordering MUST be followed:
このセクションでは、モバイルノードが登録リクエストに追加する必須およびオプションの拡張機能の順序について説明します。次の次の次のとおり、次のようになります。
a) The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by
a) IPヘッダー、続いてUDPヘッダーが続き、その後に登録要求の固定長い部分が続き、その後
b) If present, any non-authentication Extensions expected to be used by the home agent (which may or may not also be useful to the foreign agent), followed by
b) 存在する場合、ホームエージェントが使用することが予想される非認証拡張機能（外国人エージェントにとっても役立つ場合とそうでない場合があります）に続いて
c) An authorization-enabling extension, followed by
c) 承認を有する拡張機能に続いて
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つのカテゴリに分類されます。
- the registration was accepted, - the registration was denied by the foreign agent, or - the registration was denied by the home agent.
- 登録は受け入れられました - 登録は外国人エージェントによって拒否されました、または - 登録はホームエージェントによって拒否されました。
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つのモバイルホーム認証拡張機能が存在する必要があり、モバイルノードは正確に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 which 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, Lifetime too long)
コード69 ：（外国人エージェントによって拒否された、寿命が長すぎる）
In this case, the Lifetime field in the Registration Reply will contain the maximum Lifetime value which that 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, 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 except when relaying a Registration Request received from a mobile node, to the 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 valid (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:
各外国人エージェントは、ケアオブアドレスで構成する必要があります。さらに、保留中または現在の登録ごとに、外国人エージェントは、モバイルノードの登録要求から取得した以下の情報を含む訪問者リストエントリを維持する必要があります。
- the link-layer source address of the mobile node - 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) - the IP Destination Address (as specified in 3.6.1.1) - the UDP Source Port - the Home Agent address - the Identification field - the requested registration Lifetime, and - the remaining Lifetime of the pending or current registration.
- モバイルノードのリンク層ソースアドレス - IPソースアドレス（モバイルノードのホームアドレス）またはその共同住民のケアアドレス（セクション2.1.1の「R」ビットの説明を参照） - IP宛先アドレス（3.6.1.1で指定） - UDPソースポート - ホームエージェントアドレス - 識別フィールド - 要求された登録寿命、および保留中または現在の登録の残りの寿命。
If the mobile node's Home Address is zero in the Registration Request message, then the foreign agent MUST follow the procedures specified in RFC 2794 [6]. 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 Code indicating NONZERO_HOMEADDR_REQD (see [6]).
登録要求メッセージでモバイルノードのホームアドレスがゼロの場合、外国人エージェントはRFC 2794 [6]で指定された手順に従う必要があります。特に、外国人エージェントがモバイルノードのこのようなゼロホームアドレスで保留中の登録要求レコードを管理できない場合、外国人エージェントは、nonzero_homeaddr_reqdを示すコードで登録返信を返す必要があります（[6]を参照）。
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 and 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.
外国人エージェントがモバイルノードからの登録要求を受け入れる場合、指定されたホームエージェントアドレスが外国人エージェントのネットワークインターフェイスに属していないことを確認するためにチェックします。そうでない場合、外国人エージェントは、指定されたホームエージェントにリクエストを中継する必要があります。それ以外の場合、外国人エージェントがリクエストを拒否した場合、外国人エージェントが同じモバイルにそのような拒否を1秒以上送信する必要がある場合を除き、適切な拒否コードでモバイルノードへの登録返信を送信する必要がありますノード。次のセクションでは、この動作についてより詳細に説明します。
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 136 (unknown home agent address).
外国人エージェントが、モバイルノードによって指定されたIPアドレスとホームエージェントアドレスとしてそのネットワークインターフェイスの1つを構成した場合、外国人エージェントは再びリクエストを転送してはなりません。外国人エージェントがモバイルノードをホームエージェントとして提供する場合、外国人エージェントはセクション3.8.2で指定された手順に従います。それ以外の場合、外国人エージェントがモバイルノードをホームエージェントとして提供していない場合、外国人エージェントはコード136（不明なホームエージェントアドレス）で登録要求を拒否します。
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 requests 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, 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:
外国人エージェントがモバイルノードの登録要求を受け入れる場合、登録要求のホームエージェントフィールドで指定されているように、モバイルノードのホームエージェントにリクエストを中継する必要があります。外国人エージェントは、登録要求の固定部分から始まり、モバイルホーム認証拡張機能またはモバイルノードから提供されたその他の認証拡張機能をホームエージェントの許可を有する拡張機能として含めて、フィールドのいずれかを変更してはなりません。そうしないと、認証障害がホームエージェントで発生する可能性が非常に高いです。さらに、外国のエージェントは次のように進行します。
- It MUST process and remove any Extensions following the Mobile-Home Authentication Extension, - It MAY append any of its own non-authentication Extensions of relevance to the home agent, if applicable, and - It MUST append the Foreign-Home Authentication Extension, if the foreign agent shares a mobility security association with the home agent.
- モバイルホーム認証拡張機能に続く拡張機能を処理および削除する必要があります - 該当する場合は、ホームエージェントに関連する独自の非認証拡張機能のいずれかを追加することができます。外国人エージェントは、ホームエージェントとモビリティセキュリティ協会を共有しています。
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 foreign agent's address on the interface from which the message will be sent.
メッセージが送信されるインターフェイス上の外国人エージェントのアドレス。
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 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 which 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 which 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 no such 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.
外国人エージェントが登録返信メッセージを受信した場合、返信に示されているように、同じモバイルノードホームアドレスを使用した保留中の登録リクエストを訪問者リストを検索する必要があります。そのような保留中の要求が見つからない場合、および登録返信がゼロモバイルノードホームアドレスを含む保留中の登録要求に対応しない場合（セクション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 which 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つの値の最小値に設定する必要があります。
- the value specified in the Lifetime field of the Registration Reply, and
- 登録返信の生涯フィールドで指定された値、および
- the foreign agent's own maximum value for allowable registration lifetime.
- 許容可能な登録寿命の外国人エージェント自身の最大値。
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:
さらに、外国人エージェントは次の追加手順を実行する必要があります。
- It MUST process and remove any Extensions following the Mobile-Home Authentication Extension, - It MAY append its own non-authentication Extensions of relevance to the mobile node, if applicable, and - It MUST append the Mobile-Foreign Authentication Extension, if the foreign agent shares a mobility security association with the mobile node.
- モバイルホーム認証拡張機能に続く拡張機能を処理および削除する必要があります - 該当する場合は、モバイルノードに関連する独自の非認証拡張機能を追加する場合があります。エージェントは、モバイルノードとモビリティセキュリティ協会を共有しています。
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:
ホームエージェントがホームエージェントとして機能するモバイルノードからの有効な登録リクエストを受け入れる場合、ホームエージェントは、以下を含むモビリティバインディングリストにこのモバイルノードのエントリを作成または変更する必要があります。
- the mobile node's home address - the mobile node's care-of address - the Identification field from the Registration Reply - the remaining Lifetime of the registration
- モバイルノードのホームアドレス - モバイルノードのケアオブアドレス - 登録返信からの識別フィールド - 登録の残りの寿命
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 [6]. 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.
ホームエージェントは、オプションで、そのモバイルノードから登録リクエストを受信する際に、ホームアドレスをモバイルノードに動的に関連付ける機能を提供する場合があります。ホームアドレスがモバイルノードに割り当てられる方法は、このドキュメントの範囲を超えていますが、[6]を参照してください。ホームエージェントがホームアドレスとモバイルノードとの関連付けを行った後、ホームエージェントはそのホームアドレスを登録返信のホームアドレスフィールドに入れなければなりません。
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. 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.
ホームエージェントは、さまざまな外国人エージェントとのモビリティセキュリティ協会を維持することもできます。外国のエージェントから登録要求を受け取る場合、ホームエージェントが外国人エージェントとモビリティセキュリティ協会を共有する場合、ホームエージェントは、このモビリティセキュリティ協会に基づいて、メッセージの必要な外国在宅認証拡張機能で認証者をチェックする必要があります。同様に、外国人エージェントに登録返信を送信する場合、ホームエージェントが外国人エージェントとモビリティセキュリティ協会を共有している場合、ホームエージェントは、このモビリティセキュリティ協会に基づいて、メッセージに外国在宅認証拡張機能を含める必要があります。
If the home agent accepts an incoming Registration Request, it MUST update its record of the the mobile node's mobility binding(s) and SHOULD send a Registration Reply with a suitable Code. Otherwise (the home agent denies the Request), it SHOULD 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 an authorization-enabling extension, and perform the indicated authentication. Exactly 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. If no authorization-enabling extension is found, or if more than one authorization-enabling 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 131. The home agent MUST then discard the Request and SHOULD log the error as a security exception.
a) ホームエージェントは、承認を有する拡張機能の存在を確認し、指定された認証を実行する必要があります。登録リクエストには、正確に1つの承認を有する拡張機能が存在する必要があります。また、ホームエージェントは、拡張機能の認証因子値を確認するか、セキュリティ協会がある別のエージェントによって認証因子値がチェックされていることを確認する必要があります。承認を有する拡張機能が見つからない場合、または複数の承認を有する拡張機能が見つかった場合、または認証器が無効である場合、ホームエージェントはモバイルノードの登録を拒否し、モバイルノードへの登録返信をコード131で送信する必要があります。その後、ホームエージェントはリクエストを破棄し、セキュリティ例外としてエラーを記録する必要があります。
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. 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, 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認証拡張機能が見つからない場合、または複数の外国在宅認証拡張機能が見つかった場合、または認証機が無効である場合、ホームエージェントはモバイルノードの登録を拒否し、モバイルノードへの登録返信を送信する必要があります。コード132.ホームエージェントは、リクエストを破棄し、セキュリティ例外としてエラーを記録する必要があります。
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 returning 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.
登録要求がセクション3.8.2.1の有効性チェックを満たし、ホームエージェントがリクエストに対応できる場合、ホームエージェントはモバイルノードの要求のためにモビリティバインディングリストを更新する必要があり、モバイルノードへの登録返信を返す必要があります。
In this case, the Reply Code 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.
この場合、返信コードは、ホームエージェントが同時モビリティバインディングをサポートする場合は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:
ホームエージェントは、登録要求のフィールドに基づいて、次のようにモバイルノードのモビリティバインディングの記録を更新します。
- 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.
- 寿命がゼロで、アドレスのケアがモバイルノードのホームアドレスに等しい場合、ホームエージェントは、要求するモバイルノードのモビリティバインディングリストのすべてのエントリを削除します。これは、モバイルノードがホームエージェントがモビリティサービスを提供するのをやめることを要求する方法です。
- 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.
- 寿命がゼロであり、住所のケアがモバイルノードのホームアドレスに等しくない場合、ホームエージェントは、要求するモバイルノードのモビリティバインディングリストから指定されたケアオブアドレスを含むエントリのみを削除します。他のアドレスのケアを含む他のアクティブなエントリは、アクティブのままです。
- 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.
- 寿命がゼロでない場合、ホームエージェントは、モバイルノードのモビリティバインディングリストに要求されたケアのケアを含むエントリを追加します。「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 which 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）登録されているものとは異なる外国のエージェントである可能性があります。ホームエージェントが住所のケアが解除されている外国人エージェントとモビリティセキュリティ協会を共有し、外国人が登録要求を中継したエージェントとは異なる場合、ホームエージェントはさらに外国人エージェントに登録返信を送信することができますその住所の世話は登録されています。ホームエージェントは、外国人エージェントとモビリティセキュリティ協会を共有しない場合、そのような返信を送信してはなりません。返信が送信されない場合、元の生涯が期限切れになると、外国人のエージェントの訪問者リストが自然に期限切れになります。
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 [36], and the Registration Request asks the home agent to create a mobility binding for a mobile node which 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 [36]を実装し、登録リクエストがホームエージェントに、以前はバインディングがなかったモバイルノードのモビリティバインディングを作成するよう求めた場合（モバイルノードは以前は自宅にあると想定されていました）、ホームエージェントは、ARP、プロキシARP、および無償ARPに関して、セクション4.6で説明されている手順に従う必要があります。モバイルノードに以前のモビリティバインディングが既にある場合、ホームエージェントは、セクション4.6で説明されているプロキシARPのルールに従って継続する必要があります。
If the Registration Reply 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 error code 135. Similarly, a home agent may refuse to grant service to mobile nodes which 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 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 Copied from the IP Destination Address of 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アドレスに設定する必要があります。
IP Destination Address Copied from the IP Source Address of the Registration Request.
登録要求のIPソースアドレスからコピーされたIP宛先アドレス。
UDP Source Port Copied from the UDP Destination Port of the Registration Request.
登録要求のUDP宛先ポートからコピーされたUDPソースポート。
UDP Destination Port Copied from the UDP Source Port of the Registration Request.
登録要求のUDPソースポートからコピーされた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 nonzero, it MUST be copied into the Home Address field of the Registration Reply message. 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 [6] for further relevant details in the case where mobile nodes identify themselves using an NAI instead of their IP home address.
登録要求のホームアドレスフィールドがゼロでない場合、登録応答メッセージのホームアドレスフィールドにコピーする必要があります。それ以外の場合は、セクション3.6で指定されているように登録要求のホームアドレスフィールドがゼロの場合、ホームエージェントはモバイルノードのホームアドレスの選択を手配し、登録返信のホームアドレスフィールドに選択したアドレスを挿入する必要がありますメッセージ。[6]は、IPホームアドレスの代わりにNAIを使用してモバイルノードが自分自身を識別する場合の詳細については、[6]を参照してください。
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 [32]. Any mobile node that uses a co-located care-of address MUST support receiving datagrams tunneled using IP in IP encapsulation. Minimal encapsulation [34] and GRE encapsulation [16] are alternate encapsulation methods which 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データグラムをサポートする必要があります[32]。コロアのCare of Addressを使用するモバイルノードは、IPカプセル化のIPを使用してトンネル化されたデータグラムの受信をサポートする必要があります。最小限のカプセル化[34]およびGREカプセル化[16]は、オプションでモビリティエージェントとモバイルノードによってサポートされる可能性のある代替カプセル化方法です。モバイルノードから要求された場合、これらの代替形式のカプセル化の使用は、それ以外の場合は、ホームエージェントの裁量で行われます。
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 [10] is one such method.
ホームネットワークに接続すると、モバイルノードはモビリティサービスのサポートなしで動作します。つまり、他の（固定）ホストまたはルーターと同じ方法で動作します。モバイルノードがホームネットワークに接続したとき、または自宅から離れて共同配置された住所を使用するときにデフォルトのルーターを選択する方法は、このドキュメントの範囲外です。ICMPルーター広告[10]は、そのような方法の1つです。
When registered on a foreign network, the mobile node chooses a default router by the following rules:
外部ネットワークに登録されると、モバイルノードは次のルールでデフォルトのルーターを選択します。
- 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 Agent Advertisement. 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.
- モバイルノードが外国人エージェントのケアオブアドレスを使用して登録されている場合、外国人エージェントを最初のホップルーターとして使用する場合があります。外国人エージェントのMACアドレスは、エージェント広告から学ぶことができます。それ以外の場合、モバイルノードは、そのエージェント広告メッセージのICMPルーター広告部分に宣伝されているルーターアドレスの中からデフォルトのルーターを選択する必要があります。
- 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.
- モバイルノードが共同配置のケアオブアドレスを使用してホームエージェントに直接登録されている場合、モバイルノードは、外部から取得したケアを受信する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.
ホームネットワークから離れている間、モバイルノードは別のインターネットノードのMACアドレスを見つけるためにARPパケットをブロードキャストしてはなりません。したがって、メッセージの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 [27].
各外国人エージェントは、逆トンネリングのための必須機能をサポートする必要があります[27]。
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 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 [32], which allows ICMP error messages returned from the tunnel to correctly be reflected back to the original senders of the tunneled datagrams.
トンネリングに使用できるカプセル化方法については、セクション4.1を参照してください。トンネリングを実装するノードは、「トンネルソフトステート」メカニズム[32]を実装する必要があります。これにより、トンネルから返された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 [27].
ホームエージェントは、セクション5.5で説明されているように、ロケーションプライバシーを維持するためにモバイルノードによって送信された、自分自身に宛てられたパケットを脱カプセル化する必要があります。この機能は、逆トンネリングのサポートにも必要です[27]。
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つをインターセプトした場合、ホームエージェントはデータグラムを調べて、既にカプセル化されているかどうかを確認する必要があります。その場合、そのデータグラムのモバイルノードへの転送には特別なルールが適用されます。
- 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.
- 内側（カプセル化された）宛先アドレスが外側の宛先アドレス（モバイルノード）と同じ場合、ホームエージェントは、カプセル化されたデータグラム（トンネルのソースアドレス）の外側のソースアドレスも調べる必要があります。この外側のソースアドレスがモバイルノードの現在のケアオブアドレスと同じ場合、ホームエージェントは、ルーティングループの可能性を防ぐために静かにそのデータグラムを破棄する必要があります。代わりに、外側のソースアドレスがモバイルノードの現在のアドレスと同じでない場合、ホームエージェントはデータグラムをモバイルノードに転送する必要があります。この場合、データグラムを転送するために、ホームエージェントは、データグラムの再カプセルではなく、外側の宛先アドレスをアドレスのケアに変更するだけです。
- 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).
- それ以外の場合は、（内側の宛先アドレスは外側の宛先アドレスと同じではありません）、ホームエージェントは再びデータグラムをカプセル化する必要があります（ネストされたカプセル化）。新しい外側の宛先アドレスは、モバイルノードのケアオブアドレスに等しい。つまり、ホームエージェントは、他のデータグラムと同じ方法でデータグラム全体をモバイルノードに転送します（すでにカプセル化されているかどうか）。
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 [11] messages. Otherwise, it MAY use its home address.
マルチキャストを受信するには、モバイルノードが2つの方法のいずれかでマルチキャストグループに参加する必要があります。まず、モバイルノードは、訪問されたサブネットの（ローカル）マルチキャストルーターを介してグループに参加できます。このオプションは、訪問されたサブネットにマルチキャストルーターが存在することを前提としています。モバイルノードが共同配置されたアドレスを使用している場合、このアドレスをIGMP [11]メッセージのソースIPアドレスとして使用する必要があります。それ以外の場合は、自宅の住所を使用する場合があります。
Alternatively, a mobile node which wishes to receive multicasts MAY join groups via a bi-directional 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 which 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 which 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 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 intercepts the datagram and tunnels 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 illustrated 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つの方法のいずれかを使用して、特派員ノードのデータグラムを固定ノードにルーティングすることができます。
A home agent MAY be configured to have a permanent registration for the fixed node, that indicates the mobile router's address as the fixed host's care-of address. The mobile router's home agent will usually 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 bi-directional tunnel to its own home agent. This method avoids the need for nested tunneling of datagrams.
あるいは、モバイルルーターは、双方向トンネルを介して独自のホームエージェントへの通常のIPルーティングプロトコルを使用して、モバイルネットワーク全体への接続を宣伝する場合があります。この方法は、データグラムのネストされたトンネルの必要性を回避します。
The use of ARP [36] 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 [36]の使用には、ワイヤレスまたはモバイルノードが関与している場合、正しい操作のための特別なルールが必要です。このセクションで指定された要件は、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つの特別な使用を区別します。
- A Proxy ARP [39] is an ARP Reply sent by one node on behalf of another node which 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 [36], 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.
- プロキシARP [39]は、別のノードに代わって1つのノードから送信されたARP返信です。プロキシARPの送信者は、[36]で説明されているように送信者とターゲットプロトコルアドレスフィールドを逆転させますが、送信者ハードウェアアドレスフィールドに構成されたリンク層アドレス（一般的に、独自）を提供します。返信を受信するノードは、このリンク層アドレスを元のターゲットノードのIPアドレスに関連付け、このターゲットノードの将来のデータグラムをそのリンク層アドレスでノードに送信します。
- 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).
- 無償のARP [45]は、ノードから送信されるARPパケットで、他のノードがARPキャッシュのエントリを更新するために自然に発生します。無償のARPは、ARPリクエストまたはARP応答パケットのいずれかを使用する場合があります。どちらの場合でも、ARP Sender ProtocolアドレスとARPターゲットプロトコルアドレスはどちらも更新するキャッシュエントリのIPアドレスに設定され、ARP Senderハードウェアアドレスは、このキャッシュエントリが必要なリンクレイヤーアドレスに設定されます。更新しました。ARP応答パケットを使用する場合、ターゲットハードウェアアドレスは、このキャッシュエントリを更新するリンク層アドレスにも設定されます（このフィールドは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 [36], 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 [36].
どちらの場合でも、無償のARPの場合、ARPパケットはローカルリンクのローカルブロードキャストパケットとして送信する必要があります。[36]で指定されているように、ARPパケットを受信するノード（要求または返信）は、受信ノードにそのIPアドレスのエントリが既にある場合、ARPパケットの送信者プロトコルとハードウェアアドレスを使用してローカルARPキャッシュを更新する必要があります。ARPキャッシュ。ARPプロトコルのこの要件は、ARP要求パケット、および受信ノード[36]によって送信されるARP要求と一致しないARP応答パケットにも適用されます。
While a mobile node is registered on a foreign network, its home agent uses proxy ARP [39] 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 [39], 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 [39]を使用して、モバイルノードのリンク層アドレスを求めるARPリクエストに返信します。ARP要求を受信するとき、ホームエージェントはリクエストのターゲットIPアドレスを調べる必要があり、このIPアドレスが登録されたモビリティバインディングを持つモバイルノードのホームアドレスと一致する場合、ホームエージェントはARPの返信を送信する必要がありますモバイルノードに代わって。パケットで送信者とターゲットアドレスを交換した後[39]、ホームエージェントは、返信が送信される独自のインターフェイスのリンク層アドレスに送信者リンク層アドレスをパケットに設定する必要があります。
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 its (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 its (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リクエストがモバイルノードが登録しようとしている外国人エージェントによってユニキャストでない限り、ターゲット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:
上記の要件を要約するには、モバイルノードがホームネットワークを離れる場合、次の手順をこの順序で実行する必要があります。
- 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.
- モバイルノードは、おそらく外国人エージェントからエージェント広告を受け取っており、最近ホームエージェントからそれを受け取っていないため、自宅から離れて登録することを決定しました。
- 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.
- 登録要求を送信する前に、モバイルノードは、訪問したネットワークの外国人エージェントと通信するために必要な場合を除き、自宅の住所に対応するリンク層アドレスを要求するARPリクエストの独自の将来の処理を無効にします。
- The mobile node transmits its Registration Request.
- モバイルノードは登録リクエストを送信します。
- 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 (gratuitous nor proxy) is performed by the home agent.
- モバイルノードのホームエージェントが登録リクエストを受信して受け入れると、モバイルノードに代わって無償の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:
モバイルノードが後でホームネットワークに戻る場合、この順序で次の手順を実行する必要があります。
- The mobile node decides to register at home, perhaps because it has received an Agent Advertisement from its home agent.
- モバイルノードは、おそらくホームエージェントからエージェント広告を受け取ったために、自宅で登録することを決定しました。
- 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.
- 登録リクエストを送信する前に、モバイルノードは、ARPリクエストの独自の将来の処理を再確定します。その後、リンクレイヤーアドレスを要求することができます。
- 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.
- モバイルノードは、それ自体に対して無償のARPを実行します。この無償のARPでは、ARP送信者ハードウェアアドレスがモバイルノードのリンクレイヤーアドレスに設定されています。
- The mobile node transmits its Registration Request.
- モバイルノードは登録リクエストを送信します。
- 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 (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.
- モバイルノードのホームエージェントが登録リクエストを受信して受け入れると、プロキシ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 [23], 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 [23]で、キーサイズは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 [41] 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 [41]を含める必要があります。セクション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 [2]. 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.
このドキュメントで説明されている登録プロトコルは、モバイルノードのトラフィックがそのケアオブアドレスにトンネルを取得します。登録が認証されていない場合、このトンネリング機能は大きな脆弱性になる可能性があります。たとえば、モバイル登録プロトコルによって実行されるようなリモートリダイレクトは、認証されていない場合、現在のインターネットのセキュリティ問題であると広く理解されています[2]。さらに、アドレス解像度プロトコル（ARP）は認証されておらず、潜在的に別のホストのトラフィックを盗むために使用できます。「無償のARP」（セクション4.6）の使用は、ARPの使用に関連するすべてのリスクをもたらします。
This specification requires a strong authentication mechanism (keyed MD5) which 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. If nonces are used in connection with replay protection, they must also be selected carefully. Eastlake, et al. [14] provides more information on generating pseudo-random numbers.
認証メカニズムの強度は、認証アルゴリズムの生来の強度、使用されるキーの秘密、使用されるキーの強度、特定の実装の品質など、いくつかの要因に依存します。この仕様には、認証用のキー付きMD5の実装が必要ですが、他の認証アルゴリズムとモードの使用を排除しません。キー付きMD5認証が有用であるためには、128ビットキーは秘密（つまり、認可された当事者のみに知られている）と擬似ランダムの両方でなければなりません。リプレイ保護に関連してNoncesが使用されている場合、それらも慎重に選択する必要があります。イーストレイク他[14]は、擬似ランダム数の生成に関する詳細情報を提供します。
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" [15] that do not allow forwarding of packets that have a Source Address which appears topologically incorrect. In environments where this is a problem, mobile nodes may use reverse tunneling [27] 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.
多くのルーターは、「イングレスフィルタリング」[15]などのセキュリティポリシーを実装しています。これは、トポロジカルに正しくないように見えるソースアドレスを持つパケットの転送を許可しません。これが問題である環境では、モバイルノードは、外国人エージェントがソースアドレスとして提供された住所を提供する逆トンネリング[27]を使用する場合があります。逆トンネル付きパケットはそのようなルーターを正常に通過できますが、イングレスフィルタリングルールは、非モバイルノードからのパケットと同じ方法でパケットの真のトポロジカルソースを見つけることができます。
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 (but see Appendix A).
識別フィールドは、ホームエージェントに、以前の登録から攻撃者によって再生されることなく、モバイルノードによって登録メッセージが新たに生成されたことを確認できるようにします。このセクションでは、タイムスタンプ（必須）と「nonces」（オプション）の2つの方法について説明します。すべてのモバイルノードとホームエージェントは、タイムスタンプベースのリプレイ保護を実装する必要があります。これらのノードは、NonCeベースのリプレイ保護も実装する場合があります（ただし、付録Aを参照）。
The style of replay protection in effect between a mobile node and its home agent is part of the mobile 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 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ビットを変更せずにコピーする必要があります。外国人エージェントは、これらのビット（およびモバイルノードのホームアドレス）を使用して、登録要求を対応する返信と一致させます。モバイルノードは、登録返信の低次の32ビットが登録リクエストで送信されたビットと同じであることを確認する必要があります。
The Identification 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 [26]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits which 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 field also 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.
タイムスタンプを使用する場合、モバイルノードは、ネットワーク時間プロトコル[26]で指定されているように、識別フィールドを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 the Reply 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 (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 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に返すことをチェックすることです。両方のメッセージは、変更から保護するために認証コードを使用します攻撃者によって。同時に、Node Bはすべてのメッセージで独自のNoncesをノードA（ノードAでエコーする）に送信できます。これにより、新鮮なメッセージが受信されていることを確認できます。
The home agent may be expected to have resources for computing pseudo-random numbers useful as nonces [14]. 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 from the Registration Request message into the low-order 32 bits of the Identification 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 for use as the high-order 32 bits of its next Registration Request.
ホームエージェントは、ノンセスとして役立つ擬似ランダム数を計算するためのリソースがあると予想される場合があります[14]。すべての登録返信の識別フィールドの高次32ビットとして、新しいNONCEを挿入します。ホームエージェントは、登録リクエストメッセージからの低次の32ビットの識別を、登録返信の識別の低次の32ビットにコピーします。モバイルノードがホームエージェントから認証された登録返信を受信すると、次の登録リクエストの高次32ビットとして使用するための高次の32ビットを保存します。
The mobile node is responsible for generating the low-order 32 bits of the Identification 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 bits 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は、さまざまなメッセージフィールドで使用される値のいくつかの新しい数値スペースを指定します。これらの数値スペースには、次のものが含まれます。
- Mobile IP message types sent to UDP port 434, as defined in section 1.8.
- セクション1.8で定義されているように、モバイルIPメッセージタイプはUDPポート434に送信されます。
- types of extensions to Registration Request and Registration Reply messages (see sections 3.3 and 3.4, and also consult [27, 29, 6, 7, 12])
- 登録リクエストと登録への拡張機能の種類返信メッセージ（セクション3.3および3.4を参照し、[27、29、6、7、12]も参照）
- values for the Code in the Registration Reply message (see section 3.4, and also consult [27, 29, 6, 7, 12])
- 登録返信メッセージのコードの値（セクション3.4を参照し、[27、29、6、7、12]も参照）
- Mobile IP defines so-called Agent Solicitation and Agent Advertisement messages. These messages are in fact Router Discovery messages [10] 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 [7, 12].
- モバイルIPは、いわゆるエージェントの勧誘とエージェント広告メッセージを定義します。これらのメッセージは、実際には、モバイルIP固有の拡張機能で拡張されたルーター発見メッセージ[10]です。したがって、それらは新しい名前空間を定義するものではありませんが、セクション6.2で説明するように、追加のルーター発見拡張機能を定義します。また、セクション2.1を参照して、[7、12]を参照してください。
There are additional Mobile IP numbering spaces specified in [7].
[7]で指定された追加のモバイルIP番号のスペースがあります。
Information about assignment of mobile-ip numbers derived from specifications external to this document is given by IANA at http://www.iana.org/numbers.html. From that URL, follow the hyperlinks to [M] within the "Directory of General Assigned Numbers", and subsequently to the specific section for "Mobile IP Numbers".
このドキュメントの外部の仕様から派生したモバイルIP番号の割り当てに関する情報は、http://www.iana.org/numbers.htmlでIANAによって提供されています。そのURLから、「一般的な番号のディレクトリ」内のハイパーリンクに従って[M]に従って、そしてその後「モバイルIP番号」の特定のセクションに続きます。
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 [30]. The currently standardized message types have the following numbers, and are specified in the indicated sections.
モバイルIPメッセージは、ポート434（UDPまたはTCP）のメッセージ受信者に送信されるものであると定義されています。モバイルIPメッセージの番号スペースは、セクション1.8で指定されています。新しい拡張番号の承認は専門家のレビューの対象となり、仕様が必要です[30]。現在標準化されているメッセージタイプには次の数値があり、示されたセクションで指定されています。
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 Reference
---- -------------------------------------------- ---------
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 [30].
モバイルIPで使用するための新しい拡張番号の承認は、専門家のレビューの対象となり、仕様が必要です[30]。
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 [30].
このドキュメント内で指定され、セクション1.8および6.1にリストされているモバイルIPメッセージには、拡張機能がある場合があります。モバイルIPメッセージ拡張機能はすべて、異なるモバイルIPメッセージに適用される場合でも、すべて同じ番号スペースを共有します。このドキュメント内で、モバイルIPメッセージ拡張機能の番号スペースが指定されています。新しい拡張番号の承認は専門家のレビューの対象となり、仕様が必要です[30]。
Type Name Reference
---- -------------------------------------------- ---------
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, or whether the foreign agent denied the registration request, or lastly whether the home agent denied the registration request, as follows:
セクション3.4で指定されたモバイルIP登録応答メッセージには、コードフィールドがあります。コードフィールド値の数値スペースもセクション3.4で指定されています。コード番号スペースは、登録が成功したかどうか、または外国人エージェントが登録要求を拒否したかどうか、または最後にホームエージェントが登録要求を拒否したかどうかに従って構成されています。
0-8 Success Codes 9-63 No allocation guidelines currently exist 64-127 Error Codes from the Foreign Agent 128-192 Error Codes from the Home Agent 193-255 No allocation guidelines currently exist
0-8サクセスコード9-63割り当てガイドラインなし現在存在する64-127外国人エージェントからのエラーコード128-192ホームエージェントからのエラーコード193-255
Approval of new Code values requires Expert Review [30].
新しいコード値の承認には、専門家のレビューが必要です[30]。
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 [18, 19, 17].
Dan DuchampとJohn Ioannidis（JI）（Columbia University）とともに、Steve Deering（Xerox Parc）と、ワーキンググループを結成し、議長を務め、初期の開発に大いに努力してくれたことに感謝します。コロンビアの初期のモバイルIP作業は[18、19、17]にあります。
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), and - Fumio Teraoka (Sony). - Alper Yegin (NTT DoCoMo)
- ラン・アトキンソン（海軍研究室）、 - サミタ・チャクラバルティ（サンマイクロシステムズ） - ケン・インボデン（Candlestick Networks、Inc。） - デイブ・ジョンソン（カーネギー・メロン大学）、 - フランク・カステンホルツ（FTPソフトウェア）、 - アンダース・クレメット（kth）、 - チップマグワイア（kth）、 - アリソンマンキン（ISI） - アンドリューマイルズ（マッコーリー大学）、 - トーマスナルテン（IBM） - アルクイア（ベルノーザンリサーチ）、 - ヤコフレクター（IBM）、および - fumio teraoka（ソニー）。-Alper Yegin（ntt docomo）
Thanks to Charlie Kunzinger and to Bill Simpson, the editors who produced the first drafts for 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に感謝します。RFC 2002に先立つ後の改訂版の新しいテキストの多くは、ジムソロモンとデイブジョンソンによるものです。
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 M.Khalil, Nortel Networks - Raja Narayanan, nVisible Networks - Haseeb Akhtar, Nortel Networks - Emad Qaddoura, Nortel Networks
- Mohamed M.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.
これらの著者のおかげで、また、Mierの追加作業に感謝します。Mierは、Basavaraj Patil、Pat Calhoun、Neil Justusson、N。Asokan、Jouni Malinenによって貢献されました。
A. Patent Issues
A.特許問題
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
B. Link-Layer Considerations
B.リンク層の考慮事項
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 [24], 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.
モバイルノードは、リンク層メカニズムを使用して、その添付ファイルが変更されたことを決定する場合があります。このような適応症には、ダウン/テスト/アップインターフェイスステータス[24]、および細胞または投与の変化が含まれます。メカニズムは、特定のリンク層技術に固有のものであり、このドキュメントの範囲外です。
The Point-to-Point-Protocol (PPP) [42] and its Internet Protocol Control Protocol (IPCP) [25], negotiates the use of IP addresses. 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）[42]とそのインターネットプロトコル制御プロトコル（IPCP）[25]は、IPアドレスの使用を交渉します。モバイルノードは、最初にホームアドレスを指定しようとする必要があります。そうすれば、モバイルノードがホームネットワークに接続されている場合、Unrotedリンクが正しく機能します。ホームアドレスがピアによって受け入れられないが、一時的なIPアドレスがモバイルノードに動的に割り当てられ、モバイルノードが共同住宅のケアのケアをサポートできる場合、モバイルノードがアドレスを登録する場合があります。共同主よ、住所。ピアが独自のIPアドレスを指定した場合、そのアドレスは、外国のエージェントのケアオブアドレスまたはホームエージェントのIPアドレスであると想定してはなりません。
PPP extensions for Mobile IP have been specified in RFC 2290 [44]. Please consult that document for additional details for how to handle care-of address assignment from PPP in a more efficient manner.
モバイルIPのPPP拡張機能は、RFC 2290で指定されています[44]。より効率的な方法で、PPPからのアドレスのケアの割り当てを処理する方法については、詳細については、そのドキュメントを参照してください。
C. TCP Considerations
C. TCPの考慮事項
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 which consume already scarce bandwidth. Vendors are encouraged to follow the algorithms in RFC 2988 [31] when implementing TCP retransmission timers. Vendors of systems designed for low-bandwidth, high-delay links should consult RFCs 2757 and 2488 [28, 1]. 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 [31]のアルゴリズムに従うことをお勧めします。低帯域幅、高遅延リンク向けに設計されたシステムのベンダーは、RFCS 2757および2488 [28、1]を参照する必要があります。モバイルノードで動作することを目的としたアプリケーションの設計者は、タイマー関連の困難の可能性に敏感である必要があります。
Mobile nodes often use media which 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 [21]. 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 [21] 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. [5]. TCP approaches to the problem of handling errors that might interfere with congestion management are discussed in documents from the [pilc] working group [3, 9]. 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 which systematically drop packets; such designs might otherwise be considered favorably when making engineering tradeoffs.
モバイルノードは、多くの場合、エラーを導入する可能性が高いメディアを使用し、効果的により多くのパケットをドロップします。これにより、TCPの現代バージョンに見られる混雑管理のメカニズムとの対立が導入されます[21]。これで、パケットがドロップされると、特派員ノードのTCP実装は、ネットワーク輻輳の原因があるかのように反応する可能性が高く、その問題を制御するために設計されたスロースタートメカニズム[21]を開始します。ただし、これらのメカニズムは、リンク自体によって導入されたエラーを克服するのに不適切であり、ドロップされたパケットによって導入された不連続性を拡大する効果があります。この問題は、Caceres et al。によって分析されています。[5]。輻輳管理を妨げる可能性のあるエラーを処理する問題へのTCPアプローチについては、[PILC]ワーキンググループ[3、9]の文書で説明されています。このようなアプローチはこのドキュメントの範囲を超えていますが、モバイルノードにパフォーマンスの透明性を提供するには、ネットワークレイヤーの外側のメカニズムの理解が含まれることを示しています。メディアエラー率が高いことによって導入された問題は、パケットを体系的にドロップするデザインを避ける必要性も示しています。そうでなければ、このようなデザインは、エンジニアリングのトレードオフを行う際に好意的に見なされる可能性があります。
D. Example Scenarios
D.例のシナリオ
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 [13] 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サーバー[13]からアドレスを取得して、共同配置されたアドレスとして使用します。モバイルノードは、あらゆる形態のカプセル化（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)
拡張機能：承認を有する拡張機能（モバイルホーム認証拡張機能など）
E. Applicability of Prefix-Lengths Extension
E.プレフィックスレングス拡張の適用性
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".
異なるワイヤレスインターフェイスを使用する外国人エージェントは、特別なプロトコルを使用して宇宙で同一のカバレッジを提供する必要があるため、同じサブネットワーク上にワイヤレスインターフェイスがあると主張することができます。有線インターフェイスの場合、モバイルノードが切断され、その後新しい添付ポイントに接続されている場合、新しい広告が最後に記録された広告と同じメディアにあるかどうかに関係なく、新しい登録要求を送信する場合があります。そして最後に、外国人エージェントの密集した集団のある地域では、個々のワイヤレス外国人エージェントに関連付けられたサブネットプレフィックスのルーティングプロトコルを介して伝播を必要とすることは賢明ではないように思われます。このような戦略は、ルーティングテーブルのために利用可能なスペースの迅速な枯渇、ルーティングの更新の処理に必要な時間の不当な増加、およびルート（ほとんど常に不要な）の場合のルート選択の決定時間が長くなり、ワイヤレスの「サブネット」に保存される可能性があります。
F. Interoperability Considerations
F.相互運用性の考慮事項
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 [20]. 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圧縮を除き、新しい実装で動作します[20]。次のリストには、RFC 2002に従うノードと相互運用しようとする際に、この改訂された仕様に準拠したノードが経験する可能性のある互換性の問題の可能な領域の一部を詳述しています。
- A client that expects some of the newly mandatory features (like reverse tunneling) from a foreign agent would still be interoperable as long as it pays attention to the `T' bit.
- 外国のエージェントからの新たに必須の機能（逆トンネリングなど）の一部が「T」ビットに注意を払う限り、相互運用可能なクライアントがいます。
- Mobile nodes that use the NAI extension to identify themselves would not work with old mobility agents.
- NAI拡張機能を使用して自分自身を識別するモバイルノードは、古いモビリティエージェントとは機能しません。
- 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.
- ゼロホームアドレスを使用し、登録返信でホームアドレスを受け取ることを期待するモバイルノードは、古いモビリティエージェントでは機能しません。
- Mobile nodes that attempt to authenticate themselves without using the Mobile-Home authentication extension will be unable to successful register with their home agent.
- モバイルホーム認証拡張機能を使用せずに自分自身を認証しようとするモバイルノードは、ホームエージェントに登録することができません。
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.
これらのすべてのケースで、堅牢でよく構成されたモバイルノードは、拒否の原因を示すエラーコードを備えた登録返信を受け取ったときに合理的なアクションをとると回復できる可能性が非常に高くなります。たとえば、モバイルノードが間違った種類の認証拡張機能を含むため拒否される登録リクエストを送信した場合、モバイルノードは、外国人エージェントおよび/またはホームエージェントのモバイルホーム認証拡張機能で登録を再試行することができます。このケースは、代替認証データを要求するように構成されていません。
G. Changes since RFC 2002
G. RFC 2002以降の変更
This section details differences between the original Mobile IP base specification (RFC 2002 and ff.) that have been made as part of this revised protocol specification for Mobile IP.
このセクションでは、モバイルIPのこの改訂されたプロトコル仕様の一部として作成された元のモバイルIPベース仕様（RFC 2002およびFF。）の違いを詳しく説明しています。
- Specification for Destination IP address of Registration Reply transmitted from Foreign Agent, to avoid any possible transmission to IP address 0.0.0.0.
- 登録の宛先IPアドレスの仕様外国人エージェントから送信された返信。
- Specification of two new formats for Mobile IP extensions, according to the ideas contained in MIER.
- Mierに含まれるアイデアによると、モバイルIP拡張機能の2つの新しい形式の指定。
- Specification that the SPI of the MN-HA authentication extension is to be used as part of the data over which the authentication algorithm must be computed.
- MN-HA認証拡張のSPIを、認証アルゴリズムを計算する必要があるデータの一部として使用されることを指定します。
- Eliminated Van-Jacobson Compression feature
- van-jacobson圧縮機能を排除しました
- Specification that foreign agents MAY send advertisements at a rate faster than once per second, but chosen so that the advertisements do not burden the capacity of the local link. For simplicity, the foreign agent now MAY send advertisements at an interval less than 1/3 the advertised ICMP Lifetime.
- 外国人エージェントが1秒あたり1回よりも速いレートで広告を送信することができるが、広告がローカルリンクの能力に負担をかけないように選択されることを指定します。簡単にするために、外国人エージェントは、広告のICMPライフタイムの1/3未満の間隔で広告を送信することができます。
- Specification that foreign agents SHOULD support reverse tunneling, and home agents MUST support decapsulation of reverse tunnels.
- 外国人エージェントが逆トンネリングをサポートする必要があり、ホームエージェントは逆トンネルの脱カプセル化をサポートする必要があることを指定します。
- Changed the preconfiguration requirements in section 3.6 for the mobile node to reflect the capability, specified in RFC 2794 [6], for the mobile node to identify itself by using its NAI, and then getting a home address from the Registration Reply.
- モバイルノードのセクション3.6の事前設定要件を変更して、RFC 2794 [6]で指定された機能を反映して、NAIを使用して自分自身を識別し、登録返信から自宅の住所を取得することで自分自身を識別しました。
- Changed section 3.7.3.1 so that a foreign agent is not required to discard Registration Replies that have a Home Address field that does not match any pending Registration Request.
- セクション3.7.3.1を変更したため、外国人エージェントは、保留中の登録要求と一致しないホームアドレスフィールドを持つ登録返信を破棄する必要がないようにしました。
- Allowed registrations to be authenticated by use of a security association between the mobile node and a suitable authentication entity acceptable to the home agent. Defined "Authorization-enabling Extension" to be an authentication extension that makes a registration message acceptable to the recipient. This is needed according to specification in [6].
- モバイルノードとホームエージェントに受け入れられる適切な認証エンティティとの間のセキュリティアソシエーションを使用することにより、登録を認証することを許可されました。登録メッセージを受信者に受け入れられるようにする認証拡張機能となる「認証承認拡張機能」を定義しました。これは、[6]の仕様に従って必要です。
- Mandated that HMAC-MD5 be used instead of the "prefix+suffix" mode of MD5 as originally mandated in RFC 2002.
- RFC 2002で当初義務付けられているように、MD5の「プレフィックス接尾辞」モードの代わりにHMAC-MD5を使用することが義務付けられています。
- Specified that the mobile node SHOULD take the first care-of address in a list offered by a foreign agent, and MAY try each subsequent advertised address in turn if the attempted registrations are rejected by the foreign agent
- モバイルノードは、外国人エージェントが提供するリストの最初のケアアドレスを取得する必要があることを指定し、試行された登録が外国人エージェントによって拒否された場合、後続の各宣伝アドレスを順番に試すことができることを指定しました
- Clarification that a mobility agent SHOULD only put its own addresses into the initial (i.e., not mobility-related) list of routers in the mobility advertisement. RFC 2002 suggests that a mobility agent might advertise other default routers.
- モビリティエージェントは、モビリティ広告のルーターの初期（つまり、モビリティ関連の）リストにのみ独自のアドレスを配置する必要があることを明確にします。RFC 2002は、モビリティエージェントが他のデフォルトルーターを宣伝する可能性があることを示唆しています。
- Specification that 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. Furthermore, foreign agents can set the `R' bit to make sure that new bits are handled by themselves instead of some legacy mobility agent.
- このような広告を破棄するのではなく、モバイルノードがエージェント広告の予約ビットを無視する必要があることを指定します。このようにして、新たに定義されたビットが理解されていない場合でも、モバイルノードが広告を使用する機能に影響を与えることなく、新しいビットを後で定義できます。さらに、外国人のエージェントは「r」ビットを設定して、レガシーモビリティエージェントの代わりに新しいビットが自分で処理されることを確認できます。
- Specification that the foreign agent checks to make sure that the indicated home agent address does not belong to any of its network interfaces before relaying a Registration Request. If the check fails, and the foreign agent is not the mobile node's home agent, then the foreign agent rejects the request with code 136 (unknown home agent address).
- 指定されたホームエージェントアドレスが登録リクエストを中継する前に、指定されたホームエージェントアドレスがネットワークインターフェイスのいずれにも属していないことを確認するために、外国人エージェントがチェックすること。チェックが失敗し、外国人エージェントがモバイルノードのホームエージェントではない場合、外国人エージェントはコード136（不明なホームエージェントアドレス）でリクエストを拒否します。
- Specification that, 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アドレスを取得するための不特定のメカニズムがない場合、モバイルノードは、外国ネットワーク上の他のルーターへのリダイレクトを無視する必要があります。
- Specification that 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.
- 外国人エージェントは、外国ネットワーク上のモバイルノードのMACアドレスにブロードキャストARPを使用しないでください。エージェントの勧誘またはモバイルノードから送信された登録リクエストから情報をコピーすることにより、MACアドレスを取得できます。
- Specification that 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 to the mobile node's IP address.
- モバイルノードのIPアドレスの外国エージェントのARPキャッシュは、モバイルノードのIPに関連付けられたMacアドレスを更新するために外国人エージェントがブロードキャストARP以外に何らかの方法を持っている場合を除き、モバイルノードの訪問者リストエントリが期限切れになる前に有効期限を切ることを許可されてはならないことの仕様住所。
- At the end of section 4.6, clarified that a home agent MUST NOT make any changes to the way it performs proxy ARP after it rejects an invalid deregistration request.
- セクション4.6の終わりに、ホームエージェントは、無効な登録要求を拒否した後、プロキシARPの実行方法に変更を加えてはならないことを明らかにしました。
- In section 4.2.3, specification that multihomed home agents MUST use the the address sent to the mobile node in the home agent field of the registration reply as the source address in the outer IP header of the encapsulated datagram.
- セクション4.2.3では、マルチホームのホームエージェントが、カプセル化されたデータグラムの外側IPヘッダーのソースアドレスとして、登録応答のホームエージェントフィールドに送信されたアドレスを使用する必要があることを指定します。
- Inserted 'T' bit into its proper place in the Registration Request message format (section 3.3).
- 登録要求メッセージ形式（セクション3.3）の適切な場所に「t」ビットを挿入しました。
- Allowed registration replies to be processed by the mobile node, even in the absence of any Mobile-Home Authentication extension, when containing rejection code by the foreign agent.
- 外国人エージェントによる拒否コードを含む場合でも、モバイルホーム認証拡張機能がない場合でも、モバイルノードによって登録応答を処理することができます。
- Specification that 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（登録タイムアウト）でリクエストを拒否する必要があります。
- Relaxation of the requirement that, when a mobile node has joined a multicast group at the router on the foreign network, the mobile node MUST use its home address as the source IP address for multicast packets,
- モバイルノードが外部ネットワーク上のルーターでマルチキャストグループに結合した場合、モバイルノードはマルチキャストパケットのソースIPアドレスとしてホームアドレスを使用する必要があるという要件の緩和
- Clarification that a mobility agent MAY use different settings for each of the 'R', 'H', and 'F' bits on different network interfaces.
- モビリティエージェントは、異なるネットワークインターフェイスで「R」、「H」、および「F」ビットごとに異なる設定を使用できることを明確にします。
- Replacement of the terminology "recursive tunneling" by the terminology "nested tunneling".
- 用語「ネストされたトンネリング」による用語「再帰トンネル」の置き換え。
- Specification that the mobile node MAY use the IP source address of an agent advertisement as its default router address.
- モバイルノードがエージェント広告のIPソースアドレスをデフォルトのルーターアドレスとして使用できることを指定します。
- Clarification that keys with arbitrary binary values MUST be supported as part of mobility security associations.
- 任意のバイナリ値を持つキーをモビリティセキュリティ協会の一部としてサポートする必要があるという明確化。
- Specification that the default value may be chosen as 7 seconds, for allowable time skews between a home agent and mobile node using timestamps for replay protection. Further specification that this value SHOULD be greater than 3 seconds.
- リプレイ保護のためにタイムスタンプを使用して、ホームエージェントとモバイルノードの間の許容時間スキューに対して、デフォルト値が7秒として選択される可能性があることを指定します。この値は3秒以上であることをさらに指定します。
- Specification that Registration Requests with the 'D' bit set to 0, and specifying a care-of address not offered by the foreign agent, MUST be rejected with code 77 (invalid care-of address).
- 「D」ビットが0に設定された登録要求の仕様、および外国人エージェントが提供しない住所のケアを指定することは、コード77（無効なアドレスのケア）で拒否する必要があります。
- Clarification that the foreign agent SHOULD consider its own maximum value when handling the Lifetime field of the Registration Reply.
- 登録返信の生涯フィールドを処理する際に、外国人エージェントが独自の最大値を考慮する必要があることを明確にします。
- Clarification that the home agent MUST ignore the 'B' bit (as opposed to rejecting the Registration Request) if it does not support broadcasts.
- ホームエージェントは、放送をサポートしていない場合、「登録要求を拒否するのではなく）「B」ビットを無視しなければならないという明確化。
- Advice about the impossibility of using dynamic home agent discovery in the case when 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.
- ダイナミックホームエージェントディスカバリーを使用することは、ルーターがサブネット指向のブロードキャストアドレスからデータグラムのIP宛先アドレスを255.255.255.255に変更してから、宛先サブネットに注入する場合の場合に不可能です。
- Clarified that when an Agent Advertisement is unicast to a mobile node, the specific IP home address of a mobile node MAY be used as the destination IP address.
- エージェント広告がモバイルノードのユニキャストである場合、モバイルノードの特定のIPホームアドレスが宛先IPアドレスとして使用できることを明らかにしました。
- Included a reference to RFC 2290 within appendix B, which deals with PPP operation.
- PPP操作を扱う付録BにRFC 2290への参照が含まれています。
- Created IANA Considerations section
- 作成されたIANAの考慮事項セクション
- In section 3.8.3, clarified that a home agent SHOULD arrange the selection of a home address for a mobile node when the Registration Reply contains a zero Home Address.
- セクション3.8.3では、登録返信にゼロホームアドレスが含まれている場合、ホームエージェントがモバイルノードのホームアドレスの選択を手配する必要があることを明らかにしました。
This section lists the changes between this version (...-06.txt) and the previous version (...-04.txt) of the document. This section can be deleted by the RFC editor.
このセクションには、このバージョン（...- 06.txt）とドキュメントの以前のバージョン（...- 04.txt）の間の変更をリストします。このセクションは、RFCエディターによって削除できます。
- Noted that HMAC-MD5 should be considered for use in place of the "prefix+suffix" mode of MD5 as originally mandated in RFC 2002.
- HMAC-MD5は、RFC 2002で当初義務付けられているように、MD5の「プレフィックス接尾辞」モードの代わりに使用することを検討する必要があることに注意してください。
- Included a reference to RFC 2290 within appendix B, which deals with PPP operation.
- PPP操作を扱う付録BにRFC 2290への参照が含まれています。
- Revamped IANA Considerations section
- IANAの考慮事項の改良セクション
- Revamped Changes section
- 変更された変更セクション
- Replaced Patents section with wording mandated from RFC 2026.
- RFC 2026から義務付けられた文言に特許セクションを置き換えました。
- Updated citations.
- 更新された引用。
H. Example Messages
H.メッセージの例
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| 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
References
参考文献
[1] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[1] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. ACM Computer Communications Review, 19(2), March 1989.
[2] S. M.ベロビン。TCP/IPプロトコルスイートのセキュリティ問題。ACM Computer Communications Review、19（2）、1989年3月。
[3] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies", RFC 3135, June 2001.
[3] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「パフォーマンス向上プロキシ」、RFC 3135、2001年6月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Ramon Caceres and Liviu Iftode. Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments. IEEE Journal on Selected Areas in Communications, 13(5):850-- 857, June 1995.
[5] ラモンカセレスとliviu iftode。モバイルコンピューティング環境での信頼できる輸送プロトコルのパフォーマンスを向上させます。Communicationsの選択された領域に関するIEEEジャーナル、13（5）：850--857、1995年6月。
[6] Calhoun P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, January 2000.
[6] Calhoun P.およびC. Perkins、「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年1月。
[7] Calhoun, P. and C. Perkins, "Mobile IP Foreign Agent Challenge/Response Extension", RFC 3012, December 2000.
[7] Calhoun、P。and C. Perkins、「モバイルIP外国エージェントチャレンジ/応答拡張」、RFC 3012、2000年12月。
[8] Cong, D., Hamlen, M. and C. Perkins, "The Definitions of Managed Objects for IP Mobility Support using SMIv2", RFC 2006, October 1996.
[8] Cong、D.、Hamlen、M。、およびC. Perkins、「SMIV2を使用したIPモビリティサポートの管理オブジェクトの定義」、RFC 2006、1996年10月。
[9] 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.
[9] Dawkins、S.、Montenegro、G.、Kojo、M.、Magret、V。およびN. Vaidya、「エラーとリンクのエンドツーエンドのパフォーマンスへの影響」、BCP 50、RFC 3155、2001年8月。
[10] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[10] Deering、S。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[11] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[11] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[12] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-Specific Extensions", RFC 3115, April 2001.
[12] Dommety、G。およびK. Leung、「モバイルIPベンダー/組織固有の拡張機能」、RFC 3115、2001年4月。
[13] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[13] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[14] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[14] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[15] 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.
[15] Ferguson P.およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[16] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[16] Hanks、S.、Li、T.、Farinacci、D。およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 1701、1994年10月。
[17] J. Ioannidis. Protocols for Mobile Internetworking. PhD Dissertation - Columbia University in the City of New York, July 1993.
[17] J. Ioannidis。モバイルインターネットワークのプロトコル。博士論文 - 1993年7月、ニューヨーク市のコロンビア大学。
[18] John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr. IP-Based Protocols for Mobile Internetworking. In Proceedings of the SIGCOMM '91 Conference: Communications Architectures & Protocols, pages 235--245, September 1991.
[18] John Ioannidis、Dan Duchamp、およびGerald Q. Maguire Jr.モバイルインターネットワーク用のIPベースのプロトコル。Sigcomm '91 Conference：Communications Architectures＆Protocolsの議事録、235-245ページ、1991年9月。
[19] John Ioannidis and Gerald Q. Maguire Jr. The Design and Implementation of a Mobile Internetworking Architecture. In Proceedings of the Winter USENIX Technical Conference, pages 489--500, January 1993.
[19] John IoannidisとGerald Q. Maguire Jr.モバイルインターネットワーキングアーキテクチャの設計と実装。1993年1月、冬のUsenix技術会議、489-500ページの議事録。
[20] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[20] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[21] Jacobson, V., "Congestion Avoidance and Control. In Proceedings, SIGCOMM '88 Workshop, pages 314--329. ACM Press, August 1988. Stanford, CA.
[21] Jacobson、V。、「混雑の回避と管理。手続き、Sigcomm '88ワークショップ、314-329ページ。ACMPress、1988年8月。カリフォルニア州スタンフォード。
[22] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[22] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[23] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[23] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[24] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[24] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[25] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[25] McGregor、G。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[26] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[26] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装」、RFC 1305、1992年3月。
[27] Montenegro, G., "Reverse Tunneling for Mobile IP (revised)", RFC 3024, January 2001.
[27] モンテネグロ、G。、「モバイルIPの逆トンネル（改訂）」、RFC 3024、2001年1月。
[28] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[28] Montenegro、G.、Dawkins、S.、Kojo、M.、Magret、V。and N. Vaidya、「Long Thin Networks」、RFC 2757、2000年1月。
[29] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[29] モンテネグロ、G。およびV.グプタ、「モバイルIPのSun's Skip Firewalversal」、RFC 2356、1998年6月。
[30] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[30] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、RFC 2434、1998年10月。
[31] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[31] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[32] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[32] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[33] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[33] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[34] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[34] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[35] Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress, July 2001.
[35] Perkins、C。およびP. Calhoun、「モバイルIPのAAA登録キー」、2001年7月、進行中の作業。
[36] 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.
[36] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスを48.イーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[37] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[37] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[38] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[38] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[39] Postel, J., "Multi-LAN Address Resolution", RFC 925, October 1984.
[39] Postel、J。、「マルチランアドレス解決」、RFC 925、1984年10月。
[40] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[40] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[41] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[41] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[42] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[42] シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[43] Solomon, J., "Applicability Statement for IP Mobility Support" RFC 2005, October 1996.
[43] Solomon、J。、「IPモビリティサポートのアプリケーションステートメント」RFC 2005、1996年10月。
[44] Solomon J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.
[44] Solomon J.およびS. Glass、「PPP IPCPのモバイル-IPV4構成オプション」、RFC 2290、1998年2月。
[45] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols" Addison-Wesley, Reading, Massachusetts, 1994.
[45] スティーブンス、W。、「TCP/IP Illustrated、Volume 1：The Protocols」Addison-Wesley、Reading、Massachusetts、1994。
Authors' Addresses
著者のアドレス
The working group can be contacted via the current chairs:
ワーキンググループは、現在の椅子から連絡できます。
Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX. 75039 USA
Basavaraj Patil Nokia 6000 Connection Dr. Irving、テキサス75039 USA
Phone: +1 972-894-6709
EMail: Basavaraj.Patil@nokia.com
Phil Roberts Megisto Corp. Suite 120 20251 Century Blvd Germantown MD 20874 USA
Phil Roberts Megisto Corp. Suite 120 20251 Century Blvd Germantown MD 20874 USA
Phone: +1 847-202-9314
EMail: PRoberts@MEGISTO.com
Questions about this memo can also be directed to the editor:
このメモに関する質問は、編集者にも送信できます。
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスコミュニケーションシステムラボノキアリサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。