Network Working Group K. Leung
Request for Comments: 5177 G. Dommety
Category: Standards Track Cisco Systems
V. Narayanan
Qualcomm, Inc.
A. Petrescu
Motorola
April 2008
Network Working Group K. Leung
Request for Comments: 5177 G. Dommety
Category: Standards Track Cisco Systems
V. Narayanan
Qualcomm, Inc.
A. Petrescu
Motorola
April 2008
Network Mobility (NEMO) Extensions for Mobile IPv4
移动IPv4的网络移动（NEMO）扩展
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）。本备忘录的分发不受限制。
Abstract
摘要
This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function.
本文档描述了通过扩展移动IPv4协议来支持移动路由器和归属代理之间的移动网络的协议。移动路由器负责一起移动的一个或多个网段或子网的移动性。移动路由器对移动网络上的节点隐藏其移动性。移动网络上的节点可以相对于移动路由器固定，并且可以不具有任何移动功能。
Extensions to Mobile IPv4 are introduced to support Mobile Networks.
引入了对移动IPv4的扩展以支持移动网络。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Examples of Mobile Networks . . . . . . . . . . . . . . . 3
1.2. Overview of Protocol . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 8
4.1. Mobile Network Request Extension . . . . . . . . . . . . . 8
4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 9
5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 11
5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 12
5.2. Mobile Router Management . . . . . . . . . . . . . . . . . 12
6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 13
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 14
6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 14
6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 14
6.4. Advertising Mobile Network Reachability . . . . . . . . . 16
6.5. Establishment of Bi-directional Tunnel . . . . . . . . . . 16
6.6. Sending Registration Replies . . . . . . . . . . . . . . . 17
6.7. Mobile Network Prefix Deregistration . . . . . . . . . . . 17
7. Data Forwarding Operation . . . . . . . . . . . . . . . . . . 17
8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . 18
9. Routing Protocol between Mobile Router and Home Agent . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. Security when Dynamic Routing Protocol Is Used . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Examples of Mobile Networks . . . . . . . . . . . . . . . 3
1.2. Overview of Protocol . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 8
4.1. Mobile Network Request Extension . . . . . . . . . . . . . 8
4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 9
5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 11
5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 12
5.2. Mobile Router Management . . . . . . . . . . . . . . . . . 12
6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 13
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 14
6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 14
6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 14
6.4. Advertising Mobile Network Reachability . . . . . . . . . 16
6.5. Establishment of Bi-directional Tunnel . . . . . . . . . . 16
6.6. Sending Registration Replies . . . . . . . . . . . . . . . 17
6.7. Mobile Network Prefix Deregistration . . . . . . . . . . . 17
7. Data Forwarding Operation . . . . . . . . . . . . . . . . . . 17
8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . 18
9. Routing Protocol between Mobile Router and Home Agent . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. Security when Dynamic Routing Protocol Is Used . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
This document describes network mobility extensions to the Mobile IPv4 protocol. The goal of introducing these extensions is to accommodate mobility scenarios where groups of hosts and routers move homogeneously (as a whole). It is required that all hosts and routers in a Mobile Network be able to run applications connecting to the Internet, and be reachable from the Internet.
本文档介绍移动IPv4协议的网络移动性扩展。引入这些扩展的目的是适应主机组和路由器（作为一个整体）均匀移动的移动场景。要求移动网络中的所有主机和路由器能够运行连接到Internet的应用程序，并且可以从Internet访问。
For details regarding terminology related to network mobility (NEMO), a quick read of RFC 4885 [RFC4885] is suggested.
有关网络移动性（NEMO）相关术语的详细信息，建议快速阅读RFC 4885[RFC4885]。
A Mobile Network links together a set of hosts and routers. Connecting this Mobile Network to the Internet is ensured at two levels: first, a Mobile Router is connected on one side to the Mobile Network and on another side to a wireless access system; second, a Home Agent placed on the home link manages traffic between the Correspondent Node and a Local Fixed Node (LFN, a node in the Mobile Network) by means of encapsulating traffic.
移动网络将一组主机和路由器连接在一起。在两个层次上确保将该移动网络连接到因特网：首先，移动路由器在一侧连接到移动网络，在另一侧连接到无线接入系统；第二，放置在归属链路上的归属代理通过封装通信量来管理对应节点和本地固定节点（LFN，移动网络中的节点）之间的通信量。
A scenario of applicability for this Mobile Network is described next. A Mobile Network is formed by a wireless-enabled Personal Digital Assistant (PDA) and a portable photographic camera, linked together by Bluetooth wireless link-layer technology. This is sometimes referred to as a Personal Area Network (PAN). In the illustration below, one can notice the PDA playing the role of a Mobile Router and the camera the role of Local Fixed Node.
接下来描述适用于该移动网络的场景。移动网络由无线个人数字助理（PDA）和便携式照相机组成，通过蓝牙无线链路层技术连接在一起。这有时被称为个人区域网（PAN）。在下图中，可以注意到PDA扮演移动路由器的角色，而相机扮演本地固定节点的角色。
----
| HA |
---- --------
| / \ ----
-+--------| Internet |---------| CN |
\ / ----
--------
/ \
/ \
/ \
---- ----
| AR | | AR |
---- ----
|cellular |cellular
----
| HA |
---- --------
| / \ ----
-+--------| Internet |---------| CN |
\ / ----
--------
/ \
/ \
/ \
---- ----
| AR | | AR |
---- ----
|cellular |cellular
/ |cellular
| ---- ----
Mobile | | MR | |LFN | ---movement-->
Network < ---- ----
| | |
| -+-----------+-
\ Bluetooth
/ |cellular
| ---- ----
Mobile | | MR | |LFN | ---movement-->
Network < ---- ----
| | |
| -+-----------+-
\ Bluetooth
The camera (Local Fixed Node) uploads photographic content to a Correspondent Node (CN) server. When the Mobile Network moves away, the Mobile Router serving the Mobile Network changes its point of attachment from one cellular access (Access Router) to another, obtaining a new Care-of Address. The Home Agent (HA) encapsulates application traffic for the CN and LFN.
摄像机（本地固定节点）将摄影内容上传到对应节点（CN）服务器。当移动网络移开时，服务于移动网络的移动路由器将其连接点从一个蜂窝接入（接入路由器）改变到另一个，从而获得新的转交地址。归属代理（HA）封装了CN和LFN的应用程序通信量。
Whereas the illustration above is a very simple instantiation of the applicability of Mobile IP-based Mobile Networks, more complex Mobile Networks are easily accommodated by the Mobile IPv4 extensions presented in this document (NEMOv4). For example, laptop computers used by passengers in a bus, train, ship, or plane should all be considered as forming Mobile Networks, as long as they move together (homogeneously).
尽管上面的说明是基于移动IP的移动网络的适用性的一个非常简单的实例，但更复杂的移动网络很容易通过本文（NEMOv4）中介绍的移动IPv4扩展来适应。例如，公交车、火车、轮船或飞机上乘客使用的笔记本电脑都应被视为构成移动网络，只要它们一起移动（均匀）。
As introduced previously, this document presents extensions to the Mobile IPv4 protocol. The entities sending and receiving these extensions are the Mobile Router and the Home Agent. The Local Fixed Node is relieved from running Mobile IP software and, although it moves (together with the Mobile Network), its IP stack is not seeing any change in addressing.
如前所述，本文档介绍了移动IPv4协议的扩展。发送和接收这些扩展的实体是移动路由器和归属代理。本地固定节点不再运行移动IP软件，尽管它（与移动网络一起）移动，但其IP堆栈在寻址方面没有任何变化。
Mobility for the entire Mobile Network is supported by the Mobile Router registering its current point of attachment (Care-of Address) to its Home Agent: the Mobile Router sends an extended Registration Request to the Home Agent, which returns an extended Registration Reply. This signaling sets up the tunnel between the two entities, as illustrated in the following figure:
移动路由器向其归属代理注册其当前连接点（转交地址），从而支持整个移动网络的移动性：移动路由器向归属代理发送扩展注册请求，归属代理返回扩展注册回复。该信令在两个实体之间建立隧道，如下图所示：
LFN MR HA CN
| | | |
| | Extended Registration | |
| |---------------------->| |
| | Request | |
| | | |
| | | |
| | Extended Registration | |
| |<----------------------| |
| | Reply | |
| | | |
|<--------o=======================o-------->|
| | Encapsulated | |
| | Application Traffic | |
| | | |
LFN MR HA CN
| | | |
| | Extended Registration | |
| |---------------------->| |
| | Request | |
| | | |
| | | |
| | Extended Registration | |
| |<----------------------| |
| | Reply | |
| | | |
|<--------o=======================o-------->|
| | Encapsulated | |
| | Application Traffic | |
| | | |
The prefix(es) used within a Mobile Network (either implicitly configured on the Home Agent or explicitly identified by the Mobile Router in the Registration Request) is/are advertised by the Home Agent for route propagation in the home network. Traffic to and from nodes in the Mobile Network are tunneled by the Home Agent to the Mobile Router, and vice versa. Though packets from a Local Fixed Node placed in the Mobile Network can be forwarded by the Mobile Router directly without tunneling (if reverse tunneling were not used), these packets will be dropped if ingress filtering is turned on at the Access Router.
在移动网络内使用的前缀（在归属代理上隐式配置或在注册请求中由移动路由器显式标识）由归属代理播发用于归属网络中的路由传播。往返移动网络中节点的流量由归属代理通过隧道传输到移动路由器，反之亦然。尽管来自移动网络中的本地固定节点的数据包可以由移动路由器直接转发而无需隧道（如果未使用反向隧道），但如果接入路由器上的入口过滤打开，这些数据包将被丢弃。
Extensively relating to Mobile IPv4 [RFC3344], this specification addresses mainly the co-located Care-of Address mode. Foreign Agent Care-of Address mode (with 'legacy' Foreign Agents [RFC3344]) is
本规范广泛涉及移动IPv4[RFC3344]，主要解决同址转交地址模式。外部代理转交地址模式（使用“遗留”外部代理[RFC3344]）为
supported but without optimization, and with double encapsulation being used. For an optimization of this mode, the gentle reader is directed to an extension document [NEMOv4-FA].
支持但不进行优化，并使用双重封装。对于该模式的优化，温和的读者被引导到扩展文档[NEMOv4 FA]。
Compared to Mobile IPv4, this document specifies an additional tunnel between a Mobile Router's Home Address and the Home Agent. This tunnel is encapsulated within the normal tunnel between the Care-of Address (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between the Mobile Router and Home Agent is needed to allow the Foreign Agent to direct the decapsulated packet to the proper visiting Mobile Router. However, in co-located CoA mode, the additional tunnel is not essential and could be eliminated because the Mobile Router is the recipient of the encapsulated packets for the Mobile Network; a proposal for this feature is in the extending document mentioned above [NEMOv4-FA].
与移动IPv4相比，本文档指定了移动路由器的主地址和主代理之间的附加隧道。此隧道封装在转交地址（CoA）和归属代理之间的正常隧道中。在外部代理CoA模式下，需要移动路由器和归属代理之间的隧道，以允许外部代理将解除封装的数据包定向到适当的访问移动路由器。然而，在同一位置的CoA模式中，附加隧道不是必需的，并且可以消除，因为移动路由器是移动网络的封装分组的接收者；上述扩展文档[NEMOv4 FA]中有关于此功能的建议。
All traffic between the nodes in the Mobile Network and the Correspondent Nodes passes through the Home Agent. This document does not touch on aspects related to route optimization of this traffic.
移动网络中的节点和对应节点之间的所有流量都通过归属代理。本文件未涉及与该交通路线优化相关的方面。
A similar protocol has been documented in RFC 3963 [RFC3963] for supporting IPv6 Mobile Networks with Mobile IPv6 extensions.
RFC 3963[RFC3963]中记录了一个类似的协议，用于支持带有移动IPv6扩展的IPv6移动网络。
Multihoming for Mobile Routers is outside the scope of this document.
移动路由器的多主不在本文档范围内。
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]中所述进行解释。
Terminology for Mobile IPv4 mobility support is defined in RFC 3344 [RFC3344]. Terminology for network mobility support (NEMO), from an IPv6 perspective, is described in RFC 4885 [RFC4885]. In addition, this document defines the following terms for NEMOv4.
RFC 3344[RFC3344]中定义了移动IPv4移动支持的术语。RFC 4885[RFC4885]从IPv6的角度介绍了网络移动性支持（NEMO）的术语。此外，本文件定义了NEMOv4的以下术语。
Mobile Router
移动路由器
RFC 3344 [RFC3344] defines a Mobile Router as a mobile node that can be a router that is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak.
RFC 3344[RFC3344]将移动路由器定义为移动节点，该移动节点可以是负责一个或多个整体网络（可能在飞机、船舶、火车、汽车、自行车或皮划艇上）移动的路由器。
Mobile Network Prefix
移动网络前缀
The network prefix of the subnet delegated to a Mobile Router as the Mobile Network.
作为移动网络委托给移动路由器的子网的网络前缀。
Prefix Table
前缀表
A list of Mobile Network Prefixes indexed by the Home Address of a Mobile Router. The Home Agent manages and uses the Prefix Table to determine which Mobile Network Prefixes belong to a particular Mobile Router.
由移动路由器的家庭地址索引的移动网络前缀列表。归属代理管理并使用前缀表来确定哪些移动网络前缀属于特定的移动路由器。
Local Fixed Node
局部固定节点
RFC 4885 [RFC4885] defines a Local Fixed Node (LFN) to be a fixed node belonging to the Mobile Network and unable to change its point of attachment. This definition should not be confused with "Long, Fat Network, LFN" of RFC 1323 [RFC1323], at least because the latter is pronounced "elephan(t)" whereas a NEMO LFN is distinctively pronounced "elefen".
RFC 4885[RFC4885]将本地固定节点（LFN）定义为属于移动网络且无法更改其连接点的固定节点。该定义不应与RFC 1323[RFC1323]中的“长、胖网络、LFN”混淆，至少因为后者的发音为“elephan（t）”，而NEMO LFN的发音明显为“elefen”。
Although the original Mobile IPv4 specifications stated that Mobile Networks can be supported by the Mobile Router and Home Agent using static configuration or running a routing protocol (see Section 4.5 of RFC 3344 [RFC3344]), there is no solution for explicit registration of the Mobile Networks served by the Mobile Router. A solution needs to provide the Home Agent a means to ensure that a Mobile Router claiming a certain Mobile Network Prefix is authorized to do so. A solution would also expose the Mobile Network Prefixes (and potentially other subnet-relevant information) in the exchanged messages, to aid in network debugging.
尽管原始移动IPv4规范规定，移动路由器和归属代理可以使用静态配置或运行路由协议（参见RFC 3344[RFC3344]第4.5节）支持移动网络，但没有解决方案明确注册移动路由器服务的移动网络。解决方案需要向归属代理提供一种方法，以确保声称某个移动网络前缀的移动路由器被授权这样做。解决方案还将公开交换消息中的移动网络前缀（以及可能的其他子网相关信息），以帮助网络调试。
The following requirements for Mobile Network support are enumerated:
列举了移动网络支持的以下要求：
o A Mobile Router should be able to operate in explicit or implicit mode. A Mobile Router may explicitly inform the Home Agent which Mobile Network(s) need to be propagated via a routing protocol. A Mobile Router may also function in implicit mode, where the Home Agent may learn the Mobile Networks through other means, such as from the AAA server, via pre-configuration, or via a dynamic routing protocol.
o 移动路由器应该能够在显式或隐式模式下运行。移动路由器可以明确地通知归属代理哪些移动网络需要经由路由协议传播。移动路由器也可在隐式模式下工作，其中归属代理可通过诸如从AAA服务器、经由预配置或经由动态路由协议等其他手段来学习移动网络。
o The Mobile Network should be supported using Foreign Agents that are compliant to RFC 3344 [RFC3344] without any changes ('legacy' Foreign Agents).
o 应使用符合RFC 3344[RFC3344]的外部代理支持移动网络，无需任何更改（“传统”外部代理）。
o The Mobile Network should allow Fixed Nodes, Mobile Nodes, or Mobile Routers to be on it.
o 移动网络应允许固定节点、移动节点或移动路由器位于其上。
o The Local Fixed Nodes on a Mobile Network should be able to execute their sessions without running Mobile IP stacks. The Mobile Router managing the LFNs' Mobile Network is 'hiding' mobility events like the changes of the Care-of Address from the Local Fixed Nodes in that Mobile Network.
o 移动网络上的本地固定节点应该能够在不运行移动IP堆栈的情况下执行其会话。管理LFNs的移动网络的移动路由器正在“隐藏”移动事件，例如来自该移动网络中的本地固定节点的转交地址的变化。
For Explicit Mode, the Mobile Router informs the Home Agent about the Mobile Network Prefixes during registration. The Registration Request contains zero, one, or several Mobile Network Request extensions in addition to any other extensions defined by or in the context of RFC 3344 [RFC3344]. When several Mobile Networks need to be registered, each is included in a separate Mobile Network Request extension, with its own Type, Length, Sub-Type, Prefix Length, and Prefix. A Mobile Network Request extension is encoded in Type-Length-Value (TLV) format and respects the following ordering:
对于显式模式，移动路由器在注册期间将移动网络前缀通知归属代理。除了RFC 3344[RFC3344]定义的或在RFC 3344[RFC3344]上下文中定义的任何其他扩展之外，注册请求还包含零个、一个或多个移动网络请求扩展。当需要注册多个移动网络时，每个移动网络都包含在一个单独的移动网络请求扩展中，具有自己的类型、长度、子类型、前缀长度和前缀。移动网络请求扩展以类型长度值（TLV）格式编码，并遵循以下顺序：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
类型：
148 Mobile Network Extension
148移动网络扩展
Length:
长度：
Decimal 6.
小数点6。
Sub-Type:
子类型：
0 (Mobile Network Request)
0（移动网络请求）
Prefix Length:
前缀长度：
8-bit unsigned integer indicating the number of leftmost bits covering the network part of the address contained in the Prefix field.
8位无符号整数，表示包含在前缀字段中的地址网络部分的最左端位数。
Prefix:
前缀：
32-bit unsigned integer in network byte-order containing an IPv4 address whose leftmost Prefix Length bits make up the Mobile Network Prefix.
网络字节顺序的32位无符号整数，包含IPv4地址，其最左边的前缀长度位构成移动网络前缀。
The Registration Reply contains zero, one or several Mobile Network Acknowledgement extensions in addition to any other extensions defined by or in the context of RFC 3344 [RFC3344]. For Implicit Mode, the Mobile Network Acknowledgement informs the Mobile Router the prefixes for which the Home Agent sets up forwarding with respect to this Mobile Router. Policies such as permitting only traffic from these Mobile Networks to be tunneled to the Home Agent may be applied by the Mobile Router. For Explicit Mode, when several Mobile Networks need to be acknowledged explicitly, each is included in a separate Mobile Network Acknowledgement extension, with its own Type, Sub-Type, Length, Prefix, and Prefix Length fields. At least one Mobile Network Acknowledgement extension MUST be in a successful Registration Reply to indicate to the Mobile Router that the Mobile Network Request extension was processed, and therefore was not skipped by the Home Agent.
除了RFC 3344[RFC3344]定义的或在RFC 3344[RFC3344]上下文中定义的任何其他扩展之外，注册应答还包含零个、一个或多个移动网络确认扩展。对于隐式模式，移动网络确认通知移动路由器归属代理针对该移动路由器设置转发的前缀。移动路由器可以应用诸如仅允许来自这些移动网络的业务通过隧道传输到归属代理的策略。对于显式模式，当需要显式确认多个移动网络时，每个移动网络都包含在单独的移动网络确认扩展中，具有其自己的类型、子类型、长度、前缀和前缀长度字段。成功的注册应答中必须至少有一个移动网络确认扩展，以向移动路由器指示移动网络请求扩展已被处理，因此归属代理未跳过。
A Registration Reply may contain any non-zero number of Explicit Mode and Implicit Mode Acknowledgements sub-types. Both sub-types can be present in a single Registration Reply. A Mobile Network Acknowledgement extension is encoded in Type-Length-Value (TLV) format. When the registration is denied with Code HA_MOBNET_ERROR (Code field in the Registration Reply), the Code field in the included Mobile Network Extension provides the reason for the failure.
注册回复可以包含任何非零数量的显式模式和隐式模式确认子类型。这两个子类型都可以出现在单个注册回复中。移动网络确认扩展以类型长度值（TLV）格式编码。当注册被拒绝且代码为HA_MOBNET_ERROR（注册回复中的代码字段）时，包含的移动网络扩展中的代码字段将提供失败的原因。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
类型：
148 Mobile Network Extension
148移动网络扩展
Length:
长度：
Decimal 8.
小数点8。
Sub-Type:
子类型：
1 (Explicit Mode Acknowledgement)
1（显式模式确认）
2 (Implicit Mode Acknowledgement)
2（隐式模式确认）
Code: Value indicating success or failure:
代码：表示成功或失败的值：
0 Success
0成功
1 Invalid prefix (MOBNET_INVALID_PREFIX_LEN)
1无效前缀（移动网络\u无效\u前缀\u LEN）
2 Mobile Router is not authorized for prefix (MOBNET_UNAUTHORIZED)
2移动路由器未授权使用前缀（MOBNET_未授权）
3 Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED)
3转发设置失败（移动网络转发设置失败）
Prefix Length:
前缀长度：
8-bit unsigned integer indicating the number of leftmost bits covering the network part of the address contained in the Prefix field.
8位无符号整数，表示包含在前缀字段中的地址网络部分的最左端位数。
Reserved:
保留：
Sent as zero; ignored on reception.
发送为零；接待时被忽略。
Prefix:
前缀：
32-bit unsigned integer in network byte-order containing an IPv4 address whose leftmost Prefix Length bits make up the Mobile Network Prefix.
网络字节顺序的32位无符号整数，包含IPv4地址，其最左边的前缀长度位构成移动网络前缀。
A Mobile Router's operation is generally derived from the behavior of a Mobile Node, as set in RFC 3344 [RFC3344]. In addition to maintaining mobility bindings for its Home Address, the Mobile Router, together with the Home Agent, maintains forwarding information for the Mobile Network Prefix(es) assigned to the Mobile Router.
移动路由器的操作通常源自移动节点的行为，如RFC 3344[RFC3344]中所述。除了维护其归属地址的移动性绑定之外，移动路由器与归属代理一起维护分配给移动路由器的移动网络前缀的转发信息。
A Mobile Router SHOULD set the 'T' bit to 1 in all Registration Request messages it sends to indicate the need for reverse tunnels for all traffic. Without reverse tunnels, all the traffic from the Mobile Network will be subject to ingress filtering in the visited networks. Upon reception of a successful Registration Reply, the Mobile Router processes the registration in accordance to RFC 3344 [RFC3344]. In addition, the following steps are taken:
移动路由器应在其发送的所有注册请求消息中将“T”位设置为1，以指示所有流量都需要反向通道。如果没有反向隧道，来自移动网络的所有流量都将受到访问网络中的入口过滤。在接收到成功的注册应答时，移动路由器根据RFC 3344[RFC3344]处理注册。此外，还采取了以下步骤：
o Check for Mobile Network Acknowledgement extension(s) in Registration Reply.
o 在注册回复中检查移动网络确认扩展。
o Create tunnel to the Home Agent if the Mobile Router is registered in reverse tunneling mode.
o 如果移动路由器以反向隧道模式注册，则创建到归属代理的隧道。
o Set up default route via this tunnel or egress interface when the Mobile Router is registered with or without reverse tunneling, respectively.
o 当移动路由器分别注册有或没有反向隧道时，通过此隧道或出口接口设置默认路由。
In accordance with this specification, a Mobile Router may operate in one of the following two modes: explicit and implicit. In explicit mode, the Mobile Router includes Mobile Network Prefix information in all Registration Requests (as Mobile Network Request extensions), while in implicit mode it does not include this information in any Registration Request. In the latter case, the Home Agent obtains the Mobile Network Prefixes by other means than Mobile IP. One example of obtaining the Mobile Network Prefix is through static configuration on the Home Agent.
根据本规范，移动路由器可在以下两种模式之一下运行：显式和隐式。在显式模式下，移动路由器在所有注册请求中包括移动网络前缀信息（作为移动网络请求扩展），而在隐式模式下，它不在任何注册请求中包括该信息。在后一种情况下，归属代理通过移动IP以外的其他方式获得移动网络前缀。获取移动网络前缀的一个示例是通过在归属代理上的静态配置。
A Mobile Router can obtain a co-located or Foreign Agent Care-of Address while operating in explicit or implicit modes.
移动路由器在显式或隐式模式下运行时，可以获得同一位置或外部代理转交地址。
For deregistration, the Mobile Router sends a registration request with lifetime set to zero without any Mobile Network Request extensions.
对于取消注册，移动路由器发送一个注册请求，其生存期设置为零，无需任何移动网络请求扩展。
In a Mobile IP Registration Reply message, there may be two Code fields: one proper to the Registration Reply header (the 'proper' Code) and one within the Mobile Network Acknowledgement Extension (simply the 'Code'). A Mobile Router interprets the values of the Code field in the Mobile Network Acknowledgement Extension of the Registration Reply in order to identify any error related to managing the Mobile Network Prefixes by the Home Agent. It also interprets the values of the Code field in the Registration Reply header (the proper Code).
在移动IP注册回复消息中，可能有两个代码字段：一个是注册回复头的“正确”代码字段，另一个是移动网络确认扩展中的“正确”代码字段（简称“代码”）。移动路由器解释注册应答的移动网络确认扩展中的代码字段的值，以便识别与归属代理管理移动网络前缀相关的任何错误。它还解释注册回复头中代码字段的值（正确的代码）。
If the value of the Code field in the Registration Reply (the proper) is set to HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending Registration Requests with any Mobile Network Prefix extensions to that Home Agent.
如果注册回复中代码字段的值（正确）设置为HA_MOBNET_DISALLOWED，则移动路由器必须停止向该归属代理发送带有任何移动网络前缀扩展的注册请求。
If the value of the Code field in the Registration Reply (the proper) is set to HA_MOBNET_ERROR, then the Mobile Router MUST stop sending Registration Requests that contain any of the Mobile Network Prefixes that are defined by the values of the fields Prefix and Prefix Length in the Mobile Network Acknowledgement extension. Note that the registration is denied in this case, and no forwarding for any Mobile Network Prefixes would be set up by the Home Agent for the Mobile Router.
如果注册回复中代码字段的值（正确）设置为HA_MOBNET_ERROR，则移动路由器必须停止发送包含任何移动网络前缀的注册请求，这些前缀由移动网络确认扩展中的字段前缀和前缀长度的值定义。请注意，在这种情况下，注册被拒绝，并且归属代理不会为移动路由器设置任何移动网络前缀的转发。
It is possible that the Mobile Router receives a Registration Reply with no Mobile Network extensions if the registration was processed by a Mobile IPv4 Home Agent that does not support this specification at all. In that case, the absence of Mobile Network extensions must be interpreted by the Mobile Router as the case where the Home Agent does not support Mobile Networks.
如果注册由完全不支持此规范的移动IPv4归属代理处理，则移动路由器可能接收到没有移动网络扩展的注册回复。在这种情况下，移动路由器必须将缺少移动网络扩展解释为归属代理不支持移动网络的情况。
All the error code values have been assigned by IANA; see Section 11.
IANA已分配所有错误代码值；见第11节。
Operating a Mobile Router in a Mobile IPv4 environment has certain requirements on the management of the necessary initial configuration and supervision of the ongoing status information. Mobile Router maintenance indicators may need to be exposed in a manner consistent with other Mobile IPv4 indicators.
在移动IPv4环境中操作移动路由器对管理必要的初始配置和监控正在进行的状态信息有一定的要求。移动路由器维护指示器可能需要以与其他移动IPv4指示器一致的方式公开。
The objects for the Management Information Base (MIB) for Mobile IPv4 are defined in RFC 2006 [RFC2006]. The structure of the basic model of Mobile IP protocol describes three entities: Mobile Node, Home Agent, and Foreign Agent. In addition to these entities, this document proposes a functional entity to be the Mobile Router.
移动IPv4的管理信息库（MIB）的对象在RFC 2006[RFC2006]中定义。移动IP协议基本模型的结构描述了三个实体：移动节点、归属代理和外来代理。除这些实体外，本文件还建议将功能实体作为移动路由器。
The necessary initial configuration at a NEMOv4-enabled Home Agent includes, but is not limited to, the contents of the Prefix Table. The Mobile Router MAY need to store the Mobile Network Prefixes as the initial configuration.
启用NEMOv4的归属代理处的必要初始配置包括但不限于前缀表的内容。移动路由器可能需要存储移动网络前缀作为初始配置。
The definition of MIB objects related to the Mobile Router and to a NEMOv4-enabled Home Agent is outside the scope of this document.
与移动路由器和启用NEMOv4的Home Agent相关的MIB对象的定义不在本文档的范围内。
A Home Agent MUST support all the operations specified in RFC 3344 [RFC3344] for Mobile Node support. The Home Agent MUST support both implicit and explicit modes of operation for a Mobile Router.
归属代理必须支持RFC 3344[RFC3344]中为支持移动节点而指定的所有操作。归属代理必须支持移动路由器的隐式和显式操作模式。
The Home Agent processes the registration in accordance to RFC 3344 [RFC3344], which includes route setup to the Mobile Router's Home Address via the tunnel to the Care-of Address. In addition, for a Mobile Router registering in explicit mode, the following steps are taken:
归属代理根据RFC 3344[RFC3344]处理注册，其包括经由隧道到转交地址到移动路由器的归属地址的路由设置。此外，对于以显式模式注册的移动路由器，采取以下步骤：
1. Check that the Mobile Network Prefix information is valid.
1. 检查移动网络前缀信息是否有效。
2. Ensure the Mobile Network Prefix(es) is/are authorized to be on the Mobile Router.
2. 确保移动网络前缀已授权位于移动路由器上。
3. Create a tunnel to the Mobile Router if it does not already exist.
3. 如果移动路由器尚不存在，请创建到该路由器的隧道。
4. Set up route for the Mobile Network Prefix via this tunnel.
4. 通过此隧道设置移动网络前缀的路由。
5. Propagate Mobile Network Prefix routes via routing protocol if necessary.
5. 如有必要，通过路由协议传播移动网络前缀路由。
6. Send the Registration Reply with the Mobile Network Acknowledgement extension(s).
6. 使用移动网络确认扩展发送注册回复。
If there are any subnet routes via the tunnel to the Mobile Router that are not specified in the Mobile Network extensions, these routes are removed.
如果有任何通过隧道到移动路由器的子网路由未在移动网络扩展中指定，则会删除这些路由。
In the case where the Mobile Node is not permitted to act as a Mobile Router, the Home Agent sends a Registration Reply message whose Code field is HA_MOBNET_DISALLOWED (the proper Code field of the Registration Reply).
在不允许移动节点充当移动路由器的情况下，归属代理发送其代码字段为HA_MOBNET_DISALLOWED（注册应答的正确代码字段）的注册应答消息。
For a Mobile Router registering in implicit mode, the Home Agent performs steps 3-6 above, once the registration request is processed successfully.
对于以隐式模式注册的移动路由器，一旦成功处理注册请求，归属代理将执行上述步骤3-6。
For deregistration, the Home Agent removes the tunnel to the Mobile Router and all routes using this tunnel. The Mobile Network extensions are ignored.
对于注销，归属代理将删除到移动路由器的隧道以及使用此隧道的所有路由。移动网络扩展被忽略。
The Registration Table in the Home Agent, in accordance with RFC 3344 [RFC3344], contains binding information for every Mobile Node registered with it. RFC 3344 [RFC3344] defines the format of a Registration Table. In addition to all the parameters specified by RFC 3344 [RFC3344], the Home Agent MUST store the Mobile Network Prefixes associated with the Mobile Router in the corresponding registration entry, when the corresponding registration was performed in explicit mode. When the Home Agent is advertising reachability to Mobile Network Prefixes served by a Mobile Router, the information stored in the Registration Table can be used.
根据RFC 3344[RFC3344]，归属代理中的注册表包含向其注册的每个移动节点的绑定信息。RFC 3344[RFC3344]定义登记表的格式。除了RFC 3344[RFC3344]指定的所有参数外，当以显式模式执行相应的注册时，归属代理还必须将与移动路由器相关联的移动网络前缀存储在相应的注册条目中。当归属代理向移动路由器服务的移动网络前缀宣传可达性时，可以使用存储在注册表中的信息。
The Home Agent must be able to authorize a Mobile Router for use of Mobile Network Prefixes when the Mobile Router is operating in explicit mode. Also, when the Mobile Router operates in implicit mode, the Home Agent must be able to locate the Mobile Network Prefixes associated with that Mobile Router. The Home Agent may store the Home Address of the Mobile Router along with the Mobile Network prefixes associated with that Mobile Router. If the Mobile Router does not have a Home Address assigned, this table may store the Network Access Identifier (NAI) [RFC2794] of the Mobile Router that will be used in dynamic Home Address assignment.
当移动路由器以显式模式运行时，归属代理必须能够授权移动路由器使用移动网络前缀。此外，当移动路由器以隐式模式运行时，归属代理必须能够定位与该移动路由器相关联的移动网络前缀。归属代理可以存储移动路由器的归属地址以及与该移动路由器相关联的移动网络前缀。如果移动路由器没有分配家庭地址，此表可以存储将在动态家庭地址分配中使用的移动路由器的网络访问标识符（NAI）[RFC2794]。
The Home Agent must process Registration Requests coming from Mobile Routers in accordance with this section. RFC 3344 [RFC3344] specifies that the Home Address of a mobile node registering with a Home Agent must belong to a prefix advertised on the home network. In accordance with this specification, however, the Home Address must be configured from a prefix that is served by the Home Agent, not necessarily the one on the home network.
归属代理必须根据本节处理来自移动路由器的注册请求。RFC 3344[RFC3344]指定向归属代理注册的移动节点的归属地址必须属于归属网络上公布的前缀。然而，根据本规范，必须根据归属代理提供的前缀配置归属地址，而不一定是归属网络上的前缀。
If the Registration Request is valid, the Home Agent checks to see if there are any Mobile Network Prefix extensions included in the Registration Request.
如果注册请求有效，则归属代理将检查注册请求中是否包含任何移动网络前缀扩展。
If so, the Mobile Network Prefix information is obtained from the included extensions, and the Home Address from the Home Address field of the Registration Request. For every Mobile Network Prefix extension included in the registration request, the Home Agent MUST perform a check against the Prefix Table. If the Prefix Table does not contain at least one entry pairing that Home Address to that Mobile Network Prefix, then the check fails; otherwise, it succeeds.
如果是，则从包括的扩展中获得移动网络前缀信息，并从注册请求的Home Address字段中获得Home Address。对于注册请求中包含的每个移动网络前缀扩展，归属代理必须根据前缀表执行检查。如果前缀表不包含将该家庭地址与该移动网络前缀配对的至少一个条目，则检查失败；否则，它就会成功。
Following this check against the Prefix Table, the Home Agent MUST construct a Registration Reply containing Mobile Network Acknowledgement extensions. For a Mobile Network Prefix for which the check was unsuccessful, the Code field in the corresponding Mobile Network Acknowledgement extension should be set to MOBNET_UNAUTHORIZED.
在对前缀表进行此检查之后，归属代理必须构造包含移动网络确认扩展的注册回复。对于检查未成功的移动网络前缀，相应移动网络确认扩展中的代码字段应设置为MOBNET_UNAUTHORIZED。
For a Mobile Network Prefix for which the check was successful, the Code field in the respective Mobile Network Acknowledgement extensions should be set to 0.
对于检查成功的移动网络前缀，相应移动网络确认扩展中的代码字段应设置为0。
The Home Agent MUST attempt to set up forwarding for each Mobile Network Prefix extension for which the Prefix Table check was successful. If the forwarding setup fails for a particular Mobile Network Prefix (for reasons such as not enough memory available or not enough devices available), the Code field in the respective Mobile Network Acknowledgement extension should be set to MOBNET_FWDING_SETUP_FAILED.
归属代理必须尝试为前缀表检查成功的每个移动网络前缀扩展设置转发。如果转发设置因特定移动网络前缀而失败（由于内存不足或设备不足等原因），则相应移动网络确认扩展中的代码字段应设置为MOBNET_FWDING_setup_FAILED。
If forwarding and setup was successful for at least one Mobile Network Prefix, then the Code field (the proper) of the Registration Reply message should be set to 0. Otherwise, when forwarding and setup was unsuccessful for each and every Mobile Network Prefixes, that Code (the proper) should be HA_MOBNET_ERROR.
如果至少有一个移动网络前缀的转发和设置成功，则注册回复消息的代码字段（正确的）应设置为0。否则，当每个移动网络前缀的转发和设置都失败时，该代码（正确的）应该是HA_MOBNET_错误。
If the Registration Request is sent in implicit mode, i.e., without any Mobile Network Request extension, the Home Agent may use pre-configured Mobile Network prefix information for the Mobile Router to set up forwarding.
如果注册请求以隐式模式发送，即，没有任何移动网络请求扩展，则归属代理可以使用移动路由器的预先配置的移动网络前缀信息来设置转发。
If the Home Agent is updating an existing binding entry for the Mobile Router, it MUST check all the prefixes in the Registration Table against the prefixes included in the Registration Request. If one or more Mobile Network prefixes are missing from the included
如果归属代理正在更新移动路由器的现有绑定条目，它必须对照注册请求中包含的前缀检查注册表中的所有前缀。如果包含的列表中缺少一个或多个移动网络前缀
information in the registration request, the Home Agent MUST delete those prefixes from the registration table. Also, the Home Agent MUST disable forwarding for those prefixes.
在注册请求中，归属代理必须从注册表中删除这些前缀。此外，归属代理必须禁用这些前缀的转发。
If all checks are successful, the Home Agent either creates a new entry for the Mobile Router or updates an existing binding entry for it and returns a successful registration reply back to the Mobile Router or the Foreign Agent (if the Registration Request was received from a Foreign Agent).
如果所有检查都成功，则归属代理为移动路由器创建新条目或更新其现有绑定条目，并将成功的注册回复返回给移动路由器或外部代理（如果从外部代理接收到注册请求）。
In accordance with RFC 3344 [RFC3344], the Home Agent does proxy Address Resolution Protocol (ARP) for the Mobile Router Home Address when the Mobile Router Home Address is derived from the home network.
根据RFC 3344[RFC3344]，当移动路由器归属地址来自归属网络时，归属代理对移动路由器归属地址执行代理地址解析协议（ARP）。
If the 'T' bit is set, the Home Agent creates a bi-directional tunnel for the corresponding Mobile Network prefixes or updates the existing bi-directional tunnel. This tunnel is maintained independent of the reverse tunnel for the Mobile Router home address itself.
如果设置了“T”位，则归属代理将为相应的移动网络前缀创建一个双向隧道或更新现有的双向隧道。此隧道独立于移动路由器主地址本身的反向隧道进行维护。
If the Mobile Network prefixes served by the Home Agent are aggregated with the home network prefix and if the Home Agent is the default router on the home network, the Home Agent does not have to advertise the Mobile Network Prefixes. The routes for the Mobile Network Prefix are automatically aggregated into the home network prefix (it is assumed that the Mobile Network Prefixes are automatically aggregated into the home network prefix). If the Mobile Router updates the Mobile Network prefix routes via a dynamic routing protocol, the Home Agent SHOULD propagate the routes on the appropriate networks.
如果由归属代理服务的移动网络前缀与归属网络前缀聚合，并且如果归属代理是归属网络上的默认路由器，则归属代理不必公布移动网络前缀。移动网络前缀的路由自动聚合为家庭网络前缀（假设移动网络前缀自动聚合为家庭网络前缀）。如果移动路由器通过动态路由协议更新移动网络前缀路由，则归属代理应在适当的网络上传播路由。
The Home Agent creates and maintains a bi-directional tunnel for the Mobile Network prefixes of a Mobile Router registered with it. A Home Agent supporting IPv4 Mobile Router operation MUST be able to forward packets destined to the Mobile Network prefixes served by the Mobile Router to its Care-of Address. Also, the Home Agent MUST be able to accept packets tunneled by the Mobile Router with the source address of the outer header set to the Care-of Address of the Mobile Router and that of the inner header set to the Mobile Router's Home Address or an address from one of the registered Mobile Network prefixes.
归属代理为向其注册的移动路由器的移动网络前缀创建并维护双向隧道。支持IPv4移动路由器操作的归属代理必须能够将目的地为移动路由器服务的移动网络前缀的数据包转发到其转交地址。此外，归属代理必须能够接受由移动路由器隧道传输的分组，其中外部报头的源地址设置为移动路由器的转交地址，内部报头的源地址设置为移动路由器的归属地址或来自注册的移动网络前缀之一的地址。
The Home Agent MUST set the status code in the registration reply to 0 to indicate successful processing of the Registration Request and successful setup of forwarding for at least one Mobile Network prefix served by the Mobile Router. The Registration Reply MUST contain at least one Mobile Network Acknowledgement extension.
归属代理必须将注册回复中的状态代码设置为0，以指示成功处理注册请求并成功设置由移动路由器服务的至少一个移动网络前缀的转发。注册回复必须至少包含一个移动网络确认扩展。
If the Home Agent is unable to set up forwarding for one or more Mobile Network prefixes served by the Mobile Router, it MUST set the Mobile Network Acknowledgement Extension status Code in the Registration Reply to MOBNET_FWDING_SETUP_FAILED. When the prefix length is zero or greater than decimal 32, the status Code MUST be set to MOBNET_INVALID_PREFIX_LEN.
如果归属代理无法为移动路由器提供的一个或多个移动网络前缀设置转发，则必须在MOBNET_FWDING_SETUP_FAILED的注册回复中设置移动网络确认扩展状态代码。当前缀长度为零或大于十进制32时，状态代码必须设置为MOBNET\u INVALID\u prefix\u LEN。
If the Mobile Router is not authorized to forward packets to a Mobile Network prefix included in the request, the Home Agent MUST set the Code to MOBNET_UNAUTHORIZED.
如果未授权移动路由器将数据包转发到请求中包含的移动网络前缀，则归属代理必须将代码设置为MOBNET_UNAUTHORIZED。
If the received Registration Request is for deregistration of the Care-of Address, the Home Agent, upon successful processing of it, MUST delete the entry (or entries) from its Registration Table. The Home Agent tears down the bi-directional tunnel and stops forwarding any packets to/from the Mobile Router. The Home Agent MUST ignore any included Mobile Network Request extension in a deregistration request.
如果收到的注册请求是撤销转交地址的注册，则在成功处理该请求后，国内代理必须从其注册表中删除该条目。归属代理撕毁双向隧道并停止向移动路由器转发或从移动路由器转发任何数据包。归属代理必须忽略注销请求中包含的任何移动网络请求扩展。
For traffic to the nodes in the Mobile Network, the Home Agent MUST perform double tunneling of the packet, if the Mobile Router had registered with a Foreign Agent Care-of Address. In this case, the Home Agent MUST encapsulate the packet with the tunnel header (source IP address set to Home Agent, and destination IP address set to Mobile Router's Home Address) and then encapsulate one more time with the tunnel header (source IP address set to Home Agent, and destination IP address set to CoA).
对于移动网络中节点的流量，如果移动路由器已向外部代理转交地址注册，则归属代理必须执行数据包的双重隧道。在这种情况下，归属代理必须使用隧道头（源IP地址设置为归属代理，目标IP地址设置为移动路由器的归属地址）封装数据包，然后使用隧道头（源IP地址设置为归属代理，目标IP地址设置为CoA）再封装一次。
For optimization, the Home Agent SHOULD only encapsulate the packet with the tunnel header (source IP address set to Home Agent, and destination IP address set to CoA) for co-located CoA mode.
为了优化，对于同一位置的CoA模式，归属代理应该仅使用隧道报头（源IP地址设置为归属代理，目标IP地址设置为CoA）封装数据包。
When a Home Agent receives a packet from the Mobile Network prefix in the bi-directional tunnel, it MUST de-encapsulate the packet and route it as a normal IP packet. It MUST verify that the incoming
当归属代理在双向隧道中接收到来自移动网络前缀的数据包时，它必须对该数据包进行反封装，并将其作为普通IP数据包进行路由。它必须验证传入的
packet has the source IP address set to the Care-of Address of the Mobile Router. The packet MUST be dropped if the source address is not set to the Care-of Address of the Mobile Router.
数据包的源IP地址设置为移动路由器的转交地址。如果源地址未设置为移动路由器的转交地址，则必须丢弃数据包。
For traffic from the nodes in the Mobile Network, the Mobile Router encapsulates the packet with a tunnel header (source IP address set to Mobile Router's Home Address, and destination IP address set to Home Agent) if reverse tunnel is enabled. Otherwise, the packet is routed directly to the Foreign Agent or access router.
对于来自移动网络中节点的流量，如果启用反向隧道，则移动路由器使用隧道报头（源IP地址设置为移动路由器的主地址，目标IP地址设置为主代理）封装数据包。否则，数据包将直接路由到外部代理或访问路由器。
In co-located CoA mode, the Mobile Router MAY encapsulate one more time with a tunnel header (source IP address set to the CoA and destination IP address set to Home Agent).
在同一位置的CoA模式中，移动路由器可以用隧道报头（源IP地址设置为CoA，目的地IP地址设置为归属代理）再封装一次。
Nested Network Mobility is a scenario where a Mobile Router allows another Mobile Router to attach to its Mobile Network. There could be arbitrary levels of nested mobility. The operation of each Mobile Router remains the same whether the Mobile Router attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution described here does not place any restriction on the number of levels for nested mobility. Two issues should be noted though. First, whenever physical loops occur in a nested aggregation of Mobile Networks, this protocol neither detects nor solves them -- datagram forwarding may be blocked. Second, Mobile Routers in a deep nested aggregation of Mobile Networks might introduce significant overhead on the data packets as each level of nesting introduces another tunnel header encapsulation. Applications that do not support MTU discovery are adversely affected by the additional header encapsulations because the usable MTU is reduced with each level of nesting.
嵌套网络移动性是一种场景，移动路由器允许另一个移动路由器连接到其移动网络。可以有任意级别的嵌套移动。无论移动路由器连接到另一个移动路由器还是互联网上的固定接入路由器，每个移动路由器的操作都保持不变。这里描述的解决方案对嵌套移动性的级别数没有任何限制。但有两个问题需要注意。首先，当移动网络的嵌套聚合中出现物理循环时，该协议既不会检测也不会解决它们——数据报转发可能会被阻止。其次，移动网络的深层嵌套聚合中的移动路由器可能会在数据包上引入大量开销，因为每一层嵌套都会引入另一个隧道头封装。不支持MTU发现的应用程序会受到附加头封装的不利影响，因为每一层嵌套都会减少可用MTU。
There are several benefits of running a dynamic routing protocol between the Mobile Router and the Home Agent. If the Mobile Network is relatively large, including several wireless subnets, then the topology changes within the moving network can be exposed from the Mobile Router to the Home Agent by using a dynamic routing protocol. The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as defined in previous sections, is not to inform the Home Agent about these topology changes, but to manage the mobility of the Mobile Router.
在移动路由器和归属代理之间运行动态路由协议有几个好处。如果移动网络相对较大，包括几个无线子网，则可以通过使用动态路由协议将移动网络中的拓扑变化从移动路由器公开给归属代理。如前几节所述，移动IPv4的NEMOv4协议扩展的目的不是通知归属代理这些拓扑更改，而是管理移动路由器的移动性。
Similarly, topology changes in the home network can be exposed to the Mobile Router by using a dynamic routing protocol. This may be necessary when new fixed networks are added in the home network.
类似地，家庭网络中的拓扑变化可以通过使用动态路由协议暴露给移动路由器。在家庭网络中添加新的固定网络时，这可能是必要的。
Here too, the purpose of NEMOv4 extensions is not to inform the Mobile Router about topology changes at home.
在这里，NEMOv4扩展的目的也不是通知移动路由器在家中的拓扑变化。
Examples of dynamic routing protocols include, but are not limited to, OSPF Version 2 [RFC2328], BGP [RFC4271], and RIP [RFC2453].
动态路由协议的示例包括但不限于OSPF版本2[RFC2328]、BGP[RFC4271]和RIP[RFC2453]。
The recommendations are related to how the routing protocol and the Mobile IPv4 implementation work in tandem on the Mobile Router and on the Home Agent (1) without creating incoherent states in the forwarding information bases at home and on the Mobile Router, (2) without introducing topologically incorrect addressing information in the visited domain, and (3) without duplicating sent data or over-provisioning security.
这些建议涉及路由协议和移动IPv4实现如何在移动路由器和归属代理（1）上协同工作，而不会在家庭和移动路由器（2）的转发信息库中产生不一致状态在访问的域中不引入拓扑不正确的寻址信息，以及（3）不复制发送的数据或过度提供安全性。
The information exchanged between the Mobile Router and the Home Agent is sent over the bi-directional tunnel established by the Mobile IPv4 exchange Registration Request - Registration Reply (see Section 6.5). If a network address and prefix of a subnet in the moving network is sent by the Mobile Router within a routing protocol message, then they SHOULD NOT be sent in the Mobile IPv4 Registration Request too. This avoids incoherencies in the forwarding information bases. The Mobile Router SHOULD use NEMOv4 implicit mode in this case (see Section 3).
移动路由器和归属代理之间交换的信息通过移动IPv4交换注册请求-注册回复（见第6.5节）建立的双向隧道发送。如果移动路由器在路由协议消息中发送移动网络中的子网的网络地址和前缀，则不应在移动IPv4注册请求中发送它们。这避免了转发信息库中的不一致性。在这种情况下，移动路由器应使用NEMOv4隐式模式（见第3节）。
The Mobile Router SHOULD NOT send routing protocol information updates in the foreign network. The subnet addresses and prefixes valid in the moving network are topologically incorrect in the visited network.
移动路由器不应在外部网络中发送路由协议信息更新。在移动网络中有效的子网地址和前缀在访问的网络中拓扑不正确。
If the Mobile Router and the Home Agent use a dynamic routing protocol over the tunnel interface, and if that protocol offers security mechanisms to protect that protocol's messages, then the security recommendations in Section 10.1 apply.
如果移动路由器和归属代理通过隧道接口使用动态路由协议，并且如果该协议提供安全机制来保护该协议的消息，则第10.1节中的安全建议适用。
The Mobile Network extension is protected by the same rules as for Mobile IP extensions in registration messages. See the Security Considerations section in RFC 3344 [RFC3344].
移动网络扩展受到与注册消息中移动IP扩展相同的规则的保护。请参阅RFC 3344[RFC3344]中的安全注意事项部分。
The Home Agent MUST be able to verify that the Mobile Router is authorized to provide mobility service for the Mobile Networks in the Registration Request, before anchoring these Mobile Network Prefixes on behalf of the Mobile Router. Forwarding for prefixes MUST NOT be set up without successful authorization of the Mobile Router for those prefixes. The Mobile Router MUST be notified when there is a registration failure because it cannot be successfully authorized for prefixes it requested.
在代表移动路由器锚定这些移动网络前缀之前，归属代理必须能够验证移动路由器被授权在注册请求中为移动网络提供移动服务。未经移动路由器成功授权，不得设置前缀转发。当出现注册失败时，必须通知移动路由器，因为无法成功授权其请求的前缀。
All Registration Requests and replies MUST be authenticated by the MN-HA Authentication Extension as specified in RFC 3344 [RFC3344]. When the registration request is sent in explicit mode, i.e., with one or more Mobile Network Prefix extensions, all the Mobile Network Prefix extensions MUST be included before the MN-HA Authentication extension. Also, these extensions MUST be included in the calculation of the MN-HA authenticator value.
所有注册请求和回复必须通过RFC 3344[RFC3344]中规定的MN-HA身份验证扩展进行身份验证。当以显式模式发送注册请求时，即，使用一个或多个移动网络前缀扩展，在MN-HA认证扩展之前必须包括所有移动网络前缀扩展。此外，这些扩展必须包括在MN-HA验证器值的计算中。
The Mobile Router should perform ingress filtering on all the packets received on the Mobile Network prior to reverse tunneling them to the Home Agent. The Mobile Router MUST drop any packets that do not have a source address belonging to the Mobile Network.
移动路由器应在将移动网络上接收的所有数据包反向隧道传输到归属代理之前，对其执行入口过滤。移动路由器必须丢弃任何不具有属于移动网络的源地址的数据包。
The Mobile Router MUST also ensure that the source address of packets arriving on the Mobile Network is not the same as the Mobile Router's IP address on any interface. These checks will protect against nodes attempting to launch IP spoofing attacks through the bi-directional tunnel.
移动路由器还必须确保到达移动网络的数据包的源地址与任何接口上移动路由器的IP地址不同。这些检查将防止节点试图通过双向隧道发起IP欺骗攻击。
The Home Agent, upon receiving packets through the bi-directional tunnel, MUST verify that the source addresses of the outer IP header of the packets are set to the Mobile Router's Care-of Address. Also, it MUST ensure that the source address of the inner IP header is a topologically correct address on the Mobile Network. This will prevent nodes from using the Home Agent to launch attacks inside the protected network.
归属代理在通过双向隧道接收分组时，必须验证分组的外部IP报头的源地址是否设置为移动路由器的转交地址。此外，它必须确保内部IP报头的源地址是移动网络上拓扑正确的地址。这将防止节点使用归属代理在受保护的网络内发起攻击。
If a dynamic routing protocol is used between the Mobile Router and the Home Agent to propagate the Mobile Network information into the home network, the routing updates SHOULD be protected with IPsec ESP confidentiality between the Mobile Router and Home Agent, to prevent information about home network topology from being visible to eavesdroppers.
如果在移动路由器和归属代理之间使用动态路由协议将移动网络信息传播到归属网络，则路由更新应在移动路由器和归属代理之间使用IPsec ESP机密性进行保护，防止窃听者看到有关家庭网络拓扑的信息。
IANA has assigned rules for the existing registry "Mobile IPv4 numbers - per RFC 3344". The numbering space for Extensions that may appear in Mobile IP control messages (those sent to and from UDP port number 434) should be modified.
IANA已为现有注册表分配了规则“移动IPv4号码-根据RFC 3344”。应修改移动IP控制消息中可能出现的扩展名的编号空间（发送到UDP端口号434的扩展名和从UDP端口号434发送的扩展名）。
The new Values and Names for the Type for Extensions appearing in Mobile IP control messages are the following:
移动IP控制消息中出现的扩展类型的新值和名称如下：
+-------+--------------------------+
| Value | Name |
+-------+--------------------------+
| 148 | Mobile Network Extension |
+-------+--------------------------+
+-------+--------------------------+
| Value | Name |
+-------+--------------------------+
| 148 | Mobile Network Extension |
+-------+--------------------------+
Table 1: New Values and Names for Extensions in Mobile IP Control Messages
表1：移动IP控制消息中扩展的新值和名称
A new number space has been created for the Values and Names for the Sub-Type for Mobile Network Extensions. This number space is initially defined to hold the following entries, allocated by this document:
已为移动网络扩展的子类型的值和名称创建了一个新的数字空间。此数字空间最初定义为容纳本文档分配的以下条目：
+-------+-----------------------------------------+
| Value | Name |
+-------+-----------------------------------------+
| 0 | Mobile Network Request Extension |
| 1 | Explicit Mode Acknowledgement Extension |
| 2 | Implicit Mode Acknowledgement Extension |
+-------+-----------------------------------------+
+-------+-----------------------------------------+
| Value | Name |
+-------+-----------------------------------------+
| 0 | Mobile Network Request Extension |
| 1 | Explicit Mode Acknowledgement Extension |
| 2 | Implicit Mode Acknowledgement Extension |
+-------+-----------------------------------------+
Table 2: New Values and Names for the Sub-Type for Mobile Network Extensions
表2：移动网络扩展子类型的新值和名称
The policy of future assignments to this number space is following Standards Action or IESG Approval (see [RFC2434]).
该数字空间的未来分配政策遵循标准行动或IESG批准（见[RFC2434]）。
The new Code Values for Mobile IP Registration Reply messages are the following (for a registration denied by the Home Agent):
移动IP注册回复消息的新代码值如下（对于归属代理拒绝的注册）：
+-------+-----------------------------------------------------------+
| Value | Name |
+-------+-----------------------------------------------------------+
| 147 | Mobile Network Prefix operation error (HA_MOBNET_ERROR) |
| 148 | Mobile Router operation is not permitted |
| | (HA_MOBNET_DISALLOWED) |
+-------+-----------------------------------------------------------+
+-------+-----------------------------------------------------------+
| Value | Name |
+-------+-----------------------------------------------------------+
| 147 | Mobile Network Prefix operation error (HA_MOBNET_ERROR) |
| 148 | Mobile Router operation is not permitted |
| | (HA_MOBNET_DISALLOWED) |
+-------+-----------------------------------------------------------+
Table 3: New Code Values for Mobile IP Registration Reply
表3：移动IP注册回复的新代码值
A new number space has been created for the Code Values for the Mobile Network Acknowledgement Extension. This number space is initially defined to hold the following entries, allocated by this document (result of registration, as sent by the Home Agent):
已经为移动网络确认扩展的代码值创建了一个新的数字空间。此数字空间最初定义为保存本文档分配的以下条目（注册结果，由本地代理发送）：
+---+---------------------------------------------------------------+
| 0 | Success |
| 1 | Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) |
| 2 | Mobile Router is not authorized for prefix |
| | (MOBNET_UNAUTHORIZED) |
| 3 | Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) |
+---+---------------------------------------------------------------+
+---+---------------------------------------------------------------+
| 0 | Success |
| 1 | Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) |
| 2 | Mobile Router is not authorized for prefix |
| | (MOBNET_UNAUTHORIZED) |
| 3 | Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) |
+---+---------------------------------------------------------------+
Table 4: New Code Values for Mobile Network Acknowledgement Extension
表4：移动网络确认扩展的新代码值
The policy of future assignments to this number space is following Standards Action or IESG Approval (see [RFC2434]).
该数字空间的未来分配政策遵循标准行动或IESG批准（见[RFC2434]）。
The authors would like to thank Christophe Janneteau, George Popovich, Ty Bekiares, Ganesh Srinivasan, Alpesh Patel, Ryuji Wakikawa, George Tsirtsis, and Henrik Levkowetz for their helpful discussions, reviews, and comments. Vijay Devarapalli extensively reviewed one of the later versions of the document. Hans Sjostrand identified the last clarifications with respect to Foreign Agent mode treatment. Pete McCann contributed necessary refinements of many statements.
作者要感谢克里斯托夫·扬内托、乔治·波波维奇、蒂·贝基亚雷斯、加内什·斯里尼瓦桑、阿尔佩什·帕特尔、卢吉·瓦基卡瓦、乔治·齐尔蒂斯和亨里克·列夫科维茨的有益讨论、评论和评论。Vijay Devarapalli广泛审查了该文件的一个较新版本。Hans Sjostrand确定了关于外国代理模式处理的最后澄清。皮特·麦肯对许多陈述作了必要的修改。
Mobile IPv4 versions as early as 1996 (RFC 2002 by Charles Perkins) described Mobile Networks and Mobile Routers support.
早在1996年，移动IPv4版本（Charles Perkins的RFC 2002）就描述了移动网络和移动路由器的支持。
Fred Templin indicated the potential confusion for the term "LFN".
弗雷德·坦普林指出，“LFN”一词可能会引起混淆。
Amanda Baber of IANA agreed on the principles of allocating numbers for this specification and suggested improvements on the IANA section.
IANA的Amanda Baber同意为本规范分配编号的原则，并建议对IANA部分进行改进。
Tim Polk of the IESG identified a deeply entrenched error on managing the Code fields.
IESG的Tim Polk发现了管理代码字段的一个根深蒂固的错误。
Lars Eggert of the IESG suggested the accommodation of the otherwise legal non-contiguous netmask fields, instead of simply prefix lengths.
IESG的拉尔斯·艾格特（Lars Eggert）建议采用其他合法的非连续网络掩码字段，而不是简单的前缀长度。
Dan Romascanu of the IESG indicated the necessity of manageability of Mobile Routers and NEMOv4-enabled Home Agents and their deployability in MIP4 environments.
IESG的Dan Romascanu指出了移动路由器和支持NEMOv4的家庭代理的可管理性以及它们在MIP4环境中的可部署性的必要性。
David Borman of TSV-DIR reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. The implications of the growth of usable MTU adversely affecting applications deep in a Mobile Network were suggested.
TSV-DIR的David Borman审查了本文件，作为运输区董事会审查关键IETF文件的持续努力的一部分。提出了可用MTU的增长对移动网络深层应用产生不利影响的影响。
Gonzalo Camarillo provided a generalist review by an additional set of eyes for documents as they are being considered for publication (General Area Review Team).
冈萨洛·卡马里洛（Gonzalo Camarillo）通过另一组眼睛对正在考虑出版的文件进行了全面审查（一般领域审查小组）。
Jari Arkko of the IESG reviewed, suggested necessary improvements to, and diligently shepherded this document through IESG.
IESG的Jari Arkko对本文件进行了审查，提出了必要的改进建议，并通过IESG对本文件进行了认真指导。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC2006] Cong, D., Hamlen, M., and C. Perkins, "The Definitions of Managed Objects for IP Mobility Support using SMIv2", RFC 2006, October 1996.
[RFC2006]Cong，D.，Hamlen，M.，和C.Perkins，“使用SMIv2的IP移动性支持的托管对象定义”，RFC 2006，1996年10月。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，1998年11月。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794]Calhoun，P.和C.Perkins，“IPv4移动IP网络访问标识符扩展”，RFC 27942000年3月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[NEMOv4-FA] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, "FA extensions to NEMOv4 Base", Work in Progress, February 2008.
[NEMOv4 FA]Tsirtsis，G.，Park，V.，Narayanan，V.，和K.Leung，“将FA延伸至NEMOv4基地”，正在进行的工作，2008年2月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[RFC4885]Ernst，T.和H-Y.Lach，“网络移动性支持术语”，RFC 48852007年7月。
Authors' Addresses
作者地址
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Kent Leung Cisco Systems 170 W.美国加利福尼亚州圣何塞塔斯曼大道95134号
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Gopal Dommety Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Gopal Dommety Cisco Systems 170 W.塔斯曼大道圣何塞，加利福尼亚州95134
Phone: +1 408-525-1404
EMail: gdommety@cisco.com
Phone: +1 408-525-1404
EMail: gdommety@cisco.com
Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA
Vidya Narayanan高通公司5775 Morehouse Dr San Diego，CA美国
Phone: +1 858-845-2483
EMail: vidyan@qualcomm.com
Phone: +1 858-845-2483
EMail: vidyan@qualcomm.com
Alexandru Petrescu Motorola Parc les Algorithmes Saint Aubin Gif-sur-Yvette, Essonne 91140 France
Alexandru Petrescu Motorola Parc les Algorithmes Saint Aubin Gif sur Yvette，法国埃松91140
Phone: +33 169354827
EMail: alexandru.petrescu@motorola.com
Phone: +33 169354827
EMail: alexandru.petrescu@motorola.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.