Network Working Group J. Kempf, Ed.
Request for Comments: 4831 DoCoMo USA Labs
Category: Informational April 2007
Network Working Group J. Kempf, Ed.
Request for Comments: 4831 DoCoMo USA Labs
Category: Informational April 2007
Goals for Network-Based Localized Mobility Management (NETLMM)
基于网络的本地化移动性管理（NETLMM）的目标
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
摘要
In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed.
本文讨论了基于网络的本地化移动性管理（NETLMM）协议的设计目标。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. NETLMM Functional Architecture ..................................3
3. Goals for the NETLMM Protocol ...................................3
3.1. Goal 1: Handover Performance Improvement ...................4
3.2. Goal 2: Reduction in Handover-Related Signaling Volume .....5
3.3. Goal 3: Location Privacy ...................................6
3.4. Goal 4: Limit Overhead in the Network ......................7
3.5. Goal 5: Simplify Mobile Node Mobility Management
Security by Deriving from IP Network Access and/or IP
Movement Detection Security ................................7
3.6. Goal 6: Link Technology Agnostic ...........................8
3.7. Goal 7: Support for Unmodified Mobile Nodes ................8
3.8. Goal 8: Support for IPv4 and IPv6 ..........................9
3.9. Goal 9: Reuse of Existing Protocols Where Sensible ........10
3.10. Goal 10: Localized Mobility Management
Independent of Global Mobility Management ................10
3.11. Goal 11: Configurable Data Plane Forwarding
between Local Mobility Anchor and Mobile Access Gateway ..11
4. Security Considerations ........................................11
5. Acknowledgements ...............................................11
6. Normative References ...........................................12
7. Informative References .........................................12
8. Contributors ...................................................13
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. NETLMM Functional Architecture ..................................3
3. Goals for the NETLMM Protocol ...................................3
3.1. Goal 1: Handover Performance Improvement ...................4
3.2. Goal 2: Reduction in Handover-Related Signaling Volume .....5
3.3. Goal 3: Location Privacy ...................................6
3.4. Goal 4: Limit Overhead in the Network ......................7
3.5. Goal 5: Simplify Mobile Node Mobility Management
Security by Deriving from IP Network Access and/or IP
Movement Detection Security ................................7
3.6. Goal 6: Link Technology Agnostic ...........................8
3.7. Goal 7: Support for Unmodified Mobile Nodes ................8
3.8. Goal 8: Support for IPv4 and IPv6 ..........................9
3.9. Goal 9: Reuse of Existing Protocols Where Sensible ........10
3.10. Goal 10: Localized Mobility Management
Independent of Global Mobility Management ................10
3.11. Goal 11: Configurable Data Plane Forwarding
between Local Mobility Anchor and Mobile Access Gateway ..11
4. Security Considerations ........................................11
5. Acknowledgements ...............................................11
6. Normative References ...........................................12
7. Informative References .........................................12
8. Contributors ...................................................13
In [1], the basic problems that occur when a global mobility protocol is used for managing local mobility are described, and two currently used approaches to localized mobility management -- the host-based approach that is used by most IETF protocols, and the proprietary Wireless LAN (WLAN) switch approach used between WLAN switches in different subnets -- are examined. The conclusion from the problem statement document is that none of the approaches has a complete solution to the problem. While the WLAN switch approach is most convenient for network operators and users because it requires no software on the mobile node other than the standard drivers for WiFi, the proprietary nature limits interoperability, and the restriction to a single last-hop link type and wired backhaul link type restricts scalability. The IETF host-based protocols require host software stack changes that may not be compatible with all global mobility protocols. They also require specialized and complex security transactions with the network that may limit deployability. The conclusion is that a localized mobility management protocol that is network based and requires no software on the host for localized mobility management is desirable.
在[1]中，描述了使用全球移动性协议管理本地移动性时出现的基本问题，以及目前使用的两种本地化移动性管理方法——大多数IETF协议使用的基于主机的方法和专有无线局域网（WLAN）研究了不同子网中WLAN交换机之间使用的切换方法。问题陈述文件的结论是，没有一种方法能够完全解决问题。虽然WLAN交换机方法对网络运营商和用户来说最为方便，因为它除了WiFi的标准驱动程序外，不需要移动节点上的任何软件，但其专有性质限制了互操作性，并且对单个最后一跳链路类型和有线回程链路类型的限制限制了可伸缩性。IETF基于主机的协议需要主机软件堆栈更改，这些更改可能与所有全球移动协议不兼容。它们还需要与网络进行专门而复杂的安全事务处理，这可能会限制部署能力。结论是，基于网络的本地化移动性管理协议是可取的，并且不需要主机上的软件来进行本地化移动性管理。
This document develops a brief functional architecture and detailed goals for a network-based localized mobility management protocol (NETLMM). Section 2 describes the functional architecture of NETLMM. In Section 3, a list of goals that is desirable in the NETLMM protocol is presented. Section 4 briefly outlines Security Considerations. More discussion of security can be found in the threat analysis document [2].
本文档为基于网络的本地化移动性管理协议（NETLMM）开发了一个简要的功能架构和详细的目标。第2节描述了NETLMM的功能架构。在第3节中，列出了NETLMM协议中需要的目标列表。第4节简要概述了安全注意事项。有关安全性的更多讨论，请参见威胁分析文档[2]。
Mobility terminology in this document follows that in RFC 3753 [10] and in [1]. In addition, the following terms are related to the functional architecture described in Section 2:
本文件中的移动性术语遵循RFC 3753[10]和[1]中的术语。此外，以下术语与第2节中描述的功能架构相关：
Localized Mobility Management Domain
本地化移动性管理域
An Access Network in the sense defined in [1] in which mobility is handled by the NETLMM protocol.
在[1]中定义的意义上的一种接入网络，其中移动由NETLMM协议处理。
Mobile Access Gateway
移动接入网关
A Mobile Access Gateway (MAG) is a functional network element that terminates a specific edge link and tracks mobile node IP-level mobility between edge links, through NETLMM signaling with the Localized Mobility Anchor. The MAG also terminates host routed data traffic from the Localized Mobility Anchor for mobile nodes
移动接入网关（MAG）是一种功能性网络元件，其通过具有本地化移动性锚的NETLMM信令来终止特定边缘链路并跟踪边缘链路之间的移动节点IP级移动性。MAG还终止来自移动节点的本地化移动锚的主机路由数据流量
currently located within the edge link under the MAG's control, and forwards data traffic from mobile nodes on the edge link under its control to the Localized Mobility Anchor.
当前位于MAG控制下的边缘链路内，并将数据流量从其控制下的边缘链路上的移动节点转发到本地化移动锚。
Local Mobility Anchor
局部移动锚
A Local Mobility Anchor (LMA) is a router that maintains a collection of host routes and associated forwarding information for mobile nodes within a localized mobility management domain under its control. Together with the MAGs associated with it, the LMA uses the NETLMM protocol to manage IP node mobility within the localized mobility management domain. Routing of mobile node data traffic is anchored at the LMA as the mobile node moves around within the localized mobility management domain.
本地移动性锚（LMA）是一种路由器，它为在其控制下的本地化移动性管理域内的移动节点维护主机路由和相关转发信息的集合。与与其相关联的mag一起，LMA使用NETLMM协议来管理本地化移动性管理域内的IP节点移动性。当移动节点在本地移动性管理域内移动时，移动节点数据业务的路由被锚定在LMA处。
The NETLMM architecture consists of the following components. Localized Mobility Anchors (LMAs) within the backbone network maintain a collection of routes for individual mobile nodes within the localized mobility management domain. The routes point to the Mobile Access Gateways (MAGs) managing the links on which the mobile nodes currently are located. Packets for a mobile node are routed to and from the mobile node through tunnels between the LMA and MAG. When a mobile node moves from one link to another, the MAG sends a route update to the LMA. While some mobile node involvement is necessary and expected for generic mobility functions such as movement detection and to inform the MAG about mobile node movement, no specific mobile-node-to-network protocol will be required for localized mobility management itself. Host stack involvement in mobility management is thereby limited to generic mobility functions at the IP layer, and no specialized localized mobility management software is required.
NETLMM体系结构由以下组件组成。主干网内的本地化移动性锚（lma）维护本地化移动性管理域内各个移动节点的路由集合。路由指向管理移动节点当前所在链路的移动接入网关（MAG）。用于移动节点的分组通过LMA和MAG之间的隧道路由到移动节点和从移动节点路由。当移动节点从一个链路移动到另一个链路时，MAG向LMA发送路由更新。虽然一些移动节点的参与对于诸如移动检测之类的通用移动功能是必要的，并且是期望的，以便向MAG通知移动节点的移动，但是本地化移动管理本身不需要特定的移动节点到网络协议。因此，移动管理中的主机堆栈仅限于IP层的通用移动功能，不需要专门的本地化移动管理软件。
Section 2 of [1] describes three problems with using a global mobility management protocol for localized mobility management. Any localized mobility management protocol must naturally address these three problems. In addition, the side effects of introducing such a solution into the network need to be limited. In this section, we address goals for NETLMM, including both solving the basic problems (Goals 1, 2, and 3) and limiting the side effects (Goals 4+).
[1]的第2节描述了使用全局移动性管理协议进行本地化移动性管理的三个问题。任何本地化的移动性管理协议都必须自然地解决这三个问题。此外，将这种解决方案引入网络的副作用需要加以限制。在本节中，我们将介绍NETLMM的目标，包括解决基本问题（目标1、2和3）和限制副作用（目标4+）。
Some basic goals of all IETF protocols are not discussed in detail here, but any solution is expected to satisfy them. These goals are fault tolerance, robustness, interoperability, scalability, and minimal specialized network equipment. A good discussion of their applicability to IETF protocols can be found in [4].
这里不详细讨论所有IETF协议的一些基本目标，但任何解决方案都有望满足这些目标。这些目标是容错性、健壮性、互操作性、可扩展性和最小化专用网络设备。关于它们对IETF协议的适用性的详细讨论见[4]。
Out of scope for the initial goals discussion are Quality of Service (QoS) and dormant mode/paging. While these are important functions for mobile nodes, they are not part of the base localized mobility management problem. In addition, mobility between localized mobility management domains is not covered here. It is assumed that this is covered by the global mobility management protocols.
超出了最初目标讨论范围的是服务质量（QoS）和休眠模式/分页。虽然这些是移动节点的重要功能，但它们不是基本本地化移动性管理问题的一部分。此外，此处不涉及本地化移动性管理域之间的移动性。假设全球移动性管理协议涵盖了这一点。
Handover packet loss occurs because there is usually latency between when the link handover starts and when the IP subnet configuration and global mobility management signaling completes. During this time, the mobile node is unreachable at its former topological location on the old link where correspondents are sending packets. Such misrouted packets are dropped. This aspect of handover performance optimization has been the subject of much work, both in other Standards Development Organizations (SDOs) and in the IETF, in order to reduce the latency in IP handover. Many solutions to this problem have been proposed at the link layer and at the IP layer. One aspect of this goal for localized mobility management is that the processing delay for changing the forwarding after handover must approach as closely as possible the sum of the delay associated with link-layer handover and the delay required for active IP-layer movement detection, in order to avoid excessive packet loss. Ideally, if network-side link-layer support is available for handling movement detection prior to link handover or as part of the link handover process, the routing update should complete within the time required for link handover. This delay is difficult to quantify, but for voice traffic, the entire handover delay, including Layer 2 handover time and IP handover time should be between 40-70 ms to avoid any degradation in call quality. Of course, if the link-layer handover latency is too high, sufficient IP-layer handover performance for good real-time service cannot be matched.
切换数据包丢失是因为在链路切换开始与IP子网配置和全局移动性管理信令完成之间通常存在延迟。在这段时间内，移动节点在通信者发送数据包的旧链路上的前拓扑位置是不可到达的。这种错误路由的数据包被丢弃。切换性能优化的这一方面一直是其他标准开发组织（SDO）和IETF中大量工作的主题，以减少IP切换的延迟。在链路层和IP层已经提出了许多解决方案。本地化移动性管理的这一目标的一个方面是，切换后改变转发的处理延迟必须尽可能接近与链路层切换相关联的延迟和主动IP层移动检测所需的延迟之和，以避免过度的分组丢失。理想情况下，如果在链路切换之前或作为链路切换过程的一部分，网络侧链路层支持可用于处理移动检测，则路由更新应在链路切换所需的时间内完成。这种延迟很难量化，但对于语音业务，整个切换延迟（包括第2层切换时间和IP切换时间）应在40-70 ms之间，以避免呼叫质量的任何下降。当然，如果链路层切换延迟太高，则无法匹配足够的IP层切换性能以实现良好的实时服务。
A goal of the NETLMM protocol -- in networks where the link-layer handover latency allows it -- is to reduce the amount of latency in IP handover, so that the combined IP-layer and link-layer handover latency is less than 70 ms.
NETLMM协议的一个目标——在链路层切换延迟允许的网络中——是减少IP切换中的延迟量，从而使IP层和链路层的组合切换延迟小于70毫秒。
Considering Mobile IPv6 [9] as the global mobility protocol (other mobility protocols require about the same or somewhat less), if a mobile node using address autoconfiguration is required to reconfigure on every move between links, the following signaling must be performed:
将移动IPv6[9]视为全球移动协议（其他移动协议要求的大致相同或稍低），如果需要使用地址自动配置的移动节点在链路之间的每次移动上重新配置，则必须执行以下信令：
1) Link-layer signaling required for handover and reauthentication. For example, in 802.11 [7], this is the Reassociate message together with 802.1x [8] reauthentication using EAP.
1) 切换和重新验证所需的链路层信令。例如，在802.11[7]中，这是使用EAP与802.1x[8]重新认证一起重新关联的消息。
2) Active IP-level movement detection, including router reachability. The Detecting Network Attachment (DNA) protocol [5] uses Router Solicitation/Router Advertisement for this purpose. In addition, if SEcure Neighbor Discovery (SEND) [3] is used and the mobile node does not have a certificate cached for the router, the mobile node must use Certification Path Solicitation/Certification Path Advertisement to obtain a certification path.
2) 主动IP级移动检测，包括路由器可达性。检测网络连接（DNA）协议[5]为此目的使用路由器请求/路由器广告。此外，如果使用了安全邻居发现（SEND）[3]，并且移动节点没有为路由器缓存的证书，则移动节点必须使用证书路径请求/证书路径公告来获得证书路径。
3) Two Multicast Listener Discovery (MLD) [14] REPORT messages, one for each of the solicited node multicast addresses corresponding to the link local address and the global address.
3) 两个多播侦听器发现（MLD）[14]报告消息，分别对应于链路本地地址和全局地址的请求节点多播地址。
4) Two Neighbor Solicitation (NS) messages for duplicate address detection, one for the link local address and one for the global address. If the addresses are unique, no response will be forthcoming.
4) 两条用于重复地址检测的邻居请求（NS）消息，一条用于链路本地地址，另一条用于全局地址。如果地址是唯一的，则不会有响应。
5) Two NS messages from the router for address resolution of the link local and global addresses, and two Neighbor Advertisement messages in response from the mobile node.
5) 来自路由器的两条NS消息用于链路本地和全局地址的地址解析，以及来自移动节点的两条邻居广告消息作为响应。
6) Binding Update/Binding Acknowledgement between the mobile node and home agent to update the care of address binding.
6) 移动节点和归属代理之间的绑定更新/绑定确认，以更新转交地址绑定。
7) Return routability signaling between the correspondent node and mobile node to establish the binding key, consisting of one Home Test Init/Home Test and Care of Test Init/Care of Test.
7) 返回对应节点和移动节点之间的可路由性信令以建立绑定密钥，该密钥由一个Home Test Init/Home Test和Care of Test Init/Care of Test组成。
8) Binding Update/Binding Acknowledgement between the correspondent node and mobile node for route optimization.
8) 在对应节点和移动节点之间绑定更新/绑定确认以进行路由优化。
Note that Steps 1-2 may be necessary, even for intra-link mobility, if the last-hop link protocol doesn't provide much help for IP handover. Steps 3-5 will be different if stateful address configuration is used, since additional messages are required to obtain the address. Steps 6-8 are only necessary when Mobile IPv6 is
请注意，如果最后一跳链路协议没有为IP切换提供太多帮助，则步骤1-2可能是必要的，即使对于链路内移动也是如此。如果使用有状态地址配置，步骤3-5将有所不同，因为需要额外的消息来获取地址。步骤6-8仅在启用移动IPv6时才有必要
used. The result is approximately 18 messages at the IP level, where the exact number depends on various specific factors, such as whether or not the mobile node has a router certificate cached before a mobile node can be ensured that it is established on a link and has full IP connectivity. In addition to handover related signaling, if the mobile node performs Mobile IPv6 route optimization, it may be required to renew its return routability key periodically (on the order of every 7 minutes), even if it is not moving, resulting in additional signaling.
习惯于结果是在IP级别上大约有18条消息，其中确切的数目取决于各种特定因素，例如在可以确保移动节点在链路上建立并具有完全IP连接之前，移动节点是否缓存了路由器证书。除了与切换相关的信令之外，如果移动节点执行移动IPv6路由优化，则可能需要周期性地（以每7分钟的顺序）更新其返回路由性密钥，即使其不移动，也会导致额外的信令。
The signaling required has a large impact on the performance of handover, impacting Goal 1. Perhaps more importantly, the aggregate impact from many mobile nodes of such signaling on expensive shared links (such as wireless where the capacity of the link cannot easily be expanded) can result in reduced last-hop link capacity for data traffic. Additionally, in links where the end user is charged for IP traffic, IP signaling is not without cost.
所需信令对切换性能有很大影响，影响目标1。也许更重要的是，这种信令对昂贵的共享链路（例如链路容量不容易扩展的无线链路）的许多移动节点的聚合影响可导致数据业务的最后一跳链路容量降低。此外，在向最终用户收取IP流量费用的链路中，IP信令并非没有成本。
To address the issue of signaling impact described above, the goal is that handover signaling volume from the mobile node to the network should be no more than what is needed for the mobile node to perform secure IP-level movement detection, in cases where no link-layer support exists. Furthermore, NETLMM should not introduce any additional signaling during handover beyond what is required for IP-level movement detection. If link-layer support exists for IP-level movement detection, the mobile node may not need to perform any additional IP-level signaling after link-layer handover.
为了解决上述信令影响的问题，目标是在不存在链路层支持的情况下，从移动节点到网络的切换信令量不应超过移动节点执行安全IP级移动检测所需的量。此外，NETLMM在切换期间不应引入任何超出IP级移动检测所需的额外信令。如果存在对IP级移动检测的链路层支持，则在链路层切换之后，移动节点可能不需要执行任何额外的IP级信令。
In any IP network, there is a threat that an attacker can determine the physical location of a network node from the node's topological location. Depending on how an operator deploys their network, an operator may choose to assign subnet coverage in a way that is tightly bound to geography at some timescale, or it may choose to assign it in ways in which the threat of someone finding a node physically based on its IP address is smaller. Allowing the L2 attachment and L3 address to be less tightly bound is one tool for reducing this threat to location privacy.
在任何IP网络中，都存在一种威胁，即攻击者可以根据节点的拓扑位置确定网络节点的物理位置。根据运营商部署其网络的方式，运营商可以选择在某个时间尺度上以与地理紧密相关的方式分配子网覆盖范围，也可以选择以某人根据其IP地址物理查找节点的威胁较小的方式分配子网覆盖范围。允许二级连接和三级地址不那么紧密地绑定是减少位置隐私威胁的一个工具。
Mobility introduces an additional threat. An attacker can track a mobile node's geographical location in real-time, if the victim mobile node must change its IP address as it moves from one subnet to another through the covered geographical area. If the granularity of the mapping between the IP subnets and geographical area is small for the particular link type in use, the attacker can potentially assemble enough information to find the victim in real time.
机动性带来了额外的威胁。如果受害移动节点在通过覆盖的地理区域从一个子网移动到另一个子网时必须更改其IP地址，则攻击者可以实时跟踪移动节点的地理位置。如果IP子网和地理区域之间的映射粒度对于所使用的特定链路类型来说很小，则攻击者可能会收集足够的信息以实时找到受害者。
In order to reduce the risk from location privacy compromises as a result of IP address changes, the goal for NETLMM is to remove the need to change IP address as a mobile node moves across links in an access network. Keeping the IP address fixed over a large geographical region fuzzes out the resolution of the mapping between the IP subnets and geographical area, regardless of how small the natural deployment granularity may be. This reduces the chance that the attacker can deduce the precise geographic location of the mobile node.
为了降低由于IP地址更改而导致位置隐私受损的风险，NETLMM的目标是消除移动节点在接入网络中的链路上移动时更改IP地址的需要。在一个较大的地理区域上保持IP地址固定会模糊IP子网和地理区域之间映射的分辨率，而不管自然部署粒度有多小。这降低了攻击者推断移动节点精确地理位置的机会。
Access networks, including both the wired and wireless parts, tend to have somewhat stronger bandwidth and router processing constraints than the backbone. In the wired part of the network, these constraints are a function of the cost of laying fiber or wiring to the wireless access points in a widely dispersed geographic area. In the wireless part of the network, these constraints are due to the limitation on the number of bits per Hertz imposed by the physical layer protocol. Therefore, any solutions for localized mobility management should minimize overhead within the access network.
接入网络，包括有线和无线部分，往往比主干网有更强的带宽和路由器处理限制。在网络的有线部分，这些限制是在广泛分布的地理区域中铺设光纤或连接到无线接入点的成本的函数。在网络的无线部分，这些限制是由于物理层协议对每赫兹比特数的限制。因此，任何用于本地化移动性管理的解决方案都应该最小化接入网络内的开销。
3.5. Goal 5: Simplify Mobile Node Mobility Management Security by Deriving from IP Network Access and/or IP Movement Detection Security
3.5. 目标5：通过从IP网络访问和/或IP移动检测安全性派生，简化移动节点移动管理安全性
Localized mobility management protocols that have host involvement may require an additional security association between the mobile node and the mobility anchor, and establishing this security association may require additional signaling between the mobile node and the mobility anchor (see [13] for an example). The additional security association requires extra signaling and therefore extra time to negotiate. Reducing the complexity of mobile-node-to-network security for localized mobility management can therefore reduce barriers to deployment and improve responsiveness. Naturally, such simplification must not come at the expense of maintaining strong security guarantees for both the network and mobile node.
具有主机参与的本地化移动性管理协议可能需要移动节点和移动性锚之间的附加安全关联，并且建立该安全关联可能需要移动节点和移动性锚之间的附加信令（例如，参见[13]）。额外的安全关联需要额外的信令，因此需要额外的协商时间。因此，为本地化移动性管理降低移动节点到网络安全的复杂性可以减少部署障碍并提高响应能力。当然，这种简化绝不能以维护网络和移动节点的强大安全保障为代价。
In NETLMM, the network (specifically, the MAG) derives the occurrence of a mobility event, requiring a routing update for a mobile node from link-layer handover signaling, or IP-layer movement detection signaling from the mobile node. This information is used to update routing for the mobile node at the LMA. The handover, or movement detection signaling, must provide the network with proper authentication and authorization so that the network can definitively identify the mobile node and determine its authorization. The authorization may be at the IP level -- for example, using something like SEND [3] to secure IP movement detection signaling -- or it at
在NETLMM中，网络（具体地说，MAG）派生出移动事件的发生，移动事件需要来自链路层切换信令的移动节点的路由更新，或者来自移动节点的IP层移动检测信令。该信息用于在LMA处更新移动节点的路由。切换或移动检测信令必须为网络提供适当的身份验证和授权，以便网络能够最终识别移动节点并确定其授权。授权可能在IP级别，例如，使用SEND[3]之类的东西来保护IP移动检测信令，也可能在IP级别
the link level. Proper authentication and authorization must be implemented on link-layer handover signaling and/or IP-level movement detection signaling in order for the MAG to securely deduce mobile node movement events. Security threats to the NETLMM protocol are discussed in [2].
链接级别。必须在链路层切换信令和/或IP级移动检测信令上实施适当的认证和授权，以便MAG安全地推断移动节点移动事件。[2]中讨论了NETLMM协议的安全威胁。
The goal is that security for NETLMM mobile node mobility management should derive from IP network access and/or IP movement detection security, such as SEND or network access authentication, and not require any additional security associations or additional signaling between the mobile node and the network.
目标是NETLMM移动节点移动性管理的安全性应源自IP网络接入和/或IP移动检测安全性，例如发送或网络接入认证，而不需要移动节点和网络之间的任何附加安全关联或附加信令。
The number of wireless link technologies available is growing, and the growth seems unlikely to slow down. Since the standardization of a wireless link physical and medium access control layers is a time-consuming process, reducing the amount of work necessary to interface a particular wireless link technology to an IP network is necessary. When the last-hop link is a wireless link, a localized mobility management solution should ideally require minimal work to interface with a new wireless link technology.
可用无线链路技术的数量正在增长，而且增长似乎不可能放缓。由于无线链路物理层和介质访问控制层的标准化是一个耗时的过程，因此有必要减少将特定无线链路技术连接到IP网络所需的工作量。当最后一跳链路是无线链路时，理想情况下，本地化的移动性管理解决方案需要最少的工作来与新的无线链路技术接口。
In addition, an edge mobility solution should provide support for multiple wireless link technologies. It is not required that the localized mobility management solution support handover from one wireless link technology to another without a change in the IP address, but this possibility should not be precluded.
此外，边缘移动解决方案应支持多种无线链路技术。不要求本地化移动性管理解决方案支持在不改变IP地址的情况下从一种无线链路技术切换到另一种无线链路技术，但不应排除这种可能性。
The goal is that the localized mobility management protocol should not use any wireless link specific information for basic routing management, though it may be used for other purposes, such as securely identifying a mobile node.
目标是本地化移动性管理协议不应将任何无线链路特定信息用于基本路由管理，尽管它可用于其他目的，例如安全地识别移动节点。
In the WLAN switching market, no modification of the software on the mobile node is required to achieve localized mobility management. Being able to accommodate unmodified mobile nodes enables a service provider to offer service to as many customers as possible, the only constraint being that the customer is authorized for network access.
在WLAN交换市场中，无需修改移动节点上的软件即可实现本地化移动性管理。能够容纳未经修改的移动节点使服务提供商能够向尽可能多的客户提供服务，唯一的限制是客户被授权访问网络。
Another advantage of minimizing mobile node software for localized mobility management is that multiple global mobility management protocols can be supported. There are a variety of global mobility management protocols that might also need support, including proprietary or link technology-specific protocols needing support for backward compatibility reasons. Within the Internet, both Host
最小化用于本地化移动性管理的移动节点软件的另一个优点是可以支持多个全局移动性管理协议。可能还需要支持各种全球移动性管理协议，包括出于向后兼容性原因需要支持的专有或特定于链路技术的协议。在Internet中，两个主机
Identity Protocol (HIP) [11] and IKEv2 Mobility and Multihoming (MOBIKE) [6] are likely to need support in addition to Mobile IPv6 [9], and Mobile IPv4 [12] support may also be necessary.
除了移动IPv6[9]之外，身份协议（HIP）[11]和IKEv2移动和多归属（MOBIKE）[6]可能还需要支持，移动IPv4[12]支持也可能是必要的。
Note that this goal does NOT mean that the mobile node has no software at all associated with mobility. The mobile node must have some kind of global mobility protocol if it is to move from one domain of edge mobility support to another and maintain session continuity, although no global mobility protocol is required if the mobile node only moves within the coverage area of the localized mobility management protocol or no session continuity is required during global movement. Also, if the last-hop link is a wireless link, every wireless link protocol requires handover support on the mobile node in the physical and medium access control layers, typically in the wireless interface driver. Information passed from the medium access control layer to the IP layer on the mobile node may be necessary to trigger IP signaling for IP handover. Such movement detection support at the IP level may be required in order to determine whether the mobile node's default router is still reachable after the move to a new access point has occurred at the medium access control layer. Whether or not such support is required depends on whether the medium access control layer can completely hide link movement from the IP layer. For cellular type wireless link protocols, the mobile node and network undergo an extensive negotiation at the medium access control layer prior to handover, so it may be possible to trigger a routing update without any IP protocol involvement. However, for a wireless link protocol such as IEEE 802.11 [7] in which the decision for handover is entirely in the hands of the mobile node, IP-layer movement detection signaling from the mobile node may be required to trigger a routing update.
注意，该目标并不意味着移动节点根本没有与移动性相关联的软件。如果移动节点要从一个边缘移动支持域移动到另一个域并保持会话连续性，则必须具有某种全局移动协议，尽管如果移动节点仅在本地移动性管理协议的覆盖区域内移动或者在全局移动期间不需要会话连续性，则不需要全局移动性协议。此外，如果最后一跳链路是无线链路，则每个无线链路协议都需要物理和介质访问控制层（通常在无线接口驱动程序中）中的移动节点上的切换支持。从媒体接入控制层传递到移动节点上的IP层的信息可能是触发IP信令以进行IP切换所必需的。可能需要在IP级别上的这种移动检测支持，以便确定在媒体访问控制层上发生了移动到新接入点之后移动节点的默认路由器是否仍然可到达。是否需要这样的支持取决于介质访问控制层是否能够完全隐藏IP层的链路移动。对于蜂窝式无线链路协议，移动节点和网络在切换之前在介质接入控制层经历广泛的协商，因此可能在不涉及任何IP协议的情况下触发路由更新。然而，对于诸如IEEE 802.11[7]之类的无线链路协议，其中切换的决定完全掌握在移动节点手中，可能需要来自移动节点的IP层移动检测信令来触发路由更新。
The goal is that the localized mobility management solution should be able to support any mobile node that joins the link and that has an interface that can communicate with the network, without requiring localized mobility management software on the mobile node.
目标是本地化移动性管理解决方案应能够支持加入链路且具有可与网络通信的接口的任何移动节点，而无需移动节点上的本地化移动性管理软件。
While most of this document is written with IPv6 in mind, localized mobility management is a problem in IPv4 networks as well. A solution for localized mobility that works for both versions of IP is desirable, though the actual protocol may be slightly different due to the technical details of how each IP version works. From Goal 7 (Section 3.7), minimizing mobile node support for localized mobility means that ideally no IP version-specific changes should be required on the mobile node for localized mobility, and that global mobility protocols for both IPv4 and IPv6 should be supported. Any IP version-specific features should be confined to the network protocol.
虽然本文档的大部分内容都是针对IPv6编写的，但IPv4网络中的本地化移动性管理也是一个问题。一个适用于两个IP版本的本地化移动性解决方案是可取的，尽管由于每个IP版本如何工作的技术细节，实际协议可能略有不同。根据目标7（第3.7节），最小化移动节点对本地化移动性的支持意味着，理想情况下，对于本地化移动性，移动节点不需要进行特定于IP版本的更改，并且应支持IPv4和IPv6的全局移动性协议。任何特定于IP版本的功能都应限于网络协议。
Many existing protocols are available as Internet Standards upon which the NETLMM protocol can be built. The design of the protocol should have a goal to reuse existing protocols where it makes architectural and engineering sense to do so. However, the design should not attempt to reuse existing protocols where there is no real architectural or engineering reason. For example, the suite of Internet Standards contains several good candidate protocols for the transport layer, so there is no real need to develop a new transport protocol specifically for NETLMM. Reuse is clearly a good engineering decision in this case, since backward compatibility with existing protocol stacks is important. On the other hand, the network-based, localized mobility management functionality being introduced by NETLMM is a new piece of functionality, and therefore any decision about whether to reuse an existing global mobility management protocol should carefully consider whether reusing such a protocol really meets the needs of the functional architecture for network-based localized mobility management. The case for reuse is not so clear in this case, since there is no compelling backward compatibility argument.
许多现有协议可作为Internet标准使用，NETLMM协议可在此基础上构建。协议的设计应该有一个目标，即在架构和工程上有意义的地方重用现有协议。然而，在没有真正的架构或工程原因的情况下，设计不应试图重用现有协议。例如，Internet标准套件包含多个很好的传输层候选协议，因此没有必要专门为NETLMM开发新的传输协议。在这种情况下，重用显然是一个很好的工程决策，因为与现有协议栈的向后兼容性很重要。另一方面，NETLMM引入的基于网络的本地化移动性管理功能是一项新功能，因此，关于是否重用现有的全局移动性管理协议的任何决定都应该仔细考虑是否重用这样的协议真正满足基于网络的本地化移动性管理的功能架构的需求。在这种情况下，重用的理由并不那么清楚，因为没有令人信服的向后兼容性论证。
3.10. Goal 10: Localized Mobility Management Independent of Global Mobility Management
3.10. 目标10：独立于全球流动管理的本地化流动管理
Localized mobility management should be implementable and deployable independently of any global mobility management protocol. This enables the choice of local and global mobility management to be made independently of particular protocols that are implemented and deployed to solve the two different sorts of mobility management problems. The operator can choose a particular localized mobility management protocol according to the specific features of their access network. It can subsequently upgrade the localized mobility management protocol on its own, without even informing the mobile nodes. Similarly, the mobile nodes can use a global mobility management protocol that best suits their requirements, or not use one at all. Also, a mobile node can move into a new access network without having to check that it understands the localized mobility management protocol being used there.
本地化移动性管理应独立于任何全球移动性管理协议实现和部署。这使得本地和全局移动性管理的选择能够独立于为解决两种不同的移动性管理问题而实施和部署的特定协议。运营商可以根据其接入网络的特定特征选择特定的本地化移动性管理协议。随后，它可以自己升级本地化的移动性管理协议，甚至不通知移动节点。类似地，移动节点可以使用最适合其需求的全局移动性管理协议，或者根本不使用。此外，移动节点可以移入新的接入网络，而无需检查其是否理解在那里使用的本地化移动性管理协议。
The goal is that the implementation and deployment of the localized mobility management protocol should not restrict, or be restricted by, the choice of global mobility management protocol.
目标是本地化移动性管理协议的实现和部署不应限制或受全球移动性管理协议选择的限制。
3.11. Goal 11: Configurable Data Plane Forwarding between Local Mobility Anchor and Mobile Access Gateway
3.11. 目标11：本地移动锚和移动接入网关之间的可配置数据平面转发
Different network operators may require different types of forwarding options between the LMA and the MAGs for mobile node data plane traffic. An obvious forwarding option that has been used in past IETF localized mobility management protocols is IP-IP encapsulation for bidirectional tunneling. The tunnel endpoints are the LMA and the MAGs. But other options are possible. Some network deployments may prefer routing-based solutions. Others may require security tunnels using IPsec Encapsulating Security Payload (ESP) encapsulation if part of the localized mobility management domain runs over a public access network and the network operator wants to protect the traffic.
对于移动节点数据平面业务，不同的网络运营商可能需要LMA和mag之间的不同类型的转发选项。过去IETF本地化移动性管理协议中使用的一个明显的转发选项是用于双向隧道的IP-IP封装。隧道端点是LMA和MAG。但其他选择也是可能的。某些网络部署可能更喜欢基于路由的解决方案。其他人可能需要使用IPsec封装安全有效负载（ESP）封装的安全隧道，如果局部移动管理域的一部分在公共接入网络上运行，并且网络运营商希望保护流量。
A goal of the NETLMM protocol is to allow the forwarding between the LMA and MAGs to be configurable depending on the particulars of the network deployment. Configurability is not expected to be dynamic, as in controlled by the arrival of a mobile node; but rather, configuration is expected to be similar in timescale to configuration for routing. The NETLMM protocol may designate a default forwarding mechanism. It is also possible that additional work may be required to specify the interaction between a particular forwarding mechanism and the NETLMM protocol, but this work is not in scope of the NETLMM base protocol.
NETLMM协议的目标是允许LMA和MAG之间的转发可根据网络部署的细节进行配置。可配置性预计不会是动态的，因为它是由移动节点的到达控制的；但是，在时间尺度上，配置应该与路由配置类似。NETLMM协议可以指定默认的转发机制。还可能需要额外的工作来指定特定转发机制和NETLMM协议之间的交互，但是这项工作不在NETLMM基本协议的范围内。
There are two kinds of security issues involved in network-based localized mobility management: security between the mobile node and the network, and security between network elements that participate in the NETLMM protocol. The security-related goals in this document, described in Section 3.3 and 3.5, focus on the former, because those are unique to network-based mobility management. The threat analysis document [2] contains a more detailed discussion of both kinds of threats, which the protocol design must address.
基于网络的本地化移动性管理涉及两类安全问题：移动节点和网络之间的安全，以及参与NETLMM协议的网络元素之间的安全。第3.3节和第3.5节中描述的本文件中的安全相关目标侧重于前者，因为这些目标是基于网络的移动性管理所独有的。威胁分析文件[2]对协议设计必须解决的两种威胁进行了更详细的讨论。
The authors would like to acknowledge the following people for particularly diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin.
作者要感谢以下特别勤奋的评论人士：Vijay Devarapalli、Peter McCann、Gabriel Montegon、Vidya Narayanan、Pekka Savola和Fred Templin。
[1] Kempf, J., Ed., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007.
[1] Kempf，J.，Ed.，“基于网络的本地化移动性管理（NETLMM）的问题陈述”，RFC 4830，2007年4月。
[2] Vogt, C., and Kempf, J., "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
[2] Vogt，C.和Kempf，J.，“基于网络的本地化移动性管理（NETLMM）的安全威胁”，RFC 4832，2007年4月。
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[3] Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[4] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[4] Carpenter，B.，“互联网的建筑原理”，RFC 19581996年6月。
[5] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005.
[5] 崔，JH。和G.Daley，“在IPv6中检测网络连接的目标”，RFC 41352005年8月。
[6] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[6] Eronen，P.，“IKEv2移动性和多址协议（MOBIKE）”，RFC4552006年6月。
[7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[7] IEEE，“无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.111999。
[8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June, 2001.
[8] IEEE，“基于端口的访问控制”，IEEE LAN/MAN标准802.1x，2001年6月。
[9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[9] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[10] Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[11] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[11] Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC4423，2006年5月。
[12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[12] Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[13] Soliman，H.，Castelluccia，C.，El Malki，K.，和L.Bellier，“分层移动IPv6移动性管理（HMIPv6）”，RFC 41402005年8月。
[14] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[14] Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC3810，2004年6月。
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kleung@cisco.com
Kent Leung Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134电子邮件：kleung@cisco.com
Phil Roberts Motorola Labs Schaumberg, IL USA EMail: phil.roberts@motorola.com
Phil Roberts Motorola Labs Schaumbeg，伊利诺伊州美国电子邮件：Phil。roberts@motorola.com
Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 EMail: nishidak@nttdocomo.co.jp
西田胜寿NTT DoCoMo Inc.3-5 Hikarino oka，横须贺市神奈川，日本电话：+81 46 840 3545电子邮件：nishidak@nttdocomo.co.jp
Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 EMail: gerardo.giaretta@tilab.com
Gerardo Giaretta Telecom Italia Lab通过G.Reiss Romoli，274 10148意大利都灵电话：+39 011 2286904电子邮件：Gerardo。giaretta@tilab.com
Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 EMail: marco.liebsch@ccrle.nec.de
Marco Liebsch NEC网络实验室Kurfuersten Anlage 36 69115德国海德堡电话：+49 6221-90511-46电子邮件：Marco。liebsch@ccrle.nec.de
Editor's Address
编辑地址
James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com
詹姆斯·肯普夫·多科莫美国实验室加利福尼亚州圣何塞市地铁路181号300室95110美国电话：+1408 451 4711电子邮件：kempf@docomolabs-美国网
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编辑功能的资金目前由互联网协会提供。