RFC3220 日本語訳
3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002. (Format: TXT=238343 bytes) (Obsoletes RFC2002) (Obsoleted by RFC3344) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Perkins, Ed. Request for Comments: 3220 Nokia Research Center Obsoletes: 2002 January 2002 Category: Standards Track
ワーキンググループのC.パーキンス、エドをネットワークでつないでください。コメントのために以下を要求してください。 3220年のノキアリサーチセンターは以下を時代遅れにします。 2002 2002年1月のカテゴリ: 標準化過程
IP Mobility Support for IPv4
IPv4のIP移動性サポート
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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. 序論3 1.1。 要件. . . . . . . . . . . . . . . . . 4 1.2について議定書の中で述べてください。 目標. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 仮定. . . . . . . . . . . . . . . . . . . . . . 5 1.4。 適用性. . . . . . . . . . . . . . . . . . . . . 5 1.5。 新しい建築実体. . . . . . . . . . . . . . 5 1.6。 用語. . . . . . . . . . . . . . . . . . . . . . 6 1.7。 概観. . . . . . . . . . . . . . . . . . . 9 1.8について議定書の中で述べてください。 メッセージ・フォーマットとプロトコル伸展性. . . . . . . 13 1.9。 モバイルIP拡大. . . . . . . . . . . . . . . . . . . . . 15 1.10のためのタイプ長さの価値の拡大形式。 長い拡大形式. . . . . . . . . . . . . . . . . 16
Perkins Standards Track [Page 1] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[1ページ]RFC3220IP移動性サポート
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 . . . . . . . . 43
3.6.3. Registration Retransmission . . . . . . . . . . 46
3.7. Foreign Agent Considerations . . . . . . . . . . . . . 46
3.7.1. Configuration and Registration Tables . . . . . 47
3.7.2. Receiving Registration Requests . . . . . . . . 48
3.7.3. Receiving Registration Replies . . . . . . . . 51
3.8. Home Agent Considerations . . . . . . . . . . . . . . . 53
3.8.1. Configuration and Registration Tables . . . . . 54
3.8.2. Receiving Registration Requests . . . . . . . . 55
3.8.3. Sending Registration Replies . . . . . . . . . 58
4. Routing Considerations 61
4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . 61
4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . 61
4.2.1. Mobile Node Considerations . . . . . . . . . . 61
4.2.2. Foreign Agent Considerations . . . . . . . . . 62
4.2.3. Home Agent Considerations . . . . . . . . . . . 63
4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . 65
4.4. Multicast Datagram Routing . . . . . . . . . . . . . . 65
4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . 66
4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . 68
5. Security Considerations 72
1.11. 短い拡大形式. . . . . . . . . . . . . . . . 16 2。 エージェント発見17 2.1。 エージェント広告. . . . . . . . . . . . . . . . . . 18 2.1.1。 移動性エージェント広告拡大. . . . 20 2.1.2。 接頭語長さの拡大. . . . . . . . . . . 22 2.1.3。 1バイトの詰め物拡大. . . . . . . . . . 22 2.2。 エージェント懇願. . . . . . . . . . . . . . . . . . 23 2.3。 外国人のエージェントとホームエージェント問題. . . . . . 23 2.3.1。 広告を出しているルータは.2に.242.3を記述します。 一連番号とロールオーバー取り扱. . . . 24 2.4い。 モバイルノード問題. . . . . . . . . . . . . . 25 2.4.1。 登録必要な. . . . . . . . . . . . . 26 2.4.2。 検出. . . . . . . . . . . . . . . . 26 2.4.3を動かしてください。 ホーム. . . . . . . . . . . . . . . . 27 2.4.4を返します。 一連番号とロールオーバー取り扱. . . . 28 3い。 登録28 3.1。 登録概観. . . . . . . . . . . . . . . . . 29 3.2。 認証. . . . . . . . . . . . . . . . . . . . 30 3.3。 登録要求. . . . . . . . . . . . . . . . . 30 3.4。 登録回答. . . . . . . . . . . . . . . . . . 33 3.5。 登録拡大. . . . . . . . . . . . . . . . 36 3.5.1。 .2に認証拡大値. . . 36 3.5を計算します。 移動住宅認証拡大. . . . . 37 3.5.3。 モバイルに外国の認証拡大. . . . 37 3.5.4。 外国ホーム認証拡大. . . . . 38 3.6。 モバイルノード問題. . . . . . . . . . . . . . 38 3.6.1。 登録要求. . . . . . . . . 40 3.6.2を送ります。 .3に登録回答. . . . . . . . 43 3.6を受け取ります。 登録Retransmission. . . . . . . . . . 46 3.7。 外国エージェント問題. . . . . . . . . . . . . 46 3.7.1。 構成とレジスタ・テーブル. . . . . 47 3.7.2。 登録要求. . . . . . . . 48 3.7.3を受け取ります。 登録回答. . . . . . . . 51 3.8を受け取ります。 ホームエージェント問題. . . . . . . . . . . . . . . 53 3.8.1。 構成とレジスタ・テーブル. . . . . 54 3.8.2。 登録要求. . . . . . . . 55 3.8.3を受け取ります。 登録回答. . . . . . . . . 58 4を送ります。 問題61 4.1を発送します。 カプセル化は.614.2をタイプします。 ユニキャストデータグラムルート設定. . . . . . . . . . . . . . . 61 4.2.1。 モバイルノード問題. . . . . . . . . . 61 4.2.2。 外国エージェント問題. . . . . . . . . 62 4.2.3。 ホームエージェント問題. . . . . . . . . . . 63 4.3。 データグラム. . . . . . . . . . . . . . . . . . 65 4.4を放送してください。 マルチキャストデータグラムルート設定. . . . . . . . . . . . . . 65 4.5。 モバイルルータ. . . . . . . . . . . . . . . . . . . . 66 4.6。 ARP、プロキシARP、および無料のARP. . . . . . . . . . 68 5。 セキュリティ問題72
Perkins Standards Track [Page 2] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[2ページ]RFC3220IP移動性サポート
5.1. Message Authentication Codes . . . . . . . . . . . . . 72
5.2. Areas of Security Concern in this Protocol . . . . . . 72
5.3. Key Management . . . . . . . . . . . . . . . . . . . . 73
5.4. Picking Good Random Numbers . . . . . . . . . . . . . . 73
5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 73
5.6. Ingress Filtering . . . . . . . . . . . . . . . . . . . 74
5.7. Replay Protection for Registration Requests . . . . . . 74
5.7.1. Replay Protection using Timestamps . . . . . . 74
5.7.2. Replay Protection using Nonces . . . . . . . . 76
6. IANA Considerations 76
6.1. Mobile IP Message Types . . . . . . . . . . . . . . . . 77
6.2. Extensions to RFC 1256 Router Advertisement . . . . . . 77
6.3. Extensions to Mobile IP Registration Messages . . . . . 78
6.4. Code Values for Mobile IP Registration Reply
Messages. . . . . . . . . . . . . . . . . . . . . . 78
7. Acknowledgments 79
A. Patent Issues 81
B. Link-Layer Considerations 81
C. TCP Considerations 82
C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . 82
C.2. TCP Congestion Management . . . . . . . . . . . . . . . 82
D. Example Scenarios 83
D.1. Registering with a Foreign Agent Care-of Address . . . 83
D.2. Registering with a Co-Located Care-of Address . . . . . 83
D.3. Deregistration . . . . . . . . . . . . . . . . . . . . 84
E. Applicability of Prefix-Lengths Extension 85
F. Interoperability Considerations 85
G. Changes since RFC 2002 86
G.1. Major Changes . . . . . . . . . . . . . . . . . . . . . 86
G.2. Minor Changes . . . . . . . . . . . . . . . . . . . . . 88
G.3. Changes since revision 04 of RFC2002bis . . . . . . . . 90
H. Example Messages 91
H.1. Example ICMP Agent Advertisement Message Format . . . . 91
H.2. Example Registration Request Message Format . . . . . . 92
H.3. Example Registration Reply Message Format . . . . . . . 93
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 98
5.1. 通報認証は.725.2をコード化します。 このプロトコル. . . . . . 72 5.3のSecurity Concernの領域。 Key Management. . . . . . . . . . . . . . . . . . . . 73 5.4。 良い乱数. . . . . . . . . . . . . . 73 5.5を選びます。 プライバシー. . . . . . . . . . . . . . . . . . . . . . . . 73 5.6。 イングレスフィルタリング. . . . . . . . . . . . . . . . . . . 74 5.7。 登録要求. . . . . . 74 5.7.1のための保護を再演してください。 タイムスタンプ. . . . . . 74 5.7.2を使用して、保護を再演してください。 一回だけ. . . . . . . . 76 6を使用して、保護を再演してください。 IANA問題76 6.1。 モバイルIPメッセージは.776.2をタイプします。 RFC1256ルータ通知. . . . . . 77 6.3への拡大。 モバイルIP登録メッセージ. . . . . 78 6.4への拡大。 コードはモバイルIPのために登録応答メッセージを評価します。 . . . . . . . . . . . . . . . . . . . . . 78 7. 承認79A.特許は81のB.リンクレイヤ問題81C.TCP問題82C.1を発行します。 TCPタイマ. . . . . . . . . . . . . . . . . . . . . . 82C.2。 TCPふくそう管理. . . . . . . . . . . . . . . 82D.例のシナリオ83D.1。 外国人のエージェントとともに記名する、注意、-、アドレス. . . 83D.2。 aへの登録が共同場所を見つけた、注意、-、アドレス. . . . . 83D.3。 RFC2002 86G.1以来接頭語長さの拡大85F.相互運用性問題85G.のDeregistration. . . . . . . . . . . . . . . . . . . . 84E.の適用性は変化します。 メージャーは.86G.2を変えます。 マイナーチェンジ. . . . . . . . . . . . . . . . . . . . . 88G.3。 RFC2002bis. . . . . . . . 90H.Example Messages91H.1の改正04以来の変化。 例のICMPエージェント広告メッセージ・フォーマット… 91時間.2。 例の登録要求メッセージ形式… 92時間.3。 例の登録回答メッセージ・フォーマット. . . . . . . 93参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 93作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 97の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 98
1. Introduction
1. 序論
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アドレスが唯一ノードの接着点をインターネットに特定すると仮定します。 したがって、ノードはそれに運命づけられたデータグラムを受けるためにIPアドレスによって示されたネットワークに位置しなければなりません。 さもなければ、ノードに運命づけられたデータグラムは「非-提出物」でしょう。 ノードが交信する性能を失わないで接着点を変えるように、現在の2つの次のメカニズムの1つを通常使わなければなりません:
Perkins Standards Track [Page 3] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[3ページ]RFC3220IP移動性サポート
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で詳細です。
1.1. Protocol Requirements
1.1. プロトコル要件
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.
リモートリダイレクション攻撃から守るために可動のノードの位置に関して別のノードをアップデートするのに使用されるすべてのメッセージを認証しなければなりません。
1.2. Goals
1.2. 目標
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.
しばしば可動のノードが直接インターネットに添付されるリンクは無線のリンクであるかもしれません。 このリンクには、その結果、実質的に下側の帯域幅と伝統的な有線ネットワークより高い誤り率があるかもしれません。 そのうえ、可動のノードは動かされたバッテリーである傾向があります、そして、電力消費量を最小にするのは重要です。 したがって、可動のノードが直接インターネットに添付されるリンクの上に送られた管理メッセージの数は最小にされるべきです、そして、これらのメッセージのサイズは合理的にできるだけ小さく保たれるべきです。
Perkins Standards Track [Page 4] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[4ページ]RFC3220IP移動性サポート
1.3. Assumptions
1.3. 仮定
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秒あたりの一度より頻繁にそれらの接着点をインターネットに変えないと仮定します。
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ユニキャストデータグラムがデータグラムヘッダー(そして、例えばどんなソースアドレスでも、そうしない)の送付先アドレスに基づいて発送されると仮定します。
1.4. Applicability
1.4. 適用性
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が、ノードが1つのIPサブネットから別のサブネットまで動くのを可能にすることを意図します。 それは均質のメディアの向こう側に移動性に移動性のために種々雑多なメディアのむこうにあるのとちょうど同じくらい適しています。 すなわち、モバイルIPは1つのイーサネットセグメントから別のセグメントまでのノード運動をイーサネットセグメントから無線LANまでのノード運動を収容するのと同じくらいよく容易にします、可動のノードのIPアドレスがそのような動きの後に同じままで残っている限り。
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よりはるかに少ないオーバーヘッドを提供するかもしれません。
1.5. New Architectural Entities
1.5. 新しい建築実体
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.
接着点を1つのネットワークかサブネットワークから別のものに変えるホストかルータ。 IPアドレスを変えないで、可動のノードは位置を変えるかもしれません。 それは、(一定)のIPアドレスを使用することでどんな位置の他のインターネット接続装置ともコミュニケートし続けるかもしれません、接着点へのリンクレイヤの接続性が利用可能であると仮定して。
Perkins Standards Track [Page 5] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[5ページ]RFC3220IP移動性サポート
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 router on a mobile node's visited network which provides routing services to the mobile node while registered. 外国人のエージェントは、可動のノードの家のエージェントによってトンネルを堀られた可動のノードに、データグラムを「反-トンネル」であり、届けます。 可動のノードによって送られたデータグラムに関しては、外国人のエージェントは登録された可動のノードのためのデフォルトルータとして勤めるかもしれません。
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アドレスを静止したホストに提供するとき、同様に、このホームアドレスを管理します。 ホームネットワーク、aから離れている、「注意、-、アドレス、」 可動のノードに関連していて、可動のノードの現在の接着点を反映します。 例えば、同じくらい中、本書ではデータグラムのために別の方法で説明されるのを除いて、それが送るすべてのIPデータグラムのソースアドレスが、ある移動性管理機能のために発信したので可動のノードがホームアドレスを使用する、(セクション3.6 .1 .1)。
1.6. Terminology
1.6. 用語
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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
本書では、認可のエネイブリングである拡大のすべての用途が家のエージェントにとって許容できるRegistration Requestメッセージを可能にする認証拡大について言及します。 指定された追加議定書構造を使用することこのドキュメントの外では、可動のノードが登録の認証を備えるのにおいてそれが可能であるかもしれない。
Perkins Standards Track [Page 6] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[6ページ]RFC3220IP移動性サポート
home agent, by way of another authenticating entity within
the network that is acceptable to the home agent (for
example, see RFC 2794 [6]).
家のエージェント、家のエージェントにとって、ネットワークの中の別の認証実体を通してそれは許容できます。(例えば、RFC2794[6])を見てください。
Agent Advertisement
エージェント広告
An advertisement message constructed by attaching a special
Extension to a router advertisement [10] message.
ルータ通知[10]メッセージに特別なExtensionを取り付けることによって構成された広告メッセージ。
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つの異なったタイプを使用できる、注意、-、アドレス: 「外国人のエージェント、注意、-、アドレス、」、可動のノードが登録されている外国人のエージェント、およびaがアドレスがある、「共同見つけられている、注意、-、アドレス、」 可動のノードにはある外部的に得られたローカルアドレスはそれ自身のネットワーク・インターフェースの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.
可動のノードのホームを除いて、いずれも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キャッシュ[45]でエントリーをアップデートすることを自然に引き起こすためにノードによって送られたARPパケット。 セクション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アドレス。 それはどこにかかわらず変わりがないか。ノードはインターネットに添付されます。
Perkins Standards Track [Page 7] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[7ページ]RFC3220IP移動性サポート
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ルーティングメカニズムが可動のノードのホームAddressに運命づけられたデータグラムを可動のノードのホームNetworkに渡すことに注意してください。
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.
アドレスは以前は物理的なリンクの上によく何らかのコミュニケーションの終点を特定していました。 Link層のアドレスは通常、インタフェースのメディアAccess Control(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).
1組のノードの間のセキュリティ文脈の収集。ノードはそれらの間で交換されたモバイルIPプロトコルメッセージに適用されるかもしれません。 各文脈は認証アルゴリズム、モード(セクション5.1)、秘密(共有されたキー、または適切な公衆/秘密鍵組)、および使用中の反復操作による保護のスタイル(セクション5.7)を示します。
Node
ノード
A host or a router.
ホストかルータ。
Nonce
一回だけ
A randomly chosen value, different from previous choices,
inserted in a message to protect against replays.
守るメッセージに挿入された手当たりしだいに選ばれた前の選択と異なった値は再演されます。
Perkins Standards Track [Page 8] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[8ページ]RFC3220IP移動性サポート
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で利用可能な文脈の中の1組のノードの間のセキュリティ文脈を特定するインデックス。 SPI値0〜255は、予約されていて、どんなMobility Security Associationでも使用されてはいけません。
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.
それは要約されましたが、経路はデータグラムで続きました。 モデルは、それが要約されますが、データグラムが博識なdecapsulatingエージェントに発送されて、どのdecapsulatesがデータグラムであるかということであり、次に、正しくそれを最終仕向地に届けます。
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.
可動のノードのホームNetwork以外のネットワーク。可動のノードは現在、Networkに接続されます。
Visitor List
訪問者リスト
The list of mobile nodes visiting a foreign agent.
外国人のエージェントを訪問する可動のノードのリスト。
1.7. Protocol Overview
1.7. プロトコル概観
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
可動のノードが家にいないときに、登録する、それ、注意、-、家のエージェントとのアドレス。 付属の方法によって、可動のノードは登録するでしょう。
Perkins Standards Track [Page 9] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[9ページ]RFC3220IP移動性サポート
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.
実現はさらなる処理なしで誤りを送付者に示すことなしでデータグラムを捨てます。 実現SHOULDは捨てられたデータグラムのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
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.
- エージェントAdvertisementメッセージ(セクション2)で移動性エージェント(すなわち、外国人のエージェントと家のエージェント)は彼らの存在の広告を出します。 可動のノードはどんな局所的に添付の移動性エージェントからエージェントSolicitationメッセージまでも任意にエージェントAdvertisementメッセージに請求するかもしれません。
- A mobile node receives these Agent Advertisements and
determines whether it is on its home network or a foreign
network.
- 可動のノードは、これらのエージェントAdvertisementsを受けて、それがホームネットワークか外国ネットワークにあるかを決定します。
- 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.
- 可動のノードがそれを検出すると、それはホームネットワークに位置していて、移動性サービスなしで作動します。 ほかの場所に登録されるのからホームネットワークに戻るなら、それがあるRegistration RequestとRegistration Replyメッセージの交換による家のエージェントがいる可動のノード「反-レジスタ」です。
- 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]などの外部の何らかの割当機構、(aが共同場所を見つけた、注意、-、アドレス)
- 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).
- 次に、遠くで家を中心に活動する可動のノードが登録する、それが新しい、注意、-、それがあるRegistration RequestとRegistration Replyメッセージの交換による家のエージェントとことによると外国人のエージェントを通して(セクション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)に渡します。
Perkins Standards Track [Page 10] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[10ページ]RFC3220IP移動性サポート
- 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は、ホームネットワークとその現在の位置の間にモバイルノードのホームアドレスを介入しているルータから隠すのにプロトコルトンネリングを使用します。 The tunnel terminates at the mobile node's care-of address. 注意、-、アドレス、従来のIPルーティングでデータグラムを提供できるアドレスにならなければならなくなってください。 注意、-、アドレス、オリジナルのデータグラムは、トンネルから取り外されて、モバイルノードに提供されます。
Mobile IP provides two alternative modes for the acquisition of a care-of address:
モバイルIPがaの獲得のための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) 「外国人のエージェント、注意、-、アドレス、」、注意、-、アドレス、エージェントAdvertisementメッセージを通して外国人のエージェントによって提供されます。 この場合、注意、-、アドレスは外国人のエージェントのIPアドレスです。 このモードで、外国人のエージェントは、トンネルの終点であり、トンネルを堀られたデータグラムを受けるときそれらをdecapsulatesして、内側のデータグラムをモバイルノードに提供します。 多くのモバイルノードがそれで同じように共有できるので獲得のこの方法が好まれる、注意、-、既に有限な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) 「共同見つけられている、注意、-、アドレス、」、aである、注意、-、ローカルアイピーアドレスとしてモバイルノードによって次に、モバイルノードがそれ自身のネットワーク・インターフェースの1つに関連づけるいくつかの外部の手段で習得されたアドレス。 アドレスを仮の住所としてDHCP[13]などのモバイルノードでダイナミックに習得するか、またはモバイルノードは何らかの外国ネットワークを訪問しているだけである間、使用のための長期のアドレスとして所有するかもしれません。 aとして使用のためのローカルアイピーアドレスを習得する特定の外部のメソッドが共同場所を見つけた、注意、-、アドレスはこのドキュメントの範囲を超えています。 共同見つけられたaを使用する、注意、-、アドレス、トンネルとそれ自体の終点がそれにトンネルを堀られたデータグラムの被膜剥離術を実行するとき、モバイルノードは役立ちます。
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
aを使用するモードが共同場所を見つけた、注意、-、アドレスには、それが例えば、外国人のエージェントなしでまだ外国人のエージェントを配布していないネットワークで機能するのをモバイルノードを許容する利点があります。 しかしながら、それは、外国ネットワークの中でアドレスのプールを必要とするので、IPv4アドレス空間に追加負担をかけます。
Perkins Standards Track [Page 11] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[11ページ]RFC3220IP移動性サポート
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.
訪問のモバイルノードに利用可能に作られてください。 効率的にモバイルノードが訪問することを許可するかもしれない各サブネットのためのアドレスのプールを維持するのは難しいです。
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.
区別を理解しているのが重要である、注意、-、アドレス、そして、外国エージェント機能。 注意、-、アドレスは単にトンネルの終点です。 本当に、それが外国人のエージェントのアドレスであるかもしれない、(外国人のエージェント、注意、-、アドレス)、それが代わりにモバイルノードによって一時習得されたアドレスであるかもしれない、(aが共同場所を見つけた、注意、-、アドレス) 他方では、外国人のエージェントはモバイルノードに対するサービスを提供する移動性エージェントです。 追加詳細に関してセクション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、モバイルノードが外国人のエージェントを使用している、注意、-、aではなく、共同見つけられたアドレス、注意、-、アドレス。
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.
2) データグラムが傍受される、3) データグラムがホームのエージェントであって、「反-トンネル」であり、提供にトンネルを堀られる、注意、-、アドレス. モバイルノード。
+-----+ +-------+ +------+
|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.
+----+
+-----+ +-------+ +------+ |ホーム| =======>|、外国| ------>| モバイル| |エージェント| | エージェント| <、-、-、-、-、--、| ノード| +-----+ +-------+ +------+ 1) /へのデータグラム|\/モバイルノード| / 4) 発信するデータグラム、到着します。| /モバイルノード、標準のIPホームネットワーク| /ルーティングがそれぞれ配達する、標準を通してそれはあります。| |_ 目的地。 この図、IPルーティングで。 +----+ 外国人のエージェントはそうです。|ホスト| モバイルノードのデフォルトルータ。 +----+
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メカニズムを使用して、ホームのエージェントがモバイルノードのホームアドレスでリンクの上のネットワーク・インターフェースを示させるなら、この要件を満たすことができます。 また、モバイルノードのホームアドレスに運命づけられたデータグラムを妨害するのに他のメカニズムを使用して、モバイルノードのホームの位置に比例したホームのエージェントの他のプレースメントも可能であるかもしれません。 そのようなプレースメントはこのドキュメントの範囲を超えています。
Perkins Standards Track [Page 12] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[12ページ]RFC3220IP移動性サポート
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.
モバイルノードがaが共同場所を見つけた使用である、注意、-、アドレス(上で(b)で説明されるように)、ネットワーク接頭語によって特定されたリンクにモバイルノードの見つけなければならない、これ、注意、-、アドレス さもなければ、データグラムが運命づけた、注意、-、アドレスは「非-提出物」でしょう。
1.8. Message Format and Protocol Extensibility
1.8. メッセージ・フォーマットとプロトコル伸展性
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はUDP[37]がウェルノウン・ポート番号434を使用している状態で送られた1セットの新しいコントロールメッセージを定義します。 以下の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はRouter AdvertisementとRouter SolicitationメッセージがICMP Routerディスカバリー[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 Routerディスカバリーメッセージによって運ばれるのを許容するために一般的なExtensionメカニズムを定義します。 いくつかの拡大が、セクション1.9で説明された簡単なType長さの価値の形式でコード化されるために指定されました。
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.
拡大は、可変量の情報が各データグラムの中に運ばれるのを許容します。 Extensionsのリストの終わりはIPデータグラムの全長によって示されます。
Perkins Standards Track [Page 13] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[13ページ]RFC3220IP移動性サポート
Two separately maintained sets of numbering spaces, from which
Extension Type values are allocated, are used in Mobile IP:
別々に維持された2セットの付番空間(Extension Type値は割り当てられる)はモバイル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コントロールメッセージだけに現れるかもしれないそれらのExtensionsから成ります(それらはNo.とUDPポートNo.434から発信しました)。 本書では、以下のTypesはモバイルIPコントロールメッセージに現れるExtensionsのために定義されます:
32 Mobile-Home Authentication
33 Mobile-Foreign Authentication
34 Foreign-Home Authentication
32 移動住宅認証33のモバイルに外国の認証34外国ホーム認証
- 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 Routerディスカバリーメッセージ[10]だけに現れるかもしれないそれらの拡大から成ります。 本書では、以下のTypesはICMP Routerディスカバリーメッセージに現れるExtensionsのために定義されます:
0 One-byte Padding (encoded with no Length nor Data field)
16 Mobility Agent Advertisement
19 Prefix-Lengths
または、0の1バイトのPadding、(Lengthなしでコード化される、Data分野) 16MobilityエージェントAdvertisement19のPrefix-長さ
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].
それぞれの個々のExtensionは後で別々のセクションで詳細に本書では説明されます。 これらのExtension Type番号のための最新の値は最新の「規定番号」[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.
これらのセットの分離(直交性)のために、より後日定義される2Extensionsが同じType値を持っているかもしれないのが想像できます、Extensionsの1つがモバイルIPコントロールメッセージだけで使用されるかもしれなくて、もう片方がICMP Routerディスカバリーメッセージだけで使用されるかもしれない限り。
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(skippableして、skippableしない)の唯一身元保証可能な拡大をサポートすることができます。 範囲の中でこれらのセットのどちらかで0〜127に付番されたExtensionが遭遇しますが、認識されないとき、静かにそのExtensionを含むメッセージを捨てなければなりません。 範囲で128〜255に付番されたExtensionが遭遇するとき、(認識されません)その特定のExtensionは無視されますが、まだExtensionsとメッセージデータの残りを処理しなければなりません。 ExtensionのLength分野は、次のExtensionを捜し求める際にData分野をスキップするのに使用されます。
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
追加構造が拡大タイプに利用されない場合、モバイルIPへの新しい開発か追加が拡大のための利用可能なスペースがなくなるかもしれないのをタイプするとても多くの新しい拡大を必要とするかもしれません。 2つの新しい拡大構造が、この問題を解決するために提案されます。 使用して、あるタイプの拡大を集めることができます。
Perkins Standards Track [Page 14] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[14ページ]RFC3220IP移動性サポート
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.
正確な拡大を特定する例えば、Generic Authenticationキーズ拡張子[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つの新しい拡大形式の1つに続くのは、お勧めです。
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
- 単純拡大形式--長い拡大形式--短い拡大形式
1.9. Type-Length-Value Extension Format for Mobile IP Extensions
1.9. モバイルIP拡大のためのタイプ長さの価値の拡大形式
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図で例証されたType長さの価値の形式は本書では指定される拡大に使用されます。 この単純拡大構造が拡大タイプスペースの最も効率的な用法を奨励しないので、新しいモバイルIP拡大が関連する拡大を分類する可能性があるかもしれないときはいつも、セクション1.10か1.11で指定された2つの新しい拡大形式の1つに続くのは、お勧めです。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | タイプ| 長さ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: Type-Length-Value extension format for Mobile IPv4
図2: モバイルIPv4のためのタイプ長さの価値の拡大形式
Type Indicates the particular type of Extension.
Extensionの特定のタイプのIndicatesをタイプしてください。
Length Indicates the length (in bytes) of the data field within
this Extension. The length does NOT include the Type and
Length bytes.
このExtensionの中のデータ・フィールドの長さ(バイトによる)の長さのIndicates。 長さはTypeとLengthバイトを含んでいません。
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.
特定のデータがこのExtensionに関連づけたデータ。 この分野はゼロであるかもしれませんか以上は長さがバイトです。 データ・フィールドの形式と長さはタイプと長さの分野のそばで決定しています。
Perkins Standards Track [Page 15] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[15ページ]RFC3220IP移動性サポート
1.10. Long Extension Format
1.10. 長い拡大形式
This format is applicable for non-skippable extensions which carry information more than 256 bytes.
256バイト以上の情報を運ぶ非skippable拡張子に、この形式は適切です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| サブタイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Long Extension format requires that the following fields be specified as the first fields of the extension.
Long 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.
サブ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.
長さはこのExtensionの中にデータ・フィールドの長さ(バイトによる)を示します。 それはType、Length、およびSub-タイプバイトを含んでいません。
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バイトを超えることができます。
1.11. Short Extension Format
1.11. 短い拡大形式
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で定義されるskippable拡張子と互換性があります。 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 ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Short Extension format requires that the following fields be specified as the first fields of the extension:
Short Extension形式は、以下の分野が拡大の最初の分野として指定されるのを必要とします:
Perkins Standards Track [Page 16] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[16ページ]RFC3220IP移動性サポート
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.
サブ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ビットの符号のない整数。 拡大Typeと拡大Length分野を除いたバイトで表現される拡大の長さ。 データ・フィールドの1と全長にこの分野を設定しなければなりません。
Data is the data associated with this extension. This
specification does not place any additional structure on
the subtype data.
データはこの拡大に関連しているデータです。 この仕様は少しの追加構造も「副-タイプ」データに置きません。
2. Agent Discovery
2. エージェント発見
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.
エージェントディスカバリーはモバイルノードがそれが現在ホームネットワーク、または、外国ネットワークに関連づけられるかどうか決定して、モバイルノードがそれがいつ1つのネットワークから別のネットワークまで移行したかを検出できるメソッドです。 また、外国ネットワークに関連づけられると、モバイルノードがこのセクションで指定されたメソッドで外国人のエージェントを決定できる、注意、-、そのネットワークに対してはそれぞれの外国人のエージェントによって提供されるアドレス。
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 Routerディスカバリー[10]を広げています。 エージェントAdvertisementは、ICMP Router Advertisementメッセージ(セクション2.1)にMobilityエージェントAdvertisement Extensionを含んでいることによって、形成されます。 エージェントSolicitationメッセージはICMP Router Solicitationと同じです、そして、IP TTL MUSTは1(セクション2.2)に用意ができています。 このセクションはモバイルノード、外国人のエージェント、およびホームのエージェントが協力する、エージェントディスカバリーがわかるメッセージ・フォーマットと手順について説明します。
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.
エージェントAdvertisementとエージェントSolicitationは既にこの機能性を提供するリンクレイヤに必要でないかもしれません。 このドキュメントの範囲の外にモバイルノードが将来のエージェントとのリンクレイヤ接続を確立するメソッドがあります(Appendix 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.
認証は全くエージェントAdvertisementとエージェントSolicitationメッセージに必要ではありません。 それらは認証された使用IP Authentication Header[22]であるかもしれない(本書では説明されたメッセージに関係ありません)。 AdvertisementとSolicitationメッセージが認証されるかもしれない方法のさらなる仕様はこのドキュメントの範囲の外にあります。
Perkins Standards Track [Page 17] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[17ページ]RFC3220IP移動性サポート
2.1. Agent Advertisement
2.1. エージェント広告
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.
エージェントAdvertisementsは、リンクの上にサービスの広告を出すために移動性エージェントによって伝えられます。 モバイルノードは、それらの現在の接着点をインターネットに決定するのにこれらの広告を使用します。 エージェントAdvertisementはまた、任意にMobilityエージェントAdvertisement Extension(セクション2.1.1)と、Prefix-長さのExtension(セクション2.1.2)か、One-バイトPadding Extension(セクション2.1.3)か、将来定義されるかもしれない他のExtensionsを運ぶために広げられたICMP Router Advertisementです。
Within an Agent Advertisement message, ICMP Router Advertisement fields of the message are required to conform to the following additional specifications:
エージェントAdvertisementメッセージの中では、メッセージのICMP Router Advertisement分野が以下の追加仕様に従うのに必要です:
- 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.
ユニキャストエージェントAdvertisementのリンクレイヤ送付先アドレスはAdvertisementをうながしたエージェントSolicitationのソースリンクレイヤアドレスと同じであるに違いありません。
- IP Fields
- IP分野
TTL The TTL for all Agent Advertisements MUST be set
to 1.
すべてのエージェントAdvertisementsのための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.
マルチキャストエージェントAdvertisementの受信者IPアドレスがICMP Routerディスカバリー[10]に指定されるように「このリンクの上のすべてのシステム」マルチキャストアドレスであるに違いない、(224.0の.0.1)[11]か「限られた放送」アドレス、(255.255 .255 .255)。 サブネットによって指示にされるのはフォーム<接頭語>のアドレスを放送しました。モバイルノードが一般に外国ネットワークの接頭語を知らないので、<-1>は使用できません。 エージェントであるときに、Advertisementはモバイルノードへのユニキャストです、モバイルノードSHOULDに関するIPホームアドレス。Destination Addressとして、使用されます。
Perkins Standards Track [Page 18] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[18ページ]RFC3220IP移動性サポート
- ICMP Fields
- ICMP分野
Code The Code field of the agent advertisement is
interpreted as follows:
Codeがさばくエージェント広告のコードは以下の通り解釈されます:
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.
最大の長さのAdvertisementが一層の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.
エージェントAdvertisementのこの一部に現れるかもしれないアドレスの議論に関してセクション2.3.1を見てください。
Num Addrs
ヌム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.
このメッセージの広告に掲載されたRouter Addressesの数。 エージェントAdvertisementメッセージでは、メッセージのICMP Router Advertisement部分で指定されたルータアドレスの数が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
定期的に送るなら、SHOULDがエージェントAdvertisementsに送られる名目上の間隔はもうICMPヘッダーで与えられている1/3広告Lifetimeより送ります。 この間隔に、1/3より短いかもしれません。広告を出しているLifetime。 これで、有効なエージェントのリストからエージェントを削除する前に、モバイルノードは3つの連続した広告を逃すことができます。 [10] 同期を避けるためにランダマイズされて、各広告SHOULDのための実際のトランスミッション時間はわずかにそうであり、他とのその後の衝突はエージェントです。
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.
他のエージェント(または他のルータで他のRouter Advertisementsを送って)によって送られるかもしれない広告。 この分野は以下で定義されたMobilityエージェントAdvertisement Extensionの中で「登録生涯」分野に関係がないことに注意してください。
Perkins Standards Track [Page 19] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[19ページ]RFC3220IP移動性サポート
2.1.1. Mobility Agent Advertisement Extension
2.1.1. 移動性エージェント広告拡大
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:
MobilityエージェントAdvertisement ExtensionはICMP Router Advertisement野原に続きます。 それは、また、ICMP Router Advertisementメッセージが移動性エージェントによって送られるエージェントAdvertisementであることを示すのに使用されます。 MobilityエージェントAdvertisement Extensionは以下の通り定義されます:
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 |
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 登録生涯|R|B|H|F|M|G|r|T| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロか以上、Care、-、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.
Sequence Numberのバイト数のための6つのアカウント、Registration Lifetime、旗、予約された分野、およびNが数であるところの長さ(6+4*N)、注意、-、アドレスは広告を出しました。
Sequence Number
一連番号
The count of Agent Advertisement messages sent since the
agent was initialized (Section 2.3.2).
エージェント以来送られたエージェントAdvertisementメッセージのカウントは初期化されました(セクション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.
このエージェントが、どんなRegistration Requestでも受け入れても構わないと思う最も長い生涯(秒に測定されます)。 0xffffの値は無限を示します。 この分野はエージェントAdvertisementのICMP Router Advertisement部分の中で「生涯」分野に関係がありません。
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登録が必要です。 共同見つけられたaを使用さえするとき、この外国人のエージェント(または、このリンクの上の別の外国人のエージェント)との登録が必要である、注意、-、アドレス。
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ホームのエージェント。 このエージェントはホームのエージェントとしてこのエージェントAdvertisementメッセージが送られるリンクに対してはサービスを提供します。
Perkins Standards Track [Page 20] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[20ページ]RFC3220IP移動性サポート
F Foreign agent. This agent offers service as a foreign
agent on the link on which this Agent Advertisement
message is sent.
F外国人のエージェント。 このエージェントは外国人のエージェントとしてこのエージェントAdvertisementメッセージが送られるリンクに対してはサービスを提供します。
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はゼロとして発信しました。 レセプションでは、無視されます。 SHOULD NOT、いかなる他の用途にはも、割り当ててください。
T Foreign agent supports reverse tunneling [27].
T外国エージェントサポートは、[27]にトンネルを堀りながら、逆になります。
reserved
Sent as zero; ignored on reception.
ゼロとしての予約されたSent。 レセプションでは、無視されます。
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)はこの外国人のエージェントに提供されました。 エージェントAdvertisementが少なくとも1つを含まなければならない、注意、-、'F'に噛み付いたなら、アドレスは設定されます。 数、注意、-、アドレスは中でLengthでExtensionをさばきますプレゼントが決定している。
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.
ホームのエージェントはいつもそれがホームのエージェントであるモバイルノードに役立つ用意ができていなければなりません。 外国人のエージェントは時には、追加モバイルノードに役立つことができないくらい忙しいかもしれません。 たとえそうだとしても、エージェントAdvertisementsを送り続けなければなりません、既にそれに登録されたどんなモバイルノードも、外国人のエージェントの範囲から引っ越していなくて、また外国人のエージェントが失敗していないのを知るように。 外国人のエージェントは、新しいモバイルノードがそれとともに記名するのを許容するのが「忙し過ぎること」を示すかもしれません、'B'ビットをエージェントAdvertisementsにはめ込むことによって。 エージェントAdvertisementメッセージで、また、'F'ビットが設定されないなら、'B'ビットを設定してはいけません。 その上、Advertisementメッセージが送ったどんなエージェントにも少なくとも'F'ビットの1つと'H'ビットを設定しなければなりません。
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.
外国人のエージェントが後天的なaの共同見つけているそれらのモバイルノードからさえ登録を必要としたがっている、注意、-、アドレス、それは'R'ビットを1つに設定します。 このビットが外国人のエージェントだけに適用されるので、また、'F'ビットが1つに設定されない場合、エージェントは'R'ビットを1つに設定してはいけません。
Perkins Standards Track [Page 21] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[21ページ]RFC3220IP移動性サポート
2.1.2. Prefix-Lengths Extension
2.1.2. 接頭語長さの拡大
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:
Prefix-長さのExtensionはMobilityエージェントAdvertisement Extensionに続くかもしれません。 それは、各Router Addressに適用されるネットワーク接頭語のビットの数がエージェントAdvertisementのICMP Router Advertisement部分に記載したのを示すのに使用されます。 与えられた接頭語の長さが、申し込まないことに注意してください、注意、-、アドレス(es)はMobilityエージェントAdvertisement Extensionに記載しました。 Prefix長さのExtensionは以下の通り定義されます:
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 | ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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が値であるところでは、ヌムAddrsの(ことによるとゼロ)はエージェントのICMP Router Advertisement部分でAdvertisementをさばきます。
Prefix Length(s)
接頭語の長さ(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.
対応するRouter Addressのネットワーク・ナンバーを定義する主なビットの数はメッセージのICMP Router Advertisement部分に記載しました。 Router Addressesがオーダーで別々のバイトですが、メッセージのICMP Router Advertisement部分に記載されていて、Router Addressがコード化されるそれぞれ接頭語の長さ。
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.
それが移行したかどうか決定するとき、Prefix-長さのExtensionがモバイルノードによってどう使用されるかもしれないかの情報に関してセクション2.4.2を見てください。 このExtensionの使用に関する実装の詳細に関してAppendix Eを見てください。
2.1.3. One-byte Padding Extension
2.1.3. 1バイトの詰め物拡大
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メッセージを水増しすると言い張ります。 エージェントAdvertisementのICMPの長さが変であるなら、このExtensionは、ICMPを長さにしさえするように含まれるかもしれません。 このExtensionがエージェントAdvertisementの多岐を言い表すか、または長い間並べるために含まれるように汎用Extensionであることを意図しないことに注意してください。 Advertisement SHOULDが1One-バイトのPadding Extensionよりさらに、プレゼント、このExtension SHOULDであるならエージェントにおける最後のExtensionがAdvertisementであったなら含まないエージェント。
Perkins Standards Track [Page 22] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[22ページ]RFC3220IP移動性サポート
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:
Extensionsが「長さ」なしでモバイルIP、Padding Extensionがコード化されるOne-バイトa単一のバイトに使用して、「データ」分野が提示するもう一方と異なってそれに注意してください。 One-バイトPadding Extensionは以下の通り定義されます:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | タイプ| +-+-+-+-+-+-+-+-+
Type 0 (One-byte Padding Extension)
0をタイプしてください。(1バイトの詰め物拡大)
2.2. Agent Solicitation
2.2. エージェント懇願
An Agent Solicitation is identical to an ICMP Router Solicitation with the further restriction that the IP TTL Field MUST be set to 1.
エージェントSolicitationはIP TTL Fieldが1に用意ができなければならないというさらなる制限でICMP Router Solicitationと同じです。
2.3. Foreign Agent and Home Agent Considerations
2.3. 外国人のエージェントとホームエージェント問題
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.
リンク層プロトコルで発見できないどんな移動性エージェントもエージェントAdvertisementsを送らなければなりません。 またSHOULDがエージェントAdvertisementsを実装するリンク層プロトコルで発見できるエージェント。 しかしながら、サイト方針がエージェントとの登録を必要とする(すなわち、'R'ビットはいつ設定されますか)時か、特定のエージェントSolicitationへの応答としてAdvertisementsを送る必要はありません。 すべての移動性エージェントがアドレスのモバイルエージェントマルチキャストグループに扱われた状態で彼らが受けるパケットを処理しなければならない、224.0、.0、.11 モバイルノードはエージェントSolicitationを224.0に送るかもしれません。.0 .11。 すべての移動性エージェントSHOULDはエージェントSolicitationsに応じます。
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 Routerディスカバリー[10]への指定されるとしてのエージェントAdvertisementメッセージとエージェントSolicitationメッセージで用いられます、それを除いて:
- 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
- 移動性エージェントはそれが放送かマルチキャストエージェントAdvertisementsを送るレートを制限しなければなりません。 最大はAdvertisementsが消費しない選ばれたそうがネットワーク回線容量、かなりの量のANDであったならSHOULDを評定します。
- 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).
- Router Solicitationを受け取る移動性エージェントは、IP Source Addressが隣人(すなわち、ルータのそのアドレスに関連しているサブネットマスクの下で到着インタフェースに関するルータの自己のアドレスの1つに合っているアドレス)のアドレスであることを必要としてはいけません。
- a mobility agent MAY be configured to send Agent Advertisements
only in response to an Agent Solicitation message.
- 移動性エージェントは、単にエージェントSolicitationメッセージに対応してエージェントAdvertisementsを送るために構成されるかもしれません。
Perkins Standards Track [Page 23] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[23ページ]RFC3220IP移動性サポート
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.
モバイルノードのホームアドレスによって特定されたリンクに見つけられていて、ホームネットワークであるなら、次に、仮想ネットワーク、どんなモバイルノードのためのホームのエージェントもSHOULDではありません。このリンクの上のホームのエージェントによって送られたエージェントAdvertisementメッセージで、'H'ビットを設定しなければなりません。 このように、それら自身のホームネットワークのモバイルノードは、それらが本当にホームにあることを決定できるでしょう。 Advertisementメッセージでそれが付けられるかもしれない(それが1個以上のリンクに勤めている移動性エージェントであるなら)別のリンクの上のホームのエージェントで送って、また、ホームのエージェントがその他のリンクの上のホームのエージェント(他のモバイルノードへの)として勤めない場合'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.
ホームネットワークが仮想ネットワークであるなら、ホームネットワークで、どんな物理的な実現もホームのエージェント自身にとって外部になりません。 この場合、エージェントAdvertisementメッセージ広告にホームのエージェントを送る物理ネットワークリンクが全くありません。 これがホームネットワークであるモバイルノードはいつもホームから離れているとして扱われます。
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).
特定のサブネットでは、すべての移動性エージェントがPrefix-長さのExtensionを入れなければなりませんか、またはそれらは皆、このExtensionを含んではいけません。 同等に、それは与えられたサブネットの何人かのエージェントがExtensionを入れるように禁止されているのにもかかわらずの、それを含まない他のもののためのものです。 さもなければ、モバイルノードのために設計された移動検出アルゴリズムの1つは適切(セクション2.4.2)に機能しないでしょう。
2.3.1. Advertised Router Addresses
2.3.1. 広告を出しているルータアドレス
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).
エージェントAdvertisementのICMP Router Advertisement部分は1つ以上のルータアドレスを含むかもしれません。 エージェントSHOULDだけがもしあればそれ自身のアドレスを広告に置きました。 それ自身のアドレスがRouter Addressesに現れるか否かに関係なく、外国人のエージェントはそれが登録されたモバイルノード(セクション4.2.2)から受けるデータグラムを発送しなければなりません。
2.3.2. Sequence Numbers and Rollover Handling
2.3.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.
エージェントAdvertisementsの一連番号は0〜0xffffまで及びます。 穂ばらみの後に、エージェントは最初の広告のNo.0を使用しなければなりません。 一連番号256があとに続いた状態で、それぞれのその後の広告は一連番号0xffffがあるに違いない例外ですばらしい一連番号ものを使用しなければなりません。 このように、モバイルノードはリブートの後に値の0xffffに達した後に一連番号のロールオーバーをもたらす減少から起こる一連番号の減少を区別できます。
Perkins Standards Track [Page 24] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[24ページ]RFC3220IP移動性サポート
2.4. Mobile Node Considerations
2.4. モバイルノード問題
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.
あらゆるモバイルノードがエージェントSolicitationを実装しなければなりません。 懇願SHOULD、エージェントAdvertisementsといつが不在のとき単に送ってくださいか、注意、-、アドレス、リンク層プロトコルか他の手段で、決定していません。 モバイルノードはモバイルノードが3秒あたりの一度よりしばしば請求するかもしれなくて、現在どんな外国人のエージェントにも接続されないモバイルノードがマックス_SOLICITATIONSより多くの回に請求するかもしれないというそれを除いたICMP Router Solicitationメッセージ[10]のための指定されるとしてのエージェントSolicitationに同じ手順、デフォルト、および定数を用います。
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.
モバイルノードでモバイルノードがSolicitationsを送るレートを制限しなければなりません。 モバイルノードはエージェントを捜し求めている間、最高率の1つの1秒あたり3初期のSolicitationsを送るかもしれません。 この後、Solicitationsが送られるレートは、地方のリンクの上にオーバーヘッドを制限するために低下しなければなりません。 その後のSolicitationsに2進の指数のbackoffメカニズムを使用させなければなりません、連続したSolicitationsの間隔を倍にして、最大の間隔まで。 最大の間隔SHOULD、適切にモバイルノードが請求しているメディアの特性に基づいた状態で、選ばれてください。 この最大の間隔に、SHOULDは少なくともそうです。Solicitationsの間の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].
まだエージェントを捜し求めている間、モバイルノードは新しいリンクに移行したという積極的な指示を受けていない場合それがSolicitationsを送るレートを増強してはいけません。 首尾よくエージェントとともに記名するモバイルノードSHOULDがもそれがSolicitationsを送るレートを増強した後に、それであるときに、次に、登録する新しいエージェントを捜し求めるのは始まります。 増強された懇願率を最高率に戻るかもしれませんが、上で説明された方法で制限しなければなりません。 すべての場合では、お勧めの懇願間隔は額面価格です。 モバイルノードはICMP Routerディスカバリー[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.
モバイルノードは容認されたエージェントAdvertisementsを処理しなければなりません。 モバイルノードは、ICMP Router Advertisementメッセージの他の用途と広告を出しているアドレスの数とIP Total Length分野を調べることによって、エージェントAdvertisementメッセージを区別できます。 IPであるときに、全長は、ICMPメッセージが広告を出しているアドレスの数に必要とされるより長いのを示して、残っているデータは1Extensionsとして解釈されます。 MobilityエージェントAdvertisement Extensionの存在は、広告がエージェントAdvertisementであると認識します。
Perkins Standards Track [Page 25] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[25ページ]RFC3220IP移動性サポート
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.
1つ以上の広告を出しているアドレスがあれば、モバイルノードSHOULDは新規登録試みのための最初のアドレスを選びます。 外国人のエージェントによる状態Code表示拒絶に応じて登録試みが失敗するなら、モバイルノードはそれぞれのその後の広告を出しているアドレスで順番に試みを再試行するかもしれません。
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.
エージェント発見の複数のメソッドが使用中であるときに、モバイルノードSHOULDは最初に、エージェントが他の手段で発見されたものに優先して彼らの広告でMobilityエージェントAdvertisement Extensionsを入れている登録を試みます。 この好みは登録が認識されて、その結果、登録試みの数を最小にするという見込みを最大にします。
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.
そのような広告を捨てることと対照的にモバイルノードはエージェントAdvertisementsで予約されたビットを無視しなければなりません。 このように、後で新しいビットを定義できます、新たに定義されたビットが理解されてさえいないときモバイルノードが広告を使用する能力に影響しないで。
2.4.1. Registration Required
2.4.1. 登録が必要です。
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'ビットがセットした状態でモバイルノードがエージェントAdvertisementを受けるとき、モバイルノードSHOULDは外国人のエージェントを通して登録します、モバイルノードが共同見つけられたそれ自身のものを取得さえできるかもしれないとき注意、-、アドレス。 この特徴が、サイトが承認の交換を必要とする訪問方針(会計などの)を実施するのを許容することを意図します。
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'ビットを設定できます。 したがって、次に、外国人のエージェントは、方針をこれには、モバイルノードに外国人のエージェントを通して登録させるという効果があって、モニターするか、または実施できました。
2.4.2. Move Detection
2.4.2. 検出を動かしてください。
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台の一次機構をモバイルノードに提供します。 また、他のメカニズムは使用されるかもしれません。 モバイルノードがそれを検出するとき、移行して、aが適当のSHOULDレジスタ(セクション3)である、注意、-、新しい外国ネットワークに関するアドレス。 しかしながら、モバイルノードはセクション3.6.3で指定されるように1秒あたりの一度より頻繁に平均的に登録してはいけません。
Perkins Standards Track [Page 26] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[26ページ]RFC3220IP移動性サポート
2.4.2.1. Algorithm 1
2.4.2.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.
移動検出の最初のメソッドはエージェントAdvertisementのICMP Router Advertisement部分の本体の中にLifetime分野に基づいています。 LifetimeがどんなエージェントAdvertisementsにもそのLifetimeまで受け取ったモバイルノードSHOULD記録は期限が切れます。 ノードはモバイルであるなら指定されたLifetimeの中に同じエージェントから別の広告を受け取りません、それ。SHOULDは、そのエージェントから連絡が絶えたと仮定します。 モバイルノードが以前にLifetime分野がまだ期限が切れていない別のエージェントからエージェントAdvertisementを受けたなら、モバイルノードはすぐに、その他のエージェントと共に登録を試みるかもしれません。 さもなければ、モバイルノードSHOULDは、登録する新しいエージェントを発見するのを試みます。
2.4.2.2. Algorithm 2
2.4.2.2. アルゴリズム2
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が新たにエージェントAdvertisementを受けたか否かに関係なく、決定するモバイルノードによるExtensionがいくつか使用されているかもしれないPrefix-長さのケースを受け取った、モバイルノードの電流、注意、-、アドレス 接頭語が異なるなら、モバイルノードは、それが移行したと仮定するかもしれません。 モバイルノードが現在外国人のエージェントを使用している、注意、-、アドレス、現在のエージェントと新しいエージェントの両方が彼らのそれぞれのエージェントAdvertisementsでPrefix-長さのExtensionを入れないなら、モバイルノードSHOULD NOTは移動検出のこのメソッドを使用します。 このExtensionであるなら、1から消えるか、広告、このメソッドの両方が移動検出SHOULD NOTのものです。使用されます。 同様に、aを使用するのがモバイルノードであるなら共同見つけられている、注意、-、アドレス、それ、新しいエージェントがAdvertisementとモバイルノードのExtensionが、電流のネットワーク接頭語が共同場所を見つけたのを知っているPrefix-長さを入れない場合SHOULDが移動検出のこのメソッドを使用しない、注意、-、アドレス。 このメソッドが、現金書留の満了モバイルノードが再登録するよりむしろ移行したのを示す、電流、注意、-、アドレス、モバイルノードは、異なったネットワーク接頭語で新しいAdvertisementを送る外国人のエージェントをaに登録するのを代わりに選ぶかもしれません。 Lifetime分野に従って、新規登録が基づいているエージェントAdvertisementは期限が切れていてはいけません。
2.4.3. Returning Home
2.4.3. 戻っているホーム
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
缶が検出するそれであるときにそれがホームネットワークに返したモバイルノードはそれ自身のホームのエージェントからエージェントAdvertisementを受けます。 そうだとすれば、それ、ホームのエージェント(セクション3)がいるSHOULD deregister。 「反-レジスタ」への試みの前に、モバイルノードSHOULDはホームネットワーク(セクション4.2.1)のために適切に経路指定テーブルを構成します。 コネ
Perkins Standards Track [Page 27] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[27ページ]RFC3220IP移動性サポート
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.
追加、ホームネットワークがARP[36]を使用しているなら、モバイルノードはセクション4.6でARP、プロキシARP、および無料のARPに関して説明された手順に従わなければなりません。
2.4.4. Sequence Numbers and Rollover Handling
2.4.4. 一連番号とロールオーバー取り扱い
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つの連続した値を検出するなら、それが登録されている外国人のエージェントからのエージェントAdvertisementsでは、SHOULDは再び登録します。その2番目は1番目、および範囲0〜255の中のモバイルノード以下です。 2番目の値が1番目より少ないのですが、256以上であるなら、モバイルノードSHOULDは一連番号が最大値(0xffff)を超えてひっくり返って、再登録は必要でないと(セクション2.3)仮定します。
3. Registration
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.
登録メッセージはモバイルノードと、(任意に)外国人のエージェントと、ホームのエージェントの間で情報交換します。 登録がモバイルノードのホームアドレスを関連づけて、ホームのエージェントで付くaの移動性を作成するか、または変更する、それ、注意、-、指定された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
- そして「反-レジスタ」特有である、注意、-、アドレスが保有他の移動性結合をゆったり過ごす。
Perkins Standards Track [Page 28] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[28ページ]RFC3220IP移動性サポート
- discover the address of a home agent if the mobile node is not
configured with this information.
- モバイルノードがこの情報によって構成されないなら、ホームのエージェントのアドレスを発見してください。
3.1. Registration Overview
3.1. 登録概要
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.
- モバイルノードがaが共同場所を見つけた使用である、注意、-、リンクの上の外国人のエージェントからのそれが使用しているエージェントAdvertisementが扱って、受ける、これ、注意、-、アドレス、'R'ビットが受信されたエージェントAdvertisementメッセージに設定されるなら、モバイルノードSHOULDはその外国人のエージェント(またはこのリンクの上の別の外国人のエージェントを通して)を通して登録します。
- If a mobile node is otherwise using a co-located care-of
address, the mobile node MUST register directly with its home
agent.
- そうでなければ、モバイルノードがaが共同場所を見つけた使用である、注意、-、アドレス、モバイルノードは直接ホームのエージェントとともに記名しなければなりません。
- 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.
- モバイルノードがホームネットワークに戻って、ホームのエージェントとともに記名する(de)であるなら、モバイルノードは直接ホームのエージェントとともに記名しなければなりません。
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:
両方の登録手順はRegistration RequestとRegistration Replyメッセージ(セクション3.3と3.4)の交換を伴います。 外国人のエージェントを通して登録するとき、登録手順は以下の4つのメッセージを必要とします:
a) The mobile node sends a Registration Request to the prospective
foreign agent to begin the registration process.
a) モバイルノードは、登録手続を始めるために将来の外国人のエージェントにRegistration Requestを送ります。
b) The foreign agent processes the Registration Request and then
relays it to the home agent.
b) 外国人のエージェントは、Registration Requestを処理して、次に、ホームのエージェントにそれをリレーします。
c) The home agent sends a Registration Reply to the foreign agent
to grant or deny the Request.
c) ホームのエージェントは、Requestを与えるか、または否定するために外国人のエージェントにRegistration Replyを送ります。
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) 外国人のエージェントは、Requestの気質についてそれを知らせるためにRegistration Replyを処理して、次に、モバイルノードにそれをリレーします。
Perkins Standards Track [Page 29] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[29ページ]RFC3220IP移動性サポート
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) モバイルノードはホームのエージェントにRegistration Requestを送ります。
b) The home agent sends a Registration Reply to the mobile node,
granting or denying the Request.
b) Requestを与えるか、または否定して、ホームのエージェントはモバイルノードにRegistration Replyを送ります。
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チェックサムSHOULDをヘッダーで入れられていて、受取人はチェックしなければなりません。 AはUDPチェックサムSHOULDのゼロに合っています。受取人によって受け入れられます。 UDPチェックサムSHOULDが全くそれらの間に存在する移動性セキュリティ協会の一部と定義されていない彼らのパケットの互いの承認に関するモバイルノードとホームのエージェントの振舞い。
3.2. Authentication
3.2. 認証
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アドレスのために移動性セキュリティ協会をサポートすることができなければなりません。 モバイルノードの場合では、これはそのホームAddressであるに違いありません。 認証アルゴリズムのサポートのための要件に関してセクション5.1を見てください。承認のエネイブリングである拡大でモバイルノードとそのホームのエージェントの間の登録メッセージを認証しなければなりません、例えば、モバイルホームAuthentication Extension(セクション3.5.2)。 この拡大は最初の認証拡大であるに違いありません。 モバイルノードが認証を計算した後に他の外国エージェント特有の拡大はメッセージに追加されるかもしれません。
3.3. Registration Request
3.3. 登録要求
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.
モバイルノードは、ホームのエージェントがそのモバイルノード(例えば、新しい生涯がある)で付く移動性を作成するか、または変更できるようにRegistration Requestメッセージを使用することでホームのエージェントとともに記名します。 モバイルノードが登録している外国人のエージェントがホームのエージェントにRequestをリレーするかもしれないか、または直接モバイルノードがaが共同場所を見つけた登録である場合におけるホームのエージェントにそれを送るかもしれない、注意、-、アドレス。
IP fields:
IP分野:
Source Address Typically the interface address from which the
message is sent.
メッセージがどれであるかから送って、インタフェースが扱うソースAddress Typically。
Destination Address Typically that of the foreign agent or the
home agent.
目的地、外国人のエージェントのものかホームのエージェントのAddress Typically。
Perkins Standards Track [Page 30] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[30ページ]RFC3220IP移動性サポート
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
ソースPort変数
Destination Port 434
仕向港434
The UDP header is followed by the Mobile IP fields shown below:
以下に示されたモバイルIP分野はUDPヘッダーのあとに続いています:
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 ...
+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|S|B|D|M|G|r|T|x| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームのエージェント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-
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同時の結合。 '、'ビットは設定されて、モバイルノードは、ホームのエージェントが先の移動性結合を保有するよう要求しています、セクション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'に噛み付いたならセット、モバイルノード意志のdecapsulate自身が発信するデータグラムである、注意、-、アドレス すなわち、モバイルノードがaが共同場所を見つけた使用である、注意、-、アドレス。
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]を使用するというモバイルノード要求はモバイルノードにトンネルを堀りました。
Perkins Standards Track [Page 31] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[31ページ]RFC3220IP移動性サポート
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はゼロとして発信しました。 レセプションでは、無視されます。 SHOULD NOT、いかなる他の用途にはも、割り当ててください。
T Reverse Tunneling requested; see [27].
要求されたT逆のTunneling。 [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ビットの数はマッチングにRegistration Repliesと、登録メッセージの反射攻撃から守るためのRegistration Requestsを使用しました。 セクション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.
Registration Requestの固定部分はセクション3.5に記載されたExtensionsの1つ以上によって続かれています。 すべてのRegistration Requestsに承認のエネイブリングである拡大を含まなければなりません。 そして、セクション3.6.1を見てください、.3、3.7 .2 .2 存在しているとき異なった拡大をRegistration Requestメッセージに置かなければならない相対オーダの情報のために。
Perkins Standards Track [Page 32] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[32ページ]RFC3220IP移動性サポート
3.4. Registration Reply
3.4. 登録回答
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.
移動性エージェントはRegistration Request(セクション3.3)メッセージを送ったモバイルノードにRegistration Replyメッセージを返します。 モバイルノードが外国人のエージェントからサービスを要求していると、その外国人のエージェントは、ホームのエージェントからReplyを受け取って、次に、モバイルノードにそれをリレーするでしょう。 ReplyメッセージはRequestの状態に関するモバイルノードを知らせる必要なコードを含んでいます、オリジナルのRequestより小さいかもしれないホームのエージェントによって与えられた生涯と共に。
The foreign agent MUST NOT increase the Lifetime selected by the mobile node in the Registration Request, since the Lifetime is covered by an authentication extension 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.
外国人のエージェントはRegistration Requestのモバイルノードによって選択されたLifetimeを増強してはいけません、Lifetimeがホームのエージェントで承認を可能にする認証拡大でカバーされているので。 そのような拡大は正確に言えば、(re)が外国人のエージェントに計算されたということであるはずがない認証データを含んでいます。 ホームのエージェントはRegistration Requestのモバイルノードによって選択されたLifetimeを増強してはいけなくて、以来そうするのは外国人のエージェントによって許された最大のRegistration Lifetimeを超えてそれを増強するかもしれません。 Registration Replyに受け取られたLifetimeがRegistration Requestのそれより大きいなら、RequestのLifetimeを使用しなければなりません。 Registration Replyに受け取られたLifetimeがRegistration Requestのそれ以下であるときに、ReplyのLifetimeを使用しなければなりません。
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.
ソースAddress Typicallyはエージェントが返答しているRegistration Requestの送付先アドレスを回避しました。 そして、セクション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
エージェントが返答しているRegistration Requestのソースアドレスからの目的地Address Copied
UDP fields:
UDP分野:
Source Port <variable>
ソースポートの<の可変>。
Destination Port Copied from the source port of the
corresponding Registration Request (Section
3.7.1).
対応するRegistration Request(セクション3.7.1)のソースポートからの目的地Port Copied。
Perkins Standards Track [Page 33] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[33ページ]RFC3220IP移動性サポート
The UDP header is followed by the Mobile IP fields shown below:
以下に示されたモバイルIP分野はUDPヘッダーのあとに続いています:
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 ...
+-+-+-+-+-+-+-+-
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 3 (Registration Reply)
3をタイプしてください。(登録回答)
Code A value indicating the result of the Registration
Request. See below for a list of currently defined Code
values.
Registration Requestの結果を示すA値をコード化してください。 現在定義されたCode値のリストに関して以下を見てください。
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.
Code分野が、登録が受け入れられたのを示すなら、Lifetime分野は登録が満期であると考えられる前に残っている秒数に設定されます。 ゼロの値は、モバイルノードが反登録されたのを示します。 0xffffの値は無限を示します。 Code分野が、登録が否定されたのを示すなら、Lifetime分野の内容を不特定であり、レセプションで無視しなければなりません。
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
64ビットの数はマッチングにRegistration Repliesと、登録メッセージの反射攻撃から守るためのRegistration Requestsを使用しました。 値はそうです。
Perkins Standards Track [Page 34] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[34ページ]RFC3220IP移動性サポート
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.
モバイルノードからのRegistration RequestメッセージからのIdentification分野に基づいたモバイルノードとそのホームのエージェント(それらと、SPI値の間で承認のエネイブリングである拡大で移動性セキュリティ協会によって定義される)の間のセキュリティ文脈で使用される反復操作による保護のスタイルの上で。 セクション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.
Registration Replyの固定部分はセクション3.5に記載されたExtensionsの1つ以上によって続かれています。 ホームのエージェントによって返されたすべてのRegistration Repliesに承認のエネイブリングである拡大を含まなければなりません。 そして、セクション3.7.2を見てください、.2、3.8 .3 .3 Replyメッセージへの拡大のプレースメントでの規則のために。
The following values are defined for use within the Code field. Registration successful:
以下の値はCode分野の中の使用のために定義されます。 登録うまくいく:
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の行政上禁止された不十分なリソース67のモバイルノード失敗した認証68ホームのエージェント失敗した認証69要求されたLifetime長過ぎる70がRequest71を不十分に形成した理由は入手できないReply72要求されたカプセル化を不十分に形成しました; 73人の予約された病人と入手できない77病人、注意、-、アドレス78の登録の手の届かない(ICMP誤りは受信されました)82ホームエージェントタイムアウト80ホームネットワーク(ICMP誤りは受信されました)手の届かない81ホームエージェントのホスト港(ICMP誤りは受信されました)手の届かない88のホームのエージェント手の届かない(受けられた他のICMP誤り)
Perkins Standards Track [Page 35] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[35ページ]RFC3220IP移動性サポート
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の認証133登録Identification130の不十分なリソース131ノード認証132エージェントミスマッチ134がRequest135のあまりに多くの同時の移動性結合136の未知のホームエージェントアドレスを不十分に形成した理由
Up-to-date values of the Code field are specified in the most recent "Assigned Numbers" [40].
Code分野の最新の値は最新の「規定番号」[40]で指定されます。
3.5. Registration Extensions
3.5. 登録拡大
3.5.1. Computing Authentication Extension Values
3.5.1. 認証拡大値を計算します。
The Authenticator value computed for each authentication Extension MUST protect the following fields from the registration message:
各認証Extensionのために計算されたAuthenticator値は登録メッセージから以下の分野を保護しなければなりません:
- the UDP payload (that is, the Registration Request or
Registration Reply data),
- UDPペイロード(すなわち、Registration RequestかRegistration Replyデータ)
- all prior Extensions in their entirety, and
- すべての先のExtensions、全体として。
- the Type, Length, and SPI of this Extension.
- このExtensionのType、Length、および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:
デフォルト認証アルゴリズムは、登録メッセージの128ビットの「メッセージダイジェスト」を計算するのにHMAC-MD5[23]を使用します。 HMACが計算されるデータは以下と定義されます。
- the UDP payload (that is, the Registration Request or
Registration Reply data),
- UDPペイロード(すなわち、Registration RequestかRegistration Replyデータ)
- all prior Extensions in their entirety, and
- すべての先のExtensions、全体として。
- the Type, Length, and SPI of this Extension.
- このExtensionのType、Length、および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価値の計算に含まれていないことに注意してください。 さまざまな認証Extensionsと共に使用されることであるメッセージ確認コードのためのサポート要件の情報に関してセクション5.1を見てください。
Perkins Standards Track [Page 36] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[36ページ]RFC3220IP移動性サポート
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.
認証Extensionsのどれかの中のSecurity Parameter Index(SPI)はAuthenticator値を計算するのに使用されて、受信機で使用する、その値をチェックしなければならないセキュリティ文脈を定義します。 特に、SPIはAuthenticatorを計算する際に使用される認証アルゴリズム、モード(セクション5.1)、および秘密(共有されたキー、または適切な公衆/秘密鍵組)を選択します。 モバイルIPプロトコルの異なった実装の間の相互運用性を確実にするために、実装はそれが実装するどんな認証アルゴリズムとモードにもどんなSPI値も関連づけることができなければなりません。 さらに、モバイルIPのすべての実装が、デフォルト認証が上で指定されたアルゴリズム(HMAC-MD5)であると実装しなければなりません。
3.5.2. Mobile-Home Authentication Extension
3.5.2. 移動住宅認証拡大
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つの承認のエネイブリングである拡大がすべてのRegistration Requests、およびまた、ホームのエージェントによって生成されたすべてのRegistration Repliesに存在していなければなりません。 モバイルホームAuthentication Extensionはいつも本書では指定された登録メッセージのための承認可能にすることです。 この要件がリモートの非制御の伝播からの結果がインターネットで向け直す問題[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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| SPI… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI(cont。) | 固有識別文字… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 32
32をタイプしてください。
Length 4 plus the number of bytes in the Authenticator.
Authenticatorの長さ4とバイト数。
SPI Security Parameter Index (4 bytes). An opaque
identifier (see Section 1.6).
SPI Security Parameter Index(4バイト)。 不明瞭な識別子(セクション1.6を見ます)。
Authenticator (variable length) (See Section 3.5.1.)
固有識別文字(可変長)(セクション3.5.1を見てください。)
3.5.3. Mobile-Foreign Authentication Extension
3.5.3. モバイルに外国の認証拡大
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.
このExtensionはRegistration RequestsとRepliesに移動性セキュリティ協会がモバイルノードと外国人のエージェントの間に存在する場合で含まれるかもしれません。 メッセージ確認コードのためのサポート要件の情報に関してセクション5.1を見てください。
Perkins Standards Track [Page 37] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[37ページ]RFC3220IP移動性サポート
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| SPI… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI(cont。) | 固有識別文字… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 33
33をタイプしてください。
Length 4 plus the number of bytes in the Authenticator.
Authenticatorの長さ4とバイト数。
SPI Security Parameter Index (4 bytes). An opaque
identifier (see Section 1.6).
SPI Security Parameter Index(4バイト)。 不明瞭な識別子(セクション1.6を見ます)。
Authenticator (variable length) (See Section 3.5.1.)
固有識別文字(可変長)(セクション3.5.1を見てください。)
3.5.4. Foreign-Home Authentication Extension
3.5.4. 外国ホーム認証拡大
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.
このExtensionはRegistration RequestsとRepliesに移動性セキュリティ協会が外国人のエージェントとホームのエージェントの間に存在する場合で含まれるかもしれません。 メッセージ確認コードのためのサポート要件の情報に関してセクション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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| SPI… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI(cont。) | 固有識別文字… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 34
34をタイプしてください。
Length 4 plus the number of bytes in the Authenticator.
Authenticatorの長さ4とバイト数。
SPI Security Parameter Index (4 bytes). An opaque
identifier (see Section 1.6).
SPI Security Parameter Index(4バイト)。 不明瞭な識別子(セクション1.6を見ます)。
Authenticator (variable length) (See Section 3.5.1.)
固有識別文字(可変長)(セクション3.5.1を見てください。)
3.6. Mobile Node Considerations
3.6. モバイルノード問題
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
ホームエージェントの各人のためにネットマスクと移動性セキュリティ関係でモバイルノードを構成しなければなりません。 さらに、モバイルノードはホームアドレス、およびIPによって構成されるかもしれません。
Perkins Standards Track [Page 38] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[38ページ]RFC3220IP移動性サポート
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.
ホームのエージェントのより多くのひとりのアドレス。 さもなければ、セクション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.
モバイルノードがホームアドレスによって構成されないなら、それはそれ自体を特定するのにモバイルNode NAI拡張子[6]を使用するかもしれません、そして、Registration RequestのホームAddress分野を0.0に設定してください。.0 .0。 この場合、Registration Replyからホームのエージェントからこの情報を抜粋した後に、モバイルノードはホームアドレスを割り当てることができなければなりません。
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.
- そして、Registration Requestが送って、適切であった外国人のエージェント(Registration Requestの受信者IPアドレス)のリンクレイヤアドレス、注意、-、アドレスがIdentification値が登録を送ったという登録における元々要求されたLifetimeを使用した、--未定の登録の残っているLifetime。
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.
ネットワークの接続性における変化を検出するときはいつも、モバイルノードSHOULDは登録を開始します。 モバイルノードがそのような決断をするかもしれないメソッドに関してセクション2.4.2を見てください。 それが家にいないときに、モバイルノードのRegistration Requestはホームのエージェントにそれで付く移動性を、作成するか、または変更させます。 それがホームにあるとき、モバイルノード(de)の登録Requestはホームのエージェントにそれのための(s)を縛るどんな前の移動性も削除させます。 それがホームにあるとき、モバイルノードは移動性機能のサポートなしで作動します。
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.
モバイルノードSHOULD(re)が外国人のエージェントとともに記名する他の状態があって、ほぼ満了にはそのようなものがモバイルノードがそれを検出するとき、外国人のエージェントがリブートして(セクション2.4.4で指定されるように)、現金書留のLifetimeであるときに時あります。
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.
また、接着点の変化のリンクレイヤしるしが不在のとき、現金書留が期限が切れていないならSHOULD NOTがモバイルノードを新規登録を試みさせる新しいエージェントとそれからのエージェントAdvertisementsはそれが現在登録される外国人のエージェントからエージェントAdvertisementsをまだ受けています。 リンクレイヤ指摘がないとき、モバイルノードは、1秒あたりの一度よりさらにしばしば登録するのを試みてはいけません。
Perkins Standards Track [Page 39] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[39ページ]RFC3220IP移動性サポート
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 Redirectのレセプションを考えてはいけません。 これらの規制の中では、モバイルノードはいつでも、再び登録するかもしれません。
Appendix D shows some examples of how the fields in registration messages would be set up in some typical registration scenarios.
付録Dは登録メッセージの分野がいくつかの典型的な登録シナリオでどうセットアップされるだろうかに関するいくつかの例を示しています。
3.6.1. Sending Registration Requests
3.6.1. 送付登録要求
The following sections specify details for the values the mobile node MUST supply in the fields of Registration Request messages.
以下のセクションはモバイルノードがRegistration Requestメッセージの分野で供給しなければならない値のための詳細を指定します。
3.6.1.1. IP Fields
3.6.1.1. IP分野
This section provides the specific rules by which mobile nodes pick values for the IP header fields of a Registration Request.
このセクションはモバイルノードが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.
- 外国ネットワークに共同見つけられているaに登録する、注意、-、アドレス、IPソースアドレスがそうであるに違いない、注意、-、アドレス
- Otherwise, if the mobile node does not have a home address, the
IP source address MUST be 0.0.0.0.
- 0.0が.0であったに違いなく、モバイルノードがそうしないなら、さもなければ、.0にホームアドレス、IPソースアドレスを持ってください。
- 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-
- 外国人のエージェントとともに記名するとき、対応するエージェントAdvertisementのIPソースアドレスから同じくらい学識があるエージェントのアドレスを使用しなければなりません。 これが現れないアドレスであるかもしれない、広告を出す、注意、-、エージェントでAdvertisementを扱ってください。 このRegistration Requestメッセージを送るとき、さらに、モバイルノードはリンクを使用しなければなりません。
Perkins Standards Track [Page 40] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[40ページ]RFC3220IP移動性サポート
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アドレスを学んだエージェントAdvertisementメッセージのリンクレイヤソースアドレスからコピーされました。
- 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アドレスとしてこのアドレスを使用してはいけません、外国人のエージェントを通して登録するとき、それはホームエージェントアドレスとしてRegistration Requestのボディーで使用されるかもしれませんが。
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]に従って、適当な値は選ばれるべきです。
3.6.1.2. Registration Request Fields
3.6.1.2. 登録要求分野
This section provides specific rules by which mobile nodes pick values for the fields within the fixed portion of a Registration Request.
このセクションはモバイルノードが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)を縛る先の移動性を維持するよう要求するために、噛み付かれます。 さもなければ、ホームのエージェントは、どんな前の結合も削除して、それらをRegistration Requestで指定された新しい結合に取り替えます。 複数の同時の移動性結合が少なくとも1つのワイヤレス・ネットワークインタフェースを使用するモバイルノードが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.
共同見つけられているaに登録しているならモバイルノードSHOULDが'D'ビットを設定する、注意、-、アドレス。 さもなければ、'D'ビットを設定してはいけません。
Perkins Standards Track [Page 41] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[41ページ]RFC3220IP移動性サポート
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:
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:
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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.
Perkins Standards Track [Page 42] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 42] RFC 3220 IP Mobility Support for IPv4 January 2002
a) The IP header, followed by the UDP header, followed by the
fixed-length portion of the Registration Request, followed by
a) The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by
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) 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
c) An authorization-enabling extension, followed by
c) An authorization-enabling extension, followed by
d) If present, any non-authentication Extensions used only by the
foreign agent, followed by
d) If present, any non-authentication Extensions used only by the foreign agent, followed by
e) The Mobile-Foreign Authentication Extension, if present.
e) The Mobile-Foreign Authentication Extension, if present.
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.
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.
3.6.2. Receiving Registration Replies
3.6.2. Receiving Registration Replies
Registration Replies will be received by the mobile node in response to its Registration Requests. Registration Replies generally fall into three categories:
Registration Replies will be received by the mobile node in response to its Registration Requests. Registration Replies generally fall into three categories:
- the registration was accepted,
- the registration was denied by the foreign agent, or
- the registration was denied by the home agent.
- 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.
The remainder of this section describes the Registration Reply handling by a mobile node in each of these three categories.
3.6.2.1. Validity Checks
3.6.2.1. Validity Checks
Registration Replies with an invalid, non-zero UDP checksum MUST be silently discarded.
Registration Replies with an invalid, non-zero UDP checksum MUST be silently discarded.
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.
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.
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
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
Perkins Standards Track [Page 43] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 43] RFC 3220 IP Mobility Support for IPv4 January 2002
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:
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) 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.
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) 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.
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 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.
3.6.2.2. Registration Request Accepted
3.6.2.2. Registration Request Accepted
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).
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).
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.
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.
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
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
Perkins Standards Track [Page 44] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 44] RFC 3220 IP Mobility Support for IPv4 January 2002
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.
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.2.3. Registration Request Denied
3.6.2.3. Registration Request Denied
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:
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)
Code 69: (Denied by foreign agent, Lifetime too long)
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.
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)
Code 133: (Denied by home agent, Identification mismatch)
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.
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.
Code 136: (Denied by home agent, Unknown home agent address)
Code 136: (Denied by home agent, Unknown home agent address)
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
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
Perkins Standards Track [Page 45] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 45] RFC 3220 IP Mobility Support for IPv4 January 2002
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.
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.3. Registration Retransmission
3.6.3. Registration Retransmission
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.
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.
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.
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.
3.7. Foreign Agent Considerations
3.7. Foreign Agent Considerations
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.
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.
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
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
Perkins Standards Track [Page 46] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 46] RFC 3220 IP Mobility Support for IPv4 January 2002
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.
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.
3.7.1. Configuration and Registration Tables
3.7.1. Configuration and Registration Tables
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:
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.
- 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.
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]).
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]).
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).
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).
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
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
Perkins Standards Track [Page 47] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 47] RFC 3220 IP Mobility Support for IPv4 January 2002
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.
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.7.2. Receiving Registration Requests
3.7.2. Receiving Registration Requests
If the foreign agent accepts a Registration Request from a mobile node, it checks to make sure that the indicated home agent address does not belong to any network interface of the foreign agent. If not, the foreign agent then MUST relay the Request to the indicated home agent. Otherwise, if the foreign agent denies the Request, it MUST send a Registration Reply to the mobile node with an appropriate denial Code, except in cases where the foreign agent would be required to send out more than one such denial per second to the same mobile node. The following sections describe this behavior in more detail.
If the foreign agent accepts a Registration Request from a mobile node, it checks to make sure that the indicated home agent address does not belong to any network interface of the foreign agent. If not, the foreign agent then MUST relay the Request to the indicated home agent. Otherwise, if the foreign agent denies the Request, it MUST send a Registration Reply to the mobile node with an appropriate denial Code, except in cases where the foreign agent would be required to send out more than one such denial per second to the same mobile node. The following sections describe this behavior in more detail.
If the foreign agent has configured one of its network interfaces with the IP address specified by the mobile node as its home agent address, the foreign agent MUST NOT forward the request again. If the foreign agent serves the mobile node as a home agent, the foreign agent follows the procedures specified in section 3.8.2. Otherwise, if the foreign agent does not serve the mobile node as a home agent, the foreign agent rejects the Registration Request with code 136 (unknown home agent address).
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).
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.
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.
Perkins Standards Track [Page 48] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 48] RFC 3220 IP Mobility Support for IPv4 January 2002
3.7.2.1. Validity Checks
3.7.2.1. Validity Checks
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).
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).
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.
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.
3.7.2.2. Forwarding a Valid Request to the Home Agent
3.7.2.2. Forwarding a Valid Request to the Home Agent
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:
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.
- 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:
Specific fields within the IP header and the UDP header of the relayed Registration Request MUST be set as follows:
Perkins Standards Track [Page 49] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 49] RFC 3220 IP Mobility Support for IPv4 January 2002
IP Source Address
IP Source Address
The foreign agent's address on the interface from which
the message will be sent.
The foreign agent's address on the interface from which the message will be sent.
IP Destination Address
IP Destination Address
Copied from the Home Agent field within the Registration
Request.
Copied from the Home Agent field within the Registration Request.
UDP Source Port
UDP Source Port
<variable>
<variable>
UDP Destination Port
UDP Destination Port
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.
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.
3.7.2.3. Denying Invalid Requests
3.7.2.3. Denying Invalid Requests
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 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.
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.
Specific fields within the IP header and the UDP header of the Registration Reply MUST be set as follows:
Specific fields within the IP header and the UDP header of the Registration Reply MUST be set as follows:
Perkins Standards Track [Page 50] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 50] RFC 3220 IP Mobility Support for IPv4 January 2002
IP Source Address
IP Source Address
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.
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 Destination Address
IP Destination Address
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.
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.
UDP Source Port
UDP Source Port
434
434
UDP Destination Port
UDP Destination Port
Copied from the UDP Source Port of the Registration
Request.
Copied from the UDP Source Port of the Registration Request.
3.7.3. Receiving Registration Replies
3.7.3. Receiving Registration Replies
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.
ホームのエージェントから有効なRegistration Replyを受けるとき、外国人のエージェントは訪問者リストをアップデートします。 そして、それはモバイルノードにRegistration Replyをリレーします。 以下のセクションはさらに詳細にこの振舞いについて説明します。
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.
ホームのエージェントにRegistration Requestをリレーすることに関して外国人のエージェントはRegistration Replyの代わりにICMPエラーメッセージを受け取って、次に、外国人のエージェントSHOULDは(範囲の中で80-95で、包括的)の適切な「ホームのエージェント手の届かない」失敗CodeとRegistration Replyをモバイルノードに送ります。 セクション3.7を見てください。.2 .3 Registration Replyを造ることに関する詳細のために。
Perkins Standards Track [Page 51] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[51ページ]RFC3220IP移動性サポート
3.7.3.1. Validity Checks
3.7.3.1. バリディティチェック
Registration Replies with an invalid, non-zero UDP checksum MUST be silently discarded.
無効の非ゼロUDPチェックサムで静かに登録Repliesを捨てなければなりません。
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.
外国人のエージェントがRegistration Replyメッセージを受け取るとき、それはReplyにみられるように同じモバイルノードホームアドレスで未定のRegistration Requestのための訪問者リストを捜さなければなりません。 Registration Replyがゼロモバイルのノードホームアドレスでどんな未定のRegistration Requestにも対応していないなら(セクション3.7.1を見てください)そのようなどれか未定のRequestが見つけられないなら、外国人のエージェントは静かにReplyを捨てなければなりません。 また、ReplyのIdentification分野の下位の32ビットがRequestでそれらに合っていないなら、外国人のエージェントは静かにReplyを捨てなければなりません。
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.
また、Registration Replyでの認証をチェックしなければなりません。 外国人のエージェントとホームのエージェントが移動性セキュリティ協会を共有するなら、ちょうど1Foreign-ホームAuthentication ExtensionがRegistration Replyに存在していなければなりません、そして、外国人のエージェントはExtensionでAuthenticator値をチェックしなければなりません。 Foreign-ホームAuthentication Extensionが全く見つけられないか、1Foreign-ホームAuthentication Extensionが見つけられる、またはAuthenticatorが無効であるなら、外国人のエージェントは静かにReplyを捨てなければなりません、そして、SHOULDはセキュリティ例外としてイベントを登録します。 外国人のエージェントもモバイルノードの登録を拒絶しなければなりません、そして、SHOULDはCode68とのモバイルノードにRegistration Replyを送ります。
3.7.3.2. Forwarding Replies to the Mobile Node
3.7.3.2. 推進はモバイルノードに答えます。
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のバリディティチェックを満たすか。Registration Reply、.2 .1 モバイルノードにリレーされます。 また、モバイルノードがRegistration Requestの結果を反映するように、外国人のエージェントは訪問者リストエントリーをアップデートしなければなりません、ReplyのCode分野によって示されるように。 Codeが、ホームのエージェントが登録を受け入れたのを示して、Lifetime分野が非零であるなら、外国人のエージェントSHOULDは以下の2つの値の最小限への訪問者リストエントリーにLifetimeをはめ込みます:
- the value specified in the Lifetime field of the Registration
Reply, and
- そして値がRegistration ReplyのLifetime分野で指定した。
- 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
Codeが、Lifetime分野がゼロであることを代わりに示すなら、外国人のエージェントはモバイルノードのための訪問者リストエントリーを削除しなければなりません。 最終的に、Codeがそれを示すなら、登録は否定されました。
Perkins Standards Track [Page 52] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[52ページ]RFC3220IP移動性サポート
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.
外国人のエージェントは突き抜けて含んでいることへのRegistration Replyの固定部分でモバイルホームAuthentication Extensionを始める分野のいずれも変更してはいけません。 さもなければ、認証失敗はモバイルノードに非常に起こりそうです。
In addition, the foreign agent SHOULD perform the following additional procedures:
さらに、外国人のエージェントSHOULDは以下の追加手順を実行します:
- 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.
- そして、モバイルホームAuthentication Extensionに続いて、それは、どんなExtensionsも処理して、取り外さなければなりません--それ自身の関連性の非認証Extensionsをモバイルノードに追加するかもしれません、適切であるなら--モバイルに外国のAuthentication Extensionを追加しなければなりません、外国人のエージェントがモバイルノードとの移動性セキュリティ協会を共有するなら。
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.
セクション3.7.2で.3に指定された同じ規則に従って、リレーされたRegistration ReplyのIPヘッダーとUDPヘッダーの中の特定の分野は設定されます。
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.
有効なRegistration Replyをモバイルノードに送った後に、外国人のエージェントは以下のこの登録のための訪問者リストエントリーをアップデートしなければなりません。 Registration Replyが、登録がホームのエージェントによって受け入れられたのを示すなら、外国人のエージェントはRegistration Replyで与えられたLifetimeに登録の生涯のタイマをリセットします。 Registration Replyメッセージを転送するとき、始める.2、外国人のエージェントがこの生涯を考えるセクション3.6.2における、モバイルノードの説明されるとしての登録生涯のタイミングと異なって、外国人のエージェントがモバイルノードの前に登録を吐き出さないのを確実にするのはそうします。 他方では、Registration Replyが、登録がホームのエージェントによって拒絶されたのを示すなら、外国人のエージェントはこの試みられた登録のための訪問者リストエントリーを削除します。
3.8. Home Agent Considerations
3.8. ホームエージェント問題
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.
ホームのエージェントは登録手続における反応役割を果たします。 ホームのエージェントは、モバイルノード(恐らく外国人のエージェントによってリレーされる)からRegistration Requestsを受けて、このモバイルノードのために移動性結合に関する記録をアップデートして、それぞれに対応して適当なRegistration Replyを発行します。
Perkins Standards Track [Page 53] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[53ページ]RFC3220IP移動性サポート
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.
Registration Requestに答えるのがモバイルノードから受信された時以外に、ホームのエージェントはRegistration Replyを伝えてはいけません。 特に、ホームのエージェントは、Lifetimeが期限が切れたのを示すためにRegistration Replyを生成してはいけません。
3.8.1. Configuration and Registration Tables
3.8.1. 構成とレジスタ・テーブル
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:
ホームのエージェントがそれがホームのエージェントとして勤めるモバイルノードから有効なRegistration Requestを受け入れるとき、ホームのエージェントは、移動性の拘束力があるリスト含有でこのモバイルノードのためのエントリーを作成しなければならないか、または変更しなければなりません:
- 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
- モバイルノードのホームアドレス--、モバイルノードのもの、注意、-、アドレス--Registration ReplyからのIdentification分野--登録の残っているLifetime
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.
ホームのエージェントは任意にダイナミックにそのモバイルノードからRegistration Requestを受けるときのモバイルノードにホームアドレスを関連づける能力を提供するかもしれません。 ホームアドレスがモバイルノードに割り当てられるメソッドはこのドキュメントの範囲を超えていますが、[6]を見てください。 ホームのエージェントがホームアドレスの協会をモバイルノードにした後に、ホームのエージェントはRegistration ReplyのホームAddress分野にそのホームアドレスを入れなければなりません。
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.
また、ホームのエージェントは様々な外国人のエージェントとの移動性セキュリティ仲間を維持するかもしれません。 ホームのエージェントが外国人のエージェントとの移動性セキュリティ仲間を共有するなら外国人のエージェントからRegistration Requestを受けるとき、ホームのエージェントはメッセージの必要なForeign-ホームAuthentication ExtensionでAuthenticatorをチェックしなければなりません、この移動性セキュリティ協会に基づいて。 ホームのエージェントが外国人のエージェントとの移動性セキュリティ仲間を共有するなら外国人のエージェントにRegistration Replyを送るとき、同様に、ホームのエージェントはメッセージでForeign-ホームAuthentication Extensionを入れなければなりません、この移動性セキュリティ協会に基づいて。
Perkins Standards Track [Page 54] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[54ページ]RFC3220IP移動性サポート
3.8.2. Receiving Registration Requests
3.8.2. 登録要求を受け取ります。
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).
ホームのエージェントが入って来るRegistration Requestを受け入れるなら、それは(s)を縛るモバイルノードの移動性に関する記録をアップデートしなければなりません、そして、SHOULDは適当なCodeとRegistration Replyを送ります。 そうでなければ(ホームのエージェントはRequestを否定する)、それ、適切なCodeがRequestが否定された理由を指定している状態で、SHOULDはRegistration Replyを送ります。 以下のセクションはさらに詳細にこの振舞いについて説明します。 ホームのエージェントが放送をサポートしないなら(セクション4.3を見てください)、それは'B'ビット(Registration Requestを拒絶することと対照的に)を無視しなければなりません。
3.8.2.1. Validity Checks
3.8.2.1. バリディティチェック
Registration Requests with an invalid, non-zero UDP checksum MUST be silently discarded by the home agent.
ホームのエージェントは無効の非ゼロUDPチェックサムで静かに登録Requestsを捨てなければなりません。
The authentication in the Registration Request MUST be checked. This involves the following operations:
Registration Requestでの認証をチェックしなければなりません。 これは以下の操作にかかわります:
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つの承認のエネイブリングである拡大がRegistration Requestに存在していなければなりません。 そして、ホームのエージェントは、拡大でAuthenticator値をチェックしなければならないか、または固有識別文字値がそれがセキュリティ協会を持っている別のエージェントによってチェックされたことを確かめなければなりません。 承認のエネイブリングである拡大が全く見つけられないか、1つ以上の承認のエネイブリングである拡大が見つけられる、またはAuthenticatorが無効であるなら、ホームのエージェントはモバイルノードの登録を拒絶しなければなりません、そして、SHOULDはCode131とのモバイルノードにRegistration Replyを送ります。 次に、ホームのエージェントはRequestを捨てなければなりません、そして、SHOULDはセキュリティ例外として誤りを登録します。
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) ホームのエージェントは、登録Identification分野が承認のエネイブリングである拡大の中でSPIによって選択された文脈を使用することで正しいのをチェックしなければなりません。 これがどう実行されるかに関する記述に関してセクション5.7を見てください。 不正確です、ホームのエージェントがRequestを拒絶しなければならなくて、SHOULDがCode133とのモバイルノードにRegistration Replyを送るなら、セクション5.7で指定された規則に従って、Identification分野を含んでいるのは計算されました。 ホームのエージェントはこれ以上そのようなRequestと処理をしてはいけなくて、それですが、SHOULDはセキュリティ例外として誤りを登録します。
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
c) ホームのエージェントが外国人のエージェントとの移動性セキュリティ仲間を共有するなら、ホームのエージェントは有効なForeign-ホームAuthentication Extensionの存在がないかどうかチェックしなければなりません。 ちょうど1
Perkins Standards Track [Page 55] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[55ページ]RFC3220IP移動性サポート
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.
外国ホームAuthentication Extensionはこの場合Registration Requestに存在していなければなりません、そして、ホームのエージェントはExtensionでAuthenticator値をチェックしなければなりません。 Foreign-ホームAuthentication Extensionが全く見つけられないか、1Foreign-ホームAuthentication Extensionが見つけられる、またはAuthenticatorが無効であるなら、ホームのエージェントはモバイルノードの登録を拒絶しなければなりません、そして、SHOULDはCode132とのモバイルノードにRegistration Replyを送ります。 次に、ホームのエージェントはRequestを捨てなければなりません、そして、SHOULDはセキュリティ例外として誤りを登録します。
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.
Registration Requestで認証をチェックすることに加えて、ホームのエージェントはホームネットワーク(ホームのエージェントへのユニキャストであることと対照的に)のサブネットで指示された放送演説に送られるRegistration Requestsを否定しなければなりません。 136のCodeとRegistration Replyを返して、ホームのエージェントはRequestとSHOULDを捨てなければなりません。 この場合、Registration Replyはホームのエージェントのユニキャストアドレスを含むでしょう、モバイルノードが正しいホームエージェントアドレスでRegistration Requestを再発行できるように。
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 彼らが、ダイナミックなホームがエージェント発見であるとサポートしたいなら。
3.8.2.2. Accepting a Valid Request
3.8.2.2. 有効な要求を受け入れます。
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.
Registration Requestがセクション3.8.2におけるバリディティチェックを満たすなら、.1、およびホームのエージェントはそうです。Requestを収容できます、ホームのエージェントは要求のモバイルノードのために移動性の拘束力があるリストをアップデートしなければならなくて、モバイルノードにRegistration Replyを返さなければなりません。
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.
この場合、ホームのエージェントが同時の移動性に結合、または1をサポートして、0でないなら、Reply Codeは0歳になるでしょう。 Registration Replyメッセージを築き上げることに関する詳細に関してセクション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:
ホームのエージェントは以下のモバイルノードの移動性結合に関する記録をアップデートします、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.
- そして、Lifetimeがゼロである、Care、-、Addressはモバイルノードのホームアドレスと等しく、ホームのエージェントは要求のモバイルノードのための移動性の拘束力があるリストにおけるエントリーのすべてを削除します。 これはモバイルノードが、ホームのエージェントが、移動性サービスを提供するのをやめるようどう要求するかということです。
Perkins Standards Track [Page 56] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[56ページ]RFC3220IP移動性サポート
- 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.
- そして、Lifetimeがゼロである、Care、-、Addressがモバイルノードのホームアドレスと等しくなく、ホームのエージェントが指定を含むエントリーだけを削除する、Care、-、移動性結合からのAddressは要求のモバイルノードのために記載します。 もう一方を含むいかなる他の活発なエントリー、も注意、-、アドレスはアクティブなままで残るでしょう。
- 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.
- ホームのエージェントがLifetimeが非零であるなら、要求を含むエントリーを加える、Care、-、移動性結合へのAddressはモバイルノードのために記載します。 '、'ビットは設定されて、ホームのエージェントは、同時の移動性が結合であるとサポートして、前の移動性の拘束力があるエントリーは保有されます。 さもなければ、ホームのエージェントはモバイルノードのための移動性の拘束力があるリストにおける前のすべてのエントリーを取り除きます。
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.
すべての場合では、ホームのエージェントがそれより本当に、異なった外国人のエージェントであるかもしれないRegistration Requestの源にRegistration Replyを送らなければならない、だれのもの、注意、-、アドレスは登録されています(de)。 ホームのエージェントが外国人のエージェントとの移動性セキュリティ仲間を共有する、だれのもの、注意、-、その外国人のエージェントがRegistration Requestをリレーしたものと異なっている、アドレスが反登録されていて、ホームのエージェントがさらに、外国人のエージェントにRegistration Replyを送るかもしれない、だれのもの、注意、-、アドレスは反登録されています。 それが外国人のエージェントとの移動性セキュリティ仲間を共有しないなら、ホームのエージェントはそのようなReplyを送ってはいけません。 オリジナルのLifetimeが期限が切れるとき、Replyを全く送らないと、外国人のエージェントの訪問者リストは自然に期限が切れるでしょう。
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.
ホームのエージェントはRegistration Requestのモバイルノードによって指定されたそれの上でLifetimeを増強してはいけません。 しかしながら、それはモバイルノードがホームのエージェントが望んでいるより長い間受け入れるようLifetimeに要求する誤りではありません。 この場合、ホームのエージェントは、Lifetimeを許容値に単に減少させて、Registration Replyでこの値を返します。 Registration ReplyのLifetime値は登録の与えられた生涯のモバイルノードを知らせます、それであるときに、SHOULDが継続的なサービスを維持するために再登録するのを示して。 この登録生涯の満了の後に、ホームのエージェントは移動性の拘束力があるリストにおけるこの登録のためのエントリーを削除しなければなりません。
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.
Registration Requestが受け入れられた現在のRegistration Requestをコピーするなら、新しいLifetimeは元々与えられたLifetimeを超えて広がってはいけません。 ホームアドレスであるならRegistration Requestが写しである、注意、-、アドレス、Identification分野は受け入れられた現金書留のものとすべて等しいです。
Perkins Standards Track [Page 57] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[57ページ]RFC3220IP移動性サポート
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]であると実装して、Registration Requestが、以前に縛らないことを持っていたモバイルノードにおいて拘束力があった状態で移動性を作成するようにホームのエージェントに頼むなら(以前に、モバイルノードがホームにあると思われました)、ホームのエージェントはセクション4.6でARP、プロキシARP、および無料のARPに関して説明された手順に従わなければなりません。 モバイルノードに前の移動性結合が既にあったなら、ホームのエージェントは、セクション4.6で説明されたプロキシARPのために約束を守り続けなければなりません。
3.8.2.3. Denying an Invalid Request
3.8.2.3. 無効の要求を否定します。
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.
Registration Replyがセクション3.8.2におけるバリディティチェックのすべてを満たさないなら、.1、またはホームのエージェントがそうです。Requestを収容できません、ホームエージェントSHOULDは誤りの理由を示すCodeとのモバイルノードにRegistration Replyを返します。 外国人のエージェントがRequestをリレーするのにかかわったなら、これで、外国人のエージェントは未定の訪問者リストエントリーを削除できます。 また、これは、誤りを修正して、別のRequestを発行するのを試みることができるように誤りの理由のモバイルノードを知らせます。
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.
このセクションは、ホームのエージェントがRequestを拒絶するかもしれない多くの理由をリストアップして、それがどの場合にも使用するべきであるCode値を提供します。 Registration Replyメッセージを築き上げることに関する追加詳細に関してセクション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があるRegistration Replyを返すことによって。 同様に、ホームのエージェントは、129のCodeと共に権限のないサービスエリアにRegistration Replyを返すことによって入ったモバイルノードに対するサービスを承諾するのを拒否するかもしれません。
Requests with non-zero bits in reserved fields MUST be rejected with code 134 (poorly formed request).
コード134(不十分に形成された要求)で非ゼロ・ビットが予約された分野にある要求を拒絶しなければなりません。
3.8.3. Sending Registration Replies
3.8.3. 送付登録回答
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.
ホームのエージェントがRegistration Requestを受け入れるなら、それは(s)を縛るモバイルノードの移動性に関する記録をアップデートしなければなりません、そして、SHOULDは適当なCodeとRegistration Replyを送ります。 そうでなければ(ホームのエージェントはRequestを否定した)、それ、適切なCodeがRequestが否定された理由を指定している状態で、SHOULDはRegistration Replyを送ります。 以下のセクションはホームのエージェントがRegistration Replyメッセージの分野で供給しなければならない値のための追加詳細を明らかにします。
Perkins Standards Track [Page 58] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[58ページ]RFC3220IP移動性サポート
3.8.3.1. IP/UDP Fields
3.8.3.1. IP/UDP分野
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に値を選ぶ特定の規則にRegistration Replyのヘッダーフィールドを提供します。
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.
Registration RequestのIP Destination AddressからのIP Source Address Copiedマルチキャストか放送演説が使用されなかったなら。 Registration RequestのIP Destination Addressが放送かマルチキャストアドレスであったなら、Registration ReplyのIP Source Addressはホームのエージェントの(ユニキャスト)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.
そして、モバイルノードの反登録を要求したRegistration Requestに対応してRegistration Replyを送る、(Lifetimeがゼロである、Care、-、Addressはモバイルノードのまた、IP Source Addressがどれであったかにモバイルノードのホームアドレスに設定された(これはホームネットワークに戻るときモバイルノードによって「反-レジスタ」に使用される正常なメソッドです)ホームアドレスと等しいです; Registration ReplyのIP Destination Addressはモバイルノードのホームアドレスに用意ができるでしょう、RequestのIP Source Addressからコピーされるように。
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.
この場合Registration Replyを伝えるとき、まるでモバイルノードがホームにあるかのようにホームのエージェントは直接ホームネットワークにReplyを伝えなければなりません、目的地モバイルノードのためにホームのエージェントにまだ存在しているどんな移動性の拘束力があるリストエントリーも迂回させて。 ともに記名された後に家に帰るモバイルノードのために特定である、注意、-、アドレス、モバイルノードの新しいRegistration Requestがホームのエージェントによって受け入れられないなら、それでも、モバイルノードが、モバイルノードに扱われたデータグラムがモバイルノードのものにトンネルを堀られるべきであるのを示すので移動性の拘束力があるリストエントリーが登録された、注意、-、アドレス。 Registration ReplyにこのRequestの拒絶を示させるとき、リストエントリーを縛るこの存在を無視しなければなりません、そして、まるでモバイルノードがホームにあるかのようにホームのエージェントはこのReplyを伝えなければなりません。
Perkins Standards Track [Page 59] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[59ページ]RFC3220IP移動性サポート
3.8.3.2. Registration Reply Fields
3.8.3.2. 登録回答分野
This section provides the specific rules by which home agents pick values for the fields within the fixed portion of a Registration Reply.
このセクションはホームのエージェントが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.
前項で指定された規則に従って、Registration ReplyのCode分野は選ばれています。 受け入れられた登録に答えるとき、SHOULDがそれであるならCode1と共に反応させるホームのエージェントは同時の登録証明書をサポートしません。
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).
Registration Requestの対応する分野からLifetime分野をコピーしなければなりません、要求された値がホームのエージェントが要求されたサービスを提供しても構わないと思う時の最大の長さほど大きくない場合。 このような場合には、Lifetimeはサービスが実際にホームのエージェントによって提供される時間の長さに用意ができなければなりません。 そして、これが許容された最大のLifetimeがホームのエージェントであったならLifetime SHOULDを減少させた、(このモバイルノード、注意、-、アドレス)
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.
Registration RequestのホームAddress分野が非零であるなら、Registration ReplyメッセージのホームAddress分野にそれをコピーしなければなりません。 さもなければ、Registration RequestのホームAddress分野が指定されるとしてセクション3.6のゼロであるなら、ホームのエージェントSHOULDはモバイルノードのためにホームアドレスの選択を準備して、Registration ReplyメッセージのホームAddress分野に選択されたアドレスを挿入します。 モバイルノードがそれらの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.
Registration Requestのホームエージェント分野がこのホームのエージェントのユニキャストアドレスを含んでいるなら、Registration Replyのホームエージェント分野にその分野をコピーしなければなりません。 さもなければ、ホームのエージェントはユニキャストアドレスへのRegistration Replyにホームエージェント分野をはめ込まなければなりません。 この後者の場合では、ホームのエージェントは、モバイルノードが同時にことによると2人以上のホームのエージェントに登録されるのを防ぐために適当なコード(例えば、Code136)で登録を拒絶しなければなりません。
3.8.3.3. Extensions
3.8.3.3. 拡大
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:
このセクションはホームのエージェントがRegistration Replyに追加するどんな必要なExtensionsとどんな任意のモバイルIP Extensionsの注文についても説明します。 以下の注文に続かなければなりません:
a) The IP header, followed by the UDP header, followed by the
fixed-length portion of the Registration Reply,
a) UDPヘッダーによってついて来られたIPヘッダーはRegistration Replyの固定長一部のそばで続きました。
Perkins Standards Track [Page 60] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[60ページ]RFC3220IP移動性サポート
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) 存在しているなら、どんな非認証Extensionsもモバイルで、ノード(また、外国人のエージェントが使用されるかもしれない)を使用しました。
c) The Mobile-Home Authentication Extension,
c) 移動住宅認証拡大
d) If present, any non-authentication Extensions used only by the
foreign agent, and
d) そして存在しているなら、どんな非認証Extensionsも外国人のエージェントを使用した。
e) The Foreign-Home Authentication Extension, if present.
e) Foreign-ホームAuthentication Extension存在しているなら。
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)がホームのエージェントによって送られたあらゆるRegistration Replyに現れなければならないことに注意してください。 項目(b)、(d)、および(e)は任意です。 しかしながら、ホームのエージェントと外国人のエージェントが移動性セキュリティ協会を共有するとき、項目(e)を含まなければなりません。
4. Routing Considerations
4. ルート設定問題
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でホームのエージェントに関するモバイルノードのホームアドレスの相対的位置、および登録するのをそれと試みるかもしれないどんな外国人のエージェントに関するモバイルノード自体に関してもプロトコル概要を見てください。
4.1. Encapsulation Types
4.1. カプセル化タイプ
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カプセル化[32]にIPを使用して、ホームのエージェントと外国人のエージェントは、トンネリングがデータグラムであるとサポートしなければなりません。 共同見つけられたaを使用するどんなモバイルノード、も注意、-、アドレスはIPカプセル化にIPを使用することでトンネルを堀られたデータグラムを受信に支えなければなりません。 最小量のカプセル化[34]とGREカプセル化[16]は移動性エージェントとモバイルノードによって任意にサポートされるかもしれない代替のカプセル化メソッドです。 モバイルノードによって要求されると、これらの選択方式のカプセル化の使用はホームのエージェントの裁量でそうではありません。
4.2. Unicast Datagram Routing
4.2. ユニキャストデータグラムルート設定
4.2.1. Mobile Node Considerations
4.2.1. モバイルノード問題
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
ホームネットワークに関連づけられると、モバイルノードは移動性サービスのサポートなしで作動します。 いかなる他の(修理される)のホストかルータとも同様に、すなわち、それは作動します。 ホームに関連づけられるとモバイルノードがデフォルトルータを選択するメソッド
Perkins Standards Track [Page 61] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[61ページ]RFC3220IP移動性サポート
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.
aが共同場所を見つけたホームと使用から遠くのネットワーク、またはいつ、注意、-、アドレスはこのドキュメントの範囲の外のそうであるか。 ICMP Router Advertisement[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.
- モバイルノードが外国人のエージェントを使用することで登録されている、注意、-、アドレス、それは最初に、ホップルータとして外国人のエージェントを使用するかもしれません。 エージェントAdvertisementから外国人のエージェントのMACアドレスについて学習できます。 さもなければ、モバイルノードはそのエージェントAdvertisementメッセージのICMP Router Advertisement部分の広告に掲載されたRouter Addressesからデフォルトルータを選ばなければなりません。
- 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.
- モバイルノードが直接aが共同場所を見つけたホームエージェント使用に登録される、注意、-、アドレス、次に、モバイルノードSHOULDが受信するというそれを外部的に得てあるどんなICMP Router Advertisementメッセージも広告に掲載されたものからデフォルトルータを選ぶ、注意、-、アドレスとRouter Addressはネットワーク接頭語の下で合っています。 外部的にモバイルノードを得た、注意、-、アドレスはネットワーク接頭語の下でエージェントAdvertisementのIPソースアドレスに合って、また、モバイルノードは、そのIPソースアドレスがデフォルトルータのIPアドレスのための別の可能な選択であるとみなすかもしれません。 ネットワーク接頭語は、Router AdvertisementのPrefix-長さのExtensionから得て、存在しているかもしれません。 また、このドキュメントの範囲を超えた他のメカニズムを通して接頭語を得るかもしれません。
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 Router Advertisement部分からのRouter Addressesの(ことによると空)のリストは、モバイルノードに放送ARPを伴わないいくつかの手段がない場合デフォルトルータを選択することの役に立たないで、またリストでルータの1つのMACアドレスを得るためのこのドキュメントの中に指定されません。 同様に、入手のための不特定のメカニズムがないとき、MACは外国ネットワークで他にルータを向け直します外国ネットワーク、モバイルノードに関するアドレスが、無視しなければならない。
4.2.2. Foreign Agent Considerations
4.2.2. 外国エージェント問題
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
カプセル化されたデータグラムを受け取り次第発信する、それの広告を出した、注意、-、アドレス、外国人のエージェントは訪問者リストにおけるそれらのエントリーと内側の送付先アドレスを比較しなければなりません。 いつなしで目的地は何か現在、訪問者リストのモバイルノードのアドレスに合わないで、外国人のエージェントはデータグラムを進めてはいけませんか。
Perkins Standards Track [Page 62] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[62ページ]RFC3220IP移動性サポート
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ヘッダーへの変更であり、ルーティング輪は、そうでないので、なりそうです。 捨てられて、データグラムSHOULDは静かにそうです。 外国人のエージェントが入って来るトンネルを堀られたデータグラムを進めることができないとき、ICMP Destination Unreachableを送ってはいけません。 さもなければ、外国人のエージェントはdecapsulatedデータグラムをモバイルノードに送ります。
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 Header Checksumについて確かめなければならないことを意味して、減少がIP Time To Liveであり、recomputeがIP Header Checksumであり、フォワードはデフォルトルータへのそのようなデータグラムです。
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を使用してはいけません。 それは、モバイルノードから伝えられたエージェントSolicitationかRegistration Requestから情報をコピーすることによって、MACアドレスを得るかもしれません。 モバイルノードの訪問者リストエントリーが期限が切れる前にモバイルノードのIPアドレスのための外国人のエージェントのARPキャッシュを期限が切れさせてはいけません、モバイルノードのIPアドレスに関連しているMACアドレスをリフレッシュするために放送ARP以外に、外国人のエージェントに何らかの道がない場合。
Each foreign agent SHOULD support the mandatory features for reverse tunneling [27].
それぞれの外国人のエージェントSHOULDは逆のトンネリング[27]のための義務的な特徴をサポートします。
4.2.3. Home Agent Considerations
4.2.3. ホームエージェント問題
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.
ホームのエージェントはモバイルノードがホームから遠くに登録されますが、モバイルノードに扱われたホームネットワークのどんなデータグラムも妨害できなければなりません。 プロキシと無料のARP MAY、セクション4.6で指定されるようにこの妨害を可能にする際に、使用されてください。
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
ホームのエージェントは、それがホームから遠くに登録されたモバイルノードのどれかに関するホームアドレスと等しいかどうか確認するためにすべて到着しているデータグラムのIP Destination Addressを調べなければなりません。 そうだとすれば、モバイルノードのものへのデータグラムが現在登録したホームエージェントトンネルはアドレスかアドレスについて気にかけます。 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. モバイルノードにどんな現在の移動性結合もないと、ホームのエージェントは、モバイルノードのために運命づけられたデータグラムを妨害するのを試みてはいけなくて、その結果、一般に、そのようなデータグラムを受け取らないでしょう。ホームのエージェントがそうなら、また、ルータが一般的なIPトラフィックを扱って、しかしながら、推進のためのそのようなデータグラムを受けるのも、可能です。
Perkins Standards Track [Page 63] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[63ページ]RFC3220IP移動性サポート
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.
ホームネットワーク。 この場合、ホームのエージェントは、モバイルノードがホームでそうであると仮定して、単に直接ホームネットワークにデータグラムを送らなければなりません。
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を見てください。 また、トンネリングがSHOULDであると実装するノードは、「軟性国家にトンネルを堀ってください」というメカニズムが[32]であると実装します。([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で説明されるように位置のプライバシーを維持する目的のためのモバイルノードによって送られた自分たちに扱われたdecapsulateパケットがそうしなければなりません。 また、この特徴が逆のトンネリング[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.
ホームのエージェントがそのモバイルノードのために別の有効なRegistration Requestを受け取る前に与えられた移動性結合のためのLifetimeが期限が切れるなら、その結合は移動性の拘束力があるリストから削除されます。 単にモバイルノードの結合が期限が切れたので、ホームのエージェントはどんなRegistration Replyメッセージも送ってはいけません。 モバイルノードの現在の外国人のエージェントの訪問者リストにおけるエントリーは自然に期限が切れるでしょう、たぶんホームのエージェントに吐き出された結合と同時に。 移動性結合の寿命が期限が切れると、ホームのエージェントは結合を削除しなければなりませんが、それはモバイルノードのために保持するいかなる他の(非満期)の同時の移動性結合も保有しなければなりません。
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
- また、内側(カプセル化される)の目的地Addressが外側のDestination Address(モバイルノード)と同じであるなら、ホームのエージェントはカプセル化されたデータグラム(トンネルのソースアドレス)の外側のSource Addressを調べなければなりません。 この外側のSource Addressが同じである、モバイルノードの電流、注意、-、アドレス、ホームのエージェントは、ありそうなルーティング輪を防ぐために静かにそのデータグラムを捨てなければなりません。 代わりにSource Addressが同じでない外側、モバイルノードの電流、注意、-、アドレス、そして、ホームのエージェントSHOULDはモバイルノードにデータグラムを送ります。 転送
Perkins Standards Track [Page 64] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[64ページ]RFC3220IP移動性サポート
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.
この場合ホームのエージェントが単に外側のDestination Addressを変更するかもしれないデータグラム、注意、-、アドレス、データグラムを再カプセル化するよりむしろ。
- 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).
- さもなければ(内側のDestination Addressは外側のDestination Addressと同じでない)、ホームのエージェントSHOULDは再び(カプセル化を入れ子にする)データグラムをカプセル化します、等しい状態で用意ができている新しい外側のDestination Addressと共にモバイルノードのもの、注意、-、アドレス (既にカプセル化される)のいかなる他のデータグラムとも同様に、すなわち、ホームのエージェントは全体のデータグラムをモバイルノードに送ります。
4.3. Broadcast Datagrams
4.3. ブロードキャスト・データグラム
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.
ホームのエージェントがブロードキャスト・データグラムを受け取るとき、それはブロードキャスト・データグラムの推進を要求したもの以外の移動性の拘束力があるリストのどんなモバイルノードにもデータグラムを送ってはいけません。モバイルノードは、Registration Requestメッセージ(セクション3.3)に'B'ビットをはめ込むことによって、ブロードキャスト・データグラムの推進を要求するかもしれません。 そのようなそれぞれの登録されたモバイルノードに関しては、ホームのエージェントSHOULDフォワードはモバイルノードにブロードキャスト・データグラムを受けました、それがブロードキャスト・データグラムの特定のカテゴリがそのようなモバイルノードに送られるホームのエージェントにおける構成の問題ですが。
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'ビットがモバイルノードのRegistration Requestメッセージにおけるセット、モバイルノードが単にアドレスの共同位置している注意、ホームのエージェントを使用しているのを示したことである、トンネルが放送IPデータグラムを当てるモバイルノードのもの、注意、-、アドレス さもなければ('D'ビットは設定されなかった)、ホームのエージェントは、最初に、モバイルノードのホームアドレスに扱われたユニキャストデータグラム、および次に、トンネルのブロードキャスト・データグラムがこのカプセル化されたデータグラムであると外国人のエージェントにカプセル化します。 この付加的なレベルのカプセル化が、外国人のエージェントが、それがdecapsulatedされた後にどのモバイルノードがデータグラムを受けるはずであるかを決心できるくらい必要です。 外国人のエージェントによって受け取られると、いかなる他のデータグラムとも同様に、データグラムであるとカプセル化されたユニキャストは、モバイルノードに「反-トンネル」であり、提供されます。 どちらの場合ではも、モバイルノードはそれがオリジナルのブロードキャスト・データグラムを回収するために受けるデータグラムをdecapsulateしなければなりません。
4.4. Multicast Datagram Routing
4.4. マルチキャストデータグラムルート設定
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.
いかなる他の(修理される)のホストかルータとも同様に、既述のとおり、ホームネットワークに接続されるモバイルノードは機能します。 それがホームにあるとき、したがって、モバイルノードは同様に他のマルチキャスト送付者と受信機に機能します。 したがって、このセクションは外国ネットワークを訪問しているモバイルノードの動きについて説明します。
Perkins Standards Track [Page 65] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[65ページ]RFC3220IP移動性サポート
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つの方法の1つでマルチキャストグループに加わらなければなりません。 まず最初に、訪問されたサブネットに関する(地方)のマルチキャストルータでモバイルノードはグループに加わるかもしれません。 このオプションは、訪問されたサブネットの現在のマルチキャストルータがあると仮定します。 モバイルノードがaが共同場所を見つけた使用である、注意、-、アドレス、それ、SHOULDは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ヘッダーSHOULDのソースアドレスにトンネルを堀られたパケットに関してはモバイルノードのホームアドレスになってください。
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)に、この場合、モバイルノードへのマルチキャストデータグラム配信のための規則はそれらと同じです。 モバイルノードがすなわち、aが共同場所を見つけた使用である、注意、-、アドレス('D'ビットはモバイルノードのRegistration Requestに設定された)、次に、ホームのエージェントSHOULDがこれにデータグラムにトンネルを堀る、注意、-、アドレス。 さもなければ、ホームのエージェントが最初に、モバイルノードのホームアドレスに扱われたユニキャストデータグラムでデータグラムをカプセル化しなければならなくて、次に、結果として起こるデータグラム(入れ子にされたトンネリング)にトンネルを堀らなければならない、モバイルノードのもの、注意、-、アドレス この理由で、モバイルノードはこのメソッドを使用することでマルチキャストデータグラムを受けるためにホームアドレスに送られたパケットをdecapsulatingすることができなければなりません。
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ソースアドレスによるので直接訪問されたネットワークにマルチキャストデータグラムを送るモバイルノードが共同見つけられたaを使用しなければならない、注意、-、IPソースアドレスとしてのアドレス。 同様に、ホームのエージェントにマルチキャストデータグラムにトンネルを堀るモバイルノードは(内側)のマルチキャストデータグラムと(外側)の要約データグラムの両方のIPソースアドレスとしてホームアドレスを使用しなければなりません。 この2番目のオプションは、ホームのエージェントがマルチキャストルータであると仮定します。
4.5. Mobile Routers
4.5. モバイルルータ
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つ以上の全体のネットワークの移動性に原因となるルータであるかもしれません、恐らく飛行機、船、列車、自動車、自転車、またはカヤックの上に。 モバイルルータによって役立たれるネットワークに接続されたノードがそうするかもしれない、自分たち、固定ノード、モバイルノードまたはルータになってください。 本書では、そのようなネットワークは「モバイルネットワーク」と呼ばれます。
Perkins Standards Track [Page 66] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[66ページ]RFC3220IP移動性サポート
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を使用します、外国人のエージェントを使用して注意、-、アドレスがエージェントを通して航空機の外国人のエージェントからAdvertisementを発見しました。
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) 航空機ルータとそこの外国人のエージェントのホームのエージェントがデータグラムを妨害して、それにトンネルを堀る、電流、注意、-、アドレス、航空機の下の地面のこの例の外国人のエージェントである。 通信員ノードからのオリジナルのデータグラムは現在、二度カプセル化されました: 一度ラップトップのホームのエージェントと再び航空機のホームのエージェントで。
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) 地面の外国人のエージェントがデータグラム、データグラムが送付先アドレスをもっているラップトップのホームのエージェントでまだ要約していたもたらすことをdecapsulatesする、ラップトップのもの、注意、-、アドレス 外国人のエージェントが航空機へのラジオリンクの上の結果として起こるデータグラムを送る地面。
Perkins Standards Track [Page 67] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[67ページ]RFC3220IP移動性サポート
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) 航空機の上の外国人のエージェントはデータグラムをdecapsulatesします、通信員ノードからオリジナルのデータグラムをもたらして、ラップトップのホームアドレスの送付先アドレスで。 航空機の外国人のエージェントはラップトップのリンクレイヤアドレスへの航空機ネットワークの上にデータグラムを提供します。
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ルーティング・プロトコルを使用して、モバイルルータは全体のモバイルネットワークに接続性の広告を出すかもしれません。 このメソッドはデータグラムの入れ子にされたトンネリングの必要性を避けます。
4.6. ARP, Proxy ARP, and Gratuitous ARP
4.6. ARP、プロキシARP、および無料のARP
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:
ARPのIPアドレスからの目標ノードのリンクレイヤアドレスを決議する通常の使用に加えて、このドキュメントは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.
- Proxy ARP[39]は1つのノードによってそれ自身のARP Requestsに答えたがっていない別のノードを代表して送られたARP Replyです。 Proxy ARPの送付者は、[36]で説明されるようにSenderとTargetプロトコルAddress分野を逆にしますが、Sender Hardware Address分野で何らかの構成されたリンクレイヤアドレス(一般にそれ自身のもの)を供給します。 次に、Replyを受けるノードはオリジナルの目標ノードのIPアドレスにこのリンクレイヤアドレスを関連づけるでしょう、この目標ノードのためにそのリンクレイヤアドレスで将来のデータグラムをノードに送ることを引き起こして。
Perkins Standards Track [Page 68] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[68ページ]RFC3220IP移動性サポート
- 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).
- Gratuitous ARP[45]は他のノードがそれらのARPキャッシュにおけるエントリーをアップデートすることを自然に引き起こすためにノードによって送られたARPパケットです。 無料のARP MAYはARP RequestかARP Replyパケットのどちらかを使用します。 どちらの場合ではも、ARP SenderプロトコルAddressとARP TargetプロトコルAddressはアップデートするようにキャッシュエントリーのIPアドレスに用意ができています、そして、ARP Sender Hardware Addressはこのキャッシュエントリーがアップデートされるべきであるリンクレイヤアドレスに用意ができています。 また、ARP Replyパケットを使用するとき、Target Hardware Addressはこのキャッシュエントリーがアップデートされるべきであるリンクレイヤアドレスに用意ができています(この分野はARP Requestパケットで使用されません)。
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パケット(要求かReply)もアップデートしなければならないどんなノード受信でも、地方のARPはSenderと共にARPパケットでプロトコルとHardware Addressesをキャッシュします、受信ノードに既にARPキャッシュにおけるそのIPアドレスのためのエントリーがあるなら。 ARPプロトコルのこの要件はARP Requestパケット、および受信ノード[36]によって伝えられた少しのARP Requestにも合っていないARP Replyパケットのためにさえ申し込まれます。
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 Requestsに答えるのにプロキシARP[39]を使用します。 ARP Requestを受けるとき、ホームのエージェントはRequestの目標IPアドレスを調べなければなりません、そして、このIPアドレスがそれが登録された移動性結合を持っているどんなモバイルノードに関するホームアドレスにも合っているなら、ホームのエージェントはモバイルノードを代表してARP Replyを伝えなければなりません。 パケット[39]で送付者とあて先アドレスを交換した後に、ホームのエージェントはReplyが送られるそれ自身のインタフェースのリンクレイヤアドレスへのパケットに送付者リンクレイヤアドレスをはめ込まなければなりません。
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パケットはSHOULDです。信頼性を増強する再送されたa少ない番号の回になってください。
Perkins Standards Track [Page 69] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[69ページ]RFC3220IP移動性サポート
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.
モバイルノードがホームネットワークに戻るとき、モバイルノードとそのホームのエージェントは、モバイルノードのホームネットワークのすべてのノードがもう一度モバイルノードのホーム(IP)アドレスにモバイルノードの自己のリンクレイヤアドレスを関連づけるためにそれらのARPキャッシュをアップデートすることを引き起こすのに無料のARPを使用します。 (de)登録Requestメッセージをホームのエージェントに送る前に、モバイルノードはローカル放送としてこのリンクの上にホームネットワークでこの無料のARPを伝えなければなりません。 無料のARPパケットSHOULDは増加への少ない数の回再送されて、しかし、信頼性、これらのretransmissions SHOULDがトランスミッションと平行して続くということであり、(de)登録Requestを処理しています。
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)登録Requestを受け取って、受け入れるとき、ホームのエージェントはモバイルノードのホームネットワークで無料のARPを伝えなければなりません。 この無料のARPも、モバイルノードの自己のリンクレイヤアドレスにモバイルノードのホームアドレスを関連づけるのに使用されます。 無料のARPはモバイルノードとそのホームのエージェントの両方によって伝えられます、ワイヤレス・ネットワークインタフェースの場合において、モバイルノードのトランスミッション範囲の中の領域がホームのエージェントの範囲の中でおそらくそれと異なるので。 ローカルが増強する再送されたa少ない番号の回が信頼性であったならモバイルノードのホームのリンク、およびSHOULDで放送したaとしてホームのエージェントからのARPパケットを伝えなければなりません。 しかしながら、これらの「再-トランスミッション」であり、SHOULDは(de)登録Replyのトランスミッションと処理と平行して続きます。
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 RequestかARP Replyメッセージも送ってはいけません。 最終的に、モバイルノードが家にいない間、目標IPアドレスがそれ自身のホームアドレスであるARP Requestsに答えてはいけません、ARP Requestが登録するのをモバイルノードと試みている外国人のエージェントかモバイルノードには満期になっていない登録がある外国人のエージェントによるユニキャストでないなら。 後者の場合では、モバイルノードは、外国人のエージェントに応じるのにユニキャストARP Replyを使用しなければなりません。 モバイルノードがaが共同場所を見つけた使用であるならそれに注意してください、注意、-、目標IPアドレスがアドレスのこの注意、次に、モバイルノードSHOULDが返答するということであるARP RequestをこのARP Requestに扱って、受けます。 また、外国ネットワークでRegistration Requestを伝えるとき、モバイルノードがエージェントAdvertisementからその外国人のエージェントからそれを受け取るようにアドレスを保存することによって外国人のエージェントのリンクレイヤアドレスを発見するかもしれないことに注意しますが、放送ARP Requestメッセージを送ることによって、注意するというわけではなくなってください。
Perkins Standards Track [Page 70] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[70ページ]RFC3220IP移動性サポート
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、およびホームを出るときのモバイルノードのRegistration RequestとRegistration Replyメッセージのトランスミッションと処理に比例して適用されるか、または家に帰る無料の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.
- モバイルノードは、ホームから遠くに登録すると決めます、恐らく、外国人のエージェントからエージェントAdvertisementを受けて、最近ホームのエージェントから1を受け取っていないので。
- 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.
- Registration Requestを伝える前に、モバイルノードはそれ自身の外国人のエージェントがオンな状態でコミュニケートするのに必要である限り、ホームアドレスに対応するリンクレイヤアドレスがネットワークを訪問したよう要求するそれが次に受けるどんなARP Requestsの今後の処理も無効にします。
- The mobile node transmits its Registration Request.
- モバイルノードは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.
- モバイルノードのホームのエージェントがRegistration Requestを受け取って、受け入れるとき、それは、モバイルノードを代表して無料のARPを実行して、それが受けるARP Requestsに答えるのにモバイルノードリンクの層のアドレスを要求しながら、プロキシARPを使用し始めます。 無料のARPでは、ARP Sender Hardware Addressはホームのエージェントのリンクレイヤアドレスに用意ができています。 または、代わりに、ホームのエージェントがRegistration Requestを拒絶して、どんな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.
- モバイルノードは、ホームに登録すると決めます、恐らくホームのエージェントからエージェントAdvertisementを受けたので。
- 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.
- Registration Requestを伝える前に、モバイルノードはそれ自身のリンクレイヤアドレスを要求するそれが次に受けるどんなARP Requestsの今後の処理も再可能にします。
- 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 Sender Hardware Addressはモバイルノードのリンクレイヤアドレスに用意ができています。
- The mobile node transmits its Registration Request.
- モバイルノードはRegistration Requestを伝えます。
Perkins Standards Track [Page 71] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[71ページ]RFC3220IP移動性サポート
- 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.
- モバイルノードのホームのエージェントがRegistration Requestを受け取って、受け入れると、それは、それが受けるARP Requestsに答えるのにモバイルノードリンクの層のアドレスを要求しながらプロキシARPを使用するのを止めて、モバイルノードを代表して無料のARPを実行します。 この無料のARPでは、ARP Sender Hardware Addressはモバイルノードのリンクレイヤアドレスに用意ができています。 または、ホームのエージェントが代わりにRegistration Requestを拒絶するなら、ホームのエージェントがARP処理を実行する方法へのどんな変更も行ってはいけない、(無料、プロキシ) モバイルノードのために。 この後者の場合では、ホームのエージェントは、まるでモバイルノードが家に帰っていないかのように働いていて、モバイルノードを代表してプロキシARPを実行し続けるべきです。
5. Security Considerations
5. セキュリティ問題
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.
モバイル・コンピューティング環境は普通のコンピューティング環境と非常に潜在的に異なっています。 多くの場合、モバイルコンピュータはワイヤレスのリンクを通してネットワークに接続されるでしょう。 そのようなリンクは特に受け身の盗聴、アクティブな反射攻撃、および他の活発な攻撃に被害を受け易いです。
5.1. Message Authentication Codes
5.1. メッセージ立証コード
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.
ホームのエージェントとモバイルノードは認証を実行できなければなりません。 デフォルトアルゴリズムは128ビットの主要なサイズがあるHMAC-MD5[23]です。 また、外国人のエージェントは認証が128ビット以上のHMAC-MD5を使用して、主要なサイズであるとサポートしなければなりません、手動の主要な分配で。 任意の2進の値があるキーを支えなければなりません。
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登録メッセージがセクション3.5.2で指定された拡大、3.5.3、および3.5で.4に供給される認証データを生産して、確かめるとき、このモードを使用する既存のモバイルIP実装との後方の互換性が必要であるところでは、新しい実装SHOULDは使用のための追加認証アルゴリズムの1つとして合わせられたMD5[41]を含んでいます。
More authentication algorithms, algorithm modes, key distribution methods, and key sizes MAY also be supported for all of these extensions.
また、より多くの認証アルゴリズム、アルゴリズムモード、主要な分配メソッド、および主要なサイズはこれらの拡大のすべてのためにサポートされるかもしれません。
5.2. Areas of Security Concern in this Protocol
5.2. このプロトコルのSecurity Concernの領域
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
本書では説明された登録プロトコルがトンネルを堀られるモバイルノードのトラフィックをもたらす、それ、注意、-、アドレス 登録が認証されないなら、このトンネリング機能は重要な脆弱性であるかもしれないでしょうに。 そのようなリモートリダイレクション
Perkins Standards Track [Page 72] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[72ページ]RFC3220IP移動性サポート
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]を認証しました。 そのうえ、Address Resolutionプロトコル(ARP)を認証しないで、別のホストのトラフィックを横取りするのに、潜在的に、使用できます。 「無料のARP」(セクション4.6)の使用はそれと共にARPの使用に関連しているリスクのすべてをもたらします。
5.3. Key Management
5.3. Key Management
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)を必要とします。 しかしながら、主要な分配がネットワークかぎ管理プロトコルがないとき難しいので、外国人のエージェントがいるメッセージは認証されるのにすべて必要ではありません。 商業環境で、その支払いが可能であることで、外国人のエージェントとホームのエージェントの間のすべてのメッセージを認証するのが重要であるかもしれなく、サービスプロバイダーはそのサービスプロバイダーの正統の顧客でないユーザに対するサービスを提供しません。
5.4. Picking Good Random Numbers
5.4. 良い乱数を選びます。
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ビットのキーは秘密(すなわち、認可されたパーティーだけにおいて、知られている)と擬似ランダムの両方でなければなりません。 また、一回だけが反復操作による保護に関して使用されるなら、慎重にそれらを選択しなければなりません。 イーストレーク、他 [14]は擬似乱数を生成する詳しい情報を提供します。
5.5. Privacy
5.5. プライバシー
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.
それらがする極秘データを持っているユーザは、会う他のものが適切な保護を提供するのにこのドキュメント(暗号化などの)の範囲の外でメカニズムを使用するべきであることを願っていません。 トラヒック分析に関して心配しているユーザはリンク暗号化の適切な使用を考えるべきです。 絶対位置のプライバシーが望まれているなら、モバイルノードはホームのエージェントにトンネルを作成できます。 次に、通信員ノードのために運命づけられたデータグラムはホームネットワークから発するように見えるでしょう、そして、モバイルノードの位置を正確に指摘するのは、より難しいかもしれません。 そのようなメカニズムはこのドキュメントの範囲を超えています。
Perkins Standards Track [Page 73] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[73ページ]RFC3220IP移動性サポート
5.6. Ingress Filtering
5.6. イングレスフィルタリング
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.
多くのルータが不正確な状態で位相的に現れるSource Addressを持っているパケットの推進を許さない「イングレスフィルタリング」[15]などの安全保障政策を実装します。 これが問題である環境で、モバイルノードが供給する外国人のエージェントと共に逆のトンネリング[27]を使用するかもしれない、注意、-、Source Addressとしてのアドレス。 通常、逆のトンネルを堀られたパケットはそのようなルータを通り抜けることができるでしょう、規則をフィルターにかけるイングレスが非モバイルノードからのパケットと同様にまだパケットの正しい位相的な源の場所を見つけることができるでしょうが。
5.7. Replay Protection for Registration Requests
5.7. 登録要求のための反復操作による保護
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).
ホームのエージェントに攻撃者によって前の何らかの登録から再演されるのではなく、登録メッセージがモバイルノードによって新たに生成されたことを確かめさせるのにIdentification分野は使用されます。 2つのメソッドがこのセクションで説明されます: タイムスタンプ(義務的な)と「一回だけ。」(任意の) すべてのモバイルノードとホームのエージェントはタイムスタンプベースの反復操作による保護を実装しなければなりません。 また、これらのノードは一回だけベースの反復操作による保護を実装するかもしれません(Appendix 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.
スタイル、事実上、反復操作による保護では、間に、モバイルノードとそのホームのエージェントはモバイルセキュリティ協会の一部です。 モバイルノードとそのホームのエージェントは、反復操作による保護のどのメソッドが使用されるかに同意しなければなりません。 Identification分野の解釈はその後の小区分で説明されるように反復操作による保護のメソッドによります。
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. of any Registration Reply are identical to the bits it sent in the Registration Request.
いかなる使用されたメソッド、Registration RequestからReplyまで変わりがない状態でIdentificationの下位の32ビットをコピーしなければなりません。 外国人のエージェントは、対応する回答にRegistration Requestsを合わせるのに、それらのビット(そして、モバイルノードのホームアドレス)を使用します。いずれではも、Registration ReplyはそれがRegistration Requestで送ったビットと同じです。
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.
新しいRegistration RequestのIdentificationはすぐに前のRequestと同じであるはずがありません、そして、同じセキュリティ文脈がモバイルノードとホームのエージェントの間で使用されている間、SHOULD NOTは繰り返します。 セクション3.6.3で許容されているRetransmission。
5.7.1. Replay Protection using Timestamps
5.7.1. タイムスタンプを使用する反復操作による保護
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
タイムスタンプ反復操作による保護の基本原理はメッセージを生成するノードが現在の時刻を挿入して、メッセージを受け取るノードが、このタイムスタンプがそれ自身の時刻の十分近くにあるのをチェックするということです。 ノード、7秒のデフォルト値の間のセキュリティ協会で異なって指定されません。
Perkins Standards Track [Page 74] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[74ページ]RFC3220IP移動性サポート
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.
時差を制限するのに使用されるかもしれません。 これは3以上が秒であったならSHOULDを評価します。 明らかに、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.
タイムスタンプが使用されているなら、モバイルノードはNetwork Timeプロトコル[26]によって指定されるようにフォーマットされた64ビットの値にIdentification分野を設定しなければなりません。 NTP形式の下位の32ビットは有効でない断片的な秒、およびそれらのビットを表します。時間ソースSHOULDから、偶発性の良い源から生成されてください。 しかしながら、タイムスタンプを使用するとき、IdentificationがRegistration Requestでモバイルノードから使用した64ビットがどんな前のRegistration Requestでも使用されるそれより大きいに違いないことに注意してください、ホームのエージェントが一連番号としてもこの分野を使用するとき。 それが以前のRegistration Requestの遅れた写しがホームのエージェント(ホームのエージェントによって必要とされた時計同期の中の)に到着するのにおいて可能であるだろう、その結果、故障していた状態で適用されて、そのような一連番号がなければ、モバイルノードの電流を誤って変更するのが登録された、注意、-、アドレス。
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.
承認のエネイブリングである拡大を伴うRegistration Requestを受け取り次第、ホームのエージェントは正当性がないかどうかIdentification分野をチェックしなければなりません。 有効になるようにホームのエージェントの時刻時計にはIdentification分野に保管されていたタイムスタンプが十分近くにあるに違いなくて、タイムスタンプはすべてが以前に要求のモバイルノードのためのタイムスタンプを受け入れたよりすばらしいに違いありません。 時間寛容と再同期の詳細は特定の移動性セキュリティ協会に特定です。
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.
タイムスタンプが有効であるなら、ホームのエージェントはそれがモバイルノードへのReplyを返すRegistration Replyに全体のIdentification分野をコピーします。 タイムスタンプが有効でないなら、ホームのエージェントは、Registration Replyに下位だけを32ビットコピーして、高位をそれ自身の時刻から32ビット供給します。 この後者の場合では、ホームのエージェントは、Registration ReplyでCode133(識別ミスマッチ)を返すことによって、登録を拒絶しなければなりません。
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について説明するので、モバイルノードは、Registration ReplyのIdentificationの下位の32ビットが拒絶された登録試みにおけるそれらと同じであることを確かめなければなりません、時計再同期に高位のビットを使用する前に。
Perkins Standards Track [Page 75] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[75ページ]RFC3220IP移動性サポート
5.7.2. Replay Protection using Nonces
5.7.2. 一回だけを使用する反復操作による保護
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.
一回だけの反復操作による保護の基本原理はノードAが、あらゆるメッセージにノードBに新しい乱数を含んで、ノードBが攻撃者による変更から守るためにノードA.Bothメッセージ使用への次のメッセージのその同数に認証子を返すのをチェックするということです。 同時に、ノードBはノード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]として役に立つようにすると予想されるかもしれません。 それはあらゆるRegistration Replyの識別分野の高位32ビットとして新しい一回だけを挿入します。 ホームのエージェントはRegistration ReplyのIdentificationの下位の32ビットにIdentificationの下位の32ビットをRegistration Requestメッセージを回避します。 モバイルノードがホームのエージェントから認証されたRegistration Replyを受けるとき、それは、次のRegistration Requestの高位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).
下位が各Registration RequestのIdentificationの32ビットであると生成するのにモバイルノードは原因となります。 理想的に、それはそれ自身の無作為の一回だけを生成するべきです。 しかしながら、それはホームのエージェントによって送られた無作為の価値の複製を含むどんな好都合なメソッドも使用するかもしれません。 選ばれたメソッドはモバイルノードだけに重要です、それがRegistration Replyの有効値がないかどうかチェックするノードであるので。 SHOULDが選ばれた識別の高位と下位の32ビットはともにそれらの前の値と異なっています。 ホームのエージェントは新しい高位値を使用します、そして、モバイルノードはそれぞれの登録メッセージに新しい下位の値を使用します。 外国人のエージェントは、正しく未定のRequests(セクション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.
登録メッセージが無効の一回だけで拒絶されるなら、Replyは、次の登録に使用されるためにいつも新しい一回だけをモバイルノードに提供します。 したがって、一回だけのプロトコルは自己連動です。
6. IANA Considerations
6. IANA問題
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.
- モバイルIPメッセージタイプはセクション1.8で定義されるようにUDPポート434に発信しました。
Perkins Standards Track [Page 76] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[76ページ]RFC3220IP移動性サポート
- 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])
- Registration Requestへの拡大とRegistration Replyメッセージのタイプ(セクション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])
- Registration ReplyメッセージのCodeのための値(セクション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はいわゆるエージェントSolicitationとエージェントAdvertisementメッセージを定義します。 事実上、これらのメッセージはモバイルIPの特定の拡大に従って増大するRouterディスカバリーメッセージ[10]です。 したがって、彼らは新しい名前スペースを定義しませんが、セクション6.2で以下で説明される追加Routerディスカバリー拡張子を定義してください。 また、セクション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番号」のための次に特定のセクションにハイパーリンクに従ってください。
6.1. Mobile IP Message Types
6.1. モバイル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で指定されます。 新しい内線電話番号の承認はExpert Reviewを受けることがあります、そして、仕様は必要な[30]です。 現在標準化されたメッセージタイプは、以下の数を持って、示されたセクションで指定されます。
Type Name Section ---- -------------------------------------------- --------- 1 Registration Request 3.3 3 Registration Reply 3.4
型名部---- -------------------------------------------- --------- 1 登録要求3.3 3登録回答3.4
6.2. Extensions to RFC 1256 Router Advertisement
6.2. RFC1256ルータ通知への拡大
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.
RFC1256は2ICMPメッセージのタイプ、Router Advertisement、およびRouter Solicitationを定義します。 モバイルIPは拡大のために数のスペースをRouter Advertisementと定義します。(モバイルIP以外のプロトコルはRouter Advertisementを使用できました)。 現在モバイルIPとの使用のために標準化されている拡大タイプは以下の数を持っています。
Perkins Standards Track [Page 77] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[77ページ]RFC3220IP移動性サポート
Type Name Reference ---- -------------------------------------------- --------- 0 One-byte Padding 2.1.3 16 Mobility Agent Advertisement 2.1.1 19 Prefix-Lengths 2.1.2
型名参照---- -------------------------------------------- --------- 0 1バイトの詰め物2.1.3 16移動性エージェント広告2.1.1 19接頭語長さの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との使用のための新しい内線電話番号の承認はExpert Reviewを受けることがあります、そして、仕様は必要な[30]です。
6.3. Extensions to Mobile IP Registration Messages
6.3. モバイルIP登録メッセージへの拡大
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メッセージ拡張子のための数のスペースはこのドキュメントの中に指定されます。 新しい内線電話番号の承認はExpert Reviewを受けることがあります、そして、仕様は必要な[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
型名参照---- -------------------------------------------- --------- 0 1バイトの詰め物32移動住宅認証3.5.2 33のモバイルに外国の認証3.5.3 34外国ホーム認証3.5.4
6.4. Code Values for Mobile IP Registration Reply Messages
6.4. モバイルIP登録応答メッセージのためのコード値
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 Registration Replyメッセージには、Code分野があります。 また、Code分野値のための数のスペースはセクション3.4で指定されます。 登録がうまくいったかどうか、またはホームのエージェントが登録要求を否定したか否かに関係なく、外国人のエージェントが最後に登録要求を否定するかどうかに従って、Code数のスペースは構造化されます、以下の通りです:
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 成功Codes9-63いいえ配分ガイドライン、64-127 ホームのエージェント193-255いいえ配分ガイドラインからのForeignエージェント128-192Error CodesからのError Codesが現在現在存在する、存在
Approval of new Code values requires Expert Review [30].
新しいCode値の承認はExpert Review[30]を必要とします。
Perkins Standards Track [Page 78] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[78ページ]RFC3220IP移動性サポート
7. Acknowledgments
7. 承認
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].
ダン・デュシャンに伴うスティーブ・デアリングへの特別な感謝(ゼロックスPARC)と、それをまとめて、ワーキンググループを形成するためのジョンIoannidis(JI)(コロンビア大学)と、とても多くの取り組みを初期発生にそそぐこと。 [18、19、17]でコロンビアの早めのモバイルIP仕事を見つけることができます。
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、グレッグMinshall、トニー・李、ジム・ソロモン、エリックNordmark、Basavarajパティル、およびフィル・ロバーツをありがとうございます、よく彼らの多くの役に立つコメントのように。
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)
- 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)
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.
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.
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.
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.
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
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
Perkins Standards Track [Page 79] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 79] RFC 3220 IP Mobility Support for IPv4 January 2002
- 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.
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.
Perkins Standards Track [Page 80] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 80] RFC 3220 IP Mobility Support for IPv4 January 2002
A. Patent Issues
A. Patent Issues
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.
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.
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.
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.
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.
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.
B. Link-Layer Considerations
B. Link-Layer Considerations
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.
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.
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.
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.
Perkins Standards Track [Page 81] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 81] RFC 3220 IP Mobility Support for IPv4 January 2002
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.
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.
C. TCP Considerations
C. TCP Considerations
C.1. TCP Timers
C.1. TCP Timers
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.
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.
C.2. TCP Congestion Management
C.2. TCP Congestion Management
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.
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.
Perkins Standards Track [Page 82] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 82] RFC 3220 IP Mobility Support for IPv4 January 2002
D. Example Scenarios
D. Example Scenarios
This section shows example Registration Requests for several common scenarios.
This section shows example Registration Requests for several common scenarios.
D.1. Registering with a Foreign Agent Care-of Address
D.1. Registering with a Foreign Agent Care-of Address
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:
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 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)
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)
D.2. Registering with a Co-Located Care-of Address
D.2. Registering with a Co-Located Care-of Address
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:
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:
Perkins Standards Track [Page 83] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 83] RFC 3220 IP Mobility Support for IPv4 January 2002
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
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
D.3. Deregistration
D.3. Deregistration
The mobile node returns home and wishes to deregister all care-of addresses with its home agent.
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
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)
Extensions: An authorization-enabling extension (e.g., the Mobile-Home Authentication Extension)
Perkins Standards Track [Page 84] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 84] RFC 3220 IP Mobility Support for IPv4 January 2002
E. Applicability of Prefix-Lengths Extension
E. Applicability of Prefix-Lengths Extension
Caution is indicated with the use of the Prefix-Lengths Extension over wireless links, due to the irregular coverage areas provided by wireless transmitters. As a result, it is possible that two foreign agents advertising the same prefix might indeed provide different connectivity to prospective mobile nodes. The Prefix-Lengths Extension SHOULD NOT be included in the advertisements sent by agents in such a configuration.
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.
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".
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. Interoperability Considerations
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.
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.
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.
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.
- 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.
- 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.
Perkins Standards Track [Page 85] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 85] RFC 3220 IP Mobility Support for IPv4 January 2002
- Mobile nodes that use the NAI extension to identify themselves
would not work with old mobility agents.
- Mobile nodes that use the NAI extension to identify themselves would not work with old mobility agents.
- 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 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.
- 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.
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. Changes since 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.
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.
G.1. Major Changes
G.1. Major Changes
- Specification for Destination IP address of Registration Reply
transmitted from Foreign Agent, to avoid any possible
transmission to IP address 0.0.0.0.
- Specification for Destination IP address of Registration Reply transmitted from Foreign Agent, to avoid any possible transmission to IP address 0.0.0.0.
- Specification of two new formats for Mobile IP extensions,
according to the ideas contained in MIER.
- Specification of two new formats for Mobile IP extensions, according to the ideas contained in MIER.
- 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.
- 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.
- Eliminated Van-Jacobson Compression feature
- Eliminated Van-Jacobson Compression feature
- 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.
- 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.
Perkins Standards Track [Page 86] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 86] RFC 3220 IP Mobility Support for IPv4 January 2002
- Specification that foreign agents SHOULD support reverse
tunneling, and home agents MUST support decapsulation of
reverse tunnels.
- 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.
- 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.
- 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.
- 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.
- 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].
- 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].
- Mandated that HMAC-MD5 be used instead of the "prefix+suffix"
mode of MD5 as originally mandated in RFC 2002.
- Mandated that HMAC-MD5 be used instead of the "prefix+suffix" mode of MD5 as originally mandated in RFC 2002.
- 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
- 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.
- 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.
- 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.
- 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.
- 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
- 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
Perkins Standards Track [Page 87] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 87] RFC 3220 IP Mobility Support for IPv4 January 2002
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).
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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Inserted 'T' bit into its proper place in the Registration
Request message format (section 3.3).
- Inserted 'T' bit into its proper place in the Registration Request message format (section 3.3).
G.2. Minor Changes
G.2. Minor Changes
- 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.
- 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.
Perkins Standards Track [Page 88] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 88] RFC 3220 IP Mobility Support for IPv4 January 2002
- 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).
- 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).
- 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,
- 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,
- Clarification that a mobility agent MAY use different settings
for each of the 'R', 'H', and 'F' bits on different network
interfaces.
- Clarification that a mobility agent MAY use different settings for each of the 'R', 'H', and 'F' bits on different network interfaces.
- Replacement of the terminology "recursive tunneling" by the
terminology "nested tunneling".
- 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.
- Specification that the mobile node MAY use the IP source address of an agent advertisement as its default router address.
- Clarification that keys with arbitrary binary values MUST be
supported as part of mobility security associations.
- 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.
- 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.
- 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).
- 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).
- Clarification that the foreign agent SHOULD consider its own
maximum value when handling the Lifetime field of the
Registration Reply.
- 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.
- Clarification that the home agent MUST ignore the 'B' bit (as opposed to rejecting the Registration Request) if it does not support broadcasts.
Perkins Standards Track [Page 89] RFC 3220 IP Mobility Support for IPv4 January 2002
Perkins Standards Track [Page 89] RFC 3220 IP Mobility Support for IPv4 January 2002
- 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.
- 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.
- 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.
- 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.
- Included a reference to RFC 2290 within appendix B, which deals
with PPP operation.
- Included a reference to RFC 2290 within appendix B, which deals with PPP operation.
- Created IANA Considerations section
- Created IANA Considerations section
- 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.
- 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.
G.3. Changes since revision 04 of RFC2002bis
G.3. Changes since revision 04 of RFC2002bis
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.
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.
- 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が使用のためにRFC2002の元々強制されているとしてのMD5の「接頭語+接尾語」モードに代わって考えられるべきであることに注意しました。
- Included a reference to RFC 2290 within appendix B, which deals
with PPP operation.
- 付録Bの中にRFC2290の指示するものを含んでいました。付録はPPP操作に対処します。
- Revamped IANA Considerations section
- 改造されたIANA Considerations部
- Revamped Changes section
- 改造されたChanges部
- Replaced Patents section with wording mandated from RFC 2026.
- Patents部をRFC2026から強制された言葉遣いに取り替えました。
- Updated citations.
- 引用をアップデートしました。
Perkins Standards Track [Page 90] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[90ページ]RFC3220IP移動性サポート
H. Example Messages
H。 例のメッセージ
H.1. Example ICMP Agent Advertisement Message Format
H.1。 例の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 | 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 :
: .... ...... ...... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヌムAddrs|Addrエントリーサイズ| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータアドレス[1]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 好みのレベル[1]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータアドレス[2]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 好みのレベル[2]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =16をタイプしてください。| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 登録生涯|R|B|H|F|M|G|r|T| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、[1]を扱ってください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、[2]を扱ってください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 任意の拡大: : .... ...... ...... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perkins Standards Track [Page 91] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[91ページ]RFC3220IP移動性サポート
H.2. Example Registration Request Message Format
H.2。 例の登録要求メッセージ形式
The UDP header is followed by the Mobile IP fields shown below:
以下に示されたモバイルIP分野はUDPヘッダーのあとに続いています:
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =1をタイプしてください。|S|B|D|M|G|r|T|x| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームのエージェント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 任意の非Auth拡張子、ハ… | | (可変長) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =32をタイプしてください。| 長さ| SPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI(cont。) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : ミネソタHA Authenticator(可変長): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ファのための任意の非Auth拡張子… : 任意のミネソタ-ファ認証拡大… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perkins Standards Track [Page 92] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[92ページ]RFC3220IP移動性サポート
H.3. Example Registration Reply Message Format
H.3。 例の登録回答メッセージ・フォーマット
The UDP header is followed by the Mobile IP fields shown below:
以下に示されたモバイルIP分野はUDPヘッダーのあとに続いています:
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =3をタイプしてください。| コード| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームのエージェント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 任意である、ハ、非Auth拡張子… | | (可変長) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =32をタイプしてください。| 長さ| SPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI(cont) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : ミネソタHA Authenticator(可変長): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FAによって使用された任意のExtensions… : 任意のミネソタ-ファ認証拡大… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
References
参照
[1] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", BCP 28, RFC
2488, January 1999.
[1] オールマン、M.、手袋製造業者、D.、およびL.サンチェス、「衛星の上の高めるTCPは標準のメカニズムを使用することで精神を集中します」、BCP28、RFC2488、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.Bellovin。 TCP/IPにおける警備上の問題はスイートについて議定書の中で述べます。 ACMコンピュータコミュニケーションレビュー、19(2)、1989年3月。
[3] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby,
"Performance Enhancing Proxies", RFC 3135, June 2001.
[3] 境界とJ.とKojoとM.とGrinerとJ.とモンテネグロとG.とZ.シエルビイ、「プロキシを高めるパフォーマンス」、RFC3135、2001年6月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Perkins Standards Track [Page 93] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[93ページ]RFC3220IP移動性サポート
[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。 モバイル・コンピューティング環境における、信頼できるトランスポート・プロトコルの性能を向上させます。 コミュニケーションの選択された領域に関する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]カルフーンP.とC.パーキンス、「IPv4"のためのモバイルIPネットワークアクセス識別子拡張子、RFC2794、2000年1月。」
[7] Calhoun, P. and C. Perkins, "Mobile IP Foreign Agent
Challenge/Response Extension", RFC 3012, December 2000.
[7] カルフーンとP.とC.パーキンス、「モバイルIP外国エージェント挑戦/応答拡大」、RFC3012、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.パーキンス、「IPの移動性のための管理オブジェクトの定義は、使用がSMIv2"であるとサポートします、RFC2006、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] ダウキンズとS.とモンテネグロとG.とKojoとM.、MagretとV.とN.Vaidya、「終わりから終わりへの誤りとのリンクのパフォーマンス含意」BCP50、RFC3155(2001年8月)。
[10] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[10] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、1991年9月。
[11] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[11] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[12] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-
Specific Extensions", RFC 3115, April 2001.
[12]DommetyとG.とK.レオン、「モバイルIPベンダー/組織の特定の拡大」、RFC3115、2001年4月。
[13] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[13]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[14] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[14] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、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] ファーガソンP.とD.Senie、「以下をフィルターにかけるイングレスをネットワークでつないでください」 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[16] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[16]一かせとS.と李とT.とファリナッチとD.とP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC1701 1994年10月。
[17] J. Ioannidis. Protocols for Mobile Internetworking. PhD
Dissertation - Columbia University in the City of New York,
July 1993.
[17] J.Ioannidis。 モバイルインターネットワーキングのためのプロトコル。 博士号Dissertation--1993年7月のニューヨーク市のコロンビア大学。
Perkins Standards Track [Page 94] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[94ページ]RFC3220IP移動性サポート
[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] ジョンIoannidis、ダン・デュシャン、およびジェラードQ.マグワイアJr.IPはモバイルインターネットワーキングのためのプロトコルを基礎づけました。 SIGCOMM91年のコンファレンスの議事で: コミュニケーションArchitecturesとプロトコル、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]ジョンIoannidisとジェラードQ.マグワイアJr.設計と実装。 Winter USENIX TechnicalコンファレンスのProceedings、489--500ページ、1993年1月に。
[20] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, February 1990.
[20] ジェーコブソン、V.、「低速連続のリンクへのTCP/IPヘッダーを圧縮します」、RFC1144、1990年2月。
[21] Jacobson, V., "Congestion Avoidance and Control. In
Proceedings, SIGCOMM '88 Workshop, pages 314--329. ACM Press,
August 1988. Stanford, CA.
[21] ジェーコブソンと、V.と、「輻輳回避とコントロール。」 Proceedings、SIGCOMM88年Workshop、314--329ページで。 ACMは1988年8月に押します。 スタンフォード(カリフォルニア)。
[22] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[22] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[24] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[24]McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[25] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[25] マクレガー(G.、「pppインターネットプロトコル制御プロトコル(IPCP)」RFC1332)は1992がそうするかもしれません。
[26] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[26] 工場、D.、「ネットワーク時間プロトコル(バージョン3)仕様、実装」RFC1305、3月1992日
[27] Montenegro, G., "Reverse Tunneling for Mobile IP (revised)",
RFC 3024, January 2001.
[27] モンテネグロ、G.、「モバイルIP(改訂される)のための逆のトンネリング」、RFC3024、2001年1月。
[28] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N.
Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[28] モンテネグロとG.とダウキンズとS.とKojoとM.とMagretとV.とN.Vaidya、「長い薄いネットワーク」、RFC2757、2000年1月。
[29] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[29] モンテネグロ、G.、および「モバイルIPのためのSunのスキップファイアウォール縦断」、RFC2356、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問題部に書くためのガイドライン」、RFC2434、1998年10月。
[31] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[31] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
Perkins Standards Track [Page 95] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[95ページ]RFC3220IP移動性サポート
[32] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[32] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[33] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[33] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[34] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[34] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[35] Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile
IP", Work in Progress, July 2001.
[35] 「モバイルIPのためのAAA登録キー」というパーキンス、C.、およびP.カルフーンは進歩、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] プラマー、D.、「イーサネットアドレス決議は以下について議定書の中で述べます」。 「または、ネットワーク・プロトコルを変換するのは、イーサネットハードウェアの上でイーサネットがトランスミッションのためのアドレスであると48.bitに扱う」STD37、RFC826、1982年11月。
[37] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[37] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[38] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[38] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[39] Postel, J., "Multi-LAN Address Resolution", RFC 925, October
1984.
[39] ポステル、J.、「マルチLANアドレス解決」、RFC925、1984年10月。
[40] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[40] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[41] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[41] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[42] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[42] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[43] Solomon, J., "Applicability Statement for IP Mobility Support"
RFC 2005, October 1996.
1996年10月の[43] ソロモン、J.、「IP移動性サポートのための適用性証明」RFC2005。
[44] Solomon J. and S. Glass, "Mobile-IPv4 Configuration Option for
PPP IPCP", RFC 2290, February 1998.
[44] RFC2290、ソロモンJ.とS.は「ppp IPCPのためのモバイルIPv4設定オプション」とガラスで覆って、2月は1998です。
[45] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols"
Addison-Wesley, Reading, Massachusetts, 1994.
[45] w.スティーブンス、「TCP/IPは例証して、ボリュームは1です」。 「プロトコル」アディソン-ウエスリー、読書、マサチューセッツ、1994。
Perkins Standards Track [Page 96] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[96ページ]RFC3220IP移動性サポート
Authors' Addresses
作者のアドレス
The working group can be contacted via the current chairs:
現在のいすを通してワーキンググループに連絡できます:
Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX. 75039 USA
Basavarajパティルノキア6000接続アービング博士(テキサス)。 75039 米国
Phone: +1 972-894-6709 Email: Basavaraj.Patil@nokia.com
以下に電話をしてください。 +1 972-894-6709 メールしてください: Basavaraj.Patil@nokia.com
Phil Roberts Megisto Corp. Suite 120 20251 Century Blvd Germantown MD 20874 USA
フィルロバーツMegisto社のSuite120 20251世紀のBlvdジャーマンタウンMD20874米国
Phone: +1 847-202-9314 Email: PRoberts@MEGISTO.com
以下に電話をしてください。 +1 847-202-9314 メールしてください: 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フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502
以下に電話をしてください。 +1-650 625-2986 メールしてください: charliep@iprg.nokia.com Fax: +1 650 625-2502
Perkins Standards Track [Page 97] RFC 3220 IP Mobility Support for IPv4 January 2002
IPv4 January 2002のパーキンス標準化過程[97ページ]RFC3220IP移動性サポート
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Perkins Standards Track [Page 98]
パーキンス標準化過程[98ページ]
一覧
スポンサーリンク
