Network Working Group T. Ernst
Request for Comments: 4886 INRIA
Category: Informational July 2007
Network Working Group T. Ernst
Request for Comments: 4886 INRIA
Category: Informational July 2007
Network Mobility Support Goals and Requirements
网络移动性支持目标和要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution.
当将网络连接到因特网的路由器动态地改变其到因特网的连接点，从而导致相对于固定因特网拓扑改变所述网络的可达性时，产生网络移动性。这种类型的网络被称为移动网络。通过适当的机制，在移动路由器改变其连接点后，可以维持在移动网络和全球因特网中的节点之间建立的会话。本文件概述了网络移动性支持的预期目标，并定义了NEMO基本支持解决方案必须满足的要求。
Table of Contents
目录
1. Introduction ....................................................2
2. NEMO Working Group Objectives and Methodology ...................3
3. NEMO Support Design Goals .......................................5
3.1. Migration Transparency .....................................5
3.2. Performance Transparency and Seamless Mobility .............5
3.3. Network Mobility Support Transparency ......................5
3.4. Operational Transparency ...................................5
3.5. Arbitrary Configurations ...................................5
3.6. Local Mobility and Global Mobility .........................6
3.7. Scalability ................................................7
3.8. Backward Compatibility .....................................7
3.9. Secure Signaling ...........................................7
3.10. Location Privacy ..........................................8
3.11. IPv4 and NAT Traversal ....................................8
3.12. Minimal Impact on Internet Routing ........................8
4. NEMO Basic Support One-Liner Requirements .......................8
5. Security Considerations ........................................10
6. Acknowledgments ................................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
1. Introduction ....................................................2
2. NEMO Working Group Objectives and Methodology ...................3
3. NEMO Support Design Goals .......................................5
3.1. Migration Transparency .....................................5
3.2. Performance Transparency and Seamless Mobility .............5
3.3. Network Mobility Support Transparency ......................5
3.4. Operational Transparency ...................................5
3.5. Arbitrary Configurations ...................................5
3.6. Local Mobility and Global Mobility .........................6
3.7. Scalability ................................................7
3.8. Backward Compatibility .....................................7
3.9. Secure Signaling ...........................................7
3.10. Location Privacy ..........................................8
3.11. IPv4 and NAT Traversal ....................................8
3.12. Minimal Impact on Internet Routing ........................8
4. NEMO Basic Support One-Liner Requirements .......................8
5. Security Considerations ........................................10
6. Acknowledgments ................................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
Network mobility support (see [1] for the related terminology) is concerned with managing the mobility of an entire network, viewed as a single unit that changes its point of attachment to the Internet and thus its reachability in the Internet topology. Such a network is referred to as a mobile network and includes one or more mobile routers (MRs), which connect it to the global Internet. Nodes behind the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal structure of the mobile network will be relatively stable (no dynamic change of the topology), but this is not always true.
网络移动性支持（相关术语见[1]）涉及管理整个网络的移动性，将其视为一个单元，改变其与互联网的连接点，从而改变其在互联网拓扑中的可达性。这种网络称为移动网络，包括一个或多个将其连接到全球互联网的移动路由器（MRs）。MR（MNN）后面的节点既有固定（LFN）也有移动（VMN或LMN）。在大多数情况下，移动网络的内部结构将相对稳定（拓扑结构不会发生动态变化），但这并不总是正确的。
Cases of mobile networks include, for instance:
例如，移动网络的情况包括：
o Networks attached to people (Personal Area Networks or PANs): a cell phone with one cellular interface and one Bluetooth interface together with a Bluetooth-enabled PDA constitute a very simple instance of a mobile network. The cell phone is the mobile router while the PDA is used for web browsing or runs a personal web server.
o 与人相连的网络（个人区域网络或PAN）：带有一个蜂窝接口和一个蓝牙接口的手机以及支持蓝牙的PDA构成了移动网络的一个非常简单的实例。手机是移动路由器，而PDA用于网络浏览或运行个人网络服务器。
o Networks of sensors and computers deployed in vehicles: vehicles are increasingly equipped with a number of processing units for safety and ease of driving reasons, as advocated by ITS (Intelligent Transportation Systems) applications ([4]).
o 部署在车辆上的传感器和计算机网络：为了安全和方便驾驶，车辆越来越多地配备了许多处理单元，正如ITS（智能交通系统）应用所提倡的那样（[4]）。
o Access networks deployed in public transportation (buses, trains, taxis, aircrafts): they provide Internet access to IP devices carried by passengers (laptop, camera, mobile phone); host mobility within network mobility or PANs; network mobility within network mobility, i.e., nested mobility (see [1] for the definition of nested mobility).
o 公共交通（公共汽车、火车、出租车、飞机）中部署的接入网络：为乘客携带的IP设备（笔记本电脑、照相机、手机）提供互联网接入；网络移动性或PAN内的主机移动性；网络移动性中的网络移动性，即嵌套移动性（有关嵌套移动性的定义，请参见[1]）。
o Ad-hoc networks connected to the Internet via an MR: for instance, students in a train who need to both set up an ad-hoc network among themselves and get Internet connectivity through the MR connecting the train to the Internet.
o 通过MR连接到Internet的自组织网络：例如，火车上的学生需要在他们之间建立一个自组织网络，并通过MR将火车连接到Internet来获得Internet连接。
Mobility of networks does not cause MNNs to change their own physical point of attachment; however, they do change their topological location with respect to the global Internet. If network mobility is not explicitly supported by some mechanisms, the mobility of the MR results in MNNs losing Internet access and breaking ongoing sessions between arbitrary correspondent nodes (CNs) in the global Internet and those MNNs located within the mobile network. In addition, the communication path between MNNs and correspondent nodes becomes sub-optimal, and multiple levels of mobility will cause extremely sub-optimal routing.
网络的移动性不会导致MNN改变其自身的物理连接点；然而，它们确实改变了它们相对于全球互联网的拓扑位置。如果某些机制不明确支持网络移动性，则MR的移动性会导致MNN失去互联网接入，并中断全球互联网中任意对应节点（CNs）与位于移动网络内的MNN之间正在进行的会话。此外，MNN和对应节点之间的通信路径变得次优，并且多个移动级别将导致极度次优的路由。
Mobility-related terms used in this document are defined in [2], whereas terms specifically pertaining to network mobility are defined in [1]. This document is structured as follows: in Section 2, we define the rough objectives and methodology of the NEMO working group to handle network mobility issues and we emphasize the stepwise approach the working group has decided to follow. A number of desirable design goals are listed in Section 3. Those design goals then serve as guidelines to define the requirements listed in Section 4 for basic network mobility support [3].
本文件中使用的移动性相关术语在[2]中定义，而专门与网络移动性相关的术语在[1]中定义。本文件结构如下：在第2节中，我们定义了NEMO工作组处理网络移动性问题的大致目标和方法，并强调了工作组决定遵循的逐步方法。第3节列出了许多理想的设计目标。然后，这些设计目标将作为指南，用于定义第4节中列出的基本网络移动性支持要求[3]。
The mechanisms required for handling network mobility issues were lacking within the IETF standards when the NEMO working group (WG) was set up at the IETF in 2002. At that time, work conducted on mobility support (particularly in the Mobile IP working group) was to provide continuous Internet connectivity and optimal routing to mobile hosts only (host mobility support). Such mechanisms specified
当NEMO工作组（WG）于2002年在IETF成立时，IETF标准中缺乏处理网络移动性问题所需的机制。当时，关于移动支持的工作（特别是在移动IP工作组中）是为了仅向移动主机提供连续的互联网连接和最佳路由（主机移动支持）。具体规定了这些机制
in Mobile IPv6 [5] are unable to support network mobility. The NEMO working group has therefore been set up to deal with issues specific to network mobility.
在移动IPv6[5]中，无法支持网络移动性。因此，成立了NEMO工作组来处理特定于网络移动性的问题。
The primary objective of the NEMO work is to specify a solution that allows mobile network nodes (MNNs) to remain connected to the Internet and continuously reachable while the mobile router serving the mobile network changes its point of attachment. The secondary goal of the work is to investigate the effects of network mobility on various aspects of Internet communication such as routing protocol changes, implications of real-time traffic and fast handovers, and optimizations. This should support the primary goal of reachability for mobile network nodes. Security is an important consideration too, and efforts should be made to use existing security solutions if they are appropriate. Although a well-designed solution may include security inherent in other protocols, mobile networks also introduce new challenges.
NEMO工作的主要目标是指定一种解决方案，该解决方案允许移动网络节点（MNN）保持与Internet的连接，并在为移动网络服务的移动路由器更改其连接点时持续可访问。这项工作的第二个目标是调查网络移动性对互联网通信各个方面的影响，如路由协议的变化、实时流量和快速切换的影响以及优化。这应该支持移动网络节点可达性的主要目标。安全也是一个重要的考虑因素，如果适当的话，应该努力使用现有的安全解决方案。尽管设计良好的解决方案可能包括其他协议固有的安全性，但移动网络也带来了新的挑战。
To complete these tasks, the NEMO working group has decided to take a stepwise approach. The steps in this approach include standardizing a basic solution to preserve session continuity (NEMO Basic Support, see [3]) and studying the possible approaches and issues with providing more optimal routing with potentially nested mobile networks (NEMO Extended Support, see [6] and [7] for a discussion on routing optimization issues and [8] for a discussion on multihoming issues). However, the working group is not chartered to actually standardize a solution for Extended Support at this point in time. If deemed necessary, the working group will be rechartered based on the conclusions of the discussions.
为了完成这些任务，NEMO工作组决定采取逐步的方法。该方法中的步骤包括标准化基本解决方案以保持会话连续性（NEMO基本支持，请参见[3]），以及研究可能的方法和问题，以提供具有潜在嵌套移动网络的更优化路由（NEMO扩展支持，请参见[6]和[7]以了解路由优化问题的讨论和[8]用于讨论多宿主问题）。然而，工作组并没有被授权在此时实际标准化扩展支持的解决方案。如有必要，工作组将根据讨论的结论重新分组。
For NEMO Basic Support, the working group assumes that none of the nodes behind the MR is aware of the network's mobility; thus, the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption accommodates nodes inside the network that are not generally aware of mobility.
对于NEMO基本支持，工作组假设MR后面的节点都不知道网络的移动性；因此，网络的移动需要对移动网络内的节点完全透明。这种假设适用于网络内通常不知道移动性的节点。
The efforts of the Mobile IP working group have resulted in the Mobile IPv4 and Mobile IPv6 protocols, which have already solved the issue of host mobility support. Since challenges to enabling mobile networks are vastly reduced by this work, basic network mobility support has adopted the methods for host mobility support used in Mobile IP and has extended them in the simplest way possible to achieve its goals. The Basic Support solution, now defined in [3] following the requirements stated in Section 4 of the present document, is for each MR to have a Home Agent (HA), and use bi-directional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR acquires a Care-of Address (CoA) at its attachment point much like what is done for mobile hosts
移动IP工作组的努力产生了移动IPv4和移动IPv6协议，这些协议已经解决了主机移动性支持问题。由于这项工作大大减少了启用移动网络所面临的挑战，基本网络移动性支持采用了移动IP中使用的主机移动性支持方法，并以最简单的方式对其进行了扩展，以实现其目标。根据本文件第4节所述要求，基本支持解决方案（现在在[3]中定义）为每个MR配备一个归属代理（HA），并在MR和HA之间使用双向隧道，以在MR移动时保持会话连续性。MR在其连接点获得转交地址（CoA），这与移动主机的操作非常相似
(MHs), using Mobile IP. This approach allows nested mobile networks, since each MR will appear to its attachment point as a single node.
（MHs），使用移动IP。这种方法允许嵌套移动网络，因为每个MR在其连接点上显示为单个节点。
This section details the fundamental design goals the solutions will intend to achieve. Those design goals serve to define the issues and to impose a list of requirements for forthcoming solutions. Actual requirements for NEMO Basic Support are in Section 4; NEMO Extended Support is not yet considered at the time of this writing.
本节详细介绍了解决方案将要实现的基本设计目标。这些设计目标用于定义问题，并为即将出现的解决方案提供一系列需求。NEMO基本支持的实际要求见第4节；在撰写本文时，尚未考虑NEMO扩展支持。
Permanent connectivity to the Internet has to be provided to all MNNs, since continuous sessions are expected to be maintained as the mobile router changes its point of attachment. For maintaining those sessions, MNNs are expected to be reachable via their permanent IP addresses.
必须向所有MNN提供与Internet的永久连接，因为随着移动路由器更改其连接点，预计将保持连续会话。为了维护这些会话，MNN应该可以通过其永久IP地址访问。
NEMO support is expected to be provided with limited signaling overhead and to minimize the impact of handovers on applications, in terms of packet loss or delay. However, although variable delays of transmission and losses between MNNs and their respective CNs could be perceived as the network is displaced, it would not be considered a lack of performance transparency.
NEMO支持预计将以有限的信令开销提供，并在分组丢失或延迟方面最大限度地减少切换对应用程序的影响。然而，尽管MNN与其各自的CNs之间的传输延迟和损耗变化可能会被视为网络被取代，但这不会被视为缺乏性能透明度。
MNNs behind the MR(s) do not change their own physical point of attachment as a result of the mobile network's displacement in the Internet topology. Consequently, NEMO support is expected to be performed only by the MR(s). Specific support functions on any node other than the MR(s) would better be avoided.
MR后面的MNN不会因为移动网络在Internet拓扑中的位移而改变其自身的物理连接点。因此，预计NEMO支持仅由MR执行。最好避免在MR以外的任何节点上执行特定的支持功能。
NEMO support is to be implemented at the level of IP layer. It is expected to be transparent to upper layers so that any upper-layer protocol can run unchanged on top of an IP layer extended with NEMO support.
NEMO支持将在IP层实施。预计它对上层是透明的，因此任何上层协议都可以在NEMO支持下扩展的IP层上不加更改地运行。
The formation of a mobile network can occur in various levels of complexity. In the simplest case, a mobile network contains just a mobile router and a host. In the most complicated case, a mobile
移动网络的形成可能具有不同的复杂性。在最简单的情况下，移动网络只包含一个移动路由器和一个主机。在最复杂的情况下，手机
network is multihomed and is itself a multi-level aggregation of mobile networks with collectively thousands of mobile routers and hosts. While the list of potential configurations of mobile networks cannot be limited, at least the following ones are desirable:
该网络是多址的，其本身是移动网络的多级聚合，由数千个移动路由器和主机组成。虽然不能限制移动网络的潜在配置列表，但至少需要以下配置：
o Mobile networks of any size, ranging from a sole subnet with a few IP devices to a collection of subnets with a large number of IP devices.
o 任何规模的移动网络，从具有少量IP设备的单一子网到具有大量IP设备的子网集合。
o Nodes that change their point of attachment within the mobile network.
o 在移动网络中更改其连接点的节点。
o Foreign mobile nodes that attach to the mobile network.
o 连接到移动网络的外部移动节点。
o Multihomed mobile network: either when a single MR has multiple attachments to the internet, or when the mobile network is attached to the Internet by means of multiple MRs (see definition in [1] and the analysis in [8]).
o 多宿移动网络：当单个MR有多个连接到internet时，或当移动网络通过多个MR连接到internet时（参见[1]中的定义和[8]中的分析）。
o Nested mobile networks (mobile networks attaching to other mobile networks (see definition in [1]). Although the complexity requirements of these nested networks are not clear, it is desirable to support arbitrary levels of recursive networks. The solution should only impose restrictions on nesting (e.g., path MTU) when this is impractical and protocol concerns preclude such support.
o 嵌套移动网络（连接到其他移动网络的移动网络（见[1]中的定义）。虽然这些嵌套网络的复杂性要求不明确，但支持任意级别的递归网络是可取的。解决方案应仅对嵌套施加限制（例如，路径MTU）当这是不切实际的，并且协议问题排除了此类支持时。
o Distinct mobility frequencies (see mobility factor in [2]).
o 不同的迁移率频率（见[2]中的迁移率系数）。
o Distinct access media.
o 独特的访问媒体。
In order to keep complexity minimal, transit networks are excluded from this list. A transit network is one in which data would be forwarded between two endpoints outside of the network, so that the network itself simply serves as a transitional conduit for packet forwarding. A stub network (leaf network), on the other hand, does not serve as a data forwarding path. Data on a stub network is either sent by or addressed to a node located within that network.
为了将复杂性降至最低，本列表中不包括公交网络。传输网络是一个数据将在网络外部的两个端点之间转发的网络，因此网络本身只是作为数据包转发的过渡管道。另一方面，存根网络（叶网络）不作为数据转发路径。存根网络上的数据由位于该网络内的节点发送或寻址。
Mobile networks and mobile nodes owned by different administrative entities are expected to be displaced within a domain boundary or between domain boundaries. Multihoming, vertical and horizontal handoffs, and access control mechanisms are desirable to achieve this goal. Such mobility is not expected to be limited for any consideration other than administrative and security policies.
不同管理实体拥有的移动网络和移动节点预计将在域边界内或域边界之间移动。多归属、垂直和水平切换以及访问控制机制是实现这一目标所需要的。除行政和安全政策外，这种流动性预计不会受到任何限制。
NEMO support signaling and processing is expected to scale to a potentially large number of mobile networks irrespective of their configuration, mobility frequency, size, and number of CNs.
NEMO支持信令和处理预计将扩展到潜在的大量移动网络，无论其配置、移动频率、大小和CNs数量如何。
NEMO support will have to co-exist with established IPv6 standards and not interfere with them. Standards defined in other IETF working groups have to be reused as much as possible and extended only if deemed necessary. For instance, the following mechanisms defined by other working groups are expected to function without modification:
NEMO支持必须与既定的IPv6标准共存，且不得干扰这些标准。其他IETF工作组中定义的标准必须尽可能重复使用，并且只有在认为必要时才予以扩展。例如，其他工作组定义的下列机制预计将在不作修改的情况下发挥作用：
o Address allocation and configuration mechanisms.
o 地址分配和配置机制。
o Host mobility support: mobile nodes and correspondent nodes, either located within or outside the mobile network, are expected to continue operating protocols defined by the Mobile IP working group. This includes mechanisms for host mobility support (Mobile IPv6) and seamless mobility (FMIPv6).
o 主机移动性支持：位于移动网络内部或外部的移动节点和对应节点预计将继续运行移动IP工作组定义的协议。这包括主机移动支持（移动IPv6）和无缝移动（FMIPv6）机制。
o Multicast support intended for MNNs is expected to be maintained while the mobile router changes its point of attachment.
o 当移动路由器更改其连接点时，预期将保持针对MNN的多播支持。
o Access control protocols and mechanisms used by visiting mobile hosts and routers to be authenticated and authorized, gaining access to the Internet via the mobile network infrastructure (MRs).
o 访问移动主机和路由器所使用的访问控制协议和机制将被验证和授权，通过移动网络基础设施（MRs）访问互联网。
o Security protocols and mechanisms.
o 安全协议和机制。
o Mechanisms performed by routers deployed in both visited networks and mobile networks (routing protocols, Neighbor Discovery, ICMP, Router Renumbering).
o 由部署在访问网络和移动网络中的路由器执行的机制（路由协议、邻居发现、ICMP、路由器重新编号）。
NEMO support will have to comply with the usual IETF security policies and recommendations and is expected to have its specific security issues fully addressed. In practice, all NEMO support control messages transmitted in the network will have to be protected with an acceptable level of security to prevent intruders from usurping identities and forge data. Specifically, the following issues have to be considered:
NEMO支持将必须遵守通常的IETF安全政策和建议，并有望全面解决其具体的安全问题。实际上，所有在网络中传输的NEMO支持控制信息都必须以可接受的安全级别进行保护，以防止入侵者盗用身份和伪造数据。具体而言，必须考虑以下问题：
o Authentication of the sender to prevent identity usurpation.
o 对发件人进行身份验证以防止身份盗用。
o Authorization, to make sure the sender is granted permission to perform the operation as indicated in the control message.
o 授权，以确保向发件人授予执行控制消息中指示的操作的权限。
o Confidentiality of the data contained in the control message.
o 控制消息中包含的数据的机密性。
Location privacy means hiding the actual location of MNN to third parties other than the HA are desired. It is not clear to which extend this has to be enforced, since it is always possible to determine the topological location by analyzing IPv6 headers. It would thus require some kind of encryption of the IPv6 header to prevent third parties from monitoring IPv6 addresses between the MR and the HA. On the other hand, it is at the very least desirable to provide a means for MNNs to hide their real topological location to their CNs.
位置隐私意味着需要向HA以外的第三方隐藏MNN的实际位置。目前尚不清楚必须将其扩展到哪一个，因为通过分析IPv6头始终可以确定拓扑位置。因此，需要对IPv6报头进行某种加密，以防止第三方监视MR和HA之间的IPv6地址。另一方面，至少需要为MNN提供一种向其CNs隐藏其真实拓扑位置的方法。
IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time, so it is desirable to ensure that mechanisms developed for NEMO will be able to traverse such clouds.
IPv4云和NAT可能与IPv6共存很长一段时间，因此需要确保为NEMO开发的机制能够穿越此类云。
Any NEMO solution needs have minimal negative effect on the global Internet routing system. The solution must therefore limit both the amount of information that must be injected into Internet routing, as well as the dynamic changes in the information that is injected into the global routing system.
任何NEMO解决方案需求对全球互联网路由系统的负面影响最小。因此，解决方案必须限制必须注入Internet路由的信息量，以及注入全局路由系统的信息的动态变化。
As one example of why this is necessary, consider the approach of advertising each mobile network's connectivity into BGP and, for every movement, withdrawing old routes and injecting new routes. If there were tens of thousands of mobile networks each advertising and withdrawing routes, for example, at the speed that an airplane can move from one ground station to another, the potential effect on BGP could be very unfortunate. In this example, the total amount of routing information advertised into BGP may be acceptable, but the dynamic instability of the information (i.e., the number of changes over time) would be unacceptable.
作为为什么这是必要的一个例子，考虑将每个移动网络的连接通告BGP的方法，并且对于每一个移动，撤回旧路由并注入新路由。例如，如果有成千上万的移动网络，每一个网络都在宣传和撤回路线，以飞机从一个地面站移动到另一个地面站的速度，那么对BGP的潜在影响可能是非常不幸的。在该示例中，播发到BGP的路由信息总量可能是可接受的，但信息的动态不稳定性（即随时间变化的数量）将是不可接受的。
For basic network mobility support, the NEMO WG is to specify a unified and unique "Network Mobility (NEMO) Basic Support" solution, hereafter referred to as "the solution". This solution is to allow all nodes in the mobile network to be reachable via permanent IP
对于基本网络移动性支持，NEMO工作组将指定一个统一且独特的“网络移动性（NEMO）基本支持”解决方案，以下简称“解决方案”。此解决方案允许通过永久IP访问移动网络中的所有节点
addresses, as well as maintain ongoing sessions as the MR changes its point of attachment to the Internet topology. This is to be done by maintaining a bi-directional tunnel between an MR and its Home Agent.
地址，以及在MR更改其连接点到Internet拓扑时维护正在进行的会话。这是通过维护MR与其国内代理之间的双向隧道来实现的。
The NEMO Working Group, after some investigation of alternatives, has decided to reuse and extend the existing Mobile IPv6 [5] mechanisms for tunnel management.
NEMO工作组在对替代方案进行了一些调查后，决定重用和扩展现有的移动IPv6[5]隧道管理机制。
The list of requirements below has been imposed on the NEMO Basic Support solution. The requirements have mostly been met by the resulting specification, which can now be found in [3]. Associated deployment issues are discussed in [9].
NEMO基本支持解决方案的要求如下。产生的规范基本上满足了这些要求，现在可以在[3]中找到。[9]中讨论了相关的部署问题。
R01: The solution must be implemented at the IP layer level.
R01：解决方案必须在IP层级别实施。
R02: The solution must set up a bi-directional tunnel between a mobile router and its Home Agent (MRHA tunnel).
R02：解决方案必须在移动路由器及其归属代理（MRHA隧道）之间建立一个双向隧道。
R03: All traffic exchanged between an MNN and a CN in the global Internet must transit through the bi-directional MRHA tunnel.
R03：全球互联网上MNN和CN之间交换的所有流量必须通过双向MRHA隧道传输。
R04: MNNs must be reachable at a permanent IP address and name.
R04:MNN必须在永久IP地址和名称处可访问。
R05: The solution must maintain continuous sessions (both unicast and multicast) between MNNs and arbitrary CNs after IP handover of (one of) the MRs.
R05：解决方案必须在（其中一个）MRs的IP切换后保持MNN和任意CNs之间的连续会话（单播和多播）。
R06: The solution must not require modifications to any node other than MRs and HAs.
R06：解决方案不得要求对MRs和HAs以外的任何节点进行修改。
R07: The solution must support fixed nodes, mobile hosts, and mobile routers in the mobile network.
R07：解决方案必须支持移动网络中的固定节点、移动主机和移动路由器。
R08: The solution must allow MIPv6-enabled MNNs to use a mobile network link as either a home link or a foreign link.
R08：解决方案必须允许启用MIPv6的MNN将移动网络链路用作主链路或外部链路。
R09: The solution must ensure backward compatibility with other standards defined by the IETF. In particular, this includes the following:
R09：解决方案必须确保与IETF定义的其他标准向后兼容。具体而言，这包括以下内容：
R09.1: The solution must not prevent the proper operation of Mobile IPv6 (i.e., the solution must allow MIPv6-enabled MNNs to operate either the CN, HA, or MN operations defined in [5]).
R09.1：该解决方案不得阻止移动IPv6的正确操作（即，该解决方案必须允许启用MIPv6的MNN操作[5]中定义的CN、HA或MN操作）。
R10: The solution must be agnostic to the internal configuration. This means the solution will behave the same way if NEMO is nested, comprises one or several subnets, or comprises MNNs that are LFNs, VMNs, LFNs or a mixture of them.
R10:解决方案必须与内部配置无关。这意味着，如果NEMO是嵌套的，包含一个或多个子网，或包含LFN、VMN、LFN或它们的混合物的MNN，则解决方案将以相同的方式运行。
R11: The solution must support at least 2 levels of nested mobile networks, while, in principle, arbitrary levels of recursive mobile networks should be supported.
R11：解决方案必须支持至少2个级别的嵌套移动网络，而原则上，应支持任意级别的递归移动网络。
R12: The solution must function for multihomed MRs and multihomed mobile networks as defined in [1].
R12：解决方案必须适用于[1]中定义的多址MRs和多址移动网络。
R13: NEMO support signaling over the bi-directional must be minimized.
R13：必须尽量减少双向网络上的NEMO支持信号。
R14: Signaling messages between the HA and the MR must be secured:
R14：必须保护HA和MR之间的信令消息：
R14.1: The receiver must be able to authenticate the sender.
R14.1：接收方必须能够验证发送方。
R14.2: The function performed by the sender must be authorized for the content carried.
R14.2：发送方执行的功能必须对所携带的内容进行授权。
R14.3: Anti-replay must be provided.
R14.3：必须提供防重放功能。
R14.4: The signaling messages may be encrypted.
R14.4：信令消息可以加密。
R15: The solution must ensure transparent continuation of routing and management operations over the bi-directional tunnel (this includes, e.g., unicast and multicast routing protocols, router renumbering, Dynamic Host Configuration Protocol (DHCPv6)).
R15：解决方案必须确保在双向隧道上透明地继续路由和管理操作（包括单播和多播路由协议、路由器重新编号、动态主机配置协议（DHCPv6））。
R16: When one egress interface fails, the solution may preserve sessions established through another egress interface.
R16：当一个出口接口出现故障时，解决方案可能会保留通过另一个出口接口建立的会话。
R17: The solution should have a minimal impact on the global Internet routing system.
R17：该解决方案应该对全球互联网路由系统的影响最小。
Security considerations of the NEMO Basic Support solution are addressed in [RFC3963].
[RFC3963]中介绍了NEMO基本支持解决方案的安全注意事项。
Section 3.9 of this document discusses the security goals for all forms of existing and forthcoming NEMO solutions.
本文件第3.9节讨论了所有形式的现有和即将推出的NEMO解决方案的安全目标。
The material presented in this document takes most of its text from discussions and previous documents submitted to the NEMO working group. This includes initial contributions from Motorola, INRIA, Ericsson, and Nokia. We are particularly grateful to Hesham Soliman (Ericsson) and the IETF Area Directors (ADs) at the time (Erik Nordmark and Thomas Narten), who greatly helped to set up the NEMO working group. We are also grateful to all the following people whose comments greatly contributed to the present document: T.J. Kniveton (Nokia), Alexandru Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert (Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson), and all the others who have expressed their opinions on the NEMO mailing lists (formerly known as MONET). Thierry Ernst wishes to personally acknowledge INRIA Rhone-Alpes and Motorola Labs Paris for their support and direction in bringing up this topic to the IETF in 2001--particularly Claude Castelluccia (INRIA) and Hong-Yon Lach (Motorola)--and his past employer, Keio University, Japan, which supported most of the costs associated with the IETF during the timelife of previous versions of this document.
本文件中提供的材料的大部分文本来自于讨论和以前提交给NEMO工作组的文件。这包括摩托罗拉、INRIA、爱立信和诺基亚的初始贡献。我们特别感谢当时的Hesham Soliman（爱立信）和IETF区域总监（ADs）（Erik Nordmark和Thomas Narten），他们为建立NEMO工作组提供了巨大帮助。我们还感谢以下所有人士，他们的评论对本文件作出了重大贡献：T.J.Kniveton（诺基亚）、Alexandru Petrescu（摩托罗拉）、Christophe Janneteau（摩托罗拉）、Pascal Thubert（思科）、Hong Yon Lach（摩托罗拉）、Mattias Petterson（爱立信），以及所有其他在尼莫邮件列表（以前称为莫奈）上发表意见的人。Thierry Ernst希望亲自感谢INRIA Rhone Alpes和Motorola Labs Paris，感谢他们在2001年向IETF提出这一主题时提供的支持和指导——特别是Claude Castelluccia（INRIA）和Hong Yon Lach（Motorola）——以及他过去的雇主，日本庆应大学，在本文件之前版本的有效期内，支持与IETF相关的大部分成本。
[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[1] Ernst，T.和H.Lach，“网络移动支持术语”，RFC 48852007年7月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2] Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[3] Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[4] "CALM - Medium and Long Range, High Speed, Air Interfaces parameters and protocols for broadcast, point to point, vehicle to vehicle, and vehicle to point communication in the ITS sector - Networking Protocol - Complementary Element", ISO Draft ISO/WD 21210, February 2005.
[4] “CALM-ITS扇区中广播、点对点、车对车和车对点通信的中远程高速空中接口参数和协议-网络协议-补充元素”，ISO草案ISO/WD 21210，2005年2月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[5] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[6] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
[6] Ng，C.，Thubert，P.，Watari，M.，和F.Zhao，“网络移动路径优化问题声明”，RFC 4888，2007年7月。
[7] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007.
[7] Ng，C.，Zhao，F.，Watari，M.，和P.Thubert，“网络移动路径优化解决方案空间分析”，RFC 4889，2007年7月。
[8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", Work in Progress), February 2007.
[8] Ng，C.，Ernst，T.，Paik，E.，和M.Bagnulo，“网络移动性支持中的多宿分析”，正在进行的工作），2007年2月。
[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility (NEMO) Home Network Models", RFC 4887, July 2007.
[9] Thubert，P.，Wakikawa，R.，和V.Devarapalli，“网络移动（NEMO）家庭网络模型”，RFC 4887，2007年7月。
Author's Address
作者地址
Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 78 153 Le Chesnay Cedex France
Thierry Ernst INRIA INRIA Rocuncourt Domaine de Voluceau B.P.105 78 153 Le Chesnay Cedex France
Phone: +33 1 39 63 59 30
Fax: +33 1 39 63 54 91
EMail: thierry.ernst@inria.fr
URI: http://www-rocq.inria.fr/imara
Phone: +33 1 39 63 59 30
Fax: +33 1 39 63 54 91
EMail: thierry.ernst@inria.fr
URI: http://www-rocq.inria.fr/imara
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。