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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

text-autospace アルファベット等との間隔を指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る