Internet Engineering Task Force (IETF) H. Deng
Request for Comments: 6098 China Mobile
Category: Standards Track H. Levkowetz
ISSN: 2070-1721 Netnod
V. Devarapalli
Vasona Networks
S. Gundavelli
Cisco
B. Haley
Hewlett-Packard Company
April 2012
Internet Engineering Task Force (IETF) H. Deng
Request for Comments: 6098 China Mobile
Category: Standards Track H. Levkowetz
ISSN: 2070-1721 Netnod
V. Devarapalli
Vasona Networks
S. Gundavelli
Cisco
B. Haley
Hewlett-Packard Company
April 2012
Generic Notification Message for Mobile IPv4
移动IPv4的通用通知消息
Abstract
摘要
This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose.
本文档指定了协议增强功能，允许移动IPv4实体使用为此目的设计的移动IPv4消息类型发送和接收显式通知消息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6098.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6098.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Notification Message - Usage Scenarios ..........................4
3.1. Notification Message - Examples ............................4
3.2. Notification Message - Topology ............................5
3.2.1. Notification Message between a Home Agent
and a Mobile Node ...................................6
3.2.2. Notification Message between a Foreign Agent
and a Mobile Node ...................................6
3.2.3. Notification Message between a Home Agent
and a Foreign Agent .................................7
4. Generic Notification Message and Considerations .................7
4.1. Generic Notification Message ...............................7
4.2. Generic Notification Acknowledgement Message ..............11
4.3. Notification Retransmission ...............................14
4.4. General Implementation Considerations .....................15
4.5. Mobile Node Considerations ................................15
4.5.1. Receiving Generic Notification Messages ............15
4.5.2. Sending Generic Notification
Acknowledgement Messages ...........................16
4.5.3. Sending Generic Notification Messages ..............17
4.5.4. Receiving Generic Notification
Acknowledgement Messages ...........................18
4.6. Foreign Agent Consideration ...............................18
4.6.1. Receiving Generic Notification Messages ............19
4.6.2. Sending Generic Notification
Acknowledgement Messages ...........................21
4.6.3. Sending Generic Notification Messages ..............21
4.6.4. Receiving Generic Notification
Acknowledgement Messages ...........................22
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Notification Message - Usage Scenarios ..........................4
3.1. Notification Message - Examples ............................4
3.2. Notification Message - Topology ............................5
3.2.1. Notification Message between a Home Agent
and a Mobile Node ...................................6
3.2.2. Notification Message between a Foreign Agent
and a Mobile Node ...................................6
3.2.3. Notification Message between a Home Agent
and a Foreign Agent .................................7
4. Generic Notification Message and Considerations .................7
4.1. Generic Notification Message ...............................7
4.2. Generic Notification Acknowledgement Message ..............11
4.3. Notification Retransmission ...............................14
4.4. General Implementation Considerations .....................15
4.5. Mobile Node Considerations ................................15
4.5.1. Receiving Generic Notification Messages ............15
4.5.2. Sending Generic Notification
Acknowledgement Messages ...........................16
4.5.3. Sending Generic Notification Messages ..............17
4.5.4. Receiving Generic Notification
Acknowledgement Messages ...........................18
4.6. Foreign Agent Consideration ...............................18
4.6.1. Receiving Generic Notification Messages ............19
4.6.2. Sending Generic Notification
Acknowledgement Messages ...........................21
4.6.3. Sending Generic Notification Messages ..............21
4.6.4. Receiving Generic Notification
Acknowledgement Messages ...........................22
4.7. Home Agent Consideration ..................................23
4.7.1. Sending Generic Notification Messages ..............23
4.7.2. Receiving Generic Notification
Acknowledgement Messages ...........................24
4.7.3. Receiving Generic Notification Messages ............24
4.7.4. Sending Generic Notification
Acknowledgement Messages ...........................26
5. Future Extensibility ...........................................26
5.1. Examples of Possible Extensions ...........................26
5.2. Extension Specification ...................................27
6. IANA Considerations ............................................28
7. Security Considerations ........................................28
7.1. Replay Protection for GNMs and GNAMs ......................29
7.1.1. Replay Protection Using Timestamps .................29
7.1.2. Replay Protection Using Nonces .....................30
7.2. Non-Authentication Extensions Handling in the
Foreign Agent .............................................31
8. Acknowledgements ...............................................31
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................32
4.7. Home Agent Consideration ..................................23
4.7.1. Sending Generic Notification Messages ..............23
4.7.2. Receiving Generic Notification
Acknowledgement Messages ...........................24
4.7.3. Receiving Generic Notification Messages ............24
4.7.4. Sending Generic Notification
Acknowledgement Messages ...........................26
5. Future Extensibility ...........................................26
5.1. Examples of Possible Extensions ...........................26
5.2. Extension Specification ...................................27
6. IANA Considerations ............................................28
7. Security Considerations ........................................28
7.1. Replay Protection for GNMs and GNAMs ......................29
7.1.1. Replay Protection Using Timestamps .................29
7.1.2. Replay Protection Using Nonces .....................30
7.2. Non-Authentication Extensions Handling in the
Foreign Agent .............................................31
8. Acknowledgements ...............................................31
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................32
In some situations, there is a need for Mobile IPv4 entities, such as the home agent (HA), foreign agent (FA) and mobile node (MN) to send and receive asynchronous notification messages during a mobility session. In this context, 'Asynchronous messages' is used to mean messages that are not synchronous with the Registration Request and Registration Reply messages of the base Mobile IP (MIP) specification [RFC5944]. The base Mobile IP specification does not have a provision for this.
在某些情况下，移动IPv4实体，例如归属代理（HA）、外部代理（FA）和移动节点（MN）需要在移动会话期间发送和接收异步通知消息。在此上下文中，“异步消息”用于表示与基本移动IP（MIP）规范[RFC5944]的注册请求和注册回复消息不同步的消息。基本移动IP规范对此没有规定。
In order to rectify that, this document defines a generic notification message and a notification model that can be used by Mobile IPv4 entities to send various notifications. It also defines a corresponding acknowledgement message to make it possible to ensure reliable delivery of notifications. Only the following extensions may be present in these new messages, as defined by this document:
为了纠正这一点，本文定义了一个通用通知消息和一个通知模型，移动IPv4实体可以使用它来发送各种通知。它还定义了相应的确认消息，以确保可靠地传递通知。根据本文档的定义，这些新邮件中只能包含以下扩展名：
- MN-HA Authentication Extension
- MN-HA认证扩展
- MN-FA Authentication Extension
- MN-FA认证扩展
- FA-HA Authentication Extension
- FA-HA认证扩展
- Message String Extension
- 消息字符串扩展名
The semantics of receiving a generic notification message with a Message String Extension are null; i.e., it has no effect on the state of a mobile node's existing registration. See Section 3.1 for some application examples that motivate the new messages defined in this document.
接收带有消息字符串扩展名的通用通知消息的语义为空；i、 例如，它对移动节点的现有注册的状态没有影响。参见第3.1节，了解激发本文档中定义的新消息的一些应用示例。
It is assumed that the reader is familiar with the terminology used in [RFC4917] and [RFC5944]. In addition, this document frequently uses the following terms:
假设读者熟悉[RFC4917]和[RFC5944]中使用的术语。此外，本文件经常使用以下术语：
Notification Message
通知消息
A message from a mobility agent to a an MN or other mobility agent, or from an MN to a mobility agent, to asynchronously notify it about an event that is relevant to the mobility service it is currently providing.
从移动代理到MN或其他移动代理，或从MN到移动代理的消息，用于异步通知它与当前提供的移动服务相关的事件。
Generic Notification Message
通用通知消息
A Notification Message in the context of Mobile IPv4 with a well-defined envelope format and extensibility, and with certain limitations on how extensions may be defined and used, but otherwise generally available for notification purposes within the Mobile IPv4 protocol. Abbreviated 'GNM' in this document.
移动IPv4上下文中的通知消息，具有定义良好的信封格式和可扩展性，对如何定义和使用扩展具有一定限制，但在移动IPv4协议中通常可用于通知目的。本文件中缩写为“GNM”。
Generic Notification Acknowledgement Message
通用通知确认消息
An acknowledgement of a received Generic Notification Message. Abbreviated 'GNAM' in this document.
对接收到的通用通知消息的确认。本文件中缩写为“GNAM”。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The simplest usage scenario for a notification message is one where the notification has no semantic meaning within the protocol; it is only carrying a message that can be displayed to a user or an operator (depending on which is the receiving entity -- see more on this below, in Section 3.2). Examples of such usage are messages from operator to user about billing- or service-related events ("You have used nearly all of your prepaid quota; there are only XX MB left -- please purchase further service if you are going to need it."; or
通知消息最简单的使用场景是通知在协议中没有语义含义；它只携带一条可以向用户或操作员显示的消息（取决于接收实体——详见下文第3.2节）。例如，运营商向用户发送的有关计费或服务相关事件的消息（“您已使用了几乎所有的预付费配额；只剩下XX MB，如果您需要，请购买更多服务。”或
"You have now used data transfer services for the amount of $XXX since your last bill; this is above the notification threshold for your account.") or messages about service interruptions, and more. These examples are all supported by the use of the Mobile IPv4 Generic Notification Message together with the Message String Extension, as defined in this document.
“自上次账单以来，您现在已使用了金额为XXX美元的数据传输服务；这已超过您帐户的通知阈值。”）或关于服务中断的消息，等等。如本文档中所定义，使用移动IPv4通用通知消息以及消息字符串扩展都支持这些示例。
There are also other examples, which cannot be implemented solely using the messages and extensions defined in this document. Some of these are described briefly below, and covered slightly more extensively in Section 5.
还有其他一些示例，不能仅使用本文档中定义的消息和扩展来实现。下面将简要介绍其中一些，并在第5节中进行更广泛的介绍。
One example of an application of an extended Generic Notification Message is that during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP resource on the CDMA side has to be removed on the FA (Packet Data Serving Node) to avoid over-charging subscribers. To address this, the Registration Revocation Message was defined in [RFC3543], but it would have been preferable to have had it defined as a separate message (i.e., the Generic Notification Message) with a Registration Revocation extension.
扩展通用通知消息的应用的一个示例是，在CDMA 2000 1x EV-DO和无线LAN之间的切换期间，必须在FA（分组数据服务节点）上移除CDMA侧的PPP资源，以避免对用户过度收费。为了解决这个问题，在[RFC3543]中定义了注册撤销消息，但最好将其定义为具有注册撤销扩展的单独消息（即通用通知消息）。
Other applications are:
其他应用包括：
o HA switch-over (before the HA decides to go off-line, it would like to notify the MNs to register with another candidate HA),
o 医管局转换（在医管局决定离线之前，它希望通知MNs向另一个候选医管局注册），
o Network Mobility (NEMO) prefix changes (an MN is notified by the HA about NEMO prefix changes and service- or billing-related events; this is an operational requirement),
o 网络移动（NEMO）前缀更改（由HA通知MN NEMO前缀更改和服务或计费相关事件；这是一项操作要求），
o load balancing (the HA wants to move some of the registered MNs to other HAs),
o 负载平衡（医管局希望将一些注册的MN转移到其他HA），
o service termination (due to end of prepaid time), and
o 服务终止（由于预付时间结束），以及
o service interruption (due to system maintenance).
o 服务中断（由于系统维护）。
There are several scenarios where a mobility agent could initiate notification events. Some of these are described in the following sections.
有几种情况下，移动代理可以启动通知事件。以下各节将介绍其中一些。
In this case, the HA cannot directly notify the MN, but must send the notification via the FA, and vice versa.
在这种情况下，HA不能直接通知MN，但必须通过FA发送通知，反之亦然。
+----+ notification +----+ notification +----+
| MN |<================>| FA |<=============>| HA |
+----+ +----+ +----+
+----+ notification +----+ notification +----+
| MN |<================>| FA |<=============>| HA |
+----+ +----+ +----+
Figure 1: HA notifies MN or MN notifies HA through FA
图1：HA通知MN或MN通过FA通知HA
In this case, the MN has registered with the home agent directly, so the notification message can go directly to the MN.
在这种情况下，MN已直接向归属代理注册，因此通知消息可以直接发送到MN。
The notification mechanism as specified here does not support the case of co-located Care-of Address (CoA) mode with registration through an FA (due to the 'R' bit being set in the FA's advertisement messages).
此处指定的通知机制不支持通过FA注册的同处转交地址（CoA）模式（由于FA的广告消息中设置了“R”位）。
+----+ notification +----+
| MN |<===================================>| HA |
+----+ +----+
Figure 2: HA directly notifies MN or MN directly notifies HA
+----+ notification +----+
| MN |<===================================>| HA |
+----+ +----+
Figure 2: HA directly notifies MN or MN directly notifies HA
There are two cases where an FA may send notification messages to an MN -- one where it is relaying a message, the other where the notification is triggered by a message from another network entity, for example, an Authentication, Authorization, and Accounting (AAA) node. (Notification messages between a AAA entity and the FA could be based on RADIUS or Diameter, but this is out of scope for this document.) If the notification is initiated by an FA, the FA may also need to notify the HA about the event.
有两种情况下，FA可以向MN发送通知消息——一种是转发消息，另一种是由来自另一个网络实体（例如，身份验证、授权和计费（AAA）节点）的消息触发通知。（AAA实体和FA之间的通知消息可能基于半径或直径，但这超出了本文件的范围。）如果通知由FA发起，FA可能还需要将事件通知HA。
+----+ notification +----+ trigger +--------+
| MN |<================>| FA |<=============| AAA |
+----+ +----+ +--------+
|| notification +----+
================>| HA |
+----+
+----+ notification +----+ trigger +--------+
| MN |<================>| FA |<=============| AAA |
+----+ +----+ +--------+
|| notification +----+
================>| HA |
+----+
Figure 3: FA notifies MN
图3:FA通知MN
The HA may also need to send a notification to the FA, but not to the MN. The FA may also need to send a notification to the HA, as illustrated below:
医管局可能还需要向FA发送通知，但不需要向MN发送通知。FA可能还需要向医管局发送通知，如下所示：
+----+ notification +----+
| FA |<=============>| HA |
+----+ +----+
+----+ notification +----+
| FA |<=============>| HA |
+----+ +----+
Figure 4: HA notifies FA or FA notifies HA
图4：HA通知FA或FA通知HA
This section describes in detail the Generic Notification Message (GNM), Generic Notification Acknowledgement Message (GNAM), and some considerations related to the handling of these messages in the MN, FA, and HA.
本节详细描述了通用通知消息（GNM）、通用通知确认消息（GNAM）以及与在MN、FA和HA中处理这些消息相关的一些注意事项。
The MN and HA MUST maintain the following information:
MN和HA必须维护以下信息：
- the IP source address of the Registration Request/Reply
- 注册请求/回复的IP源地址
- the IP destination address of the Registration Request/Reply
- 注册请求/回复的IP目标地址
- the UDP source port of the Registration Request/Reply
- 注册请求/回复的UDP源端口
- the UDP destination port of the Registration Request/Reply
- 注册请求/回复的UDP目标端口
The sending node always sends the GNM following the same procedure for sending a Registration Request as in Section 3.3 of [RFC5944], and the receiving node follows the same procedure for Registration Reply as in Section 3.4 of [RFC5944] when sending GNAM.
发送节点始终按照[RFC5944]第3.3节中相同的发送注册请求程序发送GNM，接收节点在发送GNAM时遵循[RFC5944]第3.4节中相同的注册回复程序。
A GNM is sent by a mobility agent to inform another mobility agent, or an MN, of MIP-related information in the form of a Message String Extension [RFC4917]. These messages MUST use the same IP and UDP
GNM由移动代理发送，以消息字符串扩展的形式通知另一个移动代理或MN与MIP相关的信息[RFC4917]。这些消息必须使用相同的IP和UDP
headers as any previous Registration Request (RRQ) or Reply (RRP) message to the same entity. This would support NAT traversal and ensure the same security association used for GNM/GNAM and RRQ/RRP. The GNM is defined as follows:
头作为任何以前的注册请求（RRQ）或回复（RRP）消息发送给同一实体。这将支持NAT遍历，并确保GNM/GNAM和RRQ/RRP使用相同的安全关联。GNM的定义如下：
IP Fields:
IP字段：
Source Address
源地址
Typically, copied from the destination address of the last Registration Reply/ Request message that the agent received from the agent to which it is sending the GNM.
通常，从代理从其向其发送GNM的代理接收到的最后一条注册回复/请求消息的目标地址复制。
Destination Address
目的地址
Copied from the source address of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.
从代理从向其发送GNM的代理收到的上次注册回复/请求消息的源地址复制。
UDP Fields:
UDP字段：
Source Port
源端口
Typically, copied from the destination port of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.
通常，从代理从其向其发送GNM的代理接收的最后一条注册回复/请求消息的目标端口复制。
Destination Port
目的港
Copied from the source port of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.
从代理从向其发送GNM的代理收到的上次注册回复/请求消息的源端口复制。
The UDP header is followed by the Mobile IP fields shown below:
UDP标头后面是移动IP字段，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MD |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MD |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 22
类型22
MD: Message Direction
MD：消息方向
This memo defines the semantics of the following MD field value:
本备忘录定义了以下MD字段值的语义：
0 -- Message sent by the HA to the MN
0—HA向MN发送的消息
1 -- Message sent by the HA to the FA
1——医管局向足总发送的信息
2 -- Message sent by the MN to the HA
2——MN发送给HA的消息
3 -- Message sent by the MN to the FA
3——MN发送给FA的消息
4 -- Message sent by the FA to the MN
4——FA发送给MN的消息
5 -- Message sent by the FA to the HA
5——FA向医管局发送的信息
A
A.
This bit indicates whether the notification message MUST be acknowledged by the recipient. If the "A" bit has been set during the message, but the sender doesn't receive any acknowledgement message, then the sender will have to re-send the notification message again.
此位指示收件人是否必须确认通知消息。如果消息期间设置了“A”位，但发送方未收到任何确认消息，则发送方必须再次重新发送通知消息。
Set to "1" to indicate that acknowledgement is REQUIRED.
设置为“1”表示需要确认。
Set to "0" to indicate that acknowledgement is OPTIONAL.
设置为“0”表示确认是可选的。
Reserved
含蓄的
MUST be sent as 0, and ignored when received.
必须作为0发送，并在收到时忽略。
Home Address
家庭住址
The home address of the mobile node.
移动节点的家庭地址。
Home Agent Address
国内代理地址
The IP address of the mobile node's HA.
移动节点HA的IP地址。
Care-of Address
转交地址
The mobile node's care-of address, either the co-located care-of address or the foreign agent care-of address.
移动节点的转交地址，可以是同一位置的转交地址，也可以是外部代理的转交地址。
Identification
识别
A 64-bit number, constructed by the sender, used for matching GNM with GNAM and for protecting against replay attacks of notification messages. See Sections 7.1.1 and 7.1.2 for more on the use of timestamps and nonces in this field. Support for the use of timestamps is REQUIRED, and support for nonces is OPTIONAL.
由发送方构造的64位数字，用于将GNM与GNAM匹配，并用于防止通知消息的重放攻击。有关在该字段中使用时间戳和nonce的更多信息，请参见第7.1.1节和第7.1.2节。需要支持使用时间戳，支持nonce是可选的。
Extensions
扩展
The fixed portion of the GNM is followed by one or more extensions that may be used with this message, and by one or more authentication extensions as defined in Section 3.5 of [RFC5944].
GNM的固定部分后面是一个或多个可用于此消息的扩展，以及[RFC5944]第3.5节中定义的一个或多个身份验证扩展。
Apart from the Authentication Extensions mentioned below, only one extension is defined in this document as permitted for use with the GNM: the Message String Extension defined in [RFC4917].
除了下面提到的认证扩展之外，本文档中只定义了一个允许与GNM一起使用的扩展：[RFC4917]中定义的消息字符串扩展。
This document requires the MN-HA Authentication Extension (AE) to be used when this message is sent between the MN and the HA; MN-FA AE and FA-HA AE are OPTIONAL. This document also requires the use of the MN-FA AE when this message is sent between the MN and the FA, where the MN-HA AE and FA-HA AE are not needed. This document finally requires the use of the FA-HA AE when this message is sent between the FA and the HA, and the MN-HA AE and MN-FA AE are not needed. This could be determined based on the "MD" value. See Sections 3.6.1.3 and 3.8.3.3 of [RFC5944] for the rules on the order of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. The same rules are applicable to GNM and GNAM.
本文件要求在MN和HA之间发送此消息时使用MN-HA认证扩展（AE）；MN-FA AE和FA-HA AE是可选的。本文件还要求在MN和FA之间发送此消息时使用MN-FA AE，其中不需要MN-HA AE和FA-HA AE。本文件最后要求在FA和HA之间发送此消息时使用FA-HA AE，并且不需要MN-HA AE和MN-FA AE。这可以根据“MD”值确定。有关这些扩展在移动IPv4 RRQ和RRP消息中出现的顺序规则，请参见[RFC5944]的第3.6.1.3节和第3.8.3.3节。同样的规则适用于GNM和GNAM。
A GNAM is sent by mobility agents or MNs to indicate the successful receipt of a GNM.
GNAM由移动代理或MN发送，以表示成功接收GNM。
IP Fields:
IP字段：
Source Address
源地址
Typically, copied from the destination address of the GNM to which the agent is replying.
通常，从代理应答的GNM的目标地址复制。
Destination Address
目的地址
Copied from the source address of the GNM to which the agent is replying.
从代理答复的GNM的源地址复制。
UDP Fields:
UDP字段：
Source Port
源端口
Copied from the destination port of the corresponding GNM.
从相应GNM的目标端口复制。
Destination Port
目的港
Copied from the source port of the corresponding GNM.
从相应GNM的源端口复制。
The UDP header is followed by the Mobile IP fields shown below:
UDP标头后面是移动IP字段，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MD | Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MD | Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 23
类型23
MD: Message Direction
MD：消息方向
This memo defines the semantics of the following MD field value:
本备忘录定义了以下MD字段值的语义：
0 -- Message sent by the HA to the MN
0—HA向MN发送的消息
1 -- Message sent by the HA to the FA
1——医管局向足总发送的信息
2 -- Message sent by the MN to the HA
2——MN发送给HA的消息
3 -- Message sent by the MN to the FA
3——MN发送给FA的消息
4 -- Message sent by the FA to the MN
4——FA发送给MN的消息
5 -- Message sent by the FA to the HA
5——FA向医管局发送的信息
Code
密码
A value indicating the result of the GNM. See below for a list of currently defined Code values.
指示GNM结果的值。有关当前定义的代码值列表，请参见下文。
Notification successful
通知成功
0 -- notification accepted
0--接受通知
Notification denied by the HA
医管局拒绝通知
128 -- reason unspecified
128——原因未明
129 -- administratively prohibited
129——行政禁止
130 -- insufficient resources
130--资源不足
131 -- mobile node failed authentication
131--移动节点身份验证失败
132 -- foreign agent failed authentication
132--外部代理身份验证失败
133 -- notification Identification mismatch
133——通知标识不匹配
Notification denied by the FA
足总拒绝通知
64 -- reason unspecified
64--原因未明
65 -- administratively prohibited
65——行政禁止
66 -- insufficient resources
66--资源不足
67 -- mobile node failed authentication
67--移动节点身份验证失败
68 -- home agent failed authentication
68--归属代理身份验证失败
69 -- notification Identification mismatch
69--通知标识不匹配
Notification denied by the mobile node
移动节点拒绝通知
192 -- reason unspecified
192--原因未明
193 -- administratively prohibited
193——行政禁止
194 -- insufficient resources
194——资源不足
195 -- foreign agent failed authentication
195--外部代理身份验证失败
196 -- home agent failed authentication
196--归属代理身份验证失败
197 -- notification Identification mismatch
197——通知标识不匹配
Home Address
家庭住址
The home address of the mobile node.
移动节点的家庭地址。
Home Agent Address
国内代理地址
The IP address of the sender's home agent.
发件人的本地代理的IP地址。
Care-of Address
转交地址
The mobile node's care-of address, either the co-located care-of address or the foreign agent care-of address.
移动节点的转交地址，可以是同一位置的转交地址，也可以是外部代理的转交地址。
Identification
识别
A 64-bit number used for matching the GNM with the GNAM and for protecting against replay attacks of notification messages. See Sections 7.1.1 and 7.1.2 for more on the use of timestamps and nonces in this field. Support for the use of timestamps is REQUIRED, and support for nonces is OPTIONAL. The value is based on the Identification field from the GNM from the sender, and on the style of replay protection used in the security context between the sender and its receiver (defined by the mobility security association between them, and the Security Parameter Index (SPI) value in the authorization-enabling extension).
一个64位数字，用于将GNM与GNAM匹配，并防止通知消息的重放攻击。有关在该字段中使用时间戳和nonce的更多信息，请参见第7.1.1节和第7.1.2节。需要支持使用时间戳，支持nonce是可选的。该值基于发送方GNM中的标识字段，以及发送方和接收方之间的安全上下文中使用的重播保护类型（由它们之间的移动安全关联和授权启用扩展中的安全参数索引（SPI）值定义）。
Extensions
扩展
The fixed portion of the GNAM is followed by one or more extensions that may be used with this message, and by one or more authentication extensions as defined in Section 3.5 of [RFC5944].
GNAM的固定部分后面是一个或多个可用于此消息的扩展，以及[RFC5944]第3.5节中定义的一个或多个身份验证扩展。
This document REQUIRES the MN-HA Authentication Extension (AE) to be used when this message is sent between the MN and the HA; MN-FA AE and FA-HA AE are OPTIONAL. This document also requires the use of the MN-FA AE when this message is sent between the MN and the FA, where the MN-HA AE and FA-HA AE are not needed. This document finally requires the use of the FA-HA AE when this message is sent between the FA and the HA, and the MN-HA AE and MN-FA AE are not needed. This could be determined based on the "MD" value. See Sections 3.6.1.3 and 3.8.3.3 of [RFC5944] for the rules on the order of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. The same rules are applicable to GNM and GNAM.
本文件要求在MN和HA之间发送此消息时使用MN-HA认证扩展（AE）；MN-FA AE和FA-HA AE是可选的。本文件还要求在MN和FA之间发送此消息时使用MN-FA AE，其中不需要MN-HA AE和FA-HA AE。本文件最后要求在FA和HA之间发送此消息时使用FA-HA AE，并且不需要MN-HA AE和MN-FA AE。这可以根据“MD”值确定。有关这些扩展在移动IPv4 RRQ和RRP消息中出现的顺序规则，请参见[RFC5944]的第3.6.1.3节和第3.8.3.3节。同样的规则适用于GNM和GNAM。
If the "A" flag has been set during the GNM, but the sender doesn't receive any GNAM within a reasonable time, then the GNM SHOULD be retransmitted. When timestamps are used, a new notification Identification is chosen for each retransmission; thus, it counts as a new GNM. When nonces are used, the unanswered GNM is retransmitted unchanged; thus, the retransmission does not count as a new GNM (Section 7.1). In this way, a retransmission will not require the receiver to re-synchronize with the sender by issuing another nonce in the case in which the original GNM (rather than its GNAM) was lost by the network.
如果在GNM期间设置了“A”标志，但发送方在合理的时间内没有收到任何GNAM，则应重新传输GNM。当使用时间戳时，为每次重传选择新的通知标识；因此，它算作一个新的GNM。当使用nonce时，未应答的GNM被不变地重新传输；因此，重传不算作新的GNM（第7.1节）。这样，在原始GNM（而不是其GNAM）被网络丢失的情况下，重传将不需要接收机通过发出另一个nonce来与发送方重新同步。
The maximum time until a new GNM is sent SHOULD be no greater than the requested Lifetime of the last GNM. The minimum value SHOULD be large enough to account for the size of the messages, twice the round-trip time for transmission to the receiver, and at least an additional 100 milliseconds to allow for processing the messages before responding. The round-trip time for transmission to the receiver will be at least as large as the time REQUIRED to transmit the messages at the link speed of the sender's current point of attachment. Some circuits add another 200 milliseconds of satellite delay in the total round-trip time to the receiver. The minimum time between GNMs 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.
发送新GNM之前的最长时间不应大于请求的最后一个GNM的生存期。最小值应足够大，以说明消息的大小，传输到接收器的往返时间的两倍，以及至少额外的100毫秒，以允许在响应之前处理消息。传输到接收器的往返时间至少与以发送者当前连接点的链路速度传输消息所需的时间相同。一些电路在接收器的总往返时间中再增加200毫秒的卫星延迟。GNMs之间的最短时间不得小于1秒。每个连续的重新传输超时时间应至少是前一个时间段的两倍，只要该时间段小于上述规定的最大值。
Implementations of this specifications should provide support for management of the various settings related to the notification messages. In particular, it should be possible to do the following:
此规范的实现应支持管理与通知消息相关的各种设置。特别是，应能够执行以下操作：
o List the notification messages supported.
o 列出支持的通知消息。
o Show enabled/disabled status for notification message support, overall and in detail.
o 整体和详细显示通知消息支持的启用/禁用状态。
o Show the value of the maximum and minimum retransmission times.
o 显示最大和最小重新传输时间的值。
o Enable and disable notification support entirely.
o 完全启用和禁用通知支持。
o Enable and disable the individual notification messages supported.
o 启用和禁用支持的单个通知消息。
o Set the values of the maximum and minimum retransmission times described in Section 4.3.
o 设置第4.3节所述的最大和最小重传时间值。
It is possible that the MN MAY receive a GNM from an FA or HA. Both in the case of FA-CoA and co-located CoA, the MN MAY reply with a GNAM based on the "A" flag in the GNM.
MN可能从FA或HA接收GNM。在FA-CoA和同地CoA的情况下，MN可以基于GNM中的“a”标志用GNAM应答。
When the MN is using an FA-CoA and receives a notification message, if the "MD" value is 0, it means that the notification message came from the HA. If the "MD" value is 4, the notification came from the FA. If the MN is using a co-located CoA and receives a notification message, the "MD" value will be 0, indicating that the notification message came from the HA.
当MN使用FA CoA并接收到通知消息时，如果“MD”值为0，则表示通知消息来自HA。如果“MD”值为4，则通知来自FA。如果MN使用同一位置的CoA并接收到通知消息，“MD”值将为0，表示通知消息来自HA。
The MN MUST check for the presence of an authorization-enabling extension and perform the indicated authentication. Exactly one authorization-enabling extension MUST be present in the GNM.
MN必须检查授权启用扩展是否存在，并执行指定的身份验证。GNM中必须只有一个授权启用扩展。
If this message came from an FA, then an MN-FA AE MUST be present. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, then the MN MUST reject the GNM and MAY send a GNAM to the FA with Code 195, including an Identification field computed in accordance with the rules specified in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
如果此消息来自FA，则必须存在MN-FA AE。如果未发现MN-FA AE，或者发现多个MN-FA AE，或者如果验证器无效，则MN必须拒绝GNM，并可以向FA发送代码为195的GNAM，包括根据第7.1节规定的规则计算的识别字段。MN不得对此类通知进行进一步处理，尽管它应将错误记录为安全异常。
If this notification message came from the HA, relayed by the FA, or if the MN is using a co-located CoA, then the MN-HA AE MUST be checked and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, then the MN MUST reject the GNM and MAY send a GNAM to the initiator with Code 196, including an Identification field computed in accordance with the rules specified in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
如果此通知消息来自HA，由FA中继，或者如果MN使用同一位置的CoA，则必须检查MN-HA AE，并且MN必须检查扩展中的验证器值。如果没有发现MN-HA AE，或者如果发现多个MN-HA AE，或者如果验证器无效，则MN必须拒绝GNM，并可以向启动器发送代码为196的GNAM，包括根据第7.1节规定的规则计算的标识字段。MN不得对此类通知进行进一步处理，尽管它应将错误记录为安全异常。
The MN MUST check that the Identification field is correct using the context selected by the SPI within a mandatory authentication extension like the MN-FA AE or MN-HA AE. See Section 7.1 for a description of how this is performed. If incorrect, the MN MUST reject the GNM and MAY send a GNAM to the initiator with Code 197, including an Identification field computed in accordance with the rules specified in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
MN必须使用SPI在强制认证扩展（如MN-FA AE或MN-HA AE）内选择的上下文检查标识字段是否正确。有关如何执行此操作的说明，请参见第7.1节。如果不正确，MN必须拒绝GNM，并可向启动器发送代码为197的GNAM，包括根据第7.1节规定的规则计算的标识字段。MN不得对此类通知进行进一步处理，尽管它应将错误记录为安全异常。
The MN MUST also check that the extensions present in the Generic Notification Message are permitted for use with the GNM. If not, the MN MUST silently discard the message. It MUST NOT do any further processing with such a notification, though it SHOULD log the error.
MN还必须检查通用通知消息中存在的扩展是否允许与GNM一起使用。否则，MN必须以静默方式丢弃消息。它不能对这样的通知进行任何进一步的处理，尽管它应该记录错误。
If the MN accepts a GNM, then it will process it according to the specific rules for the extensions. After that, the MN MAY reply to the originator with a GNAM with Code 0 based on the "A" flag in the GNM.
如果MN接受GNM，那么它将根据扩展的特定规则对其进行处理。之后，MN可以基于GNM中的“a”标志，使用代码为0的GNAM回复发端人。
Both in the case of a co-located CoA and FA-CoA, the MN MAY reply with a GNAM based on the "A" flag in the GNM as follows:
在同一位置的CoA和FA CoA的情况下，MN可以根据GNM中的“a”标志用GNAM回复，如下所示：
If the GNM was initiated from the FA to the MN ("MD" value is set to 4), then the MN-FA AE MUST be the last extension in order to protect all other non-authentication extensions as defined in Section 3.5.3 of [RFC5944].
如果GNM从FA启动到MN（“MD”值设置为4），则MN-FA AE必须是最后一个扩展，以保护[RFC5944]第3.5.3节中定义的所有其他非认证扩展。
In the case of an FA-CoA, the source address is the MN's address, the destination address is the FA's address.
在FA-CoA的情况下，源地址是MN的地址，目标地址是FA的地址。
The Code field of the GNAM is chosen in accordance with the rules specified in Section 4.2. When replying to an accepted notification, an MN SHOULD respond with Code 0.
根据第4.2节规定的规则选择GNAM的代码字段。在回复接受的通知时，MN应以代码0进行响应。
There are a number of reasons why the MN might reject a notification, such as for example not being permitted to receive notifications, which could be for a number of reasons, causing the return of a GNAM with Code value 193 (administratively prohibited); or being unable to act on or display the notification, or otherwise being resource constrained, causing the use of Code value 194 (insufficient resources); or other reasons for which no other specific Code value is available, which would cause the use of Code value 192 (reason unspecified).
MN可能拒绝通知的原因有很多，例如，不允许接收通知，这可能是由于许多原因，导致返回代码值为193（行政禁止）的GNAM；或无法执行或显示通知，或资源受限，导致使用代码值194（资源不足）；或者由于其他原因，没有其他特定的代码值可用，这将导致使用代码值192（原因未指定）。
If the GNM was initiated from the HA to the MN ("MD" value is set to 0) and in the case of a co-located CoA, then the MN-HA AE MUST be the last extension in order to protect all other non-authentication extensions as defined in Section 3.5.2 of [RFC5944].
如果GNM从HA启动到MN（“MD”值设置为0），并且如果是同一位置的CoA，则MN-HA AE必须是最后一个扩展，以保护[RFC5944]第3.5.2节中定义的所有其他非认证扩展。
When replying to a GNM from an HA to an MN with an FA-CoA, the source address is the MN's home address and the destination address is the FA's address ("MD" value is set to 2). The ordering of the extension is: any non-authentication Extensions intended for the HA, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], followed by any non-authentication Extensions intended for the FA, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944].
当使用FA-CoA从HA向MN回复GNM时，源地址是MN的家庭地址，目标地址是FA的地址（“MD”值设置为2）。扩展顺序为：针对HA的任何非认证扩展，然后是[RFC5944]第3.5.2节中定义的MN-HA AE，然后是针对FA的任何非认证扩展，然后是[RFC5944]第3.5.3节中定义的MN-FA AE。
The MN may send a GNM to notify either the FA or HA.
MN可发送GNM通知FA或HA。
If the message is sent to the FA, then the source address is the MN's address, and the destination address is the FA's address
如果消息被发送到FA，则源地址是MN的地址，目标地址是FA的地址
If the FA is the target of this notification message, then the "MD" value is set to 3, and the MN-FA AE MUST be the last extension in order to protect all other non-authentication extensions. Computing the Authentication Extension Values is done in the same manner as in Section 3.5.1 of [RFC5944].
如果FA是此通知消息的目标，则“MD”值设置为3，并且MN-FA AE必须是最后一个扩展，以保护所有其他非身份验证扩展。以与[RFC5944]第3.5.1节相同的方式计算认证扩展值。
If the FA is working only as a relay agent, then the "MD" value is set to 2, and the ordering of the extension is: the notification extension, followed by any non-authentication extension expected to be used by HA, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], followed by any non-authentication Extensions intended for the FA, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944]. Computing the Authentication Extension Values is done in the same manner as in Section 3.5.1 of [RFC5944].
如果FA仅作为中继代理工作，则“MD”值设置为2，扩展顺序为：通知扩展，后跟预期由HA使用的任何非认证扩展，后跟[RFC5944]第3.5.2节中定义的MN-HA AE，后跟预期用于FA的任何非认证扩展，然后是[RFC5944]第3.5.3节中定义的MN-FA AE。以与[RFC5944]第3.5.1节相同的方式计算认证扩展值。
In the case of a co-located CoA, the MN MAY send a notification message directly to the HA if it needs to be notified. The "MD" value is set to 2, and the ordering of the extension is: the
在共址CoA的情况下，如果需要通知，MN可以直接向HA发送通知消息。“MD”值设置为2，扩展的顺序为：
notification extension, followed by any non-authentication extension expected to be used by HA, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944].
通知扩展，然后是预期由HA使用的任何非认证扩展，然后是[RFC5944]第3.5.2节中定义的MN-HA AE。
The MN chooses the Identification field in accordance with the style of replay protection it uses with its HA. This is part of the mobility security association the MN shares with its HA. See Section 7.1 for the method by which the MN computes the Identification field.
MN根据其HA使用的重放保护类型选择标识字段。这是MN与其HA共享的移动安全协会的一部分。MN计算标识字段的方法见第7.1节。
In the case of an FA-CoA, if the MN receives this message, and the "MD" value is set to 0, it means that the GNAM came from the HA.
在FA-CoA的情况下，如果MN接收到该消息，并且“MD”值设置为0，则表示GNAM来自HA。
If the "MD" value is set to 4, then the MN-FA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, then the MN MUST silently discard the GNAM.
如果“MD”值设置为4，则必须检查MN-FA AE，并且MN必须检查扩展中的验证器值。如果没有发现MN-FA AE，或者如果发现多个MN-FA AE，或者如果验证器无效，则MN必须默默地丢弃GNAM。
In addition, the low-order 32 bits of the Identification field in the GNAM MUST be compared to the low-order 32 bits of the Identification field in the most recent GNM sent to the replying agent. If they do not match, then the GNAM MUST be silently discarded.
此外，必须将GNAM中标识字段的低阶32位与发送给应答代理的最近GNM中标识字段的低阶32位进行比较。如果它们不匹配，那么必须默默地丢弃GNAM。
If the "MD" value is set to 0, then the MN-HA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, then the MN MUST silently discard the GNAM. If the MN accepted this message, then the MN MAY also process it based on the notification event.
如果“MD”值设置为0，则必须检查MN-HA AE，并且MN必须检查扩展中的验证器值。如果没有发现MN-HA AE，或者如果发现多个MN-HA AE，或者如果验证器无效，则MN必须默默地丢弃GNAM。如果MN接受此消息，则MN也可以基于通知事件对其进行处理。
In the case of a co-located CoA, if the MN received this message, then the MN-HA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, then the MN MUST silently discard the Notification Acknowledgement message.
对于同一位置的CoA，如果MN收到此消息，则必须检查MN-HA AE，并且MN必须检查扩展中的验证器值。如果未找到MN-HA AE，或者如果找到多个MN-HA AE，或者如果验证器无效，则MN必须以静默方式放弃通知确认消息。
The FA may initiate a GNM to the MN or the HA. Additionally, the FA also relays GNMs and GNAMs between the MN and its HA as long as there is an active binding for the MN at the FA.
FA可向MN或HA发起GNM。此外，只要在FA处存在MN的活性结合，FA也在MN与其HA之间中继GNM和GNAM。
If the FA receives a GNM, and the "MD" value is set to 0, then it means that the HA is asking the FA to relay the message to the MN. If the "MD" value is set to 1, then it means that the target of the notification is the FA. If the "MD" value is set to 2, then it means that the MN is asking the FA to relay the message to the HA. If the "MD" value is set to 3, then it means that the notification came from the MN to the FA.
如果FA收到GNM，“MD”值设置为0，则表示HA要求FA将消息中继到MN。如果“MD”值设置为1，则表示通知的目标是FA。如果“MD”值设置为2，则表示MN正在请求FA将消息中继到HA。如果“MD”值设置为3，则表示通知来自MN到FA。
If the "MD" value is set to 0, then the FA MAY validate the FA-HA AE if present. If the FA-HA AE is invalid, then all extensions between the HA-MN AE and the HA-FA AE MUST be removed, the FA SHOULD relay the GNM to the MN's home address as specified in the Home Address field of the GNM, and the MN will eventually validate the MN-HA AE to ensure that all information sent to the MN is integrity protected. If the FA-HA AE is valid, the FA MUST relay the GNM to the MN's home address as specified in the Home Address field of the GNM. The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNM through the MN-HA AE or other authentication extension supplied by the HA as an authorization-enabling extension for the MN.
如果“MD”值设置为0，则FA可验证FA-HA AE（如果存在）。如果FA-HA AE无效，则必须删除HA-MN AE和HA-FA AE之间的所有扩展，FA应将GNM中继到GNM的home address字段中指定的MN的home address，MN最终将验证MN-HA AE，以确保发送到MN的所有信息都受到完整性保护。如果FA-HA AE有效，FA必须将GNM中继到GNM的“家庭地址”字段中指定的MN的家庭地址。FA不得通过MN-HA AE或HA提供的其他认证扩展（作为MN的授权启用扩展）修改GNM固定部分开头的任何字段。
Furthermore, the FA MUST process and remove any extensions following the MN-HA AE. If the FA shares a mobility security association with the MN, the FA MAY append any of its own non-authentication extensions that are relevant to the MN. In this case, the FA MUST append the MN-FA AE after these non-authentication extensions.
此外，FA必须处理并移除MN-HA AE后的任何延伸。如果FA与MN共享移动安全关联，则FA可以附加其自己的与MN相关的任何非认证扩展。在这种情况下，FA必须在这些非身份验证扩展之后附加MN-FA AE。
If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the FA MUST reject the GNM and MAY send a GNAM to the HA with Code 68, including an Identification field computed in accordance with the rules specified in Section 7.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
如果“MD”值设置为1，则必须检查FA-HA AE，并且FA必须检查扩展中的验证器值。如果未发现FA-HA AE，或者如果发现多个FA-HA AE，或者如果验证器无效，FA必须拒绝GNM，并可以向HA发送代码为68的GNAM，包括根据第7.1节规定的规则计算的标识字段。FA不得对此类通知进行进一步处理，但应将错误记录为安全异常。
The FA MUST check that the Identification field is correct using the context selected by the SPI within the mandatory FA-HA AE. See Section 7.1 for a description of how this is performed. If incorrect, the FA MUST reject the GNM and MAY send a GNAM to the initiator with Code 69, including an Identification field computed in accordance with the rules specified in Section 7.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
FA必须使用SPI在强制FA-HA AE中选择的上下文检查标识字段是否正确。有关如何执行此操作的说明，请参见第7.1节。如果不正确，FA必须拒绝GNM，并可向发起者发送代码为69的GNAM，包括根据第7.1节规定的规则计算的标识字段。FA不得对此类通知进行进一步处理，但应将错误记录为安全异常。
The FA MUST also check that the extensions present in the Generic Notification Message are permitted for use with the GNM. If not, the FA MUST silently discard the message. It MUST NOT do any further processing with such a notification, though it SHOULD log the error.
FA还必须检查通用通知消息中的扩展是否允许与GNM一起使用。如果没有，FA必须默默地丢弃该消息。它不能对这样的通知进行任何进一步的处理，尽管它应该记录错误。
If the FA accepts the HA's GNM, it will process it based on the specific rules for the extensions it contains. The FA MAY then reply to the HA with a GNAM with Code 0 based on the "A" flag in the GNM.
如果FA接受医管局的GNM，它将根据其包含的扩展的特定规则进行处理。FA随后可根据GNM中的“a”标志，向HA回复代码为0的GNAM。
In the case of an FA-CoA and if the "MD" value is set to 2, if the FA received this message, and if the MN-FA AE is present, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the GNM. If the MN-FA is valid, the FA MUST relay the GNM to the HA's address as specified in the Home Agent Address field of the GNM. The HA will eventually validate the MN-HA AE to ensure that all information sent to the HA is integrity protected. The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNM through the MN-HA AE or other authentication extension supplied by the MN as an authorization-enabling extension for the HA.
对于FA CoA，如果“MD”值设置为2，如果FA收到此消息，并且如果存在MN-FA AE，则必须检查MN-FA AE，并且FA必须检查扩展中的验证器值。如果没有发现MN-FA AE，或者如果发现多个MN-FA AE，或者如果验证器无效，FA必须默默地丢弃GNM。如果MN-FA有效，FA必须将GNM中继到GNM的Home Agent address字段中指定的HA地址。医管局最终将验证MN-HA AE，以确保发送给医管局的所有信息都受到完整性保护。FA不得通过MN-HA AE或MN提供的其他认证扩展来修改任何以GNM的固定部分开始的字段，作为HA的授权启用扩展。
Furthermore, the FA MUST process and remove any extensions following the MN-HA AE, and MAY append any of its own non-authentication extensions of relevance to the HA, if applicable. Also, it MUST append the FA-HA AE if the FA shares a mobility security association with the HA.
此外，FA必须处理和删除MN-HA AE之后的任何扩展，并且可以在适用的情况下将其自身的任何非认证扩展附加到HA。此外，如果FA与HA共享移动安全关联，则必须附加FA-HA AE。
If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension, as described in Section 3.7.2.1 of [RFC5944]. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN with Code 67, including an Identification field computed in accordance with the rules specified in Section 7.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
如果“MD”值设置为3，则必须检查MN-FA AE，且FA必须检查扩展中的验证器值，如[RFC5944]第3.7.2.1节所述。如果没有发现MN-FA AE，或者如果发现多个MN-FA AE，或者如果验证器无效，FA必须拒绝GNM，并可以向MN发送代码为67的GNAM，包括根据第7.1节规定的规则计算的标识字段。FA不得对此类通知进行进一步处理，但应将错误记录为安全异常。
The FA MUST check that the Identification field is correct using the context selected by the SPI within mandatory MN-FA AE. See Section 7.1 for a description of how this is performed. If incorrect, the FA MUST reject the GNM and MAY send a GNAM to the initiator with Code 69, including an Identification field computed in accordance with the rules specified in Section 7.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
FA必须使用SPI在强制MN-FA AE中选择的上下文检查标识字段是否正确。有关如何执行此操作的说明，请参见第7.1节。如果不正确，FA必须拒绝GNM，并可向发起者发送代码为69的GNAM，包括根据第7.1节规定的规则计算的标识字段。FA不得对此类通知进行进一步处理，但应将错误记录为安全异常。
If the FA accepts the MN's GNM, it will process it based on the specific rules for the extensions it contains. The FA MAY then reply to the MN with a GNAM with Code 0 based on the "A" flag in the GNM.
如果FA接受MN的GNM，它将根据其包含的扩展的特定规则对其进行处理。FA随后可以基于GNM中的“a”标志，使用代码为0的GNAM回复MN。
The FA may need either to relay a GNAM between the MN and the HA or to send one as a response to a GNM that was sent to it. In both cases, the GNAM is defined as follows.
FA可能需要在MN和HA之间中继GNAM，或者将GNAM作为响应发送给它。在这两种情况下，GNAM的定义如下。
The source address is the FA address, and the destination address is the HA's or MN's home address.
源地址是FA地址，目标地址是HA或MN的家庭地址。
The Code field of the GNAM is chosen in accordance with the rules specified in Section 4.2. When replying to an accepted notification, an FA SHOULD respond with Code 0.
根据第4.2节规定的规则选择GNAM的代码字段。在回复接受的通知时，FA应以代码0进行响应。
The FA might reject a notification by returning a GNAM with the Code value 65 (administratively prohibited), which could be for a number of reasons; 64 (reason unspecified); or 66 (insufficient resources).
FA可能会通过返回代码值为65（行政禁止）的GNAM来拒绝通知，原因可能有很多；64（未说明原因）；或66（资源不足）。
If the FA is relaying this message to only the HA, the FA MUST NOT modify any of the fields beginning with the fixed portion of the GNAM up through and including the MN-HA AE or other authentication extension supplied by the MN as an authorization-enabling extension for the MN. Furthermore, the foreign agent MUST process and remove any extensions following the MN-HA AE. If the FA shares a mobility security association with the HA, the FA MAY append any of its own non-authentication extensions that are relevant to the HA. In this case, the FA MUST append the FA-HA AE after these non-authentication extensions.
如果FA仅向HA中继此消息，则FA不得修改任何字段，这些字段从GNAM的固定部分开始，一直到MN-HA AE或MN提供的其他认证扩展，作为MN的授权启用扩展。此外，外国代理必须处理并移除MN-HA AE之后的任何扩展。如果FA与HA共享移动安全关联，FA可以附加其自身与HA相关的任何非认证扩展。在这种情况下，FA必须在这些非身份验证扩展之后附加FA-HA AE。
If the notification message is from the HA to the FA, then the "MD" value is set to 5 and the ordering of the extension is: any non-authentication Extensions intended for the FA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944].
如果通知消息是从HA发送到FA，则“MD”值设置为5，扩展的顺序为：任何针对FA的非认证扩展，然后是[RFC5944]第3.5.4节中定义的FA-HA AE。
If the notification message is from the MN to the FA, then the "MD" value is set to 4 and the ordering of the extension is: any non-authentication Extensions intended for the FA, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944].
如果通知消息是从MN发送到FA，则“MD”值设置为4，扩展顺序为：任何针对FA的非认证扩展，然后是[RFC5944]第3.5.3节中定义的MN-FA AE。
If the FA is initiating a notification to the MN using the GNM, it MAY also notify the HA.
如果FA正在使用GNM向MN发出通知，它也可以通知HA。
In the message to the MN, the source address is the FA address, the destination address is the MN's address, the "MD" value is set to 4, and the ordering of the extension is: the notification extension, followed by any non-authentication extensions intended for the MN, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944]. Computing the Authentication Extension Values is done in the same manner as in Section 3.5.1 of [RFC5944] except the payload is the notification rather than the registration.
在发送给MN的消息中，源地址是FA地址，目标地址是MN地址，“MD”值设置为4，扩展的顺序是：通知扩展，然后是针对MN的任何非认证扩展，然后是[RFC5944]第3.5.3节中定义的MN-FA AE。计算认证扩展值的方式与[RFC5944]第3.5.1节中的方式相同，但有效负载是通知而不是注册。
In the message to the HA, the source address is the FA's address, the destination address is the HA's address (the "MD" value is set to 5), and the ordering of the extension is: notification extension, followed by any non-authentication Extensions intended for the HA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Value is done in the same manner as described in Section 3.5.1 of [RFC5944], except that the payload is the notification instead of the registration.
在发送给HA的消息中，源地址是FA的地址，目标地址是HA的地址（“MD”值设置为5），扩展的顺序是：通知扩展，后跟针对HA的任何非认证扩展，后跟[RFC5944]第3.5.4节中定义的FA-HA AE。计算认证扩展值的方式与[RFC5944]第3.5.1节中所述的方式相同，但有效负载是通知而不是注册。
In the case of an FA-CoA, if the FA receives this message, and the "MD" value is set to 2, it means that the notification acknowledgement message is from the MN to the HA; if the "MD" value is set to 3, the message is from the MN to the FA; otherwise, it came from the HA.
在FA-CoA的情况下，如果FA接收到该消息，并且“MD”值设置为2，则表示通知确认消息是从MN到HA的；如果“MD”值设置为3，则消息从MN发送到FA；否则，它来自医管局。
If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the Notification Acknowledgement message. If the FA accepted this message, the FA MAY also process it based on the notification event.
如果“MD”值设置为1，则必须检查FA-HA AE，并且FA必须检查扩展中的验证器值。如果未找到FA-HA AE，或者如果找到多个FA-HA AE，或者如果验证器无效，FA必须以静默方式放弃通知确认消息。如果FA接受此消息，FA也可以根据通知事件对其进行处理。
If the "MD" value is set to 3, and if the MN-FA AE is present, the AE MUST be checked, and the FA MUST check the Authenticator value in the extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the GNAM. If the FA accepted this message, the FA MAY also process it based on the notification event.
如果“MD”值设置为3，并且如果存在MN-FA AE，则必须检查AE，并且FA必须检查扩展中的验证器值。如果没有找到MN-FA AE，或者如果找到多个MN-FA AE，或者如果验证器无效，FA必须默默地丢弃GNAM。如果FA接受此消息，FA也可以根据通知事件对其进行处理。
In the case of an FA-CoA and if the "MD" value is set to 2, if the FA received this message, and if the MN-FA AE is present, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the GNAM. If the FA accepted the MN's GNAM, it MUST relay this message to the HA. The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNAM up through and including
对于FA CoA，如果“MD”值设置为2，如果FA收到此消息，并且如果存在MN-FA AE，则必须检查MN-FA AE，并且FA必须检查扩展中的验证器值。如果没有找到MN-FA AE，或者如果找到多个MN-FA AE，或者如果验证器无效，FA必须默默地丢弃GNAM。如果FA接受MN的GNAM，它必须将此消息转发给HA。FA不得修改任何从GNAM固定部分开始的字段，包括
the MN-HA AE or other authentication extension supplied by the HA as an authorization-enabling extension for the MN. Furthermore, the FA MUST process and remove any extensions following the MN-HA AE and MAY append any of its own non-authentication extensions of relevance to the HA, if applicable. Also, it MUST append the FA-HA AE, if the FA shares a mobility security association with the HA.
MN-HA AE或由HA提供的其他身份验证扩展，作为MN的授权启用扩展。此外，FA必须处理和删除MN-HA AE之后的任何扩展，并可在适用的情况下将其自身的任何非认证扩展附加到HA。此外，如果FA与HA共享移动安全关联，则必须附加FA-HA AE。
The HA MAY initiate a GNM to both the mobile node and FA, and it also MAY receive a GNAM from both the FA and MN. The HA also MAY receive a GNM from the FA, but only when there is a binding for an MN. If the HA receives a GNM from an FA and there is no corresponding MN registration, the HA SHOULD drop the GNM.
HA可以向移动节点和FA两者发起GNM，并且它还可以从FA和MN两者接收GNAM。HA也可以从FA接收GNM，但仅当MN存在绑定时。如果医管局从FA收到GNM，并且没有相应的MN注册，则医管局应放弃GNM。
In the case of an FA-CoA, the HA may either send a GNM to notify the FA, or have the FA relay the GNM to the MN if the MN needs to be notified.
在FA-CoA的情况下，HA可以发送GNM通知FA，或者如果需要通知MN，则让FA将GNM中继给MN。
If the message is from the HA to the FA, the source address is the HA's address, and the destination address is the FA's address
如果消息是从HA发送到FA，则源地址是HA的地址，目标地址是FA的地址
If the FA is working only as a relay agent, the "MD" value is set to 0, and the ordering of the extension is: the notification extension, followed by any non-authentication extension expected to be used by MN, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], followed by any non-authentication extensions intended for the FA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Value is done in the same manner as in Section 3.5.1 of [RFC5944].
如果FA仅作为中继代理工作，“MD”值设置为0，扩展顺序为：通知扩展，然后是预期由MN使用的任何非认证扩展，然后是[RFC5944]第3.5.2节中定义的MN-HA AE，然后是针对FA的任何非认证扩展，然后是[RFC5944]第3.5.4节中定义的FA-HA AE。以与[RFC5944]第3.5.1节中相同的方式计算认证扩展值。
If the FA is the target of this notification message, then the "MD" value is set to 1, and the ordering of the extension is: the notification extension, followed by any non-authentication Extensions intended for the FA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Values is done in the same manner as in Section 3.5.1 of [RFC5944].
如果FA是此通知消息的目标，则“MD”值设置为1，扩展的顺序为：通知扩展，后跟针对FA的任何非认证扩展，后跟[RFC5944]第3.5.4节中定义的FA-HA AE。以与[RFC5944]第3.5.1节相同的方式计算认证扩展值。
In the case of a co-located CoA, the HA MAY send a notification message directly to the MN if it needs to be notified. The "MD" value is set to 0, and the ordering of the extension is: the notification extension, followed by any non-authentication extension expected to be used by the MN, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944].
在同一位置的CoA的情况下，如果需要通知，HA可以直接向MN发送通知消息。“MD”值设置为0，扩展的顺序为：通知扩展，然后是预期由MN使用的任何非认证扩展，然后是[RFC5944]第3.5.2节中定义的MN-HA AE。
In the case of an FA-CoA, if the HA receives this message, and the "MD" value is set to 2, it means that the GNAM came from the MN.
在FA-CoA的情况下，如果HA接收到该消息，并且“MD”值设置为2，则表示GNAM来自MN。
If the "MD" value is set to 5, and the HA accepted this message, the HA MAY also process it based on the notification event. The FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM.
如果“MD”值设置为5，并且医管局接受此消息，医管局也可以根据通知事件对其进行处理。必须检查FA-HA AE，HA必须检查扩展中的验证器值。如果没有找到FA-HA AE，或者如果找到多个FA-HA AE，或者如果验证器无效，HA必须默默地丢弃GNAM。
If the "MD" value is set to 2, in the case of an FA-CoA, and if the FA-HA AE is present, the FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. No matter what, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. If the HA accepted this message, the HA MAY also process it based on the notification event.
如果“MD”值设置为2，在FA CoA的情况下，并且如果存在FA-HA AE，则必须检查FA-HA AE，并且HA必须检查扩展中的验证器值。如果发现多个FA-HA AE，或者如果验证器无效，HA必须默默地丢弃GNAM。无论如何，必须检查MN-HA AE，HA必须检查扩展中的验证器值。如果没有发现MN-HA AE，或者如果发现多个MN-HA AE，或者如果验证器无效，HA必须默默地丢弃GNAM。如果医管局接受此消息，医管局也可以根据通知事件对其进行处理。
If the "MD" value is set to 2, in the case of a co-located CoA, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. If the HA accepted this message, the HA MAY also process it based on the notification event.
如果“MD”值设置为2，则在共定位CoA的情况下，必须检查MN-HA AE，HA必须检查扩展中的验证器值。如果没有发现MN-HA AE，或者如果发现多个MN-HA AE，或者如果验证器无效，HA必须默默地丢弃GNAM。如果医管局接受此消息，医管局也可以根据通知事件对其进行处理。
The HA MAY receive a GNM sent from the FA. When the HA receives this message, if the "MD" value is set to 5, this message came from FA. The FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 132, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
医管局可能会收到FA发送的GNM。当HA收到此消息时，如果“MD”值设置为5，则此消息来自FA。必须检查FA-HA AE，HA必须检查扩展中的验证器值。如果未发现FA-HA AE，或者如果发现多个FA-HA AE，或者如果验证器无效，HA必须拒绝GNM，并可以向FA发送代码为132的GNAM，包括根据第7.1节规定的规则计算的识别字段。HA不得对此类通知进行进一步处理，但应将错误记录为安全异常。
The HA MUST check that the Identification field is correct using the context selected by the SPI within a mandatory authentication extension like MN-HA AE or FA-HA AE. See Section 7.1 for a description of how this is performed. If incorrect, the HA MUST reject the GNM and MAY send a GNAM to the initiator with Code 133,
HA必须使用SPI在强制认证扩展（如MN-HA AE或FA-HA AE）内选择的上下文检查标识字段是否正确。有关如何执行此操作的说明，请参见第7.1节。如果不正确，HA必须拒绝GNM，并可能向启动器发送代码为133的GNAM，
including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. If the HA accepts the FA's GNM, it will process it based on the notification extension. Furthermore, the HA MAY reply to the FA with a GNAM with Code 0 based on the "A" flag in the GNM.
包括根据第7.1节规定的规则计算的识别字段。HA不得对此类通知进行进一步处理，但应将错误记录为安全异常。如果医管局接受FA的GNM，它将根据通知延期进行处理。此外，医管局可根据GNM中的“a”标志，向FA回复代码为0的GNAM。
If the "MD" value is set to 2, this message comes from the MN. In the case of FA-CoA, if FA-HA AE is present, it MUST be checked, and the HA MUST check the Authenticator value in the Extension. If more than one FA-HA AE Extension is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 132, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. Also, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the MN with Code 131, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. If the HA accepts the MN's GNM, it will process it based on the notification extension. Furthermore, the HA MAY reply to the MN with a GNAM back with Code 0 based on the "A" flag in the GNM.
如果“MD”值设置为2，则此消息来自MN。对于FA CoA，如果存在FA-HA AE，则必须对其进行检查，并且HA必须检查扩展中的验证器值。如果发现多个FA-HA AE扩展，或者如果验证器无效，HA必须拒绝GNM，并可以向FA发送代码为132的GNAM，包括根据第7.1节规定的规则计算的标识字段。HA不得对此类通知进行进一步处理，但应将错误记录为安全异常。此外，必须检查MN-HA AE，HA必须检查扩展中的验证器值。如果没有发现MN-HA AE，或者如果发现多个MN-HA AE，或者如果验证器无效，HA必须拒绝GNM，并可以向MN发送代码为131的GNAM，包括根据第7.1节规定的规则计算的标识字段。HA不得对此类通知进行进一步处理，但应将错误记录为安全异常。如果医管局接受MN的GNM，它将根据通知扩展进行处理。此外，HA可以基于GNM中的“a”标志，使用代码为0的GNAM回覆MN。
If the "MD" value is set to 2, in the case of a co-located CoA, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the MN with Code 131, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. If the HA accepts the MN's GNM, it will process it based on the notification extension. Furthermore, the HA MAY reply to the MN with a GNAM with Code 0 based on the "A" flag in the GNM.
如果“MD”值设置为2，则在共定位CoA的情况下，必须检查MN-HA AE，HA必须检查扩展中的验证器值。如果没有发现MN-HA AE，或者如果发现多个MN-HA AE，或者如果验证器无效，HA必须拒绝GNM，并可以向MN发送代码为131的GNAM，包括根据第7.1节规定的规则计算的标识字段。HA不得对此类通知进行进一步处理，但应将错误记录为安全异常。如果医管局接受MN的GNM，它将根据通知扩展进行处理。此外，HA可以基于GNM中的“a”标志，使用代码为0的GNAM回复MN。
The HA MUST also check that the extensions present in the Generic Notification Message are permitted for use with the GNM. If not, the HA MUST silently discard the message. It MUST NOT do any further processing with such a notification, though it SHOULD log the error.
HA还必须检查通用通知消息中的扩展是否允许与GNM一起使用。如果没有，HA必须默默地丢弃该消息。它不能对这样的通知进行任何进一步的处理，尽管它应该记录错误。
If the GNM came from the FA only, and if the "A" flag is set in the GNM, then the HA MUST send a GNAM. The message is as follows: The source address is the HA's address, the destination address is the FA's address, and the "MD" value is set to 1. The ordering of the extension is: any non-authentication Extensions intended for the FA, followed by the Foreign-Home Authentication extension defined in Section 3.5.4 of [RFC5944].
如果GNM仅来自FA，并且GNM中设置了“A”标志，则HA必须发送GNAM。消息如下：源地址是HA的地址，目标地址是FA的地址，“MD”值设置为1。扩展的顺序是：任何针对FA的非认证扩展，然后是[RFC5944]第3.5.4节中定义的外国家庭认证扩展。
The Code field of the GNAM is chosen in accordance with the rules specified in Section 4.2. When replying to an accepted GNM, an MN SHOULD respond with Code 0.
根据第4.2节规定的规则选择GNAM的代码字段。在回复接受的GNM时，MN应以代码0进行响应。
If the GNM came from the MN, and if the "A" flag is set in the GNM, then the HA MUST send a GNAM. The message is as follows: The source address is the HA's address, the destination address is the FA's address, and the "MD" value is set to 0. The ordering of the extension is: any non-authentication extensions intended for the MN, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], optionally followed by any non-authentication extensions intended for the FA, optionally followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944].
如果GNM来自MN，并且GNM中设置了“A”标志，则HA必须发送GNAM。消息如下：源地址是HA的地址，目标地址是FA的地址，“MD”值设置为0。扩展的顺序为：任何针对MN的非认证扩展，后跟[RFC5944]第3.5.2节中定义的MN-HA AE，可选后跟任何针对FA的非认证扩展，可选后跟[RFC5944]第3.5.3节中定义的MN-FA AE。
This document defines the Generic Notification Message used with the Message String Extension [RFC4917].
本文档定义了与消息字符串扩展[RFC4917]一起使用的通用通知消息。
However, it is possible to define new notification-related extensions for use with the Generic Notification Message, for cases where the notification is intended to have a semantic content and is intended for the HA, FA, or MN, rather than for the user.
然而，对于通知旨在具有语义内容且旨在针对HA、FA或MN而不是针对用户的情况，可以定义与通用通知消息一起使用的新通知相关扩展。
One example of such usage, which would have been defined in this document if it hadn't already been defined as a separate message, is the Registration Revocation Message [RFC3543]. This is a message sent from the HA to the FA(s) or MN to notify the receiving node that a currently active registration is being revoked. The use case for this is clearly laid out in [RFC3543].
这种用法的一个例子是注册撤销消息[RFC3543]，如果没有将其定义为单独的消息，本文档中会对其进行定义。这是从HA发送到FA或MN的消息，用于通知接收节点当前活动的注册正在被撤销。[RFC3543]中明确列出了这方面的用例。
Another example would be managed maintenance switch-over between HA instances, where an HA due to go down for maintenance could direct the MNs registered with it to re-register with another specified HA.
另一个例子是HA实例之间的托管维护切换，其中一个因维护而停机的HA可以指示向其注册的MNs向另一个指定的HA重新注册。
Such a message could also be used for managed load balancing. There is currently no support for such forced switch-over in the Mobile IPv4 protocol.
这样的消息也可以用于托管负载平衡。移动IPv4协议目前不支持这种强制切换。
Yet another example is when the prefix set handled by an MIPv4 NEMO [RFC5177] HA changes; to ensure proper routing, the mobile router needs to be notified about the change so that its internal routing rules may be updated.
另一个例子是当MIPv4 NEMO[RFC5177]HA处理的前缀集改变时；为了确保正确的路由，需要通知移动路由器更改，以便更新其内部路由规则。
One final example is home network changes that require host configuration changes, for instance, a change of address for the DNS server or another network server. Again, this is a case where the HA would want to notify the MN of the change, so that service interruptions can be avoided.
最后一个示例是需要更改主机配置的家庭网络更改，例如，更改DNS服务器或其他网络服务器的地址。同样，在这种情况下，HA希望将更改通知MN，以便避免服务中断。
In order to avoid making the MIPv4 Generic Notification Message a generic protocol extension mechanism by which new protocol mechanisms could be implemented without appropriate discussion and approval, any new extensions that are to be used with the Generic Notification Message must be registered with IANA, where registration is limited by the 'RFC Required' policy defined in [RFC5226].
为了避免使MIPv4通用通知消息成为一种通用协议扩展机制，通过该机制可以在没有适当讨论和批准的情况下实现新的协议机制，任何与通用通知消息一起使用的新扩展必须在IANA注册，注册受[RFC5226]中定义的“需要RFC”政策的限制。
If additional extensions are specified for use with the Generic Notification Message, the practice exemplified in [RFC5944] and related specifications should be followed. Generally, it has not been necessary so far to provide versioning support within individual extensions; in a few cases, it has been necessary to define new extensions with new extension numbers where a generalization of a pre-existing extension has been needed. With the current rate of extension number consumption, that seems to be an acceptable approach.
如果指定其他扩展名用于通用通知消息，则应遵循[RFC5944]和相关规范中举例说明的实践。一般来说，到目前为止还没有必要在单个扩展中提供版本控制支持；在少数情况下，有必要使用新的分机号定义新的分机，其中需要对先前存在的分机进行泛化。根据目前的分机号消耗率，这似乎是一种可接受的方法。
If at some point extensions are specified for use with the Generic Notification Message that overlap with pre-existing notification messages, the authors of the specification should consider providing a method to flag which notification messages are supported, and which notification message usage is requested, in a manner similar to the way tunneling method capabilities and usage requests are flagged in the Mobile IPv4 base specification [RFC5944].
如果在某个点扩展指定与通用通知消息一起使用，该通告消息与预先存在的通知消息重叠，则规范的作者应该考虑提供一种方法来标记哪些通知消息被支持，以及请求哪个通知消息使用。与移动IPv4基本规范[RFC5944]中标记隧道方法功能和使用请求的方式类似。
Encoded in the extension number of Mobile IPv4 extensions is the notion of 'skippable' and 'not skippable' extensions; see Section 1.8 of [RFC5944]. This notion is also applicable when extensions are used with the Generic Notification Message: It is not required that a receiver understand a skippable extension, but a non-skippable extension needs to be handled according to Section 1.8 of [RFC5944]
在移动IPv4扩展的扩展编号中编码的是“可跳过”和“不可跳过”扩展的概念；见[RFC5944]第1.8节。当扩展与通用通知消息一起使用时，此概念也适用：不要求接收方理解可跳过的扩展，但需要根据[RFC5944]第1.8节处理不可跳过的扩展
(i.e., the message must be silently discarded if the extension is not recognized). This document does not specify any change from the Mobile IPv4 base specification [RFC5944] in this respect.
（即，如果无法识别扩展名，则必须以静默方式丢弃消息）。在这方面，本文档未指定移动IPv4基本规范[RFC5944]的任何更改。
This document defines two new messages, the Generic Notification Message described in Section 4.1, and the Generic Notification Acknowledgement Message described in Section 4.2. The message numbers for these two messages have been allocated from the same number space used by the Registration Request and Registration Reply messages in [RFC5944].
本文件定义了两条新消息，第4.1节中描述的通用通知消息和第4.2节中描述的通用通知确认消息。这两条消息的消息编号已从[RFC5944]中注册请求和注册回复消息使用的相同编号空间中分配。
The Generic Notification Message may only carry extensions that are explicitly permitted for use with this message. Section 4.1 of this document defines 4 extensions that are permitted. IANA has added a column to the registry of Mobile IPv4 extensions, which will indicate for each extension if it is permitted for use with the Generic Notification Message. Approval of new extensions that are permitted for use with the Generic Notification Message requires that they be defined in an RFC according to the 'RFC Required' policy described in [RFC5226].
通用通知消息只能包含明确允许与此消息一起使用的扩展名。本文件第4.1节定义了允许的4种扩展。IANA在移动IPv4扩展的注册表中添加了一列，该列将指示每个扩展是否允许与通用通知消息一起使用。批准允许与通用通知消息一起使用的新扩展需要根据[RFC5226]中描述的“需要RFC”策略在RFC中定义它们。
The Generic Notification Acknowledgement Message, specified in Section 4.2, has a Code field. The number space for the Code field values is new and also specified in Section 4.2. The Code number space is structured according to whether the notification was successful, the HA denied the notification, the FA denied the notification, or the MN denied the notification, as follows:
第4.2节中规定的通用通知确认消息具有代码字段。代码字段值的数字空间是新的，并且在第4.2节中也有规定。根据通知是否成功、HA是否拒绝通知、FA是否拒绝通知或MN是否拒绝通知来构造代码空间，如下所示：
0 Success Code 64-69 Error Codes from the FA 128-133 Error Codes from the HA 192-197 Error Codes from the MN
0成功代码64-69错误代码来自FA 128-133错误代码来自HA 192-197错误代码来自MN
Approval of new Code values requires expert review.
新代码值的批准需要专家审查。
This specification operates with the security constraints and requirements of [RFC5944]. This means that when this message is transmitted between the MN and the HA, the MN-HA AE is REQUIRED; when this message is transmitted between the MN and the FA, the MN-FA AE is REQUIRED; when this message is transmitted between the FA and the HA, the FA-HA AE is REQUIRED. It extends the operations of the MN, HA, and FA defined in [RFC5944] to notify each other about some events. The GNM defined in this specification could carry
本规范在[RFC5944]的安全约束和要求下运行。这意味着，当该消息在MN和HA之间传输时，需要MN-HA AE；当该消息在MN和FA之间传输时，需要MN-FA AE；当此消息在FA和HA之间传输时，需要FA-HA AE。它扩展了[RFC5944]中定义的MN、HA和FA的操作，以相互通知某些事件。本规范中定义的GNM可携带
information that modifies the mobility bindings. Therefore, the message MUST be integrity protected. Replay protection MUST also be guaranteed.
修改移动绑定的信息。因此，消息必须受到完整性保护。还必须保证重播保护。
RFC 5944 provides replay protection only for Registration Requests sent by the MN. There is no mechanism for replay protection for messages initiated by an FA or HA. The 64-bit Identification field specified in this document (Sections 4.1 and 4.2) for the GNM is used to provide replay protection for the notification messages initiated by the FA or HA.
RFC 5944仅为MN发送的注册请求提供重播保护。对于FA或HA发起的消息，没有重播保护机制。本文件（第4.1节和第4.2节）中为GNM指定的64位标识字段用于为FA或HA发起的通知消息提供重播保护。
The Identification field is used to let the receiving node verify that a GNM has been freshly generated by the sending node, not replayed by an attacker from some previous notification. Two methods are described in this section: timestamps (REQUIRED) and "nonces" (OPTIONAL). All senders and receivers MUST implement timestamp-based replay protection. These nodes MAY also implement nonce-based replay protection
标识字段用于让接收节点验证GNM是由发送节点新生成的，而不是由攻击者从以前的某个通知中重播的。本节描述了两种方法：时间戳（必需）和“nonces”（可选）。所有发送方和接收方必须实施基于时间戳的重播保护。这些节点还可以实现基于nonce的重播保护
The style of replay protection in effect between any two peer nodes among the MN, FA, and HA is part of the mobile security association. A sending node and its receiving node 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.
MN、FA和HA中任意两个对等节点之间有效的重播保护样式是移动安全关联的一部分。发送节点和接收节点必须就将使用哪种重播保护方法达成一致。识别字段的解释取决于后续小节中描述的重放保护方法。
Whatever method is used, the low-order 32 bits of the Identification field MUST be copied unchanged from the GNM to the GNAM. The receiver uses those bits (and the sender's source address) to match the GNAM with corresponding replies. The receiver MUST verify that the low-order 32 bits of any GNAM Identification field are identical to the bits it sent in the GNM.
无论使用何种方法，必须将标识字段的低阶32位原封不动地从GNM复制到GNAM。接收方使用这些位（以及发送方的源地址）将GNAM与相应的应答相匹配。接收器必须验证任何GNAM标识字段的低位32位是否与它在GNM中发送的位相同。
The Identification in a new GNM MUST NOT be the same as in an immediately preceding GNM, and SHOULD NOT repeat while the same security context is being used between the MN and the HA.
新GNM中的标识不得与前一个GNM中的标识相同，并且在MN和HA之间使用相同的安全上下文时不得重复。
The basic principle of timestamp replay protection is that the node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day. Unless specified differently in the security association between the nodes, a default value of 7 seconds MAY be used to limit the time difference. This value SHOULD be greater than 3 seconds. Obviously, the two nodes must have
时间戳重放保护的基本原理是，生成消息的节点插入当前时间，接收消息的节点检查该时间戳是否足够接近其自己的时间。除非在节点之间的安全关联中有不同的指定，否则可以使用默认值7秒来限制时间差。该值应大于3秒。显然，这两个节点必须具有
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.
充分同步的时钟。与任何消息一样，时间同步消息可以通过由两个节点之间的安全上下文确定的认证机制来防止篡改。
In this document, the timestamps are used, and the sender MUST set the Identification field to a 64-bit value formatted as specified by the Network Time Protocol (NTP) [RFC5905]. The low-order 32 bits of the NTP format represent fractional seconds. Note, however, that when using timestamps, the 64-bit Identification used in a GNM from the sender MUST be greater than that used in any previous GNM, as the receiver uses this field also as a sequence number. Without such a sequence number, it would be possible for a delayed duplicate of an earlier GNM to arrive at the receiver (within the clock synchronization required by the receiver), and thus be applied out of order, mistakenly altering the sender's current status.
在本文档中，使用了时间戳，发送方必须将标识字段设置为64位值，格式按照网络时间协议（NTP）[RFC5905]的规定。NTP格式的低位32位表示小数秒。但是，请注意，当使用时间戳时，发送方在GNM中使用的64位标识必须大于之前任何GNM中使用的标识，因为接收方也将此字段用作序列号。如果没有这样的序列号，早期GNM的延迟副本可能到达接收器（在接收器要求的时钟同步范围内），从而无序应用，错误地改变发送方的当前状态。
Upon receipt of a GNM with an authorization-enabling extension, the receiver 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 receiver's time-of-day clock and the timestamp MUST be greater than all previously accepted timestamps for the requesting sender. Time tolerances and re-synchronization details are specific to a particular mobility security association.
在收到带有授权启用扩展的GNM后，接收方必须检查标识字段的有效性。为了有效，标识字段中包含的时间戳必须足够接近接收方的时间时钟，并且时间戳必须大于请求发送方先前接受的所有时间戳。时间容差和重新同步细节特定于特定的移动安全关联。
If the timestamp is valid, the receiver copies the entire Identification field into the GNAM, and it returns the GNAM to the sender. If the timestamp is not valid, the receiver copies only the low-order 32 bits into the GNAM, and supplies the high-order 32 bits from its own time of day. In this latter case, the receiver MUST reject the notification by returning Code 69, 133, or 197 (notification Identification mismatch) in the GNAM.
如果时间戳有效，则接收方将整个标识字段复制到GNAM中，并将GNAM返回给发送方。如果时间戳无效，则接收器仅将低阶32位复制到GNAM中，并从其自己的时间提供高阶32位。在后一种情况下，接收方必须通过在GNAM中返回代码69、133或197（通知标识不匹配）来拒绝通知。
Furthermore, the receiver MUST verify that the low-order 32 bits of the Identification in the GNAM are identical to those in the rejected GNM attempt, before using the high-order bits for clock re-synchronization.
此外，在使用高阶位进行时钟重新同步之前，接收机必须验证GNAM中标识的低阶32位与被拒绝的GNM尝试中的标识相同。
The basic principle of nonce replay protection is that node A includes a new random number in every message to node B, and checks that node B returns that same number in its next message to node A. Both messages use an authentication code to protect against alteration by an attacker. At the same time, node B can send its own nonces in all messages to node A (to be echoed by node A), so that it too can verify that it is receiving fresh messages.
nonce replay保护的基本原理是，节点A在发送给节点B的每条消息中包含一个新的随机数，并检查节点B是否在发送给节点A的下一条消息中返回相同的数字。这两条消息都使用身份验证码来防止攻击者的更改。同时，节点B可以在所有消息中向节点A发送其自己的nonce（由节点A回送），以便它也可以验证它正在接收新消息。
The receiver may be expected to have resources for computing pseudo-random numbers useful as nonces, according to [RFC4086]. It inserts a new nonce as the high-order 32 bits of the Identification field of every GNAM. The receiver copies the low-order 32 bits of the Identification field from the GNM into the low-order 32 bits of the Identification field in the GNAM. When the sender receives an authenticated GNAM from the receiver, it saves the high-order 32 bits of the Identification field for use as the high-order 32 bits of its next GNM.
根据[RFC4086]，接收机可能被期望具有用于计算可用作nonce的伪随机数的资源。它插入一个新的nonce作为每个GNAM的标识字段的高阶32位。接收机将标识字段的低阶32位从GNM复制到GNAM中标识字段的低阶32位。当发送方从接收方接收经过身份验证的GNAM时，它保存标识字段的高阶32位，以用作其下一个GNM的高阶32位。
The sender is responsible for generating the low-order 32 bits of the Identification field in each GNM. Ideally, it should generate its own random nonces. However, it may use any expedient method, including duplication of the random value sent by the receiver. The method chosen is of concern only to the sender because it is the node that checks for valid values in the GNAM. The high-order and low-order 32 bits of the Identification chosen SHOULD both differ from their previous values. For each notification message, the receiver uses a new high-order value and the sender uses a new low-order value.
发送方负责在每个GNM中生成标识字段的低阶32位。理想情况下，它应该生成自己的随机nonce。然而，它可以使用任何方便的方法，包括复制接收器发送的随机值。选择的方法只与发送方有关，因为它是检查GNAM中有效值的节点。所选标识的高阶和低阶32位均应与其先前的值不同。对于每个通知消息，接收方使用新的高阶值，而发送方使用新的低阶值。
If a GNM is rejected because of an invalid nonce, the GNAM always provides the sender with a new nonce to be used in the next message. Thus, the nonce protocol is self-synchronizing.
如果GNM因无效的nonce而被拒绝，则GNAM始终向发送方提供一个新的nonce，以便在下一条消息中使用。因此，nonce协议是自同步的。
When the FA is relaying a GNM between the MN and the HA, and if the FA does not share a mobility security association with the MN or HA, all non-authentication extensions between the MN and FA, or FA and HA, are not protected. In this case, all non-authentication extensions should be silently discarded.
当FA在MN和HA之间中继GNM时，并且如果FA不与MN或HA共享移动安全关联，则MN和FA或FA和HA之间的所有非认证扩展都不受保护。在这种情况下，所有非身份验证扩展都应该被默默地丢弃。
The authors appreciate the efforts of Ahmad Muhanna for his detailed review of and his many contributions to the text of this document. The author also wants to thank Kent Leung, Peng Yang, Peter McCann, et al., for their helping developing this document. Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E. Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu, Tim Polk, Amanda Baber, Sebastian Thalanany, and Joseph Salowey for their discussion and comments. Thanks to Jari Arkko for help at each step of this document's development.
作者赞赏Ahmad Muhanna对本文件的详细审查和对本文件文本的许多贡献。作者还要感谢Kent Leung、Peng Yang、Peter McCann等帮助编写本文件。感谢Alexey Melnikov、Sean Turner、Ralph Droms、Charles E.Perkins、Russ Housley、Magnus Westerlund、Lars Eggert、Dan Romascanu、Tim Polk、Amanda Baber、Sebastian Thalanany和Joseph Salowey的讨论和评论。感谢Jari Arkko在本文档开发的每一步提供的帮助。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543]Glass，S.和M.Chandra，“移动IPv4中的注册撤销”，RFC 3543，2003年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message String Extension", RFC 4917, June 2007.
[RFC4917]Sastry，V.，Leung，K.，和A.Patel，“移动IPv4消息字符串扩展”，RFC 49172007年6月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]Perkins，C.，“IPv4的IP移动支持，修订版”，RFC 59442010年11月。
[RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, "Network Mobility (NEMO) Extensions for Mobile IPv4", RFC 5177, April 2008.
[RFC5177]Leung，K.，Dommety，G.，Narayanan，V.，和A.Petrescu，“移动IPv4的网络移动（NEMO）扩展”，RFC 5177，2008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Hui Deng China Mobile 53A, Xibianmennei Ave., Xuanwu District, Beijing 100053 China
惠登中国移动北京市宣武区西边门内大街53A，邮编：100053
EMail: denghui02@gmail.com
EMail: denghui02@gmail.com
Henrik Levkowetz Netnod Franzengatan 5 S-104 25, Stockholm SWEDEN
瑞典斯德哥尔摩Henrik Levkowetz Netnod Franzengatan 5 S-104 25
EMail: henrik@levkowetz.com
EMail: henrik@levkowetz.com
Vijay Devarapalli Vasona Networks 2900 Lakeside Drive Santa Clara, CA 95054 USA
Vijay Devarapalli Vasona Networks美国加利福尼亚州圣克拉拉湖畔大道2900号，邮编95054
EMail: dvijay@gmail.com
EMail: dvijay@gmail.com
Sri Gundavelli Cisco 170 W.Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134
EMail: sgundave@cisco.com
EMail: sgundave@cisco.com
Brian Haley Hewlett-Packard Company 165 Dascomb Road Andover, MA 01810 USA
Brian Haley Hewlett-Packard Company 165 Dascomb Road Andover，马萨诸塞州01810
EMail: brian.haley@hp.com
EMail: brian.haley@hp.com