Network Working Group F. Adrangi, Ed.
Request for Comments: 4093 Intel
Category: Informational H. Levkowetz, Ed.
Ericsson
August 2005
Network Working Group F. Adrangi, Ed.
Request for Comments: 4093 Intel
Category: Informational H. Levkowetz, Ed.
Ericsson
August 2005
Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways
问题陈述：虚拟专用网（VPN）网关的移动IPv4穿越
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 Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions.
在通过虚拟专用网（VPN）网关连接到Internet的网络中部署移动IP v4会带来一些目前没有详细描述的解决方案的问题。本文件旨在描述和说明这些问题，并为可能的解决方案提出一些指导方针。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Specification of Requirements ..............................3
1.3. Terminology ................................................3
2. MIP and VPN Deployment Scenarios ................................4
2.1. MIPv4 HA(s) Inside the Intranet behind a VPN Gateway .......5
2.2. VPN Gateway and MIPv4 HA(s) on the VPN Domain Border .......6
2.3. Combined VPN Gateway and MIPv4 HA ..........................7
2.4. MIPv4 HA(s) Outside the VPN Domain .........................8
2.5. Combined VPN Gateway and MIPv4 HA(s) on the Local Link .....9
3. Deployment Scenarios Selection ..................................9
4. Problem Statement ..............................................10
4.1. Registering in Co-Located Mode ............................11
4.2. Registering via an FA .....................................12
4.3. Summary: MIP Incompatibilities with IPsec-Based
VPN Gateways ..............................................13
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Specification of Requirements ..............................3
1.3. Terminology ................................................3
2. MIP and VPN Deployment Scenarios ................................4
2.1. MIPv4 HA(s) Inside the Intranet behind a VPN Gateway .......5
2.2. VPN Gateway and MIPv4 HA(s) on the VPN Domain Border .......6
2.3. Combined VPN Gateway and MIPv4 HA ..........................7
2.4. MIPv4 HA(s) Outside the VPN Domain .........................8
2.5. Combined VPN Gateway and MIPv4 HA(s) on the Local Link .....9
3. Deployment Scenarios Selection ..................................9
4. Problem Statement ..............................................10
4.1. Registering in Co-Located Mode ............................11
4.2. Registering via an FA .....................................12
4.3. Summary: MIP Incompatibilities with IPsec-Based
VPN Gateways ..............................................13
5. Solution Guidelines ............................................14
5.1. Preservation of Existing VPN Infrastructure ...............14
5.2. Software Upgrades to Existing VPN Client and Gateways .....14
5.3. IPsec Protocol ............................................14
5.4. Multi-Vendor Interoperability .............................14
5.5. MIPv4 Protocol ............................................15
5.6. Handoff Overhead ..........................................15
5.7. Scalability, Availability, Reliability, and Performance ...15
5.8. Functional Entities .......................................15
5.9. Implications of Intervening NAT Gateways ..................15
5.10. Security Requirements ....................................16
6. Security Considerations ........................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
5. Solution Guidelines ............................................14
5.1. Preservation of Existing VPN Infrastructure ...............14
5.2. Software Upgrades to Existing VPN Client and Gateways .....14
5.3. IPsec Protocol ............................................14
5.4. Multi-Vendor Interoperability .............................14
5.5. MIPv4 Protocol ............................................15
5.6. Handoff Overhead ..........................................15
5.7. Scalability, Availability, Reliability, and Performance ...15
5.8. Functional Entities .......................................15
5.9. Implications of Intervening NAT Gateways ..................15
5.10. Security Requirements ....................................16
6. Security Considerations ........................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
Mobile IP [RFC3344] agents are being deployed in enterprise networks to enable mobility across wired and wireless LANs while roaming inside the enterprise Intranet. With the growing deployment of IEEE 802.11 access points ("hot spots") in public places such as hotels, airports, and convention centers, and with wireless WAN data networks such as General Packet Radio Service (GPRS), the need is increasing for enabling mobile users to maintain their transport connections and constant reachability while connecting back to their target "home" networks protected by Virtual Private Network (VPN) technology. This implies that Mobile IP and VPN technologies have to coexist and function together in order to provide mobility and security to the enterprise mobile users.
移动IP[RFC3344]代理正在企业网络中部署，以实现在企业内部网内漫游时跨有线和无线LAN的移动。随着IEEE 802.11接入点（“热点”）在酒店、机场和会议中心等公共场所的不断部署，以及通用分组无线业务（GPRS）等无线广域网数据网络的不断发展，越来越需要使移动用户能够在连接回受虚拟专用网（VPN）技术保护的目标“家庭”网络的同时，保持其传输连接和恒定的可达性。这意味着移动IP和VPN技术必须共存并共同发挥作用，以便为企业移动用户提供移动性和安全性。
The goal of this document is to:
本文件的目标是：
o Identify and describe practical deployment scenarios for Mobile IP and VPN in enterprise and operator environments.
o 确定并描述企业和运营商环境中移动IP和VPN的实际部署场景。
o Identify example usage scenarios for remote users roaming outside the "home" network protected by a VPN gateway.
o 确定在受VPN网关保护的“家庭”网络之外漫游的远程用户的示例使用场景。
o Articulate the problems resulting from Mobile IP and VPN coexistence.
o 阐明移动IP和VPN共存带来的问题。
o Specify a set of framework guidelines to evaluate proposed solutions for supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN gateways.
o 指定一组框架指南，以评估支持跨基于IPsec的VPN网关的多供应商无缝IPv4移动的建议解决方案。
Access to the Intranet is typically guarded by both a firewall and a VPN device. The Intranet can only be accessed by respecting the security policies in the firewall and the VPN device.
对内部网的访问通常由防火墙和VPN设备共同保护。只有遵守防火墙和VPN设备中的安全策略，才能访问Intranet。
When MIP is deployed in a corporate Intranet (also referred to as a VPN domain), roaming between the Intranet (i.e., trusted domain) and the Internet (i.e., untrusted domain) becomes problematic. It would be desirable to have seamless session mobility between the two domains, because MIP was designed for session mobility regardless of the network point of attachment. Unfortunately, the current MIP standards fall short of this promise for an important customer segment: corporate users (using VPN for remote access) who desire to add mobility support because of a need to have continuous access to Intranet resources while roaming outside the Intranet from one subnet to another, or between the VPN domain and the Internet.
当MIP部署在公司内部网（也称为VPN域）中时，内部网（即受信任域）和Internet（即不受信任域）之间的漫游会出现问题。最好在两个域之间实现无缝会话移动，因为MIP是为会话移动而设计的，而不考虑网络连接点。不幸的是，当前的MIP标准没有满足一个重要客户群体的这一承诺：公司用户（使用VPN进行远程访问），他们希望增加移动支持，因为需要在从一个子网到另一个子网的内部网外漫游时连续访问内部网资源，或者在VPN域和Internet之间。
From the beginning, one explicitly stated restriction was that it was assumed that installed firewalls and VPN gateways had to be kept unchanged, rather than replaced or upgraded, because they have much wider deployments than MIP at the time of writing. Therefore, any solutions would need to minimize the impact on existing VPN and firewall deployments, related standards, and "de facto" standards.
从一开始，一个明确规定的限制是，假定已安装的防火墙和VPN网关必须保持不变，而不是更换或升级，因为在撰写本文时，它们的部署范围要比MIP广泛得多。因此，任何解决方案都需要尽量减少对现有VPN和防火墙部署、相关标准和“事实”标准的影响。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
MIPv4 Mobile IP for IPv4 [RFC3344]
用于IPv4的MIPv4移动IP[RFC3344]
MIPv6 Mobile IP for IPv6
用于IPv6的MIPv6移动IP
VPN Virtual Private Network
虚拟私有网
GW Gateway
网关
VPN Domain An Intranet protected by a VPN gateway.
VPN域受VPN网关保护的内部网。
DMZ (Demilitarized Zone) A small network inserted as a "neutral zone" between a company's private network and the outside public network to prevent outside users from getting direct access to the company's private network.
DMZ（非军事区）：插入公司专用网络和外部公共网络之间作为“中立区”的小型网络，以防止外部用户直接访问公司专用网络。
Home Network A network, possibly virtual, having a network prefix matching that of a mobile node's home address.
家庭网络可能是虚拟的网络，其网络前缀与移动节点的家庭地址匹配。
Home Agent A router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node.
归属代理移动节点的归属网络上的路由器，它通过隧道传输数据报，以便在移动节点离家时传送到移动节点，并维护移动节点的当前位置信息。
MN Refers to a mobile node that runs both MIP and IPsec-based VPN client software.
MN指同时运行MIP和基于IPsec的VPN客户端软件的移动节点。
MIPv4 inside IPsec-ESP tunnel MIPv4 packets are encapsulated in an IPsec-ESP tunnel established between the Mobile Node and the VPN gateway.
IPsec ESP隧道内的MIPv4 MIPv4数据包封装在移动节点和VPN网关之间建立的IPsec ESP隧道中。
IPsec-ESP inside MIPv4 tunnel IPsec-ESP packets are encapsulated in a MIPv4 tunnel established between the Mobile Node and the home agent.
MIPv4隧道内的IPsec ESP IPsec ESP数据包封装在移动节点和归属代理之间建立的MIPv4隧道中。
This section describes a set of deployment scenarios wherein MIP agents and VPN gateways have to coexist to provide mobility and security. The intention is to identify practical deployment scenarios for MIP and VPNs where MIP technology might be extended to solve problems resulting from the desire for co-existence.
本节描述一组部署场景，其中MIP代理和VPN网关必须共存以提供移动性和安全性。目的是确定MIP和VPN的实际部署场景，在这些场景中，MIP技术可能会被扩展，以解决由于希望共存而产生的问题。
The network topology in the following diagrams consists of an Intranet connected to the public network (i.e., the Internet). Here, the word "Intranet" refers to a private network (where private addresses [RFC1918] are typically used) protected by a VPN gateway and perhaps by a layer-3 transparent or non-transparent firewall. When private addresses are used, the non-transparent firewall also functions as a Network Address Translator (NAT) or Network Address Port Translator (NAPT) bridging between the two address realms (i.e., the Intranet and the Internet).
下图中的网络拓扑由连接到公共网络（即Internet）的内部网组成。这里，“Intranet”一词指的是受VPN网关保护的专用网络（通常使用专用地址[RFC1918]），也可能由第3层透明或不透明防火墙保护。当使用私有地址时，不透明防火墙还充当两个地址域（即，内部网和Internet）之间的网络地址转换器（NAT）或网络地址端口转换器（NAPT）桥接。
Firewalls may be placed on either side of the VPN gateway; these are referred to as inner and outer firewalls. The inner and outer firewalls typically inspect outbound traffic (i.e., from the Intranet to the Internet) and inbound traffic (i.e., from the Internet to the
防火墙可以放置在VPN网关的任一侧；这些被称为内部防火墙和外部防火墙。内部和外部防火墙通常检查出站流量（即从Intranet到Internet）和入站流量（即从Internet到Internet）
Intranet), respectively. When a firewall is present, it MUST be configured to allow Mobile IP traffic (both control and tunneled data packets) to go through. As our focus here is the relationship between MIP and VPN, we have purposely omitted firewalls from the following scenarios in order to keep things simple.
内联网），分别。当防火墙存在时，必须将其配置为允许移动IP流量（控制和隧道数据包）通过。由于我们这里的重点是MIP和VPN之间的关系，我们特意在以下场景中省略防火墙，以保持简单。
It is assumed that encryption is not enforced inside the VPN domain because: 1) the VPN domain (Intranet) is viewed as a trusted network, and users allowed inside the Intranet are also trusted, and 2) it is a common VPN deployment practice where the VPN is used to guard the Intranet resources from unauthorized users attached to an untrusted network, and to provide a secure communication channel for authorized users to access resources inside the Intranet from outside.
假设在VPN域内不强制加密，因为：1）VPN域（Intranet）被视为受信任的网络，并且允许在Intranet内的用户也受信任，2）这是一种常见的VPN部署实践，其中VPN用于保护内部网资源，防止未经授权的用户连接到不受信任的网络，并为授权用户从外部访问内部网资源提供安全的通信通道。
The following sub-sections introduce five representative combinations of MIPv4 HA and VPN gateway placement.
以下小节介绍了MIPv4 HA和VPN网关布局的五种代表性组合。
In order to give a reasonably complete survey of MIPv4 and VPN co-existence scenarios, those in Sections 2.3 and 2.5 are included even though, as covered in more detail below, there are no co-existence problems to be solved in these two cases.
为了对MIPv4和VPN共存场景进行合理完整的调查，包括第2.3节和第2.5节中的场景，尽管如下文所述，在这两种情况下没有需要解决的共存问题。
MIPv4 HAs are deployed inside the Intranet protected by a VPN gateway, and are not directly reachable by the MNs outside the Intranet.
MIPv4已部署在受VPN网关保护的Intranet内，并且不能由Intranet外的MNs直接访问。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | HA | .
. |away| | | .<=========>| | | 1..n | | 1..n | .
. +----+ +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | HA | .
. |away| | | .<=========>| | | 1..n | | 1..n | .
. +----+ +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 1
图1
Direct application of MIPv4 standards [RFC3344] is successfully used to provide mobility for users inside the Intranet. However, mobile users outside the Intranet can only access the Intranet resources (e.g., MIP agents) through the VPN gateway, which will allow only
MIPv4标准[RFC3344]的直接应用成功地用于为内部网内的用户提供移动性。但是，内部网之外的移动用户只能通过VPN网关访问内部网资源（例如，MIP代理），该网关只允许
authenticated IPsec traffic inside. This implies that the MIPv4 traffic has to run inside IPsec, which leads to two distinct problems:
内部经过身份验证的IPsec通信。这意味着MIPv4通信必须在IPsec内部运行，这会导致两个不同的问题：
1. When the foreign network has an FA deployed (e.g., as in CDMA 2000), MIPv4 registration becomes impossible. This is because the MIPv4 traffic between MN and VPN gateway is encrypted, and the FA (which is likely in a different administrative domain) cannot inspect the MIPv4 headers needed for relaying the MIPv4 packets. Please see Section 4.2 for more details.
1. 当外部网络部署了FA时（例如，在CDMA 2000中），MIPv4注册变得不可能。这是因为MN和VPN网关之间的MIPv4通信是加密的，FA（可能位于不同的管理域中）无法检查中继MIPv4数据包所需的MIPv4报头。更多详情请参见第4.2节。
2. In co-located mode, successful registration is possible but the VPN tunnel has to be re-negotiated every time the MN changes its point of network attachment.
2. 在同一位置模式下，可以成功注册，但每次MN更改其网络连接点时，都必须重新协商VPN隧道。
These problems are articulated in Section 4.
第4节阐述了这些问题。
This deployment scenario may not be common yet, but it is practical and is becoming important as there is an increasing need for providing corporate remote users with continuous access to the Intranet resources.
这种部署场景可能还不常见，但它是实用的，并且变得越来越重要，因为越来越需要为公司远程用户提供对Intranet资源的连续访问。
A MIPv4 HA is deployed on the VPN domain border (e.g., in the DMZ) together with the VPN gateway, and it is directly reachable by MNs inside or outside the Intranet.
MIPv4 HA与VPN网关一起部署在VPN域边界（例如，在DMZ中），可由内联网内外的MNs直接访问。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<=========>| | | 1..n | .
. +----+ +----+ . /\ | GW | +-------+ .
. . || +----+ .
. . || +----+ +-------+ +-------+ .
. . ++====>| HA | | CN | | MNs | .
................... | | | 1..n | | home | .
+----+ +-------+ +-------+ .
. .
................................
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<=========>| | | 1..n | .
. +----+ +----+ . /\ | GW | +-------+ .
. . || +----+ .
. . || +----+ +-------+ +-------+ .
. . ++====>| HA | | CN | | MNs | .
................... | | | 1..n | | home | .
+----+ +-------+ +-------+ .
. .
................................
Figure 2
图2
Please note that in deployments where the security policy prohibits direct communication between the MN (roaming outside the Intranet) and outside machines, the HA can be configured to forward only encrypted traffic from/to the MN.
请注意，在安全策略禁止MN（在Intranet外部漫游）和外部机器之间直接通信的部署中，HA可以配置为仅转发来自/到MN的加密流量。
The MIPv4 HA has a public interface connected to the Internet, and a private interface attached to the Intranet. Mobile users will most likely have a virtual home network associated with the MIPv4 HA's private interface, so that the mobile users are always away from home and thus registered with the MIPv4 HA. Furthermore, in deployments where the VPN gateway and the HA are placed in a corporate DMZ, this implies that MIPv4 traffic will always be routed through the DMZ (regardless of whether MNs are located outside or inside the Intranet), which may not be acceptable to IT departments in large corporations.
MIPv4 HA有一个连接到Internet的公共接口和一个连接到Intranet的专用接口。移动用户最有可能拥有一个与MIPv4 HA的专用接口相关联的虚拟家庭网络，因此移动用户总是不在家，并因此向MIPv4 HA注册。此外，在VPN网关和HA放置在企业DMZ中的部署中，这意味着MIPv4流量将始终通过DMZ路由（无论MN位于内部网还是外部），这对于大型企业的IT部门来说可能是不可接受的。
This deployment can be used with two different configurations: "MIPv4 inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The "MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario in Section 2.1. (Namely, MIPv4 registration becomes impossible when the registration is to be done via an FA, and furthermore, in co-located mode, the VPN tunnel has to be re-negotiated every time the MN changes its point of attachment.) The "IPsec-ESP inside MIPv4 tunnel" does not have the problems described in Section 2.1; however, it will require some modifications to the routing logic of the MIPv4 HA or the VPN gateway.
此部署可用于两种不同的配置：“IPsec ESP隧道内的MIPv4”和“MIPv4隧道内的IPsec ESP”。“IPsec ESP隧道内的MIPv4”与第2.1节中的场景具有相同的问题。（即，当通过FA进行注册时，MIPv4注册变得不可能，而且，在同一位置模式下，每次MN更改其连接点时，必须重新协商VPN隧道。）“MIPv4隧道内的IPsec ESP”不存在第2.1节中描述的问题；但是，它需要对MIPv4 HA或VPN网关的路由逻辑进行一些修改。
This is similar to the deployment scenario described in Section 2.2, with the exception that the VPN gateway and MIPv4 HA are running on the same physical machine.
这与第2.2节中描述的部署场景类似，只是VPN网关和MIPv4 HA在同一台物理机器上运行。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . | + | +-------+ .
. . | HA | .
................... +----+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . | + | +-------+ .
. . | HA | .
................... +----+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 3
图3
Running MIPv4 HA and VPN on the same machine resolves routing-related issues that exist in Section 2.2 when a "IPsec-ESP inside MIPv4 tunnel" configuration is used. However, it does not promote multi-vendor interoperability in environments where MIPv4 HA and VPN technologies must be acquired from different vendors.
在同一台计算机上运行MIPv4 HA和VPN可以解决第2.2节中使用“IPsec ESP inside MIPv4 tunnel”配置时存在的路由相关问题。但是，在必须从不同供应商处获得MIPv4 HA和VPN技术的环境中，它不能促进多供应商的互操作性。
In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g., in an operator network), as depicted in Figure 4, below.
在此场景中，MIPv4已部署在内部网之外（例如，在运营商网络中），如下图4所示。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . /\ | | +-------+ .
. . || | | .
................... || | | +-------+ +-------+ .
|| | | | CN | | MNs | .
.....MIPv4 Home.... || | | | 1..n | | home | .
. .<===++ | | +-------+ +-------+ .
. +------+ . +----+ .
. | HAs | . . .
. | 1..n | . ................................
. +------+ .
...................
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . /\ | | +-------+ .
. . || | | .
................... || | | +-------+ +-------+ .
|| | | | CN | | MNs | .
.....MIPv4 Home.... || | | | 1..n | | home | .
. .<===++ | | +-------+ +-------+ .
. +------+ . +----+ .
. | HAs | . . .
. | 1..n | . ................................
. +------+ .
...................
Figure 4
图4
The IPsec tunnel endpoints will be the MN and the VPN gateway. The 'home network' will most likely be a virtual home network, located at the HA, through which authorized remote users (i.e., those that have successfully established a connection to the corporate VPN) can reach the Corporate Intranet and maintain their transport session connectivity while roaming outside the Intranet from one subnet to another. Please note that this deployment scenario does not support mobility inside the Intranet.
IPsec隧道端点将是MN和VPN网关。“家庭网络”最有可能是位于HA的虚拟家庭网络，授权的远程用户（即已成功建立到公司VPN连接的用户）可以通过该网络访问公司内部网，并在从一个子网到另一个子网的内部网外漫游时保持其传输会话连接。请注意，此部署方案不支持内部网内的移动。
In this case, it is most practical to run IPsec-ESP inside a MIPv4 tunnel (i.e., the MIPv4 tunnel endpoints are the MN and the HA; the IPsec-ESP packet from the MN and to the VPN gateway is encapsulated in the MIPv4 tunnel). This is because the MNs can register with the HA without establishing an IPsec tunnel to the VPN gateway.
在这种情况下，最实际的做法是在MIPv4隧道内运行IPsec ESP（即，MIPv4隧道端点是MN和HA；从MN到VPN网关的IPsec ESP数据包封装在MIPv4隧道中）。这是因为MNs可以向HA注册，而无需建立到VPN网关的IPsec隧道。
This is similar to the deployment scenario described in Section 2.3, with the difference that the VPN gateway/HA is sitting on the local link. In this case, the VPN gateway and HA would most naturally be co-located in the same box, although this is in no way a requirement.
这与第2.3节中描述的部署场景类似，不同之处在于VPN网关/HA位于本地链路上。在这种情况下，VPN网关和HA自然会位于同一个盒子中，尽管这不是一种要求。
The VPN/HA is assumed to be reachable from the external network; i.e., it is assumed to have a public IP address, and the firewall is assumed to be configured to allow direct access to the VPN/HA from the external network.
假设VPN/HA可从外部网络访问；i、 例如，假定其具有公共IP地址，并且假定防火墙被配置为允许从外部网络直接访问VPN/HA。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +------+ +-------+ +-------+ .
. |MNs | | FA | . | Fire | | Router| | VPN/HA| .
. |away| | | .<=======>| wall | | 1..n | | 1..n | .
. +----+ +----+ . | | +-------+ +-------+ .
. . | NAT | .
................... +------+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +------+ +-------+ +-------+ .
. |MNs | | FA | . | Fire | | Router| | VPN/HA| .
. |away| | | .<=======>| wall | | 1..n | | 1..n | .
. +----+ +----+ . | | +-------+ +-------+ .
. . | NAT | .
................... +------+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 5
图5
This deployment works today without any technical problems with IPsec-ESP running inside a MIPv4 tunnel. If you were to run MIPv inside the IPsec-ESP tunnel, it would have the same problems as in Section 2.1, so it is deployed with the IPsec-ESP running inside the MIPv4 tunnel. This deployment is not practical for large deployments (on the order of thousands of users) because of the large and distributed security perimeter.
今天，在MIPv4隧道内运行IPsec ESP时，此部署不会出现任何技术问题。如果要在IPsec ESP隧道内运行MIPv，它将遇到与第2.1节中相同的问题，因此它是在IPsec ESP在MIPv4隧道内运行的情况下部署的。这种部署不适用于大型部署（数千用户），因为安全周界庞大且分散。
The deployment scenarios described in Section 2 were evaluated to identify those most in need of solving. The evaluation was done based on two main criteria: 1) Is the deployment scenario common and practical? and 2) Does the deployment scenario reveal any problems resulting from MIPv4 and VPN coexistence?
对第2节中描述的部署场景进行了评估，以确定最需要解决的部署场景。评估是基于两个主要标准进行的：1）部署场景是否通用和实用？以及2）部署场景是否揭示了MIPv4和VPN共存导致的任何问题？
The authors believe that the scenario in Section 2.1 is the most important and practical one because of a rising need for providing corporate remote users with continuous access to their Intranet resources. After analyzing each scenario, one realizes that problems
作者认为，第2.1节中的场景是最重要和最实际的场景，因为越来越需要为企业远程用户提供对其内部网资源的连续访问。在分析每个场景之后，我们会意识到问题
occurring in scenarios in Sections 2.2 and 2.4 are either the same as those in the scenario in Section 2.1 or a subset of them. Therefore, solving the scenario in Section 2.1 will also solve the scenarios in Sections 2.2 and 2.4. The scenarios in Sections 2.3 and 2.5 do not introduce functional problems resulting from MIPv4 and VPN co-existence, and thus there is no need to seek a solution. A solution for the deployment scenario in Section 2.1 is therefore seen as essential, and this in turn can also be applied to solve problems in other scenarios. In subsequent sections, we will articulate the roaming scenarios, the problems, and the solution guidelines relevant to the scenario in Section 2.1.
发生在第2.2节和第2.4节中的场景与第2.1节中的场景相同，或者是其中的一个子集。因此，解决第2.1节中的场景也将解决第2.2节和第2.4节中的场景。第2.3节和第2.5节中的场景没有引入因MIPv4和VPN共存而导致的功能问题，因此无需寻求解决方案。因此，第2.1节中的部署场景解决方案被视为必不可少的，这反过来也可以应用于解决其他场景中的问题。在后续章节中，我们将在第2.1节中阐述漫游场景、问题以及与场景相关的解决方案指南。
This section describes roaming scenarios corresponding to the deployment scenario in Section 2.1 where an MN needs to have continuous access to the Intranet resources regardless of whether it is roaming inside or outside the Intranet, and their associated problems. The scenarios are constructed based on a multi-subnetted, MIPv4-enabled Intranet (hereafter referred to as Intranet or VPN domain) protected by an IPsec-based VPN gateway as depicted in Figure 6.
本节描述了与第2.1节中部署场景相对应的漫游场景，其中MN需要连续访问Intranet资源，而不管它是在Intranet内部还是外部漫游，以及它们的相关问题。这些场景基于多个子网、支持MIPv4的Intranet（以下称为Intranet或VPN域）构建，由基于IPsec的VPN网关保护，如图6所示。
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 6: Intranet protected by a VPN gateway
图6：受VPN网关保护的Intranet
The Intranet, as depicted in Figure 6, may include both wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments. However, it is also possible to see IEEE 802.11 deployments outside the Intranet due to the perceived lack of current 802.11 security, as depicted in Figure 7.
如图6所示，内部网可能包括有线（IEEE 802.3）和IEEE 802.11无线LAN部署。然而，也可以看到由于缺乏当前802.11安全性而在内部网之外部署IEEE 802.11，如图7所示。
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . | | .
................... | | +-------+ +-------+ .
| | | CN | | MNs | .
..802.11 Wireless.. <====>| | | 1..n | | home | .
. Network . +----+ +-------+ +-------+ .
. . . .
................... ................................
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . | | .
................... | | +-------+ +-------+ .
| | | CN | | MNs | .
..802.11 Wireless.. <====>| | | 1..n | | home | .
. Network . +----+ +-------+ +-------+ .
. . . .
................... ................................
Figure 7: IEEE 802.11 Wireless deployment outside the home network
图7:IEEE 802.11家庭网络外部无线部署
In co-located mode, the IPsec tunnel endpoints would be at the MN and the VPN gateway, which (supposing we have the scenario described in Section 2.1) results in the mobile-ip tunnel from MN to HA being encapsulated inside the IPsec tunnel. See Figure 8 below. This scenario is still possible, but has some major drawbacks.
在同一位置模式下，IPsec隧道端点将位于MN和VPN网关，这（假设我们有第2.1节中描述的场景）导致从MN到HA的移动ip隧道被封装在IPsec隧道内。参见下面的图8。这种情况仍然可行，但有一些主要缺点。
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away|<###################>| |-----| 1..n |->| 1..n | .
. +----+ . \ | GW | +-------+ +-------+ .
. . \ +----+ .
................... mip . +-------+ +-------+ .
inside . | CN | | MNs | .
IPsec . | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away|<###################>| |-----| 1..n |->| 1..n | .
. +----+ . \ | GW | +-------+ +-------+ .
. . \ +----+ .
................... mip . +-------+ +-------+ .
inside . | CN | | MNs | .
IPsec . | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 8
图8
The MN obtains an address at its point of attachment (via DHCP [RFC2131] or some other means), and then sets up an IPsec tunnel to the VPN gateway, after which it can successfully register with its HA through the IPsec tunnel. The IPsec tunnel SA (Security Association) is identified by a triplet consisting of SPI (Security Parameter Index), MN's IP destination address (i.e., the address obtained at the point of attachment), and Security Protocol (AH or ESP) Identifier as described in [RFC2401]. This means that as the MN's IP
MN在其连接点获得一个地址（通过DHCP[RFC2131]或一些其他方式），然后建立一个到VPN网关的IPsec隧道，之后它可以通过IPsec隧道成功地向其HA注册。IPsec隧道SA（安全关联）由三元组标识，三元组由SPI（安全参数索引）、MN的IP目标地址（即在连接点获得的地址）和安全协议（AH或ESP）标识符组成，如[RFC2401]所述。这意味着作为MN的IP
destination address changes on each IP subnet handoff, the IPsec tunnel needs to be re-established. This could have noticeable performance implications on real-time applications and in resource-constrained wireless networks. In effect, we don't have mobility support for the tunnel endpoint changes associated with MN movements.
目标地址在每次IP子网切换时发生更改，需要重新建立IPsec隧道。这可能会对实时应用程序和资源受限的无线网络产生显著的性能影响。实际上，我们对与MN移动相关的隧道端点变化没有移动性支持。
In the case where a mobile node is in a network where mobility support is provided through the use of an FA, and no DHCP allocated address and co-located mode is possible, we run into severe trouble. This is illustrated in Figure 9 and explained below:
如果移动节点位于通过使用FA提供移动性支持的网络中，并且不可能使用DHCP分配的地址和共址模式，那么我们会遇到严重的问题。图9对此进行了说明，并解释如下：
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | VPN/HA| .
. |away|<??| |<###########>| |-----| 1..n |->| 1..n | .
. +----+ \ +----+ . \ | GW | +-------+ +-------+ .
. \ . \ +----+ .
...........\....... mip . +-------+ +-------+ .
\ inside . | CN | | MNs | .
MN expects IPsec . | 1..n | | home | .
IPsec traffic . +-------+ +-------+ .
. .
................................
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | VPN/HA| .
. |away|<??| |<###########>| |-----| 1..n |->| 1..n | .
. +----+ \ +----+ . \ | GW | +-------+ +-------+ .
. \ . \ +----+ .
...........\....... mip . +-------+ +-------+ .
\ inside . | CN | | MNs | .
MN expects IPsec . | 1..n | | home | .
IPsec traffic . +-------+ +-------+ .
. .
................................
Figure 9
图9
When arriving at the visited network on the left in this figure, the MN has to reach the FA with registration requests in order to have the FA send them on to the HA. However, the MN in all likelihood cannot register with the FA because the registration requests will be sent encrypted, and the FA will not be able to decrypt them. If the MN would have a policy that allowed split tunneling so that it could reach the FA with clear text messages, then the FA would still not be able to get through the VPN gateway unless the HA is reachable from outside and the Intranet security policy allows MIP registration packets to bypass the VPN gateway.
当到达图中左侧的访问网络时，MN必须向FA发送注册请求，以便FA将其发送给HA。然而，MN很可能无法向FA注册，因为注册请求将被加密发送，而FA将无法解密它们。如果MN具有允许拆分隧道的策略，以便可以通过明文消息到达FA，则FA仍然无法通过VPN网关，除非可以从外部访问HA，并且Intranet安全策略允许MIP注册数据包绕过VPN网关。
Even if the HA is reachable and the MIP registration succeeds, the FA (which is likely in a different administrative domain) will not be able to relay packets between the MN and the VPN gateway. Packets from the MN will be encapsulated by the FA with IP-in-IP [RFC2003], which the VPN gateway will drop, and packets from the VPN gateway will have ESP payloads (with IP-in-IP inside), which the FA will drop (as it expects IP-in-IP-encapsulated traffic to the MN).
即使HA是可访问的并且MIP注册成功，FA（可能在不同的管理域中）也将无法在MN和VPN网关之间中继数据包。来自MN的数据包将由FA用IP-in-IP[RFC2003]进行封装，VPN网关将丢弃该数据包，来自VPN网关的数据包将具有ESP有效负载（IP-in-IP-in-in-in-in-in-in-in-IP），FA将丢弃该有效负载（因为它期望IP-in-in-IP封装的流量到达MN）。
The use of a 'trusted FA' has also been suggested in this scenario, meaning an FA that is actually a combined VPN GW and FA. The scenario will work fine in this case, as the tunnel end-points are at the FA and the VPN gateway as shown in Figure 10 below. However, we cannot expect that the FA in access networks (e.g., wireless hot-spots or CDMA 2000 networks) will have security associations with any given corporate network, so this is not particularly realistic in the general mobility case.
在此场景中还建议使用“可信FA”，这意味着FA实际上是VPN GW和FA的组合。在这种情况下，该场景可以正常工作，因为隧道端点位于FA和VPN网关，如下图10所示。然而，我们不能期望接入网络（例如，无线热点或CDMA 2000网络）中的FA与任何给定的公司网络具有安全关联，因此这在一般移动性情况下并不特别现实。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. | FA | | VPN| . | VPN| | Router| | VPN/HA| .
. | |<--| GW |<###########>| |-----| 1..n |->| 1..n | .
. +----+ +----+ . \ | GW | +-------+ +-------+ .
. | . \ +----+ .
. +----+ . mip . +-------+ +-------+ .
. |MNs | . inside . | CN | | MNs | .
. |away| . IPsec . | 1..n | | home | .
. +----+ . . +-------+ +-------+ .
................... . .
................................
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. | FA | | VPN| . | VPN| | Router| | VPN/HA| .
. | |<--| GW |<###########>| |-----| 1..n |->| 1..n | .
. +----+ +----+ . \ | GW | +-------+ +-------+ .
. | . \ +----+ .
. +----+ . mip . +-------+ +-------+ .
. |MNs | . inside . | CN | | MNs | .
. |away| . IPsec . | 1..n | | home | .
. +----+ . . +-------+ +-------+ .
................... . .
................................
Figure 10
图10
Furthermore, this solution would leave the traffic between FA and MN unprotected, and as this link in particular may be a wireless link, this is clearly undesirable.
此外，该解决方案将使FA和MN之间的通信量不受保护，并且由于该链路尤其可能是无线链路，这显然是不可取的。
An MN roaming outside the Intranet has to establish an IPsec tunnel to its home VPN gateway first, in order to be able to register with its home agent. This is because the MN cannot reach its HA (inside the private protected network) directly from the outside. This implies that the MIPv4 traffic from the MN to a node inside the Intranet is forced to run inside an IPsec tunnel, and thus that it will not be in the clear. This in turn leads to two distinct problems depending on whether the MN uses co-located or non-co-located modes to register with its HA.
在内部网外漫游的MN必须首先建立到其家庭VPN网关的IPsec隧道，以便能够向其家庭代理注册。这是因为MN无法直接从外部到达其HA（在专用保护网络内）。这意味着从MN到Intranet内的节点的MIPv4流量将被迫在IPsec隧道内运行，因此它不会处于清除状态。这进而导致两个不同的问题，这取决于MN是使用同一位置还是非同一位置模式向其HA注册。
In co-located mode, the IPsec tunnel needs to be re-established on each IP subnet handoff, which will have performance implications on real-time applications and resource-constrained wireless networks.
在同一位置模式下，需要在每个IP子网切换上重新建立IPsec隧道，这将对实时应用程序和资源受限的无线网络产生性能影响。
In non-co-located mode (i.e., using an FA care-of address), the problem becomes severe, as the MN may be unable to register with its HA through the FA because the FA cannot understand MIPv4 registration
在非同址模式下（即，使用FA转交地址），问题变得严重，因为MN可能无法通过FA向其HA注册，因为FA无法理解MIPv4注册
requests if they are encrypted in the IPsec tunnel (i.e., split tunneling is not supported). Even if the MN could reach the FA with non-encrypted registration requests (i.e., split tunneling is supported), and the requests going from the FA to the HA can pass through the VPN gateway, there would still be a problem with routing of data packets between the Intranet and the internet. This is because the VPN will not allow IP-in-IP-encapsulated packets from the FA to go through. And furthermore, ESP-encapsulated packets from the VPN gateway to the MN will be dropped by the FA, as it expects IP-in-IP-encapsulated traffic to the MN.
请求，如果它们在IPsec隧道中加密（即，不支持拆分隧道）。即使MN可以通过非加密的注册请求（即，支持拆分隧道）到达FA，并且从FA到HA的请求可以通过VPN网关，内部网和internet之间的数据包路由仍然存在问题。这是因为VPN将不允许来自FA的IP封装包中的IP通过。此外，从VPN网关到MN的ESP封装数据包将被FA丢弃，因为它期望到MN的IP封装流量中包含IP。
This section describes guidelines for a solution to MIPv4 traversal across VPN gateways.
本节介绍跨VPN网关的MIPv4遍历解决方案的指导原则。
o The solution MUST work with currently deployed VPN gateways. This is the whole raison d'etre of this investigation: Finding a way to deploy Mobile-IP in cases where a VPN solution is already in place.
o 该解决方案必须与当前部署的VPN网关配合使用。这就是本次调查的全部理由：找到一种在已有VPN解决方案的情况下部署移动IP的方法。
o The solution SHOULD minimize changes to existing VPN client/gateway software.
o 该解决方案应尽量减少对现有VPN客户端/网关软件的更改。
o The solution SHOULD NOT require any changes to existing IPsec or key-exchange standard protocols implemented by VPN gateways.
o 解决方案不应要求对VPN网关实现的现有IPsec或密钥交换标准协议进行任何更改。
o The solution SHOULD NOT require that the VPN gateway or the VPN client implement any new protocols in addition to the existing standard protocols.
o 解决方案不应要求VPN网关或VPN客户端实现现有标准协议之外的任何新协议。
o The solution MUST provide multi-vendor interoperability, whereby MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN client solutions may come from four different vendors. This is typical for medium and large enterprises that purchase and deploy best-of-breed multi-vendor solutions for IP routing, VPNs, firewalls, etc.
o 该解决方案必须提供多供应商互操作性，因此，MIPv4移动代理、移动客户端（MN）、VPN服务器和VPN客户端解决方案可能来自四个不同的供应商。这对于购买和部署用于IP路由、VPN、防火墙等的同类最佳多供应商解决方案的中型和大型企业来说是典型的。
o The solution MUST adhere to MIPv4 protocol [RFC3344]. That is, the solution MUST NOT impose any changes that violate MIPv4 protocol.
o 解决方案必须遵守MIPv4协议[RFC3344]。也就是说，解决方案不得施加任何违反MIPv4协议的更改。
o The solution MAY introduce new extensions to MIPv4 nodes per guidelines specified in the MIPv4 protocol [RFC3344]. However, in order to overcome barriers to deployment, it is highly desirable to avoid any changes to MIPv4 mobility agents such as the FA and HA.
o 该解决方案可根据MIPv4协议[RFC3344]中规定的准则，向MIPv4节点引入新的扩展。然而，为了克服部署障碍，最好避免对MIPv4移动代理（如FA和HA）进行任何更改。
o The solution MAY require more than one instance of MIPv4 running in parallel (multiple encapsulation).
o 解决方案可能需要多个并行运行的MIPv4实例（多重封装）。
o It is imperative to keep the key management overhead down to a minimum, in order to support fast handoffs across IP subnets. Therefore, the solution MUST propose a mechanism to avoid or minimize IPsec tunnel SA renegotiation and IKE renegotiation as the MN changes its current point of network attachment.
o 为了支持跨IP子网的快速切换，必须将密钥管理开销降至最低。因此，解决方案必须提出一种机制，以避免或最小化当MN更改其当前网络连接点时IPsec隧道SA重新协商和IKE重新协商。
o The solution complexity MUST increase at most linearly with the number of MNs registered and accessing resources inside the Intranet.
o 解决方案的复杂性必须随着内部网中注册和访问资源的MN数量的增加而线性增加。
o The solution MAY introduce additional header or tunneling overhead if needed.
o 如果需要，该解决方案可能会引入额外的标头或隧道开销。
o The solution MAY introduce new MIPv4-compliant functional entities.
o 该解决方案可能会引入新的符合MIPv4的功能实体。
o The solution MUST be able to work with the existing MIPv4 and IPsec NAT traversal solutions [RFC3519] [RFC3715] [RFC3947].
o 该解决方案必须能够与现有的MIPv4和IPsec NAT穿越解决方案配合使用[RFC3519][RFC3715][RFC3947]。
o The solution MUST provide security that is not inferior to what is already provided to existing "nomadic computing" remote access users; i.e., for confidentiality, authentication, message integrity, protection against replay attacks, and related security services.
o 解决方案必须提供不低于现有“游牧计算”远程访问用户的安全性；i、 例如，保密性、身份验证、消息完整性、防止重播攻击以及相关安全服务。
This document describes an existing problem and proposes guidelines for possible solutions; as such, its security implications are indirect, through the guidelines it proposes for the solutions. Section 5.10 gives the relevant security requirements.
本文件描述了存在的问题，并提出了可能的解决方案指南；因此，通过它为解决方案提出的指导方针，它的安全影响是间接的。第5.10节给出了相关的安全要求。
The authors who contributed text to this document were, in no particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider, and Henrik Levkowetz.
向本文件投稿的作者顺序不分先后：Farid Adrangi、Milind Kulkarni、Gopal Dommety、Eli Gelasco、Zhangang、Sami Vaarala、Dorothy Gellert、Nitsan Baider和Henrik Levkowetz。
The authors would like to thank other contributors, especially Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung, Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti Nuopponen, Alan O'Neill, Gaetan Feige, and Brijesh Kumar, for their feedback and help in improving this document.
作者要感谢其他撰稿人，特别是Prakash Iyer、Mike Andrews、Ranjit Narjala、Joe Lau、Kent Leung、Alpesh Patel、Phil Roberts、Hans Sjostrand、Serge Tessier、Antti Nuopponen、Alan O’Neill、Gaetan Feige和Brijesh Kumar，感谢他们在改进本文件方面的反馈和帮助。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003.
[RFC3519]Levkowetz，H.和S.Vaarala，“网络地址转换（NAT）设备的移动IP遍历”，RFC 3519，2003年5月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
Authors' Addresses
作者地址
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro OR USA
Farid Adrangi Intel Corporation 2111美国希尔斯堡东北25大道
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Henrik Levkowetz Ericsson Research Torshamsgatan 23 SE-164 80 Stockholm SWEDEN
Henrik Levkowetz Ericsson Research Torshamsgatan 23 SE-164 80瑞典斯德哥尔摩
Phone: +46 7 08 32 16 08
EMail: henrik@levkowetz.com
Phone: +46 7 08 32 16 08
EMail: henrik@levkowetz.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。