Network Working Group J. Solomon
Request for Comments: 2290 Motorola
Updates: 2002 S. Glass
Category: Standards Track FTP Software
February 1998
Network Working Group J. Solomon
Request for Comments: 2290 Motorola
Updates: 2002 S. Glass
Category: Standards Track FTP Software
February 1998
Mobile-IPv4 Configuration Option for PPP IPCP
PPP IPCP的Mobile-IPv4配置选项
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed.
移动IP[RFC 2002]定义了与媒体无关的过程，通过该过程，移动节点可以保持现有的传输层和应用层连接，而无需更改其与Internet的连接点，也无需更改其IP地址。PPP[RFC1661]提供了通过点到点链路传输多协议数据包的标准方法。按照目前的规定，通过PPP支持移动节点连接的移动IP外部代理只能通过首先将唯一地址分配给这些移动节点来实现，这就破坏了外部代理的主要优势之一。本文档通过定义Internet协议控制协议（IPCP）[RFC 1332]的Mobile-IPv4配置选项来纠正此问题。使用此选项，两个对等方可以在PPP的IPCP阶段传递其对移动IP的支持。假设熟悉移动IP[RFC 2002]、IPCP[RFC 1332]和PPP[RFC 1661]。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification Language . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . 3
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2. Mobile-IPv4 Configuration Option . . . . . . . . . . . . . . . 6
2.1. Option Format . . . . . . . . . . . . . . . . . . . . . 6
2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification Language . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . 3
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2. Mobile-IPv4 Configuration Option . . . . . . . . . . . . . . . 6
2.1. Option Format . . . . . . . . . . . . . . . . . . . . . 6
2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. High-Level Requirements for Non-Mobile-Nodes . . . . . . 7
2.4. High-Level Requirements for Mobile Nodes . . . . . . . . 8
2.5. Detailed Description . . . . . . . . . . . . . . . . . . 8
2.6. Example Scenarios . . . . . . . . . . . . . . . . . . . 12
3. Additional Requirements . . . . . . . . . . . . . . . . . . . 14
3.1. Other IPCP Options . . . . . . . . . . . . . . . . . . . 14
3.2. Move Detection . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
2.3. High-Level Requirements for Non-Mobile-Nodes . . . . . . 7
2.4. High-Level Requirements for Mobile Nodes . . . . . . . . 8
2.5. Detailed Description . . . . . . . . . . . . . . . . . . 8
2.6. Example Scenarios . . . . . . . . . . . . . . . . . . . 12
3. Additional Requirements . . . . . . . . . . . . . . . . . . . 14
3.1. Other IPCP Options . . . . . . . . . . . . . . . . . . . 14
3.2. Move Detection . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
Mobile IP [RFC 2002] defines protocols and procedures by which packets can be routed to a mobile node, regardless of its current point-of-attachment to the Internet, and without changing its IP address. Mobile IP is designed to run over any type of media and any type of data link-layer. However, the interaction between Mobile IP and PPP is currently underspecified and generally results in an inappropriate application of Mobile IP when mobile nodes connect to the Internet via PPP.
移动IP[RFC 2002]定义了协议和过程，通过这些协议和过程，数据包可以路由到移动节点，而不管其当前连接到Internet的点如何，并且不改变其IP地址。移动IP设计用于在任何类型的媒体和任何类型的数据链路层上运行。然而，移动IP和PPP之间的交互目前还不明确，通常会导致当移动节点通过PPP连接到互联网时，移动IP的应用不适当。
This document defines proper interaction between a mobile node [RFC 2002] and a peer through which the mobile node connects to the Internet using PPP. This requires the definition of a new option for IPCP [RFC 1332], named the "Mobile-IPv4" Configuration Option, which is defined in this document. The mobile node and the peer use this option to negotiate the appropriate use of Mobile IP over the PPP link.
本文档定义了移动节点[RFC 2002]与对等方之间的适当交互，移动节点通过该对等方使用PPP连接到互联网。这需要为IPCP[RFC 1332]定义一个新选项，名为“Mobile-IPv4”配置选项，该选项在本文档中定义。移动节点和对等方使用此选项通过PPP链路协商移动IP的适当使用。
The Mobile-IPv4 option defined in this document is intended to work in conjunction with the existing IP-Address option [RFC 1332].
本文档中定义的Mobile-IPv4选项旨在与现有IP地址选项[RFC 1332]配合使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
This document uses the following terms as defined in [RFC 2002]:
本文件使用[RFC 2002]中定义的以下术语：
Mobile Node
移动节点
A host or router that changes its point-of-attachment from one link 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 (permanent) home, IP address, assuming link-layer connectivity is available at its current location.
将其连接点从一条链路更改为另一条链路的主机或路由器。移动节点可以在不改变其IP地址的情况下改变其位置；假设链路层连接在其当前位置可用，则它可以使用其（永久）主IP地址继续与任何位置的其他Internet节点通信。
Home Agent
国内代理
A router with at least one interface on a mobile node's home link. A home agent intercepts packets destined to a mobile node's home address and tunnels them to the mobile node's care-of address when the mobile node is connected to a foreign link. A mobile node informs its home agent of its current care-of address through an authenticated registration protocol defined by Mobile IP.
在移动节点的主链路上至少有一个接口的路由器。当移动节点连接到外部链路时，归属代理截获目的地为移动节点的归属地址的分组，并将其隧道至移动节点的转交地址。移动节点通过移动IP定义的认证注册协议通知其归属代理其当前转交地址。
Foreign Agent
外国代理人
A router with at least one interface on a mobile node's (current) foreign link. When a mobile node uses a foreign agent's care-of address, the foreign agent detunnels and delivers packets to the mobile node that were tunneled by the mobile node's home agent. A foreign agent might also serve as a default router for packets sent by a registered mobile node.
在移动节点（当前）的外部链路上至少有一个接口的路由器。当移动节点使用外部代理的转交地址时，外部代理将取消传输并向移动节点发送由移动节点的归属代理通过隧道传输的数据包。外部代理还可以用作注册移动节点发送的数据包的默认路由器。
Peer
同龄人
The PPP peer of a mobile node. The mobile node's peer might support home agent functionality, foreign agent functionality, both, or neither.
移动节点的PPP对等方。移动节点的对等方可能同时支持归属代理功能和外部代理功能，或者两者都不支持。
In Mobile IP, packets sent to a mobile node's home address are routed first to the mobile node's home agent, a router on the mobile node's home link which intercepts packets sent to the home address. The home agent then tunnels such packets to the mobile node's care-of address, where the packets are extracted from the tunnel and delivered to the mobile node. There are two types of care-of addresses:
在移动IP中，发送到移动节点的家庭地址的数据包首先被路由到移动节点的家庭代理，移动节点的家庭链路上的路由器拦截发送到家庭地址的数据包。归属代理然后通过隧道将这些分组传送到移动节点的转交地址，在该地址，分组从隧道中提取并传送到移动节点。有两种类型的转交地址：
Co-located Care-of Address
同处照管地址
An address temporarily assigned to a mobile node itself. In this case, the mobile node is the exit-point of the tunnel and decapsulates packets encapsulated for delivery by its home agent. A Co-located Care-of Address may be used by exactly one mobile node at any point in time.
临时分配给移动节点本身的地址。在这种情况下，移动节点是隧道的出口点，并且解除封装以由其归属代理递送的分组的封装。一个共同定位的转交地址可以在任何时间点被恰好一个移动节点使用。
Foreign Agent Care-of Address
外国代理人转交地址
An address of a foreign agent that has at least one interface on a mobile node's visited, foreign link. In this case, the foreign agent decapsulates packets that have been tunneled by the home agent and delivers them to the mobile node over the visited link. A Foreign Agent Care-of Address may be used simultaneously by many mobile nodes at any point in time.
外部代理的地址，在移动节点访问的外部链路上至少有一个接口。在这种情况下，外部代理对由归属代理通过隧道传输的数据包进行解封，并通过访问的链路将其传送到移动节点。外部代理转交地址可由多个移动节点在任何时间点同时使用。
In Appendix B, Mobile IP [RFC 2002] currently specifies only the following with respect to PPP:
在附录B中，移动IP[RFC 2002]目前仅就PPP规定了以下内容：
"The Point-to-Point-Protocol (PPP) [RFC 1661] and its Internet Protocol Control Protocol (IPCP) [RFC 1332], negotiates [sic] the use of IP addresses.
“点对点协议（PPP）[RFC 1661]及其互联网协议控制协议（IPCP）[RFC 1332]协商[原文如此]IP地址的使用。
"The mobile node SHOULD first attempt to specify its home address, so that if the mobile node is attaching to its home [link], 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."
“移动节点应首先尝试指定其家庭地址，以便如果移动节点连接到其家庭[链接]，未路由的链路将正常工作。当对等方不接受家庭地址，但动态地将临时IP地址分配给移动节点，并且移动节点能够支持同一位置的转交地址时，移动节点可以将该地址注册为同一位置的转交地址。当对等方指定自己的地址时IP地址，该地址不得假定为外国代理托管地址或本国代理的IP地址。”
Inspection of this text reveals that there is currently no way for the mobile node to use a foreign agent care-of address, without first being assigned a unique IP address, even if the peer also supports foreign agent functionality. The reason for this can be seen by walking through the IPCP negotiation:
对该文本的检查表明，当前移动节点无法在不首先分配唯一IP地址的情况下使用外部代理转交地址，即使对等方也支持外部代理功能。通过IPCP谈判可以看出原因：
1. A mobile node connects to a peer via PPP and proposes its home address in an IPCP Configure-Request containing the IP-Address option. In this scenario, we assume that the mobile node is connecting to some foreign link.
1. 移动节点通过PPP连接到对等方，并在包含IP地址选项的IPCP配置请求中提出其家庭地址。在此场景中，我们假设移动节点正在连接到某个外部链路。
2. The peer has no way of knowing whether this Configure-Request was received from: (a) a mobile node proposing its home address; or (b) a conventional node proposing some topologically non-routable address. In this case, the peer must (conservatively) send a Configure-Nak of the IP-Address option supplying a topologically appropriate address for use by the node at the other end of the PPP link.
2. 对等方无法知道该配置请求是否来自：（a）提出其归属地址的移动节点；或者（b）提出某种拓扑上不可路由地址的传统节点。在这种情况下，对等方必须（保守地）发送IP地址选项的Configure Nak，该选项提供拓扑上合适的地址，供PPP链路另一端的节点使用。
3. The mobile node, in turn, has no way of knowing whether this Configure-Nak was received because the peer is a foreign agent being conservative, or because the peer does not implement Mobile IP at all. Therefore, the mobile node must (conservatively) assume that the peer does not implement Mobile IP and continue the negotiation of an IP address in IPCP, after which point the mobile node can use the assigned address as a co-located care-of address.
3. 反过来，移动节点无法知道是否接收到该配置Nak，因为对等方是保守的外部代理，或者因为对等方根本没有实现移动IP。因此，移动节点必须（保守地）假设对等方不实现移动IP，并继续IPCP中的IP地址协商，在此之后，移动节点可以使用分配的地址作为共同定位的转交地址。
Here we observe that, even if the mobile node's peer is a foreign agent and sends an Agent Advertisement to the mobile node after IPCP reaches the Opened state, the mobile node will still have negotiated a routable address in step 3, which it is likely already using as a co-located care-of address. This defeats the purpose of foreign agent care-of addresses, which are designed to be shared by multiple mobile nodes and to eliminate the need to assign a unique address to each mobile node.
在这里，我们观察到，即使移动节点的对等方是外部代理并且在IPCP达到打开状态之后向移动节点发送代理广告，移动节点仍将在步骤3中协商可路由地址，其很可能已经使用该地址作为共地照管地址。这违背了外部代理托管地址的目的，该地址被设计为由多个移动节点共享，并消除了为每个移动节点分配唯一地址的需要。
The purpose of this document is to specify the behavior of both ends of the PPP link when one or more of the PPP peers supports Mobile IP. Specifically, the design of the option and protocol defined in this document is based upon the following requirements:
本文档的目的是指定当一个或多个PPP对等点支持移动IP时，PPP链路两端的行为。具体而言，本文件中定义的选项和协议的设计基于以下要求：
1. The option and protocol described in this document must be backwards compatible with conventional nodes and their potential peers which do not implement this option nor any Mobile IP functionality.
1. 本文档中描述的选项和协议必须与传统节点及其潜在对等方向后兼容，这些节点既不实现此选项，也不实现任何移动IP功能。
2. The option and protocol described in this document must accommodate a variety of scenarios, minimally those provided in the examples of Section 2.6.
2. 本文件中描述的选项和协议必须适应各种场景，至少是第2.6节示例中提供的场景。
3. The option and protocol described in this document must not duplicate any functionality already defined in other IPCP options; specifically, the IP-Address option.
3. 本文件中描述的选项和协议不得与其他IPCP选项中已定义的任何功能重复；特别是IP地址选项。
4. A unique address must not be assigned to a mobile node unless absolutely necessary. Specifically, no such address is assigned to a mobile node that connects via PPP to its home link or a mobile node that connects via PPP to a foreign agent (and uses that foreign agent's care-of address).
4. 除非绝对必要，否则不得将唯一地址分配给移动节点。具体地说，没有将这样的地址分配给通过PPP连接到其主链路的移动节点或通过PPP连接到外部代理（并使用该外部代理的转交地址）的移动节点。
This section defines the Mobile-IPv4 Configuration Option and provides several examples of its use.
本节定义了Mobile-IPv4配置选项，并提供了几个使用示例。
The Mobile-IPv4 Configuration Option for IPCP is defined as follows:
IPCP的Mobile-IPv4配置选项定义如下：
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 | Mobile Node's ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Mobile Node's ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
4 (Mobile-IPv4)
4（移动IPv4）
Length
长
6 (The length of this entire extension in bytes)
6（整个扩展的长度，以字节为单位）
Mobile Node's Home Address
移动节点的主地址
In a Configure-Request, the IP home address of the mobile node sending this Configuration Option, otherwise the (unmodified) IP home address of the mobile node when sent in a Configure-Ack or Configure-Reject. Configure-Nak'ing this option is undefined and MUST NOT be sent by implementations complying with this version of the specification. This field MUST NOT be zero.
在配置请求中，发送此配置选项的移动节点的IP主地址，否则为在配置确认或配置拒绝中发送时移动节点的（未修改的）IP主地址。Configure-Nak’ing此选项未定义，并且不能由符合此版本规范的实现发送。此字段不能为零。
Default Value
默认值
The Mobile-IPv4 Configuration Option defaults to the sending mobile node's home address.
Mobile-IPv4配置选项默认为发送移动节点的家庭地址。
In describing the operation of the Mobile-IPv4 Configuration Option (in conjunction with the IP-Address Configuration Option), we use the following abbreviations:
在描述Mobile-IPv4配置选项（结合IP地址配置选项）的操作时，我们使用以下缩写：
PPP Message Types: Request = Configure-Request Reject = Configure-Reject Ack = Configure-Ack Nak = Configure-Nak
PPP消息类型：请求=配置请求拒绝=配置拒绝确认=配置确认Nak=配置Nak
IPCP Configuration Options: MIPv4 = Mobile-IPv4 IP = IP-Address
IPCP配置选项：MIPv4=Mobile-IPv4 IP=IP地址
IP addresses: a.b.c.d = some non-zero IP address w.x.y.z = some non-zero IP address other than a.b.c.d home = a mobile node's IP Home address coa = an IP Care-Of Address 0 = the all-zeroes IP address (0.0.0.0)
IP地址：a.b.c.d=一些非零IP地址w.x.y.z=除a.b.c.d home之外的一些非零IP地址=移动节点的IP home地址coa=IP托管地址0=全零IP地址（0.0.0）
The Mobile-IPv4 Configuration Option is designed to be used in conjunction with the IP-Address Configuration Option. For the convenience of implementors, the detailed description in section 2.5 includes all possible combinations of these two options that might be sent by a PPP peer during IPCP. Along with each possibility is a description of how the receiver should interpret the contents as well as a suggested course of action.
Mobile-IPv4配置选项旨在与IP地址配置选项结合使用。为方便实施者，第2.5节中的详细描述包括PPP对等方在IPCP期间可能发送的这两个选项的所有可能组合。在每种可能性的同时，还描述了接收者应如何解释内容以及建议的行动方案。
A node that is not performing mobile node functionality (such as non-Mobile-IP-aware nodes as well as nodes performing only home agent functionality, foreign agent functionality, or both) MUST NOT include a Mobile-IPv4 Configuration Option within any Configure-Request message. As per [RFC 1332], such a node SHOULD send a Configure-Request containing an IP-Address Configuration Option in which the IP-Address field is set to a non-zero IP address that the node has assigned to one of its interfaces. If an explicit IP address has been assigned to the node's PPP interface then this address SHOULD be sent in preference to any of the node's other addresses.
未执行移动节点功能的节点（例如非移动IP感知节点以及仅执行归属代理功能、外部代理功能或两者兼有的节点）不得在任何配置请求消息中包含mobile-IPv4配置选项。根据[RFC 1332]，此类节点应发送包含IP地址配置选项的配置请求，其中IP地址字段设置为非零IP地址，节点已分配给其接口之一。如果已将显式IP地址分配给节点的PPP接口，则该地址应优先于节点的任何其他地址发送。
A node MUST NOT send a Configure-Nak containing a Mobile-IPv4 Configuration Option. Doing so is currently "undefined" and might cause interoperability problems when a useful meaning for Configure-Nak is ultimately defined for the Mobile-IPv4 Configuration Option. A node that sends a Configure-Ack containing a Mobile-IPv4 Configuration Option SHOULD send an Agent Advertisement [RFC 2002] immediately upon IPCP for that link entering the Opened state.
节点不得发送包含Mobile-IPv4配置选项的配置Nak。这样做目前是“未定义的”，当最终为Mobile-IPv4配置选项定义了配置Nak的有用含义时，可能会导致互操作性问题。发送包含Mobile-IPv4配置选项的配置确认的节点应在该链路的IPCP进入打开状态时立即发送代理播发[RFC 2002]。
A mobile node SHOULD begin its IPCP negotiation by sending the Configure-Request described in either item #1 or item #4 in Section 2.5. The mobile node MAY begin its negotiation with one of the other numbered items in Section 2.5 under extenuating circumstances.
移动节点应通过发送第2.5节第#1项或第#4项中描述的配置请求开始其IPCP协商。在情有可原的情况下，移动节点可以开始与第2.5节中的其他编号项目之一进行协商。
A mobile node that receives a Configure-Ack containing a Mobile-IPv4 Configuration Option MUST receive an Agent Advertisement, possibly in response to an Agent Solicitation, before sending a Registration Request [RFC 2002] if that mobile node is connecting to a foreign link. This is because the peer might be a foreign agent that enforces a policy which requires a mobile node to register with that foreign agent even if the mobile node is using a co-located care-of address. A mobile node need not wait for such an advertisement if it connects to its home link. See item 7a in section 2.5 for one way in which a mobile node can determine if it has connected to its home link. Another way is by receiving an explicit notification of this fact from its peer, such as receipt of the messages in items 1b, 2c, and 3a in section 2.5.
接收包含mobile-IPv4配置选项的配置Ack的移动节点在发送注册请求[RFC 2002]之前，如果该移动节点正在连接到外部链路，则必须接收代理播发，这可能是对代理请求的响应。这是因为对等方可能是强制执行策略的外部代理，该策略要求移动节点向该外部代理注册，即使移动节点正在使用同一位置的转交地址。如果移动节点连接到其主链路，则不需要等待这样的广告。请参阅第2.5节中的第7a项，了解移动节点确定其是否已连接到其主链路的一种方法。另一种方法是从其对等方接收关于该事实的明确通知，例如接收第2.5节第1b、2c和3a项中的消息。
A mobile node that receives a Configure-Reject containing a Mobile-IPv4 Configuration Option SHOULD fall back to IPCP negotiation using the IP-Address option [RFC 1332]. A mobile node SHOULD begin this negotiation with Request(IP=home) or Request(IP=0), depending on whether or not the mobile node is connecting to its home link, respectively. A mobile node MAY make this determination by inspection of an IP-Address option contained within a Configure-Request sent by its peer. If the prefix of the peer's stated IP-address is equal to the prefix of the mobile node's home address, then the mobile node MAY conclude that it is connecting to its home link. Otherwise, if the mobile node is connecting to a foreign link, then the mobile node SHOULD send Request(IP=0) since its peer might have no means for assigning addresses other than IPCP. This specification therefore updates this behavior as described in [RFC 2002], the latter of which recommends that a mobile node begin IP-Address negotiation with Request(IP=Home) under all circumstances.
接收到包含mobile-IPv4配置选项的配置拒绝的移动节点应使用IP地址选项[RFC 1332]退回到IPCP协商。根据移动节点是否分别连接到其归属链路，移动节点应以请求（IP=home）或请求（IP=0）开始此协商。移动节点可以通过检查其对等方发送的配置请求中包含的IP地址选项来进行此确定。如果对等方的所述IP地址的前缀等于移动节点的归属地址的前缀，则移动节点可以断定其正在连接到其归属链路。否则，如果移动节点正在连接到外部链路，则移动节点应发送请求（IP=0），因为其对等方可能无法分配IPCP以外的地址。因此，本规范更新了[RFC 2002]中所述的行为，后者建议移动节点在所有情况下都使用请求（IP=Home）开始IP地址协商。
A peer that is performing neither home agent nor foreign agent functionality SHOULD send a Reject in response to any Request received from its peer that contains a Mobile-IPv4 Configuration Option.
既不执行归属代理功能也不执行外部代理功能的对等方应发送拒绝，以响应从其对等方收到的包含Mobile-IPv4配置选项的任何请求。
The numbered items below show all possible combinations of Mobile-IPv4 and IP-Address Configuration Options that a mobile node (or a conventional node) might send to its peer. Mobile nodes SHOULD begin
下面的编号项目显示了移动节点（或传统节点）可能发送给对等方的所有可能的移动IPv4和IP地址配置选项组合。移动节点应该开始
their IPCP negotiation with item #1 or item #4 depending on whether they prefer a co-located or a foreign agent care-of address respectively. The lettered items list the possible legal responses that a peer might send to the mobile node (or conventional node) in response to the numbered Request.
他们与第#1项或第#4项的IPCP谈判取决于他们分别选择同一地点还是外国代理托管地址。字母项目列出了对等方可能发送给移动节点（或传统节点）以响应编号请求的可能法律响应。
In each case, an interpretation is defined and a suggested course of action is provided. Finally, it is believed that the presentation below has the advantages of conciseness and precision in comparison to an equivalent presentation in "prose form."
在每种情况下，都定义了解释，并提供了建议的行动方案。最后，我们认为，与“散文形式”中的等效表达相比，下面的表达具有简洁和精确的优势
1. Request(IP=0,MIPv4=home) means "I prefer a co-located care-of address to a foreign agent care-of address." Peer MUST respond with one of the following:
1. 请求（IP=0，MIPv4=home）意味着“我更喜欢同一地点的转交地址，而不是外国代理的转交地址。”对等方必须使用以下其中一项进行响应：
a. Nak(IP=coa) means "use coa as your co-located care-of address". Goto 2. b. Nak(IP=home) means "you're at home and don't need a care-of address". Goto 3. c. Reject(IP=0) means "I cannot assign a co-located care-of address but you're welcome to use me as a foreign agent". Goto 4. d. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4 option". If the peer also sent Request(IP=address) and the prefix of the peer's assigned address is equal to that of the mobile node's home address, then goto 6 with a.b.c.d=home; otherwise, goto 5. e. Reject(IP=0,MIPv4=home) means "use the default". Goto 7.
a. Nak（IP=coa）表示“使用coa作为您的共同托管地址”。转到2。BNak（IP=home）的意思是“你在家，不需要托管地址”。转到3。C拒绝（IP=0）表示“我无法指定同一地点的转交地址，但欢迎您将我用作外国代理人”。转到4。D拒绝（MIPv4=home）表示“我没有实现移动IPv4选项”。如果对等方也发送了请求（IP=地址），并且对等方分配的地址的前缀等于移动节点的家庭地址的前缀，则转到6，a.b.c.d=家庭；否则，转到5。E拒绝（IP=0，MIPv4=home）表示“使用默认值”。转到7。
=> Ack(IP=0, ...), Nak(MIPv4=any, ...) MUST NOT be sent.
=>Ack（IP=0，…），Nak（MIPv4=any，…）不得发送。
2. Request(IP=coa,MIPv4=home) means "I want to use coa as my co-located care-of address." Peer MUST respond with one of the following:
2. 请求（IP=coa，MIPv4=home）表示“我想使用coa作为我的同处照管地址”。对等方必须使用以下其中一项进行响应：
a. Ack(IP=coa,MIPv4=home) means "ok, use coa as your co-located care-of address; be sure to wait for an advertisement." Opened. b. Nak(IP=alternate-coa) means "no, use alternate-coa as your co-located care-of address". Goto 2. c. Nak(IP=home) means "you're at home and don't need a co-located care-of address". Goto 3. d. Reject(IP=coa) means "coa is not a useful value for a co-located care-of address on this link and I cannot assign a useful one (or I will not negotiate the IP-Address option) -- you may use me as a foreign agent". Goto 4.
a. Ack（IP=coa，MIPv4=home）表示“好的，使用coa作为您的共同托管地址；请务必等待广告。”。BNak（IP=alternate coa）表示“否，使用alternate coa作为您的共同托管地址”。转到2。CNak（IP=home）的意思是“你在家，不需要一个同一地点的看护地址”。转到3。D拒绝（IP=coa）意味着“coa对于此链接上的同处转交地址不是有用的值，我无法分配有用的值（或者我不会协商IP地址选项）——您可以将我用作外部代理”。转到4。
e. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4 option". If the peer also sent Request(IP=address) and the prefix of the peer's address is equal to that of the mobile node's home address, then goto 6 with a.b.c.d=home; otherwise, goto 5. f. Reject(IP=coa,MIPv4=home) means "use the default". Goto 7.
e. 拒绝（MIPv4=home）表示“我没有实现移动IPv4选项”。如果对等方也发送了请求（IP=地址），并且对等方地址的前缀等于移动节点的家庭地址的前缀，则转到6，a.b.c.d=家庭；否则，转到5。F拒绝（IP=coa，MIPv4=home）表示“使用默认值”。转到7。
=> Nak(MIPv4=any, ...) MUST NOT be sent.
=>Nak（MIPv4=any，…）不能发送。
3. Request(IP=home,MIPv4=home) means "I think I'm at home but if I'm wrong then I prefer a co-located care-of address to a foreign agent care-of address." Peer MUST respond with one of the following:
3. 请求（IP=home，MIPv4=home）表示“我认为我在家，但如果我错了，那么我更喜欢同一地点的转交地址，而不是外国代理的转交地址。”对等方必须回答以下问题之一：
a. Ack(IP=home,MIPv4=home) means "yes, you're at home". Opened. b. Nak(IP=coa) means "you're not at home, use coa as your co-located care-of address". Goto 2. c. Reject(IP=home) means "you're not at home and I cannot assign a co-located care-of address (or I will not negotiate the IP-Address option) -- you may use me as a foreign agent". Goto 4. d. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4 option". If the peer also sent Request(IP=address) and the prefix of the peer's address is equal to that of the mobile node's home address, then goto 6 with a.b.c.d=home; otherwise, goto 5. e. Reject(IP=home,MIPv4=home) means "use the default". Goto 7.
a. Ack（IP=home，MIPv4=home）表示“是的，您在家”。开的。BNak（IP=coa）的意思是“您不在家，请使用coa作为您的共同托管地址”。转到2。C拒绝（IP=home）表示“您不在家，我无法分配同一地点的转交地址（或者我不会协商IP地址选项）——您可以将我用作外国代理”。转到4。D拒绝（MIPv4=home）表示“我没有实现移动IPv4选项”。如果对等方也发送了请求（IP=地址），并且对等方地址的前缀等于移动节点的家庭地址的前缀，则转到6，a.b.c.d=家庭；否则，转到5。E拒绝（IP=home，MIPv4=home）表示“使用默认值”。转到7。
=> Nak(MIPv4=any, ...) MUST NOT be sent.
=>Nak（MIPv4=any，…）不能发送。
4. Request(MIPv4=home) means "I want to run Mobile IP over this link and I don't want a co-located care-of address." Peer MUST respond with one of the following:
4. 请求（MIPv4=home）表示“我想通过此链接运行移动IP，但我不想使用同一位置的转交地址。”对等方必须使用以下其中一项进行响应：
a. Ack(MIPv4=home) means "ok, wait for an advertisement to figure out where you are." Opened. b. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4 option". If the peer also sent Request(IP=address) and the prefix of the peer's address is equal to that of the mobile node's home address, then goto 6 with a.b.c.d=home; otherwise, goto 5.
a. Ack（MIPv4=home）表示“好的，等待广告来确定您的位置。”打开。B拒绝（MIPv4=home）表示“我没有实现移动IPv4选项”。如果对等方也发送了请求（IP=地址），并且对等方地址的前缀等于移动节点的家庭地址的前缀，则转到6，a.b.c.d=家庭；否则，转到5。
=> Nak(MIPv4=any, ...) MUST NOT be sent.
=>Nak（MIPv4=any，…）不能发送。
5. Request(IP=0) means "Please assign an address/co-located-care-of-address". Peer MUST respond with one of the following:
5. 请求（IP=0）表示“请分配一个地址/同处转交地址”。对等方必须使用以下选项之一进行响应：
a. Nak(IP=a.b.c.d) means "use a.b.c.d as your address/co-located-care-of-address". Goto 6. b. Reject(IP=0) means "I cannot assign an address (for the Mobile Node to use as a co-located-care-of-address), or I do not implement the IP-Address option". Goto 7.
a. Nak（IP=a.b.c.d）是指“使用a.b.c.d作为您的地址/共同托管地址”。转到6。B拒绝（IP=0）表示“我无法分配地址（用于移动节点用作同一位置的转交地址），或者我没有实现IP地址选项”。转到7。
=> Ack(IP=0) MUST NOT be sent and historically means "I don't know your address either". Opened. An implementation MUST NOT use 0 as its IP address upon receiving Ack(IP=0) but MAY use some other, non-zero, interface address for packets sent on its PPP interface.
=>Ack（IP=0）不能发送，历史上表示“我也不知道您的地址”。开的。一个实现在接收到Ack（IP=0）时不能使用0作为其IP地址，但可以为在其PPP接口上发送的数据包使用一些其他非零接口地址。
6. Request(IP=a.b.c.d) means "I want to use a.b.c.d as my address/home-address/co-located-care-of-address". Peer MUST respond with one of the following:
6. 请求（IP=a.b.c.d）表示“我想使用a.b.c.d作为我的地址/家庭地址/共同寄存地址”。对等方必须使用以下选项之一进行响应：
a. Ack(IP=a.b.c.d) means "ok, a.b.c.d is your address/home-address/co-located-care-of-address". Opened. b. Nak(IP=w.x.y.z) means "no, use w.x.y.z as your address/home-address/co-located-care-of-address". Goto 6. c. Reject(IP=a.b.c.d) means "a.b.c.d is a bad address to use, but I cannot give you a good one" or "I do not implement the IP-Address option". Goto 7.
a. 确认（IP=a.b.c.d）表示“好的，a.b.c.d是您的地址/家庭地址/共同寄存地址”。开的。BNak（IP=w.x.y.z）表示“不，使用w.x.y.z作为您的地址/家庭地址/共同寄存地址”。转到6。C拒绝（IP=a.b.c.d）表示“a.b.c.d地址不好用，但我不能给你一个好地址”或“我没有实现IP地址选项”。转到7。
7. Request() means "I want to use the default". Peer MUST respond with one of the following:
7. Request（）表示“我想使用默认值”。对等方必须使用以下选项之一进行响应：
a. Ack() means "ok, use the default". Opened.
a. Ack（）表示“确定，使用默认值”。开的。
In this case the mobile node will use the "default" values of the IP-Address option (no address configured by IPCP) and the Mobile-IPv4 option (the mobile node's IP home address). The mobile node SHOULD send Agent Solicitations to see if there are any agents present on the current link. (Note that the current "link" might also include a shared medium if the mobile node's PPP peer is a bridge.) If an agent is present and the mobile node receives an Agent Advertisement, then the mobile node employs its move-detection algorithm(s) and registers accordingly.
在这种情况下，移动节点将使用IP地址选项（IPCP未配置地址）和mobile-IPv4选项（移动节点的IP主地址）的“默认”值。移动节点应发送代理请求，以查看当前链路上是否存在任何代理。（注意，如果移动节点的PPP对等方是网桥，则当前“链路”还可以包括共享介质。）如果存在代理并且移动节点接收代理广告，则移动节点使用其移动检测算法并相应地注册。
In any case, if the mobile node's peer supplied an IP-Address option containing a non-zero value within an IPCP Configure-Request, the mobile node MAY use this address to determine whether or not it is connected to its home link. This can be accomplished by comparing the stated IP address with the mobile node's home address under the prefix-length associated with the home link. If the mobile node is connected to its home link then it SHOULD de-register with its home agent.
在任何情况下，如果移动节点的对等方在IPCP配置请求中提供了包含非零值的IP地址选项，则移动节点可以使用该地址来确定其是否连接到其主链路。这可以通过在与归属链路相关联的前缀长度下将所述IP地址与移动节点的归属地址进行比较来实现。如果移动节点连接到其归属链路，则应向其归属代理注销。
Otherwise, the mobile node MAY attempt to obtain a topologically routable address through any of its supported means (e.g., DHCP, manual configuration, etc.) for use as a co-located care-of address. If the mobile node is successful in obtaining such an address then it SHOULD register this address with its home agent.
否则，移动节点可尝试通过其任何支持的手段（例如，DHCP、手动配置等）获得拓扑上可路由的地址，以用作共同定位的转交地址。如果移动节点成功地获得这样的地址，那么它应该向其归属代理注册该地址。
=> Nak(IP=0) MUST NOT be sent. Goto 6.
=>不能发送Nak（IP=0）。转到6。
=> Nak() MUST NOT be sent.
=>不能发送Nak（）。
=> Reject() MUST NOT be sent.
=>不能发送拒绝（）。
This section illustrates the use of the option and protocol as defined in the previous sections. In the examples which follow, a Configure-Request sent by a mobile node and the response generated by the peer are shown on the same line. The number and letter to the left of each request/response refer to the numbered and lettered items in Section 2.5.
本节说明了前几节中定义的选项和协议的使用。在下面的示例中，由移动节点发送的配置请求和由对等方生成的响应显示在同一行上。每个请求/响应左边的数字和字母指的是第2.5节中的编号和字母项目。
A. A mobile node prefers a co-located care-of address and the peer is a foreign agent that is capable of assigning such an address:
A.移动节点更喜欢位于同一位置的转交地址，并且对等方是能够分配此类地址的外部代理：
(1)(a) Request(IP=0,MIPv4=Home) / Nak(IP=coa)
(2)(a) Request(IP=coa,MIPv4=Home) / Ack(IP=coa,MIPv4=Home)
(1)(a) Request(IP=0,MIPv4=Home) / Nak(IP=coa)
(2)(a) Request(IP=coa,MIPv4=Home) / Ack(IP=coa,MIPv4=Home)
- Mobile node waits to receive an Agent Advertisement. - If (Advertisement has R-bit set) then Mobile node registers using co-located care-of address via the foreign agent; else Mobile node registers using co-located care-of address directly with its home agent.
- 移动节点等待接收代理播发。-如果（广告具有R位集），则移动节点通过外部代理使用同一位置的转交地址进行注册；else移动节点使用同一位置的转交地址直接向其归属代理注册。
B. A mobile node prefers a co-located care-of address and the peer is a foreign agent that cannot assign a co-located care-of address (e.g., it has no pool of addresses from which to allocate for the purpose of assignment):
B.移动节点更喜欢同一位置的转交地址，而对等方是无法分配同一位置转交地址的外部代理（例如，它没有用于分配的地址池）：
(1)(c) Request(IP=0,MIPv4=Home) / Reject(IP=0)
(4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)
(1)(c) Request(IP=0,MIPv4=Home) / Reject(IP=0)
(4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)
- IPCP completes. - Mobile node waits to receive an Agent Advertisement. - Mobile node registers using the peer's foreign agent care-of address with its home agent.
- IPCP完成移动节点等待接收代理播发。-移动节点使用对等方的外部代理转交地址向其归属代理注册。
C. A mobile node prefers a co-located care-of address and the peer determines that the mobile node's home address is such that the mobile node is connecting to its home link:
C.移动节点更喜欢位于同一位置的转交地址，并且对等方确定移动节点的家庭地址使得移动节点连接到其家庭链路：
(1)(b) Request(IP=0,MIPv4=Home) / Nak(IP=Home)
(3)(a) Request(IP=Home,MIPv4=Home) / Ack(IP=Home,MIPv4=Home)
(1)(b) Request(IP=0,MIPv4=Home) / Nak(IP=Home)
(3)(a) Request(IP=Home,MIPv4=Home) / Ack(IP=Home,MIPv4=Home)
- IPCP completes. - Mobile node de-registers with its home agent.
- IPCP完成移动节点向其归属代理注销。
D. A mobile node prefers a foreign agent care-of address and the peer is a foreign agent which finds this state of affairs satisfactory:
D.移动节点更喜欢外部代理转交地址，并且对等方是发现这种状态令人满意的外部代理：
(4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)
(4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)
- IPCP completes. - Mobile node waits to receive an Agent Advertisement. - Mobile node registers using the peer's foreign agent care-of or de-registers at home, depending on the values in the Agent Advertisement.
- IPCP完成移动节点等待接收代理播发。-根据代理广告中的值，移动节点使用对等方的外部代理进行注册或在家中注销。
E. A mobile node prefers a co-located care-of address and the peer does not implement the Mobile-IPv4 Configuration Option. The peer is, however, capable of assigning dynamic addresses:
E.移动节点更喜欢位于同一位置的转交地址，而对等方不实施mobile-IPv4配置选项。但是，对等方能够分配动态地址：
(1)(d) Request(IP=0,MIPv4=Home) / Reject(MIPv4=Home)
(5)(a) Request(IP=0) / Nak(IP=a.b.c.d)
(6)(a) Request(IP=a.b.c.d) / Ack(IP=a.b.c.d)
(1)(d) Request(IP=0,MIPv4=Home) / Reject(MIPv4=Home)
(5)(a) Request(IP=0) / Nak(IP=a.b.c.d)
(6)(a) Request(IP=a.b.c.d) / Ack(IP=a.b.c.d)
- IPCP completes. - Mobile node registers using a.b.c.d as a co-located care-of address with its home agent.
- IPCP完成移动节点使用a.b.c.d作为其归属代理的同一位置转交地址进行注册。
F. A mobile node prefers a co-located care-of address and the peer does not implement the Mobile-IPv4 Configuration Option. The peer is not capable of assigning dynamic addresses:
F.移动节点更喜欢同一位置的转交地址，而对等方不实施mobile-IPv4配置选项。对等方无法分配动态地址：
(1)(e) Request(IP=0,MIPv4=Home) / Reject(IP=0,MIPv4=Home)
(7)(a) Request() / Ack()
(1)(e) Request(IP=0,MIPv4=Home) / Reject(IP=0,MIPv4=Home)
(7)(a) Request() / Ack()
- IPCP completes. - Mobile node sends an Agent Solicitation and/or attempts to obtain a co-located care-of address via means outside IPCP (e.g., DHCP or manual configuration), or it gives up.
- IPCP完成移动节点通过IPCP之外的方式（例如，DHCP或手动配置）发送代理请求和/或尝试获取共同定位的转交地址，或者放弃。
A mobile node MUST NOT include the deprecated IP-Addresses option in any Configure-Request that contains a Mobile-IPv4 option, an IP-Address option, or both.
移动节点不得在任何包含mobile-IPv4选项、IP地址选项或两者的配置请求中包含不推荐的IP地址选项。
Conversely, the mobile node MAY include an IP-Compression-Protocol option and any other options that do not involve the negotiation of IP addresses.
相反，移动节点可以包括IP压缩协议选项和不涉及IP地址协商的任何其他选项。
If a mobile node and a foreign agent or a home agent agree in IPCP to use Van Jacobson Header Compression [RFC 1144], then the mobile node MUST NOT set the 'V' bit in its ensuing Mobile IP Registration Request [RFC 2002]. If the PPP peer entities are utilizing VJ header compression there is no gain for the mobile ip entities to do so, and requesting this option is likely to cause confusion.
如果移动节点和外部代理或本地代理在IPCP中同意使用Van Jacobson报头压缩[RFC 1144]，则移动节点不得在随后的移动IP注册请求[RFC 2002]中设置“V”位。如果PPP对等实体正在利用VJ报头压缩，那么移动ip实体这样做没有好处，请求此选项可能会导致混淆。
Mobile nodes that connect via PPP MUST correctly implement PPP's IPCP, since movement by the mobile node will likely change its PPP peer. Specifically, mobile nodes MUST be prepared to renegotiate IPCP at any time, including, the renegotiation of the IP-Address Configuration Option and the Mobile-IPv4 Configuration Option described in this document. As per [RFC 1661], a mobile node in the Opened state MUST renegotiate IPCP upon receiving an IPCP Configure-Request from its peer.
通过PPP连接的移动节点必须正确实现PPP的IPCP，因为移动节点的移动可能会改变其PPP对等方。具体而言，移动节点必须随时准备重新协商IPCP，包括重新协商本文档中描述的IP地址配置选项和mobile-IPv4配置选项。根据[RFC 1661]，处于开放状态的移动节点必须在收到来自其对等方的IPCP配置请求时重新协商IPCP。
Also note that certain wireless links can employ handoff and proxying mechanisms that would not necessarily require bringing down a PPP link but would indeed require a mobile node to register with a new foreign agent. Therefore, mobile nodes which connect to an agent via PPP MUST employ their move detection algorithms (see section 2.4.2 in [RFC 2002]) and register whenever they detect a change in connectivity.
还请注意，某些无线链路可以采用切换和代理机制，这些机制不一定需要关闭PPP链路，但确实需要移动节点向新的外部代理注册。因此，通过PPP连接到代理的移动节点必须采用其移动检测算法（见[RFC 2002]第2.4.2节），并在检测到连接变化时进行注册。
Specifically, a mobile node that fails to receive an Agent Advertisement within the Lifetime advertised by its current foreign agent, MUST assume that it has lost contact with that foreign agent (see Section 2.4.2.1, [RFC 2002]). If, in the mean time, the mobile node has received Agent Advertisements from another foreign agent, the mobile node SHOULD immediately register with that foreign agent upon timing out with its current foreign agent.
具体而言，在其当前外部代理发布的生命周期内未能接收代理发布的移动节点必须假定其已与该外部代理失去联系（参见第2.4.2.1节[RFC 2002]）。如果同时移动节点已从另一个外部代理接收代理广告，则移动节点应在其当前外部代理超时时立即向该外部代理注册。
Likewise, a mobile node that implements move detection based upon the Prefix-Length Extension MUST compare the prefix of any advertising agents with that of its current foreign agent (see Section 2.4.2.2, [RFC 2002]). If such a mobile node receives an Agent Advertisement from a foreign agent specifying a different prefix than that of its current foreign agent, then the mobile node that employs this method of move detection MUST register with that new foreign agent.
同样，基于前缀长度扩展实现移动检测的移动节点必须将任何广告代理的前缀与其当前外部代理的前缀进行比较（参见第2.4.2.2节[RFC 2002]）。如果这样的移动节点从指定不同于其当前外部代理前缀的前缀的外部代理接收代理广告，则采用这种移动检测方法的移动节点必须向该新的外部代理注册。
A mobile node MAY treat PPP link-establishment as a sufficient reason to proceed with a new Mobile IP registration. Section 2 defines the circumstances under which mobile nodes MUST wait for an Agent Advertisement before registering. Accordingly, foreign agents and home agents SHOULD send an Agent Advertisement over a PPP link immediately after IPCP for that link enters the Opened state.
移动节点可以将PPP链路建立视为继续进行新的移动IP注册的充分理由。第2节定义了移动节点在注册前必须等待代理广告的情况。因此，外国代理和本国代理应在PPP链接的IPCP进入开放状态后立即通过PPP链接发送代理广告。
This document introduces no known security threats over and above those facing any node on the Internet that either connects via PPP or implements Mobile IP or both. Specifically, service providers should use cryptographically strong authentication (e.g., CHAP [RFC 1994]) to prevent theft-of-service. Additionally, users requiring confidentiality should use PPP link encryption [RFC 1968], IP-layer encryption [RFC 1827], or application-layer encryption, depending upon their individual requirements. Finally, Mobile IP authentication [RFC 2002] protects against trivial denial-of-service attacks that could otherwise be waged against a mobile node and its home agent.
除了通过PPP连接或实施移动IP或两者兼而有之的Internet上的任何节点所面临的安全威胁之外，本文档不介绍任何已知的安全威胁。具体而言，服务提供商应使用加密强身份验证（例如，CHAP[RFC 1994]）来防止服务被盗。此外，需要保密的用户应根据各自的要求使用PPP链路加密[RFC 1968]、IP层加密[RFC 1827]或应用层加密。最后，移动IP认证[RFC 2002]可以防止可能针对移动节点及其归属代理发起的轻微拒绝服务攻击。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, January 1990.
[RFC 1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC 1144，1990年1月。
[RFC 1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)," RFC 1332, May 1992.
[RFC 1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC 1332，1992年5月。
[RFC 1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links", STD 51, RFC 1661, July 1994.
[RFC 1661]辛普森，W.编辑，“通过点对点链路传输多协议数据报的点对点协议（PPP）”，STD 51，RFC 1661，1994年7月。
[RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[RFC 1827]阿特金森，R.，“IP封装安全有效载荷（ESP）”，RFC 1827，1995年8月。
[RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC 1994]辛普森，W，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC 1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC 1968]Meyer，G.“PPP加密控制协议（ECP）”，RFC 1968，1996年6月。
[RFC 2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1996.
[RFC 2002]Perkins，C.，编辑，“IP移动支持”，RFC 2002，1996年10月。
The design of this protocol and option were inspired by an earlier submission by B. Patel and C. Perkins, then of IBM, in a now expired internet draft. Also, some of William Simpson's text was copied verbatim from [RFC 1661] in order to ensure consistency of terminology and specification. The same goes for some of Charlie Perkins' definitions, and other relavent text, from [RFC 2002].
该协议和选项的设计灵感来自于当时IBM的B.Patel和C.Perkins在一份现已过期的互联网草案中提交的早期文件。此外，为了确保术语和规范的一致性，威廉·辛普森（William Simpson）的一些文本是从[RFC 1661]一字不差地复制过来的。查理·帕金斯（Charlie Perkins）的一些定义以及[RFC 2002]中的其他相关文本也是如此。
Tim Wilson and Chris Stanaway (Motorola) contributed significantly to the design of this Configuration Option and protocol specification. Special thanks to Vernon Schryver (SGI), Craig Fox (Cisco), Karl Fox (Ascend), and John Bray (FTP) for their helpful suggestions, comments, and patience.
Tim Wilson和Chris Stanaway（摩托罗拉）对该配置选项和协议规范的设计做出了重大贡献。特别感谢Vernon Schryver（SGI）、Craig Fox（Cisco）、Karl Fox（Ascend）和John Bray（FTP）提供的有益建议、意见和耐心。
Jim Solomon Motorola, Inc. 1301 E. Algonquin Rd. - Rm 2240 Schaumburg, IL 60196
吉姆·所罗门·摩托罗拉公司，地址：伊利诺伊州绍姆堡市阿尔冈金东路1301号2240室，邮编60196
Phone: +1-847-576-2753
Fax: +1-847-576-3240
EMail: solomon@comm.mot.com
Phone: +1-847-576-2753
Fax: +1-847-576-3240
EMail: solomon@comm.mot.com
Steven Glass FTP Software, Inc. 2 High Street North Andover, MA 01845
史蒂文·格拉斯FTP软件公司，地址：马萨诸塞州安多弗北高街2号，邮编：01845
Phone: +1-508-685-4000
Fax: +1-508-684-6105
EMail: glass@ftp.com
Phone: +1-508-685-4000
Fax: +1-508-684-6105
EMail: glass@ftp.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。