RFC2002 日本語訳
2002 IP Mobility Support. C. Perkins, Ed.. October 1996. (Format: TXT=193103 bytes) (Obsoleted by RFC3220) (Updated by RFC2290) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Perkins, Editor Request for Comments: 2002 IBM Category: Standards Track October 1996
ワーキンググループのC.パーキンス、コメントを求めるエディタ要求をネットワークでつないでください: 2002年のIBMカテゴリ: 標準化過程1996年10月
IP Mobility Support
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)の現行版を参照してください。 このメモの分配は無制限です。
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データグラムの見え透いたルーティングをインターネットの可動のノードに許すプロトコル増進を指定します。 それぞれの可動のノードはインターネットへの現在の接着点にかかわらずいつもホームアドレスによって特定されます。 また、家から遠くに位置している間、可動のノードと交際する、注意、-、アドレス、現在の接着点の情報をインターネットに提供する。 プロトコルが登録に備える、注意、-、家のエージェントとのアドレス。 家のエージェントは可動のノードのためにトンネルを通ってアドレスの注意に運命づけられたデータグラムを送ります。 そして、トンネルの到着した後端では、各データグラムを可動のノードに届けます。
Table of Contents
目次
1. Introduction 3
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 3
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.5. New Architectural Entities . . . . . . . . . . . . . . . 5
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
1.8. Specification Language . . . . . . . . . . . . . . . . . 11
1.9. Message Format and Protocol Extensibility . . . . . . . . 12
2. Agent Discovery 14
2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 14
2.1.1. Mobility Agent Advertisement Extension . . . . . 16
2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . 18
2.1.3. One-byte Padding Extension . . . . . . . . . . . 19
2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 19
2.3. Foreign Agent and Home Agent Considerations . . . . . . . 19
2.3.1. Advertised Router Addresses . . . . . . . . . . . 20
1. 序論3 1.1。 要件. . . . . . . . . . . . . . . . . . 3 1.2について議定書の中で述べてください。 目標. . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 仮定. . . . . . . . . . . . . . . . . . . . . . . 4 1.4。 適用性. . . . . . . . . . . . . . . . . . . . . . 4 1.5。 新しい建築実体. . . . . . . . . . . . . . . 5 1.6。 用語. . . . . . . . . . . . . . . . . . . . . . . 6 1.7。 概観. . . . . . . . . . . . . . . . . . . . 8 1.8について議定書の中で述べてください。 仕様言語. . . . . . . . . . . . . . . . . 11 1.9。 メッセージ・フォーマットとプロトコル伸展性. . . . . . . . 12 2。 エージェント発見14 2.1。 エージェント広告. . . . . . . . . . . . . . . . . . . 14 2.1.1。 移動性エージェント広告拡大. . . . . 16 2.1.2。 接頭語長さの拡大. . . . . . . . . . . . 18 2.1.3。 1バイトの詰め物拡大. . . . . . . . . . . 19 2.2。 エージェント懇願. . . . . . . . . . . . . . . . . . . 19 2.3。 外国人のエージェントとホームエージェント問題. . . . . . . 19 2.3.1。 広告を出しているルータアドレス. . . . . . . . . . . 20
Perkins Standards Track [Page 1] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[1ページ]。
2.3.2. Sequence Numbers and Rollover Handling . . . . . 21
2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 21
2.4.1. Registration Required . . . . . . . . . . . . . . 22
2.4.2. Move Detection . . . . . . . . . . . . . . . . . 22
2.4.3. Returning Home . . . . . . . . . . . . . . . . . 24
2.4.4. Sequence Numbers and Rollover Handling . . . . . 24
3. Registration 24
3.1. Registration Overview . . . . . . . . . . . . . . . . . . 25
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 26
3.3. Registration Request . . . . . . . . . . . . . . . . . . 26
3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 29
3.5. Registration Extensions . . . . . . . . . . . . . . . . . 32
3.5.1. Computing Authentication Extension Values . . . . 32
3.5.2. Mobile-Home Authentication Extension . . . . . . 33
3.5.3. Mobile-Foreign Authentication Extension . . . . . 33
3.5.4. Foreign-Home Authentication Extension . . . . . . 34
3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 34
3.6.1. Sending Registration Requests . . . . . . . . . . 36
3.6.2. Receiving Registration Replies . . . . . . . . . 40
3.6.3. Registration Retransmission . . . . . . . . . . . 42
3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 43
3.7.1. Configuration and Registration Tables . . . . . . 44
3.7.2. Receiving Registration Requests . . . . . . . . . 44
3.7.3. Receiving Registration Replies . . . . . . . . . 47
3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 49
3.8.1. Configuration and Registration Tables . . . . . . 49
3.8.2. Receiving Registration Requests . . . . . . . . . 49
3.8.3. Sending Registration Replies . . . . . . . . . . 53
4. Routing Considerations 55
4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 56
4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . . 56
4.2.1. Mobile Node Considerations . . . . . . . . . . . 56
4.2.2. Foreign Agent Considerations . . . . . . . . . . 57
4.2.3. Home Agent Considerations . . . . . . . . . . . . 58
4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . . 59
4.4. Multicast Datagram Routing . . . . . . . . . . . . . . . 60
4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 61
4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . . 62
5. Security Considerations 66
5.1. Message Authentication Codes . . . . . . . . . . . . . . 66
5.2. Areas of Security Concern in this Protocol . . . . . . . 66
5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 67
5.4. Picking Good Random Numbers . . . . . . . . . . . . . . . 67
5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.6. Replay Protection for Registration Requests . . . . . . . 68
5.6.1. Replay Protection using Timestamps . . . . . . . 68
5.6.2. Replay Protection using Nonces . . . . . . . . . 69
6. Acknowledgments 71
2.3.2. 一連番号とロールオーバー取り扱. . . . . 21 2.4い。 モバイルノード問題. . . . . . . . . . . . . . . 21 2.4.1。 登録必要な. . . . . . . . . . . . . . 22 2.4.2。 検出. . . . . . . . . . . . . . . . . 22 2.4.3を動かしてください。 ホーム. . . . . . . . . . . . . . . . . 24 2.4.4を返します。 一連番号とロールオーバー取り扱. . . . . 24 3い。 登録24 3.1。 登録概観. . . . . . . . . . . . . . . . . . 25 3.2。 認証. . . . . . . . . . . . . . . . . . . . . 26 3.3。 登録要求. . . . . . . . . . . . . . . . . . 26 3.4。 登録回答. . . . . . . . . . . . . . . . . . . 29 3.5。 登録拡大. . . . . . . . . . . . . . . . . 32 3.5.1。 .2に認証拡大値. . . . 32 3.5を計算します。 移動住宅認証拡大. . . . . . 33 3.5.3。 モバイルに外国の認証拡大. . . . . 33 3.5.4。 外国ホーム認証拡大. . . . . . 34 3.6。 モバイルノード問題. . . . . . . . . . . . . . . 34 3.6.1。 登録要求. . . . . . . . . . 36 3.6.2を送ります。 .3に登録回答. . . . . . . . . 40 3.6を受け取ります。 登録Retransmission. . . . . . . . . . . 42 3.7。 外国エージェント問題. . . . . . . . . . . . . . 43 3.7.1。 構成とレジスタ・テーブル. . . . . . 44 3.7.2。 登録要求. . . . . . . . . 44 3.7.3を受け取ります。 登録回答. . . . . . . . . 47 3.8を受け取ります。 ホームエージェント問題. . . . . . . . . . . . . . . . 49 3.8.1。 構成とレジスタ・テーブル. . . . . . 49 3.8.2。 登録要求. . . . . . . . . 49 3.8.3を受け取ります。 登録回答. . . . . . . . . . 53 4を送ります。 問題55 4.1を発送します。 カプセル化は.564.2をタイプします。 ユニキャストデータグラムルート設定. . . . . . . . . . . . . . . . 56 4.2.1。 モバイルノード問題. . . . . . . . . . . 56 4.2.2。 外国エージェント問題. . . . . . . . . . 57 4.2.3。 ホームエージェント問題. . . . . . . . . . . . 58 4.3。 データグラム. . . . . . . . . . . . . . . . . . . 59 4.4を放送してください。 マルチキャストデータグラムルート設定. . . . . . . . . . . . . . . 60 4.5。 モバイルルータ. . . . . . . . . . . . . . . . . . . . . 61 4.6。 ARP、プロキシARP、および無料のARP. . . . . . . . . . . 62 5。 セキュリティ問題66 5.1。 通報認証は.665.2をコード化します。 このプロトコル. . . . . . . 66 5.3のSecurity Concernの領域。 Key Management. . . . . . . . . . . . . . . . . . . . . 67 5.4。 良い乱数. . . . . . . . . . . . . . . 67 5.5を選びます。 プライバシー. . . . . . . . . . . . . . . . . . . . . . . . . 67 5.6。 登録要求. . . . . . . 68 5.6.1のための保護を再演してください。 タイムスタンプ. . . . . . . 68 5.6.2を使用して、保護を再演してください。 一回だけ. . . . . . . . . 69 6を使用して、保護を再演してください。 承認71
Perkins Standards Track [Page 2] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[2ページ]。
A. Patent Issues 72
A.1. IBM Patent #5,159,592 . . . . . . . . . . . . . . . . . . 72
A.2. IBM Patent #5,148,479 . . . . . . . . . . . . . . . . . . 72
B. Link-Layer Considerations 73
C. TCP Considerations 73
C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 73
C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 73
D. Example Scenarios 74
D.1. Registering with a Foreign Agent Care-of Address . . . . 74
D.2. Registering with a Co-Located Care-of Address . . . . . . 75
D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 76
E. Applicability of Prefix Lengths Extension 76
Editor's Address 79
A.特許問題72A.1。 IBM特許#5,159,592.72A.2。 IBM特許#5,148,479.72のB.リンクレイヤ問題73C.TCP問題73C.1。 TCPタイマ. . . . . . . . . . . . . . . . . . . . . . . 73C.2。 TCPふくそう管理. . . . . . . . . . . . . . . . 73D.例のシナリオ74D.1。 外国人のエージェントとともに記名する、注意、-、アドレス. . . . 74D.2。 aへの登録が共同場所を見つけた、注意、-、アドレス. . . . . . 75D.3。 拡大76エディタのものが記述する接頭語の長さのDeregistration. . . . . . . . . . . . . . . . . . . . . 76E.の適用性、79
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つを通常使わなければなりません:
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アドレスを変えないでそれらの接着点をインターネットに変えるのを可能にします)。
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アドレスを変えていなくて。
Perkins Standards Track [Page 3] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[3ページ]。
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.
しばしば可動のノードが直接インターネットに添付されるリンクは無線のリンクであるかもしれません。 このリンクには、その結果、実質的に下側の帯域幅と伝統的な有線ネットワークより高い誤り率があるかもしれません。 そのうえ、可動のノードは動かされたバッテリーである傾向があります、そして、電力消費量を最小にするのは重要です。 したがって、可動のノードが直接インターネットに添付されるリンクの上に送られた管理メッセージの数は最小にされるべきです、そして、これらのメッセージのサイズは合理的にできるだけ小さく保たれるべきです。
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
人は「マクロ」移動性管理問題を解決するとモバイルIPを考えることができます。 それは「マイクロより」の移動性管理にそれほどよくない合っていません。
Perkins Standards Track [Page 4] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[4ページ]。
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よりはるかに少ないオーバーヘッドを提供するかもしれません。
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アドレスを使用することでどんな位置の他のインターネット接続装置ともコミュニケートし続けるかもしれません、接着点へのリンクレイヤの接続性が利用可能であると仮定して。
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)。
Perkins Standards Track [Page 5] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[5ページ]。
1.6. Terminology
1.6. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
Agent Advertisement
An advertisement message constructed by attaching a
special Extension to a router advertisement [4] message.
ルータ通知[4]メッセージに特別なExtensionを取り付けることによって構成されたエージェントAdvertisement An広告メッセージ。
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.
注意、-、aの終了ポイントがそれが家にいない間に可動のノードに送られたデータグラムのための可動のノードに向かってトンネルを堀るAddress。 プロトコルが2つの異なったタイプを使用できる、注意、-、アドレス: 「外国人のエージェント、注意、-、アドレス、」、可動のノードが登録されている外国人のエージェント、およびaがアドレスがある、「共同見つけられている、注意、-、アドレス、」 可動のノードにはある外部的に得られたローカルアドレスはそれ自身のネットワーク・インターフェースの1つに関連していますか?
Correspondent Node
A peer with which a mobile node is communicating. A
correspondent node may be either mobile or stationary.
可動のノードと交信する予定である通信員Node Aはじっと見ます。 通信員ノードは、可動であるか、または静止しているかもしれません。
Foreign Network
Any network other than the mobile node's Home Network.
可動のノードのホームを除いて、外国Network AnyはNetworkをネットワークでつなぎます。
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.
延ばされた期間の間に可動のノードに割り当てられるホームAddress An IPアドレス。 それはどこにかかわらず変わりがないか。ノードはインターネットに添付されます。
Home Network
A network, possibly virtual, having a network prefix
matching that of a mobile node's home address. Note that
standard IP routing mechanisms will deliver datagrams
destined to a mobile node's Home Address to the mobile
node's Home Network.
Network Aネットワークで、ことによると仮想で、可動のノードのホームアドレスのものに合っているネットワーク接頭語を持っていて、家へ帰ってください。 標準のIPルーティングメカニズムが可動のノードのホームAddressに運命づけられたデータグラムを可動のノードのホームNetworkに渡すことに注意してください。
Link A facility or medium over which nodes can communicate at
the link layer. A link underlies the network layer.
ノードがリンクレイヤで交信できるA施設か媒体をリンクしてください。 リンクはネットワーク層の基礎となります。
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.
アドレスが物理的なリンクの上に何らかのコミュニケーションの終点を特定するのに使用したリンク層のAddress。 Link-層のアドレスは通常、インタフェースのメディアAccess Control(MAC)アドレスです。
Mobility Agent
Either a home agent or a foreign agent.
移動性エージェントのEither a家のエージェントか外国人のエージェント。
Perkins Standards Track [Page 6] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[6ページ]。
Mobility Binding
The association of a home address with a care-of address,
along with the remaining lifetime of that association.
移動性Binding、ホームアドレスの協会、注意、-、アドレス、その協会の残っている生涯と共に。
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.6).
1組のノードの間のセキュリティ文脈の移動性Security Association A収集。ノードはそれらの間で交換されたモバイルIPプロトコルメッセージに適用されるかもしれません。 各文脈は認証アルゴリズム、モード(セクション5.1)、秘密(共有されたキー、または適切な公衆/秘密鍵組)、および使用中の反復操作による保護のスタイル(セクション5.6)を示します。
Node A host or a router.
ノードAホストかルータ。
Nonce A randomly chosen value, different from previous choices,
inserted in a message to protect against replays.
守るメッセージに挿入された前の選択と異なった値が手当たりしだいに選ばれた一回だけAは再演されます。
Security Parameter Index (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.
セキュリティParameter Index、(SPI) 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.
仮想のNetwork Aはどんな物理的な具体化も向こうにないどんなルータ(物理ネットワークインタフェースが別のネットワークにある)もネットワークでつなぎません。 一般に、ルータ(例えば、家のエージェント)は、従来のルーティング・プロトコルを使用することで仮想ネットワークに可到達性の広告を出します。
Visited Network
A network other than a mobile node's Home Network, to
which the mobile node is currently connected.
可動のノードのホームを除いて、訪問されたNetwork AはNetworkをネットワークでつなぎます。(可動のノードは現在、Networkに接続されます)。
Visitor List
The list of mobile nodes visiting a foreign agent.
訪問者List、外国人のエージェントを訪問する可動のノードのリスト。
Perkins Standards Track [Page 7] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[7ページ]。
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 directly with its home agent, or through a foreign
agent which forwards the registration to the home agent.
登録When、登録する、可動のノードが家にいないそれ、注意、-、家のエージェントとのアドレス。 付属の方法によって、可動のノードは直接家のエージェントか、家のエージェントに登録を送る外国人のエージェントを通して登録するでしょう。
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 [6] (a co-located
care-of address).
- 可動のノードがそれを検出するとき、外国ネットワークに動きました、それ、入手、注意、-、アドレス、外国ネットワークで。 注意、-、アドレス、どちらかが外国人のエージェントの広告によって断固としている場合がある、(外国人のエージェント、注意、-、アドレス)、DHCP[6]などの外部の何らかの割当機構、(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)を記述してください。
Perkins Standards Track [Page 8] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[8ページ]。
- Datagrams sent to the mobile node's home address are intercepted
by its home agent, tunneled by the home agent to the mobile
node's care-of address, received at the tunnel endpoint (either
at a foreign agent or at the mobile node itself), and finally
delivered to the mobile node (Section 4.2.3).
- データグラムが家のエージェントによって妨害されて、家のエージェントによってトンネルを堀られた可動のノードのホームアドレスに発信した、可動のノードのもの、注意、-、アドレス、トンネル終点(外国人のエージェントにおける、または、可動のノード自体の)で受け取られていて、最終的に可動のノード(セクション4.2.3)に渡します。
- In the reverse direction, datagrams sent by the mobile node
are generally delivered to their destination using standard IP
routing mechanisms, not necessarily passing through the home
agent.
- 反対の方向では、一般に、標準のIPルーティングメカニズムを使用することで可動のノードによって送られたデータグラムをそれらの送付先に届けます、必ず家のエージェントを通り抜けるというわけではなくて。
When away from home, Mobile IP uses protocol tunneling to hide a mobile node's home address from intervening routers between its home network and its current location. The tunnel terminates at the mobile node's care-of address. The care-of address must be an address to which datagrams can be delivered via conventional IP routing. At the care-of address, the original datagram is removed from the tunnel and delivered to the mobile node.
家から離れているとき、モバイルIPは、ホームネットワークとその現在の位置の間に可動のノードのホームアドレスを介入しているルータから隠すのにプロトコルトンネリングを使用します。 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 "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.
- 「外国人のエージェント、注意、-、アドレス、」、注意、-、アドレス、エージェントAdvertisementメッセージを通して外国人のエージェントによって提供されます。 この場合、注意、-、アドレスは外国人のエージェントのIPアドレスです。 このモードで、外国人のエージェントは、トンネルの終点であり、トンネルを堀られたデータグラムを受けるときそれらをdecapsulatesして、内側のデータグラムを可動のノードに届けます。 多くの可動のノードがそれで同じように共有できるので獲得のこの方法が好まれる、注意、-、既に有限なIPv4アドレス空間における不要な要求を記述して、したがって、置きません。
- 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 [6],
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.
- 「共同見つけられている、注意、-、アドレス、」、aである、注意、-、ローカルアイピーアドレスとして可動のノードによって次に、可動のノードがそれ自身のネットワーク・インターフェースの1つに関連づけるいくつかの外部の手段で習得されたアドレス。 アドレスを仮の住所としてDHCP[6]などの可動のノードでダイナミックに習得するか、または可動のノードは何らかの外国ネットワークを訪問しているだけである間、使用のための長期のアドレスとして所有するかもしれません。 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.
aを使用するモードが共同場所を見つけた、注意、-、アドレスには、それが例えば、外国人のエージェントなしでまだ外国人のエージェントを配備していないネットワークで機能するのを可動のノードを許容する利点があります。
Perkins Standards Track [Page 9] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[9ページ]。
It does, however, place additional burden on the IPv4 address space because it requires a pool of addresses within the foreign network to be made available to visiting mobile nodes. It is difficult to efficiently maintain pools of addresses for each subnet that may permit mobile nodes to visit.
訪問の可動のノードに利用可能に作られているのが外国ネットワークの中でアドレスのプールを必要とするので、しかしながら、それはIPv4アドレス空間に追加負担をかけます。 効率的に可動のノードが訪問することを許可するかもしれない各サブネットのためのアドレスのプールを維持するのは難しいです。
It is important to understand the distinction between the care-of address and the foreign agent functions. The care-of address is simply the endpoint of the tunnel. It might indeed be an address of a foreign agent (a foreign agent care-of address), but it might instead be an address temporarily acquired by the mobile node (a co- located care-of address). A foreign agent, on the other hand, is a mobility agent that provides services to mobile nodes. See Sections 3.7 and 4.2.2 for additional details.
区別を理解しているのが重要である、注意、-、アドレス、そして、外国エージェント機能。 注意、-、アドレスは単にトンネルの終点です。 本当に、それが外国人のエージェントのアドレスであるかもしれない、(外国人のエージェント、注意、-、アドレス)、それが代わりに可動のノードによって一時習得されたアドレスであるかもしれない、(aが共同場所を見つけた、注意、-、アドレス) 他方では、外国人のエージェントは可動のノードに対するサービスを提供する移動性エージェントです。 追加詳細に関してセクション3.7と4.2.2を見てください。
A home agent MUST be able to attract and intercept datagrams that are destined to the home address of any of its registered mobile nodes. Using the proxy and gratuitous ARP mechanisms described in Section 4.6, this requirement can be satisfied if the home agent has a network interface on the link indicated by the mobile node's home address. Other placements of the home agent relative to the mobile node's home location MAY also be possible using other mechanisms for intercepting datagrams destined to the mobile node's home address. Such placements are beyond the scope of this document.
ホームのエージェントは、登録されたモバイルノードのどれかに関するホームアドレスに運命づけられているデータグラムを、引き付けて、妨害できなければなりません。 セクション4.6で説明されたプロキシと無料のARPメカニズムを使用して、ホームのエージェントがモバイルノードのホームアドレスでリンクの上のネットワーク・インターフェースを示させるなら、この要件を満たすことができます。 また、モバイルノードのホームアドレスに運命づけられたデータグラムを妨害するのに他のメカニズムを使用して、モバイルノードのホームの位置に比例したホームのエージェントの他のプレースメントも可能であるかもしれません。 そのようなプレースメントはこのドキュメントの範囲を超えています。
Similarly, a mobile node and a prospective or current foreign agent MUST be able to exchange datagrams without relying on standard IP routing mechanisms; that is, those mechanisms 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)で説明されるように)、ネットワーク接頭語によって特定されたリンクにモバイルノードの見つけなければならない、これ、注意、-、アドレス さもなければ、データグラムが運命づけた、注意、-、アドレスは「非-提出物」でしょう。
For example, the figure below 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 the figure below, the mobile node is using a foreign agent care-of address:
例えば、以下の図はノードと、そして、ホームから遠くのモバイルノードからデータグラムのルーティングを例証します、モバイルノードがいったんホームのエージェントとともに記名すると。 以下の図では、モバイルノードが外国人のエージェントを使用している、注意、-、アドレス:
Perkins Standards Track [Page 10] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[10ページ]。
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ルーティングで。 +----+ 外国人のエージェントはそうです。|ホスト| モバイルノードのデフォルトルータ。 +----+
1.8. Specification Language
1.8. 仕様言語
In this document, several words are used to signify the requirements of the specification. These words are often capitalized.
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。
MUST This word, or the adjective "required", means that
the definition is an absolute requirement of the
specification.
「必要である」というThis単語、または形容詞が、定義が仕様に関する絶対条件であることを意味しなければなりません。
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
Thisは定義がある手段を言葉で表してはいけません。仕様の絶対禁止。
SHOULD This word, or the adjective "recommended", means
that, in some circumstances, valid reasons may exist
to ignore this item, but the full implications must
be understood and carefully weighed before choosing
a different course. Unexpected results may result
otherwise.
「推薦される」というSHOULD This単語、または形容詞が、正当な理由がこの項目を無視するためにいくつかの事情に存在するかもしれないことを意味しますが、完全な含意を理解されて、異なったコースを選ぶ前に、慎重に熟慮しなければなりません。 そうでなければ、予期しなかった結果は結果として生じるかもしれません。
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementation
which does include the option.
5月のThis単語、または「任意である」という形容詞が、この項目が許容セットの代替手段の1つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
Perkins Standards Track [Page 11] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[11ページ]。
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は統計カウンタに出来事を記録に残します。
1.9. Message Format and Protocol Extensibility
1.9. メッセージ・フォーマットとプロトコル伸展性
Mobile IP defines a set of new control messages, sent with UDP [17] using well-known port number 434. Currently, the following two message types are defined:
モバイルIPはUDP[17]がウェルノウン・ポート番号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" [20].
モバイルIPコントロールメッセージのためのメッセージタイプに、最新の値は最新の「規定番号」[20]で指定されます。
In addition, for Agent Discovery, Mobile IP makes use of the existing Router Advertisement and Router Solicitation messages defined for ICMP Router Discovery [4].
さらに、エージェントディスカバリーのために、モバイルIPはRouter AdvertisementとRouter SolicitationメッセージがICMP Routerディスカバリー[4]のために定義した存在を利用します。
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. Each of these Extensions (with one exception) is encoded in the following Type-Length-Value format:
モバイルIPは、任意の情報がモバイルIPコントロールメッセージかICMP Routerディスカバリーメッセージによって運ばれるのを許容するために一般的なExtensionメカニズムを定義します。 それぞれのこれらのExtensionsは以下のType長さの価値の形式で(ただ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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | タイプ| 長さ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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 12] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[12ページ]。
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データグラムの全長によって示されます。
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). Currently, 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 [4]. Currently, Mobile IP
defines the following Types for Extensions appearing in ICMP
Router Discovery messages:
- 2番目のセットはICMP Routerディスカバリーメッセージ[4]だけに現れるかもしれないそれらの拡大から成ります。 現在、モバイルIPはICMP Routerディスカバリーメッセージに現れるExtensionsのために以下のTypesを定義します:
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" [20].
それぞれの個々のExtensionは後で別々のセクションで詳細に本書では説明されます。 これらのExtension Type番号のための最新の値は最新の「規定番号」[20]で指定されます。
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ディスカバリーメッセージだけで使用されるかもしれない限り。
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.
範囲の中でこれらのセットのどちらかで0〜127に付番されたExtensionが遭遇しますが、認識されないとき、静かにそのExtensionを含むメッセージを捨てなければなりません。 範囲で128〜255に付番されたExtensionが遭遇するとき、(認識されません)その特定のExtensionは無視されますが、まだExtensionsとメッセージデータの残りを処理しなければなりません。 ExtensionのLength分野は、次のExtensionを捜し求める際にData分野をスキップするのに使用されます。
Perkins Standards Track [Page 13] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[13ページ]。
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 [4] 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ディスカバリー[4]を広げています。 エージェント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 [1], 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[1]であるかもしれない(本書では説明されたメッセージに関係ありません)。 AdvertisementとSolicitationメッセージが認証されるかもしれない方法のさらなる仕様はこのドキュメントの範囲の外にあります。
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分野が以下の追加仕様に従うのに必要です:
Perkins Standards Track [Page 14] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[14ページ]。
- 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の目的地Addressは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 [4], the IP
destination address of an Agent Advertisement MUST
be either the "all systems on this link" multicast
address (224.0.0.1) [5] 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.
目的地Address AsがICMP Routerディスカバリー[4]に指定して、エージェントAdvertisementの受信者IPアドレスが「このリンクの上のすべてのシステム」マルチキャストアドレスであるに違いない、(224.0の.0.1)[5]か「限られた放送」アドレス、(255.255 .255 .255)。 サブネットによって指示にされるのはフォーム<接頭語>のアドレスを放送しました。モバイルノードが一般に外国ネットワークの接頭語を知らないので、<-1>は使用できません。
- 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)
See Section 2.3.1 for a discussion of the addresses
that may appear in this portion of the Agent
Advertisement.
ルータAddress(es)はエージェントAdvertisementのこの一部に現れるかもしれないアドレスの議論に関してセクション2.3.1を見ます。
Perkins Standards Track [Page 15] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[15ページ]。
Num Addrs
The number of Router Addresses advertised in this
message. Note that in an Agent Advertisement
message, the number of router addresses specified in
the ICMP Router Advertisement portion of the message
MAY be set to 0. See Section 2.3.1 for details.
Router Addressesの数がこのメッセージに広告を出したヌムAddrs。 エージェントAdvertisementメッセージでは、メッセージのICMP Router Advertisement部分で指定されたルータアドレスの数が0に設定されるかもしれないことに注意してください。 詳細に関してセクション2.3.1を見てください。
If sent periodically, the nominal interval at which Agent Advertisements are sent SHOULD be 1/3 of the advertisement Lifetime given in the ICMP header. 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 [4] in order to avoid synchronization and subsequent collisions with other Agent Advertisements that may be sent by other agents (or with other Router Advertisements sent by other routers). Note that this field has no relation to the "Registration Lifetime" field within the Mobility Agent Advertisement Extension defined below.
定期的に送るなら、SHOULDが1/3の広告がICMPヘッダーで与えられているLifetimeであったならエージェントAdvertisementsに送られる名目上の間隔です。 これで、有効なエージェントのリストからエージェントを削除する前に、モバイルノードは3つの連続した広告を逃すことができます。 実際のトランスミッション時間は、[4] 同期を避けるためにランダマイズされて、各広告SHOULDがわずかにそうであり、他のエージェントAdvertisementsとのその後の衝突がそれであるので、他のエージェント(または他のルータで他のRouter Advertisementsを送って)によって送られるかもしれません。 この分野は以下で定義されたMobilityエージェントAdvertisement Extensionの中で「登録生涯」分野に関係がないことに注意してください。
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|V| 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|V| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロか以上、Care、-、Addresses| | ... |
Type 16
16をタイプしてください。
Length (6 + 4*N), where N is the number of care-of addresses
advertised.
Nが数であるところの長さ(6+4*N)、注意、-、アドレスは広告を出しました。
Sequence Number
The count of Agent Advertisement messages sent since the
agent was initialized (Section 2.3.2).
エージェント以来エージェントAdvertisementメッセージのカウントが送った系列Numberは初期化されました(セクション2.3.2)。
Perkins Standards Track [Page 16] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[16ページ]。
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でも受け入れても構わないと思う最も長い生涯(秒に測定される)の間の登録Lifetime。 0xffffの値は無限を示します。 この分野はエージェントAdvertisementのICMP Router Advertisement部分の中で「生涯」分野に関係がありません。
R Registration required. Registration with this foreign
agent (or another foreign agent on this link) is required
rather than 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メッセージが送られるリンクに対してはサービスを提供します。
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 [15].
M最小量のカプセル化。 このエージェントは最小量のカプセル化[15]を使用するトンネルを堀られたデータグラムを受信に実装します。
G GRE encapsulation. This agent implements receiving
tunneled datagrams that use GRE encapsulation [8].
G GREカプセル化。 このエージェントはGREカプセル化[8]を使用するトンネルを堀られたデータグラムを受信に実装します。
V Van Jacobson header compression. This agent supports use
of Van Jacobson header compression [10] over the link
with any registered mobile node.
Vヴァンジェーコブソンヘッダー圧縮。 このエージェントはどんな登録されたモバイルノードとのリンクの上のヴァンジェーコブソンヘッダー圧縮[10]の使用をサポートします。
reserved
Sent as zero; ignored on reception.
ゼロとしての予約されたSent。 レセプションでは、無視されます。
Care-of Address(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.
注意、-、広告を出している外国人のエージェントのAddress(es)、注意、-、アドレス(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
ホームのエージェントはいつもそれがホームのエージェントであるモバイルノードに役立つ用意ができていなければなりません。 外国人のエージェントは時には、追加モバイルノードに役立つことができないくらい忙しいかもしれません。 たとえそうだとしても、エージェントAdvertisementsを送り続けなければなりません、既にそれに登録されたどんなモバイルノードも、外国人のエージェントの範囲から引っ越していなくて、また外国人のエージェントが失敗していないのを知るように。 A外国です。
Perkins Standards Track [Page 17] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[17ページ]。
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, and at least one of the 'F' bit and the 'H' bit MUST be set in any Agent Advertisement message sent.
エージェントは、新しいモバイルノードがそれとともに記名するのを許容するのが「忙し過ぎること」を示すかもしれません、'B'ビットをエージェントAdvertisementsにはめ込むことによって。 エージェントAdvertisementメッセージで、また、'F'ビットが設定されないで、Advertisementメッセージが送ったどんなエージェントにも少なくとも'F'ビットの1つと'H'ビットを設定しなければならないなら、'B'ビットを設定してはいけません。
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つに設定してはいけません。
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 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)
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.
Length(s)を前に置いてください。対応する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 Lengths Extensionがモバイルノードによってどう使用されるかもしれないかの情報に関してセクション2.4.2を見てください。 このExtensionの使用に関する実装の詳細に関してAppendix Eを見てください。
Perkins Standards Track [Page 18] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[18ページ]。
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であったなら含まないエージェント。
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 SHOULD respond to Agent Solicitations.
リンク層プロトコルで発見できないどんな移動性エージェントもエージェントAdvertisementsを送らなければなりません。 またSHOULDがエージェントAdvertisementsを実装するリンク層プロトコルで発見できるエージェント。 しかしながら、サイト方針がエージェントとの登録を必要とする(すなわち、'R'ビットはいつ設定されますか)時か、特定のエージェントSolicitationへの応答としてAdvertisementsを送る必要はありません。 すべての移動性エージェントSHOULDはエージェントSolicitationsに応じます。
The same procedures, defaults, and constants are used in Agent Advertisement messages and Agent Solicitation messages as specified for ICMP Router Discovery [4], except that:
同じ手順、デフォルト、および定数はICMP Routerディスカバリー[4]への指定されるとしてのエージェントAdvertisementメッセージとエージェントSolicitationメッセージで用いられます、それを除いて:
- a mobility agent MUST limit the rate at which it sends broadcast
or multicast Agent Advertisements; a recommended maximum rate is
once per second, AND
- 移動性エージェントはそれが放送かマルチキャストエージェントAdvertisementsを送るレートを制限しなければなりません。 お勧めの最高率が2番目、AND単位で一度あります。
Perkins Standards Track [Page 19] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[19ページ]。
- 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を送るために構成されるかもしれません。
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.
モバイルノードのホームアドレスによって特定されたリンクに見つけられていて、ホームネットワークであるなら、次に、仮想ネットワーク、どんなモバイルノードのためのホームのエージェントもSHOULDではありません。このリンクの上のホームのエージェントによって送られたエージェントAdvertisementメッセージで、'H'ビットを設定しなければなりません。 このように、それら自身のホームネットワークのモバイルノードは、それらが本当にホームにあることを決定できるでしょう。 Advertisementメッセージでそれが付けられるかもしれない(それが1個以上のリンクに勤めている移動性エージェントであるなら)別のリンクの上のホームのエージェントで送って、また、ホームのエージェントがその他のリンクの上のホームのエージェント(他のモバイルノードへの)として勤めない場合'H'ビットが設定してはいけないどんなエージェント。
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. Thus, an agent MAY include one of its own addresses in the advertisement. A foreign agent MAY discourage use of this address as a default router by setting the preference to a low value and by including the address of another router in the advertisement (with a correspondingly higher preference). Nevertheless, a foreign agent MUST route datagrams it receives from registered mobile nodes (Section 4.2.2).
エージェントAdvertisementのICMP Router Advertisement部分は1つ以上のルータアドレスを含むかもしれません。 したがって、エージェントは広告でそれ自身のアドレスの1つを入れるかもしれません。 低値に好みを設定して、広告で別のルータのアドレスを含めることによって(対応するより高い優先がある)、外国人のエージェントはデフォルトルータとしてこのアドレスの使用に水をさしているかもしれません。 それにもかかわらず、外国人のエージェントはそれが登録されたモバイルノード(セクション4.2.2)から受けるデータグラムを発送しなければなりません。
Perkins Standards Track [Page 20] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[20ページ]。
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 reductions in sequence numbers that result from reboots, from reductions that result in rollover of the sequence number after it attains the value 0xffff.
エージェントAdvertisementsの一連番号は0〜0xffffまで及びます。 穂ばらみの後に、エージェントは最初の広告のNo.0を使用しなければなりません。 一連番号256があとに続いた状態で、それぞれのその後の広告は一連番号0xffffがあるに違いない例外ですばらしい一連番号ものを使用しなければなりません。 このように、モバイルノードはリブートと結果として生じる一連番号の減少を区別できます、値の0xffffに達した後に一連番号のロールオーバーをもたらす減少から。
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 [4], 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メッセージ[4]のための指定されるとしてのエージェント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 [4].
まだエージェントを捜し求めている間、モバイルノードは新しいリンクに移行したという積極的な指示を受けていない場合それがSolicitationsを送るレートを増強してはいけません。 首尾よくエージェントとともに記名するモバイルノードSHOULDがもそれがSolicitationsを送るレートを増強した後に、それであるときに、次に、登録する新しいエージェントを捜し求めるのは始まります。 増強された懇願率を最高率に戻るかもしれませんが、上で説明された方法で制限しなければなりません。 すべての場合では、お勧めの懇願間隔は額面価格です。 モバイルノードはICMP Routerディスカバリー[4]のための指定されるとしてのこれらの額面価格の周りで彼らの懇願時代をランダマイズしなければなりません。
Perkins Standards Track [Page 21] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[21ページ]。
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であると認識します。
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を入れている登録を試みます。 この好みは登録が認識されて、その結果、登録試みの数を最小にするという見込みを最大にします。
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は外国人のエージェントを通して登録します、モバイルノードが共同見つけられたそれ自身のものを取得さえできるかもしれないとき注意、-、アドレス。 この特徴が、サイトが承認の交換を必要とする訪問方針(会計などの)を実施するのを許容することを意図します。
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 22] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[22ページ]。
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は期限が切れていてはいけません。
Perkins Standards Track [Page 23] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[23ページ]。
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 addition, if the home network is using ARP [16], the mobile node MUST follow the procedures described in Section 4.6 with regard to ARP, proxy ARP, and gratuitous ARP.
缶が検出するそれであるときにそれがホームネットワークに返したモバイルノードはそれ自身のホームのエージェントからエージェントAdvertisementを受けます。 そうだとすれば、それ、ホームのエージェント(セクション3)がいるSHOULD deregister。 「反-レジスタ」への試みの前に、モバイルノードSHOULDはホームネットワーク(セクション4.2.1)のために適切に経路指定テーブルを構成します。 さらに、ホームネットワークがARP[16]を使用しているなら、モバイルノードはセクション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のためのアドレス。
Perkins Standards Track [Page 24] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[24ページ]。
Several other (optional) capabilities are available through the registration procedure, which enable a mobile node to:
他のいくつかの(任意)の能力が登録手順で利用可能です(以下のことをモバイルノードは可能にします)。
- maintain multiple simultaneous registrations, so that a copy of
each datagram will be tunneled to each active care-of address
- それぞれのデータグラムのコピーがそれぞれアクティブにトンネルを堀られるように複数の同時の登録証明書を維持してください、注意、-、アドレス
- deregister specific care-of addresses while retaining other
mobility bindings, and
- そして「反-レジスタ」特有である、注意、-、アドレスが保有他の移動性結合をゆったり過ごす。
- discover the address of a home agent if the mobile node is not
configured with this information.
- モバイルノードがこの情報によって構成されないなら、ホームのエージェントのアドレスを発見してください。
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を処理して、次に、ホームのエージェントにそれをリレーします。
Perkins Standards Track [Page 25] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[25ページ]。
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を処理して、次に、モバイルノードにそれをリレーします。
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) [17]. A nonzero UDP checksum SHOULD be included in the header, and MUST be checked by the recipient.
登録メッセージはセクション3.3と3.4使用でユーザー・データグラム・プロトコル(UDP)[17]を定義しました。 非零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 the Mobile-Home Authentication Extension (Section 3.5.2). This Extension immediately follows all non-authentication Extensions, except those foreign agent-specific Extensions which may be added to the message after the mobile node computes the authentication.
それぞれのモバイルノード、外国人のエージェント、およびホームのエージェントはそれらのSPIによって索引をつけられたモバイル実体とIPアドレスのために移動性セキュリティ協会をサポートすることができなければなりません。 モバイルノードの場合では、これはそのホームAddressであるに違いありません。 認証アルゴリズムのサポートのための要件に関してセクション5.1を見てください。モバイルホームAuthentication Extension(セクション3.5.2)と共にモバイルノードとそのホームのエージェントの間の登録メッセージを認証しなければなりません。 このExtensionはすぐにすべての非認証Extensionsに続きます、モバイルノードが認証を計算した後にメッセージに追加されるかもしれないそれらの外国エージェント特有のExtensionsを除いて。
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。
Perkins Standards Track [Page 26] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[26ページ]。
Destination Address Typically that of the foreign agent or the
home agent.
目的地、外国人のエージェントのものかホームのエージェントのAddress Typically。
See Sections 3.6.1.1 and 3.7.2.2 for details.
そして、セクション3.6.1を見てください、.1、3.7 .2 .2 詳細のために。
UDP fields:
UDP分野:
Source Port variable
ソース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|V|rsv| 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|V|rsv| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームのエージェント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-
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が共同場所を見つけた使用である、注意、-、アドレス。
Perkins Standards Track [Page 27] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[27ページ]。
M Minimal encapsulation. If the 'M' bit is set, the
mobile node requests that its home agent use minimal
encapsulation [15] for datagrams tunneled to the mobile
node.
M最小量のカプセル化。 'M'ビットが設定されるなら、ホームのエージェントがデータグラムに最小量のカプセル化[15]を使用するというモバイルノード要求はモバイルノードにトンネルを堀りました。
G GRE encapsulation. If the 'G' bit is set, the
mobile node requests that its home agent use GRE
encapsulation [8] for datagrams tunneled to the mobile
node.
G GREカプセル化。 'G'ビットが設定されるなら、ホームのエージェントがデータグラムにGREカプセル化[8]を使用するというモバイルノード要求はモバイルノードにトンネルを堀りました。
V The mobile node requests that its mobility agent use Van
Jacobson header compression [10] over its link with the
mobile node.
モバイルに対して、ノードは、移動性エージェントがモバイルノードとのリンクの上のヴァンジェーコブソンヘッダー圧縮[10]を使用するよう要求します。
rsv Reserved bits; sent as zero
rsv Reservedビット。 ゼロとして、発信します。
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が扱うモバイルノードのホームAddress。
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がトンネルの端のときに扱うAddress。
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.6.
モバイルノードによって構成された識別のA64ビットの番号はマッチングにRegistration Repliesと、登録メッセージの反射攻撃から守るためのRegistration Requestsを使用しました。 セクション5.4と5.6を見てください。
Extensions
The fixed portion of the Registration Request is followed
by one or more of the Extensions listed in Section 3.5.
The Mobile-Home Authentication 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.
1つかさらにExtensionsについてRegistration Requestの固定部分のあとに続く拡大がセクション3.5に記載しました。 すべてのRegistration RequestsにモバイルホームAuthentication Extensionを含まなければなりません。 そして、セクション3.6.1を見てください、.3、3.7 .2 .2 存在しているとき異なった拡大をRegistration Requestメッセージに置かなければならない相対オーダの情報のために。
Perkins Standards Track [Page 28] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[28ページ]。
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 the Mobile-Home Authentication Extension, 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がモバイルホームAuthentication Extensionでカバーされているのでどれが正しさ(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 29] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[29ページ]。
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.
If Codeがさばく寿命は登録を受け入れて、登録が満期であると考えられる前に残っている秒数にLifetime分野を設定するのを示します。 ゼロの値は、モバイルノードが反登録されたのを示します。 0xffffの値は無限を示します。 Code分野が、登録が否定されたのを示すなら、Lifetime分野の内容を不特定であり、レセプションで無視しなければなりません。
Home Address
The IP address of the mobile node.
IPが扱うモバイルノードのホームAddress。
Home Agent
The IP address of the mobile node's home agent.
IPが演説するモバイルノードのホームのエージェントのホームのエージェント。
Perkins Standards Track [Page 30] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[30ページ]。
Identification
A 64-bit number used for matching Registration Requests
with Registration Replies, and for protecting against
replay attacks of registration messages. The value is
based on the Identification field from the Registration
Request message from the mobile node, and on the style of
replay protection used in the security context between
the mobile node and its home agent (defined by the
mobility security association between them, and SPI
value in the Mobile-Home Authentication Extension). See
Sections 5.4 and 5.6.
識別のA64ビットの番号はマッチングにRegistration Repliesと、登録メッセージの反射攻撃から守るためのRegistration Requestsを使用しました。 値はモバイルノード、およびモバイルノードとそのホームのエージェント(それらと、SPI値の間でモバイルホームAuthentication Extensionで移動性セキュリティ協会によって定義される)の間のセキュリティ文脈で使用される反復操作による保護のスタイルに関するRegistration RequestメッセージからのIdentification分野に基づいています。 セクション5.4と5.6を見てください。
Extensions
The fixed portion of the Registration Reply is followed
by one or more of the Extensions listed in Section 3.5.
The Mobile-Home Authentication 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.
1つかさらにExtensionsについてRegistration Replyの固定部分のあとに続く拡大がセクション3.5に記載しました。 ホームのエージェントによって返されたすべてのRegistration RepliesにモバイルホームAuthentication Extensionを含まなければなりません。 そして、セクション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 requested Van Jacobson compression unavailable
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の要求されたヴァンジェーコブソン入手できない圧縮の手の届かない(ICMP誤りは受信されました)82ホームエージェント80ホームネットワーク(ICMP誤りは受信されました)手の届かない81ホームエージェントのホスト港(ICMP誤りは受信されました)手の届かない88のホームのエージェント手が届きません。(受けられた他のICMP誤り)
Perkins Standards Track [Page 31] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[31ページ]。
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" [20].
Code分野の最新の値は最新の「規定番号」[20]で指定されます。
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 and Length of this Extension.
- このExtensionのTypeとLength。
The default authentication algorithm uses keyed-MD5 [21] in "prefix+suffix" mode to compute a 128-bit "message digest" of the registration message. The default authenticator is a 128-bit value computed as the MD5 checksum over the the following stream of bytes:
デフォルト認証アルゴリズムは、登録メッセージの128ビットの「メッセージダイジェスト」を計算するのに「接頭語+接尾語」モードで合わせられたMD5[21]を使用します。 デフォルト固有識別文字が値がMD5チェックサムとして計算した128ビットである、バイトの以下のストリーム:
- the shared secret defined by the mobility security association
between the nodes and by SPI value specified in the
authentication Extension, followed by
- ノードとSPIによる値が認証Extensionで指定して、続いた移動性セキュリティ協会によって定義された共有秘密キー
- the protected fields from the registration message, in the order
specified above, followed by
- 登録メッセージからの分野が上で指定されたオーダーで続いた保護
- the shared secret again.
- 再び秘密を共有しました。
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 32] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[32ページ]。
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 (keyed-MD5)
and mode ("prefix+suffix") defined above.
認証Extensionsのどれかの中のSecurity Parameter Index(SPI)はAuthenticator値を計算するのに使用されて、受信機で使用する、その値をチェックしなければならないセキュリティ文脈を定義します。 特に、SPIはAuthenticatorを計算する際に使用される認証アルゴリズム、モード(セクション5.1)、および秘密(共有されたキー、または適切な公衆/秘密鍵組)を選択します。 モバイルIPプロトコルの異なった実装の間の相互運用性を確実にするために、実装はそれが実装するどんな認証アルゴリズムとモードにもどんなSPI値も関連づけることができなければなりません。 さらに、モバイルIPのすべての実装が上で定義されたデフォルト認証アルゴリズム(合わせられたMD5)とモード(「接頭語+接尾語」)を実装しなければなりません。
3.5.2. Mobile-Home Authentication Extension
3.5.2. 移動住宅認証拡大
Exactly one Mobile-Home Authentication Extension MUST be present in all Registration Requests and Registration Replies, and 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モバイルホームAuthentication ExtensionがすべてのRegistration RequestsとRegistration Repliesに存在していなければならなくて、リモートの非制御の伝播からの結果がインターネットで向け直す問題[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 33] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[33ページ]。
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 its home address, a netmask, and a mobility security association for each home agent. In addition, a mobile node MAY be configured with the IP address of one or more of its home agents; otherwise, the mobile node MAY discover a home agent using the procedures described in Section 3.6.1.2.
それぞれのホームのエージェントのためにホームアドレス、ネットマスク、および移動性セキュリティ関係でモバイルノードを構成しなければなりません。 さらに、モバイルノードはホームのエージェントのより多くのひとりのIPアドレスによって構成されるかもしれません。 さもなければ、セクション3.6.1で.2に説明された手順を用いて、モバイルノードはホームのエージェントを発見するかもしれません。
Perkins Standards Track [Page 34] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[34ページ]。
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秒あたりの一度よりさらにしばしば登録するのを試みてはいけません。
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は登録メッセージの分野がいくつかの典型的な登録シナリオでどうセットアップされるだろうかに関するいくつかの例を示しています。
Perkins Standards Track [Page 35] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[35ページ]。
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ソースアドレスがそうであるに違いない、注意、-、アドレス
- 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. In addition, when transmitting
this Registration Request message, the mobile node MUST use a
link-layer destination address copied from the link-layer source
address of the Agent Advertisement message in which it learned
this foreign agent's IP address.
- 外国人のエージェントとともに記名するとき、対応するエージェントAdvertisementのIPソースアドレスから同じくらい学識があるエージェントのアドレスを使用しなければなりません。 このRegistration Requestメッセージを送るとき、さらに、モバイルノードはそれがこの外国人のエージェントの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アドレスを知っているとき、このアドレスに送付先アドレスを設定しなければなりません。
Perkins Standards Track [Page 36] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[36ページ]。
- 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 [19].
- 受信者IPアドレスがマルチキャストが説明されるように扱う「すべての移動性エージェント」上に設定されるなら、IP TTL分野を1に設定しなければなりません。 さもなければ、一般的なIP習慣[19]に従って、適当な値は選ばれるべきです。
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'ビットを設定してはいけません。
A mobile node MAY set the 'B' bit to request its home agent to forward to it, a copy of broadcast datagrams received by its home agent from the home network. The method used by the home agent to forward broadcast datagrams depends on the type of care-of address registered by the mobile node, as determined by the 'D' bit in the mobile node's Registration Request:
モバイルノードは、'B'ビットにそれに送るホームのエージェント、ホームのエージェントによってホームネットワークから受け取られたブロードキャスト・データグラムのコピーを要求するように設定するかもしれません。 メソッドがデータグラムがタイプに頼る放送を進めるのにホームのエージェントを使用した、注意、-、アドレスはモバイルノードによって登録されました、モバイルノードのRegistration Requestで'D'ビットで決定するように:
Perkins Standards Track [Page 37] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[37ページ]。
- If the 'D' bit is set, then the mobile node has indicated that it
will decapsulate any datagrams tunneled to this care-of address
itself (the mobile node is using a co-located care-of address).
In this case, to forward such a received broadcast datagram to
the mobile node, the home agent MUST tunnel it to this care-of
address. The mobile node de-tunnels the received datagram in the
same way as any other datagram tunneled directly to it.
- 'D'ビットが設定されるならモバイルノードが、これにトンネルを堀られたどんなデータグラムもdecapsulateするのを示した、注意、-、それ自体を扱ってください、(モバイルノードがaが共同場所を見つけた使用である、注意、-、アドレス) この場合、モバイルノードへの前進のそのようなa容認されたブロードキャスト・データグラムへのホームのエージェントがそれにトンネルを堀らなければならない、これ、注意、-、アドレス いかなる他のデータグラムも直接それにトンネルを堀ったので、同様に、モバイルノードは反-容認されたデータグラムにトンネルを堀ります。
- If the 'D' bit is NOT set, then the mobile node has indicated
that it is using a foreign agent care-of address, and that the
foreign agent will thus decapsulate arriving datagrams before
forwarding them to the mobile node. In this case, to forward
such a received broadcast datagram to the mobile node, the home
agent MUST first encapsulate the broadcast datagram in a unicast
datagram addressed to the mobile node's home address, and then
MUST tunnel this resulting datagram to the mobile node's care-of
address.
- 'D'ビットが設定されないならモバイルノードが、外国人のエージェントを使用しているのを示した、注意、-、アドレス、外国人のエージェントはその結果、モバイルノードにそれらを送る前のdecapsulate到着データグラムがそうするでしょう。 この場合モバイルノードへの容認されたブロードキャスト・データグラム、前進のそのようなものへのホームのエージェントが最初に、モバイルノードのホームアドレスに扱われたユニキャストデータグラムでブロードキャスト・データグラムをカプセル化しなければならなくて、その時がこの結果として起こるデータグラムにトンネルを堀らなければならない、モバイルノードのもの、注意、-、アドレス
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.
外国人のエージェントによってdecapsulatedされると、内側のデータグラムは、その結果カプセル化されたブロードキャスト・データグラムの意図している目的地を外国人のエージェントに特定して、モバイルノードに扱われたユニキャストIPデータグラムであり、いずれもデータグラム到着にトンネルを堀ったのと同様に、モバイルノードのためにモバイルノードに提供されるでしょう。 外国人のエージェントは、カプセル化されたブロードキャスト・データグラムをdecapsulateしてはいけなくて、モバイルノードにそれを伝えるのに企業内情報通信網放送を使用してはいけません。 モバイルノードは、その結果、カプセル化されたブロードキャスト・データグラム自体をdecapsulateしなければならなくて、その結果、データグラムをdecapsulatingすることができないなら、この場合'B'ビットをRegistration Requestにはめ込んではいけません。
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.
モバイルノードがモバイルノードがそれ自身のデータグラムをdecapsulatingしている場合にだけ'M'ビット、そして/または、'G'ビットを設定することによって選択方式のカプセル化を要求するかもしれない、(モバイルノードがaが共同場所を見つけた使用である、注意、-、アドレス、)、外国人のエージェントが対応するビットをMobilityにはめ込むことによってこれらのフォームのカプセル化のサポートを示したなら、エージェントAdvertisementのエージェントAdvertisement Extensionはモバイルノードのそばで受信しました。 さもなければ、モバイルノードはこれらのビットを設定してはいけません。
The Lifetime field is chosen as follows:
Lifetime分野は以下の通り選ばれています:
- If the mobile node is registering with a foreign agent, the
Lifetime SHOULD NOT exceed the value in the Registration Lifetime
field of the Agent Advertisement message received from the
foreign agent. When the method by which the care-of address is
learned does not include a Lifetime, the default ICMP Router
Advertisement Lifetime (1800 seconds) MAY be used.
- モバイルノードが外国人のエージェントとともに記名しているなら、Lifetime SHOULDは外国人のエージェントから受け取られたエージェントAdvertisementメッセージのRegistration Lifetime分野で値を超えていません。 メソッドである、どれ、注意、-、アドレス、学習されて、インクルードa Lifetime、デフォルトICMP Router Advertisement Lifetime(1800秒)が使用されませんようにか。
Perkins Standards Track [Page 38] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[38ページ]。
- The mobile node MAY ask a home agent to delete a particular
mobility binding, by sending a Registration Request with the
care-of address for this binding, with the Lifetime field set to
zero (Section 3.8.2).
- モバイルノードが、ホームのエージェントがRegistration Requestを送って、付く特定の移動性を削除するように頼むかもしれない、注意、-、この結合のためのアドレス、Lifetimeと共に、分野は、(セクション3.8.2)のゼロを合わせるためにセットしました。
- Similarly, a Lifetime of zero is used when the mobile node
deregisters all care-of addresses, such as upon returning home.
- モバイルノード「反-レジスタ」であるときに、同様に、ゼロのLifetimeが使用されている、すべて、注意、-、帰りなどのアドレスは家へ帰ります。
The Home Agent field MUST be set to the address of the mobile node's home agent, if the mobile node knows this address. Otherwise, the mobile node MAY use dynamic home agent address resolution to learn the address of its home agent. In this case, the mobile node MUST set the Home Agent field to the subnet-directed broadcast address of the mobile node's home network. Each home agent receiving such a Registration Request with a broadcast destination address MUST reject the mobile node's registration and SHOULD return a rejection Registration Reply indicating its unicast IP address for use by the mobile node in a future registration attempt.
モバイルノードのホームのエージェントのアドレスにホームエージェント分野を設定しなければなりません、モバイルノードがこのアドレスを知っているなら。 さもなければ、モバイルノードはホームのエージェントのアドレスを学ぶダイナミックなホームエージェントアドレス解決を使用するかもしれません。 この場合、モバイルノードはモバイルノードのホームネットワークのサブネットで指示された放送演説にホームエージェント分野を設定しなければなりません。 ブロードキャストあて先アドレスでそのようなRegistration Requestを受け取るそれぞれのホームのエージェントはモバイルノードの登録を拒絶しなければなりません、そして、SHOULDはモバイルノードで将来の登録試みで使用のためのユニキャストIPアドレスを拒絶Registration Reply表示に返します。
The Care-of Address field MUST be set to the value of the particular care-of address that the mobile node wishes to (de)register. In the special case in which a mobile node wishes to deregister all care-of addresses, it MUST set this field to its home address.
Care、-、特定の値にAddress分野を設定しなければならない、注意、-、それが(de)への願望が登録するモバイルノードであると扱ってください。 特別な場合では、すべてがどのaモバイルノードで「反-レジスタ」に願われているか、注意、-、アドレス、それはこの分野をホームアドレスに設定しなければなりません。
The mobile node chooses the Identification field in accordance with the style of replay protection it uses with its home agent. This is part of the mobility security association the mobile node shares with its home agent. See Section 5.6 for the method by which the mobile node computes the Identification field.
それがホームのエージェントと共に使用する反復操作による保護のスタイルに従って、モバイルノードはIdentification分野を選びます。 これはモバイルノードがホームのエージェントと共有する移動性セキュリティ協会の一部です。 モバイルノードがIdentification分野を計算するメソッドに関してセクション5.6を見てください。
3.6.1.3. Extensions
3.6.1.3. 拡大
This section describes the ordering of any mandatory and any optional Extensions that a mobile node appends to a Registration Request. This following ordering MUST be followed:
このセクションはモバイルノードがRegistration Requestに追加するどんな義務的なExtensionsとどんな任意のExtensionsの注文についても説明します。 この次の注文に続かなければなりません:
a) The IP header, followed by the UDP header, followed by the
fixed-length portion of the Registration Request, followed by
a) 続かれて、UDPヘッダーによってついて来られたIPヘッダーはRegistration Requestの固定長一部のそばで続きました。
b) If present, any non-authentication Extensions expected to be
used by the home agent (which may or may not also be used by
the foreign agent), followed by
b) 存在しているなら、どんな非認証Extensionsも、ホームのエージェント(また、外国人のエージェントが使用されるかもしれない)によって使用されると予想しました、続かれて
c) The Mobile-Home Authentication Extension, followed by
c) モバイルホームAuthentication Extension続かれて、
d) If present, any non-authentication Extensions used only by
the foreign agent, followed by
d) 存在しているなら、続かれて、どんな非認証Extensionsも外国だけでエージェントを使用しました。
Perkins Standards Track [Page 39] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[39ページ]。
e) The Mobile-Foreign Authentication Extension, if present.
e) モバイルに外国のAuthentication Extension存在しているなら。
Note that items (a) and (c) MUST appear in every Registration Request sent by the mobile node. Items (b), (d), and (e) are optional. However, item (e) MUST be included when the mobile node and the foreign agent share a mobility security association.
商品(a)と(c)がモバイルノードによって送られたあらゆるRegistration Requestに現れなければならないことに注意してください。 項目(b)、(d)、および(e)は任意です。 しかしながら、モバイルノードと外国人のエージェントが移動性セキュリティ協会を共有するとき、項目(e)を含まなければなりません。
3.6.2. Receiving Registration Replies
3.6.2. 登録回答を受け取ります。
Registration Replies will be received by the mobile node in response to its Registration Requests. Registration Replies generally fall into three categories:
モバイルノードはRegistration Requestsに対応して登録Repliesを受け取るでしょう。 一般に、登録Repliesは3つのカテゴリになります:
- the registration was accepted,
- the registration was denied by the foreign agent, or
- the registration was denied by the home agent.
- または、登録を受け入れました--登録が外国人のエージェントによって否定された、--登録はホームのエージェントによって否定されました。
The remainder of this section describes the Registration Reply handling by a mobile node in each of these three categories.
このセクションの残りはモバイルノードでそれぞれのこれらの3つのカテゴリでRegistration Reply取り扱いについて説明します。
3.6.2.1. Validity Checks
3.6.2.1. バリディティチェック
Registration Replies with an invalid, non-zero UDP checksum MUST be silently discarded.
無効の非ゼロUDPチェックサムで静かに登録Repliesを捨てなければなりません。
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.
さらに、返答しているエージェントに送られた最新のRegistration RequestのIdentification分野の下位の32ビットにRegistration ReplyのIdentification分野の下位の32ビットをたとえなければなりません。 彼らが合っていないなら、静かにReplyを捨てなければなりません。
Also, the authentication in the Registration Reply MUST be checked. That is, the mobile node MUST check for the presence of a valid authentication Extension, acting in accordance with the Code field in the Reply. The rules are as follows:
また、Registration Replyでの認証をチェックしなければなりません。 すなわち、モバイルノードは有効な認証Extensionの存在がないかどうかチェックしなければなりません、ReplyのCode分野に従って行動して。 規則は以下の通りです:
a) If the mobile node and the foreign agent share a
mobility security association, exactly one Mobile-Foreign
Authentication Extension MUST be present in the Registration
Reply, and the mobile node MUST check the Authenticator
value in the Extension. If no Mobile-Foreign Authentication
Extension is found, or if more than one Mobile-Foreign
Authentication Extension is found, or if the Authenticator is
invalid, the mobile node MUST silently discard the Reply and
SHOULD log the event as a security exception.
a) モバイルノードと外国人のエージェントが移動性セキュリティ協会を共有するなら、ちょうど1モバイルに外国のAuthentication ExtensionがRegistration Replyに存在していなければなりません、そして、モバイルノードはExtensionでAuthenticator値をチェックしなければなりません。 どんなモバイルに外国のAuthentication Extensionも見つけられないか、1モバイルに外国のAuthentication Extensionが見つけられる、またはAuthenticatorが無効であるなら、モバイルノードは静かにReplyを捨てなければなりません、そして、SHOULDはセキュリティ例外としてイベントを登録します。
Perkins Standards Track [Page 40] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[40ページ]。
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 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) Code分野が、サービスがホームのエージェントによって否定されるのを示すか、またはCode分野が、登録がホームのエージェントによって受け入れられたのを示すなら、ちょうど1モバイルホームAuthentication ExtensionがRegistration Replyに存在していなければなりません、そして、モバイルノードはExtensionでAuthenticator値をチェックしなければなりません。 モバイルホームAuthentication Extensionが全く見つけられないか、1モバイルホームAuthentication Extensionが見つけられる、またはAuthenticatorが無効であるなら、モバイルノードは静かにReplyを捨てなければなりません、そして、SHOULDはセキュリティ例外としてイベントを登録します。
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.
Code分野が外国人のエージェントかホームのエージェントで認証失敗を示すなら、また、Registration Replyのどんな固有識別文字も間違っているのは、かなり可能です。 例えば、モバイルノードとホームのエージェントの間の共有秘密キーが誤って構成されるなら、これは起こることができるでしょうに。 モバイルノードSHOULDはセキュリティ例外のような誤りを登録します。
3.6.2.2. Registration Request Accepted
3.6.2.2. 登録要求は受け入れました。
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).
Code分野が、要求が受け入れられたのを示すなら、モバイルノードSHOULDは適切に現在の接着点(セクション4.2.1)に経路指定テーブルを構成します。
If the mobile node is returning to its home network and that network is one which implements ARP, the mobile node MUST follow the procedures described in Section 4.6 with regard to ARP, proxy ARP, and gratuitous ARP.
モバイルノードがホームネットワークに戻っていて、そのネットワークがARPを実装するものであるなら、モバイルノードはセクション4.6でARP、プロキシARP、および無料の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 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
モバイルノードは外国ネットワークに登録して、それは登録のLifetimeの満了の前のSHOULD再レジスタです。 それぞれの未定のRegistration Requestのためにセクション3.6で説明されるように、モバイルノードはこの未定の登録の残っている生涯を維持しなければなりません、Registration RequestからのオリジナルのLifetimeと同様に。 モバイルノードが有効なRegistration Replyを受けるとき、量に従って、ホームのエージェントが元々要求されたLifetimeを減少させたモバイルノードは登録の残っている生涯の視点を減少させなければなりません。 この手順はRegistration Requestを送ったとき与えられたLifetimeのためにタイマを始動するモバイルノードに同等です、Registration Replyが受け取られているまで、与えられたLifetimeがモバイルノードに知られていませんが。 ホームのエージェントが登録Lifetime(また、与えられたLifetimeに基づいている)を調節し始める前に確かにRegistration Requestを送るので、この手順は、ホームのエージェントが登録を吐き出して、削除する前にモバイルノードが再登録するのを確実にします、オリジナルのRegistrationには、ことによると非取るにたらないトランスミッション遅れにもかかわらず
Perkins Standards Track [Page 41] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[41ページ]。
Request and Reply that started the timing of the Lifetime at the mobile node and its home agent.
モバイルノードとそのホームのエージェントでLifetimeのタイミングを始めた要求とReply。
3.6.2.3. Registration Request Denied
3.6.2.3. 否定された登録要求
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分野が、サービスが否定されているのを示すなら、モバイルノードSHOULDは誤りを登録します。 ある場合には、モバイルノードは誤りを「修理できるかもしれません」。 これらは:
Code 69: (Denied by foreign agent, Lifetime too long)
コード69: (あまりに長い間、外国人のエージェント、Lifetimeによって否定されます)
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.
この場合、Registration ReplyのLifetime分野はその外国人のエージェントがどんなRegistration Requestでも受け入れても構わないと思っている最大のLifetime値を含むでしょう。 モバイルノードは、この同じエージェントとともに記名するのを試みるかもしれません、Replyで指定されたより値以下であるに違いないRegistration RequestでLifetimeを使用して。
Code 133: (Denied by home agent, Identification mismatch)
コード133: (ホームのエージェント、Identificationミスマッチで、否定されます)
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.6). 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.
この場合、Registration ReplyのIdentification分野はモバイルノードが事実上、反復操作による保護のスタイルに基づくホームのエージェント(セクション5.6)に連動できる値を含むでしょう。 モバイルノードはそれがRegistration Replyの情報に基づくIdentification分野を計算するのに使用するパラメタを調整しなければなりません、どんな未来にもRegistration Requestsを発行する前に。
Code 136: (Denied by home agent, Unknown home agent address)
コード136: (ホームのエージェント、Unknownホームエージェントアドレスで、否定されます)
This code is returned by a home agent when the mobile node is
performing dynamic home agent address resolution as described
in Sections 3.6.1.1 and 3.6.1.2. In this case, the Home Agent
field within the Reply will contain the unicast IP address of
the home agent returning the Reply. The mobile node MAY then
attempt to register with this home agent in future Registration
Requests. In addition, the mobile node SHOULD adjust the
parameters it uses to compute the Identification field based
upon the corresponding field in the Registration Reply, before
issuing any future Registration Requests.
このコードはモバイルノードがセクション3.6.1で.1について説明するのでダイナミックなホームエージェントアドレス解決を実行することであって、3.6が.1であるホームのエージェントによって.2に返されます。 この場合、Replyの中のホームエージェント分野はReplyを返すホームのエージェントのユニキャストIPアドレスを含むでしょう。 そして、モバイルノードは、将来のRegistration Requestsにこのホームのエージェントとともに記名するのを試みるかもしれません。 さらに、モバイルノードSHOULDはそれがRegistration Replyの対応する分野に基づくIdentification分野を計算するのに使用するパラメタを調整します、どんな未来にもRegistration Requestsを発行する前に。
3.6.3. Registration Retransmission
3.6.3. 登録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;
適当な時間内にRegistration Replyを全く受け取っていないとき、別のRegistration Requestを伝えるかもしれません。 タイムスタンプが使用されているとき、新規登録Identificationは各「再-トランスミッション」に選ばれています。 したがって、それは新規登録にみなします。 一回だけが使用されているとき、答えのないRequestは変わりがない状態で再送されます。
Perkins Standards Track [Page 42] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[42ページ]。
thus the retransmission does not count as a new registration (Section 5.6). 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.
したがって、「再-トランスミッション」は新規登録(セクション5.6)にみなしません。 このように、「再-トランスミッション」は、ホームのエージェントがモバイルノードでオリジナルのRegistration Request(Registration Replyよりむしろ)がネットワークによってなくされた場合で別の一回だけを発行することによって再連動するのを必要としないでしょう。
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.
最大の新しいRegistration Requestが送られたSHOULDになるまでの時間、Registration Requestの要求されたよりLifetimeはそうですか? 最小値SHOULD、メッセージのサイズを説明できるくらい大きくいてください、ホームのエージェントへの伝送のため、少なくとも応じるメッセージを処理する考慮する追加100人のミリセカンドと同じくらいの前の時間の周遊旅行の2倍。 時間が、モバイルノードの現在の接着点のリンク速度でメッセージを送るのを必要としたのとホームのエージェントへの伝送のため周遊旅行時間は少なくとも同じくらい大きいでしょう。 いくつかの回路が別の合計の衛星遅れの円周200ミリセカンドの旅行時間にホームのエージェントに加えます。 Registration Requestsの間の最小の時間は1秒未満であるはずがありません。 それぞれの連続した「再-トランスミッション」タイムアウト時間SHOULDは少なくとも同じくらい同じくらい長く前の期間、すなわち、2倍そうです。最大より上で指定されるとして少ないです。
3.7. Foreign Agent Considerations
3.7. 外国エージェント問題
The foreign agent plays a mostly passive role in Mobile IP registration. It relays Registration Requests between mobile nodes and home agents, and, when it provides the care-of address, decapsulates datagrams for delivery to the mobile node. It SHOULD also send periodic Agent Advertisement messages to advertise its presence as described in Section 2.3, if not detectable by link-layer means.
外国人のエージェントはモバイルIP登録におけるほとんど受け身の役割を果たします。 そして、提供するときモバイルノードとホームのエージェントの間のRegistration Requestsをリレーする、注意、-、アドレス、モバイルノードへの配送のためのdecapsulatesデータグラム。 それ、また、SHOULDはリンクレイヤ手段でセクション2.3で説明される、検出可能であるとして存在の広告を出す周期的なエージェントAdvertisementメッセージを送ります。
A foreign agent MUST NOT transmit a Registration Request except when relaying a Registration Request received from a mobile node, to the mobile node's home agent. A foreign agent MUST NOT transmit a Registration Reply except when relaying a Registration Reply received from a mobile node's home agent, or when replying to a Registration Request received from a mobile node in the case in which the foreign agent is denying service to the mobile node. In particular, a foreign agent MUST NOT generate a Registration Request or Reply because a mobile node's registration Lifetime has expired. A foreign agent also MUST NOT originate a Registration Request message that asks for deregistration of a mobile node; however, it MUST relay valid (de)Registration Requests originated by a mobile node.
Registration Requestをリレーするのがモバイルノードから受信された時を除いて、外国人のエージェントはRegistration Requestを伝えてはいけません、モバイルノードのホームのエージェントに。 Registration Replyをリレーするのがいつモバイルノードのホームのエージェントから受信されたか、そして、またはRegistration Requestに答えるのがいつ外国人のエージェントがモバイルノードに対するサービスを否定している場合のモバイルノードから受信されたか以外に、外国人のエージェントはRegistration Replyを伝えてはいけません。 モバイルノードの登録Lifetimeが期限が切れたので、特に、外国人のエージェントはRegistration RequestかReplyを生成してはいけません。 外国人のエージェントもモバイルノードの反登録を求めるRegistration Requestメッセージを溯源してはいけません。 しかしながら、それはモバイルノードによって溯源された有効な(de)登録Requestsをリレーしなければなりません。
Perkins Standards Track [Page 43] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[43ページ]。
3.7.1. Configuration and Registration Tables
3.7.1. 構成とレジスタ・テーブル
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:
aでそれぞれの外国人のエージェントを構成しなければならない、注意、-、アドレス。 さらに、それぞれの未定の、または、現在の登録のために、外国人のエージェントはモバイルノードのRegistration Requestから得られた以下の情報を含む訪問者リストエントリーを維持しなければなりません:
- the link-layer source address of the mobile node
- the IP Source Address (the mobile node's Home Address)
- the IP Destination Address (as specified in 3.6.2.3)
- the UDP Source Port
- the Home Agent address
- the Identification field
- the requested registration Lifetime, and
- the remaining Lifetime of the pending or current registration.
- そして、モバイルノードのリンクレイヤソースアドレス--IP Source Address(モバイルノードのホームAddress)--IP Destination Address、(指定される、3.6、.2、.3、)、--UDP Source Port--ホームエージェントアドレス--Identification分野--要求された登録Lifetime、--未定の、または、現在の登録の残っているLifetime。
As with any node on the Internet, a foreign agent MAY also share mobility security associations with any other nodes. When relaying a Registration Request from a mobile node to its home agent, if the foreign agent shares a mobility security association with the home agent, it MUST add a Foreign-Home Authentication Extension to the Request and MUST check the required Foreign-Home Authentication Extension in the Registration Reply from the home agent (Sections 3.3 and 3.4). Similarly, when receiving a Registration Request from a mobile node, if the foreign agent shares a mobility security association with the mobile node, it MUST check the required Mobile- Foreign Authentication Extension in the Request and MUST add a Mobile-Foreign Authentication Extension to the Registration Reply to the mobile node.
また、どれかノードがインターネットにある場合、外国人のエージェントはいかなる他のノードとの移動性セキュリティ協会も共有するかもしれません。 外国人のエージェントがホームのエージェントとの移動性セキュリティ仲間を共有するならモバイルノードからホームのエージェントまでRegistration Requestをリレーするとき、それは、Foreign-ホームAuthentication ExtensionをRequestに加えなければならなくて、Registration Replyでホームのエージェント(セクション3.3と3.4)から必要なForeign-ホームAuthentication Extensionをチェックしなければなりません。 同様に、外国人のエージェントがモバイルノードとの移動性セキュリティ協会を共有するならモバイルノードからRegistration Requestを受けるとき、それは、Requestで必要なモバイル外国Authentication Extensionをチェックしなければならなくて、モバイルノードへのRegistration Replyにモバイルに外国のAuthentication Extensionを加えなければなりません。
3.7.2. Receiving Registration Requests
3.7.2. 登録要求を受け取ります。
If the foreign agent accepts a Registration Request from a mobile node, it 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.
外国人のエージェントがモバイルノードからRegistration Requestを受け入れるなら、それは示されたホームのエージェントにRequestをリレーしなければなりません。 さもなければ、外国人のエージェントがRequestを否定するなら、それは外国人のエージェントがそうであるケース中以外のCodeが同じモバイルノードへのそのような否定の1秒あたり1つ以上を出すのが必要であるという適切な否定と共にモバイルノードに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
外国人のエージェントが受信するなら、外国人のエージェントが成功を示すCodeのホームのエージェントから有効なRegistration Replyを受け取るまで、削除されるか変更されていて、訪問者リストのモバイルノードからのRegistration Request、既存の訪問者はモバイルノードSHOULD NOTのためにエントリーを記載します。 外国人のエージェントは未定の状態で新しさを記録しなければなりません。
Perkins Standards Track [Page 44] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[44ページ]。
Request separately from the existing visitor list entry for the mobile node. If the Registration Request requests deregistration, the existing visitor list entry for the mobile node SHOULD NOT be deleted until the foreign agent has received a successful Registration Reply. If the Registration Reply indicates that the Request (for registration or deregistration) was denied by the home agent, the existing visitor list entry for the mobile node MUST NOT be modified as a result of receiving the Registration Reply.
別々にモバイルノードのための既存の訪問者リストエントリーから頼んでください。 Registration Requestが、外国人のエージェントがうまくいっているRegistration Replyを受け取るまで反登録、モバイルノードSHOULD NOTのための既存の訪問者リストエントリーが削除されるよう要求するなら。 Registration Replyが、Request(登録か反登録のための)がホームのエージェントによって否定されたのを示すなら、Registration Replyを受けることの結果、モバイルノードのための既存の訪問者リストエントリーを変更してはいけません。
3.7.2.1. Validity Checks
3.7.2.1. バリディティチェック
Registration Requests with an invalid, non-zero UDP checksum MUST be silently discarded.
無効の非ゼロUDPチェックサムで静かに登録Requestsを捨てなければなりません。
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.
また、Registration Requestでの認証をチェックしなければなりません。 外国人のエージェントとモバイルノードが移動性セキュリティ協会を共有するなら、ちょうど1モバイルに外国のAuthentication ExtensionがRegistration Requestに存在していなければなりません、そして、外国人のエージェントはExtensionでAuthenticator値をチェックしなければなりません。 どんなモバイルに外国のAuthentication Extensionも見つけられないか、1モバイルに外国のAuthentication Extensionが見つけられる、またはAuthenticatorが無効であるなら、外国人のエージェントは静かにRequestを捨てなければなりません、そして、SHOULDはセキュリティ例外としてイベントを登録します。 外国人のエージェント、また、SHOULDはCode67とのモバイルノードにRegistration Replyを送ります。
3.7.2.2. Forwarding a Valid Request to the Home Agent
3.7.2.2. 有効な要求をホームのエージェントに転送します。
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. Otherwise, an authentication failure is very likely to occur at the home agent. In addition, the foreign agent proceeds as follows:
外国人のエージェントがモバイルノードのRegistration Requestを受け入れるなら、それはRegistration Requestのホームエージェント分野の指定されるとしてのモバイルノードのホームのエージェントにRequestをリレーしなければなりません。 外国人のエージェントは突き抜けて含んでいることへのRegistration Requestの固定部分でモバイルホームAuthentication Extensionを始める分野のいずれも変更してはいけません。 さもなければ、認証失敗はホームのエージェントに非常に起こりそうです。 さらに、外国人のエージェントは以下の通り続きます:
- 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.
- そして、モバイルホームAuthentication Extensionに続いて、それは、どんなExtensionsも処理して、取り外さなければなりません--それ自身の関連性の非認証Extensionsのどれかをホームのエージェントに追加するかもしれません、適切であるなら--Foreign-ホームAuthentication Extensionを追加しなければなりません、外国人のエージェントがホームのエージェントとの移動性セキュリティ仲間を共有するなら。
Perkins Standards Track [Page 45] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[45ページ]。
Specific fields within the IP header and the UDP header of the relayed Registration Request MUST be set as follows:
以下の通りリレーされたRegistration RequestのIPヘッダーとUDPヘッダーの中の特定の分野を設定しなければなりません:
IP Source Address
The foreign agent's address on the interface from which
the message will be sent.
メッセージが送られるインタフェースに関する外国人のエージェントのもののIP Source Addressのアドレス。
IP Destination Address
Copied from the Home Agent field within the Registration
Request.
Registration Requestの中のホームエージェント分野からのIP Destination Address Copied。
UDP Source Port
<variable>
UDPソースポートの<の可変>。
UDP Destination Port
434
UDP仕向港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.
有効なRegistration Requestをホームのエージェントに送った後に、外国人のエージェントは、Registration RequestでLifetimeに基づく未定の登録の残っている生涯を調節し始めなければなりません。 有効なRegistration Replyを受ける前にこの寿命が期限が切れるなら、外国人のエージェントはこの未定の登録のための訪問者リストエントリーを削除しなければなりません。
3.7.2.3. Denying Invalid Requests
3.7.2.3. 無効の要求を否定します。
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.
外国人のエージェントはどんな理由でもモバイルノードのRegistration Requestを否定します、それ。SHOULDは適当な否定Codeと共にモバイルノードにRegistration Replyを送ります。 このような場合には、Registration Replyの中のホームAddress、ホームのエージェント、およびIdentification分野は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.
Reserved分野が非零であるなら、外国人のエージェントは、RequestとSHOULDがステータスコード70があるRegistration Replyをモバイルノードに返すことを否定しなければなりません。 要求されたLifetimeが長過ぎるのでRequestが否定されているなら、外国人のエージェントは、それがどんなRegistration Requestでも受け入れても構わないと思っている最大のLifetime値へのReplyにLifetimeをはめ込んで、Code分野を69に設定します。 そうでなければ、Lifetime SHOULD、RequestのLifetime分野から、コピーされてください。
Specific fields within the IP header and the UDP header of the Registration Reply MUST be set as follows:
以下の通りIPヘッダーとRegistration ReplyのUDPヘッダーの中の特定の分野を設定しなければなりません:
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
Registration RequestのIP Destination AddressからのIP Source Address Copied、「すべてのエージェントマルチキャスト」アドレスは使用されました。 この場合、外国人のエージェントのアドレス(メッセージが送られるインタフェースの)はそうであるに違いありません。
Perkins Standards Track [Page 46] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[46ページ]。
used.
使用にされる。
IP Destination Address
Copied from the IP Source Address of the Registration
Request.
IP送付先アドレスは登録要求のIPソースアドレスからコピーされました。
UDP Source Port
434
UDPソースポート434
UDP Destination Port
Copied from the UDP Source Port of the Registration
Request.
UDP仕向港は登録要求のUDPソースポートからコピーされました。
3.7.3. Receiving Registration Replies
3.7.3. 登録回答を受け取ります。
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を造ることに関する詳細のために。
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 pending Request is found, 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のための訪問者リストを捜さなければなりません。 どんな未定の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
また、Registration Replyでの認証をチェックしなければなりません。 外国人のエージェントとホームのエージェントが移動性セキュリティ協会を共有するなら、ちょうど1Foreign-ホームAuthentication ExtensionがRegistration Replyに存在していなければなりません、そして、外国人のエージェントはExtensionでAuthenticator値をチェックしなければなりません。 Foreign-ホームAuthentication Extensionが全く見つけられないか、1Foreign-ホームAuthentication Extensionが見つけられる、またはAuthenticatorが無効であるなら、外国人のエージェントは静かにReplyとSHOULDを捨てなければなりません。
Perkins Standards Track [Page 47] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[47ページ]。
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.
セキュリティ例外としてイベントを登録してください。 外国人のエージェントもモバイルノードの登録を拒絶しなければなりません、そして、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 mobile node has accepted the registration and the Lifetime field is nonzero, the foreign agent MUST set the Lifetime in the visitor list entry to the value specified in the Lifetime field of the Registration Reply. If, instead, the Code indicates that the Lifetime field is zero, the foreign agent MUST delete its visitor list entry for the mobile node. Finally, if the Code indicates that the registration was denied by the home agent, the foreign agent MUST delete its pending registration list entry, but not its visitor list entry, for the mobile node.
どれがセクション3.8のバリディティチェックを満たすか。Registration Reply、.2 .1 モバイルノードにリレーされます。 また、モバイルノードがRegistration Requestの結果を反映するように、外国人のエージェントは訪問者リストエントリーをアップデートしなければなりません、ReplyのCode分野によって示されるように。 Codeが、モバイルノードが登録を受け入れたのを示して、Lifetime分野が非零であるなら、外国人のエージェントはRegistration ReplyのLifetime分野で指定された値への訪問者リストエントリーにLifetimeをはめ込まなければなりません。 Codeが、Lifetime分野がゼロであることを代わりに示すなら、外国人のエージェントはモバイルノードのための訪問者リストエントリーを削除しなければなりません。 最終的に、Codeが、登録がホームのエージェントによって否定されたのを示すなら、外国人のエージェントは訪問者リストエントリーではなく、その未定の有権者名簿エントリーを削除しなければなりません、モバイルノードのために。
The foreign agent MUST NOT modify any of the fields beginning with the fixed portion of the Registration Reply up through and including the Mobile-Home Authentication Extension. Otherwise, an authentication failure is very likely to occur at the mobile node. In addition, the foreign agent SHOULD perform the following additional procedures:
外国人のエージェントは突き抜けて含んでいることへのRegistration Replyの固定部分でモバイルホームAuthentication Extensionを始める分野のいずれも変更してはいけません。 さもなければ、認証失敗はモバイルノードに非常に起こりそうです。 さらに、外国人のエージェント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をモバイルノードに送った後に、外国人のエージェントは以下のこの登録のための訪問者リストエントリーをアップデートしなければなりません。 Registration Replyが、登録がホームのエージェントによって受け入れられたのを示すなら、外国人のエージェントはRegistration Replyで与えられたLifetimeに登録の生涯のタイマをリセットします。 モバイルノードのそれであるときに、前方に始める.2、外国人のエージェントがこの生涯を考えるセクション3.6.2における説明されるとしての登録生涯のタイミング
Perkins Standards Track [Page 48] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[48ページ]。
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.
外国人のエージェントがモバイルノードの前に登録を吐き出さないのを確実にする登録Replyメッセージはそうします。 他方では、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を発行します。
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 home address and mobility security association of each authorized mobile node that it is serving as a home agent. 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:
IPアドレスとホームネットワークのための接頭語サイズでそれぞれのホームのエージェントを構成しなければなりません。 それがホームのエージェントとして勤めているそれぞれの認可されたモバイルノードのホームアドレスと移動性セキュリティ関係でホームのエージェントを構成しなければなりません。 ホームのエージェントがそれがホームのエージェントとして勤めるモバイルノードから有効なRegistration Requestを受け入れるとき、ホームのエージェントは、移動性の拘束力があるリスト含有でこのモバイルノードのためのエントリーを作成しなければならないか、または変更しなければなりません:
- 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 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を入れなければなりません、この移動性セキュリティ協会に基づいて。
3.8.2. Receiving Registration Requests
3.8.2. 登録要求を受け取ります。
Perkins Standards Track [Page 49] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[49ページ]。
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.
ホームのエージェントが入って来るRegistration Requestを受け入れるなら、それは(s)を縛るモバイルノードの移動性に関する記録をアップデートしなければなりません、そして、SHOULDは適当なCodeとRegistration Replyを送ります。 そうでなければ(ホームのエージェントはRequestを否定する)、それ、適切なCodeがRequestが否定された理由を指定している状態で、SHOULDはRegistration Replyを送ります。 以下のセクションはさらに詳細にこの振舞いについて説明します。
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 a valid
Mobile-Home Authentication Extension, and perform the
indicated authentication. Exactly one Mobile-Home
Authentication Extension MUST be present in the Registration
Request, and the home agent MUST check the Authenticator
value in the Extension. If 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 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) ホームのエージェントは、有効なモバイルホームAuthentication Extensionの存在がないかどうかチェックして、示された認証を実行しなければなりません。 ちょうど1モバイルホームAuthentication ExtensionがRegistration Requestに存在していなければなりません、そして、ホームのエージェントはExtensionでAuthenticator値をチェックしなければなりません。 モバイルホームAuthentication Extensionが全く見つけられないか、1モバイルホームAuthentication Extensionが見つけられる、または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 Mobile-Home Authentication Extension. See
Section 5.6 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.6. The home agent MUST do
no further processing with such a Request, though it SHOULD
log the error as a security exception.
b) ホームのエージェントは、登録Identification分野がモバイルホームAuthentication Extensionの中のSPIによって選択された文脈を使用することで正しいのをチェックしなければなりません。 これがどう実行されるかに関する記述に関してセクション5.6を見てください。 不正確です、ホームのエージェントがRequestを拒絶しなければならなくて、SHOULDがCode133とのモバイルノードにRegistration Replyを送るなら、セクション5.6で指定された規則に従って、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 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
c) ホームのエージェントが外国人のエージェントとの移動性セキュリティ仲間を共有するなら、ホームのエージェントは有効なForeign-ホームAuthentication Extensionの存在がないかどうかチェックしなければなりません。 ちょうど1Foreign-ホームAuthentication Extensionがこの場合Registration Requestに存在していなければなりません、そして、ホームのエージェントはExtensionでAuthenticator値をチェックしなければなりません。 またはForeign-ホームAuthentication Extensionが全く見つけられないか、または1Foreign-ホームAuthentication Extensionが見つけられるなら。
Perkins Standards Track [Page 50] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[50ページ]。
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.
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を再発行できるように。
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. 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.
Registration Requestがセクション3.8.2におけるバリディティチェックを満たすなら、.1、およびホームのエージェントはそうです。Requestを収容できます、ホームのエージェントは要求のモバイルノードのために移動性の拘束力があるリストをアップデートしなければならなくて、モバイルノードにRegistration Replyを返さなければなりません。 この場合、ホームのエージェントが同時の移動性に結合、または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はモバイルノードのホームアドレスと等しく、ホームのエージェントは要求のモバイルノードのための移動性の拘束力があるリストにおけるエントリーのすべてを削除します。 これはモバイルノードが、ホームのエージェントが、移動性サービスを提供するのをやめるようどう要求するかということです。
- 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はモバイルノードのために記載します。 '、'ビットは設定されて、ホームのエージェントは、同時の移動性が結合であるとサポートして、前の移動性の拘束力があるエントリーは保有されます。 さもなければ、ホームのエージェントはモバイルノードのための移動性の拘束力があるリストにおける前のすべてのエントリーを取り除きます。
Perkins Standards Track [Page 51] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[51ページ]。
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分野は受け入れられた現金書留のものとすべて等しいです。
In addition, if the home network implements ARP [16], and the Registration Request asks the home agent to create a mobility binding for a mobile node 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が[16]であると実装して、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
Registration Replyがセクション3.8.2におけるバリディティチェックのすべてを満たさないなら、.1、またはホームのエージェントがそうです。Requestを収容できません、ホームエージェントSHOULDは誤りの理由を示すCodeとのモバイルノードにRegistration Replyを返します。 外国人のエージェントがRequestをリレーするのにかかわったなら、これで、外国人のエージェントは未定の訪問者リストエントリーを削除できます。 これも
Perkins Standards Track [Page 52] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[52ページ]。
informs the mobile node of the reason for the error such that it may attempt to fix the error and issue another 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を返すことによって入ったモバイルノードに対するサービスを承諾するのを拒否するかもしれません。
If the Reserved field is nonzero, it MUST deny the Request with a Code of 134.
Reserved分野が非零であるなら、それは134のCodeと共にRequestを否定しなければなりません。
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メッセージの分野で供給しなければならない値のための追加詳細を明らかにします。
3.8.3.1. IP/UDP Fields
3.8.3.1. IP/UDP分野
This section provides the specific rules by which mobile nodes 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ソースアドレスからコピーされました。
Perkins Standards Track [Page 53] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[53ページ]。
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を伝えなければなりません。
3.8.3.2. Registration Reply Fields
3.8.3.2. 登録回答分野
This section provides specific rules by which home agents pick values for the fields within the fixed portion of a Registration Reply. The Code field of the Registration Reply is chosen in accordance with the rules specified in the previous sections. When replying to an accepted registration, a home agent SHOULD respond with Code 1 if it does not support simultaneous registrations.
このセクションはホームのエージェントがRegistration Replyの固定部分の中の分野に値を選ぶ特定の規則を提供します。 前項で指定された規則に従って、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を減少させた、(このモバイルノード、注意、-、アドレス)
Perkins Standards Track [Page 54] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[54ページ]。
The Home Address field MUST be copied from the corresponding field in the Registration Request.
Registration Requestの対応する分野からホームAddress分野をコピーしなければなりません。
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の固定長一部のそばで続きました。
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でホームのエージェントに関するモバイルノードのホームアドレスの相対的位置、および登録するのをそれと試みるかもしれないどんな外国人のエージェントに関するモバイルノード自体に関してもプロトコル概要を見てください。
Perkins Standards Track [Page 55] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[55ページ]。
4.1. Encapsulation Types
4.1. カプセル化タイプ
Home agents and foreign agents MUST support tunneling datagrams using IP in IP encapsulation [14]. Any mobile node that uses a co-located care-of address MUST support receiving datagrams tunneled using IP in IP encapsulation. Minimal encapsulation [15] and GRE encapsulation [8] 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カプセル化[14]にIPを使用して、ホームのエージェントと外国人のエージェントは、トンネリングがデータグラムであるとサポートしなければなりません。 共同見つけられたaを使用するどんなモバイルノード、も注意、-、アドレスはIPカプセル化にIPを使用することでトンネルを堀られたデータグラムを受信に支えなければなりません。 最小量のカプセル化[15]とGREカプセル化[8]は移動性エージェントとモバイルノードによって任意にサポートされるかもしれない代替のカプセル化メソッドです。 モバイルノードによって要求されると、これらの選択方式のカプセル化の使用はホームのエージェントの裁量でそうではありません。
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 network, or when away from home and using a co-located care-of address, is outside the scope of this document. ICMP Router Advertisement [4] is one such method.
ホームネットワークに関連づけられると、モバイルノードは移動性サービスのサポートなしで作動します。 いかなる他の(修理される)のホストかルータとも同様に、すなわち、それは作動します。 ホームネットワーク、またはいつまでaが共同場所を見つけたホームと使用から遠くに接続されるかとモバイルノードがデフォルトルータを選択するメソッド、注意、-、アドレスはこのドキュメントの範囲の外のそうです。 ICMP Router Advertisement[4]はそのようなメソッドの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, then 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. The
mobile node MAY also consider the IP source address of the Agent
Advertisement as another possible choice for the IP address of a
default router, along with the (possibly empty) list of Router
Addresses from the ICMP Router Advertisement portion of the
message. In such cases, the IP source address MUST be considered
to be the worst choice (lowest preference) for a default router.
- モバイルノードが外国人のエージェントを使用することで登録されている、注意、-、アドレス、そして、モバイルノードはそのエージェントAdvertisementメッセージのICMP Router Advertisement部分の広告に掲載されたRouter Addressesからデフォルトルータを選ばなければなりません。 また、モバイルノードは、エージェントAdvertisementのIPソースアドレスをデフォルトルータのIPアドレスのための別の可能な選択と考えるかもしれません、メッセージのICMP Router Advertisement部分からのRouter Addressesの(ことによると空)のリストと共に。 そのような場合、デフォルトルータのための最も悪い選択(最も低い好み)であるとIPソースアドレスを考えなければなりません。
- 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, along with the
(possibly empty) list of Router Addresses from the ICMP Router
- モバイルノードが直接aが共同場所を見つけたホームエージェント使用に登録される、注意、-、アドレス、次に、モバイルノードSHOULDが受信するというそれを外部的に得てあるどんなICMP Router Advertisementメッセージも広告に掲載されたものからデフォルトルータを選ぶ、注意、-、アドレスとRouter Addressはネットワーク接頭語の下で合っています。 外部的にモバイルノードを得た、注意、-、アドレスはネットワーク接頭語の下でエージェントAdvertisementのIPソースアドレスに合っています、また、モバイルノードがそのIPソースアドレスがデフォルトルータのIPアドレスのための別の可能な選択であるとみなすかもしれません、ICMP RouterからのRouter Addressesの(ことによると空)のリストと共に
Perkins Standards Track [Page 56] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[56ページ]。
Advertisement portion of the message. If so, the IP source
address MUST be considered to be the worst choice (lowest
preference) for 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.
メッセージの広告部分。 そうだとすれば、デフォルトルータのための最も悪い選択(最も低い好み)であるとIPソースアドレスを考えなければなりません。 ネットワーク接頭語は、Router AdvertisementのPrefix-長さのExtensionから得て、存在しているかもしれません。 また、このドキュメントの範囲を超えた他のメカニズムを通して接頭語を得るかもしれません。
Beyond these rules, the actual selection of the default router is made by the selection method specified for ICMP Router Discovery [4], among the Router Addresses specified above. In any case, a mobile node registered via a foreign agent MAY choose its foreign agent as a default router.
これらの規則を超えて、上で指定されたRouter Addressesの中でICMP Routerディスカバリー[4]に指定された選択メソッドでデフォルトルータの実際の選択をします。 どのような場合でも、外国人のエージェントを通して登録されたモバイルノードはデフォルトルータとして外国人のエージェントを選ぶかもしれません。
Note that Van Jacobson header compression [10] will not function properly unless all TCP IP datagrams to and from the mobile node pass, respectively, through the same first and last-hop router. The mobile node, therefore, MUST select its foreign agent as its default router if it performs Van Jacobson header compression with its foreign agent.
ノードとモバイルノードからのすべてのTCP IPデータグラムが同じ1番目と最後のホップルータをそれぞれ通るというわけではないとヴァンジェーコブソンヘッダー圧縮[10]が適切に機能しないことに注意してください。 したがって、それが外国人のエージェントと共にヴァンジェーコブソンヘッダー圧縮を実行するなら、モバイルノードはデフォルトルータとして外国人のエージェントを選定しなければなりません。
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 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).
外国人のエージェントは経路ドメインの他のルータと、そして、いかなる他のモバイルノード(モバイルルータ(セクション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. In addition, the foreign agent SHOULD send an appropriate ICMP Redirect message to the mobile node.
外国人のエージェントはそれが登録されたモバイルノードから受けるデータグラムを発送しなければなりません。 最小限では、これが、外国人のエージェントがIP Header Checksumについて確かめなければならないことを意味して、減少がIP Time To Liveであり、recomputeがIP Header Checksumであり、フォワードはデフォルトルータへのそのようなデータグラムです。 さらに、外国人のエージェントSHOULDは適切なICMP Redirectメッセージをモバイルノードに送ります。
Perkins Standards Track [Page 57] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[57ページ]。
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 home network. In this case, the home agent MUST assume the mobile node is at home and simply forward the datagram directly onto the home network.
ホームのエージェントは、それがホームから遠くに登録されたモバイルノードのどれかに関するホームアドレスと等しいかどうか確認するためにすべて到着しているデータグラムのIP 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トラフィックを扱って、しかしながら、推進のためのそのようなデータグラムをホームネットワークに受けるのも、可能です。 この場合、ホームのエージェントは、モバイルノードがホームでそうであると仮定して、単に直接ホームネットワークにデータグラムを送らなければなりません。
See Section 4.1 regarding methods of encapsulation that may be used for tunneling. Nodes implementing tunneling SHOULD also implement the "tunnel soft state" mechanism [14], which allows ICMP error messages returned from the tunnel to correctly be reflected back to the original senders of the tunneled datagrams.
トンネリングに使用されるかもしれないカプセル化のメソッドに関してセクション4.1を見てください。 また、トンネリングがSHOULDであると実装するノードは、「軟性国家にトンネルを堀ってください」というメカニズムが[14]であると実装します。([14]は、トンネルから返されたICMPエラーメッセージが正しくトンネルを堀られたデータグラムの元の送り主に映し出されるのを許容します)。
Home agents SHOULD be able to decapsulate and further deliver packets addressed to themselves, sent by a mobile node for the purpose of maintaining location privacy, as described in Section 5.5.
ホームエージェントSHOULDはdecapsulateにできて、さらにセクション5.5で説明されるように位置のプライバシーを維持する目的のためのモバイルノードによって送られた自分たちに扱われたパケットを提供します。
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
ホームのエージェントがホームから遠くに登録されたモバイルノードの1つのために妨害されたデータグラムを受け取るとき、ホームのエージェントは、それが既にカプセル化されるかどうかチェックするためにデータグラムを調べなければなりません。 そうだとすれば、特別
Perkins Standards Track [Page 58] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[58ページ]。
rules apply in the forwarding of that datagram to the mobile node:
規則はそのデータグラムの推進でモバイルノードに適用されます:
- If the inner (encapsulated) Destination Address is the same
as the outer Destination Address (the mobile node), then the
home agent MUST also examine the outer Source Address of the
encapsulated datagram (the source address of the tunnel). If
this outer Source Address is the same as the mobile node's
current care-of address, the home agent MUST silently discard
that datagram in order to prevent a likely routing loop. If,
instead, the outer Source Address is NOT the same as the mobile
node's current care-of address, then the home agent SHOULD
forward the datagram to the mobile node. In order to forward
the datagram in this case, the home agent MAY simply alter the
outer Destination Address to the care-of address, rather than
re-encapsulating the datagram.
- また、内側(カプセル化される)の目的地Addressが外側のDestination Address(モバイルノード)と同じであるなら、ホームのエージェントはカプセル化されたデータグラム(トンネルのソースアドレス)の外側のSource Addressを調べなければなりません。 この外側のSource Addressが同じである、モバイルノードの電流、注意、-、アドレス、ホームのエージェントは、ありそうなルーティング輪を防ぐために静かにそのデータグラムを捨てなければなりません。 代わりにSource Addressが同じでない外側、モバイルノードの電流、注意、-、アドレス、そして、ホームのエージェントSHOULDはモバイルノードにデータグラムを送ります。 この場合ホームのエージェントが単に外側のDestination Addressを変更するかもしれないデータグラムを進める、注意、-、アドレス、データグラムを再カプセル化するよりむしろ。
- Otherwise (the inner Destination Address is NOT the same as the
outer Destination Address), the home agent SHOULD encapsulate
the datagram again (recursive 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
'D'ビットがモバイルノードのRegistration Requestメッセージにおけるセット、モバイルノードが単にアドレスの共同位置している注意、ホームのエージェントを使用しているのを示したことである、トンネルが放送IPデータグラムを当てるモバイルノードのもの、注意、-、アドレス さもなければ('D'ビットは設定されなかった)、ホームのエージェントは、最初に、モバイルノードのホームアドレスに扱われたユニキャストデータグラム、および次に、トンネルのブロードキャスト・データグラムがこのカプセル化されたデータグラムであると外国人のエージェントにカプセル化します。 この付加的なレベルのカプセル化が、外国人のエージェントが、それがdecapsulatedされた後にどのモバイルノードがデータグラムを受けるはずであるかを決心できるくらい必要です。 外国人のエージェントによって受け取られると、データグラムであるとカプセル化されたユニキャストは、「反-トンネル」であり、提供されます。
Perkins Standards Track [Page 59] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[59ページ]。
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.
いかなる他のデータグラムとも同じようにモバイルノードに。 どちらの場合ではも、モバイルノードはそれがオリジナルのブロードキャスト・データグラムを回収するために受けるデータグラムを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.
いかなる他の(修理される)のホストかルータとも同様に、既述のとおり、ホームネットワークに接続されるモバイルノードは機能します。 それがホームにあるとき、したがって、モバイルノードは同様に他のマルチキャスト送付者と受信機に機能します。 したがって、このセクションは外国ネットワークを訪問しているモバイルノードの動きについて説明します。
In order 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 [5] messages. Otherwise, it MUST use its home address.
マルチキャストを受けるために、モバイルノードは2つの方法の1つでマルチキャストグループに加わらなければなりません。 まず最初に、訪問されたサブネットに関する(地方)のマルチキャストルータでモバイルノードはグループに加わるかもしれません。 このオプションは、訪問されたサブネットの現在のマルチキャストルータがあると仮定します。 モバイルノードがaが共同場所を見つけた使用である、注意、-、アドレス、それ、SHOULDはIGMP[5]メッセージのソース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. 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 (recursive tunneling) to the mobile node's care-of address.
あるいはまた、マルチキャストを受けたがっているモバイルノードはホームのエージェントへの双方向のトンネルを通ってグループに加わるかもしれません、ホームのエージェントがマルチキャストルータであると仮定して。 モバイルノードはホームのエージェントにIGMPメッセージにトンネルを堀ります、そして、ホームのエージェントはモバイルノードへのトンネルの下側にマルチキャストデータグラムを送ります。 ブロードキャスト・データグラム(セクション4.3)に、この場合、モバイルノードへのマルチキャストデータグラム配信のための規則はそれらと同じです。 モバイルノードがすなわち、aが共同場所を見つけた使用である、注意、-、アドレス('D'ビットはモバイルノードのRegistration Requestに設定された)、次に、ホームのエージェントSHOULDがこれにデータグラムにトンネルを堀る、注意、-、アドレス。 さもなければ、ホームのエージェントが最初に、モバイルノードのホームアドレスに扱われたユニキャストデータグラムでデータグラムをカプセル化しなければならなくて、次に、結果として起こるデータグラム(再帰的なトンネリング)にトンネルを堀らなければならない、モバイルノードのもの、注意、-、アドレス
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番目のオプションは、ホームのエージェントがマルチキャストルータであると仮定します。
Perkins Standards Track [Page 60] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[60ページ]。
4.5. Mobile Routers
4.5. モバイルルータ
A mobile node can be a router, which is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks".
モバイルノードはルータであるかもしれません、恐らく飛行機、船、列車、自動車、自転車、またはカヤックの上に。(それは、一緒に移行する1つ以上の全体のネットワークの移動性に原因となります)。 モバイルルータによって役立たれるネットワークに接続されたノードがそうするかもしれない、自分たち、固定ノード、モバイルノードまたはルータになってください。 本書では、そのようなネットワークは「モバイルネットワーク」と呼ばれます。
A mobile router MAY act as a foreign agent and provide a foreign agent care-of address to mobile nodes connected to the mobile network. Typical routing to a mobile node via a mobile router in this case is illustrated by the following example:
モバイルルータが外国人のエージェントとして務めて、外国人のエージェントを提供するかもしれない、注意、-、モバイルノードへのアドレスはモバイルネットワークに接続しました。 この場合、モバイルルータを通したモバイルノードへの典型的なルーティングは以下の例によって例証されます:
a) A laptop computer is disconnected from its home network and
later attached to a network port in the seat back of an
aircraft. The laptop computer uses Mobile IP to register on
this foreign network, using a foreign agent care-of address
discovered through an Agent Advertisement from the aircraft's
foreign agent.
a) ラップトップコンピュータは、ホームネットワークから切断されて、後で航空機についてシートバックのネットワークポートに付けられます。 ラップトップコンピュータはこの外国ネットワークに登録するのにモバイルIPを使用します、外国人のエージェントを使用して注意、-、アドレスがエージェントを通して航空機の外国人のエージェントから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ルーティングはエアラインの本部の固定ネットワークにデータグラムを発送するでしょう。
Perkins Standards Track [Page 61] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[61ページ]。
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する、ラップトップのもの、注意、-、アドレス 外国人のエージェントが航空機へのラジオリンクの上の結果として起こるデータグラムを送る地面。
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 recursive 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 recursive tunneling of datagrams.
あるいはまた、双方向のトンネルを通ってそれ自身のホームのエージェントに正常なIPルーティング・プロトコルを使用して、モバイルルータは全体のモバイルネットワークに接続性の広告を出すかもしれません。 このメソッドはデータグラムの再帰的なトンネリングの必要性を避けます。
4.6. ARP, Proxy ARP, and Gratuitous ARP
4.6. ARP、プロキシARP、および無料のARP
The use of ARP [16] requires special rules for correct operation when wireless or mobile nodes are involved. The requirements specified in this section apply to all home networks in which ARP is used for address resolution.
ワイヤレスの、または、モバイルのノードがかかわるとき、ARP[16]の使用は正しい操作のための特別な規則を必要とします。 このセクションで指定された要件はARPがアドレス解決に使用されるすべてのホームネットワークに適用されます。
Perkins Standards Track [Page 62] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[62ページ]。
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 [18] 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 [16],
but supplies some configured link-layer address (generally, its
own) in the Sender Hardware Address field. The node receiving
the Reply will then associate this link-layer address with the
IP address of the original target node, causing it to transmit
future datagrams for this target node to the node with that
link-layer address.
- Proxy ARP[18]は1つのノードによってそれ自身のARP Requestsに答えたがっていない別のノードを代表して送られたARP Replyです。 Proxy ARPの送付者は、[16]で説明されるようにSenderとTargetプロトコルAddress分野を逆にしますが、Sender Hardware Address分野で何らかの構成されたリンクレイヤアドレス(一般にそれ自身のもの)を供給します。 次に、Replyを受けるノードはオリジナルの目標ノードのIPアドレスにこのリンクレイヤアドレスを関連づけるでしょう、この目標ノードのためにそのリンクレイヤアドレスで将来のデータグラムをノードに送ることを引き起こして。
- A Gratuitous ARP [23] 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[23]は他のノードがそれらの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 [16], any node receiving any ARP packet (Request or
Reply) MUST update its local ARP cache with the Sender Protocol
and Hardware Addresses in the ARP packet, if the receiving node
has an entry for that IP address already in its ARP cache. This
requirement in the ARP protocol applies even for ARP Request
packets, and for ARP Reply packets that do not match any ARP
Request transmitted by the receiving node [16].
どちらの場合ではも、無料のARPに関して、ローカル放送パケットとして地方のリンクの上にARPパケットを伝えなければなりません。 指定されるように、[16]、どんなARPパケット(要求かReply)もアップデートしなければならないどんなノード受信でも、地方のARPはSenderと共にARPパケットでプロトコルとHardware Addressesをキャッシュします、受信ノードに既にARPキャッシュにおけるそのIPアドレスのためのエントリーがあるなら。 ARPプロトコルのこの要件はARP Requestパケット、および受信ノード[16]によって伝えられた少しのARP Requestにも合っていないARP Replyパケットのためにさえ申し込まれます。
While a mobile node is registered on a foreign network, its home agent uses proxy ARP [18] 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 [18], 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[18]を使用します。 ARP Requestを受けるとき、ホームのエージェントはRequestの目標IPアドレスを調べなければなりません、そして、このIPアドレスがそれが登録された移動性結合を持っているどんなモバイルノードに関するホームアドレスにも合っているなら、ホームのエージェントはモバイルノードを代表してARP Replyを伝えなければなりません。 パケット[18]で送付者とあて先アドレスを交換した後に、ホームのエージェントはReplyが送られるそれ自身のインタフェースのリンクレイヤアドレスへのパケットに送付者リンクレイヤアドレスをはめ込まなければなりません。
Perkins Standards Track [Page 63] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[63ページ]。
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少ない番号の回になってください。
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 its home agent. Th 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 sent 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
モバイルノードが家にいない間、それはどんな放送ARP RequestかARP Replyメッセージも送ってはいけません。 最終的に、モバイルノードが家にいない間、目標IPアドレスがそれ自身のホームアドレスであるARP Requestsに答えてはいけません、ARP Requestが登録するのをモバイルノードと試みている外国人のエージェントかモバイルノードには満期になっていない登録がある外国人のエージェントによって送られない場合。 後者のケース、モバイルで
Perkins Standards Track [Page 64] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[64ページ]。
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 Replyを使用しなければなりません。 モバイルノードがaが共同場所を見つけた使用であるならそれに注意してください、注意、-、目的のIPアドレスがそうであるARP Requestが扱って、受ける、これ、注意、-、アドレス、そして、モバイルノードSHOULDはこのARP Requestに答えます。 また、外国ネットワークでRegistration Requestを伝えるとき、モバイルノードがエージェントAdvertisementからその外国人のエージェントからそれを受け取るようにアドレスを保存することによって外国人のエージェントのリンクレイヤアドレスを発見するかもしれないことに注意しますが、放送ARP Requestメッセージを送ることによって、注意するというわけではなくなってください。
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. 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を使用し始めます。 または、代わりに、ホームのエージェントが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を受けたので。
Perkins Standards Track [Page 65] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[65ページ]。
- 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.
- モバイルノードはそれ自体のために無料のARPを実行します。
- The mobile node transmits its Registration Request.
- モバイルノードはRegistration Requestを伝えます。
- When the mobile node's home agent receives and accepts the
Registration Request, it stops using proxy ARP to reply to
ARP Requests that it receives requesting the mobile node's
link-layer address, and then performs a gratuitous ARP on behalf
of the mobile node. If, instead, the home agent rejects the
Registration Request, no ARP processing (gratuitous nor proxy) is
performed by the home agent.
- モバイルノードのホームのエージェントがRegistration Requestを受け取って、受け入れると、それは、それが受けるARP Requestsに答えるのにモバイルノードのリンクレイヤアドレスを要求しながらプロキシARPを使用するのを止めて、モバイルノードを代表して無料のARPを実行します。 または、代わりに、ホームのエージェントがRegistration Requestを拒絶して、どんな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 keyed MD5 [21], with a key size of 128 bits. The default mode of operation is to both precede and follow the data to be hashed, by the 128-bit key; that is, MD5 is to be used in "prefix+suffix" mode. The foreign agent MUST also support authentication using keyed MD5 and key sizes of 128 bits or greater, with manual key distribution. More authentication algorithms, algorithm modes, key distribution methods, and key sizes MAY also be supported.
ホームのエージェントとモバイルノードは認証を実行できなければなりません。 デフォルトアルゴリズムは128ビットの主要なサイズがある合わせられたMD5[21]です。 デフォルト運転モードは、128ビットのキーによって論じ尽くされるためにともにデータに先行して、従うことです。 すなわち、MD5は「接頭語+接尾語」モードで使用されることになっています。 また、外国人のエージェントは認証が128ビット以上の合わせられたMD5を使用して、主要なサイズであるとサポートしなければなりません、手動の主要な分配で。 また、より多くの認証アルゴリズム、アルゴリズムモード、主要な分配メソッド、および主要なサイズはサポートされるかもしれません。
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 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の使用に関連しているリスクのすべてをもたらします。
Perkins Standards Track [Page 66] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[66ページ]。
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. [7] provides more information on generating pseudo-random numbers.
どんな認証機構の強さもいくつかの要素に依存します、認証アルゴリズムの生まれながらの強さ、使用されるキーの秘密保持、使用されるキーの強さ、および特定の実装の品質を含んでいて。 この仕様は、認証のために合わせられたMD5の実装を必要としますが、他の認証アルゴリズムとモードの使用を排除しません。 合わせられたMD5認証が役に立つように、128ビットのキーは秘密(すなわち、認可されたパーティーだけにおいて、知られている)と擬似ランダムの両方でなければなりません。 また、一回だけが反復操作による保護に関して使用されるなら、慎重にそれらを選択しなければなりません。 イーストレーク、他 [7]は擬似乱数を生成する詳しい情報を提供します。
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 67] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[67ページ]。
5.6. Replay Protection for Registration Requests
5.6. 登録要求のための反復操作による保護
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.2 for a patent that may apply to nonce-based replay protection).
ホームのエージェントに攻撃者によって前の何らかの登録から再演されるのではなく、登録メッセージがモバイルノードによって新たに生成されたことを確かめさせるのにIdentification分野は使用されます。 2つのメソッドがこのセクションで説明されます: タイムスタンプ(義務的な)と「一回だけ。」(任意の) すべてのモバイルノードとホームのエージェントはタイムスタンプベースの反復操作による保護を実装しなければなりません。 また、これらのノードは一回だけベースの反復操作による保護を実装するかもしれません(一回だけベースの反復操作による保護に申請されるかもしれない特許に関してAppendix A.2を見てください)。
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. The mobile node MUST verify that the low-order 32 bits of any Registration Reply are identical to the bits it sent in the Registration Request.
いかなる使用されたメソッド、Registration RequestからReplyまで変わりがない状態でIdentificationの下位の32ビットをコピーしなければなりません。 外国人のエージェントは、対応する回答にRegistration Requestsを合わせるのに、それらのビット(そして、モバイルノードのホームアドレス)を使用します。 モバイルノードは、どんなRegistration Replyの下位の32ビットもそれが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.6.1. Replay Protection using Timestamps
5.6.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. 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.
タイムスタンプ反復操作による保護の基本原理はメッセージを生成するノードが現在の時刻を挿入して、メッセージを受け取るノードが、このタイムスタンプがそれ自身の時刻の十分近くにあるのをチェックするということです。 明らかに、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 [13]. 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
タイムスタンプが使用されているなら、モバイルノードはNetwork Timeプロトコル[13]によって指定されるようにフォーマットされた64ビットの値にIdentification分野を設定しなければなりません。 NTP形式の下位の32ビットは有効でない断片的な秒、およびそれらのビットを表します。時間ソースSHOULDから、偶発性の良い源から生成されてください。 しかしながら、タイムスタンプ、64ビットのIdentificationを使用するときにはそれに注意してください。
Perkins Standards Track [Page 68] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[68ページ]。
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.
Registration Requestでモバイルノードから使用されているのは、前のいずれでも使用されるそれよりすばらしいRegistration Requestであるに違いありません、ホームのエージェントが一連番号としてもこの分野を使用するとき。 それが以前のRegistration Requestの遅れた写しがホームのエージェント(ホームのエージェントによって必要とされた時計同期の中の)に到着するのにおいて可能であるだろう、その結果、故障していた状態で適用されて、そのような一連番号がなければ、モバイルノードの電流を誤って変更するのが登録された、注意、-、アドレス。
Upon receipt of a Registration Request with a valid Mobile-Home Authentication 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.
有効なモバイルホームAuthentication Extensionと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ビットが拒絶された登録試みにおけるそれらと同じであることを確かめなければなりません、時計再同期に高位のビットを使用する前に。
5.6.2. Replay Protection using Nonces
5.6.2. 一回だけを使用する反復操作による保護
Implementors of this optional mechanism should examine Appendix A.2 for a patent that may be applicable to nonce-based replay protection.
この任意のメカニズムの作成者は一回だけベースの反復操作による保護に適用されるかもしれない特許のためにAppendix A.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 [7]. 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
ホームのエージェントが擬似乱数を計算するためのリソースを一回だけ[7]として役に立つようにすると予想されるかもしれません。 それはあらゆるRegistration Replyの識別分野の高位32ビットとして新しい一回だけを挿入します。 エージェントが下位の32ビットをコピーするホーム
Perkins Standards Track [Page 69] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[69ページ]。
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.
Registration ReplyのIdentificationの下位の32ビットへのRegistration RequestメッセージからのIdentification。 モバイルノードがホームのエージェントから認証された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は、次の登録に使用されるためにいつも新しい一回だけをモバイルノードに提供します。 したがって、一回だけのプロトコルは自己連動です。
Perkins Standards Track [Page 70] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[70ページ]。
6. Acknowledgments
6. 承認
Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp and John Ioannidis (JI) (Columbia), for forming the working group, chairing it, and putting so much effort into its early development.
ダン・デュシャンに伴うスティーブ・デアリングへの特別な感謝(ゼロックスPARC)と、それをまとめて、ワーキンググループを形成するためのジョンIoannidis(JI)(コロンビア)と、とても多くの取り組みを初期発生にそそぐこと。
Thanks also to Kannan Alaggapan, Greg Minshall, and Tony Li for their contributions to the group while performing the duties of chairperson, as well as for their many useful comments.
また、グループへの彼らの貢献を議長の義務を実行している間、Kannan Alaggapan、グレッグMinshall、およびトニー・李をありがとうございます、よく彼らの多くの役に立つコメントのように。
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),
- Dave Johnson (Carnegie Mellon University),
- Frank Kastenholz (FTP Software),
- Anders Klemets (KTH),
- Chip Maguire (KTH),
- Andrew Myles (Macquarie University),
- Al Quirt (Bell Northern Research),
- Yakov Rekhter (IBM), and
- Fumio Teraoka (Sony).
- そして、アトキンソン(海軍の研究研究室)--デーブ・ジョンソン(カーネギーメロン大学)--フランクKastenholz(FTPソフトウェア)--アンダースKlemets(KTH)--マグワイア(KTH)を欠きます--アンドリュー・マイルズ(マクオーリー大学)--アルQuirt(ベル北研究)--ヤコフRekhter(IBM)を走らせた、--Fumio Teraoka(ソニー)。
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 of this memo is due to Jim Solomon and Dave Johnson.
作業部会の議論を反映して、このドキュメントはチャーリーKunzinger、およびビル・シンプソンへの最初の案文を作成したエディタに感謝します。 このメモの新しい原本の多くがジム・ソロモンとデーブ・ジョンソンのためです。
Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), and Frank Kastenholz (FTP Software) for their generous support in hosting interim Working Group meetings.
彼らの寛大なサポートを当座の作業部会のミーティングを主催するのにおいてグレッグMinshall(ノベル)、フィルKarn(クアルコム)、およびフランクKastenholz(FTP Software)をありがとうございます。
Perkins Standards Track [Page 71] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[71ページ]。
A. Patent Issues
A。 特許問題
As of the time of publication, the IETF had been made aware of two patents that may be relevant to implementors of the protocol described in this technical specification.
IETFをこの技術仕様書で説明されたプロトコルの作成者に関連するかもしれない2つの特許を意識するようにしました公表の時点。
A.1. IBM Patent #5,159,592
A.1。 IBM特許#5,159,592
Charles Perkins, editor of this memo, is sole inventor of U.S. Patent No. 5,159,592, assigned to IBM. In a letter dated May 30, 1995, IBM brought this patent to the attention of the IETF, stating that this patent "relates to the Mobile IP." We understand that IBM did not intend to assert that any particular implementation of Mobile IP would or would not infringe the patent, but rather that IBM was meeting what it viewed as a duty to disclose information that could be relevant to the process of adopting a standard.
チャールズ・パーキンス(このメモのエディタ)はIBMに配属された米国特許番号5,159,592の唯一の発明者です。 1995年5月30日付けの手紙では、IBMはこの特許をIETFの注意にもたらしました、この特許が「モバイルIPに関連する」と述べて。 私たちは、IBMが、モバイルIPのどんな特定の実装も特許権を侵害しただろうか、または特許権を侵害しなかったでしょうが、むしろ、IBMがそれが規格を採用するプロセスに関連するかもしれない開示義務情報をみなしたことを満たしていたと断言しないつもりであったのを理解しています。
Based on a review of the claims of the patent, IETF believes that a system of registering an address obtained from a foreign agent, as described in the document, would not necessarily infringe any of the claims of the patent; and that a system in which an address is obtained elsewhere and then registered can be implemented without necessarily infringing any claims of the patent. Accordingly, our view is that the proposed protocol can be implemented without necessarily infringing the Perkins Patent.
特許のクレームのレビューに基づいて、IETFは、ドキュメントで説明されるように外国人のエージェントから得られたアドレスを登録するシステムが必ず特許のクレームのどれかを侵害するというわけではないと信じています。 そして、必ず特許のどんなクレームも侵害するというわけではなくて、アドレスがほかの場所で得られて、次に登録されるシステムを導入されることができます。 それに従って、私たちの視点は必ずパーキンスPatentを侵害するというわけではなくて提案されたプロトコルを実装することができるということです。
Parties considering adopting this protocol must be aware that some specific implementations, or features added to otherwise non- infringing implementations, may raise an issue of infringement with respect to this patent or to some other patent.
このプロトコルを採用すると考える党はいくつかの特定の実装、または非侵害しているそうでなければ、実装に加えられた特徴がこの特許かある他の特許への侵害の問題を提起するかもしれないのを意識しているに違いありません。
This statement is for the IETF's assistance in its standard-setting procedure, and should not be relied upon by any party as an opinion or guarantee that any implementation it might make or use would not be covered by the Perkins Patent and any other patents. In particular, IBM might disagree with the interpretation of this patent described herein.
この声明を標準の設定手順におけるIETFの支援のためにあって、どんなパーティーもそれが作るか、または使用するどんな実装もパーキンスPatentといかなる他の特許でもカバーされていないだろうという意見か保証として当てにするべきではありません。 特に、IBMはここに説明されるこの特許の解釈に意見を異にするかもしれません。
A.2. IBM Patent #5,148,479
A.2。 IBM特許#5,148,479
This patent, also assigned to IBM, may be relevant to those who implement nonce-based replay protection as described in Section 5.6.2. Note that nonce-based replay protection is an optional feature of this specification. Timestamp-based replay protection, on the other hand, (Section 5.6.1) is a requirement of this specification.
このまた、IBMに配属された特許はセクション5.6.2で説明されるように一回だけベースの反復操作による保護を実装する人に関連しているかもしれません。 一回だけベースの反復操作による保護がこの仕様に関するオプション機能であることに注意してください。 他方では、タイムスタンプベースの反復操作による保護はこの仕様の要件(セクション5.6.1)です。
Perkins Standards Track [Page 72] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[72ページ]。
B. Link-Layer Considerations
B。 リンクレイヤ問題
The mobile node MAY use link-layer mechanisms to decide that its point of attachment has changed. Such indications include the Down/Testing/Up interface status [11], 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.
モバイルノードは、接着点が変化したと決めるのにリンクレイヤメカニズムを使用するかもしれません。 そのような指摘は、Down/テスト/をインタフェース状態[11]に含めて、セルか管理で変化を含めます。 メカニズムは、特定のリンクレイヤ技術に特定であり、このドキュメントの範囲の外にあります。
The Point-to-Point-Protocol (PPP) [22] and its Internet Protocol Control Protocol (IPCP) [12], negotiates the use of IP addresses.
Pointからポイントプロトコル(PPP)への[22]とそのインターネットプロトコルControlプロトコル(IPCP)[12]、IPアドレスの使用を交渉します。
The mobile node SHOULD first attempt to specify its home address, so that if the mobile node is attaching to its home network, the unrouted link will function correctly. When the home address is not accepted by the peer, but a transient IP address is dynamically assigned to the mobile node, and the mobile node is capable of supporting a co-located care-of address, the mobile node MAY register that address as a co-located care-of address. When the peer specifies its own IP address, that address MUST NOT be assumed to be a foreign agent care-of address or the IP address of a home agent.
モバイルノードSHOULDは、最初にホームアドレスを指定するのを試みます、モバイルノードがホームネットワークに付いていると、非発送されたリンクが正しく機能するように。 ホームアドレスがいつでないかが同輩で受け入れましたが、一時的なIPアドレスがダイナミックにモバイルノードに割り当てられて、モバイルノードがaが共同場所を見つけたサポートすることができる、注意、-、アドレス、aとしてのアドレスが共同場所を見つけたモバイルノード5月のレジスタ、注意、-、アドレス。 同輩がそれ自身のIPアドレスを指定すると、外国人のエージェントであるとそのアドレスを思ってはいけない、注意、-、アドレスかホームのエージェントのIPアドレス。
C. TCP Considerations
C。 TCP問題
C.1. TCP Timers
C.1。 TCPタイマ
Most hosts and routers which implement TCP/IP do not permit easy configuration of the TCP timer values. When high-delay (e.g., SATCOM) or low-bandwidth (e.g., High-Frequency Radio) links are in use, the default TCP timer values in many systems may cause retransmissions or timeouts, even when the link and network are actually operating properly with greater than usual delays 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 make TCP timers more configurable. Vendors of systems designed for the mobile computing markets should pick default timer values more suited to low-bandwidth, high-delay links. Users of mobile nodes should be sensitive to the possibility of timer-related difficulties.
TCP/IPを実装するほとんどのホストとルータがTCPタイマ値の簡単な構成を可能にしません。 高い遅れ(例えば、SATCOM)か低バンド幅(例えば、High-頻度Radio)リンクが使用中であるときに、多くのシステムのデフォルトTCPタイマ値は「再-トランスミッション」かタイムアウトを引き起こすかもしれません、リンクとネットワークが使用中の媒体のために実際にいつもよりすばらしいことで適切に遅れを運用してさえいるとき。 これは、そのようなリンクの上のTCP接続を創造できませんし、維持できないことを引き起こす場合があって、また、既に不十分な帯域幅を消費する不要な「再-トランスミッション」を引き起こす場合があります。 ベンダーがTCPタイマをより構成可能にするよう奨励されます。 市場を計算するモバイルのために設計されたシステムのベンダーは低バンド幅にさらに合ったデフォルトタイマ値、高遅れリンクを選ぶべきです。 モバイルノードのユーザはタイマ関連の困難の可能性に敏感であるべきです。
C.2. TCP Congestion Management
C.2。 TCPふくそう管理
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 [9]. 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-
モバイルノードはしばしば事実上、より多くのパケットが下げられることを引き起こして、誤りをより導入しそうなメディアを使用します。 これはTCP[9]の現代版で見つけられたふくそう管理のためにメカニズムとの闘争を導入します。 パケットが現在下げられるとき、通信員ノードのTCP実装は、まるでネットワークの混雑の源があるかのように反応して、遅さを開始しそうです。
Perkins Standards Track [Page 73] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[73ページ]。
start mechanisms [9] 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. [3]; there is no easy solution available, and certainly no solution likely to be installed soon on all correspondent nodes. While this problem is beyond the scope of this document, it does illustrate that providing performance transparency to mobile nodes involves understanding mechanisms outside the network layer. It also indicates the need to avoid designs which systematically drop packets; such designs might otherwise be considered favorably when making engineering tradeoffs.
その問題を制御するように設計されたメカニズム[9]を始動してください。 しかしながら、それらのメカニズムで、リンク自体によって導入された誤りを克服するのに不適当であり、下げられたパケットは不連続を拡大するという効果を導入します。 この問題はカセレス、他によって分析されました。 [3]; すべての通信員ノードの上に利用可能な容易な解決がなく、および確かにインストールされそうなどんなソリューションもすぐ、ありません。 この問題がこのドキュメントの範囲を超えている間、性能透明をモバイルノードに提供するのが、ネットワーク層の外でメカニズムを理解していることを伴うのが例証します。 また、それは系統的にパケットを下げるデザインを避ける必要性を示します。 工学を見返りにするとき、そのようなデザインは別の方法で好意的に考えられるかもしれません。
D. Example Scenarios
D。 例のシナリオ
This section shows example Registration Requests for several common scenarios.
このセクションはいくつかの共通したシナリオのために例のRegistration Requestsを示しています。
D.1. Registering with a Foreign Agent Care-of Address
D.1。 外国人のエージェントとともに記名する、注意、-、アドレス
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:
モバイルノードが外国人のエージェントからエージェントAdvertisementを受けて、広告を出している外国人のエージェントを使用することでそのエージェントとともに記名したがっている、注意、-、アドレス。 モバイルノードは、IPにおけるIPだけにカプセル化を願って、放送が欲しくなく、また同時の移動性結合を必要としません:
IP fields:
Source Address = mobile node's home address
Destination Address = copied from the IP source address of the
Agent Advertisement
Time to Live = 1
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=0,D=0,M=0,G=0
Lifetime = the Registration Lifetime copied from the
Mobility Agent Advertisement Extension of the
Router Advertisement message
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = the Care-of Address copied from the
Mobility Agent Advertisement Extension of the
Router Advertisement message
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home Authentication Extension
IP分野: ソースAddressはモバイルノードのホームアドレスの1エージェントAdvertisement TimeのIPソースアドレスからLiveまでコピーされたDestination Address==UDPの分野と等しいです: ソースPortは434どんな>Destination Portも=Registration Requestがさばく<と等しいです: タイプ=1秒間=0、B=0、D=0、M=0、G=0 LifetimeがモバイルノードのホームのエージェントのIPモバイルノードのホームアドレスホームのRouter AdvertisementメッセージホームAddress=エージェント=アドレスのMobilityエージェントAdvertisement ExtensionからコピーされたRegistration Lifetimeと等しい、Care、-、Addressが等しい、Care、-、AddressはRouter AdvertisementメッセージIdentification=ネットワークTimeプロトコルタイムスタンプかNonce ExtensionsのMobilityエージェントAdvertisement Extensionを回避しました: 移動住宅認証拡大
Perkins Standards Track [Page 74] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[74ページ]。
D.2. Registering with a Co-Located Care-of Address
D.2。 aへの登録が共同場所を見つけた、注意、-、アドレス
The mobile node enters a foreign network that contains no foreign agents. The mobile node obtains an address from a DHCP server [6] 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:
モバイルノードはどんな外国人のエージェントも含まない外国ネットワークに入ります。 モバイルノードがaとしての使用のための[6]が共同場所を見つけたDHCPサーバからアドレスを得る、注意、-、アドレス。 モバイルノードは、すべてのフォームのカプセル化(IPにおけるIP、最小量のカプセル化、およびGRE)を支えて、ホームネットワークでブロードキャスト・データグラムのコピーを望んでいて、同時の移動性結合を必要としません:
IP fields:
Source Address = care-of address obtained from DHCP server
Destination Address = IP address of home agent
Time to Live = 64
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=1,D=1,M=1,G=1
Lifetime = 1800 (seconds)
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = care-of address obtained from DHCP server
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home Authentication Extension
IP分野: ソースAddressが等しい、注意、-、ホームのエージェントTimeのDHCPサーバDestination Address=IPアドレスからLiveまで得られたアドレスは64のUDP分野と等しいです: ソースPortは434どんな>Destination Portも=Registration Requestがさばく<と等しいです: タイプ=1秒間=0、B=1、D=1、M=1、1800(秒)ホームG=1 Lifetime=AddressがモバイルノードのホームのエージェントのIPモバイルノードのホームアドレスホームのエージェント=アドレスと等しい、Care、-、Addressが等しい、注意、-、アドレスはDHCPサーバIdentification=からネットワークTimeプロトコルのタイムスタンプかNonce Extensionsを入手しました: 移動住宅認証拡大
Perkins Standards Track [Page 75] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[75ページ]。
D.3. Deregistration
D.3。 Deregistration
The mobile node returns home and wishes to deregister all care-of addresses with its home agent.
モバイルノードが家に帰って、「反-レジスタ」にすべてを願っている、注意、-、ホームのエージェントと共に扱います。
IP fields:
Source Address = mobile node's home address
Destination Address = IP address of home agent
Time to Live = 1
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=0,D=0,M=0,G=0
Lifetime = 0
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = the mobile node's home address
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home Authentication Extension
IP分野: ソースAddressはモバイルノードのホームの1LiveのエージェントTime=UDPの分野のホームアドレスDestination Address=IPアドレスと等しいです: ソースPortは434どんな>Destination Portも=Registration Requestがさばく<と等しいです: タイプ=1秒間=0、B=0、D=0、M=0、0ホームG=0 Lifetime=AddressがモバイルノードのホームのエージェントのIPモバイルノードのホームアドレスホームのエージェント=アドレスと等しい、Care、-、AddressはモバイルノードのホームアドレスIdentification=ネットワークTimeプロトコルタイムスタンプかNonce Extensionsと等しいです: 移動住宅認証拡大
E. Applicability of Prefix Lengths Extension
E。 接頭語長さの拡大の適用性
Caution is indicated with the use of the Prefix Lengths Extension over wireless links, due to the irregular coverage areas provided by wireless transmitters. As a result, it is possible that two foreign agents advertising the same prefix might indeed provide different connectivity to prospective mobile nodes. The Prefix-Lengths Extension SHOULD NOT be included in the advertisements sent by agents in such a configuration.
警告はワイヤレスのリンクの上にPrefix Lengths Extensionの使用によって示されます、ワイヤレスの送信機によって提供された不規則な適用範囲の地域のため。 その結果、本当に、同じ接頭語の広告を出す2人の外国人のエージェントが将来のモバイルノードに異なった接続性を提供するのは、可能です。 Prefix-長さのExtension SHOULD、そのような構成でエージェントによって送られた広告で含められないでください。
Perkins Standards Track [Page 76] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[76ページ]。
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".
異なったワイヤレスインターフェースを使用している外国人のエージェントは、同じ適用範囲をスペースに提供するのに特別なプロトコルを使用することで協力して、その結果、ワイヤレスインターフェースが同じサブネットワークの上に位置させていると主張できなければならないでしょう。 ワイヤードなインタフェースの場合では、新しい接着点は、モバイルノードに切断して、次に接続します、と同じ媒体の上に新しい広告があって、最終が広告を記録したので、新しいRegistration Requestはたぶん送るでしょう。 そして、最終的に、外国人のエージェントの密集した人口がある領域では、それぞれの個々のワイヤレスの外国人のエージェントに関連しているサブネット接頭語のルーティング・プロトコルで伝播を必要とするのが賢明でなく思えるでしょう。 そのような戦略は経路指定テーブルのための利用可能なスペースの迅速な減少につながるかもしれません、とルート(ほとんどいつも不要である)がワイヤレスの「サブネット」のために保存されるなら、時間の保証のない増加は処理ルーティングアップデート、およびルート選択のための、より長い決定時間のために必要としました。
References
参照
[1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[1] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。
[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] 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.
[3] ラモン・カセレスとLiviu Iftode。 モバイル・コンピューティング環境における、信頼できるトランスポート・プロトコルの性能を向上させます。 コミュニケーションの選択された領域に関するIEEEジャーナル、13(5): 850--857と、1995年6月。
[4] Deering, S., Editor, "ICMP Router Discovery Messages",
RFC 1256, September 1991.
[4] デアリング、S.、エディタ、「ICMPルータ発見メッセージ」、RFC1256、1991年9月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, August 1989.
[5] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
October 1993.
[6]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC1541、1993年10月。
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Requirements for Security", RFC 1750, December 1994.
1994年12月の[7] イーストレークとD.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性要件」RFC1750。
[8] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[8] ハンクスとS.と李とR.とファリナッチ、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC1701、1994年10月。
[9] Van Jacobson. Congestion Avoidance and Control. In Proceedings
of the SIGCOMM '88 Symposium: Communications Architectures &
Protocols, pages 314--329, August 1988.
[9] ジェーコブソンをバンに積んでください。 輻輳回避とコントロール。 SIGCOMM88年のシンポジウムの議事で: コミュニケーションArchitecturesとプロトコル、314--329ページ、1988年8月。
Perkins Standards Track [Page 77] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[77ページ]。
[10] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990.
[10] ジェーコブソン対RFC1144、「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」での1990年2月
[11] McCloghrie, K., and F. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", RFC 1573, January 1994.
[11]McCloghrie、K.、およびF.Kastenholz、「MIB-IIのインタフェースグループの発展」、RFC1573、1994年1月。
[12] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[12] マクレガー(G.、「pppインターネットプロトコル制御プロトコル(IPCP)」RFC1332)は1992がそうするかもしれません。
[13] Mills, D., "Network Time Protocol (Version 3):
Specification, Implementation and Analysis", RFC 1305, March
1992.
[13] 工場、D.、「ネットワーク時間は以下について議定書の中で述べ(バージョン3)」。 「仕様、実装、および分析」(RFC1305)は1992を行進させます。
[14] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[14] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[15] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[16] Plummer, D., "An Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to 48.bit Ethernet
Addresses for Transmission on Ethernet Hardware", STD 37,
RFC 826, November 1982.
[16] プラマー、D.、「イーサネットアドレス決議は以下について議定書の中で述べます」。 「または、ネットワーク・プロトコルを変換するのは、イーサネットハードウェアの上でイーサネットがトランスミッションのためのアドレスであると48.bitに扱う」STD37、RFC826、1982年11月。
[17] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[17] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[18] Postel, J., "Multi-LAN Address Resolution", RFC 925, October
1984.
[18] ポステル、J.、「マルチLANアドレス解決」、RFC925、1984年10月。
[19] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[19] ポステル、J.、エディタ、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[20] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[20] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[21] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[21] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[22] Simpson, W., Editor, "The Point-to-Point Protocol
(PPP)", STD 51, RFC 1661, July 1994.
[22] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[23] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The
Protocols. Addison-Wesley, Reading, Massachusetts, 1994.
[23] W.リチャード・スティーブンス。 例証されたTCP/IP、第1巻: プロトコル。 アディソン-ウエスリー、読書、マサチューセッツ、1994。
Perkins Standards Track [Page 78] RFC 2002 IP Mobility Support October 1996
パーキンスStandardsはIP移動性サポート1996年10月にRFC2002を追跡します[78ページ]。
Editor's Address
エディタのアドレス
Questions about this memo can also be directed to the editor:
また、このメモに関する質問をエディタに向けることができます:
Charles Perkins Room H3-D34 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532
チャールズパーキンス余地のH3-D34T.J.ワトソン研究所IBM社30の製材機械川の通り ホーソーン、ニューヨーク 10532
Work: +1-914-784-7350 Fax: +1-914-784-6205 EMail: perk@watson.ibm.com
仕事: +1-914-784-7350 Fax: +1-914-784-6205 メールしてください: perk@watson.ibm.com
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
ジムソロモンモトローラ1301E.アルゴンキン族通り スカンバーブ、イリノイ 60196
Work: +1-847-576-2753
EMail: solomon@comm.mot.com
仕事: +1-847-576-2753 メールしてください: solomon@comm.mot.com
Perkins Standards Track [Page 79]
パーキンス標準化過程[79ページ]
一覧
スポンサーリンク
