Network Working Group S. Vaarala
Request for Comments: 5265 Codebay
Category: Standards Track E. Klovning
Birdstep
June 2008
Network Working Group S. Vaarala
Request for Comments: 5265 Codebay
Category: Standards Track E. Klovning
Birdstep
June 2008
Mobile IPv4 Traversal across IPsec-Based VPN Gateways
跨基于IPsec的VPN网关的移动IPv4穿越
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely.
本文档概述了针对企业用户的移动IPv4（MIPv4）和IPsec共存问题的解决方案。该解决方案包括在公司远程访问场景中使用移动IPv4和IPsec进行会话移动的适用性声明，以及安全检测受信任内部网络所需的机制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5
1.5. Requirement Levels . . . . . . . . . . . . . . . . . . . . 6
1.6. Assumptions and Rationale . . . . . . . . . . . . . . . . 7
1.7. Why IPsec Lacks Mobility . . . . . . . . . . . . . . . . . 8
2. The Network Environment . . . . . . . . . . . . . . . . . . . 9
2.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . . . 12
2.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . . . 13
2.3. Access Mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 13
2.4. Access Mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 14
2.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14
3. Internal Network Detection . . . . . . . . . . . . . . . . . . 15
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Implementation Requirements . . . . . . . . . . . . . . . 16
3.2.1. Separate Tracking of Network Interfaces . . . . . . . 16
3.2.2. Connection Status Change . . . . . . . . . . . . . . . 16
3.2.3. Registration-Based Internal Network Detection . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5
1.5. Requirement Levels . . . . . . . . . . . . . . . . . . . . 6
1.6. Assumptions and Rationale . . . . . . . . . . . . . . . . 7
1.7. Why IPsec Lacks Mobility . . . . . . . . . . . . . . . . . 8
2. The Network Environment . . . . . . . . . . . . . . . . . . . 9
2.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . . . 12
2.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . . . 13
2.3. Access Mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 13
2.4. Access Mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 14
2.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14
3. Internal Network Detection . . . . . . . . . . . . . . . . . . 15
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Implementation Requirements . . . . . . . . . . . . . . . 16
3.2.1. Separate Tracking of Network Interfaces . . . . . . . 16
3.2.2. Connection Status Change . . . . . . . . . . . . . . . 16
3.2.3. Registration-Based Internal Network Detection . . . . 17
3.2.4. Registration-Based Internal Network Monitoring . . . . 17
3.3. Proposed Algorithm . . . . . . . . . . . . . . . . . . . . 19
3.4. Trusted Networks Configured (TNC) Extension . . . . . . . 20
3.5. Implementation Issues . . . . . . . . . . . . . . . . . . 20
3.6. Rationale for Design Choices . . . . . . . . . . . . . . . 21
3.6.1. Firewall Configuration Requirements . . . . . . . . . 21
3.6.2. Registration-Based Internal Network Monitoring . . . . 22
3.6.3. No Encryption When Inside . . . . . . . . . . . . . . 22
3.7. Improvements . . . . . . . . . . . . . . . . . . . . . . . 22
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Mobile Node Requirements . . . . . . . . . . . . . . . . . 23
4.2. VPN Device Requirements . . . . . . . . . . . . . . . . . 23
4.3. Home Agent Requirements . . . . . . . . . . . . . . . . . 24
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Comparison against Guidelines . . . . . . . . . . . . . . 24
5.2. Packet Overhead . . . . . . . . . . . . . . . . . . . . . 26
5.3. Latency Considerations . . . . . . . . . . . . . . . . . . 27
5.4. Firewall State Considerations . . . . . . . . . . . . . . 27
5.5. Intrusion Detection Systems (IDSs) . . . . . . . . . . . . 28
5.6. Implementation of the Mobile Node . . . . . . . . . . . . 28
5.7. Non-IPsec VPN Protocols . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Internal Network Detection . . . . . . . . . . . . . . . . 29
6.2. Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Packet Flow Examples . . . . . . . . . . . . . . . . 34
A.1. Connection Setup for Access Mode 'cvc' . . . . . . . . . . 34
3.2.4. Registration-Based Internal Network Monitoring . . . . 17
3.3. Proposed Algorithm . . . . . . . . . . . . . . . . . . . . 19
3.4. Trusted Networks Configured (TNC) Extension . . . . . . . 20
3.5. Implementation Issues . . . . . . . . . . . . . . . . . . 20
3.6. Rationale for Design Choices . . . . . . . . . . . . . . . 21
3.6.1. Firewall Configuration Requirements . . . . . . . . . 21
3.6.2. Registration-Based Internal Network Monitoring . . . . 22
3.6.3. No Encryption When Inside . . . . . . . . . . . . . . 22
3.7. Improvements . . . . . . . . . . . . . . . . . . . . . . . 22
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Mobile Node Requirements . . . . . . . . . . . . . . . . . 23
4.2. VPN Device Requirements . . . . . . . . . . . . . . . . . 23
4.3. Home Agent Requirements . . . . . . . . . . . . . . . . . 24
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Comparison against Guidelines . . . . . . . . . . . . . . 24
5.2. Packet Overhead . . . . . . . . . . . . . . . . . . . . . 26
5.3. Latency Considerations . . . . . . . . . . . . . . . . . . 27
5.4. Firewall State Considerations . . . . . . . . . . . . . . 27
5.5. Intrusion Detection Systems (IDSs) . . . . . . . . . . . . 28
5.6. Implementation of the Mobile Node . . . . . . . . . . . . 28
5.7. Non-IPsec VPN Protocols . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Internal Network Detection . . . . . . . . . . . . . . . . 29
6.2. Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Packet Flow Examples . . . . . . . . . . . . . . . . 34
A.1. Connection Setup for Access Mode 'cvc' . . . . . . . . . . 34
The Mobile IP working group set out to explore the problem and solution spaces of IPsec and Mobile IP coexistence. The problem statement and solution requirements for Mobile IPv4 case were first documented in [RFC4093]. This document outlines a solution for IPv4.
移动IP工作组着手探索IPsec和移动IP共存的问题和解决方案空间。移动IPv4案例的问题陈述和解决方案要求首先记录在[RFC4093]中。本文档概述了IPv4的解决方案。
The document contains two parts:
该文件包括两部分：
o a basic solution that is an applicability statement of Mobile IPv4 and IPsec to provide session mobility between enterprise intranets and external networks, intended for enterprise mobile users; and
o 一种基本解决方案，是移动IPv4和IPsec的适用性声明，旨在为企业移动用户提供企业内部网和外部网络之间的会话移动；和
o a technical specification and a set of requirements for secure detection of the internal and the external networks, including a new extension that must be implemented by a mobile node and a home agent situated inside the enterprise network.
o 安全检测内部和外部网络的技术规范和一组要求，包括必须由位于企业网络内的移动节点和归属代理实施的新扩展。
There are many useful ways to combine Mobile IPv4 and IPsec. The solution specified in this document is most applicable when the assumptions documented in the problem statement [RFC4093] are valid; among others that the solution:
将移动IPv4和IPsec结合起来有很多有用的方法。当问题陈述[RFC4093]中记录的假设有效时，本文件中规定的解决方案最适用；除其他外，该解决方案：
o must minimize changes to existing firewall/VPN/DMZ (DeMilitarized Zone) deployments;
o 必须尽量减少对现有防火墙/VPN/DMZ（非军事区）部署的更改；
o must ensure that traffic is not routed through the DMZ when the mobile node is inside (to avoid scalability and management issues);
o 必须确保当移动节点在内部时，流量不会通过DMZ路由（以避免可伸缩性和管理问题）；
o must support foreign networks with only foreign agent access;
o 必须支持只有外部代理访问的外部网络；
o should not require changes to existing IPsec or key exchange protocols;
o 不应要求更改现有IPsec或密钥交换协议；
o must comply with the Mobile IPv4 protocol (but may require new extensions or multiple instances of Mobile IPv4); and
o 必须遵守移动IPv4协议（但可能需要新的扩展或移动IPv4的多个实例）；和
o must propose a mechanism to avoid or minimize IPsec re-negotiation when the mobile node moves.
o 必须提出一种机制，以避免或最小化移动节点移动时的IPsec重新协商。
Typical corporate networks consist of three different domains: the Internet (untrusted external network), the intranet (trusted internal network), and the DMZ, which connects the two networks. Access to the internal network is guarded both by a firewall and a VPN device;
典型的公司网络由三个不同的域组成：Internet（不受信任的外部网络）、intranet（受信任的内部网络）和连接两个网络的DMZ。通过防火墙和VPN设备保护对内部网络的访问；
access is only allowed if both firewall and VPN security policies are respected.
只有在遵守防火墙和VPN安全策略的情况下才允许访问。
Enterprise mobile users benefit from unrestricted seamless session mobility between subnets, regardless of whether the subnets are part of the internal or the external network. Unfortunately, the current Mobile IPv4 and IPsec standards alone do not provide such a service [tessier].
企业移动用户受益于子网之间不受限制的无缝会话移动，无论子网是内部网络还是外部网络的一部分。不幸的是，目前的移动IPv4和IPsec标准本身并没有提供这样的服务[tessier]。
The solution is to use standard Mobile IPv4 (except for a new extension used by the home agent in the internal network to aid in network detection) when the mobile node is in the internal network, and to use the VPN tunnel endpoint address for the Mobile IPv4 registration when outside. IPsec-based VPN tunnels require re-negotiation after movement. To overcome this limitation, another layer of Mobile IPv4 is used underneath IPsec, in effect making IPsec unaware of movement. Thus, the mobile node can freely move in the external network without disrupting the VPN connection.
解决方案是，当移动节点位于内部网络中时，使用标准移动IPv4（内部网络中的归属代理用于帮助网络检测的新扩展除外），并在外部使用VPN隧道端点地址进行移动IPv4注册。基于IPsec的VPN隧道在移动后需要重新协商。为了克服这个限制，在IPsec下面使用了另一层移动IPv4，实际上使IPsec不知道移动。因此，移动节点可以在不中断VPN连接的情况下在外部网络中自由移动。
Briefly, when outside, the mobile node:
简而言之，当移动节点在外部时：
o detects that it is outside (Section 3);
o 检测到它在外面（第3节）；
o registers its co-located or foreign agent care-of address with the external home agent;
o 向外部国内代理登记其共同居住地或外国代理托管地址；
o establishes a VPN tunnel using, e.g., Internet Key Exchange Protocol (IKE) (or IKEv2) if security associations are not already available;
o 如果安全关联不可用，则使用互联网密钥交换协议（IKE）（或IKEv2）建立VPN隧道；
o registers the VPN tunnel address as its co-located care-of address with the internal home agent; this registration request is sent inside the IPsec tunnel.
o 将VPN隧道地址注册为其与内部归属代理的同处转交地址；此注册请求在IPsec隧道内发送。
The solution requires control over the protocol layers in the mobile node. It must be capable of (1) detecting whether it is inside or outside in a secure fashion, and (2) controlling the protocol layers accordingly. For instance, if the mobile node is inside, the IPsec layer needs to become dormant.
该解决方案需要控制移动节点中的协议层。它必须能够（1）以安全的方式检测它是在内部还是在外部，以及（2）相应地控制协议层。例如，如果移动节点在内部，则IPsec层需要处于休眠状态。
Except for the new Mobile IPv4 extension to improve security of internal network detection, current Mobile IPv4 and IPsec standards, when used in a suitable combination, are sufficient to implement the solution. No changes are required to existing VPN devices or foreign agents.
除了新的移动IPv4扩展以提高内部网络检测的安全性外，当前的移动IPv4和IPsec标准如果结合使用，就足以实现该解决方案。无需更改现有VPN设备或外部代理。
The solution described is compatible with different kinds of IPsec-based VPNs, and no particular kind of VPN is required. Because the
所描述的解决方案与不同类型的基于IPsec的VPN兼容，并且不需要特定类型的VPN。因为
appropriate Security Policy Database (SPD) entries and other IKE and IPsec specifics differ between deployed IPsec-based VPN products, these details are not discussed in the document.
在部署的基于IPsec的VPN产品之间，适当的安全策略数据库（SPD）条目和其他IKE和IPsec细节有所不同，本文档中不讨论这些细节。
This document describes a solution for IPv4 only. The downside of the described approach is that an external home agent is required and that the packet overhead (see Section 5) and overall complexity increase. Optimizations would require significant changes to Mobile IPv4 and/or IPsec, and are out of scope of this document.
本文档介绍了仅适用于IPv4的解决方案。所述方法的缺点是需要外部归属代理，并且分组开销（参见第5节）和总体复杂性增加。优化需要对移动IPv4和/或IPsec进行重大更改，这超出了本文档的范围。
VPN, in this document, refers to an IPsec-based remote access VPN. Other types of VPNs are out of scope.
在本文档中，VPN是指基于IPsec的远程访问VPN。其他类型的VPN超出范围。
Related work has been done on Mobile IPv6 in [RFC3776], which discusses the interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6 signaling. The document also discusses dynamic updating of the IPsec endpoint based on Mobile IP signaling packets.
[RFC3776]中对移动IPv6做了相关工作，讨论了IPsec和移动IPv6在保护移动IPv6信令方面的交互作用。本文档还讨论了基于移动IP信令包的IPsec端点的动态更新。
The "transient pseudo-NAT" attack, described in [pseudonat] and [mipnat], affects any approach that attempts to provide security of mobility signaling in conjunction with NAT devices. In many cases, one cannot assume any cooperation from NAT devices, which thus have to be treated as any other networking entity.
[pseudonat]和[mipnat]中描述的“瞬态伪NAT”攻击会影响试图结合NAT设备提供移动信令安全性的任何方法。在许多情况下，不能假设NAT设备进行任何合作，因此必须将NAT设备视为任何其他网络实体。
The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec. This would allow the external Mobile IPv4 layer described in this specification to be removed. However, deploying MOBIKE requires changes to VPN devices, and is thus out of scope of this specification.
IKEv2移动性和多归属协议（MOBIKE）[RFC4555]为IPsec提供了更好的移动性。这将允许删除本规范中描述的外部移动IPv4层。然而，部署MOBIKE需要更改VPN设备，因此超出了本规范的范围。
co-CoA: co-located care-of address.
共同CoA：共同托管地址。
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：（非军事区）插入公司专用网络和外部公共网络之间作为“中立区”的小型网络，以防止外部用户直接访问公司专用网络。
external network: the untrusted network (i.e., Internet). Note that a private network (e.g., another corporate network) other than the mobile node's internal network is considered an external network.
外部网络：不受信任的网络（即互联网）。注意，除了移动节点的内部网络之外的私有网络（例如，另一个公司网络）被视为外部网络。
FA: mobile IPv4 foreign agent.
FA：移动IPv4外部代理。
FA-CoA: foreign agent care-of address.
FA CoA：外国代理人转交地址。
FW: firewall.
防火墙。
internal network: the trusted network; for instance, a physically secure corporate network where the i-HA is located.
内部网络：可信网络；例如，i-HA所在的物理安全的公司网络。
i-FA: Mobile IPv4 foreign agent residing in the internal network.
i-FA：驻留在内部网络中的移动IPv4外部代理。
i-HA: Mobile IPv4 home agent residing in the internal network; typically has a private address [privaddr].
i-HA：驻留在内部网络中的移动IPv4归属代理；通常具有专用地址[privaddr]。
i-HoA: home address of the mobile node in the internal home agent.
i-HoA：内部归属代理中移动节点的归属地址。
MN: mobile node.
MN：移动节点。
NAI: Network Access Identifier [RFC4282].
NAI：网络访问标识符[RFC4282]。
R: router.
R:路由器。
VPN: Virtual Private Network based on IPsec.
VPN：基于IPsec的虚拟专用网络。
VPN-TIA: VPN tunnel inner address, the address(es) negotiated during IKE phase 2 (quick mode), assigned manually, using IPsec-DHCP [RFC3456], using the "de facto" standard Internet Security Association and Key Management Protocol (ISAKMP) configuration mode, or by some other means. Some VPN clients use their current care-of address as their Tunnel Inner Address (TIA) for architectural reasons.
VPN-TIA:VPN隧道内部地址，在IKE阶段2（快速模式）期间协商的地址，使用IPsec DHCP[RFC3456]，使用“事实”标准Internet安全关联和密钥管理协议（ISAKMP）配置模式，或通过其他方式手动分配。出于架构原因，一些VPN客户端使用其当前的转交地址作为其隧道内部地址（TIA）。
VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode IPsec connection, or Layer 2 Tunneling Protocol (L2TP) combined with IPsec transport connection.
VPN隧道：基于IPsec的隧道；例如，IPsec隧道模式IPsec连接，或结合IPsec传输连接的第2层隧道协议（L2TP）。
x-FA: Mobile IPv4 foreign agent residing in the external network.
x-FA:驻留在外部网络中的移动IPv4外部代理。
x-HA: Mobile IPv4 home agent residing in the external network.
x-HA：驻留在外部网络中的移动IPv4归属代理。
x-HoA: home address of the mobile node in the external home agent.
x-HoA：外部归属代理中移动节点的归属地址。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
The solution is an attempt to solve the problem described in [RFC4093]. The major assumptions and their rationale is summarized below.
该解决方案试图解决[RFC4093]中描述的问题。主要假设及其基本原理总结如下。
Changes to existing firewall and VPN deployments should be minimized:
应尽量减少对现有防火墙和VPN部署的更改：
o The current deployment of firewalls and IPsec-based VPNs is much larger than corresponding Mobile IPv4 elements. Thus, a solution should work within the existing VPN infrastructure.
o 当前部署的防火墙和基于IPsec的VPN要比相应的移动IPv4元素大得多。因此，解决方案应该在现有的VPN基础设施内工作。
o Current enterprise network deployments typically centralize management of security and network access into a compact DMZ.
o 当前的企业网络部署通常将安全和网络访问的管理集中到一个紧凑的DMZ中。
When the mobile node is inside, traffic should not go through the DMZ network:
当移动节点在内部时，流量不应通过DMZ网络：
o Routing all mobile node traffic through the DMZ is seen as a performance problem in existing deployments of firewalls. The more sophisticated firewall technology is used (e.g., content scanning), the more serious the performance problem is.
o 在现有的防火墙部署中，通过DMZ路由所有移动节点流量被视为一个性能问题。使用的防火墙技术越复杂（如内容扫描），性能问题就越严重。
o Current deployments of firewalls and DMZs in general have been optimized for the case where only a small minority of total enterprise traffic goes through the DMZ. Furthermore, users of current VPN remote access solutions do not route their traffic through the DMZ when connected to an internal network.
o 当前防火墙和DMZ的部署通常针对只有一小部分企业流量通过DMZ的情况进行了优化。此外，当前VPN远程访问解决方案的用户在连接到内部网络时不会通过DMZ路由其流量。
A home agent inside the enterprise cannot be reached directly from outside, even if the home agent contains IPsec functionality:
即使主代理包含IPsec功能，也无法从外部直接访问企业内部的主代理：
o Deployment of current combined IPsec/MIPv4 solutions are not common in large installations.
o 部署当前组合的IPsec/MIPv4解决方案在大型安装中并不常见。
o Doing decryption in the home agents "deep inside" the enterprise effectively means having a security perimeter much larger than the typical, compact DMZ used by a majority of enterprises today.
o 在企业“深处”的家庭代理中进行解密有效地意味着拥有比当今大多数企业使用的典型紧凑型DMZ更大的安全周界。
o In order to maintain a security level equal to current firewall/ DMZ deployments, every home agent decapsulating IPsec would need to do the same firewalling as the current DMZ firewalls (content scanning, connection tracking, etc.).
o 为了保持与当前防火墙/DMZ部署相同的安全级别，每个解除IPsec封装的home agent都需要执行与当前DMZ防火墙相同的防火墙（内容扫描、连接跟踪等）。
Traffic cannot be encrypted when the mobile node is inside:
当移动节点位于以下位置时，无法对流量进行加密：
o There is a considerable performance impact on home agents (which currently do rather light processing) and mobile nodes (especially for small devices). Note that traffic throughput inside the enterprise is typically an order (or more) of magnitude larger than the remote access traffic through a VPN.
o 对家庭代理（目前只进行少量处理）和移动节点（尤其是小型设备）的性能有相当大的影响。请注意，企业内部的流量吞吐量通常比通过VPN的远程访问流量大一个数量级（或更多）。
o Encryption consumes processing power and has a significant impact on device battery life.
o 加密会消耗处理能力，并对设备电池寿命产生重大影响。
o There is also a usability issue involved; the user needs to authenticate the connection to the IPsec layer in the home agent to gain access. For interactive authentication mechanisms (e.g., SecurID), this always means user interaction.
o 还涉及到可用性问题；用户需要在home agent中验证到IPsec层的连接才能获得访问权限。对于交互式身份验证机制（例如SecurID），这始终意味着用户交互。
o Furthermore, if there is a separate VPN device in the DMZ for remote access, the user needs to authenticate to both devices, and might need to have separate credentials for both.
o 此外，如果DMZ中有用于远程访问的单独VPN设备，则用户需要对这两个设备进行身份验证，并且可能需要对这两个设备具有单独的凭据。
o Current Mobile IPv4 home agents do not typically incorporate IPsec functionality, which is relevant for the solution when we assume zero or minimal changes to existing Mobile IPv4 nodes.
o 当前的移动IPv4家庭代理通常不包含IPsec功能，当我们假设对现有移动IPv4节点的更改为零或最小时，这与解决方案相关。
o Note, however, that the assumption (no encryption when inside) does not necessarily apply to all solutions in the solution space; if the above mentioned problems were resolved, there is no fundamental reason why encryption could not be applied when inside.
o 但是，请注意，假设（内部不加密）不一定适用于解决方案空间中的所有解决方案；如果上述问题得到解决，就没有根本原因说明在内部无法应用加密。
IPsec, as currently specified [RFC4301], requires that a new IKE negotiation be done whenever an IPsec peer moves, i.e., changes care-of address. The main reason is that a security association is unidirectional and identified by a triplet consisting of (1) the destination address (which is the outer address when tunnel mode is used), (2) the security protocol (Encapsulating Security Payload (ESP) or Authentication Header (AH)), and (3) the Security Parameter Index (SPI) ([RFC4301], Section 4.1). Although an implementation is not required to use all of these for its own Security Associations (SAs), an implementation cannot assume that a peer does not.
按照当前的规定[RFC4301]，IPsec要求每当IPsec对等方移动时，即更改转交地址时，都要进行新的IKE协商。主要原因是安全关联是单向的，由三元组标识，三元组包括（1）目标地址（使用隧道模式时为外部地址），（2）安全协议（封装安全有效负载（ESP）或身份验证头（AH）），以及（3）安全参数索引（SPI）（[RFC4301]，第4.1节）。尽管实现不需要将所有这些用于其自身的安全关联（SA），但实现不能假定对等方不需要。
When a mobile IPsec peer sends packets to a stationary IPsec peer, there is no problem; the SA is "owned" by the stationary IPsec peer, and therefore the destination address does not need to change. The (outer) source address should be ignored by the stationary peer (although some implementations do check the source address as well).
当移动IPsec对等方向固定IPsec对等方发送数据包时，没有问题；SA由固定的IPsec对等方“拥有”，因此不需要更改目标地址。固定对等方应该忽略（外部）源地址（尽管有些实现也会检查源地址）。
The problem arises when packets are sent from the stationary peer to the mobile peer. The destination address of this SA (SAs are unidirectional) is established during IKE negotiation, and is effectively the care-of address of the mobile peer at time of negotiation. Therefore, the packets will be sent to the original care-of address, not a changed care-of address.
当数据包从固定对等点发送到移动对等点时，问题就出现了。此SA的目标地址（SA是单向的）是在IKE协商期间建立的，并且是协商时移动对等方的有效照管地址。因此，数据包将被发送到原始转交地址，而不是更改的转交地址。
The IPsec NAT traversal mechanism can also be used for limited mobility, but UDP tunneling needs to be used even when there is no NAT in the route between the mobile and the stationary peers. Furthermore, support for changes in current NAT mapping is not required by the NAT traversal specification [RFC3947].
IPsec NAT穿越机制也可用于有限的移动性，但即使在移动和固定对等点之间的路由中没有NAT，也需要使用UDP隧道。此外，NAT遍历规范[RFC3947]不要求对当前NAT映射的更改提供支持。
In summary, although the IPsec standard does not as such prevent mobility (in the sense of updating security associations on-the-fly), the standard does not include a built-in mechanism (explicit or implicit) for doing so. Therefore, it is assumed throughout this document that any change in the addresses comprising the identity of an SA requires IKE re-negotiation, which implies too heavy computation and too large latency for useful mobility.
总之，尽管IPsec标准本身并不阻止移动性（在动态更新安全关联的意义上），但该标准不包括用于这样做的内置机制（显式或隐式）。因此，在本文档中，假设组成SA的身份的地址中的任何更改都需要IKE重新协商，这意味着对于有用的移动性来说计算太重和延迟太大。
The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec. This would allow the external Mobile IPv4 layer described in this specification to be removed. However, deploying MOBIKE requires changes to VPN devices, and is thus out of scope of this specification.
IKEv2移动性和多归属协议（MOBIKE）[RFC4555]为IPsec提供了更好的移动性。这将允许删除本规范中描述的外部移动IPv4层。然而，部署MOBIKE需要更改VPN设备，因此超出了本规范的范围。
Enterprise users will access both the internal and external networks using different networking technologies. In some networks, the MN will use FAs and in others it will anchor at the HA using co-located mode. The following figure describes an example network topology illustrating the relationship between the internal and external networks, and the possible locations of the mobile node (i.e., (MN)).
企业用户将使用不同的网络技术访问内部和外部网络。在某些网络中，MN将使用FAs，而在其他网络中，MN将使用共址模式锚定在HA。下图描述说明内部和外部网络之间的关系以及移动节点（即，（MN））的可能位置的示例网络拓扑。
(MN) {fvc} {home} (MN) [i-HA]
! \ /
.--+---. .-+---+-.
( ) ( )
`--+---' [VPN] `--+----'
\ ! !
[R/FA] [x-HA] .--+--. [R]
\ / ( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {cvc} (MN) {c} (MN) {f}
(MN) {fvc} {home} (MN) [i-HA]
! \ /
.--+---. .-+---+-.
( ) ( )
`--+---' [VPN] `--+----'
\ ! !
[R/FA] [x-HA] .--+--. [R]
\ / ( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {cvc} (MN) {c} (MN) {f}
Figure 1: Basic topology, possible MN locations, and access modes
图1：基本拓扑、可能的MN位置和访问模式
In every possible location described in the figure, the mobile node can establish a connection to the corresponding HA(s) by using a suitable "access mode". An access mode is here defined to consist of:
在图中描述的每个可能位置中，移动节点可以通过使用合适的“接入模式”建立到相应HA的连接。此处定义的访问模式包括：
1. a composition of the mobile node networking stack (i-MIP or x-MIP/VPN/i-MIP); and
1. 移动节点网络堆栈的组成（i-MIP或x-MIP/VPN/i-MIP）；和
2. registration mode(s) of i-MIP and x-MIP (if used); i.e., co-located care-of address or foreign agent care-of address.
2. i-MIP和x-MIP的注册模式（如果使用）；i、 e.同一地点转交地址或外国代理人转交地址。
Each possible access mode is encoded as "xyz", where:
每个可能的访问模式编码为“xyz”，其中：
o "x" indicates whether the x-MIP layer is used, and if used, the mode ("f" indicates FA-CoA, "c" indicates co-CoA, absence indicates not used);
o “x”表示是否使用x-MIP层，如果使用，则表示模式（“f”表示FA CoA，“c”表示co CoA，不存在表示未使用）；
o "y" indicates whether the VPN layer is used ("v" indicates VPN used, absence indicates not used); and
o “y”表示是否使用VPN层（“v”表示已使用VPN，不存在表示未使用）；和
o "z" indicates mode of i-MIP layer ("f" indicates FA-CoA, "c" indicates co-CoA).
o “z”表示i-MIP层的模式（“f”表示FA CoA，“c”表示co CoA）。
This results in four access modes:
这将导致四种访问模式：
c: i-MIP with co-CoA f: i-MIP with FA-CoA cvc: x-MIP with co-CoA, VPN-TIA as i-MIP co-CoA fvc: x-MIP with FA-CoA, VPN-TIA as i-MIP co-CoA
c:i-MIP伴辅辅酶A f:i-MIP伴辅辅酶A cvc:x-MIP伴辅辅酶A，VPN-TIA伴辅辅酶A fvc:x-MIP伴辅辅酶A，VPN-TIA伴辅辅酶A
This notation is more useful when optimizations to protocol layers are considered. The notation is preserved here so that work on the optimizations can refer to a common notation.
当考虑到协议层的优化时，这种表示法更有用。这里保留了表示法，以便优化工作可以引用通用表示法。
The internal network is typically a multi-subnetted network using private addressing [privaddr]. Subnets may contain internal home agent(s), DHCP server(s), and/or foreign agent(s). Current IEEE 802.11 wireless LANs are typically deployed in the external network or the DMZ because of security concerns.
内部网络通常是使用专用寻址[privaddr]的多个子网网络。子网可能包含内部归属代理、DHCP服务器和/或外部代理。出于安全考虑，当前的IEEE 802.11无线局域网通常部署在外部网络或DMZ中。
The figure leaves out a few details worth noticing:
该图遗漏了一些值得注意的细节：
o There may be multiple NAT devices anywhere in the diagram.
o 图中的任何位置都可能有多个NAT设备。
* When the MN is outside, the NAT devices may be placed between the MN and the x-HA or the x-HA and the VPN.
* 当MN在外部时，NAT设备可以放置在MN和x-HA或x-HA和VPN之间。
* There may also be NAT(s) between the VPN and the i-HA, or a NAT integrated into the VPN. In essence, any router in the figure may be considered to represent zero or more routers, each possibly performing NAT and/or ingress filtering.
* VPN和i-HA之间也可能存在NAT，或者集成到VPN中的NAT。本质上，图中的任何路由器可被视为代表零个或多个路由器，每个路由器可能执行NAT和/或入口过滤。
* When the MN is inside, there may be NAT devices between the MN and the i-HA.
* 当MN在内部时，MN和i-HA之间可能存在NAT设备。
o Site-to-site VPN tunnels are not shown. Although mostly transparent, IPsec endpoints may perform ingress filtering as part of enforcing their policy.
o 未显示站点到站点VPN隧道。尽管IPsec端点基本上是透明的，但作为实施其策略的一部分，它们可以执行入口过滤。
o The figure represents a topology where each functional entity is illustrated as a separate device. However, it is possible that several network functions are co-located in a single device. In fact, all three server components (x-HA, VPN, and i-HA) may be co-located in a single physical device.
o 该图表示一种拓扑结构，其中每个功能实体都作为一个单独的设备进行了说明。然而，多个网络功能可能位于单个设备中。事实上，所有三个服务器组件（x-HA、VPN和i-HA）都可能位于同一个物理设备中。
The following issues are also important when considering enterprise mobile users:
在考虑企业移动用户时，以下问题也很重要：
o Some firewalls are configured to block ICMP messages and/or fragments. Such firewalls (routers) cannot be detected reliably.
o 某些防火墙配置为阻止ICMP消息和/或片段。此类防火墙（路由器）无法可靠检测。
o Some networks contain transparent application proxies, especially for HTTP. Like firewalls, such proxies cannot be detected reliably in general. IPsec and Mobile IPv4 are incompatible with such networks.
o 有些网络包含透明的应用程序代理，尤其是HTTP。与防火墙一样，通常无法可靠地检测到此类代理。IPsec和移动IPv4与此类网络不兼容。
Whenever a mobile node obtains either a co-CoA or an FA-CoA, the following conceptual steps take place:
每当移动节点获得co-CoA或FA-CoA时，就会发生以下概念性步骤：
o The mobile node detects whether the subnet where the care-of address was obtained belongs to the internal or the external network using the method described in Section 3 (or a vendor-specific mechanism fulfilling the requirements described).
o 移动节点使用第3节中描述的方法（或满足所述要求的特定于供应商的机制）检测获得转交地址的子网是属于内部网络还是外部网络。
o The mobile node performs necessary registrations and other connection setup signaling for the protocol layers (in the following order):
o 移动节点为协议层执行必要的注册和其他连接设置信令（按以下顺序）：
* x-MIP (if used);
* x-MIP（如果使用）；
* VPN (if used); and
* VPN（如果使用）；和
* i-MIP.
* i-MIP。
Note that these two tasks are intertwined to some extent: detection of the internal network results in a successful registration to the i-HA using the proposed network detection algorithm. An improved network detection mechanism not based on Mobile IPv4 registration messages might not have this side effect.
请注意，这两个任务在某种程度上是相互交织的：使用所提出的网络检测算法，检测内部网络将导致成功注册到i-HA。不基于移动IPv4注册消息的改进网络检测机制可能不会产生这种副作用。
The following subsections describe the different access modes and the requirements for registration and connection setup phase.
以下小节描述了不同的访问模式以及注册和连接设置阶段的要求。
This access mode is standard Mobile IPv4 [RFC3344] with a co-located address, except that:
此访问模式为标准移动IPv4[RFC3344]，具有同一地址，但以下情况除外：
o the mobile node MUST detect that it is in the internal network; and
o 移动节点必须检测到它在内部网络中；和
o the mobile node MUST re-register periodically (with a configurable interval) to ensure it is still inside the internal network (see Section 4).
o 移动节点必须定期（以可配置的间隔）重新注册，以确保其仍在内部网络中（参见第4节）。
This access mode is standard Mobile IPv4 [RFC3344] with a foreign agent care-of address, except that
此访问模式为标准移动IPv4[RFC3344]，具有外部代理转交地址，但以下情况除外：
o the mobile node MUST detect that it is in the internal network; and
o 移动节点必须检测到它在内部网络中；和
o the mobile node MUST re-register periodically (with a configurable interval) to ensure it is still inside the internal network (see Section 4).
o 移动节点必须定期（以可配置的间隔）重新注册，以确保其仍在内部网络中（参见第4节）。
Steps:
步骤：
o The mobile node obtains a care-of address.
o 移动节点获得转交地址。
o The mobile node detects it is not inside and registers with the x-HA, where
o 移动节点检测到它不在内部，并向x-HA注册，其中
* T-bit MAY be set (reverse tunneling), which minimizes the probability of firewall-related connectivity problems
* 可以设置T位（反向隧道），从而将防火墙相关连接问题的可能性降至最低
o If the mobile node does not have an existing IPsec security association, it uses IKE to set up an IPsec security association with the VPN gateway, using the x-HoA as the IP address for IKE/ IPsec communication. How the VPN-TIA is assigned is outside the scope of this document.
o 如果移动节点没有现有的IPsec安全关联，它将使用IKE与VPN网关建立IPsec安全关联，并使用x-HoA作为IKE/IPsec通信的IP地址。如何分配VPN-TIA不在本文件范围内。
o The mobile node sends a MIPv4 Registration Request (RRQ) to the i-HA, registering the VPN-TIA as a co-located care-of address, where
o 移动节点向i-HA发送MIPv4注册请求（RRQ），将VPN-TIA注册为同一位置的转交地址，其中
* T-bit SHOULD be set (reverse tunneling) (see discussion below)
* 应设置T位（反向隧道）（见下文讨论）
Reverse tunneling in the inner Mobile IPv4 layer is often required because of IPsec security policy limitations. IPsec selectors define allowed IP addresses for packets sent inside the IPsec tunnel. Typical IPsec remote VPN selectors restrict the client address to be VPN-TIA (remote address is often unrestricted). If reverse tunneling is not used, the source address of a packet sent by the MN will be the MN's home address (registered with i-HA), which is different from the VPN-TIA, thus violating IPsec security policy. Consequently, the packet will be dropped, resulting in a connection black hole.
由于IPsec安全策略的限制，通常需要在内部移动IPv4层中进行反向隧道。IPsec选择器为在IPsec隧道内发送的数据包定义允许的IP地址。典型的IPsec远程VPN选择器将客户端地址限制为VPN-TIA（远程地址通常不受限制）。如果不使用反向隧道，MN发送的数据包的源地址将是MN的家庭地址（在i-HA注册），这与VPN-TIA不同，因此违反了IPsec安全策略。因此，数据包将被丢弃，导致连接黑洞。
Some types of IPsec-based VPNs, in particular L2TP/IPsec VPNs (PPP-over-L2TP-over-IPsec), do not have this limitation and can use triangular routing.
某些类型的基于IPsec的VPN，特别是L2TP/IPsec VPN（PPP-over-L2TP-over-IPsec），没有此限制，可以使用三角路由。
Note that although the MN can use triangular routing, i.e., skip the inner MIPv4 layer, it MUST NOT skip the VPN layer for security reasons.
注意，尽管MN可以使用三角形路由，即跳过内部MIPv4层，但出于安全原因，它不能跳过VPN层。
Steps:
步骤：
o The mobile node obtains a foreign agent advertisement from the local network.
o 移动节点从本地网络获取外部代理广告。
o The mobile node detects it is outside and registers with the x-HA, where
o 移动节点检测到它在外部，并向x-HA注册，其中
* T-bit MAY be set (reverse tunneling), which minimizes the probability of firewall-related connectivity problems
* 可以设置T位（反向隧道），从而将防火墙相关连接问题的可能性降至最低
o If necessary, the mobile node uses IKE to set up an IPsec connection with the VPN gateway, using the x-HoA as the IP address for IKE/IPsec communication. How the VPN-TIA is assigned is outside the scope of this document.
o 如有必要，移动节点使用IKE与VPN网关建立IPsec连接，使用x-HoA作为IKE/IPsec通信的IP地址。如何分配VPN-TIA不在本文件范围内。
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the VPN-TIA as a co-located care-of address, where
o 移动节点向i-HA发送MIPv4 RRQ，将VPN-TIA注册为同一位置的转交地址，其中
* T-bit SHOULD be set (reverse tunneling) (see discussion in Section 2.3)
* 应设置T型钻头（反向隧道）（见第2.3节的讨论）
Note that although the MN can use triangular routing, i.e., skip the inner MIPv4 layer, it MUST NOT skip the VPN layer for security reasons.
注意，尽管MN可以使用三角形路由，即跳过内部MIPv4层，但出于安全原因，它不能跳过VPN层。
NAT devices may affect each layer independently. Mobile IPv4 NAT traversal [mipnat] SHOULD be supported for x-MIP and i-MIP layers, while IPsec NAT traversal [RFC3947][RFC3948] SHOULD be supported for the VPN layer.
NAT设备可以独立地影响每一层。x-MIP和i-MIP层应支持移动IPv4 NAT穿越[mipnat]，而VPN层应支持IPsec NAT穿越[RFC3947][RFC3948]。
Note that NAT traversal for the internal MIPv4 layer may be necessary even when there is no separate NAT device between the VPN gateway and the internal network. Some VPN implementations NAT VPN tunnel inner addresses before routing traffic to the intranet. Sometimes this is done to make a deployment easier, but in some cases this approach
请注意，即使VPN网关和内部网络之间没有单独的NAT设备，也可能需要对内部MIPv4层进行NAT遍历。一些VPN实现在将流量路由到intranet之前先通过NAT VPN隧道内部地址。有时这样做是为了使部署更容易，但在某些情况下，这种方法
makes VPN client implementation easier. Mobile IPv4 NAT traversal is required to establish a MIPv4 session in this case.
使VPN客户端实现更容易。在这种情况下，需要移动IPv4 NAT遍历来建立MIPv4会话。
Secure detection of the internal network is critical to prevent plaintext traffic from being sent over an untrusted network. In other words, the overall security (confidentiality and integrity of user data) relies on the security of the internal network detection mechanism in addition to IPsec. For this reason, security requirements are described in this section.
内部网络的安全检测对于防止明文通信通过不受信任的网络发送至关重要。换句话说，除了IPsec之外，整体安全性（用户数据的机密性和完整性）还依赖于内部网络检测机制的安全性。因此，本节介绍了安全要求。
In addition to detecting entry into the internal network, the mobile node must also detect when it has left the internal network. Entry into the internal network is easier security-wise: the mobile node can ensure that it is inside the internal network before sending any plaintext traffic. Exit from the internal network is more difficult to detect, and the MN may accidentally leak plaintext packets if the event is not detected in time.
除了检测进入内部网络的情况外，移动节点还必须检测何时离开内部网络。进入内部网络更容易实现安全性：移动节点可以确保在发送任何明文通信之前，它位于内部网络内。从内部网络退出更难检测，如果没有及时检测到事件，MN可能会意外泄漏明文数据包。
Several events can cause the mobile node to leave the internal network, including:
若干事件可导致移动节点离开内部网络，包括：
o a routing change upstream;
o 上游路由改变；
o a reassociation of 802.11 on layer 2 that the mobile node software does not detect;
o 移动节点软件未检测到的第2层802.11的重新关联；
o a physical cable disconnect and reconnect that the mobile node software does not detect.
o 移动节点软件未检测到的物理电缆断开和重新连接。
Whether the mobile node can detect such changes in the current connection reliably depends on the implementation and the networking technology. For instance, some mobile nodes may be implemented as pure layer three entities. Even if the mobile node software has access to layer 2 information, such information is not trustworthy security-wise, and depends on the network interface driver.
移动节点能否可靠地检测当前连接中的这种变化取决于实现和联网技术。例如，一些移动节点可以实现为纯第三层实体。即使移动节点软件可以访问第2层信息，此类信息在安全方面也不可靠，并且取决于网络接口驱动程序。
If the mobile node does not detect these events properly, it may leak plaintext traffic into an untrusted network. A number of approaches can be used to detect exit from the internal network, ranging from frequent re-registration to the use of layer two information.
如果移动节点没有正确检测到这些事件，它可能会将明文通信泄漏到不受信任的网络中。从频繁的重新注册到使用第二层信息，可以使用多种方法来检测内部网络的退出。
A mobile node MUST implement a detection mechanism fulfilling the requirements described in Section 3.2; this ensures that basic security requirements are fulfilled. The basic algorithm described in Section 3.3 is one way to do that, but alternative methods may be used instead or in conjunction. The assumptions that the
移动节点必须实现满足第3.2节所述要求的检测机制；这可确保满足基本的安全要求。第3.3节中描述的基本算法是实现这一点的一种方法，但可以使用替代方法或结合使用。假设
requirements and the proposed mechanism rely upon are described in Section 3.1.
第3.1节描述了要求和提议的机制。
The enterprise firewall MUST be configured to block traffic originating from external networks going to the i-HA. In other words, the mobile node MUST NOT be able to perform a successful Registration Request/Registration Reply (RRQ/RRP) exchange (without using IPsec) unless it is connected to the trusted internal network; the mobile node can then stop using IPsec without compromising data confidentiality.
企业防火墙必须配置为阻止来自外部网络的流量流向i-HA。换句话说，移动节点必须不能执行成功的注册请求/注册回复（RRQ/RRP）交换（不使用IPsec），除非它连接到可信的内部网络；然后，移动节点可以停止使用IPsec而不损害数据机密性。
If this assumption does not hold, data confidentiality is compromised in a potentially silent and thus dangerous manner. To minimize the impact of this scenario, the i-HA is also required to check the source address of any RRQ to determine whether it comes from a trusted (internal network) address. The i-HA needs to indicate to the MN that it supports the checking of trusted source addresses by including a Trusted Networks Configured extension in its registration reply. This new extension, which needs to be implemented by both i-HA and the MN, is described in Section 3.4.
如果这一假设不成立，则数据保密性将以潜在的沉默方式受到损害，从而造成危险。为了尽量减少这种情况的影响，i-HA还需要检查任何RRQ的源地址，以确定它是否来自受信任的（内部网络）地址。i-HA需要通过在其注册回复中包括可信网络配置的扩展来向MN指示它支持对可信源地址的检查。第3.4节描述了需要由i-HA和MN实施的新扩展。
The firewall MAY be configured to block registration traffic to the x-HA originating from within the internal network, which makes the network detection algorithm simpler and more robust. However, as the registration request is basically UDP traffic, an ordinary firewall (even a stateful one) would typically allow the registration request to be sent and a registration reply to be received through the firewall.
防火墙可被配置为阻止来自内部网络内的到x-HA的注册流量，这使得网络检测算法更简单且更健壮。但是，由于注册请求基本上是UDP流量，普通防火墙（即使是有状态防火墙）通常允许通过防火墙发送注册请求和接收注册回复。
Any mechanism used to detect the internal network MUST fulfill the requirements described in this section. An example of a network detection mechanism fulfilling these requirements is given in Section 3.3.
用于检测内部网络的任何机制必须满足本节所述的要求。第3.3节给出了满足这些要求的网络检测机制的示例。
The mobile node implementation MUST track each network interface separately. Successful registration with the i-HA through interface X does not imply anything about the status of interface Y.
移动节点实现必须单独跟踪每个网络接口。通过接口X成功注册i-HA并不意味着接口Y的状态。
When the mobile node detects that its connection status on a certain network interface changes, the mobile node MUST:
当移动节点检测到其在特定网络接口上的连接状态发生变化时，移动节点必须：
o immediately stop relaying user data packets;
o 立即停止中继用户数据包；
o detect whether this interface is connected to the internal or the external network; and
o 检测该接口是否连接到内部网络或外部网络；和
o resume data traffic only after the internal network detection and necessary registrations and VPN tunnel establishment have been completed.
o 只有在内部网络检测、必要的注册和VPN隧道建立完成后，才能恢复数据通信。
The mechanisms used to detect a connection status change depends on the mobile node implementation, the networking technology, and the access mode.
用于检测连接状态变化的机制取决于移动节点实现、联网技术和接入模式。
The mobile node MUST NOT infer that an interface is connected to the internal network unless a successful registration has been completed through that particular interface to the i-HA, the i-HA registration reply contained a Trusted Networks Configured extension (Section 3.4), and the connection status of the interface has not changed since.
移动节点不得推断接口连接到内部网络，除非已通过该特定接口成功注册到i-HA，i-HA注册回复包含可信网络配置的扩展（第3.4节），并且此后接口的连接状态未发生变化。
Some leak of plaintext packets to a (potentially) untrusted network cannot always be completely prevented; this depends heavily on the client implementation. In some cases, the client cannot detect such a change, e.g., if upstream routing is changed.
向（可能）不受信任的网络泄漏明文数据包并非总能完全避免；这在很大程度上取决于客户端实现。在某些情况下，客户端无法检测到这种变化，例如，如果上游路由发生变化。
More frequent re-registrations when the MN is inside is a simple way to ensure that the MN is still inside. The MN SHOULD start re-registration every (T_MONITOR - N) seconds when inside, where N is a grace period that ensures that re-registration is completed before T_MONITOR seconds are up. To bound the maximum amount of time that a plaintext leak may persist, the mobile node must fulfill the following security requirements when inside:
当MN在内部时更频繁地重新注册是确保MN仍在内部的一种简单方法。MN应该在内部每隔（T_MONITOR-N）秒开始重新注册，其中N是一个宽限期，确保在T_MONITOR秒结束之前完成重新注册。为了限制明文泄漏可能持续的最长时间，移动节点在内部时必须满足以下安全要求：
o The mobile node MUST NOT send or receive a user data packet if more than T_MONITOR seconds have elapsed since the last successful (re-)registration with the i-HA.
o 如果自上次成功（重新）向i-HA注册以来已超过T_MONITOR秒，则移动节点不得发送或接收用户数据包。
o If more than T_MONITOR seconds have elapsed, data packets MUST be either dropped or queued. If the packets are queued, the queues MUST NOT be processed until the re-registration has been successfully completed without a connection status change.
o 如果超过T_MONITOR秒，则必须丢弃或排队数据包。如果数据包已排队，则在重新注册成功完成且连接状态未更改之前，不得处理队列。
o The T_MONITOR parameter MUST be configurable, and have the default value of 60 seconds. This default is a trade-off between traffic overhead and a reasonable bound to exposure.
o T_MONITOR参数必须是可配置的，默认值为60秒。该默认值是流量开销和合理的风险敞口边界之间的折衷。
This approach is reasonable for a wide range of mobile nodes (e.g., laptops), but has unnecessary overhead when the mobile node is idle (not sending or receiving packets). If re-registration does not complete before T_MONITOR seconds are up, data packets must be queued or dropped as specified above. Note that re-registration packets MUST be sent even if bidirectional user data traffic is being relayed: data packets are no substitute for an authenticated re-registration.
这种方法对于范围广泛的移动节点（例如，笔记本电脑）是合理的，但是当移动节点空闲时（不发送或接收数据包），这种方法具有不必要的开销。如果在T_MONITOR秒数结束之前未完成重新注册，则必须按照上述规定排队或丢弃数据包。请注意，即使双向用户数据通信正在中继，也必须发送重新注册数据包：数据包不能替代经过身份验证的重新注册。
To minimize traffic overhead when the mobile node is idle, re-registrations can be stopped when no traffic is being sent or received. If the mobile node subsequently receives or needs to send a packet, the packet must be dropped or queued (as specified above) until a re-registration with the i-HA has been successfully completed. Although this approach adds packet processing complexity, it may be appropriate for small, battery-powered devices, which may be idle much of the time. (Note that ordinary re-registration before the mobility binding lifetime is exhausted should still be done to keep the MN reachable.)
为了在移动节点空闲时最小化流量开销，可以在没有发送或接收流量时停止重新注册。如果移动节点随后接收或需要发送分组，则分组必须丢弃或排队（如上所述），直到成功完成与i-HA的重新注册。尽管这种方法增加了数据包处理的复杂性，但它可能适用于电池供电的小型设备，这些设备可能大部分时间处于空闲状态。（请注意，在移动性绑定生存期耗尽之前，仍应进行普通的重新注册，以保持MN的可访问性。）
T_MONITOR is required to be configurable so that an administrator can determine the required security level for the particular deployment. Configuring T_MONITOR in the order of a few seconds is not practical; alternative mechanisms need to be considered if such confidence is required.
T_MONITOR需要可配置，以便管理员可以确定特定部署所需的安全级别。按几秒钟的顺序配置T_监视器是不现实的；如果需要这种信任，则需要考虑其他机制。
The re-registration mechanism is a worst-case fallback mechanism. If additional information (such as layer two triggers) is available to the mobile node, the mobile node SHOULD use the triggers to detect MN movement and restart the detection process to minimize exposure.
重新注册机制是最坏情况下的回退机制。如果附加信息（例如第二层触发器）可用于移动节点，则移动节点应使用触发器检测MN移动，并重新启动检测过程以最小化暴露。
Note that re-registration is required by Mobile IPv4 by default (except for the atypical case of an infinite binding lifetime); however, the re-registration interval may be much larger when using an ordinary Mobile IPv4 client. A shorter re-registration interval is usually not an issue, because the internal network is typically a fast, wired network, and the shortened re-registration interval applies only when the mobile node is inside the internal network. When outside, the ordinary Mobile IPv4 re-registration process (based on binding lifetime) is used.
请注意，默认情况下，移动IPv4需要重新注册（无限绑定生存期的非典型情况除外）；然而，当使用普通移动IPv4客户端时，重新注册间隔可能要大得多。较短的重新注册间隔通常不是问题，因为内部网络通常是快速有线网络，并且缩短的重新注册间隔仅在移动节点位于内部网络内时适用。在外部时，使用普通的移动IPv4重新注册过程（基于绑定生存期）。
When the MN detects that it has changed its point of network attachment on a certain interface, it issues two simultaneous registration requests, one to the i-HA and another to the x-HA. These registration requests are periodically retransmitted if reply messages are not received.
当MN检测到它已经改变了其在某个接口上的网络连接点时，它同时发出两个注册请求，一个向i-HA，另一个向x-HA。如果没有收到回复消息，这些注册请求将定期重新传输。
Registration replies are processed as follows:
注册回复的处理方式如下：
o If a response from the x-HA is received, the MN stops retransmitting its registration request to the x-HA and tentatively determines it is outside. However, the MN MUST keep on retransmitting its registration to the i-HA for a period of time. The MN MAY postpone the IPsec connection setup for some period of time while it waits for a (possible) response from the i-HA.
o 如果接收到来自x-HA的响应，MN将停止向x-HA重新传输其注册请求，并暂时确定其在外部。然而，MN必须在一段时间内继续向i-HA重新传输其注册。MN可以将IPsec连接设置延迟一段时间，同时等待来自i-HA的（可能的）响应。
o If a response from the i-HA is received and the response contains the Trusted Networks Configured extension (Section 3.4), the MN SHOULD determine that it is inside. In any case, the MN MUST stop retransmitting its registration requests to both i-HA and x-HA.
o 如果接收到来自i-HA的响应，并且该响应包含可信网络配置的扩展（第3.4节），MN应确定它在内部。在任何情况下，MN必须停止将其注册请求重新传输到i-HA和x-HA。
o When successfully registered with the i-HA directly, MN SHOULD de-register with the x-HA.
o 当直接向i-HA成功注册时，MN应该向x-HA注销。
If the MN ends up detecting that it is inside, it MUST re-register periodically (regardless of binding lifetime); see Section 3.2.4. If the re-registration fails, the MN MUST stop sending and receiving plaintext traffic, and MUST restart the detection algorithm.
如果MN最终检测到它在内部，它必须周期性地重新注册（无论绑定寿命如何）；见第3.2.4节。如果重新注册失败，MN必须停止发送和接收明文通信量，并且必须重新启动检测算法。
Plaintext re-registration messages are always addressed either to the x-HA or the i-HA, not to both. This is because the MN knows, after initial registration, whether it is inside or outside. (However, when the mobile node is outside, it re-registers independently with the x-HA using plaintext, and with the i-HA through the VPN tunnel.)
明文重新注册消息总是发往x-HA或i-HA，而不是发往两者。这是因为MN在初始注册后知道它是在内部还是外部。（但是，当移动节点在外部时，它使用明文独立地向x-HA重新注册，并通过VPN隧道向i-HA重新注册。）
Postponing the IPsec connection setup could prevent aborted IKE sessions. Aborting IKE sessions may be a problem in some cases because IKE does not provide a reliable, standardized, and mandatory-to-implement mechanism for terminating a session cleanly.
推迟IPsec连接设置可能会阻止中止的IKE会话。在某些情况下，中止IKE会话可能是一个问题，因为IKE没有提供可靠、标准化和强制性的机制来实现干净地终止会话。
If the x-HA is not reachable from inside (i.e., the firewall configuration is known), a detection period of zero is preferred, as it minimizes connection setup overhead and causes no timing problems. Should the assumption have been invalid and a response from the i-HA received after a response from the x-HA, the MN SHOULD re-register with the i-HA directly.
如果无法从内部访问x-HA（即，已知防火墙配置），则首选零检测周期，因为它可以最大限度地减少连接设置开销，并且不会导致计时问题。如果假设无效，并且在收到x-HA的响应后收到i-HA的响应，MN应直接向i-HA重新注册。
This extension is a skippable extension. An i-HA sending the extension must fulfill the requirements described in Section 4.3, while an MN processing the extension must fulfill the requirements described in Section 4.1. The format of the extension is described below. It adheres to the short extension format described in [RFC3344]:
此扩展是可跳过的扩展。发送扩展的i-HA必须满足第4.3节中描述的要求，而处理扩展的MN必须满足第4.1节中描述的要求。扩展的格式如下所述。它遵循[RFC3344]中描述的简短扩展格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 149
149型
Length 2
长度2
Sub-Type 0
子类型0
Reserved Set to 0 when sending, ignored when receiving
发送时保留设置为0，接收时忽略
When the MN uses a parallel detection algorithm and is using an FA, the MN sends two registration requests through the same FA with the same Media Acces Control (MAC) address (or equivalent) and possibly even the same home address. Although this is not in conflict with existing specifications, it is an unusual scenario; hence some FA implementations may not work properly in such a situation. However, testing against deployed foreign agents seems to indicate that a majority of available foreign agents handle this situation.
当MN使用并行检测算法并且正在使用FA时，MN通过具有相同媒体访问控制（MAC）地址（或等效地址）甚至可能具有相同家庭地址的相同FA发送两个注册请求。尽管这与现有规范没有冲突，但这是一种不寻常的情况；因此，某些FA实现在这种情况下可能无法正常工作。然而，针对部署的外国代理进行的测试似乎表明，大多数可用的外国代理处理这种情况。
When the x-HA and i-HA addresses are the same, the scenario is even more difficult for the FA, and it is almost certain that existing FAs do not deal with the situation correctly. Therefore, it is required that x-HA and i-HA addresses MUST be different.
当x-HA和i-HA地址相同时，FA的情况更加困难，几乎可以肯定，现有的FA无法正确处理这种情况。因此，要求x-HA和i-HA地址必须不同。
Regardless, if the MN detects that i-HA and x-HA have the same address, it MUST assume that it is in the external network and bypass network detection to avoid confusing the FA. Because the HA addresses are used at different layers, achieving connectivity is possible without address confusion.
无论如何，如果MN检测到i-HA和x-HA具有相同的地址，则必须假定它位于外部网络中，并绕过网络检测以避免混淆FA。因为HA地址在不同的层上使用，所以在不混淆地址的情况下实现连接是可能的。
The mobile node MAY use the following hints to determine that it is inside, but MUST verify reachability of the i-HA anyway:
移动节点可以使用以下提示来确定它在内部，但无论如何必须验证i-HA的可达性：
o a domain name in a DHCPDISCOVER / DHCPOFFER message
o DHCPDISCOVER/DHCPOFFER消息中的域名
o an NAI in a foreign agent advertisement
o 外国代理商广告中的NAI
o a list of default gateway MAC addresses that are known to reside in the internal network (i.e., configured as such, or have been previously verified to be inside)
o 已知驻留在内部网络中的默认网关MAC地址列表（即，配置为内部网络，或之前已验证为内部网络）
For instance, if the MN has reason to believe it is inside, it MAY postpone sending a registration request to the x-HA for some time. Similarly, if the MN has reason to believe it is outside, it may start IPsec connection setup immediately after receiving a registration reply from the x-HA. However, should the MN receive a registration reply from the i-HA after IPsec connection setup has been started, the MN SHOULD still switch to using the i-HA directly.
例如，如果MN有理由相信它在里面，它可能会将向x-HA发送注册请求推迟一段时间。类似地，如果MN有理由相信它在外部，它可以在收到来自x-HA的注册回复后立即启动IPsec连接设置。但是，如果MN在IPsec连接设置启动后收到i-HA的注册回复，MN仍应切换到直接使用i-HA。
The requirement that the i-HA cannot be reached from the external network is necessary. If not, a successful registration with the i-HA (without IPsec) cannot be used as a secure indication that the mobile node is inside. A possible solution to the obvious security problem would be to define and deploy a secure internal network detection mechanism based on, e.g., signed FA advertisement or signed DHCP messages.
外部网络无法达到i-HA的要求是必要的。否则，向i-HA成功注册（没有IPsec）不能用作移动节点在内部的安全指示。对于明显的安全问题，一个可能的解决方案是定义并部署一个基于签名FA广告或签名DHCP消息的安全内部网络检测机制。
However, unless the mechanism is defined for both FA and DHCP messages and is deployed in every internal network, it has limited applicability. In other words, the mobile node MUST NOT assume it is in the internal network unless it receives a signed FA or DHCP message (regardless of whether or not it can register directly with the i-HA). If it receives an unsigned FA or DHCP message, it MUST use IPsec; otherwise, the mobile node can be easily tricked into using plaintext.
但是，除非为FA和DHCP消息定义了该机制，并将其部署在每个内部网络中，否则该机制的适用性有限。换句话说，除非移动节点接收到签名的FA或DHCP消息（不管它是否可以直接向i-HA注册），否则移动节点不得假定它在内部网络中。如果接收到未签名的FA或DHCP消息，则必须使用IPsec；否则，移动节点很容易被骗使用明文。
Assuming that all FA and DHCP servers in the internal network are upgraded to support such a feature does not seem realistic; it is highly desirable to be able to take advantage of existing DHCP and FA deployments. Similar analysis seems to apply regardless of what kind of additional security mechanism is defined.
假设内部网络中的所有FA和DHCP服务器都已升级以支持此功能，这似乎不现实；非常希望能够利用现有的DHCP和FA部署。无论定义了何种附加安全机制，类似的分析似乎都适用。
Because a firewall configuration error can have catastrophic data security consequences (silent exposure of user data to external attackers), a separate protection mechanism is provided by the i-HA. The i-HA must be configured, by the administrator, with a list of trusted networks. The i-HA advertises that it knows which
由于防火墙配置错误可能会造成灾难性的数据安全后果（用户数据无声地暴露给外部攻击者），i-HA提供了单独的保护机制。i-HA必须由管理员使用可信网络列表进行配置。医管局广告说它知道
registration request source addresses are trusted, using a registration reply extension (Trusted Networks Configured extension, Section 3.4). Without this extension, an MN may not rely on a successful registration to indicate that it is connected to the internal network. This ensures that user data compromise does not occur unless both the firewall and the i-HA are configured incorrectly. Further, occurrences of registration requests from untrusted addresses should be logged by the i-HA, exposing them to administrator review.
注册请求源地址是可信的，使用注册回复扩展（可信网络配置扩展，第3.4节）。如果没有该扩展，MN可能不依赖于成功注册来指示其连接到内部网络。这确保了除非防火墙和i-HA配置不正确，否则不会发生用户数据泄露。此外，i-HA应记录来自不受信任地址的注册请求，并将其公开给管理员审查。
This issue also affects IPsec client security. However, as IPsec specifications take no stand on how and when client IPsec policies are configured or changed (for instance, in response to a change in network connectivity), the issue is out of scope for IPsec. Because this document describes an algorithm and requirements for (secure) internal network detection, the issue is in scope of the document.
此问题还影响IPsec客户端安全。但是，由于IPsec规范不支持如何以及何时配置或更改客户端IPsec策略（例如，响应网络连接的更改），因此该问题超出了IPsec的范围。由于本文档描述了（安全）内部网络检测的算法和要求，因此该问题属于本文档的范围。
The current requirement for internal network monitoring was added as a fallback mechanism.
当前对内部网络监控的要求被添加为一种回退机制。
If encryption was applied also when MN was inside, there would be no security reason to monitor the internal network periodically.
如果在MN在内部时也应用了加密，那么就没有安全理由定期监视内部网络。
The main rationale for why encryption cannot be applied when the MN is inside was given in Section 1.6. In short, the main issues are (1) power consumption; (2) extra CPU load, especially because internal networks are typically switched networks and a lot of data may be routinely transferred; (3) existing HA devices do not typically integrate IPsec functionality; (4) (IPsec) encryption requires user authentication, which may be interactive in some cases (e.g., SecurID) and thus a usability issue; and (5) user may need to have separate credentials for VPN devices in the DMZ and the HA.
第1.6节给出了MN在内部时无法应用加密的主要原理。简而言之，主要问题是（1）功耗；（2） 额外的CPU负载，特别是因为内部网络通常是交换网络，大量数据可能会定期传输；（3） 现有HA设备通常不集成IPsec功能；（4） （IPsec）加密要求用户身份验证，在某些情况下可能是交互式的（例如SecurID），因此存在可用性问题；和（5）用户可能需要拥有DMZ和HA中VPN设备的单独凭据。
The registration process can be improved in many ways. One simple way is to make the x-HA detect whether a registration request came from inside or outside the enterprise network. If it came from inside the enterprise network, the x-HA can simply drop the registration request.
注册过程可以在许多方面得到改进。一种简单的方法是让x-HA检测注册请求是来自企业网络内部还是外部。如果它来自企业网络内部，x-HA可以简单地放弃注册请求。
This approach is feasible without protocol changes in scenarios where a corporation owns both the VPN and the x-HA. The x-HA can simply determine based on the incoming interface identifier (or the router
在公司同时拥有VPN和x-HA的情况下，这种方法在不改变协议的情况下是可行的。x-HA可以简单地根据传入的接口标识符（或路由器）进行确定
that relayed the packet) whether or not the registration request came from inside.
无论注册请求是否来自内部。
In other scenarios, protocol changes may be needed. Such changes are out of scope of this document.
在其他情况下，可能需要更改协议。此类变更超出了本文件的范围。
The mobile node MUST implement an internal network detection algorithm fulfilling the requirements set forth in Section 3.2. A new configurable MN parameter, T_MONITOR, is required. The value of this parameter reflects a balance between security and the amount of signaling overhead, and thus needs to be configurable. In addition, when doing internal network detection, the MN MUST NOT disable IPsec protection unless the registration reply from the i-HA contains a Trusted Networks Configured extension (Section 3.4).
移动节点必须实现满足第3.2节所述要求的内部网络检测算法。需要一个新的可配置MN参数T_MONITOR。此参数的值反映了安全性和信令开销之间的平衡，因此需要进行配置。此外，在执行内部网络检测时，MN不得禁用IPsec保护，除非来自i-HA的注册回复包含可信网络配置的扩展（第3.4节）。
The mobile node MUST support access modes c, f, cvc, fvc (Section 2).
移动节点必须支持接入模式c、f、cvc、fvc（第2节）。
The mobile node SHOULD support Mobile IPv4 NAT traversal [mipnat] for both internal and external Mobile IP.
移动节点应支持内部和外部移动IP的移动IPv4 NAT穿越[mipnat]。
The mobile node SHOULD support IPsec NAT traversal [RFC3947] [RFC3948].
移动节点应支持IPsec NAT遍历[RFC3947][RFC3948]。
When the mobile node has direct access to the i-HA, it SHOULD use only the inner Mobile IPv4 layer to minimize firewall and VPN impact.
当移动节点可以直接访问i-HA时，它应该只使用内部移动IPv4层，以最小化防火墙和VPN的影响。
When the mobile node is outside and using the VPN connection, IPsec policies MUST be configured to encrypt all traffic sent to and from the enterprise network. The particular Security Policy Database (SPD) entries depend on the type and configuration of the particular VPN (e.g., plain IPsec vs. L2TP/IPsec, full tunneling or split tunneling).
当移动节点位于外部并使用VPN连接时，必须将IPsec策略配置为加密发送到企业网络和从企业网络发送的所有流量。特定安全策略数据库（SPD）条目取决于特定VPN的类型和配置（例如，普通IPsec与L2TP/IPsec、完全隧道或分割隧道）。
The VPN security policy MUST allow communication using UDP to the internal home agent(s), with home agent port 434 and any remote port. The security policy SHOULD allow IP-IP to internal home agent(s) in addition to UDP port 434.
VPN安全策略必须允许使用UDP与内部归属代理、归属代理端口434和任何远程端口进行通信。除了UDP端口434外，安全策略还应允许IP-IP连接到内部归属代理。
The VPN device SHOULD implement the IPsec NAT traversal mechanism described in [RFC3947] and [RFC3948].
VPN设备应实现[RFC3947]和[RFC3948]中所述的IPsec NAT遍历机制。
The home agent SHOULD implement the Mobile IPv4 NAT traversal mechanism described in [mipnat]. (This also refers to the i-HA: NAT traversal is required to support VPNs that NAT VPN tunnel addresses or block IP-IP traffic.)
归属代理应实现[mipnat]中描述的移动IPv4 NAT遍历机制。（这也指i-HA：需要NAT遍历来支持NAT VPN隧道地址或阻止IP-IP流量的VPN。）
To protect user data confidentiality against firewall configuration errors, the i-HA:
为了保护用户数据的机密性，防止防火墙配置错误，i-HA：
o MUST be configured with a list of trusted IP subnets (containing only addresses from the internal network), with no subnets being trusted by default.
o 必须使用受信任的IP子网列表（仅包含来自内部网络的地址）配置，默认情况下不信任任何子网。
o MUST reject (drop silently) any registration request coming from a source address that is not inside any of the configured trusted subnets. These dropped registration requests SHOULD be logged.
o 必须拒绝（以静默方式删除）来自不在任何配置的受信任子网内的源地址的任何注册请求。应记录这些丢弃的注册请求。
o MUST include a Trusted Networks Configured extension (Section 3.4) in a registration reply sent in response to a registration request coming from a trusted address.
o 必须在响应来自受信任地址的注册请求而发送的注册回复中包含受信任网络配置的扩展（第3.4节）。
This section provides a comparison against guidelines described in Section 6 of the problem statement [RFC4093] and additional analysis of packet overhead with and without the optional mechanisms.
本节将与问题陈述[RFC4093]第6节中描述的指南进行比较，并对有无可选机制的数据包开销进行额外分析。
Preservation of existing VPN infrastructure
保留现有VPN基础设施
o The solution does not mandate any changes to existing VPN infrastructure, other than possibly changes in configuration to avoid stateful filtering of traffic.
o 该解决方案不要求对现有VPN基础设施进行任何更改，除了可能更改配置以避免对流量进行有状态过滤。
Software upgrades to existing VPN clients and gateways
对现有VPN客户端和网关的软件升级
o The solution described does not require any changes to VPN gateways or Mobile IPv4 foreign agents.
o 所描述的解决方案不需要对VPN网关或移动IPv4外部代理进行任何更改。
IPsec protocol
IPsec协议
o The solution does not require any changes to existing IPsec or key exchange standard protocols, and does not require implementation of new protocols in the VPN device.
o 该解决方案不需要对现有IPsec或密钥交换标准协议进行任何更改，也不需要在VPN设备中实施新协议。
Multi-vendor interoperability
多供应商互操作性
o The solution provides easy multi-vendor interoperability between server components (VPN device, foreign agents, and home agents). Indeed, these components need not be aware of each other.
o 该解决方案在服务器组件（VPN设备、外部代理和本地代理）之间提供了方便的多供应商互操作性。事实上，这些组件不需要相互了解。
o The mobile node networking stack is somewhat complex to implement, which may be an issue for multi-vendor interoperability. However, this is a purely software architecture issue, and there are no known protocol limitations for multi-vendor interoperability.
o 移动节点网络堆栈的实现有些复杂，这可能是多供应商互操作性的一个问题。然而，这纯粹是一个软件体系结构问题，多供应商互操作性没有已知的协议限制。
MIPv4 protocol
MIPv4协议
o The solution adheres to the MIPv4 protocol, but requires the new Trusted Networks Configured extension to improve the trustworthiness of internal network detection.
o 该解决方案遵循MIPv4协议，但需要配置新的可信网络扩展，以提高内部网络检测的可信度。
o The solution requires the use of two parallel MIPv4 layers.
o 该解决方案需要使用两个并行的MIPv4层。
Handoff overhead
切换开销
o The solution provides a mechanism to avoid VPN tunnel SA renegotiation upon movement by using the external MIPv4 layer.
o 该解决方案通过使用外部MIPv4层，提供了一种避免VPN隧道SA在移动时重新协商的机制。
Scalability, availability, reliability, and performance
可扩展性、可用性、可靠性和性能
o The solution complexity is linear with the number of MNs registered and accessing resources inside the intranet.
o 解决方案的复杂性与内部网中注册和访问资源的MN数成线性关系。
o Additional overhead is imposed by the solution.
o 解决方案会增加额外的开销。
Functional entities
功能实体
o The solution does not impose any new types of functional entities or required changes to existing entities. However, an external HA device is required.
o 该解决方案不会对现有实体施加任何新类型的功能实体或所需的更改。但是，需要外部HA设备。
Implications of intervening NAT gateways
介入NAT网关的含义
o The solution leverages existing MIPv4 NAT traversal [mipnat] and IPsec NAT traversal [RFC3947] [RFC3948] solutions and does not require any new functionality to deal with NATs.
o 该解决方案利用现有的MIPv4 NAT穿越[mipnat]和IPsec NAT穿越[RFC3947][RFC3948]解决方案，不需要任何新功能来处理NAT。
Security implications
安全影响
o The solution requires a new mechanism to detect whether the mobile node is in the internal or the external network. The security of this mechanism is critical in ensuring that the security level
o 该解决方案需要一种新的机制来检测移动节点是在内部网络中还是在外部网络中。该机制的安全性对于确保安全级别至关重要
provided by IPsec is not compromised by a faulty detection mechanism.
IPsec提供的数据不会受到错误检测机制的影响。
o When the mobile node is outside, the external Mobile IPv4 layer may allow some traffic redirection attacks that plain IPsec does not allow. Other than that, IPsec security is unchanged.
o 当移动节点位于外部时，外部移动IPv4层可能允许一些普通IPsec不允许的流量重定向攻击。除此之外，IPsec安全性保持不变。
o More security considerations are described in Section 6.
o 第6节介绍了更多的安全注意事项。
The maximum packet overhead depends on access mode as follows:
最大数据包开销取决于访问模式，如下所示：
o f: 0 octets
o f:0八位字节
o c: 20 octets
o c:20个八位组
o fvc: 77 octets
o fvc:77个八位组
o cvc: 97 octets
o cvc:97个八位组
The maximum overhead of 97 octets in the 'cvc' access mode consists of the following:
“cvc”访问模式下97个八位字节的最大开销包括：
o IP-IP for i-MIPv4: 20 octets
o i-MIPv4的IP-IP:20个八位组
o IPsec ESP: 57 octets total, consisting of 20 (new IP header), 4+4+8 = 16 (SPI, sequence number, cipher initialization vector), 7+2 = 9 (padding, padding length field, next header field), 12 (ESP authentication trailer)
o IPsec ESP：总共57个八位字节，包括20个（新IP头）、4+4+8=16（SPI、序列号、密码初始化向量）、7+2=9（填充、填充长度字段、下一个头字段）、12个（ESP验证尾）
o IP-IP for x-MIPv4: 20 octets
o x-MIPv4的IP-IP:20个八位组
When IPsec is used, a variable amount of padding is present in each ESP packet. The figures were computed for a cipher with 64-bit block size, padding overhead of 9 octets (next header field, padding length field, and 7 octets of padding; see Section 2.4 of [RFC4303]), and ESP authentication field of 12 octets (HMAC-SHA1-96 or HMAC-MD5-96). Note that an IPsec implementation MAY pad with more than a minimum amount of octets.
当使用IPsec时，每个ESP数据包中都存在可变的填充量。这些数字是针对具有64位块大小、9个八位字节的填充开销（下一个标头字段、填充长度字段和7个八位字节的填充；参见[RFC4303]第2.4节）和12个八位字节的ESP认证字段（HMAC-SHA1-96或HMAC-MD5-96）的密码计算的。请注意，IPsec实现可能会使用超过最小数量的八位字节进行填充。
NAT traversal overhead is not included, and adds 8 octets when IPsec NAT traversal [RFC3947] [RFC3948] is used and 12 octets when MIP NAT traversal [mipnat] is used. For instance, when using access mode cvc, the maximum NAT traversal overhead is 12+8+12 = 32 octets. Thus, the worst case scenario (with the above mentioned ESP assumptions) is 129 octets for cvc.
NAT穿越开销不包括在内，当使用IPsec NAT穿越[RFC3947][RFC3948]时增加8个八位字节，当使用MIP NAT穿越[mipnat]时增加12个八位字节。例如，当使用访问模式cvc时，最大NAT遍历开销为12+8+12=32个八位字节。因此，cvc的最坏情况（根据上述ESP假设）是129个八位字节。
When the MN is inside, connection setup latency does not increase compared to standard MIPv4 if the MN implements the suggested parallel registration sequence (see Section 3.3). Exchange of RRQ/ RRP messages with the i-HA confirms the MN is inside, and the MN may start sending and receiving user traffic immediately. For the same reason, handovers in the internal network have no overhead relative to standard MIPv4.
当MN在内部时，如果MN实现建议的并行注册序列，则与标准MIPv4相比，连接设置延迟不会增加（参见第3.3节）。与i-HA交换RRQ/RRP消息确认MN在内部，并且MN可以立即开始发送和接收用户流量。出于同样的原因，与标准MIPv4相比，内部网络中的切换没有开销。
When the MN is outside, the situation is slightly different. Initial connection setup latency essentially consists of (1) registration with the x-HA, (2) optional detection delay (waiting for i-HA response), (3) IPsec connection setup (IKE), and (4) registration with the i-HA. All but (4) are in addition to standard MIPv4.
当MN在外部时，情况略有不同。初始连接设置延迟主要包括（1）向x-HA注册，（2）可选检测延迟（等待i-HA响应），（3）IPsec连接设置（IKE）和（4）向i-HA注册。除第（4）项外，所有内容都是标准MIPv4之外的内容。
However, handovers in the external network have performance comparable to standard MIPv4. The MN simply re-registers with the x-HA and starts to send IPsec traffic to the VPN gateway from the new address.
但是，外部网络中的切换具有与标准MIPv4相当的性能。MN只需向x-HA重新注册，并开始从新地址向VPN网关发送IPsec流量。
The MN may minimize latency by (1) not waiting for an i-HA response before triggering IKE if the x-HA registration succeeds and (2) sending first the RRQ most likely to succeed (e.g., if the MN is most likely outside). These can be done based on heuristics about the network, e.g., addresses, MAC address of the default gateway (which the mobile node may remember from previous access); based on the previous access network (i.e., optimize for inside-inside and outside-outside movement); etc.
MN可以通过以下方式最小化延迟：（1）如果x-HA注册成功，则在触发IKE之前不等待i-HA响应；（2）首先发送最有可能成功的RRQ（例如，如果MN最有可能在外部）。这些可以基于关于网络的试探法来完成，例如，地址、默认网关的MAC地址（移动节点可以从先前的访问中记住）；基于之前的接入网络（即优化内外移动）；等
A separate firewall device or an integrated firewall in the VPN gateway typically performs stateful inspection of user traffic. The firewall may, for instance, track TCP session status and block TCP segments not related to open connections. Other stateful inspection mechanisms also exist.
VPN网关中的单独防火墙设备或集成防火墙通常执行用户流量的状态检查。例如，防火墙可以跟踪TCP会话状态并阻止与打开的连接无关的TCP段。还有其他有状态的检查机制。
Firewall state poses a problem when the mobile node moves between the internal and external networks. The mobile node may, for instance, initiate a TCP connection while inside, and later go outside while expecting to keep the connection alive. From the point of view of the firewall, the TCP connection has not been initiated, as it has not witnessed the TCP connection setup packets, thus potentially resulting in connectivity problems.
当移动节点在内部和外部网络之间移动时，防火墙状态会带来问题。例如，移动节点可以在内部发起TCP连接，然后在期望保持连接活动的情况下外出。从防火墙的角度来看，TCP连接尚未启动，因为它没有见证TCP连接设置数据包，因此可能导致连接问题。
When the VPN-TIA is registered as a co-located care-of address with the i-HA, all mobile node traffic appears as IP-IP for the firewall.
当VPN-TIA注册为与i-HA位于同一位置的转交地址时，防火墙的所有移动节点流量均显示为IP-IP。
Typically, firewalls do not continue inspection beyond the IP-IP tunnel, but support for deeper inspection is available in many products. In particular, an administrator can configure traffic policies in many firewall products even for IP-IP encapsulated traffic. If this is done, similar statefulness issues may arise.
通常，防火墙不会在IP-IP隧道之外继续检查，但许多产品都支持更深入的检查。特别是，管理员可以在许多防火墙产品中配置流量策略，甚至针对IP-IP封装的流量。如果这样做，可能会出现类似的状态性问题。
In summary, the firewall must allow traffic coming from and going into the IPsec connection to be routed, even though they may not have successfully tracked the connection state. How this is done is out of scope of this document.
总之，防火墙必须允许路由来自和进入IPsec连接的流量，即使它们可能没有成功跟踪连接状态。如何做到这一点超出了本文件的范围。
Many firewalls incorporate intrusion detection systems monitoring network traffic for unusual patterns and clear signs of attack. Since traffic from a mobile node implementing this specification is UDP to i-HA port 434, and possibly IP-IP traffic to the i-HA address, existing IDSs may treat the traffic differently than ordinary VPN remote access traffic. Like firewalls, IDSs are not standardized, so it is impossible to guarantee interoperability with any particular IDS system.
许多防火墙包含入侵检测系统，用于监控网络流量，以发现异常模式和明显的攻击迹象。由于来自实现此规范的移动节点的流量是UDP到i-HA端口434的流量，并且可能是IP-IP到i-HA地址的流量，因此现有的IDS可能会以不同于普通VPN远程访问流量的方式处理该流量。像防火墙一样，IDS也没有标准化，因此无法保证与任何特定IDS系统的互操作性。
Implementation of the mobile node requires the use of three tunneling layers, which may be used in various configurations depending on whether that particular interface is inside or outside. Note that it is possible that one interface is inside and another interface is outside, which requires a different layering for each interface at the same time.
移动节点的实现需要使用三个隧道层，这三个隧道层可以在各种配置中使用，取决于特定接口是在内部还是外部。请注意，一个接口可能在内部，另一个接口在外部，这需要同时对每个接口进行不同的分层。
For multi-vendor implementation, the IPsec and MIPv4 layers need to interoperate in the same mobile node. This implies that a flexible framework for protocol layering (or protocol-specific APIs) is required.
对于多供应商实现，IPsec和MIPv4层需要在同一移动节点中进行互操作。这意味着需要一个灵活的协议分层框架（或特定于协议的API）。
The solution also works for VPN tunneling protocols that are not IPsec-based, provided that the mobile node is provided IPv4 connectivity with an address suitable for registration. However, such VPN protocols are not explicitly considered.
该解决方案还适用于不基于IPsec的VPN隧道协议，前提是为移动节点提供具有适合注册的地址的IPv4连接。然而，这种VPN协议没有被明确考虑。
If the mobile node by mistake believes it is in the internal network and sends plaintext packets, it compromises IPsec security. For this reason, the overall security (confidentiality and integrity) of user data is a minimum of (1) IPsec security and (2) security of the internal network detection mechanism.
如果移动节点错误地认为它在内部网络中并发送明文数据包，则会危及IPsec安全。因此，用户数据的总体安全性（机密性和完整性）至少为（1）IPsec安全性和（2）内部网络检测机制的安全性。
Security of the internal network detection relies on a successful registration with the i-HA. For standard Mobile IPv4 [RFC3344], this means HMAC-MD5 and Mobile IPv4 replay protection. The solution also assumes that the i-HA is not directly reachable from the external network, requiring careful enterprise firewall configuration. To minimize the impact of a firewall configuration problem, the i-HA is separately required to be configured with trusted source addresses (i.e., addresses belonging to the internal network), and to include an indication of this in a new Trusted Networks Configured extension. The MN is required not to trust a registration as an indication of being connected to the internal network, unless this extension is present in the registration reply. Thus, to actually compromise user data confidentiality, both the enterprise firewall and the i-HA have to be configured incorrectly, which reduces the likelihood of the scenario.
内部网络检测的安全性依赖于向i-HA成功注册。对于标准移动IPv4[RFC3344]，这意味着HMAC-MD5和移动IPv4重播保护。该解决方案还假设无法从外部网络直接访问i-HA，因此需要仔细配置企业防火墙。为了最大限度地减少防火墙配置问题的影响，i-HA需要单独配置可信源地址（即，属于内部网络的地址），并在新的可信网络配置扩展中包含此指示。MN不需要信任注册作为连接到内部网络的指示，除非注册回复中存在此扩展。因此，为了实际损害用户数据的机密性，必须错误地配置企业防火墙和i-HA，这降低了出现这种情况的可能性。
When the mobile node sends a registration request to the i-HA from an untrusted network that does not go through the IPsec tunnel, it will reveal the i-HA's address, its own identity including the NAI and the home address, and the Authenticator value in the authentication extensions to the untrusted network. This may be a concern in some deployments.
当移动节点从未通过IPsec隧道的不受信任网络向i-HA发送注册请求时，它将显示i-HA的地址、其自身身份（包括NAI和家庭地址）以及不受信任网络的身份验证扩展中的身份验证者值。在某些部署中，这可能是一个问题。
When the connection status of an interface changes, an interface previously connected to the trusted internal network may suddenly be connected to an untrusted network. Although the same problem is also relevant to IPsec-based VPN implementations, the problem is especially relevant in the scope of this specification.
当接口的连接状态改变时，先前连接到受信任内部网络的接口可能突然连接到不受信任的网络。尽管同样的问题也与基于IPsec的VPN实现有关，但该问题在本规范的范围内尤其相关。
In most cases, mobile node implementations are expected to have layer 2 information available, making connection change detection both fast and robust. To cover cases where such information is not available (or fails for some reason), the mobile node is required to periodically re-register with the internal home agent to verify that it is still connected to the trusted network. It is also required that this re-registration interval be configurable, thus giving the administrator a parameter by which potential exposure may be controlled.
在大多数情况下，移动节点的实现需要有第2层信息可用，从而使连接更改检测既快速又可靠。为了涵盖此类信息不可用（或由于某种原因失败）的情况，移动节点需要定期向内部归属代理重新注册，以验证其仍然连接到受信任网络。还要求该重新注册间隔是可配置的，从而为管理员提供一个参数，通过该参数可以控制潜在的暴露。
MIPv4 and IPsec have different goals and approaches for providing security services. MIPv4 typically uses a shared secret for authentication of signaling traffic, while IPsec typically uses IKE (an authenticated Diffie-Hellman exchange) to set up session keys. Thus, the overall security properties of a combined MIPv4 and IPsec system depend on both mechanisms.
MIPv4和IPsec在提供安全服务方面有不同的目标和方法。MIPv4通常使用共享秘密对信令流量进行身份验证，而IPsec通常使用IKE（经过身份验证的Diffie-Hellman交换）来设置会话密钥。因此，MIPv4和IPsec组合系统的总体安全属性取决于这两种机制。
In the solution outlined in this document, the external MIPv4 layer provides mobility for IPsec traffic. If the security of MIPv4 is broken in this context, traffic redirection attacks against the IPsec traffic are possible. However, such routing attacks do not affect other IPsec properties (confidentiality, integrity, replay protection, etc.), because IPsec does not consider the network between two IPsec endpoints to be secure in any way.
在本文档概述的解决方案中，外部MIPv4层为IPsec通信提供移动性。如果在此上下文中MIPv4的安全性被破坏，则可能会发生针对IPsec流量的流量重定向攻击。然而，这样的路由攻击不会影响其他IPSec属性（机密性、完整性、重放保护等），因为IPSec不认为两个IPSec端点之间的网络以任何方式安全。
Because MIPv4 shared secrets are usually configured manually, they may be weak if easily memorizable secrets are chosen, thus opening up redirection attacks described above. Note especially that a weak secret in the i-HA is fatal to security, as the mobile node can be fooled into dropping encryption if the i-HA secret is broken.
由于MIPv4共享机密通常是手动配置的，因此如果选择易于记忆的机密，它们可能会很弱，从而打开上述重定向攻击。请特别注意，i-HA中的弱机密对安全性是致命的，因为如果i-HA机密被破坏，移动节点可能会被欺骗而放弃加密。
Assuming the MIPv4 shared secrets have sufficient entropy, there are still at least the following differences and similarities between MIPv4 and IPsec worth considering:
假设MIPv4共享机密具有足够的熵，MIPv4和IPsec之间至少还有以下值得考虑的区别和相似之处：
o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT" attack described in [pseudonat] and [mipnat], assuming that NAT traversal is enabled (which is typically the case). "Pseudo NAT" attacks allow an attacker to redirect traffic flows, resulting in resource consumption, lack of connectivity, and denial of service. However, such attacks cannot compromise the confidentiality of user data protected using IPsec.
o 假设启用了NAT遍历（通常情况下），IPsec和MIPv4都容易受到[pseudonat]和[mipnat]中描述的“瞬态伪NAT”攻击。“伪NAT”攻击允许攻击者重定向流量，导致资源消耗、连接不足和拒绝服务。但是，此类攻击不能损害使用IPsec保护的用户数据的机密性。
o When considering a "pseudo NAT" attack against standard IPsec and standard MIP (with NAT traversal), redirection attacks against MIP may be easier because:
o 当考虑针对标准IPsec和标准MIP（使用NAT遍历）的“伪NAT”攻击时，针对MIP的重定向攻击可能更容易，因为：
* MIPv4 re-registrations typically occur more frequently than IPsec SA setups (although this may not be the case for mobile hosts).
* MIPv4重新注册通常比IPsec SA设置更频繁（尽管移动主机可能不是这样）。
* It suffices to catch and modify a single registration request, whereas attacking IKE requires that multiple IKE packets are caught and modified.
* 它足以捕获和修改单个注册请求，而攻击IKE则需要捕获和修改多个IKE数据包。
o There may be concerns about mixing of algorithms. For instance, IPsec may be using HMAC-SHA1-96, while MIP is always using HMAC-MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Furthermore, while IPsec algorithms are typically configurable, MIPv4 clients typically use only HMAC-MD5 or prefix+suffix MD5. Although this is probably not a security problem as such, it is more difficult to communicate to users.
o 可能存在混合算法的问题。例如，IPsec可能使用HMAC-SHA1-96，而MIP始终使用HMAC-MD5（RFC 3344）或前缀+后缀MD5（RFC 2002）。此外，虽然IPsec算法通常是可配置的，但MIPv4客户端通常只使用HMAC-MD5或前缀+后缀MD5。虽然这本身可能不是一个安全问题，但与用户通信更为困难。
o When IPsec is used with a Public Key Infrastructure (PKI), the key management properties are superior to those of basic MIPv4. Thus, adding MIPv4 to the system makes key management more complex.
o 当IPsec与公钥基础设施（PKI）一起使用时，密钥管理属性优于基本的MIPv4。因此，将MIPv4添加到系统中会使密钥管理更加复杂。
o In general, adding new security mechanisms increases overall complexity and makes the system more difficult to understand.
o 一般来说，添加新的安全机制会增加总体复杂性，并使系统更难理解。
This document specifies a new skippable extension (in the short format) in Section 3.4, whose Type and Sub-Type values have been assigned.
本文件在第3.4节中指定了一个新的可跳过扩展名（短格式），其类型和子类型值已分配。
Allocation of new Sub-Type values can be made via Expert Review and Specification Required [RFC5226].
可通过专家评审和所需规范分配新的子类型值[RFC5226]。
This document is a joint work of the contributing authors (in alphabetical order):
本文件是投稿作者的联合作品（按字母顺序排列）：
- Farid Adrangi (Intel Corporation) - Nitsan Baider (Check Point Software Technologies, Inc.) - Gopal Dommety (Cisco Systems) - Eli Gelasco (Cisco Systems) - Dorothy Gellert (Nokia Corporation) - Espen Klovning (Birdstep) - Milind Kulkarni (Cisco Systems) - Henrik Levkowetz (ipUnplugged AB) - Frode Nielsen (Birdstep) - Sami Vaarala (Codebay) - Qiang Zhang (Liqwid Networks, Inc.)
- Farid Adrangi（英特尔公司）-Nitsan Baider（Check Point Software Technologies，Inc.）-Gopal Dommety（思科系统）-Eli Gelasco（思科系统）-Dorothy Gellert（诺基亚公司）-Espen Kloving（Birdstep）-Milind Kulkarni（思科系统）-Henrik Levkowetz（Ipkowetz AB）-Frode Nielsen（Birdstep）-Sami Vaarala（Codebay）-张强（Liqwid网络有限公司）
The authors would like to thank the MIP/VPN design team, especially Mike Andrews, Gaetan Feige, Prakash Iyer, Brijesh Kumar, Joe Lau, Kent Leung, Gabriel Montenegro, Ranjit Narjala, Antti Nuopponen, Alan O'Neill, Alpesh Patel, Ilkka Pietikainen, Phil Roberts, Hans Sjostrand, and Serge Tessier for their continuous feedback and helping us improve this document. Special thanks to Radia Perlman for giving the document a thorough read and a security review. Tom
作者要感谢MIP/VPN设计团队，特别是Mike Andrews、Gaetan Feige、Prakash Iyer、Brijesh Kumar、Joe Lau、Kent Leung、Gabriel黑山、Ranjit Narjala、Antti Nuopponen、Alan O'Neill、Alpesh Patel、Ilka Pietikainen、Phil Roberts、Hans Sjostrand、，以及Serge Tessier，感谢他们的持续反馈，并帮助我们改进本文件。特别感谢Radia Perlman对文件进行了全面阅读和安全审查。汤姆
Hiller pointed out issues with battery-powered devices. We would also like to thank the previous Mobile IP working group chairs (Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important feedback and guidance.
希勒指出了电池供电设备的问题。我们还要感谢前移动IP工作组主席（加布里埃尔·黑山、巴萨瓦拉吉·帕蒂尔和菲尔·罗伯茨）提供的重要反馈和指导。
[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月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，Ed.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[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月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[mipnat] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
[mipnat]Levkowetz，H.和S.Vaarala，“网络地址转换（NAT）设备的移动IP遍历”，RFC 3519，2003年4月。
[privaddr] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[privaddr]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002]Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456]Patel，B.，Aboba，B.，Kelly，S.，和V.Gupta，“IPsec隧道模式的动态主机配置协议（DHCPv4）配置”，RFC 3456，2003年1月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776]Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005.
[RFC4093]Adrangi，F.和H.Levkowetz，“问题陈述：虚拟专用网络（VPN）网关的移动IPv4穿越”，RFC 4093，2005年8月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[pseudonat] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", Work in Progress, June 2004.
杜邦，F.和J.伯纳德，“短暂的伪NAT攻击或NAT比你想象的更邪恶”，正在进行的工作，2004年6月。
[tessier] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage", Work in Progress, December 2002.
[tessier]tessier，S.，“移动IP和IPsec VPN使用指南”，正在进行的工作，2002年12月。
The following figure illustrates connection setup when the mobile node is outside and using a co-located care-of address. IKE connection setup is not shown in full, and involves multiple round trips (4.5 round trips when using main mode followed by quick mode).
下图说明了当移动节点位于外部并使用同一位置的转交地址时的连接设置。IKE连接设置未完整显示，并涉及多个往返（使用主模式后接快速模式时为4.5个往返）。
MN-APP MN x-HA VPN i-HA CN
! ! ! ! ! !
! ! -------> ! ! ! !
! ! rrq ! ! ! !
! ! -----------------X ! ! ! rrq not
! ! rrq ! ! ! ! received
! ! ! ! ! ! by i-HA
! ! <------- ! ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
! [wait for detection period for response from i-HA] !
! [may also retransmit to i-HA, depending on config] ! no rrp
! ! ! ! ! ! from i-HA
! ! ==(1)==> ! ! ! !
! ! ike {1a}! -------> ! ! !
! ! ! ike ! ! !
! ! ! <------- ! ! !
! ! <==(1)== ! ike ! ! !
! ! ike ! ! ! !
: : : : : :
: : : : : :
! ! ! ! ! !
! ! ==(2)==> ! ! ! !
! ! rrq {2a}! ==(1)==> ! ! !
! ! ! rrq {2b}! -------> ! !
! ! ! ! rrq {2c}! !
! ! ! ! <------- ! !
! ! ! <==(1)== ! rrp ! !
! ! <==(2)== ! rrp ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
[[--- connection setup ok, bidirectional connection up ---]]
! ! ! ! ! !
! -------> ! ! ! ! !
! pkt {3a}! ==(3)==> ! ! ! !
! ! pkt {3b}! ==(2)==> ! ! !
! ! ! pkt {3c}! ==(1)==> ! !
! ! ! ! pkt {3d}! -------> !
! ! ! ! ! pkt {3e}!
! ! ! ! ! <------- !
! ! ! ! <==(1)== ! pkt !
! ! ! <==(2)== ! pkt ! !
! ! <==(3)== ! pkt ! ! !
! <------ ! pkt ! ! ! !
! pkt ! ! ! ! !
: : : : : :
: : : : : :
MN-APP MN x-HA VPN i-HA CN
! ! ! ! ! !
! ! -------> ! ! ! !
! ! rrq ! ! ! !
! ! -----------------X ! ! ! rrq not
! ! rrq ! ! ! ! received
! ! ! ! ! ! by i-HA
! ! <------- ! ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
! [wait for detection period for response from i-HA] !
! [may also retransmit to i-HA, depending on config] ! no rrp
! ! ! ! ! ! from i-HA
! ! ==(1)==> ! ! ! !
! ! ike {1a}! -------> ! ! !
! ! ! ike ! ! !
! ! ! <------- ! ! !
! ! <==(1)== ! ike ! ! !
! ! ike ! ! ! !
: : : : : :
: : : : : :
! ! ! ! ! !
! ! ==(2)==> ! ! ! !
! ! rrq {2a}! ==(1)==> ! ! !
! ! ! rrq {2b}! -------> ! !
! ! ! ! rrq {2c}! !
! ! ! ! <------- ! !
! ! ! <==(1)== ! rrp ! !
! ! <==(2)== ! rrp ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
[[--- connection setup ok, bidirectional connection up ---]]
! ! ! ! ! !
! -------> ! ! ! ! !
! pkt {3a}! ==(3)==> ! ! ! !
! ! pkt {3b}! ==(2)==> ! ! !
! ! ! pkt {3c}! ==(1)==> ! !
! ! ! ! pkt {3d}! -------> !
! ! ! ! ! pkt {3e}!
! ! ! ! ! <------- !
! ! ! ! <==(1)== ! pkt !
! ! ! <==(2)== ! pkt ! !
! ! <==(3)== ! pkt ! ! !
! <------ ! pkt ! ! ! !
! pkt ! ! ! ! !
: : : : : :
: : : : : :
The notation "==(N)==>" or "<==(N)==" indicates that the innermost packet has been encapsulated N times, using IP-IP, ESP, or MIP NAT traversal.
符号“==（N）=>”或“<=（N）==”表示最里面的数据包已经使用IP-IP、ESP或MIP NAT遍历被封装了N次。
Packets marked with {xx} are shown in more detail below. Each area represents a protocol header (labeled). Source and destination addresses or ports are shown underneath the protocol name when applicable. Note that there are no NAT traversal headers in the example packets.
下面将更详细地显示标有{xx}的数据包。每个区域代表一个协议头（标记）。适用时，源和目标地址或端口显示在协议名称下方。注意，示例数据包中没有NAT遍历头。
Packet {1a}
.------------------------------------.
! IP ! IP ! UDP ! IKE !
! co-CoA ! x-HoA ! 500 ! !
! x-HA ! VPN-GW ! 500 ! !
`------------------------------------'
Packet {1a}
.------------------------------------.
! IP ! IP ! UDP ! IKE !
! co-CoA ! x-HoA ! 500 ! !
! x-HA ! VPN-GW ! 500 ! !
`------------------------------------'
Packet {2a}
.--------------------------------------------------------.
! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ !
! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! !
! x-HA ! VPN-GW ! ! i-HA ! 434 ! !
`--------------------------------------------------------'
Packet {2a}
.--------------------------------------------------------.
! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ !
! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! !
! x-HA ! VPN-GW ! ! i-HA ! 434 ! !
`--------------------------------------------------------'
Packet {2b}
.----------------------------------------------.
! IP ! ESP ! IP ! UDP ! MIP RRQ !
! x-HoA ! ! VPN-TIA ! ANY ! !
! VPN-GW ! ! i-HA ! 434 ! !
`----------------------------------------------'
Packet {2b}
.----------------------------------------------.
! IP ! ESP ! IP ! UDP ! MIP RRQ !
! x-HoA ! ! VPN-TIA ! ANY ! !
! VPN-GW ! ! i-HA ! 434 ! !
`----------------------------------------------'
Packet {2c}
.----------------------------.
! IP ! UDP ! MIP RRQ !
! VPN-TIA ! ANY ! !
! i-HA ! 434 ! !
`----------------------------'
Packet {2c}
.----------------------------.
! IP ! UDP ! MIP RRQ !
! VPN-TIA ! ANY ! !
! i-HA ! 434 ! !
`----------------------------'
Packet {3a}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3a}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3b}
.------------------------------------------------------- -
! IP ! IP ! ESP ! IP ! IP ! user \
! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../
! x-HA ! VPN-GW ! ! i-HA ! CN ! \
`------------------------------------------------------- -
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
Packet {3b}
.------------------------------------------------------- -
! IP ! IP ! ESP ! IP ! IP ! user \
! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../
! x-HA ! VPN-GW ! ! i-HA ! CN ! \
`------------------------------------------------------- -
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
Packet {3c}
.--------------------------------------------------------.
! IP ! ESP ! IP ! IP ! user ! ESP !
! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer !
! VPN-GW ! ! i-HA ! CN ! ! !
`--------------------------------------------------------'
Packet {3c}
.--------------------------------------------------------.
! IP ! ESP ! IP ! IP ! user ! ESP !
! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer !
! VPN-GW ! ! i-HA ! CN ! ! !
`--------------------------------------------------------'
Packet {3d}
.------------------------------.
! IP ! IP ! user !
! VPN-TIA ! i-HoA ! protocol !
! i-HA ! CN ! !
`------------------------------'
Packet {3d}
.------------------------------.
! IP ! IP ! user !
! VPN-TIA ! i-HoA ! protocol !
! i-HA ! CN ! !
`------------------------------'
Packet {3e}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3e}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3b} with all NAT traversal headers (x-MIP, ESP, and i-MIP) is shown below for comparison.
具有所有NAT遍历头（x-MIP、ESP和i-MIP）的数据包{3b}如下所示，以供比较。
Packet {3b} (with NAT traversal headers)
.------------------------------------------------- -
! IP ! UDP ! MIP ! IP ! UDP ! ESP.. \
! co-CoA ! ANY ! tunnel ! x-HoA ! 4500 ! /
! x-HA ! 434 ! data ! VPN-GW ! 4500 ! \
`------------------------------------------------- -
<=== external MIPv4 ====> <=== IPsec ESP ======== = =
Packet {3b} (with NAT traversal headers)
.------------------------------------------------- -
! IP ! UDP ! MIP ! IP ! UDP ! ESP.. \
! co-CoA ! ANY ! tunnel ! x-HoA ! 4500 ! /
! x-HA ! 434 ! data ! VPN-GW ! 4500 ! \
`------------------------------------------------- -
<=== external MIPv4 ====> <=== IPsec ESP ======== = =
- - ------------------------------------------------ -
\..ESP ! IP ! UDP ! MIP ! IP ! user \
/ ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../
\ ! i-HA ! 434 ! data ! CN ! \
- - ------------------------------------------------ -
= ===> <==== internal MIPv4 ====> <== user packet == =
- - ------------------------------------------------ -
\..ESP ! IP ! UDP ! MIP ! IP ! user \
/ ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../
\ ! i-HA ! 434 ! data ! CN ! \
- - ------------------------------------------------ -
= ===> <==== internal MIPv4 ====> <== user packet == =
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
= = ======> <= ESP =>
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
= = ======> <= ESP =>
Authors' Addresses
作者地址
Sami Vaarala Codebay P.O. Box 63 Espoo 02601 FINLAND
Sami Vaarala Codebay邮政信箱63芬兰埃斯波02601
Phone: +358 (0)50 5733 862
EMail: sami.vaarala@iki.fi
Phone: +358 (0)50 5733 862
EMail: sami.vaarala@iki.fi
Espen Klovning Birdstep Bryggegata 7 Oslo 0250 NORWAY
Espen Kloving Birdstep Bryggegata 7挪威奥斯陆0250
Phone: +47 95 20 26 29
EMail: espen@birdstep.com
Phone: +47 95 20 26 29
EMail: espen@birdstep.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.